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

y 19, 2018 11:34 AM > To: Ilari Liusvaara <ilariliusva...@welho.com>; Tim Hollebeek > <tim.holleb...@digicert.com> > Cc: IETF ACME <acme@ietf.org> > Subject: Re: [Acme] Fixing the TLS-SNI challenge type > > ➢ challenge: Random string of at least 128 bits of entropy. >

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

➢ challenge: Random string of at least 128 bits of entropy. What does that mean? How can you measure if you’ve got 125 or 67 or 2 bits of entropy? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

On Fri, Jan 19, 2018 at 05:24:01PM +, Tim Hollebeek wrote: > > > > 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

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

> Basically, for security, one needs to put the domain to be validated to the SNI > field. Not doing that was the reason for the TLS-SNI-01/02 vulernability. I agree. Not only for security, but for compliance, both with the Baseline Requirements [1] and the intended use of SNI. Abusing SNI as

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

On Fri, Jan 19, 2018 at 4:38 PM, Ilari Liusvaara wrote: > On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote: > > > > > > I agree this approach will limit compatible TLS servers but luckily > > > HAProxy should be fully compatible. > > > > > > Alas, there's

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

On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote: > > > > I agree this approach will limit compatible TLS servers but luckily > > HAProxy should be fully compatible. > > > Alas, there's nothing like hitting send on a message to a mailing list to > make you think a little bit

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

> > I agree this approach will limit compatible TLS servers but luckily > HAProxy should be fully compatible. Alas, there's nothing like hitting send on a message to a mailing list to make you think a little bit harder. I overlooked the fact that it doesn't seem possible to select the

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

> > If we use the "real" identifier for SNI, we'd limit that option to web > servers that natively support the ALPN value for ACME and can route based > on it. > Not sure how common this kind of setup is, if it's just a small subset of > HAProxy deployments it'd probably not have much of an

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

On Thu, Jan 11, 2018 at 04:49:45PM -0800, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. > Given that blindly responding to an unknown ALPN value would be an > RFC violation this seems safe (although, hey, who knows what servers/ > cloud

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

So the original source of the TLS-SNI-01 in-the-field vulnerability that caused Let’s Encrypt to disable TLS-SNI-01 has just openly published details of the exploit he demonstrated:

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

Breaking that on purpose is actually why I most believe that the SNI should be required to reflect the exact SNI of the domain label being validated. The threat model I was concerned about evaporates if the SNI is the actual domain label and the decisioning of which TLS certificate to present

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

On 12.01.18 04:06, Roland Bracewell Shoemaker wrote: > I'm actually going to roll back my thoughts on the SNI value. Thinking > about this more I think it does actually make sense to revert to using > the actual host name here. > > In the initial design of the TLS-SNI challenge the

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

> On Jan 11, 2018, at 22:46, Matthew D. Hardeman wrote: > > Hi, guys, > > I’m entirely new to this list and not sure whether or not I’m welcome, but I > have some comments on the ALPN idea. > > In order to actually be an improvement in security, the ALPN needs to be

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

On Thu, Jan 11, 2018 at 09:46:28PM -0600, Matthew D. Hardeman wrote: > > In order to actually be an improvement in security, the ALPN needs > to be more than a mere marker of support. > > Consider: The new mechanism is implemented and Let’s Encrypt > deploys. > > Rather than do the work to

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

I strongly support the ideas that Martin Thompson is presenting on this matter. While this is a major change, it provides an opportunity build a mechanism to achieve the actual security goal: to ensure that the TLS endpoint that you’re speaking to when you follow all the routing steps a real

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

Hi, guys, I’m entirely new to this list and not sure whether or not I’m welcome, but I have some comments on the ALPN idea. In order to actually be an improvement in security, the ALPN needs to be more than a mere marker of support. Consider: The new mechanism is implemented and Let’s

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

The confidentiality point was a minor one, certainly, but it would represent an improvement. TLS-SNI is a protocol already, but it's more complicated than it needs to be. Certificate generation is a pretty big lift compared to the other challenges. On Fri, Jan 12, 2018 at 2:29 PM, Jonathan

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

> On Jan 11, 2018, at 22:26, Martin Thomson wrote: > > If you are using a new protocol, all of the concerns Peter have come > into play. If you are there, why wouldn't you do the challenge > validation within the new protocol rather than using the certificate > (which

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

If you are using a new protocol, all of the concerns Peter have come into play. If you are there, why wouldn't you do the challenge validation within the new protocol rather than using the certificate (which is sent in the clear in current TLS versions). That might be easier to implement than

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

On Thu, Jan 11, 2018 at 04:49:45PM -0800, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this seems safe (although, hey, who knows what servers/cloud

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

I'm actually going to roll back my thoughts on the SNI value. Thinking about this more I think it does actually make sense to revert to using the actual host name here. In the initial design of the TLS-SNI challenge the XXX.acme.invalid value was used as a way to allow servers to dynamically

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

> On Jan 11, 2018, at 19:49, Roland Bracewell Shoemaker > wrote: > > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this seems safe (although, hey, who knows what

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

This seems like a silver bullet for the problems we’ve been seeing. Given that blindly responding to an unknown ALPN value would be an RFC violation this seems safe (although, hey, who knows what servers/cloud providers actually do). Definitely interested in the results of the scan. There could

[Acme] Fixing the TLS-SNI challenge type

As many of you are probably aware, Frans Rosén of Detectify discovered a method of exploiting many shared hosting providers to obtain unauthorized certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt is in the process of removing support for these challenge types[1].