Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ilari Liusvaara <[e-mail]>]

On Wed, Apr 24, 2019 at 01:48:24PM -0400, Ryan Sleevi wrote:
> On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > > If that's roughly correct, would you agree a possible mitigation
> > > (notwithstanding complexity concerns) 'could' be the use of a client
> > hello
> > > extension, echo'd by the server (thus confirming it understands the
> > > protocol, and is not merely 'dumb' parsing but an active participant in
> > the
> > > TLS handshake), that indicates the IP being verified?
> >
> > The server must already acknowledge the IP address being verified.
> >
> 
> I'm not sure how this conclusion is reached. Could you help me understand
> more?

The validation certificate contains the IP address being verified
in the SAN extension.

> > And that mitigation does not work. If the NAT does not know about
> > TLS-ALPN, it will not know about whatever extension that would be,
> > and thus just copy it through straight to attacker, who can then
> > freely reply.
> 
> 
> I'm not sure why you say this. Your original threat model was that the TLS
> SNI NAT box does something 'sensible' in the absence of SNI - and that the
> attacker would not be able to terminate the handshake if SNI were absent.
> If the proposal were to omit the SNI, while still making sure it's bound to
> the request (via a separate extension), then as long as the TLS SNI NAT box
> does the sensible thing for an SNI-less request, there's no additional
> privilege.

What are the consequences if the server just takes that address without
checking (echoing the extension, with whatever is in it)?

TLS-ALPN with domain names is pretty robust security-wise against
servers and middleboxes doing wrong (but sensible) things.

And in CABForum BRs, fradulent IP address certificate is quite bad, as
it allows (at least in rules) getting fradulent DNS certificates for
any domain pointing to that name (due to existence of method 8).

> If the issue is that the TLS SNI NAT box is *only* secure in the context of
> DNS - and maybe it does something sensible absent an SNI, and maybe it's
> terrible and fundamentally insecure absent an SNI - then what we're saying
> is middleboxes are evil and fundamentally insecure ;)

The reason for distinction between DNS and IP here is because of the
difference in how TLS-ALPN works with DNS and IP versus how clients
works with DNS and IP.

Consider TLS-SNI. That difference in behavior renders it insecure
w.r.t. such middleboxes for both DNS and IP. Yet I do not think anybody
would blame the middleboxes for this issue, they blame TLS-SNI instead.



-Ilari