TCP Increased Security
charter-ietf-tcpinc-01

Good to see this happening.

Maybe a surfeit of words :-) For example:
"This work is part of the IETF effort to harness the Internet architecture"

In...
"The working group is looking to produce experimental documents specifying the required TCP extensions and any additional documents needed."
...I think that "any additional documents needed" could be a little open-ended especially as the text later identifies precisely three documents.

We should definitely do this, and the substance of the charter is good.

I have a bunch of mostly editorial comments:

I found this sentence very awkward and hard to parse:

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

NEW
This work will deal
with unprotected connections, and therefore will focus more on improvements
from a baseline of no security than on achieving the high standard of security
that is already available to users of authenticated TLS.

END

This sentence is *way* too long and convoluted:

OLD
Providing unauthenticated encryption and
integrity protection at the TCP layer will provide a set of features that cannot
be achieved with existing tools, namely, encryption and integrity protection
without modifications to the upper ayers (no API changes), encryption and
integrity protection with forward secrecy with a per-connection granularity,
simple NAT and firewall traversal capabilities, key rollover without significant
impact to the TCP connection, lower overhead compared to solutions relying in
stacking multiple protocols to achieve different features, no manual
configuration required.

Maybe this?:
NEW
Unauthenticated encryption and integrity protection at the TCP layer will
provide a set of features that cannot be achieved with existing tools.  Those
features include
- encryption and integrity protection without API changes or other modifications
  to the upper layers,
- encryption and integrity protection with forward secrecy with per-connection
  granularity,
- simple NAT and firewall traversal capabilities,
- key rollover without significant impact to the TCP connection,
- lower overhead compared to solutions that rely on stacking multiple protocols
  to achieve different features, and
- no requirement for manual configuration.

END

About the above list: is "forward secrecy" sufficiently well defined?

This is a charter, so it needs to say what *will* happen, not what you hope might happen:

OLD
The working group is looking to produce experimental documents specifying the
required TCP extensions and any additional documents needed.

NEW
The working group will produce experimental documents specifying the
required TCP extensions and any additional documents needed.

END

That said, why do you need to specify "experimental" here in the charter?  Shouldn't the target status be determined by the work?  Or do you really want to limit it to Experimental, and have to re-charter in order to make it Standards Track?  (And if so, why?)

In the "high-level requirements" list, the first bullet should break into two sentences, by changing "works over, in particular it must be" to "works over. In particular, it must be".  Also, make the final ";" into a ".".

In the second bullet, I can't pull this sentence apart: "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)."  Please rephrase it (and probably split it into two sentences).

"Must gracefully fall-back to TCP" should be "The protocol must gracefully fall-back to TCP", to be parallel with the other items.  There should be a "." at the end of the bullet.

The next bullet should end with a "." instead of with a comma.

In the next bullet, "Should attempt to use" is missing a subject; please add the appropriate one.

Similarly, the next bullet is also missing a subject ("Must not require"); please add.

The bullets that follow "When encryption is enabled, then the protocol:" should probably each end with a period.  That's not strictly right, but it's better than trying to tweak things otherwise.

I have not seen any answer to my questions on the IESG/IAB mailers, so let me ask again here.

- I was wondering whether Multipath TCP is in scope?
Multipath TCP appears only once in the charter, and it's not to clear (to me)

- "It should work over the vast majority of paths that unmodified TCP"
What does "unmodified TCP" mean?

And no milestones (I'll keep repeating this point for every new charter till the end of times)

I like Stephen's edit suggestion, it would be good if they could be incorporated.

Editorial nits only:

s/may not be changed/may not be able to be changed/;
s/e.g., like configure/e.g. configuring/
OLD:
- 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).
NEW:
- 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 able to 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., configuring encryption in an application).

s/would be present for/would be the case for/
OLD: 
- must allow the initiator of the connection to avoid fingerprinting: some
initiators may want to avoid appearing as the same endpoint when connecting to a
remote peer on subsequent occasions. This should either be the default or some
mechanism should be available for initiators to drop or ignore shared state to
avoid being fingerprintable any more than would be present for a cleartext
session.
NEW:
- must allow the initiator of the connection to avoid fingerprinting: some
initiators may want to avoid appearing as the same endpoint when connecting to a
remote peer on subsequent occasions. This should either be the default or some
mechanism should be available for initiators to drop or ignore shared state to
avoid being fingerprintable any more than would be the case for a cleartext
session.

I don't strongly care if you make these changes, but I think they improve the readability of the charter slightly.