[tcpinc] Review of draft-ietf-tcpinc-api-03

Kyle Rose <krose@krose.org> Fri, 28 July 2017 22:24 UTC

Return-Path: <krose@krose.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 24DF2131E67 for <tcpinc@ietfa.amsl.com>; Fri, 28 Jul 2017 15:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uev0B4qZRkor for <tcpinc@ietfa.amsl.com>; Fri, 28 Jul 2017 15:24:52 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 DD09C131761 for <tcpinc@ietf.org>; Fri, 28 Jul 2017 15:24:50 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id d145so119812152qkc.2 for <tcpinc@ietf.org>; Fri, 28 Jul 2017 15:24:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=GY5dKcONNJCOKV7zpi+8FNxCTSO/2zL/n+gu60kuHEI=; b=nEETrhNeH+fRd/ao0pqTsvqvumn2RO0S9Fct8oQ5aeh53/omkqW9C6BRXrYS6TWXsU A1nswA355Fm4InGd+iCKXKsoIVdfr5keUwWiZxtD03nJAFpwH+CO0vSM3jd87LkzSEKm 6AxLpGoWSaeK2f4bTt4dvTUxw9zUaBRtWzUaw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GY5dKcONNJCOKV7zpi+8FNxCTSO/2zL/n+gu60kuHEI=; b=LBLaPHPIA07KYAcQ6d/k9X1tbAqoSHOQ4NJO1YwtSVr7a0GA5PEsRHEdXqtvRr5kdJ L7lrk3qxRbCKloBDarfFNfoBsQg+DpqPIXZgkT+yryWf0+1jM6P/AKvFakDRDbciRdxv WGV9hVj7QgmLJLOqi2CiB3pa9I9pBgaVBylbK5yORrhby5sz6Vek3lIUDYzfXQ6caCg+ LcKjS4QnHxOV4s7VLyydgM0PXYXTXKLoXPKfhKXQqaZdHaQxE4z05I1UlDgcV4elWbpX AKfchTe53xAR9iZVRkVeNdIon84SHsS5w+eICt7/tpJn4gXRTzwpOk4nFfueWCD3stqu ZGRg==
X-Gm-Message-State: AIVw1118jmkMeIbYXObheyGd1OMeXC/5hUZXS83EpYOJQyHXJTDuPrjJ lgcEGD9VqhaOb/hyd9yEwQRg9uP7wJkRjOFUsA==
X-Received: by with SMTP id m64mr1655517qkc.227.1501280689683; Fri, 28 Jul 2017 15:24:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 28 Jul 2017 15:24:49 -0700 (PDT)
X-Originating-IP: []
From: Kyle Rose <krose@krose.org>
Date: Fri, 28 Jul 2017 18:24:49 -0400
Message-ID: <CAJU8_nW_SLVBHvnELTq_vWVN+TtFh6hmST-O2+MQSyA19=5pyw@mail.gmail.com>
To: tcpinc <tcpinc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/JY0Ql2kXTmUs4q-yXZH3IA-b8zM>
Subject: [tcpinc] Review of draft-ietf-tcpinc-api-03
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <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: Fri, 28 Jul 2017 22:24:54 -0000

(Keepalive before list timeout.)

This is a review of draft-ietf-tcpinc-api-03. Chair hat off.

Overall, I think the doc is informative. I want to echo some
discussion from long ago (maybe in Berlin or even earlier?) re: the
abstractness of the API. In particular, section 4 begins:

q( The previous sections presented abstract APIs )

when they feel remarkably concrete in some ways: everything from
the representation of bad ports. IIRC, one complaint was that an API
like this feels too concrete for the IETF, but is nowhere near precise
enough for POSIX. I agree with that assessment.

That said, there is a lot of value here, so I'm happy with something
that is basically socket API pseudocode because it's clear to anyone
who familiar with the Berkeley sockets API, which is most people who
write networking software. I don't know if that will be okay with the
IESG. Maybe Mirja can chime in on that.

For the following I'm going to assume we're okay with this
presentation style. On to the show. By section:


* Not sure what versions "(and perhaps versions)" refers to in the
second to last bullet in the ENO section. If you replace "encryption
scheme" with TEP, the parenthetical can probably just go away.

* I don't understand the rationale behind the last bullet in the
tcpcrypt section. Is the presumption that an application will
authenticate the first connection and then resume without
authentication? If so, then it's more than prudent: it MUST purge that
session from the cache.

* Relatedly, does this suggestion apply only to the keys cached for
the current session? For performance reasons, this should probably be
the case.


* q( Non-socket systems should use existing error codes corresponding
to the same conditions.) I would strike "existing". What if they don't
have existing error codes corresponding to the same conditions, for
whatever reason?

* EBADF should be used for attempts to operate on closed sockets.
EINVAL should be used when any other element of the input is invalid
(e.g., invalid TEP).

* Right under table 2, there is a set of conditions starting with
"Unless otherwise specified". Do any of them cover the case in which
ENO is being negotiated but is not yet either enabled or disabled? In
implementing this, ENO was really best modeled as a tri-state:
negotiating, disabled, enabled. I'm thinking in particular of NEGSPEC,

* Sort the option descriptions in the same order as given in the table.

* Throughout this section, there are double quotes used
inconsistently. I would just remove them all, but either way make them
consistent. See: "TCP_ENO_RAW", "EISCONN", "A", "B".

* Under TCP_ENO_NEGSPEC, I would strike the last sentence as redundant
with TCP-ENO.


* Is "Global options" going to be confused with the global suboption
in TCP-ENO? Maybe "System-wide default options/configuration

* Does it make sense to prefix all of the global options with
"eno_default_" to make it clear they can be overridden? Or is that
just too wordy?

* "eno_specs" should probably be updated for the TEP nomenclature.

* What is "baddynamic"? A Google search was unrevealing. Does this
need a reference?

* I would replace "bad" with "disable" or "exclude", especially if we
go with "eno_default_".

* If we're getting into the format of each value by byte, anyway, why
not go with each word representing a range "lowport:highport"?


* The tcpcrypt doc consciously does not normatively specify how a
server is to choose the symmetric cipher. TCP_CRYPT_BCONF, by
contrast, specifies a decreasing preference order. This may not be
necessary (though it might be easier to understand given that this API
straddles the line between abstract and concrete), but it's also
potentially confusing that this preference list is in decreasing order
while the one for TEPs is in increasing order. (I understand that the
ordering there relates to saving the length byte for the TEP you
expect, when it is most likely to contain a session ID, and maybe this
isn't a big deal. Happy to entertain rebuttals.)


* q( For example...a suitable name would be "net.inet.tcp.eno.specs"
). Why "specs" (or even "teps")? Maybe "<option name>" or a clause
introducing the example.


* TCP_ENO_LOCAL_NAME conflicts with SELF_NAME.

* Can you describe for me an attack that would be possible using an
authenticator taken out of context? I'm assuming that both ends of the
connection with the unique session ID already have the cookie, and
that the authenticator would be useless on any other tcpinc connection
because of the uniqueness property. Is the issue that the session ID
used in the PRF could collide with an entirely distinct (i.e.,
non-tcpinc) use? Something similar applies to 5.2, as well.


* It might be worth pointing out that, in unilateral authentication,
the side that does not validate an authenticator relies on the peer
ending the connection if validation fails to prevent man-in-the-middle