Skip to content

Commit

Permalink
Script updating gh-pages from 659cd26. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jul 31, 2024
1 parent 7183fc7 commit 4cb5ee1
Show file tree
Hide file tree
Showing 2 changed files with 69 additions and 53 deletions.
43 changes: 26 additions & 17 deletions draft-ietf-tls-rfc8446bis.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1034,7 +1034,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Rescorla</td>
<td class="center">Expires 8 January 2025</td>
<td class="center">Expires 1 February 2025</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1053,12 +1053,12 @@
<a href="https://www.rfc-editor.org/rfc/rfc5705" class="eref">5705</a>, <a href="https://www.rfc-editor.org/rfc/rfc6066" class="eref">6066</a>, <a href="https://www.rfc-editor.org/rfc/rfc7627" class="eref">7627</a>, <a href="https://www.rfc-editor.org/rfc/rfc8422" class="eref">8422</a> (if approved)</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2024-07-07" class="published">7 July 2024</time>
<time datetime="2024-07-31" class="published">31 July 2024</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Standards Track</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2025-01-08">8 January 2025</time></dd>
<dd class="expires"><time datetime="2025-02-01">1 February 2025</time></dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1098,7 +1098,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 8 January 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
This Internet-Draft will expire on 1 February 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1617,7 +1617,7 @@ <h2 id="name-introduction">
<ul class="normal">
<li class="normal" id="section-1-6.1">
<p id="section-1-6.1.1">A handshake protocol (<a href="#handshake-protocol" class="auto internal xref">Section 4</a>) that authenticates the communicating parties,
negotiates cryptographic modes and parameters, and establishes
negotiates cryptographic algorithms and parameters, and establishes
shared keying material. The handshake protocol is designed to
resist tampering; an active attacker should not be able to force
the peers to negotiate different parameters than they would
Expand Down Expand Up @@ -1993,7 +1993,7 @@ <h2 id="name-protocol-overview">
<p id="section-2-9">In the Key Exchange phase, the client sends the ClientHello
(<a href="#client-hello" class="auto internal xref">Section 4.1.2</a>) message, which contains a random nonce
(ClientHello.random); its offered protocol versions; a list of
symmetric cipher/HKDF hash pairs; either a list of Diffie-Hellman key shares (in the
symmetric cipher/hash pairs; either a list of Diffie-Hellman key shares (in the
"key_share" (<a href="#key-share" class="auto internal xref">Section 4.2.8</a>) extension), a list of pre-shared key labels (in the
"pre_shared_key" (<a href="#pre-shared-key-extension" class="auto internal xref">Section 4.2.11</a>) extension), or both; and
potentially additional extensions. Additional fields and/or messages
Expand Down Expand Up @@ -4689,7 +4689,8 @@ <h3 id="name-authentication-messages">
sent under certain circumstances, as defined below. The Finished
message is always sent as part of the Authentication Block.
These messages are encrypted under keys derived from the
[sender]_handshake_traffic_secret.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
[sender]_handshake_traffic_secret,
except for post-handshake authentication.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">The computations for the Authentication messages all uniformly
take the following inputs:<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
Expand Down Expand Up @@ -4755,7 +4756,7 @@ <h3 id="name-authentication-messages">
<tr>
<td class="text-left" rowspan="1" colspan="1">Post-Handshake</td>
<td class="text-left" rowspan="1" colspan="1">ClientHello ... client Finished + CertificateRequest</td>
<td class="text-left" rowspan="1" colspan="1">client_application_traffic_secret_N</td>
<td class="text-left" rowspan="1" colspan="1">[sender]_application_traffic_secret_N</td>
</tr>
</tbody>
</table>
Expand Down Expand Up @@ -4987,9 +4988,8 @@ <h5 id="name-certificate-selection">
indicated supported algorithms, then it SHOULD continue the handshake by sending
a certificate chain of its choice that may include algorithms that are not known
to be supported by the client.
This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general,
but MAY do so if the client's advertisement permits it,
and MUST NOT do so otherwise.<a href="#section-4.4.2.2-8" class="pilcrow">¶</a></p>
This fallback chain MUST NOT use the deprecated SHA-1 hash,
unless the client specifically advertises that it is willing to accept SHA-1.<a href="#section-4.4.2.2-8" class="pilcrow">¶</a></p>
<p id="section-4.4.2.2-9">If the sender is the client, the client MAY use a fallback chain as above, or
continue the handshake anonymously.<a href="#section-4.4.2.2-9" class="pilcrow">¶</a></p>
<p id="section-4.4.2.2-10">If the receiver cannot construct an acceptable chain using the provided
Expand Down Expand Up @@ -5253,7 +5253,8 @@ <h3 id="name-post-handshake-messages">
<h4 id="name-new-session-ticket-message">
<a href="#section-4.6.1" class="section-number selfRef">4.6.1. </a><a href="#name-new-session-ticket-message" class="section-name selfRef">New Session Ticket Message</a>
</h4>
<p id="section-4.6.1-1">At any time after the server has received the client Finished message,
<p id="section-4.6.1-1">If the client's hello contained a suitable "psk_key_exchange_modes" extension,
at any time after the server has received the client Finished message,
it MAY send a NewSessionTicket message. This message creates a unique
association between the ticket value and a secret PSK
derived from the resumption secret (see <a href="#cryptographic-computations" class="auto internal xref">Section 7</a>).<a href="#section-4.6.1-1" class="pilcrow">¶</a></p>
Expand Down Expand Up @@ -6010,14 +6011,20 @@ <h3 id="name-closure-alerts">
requirement could cause truncation in the read side. Both parties need not
wait to receive a "close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of truncation.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">If the application protocol using TLS provides that any data may be carried
<p id="section-6.1-5">Application protocols MAY choose to flush their send buffers and immediately
send a close_notify upon receiving a close_notify, but this allows an attacker
to influence the data that the peer receives by delaying the close_notify or
by delaying the transport level delivery of the application's packets. These
issues can be addressed at the application layer, for instance by ignoring
packets received after transmitting the close_notify.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">If the application protocol using TLS provides that any data may be carried
over the underlying transport after the TLS connection is closed, the TLS
implementation MUST receive a "close_notify" alert before indicating
end-of-data to the application layer. No part of this
standard should be taken to dictate the manner in which a usage profile for TLS
manages its data transport, including when connections are opened or closed.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">Note: It is assumed that closing the write side of a connection reliably
delivers pending data before destroying the transport.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
manages its data transport, including when connections are opened or closed.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
<p id="section-6.1-7">Note: It is assumed that closing the write side of a connection reliably
delivers pending data before destroying the transport.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="error-alerts">
Expand Down Expand Up @@ -7187,6 +7194,7 @@ <h3 id="name-changes-for-this-rfc">
</div>
</section>
</div>
<div id="sec-combined-references">
<section id="section-12">
<h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
Expand Down Expand Up @@ -7303,7 +7311,7 @@ <h3 id="name-normative-references">
<dd class="break"></dd>
<dt id="RFC8996">[RFC8996]</dt>
<dd>
<span class="refAuthor">Moriarty, K.</span> and <span class="refAuthor">S. Farrell</span>, <span class="refTitle">"Deprecating TLS 1.0 and TLS 1.1"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 8996</span>, <span class="seriesInfo">DOI 10.17487/RFC8996</span>, <time datetime="2021-03" class="refDate">March 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8996">https://www.rfc-editor.org/rfc/rfc8996</a>&gt;</span>. </dd>
<span class="refTitle">"*** BROKEN REFERENCE ***"</span>. </dd>
<dd class="break"></dd>
<dt id="SHS">[SHS]</dt>
<dd>
Expand Down Expand Up @@ -7670,6 +7678,7 @@ <h3 id="name-informative-references">
</section>
</div>
</section>
</div>
<div id="state-machine">
<section id="appendix-A">
<h2 id="name-state-machine">
Expand Down
79 changes: 43 additions & 36 deletions draft-ietf-tls-rfc8446bis.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,10 +4,10 @@

Transport Layer Security E. Rescorla
Internet-Draft Windy Hill Systems, LLC
Obsoletes: 8446 (if approved) 7 July 2024
Obsoletes: 8446 (if approved) 31 July 2024
Updates: 5705, 6066, 7627, 8422 (if approved)
Intended status: Standards Track
Expires: 8 January 2025
Expires: 1 February 2025


The Transport Layer Security (TLS) Protocol Version 1.3
Expand Down Expand Up @@ -39,7 +39,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 January 2025.
This Internet-Draft will expire on 1 February 2025.

Copyright Notice

Expand Down Expand Up @@ -232,7 +232,7 @@ Table of Contents
TLS consists of two primary components:

* A handshake protocol (Section 4) that authenticates the
communicating parties, negotiates cryptographic modes and
communicating parties, negotiates cryptographic algorithms and
parameters, and establishes shared keying material. The handshake
protocol is designed to resist tampering; an active attacker
should not be able to force the peers to negotiate different
Expand Down Expand Up @@ -501,7 +501,7 @@ Auth | {CertificateVerify*}
In the Key Exchange phase, the client sends the ClientHello
(Section 4.1.2) message, which contains a random nonce
(ClientHello.random); its offered protocol versions; a list of
symmetric cipher/HKDF hash pairs; either a list of Diffie-Hellman key
symmetric cipher/hash pairs; either a list of Diffie-Hellman key
shares (in the "key_share" (Section 4.2.8) extension), a list of pre-
shared key labels (in the "pre_shared_key" (Section 4.2.11)
extension), or both; and potentially additional extensions.
Expand Down Expand Up @@ -2636,7 +2636,8 @@ Auth | {CertificateVerify*}
only sent under certain circumstances, as defined below. The
Finished message is always sent as part of the Authentication Block.
These messages are encrypted under keys derived from the
[sender]_handshake_traffic_secret.
[sender]_handshake_traffic_secret, except for post-handshake
authentication.

The computations for the Authentication messages all uniformly take
the following inputs:
Expand Down Expand Up @@ -2665,25 +2666,25 @@ Auth | {CertificateVerify*}
The following table defines the Handshake Context and MAC Base Key
for each scenario:

+=========+====================+===================================+
|Mode |Handshake Context |Base Key |
+=========+====================+===================================+
|Server |ClientHello ... |server_handshake_traffic_secret |
| |later of | |
| |EncryptedExtensions/| |
| |CertificateRequest | |
+---------+--------------------+-----------------------------------+
|Client |ClientHello ... |client_handshake_traffic_secret |
| |later of server | |
| |Finished/ | |
| |EndOfEarlyData | |
+---------+--------------------+-----------------------------------+
|Post- |ClientHello ... |client_application_traffic_secret_N|
|Handshake|client Finished + | |
| |CertificateRequest | |
+---------+--------------------+-----------------------------------+

Table 2: Authentication Inputs
+=========+====================+=====================================+
|Mode |Handshake Context |Base Key |
+=========+====================+=====================================+
|Server |ClientHello ... |server_handshake_traffic_secret |
| |later of | |
| |EncryptedExtensions/| |
| |CertificateRequest | |
+---------+--------------------+-------------------------------------+
|Client |ClientHello ... |client_handshake_traffic_secret |
| |later of server | |
| |Finished/ | |
| |EndOfEarlyData | |
+---------+--------------------+-------------------------------------+
|Post- |ClientHello ... |[sender]_application_traffic_secret_N|
|Handshake|client Finished + | |
| |CertificateRequest | |
+---------+--------------------+-------------------------------------+

Table 2: Authentication Inputs

4.4.1. The Transcript Hash

Expand Down Expand Up @@ -2900,10 +2901,9 @@ Auth | {CertificateVerify*}
certificate chain that is signed only via the indicated supported
algorithms, then it SHOULD continue the handshake by sending a
certificate chain of its choice that may include algorithms that are
not known to be supported by the client. This fallback chain SHOULD
NOT use the deprecated SHA-1 hash algorithm in general, but MAY do so
if the client's advertisement permits it, and MUST NOT do so
otherwise.
not known to be supported by the client. This fallback chain MUST
NOT use the deprecated SHA-1 hash, unless the client specifically
advertises that it is willing to accept SHA-1.

If the sender is the client, the client MAY use a fallback chain as
above, or continue the handshake anonymously.
Expand Down Expand Up @@ -3139,10 +3139,11 @@ Auth | {CertificateVerify*}

4.6.1. New Session Ticket Message

At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message. This message
creates a unique association between the ticket value and a secret
PSK derived from the resumption secret (see Section 7).
If the client's hello contained a suitable "psk_key_exchange_modes"
extension, at any time after the server has received the client
Finished message, it MAY send a NewSessionTicket message. This
message creates a unique association between the ticket value and a
secret PSK derived from the resumption secret (see Section 7).

The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello
Expand Down Expand Up @@ -3814,6 +3815,14 @@ Auth | {CertificateVerify*}
connection, though doing so would introduce the possibility of
truncation.

Application protocols MAY choose to flush their send buffers and
immediately send a close_notify upon receiving a close_notify, but
this allows an attacker to influence the data that the peer receives
by delaying the close_notify or by delaying the transport level
delivery of the application's packets. These issues can be addressed
at the application layer, for instance by ignoring packets received
after transmitting the close_notify.

If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive a "close_notify" alert
Expand Down Expand Up @@ -4861,9 +4870,7 @@ Auth | {CertificateVerify*}
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/rfc/rfc8439>.

[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/rfc/rfc8996>.
[RFC8996] "*** BROKEN REFERENCE ***".

[SHS] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology, DOI 10.6028/nist.fips.180-4,
Expand Down

0 comments on commit 4cb5ee1

Please sign in to comment.