On Tue, May 09, 2017 at 11:44:14AM -0700, Colm MacCárthaigh wrote:
> On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara
> wrote:
>
> Because HTTP specification expressly forbids any and all updates and
> > writes using safe methods. Ignoring that causes very severe security
> > vulernabilities eve
On Thu, May 11, 2017 at 12:00:17AM -0500, Benjamin Kaduk wrote:
>
> First off, it seems somewhat self-evident that if we guarantee 0-RTT
> non-replay, then of course it makes sense to just concatenate the
> streams. That is, if 0-RTT data is not replayable, there's not much
> special about it to
On Wed, May 10, 2017 at 10:00 PM, Benjamin Kaduk wrote:
>
> However, I'm still not convinced that requiring strong 0-RTT non-replay is
> feasible/the right thing to do.
>
[ I've cut a lot for brevity, but hopefully what I've replied with can
address this, and the rest ]
The case for requiring se
As Ilari says, there's a lot of stuff in here. I'll put some thoughts
here at the top, and more inline.
First off, it seems somewhat self-evident that if we guarantee 0-RTT
non-replay, then of course it makes sense to just concatenate the
streams. That is, if 0-RTT data is not replayable, there'
On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara
wrote:
>
> Doesn't this imply that clients or CDN are using unsafe HTTP methods in
> 0-RTT data? Which is of course _seriously_ broken.
>
It doesn't really. First; the CDN may be acting as a Layer 4 TLS proxy.
Some CDNs sell these as SSL accelerato
On Tue, May 09, 2017 at 10:35:37AM -0700, Colm MacCárthaigh wrote:
> On Tue, May 9, 2017 at 9:41 AM, Salz, Rich wrote:
> >The second problem is that middle-boxes can break any signaling. For
> > example a CDN or TLS accelerator may enable 0-RTT towards the back-end
> > origin without enabling it
On Tue, May 9, 2017 at 9:41 AM, Salz, Rich wrote:
> > It's actually impossible because a 0RTT request may be retried as a 1RTT
> request and there's no way to correlate the two. So when the 1RTT request
> shows up, we can't go "This might be a repeat" - for example the X- header
> trick doesn't w
Am 09.05.2017 um 18:41 schrieb Salz, Rich:
The second problem is that middle-boxes can break any signaling. For example a
CDN or TLS accelerator may enable 0-RTT towards the back-end origin without
enabling it to the original client. In this model, the client has *no* way to
reason about ret
> To me, the argument against this comes down to this: The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.
This is true, and early on there seemed to be general agreement that 0-RTT data
wou
> It's actually impossible because a 0RTT request may be retried as a 1RTT
> request and there's no way to correlate the two. So when the 1RTT request
> shows up, we can't go "This might be a repeat" - for example the X- header
> trick doesn't work in this case. It's subtle, which makes it even
> What would a receiver API then look like? Would it be something like:
...
> Or did you have something else in mind? What are your thoughts on the
> sender side? Just enable 0-RTT and have the toolkit send as much 0-RTT data
> as "fits" and the rest 1-RTT, or an explicit request for a specific
On Tue, May 9, 2017 at 9:00 AM, Salz, Rich wrote:
> To me, the argument against this comes down to this: The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.
>
I absolutely agree with sentime
> On May 9, 2017, at 12:00 PM, Salz, Rich wrote:
>
> To me, the argument against this comes down to this: The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.
What would a receiver API then
To me, the argument against this comes down to this: The 0RTT data has
different security properties than the post-handshake data, and TLS
implementations should not hide that difference from applications.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at
On 05/08/2017 11:45 PM, Ilari Liusvaara wrote:
> On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote:
>> On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
>>
>>> - That automatic wait on 0-RTT failure seems just the kind of feature
>>> that gets disabled. Furthermore, 10 second idle on co
On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote:
> On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
> > On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:
> >> I wanted to start a separate thread on this, just to make some small
> >> aspects of replay mitigating clear,
On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
> On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:
>> I wanted to start a separate thread on this, just to make some small
>> aspects of replay mitigating clear, because I'd like to make a case for TLS
>> providing a single-stream, wh
On Sat, May 6, 2017 at 4:54 PM, Kyle Rose wrote:
> On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara > wrote:
>
>> On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
>> > I asked this question a while back, and didn't get a satisfying answer:
>> if
>> > an on-path attacker replaces the ea
On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara
wrote:
> On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> > I asked this question a while back, and didn't get a satisfying answer:
> if
> > an on-path attacker replaces the early data with a replay from an earlier
> > connection, does
On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> On Sat, May 6, 2017 at 8:22 AM, Salz, Rich wrote:
>
> >
> > What about when **part** of a request is in the 0RTT part, and the rest
> > of it isn’t? I believe this will happen often for H2 initial setup.
> > Imagine the “fun” when init
On Sat, May 6, 2017 at 8:22 AM, Salz, Rich wrote:
>
> What about when **part** of a request is in the 0RTT part, and the rest
> of it isn’t? I believe this will happen often for H2 initial setup.
> Imagine the “fun” when initial connection data, such as login cookies, is
> replayed in other cont
What about when *part* of a request is in the 0RTT part, and the rest of it
isn’t? I believe this will happen often for H2 initial setup. Imagine the
“fun” when initial connection data, such as login cookies, is replayed in other
contexts and eventually decrypted?
--
Senior Architect, Akamai
On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:
> I wanted to start a separate thread on this, just to make some small
> aspects of replay mitigating clear, because I'd like to make a case for TLS
> providing a single-stream, which is what people seem to be doing anyway.
Coupl
I wanted to start a separate thread on this, just to make some small
aspects of replay mitigating clear, because I'd like to make a case for TLS
providing a single-stream, which is what people seem to be doing anyway.
Let's look at the DKG attack. There are two forms of the attack, one is as
follo
24 matches
Mail list logo
