Re: [tcpinc] Kathleen Moriarty's Yes on draft-ietf-tcpinc-tcpeno-13: (with COMMENT)

David Mazieres <> Mon, 13 November 2017 00:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB5F0126D85; Sun, 12 Nov 2017 16:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yEQL579V0mr1; Sun, 12 Nov 2017 16:17:43 -0800 (PST)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14BAD126CB6; Sun, 12 Nov 2017 16:17:43 -0800 (PST)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id vAD0Hf4I008658; Sun, 12 Nov 2017 16:17:41 -0800 (PST)
Received: (from dm@localhost) by (8.15.2/8.15.2/Submit) id vAD0HeTK087626; Sun, 12 Nov 2017 16:17:40 -0800 (PST)
From: David Mazieres <>
To: Kathleen Moriarty <>, The IESG <>
In-Reply-To: <>
References: <>
Reply-To: David Mazieres expires 2018-02-10 PST <>
Date: Sun, 12 Nov 2017 16:17:40 -0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] Kathleen Moriarty's Yes on draft-ietf-tcpinc-tcpeno-13: (with COMMENT)
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: Mon, 13 Nov 2017 00:17:44 -0000

Kathleen Moriarty <> writes:

> Thanks for your work on this draft and experiment.  I just have one
> comment that I don't think has been mentioned already. In section 4,
> could you include reference to Opportunistic security, RFC7435.  The
> definition has changed slightly over time and it would be good to link
> this to the current definition that is intended.  The work on 7435 was
> painstaking and the definition varies a bit in older specs.  I do
> realize you describe this more in the security considerations section,
> but it is much later in the document, so this seemed like an easy fix.

Would you be okay if we cited RFC7435 in the security considerations
section (10), rather than section 4?

My issue is that the term "opportunistic security" entails some
subjective judgment (like the fact that it is a form of security) that
requires some context I don't really want to get into at the beginning
of Section 4.  Section 4 is trying to be an objective specification of
what the protocol does with just the minimal rationale necessary for it
to make sense.  The security considerations section already gets into
detail about security, which is why RFC7435 would seem to fit well