On Wed, Oct 16, 2019 at 5:27 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-httpbis-http2-tls13-02: Yes > > 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-httpbis-http2-tls13/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this; I just have some minor nit-level comments; no response > necessary. > > Abstract > > This document updates HTTP/2 to prohibit TLS 1.3 post-handshake > authentication, as an analog to existing TLS 1.2 renegotiation > restriction. > > nit: either "restrictions" or "the existing". > Done in https://github.com/httpwg/http-extensions/pull/955. (I'll merge to the repository and publish a -03 shortly.) > Section 1 > > TLS 1.3 [RFC8446] updates TLS 1.2 to remove renegotiation in favor of > separate post-handshake authentication and key update mechanisms. > The former shares the same problems with multiplexed protocols, but > the prohibition in HTTP/2 only applies to TLS 1.2 renegotiation. > > nit: I'd suggest referring to a specific RFC rather than "HTTP/2" -- > this document will in some sense become part of "HTTP/2" upon > publication :) > Done. > Section 3 > > HTTP/2 servers MUST NOT send post-handshake TLS 1.3 > CertificateRequest messages. HTTP/2 clients MUST treat TLS 1.3 post- > handshake authentication as a connection error (see Section 5.4.1 of > [RFC7540]) of type PROTOCOL_ERROR. > > nit: is it the authentication or the request thereof that is the > connection error? > Reworded to say the message is the authentication error. > Section 4 > > Unless the use of a new type of TLS message depends on an interaction > with the application layer protocol, that TLS message can be sent > after the handshake completes. > > I don't see anything better to say than this, but ... will > draft-ietf-tls-exported-authenticator be considered to "depend on an > interaction with the application layer protocol"? > (Also, nit: hyphenate "application-layer".) > (Hyphenation fixed.) draft-ietf-tls-exported-authenticator doesn't define a post-handshake TLS message, so it hopefully shouldn't apply?Received on Thursday, 17 October 2019 19:33:32 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC