Ballot for draft-ietf-lamps-ocsp-nonce
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
I support Barry's DISCUSS. I'll also repeat one of Barry's observations: In Section 2, the list of extensions that exist seems to be an unnecessary citation if all this document needs to talk about is the Nonce extension.
I support Barry's discuss -- I'm assuming that there is some blindingly obvious reason for the text as is, but a: I don't see it and b: if there is, please add it to the document so others like me understand...
Just some nits of varying severity from me... Abstract This document specifies the updated format of the Nonce extension in Online Certificate Status Protocol (OCSP) request and response nit(?): is it the format itself that is specified or constraints upon the format? Section 1 Due to not having an upper or lower limit of the length of the Nonce extension, the OCSP responders that follow [RFC6960] may be vulnerable to various attacks like Denial of Service attacks [RFC4732], chosen prefix attacks to get a desired signature from the OCSP responder and possible evasions that can use the Nonce extension data for evasion. [...] nit: "evasions that can use [...] for evasion" is slightly awkward wording. Could we say something different about what is being evaded? This document specifies a lower limit of 1 and an upper limit of 32 to the length of the Nonce extension. This (pedantic nit): the length of the extension, or the length of the OCTET STRING bearining the nonce value, contained in the extension? Section 2 Thanks for agreeing to remove the unrelated list of OCSP extnsions. Section 2.1 I'm happy to see the discussion with Barry about mandating the behavior of new clients more tightly without breaking old clients. A server MUST reject any OCSP request having a Nonce extension with length of 0 octets or more than 32 octets with the malformedRequest OCSPResponseStatus as described in section 4.2.1 of [RFC6960]. (same nit about exactly which length is being constrained.) Section 3.1 (side note) the bit about the Nonce being optional in the response even if it was present in the request is actually in 6960 itself if you read carefully; 5019 has a bit more exposition on it but may not, strictly speaking, be a necessary reference. Section 5.x [I expect that the RFC Editor will adjust the formatting/wording a bit, especially since "old syntax" and "new syntax" in the context of 1998 vs. 2008 ASN.1 syntax is probably going to make people think ASN.1, as opposed to "OLD text" and "NEW text" or just "OLD"/"NEW".]
Thanks, Mohit, for addressing my DISCUSS and other comments!
I support Barry's DISCUSS
Hi, This document is simple and easy to read and understand, to thank your for that. As someone with little security knowledge, I was left wondering how the determination of what length nonce is required is made? E.g., is there some calculation that is performed that concludes that 16 bytes is okay, but 32 is better and any longer is pointless? Or is that described in another document that could be referenced (perhaps this is covered by the last parts of rfc4086)? Hence, my comment on this document is whether it would be helpful to have any background text that explains why the particular length(s) of nonce has been chosen. Regards, Rob