tlswg/dtls13-spec

Repo for DTLS 1.3

dtls13-spec's Issues

expand on first use "CID"

I didn't do this in my pass through, because I would prefer to just write it out as "connection ID".

Changelog

Version in the record header

If we keep version numbers in the record header, which seems unlikely, we should at least converge on using the same version as in TLS 1.3. TLS 1.3 mandates 0x0301 (TLS version 1.0). That version has no meaning in DTLS, so we use 0x0302 (TLS 1.1) in NSS, which just ends up being disgusting.

Determining the header format

Section 4.1 states:

Implementations can distinguish the two header formats by examining
the first byte:

• If the first byte is alert(21), handshake(22), or ack(proposed,
  25), the record MUST be interpreted as a DTLSPlaintext record.

But 21, 22 and 25 are legitimate values for the first byte of the DTLSCiphertext. For example:

• no CID
• 8-bit sequence number
• no length
• EE = 01

Gives 21. Same with 22 and 25. How to properly determine the header format in this case?
Am I missing something?

IANA Considerations

content types and handshake types needs to say whether they are DTLS-OKAY. The ones defined in the DTLS spec obviously are, but to ensure IANA gets clear instructions we should include a value for these columns.

Identifying versions

This might not be an appropriate question for here, so feel free to close.

The use of draft versions in stacks will switch to 0x0304 shortly. But DTLS is still a little way from done. Are we going to continue to recommend the use of 0x7f00+draft for DTLS?

RequestConnectionId details

This message appears to be lacking a codepoint.

Also, is this a Handshake message? If so, does it enter the transcript (I assume not).

Recommendations for what is in the cookie

Copied from EKR's repo. https://github.com/ekr/dtls13-spec/issues/12
MT writees:

"The server SHOULD use information received in the ClientHello to generate its cookie,such as version, random, ciphersuites. "

This isn't really an interoperability requirement, or even a security one, since the handshake hash includes these. I think that this can be dropped.

(Also in the same paragraph, the client can now double-check the cipher suite as well as the version.)

What about TCP cookies?

DTLS borrows the stateless cookie technique used by Photuris {{RFC2522}} and IKE {{RFC7296}}.

What about TCP?

s4.1 context

RFC6437 s3.1 introduced the concept of a "cryptographic context", which makes sense when reading the following in s4.1:

Conversely, it is possible for records that are protected
by the newly negotiated context to be received prior to
the completion of a handshake.

But, in this version s3.1 is gone so "context" in s4.1 kind of jumps out of nowhere. Does it make sense to replace "context" with "server_handshake_traffic_secret value"?

"Packet" and "datagram"

I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram".

I'm sure that this is just the influence of QUIC and it can be fixed easily.

New header format: proposal to reduce the amount of code points implicitly consumed

Instead of 001, make the fixed prefix 0011 by picking one of the three reserved bits:

 +-+-+-+-+-+-+-+-+
 |0|0|1|1|C|L|X|X|
 +-+-+-+-+-+-+-+-+
 |Ep.| 14 bit    |   Legend:
 +-+-+           |
 |Sequence Number|   Ep. - Epoch
 +-+-+-+-+-+-+-+-+   C   - CID present
 | Connection ID |   L   - Length present
 | (if any,      |   X   - Reserved
 /  length as    /
 |  negotiated)  |
 +-+-+-+-+-+-+-+-+
 | 16 bit Length |
 | (if present)  |
 +-+-+-+-+-+-+-+-+

This way the implicit Content Type allocation is halved to [48, 63] and we get back 16 codepoints.

The definition and examples of the DTLS ciphertext header does not seem to match

The definition and examples of the DTLS ciphertext header does not seem to match

Figure 3:

|0|0|1|C|S|L|E E|

vs.

Figure 4:

|0|0|1|C|1|E|E|1|
|0|0|1|0|0|E|E|0|

Add "Appendix B. Protocol Data Structures and Constant Values"?

Seems like it makes sense to have an Appendix B similar to the one in TLS1.3 to collect all of the syntax.

Generalize rules about acking the last flight

And extend 2MSL rule to key changes.

Who restarts the connection after receiving a bad cookie?

If a server receives a ClientHello with an invalid cookie, it MUST NOT respond with a HelloRetryRequest. Restarting the handshake from scratch, without a cookie, allows the client to recover from a situation where it obtained a cookie that cannot be verified by the server.

I don't understand what this is trying to say. I think that it says that the client, having received a bad cookie will send its second ClientHello off into the void, only to have the handshake time out. Then, the client is expected to restart.

This is probably right. The bad cookie indicates that something is badly wrong. Anything the server might send that would fix this wouldn't be authenticated and so might be exploited by an attack as a denial of service on the connection. However, I'm not sure if any client actually implements this restart.

Spoofed or ignored PTB messages

This probably isn't dire, but it might be worth adding a note to the PMTU section saying that DTLS doesn't bother to defend against spoofed PTB messages. That is consistent with the posture that it takes with respect to just getting the handshake done. It might be wise to recommend ignoring anything less than 576/1280 though.

Remove prohibition on sending before handshake completion

In particular, it is still impermissible to send data prior to completion of the first handshake.

Aside from the "first" being a vestige of renegotiation, I think that this is wrong. Clients send 0-RTT before the handshake completes from their perspective; servers send 0.5-RTT data before they believe the handshake is complete. This needs more nuance.

Content Type - 25 taken by CID

DTLS recommends using 25 as the ACK Content Type. CID is using that number based on an early IANA assignment will change DTLS.

Review key update design

In meetings with folks at the last QUIC interim, we talked at some length about improving the key update design for QUIC. Ultimately, we concluded that the existing design was good and that it might be in some ways superior to that in DTLS. Consider whether that is something that we want to use here.

Where does the connection ID go?

After the sequence number, I assume. This detail disappeared from the other CID draft.

Disable compatibility mode hacks

Right now, my NSS patch for compatibility mode in TLS also includes changes to DTLS. Those changes include the ServerHello format changes, but NSS will ignore the session_id and never send a ChangeCipherSpec from either client or server.

Shrink the record size

https://github.com/ekr/dtls13-spec/issues/5

reference to IETF guidance

s4.1 includes the following:

(Note that the intention here is that implementers
 use the current guidance from the IETF for MSL,
 not that they attempt to interrogate the MSL that
 the system TCP stack is using.)

I think we need a reference to that IETF guidance.

(being pedantic) Also, who is the "they" in this sentence is it implementers/implementations or the IETF?

Clarifying the use of message_seq vs. record sequence_number

Copied from ekr's repo:
Ben wrote:

On page 20, second paragraph, please be clear that it is the
message_seq vs. the record sequence_number that must match
next_receive_seq.
The text in the document says:

DTLS implementations maintain (at least notionally) a
next_receive_seq counter. This counter is initially set to zero.
When a message is received, if its sequence number matches
next_receive_seq, next_receive_seq is incremented and the message is
processed. If the sequence number is less than next_receive_seq, the
message MUST be discarded. If the sequence number is greater than
next_receive_seq, the implementation SHOULD queue the message but MAY
discard it. (This is a simple space/bandwidth tradeoff).

CID needs path validation

(From tlswg/dtls-conn-id#64)

If CID is successfully negotiated, an active man-in-the-middle can freely modify the source address of the UDP datagram — which is not integrity protected — thus potentially causing amplified backscatter to be inadvertently generated by the receiver towards the spoofed address.

(This does not work without CID because the spoofed packet would not reach the other end in the first place.)

To avoid this situation to arise, DTLS should provide a peer address validation sub-protocol — e.g., QUIC’s path validation — to be triggered when the receiver notices a change in the peer source address.

Update gh-pages

The draft there is well out of date and it does more harm than good having it there.

AD parameter for DTLS(Short)Ciphertext is unclear

As I understand, the intent with the record header in AD business was so that DTLS 1.3 would inherit putting the entire header into the AD. However, TLS 1.3 defines the AD as:

and the additional data input is the record header. I.e.,

      additional_data = TLSCiphertext.opaque_type ||
                        TLSCiphertext.legacy_record_version ||
                        TLSCiphertext.length

and DTLS 1.3 defines encrypted_record as:

   encrypted_record:  Identical to the encrypted_record field in a TLS
      1.3 record.

If one takes the first half of the clause, it works out, but "record header" isn't defined formally. If one takes the second half, it suggests that DTLSCiphertext.epoch_and_sequence is not in the AD and it's not clear how DTLSShortCiphertext's AD is defined at all.

Probably worth clarifying this.

Make sure to document how you handle the last ACK in a flight

(2MSL, etc.)

What if ClientHello.cookie is not empty?

Should the server reject the ClientHello if it appears as though the client is responding to a HelloVerifyRequest? What if it also contains a cookie extension?

Connection ID

https://github.com/ekr/dtls13-spec/issues/6

New header format: explicit implications on muxing

The document should contain text that describes the implications on muxing (RFC5764) of the new header format.

Specifically, the implicit ContentType allocation [32, 63] implied by the fixed 001 prefix should end up in the IANA section.

Sliding window size

A minimum window size of 32 MUST be supported, but a window size of 64 is preferred and SHOULD be employed as the default.

The MUST is not consistent with earlier statements about the sliding window being optional.

Also, this is very small. NSS uses a 1024 message window, which takes a tiny amount of memory (128 bytes). The goal here is to make the window large enough to account for reordering, which will depend on rate. I think that it would be enough to say that and leave the exact number to implementations.

Cookie collection attack text

Copied from EKR's repo.

MT writes:

"One potential attack on this scheme is for the attacker to collect a
number of cookies from different addresses and then reuse them to
attack the server. "

This assumes that the attacker can read packets on those paths.

The mitigation doesn't mention including source address information in the cookie. It should, because that makes the cookies less mobile. An extra note that this requires additional complexity if DTLS operates over a multipath substrate - SCTP and ICE spring to mind - but those generally have their own address validation.

The mitigation for this jumps through a lot of hoops in dealing with time-limiting these. But then it recommends a timestamp, which is far more elegant.

Connection ID liveness

This mirrors an open topic of discussion in QUIC, and I assume that we'll want to take the lessons learned there and probably copy whatever the conclusion is.

The problem is that the current design has a server remember all connection IDs that it ever minted. Over time, that might be infeasible for a server. It might be good to limit the number that are in use.

Security guarantees are not equivalent to TLS 1.3

The Abstract states that: "The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees."

This is not true when it comes to Order protection/non-replayability which is states as a guarantee in Appendix E.2 of RFC 8446. DTLS does not provide order protection and may not provide replay protection. I suggested this statement "equivalent security guarantees" is deleted (or rewritten) in the abstract and that some short text describing this is added to the Security Considerations.

Editor's draft is ancient

Looks like CI is busted.

Key update process

Using the TLS process for KeyUpdate - as the current draft does - leads to a suboptimal set of choices in implementations.

Sending KeyUpdate followed immediately by a key change means that KeyUpdate isn't a reliable indicator of a key change at the receiver. If the record containing the KeyUpdate is lost, then the receiver will be unable to decrypt anything sent after it unless it looks at the epoch and tries the new keys. That suggests a design much closer to the one in QUIC, where the KEY_PHASE bit (here, the low bit of the epoch) is the only signal of a key update.

The receiver could buffer those records, but I don't see why it would choose head-of-line blocking and a potentially-large memory commitment over trialing the new epoch.

I would prefer a different design, even if it diverges from the TLS design.

1. That could be the same design as QUIC uses, with the epoch bit signaling intent. The cost there is that you need to use the bit as an acknowledgment of a key update, so you end up having to keep key updates in lock step, even if no update is needed. If there are asymmetric sending patterns, this isn't ideal.

2. Wait until the KeyUpdate is acknowledged before installing new keys. When KeyUpdate is received, the receiver installs new keys, but retains old keys on a timer (the holddown timer would do). The sender waits for the ACK and starts using new keys when it sees it. The cost here is that switching keys can't be immediate and it requires hooks into the ACK handling logic, neither of which is ideal.

Old epochs

Until the handshake has completed, implementations MUST accept packets from the old epoch.

I think that this is a vestige of renegotiation and can be removed. But we might want to say something more helpful about accepting 0-RTT and Handshake at the same time.

Key separation from TLS

Consider whether the key schedule should be separated from TLS. And, if so, how to do that.

QUIC is debating whether or not to change the label prefix (from "tls13 " to "quic ", for instance), or whether it is better to change only the labels for calculating the key, iv, and sn keys.

ChaCha20 header encryption

... takes its sample inputs in a different order to the one used in QUIC. This issue tracks the possibility of erasing that difference.

Amplification factor

The cookie exchange is optional-ish. If a server chooses not to try it, then should we recommend against sending lots and lots of data in response to a small ClientHello? or use MUST in some way? QUIC does, but ties itself into knots in the process.

Omitting length

The requirement to include length on all records that are protected with handshake keys is overly constraining. It is enough to just insist that all records aside from the last one included in the datagram have a length.

Records from different connections in the same datagram

QUIC prohibits the inclusion of packets from multiple connections in the same datagram. DTLS probably should too. With the address tuple no longer being the only way to identify connections, this question is relevant.

Fix the ACK

ekr#2

Additional text about reflection/amplification attacks

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

Linkability across new points of network attachment

A client that migrates to a new point of network attachment probably wants to use a new connection ID. But that attempt will result in linkability if the server doesn't also change. How do we manage that? One approach is to use the cid_immediate instruction. But clients need to be careful to include that instruction in every packet they send lest the server miss it.

QUIC takes a different approach, which is to number all connection IDs combined with a ratchet. If connection ID N is used by one endpoint, its peer has to use connection ID N or greater on that same network path.

Fix Figure 11

1. There is no HRR, so you don't have a cookie in msg 0
2. Certificate should be message 1

deal with RFC 6347 errata

These may have all been addressed by wanted to make sure that we explicit addressed them:
https://www.rfc-editor.org/errata_search.php?rfc=6347

Prohibit concurrent NST and KeyUpdate

The logical way to implement these is to reuse the same retransmission and ACK logic and timers as you use during the handshake. Having multiple concurrent exchanges in progress is possible in theory, and it might even be possible to retain the same timers by delaying responses to a transaction, but it would be easier to implement if you only had to worry about one at a time.