Hi Roman, Thanks for the review. I've captured your comments as issues on the QUIC WG GItHub repository. Links to each are provided as in-line responses.
On Tue, Jan 5, 2021 at 10:38 PM Roman Danyliw via Datatracker < [email protected]> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-quic-tls-33: 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-quic-tls/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Radia Perlman for the SECDIR review and the ensuing discussion > about this review. > > Two areas of recommended clarity: > > ** Section 4. Recommend a bit more text up front describing the notion of > “encryption levels”. This section first introduces the concept by noting > that > “Those frames are packaged into QUIC packets and encrypted under the > current > TLS encryption level”. Later in Section 4.1.3, it is noted that “Four > encryption levels are used, producing keys for Initial, 0-RTT, Handshake, > and > 1-RTT packets” which makes these “levels” seem only like categories. In > describing specific processing there is text such as “When TLS provides > keys > for a higher encryption level …” which now describes a relatively ordering > perhaps with something have having or less. I might be helpful to include > an > early narrative on what “higher” and “lower” and encryption “levels” means > and > how level changes occur (i.e., explicitly linking them to changes in the > QUIC > state machine). > https://github.com/quicwg/base-drafts/issues/4556 > ** Section 4.4. Per the peer authentication text, should it be > acknowledged > that due the general-purpose nature of the protocol, peer validation > practices > may will need to be further defined by applications? > > https://github.com/quicwg/base-drafts/issues/4557 Cheers, Lucas On behalf of QUIC WG Chairs
