Subject: [Curdle] Warren Kumari's No Objection on draft-ietf-curdle-ssh-curves-10: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 03 Sep 2019 08:12:50 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-curdle-ssh-curves-10: 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-ssh-curves/

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

Mirja beat me to it with the questions re: the additional Copyright text -- I'd
*thought* I'd seen a reply to that mail, but cannot seem to find it at the
moment..

Also:
"An abort for these purposes is defined as a disconnect of the session with an
appropriate SSH "protocol error" for the fault provided to or by the client. "
Fair enough -- but would it be possible to point at where people can go find
out what the "appropriate SSH protocol error" is?

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 3 Sep 2019 09:08:27 -0700

Hi Warren,

Warren Kumari writes:
> Mirja beat me to it with the questions re: the additional Copyright
> text -- I'd *thought* I'd seen a reply to that mail, but cannot seem
> to find it at the moment..

My comment was that as I had not introduced the copyright section, I was
not comfortable removing it without approval of the other two authors of
this Draft. I have not yet heard from them on this topic. I have no
objections to the removal myself.

> Also:
>
> "An abort for these purposes is defined as a disconnect of the session
> with an appropriate SSH "protocol error" for the fault provided to or
> by the client. "
>
> Fair enough -- but would it be possible to point at where people can
> go find out what the "appropriate SSH protocol error" is?

Protocol error messages to abort are in Section 11.1 of RFC4253. and the
most likely code would be SSH_DISCONNECT_KEY_EXCHANGE_FAILED (reason
code 3).

See also URL:
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-3

However, it has been suggested that too narrow a description of the
issue might not be wise.

As this comment has been raised and discussed a few times now. Should I
add a reference?

	An abort for these purposes is defined as a disconnect of the
	session with an appropriate SSH "protocol error" for the fault
	provided to or by the client such as using the reason code
	SSH_DISCONNECT_KEY_EXCHANGE_FAILED for the SSH_MSG_DISCONNECT
	message <xref target="IANA-REASON"/>

I am not happy to be this prescriptive given that I am not certain what
all implementors of this KEX do when the abort happens.

A number of different reason codes might be currently implemented,
including:

           Symbolic name                                reason code
           -------------                                -----------
      SSH_DISCONNECT_PROTOCOL_ERROR                          2
      SSH_DISCONNECT_KEY_EXCHANGE_FAILED                     3
      SSH_DISCONNECT_CONNECTION_LOST                        10
      0xFE000000-0xFFFFFFFF		    Reserved for Private Use

The "IANA_REASON" xref would become this informative reference:

     <reference
         anchor="IANA-REASON"
         target="http://www.iana.org/assignments/ssh-parameters/ssh-parameters.\
xhtml#ssh-parameters-3">
       <front>
         <title>Secure Shell (SSH) Protocol Parameters:
	 Disconnection Messages Reason Codes and Descriptions</title>
         <author>
           <organization>Internet Assigned Numbers Authority (IANA)
           </organization>
         </author>
         <date month="August" year="2019"/>
       </front>
     </reference>

	Thank you,
	-- Mark

---

From: Aris Adamantiadis <[email-masked]>
Date: Tue, 3 Sep 2019 18:42:24 +0200

Hi Mark, Warren,

> objections to the removal myself.
I have no objection with removing this section. I did not introduce it.
> most likely code would be SSH_DISCONNECT_KEY_EXCHANGE_FAILED (reason

I was going to suggest this.

This should at most be a SHOULD because the rest of the SSH specs (and 
implementations) aren't very prescriptive on the error conditions. If we 
had to pick one, I'd pick SSH_DISCONNECT_KEY_EXCHANGE_FAILED. We can 
refer to RFC4253 11.1 on the process of disconnecting a peer, but that 
looks already obvious in light of the rest of the protocol.

For reference, RFC5656 doesn't go further than this on handling kex 
problems:

    All elliptic curve public keys MUST be validated after they are
    received.  An example of a validation algorithm can be found in
    Section 3.2.2 of [SEC1  <https://tools.ietf.org/html/rfc5656#ref-SEC1>].  If a key fails validation, the key exchange
    MUST fail.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Sep 2019 12:46:41 -0400

> I was going to suggest this.

That'd work for me, or even something like "An abort for these
purposes is defined as a disconnect of the session with an appropriate
SSH "protocol error" (see Section 11.1 of RFC4253) for the fault
provided to or by the client.", but I think your text is better...

W

> This should at most be a SHOULD because the rest of the SSH specs (and implementations) aren't very prescriptive on the error conditions. If we had to pick one, I'd pick SSH_DISCONNECT_KEY_EXCHANGE_FAILED. We can refer to RFC4253 11.1 on the process of disconnecting a peer, but that looks already obvious in light of the rest of the protocol.
>
> For reference, RFC5656 doesn't go further than this on handling kex problems:
>
>    Section 3.2.2 of [SEC1].  If a key fails validation, the key exchange
>    MUST fail.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ron Frederick <[email-masked]>
Date: Tue, 3 Sep 2019 09:53:32 -0700

On Sep 3, 2019, at 9:46 AM, Warren Kumari <[email-masked]> wrote:
> provided to or by the client.", but I think your text is better…

One thing to keep in mind here is that the abort isn’t limited to only coming from the client. Either side could receive a public key blob from the peer that triggers an all-zeroes shared key, So, this check should be done by both the client and server, and either of them could end up triggering this abort.
-- 
Ron Frederick
[email-masked]

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 3 Sep 2019 10:27:31 -0700

Hi Aris & Warren & Ron,

With a two of three majority, I will remove the "Copying Conditions"
section.

Regardin the key agreement abort. Here is the revised text...

        ...elided...
                    Alternative implementations of these functions
        SHOULD abort when either input forces the shared secret to one
        of a small set of values, as described in Section 7 of
        [RFC7748].  Clients and servers MUST fail the key exchange if
        the length of the received public keys are not the expected
        lengths. An abort for these purposes is defined as a
        disconnect (SSH_MSG_DISCONNECT) of the session and SHOULD use
        the SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message
        <xref target="IANA-REASON"/>.
        ...elided...

Where IANA-REASON is an information reference to the URL

    http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-3

(which extended the RFC4250 and RFC4253 number space to include private
values).

Should I upload the latest revision now or wait for more comments?

        -- Mark

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Sep 2019 13:58:44 -0400

> Should I upload the latest revision now or wait for more comments?

Whatever you'd like / personal preference.

I personally take the "post early and often" strategy, but other
people prefer batching a bunch of edits.

W

---

From: Ron Frederick <[email-masked]>
Date: Tue, 3 Sep 2019 16:12:43 -0700

> (which extended the RFC4250 and RFC4253 number space to include private

The middle sentence here about failing the key exchange due to the length of the public keys kind of breaks up the references to “abort” here. I think it might read better as something like:

       [RFC7748].  Clients and servers MUST also abort if

That way, the paragraph consistently uses the “abort” terminology for both types of failures, and then goes on to explain what “abort” means.
-- 
Ron Frederick
[email-masked]

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 3 Sep 2019 20:50:28 -0700

Ron Frederick <[email-masked]> writes:

> The middle sentence here about failing the key exchange due to the
> length of the public keys kind of breaks up the references to “abort”
> here. I think it might read better as something like:
> 
> That way, the paragraph consistently uses the “abort” terminology for
> both types of failures, and then goes on to explain what “abort”
> means.

You are correct. The paragraph reads better with your change.
I'll add it to the -12 revision after I get a few more comments.

	-- Mark