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

  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

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. 