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 security? If so, that seems like a good > thing

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 has

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 slight >

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 0-RTTs the POST to take o

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 this point we mos

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 concern that should b

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

> > On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla wrote: > > > 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause > >connection failures) then a DKG-style attack where the client > >replays the 0-RTT data in 1-RTT is possible. > > > > This isn't what I call a replay. It's a seco

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, 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 pro

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 clarifications ...

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

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. 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause connection failures) then a DKG-style attack where the clie

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 distinction in > oth

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 approach. > > > > If the

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 if it is possible to

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 thos

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 there > are > many th

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) application > behavior. > > Actual

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 > > mailto:ilariliusva...@welho.com>> wrote: > > > > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > >

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 > mailto:ilariliusva...@welho.com>> wrote: > > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > > > - Clients MUST NOT use the same ticket multiple times for 0-RTT.

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 on

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, an

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 t

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? Th

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 could keep a nonce cache, in

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: https://dnscurve.org/replays.html (which

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 that specific local problem

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 balancing. Adversaries ca

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 first time. Here it >

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

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 first time. Here it is: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html -- Colm __

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 > mailto:huit...@huitema.net>> wrote > > Check DKG's analysis of 0-RTT for DNS over TLS: > https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html > >

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 data can be > replaye

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 the > tradeoff

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 insecure; plain and simp

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

TLS] Security review of TLS1.3 0-RTT On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla 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, servers are ultimately responsible fo

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 WG what they thi

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 why clients obe

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 side-channel and DOS > > prob

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 > sc

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 0-RTT receipt. Agreed by > > a

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 to all of the above, and lower priority: >>

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 forgetting that t1' is s

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 shortly > changed to a

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 obfuscated ticket age

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 1-RTT, then you

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 using 0-RTT. > > Isn't that

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 once-per-cluster replay detection lim

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

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 > wrote: > > > > - Even if once-per-server or once-per-cluster replay detection limits > > the number of replays to few hundred to few thoursand at maximum, > > where the low-l

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 are in TLS library. > If

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 senses of the t

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 text to address

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. > > Agreed. Also,

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 leaks a unique identif

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 impl

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 replay

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 to > > consider one

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 requirement to do one of th

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 t

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

On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: > > There are definitely cases (i.e. application profiles) where this should > be done. I think a general case HTTPS server is one. But I don’t think this > is strictly necessary across the board (for every application using 0-RTT > at all). DNS

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 IP

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

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

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 defense, >>> explaining both session-cache and strike register

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 each. >> >> >> >> First, a point of c

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 to do one of the m

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

_age of 0 SHOULD 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 > *Cc:* tls@

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

the 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 Cc: tls@ietf.org Subject: Re: [TLS] Security review of TLS1.3 0-RTT [Deliberately responding to

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 PM, Colm MacCárt

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 involves a > > non-idempotent o

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 each. >> > > I don't believe this is tech

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 but TLS stands for "Tra

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 whe

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 session-cache and strik

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. > > > Many of the discu

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 server-side 0-RTT defen

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 register styles and the

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 should say that the

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 operators most interes

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

ity review of TLS1.3 0-RTT On Thu, May 4, 2017 at 11:29 AM, Andrei Popov mailto:andrei.po...@microsoft.com>> 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 n

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, but isn’t an attacker going to

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 geographically distributed datacenters, >

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 whether the server is > mitigat

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 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árthaigh wrote: > On Sunday

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 SHOULD-level requirement for server-side 0-RT

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 register styles a

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 the server nor the clie

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 yesterda

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 wr

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. What I'm trying to get at is that idempotency

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

> 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. > for example Bind9 will rotate an RRset by one increment on each query. Regardless of who the client is, the "att

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

On Wed, May 3, 2017 at 6:11 PM, 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. > And that choice is inse

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 > given the enormous query

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 consi

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 > on some, but I can fairly c

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 the fallacy out of the wa

  1   2   >