On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <[email protected]> wrote:
> > Hiya, > > On 29/12/16 19:08, Eric Rescorla wrote: > > 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 > > What I'm wondering is if we're maybe missing a server-side check > on that, with the possible attempted attack of a 0rtt replay in > mind. E.g. a MUST check for the server that SNI is the same as for > initial h/s before processing early data, (as is done for ALPN now) > and/or some guidance about what might not be an obvious relationship > between any 0rtt replay detection mechanisms and session ticket > equivalents I believe that the text I quote below already requires that check. The reason it's there and not in the 0-RTT text is that it is a requirement on resumption which itself is a requirement for 0-RTT. The ALPN check is an explicit 0-RTT requirement but not a resumption requirement. I.e., Can resume only if SNI is equal Can accept 0-RTT only if (resumed && ALPN is equal) -Ekr > "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. > > I'd wonder if that optimisation is really worthwhile, esp if it > opens the door wider to 0rtt replay. (And it seems like it'd be > somewhat complex to take advantage of the optimisation anyway.) > > > > > However, the general consensus was to leave this out of the base spec, > > Seems right. > > Cheers, > S. > > > 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
