Re: [Tcpcrypt] Initial questions

[marcelo bagnulo braun <[e-mail]>]

below...

El 18/06/14 23:15, Sandy Harris escribió:
> 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"?

I replied to this in a separated email

> As others
> have said quite eloquently in various posts, there is no reason at all
> to even consider a null encryption mode;

The requirement for disabling encryption was removed from the charter.
The text above refers to the case when a TCPINC host is talking to a 
legacy host.

> 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.

Right, this needs more discussion. The other side of the coin is that if 
you dotn provide agility and a vulnerability is found in an algorithm, 
then you are in bad shape. So, i agree, we need to find the way to 
provide agility with minimum complexity (not sure if we will be able to 
make it simpler than what is already out there though)

>
> 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.

mmm, the problem with securing the header is not about the performance 
of signing the header but about the impact to other aspects.
In particular, how this interacts with middleboxes? Clearly you cant 
protect the IP address and the ports as it would break nat 
compatibility. what about the other fields? well, there are some other 
boxes out there that do funny things with seq numbers (boxes coalescing 
segments), do we want to be compatible with those or not?
The other aspect realted to this is where we carry the MAC for each 
segment, in the payload or in an option? Do we have room in options to 
carry this for every segment? wouldnt people rather have more sack 
blocks? If we go for carrying the MAC in the payload, then it is much 
harder to secure the header. Again, all these are discussions we need to 
have. I personally dont have a clear position, i just dont find it 
obvious (i know some of you do)

> 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.

The main issue addressed here is incremental deployment. In early phases 
of deployment, a host needs to be able to communicate with legacy hosts. 
When wider deployment is available it can have stringent policies, i guess.

Regards, marcelo