[Tcpcrypt] Initial questions

[Sandy Harris <[e-mail]>]

This is basically a fine idea & I'm glad to see people working on it.

Some comments in the archive had me somewhat worried, and the current
draft charter has the following:

- When encryption is enabled, it must at least provide protection against
  passive eavesdropping by default,
...
When encryption is enabled, then the protocol:
- must always provide forward secrecy.
- must always provide integrity protection of the payload data ...
- must always provide payload encryption.

Why on Earth do these have "When encryption is enabled"? As others
have said quite eloquently in various posts, there is no reason at all
to even consider a null encryption mode; anyone who needs that can
just fall back to TCP.

I'd go further. At a bare minimum, reject the insecure things
FreeS/WAN refused to do 15 years ago even though they were in the
IPsec RFCs -- single DES, small DH groups and null encryption.
http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/compat.html#dropped

Probably today we should go much further. No MD5 or SHA1 since there
are known problems. No 3DES since newer ciphers are far faster. No
reliance on the whole X.509 cert infrastructure SLL/TLS uses; that
also has known problems. I'm not sure what else.

The draft charter also has:

- The protocol must provide cryptographic algorithm agility.

OK, but there is a balance to be struck. IPsec & TLS both have
problems from arguably excessive complexity and in general complexity
is the enemy of security. It makes all of design, implementation,
testing & auditing much harder. TCPcrypt has a rather narrow niche to
fill; that can be done with a fairly simple protocol. We really must
strive to keep it simple.

Here's a first cut at what we might support:

Block ciphers: MUST do AES. SHOULD do the other three AES finalists
with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers
which are national standards: Aria for Korea, Camellia for Japan,
maybe others. Nothing else.

Overhead for those is minimal since they all have same block size as
AES and same range of key sizes, so they are drop-in replacements.
Also, all the AES candidates and Aria have readily available open
source code; I have not checked for Camellia.

Key size? I'd mandate 128 bits everywhere to keep it simple.

Authentication: The draft has:

- must always provide integrity protection of the payload data (it is open for
  discussion for the WG if the TCP header should or not be protected)

AEAD (authenticated encryption with additional data) algorithms have
partly replaced the cipher+HMAC combination in both IPsec and TLS.
They are often faster, and the "additional data" feature would let us
protect the TCP header at negligible extra cost. I'd say they are
obviously what we should use.

I'd just take two with existing RFCs -- AES-GCM RFC 5288 and OCB RFC
7253 --  and make them both MUST. Leave HMAC out to keep it simple.

The draft also has:

- Must gracefully fall-back to TCP if the remote peer does not support the
  proposed extensions

Aren't there a set of policy questions there? Some users might prefer
to drop the connection rather than communicate insecurely. Perhaps
they need a mechansim to set policy, globally and/or on a
per-connection basis. FreeS/WAN had something like this for IPsec over
a decade ago:
http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html

At an absolute minimum, I think there must be a requirement that any
fallback action is logged.

Another question is whether we could achieve the goals of this group
with almost no work just by deploying existing stuff.

The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than
nothing security", which they implemented as an unauthenticated mode
for IPsec. That sounds much like what we are aiming at. Can we just
work on getting BTNS deployed, thereby protecting both TCP and other
protocols?

The draft has:

- Must not require any authentication or configuration from
applications or users. However, hooks for external authentication must
be made available.

RFC 4322 describes an authentication mechansim for IPsec opportunistic
encryption using keys stored in DNS. Could we make that the external
hook and fall back to BTNS if the right record is not found?

Even if we choose to avoid the complexity of IPsec and design
something specifically for TCP instead of just using BTNS, the idea of
using DNS for keys may be useful. I do not know details, but it looks
as though the DANE working group is doing this sort of thing:
https://datatracker.ietf.org/wg/dane/