-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0RTT and other cryptographically unconfirmed situations (DTLS CIDs, OSCORE B.1.2) #39
Comments
Changing as per today's interim:
(And then this goes into a PR for better change tracking)
|
Also per today's interim, checking we're not missing anything:
|
cc @boaks |
This includes the changes from core-wg#39 (comment) Closes: core-wg#39
Sorry., I'm currently very busy with other tasks, including the Eclipse/Californium 3.13 release. so just some comments:
For me the word "resume" is somehow close to RFC 6347, page 21, figure 2
But in fact, using DTLS CID doesn't require such extra message exchanges. I would prefer to use "continued" or adding "immediately" to resumed. FMPOV, the most discussions and comments gets pretty large (and somehow complicated), because the assumed attack isn't clearly described. That may be much more misleading than helping. In quite a lot of cases, common traffic doesn't provide a specific attack surface and so there is no need to handle them special. And in some cases, techniques as RRC or similar, will be required to be applied. AFAIK spoofing, including spoofing wrong source addresses in DTLS CID records, is done in order to apply a DDoS attack. That requires some amplification so the very first thing, I would got for, is to limit applying countermeasure to message exchanges, which has that amplification. That doesn't only eliminate to apply countermeasure to that part of the message exchanges, which don't come with amplification (e.g. in SCADA that's in my experience about 96% of the traffic without amplification), it also indicates, that the probability for amplification is depending on the use-case low. In the end, an DDoS attack using that will be frequently inefficient, e.g. if you apply the spoofing but only 4% get amplified, that attack doesn't work well. So you need to prepare, but if that will be really applied in the wild, is something else. To be frank, I'm not sure, if all this discussions will make it easier for users to operate the systems more secure, or if that just prevents them from using UDP based protocols at all. But that's more a question for those who are more active in the core group. |
CoAP based documents receive comments on how to correctly work with CIDs, eg. in https://mailarchive.ietf.org/arch/msg/core/Md4gV_0tUq7K6uyIwCjuRHSJOaA/. I'd prefer if those comments would not need to be addressed in those documents but once and for all in some CoAP update such as corr-clar.
The original comments were about DTLS CIDs, but we'd have the same with any zero-round-trip encrypted requests; for example, if an OSCORE server uses RFC8613 Appendix B.1.2 recovery, it's actually legitimate to send something else than a 4.01 Unauthorized along with the Echo option (but that needs some explanation as to when that's OK; DTLS RRCs hint at something similar on the DTLS side without going into CoAP specifics).
Proposed text (wherever that'll fit):
(I think this also picks up everything that is important from Section 3.1 of draft-amsuess-lwig-oscore-00, which doesn't really have a new home with LWIG shut down)
I'm taking the liberty to CC
The text was updated successfully, but these errors were encountered: