[TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)

2018-07-09 Thread Viktor Dukhovni
On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote: > Is there any reason why we wouldn't also consider deprecating cipher > suites we don't like? For instance, RFC 5246 mandates the > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably > agree isn't ideal for

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread nalini elkins
>On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the time on the client side (this includes non-browser connections from all sorts of apps, some hard-coding TLS versions), and TLS 1.1 accounts for ~0.3% of client >connections. Windows server negotiates TLS 1.0 ~1.5% of the

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Salz, Rich
FWIW, The next release of OpenSSL is an LTS release and will be supported for five years. It disables SSLv3 by default, but does enable TLS1.0 and TLS1.1 by default. (It also includes TLS1.3, nudge nudge RFC editor queue.) On 7/9/18, 12:42 PM, "Kathleen Moriarty" wrote: Hello,

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Loganaden Velvindron
On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla wrote: > Thanks for writing this. > > I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox > Telemetry shows that about 1% of our connections are TLS 1.1 (on the same > data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. > >

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Salz, Rich
Without quoting any specific numbers, I share Alessandro's support for this, while also emphasizing that it will be quite some time before my employer stops supporting those versions. ___ TLS mailing list TLS@ietf.org

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Eric Mill
If we're looking for precedent and support, the Canadian government recently (like in the last week or two) issued a policy requiring TLS 1.0 and 1.1 be disabled:

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Martin Thomson
I want to see these disappear, but I am guessing that there is still some time before many products can make the move. For websites, like the ones mentioned in the draft, that time is already here. As a site operator, you do not want to talk to a browser that doesn't talk TLS 1.2. Is there any

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Martin Rex
Andrei Popov wrote: > > On the recent Windows versions, TLS 1.0 is negotiated more than 10% > of the time on the client side (this includes non-browser connections > from all sorts of apps, some hard-coding TLS versions), > and TLS 1.1 accounts for ~0.3% of client connections. "On recent Windows

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-09 Thread Peter Gutmann
Hubert Kario writes: >There Is No Such Thing As A Trusted Network I didn't say "trusted network", I said "isolated, private network". The type where, if an attacker has got to the point where they have physical access to the area where the network is, they can do far more damage via any kind

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-09 Thread Hubert Kario
On Thursday, 5 July 2018 04:32:08 CEST Peter Gutmann wrote: > David Benjamin ​ writes: > >The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit > >minimum. (Chrome enabled far more DHE ciphers than others, so we > >encountered a lot of this.) 2048-bit was completely hopeless. At

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-09 Thread Hubert Kario
On Thursday, 5 July 2018 20:18:27 CEST Martin Rex wrote: > btw. which kind of "problematic pure-RSA" are you talking of? > I'm not actually aware of any problem the ones that gave us 20 years of oracles to use for attacking encrypted connections Bleichenbacher and ROBOT, and those are not even

Re: [TLS] Malformed Finished handling

2018-07-09 Thread Hubert Kario
On Thursday, 5 July 2018 02:06:45 CEST Martin Thomson wrote: > On Wed, Jul 4, 2018 at 7:55 PM Hubert Kario wrote: > > Despite this, is it correct to terminate a connection with > > "illegal_parameter" upon receiving a Finished handshake message with a > > 100 byte payload? or a 20 byte payload?

Re: [TLS] Malformed Finished handling

2018-07-09 Thread Hubert Kario
On Wednesday, 4 July 2018 18:54:10 CEST Eric Rescorla wrote: > On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario wrote: > > On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote: > > > I think it's a close call, because the length is sort of external to the > > > language. > > > > which

Re: [TLS] Malformed Finished handling

2018-07-09 Thread Hubert Kario
On Wednesday, 4 July 2018 15:46:04 CEST Salz, Rich wrote: > >if the interpretation of "I know this _message_ _length_ is wrong > >because of > >some other values I negotiated before, so I'll send illegal_parameter" > >was correct, then overflow_error, decrypt_error and probably

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-09 Thread Blumenthal, Uri - 0553 - MITLL
+1 to Rich and Peter. Regards, Uri Sent from my iPhone On Jul 9, 2018, at 08:20, Salz, Rich wrote: >> There Is No Such Thing As A Trusted Network > > That's a great aphorism, and we've all made lots of progress in working with > that assumption, but there are important cases where it is

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-09 Thread Salz, Rich
>There Is No Such Thing As A Trusted Network That's a great aphorism, and we've all made lots of progress in working with that assumption, but there are important cases where it is not true. And I think Peter works in many of those cases. ___

[TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Kathleen Moriarty
Hello, Stephen and I posted the draft below to see if the TLS working group is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has been a recent drop off in usage for web applications due to the PCI Council recommendation to move off TLSv1.0, with a recommendation to go to TLSv1.2 by

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Eric Rescorla
On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote: > Thanks for writing this. > > I would be in favor of deprecating old versions of TLS prior to 1.2. > Firefox Telemetry shows that about 1% of our connections are TLS 1.1 > This should be 1.0. (on the same data set, TLS 1.3 is > 5%), and

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Eric Rescorla
Thanks for writing this. I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox Telemetry shows that about 1% of our connections are TLS 1.1 (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. This is probably a higher number than we'd be comfortable turning

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Andrei Popov
On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the time on the client side (this includes non-browser connections from all sorts of apps, some hard-coding TLS versions), and TLS 1.1 accounts for ~0.3% of client connections. Windows server negotiates TLS 1.0 ~1.5% of the

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Alessandro Ghedini
On Mon, Jul 09, 2018 at 12:40:54PM -0400, Kathleen Moriarty wrote: > Hello, > > Stephen and I posted the draft below to see if the TLS working group > is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > been a recent drop off in usage for web applications due to the PCI >