Subject: [tcpinc] Any more corrections to minutes.

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Mar 2015 17:37:20 +0200

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-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 30 Mar 2015 01:09:45 +0100

Tero, inline...

>Is there any other comments, corrections or additions to the minutes:

I said: EDO is applicable to neither the SYN nor the SYN/ACK.

>ekr: there were some discussions. Fix that

I believe EKR said that by 'EDO' he meant a 
general term for proposals that apply to the 
SYN/SYN-ACK as well as using EDO beyond the 3WHS.

>ekr: If it's EDO it's ignored.

I assume EKR meant, "if it's tls-option it's 
negotiated to understand TLS stuff."

>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.

>        things (socket buffer size...)

s/tcpcrypt/tcpcrypt implementation complexity/

Bob: We've started an implementation of inner 
space as a TLV framing for tcpcrypt - in FreeBSD.

>???: It has not changed on the wire.

Dave Borman, I think? [So you'll need to disambiguate David & Dave]

>Bob: I also don't like Tim's first option. Don't want TLS 1.2. Want

[Replace last two sentences with:]

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.

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.

>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

HTH

Bob

>--
>[email-masked]
>
>_______________________________________________
>Tcpinc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpinc

________________________________________________________________
Bob Briscoe,                                                  BT