Re: [Curdle] Looking for comments on draft-ietf-curdle-ssh-kex-sha2

denis bider <> Wed, 19 August 2020 02:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB60C3A10A3 for <>; Tue, 18 Aug 2020 19:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DP5lDPJCkG-O for <>; Tue, 18 Aug 2020 19:01:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24C113A109E for <>; Tue, 18 Aug 2020 19:01:32 -0700 (PDT)
Received: by with SMTP id l84so19688713oig.10 for <>; Tue, 18 Aug 2020 19:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tFHopz3EAENFTMVKFB6TCoeSoEbr1p8OFLElxaFcc8E=; b=WFDxo/fgEGfUGSUBY4xx1FrTbyj8w4q02p03jjLwET9SO+ZvRFTgPJBFlWbmek7xAx 6bCxEcJpUvwANWkSm2N5at6mHoT3j+JG84ZHUXkC9YWYgWhpmJO9pQhTzIl4ySy5mdSu 9z0MO2/Xigt/8yKhLnLleWLf4Pvm9fmKLQw2MjFSdNjdk3JnpZdDN53FYUHXjkTh1jQ3 qXlRivaswAT6pdFwmVqkhnvROVp5RWE9/bKxBQLv1/GvUAqbjYd1i0IN0D94HcZZY+VK PRoa83s3JwlLrn1S+XE7S4GdhOlAD2+lkVrMK89fGvnJ3eoebBk6KgTWEeQnrkAxOp8Q /hDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tFHopz3EAENFTMVKFB6TCoeSoEbr1p8OFLElxaFcc8E=; b=Vj3vPIvTfIuWVI0rPCNl/CtTU1hA1T7e6nCE9P8Nbm7FP2E5/Z4086HoUaE+o7GkNz 4tQu3OH4AXg6M6YOc9fLyUFmS5oNFkSLpjEwiaJE9ZA/TX/2KryqM9uRyqgxakB1M4dT vQvRJ8WuyfZf8nRHwT8Hj0k79lqRXnl3Cu4Ctyp4Sht91TILkko65hqNZ4HAHJxUKdF4 vAunnQU2tqeDQF4PpTjQyWsjBP6xcYSgaRKme74sQDe13VieaAeKoF1ATZH/aQtBiORB jtEmmGW6fKaRm8hQMg9r6Mz7Gum13CZZy7wFGAJBpzQ4iA4e4xmwl1MO4ukZn/UKuBII JrKw==
X-Gm-Message-State: AOAM531E/tWdhvvjmdkZ7b1HwJIr1rNEml01Xxb37T82Ca8RLgNFMRwn g97Ap0GlmYdAf/FHoOCRCRGN+1m1qHLuFSLBDZvhAOeif7OqMg==
X-Google-Smtp-Source: ABdhPJySUVEMpW5Ykg6+1unmQh3/8KOoaddLUzgCIpGgCKjMn23XFNOeYpRW39DXySAJu1KLLuQmqFEsmULd7IzC0B4=
X-Received: by 2002:a54:4088:: with SMTP id i8mr1873884oii.139.1597802491231; Tue, 18 Aug 2020 19:01:31 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: denis bider <>
Date: Tue, 18 Aug 2020 21:01:20 -0500
Message-ID: <>
To: "Mark D. Baushke" <>
Cc: Ron Frederick <>, curdle <>
Content-Type: multipart/alternative; boundary="000000000000e941fe05ad3161ab"
Archived-At: <>
Subject: Re: [Curdle] Looking for comments on draft-ietf-curdle-ssh-kex-sha2
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: Wed, 19 Aug 2020 02:01:35 -0000

About ECDH/secp256k1:

> The reserved name is for ecdh-sha2-* ... so ecdh-sha2-secp256k1
> or ecdh-sha2- or ecdh-sha2-oid- would be
> better... depending on what Bitvise uses.

RFC 5656 is clear about this and provides an example:

"For example, the method name for ECDH key exchange with ephemeral
generated on the sect409k1 curve is "ecdh-sha2-"."

secp256k1 is not among the curves explicitly named in RFC 5656, therefore
it uses the OID form (unfortunately).

Bitvise SSH Server, SSH Client and FlowSsh (the library) use the following
for ECDSA and ECDH over secp256k1:


I'm not sure if ECDH over secp256k1 needs to be mentioned in the draft. If
so, the reason would be to acknowledge its practical usage. In this case,
the disposition should be "MAY" and there ought to be some remark to
indicate this is secp256k1.

> Does anyone else want me to add either the Koblitz or Brainpool
> names or OIDs to this IETF draft?

In theory, we could add all the possible curves that have OID assignments.
I would not add them unless there exist practical implementations that are
in use.


On Mon, Aug 17, 2020 at 5:34 PM Mark D. Baushke <mdb=> wrote:

> Ron Frederick <> writes:
> > This generally looks good to me.
> I am still going back over some of the comments that ekr provided...
> > Here are a few more detailed comments:
> >
> > - Sections 3.14 and 3.15 list the ext-info values as SHOULD (which I
> >   agree with). However, your table in section 5 has them marked as
> >   MAY.
> Updated in my copy.
> > - I noticed you dropped diffie-hellman-group14-sha256 back from MUST
> >   to SHOULD, leaving no algorithms listed as MUST. I’d still like to
> >   see at least one algorithm be listed as MUST, and think this is
> >   probably the safest candidate for that.
> How long is a 2048-bit prime, even with such a large q-ordered subgroup
> likely to remain viable?
> 1024-bits for:
>   a) IFC RSA,
>   b) FFC DSA, and
>   c) FFC DH,
>   d) as well as FFC DH group5 (1536-bits)
> are all considered too weak now.
> 3DES with 112-bits of security is being phased out as of January 1, 2024.
> When should we expect to see 2048-bit RSA, which also nominally has only
> 112-bits of security as does 2048-bit DSA become retired?
> To me, it looks like the better bet would be the 3072-bit MODP prime of
> group15, but I do not see it being adopted by most implementations.
> I might suggest Curve25519, as it is pretty fast and has many
> implementations.
> That said, there are many who have been doing research which seems to
> show that ECC is easier to break with Quantum Crypto systems than FFC
> and are NOT interested in implementating ANY ECC algorithms.
> I believe I have seen some text from implementers who have said they
> would NOT adopt ECC for their SSH implementations.
> > - I’m also thinking diffie-hellman-group15-sha512 might be a good
> >   candidate for a SHOULD rather than a MAY, but I’m not sure we have
> >   consensus on that.
> Yup, I have not seen any consensus on this issue as yet.
> Perhaps we should opt to make diffie-hellman-group-exchange-sha256 a
> MUST? This allows implementors to put in whatever MODP groups they wish
> as long as q = (p-1)/2 ... so, a maximized q-ordered subgroup... though
> I o worry a bit about the way that the generator g is created perhaps
> not providing that g^q mod p == 1 is a will formed subgroup. When it is
> not a well-formed subgroup, then it will be leaking the first bit of the
> key value.
> > - I agree with the downgrade of diffie-hellman-group16-sha512 from
> >   SHOULD to MAY.
> Okay.
> > - Regarding possible ECDSA algorithms, I implemented the secp256k1
> >   curve as ecdh-sha21. in AsyncSSH after seeing it was
> I think you mean ecdh-sha2- here?
> >   implemented by Bitvise. I don’t know if it is worth mentioning here
> >   explicitly, but it’s one real-world example of an ecdh-sha2-*
> >   algorithm not explicitly given a name in RFC 5656. The ‘endsa-sha2’
> >   algorithm with this curve is also supported.
> The reserved name is for ecdh-sha2-* ... so ecdh-sha2-secp256k1 or
> ecdh-sha2- or ecdh-sha2-oid- would be better...
> depending on what Bitvise uses.
> I think you might as well use the name, the Koblitz curve names are
> present in RFC 4492.
>     b'': (ec.SECP256K1, SHA256),
>     b'': (ec.secp384r1, SHA384),
>     b'': (ec.secp521r1, SHA512),
> For that matter, as long as you are going to use vanity curve for Bitcoin;
> Why not use the RFC 7027 ECC Brainpool curves too?
>     b'':  (ec.brainpoolP256r1, SHA256),
>     b'': (ec.brainpoolP384r1, SHA384),
>     b'': (ec.brainpoolP512r1, SHA512),
> That said, given that they are named in RFC 7027, using their names may
> be better too.
> Does anyone else want me to add either the Koblitz or Brainpool names or
> OIDs to this IETF draft?
>         Be safe, stay healthy,
>         -- Mark
> > --
> > Ron Frederick
> >
> _______________________________________________
> Curdle mailing list