Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Stephen Farrell <[e-mail]>]

Hiya,

On 26/08/15 16:47, Mirja Kühlewind wrote:
> Hi Stephen,
> 
> just to double-check if I understand correctly what you are saying:

I don't think we're saying the same thing. My fault probably, but
I'll try again below:-)

> 
> You basically say that you would not support the tcp-eno approach
> because you would like to have for any tcpinc protocol (not matter if
> tcp-use-tls or tcpcrypt) only a very simple negotiation in a TCP
> option where both ends confirm that they support tcpinc and then all
> additional negotiation is done in the payload data space (and
> therefore an own document is not needed)?
> 
> What’s about the argument, that I believe you’ve stated earlier
> yourself, that one could use tcp-eno to update to a new protocol
> version (not only a new cipher) in case we detect flaws in the
> general protocol design…? If you think this is useful to have, would
> it then make then to have an own document for it (and potentially
> take the tcp-eno proposal as a starting point)?

Until the WG have selected between tcpcrypt and tcp-use-tls
I don't think it makes any sense for tcp-eno to delve into
ciphersuite or cryptographic algorithm details.

After the WG have selected tcpcrypt or tcp-use-tls:
- if the WG pursue only tcpcrypt it may make sense to handle
  algorithm agility in a TCP option (I'm not sure if it would
  or not but it'd be worth a look)
- if the WG select tcp-use-tls I don't think it makes sense
  to try handle any algorithm agility in a TCP option

The reason is that adding ciphersuite details into tcp-eno when
tcp-use-tls might be used could mean negotiating the same thing
twice, once in a TCP option and the 2nd time in the TLS handshake.
That seems like a bad idea that could create potential new
vulnerabilities, or at least confusion, bugs and possible lack
of interop.

If tcp-eno is only negotiating (or indicating) that tcpcrypt or
tcp-use-tls will be used, or that version-N of one of those will
be used, that could work, but I'm not so keen on it as it might
move the wg towards pursuing both tcpcrypt and tcp-use-tls in
the longer term, and I think one of the things on which the wg
did have consensus was that tcpinc would be based on only one
of those and that the wg would not continue to work on both
options beyond the next IETF meeting.

Does that help?

Cheers,
S.



> 
> Mirja
> 
> 
> 
> On 25.08.2015 22:03, Stephen Farrell wrote:
>> 
>> On 25/08/15 17:54, David Mazieres wrote:
>>> TCP-ENO is an effort A) to make progress on common elements of
>>> TCP-use-TLS and tcpcrypt,
>> 
>> The above is reasonable.
>> 
>> ...
>>> Well, in order to make the choice between tcpcrypt and
>>> TCP-use-TLS the most salient, it seems worth maximizing the
>>> advantages of the two protocols.
>> 
>> I think your goal (A) and "maximising the advantages" of tcpcrypt 
>> (or of TLS) are incompatible goals at this point in time.
>> 
>> If/when the WG adopt tcpcrypt optimisations relating to algorithm 
>> agility will inevitably be explored. If/when the WG adopt TLS that 
>> kind of change wouldn't make sense.
>> 
>> In the meantime trying to squeeze discussion of loads of different 
>> things into discussion about TCP-ENO seems mostly a distraction.
>> 
>> S.
>> 
>> _______________________________________________ Tcpinc mailing
>> list [e-mail] https://www.ietf.org/mailman/listinfo/tcpinc
>> 
>