Draft: draft-ietf-tls-tls13

Commentary: A straightforward cleanup of part of the backwards compatibility section . ( handles an easy part of issue ) 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 . Remove it and replace it with a simple " MUST NOT " send or accept . Edit to correct attribution of the " phased out with all due haste " language . Whilst in the TLS 1.2 ( 2008 ) spec , it was first introduced in SSL 3 ( 1996 ) . It has been around for 19 years , not 5 . 
  , can you please post about this to the list ? 
 I have to ask , why not SSL 3 as well ? 
 This is about SSLv2 compatibility needing a different ClientHello format . 
 I completely agree that similar language should be for SSL3 as well , however its prohibition RFC is not done yet .  was just an obvious start . I 'll write another PR with the SSL3 prohibition draft language in . 
 One possible idea if SSL 2.0 ClientHello compatibility is still needed is to  it at TLS 1.2 . 
 There is discussion on list , but just let me say for the record here that I am astonished that this was n't considered a non - controversial cleanup . The  hello has been deprecated for 20 years ... 
 Per  's suggestion , this PR is now just for the changes with large agreement . Prohibiting all SSL v2 CLIENT - HELLO entirely is now moved to issue . 
 Per  's suggestion , splitting this off of PR . SSL v2 CLIENT - HELLO support requires additional implementation complexity that is an unnecessary risk to maintain support with a 20 year old deprecated negotiation format . Implementations have had notable bugs in handling this in the past . The current status quo expects them to be acceptable for negotiating TLS 1.0 - 1.2 , even though ALL TLS clients are capable of using the SSL v3 version ClientHello if properly configured . Support for this has been optional and deprecated for many years , with the SSL 3 spec noting in 1996 that " 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 . " Some implementers would be quite happy to have this prohibited entirely so that their code can finally be scrubbed clean of obsolete SSL 2 junk . Others want to perpetuate backwards compatibility support for EOL clients forever . I argue the former . A decision needs to be made on which path to chose . It will be depressing if it is to be the latter . :/ 
 It is now no longer possible to use SSLv2 hellos with TLS 1.3 ( because some extensions are mandatory ) so we should n't need anythign here .
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 RFC2119.
Paragraph (version B):
Prohibit SSL negotiation for backwards compatibility.