Subject: Re: [Last-Call] Last Call: <draft-ietf-curdle-ssh-kex-sha2-14.txt> (Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)) to Proposed Standard

From: Rene Struik <[email-masked]>
Date: Wed, 24 Feb 2021 17:46:29 -0500

Dear colleagues:

I did have a brief look at this draft and have the following (small) 
comments:

Draft: draft-ietf-curdle-ssh-kex-sha2-14

Comments:
- the document seems to take a half-hearted stance on deprecating the 
use of SHA1. Why not simply strike all key exchange methods that use it 
off Table 6 altogether?
- in Section 1.1 (p. 3, forelast para), it is suggested to not use 
SHA-224 since it has the same compression function as SHA-256 (and only 
differs from it by the initialization vector and truncation in the end). 
Shouldn't one add similar language for SHA-384 vs. SHA-512?
- in Section 1.2.1, the bit security of Curve25519 and Curve448 is 
somewhat smaller than stated (126-bit and 223-bit) {although perhaps not 
that important a change}.
- in Section 3.2.2, I am somewhat puzzled by the suggested use of 
Curve448 with SHA512, since RFC8709 introduces Ed448 (which uses a 
4-isogenous curve Edwards448 to Curve448, but which uses SHAKE256/d=914 
internally). Why not align the underlying hash functions, so that 
implementations with this curve would be able to use a single hash 
function implementation?
- in Section 3.3, I am wondering about the underlying philosophy of 
still aiming for implementation of ordinary discrete log groups (Note: 
it is the only method with a MUST). Shouldn't one give a nudge towards 
implementing elliptic curve-based methods (which all have a MAY or 
SHOULD only). It seems more appropriate to switch this order and label 
DLP groups as MAY at most (if sufficiently large)?
- (not really in this document, but I thought to ask nevertheless) some 
representations, such as "mpint", do not seem to be such a smart choice 
any more, since variable-size encodings may leak info on secret 
parameters in crypto processing. Is there any reason this still, in 
2021, should be kept as is?

I do realize that not all these comments are directly fixable with this 
draft (e.g., the last one). However, it makes me wonder whether it may 
be time for a more general design update of ssh-related protocols? (in 
my mind, crypto agility should have a complement in general design 
agility... [even if one would just only get rid of mpint etc.])

Best regards, Rene

On 2021-02-10 11:59 a.m., The IESG wrote:
> The IESG has received a request from the CURves, Deprecating and a Little
> more Encryption WG (curdle) to consider the following document: - 'Key
> Exchange (KEX) Method Updates and Recommendations for Secure Shell
>     (SSH)'
>    <draft-ietf-curdle-ssh-kex-sha2-14.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-02-24. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document is intended to update the recommended set of key
>     exchange methods for use in the Secure Shell (SSH) protocol to meet
>     evolving needs for stronger security.  This document updates RFC
>     4250, RFC 4253, RFC 4432, and RFC 4462.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 24 Feb 2021 18:12:27 -0800

Hi Rene,

I have tried to address all of your comments below.

> use of SHA1. Why not simply strike all key exchange methods that use it

MDB:

As the draft author, my original intention was to move all of the *-sha1
key exchanges to either deprecated or disallowed. In RFC keyword terms,
this is SHOULD NOT or MUST NOT. If you look at Table 6, the only one
that was missed was the former "MUST" algorithm
"diffie-hellman-group14-sha1" which has been moved from "MUST" by
RFC4253 to "MAY by this draft.

The WG consensus was that this "MAY" allows for a transition period to
the new "MUST", "SHOULD", and "MAY" guidelines for key exchange methods.

> Shouldn't one add similar language for SHA-384 vs. SHA-512?

MDB:

I can add it if it is desired by the community. Or, I could remove any
mention of SHA-224 if that would make the community happier.

I will note that RFC5656 section 6.3 mandates that ecdh-sha2-nistp384
use SHA-384 which is why there is no similar language for that hashing
algorithm.

> that important a change}.

MDB:

I do say 'approximately 128 bits' in the text. I could add the word
'approximately' to the table if that is needed for consistency.

Do you have an informative reference for Curve448 being at 223 bits of
security rather than 224 bits? If so, I could add it to the
informational references and update the table.

> implementations with this curve would be able to use a single hash

MDB:

I thought the section 3.2.2 text was clear that the key exchange method
names were those found in RFC8731.

Section 3.2.2 specifies curve25519-sha256 for two reasons:

  a) it is a direct documentation of [email-masked] which
     is deployed in many SSH implementations and is documented in
     RFC8731.

  b) SHA-3 implementation were not as widely deployed as SHA-2 when the
     [email-masked] implementation was created.

If you have any suggestions for how to make section 3.2.2 clearer, I
have no pblems with updating the section with such a consideration to
help readers of the RFC.

> it is the only method with a MUST). 

MDB:

Yes, and it is only FFC group14 which already in fielded implementations
due to RFC4253 mandating it (for use with SHA-1). The only change was to
move from SHA-1 to SHA256. This was considered to be a simple code
change as compared to trying to add EC to implementations that do not
have it and are not interested in implementing it.

> Shouldn't one give a nudge towards implementing elliptic curve-based
> methods (which all have a MAY or SHOULD only). It seems more
> appropriate to switch this order and label DLP groups as MAY at most
> (if sufficiently large)?

MDB:

The nudge I used was marking them as "SHOULD" ... I was unable to get
consensus on MUST for any of the EC key exchange methods.

That said, there are again two plausible reasons for this:

 a) In a Post Quantum Cryptography (PQC) world (which I do not expect to
    happen in my lifetime), it is easier to break EC than FFC because EC
    uses fewer bits.

 b) If you look at the archives, you will find a number of implementors
    refuse to consider a move to EC key exchanges at all.

So, one reason is technical and one reason is mistrust of EC... or maybe
they are both anxious about PQC.

I feel happy I was able to make rsa1024-sha1 a MUST NOT as there are
still a lot of folks that enjoy using RSA. and I would have no problems
if rsa2048-sha256 were removed due to a lack of perfect forward
security.

> 2021, should be kept as is?

MDB:

Given the key exchange method names are sent in the clear of the fixed
sized prime fields for FFC and curves for EC and key size for RSA, I am
unclear on your point. There is not really anything secret about the
sizes of these crypto variables.

If you are talking about mpint for other parts of the SSH protocol, then
that may be worth a larger discussion.

> agility... [even if one would just only get rid of mpint etc.])

MDB:

At this time, the CURves, Deprecating and a Little more Encryption
(curdle) working group is winding down. I believe that the this draft is
the second to the last one for the WG. (The only one still waiting is
draft-kampanakis-curdle-pq-ssh-00)

I would suggest that the ietf SSH working group would need to be
restarted if there was going to be a design update to move from SSHv2 to
SSHv3. However, that is just my opinion.

> Best regards, Rene

I hope that my answers have addressed your questions and concerns and
look forward to any suggested textual changes to make the document
better.

...elided the rest of the message...

	Be safe, stay healthy,
	-- Mark

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 24 Feb 2021 18:19:03 -0800

[I got some email bounces... please pardon any duplication... trying
again -- mdb]

Hi Rene,

MDB:

MDB:

MDB:

MDB:

MDB:

MDB:

MDB:

MDB:

	Be safe, stay healthy,
	-- Mark

---

From: Rene Struik <[email-masked]>
Date: Thu, 25 Feb 2021 10:39:24 -0500

Hi Mark:

Brief feedback below..

Rene

> the new "MUST", "SHOULD", and "MAY" guidelines for key exchange methods.

RS>> Please note that IACR awarded the "test of time" award (see 
https://www.iacr.org/testoftime/)(after 15 years) to

 From Crypto 2005:Finding collisions in the full 
SHA-1<https://doi.org/10.1007/11535218_2>, by Xiaoyun Wang, Yiqun Lisa 
Yin and Hongbo Yu/For a breakthrough in the cryptanalysis of hash 
functions./

    If people after 15 years still need time, crypto agility seems to be
    a dead letter. Besides, RFCs are not laws: implementors always have
    the option to ignore/reject whatever IETF produces. By stipulating
    MUST NOT one at least forces implementers to justify themselves. {In
    my mind, most security flaws are caused by sloppy implementors,
    which gives everyone else also a bad name.}
    //<<RS/
    /

> use SHA-384 which is why there is no similar language for that hashing
RS>> okay. <<RS
> informational references and update the table.
RS>> As already said, perhaps not that important. (bit-security is 
usually phrased as (1/2)*log2(n), rounded to an integer, where n is the 
order of the largest prime-order subgroup.) <<RS
> have no pblems with updating the section with such a consideration to
RS>> I simply wanted to suggest that specifications should aim for 
lowering implementation cost, unless there are very strong reasons for 
not doing so. BTW - my comment was about different hash functions used 
with Curve448 and Ed448, not about curve25519. If one can write code for 
Ed448 (which enforces the use of SHAKE256/d=914), why can't the key 
exchange method do a call to that hash function with the key derivation 
function? It is somewhat disturbing that one simply copies what a single 
library does... <<RS
>      happen in my lifetime), it is easier to break EC than FFC because EC
RS>> If this is indeed a "plausible" motivation, this should perhaps be 
mentioned in the draft. It is unclear, though, whether the "easier to 
break" statement actually holds, at least in common usage of FFC with a 
"safe" prime p=2q+1, where one uses a much shorter private key (of bit 
length similar to ECC bit length), e.g., prime p is 2048 bits and 
private key is 224 bits. To my knowledge, a careful analysis of quantum 
algorithms for this scenario have not been reported on in the 
literature, but this may very well turn out to be solvable with an 
adaptation of the "order finding problem". BTW - I do not expect it 
would be easy to entice researchers to work on this problem, since it is 
much easier to defend spending time on more prevalent algorithms. <<RS
> they are both anxious about PQC.
RS>> Again, implementors are free to ignore what is written in RFCs, but 
mistrust does not necessarily have to guide IETF recommendations. 
Considering that "sha1" apparently still has to be supported somewhat 
"to allow more time", wouldn't it be plausible that people are simply 
resistant to any change, period? Personally, I think the PQC argument is 
an argument of convenience, while implementation attacks are a clear and 
present danger and quite easy to carry out for FFC groups (but 
consistently ignored when drawing up algorithm tables). Hence, my 
suggestion to still nudge people in the (considered by most) right 
direction. <<RS
> sizes of these crypto variables.

RS>> A concrete example of such an attack is a timing attack, where one 
exploits that the hash function used for key derivation may not run in 
constant time if the input size is not fixed-size. This could 
potentially be the case when the shared key K is encoded using mpint 
(where, e..g., if the leftmost bit of K is one, one prepends an all-zero 
byte). For a simple attack in the case of FFC groups (hence, my nudge 
remark), see, e.g.:

Side Channel Analysis - Raccoon Attack, Exploiting MSB-Oracles in 
TLS-DHE, hnp (Robert Merget, Marcus Brinkmann, Nimrod Aviram, Juraj 
Somorovsky, Johannes Mittmann, Jorg Schwenk, IACR ePrint 2020-1151)

https://eprint.iacr.org/2020/1151

<<RS

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 15:46:36 +0000

I just want to point out that the current draft represents the WG consensus.

---

From: Rene Struik <[email-masked]>
Date: Thu, 25 Feb 2021 11:09:06 -0500

Hi Rich:

I do not have any fish to fry here, but I thought IETF Last-Call was to 
get wider community feedback.

The WGLC was June 14, 2017 on rev08, more than 3 1/2 years ago, so 
perhaps some perceptions may have changed since then. The draft also 
changed [1].

Once again, simple IETF Last-Call comments...

Ref: [1] 
https://www.ietf.org/rfcdiff?url1=draft-ietf-curdle-ssh-kex-sha2-14&url2=draft-ietf-curdle-ssh-kex-sha2-08

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 16:16:52 +0000

*   I do not have any fish to fry here, but I thought IETF Last-Call was to get wider community feedback.

I like that phrase. :)

>The WGLC was June 14, 2017 on rev08, more than 3 1/2 years ago, so perhaps some perceptions may have changed since then. The draft also changed [1].

And we had WG discussion on the changes. And a poll (https://mailarchive.ietf.org/arch/browse/curdle/?q=%20straw%20poll) about some of the issues.

As for bad algorithms not being MUST NOT, the feeling was that we needed to have a transition period.

Just trying to provide some context. I appreciate your feedback, as always, you’re quite good. :)

---

From: denis bider <[email-masked]>
Date: Thu, 25 Feb 2021 13:51:35 -0600

With regard to recent comments on this draft by Rene and Mališa:

- A number of the comments are welcome improvements. They will improve the
quality of the document and can be accommodated without substantially
resetting progress on the draft.

- Some other comments are fairly fundamental. For those things to be
seriously looked at, progress on the draft has to be effectively reset, and
a new consensus has to be sought.

A reason this draft has already taken as long as it has is that consensus
is difficult to achieve about a document that covers all of the SSH key
exchanges and attempts to make normative remarks. Now, reviewers who never
previously looked at this have different opinions about decisions that were
subject to prolonged discussions and consensus votes. These reviewers
appear to expect their views to be considered alongside the consensus -
perhaps to override it, invalidate it, correct it, or something of the sort.

I propose that reviews at this late stage should focus on changes that are
appropriate for this late stage, not changes that require a return to the
drafting board. If people have personal opinions about how things should be
done in SSH, then maybe they should get involved before last call.

denis

On Thu, Feb 25, 2021 at 10:18 AM Salz, Rich <rsalz=
[email-masked]> wrote:

>
>    - I do not have any fish to fry here, but I thought IETF Last-Call was
>    to get wider community feedback.
>
>
>
> I like that phrase. :)
>
>
>
> And we had WG discussion on the changes. And a poll (
> https://mailarchive.ietf.org/arch/browse/curdle/?q=%20straw%20poll) about
> some of the issues.
>
>
>
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 27 Feb 2021 17:21:04 -0800

Hi Rene,

Picking just a couple points...

>     which gives everyone else also a bad name.}

The "transition period" is not about time per se, as much as transitioning
an algorithm from "MUST implement" to "MUST NOT implement", with no
algorithms guaranteed to be available in "old" implementations that would
interoperate with "new" implementations.

Yes, we should have published a document to deprecate the SHA-1 algorithms
many years ago; we didn't.  As far as I can tell the best path forward is
to publish something like this now and come back in a year or two to finish
the transition to "MUST NOT".  Recall that continuing to debate will leave
SHA-1 as "MUST implement"!

> function? It is somewhat disturbing that one simply copies what a single 

Note that curve448-sha512 was already specified in RFC 8731, so it is too
late to change anything about it.

I'll echo others' thanks for the feedback; the extra review is appreciated.

-Ben