Subject: Re: [saag] Cipher suite proliferation

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Sep 2010 17:12:33 -0400

It is certainly a problem. What happens when someone comes along
wanting to show how to use BROKEN with S/MIME. Do we really want a
standards track RFC to issue? Like it or not, a standards track RFC is
an endorsement of the algorithm.

Some of these crypto requests are for vanity crypto. Others have
serious political and/or business rationales. There are good reasons
for stating how to use the crypto but we are in no position to
evaluate its strength.

Another related problem we have is that a lot of our standards mandate
the crypto algorithms of the date they were specified rather than
contemporary standards.

I would like it to have as few obstacles as possible put in the path
of people proposing to use SHA-2 or the new SHA-3 with legacy
algorithms. I would also like to have a general statement that
protocols should regard 2048 bits as a minimum for RSA and that they
should support AES.

Unless there is something weird in the protocol definition, an
algorithm specification should not be much more than specifying a code
point and giving some examples. If it takes anything more we have
problems.

One point to consider is whether we need 16 documents per algorithm,
one for each major protocol or if some or most of these documents
could be combined.

I suggest that we recognize the fact that the IETF has adopted a set
of core cryptographic algorithms that are generally regarded as MUST
for the protocols currently being agreed and have a way to backdate
them to prior standards.

Only core algorithms and algorithms discussed in WGs would
(ordinarily) be eligible for standards track documents.