Re: Roman Danyliw's No Objection on draft-ietf-quic-tls-33: (with COMMENT)

[Lucas Pardue <[e-mail]>]

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 <
[e-mail]> 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