Re: [lamps] [EXT] Re: [EXTERNAL] Re: draft-ounsworth-pq-composite-sigs-11

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Not going too deep into this conversation (yet), at this point I agree with Stephen. I'm not looking forward to these proposed changes.

TNX
-- 
V/R, 
Uri 




On 2/9/24, 10:42, "Spasm on behalf of Stephen Farrell" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:




Hiya,


On 09/02/2024 10:45, Kousidis, Stavros wrote:
> Hi Stephen,
> 
> I’ll try to explain again the motivation of the BSI for recommending
> hybrid signatures especially in the context of PKIs which I did
> already in short in my answer to Kris, see
> https://mailarchive.ietf.org/arch/msg/spasm/LdjVSB4asaSsWteEnUVzCIR-_u4/ <https://mailarchive.ietf.org/arch/msg/spasm/LdjVSB4asaSsWteEnUVzCIR-_u4/>.
>
> 
> 
> 1) The BSI recommends „a solution that is at least as secure as
> what we have now“ with RSA or ECC (sentence borrowed from Scott’s
> text:
> https://mailarchive.ietf.org/arch/msg/spasm/a16OpwGzWRKbwDstTsNxaT0lx1A/ <https://mailarchive.ietf.org/arch/msg/spasm/a16OpwGzWRKbwDstTsNxaT0lx1A/>).


Sounds like a reasonable goal.


> We recommend a simple 


Generally, claims as to simplicity aren't useful for IETF
protocols as it almost never turns out that way:-)


> and secure hybrid signature construction by
> saying to concatenate two, sign independently and having an
> AND-verifier. This recommendation will be published soon in our 2024
> version of the BSI technical guideline on crypto TR-02102-1
> (https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html>).
> We are in the final steps of putting that online.
> 
> 
> 2) We want a simple solution, concepts like multiple
> certificates and/or periodic local countersigning add complexity to
> an already inherently complex PKI. The normal subscriber is sometimes
> already overburdened with managing even one certificate. With PQC a
> subscriber will have already two, one for signing and one for
> encryption. Now you are asking to give him multiple certs. We decided
> against this in our infrastructure.


Wait. For a real email system, won't senders have to have
multiple signing certs anyway, in order for recipients who've
not got PQ algs at all to verify something?


What MUA has considered these issues for email? Given BSI did
that analysis is there a sketch somewhere of the kinds of
changes that MUAs will need? E.g. what's to be done if a
cleartext signed email is to be sent to a set of recipients
some of whom do have pq algs, and some of whom don't (or
where the sender can't tell)?


> 3) A PKI (such that the one for the German administration) has
> very long migration periods that are beyond 10 years. Every little
> change in cryptography is subject to long development, testing and
> deployment cycles. 


That's a bit of a circular argument: we want to radically
change the PKI; changing the PKI takes 10 years, therefore
we must start now. The "start now" part depends on it really
being necessary to make radical changes to the PKI. (And yes,
the change you call "simple," I call "radical":-)


I don't disagree that if radical changes to PKI are needed,
then those'll take a long time to get deployed. OTOH, if we
propose the wrong radical changes, then getting a deployed
PKI that meets the real needs will probably take even more
time and involve a pile of essentially wasted effort.


> We don’t make use of cut-off date changes here as
> we don’t touch the PKI prior to being absolutel sure that we can
> uphold business continuity. It’s hard for me to imagine that the BSI
> is the only institution that is maximally careful when it comes to
> PKIs with #subscribers in the magnitude >= 10^6.


I don't doubt anyone's desire to keep things working.


> 4) Given 3) it is easy to conclude that even if we start
> migrating now we will have a quantum-safe PKI at the earliest by 2035
> (if not 2040). So yes, these concepts (like hybrid signatures) are
> needed now.


Maybe this gets to the heart of the issue: I don't think
new features for PKI are first order goals here unless those
are demonstrated necessary for real applications that need
to use security mechanisms that benefit from a PKI. The goal
rather is to end up with robust applications and a PKI
that works for those, so the question to ask is whether or
not such applications need hybrid signatures. I'm still not
seeing that they do.


As an aside: with the best will in the world, we (incl.
me;-), set out to develop PKI stuff in PKIX back in the
late '90s. I think we got lots of it fairly wrong, in no
small part because we were working on PKI stuff first
rather then on real applications that benefit from PKI.
It was only when the acme stuff started that we really
started seeing a WebPKI that worked well, and that was
less than 10 years ago. So I'm very wary of arguments
that we should start here by making (radical:-) changes
to PKI and only later figure out how applications can
benefit from those.


> The argument concerning extremely long migration periods for PKIs is
> a different argument then Mike’s long-term resistance one. In the PKI
> scenario periodic local countersigning is not helping.
> 
> You are asking if the BSI did analyze its needs and options – answer:
> yes, it did. The composite signatures seem to be the most simple
> approach that satisfy our needs. This is the way we would like to
> proceed. Therefore we would implement them in our PKI as already
> stated in
> https://mailarchive.ietf.org/arch/msg/spasm/LdjVSB4asaSsWteEnUVzCIR-_u4/ <https://mailarchive.ietf.org/arch/msg/spasm/LdjVSB4asaSsWteEnUVzCIR-_u4/>.
>
> If you still lack a use case or need one proposed – goto 1-4)
> above.


I still do not see the use case where hybrid signatures
are needed, sorry. And I did follow the goto:-)


> 
> Texts out published by the BSI concerning PKIs and X.509:
> 
> - In our guide „Quantum-safe cryptography – fundamentals,
> current developments and recommendations“ see section „3.4 X.509“ and
> recommendation „6.10 Migration to quantum-safe public key
> infrastructures“. Though this is from 2021 and intended as an
> overview touching on many topics not only on PKIs.
> 
> - Specifics on what the BSI plans for its PKI are (and our
> expected migration periods), you will find in the article „A
> Quantum-Safe Public Key Infrastructure for the Public Administration“
> published in the BSI Magazine „Security in focus“
> 2023/01(https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Magazin/BSI-Magazin_2023-01.pdf?__blob=publicationFile&v=2 <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Magazin/BSI-Magazin_2023-01.pdf?__blob=publicationFile&amp;v=2>).


More reading:-) Fair enough, will add that to my list.


Cheers,
S.




>
> Best Stavros
> 
> Von: Stephen Farrell <[e-mail] <mailto:[e-mail]> Gesendet: Donnerstag,
> 8. Februar 2024 20:34 An: Mike Ounsworth
> <[e-mail] <mailto:[e-mail]>>; Scott Fluhrer (sfluhrer)
> <[e-mail] <mailto:[e-mail]>>; Kris Kwiatkowski <[e-mail] <mailto:[e-mail]>>;
> [e-mail] <mailto:[e-mail]> Betreff: Re: [lamps] [EXTERNAL] Re:
> draft-ounsworth-pq-composite-sigs-11
> 
> 
> 
> Hiya,
> 
> On 08/02/2024 19:09, Mike Ounsworth wrote:
>>> Exactly. I'd like to know that we're talking about something that
>>> is needed, and needed now. Surely someone has documented such a
>>> thing that's IETF relevant?
>> 
>> Ok, let me try.
> 
> Thanks!
> 
>> 
>> First, I will define "now" to be "between 2024 and 20xx when BSI,
>> ANSSI and others recommend using lattice schemes by themselves".
>> 
>> As a concrete example, I provide S/MIME:
> 
> I'm assume we're talking email here.
> 
>> Encryption: I publish my encryption certificate so that people can
>> encrypt email to me. If the data in that email requires long-term
>> resistance to Harvest-Now-Decrypt-Later, then that S/MIME
>> encryption certificate needs to be a ML-KEM+ECC or ML-KEM+RSA
>> hybrid. This is consistent with the above referenced BSI
>> recommendation document.
> 
> A hybrid KEM, sure, that has real utility as you say.
> 
>> Signatures: I publish my signing certificate so that people can
>> verify the signatures on emails that I send. If the data in that
>> email requires long-term resistance to forgery and non-repudiation
>> attacks, then that S/SIME signing certificate needs to be a
>> ML-DSA+ECC or ML-DSA+RSA hybrid. This is consistent with the above
>> referenced BSI recommendation document.
> 
> So depending solely on long term certificates and signatures to try
> verify the signer long after the fact is a fairly tough ask as I
> guess we all know. It's entirely unclear to me that signing 
> separately twice would be any worse, once one considers all the 
> timestamping and countersignature stuff etc that's really needed (but
> probably almost never used?) to properly do that verification long
> after the eamil is received.
> 
> As a strawman, periodic local countersigning of the mail in the 
> message store with the fashionable pq sig de-jure without changing 
> the PKI (at signing time) could be a path worth exploring. It's not
> clear to me that the authorities cited earlier actually did that kind
> of analysis, but maybe they did?
> 
>> Now, there are design choices here: we could, for example, define a
>> new CMS extension that indicates that two SignerInfos MUST be
>> verified together, but I am not aware of such an extension, and if
>> such an I-D were submitted, I would argue that it is a more complex
>> and difficult-to-implement mechanism than the composite signature /
>> composite certificate mechanism proposed here. So, in absence of
>> any other proposed solutions, we are left with this composite 
>> signatures draft.
> 
> Or, we could note that nobody actually properly does that kind of 
> email signature verification (if that's the case) giving us a good 
> bit more time for pq sig algs to improve and gain confidence.
> 
> For context, 'case it helps, I've never believed x.509 alone gets us
> N-R, and I don't think I'm alone in that opinion.
> 
> So, thanks again for trying to provide the kind of answer for which 
> I'm asking, but in this case, I don't conclude that this scenario 
> actually demonstrates a need for hybrid sig algs.
> 
> Cheers, S.
> 
> PS: I'll read the BSI doc but probably not this evening.
> 
>> 
>> --- Mike Ounsworth
>> 
>> -----Original Message----- From: Stephen Farrell
>> <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>> Sent:
>> Thursday, February 8, 2024 12:56 PM To: Scott Fluhrer (sfluhrer)
>> <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>>; Mike Ounsworth 
>> <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>>;
>> Kris Kwiatkowski
>> <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>>; 
>> [e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>> Subject: Re: [lamps]
>> [EXTERNAL] Re: draft-ounsworth-pq-composite-sigs-11
>> 
>> 
>> Hiya,
>> 
>> Just to focus on the main point..
>> 
>> On 08/02/2024 18:51, Scott Fluhrer (sfluhrer) wrote:
>>> I would disagree; I do not believe that it is LAMPS's job to
>>> determine the appropriate solution for all the various use cases
>>> (we can give guidance, however what people use is out of our
>>> hands).
>> 
>> I didn't ask for "all," just for one.
>> 
>>> I believe that LAMPS does have the responsibility for giving
>>> people the tools they need
>> 
>> Exactly. I'd like to know that we're talking about something that
>> is needed, and needed now.
>> 
>> Surely someone has documented such a thing that's IETF relevant?
>> 
>> Ta, S.
>> 
>>