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

[Ilari Liusvaara <[e-mail]>]

On Mon, Dec 24, 2018 at 12:47:30PM -0800, Eric Rescorla wrote:
> 
> 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?

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