On Thu, Dec 29, 2016 at 1:50 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > > 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. > FWIW, we've been working on separating session caches at a finer-than-domain-name level in Firefox, in support of allowing users to set tracking boundaries. https://bugzilla.mozilla.org/show_bug.cgi?id=1316283 https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/ https://www.torproject.org/projects/torbrowser/design/#identifier-linkability --Richard >> > >> 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 > >> > >> > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
