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?
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
