The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not <del> deprecate SHA-1 in HMAC for record protection. </del>  1. The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in RFC5246.  MD5 and SHA-1 have been proven to be insecure, <del> subject to collision attacks.  RFC6151 details the security considerations, including collision attacks for MD5, published in 2011.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del>  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del>  2.

Addressing Roman's AD comments.
has 2 conflicts, not sure how to resolve, the updates look fine. Please merge.
There was a conflict with the 8174 reference being in the other branch. I added it in because it's now part of the terminology paragraph.
Please address the following IDNits: -- The document seems to lack an IANA Considerations section. (See Section 2.2 of URL for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Section 1. Editorial. -- s/RFC 5246 [RFC5246]/[RFC5246]/ -- s/RFC 6151 [RFC6151]/[RFC6151]/ -- s/RFC7525 [RFC7525]/[RFC7525]/ Section 1. Editorial. For symmetry with the rest of the text: OLD RFC 6151 [RFC6151] details the security considerations, including collision attacks for MD5, published in 2011. NEW In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. Section 1. Please provide a reference for "Wang, et al". Is there a reference to provide for the "the potential for brute-force attack" Section 6. Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/ Section 6. Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut-and-paste. Section 7. Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/ Section 7. SHA-1 is also not mentioned in RFC7525. Recommend: OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. NEW The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 7. Editorial. Grammar. OLD In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used NEW In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make RFC5246 a normative reference.

The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not  <ins> deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1. The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in RFC5246.  MD5 and SHA-1 have been proven to be insecure,  <ins> subject to collision attacks Wang.  In 2011, RFC6151 detailed the security considerations, including collision attacks for MD5.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.


their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated.  OLD: <del> In Section 7.4.1.4.1: the text should be revised from " Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </del>  NEW:

their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. <ins> In Section 7.4.1.4.1: the text should be revised from: </ins> OLD:  <ins> "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </ins> NEW:


(TLS) and Datagram Transport Layer Security (DTLS) recommends use of SHA-256 as a minimum requirement.  This update moves the minimum recommendation to use stronger language deprecating use of both SHA-1 <del> and MD5.  The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. </del>  Section 4.3:

(TLS) and Datagram Transport Layer Security (DTLS) recommends use of SHA-256 as a minimum requirement.  This update moves the minimum recommendation to use stronger language deprecating use of both SHA-1  <ins> and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated.. </ins> Section 4.3:


Servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. <del> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details). Clients MUST indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. </del>  8.

Servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key.  <ins> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details).  Clients MUST indicate to servers that they request SHA- 256, by using the "Signature Algorithms" extension defined in TLS 1.2. </ins> 8.


will typically be the minimum of the server's self-imposed limit and TicketRequestContents.count. <del> Servers that support ticket requests MUST NOT echo "ticket_request" in the EncryptedExtensions message.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in the EncryptedExtensions message. </del>  If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second

Addresses and . The server hint came up in the context of QUIC, e.g., as a possible optimization to let clients know if they should expect any post handshake messages. cc NAME NAME
Looks like this got merged without any business days to review it :) but otherwise the text looks good, approved.
Every day is a business day! ;-)
From NAME
Fixed by .
You probably want to be clear that ticket_request cannot appear in HRR, given that you have a section on it.
Fixed in .
I'm not a huge fan of sending extensions that aren't really needed, but this seems fine. I missed the QUIC discussion (or maybe it's still in my inbox). BTW, I still like the idea of hoisting tickets to the application layer, but ekr seems to think that they belong at the TLS layer. I guess we'll just have to keep disagreeing on that point :)

will typically be the minimum of the server's self-imposed limit and TicketRequestContents.count.  <ins> A server that supports ticket requests MAY echo the "ticket_request" extension in the EncryptedExtensions message.  If present, it contains a TicketRequestContents structure, where TicketRequestContents.count indicates the number of tickets the server expects to send to the client. Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in either of these messages. </ins> If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second


IANA is requested to Create an entry, ticket_request(TBD), in the existing registry for ExtensionType (defined in RFC8446), with "TLS <del> 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del>  5.

IANA is requested to Create an entry, ticket_request(TBD), in the existing registry for ExtensionType (defined in RFC8446), with "TLS  <ins> 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </ins> 5.


4.2. <del> WebTransport clients can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </del>  "WEBTRANSPORT_STREAM" (type=0x41).  The format of the frame SHALL be the frame type, followed by the session ID, encoded as a variable- length integer, followed by the user-specified stream data (fig-bidi- client).  The frame SHALL last until the end of the stream. <del> 4.3. </del>  <del> WebTransport servers can initiate bidirectional streams by opening a bidirectional stream within the HTTP/3 connection.  Note that since HTTP/3 does not define any semantics for server-initiated bidirectional streams, this document is a normative reference for the semantics of such streams for all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated.  The format of those streams SHALL be the session ID, encoded as a variable-length integer, followed by the user-specified stream data (fig-bidi- server). </del>  <del> 4.4. </del>  Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the

This matches agreement at the last interim. We should separate this into a different draft, but for now this will make the draft match implementation.
Partially addresses . cc NAME NAME
Http3Transport currently assumes that server-initiated bidirectional streams and datagrams can only be used for WebTransport. I suggest we prefix each server-initiated bidirectional stream and datagram with a new HTTP/3 frame type for WebTransport. This way, a future standard could define it's own frame type to run alongside WebTransport.
Using an H3 frame type for server initiated bidi streams would also make the design more consistent, instead of the asymmetric design there is today. It costs a byte per bidi stream, but it seems worth it for consistency and flexibility. For datagrams, I believe that we'd want to be able to coexist with other H3 extensions, such as MASQUE, and I believe that's possible without any extra overhead by adding a Session -> Datagram flow ID mapping when a WebTransport session is created.
If it's a single byte, it's more of a stream type (like the unidirectional stream-type) than a frame type, right? There's a discussion Victor pointed me to in , where it's suggested that datagrams belonging to a WebTransport session use the Flow ID = to the Session ID. It would be nice to avoid the extra state and lookup.
Ah yes, it's more of a stream type. In that case, I'm unsure of whether there's a good way of eliminating the asymmetry. The only option I can think of is to not use a stream type for server bidi streams and only use the frame, like for the client initiated bidi streams? Thanks for the pointer to , it looks like there are a few potential designs for datagrams flow IDs. If in doubt, simpler is probably better. I'll think more about this one.
I agree we should use the same mechanics for client and server bidi streams.
After thinking about this more, not having a stream type doesn't seem so bad to me and it does provide symmetry. Stream types seem like an obvious design choice, but I believe HTTP/3 is sufficiently constrained that one could infer the stream type based on the first frame on the stream. For example, the control stream MUST start with SETTINGS. In retrospect, having both stream types and frame types is a bit awkward, and it likely would have been cleaner to only have frame types, but that ship has sailed.
After having implemented this for hackathon, I can confirm that the lack of stream preface on server-bidi streams is annoying and requires special casing (I actually simulate receiving one). Let's please add one. I took a bit of a shortcut and treated the stream preface as both a stream type AND a frame type. After peeking at the unidirectional stream input to discover that it's WT, I let the parser run on that and treat it as a frame type, making it symmetric with the bidi case. Is it possible to define a reserved frame type with the same value as the stream type?
Given HTTP/3 does not have a stream type varint for bidi streams, I think a potential way forward is to say that the first frame on the bidi stream can indicate the 'type' of the stream, but that there is no explicit type identifier on the wire. Feel free to ignore the below comment, as it's apparently unchanged from January Looking back, SETTINGS is required to be the first frame on the control stream, so the control stream type is a bit redundant and the same is true for QPACK and I believe could be true for server push? Obviously we're not going to redesign HTTP/3 stream and frame types at this stage in the process, but making bidi streams consistent for both perspectives seems preferable to me.
Discussed at IETF 110. There seems to be a general agreement that we should make server-initiated bidi streams use the same encoding as client-initiated ones (that is to say, frames). There was some interest expressed in splitting definition of server-initiated bidi streams into their own draft; NAME and NAME are to reach out to httpbis about the appropriate venue for that.
Just bringing some of the discussion from here: HTTP should provide some consistent guidance for the format of HTTP/3 extension streams. Client-bidi extension streams have to start with a frame or series of frames, to be compatible for H3. One of these frames has to identify the type of stream. This is how WT is currently specified. Unidirectional streams all start with a Stream Type, but after that are inconsistent in H3 the control stream is: Stream Type + Frames QPACK Streams are: Stream Type + QPACK instructions Push streams are: Stream Type + Preface (Push ID) + Frames Stream Type seems like a more general extension mechanism, since it can be used to completely decouple from HTTP/3 frame parsing.
I find stream types to be less extensible than frames: frames allow you to do anything that stream types do, while additionally providing more opportunity for extensibility. I would prefer server-initiated bidirectional streams to behave like client-initiated bidirectional streams instead of unidirectional streams, as that makes implementations simpler.
January Me said: So I think I'm arguing against myself and I'm going to stop. My other comments on this thread we that I didn't like was the asymmetry of WT uni streams, which currently are . My past self seemed to be advocating that we change WT uni streams to or perhaps . Do we want general guidance about how extensions should use Stream Type vs Frames on unidirectional streams -- specifically that there should be at least one frame?
The place to put that guidance would have been draft-ietf-quic-http, and I think that ship has sailed. For unidirectional streams, I like your framing proposal as that enables extension frames down the road.
Well, not too late to put out a BCP or something, especially if there's going to be some kind of formal guidance on server-initiated bidi streams. I'll open a separate issue about changing the WT uni framing.
I think this specific issue was fixed by . Please reopen if I'm wrong.

4.2.  <ins> WebTransport endpoints can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </ins> "WEBTRANSPORT_STREAM" (type=0x41).  The format of the frame SHALL be the frame type, followed by the session ID, encoded as a variable- length integer, followed by the user-specified stream data (fig-bidi- client).  The frame SHALL last until the end of the stream.  <ins> HTTP/3 does not by itself define any semantics for server-initiated bidirectional streams.  If WebTransport setting is negotiated by both endpoints, the syntax of the server-initiated bidirectional streams SHALL be the same as the syntax of client-initated bidirectional streams, that is, a sequence of HTTP/3 frames.  The only frame defined by this document for use within server-initiated bidirectional streams is WEBTRANSPORT_STREAM. </ins>  <ins> TODO: move the paragraph above into a separate draft; define what happens with already existing HTTP/3 frames on server-initiated bidirectional streams. </ins>  <ins> 4.3. </ins> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the


MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.5. </del>  In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data

MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies.  <ins> 4.4. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data


Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  Using coding can be a useful way to better deal with tail losses or with networks with non- <del> congestion losses.  However, coding mechanisms could hide congestion signals to the server.  This memo proposes a discussion on how coding and congestion signals could interact and proposes best current practice. </del>  1.

This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.

Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  Using coding can be a useful way to better deal with tail losses or with networks with non-  <ins> congestion losses.  However, coding mechanisms should not hide congestion signals.  This memo offers a discussion of how coding and congestion control interact. </ins> 1.


it is not an IETF product and is not a standard. There are cases where deploying coding improves the quality of the <del> transmission.  As example, the server may hardly detect tail losses that impact may impact the application layer.  Another example may be the networks where non-congestion losses are persistent and prevent the server from exploiting the link capacity.  RFC5681 defines TCP as a loss-based congestion control and coding mechanisms can hide congestion signals to the server. </del>  Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  This memo discusses

it is not an IETF product and is not a standard. There are cases where deploying coding improves the quality of the  <ins> transmission.  As an example, the server may hardly detect tail losses that impact may impact the application layer [MICHAEL: I don't understand this.  Why would it not detect them?  And why is detecting them the problem?].  Another example are networks where non- congestion losses are persistent and prevent a sender from exploiting the link capacity.  RFC5681 defines TCP as a loss-based congestion control; because coding repairs such losses, blindly applying it may easily lead to an implementation that also hides a congestion signal to the sender.  It is important to ensure that such information hiding does not occur. </ins> Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  This memo discusses


consider congestion control aspects when proposing coding solutions. The proposed recommendations apply for coding at the transport or <del> application layer and coding for tunnels is out-of-the scope of the </del>  document. 2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward <del> Erasure Correction (FEC) channels.  Congestion Control channel carries data packets (from the server to the client) and a potential </del>  information signaling the packets that have been received (from the <del> client to the server).  Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. </del>  3.

consider congestion control aspects when proposing coding solutions. The proposed recommendations apply for coding at the transport or  <ins> application layer.  Coding for tunnels is out of scope for the </ins> document. 2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward  <ins> Erasure Correction (FEC) channels.  The Congestion Control channel carries data packets (from a server to a client) and a potential </ins> information signaling the packets that have been received (from the  <ins> client to the server).  The Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. Inside a host, the CC and FEC entities can be regarded as conceptually separate: As this diagram shows, the inputs to FEC (data to work upon, and signaling from the receiver about losses and/or repaired blocks) are distinct from the inputs to CC.  The latter calculates a sending rate or window from network measurements, and it takes the data to send as input, sometimes along with application requirements such as upper/ lower rate bounds, periods of quiescence, or a priority. It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa - information about repaired blocks may be quite irrelevant to a CC algorithm.  However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, usually as a result of their operation rather than by relaying their own raw inputs.  For example, the network measurements carried out by CC can yield a longer-term statistical measure such as a loss ratio which is useful input for a FEC coding scheme.  Similarly, unequal error protection using fountain codes can be used to assign different priorities to blocks of data, and these priorities can be honored by a CC mechanism. </ins> 3.


3.2. <del> The document focuses on end-to-end coding, i.e. in cases where coding is added at the server and client end points.  The discussions should </del>  then consider fairness with non-coding solutions. 4. <del> The solution can be described as follows: </del>  <del> The client MUST indicate to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </del>  <del> The server MUST be able to detect the "repaired packet" signal. </del>  The base solution does not describe how the congestion control reacts to such signal. The rationale behind this solution is the following: the server has more information on the congestion status and the application <del> characteristics.  Moreover, congestion control should not be splitted between multiple entities otherwise non-optimized decisions may be taken. </del>  The proposed solution applies for coding in the transport and <del> application layers.  The proposed approach is inline with the one in </del>  I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not <del> applies for the interaction between coding under the transport layer </del>  (i.e. not end-to-end), such as coding for tunnels. 5.

3.2.  <ins> The document focuses on end-to-end coding, i.e. cases where coding is added at the server and client end points.  The discussions should </ins> then consider fairness with non-coding solutions. 4.  <ins> The solution can be described as follows: [MICHAEL: So far, it hasn't been clear that we're going to describe a "solution".  A solution to which problem?  I thought we're only discussing how FEC and CC relate.] </ins>  <ins> The client indicates to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </ins>  <ins> The server must be able to detect the "repaired packet" signal. </ins> The base solution does not describe how the congestion control reacts to such signal. The rationale behind this solution is the following: the server has more information on the congestion status and the application  <ins> characteristics.  Moreover, congestion control should not be split between multiple entities, as otherwise non-optimized decisions may be taken. </ins> The proposed solution applies for coding in the transport and  <ins> application layers.  The proposed approach is in-line with the one in </ins> I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not  <ins> apply for the interaction between coding under the transport layer </ins> (i.e. not end-to-end), such as coding for tunnels. 5.


In this solution, the coded packets are sent on top of what is allowed by a congestion window.  Examples of the solution could be <del> adding a given pourcentage of the congestion window as supplementary </del>  packets or sending a given amount of coded packets at a given rate. The redundancy flow can be decorrelated from the congestion control <del> that manages source packets : a secondary congestion control can be </del>  introduced, such as in coupled congestion control for RTP media I- D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than best-effort congestion control RFC6297. <del> The advantage of such solution is that coding would help in challenges cases where transmission losses are persistent. </del>  <del> The drawback of such solution is that it may result in coding </del>  solutions being unfair towards non-coding solutions.  This solutions may result in adding congestion in congested networks.

In this solution, the coded packets are sent on top of what is allowed by a congestion window.  Examples of the solution could be  <ins> adding a given percentage of the congestion window as supplementary </ins> packets or sending a given amount of coded packets at a given rate. The redundancy flow can be decorrelated from the congestion control  <ins> that manages source packets: a secondary congestion control can be </ins> introduced, such as in coupled congestion control for RTP media I- D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than best-effort congestion control RFC6297.  <ins> The advantage of such a solution is that coding would help in challenging cases where transmission losses are persistent. </ins>  <ins> The drawback of such a solution is that it may result in coding </ins> solutions being unfair towards non-coding solutions.  This solutions may result in adding congestion in congested networks.


or preferably send coded packets instead of the following packets in the send buffer. <del> The advantage of this solution is that it does not contribute in adding more congestion than the congestion window allows.  Indeed, all traffic (source and redundancy) is controlled by one congestion control only and TCP metrics for fairness can be indifferently applied in this case. </del>  The main drawback is the decrease of goodput if coded packets are sent but are not used at the client side. 6. <del> Delay-based congestion controls ignore packets that have been repaired with coding.  There is no need to define best current </del>  pratices in this case.  However, more discussions are required for congestion controls that use loss as congestion signals (potentially among other congestion detection mechanism). 6.1. <del> In this solution, the server reacts to repaired packet signals as to congestion-implied packet losses.  That being said, this does not necessarily means that the packets have actually been lost.  The server may have other means to identify that the packet was just out- of-ordered and ignore the repaired packet signals. </del>  The advantages of the solution are (1) that coding mechanisms do not hide congestion signals, such as packets voluntary dropped by a AQM <del> RFC7567 and (2) packets may be repaired faster than with traditionnal retransmission mechanisms. </del>  The drawback of this solution is that, if there is a high non- congestion loss rate, the congestion control throughput may decrease

or preferably send coded packets instead of the following packets in the send buffer.  <ins> The advantage of this solution is that it does not add more traffic than the congestion window allows.  Indeed, all traffic (source and redundancy) is controlled by one congestion control only and TCP metrics for fairness can be indifferently applied in this case. </ins> The main drawback is the decrease of goodput if coded packets are sent but are not used at the client side. 6.  <ins> [MICHAEL: I would remove this section entirely: it only adds to confusion.  If the inputs are seen as distinct, and we say that the raw inputs shouldn't be shared, then why would one even think about what delay-based CC does with this input?  It's just not the right input.]  Delay-based congestion controls ignore packets that have been repaired with coding.  There is no need to define best current </ins> pratices in this case.  However, more discussions are required for congestion controls that use loss as congestion signals (potentially among other congestion detection mechanism). 6.1.  <ins> [MICHAEL: As above, lets remove all of this please.  This text gets in the way of a clean separation.]  In this solution, the server reacts to repaired packet signals as to congestion-implied packet losses.  That being said, this does not necessarily mean that the packets have actually been lost.  The server may have other means to identify that the packet was just out-of-order and ignore the repaired packet signals. </ins> The advantages of the solution are (1) that coding mechanisms do not hide congestion signals, such as packets voluntary dropped by a AQM  <ins> RFC7567 and (2) packets may be repaired faster than with a traditional retransmission mechanisms. </ins> The drawback of this solution is that, if there is a high non- congestion loss rate, the congestion control throughput may decrease


6.2. <del> In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </del>  The advantage of the solution is that in cases where there is no actual congestion, coding could help in improving the transmission

6.2.  <ins> [MICHAEL: this is even just a terrible idea.  There's no good rationale to back off less when a packet is repaired.]  In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </ins> The advantage of the solution is that in cases where there is no actual congestion, coding could help in improving the transmission


6.3. <del> This is the case for delay-based congestion controls.  The interaction between delay-based congestion controls and the delay induced by a coding mechanisms is an open research activity.  That being said, a potential approach would be that loss-based congestion control ignores the "repaired packet" signal. </del>  The advantage of this solution is that coding would provided substantial benefits in cases where there are transmission losses.

6.3.  <ins> [MICHAEL: as above, also here, the signals are discussed as going into both blocks, leading to a strange unification of things that shouldn't be together.  Let's remove this.  Also, the idea of ignoring packet loss for CC is appalling anyway.]  This is the case for delay-based congestion controls.  The interaction between delay- based congestion controls and the delay induced by a coding mechanisms is an open research activity.  That being said, a potential approach would be that loss-based congestion control ignores the "repaired packet" signal. </ins> The advantage of this solution is that coding would provided substantial benefits in cases where there are transmission losses.


7. <del> This section provides a summary on the content in previous sections. The fig:summary sums up some recommendations.  It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit.  Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </del>  8.

7.  <ins> [MICHAEL: I'm sorry to say that I find this table to be in the same style, of wrongly mixing things together, and would like to see it removed altogether.]  This section provides a summary on the content in previous sections.  The fig:summary sums up some recommendations. It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit. Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </ins> 8.


5.4. <del> frames implicitly create a stream and carry stream data.  The Type field in the frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f) to maximize compatibility with QUIC.  However, unlike QUIC, there are only one bit used to determine the fields that are present in the frame: The FIN bit (0x01) indicates that the frame marks the end of the stream.  The final size of the stream is the sum of the length, in bytes, of all data previously sent on this stream and the length of this frame without the length of the Stream ID. </del>  5.5.

The definition was a little loose, so I rewrote it. We only need to use 0x0a and 0x0b, which is lucky and it lets us avoid much of the mess that QUIC has around bits in the type. I've also added definitions for the fields in the frame.

5.4.  <ins> frames implicitly create a stream and carry stream data. The Type field in the frame is either 0x0a or 0x0b.  This uses the same frame types as a QUIC STREAM frame with the OFF bit clear and the LEN bit set.  The FIN bit (0x01) in the frame type indicates that the frame marks the end of the stream in one direction.  Stream data consists of any number of 0x0a frames followed by a terminal 0x0b frame. frames contain the following fields: The stream ID for the stream. Zero or more bytes of data for the stream.  Empty frames MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty frame that neither starts nor ends a stream as a session error. </ins> 5.5.


ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates <del> that the client is prepared to send with a CID but does not wish the </del>  server to use one when sending. A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value <del> indicates that the server will send with the client's CID but does not wish the client to include a CID. </del>  Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for

URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: 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 URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1

ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates  <ins> that the client is prepared to send using a CID but does not wish the </ins> server to use one when sending. A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value  <ins> indicates that the server will send using the client's CID but does not wish the client to include a CID when sending. </ins> Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for


5.2. The following MAC algorithm applies to block ciphers that use the <del> with Encrypt-then-MAC processing described in RFC7366. </del>  5.3.

5.2. The following MAC algorithm applies to block ciphers that use the  <ins> Encrypt-then-MAC processing described in RFC7366. </ins> 5.3.


publication, the early allocation will be deprecated in favor of this assignment.  Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not

publication, the early allocation will be deprecated in favor of this assignment. <ins> A new column "DTLS-Only" is added to the registry.  The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N". </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not


6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del>  7.

URL The example shows in flight 5 Certificate --------> ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished (cid=100) Does this imply that the flight 5 is send with cid = 100 or only the Finished? I would prefer to be able to send also the other handshake messages of the flight with a cid, that would make it harder to disturb handshakes by spoofed handshake messages.
In DTLS 1.2 only the Finished message is encrypted. In the current design we make use of the CIDs only once encryption is enabled. I should explain that only the Finished message contains a CID here.
See additional explanation in PR : URL
I would enjoy it, if the cid could be extended into the not encrypted handshake messages also. Is there any reason, not to do so? My consideration is to make the handshake "slightly more" protected against spoofing. The current protection in RFC6347 is limited to URL and URL . The first applies only to the CLIENTHELLO ("cookie" protection again spoofed CLIENTHELLOs). The second (MAC and Anti-Replay) is only usable after a successful handshake. If an attacker spoofs other handshake messages, the attacker may block a handshake from being successful (even if the time window for that is very small and so it would be a rather expensive attack). Using a CID would enable a implementation either to handshake even when addresses are changing during the handshake or to protect the handshake slightly more (not supporting address changes but) use the CID to validate the handshake message belonging to this handshake. I would leave the chosen strategy to the implementation, enabling implementations to flexible chose the strategy depending on the current handshake load (means: supporting address changes in handshakes as normal operation, but switch dynamically to the more protective one, if a certain relative number of handshake fails.) My current work in progress: URL contains already this feature as experimental extension. It's easy to be added to a cid implementation.
Section 4.1.2 describes an attack where an attacker injects traffic that cannot be correctly processed due to a MAC failure. The reason why MAC failures in DTLS do not lead to a connection termination (unlike in TLS) is that they are much easier to mount: an attacker only needs to know the source and destination IP and port. Section 4.2.1 talks about the cookie exchange, which has been added to prevent amplification attacks against third parties. I would argue that these two attacks are very different from what you are trying to tackle. You would like to add resiliency against on-path (?) attacks sending spoofed handshake messages. I cannot see how the CID provides that extra protection. I understand the use case of address changes during the handshake. The question is whether this is actually something real. If the IP address & port changes during the handshake then this is indeed annoying but how often does this happen?
I mentioned 4.1.2 and 4.2.1 just to sum up the current protection mechanisms. The attack, I consider, is a off-path. e.g. using PSK, someone spoofs a CLIENTKEYEXCHANGE with the identity "ghost". Now it's hard for the server to differentiate the wrong from the right CLIENTKEYEXCHANGE with identity "me". With the CID in the handshake, spoofing into the handshake will be much harder. I don't assume, that such attacks will be easy or happen frequently. But assuming something as a "theft detection" for something valuable, it may be used to block the reporting message.
I don't understand why we'd need to enable CID during handshake, and in particular on Finished? Any sane handshake will complete well before any NAT rebinding has a chance to mess with the path (note that in-flight handshake messages refresh the port bindings...). What kind of use case would that address? Is it connection migrations while handshaking? I'm not sure the "increased robustness against spoofing" argument is a very strong one: the handshake is either robust as-is or we are in trouble :-) Also, would that imply reconsidering the security analysis of the handshake? My preference instead would be to send tls12cid records only after the handshake has completed successfully, i.e. on the first application_data.
FMPOV: protects in the long period before the handshake. With the cookie you could not only spoof CLIENTHELLOs an trigger heavy functions. protects in the long period after the handshake. With the MAC filter it's also not possible to spoof messages at that period (or even repeat them). But in the short period (few seconds) of the handshake itself, I couldn't find a straight forward method, to distinguish between the right inner handshake messages and spoofed ones. Using the CID would offer a similar protection for those inner handshake messages as the cookie for the CLIENTHELLO. I don't assume, that such attack will happen too frequently. But I could assume, if someone has a high interest, such an attack may be used to "deny" a handshake of a certain peer for a certain time period, e.g. "theft detection" for one device may be blocked for a couple of minutes. Only because the CID would offer protection against this "for free", if used during the handshake, I started to try to introduce that.
Let me admit, that the attack in the inner handshake is not likely. Some implementations seems to use the 4.1.2 mechanism even in epoch 0, that may help, but introduces other risks (attack possibilities for the inner handshake). FMPOV, currently you would need too much implementation knowledge to execute such an attack. But, though in my opinion, using the CID within the handshake, offers a protection "for free", I think it's worth to be considered.
Sorry, I'm not sure I understand which kind of extra protection we'd get: when handshaking the CID is spoofable as much as the source address in the UDP packet.
Another argument for not changing the wire image of the record layer during the handshake phase is possible middleboxes interference.
The cookie of 4.2.1 is also spoofable, but for successful spoofing it must be the right cookie for that time period and address. The same applies for the CID. If combined with the address, then it protects, because a spoofer must know the CID. (And sure, it's visible and .. but the cookie is also visible. The point is also the time period, when this CID could be used for spoofing. And that's very short, comparable with the short valid time-period of the cookie.)
I'm still confused, could you characterise precisely your attacker in terms of its goal and position in the network? Thanks!
I don't want to change the wire image more, than this draft already does! With outer type and inner types nothing additional to the already defined additions is introduces, except that it is used already within the handshake. If you want, I update my wip URL and document, how to use a CID in the handshake. Then you see in wireshark, how it works.
With outer type tls12cid(25) and inner types changecipher_spec(20), alert(21), handshake(22) nothing additional to the already defined additions is introduced Yep That's the trouble. Most "enterprise security" middleboxes want to be able to look into the handshake to determine whether a connection is ok according to their policies. After the handshake completes and the connection is considered alright, they just act as blind packet forwarders. To do the handshake inspection they depend on the established wire image of the TLS/DTLS protocol. If we introduce the ability to change the wire format during handshake (as opposed to the post-handshake phase only) we might end up impairing clients that sit behind those boxes.
Goal: Deny successful handshake of a selected peer. Position: off-path, but know the peer's address and the interesting time period. Something missing?
Smells for me, that a "list of typed cid" (see ) may be used, to enable a peer behind such a box to inform the other, not to use the CID during the handshake. types: "plain" - cid only after handshake "plain+" - cid also during handshake
Just for my personal interest: can you name a middlebox, which supports DTLS?
Sorry, now you triggered me: Why should those middleboxes forward my tlscid record, when my address has changed, but block my tlscid record, when it contains a handshake? If the middleboxes are unaware of this draft, but forward my tlscid record even with changed address, I would assume, they forward my tlscid record also with a inner handshake message.
Deny successful handshake of a selected peer. Position: off-path, but know the peer's address and the interesting time period. OK, thanks very much. Frankly, the combination of perfect timing as well as the randomization provided by the source port makes the attack window pretty narrow. On the other hand, allocating state too early (i.e., allocating CIDs without strong commitment from client side) opens up an interesting amount of attack surface on server side.
This is a tricky question. Boxes like typically have scripting capabilities which give their admins lots of leeway. I do not build nor operate any of these so my direct experience is ~0, but speaking with the Symantec guys exactly about how to modify the DTLS wire image to signal the presence of CID in a middlebox-tolerant way, their feedback was "to be sure, just leave the handshake alone as much as possible"... I have no reason to doubt their assessment, also given the ways TLS 1.3 was hit in this same space.
Above I wrote nothing else. ??? what's that ??? Why should the use of cid in the inner handshake messages as well allocate anything additionally? The cid is provided in the CLIENTHELLO and/or SERVERHELLO, it's currently just not send in the inner handshake messages. But there is not more or less to allocate, if they are used with other handshake message or not.
I have also no reason to doubt them, but I'm very unsure, if an address change will then work at all with such boxes. I would really prefer to test such an address change. I couldn't find any hint, that that box supports DTLS at all.
So the critical issue seems: with TLS there are bad experience changing the records with DTLS this experience seems to be missing. Some expect them to be similar bad. I unfortunately suspect them to be either a real disaster (address change not working at all), or not that hard. Without boxes to test and/or people with DTLS-boxes experience, it will be hard to find a solution. So, try to use the mailing list to get more feedback?
Sorry, I fail to understand your argument. What to do with an unknown 5-tuple vs what to do with an unknown C-T in a context where you expect to understand the semantics of the flow seem orthogonal to me.
I don't really understand the above sentence so I know a reply is quite risky :-) Anyway, what I wanted to say is that if you want to use CID during handshake in any meaningful way, it means the party requiring it (e.g., server) needs to allocate state internally to be able to check it on receive. If this allocation is triggered only by one (or two) CH(s), it's pretty easy to mount a "CID exhaustion" attack against the server. Requiring the client to complete the handshake before promoting a "2-tuple" connection into a "CID" connection makes the attack much more demanding and therefore a lot less likely.
(some overlap in the discussion :-) so a updated my comment with the question above.) Try to explain it: Which rules should a box apply to a tls_cid record? It's only valid after a successful handshake? But, how should such a record then be assigned to that successful handshake? Either by knowing the CID (which requires to be aware of this draft), or much weaker by the address, but then it will not work with address changes.
OK, so you don't allocate something on the server side for the CID in the CLIENTHELLO until the handshake is finished? Or you send a CID in the SERVERHELLO without allocating it before the handshake is finished? May be I'm too focused on my implementation, but without an other implementation, which shows what you wrote, it's also hard for me to understand your comments.
At least, I think you target the CID the server side is using. How is it ensured, that the CID in the SERVER_HELLO is unique at least for all established connections and all ongoing handshakes, which are not terminated at that time point?
In my message above s/CID exhaustion/resource exhaustion/ sorry... And yes, you can certainly separate the act of reserving the CID when you decide to send it in the CH from creating state associated with the CID-based session lookup paraphernalia. For example you could use a big enough CID space (say 8 bytes) and reserve your CIDs by means of a monotonically increasing function. And at a later time (my proposal is after the handshake is completed successfully) you grab the memory needed for the CID based session lookup stuff...
Another point is that we'd put more bytes on the wire, increasing the risk of message fragmentation with small MTUs in a situation, the handshake, where the timing of the messaging is such that NAT timeouts are very unlikely and therefore the 5-tuple based demuxing more than adequate.
I can't see a relation of "resource exhaustion" with the usage of the CID in the handshake.
That's right. In my experience, "small MTUs" are rarely used. The highest risk is caused by a larger CLIENTHELLO, which then gets fragmented (see "resource exhaustion"). Though CID makes the CLIENTHELLO larger, it's more an argument, that CID may not be support on such path. FMPOV, a "optimal support" for peers with a very narrow link, should be moved into a other discussion.
The part with having the choice to either "protect the handshake" or "support address changes" should just leave it to the implementation, which strategy is chosen. I would go for a configurable solution, which enables a "dynamic protection", if too many handshakes are ongoing.
I had a chat with Achim and he agreed that we can leave the feature of using CIDs for handshake messages for DTLS 1.3. This will allow us to get this work done faster. DTLS 1.3 encrypts handshake messages earlier and hence already the handshake itself utilize CIDs.
NAME Thanks for your time!
Hi Hannes, Achim, Good, thanks both for taking the time to sort this out. I think it's a very reasonable choice to not introduce scope inflation at this (late) stage. One thing we still need to do though is tighten up a bit the language around when exactly the CID is put on the wire. Something like: "Once a non-empty CID is successfully negotiated, it MUST be sent on the XYZ message and on all subsequent records of the connection" would remove all the uncertainty I guess. I personally have an inclination for XYZ to be the first application data, mainly because I'd like to commit any resources only after I have full confirmation that the client is a good one. However, I don't care whatever choice we end up with, as long as it's written down precisely in 2119 language.
I'm not sure, what "commit" includes or means exactly. To verify the FINISH you will need the "keying material from the crypto context (derived from the specific mastersecret)". According URL a good estimation will be about 128 bytes. In your wording, you use them before you "commit" them? So adding a couple of bytes for CID to that storage, should not make a difference, or?
I mean making a certain CID "used" (not just reserved) and making room for the CID in a lookup table. But, as I said, I won't be unhappy if the "first CID record" happens to be something different than the application data.
From my side the specification is also free to chose, when the peer should start to use the tls_cid records.
NAME I'm still not sure, if I really understand the requirements of your approach. My current feeling is, that you store all the keying and cid stuff in a "context" and provide a address:port-lookup-table for that stored context. One finish, you then want to store this context into a cid-lookup-table. If that's the plan, a cid usage even in the handshake doesn't matter. For epoch 0 records, just still use the address:port lookup and verify the record cid with the stored one. I personally prefer a "relaxed definition", but your case will not be wrong. It just doesn't support address changes during handshake. I guess, after a period of experience, the most user will select that option and use it to secure the handshake without supporting an address change. But that would be left to future experience. After the call with NAME I think it's better not to extend this draft with that idea and instead focus on DTLS 1.3. Therefore I removed the code for this extended usage from my wip and closed this issue. In the meantime, it's really hard to collect all statements over several issues. So, if you still interested in using the RFC6347 record for the finish and start with the tls12_cid records after that, I think, open a new issues (or PR) would make it easier to fetch up this idea.
If this feature is negotiated on, then the MAC calculation changes, even if no connection ID is sent, because of . This needs to be clearly sign-posted.
My preferred interpretation is: uses the original RFC6347, section 4.1 record format URL indicated by the already used content type ids. That includes also the unchanged MAC.
Created a pull request to add clarifying text: URL
NAME it would be great, if you could explain, if you want to use the new record type with an empty CID in order to obfuscate the DTLS payload length. Please note, that currently the specification of this draft turns more into a "strict" usage (see issue ) which will not support the new record type with an empty CID.
Interesting question. Yes, I would like to be able to use the new record type to pad records, but I don't think that it is an especially important consideration. If the design is easier without that, and I suspect that it is, then I am OK with not doing that. A one-octet connection ID is not that much of a burden to pay to get this feature.
So you would then got for adding a 1 byte cid, but still use the ip-address:port to map it to the security context (keying stuff)? Or do you consider only a few connections? For me that is just one of the scenario's, I'm really afraid of! It makes the usage of cid more indeterministic, if the spec "ignores" that kind of usage instead of explicitly considering it! FMPOV, it will be easier, to support then a empty CID record indicating, that still the ip-address:port must be used instead of a 1 byte cid, but then being not strict on the mapping.
Addressed in submitted version -04
In Figure 2, parentheses are used to signify both extensions (connection_id=100) and the addition to the record header (cid=100). I suggest using a different notation here.
NAME can you take a crack at fixing this
Here is an update: URL
Updated diagram merged into the draft.

6. dtls-example2 shows an example exchange where a connection id is used  <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.


10.  IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3.  IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext.  11. Issues against this document are tracked at https://github.com/tlswg/

This PR is on top of
We probably need to create a new IANA registry for RRC message types. The registry should be initialised with the 3 message types we define in the draft.
Ok.

10. <ins> [[to-be-removed: RFC Editor: please replace RFCthis with this RFC number and remove this note.]] 10.1. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. <ins> 10.2. </ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <ins> 10.3. IANA is requested to create a new sub-registry for RRC Message Types in the TLS Parameters registry IANA.tls-parameters, with the policy "expert review" RFC8126. Each entry in the registry must include: The initial state of this sub-registry is as follows: </ins> 11. Issues against this document are tracked at https://github.com/tlswg/


those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity.  10. [[to-be-removed: RFC Editor: please replace RFCthis with this RFC

Signed-off-by: Thomas Fossati
CC NAME
We don't currently discuss any privacy implication associated with CID reuse. We should at least: document how to ensure a new CID is used during path validation in 1.3 flag that 1.2 has no way to work around linkability because CID have the same lifetime as the session

those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <ins> When using DTLS 1.3, peers SHOULD avoid using the same CID on multiple network paths, in particular when initiating connection migration or when probing a new network path, as described in path- validation, as an adversary can otherwise correlate the communication interaction across those different paths.  DTLS 1.3 provides mechanisms to ensure that a new CID can always be used.  In general, an endpoint should proactively send a RequestConnectionId message to ask for new CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold).  Also, in case a peer might have exhausted available CIDs, a migrating endpoint could include NewConnectionId in packets sent on the new path to make sure that the subsequent path validation can use fresh CIDs. Note that DTLS 1.2 does not offer the ability to request new CIDs during the session lifetime since CIDs have the same life-span of the connection.  Therefore, deployments that use DTLS in multihoming environments SHOULD refuse to use CIDs with DTLS 1.2 and switch to DTLS 1.3 if the correlation privacy threat is a concern. </ins> 10. [[to-be-removed: RFC Editor: please replace RFCthis with this RFC


active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the <del> RTT of the active path, a value of 1s SHOULD be used. </del>  Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a

/cc NAME Signed-off-by: Thomas Fossati
In this second paragraph, does this mean T=1s or RTT=1s ?
FMPOV: (because that refers to the default timeout of DTLS 1.2 RFC6347)

active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the  <ins> RTT of the active path, T SHOULD be set to 1s. </ins> Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a


Handshake messages are potentially larger than any given datagram, thus creating the problem of IP fragmentation. <del> Datagram transport protocols, like UDP, are more vulnerable to denial of service attacks and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </del>  3.1.

Attempt to address though I'm not entirely happy with this text. Having gone through the existing text looking at "vulnerable" and "susceptible", it doesn't seem in particularly bad shape, so my comment there may have been stronger than needed.
Copied from EKR's repo Ben Kaduk wrote: "We talk in a couple places about datagram protocols being “vulnerable” or “susceptible” to DoS attacks, which leads me to at least partially read that as meaning that the protocol’s own service will be disrupted; as we know, this is not the whole story, as the reflection/amplification part can facilitate DoS attacks targeted at other services/networks. So perhaps some rewording is in order. "
NAME I would welcome a PR here.
NAME did this,

Handshake messages are potentially larger than any given datagram, thus creating the problem of IP fragmentation.  <ins> Datagram transport protocols, like UDP, are susceptible to abusive behavior effecting denial of service attacks against nonparticipants, and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </ins> 3.1.


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 <del> NOT RECOMMENDED for such transports. </del>  If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts

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  <ins> 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. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


datagram.  Omitting the length field MUST only be used for the last record in a datagram. <del> Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same association.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </del>  When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:

As proposed on list.
Hanno Becker points out that the current text does not cryptographically protect the CID when we have coalesced packets. I created PR to add this feature, but I think instead we should simply require that all packets have CIDs once the CID is established. This seems like a net reduction in complexity. There would be two changes here: Re-emphasize the point already in the DTLS CID spec that you abort if a CID is expected and none is found. Remove the text about allowing implicit CIDs.
NAME NAME
This was resolved by . Please re-open if that's not the case!

datagram.  Omitting the length field MUST only be used for the last record in a datagram.  <ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:


5.7.3.  DTLS 1.3 makes use of the following categories of post-handshake messages:

NAME NAME
(Probably want to fix the typo for "Fixes" in the PR title, but the content looks good to me)
DTLS 1.3 does not really change this aspect compared to earlier DTLS versions. We could reference a number of the other TLS WG documents that attempt to reduce the size of the certificate message, such as Client Certificate URL Cached Info Certificate Compression Following the guidelines in RFC 7925 Other certificate types It may be possible to use the fragmentation mechanism to send one certificate after the other in the certificate chain. Is this what you had in mind?

5.7.3. <ins> 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. 5.7.4. </ins> DTLS 1.3 makes use of the following categories of post-handshake messages:


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 <del> this property for application data.  Applications such as media </del>  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.  TLS cannot be used directly in datagram environments for the following five reasons:

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. TSV-ART Review of draft-ietf-tls-dtls13-41 Reviewer: 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 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? 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? 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...". 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. 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 "clientcertificateurl" extension which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. 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. Section 7.1 "Disruptions" such as reordering do not affect timers, correct? ACKs SHOULD NOT be sent for these flights unless generating the responding flight takes significant time. What is "significant time"? Editorial Comments (NITs) Section 2 The reader is also as to be familiar with [BA] "as" -> "assumed" 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. 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." 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. 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" 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"? 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? 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"?
Addressed in

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  <ins> this property for application data.  Applications, such as media </ins> 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. <ins> Note that while low-latency streaming and gaming use DTLS to protect data (e.g. for protection of a WebRTC data channel), telephony utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. </ins> TLS cannot be used directly in datagram environments for the following five reasons:


thus avoiding concerns about interleaving multiple HelloRetryRequests.  3.2. In DTLS, each handshake message is assigned a specific sequence

thus avoiding concerns about interleaving multiple HelloRetryRequests. <ins> For more detail on timeouts and retransmission, see timeout- retransmissions. </ins> 3.2. In DTLS, each handshake message is assigned a specific sequence


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 <del> the record layer. </del>  Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records

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  <ins> the record layer.  For more information about PMTU issues see pmtu- issues. </ins> Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records


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 <del> (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. </del>  If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts

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  <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts 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. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


5.8.2. <del> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if 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. </del>  Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted,

5.8.2.  <ins> The configuration of timer settings varies with implementations and certain deployment environments require timer value adjustments. Mishandling of the timer can lead to serious congestion problems, for example if 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. </ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted,


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 <del> 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. </del>  5.8.4.

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  <ins> acknowledged.  Several extensions have been standardized to reduce the size of the certificate message, for example the cached information extension RFC7924, certificate compression RFC8879 and RFC6066, which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. </ins> 5.8.4.


first.  Likewise, a server MAY send multiple CertificateRequest messages at once without having completed earlier client authentication requests before.  In contrast, implementations MUST <del> NOT have send KeyUpdate, NewConnectionId or RequestConnectionId </del>  message if an earlier message of the same type has not yet been acknowledged.

first.  Likewise, a server MAY send multiple CertificateRequest messages at once without having completed earlier client authentication requests before.  In contrast, implementations MUST  <ins> NOT have sent KeyUpdate, NewConnectionId or RequestConnectionId </ins> message if an earlier message of the same type has not yet been acknowledged.


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, <del> which are needed to encrypt to decrypt messages found in Record 1. </del>  ack-msg provides the necessary background details for this interaction.

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,  <ins> which are needed to encrypt or decrypt messages found in Record 1. </ins> ack-msg provides the necessary background details for this interaction.


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 <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del>  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 <del> indefinitely until its transmission cap is reached. </del>  8.

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  <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> 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  <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.


sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions.  The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and

Yet another attempt to This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.
This seems promising.
NAME this LGTM, but there's a conflict. Can you resolve prior to merging? NAME are you OK with the new rationale, and text that allows it to be relaxed in the future?
If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES-GCM connection to 2^40.5 compared to 2^64 in DTLS 1.2. This is quite a severe limitation that is not mentioned explicitly. The AEAD limits in themselves are not a problem, but the combination of AEAD limits (2^24.5) and a small epoch (2^16) is a problem. I think this is major problem in some use cases of DTLS. E.g. most 3GPP 5G use cases where DTLS or DTLS/SCTP is used for semi-permanent connections (lasting years) and where the terminating the connection cause severe disturbances. I did not find any discussion about this problem (but I could easily have missed it) It is known that the limit of 2^48 packets in SRTP can be reached and 2^40.5 is significantly smaller than this... If the document was not in such a late stage, I would have suggested to increase the size of the epoch to 32 bits..... I think this and the other problems DTLS 1.3 has with semi-permanent connections has to be solved sooner than later.
NAME thanks for filing this. I hear you about the late stage, but IIRC we never represent the entire epoch on the wire in any case, so it seems like just changing it to 32 bits would be pretty easy, so why not do it now?
How do the chacha20 numbers compare to the AES-GCM ones?
NAME I don't think (D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2^64 (2^48 2^16) AES-GCM 2^40.5 (2^24.5 2^16) AES-GCM 2^39 (2^23 * 2^16)
NAME I am all for changing this now. I made a PR that change epoch from uint16 to uint32. As you say, it seems like a pretty easy change to do. Is uint32 the right size?
Unless you think we should do uint64. NAME NAME what would we have to do to make this change?
URL Magnus Westerlund thinks uint64 would be a safer bet.Michael Tüxen suggest to wrap the uint16 epoch instead. That might be an easier solution. I don't see a direct problem in DTLSPlaintext, ACK message, or recordsequencenumber with a uint16 epoch that is allowed to wrap like: 4, 5, ... 2^16-1, 4, 5, ... 2^16-1, 4, 5, ...
NAME NAME NAME since it's through the IESG we would need to at least raise that this change was made after they had approved it. I suspect that doing some kind of 2-week heads up to the WG/IESG that we want to make the change before landing it. But, if we do that or something more drastic that's really up to NAME
I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that doesn't wrap, and then to ensure that one doesn't practically run into any limits, then an uint64 would be better. An unit32 appears to be sufficient for a quite extreme use case with minimal messages size (which is one DTLS record with 4 byte user message) and high bandwidth (10 Gbps) sustained over a period of more than 5 years before the epoch would wrap. However, to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4-bytes to be certain to have eliminated any practical limitation.
I think a 2-week WGLC and notifying the IESG will suffice.
FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3: No Diffie-Hellman rekeying No post-handshake server authentication No rekeying of the exporter_secret 2^40.5 packets limit 2 minute MSL requirement 2^38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now startnig to consider quite big changes to DTLS/SCTP 1.3 to make this work: URL Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.
Hi, Based on the problems long-lived DTLS/SCTP had with DTLS 1.3 (as well as DTLS 1.2 without renegotiation and respecting AEAD limits) we restructured DTLS/SCTP (RFC6083bis) to use parallel connections instead of relying on renegotiation and post-handshake messages. We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3. It also makes DTLS/SCTP less dependant on version specific DTLS mechanisms. It will hopefully work without changes with any future DTLS 1.4. URL We can now firmly RECOMMEND DTLS 1.3 which I think is very important. 5G is to a large degree replacing or complementing IPsec with TLS, DTLS, and DTLS/SCTP. I will do my best to transition 3GPP to DTLS 1.3 asap. FYI, 3GPP DTLS/SCTP associations have very long lifetimes (can be years), strive for five nines (99.999%) availability and cannot be teared down without causing major disruptions. With such long lifetimes we think mutual reauthentication, rekeying of the SCTP-AUTH key, and forcing attackers to dynamic key exfiltration [RFC7624] are required features. I still think should be done. 2^40.5 packets is quite limiting.
Seems OK.Thanks -- this LGTM. We'll need to do a brief consensus call given the type of change.

sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions. <ins> The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2.  However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate.  See seq-and-epoch for details.  The sequence number is set to be the low order 48 bits of the 64 bit sequence number.  Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0. </ins> The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and


compatibility purposes.  It MUST be ignored for all purposes.  See TLS13; Appendix D.1 for the rationale for this.  The unified header (unified_hdr) is a structure of variable length, as shown in cid_hdr.

compatibility purposes.  It MUST be ignored for all purposes.  See TLS13; Appendix D.1 for the rationale for this. <ins> The least significant 2 bytes of the connection epoch value. </ins> The unified header (unified_hdr) is a structure of variable length, as shown in cid_hdr.


When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below: <del> This 64-bit value is used in the ACK message as well as in the "record_sequence_number" input to the AEAD function. </del>  The entire header value shown in hdr_examples (but prior to record number encryption, see rne) is used as as the additional data value for the AEAD function.  For instance, if the minimal variant is used, the AAD is 2 octets long.  Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with <del> Connection ID. </del>  4.1.

When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:  <ins> This 128-bit value is used in the ACK message. </ins> The entire header value shown in hdr_examples (but prior to record number encryption, see rne) is used as as the additional data value for the AEAD function.  For instance, if the minimal variant is used, the AAD is 2 octets long.  Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with  <ins> Connection ID.  In DTLS 1.3 the 64-bit sequence_number is used as the sequence number for the AEAD computation; unlike DTLS 1.2, the epoch is not included. </ins> 4.1.