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

[Ilari Liusvaara <[e-mail]>]

On Wed, Dec 26, 2018 at 07:14:44AM -0800, Eric Rescorla wrote:
> On Wed, Dec 26, 2018 at 6:56 AM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > 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.
> >
> 
> 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.

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