Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

Tim,

I find the reply approach fairly unhelpful. Perhaps you could reply to
specific statements in my message, rather than directing them to me
personally. I made several statements in the previous message, and your
statement "Most people disagree with you" provides little insight into what
you take umbrage with.

Such thoughtful replies on the substance, rather than the person, also
helps make sure that concerns are addressed; for example, given that you
have not elaborated on the CT argument, it's difficult for others to make
sense of that reference. As I'm certain we both want to ensure a productive
discussion, chair hat or otherwise, understanding the substance of your
past arguments and current statements provides much more value than the
quick and unfortunately too brief replies.

On Mon, Nov 12, 2018 at 11:06 AM Tim Hollebeek <tim.hollebeek@digicert.com>
wrote:

> Most people disagree with you, including NIST.
>
>
>
> Another example:
>
>
>
> http://www.pqsignatures.org/index/hbs.html
>
>
>
> “While the security of other post-quantum cryptographic schemes like
> lattice-based ones is still object to further research, hash-based
> signatures are well understood.”
>
>
>
> Second, hash-based signatures have already been standardized by IETF,
> while stateless schemes have not.
>
>
>
> -Tim
>
>
>
>
>
> *From:* Ryan Sleevi <ryan-ietf@sleevi.com>
> *Sent:* Monday, November 12, 2018 7:47 AM
> *To:* Tim Hollebeek <tim.hollebeek@digicert.com>
> *Cc:* Russ Housley <housley@vigilsec.com>; SPASM <spasm@ietf.org>
> *Subject:* Re: [lamps] Proposed addition of hash-based signature
> algorithms for certificates to the LAMPS charter
>
>
>
>
>
>
>
> On Mon, Nov 12, 2018 at 9:35 AM Tim Hollebeek <tim.hollebeek@digicert.com>
> wrote:
>
> (chair hat off)
>
>
>
> Reconstituting a CT log server from a backup is similarly catastrophic.
>
>
>
> Could you elaborate on why you believe that’s relevant? I have some
> suspicions, but before I point out the flaws in an argument you may not be
> making, it seems useful to understand exactly what connection you see
> between that and a discussion of certificate signing algorithms.
>
>
>
> The risk you note is certainly something that should be carefully
> addressed in the draft, but I think throwing stateful signatures out of
> IETF entirely because of it is a bit of an overreaction.
>
>
>
> That’s fairly dismissive, even if couched in “a bit”. Do you disagree that
> the stateless signatures offer equivalent security and with better
> usability than stateful signatures - something that other WGs have been
> prioritizing or requiring of their work product for half a decade now? What
> makes this WG unique?
>
>
>
>
>
> -Tim
>
>
>
> *From:* Spasm <spasm-bounces@ietf.org> *On Behalf Of *Adam Langley
> *Sent:* Thursday, November 8, 2018 12:42 PM
> *To:* Russ Housley <housley@vigilsec.com>
> *Cc:* SPASM <spasm@ietf.org>
> *Subject:* Re: [lamps] Proposed addition of hash-based signature
> algorithms for certificates to the LAMPS charter
>
>
>
> On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <housley@vigilsec.com> wrote:
>
> The SECDISPATCH WG met on Tuesday afternoon, and they made this
> recommendation:
>
> >  draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this
> draft
>
> Three questions:
>
> 1) Do you support the addition of this work to the LAMPS charter?
>
>
>
> No:
>
>
>
> The signature schemes in the draft are stateful and sudden-death: the
> penalty for mishandling the state is huge. This contrasts with every
> signature scheme ever (I believe) deployed and thus with every current
> process. For example, reconstituting an HSM from smartcards would be a
> fatal error with such a scheme.
>
>
>
> These schemes hedge against a valid risk, but at the cost of introducing a
> much larger one.
>
>
>
> The contexts in which stateful & sudden-death signatures are plausible are
> so specific and controlled that standisation in X.509 would be immaterial
> to them—they are not multi-lateral enough that whether something has an RFC
> or not matters. On the other hand, standisation implicitly hints that the
> thing being standardised is somewhat reasonable. So, on balance, I don't
> think the integration of stateful schemes into formats and protocols is a
> suitable subject for the IETF.
>
>
>
>
>
> AGL
>
> --
>
> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
> <https://clicktime.symantec.com/a/1/dyI47pNUwzjnKlpg5udkPYVvjyqwzB1mpFy1Reomrlc=?d=k6708s9Yv76k4u3DteWeNyNOB5qXm722T3vthjyGAq-vZUunB52jcSXFBqPSaPV8clB2U6v9LdUA6qqUDEFXMYI2EYb10gQzgWPHgg5zy5YButabWcD3uM8cv3SS8WaF7oL89L6mk3K41RNvexdilfSE8we0zrFulaYBg2_vzWrKDFI5g5dee2LGJJlYgIZFkBjm-r89vLH_9UZes9qNh6nvM8fitYtAbTW2X5SpXcDwEupqziQfEdp0AUp_ZWRio7Zg7IELEKymOt_OAir1EM4YDzXS4k-Q4m7TgUOxSg1SkUi7eLnoMN0B8TxjhQu_6ALXBwIBi1vOPxj0tNIU-KMvm7z1yOvxSgM25di33PoRVxKwORl2mjWtpVF-7uUOAdyM5-ER_1F9I-IE9i-SHiLiLSfIMGOrOICyk_9pUEGrNDgrLfB_btIgsPekbVALCeAJo3KjSW2Lfa0z5wAuXFR1Kf4KfMUYxLAbsxnsdaif&u=https%3A%2F%2Fwww.imperialviolet.org>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> <https://clicktime.symantec.com/a/1/oOomiZEcGux8HmqHiFlNh-Bhr7iH6WnkP2UWmAx89wU=?d=k6708s9Yv76k4u3DteWeNyNOB5qXm722T3vthjyGAq-vZUunB52jcSXFBqPSaPV8clB2U6v9LdUA6qqUDEFXMYI2EYb10gQzgWPHgg5zy5YButabWcD3uM8cv3SS8WaF7oL89L6mk3K41RNvexdilfSE8we0zrFulaYBg2_vzWrKDFI5g5dee2LGJJlYgIZFkBjm-r89vLH_9UZes9qNh6nvM8fitYtAbTW2X5SpXcDwEupqziQfEdp0AUp_ZWRio7Zg7IELEKymOt_OAir1EM4YDzXS4k-Q4m7TgUOxSg1SkUi7eLnoMN0B8TxjhQu_6ALXBwIBi1vOPxj0tNIU-KMvm7z1yOvxSgM25di33PoRVxKwORl2mjWtpVF-7uUOAdyM5-ER_1F9I-IE9i-SHiLiLSfIMGOrOICyk_9pUEGrNDgrLfB_btIgsPekbVALCeAJo3KjSW2Lfa0z5wAuXFR1Kf4KfMUYxLAbsxnsdaif&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm>
>