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

Commentary: The example shows in flight 5 Certificate --------ClientKeyExchange CertificateVerify [ ChangeCipherSpec ] Finished ( cid=100 ) Does this imply that the flight 5 is send with cid = 100 or only the Finished ? I would prefer to be able to send also the other handshake messages of the flight with a cid , that would make it harder to disturb handshakes by spoofed handshake messages . 
 In DTLS 1.2 only the Finished message is encrypted . In the current design we make use of the CIDs only once encryption is enabled . I should explain that only the Finished message contains a CID here . 
 See additional explanation in PR : 
 I would enjoy it , if the cid could be extended into the not encrypted handshake messages also . Is there any reason , not to do so ? My consideration is to make the handshake " slightly more " protected against spoofing . The current protection in RFC6347 is limited to and . The first applies only to the CLIENTHELLO ( " cookie " protection again spoofed CLIENTHELLOs ) . The second ( MAC and Anti - Replay ) is only usable after a successful handshake . If an attacker spoofs other handshake messages , the attacker may block a handshake from being successful ( even if the time window for that is very small and so it would be a rather expensive attack ) . Using a CID would enable a implementation either to handshake even when addresses are changing during the handshake or to protect the handshake slightly more ( not supporting address changes but ) use the CID to validate the handshake message belonging to this handshake . I would leave the chosen strategy to the implementation , enabling implementations to flexible chose the strategy depending on the current handshake load ( means : supporting address changes in handshakes as normal operation , but switch dynamically to the more protective one , if a certain relative number of handshake fails . ) My current work in progress : contains already this feature as experimental extension . It 's easy to be to a cid implementation . 
 Section 4.1.2 describes an attack where an attacker injects traffic that can not be correctly processed due to a MAC failure . The reason why MAC failures in DTLS do not lead to a connection termination ( unlike in TLS ) is that they are much easier to mount : an attacker only needs to know the source and destination IP and port . Section 4.2.1 talks about the cookie exchange , which has been to prevent amplification attacks against third parties . I would argue that these two attacks are very different from what you are trying to tackle . You would like to add resiliency against on - path ( ? ) attacks sending spoofed handshake messages . I can not see how the CID provides that extra protection . I understand the use case of address changes during the handshake . The question is whether this is actually something real . If the IP address & port changes during the handshake then this is indeed annoying but how often does this happen ? 
 I mentioned 4.1.2 and 4.2.1 just to sum up the current protection mechanisms . The attack , I consider , is a off - path . e.g. using PSK , someone spoofs a CLIENTKEYEXCHANGE with the identity " ghost " . Now it 's hard for the server to differentiate the wrong from the right CLIENTKEYEXCHANGE with identity " me " . With the CID in the handshake , spoofing into the handshake will be much harder . I do n't assume , that such attacks will be easy or happen frequently . But assuming something as a " theft detection " for something valuable , it may be used to block the reporting message . 
 I do n't understand why we 'd need to enable CID during handshake , and in particular on Finished ? Any sane handshake will complete well before any NAT rebinding has a chance to mess with the path ( note that in - flight handshake messages refresh the port bindings ... ) . What kind of use case would that address ? Is it connection migrations while handshaking ? I 'm not sure the " increased robustness against spoofing " argument is a very strong one : the handshake is either robust as - is or we are in trouble :-) Also , would that imply reconsidering the security analysis of the handshake ? My preference instead would be to send tls12cid records only after the handshake has completed successfully , i.e. on the first application_data . 
 FMPOV : 1 protects in the long period before the handshake . With the cookie you could not only spoof CLIENTHELLOs an trigger heavy functions . 2 protects in the long period after the handshake . With the MAC filter it 's also not possible to spoof messages at that period ( or even repeat them ) . But in the short period ( few seconds ) of the handshake itself , I could n't find a straight forward method , to distinguish between the right inner handshake messages and spoofed ones . Using the CID would offer a similar protection for those inner handshake messages as the cookie for the CLIENTHELLO . I do n't assume , that such attack will happen too frequently . But I could assume , if someone has a high interest , such an attack may be used to " deny " a handshake of a certain peer for a certain time period , e.g. " theft detection " for one device may be blocked for a couple of minutes . Only because the CID would offer protection against this " for free " , if used during the handshake , I started to try to introduce that . 
 Let me admit , that the attack in the inner handshake is not likely . Some implementations seems to use the 4.1.2 mechanism even in epoch 0 , that may help , but introduces other risks ( attack possibilities for the inner handshake ) . FMPOV , currently you would need too much implementation knowledge to execute such an attack . But , though in my opinion , using the CID within the handshake , offers a protection " for free " , I think it 's worth to be considered . 
 Sorry , I 'm not sure I understand which kind of extra protection we 'd get : when handshaking the CID is spoofable as much as the source address in the UDP packet . 
 Another argument for not changing the wire image of the record layer during the handshake phase is possible middleboxes interference . 
 The cookie of 4.2.1 is also spoofable , but for successful spoofing it must be the right cookie for that time period and address . The same applies for the CID . If combined with the address , then it protects , because a spoofer must know the CID . ( And sure , it 's visible and .. but the cookie is also visible . The point is also the time period , when this CID could be used for spoofing . And that 's very short , comparable with the short valid time - period of the cookie . ) 
 I 'm still confused , could you characterise precisely your attacker in terms of its goal and position in the network ? Thanks ! 
 I do n't want to change the wire image more , than this draft already does ! With outer type and inner types nothing additional to the already defined additions is introduces , except that it is used already within the handshake . If you want , I update my wip and document , how to use a CID in the handshake . Then you see in wireshark , how it works . 
 With outer type tls12cid(25 ) and inner types changecipher_spec(20 ) , alert(21 ) , handshake(22 ) nothing additional to the already defined additions is introduced Yep That 's the trouble . Most " enterprise security " middleboxes want to be able to look into the handshake to determine whether a connection is ok according to their policies . After the handshake completes and the connection is considered alright , they just act as blind packet forwarders . To do the handshake inspection they depend on the established wire image of the TLS / DTLS protocol . If we introduce the ability to change the wire format during handshake ( as opposed to the post - handshake phase only ) we might end up impairing clients that sit behind those boxes . 
 Goal : Deny successful handshake of a selected peer . Position : off - path , but know the peer 's address and the interesting time period . Something missing ? 
 Smells for me , that a " list of typed cid " ( see ) may be used , to enable a peer behind such a box to inform the other , not to use the CID during the handshake . types : " plain " - cid only after handshake " plain+ " - cid also during handshake 
 Just for my personal interest : can you name a middlebox , which supports DTLS ? 
 Sorry , now you triggered me : Why should those middleboxes forward my tlscid record , when my address has changed , but block my tlscid record , when it contains a handshake ? If the middleboxes are unaware of this draft , but forward my tlscid record even with changed address , I would assume , they forward my tlscid record also with a inner handshake message . 
 Deny successful handshake of a selected peer . Position : off - path , but know the peer 's address and the interesting time period . OK , thanks very much . Frankly , the combination of perfect timing as well as the randomization provided by the source port makes the attack window pretty narrow . On the other hand , allocating state too early ( i.e. , allocating CIDs without strong commitment from client side ) opens up an interesting amount of attack surface on server side . 
 This is a tricky question . Boxes like typically have scripting capabilities which give their admins lots of leeway . I do not build nor operate any of these so my direct experience is ~0 , but speaking with the Symantec guys exactly about how to modify the DTLS wire image to signal the presence of CID in a middlebox - tolerant way , their feedback was " to be sure , just leave the handshake alone as much as possible " ... I have no reason to doubt their assessment , also given the ways TLS 1.3 was hit in this same space . 
 Above I wrote nothing else . ? ? ? what 's that ? ? ? Why should the use of cid in the inner handshake messages as well allocate anything additionally ? The cid is provided in the CLIENTHELLO and/or SERVERHELLO , it 's currently just not send in the inner handshake messages . But there is not more or less to allocate , if they are used with other handshake message or not . 
 I have also no reason to doubt them , but I 'm very unsure , if an address change will then work at all with such boxes . I would really prefer to test such an address change . I could n't find any hint , that that box supports DTLS at all . 
 So the critical issue seems : with TLS there are bad experience changing the records with DTLS this experience seems to be missing . Some expect them to be similar bad . I unfortunately suspect them to be either a real disaster ( address change not working at all ) , or not that hard . Without boxes to test and/or people with DTLS - boxes experience , it will be hard to find a solution . So , try to use the mailing list to get more feedback ? 
 Sorry , I fail to understand your argument . What to do with an unknown 5 - tuple vs what to do with an unknown C - T in a context where you expect to understand the semantics of the flow seem orthogonal to me . 
 I do n't really understand the above sentence so I know a reply is quite risky :-) Anyway , what I wanted to say is that if you want to use CID during handshake in any meaningful way , it means the party requiring it ( e.g. , server ) needs to allocate state internally to be able to check it on receive . If this allocation is triggered only by one ( or two ) CH(s ) , it 's pretty easy to mount a " CID exhaustion " attack against the server . Requiring the client to complete the handshake before promoting a " 2 - tuple " connection into a " CID " connection makes the attack much more demanding and therefore a lot less likely . 
 ( some overlap in the discussion :-) so a updated my comment with the question above . ) Try to explain it : Which rules should a box apply to a tls_cid record ? It 's only valid after a successful handshake ? But , how should such a record then be assigned to that successful handshake ? Either by knowing the CID ( which requires to be aware of this draft ) , or much weaker by the address , but then it will not work with address changes . 
 OK , so you do n't allocate something on the server side for the CID in the CLIENTHELLO until the handshake is finished ? Or you send a CID in the SERVERHELLO without allocating it before the handshake is finished ? May be I 'm too focused on my implementation , but without an other implementation , which shows what you wrote , it 's also hard for me to understand your comments . 
 At least , I think you target the CID the server side is using . How is it ensured , that the CID in the  is unique at least for all established connections and all ongoing handshakes , which are not terminated at that time point ? 
 In my message above s / CID exhaustion / resource exhaustion/ sorry ... And yes , you can certainly separate the act of reserving the CID when you decide to send it in the CH from creating state associated with the CID - based session lookup paraphernalia . For example you could use a big enough CID space ( say 8 bytes ) and reserve your CIDs by means of a monotonically increasing function . And at a later time ( my proposal is after the handshake is completed successfully ) you grab the memory needed for the CID based session lookup stuff ... 
 Another point is that we 'd put more bytes on the wire , increasing the risk of message fragmentation with small MTUs in a situation , the handshake , where the timing of the messaging is such that NAT timeouts are very unlikely and therefore the 5 - tuple based demuxing more than adequate . 
 I ca n't see a relation of " resource exhaustion " with the usage of the CID in the handshake . 
 That 's right . In my experience , " small MTUs " are rarely used . The highest risk is caused by a larger CLIENTHELLO , which then gets fragmented ( see " resource exhaustion " ) . Though CID makes the CLIENTHELLO larger , it 's more an argument , that CID may not be support on such path . FMPOV , a " optimal support " for peers with a very narrow link , should be moved into a other discussion . 
 The part with having the choice to either " protect the handshake " or " support address changes " should just leave it to the implementation , which strategy is chosen . I would go for a configurable solution , which enables a " dynamic protection " , if too many handshakes are ongoing . 
 I had a chat with  and he agreed that we can leave the feature of using CIDs for handshake messages for DTLS 1.3 . This will allow us to get this work done faster . DTLS 1.3 encrypts handshake messages earlier and hence already the handshake itself utilize CIDs . 
 Thanks for your time ! 
 Hi Hannes , Achim , Good , thanks both for taking the time to sort this out . I think it 's a very reasonable choice to not introduce scope inflation at this ( late ) stage . One thing we still need to do though is tighten up a bit the language around when exactly the CID is put on the wire . Something like : " Once a non - empty CID is successfully negotiated , it MUST be sent on the XYZ message and on all subsequent records of the connection " would remove all the uncertainty I guess . I personally have an inclination for  to be the first application data , mainly because I 'd like to commit any resources only after I have full confirmation that the client is a good one . However , I do n't care whatever choice we end up with , as long as it 's written down precisely in 2119 language . 
 I 'm not sure , what " commit " includes or means exactly . To verify the FINISH you will need the " keying material from the crypto context ( derived from the specific mastersecret ) " . According a good estimation will be about 128 bytes . In your wording , you use them before you " commit " them ? So adding a couple of bytes for CID to that storage , should not make a difference , or ? 
 I mean making a certain CID " used " ( not just reserved ) and making room for the CID in a lookup table . But , as I said , I wo n't be unhappy if the " first CID record " happens to be something different than the application data . 
 From my side the specification is also free to chose , when the peer should start to use the tls_cid records . 
 I 'm still not sure , if I really understand the requirements of your approach . My current feeling is , that you store all the keying and cid stuff in a " context " and provide a address : port - lookup - table for that stored context . One finish , you then want to store this context into a cid - lookup - table . If that 's the plan , a cid usage even in the handshake does n't matter . For epoch 0 records , just still use the address : port lookup and verify the record cid with the stored one . I personally prefer a " relaxed definition " , but your case will not be wrong . It just does n't support address changes during handshake . I guess , after a period of experience , the most user will select that option and use it to secure the handshake without supporting an address change . But that would be left to future experience . After the call with I think it 's better not to extend this draft with that idea and instead focus on DTLS 1.3 . Therefore I removed the code for this extended usage from my wip and closed this issue . In the meantime , it 's really hard to collect all statements over several issues . So , if you still interested in using the RFC6347 record for the finish and start with the tls12_cid records after that , I think , open a new issues ( or PR ) would make it easier to fetch up this idea . 
 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 -04 
 In Figure 2 , parentheses are used to signify both extensions ( connection_id=100 ) and the addition to the record header ( cid=100 ) . I suggest using a different notation here . 
 can you take a crack at fixing this 
 Here is an update : 
 Updated diagram merged into the draft .
Paragraph (version A):
dtls-example2 shows an example exchange where a connection id is used
uni-directionally from the client to the server.
Paragraph (version B):
dtls-example2 shows an example exchange where a connection id is used
uni-directionally from the client to the server.  To indicate that a
connection_id has zero length we use the term 'connection_id=empty'.
Paragraph (version B):
Note: In the example exchange the CID is included in the record layer
once encryption is enabled.  In DTLS 1.2 only one handshake message
is encrypted, namely the Finished message.  Since the example shows
how to use the CID for payloads sent from the client to the server
only the record layer payload containing the Finished messagen
contains a CID.  Application data payloads sent from the client to
the server contain a CID in this example as well.