Re: [tcpinc] Simultaneous open tie breaking

David Mazieres <> Tue, 25 August 2015 14:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3642D1B3437 for <>; Tue, 25 Aug 2015 07:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 4.489
X-Spam-Level: ****
X-Spam-Status: No, score=4.489 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, MANGLED_BACK=2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Md-AfslsgYLr for <>; Tue, 25 Aug 2015 07:45:02 -0700 (PDT)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74FB01B3427 for <>; Tue, 25 Aug 2015 07:45:00 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t7PEj0Js015737; Tue, 25 Aug 2015 07:45:00 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t7PEixso006763; Tue, 25 Aug 2015 07:44:59 -0700 (PDT)
X-Authentication-Warning: dm set sender to using -f
From: David Mazieres <>
To: Kyle Rose <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Tue, 25 Aug 2015 07:44:59 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: tcpinc <>
Subject: Re: [tcpinc] Simultaneous open tie breaking
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Aug 2015 14:45:03 -0000

Kyle Rose <> writes:

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

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.

> IMHO, all applications should be able to benefit from TCPINC's
> 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.