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

[Daniel B Giffin <[e-mail]>]

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