Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt

From: [email-masked]
Date: Wed, 18 May 2005 15:51:12 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: The TLS Protocol Version 1.1
	Author(s)	: T. Dierks, E. Rescorla
	Filename	: draft-ietf-tls-rfc2246-bis-11.txt
	Pages		: 90
	Date		: 2005-5-18
	
This document specifies Version 1.1 of the Transport Layer Security
   (TLS) protocol. The TLS protocol provides communications security
   over the Internet. The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tls-rfc2246-bis-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 24 May 2005 20:29:25 +0200

Hello all,

A couple of question and comments:

Sec. 6 says "If a TLS implementation receives a record type it does not
understand, it SHOULD just ignore it."

If such a record is received after the parties have started encrypting the  
records, should it try to decrypt the data, or should the implementation  
throw the record away immediately?

Sec A.5 specifically forbids the negotiation of 40 bit export ciphers.

Does this also apply to the 56 bit export ciphers that was defined just  
before the export restrictions were eased? My reading of the document  
indicates "Yes". But should not also the single DES suites (e.g.  
TLS_RSA_WITH_DES_CBC_SHA) and perhaps also IDEA also be phased out in a  
similar manner?

About compatibility: Back in August/September 2004 Opera Software  
performed a test where we released a Technology Preview version of Opera  
with TLS 1.1 and TLS Extensions enabled. During this test our users  
identified more than 120 services (including major banks) that did not  
interoperate with a client using either TLS 1.1 or TLS Extensions, or  
both. I have so far not been able to find out what is causing the problem.

Is it within the scope of this draft to discuss how to handle this  
situation? We did, after all, have similar problems when TLS 1.0 was  
introduced.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer		             Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Satoshi Akimoto <[email-masked]>
Date: Fri, 27 May 2005 12:17:39 +0900

Hi,

The terms like 'PKCS #1 block type x' are frequently used in 2246 and its bis, but they are no longer used in the current PKCS #1 or rfc3447. Wouldn't it be more explicit to use 'EME-PKCS1-v1_5' or 'EMSA-PKCS1-v1_5' instead? (it leaves a question for 'type 0' padding, though)

Best regards,
Satoshi Akimoto
Dai Nippon Printing

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 27 May 2005 00:52:49 -0600

> http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt

This new ID does not yet correct the inconsistencies for some field
and type names pointed out in
<URL:http://www.imc.org/ietf-tls/mail-archive/msg04525.html>,
reproduced below.

But first, here's a new comment:

7.4.7.1. RSA encrypted premaster secret message

       [...]                                         In practice, since
       there are no significant known security differences between TLS
       and SSLv3, rollback to SSLv3 is not believed to be a serious
       security risk.

Discussing "security differences between TLS and SSLv3" is a little
odd because this sounds like comparing two protocol versions.  But in
fact this specification defines TLS 1.1, so there are three protocol
versions to take into account.  And there are security differences
both between SSL 3.0 and TLS 1.0 *and* between TLS 1.0 and TLS 1.1:
TLS 1.1 uses explicit IVs for CBC encryption to avoid deficiencies
present in both earlier versions; SSL 3.0 has additional weaknesses
due to its failure to completely specify block cipher padding
(as I pointed out in
http://www.imc.org/ietf-tls/mail-archive/msg03983.html).

Section 7.4.3 defines

       struct {
           opaque rsa_modulus<1..2^16-1>;
           opaque rsa_exponent<1..2^16-1>;
       } ServerRSAParams;

       struct {
           opaque dh_p<1..2^16-1>;
           opaque dh_g<1..2^16-1>;
           opaque dh_Ys<1..2^16-1>;
       } ServerDHParams;     /* Ephemeral DH parameters */

but Appendix A.4.2 has capitalized versions of the names.

    struct {
        opaque RSA_modulus<1..2^16-1>;
        opaque RSA_exponent<1..2^16-1>;
    } ServerRSAParams;

    struct {
        opaque DH_p<1..2^16-1>;
        opaque DH_g<1..2^16-1>;
        opaque DH_Ys<1..2^16-1>;
    } ServerDHParams;

Generally, the principle appears to be that field names should be
[mostly] lower-case, with capital letters reserved for type names,
so it's A.4.2 that should be changed.

And in A.4.3, the type definition for ClientKeyExchange refers to a
"DiffieHellmanClientPublicValue" type.  But this should actually
be "ClientDiffieHellmanPublic".
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 27 May 2005 20:51:21 +1200

Satoshi Akimoto <[email-masked]> writes:

>The terms like 'PKCS #1 block type x' are frequently used in 2246 and its
>bis, but they are no longer used in the current PKCS #1 or rfc3447. Wouldn't
>it be more explicit to use 'EME-PKCS1-v1_5' or 'EMSA-PKCS1-v1_5' instead? (it
>leaves a question for 'type 0' padding, though)

Far too many existing publications refer to PKCS #1 to simply drop it at this
point.  Perhaps the text could use both, with the alphabet-soup version in
parentheses after the more common term.  I've always found the alphabet-soup
terminology that seems to have been introduced by P1363 highly confusing, so
having both would be nice.

Peter.

---

From: EKR <[email-masked]>
Date: Fri, 27 May 2005 09:39:04 -0700

> having both would be nice.

I've discussed this with Russ and our plan is to provide references
to both 2246 and 3447 but in the interest of minimal spec changes
to use the old PKCS#1 1.5 terminology.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 May 2005 10:58:02 -0700

> <URL:http://www.imc.org/ietf-tls/mail-archive/msg04525.html>,
OK. I'll fix this.

> http://www.imc.org/ietf-tls/mail-archive/msg03983.html).

Right. I'll rewrite this.

> be "ClientDiffieHellmanPublic".

OK. 

-Ekr

---

From: EKR <[email-masked]>
Date: Tue, 31 May 2005 17:15:33 -0700

"Yngve Nysaeter Pettersen" <[email-masked]> writes:

> If such a record is received after the parties have started encrypting
> the  records, should it try to decrypt the data, or should the
> implementation  throw the record away immediately?

Well, for RC4 you have to at least skip ahead to the next
section of keystream. With the block ciphers in TLS 1.1 you
can just discard the record. Otherwise, I think it's implementation
dependent.

> Does this also apply to the 56 bit export ciphers that was defined
> just  before the export restrictions were eased? My reading of the
> document  indicates "Yes". But should not also the single DES suites
> (e.g.  TLS_RSA_WITH_DES_CBC_SHA) and perhaps also IDEA also be phased
> out in a  similar manner?

My read of this is no.

> performed a test where we released a Technology Preview version of
> Opera  with TLS 1.1 and TLS Extensions enabled. During this test our
> users  identified more than 120 services (including major banks) that
> did not  interoperate with a client using either TLS 1.1 or TLS
> Extensions, or  both. I have so far not been able to find out what is
> causing the problem.

You mean aside from noone actually implementing them? :)

Was there some other problem?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 May 2005 21:03:46 -0700

"Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]> writes:
> Yes. The mentioned servers (or their surround support systems) did not
> tolerate clients that used TLS 1.1, or TLS extensions, or both. The
> most  common response (but not the only one) to a Client Hello
> including one or  both of them is to shut down the connection, without
> any alert messages  whatsoever.
>
> There are a number of variations, some servers would accept either,
> but  not both; others would accept TLS 1.1 and extensions, but not TLS
> 1.0 with  extensions, and so on. I classified 5 major types of
> problems.
>
> Some minor variations also existed: One TLS 1.0 capable server
> actually  negotiated SSL v3 when the client asked for TLS 1.1. Another
> used an  incorrect version number (the negotiated) when checking the
> RSA Premaster  Secret.
>
> In one case I saw one server that initially only cut the connection
> when a  TLS 1.1 Hello was sent change to also cutting the connection
> when TLS  Extensions were used, a few weeks later.
>
> See the top post in
> http://my.opera.com/forums/showthread.php?s=&threadid=65055 for more
> examples.
>
> For those interested, Opera 8.0 ships with TLS 1.1 (it still support
> export ciphers) and TLS Server Name Extension support, both controlled
> by  the TLS 1.1 setting, which is disabled by default.

Hmm... That's too bad to hear. That said, I think the documentation
on what one is supposed to do is pretty clear, so I'm not sure
that more specification can help. 

-Ekr