TCP Increased Security (tcpinc) minutes IETF-94, Yokohama Wed, Nov 4, 13:00-15:00 ------------------------- -- WG Status Update (chairs) Three WG-adopted drafts: - TCP-ENO: Encryption Negotiation Option (draft-ietf-tcpinc-tcpeno) - Cryptographic protection of TCP Streams (tcpcrypt) (draft-ietf-tcpinc-tcpcrypt) - Using TLS to Protect TCP Streams (draft-ietf-tcpinc-use-tls) Interoperability is a requirement, 3 possible ways forward: -1- Converge tcpcrypt and use-tls into one protocol -2- Select one of the two protocols -3- Publish both protocols, usage negotiable via TCP-ENO WG chairs want to see development of both protocols (tcpcrypt, use-tls), as attempting to choose one has not worked well to date. The WG chairs want to see complete protocol specs suitable for review by external experts (e.g., security, transport) in mid/late Feb 2016, and intend to defer further discussion of which of the above approaches will be used until at least then. The WG chairs will not hold up one protocol to wait for a complete spec for the other one. WG chairs would like to see multiple implementations of both protocols. Discussion: Protocols developed by this WG will not work through ALGs (Application Level Gateways), e.g., in NATs. A specific example is that tcpinc protocols will not work for FTP through a NAT because the ALG changes address and port info in FTP (carried by TCP). -- TCP-ENO: Encryption Negotiation Option (Andrea Bittau) draft-ietf-tcpinc-tcpeno This is a new draft since Prague, to separate out negotiation in a fashion that can be used by both tcpcrypt and use-tls. There are some open issues around the details of the option design - whether we can get down to one option per TCP packet at the possible expense of extra space. Discussion will move to list. ENO transcript has to be well-defined wrt retransmission of packets involved in TCP handshake. Inconclusive discussion of how to deal with simultaneous open (have to identify a "goes first" role for one endpoint to make security negotiation work) - the one bit in ENO is useful, more is possible, but limited TCP option space is a countervailing concern. Middlebox behavior wrt the ENO option is an area in which some insight into what actual middleboxes do would be helpful. -- Interface Extensions for TCPINC (David Mazieres) draft-bittau-tcpinc-api Getting code into OS distributions, but disabled by default may result in a lot more time getting it enabled. Suggestion: enable response by default but start out with initiation disabled by default. ECN deployment went down a similar path and still took a long time. Proposed API extensions are for TCP-ENO - all are optional (can get encryption to set up without any new API calls). There are a lot of subtleties in the STUN and DHCP material to check on ENO failures/problems (see slide 6). Both David Black (tcpinc WG chair) and Flemming Andreasen (mmusic WG chair) expect that a lot of details and operational considerations will need to be specified and recommend use of a separate draft for that material. RAW mode discussion (see slide 7) was inconclusive. -- Cryptographic protection of TCP Streams (tcpcrypt) (Andrea Bittau) draft-ietf-tcpinc-tcpcrypt-00 Integrating tcpcrypt with ENO and other changes have significantly simplified it (e.g., RSA key support removed). Session to resume is unambiguously identified by session ID, which is among the things generated from the master secret for the session. The tcpcyrpt URG and FIN bits will be renamed to make it clearer that they are not copies of the URG and FIN flags in the TCP header, but are instead tcpcrypt-defined bits that have similar functions (pURG and pFIN names aren't sufficiently different). Suggestion: URG support has been deprecated and really isn't used; could just be eliminated. Bryan Ford suggested that the tcpcrypt protocol could be made symmetric (current draft has distinguished A and B roles) - follow-up on list. -- Using TLS to Protect TCP Streams draft-ietf-tcpinc-use-tls-00 Profile of TLS 1.3 is now in draft. Discussion conclusion: Do *not* use X.509 certificates in this protocol and expect recipient to extract key without certificate path validation. The certificate parsing involved is not simple, and setting an expectation that a certificate can be used w/o path validation is a bad idea. Sender needs to extract key and send that by itself - it's ok to use ASN.1 to wrap the key; the parse complexity is caused by X.509 certificate syntax. Structure of TLS requires a server key, even if the certificate is not used. The base TCP-ENO protocol number for use-TLS should be for a simple TLS 1.3 profile. Additional functionality (e.g., certificates, use of TLS 1.2) should use a separate ENO protocol number. 0-RTT discussion - is there enough space in TCP-ENO for the required nonce? It looks like there is room for nonce material.