TCPINC minutes ============== Agenda bashing Tero: two drafts, trying to select between them: tcpcrypt and TLS-based. Lots of ADs in the room. ==== Andrea about tcpcrypt Encrypt payload, MAC some of the options. The MAC is in a TCP option Brian Trammell: tcpcrypt MAC'd the header. Do you have data as to how often you run into trouble? Andrea: some data. No exact number. BT: This discussion should be informed by data. Andrea: I have 1000 points of data. Wish I was Google. Question is: does it work? We don't have a clear answer. Open question: store the MAC in TCP header or use TLV? MAC in TCP option is simple, easy to implement. Does not change TCP semantics. Does not mess with buffering. TLV advantages: robust to middleboxes. Easier to make work with TSO. ==== ekr for TLS over TCP Bob: EDO is not applicable to neither the SYN nor the SYN/ACK. ekr: my understanding was that there were designs doing initial data in syn packets, that is not EDO Bob: They all got some problems ekr: it would great to have those work others: you need some magic. ekr: please add the magic. Stuart Cheshire: If we're doing it this implies the application is plaintext. So the application receives a bunch of TLS stuff it doesn't understand ekr: My understanding was that initial data can be out of band from the application perspective, isn't that so? Others: that's the needed magic. Bob Briscoe: the ability to build authentication on top of the encryption EKR: channel bindings is a standard feature of TLS Bob: need to spec the details pls - tcpinc would be a different basis to start from. Andrea: tcpcrypto session-id is super simple. Don't know about TLS channel binding. David Mazieres: The issue of segmentation and choosing MTU helps in the center, but pushes complexity to the receiver. There are advantages to TLV, but it's nice that TCP options keep semantics. EKR: yes, but TLS does this all the time. Jana Iyengar: MACS by segment is not just a strength. A TCP-level proxy might muck with segment size Daniel Giffin: if we decide we need a TLV-style transport, we end up with two proposals that have a lot of common features. Even a TLS handshake could export keying material for tcpcrypt style data layer. Both can be upgraded to MAC headers like TCP-AO. After those were addressed, it comes down to which crypto you want. We can do both. chair: no. Bob: in both cases we're talking about things you COULD do, but it's not written down, and you can't just hand-waive. chair: we don't want to progress with two proposals. Too much effort. We want to pick one, assume that it's very initial and work on that. Bob: not disagree, but neither protocol is specified enough. chair: both can be made to work. People will be able to modify the proposal. We don't want to make the authors invest a lot of work in modifying only to then throw away their work by picking the other. Bob: These are important details. David: we are not proposing to change them. Only change the framing of the application data. AD: no space for two documents. Need to go with one single document. Need not be perfect. Steve Kent: If we're going to make a decision, it should be based on properly-specified proposals. Let the proponents make a best and final proposal. Ted Hardie: I disagree with SK. I want this to deploy. The faster we have *one* thing, the faster we'll get something that is deployed. EKR: If people don't want to select between non-fleshed-out proposals, there's always something else that can be fleshed out. If we want something, get requirements. Stephen Farrell: Don't want to spend time writing requiremetns. Christian: Both are good. tcpcrypt doesn't require a server credential. TLS as deployed does. EKR: There are two options without good certs: self-signed, oob keys. Mirja Kühlewind: Is there an implementation? EKR: not yet. David: concern about moving to TLV for tcpcrypt: it changes a lot of things (socket buffer size...) Bob: We've started an implementation of inner space as a TLV framing for tcpcrypt - in FreeBSD. ==== Tero on framing options Paul Wouters: please don't do with library pre-loading Tero: I said you *can* do, not that you should. We want it to be in kernel. David: people don't want to change the kernel. need usermode. Our implementation of tcpcrypt is not pre-loading. Jana: is there an equivalent for Mac and Windows? David: yes. Keith Moore: you need to have the same effect of urgent data. They are rare, but important to some people. This is going to be imposed on applications, and you don't want random breakage. Tero: Right, and we don't know that urgent data is going to come. Urgent pointer cleared by middlebox causes breakage Richard: obsolete. don't have to worry about it Keith: yes, you do. David: only FTP and telnet use urgent data. Richard: but it's broken in a lot of operating systems. Bob Briscoe: Richard is saying that given that it's broken, might as well break it more. Dave Borman: It has not changed on the wire. Christian: no discussion of MTU changes. Tero: users don't know MTU Christian: if you add a MAC, your MTU reduces. Tero: As long as it's fixed, it just goes down and the kernel knows the overhead. Christian: If you sent a 2K packet with MAC and it is dropped, how do you retransmit? The already calculated MAC is wrong for the smaller packet. David: The attempt to be friendly to middleboxes. relatively straight-forward. Optimized the MAC Bob: Do you think you've presented something that's the same as I presented in HNL? Bob: Trying to design a generic framing protocol. I think it meets your requirements. Can break out the part of it and do tcpcrypt in it. Jana: Which conversation are we having now? ==== Discussion Jana: important question of deployability. TLV is probably better. Tim Shepherd: If I understood it, three things to choose from: tcpcrypt with current framing, tcpcrypt with TLV, and TLS. the 1st should not happen. framing is important. which of the others has closer to running code? Tero: I think in both cases we need new code. Keith: don't want to discourage. there is a lot of mindshare for tls. even with tcpcrypt, need to be able to run tls on top. overhead matters. Ability to evolve the stack is important. should not choose between approaches. tls is important. stephen: which version TLS? 1.3? 1.2? ekr: tls 1.2 and profile 1.3 ciphersuites. YN: TLS on ports that are usually non-TLS might have issues. TH + others: no problem if middlebox terminates TCP. Trouble if it doesn't. Bob: I also don't like Tim's first option. Don't want TLS 1.2. Bob: Then zero added latency is an important requirement; when turning on opportunistic encr, users will prefer performance over privacy. I gave a detailed spec of how not to add rounds for tcpcrypt, but neither the authors nor the list responded, so I've no confirmation whether my proposal will weaken security. Bob: I believe TLS-option can also be done without adding latency, but only up to the TLS handshake. Then I wouldn't want TLS 1.2, which would add rounds. And we don't know if TLS 1.3 will be zero latency, that is only a hope. David: the choice depends on your vision for TCP. tcpcrypt want to guarantee that it's as close to normal TCP. Ultimately, its place is in the kernel. Christian: The one thing I understand about tcpcrypt is socket API. Do not understand TLS over the socket API. EKR: don't expect to change API. Tero: should work on unmodified applications. Christian: If we need an API for certificate validation... Tero: not needed. Could be OOB public keys. ==== Chairs asking questions 1. Do we need a framing protocol (TLV or something) Yes - strong hum. No - very weak 2. Are we ready to make a decision? Yes - somewhat louder No - somewhat less loud 3. Who thinks either is good? somewhat loud 4. Only one? somewhat louder 5. tcpcrypt? Quite audible 6. TLS? A little bit louder Tero: we want a framing protocol, we are ready to pick, it's almost even between proposals, with TLS a little louder. Bob Briscoe: How do we resolve this? Bob: Given we want to move fast, we should create a race: whichever solution the authors specify the unknowns for first is the winner. [Chairs, ADs and draft authors will discuss, and try to solve this issue]