Re: TLS 1.1/1.2 impact on applications protocols

[Keith Moore <[e-mail]>]

> On 2007-01-30 22:50, Mark Nottingham wrote:
>> 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.
> 
> 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.

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