Subject: [Acme] Proposed changes to TLS-SNI, autorenewal removal

From: Hugo Landau <[email-masked]>
Date: Fri, 22 Jan 2016 16:13:07 +0000

I've submitted various pull requests for discussion here.

Firstly, I've drafted a specification for tls-sni-02
which resolves Jehiah's concerns.
  <https://github.com/ietf-wg-acme/acme/pull/71>

Secondly, I've added operational guidance for the use
of DNSSEC by ACME CAs.
  https://github.com/ietf-wg-acme/acme/pull/69

Thirdly, I propose the removal of autorenewal, which
complicates the protocol, introduces a number of concerns
and risks, and doesn't really enable anything that couldn't
be done without it. I'm also not aware of any current implementations of
it.
  <https://github.com/ietf-wg-acme/acme/pull/67>

Fourthly, I think the expiry of authorizations should be a timestamp,
not merely a date. This also fixes some examples with incorrect RFC3339
timestamps.
  <https://github.com/ietf-wg-acme/acme/pull/68>

Hugo Landau

---

From: Andrew Ayer <[email-masked]>
Date: Fri, 22 Jan 2016 10:27:25 -0800

On Fri, 22 Jan 2016 16:13:07 +0000

>   <https://github.com/ietf-wg-acme/acme/pull/71>

I agree with jehiah's comment on GitHub that for consistency with the
http-01 challenge, SAN A (the token) should be used for the SNI
request, and SAN B (the keyAuthorization) should be the SAN which the
ACME server looks for.

Also, it's not necessary for the ACME server to verify that the
returned certificate contains SAN A (the token).  Seeing the
keyAuthorization in a SAN is sufficient.

I think these changes should be made because paring the challenges down
to their essentials and making them as similar as possible makes them
much easier to reason about.  For both http-01 and tls-sni-02, the
basic procedure would be:

1. Request a resource (file or certificate) at the domain using the
token to identify the resource.

2. Verify that the returned resource contains the keyAuthorization.

-- Andrew

---

From: Hugo Landau <[email-masked]>
Date: Fri, 22 Jan 2016 18:54:43 +0000

I've reversed the roles of SAN A and SAN B. The branch has been updated.

Certificates should probably contain SAN A. If they don't, this is
liable to confuse TLS implementations and supporting infrastructure,
which doesn't expect that an SNI request for x should result in a
certificate not listing x.

You could allow extra names (which could be SAN A, or something else
entirely), but, well, why allow extra names? If you have SANs of
foo.token.acme.invalid, bar.ka.acme.invalid and example.com, something
is wrong. If you don't allow extra names, you need to check that all
naems are in {SAN A, SAN B} anyway. Or you require a SNI request for SAN
A lead to a certificate with {SAN B}, which is rather bizarre and will
probably cause problems somewhere.

This is a request-response procedure but it's a request-response
procedure being conducted in a byzantine fashion using TLS's certificate
presentation functionality. The practicalities of that mechanism must be
considered.

On Fri, Jan 22, 2016 at 10:27:25AM -0800, Andrew Ayer wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Andrew Ayer <[email-masked]>
Date: Fri, 22 Jan 2016 11:18:46 -0800

On Fri, 22 Jan 2016 18:54:43 +0000

> certificate not listing x.

Agreed, but that doesn't mean the ACME server has to check for such a
SAN.  What the client has to do and what the server has to do are
separate things, and the server should only do what's necessary to
ensure the security of the challenge.  Superfluous checks obscure the
security-critical checks, which makes the challenge harder to reason
about, and makes it harder to audit server implementations.

So I say keep the client-side part of the spec the same, but change
item three of the server-side part to say:

"Verify that the certificate contains a subjectAltName extension
containing a dNSName entry of SAN B.  The comparison MUST be
insensitive to case and ordering of names."

-- Andrew

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Jan 2016 19:20:32 +0000

> Agreed, but that doesn't mean the ACME server has to check for such a SAN.

Agreed.

> So I say keep the client-side part of the spec the same, but change item
> three of the server-side part to say:
> 
> "Verify that the certificate contains a subjectAltName extension containing a
> dNSName entry of SAN B.  The comparison MUST be insensitive to case and
> ordering of names."

In other words, follow the rules of subjectAltName per the RFC.  So perhaps strike the last sentence.