[Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)
Alexey Melnikov <aamelnikov@fastmail.fm> Wed, 13 September 2017 12:00 UTC
Return-Path: <aamelnikov@fastmail.fm>
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 CEB23134215; Wed, 13 Sep 2017 05:00:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
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: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com>
Date: Wed, 13 Sep 2017 05:00:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/QkPKQ1IroWGH3TZ4bTq3OCX0HBE>
Subject: [Curdle] Alexey Melnikov'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 12:00:28 -0000
Alexey Melnikov 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: ---------------------------------------------------------------------- This is generally a good and useful document. I have some minor comments I would like to discuss: 3.2. "delay-compression" This extension MAY be sent by both parties as follows: string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client It is not clear for me from the formatting whether the first name-list is sent by the client and the second by the server, or both lists are always included in the value. I suspect it is the former, but can you please clarify? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Sentences like: Use of Receivers MUST tolerate any sequence of bytes; including null bytes at any position; in an unknown extension's extension-value. or In particular, applications MUST tolerate any sequence of bytes; including null bytes at any position; in an unknown extension's extension-value. Use of punctuation is not my strongest point, but I am reasonably certain that use of ";" is not correct here. I think you should use (). Otherwise these sentences are reading as a list of 3 things, yet in both cases the 3rd is a continuation of the 1st. 2) In Section 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. Can you provide an example of why depending on order would be useful? This potentially makes it harder to implement. In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be less confusing if you used the latter consistently everywhere. 3) In 3.1: This extension is sent by the server, and contains a list of public key algorithms that the server is able to process as part of a "publickey" authentication request. If a client sends this extension, the server MAY ignore it, and MAY disconnect. Why would the client disconnect when seeing this extension? Does it mean it is broken? Also, as the client can always disconnect at any point, why mentioning this here? If a server does not send this extension, a client MUST NOT make any assumptions about the server's public key algorithm support, and MAY proceed with authentication requests using trial and error. Note that implementations are known to exist that apply authentication penalties if the client attempts to use an unexpected public key algorithm. Can you elaborate on what do you mean by "authentication penalties" in this context?
- [Curdle] Alexey Melnikov's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… denis bider
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… Alexey Melnikov
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… denis bider
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… Eric Rescorla
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… denis bider
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… Adam Roach
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… denis bider
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… Adam Roach
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… denis bider
- Re: [Curdle] Alexey Melnikov's Discuss on draft-i… Adam Roach