Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Jul 2018 14:18:42 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-imap-objectid-06: 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:
----------------------------------------------------------------------

This is pretty exciting to see; I hope that all of this, specifically
THREADID, gains traction!

Please use the RFC 8174 boilerplate instead of a custom variant.

Section 4

nit: s/invarients/invariants/

Section 5.3

Is this valid ABNF without quotes around the literals, SP, and whatnot?

Section 7

The comment lines seem to have been wrapped badly for some of these
stanzas.

Section 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.  As the IDs are
   generated by the server, it will be possible to migrate to a new hash
   by just creating new IDs with the new algorithm. [...]

Perhaps reword to "by just using the new algorithm when creating new IDs";
the current wording could be misread to imply that the server should even
regenerate new IDs for existing messages (which is forbidden).

I guess we don't really need to discuss the case of a malicious server that
reuses IDs or returns incomplete search results, in this context.  But if
we did, there are several things that could be said.

Section 13.1

Server-assigned sequence numbers can have some operational challenges with
respect to power outages, crashes, restore from backup, and the like, and
ensuring that the number is in fact globally unique.  I guess for this case
it's less catastrophic than it is for, e.g., leaf reuse in hash-based
signatures (RFC 8391), so maybe the risk does not need to be called out.

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 31 Jul 2018 23:28:39 +1000

On Tue, Jul 31, 2018, at 07:18, Benjamin Kaduk wrote:
> 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.
> 
> 
> ----------------------------------------------------------------------> COMMENT:
> ----------------------------------------------------------------------> 
> This is pretty exciting to see; I hope that all of this, specifically> THREADID, gains traction!

Thanks :)

> Please use the RFC 8174 boilerplate instead of a custom variant.

Sure thing - done.

> nit: s/invarients/invariants/

Ta!  Fixed.

> Is this valid ABNF without quotes around the literals, SP, and
Now that's a really good point - it's kinda sloppy how it is now.  On
the other hand, it is spelled out clearly in the ABNF later.  I'll defer
to Alexey on whether it's worth going back and changing that.
> The comment lines seem to have been wrapped badly for some of these

It looked beautiful in the Markdown!  I've surrounded it with ``` and
now it's formatting a code block which looks much better in both text
and html.  I'm sure the editors will make it look even more lovely by
the time they've finished with it :)
>   resistent property, so server implementations are advised to monitor>   current security research and choose secure digests.  As the IDs are>   generated by the server, it will be possible to migrate to a
>   new hash>   by just creating new IDs with the new algorithm. [...]
> 
> Perhaps reword to "by just using the new algorithm when creating
> new IDs";> the current wording could be misread to imply that the server
> should even> regenerate new IDs for existing messages (which is forbidden).

I'll pay that.  That's more clear.

> I guess we don't really need to discuss the case of a malicious
> server that> reuses IDs or returns incomplete search results, in this
> context.  But if> we did, there are several things that could be said.

No, we really don't.  A server which lies about IDs could also return
different data every time for the same message.  Clients always need to
be somewhat defensive against rubbish on the wire.
> Section 13.1
> 
> Server-assigned sequence numbers can have some operational
> challenges with> respect to power outages, crashes, restore from backup, and the
> like, and> ensuring that the number is in fact globally unique.  I guess for
> this case> it's less catastrophic than it is for, e.g., leaf reuse in hash-based> signatures (RFC 8391), so maybe the risk does not need to be
> called out.
Yeah, we discussed it in group and decided everyone already knows that
to some extent for any server-set ids.  Unless my AD requests a change,
I'd leave this as is.
Thanks again - really comprehensive and good review.  I've updated the
draft with the feedback I've received over the past couple of days, and
I'll ask about whether the "Syntax" examples should be updated to ABNF
or stay more like the bytes on the wire.
Cheers,

Bron

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 Jul 2018 15:11:48 +0100

Hi,

> On Tue, Jul 31, 2018, at 07:18, Benjamin Kaduk wrote:
  [snip]
> the other hand, it is spelled out clearly in the ABNF later.  I'll 
> defer to Alexey on whether it's worth going back and changing that.
I was tripped by this as well. I would prefer either to use ABNF here or 
make it clear that this is a pseudo-syntax.

> to some extent for any server-set ids.  Unless my AD requests a 
> change, I'd leave this as is.

I think no change is fine.