Subject: TLS 1.1/1.2 impact on applications protocols

From: Chris Newman <[email-masked]>
Date: Mon, 29 Jan 2007 20:38:09 -0800

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?

                - Chris

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 30 Jan 2007 12:02:35 -0500

> -----Original Message----- 
> From: Chris Newman [mailto:[email-masked]] 
> 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? 
> 
> (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. 
> 

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-

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 31 Jan 2007 08:50:09 +1100

The language Scott references ("using the latest version supported by  
both parties") seems reasonable, but I think what's being asked for  
is for the latest version to automatically become MTI.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jan 2007 11:43:35 +0100

On 2007-01-30 22:50, Mark Nottingham wrote:
> both parties") seems reasonable, but I think what's being asked for is 
> for the latest version to automatically become MTI.

I can imagine that creating considerable confusion for people using
RFCs in procurement requirements and the like. Obviously it's highly
desirable from a security PoV, but if we make RFCs refer to variable
quantities, we create great complications for the consumers of
our work.

     Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jan 2007 08:54:52 -0500

> quantities, we create great complications for the consumers of

on the other hand, we don't really want to re-issue entire RFCs just to 
allow the incorporation of a new version of TLS, do we?

nor do I think it's reasonable to retroactively make a new version of 
TLS MTI for an existing RFC number.

it might be that the easiest way out is to issue some number of 
"profile" RFCs so that, for instance, RFC XXXX says "the version of FOO 
that conforms to RFC XXXX consists of an implementation that conforms to 
the requirements of RFC YYYY except that TLS 1.2 as described in RFC 
ZZZZ MUST be used rather than another version of TLS."

the downside is that we'd be tempted to use these "profile" RFCs as an 
excuse to list errata, and fixes for those errata, for each of those 
protocols. this would delay publication and adoption, and perhaps invite 
long drawn-out processes for second-guessing the original specification 
like the one we saw in DRUMS.  (not that I don't think DRUMS was a good 
thing to do, but there was a tremendous amount of second-guessing rather 
than just clarification, and I'm probably as guilty as anyone.  I guess 
it's a slippery slope between the two)

more broadly, I actually think that IF we can figure out how to avoid 
that kind of second-guessing, we should for each of our be periodically 
issuing a document that describes the applicability, current state of 
maturity and deployment, and errata and fixes for that 
specification...and that such documents should to some extent replace 
our current use of standardization status as a means of recommending or 
not recommending a particular protocol.  that might help us make a 
transition away from three stages (proposed, draft, full) to one or two.

Keith