[TLS] comments on draft-ietf-tls-tls13-19

[Nikos Mavrogiannopoulos <[e-mail]>]

Hi,
 In this mail I summarize my comments for draft-ietf-tls-tls13-19
(which I have read but not implemented). They include both editorial
comments and content comments. Overall this is a very good document,
congratulations to everyone involved.

On the following text, I use the format Section: Comment.


1.2. Major Differences from TLS 1.2
 It is very hard to make use of this section as is. It is organized on
per-draft, while it would be expected to have the changes of the
document since TLS 1.2. It contains phrases like "Remove spurious
requirement to implement "pre_shared_key"." At its current state it is
not useful to someone familiar with TLS 1.2.


2. Figure 1 ascii art is a bit awkward (IMHO). "Key Exch" looks like
bad shortening. Symbols '^' and 'v' were confusing on the first read.
A suggestion could be to avoid ^v, and define shortened terminology
upfront and use it on the figures.

One the content, Figure 1 contents are too many to swallow at an
overview. A suggestion would be to split into two diagrams (preshared
keys and not).

A more general note on the section/document, is that although the PKIX
identity (certificate) is protected from passive adversaries, the PSK
identity is not. This is a discrepancy in terms of protecting the
user's identity between PSK and certificate authentication (that should
warrant .


4.1.1. HelloRetryRequest how many times can it be re-sent by the
server? I assume only a single one, but it maybe good to make it
explicit.


4.1.2. It is not defined what a server should do if encountered with a
ProtocolVersion of TLS 1.3.


4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066
status request. Why not require RFC6961?


4.2. the exception for including cookie in HelloRetryRequest seems like
something that could cause issues in future revisions. Any future
revision of the protocol would not be able to add such exceptions
(since they will be rejected by existing clients), and the fact that
the cookie is there, it indicates that such an exception may be useful.
A suggestion to address that would be to allow the HelloRetryRequest 
contain any extension or grant an exception to a specific extension
number range.


4.2.5.2. The parameters are informally defined.
I'd suggest to follow rfc4492bis and use its text as in:
 https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-16#section-5.4.1


4.2.7. There is no guidance on the use of max_early_data_size. 
I'd find it natural to have a recommended minimum value for application
protocols layered on TLS to take into account. E.g., text like servers
supporting early_data SHOULD allow at least 1024 bytes of data
(arbitrary number). Is the 32-bit upper limit intentional?


4.2.8. This section changes the semantics for pre-shared keys as used
in any other protocol (including TLS 1.2). With the new text it
implies, pre-shared keys must be combined with a hash algorithm. Thus
existing PSK deployments which share keys and would like to upgrade to
TLS 1.3 cannot do transparently. They would have to fix to a specific
hash algorithm for their existing PSKs, and make sure they provide that
information to all the underlying software (which may be different on
the server and client side). I could find no implementation guideline
on what to do in the case of pre-existing PSKs in that text.

My recommendation would be to switch the sentence "For externally
established PSKs, the Hash algorithm MUST be set when the PSK is
established" to "For externally established PSKs, the Hash algorithm
MUST be set when the PSK is established, or default to SHA-256". That
way implementations can cope transparently with an upgrade to TLS 1.3
for already present PSK keys without requiring an additional RFC
describing that.


4.2.8. The overlap of the namespace for usernames to be used in PSK
authentication, and the namespace for "resumption" does not give a good
feeling.


4.2.8. Related to the above, it is unclear what obfuscated_ticket_age
should contain when using PSK authentication (but not resumption).


4.2.8.1. It is not defined what the binder should contain when using
PSK authentication (but not resumption).


4.2.8.1. If a single binder corresponds to a single identity, the
parsing and mapping of binders in the PreSharedKeyExtension seems
unnecessarily complicated. A suggestion is to move the binder inside
each identity structure:
struct {
          opaque identity<1..2^16-1>;
          uint32 obfuscated_ticket_age;
          opaque PskBinderEntry<32..255>;
} PskIdentity;


4.2.8.3. I believe that section can benefit from some improvements.
>From a first read it is not clear what this section wants to protect
from. It provides some checks, but it is unclear to me what these
protect from.

Some more concrete comments on the same section:
It mentions "see if the value used by the client matches its
expectations". A question that arises, is what is the recommended
expectation for a server? Given the text in 4.2.8 that should be a
week, but the text in 4.2.8 seems to imply that the restriction is
defined somewhere else, and I would have expected it to be here.

The text recommends: "a server SHOULD measure the round trip time prior
to sending the NewSessionTicket message". I see two issues here. (1) it
doesn't mention how to do this measurement --my guess is that this can
be done in the context of TLS--, and (2) it assumes that round-trips
are fixed over time. About (1), I ask because the obvious measurement
time between [server Application Data*] and client [Certificate*] would
include the processing of the application data by the client.
On (2), this check will not work as is for mobile clients which will
have variable round-trips.

The check 'ticket age must be shorter than elapsed time by a round-
trip', is unclear to me what it intends to protect from.

A clarification: "the actual time elapsed on the server", elapsed since
when? (I guess since the first message was received).


4.3.2.1. The OID Filters extension on a first look seems quite
independent and unrelated to everything else in this document (seemed
quite a distraction that could have been in an appendix as well).


4.4.2.1.  OCSP Status and SCT Extensions
This is a very nice addition to TLS 1.3. Something that I miss as an
implementer is guidelines on how to determine the (time) validity of an
OCSP stapled response. Here my point is that OCSP responses have
several fields optional (e.g., nextUpdate), which make a validation to
be hand-wavy. It would be nice to have a profile of OCSP responses that
would be recommended for use in TLS, as well or a recommendation of
what constitutes a "fresh" response for use in TLS.


4.4.2.2., 4.4.2.3.
I think the reference to RFC5081 should be replaced with RFC5270 which
obsoletes the former even though not explicitly.

4.4.3. "RSA signatures MUST use an RSASSA-PSS algorithm". What should a
client or server do when encounters an non RSA-PSS signature in TLS
1.3?

4.4.4. "Where HMAC [RFC2104] uses the Hash algorithm for the
handshake.  As noted above, the HMAC input can generally be implemented
by a running hash, i.e., just the handshake hash at this point."

If that's now possible, it is a great addition for TLS 1.3. As this is
not possible in TLS 1.2, I envy the TLS 1.3-only implementations.


4.6.3. My comment on this section, is that leaving up to the
implementer to decide the re-key, would most probably result in the
implementer delegating that decision to the application. In my
experience that would mean no re-key in practice for the majority of
applications. I'd have preferred a one-size fits all approach, where
re-key is done on decided points.


5.1. I miss a maximum number of alerts received per session, or some
other alert limiting mechanism (having CVE-2016-8610 in mind).


7.5. There is no definition of early_exporter_secret, and it is unclear
why it is even mentioned. In short how is this supposed to be used, and
why should implementations consider adding an interface to it?


A. Is the described state machine intended to be normative or
informative? I.e., which takes precedence, this description or the text
above? (would be nice to clarify)


B.4.
I believe it was discussed before, but I miss the AES-256-CCM
ciphersuites. If only one must be defined, it may be better to only
have the 256-bit variants (at least for the non-mac-truncated version).


E. I'd find it natural for this to be the security considerations
rather than an appendix.


G. Quite a long list. Would be nice to have the contributors to TLS 1.3
separately.


Bibliography: There are references to PKCS6 and PKCS7 that are never
used throughout the text (I guess there are more).


regards,
Nikos