Hi, On 06/06/2016 11:53 +0200, Antoine Delignat-lavaud wrote: > Le 2016-06-04 16:51, Eric Rescorla a écrit : >> I wanted to call out to cryptographers/analysts that this formalizes >> the existing practice (going back to RFC 5077) of having multiple >> ticket values tied to the same basic secret (though less so with 1.3 >> because tickets issued on connection N+1 don't have the same RMS as >> those on connection N). If there is a problem with this, that would be >> good to know. > > Looking at the pull request, I don't think it will have much impact on > the protocol analysis given that it doesn't introduce any adversarial > capability that wasn't already present before. If anything, your change > may enable a proof of session unlinkability for well-behaved clients > connecting to honest servers, under a number of restrictions.
I agree with Antoine that I don't expect multiple ticket values for the same cryptographic key to have a (negative) impact on the/our security results. As the ticket value is, through ClientHello, part of the handshake hash, hence flowing into the key derviation, separate ticket values should "domain-separate" the keys established from the same RMS. And yes, might be one can establish some form of cryptographic session/handshake unlinkability for honest client-server communication. Cheers, Felix
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
