Mike Bishop has entered the following ballot position for draft-ietf-emu-bootstrapped-tls-08: Discuss
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is hopefully easy to resolve. In Section 3.2, the document makes the following normative statement: CURRENT: "When clients use the [duckling] form of authentication, they MAY forgo...." [duckling] is an informative reference, and so cannot be the condition of a normative statement. As it's not a specification, I wouldn't think the solution is to make it a normative reference. Perhaps the specific behavior that's involved can be normatively stated here? CONSIDER: "When clients are configured to trust the first network which proves possession of their public key (as in [duckling]), they MAY forgo...." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The colloquial term "catch-22" might not be accessible to all readers. If you retain it, consider an informative reference such as https://en.wikipedia.org/wiki/Catch-22_(logic); it might perhaps be better to reword away from this term. Maybe "circular dependency"? Given that knowledge of the "public" key is being used as an identity proof on the network's part, it's inherently not public. Consider rephrasing throughout to use the term "asymmetric" since both keys are semi-secret, and using names other than public and private? Referring to a key pair as a "key" (in BSK) is also somewhat confusing -- consider perhaps "Bootstrap Keypair" and the same abbreviation? In Section 3, embedding the name of the RFC doesn't really improve clarity: CURRENT: the client must use [RFC7250] Using Raw Public Keys in TLS and DTLS in order to present the BSK as raw public key. CONSIDER: the client must present the BSK as a raw public key as described in [RFC7250]. In Section 3.1, this sentence is probably correct but reads awkwardly: CURRENT: A performance versus storage tradeoff a server can choose is to precompute.... CONSIDER: A server can choose to precompute.... Doing so represents a tradeoff between performance and storage. === NITS FOLLOW === Abstract and 1.1: Consider adding a "/" in "public private key pair" as is done in the Introduction. 2: "to identity" => "to identify" 3.2: "and client" => "and the client", "is knows" => "it knows" 4: "the server received" => "the server receives" _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
