Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (

[Eric Rescorla <[e-mail]>]

On Thu, Jan 2, 2020 at 11:19 AM Carrick Bartle <[e-mail]>
wrote:

> What "start over" means in this case is get to the point where there is a
> critical mass of client and server deployment, a process which takes time.
>
>
> I see.
>
> I think not, at least for TLS. The consensus of implementors seems to be
> that it's better to just cast composite algorithms as if they were new DH
> groups, so there's not a huge amount of leverage in a generic mechanism.
>
>
> My understanding is that the Cloudflare-Google implementation generated
> two separate shared secrets. Also this draft references several different
> "ad hoc" approaches in implementations:
> https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01.
>

Well, yes, but on the wire it's packaged as a single group and key share.

https://blog.cloudflare.com/the-tls-post-quantum-experiment/

-Ekr


> Carrick
>
>
> On Jan 2, 2020, at 10:50 AM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle <[e-mail]>
> wrote:
>
>> it's not useful to be prepared in that fashion
>> unless the algorithm that you are deploying is the one that is
>> eventually selected, because otherwise you just have to start over
>> once the selection is made.
>>
>>
>> Just to be specific, do you mean, for instance, all the certificates with
>> the PQ algorithm that wasn't chosen would have to be revoked?
>>
>
> Probably not.
>
> At a high level, there are two possible designs:
>
> 1. A certificate which has a composite signature in place of the classical
> signature and thus cannot be validated by old clients.
> 2. A certificate which has a PQ signature somehow attached in a way that
> it leaves the classical signature valid (as in an extension).
>
> In the former case, every server would need two certificates (one
> composite and one classical) and use signature_algorithms to distinguish
> which one to use. Once clients stopped liking the old PQ algorithm, then
> those composite certificates would become irrelevant and just be unused. In
> the latter case, the certificates would continue to be valid and the client
> could just ignore the PQ part of the signature.
>
> What "start over" means in this case is get to the point where there is a
> critical mass of client and server deployment, a process which takes time.
>
> the primary rationale for doing composite key exchange now is to
>> defend against retrospective attacks in case a quantum computer exists
>> in the future. In this setting, it isn't critically important to have
>> the PQ algorithm be the one we eventually land on, because each
>> connection is separately negotiated and as long as the PQ algorithm
>> has some security, you're getting benegit,.
>>
>>
>> In that case, would it make sense to take the next step with drafting an
>> intended standard for composite key exchanges (that is PQ
>> algorithm-agnostic)? If not, why not?
>>
>
> I think not, at least for TLS. The consensus of implementors seems to be
> that it's better to just cast composite algorithms as if they were new DH
> groups, so there's not a huge amount of leverage in a generic mechanism.
>
> -Ekr
>
> Carrick
>>
>>
>>
>>
>> On Dec 25, 2019, at 5:57 PM, Eric Rescorla <[e-mail]> wrote:
>>
>> On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle <[e-mail]>
>> wrote:
>> > How can it be true that it's too early to start developing a protocol
>> > for composite keys and signatures for Web PKI when Cloudflare and
>> > Google have already finished a round of experiments with composite key
>> > exchanges? Maybe I'm reading too much into it, but the existence of
>> > those experiments suggested to me that the need for composite/composite
>> > implementations was imminent. (I understand that the draft in question
>> > concerns signatures, not key exchanges, but apparently there isn't
>> > even a draft for the latter yet.)
>>
>> ISTM that these cases are pretty different, in a number of respects.
>>
>> First, the primary rationale for doing composite key exchange now is to
>> defend against retrospective attacks in case a quantum computer exists
>> in the future. In this setting, it isn't critically important to have
>> the PQ algorithm be the one we eventually land on, because each
>> connection is separately negotiated and as long as the PQ algorithm
>> has some security, you're getting benegit,.
>>
>> The primary rationale for doing PQ authentication now (or for that
>> matter composite authentication) is to be prepared for the day when QC
>> exists and we are therefore unable to rely on classical
>> algorithms. However, it's not useful to be prepared in that fashion
>> unless the algorithm that you are deploying is the one that is
>> eventually selected, because otherwise you just have to start over
>> once the selection is made.
>>
>> Moreover, in order to be truly prepared, what you need isn't
>> principally relying party deployment, but rather authenticating party
>> (in the case of the WebPKI, server-side) deployment. The reason for
>> this is that in the world where a QC exists, you don't have protection
>> until the relying party refuses to accept the classical credential
>> [0], and at present, any client which does so will effectively be
>> unable to communicate. And in order to make that happen, relying
>> parties will have to require a post-quantum algorithm (most likely as
>> a composite) and that's something I don't expect them to be willing to do
>> until there's widespread agreement on what that algorithm should be.
>>
>>
>> > If not now, when? After NIST crowns a winner? I don't see why it's
>> > necessary to wait that long given that the proposed solutions are
>> > algorithm-independent. And since the standardization process takes a
>> > while, won't waiting until then mean that there won't be a standard
>> > until after it's needed?
>>
>> No, i don't think so.
>>
>> For the reasons above, ISTM that real deployment will have to wait
>> until we have a selected algorithm. One could, as you suggest, deploy
>> some sort of multi-algorithm container, but IMO we will be far better
>> off just deploying new composite algorithms as if the were single
>> new algorithms, in the same way as we have done for key establishment.
>>
>> For this reason, I think we ought to wait until there is a consensus
>> PQ signature algorithm, at least for the WebPKI.
>>
>> -Ekr
>>
>> [0] This is why this kind of composite isn't helpful in the world
>> where a secret QC exists not.
>>
>>
>>> _______________________________________________
>> Secdispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secdispatch
>>
>>
>