Re: [tcpinc] Rtgdir telechat review of draft-ietf-tcpinc-tcpeno-12
David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Mon, 30 October 2017 05:34 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 D09FD13FCDF; Sun, 29 Oct 2017 22:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auOWMMa0wyXV; Sun, 29 Oct 2017 22:34:56 -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 BE6A013F50F; Sun, 29 Oct 2017 22:34:56 -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 v9U5YpfU053075; Sun, 29 Oct 2017 22:34:51 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9U5YolU008699; Sun, 29 Oct 2017 22:34:50 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Min Ye <amy.yemin@huawei.com>, rtg-dir@ietf.org
Cc: draft-ietf-tcpinc-tcpeno.all@ietf.org, ietf@ietf.org, tcpinc@ietf.org
In-Reply-To: <150932741880.3409.9749564373399664113@ietfa.amsl.com>
References: <150932741880.3409.9749564373399664113@ietfa.amsl.com>
Reply-To: David Mazieres expires 2018-01-27 PST <mazieres-xwfvkvtrtbauq7t2tk2zm8v9v2@temporary-address.scs.stanford.edu>
Date: Sun, 29 Oct 2017 22:34:50 -0700
Message-ID: <87y3nt8ah1.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/pUUwguer1kG3gUJ4W3POPAKq9N0>
Subject: Re: [tcpinc] Rtgdir telechat review of draft-ietf-tcpinc-tcpeno-12
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: Mon, 30 Oct 2017 05:34:59 -0000
Min Ye <amy.yemin@huawei.com> 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. Thanks, David