Re: [Secdispatch] [EXTERNAL] Re: IETF117 - Call for topics

[Eric Rescorla <[e-mail]>]

On Sun, Jun 25, 2023 at 2:17 PM John Gray <John.Gray=
[e-mail]> wrote:

> This caught my eye:
>
> >> I think a BoF about hybrid signatures is appropriate as long as one of
> >> the topics is “do we really need them?”
>
> >So one of the problems with that is it'd be about a specific mechanism
> that may or may not
> >form part of a sensible response to the possibility of a CRQC but it'd
> omit consideration of the
> >systemic impacts of adopting such signatures, esp. in PKI and in other
> protocols that make use
> >of PKI. We'd also be passing up the very rare opportunity to consider
> significant changes to
> >PKI that might actually get deployed, which I think would be fairly
> unwise of us.
>
> I agree there is an opportunity to consider changes to PKI, but I don't
> think it is time boxed by the Quantum threat.   I think there is always an
> opportunity to consider significant changes to PKI.  I don't think it
> should prevent us from enhancing existing PKI infrastructure until such
> newer systems become feasible.
>
> It has been clear to many of us, (since at least 2017), that hybrid
> signatures were going to be needed:
>

 Hi John,

I do agree we need post-quantum certificates, but I'm less persuaded
that *hybrid* signatures are the way to go, especially for online
protocols like TLS or IPsec.

My argument here starts with the threat model: unlike confidentiality,
what matters for security is the state of the algorithm at the time of
signature verification rather than at the time of signature
generation. In fact, it doesn't matter much what signature algorithms
were initially used, but rather what the relying party will accept.

As a concrete example, suppose that Alice signs a document with
classical algorithm C and quantum-resistant algorithm Q. If both
algorithms are secure, then it doesn't matter which the RP accepts or
verifies. So, the RP can simply adopt a policy of verifying whatever
signatures are there from its accepted set.  However, if C is broken
then it matters what the RP does. Specifically, if the RP accepts
C-only signatures, then the Q signature doesn't help because the
attacker can generate a new document just signed by C, either de novo
or by stripping the Q signature. What is required for security is for
the RP to reject C.

There are, however, two reasons to sign with both C and Q:

1. If you don't know what the other side supports and you want
   the peer to able to verify it whatever its policies.
2. If you are worried that *either* C or Q might be broken
   in the future and you want the RP to be able to verify
   in either case (this is roughly the rationale for using
   both classical and PQ algorithms for key establishment).

However, neither of these rationales applies to interactive protocols
like TLS, IPsec, etc. because they already negotiate the signature
algorithm, so the RP can just tell the peer what signature algorithm
to use (and by extension, which credential to send). Moreover,
because there are peers which only support the existing non-PQ
algorithms and thus *neither* hybrid nor PQ-only signatures, you
still need to be able to generate non-PQ signatures and to have a
non-PQ credential, so it's equally (perhaps more) convenient to just
have two credentials (assuming certificates here).

- A classical key pair that chains up through classical signatures.
- A PQ key pair that chains up through PQ signatures


Finally, let's consider the case of non-interactive protocols,
where you don't necessarily know the state of the RP, so it's
plausible you would want to sign with both C and Q regularly.
However, the problem here is the same backward compatibility
issue that you have with the interactive protocols, namely that
there are some RPs which will only be able to verify C, so
this means that you have to generate at least one pure classical
signature, and if you want to add a PQ signature then you need
some way to have two signatures, at which point why not just
have the second one be pure PQ.

Can you explain why you think that hybrid is a better design in
these cases?

-Ekr




> 1)  We need to evolve our systems, I can't imagine telling customer x to
> throw away their PKI infrastructure to use this new thing to ensure they
> are protected from the quantum threat.   Do you think that is realistic?
>  Maybe if we knew what the new thing looked like now and had 25 years for
> people to transition to it.  So adding support for the NIST approved PQ
> signature algorithms (when available) seems like a mandatory requirement
> for future PKI systems, and is a natural way to enhance existing systems
> against the quantum threat.
> 2)  Given the uncertainty when a QRCQ will become available, and lack of
> mature implementations of quantum resistant algorithms, it seems prudent to
> add existing signature algorithms (RSA, EC) in combination with the newer,
> larger PQ algorithm.   Adding EC only adds about 128 extra bytes which is a
> small overhead and gives extra security and peace of mind in case problems
> are found in the new PQ algorithm.  This can help to further enhance
> existing PKI systems.
> 3) In the call for adoption, we did have a lot of support for the work and
> it looks like many organizations are planning to deploy hybrid signatures
> of some kind.   We have proven this works in all the existing PKI
> structures we have tested it with as part of our Hackathon which currently
> has at least 6 different vendor supplied implementations of composite
> "hybrid" signatures:  https://github.com/IETF-Hackathon/pqc-certificates
> We are simply trying to work out a common standard for what this looks
> like.  Isn't that the point of the working group (LAMPS in this case has a
> charter item 5.b.ii. for hybrid signatures).
>
> Cheers,
>
> John Gray
>
>
> -----Original Message-----
> From: Secdispatch <[e-mail]> On Behalf Of Stephen
> Farrell
> Sent: Friday, June 23, 2023 8:37 AM
> To: Yoav Nir <[e-mail]>
> Cc: Mike Ounsworth <Mike.Ounsworth=[e-mail]>; Michael
> Richardson <[e-mail]>; David Woodhouse <[e-mail]>;
> Rifaat Shekh-Yusef <[e-mail]>; secdispatch <
> [e-mail]>
> Subject: Re: [Secdispatch] [EXTERNAL] Re: IETF117 - Call for topics
>
>
> Hiya,
>
> On 23/06/2023 10:29, Yoav Nir wrote:
> >
> >
> >> On 22 Jun 2023, at 21:06, Stephen Farrell <[e-mail]>
> >> wrote:
> >> On 22/06/2023 19:01, Mike Ounsworth wrote:
> >>> I also support a BoF about hybrid signatures.
> >>
> >> FWIW: I would not support the above. The BoF I think we need would
> >> address evolving PKI in the face of a CRQC.
> >>
> >> Discussion of hybrid signatures would be a part of that, but just a
> >> part.
> >
> > That’s not going to happen. If everything’s in scope then the BoF will
> > discuss everything all at once, and take forever and not reach any
> > conclusions.
>
> Of course, an ocean-boiling BoF is always possible, but I don't think one
> on how to evolve PKI in the face of a possible CRQC is likely to be that.
>
> > I think a BoF about hybrid signatures is appropriate as long as one of
> > the topics is “do we really need them?”
>
> So one of the problems with that is it'd be about a specific mechanism
> that may or may not form part of a sensible response to the possibility of
> a CRQC but it'd omit consideration of the systemic impacts of adopting such
> signatures, esp. in PKI and in other protocols that make use of PKI. We'd
> also be passing up the very rare opportunity to consider significant
> changes to PKI that might actually get deployed, which I think would be
> fairly unwise of us.
>
> Cheers,
> S.
>
> >
> > Yoav
> >
> >
> >
> >
> 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.
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>