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

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 13 Sep 2017 11:08:47 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-curdle-ssh-dh-group-exchange-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I do agree with Spencer, the text that is non-normative reads as if this is
fully deprecating any recommendation below 2048, but then the normative text
just says SHOULD.  Is there a reason this is not MUST?  I know deprecating
things takes a long time.

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 15 Sep 2017 15:01:40 +0400

> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/

Yes, it takes a long time, and also because of backward compatibility.
We felt that "SHOULD" was sufficient at the time.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 15 Sep 2017 09:04:33 -0500

So, Kathleen's ballot thread, but since she and I share this curiosity ...

> We felt that "SHOULD" was sufficient at the time.

That doesn't surprise me (speaking only for myself).

It might be helpful to add a sentence explaining that the SHOULD is for
backward compatibility.

That changes the incentives a bit - implementers have more incentive to
implement a SHOULD if it's not a MUST *yet*, but when the community stops
worrying about backward compatibility, it could be, and then other
implementations won't interop with yours.

And, for extra credit, that could happen suddenly, if someone posts a
clever attack on 1024-bit keys that requires minimal computing resources
and includes an implementation that anyone can pick up ... so everyone else
stops accepting shorter keys, like, today.

But do the right thing, of course.

Spencer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 15 Sep 2017 10:06:36 -0500

> On Sep 15, 2017, at 9:04 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> So, Kathleen's ballot thread, but since she and I share this curiosity …

Same here :-)

> It might be helpful to add a sentence explaining that the SHOULD is for backward compatibility.
> 
> That changes the incentives a bit - implementers have more incentive to implement a SHOULD if it's not a MUST *yet*, but when the community stops worrying about backward compatibility, it could be, and then other implementations won't interop with yours.
> 
> And, for extra credit, that could happen suddenly, if someone posts a clever attack on 1024-bit keys that requires minimal computing resources and includes an implementation that anyone can pick up ... so everyone else stops accepting shorter keys, like, today.
> 

I agree with Spencer’s comments, especially the one about adding text to explain the SHOULDs.

I also understand the need for a transition period. However, unconstrained SHOULDs leave things open ended. Was that the intent of the working group? Is there an expectation that these might be revised to MUSTs sometime in the future?

IIRC, Benoit mentioned the idea of logging or surfacing a warning if you receive less than 2048 bits. That seems like a good idea.

Thanks!

Ben.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 15 Sep 2017 11:11:56 -0400

Hello,

Sent from my iPhone

> On Sep 15, 2017, at 10:04 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
>> On Fri, Sep 15, 2017 at 6:01 AM, Loganaden Velvindron <[email-masked]> wrote:

Hmm, I'd like to push on this a bit more.  First, do you still feel it's sufficient?

Next, what's the explicit compatibility concern?  If your just waiting on a key rollover or something along those lines, it's fine for this RFC to draw a hard line.

Thanks,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Sep 2017 15:15:59 +0000

➢ Hmm, I'd like to push on this a bit more.  First, do you still feel it's sufficient? 

The WG was comfortable with a SHOULD for now.  MUST was further than most people wanted to go.

➢ Next, what's the explicit compatibility concern?  If your just waiting on a key rollover or something along those lines, it's fine for this RFC to draw a hard line.

I believe the concern is about upgrading the deployed base.

---

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

Sent from my iPhone

> On Sep 15, 2017, at 11:15 AM, Salz, Rich <[email-masked]> wrote:
> 

Ok, so why can't that just be done the next time the deployed base is ready?  Is there a reason why the deployed base needs to be compliant with this RFC?  Or will making 2048 a MUST help to drive the change?

Thank you,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Sep 2017 16:28:42 +0000

➢ Ok, so why can't that just be done the next time the deployed base is ready?  Is there a reason why the deployed base needs to be compliant with this RFC?  Or will making 2048 a MUST help to drive the change?

That’s an excellent question; I think Dennis and other authors should reply ☺

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 15 Sep 2017 11:25:25 -0700

Salz, Rich <[email-masked]> writes:

> ➢ Ok, so why can't that just be done the next time the deployed base
> > is ready? Is there a reason why the deployed base needs to be
> > compliant with this RFC? Or will making 2048 a MUST help to drive the
> > change?
> 

My biggest change for the core SSH protocol is that governmental
agencies are mandating compliance to the standards if SSH is to be used
in a product. By updating the standards from a SHOULD to a MUST without
consideration for a large installed base of embedded equipment, we may
find that many products are being excluded from being used when the
'standard' they define is bumped.

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.

I worry more about more of core SSH compliance changes.

For example, diffie-hellman-group1-sha1 which is in the original SSH
RFCs as a MUST implement is too weak. My draft moves it from a MUST
implement from the SSH core standards to a SHOULD NOT. I stopped short
of going to a MUST NOT as I believe there needs to be a transition
period for the implementations out there to become compliant. I say this
because I have observed some standards (NIAP an Common Criteria)
currently want exact complaince to the standand RFCs they list. For a
large embedded installed base, it will likely take a long time for those
boxes to be updated (if they even can be updated in all cases).

Is SHOULD NOT stronger than SHOULD? It may not be, but somehow it feels
stronger...

The above is my personal opinion and may not represent that of the
company with which I am affiliated.

	-- Mark

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 15 Sep 2017 14:58:19 -0400

Mark,

Thanks for your detailed response, I appreciate it.  Inline.

> 'standard' they define is bumped.

Embedded equipment is a tough problem.  So for this, your worried
about new purchases.  Sales should go way down with the SHOULD at this
point and I wouldn't let an organization I managed chose a product
that didn't support the minimum recommendation at this point, so it is
really an issue if there is no competitor and the only choice doesn't
meet the minimum SHOULD.  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.  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.

> do not believe that view is accepted by everyone, so 2048 bits is what

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.

> Is SHOULD NOT stronger than SHOULD? It may not be, but somehow it feels

It's technically not, but I see what you are saying.

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.

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?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 15 Sep 2017 12:59:15 -0700

> Thanks for your detailed response, I appreciate it.  Inline.

Trimmed response, likewise inline.

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

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?

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

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

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

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

	-- Mark

---

From: denis bider <[email-masked]>
Date: Sat, 16 Sep 2017 04:46:09 -0600

I think Mark has a more educated position on this than I do, but I can
respond to the following with a bit of practical information:

> Next, what's the explicit compatibility concern?  If your just waiting on
a key rollover
> or something along those lines, it's fine for this RFC to draw a hard
line.

One of the explicit compatibility concerns goes like this. More or less
directly taken from a real example:

- Organization X has a bunch of appliances (routers, etc) of model C.
- The appliances need to back up their log files.
- The appliances offer like two choices for backup, either plaintext FTP or
some old version of SSH+SFTP with only 1024-bit crypto, or only SHA-1, or
like that.
- The manufacturer no longer maintains the appliances. There are no updates
planned for SSH+SFTP on this hardware.
- Organization X wants to upgrade their SSH+SFTP server S on which they
receive the log files from the appliances.

Now the issue arises that a new RFC is out that says "MUST NOT support
1024-bit crypto" or "MUST NOT support SHA-1".

If it said "SHOULD NOT", then that's fine. Server S can come with 1024-bit
crypto and SHA-1 disabled by default, but users can enable if they want
compatibility with these old appliances.

But the spec says "MUST NOT". So now Server S, if it wants to be compliant,
cannot include 1024-bit crypto or SHA-1 at all. So now organization X
cannot update to a new version of server S because then they won't be able
to receive transfers from appliances that only support 1024-bit crypto or
SHA-1 or whatnot.

The organization is not throwing away the appliances also, because they
serve their purpose and are a big hardware investment. So as a result,
causal process goes like this:

idealist standards organization says "MUST NOT" support old stuff
=> new version of software cuts out support for old stuff
=> new version can't interoperate with old hardware
=> users don't upgrade to new version

Or alternately:

idealist standards organization says "MUST NOT" support old stuff
=> new version of software violates spec and supports it anyway
=> spec is toothless

Or alternately:

=> new version of software violates spec and supports "MUST NOT" algorithms
anyway
=> another type of user comes in and says "we can't use because you violate
spec"
=> two new versions of software must be released and maintained, one that
violates spec and one that doesn't

We must accept that hardware implementations exist which are set in stone.
"MUST NOT" for anything that was enabled by default, in new software, in
the last 10 years, is more or less a no-go.

With regard to key rollover, most users do not rollover keys in SSH. At all.

On Fri, Sep 15, 2017 at 10:28 AM, Salz, Rich <[email-masked]> wrote:

> ➢ Ok, so why can't that just be done the next time the deployed base is
> ready?  Is there a reason why the deployed base needs to be compliant with
> this RFC?  Or will making 2048 a MUST help to drive the change?
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>