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

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Aug 2015 14:28:02 -0700

Review of draft-bittau-tcpinc-tcpeno-01

I have reviewed the -01 version of the ENO draft. This seems like a good
general idea, but I have concerns about a number of the details.

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.

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.

S 3.2.
I am unclear on why the active opener needs to have an ENO segment
in his first ACK. Can you explain?

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.

S 3.3.
Having two different "application aware" code points (10 and 01) seems
like it's asking for trouble. I would make one of these reserved.

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.

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?

S 4.1.
Given that session IDs are required to be unique, why bother with the
spec-id prefix?

EDITORIAL/TERMINOLOGY
Instead of describing this as a negotiation between "specs" I would
describe it as a negotiation between "protocols".

I would use the terminology "initiator" and "responder" rather than
A and B. This matches IKE and is generally more familiar.

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

---

From: David Mazieres <[email-masked]>
Date: Sat, 22 Aug 2015 22:13:32 -0700

> general idea, but I have concerns about a number of the details.

Thanks for going through in detail.  I will respond point-by-point.

> want to have multiple variable-length options, since you don't need

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

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 believe we must either ignore simultaneous open or use a higher-

A high-level question is whether we should completely abandon enabling
TCP?INC for simultaneous open.  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.  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.  Perhaps we should
work out an example of simultaneous open in the API document.

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.

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

> 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.
Moreover, other than the SYN, you can't consume TCP sequence numbers
until you have definitively enabled or disabled TCPINC (and in the
former case negotiated an encryption spec).  So whereas in a three-way
hand-shake, you can do:

   A -> B:  SYN     X
   B -> A:  SYN-ACK X' which depends on X
   A -> B:  ACK     X'' which depends on X and X' and might disable TCPINC

With simultaneous open, you have two pairs of messages sent in parallel:

   A -> B:  SYN X
   B -> A:  SYN Y

   A -> B:  SYN-ACK X' which depends on X and Y, but not X' or Y'
   B -> A:  SYN-ACK Y' which depends on X and Y, but not X' or Y'

So in particular B does not have the opportunity to abort TCPINC in
response to X', but must decide it based on X and Y.  That's why TCP-ENO
determines the spec based only on the first ENO option sent by each
side.

As for inflexible implementations, I actually thought you would like
that, as it means even if TCPINC ends up not exactly using TLS,
library-level TLS implementations could still potentially someday use
TCP-ENO.  We're much more likely to see something like TCPENO_RAW added
to operating systems than to get an upcall API that allows libraries to
compute SYN-ACK options in response to SYN segments.  That said, the
tcpcrypt team is not particularly keen on library-level implementations;
I could easily see removing this feature given a way to address (or a
decision not to address) simultaneous open.

> like it's asking for trouble. I would make one of these reserved.

That seems fair enough.  Maybe reserved in the sense of should not send,
but should still accept and consider compatible with 11.

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

> the server to be stateless (RFC 5077 Session Tickets). Would this

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.

> Given that session IDs are required to be unique, why bother with the

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.

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

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

> than here. Perhaps "channel binding" or "channel identifier"?

How about just "Channel ID"?

David

---

From: Watson Ladd <[email-masked]>
Date: Sat, 22 Aug 2015 22:35:20 -0700

> work out an example of simultaneous open in the API document.

Let's imagine the stupidest possible protocol: each party squeezes 32
bytes into each SYN, representing a Curve25519 public key, and
we compute H(agreed key || lexographically least || lexographically
greater) . This protocol supports simultaneous open. So why can't a
more complicated protocol do the same?

> style example with TCP flags.

How often is simultaneous open used? Are there important applications
we won't encrypt if we kill it?

> determines the spec based only on the first ENO option sent by each

But what do you need the other ones for in that case? If they just
contain keying material, you probably want to specialize them to that
case.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 23 Aug 2015 07:08:16 -0700

On Sat, Aug 22, 2015 at 10:13 PM, David Mazieres <
[email-masked]> wrote:
> 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
> 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.

> multiple variable-length suboptions, you could possibly convince us to

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.

> 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

> 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
> application using STUN to broker simultaneous open.

See above.

> *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?

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

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

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

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

> assumption implies uniqueness without that tag byte.

Can you unpack this some?

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

> So that's how we ended up there, but again, I don't feel super strongly

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

> How about just "Channel ID"?

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

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Aug 2015 08:37:12 -0700

On Sat, Aug 22, 2015 at 11:12 PM, David Mazieres
<[email-masked]> wrote:
> Watson Ladd <[email-masked]> writes:
>
> What you describe about lexicographically least is a proprety of the
> encryption spec.  The question ENO addresses is how to negotiate that
> spec in the first place.  Suppose suboptDHE does what you describe and
> suboptA is TCPINC (e.g., something derived from tcpcrypt or
> TCP-use-TLS).  Now consider the following simultaneous open:
>
>   A->B: SYN ENO<suboptA, suboptDHE key-material>
>   B->A: SYN ENO<suboptDHE key-material>, ENO<suboptA>
>
> Keeping in mind that the above two messages were sent concurrently,
> which spec should ENO chose:  A or DHE?  The current draft says pick the
> first spec in whichever SYN segment has the b flag set, and disable
> encryption unless exactly one SYN segment has the b flag set.

So 50% of the time, encryption fails between two parties both
supporting the spec, when using simultaneous open. Why not impose a
fixed ordering on all possible options and use the best mutually
supported option, aka versioning?

> It is probably used mostly by NAT-piercing applications.  The timing is
> actually hard to get right if you don't have NATs involved to drop SYN
> segments that would otherwise trigger resets.  I wish I had more data on
> this.
>
>>>    A -> B:  SYN     X
> I don't understand your comment.  By "the other ones", do you mean the
> contents of packets X' and Y' in the simultaneous open scenario?  With
> TCP-ENO you don't need those contents (just the one bit that the option
> got through and was acceptable).
>
> The context of the example was a response to a comment from EKR about
> why not eliminate the tie-breaker bit "b" and have B chose one of the
> active opener's encryption specs.  I can't see a way to make EKR's
> suggestion work without embedding meaningful data in X'.  And the
> problem I was pointing out is that the other side must commit to TCPINC
> before seeing the contents of X'.
>
> But I may have misunderstood your question.
>
> For context, keep in mind that, while we would like to leave open the
> possibility of embedding a DH key exchange in the SYN options, this
> cannot be the only solution to TCPINC, because 32-byte curves may stop
> being secure before we get large options in SYN segments (not to mention
> middlebox problems of inevitably compressing SACK, TIMESTAMP, etc., to a
> supported-option bit-vectorj.  So we need a more general
> forward-compatible negotiation option.  To avoid a circular dependency,
> the negotiation needs to proceed independently of the particular
> encryption spec.

My question is as follows: If we're willing to add half an RTT of
latency because we can't put key material in the first flight,
we can do the following exchange in the following manner
A->B "I can speak X,Y,Z"
B->A: "X, and here is my key share"
A->B: "here is my key share".

In the simultaneous case we can do: (using ; as sequencing mark)
A->B: "I speak X, Y, Z"
B->A: "I speak X,Y,Z";
A->B: "My key"
B->A "My key"

A and B both know that X, Y, Z are ordered, and so can agree.
Now, both kinds of message are completely different, and so shouldn't
be variations on the same kind to avoid attacks based on confusing SYN
with SYN-ACK.

---

From: David Mazieres <[email-masked]>
Date: Sun, 23 Aug 2015 09:26:36 -0700

> is that things get more complicated, rather than less.

Well, I'd say TCP's experience is that option space gets more precious,
not less.  I think the most common case is going to be that the SYN
proposes a bunch of one-byte suboptions and the SYN-ACK contains a
single suboption that is either one byte or variable length.  That's
what TCP-ENO is optimized for.

The "things get more complicated" argument is valid because software
doesn't typically have weight-and-balance-style restrictions like
aircraft.  Yet the 40-byte option limit is just such a hard limit.

Anyway, I'm not sure we can usefully debate this point without more
data, so maybe this question should be deferred until later in the
process?

> will find some way to make the SYN bigger.

I think we will get large NON-SYN options long before we get large SYN
options, and even that does not appear to be particularly close to
happening.  I'm not sure you and I can usefully debate the future of
TCP.  However, if we get the extra SYN space, then the additional byte
won't matter.  That's why I'd rather ensure that at least one use of
TCP-ENO consumes minimal space, rather than optimize something that
probably won't conveniently fit in today's SYN segments anyway.  And I'd
like to leave the door open to a minimal ECDHE spec of the kind
suggested by Watson.

> would allow you to have an optional long tiebreaker for NAT penetration.

That's too general to convince me.  I think we'll have to wait and see
some specs that use TCP-ENO.  If a non-simultaneous open scenario could
end up benefiting from multiple variable-length options in the SYN
segment, that might convince me.  But if only SYN-ACK segments need
variable length options, since they SHOULD send only one suboption, I
don't think we want to optimize for the multiple suboption case.

> Which one has the lower IP address?

Well, assuming the RFC5737 addresses are publicly routable, obviously B
has a lower IP address.

If the simultaneous open is happening in any kind of application, the
two sides will need to use STUN or some other service to figure out
their public IP addresses and determine that they are behind the
appropriate kind of NAT.  They will also need to communicate their IP
addresses to each other.  This logic is happening anyway.  We are adding
a requirement that applications use this information to set the "b" bit
appropriately, which is not a lot more work, but definitely not
transparent.

See below for more cases where setting b is not application transparent
but does not require much work, either.

> a much larger tiebreaker is used.

RFC5245 uses an 8-byte tie-breaker.  So to put our options in a table:

                   +--------------+--------------+-------------+
                   |              | application- |   option    |
                   |  works ever  | transparent  |   space     |
+------------------+--------------+--------------+-------------+
|drop simultaneous |      no      |      no      |      0      |
|open support      |              |              |             |
+------------------+--------------+--------------+-------------+
|TCP-ENO draft     |     yes      |      no*     |  0 / 1 bit  |
+------------------+--------------+--------------+-------------+
|TCP-use-TLS       |     yes      |      no*     | 0 / 48 bits |
+------------------+--------------+--------------+-------------+
|always-on RFC5245 |     yes      |     yes      |   48 bits** |
+------------------+--------------+--------------+-------------+

*TCP-ENO requires applications to break the tie, while TCP-use-TLS only
 requires applications to set a single bit indicating they are about to
 engage in a simultaneous open.

**RFC5245 uses 64 bits, but TCP-use-TLS shows you can do the same thing
  with only 48 bits.

If we agree on the table, then it's just a subjective question of how
much the working group values simultaneous open vs. option space.

> are independently able to break the symmetry, why not simply do so

I'm not sure I know what you mean about signaling.  But suppose two
hosts are behind NATs and an application cannot use TCP between the two
hosts except through simultaneous open.  Here are three realistic
scenarios in which applications can easily be modified to break the
symmetry.  Again, this isn't transparent, but it's not a huge burden,
either:

  * The applications use STUN to learn their public IP address and NAT
    type and communicate this to the other node or register it with a
    public rendezvous service.  The applications can then set b based on
    the public IP addresses and ports as previously discussed.

  * The applications are part of a DHT in which each node has a unique
    node ID.  In this case, the application can set b based on lowest
    node ID.

  * The simultaneous open is triggered by some external broker service
    that sends a message to both hosts, in which case the broker can
    assign the b bit to the two sides.

> in the SYN/ACK, not for having the active opener supply one in his first

Neither of the two examples I made will work if you do not require ENO
in the first ACK from each side (including the active opener--obviously
the SYN-ACK includes an ENO option).  To see this for my point #1 above,
let's look at the example from Figure 7:

        (1) A -> B:  SYN      ENO<X,Y>
        (2) B -> A:  SYN-ACK  ENO<X>    [ENO stripped by middlebox]
        (3) A -> B:  ACK

Now suppose B is not expecting an ENO option on flow 3.  B will enable
encryption, while A will not, and the whole TCP connection will fail
(not just fail to encrypt).  That's very bad.

To see this for #2, imagine Y is a variable-length suboption:

        (1) A -> B:  SYN      ENO<X,Y>
        (2) B -> A:  SYN-ACK  ENO<Y 123>
        (3) A -> B:  ACK                [A does not like parameter 123]

Here B chooses some sort of parameter 123 that A does not support.  123
might be a bitmask of B's supported public key ciphers, and the
designated set might not intersect with A's.  In TCP-ENO, A disables
encryption by not sending an ENO option in its ACK.  However, if B does
not expect the ENO option, B will already have committed to spec Y
encryption after flow 2 and again the whole TCP connection will fail.

> can negotiate as I indicate above.

I understand how TCP-use-TLS does this, but at this point we are going
around in circles.  Ultimately this comes down to a question of
subjective design priorities.  I'd like to hear how you and other
working group members answer the following two questions a scale of 1 to
10:

   A. How much do you care about conserving TCP option space?

   B. How much do you care about simultaneous open.

For me, I'd rate A a 9/10 and rate B a 5/10, which is why TCP-ENO looks
the way it does.

> smaller, e.g., 112 bits, which NIST has at about 2048 bits in FFDHE.

I think that probably works for us.

> restriction (as, in fact, do the rest of these).

Again, please don't confuse things by mentioning PFS, which is required
by neither the charter nor the TCP-ENO draft.  The charter contains the
following language:

        When encryption is enabled, then the protocol:
        - must always provide forward secrecy.

This is verbatim, no ellipsis or anything.  Seems pretty clear to me.
The TCP-ENO draft contains the following language:

   o  Specs MUST NOT allow the negotiation of encryption modes that do
      not provide forward secrecy.

I do not favor amending the charter to weaken confidentiality, but that
is a debate we can have.  However, given the current charter, it seems
beyond debate that TCP-ENO should ensure the same basic security
properties as TCPINC.  The whole point is that applications should be
forward-compatible with future methods of obtaining the same security
guarantees as TCPINC.

> Can you unpack this some?

Let's say that we can compute two transcripts, A and B, such that
SHA-256(A) == KECCAK-256(B).  This doesn't violate any standard
cryptographic assumptions.  Yet without the tag byte, it would be
devastating to TCP-ENO's security in the event that different specs use
different hash functions.

>> EDITORIAL/TERMINOLOGY

Since you mentioned RFC5245, maybe we should consider "controlling" and
"controlled" instead of A and B or initiator and responder.  But anyway,
let's debate terminology after we've got the more basic goals and
structure down.

David

---

From: David Mazieres <[email-masked]>
Date: Sun, 23 Aug 2015 09:38:28 -0700

> supported option, aka versioning?

No, encryption fails 100% of the time, because the b bit defaults to 0.
As currently written, TCP-ENO requires application involvement to enable
encryption under simultaneous open.

The fixed ordering seems potentially harmful, because it might
prioritize weak protocols over newer strong ones.  But maybe we could
have some kind of combination, like assign all suboptions consecutive
numbers in each SYN, and take set of suboptions which have the maximum
value of the sum of the two numbers in the two SYN segments, and then
apply the fixed ordering based on that?  (Maximum will favor
variable-length options.)  We're definitely open to suggestions, but I
worry this can get kind of complicated pretty quickly.

> A->B: "here is my key share".

That's certainly the kind of thing TCP-ENO is designed to allow.
However, we don't completely rule out doing the key exchange in the SYN,
as that may turn out to be a useful encryption spec down the line.

> be variations on the same kind to avoid attacks based on confusing SYN

Something like this might be viable.  Please spec it out in a bit more
detail.

David

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Aug 2015 09:42:58 -0700

> encryption under simultaneous open.

Ok, I got confused about what b was doing. I thought it was
disambiguating and picked randomly.

> worry this can get kind of complicated pretty quickly.

Think of this "fixed ordering" as versioning, like HTTP/0.9, 1.0, 1.1,
2.0, etc. The idea is that we'd only introduce new versions when we
knew they were stronger than the old ones.

> Something like this might be viable.  Please spec it out in a bit more

Will do sometime.

---

From: David Mazieres <[email-masked]>
Date: Sun, 23 Aug 2015 12:42:16 -0700

> knew they were stronger than the old ones.

Such a linear ordering would be very hard to achieve, given that
different parts of the world trust/mistrust different crypto algorithms.
Even among cipher suites discussed so far, how would we order
P-256/AES-128 vs. Curve25519/Chacha/Poly1305.  The former set is better
is the sense that it is more established.  The latter is better in the
sense that it is newer, potentially more efficient, and (for the
paranoid) less tainted by government involvement.  I think realistically
the preference has to be left to the individual host configuration
rather than the IETF.

David

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Aug 2015 13:54:26 -0700

> the preference has to be left to the individual host configuration

Let's consider what this actually means. Hosts that implement 1 of two
options because they don't trust the other one to provide adequate
security will not talk to the ones that make the wrong choice. Hosts
that implement both would be fine picking just one, in fact prefer it
as it reduces the amount of work they have to do.

But by having ranking preferences, we're in fact saying "you would be
fine with picking one for improved interop, but we're going to force
you to make a choice that complicates your implementation, because we
assume you are an expert in cryptanalysis research and we are not".
Picking one suite that's widely acceptable is far better than
providing a smorgasbord.

---

From: David Mazieres <[email-masked]>
Date: Sun, 23 Aug 2015 14:33:30 -0700

> Picking one suite that's widely acceptable is far better than

Well, hypothetically, say the US prefers spec X and the EU prefers spec
Y.  The goal is that two hosts in the US would always choose spec X and
two hosts in the EU would always chose spec Y.  But when a host in the
US communicates with a host in the EU, we don't really care as
much--they could choose X or Y, so we might as well base it on the
preferences of the passive opener.  However, hard-coding the spec
rankings risks delaying standardization to argue over which specs should
take priority.

David

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Aug 2015 16:46:01 -0700

> rankings risks delaying standardization to argue over which specs should

Suppose everyone behaves the way you suggest. How unhappy are they
with using X or Y? Clearly not very much: they were willing to use it
if the other side didn't want their preference.  The result of wanting
to support every possible combination of preferences and admin
interface is having dead options linger forever as the sysadmins keep
copypasta in config files alive forever. I'd rather order my crypto
from McSorley's.

---

From: David Mazieres <[email-masked]>
Date: Sun, 23 Aug 2015 19:28:13 -0700

Watson Ladd <[email-masked]> writes:

> if the other side didn't want their preference.

Actually, people have *very* strong opinions about crypto and are
willing to lobby pretty hard for particular algorithms and protocols.
We should ensure such lobbying is directed towards OS vendors *after*
TCP-ENO is standardized, not towards the working group beforehand (where
it will further slow us down undermine TCP-ENO's goal of breaking the
working group deadlock).

> The result of wanting to support every possible combination of
> preferences and admin interface is having dead options linger forever
> as the sysadmins keep copypasta in config files alive forever. I'd
> rather order my crypto from McSorley's.

The fact that we have way too many encryption options floating around
does not mean all ciphersuites can be strictly ordered by security, for
the simple reason that nobody can predict the future.  Cryptanalysis may
alter the relative security of different algorithms at any time.  Or
some NIST scandal might erupt casting doubt on the design methodology of
P-512 compared to the nominally weaker Curve25519.  At such points, OS
vendors need the ability to re-prioritize cipher suites without breaking
backwards compatibility.

David

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Aug 2015 19:40:37 -0700

> it will further slow us down undermine TCP-ENO's goal of breaking the

Who are people? Certainly not the people willing to use the
alternative algorithm if they have to. The problem is with the
existence of sites where only one algorithm must be used, and the OS
is configured accordingly.
> vendors need the ability to re-prioritize cipher suites without breaking

Am I proposing a fixed, static ordering? No. I'm proposing that in
response to cryptanalysis we have a functional migration plan, and the
negotiation mechanism to support it. We start with version 1, when
that becomes untenable move to version 2. This has eliminated SSHv1
from the Internet. The alternative plan has never eliminated any
cipher completely.

---

From: David Mazieres <[email-masked]>
Date: Mon, 24 Aug 2015 06:33:51 -0700

Watson Ladd <[email-masked]> writes:

> Who are people?

For example, the Russians vs. the US.  The Russians require that banks
and any products purchased by the government employ the GOST cipher.  In
the US, AES is effectively required.  According to wikipedia, the best
known attacks on the two are roughly comparable, though GOST is easier
to misuse (by setting bad S-boxes) and has only a 64-bit block size.

Now if I go visit a Russian bank (e.g., https://www.sberbank.ru), my
browser (which doesn't support GOST) happily chooses AES as the cipher.
Similarly, I'm sure Russian bank employees get AES when talking to US
institutions.  But according to the amended "presidential decree number
334," it seems the banks have to use GOST internally because the
Russians don't trust our crypto (which at the time of the decree was
DES, and at the time it was amended was AES).  Of course, if you are
paranoid maybe you think the Russian government can break GOST and/or
the US government can break AES.

> Certainly not the people willing to use the alternative algorithm if
> they have to.

Yes the people willing to use the alternative algorithms, as evidenced
by Russian web sites willing to use AES with me.

> The problem is with the existence of sites where only one algorithm
> must be used, and the OS is configured accordingly.

Hard-coding global cipher priority is likely to exacerbate this problem.
If the only way to prefer GOST is to disable AES entirely, well, then
Russian institutions will disable AES.

> Am I proposing a fixed, static ordering?

It certainly sounds like it.

> No. I'm proposing that in response to cryptanalysis we have a
> functional migration plan, and the negotiation mechanism to support
> it. We start with version 1, when that becomes untenable move to
> version 2. This has eliminated SSHv1 from the Internet. The
> alternative plan has never eliminated any cipher completely.

But SSH has had the same kind of mix-and-match crypto you have been
decrying.  In context, that was a good thing.  For years SSH shipped a
broken stream cipher mode that used the same key in both directions.  A
lot of people used SSH'S ARC4 mode because it was super fast.
Fortunately, when it was found insecure, vendors simply removed support
for that mode and security was restored where either endpoint had an
upgraded SSH.  If people had disabled other modes to prefer ARC4,
obviously the upgrade path would have been much harder, as SSH would
have been unusable during the transition.

The upgrade from SSH version 1 to version 2 was not primarily about
upgrading the encryption, was not in response to cryptanalysis, and did
not eliminate any cipher from the Internet.  We could, of course,
imagine using TCP-ENO to select between the equivalent of SSH 1 and SSH
2, with cipher negotiation handled at a different layer.  But if we want
just a few good cipher suite options, then these should simply be tied
to ENO suboptions, in which case the IETF cannot prioritize these.

David

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Aug 2015 07:22:23 -0700

> the US government can break AES.

Let's look at an actual Russian bank website, and see which
ciphersuites are enabled.
https://www.ssllabs.com/ssltest/analyze.html?d=http%3A%2F%2Fwww.sberbank.ru%2F

Please point out the GOST ciphersuite being used. Even if internal
tools (which won't rely on easily disabled tcp encryption) used GOST,
clearly this isn't actually applying to the website.

> It certainly sounds like it.

This is a misreading: I'm proposing that at any time there is only one
suite that everyone uses, and versioning is just for transitions.

> have been unusable during the transition.

No, I'm proposing introducing a new version done correctly in
response. RC4 should never have been used in the first place. This
migration hasn't taken place in SSL, despite a similar negotiation
mechanism.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Aug 2015 17:29:48 +0300

> suite that everyone uses, and versioning is just for transitions.

This becomes highly problematic when one needs to:
- Support multiple security levels.
- There isn't one technically (meaning, ignore legal constraints)
  superrior algorithm.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Aug 2015 07:31:14 -0700

> - There isn't one technically (meaning, ignore legal constraints)

In case of point 2, why is there a need to use multiple algorithms?

As far as point 1 goes, if you want data to only travel over one
security level, you cannot support two security levels.

---

From: Mark Handley <[email-masked]>
Date: Mon, 24 Aug 2015 17:32:43 +0100

> Russian institutions will disable AES.

[just back from vacation, and trying to catch up]

Surely we don't need to hard-code cipher priority to choose a mutually
acceptable cipher in the case of simultaneous open.

For example, suppose we have:

A->B SYN ENO(X,Y,Z) 
B->A SYN ENO(Z,Y,X)

You eliminate any not supported by both parties, rank the remaining
options from each message, square the ranks, and sum the squares:
X: 1^2 + 3^2 = 10  (X is rank 1 from A's SYN and rank 3 from B's SYN).
Y: 2^2 + 2^2 = 8
Z: 3^2 + 1^2 = 10

Both choose Y because the sum (8) is the lowest, and send the key
material for Y in the ACK.  

The rationale is both A and B had reasons for their ranking, and with
simultaneous open, you're trying to find a mutually acceptable
compromise.  The squaring does this.  If there's still a tie, it doesn't
really matter which you choose, and no good way to disambiguate, so hash
both option lists and choose the prefered tied option from the list with
the lower hash.

For non-simultaneous open, allowing the passive opener to choose seems
to make most sense.  Simultaneous open is a corner case, and I don't
think it's worth wasting bytes to try to do any better than achieve a
reasonably mutually acceptable compromose.

Mark

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Aug 2015 20:44:38 +0300

> On Aug 24, 2015, at 5:31 PM, Watson Ladd <[email-masked]> wrote:
> 

Because I believe algorithm A is superior, you believe algorithm B is superior, but neither of us thinks the other algorithm is so bad that we might as well use cleartext.

So both of our implementations (or configurations) support both algorithms, but whichever one gets to choose chooses according to our preference.

AES-GCM vs ChaCha20/Poly1305. Which is superior?

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Aug 2015 10:47:19 -0700

> AES-GCM vs ChaCha20/Poly1305. Which is superior?

Would you cry if you had to pick one? Clearly not. So why worry about
making it possible to do this?

---

From: Kyle Rose <[email-masked]>
Date: Mon, 24 Aug 2015 13:48:47 -0400

> different hash functions.

To further illustrate: it's not impossible to imagine someone creating
a SHA-256-twiddle that transforms the input in some invertible way
(perhaps specifically to make one transcript look like another) and
then produces as output the SHA-256 of this transformed input. The
security of SHA-256 and SHA-256-twiddle are equivalent, but are
related in such a way as to make this precise type of attack possible.
The tag byte eliminates this entire class of attack.

I'll admit that the scenario is far-fetched, and that two different
hash functions that reach the standardization stage are very unlikely
to be related in a way useful to such an attack.

Kyle

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Aug 2015 16:08:28 -0400

Watson,

based on many years of experience dealin wit this sort of issue
I suggest that the relative merits (strength, etc.) of cipher suites
form a lattice, not a total order.

Steve

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Aug 2015 13:37:22 -0700

> form a lattice, not a total order.

Every lattice has a compatible total order, and preferences are
expressed as total orders. Could you explain how your supposed insight
into the reality of comparing ciphersuites justifies exposing all
possible ciphersuites, and permitting specifying arbitrary preferences
among them?

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Aug 2015 21:48:56 +0100

> form a lattice, not a total order.

Folks - Steve is I think correct here but I'm quite confused
as to why we're having this discussion about this draft. TLS
(if we go there) has a way of negotiating ciphersuites. So
does tcycrypt (or it will before we're done).

Discussion of AES vs. ChaCha shouldn't be popping up to this
level should it?

S.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Aug 2015 14:20:22 -0700

> Discussion of AES vs. ChaCha shouldn't be popping up to this

So this protocol negotiates how to negotiate?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Aug 2015 14:24:05 -0700

> So this protocol negotiates how to negotiate?

That's my read on it.  That's a natural consequence of layering.  You
can make your own assessment about whether that is too much, but in
this case, I don't think that it is.

---

From: David Mazieres <[email-masked]>
Date: Mon, 24 Aug 2015 14:44:54 -0700

> Discussion of AES vs. ChaCha shouldn't be popping up to this

Watson has lodged a specific objection to the fact that TCP-ENO allows
hosts to express preferences for TCP-ENO specs, vs. having the IETF
impose a total ordering on the specs.  By analogy, he gave the example
of always preferring SSHv2 over SSHv1 (though I note that OpenSSH
permits you to overwrite this default by putting "Protocol 1,2" in a
stanza, and people actually do this sometimes to accommodate old
authorized_keys files with v1-format user keys).

The issue relates to ciphers because TCP-ENO can be used to negotiate
cipher suites.  Indeed, that is how we are currently rewriting the
tcpcrypt draft, and it has significantly simplified things.  Even if our
initial TCPINC spec supports negotiation outside of TCP-ENO (as
TCP-use-TLS does), we still need to allow the possibility of ENO being
used to negotiate cipher suites, because if we ever get large SYN
options, we will want a new spec that starts an ECDH exchange in the
SYN-ACK (or possibly even initial SYN) segment.

In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK
segment today.  That means even without large SYN options, we can
imagine making TCPINC zero latency.  Realistically, doing so will
require a gross hack in which TCP-ENO compactly encodes timestamp and
SACK availability, window scaling, etc., in lieu of larger options.  I
don't expect people would be very happy with something like that from
day one.  But we don't want to shut the door to such an optimization
either, in case TCPINC becomes a runaway success.  (We've been careful
to leave a bunch of reserved suboptions in the TCP-ENO spec just in case
we need extra bits for such optimizations.)

That said, Watson has a point that even more simplicity is to be gained
by just picking some particular cipher suite that works.  I respect this
argument, but given how many future unknowns are associated with any
choice of cipher suite, and given the additional hurdles this may create
to standardization (as it forces us to argue over ciphers as well), I'm
unpersuaded by his argument.  Thus, unless a bunch of other people voice
the same opinion, I do not anticipate the group would want to remove the
preference mechanism from TCP-ENO.

David

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Aug 2015 22:59:41 +0100

On 24/08/15 22:44, David Mazieres wrote:
> cipher suites.  

It is not at all clear to me that that'd be a good plan. I think
the gross-hack that it may one-day open up is unlikely to be worth
it, and negotiating once is bad enough so it'd seem like a bad
plan to do it twice, which I think would be the inevitable outcome.

But so long as tcpcrypt is not a WG document that's your call I guess.

My take fwiw would be that a TCP option should really only signal
turning on TCPINC full stop. And that TCPINC initially ought only
have two ciphersuites defined, one for use now and a backup. But
TPCINC will have to support some form of algorithm agility so that
that pair of ciphersuites can be changed over time. So yes some
form of agility is needed but it's not clear to me that a TLS-like
scheme is best.

If/when practical deployment of DH values becomes feasible then
it'd be time to discuss how to use that. But not now when that is
not, if I understand correctly, possible to do that.

However, a caveat - I've not had time to read all of this thread
so apologies if I'm off base a bit.

S.

> Indeed, that is how we are currently rewriting the

---

From: David Mazieres <[email-masked]>
Date: Mon, 24 Aug 2015 15:10:27 -0700

> So this protocol negotiates how to negotiate?

It doesn't have to.  This may be one of the differences between tcpcrypt
and TCP-use-TLS, where tcpcrypt is in the process ditching its own
negotiation mechanism in favor of ENO, while TLS will just keep the TLS
mechanism.  This seems like the best way to capitalize on the relative
merits of the two protocols, where tcpcrypt's selling points are its
simplicity and custom fit with TCP, vs. TCP-use-TLS whose selling point
is reusing mechanisms and analysis from TLS.

David

---

From: David Mazieres <[email-masked]>
Date: Mon, 24 Aug 2015 15:48:39 -0700

> plan to do it twice, which I think would be the inevitable outcome.

Sorry, I can't reconcile the first and last sentence of that paragraph.
If negotiated TCP-ENO spec implies a specific cipher suite, then you
only negotiate once.  If TCP-ENO specs have multiple cipher suites, then
you have two negotiations, first the ENO-level meta-negotiation on how
to negotiate, then a second cipher suite within the particular
encryption spec.

Your first sentence reads like a recommendation *not* to tie a single
cipher suite to a single TCP-ENO suboption, in which case you'd need a
separate cipher suite negotiation mechanism.  Your second sentence
implies you consider two rounds of negotiation a bad idea, in which case
why wouldn't you want ENO to negotiate the cipher suite.  We value your
opinion on this question, so please clarify!

> But so long as tcpcrypt is not a WG document that's your call I guess.

We are currently rewriting tcpcrypt to consume three ENO suboptions, one
for P-256+AES-128, one for P-512+AES-256, and one for
Curve25519+Chacha/Poly1305.  Compared to the existing draft, this lets
us ditch PKCONF and pretty much everything except the DH parameters in
INIT1 and INIT2 messages.  We are also ditching RSA (which at this point
was there "just in case," because tcpcrypt had to be future compatible
with things other than DH, but now ENO frees us from worrying about
future compatibility).  The result is a much simpler document.

But this is all easy to change until we've updated the code to match the
forthcoming document, so high-level feedback now would be appreciated.

> form of agility is needed but it's not clear to me that a TLS-like

Given that latency is critical, at a minimum we have to start the
public-key cipher negotiation in the SYN-ACK of a three-way handshake.
So why not have the TCP-ENO suboption just specify the ciphersuite?

> not, if I understand correctly, possible to do that.

Well, it is possible today.  What's not not possible is to do that and
enable TCP timestamp for the same connection.

David

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 25 Aug 2015 10:05:01 +0000

> In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK segment today.  That means even without large SYN options, we can imagine making TCPINC zero latency.  Realistically, doing so will > require a gross hack in which TCP-ENO compactly encodes timestamp and SACK availability, window scaling, etc., in lieu of larger options.  I don't expect people would be very happy with something like > that from day one.  But we don't want to shut the door to such an optimization either, in case TCPINC becomes a runaway success.  (We've been careful to leave a bunch of reserved suboptions in the TCP-> ENO spec just in case we need extra bits for such optimizations.)

I've not followed this thread. But this discussion about long options in SYN, modifying existing TCP options, etc. really scares me. I've always thought TCPINC's objective is to provide *payload* encryption, and negotiating this should IMHO not require any complex option.

I am also confused about the actual technical details in this discussion. In my understanding, the SYN-ACK for any modern high-speed TCP stack has to carry MSS (4 bytes), windows scale (3 bytes), and SACK permitted (2 bytes). This means that at most 31 bytes are left (in theory, we have plenty of other TCP extensions consuming parts of it). Also, I believe some middleboxes/firewalls may act upon those options in the SYN-ACK, i.e., they cannot easily be replaced or encoded in a more compact way. As a result, I somehow don't understand how to get a 32 byte value into SYN-ACK without EDO (draft-ietf-tcpm-tcp-edo). And for EDO there are deployment challenges with using it in the SYN-ACK, see the discussion in TCPM.

In any case, this sort of discussion on SYN option space IMHO should be taken to the TCPM list.

Michael

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Aug 2015 11:59:35 +0100

Hiya,

> Sorry, I can't reconcile the first and last sentence of that paragraph.

If a mechanism defined in the TCP-ENO document "supported" ckiphersuite
negotiation, but was not deployable (which seems like it'd be the case
given attempts to squeeze in 32 bytes of DH public) then you'd end up
having to support algorithm agility in-band anyway. Hence bad-plan +
doing it twice.

> future compatibility).  The result is a much simpler document.

I'll just repeat that I think that's a bad plan and you'd be
better off not making such changes.

S.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Aug 2015 14:38:36 +0300

[I changed the subject to make the discussion easier to follow.]

> disambiguating and picked randomly.

I do not think the b bit is really going to work, and I agree with
others that we need proper tie-breaker to solve this issue.

On the other hand I do not think we need to add large tie breaker to
the frame, we can most likely use something like very small tie
breaker and sequence numbers for tie-breaker. I.e. whoever has smaller
8-bit (or 6-bit) tie breaker is winner, if the tie breakers are same,
then we compare initial sequence numbers, and whoever has smaller
initial sequence number is the initiator and other end responder.

After that we just need to have rules specifying how we pick up the
protocol from two ordered list. The most simple solution would be to
just say we take initiators list, remove all of the protocols not in
the responders list, and then take first item from initiators list
that is also supported by responder.

I.e. the negotiation would be (with same tie breaker selected randomly
in both ends):

A->B(0x9453f454) SYN: Tie breaker=33; I can speak Z, Y
B->A(0x434945e5) SYN: Tie breaker=33; I can speak X, Y, Z

As tie breaker is same, we will check sequence numbers, and as B has
smaller he is the winner, and both ends know this. Following the rules
above, the protocol to be used is Y.

There are of course some middleboxes who do mess up with sequence
numrbers. To detect this we want to tell the result of the exchange to
both ends:

A->B(0x9453f455) ACK: We are using protocol Y
B->A(0x434945e6) ACK: We are using protocol Y, I am initiator

If both ends claim to be initiator, or neither end claims to be
initiator, both ends will know that immediately when they get receive
ACK, and will know that someone messed up the sequence numbers
(provided they didn't happen to be exactly same initially :-).

In that case we need to do something more complicated, or we could
simply say we drop the connection and try again. This is such rare
happening, that wasting extra round trips is much more preferred to
having more complicated protocol solving the tie (simultaneous opens
are rare, both ends happening to select same 8-bit (or 6-bit or
whatever) tie breaker is not very common, having exactly same initial
sequence number is rare, or even if we have middle box messing up
sequence numbers, there is 50% them being in right order anyways).

On the next try both ends will pick new random tie breaker, and this
time they most likely will not be same, and then the simulatenous open
will succeed (or there might even be timing differences, causing one
of them be bit faster, and one of the ends might receive SYN before it
has time to send his SYN out, in which case this will not be
simultaneous open anymore). 

Also if application will know it will NEVER do simulatenous opens
(like web server, or web client), it can do setsockopt that will
disable the Tie breaker option from the option list, saving byte or
two.

Normal open would be:

A->B(0x9453f454) SYN: Tie breaker=33; I can speak Z, Y
B->A(0x434945e5) SYN-ACK: We are using protocol Y
A->B(0x9453f455) ACK: We are using protocol Y, I am initiator

"We are using protocol Y" could also include the initial key exchange
messages for protocol Y, if they fit in option space.
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Aug 2015 10:06:07 -0400

Watson,

On 8/24/15 4:37 PM, Watson Ladd wrote:
> Every lattice has a compatible total order
more properly, a total order can be _imposed_ on a lattice.

> , and preferences are
> expressed as total orders.
The issue here is that reasonable people can disagree about
the total order imposed on the lattice.
> Could you explain how your supposed insight
"supposed insight" seems rather pejorative; better watch out for the
IETF mail list PC police
> possible ciphersuites, and permitting specifying arbitrary preferences
The preferences of others are "arbitrary" but yours are not?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Aug 2015 10:07:04 -0400

Stephen,

> Discussion of AES vs. ChaCha shouldn't be popping up to this
agreed, yet it did, so ...

Steve

---

From: Kyle Rose <[email-masked]>
Date: Tue, 25 Aug 2015 10:11:00 -0400

> The preferences of others are "arbitrary" but yours are not?

Touché.

I don't hear a lot of opposition to maintaining agility in ciphersuite
preference. I am personally in favor of keeping some mechanism
(whether this one or a different one) in place for that purpose,
because it provides much more flexibility than it requires complexity.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Tue, 25 Aug 2015 10:21:56 -0400

> If we are going to add another round of exchanges anyway, though, why
> not do the tie-breaking there?  We could keep the single b bit as is
> (for applications that want to work it out), and then add a
> variable-length tie-breaking phase.  E.g.,
>
>     A->B:  SYN ENO<Z, Y>
>     B->A:  SYN ENO<X, Y, Z>
>     A->B:  ACK ENO<Breaker 0x29892a863ce5>
>     B->A:  ACK ENO<Breaker 0xdb636b5918a2>

Why not dump b entirely and just always require an extra round trip
for simultaneous open? It seems to be enough of an edge case that,
given the options, I'd rather not optimize for it (and also not spend
a disproportionate amount of time debating optimization of something
that is such a long-tail, and practically degenerate, use case).

> Before settling on something, I'd like to get a sense of whether people
> think it's okay to ask applications to signal their intent to use
> simultaneous open, or whether it's important for TCP-ENO to enable
> encryption for existing, unmodified applications that use simultaneous
> open.  Those two options put us down different paths.

IMHO, all applications should be able to benefit from TCPINC's
protection against passive eavesdropping without any changes.

Kyle

---

From: David Mazieres <[email-masked]>
Date: Tue, 25 Aug 2015 07:27:17 -0700

> having to support algorithm agility in-band anyway. Hence bad-plan +

I wish I hadn't conflated things.  What's not deployable today is
putting a DH key exchange into SYN segments.  The downside (in terms of
ruling out timestamp, MSS, etc.) is simply not realistic.  Of course,
that's the long-term dream, so I discussed it, but realistically it
cannot happen without large options, so let's just forget I ever
mentioned it.

What is eminently deployable is using TCP-ENO to negotiate a
ciphersuite.  E.g., you can agree to use curve25519 for ECDHE by the end
of the SYN exchange, and include a DH parameter in the first data
segment of a connection, after only one round trip.

As you say, we probably only need two or three ciphersuites in play at a
time, a primary and one in case the primary starts looking weak, and
maybe third to satisfy diversity of algorithm designers.  So there's no
reason ENO can't chose between these three.

> better off not making such changes.

If you can elaborate on this, we would certainly appreciate it.  We
certainly can leave a second level of negotiation in tcpcrypt--that
would even be easier for us--but it will add pages to the RFC, so it
would help to understand why.

David

---

From: Watson Ladd <[email-masked]>
Date: Tue, 25 Aug 2015 07:43:15 -0700

On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent <[email-masked]> wrote:
> more properly, a total order can be imposed on a lattice.

I don't see the difference between these two statements, and I don't
see the relevance.
> "supposed insight" seems rather pejorative; better watch out for the

Earlier people raised examples of ciphersuites with no comparison
between them. Why does what you are saying matter more? What's the
connection between being a lattice, and picking just one ranking not a
good idea.

> The preferences of others are "arbitrary" but yours are not?

Of course it's an arbitrary choice! My question is why is it not a
good idea to pick a single nothing-else-is better suite. and have a
mechanism designed to support migration if weaknesses are discovered?
So far as I can tell the argument has been that people have different
orderings, and should be allowed to express them. But this doesn't
actually get to the fundamental issue: how much more secure are people
if they will use X instead of Y if the other side wants it, then if
they prefer Y instead of X?

What happens in practice is that we end up with copypasta in config
files. And then when we do need to have a migration, instead of the
next version of the software automatically prefering the new thing,
configurations need to be changed. Of course you can always wash your
hands of this by saying software could have expressed the preferences
differently. But if software is going to do that, then we might as
well chop down on what the mechanism needs to express. There are real
benefits from shrinking code and reducing the complexity of the
versioning mechanism.

Downthread David Menzies is saying we only need three ciphersuites,
with one explicitly as a backup for the other. So what's gained from
being able to reverse that ordering? I do think we can't actually
specify a backup until the primary is weak: remember when RC4 was the
solution for Bard's attack on TLS 1.0?

Sincerely,
Watson Ladd

---

From: David Mazieres <[email-masked]>
Date: Tue, 25 Aug 2015 07:44:59 -0700

> that is such a long-tail, and practically degenerate, use case).

There is one reason this isn't ideal (though I think it might still be
workable), and that is that the first ACK packet might need to contain
spec-specific information (like cipher suite preferences).  If that
information is in options only, then it doesn't consume sequence number
space and now you have the problem of potentially needing to retransmit
two ACKs for the other side's ISN.

> protection against passive eavesdropping without any changes.

That's a perfectly valid position, and we can make it work.  It will
cost some complexity, though, so it would be nice to get clarity on
whether this is also the preference of the whole working group.  I
wouldn't want to jump through hoops to make simultaneous open always
work, then run into objections that it's too complicated or consumes too
much option space.

Note that yet another possibility is to delegate the choice of roles to
the individual encryption specs.  In the case of ECDHE, that's actually
easy to do.  But now the complexity of a fringe use case is bleeding
into multiple documents.

David

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Aug 2015 15:55:47 +0100

Hiya,

On 25/08/15 15:27, David Mazieres wrote:
> I wish I hadn't conflated things. 

Conflating often does that - but none of us are perfect, certainly
not me;-)

> What's not deployable today is

Good.

> segment of a connection, after only one round trip.

So yes one could. But that assumes that the WG have not chosen
to do TLS I think, doesn't it? If the WG did choose TLS then
ciphersuite selection has to happen in the TLS h/s or else we
will not get the security guarantees that TLS is supposed to
give us.

Even without the large options, whacking in ciphersuite specific
values in TCP-ENO now is a bad plan as it (for me anyway) further
muddies the already muddy waters within which we've been fishing
for consensus in this WG. (Apologies for the strained analogy and
even more for the pun in the apology:-)

*If* the WG selected tcpcrypt then it might make sense to see
if algorithm agility could be sufficiently well supported in the TCP
handshake. I'm not sure if it could or not myself. But if the WG
selects TLS or decide to pursue both (ick) then that'd not make
any sense that I can see.

So trying to figure out now if or how algorithm agility can be
handled via TCP options is IMO a bad plan that may move us further
away from rather than towards consensus.

If TCP-ENO is proposed as a meta-negotiation of the security
protocol to use that is arguably different. I still don't like it
(as I don't want us to continue processing both TLS and tcpcrypt,
though it seems like Martin T. disagrees with me on that) but at
least that meta-negotiation wouldn't repeat stuff done within TLS
or tcypcypt so isn't nearly as bad as putting ciphersuite stuff
into TCP options (now).

Cheers,
S.

---

From: John Leslie <[email-masked]>
Date: Tue, 25 Aug 2015 12:44:50 -0400

Scharf, Michael (Michael) <[email-masked]> wrote:
> To: David Mazieres <[email-masked]>...
> 
>> segment today.

   It's always possible to fit _one_ thing in -- what's hard is fitting
all the things folks consider "necessary".

   We've come late to this dance. :^( We should expect a lot of pushback
putting that much in SYN-ACK until there is a Proposed Standard for
expanding the SYN-ACK option space.

>> That means even without large SYN options, we can imagine making TCPINC
>> zero latency.

   "Zero latency" isn't the right target, IMHO. We should be advocating
for low latency by alieviating buffer-bloat latency overall; and designing
a default-case where we're not negotiating in the originating SYN: merely
allowing for negotiation later.

   Until TCPM gets a "round tuit" and increases option space at least for
the SYN-ACK, we're facing an almost insurmountable obstacle to deployment.

>> Realistically, doing so will require a gross hack in which TCP-ENO
>> compactly encodes timestamp and SACK availability, window scaling,
>> etc., in lieu of larger options.

   I strongly advise against going there. Deployment would take forever!

>> I don't expect people would be very happy with something like that from
>> either, in case TCPINC becomes a runaway success.

   Ah! Youthful optimism! It's refreshing to see it!

>> (We've been careful to leave a bunch of reserved suboptions in the
>> TCP-> ENO spec just in case we need extra bits for such optimizations.)
> 
> I've not followed this thread. But this discussion about long options in
> SYN, modifying existing TCP options, etc. really scares me. I've always
> thought TCPINC's objective is to provide *payload* encryption, and
> negotiating this should IMHO not require any complex option.

   I wonder if we _have_ a shared goal there...

> I am also confused about the actual technical details in this
> discussion. In my understanding, the SYN-ACK for any modern high-speed
> TCP stack has to carry MSS (4 bytes), windows scale (3 bytes), and
> SACK permitted (2 bytes).

   (In _many_ cases, timestamp is automatically included, in order to
disambiguate over-large bandwidth-delay-product and error-correction
algorithms trying to avoid packet loss. This _is_ of course a terrible
design; but we seem to be stuck with it for at least five more years.)

> This means that at most 31 bytes are left (in theory, we have plenty of
> other TCP extensions consuming parts of it).

   +1

> Also, I believe some middleboxes/firewalls may act upon those options
> in the SYN-ACK, i.e., they cannot easily be replaced or encoded in a
> more compact way. As a result, I somehow don't understand how to get a
> 32 byte value into SYN-ACK without EDO (draft-ietf-tcpm-tcp-edo).

   That really _is_ a non-starter. If we want negotiation in the SYN-ACK,
we need to push the TCPM group to publish _some_ Proposed Standard.

   (Myself, I'd rather avoid the need for negotiatting in our first
Proposed Standard: deployment of draft-ietf-tcpm-tcp-edo is going to be
too slow for what I thought our target deployment to be. :^(

> And for EDO there are deployment challenges with using it in the SYN-ACK, see the discussion in TCPM.

   Seriously, we SHOULD follow (and participate in) the TCPM discussion.

> In any case, this sort of discussion on SYN option space IMHO should be

   I suspect we need to continue the discussion here; but recognize that
multi-byte TCP options simply won't be available without TCPM action.

   :^(

--
John Leslie <[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Aug 2015 09:45:38 -0700

> data, so maybe this question should be deferred until later in the

The usual way to handle this is with an [[OPEN ISSUE]] marker.

> That's too general to convince me.

A totally reasonable standard for an individual submission. Less so for a WG
document, which I understand you would like this to be.

> Well, assuming the RFC5737 addresses are publicly routable, obviously B

OK, that was what I was expecting you to say, but unfortunately the
situation
isn't always so simple. Consider what happens from A's perspective if
he is doing trickle ICE and assume for simplicity that B is non-NATed so
he just has the 192.0.2.1 address.

A        Signaling        B        STUN

STUN Check ------------------------->
Host Cand ---->
              Host Cand -->
              <-- Candidate
<--- Candidate
SYN -------------------------------->   X
<---------------------- STUN Response

At the point when A sends his first SYN (labelled X) he knows his host
address
(10.0.0.2) and B's srflx (192.0.2.1) so he thinks his address is lower.
However,
after he gets the STUN response from the server, he learns his srflx and
that it's higher than B's (note: in ICE you do only one check from both
the srflx and the host candidates).

There may be some way to resolve this, but it's not clear to me that in
general
it will be possible, and it's not clear to me in any case how the "b" bit
helps.

> appropriate kind of NAT.

ICE actually does the combinatoric explosion of all the IP address
pairs, not NAT characterization.

> RFC5245 uses an 8-byte tie-breaker.  So to put our options in a table:

Well, 48 versus 64 is just a matter of statistics. I.e., how many failures
are you willing to accept with simultaneous open? To be honest, 32 bits
is probably enough.

> I'm not sure I know what you mean about signaling.

What I mean is that whatever mechanism you used to determine who should
set the 'b' bit seems like it could just as easily determine which side
should
adopt the initiator versus responder role.

> But suppose two

If you're using a rendezvous service like this, you can just put a
tiebreaker in
those messages, no?

>     assign the b bit to the two sides.

I don't understand why the 'b' bit is adding any value in this case, since
each side actually knows in advance which side will be assuming the
initiator role. Why not simply just tell the stack "adopt this role for this
connection regardless of simultaneous open"

> (not just fail to encrypt).  That's very bad.

All right. I'm willing to concede this point.

> encryption after flow 2 and again the whole TCP connection will fail.

I don't find this convincing. Better to make the application protocol fall
back
cleanly.

> For me, I'd rate A a 9/10 and rate B a 5/10, which is why TCP-ENO looks

I think there's a 'C'. How much do you care about preserving option space
*in* simultaneous open? And the answer for me is "not much".

> This is verbatim, no ellipsis or anything.  Seems pretty clear to me.

As I said, I don't think it's particularly dispositive with regard to the
point
I made above about the relationship of forward secrecy to long-running
connections.

The TCP-ENO draft contains the following language:
> properties as TCPINC.

It doesn't seem even obvious to me, let alone beyond debate.

> different hash functions.

Given that I would expect specs to have hash agility, it seems like if we
in fact have this situation, we have a fairly serious problem, and it's
unfortunate that "standard" assumptions don't capture that.

-Ekr

---

From: David Mazieres <[email-masked]>
Date: Tue, 25 Aug 2015 09:54:38 -0700

> will not get the security guarantees that TLS is supposed to

Right.  So my working assumption is that the WG has not killed tcpcrypt
yet, and is still deciding on tcpcrypt vs. TCP-use-TLS.  TCP-ENO is an
effort A) to make progress on common elements of TCP-use-TLS and
tcpcrypt, B) to satisfy people from tcpm who believe (correctly, IMO)
that TCPINC would benefit from future TCP enhancements, and C) to enable
a fixed target API for application writers so that any application-level
efforts to leverage TCPINC will continue to apply even across
significant revisions of TCPINC.

> even more for the pun in the apology:-)

Well, in order to make the choice between tcpcrypt and TCP-use-TLS the
most salient, it seems worth maximizing the advantages of the two
protocols.

The big advantage of TCP-use-TLS is compatibility with TLS.  Hence, the
obvious way to fit TCP-use-TLS onto tcpcrypt is to use a single
ENO suboption to trigger it, and then use as much TLS as possible for
everything else.

The big advantage of tcpcrypt is simplicity (and hence easier analysis)
as well as its tight fit with TCP, for which it was specifically
designed.  So for that our thinking was that TCP-ENO already specifies a
suitable negotiation mechanism, let's not have two different negotiation
mechanisms when we only need one.  It doesn't feel particularly "whacked
in"--in fact there's a very straight-forward fit.  It's basically about
as simple as you can get:

  A->B: SYN      "Hey, I support tcpcrypt suite X and tcpcrypt suite Y"
  B->A: SYN-ACK  "Great, let's use X"
  A->B: ACK      "Agreed, here's my DH parameter"
  B->A: ACK      "Here my DH parameter, ciphertext from here on out"
  ...

The alternative (more like the previous draft of tcpcrypt) would be:

  A->B: SYN      "Hey, I support tcpcrypt and TLS"
  B->A: SYN-ACK  "Great, let's tcpcrypt with cipher suite X or Y"
  A->B: ACK(*)   "I choose X and here's my DH parameter"
  B->A: ACK(*)   "Here my DH parameter, ciphertext from here on out"
  ...

(*)These segments use TCP data for TCPINC messages, not application
   data.

That's also pretty simple, and works perfectly well with the existing
TCP-ENO.  I'd be delighted to do it if we didn't support simultaneous
open.  But simultaneous open risks scenarios like this:

  A->B: SYN      "Hey, I support tcpcrypt and TLS"
  B->A: SYN      "Hey, I support tcpcrypt"
  A->B: ACK(+)   "Great, let's use tcpcrypt with cipher suite X or Y"
  B->A: ACK(+)   "Great, let's use tcpcrypt with cipher suite Z"
  A->B: ACK(*)   DH parameter, etc.

(*)TCP payload includes TCPINC message.

Now this gets messy if either of the segments market (+) is dropped,
because those segments don't consume sequence numbers, and so wouldn't
ordinarily get ACKed.

> any sense that I can see.

So there are multiple issues being discussed in this thread:

  1. Should IETF set a global total order on ENO suboption preference,
     or should hosts be able to configure this?

  2. Should simultaneous open enable encryption with no application
     involvement, or is it okay to require a socket option?

  3. Should tcpcrypt leverage TCP-ENO suboptions for ciphersuite
     negotiation?

Questions 1-2 affect the TCP-ENO draft.  Question 3 does not affect the
TCP-ENO draft.  The discussion touched on both because answering YES to
question 1 forces us to answer NO to question 3.  However, my sense is
that the working group mostly believes the answer to #1 is YES.

In that case, does it not make sense to answer question 3 (which affects
only the next tcpcrypt draft) under the assumption that the WG will
select tcpcrypt?  This is not being presumptuous, it's being realistic
that if the WG does not adopt tcpcrypt, we will have to chuck the
document.  So why not optimize the document for the case in which it
actually gets used, no?

That's not to say the answer to #3 is automatically YES.  We are leaning
towards YES because, a posteriori, having fiddled with the tcpcrypt
draft in the context of ENO, answering YES seems to buy us a lot of
simplicity.  We aren't fully convinced, though, so to the extent people
believe the answer is NO, we very interested in arguments, but only
arguments that still apply under the assumption tcpcrypt is adopted by
the WG.

> away from rather than towards consensus.

But do you still feel this way if the debate becomes one over how to
*use* TCP-ENO, rather than one over what goes in the TCP-ENO document
itself?

David

---

From: Kyle Rose <[email-masked]>
Date: Tue, 25 Aug 2015 13:55:53 -0400

>   A->B: ACK(*)   DH parameter, etc.

One way to resolve this for TLS is to just make TLS one of the cipher suites:

A->B: SYN "Hey, I support (TLS, tcpcryptX, tcpcryptY)"
B->A: SYN "Hey, I support (TLS)"
A->B: ACK "Great, let's use TLS"
B->A: ACK "Great, let's use TLS"

And then switch to straight-up TLS, whether in userspace or in the
kernel. In userspace this is a little tricky in that a software or
administrative change to the cipher suite preference list should be
made when TCP-ENO is activated by default in the kernel: as long as
one of the two endpoints is properly configured, tcpcrypt-unaware
endpoints will do the right thing, but if both endpoints are
improperly configured you'll get two key exchanges and connections
will be doubly-encrypted. (An HTTPS server implementor might just
choose to turn off TCP-ENO for port 443, which would have the desired
effect.)

For passive/active, the same basic logic applies:

A->B: SYN "Hey, I support (TLS, tcpcryptX, tcpcryptY)"
B->A: SYN-ACK "Great, let's use TLS"
B->A: ACK "Ok, let's use TLS"

Kyle

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Aug 2015 15:12:53 -0400

Watson,

> I don't see the difference between these two statements, and I don't
pity, I tried.
>> ....
they're equivalent, but since you seem to bring an academic perspective
to the discussion I thought you might like a more math-oriented response 
;-).
> they prefer Y instead of X?
protocol design is a complex process where there often is not a
single "right" answer. preserving the ability of different sets
of folks to do what they perceive as the "right thing" has often
been a critical element of successful standards. Yes, this can lead
to bad outcomes, but trying to dictate one answer is also likely to
lead to a bad outcome, i.e., nobody adopts the standard.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Aug 2015 21:03:50 +0100

On 25/08/15 17:54, David Mazieres wrote:
> TCP-ENO is an
> tcpcrypt,

The above is reasonable.

...
> most salient, it seems worth maximizing the advantages of the two

I think your goal (A) and "maximising the advantages" of tcpcrypt
(or of TLS) are incompatible goals at this point in time.

If/when the WG adopt tcpcrypt optimisations relating to algorithm
agility will inevitably be explored. If/when the WG adopt TLS that
kind of change wouldn't make sense.

In the meantime trying to squeeze discussion of loads of different
things into discussion about TCP-ENO seems mostly a distraction.

S.

---

From: David Mazieres <[email-masked]>
Date: Wed, 26 Aug 2015 07:07:12 -0700

> he just has the 192.0.2.1 address.

I'm afraid I'm having a hard time following your example.  I didn't
state it, but I was assuming that the RFC1918 addresses were private.
What does it mean to say B is non-NATted in the above diagram?  Are you
saying that you agree with my analysis of the previous diagram and are
now introducing a new example in a different format, or is your point
that there's some sort of "gotcha" with the previous diagram?

> the srflx and the host candidates).

I previously gave three scenarios where tie-breaking works, and said
that the IP-address-based technique works when "The applications use
STUN to learn their public IP address and NAT type and communicate this
to the other node or register it with a public rendezvous service."
That doesn't seem to be what is happening in your diagram.

> it will be possible, and it's not clear to me in any case how the "b" bit

If you remove the b bit from TCP-ENO, there will be pairs of hosts that
can communicate via simultaneously opened TCP connections that cannot
use TCP-level encryption.  The goal of the b bit is to ensure that, with
appropriate application involvement, it is always possible for
applications to use encryption where they can communicate.  The goal is
*not* to guarantee that this will happen transparently.

I haven't seen anyone argue that the b bit fails to achieve its goal.
Rather, some people seem to be arguing that this is the wrong goal, that
in fact TCP-ENO should work with unmodified applications in simultaneous
open.  In fact, there are four reasonable goals the WG could shoot for:

 1. Simultaneous open never gets encryption (but still works).

 2. Simultaneous open gets encryption only if modified applications
    indicate their intention to use simultaneous open AND do the work of
    breaking the tie (this is the current TCP-ENO position).

 3. Simultaneous open gets encryption only if modified applications
    indicate their intention to use simultaneous open (this it the
    current TCP-use-TLS position).

 4. Simultaneous open gets encryption with unmodified applications.

My current (not very strong) position is #2.  Given that you wrote
TCP-use-TLS, I assume your position is #3.  Frankly, there's very little
difference between those two positions.  The distinction is also
orthogonal to everything else in our drafts.  TCP-use-TLS could easily
be modified to have a "b" bit, while TCP-ENO could easily just adopt
TCP-use-TLS's tie-breaker mechanism.  I'd be happy to adopt position #3
if a clear working group consensus formed around that goal.  Switching
between #2 and #3 would require relatively minor changes to either
draft, so uncertainty around the goal shouldn't be a reason to delay
adoption of a draft.

That said, I'd be far more concerned with #4 for either TCP-ENO or
TCP-use-TLS.  It's not that we can't achieve goal #4 if the working
group expresses a strong preference for it.  It's just that doing so
will inflict carnage on both of our drafts in the form of increased
option space usage for non-simultaneous open and/or complex, rarely-used
code paths in implementations (such as extra timers not linked to
sequence numbers, etc.).

So before we embrace goal #4, it would be nice to get a bit more data
about how simultaneous open is used in practice.  In particular, if
people are working from a mental model like:

    A->B: SYN
    B->A: SYN
    A->B: ACK
    B->A: ACK

Then that may be too simplistic.  On the open Internet, unless you are
very lucky with timing, two concurrent connects would actually look like
this:

    A->B: SYN
    B->A: RST
    B->A: SYN
    A->B: RST

So that's not good.  Of course, you don't need simultaneous open on the
open Internet; you only need it with a NAT at both ends.  So the actual
picture in practice looks more like the following:

    A->B: SYN   [A's NAT opens port, B's NAT drops packet]
    B->A: SYN
    A->B: ACK   (or does A retransmit its SYN?)
    B->A: ACK

In fact, in this situation, I'm not sure any of the drafts work, unless
A retransmits the SYN.  But if it retransmits the SYN after receiving
the other side's SYN, maybe that could be used to break the tie.  And if
it doesn't retransmit the SYN, does B fail to learn A's tie-breaker?

In short, *if* the working group decides to target goal #4, someone
needs to go out and do the work of characterizing actual uses of
simultaneous open with actual middleboxes.  Regardless of which draft
the WG adopts, we shouldn't waste 6 bytes of option space and/or
hundreds of lines of implementation code on something we don't know is
necessary and don't even know for sure will work.

Since TCPINC has been around for over a year and neither of the two main
candidate drafts has yet attempted goal #4, perhaps we should say that
fully-transparent encryption with simultaneous open is not a high enough
priority to delay TCPINC progress.  If some subdelegation wants to
investigate the problem in parallel and report back with some data,
there's no reason the WG couldn't later move to accommodate the results.

David

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 26 Aug 2015 17:47:20 +0200

Hi Stephen,

just to double-check if I understand correctly what you are saying:

You basically say that you would not support the tcp-eno approach because you would like to have for any tcpinc protocol (not matter if tcp-use-tls or tcpcrypt) only a very simple negotiation in a TCP option where both ends confirm that they support tcpinc and then all additional negotiation is done in the payload data space (and therefore an own document is not needed)?

What’s about the argument, that I believe you’ve stated earlier yourself, that one could use tcp-eno to update to a new protocol version (not only a new cipher) in case we detect flaws in the general protocol design…? If you think this is useful to have, would it then make then to have an own document for it (and potentially take the tcp-eno proposal as a starting point)?

Mirja

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: [email-masked]
------------------------------------------

---

From: ianG <[email-masked]>
Date: Wed, 26 Aug 2015 16:53:41 +0100

> ....  Ultimately this comes down to a question of

For me - I'd rate B as lower, a 2.  But I'd really like to find out why 
this even exists.  Is there some way for someone who's got the kit to go 
out and measure how & where simultaneous opens are happening?

Without some data, this discussion is too theoretical;  I'd suggest 
dropping simultaneous open until someone can provide the fuller case.

> different hash functions.

That doesn't work for me.  If someone can compute that, then

   (a) we've got much bigger problems with the hashes, and both of them 
needed to be deprecated a few years back,
   (b) most all other protocols are in deep-doo-doo and
   (c) this is TCPINC - we really don't care that much if the attacker 
can just kick the packets and force TCP to plaintext.

IOW, accept that risk.  Trust the crypto - it's the strongest thing 
we've got.

Or did I miss something?

iang

---

From: ianG <[email-masked]>
Date: Wed, 26 Aug 2015 17:03:09 +0100

> rankings risks delaying standardization to argue over which specs should

Again, this argument doesn't apply to TCPINC.  If someone (anyone) 
specifies a certain algorithm at management level, they can and should 
use TLS.  And, that especially applies to the banks in Russia...

The notion that someone is both specifying TCPINC and specifying 
algorithm suite XXX appears too constructed to get much credence.

iang

ps; The argument doesn't apply generally either:

a. We here are far better placed to choose the Internet's crypto suite 
for the general case than any manager, committee, or sysadm.
b. If the Russians don't trust it, they are entirely at liberty to write 
their own crypto protocol and back-fit it into their software.  It's not 
that hard, and if they care - which they do for natsec - they'll be 
backfitting software anyway.
c. the deployment argument wins over for the banks.
d. Unlike the WB/IMF/UN, IETF isn't a subsidy organisation to deliver 
solutions to governments.  It delivers to the masses, not any particular 
squeaky wheel.
e.  etc...

---

From: ianG <[email-masked]>
Date: Wed, 26 Aug 2015 17:09:53 +0100

> AES-GCM vs ChaCha20/Poly1305. Which is superior?

To dig us out of this rabbit hole, I suggest the question should not be 
which is better, but what is the method by which we pick?

I posit that the objective & aligned way is to tell the proposer of the 
draft to pick.  E.g., David for tcpcrypt.  Eric for tls-in-tcp.

Done deal.

iang

---

From: ianG <[email-masked]>
Date: Wed, 26 Aug 2015 17:34:38 +0100

>> The preferences of others are "arbitrary" but yours are not?

Arbitrary is fair enough.  The experiences out in sysadmland support 
that (cite https://bettercrypto.org/ ).

> preference.

<cough>  It was discussed about 6 months to a year ago.

The alternate -- loosely known as 1TCS or one true cipher suite -- has 
been proposed on the basis that if it is ever going to be useful, then 
the place it will be most useful is TCPINC.  Because TCPINC is MITMable 
anyway, why worry so much about the purported benefits of algorithmic 
agility?

However basic IETF consensus or practice is that protocols maintain 
agility, and there is a coming draft on that.

> I am personally in favor of keeping some mechanism

iang

---

From: Kyle Rose <[email-masked]>
Date: Wed, 26 Aug 2015 13:14:18 -0400

> The alternate -- loosely known as 1TCS or one true cipher suite -- has been
> proposed on the basis that if it is ever going to be useful, then the place
> it will be most useful is TCPINC.  Because TCPINC is MITMable anyway, why
> worry so much about the purported benefits of algorithmic agility?

You may have an argument for a minimal implementation of the WG's
goals, but both TCP-ENO/tcpcrypt and TLS-over-TCP are trying to
achieve a solution for opportunistic encryption that is also the basis
for an authenticated channel for applications that want the upgrade
against active attacks.

If, in the case of tcpcrypt, the cipher suite is chosen by the kernel
at connection time before the application is even told that the
connection has been established, then it's critical for that cipher
suite to be secure against active attacks in the presence of endpoint
authentication. Best practice here is that it be upgradeable, because
nothing is secure forever. Strictly speaking, I think the 1TCS notion
is *possible*, but there's simply no way to rule out future
revolutions in cryptanalysis.

> However basic IETF consensus or practice is that protocols maintain agility,
> and there is a coming draft on that.

Agreed in principle, but can you be more specific on this draft?

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Wed, 26 Aug 2015 13:25:20 -0400

> a. We here are far better placed to choose the Internet's crypto suite for
> the general case than any manager, committee, or sysadm.

Agreed, but how are you proposing to force a change when a particular
cipher suite starts to show its age? It seems that those decisions
need to be made locally as software is upgraded, and certainly it is
not realistic for a global change to be done atomically. No agility
now => no ability to change, ever. I've been down this path too many
times to have hope.

> backfitting software anyway.

I think I might agree about any one specific case, but at what point
are the goals of the WG defeated by this attitude? Only the Russians?
"Ok, I guess." The Russians and the Chinese? "Well, that's a lot of
people..." The entire US government too? "Uh..." What about the
banking system? "..."

The high level goal here is to have a framework for global encryption
of all TCP traffic. Fragmentation acts against this goal.

> solutions to governments.  It delivers to the masses, not any particular

Absolutely. But I think there are enough squeaky wheels on this issue
that they are a substantial constituent of the wider internet
community, and not simply ornery outliers.

Kyle

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Aug 2015 18:52:45 +0100

Hiya,

> just to double-check if I understand correctly what you are saying:

I don't think we're saying the same thing. My fault probably, but
I'll try again below:-)

> 
> You basically say that you would not support the tcp-eno approach
> because you would like to have for any tcpinc protocol (not matter if
> tcp-use-tls or tcpcrypt) only a very simple negotiation in a TCP
> option where both ends confirm that they support tcpinc and then all
> additional negotiation is done in the payload data space (and
> therefore an own document is not needed)?
> 
> What’s about the argument, that I believe you’ve stated earlier
> yourself, that one could use tcp-eno to update to a new protocol
> version (not only a new cipher) in case we detect flaws in the
> general protocol design…? If you think this is useful to have, would
> it then make then to have an own document for it (and potentially
> take the tcp-eno proposal as a starting point)?

Until the WG have selected between tcpcrypt and tcp-use-tls
I don't think it makes any sense for tcp-eno to delve into
ciphersuite or cryptographic algorithm details.

After the WG have selected tcpcrypt or tcp-use-tls:
- if the WG pursue only tcpcrypt it may make sense to handle
  algorithm agility in a TCP option (I'm not sure if it would
  or not but it'd be worth a look)
- if the WG select tcp-use-tls I don't think it makes sense
  to try handle any algorithm agility in a TCP option

The reason is that adding ciphersuite details into tcp-eno when
tcp-use-tls might be used could mean negotiating the same thing
twice, once in a TCP option and the 2nd time in the TLS handshake.
That seems like a bad idea that could create potential new
vulnerabilities, or at least confusion, bugs and possible lack
of interop.

If tcp-eno is only negotiating (or indicating) that tcpcrypt or
tcp-use-tls will be used, or that version-N of one of those will
be used, that could work, but I'm not so keen on it as it might
move the wg towards pursuing both tcpcrypt and tcp-use-tls in
the longer term, and I think one of the things on which the wg
did have consensus was that tcpinc would be based on only one
of those and that the wg would not continue to work on both
options beyond the next IETF meeting.

Does that help?

Cheers,
S.

>>> TCP-ENO is an effort A) to make progress on common elements of
>>> TCP-use-TLS and tcpcrypt,
>> 
>> The above is reasonable.
>> 
>> ...
>>> Well, in order to make the choice between tcpcrypt and
>>> TCP-use-TLS the most salient, it seems worth maximizing the
>>> advantages of the two protocols.
>> 
>> _______________________________________________ Tcpinc mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/tcpinc
>> 
>

---

From: ianG <[email-masked]>
Date: Wed, 26 Aug 2015 19:32:48 +0100

> Agreed in principle, but can you be more specific on this draft?

https://tools.ietf.org/html/draft-iab-crypto-alg-agility-06

Being reviewed on [saag] as we speak.

iang

---

From: ianG <[email-masked]>
Date: Wed, 26 Aug 2015 19:58:31 +0100

On 26/08/2015 18:25 pm, Kyle Rose wrote:
> cipher suite starts to show its age?

v += 1

Eg:  SSL v2 -> v3 -> TLS 1.0 -> 1.1 -> 1.2 -> 1.3

The changes in the protocols needed generally exceed the lifetime of 
well-chosen ciphersuites, so any upgrades won't unduly increase the 
cycle count much.

> It seems that those decisions

Well, the experience is pointing to security upgrades being pushed by 
the product supporter out to user land, and sysadms following the 
general advice "keep all software up to date."  In user land this is 
enacted by Apply updates, patch Tuesday and the like.  The sore thumb 
here is Android.  99% of sysadms don't care whether it is TLS 1.1 or TLS 
1.2, they just want it to work.

> people..." The entire US government too? "Uh..." What about the

That's a hypothetical.  But assuming that there is some merit to that, 
why not?  The goal is to stop mass surveillance, right?

And, for TCPINC - do we care that much?  Why not have the Russians, the 
Chinese, and the NSA advise that TCPINC is bad for them, so they're 
going to ... do their own.

Isn't that the endorsement we need?

> of all TCP traffic. Fragmentation acts against this goal.

Right.  And being all things to all governments is probably going to be 
a bigger fragmentation than charging ahead and doing the tcpcrypt thing 
fast and furious, with one cipher suite.

Tcpcrypt could have been already out in v0.1 by now.  We could have been 
rolling it out for 6m already, and starting to think about v1.0.

Instead we're chasing a "perfect" protocol in an imperfect MITMable 
threat scenario.  Who's winning here?

> community, and not simply ornery outliers.

The nature of the squeaky wheel is to say "squeak!  Listen to me or 
else."  But if you don't listen, the wheel suddenly starts rolling, 
because it doesn't want to miss out.

It's an economic thing - formation of cartels, equilibria and all - the 
incumbent argues against the new order, as much as possible, but once 
it's a done deal, the incumbent adopts.

Which is to say, in order to make this argument stick "we have to listen 
to the Russians, Chinese, NSA and other squeaky wheels" you'd also have 
to show that they won't suddenly find some oil when the machine starts 
moving without them, *and* they represent a constituency that can shift 
the internet.

Of course - you will recognise I am actually arguing against consensus 
model to an extent.  But that's a given for this topic.  Mass 
surveillance, TCPINC, we know there are going to be people who fight 
this one.

All governments are recused.

iang

ps; if you want to take this private, I'm happy - I'm pretty sure I'm 
arguing from the golf course rough, not the IETF rough.

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 26 Aug 2015 21:31:20 +0200

Hi,

> Am 26.08.2015 um 19:52 schrieb Stephen Farrell <[email-masked]>:
> 
> 
> Hiya,
> 

Okay, thanks for clarification… I was just trying to figure out what your view is or rather what the implications for tcp-eno are.

> ciphersuite or cryptographic algorithm details.

I personally agree!

>  to try handle any algorithm agility in a TCP option

Okay.

> vulnerabilities, or at least confusion, bugs and possible lack

Agreed. I don’t think anybody wants to negotiate the same thing twice here. And it definitely should be avoided.

> options beyond the next IETF meeting.

I guess tcpcrpyt and tcp-use-tls could be two different versions of tcpinc.
So of course versioning would allow the wg to keep working on both approaches; which might be good or bad, but I anyway double you can easily keep people from working on one or the others.
However, just to make this clear, we as a working group don’t need to work on both approaches at the same time (even though we can if that’s what the wg wants to do). Just as an examples, versioning, as it could be provided by tcp-eno, would for example allow the wg to specify tcpcrypt now because the wg believe that’s the quickest and straight-forward solution and then alterwards specify a next version that uses TLS as soon as 1.3 is ready and has proven to be well applicable to tcpinc. Or the wg could go for tcp-use-tls now and as soon as the new tcp-eno option has proven to be usable in the Internet, the wg could start working on a different negotiation that is better integrated with tcp and only use the actual data encryption of tls… I’m not saying we should go for any of these two examples; just saying that a way to update tcpinc basically completely as tcp-eno provides can be beneficial. 

> Does that help?

Yes, a lot. Thanks!

Mirja

---

From: David Mazieres <[email-masked]>
Date: Wed, 26 Aug 2015 14:04:31 -0700

> ciphersuite or cryptographic algorithm details.

Okay, but I just want to clarify one thing:  We should separate TCP-ENO,
the draft, from my (possibly ill-advised) ramblings on this mailing
list, even though I'm an author of TCP-ENO.

TCP-ENO provides negotiation in the abstract.  That could be used to
negotiate between TCPINC v1 and v2, or TLS v1.3 and v2.0, or someday
TCPINC with and without large option/dedicate middlebox support, or
anything else.  ENO could also be used to negotiate between TCPINC with
one cipher suite and TCPINC with another cipher suite, *if TCPINC itself
does not negotiate cipher suites* (which means it's not TLS).  We can
debate whether or not the latter use of TCP-ENO is a good idea, but that
probably won't be a particularly useful debate at this point.

If the WG adopts TCP-ENO and TLS, I don't think anybody believes ENO
should specify cipher suites.  Rather, it should negotiate how to embed
TLS into TCP (especially if TCPM does something we can take advantage
of) or maybe what version of TLS to use (in the event that something
about TCP-use-TLS could benefit from a significant rearchitecting to
take advantage of TLS 2.0).

David

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Aug 2015 22:30:08 +0100

> take advantage of TLS 2.0).

That all makes sense to me,
Thanks,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Aug 2015 17:24:43 -0700

> that there's some sort of "gotcha" with the previous diagram?

I believe that the previous diagram actually has this problem as well but
I realized in the meantime that you didn't need B to be NATted to produce
the problem, so I decided to simplify. Sorry about the confusion.

> That doesn't seem to be what is happening in your diagram.

This is the first class: you learn your public IP and communicate it to
the other node via a rendezvous service. In fact, it's the "trickle" variant
of ICE, which is what WebRTC uses.

Note: you can't really build a reliable NAT traversal system where you
use STUN to learn your public address and then register it because
too many NATs have unstable bindings or require you to open pinholes.
We tried that and it didn't work which is why ICE is the way it is.

> use TCP-level encryption.

OK, I don't understand that. Can you please provide an example of a case
where the "b" bit helps that the sides couldn't have already broken the
tie via out-of-band signaling.

That's precisely what I am arguing with the example above.

> TCP-use-TLS, I assume your position is #3.

Yes, but it's not a very strong position.

Frankly, there's very little
> TCP-use-TLS's tie-breaker mechanism.

I agree with this as well and I agree that #2 is a viable position. The open
issue for me is whether the "b" bit actually accomplishes that goal.

> there's no reason the WG couldn't later move to accommodate the results.

This seems like a good proposal. FWIW, the major applications that I know of
that use TCP-SO for NAT traversal have their own COMSEC anyway and
in fact often treat TCP as if it were UDP.

-Ekr

---

From: David Mazieres <[email-masked]>
Date: Wed, 26 Aug 2015 22:28:51 -0700

> We tried that and it didn't work which is why ICE is the way it is.

Can you demonstrate simultaneous open without stable NAT bindings?  I
don't see how that could work.  But if it can, then a simplified packet
trace would be super helpful to this discussion.

> tie via out-of-band signaling.

I'm not sure I understand your comment.  The "b" bit assumes the
applications have broken the tie via out-of-band signaling.  It is the
mechanism that permits you to have encryption when applications break
the tie.  So no "b" bit means no encryption on simultaneous open, ever.

> That's precisely what I am arguing with the example above.

So to be clear, the goal is that if applications can break the tie, the
"b" bit allows encryption with simultaneous open.  If you believe
there's a case where simultaneous open will still fail to encrypt, even
with the "b" bits correctly set, can you break it down on a
packet-by-packet basis (for the first 4 packets of the connection)?
Such a four-segment example with two SYNs and two ACKs would really
advance the debate.

> issue for me is whether the "b" bit actually accomplishes that goal.

Well, it looks like this:

    A -> B:  SYN ENO<b=0>
    B -> A:  SYN ENO<b=1>
    A -> B:  ACK
    B -> A:  ACK

You might argue that applications won't break the tie properly, but I
don't see why you think the "b" bit wouldn't work if they do.

> in fact often treat TCP as if it were UDP.

Ah... great.  Sounds like progress.  Also, do you mind sharing what
those major TCP-SO applications are?  It would add some badly needed
context to this discussion.

Thanks,
David

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Aug 2015 10:55:05 +0200

Hi David,

I believe the point is, if you have already broken the tie via out-of-band signal and both endpoints have already decided who will be the opener (host A) and responder (host B), why do you still need to write this information in the tcp-eno option if this information is already known to the host?

Mirja

> Am 27.08.2015 um 07:28 schrieb David Mazieres <[email-masked]>:
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Aug 2015 16:59:40 +0200

Don't you need anyway an internal interface to say that tcp-eno has to set the 
"b" bit?

That's simply saying to tcp-eno that this side will be the host A. Isn't this 
sufficient? Or do I miss something?

Mirja

On 27.08.2015 16:49, David Mazieres expires 2015-11-25 PST wrote:
> Mirja Kühlewind <[email-masked]> writes:
>
>> Hi David,
>>
>> I believe the point is, if you have already broken the tie via
>> out-of-band signal and both endpoints have already decided who will be
>> the opener (host A) and responder (host B), why do you still need to
>> write this information in the tcp-eno option if this information is
>> already known to the host?
>
> Because without the "b" bit, TCP-ENO has no way of knowing that it's
> known to the host.  I'm operating under the assumption that we still
> want to fall back to a working unencrypted TCP connection in the event
> that the endpoints do not properly break the tie.  Is that not the case?
>
> David
>

---

From: David Mazieres <[email-masked]>
Date: Thu, 27 Aug 2015 09:13:47 -0700

Mirja Kühlewind <[email-masked]> writes:

> Don't you need anyway an internal interface to say that tcp-eno has to
> set the "b" bit?
>

You need both a local interface to set the role, and a bit on the wire
to verify that the remote application set is role compatibly.  Isn't
that the minimum necessary to break the symmetry of simultaneous open?
Anything less risks complete connection failure (not just fallback to
plaintext) when the tie is incorrectly broken.

David

---

From: [email-masked]
Date: Thu, 27 Aug 2015 08:40:26 -0700

Tero Kivinen <[email-masked]> writes:

>> This is doable, though adds complexity to implementations.  Should this
>> tie-breaker be sent by every active opener (and therefore consume option
>> space), or do you imagine that applications intending to use
>> simultaneous open set an option to include the tie breaker?
>
> I think tcpinc charter says we must work with unmodified applications,
> so I think the default needs to be send it, but allow API call to
> disable it. 

Well, it would be nice to have some evidence that always sending the
tie-breaker would make things work with unmodified applications.  I'm
not saying such applications don't exist, but I think we are debating
the point with insufficient data.

> Also as tie-breaker is only needed in the simultaneous opens, and
> simulatenous opens with NATs in the middle are not that common.

Again, we need some evidence here.  As far as I can tell, it's not even
possible to make simultaneous open work reliably *without* NATs or at
least stateful firewalls (that are likely to modulate sequence numbers
and timestamps) on both ends, because otherwise you risk RST segments.
Also, there's really no reason applications would use simultaneous open
without NATs.  I may be wrong, in which case I would love for someone to
explain how applications use simultaneous open without NATs.

Now you are asserting that simultaneous open is not common *with* NATs.
You may be right.  But also we may both be right, in which case the
conclusion is that simultaneous open just isn't really used period, so
let's not add a lot of complexity or option space to deal with something
that doesn't happen.

> By our charter, I think we need to work with unmodified applications,
> but we can provide API to allow optimizations and other things later.

But for that we need an example application.  Otherwise, we can argue
about whether simultaneous open should work with or without NATs, with
or without sequence number modulation, etc., but we are basically
designing in the dark.  I mean if we are giving up on NAT anyway, then
we could break the tie with port numbers and IP addresses.

I don't mind something simple like dedicating one bit to simultaneous
open in case that's someday useful.  But if we start to add a lot of
complexity or consume a lot of option space, I don't think we can
justify that in the abstract--we need to look at real applications.

David

---

From: [email-masked]
Date: Thu, 27 Aug 2015 07:49:47 -0700

David

---

From: Kyle Rose <[email-masked]>
Date: Thu, 27 Aug 2015 12:52:38 -0400

I think maybe what Mirja is implying is that it's okay to break TCP
(i.e., not fall back to unencrypted) if the two peers explicitly set
their roles locally to the same thing. TCP-ENO-aware applications that
set the role are assumed to get it right and not set both to A or both
to B.

Question re: the WG goals: is it in fact okay not to always fall back
to unencrypted TCP if the applications themselves are aware of TCPINC
and relying on TCPINC-specific API calls?

Kyle

---

From: David Mazieres <[email-masked]>
Date: Thu, 27 Aug 2015 10:32:48 -0700

> and relying on TCPINC-specific API calls?

So to be pedantic here, we are now assuming a design with three local
states for each side, let's call them NULL, A, and B.  If both sides of
a simultaneous open are NULL (the default) you get unencrypted TCP.  If
one side is A and the other is B, you get TCP-ENO.  In the other 6
permutations, you get complete connection failure.

I don't particularly love that or foresee getting a WG consensus behind
it, but I guess I could live with it.  Moreover, it doesn't really
address any of the "hot" TCP-SO questions at this point, which are:

 1. Does TCP-SO really exist in the wild, and if so under what
    circumstances (NAT, no NAT, etc.)?

 2. If applications of TCP-SO exist, must TCPINC support them
    unmodified, or is it okay to disable encryption in the absence of a
    setsockopt on at least one end of the connection?

 3. If we require a setsockopt to encrypt a TCP-SO connection, is it
    okay to ask applications to break the tie as well?

For my part, I'm beginning to have doubts about 1, but answer YES to 2
and 3.

David

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2015 10:34:30 -0700

>     circumstances (NAT, no NAT, etc.)?

TCP-SO definitely exists in the wild. We do it in Firefox's ICE stack.

-Ekr

---

From: David Mazieres <[email-masked]>
Date: Thu, 27 Aug 2015 23:56:17 -0700

> TCP-SO definitely exists in the wild. We do it in Firefox's ICE stack.

So I'm not familiar with ICE over TCP, though I see there's now an
RFC6544 on this.  Is that what firefox does?  That's great information.

With RFC6544, could the controlling/controlled roles be used to break
ties?  E.g., with TCP-ENO, could the controlling peer just always set
b=1?

David

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 10:14:51 -0700

On Wed, Aug 26, 2015 at 10:28 PM, David Mazieres <
[email-masked]> wrote:

> don't see how that could work.

The issue is how stable they are over time. My point is that you need
real-time
signaling because you can't publish something and have it be valid 10
minutes
later, not that it's not stable over 5-15 second intervals.

> the tie.  So no "b" bit means no encryption on simultaneous open, ever.

I don't think that's true. See Mirja's point below.

> Such a four-segment example with two SYNs and two ACKs would really

In order to assess the issue, you actually need to see how it interacts
with the NAT traversal algorithm. Here's the example I sent before, with
the following NAT topology.

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

A        Signaling        B        STUN

What appears in the "b" bit in the packet marked with "X"?

> context to this discussion.

The one I am mostly familiar with VoIP, whether of the SIP (3261, etc.)
variety or WebRTC. In either case, you use ICE (RFC 5245, 6544) and
try to set up a channel in parallel via both UDP and TCP (preferring UDP).

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 10:18:20 -0700

> ties?  E.g., with TCP-ENO, could the controlling peer just always set

The problem is that there are situations where each side thinks it is
controlling
("role conflicts"). RFC 5245 has the tiebreaker field to resolve this.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 10:21:31 -0700

I should also mention several other points about this:

1. Chrome doesn't do SO candidates even though it has ICE-TCP.
TCP NAT traversal works so badly that the major argument for ICE-TCP
is to allow for clients to talk to public servers even if they are behind
TCP-only firewalls, and that doesn't require SO.

2. We just added ICE-TCP and we may also remove SO if experience
shows it doesn't help.

3. WebRTC has its own COMSEC so we would want to disable TCPCINC
for these settings in any case.

So I think this is really an argument in favor of "don't worry too much
about SO"

-Ekr

---

From: David Mazieres <[email-masked]>
Date: Fri, 28 Aug 2015 11:56:46 -0700

> ("role conflicts"). RFC 5245 has the tiebreaker field to resolve this.

But isn't the tie broken before probing the candidate addresses?  I
thought the tie breaker was something that went in an SDP message or
something?  With respect to figure 12 in RFC5245, I was assuming the tie
breaker was sent in SDP1 or SDP2, which would occur before the TCP-SO.
But I admit I'm not very knowledgeable about ICE.

Anyway, it's entirely possible that ICE could make setting the b bit a
pain, where a revised protocol could solve this problem (e.g., the
controller that causes this role conflict in the first place could just
assign the b bit).  But since as you say, ICE itself doesn't want
TCPINC, this isn't a big deal.

Really, the goal of the "b" bit was just that if an application cares
enough to break the tie out of band, it should be able to use TCPINC
with TCP-SO.  In this sense, TCP-ENO is shooting for a pretty minimal
goal, but at a pretty minimal cost as well (namely one bit).  At a
higher level, we both agree "don't worry too much about SO".

David

---

From: David Mazieres <[email-masked]>
Date: Fri, 28 Aug 2015 12:21:54 -0700

> later, not that it's not stable over 5-15 second intervals.

Ah, I see.  So you are saying one key issue is effectively the existence
of "brief cone" NATs?  That makes sense.

> I don't think that's true. See Mirja's point below.

Yes, I still don't understand her point, unless we are willing to accept
total connection failure for misconfigured tie breaking.  I very much
want to understand the point, because I think it might warrant changes
to TCP-ENO.  Can you possibly walk me through a simple example where
TCP-SO can work without an in-band "b" bit or tie-breaker value?

> What appears in the "b" bit in the packet marked with "X"?

It looks like the packet marked X is an ordinary SYN segment sent as
part of a three-way handshake to a STUN server (which presumably has a
public IP address, though you don't list it).  In that case, the b bit
is irrelevant.  I suspect I just don't understand how to read your
diagram, but it doesn't appear to contain a TCP-SO flow.

But again, to make sure we are talking about the same thing, I'm not
necessarily saying ICE gives you enough information to set the b bit
correctly.  I'm just saying that if you do set the b bit correctly
(though whatever means, including a modified ICE or signaling
mechanism), you will get TCPINC + TCP-SO.

> try to set up a channel in parallel via both UDP and TCP (preferring UDP).

Okay, so it mostly comes down to ICE?  It's confusing because RFC5245
says, "Note that ICE is not intended for NAT traversal for SIP, which is
assumed to be provided via another mechanism [RFC5626]."  And then
RFC5626 talks about TCP but not simultaneous open.  So far, RFC5382 and
RFC6544 are the only modern RFCs I've found discussing TCP-SO.

David

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 16:16:47 -0700

On Fri, Aug 28, 2015 at 12:21 PM, David Mazieres expires 2015-11-26 PST <
[email-masked]>
wrote:

> total connection failure for misconfigured tie breaking.

I am indeed willing to live with that.

> diagram, but it doesn't appear to contain a TCP-SO flow.

This was supposed to go to B. Sorry about that.

> mechanism), you will get TCPINC + TCP-SO.

Well, it seems like the question is whether or not the "b" bit can be
reliably set correctly, and in particular with the algorithm you propose
based on IP.

> assumed to be provided via another mechanism [RFC5626]."

What that means is that you don't use ICE to set up SIP connections, but SIP
uses ICE for NAT traversal for the RTP.

 -Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 16:22:00 -0700

On Fri, Aug 28, 2015 at 11:56 AM, David Mazieres <
[email-masked]> wrote:

> something?

No. The tiebreaker goes in the STUN checks. The issue is that it's
possible to be in a situation where after the SDP exchange each
side thinks it is controlling.

>   With respect to figure 12 in RFC5245, I was assuming the tie

I think we're finally getting to the place where we have been
misunderstanding
each other. We have some mechanism in the signaling which attempts to
break the symmetry and assign one side as A and one as B. If that mechanism
works, then no signaling in TCP is necessary. However, if that mechanism
does not work, then you have three main choices:

1. Allow things to just fail.
2. Have a mechanism to detect failure and then fall back to ordinary TCP.
This is what the "b" bit primarily does. You could also do this by having
the negotiated security protocol detect that both sides thought they
were (A) or (B) and then discard the handshake and fall back to ordinary
TCP.
3. Have a mechanism to resolve the conflict. This is what a larger
tiebreaker
like the one in TCP-use-TLS or the one in ICE does.

Does that seem like a fair summary of the situation?

-Ekr

---

From: [email-masked]
Date: Fri, 28 Aug 2015 17:04:34 -0700

Eric Rescorla <[email-masked]> writes:

> misunderstanding each other. We have some mechanism in the signaling
> which attempts to break the symmetry and assign one side as A and one
> as B. If that mechanism works, then no signaling in TCP is
> necessary. However, if that mechanism does not work, then you have
> three main choices:
>

Indeed, if Mirja was thinking #1, I was thinking #2, and you were
thinking #3, then this all makes sense.  Frankly, I could live with any
of the three, so long as some application action is required.  The only
thing I strongly oppose is having to support encrypted simultaneous open
without some non-default setting by the connecting application.

In the absence of a TCP-SO application that can use TCPINC, I'm in favor
of doing the minimum work possible for TCP-SO, which I thought was #2,
but maybe is #1.  If you strongly prefer #3, we can easily make TCP-ENO
support it either before or after adoption.

David