Draft: draft-ietf-tls-dtls-connection-id

Commentary: According 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 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 ,  can make a contribution for the MAC calculation for non - AEAD ciphers . 
 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 , did n't receive an answer . If that usage is planned , I think it should be addressed explicitly . See : Issue 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 does n'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 
 According  , 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 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 did n't get that . Why are " multiple CIDs " pointing to the same keys ? Is " keys " referring to 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 did n'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 ca n'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 do n'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 ca n'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 i d 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 is n'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 could n'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 ? argument is that wrong , that no more comment is required some time to think on it 
 typo . 
 Given that the CID replaces the IP : PORT tuple for TCP , not including in the MAC does n'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 : 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 can not 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 , it also adds the " internal " cidlength , and I 'm wondering , why . With I 'm not sure , what the order of the " good practice " should be . And agreeing with 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 indicated by the already used content type ids . That includes also the unchanged MAC . 
 Created a pull request to add clarifying text : 
 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 do n'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  
 Is there a implementation available to test interoperability ? I currently plan to introduce in a open source project ( californium / scandium , ) 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 : 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 file . 
 another WIP implementation is at 
 reports errors ? Could you please provide the log with the errors ? Here , or may be as comment in 
 Great , I will try that at the weekend . 
 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 
 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 could n'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  uses also this number ? 
 I 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 :-) . for coap over dtls supporting cid after the handshake 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 ) . 
 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 does n'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 does n'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 does n't require padding ) I can send data successfully to the go server . Go currently does n'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 ) . If possible , can you check the go client forcing to use ? 
 I pushed the update and left a comment 
 hi 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 . 
 " 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 ( ) ( 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- Undefined reference : void ( ) [ ERROR ] /home / hannes / californium / californium- Undefined reference : void Throwable.addSuppressed(Throwable ) [ ERROR ] /home / hannes / californium / californium- Undefined reference : void ( ) [ ERROR ] Failed to execute goal ( 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 ] [ ERROR ] [ ERROR ] After correcting the problems , you can resume the build with the command [ ERROR ] mvn < goals - rf : californium - core 
 Which java jdk do you use ? If I remember well , I saw a similar error last year , when I used  on ubuntu 18.04 . With the current jave update it seems to be solved . I use  ( build 1.8.0191 - 8u191 - b12 - 2ubuntu0.18.04.1 - b12 ) and  ( 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 ) . 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 ? 
 it runs the " etsi plugtest server " . PSK credentials identity " password " secret " sesame " ( or hex  ) Since today , the snapshot of the plugtest server is also available at 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 
 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 . 
 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 
 I 'm going to close this because we want to get to issues 0 . 
 These changes look appropriate .
Paragraph (version B):
The cid value of length indicated with cid_length, as agreed
during the exchange.
Paragraph (version A):
The "cid_length" field is a single octet containing the length of the
connection ID.
Paragraph (version B):
In addition, the CID value is included in the MAC calculation for the
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.
Paragraph (version B):
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.
Paragraph (version B):
This value contains the outer-header content type, i.e. the
tls12_cid.
Paragraph (version B):
This value contains the version number.
Paragraph (version B):
This value contains the length information in the outer-header.
Paragraph (version B):
Value of the negotiated cid.  This field is empty in case a zero-
length cid has been negotiated.
Paragraph (version B):
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.