Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
Daniel B Giffin <dbg@scs.stanford.edu> Fri, 17 November 2017 03:17 UTC
Return-Path: <dbg@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 5AF48127522; Thu, 16 Nov 2017 19:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 8A-xNalLY1be; Thu, 16 Nov 2017 19:17:37 -0800 (PST)
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 0A7E6124D68; Thu, 16 Nov 2017 19:17:37 -0800 (PST)
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 vAH3Ha8r089777; Thu, 16 Nov 2017 19:17:36 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAH3Ha2V062981; Thu, 16 Nov 2017 19:17:36 -0800 (PST)
Date: Thu, 16 Nov 2017 19:17:36 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org, Kyle Rose <krose@krose.org>, tcpinc-chairs@ietf.org, tcpinc@ietf.org
Message-ID: <20171117031736.GC11150@scs.stanford.edu>
References: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/9jHh0MUrMjQl2KABbTLc01yYwPo>
Subject: Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
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: Fri, 17 Nov 2017 03:17:38 -0000
Thanks for the review, Adam ... Adam Roach wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for a well-written document. I have some suggestions for improvement > (two minor, and one significant). > > This document has several references to tables that are quite distant from the > table being referenced. It might be useful to readers if these were phrased > something like "Table 4 in section 7," so they know where to go looking for the > table. Good idea. I've gone and added the section to all table references. > Section 3.5 says: > > If an active opener receives a resumption suboption for a particular > TEP and the received identifier-half does not match the "resume[i]" > value whose other half it previously sent in a resumption suboption > for the same TEP, it MUST ignore that suboption. In the typical case > that this was the only ENO suboption received, this means the host > MUST disable TCP-ENO and tcpcrypt: that is, it MUST NOT send any more > ENO options and MUST NOT encrypt the connection. > > I think the text here would benefit from pointing out that the client MUST NOT > attempt to resume a session with this host for the next TCP connection attempt. Is your concern that these two peers can get "stuck" in a state where they repeatedly fail a mutual attempt at resumption, thus forever falling back to no encryption? In the case of a hash-collision of resumption identifiers, it seems we don't get stuck because the active opener will advance to the next session secret on the next connection: When proposing resumption, the active opener MUST use the lowest value of `i` that has not already been used (successfully or not) to negotiate resumption with the same host and for the same pre-session key `ss[0]`. Maybe you're seeing a different problem? > ____ > > Section 3.6 stipulates: > [truncate] (I've responded to this concern in a separate thread.) daniel
- [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tc… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Mirja Kuehlewind (IETF)
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Mirja Kuehlewind (IETF)
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Kyle Rose
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Daniel B Giffin
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Daniel B Giffin
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach