[TLS] draft-ietf-tls-dtls13-42 responses to feedback

[Eric Rescorla <[e-mail]>]

I have posted draft-ietf-tls-dtls13-42, addressing the IESG
Feedback. Thanks to everyone who provided reviews. Here is a
description how I handled comments. If there is somebody whose
feedback I missed please let me know.

-Ekr

**** Erik Kline

> [ section 4.4 ]
>
> * "respectively" -> "respectively."
>
> * Could a DTLS implementation packetize to a min-MTU for an IP version
>   and avoid all pMTU issues?  Such a strategy would probably be poor for
>   IPv4 but might be acceptable for IPv6 communications.

Maybe, but I think we probably don't need to say much.


> [ section 4.5.3 ]
>
> * "MUST NOT used" -> "MUST NOT be used"

Fixed.

> [ section 5.8.4 ]
>
> * "NOT have send" -> "NOT send", I think

Fixed.

> [ section 6 ]
>
> * "which are needed to encrypt to decrypt"?

Fixed.


**** Francesca Palombini

> section 2. Conventions and Terminology
>
> FP: Please spell out that network byte order (most significant byte
first) is used throughout the document.

Done.

>
>     Once the client has transmitted the ClientHello message, it expects
>     to see a HelloRetryRequest or a ServerHello from the server.
>     However, if the server's message is lost, the client knows that
>     either the ClientHello or the response from the server has been lost
>     and retransmits. When the server receives the retransmission, it
>     knows to retransmit.
>
> FP: It would be good to mention retransmission max times here.

DTLS actually doesn't have an overall timeout. This is left to
the discretion of the implementation. It does have a maxmimum
backoff, butbackoff isn't mentioned at all.


>              |                |   /+----------------+\
>              | 31 < OCT < 64 -+--> |DTLS Ciphertext |
>              |                |    |(header bits    |
>              |      else      |    | start with 001)|
>              |       |        |   /+-------+--------+\
>
>         The value for the "DTLS-OK" column is "Y". IANA is requested to
>         reserve the content type range 32-63 so that content types in this
>         range are not allocated.
>
> FP: IANA is asked to reserve 32-63, but I could not see any explanation
for that. I would like to see it justified in section 4.1 or in the
respective IANA section.

Done.

>
>
>     fragmentation, clients of the DTLS record layer SHOULD attempt to
>     size records so that they fit within any PMTU estimates obtained from
>     the record layer.
>
> FP: First time PMTU appears, please expand and add reference.

Done.

>     performing PMTU discovery, whether via [RFC1191] or [RFC4821]
>     mechanisms. In particular:
>
> FP: I think this is missing areference to RFC 8201 since IPv6 is
mentioned below.

Done.

>     Any TLS cipher suite that is specified for use with DTLS MUST define
>     limits on the use of the associated AEAD function that preserves
>     margins for both confidentiality and integrity. That is, limits MUST
>     be specified for the number of packets that can be authenticated and
>     for the number of packets that can fail authentication before a key
>     update is required. Providing a reference to any analysis upon which
>     values are based - and any assumptions used in that analysis - allows
>     limits to be adapted to varying usage conditions.
>
> FP: This seems important enough that it should be highlighted for the
experts reviewing the registration. I see that
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
has a number of notes, maybe that would be enough, or maybe add it (as an
update?) to RFC 8447?

Done.

> zero
> length vector (i.e., a single zero byte length field).
>
> FP: I suggest using TLS 1.3 terminology of "zero-length vector (i.e., a
zero-valued single byte length field)"

Done.

>     flow shown in Figure 11 if the client does not send the ACK message
>
> FP: s/11/12

Done.


***** Martin Duke

> COMMENTS:
> Sec 2. It might be useful to introduce the term "epoch" in the glossary,
for those who read this front to back.

Done.


> Sec 4.2.3: "The encrypted sequence number is computed by XORing the
leading bytes of the Mask with the sequence number. Decryption is
accomplished by the same process."
>
> The text is unclear if the XOR is applied to the expanded sequence number
or merely the 1-2 octets on the wire. I presume it's the latter, but this
should be clarified.

Fixed.


> Sec 4.2.3: It's implied here that the sn_key rotates with the epoch. As
this is different from QUIC, it's probably worth spelling out.

Fixed.


> Sec 5.1 is a bit vague about the amplification limit; why not at least
RECOMMEND 3, as we've converged on this elsewhere?

Added.


> Sec 5.1. Reading between the lines, it's clear that the cookie can't be
used as address verification across connections in the way that a NEW_TOKEN
token is. It would be good to spell this out for clients -- use the
resumption token or whatever instead.

Added some text.


> Sec 7.2 "As noted above, the receipt of any record responding to a given
flight MUST be taken as an implicit acknowledgement for the entire flight."
I think this should be s/entire flight/entire previous flight?

Added some text.


> Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages
from a flight having been acknowledged an implementation SHOULD retransmit
the unacknowledged messages or fragments."
>
> This language appears inconsistent with Figure 12, where Record 1 has not
been acknowledged but is also not retransmitted. It appears there is an
implied handling of empty ACKs that isn't written down anywhere in Sec 7.2

This is just a bug in the diagram. Good catch. Fixed.



> Sec 9. Should there be any flow control limits on new_connection_id? Or
should receivers be free to simply drop CIDs they can't handle? It might be
good to specify.

Added some text.


> Finally, a really weird one. Reading this document and references to
connection ID prompted to me to think how QUIC-LB could apply to DTLS. The
result is here: https://github.com/quicwg/load-balancers/pull/106/files.
Please note the rather unfortunate third-to-last paragraph. I'm happy to
take the answer that this use case doesn't matter, since I made it up
today. But if it does, it would be very helpful if (1) DTLS 1.3 clients
MUST include a connection_id extension in their ClientHello, even if zero
length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to
include connection_id in HelloRetryRequest even if the client didn't offer
it. Thoughts?

Addressed.



> NITS:
> 5.2 s/select(HandshakeType)/select(msg_type). Though with pseudocode your
mileage may vary as to what's clearer.

Agreed.


> 5.7 s/consitute/constitute

Fixed.


> Sec 5.7 In table 1, why include one ACK in the diagram but not the other?
It's clear from the note, but the figure is a weird omission.

I don't think I understand why we did this, so I just removed it.



**** Lars Eggert

Indicated minor changes made.


**** Zaheduzzaman Sarker

> This was very well written document. Thanks for this.
>
> Minor observations below-
>
> * Section 3.1 :
>   - Once the client has transmitted the ClientHello message, it expects
to see a HelloRetryRequest or a ServerHello from the server. However, if
the server's message is lost, the client knows that either the ClientHello
or the response from the server has been lost and retransmits.
>
> is this supposed to mean when the timer expires the client knows either
the ClientHello or the response from the server has been lost? the current
text does not imply that - the server's message is lost is an
interpretation of timer expired event.
>

Fixed.


>   -  The server also maintains a retransmission timer and retransmits
when that timer expires.
>
> The way it is written following the previous paragraph, almost made me
feel that the server is also maintaining a timer for the client hello. It
would be nicer if some text explains the usage of timers at the server to
break the continuous read from previous paragraph.

Fixed.


> * Section 3.3: I would add a reference to section 4.4.

Done.


> * Section 4.5.2: I assume the silent discard of invalid records will not
impact the timers, is that a valid assumption? if yes, then it would be
good if this is clarified in the text.

This is correct, but I don't quite see why one would think it does, as they
don't even get to the point where you it would impact the timer. Anyway,
added some text.



> * Section 5.8.1:
>
>     Because DTLS clients send the first message (ClientHello), they start
in the PREPARING state. DTLS servers start in the WAITING state, but with
empty buffers and no retransmit timer
>
> This is repeated twice in the section, is there any reason for that?

Fixed.


**** John Scudder

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.

Fixed.


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

Removed.


> NITS:
>
> Section 2:
>
> “The reader is also as to be familiar” s/as/assumed/

Fixed.

> Section 11:
>
>    Although the cookie must allow the server to produce the right
>    handshake transcript, they
>
> “It” not “they” (agreement in number)

Fixed.

> and
>
>    DTLS with connection IDs allow for endpoint addresses to
>    change during the association;
>
> “allows” not “allow” (agreement in number)

Fixed.



**** Eric Vyncke
>
>
> -- Section 3 --
> s/TLS cannot be used directly in datagram environments/TLS cannot be used
directly over a datagram transport/ ?
>
> Bullet 2) s/to enable reassembly in the correct order/to enable
reordering/ ?

Fixed.


> -- Section 3.1 --
> Should there be a hint to a maximum retry count ?

I'm not sure what we would put here given the diversity of environments,
so we opted not to.



> -- Section 3.3 --
> I understand the motivation (and no need to reply), but, sigh...
implementing frag/reassembly above the transport layer...

Indeed. If it helps, think of DTLS as the transport layer :)


**** Robert Wilton
> 1) Although it is clear from the metadata, it might be helpful if the
> introduction also stated that it obsoletes DTLS 1.2.

Done.

> 2) This document is a set of deltas against TLS 1.3.  Given that it
> talks about the DTLS 1.1/1.2 documents being deltas in the
> introduction, I would have also included that information for this
> document in the introduction rather than in the Terminology and
> Considerations section.  Initially, having read the introduction I had
> assumed that it was not going to be deltas.

Done.


**** Bernard Aboba

> Summary: The timeout and retransmission scheme looks workable for common
cases, but could use some refinement to make it more robust.
>
> Technical Comments
>
> 4.5.2. Handling Invalid Records
>
> Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
> invalid formatting, length, MAC, etc.). In general, invalid records
> SHOULD be silently discarded, thus preserving the association;
> however, an error MAY be logged for diagnostic purposes.
>
> [BA] How does silent discard of invalid records interact with
retransmission timers?

It doesn't. How could it? But I added some text anyway.


> 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
> which does this will be extremely susceptible to denial-of-service
> (DoS) attacks because UDP forgery is so easy. Thus, this practice is
> NOT RECOMMENDED for such transports, both to increase the reliability
> of DTLS service and to avoid the risk of spoofing attacks sending
> traffic to unrelated third parties.
>
> [BA] "this practice" refers to "generate an alert instead", correct?

Yes. Addressed,


> 5.8.2. Timer Values
>
> Though timer values are the choice of the implementation, mishandling
> of the timer can lead to serious congestion problems, for example if
>
> [BA] Saying "timer values are the choice of the implementation" seems
> odd, because it is followed by normative language. I would delete this
> and start the sentence with "Mishandling...".

It has been deleted.


> many instances of a DTLS time out early and retransmit too quickly on
> a congested link. Implementations SHOULD use an initial timer value
> of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double
> the value at each retransmission, up to no less than 60 seconds (the
> RFC 6298 maximum). Application specific profiles, such as those used
> for the Internet of Things environment, may recommend longer timer
> values. Note that a 100 msec timer is recommended rather than the
> 3-second RFC 6298 default in order to improve latency for time-
> sensitive applications. Because DTLS only uses retransmission for
> handshake and not dataflow, the effect on congestion should be
> minimal.
>
> Implementations SHOULD retain the current timer value until a message
> is transmitted and acknowledged without having to be retransmitted,
> at which time the value may be reset to the initial value.
>
> [BA] Is it always possible to distinguish a retransmission from a late
> arrival of an original packet? This seems like it could result in
> wrongly resetting the timer in some situations.

The intent of this text is that you didn't retransmit at all.


> 5.8.3. Large Flight Sizes
>
> DTLS does not have any built-in congestion control or rate control;
> in general this is not an issue because messages tend to be small.
> However, in principle, some messages - especially Certificate - can
> be quite large. If all the messages in a large flight are sent at
> once, this can result in network congestion. A better strategy is to
> send out only part of the flight, sending more when messages are
> acknowledged. DTLS offers a number of mechanisms for minimizing the
> size of the certificate message, including the cached information
> extension [RFC7924] and certificate compression [RFC8879].
>
> [BA] How does the implementation know how much of the flight to send?
> Not sure how prevalent large certs are for DTLS (e.g. compared with the
self-signed certs of WebRTC),
> but in EAP-TLS deployments, large certs have caused problems.
> The EAP-TLS cert document draft-ietf-emu-eaptlscert cites some additional
> mechanisms for reducing certificate sizes, such as draft-ietf-tls-ctls
> and [RFC6066] which defines the "client_certificate_url"
> extension which allows TLS clients to send a sequence of Uniform
> Resource Locators (URLs) instead of the client certificate.

We added some text.


> 5.11. Alert Messages
>
> Note that Alert messages are not retransmitted at all, even when they
> occur in the context of a handshake. However, a DTLS implementation
> which would ordinarily issue an alert SHOULD generate a new alert
> message if the offending record is received again (e.g., as a
> retransmitted handshake message). Implementations SHOULD detect when
> a peer is persistently sending bad messages and terminate the local
> connection state after such misbehavior is detected. Note that
> alerts are not reliably transmitted; implementation SHOULD NOT depend
> on receiving alerts in order to signal errors or connection closure.
>
> [BA] For the fatal alert case, it does seem like retransmission would
> be a good idea; otherwise the peer can be left hanging.

This has been the practice since DTLS 1.0, and there's no way to
ack them, so I don't think we should change no.


> Section 7.1
> "Disruptions" such as reordering do not affect timers, correct?

No. The timers are only on the sender side, so they kind of
can't.



> ACKs SHOULD NOT be sent for these flights unless generating the
> responding flight takes significant time.
>
> What is "significant time"?

Rewritten.


> Editorial Comments (NITs)
>
> Section 2
>
> The reader is also as to be familiar with
>
> [BA] "as" -> "assumed"

Fixed.

> Section 3
>
> The basic design philosophy of DTLS is to construct "TLS over
> datagram transport". Datagram transport does not require nor provide
> reliable or in-order delivery of data. The DTLS protocol preserves
> this property for application data. Applications such as media
> streaming, Internet telephony, and online gaming use datagram
> transport for communication due to the delay-sensitive nature of
> transported data. The behavior of such applications is unchanged
> when the DTLS protocol is used to secure communication, since the
> DTLS protocol does not compensate for lost or reordered data traffic.
>
> [BA] While low-latency streaming and gaming does use DTLS to protect data
(e.g. for
> protection of WebRTC data channel), telephony and RTC Audio/Video uses
DTLS/SRTP for
> key derivation only, and SRTP for protection of data. So you might want
to make a
> distinction.

Done.

> Section 3.1
>
> 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.
>
> [BA] I would add "For more detail on timeouts and retransmission,
> see Section 5.8."

Done.

> 4.3. Transport Layer Mapping
>
> DTLS messages MAY be fragmented into multiple DTLS records. Each
> DTLS record MUST fit within a single datagram. In order to avoid IP
> fragmentation, clients of the DTLS record layer SHOULD attempt to
> size records so that they fit within any PMTU estimates obtained from
> the record layer.
>
> [BA] You might reference PMTU considerations described in Section 4.4.

Done.

>     Post-handshake client authentication
>
> Messages of each category can be sent independently, and reliability
> is established via independent state machines each of which behaves
> as described in Section 5.8.1. For example, if a server sends a
> NewSessionTicket and a CertificateRequest message, two independent
> state machines will be created.
>
> As explained in the corresponding sections, sending multiple
> instances of messages of a given category without having completed
> earlier transmissions is allowed for some categories, but not for
> others. Specifically, a server MAY send multiple NewSessionTicket
> messages at once without awaiting ACKs for earlier NewSessionTicket
> first. Likewise, a server MAY send multiple CertificateRequest
> messages at once without having completed earlier client
> authentication requests before. In contrast, implementations MUST
> NOT have send KeyUpdate, NewConnectionId or RequestConnectionId
>
> [BA] "send" -> "sent"

Changed.

>     Example of Handshake with Timeout and Retransmission
>
> The following is an example of a handshake with lost packets and
> retransmissions. Note that the client sends an empty ACK message
> because it can only acknowledge Record 1 sent by the server once it
> has processed messages in Record 0 needed to establish epoch 2 keys,
> which are needed to encrypt to decrypt messages found in Record 1.
>
> [BA] "encrypt to decrypt" -> "encrypt or decrypt"?

Changed.

> Section 7.3
>
> In the first case the use of the ACK message is optional because the
> peer will retransmit in any case and therefore the ACK just allows
> for selective retransmission, as opposed to the whole flight
> retransmission in previous versions of DTLS. For instance in the
> flow shown in Figure 11 if the client does not send the ACK message
>
> [BA] Figure 11 is the DTLS State Machine. Are you referring to another
figure?

Fixed.

> The use of the ACK for the second case is mandatory for the proper
> functioning of the protocol. For instance, the ACK message sent by
> the client in Figure 13, acknowledges receipt and processing of
> record 4 (containing the NewSessionTicket message) and if it is not
> sent the server will continue retransmission of the NewSessionTicket
> indefinitely until its transmission cap is reached.
>
> [BA] Do you mean "maximum retransmission timemout value"?

Fixed.