Re: [Tcpcrypt] Initial questions

[ianG <[e-mail]>]

On 18/06/2014 22:15 pm, Sandy Harris wrote:
> 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:


my 2c below.

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


Perhaps we can change the text to say more about what is meant:

   When TCPCRYPT mode is enabled, the protocol will provide a good stab
at the following:

  - must PFS
  - must integrity
  - must encrypt payload, and must block passive eavesdropping

etc.


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


I don't think we need to enumerate the current fads on algorithms.
Everyone knows what is old and tired.  Currently the fad is
ChaCha20/Poly1305.  But in 3 years the new fad will be a CAESAR winner.
 Leave the WG some room to move with the times.


> The draft charter also has:
> 
> - The protocol must provide cryptographic algorithm agility.


As previously written (ranted?), I'm adamantly against any such thing.
IMHO the protocol should provide precisely one and only one whole cipher
suite;  the truth, the whole truth and nothing but the truth!

For any issues that might arise, change the protocol.  Entirely.  You
will anyway ... so we need a way to negotiate the protocol number, from
1 to 2 to 3, etc.


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


Nothing gets simpler than the ONE!


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


Even if I agreed with the above, I'd say, this is the job of the WG, not
to be listed in the charter at all.  Too low level.


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


This is all the job of the WG, to come up with a suite.  Keep that
competition out of the charter, let the WG also have their fun ;-)

> 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


Well, we want this stuff to spread like the plague.  So, I'd keep policy
well away from users.  Any switch provided to users just has a habit of
branching decision trees, interfering with something else in their daily
lives, and potentially causing the whole shebang to be switched off
until it works.

E.g., if there is to be some policy discussion I would frame it in these
terms for the charter:

  - there is to be zero confuguration load for the sysadm/user

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

Oh, sure.  That's like remembering to put air in tires, no need to say
that in the charter.

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


If it fits the charter, then let it be proposed -- in the WG ring.
Let's have a nice clean fight, no hitting below the belt, ...

Especially, I'd like a fast knockout in round 1.  If we can slide in
BTNS for the TCPCRYPT v1, and then have a better, later-gen
bells&whistles proposal for v2, then we could win twice over.


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


Any external hook, that included?  That is, it is beyond scope how that
is done.  The point is to allow a later TLS drop-in replacement to
bootstrap over TCPCRYPT and allow a fuller authentication to work.


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


Yep, but out of scope to specify which.  Only need would be to keep an
eye on the ways and make sure there are no snafus.



iang