Re: [Tcpcrypt] New version of the charter text

thanks for the comments, replies below...

El 27/04/14 22:07, ianG escribió:
> Hi Marcelo
>
> On 23/04/2014 08:02 am, marcelo bagnulo braun wrote:
>> Hi,
>>
>> Thanks for the lively discussion on the charter text.
>> I attach a new version of the charter trying to include the received
>> comments.
>> I have tried to be carefull using the should and the must, so please
>> look into those.
>
> As this is a charter, I'm not sure MUST is appropriate with every thing
> we want.
>

I dont follow.
It is perfectly appropriate to have musts in the charter.
>> I tried to reflect the different levels of requirements for the
>> resulting protocol.
>> As usual comments are welcome.
>>
>>
>>
>> TCP Increased Security (TCP Inc.)
>>
>> The TCP Inc. WG will develop the TCP extensions to provide unauthenticated
>> encryption and integrity protection of TCP streams. The WG will define the
>> TCP extensions to perform an unauthenticated key exchange resulting in
>> encryption
>> without authentication.  This is better than plain-text because it thwarts
>> passive eavesdropping, but is weaker than using authenticated keys,
>> because it
>> is vulnerable to man-in-the-middle attacks.  This work is part of the IETF
>> effort to harness the Internet architecture given the latest events of
>> pervasive
>> monitoring (see draft-farrell-perpass-attack).
>>
>> The working group is looking to produce experimental documents
>> specifying the
>> required TCP extensions and any additional informational documents needed.
>
> It would be nice to have something about goals here.  Something like:
>
> We are looking for the designs that find the sweet spot between
> conflicting requirements:  to provide reasonable security for the
> majority of connections.  Because we are dealing with unprotected
> connections, we are more focussed on improving from baseline of no
> security than achieving the high standard of security that is already
> available to users of TLS.
>
sounds good to me

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

>> - 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... ;)
>
>
>> - Must not require any authentication or configuration from
>>    applications or users.  However, hooks for external authentication
>> must be
>>    made available.  The WG will not work on new authentication mechanisms.
>>
>> - The protocol must have acceptable performance.  For example, the
>> protocol may
>>    try to re-use existing cryptographic material for future communication
>> between the
>>    same endpoints to avoid expensive public key operations on connection
>> set up.
>>
>> - 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?

Regards, marcelo

>> - No extra linkability: when encryption is enabled the TCP traffic
>> should not
>>    give a third party observer any extra way to associate those packets
>> with the
>>    specific peers beyond information that would have been present in a
>> cleartext session.
>>
>> - Client fingerprinting: some clients may want to avoid appearing as the
>> same
>>    client when connecting to a remote peer on subsequent occasions.  This
>> should either
>>    be the default (clients cannot be "fingerprinted" by the server based
>> on shared state)
>>    or some mechanism should be available for clients to drop or ignore
>> shared state to avoid
>>    being fingerprintable.
>>
>> Security features at the TCP-level can benefit other TCP extensions.  For
>> example, both Multipath TCP and TCP Fast Open require proof that some
>> connections are
>> related.  Session resumption and Message Authentication Codes (MACs) can
>> provide
>> this evidence.  The working group should identify synergies and design the
>> security protocol in such a way that other TCP efforts can benefit from
>> it.  Of
>> course, TCP extensions that break must be identified too, and kept to a
>> minimum.
>>
>> The working group will produce the following documents:
>>
>> - A framework for unauthenticated encryption and integrity protection of
>> TCP connections.
>> This document will describe basic design considerations, including the
>> motivation and the
>> applicability of the proposed mechanism, the interaction with other
>> security mechanisms in
>> different layers of the stack, the interaction with external
>> authentication mechanisms, the
>> expected protection, privacy considerations and residual threats.
>>
>> - Extensions to current TCP to support unauthenticated key exchange and
>> encryption and
>> integrity protection. This covers all the protocol changes required.
>> This will be a
>> experimental document.
>>
>> - An extended API describing how applications can obtain further
>> benefits of the
>> proposed extensions. In particular, the hooks for supporting external
>> authentication
>> will be defined in this document and the hooks for disabling encryption.
>> This will be an informational document.
>
>
> some thoughts.
>
> iang
>
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>