On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell <[email protected] > wrote:
> > > On 29/12/16 18:38, Eric Rescorla wrote: > > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < > [email protected] > >> wrote: > > > >> > >> Hiya, > >> > >> On 29/12/16 17:37, Adam Langley wrote: > >>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > >>> specifies that (EC)DH values must be fresh for both parties in TLS > >>> 1.3. > >>> > >>> For clients, this is standard practice (as far as I'm aware) so should > >>> make no difference. For servers, this is not always the case: > >>> > >>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: > >>> ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more > >>> than a day. > >>> ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day. > >> ... > >> > >> As an individual, I'd be in favour of this change but reading > >> over [1], section 5, I wondered if we'd analysed the effects of > >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? > >> The situation being where session ID based caches or session ticket > >> equivalents in tls1.3 are shared over multiple domains. > >> > >> I don't recall this being explicitly considered, but maybe that's > >> just me forgetting. And hopefully the analysis is that such re-use > >> doesn't enable broader replay of early data, but there may be > >> something worth a mention in the tls1.3 spec, e.g. that there may > >> be linkages between the duration for which entries are maintained > >> in resumption and replay detection caches. > >> > > > > This question seems essentially orthogonal to the question of ECDHE key > > reuse > > because even if you use the same ECDHE key in perpetuity you get unique > > traffic keying material for each connection. > > Fair enough, I probably should've started a new thread so have > done that now. > Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI changes: https://tlswg.github.io/tls13-spec/#NewSessionTicket "Any ticket MUST only be resumed with a cipher suite that has the same KDF hash as that used to establish the original connection, and only if the client provides the same SNI value as in the original connection, as described in Section 3 of [RFC6066] <https://tlswg.github.io/tls13-spec/#RFC6066>." We have discussed relaxing that restriction, specifically to allow the following case: - Client connects to server with SNI=A and the server supplies a cert with SNI=A, B - Client reconnects to server and tries to resume with SNI=B See PR: https://github.com/tlswg/tls13-spec/pull/777. However, the general consensus was to leave this out of the base spec, though we might supply an enhancement for that later (and potentially slightly soften the above language to foreshadow such an enhancement). -Ekr > S > > > > > -Ekr > > > > > >> Cheers, > >> S. > >> > >>> > >>> [1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016, > >>> pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480 > >>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh- > in-tls13/ > >>> > >>> > >>> Cheers > >>> > >>> AGL > >>> > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/tls > >> > >> > > > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
