On Thu, Apr 25, 2019 at 2:27 AM Ilari Liusvaara <[email protected]> wrote:
> On Wed, Apr 24, 2019 at 01:48:24PM -0400, Ryan Sleevi wrote: > > On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara < > [email protected]> > > 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. I’m still struggling to build up a cohesive threat model for your concerns. Perhaps you can try writing one up, for folks who haven’t read this thread - and this might help folks like me who have read this thread. Where I struggle is that the threats seem to continually shift through each message, but perhaps I’m not understanding. For example, a middlebox that blindly echoes TLS extensions means it is terminating TLS, not merely dispatching on it. The security model of TLS-ALPN is, as discussed during that process, fundamentally undermined if the server starts echoing the ALPN - which is why the ALPN draft warns against it. I’m trying to understand what “bad but legitimate” behaviors you see, because I doubt we can, will, or should solve for “bad and violating existing TLS invariant” behaviours. We should be careful to balance how many hypotheticals here, as unless we have a concrete threat model, we’re making protocol authors do unreasonable and undocumented dances. 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). I think that is largely orthogonal to this discussion. There is no need for a certificate - any “technical control” over the IP is sufficient for that purpose. If we’re countenancing servers that don’t do something sensible for SNI-less requests, then that’s already an issue, since CAs also aren’t required to use TLS-ALPN. > 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. I’m still not confident I have a clear understanding of your concerns, and that’s concerning if only because it sounds like you believe there are critical, unaddressed security issues with the draft, and it’s unclear how to move forward or address them. It appears the concerns are shifting in the messages, but it’s entirely likely I’m missing some metapoint you’re making. Do you have suggestions on how to address the issues you see? That might also help make it clearer.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
