Comments (5)
I think that we can do better. I've just opened #58. That uses all the bits in that first octet, which would seem to be a regression, but there are two ways in which we could get another bit back.
The first option is to drop the S-bit I propose and have sequence numbers be 16 bits always. I'd be sad that we lost the small optimization, but that isn't the end of the world.
Perhaps a better option is to drop the second epoch bit. This seems like a bad idea because you potentially have multiple epochs inbound to a server during a 0-RTT handshake. In that case, you have to distinguish between ClientHello (001 or 0011 would work for that), 0-RTT (epoch 1), Handshake (epoch 2), and the ultimate Application Data (epoch 3). If you only have one bit of epoch, then 1 and 3 are indistinguishable.
However, if you look at the way we handle 0-RTT in stacks, it might be OK to allow those late-arriving 0-RTT records to be dropped. For instance, NSS processes 0-RTT and handshake linearly. We don't read the Finished until we have the EndOfEarlyData, and as soon as we process the EOED, we stop accepting new 0-RTT. Part of the reason for this is that once we report handshake success, we don't provide any other signal to an application about the data it receives. So, for NSS, dropping 0-RTT when 1-RTT is available wouldn't change anything for us.
The final option is to not worry about this. The codepoints are there to use. The number of public bits we have is small, and we don't need to signal content type in the clear any more. As I suggested in discussing tlswg/dtls-conn-id#11, perhaps the right answer is to backport the TLS 1.3 record format to DTLS 1.2 and use only one codepoint.
from dtls13-spec.
With regards to 1. Losing the ability to signal 8- v 16-bits sequence would be a bit of a shame, especially in constrained networks (@hannestschofenig, opinions?), but I agree with you it's not the end of the world and I'd be more than happy to immolate it to get one of the reserved bits back. In fact, one bit is sufficient to build a whole header extension machinery if we'd need to -- for spin bit, VEC, etc. I value that much more than a tiny optimisation.
WRT 2. Your argument in favour of dropping the second epoch bit is pretty convincing, so personally I'd be OK with one-bit epoch.
So, I guess we could have something like:
+-+-+-+-+-+-+-+-+
|0|0|1|1|C|L|E|X|
+-+-+-+-+-+-+-+-+
C - CID present
L - Length present
E - Epoch
X - reserved
and 16 bits sequence, always?
from dtls13-spec.
You haven't made a convincing case for an extension mechanism to my mind. And given the choice between having two sequence number lengths and extensions, I'd take the former every time.
from dtls13-spec.
The appalling amount of cycles we have been spending on devising how to do CID signalling in 1.2 is a very good argument in favour of having some kind of extension built in in 1.3. Next time we realise we missed something we won't have to struggle like Houdini. To me this is far more important than a small optimisation of undetermined benefit.
from dtls13-spec.
I don't think this is the right answer. Given that as soon as we can recognize the CID, we can make extensions without changing the header here, I agree with MTabout filling the bits.
from dtls13-spec.
Related Issues (20)
- Francesca Palombini Comments HOT 1
- Martin Duke Comments HOT 1
- Bernard Aboba Comments HOT 1
- AEAD Limits HOT 2
- Retransmissions HOT 4
- Remove ACK from flight table HOT 1
- It seems there a merge conflict. HOT 2
- message_hash construction is ambiguous in DTLS
- Should the protocol specify a mechanism to ensure that the link is disconnected if the peer is restarted or some reason? HOT 6
- DTLS 1.3 limits the number of packets that can be encrypted with AES-GCM to 2^40.5 HOT 11
- Establishing New Associations with Existing Parameters - SHOULD / please add description of the alternatives HOT 1
- Rekeying in (D)TLS 1.3 does not update the exporter_secret HOT 6
- Mention RFC 7457 in Security section HOT 6
- Consider rewording of handshake buffering requirement
- AEAD integrity limits for 0-RTT data HOT 9
- Rename TLS HandshakeTypes
- Peer Address Update HOT 4
- DTLS behavior on received closure alert HOT 9
- Whats the status of this? HOT 5
- Imprecise definitions for handling invalid records HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dtls13-spec.