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

[Ron Frederick <[e-mail]>]

On Aug 17, 2020, at 3:34 PM, Mark D. Baushke <[e-mail]> wrote:
> Ron Frederick <[e-mail]> writes:
>> - 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?

I’m no expert when it comes to key strength, but I would expect a 2048-bit RSA key to last at least as long as 3DES, since both are considered to have 112 bits of security. The applies to DH keys as well. According to Wikipedia, RSA claimed back in 2003 that 2048-bit keys should be good until 2030, and even now the largest RSA key known to be cracked was a key with 829 bits. So, it seems like we’ve got another 5-10 years probably before we’d have to worry about phasing these keys out.


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

As I noted below, I can definitely get behind this as a SHOULD, and perhaps that could position it to become a MUST later when it comes time to retire 2048-bit keys.


> I might suggest Curve25519, as it is pretty fast and has many
> implementations.

I’m definitely a big fan of curve25519/Ed25519, and indeed curve25519-sha256 is the most preferred key exchange algorithm in AsyncSSH right now. However, when it comes to choosing which algorithm to make a MUST, I figured that going with one of the plain DH algorithms might be less of a burden on implementers, as it’s much easier to change the key size than it would be to add ECC support to an implementation that doesn’t yet have it.


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

That’s interesting - I hadn’t read that. I was aware of concerns about potential compromises in the nistp curves, but not specifically about Quantum attacks against ECC.


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

That’s an interesting thought. Are there “best practices” which could be followed in generating/validating  these values that could avoid such a weakness?

For now, my implementation of the “group-exchange” algorithms has been to only let them select from a table of previously generated groups (basically the same group14-18 values that can be named directly). I haven’t looked into what it would take to construct new MODP groups.


> - 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.3.132.0.10 in AsyncSSH after seeing it was
> 
> I think you mean ecdh-sha2-1.3.132.0.10 here?

Whoops, yes. Looks like my cost/paste swallowed the preceding dash.

>>  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-1.3.132.0.10 or ecdh-sha2-oid-1.3.132.0.10 would be better...
> depending on what Bitvise uses.

They use ecdh-sha2-1.3.132.0.10 and so do I, following the guidance in RFC 5656 section 6.3 which states:

   This section specifies identifiers encoding named elliptic curve
   domain parameters.  These identifiers are used in this document to
   identify the curve used in the SSH ECC public key format, the ECDSA
   signature blob, and the ECDH method name.

   For the REQUIRED elliptic curves nistp256, nistp384, and nistp521,
   the elliptic curve domain parameter identifiers are the strings
   "nistp256", "nistp384", and "nistp521".

   For all other elliptic curves, including all other NIST curves and
   all other RECOMMENDED curves, the elliptic curve domain parameter
   identifier is the ASCII period-separated decimal representation of
   the Abstract Syntax Notation One (ASN.1) [ASN1] Object Identifier
   (OID) of the named curve domain parameters that are associated with
   the server's ECC host keys.  This identifier is defined provided that
   the concatenation of the public key format identifier and the
   elliptic curve domain parameter identifier (or the method name and
   the elliptic curve domain parameter identifier) does not exceed the
   maximum specified by the SSH protocol architecture [RFC4251], namely
   64 characters; otherwise, the identifier for that curve is undefined,
   and the curve is not supported by this specification.

   A list of the REQUIRED and RECOMMENDED curves and their OIDs can be
   found in Section 10.

   Note that implementations MUST use the string identifiers for the
   three REQUIRED NIST curves, even when an OID exists for that curve.


So, with the exception of the REQUIRED curves, it looks like it would violate the RFC to use names even when they exist (e.g. ecdh-sha2-secp256k1). So, until there is a new SSH-specific RFC which updates RFC 5656, I think only OIDs should be used.


> I think you might as well use the name, the Koblitz curve names are
> present in RFC 4492.
> 
>    b'1.3.132.0.10': (ec.SECP256K1, SHA256),
>    b'1.3.132.0.34': (ec.secp384r1, SHA384),
>    b'1.3.132.0.35': (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'1.3.36.3.3.2.8.1.1.7':  (ec.brainpoolP256r1, SHA256),
>    b'1.3.36.3.3.2.8.1.1.11': (ec.brainpoolP384r1, SHA384),
>    b'1.3.36.3.3.2.8.1.1.13': (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?

My rule on adding new curves (and algorithms in general) is that I want at least one other independent implementation of that support that I can do interoperability testing against before I’ll consider adding something. For now, I’m not aware of any SSH implementations that support any other curves, but if anyone knows of any, I’d love a pointer to them.

As for adding new named curves to this draft, I would recommend you focus only on implementations currently out there and not introduce anything new. I like the fact that this draft focuses on being a catalog of existing algorithms in actual use, and recommendations for which ones should be prioritized. If someone wanted to recommend new curves, I think that should probably be its own separate draft, and it can then decide whether to recommend using the OID format required by RFC 5656 or updating it to introduce additional non-OID algorithm names.
-- 
Ron Frederick
[e-mail]