Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap4rev2-27: (with COMMENT)

[Timo Sirainen <[e-mail]>]

On 4. Feb 2021, at 15.33, Barry Leiba <[e-mail]> wrote:
> 
>> Section 2.3.1.1
>> 
>>                                         A good UIDVALIDITY value to use
>>   is a 32-bit representation of the current date/time when the value is
>>   assigned: this ensures that the value is unique and always increases.
>>   Another possible alternative is a global counter that gets
>>   incremented every time a mailbox is created.
>> 
>> In light of the discussion in draft-gont-numeric-ids-sec-considerations,
>> I wonder if these are truly the most recommended options, as either
>> option has potential to leak some information about rate or time of
>> mailbox creation.  Leaking the time of mailbox creation to the user who
>> created it is, of course, not an issue, but not all IMAP mailboxes are
>> single-user-access.  A 32-bit PRP (e.g., block cipher) applied to either
>> option would provide some level of obfuscation while preserving the
>> uniqueness properties.
> 
> It would obfuscate and preserve uniqueness, but it would not preserve
> the monotonicity: a new UIDVALIDITY must always be greater than the
> previous ones.  Do you have a good suggestion for that, which still
> takes care of the privacy leak?

I wouldn't mind if that requirement was relaxed with rev2. It should be enough that the UIDVALIDITY is always different if a mailbox gets recreated. My guess is that all/most IMAP4rev1 clients would already work correctly.