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 -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
