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

[Eric Rescorla <[e-mail]>]

Thanks for your comments.


> 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.

Yes, I agree. This is an action item for me.



> 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).

I agree that this is a bit hard to take in, but I'd like to have
a unified diagram. I'll see what I can do about the shortening.


> 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 .

I agree. I will mention this.


> 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.

This is forbidden in S 4.1.4.
https://tlswg.github.io/tls13-spec/#hello-retry-request

   If a client receives a second HelloRetryRequest in the same
   connection (i.e., where the ClientHello was itself in response to a
   HelloRetryRequest), it MUST abort the handshake with an
   “unexpected_message” alert.

Does this seem sufficient?





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

https://tlswg.github.io/tls13-spec/#supported-versions says:

   If this extension is not present, servers which are compliant with
   this specification MUST negotiate TLS 1.2 or prior as specified in
   [RFC5246], even if ClientHello.legacy_version is 0x0304 or
   later. Servers MAY abort the handshake upon receiving a ClientHello
   with legacy_version 0x0304 or later.





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

Because TLS 1.3 allows you to attach OSCP-stapled responses to each
certificate with status_request, we felt that 6961 was superseded.


> 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.

Yes, this is an interesting suggestion. I have filed issue:

https://github.com/tlswg/tls13-spec/issues/939

However, as David Benjamin points out, it's not clear how one would
handle this in practice, because HRR is an instruction to the client
to do something, so if it can't parse that then the handshake fails.


> 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

Good idea.
https://github.com/tlswg/tls13-spec/issues/943


> 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?

I think it's just a result of the way the PDU is formatted. I
would be interested in seeing a PR with guidance...


> 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.

This seems like a good change. I have made it.


> 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.

Yeah, I can see that perspective. That's part of why we domain
separate in the implementation.



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

https://tlswg.github.io/tls13-spec/#pre-shared-key-extension:

    For identities established externally an obfuscated_ticket_age of
    0 SHOULD be used, and servers MUST ignore the value.


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

It's intended to be the same (modulo the domain separation in the label).


> 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;

I did consider that, but it's not possible because you want the
binders to cover the other key identities so that it's not possible
to remove one without detection (unless you reject PSK entirely,
in which case this is detected in the Finished).


> 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).

Thanks. I will try to clean this up. I have filed


> 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).

This is a fair point, but it's been in the document a long time,
so I think this would require WG Consensus.


> 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.

Do you have any thoughts on what text we should insert here? I admit
to being not that familiar with the practical matters of OCSP stapling.



> 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.

Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion
in Chicago.


> 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


> 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.

I can understand that, but we did litigate this extensively, so I think
any change would require WG consensus at this point.


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

All alerts now result in connection termination, so the limit
seems to implicitly be 1.


> 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?

It is defined in:
https://tlswg.github.io/tls13-spec/#key-schedule

I added some text to explain why you would want 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)

They are intended to be consistent. I wiould appreciate WG feedback
on this point.


> 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)

Open to WG feedback here as well.


> 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.

I'd rather not try to draw this distinction in acknowledgements. My
feeling is that people have been doing good work on this back to
SSLv3. I will, however, try to typeset it into two columns.


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

Thanks. We will fix this pre-publication.


-Ekr


On Wed, Mar 29, 2017 at 7:32 AM, Nikos Mavrogiannopoulos <[e-mail]>
wrote:

> On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote:
>
> > 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 .
>
> ... an entry in the security considerations.
>
> > 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066
> > status request. Why not require RFC6961?
>
> Please ignore that. I forgot to delete in my draft.
>
> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>