[tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpeno-12: (with COMMENT)
Spencer Dawkins <spencerdawkins.ietf@gmail.com> Thu, 26 October 2017 04:24 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tcpinc@ietf.org
Delivered-To: tcpinc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4213A092; Wed, 25 Oct 2017 21:24:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tcpinc-tcpeno@ietf.org, David Black <david.black@dell.com>, tcpinc-chairs@ietf.org, david.black@dell.com, tcpinc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150899187130.24208.12665806500544882040.idtracker@ietfa.amsl.com>
Date: Wed, 25 Oct 2017 21:24:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/4esetVq9ADihofDccWr7leIV9WA>
Subject: [tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpeno-12: (with COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 26 Oct 2017 04:24:31 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-tcpinc-tcpeno-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This draft was fairly easy for me to follow. I do have some questions, of course, but I'm a Yes. In Section 3, Terminology, most of the terms were originally defined in RFC 793 (pretty much all, except for the last three, about TEP). I don't object to this document saying "this is how we are using these terms from RFC 793", but I do think it's worth providing an explicit pointer to the more detailed descriptions in RFC 793, which is already a normative reference but is only referenced for the description of TCP header options in Section 4.1. I'm having a little trouble figuring out what "kind" means in this text. It uses a new TCP option kind to negotiate one among multiple possible TCP encryption protocols or TEPs. Is this a term of art I haven't seen? I understand every word in this text, b The passive role bit MUST be 1 for all passive openers. For active openers, it MUST default to 0, but implementations MUST provide an API through which an application can explicitly set "b = 1" before initiating an active open. (Manual configuration of "b" is necessary to enable encryption with a simultaneous open.) but am not sure what you're telling implementers - is the point that a client application using a traditional client-server application protocol doesn't need to set "b = 1" for an active open, because servers won't also be attempting an active open simultaneously, but applications using peer-to-peer application protocols should? Could you give an example of the kind of "implementation considerations" that A passive opener (which is always host B) sees the remote host's SYN segment before constructing its own SYN-ACK segment. Hence, a passive opener SHOULD include only one TEP identifier in SYN-ACK segments and SHOULD ensure this TEP identifier is valid. However, simultaneous open or implementation considerations can prevent host B from offering only one TEP. is envisioning? Perhaps A host MAY send a _vacuous_ SYN-form ENO option containing zero TEP identifier suboptions. would be an appropriate entry in the terminology section? I had to keep reading to understand what _vacuous_ meant in this sentence. I wonder what the understanding of "significantly less" in o TEPs MUST NOT permit the negotiation of any encryption algorithms with significantly less than 128-bit security. will be in practice. Could you help me understand why this isn't a specific number? I couldn't parse "provide forward secrecy some bounded, short time" in o TEPs MUST NOT depend on long-lived secrets for data confidentiality, as implementations SHOULD provide forward secrecy some bounded, short time after the close of a TCP connection. without guessing. Perhaps one or more words is missing?
- [tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpin… Spencer Dawkins
- Re: [tcpinc] Spencer Dawkins' Yes on draft-ietf-t… David Mazieres
- Re: [tcpinc] Spencer Dawkins' Yes on draft-ietf-t… Spencer Dawkins at IETF