tlswg / dtls13-spec Goto Github PK
View Code? Open in Web Editor NEWRepo for DTLS 1.3
Repo for DTLS 1.3
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:
Gives 21. Same with 22 and 25. How to properly determine the header format in this case?
Am I missing something?
DTLS borrows the stateless cookie technique used by Photuris {{RFC2522}} and IKE {{RFC7296}}.
What about TCP?
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.
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.
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.
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.
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?
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.
This message appears to be lacking a codepoint.
Also, is this a Handshake message? If so, does it enter the transcript (I assume not).
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.
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
Seems like it makes sense to have an Appendix B similar to the one in TLS1.3 to collect all of the syntax.
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.
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.)
(2MSL, etc.)
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.
The draft there is well out of date and it does more harm than good having it there.
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.
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.
After the sequence number, I assume. This detail disappeared from the other CID draft.
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.
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.
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.
... takes its sample inputs in a different order to the one used in QUIC. This issue tracks the possibility of erasing that difference.
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.
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.
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.
(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.
And extend 2MSL rule to key changes.
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.
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.
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.
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?
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|
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.
DTLS recommends using 25 as the ACK Content Type. CID is using that number based on an early IANA assignment will change DTLS.
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).
I didn't do this in my pass through, because I would prefer to just write it out as "connection ID".
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.
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.
Looks like CI is busted.
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.
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.
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"?
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.
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?
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.
"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.