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 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
r ALPN as Ilari suggests). So, we might as well just add it and
stuff time
there.
-Ekr
>
> Kyle
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Martin Thomson
> *Sent:* Sunday, March 13, 2016 5:36 AM
> *To:* Erik Nygren
> *Cc:* tls@ietf.org
> *Subje
>> 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
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
of ticket issuance. How
concerning is this, is it worth encrypting this time?
Kyle
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Sunday, March 13, 2016 5:36 AM
To: Erik Nygren
Cc: tls@ietf.org
Subject: Re: [TLS] Limiting replay time frame of 0-RTT data
I assume that
On Sat, Mar 12, 2016 at 12:45 PM, Karthikeyan Bhargavan
wrote:
> Hi Kyle,
>
> In my talk at TRON, I was also concerned by potential attacks from allowing
> unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
> implement replay protection using a cache, but requiring clients t
I assume that you would run a tight tolerance on the 0RTT resumption by
saving the client's clock error in the ticket. That a way only clients
with bad drift get no 0RTT. To do that all sessions need time.
I do not see how the server can do this in general without client help. But
the solution al
That does seem like a good idea to include a client time stamp in the 0RTT
flow to let the server force 1RTT in the case where this is too far off as
this bounds the duration of the replay window. (I suspect we'll find a
whole range of other similar attacks using 0RTT.) An encrypted client
timest
On Fri, Mar 11, 2016 at 10:21 AM, Kyle Nekritz wrote:
> Note: it’s also useful for the server to know which edge cluster the early
> data was intended for, however this is already possible in the current
> draft. In ECDHE 0-RTT server configs can be segmented by cluster, and with
> tickets, the s
Hi Kyle,
In my talk at TRON, I was also concerned by potential attacks from allowing
unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
implement replay protection using a cache, but requiring clients to provide
a timestamp in the client random is a great idea. Perhaps this
Hi Kyle,
Clever attack. I don't think it would be unreasonable to put a low
granularity time stamp in the
ClientHello (and as you observe, if we just define it it can be done
backward compatibly)
or as you suggest, in an encrypted block. With that said, though couldn't
you
also just include the in
13 matches
Mail list logo
