Re: [Tcpcrypt] New version of the charter text

[ianG <[e-mail]>]

On 27/04/2014 21:43 pm, marcelo bagnulo braun wrote:

>>> The high-level requirements for the protocol for providing TCP
>>> unauthenticated
>>> encryption and integrity protection are:
>>>
>>> - Deployable and usable without significant changes to existing Internet
>>>    infrastructure, in particular it must be compatible with NATs (at the
>>>    very minimum with the NATs that comply with BEHAVE requirements as
>>> documented
>>>    in RFC4787, RFC5382 and RFC5508);
>>>
>>> - The protocol must be usable by unmodified applications.  This effort
>>> is complementary
>>>    to other security protocols developed in the IETF (such as TLS) as it
>>> protects
>>>    those applications and protocols that are difficult to change or may
>>> even not
>>>    be changed in a backward compatible way.  It also provides some
>>> protection in
>>>    scenarios where people are unwilling to do any change just for the
>>> sake of
>>>    security (e.g., like configure encryption in an application).
>>>
>>> - When encryption is enabled, it must at least provide protection
>>> against
>>>    passive eavesdropping by default,
>>
>> So, in the above, we see the "When encryption is enabled," which is
>> repeated through out.  I would suggest this immediate above para be
>> swapped with the below para, as then the flowchart is more clear.  Then,
>> that phrase be dropped because it is an implementation detail.
>>
>> Like this:
>>
>>
>> - If encryption cannot be achieved, must gracefully fall-back to TCP.
>>
>> - Elsewise,


Perhaps here, insert:

Elsewise, all the following apply:


>> must at least provide protection against passive
>> eavesdropping by default,
>>
>> - must ...
>>
> 
> In the first version of the charter it was not explict that these things
> were required when encryption is enabled, and i received several
> comments about it, so i made it explicit. I think it is more imprtnat
> for the charter to be clear than to read nicely, so i think we should
> keep it.


Well, the point of putting the fall-back first is that there are two
modes of operation:  passthru and ENCRYPTED.  On starting up, the
protocol can enter either of these two states, but not transition
between them.  This choice dominates all to follow [0].

Then, for ENCRYPTED mode, all of the additional points apply.  For
passthru mode, none of the additional points apply.  So it's easier to
have the passthru mode listed first, then disposed of as far as further
writing is concerned.


>>> - Must gracefully fall-back to TCP if the remote peer does not
>>> support the
>>>    proposed extensions
>>>
>>> - When encryption is enabled, it must always provide forward secrecy.
>>>
>>> - When encryption is enabled, it 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)
>>>
>>> - When encryption is enabled, it must always provide payload encryption.
>>>
>>> - Should attempt to use the least amount of TCP option space.
>>
>> All of those above, and some below, are the sort of thing that any
>> protocol is going to aim for anyway.  They could be simply collapsed
>> into something like:
>>
>> - should provide the best mix possible of the following features:
>>     - forward and backward secrecy
>>     - encryption and integrity protection over the payload
>>     - most efficient use of the TCP option space
>>     - efficient performance, including restart using previously exchanged
>> keys
>>     - minimise scope for linkability and fingerprinting
>>     - synergies with other aspects such as multipath and fast open.
> 
> mmm, but the problem si that you are not making distinctions between
> thing we want to be mandatory (encryption) and other things that we
> would like but it is not clear how much we will achieve (like efficient
> use of option space ). To make a very silly example, if we dont do
> encryption, we do a very optimal use of the option space, but that is
> not what we want.
> 
>> Otherwise you're sort of teaching grandma to suck eggs, which is right
>> to do in a WG but not in the charter... ;)


This bit above!  If we need to remind someone doing a mandatory
encryption in a security protocol, then we've got another problem and we
shouldn't be in the job :)

Hence the early objections to the kill switch.


...
>>> - Hooks for allowing upper layers to disable encryption must be made
>>> available.
>>>    The protocol may try to avoid redundant encryption when it is
>>> possible
>>> e.g.
>>>    by detecting encryption performed by upper layers (notably, when TLS
>>> is used).
>>
>> Disagree.  The protocol may have it in there (sad!), and devs will have
>> this in their code for development phase, but mandating it is just
>> opening a can of worms.  Especially in the charter.
> 
> You think this should be a should?


Well.  I think the RFC should list it as a MAY so that people who read
it can be alerted to the fact that they had better figure out how this
happens and make sure it never happens on their watch.

I don't think it should be a SHOULD because I've yet to see a valid
reason for it.  All of the reasons so far presented have been handwavy,
very edge-case or development only.

And I don't see its place in the Charter.  It seems like cursing the
baby before its been born.



iang


[0] I am assuming these two exlusive modes.  This could be challenged.