Re: [tcpinc] Rtgdir telechat review of draft-ietf-tcpinc-tcpeno-12

David Mazieres <> Mon, 30 October 2017 05:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D09FD13FCDF; Sun, 29 Oct 2017 22:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id auOWMMa0wyXV; Sun, 29 Oct 2017 22:34:56 -0700 (PDT)
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 BE6A013F50F; Sun, 29 Oct 2017 22:34:56 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id v9U5YpfU053075; Sun, 29 Oct 2017 22:34:51 -0700 (PDT)
Received: (from dm@localhost) by (8.15.2/8.15.2/Submit) id v9U5YolU008699; Sun, 29 Oct 2017 22:34:50 -0700 (PDT)
From: David Mazieres <>
To: Min Ye <>,
In-Reply-To: <>
References: <>
Reply-To: David Mazieres expires 2018-01-27 PST <>
Date: Sun, 29 Oct 2017 22:34:50 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] Rtgdir telechat review of draft-ietf-tcpinc-tcpeno-12
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, 30 Oct 2017 05:34:59 -0000

Min Ye <> writes:

> I have some minor concerns about this document that I think should be
> resolved before it is submitted to the IESG.
> Comments:
> - May be the document can document if there is any modification for
> what concerns closing of connections (in its current version the
> document provides a requirement in Section 5 but no actual procedure)

Thanks for the review and the comments.  All of your other comments
besides the above one are already slated to be fixed in the next draft.

As for closing the connection, the intent of the ENO draft is for the
actual close procedure to be delegated to the individual TEPs.  During
the working group, we saw at least two different cases depending on
whether an encryption protocol authenticates individual TCP segments
(like Joe Touch's ao-encrypt proposal and early drafts of tcpcrypt) or
it authenticates data frames that may span TCP segments (like
tcp-use-TLS and tcpcrypt in its current form).  The goal of the ENO
draft is to set minimum security requirements for all TEPs without
ruling out either approach.

Given that the tcpcrypt TEP draft does in fact specify the close
procedure, do you think it is okay to leave the ENO draft as is?  Or, as
another alternative, ENO could simply state that any TEP must clearly
specify the exact close procedure.