Re: [tcpinc] AD review of tcp-eno

Kyle Rose <> Fri, 28 July 2017 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD0181322FF for <>; Fri, 28 Jul 2017 12:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ZY_AIlIQc5v for <>; Fri, 28 Jul 2017 12:35:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7460E132302 for <>; Fri, 28 Jul 2017 12:35:40 -0700 (PDT)
Received: by with SMTP id t37so88763577qtg.5 for <>; Fri, 28 Jul 2017 12:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kjI18YHpUPtebd2Gr5IcjooS8/nHEExgeN0JgRmvg0o=; b=eYwzr7Y/db7hEYFX5tkQDTXitgvlJJs78Wxn2c05a8qyzIiPBYXIOQ4uZGVZTllL2F HKJzI2d8a6SdPSEPY4mXUzYbq0J7Dx1Ff5LU6z0Qj1nZZ3sr7qmA7M74Up9taP4Plful G4OrP172xhndHe0hr4tDyPoPaMRMfBF9MLBp4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kjI18YHpUPtebd2Gr5IcjooS8/nHEExgeN0JgRmvg0o=; b=rp54BrVlJwZmoGd4IHLJ0LFWjfhQTy2T74g9QZyOtslpQXhozNzCoh7RMIuRsl5VgF q2zro/ViDC9cI4XrET9H+YhLnI/tCO9VNjenZlBz/B9kc4og/WAKt/8Puox4Ahqys2b0 1wsHsDMSaV11a4Jw3fRqgRF/IlOIoyCe23LTlMbczWQHQ5uFPwzcMweymfddBs4xWd9q q/Qpd19/uSlQJ8uu37hGgH+G3A2KzqGk2baI5sf+pmmfIDcabYDQ8qWr/kzzXNSDqBJg 5Vnne/hkNnYf/AvUF3BKV/M97FP0ebzxGhKLavFQ4RLF7ZCluGmq0f0LWUgPHP4j/wG8 UMYA==
X-Gm-Message-State: AIVw1138WfS/OJVdMRtEg8myS2iykdyDbU609wKxxQfiR0150eXiEwO9 cpYZkwqt5knJ4h7a2OfWOE6UywZ0mKRf
X-Received: by with SMTP id f1mr12330878qtf.264.1501270539419; Fri, 28 Jul 2017 12:35:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 28 Jul 2017 12:35:38 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Kyle Rose <>
Date: Fri, 28 Jul 2017 15:35:38 -0400
Message-ID: <>
To: David Mazieres expires 2017-10-26 PDT <>
Cc: "Mirja Kuehlewind (IETF)" <>,, tcpinc <>
Content-Type: multipart/alternative; boundary="001a11404d0a36d723055565c958"
Archived-At: <>
Subject: Re: [tcpinc] AD review of tcp-eno
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Jul 2017 19:35:58 -0000

On Fri, Jul 28, 2017 at 2:17 PM, David Mazieres expires 2017-10-26 PDT <>

> Kyle Rose <> writes:
> > Does it make sense to allocate a few TEP IDs (e.g., 0x7c-0x7f) as
> explicit
> > "for testing purposes: not for production use" IDs that implementors can
> > use in testing? Another alternative is an explicit ExID-like mechanism,
> but
> > that seems far too heavy-weight for something like ENO. A range like this
> > would at least offer implementors a no-effort way to do their own
> > development and testing without poisoning other TEP IDs.
> The document already reserves 0x20 for experimental use.

Evidently, I must have glossed over that entry in table 2 a half-dozen
times over the past two years. Heh. I think we're good on that point.

>   I'm a little
> hesitant to go allocating the top end of the space, because in the
> unlikely event that ENO is so successful we project running out of code
> points, we might want to use the low two bits of 0x7c-0x7f or 0x78-0x7f
> as the first three bits of a 10- or 11-bit extended TEP Id.

Hopefully that's a lot of crypto evolution away. Certainly, if we make the
standard "RFC", then many documents would likely have to be published
before we were in danger of exhausting this space.

> Is one
> experimental TEP ID not enough?

I was thinking of implementors developing multiple TEPs simultaneously,
like you did with both of the NIST curves. Is this realistic? I don't know.
Will it be confusing to have two separate experimental ID spaces? Possibly.
Can implementors just encode their algorithm choices as suboption data?
Yes. So it's probably not a big deal.

> The intention with 0x20 is eventually to specify an ExID-like mechanism,
> but I think maybe we felt it was premature to do so in this document.
> We could also add vaguer language about how users of 0x20 should start
> options with two or more identifier bytes to leave open the possibility
> of interoperating with other experiments.

Without a registry of TEP ExIDs, conflicts between experimental TEPs are
likely to happen if this mechanism takes off and those experiments are
deployed on the public internet. Does it matter if it's just an experiment?
Possibly, if the TEP designer decides they need test results at scale
before even approaching the IETF. Maybe the guidance in this doc should be
for the first two bytes of the 0x20 suboption data to be 00 00, which
leaves us room in the future to create a TEP ExID standard with the hope
that the other 65535 values are unused.