I do think this should be allowed if the client is satisfied with the previous identities presented. We currently allow resumption across domains supported by our wildcard certificate (I believe this is fairly common practice), and our clients take advantage of this to improve their resumption rate. In regards to the referenced paper, I don’t think this is any more dangerous than the wildcard certificate itself as a full handshake would succeed anyway. I don’t think it’s entirely necessary for the server to opt-in to this either, if the server wants it can simply reject the resumption attempt.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Thursday, October 20, 2016 8:34 PM To: tls@ietf.org Subject: [TLS] SNI and Resumption/0-RTT We used to explicitly say that you had to check SNI for 0-RTT (but didn't say anything about resumption). On the principle that 0-RTT and resumption should be the same I removed that, but it turns out that the document doesn't actually have any rule at all other than the one we've inherited from RFC 6066, which clearly says that you can't resume with a different SNI [0]. Following the discussion in https://github.com/tlswg/tls13-spec/issues/720 I've added a statement to the draft clarifying that the RFC 6066 rule still applies [1] With that said, it does seem like there might be situations where it would be useful to allow resumption/0-RTT with different SNIs. My intuition (partly informed by [2]) is that this is something we should be pretty careful about and have the server opt-in explicitly (if at all) but I'm willing to be wrong about that. Comments? -Ekr [0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcmarkup-3Fdoc-3D6066-23section-2D3&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=7lJsgC6sHRMouuFOq6wDh4N72rm4yWm2VW6gd2zCvdQ&s=RMozNpWLpaS7k3E6SrgmGx-BrX-olX_B5oGaNDICn_M&e=> [1] https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121 [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__antoine.delignat-2Dlavaud.fr_doc_www15.pdf&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=7lJsgC6sHRMouuFOq6wDh4N72rm4yWm2VW6gd2zCvdQ&s=HBfcl1svWchDshZqQKO_NCVPq2TcxvaGaDaFdMXSG78&e=>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
