On 01/03/2017 10:38 PM, Martin Thomson wrote: > On 4 January 2017 at 15:29, Ilari Liusvaara <[email protected]> wrote: >>> Naively, if s1 and s2 share cert and private key, and ignore the SNI, it >>> seems like redirecting a full handshake would work. But I didn't think >>> about it very hard. >> Actually, I think it would work if you merely have cross-valid >> selected certs. No need to share private key or even ignore SNI. > That's almost ignoring SNI. You are X but will accept a connection > for Y. It's certainly true that you don't need to share keys, you > share valid credentials and are willing to use them. > > Either way, your point is well made. How servers identify themselves > is bound up in how they expect to be identified, which is often > ambiguous intentionally. > > For example, it's common to have a single deployment configuration > across an entire cluster and to rely on SNI alone for picking a > certificate. That way you simplify management and don't have to look > at IP addresses or anything like that.
It seems like we're violently agreeing with each other, here, and should settle on text to go (or not go) into the security considerations section. In the interest of sparking discussion, I propose the strawman: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% When a server has valid credentials for multiple server names, and at least one of those names could also be served by valid credentials on a different server, it may be possible for an attacker to replay traffic from a client intended for the second server against the first server, including 0-RTT data. This behavior can be avoided if the server knows what server name is expected for a given request (e.g., via an HTTP Host header) and verifies that the supplied SNI extension matches the expected server name, though in some cases the mismatch is harmless. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Though, to be honest, I'm not even 100% convinced that we need to add new text. -Ben
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
