Change:
According URL this is obvious far away from "appropriate". I would appreciate, if the scope of this draft could be clarified, before adding additional features.
The issue you raised in URL is important and will be addressed in a separate PR. I would like to merge some of the PRs to that we do not have too many conflicts. This PR only provides the text for the additional_data and, since we have changed our mind about it so many times already, I would like to get it into the working draft. Then, Thomas can make a contribution for the MAC calculation for non-AEAD ciphers.
NAME Thank you very much for great patience! It's sure still easy to implement, even with a new MAC for the old RFC 6347 record. As I tried to point out, if there are new use-cases, they should not be obfuscated by introducing only "maverick fields" somewhere, in my opinion, they should be addressed clearly. I still see no argument to include the cid_length into the MAC.
During the discussion of the last weeks, my impression of the scope of this draft has changed. At the begin it was clearly the solution for issues caused by a NAT. With the questions from others about the usage of a empty CID in the MAC, I started to wonder, why this should be used. In the meantime in think, using the new record type (even with an empty CID) would enable peers to obfuscate the DTLS payload length. That feature may be even used without a real CID (therefore using a empty CID). I'm not sure, if this is really planned. I asked for it, but unfortunately, didn't receive an answer. If that usage is planned, I think it should be addressed explicitly. See: Issue URL And working on the implementation, I got also the idea, to use this extension to improve the protection of the handshake itself (see ). Currently the protection seems to be mainly the "randomness of the ip-address:port". But this randomness is not really defined and so using a random CID to lock the handshake may help. The interesting point of this usage would be, that it get's more important, when the address doesn't change (less randomness), so it targets the opposite environment as the original idea (frequently changing (by NAT) to static reachable). In the end this may end up in a "large CID used in the handshake" and no need to use the CID after the handshake. With these other "use-cases", I'm not sure, if the "strict" definitions in should be implemented or if the definitions should be "relaxed". The worst case would be, that the "strict" is mostly implemented, but the users also want the other scenarios independent for the "original idea".
See URL
URL According RFC5246, the record layer protection is split into 3 sections NULL and stream (stream is not used for DTLS) CBC AEAD in this draft, only the NULL is referenced URL If the CID value should be included in that MAC, I would expect, that this draft specifies how to do this for all three variants. By the way, I'm not sure, why the CID should be explicitly included. The CID "points" to the "keys" used to calculate the MAC, with a wrong CID, the wrong "key" will be used and that should cause a MAC violation anyway.
I can fix this text, but there are multiple CIDs pointing to the same keys, so we need to have the CID in the MAC
Sorry, I didn't get that. Why are "multiple CIDs" pointing to the same keys? Is "keys" referring to URL may be I miss something, if ip-address:port is used to identify the "keys", the MAC ensures, that the same keys are used. But the MAC itself is not based on the ip-address:port. or I'm wrong? If, I didn't miss something, then the cid is not required to be directly included in the MAC, as the ip-address:port. Instead is indirect validated with the MAC, as the ip-address:port would also be validated.
You can change CIDs during the connection. Thus, if it's not included in the MAC, you can substitute CIDs.
Sorry, I still can't see the point. Do you mean, the CID could be exchanged during the transmission? FMPOV this seems to be no issue, which could be fixed by including it explicit in the MAC. The ip-address:port may also be exchanged, but are not included explicit in the MAC (this would fail on every NAT). Receiver side: Record contents get protected by a MAC calculated with . If the is exchanged during transmission with , this fails, because, no keys are mapped at the receiver. If the is exchanged during transmission with , this fails, because, the receiver would try to validate the MAC using . For me, it's pretty the same, if you use the ip-address:port or CID to point to the keys, both are considered indirect and don't need to be included explicit. Or is there still a case, I missed?
You can have multiple valid CIDs for the same connection (and hence the same keys) at once. In this case, the attacker can swap them. Including the CID in the MAC protects against that. I understand your analogy with IP address, but this is internal to TLS and might be used by the implementation, and therefore the safest practice is to protect it, like everything else in the header.
I can't see, that this is valid for this version of the draft! If that is true, and the keys are generated in a way, which ensures that they are very likely to be unique for each session, how can I establish connections using different connections id but resulting in the same keys?
May be an handshakes example, which results in that, will clarify it.
Yes, but it might be true with some extension in the future. Moreover, authenticating the whole header is just good practice. In DTLS, connection ids are exchanged at the beginning of the DTLS session Ah.
But isn't the future DTLS 1.3? But the CID is authenticated! Indirect! And, if it's not included in the MAC, then the changes in the implementations should be much smaller. Unfortunately, I had some other reported issues in californium, so I was just able to start to implement CID, but I couldn't finish it right now. I would really prefer, if this draft focus on fixing the NAT pain in DTLS 1.2 and leave the future to DTLS 1.3. But that's just my preference, and not really an argument.
Is for? my argument is that wrong, that no more comment is required takes some time to think on it
typo.
Given that the CID replaces the IP:PORT tuple for TCP, not including in the MAC doesn't make the connection vulnerable to any attack that was not possible before. Indeed leaving it outside the calculations would make the DTLS1.2 implementation simpler and that's a plus.
Regarding the earlier point of not using the correct MAC definition I agree. Here is a proposed change: URL My suggestion is to only focus on AEAD ciphers. Regarding the question whether the inclusion of the cid, cid_length, etc. is necessary or not I am not entirely sure myself either since I cannot see the attack. I do, however, understand that it is good practice to include more information in the MAC.
I still feel, that this extended/changed MAC will introduce some misunderstandings.
I tried to improve clarity in the description. If there is a way to improve the text please let me know. I fear that not making any changes to the additional data computation will require a formal analysis to ensure that it is safe to use.
Yes, and I welcome that very much. FMPOV, it's open, what the "good practice" really includes. In TLS 1.2 it's the header and the "internal" seqnum to prevent repeats. With DTLS 1.2 it's parts of the header in order of the header, and, with the seqnum now also in the header, parts of the header not in order of that header. With this draft, not only the additional header field cid is added, it also adds the "internal" cidlength, and I'm wondering, why. With URL I'm not sure, what the order of the "good practice" should be. And agreeing with URL the other modes need to be defined also.
Will be fixed with
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
Is there a implementation available to test interoperability? I currently plan to introduce in a open source project (californium/scandium, URL) and it would make it much easier, if such a implementation is available.
Huawei is working an updated implementation and so do I. We can start interop testing in Jan 2019, if you want.
That would be great. At least "with itself", californium's scandium works in the meantime :-) ! For interop testing, the used number for the extension in the test should be clear. And the content and format of the additional data. My current state of work in progress: URL The demo-apps/cf-secure is prepared to used a CID (client -> server).
I have cloned the californium repo and switched to the branch. Unfortunately, I get errors when I try to compile the project using instructions in the URL file.
another WIP implementation is at URL
reports errors? Could you please provide the log with the errors? Here, or may be as comment in URL
Great, I will try that at the weekend.
NAME I managed to try your dtls-cid implementation. Unfortunately, the implementation seems not to share a common cipher suite with californium/scandium. From your CLIENTHELLO From my CLIENTHELLO using X509
NAME I add to my wip and validated its compatibility with openssl (see scripts in californium demo-apps/cf-secure folder). But with the GO implementation I could not establish successfully a connection. As far as I could analyze, the master secret is the same, but the hash of the messages differs. Anyway, maybe you can check the compatibility with openssl using that cipher suite ? (I would have created an issue in the linked github repo, but I couldn't find the button for new issues there.)
Though GO uses the currently next "unassigned number for extensions (52)", I can switch to that. Does mbedTLS uses also this number?
NAME I added now also TLSECDHEECDSAWITHAES128GCMSHA256 (0xc02b). Same result, works with openssl but GO reports: I pushed the changes to my wip. I tested using GO as server (port 5684) and the cf-secure with argument .
The californium wip is online :-). URL for coap over dtls supporting cid after the handshake URL for coap over dtls supporting cid also during the handshake For no coap clients, just send four bytes 40 00 12 35 (coap ping with MID 1235). The answer should be 70 00 12 35 (RST for MID 1235).
NAME great! I've just tried my client against this endpoint. Client sends the CID extension (I'm using 52) with a 0-length CID and gets back an handshake failure alert after CH.
I have fixed one thing on server side and now I have no problem interop'ing with openssl (both client and server). Could you please try again?
I adapted to that value in the wip. After CLIENTHELLO? Could your please provide the wireshark capture of your CH? The cid in the extension is documented as So I encoded it with "uint8 cidlength, cid-bytes". do you use also a length?
Thanks for the update! I will check it today a little later.
This is the 0-length CID extension sent by the client: Is this not what you'd expect?
Cool; one limitation to be aware of is that my client currently only handles certificate chains of length one :-)
FYI: I'm running locally and I get the same behaviour as above when I run it without specifying on the command line: Is this maybe the case for the public endpoint? Another interesting thing I've noticed while running locally is that even though my client sends the (0-length) CID extension, server seems to ignore it (it's not mirrored in the SH).
Please update my wip (git pull --force). You use cidlength and cid in the aad? With the go server and the cf-secure client using "X509TRUST CID:0" I get a "Connected" and then a "Disconnected" (maybe the binary payload is not expected). With cf-secure server "X509 NO_AUTH CID:4" and your client I get "panic: dtls: Expected and actual key signature do not match". I will check that more detailed at the weekend.
yes, please add "CID:4" to the argument line. And NO_AUTH to suppress the client certificate request.
The captures with the certificates. Where can I find your certificate? May be using that is more successful :-).
Some updates: The go implementation seems to have issues as client, if the group is used instead of . You may check this with openssl using "-namedcurve prime256v1" to force openssl to use the instead of . (Californium/scandium currently doesn't support .) The reported error from go is "Expected and actual key signature do not match", with both openssl and californium/scandium as server. Using go as server doesn't show this effect and the handshake can be finished. Using the cidlength in aad (PR would removed that) and always add a 0 pad (even if AEAD is used, which doesn't require padding) I can send data successfully to the go server. Go currently doesn't send the FINISHED with tlscid and if a FINISHED with tlscid is received, " unhandled wrapped content type: 22" is reported. I prepared a work around commit, but I must clean it up much more before I can PUSH it. I hope I can update the wip during this week (may be today). NAME If possible, can you check the go client forcing to use ?
I pushed the update and left a comment URL
hi NAME thanks! this should be fixed
quick update: Scandium and the go implementation interop OK, both client and server and over volatile 4-tuples. Cool :-)
Indeed! The basic idea of this draft is really straight forward to implement. Some of the crypto-details, which are discussed (e.g. MAC) must sure be implemented based on the same definition, but that's not too surprising. FMPOV, for sustainability, the scope of the draft should be discussed. Otherwise I would be afraid, that assumption for "special use-cases" will break too much the interoperability. But lets open a new issue for that.
NAME URL "I believe we should allow cid usage already in the handshake itself rather than just for application layer payloads." I will try to polish my approach over the next weekend and push it to the californium sandbox (URL) (5684 will be "cid not used in the handshake").
I tried to compile the Californium code and here are the error messages I get: [ERROR] /home/hannes/californium/californium-URL Undefined reference: void URL() [ERROR] /home/hannes/californium/californium-URL Undefined reference: void Throwable.addSuppressed(Throwable) [ERROR] /home/hannes/californium/californium-URL Undefined reference: void URL() [ERROR] Failed to execute goal URL (default) on project californium-core: Signature errors found. Verify them and ignore them with the proper annotation if needed. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] URL [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :californium-core
Which java jdk do you use? If I remember well, I saw a similar error last year, when I used java11 on ubuntu 18.04. With the current jave update it seems to be solved. I use java8 (build 1.8.0191-8u191-b12-2ubuntu0.18.04.1-b12) and java11 (build 11.0.1+13-Ubuntu-3ubuntu118.04ppa1). If you use the "wipadddtlscid" please note, that the last commit contains fixes for go. Please use the commit before that (currently df6464eb9390). Scandium uses currently 52 for the hello extension.
The "tlscidrecord-already-in-handshake" is removed :-), "the commit before the go fixes" should comply to the current version of this spec.
openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode) javac 10.0.2 Do you have a virtual machine somewhere with Californium running properly?
URL it runs the "etsi plugtest server". PSK credentials identity "password" secret "sesame" (or hex 736573616D65) Since today, the snapshot of the plugtest server is also available at URL for download. If you put also direct before the class definition, it may also compile with java 10. But it's not that tested with java 10 (closer to not tested :-) ).
If you want to use a coap-request GET URL
I re-installed a new version of Ubuntu from scratch and the error is gone.
:-). That sounds good. Remember not to use the HEAD of the wip-branch, it contains the fixes for the "go" implementation (finish without cid). Please use the commit before.
NAME In the meantime I was able to test your update. The FINISH seems to be still a HANDSHAKE record instead of a TLS_CID record. All other issues are solved.
Just for those, who are interested: Based on the CID and the californium implementation I prepared a demonstration load-balancer setup. See URL
I'm going to close this because we want to get to issues 0.
These changes look appropriate.

Discussion:
the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. <ins> The cid value of length indicated with cid_length, as agreed during the exchange. </ins> The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure.

does not make use of the DTLSCompressed structure. In addition, the CID value is included in the MAC calculation for the <del> DTLS record, as shown below.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </del> <ins> DTLS record layer.  At the time of writing ciphers using authenticated encryption with additional data (AEAD) were state-of- the-art.  Hence, this specification updates only the additional data calculation defined in Section 6.2.3.3 of RFC5246, which is re-used by Section 4.1.2.1 of RFC6347. The additional data calculation is extended as follows: As described in Section 6.2.3.3 of RFC5246 this 64-bit value is formed by concatenating the epoch and the sequence number in the order they appear on the wire. This value contains the outer-header content type, i.e. the tls12_cid. This value contains the version number. This value contains the length information in the outer-header. Value of the negotiated cid.  This field is empty in case a zero- length cid has been negotiated. </ins> <del> The "cid_length" field is a single octet containing the length of the connection ID. </del> <ins> 1 byte field indicating the length of the negotiated cid.  If a zero-length cid has been negotiated, and therefore no cid appears on the wire, a cid_length of zero (0) MUST be added. </ins> 5.