Subject: [tcpinc] Minutes for tcpinc @ IETF 92

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Mar 2015 17:13:28 -0500

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 on the SYN, only SYN-ACK
ekr: there were some discussions. Fix that
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: If it's EDO it's ignored.
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
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
Jana: 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.
???: Is there an implementation?
EKR: not yet.
David: concern about moving to TLV for tcpcrypt: it changes a lot of things (socket buffer size...) 

==== 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 telent 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.
???: 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?
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 running 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. Want 1.3 for 0RTT.
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?

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 27 Mar 2015 00:08:01 +0000

Sorry, I couldn't attend the TCPINC meeting. But I've spoken up on the list quite a bit. One comment...

> ==== Andrea about tcpcrypt

[...]

> semantics. Does not mess with buffering.

I've challenged these statements on the list already, and I have explained why I do not agree to any of them. Please back with data.

> TLV advantages: robust to middleboxes. Easier to make work with TSO.

Plus others - see my list postings.

Michael

---

From: Andrea Bittau <[email-masked]>
Date: Thu, 26 Mar 2015 20:15:15 -0700

We (tcpcrypt) agreed to use TLV and will update the draft and code
accordingly.

On Thu, Mar 26, 2015 at 5:08 PM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> I've challenged these statements on the list already, and I have explained
> why I do not agree to any of them. Please back with data.
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 27 Mar 2015 07:54:43 +0000

> Bob Briscoe: How do we resolve this?

Running code?

Lars

---

From: ianG <[email-masked]>
Date: Fri, 27 Mar 2015 11:44:00 +0000

>> Bob Briscoe: How do we resolve this?

+1

iang