[CFRG] IRTF Chair review of draft-irtf-cfrg-opaque-16

[Colin Perkins <[e-mail]>]

The CFRG chairs have requested that draft-irtf-cfrg-opaque-16 be 
published as an RFC on the IRTF stream. The IRTF publication process is 
described in RFC 5743, and comprises a review by the IRSG to ensure 
technical and editorial quality, followed by a check by the IESG to 
ensure the work does not conflict with IETF standards activities.

As IRTF Chair, I perform an initial review of all drafts submitted for 
publication on the IRTF stream before sending them for detailed review 
by the IRSG. This note provides my review comments, for discussion.

The document shepherd write-up states that the authors have made all 
necessary IPR disclosures, as described at 
https://irtf.org/policies/ipr.

**Result:** Ready with nits

**RFC 5743 compliance:** The draft does not follow the guidelines in RFC 
5743

**Comments:**

Thank you for preparing this draft. Apologies for the delay in my 
review. Overall this looks good, and I thank the authors and others in 
the group for the effort they have spent developing and reviewing the 
work.

I have two procedural details that should be resolved:

* Please add a sentence to the end of the Introduction to say “This 
document is not an IETF product and is not a standard” to meet the 
requirements of RFC 5743.

* The Discussion Venues section is marked “to be removed before 
publishing”. That’s appropriate, but the CFRG Chairs should add a 
link to the GitHub page in the “Additional resources” part of 
https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/ so it can be 
found after publication.


While reviewing the draft, I also noted areas where I thought 
clarifications might be helpful. I’m a generalist, and very much not a 
security expert, so none of these should be considered blocking comments 
– I’m happy to be told that the draft follows the usual conventions 
in the field and the description will be clear to the intended audience:

* Section 2.1: some of the APIs reference specific sections of RFC 9497, 
some do not. To avoid confusion, would it make sense to consistently 
reference RFC 9497 in cases when the APIs are defined there?

* Section 2.2: “`Expand(prk, info, L)`: Expand a pseudorandom key prk 
using the optional string info…” – will it be clear to readers 
what to do if the optional string is not provided?

* Section 2.3: the definition of `Stretch(msg)` doesn’t specify the 
size of the output. Should it? Similar issues occur elsewhere, e.g., 
`auth_tag` in section 4.1.1, so if this is important it may be worth 
checking that the sizes are consistently specified.

* Section 3.2: for clarity, I suggest to change “The registration flow 
is shown below” to “The registration message flow is shown below and 
the process is described in detail in Section 5”.

* Section 4.1.2: I found the syntax `Create Envelope envelope with 
(envelope_nonce, auth_tag)` confusing since it reads like pseudo code 
but is in the middle of a more precise description. It wasn’t 
immediately obvious to me that it was referring to previously defined 
types. Would it be clearer to say `envelope = Envelope(envelope_nonce, 
auth_tag)` or similar? (There is similar phrasing in a number of other 
places)

* Section 5: what happens to the results that are not sent to the peer? 
For example, `CreateRegistrationRequest()` returns `(request, blind)` 
and it looks like `request` is sent to the server, but what is done with 
`blind`? (Similar issue with the ladder diagrams elsewhere in this 
section and in Section 6)


Finally, I note that the appendices contain a number of test vectors. 
Has the latest version of the draft been verified against a reference 
implementation to ensure these are correct?

Regards,
Colin