Re: [saag] can an on-path attacker drop traffic?

Eric Rescorla <ekr@rtfm.com> Sun, 04 October 2020 03:06 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB673A0AC8 for <saag@ietfa.amsl.com>; Sat, 3 Oct 2020 20:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 kOb3gH-DzPWl for <saag@ietfa.amsl.com>; Sat, 3 Oct 2020 20:06:35 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 781AC3A0AC6 for <saag@ietf.org>; Sat, 3 Oct 2020 20:06:35 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id p15so21417ljj.8 for <saag@ietf.org>; Sat, 03 Oct 2020 20:06:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tSM92HvucGX48dxhn5YItO1Qc7oPUb+0fbWBiYu1g6k=; b=LksAed+Vl0mn8SYnjm89NAbj9vsKVduLoxxFv+9ur/7ozFC0102iuNeor2ZFzhvPnv Biovp2o/RuQOeei5+5EHRJTJASgd2jJAjEkShOJAuwiPPigd3ElQ+BogyZ8+MpbhXMrc kwA4kYsSYFt4RqvOPeIe2lDNDjrOWeBg2gtLnANB1O+DSf31Xq76kNXPU16ArbVg+Sax 5A+K4XEMnPq/J1CboP+26XryKsZmrOz5u1umEPWiRwgWQhWlf3HCnAdoWIRvsfYzPla1 FXlEtHMSvfwdX4zM9TloZdADIh4BnTYGAm2tPGOsEZKVHiy4Ay7RR344TXNOzGHXOLFk 6vBw==
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=tSM92HvucGX48dxhn5YItO1Qc7oPUb+0fbWBiYu1g6k=; b=lfiEDEtr5n9yrI64kG2gcR8gZUNyFkPXGWJ/ngw7K4cRgejPJ8r78rXx/PrIjRTwe/ plWUbdXCmhu4S16ig6CirzAPQpkB/nwkwFjNHHdENJT2M+ne3xQSy64Y234sfgDaKA4C 5EzZ3zDaYQXtGi6A3Hk5G5si3l7fqQHYOMwmJDMoW2r0hcQW+NkkMFf7RZZpGF5bibuY 8LtbFfmBeszdgYvs/e/5n/Rd/Y1YxYTvk1Ibp2fEMQ7dzBC+rEmF8YPFRRTDSPb+7grq yBgRs9w4hJ7/ediQwLV+WlaIJC82N65wEW60UAlqLrwB2EpJrV7RtCBiL3RO/NP4OPrS 4kGg==
X-Gm-Message-State: AOAM533IWFlWk1kkg1/nPcdw3oVO8Gq1u1pqqjFuRVNMP2Gne2BhrFTe D4RJimXjzM5pS0qVNq+jKsocQgWaV8LXMqXPXbzFbA==
X-Google-Smtp-Source: ABdhPJz3nlp9O8XDxygfboyDt5b1QEqXO8+HHGH4oYXXMzxqzWtSthKfaw0vhWQHNeUVxxn/xaLSa7/Vi+9cxwdhWZU=
X-Received: by 2002:a2e:804f:: with SMTP id p15mr2543040ljg.199.1601780793567; Sat, 03 Oct 2020 20:06:33 -0700 (PDT)
MIME-Version: 1.0
References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <CABcZeBNuBhu8KUoZJsY3VR8LzDa78_n53rRZ-5nMrpCbqh_6KQ@mail.gmail.com> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> <CABcZeBO3sZTVL002FzHnpuqpAxe45_3JBZPRYRFScML8JCDUqg@mail.gmail.com>
In-Reply-To: <CABcZeBO3sZTVL002FzHnpuqpAxe45_3JBZPRYRFScML8JCDUqg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 3 Oct 2020 20:05:57 -0700
Message-ID: <CABcZeBMc4LAQzMFjrtCOwiDxRj1sa+F6vyjAQMaNLAOr09KUfQ@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: Fernando Gont <fernando@gont.com.ar>, Michael Richardson <mcr+ietf@sandelman.ca>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035831f05b0cfa7ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/nEpwmY1hAzYYkBQ0ldYQKKbPFvY>
Subject: Re: [saag] can an on-path attacker drop traffic?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2020 03:06:37 -0000

On Sat, Oct 3, 2020 at 7:58 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Sat, Oct 3, 2020 at 6:14 PM Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>> On 10/2/20 7:03 AM, Eric Rescorla wrote:
>> [snip]
>> >
>> > For capabilities, our basic assumption is what is often called a
>> > Dolev-Yao attacker, in which the attacker has complete control of the
>> > channel (this is what 3552 describes as the Internet Threat model
>> > [0]). However, it's also useful to try to consider more limited
>> > attackers such as those who can only read from the wire and those who
>> > cannot remove packets.
>>    Why? If we want to develop protocols that are secure in the presence of
>> a powerful attacker who has complete control of the medium what value
>> is there in considering a "more limited attacker"?
>>
>
>>    It sounds like you're making a distinction between a passive attacker
>> and an active attacker. Which is fine but what use do you see in a
>> protocol
>> that is secure against this "limited attacker" but not against the more
>> powerful attacker?
>>
>
> IMO the primary reason is that (!) there are some attacks which we do not
> presently know how to defend against in the case of a Dolev-Yao attacker,
> but which we can defend against a weaker attacker and (2) weaker attackers
> exist.
>
> As a concrete example, it is possible for such an attacker to terminate
> even connections which are cryptographically protected (e.g., QUIC) by
> simply refusing to carry any packet, so in this respect, QUIC and TCP are
> similar. However a weaker attacker (e.g., an off-path attacker) can
> terminate TCP connections by forging RSTs, which does not work against QUIC
> because the connection termination signals are cryptographically protected.
> I believe this is of some security value -- though perhaps you don't agree,
> but we can only properly analyze it by considering a range of attacker
> capabilities.
>

Following up to myself, an example of where the distinction between a
passive and active attacker is useful is browser fingerprinting. A browser
fingerprint which can be measured by the site without taking any explicit
action (e.g., User-Agent) is more concerning than one which requires the
site to take some browser-visible action. In the former case, we are not
able to know whether sites are using it for tracking and thus must assume
they are, but in the latter we can measure -- and potentially restrict --
the use of the parameter.

-Ekr


> -Ekr
>
>
>