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

[Ryan Sleevi <[e-mail]>]

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?


> 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.

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 ;)