Reviewer: Dale Worley
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>.
Document: draft-ietf-tls-tls13-24
Reviewer: Dale R. Worley
Review Date: 2018-03-02
IETF LC End Date: 2018-03-02
IESG Telechat date: 2018-03-08
Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.
This review only covers the general properties of the proposed
protocol and the exposition, as I am unqualified to assess its
security properties.
There are various places where the exposition could be made clearer,
especially to readers not immersed in security matters. In many
places, it is mostly a matter of making clearer the connections
between different points in the exposition.
In a few places, there seems to be ambiguity regarding the
specification that has technical significance. In particular:
- There is inexactness about "transcript", "handshake context", and
"context".
- When a server receives ClientHello, is it obligated to promptly send
not just the ServerHello, but all first-flight messages from
ServerHello through Finished? (section 4.2.11.3) I ask this
because the client is only obligated/permitted to send
EndOfEarlyData when it receives the server's Finished.
- It seems inconsistent that the client can send an empty Certificate
message, but the server cannot, even though the server can omit
sending the Certificate message. (section 4.4.2.4)
- Comparing sections 4.2.10 and 4.6.1, when a PSK was established in
an earlier connection, exactly what are the limitations on the
cryptographic parameters that can be used when the PSK is used in a
resumption connection? 4.2.10 suggests that the following must be
the same in both connections: TLS version, cipher suite, ALPN. But
4.6.1 suggests that different cipher suites can be used, as long as
they use the same hash algorithm.
- In regard to section 4.6.1, it seems to require that a client MAY
NOT resume a connection using a ticket issued during a connection in
which the server did not present a certificate for itself, because
in the handshake of the resumption connection, the client is required
to verify that the SNI is compatible with the certificate the server
presented in the original connection. But that constraint isn't
stated in section 2.2, despite being a global constraint on the
structure of sessions.
- Presumably implementations MUST NOT send zero-length fragments of alert
messages for the same reasons that they cannot send zero-length
fragments of handshake messages (whatever those reasons are).
- There are about 28 error codes but nearly 150 places where the text
require the connection to be aborted with an error -- and hence,
nearly 150 distinct constraints that can be violated. There are 19
alone for "illegal_parameter". I would like to see an "alert
extension value" which assigns a distinct "minor" code to each
statement in the text that requires an error response (with
implementations being allowed to be a bit sloppy in providing the
correct minor code).
- I take it that there is no "close read side" operation. (If that
existed, TLS could generate the "broken pipe" error.)
There are a number of issues which span the whole text:
The interaction of this draft with extensions defined for previous
versions of TLS is not laid out clearly. It seems safe enough for
this draft to import data structures from earlier extensions with only
a reference to the earlier RFC, but if an extension defines behavior
(e.g., a negotiation process), exactly what is the specification of
that behavior in TLS 1.3, given that the referenced RFC only defines
its use in TLS 1.2 or earlier? At the least, there should be an
explicit statement that the behaviors are carried forward in the
"obvious way".
It's also not clear exactly which previously defined extensions are
brought forward into TLS 1.3. I suspect that they are all listed in
section 4.2, but is it clearly stated that those, and only those, are
grandfathered in?
Presumably, for any referenced extension, the placement of values in
messages in TLS 1.2 has a "natural" analog in TLS 1.3 that at most
involves moving the value from one field to another in certain
messages. But it would be reassuring to have a clear statement of
this, and an enumeration of any more complex cases.
There are about 28 error codes but nearly 150 places where the text
require the connection to be aborted with an error. There are 19
alone for "illegal_parame
