Re: [Curdle] Mirja Kühlewind's Discuss on draft-ietf-curdle-ssh-curves-10: (with DISCUSS and COMMENT)

With regard to the following:

> Additionally it doesn't really help the end user who would
> see this message, because this is clearly an implementation
> issue within the SSH software stack, not something that the
> user can tweak in a configuration file.

I think it's important to note that this reasoning, in general, is false.
As someone who has directly supported users of SSH software over 20 years,
it is highly useful if the user can send log files which contain technical
information, even if the user doesn't understand that information. It can
dramatically reduce the effort needed to figure out an issue, and increases
the odds that it will be figured out at all.

The part of the argument about protecting sensitive information is valid,
but implementers also tend to run with that much further than it's useful.
For example, there are implementations which use this reasoning to try to
deny the other party information about the software name and version in the
SSH version string. This greatly frustrates figuring out problems when
connecting to those implementations (what software is this to begin with?)
and makes it difficult to implement compatibility workarounds (how do we
tell this broken implementation from others when it's going out of its way
to disguise itself?). From this perspective, I am thankful to developers
like OpenSSH for their policy to always include the software name and
version in the SSH version string, that's a godsend that greatly helps when
we need to work around a compatibility issue.

In general - protect sensitive information, yes; but consider that every
piece of information that's removed also makes things substantially more
difficult for tech support and compatibility.

denis

On Wed, Aug 28, 2019 at 12:08 PM Aris Adamantiadis <aris@badcode.be> wrote:

> Le 28-08-19 à 17:53, Mark D. Baushke a écrit :
>
> > In section 3, the appropriate SSH "protocol error" might be one of a
> > two:
> >
> >    SSH_ERR_KEY_INVALID_EC_VALUE for zeros found for the all-zero shared
> >    secret
> >
> > and
> >
> >    SSH_ERR_SIGNATURE_INVALID if the blob is not the correct size for a
> >    public key
> >
> > However, an implementation miight return SSH_ERR_SIGNATURE_INVALID
> > rather than SSH_ERR_KEY_INVALID_EC_VALUE depending on how the
> > implementation was written.
> >
> > As long as the connection aborts and does not continue in the case of a
> > "protocol error", it is sufficient in my opinion.
> >
> > Is it really needful to be prescriptive in this given that many
> > implementations of this code have already been fielded and I do not
> > have any ability to know which design choices they made?
>
> Hi Mark,
>
> I would think it's best that as little information as possible about the
> error is sent over the SSH connection. This vector was historically used
> to exploit other cryptographic protocols, enabling attacks such as
> padding oracles and others. Additionally it doesn't really help the end
> user who would see this message, because this is clearly an
> implementation issue within the SSH software stack, not something that
> the user can tweak in a configuration file.
>
> I'd then recommend a SHOULD send SSH_ERR_SIGNATURE_INVALID for all cases
> where protocol errors happen when handling the shared secret or the
> peer's key, if we really wish to be prescriptive, something I don't
> think is important.
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>