Subject: [TLS] Fwd: I-D ACTION:draft-rescorla-tls-extractor-00.txt

From: Badra <[email-masked]>
Date: Tue, 16 Jan 2007 16:32:31 +0100

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Jan 15, 2007 9:50 PM
Subject: I-D ACTION:draft-rescorla-tls-extractor-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : Keying Material Extractors for Transport Layer
Security (TLS)
       Author(s)       : E. Rescorla
       Filename        : draft-rescorla-tls-extractor-00.txt
       Pages           : 6
       Date            : 2007-1-15

  A number of protocols wish to leverage Transport Layer Security (TLS)
  to perform key establishment but then use some of the keying material
  for their own purposes.  This document describes a general mechanism
  for allowing that.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rescorla-tls-extractor-00.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-rescorla-tls-extractor-00.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-rescorla-tls-extractor-00.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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Wed, 17 Jan 2007 06:50:25 -0800

A number of protocols wish to leverage Transport Layer Security 
(TLS)
  to perform key establishment but then use some of the keying 
material
  for their own purposes.  This document describes a general 
mechanism
  for allowing that.

I think this is ok, in principle. This was always done. Its been 
done already, as shown now in the EAP-TLS I-D, for years. This 
and AEAP suggests a fair amount is being driven from IEEE WGs ( 
which are closed forums). One should assume a fully finished spec 
will eventually arrive, much like TLS Evidence, and be presented 
as a "new workitem" request to IETF, with a quick last call etc. 
I don't see anything particularly wrong with that, tho.

I do believe it does make sense in this era for TLS to a) 
parameterize the final KDF algorithm (the PRF function itself) b) 
parameterize the generation of the key block, much as used to be 
done based on the export flag for the ciphersuite, or the 
fortezza_dms SSLv3 ciphersuite. As Ive always said -  to some 
ugly barracking from a former IAB member once when discussing 
SSLVPNs and TLS - SSL transport is not limited to TCP.  It is not 
limited to any notion associated with TCP (half closes, SYN 
cookies, RR timestamping, 3168 signaling...), tho Ive seen 
value-added SSL engines that exploit these features.

There are lots of (good) uses, in my opinion. and of course the 
omnipresent abuse potential. Adding the handshake to help with 
generating keying material for the cores in internet multicast 
group management is appropriate. Its nice to see this area get 
worked on, again. (I think this area can do a lot better for voip 
than the ENUM direction based on DNS resolvers, and really 
exploit what the IP can REALLY do, when one lets rip.)

The work may well interfere with practices already in place for 
https 80 udp, but they are hardly mainstream. I used to apply the 
ChangeCipherSpec class of messages (defining my own) to "alter" 
the copying of keying material from the pending to active state, 
according to the custom semantics of my scheme. These days, its 
trivial to define an extension negotiation to agree to that new 
class of message support, of course.

Need to careful of IP issues, here. 
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls