From 34be75ec8b11a7ec9f19bfd777090ea49448f574 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Tue, 3 Sep 2019 11:39:32 +1000 Subject: [PATCH 01/14] add obsoletes for 2818 --- draft-ietf-httpbis-semantics-latest.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index 7fe75f4d1..a709e3054 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -31,7 +31,7 @@ - - This document obsoletes RFC 7231, RFC 7232, RFC 7233, + This document obsoletes RFC2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, and portions of RFC 7230. From 42a9fd7e37fa5666119e55ef29bb96f3b9b93157 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Tue, 3 Sep 2019 11:56:46 +1000 Subject: [PATCH 02/14] Bring in text about identifying servers, clients ... and update reference to 5280. --- draft-ietf-httpbis-semantics-latest.xml | 120 ++++++++++++++++++++++-- 1 file changed, 112 insertions(+), 8 deletions(-) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index a709e3054..eecb94642 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -819,7 +819,7 @@ Content-Type: text/plain The process for authoritative access to an "https" identified - resource is defined in . + resource is defined in . @@ -9628,15 +9628,85 @@ Content-Encoding: gzip an "http" URI is vulnerable to attacks on Internet Protocol routing. - The "https" scheme () is intended to prevent - (or at least reveal) many of these potential attacks on establishing - authority, provided that the negotiated TLS connection is secured and - the client properly verifies that the communicating server's identity - matches the target URI's authority component - (see ). Correctly implementing such verification - can be difficult (see ). + The "https" scheme () is intended to prevent (or + at least reveal) many of these potential attacks on establishing + authority, provided that the negotiated TLS connection is secured and the + client properly verifies that the communicating server's identity matches + the target URI's authority component, as described below. Correctly + implementing such verification can be difficult (see ). + +
+ + In general, HTTP/TLS requests are generated by dereferencing a URI. + As a consequence, the hostname for the server is known to the client. + If the hostname is available, the client &MUST; check it against the + server's identity as presented in the server's Certificate message, + in order to prevent man-in-the-middle attacks. + + + If the client has external information as to the expected identity of + the server, the hostname check &MAY; be omitted. (For instance, a + client may be connecting to a machine whose address and hostname are + dynamic but the client knows the certificate that the server will + present.) In such cases, it is important to narrow the scope of + acceptable certificates as much as possible in order to prevent man + in the middle attacks. In special cases, it may be appropriate for + the client to simply ignore the server's identity, but it must be + understood that this leaves the connection open to active attack. + + + If a subjectAltName extension of type dNSName is present, that &MUST; + be used as the identity. Otherwise, the (most specific) Common Name + field in the Subject field of the certificate &MUST; be used. Although + the use of the Common Name is existing practice, it is deprecated and + Certification Authorities are encouraged to use the dNSName instead. + + + Matching is performed using the matching rules specified by + . If more than one identity of a given type is present in + the certificate (e.g., more than one dNSName name, a match in any one + of the set is considered acceptable.) Names may contain the wildcard + character * which is considered to match any single domain name + component or component fragment. E.g., *.a.com matches foo.a.com but + not bar.foo.a.com. f*.com matches foo.com but not bar.com. + + + In some cases, the URI is specified as an IP address rather than a + hostname. In this case, the iPAddress subjectAltName must be present + in the certificate and must exactly match the IP in the URI. + + + If the hostname does not match the identity in the certificate, user + oriented clients MUST either notify the user (clients MAY give the + user the opportunity to continue with the connection in any case) or + terminate the connection with a bad certificate error. Automated + clients &MUST; log the error to an appropriate audit log (if available) + and SHOULD terminate the connection (with a bad certificate error). + Automated clients MAY provide a configuration setting that disables + this check, but &MUST; provide a setting which enables it. + + + Note that in many cases the URI itself comes from an untrusted + source. The above-described check provides no protection against + attacks where this source is compromised. For example, if the URI was + obtained by clicking on an HTML page which was itself obtained + without using HTTP/TLS, a man in the middle could have replaced the + URI. In order to prevent this form of attack, users should carefully + examine the certificate presented by the server to determine if it + meets their expectations.
+
+ + Typically, the server has no external knowledge of what the client's + identity ought to be and so checks (other than that the client has a + certificate chain rooted in an appropriate CA) are not possible. If a + server has such knowledge (typically from some source external to + HTTP or TLS) it &SHOULD; check the identity as described above. + +
+
@@ -10368,6 +10438,40 @@ Content-Encoding: gzip + + + +Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile + + + + + + + + + + + + + + + + + + + + + + +This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] + + + + + + + Tags for Identifying Languages From e47fbb16c3c6a7a0a56224b19a900f300100a0e4 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Tue, 3 Sep 2019 12:08:26 +1000 Subject: [PATCH 03/14] Add TLS Connection Closure --- draft-ietf-httpbis-messaging-latest.xml | 47 +++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/draft-ietf-httpbis-messaging-latest.xml b/draft-ietf-httpbis-messaging-latest.xml index 71113a66b..e515d47af 100644 --- a/draft-ietf-httpbis-messaging-latest.xml +++ b/draft-ietf-httpbis-messaging-latest.xml @@ -2009,6 +2009,32 @@ https://www.example.org
+
+ + TLS provides a facility for secure connection closure. When a valid + closure alert is received, an implementation can be assured that no + further data will be received on that connection. TLS + implementations &MUST; initiate an exchange of closure alerts before + closing a connection. A TLS implementation &MAY;, after sending a + closure alert, close the connection without waiting for the peer to + send its closure alert, generating an "incomplete close". Note that + an implementation which does this &MAY; choose to reuse the session. + This &SHOULD; only be done when the application knows (typically + through detecting HTTP message boundaries) that it has received all + the message data that it cares about. + + As specified in , any implementation which receives a + connection close without first receiving a valid closure alert (a + "premature close") &MUST-NOT; reuse that session. Note that a + premature close does not call into question the security of the data + already received, but simply indicates that subsequent data might + have been truncated. Because TLS is oblivious to HTTP + request/response boundaries, it is necessary to examine the HTTP data + itself (specifically the Content-Length header) to determine whether + the truncation occurred inside a message or between messages. + +
+
@@ -2733,6 +2759,27 @@ Upgrade: HTTP/2.0 + + + The Transport Layer Security (TLS) Protocol Version 1.3 + + + + + + This document specifies version 1.3 of the Transport Layer + Security (TLS) protocol. TLS allows client/server applications to + communicate over the Internet in a way that is designed to prevent + eavesdropping, tampering, and message forgery. + This document updates RFCs 5705 and 6066, and obsoletes RFCs + 5077, 5246, and 6961. This document also specifies new requirements + for TLS 1.2 implementations. + + + + + + A Technique for High-Performance Data Compression From b6bab42300e9ff9d4fe8301e73e249b023306b7f Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Tue, 3 Sep 2019 12:16:37 +1000 Subject: [PATCH 04/14] add change notes For #236 --- draft-ietf-httpbis-messaging-latest.xml | 3 ++- draft-ietf-httpbis-semantics-latest.xml | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-messaging-latest.xml b/draft-ietf-httpbis-messaging-latest.xml index e515d47af..1e25bce8c 100644 --- a/draft-ietf-httpbis-messaging-latest.xml +++ b/draft-ietf-httpbis-messaging-latest.xml @@ -2009,7 +2009,7 @@ https://www.example.org
-
+
TLS provides a facility for secure connection closure. When a valid closure alert is received, an implementation can be assured that no @@ -3454,6 +3454,7 @@ Upgrade: HTTP/2.0
  • In and related Sections, move the trailing CRLF from the line grammars into the message format ()
    • +
  • In , add text from RFC2818 ()
diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index eecb94642..9573cf8c9 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -11720,6 +11720,7 @@ This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation
  • In , remove concept of "cacheable methods" in favor of prose ()
  • In , replace "authorize" with "fulfill" ()
  • In , removed a misleading statement about Content-Length (, )
    • +
  • In , add text from RFC2818 ()
    • From 823c36c885b1318d3f1cbe744b4e5c0584f11af5 Mon Sep 17 00:00:00 2001 From: Julian Reschke Date: Tue, 3 Sep 2019 12:18:45 +0100 Subject: [PATCH 05/14] fix XML --- draft-ietf-httpbis-messaging-latest.xml | 5 +++-- draft-ietf-httpbis-semantics-latest.xml | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-messaging-latest.xml b/draft-ietf-httpbis-messaging-latest.xml index 1e25bce8c..ad6dafab5 100644 --- a/draft-ietf-httpbis-messaging-latest.xml +++ b/draft-ietf-httpbis-messaging-latest.xml @@ -2022,7 +2022,8 @@ https://www.example.org This &SHOULD; only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all the message data that it cares about. - + + As specified in , any implementation which receives a connection close without first receiving a valid closure alert (a "premature close") &MUST-NOT; reuse that session. Note that a @@ -2032,7 +2033,7 @@ https://www.example.org request/response boundaries, it is necessary to examine the HTTP data itself (specifically the Content-Length header) to determine whether the truncation occurred inside a message or between messages. - +
    diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index 9573cf8c9..000de49e8 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -9664,7 +9664,7 @@ Content-Encoding: gzip Matching is performed using the matching rules specified by - . If more than one identity of a given type is present in + . If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name From ef0cfe2687c28c34f8438eefeb0479d2ea9bda74 Mon Sep 17 00:00:00 2001 From: Julian Reschke Date: Tue, 3 Sep 2019 12:22:54 +0100 Subject: [PATCH 06/14] ref style --- draft-ietf-httpbis-messaging-latest.xml | 2 +- draft-ietf-httpbis-semantics-latest.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-messaging-latest.xml b/draft-ietf-httpbis-messaging-latest.xml index ad6dafab5..9aa62707c 100644 --- a/draft-ietf-httpbis-messaging-latest.xml +++ b/draft-ietf-httpbis-messaging-latest.xml @@ -3455,7 +3455,7 @@ Upgrade: HTTP/2.0
    • In and related Sections, move the trailing CRLF from the line grammars into the message format ()
      • -
    • In , add text from RFC2818 ()
      • +
    • In , add text from RFC 2818 ()
    diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index 000de49e8..bcad57e0d 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -100,7 +100,7 @@ codes, response header fields, and content negotiation.     - This document obsoletes RFC2818, RFC 7231, RFC 7232, RFC 7233, + This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, and portions of RFC 7230. From 32f92a026083091bd67fa2928f44d9ca25896f48 Mon Sep 17 00:00:00 2001 From: Julian Reschke Date: Tue, 3 Sep 2019 12:26:41 +0100 Subject: [PATCH 07/14] prune reference --- draft-ietf-httpbis-semantics-latest.xml | 36 ++++++------------------- 1 file changed, 8 insertions(+), 28 deletions(-) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index bcad57e0d..8cac8e700 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -10438,38 +10438,18 @@ Content-Encoding: gzip - + - -Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile - - - - - - - - - - - - - - - - - - - + Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile + + + + + + - - -This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] - - - From e43f1e26ab65ec2c560b348e3a254e0659221236 Mon Sep 17 00:00:00 2001 From: Julian Reschke Date: Tue, 3 Sep 2019 12:29:21 +0100 Subject: [PATCH 08/14] ref style --- draft-ietf-httpbis-semantics-latest.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index 8cac8e700..c76e33e19 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -11700,7 +11700,7 @@ Content-Encoding: gzip
  • In , remove concept of "cacheable methods" in favor of prose ()
  • In , replace "authorize" with "fulfill" ()
  • In , removed a misleading statement about Content-Length (, )
    • -
  • In , add text from RFC2818 ()
    • +
  • In , add text from RFC 2818 ()
    • From 065812bbe4f1de65f6d5e30e26e3debdb3dc62e9 Mon Sep 17 00:00:00 2001 From: Julian Reschke Date: Tue, 3 Sep 2019 12:37:01 +0100 Subject: [PATCH 09/14] add "changes from 2818" section --- draft-ietf-httpbis-semantics-latest.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index c76e33e19..eee39c6fd 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -211,6 +211,8 @@ The other parts of RFC 7230 are obsoleted by "HTTP/1.1 Messaging" . This document also obsoletes + RFC 2818 + (see ), RFC 7231 (see ), RFC 7232 @@ -11549,6 +11551,12 @@ Content-Encoding: gzip     +
    + + None yet. + +
    +
    Removed a superfluous requirement about setting Content-Length From 4e77d4a506472030b491d410604e72b7f19cb42d Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Mon, 30 Sep 2019 15:39:47 +1000 Subject: [PATCH 10/14] Ack EKR for 2818. --- draft-ietf-httpbis-semantics-latest.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index 9573cf8c9..e07ee107f 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -11730,12 +11730,13 @@ This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation This edition of the HTTP specification builds on the many contributions that went into RFC 1945, RFC 2068, - RFC 2145, and - RFC 2616, including + RFC 2145, + RFC 2616, and + RFC 2818, including substantial contributions made by the previous authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, - Paul J. Leach, and Yves Lafon. + Paul J. Leach, Eric Rescorla, and Yves Lafon. See for further From ba0ed08b8dd272ac3642013dd783bcdf8f7c329e Mon Sep 17 00:00:00 2001 From: "Roy T. Fielding" Date: Mon, 28 Oct 2019 16:32:59 -0700 Subject: [PATCH 11/14] update generated files --- draft-ietf-httpbis-messaging-latest.html | 142 +++++---- draft-ietf-httpbis-semantics-latest.html | 354 ++++++++++++++--------- httpbis-errata-status.html | 34 +-- outlineALL.html | 42 +-- 4 files changed, 343 insertions(+), 229 deletions(-) diff --git a/draft-ietf-httpbis-messaging-latest.html b/draft-ietf-httpbis-messaging-latest.html index ec0eb49a5..54be11981 100644 --- a/draft-ietf-httpbis-messaging-latest.html +++ b/draft-ietf-httpbis-messaging-latest.html @@ -837,9 +837,10 @@

    Table of Contents

  • 9.5.   Concurrency
  • 9.6.   Failures and Timeouts
  • 9.7.   Tear-down
    • -
  • 9.8.   Upgrade @@ -1425,7 +1426,7 @@

    5. Upgrade standard - Section 9.8 + Section 9.9 @@ -2341,100 +2342,119 @@

    9.7. 

    • -
    -

    9.8. Upgrade

    +
    +

    9.8. TLS Connection Closure

    -

    The "Upgrade" header field is intended to provide a simple mechanism for transitioning - from HTTP/1.1 to some other protocol on the same connection.

    +

    TLS provides a facility for secure connection closure. When a valid closure alert + is received, an implementation can be assured that no further data will be received + on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer + to send its closure alert, generating an "incomplete close". Note that an implementation + which does this MAY choose to reuse the session. This SHOULD only be done when the application knows (typically through detecting HTTP message + boundaries) that it has received all the message data that it cares about.

    +

    As specified in [RFC8446], any implementation which receives a connection close without first receiving a valid + closure alert (a "premature close") MUST NOT reuse that session. Note that a premature close does not call into question the security + of the data already received, but simply indicates that subsequent data might have + been truncated. Because TLS is oblivious to HTTP request/response boundaries, it is + necessary to examine the HTTP data itself (specifically the Content-Length header) + to determine whether the truncation occurred inside a message or between messages.

    +
    +
    +
    +

    9.9. Upgrade

    +
    +

    The "Upgrade" header field is intended to provide a simple mechanism for transitioning + from HTTP/1.1 to some other protocol on the same connection.

    +
    +

    A client MAY send a list of protocol names in the Upgrade header field of a request to invite the server to switch to one or more of the named protocols, in order of descending preference, before sending the final response. A server MAY ignore a received Upgrade header field if it wishes to continue using the current - protocol on that connection. Upgrade cannot be used to insist on a protocol change.

    + protocol on that connection. Upgrade cannot be used to insist on a protocol change.

    - 
      Upgrade          = 1#protocol
+            
-            
    
-               
    Although protocol names are registered with a preferred case, recipients SHOULD use case-insensitive comparison when matching each protocol-name to supported protocols.
    
+            
    
+               
    Although protocol names are registered with a preferred case, recipients SHOULD use case-insensitive comparison when matching each protocol-name to supported protocols.
    
             
    
-            
    
+            
    
                
    A server that sends a 101 (Switching Protocols) response MUST send an Upgrade header field to indicate the new protocol(s) to which the connection
                   is being switched; if multiple protocol layers are being switched, the sender MUST list the protocols in layer-ascending order. A server MUST NOT switch to a protocol that was not indicated by the client in the corresponding request's
                   Upgrade header field. A server MAY choose to ignore the order of preference indicated by the client and select the new
                   protocol(s) based on other factors, such as the nature of the request or the current
-                  load on the server.
    
+                  load on the server.
    
             
    
-            
    
+            
    
                
    A server that sends a 426 (Upgrade Required) response MUST send an Upgrade header field to indicate the acceptable protocols, in order of descending
-                  preference.
    
+                  preference.
    
             
    
-            
    
+            
    
                
    A server MAY send an Upgrade header field in any other response to advertise that it implements
                   support for upgrading to the listed protocols, in order of descending preference,
-                  when appropriate for a future request.
    
+                  when appropriate for a future request.
    
             
    
-            
    
-               
    The following is a hypothetical example sent by a client:
    
+            
    
+               
    The following is a hypothetical example sent by a client:
    
             
    
-            
    GET /hello HTTP/1.1
+            
    GET /hello HTTP/1.1
 Host: www.example.com
 Connection: upgrade
 Upgrade: websocket, IRC/6.9, RTA/x11
 
 
    
-            
    
+            
    
                
    The capabilities and nature of the application-level communication after the protocol
                   change is entirely dependent upon the new protocol(s) chosen. However, immediately
                   after sending the 101 (Switching Protocols) response, the server is expected to continue responding to the original request as
                   if it had received its equivalent within the new protocol (i.e., the server still
                   has an outstanding request to satisfy after the protocol has been changed, and is
-                  expected to do so without requiring the request to be repeated).
    
+                  expected to do so without requiring the request to be repeated).
    
             
    
-            
    
+            
    
                
    For example, if the Upgrade header field is received in a GET request and the server
                   decides to switch protocols, it first responds with a 101 (Switching Protocols) message in HTTP/1.1 and then immediately follows that with the new protocol's equivalent
                   of a response to a GET on the target resource. This allows a connection to be upgraded
                   to protocols with the same semantics as HTTP without the latency cost of an additional
                   round trip. A server MUST NOT switch protocols unless the received message semantics can be honored by the new protocol;
-                  an OPTIONS request can be honored by any protocol.
    
+                  an OPTIONS request can be honored by any protocol.
    
             
    
-            
    
-               
    The following is an example response to the above hypothetical request:
    
+            
    
+               
    The following is an example response to the above hypothetical request:
    
             
    
-            
    HTTP/1.1 101 Switching Protocols
+            
    HTTP/1.1 101 Switching Protocols
 Connection: upgrade
 Upgrade: websocket
 
 [... data stream switches to websocket with an appropriate response
 (as defined by new protocol) to the "GET /hello" request ...]
 
    
-            
    
+            
    
                
    When Upgrade is sent, the sender MUST also send a Connection header field (Section 9.1) that contains an "upgrade" connection option, in order to prevent Upgrade from being
                   accidentally forwarded by intermediaries that might not implement the listed protocols.
-                  A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request.
    
+                  A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request.
    
             
    
-            
    
+            
    
                
    A client cannot begin using an upgraded protocol on the connection until it has completely
                   sent the request message (i.e., the client can't change the protocol it is sending
-                  in the middle of a message). If a server receives both an Upgrade and an Expect header field with the "100-continue" expectation (Section 8.1.1 of [Semantics]), the server MUST send a 100 (Continue) response before sending a 101 (Switching Protocols) response.
    
+                  in the middle of a message). If a server receives both an Upgrade and an Expect header field with the "100-continue" expectation (Section 8.1.1 of [Semantics]), the server MUST send a 100 (Continue) response before sending a 101 (Switching Protocols) response.
    
             
    
-            
    
+            
    
                
    The Upgrade header field only applies to switching protocols on top of the existing
                   connection; it cannot be used to switch the underlying connection (transport) protocol,
                   nor to switch the existing communication to a different connection. For those purposes,
-                  it is more appropriate to use a 3xx (Redirection) response (Section 9.4 of [Semantics]).
    
+                  it is more appropriate to use a 3xx (Redirection) response (Section 9.4 of [Semantics]).
    
             
    
             
    
-               
    9.8.1. Upgrade Protocol Names
    
-               
    
+               
    9.9.1. Upgrade Protocol Names
    
+               
    
                   
    This specification only defines the protocol name "HTTP" for use by the family of
                      Hypertext Transfer Protocols, as defined by the HTTP version rules of Section 3.5 of [Semantics] and future updates to this specification. Additional protocol names ought to be registered
-                     using the registration procedure defined in Section 9.8.2.
    
+                     using the registration procedure defined in Section 9.9.2.
    
                
    
                
    
                   
@@ -2458,20 +2478,20 @@ 
    9.8.1. 
             
             
    
-               
    9.8.2. Upgrade Token Registry
    
-               
    
+               
    9.9.2. Upgrade Token Registry
    
+               
    
                   
    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace
-                     for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at <https://www.iana.org/assignments/http-upgrade-tokens>.
    
+                     for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at <https://www.iana.org/assignments/http-upgrade-tokens>.
    
                
    
-               
    
+               
    
                   
    Each registered protocol name is associated with contact information and an optional
                      set of specifications that details how the connection will be processed after it has
-                     been upgraded.
    
+                     been upgraded.
    
                
    
-               
    
-                  
    Registrations happen on a "First Come First Served" basis (see Section 4.4 of [RFC8126]) and are subject to the following rules:
    
+               
    
+                  
    Registrations happen on a "First Come First Served" basis (see Section 4.4 of [RFC8126]) and are subject to the following rules:
    
                
    
-               
    
+               
    
                   
      
                      
    1. A protocol-name token, once registered, stays registered forever.
      2. 
                      
    2. A protocol-name token is case-insensitive and registered with the preferred case to
@@ -2773,7 +2793,7 @@ 
      12.3. 
             
      12.4. Upgrade Token Registration
      
             
      
-               
      Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> with the registration procedure of Section 9.8.2 and the upgrade token names summarized in the table of Section 9.8.1.
      
+               
      Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> with the registration procedure of Section 9.9.2 and the upgrade token names summarized in the table of Section 9.9.1.
      
             
      
          
    
       
@@ -2809,6 +2829,9 @@ 
    13.1. Normative Refere
                   
    [RFC7405]
    
                   
    Kyzivat, P., “Case-Sensitive String Support in ABNF”, RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
                   
    
+                  
    [RFC8446]
    
+                  
    Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
+                  
    
                   
    [Semantics]
    
                   
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, Internet-Draft draft-ietf-httpbis-semantics-latest (work in progress), October 2019.
                   
    
@@ -3266,7 +3289,7 @@ 
    D.5. D.6. Since draft-ietf-httpbis-messaging-04 📄 🔍
    
                
             
    
@@ -3326,9 +3351,9 @@ 
    Index
  • chunked (Coding Format)  6.1, 6.3
  • chunked (transfer coding)  7.1
    • 
-                     
  • close  5, 5, 7.4, 9.1, 9.1, 9.4.2, 9.7, 9.7, 9.8
    • 
+                     
  • close  5, 5, 7.4, 9.1, 9.1, 9.4.2, 9.7, 9.7, 9.9
  • compress (transfer coding)  7.2
    • 
-                     
  • Connection header field  5, 5, 7.4, 9.1, 9.1, 9.4.2, 9.7, 9.7, 9.8
    • 
+                     
  • Connection header field  5, 5, 7.4, 9.1, 9.1, 9.4.2, 9.7, 9.7, 9.9
  • Content-Length header field  6.2
  • Content-Transfer-Encoding header field  B.5
    • 
@@ -3393,7 +3418,7 @@ 
    Index
  • transfer-coding  7
  • Transfer-Encoding  6.1
  • transfer-parameter  7
    • 
-                           
  • Upgrade  9.8
    • 
+                           
  • Upgrade  9.9
  • VCHAR  1.2
    • 
@@ -3467,15 +3492,16 @@ 
    Index
  • RFC7230  1, 1, 13.2, C.2, D.2
  • RFC7231  13.2, D.2
  • RFC7405  1.2, 13.1
    • 
-                     
  • RFC8126  7.3, 9.8.2, 13.2
                
  • S
    • 
-                  
@@ -723,8 +725,8 @@ 
    Abstract
    
                codes, response header fields, and content negotiation.
    
-            
    This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615,
-               and portions of RFC 7230.
    
+            
    This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538,
+               RFC 7615, and portions of RFC 7230.
    
          
    
@@ -740,7 +742,7 @@ 
    Editorial Note
    
             
    Working Group information can be found at <https://httpwg.org/>; source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>.
    
          
          
    
-            
    The changes in this draft are summarized in Appendix I.7.
    
+            
    The changes in this draft are summarized in Appendix J.7.
    
          
    
       
    
@@ -1059,7 +1061,11 @@ 
    Table of Contents
    
                
             
             
  • 13.   Security Considerations
    • 
-                     
@@ -536,7 +536,7 @@ 
    1. 2014-08-06
                      
    
-                     
@@ -547,7 +547,7 @@ 
    1. 2014-11-09
                      
    
-                     
@@ -558,7 +558,7 @@ 
    1. 2014-11-26
                      
    
-                     
@@ -591,7 +591,7 @@ 
    1. 2015-02-01
                      
    
-                     
@@ -602,7 +602,7 @@ 
    1. 2015-02-01
                      
    
-                     
@@ -613,7 +613,7 @@ 
    1. 2015-05-07
                      
    
-                     
@@ -624,7 +624,7 @@ 
    1. 2015-08-06
                      
    
-                     
@@ -635,7 +635,7 @@ 
    1. 2015-08-22
                      
    
-                     
@@ -646,7 +646,7 @@ 
    1. 2016-04-13
                      
    
-                     
@@ -690,7 +690,7 @@ 
    1. 2016-05-10
                      
    
-                     
@@ -701,7 +701,7 @@ 
    1. 2016-06-09
                      
    
-                     
@@ -745,7 +745,7 @@ 
    1. 2016-12-16
                      
    
-                     
@@ -756,7 +756,7 @@ 
    1. 2017-10-20
                      
    
-                     
@@ -789,7 +789,7 @@ 
    1. 2018-02-07
                      
    
-                     
@@ -811,7 +811,7 @@ 
    1. 2018-08-21
                      
    
-                     
@@ -822,7 +822,7 @@ 
    1. 2018-11-02
                      
    
-                     
diff --git a/outlineALL.html b/outlineALL.html
index fa796bf9d..c8ea0d7ae 100644
--- a/outlineALL.html
+++ b/outlineALL.html
@@ -685,7 +685,11 @@ 
    HTTP Semantics
  • 13.   Security Considerations
      
-                     
    • 13.1.   Establishing Authority
      • 
+                     
    • 13.1.   Establishing Authority
+                     
      • 
                      
    • 13.2.   Risks of Intermediaries
      • 
                      
    • 13.3.   Attacks Based on File and Path Names
      • 
                      
    • 13.4.   Attacks Based on Command, Code, or Query Injection
      • 
@@ -726,20 +730,21 @@ 
      HTTP Semantics
      
                
                
    • A.   Collected ABNF
      • 
                
    • B.   Changes from RFC 7230
      • 
-               
    • C.   Changes from RFC 7231
      • 
-               
    • D.   Changes from RFC 7232
      • 
-               
    • E.   Changes from RFC 7233
      • 
-               
    • F.   Changes from RFC 7235
      • 
-               
    • G.   Changes from RFC 7538
      • 
-               
    • H.   Changes from RFC 7615
      • 
-               
    • I.   Change Log
             
      • 
             
    • 13.   Security Considerations
        
-                  
      • 13.1.   Establishing Authority
-                  
        • 
+                  
      • 13.1.   Establishing Authority
        • 
                   
      • 13.2.   Risks of Intermediaries
        • 
                   
      • 13.3.   Attacks Based on File and Path Names
        • 
                   
      • 13.4.   Attacks Based on Command, Code, or Query Injection
        • 
@@ -1628,10 +1624,66 @@ 
        2.5.2. [RFC6265], can allow information set by one service to impact communication with other services
                      within a matching group of host domains.
        
                
-               
        
-                  
        The process for authoritative access to an "https" identified resource is defined
-                     in Section 13.1.1.
        
-               
        
+               
        
+                  
        2.5.2.1. Identifying HTTPS Servers
        
+                  
        
+                     
        In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence,
+                        the hostname for the server is known to the client. If the hostname is available,
+                        the client MUST check it against the server's identity as presented in the server's Certificate message,
+                        in order to prevent man-in-the-middle attacks.
        
+                  
        
+                  
        
+                     
        If the client has external information as to the expected identity of the server,
+                        the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and
+                        hostname are dynamic but the client knows the certificate that the server will present.)
+                        In such cases, it is important to narrow the scope of acceptable certificates as much
+                        as possible in order to prevent man in the middle attacks. In special cases, it may
+                        be appropriate for the client to simply ignore the server's identity, but it must
+                        be understood that this leaves the connection open to active attack.
        
+                  
        
+                  
        
+                     
        If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject
+                        field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated
+                        and Certification Authorities are encouraged to use the dNSName instead.
        
+                  
        
+                  
        
+                     
        Matching is performed using the matching rules specified by [RFC5280]. If more than one identity of a given type is present in the certificate (e.g., more
+                        than one dNSName name, a match in any one of the set is considered acceptable.) Names
+                        may contain the wildcard character * which is considered to match any single domain
+                        name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com.
+                        f*.com matches foo.com but not bar.com.
        
+                  
        
+                  
        
+                     
        In some cases, the URI is specified as an IP address rather than a hostname. In this
+                        case, the iPAddress subjectAltName must be present in the certificate and must exactly
+                        match the IP in the URI.
        
+                  
        
+                  
        
+                     
        If the hostname does not match the identity in the certificate, user oriented clients
+                        MUST either notify the user (clients MAY give the user the opportunity to continue
+                        with the connection in any case) or terminate the connection with a bad certificate
+                        error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the
+                        connection (with a bad certificate error). Automated clients MAY provide a configuration
+                        setting that disables this check, but MUST provide a setting which enables it.
        
+                  
        
+                  
        
+                     
        Note that in many cases the URI itself comes from an untrusted source. The above-described
+                        check provides no protection against attacks where this source is compromised. For
+                        example, if the URI was obtained by clicking on an HTML page which was itself obtained
+                        without using HTTP/TLS, a man in the middle could have replaced the URI. In order
+                        to prevent this form of attack, users should carefully examine the certificate presented
+                        by the server to determine if it meets their expectations.
        
+                  
        
+               
        
+               
        
+                  
        2.5.2.2. Identifying HTTPS Clients
        
+                  
        
+                     
        Typically, the server has no external knowledge of what the client's identity ought
+                        to be and so checks (other than that the client has a certificate chain rooted in
+                        an appropriate CA) are not possible. If a server has such knowledge (typically from
+                        some source external to HTTP or TLS) it SHOULD check the identity as described above.
        
+                  
        
+               
        
             
             
        
                
        2.5.3. Fragment Identifiers on http(s) URI References
        
@@ -8902,90 +8954,29 @@ 
        13.1. Section 2.5.2) is intended to prevent (or at least reveal) many of these potential attacks on establishing
                   authority, provided that the negotiated TLS connection is secured and the client properly
                   verifies that the communicating server's identity matches the target URI's authority
-                  component, as described below. Correctly implementing such verification can be difficult
-                  (see [Georgiev]).
        
-            
-            
        
-               
        13.1.1. Identifying HTTPS Servers
        
-               
        
-                  
        In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence,
-                     the hostname for the server is known to the client. If the hostname is available,
-                     the client MUST check it against the server's identity as presented in the server's Certificate message,
-                     in order to prevent man-in-the-middle attacks.
        
-               
        
-               
        
-                  
        If the client has external information as to the expected identity of the server,
-                     the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and
-                     hostname are dynamic but the client knows the certificate that the server will present.)
-                     In such cases, it is important to narrow the scope of acceptable certificates as much
-                     as possible in order to prevent man in the middle attacks. In special cases, it may
-                     be appropriate for the client to simply ignore the server's identity, but it must
-                     be understood that this leaves the connection open to active attack.
        
-               
        
-               
        
-                  
        If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject
-                     field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated
-                     and Certification Authorities are encouraged to use the dNSName instead.
        
-               
        
-               
        
-                  
        Matching is performed using the matching rules specified by [RFC5280]. If more than one identity of a given type is present in the certificate (e.g., more
-                     than one dNSName name, a match in any one of the set is considered acceptable.) Names
-                     may contain the wildcard character * which is considered to match any single domain
-                     name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com.
-                     f*.com matches foo.com but not bar.com.
        
-               
        
-               
        
-                  
        In some cases, the URI is specified as an IP address rather than a hostname. In this
-                     case, the iPAddress subjectAltName must be present in the certificate and must exactly
-                     match the IP in the URI.
        
-               
        
-               
        
-                  
        If the hostname does not match the identity in the certificate, user oriented clients
-                     MUST either notify the user (clients MAY give the user the opportunity to continue
-                     with the connection in any case) or terminate the connection with a bad certificate
-                     error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the
-                     connection (with a bad certificate error). Automated clients MAY provide a configuration
-                     setting that disables this check, but MUST provide a setting which enables it.
        
-               
        
-               
        
-                  
        Note that in many cases the URI itself comes from an untrusted source. The above-described
-                     check provides no protection against attacks where this source is compromised. For
-                     example, if the URI was obtained by clicking on an HTML page which was itself obtained
-                     without using HTTP/TLS, a man in the middle could have replaced the URI. In order
-                     to prevent this form of attack, users should carefully examine the certificate presented
-                     by the server to determine if it meets their expectations.
        
-               
        
-               
        
-                  
        Authority for a given origin server can be delegated through protocol extensions;
-                     for example, [RFC7838]. Likewise, the set of servers that a connection is considered authoritative for can
-                     be changed with a protocol extension like [RFC8336].
        
-               
        
-               
        
-                  
        Providing a response from a non-authoritative source, such as a shared proxy cache,
-                     is often useful to improve performance and availability, but only to the extent that
-                     the source can be trusted or the distrusted response can be safely used.
        
-               
        
-               
        
-                  
        Unfortunately, communicating authority to users can be difficult. For example, phishing is an attack on the user's perception of authority, where that perception can be misled
-                     by presenting similar branding in hypertext, possibly aided by userinfo obfuscating
-                     the authority component (see Section 2.5.1). User agents can reduce the impact of phishing attacks by enabling users to easily
-                     inspect a target URI prior to making an action, by prominently distinguishing (or
-                     rejecting) userinfo when present, and by not sending stored credentials and cookies
-                     when the referring document is from an unknown or untrusted source.
        
-               
        
-               
        
-                  
        See also [RFC6454] for a formalisation of authority that is used by many clients.
        
-               
        
-            
        
-            
        
-               
        13.1.2. Identifying HTTPS Clients
        
-               
        
-                  
        Typically, the server has no external knowledge of what the client's identity ought
-                     to be and so checks (other than that the client has a certificate chain rooted in
-                     an appropriate CA) are not possible. If a server has such knowledge (typically from
-                     some source external to HTTP or TLS) it SHOULD check the identity as described above.
        
-               
        
-            
        
+                  component (Section 2.5.2.1). Correctly implementing such verification can be difficult (see [Georgiev]).
        
+            
+            
        
+               
        Authority for a given origin server can be delegated through protocol extensions;
+                  for example, [RFC7838]. Likewise, the set of servers that a connection is considered authoritative for can
+                  be changed with a protocol extension like [RFC8336].
        
+            
        
+            
        
+               
        Providing a response from a non-authoritative source, such as a shared proxy cache,
+                  is often useful to improve performance and availability, but only to the extent that
+                  the source can be trusted or the distrusted response can be safely used.
        
+            
        
+            
        
+               
        Unfortunately, communicating authority to users can be difficult. For example, phishing is an attack on the user's perception of authority, where that perception can be misled
+                  by presenting similar branding in hypertext, possibly aided by userinfo obfuscating
+                  the authority component (see Section 2.5.1). User agents can reduce the impact of phishing attacks by enabling users to easily
+                  inspect a target URI prior to making an action, by prominently distinguishing (or
+                  rejecting) userinfo when present, and by not sending stored credentials and cookies
+                  when the referring document is from an unknown or untrusted source.
        
+            
        
+            
        
+               
        See also [RFC6454] for a formalisation of authority that is used by many clients.
        
+            
        
          
        
          
        
             
        13.2. Risks of Intermediaries
        
@@ -10741,7 +10732,7 @@ 
        Index
        
                         
      
                      
      • 
                      
    • RFC5246  2.2, 2.5.2, 7.3.6, 13.14.1, 15.2
      • 
-                     
    • RFC5280  13.1.1, 15.1
      • 
+                     
    • RFC5280  2.5.2.1, 15.1
      • 
                      
    • RFC5322  5.5.1, 8.6.1, 8.6.1, 10.1.1.1, 10.1.1.1, 10.1.1.1, 10.1.1.2, 15.2, A
                
      • 
                
    • S
        
diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml
index ecf5d25fb..41908466a 100644
--- a/draft-ietf-httpbis-semantics-latest.xml
+++ b/draft-ietf-httpbis-semantics-latest.xml
@@ -826,12 +826,80 @@ Content-Type: text/plain
    set by one service to impact communication with other services
    within a matching group of host domains.
 
+
+
        
+
+   In general, HTTP/TLS requests are generated by dereferencing a URI.
+   As a consequence, the hostname for the server is known to the client.
+   If the hostname is available, the client &MUST; check it against the
+   server's identity as presented in the server's Certificate message,
+   in order to prevent man-in-the-middle attacks.
+
+
+   If the client has external information as to the expected identity of
+   the server, the hostname check &MAY; be omitted. (For instance, a
+   client may be connecting to a machine whose address and hostname are
+   dynamic but the client knows the certificate that the server will
+   present.) In such cases, it is important to narrow the scope of
+   acceptable certificates as much as possible in order to prevent man
+   in the middle attacks.  In special cases, it may be appropriate for
+   the client to simply ignore the server's identity, but it must be
+   understood that this leaves the connection open to active attack.
+
+
+   If a subjectAltName extension of type dNSName is present, that &MUST;
+   be used as the identity. Otherwise, the (most specific) Common Name
+   field in the Subject field of the certificate &MUST; be used. Although
+   the use of the Common Name is existing practice, it is deprecated and
+   Certification Authorities are encouraged to use the dNSName instead.
+
 
-   The process for authoritative access to an "https" identified
-   resource is defined in .
+   Matching is performed using the matching rules specified by
+   .  If more than one identity of a given type is present in
+   the certificate (e.g., more than one dNSName name, a match in any one
+   of the set is considered acceptable.) Names may contain the wildcard
+   character * which is considered to match any single domain name
+   component or component fragment. E.g., *.a.com matches foo.a.com but
+   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
+
+
+   In some cases, the URI is specified as an IP address rather than a
+   hostname. In this case, the iPAddress subjectAltName must be present
+   in the certificate and must exactly match the IP in the URI.
+
+
+   If the hostname does not match the identity in the certificate, user
+   oriented clients MUST either notify the user (clients MAY give the
+   user the opportunity to continue with the connection in any case) or
+   terminate the connection with a bad certificate error. Automated
+   clients &MUST; log the error to an appropriate audit log (if available)
+   and SHOULD terminate the connection (with a bad certificate error).
+   Automated clients MAY provide a configuration setting that disables
+   this check, but &MUST; provide a setting which enables it.
+
+
+   Note that in many cases the URI itself comes from an untrusted
+   source. The above-described check provides no protection against
+   attacks where this source is compromised. For example, if the URI was
+   obtained by clicking on an HTML page which was itself obtained
+   without using HTTP/TLS, a man in the middle could have replaced the
+   URI.  In order to prevent this form of attack, users should carefully
+   examine the certificate presented by the server to determine if it
+   meets their expectations.
 
 
        
 
+
        
+
+   Typically, the server has no external knowledge of what the client's
+   identity ought to be and so checks (other than that the client has a
+   certificate chain rooted in an appropriate CA) are not possible. If a
+   server has such knowledge (typically from some source external to
+   HTTP or TLS) it &SHOULD; check the identity as described above.
+
+
        
+
+
 
        
   
 
@@ -9792,73 +9860,13 @@ Content-Encoding: gzip
    an "http" URI is vulnerable to attacks on Internet Protocol routing.
 
 
-   The "https" scheme () is intended to prevent (or
-   at least reveal) many of these potential attacks on establishing
-   authority, provided that the negotiated TLS connection is secured and the
-   client properly verifies that the communicating server's identity matches
-   the target URI's authority component, as described below. Correctly
-   implementing such verification can be difficult (see ).
-
-
        
-
-   In general, HTTP/TLS requests are generated by dereferencing a URI.
-   As a consequence, the hostname for the server is known to the client.
-   If the hostname is available, the client &MUST; check it against the
-   server's identity as presented in the server's Certificate message,
-   in order to prevent man-in-the-middle attacks.
-
-
-   If the client has external information as to the expected identity of
-   the server, the hostname check &MAY; be omitted. (For instance, a
-   client may be connecting to a machine whose address and hostname are
-   dynamic but the client knows the certificate that the server will
-   present.) In such cases, it is important to narrow the scope of
-   acceptable certificates as much as possible in order to prevent man
-   in the middle attacks.  In special cases, it may be appropriate for
-   the client to simply ignore the server's identity, but it must be
-   understood that this leaves the connection open to active attack.
-
-
-   If a subjectAltName extension of type dNSName is present, that &MUST;
-   be used as the identity. Otherwise, the (most specific) Common Name
-   field in the Subject field of the certificate &MUST; be used. Although
-   the use of the Common Name is existing practice, it is deprecated and
-   Certification Authorities are encouraged to use the dNSName instead.
-
-
-   Matching is performed using the matching rules specified by
-   .  If more than one identity of a given type is present in
-   the certificate (e.g., more than one dNSName name, a match in any one
-   of the set is considered acceptable.) Names may contain the wildcard
-   character * which is considered to match any single domain name
-   component or component fragment. E.g., *.a.com matches foo.a.com but
-   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
-
-
-   In some cases, the URI is specified as an IP address rather than a
-   hostname. In this case, the iPAddress subjectAltName must be present
-   in the certificate and must exactly match the IP in the URI.
-
-
-   If the hostname does not match the identity in the certificate, user
-   oriented clients MUST either notify the user (clients MAY give the
-   user the opportunity to continue with the connection in any case) or
-   terminate the connection with a bad certificate error. Automated
-   clients &MUST; log the error to an appropriate audit log (if available)
-   and SHOULD terminate the connection (with a bad certificate error).
-   Automated clients MAY provide a configuration setting that disables
-   this check, but &MUST; provide a setting which enables it.
-
-
-   Note that in many cases the URI itself comes from an untrusted
-   source. The above-described check provides no protection against
-   attacks where this source is compromised. For example, if the URI was
-   obtained by clicking on an HTML page which was itself obtained
-   without using HTTP/TLS, a man in the middle could have replaced the
-   URI.  In order to prevent this form of attack, users should carefully
-   examine the certificate presented by the server to determine if it
-   meets their expectations.
+   The "https" scheme () is intended to prevent
+   (or at least reveal) many of these potential attacks on establishing
+   authority, provided that the negotiated TLS connection is secured and
+   the client properly verifies that the communicating server's identity
+   matches the target URI's authority component
+   (). Correctly implementing such verification
+   can be difficult (see ).
 
 
    Authority for a given origin server can be delegated through protocol
@@ -9888,17 +9896,6 @@ Content-Encoding: gzip
   See also  for a formalisation of authority that is
   used by many clients.
 
-
-
        
-
        
-
-   Typically, the server has no external knowledge of what the client's
-   identity ought to be and so checks (other than that the client has a
-   certificate chain rooted in an appropriate CA) are not possible. If a
-   server has such knowledge (typically from some source external to
-   HTTP or TLS) it &SHOULD; check the identity as described above.
-
-
        
 
        
 
 
        

From dc0cd2549d6958b603ba5e3feb3214a34cc324ec Mon Sep 17 00:00:00 2001
From: "Roy T. Fielding" 
Date: Mon, 28 Oct 2019 18:15:39 -0700
Subject: [PATCH 13/14] include initiation section from RFC2818 and update TLS
 refs

---
 draft-ietf-httpbis-semantics-latest.html | 70 ++++++++++++++----------
 draft-ietf-httpbis-semantics-latest.xml  | 37 +++++++++----
 2 files changed, 68 insertions(+), 39 deletions(-)

diff --git a/draft-ietf-httpbis-semantics-latest.html b/draft-ietf-httpbis-semantics-latest.html
index f12412f8e..b2ed51ae2 100644
--- a/draft-ietf-httpbis-semantics-latest.html
+++ b/draft-ietf-httpbis-semantics-latest.html
@@ -1404,7 +1404,7 @@ 
        2.2. [RFC5246]) is used to establish confidential communication through a shared firewall proxy.
        
+                  through an intermediary, such as when Transport Layer Security (TLS, [RFC8446]) is used to establish confidential communication through a shared firewall proxy.
        
             
             
        
                
        The above categories for intermediary only consider those acting as participants in
@@ -1605,7 +1605,7 @@ 
        2.5.2. 
                   
        The "https" URI scheme is hereby defined for the purpose of minting identifiers according
                      to their association with the hierarchical namespace governed by a potential HTTP
-                     origin server listening to a given TCP port for TLS-secured connections ([RFC5246]).
        
+                     origin server listening to a given TCP port for TLS-secured connections ([RFC8446]).
        
                
        
                
        
                   
        All of the requirements listed above for the "http" scheme are also requirements for
@@ -1624,64 +1624,78 @@ 
        2.5.2. [RFC6265], can allow information set by one service to impact communication with other services
                      within a matching group of host domains.
        
                
        
-               
        
-                  
        2.5.2.1. Identifying HTTPS Servers
        
+               
        
+                  
        2.5.2.1. Initiating HTTP Over TLS
        
                   
        
+                     
        Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would
+                        use HTTP over TCP.
        
+                  
        
+                  
        
+                     
        The agent acting as the HTTP client should also act as the TLS client. It should initiate
+                        a connection to the server on the appropriate port and then send the TLS ClientHello
+                        to begin the TLS handshake. When the TLS handshake has finished. The client may then
+                        initiate the first HTTP request. All HTTP data MUST be sent as TLS "application data".
+                        Normal HTTP behavior, including retained connections should be followed.
        
+                  
        
+               
        
+               
        
+                  
        2.5.2.2. Identifying HTTPS Servers
        
+                  
        
                      
        In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence,
                         the hostname for the server is known to the client. If the hostname is available,
                         the client MUST check it against the server's identity as presented in the server's Certificate message,
-                        in order to prevent man-in-the-middle attacks.
        
+                        in order to prevent man-in-the-middle attacks.
        
                   
        
-                  
        
+                  
        
                      
        If the client has external information as to the expected identity of the server,
                         the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and
                         hostname are dynamic but the client knows the certificate that the server will present.)
                         In such cases, it is important to narrow the scope of acceptable certificates as much
                         as possible in order to prevent man in the middle attacks. In special cases, it may
                         be appropriate for the client to simply ignore the server's identity, but it must
-                        be understood that this leaves the connection open to active attack.
        
+                        be understood that this leaves the connection open to active attack.
        
                   
        
-                  
        
+                  
        
                      
        If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject
                         field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated
-                        and Certification Authorities are encouraged to use the dNSName instead.
        
+                        and Certification Authorities are encouraged to use the dNSName instead.
        
                   
        
-                  
        
+                  
        
                      
        Matching is performed using the matching rules specified by [RFC5280]. If more than one identity of a given type is present in the certificate (e.g., more
                         than one dNSName name, a match in any one of the set is considered acceptable.) Names
                         may contain the wildcard character * which is considered to match any single domain
                         name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com.
-                        f*.com matches foo.com but not bar.com.
        
+                        f*.com matches foo.com but not bar.com.
        
                   
        
-                  
        
+                  
        
                      
        In some cases, the URI is specified as an IP address rather than a hostname. In this
                         case, the iPAddress subjectAltName must be present in the certificate and must exactly
-                        match the IP in the URI.
        
+                        match the IP in the URI.
        
                   
        
-                  
        
+                  
        
                      
        If the hostname does not match the identity in the certificate, user oriented clients
                         MUST either notify the user (clients MAY give the user the opportunity to continue
                         with the connection in any case) or terminate the connection with a bad certificate
                         error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the
                         connection (with a bad certificate error). Automated clients MAY provide a configuration
-                        setting that disables this check, but MUST provide a setting which enables it.
        
+                        setting that disables this check, but MUST provide a setting which enables it.
        
                   
        
-                  
        
+                  
        
                      
        Note that in many cases the URI itself comes from an untrusted source. The above-described
                         check provides no protection against attacks where this source is compromised. For
                         example, if the URI was obtained by clicking on an HTML page which was itself obtained
                         without using HTTP/TLS, a man in the middle could have replaced the URI. In order
                         to prevent this form of attack, users should carefully examine the certificate presented
-                        by the server to determine if it meets their expectations.
        
+                        by the server to determine if it meets their expectations.
        
                   
        
                
        
                
        
-                  
        2.5.2.2. Identifying HTTPS Clients
        
-                  
        
+                  
        2.5.2.3. Identifying HTTPS Clients
        
+                  
        
                      
        Typically, the server has no external knowledge of what the client's identity ought
                         to be and so checks (other than that the client has a certificate chain rooted in
                         an appropriate CA) are not possible. If a server has such knowledge (typically from
-                        some source external to HTTP or TLS) it SHOULD check the identity as described above.
        
+                        some source external to HTTP or TLS) it SHOULD check the identity as described above.
        
                   
        
                
        
             
        
@@ -4682,7 +4696,7 @@ 
        7.3.6. [RFC5246]).
        
+                     one or more proxies, which can then be secured using TLS (Transport Layer Security, [RFC8446]).
        
                
                
        
                   
        CONNECT is intended only for use in requests to a proxy. An origin server that receives
@@ -8954,7 +8968,7 @@ 
        13.1. Section 2.5.2) is intended to prevent (or at least reveal) many of these potential attacks on establishing
                   authority, provided that the negotiated TLS connection is secured and the client properly
                   verifies that the communicating server's identity matches the target URI's authority
-                  component (Section 2.5.2.1). Correctly implementing such verification can be difficult (see [Georgiev]).
        
+                  component (Section 2.5.2.2). Correctly implementing such verification can be difficult (see [Georgiev]).
        
             
        
             
        
                
        Authority for a given origin server can be delegated through protocol extensions;
@@ -9277,7 +9291,7 @@ 
        13.14.1. [RFC5246]) prior to exchanging any credentials.
        
+                     Layer Security", [RFC8446]) prior to exchanging any credentials.
        
                
        
             
        
             
        
@@ -9611,9 +9625,6 @@ 
        15.2. Informative Refe
                   
        [RFC4918]
        
                   
        Dusseault, L., Ed., “HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)”, RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.
                   
        
-                  
        [RFC5246]
        
-                  
        Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
-                  
        
                   
        [RFC5322]
        
                   
        Resnick, P., “Internet Message Format”, RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
                   
        
@@ -9680,6 +9691,9 @@ 
        15.2. Informative Refe
                   
        [RFC8336]
        
                   
        Nottingham, M. and E. Nygren, “The ORIGIN HTTP/2 Frame”, RFC 8336, DOI 10.17487/RFC8336, March 2018, <https://www.rfc-editor.org/info/rfc8336>.
                   
        
+                  
        [RFC8446]
        
+                  
        Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
+                  
        
                   
        [Sniffing]
        
                   
        WHATWG, “MIME Sniffing”, <https://mimesniff.spec.whatwg.org>.
                   
        
@@ -10731,8 +10745,7 @@ 
        Index
        
                            
      • Appendix B.1  1.2
        • 
                         
      
                      
      • 
-                     
    • RFC5246  2.2, 2.5.2, 7.3.6, 13.14.1, 15.2
      • 
-                     
    • RFC5280  2.5.2.1, 15.1
      • 
+                     
    • RFC5280  2.5.2.2, 15.1
      • 
                      
    • RFC5322  5.5.1, 8.6.1, 8.6.1, 10.1.1.1, 10.1.1.1, 10.1.1.1, 10.1.1.2, 15.2, A
                
      • 
                
    • S
        
diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml
index 41908466a..62d32bb29 100644
--- a/draft-ietf-httpbis-semantics-latest.xml
+++ b/draft-ietf-httpbis-semantics-latest.xml
@@ -524,7 +524,7 @@ Content-Type: text/plain
    have been initiated by an HTTP request. A tunnel ceases to exist when
    both ends of the relayed connection are closed. Tunnels are used to
    extend a virtual connection through an intermediary, such as when
-   Transport Layer Security (TLS, ) is used to
+   Transport Layer Security (TLS, ) is used to
    establish confidential communication through a shared firewall proxy.
 
 
@@ -800,7 +800,7 @@ Content-Type: text/plain
    The "https" URI scheme is hereby defined for the purpose of minting
    identifiers according to their association with the hierarchical
    namespace governed by a potential HTTP origin server listening to a
-   given TCP port for TLS-secured connections ().
+   given TCP port for TLS-secured connections ().
 
 
    All of the requirements listed above for the "http" scheme are also
@@ -827,6 +827,22 @@ Content-Type: text/plain
    within a matching group of host domains.
 
 
+
        
+
+   Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
+   precisely as you would use HTTP over TCP.
+
+
+   The agent acting as the HTTP client should also act as the TLS
+   client.  It should initiate a connection to the server on the
+   appropriate port and then send the TLS ClientHello to begin the TLS
+   handshake. When the TLS handshake has finished. The client may then
+   initiate the first HTTP request.  All HTTP data MUST be sent as TLS
+   "application data".  Normal HTTP behavior, including retained
+   connections should be followed.
+
+
        
+
 
        
 
    In general, HTTP/TLS requests are generated by dereferencing a URI.
@@ -4514,7 +4530,7 @@ Content-Range: exampleunit 11.2-14.3/25
    packets, in both directions, until the tunnel is closed.
    Tunnels are commonly used to create an end-to-end virtual connection,
    through one or more proxies, which can then be secured using TLS
-   (Transport Layer Security, ).
+   (Transport Layer Security, ).
 
 
    CONNECT is intended only for use in requests to a proxy.
@@ -10244,7 +10260,7 @@ Content-Encoding: gzip
    properly secured in accordance with the nature of the authentication
    scheme used. For example, services that depend on individual user
    authentication often require a connection to be secured with TLS
-   ("Transport Layer Security", ) prior to exchanging
+   ("Transport Layer Security", ) prior to exchanging
    any credentials.
 
 
        
@@ -11157,16 +11173,15 @@ Content-Encoding: gzip
   
 
 
-
+
    
-      The Transport Layer Security (TLS) Protocol Version 1.2
-      
-      
-         RTFM, Inc.
+      The Transport Layer Security (TLS) Protocol Version 1.3
+      
+         
       
-      
+      
    
-   
+   
 
 
 

From fe4dfcdafb91bab96a81459602295a40c5cd187a Mon Sep 17 00:00:00 2001
From: "Roy T. Fielding" 
Date: Sat, 2 Nov 2019 17:47:02 -0700
Subject: [PATCH 14/14] for completeness, include the redundant RFC2818
 requirements that are already summarized, to be deleted later

---
 draft-ietf-httpbis-messaging-latest.html | 21 ++++++++++++++++++
 draft-ietf-httpbis-messaging-latest.xml  | 27 ++++++++++++++++++++++++
 draft-ietf-httpbis-semantics-latest.html |  4 ++--
 outlineALL.html                          |  6 +-----
 4 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/draft-ietf-httpbis-messaging-latest.html b/draft-ietf-httpbis-messaging-latest.html
index 91bceac13..aaa009778 100644
--- a/draft-ietf-httpbis-messaging-latest.html
+++ b/draft-ietf-httpbis-messaging-latest.html
@@ -2360,6 +2360,27 @@ 
        9.8. 
        
             
+            
        
+               
        When encountering a premature close, a client SHOULD treat as completed all requests for which it has received as much data as specified
+                  in the Content-Length header.
        
+            
        
+            
        
+               
        A client detecting an incomplete close SHOULD recover gracefully. It MAY resume a TLS session closed in this fashion.
        
+            
        
+            
        
+               
        Clients MUST send a closure alert before closing the connection. Clients which are unprepared to
+                  receive any more data MAY choose not to wait for the server's closure alert and simply close the connection,
+                  thus generating an incomplete close on the server side.
        
+            
        
+            
        
+               
        Servers SHOULD be prepared to receive an incomplete close from the client, since the client can often
+                  determine when the end of server data is. Servers SHOULD be willing to resume TLS sessions closed in this fashion.
        
+            
        
+            
        
+               
        Servers MUST attempt to initiate an exchange of closure alerts with the client before closing the
+                  connection. Servers MAY close the connection after sending the closure alert, thus generating an incomplete
+                  close on the client side.
        
+            
        
          
          
        
             
        9.9. Upgrade
        
diff --git a/draft-ietf-httpbis-messaging-latest.xml b/draft-ietf-httpbis-messaging-latest.xml
index cd9dc8124..4cafc2de9 100644
--- a/draft-ietf-httpbis-messaging-latest.xml
+++ b/draft-ietf-httpbis-messaging-latest.xml
@@ -1996,6 +1996,33 @@ https://www.example.org
    itself (specifically the Content-Length header) to determine whether
    the truncation occurred inside a message or between messages.
 
+
+   When encountering a premature close, a client &SHOULD; treat as completed
+   all requests for which it has received as much data as specified in the
+   Content-Length header.
+
+
+   A client detecting an incomplete close &SHOULD; recover gracefully.  It
+   &MAY; resume a TLS session closed in this fashion.
+
+
+   Clients &MUST; send a closure alert before closing the connection.
+   Clients which are unprepared to receive any more data &MAY; choose not
+   to wait for the server's closure alert and simply close the
+   connection, thus generating an incomplete close on the server side.
+
+
+   Servers &SHOULD; be prepared to receive an incomplete close from the client,
+   since the client can often determine when the end of server data is.
+   Servers &SHOULD; be willing to resume TLS sessions closed in this
+   fashion.
+
+
+   Servers &MUST; attempt to initiate an exchange of closure alerts with
+   the client before closing the connection. Servers &MAY; close the
+   connection after sending the closure alert, thus generating an
+   incomplete close on the client side.
+
 
        
 
 
        
diff --git a/draft-ietf-httpbis-semantics-latest.html b/draft-ietf-httpbis-semantics-latest.html
index 79c67f9b4..b0230a75c 100644
--- a/draft-ietf-httpbis-semantics-latest.html
+++ b/draft-ietf-httpbis-semantics-latest.html
@@ -9971,8 +9971,8 @@ 
        Appendix D. 
             
        Removed a superfluous requirement about setting Content-Length from the description of the OPTIONS method. (Section 7.3.7)
        
          
-         
        
-            
        Minimum URI lengths to be supported by implementations are now recommended. (Section 2.5)
        
+         
        
+            
        Minimum URI lengths to be supported by implementations are now recommended. (Section 2.5)
        
          
        
       
        
       
        
diff --git a/outlineALL.html b/outlineALL.html
index c8ea0d7ae..76005265e 100644
--- a/outlineALL.html
+++ b/outlineALL.html
@@ -685,11 +685,7 @@ 
        HTTP Semantics
        
                   
      
                
      • 
                
    • 13.   Security Considerations
    • 
             
          
                      
                      
                      
                      
                      
                      
                   
                            
                            
                            
                            
                         
                      
                      
                      
                      
                
    Adobe
                
    
                
    Obsoletes: 7230, 7231, 7232, 7233, 7235, 7538, 7615 (if approved)
+                  Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615 (if approved)
                   
                   M. Nottingham, Editor
                
    
          
          
       
       
       
    Verified
                      Daisuke Miyakawa#94 (see [Messaging], Appendix D.3, [Semantics], Appendix I.3)
+                     #94 (see [Messaging], Appendix D.3, [Semantics], Appendix J.3)
                      
                   
    
                   
    Held for Document Update
                      Martin Thomson#84 (see [Semantics], Appendix I.3)
+                     #84 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Verified
                      Simon Schueppel#104 (see [Semantics], Appendix I.3)
+                     #104 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Held for Document Update
                      Simon Schueppel#19 (see [Messaging], Appendix D.6, [Semantics], Appendix I.6)
+                     #19 (see [Messaging], Appendix D.6, [Semantics], Appendix J.6)
                      
                   
    
                   
    Verified
                      Bjoern Hoehrmann#103 (see [Semantics], Appendix I.4)
+                     #103 (see [Semantics], Appendix J.4)
                      
                   
    
                   
    Verified
                      Bjoern Hoehrmann#103 (see [Semantics], Appendix I.4)
+                     #103 (see [Semantics], Appendix J.4)
                      
                   
    
                   
    Held for Document Update
                      Tim#102 (see [Semantics], Appendix I.3)
+                     #102 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Held for Document Update
                      Aron Duby#85 (see [Semantics], Appendix I.3)
+                     #85 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Held for Document Update
                      Attila Gulyas#98 (see [Semantics], Appendix I.3)
+                     #98 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Verified
                      Amichai Rothman#83 (see [Semantics], Appendix I.3)
+                     #83 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Held for Document Update
                      Daurnimator#100 (see [Semantics], Appendix I.4)
+                     #100 (see [Semantics], Appendix J.4)
                      
                   
    
                   
    Verified
                      Julian Reschke#86 (see [Semantics], Appendix I.3)
+                     #86 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Held for Document Update
                      Mike Bishop#81 (see [Semantics], Appendix I.3)
+                     #81 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Verified
                      Julian Reschke#89 (see [Semantics], Appendix I.3)
+                     #89 (see [Semantics], Appendix J.3)
                      
                   
    
                   
    Reported
                      Erwin Pe#164 (see [Semantics], Appendix I.6)
+                     #164 (see [Semantics], Appendix J.6)
                      
                   
    
                   
    Verified
                      Kalin Gyokov#135 (see [Semantics], Appendix I.4)
+                     #135 (see [Semantics], Appendix J.4)
                      
                   
    
                   
    Held for Document Update
                      Danil Suits#167 (see [Semantics], Appendix I.5)
+                     #167 (see [Semantics], Appendix J.5)