[Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)
Ben Campbell <ben@nostrum.com> Wed, 13 September 2017 19:30 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: curdle@ietf.org
Delivered-To: curdle@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A92126B6D; Wed, 13 Sep 2017 12:30:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.61.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com>
Date: Wed, 13 Sep 2017 12:30:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/RNNMp0f9rMfQqXsOJcFeDNC_5z4>
Subject: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Sep 2017 19:30:27 -0000
Ben Campbell has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Discuss 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-curdle-ssh-ext-info/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I plan to ballot "yes", but I want to discuss one point first. Alexey mentioned this in his comments, but I think it's discuss worthy. Hopefully it's an easy fix, and it may well be because I've missed something obvious. If people think it really, really needs to be this way, I will clear--but I want to discuss it first: - 2.5: The relative order in which extensions appear in an EXT_INFO message MUST be ignored by default; but an extension MAY specify that the order matters for that extension, in a specific way. I don't think allowing specific extensions to add ordering requirement works. It opens up the possibility of incompatible ordering requirements across extensions. As far as I can tell, the only control over this is the "IETF Consensus" requirement for adding new extensions. I'm open to arguments that this is good enough, but my knee-jerk response is that it puts an undue burden on the consensus process for little return. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: -2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without delay." That seems to be contradicted in section 2.4, which talks about two other potential times. -2.4, last paragraph (asterisk note): "The message MUST be sent at this point for the following reasons:" That's a confusing use of MUST. Do you mean that the message MUST NOT be sent unless the reasons are true? Or that if the reasons are true, the message MUST be sent? Or is this just a statement of fact, in which case the 2119 keyword is not appropriate? -2.5, 2nd paragraph: "or it MAY be sufficient that only one party includes it" That seems like a statement of fact rather than a grant of permission. If so, the 2119 MAY is not appropriate. Editorial: -2.1, first paragraph: "Applications implementing this mechanism MUST add to the field "kex_algorithms", in their KEXINIT packet sent for the first key exchange, one of the following indicator names:" That's hard to parse. Suggestion: "Applications implementing this mechanism MUST add one of the following indicator names to the "kex_algorithms" field for the first key exchange:" -2.5, 2nd to last paragraph: "... applications MUST tolerate any sequence of bytes; including null bytes at any position; in an unknown extension’s extension-value." Redundant to similar normative statement in 2.3.
- [Curdle] Ben Campbell's Discuss on draft-ietf-cur… Ben Campbell
- Re: [Curdle] Ben Campbell's Discuss on draft-ietf… denis bider
- Re: [Curdle] Ben Campbell's Discuss on draft-ietf… Ben Campbell
- Re: [Curdle] Ben Campbell's Discuss on draft-ietf… denis bider
- Re: [Curdle] Ben Campbell's Discuss on draft-ietf… Ben Campbell
- Re: [Curdle] Ben Campbell's Discuss on draft-ietf… denis bider
- Re: [Curdle] Ben Campbell's Discuss on draft-ietf… Ben Campbell