TCP Increased Security
charter-ietf-tcpinc-01

WG review announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: tcpinc WG <tcpcrypt@ietf.org> 
Subject: WG Review: TCP Increased Security (tcpinc)

A new IETF working group has been proposed in the Transport Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-15.

TCP Increased Security (tcpinc)
------------------------------------------------
Current Status: Proposed WG

Technical advisors:
  Stephen Farrell <stephen.farrell@cs.tcd.ie>

Assigned Area Director:
  Martin Stiemerling <mls.ietf@gmail.com>

Mailing list
  Address: tcpcrypt@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt
  Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/

Charter:

The TCPINC WG will develop the TCP extensions to provide unauthenticated
encryption and integrity protection of TCP streams. The WG will define 
an unauthenticated key exchange mechanism. In addition, the WG will 
define the TCP extensions to utilize unauthenticated keys, resulting in 
encryption and integrity protection 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 during the initial unathenticated key exchange. 
This work is part of the IETF effort to evolve the Internet architecture 
given the latest events of pervasive monitoring (see BCP 188).

The goal of this WG is to provide an additional security tool that
complements existing protocols at other layers in the stack. The WG will 
be looking for the designs that find the right tradeoff spot between 
conflicting requirements: to provide reasonable security for the 
majority of connections.  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.

Providing 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 modifications to the upper
  layers (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.

A more detailed description of the motivations for TCP-based solutions
can be found in draft-bellovin-tcpsec-01 and in RFC5925.

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

The high-level requirements for the protocol for providing TCP
unauthenticated encryption and integrity protection are:
- It should work over the vast majority of paths that unmodified TCP
  works over, 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 able to be changed in a 
  backward compatible way.  It also provides some protection in 
  scenarios where application developers are unwilling to change their 
  applications (e.g., by configuring encryption) solely for the sake of 
  improving security.

- The protocol must provide cryptographic algorithm agility.

- The protocol must gracefully fall-back to TCP if the remote peer does
  not support the proposed extensions.

- When encryption is enabled, it must at least provide protection 
  against passive eavesdropping by default,

- Any required TCP option should use a minimum amount of TCP option
  space, especially in SYN segments.

- The protocol 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, including acceptable
  latency and  processing overheads.  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.

When encryption is enabled, then the protocol:

- must always provide forward secrecy.

- must always provide integrity protection of the payload data (it is
  open for discussion for the WG if the TCP header should or should not 
  be protected).

- must always provide payload encryption.

- must not provide 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.

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

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.

- Definition of the unauthenticated key exchange mechanism and the
extensions to current TCP to utilize unauthenticated key to provide 
encryption and integrity protection. This covers all the protocol 
changes required. This will be an 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. 
This will be an informational document.

Milestones:

TBD

WG action announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: tcpinc WG <tcpinc@ietf.org> 
Subject: WG Action: Formed TCP Increased Security (tcpinc)

A new IETF working group has been formed in the Transport Area. For
additional information please contact the Area Directors or the WG Chair.

TCP Increased Security (tcpinc)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Marcelo Bagnulo <marcelo@it.uc3m.es>

Technical advisors:
  Stephen Farrell <stephen.farrell@cs.tcd.ie>

Assigned Area Director:
  Martin Stiemerling <mls.ietf@gmail.com>

Mailing list
  Address: tcpinc@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/tcpinc
  Archive: http://www.ietf.org/mail-archive/web/tcpinc/

Charter:

The TCPINC WG will develop the TCP extensions to provide unauthenticated
encryption and integrity protection of TCP streams. The WG will define 
an unauthenticated key exchange mechanism. In addition, the WG will 
define the TCP extensions to utilize unauthenticated keys, resulting in 
encryption and integrity protection 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 during the initial unauthenticated key exchange. 
This work is part of the IETF effort to evolve the Internet architecture 
given the latest events of pervasive monitoring (see BCP 188).

The goal of this WG is to provide an additional security tool that 
complements existing protocols at other layers in the stack. The WG will 
be looking for the designs that find the right tradeoff spot between 
conflicting requirements: to provide reasonable security for the 
majority of connections.  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.

Providing 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 modifications to the upper 
  layers (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.

A more detailed description of the motivations for TCP-based solutions 
can be found in draft-bellovin-tcpsec-01 and in RFC5925.

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

The high-level requirements for the protocol for providing TCP 
unauthenticated encryption and integrity protection are:
- It should work over the vast majority of paths that unmodified TCP 
  works over, 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 able to be changed in a 
  backward compatible way.  It also provides some protection in 
  scenarios where application developers are unwilling to change their 
  applications (e.g., by configuring encryption) solely for the sake of 
  improving security.

- The protocol must provide cryptographic algorithm agility.

- The protocol must gracefully fall-back to TCP if the remote peer does 
  not support the proposed extensions.

- When encryption is enabled, it must at least provide protection 
  against passive eavesdropping by default,

- Any required TCP option should use a minimum amount of TCP option 
  space, especially in SYN segments.

- The protocol 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, including acceptable 
  latency and  processing overheads.  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.

When encryption is enabled, then the protocol:

- must always provide forward secrecy.

- must always provide integrity protection of the payload data (it is 
  open for discussion for the WG if the TCP header should or should not 
  be protected).

- must always provide payload encryption.

- must not provide 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.

- must allow the initiator of the connection to avoid being 
  fingerprinted as a result of using the protocol: 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.

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.

- Definition of the unauthenticated key exchange mechanism and the 
  extensions to current TCP to utilize unauthenticated key to provide 
  encryption and integrity protection. This covers all the protocol 
  changes required. This will be an 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. 
  This will be an informational document.



Ballot announcement

Technical Summary

   Relevant content can frequently be found in the abstract
   and/or introduction of the document.  If not, this may be 
   an indication that there are deficiencies in the abstract
   or introduction.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

Personnel

   Who is the Document Shepherd for this document?  Who is the 
   Responsible Area Director?  If the document requires IANA
   experts(s), insert 'The IANA Expert(s) for the registries
   in this document are <TO BE ADDED BY THE AD>.'

RFC Editor Note

  (Insert RFC Editor Note here or remove section)

IRTF Note

  (Insert IRTF Note here or remove section)

IESG Note

  (Insert IESG Note here or remove section)

IANA Note

  (Insert IANA Note here or remove section)