Re: [Tcpcrypt] Initial questions

[Joe Touch <[e-mail]>]

Comments on your other points:

On 6/18/2014 2:15 PM, Sandy Harris wrote:

As to the specific algorithms and how many, we probably all agree that a 
small number of required algorithms is preferable. I think 2 is a good 
upper bound on the MUST algorithms, though.

Algorithm agility just means that the protocol isn't inherently 
dependent on any one algorithm, so that it can be extended in the future 
to support other algorithms - that seems prudent.

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

If you don't protect the header, IMO you're not doing TCP security, and 
might as well use TLS.

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

Gracefully != silently

Gracefully != without regard for policy

I think the intent of the requirement is that graceful fallback needs to 
be supported, but not that it is either silent or the default - 
especially for associations indicated as preferring/requiring TCPCRYPT.

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

That's certainly one possibility, but IPsec protection isn't quite the 
same as TCP-level. IPsec won't create new keying material for each TCP 
connection, whereas a TCP-level solution might. IPsec solutions also 
often required tunneling over UDP for NAT traversal, whereas a TCP 
solution might not (e.g., if the TCP header is protected but not encrypted).

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

It's possible, but TCP currently doesn't consult the DNS directly; 
inserting this dependence in a TCP-layer protocol could introduce 
additional delays.

Joe