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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls