Re: [TLS] John Scudder's Discuss on draft-ietf-tls-dtls13-41: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Wed, Mar 24, 2021 at 7:18 PM John Scudder via Datatracker <
[e-mail]> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-tls-dtls13-41: Discuss
>
> 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-dtls13/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 4.5.2:
>
>    Implementations which choose to generate an alert instead, MUST
>    generate error alerts to avoid attacks where the attacker repeatedly
>    probes the implementation to see how it responds to various types of
>    error.  Note that if DTLS is run over UDP, then any implementation
>
> I just don’t understand this, despite having hopped over to RFC 8446
> Sections 6
> and 6.2. Is the intention that “error alert” implies closure of the
> association? That doesn’t seem to be exactly what 8446 says — it says the
> receiver of the alert closes the connection, but it doesn’t mandate this
> for
> the sender (except in the case of “fatal alert” messages, where “fatal”
> seems
> like the exception that proves the rule).
>

> It may be that “everyone knows” an error alert is the same as termination,
> but
> it’s not obvious in the plain English of the text I reviewed. Or maybe I’m
> barking up the wrong tree and this isn't what the text quoted above is even
> driving at.
>

You're right. This should say "fatal alert".
https://github.com/tlswg/dtls13-spec/pull/219

-Ekr




>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for the well-written document. In particular I thought it was
> helpful
> that you noted important divergences from DTLS 1.2 in line and not just at
> the
> end.
>
> COMMENTS:
>
> Section 3.1:
>
> I found the explanatory text to be confusing. You start with a figure
> illustrating a lost HelloRetryRequest. Then you tell me the server
> maintains a
> rexmit timer:
>
>    The server also maintains a retransmission timer and retransmits when
>    that timer expires.
>
> But then you immediately tell me that it actually doesn’t:
>
>    Note that timeout and retransmission do not apply to the
>    HelloRetryRequest since this would require creating state on the
>    server.  The HelloRetryRequest is designed to be small enough that it
>    will not itself be fragmented, thus avoiding concerns about
>    interleaving multiple HelloRetryRequests.
>
> I presume that if I added some more words to this, your intent is that the
> server maintains a retransmission timer *for messages other than
> HelloRetryRequest*. As written, it gave me some whiplash.
>
> Section 4.2.1:
>
>    In general,
>    implementations SHOULD discard records from earlier epochs, but if
>    packet loss causes noticeable problems implementations MAY choose to
>    retain keying material from previous epochs for up to the default MSL
>    specified for TCP [RFC0793] to allow for packet reordering.
>
> It seems to me as though “if packet loss causes noticeable problems” is
> saying
> either too much, or not enough. Not enough: problems for whom? Noticeable
> by
> whom? How is this determined? Do you really mean I’m supposed to work this
> out
> dynamically as the text sort-of implies? Too much: if you’re not going to
> answer the foregoing, maybe don’t taunt me, and omit the clause entirely?
> Or,
> possibly a less vague rewrite could be in the nature of “if providing
> service
> to an application that is especially sensitive to packet loss”.
>
> NITS:
>
> Section 2:
>
> “The reader is also as to be familiar” s/as/assumed/
>
> Section 11:
>
>    Although the cookie must allow the server to produce the right
>    handshake transcript, they
>
> “It” not “they” (agreement in number)
>
> and
>
>    DTLS with connection IDs allow for endpoint addresses to
>    change during the association;
>
> “allows” not “allow” (agreement in number)
>
>
>
>