Subject: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft

From: Dave Garrett <[email-masked]>
Date: Mon, 22 Dec 2014 19:45:35 -0500

I've submitted a straightforward PR to remove the SSL 2 backwards compatibility 
section from the current TLS 1.3 draft:

https://github.com/tlswg/tls13-spec/pull/105

SSL 2.0 backwards compatibility was previously deprecated in TLS 1.2 (2008) and 
was warned to be "phased out with all due haste". RFC 6176 (2011) prohibits it 
entirely. It's a section of obsolete complexity still in the draft.

The PR replaces the section with a simple "MUST NOT" send or accept for TLS 1.3 
implementations.

Eric Rescorla requested I post this to the list, though I would hope that at 
this point this would be a noncontroversial edit. The only functional difference 
between this language and RFC 6176 is that servers were still permitted to 
accept version 2 CLIENT-HELLO messages, though not actually negotiate the 
protocol.

https://tools.ietf.org/html/rfc6176

There's no reason to maintain any backwards support here just for Internet 
Explorer 2.0 on Windows 3.1.

Dave

---

From: Brian Smith <[email-masked]>
Date: Tue, 23 Dec 2014 13:51:40 -0800

> The PR replaces the section with a simple "MUST NOT" send or accept for TLS 1.3

It would be best to have your change do exactly that, by shortening
the remaining text to:

    Implementations MUST NOT send or accept an SSL
    version 2.0 compatible CLIENT-HELLO. Implementations
    MUST NOT send or accept TLS records with a version
    less than { 3, 0 }.

Note the suggestion to use the term "records" instead of "messages".

I think further changes can be made to tighten up the text regarding
allowed record versions, but those changes are more open for debate.
For example, we might say that the ClientHello's record version MUST
be { 3, 1 } and that the version field in all other records MUST equal
the negotiated version. But, again, this can be done on top of your
changes.

Cheers,
Brian

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Dec 2014 08:40:10 +0200

> Explorer 2.0 on Windows 3.1.

I’m not objecting to the change, but I am objecting to the hyperbole. The issue is with Internet Explorer 6 on Windows XP, which still exists, but more importantly, a lot of web service clients running on top of Windows XP use the same SCHANNEL library as IE would use, so they issue a SSLv2 ClientHello. Despite Microsoft’s best efforts, there is still a substantial but diminishing install base of XP.

It’s fine for us to break compatibility with these clients, but let’s not pretend it’s some ancient technology that doesn’t exist in the market anymore.

Yoav

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 23 Dec 2014 23:02:54 -0800

> It’s fine for us to break compatibility with these clients, but let’s not pretend it’s some ancient technology that doesn’t exist in the market anymore.
If needed, one suggestion would be to cap the old SSLv2 ClientHello to TLS 1.2.
I don't think the old SSLv2 ClientHello supports extensions anyway.

Yuhong Bao

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Dec 2014 10:18:22 +0200

> On Dec 24, 2014, at 9:23 AM, Dave Garrett <[email-masked]> wrote:
> 
> On Wednesday, December 24, 2014 01:40:10 am you wrote:
>>> There's no reason to maintain any backwards support here just for
>>> Internet Explorer 2.0 on Windows 3.1.
>> 
>> I’m not objecting to the change, but I am objecting to the hyperbole. The
>> issue is with Internet Explorer 6 on Windows XP, which still exists, but
>> more importantly, a lot of web service clients running on top of Windows
>> XP use the same SCHANNEL library as IE would use, so they issue a SSLv2
>> ClientHello. Despite Microsoft’s best efforts, there is still a
>> substantial but diminishing install base of XP.
> 
> I was not aware Microsoft used an SSL2 ClientHello for SSL3. Thanks for pointing 
> that out. Is it not capable of sending an SSL3/TLS Hello at all? If it were 
> properly configured to enable TLS1 and disable SSL2/3, would it send the proper 
> TLS compatible Hello? (Microsoft really should've pushed an XP update to flip 
> that switch years ago)

Yes. From the control panel you clicked “Internet Options”, and that had a tab for security, but it wasn’t there. Instead, it was in the tab for advanced, which had a bunch of options, some related to security, but it was under “encryption”, not security. There were checkboxes for support of SSLv2, SSLv3, and TLS 1.0.  By default the SSLv2 and SSLv3 checkboxes were checked, while the TLS 1.0 box was unchecked. To get rid of the SSLv2 ClientHello you had to uncheck the SSLv2. I don’t think the kind of people who still use Windows XP are the same ones who would go into the settings to disable SSLv2. 

I might have some of the details wrong. It’s been a few years since I last set Internet Options on a Windows XP box.

Yoav

---

From: Dave Garrett <[email-masked]>
Date: Tue, 23 Dec 2014 20:46:20 -0500

On Tuesday, December 23, 2014 04:51:40 pm Brian wrote:
> > The PR replaces the section with a simple "MUST NOT" send or accept for
> > TLS 1.3 implementations.
> 

I've updated the language for SSL2 based on your suggestions and have added in 
new language to prohibit SSL3 negotiation. Specifically, I'm using wording based 
on:
https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00

This would have SSL2 connections attempts be ignored and SSL3 connection 
attempts be refused.

Dave

PS

I do hope the SSL3 "diediedie" name stays around until RFC, as it so nicely 
carries the appropriate sentiment. ;)

---

From: Dave Garrett <[email-masked]>
Date: Wed, 24 Dec 2014 02:23:45 -0500

> It’s fine for us to break compatibility with these clients, but let’s not
> pretend it’s some ancient technology that doesn’t exist in the market
> anymore.
> 
> Yoav

Sad, but I guess that's true. :/

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 24 Dec 2014 03:24:35 -0500

> the negotiated version. But, again, this can be done on top of your

Making the revisions for that was straightforward enough. I've also made some 
small editorial changes to the backwards compatibility section to update things 
as well as make it a little easier to follow.

https://github.com/tlswg/tls13-spec/pull/107

That plus the other PR for dealing with SSL should probably be enough to resolve 
issue #54, "Rewrite backward compatibility section to deal with TLS 1.3".

I'm no expert on the implementation details of working with buggy severs, so it 
might be warranted to add more information here.

I know some implementations already specify the ClientHello in this fashion, yet 
I don't know if there's a consensus on this topic. I would expect to wait until 
next year for those who wish to debate this, due to the holiday season.

Dave

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 26 Dec 2014 19:11:39 +0100

> The PR replaces the section with a simple "MUST NOT" send or accept for TLS 1.3 

I'm having mixed feelings about this.

It's saying that you should refuse a connection from a client that
supports TLS 1.0 but set it up using a SSLv2 compatible client
hello.  If TLS 1.0 is still acceptable, why would you refuse such
a connection?

On the other hand if you do receive such a client hello you're
likely talking to old software that most likely isn't support
anymore and might have various security issues.  It might be a
good indication of clients you prefer not to talk to.

PS: I recently actually removed all the SSLv2 support from OpenSSL
(in master) except for supporting receiving an SSLv2 compatible
client hello.

Kurt

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 26 Dec 2014 14:12:25 -0500

> (in master) except for supporting receiving an SSLv2 compatible
Some folks need this for auditing systems. I have a custom build of
SSLscan that exercises it.

Eventually, we will get to a point where lack of back patching new
features to into a branch coupled with lack of SSLv2 support testing
means we won't be able to perform a thorough audit.

Jeff

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 27 Dec 2014 00:26:25 +0100

On Fri, Dec 26, 2014 at 05:47:00PM -0500, Dave Garrett wrote:
> On Friday, December 26, 2014 01:11:39 pm Kurt Roeckx wrote:
> My primary concern is that continuing to maintain official support for a 
> deprecated format from an insecure protocol leaves a significant amount of 
> complexity in place just to support woefully out-of-date implementations.

Isn't it up to the implementations to decide if they still wish to
support it?  Does it do any harm to support it other then possible
talking to outdated software?

(It currently seems to be about 150 lines in OpenSSL, and it seem
clear to me that it's just to support that.)

> I think that many people agree that one of the main goals of TLS 1.3 needs to be 
> reduction of complexity. The more legacy features that are removed, the simpler 
> the protocol will be, and the safer it will be to implement properly.

Even if TLS 1.3 reduces complexity, it's not suddenly going to
make any implementation less complex.   I think it's likely going
to make things more complex.   It's not like we're going drop
support for the older protocols at the same time.  We'll add one
more that is different then the others.

> Refusing to connect to these old clients will also, hopefully, get some of them 
> upgraded to new ones that actually work with modern protocols.

Or prevent the adoption of the new software because it breaks
things.

> If there were a simple way to detect that, without having to support the old 
> hello format, and reply with a simple refusal that triggered a negotiation using 
> TLS, then that might be preferable. However, at some point it's just not worth 
> it. You just have to cut off backwards compatibility, eventually.
> 
> Also, I'm not sure I agree that TLS 1.0 is still acceptable. Personally, I'd 
> like to see an official deprecation and an attempt to force implementations to 
> upgrade to at least 1.2 at some point. HTTP/2 should help here, I hope. (at 
> least on the web) It would be nice to not have to panic and handle some fatal 
> flaw in TLS 1.0 like had to be done for SSL 3.

I would also like to get rid of TLS 1.0.  It's just not realistic
to do this at this point in time.  Only about 50% of the http
servers support TLS 1.2 currently.

Kurt

---

From: Hauke Mehrtens <[email-masked]>
Date: Sat, 27 Dec 2014 23:07:12 +0100

> It’s fine for us to break compatibility with these clients, but let’s not pretend it’s some ancient technology that doesn’t exist in the market anymore.

In addition the Oracle Java Runtime Environment in Version 6 uses a SSL
v2 compatible ClientHello in the default settings. It supports SSL v3
and TLS 1.0. In Java JRE 7 a SSLv3 ClientHello is used by default.

I think a TLS 1.3 Client must not send a SSLv2 ClientHello, but a server
should understand it.

Hauke

---

From: Yoav Nir <[email-masked]>
Date: Sun, 28 Dec 2014 00:54:22 +0200

Hi, Dave

I see a "should" from Hauke and a "should not" from you. But using RFC 2119 words like “MUST NOT” in the spec could mean one of the following things:
 1, That an SSLv2 ClientHello with version equal to whatever we choose for TLS 1.3 (0x03,0x04?) must be rejected and the connection closed.
 2. That any TLS 1.3 implementation MUST remove support for SSLv2 ClientHellos.
 3. That it is no longer prudent to even perform handshakes with clients that still offer SSLv2. In this case SSLv2 support is used as a proxy for insecure peer.

In your message you said “should not”. Why do you think we need to mandate dropping this support from existing products?

Yoav

> On Dec 28, 2014, at 12:39 AM, Dave Garrett <[email-masked]> wrote:
> 
> On Saturday, December 27, 2014 05:07:12 pm Hauke Mehrtens wrote:
> The newest version of TLS should not be have to be written to accommodate an 8 
> year old EOL Java version's default settings.
> 
> 
> Dave

---

From: Fabrice <[email-masked]>
Date: Sat, 27 Dec 2014 14:59:02 -0800

> On Dec 27, 2014, at 14:07, Hauke Mehrtens <[email-masked]> wrote:
> 
> 
> 

openssl s_client, is also using a SSLv2 hello unless the -no_ssl2 option is used. (At least in the 0.9.8 version shipped on OSX, other may comment if this is still true on other platforms and in more recents OpenSSL version)

s_client is often used in scripts and test harness and there is no easy way to disable that behavior globally short of recompiling.

In my mind, the point of explicitly forbidding v2 hellos on the server side is to:
- First eventually kill all remaining clients that's still speak v2 by default. 
- Once those clients are gone this should finish killing all remaining ssl2 servers.

Also, the complexity of implementing the SSLv2 record parsing on the server side for servers that only do TLS is real. Isn't that the origin of the bug that caused server to hang on client hello with specific size? The one that motivated the writing of https://tools.ietf.org/html/draft-agl-tls-padding-03 ?

I think implementors will be happy to remove that bug prone piece of code from their stacks, eventually.

-- Fabrice. 

> Hauke
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Brian Smith <[email-masked]>
Date: Sat, 27 Dec 2014 15:37:08 -0800

>  1, That an SSLv2 ClientHello with version equal to whatever we choose for TLS 1.3 (0x03,0x04?) must be rejected and the connection closed.

The server should be required to (MUST) reject such a client hello, so
that we can make some extensions mandatory for the client to send.
(SSL2-compatible hellos cannot support extensions.) In particular,
signature_algorithms and SNI, at a minimum, should be mandatory to
send, at least for HTTPS clients.

>  3. That it is no longer prudent to even perform handshakes with clients that still offer SSLv2. In this case SSLv2 support is used as a proxy for insecure peer.

if the server is allowed to support TLS 1.0, then it should seems
reasonable for it to negotiate TLS 1.0 with a client that sent an
SSL2-compatible TLS 1.0 ClientHello. However, I think it is fine to
say that the server MUST NOT implement support for the SSL2 protocol.
And, it is fine to say that all TLS clients MUST NOT use
SSL2-compatible ClientHellos, since they wouldn't be able to add
extensions if they did.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Sat, 27 Dec 2014 16:39:07 -0800

Dave Garrett <[email-masked]> wrote:
> On Saturday, December 27, 2014 06:37:08 pm Brian Smith wrote:
>> SSL2-compatible TLS 1.0 ClientHello.
>
> The fact
> that some clients are EOL and might not do connect in a way that will work
> forever is not something worth worrying about. I don't think it's unreasonable
> to expect that 20 years later the "new" hello format should be mandatory.

> SSL2 messages should not be tolerated at this point if we want TLS 1.3 to be
> considered a specification for a modern security protocol implementation.

Like I said in my previous message, I do think that for TLS 1.3,
SSL2-compatible ClientHellos must not be used since they don't allow
extensions. Further, it is better for the TLS 1.3 spec to remove all
the text describing the SSL2-compatible hello stuff, regardless of
whether or not supporting SSL2-compatible-ClientHello for TLS
1.0/1.1/1.2 is explicitly prohibited or not.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Sat, 27 Dec 2014 17:38:56 -0800

Dave Garrett <[email-masked]> wrote:
> On Saturday, December 27, 2014 07:39:07 pm Brian Smith wrote:
> I'm hesitant to even mention it, but obviously my next most preferred route is
> obviously to do that and make acceptance of an SSL2 hello for older TLS versions
> a SHOULD NOT rather than a MUST NOT.

That seems good to me.

> That, however, is basically just RFC 6176 with a wag of a finger thrown in.

That's good, because it should be easy for everybody to accept.

> There have been bugs caused by supporting this and it should be mandated to no
> longer be usable for all implementations. Anyone actually relying on it and not
> capable of flipping the client-side switches needed to stop it is not likely to
> be a candidate for early adoption of TLS 1.3, anyway.

Servers generally cannot flip switches on the client.

I want TLS 1.3 to be deployed widely and quickly after it's been
standardized, and I want people to be able to put it into production
use during the standardization effort so we get the same kind of
interop testing that HTTP/2 got. This requires that the TLS 1.3 spec
should try to avoid breaking how earlier versions of TLS work, unless
there is a very strong reason to do so.

Cheers,
Brian

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 28 Dec 2014 11:43:48 +0100

On Sat, Dec 27, 2014 at 02:59:02PM -0800, Fabrice wrote:
> 
> openssl s_client, is also using a SSLv2 hello unless the -no_ssl2 option is used.

This was changed in OpenSSL 1.0.0.  The default cipher list
dropped SSLv2 ciphers and it would only use an SSLv2 compatible
client hello in case the cipher list didn't include an SSLv2
cipher and there aren't any extentions.  OpenSSL 0.9.8
unfurtuantly is still a supported version but we've announce
end of line for the end of next year.

Kurt

---

From: Hauke Mehrtens <[email-masked]>
Date: Sun, 28 Dec 2014 15:43:41 +0100

Hi,

as even OpenSSL 0.9.8 sends such ClientHellos in the default settings, I
think TLS 1.3 should support the following:

1. TLS 1.3 Clients must only negotiate TLS 1.0 or up. I think with the
Poodle attack most servers and clients already deactivated SSL v3
support. This is draft-ietf-tls-sslv3-diediedie-00.
2. A TLS 1.3 Client most not send a SSL v2 or SSL v3 ClientHello. This
is draft-ietf-tls-sslv3-diediedie-00.
2. A TLS 1.3 server may or should accept a SSL V2 and V3 compatible
ClientHello, but not negotiate these protocol versions.

I think for compatibility reasons most implementors would like to stay
compatible with old ClientHellos, but I think the RFC should not mandate
this. In 10 years TLS servers implementors are probably save to remove
support for this old OpenSSL version, Java 6 and probably more stuff.
This should be an implementors decision how long they want to stay
backwards compatible with old software as long as this does not have
negative implications on security.

Hauke

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 28 Dec 2014 17:44:21 +0100

> ClientHello, but not negotiate these protocol versions.

Maybe some people would like to see that TLS 1.3 should never be
set up using an SSLv2 compatible client hello.

Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 28 Dec 2014 13:44:25 -0500

TLS 1.3 is going to require new code.  A client supporting TLS can issue a post-SSL2 handshake. A server supporting old clients can try the new handshake, and then fallback and re-parse if it doesn't work.

This is a new protocol version, not a BCP.  If not now, when CAN we move things forward?

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Watson Ladd <[email-masked]>
Date: Sun, 28 Dec 2014 13:55:03 -0500

> set up using an SSLv2 compatible client hello.

I am really confused as to what the proposed v2 compatible, TLS 1.3
hello would look like. TLS 1.3 demands extension support, and the
SSLv2 and v3 protocols do not support extensions.  We've already seen
bugs and workarounds (padding extensions) resulting from continued
support of SSLv2.

There is a working version negotiation mechanism in TLS 1.0 and above
which doesn't have these issues. We should use it: a tiny handful of
old clients don't matter.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: [email-masked] (Martin Rex)
Date: Mon, 29 Dec 2014 12:58:43 +0100 (CET)

Yoav Nir wrote:
> 
> I see a "should" from Hauke and a "should not" from you.
> But using RFC 2119 words like ?MUST NOT? in the spec could
> mean one of the following things:

Using RFC2119 words "MUST NOT" in the spec would mean, according to
section 6 of RFC2119, that such a requirement would be NULL and VOID.

>> December 27, 2014 05:07:12 pm Hauke Mehrtens wrote:
>>> Yoav Nir wrote:
>>>>
>>>> It's fine for us to break compatibility with these clients, but let's not
>>>> pretend it's some ancient technology that doesn't exist in the market
>>>> anymore.
>>> 
>> The newest version of TLS should not be have to be written to accommodate
>> an 8 year old EOL Java version's default settings.

JDK 1.6 might be past its "End of Public Updates", but it is still
fully supported and pretty omnipresent, in particular in company
environments and the majority of server-side (J2EE) installations.

  http://www.oracle.com/technetwork/java/javase/eol-135779.html

You can start the JavaVM with the additional command line parameter
   -Dhttps.protocols="TLSv1"
but the default seems to be the use of a SSL VERSION 2.0 CLIENT-HELLO
at the beginning of a new connection.

OpenSSL 0.9.8 is also in use with enterprise installations,
such as SUSE SLES-11(up to and including sp3), for which the
General supports ends on 31-Mar-2019 and extended support ends on 31-Mar-2022

  https://www.suse.com/lifecycle/

Breaking backwards interop just for the sake of the fun of it is a bad
idea and will slow down adoption.  Poor backwards interop slowed and is
still slowing down adoption of TLSv1.2, and same for IPv6.

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Fri, 26 Dec 2014 17:47:00 -0500

My primary concern is that continuing to maintain official support for a 
deprecated format from an insecure protocol leaves a significant amount of 
complexity in place just to support woefully out-of-date implementations. I 
think that many people agree that one of the main goals of TLS 1.3 needs to be 
reduction of complexity. The more legacy features that are removed, the simpler 
the protocol will be, and the safer it will be to implement properly.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Fri, 26 Dec 2014 18:58:19 -0500

> clear to me that it's just to support that.)

It's always possible for some implementation to have a bug in how it handles 
hellos. Having to decipher which is which is not as clean as one would hope. 
Just because it's probably being done correctly now, doesn't mean some (new) 
implementation couldn't do something bad here. If there is a problem, it's 
probably not going to be properly tested, seeing as it's an obsolete format. 
It's yet another thing to worry about.

> more that is different then the others.

Well, strictly speaking, the goal is to add as little new complexity as 
possible, in total. Dropping SSL3 support is at least another drop in 
complexity, as well.

> > Refusing to connect to these old clients will also, hopefully, get some
> > of them upgraded to new ones that actually work with modern protocols.
> 

Anyone using software that old has probably already made that choice. :/

> servers support TLS 1.2 currently.

I agree. I'm certainly not in favor of an SSL2/3 style prohibition RFC, or 
anything. I'm just saying that it would be far better to attempt to put some 
pressure on them rather than just waiting around. Unfortunately, I admit that 
changing UIs to indicate HTTP as insecure, and releasing HTTP/2 and 
letsencrypt.org are prerequisites to getting serious about not tolerating out-
of-date security. An official "please stop using TLS 1.0" from the IETF is about 
the best one could hope for, at the moment. I guess we'll get that to some 
degree with:
https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 27 Dec 2014 17:39:24 -0500

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 27 Dec 2014 18:42:20 -0500

On Saturday, December 27, 2014 05:54:22 pm Yoav Nir wrote:
> I see a "should" from Hauke and a "should not" from you. But using RFC 2119
> words like “MUST NOT” in the spec could mean one of the following things:
> 1, That an SSLv2 ClientHello with version equal to whatever we choose for
> TLS 1.3 (0x03,0x04?) must be rejected and the connection closed. 2. That
> any TLS 1.3 implementation MUST remove support for SSLv2 ClientHellos. 3.
> That it is no longer prudent to even perform handshakes with clients that
> still offer SSLv2.

The intent of the language used is #3. Specifically, neither the version nor the 
hello format from 1995 should be considered acceptable in 2015.

> In this case SSLv2 support is used as a proxy for insecure peer.

Indirectly, yes, though not directly. I'm simply stating that having to 
implement the obsolete format is an unreasonable kludge to keep around. If it 
weren't for the differing format, I'd be suggesting simply refusing to negotiate 
SSL2 as is already expected.

> In your message you said “should not”. Why do you think we need to mandate
> dropping this support from existing products?

Inverted: Can you really make a full justification for keeping this around still?

Fabrice's reply gives a specific example of breakage from this, if you want one.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 27 Dec 2014 19:06:00 -0500

> SSL2-compatible TLS 1.0 ClientHello.

TLS 1.0 is perfectly capable of negotiating using the proper hello. The fact 
that some clients are EOL and might not do connect in a way that will work 
forever is not something worth worrying about. I don't think it's unreasonable 
to expect that 20 years later the "new" hello format should be mandatory.

Let's stop and think about this for a moment. We're discussing a message format 
from a two decade old protocol, generally considered to be woefully insecure and 
unfit for any use. It has been listed in the "backwards compatibility" section 
since SSL3 in 1996. The following has been in there for 19 years:

"Warning: The ability to send version 2.0 client hello messages will
be phased out with all due haste. Implementers should make every
effort to move forward as quickly as possible."

> However, I think it is fine to

That is already agreed upon via RFC 6176.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 27 Dec 2014 20:07:51 -0500

On Saturday, December 27, 2014 07:39:07 pm Brian Smith wrote:
> > that some clients are EOL and might not do connect in a way that will
> > work forever is not something worth worrying about. I don't think it's
> > unreasonable to expect that 20 years later the "new" hello format should
> > be mandatory.
> > 
> > SSL2 messages should not be tolerated at this point if we want TLS 1.3 to
> > be considered a specification for a modern security protocol
> > implementation.
> 

I'm hesitant to even mention it, but obviously my next most preferred route is 
obviously to do that and make acceptance of an SSL2 hello for older TLS versions 
a SHOULD NOT rather than a MUST NOT. That, however, is basically just RFC 6176 
with a wag of a finger thrown in.

If the TLS WG was doing the proper thing, namely writing a TLS 1.3 that was just 
an update of TLS designed to make implementing modern security easier and saving 
other changes for TLS 1.4, then I would probably agree with your position. It's 
not though; HTTP/2 is having to be released with a messy hack to attempt to make 
TLS 1.2 palatable. The response I got to suggesting a more iterative approach 
was that people wanted to fix all the problems and get it right. That's a bit of 
a contradiction with considering this hello format valid for any use.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 27 Dec 2014 20:51:21 -0500

> Servers generally cannot flip switches on the client.

I'm referring to situations where an organization has legacy software they use 
with old clients and an old server. In a case like that, they would be capable 
of pushing a pref change to their clients easily enough.

If we're talking about obsolete clients on the general web, then no, obviously. 
I just prefer breakage over perpetuating its legitimacy.

> there is a very strong reason to do so.

Very much agreed, however I argue that legacy complexity and its resultant risks 
are strong enough, and that not enough clients would break to justify keeping 
it. (the later could unfortunately be swayed with stats that say otherwise)

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sun, 28 Dec 2014 14:01:11 -0500

On Sunday, December 28, 2014 09:43:41 am Hauke Mehrtens wrote:
> as even OpenSSL 0.9.8 sends such ClientHellos in the default settings

http://openssl.6102.n7.nabble.com/OpenSSL-0-9-8-End-Of-Life-Announcement-
td54154.html

OpenSSL 0.9.8 will be EOL next year and is receiving only security updates until 
then. Servers still using it will not be affected by whatever is specified in TLS 
1.3. What client would still be using this? (and why should we care?)

Java 6 has been EOL for a couple years now.

New security protocols should not be written to accommodate dead software, 
especially if there's no plausible reason to legitimately use it still.

I restate again, that even these EOL implementations are perfectly capable of 
interoperating with the proposed spec if properly configured. SSL2 & SSL3 should 
not be enabled. This is already agreed upon. (pending second RFC passage for 
official status) The desire to continue supporting SSL2 hellos requires the 
acceptance that it is legitimate to expect an insecurely configured 
implementation to work forever. This is not a safe thought process.

Also, it breaks things. It'd be nice to stop that.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Dec 2014 11:03:30 -0800

> still slowing down adoption of TLSv1.2, and same for IPv6.

I think that - as I think Brian suggested earlier - requiring TLS 1.3
clients not to offer SSLv2/3; and requiring TLS 1.3 servers not to
negotiate 1.3 with clients that offer SSLv2/3; is perfectly
reasonable.  As a practical matter, we'll be relying on Hello
extensions, so those combinations are impossible anyway.

No one is going to change what Java 6 does.  And mandates on what any
deployment should do outside of what is required for TLS 1.3 would be
inappropriate for this draft.  Our separate recommendations on SSLv2/3
elsewhere should suffice.

You might agree to ignore those recommendations.  That is, as always,
your prerogative.  RFC compliance being essentially voluntary.

---

From: [email-masked] (Martin Rex)
Date: Mon, 29 Dec 2014 20:26:57 +0100 (CET)

Dave Garrett wrote:
> Martin Rex wrote:
> Server-side usage would not be affected by the proposed changes.

Server-side usage will be significantly adversely affected by a silly
MUST NOT accept TLSv1.2 offered in SSL Version 2.0 CLIENT-HELLO

>
> Server and client usage in company environments are where it is easiest
> to deal with the proposed changes. The clients' settings just need to be
> changed to stop using SSL entirely and send only v3 hellos.

The Server's setting will have to be changed to modify the client connections
originating from a J2EE server that is using Java 6.

> 
> I'll restate again, this is already the consensus.
> (again, assuming no surprises with the SSL3 I-D)
> 
> http://tools.ietf.org/html/rfc6176

You might be misreading that document:

  http://tools.ietf.org/html/rfc6176#section-3

   o  TLS servers MAY continue to accept ClientHello messages in the
      version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
      Appendix E.2.

A SSL Version 2.0 CLIENT-HELLO offering TLSv1.2 is perfectly sufficient
to negotiate the mandatory-to-implement TLSv1.2 TLS cipher suite:

  https://tools.ietf.org/html/rfc5246#section-9

>
> "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
> HELLO message format"

This applies only to *NEW* clients.  This does not affect the behaviour
of the installed base at all.  The Server-side needs to address the behaviour
of the installed base for the purpose of interop.

> 
> With both SSL2 & SSL3 prohibited, there should be no v2 hellos.

But there still are plenty of them around in the installed base.

> 
> Put bluntly, any environment that actually HAS v2 hellos is already
> ignoring IETF RFCs.

Behaviour of the installed base is well known to be unaffected by documents
published by the IETF (or any other organization, or government).

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Mon, 29 Dec 2014 15:28:11 -0500

> MUST NOT accept TLSv1.2 offered in SSL Version 2.0 CLIENT-HELLO

This is a semantical disagreement. The server will continue to work fine, just 
dropping v2 connection attempts. It's the client sending the v2 hello that will 
be disaffected. (it could be phrased from either perspective; the client 
initiates the connection, so I significantly prefer this one)

>       version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],

Yes, in 2011 optional backwards compatibility was left in place. In 2015 I'm 
saying that it shouldn't be expected anymore. (or let's be realistic, 2016, when 
the slow to update get around to considering this)

>   https://tools.ietf.org/html/rfc5246#section-9

Wrong reference? That's just the MTI cipher. SSL2 compatibility in TLS 1.2 is 
here:

https://tools.ietf.org/html/rfc5246#appendix-E.2

What it does say is:

"However, even TLS servers that do not support SSL 2.0 MAY accept
version 2.0 CLIENT-HELLO messages."

It's only sufficient if the server is willing to do so. It's not to be expected. 
This is a "MAY" and not a "SHOULD".

Clients MUST send v2 to connect to SSL2 servers, but that's it.

It is important to remember, however, that this section is not a valid reference 
as-is. RFC 6176 amends it.

> This applies only to *NEW* clients.

Please cite to me where it says that RFC 6176 only applies to new clients. (is 
there actually some other reference I'm missing that says that? that's certainly 
possible) It simply says:

"Updates: 2246, 4346, 5246"
&
"This document updates
the backward compatibility sections found in the Transport Layer
Security (TLS)."

Thus, anything that implements any of the updated TLS 1.x RFCs is expected to 
implement this amendment in full.

If there's some policy I'm missing here, please do point it out. However, I'm 
under the impression that this is fairly unambiguous and SSL2 is not to be 
considered acceptable anywhere. This does not seem like a controversial position 
to take in 2015.

> published by the IETF (or any other organization, or government).

I certainly can't disagree with that. I can disagree that it should be the 
overriding force in deciding what to do next.

-----

Let me sum things up this way. There are two categories here:

A) Obsolete implementations that are insecure and supported by nobody.
B) Obsolete implementations that are at least maintained by some group.

Category B is the enterprise situation. Their IT & the software they use 
maintains this old stuff in some way. Disabling SSL2 & SSL3 is not an 
unreasonable expectation for continued maintenance if their desire is to switch 
servers over to TLS 1.3 capability. If they don't want to adopt TLS 1.3 servers 
yet, they are not affected until they do. TLS 1.3 clients would only fail to 
connect to SSL only servers. Complying with intervening RFCs is simply a 
requirement to implement the new RFC.

Category A is forsaken. There is no expectation of a secure connection with 
those clients. Dragging along backwards compatibility forever for them would be 
irresponsible. If they break, they will have to be replaced with something that 
continues to work. If this was half the population of the Internet, then yeah, 
we'd have to pathetically work around them, but that is not the case. Modern 
clients are fine here and have more than enough widespread use. If IE6 breaks, 
nobody can argue in good conscience that TLS 1.3 should be modified to 
accommodate that. And again, it is entirely possible to click a few checkboxes 
in its security options to fix the issue. (IE has generally had decent 
configurability here) I don't know about you, but I'd like to see a world where 
the only pages old versions of IE can connect to are ones that let you download 
a new browser or at least upgrade its security slightly.

Is there some specific real-world case this opposition is coming from? An 
argument to defend a specific widely used client, with justification for its 
continued use, would be far more persuasive. Simply "ahh, but Java 6" doesn't 
feel like a particularly useful argument when Java 7 & 8 are long since 
available. Give me significant hard numbers and I'll certainly change my opinion 
to a "SHOULD NOT" rather than a "MUST NOT" for all but pure TLS 1.3 connections. 
(the idea that TLS 1.3 should be negotiatable via an SSL2 hello is insane)

Dave

---

From: Dave Garrett <[email-masked]>
Date: Mon, 29 Dec 2014 15:32:39 -0500

On Monday, December 29, 2014 03:28:11 pm Dave Garrett wrote:
> Wrong reference? That's just the MTI cipher. SSL2 compatibility in TLS 1.2
> is here:

Sorry, misunderstanding what you were referencing there. The backwards 
compatibility is in the appendix. The MTI cipher _itself_ is in section 9.

Dave

---

From: Brian Smith <[email-masked]>
Date: Tue, 30 Dec 2014 00:20:34 -0800

> the slow to update get around to considering this)

The change you are suggesting is likely to make people even more slow to update.

>> > "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-

I think everybody agrees with that. The only disagreement is whether
the server MUST refuse to accept a v2-compatible TLS 1.0/1.1/1.2
ClientHello, which is a different thing.

> implement this amendment in full.

No, because we don't expect everybody to conform to every RFC. We
regularly have to deal with implementations that do not conform to
RFCs. In particular, just because some RFC says that a clients MUST
NOT use a SSv2-compatible hello doesn't mean that some servers don't
have legitimate need to deal with clients that do send SSv2-compatible
hellos.

> However, I'm

Zero people are arguing that.

> accommodate that.

Dave,

I think there is pretty strong agreement that:

* The client MUST NOT use an SSLv2-compatible ClientHello. (RFC 6176
already says this.)

* The server MUST reject an SSLv2-compatible ClientHello when its
version field is higher than TLS 1.2. (Somebody else said that this is
already the case because some extensions are mandatory for the client
to send, and extensions aren't allowed in the SSLv2-compatible
ClientHello.)

* All the other text regarding SSLv2 should be removed from the TLS 1.3 spec.

The only disagreement is whether the TLS 1.3 spec should say that the
server MUST reject any SSLv2-compatible ClientHello, regardless of
what TLS version is being offered by the client.

So, why not break up your changeset into two parts in two separate
issues?: One that does the three things that there is agreement on,
and a new changeset for a new issue about whether all SSLv2-compatible
ClientHellos must be rejected. Then at least we don't hold up the
significant progress of those three changes while we resolve whether
to make the last change.

Cheers,
Brian

---

From: Dave Garrett <[email-masked]>
Date: Tue, 30 Dec 2014 03:25:17 -0500

> significant progress of those three changes while we resolve whether

Agreed. Will do.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Mon, 29 Dec 2014 14:08:23 -0500

> environments and the majority of server-side (J2EE) installations.

Server-side usage would not be affected by the proposed changes. TLS 1.3 clients 
would be sending v3 hellos which would be read just fine.

Server and client usage in company environments are where it is easiest to deal 
with the proposed changes. The clients' settings just need to be changed to stop 
using SSL entirely and send only v3 hellos.

http://tools.ietf.org/html/rfc6176
http://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00

To directly quote RFC 6176 (2011):
"TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
HELLO message format"

Put bluntly, any environment that actually HAS v2 hellos is already ignoring 
IETF RFCs. They will potentially ignore the proposed change for this RFC. They 
cannot be the basis for decisions on what gets into new RFCs.

Dave