Re: [Tcpcrypt] Initial questions

[Sandy Harris <[e-mail]>]

On Tue, Jun 24, 2014 at 10:45 AM, Stephen Kent <[e-mail]> wrote:

>> 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.
>
> To which X.509 cert infrastructure problems are you referring? Do you
> mean the Web PKI or PKI in general? IPsec, for example, does not make
> use of the Web PKI. Just curious.

I said SSL/TLS, implying the web. I think there are more general problems
in PKI -- see some of Peter Gutmann's comments, for example -- but
those are not relevant here.

>> 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.
>
> I'm not sure what your position is re alg agility, based on the paragraph
> above.

I wrote "OK, but ..".

> I can say that failure to accommodate alg agility will almost certainly
> cause the IESG to reject this as a standard, based on precedents
> for some time.

OK, we need some agility, both because it is a good safety measure
and because IESG will likely insist.

BUT the fewer choices there are, the simpler the protocol can be.
That has costs in "design, implementation, testing & auditing" &
extra options may mean a risk of downgrade attacks.

IPsec has a lot of arguably unnecessary complexity -- pre-shared
keys or public keys, main mode or aggressive mode, with or
without PFS, actual encryption or do the whole negotiation and
then use null encryption, ... Such things should be flatly rejected
here; just choose one secure option.

As for cipher suites, we need at least two to test the agility and
the negotiation part of the protocol. On the other hand, having
fewer makes it simpler. I conclude we should have exactly two
MUST implement algorithms per choice.

>> 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.
>
> why would one make the other AES finalists SHOULD? They didn't make the cut.

They are easy to add, patent-free and with open source software
readily available, and they have had lots of analysis. Maybe make
one a MUST (I'd pick Serpent) and the others MAY.

>> Key size? I'd mandate 128 bits everywhere to keep it simple.
>
> recall that AES has 256-bit keys as an option as a counter to possible
> quantum computing attacks. Why rule out that option?

The protocol can be simpler if it does not negotiate key size. Make it
256 everywhere, perhaps, but don't complicate the protocol.

If quantum attacks become feasible, my understanding is that
more-or-less everything we are likely to use would become
vulnerable: DH, RSA, ... We'd need a new version no matter
what symmetric ciphers were in play.

Anyway, this is an opportunistic encryption protocol which blocks
easy wholesale monitoring. Its essential goals do not include
resistance to more sophisticated attacks, whether MITM or
quantum.