Re: [CFRG] NSA vs. hybrid

> Natanael <natanael.l@gmail.com> Mon, 06 December 2021 17:09 UTC
> This is straying away from the main topic, but there is "quantum annoyance"
> as a step in between quantum resistant or quantum weak.

> In other words, systems where every session has to be broken individually
> even if you have a quantum computer, rather than just breaking one key once
> and then reading all sessions.

I haven't seen the term "quantum annoyance" before. I like it.

I think we have a bit of a "bike shedding" problem here that discussions like this one seem to inevitably gravitate back to TLS-like protocols; which IMO is the easier of the two problem spaces with "offline" or "asynchronous" protocols being a much harder problem to design and deploy PQ migrations for.
For example the following things don't have "sessions" where you can apply the concept of "quantum annoyance":
* S/MIME emails where you look up the recipient's encryption cert, and sign the message with your signing cert
* Code-signing infrastructures
* Documents signed by an eIDAS digital signature infrastructure

These are cases where the signing / encryption is done and the object sent into the ether to be verified / decrypted by some unknown client potentially years later. The PQ migrations concerns here are both security (longer data shelf-life means higher importance that algorithm(s) chosen at signing / encryption time don't turn out to be flawed hint hint hybrid), as well as interop (we really can't proceed pre-standards because of the multi-vendor nature of most of these environments, not to mention that the "unknown client" factor makes graceful migration mechanisms much more difficult to design).
It's fine that we want to solve PQ migration for TLS / IKE first, but let's not forget that we have this (IMO far more difficult) problem waiting for us around the corner.

---
Mike Ounsworth
Software Security Architect, Entrust

-----Original Message-----
From: CFRG <cfrg-bounces@irtf.org> On Behalf Of cfrg-request@irtf.org
Sent: December 6, 2021 11:43 AM
To: cfrg@irtf.org
Subject: [EXTERNAL] CFRG Digest, Vol 200, Issue 12

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Send CFRG mailing list submissions to
        cfrg@irtf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/cfrg__;!!FJ-Y8qCqXTj2!IH4lkvnSGWEpPmfUM7KgYGIRp3Qnzdib0uYXyNaP5j2NsST6Oghk2ZmcBVopdE1pe_tX$
or, via email, send a message with subject or body 'help' to
        cfrg-request@irtf.org

You can reach the person managing the list at
        cfrg-owner@irtf.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of CFRG digest..."

Today's Topics:

   1. Re: NSA vs. hybrid (Dan Brown)
   2. Re: NSA vs. hybrid (Natanael)
   3. Re: NSA vs. hybrid (Blumenthal, Uri - 0553 - MITLL)

----------------------------------------------------------------------

Message: 1
Date: Mon, 6 Dec 2021 15:19:27 +0000
From: Dan Brown <danibrown@blackberry.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, Mike Ounsworth
        <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, "cfrg@irtf.org"
        <cfrg@irtf.org>
Subject: Re: [CFRG] NSA vs. hybrid
Message-ID: <8223d944172648d38426533b0da11325@blackberry.com>
Content-Type: text/plain; charset="utf-8"

> -----Original Message-----
> From: Blumenthal, Uri - 0553 - MITLL
> Sent: Saturday, December 4, 2021 8:45 PM ...
> My point is: we "should NOT have layered..." then, and we did not - as
> evidenced by pretty much all of the current IETF and proprietary (that
> I'm aware of) protocols.
> ...
> People who designed IPsec and TLS (presumably as smart and educated as
> we are) understood the concept of combining different algorithms as
> well as we do (it's hard not to, given its age).
> ...
> The common sense prevailed back then, and IMHO it would be better if
> it prevails now.

Not offering hybrid, say NTRU & ECC, in the past put us in this pickle now of the quantum computer attack risk.
Especially, all the forward secrecy obtained in the past from (EC)DHE is now in jeopardy (even for bug-free implementations).
Arguably, it was a smaller bug than others (using http not https, and non-forward-secure key exchange (RSA)).
Certainly, there are applications where the gains from hybrid are outweighed by the cost, but also applications where hybrid is worthwhile.
Hybrid ought to be option, or IETF WGs should use a cost-benefit analysis per application, the CFRG could help there.
(Generally, let's learn from our mistakes. Besides, aren't some users naturally inclined to expect the Internet to maximally secure their data? ;)

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6441 bytes
Desc: not available
URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/cfrg/attachments/20211206/e1994010/attachment.p7s__;!!FJ-Y8qCqXTj2!IH4lkvnSGWEpPmfUM7KgYGIRp3Qnzdib0uYXyNaP5j2NsST6Oghk2ZmcBVopdIqIQ03t$ >

------------------------------

Message: 2
Date: Mon, 6 Dec 2021 18:09:04 +0100
From: Natanael <natanael.l@gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IRTF CFRG
        <cfrg@irtf.org>
Subject: Re: [CFRG] NSA vs. hybrid
Message-ID:
        <CAAt2M180ADofCVAw9DZ_86aNnzUU80rcckCQ=tGZ+upK0mPvhg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Den m?n 6 dec. 2021 15:21Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
skrev:

> > The other point to consider is that the WebPKI only needs signatures
> > and
> there are other,
>
> > simpler ways to achieve PQC hardening.
>
>
>
> I?m not sure I follow.
>
> In my understanding, PQ hardening (especially for signatures) requires
> using PQ algorithms ? what other ways are there?
>
>
>
> > We could heavily modify Certificate Transparency for instance.
>
>
>
> How would that help??
>

This is straying away from the main topic, but there is "quantum annoyance"
as a step in between quantum resistant or quantum weak.

In other words, systems where every session has to be broken individually even if you have a quantum computer, rather than just breaking one key once and then reading all sessions.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/cfrg/attachments/20211206/cd5330e0/attachment.htm__;!!FJ-Y8qCqXTj2!IH4lkvnSGWEpPmfUM7KgYGIRp3Qnzdib0uYXyNaP5j2NsST6Oghk2ZmcBVopdEeLeeWL$ >

------------------------------

Message: 3
Date: Mon, 6 Dec 2021 17:42:18 +0000
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Natanael <natanael.l@gmail.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IRTF CFRG
        <cfrg@irtf.org>
Subject: Re: [CFRG] NSA vs. hybrid
Message-ID: <21AB33DA-1D7E-4FDC-B417-A20BFC670C37@ll.mit.edu>
Content-Type: text/plain; charset="utf-8"

>>> The other point to consider is that the WebPKI only needs signatures
>>> and there are other, simpler ways to achieve PQC hardening.
>>
>> In my understanding, PQ hardening (especially for signatures)
>> requires using PQ algorithms ? what other ways are there?
>>
>>> We could heavily modify Certificate Transparency for instance.
>>?
>> How would that help??
>
> This is straying away from the main topic, but there is "quantum annoyance"
> as a step in between quantum resistant or quantum weak.?

Ah, "quantum annoyance". I did not think it's applicable to signatures.

> In other words, systems where every session has to be broken
> individually even if you have a quantum computer, rather than just
> breaking one key once and then reading all sessions.?

Yes. But as I said, while I have my personal opinion about this defense mechanism, it may work for key exchange, but IMHO not for signatures, unless in some point up the chain a "true" PQ signature is used - and even then, people with sensitive information to protect and worry about, cannot rely on this kind of "annoyance" defense.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/cfrg/attachments/20211206/1bb177e3/attachment.p7s__;!!FJ-Y8qCqXTj2!IH4lkvnSGWEpPmfUM7KgYGIRp3Qnzdib0uYXyNaP5j2NsST6Oghk2ZmcBVopdJWpIAxF$ >

------------------------------

Subject: Digest Footer

_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/cfrg__;!!FJ-Y8qCqXTj2!IH4lkvnSGWEpPmfUM7KgYGIRp3Qnzdib0uYXyNaP5j2NsST6Oghk2ZmcBVopdE1pe_tX$

------------------------------

End of CFRG Digest, Vol 200, Issue 12
*************************************
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.