Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring RFC2818 into semantics (Mnot 236) #249

Merged
merged 20 commits into from
Nov 3, 2019
Merged

Bring RFC2818 into semantics (Mnot 236) #249

Show file tree
Hide file tree
Changes from 9 commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
34be75e
add obsoletes for 2818
mnot Sep 3, 2019
42a9fd7
Bring in text about identifying servers, clients
mnot Sep 3, 2019
e47fbb1
Add TLS Connection Closure
mnot Sep 3, 2019
b6bab42
add change notes
mnot Sep 3, 2019
823c36c
fix XML
reschke Sep 3, 2019
ef0cfe2
ref style
reschke Sep 3, 2019
32f92a0
prune reference
reschke Sep 3, 2019
e43f1e2
ref style
reschke Sep 3, 2019
065812b
add "changes from 2818" section
reschke Sep 3, 2019
1f19f43
Merge branch 'master' into mnot-236
reschke Sep 5, 2019
af06d38
Merge branch 'master' into mnot-236
reschke Sep 10, 2019
4e77d4a
Ack EKR for 2818.
mnot Sep 30, 2019
2c346a0
Merge branch 'mnot-236' of github.com:httpwg/http-core into mnot-236
mnot Sep 30, 2019
bdb7720
Merge branch 'master' into mnot-236
reschke Sep 30, 2019
e0ed5e7
Merge branch 'master' into mnot-236
royfielding Oct 28, 2019
ba0ed08
update generated files
royfielding Oct 28, 2019
c474780
move bits added from RFC2818 to a subsection of https until we can de…
royfielding Oct 29, 2019
dc0cd25
include initiation section from RFC2818 and update TLS refs
royfielding Oct 29, 2019
ac63b85
Merge branch 'master' into mnot-236
royfielding Nov 3, 2019
fe4dfcd
for completeness, include the redundant RFC2818 requirements that are…
royfielding Nov 3, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions draft-ietf-httpbis-messaging-latest.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2009,6 +2009,33 @@ https://www.example.org
</t>
</section>

<section title="TLS Connection Closure" anchor="tls.connection.closure">
<t>
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.
</t>
<t>
As specified in <xref target="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
royfielding marked this conversation as resolved.
Show resolved Hide resolved
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.
</t>
</section>

<section title="Upgrade" anchor="header.upgrade">
<iref primary="true" item="Upgrade header field" x:for-anchor=""/>
<x:anchor-alias value="Upgrade"/>
Expand Down Expand Up @@ -2733,6 +2760,27 @@ Upgrade: HTTP/2.0
<seriesInfo name="RFC" value="1952"/>
</reference>

<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2018" month="August"/>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>

<reference anchor="Welch">
<front>
<title>A Technique for High-Performance Data Compression</title>
Expand Down Expand Up @@ -3407,6 +3455,7 @@ Upgrade: HTTP/2.0
<section title="Since draft-ietf-httpbis-messaging-05" anchor="changes.since.05">
<ul x:when-empty="None yet.">
<li>In <xref target="message.format"/> and related Sections, move the trailing CRLF from the line grammars into the message format (<eref target="https://github.com/httpwg/http-core/issues/62"/>)</li>
<li>In <xref target="tls.connection.closure"/>, add text from RFC 2818 (<eref target="https://github.com/httpwg/http-core/issues/236"/>)</li>
</ul>
</section>

Expand Down
113 changes: 103 additions & 10 deletions draft-ietf-httpbis-semantics-latest.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@
<?rfc-ext html-pretty-print="prettyprint https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js"?>
<?rfc-ext include-references-in-index="yes" ?>

<rfc obsoletes="7230,7231,7232,7233,7235,7538,7615"
<rfc obsoletes="2818,7230,7231,7232,7233,7235,7538,7615"
category="std" x:maturity-level="proposed"
ipr="pre5378Trust200902" docName="draft-ietf-httpbis-semantics-&ID-VERSION;"
xmlns:x='http://purl.org/net/xml2rfc/ext'
Expand Down Expand Up @@ -100,7 +100,7 @@
codes, response header fields, and content negotiation.
</t>
<t>
This document obsoletes 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.
</t>
</abstract>
Expand Down Expand Up @@ -211,6 +211,8 @@
The other parts of <xref target="RFC7230" x:fmt="none">RFC 7230</xref> are
obsoleted by "HTTP/1.1 Messaging" <xref target="Messaging"/>.
This document also obsoletes
<xref target="RFC2818" x:fmt="none">RFC 2818</xref>
(see <xref target="changes.from.rfc.2818"/>),
<xref target="RFC7231" x:fmt="none">RFC 7231</xref>
(see <xref target="changes.from.rfc.7231"/>),
<xref target="RFC7232" x:fmt="none">RFC 7232</xref>
Expand Down Expand Up @@ -819,7 +821,7 @@ Content-Type: text/plain
</t>
<t>
The process for authoritative access to an "https" identified
resource is defined in <xref target="RFC2818"/>.
resource is defined in <xref target="https.identify.server"/>.
</t>
</section>

Expand Down Expand Up @@ -9628,15 +9630,85 @@ Content-Encoding: gzip
an "http" URI is vulnerable to attacks on Internet Protocol routing.
</t>
<t>
The "https" scheme (<xref target="https.uri"/>) 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 <xref target="RFC2818"/>). Correctly implementing such verification
can be difficult (see <xref target="Georgiev"/>).
The "https" scheme (<xref target="https.uri"/>) 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 <xref
target="Georgiev"/>).
</t>
<section title="Identifying HTTPS Servers" anchor="https.identify.server">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Matching is performed using the matching rules specified by
<xref target="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.
</t>
<t>
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.
</t>
<t>
If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

user-oriented, no?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is a "user(-)oriented client" different from a "user agent"?

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.
</t>
<t>
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.
</t>
</section>
<section title="Identifying HTTPS Clients" anchor="https.identify.client">
<t>
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.
</t>
</section>
</section>

<section title="Risks of Intermediaries" anchor="risks.intermediaries">
<t>
Expand Down Expand Up @@ -10368,6 +10440,20 @@ Content-Encoding: gzip
<seriesInfo name="RFC" value="5234"/>
</reference>

<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper"/>
<author initials="S." surname="Santesson" fullname="S. Santesson"/>
<author initials="S." surname="Farrell" fullname="S. Farrell"/>
<author initials="S." surname="Boeyen" fullname="S. Boeyen"/>
<author initials="R." surname="Housley" fullname="R. Housley"/>
<author initials="W." surname="Polk" fullname="W. Polk"/>
<date year="2008" month="May"/>
</front>
<seriesInfo name="RFC" value="5280"/>
</reference>

<reference anchor='RFC5646'>
<front>
<title>Tags for Identifying Languages</title>
Expand Down Expand Up @@ -11465,6 +11551,12 @@ Content-Encoding: gzip
</t>
</section>

<section title="Changes from RFC 2818" anchor="changes.from.rfc.2818">
<t>
None yet.
</t>
</section>

<section title="Changes from RFC 7231" anchor="changes.from.rfc.7231">
<t>
Removed a superfluous requirement about setting <x:ref>Content-Length</x:ref>
Expand Down Expand Up @@ -11616,6 +11708,7 @@ Content-Encoding: gzip
<li>In <xref target="cacheable.methods"/>, remove concept of "cacheable methods" in favor of prose (<eref target="https://github.com/httpwg/http-core/issues/54"/>)</li>
<li>In <xref target="status.403"/>, replace "authorize" with "fulfill" (<eref target="https://github.com/httpwg/http-core/issues/218"/>)</li>
<li>In <xref target="OPTIONS"/>, removed a misleading statement about Content-Length (<eref target="https://github.com/httpwg/http-core/issues/235"/>, <eref target="https://www.rfc-editor.org/errata/eid5806"/>)</li>
<li>In <xref target="establishing.authority"/>, add text from RFC 2818 (<eref target="https://github.com/httpwg/http-core/issues/236"/>)</li>
</ul>
</section>
</section>
Expand Down