Skip to main content

Using TLS 1.3 with HTTP/2
draft-ietf-httpbis-http2-tls13-03

Yes

(Adam Roach)
(Barry Leiba)

No Objection

Éric Vyncke
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)

Note: This ballot was opened for revision 02 and is now closed.

Éric Vyncke
No Objection
Roman Danyliw
No Objection
Comment (2019-10-15 for -02) Sent
** Abstract.  Recommend adding a sentence to the abstract that this draft updates RFC7540.
Adam Roach Former IESG member
Yes
Yes (for -02) Not sent

                            
Barry Leiba Former IESG member
Yes
Yes (for -02) Unknown

                            
Benjamin Kaduk Former IESG member
Yes
Yes (2019-10-16 for -02) Sent
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".

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 :)

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?

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".)
Alexey Melnikov Former IESG member
No Objection
No Objection (2019-10-16 for -02) Not sent
Thank you for this document.
Alissa Cooper Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Warren Kumari Former IESG member
No Objection
No Objection (2019-10-15 for -02) Sent
Please update the Abstract to say something like:
"This document updates RFC 7540 by  forbidding  TLS 1.3 post-handshake authentication." or similar.

Also, thanks to Tianran for the OpsDir review.