Re: [Privacy-pass] AD review of draft-ietf-privacypass-protocol-11

[Christopher Wood <[e-mail]>]

Thanks for the feedback, Paul! I addressed most of it here:

   https://github.com/ietf-wg-privacypass/base-drafts/pull/435

Please see inline below for responses to comments that were not addressed.

> On Aug 15, 2023, at 10:30 PM, Paul Wouters <paul.wouters=[e-mail]> wrote:
> 
> Thanks for producing this document. It is a clear read. I have a few minor questions and a few comments to consider for improvement.
> 
> Questions:
> 
>         Clients SHOULD NOT use a token key before this timestamp
> 
> Why is this not a MUST NOT ?

Because using a stale key does not necessarily mean that issuance will fail. Issuers can certainly hang onto keys well after the expiration.

> 
> Why is token-keys not called issuer-token-list ? Brings it more in line with
> issuer-request-uri and deconfuses it from token-key. This way, the top layer
> is issuer-* values and the bottom layer is token-* values. Similarly, I would
> name not-before token-not-before.
> 
>         Since Clients truncate token_key_id in each TokenRequest,
>         Issuers should ensure that the truncated form of new key IDs do 
>         not collide with other truncated key IDs in rotation.

Since this is an editorial suggestion that would be a breaking change for shipping implementations, I think it’s best to leave the names as-is for now.

> 
> So why are the token ids truncated? Why not use the full id ?
> 
>         Each key pair SHALL be generated as as specified in FIPS 186-4
> 
> Can this be rephrased as "SHALL be generated securely, for example as specified in FIPS 186-4".
> I find it a bit odd for an IETF document to require a national crypto standard conformance.
> Then you can also keep the DSS reference as informative. If the document ends up keeping
> this text, it would have to reference DSS normatively.
> 
> The DSS link https://dx.doi.org/10.6028/nist.fips.186-4 throw a warning that it is about to
> die and points to an updated reference. Use that instead?
> 
> Comments:
> 
> I find the line breaks for some table items confusing, eg:
> 
>         issuera-
>         request-
>         uri
> 
> People will wonder if that should read as "issuer-request-uri" or "issuerrequesturi"
> There are a number of these in the document (token-key, token-type, ?)

I agree, but this is precisely the sort of thing the RPC is equipped to do, so I did not try to resolve this.

> 
> UNIX timestamp - Maybe refer to https://datatracker.ietf.org/doc/html/rfc8877#section-4.2.1
> 
> 
>         Regular rotation of token keys is recommended to minimize the risk of key compromise.
> 
> You mean minimize the effects of a key compromise ? Or minimize the exposure of compromised keys?
> 
> 
>         The Issuer then tries to deseralize
> 
> Start this sentence on a new line so it becomes clearer this is not part of the just mentioned failure path?
> 
>         The Token.nonce value is that which was sampled in
> 
> Can we say "created" instead of "sampled" ?
> 
>         Otherwise, if the Issuer is willing to produce a token token to the Client
> 
> There is a stray "token" word in that sentence.
> 
> The document references draft-irtf-cfrg-rsa-blind-signatures-13 but -14 is out.
> 
> The last sentence of the Security Consideration section runs on very long and is very hard to
> read. Can this be split in separate sentences?
> 
> The document references  draft-ietf-privacypass-auth-scheme-11  but -12 is out.
> 
> In section 8.2, it refers to an IANA registry by pointing to another document instead of just
> naming the registry. This indirection is not desirable. Just reference the IANA registry
> "Privacy Pass Token Type".
> 
> draft-ietf-privacypass-key-consistency-00 is also an outdated reference, as -01 is available.
> 
> 
> The Shepherds write up answered the question on "required formal expert review criteria,
> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews" as "N/A" but the
> document does add a number of media type registrations.

I’ll leave this one to chairs to respond to.

Best,
Chris