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

["Black, David" <[e-mail]>]

Stephen,

> > > > Section 6 defines the initial set of AEAD algorithms supported by tcpcrypt,
> > > > in Table 2. Each algorithm is assigned a value in the 1-255 range, a much
> > > > smaller range of values that used in protocols like TLS. The

This does not appear to be a significant problem in practice - a quick scan of the TLS ciphersuite registry (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) turns up less than half-a-dozen encryption algorithms that appear to be nation-specific.

The two primary reasons for the massive size of that TLS registry are:
	a) a bunch of obsolete cr*p that SHOULD NOT be used (e.g., RC4, DES and  EXPORT ciphersuites); and
	b) the combinatorics of registering all the possible TLS ciphersuites, courtesy of the number of components in a TLS ciphersuite.
Neither of those apply to tcpcrypt.

The IKEv2 Transform Type 1 - Encryption Algorithm Transform IDs registry (https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-3) appears to be a better example for this analogy - it has less than 30 values assigned.  I'd suggest adding one sentence to point out the following:

> > > Well, although the code-space used by tcpcrypt is small,
> > > TCP-ENO is a big escape-hatch in terms of extensibility.

Thanks, --David

> -----Original Message-----
> From: Daniel B Giffin [mailto:[e-mail]]
> Sent: Tuesday, October 24, 2017 3:08 AM
> To: Stephen Kent <[e-mail]>
> Cc: [e-mail]; Black, David <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: SECDIR review of draft-ietf-t cpinc-tcpcrypt-07
> 
> Hi Stephen et al.,
> 
> Below is some discussion about the number of bits devoted to
> negotiating the symmetric cipher (currently eight for
> tcpcrypt) ...
> 
> Stephen Kent wrote:
> > > > Section 6 defines the initial set of AEAD algorithms supported by
> tcpcrypt,
> > > > in Table 2. Each algorithm is assigned a value in the 1-255 range, a much
> > > > smaller range of values that used in protocols like TLS. The text in
> Section
> > > > 7 might need to remind readers that this will argue against the
> registration
> > > > of “vanity” AEAD algorithms for tcpcrypt.
> > > Hm yes, I see that TLS 1.3 uses a two-byte identifier for a
> > > similar purpose, although it looks like this specifies both
> > > an AEAD algorithm and an HKDF.
> > >
> > > Well, although the code-space used by tcpcrypt is small,
> > > TCP-ENO is a big escape-hatch in terms of extensibility.
> > > For example, tcpcrypt could be extended with additional TEPs
> > > whose only difference is to map the symmetric-cipher
> > > identifier-bytes to different meanings.  Not the prettiest
> > > solution, but perhaps acceptable if one is optimistic that
> > > exhaustion is unlikely anyway?
> > We've seen nation-specific algorithms proposed as optional for use with a
> > number of
> > security protocols, which is why I mention this issue. An allusion to the
> > potential
> > to expand this space, if needed, would be useful here.
> 
> 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.
> 
> 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?
> 
> 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.
> 
> daniel