Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-13.txt

From: [email-masked]
Date: Mon, 18 Dec 2006 15:50:01 -0500

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		: Using SRP for TLS Authentication
	Author(s)	: D. Taylor, et al.
	Filename	: draft-ietf-tls-srp-13.txt
	Pages		: 26
	Date		: 2006-12-18
	
This memo presents a technique for using the Secure Remote Password
   protocol as an authentication method for the Transport Layer Security
   protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-13.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-srp-13.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-srp-13.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: Peter Sylvester <[email-masked]>
Date: Tue, 19 Dec 2006 16:59:32 +0100

Hello,

it took me a while to discover that the new srp-tls draft contains:

      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD2 };

      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD3
      };

      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD4
      };

      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD5 };

      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD6
      };

      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD7
      };

      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD8 };

      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD9
      };

      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD10
      };

Does this mean that that the document is not supposed to proceed in 
standards track
according to TLS 1.1?

     2. Cipher suite values with first byte decimal 192 (0xC0) through
         decimal 254 (0xFE) inclusive are reserved for assignment for
         non-Standards Track methods.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 19 Dec 2006 16:31:39 +0000

A first version of the GSS-API draft is available from:
http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-00.txt

The title of this draft is wrong. Please ignore that error. A new draft 01 with a correct title has been submitted today.

I request on behalf of the editors that the TLS WG adopt this as a WG document.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 12:15:41 -0800

>          non-Standards Track methods.

Yes. This document is expected to proceed as Experimental.

-Ekr

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 21 Dec 2006 11:55:01 +0100

Hi,

Would you mind giving a little bit more detailed explanation in particular
what are the reasons why this cannot be on standards tracks, or what would
be necessary if it would be etc.

Thanks in advance
Peter

---

From: EKR <[email-masked]>
Date: Thu, 21 Dec 2006 07:41:19 -0800

> be necessary if it would be etc.

There are two reasons. First, as a matter of policy we are attempting
to move new work to Standards Track only where there is fairly strong
support for the work. In this case, the support for this work did
not appear to be particularly strong.

Second, the IPR issues surrounding all the ZKPP protocols are quite
murky and thus it would have required an affirmative decision by
the WG to move this document forward as a Proposed Standard
despite said issues. 

-Ekr

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 21 Dec 2006 18:10:48 +0100

> not appear to be particularly strong.
Several existing interoperable implementations exist. I think that this is
perfectly in the spirit of the IETF. If accepted as a standards track, 
the protocol
would probably directly directly go to draft.
> the WG to move this document forward as a Proposed Standard
Several have requested the document being forwarded.
I have not read any comment so far that is against the proposal except may
you in this comment.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Dec 2006 11:50:35 -0800

> would probably directly directly go to draft.

In a thread starting November 28, 2005, I asked for expressions of
support. I received three responses in favor of moving it forward
as PS, from you, Trevor Perrin, and Nikos Mavrogiannopoulus. Pasi
and I judged that this did not meet the bar of WG support for
a decision to move it forward at PS.

-Ekr

---

From: Tom Wu <[email-masked]>
Date: Thu, 21 Dec 2006 19:08:29 -0800 (PST)

> a decision to move it forward at PS.

Did my vote in favor of Proposed status not count?

   http://www1.ietf.org/mail-archive/web/tls/current/msg00401.html

Actually, my larger concern, as I raised in that message last year,
is why the "bar of WG support" appears to exclude the substantial
base of implementations, especially free/OSS ones, that have already
developed around the TLS/SRP spec.  I would think that the existence
of implementations, in several languages no less, and the support of
the associated implementors who have invested time/energy in solving
not just the technical problems but political/legal/IPR ones if
anything should carry more weight.

> -Ekr

Tom
-- 
Tom Wu
http://www-cs-students.stanford.edu/~tjw/

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Dec 2006 21:13:30 -0800

>    http://www1.ietf.org/mail-archive/web/tls/current/msg00401.html

My apologies, I miscounted when I wrote my response to Peter.
Pasi and I did, however, account for your opinion when we made
our decision about the document.

> anything should carry more weight.

Implementations are one indicator of support but they're not
the only one, and when Pasi and I asked the question directly
of the WG, the support was fairly weak, as I indicated in my
previous message.

-Ekr

---

From: Tom Wu <[email-masked]>
Date: Thu, 21 Dec 2006 23:00:05 -0800 (PST)

> of the WG, the support was fairly weak, as I indicated in my

Ok, but reading between the lines, it seems as though strong
implementation support is still being disregarded.  You could just
as easily have said "Although there wasn't a strong response on the
WG mailing list, SRP enjoys strong implementation support" as a
rationale for Proposed Standard.  The way you phrased things implies
that WG vote is the only thing that matters, or at the very least
overrides other factors.

Out of curiosity, what kind of WG support did the Camellia ciphersuites
(RFC 4132) enjoy when it came up for vote?

Tom