Subject: [TLS] draft-turner-ssl-must-not

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 29 Jun 2010 19:15:06 +0200

I just found out about:
http://www.ietf.org/id/draft-turner-ssl-must-not-01.txt

It seems to suggest dropping SSL 2.0, SSL 3.0 and use TLS 1.2. I pretty
much agree for SSL 2.0, but for SSL 3.0 I have some comments.

For SSL 3.0:
* The main argument for SSL 3.0 is that it uses MD5 in the KDF which is
not collision resistant and pre-image resistant.

I don't think this is clear. I'd explicit mention the finished message
calculation, rather than the KDF, since in general a KDF does not really
need to be collision resistant and pre-image resistant, whilst the
algorithm used for the Finished messages needs to be.

For TLS 1.0:
The following arguments are made:
* TLS 1.0 does not have explicit IVs and counter-measures are required
or move to TLS 1.1 to fix it.

* Some TLS 1.0 implementations incorrectly fail the handshake when
there is data (e.g., extensions).

I understand that the explicit IV, is an issue and moving to TLS 1.1 is
well-advised, but the second argument I think it shouldn't be there. One
might just argue that it is simply easier to just fix those servers,
rather than upgrading everyone else + those.

Moreover it is suggested that "TLS implementations MUST support TLS 1.0
and SHOULD support TLS 1.1 and 1.2". This is problematic, as I found out
the hard way. A TLS implementation that supports TLS 1.2 MUST support
TLS 1.1 if it wants to support TLS 1.0. This sounds funny but in TLS
negotiation there must not be a version gap between the advertized
version and the next highest supported, or negotiation will fail.

For example a client implementation supporting SSL 3.0 and TLS 1.2
cannot exist, since most servers will fallback to TLS 1.0 or TLS 1.1
after having seen TLS 1.2, which is not supported by client. Thus a
table of allowed combinations should be provided :)

regards,
Nikos

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 Jun 2010 13:24:33 -0400

> http://www.ietf.org/id/draft-turner-ssl-must-not-01.txt

Thanks for finding it!  I'm not trying to keep it a secret.  I posted 
it right before IESG telechat week, got swamped, and forgot to send it 
around.  I'll get back to you soon.

spt

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 30 Jun 2010 09:16:54 +0200

> algorithm used for the Finished messages needs to be.

To add to this, it seems that the SSL3 variation of HMAC is used in
the finished messages, thus collision resistance and pre-image
resistance might not even be relevant.

btw. Is there a way for
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
published as historic rfc with the original authors? It's quite bad
there is no easy way to reference it.

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 30 Jun 2010 10:45:24 +0300

> resistance might not even be relevant.

I would also very much like to hear why SSL 3.0 is a MUST NOT accept in that draft. I have quite recently implemented versions from SSL 3.0 to TLS 1.2 from scratch and don't see why I should refuse to negotiate SSL 3.0 with my implementation. I'm ok with it, but I'd like to see some proof first.

Of course the deficiencies of TLS 1.0 are valid for SSL 3.0 as well, but that same draft is recommending TLS 1.0, which seems a bit backwards. Using MD5+SHA1 HMAC variation in finished messages is an annoyance from implementation point of view, because it requires the master_secret that is not necessary in TLS, but not much less secure than the MD5^SHA1 PRF. (might make a difference compared to TLS 1.2 that uses SHA-256 PRF though) And as you mention collisions in KDF shouldn't be an issue, pre-master secret should be secured well enough by the key exchange algorithms anyway.

> there is no easy way to reference it.

I'd like that, right now it's hard to find. Google gives some results but having it in a known location would definitely be a plus.

Juho

---

From: Ivan Ristic <[email-masked]>
Date: Wed, 30 Jun 2010 08:53:11 +0100

Speaking as a keen SSL user but not a cryptographer, I would like to
add that we are in dire need of a clear document that explains why
some protocols should not be used, and why some protocols are better
than others. Some of that information is available on the Internet,
but it's sketchy, difficult to find, and difficult (for
non-cryptographers) to understand.

On Wed, Jun 30, 2010 at 8:45 AM, Juho Vähä-Herttua <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Ivan Ristic
ModSecurity Handbook [http://www.modsecurityhandbook.com]
SSL Labs [https://www.ssllabs.com/ssldb/]

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2010 16:39:26 +0200 (MEST)

> resistance might not even be relevant.

There are a few issues where this document discriminates against SSLv3,
although most implementations that support it have taken care of the
issues listed here: http://www.schneier.com/paper-ssl.html
and many of them have likely addressed timing attack issues as well,
like continuing the handshake with a fake premaster secret instead of
immediately aborting with a specific alert.

> there is no easy way to reference it.

It would already help if the expiration marker and the
I-D "work in progress" boilerplate would be removed from the
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
document -- because this is likely what caused the RFC Editor
to botch the informational reference in rfc-5746 to that URL.

-Martin