TCPINC
IETF-96 Berlin
2016-07-19 16:20-18:20 CEST

Action: Chairs will update the WG milestones to reflect the multi-document
approach (ENO + tcpcrypt)

Action: draft-bittau-tcpinc-bcp should be renamed from -bcp to
-middlebox-probing

Draft guidance: Need to clarify expectations for TEP usage of ENO option
content in non-SYN packets. What can a TEP author expect when using the ENO
option?  Could send in every packet, guidance to TEP authors needs to be clear.

Draft guidance: Mazieres will add a section describing the issues around
session ID disclosure to the security considerations section

Draft guidance: Will need text on what happens when TCP-ENO tries to talk to
old (squatting) use of option 69

Draft guidance: What to do about unauthenticated FIN and URG? Don't want to say
"Updates: 793" in header.

Draft guidance: Document TFO interaction with TCP-ENO

Confirm on list: So, change m bit to another reserved z bit.  Subsequent draft
can define m bit and all the details on how to use it.

Confirm on list: Remove length word for now, limiting all but last suboption to
32 bytes of data

Confirm on list: Encrypt frame lengths? (Editor's note: krose and dbg had a
discussion about this after the meeting, so we might want to talk about this
more on the list.)

================================================================
TCP-ENO: Encryption Negotiation Option
draft-ietf-tcpinc-tcpeno-03
Dave Mazières

ENO in non-SYN segments
 * Not currently used, but future encryption specs could use it, and they could
   vary the data between packets
 * We may need more clarity on what spec designers can expect from it

Simultaneous open
 * Mechanism simplified
 * If both sides think they are active, default is no encryption

Middleware "m bit"
 * Questions and concerns about the distinction between middleware vs.
   application
 * Agreement to kill the m bit in this draft, and have 3 z bits
 * Will need a future document to guide/control usage of m bit (as indicated in
   slides)

Length byte/word
 * Length word - discussion of must be zero (z) bits in spec suboption (slide
   11)
 * Intended to allow for extension in future if more TCP option space becomes
   available
 * Can fill current TCP option space (<=255 bytes) with existing specification;
   would need a revision to the TCP spec allowing for longer individual options
   to make use of 256+ byte ENO suboptions, the specification for which could
   update the ENO standard
 * Note: Octets on slide 11 are reversed from network byte order, byte w/bits
   7-0 come first, bit 7=0 of the octet following a length byte indicates that
   the length is a word (2 octets)
 * Existing proposed use of length byte is session resumption
 * Mirja Kühlwind suggests that we should remove the "length word" for
   simplicity
 * Hum: Sense of room is get rid of length word, just use length byte for now.
   Consequence: At most 1 long suboption in payload (last one, which does not
   require a length be specified), all others are limited to 32 bytes. (See
   slide "Spec identifier suboption length")

"Spec" terminology
 * Suggestion to change "spec" to "TCP encryption protocol" (TEP)

Exporters
 * RFC-5705-like key exporter mechanism not needed
 * Will need to make a minor change to tcpcrypt to make session ID completely
   secret - this involves session resumption - don't want to reveal ID to
   potential attacker and to limit privacy concerns
 * Clarification: if you don't use the session ID for anything, it is safe to
   disclose it.  If it is used for anything, then those dependencies may care
   about disclosure.  Mazieres will add a section describing this to the
   security considerations section.

TCP Option Kind 69
 * Mazieres is fine using 69 as the TCP option kind "since we polluted it"
 * Draft will need text on what happens when TCP-ENO tries to talk to old code
   using option 69.
 * Failure is okay given limited deployment, but it needs to be noted.
 * Ekr: can we make interaction between old code and new code fail cleanly?


================================================================
tcpcrypt: Cryptographic protection of TCP Streams
draft-ietf-tcpinc-tcpcrypt-02
Andrea Bittau

Unauthenticated FIN and URG
 * Take what to do offline, don't want to say "Updates: 793" in header

Encrypted frame lengths
 * Not being done now, prefer to stay that way

Split API document into two/add separate tcpcrypt API doc
 * Not now
 * Ekr offers to take a look at the merged doc to make sure it'll be ok for TLS
   via TCP-ENO
 * Action: move the API bits that are currently in the tcpcrypt doc into the
   ENO API document

TFO
 * On session resume - TFO sends ciphertext immediately, would have to drop
 * Two problems with layering TCP-ENO and TFO:
    - TFO will preemptively send cleartext that TCP-ENO would want to encrypt
    - Sending pre-encrypted data, then TCP-ENO changes TEP
 * Action: Document TFO interaction with TCP-ENO
 * Take possible inclusion of data in SYN w/TCP-ENO for session resumption to
   list. David Mazieres will send message to start discusion.

Call for kernel implementations

================================================================
TLS privacy Negotiation Using TCP-ENO
Dave Plonka

Server name (from URL) is usually sent in clear by browser in TLS SNI (Server
Name Indication).
Server name comes back in clear in server certificate.
May want to keep server name private.

SNI is not negotiable in TLS because it is sent in the first flight.
TCP-ENO could negotiate it.

Comment: Have to randomize (obfuscate) server IPv6 addresses to make omission
of SNI have useful privacy benefits.

Anticipates dynamic random IPv6 addresses ("fast flux"), so IPv6 address
doesn't give away server identity.  Wants to hide other rendezvous information
that would enable associating server identity to IPv6 addresses.

Negotiation has to be secured in order to function against active adversary -
this is about making pervasive passive monitoring more difficult.

This use of TCP-ENO adds a round-trip to potential TLS use of TFO - serious
disincentive to deploy.

Alternative: could put "don't send SNI" into DNS (DNSSEC).

Comment: Could use TCP-ENO to encrypt SNI (e.g., w/tcpcrypt).

Comment: TLS TEP will not use SNI.  Harder problems that need to be solved to
realize privacy benefits here are DNS-related (e.g., DPRIVE & DANE).

Comment: Ask for a TCP ExID; could just use that as a signal, don't need to
piggyback on ENO.

================================================================