Subject: Re: [Curdle] Which curves are MUST and SHOULD ?

From: Hubert Kario <[email-masked]>
Date: Mon, 04 Jan 2021 17:53:38 +0100

On Thursday, 17 December 2020 20:35:24 CET, Mark D. Baushke wrote:
> Ron Frederick <[email-masked]> writes:
>
>> On Dec 15, 2020, at 8:09 AM, Salz, Rich <[email-masked]> wrote:
>>>>   I’m not comfortable with algorithms going from REQUIRED to 
>>>> SHOULD NOT without some kind of transitional period. My 
>>>> suggestion would be to ease into this with SHOULD NOT for 
>>>> now. If you want to discuss BCP in this draft, perhaps that 
>>>> can be a separate section.
>>> 
>>> We've done it before, MD5, short RSA/DH keys, etc.
>>> 
>>> We shouldn't pretend that crypto-breaking advances haven't happened.
>>> 
>>> Admins can make trade-offs anyway.
>
> I am under the impression that the audience here is the maintainers of
> SSHv2 software rather than the administrators that manage the sites
> using it.

it's both
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 4 Jan 2021 12:21:50 -0800

> > SSHv2 software rather than the administrators that manage the sites

Fair enough.

Two kinds of stakeholders: a) "implementors" and b) "users" should mean
more responses for the question.

Okay. In the original RFC4253 specification both

    diffie-hellman-group1-sha1 
and
    diffie-hellman-group14-sha1

were REQUIRED key exchanges.

The group1 parameters in RFC4253 point to the 1024-bit MODP Second
Oakley Group given in RFC2409 section 6.2 and RFC2412 section E.2.

There are two issues with diffie-hellman-group1-sha1: 1) recent
estimages are that it has roughly 80 bits of security strength, and 2)
it uses SHA1 for hashing which is considered weak.

If we choose "MUST NOT" for this key exchange, then we are going from
"MUST" to "MUST NOT" which could be a hardship for low-end devices
unable to run calculations to generate a shared secret using a larger
MODP group if support is completely removed.

If we choose "SHOULD NOT", then it is hoped that most implementors would
default to not configuring this option by default, but may provide it
for enviornments that need it.

If we choose "MAY", then it is not certain if implementors or users will
do much of anything different and this potentially insecure key exchange
may continue to be used even when it may be a hazard to those that
desire a more secure by default system.

Are you an SSH impelmentor or user or both?

  Implementor
  User
  Both

I would like to get a straw vote for the six *sha1* related key
exchanges. I am proposing that the rsa1024-sha1-* kex be a MUST NOT and
that all of the others be a SHOULD NOT.

1. For diffie-hellman-group1-sha1 what is your vote?

  MUST          -- current for RFC4253
  SHOULD
  MAY
  SHOULD NOT    -- proposed in the -13 draft
  MUST NOT

2. For diffie-hellman-group14-sha1 what is your vote?

  MUST          -- current for RFC4253
  SHOULD
  MAY           -- proposed in the -13 draft
  SHOULD NOT
  MUST NOT

3. For diffie-hellman-group-exchange-sha1 what is your vote?

  MUST
  SHOULD
  MAY           -- current for RFC4419    
  SHOULD NOT    -- proposed in the -13 draft
  MUST NOT

4. For rsa1024-sha1 what is your vote?

  MUST
  SHOULD
  MAY           -- current for RFC4432
  SHOULD NOT
  MUST NOT      -- proposed in the -13 draft

5. For gss-gex-sha1-* what is your vote?

  MUST
  SHOULD        -- current for RFC4462
  MAY
  SHOULD NOT    -- proposed in the -13 draft
  MUST NOT  

6. For gss-group1-sha1-* what is your vote?

  MUST
  SHOULD        -- current for RFC4462
  MAY
  SHOULD NOT    -- proposed in the -13 draft
  MUST NOT  

You may direct your votes to the list or to the chairs and me.

	Be safe, stay healthy,
	-- Mark

---

From: Daniel Migault <[email-masked]>
Date: Mon, 4 Jan 2021 15:56:31 -0500

Hi,

Thanks for the follow-up. Please find my responses. I would encourage the
WG to state his opinion as soon as possible. Would the end of the week fine
?

Yours,
Daniel

On Mon, Jan 4, 2021 at 3:21 PM Mark D. Baushke <mdb=
[email-masked]> wrote:

> user

> I am fine with the -13 draft

> I am fine with either MAY as well as SHOULD NOT

> I am fine with the -13 draft

> I am fine with the -13 draft

> I am fine with the -13 draft

> I am fine with the -13 draft

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

-- 
Daniel Migault
Ericsson

---

From: Simo Sorce <[email-masked]>
Date: Mon, 04 Jan 2021 20:55:25 -0500

Votes inline.

> Are you an SSH impelmentor or user or both?

I am Both, but I lean on the Implementor side.

SHOULD NOT

MAY

SHOULD NOT

MUST NOT

SHOULD NOT

MAY

The reason why I voted MAY in the last is that the draft to implement
gssapi with sha2 has been published only recently, so in order to
interoperate with older client I think we still need a MAY, but I would
not be upset if the group chooses SHOULD NOT. (GEX is less used and
less critical, so I am ok with SHOULD NOT there)

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 4 Jan 2021 18:38:49 -0800

To make things easier to count. Here is a template for your response:

Template::

From:
Implementor-or-User: 
diffie-hellman-group1-sha1: 
diffie-hellman-group14-sha1: 
diffie-hellman-group-exchange-sha1: 
rsa1024-sha1: 
gss-gex-sha1-*: 
gss-group1-sha1-*: 

If you are an Implementor, you are assumed to also be a user and get one
vote as an Implementor and one vote as a User (that is your vote is
worth twice as much as a User).

If you list more than one response, like "MAY" or "SHOULD NOT" then I
suppose each could get a fraction of your vote, but I would rather not
see vote splitting done. Please take a stand.

My vote is the current (unpublished) -13 draft suggested values:

----------%<----------%<----------%<----------%<----------%<----------

From: Mark Baushke <[email-masked]>
Implementor-or-User: User
diffie-hellman-group1-sha1: SHOULD NOT
diffie-hellman-group14-sha1: MAY
diffie-hellman-group-exchange-sha1: SHOULD NOT
rsa1024-sha1: MUST NOT
gss-gex-sha1-*: SHOULD NOT
gss-group1-sha1-*: SHOULD NOT

----------%<----------%<----------%<----------%<----------%<----------

I would expect that any "MUST NOT" votes are requesting that the
Implementors will remove any code to support the Key Exchange.

A "SHOULD NOT" vote would be a vote requesting that the Key Exchange not
be enabled by default.

A "MAY" vote would be a vote requesting that the Key Exchange be listed
as among those of last resort among the list of proposed Key Exchanges.

If you wish to update your vote, please send me email and I will replace
your vote.

Should I post the summary of the Straw Poll with email addresses at the
end of the period (say, two weeks hence? at 17:00 UTC on 2021-01-19).

	Be safe, stay healthy,
	-- Mark

---

From: Ron Frederick <[email-masked]>
Date: Mon, 4 Jan 2021 18:40:34 -0800

> Are you an SSH impelmentor or user or both?

[Ron] Primarily implementor for this discussion, but I’m also definitely an SSH end-user (for both client and server).

>  SHOULD NOT    -- proposed in the -13 draft

[Ron] I’m good with SHOULD NOT here, and would take this to mean that this could still be explicitly enabled but would be disabled by default in my implementation.

>  MAY           -- proposed in the -13 draft

[Ron] I’m good with MAY here, and would consider group14-sha1 as the preference to maintain interoperability with older/slower devices.

>  SHOULD NOT    -- proposed in the -13 draft

[Ron] I’m good with SHOULD NOT here.

>  MUST NOT      -- proposed in the -13 draft

[Ron] I’d be ok with either SHOULD NOT or MUST NOT on this one. I’d lean toward SHOULD NOT to be consistent with other sha1 cases here and to give a bit more time for people to move off of rsa1024-sha1 before implementations start removing it completely. However, I’m not sure it was ever that popular to begin with, so I don’t really know how necessary it is to do this in two phases.

>  SHOULD NOT    -- proposed in the -13 draft

[Ron] I’m good with SHOULD NOT for both of these.
-- 
Ron Frederick
[email-masked]

---

From: Ron Frederick <[email-masked]>
Date: Mon, 4 Jan 2021 18:43:54 -0800

Sorry - didn’t see the template until after I sent my votes, but here they are in the request format:

From: Ron Frederick <[email-masked]>
Implementor-or-User: Implementor
diffie-hellman-group1-sha1: SHOULD NOT
diffie-hellman-group14-sha1: MAY
diffie-hellman-group-exchange-sha1: SHOULD NOT
rsa1024-sha1: SHOULD NOT
gss-gex-sha1-*: SHOULD NOT
gss-group1-sha1-*: SHOULD NOT

---

From: denis bider <[email-masked]>
Date: Tue, 5 Jan 2021 06:54:58 -0600

It's not both. It is developers that are aware of RFCs.

In my experience supporting users over 20 years, only a vanishing minority
of users are even aware of RFCs, and none read them.

denis

---

From: denis bider <[email-masked]>
Date: Tue, 5 Jan 2021 07:02:16 -0600

Furthermore, in my experience dealing with users, you can generally expect:

- Users think "SSH" is a misspelling of "SSL"

- They're given a security requirement to disable old TLS versions, and
they look into SSH server settings to achieve that

- They think "SHA" is a signature algorithm

- They don't know what "RSA" is or what "DH" does

- They think they need to set up TLS certificates with SSH (which is
possible, sure, but not needed or widely supported - our software still
doesn't)

These are users.

Users might think "RFC" stands for "Request For Cake".

denis

---

From: Hubert Kario <[email-masked]>
Date: Tue, 05 Jan 2021 14:03:56 +0100

> of users are even aware of RFCs, and none read them.

by "user" I mean "administrator"

and system administrators do read RFC

>>  ...

---

From: Simo Sorce <[email-masked]>
Date: Tue, 05 Jan 2021 09:17:49 -0500

Hi Denis,
it does not serve any purpose to characterize users by depicting them
as ignorant, repeating trite tropes is demeaning and useless,
especially in a WG.

Users cover a large spectrum, just like developers cover a large
spectrum. If I wanted to make fun of developers I could say the exact
things you wrote of some of them.

The users I am in contact with (sysadmins/devops) are very
knowledgeable, and can make reasoned choices, as well as understand
perfectly well what SSH is and what the various algorithm acronyms
stand for.

In this case users understand pretty well what their installed base is,
whether they can move off of some legacy algorithm or not, and how
fast. In this area, my experience is that developers have generally not
enough data to make good choices, instead.

Peace & Empathy,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: denis bider <[email-masked]>
Date: Tue, 5 Jan 2021 13:44:57 -0600

> by "user" I mean "administrator"

Yes, and so did I.

> and system administrators do read RFC

That's technically correct if you meant 0.1% of administrators read RFCs.

Simo:

> The users I am in contact with (sysadmins/devops)
> are very knowledgeable

These are the 0.1%. The 99.9% do not have a way to access you to begin with.

> it does not serve any purpose to characterize users by depicting
> them as ignorant, repeating trite tropes is demeaning and useless,
> especially in a WG.

You think I'm being hateful and antagonistic, so therefore you become
hateful and antagonistic.

I'm not being hateful and antagonistic. That's all you.

I'm telling you how things are.

denis

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 12 Jan 2021 12:30:20 -0800

A reminder to the CURdle list members. There is a poll running for
draft-ietf-curdle-ssh-kex-sha2 recommendations on the *sha1* key
exchange algorithms. The poll ends at 17:00 UTC on 2021-01-19. At that
time, I will take the poll responses and tally up the votes to see what
recommendation to put into the -13 draft which I hope will go to WGLC.

At present, I have straw poll input from the following individuals:

    Mark Baushke <[email-masked]> (user)
    Ron Frederick <[email-masked]> (implementor)
    Daniel Migault <[email-masked]> (user)
    Simo Sorce <[email-masked]> (implementor)
    Peter Gutmann <[email-masked]> (implementor)

Current weighted voting favors this set of recommendations:

  Kex Algorithm                       Recommendation
====================================================================
 diffie-hellman-group1-sha1:         SHOULD NOT (8)
 diffie-hellman-group14-sha1:        MAY (8)
 diffie-hellman-group-exchange-sha1: SHOULD NOT (6), MAY (2)
 rsa1024-sha1:                       MUST NOT (6), SHOULD NOT (2)
 gss-gex-sha1-*:                     SHOULD NOT (8)
 gss-group1-sha1-*:                  SHOULD NOT (6), MAY (2)
====================================================================

I hope that after I publish the -13 draft on 2021-01-19, we can move the
draft to WGLC.

Anyone who wants to vote in the next week, please do so. The template
to use is:

Template::

I will assume that an Implementor is also a User.
I will also give an Implementor double the vote for this reason.

If you give a vote like "MAY or SHOULD NOT" I will assume "MAY" as it is
the least restrictive.

You may change your vote, just send a new message to the list or to me
personally with the update.

	Be safe, stay healthy,
	-- Mark

---

From: denis bider <[email-masked]>
Date: Wed, 13 Jan 2021 17:32:45 -0600

My vote:

----------%<----------%<----------%<----------%<----------%<----------
From: denis bider
Implementor-or-User: Implementor
diffie-hellman-group1-sha1: SHOULD NOT (or MUST NOT)
diffie-hellman-group14-sha1: MAY (or SHOULD NOT)
diffie-hellman-group-exchange-sha1: SHOULD NOT (or MAY)
rsa1024-sha1: MUST NOT
gss-gex-sha1-*: SHOULD NOT (or MAY)
gss-group1-sha1-*: SHOULD NOT (or MUST NOT)
----------%<----------%<----------%<----------%<----------%<----------

I put current majority opinions as my first preference because (1) I am
okay with them, (2) I think multiple options are acceptable and it's more
important to move forward with the document than to identify the most ideal
option, which would require 20/20 hindsight which we don't have. So I think
all of the acceptable options are good, I find the majority votes to be
acceptable options, and therefore I support the majority options.

denis

---

From: Daniel Migault <[email-masked]>
Date: Wed, 13 Jan 2021 22:44:35 -0500

Hi,

I would encourage the WG to provide their feedbacks by tomorrow - or at
least send a notice they intend to send their feedbacks - so Mark can
update the draft as soon as possible.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 14 Jan 2021 12:51:20 -0800

Hi,

Per Daniel's request, I plan to close the poll at 5pm PST.

Here is what I have so far.

    denis bider <[email-masked]> (implementor)

  Kex Algorithm                       Recommendation
====================================================================
 diffie-hellman-group1-sha1:         SHOULD NOT (10)
 diffie-hellman-group14-sha1:        MAY (19)
 diffie-hellman-group-exchange-sha1: SHOULD NOT (8), MAY (2)
 rsa1024-sha1:                       MUST NOT (8), SHOULD NOT (2)
 gss-gex-sha1-*:                     SHOULD NOT (10)
 gss-group1-sha1-*:                  SHOULD NOT (8), MAY (2)
====================================================================

	Be safe, stay healthy,
	-- Mark

PS: Here are the current differences between the published -12 and the
current -13 draft which I plan to upload tonight if no other votes come
in to change the current weighting.

--- draft-ietf-curdle-ssh-kex-sha2-12.txt	2020-11-23 13:25:22.000000000 -0800
+++ draft-ietf-curdle-ssh-kex-sha2-13.txt	2021-01-13 20:50:14.000000000 -0800
@@ -4,9 +4,9 @@
 
 Internet Engineering Task Force                            M. D. Baushke
 Internet-Draft                                    Juniper Networks, Inc.
-Updates: 4250 (if approved)                             23 November 2020
+Updates: 4250 4253 4432 4462 (if approved)               13 January 2021
 Intended status: Standards Track                                        
-Expires: 27 May 2021
+Expires: 17 July 2021

  Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
@@ -35,11 +35,11 @@
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 27 May 2021.
+   This Internet-Draft will expire on 17 July 2021.
 
 Copyright Notice
 
-   Copyright (c) 2020 IETF Trust and the persons identified as the
+   Copyright (c) 2021 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
@@ -67,7 +67,7 @@
        1.2.2.  Finite Field Cryptography (FFC) . . . . . . . . . . .   4
        1.2.3.  Integer Factorization Cryptography (IFC)  . . . . . .   5
    2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
-   3.  Key Exchange Methods  . . . . . . . . . . . . . . . . . . . .   5
+   3.  Key Exchange Methods  . . . . . . . . . . . . . . . . . . . .   6
      3.1.  SHA-1 and SHA-2 Hashing . . . . . . . . . . . . . . . . .   6
      3.2.  Elliptic Curve Cryptography (ECC) . . . . . . . . . . . .   6
        3.2.1.  curve25519-sha256 and gss-curve25519-sha256-* . . . .   6
@@ -97,7 +97,11 @@
    considered secure is no longer considered secure.  The purpose of
    this RFC is to recommend that some published key exchanges be
    deprecated as well as recommending some that SHOULD and one that MUST
-   be adopted.  This document updates [RFC4250].
+   be adopted.  This document updates [RFC4250] [RFC4253] [RFC4432]
+   [RFC4462] by changing the requirement level ("MUST" moving to
+   "SHOULD" or "MAY" or "SHOULD NOT", and "MAY" moving to "MUST" or
+   "SHOULD" or "SHOULD NOT" or "MUST NOT") of various key-exchange
+   mechanisms.
 
    A key exchange has two components, a hashing algorithm and a public
    key algorithm.  The following subsections describe how to select each
@@ -121,11 +121,28 @@
    are weaknesses in the algorithm.  Therefore, it is desirable to move
    away from using it before attacks become more serious.
 
-   At present, the attacks against SHA-1 are collision attacks that rely
-   on human help rather than a pre-image attack.  So, it is still
-   possible to allow time backward compatibility use of SHA-1 during a
-   SSH key-exchange for a transition to stronger hashing.  However, any
-   such key exchanges should be listed last in the preference list.
+   At present, the attacks against SHA-1 are collision attacks that
+   usually rely on human help rather than a pre-image attack.  SHA-1
+   resistance against 2nd pre-image is still at 160 bits, but SSH does
+   not depend on that, but rather on chosen prefix resistance.
+
+   Transcript Collision attacks are documented in [TRANS-COLL].  This
+   paper shows that the man in the middle does not tamper with the
+   Diffie-Hellman values and does not know the connection keys.
+   However, it manages to tamper with both Ic and Is, and can therefore
+   downgrade the negotiated ciphersuite to a weak cryptographic
+   algorithm that the attacker knows how to break.
+
+   These attacks are still computationally very difficult to perform,
+   but is is desirable that any Key Exchanging using SHA-1 be phased out
+   as soon as possible.
+
+   These attacks are potentially slightly easier when the server
+   provides the Diffie-Hellman parameters such as using the [RFC4419]
+   generated set of diffie-hellman parameters with SHA-1 hashing.  If
+   there is a need for using SHA-1 in a Key Exchange for compatibility,
+   it would be desirable it be listed last in the preference list of key
+   exchanges.
 
    Use of the SHA-2 family of hashes found in [RFC6234] rather than the
    SHA-1 hash is strongly advised.
@@ -145,6 +162,14 @@
 
    SSH uses mathematically hard problems for doing Key Exchange:
 
+
+
+
+Baushke                   Expires 17 July 2021                  [Page 3]
+
+Internet-Draft KEX Method Updates/Recommendations for SSH   January 2021
+
+
    *  Elliptic Curve Cryptography (ECC) has families of curves for Key
       Exchange Methods for SSH.  NIST prime curves with names and other
       curves are available using an object identifier (OID) with
@@ -159,17 +184,6 @@
    *  Integer Factorization Cryptography (IFC) using the RSA algorithm
       is provided for in [RFC4432].
 
-
-
-
-
-
-
-Baushke                    Expires 27 May 2021                  [Page 3]
-
-Internet-Draft KEX Method Updates/Recommendations for SSH  November 2020
-
-
    It is desirable for the security strength of the key exchange be
    chosen to be comparable with the security strength of the other
    elements of the SSH handshake.  Attackers can target the weakest
@@ -251,6 +251,8 @@
    The only IFC algorithm for key exchange is the RSA algorithm via
    [RFC4432].  The minimum modulus size is 2048 bits.  The use of a
    SHA-2 Family hash with RSA 2048-bit keys has sufficient security.
+   The rsa1024-sha1 key exchange has less than 2048 bits and MUST NOT be
+   implemented.
 
            +=====================+=============================+
            | Key Exchange Method | Estimated Security Strength |
@@ -270,18 +272,21 @@
    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.
 
-3.  Key Exchange Methods
 
-   This memo adopts the style and conventions of [RFC4253] in specifying
-   how the use of data key exchange is indicated in SSH.

-Baushke                    Expires 27 May 2021                  [Page 5]
+
+Baushke                   Expires 17 July 2021                  [Page 5]
 
-Internet-Draft KEX Method Updates/Recommendations for SSH  November 2020
+Internet-Draft KEX Method Updates/Recommendations for SSH   January 2021

+3.  Key Exchange Methods
+
+   This memo adopts the style and conventions of [RFC4253] in specifying
+   how the use of data key exchange is indicated in SSH.
+
    This RFC also collects key exchange method names in various existing
    RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
    [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a
@@ -305,9 +310,10 @@
    is the stronger of the two.  Group14 (a 2048-bit MODP group) is
    defined in [RFC3526].  It is reasonable to retain the diffie-hellman-
    group14-sha1 exchange for interoperability with legacy
-   implementations.  Therefore, diffie-hellman-group14-sha1 SHOULD be
-   implemented and all other *-sha1 key exchanges SHOULD NOT be
-   implemented.
+   implementations.  Therefore, diffie-hellman-group14-sha1 MAY be
+   implemented.  The diffie-hellman-group1-sha1, diffie-hellman-group-
+   exchange-sha1, gss-gex-sha1-*, and gss-group1-sha1-* key exchanges
+   SHOULD NOT be implemented.
 
 3.2.  Elliptic Curve Cryptography (ECC)
 
@@ -519,7 +519,7 @@
      +--------------------------------------+-----------+------------+
      | diffie-hellman-group1-sha1           | RFC4253   | SHOULD NOT |
      +--------------------------------------+-----------+------------+
-     | diffie-hellman-group14-sha1          | RFC4253   | SHOULD     |
+     | diffie-hellman-group14-sha1          | RFC4253   | MAY        |
      +--------------------------------------+-----------+------------+
      | diffie-hellman-group14-sha256        | RFC8268   | MUST       |
      +--------------------------------------+-----------+------------+
@@ -577,7 +577,7 @@
      +--------------------------------------+-----------+------------+
      | gss-nistp384-sha384-*                | RFC8732   | SHOULD     |
      +--------------------------------------+-----------+------------+
-     | gss-nistp521-sha512-*                | RFC8732   | MAY        |
+     | gss-nistp521-sha512-*                | RFC8732   | SHOULD     |
      +--------------------------------------+-----------+------------+
      | rsa1024-sha1                         | RFC4432   | MUST NOT   |
      +--------------------------------------+-----------+------------+
@@ -696,7 +696,7 @@
 
    [IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell
               (SSH) Protocol Parameters: Key Exchange Method Names",
-              July 2020, <http://www.iana.org/assignments/ssh-
+              December 2020, <http://www.iana.org/assignments/ssh-
               parameters/ssh-parameters.xhtml#ssh-parameters-16>.
 
    [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
@@ -725,9 +725,9 @@

-Baushke                    Expires 27 May 2021                 [Page 13]
+Baushke                   Expires 17 July 2021                 [Page 13]
 
-Internet-Draft KEX Method Updates/Recommendations for SSH  November 2020
+Internet-Draft KEX Method Updates/Recommendations for SSH   January 2021

    [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
@@ -750,6 +750,14 @@
               SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,
               <https://www.rfc-editor.org/info/rfc8732>.
 
+   [TRANS-COLL]
+              Bhargavan, K. and G. Leurent, "Transcript Collision
+              Attacks: Breaking Authentication in TLS, IKE, and SSH",
+              Network and Distributed System Security Symposium - NDSS
+              2016, Feb 2016, San Diego, United
+              States. 10.14722/ndss.2016.23418 . hal-01244855,
+              <https://hal.inria.fr/hal-01244855/document>.
+
 Author's Address
 
    Mark D. Baushke

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 15 Jan 2021 08:28:00 +0400

From: Loganaden Velvindron

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 14 Jan 2021 21:04:40 -0800

The straw poll is now closed.

    Loganaden Velvindron <[email-masked]> (user)

  Kex Algorithm                       Recommendation
====================================================================
 diffie-hellman-group1-sha1:         SHOULD NOT (11)
 diffie-hellman-group14-sha1:        MAY (20)
 diffie-hellman-group-exchange-sha1: SHOULD NOT (9), MAY (2)
 rsa1024-sha1:                       MUST NOT (9), SHOULD NOT (2)
 gss-gex-sha1-*:                     SHOULD NOT (11)
 gss-group1-sha1-*:                  SHOULD NOT (9), MAY (2)
====================================================================

I will shortly be uploading the updated document to the
datatracker.ietf.org.

	Be safe, stay healthy,
	-- Mark