Subject: [TLS] publishing SSL 3.0 as historic

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 11 Feb 2011 09:18:31 +0100

Hello,
 After some discussion with Sean Turner, I've decided to
try re-shaping the old draft-ietf-tls-ssl-version3 draft to
be publish it as a historic rfc. The draft I came up with is at:
http://tools.ietf.org/html/draft-mavrogiannopoulos-ssl-version3-00

I've converted the original document to xml format so some
formatting might not be exactly the same. Apart from that
other changes to the original are:
* stray references to documents [IP],[SSL-2] were defined.
* stray reference to RC4 was replaced with RSADSI.
* Appendix A.1.1 was renumbered as A.2 as it was not a subsection of
A.1.
* Section that discussed patents was removed (all patents discussed
are expired).

Do you think this draft should be adopted by the WG and be published as
historic?

regards,
Nikos

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Feb 2011 09:35:41 +0100

> Do you think this draft should be adopted by the WG and be published as

I support this.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Fri, 11 Feb 2011 12:03:13 +0200

> Do you think this draft should be adopted by the WG and be published as

I think it should be published, but why does it need the working group?  SSLv3 is by now set in stone, or rather, set in the code of the browsers that support it.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 11 Feb 2011 11:50:11 +0100

> I think it should be published, but why does it need the working group?  SSLv3 is by now set in stone, or rather, set in the code of the browsers that support it.

Because draft-ietf-tls-ssl-version3 was this working group's item.

regards,
Nikos

---

From: Geoffrey Keating <[email-masked]>
Date: 11 Feb 2011 13:45:59 -0800

> Do you think this draft should be adopted by the WG and be published as

I support this, but would suggest that there should be something
warning readers that SSLv3 has known security issues and so should not
be used by new implementations.

---

From: Martin Rex <[email-masked]>
Date: Sat, 12 Feb 2011 00:31:35 +0100 (MET)

> > Do you think this draft should be adopted by the WG and be published as

I would consider it counter-productive to make such a document a
WG item (I assume the WG would have to re-charter for it).

There is not that much "to fix" about this document anyway, so
an individual submission should be just fine.

In my understanding "historic" is a classification, not a document type.
--the document type ("track") would be Informational.

Considering that a non-marginal fraction of the TLS protected communication
actually negotiates protocol version {0x03,0x00}, there is not reason for
a classification of "historic".

> be used by new implementations.

Consider me highly confused.

What specific security issues do you have in mind that are not either
implementation (rather than protocol) issues other than the overly
detailed alert codes that enabled timing attacks (Bleichebacher,Vaudeney) ?

The latter would be easy to address with an implementation note.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 11 Feb 2011 16:32:50 -0800

> detailed alert codes that enabled timing attacks (Bleichebacher,Vaudeney) ?

Yes, I was thinking of the IV and padding attacks fixed in TLS 1.1.

There are a number of other things that are questionable but not flaws
as such, like the 'should' for SSLv2, and the export cipher suites.  I
guess use of MD5 and SHA-1 also counts as 'questionable' nowadays.

> The latter would be easy to address with an implementation note.

Writing such a note might get quite complex and probably deserves a
RFC of its own...  I was thinking of something simpler, just noting
that this protocol has known flaws which are addressed in current
versions.  I'm good with either approach.

Since I'm looking at the document, I'd also suggest removing this paragraph:

   Note: Additional cipher suites will be considered for implementation
   only with submission of notarized letters from two independent
   entities.  Netscape Communications Corp. will act as an interim
   registration office, until a public standards body assumes control of
   SSL.

and also remove or update the 'Reserved port assignments' section.

---

From: Martin Rex <[email-masked]>
Date: Sat, 12 Feb 2011 02:26:51 +0100 (MET)

> Yes, I was thinking of the IV and padding attacks fixed in TLS 1.1.

Padding?  Does the MAC include the _entire_ padding in any TLS version?
MAC-ing only the payload and not MAC-ing the padding may leak information
about the size of the padding.

A possible solution is to hash the payload, copy the hash context,
hash the padding and finalize only the copied context of the hash over
the payload.   I don't remember any TLS specs hinting about this.

> guess use of MD5 and SHA-1 also counts as 'questionable' nowadays.

There is a difference between "could have done better" and "flawed".

I'm not aware of anything that would make me sleep bad.
I'm actually wondering why TLSv1.2 still truncates the finished
messages to 12 octets, instead of truncating to 20 octets.

> RFC of its own...

I think it would be simple.  If there are pitfalls that can be avoided,
a few implementation hints should be perfectly sufficient.

>
> I was thinking of something simpler, just noting

A brief "this protocol has known flaws which are addressed in current
versions" statement, without listing the issues and possible mitigations,
looks somewhat like FUD to me.

I would prefer to spend time on re-publication of the SSLv3 spec as
an informational RFC only if it adds value for the community.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 11 Feb 2011 17:37:45 -0800

> about the size of the padding.

These, from RFC4346:

   -  The implicit Initialization Vector (IV) is replaced with an
      explicit IV to protect against CBC attacks [CBCATT].

   -  Handling of padding errors is changed to use the bad_record_mac
      alert rather than the decryption_failed alert to protect against
      CBC attacks.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 12 Feb 2011 10:00:37 +0100

On 02/12/2011 12:31 AM, Martin Rex wrote:

>>> Do you think this draft should be adopted by the WG and be
>>> published as historic?
> I would consider it counter-productive to make such a document a WG
> item (I assume the WG would have to re-charter for it). There is not
> that much "to fix" about this document anyway, so an individual
> submission should be just fine. In my understanding "historic" is a
> classification, not a document type. --the document type ("track")
> would be Informational. Considering that a non-marginal fraction of
> the TLS protected communication actually negotiates protocol version
> {0x03,0x00}, there is not reason for a classification of "historic".

Ah, I see what you mean here... The "historic" is mostly because the
protocol is already obsoleted (by TLS 1.x), even if it is still
in use. I don't think the historic category refers to the actual
protocol usage on the internet.

regards,
Nikos

---

From: Ralph Holz <[email-masked]>
Date: Sat, 12 Feb 2011 12:24:43 +0100

Hi,

> a classification of "historic".

Not intending to take sides here, but from our own observations at a
large ISP, SSLv3 seems to be chosen as a protocol version only for a
very marginal fraction of connections. I can't quite remember the
numbers, but it was something around 0.1% or less. I can look it up, if
you want.

-- 
Regards,
Ralph

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 12 Feb 2011 09:05:12 -0500

Wouldn't it make more sense to set the status to Deprecated?

Historic is appropriate for stuff that is never used. The point here is to
tell people to stop using it.

And all the draft needs to say is SSL3.0 has known security issues and TLS
is the current protocol.

On Fri, Feb 11, 2011 at 8:26 PM, Martin Rex <[email-masked]> wrote:

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

-- 
Website: http://hallambaker.com/

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 12 Feb 2011 15:32:57 +0100

> numbers, but it was something around 0.1% or less. I can look it up, if

Among sites probed by my "TLS Prober" the number of SSLv3-only servers is  
about 1.0%.

See  
http://my.opera.com/securitygroup/blog/2010/11/04/a-few-results-from-the-tls-prober  
for more information.

Please note that the article says that the SSL v3-only number at the time  
was 1.5%, later investigation revealed that 0.5 percentage-points of the  
probed servers were actually TLS 1.0 servers that required the Record  
Protocol Version field and the Client Hello Version field to both be 3.1  
to select TLS 1.0; the prober was generally using 3.0 as the Record  
Protocol version. The servers were therefore incorrectly classifies as SSL  
v3-only. The detection problem has since been fixed.

For reference, the number (*not* percentage) of TLS 1.2 servers in the  
last run on Monday was 21 (of 378390). Which is up from the two(2)  
testservers detected when probing started almost a year ago. The TLS 1.1  
count was 108.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Feb 2011 08:23:17 -0800

> Wouldn't it make more sense to set the status to Deprecated?

There is currently no such status for RFCs; see RFC 2026. Having the TLS 
WG attempt to modify RFC 2026 for this one document seems like a large 
use of energy.

---

From: Ralph Holz <[email-masked]>
Date: Sat, 12 Feb 2011 20:20:54 +0100

Hi,

> Among sites probed by my "TLS Prober" the number of SSLv3-only servers
> is about 1.0%.
> 
[...]

Interesting. The difference here may be that you are probing servers
(the Alexa Top 1M list, as I take it) and the ISP is observing what
version established connections actually use. I am currently away from
my office, but I will be back in 10 days and can find out then. Maybe
the numbers are not actually off.

> testservers detected when probing started almost a year ago. The TLS 1.1

Agreed, it's a vanishing percentage.

-- 
Regards,
Ralph

---

From: Yoav Nir <[email-masked]>
Date: Sat, 12 Feb 2011 21:32:01 +0200

> Among sites probed by my "TLS Prober" the number of SSLv3-only servers is  

Yes, but among clients, the latest figures I've heard, 20% were still IE6, and that by default supports only SSLv2 and SSLv3, so the connections end up being SSLv3. That 0.1% figure seems very low to me.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 13 Feb 2011 09:35:43 +0100

>    registration office, until a public standards body assumes control of

Indeed this note might deserve to be removed...

> and also remove or update the 'Reserved port assignments' section.

Since this is a historic document, it might be nice for this
section to stay to indicate how SSL was initially used.

I also would like to minimize editing/removal of text,
because I want to keep the original author's names, and
it would be unfair to publish a different text.

regards,
Nikos

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 13 Feb 2011 08:12:29 -0800

> it would be unfair to publish a different text.

Yes, but this document could *really* use a small subsection near the 
beginning of the Introduction saying why the RFC is being published in 
2011, and saying what the diffs are from the earlier document.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 14 Feb 2011 09:47:46 +0100

> (Bleichebacher,Vaudeney) ?

I can't speak for Geoffrey, but quite a while ago I found problems  
with the unspecified CBC padding bytes in SSL 3.0: something that's a  
potential implementation bug in TLS 1.0 is a protocol bug in SSL 3.0;  
see item 3 in http://www.openssl.org/~bodo/tls-cbc.txt.

Of course, TLS 1.0 still has problems with its CBC ciphersuites  
(implicit IVs are bad), as documented in the TLS 1.1 specs (RFC 4346).

Bodo

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Feb 2011 14:47:26 +0100 (MET)

> numbers, but it was something around 0.1% or less. I can look it up, if

That low number appears somewhat unrealistic to me.

Microsoft Windows XP was shipped with SSLv2 enabled and TLSv1.0 disabled.

The client market shares reported here:
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10

are for Feb 14,2011:

 Windows XP      55.26%
 Windows 7       22.31%
 Windows Vista   11.66%

and I would expect the fraction of the Windows XP users that still uses
MSIE with the default configuration (SSLv2 enabled, TLSv1.0 disabled)
is much larger than 0,1%

Then there are a number of programmatic clients that use SSLv3.
They may not cause much of the Web traffic, but they represent a
non-marginal installed base.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Feb 2011 14:52:10 +0100

> Microsoft Windows XP was shipped with SSLv2 enabled and TLSv1.0 disabled.

Service packs can make rather radical changes, are you sure an updated
Windows XP still enable SSLv2?  If so, I'm hoping the next security
update will disable it.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Feb 2011 16:10:07 +0100 (MET)

> Windows XP still enable SSLv2?  If so, I'm hoping the next security

I do not have access to a sufficient variety of "virgin" installs.
My impression is that installation of MSIE7 (or later) might change
the defaults and disable SSLv2 and enable TLSv1.0.  I don't know about XPsp3.

With XPsp2+MSIE6 as well as Win2K3sp2+MSIE6 the original default applies.

-Martin