Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-objectid-07: (with COMMENT)

[Bron Gondwana <[e-mail]>]

On Wed, Aug 1, 2018, at 08:50, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-extra-imap-objectid-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all> email addresses included in the To and CC lines. (Feel free to
> cut this> introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/
> 
> 
> 
> ----------------------------------------------------------------------> COMMENT:
> ----------------------------------------------------------------------> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D7116
> 
> 
> 
> IMPORTANT
> S 11.
>>     If a digest is used for ID generation, it must have a collision
>>     resistent property, so server implementations are advised to
>>     monitor>>     current security research and choose secure digests.
>>  
>>     The use of a digest for ID generation may be used as proof that a>>     particular sequence of bytes was seen by the server.
> 
> I don't understand this text. How does the client know whether a
> digest was sued.

The client doesn't care, unless the server breaks the contract and
returns the same objectid for two different objects.  So using a non-collision-
resistant digest is bad.  The proof of sequence of bytes is the flip
side - if you use the sha256 of the message content as your id (for
example), then anybody who has a message ID from your server can prove
that you had that full email content by showing the email content and
the ID, because you couldn't have generated that ID without having that
particular email in your mailbox.  This might be relevant if you claim
you never had that email, but there's a protocol trace of a mailbox
listing which includes that EMAILID.
> COMMENTS
> S 7.
>>     IMAP ABNF extensions [RFC4466] specifications.
>>  
>>     Except as noted otherwise, all alphabetic characters are case-
>>     insensitive.  The use of upper- or lowercase characters to define>>     token strings is for editorial clarity only.  Implementations
>>     MUST>>     accept these strings in a case-insensitive fashion.
> 
> For clarity: IDs are not case insensitive, right? Because otherwise
> the text below about differing  in case doesn't make sense.

I've added wording to that effect.  Indeed IDs are case sensitive.

> 
> S 8.1.
>>  
>>     o  ids which contain only digits
>>  
>>     o  ids which differ only by ASCII case (A vs a)
>>  
>>     o  the specific sequence of 3 characters NIL
> 
> Nit. Do you want to quote "NIL"?

No - it's an IMAP protocol construct.  but I might add some more
descriptive text to it.  Thanks.
Cheers,

Bron.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]