On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara <ilariliusva...@welho.com> 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 ;)
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
