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

Rene Struik <> Thu, 25 February 2021 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB6B23A1B47; Thu, 25 Feb 2021 07:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.589
X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, PDS_SHORTFWD_URISHRT_QP=1.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PykZeCJal1B8; Thu, 25 Feb 2021 07:39:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA5B73A1B46; Thu, 25 Feb 2021 07:39:29 -0800 (PST)
Received: by with SMTP id p12so2934752qvv.5; Thu, 25 Feb 2021 07:39:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=VEpLzzzfrBbxTnzEdhr95h2e7tQGRFSweexMcAXgxfA=; b=fb6AUQc0Tqt66UsWPLG8Vlv50VXCZS9IIGpWYlWUFHhEVGw5HjJz0/iCFzuuCP5pqu 2r8MTX7FTuB6Py+UfpHYnl46s6zZCS4gTnyMmtxlKOnmNAaJw0L2rH0LmTlWLLik3zss SThHXKSQEB6bCEvT9jsZ4gnOBpMQ85NQA+/90vg+Bu21zeF5tkB35FEO5zHY59Pcb3zc euEwWkqj3aS5RHkRiPoTivfFeD/0BmLm2lHk/Ar5cOoxqznYfYOEAgE+BMcDYQoyI+7F Z1vFBsm17vqbCe7nnWYJzxpfRjxix1wY1Ms7KAEInYrF43qm2YbUVaviT1TFQvn8KWw/ Okbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=VEpLzzzfrBbxTnzEdhr95h2e7tQGRFSweexMcAXgxfA=; b=nOvlZeGVczu7YuYQ+tSEelf7iyptrOQZRd4qgfakNIfluj3Asg5oGyAkwL8nxswqGo EDUaVeUafkr4QPA4oYaCrco2rZqL5oYfYlPCG8Iwi+/Mv4HbMgobo5uGGGTLkHKEPzPr ozw0c1fPLy3IFNCxfZClozAtxiRCVeU/rksSDHgJzvPm3mUzsEtqtwNe/Q82eXRi8DMD MwLBXS9IXMmtJYAXddk4mRYvSIfW8JHpcwYC/7vvyX+NB/inB46/CE8ZlZiIOIZzgHpk i6y07l6OjSXSFC8VlbT/lIlHHCBGi+GlvKs1nwjaufd4VaxtOT5TXcoPRvZWjudYp/Ee VvWQ==
X-Gm-Message-State: AOAM530e8N7VCj7pJoYoKiV0OdYHXXEKIxGaRHE6YQPPTgnYZPpJXk9k er0bSyWqqcco9JrhzkZG3Ic=
X-Google-Smtp-Source: ABdhPJx9J8jzORpoIZZkIIFJkcyuNPQOdqb0kx21KCIvTo4rYHl1n9J+RrSFDu1h3S1t549hZRNOJw==
X-Received: by 2002:ad4:4692:: with SMTP id bq18mr3176163qvb.0.1614267567532; Thu, 25 Feb 2021 07:39:27 -0800 (PST)
Received: from ?IPv6:2607:fea8:8a0:1397:b015:b65a:26d0:15a2? ([2607:fea8:8a0:1397:b015:b65a:26d0:15a2]) by with ESMTPSA id q15sm3754902qti.9.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Feb 2021 07:39:27 -0800 (PST)
To: "Mark D. Baushke" <>
Cc:,,,, Daniel Migault <>
References: <> <> <>
From: Rene Struik <>
Message-ID: <>
Date: Thu, 25 Feb 2021 10:39:24 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------AA0C4C2D4EA42D597635D852"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Curdle] Last Call: <draft-ietf-curdle-ssh-kex-sha2-14.txt> (Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Feb 2021 15:39:33 -0000

Hi Mark:

Brief feedback below..


On 2021-02-24 9:12 p.m., Mark D. Baushke wrote:
> Hi Rene,
> I have tried to address all of your comments below.
> Rene Struik <> writes:
>> 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?
> 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.

RS>> Please note that IACR awarded the "test of time" award (see 15 years) to

 From Crypto 2005:Finding collisions in the full 
SHA-1<>, by Xiaoyun Wang, Yiqun Lisa 
Yin and Hongbo Yu/For a breakthrough in the cryptanalysis of hash 

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

>> - 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?
> 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.
RS>> okay. <<RS
>> - 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}.
> 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.
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
>> - 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?
> 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 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
> 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.
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
>> - 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).
> 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.
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
>   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.
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
> 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.
>> - (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?
> 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.

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)


> If you are talking about mpint for other parts of the SSH protocol, then
> that may be worth a larger discussion.
>> 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.])
> 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

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