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

[denis bider <[e-mail]>]

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.

On Fri, Nov 22, 2019 at 1:04 PM Simo Sorce <[e-mail]> wrote:

> On Thu, 2019-11-21 at 22:44 -0500, Watson Ladd wrote:
> > On Thu, Nov 21, 2019 at 9:44 PM Daniel Van Geest <
> [e-mail]>
> > 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.
>
> 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
>
>
>
>
>