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

[Warren Kumari <[e-mail]>]

On Tue, Sep 3, 2019 at 12:42 PM Aris Adamantiadis <[e-mail]> wrote:
>
> Hi Mark, Warren,
>
> Le 03/09/2019 à 18:08, Mark D. Baushke a écrit :
>
> 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.
>
> I have no objection with removing this section. I did not introduce it.
>
> 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).
>
> 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:
>
>    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].  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