Subject: [Acme] AD Review: draft-ietf-acme-tls-alpn-05

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Dec 2018 12:47:30 -0800

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5386

IMPORTANT
S 3.
>          the handshake MUST contain a ALPN extension with the single
>          protocol name "acme-tls/1" and a Server Name Indication [RFC6066]
>          extension containing the domain name being validated.
>
>      4.  Verify that the ServerHello contains a ALPN extension containing
>          the value "acme-tls/1" and that the certificate returned contains

This will not work with TLS 1.3, where ALPN is in EE.

S 4.
>      properly segregates control of those names to the users that own
>      them.  This means that if User A registers Host A and User B
>      registers Host B the server should not allow a TLS request using a
>      SNI value for Host A to be served by User B or Host B to be served by
>      User A.  If the server allows User B to serve this request it allows
>      them to illegitimately validate control of Host A to the ACME server.

Isn't this the property you say doesn't hold in S 6 below. As I
understand it, the rationale for this design is that people who opt in
to acme-tls/1 won't do this, no?

COMMENTS
S 3.
>      that it is returned during a TLS handshake that contains a ALPN
>      extension containing the value "acme-tls/1" and a SNI extension
>      containing the domain name being validated.
>
>      A client responds with an empty object ({}) to acknowledge that the
>      challenge is ready to be validated by the server.  The base64url

This isn't really a response. It posts a message.

S 4.
>      blindly agreeing to use the "acme-tls/1" protocol without actually
>      understanding it.
>
>      To further mitigate the risk of users claiming domain names used by
>      other users on the same infrastructure hosting providers, CDNs, and
>      other service providers should not allow users to provide their own

Should this be a 2119/8174 SHOULD NOT?

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 26 Dec 2018 16:56:25 +0200

> to acme-tls/1 won't do this, no?

No. This is a different property than one mentioned in S6. This is due
to different SNI used.

The property wanted here is basically coherence of HTTP and TLS
forwarding: Both are always forwarded to the same user for the same
name. If such coherence exists, the ALPN acts as just muxing
function (allow validating without bringing the host down).

Such coherence is not enough for TLS-SNI, as the SNI sent is junk,
so nobody has seen it before. The service provoder would have to
block the TLS-SNI names in order to not be vulernable.

If there is no such coherence, then if acme-tls/1 is forwarded, then
the attacker can misvalidate if the legit user has not already enabled
HTTPS. However, this is not sufficient to deter attacks if HTTPS is
not enabled yet: Merely forwarding the HTTPS pkix validation path is
enough to misvalidate (some CAs can use it to validate, as it is
consistent with BRs). With publically trusted certificate, attacker
can then abuse HSTS (HTTP Strict Transport Security) to hijack traffic
without having to mess with DNS or BGP.

My interpretation of BR method 10 is that it requires the authorization
domain name to be present in certficate ("a certificate on the
authorization domain name"). TLS-SNI fails this requirement, as the
certificate most definitely is not on the authorization domain name. I
do not think any reasonable implementation of method 10 is vulernable
to the attack that fell TLS-SNI (as reasonable implementation would set
SNI to the authorization domain name, which makes attacks much more
difficult). Nevertheless, CABForum is considering scrapping method 10
and replacing it with something like TLS-ALPN.

And with regards of servers blindly selecting ALPN, I really do not
think any server does this, as it would cause a lot of connect
failures (any modern browser would fail if HTTP/2 is not also enabled).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Dec 2018 07:14:44 -0800

> No. This is a different property than one mentioned in S6. This is due

That appears to be what S 6 says as well:

   domain names they controlled (i.e. if User A registered Host A and
   User B registered Host B with a service provider that User A wouldn't
   be able to respond to SNI traffic for Host B).  This turns out not to

So at minimum some improved text is required here.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 26 Dec 2018 17:33:13 +0200

> So at minimum some improved text is required here.

Oh, that text in S6 looks to be incorrect.

Maybe something like (some further wordsmithing needed):

When the TLS SNI challenge was designed it was assumed that a user
would only be able to respond to TLS traffic via SNI for domain names
they controlled (i.e. User A would only be able to register Host A if
they controlled the domain name for Host A).

TLS-SNI needs stronger properties than coherent FCFS registration of
names for security. Specifically, it needs some mechanism that prevents
the registration of validation names.

-Ilari