Subject: [tcpinc] TCP-ENO - simultaneous open support

From: "Black, David" <[email-masked]>
Date: Thu, 19 Nov 2015 18:42:55 +0000

Everyone,

The discussion on protocol asymmetry has focused on tcpcrypt.  While
that discussion has been interesting and useful, the chairs believe
that the WG should figure out how TCP Simultaneous Open (TCP-SO)
interacts with the TCP Encryption Negotiation Option (TCP-ENO), as
that's where TCP-SO first impacts tcpinc.

There will be at least one tcpinc asymmetric security protocol
(distinct A/B, client/server, passive/active opener or whatever 
roles) as TLS is inherently asymmetric, independent of whether
tcpcrypt is modified to be symmetric (and the chairs also do
not currently see WG rough consensus for such a modification
to tcpcrypt).

Hence the initial focus needs to be on how TCP-ENO functions when
sandwiched between TCP-SO and an asymmetric tcpinc security protocol.
The starting point for this is the TCP-SO discussion in the TCP-ENO
draft:

https://tools.ietf.org/html/draft-ietf-tcpinc-tcpeno-00#section-6.2

TCP-SO is detectable at runtime - SYN sent followed by SYN received
for the same connection causes a TCP connection state machine
transition that is unique to TCP simultaneous open.  More background
on TCP-SO (and its interaction with NATs) can be found in sections
4.2 and 4.3 of RFC 5382:
        https://datatracker.ietf.org/doc/rfc5382/

The first topic is what to do about tcpinc encryption when that
detection happens, starting with:

- Should tcpinc support TCP simultaneous open?  Yes or No

If the WG's answer to that is "No", the next question will be
whether tcpinc should abandon a TCP-SO connection attempt vs.
proceed unencrypted, so it will be helpful for comments that
advocate a "No" answer to express a preference on what to do
when TCP-SO is detected.

If the answer is "Yes," discussion will proceed into options like
those listed in Section 6.2 of the TCP-ENO draft, but the chairs
would like to get to WG rough consensus on TCP-SO support first.

The chairs have seen some concern expressed that a "No" answer might
get veto-ed by the larger Transport Area or the IETF as a whole.
We ask WG participants to set aside this possible veto for the
purpose of discussion because:

1) The right technical answer is the preferred starting point
        in the IETF.

2) The WG charter says that our goal is "to provide reasonable
        security for the majority of connections."  It does not
        say "all connections."  We already know that some connections
        are unworkable - e.g., tcpinc integrity protection is
        incompatible with NAT traversal via a protocol-specific
        NAT-resident ALG (e.g., as used for FTP).

3) The WG chairs intend to take the WG rough consensus on this
        topic and vet it with at least the Transport and ART Areas
        to see what transpires.  Any resulting discussion will have
        a technical foundation and be visible to the WG.

WG rough consensus on the right technical answer is the first
step towards making progress here.

So please comment on:

- Should tcpinc support TCP simultaneous open?  Yes or No
-- If "No," should TCP simultaneous open connection attempts
     be abandoned or proceed unencrypted?

Thanks,
--David & Kyle (in Mirja's absence)

----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Kyle Rose <[email-masked]>
Date: Thu, 19 Nov 2015 21:38:47 -0500

Responding as a member...

>         NAT-resident ALG (e.g., as used for FTP).

I'm not sure these situations are analogous. One point of view is that
tcpinc breaks active FTP, but another is that *firewalls* are what
really break FTP. The use of packet inspection and stateful firewall
rules to punch a hole back through to the client machine for the data
connection (whether NATted or not) constitutes special consideration,
and seems like a terrible hack, as well. Meanwhile, without firewalls,
FTP would work just fine with tcpinc with no special consideration.

This differs from the situation for TCP-SO, in which a "No+Abandoned"
decision means that tcpinc itself is explicitly breaking TCP-SO.

I'm thinking the way FTP works just doesn't really make sense in
modern networks. Owing to firewall difficulties, I haven't used active
FTP in a long time, even on the rare occasions I need to use FTP in
the first place. HTTP seems to have mostly taken over, anyway.

>      be abandoned or proceed unencrypted?

No+Unencrypted. I think TCP-SO is rare enough that there's no reason
for tcpinc to support encryption for those connections, but I don't
think it's acceptable for tcpinc to break TCP-SO.

Kyle

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2015 19:54:15 -0800

> decision means that tcpinc itself is explicitly breaking TCP-SO.

If you know you are doing SO beforehand (in the cases I know of, this
is true), then you can disable the crypto option.  Otherwise, I agree,
fallback to plaintext seems like the only possible answer.

In general, I think that fallback to plaintext is the answer we want.
I'm happy with not solving the problem for SO.  Again, the uses that
I'm aware of layer a security protocol on the top almost immediately.

---

From: David Mazieres <[email-masked]>
Date: Thu, 19 Nov 2015 23:46:04 -0800

>         https://datatracker.ietf.org/doc/rfc5382/

Okay, but just to be clear only one side of the connection may detect
this.  In particular, the most realistic scenario is:

        A -> B: SYN      [DROPPED by B's cone NAT or stateful firewall]
        B -> A: SYN
        A -> B: SYN-ACK
        B -> A: ACK

So in this case, A has no way to discern whether B is an active or
passive opener.  More generally, even in without NATs or stateful
firewalls, there's always the possibility of a SYN packet getting
dropped for other reasons.  Hence, the only safe conclusions are:

  * If you receive a SYN-only (no ACK) segment after sending one (the
    transition you mention), you are 100% sure the other host is an
    active opener.

  * If you receive a SYN-ACK segment but not a SYN-only segment, the
    other host is probably a passive opener, but it's also possible the
    connection employed TCP-SO.

It is worth noting that there's a little bit of subtlety in why the
current TCP-ENO design works.  If we revisit the above scenario with
ENO, assuming no special configuration (b=0 on both hosts):

        A -> B: SYN<ENO>    [segment dropped]
        B -> A: SYN<ENO>
        A -> B: SYN-ACK<>
        B -> A: SYN

So an important point is that B doesn't necessarily know it is using
TCP-SO, while A does, and hence it is A's responsibility to pull the
plug on ENO by sending no ENO option in its first ACK (namely its
SYN-ACK).  The key property here is that first side to send an ACK
always knows whether TCP-SO is in use.  And of course if both SYNs do
get through, both sides will come to the same conclusion about pulling
the plug.

> - Should tcpinc support TCP simultaneous open?  Yes or No

I'm definitely in favor of polling the working group about TCP-SO, but
I'd like to suggest that we make the question much more precise.  As it
stands I don't really know what "support" means in this context.  Some
possible interpretations are:

 1. Should it ever be possible for TCPINC to encrypt a simultaneously
    opened connection under any circumstances?

 2. Should TCPINC avoid breaking existing applications that make use of
    TCP-SO?

 3. Should the TCPINC documents even mention TCP-SO, or do we care so
    little that preventing unspecified behavior is not even worth the
    column inches?

> advocate a "No" answer to express a preference on what to do

Depending on what we decide "support" means, this second part may be
redundant.  In particular, if we discard option #3 above (leave behavior
unspecified), I believe we could answer yes to either interpretation #1
or #2 for free, but would need some additional complexity/cost to say
Yes to both.  Hence the first question the WG answers really needs to be
a three-way choice between:

  A. Allow encryption with TCP-SO but break existing applications.
     (This is option #1 in section 6.2 of the ENO draft)

  B. Never allow encryption with TCP-SO, but don't break anything.

  C. Add complexity/cost, but allow encryption with TCP-SO and don't
     break anything.

Then, if the WG chooses C, we go on to make another choice among a bunch
of options that have been discussed:

 C2. Require application configuration and use one bit to detect
     incompatible configurations and fall back to unencrypted TCP (the
     current ENO design, called C2 because it's option #2 in the ENO
     draft section 6.2).

 C3. Require hosts to pre-declare that they are doing simultaneous open,
     but don't require them to negotiate roles.  (Option #3 in ENO
     draft, and I think how TCP-use-TLS used to do it.)

 C4. Have TCP-ENO always negotiate roles, at the cost of more option
     space (Option #4 in ENO draft.)

 C5. Leave it to individual encryption specs to make TCP-SO work
     automatically.  For DH-based specs, there may be an easy trick.
     However, for public-key-based specs--such as those relying on RSA
     or post-quantum crypto--this would even for non-SO more than double
     computational cost at passive openers and add an extra round trip
     to client-speaks-first protocols.  (This is what Bryan has been
     advocating, at least for ECDH.)

>      be abandoned or proceed unencrypted?

Also, "abandoned" is ambiguous here.  Does an abandoned connection mean
one side might hang for a long period of time, or that the connect call
quickly returns an error?  Either way, this seems unnecessarily
harsh:  We really shouldn't leave file descriptors hanging, and if we
know enough to abort the connection we also know enough to downgrade it
to plaintext.

Now if I were voting in my new taxonomy, my first choice would be C2.
But my second choice would actually be B.  So the two vote structure
doesn't even really capture my preferences.

My reasoning is that I don't like unnecessarily breaking existing
things, and I really don't like paying a whole lot of complexity or
performance or option space for a fringe feature none of us has observed
in the wild.  However, the cost of C2 is so minimal that it seems
worthwhile.  Even though C2 doesn't currently work with ICE in all
cases, it leaves the door open to other NAT traversal schemes that do
work (possibly including variants of STUN).  To me, that's worth using
up one bit of an optional byte.

David

---

From: "Black, David" <[email-masked]>
Date: Fri, 20 Nov 2015 13:47:01 +0000

Summary: I don't think the questions have changed, but there are some
minor clarifications inline below ...

> passive opener.

It looks like what was intended is that *B* has no way to discern whether
A is an active or passive opener.  This is of limited relevance - A sent
a SYN and received a SYN, hence A knows that TCP-SO is going on ...

>  More generally, even in without NATs or stateful

... and if tcpinc does not support TCP-SO, A would discontinue TCP-ENO
negotiation at that point ...

>     connection employed TCP-SO.

... resulting in B seeing a TCP-ENO failure w/o knowing the cause in the
above scenario.
 
> get through, both sides will come to the same conclusion about pulling

Right.  If the WG's answer on TCP-SO support is "no", that paragraph
summarizes the expected plug-pulling behavior.

> stands I don't really know what "support" means in this context.

Really?  The above summary up to the point of plug-pulling behavior
is an accurate restatement of the question ...

> Some

No support means that this is not required.  If tcpinc for some TCP-SO
cases is possible as a relatively easy/simple extension, that's ok, but
as a WG chair, I would take a dim view of expending significant design
effort in pursuit of something the WG has determined to be a
non-requirement ;-).
 
>  2. Should TCPINC avoid breaking existing applications that make use of

That's a restatement of the follow-on question about what to do when
TCP-SO is detected - break connection vs. proceed unencrypted.  For
clarity, assume that the choice here is between actively breaking
the connection (e.g., send RST) and proceeding unencrypted.  What
middleboxes do or don't do with RST and the like is beyond our control.

>     little that preventing unspecified behavior is not even worth the

That can be figured out after we have the first two answers ;-).  Based
on the amount of attention that TCP-SO has received, I strongly suspect
that "care so little" is not the case ;-).

[ ... remainder snipped ... in the hope that the requirements answers (the
questions can be restated as 1 and 2 above, if that helps) precede working
out design details ...]

Thanks,
--David

---

From: David Mazieres <[email-masked]>
Date: Fri, 20 Nov 2015 07:08:45 -0800

> is an accurate restatement of the question ...

But in your previous email, you talked about two different ways of
pulling the plug:

| - Should tcpinc support TCP simultaneous open?  Yes or No
| -- If "No," should TCP simultaneous open connection attempts
|      be abandoned or proceed unencrypted?

How do I vote if I'm okay with either "proceed unencrypted" or minimal
support, but I'm strongly opposed to "abandon the connection" or more
invasive TCP-SO support?  As I stated in my previous email, the options
seem to be laid out like this:

       no   |
  support   |  support
            |
     A  B   |  C2 C3 C4 C5

As currently phrased, the question before the working group is whether
to select the left or right set of options.  However, my preference is
to be as close to the line as possible:  C2 (current ENO) is my
favorite, but I can also easily live with B (proceed unenecrypted).  I
find both A (abandon connection) and C4 (always work) to be horrible
options (C4 even worse than A), and believe C5 (leave it to specs) is
not forward looking enough and would have to be combined with C2 to
avoid ruling out efficient use of post-quantum crypto down the line.

So I don't know where this leaves me with respect to the current
question.  If we can rule out A immediately, this would make me happier,
but even so the left vs. right choice would not clear to me, given that
I prefer B to C4 and C5.

David

---

From: "Black, David" <[email-masked]>
Date: Fri, 20 Nov 2015 16:24:01 +0000

David> Inline ...

> invasive TCP-SO support?

David> You write exactly what you wrote ;-).

David> Seriously, this is not a "vote" that will be counted with the
David> count determining the outcome.  We're trying to gauge the sense
David> of the WG, and both questions were teed up at the same time in
David> order to enable expressions of exactly that sort of concern, so
David> Explanations are always appreciated.

> As I stated in my previous email, the options

David> Preferences noted, explanations appreciated, thank you.

---

From: Kyle Rose <[email-masked]>
Date: Fri, 20 Nov 2015 13:19:53 -0500

Speaking as a member, I've spent the last 20 minutes trying to come up
with some way of simplifying this or reframing it, but I think David
Mazieres has it right: paraphrasing, the position "Tcpinc should
support TCP-SO only if it can do so cheaply" (the close-to-the-line
position) is perfectly natural, and is not covered by the initial
question, as that question sets up the dividing line based on a binary
willingness to support, not incorporating cost of support.

My vote would be for B unless C2 has literally no greater cost. I
don't care about supporting TCP-SO, but as it is an integral part of
TCP (even if it is a degenerate edge case) tcpinc must not break it;
but if the implementation of C2 consumes any more option space than B,
I wouldn't bother.

Given that, it looks like the actual amount of option space used is
going to be the same in either case as even if we eliminate bit b from
the general suboption (i.e., A in your example assumes it's 0 for both
hosts) that would simply mean two reserved bits instead of one: the
actual number of bytes of option space consumed remains the same. So
it only helps with option space if we can eliminate the suboption
entirely, which would mean stuffing the application aware bits
somewhere else, something I'm not sure is possible.

The other consideration is API complexity. Should "cost" incorporate
this, as well? If so, then B may be more attractive than C2 even
though there is no difference in option space usage.

Kyle

On Fri, Nov 20, 2015 at 11:24 AM, Black, David <[email-masked]> wrote:
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 20 Nov 2015 10:58:49 -0800

> favorite, but I can also easily live with B (proceed unenecrypted).  I
For C2, does that requires "every" TCPINC application to specify its
roles SO or not? i.e., both sides need to setsockopt("I am [AB]")?

---

From: David Mazieres <[email-masked]>
Date: Fri, 20 Nov 2015 11:12:06 -0800

> roles SO or not? i.e., both sides need to setsockopt("I am [AB]")?

If you are using simultaneous open, exactly one side must specify that
it wants the B role, which requires sending a general suboption byte
with bit b=1.  If the other side sends a general suboption byte it must
specify b=0, but since that is the default is b=0, that side need not
send a general suboption byte.  In the event that sides do not send the
correct bytes, the connection falls back to unenecrypted TCP but still
works.

In the case of non-simultaneous open, nothing need be specified.

David

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Nov 2015 11:14:01 -0800

Yes.

	I agree with other posters in noting that this should not
	be done if it requires too much work - i.e., a longer
	option or additional exchanges.

	However, any mechanism intended to work in conjunction
	with TCP SYN exchange ought to be able to support
	simulatenous open as a true degenerate case without
	such a burden - at best, it should require only
	trivial tie-breaking.

	If it requires more than that, IMO that means you
	have a mechanism that isn't well matched to TCP, not
	that the WG should "give up" on SO.

	If SO fails for any reason, it should act exactly
	like any other failure of TCO ENO.

	Again, if it's treated as a special case when
	failing, then that is a strong indication that
	ENO isn't designed properly, IMO.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 20 Nov 2015 16:15:37 -0800

> In the case of non-simultaneous open, nothing need be specified.
Then I second your C2 or B opt order

---

From: Bryan A Ford <[email-masked]>
Date: Sat, 21 Nov 2015 18:53:59 -0800

> - Should tcpinc support TCP simultaneous open?  Yes or No

Yes.  For one thing, it seems there's little cost to doing so: at least
in the TCP-ENO spec as currently written, just one or two bits in the
standard suboption byte, which is presumably needed anyway for the
application-aware bits.

And if the negotiated protocol doesn't require a passive/active
distinction (as in my proposed change to tcpcrypt), then the negotiated
protocol wouldn't even need these suboption bits and could simply ignore
them, while "just working" in the case of simultaneous open with no
special effort.  I'm not suggesting to eliminate the bits from the
TCP-ENO header, since some negotiated protocols will clearly need/want
the passive/active distinction, but I see no reason they always need to
be used.

>      be abandoned or proceed unencrypted?

If "No" (which I think is the wrong answer), then abandoned (e.g., RST).

I'm quite concerned about the "proceed unencrypted" choice here, because
it is introducing a "fail-open" downgrade-attack scenario that at least
in principle does *not* require an attacker to be on-path.  My
understanding is that the "tcpinc threat model" is to try to protect
against off-path but not on-path attackers, which seems reasonable, but
having SO connections downgrade to unencrypted operation seems like a
potential violation of this threat model.

For example, assume some P2P-type application protocol has SO support,
perhaps as part of its NAT traversal strategy, but doesn't normally use
SO (except as needed for NAT traversal for example).  Suppose this P2P
application protocol allows peers to send each other "connection hints",
e.g., an IP address and TCP port number that another desired peer might
be located at.  Suppose the P2P application does a good job of
authenticating peers at application level: e.g., if Alice receives a
hint on how to reach Bob, she will try the suggested IP,Port but
authenticate whoever she connects to to make sure it's really Bob (or at
least someone she wants to talk to).  This is all standard P2P
best-practice stuff.

Now suppose Eve is *not* on the path between Alice and Bob, and can't
truly MITM them, but just doesn't like them and wants their traffic to
be less secure, readily visible to any three-letter agencies lurking
around silently, etc.  If Alice were to connect "normally" to Bob or
vice versa they would use a passive/active open, and tcpinc would offer
them confidentiality.  But Eve cunningly sends Alice a connection hint
pointing to Bob at about the same time she sends Bob a connection hint
pointing to Alice, causing Alice and Bob to create a SO connection
without their even intending to.  If tcpinc causes SO attempts to "fail
open" (sometimes or always) and just silently leave the connection
unencrypted, then Eve has succeeded in a downgrade attack against Alice
and Bob even though Eve is off-path.  That doesn't sound to me like what
the tcpinc threat model is supposed to or should allow.

This particular scenario might sound remote (e.g., what does Eve really
have to gain, blah blah).  But a related case is that of passive
adversaries who might be able to monitor traffic between Alice and Bob
without being able to get between or impersonate them directly: e.g., an
off-path attacker who has access to a diverted copy of Alice-Bob traffic
but can't inject packets onto their path.  If tcpinc fails open in the
SO case, such an attacker who's only "passively on-path" might be able
to trigger SO deliberately (from off-path) in order to make use of that
passive monitoring capability against Alice and Bob.

Potentially even more realistic is the "wifi network snooper" case:
e.g., Alice, Bob, and Eve are all in the same Internet cafe, and thus
Eve can see traffic between Alice and Bob and potentially even inject
packets but cannot actively prevent Alice from seeing Bob's packets or
vice versa, and hence can't readily "get ahead" of either of them in
attempt to MITM a TCP connection between them.  If Eve can't truly MITM
attack Alice and Bob on the shared wifi network but *can* trick them
into using a SO connection whose tcpinc protection fails open, again Eve
wins.  Of course one might argue that this is outside of tcpinc's threat
model, depending on the details of how you define "off-path" versus
"on-path" attackers - but it seems like a fairly realistic threat model
that I at least would really like to see tcpinc address.

So I think TCP-ENO should at the very least try not to break SO or
preclude negotiated protocols from supporting SO.  And if a negotiated
encryption protocol doesn't support SO (as USE-TLS probably can't
realistically without a major upgrade to TLS), from a security
perspective it seems much safer just to abandon (perhaps RST) accidental
SO connections rather than fail open to unencrypted mode.  Admittedly
that's not so great from a usability perspective.  Which is why my real
preference would be to adopt a protocol like tcpcrypt but modified so
that it never fails because of SO.

B

---

From: Bryan A Ford <[email-masked]>
Date: Sat, 21 Nov 2015 20:55:02 -0800

>      advocating, at least for ECDH.)

You misrepresent what I'm advocating.  I've already pointed out at least
twice how tcpcrypt could readily be made to support public-key-based
exchange and support SO without ever failing open, and without either
doubling the computational cost or adding an extra round trip in the
common case.

To summarize one way of doing this cleanly:

Assume TCP-ENO works more-or-less as currently specified, such that each
endpoint picks 'p' and 'b' bits and the 'pb' combination serves as a
priority that can be used for tiebreaking - BUT, the TCP-ENO protocol
doesn't just give up (and either fail open or abandon) if both
endpoints' pb values happen to end up equal.  Instead, TCP-ENO simply
passes the negotiated pair of pb values - e.g., as 'local_pb' and
'remote_pb' - to the negotiated protocol (e.g., USE-TLS or tcpcrypt),
which can then decide how to use them.  Maybe some negotiated protocols
(e.g., USE-TLS) will still need to bail if local_pb == remote_pb, but
let's say we want tcpcrypt to handle all cases gracefully.

Each endpoint's public-key-based tcpcrypt key exchange follows something
like this pseudocode:

local_symkey := 0x00...00 // all-zero symmetric key of appropriate size
remote_symkey := 0x00...00
if (local_pb >= remote_pb) { // active or equal role
	send local_pubkey
}
if (remote_pb >= local_pb) { // passive or equal role
	receive remote_pubkey
	local_symkey = pick_random_key()
	encrypt_and_send(remote_pubkey, local_symkey)
}
if (local_pb >= remote_pb) { // active or equal role
	remote_symkey = receive_and_decrypt(local_prikey)
}
master_local_to_remote := derive_master(local_symkey, remote_symkey)
master_remote_to_local := derive_master(remote_symkey, local_symkey)

Each endpoint then uses 'master_local_to_remote' to encrypt and append
MACs to traffic it sends to the other endpoint, and
'master_remote_to_local' to decrypt and integrity-check traffic it
receives.  Once these master secrets are derived, everything else in the
protocol can be entirely oblivious to whether the endpoints are
operating in active/passive or symmetrical roles.

Notice that whenever TCP-ENO's 2-bit tiebreaking mechanism succeeds and
produces different values (local_pb != remote_pb), the above pseudocode
yields exactly the same protocol exchange as the optimized one you like,
namely:

  A -> B:  SYN(ENO)
  B -> A:  SYN-ACK(ENO)
  A -> B:  (ENO) PKA
  B -> A:  {NB}_PKA
  B -> A:  data
  A -> B:  data

In this case, at each endpoint either local_symkey or remote_symkey will
be an all-zero key, but that's OK because the other one is fresh and
protected in transit by public-key encryption.  And I think we all can
agree that TCP-ENO's tiebreaking mechanism *should* work *almost* all
the time in practice, given that SO is uncommon in the first place and
even when it happens (intentionally or not) TCP-ENO still provides a
50-50 chance of successful tiebreaking via the low-order b bit.

In the rare case that the tiebreaking mechanism doesn't succeed, all of
the if statements in the above pseudocode will evaluate to true at both
endpoints, yielding a perfectly operational symmetric version of the
same key exchange.  In this case, local_symkey and remote_symkey end up
being nonzero at both endpoints, but everything still just works.  This
situation will incur that doubling of computational cost and perhaps an
extra round trip, but I don't think we care about if this is expected to
be such an uncommon case.

Finally, notice that the above pseudocode doesn't add any code specific
to SO - i.e., there are no SO-specific statements that we should worry
is unlikely ever to be tested, apart from the conditionals themselves.
This approach adds only one conditional that might not already be needed
anyway in your asymetric-only version of the protocol, namely the second
if (local_pb >= remote_pb) test.  And it eliminates any role-specific
conditionals you might currently have elsewhere in tcpcrypt after key
exchange.

So are there any other reasons that it would be extremely burdensome to
avoid breaking SO and potentially introduce unnecessary fail-open risks?

Bryan

---

From: David Mazieres <[email-masked]>
Date: Sun, 22 Nov 2015 12:53:26 -0800

> doubling the computational cost or adding an extra round trip in the

The current version of tcpcrypt is DH-based, so I'm saying we may have
an easy trick.  I say "may" because it makes API-visible changes we'd
have to agree on, though such changes are well within the parameters of
debate.  You just described that trick.  So how am I misrepresenting
what you are advocating?

David