RE: TLS 1.1/1.2 impact on applications protocols

["Scott Hollenbeck" <[e-mail]>]

> -----Original Message----- 
> From: Chris Newman [mailto:[e-mail]] 
> Sent: Monday, January 29, 2007 11:38 PM 
> To: Apps Discuss 
> Cc: Pasi Eronen; Eric Rescorla 
> Subject: TLS 1.1/1.2 impact on applications protocols 
> 
> The changes that are happening in the TLS WG with the 
> publication of TLS 1.1 and the upcoming TLS 1.2 do have a 
> significant impact on application deployment.  Many of our 
> application protocols make TLS 1.0 mandatory-to-implement.  
> I'd like to see a discussion of the importance of transition 
> to 1.2 (when it comes out) and the real-world problems that 
> might occur.  Do we need to update our application protocol 
> specifications to mandate the newer version?  Or perhaps we 
> need an app-area RFC which does that to a set of application 
> protocols? 
> 
> Can we just have a blanket exception to the standards status 
> (proposed/draft/full) reference rules for the TLS base spec 
> (and trust the TLS WG to do the right thing)?  It seems more 
> important to keep up-to-date on security technology than to 
> have normative reference purity. 
> 
> Perhaps this would be a good topic for the Prague apparea meeting? 

I just ran into this very situation in the process of bringing EPP (RFCs
3730 - 3734) to Draft.  The IESG was OK with a normative downward reference
to TLS 1.0 and some additional text to note that the work is still evolving.
Here's what we agreed to say:

"When layered over TCP, the Transport Layer Security (TLS) Protocol version
1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), using the
latest version supported by both parties, MUST be used to provide integrity,
confidentiality, and mutual strong client-server authentication."

The reference to 2246 is normative; a downref note and exception processing
was required.  The reference to 4346 is informative.  This approach worked
because EPP does not depend on any version-specific features of TLS.  The
situation may well be different for other protocols.

-Scott-