Subject: [tcpinc] Preliminary minutes of TCPINC

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Jul 2015 15:07:11 +0300

Here is preliminary minutes of the TCPINC session in IETF 93, Prague.

If there is anything to fix, send me email, and thanks for Yoav Nir
for them.

----------------------------------------------------------------------
Notes from TCPINC
=================

Projector isn't working, but that's find: there are no slides.

--

tcpcrypt progress (Andrea)

Been taking feedback. Reworked to move to TLV. Submitted a new draft
(with TLV). Not MAC-ing the header. Doing Diffie-Hellman. We've always
had an option to disable tcpcrypt when TLS is present.

--

TLS-based solution (Eric)

Most tried to make the draft clearer. No technical changes other than
mandating session hash. Have a very early prototype. Not ready to show
yet, but nothing surprising found during implementation.

--

Tero: How to go forward? There was a discussion on the mailing list.
The working group prefers option #1: adopt both and see what happens.

By IETF94 we need a full (though not final) specification
  - for tcpcrypt it means including all the changes from WG input
  - for TLS means a complete profile

For both: need an implementation that the implementers claim matches
the spec.

If both deliver: we do a consensus call.  No consensus? Coin toss.

Consensus on this plan?

--

Jan Seedorf: Surprised that we're considering closing the WG when we
    	     think this is important for tackling pervasive
    	     monitoring.

David Mazieres: Seems fine for what we have to do. Should have an
      		earlier deadline for feedback so that we can have some
      		time for impleemntation

ekr: Does not seem crazy. probably should be lenient on evaluating the
     implementation for matching the spec. Don't want to see us
     falling back on rough consensus

Ted Hardie: Perhaps test for consensus now and skip all this. If we
    	    are going to do this, adopt a blank sheet of paper. It's
    	    too important to let it drop. Shouldn't die over a process
    	    point.

Marcelo: We've tried, but it doesn't seem to work. How will a blank
	 sheet help? It's always "do TLS" or "do not-TLS".

Ted: What you are describing is that we need to move forward with one
     of the proposals. Either one is a starting point for the group to
     work. They might change within the process. I really don't want
     us to give up on this.

Brian Trammell: Coin toss not great. Perhaps we need to adopt both for
      		different use cases...

David Mazieres: Tcpcrypt is good for people who can't stick a STARTTLS
      		message in their (legacy?) protocol. While the
      		TLS-based method could be good for other cases.
      		Tcpcrypt is great if it's inside the kernel. Eric is
      		not going to like it, but the draft should either be
      		referencing TLS or should be self-contained. Then
      		TCP-use-TLS can be signalled by a bit.

Tim Sheppard: The key architectural difference vanished when they
    	      decided on TLV. I think you should all look at the TLV
    	      encoding from TLS and use that. Then they would be even
    	      closer. I would like to understand why the proposals
    	      haven't moved entirely close together. I think they
    	      could have two implementation style stories, but they
    	      would interoperate because the bits on the wire are the
    	      same.

David: I wanted to use the TLS encoding on the wire but our key
       exchange. There are several things we care about in the key
       exchange protocol: it's simpler to prove secure. If the WG
       instructs us to use the other key exchange, we can live with
       that.

Brian Trammell: there is wilingness to move forward/around. Should
      		make a consensus call here.

Mirja:  Perhaps adopt both and publish both as experimental.

ekr: I'm good.

Matt Matthis: I had a colleague who went through adding TLS to an old
     	      protocol. This is very hard, because TLS makes
     	      assumptions. Think about that.

ekr: Viable to do a library shim option. Our first cut is a kernel
     proxy.

Martin: Can do a consensus call now and continue on the ML. If not,
	kick in this procedure. 

Tero: OK. 
  - Option #A: tcpcrypt: (quite audible hum)
  - Option #B: UseTLS:   (also audible, slightly less)
  - Option #C: both (considerably less)
Tero: we don't have a consensus now.

Marcelo: What are the fundamental differences.

Ted Hardie: What about change control? Change control usually shifts
    	    to the IETF. The tcpcrypt team have some things they don't
    	    like to lose. For the TLS proposal some changes rest with
    	    the TLS group.

ekr: The entire benefit of UseTLS is that we re-use TLS. Hopefully the
     TLS WG would be responsive, but that is our entire value
     proposition.

Christian Huitema: I would like to see in a TLS proposal that a single
	  	   implementation can work for both regular TLS and
	  	   UseTLS.

Marcelo: So what features of tcpcrypt can you not do by profiling TLS?
	 (this is a "homework" assignment for the authors)

Tim Sheppard: Don't know what is going to be on that list, but knowing
    	      what is going to be requested from the TLS WG would be
    	      good.

David Mazieres: Some things are harder like using SYN packets for
      		session resumption. The methodology we're using for
      		tcpcrypt is different. Such as "make the security
      		proof easier". We have much less manpower, but we're
      		likely to come up with a different set of bugs.
      		tcpcrypt adds diversity.

Andrea: Tcpcrypt works on the first packet. lower latency. Question:
	are the people against tcpcrypt like that because we're not
	inheriting TLS?

Matt: It's more like a socket intercept rather than a tcp intercept.
      That piece needs to be in the kernel. Everything else can be
      outside the kernel.

Tich Salz (OpenSSL dev team): understand the risk of monoculture. Less
     	  concerned about it in protocols. If all we need is to shim
     	  it to the kernel, that's easy.

ekr: I'm not sure how much we want to get into technical fine points.
     The only technical reason not to use the SYN-ACK is middlebox
     friendliness - it doesn't look like TLS. In terms of latency it's
     comparable, because 1.3 is more aggressive. We originally wanted
     a socket intercept. We ended up with a packet intercept.

Tommy Pauly: If you do something like TFO would there be any
      	     difference?

???: the TFO has to happen first.

ekr: in 1.2 the client can send in round 2

Lars: I asked netapp guys which they preferred, and they preferred
      tcpcrypt. Our product runs in kernel space and we are not going
      to put TLS in the kernel.

Bryan Ford: Perhaps have one protocol with two ways to start it?

Brian Trammel: Why no? There is a whole wisdom that says don't design
      	       new crypto. I suggest that we're working as a group
      	       that has adopted a blank slate and has a design team
      	       working.

Bob Briscoe: Latency is very important. If you make it slow, nobody
    	     will deploy. Tcpcrypt is more open for changes, whereas
    	     TLS is constrained by the other TLS uses.

Tero: Can make changes to either after adoption. Both can be finish.
      If we have TFO things should end in one round-trip.

Marcelo: You think there is a way to do it for tcpcrypt?

Bob Briscoe: I vote tcpcrypt, because it's difficult to change TLS

Tim S: The proposal is not to put TLS in the kernel: we don't have to
       support TLS.

Lars: We don't know how profiled it would be. We don't care about
      latency, but I am for tcpcrypt because it's a known quantity.

Martin Thomson: Anything TLS can do, tcpcrypt can do and vice versa.
       		tcpcrypt is untested but has less baggage.

David M: Tcpcrypt is more nimble. Not constrained by the structure of
      	 the TLS protocol.

Bob Briscoe: there is a bunch of hardware that recognizes TLS.

Tero: It doesn't recognize 1.3, which is what we're likely to
      recommend.

ekr: Either you know tcpinc is enabled on the other side, or you
     don't. You can't just send handshake and hope the other side
     understands.

Jana Ayengar: Since we're doing TLV, we have the same issues. Even
     	      with TFO you need to negotiate capability first, and
     	      both have this issue.

tcpcrypt is allowed to send data on the SYN-ACK, whereas TLS has to
wait for the ACK.

ekr: You don't have to assume the client speaks first. The only reason
     to have the client speak first is friendliness to middleboxes.

Mirja: You can send data in the first round trip. I hummed for #C but
       I'm in favor of adopting tcpcrypt right now. Consensus call for
       tcpcrypt right now and maybe TLS later?

Ted: It's fine to run a consensus call again. It's different.

ekr: This is silly. Once we adopt something we go with that something.

David Mazieres: I think we're willing to make changes, so it's not
      		that silly.

Aaron Falk: A lot of interest in making forward progress. Should ask
      	    about whether people are opposed to adopting one or the
      	    other.

ekr: Six weeks is fine to get the profile / complete spec.

Mirja: I don't have an objection to this, but not sure it can all be
       done in six weeks. All that just to adopt something. I'm not
       able to say yes to any, because I'm not sure what drawbacks
       we'll have from choosing one or the other. We could have them
       all as editors of whichever one is adopted.

Christian Huitema: We're making this too complicated. Two proposals do
	  	   the same thing. One emphasizing code reuse (with
	  	   its cons and pros). The other is an ad-hoc specific
	  	   solution. Nevertheless, it is new code that has not
	  	   been tested. That dillema is not going to change in
	  	   6 weeks of 4 months.

Daniel Khan Gilmore: I don't think the proposal of having one evolve
       	    	     into the other is crazy. Both need a signalling
       	    	     mechanism. We have different TLV implementations
       	    	     but they're willing to change. The TLS handshake
       	    	     is burdened with a lot of cruft. TLS was not
       	    	     suitable for analysis. New versions of TLS have
       	    	     better analysis. TLS has a complicated handshake
       	    	     because you don't know how the other is
       	    	     configured. The signaling mechanism allows to
       	    	     make it simple. So they're coming down to the
       	    	     same thing. I think the tcpcrypt people have more
       	    	     code down.

Andrea: I agree, but realistically, tcpcrypt is not going to change
	much. We might get a TLS profile. But we are probably going to
	be in the same situation. tcpcrypt won't change, TLS might be
	more complete.

Lars: Christian nailed the difference. The considerations are
      different. We can do tcpcrypt over TCP stacks. But to my
      implementers one is acceptable.

:::

Yoav: As an implementer, can do both.

Andrea: So why don't we see UseTLS if it's so easy?

Stephen: Will people change their minds? If now, what's the point?

Tero: how many people are willing to change their minds?
   - yes (some hum)
   - no (stronger hum)

Stephen: if people won't change their minds, this plan is going to
	 fail.

David: About the question of whether you would be able to participate
       if the other proposal is chosen: I don't understand TLS well
       enough. I want a protocol where the key exchange proof takes
       like two pages. If it's possible to profile TLS 1.3 down to
       that, then I'm happy.

Tero: Can we make a TLS profile that is 2 pages and self-contained?

???: I'm not best to evaluate that, but TLS 1.3 should want what
     tcpcrypt is offering.

ekr: Crypto handshakes of TLS and tcpcrypt are isomorphic. TLS is
     complicated because it does more than that.

David Mazieres: TLS wrapping key exchange and authentication makes it
      		complicated.

Ted Hardie: Tcpcrypt people are willing to consider harmonization. An
    	    opportunity to make them converge. Working for convergence
    	    is a good option. Would people be fine with that?

DM: We've been trying for a while. Not sure what convergence means.

Ted Hardie: We try. If we don't reach convergence, we do something
    	    else.

Mirja: There is rough consensus to adopt both. Let's do it.

Brian Trammel: Let's do it.

DM: Willing to work toward convergence. But only if we start with a
    fork of TLS.

Stephen: Don't want to fork 1.3 while it's being worked on.

Lars: Won't help to make them WG drafts.

Tero: Probably not.

Rich Salz: This is the same as the last two meetings

Martin: look at the mailing list. There is consensus about adopting
	both. There is tine to work on both.

Tero: are you willing to work on this time schedule?
  - yes (soft hum)
  - no, this is a bad idea (lower hum)
-- 
[email-masked]