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

[Sean Turner <[e-mail]>]

> On Mar 8, 2018, at 08:10, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Wed, Mar 7, 2018 at 9:25 PM, Spencer Dawkins <[e-mail]> wrote:
> 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"?
> 
> Thanks, yes.

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

> 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)?
> 
> 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"
> 
> 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?
> 
> I don't :)

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

> 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?
> 
> 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.
> 
> 
> 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.
> 
> Ah, good. One alert for two conditions:
> 
> 1. An unexpected record type at the record layer.
> 2. An unexpected handshake message.
> 
> 
> I wondered why
> 
>    Newer
>    clients or servers, when communicating with newer peers, SHOULD
>    negotiate the most preferred common parameters.
> 
> was not a MUST.
> 
> Ugh, this is actually not even a normative statement, It's just a statement of
> what the protocol is supposed to do. Good catch!

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

spt