Subject: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Wed, 07 Mar 2018 21:25:38 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-tls-tls13-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nice work. Of course, no one reads a 150-page document without wondering about
a few things ...

I suspect that

   Because
   TLS 1.3 changes the way keys are derived it updates [RFC5705] as
   described in Section 7.5 it also changes how OCSP messages are
   carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
   described in section Section 4.4.2.1.

is a run-on sentence. Perhaps a period after "section 7.5"?

Is "forward secrecy" (the term used in this draft) the same thing as "perfect
forward secrecy" (the term I hear most often, and it does appear in one
reference title)?

The use of "mandatory" as the name of a vector in

  In the following example, mandatory is a vector that must contain
   between 300 and 400 bytes of type opaque.

was pretty hard to parse until I read further. Did anyone else find that
confusing?

In this text,

  When multiple extensions of different types are present, the
   extensions MAY appear in any order, with the exception of
   "pre_shared_key" Section 4.2.11 which MUST be the last extension in
   the ClientHello.  There MUST NOT be more than one extension of the
   same type in a given extension block.

I didn't see what to do if the MUST NOT is violated. Is that worth mentioning?

In this text,

   An
   implementation which receives any other change_cipher_spec value or
   which receives a protected change_cipher_spec record MUST abort the
   handshake with an "unexpected_message" alert.  A change_cipher_spec
   record received before the first ClientHello message or after the
   peer's Finished message MUST be treated as an unexpected record type.

   Implementations MUST NOT send record types not defined in this
   document unless negotiated by some extension.  If a TLS
   implementation receives an unexpected record type, it MUST terminate
   the connection with an "unexpected_message" alert.  New record
   content type values are assigned by IANA in the TLS Content Type
   Registry as described in Section 11.

I wondered if there was a difference between an unexpected record type and and
unexpected message.

I wondered why

   Newer
   clients or servers, when communicating with newer peers, SHOULD
   negotiate the most preferred common parameters.

was not a MUST.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Mar 2018 05:10:45 -0800

> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

Thanks, yes.

Is "forward secrecy" (the term used in this draft) the same thing as
> "perfect

Close enough. The basic problem is that people get hung up on "perfect".
So, consider the case where you generate a fresh DH key every hour or
so, but you reuse it for that period. It's clear you get forward secrecy
once that key s deleted but is that "perfect" because you have a window
of exposure uring that hour? So, we just decided to use "forward secret"

> was pretty hard to parse until I read further. Did anyone else find that

I don't :)

In this text,
> I didn't see what to do if the MUST NOT is violated. Is that worth

I don't think it's necessary. In general, you can always abort on a protocol
violation like this, but there's no known reason you would *need* to, other
than it would create interop problems if (say) A thinks extension #1 matters
and B thinks #2 matters, but of course there are lots of possible causes
of interop. This is different from cases where there are clear security
problems if you don't check some value or something.

> I wondered if there was a difference between an unexpected record type and

Ah, good. One alert for two conditions:

1. An unexpected record type at the record layer.
2. An unexpected handshake message.

I wondered why
>    negotiate the most preferred common parameters.

Ugh, this is actually not even a normative statement, It's just a statement
of
what the protocol is supposed to do. Good catch!

-Ekr

---

From: Sean Turner <[email-masked]>
Date: Thu, 8 Mar 2018 08:32:08 -0500

> On Mar 8, 2018, at 08:10, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Mar 7, 2018 at 9:25 PM, Spencer Dawkins <[email-masked]> wrote:

Fix in https://github.com/tlswg/tls13-spec/pull/1169

> was pretty hard to parse until I read further. Did anyone else find that

It’s at least on the same page so it’s not too hard to scan lower.  If we called it hooziewazit it’ll still be after it ;)

> Ugh, this is actually not even a normative statement, It's just a statement of

I made it a MUST in:
https://github.com/tlswg/tls13-spec/pull/1172

spt

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Mar 2018 10:32:48 +1100

> what the protocol is supposed to do. Good catch!

Drop the SHOULD, yeah.  Is it worth noting that it's the server's
preference that wins?  As in:

   Newer clients or servers, when communicating with newer peers,
negotiate the common parameters most preferred by the server.

Or is that too constraining?