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