I cleaned up minutes bit, added Mirja's name, fixed one thing I said
about running code (I at least meant to say that we need write new
code), and added comment to the end that Chairs, ADs, and authors will
discuss about this and try to solve this issue.
Is there any other comments, corrections or additions to the minutes:
----------------------------------------------------------------------
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.
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...)
==== 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.
???: 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. 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?
[Chairs, ADs and draft authors will discuss, and try to solve this
issue]
--
[email protected]
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
