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.

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

MT's proposed change. Fixes #1310. Fixes #1319 #1321

Merged
merged 3 commits into from
Jul 7, 2023
Merged
Changes from all commits
Commits
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
17 changes: 8 additions & 9 deletions draft-ietf-tls-rfc8446bis.md
Original file line number Diff line number Diff line change
Expand Up @@ -517,7 +517,7 @@ specific technical changes:

- Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by {{!RFC8996}}.

- Removes ambiguity around which hash is used with PreSharedKeys and
- Removes ambiguity around which hash is used with PreSharedKeys and
HelloRetryRequest.

- Require that clients ignore NewSessionTicket if they do not
Expand Down Expand Up @@ -1563,16 +1563,15 @@ Random value to the bytes:

44 4F 57 4E 47 52 44 01

If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2
servers SHOULD, set the last 8 bytes of their ServerHello.Random value to the
{{RFC8996}} and {{backward-compatibility-security}} forbid
the negotiation of TLS versions below 1.2. However, server
implementations which do not follow that guidance MUST
set the last 8 bytes of their ServerHello.random value to the
bytes:

44 4F 57 4E 47 52 44 00


Note that {{RFC8996}} and {{backward-compatibility-security}} forbid
the negotation of TLS versions below 1.2; implementations which do not
follow that guidance MUST behave as described above.

TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below
MUST check that the last 8 bytes are not equal to either of these values.
Expand Down Expand Up @@ -3926,7 +3925,7 @@ There are cryptographic limits on the amount of plaintext which can be
safely encrypted under a given set of keys. {{AEAD-LIMITS}} provides
an analysis of these limits under the assumption that the underlying
primitive (AES or ChaCha20) has no weaknesses. Implementations MUST
either close the connection or
either close the connection or
do a key update as described in {{key-update}} prior to reaching these limits.
Note that it is not possible to perform a KeyUpdate for early data
and therefore implementations MUST not exceed the limits
Expand Down Expand Up @@ -6117,7 +6116,7 @@ Since -05
- Reference RFC 8773 (PR 1296)
- Add some more information about application bindings and cite
6125-bis (PR 1297)

Since -04

* Update the extension table (Issue 1241)
Expand Down Expand Up @@ -6441,7 +6440,7 @@ Since -00
Brian Smith
Independent
brian@briansmith.org

Ben Smyth
Ampersand
www.bensmyth.com
Expand Down
Loading