Re: [CFRG] NSA vs. hybrid

[Natanael <[e-mail]>]

Den fre 12 nov. 2021 10:29D. J. Bernstein <[e-mail]> skrev:

> This looks to me like something that should be discussed in CFRG rather
> than LAMPS:
>
>
> https://datatracker.ietf.org/meeting/112/materials/slides-112-lamps-hybrid-non-composite-multi-certificate-00
>
> https://mailarchive.ietf.org/arch/msg/spasm/McksDhejGgJJ6xG617FEWLbBq0k/
>
> This is one part of a big push by NSA across multiple non-CFRG venues to
> convince everyone to
>
>    * deploy small lattice systems---which _hopefully_ protects against
>      quantum computers---and
>
>    * _turn off ECC_---this is the scary part, since there's a serious
>      risk that the small lattice systems are easier to break than ECC.
>
> I would like to see CFRG instead advising integration of ECC into all
> post-quantum deployments for the foreseeable future. There's no reason
> that this advice has to wait for NISTPQC standards.
>
> Specific comments follow.
>
> [...]

  [ under "CONS" of "composite" certs ]
> > Can require reworking of certificate validation
>
> Yikes---sounds scary given how tricky certificate validation is. But
> wait a minute. Isn't certificate validation simply calling signature
> verification as a black box? What has to be reworked here?
>

In theory it should be simple, in practice there's constant mistakes made
in validating certificate chains and certificate properties. In theory this
should be as simple as requiring dual and identical certificate chains with
no difference but the asymmetric primitives, requiring both to be valid at
once. In practice, I expect this to get messed up in a million different
ways.

With that said, I do personally favor adding support for "multi-signature
certs", of which composite certs with non PQ and PQ algorithms together is
one variant. Fixing this once and making sure it stays fixed feels to me
like the better option (in my layman's opinion).

  [ under "CONS" of "composite" certs ]
> > Maintenance concerns surrounding deprecated algorithms
>
> Why is this supposed to be more of an issue for "composite" certs than
> for "non-composite" certs?
>

My best guess is that with non composite you can easily ignore the cert
with non PQ algorithms (just don't supply it to the validator). However a
validator with support for composite certs should equally easily be able to
ignore non PQ chains.

  [ under "PROS" of "non-composite" certs ]
> > Computational processes remain unchanged (but perhaps multiple
> > iterations)
>
> This sounds weird, given that the whole point is to be adding new
> post-quantum primitives into the picture. Perhaps I'm missing some
> restricted definition of "computational process".
>

This is essentially a variant of the argument above, you run the validator
twice on different certs with only the primitive being different. The
validator needs additional changes to put both chains in the same cert.

  [ under "PROS" of "non-composite" certs ]
> > Ease of use for backward compatibility
>
> How is a P certificate plus a Q certificate easier to use than a P
> certificate plus a P+Q certificate? If this is supposed to be an
> objection to the cost of the extra 64 bytes then there also has to be an
> analysis of how much space is lost by the "non-composite" approach.
>

Similar to above, some older strict validators might reject composite certs
with an additional PQ chain even if the non PQ chain is valid. In this case
you may need to identify the user agent and serve only a non PQ cert.

However, I don't see what kind of software would have issues with
validating the non PQ part in composite certs but which would also happily
accept double certificates and validate just the non PQ one and ignore that
the other fails to validate (due to incompatibility), so this claim is odd.
Any software updated to support two certs can also update the validator
code.

The ability to serve and receive and correctly process double certs will in
itself essentially be a new standard.