Hi, 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.
My main complain about the current specification is that it doesn't clearly state that the specified restriction mechanisms for ticket lifetime and usage only partially bound the forward secrecy loss of PSK; implementations themselves must independently keep track of the lifetime of any given PSK in addition to managing the lifetime of tickets and ticket encryption keys by servers. For instance, if a server keeps re-issuing allow_psk_resumption tickets based on the same PSK it is up to the client to expire the session at some point even if still has valid ticket(s). Similarly, if servers do not store PSK lifetime information inside tickets it may end up using an ancient PSK although the ticket may have been encrypted under a recent ticket key.
Best, Antoine _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
