Subject: Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 2 Feb 2021 15:13:05 -0800

Hi all,

Daniel Migault <[email-masked]> writes:

> Thanks Mark for the follow-up as well as for pushing the updated
> version considering the feed backs received during the WGLC. We am
> planning to proceed to a request for publication in the next coming
> days. So, if one of your concerns has not been address please let the
> mailing list know.
> 
> Yours,
> Rich and Daniel
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

...elided...

As I write this, I have received no additional comments in the last
seventeen days.

If I missed any, please let me know.

	Be safe, stay healthy,
	-- Mark

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Feb 2021 01:12:46 +0000

I have not seen any comments either. I believe we can safely move this forward.

Yours,
Daniel
________________________________
From: Curdle <[email-masked]> on behalf of Mark D. Baushke <mdb=[email-masked]>
Sent: Tuesday, February 2, 2021 6:13 PM
To: Daniel Migault <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2

Hi all,

...elided...

        Be safe, stay healthy,
        -- Mark

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Feb 2021 17:22:47 -0800

> I have not seen any comments either. I believe we can safely move this forward.

I agree; it's in my queue.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Feb 2021 18:21:55 -0800

Hi Mark,

> As I write this, I have received no additional comments in the last

Thanks for following up.

I went through the -13 -- the changes since the -12 make sense to me.
That said, I think we will want a -14 before issuing IETF LC, mostly
just to tidy up some editorial stuff that would keep the genart reviewer
busy and make it harder to read for other reviewers -- I'll send an
edited XML file with my take on those fixes to help get them out
quickly.

There were a few things that I wanted to mention separately, though:

The shepherd writeup was last modified in 2018 and should probably get
an update to reflect the recent WG review and input, before the draft
gets to IESG Evaluation.

The table in the IANA considerations disagrees about the implementation
recommendation for gss-group16-sha512-* with the table in Section 3.3.2
(SHOULD vs MAY) -- your previous messages to the list suggest that MAY
is intended, and I mostly assume that the SHOULD crept in during the
rewrite for the -12, when making the non-GSS group16 method 'SHOULD'.

There's also a line in Section 3.2.3 (ecdh-*, ecmqv-sha2, gss-nistp*)
that says "this set of methods MAY be implemented" when the tables and
other prose say "SHOULD" about ecdh-sh2-nistp*.  The "MAY" would line up
with ecmqv-sha2, that otherwise is not mentioned in this section other
than the table, but ecmqv-sha2 is not really a "set" of methods.
I'm not sure what the intent was for that text (maybe it's just stale?);
my current proposal is to just remove it, but that doesn't do anything
to address the lack of prose about ecmqv-sha2 in this section.  (It might
also have been referring to the general set other than the specific named
curves.)

I also went through the references, with these comments:

Section 8.1

RFC 8031 is just about curve25519/curve448 for IKEv2, and I don't see a
need for them to be normative references for us -- 8731 is (AFAIK) the
relevant SSH reference.

Section 8.2

We may get some people asking for RFCs 4419, 4432, 4462, 5656, 8731, and
8732 to be moved to normative references.  In my opinion it's debatable,
so I'm happy to leave them as-is for now -- they're all standards track,
so there would not be a process issue if we had to move them after the
IETF LC.

I'll include the editorial notes below for visibility and in case they
help Mark decipher my proposed changes, but I don't expect anything
noteworthy that's not (also) mentioned above.

Thanks,

Ben

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Section 1.1

> At present, the attacks against SHA-1 are collision attacks that
> usually rely on human help rather than a pre-image attack. 

nit: I think a comma before "rather than" would help.

> 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, [...]

nit: it looks like RFC 4253 writes these as "I_C" and "I_S" (though
maybe native subscripts are better yet).

Section 1.2.1

> For ECC, it is recommended to select one with approximately 128 bits
> of security strength.

nit: s/one/a curve/

Section 1.2.2

> For FFC, a modulus 2048 bits (112 bits of security strength).

editorial: it's not clear what this not-quite-sentence is trying to say.
If we wanted parallelism with §1.2.1, it would be "it is recommended to
use a modulus with 2048 bits (112 bits of security strength)", but since
after the table we go and list an explicit minimum of 2048-bit MODP
group14 it's not entirely clear that that's the intent.

Section 1.2.3

> The only IFC algorithm for key exchange is the RSA algorithm via
> [RFC4432]. 

nit: s/via/specified in/

Section 3.1

> diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are
> currently mandatory to implement (MTI). [...]

I'd suggest avoiding "currently" (due to the ambiguity of whether it
applies to the state of affairs before or after the publication of this
document, when the reader will be reading it after publication) and
favoring "prior to the changes made by this document, [...] were
mandatory to implement".

> SHA-1 has security concerns provided in [RFC6194].

nit: s/provided/documented/ or something like that

Section 3.2.1

> These key exchange methods are described in [RFC8731] and [RFC8732]
> and is similar to the IKEv2 Key Agreement described in [RFC8031].

nit: singular/plural mismatch "are described"/"is similar".

Section 3.2.2

> This Key Exchange Method is described in [RFC8731] and is similar
> [...]

nit: since we added gss-curve448-sha512-* to this section we have to go
to "methods are described" and "are similar" just as in §3.2.1.

> This method MAY be implemented.

nit: may also need to reword this to just cover curve448-sha512.

Section 3.2.3

> At present, there are three named curves in this name-space which
> SHOULD be supported. They appear in [RFC5656] in section 10.1 Required
> Curves all of the NISTP curves named are mandatory to implement if any
> of this RFC is implemented.

nit: "at present" may not age as well as "at the time of this writing".

nit: I think the intent was maybe to format this as """section 10.1
("Required Curves").  All of the NISTP curves named therein are
mandatory to implement if any of that RFC is implemented".

> This set of methods MAY be implemented.

Is this sentence stale text?  AFAICT it refers to the same
ecdh-sha2-nistp* that are SHOULD elsewhere in the section.
But if it referred to ecmqv-sha2 then the "MAY" would make more sense.

> The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms
> used by ecdh-sha2-* names. The table provides guidance for
> implementation.

This would be a good place to put a reference to RFC 8732.

Section 3.3.1

> [RFC8270] mandates implementations avoid any MODP group

nit: "mandates that"

Section 3.3.2

> diffie-hellman-group14-sha256 method MUST be implemented.

nit: "The".

Section 3.4

> Uses an RSA 2048-bit modulus with a SHA2-256 hash.

nit: "It uses"

Section 6

> It is desirable to deprecate or remove key exchange method name that
> are considered weak. A key exchange method may be weak because too few
> bits are used, or the hashing algorithm is considered too weak.

nit: this is not an exhaustive list, so we could tweak the wording.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 9 Feb 2021 21:33:10 -0500

On Tue, Feb 9, 2021 at 9:22 PM Benjamin Kaduk <[email-masked]> wrote:

> <mglt>I think this is on me.</mglt>

-- 
Daniel Migault
Ericsson

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 9 Feb 2021 23:46:30 -0800

...elided...

...elided...
> rewrite for the -12, when making the non-GSS group16 method 'SHOULD'.

Yes. MAY is what I intended. The SHOULD is probably from doing a quick
replace for diffie-hellman-group16-sha512 which is marked SHOULD. I think
sticking with MAY is okay here, so I will update it in the -14 edition.

> also have been referring to the general set other than the specific named

It was indeed stale text and will be removed in -14.

> need for them to be normative references for us -- 8731 is (AFAIK) the

Agreed. I will move 8031 to informative and 8731 to normative.

> so there would not be a process issue if we had to move them after the

I seem to recall getting feedback from someone that they should be
informative.

> noteworthy that's not (also) mentioned above.

Thanks.

> Ben

Will be fixed in -14.

> maybe native subscripts are better yet).

Will be fixed in -14.

> > For ECC, it is recommended to select one with approximately 128 bits

Will be fixed in -14.

> group14 it's not entirely clear that that's the intent.

The -14 draft will use

            For FFC, it is recommended to use a modulus with 2048 bits
            (112 bits of security strength).
 
> > The only IFC algorithm for key exchange is the RSA algorithm via

Will be fixed in -14.

> favoring "prior to the changes made by this document, [...] were

Will be fixed in -14 to use "Prior to the changes made by this document,"
at the start of the paragraph.
 
> nit: s/provided/documented/ or something like that

Will be fixed in -14.

> nit: singular/plural mismatch "are described"/"is similar".

Will be fixed in -14.

> to "methods are described" and "are similar" just as in §3.2.1.

Ack.

> nit: may also need to reword this to just cover curve448-sha512.

Ack.

> nit: "at present" may not age as well as "at the time of this writing".

Will be fixed in -14.

> mandatory to implement if any of that RFC is implemented".

Will be fixed in -14.

> But if it referred to ecmqv-sha2 then the "MAY" would make more sense.

The intent was ecmqv-sha2 would be MAY. Also, any OID-based curved MAY
be implemented. This section may need better editing to get the point
across.

> This would be a good place to put a reference to RFC 8732.

Agreed. Will be fixed in -14.

> > [RFC8270] mandates implementations avoid any MODP group

Will be fixed in -14.

> > diffie-hellman-group14-sha256 method MUST be implemented.

Will be fixed in -14.

> > Uses an RSA 2048-bit modulus with a SHA2-256 hash.

Will be fixed in -14.

> nit: this is not an exhaustive list, so we could tweak the wording.

Good point. I guess your suggestion of ", or for other reasons" like

        It is desirable to deprecate or remove key exchange method name
        that are considered weak. A key exchange method may be weak
        because too few bits are used, or the hashing algorithm is
        considered too weak, or for other reasons.

at the end of the paragraph is one way to address this.

Other suggestions from the list greatfully considered.

	Be safe, stay healthy,
	-- Mark