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

[Simo Sorce <[e-mail]>]

On Fri, 2019-11-22 at 20:38 -0600, denis bider wrote:
> 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.

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.

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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc