Re: New confidentiality and integrity limits

[Lars Eggert <[e-mail]>]

Thanks, Felix.

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

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.
>> 
>