Re: [TLS] Limiting replay time frame of 0-RTT data

On Mon, Mar 14, 2016 at 7:25 PM, Martin Thomson wrote: > On 15 March 2016 at 13:22, Bill Cox wrote: > > In TLS 1.3, tickets are sent after the full handshake completes, after > > encryption is enabled for the connection. Now, if an attacker has

Re: [TLS] Limiting replay time frame of 0-RTT data

On 15 March 2016 at 13:22, Bill Cox wrote: > In TLS 1.3, tickets are sent after the full handshake completes, after > encryption is enabled for the connection. Now, if an attacker has the > ticket encryption key, it is not possible to decrypt old connections. Is > that

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] Limiting replay time frame of 0-RTT data

On Mon, Mar 14, 2016 at 1:43 PM, Kyle Nekritz wrote: > As others have said I do think adding client time solves much more than > just this specific issue. Running a client nonce cache at scale also likely > requires client time in order to limit the storage needed to a

Re: [TLS] Limiting replay time frame of 0-RTT data

>> From the browser side of things, 0-RTT is a solution to a very real >> problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT resumption) >> and converting QUIC to use the TLS 1.3 handshake as a result. > > ... > TCP in the works? (does TCPCT work on the client side?). Do you have any

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

If a client nonce cache is used then the threat is essentially the same as with ordinary retries. As far as forward secrecy, yes, the 0-RTT data loses some forward secrecy. I think this is a reasonable trade off for a lot of use cases. Currently, TLS 1.2 implementations commonly use session

Re: [TLS] Limiting replay time frame of 0-RTT data

On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton wrote: > > On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton > wrote: > >> 0-RTT seems to be a solution looking for a problem. >> > > ​Google has been using 0-RTT as part of the QUIC transport for quite a > while

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] Limiting replay time frame of 0-RTT data

As others have said I do think adding client time solves much more than just this specific issue. Running a client nonce cache at scale also likely requires client time in order to limit the storage needed to a reasonable amount. I like the idea of including time since receiving the session

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] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)

On Mon, Mar 14, 2016 at 12:25 PM, Dave Garrett wrote: > (This thread has gotten long and winding, so I'm replying to these two > portions bellow under a new subject. Reply after quotations.) > > On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote: > > On Mon, Mar 14,

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

[TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)

(This thread has gotten long and winding, so I'm replying to these two portions bellow under a new subject. Reply after quotations.) On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote: > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh wrote: > > On Mon, Mar 14, 2016 at

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

> Is the "application" HTTP or a website? Many websites got bitten by nginx > changing how it treated certain retries due to ordering interactions. The > canonical example is a DELETE and a POST. By application here I mean website html / JS which creates the http request and triggers the agent

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

On Mar 14, 2016 11:04 AM, "Subodh Iyengar" wrote: > > I think the discussion about not understanding the implications of replayability is not correct. We are already in the situation where client data is replayable. For example if a mobile app encounters an HTTP error, it will

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

I think the discussion about not understanding the implications of replayability is not correct. We are already in the situation where client data is replayable. For example if a mobile app encounters an HTTP error, it will probably retry the request throwing caution to the wind about

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

I think that idempotency is a relatively straightforward idea, it seems reasonable to trust that the application layer will only send 0-RTT data that is idempotent in terms of server-side state. I also don't think it's that much different than the current state of TLS. Providing strict replay

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