Re: [tcpinc] AD review of tcp-eno

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Fri, 28 July 2017 20:22 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D944131C91; Fri, 28 Jul 2017 13:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHNtJbLJEDlz; Fri, 28 Jul 2017 13:22:41 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E1B12ECF0; Fri, 28 Jul 2017 13:22:40 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v6SKMehC021229; Fri, 28 Jul 2017 13:22:40 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v6SKMe5R099229; Fri, 28 Jul 2017 13:22:40 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: draft-ietf-tcpinc-tcpeno.all@ietf.org, tcpinc <tcpinc@ietf.org>
In-Reply-To: <36738439-CAEC-4694-87EF-00EC91426D9C@kuehlewind.net>
References: <55B07DA5-E274-4720-A919-83483094B9A0@tik.ee.ethz.ch> <80C705CD-8A24-49A9-A1B8-6FA7B2162941@kuehlewind.net> <87fudh62um.fsf@ta.scs.stanford.edu> <36738439-CAEC-4694-87EF-00EC91426D9C@kuehlewind.net>
Date: Fri, 28 Jul 2017 13:22:40 -0700
Message-ID: <87shhg2twv.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/9UbJ_nSDPWcS9y_ja3mE-5-GMT8>
Subject: Re: [tcpinc] AD review of tcp-eno
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 20:22:42 -0000

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> writes:

> This is what early allocation is for. We could have also asked for
> early allocation for tcpinc as soon as the spec was reasonably stable
> but given there was no-one who was actually about to deploy this in
> the Internet, it was probably not necessary.

Is there something I can put in the document to clarify that early
allocation should be the norm not the exception?  The think I like about
"Specification required" is that RFC7120 2a says:

       The code points must be from a space designated as "RFC
       Required", "IETF Review", or "Standards Action".  Additionally,
       requests for early assignment of code points from a
       "Specification Required" registry are allowed if the
       specification will be published as an RFC.

So I like the fact that the specification required allows early
allocation *if* an RFC is anticipated.

Basically I want something in this document to make it clearly easier to
get ENO TEP IDs than TCP option kinds.


On a related note, I think there might be an inconsistency in the draft
that I would appreciate some input in resolving.  Section 7.1 says:

        TLS can currently only be added to legacy applications whose
        protocols accommodate a STARTTLS command or equivalent.
        TCP-ENO, because it provides out-of-band signaling, opens the
        possibility of future TLS revisions being generically applicable
        to any TCP application.

Of course what, we really wanted to say was TCP-ENO was designed to
support TCP-use-TLS.  However, if I recall, there's a citation issue
because we aren't supposed to cite an internet draft in an RFC unless
the two will become RFCs at the same time, and TCP-use-TLS has been
delayed.  But then in 0x30, we still cite TCP-Use-TLS to assign it code
point 0x30.

Given the work invested in TCP-Use-TLS, should we indeed reserve TEP Id
0x30 for that effort in case anyone wants to pick up it up again, and if
so how should we do that without citing an expired internet draft?  Can
we just reserve TEP ID 0x30 for future use by TLS and cite TLS?  Or what
should we do?

Thanks,
David