Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi Ben, Let me add: - If the scenario uses "dynamic 5-tuples, with CID or without" and "static 5-tuples without CID", - then an attack, with the spoofed 5-tuple (out of that static-5-tuple" pool) and CID (described in https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the communication to such a static-5-tuple without CID. Yes, I think this is the disruption I was pondering. Even then, that "static-5-tuple" peers must be anyway aware, that sometimes new handshakes are required. So that scenario may also depend more on the volume of such attacks, than just on the pure possibility. It does seem like a pretty rare/difficult attack, unlikely to be worth the trouble. But perhaps it is still worht documenting as a property of the protocol ... The point from my side was, that anyway, with or without that attack, even clients with static-5-tuples must take care of their "encryption association". If the client expects responses but didn't get them, then a new handshake may be required. So, I'm not sure, if explicitly mention that, really changes the game. In my experience, such "static-5-tuples" are rare and I would guess, they will benefit from different handling also for other reasons. Therefore I would just spend them an separate endpoint to separate their traffic. ... especially when we can give this recommendation as a workaround. (Actually, is it generally a good idea to try to steer CID-ful and CID-less traffic to different endpoints?) If it's possible to use different endpoints, I think so. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi Achim, Sorry again for the delayed response. (Inline.) On Fri, Sep 18, 2020 at 09:59:55AM +0200, Achim Kraus wrote: > Hi Ben, > > > Am 16.09.20 um 08:31 schrieb Achim Kraus: > > Hi Ben, > > > >>> > >>> If I did't get it, it may be easier to discus this as issue in the > >>> github repo. > >> > >> I think you got it; I am just failing to remember where the "MUST anyway > >> use new handshakes" requirement comes in from. And I guess that also > >> raises the question of what the expected behavior is when a server > >> expects > >> CID-ful traffic on a given 5-tuple and receives an (unencrypted) > >> ClientHello on that 5-tuple. > >> > > > > "when a server expects CID-ful traffic on a given 5-tuple" > > > > I'm not sure, why that should happen. If CID is used, the server should > > not expect a given 5-tuple (at least not longer than a few seconds). > > If a new CLIENT_HELLO arrives, it's first challenge it with a > > HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple > > of a previous CID message" is hit, then just mark/remove the 5-tuple of > > that CID association. That mainly means, you will not be able to reach > > the CID peer with that 5-tuple. That's anyway extremely common to lose > > the ip-route to such CID peers, otherwise CID would not be required. > > > > Let me add: > > - If the scenario uses "dynamic 5-tuples, with CID or without" and > "static 5-tuples without CID", > - then an attack, with the spoofed 5-tuple (out of that static-5-tuple" > pool) and CID (described in > https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the > communication to such a static-5-tuple without CID. Yes, I think this is the disruption I was pondering. > Even then, that "static-5-tuple" peers must be anyway aware, that > sometimes new handshakes are required. So that scenario may also depend > more on the volume of such attacks, than just on the pure possibility. It does seem like a pretty rare/difficult attack, unlikely to be worth the trouble. But perhaps it is still worht documenting as a property of the protocol ... > In my experience, such "static-5-tuples" are rare and I would guess, > they will benefit from different handling also for other reasons. > Therefore I would just spend them an separate endpoint to separate their > traffic. ... especially when we can give this recommendation as a workaround. (Actually, is it generally a good idea to try to steer CID-ful and CID-less traffic to different endpoints?) Thanks, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi Ben, Am 16.09.20 um 08:31 schrieb Achim Kraus: Hi Ben, If I did't get it, it may be easier to discus this as issue in the github repo. I think you got it; I am just failing to remember where the "MUST anyway use new handshakes" requirement comes in from. And I guess that also raises the question of what the expected behavior is when a server expects CID-ful traffic on a given 5-tuple and receives an (unencrypted) ClientHello on that 5-tuple. "when a server expects CID-ful traffic on a given 5-tuple" I'm not sure, why that should happen. If CID is used, the server should not expect a given 5-tuple (at least not longer than a few seconds). If a new CLIENT_HELLO arrives, it's first challenge it with a HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple of a previous CID message" is hit, then just mark/remove the 5-tuple of that CID association. That mainly means, you will not be able to reach the CID peer with that 5-tuple. That's anyway extremely common to lose the ip-route to such CID peers, otherwise CID would not be required. Let me add: - If the scenario uses "dynamic 5-tuples, with CID or without" and "static 5-tuples without CID", - then an attack, with the spoofed 5-tuple (out of that static-5-tuple" pool) and CID (described in https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the communication to such a static-5-tuple without CID. Even then, that "static-5-tuple" peers must be anyway aware, that sometimes new handshakes are required. So that scenario may also depend more on the volume of such attacks, than just on the pure possibility. In my experience, such "static-5-tuples" are rare and I would guess, they will benefit from different handling also for other reasons. Therefore I would just spend them an separate endpoint to separate their traffic. best regards Achim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi Ben, 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. I guess there's maybe a risk that an attacker sets up a CID-ful connection on a given 5-tuple and then disappears, thereby denying the target of the attack the ability to use a CID-less DTLS association on that 5-tuple. But it would be hard to swamp all the ports, so it's only likely to be an issue when fixed ports are used on both sides ... which is known to happen sometimes. Perhaps we should document this in the security considerations. I'm not sure, if I understand that well. Do you assume, that in a network envirnoment, where the 5-tuple is not stable, someone may use a CID and so block the (instable) 5-tuple? Yes, but in that network your peer MUST anyway use new handshakes and so the CID usage will be overwriten by the new handshake. If the 5-tuples are stable, then the attack must spoof the 5-tuple, but the hello verify mechanism will block that. If I did't get it, it may be easier to discus this as issue in the github repo. I think you got it; I am just failing to remember where the "MUST anyway use new handshakes" requirement comes in from. And I guess that also raises the question of what the expected behavior is when a server expects CID-ful traffic on a given 5-tuple and receives an (unencrypted) ClientHello on that 5-tuple. "when a server expects CID-ful traffic on a given 5-tuple" I'm not sure, why that should happen. If CID is used, the server should not expect a given 5-tuple (at least not longer than a few seconds). If a new CLIENT_HELLO arrives, it's first challenge it with a HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple of a previous CID message" is hit, then just mark/remove the 5-tuple of that CID association. That mainly means, you will not be able to reach the CID peer with that 5-tuple. That's anyway extremely common to lose the ip-route to such CID peers, otherwise CID would not be required. Just if you're interested: I have already implemented that CID/5-tuple management in the open source project Eclipse/Californium. (That project also contains a very simple test-NAT, where you may simulate some address changes. But that requires some more docu :-) ). You may check, if that works as you would expect. Any feedback will be very welcome. If you want ot use it with other implementations (e.g. mbedTLS), ensure that the hello extension uses the right assigned IANA value 53. The TLS 1.2 notation is "seq_num" for the implicit sequence number, but DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch and the DTLS (explicit) sequence number. I do not see this concatenation given the name "seq_num" anywhere, so I think we need to reformulate this expression. cid + cid_length + Does this construction preserve injectivity? It seems easier to reason about when the length of an element is always before or always after the element itself, but we put the length first for some of the other fields (that appear after these) so there seems to be some malleability. That order was also discussed a lot. https://github.com/tlswg/dtls-conn-id/pull/29 I would prefer, if this is not changed again without strong arguments! Thanks for the pointer! I am not sure that the specific question about injectivity was raised there, though. (The topic of whether "seq_num" includes epoch was raised but I did not see a clear resolution on my first reading, just https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379) Specifically, the question of "injectivity" is referring to a scenario where I can use different actual values for (cid, cid_length, length_of_DTLSInnerPlaintext, etc.) but have a collision in the constructed cid + cid_length + length_of_DTLSInnerPlaintext + ... (Hmm, we should probably say that length_of_DTLSInnerPlaintext is a 2-byte field...) Attempting to construct a trivial example on the fly, (hex) 01 01 02 02 01 <513 bytes of plaintext content> could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202, DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201, DTLSInnerPlaintext.content = <513 bytes>. The possibility of such a collision weakens the cryptographic protection and should be avoided. If that is going to be changed, the early adopters run into trouble with their deployments! The cid length is not on the wire, so on the wire is (cid 01 01) > 01 01 02 01 <513 bytes of plaintext content> Therefore I don't understand, WHO will inject something, which is not on the wire.
Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi Achim, On Fri, Sep 04, 2020 at 08:58:51AM +0200, Achim Kraus wrote: > Hi Ben, > > see my comments inline. > > Generally you may read the closed issues or PRs with the proper keywords > in https://github.com/tlswg/dtls-conn-id. > > FMPOV most stuff has been discussed over and over. For me, in many cases > there are not that strong arguments for the choosen option over the > others. But these discussion have been at that time. For now, I'm not > sure, if changing details will bring that benefit. > So, please, only address and change things, which are really important. Sure. If there are particular PRs/issues or search queries that are relevant, that can help me revisit the previous discussions. > > Am 04.09.20 um 01:02 schrieb Benjamin Kaduk: > > Hi all, > > > > Sorry for the slow processing time -- my queue is still longer than I am > > happy with. > > > > There's a few apparent inconsistencies that we'll need to tighten up, > > but I don't think there's anything particularly problematic. > > I made a PR for most of the editorial stuff: > > https://github.com/tlswg/dtls-conn-id/pull/75 > > And having pulled the github repo up, it looks like there's a few open > > issues and PRs still, there -- what's the status of those? > > > > #73 FMPOV it's worth to address the issue Thomas found. > I would prefer a wording, which point to RFC6347, 4.1.2.1 and explain > not to use the option "If a DTLS implementation chooses to generate an > alert". Seems reasonable to me, thanks. > > I wonder whether, as a rhetorical device, it would be helpful to give > > the new record payload structure a new name (DTLSCIDCiphertext?) to > > distinguish it from the RFC 6347 DTLSCiphertext. Then we could write > > things like "in order to distinguish between DTLSCiphertext and > > DTLSCIDCiphertext", "the DTLSCIDCiphertext record format is only used > > once encryption is enabled", etc. > > > > Section 3 > > > > 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 Figure 3 MUST be used. > > > > I'm glad that we take a clear stance on what content-type to use for > > zero-length CIDs, though I forget what the reasoning was to fall this > > way vs requiring that the tls12_cid ContentType is used whenever CIDs > > are negotiated. I see how this approach makes some processing easier > > (there is always a CID present when the ContentType is used), but it > > does have the drawback of requiring use of actual CIDs in order to > > get encrypted content-type. If you could remind me why this approach > > was chosen, that will be helpful for subsequent discussions/IESG > > review/etc. > > There have benn some discussion about that, see > > https://github.com/tlswg/dtls-conn-id/issues/22 > https://github.com/tlswg/dtls-conn-id/issues/28 > > So, I'm also glad that in the end of the discussion there was a > consense. I'm not sure, but I think that comment > > https://github.com/tlswg/dtls-conn-id/issues/28#issuecomment-458032109 > > made mainly the decission. Excellent; thank you for these references. > > > > > 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. > > > > I guess there's maybe a risk that an attacker sets up a CID-ful > > connection on a given 5-tuple and then disappears, thereby denying > > the target of the attack the ability to use a CID-less DTLS association > > on that 5-tuple. But it would be hard to swamp all the ports, so it's > > only likely to be an issue when fixed ports are used on both sides ... > > which is known to happen sometimes. Perhaps we should document this in > > the security considerations. > > > > I'm not sure, if I understand that well. > Do you assume, that in a network envirnoment, where the 5-tuple is not > stable, someone may use a CID and so block the (instable) 5-tuple? Yes, > but in that network your peer MUST anyway use new handshakes and so the > CID usage will be overwriten by the new handshake. > If the 5-tuples are stable, then the attack must spoof the 5-tuple, but > the hello verify mechanism will block that. > > If I did't get it, it may be easier to discus this as issue in the > github repo. I think you got it; I am just failing to remember where the "MUST anyway use new handshakes" requirement comes in from. And I guess that also raises the question of what the expected behavior is when a server expects CID-ful traffic on a given 5-tuple and receives an (unencrypted) ClientHello
Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi Ben, see my comments inline. Generally you may read the closed issues or PRs with the proper keywords in https://github.com/tlswg/dtls-conn-id. FMPOV most stuff has been discussed over and over. For me, in many cases there are not that strong arguments for the choosen option over the others. But these discussion have been at that time. For now, I'm not sure, if changing details will bring that benefit. So, please, only address and change things, which are really important. best regards Achim Kraus Am 04.09.20 um 01:02 schrieb Benjamin Kaduk: Hi all, Sorry for the slow processing time -- my queue is still longer than I am happy with. There's a few apparent inconsistencies that we'll need to tighten up, but I don't think there's anything particularly problematic. I made a PR for most of the editorial stuff: https://github.com/tlswg/dtls-conn-id/pull/75 And having pulled the github repo up, it looks like there's a few open issues and PRs still, there -- what's the status of those? #73 FMPOV it's worth to address the issue Thomas found. I would prefer a wording, which point to RFC6347, 4.1.2.1 and explain not to use the option "If a DTLS implementation chooses to generate an alert". I wonder whether, as a rhetorical device, it would be helpful to give the new record payload structure a new name (DTLSCIDCiphertext?) to distinguish it from the RFC 6347 DTLSCiphertext. Then we could write things like "in order to distinguish between DTLSCiphertext and DTLSCIDCiphertext", "the DTLSCIDCiphertext record format is only used once encryption is enabled", etc. Section 3 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 Figure 3 MUST be used. I'm glad that we take a clear stance on what content-type to use for zero-length CIDs, though I forget what the reasoning was to fall this way vs requiring that the tls12_cid ContentType is used whenever CIDs are negotiated. I see how this approach makes some processing easier (there is always a CID present when the ContentType is used), but it does have the drawback of requiring use of actual CIDs in order to get encrypted content-type. If you could remind me why this approach was chosen, that will be helpful for subsequent discussions/IESG review/etc. There have benn some discussion about that, see https://github.com/tlswg/dtls-conn-id/issues/22 https://github.com/tlswg/dtls-conn-id/issues/28 So, I'm also glad that in the end of the discussion there was a consense. I'm not sure, but I think that comment https://github.com/tlswg/dtls-conn-id/issues/28#issuecomment-458032109 made mainly the decission. 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. I guess there's maybe a risk that an attacker sets up a CID-ful connection on a given 5-tuple and then disappears, thereby denying the target of the attack the ability to use a CID-less DTLS association on that 5-tuple. But it would be hard to swamp all the ports, so it's only likely to be an issue when fixed ports are used on both sides ... which is known to happen sometimes. Perhaps we should document this in the security considerations. I'm not sure, if I understand that well. Do you assume, that in a network envirnoment, where the 5-tuple is not stable, someone may use a CID and so block the (instable) 5-tuple? Yes, but in that network your peer MUST anyway use new handshakes and so the CID usage will be overwriten by the new handshake. If the 5-tuples are stable, then the attack must spoof the 5-tuple, but the hello verify mechanism will block that. If I did't get it, it may be easier to discus this as issue in the github repo. When receiving a datagram with the tls12_cid content type, the new MAC computation defined in Section 5 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] MUST be used. I guess that "4.1.2" includes "4.1.2.5 New Cipher Suites", so this is not inadvertently closing off extensibility (not that we expect much in the way of new 1.2 ciphersuites)...right? The MAC calculation have also been discussed: https://github.com/tlswg/dtls-conn-id/issues/25 If the CID is to be included into the MAC, then in my opinion, that must be defined for each supported cipher suite. Section 4 When CIDs are being used, the content to be sent is first wrapped along with its content type and optional padding into a
[TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi all, Sorry for the slow processing time -- my queue is still longer than I am happy with. There's a few apparent inconsistencies that we'll need to tighten up, but I don't think there's anything particularly problematic. I made a PR for most of the editorial stuff: https://github.com/tlswg/dtls-conn-id/pull/75 And having pulled the github repo up, it looks like there's a few open issues and PRs still, there -- what's the status of those? I wonder whether, as a rhetorical device, it would be helpful to give the new record payload structure a new name (DTLSCIDCiphertext?) to distinguish it from the RFC 6347 DTLSCiphertext. Then we could write things like "in order to distinguish between DTLSCiphertext and DTLSCIDCiphertext", "the DTLSCIDCiphertext record format is only used once encryption is enabled", etc. Section 3 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 Figure 3 MUST be used. I'm glad that we take a clear stance on what content-type to use for zero-length CIDs, though I forget what the reasoning was to fall this way vs requiring that the tls12_cid ContentType is used whenever CIDs are negotiated. I see how this approach makes some processing easier (there is always a CID present when the ContentType is used), but it does have the drawback of requiring use of actual CIDs in order to get encrypted content-type. If you could remind me why this approach was chosen, that will be helpful for subsequent discussions/IESG review/etc. 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. I guess there's maybe a risk that an attacker sets up a CID-ful connection on a given 5-tuple and then disappears, thereby denying the target of the attack the ability to use a CID-less DTLS association on that 5-tuple. But it would be hard to swamp all the ports, so it's only likely to be an issue when fixed ports are used on both sides ... which is known to happen sometimes. Perhaps we should document this in the security considerations. When receiving a datagram with the tls12_cid content type, the new MAC computation defined in Section 5 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] MUST be used. I guess that "4.1.2" includes "4.1.2.5 New Cipher Suites", so this is not inadvertently closing off extensibility (not that we expect much in the way of new 1.2 ciphersuites)...right? Section 4 When CIDs are being used, the content to be sent is first wrapped along with its content type and optional padding into a DTLSInnerPlaintext structure. This newly introduced structure is Is it worth mentioning that this is anlogous to the TLS 1.3 TLSInnerPlaintext? (I do see that we have such a reference a couple paragraphs later in the context of the record padding functionality.) enc_content The encrypted form of the serialized DTLSInnerPlaintext structure. In Section 5.2 we refer to the DTLSCiphertext.enc_content as the intermediate encrypted stuff used as input to the MAC for Encrypt-then-MAC processing, which maps up well to this description, but is in conflict with DTLSCiphertext being the bits that actually go on the wire. So we seem to be internally inconsistent about whether enc_content includes the EtM MAC. Most likely it will be easiest to address this in Section 5.2, though. Section 5.x MAC(MAC_write_key, seq_num + The TLS 1.2 notation is "seq_num" for the implicit sequence number, but DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch and the DTLS (explicit) sequence number. I do not see this concatenation given the name "seq_num" anywhere, so I think we need to reformulate this expression. cid + cid_length + Does this construction preserve injectivity? It seems easier to reason about when the length of an element is always before or always after the element itself, but we put the length first for some of the other fields (that appear after these) so there seems to be some malleability. Section 6 - There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such test is defined in this specification. [...] Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms. When delivered such an
