Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Achim Kraus <achimkraus@gmx.net> Wed, 05 May 2021 05:51 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4A93A0E55 for <tls@ietfa.amsl.com>; Tue, 4 May 2021 22:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwuM-GeiTk-Z for <tls@ietfa.amsl.com>; Tue, 4 May 2021 22:51:45 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEC83A0E54 for <tls@ietf.org>; Tue, 4 May 2021 22:51:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1620193896; bh=cSZwQ40tMNo4DrEuqPSQvnMqKm2YGO6pcAqNV2zbrNc=; h=X-UI-Sender-Class:Subject:To:References:From:Cc:Date:In-Reply-To; b=jrIwNU7ZuRsBZdjz+tUyzo8AOlIBQhWy9b+rRuG1HvhWMpM+6MLFuDK8Bxvt5oadh RXHAIq9fOnmFGRva5Fv7YnQ1I/bPRT1blfUcOSYL78rnxwfXd953HTazC0rNfixiD7 rNHA6//qMNxEOb8IFL5NkPi0aSiwG1oBdu1nQe+w=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.10] ([88.152.184.201]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFKGZ-1ll0410zLl-00Flzv; Wed, 05 May 2021 07:51:36 +0200
To: Martin Thomson <mt@lowentropy.net>
References: <161894801377.8373.6532898944771346676@ietfa.amsl.com> <VI1PR08MB2639A557022756B119EAB4EAFA5A9@VI1PR08MB2639.eurprd08.prod.outlook.com> <CAM4esxQaGhv8p3U7pa3JTyLFOvicZ4fM14p8-J5zpyOdBWNw9Q@mail.gmail.com> <72c410c0-f164-4428-9dda-ca62a9c0b419@www.fastmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Cc: tls@ietf.org
Message-ID: <f67218d9-5cd0-397e-a1f7-23a8411d9411@gmx.net>
Date: Wed, 5 May 2021 07:51:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <72c410c0-f164-4428-9dda-ca62a9c0b419@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:IdvOmP5EDa+PhE6DPbLGYCLdIv9lmae/fGhYTTyf5+JiEHHAO+4 B5/Ljm+ZtocqLW8yzvQ2HnqlhGPBkoNm8faY5R6GNYCq8MneqDlL1ezae1+jrQurYbEDImA 9p71m0virKgRc+AjrkN1kDWtwBu49vTQpypNhl+0Zo726/RlWRTAtYT65TmtSfawYsXyaSP wghiSU6ebzTYWAAq7DIsw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:R0963zTH3/c=:otroefcvDcWyyYBLndVqjo CVW/WwJH75Hgvaf6NvkttA8dRhLjnbnzeIAIKuYxTa9+GtGeLthUjl9HKPIOhH421xkv0oOX4 n2+SQE7iME+VJd4SSM5mxmd2klJfzae1khDXt7JjQP8xJ20iRJKc+asvrZMXZKKmsOsI2aIFE X/Mior/im6sDpkvixwX9S/DIoF5Lhe7waPF04wPC9nPUlcd4Izb2ggIIXRhwHZlsDOlvjqdwM 6l19w0gu07Y3qXlDlaaSv1Fzxqhna9WV1ZpggA2HHRxWEuJg3PKSmdV394KA1fygwpdh5K57M q0MndW2GOvezMKAS45xrT3ETdMFJFccLrJPk/wXOi3wSgaHsKfZI2MwftDNz9Jd6NwxHBA2av j4lDjM37N7StSU9ut9DojTW+O2NFjfcUf5sXbUSuFclaYzd5h6VM1SYXakVRtcPmm+rK9z6YD NDlZHgYYTggojp9enE9y2+4CL+rsdcDcj4bHEUjm8RgfbKmeZP0r3txAsy8gLK2mfM1vUhwFL XB7Q0472vG8GaQNtCoSQ8V7ZtHYayF/hJCk9W3z6uUSelNHjgNH9HNXI/CLBkYWDZf8AYxw+V khfV5ikKFm0m03bOeX5wOQ5XFmEP8h7fLDg/Lwstky0D2SGbRUSs2T3Erimq7LIWQ36QVIpR0 a6/Kh6xwoLv8u72xEupNS1uMPZgm0psOP5FxTE5pS5Hkbp01AiUjXzuCr6MC6NNRdFDXPnLUJ vdc77zKBGEbhNi8eg7EVZfVw8hm5ITKGGy9r0tX6IcqBaWxVzyS9kqptUT9FpLuENlK0veqoX IGN8IbnBEt2SzO++6SlSo+r4p28EiRHb1cbOULGsAS471LZ/azS2aWNgJLhbjMYHzNBgyPayU Od4pVSdtYCj3iVCX3Wq96YjoMd8VHnKleXVx8O5PT4xJwbiP2yrbz9NULR7mm2Zv+nioWhSpV fzmV5nTTfzK5uiFfybu/sT7i72Nn1dVB+QxwsJf9dkNFz5THpbwgMlkBDKAgOLLp5e5izEQvQ aJn4jQIkZUSHcCOJj5YE3jNmzb17uYVO0kUzT5GeEmF90KAZR1bupmMLvRsou5/FQ7ilhG0wb uxF4jhKUFPc3XzbANdeJDhuihEnh8QFRfI2aXUdBf4++aONzxTsZdlqNlZ6+Uz1w+SE/vNWzL pcqnxbb+hHGml88Jnf3OmsWkqDLQc7EGQKCQPoq3jPpgaFqkML6ak267+0m6xF7Xb+Dug=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xl3VTx8OZeWw_naH_AfXXR49RfM>
Subject: Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2021 05:51:50 -0000

Hi Martin,

 > 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.

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.)

 > 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.

"With this" and a "setup, where both peer's addresses will change
dynamically", ....

In my experience, one peer uses a fixed ip-address, while the other one
uses a temporary/dynamic assigned one. Yes, the RFC supports that both
peers are using CID. FMPOV, that's more about that the CID principals
maybe used for both directions (with the risk you point), than that
there are real worlds use-cases on a "both sides dynamic".

 > 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.

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?

best regards
Achim Kraus


Am 05.05.21 um 04:45 schrieb Martin Thomson:
> 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
>> <Hannes.Tschofenig@arm.com> 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 <noreply@ietf.org>
>>> Sent: Tuesday, April 20, 2021 9:47 PM
>>> To: The IESG <iesg@ietf.org>
>>> Cc: draft-ietf-tls-dtls-connection-id@ietf.org; tls-chairs@ietf.org; tls@ietf.org; Joseph Salowey <joe@salowey.net>et>; joe@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
>