From nobody Thu Oct 1 20:01:18 2020 Return-Path: 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 4D7BC3A0C32 for ; Thu, 1 Oct 2020 20:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JCkYL0Nmnsso for ; Thu, 1 Oct 2020 20:01:14 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731D93A0C11 for ; Thu, 1 Oct 2020 20:01:14 -0700 (PDT) Received: from [IPv6:2800:810:464:399:85a9:9e7:d7fe:7d2c] (unknown [IPv6:2800:810:464:399:85a9:9e7:d7fe:7d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 409B1283A5B; Fri, 2 Oct 2020 03:01:10 +0000 (UTC) To: Michael Richardson , saag@ietf.org References: <4645.1599064072@localhost> From: Fernando Gont Message-ID: <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> Date: Thu, 1 Oct 2020 23:54:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <4645.1599064072@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 03:01:17 -0000 On 2/9/20 13:27, Michael Richardson wrote: [...] > > A firewall or router is a potential on-path attacker, but it can also drop packets. > What do we call this? > This was historically called a MITM, and it implied all the attributes of > on-path. But it is unclear to me if MITM > on-path, or MITM == on-path. FWIW, I'd call this "man in the middle", and I'd say MITM > on-path. MITM implies the attacker receives the packets, and then it's up to the attacker to just inspect and pass on, or inspect & drop, or simply drop. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Oct 2 07:03:56 2020 Return-Path: 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 682453A1637 for ; Fri, 2 Oct 2020 07:03:55 -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 Iw70lLTVn9CM for ; Fri, 2 Oct 2020 07:03:53 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 E12353A163A for ; Fri, 2 Oct 2020 07:03:52 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id z19so2009284lfr.4 for ; Fri, 02 Oct 2020 07:03:52 -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=9/5/jsJKD0Xz0XVfDUWlXSJX60PhRSXSkFvj1q+4c84=; b=csuMcqXuNdz5rFkn6ASkRzN+nAzMHWZV2qSblfNtvgk7mu4vxVS2rI8cEsYw+crjZF 2wvpNKQ1x94WrcD4jyDVmM8Ysx3/DdJV92YjvqNc0RoqEnHWR2uz0bxRUVUqQjmNgDY6 amkvSNBofqcCasqSG+hGWZwqsJJLPg/V+3ycUO/2iBHZ7zvfDN3PCmLkKytKVRCsS3A+ Fsf59VVYfqUri7ImkUcOvUB1Epkzy8+4bEa+E2lIRHuRpWNhwOgBeaHkDZJhCq0LRQz5 jfZV/GWcWRcILEfm4x/S8n0PXKbyNDvcn3GUiIm74VHl9iImPHAoEtov6EVzplQnV6i6 6F8A== 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=9/5/jsJKD0Xz0XVfDUWlXSJX60PhRSXSkFvj1q+4c84=; b=DxK6nStE8hE+WKFLbdgnheqrQx2aVVkdHTMAhAp6q2WJsSqcvVPmIzkYBk41aoUvx1 XUwVKhQDDp2ek5A3NkCGk6oNMokeYsZ2GgHposnmku+X/cS6798jPZ/I7caPox7F80D4 PTq4oQLBtLkbqlFPC5X3RCnsL6UMxd6ZejTeTkegiE0yd52j0mGyDJ0h/baGl8yUmeeK LBb+p3nPqyZpAn6D05lb4QIXwVeWbH68h31jWXmGFpuCdgNLg2M3hbdBz4k4DqeguZ3M zvSjbCivMeIngi0uu6DnyiYz2PLhPoIy8W6oUPo294+sS8th1YnbX6bO6mkqXv1LluZR 6q6Q== X-Gm-Message-State: AOAM530bx0Rr5oi/5pLsEFHOz9kf78qPm6fdPu3tKY3aRxmjP78KaY6n Pak1YRy/N00vfNhYzClrpqjgQyn80aYJwdpSMXFHJg== X-Google-Smtp-Source: ABdhPJzg5hHzSyxEtOTNEvYOQSbe+plpi+TLuWFGMAGyEUmSLYyFAoIHR1mxX3zCJFGXstar7LLjD1yhIh/NdhH1Df8= X-Received: by 2002:ac2:4e92:: with SMTP id o18mr925509lfr.543.1601647431036; Fri, 02 Oct 2020 07:03:51 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> In-Reply-To: <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> From: Eric Rescorla Date: Fri, 2 Oct 2020 07:03:14 -0700 Message-ID: To: Fernando Gont Cc: Michael Richardson , IETF SAAG Content-Type: multipart/alternative; boundary="0000000000002ec57805b0b09ab3" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 14:03:55 -0000 --0000000000002ec57805b0b09ab3 Content-Type: text/plain; charset="UTF-8" As I think this discussion reveals, we don't have a really precise description of MITM, in part because it's quite an old term from an era where we had much less ability to analyze security protocols than we do today. One result of improvements in analysis is the need for precise definitions so that we can formalize the guarantees of systems against those definitions. This process is rather further along in in cryptography where there are very precise definitions for both the assumptions that our primitives depend on (RO, CDH, etc.) and the security guarantees they provide (IND-CCA2, etc.), but it is happening in communications security as well. In general, we need terms for both attacker capabilities and attacks. 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. To my knowledge, we don't have a consensus set of precise definitions for these yet, though both 3552 and QUIC [1] make a stab at this). Similarly, some attacks are well-defined (reflection, identity misbinding, KCI, impersonation etc.) and some are not. This brings us to MITM which is often used both for a set of capabilities (usually roughly a Dolev-Yao attacker) and for a class of active attacks including straight up impersonation to various kinds of relay attacks). This broad a scope of usage isn't that useful and rather than trying to give it a precise definition, it's probably time to retire the term and replace it with a set of terms (perhaps including some new terms) that do have precise definitions. -Ekr [0] https://tools.ietf.org/html/rfc3552#section-3 [1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-31#section-21.13.3 On Thu, Oct 1, 2020 at 8:01 PM Fernando Gont wrote: > On 2/9/20 13:27, Michael Richardson wrote: > [...] > > > > A firewall or router is a potential on-path attacker, but it can also > drop packets. > > What do we call this? > > This was historically called a MITM, and it implied all the attributes of > > on-path. But it is unclear to me if MITM > on-path, or MITM == on-path. > > FWIW, I'd call this "man in the middle", and I'd say MITM > on-path. > > MITM implies the attacker receives the packets, and then it's up to the > attacker to just inspect and pass on, or inspect & drop, or simply drop. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --0000000000002ec57805b0b09ab3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I think this discussion reveals, we don't have a re= ally precise
description of MITM, in part because it's quite an old = term from an
era where we had much less ability to analyze security prot= ocols than
we do today. One result of improvements in analysis is the ne= ed for
precise definitions so that we can formalize the guarantees of sy= stems
against those definitions. This process is rather further along in= in
cryptography where there are very precise definitions for both theassumptions that our primitives depend on (RO, CDH, etc.) and the
secu= rity guarantees they provide (IND-CCA2, etc.), but it is happening
in co= mmunications security as well.

In general, we need terms for both at= tacker capabilities and attacks.

For capabilities, our basic assumpt= ion 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 cons= ider more limited
attackers such as those who can only read from the wir= e and those who
cannot remove packets. To my knowledge, we don't hav= e a consensus set
of precise definitions for these yet, though both 3552= and QUIC [1]
make a stab at this). Similarly, some attacks are well-def= ined
(reflection, identity misbinding, KCI, impersonation etc.) and some= are
not.

This brings us to MITM which is often used both for a s= et of
capabilities (usually roughly a Dolev-Yao attacker) and for a clas= s of
active attacks including straight up impersonation to various kinds= of
relay attacks). This broad a scope of usage isn't that useful an= d
rather than trying to give it a precise definition, it's probably = time
to retire the term and replace it with a set of terms (perhaps
i= ncluding some new terms) that do have precise definitions.

-Ekr
<= br>
[0] https:= //tools.ietf.org/html/rfc3552#section-3
[1] http= s://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-31#section-21.1= 3.3



On Thu, Oct 1, 2020 at 8:01 PM Fernando Gont <fernando@gont.com.ar> wrote:
On 2/9/20 13:27, Micha= el Richardson wrote:
[...]
>
> A firewall or router is a potential on-path attacker, but it can also = drop packets.
> What do we call this?
> This was historically called a MITM, and it implied all the attributes= of
> on-path.=C2=A0 But it is unclear to me if MITM > on-path, or MITM = =3D=3D on-path.

FWIW, I'd call this "man in the middle", and I'd say MITM= > on-path.

MITM implies the attacker receives the packets, and then it's up to the=
attacker to just inspect and pass on, or inspect & drop, or simply drop= .

Thanks,
--
Fernando Gont
e-mail: fernando@= gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--0000000000002ec57805b0b09ab3-- From nobody Sat Oct 3 18:14:28 2020 Return-Path: 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 1BA913A0A70 for ; Sat, 3 Oct 2020 18:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0R2doTMQXUas for ; Sat, 3 Oct 2020 18:14:24 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 CFBB83A098D for ; Sat, 3 Oct 2020 18:14:24 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QHN0XXKNKS0U3@wwwlocal.goatley.com> for saag@ietf.org; Sat, 03 Oct 2020 20:14:24 -0500 (CDT) Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QHN0065KKNWV2@trixy.bergandi.net> for saag@ietf.org; Sat, 03 Oct 2020 18:11:57 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sat, 03 Oct 2020 18:11:57 -0700 Date: Sat, 03 Oct 2020 18:14:22 -0700 From: Dan Harkins In-reply-to: To: Eric Rescorla , Fernando Gont Cc: Michael Richardson , IETF SAAG Message-id: <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local) References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> X-PMAS-Software: PreciseMail V3.3 [201003] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 01:14:26 -0000 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?   Dan. From nobody Sat Oct 3 19:25:32 2020 Return-Path: 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 A416D3A0AA7 for ; Sat, 3 Oct 2020 19:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 f-56bpU3pjsV for ; Sat, 3 Oct 2020 19:25:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C81B3A0AA6 for ; Sat, 3 Oct 2020 19:25:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1E16F389D2; Sat, 3 Oct 2020 22:30:37 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ofYbkGs6ZI-l; Sat, 3 Oct 2020 22:30:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 836EC389CF; Sat, 3 Oct 2020 22:30:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8BB79A14; Sat, 3 Oct 2020 22:25:26 -0400 (EDT) From: Michael Richardson To: Eric Rescorla , Fernando Gont , IETF SAAG In-Reply-To: References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 02:25:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > As I think this discussion reveals, we don't have a really precise > description of MITM, in part because it's quite an old term from an e= ra > where we had much less ability to analyze security protocols than we = do > today. One result of improvements in analysis is the need for precise > definitions so that we can formalize the guarantees of systems against > those definitions. I'm very much in agreement. > 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]). "Dolev-Yao" is a bit of a mouthful, but maybe if I say it really fast as if it's the name of a Kata it will work for me :-) > 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. To my knowledge, we don't have a consensus set > of precise definitions for these yet, though both 3552 and QUIC [1] > make a stab at this). Similarly, some attacks are well-defined > (reflection, identity misbinding, KCI, impersonation etc.) and some a= re > not. The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao attacker. The 21.13.3.2 "off-path" attacker seems to have the ability to observe packets, which I normally would not think an off-path attacker would have. So this definition is very surprising to me. RFC7416 has some terms (sinkhole, wormhole) that might be useful. I notice that sections 21.13.3.4 about how an off-path could become on-path by offering "better" routing. Perhaps this is worth an hour of IETF109 SAAG time. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl95MpYACgkQgItw+93Q 3WU5DAf9HdQucacYfqpg772yQWc0IqHAQjk4nT439E4Eyc/aCD7s6oRQ38A+Rww5 Geuqr5C7Dn3lr8eT1V7eCuOyk4OsJbIkBjhPDcdoltdMxwNceCpXiot8aWv+7Snj JynPc78AH/btFELSvl1hj/BVfW+WROFTLl5JM5qtPXYac3sd9GPZp4blMvgbMto9 DWbSggqm9ro1ECprT6wdfPrdR0GPvlFKRNt/epP3oIWy4IlieHcLzEjUkOWIGqLp i82b2qGfUOP2WhFfeatIT/hnnZ+RY24ub4fs2PVXWcyCL0MQp99bzw2ljJLHXA9B Ld2oEso/Iqwg7mymTJGx0NykWEjU8A== =sh4q -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 3 19:58:57 2020 Return-Path: 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 D469C3A0AC5 for ; Sat, 3 Oct 2020 19:58:54 -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 XQkQotkICCAA for ; Sat, 3 Oct 2020 19:58:53 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 029DC3A08CA for ; Sat, 3 Oct 2020 19:58:53 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id h6so54954lfj.3 for ; Sat, 03 Oct 2020 19:58:52 -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=UCJdATqffL8JrMPvCdPIm8JY8At2rd238OvMNniPlWQ=; b=niGZiDn1zHsYuxAkCHrIURJswDqtsejogl9kD8TG+ijcB0wDVKHXgCMs/QrrfVvs/n bolhfMTPFc7PbV4WdlwZaRRVt+hOPi1Rc/tV0rJkazPkGOKTtiIaHJf7NhSDrOoXJS1L dtuN6KF9lY5csNo13+IqasRAb4L1346vt7VKuwQ5RmckptnbRcFA+YfcITIPS8JC88tc IYa7/tN4oF5ErXisB35IRYlBjdz1Nu8hesuazks4quKj91VBtpmvLNMLBtovh1HFcoLB YSqc6mAGZ73FOxeIIG8JsK0CxHSHyc4nmyYSh9LIU4rv4fTCwICEkAgk8EicgFezEw9a b+1Q== 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=UCJdATqffL8JrMPvCdPIm8JY8At2rd238OvMNniPlWQ=; b=K/8AIMvXWo9YEQqoXyApyBo2bk2TCN+umrBb48ZWfdzec8RcOELe1ZoUvRr9dt+D5r qI1J9uxEdcNT0380/7Jsyl0vWMMnq8OxNOQegCM8oe2Vr3OOZXZu9ff3zkM8wmTa99ls ci72ZVmgxXgmLsudFykkYDsdOF7W7yXL777ZwgNY2QyOUKSIOtajQ90iL6rVTwsagN3x gBrkeqRceZe2gqAQYsTi7PtD0VhR9y7omDvBj8f6oio1nJHPz6ORx3O+s07utJulrJ3C rgjUItuR+BKETUZSxIqJQ0oOQbtSqO3g7o0yREotD7uZb0BC9fj/DtxPDkhIADHzWNcR 8ing== X-Gm-Message-State: AOAM533A8Mke3mz7y0rRVD9KnvJ1k9rGFkVefTAH/N3ax1Ap4v7w708E pzsjWk+sbylqdEcBYFMRAgHoaL+0nREIQz37WyiClVb4fMxL7g== X-Google-Smtp-Source: ABdhPJw0vfJrRck6bTEcLyZnoT5J0gIkBvo+kV10y0jDvskWVrUFcQKFEJAhA443fzPWF0sFlTDegbRTDYzZcrUA6c4= X-Received: by 2002:a19:dd5:: with SMTP id 204mr3134306lfn.579.1601780331126; Sat, 03 Oct 2020 19:58:51 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> In-Reply-To: <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> From: Eric Rescorla Date: Sat, 3 Oct 2020 19:58:15 -0700 Message-ID: To: Dan Harkins Cc: Fernando Gont , Michael Richardson , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000a5338b05b0cf8ba9" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 02:58:55 -0000 --000000000000a5338b05b0cf8ba9 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 3, 2020 at 6:14 PM Dan Harkins 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. -Ekr --000000000000a5338b05b0cf8ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Oct 3, 2020 at 6:14 PM Dan Ha= rkins <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<= br> > 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<= br> > cannot remove packets.
=C2=A0=C2=A0 Why? If we want to develop protocols that are secure in the pr= esence of
a powerful attacker who has complete control of the medium what value
is there in considering a "more limited attacker"?

=C2=A0=C2=A0 It sounds like you're making a distinction between a passi= ve 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 th= e more
powerful attacker?

IMO the primary reas= on 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 defen= d against a weaker attacker and (2) weaker attackers exist.
<= br>
As a concrete example, it is possible for such an attacker to= terminate even connections which are cryptographically protected (e.g., QU= IC) by simply refusing to carry any packet, so in this respect, QUIC and TC= P are similar. However a weaker attacker (e.g., an off-path attacker) can t= erminate 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 a= gree, but we can only properly analyze it by considering a range of attacke= r capabilities.

-Ekr

=
--000000000000a5338b05b0cf8ba9-- From nobody Sat Oct 3 20:00:29 2020 Return-Path: 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 427953A0AC5 for ; Sat, 3 Oct 2020 20:00:27 -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 w4FHepGOgyWv for ; Sat, 3 Oct 2020 20:00:25 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 82D0B3A08CA for ; Sat, 3 Oct 2020 20:00:25 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id h6so57141lfj.3 for ; Sat, 03 Oct 2020 20:00:25 -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=LIGFOosY43a83Kt7znLFRs9uue3zuJ498DogtgNE6Rc=; b=oLKp20HJzQAynMH1c+cGUmtngGEkw+Bmj5BdOXqsdsAPy70/9JUeHCGxFQlBrmjSP5 Lnw4gGOOY4cXD/4JEz7odNbOkpLRaSvqmtP9cZc7OsHYx3J/lJSrZ4bBjqP/ku3RcNJH TdhW8rAeO1l6/D+aG5+eBjHInnXhMPiWROn9vdYHMalvWD78roAjIMtc+lWgrFSXhn7O LDwd7xCb/PNmgVCQ9FBM0FgRSS0lmw+NDBToexMCOwRZQPvPXptc1lgngnE6zGTrgLre eFcEw5ZBhGbIkb7lfyzxciHJ1kh4QL4mubqrEteJOA2tmgcds/WP4lHiqTzRIP5EK9I2 pBgw== 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=LIGFOosY43a83Kt7znLFRs9uue3zuJ498DogtgNE6Rc=; b=AQzYRWbZw2B0SVRe8NinKLyoJZs8u4ycCoyo98zjTpPrK+kTZgL1cmuLTIM+D5rNTn vTTwpXgKv4dvHfjdGZsrMfbLR/UxrziKD1UoCMcKHAXYnVyAQhtzhPOEaCf06UEf7f3M ewNyzJTTzSQXLZctDaKhHI3YlYKc5/ysxJiIQDHStVSgc3JJF6ioqCyjJ4lW07NnX35r GRSfOPySEKdVdWtSl+gc+CLCghoLw1nnGsaG18wqkGhDhiR1PVh1dEXdcjEK/0qmI6ZU mG1ZGTsXlW5gM8RA8LCz1wJUcyu5jH9ZxQw+oNcNG6i36onYmcm+yoFzton4LaeB7lD8 EHPQ== X-Gm-Message-State: AOAM532MFRinWgKfstgstxgBUgGh8Sah2kJN/hbhyYklVU/Xy4BVjlN6 rkGtn4mBhPoFb5UzY1zpJzo+hgLmSD4BRsa+BRkamA== X-Google-Smtp-Source: ABdhPJwILQn2JnB8oWaFKOUTlMYDx28GE6VH8apgpc1EMv/g7Lef+c8GFml21ZLsx7s8qt5ZQUEHnMvQr9uMVrRyq14= X-Received: by 2002:ac2:4e92:: with SMTP id o18mr3321750lfr.543.1601780423701; Sat, 03 Oct 2020 20:00:23 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <14793.1601778326@localhost> In-Reply-To: <14793.1601778326@localhost> From: Eric Rescorla Date: Sat, 3 Oct 2020 19:59:47 -0700 Message-ID: To: Michael Richardson Cc: Fernando Gont , IETF SAAG Content-Type: multipart/alternative; boundary="00000000000029cc7f05b0cf91d2" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 03:00:27 -0000 --00000000000029cc7f05b0cf91d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 3, 2020 at 7:25 PM Michael Richardson wrote: > > Eric Rescorla wrote: > > As I think this discussion reveals, we don't have a really precise > > description of MITM, in part because it's quite an old term from an > era > > where we had much less ability to analyze security protocols than w= e > do > > today. One result of improvements in analysis is the need for preci= se > > definitions so that we can formalize the guarantees of systems > against > > those definitions. > > I'm very much in agreement. > > > For capabilities, our basic assumption is what is often called a > > Dolev-Yao attacker, in which the attacker has complete control of t= he > > channel (this is what 3552 describes as the Internet Threat model > > [0]). > > "Dolev-Yao" is a bit of a mouthful, but maybe if I say it really fast as = if > it's the name of a Kata it will work for me :-) > I agree. It might be useful to create a new name, as long as we are careful to have a precise definition. > > However, it's also useful to try to consider more limited > > attackers such as those who can only read from the wire and those w= ho > > cannot remove packets. To my knowledge, we don't have a consensus s= et > > of precise definitions for these yet, though both 3552 and QUIC [1] > > make a stab at this). Similarly, some attacks are well-defined > > (reflection, identity misbinding, KCI, impersonation etc.) and some > are > > not. > > The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao attacker. > > The 21.13.3.2 "off-path" attacker seems to have the ability to observe > packets, which I normally would not think an off-path attacker would have= . > So this definition is very surprising to me. > I agree it's not ideal. QUIC has been pubreq-ed, so you could raise it in IETF-LC. -Ekr RFC7416 has some terms (sinkhole, wormhole) that might be useful. > I notice that sections 21.13.3.4 about how an off-path could become on-pa= th > by offering "better" routing. > > Perhaps this is worth an hour of IETF109 SAAG time. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > --00000000000029cc7f05b0cf91d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Oct 3, 2020 at 7:25 PM Michae= l Richardson <mcr+ietf@sandel= man.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 > As I think this discussion reveals, we don't have a = really precise
=C2=A0 =C2=A0 > description of MITM, in part because it's quite an o= ld term from an era
=C2=A0 =C2=A0 > where we had much less ability to analyze security proto= cols than we do
=C2=A0 =C2=A0 > today. One result of improvements in analysis is the nee= d for precise
=C2=A0 =C2=A0 > definitions so that we can formalize the guarantees of s= ystems against
=C2=A0 =C2=A0 > those definitions.

I'm very much in agreement.

=C2=A0 =C2=A0 > For capabilities, our basic assumption is what is often = called a
=C2=A0 =C2=A0 > Dolev-Yao attacker, in which the attacker has complete c= ontrol of the
=C2=A0 =C2=A0 > channel (this is what 3552 describes as the Internet Thr= eat model
=C2=A0 =C2=A0 > [0]).

"Dolev-Yao" is a bit of a mouthful, but maybe if I say it really = fast as if
it's the name of a Kata it will work for me :-)
I agree. It might be useful to create a new name, as long as w= e are careful to have
a precise definition.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 =C2=A0 > However, it's also useful to try to consider more li= mited
=C2=A0 =C2=A0 > attackers such as those who can only read from the wire = and those who
=C2=A0 =C2=A0 > cannot remove packets. To my knowledge, we don't hav= e a consensus set
=C2=A0 =C2=A0 > of precise definitions for these yet, though both 3552 a= nd QUIC [1]
=C2=A0 =C2=A0 > make a stab at this). Similarly, some attacks are well-d= efined
=C2=A0 =C2=A0 > (reflection, identity misbinding, KCI, impersonation etc= .) and some are
=C2=A0 =C2=A0 > not.

The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao att= acker.

The 21.13.3.2 "off-path" attacker seems to have the ability to ob= serve
packets, which I normally would not think an off-path attacker would have.<= br> So this definition is very surprising to me.

I agree it's not ideal. QUIC has been pubreq-ed, so you could rai= se it in IETF-LC.

-Ekr

RFC7416 has some terms (sinkhole, wormhole) that might be useful.
I notice that sections 21.13.3.4 about how an off-path could become on-path=
by offering "better" routing.

Perhaps this is worth an hour of IETF109 SAAG time.


--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide

--00000000000029cc7f05b0cf91d2-- From nobody Sat Oct 3 20:06:39 2020 Return-Path: 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 ; 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 ; 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 ; Sat, 3 Oct 2020 20:06:35 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p15so21417ljj.8 for ; 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> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> In-Reply-To: From: Eric Rescorla Date: Sat, 3 Oct 2020 20:05:57 -0700 Message-ID: To: Dan Harkins Cc: Fernando Gont , Michael Richardson , IETF SAAG Content-Type: multipart/alternative; boundary="00000000000035831f05b0cfa7ca" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 03:06:37 -0000 --00000000000035831f05b0cfa7ca Content-Type: text/plain; charset="UTF-8" On Sat, Oct 3, 2020 at 7:58 PM Eric Rescorla wrote: > > > On Sat, Oct 3, 2020 at 6:14 PM Dan Harkins 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 > > > --00000000000035831f05b0cfa7ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


On Sat, Oct 3, 2020 at 6:14 PM Dan Harkins <dharkins@lounge.org&g= t; 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<= br> > 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<= br> > cannot remove packets.
=C2=A0=C2=A0 Why? If we want to develop protocols that are secure in the pr= esence of
a powerful attacker who has complete control of the medium what value
is there in considering a "more limited attacker"?

=C2=A0=C2=A0 It sounds like you're making a distinction between a passi= ve 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 th= e more
powerful attacker?

IMO the primary reas= on 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 defen= d against a weaker attacker and (2) weaker attackers exist.
<= br>
As a concrete example, it is possible for such an attacker to= terminate even connections which are cryptographically protected (e.g., QU= IC) by simply refusing to carry any packet, so in this respect, QUIC and TC= P are similar. However a weaker attacker (e.g., an off-path attacker) can t= erminate 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 a= gree, but we can only properly analyze it by considering a range of attacke= r capabilities.

Follo= wing up to myself, an example of where the distinction between a passive an= d active attacker is useful is browser fingerprinting. A browser fingerprin= t 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 wh= ether 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 pa= rameter.

-Ekr


-Ekr


--00000000000035831f05b0cfa7ca-- From nobody Sat Oct 3 21:43:06 2020 Return-Path: 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 103583A0DD9 for ; Sat, 3 Oct 2020 21:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9cAJp080REpy for ; Sat, 3 Oct 2020 21:43:03 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F266F3A0DD6 for ; Sat, 3 Oct 2020 21:43:02 -0700 (PDT) Received: from AUS01-SY3-obe.outbound.protection.outlook.com (mail-sy3aus01lp2057.outbound.protection.outlook.com [104.47.117.57]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-49-ZnqwzzHNN0m9WpkNApmtHw-1; Sun, 04 Oct 2020 15:42:57 +1100 X-MC-Unique: ZnqwzzHNN0m9WpkNApmtHw-1 Received: from HK2PR04CA0077.apcprd04.prod.outlook.com (2603:1096:202:15::21) by MEAPR01MB5077.ausprd01.prod.outlook.com (2603:10c6:220:37::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Sun, 4 Oct 2020 04:42:52 +0000 Received: from HK2APC01FT046.eop-APC01.prod.protection.outlook.com (2603:1096:202:15:cafe::73) by HK2PR04CA0077.outlook.office365.com (2603:1096:202:15::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34 via Frontend Transport; Sun, 4 Oct 2020 04:42:51 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.208) smtp.mailfrom=cs.auckland.ac.nz; sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cs.auckland.ac.nz Received: from uxcn13-tdc-a.UoA.auckland.ac.nz (130.216.95.208) by HK2APC01FT046.mail.protection.outlook.com (10.152.249.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3433.34 via Frontend Transport; Sun, 4 Oct 2020 04:42:49 +0000 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 4 Oct 2020 17:42:47 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1497.006; Sun, 4 Oct 2020 17:42:47 +1300 From: Peter Gutmann To: Dan Harkins , Eric Rescorla , "Fernando Gont" CC: Michael Richardson , IETF SAAG Thread-Topic: [saag] can an on-path attacker drop traffic? Thread-Index: AQHWgUYXwImtjh9v5US2r7Xor+/lhKmC8hsAgAC69ACAAk3YAIABFA5R Date: Sun, 4 Oct 2020 04:42:46 +0000 Message-ID: <1601786570544.65950@cs.auckland.ac.nz> References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> , <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> In-Reply-To: <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> Accept-Language: en-NZ, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ee6c1ee8-373d-4c1a-30f1-08d8681ff270 X-MS-TrafficTypeDiagnostic: MEAPR01MB5077: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5236 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: TUZd3xHFFUMfpDjqP3+YDkTtjKDOUW3hGoHeBpOFWhJOhkX7HGEiCxKT6/CJ3Xeiy03U8UvT/dXgOnFHUhG2iSHz7sbtQjLujxH2XbEoVthc78Qo1sn5g0gaO71chUzr7AGuO27gDbiSpGfHnNyu1+ASWN3TimBSvbmlIzK/zXJVmMy42u5ITAOZRwjLJdwfydaPDIyqKOZjU20sGAKV7hBaO4rmz0TEpZardlUG53oLW687Y72PNYOd0Dl2236jztim1ZsoWr9SB1YW9pyvQw/ac+ZNpjBunJ4GpLeajjEDbyDVxHJ5+BdgdUFnFhFv8E2BlNXZQKYN8c2Qpemk5E/f8XvRpFG2AxpWqQEPBNYoQxoy9B37OH/1sXgRMUJ4rpAPQA0z3In2AVgfznGt4Q== X-Forefront-Antispam-Report: CIP:130.216.95.208; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-tdc-a.UoA.auckland.ac.nz; PTR:natgate1-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(136003)(396003)(46966005)(86362001)(336012)(5660300002)(316002)(786003)(356005)(54906003)(8936002)(83380400001)(110136005)(36906005)(7636003)(2906002)(82310400003)(8676002)(4326008)(47076004)(82740400003)(26005)(478600001)(186003)(2616005)(70206006)(70586007); DIR:OUT; SFP:1101 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2020 04:42:49.0170 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ee6c1ee8-373d-4c1a-30f1-08d8681ff270 X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.208]; Helo=[uxcn13-tdc-a.UoA.auckland.ac.nz] X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT046.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB5077 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 04:43:05 -0000 Dan Harkins writes:=0A=0A>Which is fine but what use = do you see in a protocol that is secure against=0A>this "limited attacker" = but not against the more powerful attacker?=0A=0ABecause it's far easier to= deploy a relatively straightforward, realistic=0Aprotocol secure against a= general attack than it is to deply an awkward,=0Acomplex, impractical prot= ocol that's theoretically (but often not practically)=0Asecure against a mo= re unlimited attacker. To quote the end of John Gordon's=0Ajoke:=0A=0A No= w most people in Alice's position would give up. Not Alice. She has=0A cou= rage which can only be described as awesome. Against all odds, over a=0A n= oisy telephone line, tapped by the tax authorities and the secret police,= =0A Alice will happily attempt, with someone she doesn't trust, whom she c= annot=0A hear clearly, and who is probably someone else, to fiddle her tax= returns=0A and to organize a coup d'etat, while at the same time minimizi= ng the cost of=0A the phone call.=0A=0A A coding theorist is someone who = doesn't think Alice is crazy.=0A=0AI don't need a theoretically perfect pro= tocol that's practically un-=0Adeployable, I just need something that's pra= ctical and good enough for the=0Ajob.=0A=0APeter.=0A From nobody Sat Oct 3 22:23:37 2020 Return-Path: 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 C55033A105E for ; Sat, 3 Oct 2020 22:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yW9rqiNDN3_P for ; Sat, 3 Oct 2020 22:23:34 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2234D3A105C for ; Sat, 3 Oct 2020 22:23:33 -0700 (PDT) Received: from xse363.mail2web.com ([66.113.197.109] helo=xse.mail2web.com) by mx17.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kOwUZ-0007pF-W8 for saag@ietf.org; Sun, 04 Oct 2020 07:23:31 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4C3sZf4FT7ztB3 for ; Sat, 3 Oct 2020 22:23:22 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kOwUU-0003Jh-Fh for saag@ietf.org; Sat, 03 Oct 2020 22:23:22 -0700 Received: (qmail 15683 invoked from network); 4 Oct 2020 05:23:21 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.46.239]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Oct 2020 05:23:21 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-AF012C8D-8EDC-4CFB-BC9D-F396C3A61113 Content-Transfer-Encoding: 7bit From: Christian Huitema Mime-Version: 1.0 (1.0) Date: Sat, 3 Oct 2020 22:23:20 -0700 Message-Id: References: Cc: Michael Richardson , Fernando Gont , IETF SAAG In-Reply-To: To: Eric Rescorla X-Mailer: iPhone Mail (17H35) X-Originating-IP: 66.113.197.109 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.71) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVMpUGqoktPdof do6VQqSoRETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59ftsra6SECpO06iBsnkTuhZiU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5hmwN8D4LrepG7AX8WNwY8Mm/JD3cPBOX47Hg3FEpDo46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAmxx/Wk8McinP JEkgAVrOMpZe3hRpsu7wNFYkklzOSk+gn8xjOPPpotNGdiYmcA8z3gPBb9iGpTEjWGgNXUgraFIv UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azSDOyu53XgzieW2z5dggn85xMPnetLBJMh51NiRRoHIBmdjuhXtou9fyHZ5xUc1l1miK7 x42VjdzChZMe6O/Did+/hGXTmfhE+Dx2/NyzMXogeTaqPadUMySWqNjMcOK/vOnCUbNPgcPcQwzM gKHyQxUo+ql2ySTkvEFH/23XMww2BnTTFGX5/yI4Ky+1ZJcbGqc5H4PEZHeoI/d6LWFf332z7LMw LGdoi9FMQ5j9dQUvMi1YKAun15JQSJLyCT5k+MTObVKxHy/dols381l9r9ft9daDonlwd6LnuX+J u10= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 05:23:36 -0000 --Apple-Mail-AF012C8D-8EDC-4CFB-BC9D-F396C3A61113 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Oct 3, 2020, at 8:00 PM, Eric Rescorla wrote: >=20 >> The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao attacker. >>=20 >> The 21.13.3.2 "off-path" attacker seems to have the ability to observe >> packets, which I normally would not think an off-path attacker would have= . >> So this definition is very surprising to me. >=20 > I agree it's not ideal. QUIC has been pubreq-ed, so you could raise it in I= ETF-LC. I think of it as man-in-the-middle, man-on-the-side and man-in-the-rough. Fo= r me, the man in the middle is what EKR refers to as the Dolev-Yao attacker;= best hope there is to detect the attack and reduce it to a denial of servic= e. The man on the side is capable of reading the traffic and injecting messages= ; it cannot easily delete messages, but it can win races and get his own fa= kery delivered before the genuine packets -- TCP RST is an example of such a= ttacks. Various national organizations have that capability. It is much easi= er for them to implement than a full MITM. I think that with effort we can d= efeat this class of attackers. The man in the rough does not see the traffic but can make guesses. DDOS att= acks, port scanning, observing or gaming DNS caches fall in that category. B= otnets sometimes resort to these attacks. And yes, in 2020 we probably need names that don't carry "man-in-foo" imager= y. But English is not my mother tongue... -- Christian Huitema=20 --Apple-Mail-AF012C8D-8EDC-4CFB-BC9D-F396C3A61113 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Oct 3, 2020, at 8:00 PM, Eric Rescorla <ekr@rtfm.com> wrote:=

The QUIC 21.13.3.1 "on-path" atta= cker seems to be a Dolev-Yao attacker.

The 21.13.3.2 "off-path" attacker seems to have the ability to observe
packets, which I normally would not think an off-path attacker would have. So this definition is very surprising to me.

=
I agree it's not ideal. QUIC has been pubreq-ed, so you could raise it i= n IETF-LC.

I think of it as man-in-the-midd= le, man-on-the-side and man-in-the-rough. For me, the man in the middle is w= hat EKR refers to as the Dolev-Yao attacker; best hope there is to detect th= e attack and reduce it to a denial of service.

The m= an on the side is capable of reading the traffic and injecting messages; it c= annot easily delete messages,  but it can win races and get his own fak= ery delivered before the genuine packets -- TCP RST is an example of such at= tacks. Various national organizations have that capability. It is much easie= r for them to implement than a full MITM. I think that with effort we can de= feat this class of attackers.

The man in the rough d= oes not see the traffic but can make guesses. DDOS attacks, port scanning, o= bserving or gaming DNS caches fall in that category. Botnets sometimes resor= t to these attacks.

And yes, in 2020 we probably ne= ed names that don't carry "man-in-foo" imagery. But English is not my mother= tongue...

-- Christian Huitema 

= --Apple-Mail-AF012C8D-8EDC-4CFB-BC9D-F396C3A61113-- From nobody Sun Oct 4 08:17:18 2020 Return-Path: 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 34DC63A083F for ; Sun, 4 Oct 2020 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, MAY_BE_FORGED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 eJ-g08u4NZku for ; Sun, 4 Oct 2020 08:17:15 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 7146E3A0658 for ; Sun, 4 Oct 2020 08:17:15 -0700 (PDT) Received: from [10.32.60.37] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 094FF9qh051524 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 4 Oct 2020 08:15:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged) claimed to be [10.32.60.37] From: "Paul Hoffman" To: "IETF SAAG" Date: Sun, 04 Oct 2020 08:17:13 -0700 X-Mailer: MailMate Trial (1.13.2r5673) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 15:17:17 -0000 I like Christian's triage (minus the "men"). The "where are they relative to the path" differentiation is likely to be more understandable to people who are not security geeks than "what they can do with creative use of packets". Using a road analogy: a person running a tollbooth, a person who can watch the cars go by and tell his colleagues when to enter the stream in order to do damage, a person who cannot see the traffic or send in cars but can cause lightning storms and send fake news to the cars on the road. --Paul Hoffman On 3 Oct 2020, at 22:23, Christian Huitema wrote: >> On Oct 3, 2020, at 8:00 PM, Eric Rescorla wrote: >> >>> The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao >>> attacker. >>> >>> The 21.13.3.2 "off-path" attacker seems to have the ability to >>> observe >>> packets, which I normally would not think an off-path attacker would >>> have. >>> So this definition is very surprising to me. >> >> I agree it's not ideal. QUIC has been pubreq-ed, so you could raise >> it in IETF-LC. > > I think of it as man-in-the-middle, man-on-the-side and > man-in-the-rough. For me, the man in the middle is what EKR refers to > as the Dolev-Yao attacker; best hope there is to detect the attack and > reduce it to a denial of service. > > The man on the side is capable of reading the traffic and injecting > messages; it cannot easily delete messages, but it can win races and > get his own fakery delivered before the genuine packets -- TCP RST is > an example of such attacks. Various national organizations have that > capability. It is much easier for them to implement than a full MITM. > I think that with effort we can defeat this class of attackers. > > The man in the rough does not see the traffic but can make guesses. > DDOS attacks, port scanning, observing or gaming DNS caches fall in > that category. Botnets sometimes resort to these attacks. > > And yes, in 2020 we probably need names that don't carry "man-in-foo" > imagery. But English is not my mother tongue... > > -- Christian Huitema From nobody Sun Oct 4 08:41:50 2020 Return-Path: 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 96FFF3A02BB for ; Sun, 4 Oct 2020 08:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LU7wG9jvmWNb for ; Sun, 4 Oct 2020 08:41:47 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E713A017E for ; Sun, 4 Oct 2020 08:41:46 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4C47J84BVszybs; Sun, 4 Oct 2020 17:41:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Sun, 4 Oct 2020 17:41:44 +0200 Cc: IETF SAAG X-Mao-Original-Outgoing-Id: 623518903.898404-5a3922620bc7e27abd49b905791fcac5 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 15:41:50 -0000 On 2020-10-04, at 17:17, Paul Hoffman wrote: >=20 > I like Christian's triage (minus the "men=E2=80=9D). +1. Note that these are classes of capabilities. It is worth talking about classes of attacks separately. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Oct 4 09:46:38 2020 Return-Path: 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 BB94E3A08AF for ; Sun, 4 Oct 2020 09:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xCCstkQqxm0i for ; Sun, 4 Oct 2020 09:46:33 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F44B3A08AE for ; Sun, 4 Oct 2020 09:46:33 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 0742F198; Sun, 4 Oct 2020 16:46:30 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Alan DeKok In-Reply-To: Date: Sun, 4 Oct 2020 12:46:29 -0400 Cc: IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <87DC9F8E-1FA9-48AC-9757-182E6E813014@deployingradius.com> References: To: Paul Hoffman X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 16:46:36 -0000 > On Oct 4, 2020, at 11:17 AM, Paul Hoffman = wrote: >=20 > I like Christian's triage (minus the "men"). The "where are they = relative to the path" differentiation is likely to be more = understandable to people who are not security geeks than "what they can = do with creative use of packets". Using a road analogy: a person running = a tollbooth, a person who can watch the cars go by and tell his = colleagues when to enter the stream in order to do damage, a person who = cannot see the traffic or send in cars but can cause lightning storms = and send fake news to the cars on the road. My $0.02 is to call this "the council of attackers". One is a = malicious messenger, who rewrites messages he sends. Another is the = oppressive observer, who uses your information against you. And the = third is the chaos creator, who just breaks things so you can't use = them. Alliteration is cute, and helps with memory. :) =20 Alan DeKok. From nobody Sun Oct 4 10:15:47 2020 Return-Path: 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 193F93A0905 for ; Sun, 4 Oct 2020 10:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BKJeBqHLTCBH for ; Sun, 4 Oct 2020 10:15:44 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 A16853A08E7 for ; Sun, 4 Oct 2020 10:15:44 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QHO0XX78TA8U3@wwwlocal.goatley.com> for saag@ietf.org; Sun, 04 Oct 2020 12:15:44 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QHO00AB7T5VEL@trixy.bergandi.net> for saag@ietf.org; Sun, 04 Oct 2020 10:13:08 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 04 Oct 2020 10:13:08 -0700 Date: Sun, 04 Oct 2020 10:15:37 -0700 From: Dan Harkins In-reply-to: <1601786570544.65950@cs.auckland.ac.nz> To: Peter Gutmann Cc: IETF SAAG Message-id: <6cf04f29-0837-5fe1-c9fd-59d31d606f3c@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> <1601786570544.65950@cs.auckland.ac.nz> X-PMAS-Software: PreciseMail V3.3 [201003] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 17:15:46 -0000 On 10/3/20 9:42 PM, Peter Gutmann wrote: > Dan Harkins writes: > >> 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? > Because it's far easier to deploy a relatively straightforward, realistic > protocol secure against a general attack than it is to deply an awkward, > complex, impractical protocol that's theoretically (but often not practically) > secure against a more unlimited attacker. To quote the end of John Gordon's > joke: > > Now most people in Alice's position would give up. Not Alice. She has > courage which can only be described as awesome. Against all odds, over a > noisy telephone line, tapped by the tax authorities and the secret police, > Alice will happily attempt, with someone she doesn't trust, whom she cannot > hear clearly, and who is probably someone else, to fiddle her tax returns > and to organize a coup d'etat, while at the same time minimizing the cost of > the phone call. > > A coding theorist is someone who doesn't think Alice is crazy. > > I don't need a theoretically perfect protocol that's practically un- > deployable, I just need something that's practical and good enough for the > job.   For some people the job includes tax avoidance and fomenting of coups.   Dan. From nobody Sun Oct 4 10:22:45 2020 Return-Path: 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 023813A0906 for ; Sun, 4 Oct 2020 10:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RTqpUGi9cZre for ; Sun, 4 Oct 2020 10:22:41 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 E4D703A0905 for ; Sun, 4 Oct 2020 10:22:41 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QHO0XYUTTLT13@wwwlocal.goatley.com> for saag@ietf.org; Sun, 04 Oct 2020 12:22:41 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QHO00BB7THMI3@trixy.bergandi.net> for saag@ietf.org; Sun, 04 Oct 2020 10:20:11 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 04 Oct 2020 10:20:11 -0700 Date: Sun, 04 Oct 2020 10:22:40 -0700 From: Dan Harkins In-reply-to: To: saag@ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1eV+rLVBdsAO/9OTW0J9Zw)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: X-PMAS-Software: PreciseMail V3.3 [201003] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 17:22:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_1eV+rLVBdsAO/9OTW0J9Zw) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT On 10/3/20 10:23 PM, Christian Huitema wrote: >> On Oct 3, 2020, at 8:00 PM, Eric Rescorla wrote: >> >> The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao >> attacker. >> >> The 21.13.3.2 "off-path" attacker seems to have the ability to >> observe >> packets, which I normally would not think an off-path attacker >> would have. >> So this definition is very surprising to me. >> >> >> I agree it's not ideal. QUIC has been pubreq-ed, so you could raise >> it in IETF-LC. > > I think of it as man-in-the-middle, man-on-the-side and > man-in-the-rough. For me, the man in the middle is what EKR refers to > as the Dolev-Yao attacker; best hope there is to detect the attack and > reduce it to a denial of service. > > The man on the side is capable of reading the traffic and injecting > messages; it cannot easily delete messages,  but it can win races and > get his own fakery delivered before the genuine packets -- TCP RST is > an example of such attacks. Various national organizations have that > capability. It is much easier for them to implement than a full MITM. > I think that with effort we can defeat this class of attackers. > > The man in the rough does not see the traffic but can make guesses. > DDOS attacks, port scanning, observing or gaming DNS caches fall in > that category. Botnets sometimes resort to these attacks.   This is useful. Defining it as classes of capabilities. The man-in-the-rough has certain capabilities, class C. The man-on-the-side has those plus some others, class B. And the man-in-the-middle (the Dolev-Yao attacker) has those plus some others, class A. And A > B > C. > > And yes, in 2020 we probably need names that don't carry "man-in-foo" > imagery. But English is not my mother tongue...   Yes, and sadly, this being 2020, identity politics plus bike shedding will mean most of the time is spent on naming/imagery.   Dan. --Boundary_(ID_1eV+rLVBdsAO/9OTW0J9Zw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT

On 10/3/20 10:23 PM, Christian Huitema wrote:
On Oct 3, 2020, at 8:00 PM, Eric Rescorla <ekr@rtfm.com> wrote:

The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao attacker.

The 21.13.3.2 "off-path" attacker seems to have the ability to observe
packets, which I normally would not think an off-path attacker would have.
So this definition is very surprising to me.

I agree it's not ideal. QUIC has been pubreq-ed, so you could raise it in IETF-LC.

I think of it as man-in-the-middle, man-on-the-side and man-in-the-rough. For me, the man in the middle is what EKR refers to as the Dolev-Yao attacker; best hope there is to detect the attack and reduce it to a denial of service.

The man on the side is capable of reading the traffic and injecting messages; it cannot easily delete messages,  but it can win races and get his own fakery delivered before the genuine packets -- TCP RST is an example of such attacks. Various national organizations have that capability. It is much easier for them to implement than a full MITM. I think that with effort we can defeat this class of attackers.

The man in the rough does not see the traffic but can make guesses. DDOS attacks, port scanning, observing or gaming DNS caches fall in that category. Botnets sometimes resort to these attacks.

  This is useful. Defining it as classes of capabilities. The man-in-the-rough has
certain capabilities, class C. The man-on-the-side has those plus some others, class B.
And the man-in-the-middle (the Dolev-Yao attacker) has those plus some others, class
A. And A > B > C.


And yes, in 2020 we probably need names that don't carry "man-in-foo" imagery. But English is not my mother tongue...
  Yes, and sadly, this being 2020, identity politics plus bike shedding will mean most
of the time is spent on naming/imagery.

  Dan.



--Boundary_(ID_1eV+rLVBdsAO/9OTW0J9Zw)-- From nobody Sun Oct 4 13:31:26 2020 Return-Path: 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 0409C3A0A1F for ; Sun, 4 Oct 2020 13:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aMhOM30VycgR for ; Sun, 4 Oct 2020 13:31:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC8B3A09EF for ; Sun, 4 Oct 2020 13:31:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 57A25389B6 for ; Sun, 4 Oct 2020 16:36:26 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wSBcvB-aCdd2 for ; Sun, 4 Oct 2020 16:36:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C1189389B5 for ; Sun, 4 Oct 2020 16:36:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F13FE7E for ; Sun, 4 Oct 2020 16:31:12 -0400 (EDT) From: Michael Richardson To: IETF SAAG In-Reply-To: <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 20:31:24 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dan Harkins wrote: >> 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. > =C2=A0 Why? If we want to develop protocols that are secure in the pr= esence > of a powerful attacker who has complete control of the medium what > value is there in considering a "more limited attacker"? The utility of the terminology is that it makes it clear what kinds of threats there are, and what mechanisms defend against which. There are many cases where we can assume (as a result of a sound L2 protoco= l) that there are no Dolev-Yao on-path attackers, but that there may be many off-path attackers who can send traffic. At the same time, the existence of nodes which may harbour malware, giving them access to the L2-media, but not to make on-path attacks, makes understanding what the layers of defense we might have. --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Description: Signature =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl96MRAACgkQgItw+93Q 3WX5aQf/cCZP9Irg6AJVUMXO1lyRSjk3SCgDbFb6EmFaleD8tZ0e+eq56bLg+lu7 B8oDOOYYBUsozPqudEahg+6+7Jiclp/wkDWMsud8pR/sOiC4JuuTdfzM7P4w18bJ YbIpgRxoPkJPt3b0kxTlkOZrdS4x8Uikk3cCrfQa7/3sY+GRItLAa+3s/HoJRNe0 qRBXDxJzpXzj2/Nd99KOOE7OyuFVlyNVK67HfxAJkaDXbL6una8UjtISyfgTUYPu 5Eqh631jR3hmy3KPwH4v9KazOhpxtJS3BlELd+G2vj541ybhEfRsAkdyng4injfM Mqyhls2fprBSgO6V2eGdAHOSP5PMig== =sIPS -----END PGP SIGNATURE----- --==-=-=-- From nobody Sun Oct 4 15:17:28 2020 Return-Path: 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 DA0393A0A50 for ; Sun, 4 Oct 2020 15:17:26 -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, 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=cryptonector.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 y3ORZNEvFFE5 for ; Sun, 4 Oct 2020 15:17:24 -0700 (PDT) Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (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 F12AC3A0A49 for ; Sun, 4 Oct 2020 15:17:23 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2451C640987; Sun, 4 Oct 2020 22:17:23 +0000 (UTC) Received: from pdx1-sub0-mail-a98.g.dreamhost.com (100-100-138-5.trex.outbound.svc.cluster.local [100.100.138.5]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 86A59640446; Sun, 4 Oct 2020 22:17:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a98.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Sun, 04 Oct 2020 22:17:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Thoughtful-Abaft: 1b2de5f442860f42_1601849842854_4152633201 X-MC-Loop-Signature: 1601849842854:518875501 X-MC-Ingress-Time: 1601849842854 Received: from pdx1-sub0-mail-a98.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a98.g.dreamhost.com (Postfix) with ESMTP id 01E27BA831; Sun, 4 Oct 2020 15:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2IGYF/vRD9JeWH /oYMXyeXcoTbE=; b=U4E5AbjKgQ9VjX4WNk9sutspRv5YGWzL+D/40qo90SRws3 mxtusTPZm3N9annVx4a05AAfksq+/HE0XJFClR/2Lmov25NGpaT1Fv+vVIxjjqXc puxAgFjkEYJM46vbKGgPpcbAbkGWdpJNp51FEWMXcZBJzhJ/RtumsaZplu4tI= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 4228FBA82F; Sun, 4 Oct 2020 15:17:18 -0700 (PDT) Date: Sun, 4 Oct 2020 17:17:16 -0500 X-DH-BACKEND: pdx1-sub0-mail-a98 From: Nico Williams To: Eric Rescorla Cc: Dan Harkins , Michael Richardson , Fernando Gont , IETF SAAG Message-ID: <20201004221715.GB3100@localhost> References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgedugddtlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepffdtkeethfeuteeviefgfeegjeetjedvhfehgfdvtdefueejheelgeeuhffghffgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 22:17:27 -0000 On Sat, Oct 03, 2020 at 07:58:15PM -0700, Eric Rescorla wrote: > On Sat, Oct 3, 2020 at 6:14 PM Dan Harkins wrote: > > 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? We could come up with a name for each set of attacker capabilities, or we could just list the capabilities. We should want a compact representation so as to aid in keeping things pithy. It is true that neither "on-path" nor "MITM" are sufficiently exact. For example, "on-path" need not imply "active attacker", for example, and "MITM" need not imply physically on-path. And an active attacker who is on-path can be an MITM at some layers but maybe not others. An active attacker who is on-path should be able to observe, modify, and insert messages, but dropping messages might be harder. For example, in a wireless system dropping a message might require jamming it, but that would require making a decision to drop a particular message before the transmission of it ends -- having to see the whole message first would mean not being able to jam it because the whole message will also already have been received by the intended recipient. Note that in the wireless example "on-path" is just not a very good descriptor at all. If the communication is line-of-sight and the attacker could literally block all radiation in the relevant frequencies between the two end-points, then they can be on-path in the same sense that the attacker could be on the wire. Otherwise the attacker is on-path some ways, and not at all in others. IMO there's enough combinations that we probably just want to list the attacker's capabilities. We could encode it pithily as a set of one- character flags, say: Ln{flags},Ln{flags}... where is a layer and {flags} is a set of letters, each representing a capability: - O (observe) - M (modify) - I (insert) - D (drop) E.g., 'L3O' == "on-path" eavesdropper, "L3OMID" == all-powerful on-path MITM at layer 3 that a protocol might want to defend against, but taking EKR's point about DoS (below) we might limit our threat models to just L3OMI attackers. Such pithy attacker capability description language would probably need a lot of work to be really useful. For example, a real attacker might only be on-path enough to see some DNS traffic but then might leverage DNS spoofing and cache poisoning to get itself to be on-path enough in some cases. > 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. This is a DoS attack. It is true that many DoS attacks cannot be defeated cryptographically. For example, a physical cable cut cannot be protected against with crypto. What kinds of active attacks other than DoS attacks cannot be defended against? Nico -- From nobody Sun Oct 4 16:48:39 2020 Return-Path: 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 074153A0A9D for ; Sun, 4 Oct 2020 16:48:38 -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 V8sup8knVqg5 for ; Sun, 4 Oct 2020 16:48:36 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 CCE243A09A4 for ; Sun, 4 Oct 2020 16:48:35 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id a22so5768794ljp.13 for ; Sun, 04 Oct 2020 16:48: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=oXTZx/WreLK1uhFk568mLBT0yNn3anPsW816Wq52iD8=; b=i6Pz71AJp1ipwTiwGpXGxzXlAbDnnSlJknSMhOj+tDkuui+5/Klzfn2F7MngX6bIeo Naz6sxqkILQ5/AkxOKx8emCeAIuYAB4Np1tPAMH9bMVzvlIu1FCGk0uBUPiBIqH/yx8c rATTQnsUC9n0RZjrN95EZlxmw7WnccDuKjki+hOA+XfBDA6U/YccgZzEyaM2ZAmlFfYw EIO6tsW5Qck0sLuLl8eqy1YwkItg6w2AuZlixQDX0VNZMeuJVYc2ttlZBF3sxkmNEANu GWoA0t08iKcr0G6YqSBuNpPycRWEPkt0fcu+sz13xv9mEFEqrFWCC9/uX03KmU2qoEJu Fjdw== 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=oXTZx/WreLK1uhFk568mLBT0yNn3anPsW816Wq52iD8=; b=HhXLJDOh4wpLSdvvnGY6kPlsRfz/VR4eHcn8qO8Mn5OCX+GI6a3ABKycv5SPsdoPn8 qi6m6douSuExZBlcelEuVcz1Mgs6vFtPrkVZNGf1SqIMQfQEN7xOOqU7cNCO4rU5PZkS ZxOdXaMRCz5YROs93Evqhozjfwifn4sezkkcY3N+teDEL7htlxIeTDaSSSwpEhcqw7nu RYRrpW2Mv8nebjyPtPM/TjCjAel/lLF9QDqOD0cIqHzrOBsmbewcqLJ83nwPDguc4PLJ cPiEcLQ+t0HMEuKNFbZHCBLlXQyczs4OmHMoPgrqUEn/3QS9Y3QFP5hLpeYke4MoAWKx 3a7g== X-Gm-Message-State: AOAM531pGVsWqYkVyMzASuK+EDjTWPLD7rNciEaVal5hklzYSJIqudIG +S7hed/aSJi8Ybzjj9oRWZr5xXStKZAChysB6N8jDg== X-Google-Smtp-Source: ABdhPJzltRrXQZ+caMqLVEUTa0niTLY+M70W3nHmrWu1Ix7RBD5AigpVsqvKvKXPv11iptEfhhg7HnDhgtFLlDeh/Eo= X-Received: by 2002:a2e:9849:: with SMTP id e9mr3287770ljj.184.1601855313875; Sun, 04 Oct 2020 16:48:33 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> <20201004221715.GB3100@localhost> In-Reply-To: <20201004221715.GB3100@localhost> From: Eric Rescorla Date: Sun, 4 Oct 2020 16:47:57 -0700 Message-ID: To: Nico Williams Cc: Dan Harkins , Michael Richardson , Fernando Gont , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000f72c3305b0e1007c" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 23:48:38 -0000 --000000000000f72c3305b0e1007c Content-Type: text/plain; charset="UTF-8" On Sun, Oct 4, 2020 at 3:17 PM Nico Williams wrote: > On Sat, Oct 03, 2020 at 07:58:15PM -0700, Eric Rescorla wrote: > > 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. > > This is a DoS attack. It is true that many DoS attacks cannot be > defeated cryptographically. For example, a physical cable cut cannot be > protected against with crypto. What kinds of active attacks other than > DoS attacks cannot be defended against? > I'm not sure that I would characterize connection termination as DoS (arguably, this is another case of terminological imprecision). For instance, sometimes it's a piece of another attack, such as in ABP+13 [0] or BDF+14 [1]. In any case, another example of an attack that is difficult to defend against cryptographically is IP address spoofing attacks. For instance, an on-path attacker can force QUIC migration (how useful this is is not clear) but an off-path attacker cannot and an on-path attacker who cannot delete packets is supposed to be able to cause a hiccup but not permanent migration. Finally, another example of a limited threat model is one in which the attacker has Dolev-Yao access to only some set of network segments. This is often used in the analysis of anonymity protocols like Tor. While it is believed to be possible to build low latency protocols which provide anonymity under this threat model, AFAIK it is not known how to do so efficiently. -Ekr [0] http://www.isg.rhul.ac.uk/tls/RC4biases.pdf [1] https://www.mitls.org/pages/attacks/3SHAKE --000000000000f72c3305b0e1007c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 4, 2020 at 3:17 PM Nico W= illiams <nico@cryptonector.com<= /a>> wrote:
O= n Sat, Oct 03, 2020 at 07:58:15PM -0700, Eric Rescorla wrote:
> IMO t= he 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 attack= er,
> but which we can defend against a weaker attacker and (2) weaker attac= kers
> exist.
>
> As a concrete example, it is possible for such an attacker to terminat= e
> 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 prote= cted.
> 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.

This is a DoS attack.=C2=A0 It is true that many DoS attacks cannot be
defeated cryptographically.=C2=A0 For example, a physical cable cut cannot = be
protected against with crypto.=C2=A0 What kinds of active attacks other tha= n
DoS attacks cannot be defended against?

I'm not sure that I would characterize connection termination as DoS (= arguably, this is another case of terminological imprecision). For instance= , sometimes it's a piece of another attack, such as in ABP+13 [0] or BD= F+14 [1].


--000000000000f72c3305b0e1007c-- From nobody Sun Oct 4 16:56:26 2020 Return-Path: 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 76F6A3A0AA4 for ; Sun, 4 Oct 2020 16:56:25 -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 o0pJELHWA7sB for ; Sun, 4 Oct 2020 16:56:23 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 44E823A0AA3 for ; Sun, 4 Oct 2020 16:56:23 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id y11so8725453lfl.5 for ; Sun, 04 Oct 2020 16:56:23 -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=4h/IDnyWq9R+YsXmYXGp2Z5NZBqrgsQcLPdv2rUENnE=; b=uLiBneo9IBOAetZSVuzOR2shN6PDdnVj/g8mbfe6FYkz8hHp3yqfYC2p/eVcS/uefi dPhWZmBQWqg77ypKMM3iHx/BBCETab130efJE9r0ej9EpvH0SP6ZD9oKljIU+qxu1dfU gkJf34YmpxPqnwhntXw3IZGDsiofKtbO6B4QLflmq6vGS28nS+OKwG1lT6056VCdUwGX JokLNXm4kqGA3r2z8qDLuiiQgkxhRoV9jv0Z+UX9K0GWTOU/U42wfzn0GDVMV6c9OjTa QPllP/6/TcsSEsCjgiX3N/HNlpvjY6Mrbuc388aJcrJqpDvnVbOostFmd3FKIKvgIRjI /Zuw== 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=4h/IDnyWq9R+YsXmYXGp2Z5NZBqrgsQcLPdv2rUENnE=; b=knb3LJHsZHv6A3EE5/2QLnQFibh5m8JGKLzTH1c+RQ7NnD9jSJFxNozZqU5z7j+uZQ fvy+FiQEhAT7fDwCFTMIYxmdJPqQmR/fJ2+yeyaYx9OnBgIC42lxQCUPhuv/pFZyc2Cf 1M70BBwJq5s1aDfwu8zyh8Fp4zfpw7p2lJnM7XKbGyZUTEUBcjysYXlmTYh9713w9qrd uFVljdfphpUAFWlLzlx+9lMGMqSdY+EfJIxwYajTglQk33hBgnVgEbpajSQ+6j16ptmP O9sU+VODqVeNNngAmdlwtPTTcQcWYD/oA56SHC+9z+6/zp72UOsfc1EN7aIePCBzf9LD Y28g== X-Gm-Message-State: AOAM530JMciTT+iYrs0KBepWhboFLMS0Vd86mQvpvXcUodkZlujpBDQz 0f/0AHPqgxnCpGmwlpi0pRx+g4kpUbnzk479ZEtxkQ== X-Google-Smtp-Source: ABdhPJyTFDkhIz14JgcUZTt/dDshe9wDlMxjHSz144T8D/Ik88vZIg7YeSbsWzMrUgjS5bdVQz0ApTMlzWhQHAeyf0Y= X-Received: by 2002:a19:5e15:: with SMTP id s21mr91944lfb.579.1601855781355; Sun, 04 Oct 2020 16:56:21 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> <20201004221715.GB3100@localhost> In-Reply-To: From: Eric Rescorla Date: Sun, 4 Oct 2020 16:55:45 -0700 Message-ID: To: Nico Williams Cc: Dan Harkins , Michael Richardson , Fernando Gont , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000d45b7405b0e11c7b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 23:56:25 -0000 --000000000000d45b7405b0e11c7b Content-Type: text/plain; charset="UTF-8" On Sun, Oct 4, 2020 at 4:47 PM Eric Rescorla wrote: > > > On Sun, Oct 4, 2020 at 3:17 PM Nico Williams > wrote: > >> On Sat, Oct 03, 2020 at 07:58:15PM -0700, Eric Rescorla wrote: >> > 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. >> >> This is a DoS attack. It is true that many DoS attacks cannot be >> defeated cryptographically. For example, a physical cable cut cannot be >> protected against with crypto. What kinds of active attacks other than >> DoS attacks cannot be defended against? >> > > I'm not sure that I would characterize connection termination as DoS > (arguably, this is another case of terminological imprecision). For > instance, sometimes it's a piece of another attack, such as in ABP+13 [0] > or BDF+14 [1]. > > In any case, another example of an attack that is difficult to defend > against cryptographically is IP address spoofing attacks. For instance, an > on-path attacker can force QUIC migration (how useful this is is not clear) > but an off-path attacker cannot and an on-path attacker who cannot delete > packets is supposed to be able to cause a hiccup but not permanent > migration. > > Finally, another example of a limited threat model is one in which the > attacker has Dolev-Yao access to only some set of network segments. This is > often used in the analysis of anonymity protocols like Tor. While it is > believed to be possible to build low latency protocols which provide > anonymity under this threat model, AFAIK it is not known how to do so > efficiently. > Correcting my bad writing here: "While it is believed to be possible to build anonymity protocols under the stronger threat model, AFAIK it is not known how to do so efficiently." -Ekr [0] http://www.isg.rhul.ac.uk/tls/RC4biases.pdf [1] https://www.mitls.org/pages/attacks/3SHAKE > --000000000000d45b7405b0e11c7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 4, 2020 at 4:47 PM Eric R= escorla <ekr@rtfm.com<= /a>> wrote:
<= div dir=3D"ltr">


<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oct 4, 2020 at 3:17 PM Nico Wi= lliams <nico@= cryptonector.com> wrote:
On Sat, Oct 03, 2020 at 07:58:15PM -0700, Eric Rescorla wro= te:
> 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 attack= er,
> but which we can defend against a weaker attacker and (2) weaker attac= kers
> exist.
>
> As a concrete example, it is possible for such an attacker to terminat= e
> 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 prote= cted.
> 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.

This is a DoS attack.=C2=A0 It is true that many DoS attacks cannot be
defeated cryptographically.=C2=A0 For example, a physical cable cut cannot = be
protected against with crypto.=C2=A0 What kinds of active attacks other tha= n
DoS attacks cannot be defended against?

I'm not sure that I would characterize connection termination as DoS (= arguably, this is another case of terminological imprecision). For instance= , sometimes it's a piece of another attack, such as in ABP+13 [0] or BD= F+14 [1].

In any case, another example of an = attack that is difficult to defend against cryptographically is IP address = spoofing attacks. For instance, an on-path attacker can force QUIC migratio= n (how useful this is is not clear) but an off-path attacker cannot and an = on-path attacker who cannot delete packets is supposed to be able to cause = a hiccup but not permanent migration.

Finally, ano= ther example of a limited threat model is one in which the attacker has Dol= ev-Yao access to only some set of network segments. This is often used in t= he analysis of anonymity protocols like Tor. While it is believed to be pos= sible to build low latency protocols which provide anonymity under this thr= eat model, AFAIK it is not known how to do so efficiently.

Correcting my bad w= riting here: "While it is believed to be possible to build anonymity p= rotocols under the stronger threat model, AFAIK it is not known how to do s= o efficiently."

-Ekr

[1] https://www.mitls.org/pages/attacks/3SHAKE
--000000000000d45b7405b0e11c7b-- From nobody Mon Oct 5 08:52:00 2020 Return-Path: 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 6BE2F3A0C4A for ; Mon, 5 Oct 2020 08:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=cert.org 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 sgr32mYrzhgz for ; Mon, 5 Oct 2020 08:51:51 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 BFADB3A0DDF for ; Mon, 5 Oct 2020 08:51:49 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 095FpmiM000932 for ; Mon, 5 Oct 2020 11:51:48 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 095FpmiM000932 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1601913108; bh=VrdQcvz33GpscK/u0OeDmSMpn+SgTtMJdrKJWQvTzyU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Z1smm+13xUPRA+5GG0aeQdEHRJyNSVoIvUfQ5chhYU3URi34twARmAcdDxOQvyUXb 94XfACTenTwLlacVreNW8X1yp2Qt5JP6LijqIF+H7UIH9IoyPhH7zX/2JRZbrgbNiY eBJjdmMMMlROleSfb4g1IebYLF06WpCWKPziKR3s= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 095Fpi42027716 for ; Mon, 5 Oct 2020 11:51:44 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 5 Oct 2020 11:51:44 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 5 Oct 2020 11:51:44 -0400 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: Jim Schaad Thread-Index: AQHWmo1UGcKStRMEAE2YetEN7d36KqmJDilA Date: Mon, 5 Oct 2020 15:51:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [saag] FW: Jim Schaad X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 15:51:58 -0000 KEZvcndhcmRpbmcgaGVyZSBmcm9tIGlldGZAaWV0Zi5vcmcgdG8gZW5zdXJlIHZpc2liaWxpdHkp DQoNCkl0IGlzIHdpdGggZ3JlYXQgc2FkbmVzcyB0aGF0IEkgcmVsYXkgdGhlIG5ld3Mgb2YgSmlt IFNjaGFhZCdzIHBhc3NpbmcuICBKaW0gd2FzIGluc3RydW1lbnRhbCBpbiB0aGUgc3VjY2VzcyBv ZiBzbyBtYW55IG9mIG91ciB3b3JraW5nIGdyb3Vwcy4gIE5vdCBvbmx5IGRpZCBoZSBjaGFpciB0 aGVtIGFuZCBhdXRob3IgdGhlaXIga2V5IGRyYWZ0cywgaGUgZ2F2ZSBnZW5lcm91c2x5IG9mIGhp cyB0aW1lIHdpdGggZG9jdW1lbnQgcmV2aWV3cywgbWVudG9yaW5nIGFuZCByZXNvbHZpbmcgV0cg Y29udGVudGlvbiB3aXRoIGdyb3VuZCB0cnV0aCBmcm9tIHRoZSBjb2RlIGhlIHdyb3RlLg0KDQpJ IHdpbGwgbWlzcyBoaW0uDQoNCldpdGggZ3JlYXQgc29ycm93LA0KUm9tYW4NCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0ZiA8aWV0Zi1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgSmF5IERhbGV5DQpTZW50OiBTdW5kYXksIE9jdG9iZXIgNCwgMjAyMCA0OjMx IFBNDQpUbzogSUVURiBEaXNjdXNzaW9uIDxpZXRmQGlldGYub3JnPg0KU3ViamVjdDogSmltIFNj aGFhZA0KDQpJIGhhdmUgaGVhcmQgZnJvbSBKaW0gU2NoYWFk4oCZcyBicm90aGVyIFRvbSB0aGUg c2FkIG5ld3MgdGhhdCBKaW0gcGFzc2VkIGF3YXkgYXQgdGhlIGVuZCBvZiBsYXN0IHdlZWsuICBK aW0gd2FzIHRoZSBjby1jaGFpciBvZiBhY2UgYW5kIGNib3IgYW5kIGEgbG9uZyB0aW1lIElFVEYg Y29udHJpYnV0b3Igd2l0aCBhIHByb2xpZmljIG91dHB1dCBhcyBzaG93biBvbiBoaXMgcHJvZmls ZSBwYWdlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvcGVyc29uL0ppbSUyMFNjaGFhZCAu IA0KDQppZiBhbnlvbmUgd2lzaGVzIHRvIHJlYWNoIG91dCB0byBUb20gdGhlbiBwbGVhc2UgbGV0 IG1lIGtub3cgYW5kIEkgd2lsbCBwYXNzIG9uIGRldGFpbHMuICBUb20gaXMgYWxzbyBsb29raW5n IGZvciBoZWxwIGdhaW5pbmcgYWNjZXNzIHRvIHRoZSBJVCBraXQgdGhhdCBKaW0gbWFpbnRhaW5l ZCBhbmQgd2hpY2ggcnVucyB0aGVpciB3aW5lcnkgYnVzaW5lc3MuDQoNCkpheQ0KDQoNCi0tIA0K SmF5IERhbGV5DQpJRVRGIEV4ZWN1dGl2ZSBEaXJlY3Rvcg0KamF5QGlldGYub3JnDQoNCg== From nobody Fri Oct 23 14:17:59 2020 Return-Path: X-Original-To: saag@ietf.org Delivered-To: saag@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C213A0B65; Fri, 23 Oct 2020 14:15:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774898.5087.6127723066925329987@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:48 -0700 Archived-At: Subject: [saag] saag - Requested session has been scheduled for IETF 109 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:52 -0000 Dear Benjamin Kaduk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. saag Session 1 (2:00 requested) Thursday, 19 November 2020, Session I 1200-1400 Room Name: Room 7 size: 507 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/saag.ics Request Information: --------------------------------------------------------- Working Group Name: Security Area Open Meeting Area Name: Security Area Session Requester: Benjamin Kaduk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: ace acme cfrg cose curdle dots emu gnap i2nsf ipsecme kitten lamps mile mls oauth rats sacm secdispatch secevent suit teep tls tokbind trans privacypass Technology Overlap: dmarc dprive sidrops uta pearg Key Participant Conflict: irtfopen People who must be present: Roman Danyliw Benjamin Kaduk Resources Requested: Special Requests: Normally we ask for Thursday "after lunch", but for the virtual meeting any time on Thursday should be fine. ---------------------------------------------------------