Subject: Re: New confidentiality and integrity limits

From: Lucas Pardue <[email-masked]>
Date: Wed, 15 Jul 2020 19:12:27 +0100

Folks,

As mentioned up thread, the proposal for this issue requires a design
change.

Would anyone else care to express opinion in support for, or against, us
spending time on solving this problem in QUICv1. Please comment here or on
the Github issue: https://github.com/quicwg/base-drafts/issues/3788.

Cheers
Lucas

---

From: Watson Ladd <[email-masked]>
Date: Wed, 15 Jul 2020 21:40:03 -0400

I do not believe the analysis is correct.

A forgery against a QUIC connection will be checked at one or at most
two keys: the current one and the next one. It is not the case that a
forgery will be attempted against all the keys simultaneously: it will
have to be resent. Perhap I'm missing something about the setting here
that makes this the multiuser and not the singleuser setting.

Sincerely,
Watson

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 16 Jul 2020 14:58:33 +1000

> that makes this the multiuser and not the singleuser setting.

Thanks for checking Watson.

I had exactly the same thought, but was convinced by Felix that the analysis was based on a definition that only considers the number of encryption/verification queries in total. In particular, that the values in results are not limited in any way by which subset of the keys could be tried.

Incidentally, that also supports the view that there is degradation in the confidentiality advantage as you update to different keys.  I note that the PR does not acknowledge this, but maybe it should.

I confess that I'm still not completely confident that the multiuser setting is a good fit for our needs (or even that the threat model is the right one).  This is, in part of the reason you state: the mu setting assumes that the attacker has equal access to all "users" concurrently and the limited number of active keys would seem to make that difficult to exploit.  But I don't know how to prove that this is an acceptable assumption.

What I am confident about is that a conservative approach doesn't hurt a great deal here.  The calculated limits for GCM are high enough - even under the assumptions made - that you have serious problems if you hit them.

---

From: Felix Günther <[email-masked]>
Date: Thu, 16 Jul 2020 08:47:48 +0200

Hi Watson,

Let me clarify that the multi-user setting does not mean that a forgery
attempt is made against all keys simultaneously -- this model still
counts "try to decrypt 1 ciphertext under 1 key" as 1 forgery attempt.
The important difference is that, for each attempt, you may try a
different key.

While the model is somewhat more general in allowing to go back and
forth between all keys, this of course also captures the QUIC setting
where only few keys are active at any point in time, and are phased
in/out sequentially. I am not aware of an intermediate model, but I
don't think the difference would be huge, plus I strongly agree with
Martin that this conservative over-approximation doesn't hurt much here.

So, the multi-user model is the closest analysis we have to answer the
question:  "What's the advantage of an adversary that tries to inject a
forgery *at some point* in a QUIC connection."
Single-user models cannot answer this question, as they only speak to
forgery attempts under one fixed key, hence don't capture key updates.

I hope this clarifies the need for multi-user bounds.

Cheers,
Felix

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Jul 2020 09:49:51 +0300

Thanks, Felix.

Watson, does this address your comments? (Chairs are trying to push #3788 to resolution.)

Thanks,
Lars

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Jul 2020 08:38:42 -0400

> Watson, does this address your comments? (Chairs are trying to push #3788

Yes. I am still confused but it's clear I need to think harder about multi
user.

> >> I had exactly the same thought, but was convinced by Felix that the
> analysis was based on a definition that only considers the number of
> encryption/verification queries in total. In particular, that the values in
> results are not limited in any way by which subset of the keys could be
> tried.
> >>
> >> Incidentally, that also supports the view that there is degradation in
> the confidentiality advantage as you update to different keys.  I note that
> the PR does not acknowledge this, but maybe it should.
> >>
> >> I confess that I'm still not completely confident that the multiuser
> setting is a good fit for our needs (or even that the threat model is the
> right one).  This is, in part of the reason you state: the mu setting
> assumes that the attacker has equal access to all "users" concurrently and
> the limited number of active keys would seem to make that difficult to
> exploit.  But I don't know how to prove that this is an acceptable
> assumption.
> >>
> >> What I am confident about is that a conservative approach doesn't hurt
> a great deal here.  The calculated limits for GCM are high enough - even
> under the assumptions made - that you have serious problems if you hit them.
> >>
> >
>
>