I think that there are four levels of continuity that make sense here : 1. None. Anthony can change. 2. Server name. I.e. SNI stays constant. 3. Public key (and SNI) stays constant. 4. The certificate stays the same.
The use case of short-lived certs is served by 2. 3 might also work. I think that 4 is too restrictive, as we have established. 1 just doesn't seem plausible, since the psk_identity will be cached against a name in almost every case I can imagine. On 26 May 2016 01:47, "Benjamin Kaduk" <bka...@akamai.com> wrote: On 05/24/2016 11:18 PM, Martin Thomson wrote: > On 24 May 2016 at 19:06, Kyle Nekritz <knekr...@fb.com> wrote: >> What is the rationale for restricting a change in certificate? If the server has a new certificate that the client would accept with a full handshake, what threat is added by also accepting that certificate with a PSK handshake? > This was a request from David Benjamin. But then all the things you > mention are why I think that it might have been a bad idea. I think > that the idea was to avoid unnecessary changes. Changes that might > regress the security decisions made originally. It was the most > conservative choice without thinking about the problem too much. > > However, if we model this as new connection + 0-RTT stuff, then I > think that we are good. Probably. If anyone disagrees it would be > good to hear that. > It seems like it's kind of messy either way -- if the cert changes, the client has to check the chain of course, but it also ought to confirm that it's still talking to "the same party" [0] that it was before, so it is not sending data to someplace it didn't expect. A scenario where an attacker can break the 0-RTT crypto and swap in an attacker-controlled certificate is admittedly a bit far-fetched (other things would probably be broken, too), but what about a mis-configured shared host that can accept the 0-RTT for the original site but then mistakenly presents a cert for a different site that is hosted there [and sends the data off to the wrong backend]? If we prevent the cert from changing, then yes there's the added complexity for deploying cert updates. It's not even clear that doing a 0-RTT reject when the server wants to change cert would fix everything, though it might help some. -Ben [0] Somehow I don't think there's a good way to express the "same party" check that works everywhere.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
