Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Eric Rescorla <[e-mail]>]

On Sat, Aug 22, 2015 at 10:13 PM, David Mazieres <
[e-mail]> wrote:
>
> > TECHNICAL
> > S 3.0.
> > The variable/non-variable encoding seems suboptimal and in particular
> > the restriction that only one suboption can be variable length. What
> > are we going to do if two specifications wish to have variable-length
> > data in the SYN packets? The specification suggests that you should
> > address this by having two ENO options but that seems clumsy.
> >
> > I would suggest instead that if the v bit is set the next byte be the
> > length. This comes at the cost of one byte for settings where there is
> > only one variable-length option but is more efficient when you
> > want to have multiple variable-length options, since you don't need
> > to repeat the kind byte.
>
> Our intent is to optimize for a future in which people only need one
> variable-length option.  For example, the SYN can list a bunch of
> options, and then the SYN-ACK can pick one of them.  The current design
> saves one byte, which may be quite important.


But, as I note, at the cost of a byte if you *ever* want to have >1. My
experience
is that things get more complicated, rather than less.


For instance, you can
> just barely fit a P-256 or Curve25519 DH key exchange in TCP options
> currently.  If TCPINC is wildly successful, we can imagine a future spec
> that does that and squeezes the 8 most popular SYN options into a single
> byte or something.  But if we waste even one more byte of option space,
> we start closing a lot of doors along that front.
>

It seems like if that actually happens, it's also reasonably likely that we
will find some way to make the SYN bigger.


That said, if you can provide an explicit example of why you might want
> multiple variable-length suboptions, you could possibly convince us to
> optimize for that case.


I think it's a general issue of protocol hygiene, but with that said, this
would allow you to have an optional long tiebreaker for NAT penetration.


>
> > S 3.1.
> > I am not convinced that a one-bit tiebreaker for simultaneous open
> > is going to work. Experience with other protocols that have the
> > problem of symmetry (e.g., ICE) is that this sort of thing results
> > from confusion about which side is really "first". In that case,
> > both sides will try to set the same "b" bit, and you will not break
> > the symmetry.
> >
> > I believe we must either ignore simultaneous open or use a higher-
> > entropy tiebreaker.
>
> A high-level question is whether we should completely abandon enabling
> TCP?INC for simultaneous open.


Yes, that would be fine with me. Another option would be to have a larger
tiebreaker you only include in cases of simultaneous open, as is done in
TCP-use-TLS.



>   If we allow encryption under some
> circumstances after simultaneous open, then the next question is how to
> apportion responsibility for making it work.  The high-entropy solution
> says make it work with high probability, but at the cost of a lot more
> option space.  Since simultaneous open is kind of finicky anyway,
> TCP-ENO took the approach of making applications responsible for working
> out the roles. For example, one plausible approach is to set the 'b'

bit to 1 at the endpoint with the lowest (public-IP-address,
> public-port-number) pair.


As you say elsewhere, this is common in cases of NAT penetration and
generally in NAT penetration cases you don't know your IP address
with certainty. For instance, say we have two devices with apparent
addresses:

A: 10.0.0.1 (host),  198.51.100.1 (srflx)
B: 10.0.0.2 (host),  192.0.2.1 (srflx).

Which one has the lower IP address?

In the case where that was worked out most carefully at IETF (RFC 5245),
a much larger tiebreaker is used.



That's obviously not information available to
> TCP-ENO, which knows nothing of NATS, but is information available to an
> application using STUN to broker simultaneous open.


See above.


As it is, the b bit is an effort to find the knee in the cost-benefit
> curve.  I.e., is it worth 4+ bytes of option space to make
> simultaneous open work?  Hard to make that case.  But is it worth one
> *bit* not to shut the door completely?  Quite possibly.


This would be more convincing if you provided an example where it
actually added value. In the case you suggest above, where the sides
are independently able to break the symmetry, why not simply do so
via signaling?


> S 3.2.
> > I am unclear on why the active opener needs to have an ENO segment
> > in his first ACK. Can you explain?
>
> There are two reasons:
>
> 1. Given the prevalence of asymmetric routes, it's highly likely that
>    situations will arise where ENO options are stripped in one
>    direction but not the other.  Therefore, both sides need to know
>    not only that the other endpoint supports ENO, but that the other
>    endpoint can receive ENO options.  If you remove the requirement
>    for that ACK, a scenario such as Figure 7 would result in total
>    failure of the TCP connection, not just failure to encrypt.  We
>    definitely want to avoid that.
>
> 2. Suboption data could involve parameters that are not universally
>    supported, in which case the active opener may which to disable
>    TCPINC based on the contents of the SYN-ACK segment.


These seem like an argument for having the passive opener supply one
in the SYN/ACK, not for having the active opener supply one in his first
ACK.


> This mechanism for negotiating mechanisms seems over-complex, what
> > with A and B each providing lists and then choosing B's top
> > preference.  I would suggest instead that we simply have B choose out
> > of A's list, as with ALPN. The document offers two reasons why this
> > might not work, simultaneous open and inflexible implementations: If
> > we resolve simultaneous open in the SYN exchange then this should work
> > fine and the issue of implementation seems like a corner case.
>
> If by resolve simultaneous open you mean not support it, I agree.  But
> if you mean something else, then things can get tricky.  I would
> welcome a detailed design that works, but just saying "do something
> like ALPN" is not enough detail to determine whether or not that
> approach is viable.  We'd need to see an "A -> B: ... B -> A: ..."-
> style example with TCP flags.
>
> One big challenge of simultaneous open is that each side must
> acknowledge the other side's SYN before seeing the other side's SYN-ACK.
>

Consider the version in the TCP-use-TLS draft where in the case of
simultaneous
open you have a large tiebreaker in both the SYN and the SYN/ACK. In that
case, it's quite straightforward to determine who is is who. In that case,
you
can negotiate as I indicate above.


> S 4.
> > I understand the desire to require a minimum cipher length, but I
> > would observe that read strictly, "128-bit security" excludes
> > Curve25519 and also would exclude AES if any real analytical progress
> > is ever made and it becomes secure at (say) 127 bits.
>
> That's a fair point.  We definitely need to say something to rule out
> another 40-bit encryption fiasco, but saying "128-bit" security is
> probably too specific.  Any suggested wording?


Easiest would probably be to simply make the number somewhat
smaller, e.g., 112 bits, which NIST has at about 2048 bits in FFDHE.



> I'd like to see more clarity around forbidding encryption modes that
> > don't supply PFS. For instance, with TLS a common strategy for
> > optimizing session resumption is for the client to send the server
> > a traffic key encrypted under the server's master key, thus allowing
> > the server to be stateless (RFC 5077 Session Tickets). Would this
> > be forbidden?
>
> The draft does not mention PFS, only [non-perfect] forward security.  In
> this regard, TCP-ENO is just echoing the requirements of the working
> group charter.  I happen to think the charter is fine.  If you don't,
> then we should separately discuss re-chartering.  Either way, it is
> appropriate for ENO to follow the charter on this point.


I've read the charter, but I don't think it's actually that clear here. It's
obvious that tcpinc doesn't supply PFS if you have a long-running
connection and never re-key, so I think the question is what the
desired properties are between connections. This language doesn't
actually seem particularly helpful on this point. In any case, if
part of the point of TCP-ENO is to allow for negotiating protocols
defined outside of TCPINC, then this seems like an unnecessary
restriction (as, in fact, do the rest of these).


> S 4.1.
> > Given that session IDs are required to be unique, why bother with the
> > spec-id prefix?
>
> Precisely to guarantee this uniqueness.  If one spec uses SHA-256 for
> session IDs and another uses Keccak, no standard cryptographic
> assumption implies uniqueness without that tag byte.


Can you unpack this some?



> EDITORIAL/TERMINOLOGY
> > Instead of describing this as a negotiation between "specs" I would
> > describe it as a negotiation between "protocols".
>
> I agree that "spec" is a bit of a weird term, deliberately chosen to be
> different from other terms like protocol and cipher suite.  Protocol is
> also somewhat inaccurate, because we're selecting a modification of an
> existing protocol (TCP), not an entirely new protocol.  I don't feel
> super strongly about this.


Well, TLS is certainly a protocol and it's sensible to think of TCP-use-TLS
as negotiating TLS on top of TCP. tcpcrypt also describes itself as a
protocol
("This section describes the tcpcrypt protocol") so I think protocol is the
appropriate word rather than minting new terms.



> > I would use the terminology "initiator" and "responder" rather than
> > A and B. This matches IKE and is generally more familiar.
>
> If we junk simultaneous open, then we should go with active/passive
> opener as the terms, since TCP already has those terms.  Otherwise,
> maybe initiator and responder, though that might not be any more clear.
> In an earlier draft, we used the terms "virtual active opener" and
> "virtual passive opener", to indicate the indented relationship to TCP
> while also leaving room to switch things up under simultaneous open.
> But from our small sample size, that seemed to confuse people even more,
> after which we just decided to introduce terms ("A" and "B") that
> deliberately didn't try to leverage (potentially misleading) intuition.
> So that's how we ended up there, but again, I don't feel super strongly
> about it.


As I said above, I think this is more confusing.



> "Session ID" is a technical term in TLS that means something different
> > than here. Perhaps "channel binding" or "channel identifier"?
>
> How about just "Channel ID"?


I could live with it, but it's a term of art in TOKBIND for a different
concept.

-Ekr