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

[Aris Adamantiadis <[e-mail]>]

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.

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.