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

Martin Duke <martin.h.duke@gmail.com> Tue, 04 May 2021 15:50 UTC

Return-Path: <martin.h.duke@gmail.com>
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 C268F3A0CDD; Tue, 4 May 2021 08:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 (2048-bit key) header.d=gmail.com
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 VRJV7ZzHQeWd; Tue, 4 May 2021 08:49:56 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8E83A0CDB; Tue, 4 May 2021 08:49:56 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id e2so6758487ilr.1; Tue, 04 May 2021 08:49:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HYnOQTbRpfftZiXyGz7lkXcftmWBa4FiZjYO68pgWyQ=; b=mj3mZd5f1epXJMGlwsCcLpaTl/TOY6ExZtcPjR+4+QaBKKmAzrhi1uZJ00K4me3la2 SgSoXiakM83FdOqYwolXb53icu4QN/EQtZCe4Ty2qxCJOPwTBtu4aernQ5VjAzx6pNEr pkoc0ingVvIR87kPAbNYxlGNrxZeyKIr68R/jCzPKIKWkDvuCF8F2N2BM+EdHlaIb5t3 rS9Qr/rdJ0P5Q0ZdQNrLN38yRxaBzuQYw5kC5LIK7F4YzSxrX5v5aQGhvBtclmbs1mom aOpBvNbRFsJKPdJ2kMLZIplgnkfbgUKULrGFxS/H3ziPd6awjONLRCcjAzr74IZTrk2T ijcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HYnOQTbRpfftZiXyGz7lkXcftmWBa4FiZjYO68pgWyQ=; b=jrSOE/+qALAI1CxJWNOCFmoKia2/wHvXziXh2deaXJRLKGV4fgHJ9peVbXT7RAriTA xKfhJ7Mp61pzGUN5urUs6tCU86x8DngVR0iNCFKcdb05S+DMwKi5cCLXkU3OQ7Q4+Kgo ZR4tnbsrbVHgCR7Psobl9alnYBbfQA3gjQmGMRUOE7FryOX9SQJeu/huZdgdYmJfNFct jogx5qQb61ik/93nQLDbVPaj5m7baVlvpnqDA+1lNEqUJ7gKUscEKicyEmZy88X3dHOw aHNCTRprI2Ohkiysd5DvOxG5+8QJvdBLHDsO3Ns32/U9pzlvTL9ZYZPbhKGaFBlPIVEo peAA==
X-Gm-Message-State: AOAM532OBhMREU4as/xMK4NhzxPjAx/WFRjDPwDKGmKgK09kQ4AlFznl xkRx0FMJYwE42GN6O3OP092oyTznSnOc20n8u7mCfpojzZZ/5vBA
X-Google-Smtp-Source: ABdhPJxhZZdWM6RwgDB6uG4bCu2oOh3o8KXYg5m1aDcieFsu5FXPxyatjN76QnXf/y4JBmJbWLtrfeRfaqrYMlZdh/M=
X-Received: by 2002:a05:6e02:2162:: with SMTP id s2mr21238501ilv.237.1620143393525; Tue, 04 May 2021 08:49:53 -0700 (PDT)
MIME-Version: 1.0
References: <161894801377.8373.6532898944771346676@ietfa.amsl.com> <VI1PR08MB2639A557022756B119EAB4EAFA5A9@VI1PR08MB2639.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR08MB2639A557022756B119EAB4EAFA5A9@VI1PR08MB2639.eurprd08.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 4 May 2021 08:49:44 -0700
Message-ID: <CAM4esxQaGhv8p3U7pa3JTyLFOvicZ4fM14p8-J5zpyOdBWNw9Q@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-tls-dtls-connection-id@ietf.org" <draft-ietf-tls-dtls-connection-id@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>, Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="00000000000074d3a505c1830734"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KdO3y8eqBtyr0Xk0inbgfd4Jmps>
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: Tue, 04 May 2021 15:50:02 -0000

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