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

Commentary: Text to address the discussion in 
 Completely re - wrote PR 
 Great work ! So alternative I made it , right ? 
 We now have to wait for Martin ,  , and Ekr to agree that the proposed changes are inline with their thinking and then I would submit a new version of the draft for the working group to look at . 
  wrote : So proposal has not been made so far . We should discuss this idea . This is a new privacy - enhancing feature that does not necessarily have anything to do with the CID idea . In some sense this would allow the client and the server to negotiate the use of a traffic obfuscation technique . Achim , Ekr ,  , etc . -- what do you think ? 
 That 's the discussions in issues and I linked to that issue in the previous PR as " Alternative III " To follow up the discussion is really difficult and time intensive . There is also one change left here That request to use the first CID not in FINISH and instead in the record after that . 
 I agree , this adds a new use - case to this draft and is not related to the CID idea . It 's related to the usage of the new introduced record type . I created a issue about the scope of this draft , which mentions that additional use - case . In the meantime I closed that scope issue . My current impression is , that the discussions are split and really hard to follow . Therefore I closed my additional issues in hope , that focus on the CID idea makes it possible to " release " this draft sooner . 
 You are correct . The proposal has been made before . I was confused .... 
  , do you prefer to use " alternative III " instead of what I wrote - up today ? 
  , I notes to the draft about the additional privacy features . So , I believe I captured the scope issue you raised . 
 I prefer any of the solutions ! The difference between the flavours is for me much smaller , than the difference in shifting the timelines would be . For me ,  did a really great job . It would be also great , if you can give your " final " votes to give him a chance to finalize his work :-) . 
 I can live with that proposal as well , as long as we agree that it 's a violation to send an empty CID when one is expected . 
 The idea was to use the new record type even if an empty CID is negotiated . If a none empty CID is negotiated , then this none empty CID has to be used . The mentioned " violation " was , at least from my understand , not intended . 
 Fine ! AFAIK all discussion about features / scope are concluded with that ! FMPOV , . are fixed , when this PR is merged . will then be the only open issue , asking for implementations :-) . 
  , I think , I got a very late catch : If a zero - length CID has been negotiated , and therefore no CID appears on the wire , a cid_length of zero ( 0 ) MUST be . Is not longer valid ! For a empty CID , the RFC6347 record is used with the RFC6347 MAC and not the new MAC . 
 A zero - length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending ( alternately , this can be interpreted as the client wishes the server to use a zero - length CID ; the result is the same ) . This implies that an empty CID and an absent CID are identical . But they do n't have to be . If both endpoints negotiate a zero- length CID , then this extension could be used to enable record padding . The doc is not clear on this point . If a peer sends an empty connectionid extension , what are you supposed to do : send records in the old format . send tls12cid records ( which could be padded ) . send either . It seems like option 2 or 3 give us a nice new feature - the ability to pad records - though 2 forces an additional overhead of 1 byte . Option 3 is somewhat less deterministic though ( it does n't seem like it would be harder to implement though ) . 
 I agree that the old text is wrong . It comes from a previous encoding and MAC structure . I do n't care about the padding feature for ( 2 ) or ( 3 ) , as this is a point fix for DTLS 1.2 . I could live with ( 2 ) but the nondeterminism in ( 3 ) seems bad . 
 Addressed in submitted version  
 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 
 FMPOV , searching for the " length field " assuming that it 's that  pointing to the end of the UDP datagram , should result in many cases in the right length for the connection i d. Moving the connection i d after the " length field " , will hide it from that search , but with the AEAD explicit nonce copied from the header , it will also be easy to find there . Therefore , if it 's intended to hide the connection i d length in tls12_cid records , it must be after the " length field " , and the explicit nonce could not longer be copied from the header to the fragment ( saving 8 bytes ) . It 's no issue , if there is no intention to hide the connection i d length . But then the misguided note above should be removed . 
 We 're not hiding the CID length . It 's transmitted in the clear in the handshake . 
 So what 's the message of it is in many cases possible . 
 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 
 It probably makes sense to be a little more consistent . 
 Makes sense . I will do this after the current wave of pull requests have been reviewed and accepted / rejected . 
 I addressed this issue in PR 
 Addressed with submitted draft version -04
Paragraph (version A):
The reader is assumed to be familiar with DTLS RFC6347.
Paragraph (version B):
This document assumes familiarity with DTLS 1.2 RFC6347.
Paragraph (version A):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure, which carries
the CID which the client wishes the server to use when sending
messages towards it.  A zero-length value indicates that the client
is prepared to send with a CID but does not wish the server to use
one when sending (alternately, this can be interpreted as the client
wishes the server to use a zero-length CID; the result is the same).
Paragraph (version B):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure.  This structure
contains the CID value the client wishes the server to use when
sending messages to the client.  A zero-length CID value indicates
that the client is prepared to send with a CID but does not wish the
server to use one when sending.  Alternatively, this can be
interpreted as the client wishes the server to use a zero-length CID;
the result is the same.
Paragraph (version A):
When a session is resumed, the "connection_id" extension is
negotiated afresh, not retained from previous connections in the
session.
Paragraph (version A):
Because each party sends the value in the "connection_id" extension
that it wants to receive as a connection identifier in encrypted
records, it is possible for an endpoint to use a globally constant
length for such connection identifiers.  This can in turn ease
parsing and connection lookup,
Paragraph (version A):
for example by having the length in question be a compile-time
constant.  Implementations, which want to use variable-length CIDs,
are responsible for constructing the CID in such a way that its
length can be determined on reception.  Note that such
implementations must still be able to send connection identifiers of
different length to other parties.
Paragraph (version A):
Note that it is not possible to parse the records without knowing how
long the CID is.
Paragraph (version A):
In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session
only.  There is no dedicated "CID update" message that allows new
CIDs to be established mid-session, because DTLS 1.2 in general does
not allow TLS 1.3-style post-handshake messages that do not
themselves begin other handshakes.
Paragraph (version A):
DTLS peers switch to the new record layer format, i.e., the record
layer format containing the CID, when encryption is enabled.
Paragraph (version B):
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a globally constant length for such connection
identifiers.  This can in turn ease parsing and connection lookup,
for example by having the length in question be a compile-time
constant.  Implementations, which want to use variable-length CIDs,
are responsible for constructing the CID in such a way that its
length can be determined on reception.  Such implementations must
still be able to send CIDs of different length to other parties.
Note that there is no CID length information included in the record
itself.
Paragraph (version B):
In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session
only.  There is no dedicated "CID update" message that allows new
CIDs to be established mid-session, because DTLS 1.2 in general does
not allow TLS 1.3-style post-handshake messages that do not
themselves begin other handshakes.  When a DTLS session is resumed or
renegotiated, the "connection_id" extension is negotiated afresh.
Paragraph (version B):
If DTLS peers have not negotiated the use of CIDs then the RFC
6347-defined record format and content type MUST be used.
Paragraph (version B):
If DTLS peers have negotiated the use of a CIDs using the ClientHello
and the ServerHello messages then the peers need to take the
following steps.
Paragraph (version B):
The DTLS peers determine whether incoming and outgoing messages need
to use the new record format, i.e., the record format containing the
CID.  The new record format with the the tls12_cid content type is
only used once encryption is enabled.  Plaintext payloads never use
the new record type and the CID content type.
Paragraph (version B):
For sending, if a zero-length CID has been negotiated then the RFC
6347-defined record format and content type MUST be used (see
Section 4.1 of RFC6347) else the new record layer format with the
tls12_cid content type defined in dtls-record12 MUST be used.
Paragraph (version B):
When transmitting a datagram with the tls12_cid content type, the new
MAC computation defined in mac MUST be used.
Paragraph (version B):
For receiving, if the tls12_cid content type is set, then the CID is
used to look up the connection and the security association.  If the
tls12_cid content type is not set, then the connection and security
association is looked up by the 5-tuple and a check MUST be made to
determine whether the expected CID value is indeed zero length.  If
the check fails, then the datagram MUST be dropped.
Paragraph (version B):
When receiving a datagram with the tls12_cid content type, the new
MAC computation defined in mac MUST be used.  When receiving a
datagram with the RFC 6347-defined record format the MAC calculation
defined in Section 4.1.2 of RFC6347 (and Section 4.1.2.4 of RFC6347
for use with AEAD ciphers) MUST be used.
Paragraph (version B):
The CID field is present and contains one or more bytes.
Paragraph (version B):
The MAC calculation follows the process described in mac.
Paragraph (version A):
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):
This specification changes the MAC calculation defined in
Section 4.1.2 of RFC 6347.  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 A):
Value of the negotiated CID.  This field is empty in case a zero-
length CID has been negotiated.
Paragraph (version A):
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.
Paragraph (version B):
1 byte field indicating the length of the negotiated CID.
Paragraph (version A):
This document does not change the security properties of DTLS
RFC6347.  It merely provides a more robust mechanism for associating
an incoming packet with a stored security context.
Paragraph (version B):
The CID-enhanced record layer introduces record padding; a privacy
feature not available with the original DTLS 1.2 RFC.  Padding allows
to inflate the size of the ciphertext making traffic analysis more
difficult.  More details about the padding can be found in
Section 5.4 and Appendix E.3 of RFC 8446.