Re: [TLS] PR#1091: Changes to provide middlebox robustness

;>> That only applies to the ClientHello. >>> >>> >>> From: Andrei Popov <andrei.po...@microsoft.com> >>> Sent: Wednesday, November 22, 2017 11:22:23 AM >>> To: Yuhong Bao; Peter Saint-Andre;

Re: [TLS] PR#1091: Changes to provide middlebox robustness

> wrote: > >> That only applies to the ClientHello. >> >> >> From: Andrei Popov <andrei.po...@microsoft.com> >> Sent: Wednesday, November 22, 2017 11:22:23 AM >> To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla >> Cc: tls@iet

Re: [TLS] PR#1091: Changes to provide middlebox robustness

ter Saint-Andre; Eric Rescorla > Cc: tls@ietf.org; Tapio Sokura > Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness > > The idea was for the client to randomly add non-existent TLS versions to > supported_versions. > Presumably, this will exercise the extensibili

Re: [TLS] PR#1091: Changes to provide middlebox robustness

Tapio Sokura <tapio.sok...@iki.fi> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness They are basically doing a supported_versions extension with only one entry in the ServerHello. The problem with future middleboxes should be obvious. From:

Re: [TLS] PR#1091: Changes to provide middlebox robustness

__ > From: TLS <tls-boun...@ietf.org> on behalf of David Benjamin < > david...@chromium.org> > Sent: Wednesday, November 22, 2017 5:02:15 AM > To: Tapio Sokura > Cc: tls@ietf.org > Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness > >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

As a source of some of those numbers, someone interested in actually deploying TLS 1.3, and, most importantly, someone who would have to deal with the fallout of that deployment, I can unequivocally say those are not "very good" figures. They are completely implausible by orders of magnitude. TLS

Re: [TLS] PR#1091: Changes to provide middlebox robustness

Hello, On 6.11.2017 20:19, Eric Rescorla wrote: Once you do this, the middleboxes seem to mostly ignore everything after the CCS, so the rest of the handshake proceeds smoothly. This is all a bit nasty, but none of it changes the cryptographic computations or the state machine (because you

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Wed, Nov 8, 2017 at 5:54 AM, Benjamin Kaduk wrote: > On 11/08/2017 07:34 AM, Eric Rescorla wrote: > > > > On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos > wrote: > >> On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: >> > >> > >> > On Tue,

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/08/2017 07:34 AM, Eric Rescorla wrote: > > > On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos > > wrote: > > On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Wed, Nov 8, 2017 at 4:01 AM, Hubert Kario wrote: > On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote: > > On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote: > > > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > > > > On Tue,

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos wrote: > On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd > > wrote: > > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote: > > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > > > > In

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd > wrote: > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar > > wrote: > > > FWIW: In my experience middleboxes don't ossify based on what the > >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

> On 8 Nov 2017, at 2:25, Watson Ladd wrote: > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> FWIW: In my experience middleboxes don't ossify based on what the spec says, >> they ossify based on what they see on the wire. So, if common >>

Re: [TLS] PR#1091: Changes to provide middlebox robustness

> On 8 Nov 2017, at 2:32, Salz, Rich wrote: > > ➢ Given that we're almost there, and that only really browsers are > asking for these hacks, and that even some of those were almost ready > to ship without these hacks, I don't think that this is entirely >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote: > >> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> > FWIW: In my experience middleboxes don't ossify based on what the spec

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 5:19 AM, Eric Rescorla wrote: > - The client sends a fake session_id and the server echoes it One friendly amendment. I think that we should insist (with a MUST) that the server send CCS in the case that it receives a non-empty session_id. That gives

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote: > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: > > FWIW: In my experience middleboxes don't ossify based on what the spec > says, > > they ossify based on what they see on the wire. So, if common >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

➢ Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship without these hacks, I don't think that this is entirely unrealistic as an aspiration. The Internet is more than just a couple of browser

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: > FWIW: In my experience middleboxes don't ossify based on what the spec says, > they ossify based on what they see on the wire. So, if common > implementations send CCS in a particular way, that's what will get --- and, > I'll

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich wrote: > ➢ Given that we're almost there, and that only really browsers are > asking for these hacks, and that even some of those were almost ready > to ship without these hacks, I don't think that this is entirely >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

➢ Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship without these hacks, I don't think that this is entirely unrealistic as an aspiration. The Internet is more than just a couple of

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Wed, Nov 8, 2017 at 7:23 AM, Salz, Rich wrote: > “We can remove it when middleboxes aren’t a problem.” Talk about > aspirational ( Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship

Re: [TLS] PR#1091: Changes to provide middlebox robustness

I think Hubert makes excellent points. “We can remove it when middleboxes aren’t a problem.” Talk about aspirational ( ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote: > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > > > In general +1, I like to see TLS 1.3 deployed ASAP and making the > spurious >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > > failures as rare as possible is a good way to make that happen. > > > > that

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > failures as rare as possible is a good way to make that happen. > > that being said, I have few comments: > > On Monday, 6 November 2017 19:19:01

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 10:53 AM Hubert Kario wrote: > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > failures as rare as possible is a good way to make that happen. > > that being said, I have few comments: > > On Monday, 6 November 2017 19:19:01

Re: [TLS] PR#1091: Changes to provide middlebox robustness

In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious failures as rare as possible is a good way to make that happen. that being said, I have few comments: On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/1091 > > As I

[TLS] PR#1091: Changes to provide middlebox robustness

https://github.com/tlswg/tls13-spec/pull/1091 As I mentioned a while back, we've been seeing evidence of middlebox intolerance. I just posted PR 1091, which is based on a bunch of work by the BoringSSL team and an original suggestion by Kyle Nekritz that should significantly decrease the rate of