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

Eric Rescorla <ekr@rtfm.com> Sat, 22 August 2015 21:28 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 669891B2D5E for <tcpinc@ietfa.amsl.com>; Sat, 22 Aug 2015 14:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bJxJOkgTEzma for <tcpinc@ietfa.amsl.com>; Sat, 22 Aug 2015 14:28:42 -0700 (PDT)
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4341B2D5B for <tcpinc@ietf.org>; Sat, 22 Aug 2015 14:28:42 -0700 (PDT)
Received: by vkd66 with SMTP id 66so43907586vkd.0 for <tcpinc@ietf.org>; Sat, 22 Aug 2015 14:28:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=o4RGhaNJaEZ6YgUOXLUlbfl9JITQJ7O1X/HexszjLvc=; b=D1nZFPqF/hni65ZYVM/h9EnAtapz8tcrC/TXifulYJGj/J9wYIoIkWs9/gPy7ZhGb2 cA1dQYuH0XSesJvlfDE8PrDiyNbG1jTvCgdfFxM4F8ZW7y/6n1gvfYuD8T2x85hz12Q5 W4vamhwFJTXm2tgOwrf21HbjC96sM7/WXULdA7hFKf5nTsgdHKsYNLtT+vfF4oz1CwSy DTGtmlfMF3KYqWgN6s3ekb8Jf/gK+cwh/9ayLbiGeVduT5OzNygGCV+VadlecD9qpOMw jOCnO6u1qD3EkTFblSfG9xkOgv6X4pZVmKlbV2FlVXWF4hTMWfDT/8jF1ln7L05XouIv r5yw==
X-Gm-Message-State: ALoCoQk6OEZ1hcintZmCM8a1RS50CrLQ4l+pHQnyzz7EffBIglWcDVMYwWQOyJVutH+4Z4CnMKsa
X-Received: by with SMTP id to3mr20506020vdc.34.1440278921621; Sat, 22 Aug 2015 14:28:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 22 Aug 2015 14:28:02 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 22 Aug 2015 14:28:02 -0700
Message-ID: <CABcZeBNEFVkDi38y3G-C2nQF=dzW2mGDsj5DVK_OKVkPwK=G0g@mail.gmail.com>
To: tcpinc <tcpinc@ietf.org>
Content-Type: multipart/alternative; boundary="001a11337c1280499e051ded1125"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/X5PeJQXvBc7OCFcfkAwdhonUaQ8>
Subject: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Aug 2015 21:28:44 -0000

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.

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?

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