[Ssh] Re: Éric Vyncke's Discuss on draft-ietf-sshm-ssh-agent-12: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Damien,

Thanks for your quick response. I have read the proposed changes, and they indeed address my concerns except for:


  *
The <note> would probably benefit from using a name attribute (but this is mostly cosmetic)
  *
About the reference for the registries, per section 7 of RFC 8126 the reference should be at the 'definition' section and not the 'registration' section

Finally, I am really uneasy about the double specifications of the code points, in section 6 and in section 7. I would prefer to leave all the assignments out of section 6 and just keep the text about constraints.

Suggest pushing the revised I-D to the data tracker when you have time,

Regards

-éric



From: Damien Miller <[e-mail]>
Date: Thursday, 27 November 2025 at 00:45
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-sshm-ssh-agent-12: (with DISCUSS and COMMENT)

On Wed, 26 Nov 2025, Éric Vyncke via Datatracker wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-sshm-ssh-agent-12: Discuss
>
> # Éric Vyncke, INT AD, comments for draft-ietf-sshm-ssh-agent-12
> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below one blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points/nits (replies would be appreciated even if only for
> my own education).
>
> Special thanks to Job Snijders for the shepherd's detailed write-up including
> the WG consensus and some justification of the intended status.
>
> Other thanks to Duane Wessels, the Internet directorate reviewer (at my
> request), and I have read Damien's reply to Duane's detailed review:
> https://datatracker.ietf.org/doc/review-ietf-sshm-ssh-agent-12-intdir-telechat-wessels-2025-11-20/
>
> I hope that this review helps to improve the document,

Thanks for the detailed review and feedback, Éric.

I have one of two questions on the feedback - see below, but have addressed
the other things. Please take a look at

https://github.com/djmdjm/drafts/commit/eef7676e117ca

If you have the time.

> ## DISCUSS (blocking)
>
> As noted in
> https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
> a DISCUSS ballot is a request to have a discussion on the points below; I
> really think that the document would be improved with a change here, but can be
> convinced otherwise.
>
> ### Section 7.1 and others
>
> SSH_AGENTC_ADD_IDENTITY is not specified in section 6.1 but in section 3.2.

I'm not sure I follow here. The definition of the SSH_AGENTC_ADD_IDENTITY
message is indeed section 3.2, but the message number is defined in 6.1.
I figured that since IANA is registering name/number pairs, it would be
best to refer to the section in which they appear together. Is this
incorrect?

> `Reserved for organizational use` is not a use specified in RFC 8126.

Thanks, changed to "Private Use" per RFC8126.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ## COMMENTS (non-blocking)
>
> ### Abstract
>
> s/This document describes/This document *specifies*/ as it is proposed standard
> ;-)

Done.

> The 'This note...' should not be in the abstract but in a `<note>`.

I think this is already the case, see:

https://github.com/djmdjm/drafts/blob/48559be416c37/draft-ietf-sshm-ssh-agent.xml#L51-L56

Am I missing something?>

> ### Section 1
>
> Strongly suggest to add references to all RFC 425x that specify the SSH
> protocol.

Done

> ### Section 3.2
>
> Where are the components listed in `"contents" consists of the public and
> private components of the key and vary by key type, they are listed below for
> standard and commonly used key types`? A forward reference 'as specified in the
> following sub-sections' would be welcome.

Now reads:

> "key data" consists of the public and private components of the key
> and vary by key type, as specified in sub-sections 3.2.1 through 3.2.4
> for commonly used key types

> ### Section 3.2.6
>
> Why not a "MUST" in `the agent SHOULD also return SSH_AGENT_FAILURE` ?

Fixed.

> ### Section 3.2.7
>
> `it is necessary to know its structure beforehand and it is not possible to
> safely recover` this seems like a big issue to me as it mostly ossify the SSH
> agent. Probably too late to change this as implementations are deployed, but
> using the usual TLV would have been better.

I don't think it's a problem in practice as key constraints are a mechanism
to provide restrictions on the scope or use of a key. For this reason they
should all be considered "critical" and an agent's inability to accept a
constraint should be cause for it to refuse to load the key.

> This should also be described in an operational considerations section.
>
> ### Section 5.3
>
> What are the consequences (even if semi obvious) of bypassing the "SHOULD" in
> `An SSH client SHOULD be prepared`? See also
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Added some explanation of why this is desirable and the consequences if not
supported.

> ### Section 6
>
> Unsure whether this section is required or even useful as the IANA section
> repeats the same data. Consider removing it.

If this what you meant with the DISCUSS note above? If so, I don't think I
agree - section 6 adds IMO important context about the use of some of the
numbers and the rationale for many of the reservations that would be
inappropriate for the IANA section.

> ### Section 7.1
>
> Please use the registry URI
> https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml rather
> than RFC 4250.

Done

> ### Section 7.8
>
> This sub-section should really appear *before* section 7.1.

Moved.

> ### Section 8
>
> A lot of "SHOULD" in this section without the companion clauses requested by
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Added context for all but two that were IMO sufficiently self-explanatory.

Thanks again for the feedback.

-d