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

[Eric Rescorla <[e-mail]>]

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.



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


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!

-Ekr