Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 15 Sep 2017 16:41:38 -0400

Hi Mark,

On Fri, Sep 15, 2017 at 3:59 PM, Mark D. Baushke <[email-masked]> wrote:
> Kathleen Moriarty <[email-masked]> writes:
>
>> Mark,
>>
>> Thanks for your detailed response, I appreciate it.  Inline.
>
> Trimmed response, likewise inline.
>
>> On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke <[email-masked]> wrote:
>> > Salz, Rich <[email-masked]> writes:
>> >
>> Embedded equipment is a tough problem.
>
> Yes.
>
>> So for this, your worried about new purchases.
>
>> If it's already purchased, then we are talking an audit issue and
>> possibly not having funds to buy some million dollar piece of
>> equipment that happens to support less than 2048.
>
> Well, one hopes that with a million dollar piece of equipment, there is
> a support cotract and a way to update the software in that box.

One would think, but that's a real example and nothing could be done.
It's not uncommon either.

>
> I was more concerned with needing to sell software to manage thousands
> of very low price embedded devices and still be able to inter-operate
> between the management station and the devices.
>
> For example, a conformant implementation that MUST use 2048 bit keys,
> but needs to talk to a device only able to use 1024 bit keys has a
> problem. Likewise if the embedded devices only support
> diffie-hellman-group1-sha1 as they were two small and slow to manage
> with diffie-hellman-group14-sha1 when deployed as a read-only device.
>
> Does my management station get to talk to those old devices when MUST is
> present and exact conformance to the specification is mandated?

OK, thanks for providing that example, it's helpful and I see your
point better now.

>
>> Hmm, in the past, I've done thing to mitigate threats like isolating
>> such hosts when the threat warranted measures. I see your point, I'm
>> just trying to walk through real instances of issues to make sure we
>> are considering options well.
>
> Yes, and I really appreciate that we are getting this into the archive.
>
>> > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use the
>> > word "MUST" for the current 1024 bit value. So, in this case, just
>> > updating a SHOULD from a SHOULD seems reasonable to me. If it were a
>> > MUST, then I would probably advocate for SHOULD NOT as the step down.
>> >
>> > For example, I would have no objection to adding text which says that
>> > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less than
>> > 2048.
>> >
>> > fwiw: I also suspect that 2048 will not survive more than another couple
>> > of years and would not mind saying that "n SHOULD be 3072 or greater". I
>> > do not believe that view is accepted by everyone, so 2048 bits is what
>> > is in place for now.
>>
>> Hmm, than it would be good to make a note of this so those who are
>> replacing embedded equipment make the leap to a higher value than
>> 2048.  This can be in the non normative text.
>
> So, using words like 'desirable' rather than recommended or should?
> I guess that might be a way to approach it for this particular draft.
>
> I am less certain how to deal with the more general issue of algorithm
> deprecation in the security area. Guessing wrong can be very expensive.
>
>> There are a few published RFCs (I think some CMS RFCs) that took on a
>> notion of SHOULD - and SHOULD + as well as MUST + MUST -.  I see the
>> JOSE algorithms RFC also uses recommended + and recommended -.  The
>> minus shows that although this is kinda okay now, it really isn't
>> recommended and shouldn't be in new products.
>
> Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2
> and eventually removed it due to comments not liking it.

Hmm, I still see a table with the SHOULD, MUST, etc. listed out for
that draft?  I don't see the use of SHOULD +/-, MUST +/- and think it
might help in cases like this draft where you have mushy guidance.

I still think some warning that 2048 as the minimum recommendation may
change to 3072 or greater in a couple of years should be in a non
normative statement for developers to plan ahead as a minimum.

>
>> Do you think that approach could help to allow some flexibility, but
>> also show 1024 is on it's way out the door and 2048 will follow soon?
>
> I do not think that moving to 'a min value of 2048  SHOULD+ be used'
> will do much to help this particular case.

I would actually be recommending min value of SHOULD - as it will not
be recommended in a few years and is on a decline.  SHOULD + typically
indicates that it will be required as a MUST next, whereas in this
case, it will be deprecated in a few years.

Thanks,
Kathleen

>         -- Mark

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 15 Sep 2017 17:05:24 -0500

Speaking as someone whose primary connection to crypto is transporting
bytes whether the transport protocol can understand them or not ...

> >> 2048.  This can be in the non normative text.

I've had a comment with someone within the last 24 hours about whether
having text that says, roughly, if you're using less than 2048 bits and
can't go higher, you should probably expect that if this does become a
MUST, that might happen very suddenly ("attack + CERT advisory + vendors
who can go higher turning off anything lower than 2048 = you can only talk
to people who can't do 2048, and they're all vulnerable to a known exploit"
is a layperson's understanding, but I hope that's not too muddy to make
sense).

If that was a decent idea, and "you might want to be adding 3072 if you
can't do it now" is a good idea, this is turning into an advisory section,
and I like that, even if you don't have consensus for normative statements
now.

Is that going to make things better? (I'm assuming it won't make them
perfect)

Spencer

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 15 Sep 2017 21:03:12 -0400

Hi,

Sent from my iPhone

> On Sep 15, 2017, at 6:05 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Speaking as someone whose primary connection to crypto is transporting bytes whether the transport protocol can understand them or not ...
> 
>> On Fri, Sep 15, 2017 at 3:41 PM, Kathleen Moriarty <[email-masked]> wrote:
>> Hi Mark,
>> 
> I've had a comment with someone within the last 24 hours about whether having text that says, roughly, if you're using less than 2048 bits and can't go higher, you should probably expect that if this does become a MUST, that might happen very suddenly ("attack + CERT advisory + vendors who can go higher turning off anything lower than 2048 = you can only talk to people who can't do 2048, and they're all vulnerable to a known exploit" is a layperson's understanding, but I hope that's not too muddy to make sense).

I wish, but until it's phased out, some hosts will have no choice but to talk to hosts at 1024.  That's why I'm poking at this a bit, how much can we improve things deployed/being deployed.

> 
> If that was a decent idea, and "you might want to be adding 3072 if you can't do it now" is a good idea, this is turning into an advisory section, and I like that, even if you don't have consensus for normative statements now.
> 
> Is that going to make things better? (I'm assuming it won't make them perfect)

How about something along the lines of (please tweak, this is off the cuff):

It's recommended that you implement no less than 3072 bits in new deployments with the expectation of a minimum of 3072 bits within a few years.  It's understood that devices will be deployed for many years and implementing to the bare minimum recommended value is not advised.

Thank you & at the end of the day, I balloted yes but hope that we provide good guidance for implementors.

Best regards,
Kathleen

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 20 Sep 2017 09:27:59 -0700

Hi Kathleen,

Aside: Regarding SHOULD+ and SHOULD- in IETF drafts...

    The draft-ietf-curdle-ssh-kex-sha2-08.txt edition of that document
    defined and used SHOULD+ and SHOULD-, but many reviewers did not like
    them. So, I removed them from the draft-ietf-curdle-ssh-kex-sha2-09.txt
    edition.

Regarding the language in the current draft...

The primary author of draft-ietf-curdle-ssh-dh-group-exchange-05 is
Loganaden Velvindron.

I believe that he is the one who should make any changes to the
document to address comments provided in this review process.

I have no objections to suggesting that MIN value SHOULD be 2048
and that n SHOULD be 3072 or be capable of being set to 3072 by
an implementation as 2048 is not expected to need to be updated
within the next five years, perhaps abruptly. I actually think
that this would be a good idea.

Does this make sense to anyone else?

	Thanks,
	-- Mark

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Sep 2017 06:34:43 -0700

Chairs: do we expect Loganaden to make changes?

-Ekr

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 22 Sep 2017 17:37:10 +0400

I am working on the requested changes. I will upload the new document soon.

On Fri, Sep 22, 2017 at 5:34 PM, Eric Rescorla <[email-masked]> wrote:
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 22 Sep 2017 13:38:03 +0000

I am sure he will.
Yours,
Daniel

From: Curdle [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, September 22, 2017 9:35 AM
To: Mark D. Baushke <[email-masked]>
Cc: curdle <[email-masked]>; Salz, Rich <[email-masked]>; draft-ietf-curdle-ssh-dh-group-exchange <[email-masked]>; curdle <[email-masked]>; Daniel Migault <[email-masked]>; Loganaden Velvindron <[email-masked]>; Kathleen Moriarty <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>; The IESG <[email-masked]>
Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT)

-Ekr

On Wed, Sep 20, 2017 at 9:27 AM, Mark D. Baushke <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen,

        Thanks,
        -- Mark

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Sep 2017 06:51:53 -0700

Fantastic. I just hadn't heard from him yet and wanted to make sure we
agreed on who had the job

On Fri, Sep 22, 2017 at 6:38 AM, Daniel Migault <[email-masked]
> wrote:

> I am sure he will.
>
> Yours,
> Daniel
>
>
>
> *From:* Curdle [mailto:[email-masked]] *On Behalf Of *Eric
> Rescorla
> *Sent:* Friday, September 22, 2017 9:35 AM
> *To:* Mark D. Baushke <[email-masked]>
> *Cc:* curdle <[email-masked]>; Salz, Rich <[email-masked]>;
> draft-ietf-curdle-ssh-dh-group-exchange <draft-ietf-curdle-ssh-dh-
> [email-masked]>; curdle <[email-masked]>; Daniel Migault
> <[email-masked]>; Loganaden Velvindron <[email-masked]>;
> Kathleen Moriarty <[email-masked]>; Spencer Dawkins at
> IETF <[email-masked]>; The IESG <[email-masked]>
> *Subject:* Re: [Curdle] Kathleen Moriarty's Yes on
> draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT)
>
>
>

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 22 Sep 2017 18:20:10 +0400

> agreed on who had the job

Hello Eric,

It's my fault for not responding earlier. I admit that the IESG review
is quite complex for someone who is going through it the first time. I
was more comfortable with Mark responding as he has more experience
than me, dealing with the IESG.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 Sep 2017 10:30:07 -0400

> than me, dealing with the IESG.

Thank you.  I guess some of the nuances can be confusing, like a YES
ballot with a comment.  The last suggested update would be very
helpful so anyone reading it would know that they shouldn't just go
for the minimum as that could be phased out within a few years.

-- 

Best regards,
Kathleen

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 22 Sep 2017 21:14:06 +0400

> for the minimum as that could be phased out within a few years.

Yes, and it seems that it's hard to follow the point at which
consensus is reached. I have attempted to address your concern, and
most of the others in rev 06.

Changelog:
an->any;
typo from warren;
fix normative reference & ipr trust from mirja;
include section about logging in security considerations from Benoit
Claise and OPS DIR; include suggestions about 3072 bits as an option
for implementation should the need arise in the coming years from
K.Moriarty and S. Dawkins.

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 22 Sep 2017 21:23:05 +0400

> for the minimum as that could be phased out within a few years.

Interestingly, this message about 3072 bits DH Group was sent to the
OpenSSH mailing list recently:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-September/036217.html

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 Sep 2017 13:35:41 -0400

> https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-September/036217.html

Yes, interesting indeed, thanks for sharing.

-- 

Best regards,
Kathleen