Re: [secdir] SECDIR review of draft-ietf-t cpinc-tcpcrypt-07

[Stephen Kent <[e-mail]>]

Daniel,

> If you could let us know what protocols you mean, that would
> be a helpful point of comparison.  It looks like the main
> TLS 1.3 document specifies only five symmetric algorithms,
> but of course other documents could supplement this
> arbitrarily; I guess I should look at OpenSSL or something
> to see how many are actually supported.
My comments are based on my experiences with IPsec (ESP and AH). If you 
look at RFCs 4305,
4835,  and 7321, you see a set of algs that have been recommended, and 
ones that have been
deprecated over many years. There are a fair number of them when one 
looks at the need
to specify both an encryption alg and an integrity alg. We started with 
DEC-CBC and MD5,
moved on to triple DES-CBC and several SHA-based MACs, then AES-CBC (in 
3 key lengths) with
SHA MACs, plus AES-GMAC (3 key lenghts) and AES-GCM (3 key lengths).  
Don't forget outliers
like SKIPKACK, RC4, RC5, Blowfiosh, Twofish, Threefish, CAST, and IDEA. 
One might add Salsa20, ChaCha, Poly1305-AES to the list of more recent 
options, if anyone wanted to register them.
Note that even when we deprecate an alg it may live on for a long time 
in implementations.

> Concerning "nation-specific algorithms", do you mean that
> the number of needed symmetric-encryption algorithms could
> be on the same order as the number of countries in the
> world?
not likely, but potentially, and I would not like to have IANA rejecting 
a national
alg because of limited ID space. In the IPsec arena, we had SEED (South 
Korea),
GOST symmetric crypto and MAC algs (Russia), and Camilla (Japan) all 
defined for
use ion the IPsec environment. Nothing makes for a good international 
incident like
having the IETF reject some country's request for an alg ID.
> If there's a need to mention how the code-space for
> symmetric ciphers could be expanded, maybe we should
> seriously consider allocating 16 bits to this; I just don't
> have a good handle on the order of magnitude that is
> plausibly needed.
I'd prefer 16 bits, just to be safe, based on the IPsec experiences and 
a strong desire
to NEVER reuse IDs.

Steve