Subject: Re: [Curdle] call for adoption for draft-mu-curdle-ssh-xmss-00

From: Daniel Van Geest <[email-masked]>
Date: Fri, 22 Nov 2019 02:44:50 +0000

NIST will issue a special publication on stateful hash-based signatures before the rest of the PQ process completes.  Based on today’s date I’d hazard a guess that the publication will be next year.

XMSS/HSS is better suited for roots of trust and code signing (and possibly a few other limited cases, the NIST publication may give guidance here) where the environment where the signature is generated is tightly controlled.  I’d possibly support its use for limited end-entity certificates (the only semi-reasonable one I can think of is an EE cert with a private key in an HSM which is used to sign a TLS delegated credential of a different PQ or classical algorithm).

The general SSH use case does not fit any tightly-controlled scenario like above, so I oppose adoption of this draft.

Daniel

On 2019-11-21, 4:39 PM, "Curdle on behalf of Salz, Rich" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Speaking as an individual, I am opposed to adoption of this draft.

The IETF has pretty much decided to wait until the NIST post-quantum crypto process is finished.

Ø  SSH is rife with short, ad-hoc sessions in practical usage; as well as long sessions that can last many days.

Yes, and  for this reason, and because NIST explicit said that this will be part of the PQ process, adoption is premature. The NIST link mentioned (https://csrc.nist.gov/Projects/Stateful-Hash-Based-Signatures) explicitly talks about the problems and concerns of managing the state.

                /r$

---

From: Watson Ladd <[email-masked]>
Date: Thu, 21 Nov 2019 22:44:15 -0500

On Thu, Nov 21, 2019 at 9:44 PM Daniel Van Geest <[email-masked]>
wrote:

> NIST will issue a special publication on stateful hash-based signatures
> before the rest of the PQ process completes.  Based on today’s date I’d
> hazard a guess that the publication will be next year.
>
>
>
> XMSS/HSS is better suited for roots of trust and code signing (and
> possibly a few other limited cases, the NIST publication may give guidance
> here) where the environment where the signature is generated is tightly
> controlled.  I’d possibly support its use for limited end-entity
> certificates (the only semi-reasonable one I can think of is an EE cert
> with a private key in an HSM which is used to sign a TLS delegated
> credential of a different PQ or classical algorithm).
>
>
>
> The general SSH use case does not fit any tightly-controlled scenario like
> above, so I oppose adoption of this draft.
>

Any protocol where ordinary sysadmin tasks like restoring from backup or
running salt/Ansible/system de jour can cause a complete and total break of
security is unsuitable for a lot of servers. when used in SSH. Furthermore
PQ signatures aren't needed yet: you cannot retroactively attack
authorization they way you can encryption. I also oppose adoption.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 22 Nov 2019 14:03:57 -0500

> authorization they way you can encryption. I also oppose adoption.

I am also very concerned about allowing such a fragile construct for
SSH specifically.

Among all the issues mentioned above I want to add that in practice ssh
keys are used concurrently by multiple binaries in modern software
distributions.

For example OpenSSH my be used by an interactive user at the same time
as another automated process uses libssh. If these processes use the
same keys without the coordination of a tightly controlled key
management solution (like an HSM, or a special daemon, or some form of
mandatory file locking and IPC) we will see an immediate disaster.

Moreover, private keys are commonly copied between different systems by
users, that behavior is perfectly fine and common nowadays but would be
catastrophic with this mechanism.

My 2c.
simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: denis bider <[email-masked]>
Date: Fri, 22 Nov 2019 20:38:56 -0600

Those are all valid concerns, however the XMSS key could conceivably be
located on a smart card which contains the key and solves all these
concerns.

An RFC could spell out in all caps that use on a dedicated device is the
only usage case recommended.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Nov 2019 13:25:18 +0100

> only usage case recommended.

That's very fragile still, as the client has no way of knowing if the 
signature
was made by a HSM or not.

The biggest problem now for PQ is encryption that can be broken after big
quantum computers become available (either directly or because the key 
exchange
is not quantum-secure). Making quantum-safe authentication methods
does not help with that.

So I am opposed to adoption of it.

We can reconsider after NIST publishes its findings, but even then it looks
way too fragile for use in SSH.

>>>  ...
>> guidance
>>>> credential of a different PQ or classical algorithm). ...
>> like
>>>> ...
>>> running salt/Ansible/system de jour can cause a complete and 
>>> total break ...
>> of

-- 
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: Simo Sorce <[email-masked]>
Date: Mon, 25 Nov 2019 08:21:17 -0500

> only usage case recommended.

If the RFC said something about a device that MUST be used, it would be
better for sure, but there is no such device today, so we'd have to
push back on the RFC for lack of implementations?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc