Subject: [TLS] WGLC: draft-ietf-tls-srp-13

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

This is a Working Group Last Call for draft-ietf-tls-srp-13.

This document is intended for Experimental status. Please provide
comments to the authors and the list.

This WGLC will end Fri Jan 12 (to allow time for people's holidays).

-Ekr

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

---

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

Do ciphersuites  in the experimental range mean that they could be
reused by any other experimental protocol, or does IANA reserve values?

-- 
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: EKR <[email-masked]>
Date: Thu, 21 Dec 2006 11:37:47 -0800

> reused by any other experimental protocol, or does IANA reserve values?

IANA will reserve the values.

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Dec 2006 12:00:03 +0100

> This WGLC will end Fri Jan 12 (to allow time for people's holidays).

The document seems fine, but the intended status bothers me.  Changing
the cipher suite numbers because the document now targets experimental
status will disrupt deployed implementations and harms adoption of the
protocol.  Also, for this particular protocol, I believe its already
wide deployment suggests that PS is the appropriate choice.

However, as a general issue, it seems unfortunate that ciphersuite
numbers are tightly connected to the IETF standards track category.
If I recall correctly, successful documents on the Experimental track
may later be revised into Proposed Standards.  Will the ciphersuite
numbers then change?  This seems to be a general problem with the core
TLS specification, and doesn't seem to be fully thought out.

I suggest that for future TLS revisions, it should be considered
whether to remove the distinction of standards-track numbers and
non-standards track number, and that it becomes easier to have IANA
perform early allocation of TLS ciphersuite numbers to help
implementers test new TLS draft.

/Simon

---

From: Mike <[email-masked]>
Date: Tue, 26 Dec 2006 10:35:05 -0800

> implementers test new TLS draft.

I can see that it may be a good idea to remove the distinction
between standard track and non-standard track ciphersuite numbers,
but I'd like to see the private range retained.  I am actually
planning to use some private ciphersuites soon in an experiment.

Mike

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 28 Dec 2006 08:15:19 +0100

On Tue, Dec 26, 2006 at 12:00:03PM +0100, Simon Josefsson wrote:

> numbers then change?

Having separate ranges reserved for Standards Track assignments and
reserved for non-Standards Track ciphersuite assignments is meant to
prevent non-Standards Track documents from using up too much of the
total ciphersuite space.  So, unless there are incompatible changes to
the ciphersuite, there is no need to renumber if a ciphersuite
progresses from Experimental Track to Standards Track.  After all, the
Standards Track specification won't need to use cipher suite values
that are merely reserved: instead, it can continue to use the cipher
suite values that have already been assigned.

---

From: <[email-masked]>
Date: Thu, 28 Dec 2006 23:04:55 -0800

well done!

----- Original Message -----
> planning to use some private ciphersuites soon in an experiment.

(a) there is good basis now to define a class of "local" changeciphersuite 
values,
to allow signaling of per-ciphersuite customizations of the finished/final
process. I already gave the example of completing SSLv3 fortezza_dms
generation of sessionTEKs with the UKM processes for deriving key for
SSL connections, that could then control active state duplication (on the 
current,
multiplexed, or different TLS transport) and  session resumption (on a new
transport instance)

(b) we see GSSAPI-proposal basically introducing a mechanism-negotiation 
sub-protocol,
qualifying the negotiation of some nominal GSS ciphersuites essentially, for
PRF mechanisms and who knows what else, tomorrow. This same process could 
easily
now mandate the changeciphersuite value to be used, and thus key 
derivation(s) used
to create connection states, for each of the the 4 channels per SSL 
Connection
instance

(c) we see local ciphersuites being used, possibly to profile mainstream
ciphersuites (E.g facilitate SGC variant for std RSA ciphersuites). That is, 
do
IETF RSA, but don't do or perhaps add rule X on a renegotiation (e.g. use 
cache of
public keys  for server auth) when the capability negotiation from the 
GSSAPI negotiation
signals that a particular class of renegotiation is required, using "local
ciphersuite" local.X ...whose local-number and semantics is associated with 
some
GSSAPI mechanism oid (an unlimited size name space).