On 06/11/17 14:31, Loganaden Velvindron wrote:
> On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla wrote:
>> Hi folks,
>>
>> In Prague I mentioned that we were seeing evidence of increased
>> failures with TLS 1.3 which we believed were due to middleboxes. In
>> the meantime, several of us have don
On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla wrote:
> Hi folks,
>
> In Prague I mentioned that we were seeing evidence of increased
> failures with TLS 1.3 which we believed were due to middleboxes. In
> the meantime, several of us have done experiments on this, and I
> wanted to provide an upda
On Saturday, 7 October 2017 20:37:35 CEST Yoav Nir wrote:
> > On 7 Oct 2017, at 17:17, Nick Sullivan
> > wrote:
> >
> > Yoav,
> >
> > Let me make a correction to your scenario:. Instead of:
> > "You’ll need it for Chrome to work with Google."
> > it's:
> > "You’ll need it for Chrome to work with
Hannes Tschofenig wrote:
>
> On 10/10/2017 10:52 AM, Martin Rex wrote:
>> Nope, none at all. I'm _not_ asking for protocol changes, just that
>> the TLS handshake continues to end with CCS + HS, and ContentTypes
>> remain visible. Contents of all handshake messages, and whether
>> and how that
On Tue, Oct 10, 2017 at 11:11:59AM +0200, Hannes Tschofenig wrote:
>
> PS: I think sending fake ChangeCipherSpec messages around is a terrible
> idea.
Oh, me too. That was just thinking what it would take to get around
some really annoying middleboxes.
-Ilari
__
On Tue, Oct 10, 2017 at 10:52:26AM +0200, Martin Rex wrote:
> Ilari Liusvaara wrote:
> [ Charset UTF-8 unsupported, converting... ]
Lol.
> > On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote:
> >>
> >> Fixing the backwards-incompatibilities in the TLS record layer
> >> would be terribl
Hi Martin,
On 10/10/2017 10:52 AM, Martin Rex wrote:
> Nope, none at all. I'm _not_ asking for protocol changes, just that
> the TLS handshake continues to end with CCS + HS, and ContentTypes
> remain visible. Contents of all handshake messages, and whether
> and how that content is protected, r
Ilari Liusvaara wrote:
[ Charset UTF-8 unsupported, converting... ]
> On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote:
>>
>> Fixing the backwards-incompatibilities in the TLS record layer
>> would be terribly useful for streaming-optimized IO layers as well,
>> i.e. ensure the the TLS
On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote:
> Ilari Liusvaara wrote:
> >
> > And even if the changes might not be directly consequential to
> > security, the changes to get through some more annoying middleboxes
> > might be quite annoying to implement.
> >
> > E.g. there probably
Ilari Liusvaara wrote:
>
> And even if the changes might not be directly consequential to
> security, the changes to get through some more annoying middleboxes
> might be quite annoying to implement.
>
> E.g. there probably are several different middeboxes that have a
> configuration that actuall
Eric Rescorla wrote:
>
> two options:
>
> - Try to make small adaptations to TLS 1.3 to make it work better with
> middleboxes.
Return to the proper TLSv1.2 record format with true ContentTypes
(hiding them doesn't add any security anyways).
With the needlessly broken ContentTypes, we will be u
It would be great if the IETF had a mechanism to put something on-hold. To
repeat what I said at ’99, we need to put this on hold for a year or two after
TLS 1.3 is done.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> You seem to be responding to some other thread. As both Adam Langley and I
> mentioned, none of the changes that anyone is investigating for reducing
> middlebox-induced breakage affect the cryptographic properties of TLS.
my apologies. i can only plead low caffeine (6:45 am tokyo time).
the p
You seem to be responding to some other thread. As both Adam Langley and I
mentioned, none of the changes that anyone is investigating for reducing
middlebox-induced breakage affect the cryptographic properties of TLS.
-Ekr
On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush wrote:
> there are a lot of
there are a lot of us lurkers out here a bit horrified watching this wg
go off the rails.
it would help if vendors of devices which break privacy would stop
speaking for 'datacenters' and let datacenters speak for themselves. i
have not seen any doing so. my $dayjob has >10 medium sized datacent
On Sat, Oct 07, 2017 at 11:33:33AM -0400, Jeffrey Walton wrote:
> On Sat, Oct 7, 2017 at 11:25 AM, Salz, Rich wrote:
> >
> >
> >> I suggest we not have this debate now. We'll have a lot more data towards
> >> the end of the month and we can have an informed discussion then.
> >
>
> > That is what
> On 7 Oct 2017, at 17:17, Nick Sullivan wrote:
>
> Yoav,
>
> Let me make a correction to your scenario:. Instead of:
> "You’ll need it for Chrome to work with Google."
> it's:
> "You’ll need it for Chrome to work with Google, Facebook, and most of the 10%
> of Alexa top million sites that are
On Sat, Oct 07, 2017 at 09:38:24AM -0700, Adam Langley wrote:
> On Sat, Oct 7, 2017 at 12:17 AM, Hanno Böck wrote:
> > Alternative proposal:
> >
> > 1. Identify the responsible vendors.
> > 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
> > it's your customers who don't updat
On Sat, Oct 7, 2017 at 12:17 AM, Hanno Böck wrote:
> Alternative proposal:
>
> 1. Identify the responsible vendors.
> 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
> it's your customers who don't update? Seems you don't have any
> reasonable update system. Call your customer
> I didn't intend to be arguing with you. I'm happy to present what I have in
> Singapore and while I can't speak for others, I expect they would be as well.
*I* know you meant everyone else on this thread, and not me.
FB and Google folks, will you present at Singapore?
On Sat, Oct 7, 2017 at 8:25 AM, Salz, Rich wrote:
>
>
> > I suggest we not have this debate now. We'll have a lot more data
> towards the end of the month and we can have an informed discussion then.
>
>
>
>
>
> That is what I am asking for. More information so that the entire WG can
> make an i
Hi,
On Fri, 6 Oct 2017 13:16:37 -0700
Eric Rescorla wrote:
> - Fall back to TLS 1.2 (as we have unfortunately done for previous
> releases)
Thinking about this I honestly hope nobody is considering this
seriously. This would be an unfixable security design flaw. And it also
quite significantly
On Sat, Oct 7, 2017 at 11:25 AM, Salz, Rich wrote:
>
>
>> I suggest we not have this debate now. We'll have a lot more data towards
>> the end of the month and we can have an informed discussion then.
>
> That is what I am asking for. More information so that the entire WG can
> make an informed
> I suggest we not have this debate now. We'll have a lot more data towards the
> end of the month and we can have an informed discussion then.
That is what I am asking for. More information so that the entire WG can make
an informed decision. And I was only laying out an option that does no
I suggest we not have this debate now. We'll have a lot more data towards
the end of the month and we can have an informed discussion then.
-Ekr
On Sat, Oct 7, 2017 at 7:57 AM, Richard Barnes wrote:
>
>
> On Oct 7, 2017 10:43, "Salz, Rich" wrote:
>
>
> ➢ I don't want to speak for browser vend
On Sat, Oct 7, 2017 at 7:44 AM, Watson Ladd wrote:
> On Sat, Oct 7, 2017 at 7:17 AM, Nick Sullivan
> wrote:
> > Yoav,
> >
> > Let me make a correction to your scenario:. Instead of:
> > "You’ll need it for Chrome to work with Google."
> > it's:
> > "You’ll need it for Chrome to work with Google,
On Oct 7, 2017 10:43, "Salz, Rich" wrote:
➢ I don't want to speak for browser vendors, but history suggests that
Option 3) may not be a viable one for browsers with a significant market
share.
They can do what they want, but if they’re “in the rough” on the consensus
call, I hope they’ll go alo
On Sat, Oct 7, 2017 at 7:17 AM, Nick Sullivan
wrote:
> Yoav,
>
> Let me make a correction to your scenario:. Instead of:
> "You’ll need it for Chrome to work with Google."
> it's:
> "You’ll need it for Chrome to work with Google, Facebook, and most of the
> 10% of Alexa top million sites that are
➢ I don't want to speak for browser vendors, but history suggests that Option
3) may not be a viable one for browsers with a significant market share.
They can do what they want, but if they’re “in the rough” on the consensus
call, I hope they’ll go along.
As for yoav’s point about “not during
Yoav,
Let me make a correction to your scenario:. Instead of:
"You’ll need it for Chrome to work with Google."
it's:
"You’ll need it for Chrome to work with Google, Facebook, and most of the
10% of Alexa top million sites that are using Cloudflare."
TLS 1.3 (in on draft version or another) is ver
On Sat, Oct 7, 2017 at 2:57 AM, Ilari Liusvaara
wrote:
> On Fri, Oct 06, 2017 at 01:16:37PM -0700, Eric Rescorla wrote:
> > Hi folks,
> >
> > In Prague I mentioned that we were seeing evidence of increased
> > failures with TLS 1.3 which we believed were due to middleboxes. In
> > the meantime, s
> On 7 Oct 2017, at 4:01, Salz, Rich wrote:
>
> Thanks very much for the update.
>
> There is a third option, name the devices which are known to cause problems,
> and move forward with the draft as-is.
+1. I like this third option.
> 2. Tell all those vendors "You have 1 month to fix this.
On Fri, Oct 06, 2017 at 01:16:37PM -0700, Eric Rescorla wrote:
> Hi folks,
>
> In Prague I mentioned that we were seeing evidence of increased
> failures with TLS 1.3 which we believed were due to middleboxes. In
> the meantime, several of us have done experiments on this, and I
> wanted to provid
Alternative proposal:
1. Identify the responsible vendors.
2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
it's your customers who don't update? Seems you don't have any
reasonable update system. Call your customers, send some support staff
to them. Fix this. Now."
3. Call for
I think this third option is a good idea, it's worked in the past with at
least 2 different load balancers and (to an extent) with a certain color of
proxy.
People that work in "Enterprises" do follow this list and can help open
tickets with vendors and get the work prioritized.
On Oct 6, 2017 8
Thanks very much for the update.
There is a third option, name the devices which are known to cause problems,
and move forward with the draft as-is.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi folks,
In Prague I mentioned that we were seeing evidence of increased
failures with TLS 1.3 which we believed were due to middleboxes. In
the meantime, several of us have done experiments on this, and I
wanted to provide an update.
The high-order bit is that *negotiating* TLS 1.3 seems to cau
37 matches
Mail list logo