Re: Comments on Mandatory Ciphers and a Proposal

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

> From: Ned Freed <Ned.Freed@xxxxxxxxxxxx>
> 
> > Specifying any mandatory-to-implement ciphersuite does not allow the
> > designers of a higher-level protocol with stringent code space
> > requirements to implement _only_ one or two ciphersuites whose
> > implementation happens not to be mandated.
> 
> I'm sorry, but this is simply not the case. In fact not only is this possible,
> it is procedurally quite trivial: You write a document profiling the use of the
> application protocol of your choice over TLS in some specific sort of
> environment (tight code space requirements, limited processor power,
> specialized hardware support for specific ciphers, requirements imposed from
> outside the IETF that force certain cipher choices, etc. etc. etc.)  and put it
> on the standards track. This document could even go so far as to change all the
> ciphersuite MUSTs to MUST NOTs and add a set of entirely new MUSTs if in fact
> that was the appropriate thing to do. As I say, this is procedurally quite
> elementary -- the only thing that's often hard is knowing what to put in the
> profile and getting agreement on it.


The fact that procedurally it is possible for one RFC to modify or
replace sections of another RFC does not mean that it is desirable to
do so.  It would be far better to design the first RFC in such a manner
that it could be incorporated into subsequent documents *without*
modification.

Two methods of achieving clean reuse have been proposed:

1) Have the Technical Standard for TLS and the Applicability Statement
   for particular ciphersuites appear in separate RFCs, and

2) Allow the TLS Applicability Statement be reused without overriding it
   by designating the preferred ciphersuites as SHOULDs instead of MUSTs.

Most of the TLS working group is in favor of option 2 (although I would
like to hear the opinions of those who haven't chimed in yet - Dan Simon,
Tatu, ekr, eay (who probably isn't reading email while on vacation :-),
Paul Hoffman, etc.).

The folks with Innosoft addresses and the IESG don't like option 2.

Assuming that reaching agreement between the IESG and the WG on option 2
will be a protracted process, perhaps leading to stalemate, what do folks
think about option 1?  Although I strongly disagree with having MUST
requirements at all, for the reasons previously discussed, I could live
with them if they were explicitly separated from the TLS Technical Standard.