Re: [Acme] Fixing the TLS-SNI challenge type

[Ilari Liusvaara <[e-mail]>]

On Fri, Jan 19, 2018 at 04:47:59PM +0100, Richard Barnes wrote:
> On Fri, Jan 19, 2018 at 4:38 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote:
> >
> > AFAICT, the hard constraints are:
> >
> > - No taking site offline when validating.
> > - The validation certificates are not publically trusted.
> > - SNI needs to be set to the domain being validated.
> > - Compliant with reasonably strict reading of "10 methods" (which
> >   essentially impiles the third point and using certificate to
> >   transmit data).
> >
> 
> I'm less worried about this constraint.  If there's consensus for a change,
> changes can be made to the BRs much more quickly than an RFC can be issued.

Oh yeah, the minimum process latency for changing BRs is ~7 weeks.

However, that would take well-fleshed proposal to do it even close to
that quick. Take note that "10 methods" took years.
 
> > (I do not consider compatiblity with present software a hard
> > requirment).
> >
> >
> > Few ways that come to mind:
> >
> > - Have "acme" ALPN and send validation certificate for that.
> > - Have some new TLS extension and send validation certificate for that.
> >
> 
> My inclination here would be to do the whole thing in a TLS extension: Have
> the client send its value in an extension, and have the server respond in
> an extension.  It's what they're there for.  You would need upgrades to TLS
> stacks and new API for this, but IIRC, QUIC is going to require some
> similar changes to make applications aware of extensions anyway. (Cf.
> https://github.com/bifurcation/mint/pull/137 for EKR's minq implementation
> of QUIC)

Yes, that is one way, if BRs are easy enough to change. If they are not,
then just change where the reply is sent, and it is compliant.

Also, I consider TLS-SNI type methods to be UNSUITABLE for validating
usual webservers. Anything that the method is suitable for should have
special case support anyway (e.g., I had support in one TLS library, before
I ripped the code out).

> Any approach that relies on overloading an existing TLS field make me
> nervous.  If the field is there for some other purpose, then it seems
> inevitable that you'll run into bugs of more or less the character we've
> hit two times already.

Yeah, as I said, custom extension provodes slightly better guarantees.


-Ilari