Re: [TLS] Security review of TLS1.3 0-RTT

> On 5 Jun 2017, at 6:06, Bill Cox wrote: > > On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk > wrote: > > Do we have a good example of why a non-safe HTTP request in 0-RTT would lose > specific properties required for

Re: [TLS] Security review of TLS1.3 0-RTT

On 06/01/2017 03:50 PM, Victor Vasiliev wrote: > > To clarify, I am not suggesting that two streams would help. > I completely > agree with you that two streams is not going to mitigate the > DKG attack or > others. What I meant is that 0-RTT inherently

Re: [TLS] Security review of TLS1.3 0-RTT

On 06/02/2017 04:49 PM, Victor Vasiliev wrote: > > 4. If implemented properly, both a single-use ticket and a >strike-register style mechanism make it possible to limit >the number of 0-RTT copies which are processed to 1 within >a given zone (where a zone is defined as

Re: [TLS] Security review of TLS1.3 0-RTT

On 06/04/2017 02:08 PM, Bill Cox wrote: > My feeling is that when talking to stateless 0-RTT servers, browsers > should send only idempotent HTTP requests, and accept > less-than-perfect FS. I also feel they should avoid attempts at > client auth over 0-RTT. However, when talking to servers that

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, Jun 2, 2017 at 2:25 PM, Eric Rescorla wrote: > > Sure. For the sake of clarify, I'm going to suggest we call: > > - replay == the attacker re-sends the data with no interaction > with the client > - retransmission == the client re-sends (possibly with some

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, Jun 2, 2017 at 2:39 PM, Victor Vasiliev wrote: > > Now, imagine the following attack: > > a) Between (1) and (2), the attacker resets the TCP connection, after > the client got the response and the session ticket. > b) Since the client has the ticket, it

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, Jun 02, 2017 at 05:49:51PM -0400, Victor Vasiliev wrote: > On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla wrote: > > > I've just gone through this thread and I'm having a very hard time > > understanding what the actual substantive argument is about. > > > > I believe at

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla wrote: > I've just gone through this thread and I'm having a very hard time > understanding what the actual substantive argument is about. > I believe at this point we mostly disagree on what specific scenarios are and are not a

Re: [TLS] Security review of TLS1.3 0-RTT

It's still there, in 4.6.1. "The sole extension currently defined for NewSessionTicket is “early_data”, indicating that the ticket may be used to send 0-RTT data (Section 4.2.9 )). It contains the following value:" -Ekr On Fri, Jun 2,

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, Jun 01, 2017 at 11:20:56PM -0700, Colm MacCárthaigh wrote: > > Maybe a lot of this dilemma could be avoided if the the PSKs that can be > used for regular resumption and for 0-RTT encryption were separate, with > the latter being scoped smaller and with use-at-most-once semantics. The

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla wrote: > I've just gone through this thread and I'm having a very hard time > understanding what the actual substantive argument is about. > > Let me lay out what I think we all agree on. > This is a good summary, I just have a few

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev wrote: > I am not sure I agree with this distinction. I can accept the difference > in > terms of how much attacker can retry -- but we've already agreed that > bounding > that number is a good idea. I don't see any meaningful

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 31, 2017 at 03:49:03PM -0400, Victor Vasiliev wrote: > On Tue, May 30, 2017 at 9:56 PM, Colm MacCárthaigh > wrote: > > > Here you argue, essentially, that it is too inconvenient to mitigate those > > attacks for users. I don't think we can seriously take that

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev wrote: > I think I am not getting my key point across here clearly. I am not > arguing > that they are inconvenient, I am arguing that the guarantee you are trying > to > provide is impossible. > > I wholeheartedly agree that

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 30, 2017 at 05:38:02PM -0400, Victor Vasiliev wrote: A couple points: - Various mechanisms related to conserving IPv4 addresses can result client and server disagreeing about server IP address. Or even the address family. - If one has limited number of replays, distributing

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 30, 2017 at 2:38 PM, Victor Vasiliev wrote: > Thank you for your analysis! I appreciate the attention to the security > properties of the 0-RTT requests, as it is the more delicate part of the > protocol. It took me a while to get through the entire review, and

Re: [TLS] Security review of TLS1.3 0-RTT

On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote: > TLS isn’t a magical “transport security solution”, it provides a very specific > set of explicit security guarantees to the applications that use it. It can > be > used as a building block for the secure systems, but at the end of the

Re: [TLS] Security review of TLS1.3 0-RTT

On 05/24/2017 10:32 AM, Colm MacCárthaigh wrote: > > > Another crazy idea would be to just say that servers MUST limit > the use > > of a single binder to at most 100 times, with the usual case > being just > > once, to allow for alternative designs that have weaker distributed

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 24, 2017 at 7:30 AM, Ilari Liusvaara wrote: > > > Right, this would bring replays down from the millions hypothesized for > > the weak time-based thing to more like tens, which is kind of in the > > regime that we are currently in with (at least some)

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 24, 2017 at 08:50:07AM -0500, Benjamin Kaduk wrote: > On 05/21/2017 05:47 PM, Eric Rescorla wrote: > > > > > > On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara > > > wrote: > > > > On Fri, May 19, 2017 at 09:59:57AM -0700,

Re: [TLS] Security review of TLS1.3 0-RTT

On 05/21/2017 05:47 PM, Eric Rescorla wrote: > > > On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara > > wrote: > > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > > > - Clients MUST NOT use the same

Re: [TLS] Security review of TLS1.3 0-RTT

On 05/20/2017 04:33 AM, Ilari Liusvaara wrote: > > I meant what prevents the (say 10 second) windows from stacking up into > (say 20 second windows) if 0-RTT is used on multiple hops (client- > middlebox and middlebox-server)? > > One can not assume that the client has knowledge of any middlebox

Re: [TLS] Security review of TLS1.3 0-RTT

> Well it's a little more subtle then that; folks seem to acknowledge the > attacks > but feel that their use-cases won't be affected. I'm looking at you, Chrome, > boring, Firefox :) I've heard from two people that the "looking at you" phrase was not well-received. I apologize to the list,

Re: [TLS] Security review of TLS1.3 0-RTT

>I've seen a number of arguments here that essentially boil down to "We'd like >to keep it anyway, because it is so operationally convenient". Is that really >how this process works? Don't demonstrable real-world attacks deserve >deference? Well it's a little more subtle then that; folks seem

Re: [TLS] Security review of TLS1.3 0-RTT

On 05/23/2017 01:07 PM, Colm MacCárthaigh wrote: > > I've seen a number of arguments here that essentially boil down to > "We'd like to keep it anyway, because it is so operationally > convenient". Is that really how this process works? Don't demonstrable > real-world attacks deserve deference?

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 23, 2017 at 11:27 AM, Viktor Dukhovni wrote: > Actually, nonces in DNScurve protect clients from replayed server > responses (clients > are stateful). I see no explicit guidance to detect or refuse replays of > client > queries in DNScurve. While servers

Re: [TLS] Security review of TLS1.3 0-RTT

> On May 23, 2017, at 2:07 PM, Colm MacCárthaigh wrote: > > That's not good for users, and seems like another very strong reason to make > it clear in the TLS draft that that it is not secure. FWIW; DNSCurve includes > nonces to avoid attacks like this:

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 23, 2017 at 10:50 AM, Viktor Dukhovni wrote: > The fix is to amend DNSpriv to require stateless (random rather > than say round-robit) RRset rotation. With random rotation, the > next RRset order is independent of previous queries. > That's a good fix for

Re: [TLS] Security review of TLS1.3 0-RTT

> On May 23, 2017, at 12:52 PM, Christian Huitema wrote: > > Colm's point is that for many DNS servers, queries are not truly stateless. > The answer to a query for records for example.net might vary over time, > or even query to query, for example to manage load

Re: [TLS] Security review of TLS1.3 0-RTT

On 5/22/2017 7:53 PM, Colm MacCárthaigh wrote: > > > On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk > wrote: > > > Sorry for being daft, but a direct link to this additional > side-channel would be helpful. > > > I should have done it the

Re: [TLS] Security review of TLS1.3 0-RTT

On 05/22/2017 12:56 PM, Colm MacCárthaigh wrote: > > > On Mon, May 22, 2017 at 10:46 AM, Christian Huitema > > wrote > > Check DKG's analysis of 0-RTT for DNS over TLS: >

Re: [TLS] Security review of TLS1.3 0-RTT

On Mon, May 22, 2017 at 10:46 AM, Christian Huitema wrote > > Check DKG's analysis of 0-RTT for DNS over TLS: https://www.ietf.org/mail- > archive/web/dns-privacy/current/msg01276.html. There is only one point of > concern, a minor privacy leak if the DNS queries in the 0-RTT

Re: [TLS] Security review of TLS1.3 0-RTT

On 5/22/2017 10:24 AM, Colm MacCárthaigh wrote: > > > On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz > wrote: > ... > > Which mechanisms to use, and whether to enable 0-RTT in the first > place (or PSK mode at all), should be decided considering

Re: [TLS] Security review of TLS1.3 0-RTT

On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz wrote: > The stateless technique certainly doesn’t solve all issues with replay. > Neither do the other techniques, unless a fairly unrealistic (imo, in most > use cases) retry strategy is used. > The stateless technique is

Re: [TLS] Security review of TLS1.3 0-RTT

g Subject: Re: [TLS] Security review of TLS1.3 0-RTT On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: - Clients MUST NOT use the same ticket multiple times for 0-RTT. I don't understand the purpose of this requirement. As you note below, s

Re: [TLS] Security review of TLS1.3 0-RTT

On 5/21/2017 7:28 PM, Colm MacCárthaigh wrote: > > > On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla > wrote: > > > > ... > > I'm happy to write this up as part of the first two techniques. > I'd be > interested in hearing from others in the

Re: [TLS] Security review of TLS1.3 0-RTT

On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla wrote: > > - Clients MUST NOT use the same ticket multiple times for 0-RTT. >> > > I don't understand the purpose of this requirement. As you note below, > servers are ultimately responsible for enforcing it, and it's not clear to > me

Re: [TLS] Security review of TLS1.3 0-RTT

On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara wrote: > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > > > > > Some protection is necessary; but it isn't too hard - a single-use > session > > cache, or a strike register, do protect against the

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > > Some protection is necessary; but it isn't too hard - a single-use session > cache, or a strike register, do protect against the side-channel and DOS > problems. Combined with a "fail closed" strategy and tickets that are >

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 01:10:29PM -0700, Colm MacCárthaigh wrote: > On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara > wrote: > > > > * In order to fully reason about when that message may later get > > received, > > > there needs to be an agreed upon time-cap for

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 4:49 PM, David Benjamin wrote: > Seeing as this utterly ridiculous ticket_age_add thing is partially my > fault, I suppose I should respond: > > On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh > wrote: > >> > And then separate

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 1:58 PM, Viktor Dukhovni wrote: > > +1. The additive obfuscation leaks nothing that is not already leaked > just by sending the tickets. > You're both right, that does work out. I was thinking my balanced equations stupidly and solving for x while

Re: [TLS] Security review of TLS1.3 0-RTT

> On May 19, 2017, at 4:49 PM, David Benjamin wrote: > > Could you expand on your cryptanalysis? I don't believe this is actually > leaked. It's addition mod 2^32, not XOR, which means you effectively > randomize the parent starting time. (It was initially XOR, and then

Re: [TLS] Security review of TLS1.3 0-RTT

Seeing as this utterly ridiculous ticket_age_add thing is partially my fault, I suppose I should respond: On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh wrote: > > And then separate to all of the above, and lower priority: >> > >> > * There's a contradiction between the

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla wrote: > Yup. There are no known reasons that prevent at-most-once 0-RTT delivery, > >> even with distributed servers for the origin. >> > > I don't disagree with that necessarily, but if the client responds by > retransmitting > in

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara wrote: > > * In order to fully reason about when that message may later get > received, > > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by > all > > potential middle-boxes in the pipe that may be

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 2:40 PM, Ilari Liusvaara wrote: > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > > On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > > - Even if once-per-server or

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara wrote: > > To me, that reads as gross understatement about the dangers involved in > 0-RTT: > > - The side channel attacks with millions or billions of replays are hard > to protect against. This is if the side channels

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 16, 2017 at 05:39:55PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla wrote: > > > As promised: > > https://github.com/tlswg/tls13-spec/pull/1005 > > > > Note: I may have to do a little post-landing cleanup, but I wanted to get > > people's

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla wrote: > As promised: > https://github.com/tlswg/tls13-spec/pull/1005 > > Note: I may have to do a little post-landing cleanup, but I wanted to get > people's senses of the text ASAP. > Thanks for everyone's comments. I've updated the

Re: [TLS] Security review of TLS1.3 0-RTT

> On May 6, 2017, at 8:51 PM, Eric Rescorla wrote: > > Yes, they can. But doing so leaks a unique identifier, which can be used > to link sessions. When I look at the privacy implications as well as the > replay attacks, there is real value in using a resume ticket only once. >

Re: [TLS] Security review of TLS1.3 0-RTT

On Sat, May 6, 2017 at 5:35 PM, Christian Huitema wrote: > > > On 5/4/2017 10:12 PM, Eric Rescorla wrote: > > > > Obligatory note that if clients are forbidden from reusing a single > > PSK for multiple 0-RTT, they can still use it for 1-RTT. > > Yes, they can. But doing so

Re: [TLS] Security review of TLS1.3 0-RTT

On 5/4/2017 10:12 PM, Eric Rescorla wrote: > > Obligatory note that if clients are forbidden from reusing a single > PSK for multiple 0-RTT, they can still use it for 1-RTT. Yes, they can. But doing so leaks a unique identifier, which can be used to link sessions. When I look at the privacy

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 05, 2017 at 12:07:09AM -0500, Benjamin Kaduk wrote: > On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > P.S. Care to name (another :) one security-related protocol that > > doesn't provide replay protection? > > Some of the earlier uses of Kerberos are subject to

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 04, 2017 at 10:12:34PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk wrote: > > > > > That seems like an inconsistent position to take (don't do this, but if > > you ignore me, do this in this fashion). Advising application profiles

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk wrote: > Trying to consolidate various things into a single mail... > > On 05/04/2017 04:37 PM, Eric Rescorla wrote: > > In the PR I just posted, I spent most of my time describing the > mechanisms and used a SHOULD-level

Re: [TLS] Security review of TLS1.3 0-RTT

Trying to consolidate various things into a single mail... On 05/04/2017 04:37 PM, Eric Rescorla wrote: > In the PR I just posted, I spent most of my time describing the > mechanisms and used a SHOULD-level requirement to do one of the > mechanisms. > I think there's a bunch of room to wordsmith

Re: [TLS] Security review of TLS1.3 0-RTT

Sure, those are fine weasel words. But do we really want to allow into this protocol something that can be misused with security implications in a protocol that’s attempting to solve a security problem? I really don’t know. I’m inclined to say, ‘no’ though. For all those same reasons that

Re: [TLS] Security review of TLS1.3 0-RTT

tions/ ). From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Thursday, May 4, 2017 5:37 PM To: Kyle Nekritz <knekr...@fb.com> Cc: Colm MacCárthaigh <c...@allcosts.net>; tls@ietf.org Subject: Re: [TLS] Security review of TLS1.3 0-RTT On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <k

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 3:00 PM, Erik Nygren wrote: > On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla wrote: > >> >> >> >> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: >> >>> > 1. A SHOULD-level requirement for server-side 0-RTT

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla wrote: > > > > On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: > >> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >> both session-cache and strike register styles and the merits of

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 04, 2017 at 02:37:20PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: > > [...] > > I think this is basically right. In the PR I just posted, I spent most of > my time describing the > mechanisms and used a SHOULD-level requirement

Re: [TLS] Security review of TLS1.3 0-RTT

D be used, and servers MUST ignore the value." https://tlswg.github.io/tls13-spec/#pre-shared-key-extension -Ekr > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, May 3, 2017 11:13 PM > *To:* Colm MacCárthaigh <c...@allcosts.net> >

Re: [TLS] Security review of TLS1.3 0-RTT

case of a device without a real time clock, or with an external PSK). From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Wednesday, May 3, 2017 11:13 PM To: Colm MacCárthaigh <c...@allcosts.net> Cc: tls@ietf.org Subject: Re: [TLS] Security review of TLS1.3 0-RTT [Del

Re: [TLS] Security review of TLS1.3 0-RTT

As promised: https://github.com/tlswg/tls13-spec/pull/1005 Note: I may have to do a little post-landing cleanup, but I wanted to get people's senses of the text ASAP. Comments welcome. -Ekr On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla wrote: > > > On Wed, May 3, 2017 at 8:20

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 04, 2017 at 01:21:43PM -0700, Colm MacCárthaigh wrote: > On Thu, May 4, 2017 at 12:39 PM, Nico Williams > wrote: > > The SHOULD should say that the server-side needs to apply a replay cache > > OR fallback onto a full exchange when the 0-rtt data payload

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 12:12 PM, Erik Nygren wrote: > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > >> >> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >> both session-cache and strike register styles and the merits of

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 12:39 PM, Nico Williams wrote: > The SHOULD should say that the server-side needs to apply a replay cache > OR fallback onto a full exchange when the 0-rtt data payload involves a > non-idempotent operation. > I don't mean to be dismissive with this

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 04, 2017 at 02:49:20PM -0500, Nico Williams wrote: > On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote: > > On 05/04/2017 02:39 PM, Nico Williams wrote: > > > The SHOULD should say that the server-side needs to apply a replay cache > > > OR fallback onto a full exchange

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 04, 2017 at 11:01:02PM +0300, Ilari Liusvaara wrote: > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: > > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > > > both

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote: > On 05/04/2017 02:39 PM, Nico Williams wrote: > > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: > >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > >>> 1. A SHOULD-level requirement for

Re: [TLS] Security review of TLS1.3 0-RTT

On 05/04/2017 02:39 PM, Nico Williams wrote: > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: >>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >>> both session-cache and strike

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > > both session-cache and strike register styles and the merits of each. The SHOULD

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > both session-cache and strike register styles and the merits of each. > I don't believe this is technically viable for the large-scale server

Re: [TLS] Security review of TLS1.3 0-RTT

;ilariliusva...@welho.com>; tls@ietf.org Subject: Re: [TLS] Security review of TLS1.3 0-RTT On Thu, May 4, 2017 at 11:29 AM, Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote: * Providers already work hard to maximize user affinity to a data ce

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov wrote: > >- Providers already work hard to maximize user affinity to a data >center for other operational reasons; re-routing is relatively rare and >quickly repaired by issuing a new ticket. > > Understood,

Re: [TLS] Security review of TLS1.3 0-RTT

* Providers already work hard to maximize user affinity to a data center for other operational reasons; re-routing is relatively rare and quickly repaired by issuing a new ticket. Understood, but isn’t an attacker going to be able to re-route at will?

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 11:22 AM, Andrei Popov wrote: > >- I don't think we'll have a problem implementing a single use cache, >strike register, we have similar systems for other services, at higher >volumes. > > … and these things work across

Re: [TLS] Security review of TLS1.3 0-RTT

* I don't think we'll have a problem implementing a single use cache, strike register, we have similar systems for other services, at higher volumes. … and these things work across geographically distributed datacenters, without negating the latency benefits of 0-RTT? Cheers, Andrei

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 10:07 AM, Andrei Popov wrote: > IMHO what we have is a facility in TLS 1.3 that: > 1. Requires extraordinary effort on the server side to mitigate replay > (for all but the smallest deployments); > 2. Offers no way for the client to determine

Re: [TLS] Security review of TLS1.3 0-RTT

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara Sent: Thursday, May 4, 2017 2:35 AM To: Colm MacCárthaigh <c...@allcosts.net> Cc: tls@ietf.org Subject: Re: [TLS] Security review of TLS1.3 0-RTT On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCár

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote: > On Sunday at the TLS:DIV workshop I presented a summary of findings of a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. > Thanks to feedback in the room I've now tightened up the findings from the >

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 8:20 PM, Colm MacCárthaigh wrote: > > > On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla wrote: > >> I made some proposals yesterday >> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). >> >> Specifically: >> 1. A

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla wrote: > I made some proposals yesterday > (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). > > Specifically: > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > both session-cache and strike

Re: [TLS] Security review of TLS1.3 0-RTT

Nico Williams writes: >Yeah, but a non-persistent clock is fine if the client can learn time from >the server (and keep a different offset from system time to every server if >need be, learning system time from one of them, or from NTP, or whatever). In many cases neither

Re: [TLS] Security review of TLS1.3 0-RTT

[Deliberately responding to the OP rather than to anyone in particular] Hi folks, I'm seeing a lot of back and forth about general philosophy and the wisdom of 0-RTT but I think it would be useful if we focused on what changes, if any, we need to make to the draft. I made some proposals

Re: [TLS] Security review of TLS1.3 0-RTT

Chose not to provide replay protection?! I have to agree with Colm - it doesn't sound good. Care to justify? P.S. Care to name (another :) one security-related protocol that doesn't provide replay protection? Regards, Uri Sent from my iPhone > On May 3, 2017, at 21:42, Colm MacCárthaigh

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 6:59 PM, Viktor Dukhovni wrote: > > > On May 3, 2017, at 9:39 PM, Colm MacCárthaigh wrote: > > > > As it happens, DNS queries are not idempotent. Queries have > side-effects, > > This is sufficiently misleading to be false.

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 6:19 PM, Viktor Dukhovni wrote: > One obvious use case for 0-RTT is DNS queries. The query protocol is > idempotent, and latency matters. So for DNS over TLS, 0-RTT would be > a good fit. TLS session caches are not attractive on the DNS server >

Re: [TLS] Security review of TLS1.3 0-RTT

> Let's get the fallacy out of the way. TLS 1.3 provides protection against > replay > attacks, just not if you decide to use 0-RTT. > > I realize that there is a real risk that this distinction will be lost on > some, but I > can fairly confidently say that it isn't lost on those who are

Re: [TLS] Security review of TLS1.3 0-RTT

> On May 3, 2017, at 9:15 PM, Martin Thomson wrote: > > Let's get the fallacy out of the way. TLS 1.3 provides protection > against replay attacks, just not if you decide to use 0-RTT. Amen. > I realize that there is a real risk that this distinction will be lost >

Re: [TLS] Security review of TLS1.3 0-RTT

On 4 May 2017 at 11:11, Watson Ladd wrote: > Historically TLS protected against replay attacks. Now it doesn't. An > application that relies on this property which TLS used to guarantee > is now broken. Clearly we could have provided it, we just chose not > to. Let's get

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 3:56 PM, Martin Thomson wrote: > On 3 May 2017 at 22:45, Colm MacCárthaigh wrote: >> This is easy to say; the TLS layer is the right place. It is not practical >> for applications to defend themselves, especially from timing

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 5:51 PM, Viktor Dukhovni wrote: > > > On May 3, 2017, at 6:29 PM, Colm MacCárthaigh wrote: > > > > Pervasive forward secrecy is one of the central security goals of modern > > cryptography, > > Sure, given a sensible definition of

Re: [TLS] Security review of TLS1.3 0-RTT

> On May 3, 2017, at 6:29 PM, Colm MacCárthaigh wrote: > > Pervasive forward secrecy is one of the central security goals of modern > cryptography, Sure, given a sensible definition of forward-secrecy. And near instanenous deletion of session keys is not part of such a

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 5:25 PM, Martin Thomson wrote: > I was responding to an overly broad statement you made. In the > discussion you also talk about timing side-channels and other ways in > which information can leak. Nothing we do at the TLS layer will > prevent

Re: [TLS] Security review of TLS1.3 0-RTT

On 4 May 2017 at 09:16, Colm MacCárthaigh wrote: >> We've historically done a lot to >> secure applications at a single point, and we're almost at the end of >> what we can reasonably do for them at this layer. We need to think >> more hollistically and acknowledge that

Re: [TLS] Security review of TLS1.3 0-RTT

> On May 3, 2017, at 6:29 PM, Colm MacCárthaigh wrote: > > Just an aside related to that; it can be useful to fuzz ticket lifetimes a > bit so all of the tickets from a STEK don't expire at exactly the same time. > That can lead to a lot of painful renegotiations happening at

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 3:56 PM, Martin Thomson wrote: > On 3 May 2017 at 22:45, Colm MacCárthaigh wrote: > > This is easy to say; the TLS layer is the right place. It is not > practical > > for applications to defend themselves, especially from

Re: [TLS] Security review of TLS1.3 0-RTT

On 3 May 2017 at 22:45, Colm MacCárthaigh wrote: > This is easy to say; the TLS layer is the right place. It is not practical > for applications to defend themselves, especially from timing attacks. If you care about these attacks as much as it appears, then you can't

  1   2   >