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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 28 Aug 2019 04:02:31 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-curdle-ssh-curves-10: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Question to the IESG/responsible AD:

I found this:

"Appendix A.  Copying conditions

   Regarding this entire document or any portion of it, the authors make
   no guarantees and are not responsible for any damage resulting from
   its use.  The authors grant irrevocable permission to anyone to use,
   modify, and distribute it in any way that does not diminish the
   rights of anyone else to use, modify, and distribute it, provided
   that redistributed derivative works do not contain misleading author
   or version information.  Derivative works need not be licensed under
   similar terms."

Does it make sense to have this in addition to the usual IETF terms? And/or why is this needed here?

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

One minor comment:
In section 3, would it make sense to actually name what the "appropriate SSH "protocol error"" is?

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 28 Aug 2019 08:53:23 -0700

Hi Marja,

I did not write the original "Copying Conditions" section and would
rather have the approval of the other authors before it is removed.
I have no objections myself.

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?

	-- Mark

---

From: Aris Adamantiadis <[email-masked]>
Date: Wed, 28 Aug 2019 19:08:21 +0200

> 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.

---

From: Ron Frederick <[email-masked]>
Date: Wed, 28 Aug 2019 15:37:17 -0700

On Aug 28, 2019, at 10:08 AM, Aris Adamantiadis <[email-masked]> wrote:
> 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.

The SSH_ERR_* names are not actually wire protocol constructs, so I don’t believe they should be used in this spec. From what I can see, they are values defined internally by OpenSSH and LibSSH (and possibly others), but in the end they are converted to a text string before being used anywhere. I didn’t track all the way through the code to see if the text strings ever appear on the wire or not or only in local log messages, but if they did appear on the wire I expect they would be as the “description” text in an SSH_MSG_DISCONNECT message. The “reason code” in that message comes from a much smaller list (defined in RFC 4253 section 11.1) and would probably be set to SSH_DISCONNECT_PROTOCOL_ERROR or perhaps SSH_DISCONNECT_KEY_EXCHANGE_FAILED.

I agree that this spec should not attempt to go into detail about what error is returned, especially not for a text string like this. I could see potentially recommending that a disconnect be performed, but even attempting to recommend the specific disconnect reason runs the risk of not matching what existing implementations are currently doing in this case and I see very little value in trying to standardize the exact disconnect reason.
-- 
Ron Frederick
[email-masked]

---

From: denis bider <[email-masked]>
Date: Wed, 28 Aug 2019 17:46:21 -0500

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 <[email-masked]> wrote:

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>