Subject: [TLS] RE: Comments on the TLS 1.1 draft

From: "John Banes" <[email-masked]>
Date: Mon, 6 Sep 2004 22:37:50 -0700

Adding mention of the AES cipher suites to the TLS 1.1 specification
sounds like a good idea to me. I suspect that market forces will
encourage most people implementing TLS 1.1 to add support for some
subset of the AES cipher suites.

This leads me to wonder why the TLS 1.1 specification still lists the
legacy 40-bit and 56-bit cipher suites. I would expect that any
reasonable TLS 1.1 implementation would forsake these
low-encryption-strength cipher suites. About the only reason to support
these that I can think of is for backward compatibility, and if the
client and server manage to negotiate TLS 1.1, then backward
compatibility obviously isn't an issue. If using a 40-bit or 56-bit
cipher suite becomes necessary, then I would expect the TLS
implementation to fall back to TLS 1.0 or even SSL 3.0.

Regards,
John

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Sunday, September 05, 2004 2:06 AM
To: [email-masked]
Subject: Comments on the TLS 1.1 draft

Given that this is probably my last chance to gripe about things:

Section 6.2.1 says:

  Application data is generally of lower precedence for transmission
than
  other content types and therefore handshake records may be held if
  application data is pending.

Wouldn't application data be of higher precedence if it can pre-empt
handshake
data?

Section 6.3, this is somewhat misleading, the cipher spec that requires
the
most key material isn't 3DES_EDE_CBC_SHA but AES_256_CBC_SHA, even if
it's
defined elsewhere.

(Shouldn't the RFC 3268 suites be folded into the TLS 1.1 spec?  It
seems like
 a good idea to have them all in the same document, at the moment TLS
1.1
 doesn't even hint that there are AES suites, and in particular suites
that
 actually require more keying material than 3DES_EDE_CBC_SHA).

More section 6.3: The mention of IV generation for < TLS 1.1 has been
completely excised, apart from a passing mention elsewhere that explicit
IVs
are new for TLS 1.1.  Shouldn't there be some mention of this somewhere,
either in section 6.3 or in an appendix?  There are various historical
notes
covering older usage (e.g. the lack of a length field in RSA encrypted
data in
SSLv3), but the only way to find out about previous IV usage is to dig
up old
copies of the spec.  Note that this change also applies to the
keying-material
note, since with the additional implicit IV data the size increases
still
further.

Peter.

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

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 07 Sep 2004 19:07:35 +1200

"John Banes" <[email-masked]> writes:

>This leads me to wonder why the TLS 1.1 specification still lists the legacy
>40-bit and 56-bit cipher suites. I would expect that any reasonable TLS 1.1
>implementation would forsake these low-encryption-strength cipher suites.

You need to maintain at least one crippled-crypto suite in the handshake as a
canary for older crippled-crypto versions of IIS, which simply drop the
connection (without sending an alert) if they get a hello containing only non-
crippled suites.  If you get the canary back, you know that you're talking to
IIS and can display an appropriate warning to the user.

(It probably isn't worth retaining crippled suites in the spec for this, just
thought I'd mention it as an FYI).

Peter.