On 29/12/16 18:38, Eric Rescorla wrote: > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie >> 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. 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls