Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi Martin, Nothing here depends on using a CID, except perhaps to the extent that the endpoint that observes the "migration" needs to be able to match incoming records with connection state. If they need a CID for that, then this needs a CID. If the threat is only weakly related to the use of a CID, would then the discussion of that more general threats not require also a more general scope than that of this DTLS CID RFC? 5. Victim believes that the connection has migrated and stops sending on the old path. If the new address is attacker controlled, the attacker is now on-path. The attacker can stop forwarding and deny service at its discretion. For a "service deny" no attacker is needed :-), UDP traffic may be lost, DTLS traffic may be ignored, and overloaded peers may response out of the expected time-frame. Most of that is in my opinion the general risk using something as the "public internet" with its grants and no-grants. In all cases of a "service-deny", the peer was, and with CID, is still, intended to try a reconnect strategy (what ever that means according the destination ip-address.) In my sum: - without CID, much more (resumption) handshakes are needed in order to communicate using DTLS. - with CID, such (resumption) handshakes are still required, but much less. Your attack adds some more handshakes, but it doesn't introduce something new, nor do I see, that this will exceed the number of handshakes without CID. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
On Wed, May 5, 2021, at 15:51, Achim Kraus wrote: > For me, this requires, that cid is used in both directions. If not, the > "elicits" doesn't work, or? If both parties are using CID in order to > signal, that the addresses are changing, my feeling is, this scenario is > not that common. (Even more, it will have anyway troubles, with or > without CID.) Nothing here depends on using a CID, except perhaps to the extent that the endpoint that observes the "migration" needs to be able to match incoming records with connection state. If they need a CID for that, then this needs a CID. The attacker can ensure that the other endpoint receives all records from the same address, so whether it uses a CID doesn't matter. > I see, that in cases, where both sides uses cid and dynamic addresse, > there maybe that manipulation. But, I can't see the attack. Maybe I > oversee something. If the "on path attacker" is installed and that > attacker changes the source of the traffic again in order to attack an > other victim peer, the probe will again protect the victim's new source > from being DDoS'ed. > So, please be more explizit, what the resulting attack would look like? 0. Connection is setup between a victim and its peer on a certain network path. 1. Attacker causes victim to believe it has received (valid) packet from a new address. 2. Victim probes toward that address. 3. Attacker captures the probe and forwards it to the victim's peer, spoofing the source address so that it follows the original path (from Step 0). 4. Attacker captures the response to the probe and forwards it to the victim, spoofing the source address to match the address the attacker chose in Step 1. 5. Victim believes that the connection has migrated and stops sending on the old path. If the new address is attacker controlled, the attacker is now on-path. The attacker can stop forwarding and deny service at its discretion. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
as to sit between NAT and server, observe packets, rewrite source IPs, and beat the original packet to the server. Martin On Tue, May 4, 2021 at 6:30 AM Hannes Tschofenig wrote: Hi Martin, The attack described in Section 9.3.3 of https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 makes a lot of assumptions about the attacker. I am not opposed to adding the recommendation but I want to understand it first since there is also a price to pay for it (in terms of complexity and performance). Like elsewhere there is no free lunch. Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that the attacker needs to be able to * observe the packets sent by DTLS endpoints in both directions, and * replay the packets in such a way that they arrive faster than the original packets send by the DTLS endpoints, and * re-write both source and destination IP address to appear like a NAT for both endpoints. The last point is needed to ensure that the packet re-routing persists. IMHO these assumptions hint to an on-path attacker. An on-path attacker (such as a router) can already today perform a denial of service attack on DTLS secured communication by dropping all packets. Ciao Hannes -Original Message- From: Martin Duke via Datatracker Sent: Tuesday, April 20, 2021 9:47 PM To: The IESG Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; tls@ietf.org; Joseph Salowey ; j...@salowey.net Subject: Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT) Martin Duke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ -- COMMENT: -- Thanks for this document. Section 9.3.3 of quic-transport, which deals with basically the same security model, also requires the receiving endpoint to probe the original address, not just the new one, to address a somewhat more difficult attack. It would be good to at least RECOMMEND this behavior for DTLS applications, and/or (repeat/informatively reference) the logic there. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org <mailto:TLS%40ietf.org> https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
I can't claim credit for all of the jankiness in QUIC regarding on-path, off-path, and friends. The attack here is fairly simple: an attacker gets a valid packet and rewrites the source address (to an address it controls). If that packet is accepted by the endpoint that receives it, then it will probe toward the attacker. The attacker needs to rewrite the source address on the packet it receives so that it elicits a genuine response from the peer. Then the attacker captures the response and rewrites the source address. With this, if the attacker can observe two dropped packets (or cause them to be dropped somehow). The first probably has to precede a quiet period that is long enough to complete the process; the latter needs to contain a probe response. If those conditions can be met, then the attack can place itself on-path. Without a probe on the original path, the attacker doesn't have to provide a better route than the original. Adding that probe means that the attacker has to provide a faster and more consistent service, which looks more like a net gain than an attack. On Wed, May 5, 2021, at 01:49, Martin Duke wrote: > Hannes, > > What you might be missing is that Martin Thomson chose what to me is an > unintuitive definition of off-path attacker. On-path means that you a > router that you can drop a packet. An off-path attacker might be an > observer, which can see the packets, or not. I hope that clears things > up a little bit -- although this is very hard to reason about. > > >Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that > >the attacker needs to be able to > >* observe the packets sent by DTLS endpoints in both directions, and > > I would argue it needs to only observe from the client (the one > allegedly changing address) to server. > > >* replay the packets in such a way that they arrive faster than the original > >packets send by the DTLS endpoints, and > > This is the hardest part. The most plausible way is to purchase a > higher SLA from the service provider than the victim traffic. > > >* re-write both source and destination IP address to appear like a NAT for > >both endpoints. > > No, it just needs to rewrite the source address of client->server packets. > > Your second and third capabilities would actually defeat the "probe the > original address" countermeasure provided in the draft. > > So yes, if the "attacker" is actually a router providing a superior > route to the host, there's nothing you can do. > > But the required capabilities are the same for (1) pretending there is > a NAT rebinding where there isn't, and (2) pretending there isn't one > where there is. In both cases, one has to sit between NAT and server, > observe packets, rewrite source IPs, and beat the original packet to > the server. > > Martin > > On Tue, May 4, 2021 at 6:30 AM Hannes Tschofenig > wrote: > > Hi Martin, > > > > The attack described in Section 9.3.3 of > > https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 > > makes a lot of assumptions about the attacker. > > > > I am not opposed to adding the recommendation but I want to understand it > > first since there is also a price to pay for it (in terms of complexity and > > performance). Like elsewhere there is no free lunch. > > > > Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that > > the attacker needs to be able to > > * observe the packets sent by DTLS endpoints in both directions, and > > * replay the packets in such a way that they arrive faster than the > > original packets send by the DTLS endpoints, and > > * re-write both source and destination IP address to appear like a NAT for > > both endpoints. > > > > The last point is needed to ensure that the packet re-routing persists. > > > > IMHO these assumptions hint to an on-path attacker. An on-path attacker > > (such as a router) can already today perform a denial of service attack on > > DTLS secured communication by dropping all packets. > > > > Ciao > > Hannes > > > > -Original Message- > > From: Martin Duke via Datatracker > > Sent: Tuesday, April 20, 2021 9:47 PM > > To: The IESG > > Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; > > tls@ietf.org; Joseph Salowey ; j...@salowey.net > > Subject: Martin Duke's No Objection on > > draft-ietf-tls-dtls-connection-id-11: (with COMMENT) > > > > Martin Duke has entered the following ballot position for > > draft-ietf-tls-dtls-connection-id-11: No Objection > &g
Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hannes, What you might be missing is that Martin Thomson chose what to me is an unintuitive definition of off-path attacker. On-path means that you a router that you can drop a packet. An off-path attacker might be an observer, which can see the packets, or not. I hope that clears things up a little bit -- although this is very hard to reason about. >Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that the attacker needs to be able to >* observe the packets sent by DTLS endpoints in both directions, and I would argue it needs to only observe from the client (the one allegedly changing address) to server. >* replay the packets in such a way that they arrive faster than the original packets send by the DTLS endpoints, and This is the hardest part. The most plausible way is to purchase a higher SLA from the service provider than the victim traffic. >* re-write both source and destination IP address to appear like a NAT for both endpoints. No, it just needs to rewrite the source address of client->server packets. Your second and third capabilities would actually defeat the "probe the original address" countermeasure provided in the draft. So yes, if the "attacker" is actually a router providing a superior route to the host, there's nothing you can do. But the required capabilities are the same for (1) pretending there is a NAT rebinding where there isn't, and (2) pretending there isn't one where there is. In both cases, one has to sit between NAT and server, observe packets, rewrite source IPs, and beat the original packet to the server. Martin On Tue, May 4, 2021 at 6:30 AM Hannes Tschofenig wrote: > Hi Martin, > > The attack described in Section 9.3.3 of > https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 > makes a lot of assumptions about the attacker. > > I am not opposed to adding the recommendation but I want to understand it > first since there is also a price to pay for it (in terms of complexity and > performance). Like elsewhere there is no free lunch. > > Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that > the attacker needs to be able to > * observe the packets sent by DTLS endpoints in both directions, and > * replay the packets in such a way that they arrive faster than the > original packets send by the DTLS endpoints, and > * re-write both source and destination IP address to appear like a NAT for > both endpoints. > > The last point is needed to ensure that the packet re-routing persists. > > IMHO these assumptions hint to an on-path attacker. An on-path attacker > (such as a router) can already today perform a denial of service attack on > DTLS secured communication by dropping all packets. > > Ciao > Hannes > > -Original Message- > From: Martin Duke via Datatracker > Sent: Tuesday, April 20, 2021 9:47 PM > To: The IESG > Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; > tls@ietf.org; Joseph Salowey ; j...@salowey.net > Subject: Martin Duke's No Objection on > draft-ietf-tls-dtls-connection-id-11: (with COMMENT) > > Martin Duke has entered the following ballot position for > draft-ietf-tls-dtls-connection-id-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ > > > > -- > COMMENT: > -- > > Thanks for this document. > > Section 9.3.3 of quic-transport, which deals with basically the same > security model, also requires the receiving endpoint to probe the original > address, not just the new one, to address a somewhat more difficult attack. > It would be good to at least RECOMMEND this behavior for DTLS applications, > and/or (repeat/informatively reference) the logic there. > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi Martin, The attack described in Section 9.3.3 of https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 makes a lot of assumptions about the attacker. I am not opposed to adding the recommendation but I want to understand it first since there is also a price to pay for it (in terms of complexity and performance). Like elsewhere there is no free lunch. Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that the attacker needs to be able to * observe the packets sent by DTLS endpoints in both directions, and * replay the packets in such a way that they arrive faster than the original packets send by the DTLS endpoints, and * re-write both source and destination IP address to appear like a NAT for both endpoints. The last point is needed to ensure that the packet re-routing persists. IMHO these assumptions hint to an on-path attacker. An on-path attacker (such as a router) can already today perform a denial of service attack on DTLS secured communication by dropping all packets. Ciao Hannes -Original Message- From: Martin Duke via Datatracker Sent: Tuesday, April 20, 2021 9:47 PM To: The IESG Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; tls@ietf.org; Joseph Salowey ; j...@salowey.net Subject: Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT) Martin Duke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ -- COMMENT: -- Thanks for this document. Section 9.3.3 of quic-transport, which deals with basically the same security model, also requires the receiving endpoint to probe the original address, not just the new one, to address a somewhat more difficult attack. It would be good to at least RECOMMEND this behavior for DTLS applications, and/or (repeat/informatively reference) the logic there. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ -- COMMENT: -- Thanks for this document. Section 9.3.3 of quic-transport, which deals with basically the same security model, also requires the receiving endpoint to probe the original address, not just the new one, to address a somewhat more difficult attack. It would be good to at least RECOMMEND this behavior for DTLS applications, and/or (repeat/informatively reference) the logic there. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
