On 30/12/16 16:14, Eric Rescorla wrote: > On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> Hiya, >> >> On 29/12/16 19:08, Eric Rescorla wrote: >>> On Thu, Dec 29, 2016 at 10:50 AM, 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. >>>>>> >>>>>> 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)
Fair enough. I didn't read enough text to get that clearly I guess, which is my fault:-) Thanks, S. > > -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 >>>>>> 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
