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

ekr,

Thanks for circling back to the WG with the consolidated list!

Cheers,
spt

> On Apr 22, 2021, at 13:31, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 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.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls