Re: New confidentiality and integrity limits

[Watson Ladd <[e-mail]>]

On Tue, Jul 21, 2020, 2:50 AM Lars Eggert <[e-mail]> wrote:

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

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


> Thanks,
> Lars
>
> On 2020-7-16, at 9:47, Felix Günther <[e-mail]> wrote:
> >
> > 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
> >
> >
> > On 2020-07-16 06:58 +0200, Martin Thomson <[e-mail]> wrote:
> >> On Thu, Jul 16, 2020, at 11:40, Watson Ladd wrote:
> >>> 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.
> >>
> >> 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.
> >>
> >
>
>