Re: [Cfrg] I-D Action: draft-mcgrew-hash-sigs-03.txt

Hi Watson,

      -----Original Message-----
      From: Watson Ladd [mailto:watsonbladd@gmail.com]
      Sent: Thursday, November 05, 2015 7:25 AM
      To: David McGrew (mcgrew)
      Cc: Zooko Wilcox-OHearn; cfrg@ietf.org; internet-drafts@ietf.org; i-d-announce@ietf.org
      Subject: Re: [Cfrg] I-D Action: draft-mcgrew-hash-sigs-03.txt

      On Wed, Nov 4, 2015 at 5:50 PM, David McGrew (mcgrew) <mcgrew@cisco.com<mailto:mcgrew@cisco.com>> wrote:
      > Hi Watson and Zooko,
      >
      >
      > -----Original Message-----
      > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Watson Ladd
      > Sent: Wednesday, November 04, 2015 6:48 AM
      > To: Zooko Wilcox-OHearn
      > Cc: cfrg@ietf.org<mailto:cfrg@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>; i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
      > Subject: Re: [Cfrg] I-D Action: draft-mcgrew-hash-sigs-03.txt
      >
      > On Tue, Nov 3, 2015 at 1:23 AM, Zooko Wilcox-OHearn
      > <zooko@leastauthority.com<mailto:zooko@leastauthority.com>> wrote:
      >> Dear folks:
      >>
      >> Is there a better way for me to register my objections to this scheme
      >> than my earlier post to CFRG about it?
      >
      > To be clear: This scheme will fail in very nasty, very obvious ways
      > anytime you have backups of your machine, or restart your VM, or crash
      > at just the wrong moment.
      >
      > Section 10.1 documents some of the concerns that you raise and
      > provides some guidance.  Probably stronger guidance is needed; if you
      > have suggestions, please let us know.
      >
      > Proposing it, and expecting it to be used widely, will inevitably lead
      > to these problems on a mass scale.
      >
      > Hash based signatures are well suited for some applications, such as the
      > long-term protection of firmware that is checked in embedded systems.   In
      > these cases postquantum security is essential, the verifier needs to
      > be compact, and signing is a relatively rare operation.

      How does the rarity of signing decrease the problems posed by backups?

It doesn't, as you already know, but rarity of signing makes state synchronization easier.

      If anything, embedding implementations into hardware or ROM is likely to lead to lots of backups of the private key, and any restore will cause problems. There are workarounds, but they have costs with reducing the number of possible signatures.
       Alternatives like SPHINCS are post quantum secure and do not have this extremely likely failure mode.

I agree that stateless signatures are also worth investigating.

      >
      > Is this really what we want to tell people to use?
      >
      > Like Winston Churchill said about democracy, they are the worst
      > postquantum secure digital signatures, except for all the others.
      >
      > For sure the issue of synchronization of state in hash based
      > signatures schemes is a major issue, and there might be scenarios where they will never
      > be appropriate, such as VM environments in which VMs are cloned.   It may be
      > the case that these types of signatures need to have a different interface
      > that would better ensure the security of implementations.   But in any case,
      > given their postquantum security and solid theoretical foundations,
      > they deserve to be studied more to see what their limits are.

      It's not about the security of an implementation, but a deployment.
      Back up your computer? You've revealed your secret key. Ensure HVM failures won't render your hardware unupdatable? You've revealed your secret key. Does Cisco really think that a single point of failure for updating firmware is acceptable?

Like many other vendors, Cisco is looking into postquantum security, including hash based signatures with stateful components.

      The CFRG is not a CRYPTO reviewer panel. Publishing this draft will lead to it being used in products.

This is total BS.  The IRTF chartered CFRG to be a “forum for discussing and analyzing general cryptographic aspects of security protocols, and to offer guidance on the use of emerging mechanisms and new uses of existing mechanisms”.

David

      >
      > David
      >
      >>
      >> Regards,
      >>
      >> Zooko
      >>
      >> _______________________________________________
      >> Cfrg mailing list
      >> Cfrg@irtf.org<mailto:Cfrg@irtf.org>
      >> https://www.irtf.org/mailman/listinfo/cfrg
      >
      >
      >
      > --
      > "Man is born free, but everywhere he is in chains".
      > --Rousseau.
      >
      > _______________________________________________
      > Cfrg mailing list
      > Cfrg@irtf.org<mailto:Cfrg@irtf.org>
      > https://www.irtf.org/mailman/listinfo/cfrg
      >

      --
      "Man is born free, but everywhere he is in chains".
      --Rousseau.