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

denis bider <> Wed, 19 August 2020 00:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC2443A1056 for <>; Tue, 18 Aug 2020 17:21:44 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zXGvHdEQ5nny for <>; Tue, 18 Aug 2020 17:21:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71D153A1053 for <>; Tue, 18 Aug 2020 17:21:42 -0700 (PDT)
Received: by with SMTP id k63so4535517oob.1 for <>; Tue, 18 Aug 2020 17:21:42 -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=Muj1G6/qEJpYUsNY8BHX+SE6S3vUtl5F0wlV/Nj64BA=; b=KLcIoTzb3lrjodnCkMJM+IMxxX8b5SsNVe/lYknGnZ4gJx6OizduzM8lZKEwHKafnf ZkZBFZQlxe7uuMQ0kNKJCT4AB3Z0EXMFVf3T5MFf1I5HATrhY3yFZfpMwz7erJlAeQho 6K+yqs4TVb7cRkkP/Wn1mnsp9KMZTsPyFjtx5sFM/UqNqAA1akWwn+u6Y+sAbjZvhFvY 1wLa3mAPTTb0ty7UnOEThIPKEGMYciohVmdpBUNNx0aMjiKzSYCPI0TxUJ210g4I6RXz 5FgRgG7Mu4Irzd9Pw6fu7HlJaavrA/yVuF2Fhl4D3bew2/pAV3TQSLtENtqlmr89yKZo MndQ==
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=Muj1G6/qEJpYUsNY8BHX+SE6S3vUtl5F0wlV/Nj64BA=; b=LnzDluu+9fAvC1CH6Zv0enQ3eiRL+/ECGLkyTUBeBY3QXVw+YXqZaaW9PEy1qsNUcj QoOMMJ0M3e1p7fX9nM+YuAA4xUwtw+zNIVnC08M8TeCWn0TfG7mW9uRLLLfuqcCdwM1r YZGocja3IKVuaecPRfpKV2RY9lVkAWf1Nz7jlJcMxl1ryxPjKb5Pdb3NoEg40OJR4S2Y xV33X0QVA4ghIx+xmncCEyLV8Wt/urlCzO3qrAE35vuEzx/iXp3iEynqxBwMCE8LoZXu eCSn0i4PX8p3YQ3HIMzmFBflFjjGaS3qNUUlEj+p9aEM3GHSsJASpjuKl1bz5z6mH87F zEgw==
X-Gm-Message-State: AOAM5308StuKBQdxatjGhbN8LtG/EGcuLw+GrefX80TCNSUw3XoubS5x DtsEFGYMt1JN7UNHneDY1N6pDxIECMymFr3X0wr/5kN7+Q4bqg==
X-Google-Smtp-Source: ABdhPJwKWAp+yKTV275gvfXr/zpO/IGrRAziQ2JeOf/25SoqJW3CWd/vnsZk+pOs4cr7JjvDZtRiBhy775gJrwNTa7w=
X-Received: by 2002:a4a:9e41:: with SMTP id w1mr16843875ook.87.1597796501657; Tue, 18 Aug 2020 17:21:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: denis bider <>
Date: Tue, 18 Aug 2020 19:21:30 -0500
Message-ID: <>
To: "Mark D. Baushke" <>
Cc: Ron Frederick <>, curdle <>
Content-Type: multipart/alternative; boundary="000000000000e79dab05ad2ffcd0"
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 00:21:45 -0000

> Perhaps we should opt to make diffie-hellman-group-exchange-sha256
> a MUST? This allows implementors to put in whatever MODP groups
> they wish

I think this is unwise for reasons mentioned earlier: implementations
generate their own DH groups which fail FIPS tests and are incompatible
with FIPS implementations. In the interest of compatibility, FIPS
implementations then have to avoid this algorithm.

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

The main problem here is that OpenSSH does not implement it. Last time I
checked, their stated reasoning was that 3072 bits was "too much
granularity". They like either 2048 or 4096. But on constrained devices,
4096 is super expensive.

I agree here that 3072-bit DH and RSA are a sweet spot for a fair amount of
future security with acceptable performance. If it was up to me with no
other considerations involved, I would declare this the conservative
"MUST". If everyone else decides this and declares it so, then perhaps
OpenSSH might reluctantly support it. However, it's also quite possible
they might not.

And even if they do, it's not CURRENTLY offered by any existing OpenSSH

For now, I think we're left with either group14 as the only widely
acceptable MUST, or no MUST key exchange algorithm at all.

The NIST post-quantum crypto fest is also slowly unfolding, and we may have
a post-quantum standard in a few years. I think that will be the next major
event that changes the algorithm preference landscape, more so than great
classic progress in breaking larger RSA or DH. If there is surprising
progress in breaking RSA or DH, chances are it will be quantum rather than
classic, in which case the new standard will need to be the winner of the
post-quantum contest, which we currently don't have.


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