Re: Comments on Mandatory Ciphers and a Proposal

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> > I don't think so.  The "MUST implement" ciphersuites are defaults, to
> > be used with most protocols.  That doesn't meen that they're deemed
> > adequate for all purposes, and a particular application that uses TLS
> > might want to specify some other mandantory set of ciphersuites *for
> > use with that application*.

> 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.

Demonstrating that this is entirely possible under IETF rules is easy since
there are cases where exactly this sort of thing has already been done. For
example, consider the voice messaging profile of SMTP/MIME. This specification
specifically changes the support requirements for some things specified as
mandatory in the base MIME specification to optional (e.g. text/plain) and
makes support for some things not even mentioned in the MIME specification
mandatory (e.g. new subtypes of audio). The reasons these changes had to be
made are obvious if you consider the nature of the specialized hardware in a
voice messaging system. But equally obvious are the reasons why support for
text/plain had to be a mandatory part of the base MIME specification.

I will also add that the MIME application space also offers examples of how one
IETF protocol can include another but in the process change the first protocol
in substantive ways. HTTP does exactly this with MIME -- it changes the rules
for text line terminators so as not to agree with what MIME mandates and it
also changes various parameter defaults away from what MIME specifies.

> As far as I understand the
> previous official response from the IESG and the more recent informal
> word from Jeff S., TLS-compliant applications could not specify a
> different set of mandatory-to-implement ciphersuites unless they
> were to include all the base TLS mandatory-to-implement ciphersuites.

Well, Keith Moore is an application area co-director and hence on the IESG, and
he just said the exact opposite of this. It also certainly wasn't the
understanding *I* took away from either the original IESG response or from
Jeff's followup. In fact on a procedural level I don't see how the IESG could
ever require such a thing -- protocols can always be revised and one
specification is always free to update another in whatever fashion it chooses.

				Ned