Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Tuesday 22 March 2016 10:45:32 Martin Thomson wrote: > On 22 March 2016 at 06:40, Hubert Kario wrote: > > Only in theory, in practice you can do most of the same things in > > GET's as you can in POSTs. > > > > in other words, basically web frameworks can be made to modify

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On 22 March 2016 at 06:40, Hubert Kario wrote: > Only in theory, in practice you can do most of the same things in GET's > as you can in POSTs. > > in other words, basically web frameworks can be made to modify server > state upon receiving GET request Ahh yes, but it's not

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote: > Colm MacCárthaigh writes: > > On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar wrote: > > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite > > > replayability. As mentioned in the

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox wrote: > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh > wrote: > >> On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote: >> >>> As we all know, what matters most in security is the

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

ost and larger benefit compared to session tickets in use today. Kyle From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Colm MacCárthaigh Sent: Monday, March 14, 2016 2:29 PM To: Subodh Iyengar <sub...@fb.com> Cc: tls@ietf.org Subject: Re: [TLS] analysis of wider impact of TLS1.3 repla

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 1:47 PM, Ryan Hamilton wrote: > On Mon, Mar 14, 2016 at 12:25 PM, Salz, Rich wrote: > >> > It's worth keeping in mind this recent paper about Replay attacks >> against HTTPS. TL;DR: Attackers can already force a browser to replay >>

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Ryan Hamilton writes: > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating > wrote: > > > So, I don't think HTTP is generally safe against attacker-forced > > replay, and would suggest great caution in allowing it. > > > > It's worth keeping in mind this

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> It's worth keeping in mind this recent paper about Replay attacks against > HTTPS. TL;DR: Attackers can already force a browser to replay requests > basically at will. ​As a result, it's not clear that 0-RTT replay makes this > situation worse. TLS is more than just browsers, which is what

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara wrote: > > (Also, with regards to my comment about cryptographic screwedness, > such screwedness is not inherent in DH-0RTT, but is consequence of > the current implementation). > This is interesting ... is there a way

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:27 AM, Subodh Iyengar wrote: > Currently the only way to express retry behavior in HTTP is by the method > (i.e. whether it is idempotent or not), which as you pointed out may have > unfortunate side effects, since it is not explicit. The proposal (at

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar wrote: > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite > replayability. As mentioned in the other thread we have ways to reduce the > impact of infinite replayable data for TLS, making it reasonably replay >

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

ttp data. I'll link to it in this thread once it's posted. Subodh From: Watson Ladd [watsonbl...@gmail.com] Sent: Monday, March 14, 2016 11:19 AM To: Subodh Iyengar Cc: tls@ietf.org Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data On Mar 14, 201

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

i.org] > Sent: Monday, March 14, 2016 10:36 AM > To: tls@ietf.org > Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data > > > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > > So, can people sugg

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

From: TLS [tls-boun...@ietf.org] on behalf of Viktor Dukhovni [ietf-d...@dukhovni.org] Sent: Monday, March 14, 2016 10:36 AM To: tls@ietf.org Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <stephe

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> On Mar 13, 2016, at 7:14 AM, Stephen Farrell > wrote: > > So, can people suggest ways in which we can figure out the impact > of replayable data across all the many uses of TLS? For idempotent (more strongly side-effect free) lookup protocols, 0-RTT makes good

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 12:04 PM, Bill Cox wrote: > > IMO, 0-RTT is the most important new feature in TLS 1.3 ... Speed really > _is_ that important. > I just want to be super explicit on this. There is a trade off to be made here between fast and loose Vs security and

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 4:32 AM, Eric Rescorla wrote: > For 1. Raw data throughput could be improved by envelope encrypting the > early data; and transferring the envelope key only once the session has > been fully authenticated > 1. Client generates a random secret and uses it

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote: > As we all know, what matters most in security is the default mode. I am > suggesting making the default 0-RTT resumption mode stateful, with a > documented session-ID (and let's bring back the timestamp, too, since we'll

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 4:39 AM, Eric Rescorla wrote: > This is just my opinion, not Google's. Here is a dumb idea I just had: >> >> The current 0-RTT modes described in TLS 1.3 are clearly only for admins >> who really know what they are doing. If the current 0-RTT modes are

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

] On Behalf Of Bill Cox Sent: Sunday, March 13, 2016 6:23 PM To: Scott Schmit <i.g...@comcast.net> Cc: tls@ietf.org Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit <i.g...@comcast.net<mailto:i.g...@comcast.net>> wro

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla wrote: > > > > However, if I'm in the rough about the above, (which seems > > to me to be the case now) then my job as AD when I get a > > publication > > request that includes 0rtt, will include figuring out if that's > > safe or not. And I've no

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 8:51 PM, Colm MacCárthaigh wrote: > On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell < > stephen.farr...@cs.tcd.ie> wrote: > >> With 0rtt, I think it also becomes a dangerous >> implement. So, that's my personal opinion, while not wearing an >> AD hat.

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 09:26:14PM -0400, Harlan Lieberman-Berg wrote: > > I agree with a slight tweak in wording here, Bill. I think that we > /should/ drop the parts of 0-RTT where we are not confident that an > admin who blindly enables functionality in TLS 1.3 will not end up > harming

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Ar Dé Domhnaigh 13 Márta 2016, scríobh Eric Rescorla : > > > 1. Nothing requires applications to use this feature at all. First, servers > need to advertise it and are free to (a) not offer clients the ability to > send > 0-RTT data and (b) refuse to accept it if clients send it.

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell wrote: > With 0rtt, I think it also becomes a dangerous > implement. So, that's my personal opinion, while not wearing an > AD hat. > +1 for this as 0RTT is outlined in the draft. But to expand a little: * Losing

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Bill Cox writes: >> Most server admins won't be reading the TLSv1.3 spec. They're going to >> see "shiny feature added specifically in this version that makes it >> faster!" with *maybe* a warning that there are risks, which they'll >> dismiss because "if it was so

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 12:21 PM, Eric Rescorla wrote: > > On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote: > >> >> > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote: >> > >> >> I also think it is prudent to assume that implementers will turn

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 11:14:13AM +, Stephen Farrell wrote: > First, with no hats, if the WG were to have a poll on whether > or not to include 0rtt in TLS1.3, then as a participant in the > work here, I'd be firmly arguing to leave it out entirely. I > really think an over-emphasis on

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 11:14:13AM +, Stephen Farrell wrote: > > I've been worried about this for a while now, but the recant > thread started by Kyle Nekritz [3] prompted me to send this > as I think that's likely just the tip of an iceberg. E.g., I'd > be worried about cross-protocol

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> Personally, I think we should start without 0 RTT until we have a better > understanding of what the consequences are. For those who don't know, Kurt is on the openssl-dev team (longer than me), but is just more quiet and modest about it :) ___ TLS

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote: > > > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote: > > > >> I also think it is prudent to assume that implementers will turn on > replayable > >> data even if nobody has figured out the consequences. > > >

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 04:51:49PM +0200, Yoav Nir wrote: > > Is OpenSSL going to implement this? Personally, I think we should start without 0 RTT until we have a better understanding of what the consequences are. Kurt ___ TLS mailing list

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> Is OpenSSL going to implement this? Are all the browsers? > > (only the first one is directed specifically at you, Rich…) I can answer the second question more easily :) Yes the browsers will. OpenSSL is unlikely to have TLS 1.3 before end of 2016 and I don't know what we'll do. Right now

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On 13/03/16 14:49, Eric Rescorla wrote: > Perhaps we could start by actually sponsoring some of those > reviews. Given that HTTP is the primary customer for 0-RTT, perhaps > Mark or Martin would be willing to start a review there? I think that'd really help esp. if we can get folks looking at

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote: > >> I also think it is prudent to assume that implementers will turn on >> replayable >> data even if nobody has figured out the consequences. > > I very much agree. Customers, particularly those in the mobile field, will >

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 3:41 PM, Stephen Farrell wrote: > > Hiya, > > On 13/03/16 14:01, Eric Rescorla wrote: > > > > This is not an accurate way to represent the situation. Those WGs can > safely > > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*. > > I

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> I also think it is prudent to assume that implementers will turn on > replayable > data even if nobody has figured out the consequences. I very much agree. Customers, particularly those in the mobile field, will look at this and say "I can avoid an extra RTT? *TURN IT ON*" without fully

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Hiya, On 13/03/16 14:01, Eric Rescorla wrote: > > This is not an accurate way to represent the situation. Those WGs can safely > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*. I agree your 2nd sentence but not your 1st. I also think it is prudent to assume that implementers will

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 2:51 PM, Stephen Farrell wrote: > > > That allows > > the > > experts in those protocols to do their own analysis, rather than somehow > > making it the responsibility of the TLS WG. I agree that this is a sharp > > object > > and I'd certainly

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Hiya, I mostly agree with what you wrote about specific mitigating factors for specific potential threats. For this thread though, maybe we're better talking about how we might get to where we can be confident that replayable data in TLS1.3 won't cause significant harm. I'm happy to talk more

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell wrote: > > > However, if I'm in the rough about the above, (which seems > to me to be the case now) then my job as AD when I get a publication > request that includes 0rtt, will include figuring out if that's > safe or