Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

"Holland, Jake" <> Mon, 06 February 2017 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D575F1293F9 for <>; Mon, 6 Feb 2017 13:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, 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 fjgYb8jqEGze for <>; Mon, 6 Feb 2017 13:04:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 260E81295ED for <>; Mon, 6 Feb 2017 13:04:33 -0800 (PST)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id A842E433451; Mon, 6 Feb 2017 21:04:32 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 8836043340B; Mon, 6 Feb 2017 21:04:32 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1486415072; bh=sxzilUMWDiNHUPebqe7xpoclP2/qBqbaWgvI+zNoymU=; l=2800; h=From:To:Date:References:In-Reply-To:From; b=tgxYxgmLEJvDKovBtjuchS3FJRGdo83qxpiKPiEWH2sEJMxkKjfCq+4zM2H401nQr TlinSHs35yZP7w6boWIsD5iKkR7tC9ltGOh/hB9IRT3hn1TcboKy2RRATrHuZCsjAI aj6XvcV4Wb+8hQhXHkKfJofe25dju3IAn3MySekg=
Received: from ( []) by (Postfix) with ESMTP id 693AF1FC90; Mon, 6 Feb 2017 21:04:32 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Feb 2017 15:04:31 -0600
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Mon, 6 Feb 2017 13:04:31 -0800
From: "Holland, Jake" <>
To: David Mazieres expires 2017-05-05 PDT <>, "" <>
Thread-Topic: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
Thread-Index: AQHSfaH8bHX24B8Ba06t1pm3vEt1naFXQ4GAgAC4JQCAAKuKAP//y7SAgAFVG4CAArX1gA==
Date: Mon, 06 Feb 2017 21:04:31 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-Mailman-Version: 2.1.17
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: Mon, 06 Feb 2017 21:04:36 -0000

On 2/4/17, 11:40 AM, "David Mazieres" <> wrote:
>   Achieving stronger security with TCP-ENO requires verifying session
>   IDs.  Any application relying on ENO for communications security MUST
>   incorporate session IDs into its endpoint authentication.  By way of
>   example, an authentication mechanism based on keyed digests (such

nit: I think you want an “as” here

>   Digest Access Authentication [RFC7616]) can be extended to include
>   the role and session ID in the input of the keyed digest.

>   Applications MAY use the application-aware "a" bit to negotiate the
>   inclusion of session IDs in authentication even when there is no in-
>   band way to carry out such a negotiation

In this particular sentence (“Applications MAY use the ...”) I would prefer to see something like “Higher-layer protocols”, or “Higher-layer authentication mechanisms” instead of “Applications”, as the thing which MAY use the ...

The reason is because this negotiation is something that every application which connects to the same service has to do in a coherent manner. In other words, this is inherently NOT a negotiation that an individual application could perform in a different way from another different application that uses the same higher layer protocol for communication. Using “Applications” in that sentence seems to imply that it’s an application-level negotiation, when in fact it’s a higher-layer-protocol negotiation. Using “Applications” might still have left some confusion about this point for me on my first reading.

(Also, I still think you’d be better served by changing the name of the a-bit from “application-aware” to something like “Legacy protocol updated” or “Higher-layer negotiation”, or another phrase that more narrowly describes the usage of the a-bit. But outside from this one final mention I won’t quibble with your decision.)

Otherwise I’m satisfied with your proposed changes, and thanks again.