Thanks for your comments. I have created
https://github.com/tlswg/tls13-spec/pull/1396 to address
the ones I think need changes. Responses below.
> > If a TLS 1.3 ClientHello is received with any other value in this
> field, the server MUST abort the handshake with an "illegal_parameter"
> alert.
>
> `ClientHello` -> `ServerHello`, server -> client.
Yes, this is correct.I have fixed it.
> > Upon receipt of a HelloRetryRequest, the client MUST ... process the
> extensions .... Otherwise, the client MUST process all extensions in
> the HelloRetryRequest...
>
> Twice about the same thing (processing the extensions).
I don't see a problem here. The first statement is generally about the
order of operations and the second is a mandate to process all
all extensions.
> ## 4.1.4
>
> > As with the ServerHello, a HelloRetryRequest MUST NOT contain any
> extensions that were not first offered by the client.
>
> It appears to be the first explanation that the ServerHello /
> HelloRetryRequest extensions must match the ClientHello ones.
> So "As with the ServerHello" does not work.
I don't think this is actually a problem, but I agree it's slightly
clearer.
> ## 4.2.1
>
> > A server which negotiates a version of TLS prior to TLS 1.3 MUST set
> ServerHello.version and MUST NOT send the "supported_versions"
> extension.
>
> `ServerHello.version` -> `ServerHello.legacy_version`.
Fixed.
> ## 4.2.8
>
> > Each KeyShareEntry value MUST correspond to a group offered in the
> "supported_groups" extension and MUST appear in the same order. [A]
> .
> > If using (EC)DHE key establishment, servers offer exactly one
> KeyShareEntry in the ServerHello. This value MUST be in the same group
> as the KeyShareEntry value offered by the client that the server has
> selected for the negotiated key exchange. [B]
> .
> > Servers MUST NOT send a KeyShareEntry for any group not indicated in
> the client's "supported_groups". [C]
>
> [C] is redundant: it automatically holds if [A] and [B] hold.
I agree it's redundant, but I think it's clearer.
> ## 4.2.11.3
>
> > Clients are permitted to "stream" 0-RTT data until they receive the
> server's Finished, only then sending the EndOfEarlyData message,
> followed by the rest of the handshake. In order to avoid deadlocks,
> when accepting "early_data", servers MUST process the client's
> ClientHello and then immediately send their flight of messages, rather
> than waiting for the client's EndOfEarlyData message before sending
> its ServerHello.
>
> A better place for this paragraph seems to be 4.2.10 (early_data) or
> 4.5 (EndOfEarlyData).
I think this is fine as-is.
> ## 4.6.1
>
> > The value of zero indicates that the ticket should be discarded
> immediately.
>
> "discarded immediately" -> "discarded immediately after use".
Agreed. Fixed.
> > If such an indication is provided (externally or by any other
> means), clients MAY resume with a different SNI value.
>
> It is difficult to understand that "indication" refers (indeed?) to
> the beginning of the paragraph.
I think this is clear enough as is.
> ## 6.1
>
> > close_notify: ... Any data received after a closure alert has been
> received MUST be ignored.
>
> > Any data received after a close_notify alert has been received MUST
> be ignored.
>
> Duplication.
Removed the second one.
>
> ## 7.2
>
> > Once the handshake is complete, it is possible for either side to
> update its sending traffic keys.
>
> keys -> key.
>
> > application_traffic_secret_0 ... application_traffic_secret_N ...
> application_traffic_secret_N+1
>
> It might be better to use a single `application_traffic_secret`
> instead of multiple `application_traffic_secret_XXX`:
>
> ```
> application_traffic_secret =
> HKDF-Expand-Label(application_traffic_secret,
> "traffic upd", "", Hash.length)
> ```
In my opinion this would be less clear.
> ## Presentation Language
>
> Formally, it is necessary to explain `a^b`.
I think this is well-enough known that it's not necessary. It
hasn't been an issue in the past AFAICT.
> Recommendation: define `+=` for enums:
> ```
> NamedGroup += group_a(0xFEFF);
> ...
> NamedGroup += { group_b(0xFEFE), group_c(0xFEFD) };
> ```
> This facilitates extending enums in external specifications.
We usually just do this verbally. I'm opposed to adding new
syntax at this time.
> # Questions
>
> ## 4.1.2
>
> > The client will also send a ClientHello when the server has
> responded to its ClientHello with a HelloRetryRequest. In that case,
> the client MUST send the same ClientHello without modification, except
> as follows: ...
> * Optionally adding, removing, or changing the length of the "padding"
> extension [RFC7685].
>
> Q: Allowing the "padding" extension to be modified makes it
> problematic to reconstruct the first ClientHello from the second, does
> not it? (The reconstruction is mentioned in
> [https://mailarchive.ietf.org/arch/msg/tls/7rLQEHrqKaYo7u31iNBNsPI_OVg/]
> but not in the specification).
As you say it's not in the specification, so it's the job of the
receiver to figure out what to do, potentially by memoizing
the extension in the cookie, or just memoizing the whole hash
state.
> ## 4.6.2
>
> > In addition, clients which receive multiple CertificateRequests in
> close succession MAY respond to them in a different order than they
> were received (the certificate_request_context value allows the server
> to disambiguate the responses).
>
> Q: Can messages from different responses to CertificateRequests be
> interleaved? Is it possible, for example, to obtain the following
> transcript:
> ```
> CR_1, CR_2, CT_1, CT_2, CV_2, CV_1, F_1, F_2
> ```
> ? If so, how does the server differentiate between CV_1 and CV_2 or
> between F_2 and F_1 considering that these messages don't contain
> `certificate_request_context`?
No. This is forbidden earlier.
All of the client's messages for a given response MUST appear
consecutively on the wire with no intervening messages of other
types.
I sharpened this slightly in the current text by adding:
"or from other responses."
-Ekr
On Thu, Jul 24, 2025 at 5:32 AM Sergey Agievich <Agievich=
[email protected]> wrote:
> Hi,
>
> I have enough carefully read draft-ietf-tls-rfc8446bis and prepared
> some comments. I hope they will help improve the editorial quality of
> the specification.
>
> I also have 2 technical questions. It would be great to have answers.
>
> Best,
> Sergey
>
> # Comments
>
> ## 4.1.3
>
> > If a TLS 1.3 ClientHello is received with any other value in this
> field, the server MUST abort the handshake with an "illegal_parameter"
> alert.
>
> `ClientHello` -> `ServerHello`, server -> client.
>
> > Upon receipt of a HelloRetryRequest, the client MUST ... process the
> extensions .... Otherwise, the client MUST process all extensions in
> the HelloRetryRequest...
>
> Twice about the same thing (processing the extensions).
>
> ## 4.1.4
>
> > As with the ServerHello, a HelloRetryRequest MUST NOT contain any
> extensions that were not first offered by the client.
>
> It appears to be the first explanation that the ServerHello /
> HelloRetryRequest extensions must match the ClientHello ones.
> So "As with the ServerHello" does not work.
>
> ## 4.2.1
>
> > A server which negotiates a version of TLS prior to TLS 1.3 MUST set
> ServerHello.version and MUST NOT send the "supported_versions"
> extension.
>
> `ServerHello.version` -> `ServerHello.legacy_version`.
>
> ## 4.2.8
>
> > Each KeyShareEntry value MUST correspond to a group offered in the
> "supported_groups" extension and MUST appear in the same order. [A]
> .
> > If using (EC)DHE key establishment, servers offer exactly one
> KeyShareEntry in the ServerHello. This value MUST be in the same group
> as the KeyShareEntry value offered by the client that the server has
> selected for the negotiated key exchange. [B]
> .
> > Servers MUST NOT send a KeyShareEntry for any group not indicated in
> the client's "supported_groups". [C]
>
> [C] is redundant: it automatically holds if [A] and [B] hold.
>
> ## 4.2.11.3
>
> > Clients are permitted to "stream" 0-RTT data until they receive the
> server's Finished, only then sending the EndOfEarlyData message,
> followed by the rest of the handshake. In order to avoid deadlocks,
> when accepting "early_data", servers MUST process the client's
> ClientHello and then immediately send their flight of messages, rather
> than waiting for the client's EndOfEarlyData message before sending
> its ServerHello.
>
> A better place for this paragraph seems to be 4.2.10 (early_data) or
> 4.5 (EndOfEarlyData).
>
> ## 4.6.1
>
> > The value of zero indicates that the ticket should be discarded
> immediately.
>
> "discarded immediately" -> "discarded immediately after use".
>
> > If such an indication is provided (externally or by any other
> means), clients MAY resume with a different SNI value.
>
> It is difficult to understand that "indication" refers (indeed?) to
> the beginning of the paragraph.
>
> ## 6.1
>
> > close_notify: ... Any data received after a closure alert has been
> received MUST be ignored.
>
> > Any data received after a close_notify alert has been received MUST
> be ignored.
>
> Duplication.
>
> ## 7.2
>
> > Once the handshake is complete, it is possible for either side to
> update its sending traffic keys.
>
> keys -> key.
>
> > application_traffic_secret_0 ... application_traffic_secret_N ...
> application_traffic_secret_N+1
>
> It might be better to use a single `application_traffic_secret`
> instead of multiple `application_traffic_secret_XXX`:
>
> ```
> application_traffic_secret =
> HKDF-Expand-Label(application_traffic_secret,
> "traffic upd", "", Hash.length)
> ```
>
> ## Presentation Language
>
> Formally, it is necessary to explain `a^b`.
>
> Recommendation: define `+=` for enums:
> ```
> NamedGroup += group_a(0xFEFF);
> ...
> NamedGroup += { group_b(0xFEFE), group_c(0xFEFD) };
> ```
> This facilitates extending enums in external specifications.
>
> # Questions
>
> ## 4.1.2
>
> > The client will also send a ClientHello when the server has
> responded to its ClientHello with a HelloRetryRequest. In that case,
> the client MUST send the same ClientHello without modification, except
> as follows: ...
> * Optionally adding, removing, or changing the length of the "padding"
> extension [RFC7685].
>
> Q: Allowing the "padding" extension to be modified makes it
> problematic to reconstruct the first ClientHello from the second, does
> not it? (The reconstruction is mentioned in
> [https://mailarchive.ietf.org/arch/msg/tls/7rLQEHrqKaYo7u31iNBNsPI_OVg/]
> but not in the specification).
>
> ## 4.6.2
>
> > In addition, clients which receive multiple CertificateRequests in
> close succession MAY respond to them in a different order than they
> were received (the certificate_request_context value allows the server
> to disambiguate the responses).
>
> Q: Can messages from different responses to CertificateRequests be
> interleaved? Is it possible, for example, to obtain the following
> transcript:
> ```
> CR_1, CR_2, CT_1, CT_2, CV_2, CV_1, F_1, F_2
> ```
> ? If so, how does the server differentiate between CV_1 and CV_2 or
> between F_2 and F_1 considering that these messages don't contain
> `certificate_request_context`?
>
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
