[Curdle] Adam Roach's No Objection on draft-ietf-curdle-rsa-sha2-11: (with COMMENT)

Adam Roach <adam@nostrum.com> Tue, 10 October 2017 22:56 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-curdle-rsa-sha2@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150767618401.24715.8705209714344379151.idtracker@ietfa.amsl.com>
Date: Tue, 10 Oct 2017 15:56:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/nlPk9foYmNPwRHBqyyLsfD_Z4eg>
Subject: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-rsa-sha2-11: (with COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-curdle-rsa-sha2-11: No Objection

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-rsa-sha2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.2:
  The signature field, if present, encodes a signature using an
  algorithm name that MUST match the SSH authentication request - either
  "rsa-sha2-256", or "rsa-sha2-512".

It might be that I'm not familiar enough with SSH to know what recipients do
when receiving unexpected values and the the proper behavior here would be
obvious to implementors. If that's not the case, I would think that additional
text here telling recipients what to do in the case of a mismatch would be
helpful.

The reference [EXT-INFO] needs to be normative rather than informative, as it
is part of a normative behavior described in this document.

Both section 1 and Section 5.1 describe NIST recommendations regarding key
length, while not endorsing them (normatively or otherwise). This strikes me as
notable, given that the NIST recommendations regarding SHA-1 seem to form part
of the rationale for its replacement. Is the lack of endorsing NIST-recommended
key lengths intentional?

Nits:

RFC6979 is in the references section, but does not appear to be referenced.

One of the lines in the Acknowledgements section is too long.

[Curdle] Adam Roach's No Objection on draft-ietf-… Adam Roach