Skip to main content

Minutes for TCPINC at IETF-93
minutes-93-tcpinc-1

Meeting Minutes TCP Increased Security (tcpinc) WG
Date and time 2015-07-20 13:20
Title Minutes for TCPINC at IETF-93
State Active
Other versions plain text
Last updated 2015-08-03

minutes-93-tcpinc-1
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 implementation.

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 hum)
 - 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 Iyengar: 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 if you negotiate TFO and
tcpinc together. 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)