HTTP/2
draft-ietf-httpbis-http2bis-07

[Ballot comment]
Not much to say - another well written document update - I only reviewed the diff.

One minor comment/nit,

Section 5.3.1.  Background of Priority in HTTP/2

  HTTP/2 included a rich system for signaling priority of requests.
  However, this system proved to be complex and it was not uniformly
  implemented.

Given that this document obsoletes RFC7540 and becomes the reference for HTTP/2 then I would suggest that this section would be better introduced as "RFC7540 included a rich system ..."

Regards,
Rob

[Ballot comment]
Thanks for this eminently readable document.

I do have one piffling little question. Appendix A ends with

      |  Note: This list was assembled from the set of registered TLS
      |  cipher suites when [RFC7540] was developed.  This list includes
      |  those cipher suites that do not offer an ephemeral key exchange
      |  and those that are based on the TLS null, stream, or block
      |  cipher type (as defined in Section 6.2.3 of [TLS12]).
      |  Additional cipher suites with these properties could be
      |  defined; these would not be explicitly prohibited.

This text leaves me with the strong impression that the authors think it would be in exceedingly poor taste to make use of additional cipher suites with these properties, even if you can’t a priori forbid them. Then again you haven’t even explicitly prohibited the ones you do list, just said that implementations MAY reject them.

What I’m getting around to here, is the question of whether you can and should be a little more concrete about the “in exceedingly poor taste” thing if indeed that is what you intend. E.g., something like “although future cipher suites can’t be explicitly listed here for obvious reasons, implementations may wish to consider giving such future suites equivalent treatment.”

The language about “explicitly prohibited” also makes me wonder if you believe you’ve explicitly prohibited the suites you list. As mentioned above, you haven’t, strictly speaking.

[Ballot discuss]
I see that the list of "changes since RFC 7540" in Appendix B lists:

  *  The ranges of codepoints for settings and frame types that were
      reserved for "Experimental Use" are now available for general use.

But this doesn't seem to be reflected in either §11 (IANA Considerations)
or the live registry.
Should it be?  (Some backchannel discussion suggests that it's rather
this entry in the appendix is erroneous.)

[Ballot comment]
Thanks to Sean Turner for the secdir review, and the authors for preparing
PR #1001 in response.

Thanks as well for another high-quality and well-written document; it was a
pleasure to read.

I put most of my editorial suggestions in a PR on github:
https://github.com/httpwg/http2-spec/pull/1009

There are a number of places in the section-by-section comments where I
compare this document to the text in the quic-http spec; those comparisons
were made mostly in vacuum, and can safely be ignored if there are known
reasons for divergence between h/2 and h/3.

Section 4.1

I recall that quic-http has a note on the generic frame format that each
frame's payload must contain exactly the fields listed, with no additional
bytes and not terminating before the end of the listed fields, and that
redundant length-encodings must be verified for consistency.  While I don't
actually see any redundant length encodings in the frame types specified in
this document (but maybe there is some redundancy when HPACK is added into
the mix?), the other cautions from h/3 might be worth mentioning here as
well.

Section 4.3

  Field blocks carry the compressed bytes of a field section, with
  header sections also carrying control data associated with the
  message in the form of pseudo-header fields (Section 8.3) that use
  the same format as a field line.

The procedures described in the rest of the section give me the impression
that there is a 1:1 relationship between field section and field block, but
this text only gives me a clear impression that each field block corresponds
to a single field section, not the reverse.  Should we try to clarify that
it's definitely a 1:1 relationship (assuming it actually is, of course)?
Perhaps something like "a field block carries the compressed bytes of a
field section, with header sections also [...]".

Section 5.1

  half-closed (local):  A stream that is in the "half-closed (local)"
      [...]
      An endpoint can receive any type of frame in this state.
      [...]
      PRIORITY frames can be received in this state.

I'm not sure whether this redundancy is adding much.  In RFC 7540 the last
sentence was followed by a note about "used to reprioritize streams that
depend on the identified stream", but since PRIORITY is basically neutered
now it may not need a special mention.

  closed:  The "closed" state is the terminal state.
  [...]
      An endpoint that sends a frame with the END_STREAM flag set or a
      RST_STREAM frame might receive a WINDOW_UPDATE or RST_STREAM frame
      from its peer in the time before the peer receives and processes
      the frame that closes the stream.

Could such a client also receive PUSH_PROMISE frames in this situation?
The following paragraph (about the "open"->"closed" via sending RST_STREAM
transition) does mention receiving any frame (and PUSH_PROMISE specifically)
and the need to update compression state, but if I understand correctly
PUSH_PROMISE can happen after a "half-closed (local)"->"closed" transition
due to sending RST_STREAM as well, which does not seem covered by the
existing text.

Looking at the diff from RFC 7540, I see that this state's description was
substantially rewritten; in 7540 there was a dedicated paragraph about
PUSH_PROMISE that went on to note that RST_STREAM would be needed to close
an unwanted promised stream; I don't know if that is worth bringing back or
not.

Another item that comes up looking at the diff is receipt of DATA after
RST_STREAM.  That makes me wonder if the text I mentioned earlier, about
sending RST_STREAM specifically on a stream in the "open" state, is too
narrowly specified.  If that paragraph is not limited to the situation where
"closed" is entered by sending RST_STREAM from "open", then it looks like
most of what I'm worried about here would not be problematic anymore.  That
change might cause other issues, though.

Section 5.1.2

  An endpoint that wishes to reduce the value of
  SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current
  number of open streams can either close streams that exceed the new
  value or allow streams to complete.

Is there a race condition here between the peer continuously creating new
connections and the endpoint closing connections to try to lower the value?
In particular, what happens if the SETTINGS that reduces the value crosses
on the wire with the frame creating a stream that would exceed the value?

Section 5.5

  An extension that changes existing elements MUST be negotiated before
  being used.  For example, an extension that changes the layout of the
  HEADERS frame cannot be used until the peer has given a positive
  signal that this is acceptable.  In this case, it could also be
  necessary to coordinate when the revised layout comes into effect.
  For example, treating frames other than DATA frames as flow
  controlled requires a change in semantics that both endpoints need to
  understand, so this can only be done through negotiation.

Do we want to call out use of frame types that alter (existing elements of)
connection state as another thing that needs negotiation before use?

Section 6.9.2

  The connection flow-control window is also 65,535 octets.  Both
  endpoints can adjust the initial window size for new streams by
  including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS
  frame that forms part of the connection preface.  [...]

This phrasing suggests that SETTINGS_INITIAL_WINDOW_SIZE can be sent only in
the connection preface, but the rest of the section does not seem consistent
with such a limitation.  Is it better to just end the sentence with "in a
SETTINGS frame"?

Section 8.4.1

  The header fields in PUSH_PROMISE and any subsequent CONTINUATION
  frames MUST be a valid and complete set of request header fields
  (Section 8.3.1).  The server MUST include a method in the :method
  pseudo-header field that is safe and cacheable.  If a client receives
  a PUSH_PROMISE that does not include a complete and valid set of
  header fields or the :method pseudo-header field identifies a method
  that is not safe, it MUST respond with a stream error (Section 5.4.2)
  of type PROTOCOL_ERROR.

Up in §8.4 we seemed to talk about the same (non-safe) scenario by saying
that the promised stream being reset with the PROTOCOL_ERROR.  But I read
this text ("respond with a stream error") as applying to the explicit
request to which the promised request is associated.  Is that the intent?
If not, perhaps we should say "respond on the promised stream ID".

Section 8.4.2

  Clients receiving a pushed response MUST validate that either the
  server is authoritative (see Section 10.1) or the proxy that provided
  the pushed response is configured for the corresponding request.  For
  example, a server that offers a certificate for only the example.com
  DNS-ID is not permitted to push a response for
  https://www.example.org/doc.

Should we reference RFC 6125 (or its bis) for "DNS-ID"?

Section 9.1

  Clients SHOULD NOT open more than one HTTP/2 connection to a given
  host and port pair, where the host is derived from a URI, a selected
  alternative service [ALT-SVC], or a configured proxy.

quic-http has similar text (in §3.3), but it refers to a given IP address
and port, rather than host and port.  Is the difference between host and IP
address significant when comparing h/2 and h/3?  (When using IP addresses,
we of course have to additionally talk about name resolution of the other
types of identifier.)

  A client MAY open multiple connections to the same IP address and TCP
  port using different Server Name Indication [TLS-EXT] values or to
  provide different TLS client certificates but SHOULD avoid creating
  multiple connections with the same configuration.

Similarly, comparing against the analogous h/3 text, h/3 talks about
"transport or TLS configurations" rather than SNI values or TLS client
certificates.  Do we want to follow h/3's lead on phrasing?

Section 9.2.2

  have non-intersecting sets of permitted cipher suites.  To avoid this
  problem causing TLS handshake failures, deployments of HTTP/2 that
  use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  [TLS-ECDHE] with the P-256 elliptic curve [FIPS186].

I think that RFC 8422 would be a fine reference for the use of the P-256
curve for TLS ECDHE.  In particular, FIPS186-4 only covers ECDSA, not ECDHE,
and for ECDSA it largely defers to the costs-money X9.62 standard, which
gives some reason to prefer more open references.

Section 10.5.2

  The CONNECT method can be used to create disproportionate load on a
  proxy, since stream creation is relatively inexpensive when compared
  to the creation and maintenance of a TCP connection.  A proxy might
  also maintain some resources for a TCP connection beyond the closing
  of the stream that carries the CONNECT request, since the outgoing
  TCP connection remains in the TIME_WAIT state.  Therefore, a proxy
  cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the
  resources consumed by CONNECT requests.

Looking at the diff from this text to §10.5.2 of quic-http, I see the latter
has a new sentence about "a proxy that supports CONNECT might be more
conservative in the number of simultaneous requests it accepts", and also
has some different phrasing in the last sentences about "might delay
increasing the stream limit after a TCP connection terminates" vs "cannot
rely on SETTINGS_MAX_CONCURRENT_STREAMS alone".  I think that the overall
issues in this space remain pretty analogous between h/3 and h/2, so we
might want to pull in more of the updated h/3 text here.

Separately, do we want to mention [TALKING] again here and the issues it
raises?

Section 11.1

  This section marks the HTTP2-Settings header field registered by
  Section 11.5 of [RFC7540] in the Hypertext Transfer Protocol (HTTP)
  Field Name Registry as obsolete.  This capability has been removed:
  see Section 3.1.  [...]

I don't really see anything in §3.1 that speaks to HTTP2-Settings as being
obsolete.  "Settings" overall are mentioned under §3 only in §3.4, but only
in the context of the SETTINGS frame.

Is this perhaps something that should be mentioned in Appendix B (changes
from RFC 7540), and the reference changed to point to that?

Section 12.2

The link for [TALKING] doesn't resolve for me.
I guess it's probably the same content as
https://ptolemy.berkeley.edu/projects/truststc/pubs/840/websocket.pdf and
https://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf
though.

Appendix B

As part of resolving errata report 4666, we removed text from this
specification about the HTTP 421 status code, in particular, text saying
that it was cachable by default.  Is that change worth noting here?

EDITORIAL

Section 10.5

  *  An attacker can provide large amounts of flow control credit at
      the HTTP/2 layer, but withhold credit at the TCP layer, preventing
      frames from being sent.  An endpoint that constructs and remembers
      frames for sending without considering TCP limits might be subject
      to resource exhaustion.

This risk seems interrelated with the first one, about "insufficient
tracking of outstanding outbound frames"; is there a reason for the current
ordering of this list, or might we reorder to keep these related topics
together?

[Ballot comment]
Thank you for the work put into this document. As a side note, I am impressed that the WG only needed 6 revisions for such a major document! The introduction section is also crystal clear and to the points.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Mark Nottingham for the (short) shepherd's write-up including the section about the WG consensus (even if very terse).

I hope that this helps to improve the document,

Regards,

-éric

-- Section 3.1 --
Beside the history associated to "h2c", I really wonder why it is described in the document (just out of curiosity).

-- Section 5.1.1 --
In "The identifier of a newly established stream MUST be numerically greater", is the increment interval 1 or can it be any positive non-nul integer ?

-- Section 5.2.1 --
In the bullet 1. in "Both types of flow control", it is unclear to me what "both" refers to especially after reading the previous "allow a variety of flow-control algorithms", which hints to several (and not 2) mechanisms. Or is it per direction ?

-- Section 6.1 --
The SEC AD will obviously have the final word on this but wouldn't random padding be more secure (at the expense of later compression of course) ?

-- Section 6.7 --
In figure 9, suggest to indicate that the Length is 8 octets.

-- Section 9.1 --
In "Clients SHOULD NOT open more than one HTTP/2 connection", should some words be added when the client has multiple interfaces (e.g., Wi-Fi & mobile) ? I understand that this is probably beyond HTTP...

-- Appendix A --
Some justifications (beyond the note at the end of the appendix) would be welcome.

Should a pointer to section 9.2.2 be added ?

[Ballot comment]
Thanks for this document. Please address Joerg's TSVART review.

Although it doesn't use an RFC2119 keyword, the reference to httpbis-priority in Sec. 5.3.2 feels normative to me. There's no need to argue it out with me, but as both drafts are done it seems harmless to make it a normative reference (assuming you're going for PS).

[Ballot comment]
Thank you to Sean Turner for the SECDIR review.

** Section 2.  Editorial.  Could this section provide a summary of what’s getting obsoleted from RFC7540 in one place?  The text already explicitly says that the RFC7540 prioritization scheme is deprecated.  Should the text also note that the upgrade mechanism of HTTP2-Settings header field (per Section 3.2 of RFC7540) is obsolete?  This detail is buried in Section 11 and Section 3.1 could be clearer.

** Section 5.3.2
  Servers SHOULD use other contextual information in determining
  priority of requests in the absence of any priority signals.

Given that “the prioritization signaling in RFC7540 [RFC7540] was not successful.”  Can more be said to guide implementers on what contextual information could be used?

** Section 6.5.1.  Editorial.  After Figure 7, should this section have the boiler plate text “The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in Section 4”?

** Section 8.1.1.  Per Section 6.1, padding octets must be zero and a recipient may treat non-zero padding as a connection error (no change in guidance from RFC7540).  In this new section, would it be worth reiterating this guidance and categorizing non-zero padding as a malformed frame?

[Ballot comment]
Section 3.1. , paragraph 6, comment:
>      The "h2c" string was previously used as a token for use in the
>      HTTP Upgrade mechanism's Upgrade header field (Section 7.8 of
>      [HTTP]).  This usage was never widely deployed, and is no longer
>      specified in this document.

Does that mean its deprecated? Since this RFC obsoletes the earlier specs, it
would be good to clarify what that means for anything that got dropped.

Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/EwzPC-Ttz_9fX8_I3tvw-Din_GQ).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.1. , paragraph 7, nit:
>      The "h2c" string is reserved from the ALPN identifier space but
>      describes a protocol that does not use TLS.  The security
>      properties of this protocol do not hold unless TLS is used; see
>      Section 10.

s|this protocol|HTTP/2| for clarity?

Section 8.2.1. , paragraph 2, nit:
-    The definitions of field names and values in HTTP prohibits some
-                                                              -

Section 8.4. , paragraph 2, nit:
-    HTTP/2 allows a server to pre-emptively send (or "push") responses
-                                -

Section 5.1. , paragraph 33, nit:
> as an error after receiving an acknowledgement of the settings. Other things
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 5.5. , paragraph 3, nit:
> r is not obligated to verify padding but MAY treat non-zero padding as a con
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 6.1. , paragraph 2, nit:
> r is not obligated to verify padding but MAY treat non-zero padding as a con
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 6.2. , paragraph 12, nit:
> nal frames for that stream, with the exception of PRIORITY. However, after s
>                            ^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for".

Section 6.5. , paragraph 8, nit:
> INGS frame does not receive an acknowledgement within a reasonable amount of
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 6.5.2. , paragraph 5, nit:
> r is not obligated to verify padding but MAY treat non-zero padding as a con
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 6.5.2. , paragraph 8, nit:
>  this setting and has received acknowledgement MUST treat the receipt of a PU
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 6.6. , paragraph 23, nit:
> l activity is not possible, with the exception of idempotent actions like HTT
>                            ^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for".

Section 7. , paragraph 16, nit:
> Z', ASCII 0x41 to 0x5a). * With the exception of pseudo-header fields (Sectio
>                            ^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for".

Section 8.1. , paragraph 10, nit:
> ilers". An intermediary transforming a HTTP/1.x message to HTTP/2 MUST remov
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 8.1. , paragraph 11, nit:
> kie header field [COOKIE] uses a semi-colon (";") to delimit cookie-pairs (o
>                                  ^^^^^^^^^^
This word is normally spelled as one.

Section 8.1.1. , paragraph 6, nit:
> ion 7.1 of [HTTP]). The recipient of a HTTP/2 request MUST ignore the Host h
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Document references draft-ietf-httpbis-semantics-18, but -19 is the latest
available revision.

Document references draft-ietf-httpbis-cache-18, but -19 is the latest
available revision.

Reference [TLS12] to RFC5246, which was obsoleted by RFC8446 (this may be on
purpose).

Document references draft-ietf-httpbis-priority-10, but -11 is the latest
available revision.

Document references draft-ietf-httpbis-messaging-18, but -19 is the latest
available revision.

These URLs in the document did not return content:
* http://w2spconf.com/2011/papers/websocket.pdf

These URLs in the document can probably be converted to HTTPS:
* http://dx.doi.org/10.6028/NIST.FIPS.186-4
* http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-http2bis-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the registries on the Hypertext Transfer Protocol version 2 (HTTP/2) Parameters registry page located at:

https://www.iana.org/assignments/http2-parameters/

All of the existing references to [RFC7540] will be changed to [ RFC-to-be ].

Second, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the two, current references to [RFC7540] will be changed to [ RFC-to-be ].

Third, in the HTTP Method Registry located at:

https://www.iana.org/assignments/http-methods/

the single reference to [RFC7540] will be changed to [ RFC-to-be ]. In addition, in the same registry, the PRI method will have its reference changed to [ RFC-to-be; Section 3.4 ].

Fourth, in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

the existing Field Name: HTTP2-Settings

is to be marked obsolete with a note to see [ RFC-to-be; Section 11.1 ]

Fifth, in the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry located at:

https://www.iana.org/assignments/http-upgrade-tokens/

the Value: h2c

is to be marked obsolete with a reference of [ RFC-to-be; Section 3.1 ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
IANA Services

The following Last Call announcement was sent out (ends 2021-11-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-http2bis@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Hypertext Transfer Protocol Version 2 (HTTP/2)) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'Hypertext Transfer Protocol Version 2 (HTTP/2)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-11-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification describes an optimized expression of the semantics
  of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
  version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network
  resources and a reduced latency by introducing field compression and
  allowing multiple concurrent exchanges on the same connection.

  This document obsoletes RFC 7540 and RFC 8740.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2bis/



No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for draft-ietf-httpbis-http2bis

## 1. Summary

Mark Nottingham is the document shepherd; Francesca Palombini is the responsible Area Director.

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.

This document obsoletes RFC 7540 and RFC 8740, and is intended to be publishd as a Proposed Standard.


## 2. Review and Consensus

This document has enjoyed wide review and discussion among HTTP implementers and other Working Gropu participants. It benefits from the broad deployment of the protocol and the experiences of those deployments.


## 3. Intellectual Property

Both authors have confirmed that they have no direct, personal knowledge of any IPR related to this document.


## 4. Other Points

The document has an intentional reference to TLS 1.2, even though that document has been obsoleted by TLS 1.3.

# Shepherd Writeup for draft-ietf-httpbis-http2bis

## 1. Summary

Mark Nottingham is the document shepherd; Francesca Palombini is the responsible Area Director.

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.

This document obsoletes RFC 7540 and RFC 8740, and is intended to be publishd as a Proposed Standard.


## 2. Review and Consensus

This document has enjoyed wide review and discussion among HTTP implementers and other Working Gropu participants. It benefits from the broad deployment of the protocol and the experiences of those deployments.


## 3. Intellectual Property

Both authors have confirmed that they have no direct, personal knowledge of any IPR related to this document.


## 4. Other Points

The document has an intentional reference to TLS 1.2, even though that document has been obsoleted by TLS 1.3.