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 the
> > ticket encryption key, it is not possible
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 right? It looks to me lik
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 default mode. I am
>>> suggesting making the default 0-RTT resumptio
On Mon, Mar 14, 2016 at 5:44 PM, Ryan Hamilton wrote:
> On Mon, Mar 14, 2016 at 2:04 PM, Colm MacCárthaigh
> wrote:
>
>> 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
David,
Thanks for being patient with me here. Sorry it took so long
As usual, this seems like a question of whether we're going to want a lot
of flexibility
(thus motivating orthogonal negotiation) versus whether we're going to want
little flexibility
(thus motivating suites). I think that with t
On Mon, Mar 14, 2016 at 12:23 PM, Ryan Hamilton wrote:
>
> 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 recent pa
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 reasonable
> amount.
>
>
>
>> 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
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 tic
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 now. In April of last year, we posted a
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
>> requests basically at will. As a resul
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 tick
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 recent paper about Replay attacks again
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, 2016 at 9:10 AM, Colm MacCár
> 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 st
(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 8:35 AM, Bill Cox wr
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 other thread we have ways to reduce the
> > impact of infinite replayable data for TLS, making it r
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 to do it that would preserve
On Mon, Mar 14, 2016 at 09:15:17AM -0700, Colm MacCárthaigh wrote:
> 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 authe
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 least
> one of the
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
> safe.
>
That too i
> 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
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 probably retry the r
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 replayabil
> 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 sense. There is no need for re
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 safety. My take is that sp
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 to derive encrypt
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
> need it).
>
Having st
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 deemed
>> to dange
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 pr
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 c
On Sun, Mar 13, 2016 at 9:29 PM, Bill Cox wrote:
> On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg <
> hlieber...@setec.io> wrote:
>
>> Bill Cox writes:
>>
>> More generally, I strongly believe that TLS 1.3 should not
>> provide options which we think should be restricted to "admins who k
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.
>>
>
> +1 for this a
33 matches
Mail list logo
