From nobody Thu Sep 9 21:46:49 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED7D3A18E0 for ; Thu, 9 Sep 2021 21:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.087 X-Spam-Level: X-Spam-Status: No, score=-18.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 naab8P6dVPcC for ; Thu, 9 Sep 2021 21:46:42 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 1DBBC3A18E1 for ; Thu, 9 Sep 2021 21:46:38 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id g9so762032ioq.11 for ; Thu, 09 Sep 2021 21:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=pJ9zMqVAzWQpG5xm98L0sz8vovK8wOlwOlGFvshZNOI=; b=pIWeCe3DZ58cMfVe1G0QTzOo6xoJxo3KIASrV7m88+DZ/DfxeSqm7DfAkwGDJLqIl6 cZvzdCei9zpboBvEHkXinV8nhtcZKVy/ZZ1e0NTYEqSpPhAx/h0W2T+/vZgh2i9tlbxE Uz2v9Q43/eMJMhJDmhdtCZiATV+GDepzWES1+7t+tPZT0H+pknLPXbKjbd43xcNPv69e fyxKnymAj2lmvu5ARgQLcGxNJ8k3nyFVDBCtwTbEn1r9reoTn4Ye6Wl0IQw1pYuHZ6gu EzSKJuet0ATl75foappAUnINjQntBdJ23H4HTXyAAEnQ1KsGNZV8ZWrrqI1bBYnWFj78 EecA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pJ9zMqVAzWQpG5xm98L0sz8vovK8wOlwOlGFvshZNOI=; b=UjCTQwbVNPUQimxvEu1kWH5WON+zo5jVUy+Oo+Obwp6/jPvnUUiELAdbhezMO6ONuI gqnqe2Kj86imxFRuzRsJUEFCr8KgtZ2IpTA+QEVYntnBiajYaEbmfZmmixxCqUHfyQMm psMwjRpDi0MHkO2Q8X+seZyurDd0YsvhTYSCaFOX5Gi1gz7rfcTWDFAVYJBEua1F4x5u krtStxGjDqvEdrv7y5r+s1mh6xYFR2haSCY8r2AyzD77I8R1AzflxgIfztcumMI2lQyV Rtw7rimX9IZk24OIUAsfOE0pqfvP4Sod0m42N9in8GpNSZDVTApNBK5OVbQFJ+PV0Rbm ctAw== X-Gm-Message-State: AOAM531HWpmaudYgYl5d4rVxsOYwQfsjVbsal7KkD8yhxv1wYAFfMo71 XVfYr+OdkWI0MZpxUQD8btdEUmGizkx1t2324wk+GY30mqwOMQ== X-Google-Smtp-Source: ABdhPJyiy0Cskbovu6J4igfzICv1i8lk+zdywj8yPhKCCXv7WbWze+4ZRDgB/EFGu8em9v5YQmUx3s/Yb/epUgy7alo= X-Received: by 2002:a05:6638:103b:: with SMTP id n27mr2898014jan.48.1631249196964; Thu, 09 Sep 2021 21:46:36 -0700 (PDT) MIME-Version: 1.0 From: Wei Chuang Date: Thu, 9 Sep 2021 21:46:22 -0700 Message-ID: To: arc@ietf.org Content-Type: multipart/alternative; boundary="000000000000eda85205cb9ccc43" Archived-At: Subject: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 04:46:48 -0000 --000000000000eda85205cb9ccc43 Content-Type: text/plain; charset="UTF-8" Hi all, I think one of the key stumbling blocks for ARC is what to do about building an intermediate forwarder reputation system so I wanted to pose a conceptual idea to build this. The essential idea is to build out an authenticated path as defined by the originator. It's probably easiest to illustrate this as an example below where the message is being sent from gmail -> googlegroups -> outlook. Just to distinguish this proposal from ARC, I've prepended a ARC++ header prefix to denote proposed header changes as well as bolded key properties to be checked for. 1) Origination From: someuser@gmail.com To: example-group@googlegroups.com Arc++-path: i=0; s=gmail.com ; d=googlegroups.com; Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass; d=gmail.com; s=arc-20160816; b=ABCD...Z 2) Mailing list From: someuser@gmail.com To: example-group@googlegroups.com Arc-Authentication-Results: i=1; arc++=pass (....) Arc-Seal: i=1; a=rsa-sha256; t=1628539508; cv=pass; d=googlegroups.com; s=arc-20160816; b=ABCD...Z Arc++-path: i=1; s=googlegroups.com ; d=outlook.com; Arc++-path: i=0; s=gmail.com ; d=googlegroups.com; Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass; d=gmail.com; s=arc-20160816; b=ABCD...Z 2) Recipient From: someuser@gmail.com To: example-group@googlegroups.com Arc-Authentication-Results: i=2; arc++=pass (....) Arc-Seal: i=2; a=rsa-sha256; t=1628539509; cv=pass; d=outlook.com; s=arc-20160816; b=ABCD...Z Arc-Authentication-Results: i=1; arc++=pass (....) Arc++-path: i=1; s=googlegroups.com ; d=outlook.com; Arc-Seal: i=1; a=rsa-sha256; t=1628539507; cv=pass; d=googlegroups.com; s=arc-20160816; b=ABCD...Z Arc++-path: i=0; s=gmail.com ; d=googlegroups.com; Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass; d=gmail.com; s=arc-20160816; b=ABCD...Z There would also be a Arc-Message-Signature header dropped for readability. Also note that the originator generates an ARC set to establish the path. In practice, likely the path key-value could be subsumed by some other ARC header. This example works by establishing a path from the FROM sender domain to the destination in order to show the intent for each sender to go along this path to be trusted by the destination. Here it is gmail.com -> googlegroups.com -> outlook.com. Each hop signed for themselves and the intended next hop recipient domain. All recipients should be able to validate the path up to that point by checking the signatures, and then matching the source and destination for each edge in the path. Validate the ARC chain. Also the timestamps must be approximately increasing and within some rough time guardband, to check there wasn't a replay attack. A valid path can be used as an authentication input to DMARC to show the intent of the FROM domain sender for the purposes of applying domain policy. Then do normal spam checking on message content, and quantify this to create a reputation signal. Apply the reputation for the sender and intermediates domains along that path. That reputation signal might be used in aggregate when the path authentication isn't established by the originator but can fall back to regular ARC, to determine when the intermediates are considered trustworthy. Feedback is very much welcome. -Wei --000000000000eda85205cb9ccc43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I think one of the key stumbling blocks for ARC is what t= o do about building an intermediate forwarder reputation system so I wanted= to pose a conceptual idea to build this.=C2=A0 The essential idea is to bu= ild out an authenticated path as defined by the originator.=C2=A0 It's probably easiest to il= lustrate this as an example below where the message is being sent from gmai= l -> googlegroups -> outlook.=C2=A0 Just to distinguish this proposal= from ARC, I've prepended a ARC++ header prefix to denote proposed head= er changes as well as bolded key properties to be checked for.=C2=A0=C2=A0<= /span>

1) Origination

From: someuser@gmail.com

To: example-group@googlegroups.com

Arc++-path: i=3D0; s=3Dgmail.com ; d=3Dgooglegroups.com;

= Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D1628539507; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= d=3Dgmail.com; s=3Darc-20160816; b=3DABCD= ...Z

2) Mailing li= st

From: someuser@gmail.com

To: example-group@googlegroups.com

Arc-Authentication-Results: i=3D1; arc++=3Dpass (....)<= /p>

Arc-Seal: i=3D1; a=3Drsa-sha256; t=3D1628539508; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= d=3Dgooglegroups.com; s=3Darc-2016= 0816; b=3DABCD...Z

Arc++-path: i=3D1; s=3Dgooglegroup= s.com ; d=3Doutlook.com;

<= p dir=3D"ltr" style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">Arc++-path: i=3D0; s=3Dgmail.com ; d=3Dgooglegroups.com;

= Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D162853= 9507; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0d=3Dgmail.com; s= =3Darc-20160816; b=3DABCD...Z

2) Recipient

From: someuser@gmail.com

To: example-group@googlegroups.com

Arc-Authentication-Results: i=3D2; arc++= =3Dpass (....)

Arc-Seal: i=3D2; a=3Drsa-sha256; t=3D1628539509; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0d=3D<= a href=3D"http://outlook.com">outlook.com= ; s=3Darc-20160816; b=3DABCD...Z

Arc-Authen= tication-Results: i=3D1; arc++=3Dpass (....)

Arc++-path: i=3D1; s=3Dgooglegroups.com ; d=3Dou= tlook.com;

Arc-Seal: i=3D1; a=3Drsa-sha256; t=3D1628539507; cv=3Dpass;<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0d=3Dgooglegroups.com; s=3Darc= -20160816; b=3DABCD...Z

Arc++-path: i=3D0; s=3Dgmail.com= ; d=3Dgooglegroups.com;

=

<= span style=3D"font-family:"Courier New";color:rgb(0,0,0);backgrou= nd-color:transparent;font-variant-numeric:normal;font-variant-east-asian:no= rmal;vertical-align:baseline;white-space:pre-wrap">Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D1628539507; cv=3Dpass;<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0d= =3Dgmail.com; s=3Darc-20160816; b=3DABCD..= .Z


There would a= lso be a Arc-Message-Signature header dropped for readability.=C2=A0 Also n= ote that the originator generates an ARC set to establish the path.=C2=A0 I= n practice, likely the path key-value could be subsumed by some other ARC h= eader.=C2=A0=C2=A0


This example works by establishing a path from the FROM sender domain to= the destination in order to show the intent for each sender to go along th= is path to be trusted by the destination.=C2=A0 Here it is gmail.com -> google= groups.com -> outlook.com.=C2=A0 = Each hop signed for themselves and the intended next hop recipient domain.= =C2=A0 All recipients should be able to validate the path up to that point = by checking the signatures, and then matching the source and destination fo= r each edge in the path. =C2=A0 Validate the ARC chain. Also the timestamp= s must be approximately increasing and within some rough time guardband, to= check there wasn't a replay attack.=C2=A0 A valid path can be used as = an authentication input to DMARC to show the intent of the FROM domain send= er for the purposes of applying domain policy.=C2=A0 Then do normal spam ch= ecking on message content, and quantify this to create a reputation signal.= =C2=A0 Apply the reputation for the sender and intermediates domains= along that path.=C2=A0 That reputation signal might be used in aggregate w= hen the path authentication isn't established by the originator but can= fall back to regular ARC, to determine when the intermediates are consider= ed trustworthy.


Feedback is very much welcome.


-Wei
--000000000000eda85205cb9ccc43-- From nobody Fri Sep 10 11:59:41 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395303A154B for ; Fri, 10 Sep 2021 11:59:38 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=muJPejXu; dkim=pass (2048-bit key) header.d=taugh.com header.b=yozPMjtq 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 tYMMCqG5ibvb for ; Fri, 10 Sep 2021 11:59:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 229B33A1547 for ; Fri, 10 Sep 2021 11:59:32 -0700 (PDT) Received: (qmail 95642 invoked from network); 10 Sep 2021 18:59:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17598.613bab13.k2109; bh=2vbOSp73kP9OP52f1Z9dZeiCwjrC5vM0EIn5p8vwkQc=; b=muJPejXuoIOCHO0WCIc3n3j7j0XR5hXfhaWKpnxv9nd0mzqeirM/AhPhXpIztMk0jT23+hxmCx+jgwXvJx5mtE/JgcMZgR7jbMuXlce7sMmt62Kb6csBLmHkVbvpMocxEl4K9C8174q1977G6Pu9S6SO4FsipHjmNoaafxTfnBMp6/Ts6I4ms8OiWcOyvvifHXQrC+VU2IlPyqo/dxAOUD2vqYz5hTmMrovO4kN38q59KnPepf2euHDk8dQF2k0FqfN+BLNePknRq5eNHd9muE8LFcqLbYGQI8dzNFlA8EH8iYnKRas+cQfD6/HHDidJ5yAYmjCdKdifdpVPpUuegQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17598.613bab13.k2109; bh=2vbOSp73kP9OP52f1Z9dZeiCwjrC5vM0EIn5p8vwkQc=; b=yozPMjtqRr1tCbgxZRUmpcFz3G/zWdiIWYb2Y1QpwWCOLLjwjwIW7g32XclGxBkN2INnL4WJLjTcD4yxR60M+TK7EbLDTdmR9mIeRhfxcXB65APEEFkndpwfWiSZQORMH33A0yzL05unQHZK1UcfEdhIeFT4E/wFkGcHKfgTriZ9kpJ3Sqh8x8XXZCZIJVJKSFIoyPoKirtSCPiIog+6YdaZn8swM4oRUgL+/PzNIkCC8sxg4ypPVqbl9m4H6oGKaOLPMM00p7CZwJrHZOFIzrB7JN8ZWu/XglfQc+iidyXkQg26cFGjPyJq6c33avSh4e6Vla4/ASchjpWgjemZMA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 10 Sep 2021 18:59:30 -0000 Received: by ary.qy (Postfix, from userid 501) id 8223627ACE21; Fri, 10 Sep 2021 14:59:28 -0400 (EDT) Date: 10 Sep 2021 14:59:28 -0400 Message-Id: <20210910185930.8223627ACE21@ary.qy> From: "John Levine" To: arc@ietf.org Cc: weihaw@google.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 18:59:38 -0000 It appears that Wei Chuang said: >This example works by establishing a path from the FROM sender domain to >the destination in order to show the intent for each sender to go along >this path to be trusted by the destination. ... I proposed a somewhat similar idea for DKIM in 2015 which was rather thoroughly rejected in favor of ARC. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ Figuring out all of the downstream forwarders for which a sender needs to set an intent tag is no easier than a receiver figuring out the upstream forwarders with credible ARC chains. R's, John From nobody Sat Sep 11 10:55:09 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279133A204D for ; Sat, 11 Sep 2021 10:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 P_hHxrbPClZs for ; Sat, 11 Sep 2021 10:55:01 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 26ABC3A204C for ; Sat, 11 Sep 2021 10:55:01 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id a22so6556018iok.12 for ; Sat, 11 Sep 2021 10:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8PjG/CjpJ3Xu0Zt7jCbkSyByOzo9rhK8pfaWWaDTvFo=; b=K3WupMPK1cNSE/6twTCtXV70w8uefQ9ZImjs5ZfO+Fp/mRwv2WN/DCbwK3eX/sDBVV sDzDTIlBs93UY/RSa5KHu296xM+1NVSjvg8I49t2gwkEMuBoNjpT28v2ZfyusC1NBDNm e6BSppjAgx7PIWlW2HV3FpogLbruLXy4lHKi0/sLcbiXIUcWEGsL+EPh8a8xmZ8vZayI kOWD27odSm9vluTZWkbLHrqHW1N+bWX5FbgbvXfKsq0vlN8R53TxITD8mA0eiqFmARpH GwDA7RXN8k8UoLMmtCRMmzv4+48a1t985/l/Yu0lyampfpD0BJPdmmkS41ETv0tl35sw we+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8PjG/CjpJ3Xu0Zt7jCbkSyByOzo9rhK8pfaWWaDTvFo=; b=T+CnB6NTZBREpmPltc3olCV7o8XmCWoQj+r9yVlm3zVqVf4G2Gg9pxptqbB24gTvT7 2f6g7AKKeAswDQE6gotuzBz4RWmh/wva3pyGScOAsVHh+wDWjhoZ8/0FmYlM3eT2FI1S ZzlrrAANymXfys5RBvr+eFnHDkXMiiByk5ckuICpz14djQUM6ZZlFJKvZLosDBKzF6Ot JpwiFLuTCnxjJAI0TKLpJeSEDUAXrL8t8Olx3IJ8g+obguQCbvxDg59OI2WBJgR+C/8b vqoGg8ciqVBxk9BBsTxDrpiJNuwIeRoAKp7ynouEluWLdVBXY2Vy9NsWTX/XoEj3jYtx JZLg== X-Gm-Message-State: AOAM531rcp+f9qFWPGOQ3vqIABHZgw0nGHzXMIzzwTKswtByb5OfD5pd gIGG0tAwbMtC3FV/tv24h/u0gLfmoLGbxdrpvECt0oqjCz4= X-Google-Smtp-Source: ABdhPJxKGu0aQk2aZg2HF2nmAri2pk62I1EDp1bO8hl9uzzHO4VsuORQAOYMp7tfEZ11rMznLao+TKrR5o9Q1/sFc1U= X-Received: by 2002:a05:6602:2ac7:: with SMTP id m7mr2696293iov.66.1631382899270; Sat, 11 Sep 2021 10:54:59 -0700 (PDT) MIME-Version: 1.0 References: <20210910185930.8223627ACE21@ary.qy> In-Reply-To: <20210910185930.8223627ACE21@ary.qy> From: Wei Chuang Date: Sat, 11 Sep 2021 10:54:44 -0700 Message-ID: To: John Levine Cc: arc@ietf.org Content-Type: multipart/alternative; boundary="00000000000034bc2e05cbbbeecb" Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2021 17:55:07 -0000 --00000000000034bc2e05cbbbeecb Content-Type: text/plain; charset="UTF-8" On Fri, Sep 10, 2021 at 11:59 AM John Levine wrote: > It appears that Wei Chuang said: > >This example works by establishing a path from the FROM sender domain to > >the destination in order to show the intent for each sender to go along > >this path to be trusted by the destination. ... > > I proposed a somewhat similar idea for DKIM in 2015 which was rather > thoroughly rejected in favor of ARC. > > https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ I agree this path building concept in your draft is the same as what's being proposed in the OP, and agree with the intent of your draft. Both are trying to use signed header signatures that form a path to protect against replay attacks. There are differences too and they are: The OP proposal builds upon ARC. The advantage of doing that is there is some infrastructure already deployed which makes a small modification easier to deploy at some later time. The ARC set provides a convenient way of defining a node in a path and the ARC header sealing is likely more tolerant of changes in the message. That said, your draft's notion of "weak" (or rather further specialization of) signatures for headers likely provides greater security. I think we should revisit both approaches or some hybrid with respect to making further progress with mail authentication that's tolerant of forwarder modifications. > Figuring out all of the downstream forwarders for which a sender needs > to set an intent tag is no easier than a receiver figuring out the upstream > forwarders with credible ARC chains. > Agreed figuring out the full path from the originators point of view is impossible. But each hop knows the next destination(s), and the path can be built and identified via headers incrementally. And from the perspective of applying DMARC policy, I argue that it's sufficient to see that the originator intended to send the message down that particular path (assuming that the path signatures are valid). Of course some intermediary might be malicious and so the receiver still must do spam filtering. -Wei > R's, > John > --00000000000034bc2e05cbbbeecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Sep 10, 2021 at 11:59 AM John= Levine <johnl@taugh.com> wrot= e:
It appears th= at Wei Chuang=C2=A0 <weihaw@google.com> said:
>This example works by establishing a path from the FROM sender domain t= o
>the destination in order to show the intent for each sender to go along=
>this path to be trusted by the destination. ...

I proposed a somewhat similar idea for DKIM in 2015 which was rather
thoroughly rejected in favor of ARC.

https://datatracker.ietf.org/doc/draf= t-levine-dkim-conditional/

I agree this= path building concept in your draft is the same as what's being propos= ed in the OP, and agree with=C2=A0the=C2=A0intent of your draft.=C2=A0 Both= are trying to use signed header signatures that form a path to protect aga= inst replay attacks.=C2=A0 There are=C2=A0differences too and they are: The= OP proposal builds upon ARC.=C2=A0 The advantage of doing that=C2=A0is the= re is some infrastructure already deployed which makes a small modification= easier to deploy at some later time.=C2=A0 The ARC set provides a convenie= nt way of defining a node in a path and the ARC header sealing is likely mo= re tolerant of changes in the message.=C2=A0 That said, your draft's no= tion of "weak" (or rather further specialization of) signatures f= or headers likely provides greater security.=C2=A0

I think we should revisit both approaches or some hybrid with respect to m= aking further progress with mail authentication that's tolerant of forw= arder modifications.
=C2=A0
Figuring out all of the downstream forwarders for which a sender needs
to set an intent tag is no easier than a receiver figuring out the upstream=
forwarders with credible ARC chains.

Ag= reed figuring out the full path from the originators point of view is impos= sible.=C2=A0 But each hop knows the next destination(s), and the path can b= e built=C2=A0and identified via headers incrementally.=C2=A0 And from the p= erspective of applying DMARC policy, I argue that it's sufficient to se= e that the originator intended to send the message down that particular pat= h (assuming that the path signatures are valid).=C2=A0 Of course some inter= mediary might be malicious and so the receiver still must do spam filtering= .=C2=A0=C2=A0

-Wei
=C2=A0
R's,
John
--00000000000034bc2e05cbbbeecb-- From nobody Sat Sep 11 12:11:01 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687753A2267 for ; Sat, 11 Sep 2021 12:10:58 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=H1OO2WT+; dkim=pass (2048-bit key) header.d=taugh.com header.b=Mtldi1x0 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 zfF5JN2SQn_u for ; Sat, 11 Sep 2021 12:10:53 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0002E3A2265 for ; Sat, 11 Sep 2021 12:10:52 -0700 (PDT) Received: (qmail 17435 invoked from network); 11 Sep 2021 19:10:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=4418.613cff38.k2109; bh=A69PKoOxygYglF1VcFFjp6EA8zqck34XH67SpSwWLV8=; b=H1OO2WT+RDLVlmW59yj9GxK252dqxYNMioE0tXXiVo4pVahIKg3Ybvzui4eKMiE5z5bEa3rOUpPr9dk0WL0LV6fGXoFJkv5R7Q14oK8HdzN290G4Dr98IA8GDNLMk3Y2m6qXz0pbRwhcYkRjsWd4TM2ov34vZb271SYFBsOrOmFhpHSXbxcJGsF/u2z/1BOCQnkoCF//opa0evO14p7COJOCsv8zOdK9g8hyRnJ28vml8FUhzGQVzzdM4Wwwb5JqGfrQAWs3GLppwob/dIrLeg2+Xw22djb9ex0daX+ceGymVITIiQqoV6ylFQVH005Sq9yxwvpfqWM38iEurLiDEw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=4418.613cff38.k2109; bh=A69PKoOxygYglF1VcFFjp6EA8zqck34XH67SpSwWLV8=; b=Mtldi1x0pe4LA9Rf5j7SqThO7yE2gbKzm4eacrcIF3lPfID2lR2IpANVXV5znwnbWkXCSucnOHxjfexISAyys7Nk7KZpfH40cI4diC9SKy/nu8lmYQ2RhIWM1BzQub8tcYuXXdD4KB4XQa/ZSmU8w+piZlhq/TFTYtn203KhHt9J6sxq4YtagjSTKSxJJ3BqXAGyx4rSDbyRqNktX9cMimcYTaOYvI+ke8jR8dEjhx2VccqEfVXrkDz637BqDcL5edoKd0wGij+aR/K8qauqkVJ1E21p/7t4qk/AtiAxhLA9vaj9nvoOzrN0Fs7uiuX4u0JP+Kp5AfCUau47uAa9fQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 11 Sep 2021 19:10:48 -0000 Received: by ary.qy (Postfix, from userid 501) id D1AA727B7BCB; Sat, 11 Sep 2021 15:10:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 3293B27B7BAD; Sat, 11 Sep 2021 15:10:47 -0400 (EDT) Date: 11 Sep 2021 15:10:47 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" Cc: arc@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210910185930.8223627ACE21@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2021 19:10:59 -0000 >> Figuring out all of the downstream forwarders for which a sender needs >> to set an intent tag is no easier than a receiver figuring out the upstream >> forwarders with credible ARC chains. > > Agreed figuring out the full path from the originators point of view is > impossible. But each hop knows the next destination(s), and the path can > be built and identified via headers incrementally. Sure, give or take grouping by MX since MX lookups can happen fairly late in the process. But the problem is that every one of these approaches depends on an external table saying when to use it. For your approach and mine, each sending system needs a list of recipient systems that are likely to edit and forward mail, and also what signature it'll apply if it's not the same as the recipient address. I suppose you could add it to every outgoing message using the recipient address domain but I think you'd still have a fair number of cases where the signature from the forwarder is different. For ARC as it stands now, each receiving system needs to keep a list of what I call credible forwarders, systems well enough behaved that you can believe their ARC chains. At least on a small system like mine, you follow the ARC chain and if you find one with a better DMARC result, you use it. My point is that compiling any of these lists wlll be roughly the same amount of work, and the credible forwarders have the advantage of working with ARC as currently implemented. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Sep 12 09:27:26 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7783A1200 for ; Sun, 12 Sep 2021 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IaabwBT4au7f for ; Sun, 12 Sep 2021 09:27:18 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 89FB33A11FE for ; Sun, 12 Sep 2021 09:27:18 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id n24so8930855ion.10 for ; Sun, 12 Sep 2021 09:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LtzmypiRl7qj4BAhYVOYafUvtwquBdTZ5+hYDmQScHE=; b=oDIHNKXKAWl6nw0U89nP8bOa1MLxtrm2LMBmiP5F1IbNm9MXoYvNqP7XKBCtcSTFfk gVXUupnT9IoW/MpUpzdAcVgNiSWwCBYn+RG8bL+I6m3O1oejTqnjI3Cczk+xh7JhK9ai y/Ivm7TefhzIcYRHhBb/2zQaALZEytb5Dzc/WWo0hal8wCKQqj0/Zf30FcvzX9O/0pqK vj+2ad+ie/LtfXx+114kGuxQw1VVICFSrBHnlUJlP9P8j7FlWYKfwrm5WT7hhyU0SJuM +2ZKwN5U7/A0C30JR6KoVeMcTWofxHLEd8HnLbVawPskZWxXhABzuXrqJDje1s/6Ih87 br0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LtzmypiRl7qj4BAhYVOYafUvtwquBdTZ5+hYDmQScHE=; b=M4Ty7jefvCCHZv8PnfEZqQ6ltNx8ZjwkmH7no2FB/hGsway9TniAZ2/IXuUya4Vn06 BpXKtEHtgFPcjyu9UaC7hRvdbPdpZ+db8Cwkuo5ICw0q2jj8n3TaRRVbEBp9DP+VdbC0 cUPkk0iUFpCtbJnrJYfAfTqtIPPcJt5UtE0KBGHgZrHQMJJpEGtVRwIbI4LrdXrnSytN c29oCprq2VRQakftKEOBXinCqOAxFmPN/TqxwEKahErKQ3r8q44wmKvCBv9LHk9FKlrn vAeUjvaKH/q7fKKtr2kx2Xnrc4jlzSZMjkzvVkevwD/yxrQDcPbZ/hHsAYbgmZKqbDLU qgBw== X-Gm-Message-State: AOAM531MnahP3tAVjPCsKLGIfsqhN61kTgNJVa5i2GdtjjbP9tvysUdc uAsSZcKGDeiNarobIpHXv7IRbso/RX2RCpMR5RAYXq6B0jAyvg== X-Google-Smtp-Source: ABdhPJydDFFVI1L0kxdBf/OCeeUPHPor3AwzLmbDi+N8ooHVOrjFrVz5mLN/cy+72XuXJEH3Konaww8PoZqMUdWWXAE= X-Received: by 2002:a05:6638:103b:: with SMTP id n27mr5940508jan.48.1631464036399; Sun, 12 Sep 2021 09:27:16 -0700 (PDT) MIME-Version: 1.0 References: <20210910185930.8223627ACE21@ary.qy> In-Reply-To: From: Wei Chuang Date: Sun, 12 Sep 2021 09:27:01 -0700 Message-ID: To: John R Levine Cc: arc@ietf.org Content-Type: multipart/alternative; boundary="0000000000005ae3c705cbced2ca" Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 16:27:25 -0000 --0000000000005ae3c705cbced2ca Content-Type: text/plain; charset="UTF-8" On Sat, Sep 11, 2021 at 12:10 PM John R Levine wrote: > >> Figuring out all of the downstream forwarders for which a sender needs > >> to set an intent tag is no easier than a receiver figuring out the > upstream > >> forwarders with credible ARC chains. > > > > Agreed figuring out the full path from the originators point of view is > > impossible. But each hop knows the next destination(s), and the path can > > be built and identified via headers incrementally. > > Sure, give or take grouping by MX since MX lookups can happen fairly late > in the process. But the problem is that every one of these approaches > depends on an external table saying when to use it. > > For your approach and mine, each sending system needs a list of recipient > systems that are likely to edit and forward mail, and also what signature > it'll apply if it's not the same as the recipient address. I suppose you > could add it to every outgoing message using the recipient address domain > but I think you'd still have a fair number of cases where the signature > from the forwarder is different. > I am probably missing something here. Why is this list of trusted recipients a prerequisite? I propose that this path based authentication can help discover these intermediary domains at scale that otherwise might be rejected due to DMARC. That process starts without any trust on these intermediaries but over time can build reputation/history. In the meanwhile it depends much more on spam filtering. With sufficient reputation/history these domains might be promoted to being trusted so that they might be used as ARC intermediaries when the path authentication doesn't form a full chain. I also propose that the path can be used for domain authentication even without that trust prerequisite. Another way to look at this is via threat modeling. (And please correct me where I am mistaken, as I've only recently looked into this.) With ARC, we have to trust that intermediary to provide a valid authentication result meaning a malicious domain could forge the authentication result as coming from some victim originator as well as the headers for it. They could then correctly seal the AAR, etc that could wrongly cause a DMARC policy pass. So for ARC, having a trustworthy intermediary domain is important, hence the need for a trusted list of intermediaries/credible forwarders ahead of send time. Path based authentication establishes that a message travelled from the originating FROM domain to the receiver. Malicious senders outside of the path wouldn't be able to inject a message pretending to be that FROM originator sending a message along that path. And from my granted limited understanding of what domain authentication is trying to do in general, it is trying to protect against those types of spoofed originator attack. It takes what once was a trivial attack, and makes it harder. Path authentication is vulnerable to some malicious intermediary on the path, but that is a higher bar now. Path authentication also says nothing about valid content, and consequently it still must depend on spam filtering (but so does any other domain authentication technique. And also there needs to be more on header signing that your proposal speaks to). . -Wei > For ARC as it stands now, each receiving system needs to keep a list of > what I call credible forwarders, systems well enough behaved that you can > believe their ARC chains. At least on a small system like mine, you > follow the ARC chain and if you find one with a better DMARC result, you > use it. > > My point is that compiling any of these lists wlll be roughly the same > amount of work, and the credible forwarders have the advantage of working > with ARC as currently implemented. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --0000000000005ae3c705cbced2ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Sep 11, 2021 at 12:10 PM John= R Levine <johnl@taugh.com> wr= ote:
>> Fi= guring out all of the downstream forwarders for which a sender needs
>> to set an intent tag is no easier than a receiver figuring out the= upstream
>> forwarders with credible ARC chains.
>
> Agreed figuring out the full path from the originators point of view i= s
> impossible.=C2=A0 But each hop knows the next destination(s), and the = path can
> be built and identified via headers incrementally.

Sure, give or take grouping by MX since MX lookups can happen fairly late <= br> in the process.=C2=A0 But the problem is that every one of these approaches=
depends on an external table saying when to use it.

For your approach and mine, each sending system needs a list of recipient <= br> systems that are likely to edit and forward mail, and also what signature <= br> it'll apply if it's not the same as the recipient address.=C2=A0 I = suppose you
could add it to every outgoing message using the recipient address domain <= br> but I think you'd still have a fair number of cases where the signature=
from the forwarder is different.

I am p= robably missing something here.=C2=A0 Why is this list of trusted recipient= s a prerequisite?=C2=A0 I propose that this path based authentication can h= elp discover these intermediary domains at scale that otherwise might be re= jected due to DMARC.=C2=A0 That process starts without any trust on these i= ntermediaries but over time can build reputation/history.=C2=A0 In the mean= while it depends much more on spam filtering.=C2=A0 With sufficient reputat= ion/history these domains might be promoted to being trusted so that they m= ight be used as ARC intermediaries when the path authentication doesn't= form a full chain.=C2=A0 I also propose that the path can be used for doma= in authentication even without that trust prerequisite.=C2=A0=C2=A0

Another way to look at this is via threat modeling.=C2=A0= (And please correct me where I am mistaken, as I've only recently look= ed into this.)=C2=A0 With ARC,=C2=A0 we have to trust that intermediary to = provide a valid authentication result meaning a malicious domain could forg= e the authentication result as coming from some victim originator as well a= s the headers for it.=C2=A0 They could then correctly seal the AAR, etc tha= t could wrongly cause a DMARC policy pass.=C2=A0 So for ARC, having a trust= worthy intermediary domain is important,=C2=A0hence the need for a trusted= =C2=A0list of intermediaries/credible forwarders ahead of send time.=C2=A0= =C2=A0

Path based authentication establishes that = a message travelled from the originating FROM domain to the receiver.=C2=A0= Malicious senders outside of the path wouldn't be able to inject a mes= sage pretending to be that FROM originator sending a=C2=A0 message along th= at path.=C2=A0 And from my granted limited understanding of what domain aut= hentication is trying to do in general, it is trying to protect against tho= se types of spoofed originator=C2=A0attack.=C2=A0 It takes what once was a = trivial=C2=A0attack, and makes it harder.=C2=A0 Path authentication is vuln= erable to some malicious intermediary on the path, but that is a higher bar= now.=C2=A0 Path authentication also says nothing about valid=C2=A0content,= and consequently it still must depend on spam filtering (but so does any o= ther domain authentication technique.=C2=A0 And also there needs to be more= on header signing that your proposal speaks to). .=C2=A0=C2=A0
<= br>
-Wei
=C2=A0
For ARC as it stands now, each receiving system needs to keep a list of what I call credible forwarders, systems well enough behaved that you can <= br> believe their ARC chains.=C2=A0 At least on a small system like mine, you <= br> follow the ARC chain and if you find one with a better DMARC result, you use it.

My point is that compiling any of these lists wlll be roughly the same
amount of work, and the credible forwarders have the advantage of working <= br> with ARC as currently implemented.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
--0000000000005ae3c705cbced2ca-- From nobody Sun Sep 12 10:48:17 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A63A3A1538 for ; Sun, 12 Sep 2021 10:48:14 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=NPmp60P+; dkim=pass (2048-bit key) header.d=taugh.com header.b=K8BLaQvZ 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 rEURdXFznnAy for ; Sun, 12 Sep 2021 10:48:08 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 522DB3A1537 for ; Sun, 12 Sep 2021 10:48:08 -0700 (PDT) Received: (qmail 32461 invoked from network); 12 Sep 2021 17:48:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7ecb.613e3d56.k2109; bh=XKPx6beRgp87QWloFDbuWtkuDPVlZ54DDl6t1SFlspQ=; b=NPmp60P+mwS3Sd+87/6Oc4FMCpmErIaNI1ugPw11hp9joy5RGYdPFrN70a5KYVyz3OV9ZUjMW09qEYt7QoAsAaXans2mTD56g3aHPhanEG9vF02Yd802SFqBzv0OnJSA8s3Ln7tYxIBljl2rvnqH19bJKz7LH8mxcTD6i2vTFTumHNUlmCpy85qqD2igOetsRfV9W4ZqYSCV5fTNR//Gv12jdKZun5evGWI13okHgmbF+TGW1v+pY062myaA4RJe8evjc9vjARioHmL916hRhQE8CZFPwWVuXBwHXqt33s0jtQYWKLHz6lLJpH/ZDY1izK7K3xJqaonUuPLNMW6SQg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7ecb.613e3d56.k2109; bh=XKPx6beRgp87QWloFDbuWtkuDPVlZ54DDl6t1SFlspQ=; b=K8BLaQvZ/ZSulzHPqReR1geVshoW9eSgtU4Y2fG6GNoqkRmQ0YmL4OcQ8CORyIhbNjYyRiU9bvyYqqMSxkuXcFDUoaAtzn1J5K7RyDhWfiu/o//RsqGIeyzVVaisGkMAQlr+VObvvA3btCQC1HM7Oz1z2/gSygV84z0gaSjPrZguQ2mGG7A8Ds2cr9jTepOMUsEfCFsp9E8CH/zTAtfFijilw+6l4rgdi+ZXwMcxkZV7ZlLCl4sH5qRd3vVU+pRG8dc8sAbhUQT+o7uhHCGzcMIW211mprUQCDLx4YERp79ynZhzaTYZTKBJMXAgwkACi+jzNFS6eIuIBbggjb70gA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 12 Sep 2021 17:48:05 -0000 Received: by ary.qy (Postfix, from userid 501) id BB7E527C37B9; Sun, 12 Sep 2021 13:48:04 -0400 (EDT) Date: 12 Sep 2021 13:48:04 -0400 Message-Id: <20210912174804.BB7E527C37B9@ary.qy> From: "John Levine" To: arc@ietf.org Cc: weihaw@google.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 17:48:14 -0000 It appears that Wei Chuang said: >> For your approach and mine, each sending system needs a list of recipient >> systems that are likely to edit and forward mail, and also what signature >> it'll apply if it's not the same as the recipient address. I suppose you >> could add it to every outgoing message using the recipient address domain >> but I think you'd still have a fair number of cases where the signature >> from the forwarder is different. > >I am probably missing something here. Why is this list of trusted >recipients a prerequisite? It's not, I suppose you could put a forwarding path on everything, without trying to guess who's likely to forward. I do worry about replay attacks: find a forwarded message somewhere, splice the original headers onto a malicious body, and send it to the same mailing list as the original. You can't tie the forwarding token to a body checksum, since mailing lists change the body and aren't likely to stop doing so. In any event, I know the ARC group was aware of my DKIM proposal and decided to do it the way they did. Dave Crocker or Brandon Long might have some insights into why. R's, John From nobody Sun Sep 12 23:39:29 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D863A0822 for ; Sun, 12 Sep 2021 23:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=SwMBYkGu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Peo2VQLV 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 g_poxEQN4QYT for ; Sun, 12 Sep 2021 23:39:21 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A1C3A07A9 for ; Sun, 12 Sep 2021 23:39:20 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C898A5C00E0 for ; Mon, 13 Sep 2021 02:39:16 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute2.internal (MEProxy); Mon, 13 Sep 2021 02:39:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=hRZsCpN af/IOff+2cv9Tg4ANjupE/rfl4UjvDhnNbdU=; b=SwMBYkGu3VAyNIjYYjV3VBj zwj3dzv/Se/YKvDzXbjy5nHG/51k6S1Uh9nzYVoS1u13qHIWPoYnqa+tjMqhhUgm soQiIN7BhEyzAa2zUb7qpskPGjOWNY5XH0SdctvebgWm2HA38Je4fYIdd3qxeWmN 6zas5RvaXY5yx3cJupL4fva9ZFltSjSU5vXeXy2fVY2sCQQqrMLLFDd17eYhSKAH d+G9rAB5gFDETqmOClz9TYwtZMvjFE+FF8H3zUiVU3kdq1TTfcy76Mgrazcxd0/+ NnOfxuyiWqir71gLLxDE1wAtvlLsBAGLqAz2L/zpeM2N0+mLVXX5MxsZGvtp2rQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=hRZsCp Naf/IOff+2cv9Tg4ANjupE/rfl4UjvDhnNbdU=; b=Peo2VQLVq046L49mIt/sSC HOPblwM/V9J7j2Xn0t1gFOYI8j3GZEIYZY1TS3AUoats7Qsi0iJU3jeLs9I7WCo2 3cFI+COI9ZmjsbgvOeifFjdIuyZEbmqK4YLs4XPF7pYwIVPrkPreNXiJ9Ak5M1r4 KVLvOG+ofe/s/s+L/qmajtCweujDSNCASz13G8T018kVha4ue5ZRpQJl6BYQVl74 nIB3E7ZJ+/6UKoIu/sKBauZI8tHgzG5Ni7CzWhIlIdqxfuLDWox5wshnO+exuHXO xondDZa885CAbjfqx/N9MXu69GdYw7j3juitiTvvwIV0Jvnx/5RfYqHni6qnb1pQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegiedguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfofgr rhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnhgvth eqnecuggftrfgrthhtvghrnhepuddvteffheduteefjeelvdefveelleekheehveevvdel udelleeuhfevgeelkedvnecuffhomhgrihhnpehgmhgrihhlrdgtohhmpdhgohhoghhlvg hgrhhouhhpshdrtghomhdpohhuthhlohhokhdrtghomhdpvgigrghmphhlvgdrtghomhdp ihgvthhfrdhorhhgpdhmrghrtggsrhgrughshhgrfidrnhgvthdpthifihhtthgvrhdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm rghrtgesmhgrrhgtsghrrggushhhrgifrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 686AE1EE006E; Mon, 13 Sep 2021 02:39:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1229-g7ca81dfce5-fm-20210908.005-g7ca81dfc Mime-Version: 1.0 Message-Id: In-Reply-To: <20210912174804.BB7E527C37B9@ary.qy> References: <20210912174804.BB7E527C37B9@ary.qy> Date: Mon, 13 Sep 2021 16:38:55 +1000 From: "Marc Bradshaw" To: arc@ietf.org Content-Type: multipart/alternative; boundary=4f2bd7467e934c82a7a464a2c881b587 Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 06:39:27 -0000 --4f2bd7467e934c82a7a464a2c881b587 Content-Type: text/plain As I have understood this proposal there still needs to be a method of evaluating the trustworthyness of the intermediaries. It differs fromn the status quo in moving that responsibility from the receiver onto the originator and each hop. It's one thing for a sender (or intermediary) to know where it is sending a message to, but quiet anther to make any determination of the trustworthyness of that arc sealer. I may know that I'm sending a message on to foo.com, and may know they are a forwarder or mailing list, but once that hop changes a message there still needs to be established trust that those modifications are reasonable. That is the major hurdle for ARC and I don't think that this proposal helps. For example, to expand on your earlier mailflow. > 1) Origination > > From: someuser@*gmail.com* > > To: example-group@googlegroups.com > > Arc++-path: i=0; s=*gmail.com* ; d=googlegroups.com; > > Arc++-Seal: i=0; a=rsa-sha256; *t=1628539507*; cv=pass; > > d=*gmail.com*; s=arc-20160816; b=ABCD...Z > > 2) Mailing list > > From: someuser@gmail.com > > To: example-group@googlegroups.com > > Arc-Authentication-Results: i=1; arc++=pass (....) > > Arc-Seal: i=1; a=rsa-sha256; *t=1628539508*; cv=pass; > > d=*googlegroups.com*; s=arc-20160816; b=ABCD...Z > > Arc++-path: i=1; s=googlegroups.com ; d=outlook.com; > > Arc++-path: i=0; s=gmail.com ; d=*googlegroups.com*; > > Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass; > > d=gmail.com; s=arc-20160816; b=ABCD...Z > > 2) Recipient > > From: someuser@gmail.com > > To: example-group@googlegroups.com > > Arc-Authentication-Results: i=2; arc++=pass (....) > > Arc-Seal: i=2; a=rsa-sha256; *t=1628539509*; cv=pass; > > d=*outlook.com*; s=arc-20160816; b=ABCD...Z > > Arc-Authentication-Results: i=1; arc++=pass (....) > > Arc++-path: i=1; s=googlegroups.com ; d=*outlook.com*; > > Arc-Seal: i=1; a=rsa-sha256; t=1628539507; cv=pass; > > d=googlegroups.com; s=arc-20160816; b=ABCD...Z > > Arc++-path: i=0; s=gmail.com ; d=googlegroups.com; > > Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass; > > d=gmail.com; s=arc-20160816; b=ABCD...Z > If eviluser@gmail.com was a member of the example-group, and had a forward setup to evilforwarder.example.com, would we see an arc set with s=gmail.com d=evilforwarder.example.com set by google groups. evilforwarder.example.com could then replace the message body entirely, reseal the message and pass it on to a recipient with intact ARC headers. If the proposal is that the ARC seal includes the recipient domain regardless of a determination that that domain is somehow trusted then I (as a receiver) can't trust any of this. Either the sender and every intermediary needs to maintain a list of trusted forwarders it may send to, or each ARC processor needs to maintain a list of trusted forwarders it may receive mail from. On Mon, 13 Sep 2021, at 3:48 AM, John Levine via Arc wrote: > It appears that Wei Chuang said: > >> For your approach and mine, each sending system needs a list of recipient > >> systems that are likely to edit and forward mail, and also what signature > >> it'll apply if it's not the same as the recipient address. I suppose you > >> could add it to every outgoing message using the recipient address domain > >> but I think you'd still have a fair number of cases where the signature > >> from the forwarder is different. > > > >I am probably missing something here. Why is this list of trusted > >recipients a prerequisite? > > It's not, I suppose you could put a forwarding path on everything, > without trying to guess who's likely to forward. I do worry about > replay attacks: find a forwarded message somewhere, splice the > original headers onto a malicious body, and send it to the same > mailing list as the original. You can't tie the forwarding token to a > body checksum, since mailing lists change the body and aren't likely > to stop doing so. > > In any event, I know the ARC group was aware of my DKIM proposal and > decided to do it the way they did. Dave Crocker or Brandon Long might > have some insights into why. > > R's, > John > > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --4f2bd7467e934c82a7a464a2c881b587 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As I have under= stood this proposal there still needs to be a method of evaluating the t= rustworthyness of the intermediaries. It differs fromn the status quo in= moving that responsibility from the receiver onto the originator and ea= ch hop.
It's one thing for a sender (or intermediary) to k= now where it is sending a message to, but quiet anther to make any deter= mination of the trustworthyness of that arc sealer.

I may know that I'm sending a message on to foo.com, and may kn= ow they are a forwarder or mailing list, but once that hop changes a mes= sage there still needs to be established trust that those modifications = are reasonable. That is the major hurdle for ARC and I don't think that = this proposal helps.

For example, to expand= on your earlier mailflow.

1) Origination

From: someuser@gmail.com

To: example-group@googlegroups.com

Arc++-path: i=3D0; s=3D<= /span>gmail.com<= span style=3D"color:rgb(0, 0, 0);background-color:transparent;font-varia= nt-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline= ;white-space:pre-wrap;"> ; d=3Dgooglegroups.com;=

Arc++-Seal: i=3D0; a=3Drsa-sha256;= t=3D1628539507; cv=3Dpass;

<= span style=3D"color:rgb(0, 0, 0);font-variant-numeric:normal;font-varian= t-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;"> &nb= sp;      d=3Dgmail.com; s=3Darc-20160816; b=3DABCD...Z

2) Mailing list

Fr= om: someuser@gmail.com

To: example-group@googlegroups.com

Arc-Authentication-Results: i=3D1; arc++=3Dpass (....= )

Arc-Seal: i=3D1; a=3D= rsa-sha256; t=3D1628539508; cv=3Dpass;<= br>

= googlegroups.com; s=3Darc-20160816; b=3DABCD...Z

Arc++-path: i=3D1; s=3Dgoo= glegroups.com ; d=3Doutlook.com;

Arc++-path: i=3D0; s=3Dgmail.com ; d=3D= googlegroups.com<= /span>;

Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D1628539507; cv=3Dpass;

        d=3Dgmai= l.com; s=3Darc-20160816; b=3DABCD...Z

2) Recipient

Fr= om: someuser@gmail.com

To: example-group@googlegroups.com

Arc-Authentication-Results: i=3D2; arc++=3Dpass (....= )

Arc-Seal: i=3D2; a=3D= rsa-sha256; t=3D1628539509; cv=3Dpass;<= br>

outlo= ok.com; s=3Darc-20160816; b=3DABCD...Z

Arc= -Authentication-Results: i=3D1; arc++=3Dpass (....)

Arc++-path: i=3D1; s=3Dgooglegroups.c= om ; d=3Doutlook.com<= /span>;

Arc-Seal: i=3D1; a=3Drsa-sha256; t=3D1628539507; cv=3D= pass;

        d=3D= googlegroups.com; s=3Darc-20160816; b=3DABCD...Z

Arc++-path: i=3D0; s=3Dgmail.com ; d=3Dgooglegroups.com;

Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D1628539507; c= v=3Dpass;

       &nbs= p;d=3Dgmail.com; s=3Darc-20160816; b=3DABCD...Z
=


If eviluser@gmai= l.com was a member of the example-group, and had a forward setup to evil= forwarder.example.com, would we see an arc set with s=3Dgmail.com d=3Dev= ilforwarder.example.com set by google groups.
evilforwarde= r.example.com could then replace the message body entirely, reseal the m= essage and pass it on to a recipient with intact ARC headers.
<= div>If the proposal is that the ARC seal includes the recipient domain r= egardless of a determination that that domain is somehow trusted then I = (as a receiver) can't trust any of this.

Ei= ther the sender and every intermediary needs to maintain a list of trust= ed forwarders it may send to, or each ARC processor needs to maintain a = list of trusted forwarders it may receive mail from.

<= /div>

On Mon, 13 Sep 2021, at 3:48 AM, John Levine vi= a Arc wrote:
It appears that Wei Chuang  <weihaw@google.com> said:
>> For your appr= oach and mine, each sending system needs a list of recipient
>> systems that are likely to edit and forward mail, and also w= hat signature
>> it'll apply if it's not the same as= the recipient address.  I suppose you
>> could= add it to every outgoing message using the recipient address domain
=
>> but I think you'd still have a fair number of cases = where the signature
>> from the forwarder is differe= nt.
>
>I am probably missing something= here.  Why is this list of trusted
>recipients a = prerequisite?

It's not, I suppose you could= put a forwarding path on everything,
without trying to gu= ess who's likely to forward. I do worry about
replay attac= ks: find a forwarded message somewhere, splice the
origina= l headers onto a malicious body, and send it to the same
m= ailing list as the original. You can't tie the forwarding token to a
=
body checksum, since mailing lists change the body and aren't= likely
to stop doing so.

In = any event, I know the ARC group was aware of my DKIM proposal and
decided to do it the way they did. Dave Crocker or Brandon Long = might
have some insights into why.

R's,
John


--
<= div>

  Marc Bradshaw
  marcbradshaw.net= | @marcbradshaw
<= br>

--4f2bd7467e934c82a7a464a2c881b587-- From nobody Mon Sep 13 09:21:35 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73A43A07F0 for ; Mon, 13 Sep 2021 09:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.087 X-Spam-Level: X-Spam-Status: No, score=-18.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QDdagI9H4kZB for ; Mon, 13 Sep 2021 09:21:18 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 A44E83A07F6 for ; Mon, 13 Sep 2021 09:21:18 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id z1so12846046ioh.7 for ; Mon, 13 Sep 2021 09:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=itumnTyG+ArujO/7yYijzKr2qpDj/Ctjh629bgUMZWw=; b=P8xtBFowAsrvQIbNErHiYWhAz5xr6aN2L5S5KaS0QbIFqXg4TJS1OdyFV5SSJ5YdDQ NVWSS80nimWJFv7cc2W9n3qiODrW/Bfq9uayVYef7MQxTRsTaltUGK4EuXcfLCbuwKi3 FHknnvKO1trjIpGM4Jt3TFfKa44Od7db5r/PXYG3Ez0lPET3H1LjnL/+pFL0YDjhRzt/ VIwBnaUuV5izhkMTXtewrDWwLfHsIr0fUePh7Z8IxDCrP8xGKQAcqJ0z9ZWSgNU+/HEJ GyPMsgXQX2QSDbzt6UlJerOj/r9ifYH+hwJh5QmdfdtakymXHY0NFznnmz+DZm/NokQW kJQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=itumnTyG+ArujO/7yYijzKr2qpDj/Ctjh629bgUMZWw=; b=ezcRirr2BpQ/KQgKzlDG/uYH8NVQlHWWCmZbMrBSUHHiexTvfOE2o7kK3egKUIl6uD g+m0GS9H7fXzVfrkVwoNWTUdhWrbMOii/mDSGk2UVqfJG6uC1q/gKljQZL/KfqBBdydX OIEXMF/u3zTwlVDolVdacbxBceTX4RKzmjrqC9FLssxQzm2B4OvbGRnHFv+MWuWixNwW 8gqduKkINL6QK3p47riF3Z6mr03RLIy+m2JWWwAesxlzjtumTZmnz0M7ladP1EyjfyOt uz88l2B7Go5/7tTZJYqs7ELwPG1vl69Gseyw0bD1CxbIb9Y4rcmiAlT4T4ILe0NifHdN LEuQ== X-Gm-Message-State: AOAM5315XQLTrO0RYCPmNfonfTo93qUhqrqqat1M2mE6pqbSNKse3BY0 RzrNcVKxCRkOmTFS4R1zrxvYXbkdtliZThFkf96UC40I2BNLkQ== X-Google-Smtp-Source: ABdhPJx7EXBOw/5RwrXE7nHl4gsNC6tQTqczhjAt3vbE2t7mjCoYF8fswgTMyXqhaM3qrvkwGzqc04/ItecvfO5kyVI= X-Received: by 2002:a05:6638:268f:: with SMTP id o15mr8788670jat.94.1631550076606; Mon, 13 Sep 2021 09:21:16 -0700 (PDT) MIME-Version: 1.0 References: <20210912174804.BB7E527C37B9@ary.qy> In-Reply-To: <20210912174804.BB7E527C37B9@ary.qy> From: Wei Chuang Date: Mon, 13 Sep 2021 09:21:02 -0700 Message-ID: To: John Levine Cc: arc@ietf.org Content-Type: multipart/alternative; boundary="000000000000c0575505cbe2da34" Archived-At: Subject: [arc] Replay attacks (was Re: ARC path header) X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 16:21:34 -0000 --000000000000c0575505cbe2da34 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 12, 2021 at 10:48 AM John Levine wrote: > It appears that Wei Chuang said: > >> For your approach and mine, each sending system needs a list of > recipient > >> systems that are likely to edit and forward mail, and also what > signature > >> it'll apply if it's not the same as the recipient address. I suppose > you > >> could add it to every outgoing message using the recipient address > domain > >> but I think you'd still have a fair number of cases where the signature > >> from the forwarder is different. > > > >I am probably missing something here. Why is this list of trusted > >recipients a prerequisite? > > It's not, I suppose you could put a forwarding path on everything, > without trying to guess who's likely to forward. I do worry about > replay attacks: find a forwarded message somewhere, splice the > original headers onto a malicious body, and send it to the same > mailing list as the original. You can't tie the forwarding token to a > body checksum, since mailing lists change the body and aren't likely > to stop doing so. > I propose checking timestamps to look for and prevent some basic replay attacks, and depends on spam filtering to handle other scenarios. Yes, you could argue for additional authentication on the message body, but such proposals to do that are much more complex that arguably would not help many mail forwarders and receivers. (IMHO There are good ideas out there for that e.g draft-kucherawy-dkim-list-canon ) Like you say because body modifications happen in legitimate mail flow by mailing lists and other forwarders, and this proposal is intentionally scoped to just solve the mailing lists with DMARC issue (as well as the other legitimate forwarders). -Wei In any event, I know the ARC group was aware of my DKIM proposal and > decided to do it the way they did. Dave Crocker or Brandon Long might > have some insights into why. > > R's, > John > --000000000000c0575505cbe2da34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Sep 12, 2021 at 10:48 AM John= Levine <johnl@taugh.com> wrot= e:
It appears th= at Wei Chuang=C2=A0 <weihaw@google.com> said:
>> For your approach and mine, each sending system needs a list of re= cipient
>> systems that are likely to edit and forward mail, and also what si= gnature
>> it'll apply if it's not the same as the recipient address.= =C2=A0 I suppose you
>> could add it to every outgoing message using the recipient address= domain
>> but I think you'd still have a fair number of cases where the = signature
>> from the forwarder is different.
>
>I am probably missing something here.=C2=A0 Why is this list of trusted=
>recipients a prerequisite?

It's not, I suppose you could put a forwarding path on everything,
without trying to guess who's likely to forward. I do worry about
replay attacks: find a forwarded message somewhere, splice the
original headers onto a malicious body, and send it to the same
mailing list as the original. You can't tie the forwarding token to a body checksum, since mailing lists change the body and aren't likely to stop doing so.

I propose checking ti= mestamps to look for and prevent some basic replay attacks, and=C2=A0depend= s on spam filtering to handle other scenarios.=C2=A0 Yes, you could argue f= or additional authentication on the message body,=C2=A0but such proposals t= o do that are much=C2=A0more complex that arguably would not help many mail= forwarders and receivers.=C2=A0 (IMHO There are good ideas out there for t= hat e.g=C2=A0draft-kucherawy-dkim-list-canon)=C2=A0 Like you say because body modifications happen in leg= itimate=C2=A0mail flow by mailing lists and other forwarders, and=C2=A0this= proposal is intentionally scoped to just solve the mailing lists with DMAR= C issue (as well as the other legitimate forwarders).=C2=A0 =C2=A0
=C2=A0
-Wei

In any event, I know the ARC group was aware of my DKIM proposal and
decided to do it the way they did. Dave Crocker or Brandon Long might
have some insights into why.

R's,
John
--000000000000c0575505cbe2da34-- From nobody Mon Sep 13 09:47:19 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7A23A0A6D for ; Mon, 13 Sep 2021 09:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.087 X-Spam-Level: X-Spam-Status: No, score=-18.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2yei1JDNg5FC for ; Mon, 13 Sep 2021 09:47:11 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0: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 8D0EA3A0A68 for ; Mon, 13 Sep 2021 09:47:11 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id h20so9863156ilj.13 for ; Mon, 13 Sep 2021 09:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=14qABcklGlPD+A3elUKMtDupuLY9UBDOoAGUDVYtdN4=; b=c6ZrFFh9gM0rqEOxZ9mKkifps45ufV1ZzMgq7eFmymyTgDaw6eVmyA8Qri3+RQaUCM 8L3aPjmYHHJOFzNzT6srpFRLIElwpP3XvJGCdI9ifz9aF4QKHhz1ZmLLOhuaIjSx0AQh fWxdHQ0h/EL/PjU9y0DAJ9BdP88/WrvwPvEd4LR9c4RehY20DNP1KWVSuXsR9ZJAaLFP nWz65Plgtma/BKvpEecBCJT/23TC4gmhT7NrPnMMijTUbnJpi1iohvdDGYo08NNt4ZSi iKewc9yH9f8ynAGCZKG5dgib6b+VNNpPeZ1uS8qlcuthWKfw8YJaVxBsDFkMt3XCLhYD wiVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=14qABcklGlPD+A3elUKMtDupuLY9UBDOoAGUDVYtdN4=; b=3bbFxtoKU+fYpj1w6RBfh2IGUr2zSOBIlEWpVegLVHjnqa06cTvihAmS0ZS3OdYBQ0 Hg9m6W+mgBbE5J1pGPzpY3rf0IyrKTW8w7utj4jkVl4iuim0WVXGPa6NHAsWksc5jcGB 67S21+Kk5rat97fi/LvXS5VBL/EcF/rhs2zo5kzAwQYJWd3P8bYkCz9Lvr+y09UeyDOn KmeCU1uaQpEPrvhDcqbOzt1s6aMwB3X4DDs5AX0hOs+XAaD5RHjsrtt6ffe40Bv6huiy 8wLBiTB00LwheofsJBJcelP/yWIDaY9uE+lcb6rzuranYW0T3SaFzXI6JtKe/GfzrO1A yGqQ== X-Gm-Message-State: AOAM5313DUC0+FG/g0M6hwODX0qNlEv4wRaNx+n38xV6fSovRHcGZgy2 TE9iDhDS55Ttg2Z7LSm34qDMIfklWFmjgfb5dK+axA== X-Google-Smtp-Source: ABdhPJyuLPDEx3Y9VEwZBzcfSGUUi9sSZgSKeixz++EY25U/bFnGNHam+df4vUD4SbNey6iyFM/9dfCgrEWuFIhx0BE= X-Received: by 2002:a92:cd8d:: with SMTP id r13mr3149001ilb.244.1631551628003; Mon, 13 Sep 2021 09:47:08 -0700 (PDT) MIME-Version: 1.0 References: <20210912174804.BB7E527C37B9@ary.qy> In-Reply-To: From: Wei Chuang Date: Mon, 13 Sep 2021 09:46:56 -0700 Message-ID: To: Marc Bradshaw Cc: arc@ietf.org Content-Type: multipart/alternative; boundary="00000000000038a46005cbe337fd" Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 16:47:18 -0000 --00000000000038a46005cbe337fd Content-Type: text/plain; charset="UTF-8" On Sun, Sep 12, 2021 at 11:39 PM Marc Bradshaw via Arc wrote: > As I have understood this proposal there still needs to be a method of > evaluating the trustworthyness of the intermediaries. It differs fromn the > status quo in moving that responsibility from the receiver onto the > originator and each hop. > It's one thing for a sender (or intermediary) to know where it is sending > a message to, but quiet anther to make any determination of the > trustworthyness of that arc sealer. > Actually it's proposing that the path authentication is sufficient for DMARC policy checks. It still asks the receivers (i.e. both the final destination as well as the intermediates) to spam filtering. In the case of intermediates determines whether to forward the message, which helps protect its reputation. All receivers ought to score the results to create some sort of domain reputation filtering that can be applied as part of the spam filtering as well as for using the ARC authentication results when a path can't be formed, and the intermediate's trustworthiness is needed to determine whether to trust the authentication result from that intermediate. > > I may know that I'm sending a message on to foo.com, and may know they > are a forwarder or mailing list, but once that hop changes a message there > still needs to be established trust that those modifications are > reasonable. That is the major hurdle for ARC and I don't think that this > proposal helps. > > For example, to expand on your earlier mailflow. > > 1) Origination > > From: someuser@*gmail.com * > > To: example-group@googlegroups.com > > Arc++-path: i=0; s=*gmail.com * ; d=googlegroups.com; > > Arc++-Seal: i=0; a=rsa-sha256; *t=1628539507*; cv=pass; > > d=*gmail.com *; s=arc-20160816; b=ABCD...Z > > 2) Mailing list > > From: someuser@gmail.com > > To: example-group@googlegroups.com > > Arc-Authentication-Results: i=1; arc++=pass (....) > > Arc-Seal: i=1; a=rsa-sha256; *t=1628539508*; cv=pass; > > d=*googlegroups.com *; s=arc-20160816; > b=ABCD...Z > > Arc++-path: i=1; s=googlegroups.com ; d=outlook.com; > > Arc++-path: i=0; s=gmail.com ; d=*googlegroups.com > *; > > Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass; > > d=gmail.com; s=arc-20160816; b=ABCD...Z > > 2) Recipient > > From: someuser@gmail.com > > To: example-group@googlegroups.com > > Arc-Authentication-Results: i=2; arc++=pass (....) > > Arc-Seal: i=2; a=rsa-sha256; *t=1628539509*; cv=pass; > > d=*outlook.com *; s=arc-20160816; b=ABCD...Z > > Arc-Authentication-Results: i=1; arc++=pass (....) > > Arc++-path: i=1; s=googlegroups.com ; d=*outlook.com * > ; > > Arc-Seal: i=1; a=rsa-sha256; t=1628539507; cv=pass; > > d=googlegroups.com; s=arc-20160816; b=ABCD...Z > > Arc++-path: i=0; s=gmail.com ; d=googlegroups.com; > > Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass; > > d=gmail.com; s=arc-20160816; b=ABCD...Z > > > If eviluser@gmail.com was a member of the example-group, and had a > forward setup to evilforwarder.example.com, would we see an arc set with > s=gmail.com d=evilforwarder.example.com set by google groups. > evilforwarder.example.com could then replace the message body entirely, > reseal the message and pass it on to a recipient with intact ARC headers. > If the proposal is that the ARC seal includes the recipient domain > regardless of a determination that that domain is somehow trusted then I > (as a receiver) can't trust any of this. > > Either the sender and every intermediary needs to maintain a list of > trusted forwarders it may send to, or each ARC processor needs to maintain > a list of trusted forwarders it may receive mail from. > This proposal is intentionally scoped to just solve the mailing lists with DMARC issue (and other legitimate forwarders modifications) As noted in the other thread, there are good ideas out there for enabling checks of the legitimacy of the body modifications (e.g draft-kucherawy-dkim-list-canon ) My worry is that those solutions are very complex and will may actually hinder adoption of any solution to resolve the immediate and broad problem of DMARC false rejection due to mailing list forwarding. -Wei > On Mon, 13 Sep 2021, at 3:48 AM, John Levine via Arc wrote: > > It appears that Wei Chuang said: > >> For your approach and mine, each sending system needs a list of > recipient > >> systems that are likely to edit and forward mail, and also what > signature > >> it'll apply if it's not the same as the recipient address. I suppose > you > >> could add it to every outgoing message using the recipient address > domain > >> but I think you'd still have a fair number of cases where the signature > >> from the forwarder is different. > > > >I am probably missing something here. Why is this list of trusted > >recipients a prerequisite? > > It's not, I suppose you could put a forwarding path on everything, > without trying to guess who's likely to forward. I do worry about > replay attacks: find a forwarded message somewhere, splice the > original headers onto a malicious body, and send it to the same > mailing list as the original. You can't tie the forwarding token to a > body checksum, since mailing lists change the body and aren't likely > to stop doing so. > > In any event, I know the ARC group was aware of my DKIM proposal and > decided to do it the way they did. Dave Crocker or Brandon Long might > have some insights into why. > > R's, > John > > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > > > -- > > Marc Bradshaw > marcbradshaw.net | @marcbradshaw > > > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > --00000000000038a46005cbe337fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= br>

On Sun, Sep 12, 2021 at 11:39 PM Marc Bradshaw via Arc <= arc@ietf.org> wrot= e:
<= div>As I have understood this proposal there still needs to be a method of = evaluating the trustworthyness of the intermediaries. It differs fromn the = status quo in moving that responsibility from the receiver onto the origina= tor and each hop.
It's one thing for a sender (or interme= diary) to know where it is sending a message to, but quiet anther to make a= ny determination of the trustworthyness of that arc sealer.
=

Actually it's proposing that the path = authentication is sufficient for DMARC policy checks.=C2=A0 It still asks t= he receivers (i.e. both the final destination as well as the intermediates)= to spam filtering.=C2=A0 In the case of intermediates=C2=A0determines whet= her to forward the message, which helps protect=C2=A0its=C2=A0reputation.= =C2=A0 All receivers ought to score the results to create some sort of doma= in reputation filtering that can be applied as part of the spam filtering a= s well as for using the ARC authentication results when a path can't be= formed, and the intermediate's trustworthiness is needed to determine = whether to trust the authentication result from that intermediate.
=C2=A0
<= /div>

I may know that I'm sending a message on to foo.com, and may know they a= re a forwarder or mailing list, but once that hop changes a message there s= till needs to be established trust that those modifications are reasonable.= That is the major hurdle for ARC and I don't think that this proposal = helps.

For example, to expand on your earlier = mailflow.

1) Origin= ation

From: someuser@gmail.com=

= To: example-group@googlegroups.com

Ar= c++-path: i=3D0; s=3Dgmail.com ; d=3Dgoog= legroups.com;

Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D1628539507; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0d=3D<= span style=3D"font-family:"Courier New"">gmail.com= ; s=3Darc-20160816; b=3DABCD.= ..Z

2) Mailing list

From: someuser@gmail.com=

To: example-group@googlegroups.com

Arc-Authentic= ation-Results: i=3D1; arc++=3Dpass (....)

Arc-= Seal: i=3D1; a=3Drsa-sha256; <= span style=3D"font-family:"Courier New"">t=3D1628539508; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0d=3Dgooglegroups.com; s=3Darc-20160816; b=3DABCD...Z

Arc++-path: i= =3D1; s=3Dgooglegroups.com ; d=3Doutlook.com;

Arc++-path: i=3D0; s=3Dgmail.com ; d=3D<= b>googlegroups.c= om;

Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D1628539507; cv=3Dpass;

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0d=3Dgmail.com; s=3Darc-20160816; b=3DABCD= ...Z

2) Recipient

From: someuser@gmail.com<= /a>

To: example-group@googlegroups.com

Arc-Authentic= ation-Results: i=3D2; arc++=3Dpass (....)

Arc-= Seal: i=3D2; a=3Drsa-sha256; <= span style=3D"font-family:"Courier New"">t=3D1628539509; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0d=3Doutlook.comArc-Authentication-Results: i=3D1; arc++=3Dpass (....)

Arc++-path: i=3D1; s=3Dgooglegroups.com ; d=3Doutlook.com;

Arc-Seal: i=3D1; a=3Drsa-sha256; t=3D1628539507; = cv=3Dpass;

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0d=3Dgooglegroups.com; s=3Darc-20160816; b=3DABCD...Z

Arc++-path: i=3D0; s=3Dgmail= .com ; d=3Dgooglegroups.com;

Arc++-Seal: i=3D0; a=3Drsa-sha256; t=3D1= 628539507; cv=3Dpass;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0d=3Dgmail.com; s= =3Darc-20160816; b=3DABCD...Z


If eviluser@gmail.com was a member of the example-group, and h= ad a forward setup to evilforwarder.example.com, would we see an arc set with s= =3Dgmail.com d=3Devilforwarder.examp= le.com set by google groups.
evilforwarder.example.com could then= replace the message body entirely, reseal the message and pass it on to a = recipient with intact ARC headers.
If the proposal is that th= e ARC seal includes the recipient domain regardless of a determination that= that domain is somehow trusted then I (as a receiver) can't trust any = of this.

Either the sender and every intermedi= ary needs to maintain a list of trusted forwarders it may send to, or each = ARC processor needs to maintain a list of trusted forwarders it may receive= mail from.

This proposal i= s intentionally scoped to just solve the mailing lists with DMARC issue (an= d other legitimate forwarders modifications)
As noted in the = other thread, there are good ideas out there for enabling checks of the leg= itimacy of the body modifications (e.g=C2= =A0draft-kucherawy-dkim-list-canon)=C2=A0 My = worry is that those solutions are very complex and will may actually hinder= adoption of any solution to resolve the immediate and broad problem of DMA= RC false rejection due to mailing list forwarding.=C2=A0 =C2=A0

-Wei
=C2=A0
On Mon, 13 Sep 2021, at 3:48 AM, John Levine = via Arc wrote:
It appears tha= t Wei Chuang=C2=A0 <weihaw@google.com> said:
>> For your approach= and mine, each sending system needs a list of recipient
>= > systems that are likely to edit and forward mail, and also what signat= ure
>> it'll apply if it's not the same as the = recipient address.=C2=A0 I suppose you
>> could add it = to every outgoing message using the recipient address domain
= >> but I think you'd still have a fair number of cases where the = signature
>> from the forwarder is different.
=
>
>I am probably missing something here.=C2=A0 Why= is this list of trusted
>recipients a prerequisite?

It's not, I suppose you could put a forwarding = path on everything,
without trying to guess who's likely = to forward. I do worry about
replay attacks: find a forwarded= message somewhere, splice the
original headers onto a malici= ous body, and send it to the same
mailing list as the origina= l. You can't tie the forwarding token to a
body checksum,= since mailing lists change the body and aren't likely
to= stop doing so.

In any event, I know the ARC g= roup was aware of my DKIM proposal and
decided to do it the w= ay they did. Dave Crocker or Brandon Long might
have some ins= ights into why.

R's,
John

--=C2=A0

--

=C2=A0 Marc= Bradshaw
=C2=A0=C2=A0marcbradshaw.net |=C2=A0@marcbradshaw


--
Arc mailing list
Arc@ietf.org
https://www.ietf.org/mailman/listinfo/arc
--00000000000038a46005cbe337fd-- From nobody Mon Sep 13 10:52:12 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076E93A1078 for ; Mon, 13 Sep 2021 10:52:10 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=qboztdKz; dkim=pass (2048-bit key) header.d=taugh.com header.b=Zxp4a5ez 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 sBF8AOqAObH1 for ; Mon, 13 Sep 2021 10:52:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 33AB33A106E for ; Mon, 13 Sep 2021 10:52:03 -0700 (PDT) Received: (qmail 49196 invoked from network); 13 Sep 2021 17:52:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=c02a.613f8fc1.k2109; bh=ue0sT19b9AzHnc30m9EpQisUCl8ogBuhN26XLYAOuWw=; b=qboztdKzBIZQsTFZKkT0WGqyOAfkwYxXygfc4HDHRPrjUJyDQbbUGlP6M9yWMoohR5IXDWL9IO442dag11ejC3TcJVGqZA2M6W8/Z1Dsq7G209HAtn0b6LuMfksgVfQpE0+XqQM5W2dOdMnXcvLTeL5v0ybdWS7N9P71mh+3ZViBRZM54su09u/kooEzpgyQvrUu4rqWu3UErCcekxNKmTafkITF8+3FaginjbTFb0//EgGVJ10CHdifOFYtA1oahvRT4133hu2SJUkRlFat3qaP/aKbr1w7BbnnweGslPuwX+nN5wpFSq2psAIsqtxDei5hwPPmzmrchRzt3GAlXw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=c02a.613f8fc1.k2109; bh=ue0sT19b9AzHnc30m9EpQisUCl8ogBuhN26XLYAOuWw=; b=Zxp4a5ezgHAUoaqV1Vz31DExQBn47O0/RJXil52XHgrUllccJeazzjru6gteD1ZhMeUdom8nLBZnEViiYelXKLk6/jb8QRpZywNHswkrliRwGUkRDd6HDxCVWwF4ONoEzDA0qe+eVQCAo9wRG6P+gT9grm/YmC9Xs0AF0PeeqTfq2/Uz1gDlgirvzOkCAcKxl4av6dM9UG2Vd75thm482tzR8YiL67ToK5GZ9b/RHxWCV8pchlGSb6pyzoYp1HlUzOS/6WwUy8R66T8CR481EYYZL999IdtMnmlIZ5zcV/nnf/ptgDXYRUDg3XWvxP2dnfbZ3wyyd6r1HP2BbZAuJQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Sep 2021 17:52:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 345E327CC40E; Mon, 13 Sep 2021 13:51:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 9923427CC3F0; Mon, 13 Sep 2021 13:51:59 -0400 (EDT) Date: 13 Sep 2021 13:51:59 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" Cc: arc@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210912174804.BB7E527C37B9@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [arc] Replay attacks (was Re: ARC path header) X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 17:52:10 -0000 >> without trying to guess who's likely to forward. I do worry about >> replay attacks: find a forwarded message somewhere, splice the >> original headers onto a malicious body, and send it ... > I propose checking timestamps to look for and prevent some basic replay > attacks, and depends on spam filtering to handle other scenarios. I don't think timestamps would help. If I were a bad person, I would find a list with a public archive or maybe just subscribe, and then replay messages a minute after they arrive. In my DKIM approach I assumed it would sign the message-id, since you can fairly safely drop duplicate messages with the same ID, but I don't think many lists do that. It'd be yet another game of cat and mouse. R's, John > In any event, I know the ARC group was aware of my DKIM proposal and >> decided to do it the way they did. Dave Crocker or Brandon Long might >> have some insights into why. From nobody Mon Sep 13 12:32:32 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DD03A170D for ; Mon, 13 Sep 2021 12:32:29 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=WD//ccgL; dkim=pass (2048-bit key) header.d=taugh.com header.b=Bfm34/Jt 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 xBKJeH-TLnH0 for ; Mon, 13 Sep 2021 12:32:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 DBB153A170A for ; Mon, 13 Sep 2021 12:32:23 -0700 (PDT) Received: (qmail 66491 invoked from network); 13 Sep 2021 19:32:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=103b9.613fa745.k2109; bh=od6rJmznlVWjrmkxUOdkThOYM6o7dLmg133AxoU0TWM=; b=WD//ccgL7/gmQzFvJegUYpd7cOYz9fopKZ+nvfoO3iHH2XC/7TNlXGLjah6vIF7jccq3qA84ag/F6BoXJvFcSfFtDLKO8AoQ5mdOC8TpGZD7dGc+HuHz0+q25BvljnY806vOFtGpxHOGddBehc1kVULaXL3jXmnSVU1IrEHb+LH+LertyobT2TtBW6TTkDkdbqKh+3o6k8ZLUQ8AoRidLdif23P1vZ9cQ3nJqKjT6W/I8aoRmNefwNgrvdLzbhoLxzCFUSo4sGi8qijUFWJBX4SHFIdAB10iO95358ihNNyn/rRHjZV4DHJSzgJGlLKJz33jrCpV1RbDKGd18w2CUg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=103b9.613fa745.k2109; bh=od6rJmznlVWjrmkxUOdkThOYM6o7dLmg133AxoU0TWM=; b=Bfm34/JtPkZLmJT1OM6MvEs7JUDIRKDZsIkiq4W6Jnuwqnf1tlfZYxfLiRP6WqyrLY+t8tteWo5iGvrhHUXhm+WboNVtuVOA2xSVSgbiawQ4/JPb/l363HQop2wRbeAdOMd+diSH3pmtTbnh1WZF/dFRWv0ILwzTniAq47U15e73OuuFTZ0wrD9fl+koC78O1oI+gFempNkT8UuZANJi8bifCbtOER9YCLszBpkAwHlfPMF9BaAGfeCwG8lhZhozShJjtOtdr24W8b8t9+TBmu4b0RfBGY03xsnjvDPqF/tgKqbRMbZBxXtf54hYMyR7uigxNauSm8YPvuH/sMPyAA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Sep 2021 19:32:21 -0000 Received: by ary.qy (Postfix, from userid 501) id 9938527CD4BF; Mon, 13 Sep 2021 15:32:19 -0400 (EDT) Date: 13 Sep 2021 15:32:19 -0400 Message-Id: <20210913193220.9938527CD4BF@ary.qy> From: "John Levine" To: arc@ietf.org Cc: marc@marcbradshaw.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 19:32:29 -0000 It appears that Marc Bradshaw said: >I may know that I'm sending a message on to foo.com, and may know they are a forwarder or mailing list, but once that hop changes a message there still needs to be >established trust that those modifications are reasonable. That is the major hurdle for ARC and I don't think that this proposal helps. Not really. If you know that foo.com runs mailing lists that your users subscribe to, the chances that it will suddenly turn evil are pretty low. One time I asked one of the authors of ARC why they don't just whitelist mail from known mailing lists. They said the problem is that lists do lousy spam filtering, and legit lists leak bursts of spam all the time. For example, spammer steals someone's address book and starts sending spam to a mailing list with a From: that happens to be a subscriber. Most lists only check the From: address and let the spam through. ARC lets the final recpient peek back and see whether a message was DMARC aligned when it arrived at the list. Real mail from the sender would be, the spam wouldn't. Note that this isn't something for which the original sender can provide much help, since the spammer will always say as much as it can "I am legit, let me through." R's, John PS: I should tweak my list software to moderate or reject incoming mail with DMARC failures, since at that point, it's pretty much 100% spam. From nobody Mon Sep 13 13:45:46 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4C93A0C2B for ; Mon, 13 Sep 2021 13:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 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, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=amNinta+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dvI41w2A 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 s-isjc_lNxOU for ; Mon, 13 Sep 2021 13:45:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E253A0C29 for ; Mon, 13 Sep 2021 13:45:37 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D73E55C029C for ; Mon, 13 Sep 2021 16:45:35 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute2.internal (MEProxy); Mon, 13 Sep 2021 16:45:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=XmRR46u mXWT6ev6sVIm3uSpVcjZd2U2q9eDK1lZNLmc=; b=amNinta+k5JIxp+TkfVYeXw 6N1loCjZSIJwsNMSgVbD2A7nr7uVDRK5iURueSvrydstor7qyxfKZcjRm3aZ6sZc 2vUK5MaXyavRnz4OmMvMqM+57HdFp6tbLjvT/E+r3gsetcBS6GapihhR/EyuPWYT QJPtU3rZTWiO9JMKQI+JSgLSsaGs9DkASWlYB5cqES5joWuEofOg3rtxGVxrzcD1 H/h9MqbsCXeD3SfBelIwjMq1IbAEPjZaxzwrH9/Xhg2dCsabMdC3oNfpq6VrAkcH 9i5I6Vpn/WwG/qmXz8CuqZsJWZNBfPnJWjWzQ3pNHhH+G0V+Fwk/P+EP5orVOPQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=XmRR46 umXWT6ev6sVIm3uSpVcjZd2U2q9eDK1lZNLmc=; b=dvI41w2AxE6ADbcalVI7L7 6aWwp/VMlV+UPMSv5sKzxwi9xBSnXuVAP+0oKAID14PsEyPJsm6vV6ttf+1GFPJN rKtM7hl6CgqnmIJ24bDh2quSP7SqrtGNkceVHKVsXxv+d/WPB9uOw70DtSEalALB BGCYPv415B+MBPIM8AYv2iVmJnLUgxQCfVhw2q0B/ZnIAJa7fwpjBldMKhAiEamx p597wrQcOQJlSPGDTLF1+Sfya0WgSKWsMmgDefPGpjOkpm2K/REICj17a1IPVsb1 LjlOb6BLem0q5OesVrzPlKpjZ65p+eIThN6kH/pnzZJMwY9JMgg/R/BYPXc1kfLg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegjedgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtkfhmghffohhmrghinhculd eftddmnecujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhep fdforghrtgcuuehrrggushhhrgiffdcuoehmrghrtgesmhgrrhgtsghrrggushhhrgifrd hnvghtqeenucggtffrrghtthgvrhhnpefggeehleelueeiteehteekkeejvedtuddvveef keeffedvieeuffefieehudfhgfenucffohhmrghinhepihgvthhfrdhorhhgpdhmrghrtg gsrhgrughshhgrfidrnhgvthdpthifihhtthgvrhdrtghomhenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrtgesmhgrrhgtsghrrggush hhrgifrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 71A721EE0067; Mon, 13 Sep 2021 16:45:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1229-g7ca81dfce5-fm-20210908.005-g7ca81dfc Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20210912174804.BB7E527C37B9@ary.qy> Date: Tue, 14 Sep 2021 06:44:52 +1000 From: "Marc Bradshaw" To: arc@ietf.org Content-Type: multipart/alternative; boundary=ee6ea83b2e2f4f619350f9cab0c243c8 Archived-At: Subject: Re: [arc] Replay attacks (was Re: ARC path header) X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 20:45:43 -0000 --ee6ea83b2e2f4f619350f9cab0c243c8 Content-Type: text/plain On Tue, 14 Sep 2021, at 2:21 AM, Wei Chuang via Arc wrote: > > I propose checking timestamps to look for and prevent some basic replay attacks, and depends on spam filtering to handle other scenarios. Yes, you could argue for additional authentication on the message body, but such proposals to do that are much more complex that arguably would not help many mail forwarders and receivers. (IMHO There are good ideas out there for that e.g draft-kucherawy-dkim-list-canon ) Like you say because body modifications happen in legitimate mail flow by mailing lists and other forwarders, and this proposal is intentionally scoped to just solve the mailing lists with DMARC issue (as well as the other legitimate forwarders). > I don't feel that replay attacks are the issue. A reasonably placed attacker could inject bad mail into a flow almost instantaneously, while legitimate mail could be delayed for long periods if, for example, a list server held it for moderator approval. -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --ee6ea83b2e2f4f619350f9cab0c243c8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

= On Tue, 14 Sep 2021, at 2:21 AM, Wei Chuang via Arc wrote:

I propose checking tim= estamps to look for and prevent some basic replay attacks, and depe= nds on spam filtering to handle other scenarios.  Yes, you could ar= gue for additional authentication on the message body, but such pro= posals to do that are much more complex that arguably would not hel= p many mail forwarders and receivers.  (IMHO There are good ideas o= ut there for that e.g draft-kucherawy-dkim-list-canon)  Like you say because body modifications happen in legitimate&nbs= p;mail flow by mailing lists and other forwarders, and this proposa= l is intentionally scoped to just solve the mailing lists with DMARC iss= ue (as well as the other legitimate forwarders).   
<= div> 

I don't= feel that replay attacks are the issue. A reasonably placed attacker co= uld inject bad mail into a flow almost instantaneously, while legitimate= mail could be delayed for long periods if, for example, a list server h= eld it for moderator approval.

--
<= br>
  Marc Bradshaw
  mar= cbradshaw.net | @m= arcbradshaw


--ee6ea83b2e2f4f619350f9cab0c243c8-- From nobody Mon Sep 13 13:53:52 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728BE3A0CF0 for ; Mon, 13 Sep 2021 13:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 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, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=E2Sus1bU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s7tRmOKY 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 7nNhqkXqfTum for ; Mon, 13 Sep 2021 13:53:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9F83A0CED for ; Mon, 13 Sep 2021 13:53:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4E90D5C029C; Mon, 13 Sep 2021 16:53:43 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute2.internal (MEProxy); Mon, 13 Sep 2021 16:53:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=c5m8ODs PXV9LfTStZZdeYQy52heNlx9zBv8yYuFpF6g=; b=E2Sus1bUjD8tD2Uz8vJeMMo ny9NS9pEuFO+vz6X6RajxhoTtbBGQx5Ad9dgHDk5KLT7T8GV+jxHPrqe3iqwL/SS 9OSGniIVboWD/KjakUD6MYxcZmhKiW/qlTbjShAq39hl3Hy9U7dbkqQjUmeXr2g+ XjDcYN7bUiBRAFbO3JtdVhZgR1YLVnjDdPAgMHrE/1v5cbuamfdjXJSVHh+mOmXL 8zJIi5Noa0F2JdvlfrLe52jqcUe3oG6AK/2+v+SqANkx+Wtontcrrl3H2iXXHxgF PTRAZ7NB4szmmmn/TajQeJd4ncuno7+v9FORqLtR/ZId3EbxEkMKdSdbgkMtpMQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=c5m8OD sPXV9LfTStZZdeYQy52heNlx9zBv8yYuFpF6g=; b=s7tRmOKYxZaC+H3m4AjScO pxDnOdcwXLr0ejR+ns8PotCNuDpZ6NcX8NIO6gV50Zdl2CBtSDUHWe/8TEsXnMAR jOnxYJLREwFkxsod1aIFiooCTDFNfiXhnTWUsMltxXNM9VLnCKoSpRr2AHDdWAHs LWmQ0OtgUr57ejIGkf6W+DB3qjNUR+BQGyN1+wUpmIT6Gf8hFepUQTPtejzBIZ0N reNKXZi0tnqO4w8PcOw5ALhKZer+7++ny8dhD54/2xobQrATwqtM/FB8WxumO9/B aoD4tx3JsRw9KbePaAtqFLK/g5JECDp4hCC0lHo/3hRrAKTsKXKdxA6tH2u4RDWg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegjedgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtkfhmghffohhmrghinhculdeftddmnecujfgurhepofgfggfkjghf fffhvffutgesrgdtreerreertdenucfhrhhomhepfdforghrtgcuuehrrggushhhrgiffd cuoehmrghrtgesmhgrrhgtsghrrggushhhrgifrdhnvghtqeenucggtffrrghtthgvrhhn peelleefkeevteefieefgfduueejhfeutdegtdffvdevgefhffeiteelgeeuhfekheenuc ffohhmrghinhepmhgrrhgtsghrrggushhhrgifrdhnvghtpdhtfihithhtvghrrdgtohhm necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrh gtsehmrghrtggsrhgrughshhgrfidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD7151EE0067; Mon, 13 Sep 2021 16:53:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1229-g7ca81dfce5-fm-20210908.005-g7ca81dfc Mime-Version: 1.0 Message-Id: <370ffe5c-ce58-487b-9790-460500ec94f6@beta.fastmail.com> In-Reply-To: <20210913193220.9938527CD4BF@ary.qy> References: <20210913193220.9938527CD4BF@ary.qy> Date: Tue, 14 Sep 2021 06:53:22 +1000 From: "Marc Bradshaw" To: "John Levine" , arc@ietf.org Content-Type: multipart/alternative; boundary=cceeadde610e4339ba3d3183ff8179f7 Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 20:53:51 -0000 --cceeadde610e4339ba3d3183ff8179f7 Content-Type: text/plain On Tue, 14 Sep 2021, at 5:32 AM, John Levine wrote: > > Not really. If you know that foo.com runs mailing lists that your > users subscribe to, the chances that it will suddenly turn evil are > pretty low. > If you know that, then you have some already done some work in establishing a list of trusted sealers, and we are back where we started. -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --cceeadde610e4339ba3d3183ff8179f7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

= On Tue, 14 Sep 2021, at 5:32 AM, John Levine wrote:

Not really. If y= ou know that foo.com runs mailing lists that your
users su= bscribe to, the chances that it will suddenly turn evil are
pretty low.


I= f you know that, then you have some already done some work in establishi= ng a list of trusted sealers, and we are back where we started.

--
=

&n= bsp; Marc Bradshaw
  marcbradshaw.net | @marcbradshaw

--cceeadde610e4339ba3d3183ff8179f7-- From nobody Mon Sep 13 13:55:37 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1723A0D2A for ; Mon, 13 Sep 2021 13:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.087 X-Spam-Level: X-Spam-Status: No, score=-18.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8zG7z0oaqxWN for ; Mon, 13 Sep 2021 13:55:30 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 44E0A3A0D3B for ; Mon, 13 Sep 2021 13:55:30 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id f6so14036040iox.0 for ; Mon, 13 Sep 2021 13:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ydRPhrF0Jw19w1RrJJ0K1mZDMZkd6rWYJ2rkdyFn3rs=; b=INyR+deAHFV6z+Uudi8N9BYP0yOmMf+sJ03hNvNCdee0+xzjUF3Km9vSD0098c6V1Q iUNrYhtGnsPAZWVa5vrF9mPJEWP1qR4whqjDEi0d6ZhKNPgU1sLKvesE+Kvp5k3IVBwx cPow51oAx1o35SWSCLF5Ll647S6WIqIR0oSmBkh/DNLjQe/8nl3OK16ufFJkeh7Vaavp A+V/iA4WWfxvgpiY6iOM0nf5QaJYEOjZJQ3I0APf2pXjQhLC6IyDoqgsIe2LJh7CPQB7 sm05t0k1zIEf8nY8qOvaB/aMKJ3NZJ+Qc6dSI8jecd0uuHMo/96u253SGfx9njFkJ4R+ IN4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ydRPhrF0Jw19w1RrJJ0K1mZDMZkd6rWYJ2rkdyFn3rs=; b=Qfm4LAkNt5vh7S6w+vCib3sdcSm2MY+/TOKbAueaSvgj8RbufPMx8vqQoV5I99/DQ8 +yv52GbfptOO2uJQMU3TWrhV2EslGDHH3JD4HfGw3tbqmDdbP1i9kVOxfoSAGbTmJvkY qgq+GaSm9Ef40a9ArKSvMruHDN+GEivCHeBxXakfpAU/8jLbDovE9X+YeQdbR7YU/cGR A60Ph3248aN3EnVg8e/cWwz9UYmoCqrc5j6mOYduHCuMY+a7l7OZZyP35SG1UhpY5U8t aBJVm+yeeUz4k8/sPcxkFslozBsuLWijEIQyPG6yBGzN/jmYBgVfUGNsU2DmJ0pBy9b/ NCgQ== X-Gm-Message-State: AOAM531LVIBKrIH/vmx0DEmpB/0QMq/ra6TmGSaB7qp2xpAT8Apcu0e2 VH4lDZ/CiO7OwbLRlnBWHx4Xyi4jx9FGhc4TopUB9SsTo+M= X-Google-Smtp-Source: ABdhPJwPFue40hKVM0ElQJ3LgO1ebfEmqmzf0DBdLPRwOfa1ssThXPVHaxO+YahSAXUOIm1OoBrMjpVDjMJ0Wyk8IAU= X-Received: by 2002:a5e:db06:: with SMTP id q6mr10601609iop.24.1631566528128; Mon, 13 Sep 2021 13:55:28 -0700 (PDT) MIME-Version: 1.0 References: <20210912174804.BB7E527C37B9@ary.qy> In-Reply-To: From: Wei Chuang Date: Mon, 13 Sep 2021 13:55:13 -0700 Message-ID: To: Marc Bradshaw Cc: arc@ietf.org Content-Type: multipart/alternative; boundary="00000000000056989105cbe6af12" Archived-At: Subject: Re: [arc] Replay attacks (was Re: ARC path header) X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 20:55:35 -0000 --00000000000056989105cbe6af12 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 13, 2021 at 1:45 PM Marc Bradshaw via Arc wrote: > > On Tue, 14 Sep 2021, at 2:21 AM, Wei Chuang via Arc wrote: > > > I propose checking timestamps to look for and prevent some basic replay > attacks, and depends on spam filtering to handle other scenarios. Yes, you > could argue for additional authentication on the message body, but such > proposals to do that are much more complex that arguably would not help > many mail forwarders and receivers. (IMHO There are good ideas out there > for that e.g draft-kucherawy-dkim-list-canon > ) > Like you say because body modifications happen in legitimate mail flow by > mailing lists and other forwarders, and this proposal is intentionally > scoped to just solve the mailing lists with DMARC issue (as well as the > other legitimate forwarders). > > > > I don't feel that replay attacks are the issue. A reasonably placed > attacker could inject bad mail into a flow almost instantaneously, while > legitimate mail could be delayed for long periods if, for example, a list > server held it for moderator approval. > Except that the originator intended for the mail to go along that path to the attacker. So from the perspective of applying DMARC policy, we would say the message was intended and should pass DMARC, even if ultimately it was malicious. The proposal identifies such a path, and also asks for spam filtering to detect malicious modified messages because it acknowledges this limitation that comes with accepting mailing list and other legitimate body modifications. -Wei > > -- > > Marc Bradshaw > marcbradshaw.net | @marcbradshaw > > > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > --00000000000056989105cbe6af12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 13, 2021 at 1:45 PM Marc = Bradshaw via Arc <arc@ietf.org> w= rote:

On Tue, 14 Sep 2021, at 2:21 AM, Wei Chuang via Arc w= rote:

I propose checkin= g timestamps to look for and prevent some basic replay attacks, and=C2=A0de= pends on spam filtering to handle other scenarios.=C2=A0 Yes, you could arg= ue for additional authentication on the message body,=C2=A0but such proposa= ls to do that are much=C2=A0more complex that arguably would not help many = mail forwarders and receivers.=C2=A0 (IMHO There are good ideas out there f= or that e.g=C2=A0d= raft-kucherawy-dkim-list-canon)=C2=A0 Like you say becaus= e body modifications happen in legitimate=C2=A0mail flow by mailing lists a= nd other forwarders, and=C2=A0this proposal is intentionally scoped to just= solve the mailing lists with DMARC issue (as well as the other legitimate = forwarders).=C2=A0 =C2=A0
=C2=A0

I don't feel that replay attacks are the issu= e. A reasonably placed attacker could inject bad mail into a flow almost in= stantaneously, while legitimate mail could be delayed for long periods if, = for example, a list server held it for moderator approval.
<= /blockquote>

Except that the originator intended for the= mail to go along that path to the attacker.=C2=A0 So from the perspective = of applying DMARC policy, we would say the message was intended and should = pass DMARC, even if ultimately it was malicious.=C2=A0 The proposal identif= ies such a path, and also asks for spam filtering to detect malicious modif= ied messages because it acknowledges this limitation that comes with accept= ing mailing list and other legitimate body modifications.

-Wei
=C2=A0

--

=C2=A0 Marc = Bradshaw
=C2=A0=C2=A0marcbradshaw.net |=C2=A0@marcbradshaw


--
Arc mailing list
Arc@ietf.org
https://www.ietf.org/mailman/listinfo/arc
--00000000000056989105cbe6af12-- From nobody Mon Sep 13 14:07:19 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55A53A0E14 for ; Mon, 13 Sep 2021 14:07:16 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=w9Z21gop; dkim=pass (2048-bit key) header.d=taugh.com header.b=o7e1cCOC 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 XgD7hrQam1sb for ; Mon, 13 Sep 2021 14:07:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 B2D013A0E0D for ; Mon, 13 Sep 2021 14:07:10 -0700 (PDT) Received: (qmail 81144 invoked from network); 13 Sep 2021 21:07:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=13cf1.613fbd7c.k2109; bh=PtMb70+pHL4fuYJSibw3q8fVPk9zHzjfQMue5WIH96g=; b=w9Z21gopvYewYSfGZK1QHjeBesrkmWn3J8OzRVT9ICp3mgCBVq2i4NC4JcSOt2iL0x99afm5xSzREQeWrBRNomrooG7vSny1pc4iUUi0WpF+PnlQ1JeNKvRMIr8sN3S6HeeBWk+n1gz0W1YPORoP/PDscgpQEvsTpK6Hc25XKqDF7u25s2ahrvOoEKtEok0ujjsTA31SDuNElA7l5+GAYzEtH+zbDtS45Aa0yCkLpJDMWuALPJ0wqWfgfsgQMfD9BM3RA6b1vXVKiZtj57UZJe1x93mbA46pPG4fXQPTQ2f3KAy37BBgz/LblqfBWOpzyFKpN9Z3+64CRI5dqM+NXg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=13cf1.613fbd7c.k2109; bh=PtMb70+pHL4fuYJSibw3q8fVPk9zHzjfQMue5WIH96g=; b=o7e1cCOCHoF+nvKEGSx5Lm21OelVhd7qw1CHT6i8istjTZ/nBFIDwFIJKomqokrP0VrV9EtIembtWLhiFyLN7f1qm3De9hKl1Q2rtDrCa2AEVQlI0SM1P2sEh6W2SuDPpFxUIDxzqoLHXcVyhC9MyLDlE8GYaBNsONtZrFcu7oXyojHe5Ff+ki44TuWk+THZRuD/a3zfBeqNezEGKcDraK1/IeJ/6FdfGR+FQt9voKWhMIYmv3oABJXVZ0bxojebNvQrxaafSDfrykrHzG9NvbQtKWRVlIJpex5BidLawFR5izcHf5LHgR38fKEohBwquuFMiA9hx7bm+FXBN7GkwA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Sep 2021 21:07:07 -0000 Received: by ary.qy (Postfix, from userid 501) id 31BB727D82DB; Mon, 13 Sep 2021 17:07:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id AB57E27D82BD; Mon, 13 Sep 2021 17:07:03 -0400 (EDT) Date: 13 Sep 2021 17:07:03 -0400 Message-ID: <68272e8a-26fb-8cc4-4acb-1f3bf663d9dd@taugh.com> From: "John R Levine" To: "Marc Bradshaw" , arc@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <370ffe5c-ce58-487b-9790-460500ec94f6@beta.fastmail.com> References: <20210913193220.9938527CD4BF@ary.qy> <370ffe5c-ce58-487b-9790-460500ec94f6@beta.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 21:07:17 -0000 >> Not really. If you know that foo.com runs mailing lists that your >> users subscribe to, the chances that it will suddenly turn evil are pretty low. > > If you know that, then you have some already done some work in establishing a list of trusted sealers, and we are back where we started. Since it is easy to fake an ARC chain beyond the most recent link, it was always clear that ARC is only interesting on mail from sources that are generally credible. There were some sporadic attempts to crowdsource a set of mailing list sites but as far as I know they never went anywhere. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Sep 14 10:04:42 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E8D3A264F for ; Tue, 14 Sep 2021 10:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 fQZGIVOKuq1f for ; Tue, 14 Sep 2021 10:04:18 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 35D3E3A2644 for ; Tue, 14 Sep 2021 10:04:11 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id c19so12099345qte.7 for ; Tue, 14 Sep 2021 10:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AczP3OIgo9nDZ6LJWRb9MLHAVUsb1znEaJe9+3nhmH4=; b=CsnAeFxOmeuubz5/kMgPCEKCrCHCmt6GWmyANHtA7TTl66nuILNlmBkefezSfSp/As GfWMfw9I+QzuBVyFZ0BXq2jWT2nYd9M5MD1laOdnKVmwdeI5ueDYXiMuJnJl+ZTM2a9N CHXT4N4WeF/6vAG3m0GmYY79nI6wH8EEMuW2k6Ru3zfaMTkDBTQ9KcVOvShEcoiqt+sT lt6M3vO8JBJrloemIHJLwQZavJs4U14w8wLtv04KZiczAsTlH7GRGYFnwr+lUbDQESMU TBARoiD4yW9XAX9GliDiEWThNSSnfssatl7ArRqT+YAP+Og6wwKwMMDQQ/AjOn8HEO/p C4bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AczP3OIgo9nDZ6LJWRb9MLHAVUsb1znEaJe9+3nhmH4=; b=GnyntIXIaJ1KrMZqlgKrB5AK6DicMIaiz8jnKiULBYGQxMzTqsUXTEj2Ep5F3l/K4v KmRQX5GhRvlV/s2MRvxSLKxKa3k4dwT68n/XCzOVUqdEM07GTgMoNSDmFnMjZx0G20q5 JLjXYivg4HY6sB4+8jNkQTq9fmjDiMqj2aU/HNzoEX09KyyR4juWRMC6HRAcSM08P4VE zW2lAMT2GF9GrymZz3t/DL6hk7s4uCywgUokh4cJlmgexvWyhXr9GDTCo/hrtlkfSUaF s25wApHkdEDE9hEbOOq+i/AtIJ/RxMlVFZPT63+3iyPna8qu/DeRm3O5z0KIPcvb8HTm QbCw== X-Gm-Message-State: AOAM531dz+GQrc9GymZsbwRS1r82E5fKwhK3++wiVwtHlDRGCIBaFBig YXNrnk55Pw9FhEdpCeJgo8L9Qw7KSY8hcHOqW/rJVhvSZ1Y= X-Google-Smtp-Source: ABdhPJzKRo1OqWsioS9wN1rwCg5v53ckFesdu+V3yWTV7Dno+5mAHNon8dPRTFWFK4fnsva4/1VvSsFIy3wCdItE/cE= X-Received: by 2002:ac8:7b47:: with SMTP id m7mr5971188qtu.178.1631639048975; Tue, 14 Sep 2021 10:04:08 -0700 (PDT) MIME-Version: 1.0 References: <20210913193220.9938527CD4BF@ary.qy> In-Reply-To: <20210913193220.9938527CD4BF@ary.qy> From: Todd Herr Date: Tue, 14 Sep 2021 13:03:53 -0400 Message-ID: To: John Levine Cc: arc@ietf.org, marc@marcbradshaw.net Content-Type: multipart/alternative; boundary="000000000000ea8d7f05cbf79178" Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 17:04:39 -0000 --000000000000ea8d7f05cbf79178 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 13, 2021 at 3:32 PM John Levine via Arc wrote: > > One time I asked one of the authors of ARC why they don't just > whitelist mail from known mailing lists. They said the problem is that > lists do lousy spam filtering, and legit lists leak bursts of spam all > the time. For example, spammer steals someone's address book and > starts sending spam to a mailing list with a From: that happens to be > a subscriber. Most lists only check the From: address and let the spam > through. ARC lets the final recpient peek back and see whether a > message was DMARC aligned when it arrived at the list. Real mail from > the sender would be, the spam wouldn't. > This kind of thing makes me think that people are tying signer/sealer reputation to the quality of mail that they're signing and forwarding, and I just don't understand that approach. To my mind, signer/sealer reputation should be determined based on whether or not one feels it can trust the authentication results being reported by the signer/sealer. In private conversations with some mailbox providers, I've proposed an idea that signer reputation can be measured by comparing the reputation earned by authenticated indirect mail flows to authenticated direct mail flows. At a rudimentary level, that would look like this: - Domain D sends some quantity of mail directly to Mailbox Provider M, and D earns a reputation for its authenticated mail; call this R1 - ARC signer/sealer S is an intermediary on some quantity of mail that originated at D and is ultimately delivered to M, and D earns a reputation for mail that was successfully authenticated as reported by S; call this R2 - If and only if R1 and R2 are reasonably similar, then S can be trusted to have reported correct authentication results This idea was shot down because it wouldn't scale, due to too many paths to keep track of, what with the endless number of originating domains that a large mailbox provider might see, but I still believe in the idea that signer/sealer reputation should be based on the trustworthiness of its ARC Header Sets and nothing else. I just haven't figured out a good way to instrument and measure that trustworthiness. Am I misunderstanding the discussion here, or am I wildy off base? -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ea8d7f05cbf79178 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 13, 2021 at 3:32 PM John Levine via Arc <arc@ietf.org> wrote:
One time I asked one of the authors of ARC why they don't just
whitelist mail from known mailing lists. They said the problem is that
lists do lousy spam filtering, and legit lists leak bursts of spam all
the time. For example, spammer steals someone's address book and
starts sending spam to a mailing list with a From: that happens to be
a subscriber. Most lists only check the From: address and let the spam
through. ARC lets the final recpient peek back and see whether a
message was DMARC aligned when it arrived at the list. Real mail from
the sender would be, the spam wouldn't.

=
This k= ind of thing makes me think that people are tying signer/sealer reputation = to the quality of mail that they're signing and forwarding, and I just = don't understand that approach.

To my mind, signer/sealer reputation= should be determined based on whether or not one feels it can trust the au= thentication results being reported by the signer/sealer. In private conver= sations with some mailbox providers, I've proposed an idea that signer = reputation can be measured by comparing the reputation earned by authentica= ted indirect mail flows to authenticated direct mail flows. At a rudimentar= y level, that would look like this:
  • Domain D sends some quantity of = mail directly to Mailbox Provider M, and D earns a reputation for its authe= nticated mail; call this R1
  • ARC signer/sealer S is an intermediary = on some quantity of mail that originated at D and is ultimately delivered t= o M, and D earns a reputation for mail that was successfully authenticated = as reported by S; call this R2
  • If and only if R1 and R2 are reasona= bly similar, then S can be trusted to have reported correct authentication = results
This idea was shot down because it wouldn't scale= , due to too many paths to keep track of, what with the endless number of o= riginating domains that a large mailbox provider might see, but I still bel= ieve in the idea that signer/sealer reputation should be based on the trust= worthiness of its ARC Header Sets and nothing else. I just haven't figu= red out a good way to instrument and measure that trustworthiness.

Am I misunderstanding the discussion here, or am I wildy o= ff base?

--

Todd Herr | Technical Director, Standards and Ecosyste= m
m: 703.220.4153

This email and all data transmitte= d with it contains confidential and/or proprietary information intended sol= ely for the use of individual(s) authorized to receive it. If you are not a= n intended and authorized recipient you are hereby notified of any use, dis= closure, copying or distribution of the information included in this transm= ission is prohibited and may be unlawful. Please immediately notify the sen= der by replying to this email and then delete it from your system.

--000000000000ea8d7f05cbf79178-- From nobody Tue Sep 14 15:41:05 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36603A3444 for ; Tue, 14 Sep 2021 15:41:03 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=cIuaiANd; dkim=pass (2048-bit key) header.d=taugh.com header.b=SOVkIscx 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 M4Tow0Qogb9m for ; Tue, 14 Sep 2021 15:40:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 3E8923A3441 for ; Tue, 14 Sep 2021 15:40:57 -0700 (PDT) Received: (qmail 97221 invoked from network); 14 Sep 2021 22:40:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=17bc3.614124f7.k2109; bh=yG7dYesIOKkdi5OdB8tcYWPQPjROWr+7ClSamI4YsOk=; b=cIuaiANd70YFJsbUEdrkbXy6nTZQJOi4YPqrHH+JYkVDplCnelFOaW//FTL+mDziJ+aQpXcYEVa04O+flPfAIRgZBH2nc5xSpowEEuq3jx5p4heeW65mUoWV7Av/FcD8ojjwiTmjEmb963NlNURrohU5ZcQAkmRprB9028QIrC4SIknW6snHTetgGfmkTmDasspOhy2XK4wfuYHaWNJ1iRH5+eBquWv9cU0B21WoOebv0KA/WvOhyBx2IZNiK6XQoHX6TRk/hSruVWP89mQePxdfT7IR2y7kwOYab2s/zHJgiMojXkFOqZE48lkVDgC4OnpOF2iON8RbWmICE7Eo5g== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=17bc3.614124f7.k2109; bh=yG7dYesIOKkdi5OdB8tcYWPQPjROWr+7ClSamI4YsOk=; b=SOVkIscxY4YX2RqvNQynJpN2WkdyCQo3K7lJFGPQ267cB6qXgPXSs7Vr8BcCTlZHvE2LGKHk0uE/IJaDh+9OnTQsyb+1SgWxlxY7XMnu9kmkmFMYTm0e8DBxL3R9gkKPl9/R4joEHmYPfu+2HqNkzGYFZQGxfqaxxun4kVshVyiiuGO1n+l6Qdn+yDbARNTsDRKGbLCEo8EpwWaTqh5gakfv111xgPJ7AZQJMPkcWV9QZ6dcw3Bitd/MvlPDBXjHqO1leLAOhzbxwR5KwXKbg4Ui9j4qEuC6W/MrqAm5HrioJC3QmbxDIJ0zCdcWsj05GNvVzxJK9MiR8/ZmJkGbOw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Sep 2021 22:40:54 -0000 Received: by ary.qy (Postfix, from userid 501) id DC3F52819FC0; Tue, 14 Sep 2021 18:40:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 41CE72819FA2; Tue, 14 Sep 2021 18:40:54 -0400 (EDT) Date: 14 Sep 2021 18:40:54 -0400 Message-ID: From: "John R Levine" To: "Todd Herr" Cc: arc@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210913193220.9938527CD4BF@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [arc] what ARC does, was ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 22:41:04 -0000 > This kind of thing makes me think that people are tying signer/sealer > reputation to the quality of mail that they're signing and forwarding, and > I just don't understand that approach. The interesting question isn't whether the forwarder is doing genuine sealing, it's whether you want the mail they send. Sealing is merely a part of that. Here's a thought experiment: someone sets up a copy of Mailman with ARC. Re Mark's concerns, it only add a List-ID, no other message modifications, and the ARC seals are all genuine. And 100% of the mail it sends is spam. (I have enountered a few Mailman setups like this give or take the ARC bit.) Do you accept its mail because of its perfect ARC seals and minimal message modification? Of course not, it's sending spam and ARC doesn't change that. As far as I can see ARC is useful for one narrow but important thing: if you have a forwarder that sends mostly mail your users want, but leaks some spam due to lousy filtering at its end, ARC can compensate for the lousy filtering and sort mail better than blindly following DMARC policies. So you use ARC on forwarders that already have a good reputation. By the way, trying to see if a host's seals are genuine by comparing the pass rate won't work. A bad guy can seal whatever it wants with fake A-R results that match whatever ratio you're looking for. If an ARC seal validates, that only means you're seeing the same seal the signer added, not that the seal reflected reality. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Sep 15 05:57:46 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A813A17E2 for ; Wed, 15 Sep 2021 05:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 w5Mu2YlXv0So for ; Wed, 15 Sep 2021 05:57:40 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 F1AE33A17E9 for ; Wed, 15 Sep 2021 05:57:39 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id m9so2201297qtk.4 for ; Wed, 15 Sep 2021 05:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=c1UC5nG5hP6qlrMxrZPwIubVg+HCntImZU6N8BN1mKE=; b=M2HLQfAKULKgimuHGUOkt54+vERq447Ow9g5Y14UiWosCFqjBDT/vgqU9yywJEKMVq nLjsNhX6539Nu8OgbmvJ2CkfBckei04q9ymDWyLSeW3dnaznevp+ujGcZJ9iTx8nW9Hx vRc4NbNx/aX9UZccWs/0FaX3PSyOxBXrQSqZx4QFWv2+PR+SAsKWflZtytiS0hWY6c57 YIQkdzllYQDEk1yPldOSMxzj2WTcMty/tnSrgKVLGhV/NHeus1RIsJfWRUBOqOlfYw8y dMAVjIHUHiNWT4Z6mg7ghI/JYZbB8AHtqZsgbqrBkcq70gW1wmZXkFCKa4I7E1LmWo58 6mBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=c1UC5nG5hP6qlrMxrZPwIubVg+HCntImZU6N8BN1mKE=; b=soFpgCyDuXi8TJQ+7CWDlLgaxKG+YXNOL77zZfI5NcQtVpQq7REtvLefpjqjSCH+sZ +SVICld3lBYtc6/kYQPjyBk1ddtPNi4SspOuDyFLmcOCYjAxcn6MX7OB+2bw8ijsJBky A+mBxbrQlEZlRQdgKnopW0zMnb8Hec880/FfHAF4yj4SSQYN9aH9h+JoRgp+l7Wgl6W+ DKUyBalypRyMiwEAAeUSuppalqTbSY+6Bay6Z7Ub4VOnqyck+okJqZ8V0+RkEaqviWEj jaDcyk5Qh36R/tnT8p87zGJs8ymb9vsDE7lSy0Twq3FAYtdRJ0ARk0YKvugEo9w2gbxa 4rAA== X-Gm-Message-State: AOAM5313VwAG0wsGZNxaE+SkQ7J2Qa2+ByX7SIgjpSkhKGLQ6jyi79m2 tM66E9PfVV3nH+5iG3kabvM86dL2gu+pSnUNx8ZlnzdYxTSP/w== X-Google-Smtp-Source: ABdhPJxcuGoVTVqzlIQ7J1sHhDFwUJ2B8gHY5Kh1Rgpv2n6XFAo3O4YDzIFQN2q1nx6EkHWikYKaxJezbVXsxbhuO+s= X-Received: by 2002:ac8:7050:: with SMTP id y16mr10034826qtm.44.1631710657812; Wed, 15 Sep 2021 05:57:37 -0700 (PDT) MIME-Version: 1.0 References: <20210913193220.9938527CD4BF@ary.qy> In-Reply-To: From: Todd Herr Date: Wed, 15 Sep 2021 08:57:22 -0400 Message-ID: To: arc@ietf.org Content-Type: multipart/alternative; boundary="00000000000022af5b05cc083eb3" Archived-At: Subject: Re: [arc] what ARC does, was ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 12:57:46 -0000 --00000000000022af5b05cc083eb3 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 14, 2021 at 6:40 PM John R Levine wrote: > > This kind of thing makes me think that people are tying signer/sealer > > reputation to the quality of mail that they're signing and forwarding, > and > > I just don't understand that approach. > > The interesting question isn't whether the forwarder is doing genuine > sealing, it's whether you want the mail they send. Sealing is merely a > part of that. > > Here's a thought experiment: someone sets up a copy of Mailman with ARC. > Re Mark's concerns, it only add a List-ID, no other message modifications, > and the ARC seals are all genuine. And 100% of the mail it sends is spam. > (I have enountered a few Mailman setups like this give or take the ARC > bit.) Do you accept its mail because of its perfect ARC seals and minimal > message modification? Of course not, it's sending spam and ARC doesn't > change that. > > As far as I can see ARC is useful for one narrow but important thing: if > you have a forwarder that sends mostly mail your users want, but leaks > some spam due to lousy filtering at its end, ARC can compensate for the > lousy filtering and sort mail better than blindly following DMARC > policies. So you use ARC on forwarders that already have a good > reputation. > > By the way, trying to see if a host's seals are genuine by comparing the > pass rate won't work. A bad guy can seal whatever it wants with fake A-R > results that match whatever ratio you're looking for. If an ARC seal > validates, that only means you're seeing the same seal the signer added, > not that the seal reflected reality. > I have not considered ARC to be necessary to answering the question of "Do I want the mail that this forwarder is sending me?" at least not in the context in which you're presenting it. I am long removed from the mailbox provider side, but I have always seen this as the use case for ARC... - Message arrives, RFC5322.From domain is X - X publishes a DMARC policy record, and the message fails the DMARC validation checks that I perform - However, there is within the message one or more ARC header sets, and at least one of those header sets indicates that the message passed DMARC validation checks at a previous hop in its journey, signed and sealed by S - If I know S to be a source of truth for such signing and sealing (meaning I can trust that the message really did pass DMARC validation checks when S inserted its ARC header set), then I can reliably know that X was the authentic source of the message, and I can apply whatever rules I have in place to treat the message in a manner that is consistent with the reputation X has earned at my site. - If I do not know S to be a source of truth for signing and sealing, then I must treat the message as if it failed DMARC validation checks - If there are no ARC header sets in the message, then I must treat the message as if it failed DMARC validation checks The open question for me, of course, is how does S establish itself to me as a source of truth for the information contained in its ARC header sets, and the above probably really only works if there is one ARC header set for every intermediary that handled the message, but this is where my brain lands when thinking about ARC. Note that I'm not arguing here that my interpretation of ARC is correct; it's just how I've interpreted the Abstract from 8617: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000022af5b05cc083eb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 14, 2021 at 6:40 PM John R Levine <johnl@taugh.com> wrote:
&g= t; This kind of thing makes me think that people are tying signer/sealer > reputation to the quality of mail that they're signing and forward= ing, and
> I just don't understand that approach.

The interesting question isn't whether the forwarder is doing genuine <= br> sealing, it's whether you want the mail they send.=C2=A0 Sealing is mer= ely a
part of that.

Here's a thought experiment: someone sets up a copy of Mailman with ARC= .
Re Mark's concerns, it only add a List-ID, no other message modificatio= ns,
and the ARC seals are all genuine.=C2=A0 And 100% of the mail it sends is s= pam.
(I have enountered a few Mailman setups like this give or take the ARC
bit.)=C2=A0 Do you accept its mail because of its perfect ARC seals and min= imal
message modification?=C2=A0 Of course not, it's sending spam and ARC do= esn't
change that.

As far as I can see ARC is useful for one narrow but important thing: if you have a forwarder that sends mostly mail your users want, but leaks
some spam due to lousy filtering at its end, ARC can compensate for the lousy filtering and sort mail better than blindly following DMARC
policies.=C2=A0 So you use ARC on forwarders that already have a good
reputation.

By the way, trying to see if a host's seals are genuine by comparing th= e
pass rate won't work.=C2=A0 A bad guy can seal whatever it wants with f= ake A-R
results that match whatever ratio you're looking for.=C2=A0 If an ARC s= eal
validates, that only means you're seeing the same seal the signer added= ,
not that the seal reflected reality.

I have not considered ARC to be necessary to answering the question of &q= uot;Do I want the mail that this forwarder is sending me?" at least no= t in the context in which you're presenting it.

I am long removed fr= om the mailbox provider side, but I have always seen this as the use case f= or ARC...
  • Message arrives, RFC5322.From domain= is X
  • X publishes a DMARC p= olicy record, and the message fails the DMARC validation checks that I perf= orm
  • However, there is withi= n the message one or more ARC header sets, and at least one of those header= sets indicates that the message passed DMARC validation checks at a previo= us hop in its journey, signed and sealed by S
    • If I know S to be a source of truth for such signing= and sealing (meaning I can trust that the message really did pass DMARC va= lidation checks when S inserted its ARC header set), then I can reliably kn= ow that X was the authentic source of the message, and I can apply whatever= rules I have in place to treat the message in a manner that is consistent = with the reputation X has earned at my site.
    • If I do not know S to = be a source of truth for signing and sealing, then I must treat the message= as if it failed DMARC validation checks
  • If there are no ARC header sets in the message, the= n I must treat the message as if it failed DMARC validation checks
The open question for me, of= course, is how does S establish itself to me as a source of truth for the = information contained in its ARC header sets, and the above probably really= only works if there is one ARC header set for every intermediary that hand= led the message, but this is where my brain lands when thinking about ARC.<= /font>

Note that I'm not arguing here that my = interpretation of ARC is correct; it's just how I've interpreted th= e Abstract from 8617:

   The Authenticated Received=
 Chain (ARC) protocol provides an
   authenticated "chain of custody" for a message, allowing each =
entity
   that handles the message to see what entities handled it before and
   what the message's authentication assessment was at each step in the
   handling.

   ARC allows Internet Mail Handlers to attach assertions of message
   authentication assessment to individual messages.  As messages
   traverse ARC-enabled Internet Mail Handlers, additional ARC
   assertions can be attached to messages to form ordered sets of ARC
   assertions that represent the authentication assessment at each step
   of the message-handling paths.

   ARC-enabled Internet Mail Handlers can process sets of ARC assertions
   to inform message disposition decisions, identify Internet Mail
   Handlers that might break existing authentication mechanisms, and
   convey original authentication assessments across trust boundaries.



--

Todd He= rr | Technical Director, Standards and Ecosystem
e: <= a href=3D"mailto:todd.herr@valimail.com" target=3D"_blank">todd.herr@valima= il.com
m: 703.= 220.4153

This email and all data transmitted with it con= tains confidential and/or proprietary information intended solely for the u= se of individual(s) authorized to receive it. If you are not an intended an= d authorized recipient you are hereby notified of any use, disclosure, copy= ing or distribution of the information included in this transmission is pro= hibited and may be unlawful. Please immediately notify the sender by replyi= ng to this email and then delete it from your system.

--00000000000022af5b05cc083eb3-- From nobody Wed Sep 15 12:30:07 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA13E3A08A7 for ; Wed, 15 Sep 2021 12:30:04 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=mg7NRL/Z; dkim=pass (2048-bit key) header.d=taugh.com header.b=xEyX7veZ 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 yHL9gQ7P5Fht for ; Wed, 15 Sep 2021 12:29:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 198E23A08AF for ; Wed, 15 Sep 2021 12:28:58 -0700 (PDT) Received: (qmail 29977 invoked from network); 15 Sep 2021 19:28:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7516.61424978.k2109; bh=QVDGMdkdJTkoYTmfqiqi6YkJDohDjU+LQSdWk7YCPLI=; b=mg7NRL/ZKqsTaIyoz4VTmron23uz3UtCU/wXwA/FHTh4uRqmp4TLr5Oo9W2tT7Xio4Jck9mNJh9DO3luvZqDU9c4VBeKOjHMuOBDifzttI4lEcdCCoNWAADhSYsDle99EodZiR8pQmI4kNw9q7p7FZoQDOd1bJJkW5MHMLjEhkc7TsHgwe/b5kEqAtVtOGEHJnIsOnM/WmoteQsx2VkyUYTgmL/BQx7IEBpIf7UE6fGcFqXz+7kVwi1T3iuiCjgdEN2KTGBv3OkUrJhEPUW2bj5g6NM9fQvCAtrHLfPp59U3fOrqn9jukv9LWkxXICxQg3me9b83wPv2+Zy/aUohPg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7516.61424978.k2109; bh=QVDGMdkdJTkoYTmfqiqi6YkJDohDjU+LQSdWk7YCPLI=; b=xEyX7veZ3SEaIc3DMcTQOSOPgDfUxXQu5/dJ5QqxyE2b25E5JS9i9G7GwdPPohB+VMeHYK4q2/TqYKDW9ifJJh1ddNT/Nxt5H/WWkaKo/SIvw3mWXUxVI/kbF/jK5A/gTa3cC9OxJIYQXS+WdgXH3dj1OGd7/c5H/ZIGl5d6Zs8kvMCj0J9aMEqIqH67vx/Tfkk3IJptPwUxf1REY19fDx8OtXl3fF/yT2Eoeh5quF4c/rDR1ftiIJCzUAhJx7jUHleeVvFlmV1HuQsOtdzxsHK8L6Mf/nXEfGNpP+t2uZ4HXExT1bIEqrsZE9zl13+dGPyrclwU/JoZ2+mt0OjFog== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Sep 2021 19:28:55 -0000 Received: by ary.qy (Postfix, from userid 501) id A125A28286C0; Wed, 15 Sep 2021 15:28:54 -0400 (EDT) Date: 15 Sep 2021 15:28:54 -0400 Message-Id: <20210915192855.A125A28286C0@ary.qy> From: "John Levine" To: arc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] what ARC does, was ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 19:30:05 -0000 It appears that Todd Herr said: >I am long removed from the mailbox provider side, but I have always seen >this as the use case for ARC... > > - Message arrives, RFC5322.From domain is X > - X publishes a DMARC policy record, and the message fails the DMARC > validation checks that I perform > - However, there is within the message one or more ARC header sets, and > at least one of those header sets indicates that the message passed DMARC > validation checks at a previous hop in its journey, signed and sealed by S So far so good. > - If I know S to be a source of truth for such signing and sealing > (meaning I can trust that the message really did pass DMARC validation > checks when S inserted its ARC header set), then I can reliably know that X > was the authentic source of the message, and I can apply whatever rules I > have in place to treat the message in a manner that is consistent with the > reputation X has earned at my site. Nope. You know that the message originally came from X but you do not know what S did with it. The message reputation can't be better than X's reputation but depending on what S does, it could be much worse. Let's adjust my example a little: it picks up real mail from somewhere, replaces the bodies with ransomware, and sends it out with genuine ARC seals. The reputation of X was fine, but S is very not fine. The message reputation is min(S,X). That's why ARC is only useful if S has a good reputation, and you can't tell that by looking at ARC seals. R's, John From nobody Wed Sep 15 13:01:16 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C06B3A0E15 for ; Wed, 15 Sep 2021 13:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 W0Hm_XE_OLJ7 for ; Wed, 15 Sep 2021 13:01:09 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 A687C3A0E13 for ; Wed, 15 Sep 2021 13:01:09 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id c19so3484818qte.7 for ; Wed, 15 Sep 2021 13:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aOLYrSqQTT7N3Yb7Da0xVmwS3GVhyF0P33fyKatcK/Y=; b=ZujM94twQyJJ132zW6ZqGWuy+vC/ZutOR3zrmTUrj2/LGb1cwr/nrzfXQaWxGuDqMU qB/OFYm039A28Z+mdKsr/pzMkolpwG5rEYIH6qQOpGx9LZRmyfAX2pILfHSVpA1MaTDG iBQ7pactkeKVR9IwntyMYeufh1dQvBS6RON8ga1hCLaGr7dnU8doohJKLnNQHO9hDC45 nwcIu7ho2LPsNq+SHLKTFNTc3+OicOKTJh/uT3qk+zjkSCDwfBqizXNdIVoETjCBssju wlhSABTyRwF52lwg+g8Lue4FRtMDJto+UfUznpuUOD838texxBTR2Sk6nHQ7lJMsqco6 KXqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=aOLYrSqQTT7N3Yb7Da0xVmwS3GVhyF0P33fyKatcK/Y=; b=4l/tAlw4nuoOwiDMZptQUgUy7HTMBcoEKhramTR4jtoMBx3BnCsJ9UN5G1OAaXwd0g t0EaWYsVXhrxMIf/Wwd9wYmNdmGETMIeL62YCWRppLvflqYDcw3oLt+3lxlURbkESB7v PPYIisW3v7kF5oIqtM2+bfpztFmSVghH9g4JY//aCr1bMmaU2TDiChReCegK/GyZwjL7 QWilKpyNBh/vvk3DgFkYKMgqeGclhFP45Knt1Gq27DvyRKNK4iL5AI842pNi2gTCfnGs wCk1MFkLQxWlyeu0zWujwFAJ/0kDoBajjD3EOQB4fSH1R06HrcTw7RCvM/2hw94gF0wB Bq0g== X-Gm-Message-State: AOAM533Kb/4wRJYBNF8WHbHnxZE2Dd7xf3QlDpNVSF1GoJxc90Lw2f+Q yQBrHkRdGgKgGVcEHl0fHkM/X21nyYDriBxEmODfeL+sbWQ= X-Google-Smtp-Source: ABdhPJx1QLAHLg4LTVD4ii5pzp8+ftWHxw5FicNfevKjrO10rF4kS/4o4ZEAeBMNYwCsBV0/5CGXcCL8gcrIkzmHOGU= X-Received: by 2002:ac8:7050:: with SMTP id y16mr1729657qtm.44.1631736067243; Wed, 15 Sep 2021 13:01:07 -0700 (PDT) MIME-Version: 1.0 References: <20210915192855.A125A28286C0@ary.qy> In-Reply-To: <20210915192855.A125A28286C0@ary.qy> From: Todd Herr Date: Wed, 15 Sep 2021 16:00:51 -0400 Message-ID: To: arc@ietf.org Content-Type: multipart/alternative; boundary="000000000000a7d63905cc0e28a5" Archived-At: Subject: Re: [arc] what ARC does, was ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 20:01:15 -0000 --000000000000a7d63905cc0e28a5 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 15, 2021 at 3:28 PM John Levine wrote: > It appears that Todd Herr said: > > > - If I know S to be a source of truth for such signing and sealing > > (meaning I can trust that the message really did pass DMARC > validation > > checks when S inserted its ARC header set), then I can reliably > know that X > > was the authentic source of the message, and I can apply whatever > rules I > > have in place to treat the message in a manner that is consistent > with the > > reputation X has earned at my site. > > Nope. > > You know that the message originally came from X but you do not know > what S did with it. The message reputation can't be better than X's > reputation but depending on what S does, it could be much worse. > > Let's adjust my example a little: it picks up real mail from > somewhere, replaces the bodies with ransomware, and sends it out with > genuine ARC seals. The reputation of X was fine, but S is very not > fine. > > The message reputation is min(S,X). That's why ARC is only useful if S > has a good reputation, and you can't tell that by looking at ARC > seals. > > I'm doing a poor job of getting my idea across, or perhaps I'm doing a good job and you're rejecting it, but I'm going to try one more time... I'm not proposing that S's reputation be directly driven by the content of its seals; rather, I'm proposing that S's reputation be driven by the reputation X gathers through its indirect mail flow (call it XI) that is sealed by S, when compared to the reputation X gathers through its direct mail flow to me (call it XD). - XD will be calculated based on authenticated mail sent directly to me from X. Doesn't matter what the reputation is, only that it establishes one in this fashion. - XI will be calculated based on mail claimed to be authenticated through S's sealing. Again, doesn't matter what the reputation is, only that it establishes one. - If XD and XI are similar (by my definition of "similar" based on how I calculate sender domain reputation), then I know I can trust S to properly seal X's mail, because the quality of X's mail is the same whether it's direct or indirect through S. Doesn't necessarily mean that I'll place it in the Inbox or even accept it, because if X's reputation is bad, it'll still be subject to the "Your mail is bad and you should feel bad" treatment, but I have established that S can be trusted for this mailstream, I think. - If XI is demonstrably worse than XD, then I likely cannot trust S to properly seal X's mail (and maybe can't trust S at all) - If XI is demonstrably better than XD (something I think likely when X is a mailbox provider and S is a well-run mailing list server) then I likely can trust S to properly seal X's mail. - At some point, if S has shown itself worthy of trust to reliably seal mail from many domains, then I know I can trust S to seal all mail, but I'll keep monitoring things As I said in an earlier post, though, it's likely this won't scale because there are too many X's to keep track of. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000a7d63905cc0e28a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Sep 15, 2021 at 3:28 PM John Levi= ne <johnl@taugh.com> wrote:
It appears that To= dd Herr=C2=A0 <todd.herr@valimail.com> said:

>=C2=A0 =C2=A0 =C2=A0 - If I know S to be a source of truth for such sig= ning and sealing
>=C2=A0 =C2=A0 =C2=A0 (meaning I can trust that the message really did p= ass DMARC validation
>=C2=A0 =C2=A0 =C2=A0 checks when S inserted its ARC header set), then I= can reliably know that X
>=C2=A0 =C2=A0 =C2=A0 was the authentic source of the message, and I can= apply whatever rules I
>=C2=A0 =C2=A0 =C2=A0 have in place to treat the message in a manner tha= t is consistent with the
>=C2=A0 =C2=A0 =C2=A0 reputation X has earned at my site.

Nope.=C2=A0

You know that the message originally came from X but you do not know
what S did with it.=C2=A0 The message reputation can't be better than X= 's
reputation but depending on what S does, it could be much worse.

Let's adjust my example a little: it picks up real mail from
somewhere, replaces the bodies with ransomware, and sends it out with
genuine ARC seals. The reputation of X was fine, but S is very not
fine.

The message reputation is min(S,X). That's why ARC is only useful if S<= br> has a good reputation, and you can't tell that by looking at ARC
seals.


I'm doing a poor job of getting my idea acros= s, or perhaps I'm doing a good job and you're rejecting it, but I&#= 39;m going to try one more time...

I'm not proposing that S's r= eputation be directly driven by the content of its seals; rather, I'm p= roposing that S's reputation be driven by the reputation X gathers thro= ugh its indirect mail flow (call it XI) that is sealed by S, when compared = to the reputation X gathers through its direct mail flow to me (call it XD)= .
  • XD will be calculated based on authenticated mail sent directly to= me from X. Doesn't matter what the reputation is, only that it establi= shes one in this fashion.
  • XI will be calculated based on mail claim= ed to be authenticated through S's sealing. Again, doesn't matter w= hat the reputation is, only that it establishes one.
  • If XD and XI a= re similar (by my definition of "similar" based on how I calculat= e sender domain reputation), then I know I can trust S to properly seal X&#= 39;s mail, because the quality of X's mail is the same whether it's= direct or indirect through S. Doesn't necessarily mean that I'll p= lace it in the Inbox or even accept it, because if X's reputation is ba= d, it'll still be subject to the "Your mail is bad and you should = feel bad" treatment, but I have established that S can be trusted for = this mailstream, I think.
  • If XI is demonstrably worse than XD, then= I likely cannot trust S to properly seal X's mail (and maybe can't= trust S at all)
  • If XI is demonstrably better than XD (something I = think likely when X is a mailbox provider and S is a well-run mailing list = server) then I likely can trust S to properly seal X's mail.
  • At= some point, if S has shown itself worthy of trust to reliably seal mail fr= om many domains, then I know I can trust S to seal all mail, but I'll k= eep monitoring things
As I said in an earlier post, though, i= t's likely this won't scale because there are too many X's to k= eep track of.

--

Todd Herr | Technical Director, Standards and Ec= osystem
m: 703.220.4153

This email and all data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

--000000000000a7d63905cc0e28a5-- From nobody Wed Sep 15 23:16:04 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912B13A19C1 for ; Wed, 15 Sep 2021 23:16:01 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=VGHUOAfl; dkim=pass (2048-bit key) header.d=taugh.com header.b=RXv41BgY 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 Ousj6JP8r0fG for ; Wed, 15 Sep 2021 23:15:55 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 5056F3A19CD for ; Wed, 15 Sep 2021 23:15:55 -0700 (PDT) Received: (qmail 26549 invoked from network); 16 Sep 2021 06:15:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=67a8.6142e118.k2109; bh=7I/syhMs/MmGmChORJH1EbjKAOobheaoOTp0n3W3F50=; b=VGHUOAfl+2EnZIAOF4dCDWO9LsFj069OoAnDTr9fO78vowRvrBXYA4Na2VbEM88drQoAZ+Z+2+ycG8aRYhoiuHbD8u6BoTfefWXJhqrn8JNS71NmxGcNqKjjH59dC3y8oB3qKRwfQ8Jlj/k8t6rtEsYj1FXv4Fjx0/H5hhfdyRqxcH7anob2L8zMdTAbmiw4EHDwbAgkCgA6e9uzVTrQSG/6gK6a1Ug4W+HpiJKXknfmgXa3jf5bG/8XDuYgEkmLv80tt4mAt245Xrr0c+fyKIUDNMeknSJTdfR1PZMhDX6ci+G3rfkAs9IyKfqBfLGHQi9DaKweMzydwvnF9n34fw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=67a8.6142e118.k2109; bh=7I/syhMs/MmGmChORJH1EbjKAOobheaoOTp0n3W3F50=; b=RXv41BgYC8iC+1YfZe23Qi2r0pJPOQX7SoWvi0wCIx0Szw67gM6WHJF7XA2VdXz0jv0+ruF3nWqN+Cm1QjKB2fESzACPsc4iuvAaOLh5nFxA5eGBuuSyP7NW0FP72Cd8NOCEjCwB6P9HLvEKdi37Ulv4k/lg9fIHeGWgzSspr3GkMHexTsns7ylE7TbrrR3x7Dh72V6M6mUPmk/a9R4ToT3nSa/yFoLwxFdwsjkeWMYZG2mn8dBYEheg5KD33q45Wrw6WKqQeynn6DFlAUdDgFjt5HEIMQecFNhLF21vsz+gfchS0DgZ9HBk/ctrGT4ZC48k87MiTaalmsK87LE3uQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Sep 2021 06:15:51 -0000 Received: by ary.qy (Postfix, from userid 501) id CB60A28307D6; Thu, 16 Sep 2021 02:15:50 -0400 (EDT) Date: 16 Sep 2021 02:15:50 -0400 Message-Id: <20210916061550.CB60A28307D6@ary.qy> From: "John Levine" To: arc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] what ARC does, was ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 06:16:02 -0000 It appears that Todd Herr said: > - If XD and XI are similar (by my definition of "similar" based on how I > calculate sender domain reputation), then I know I can trust S to properly > seal X's mail, because the quality of X's mail is the same whether it's > direct or indirect through S. ... Oh. I see what you're saying. I suppose it would work although it'd be hard to tell from a perverse setup where S rejected all of the unaligned mail from X and a lazy programmer put a fake seal on everything. I realize that's unlikely. So here's my low(ish) tech counterapproach. If a mail source has a generally good reputation, assume its ARC seals are real. What's the downside? R's, John From nobody Thu Sep 16 05:13:07 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8354A3A26DB for ; Thu, 16 Sep 2021 05:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=SjhCI4Rp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Lvy5DH9o 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 ynHL8lr0C_Ha for ; Thu, 16 Sep 2021 05:12:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278E03A26DD for ; Thu, 16 Sep 2021 05:12:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 618F05C00D4 for ; Thu, 16 Sep 2021 08:12:58 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute2.internal (MEProxy); Thu, 16 Sep 2021 08:12:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=4OBEzKF C1tdvPrJz+NpDlKd8dr776phMvqQRijJQARQ=; b=SjhCI4Rp3pa1y7ys3db/LPe Gr95Ze/cKyYNlJm6GGt4FnQ6tzg0kLu3p/wf4jMN46X/EHlFkik4fP7eIV+k6iKb 31ixqQv95HJuzWYySAZJO91Hrd6IulPmqMaBhGyiyXSVxp1hXZjlZ3ZlGHE/OM6d INFIu1Oeab8AmVtMJ3EZB7YJPfThmazvUdR3bMazH67G+pjN8CBSeC7IlT1azVvK C9PvHyaZA2iqMgzW8gMzHLVHYPaA50pNiui66QD2i4zhNhruQTV+uMfDpHji0EdO tp3JOhwC5jCm/Xd57pOcQkIEs3VK7U1DnWM3ipVqRwm+FGjk9yTKuNDGICdwfWQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=4OBEzK FC1tdvPrJz+NpDlKd8dr776phMvqQRijJQARQ=; b=Lvy5DH9oIgsRf09kDxaI1m G0jYnpaIsnCNKe3+xaYZTGtGYtRTdwAhqDVEYz2Erio787aeTwAVMb/ACpipwbSZ MF5ZuU/ldRO/KMLqtLeSUCnoOAU+velPNAuA4i9cUJS5Fqw07aYAenFm3OqeW9Go tGiFmrhl93LFeHsiKQDuv8sigheCWaeA5umF739VQDgYRA1/wzXMyeZaILlb68cQ Mb3iyXjUsviZ9zGem1CXr723+uKzjOmaxfvHRFAJuCR3RF2mBf66+ykf8i9NUExZ xIhHa441LTIlY2HJBN+iJPtTTyHHd7RyMO5rp3jjmlbPhhLATjdttRxElVM0VayQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehgedggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthfkmhhgffhomhgrihhnucdlfe dtmdenucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedf ofgrrhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnh gvtheqnecuggftrfgrthhtvghrnhepgfegheelleeuieetheetkeekjeevtdduvdevfeek feefvdeiuefffeeiheduhffgnecuffhomhgrihhnpehivghtfhdrohhrghdpmhgrrhgtsg hrrggushhhrgifrdhnvghtpdhtfihithhtvghrrdgtohhmnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhgtsehmrghrtggsrhgrughshh grfidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C55781EE0067; Thu, 16 Sep 2021 08:12:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1291-gc66fc0a3a2-fm-20210913.001-gc66fc0a3 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20210912174804.BB7E527C37B9@ary.qy> Date: Thu, 16 Sep 2021 22:12:24 +1000 From: "Marc Bradshaw" To: arc@ietf.org Content-Type: multipart/alternative; boundary=1020ce84540f466091b5244e2e770b21 Archived-At: Subject: Re: [arc] Replay attacks (was Re: ARC path header) X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 12:13:05 -0000 --1020ce84540f466091b5244e2e770b21 Content-Type: text/plain The originator indended for A message to be sent along that part of the path, But if a bad actor maliciously modified it en route they may not have indended that the message arrived at the destination as it was when it arrived. If we can't trust that a modification made by an intermediary was legitimate we surely cannot make any judgement about what DMARC policy should or should not be applied. Spam and maliciousness filtering is a side issue. I have said before, and will keep saying. A good forwarder can and will forward bad messages, this isn't about the quality of mail, it is about wether or not we believe that an intermediary which modifies messages makes only reasonable and legitimate modifications. On Tue, 14 Sep 2021, at 6:55 AM, Wei Chuang via Arc wrote: > > > On Mon, Sep 13, 2021 at 1:45 PM Marc Bradshaw via Arc wrote: >> __ >> >> On Tue, 14 Sep 2021, at 2:21 AM, Wei Chuang via Arc wrote: >>> >>> I propose checking timestamps to look for and prevent some basic replay attacks, and depends on spam filtering to handle other scenarios. Yes, you could argue for additional authentication on the message body, but such proposals to do that are much more complex that arguably would not help many mail forwarders and receivers. (IMHO There are good ideas out there for that e.g draft-kucherawy-dkim-list-canon ) Like you say because body modifications happen in legitimate mail flow by mailing lists and other forwarders, and this proposal is intentionally scoped to just solve the mailing lists with DMARC issue (as well as the other legitimate forwarders). >>> >> >> I don't feel that replay attacks are the issue. A reasonably placed attacker could inject bad mail into a flow almost instantaneously, while legitimate mail could be delayed for long periods if, for example, a list server held it for moderator approval. > > Except that the originator intended for the mail to go along that path to the attacker. So from the perspective of applying DMARC policy, we would say the message was intended and should pass DMARC, even if ultimately it was malicious. The proposal identifies such a path, and also asks for spam filtering to detect malicious modified messages because it acknowledges this limitation that comes with accepting mailing list and other legitimate body modifications. > > -Wei > >> >> >> -- >> >> Marc Bradshaw >> marcbradshaw.net | @marcbradshaw >> >> >> -- >> Arc mailing list >> Arc@ietf.org >> https://www.ietf.org/mailman/listinfo/arc > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --1020ce84540f466091b5244e2e770b21 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
The originator = indended for A message to be sent along that part of the path,  But= if a bad actor maliciously modified it en route they may not have inden= ded that the message arrived at the destination as it was when it arrive= d.
If we can't trust that a modification made by an interm= ediary was legitimate we surely cannot make any judgement about what DMA= RC policy should or should not be applied.
Spam and malici= ousness filtering is a side issue. I have said before, and will keep say= ing. A good forwarder can and will forward bad messages, this isn't abou= t the quality of mail, it is about wether or not we believe that an inte= rmediary which modifies messages makes only reasonable and legitimate mo= difications.

On Tue, 14 Sep 2021, at 6:55 A= M, Wei Chuang via Arc wrote:


=
O= n Mon, Sep 13, 2021 at 1:45 PM Marc Bradshaw via Arc <arc@ietf.org> wrote:


On Tue, 14 Sep 2021, at 2:21 AM, Wei Chuang v= ia Arc wrote:

= I propose checking timestamps to look for and prevent some basic replay = attacks, and depends on spam filtering to handle other scenarios.&n= bsp; Yes, you could argue for additional authentication on the message b= ody, but such proposals to do that are much more complex that = arguably would not help many mail forwarders and receivers.  (IMHO = There are good ideas out there for that e.g draft-kucherawy-dkim-list-canon) = ; Like you say because body modifications happen in legitimate mail= flow by mailing lists and other forwarders, and this proposal is i= ntentionally scoped to just solve the mailing lists with DMARC issue (as= well as the other legitimate forwarders).   
&n= bsp;

I don't feel = that replay attacks are the issue. A reasonably placed attacker could in= ject bad mail into a flow almost instantaneously, while legitimate mail = could be delayed for long periods if, for example, a list server held it= for moderator approval.

Except that the originator intended for the mail to go along that path = to the attacker.  So from the perspective of applying DMARC policy,= we would say the message was intended and should pass DMARC, even if ul= timately it was malicious.  The proposal identifies such a path, an= d also asks for spam filtering to detect malicious modified messages bec= ause it acknowledges this limitation that comes with accepting mailing l= ist and other legitimate body modifications.

-Wei
 
--=  
Arc mailing list


= --

<= /td>
  Marc Bradshaw


--1020ce84540f466091b5244e2e770b21-- From nobody Thu Sep 16 05:18:40 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C5E3A270C for ; Thu, 16 Sep 2021 05:18:37 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=Z+FhWTRI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FCPUxbU9 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 uQGjNVHOmVLh for ; Thu, 16 Sep 2021 05:18:31 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E403A270A for ; Thu, 16 Sep 2021 05:18:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A1B8B5C0221 for ; Thu, 16 Sep 2021 08:18:30 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute2.internal (MEProxy); Thu, 16 Sep 2021 08:18:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=qD6lN2B CGW5IUOLNlB6PcqUWZ5aMdBgmc6GYBWS5Hkk=; b=Z+FhWTRIqhVtrrDx7hujz3a ySFuTrZ/0Ms3YepKxR9TfATGFUPhtLdk5gVe5lHw98fpBM5AFiberCXdbf9W8947 v68LsurAVzX273vY3eLeaR16okZudJt+bSxPXLS9/Pohyaa1Tcy0WoUuYBiSTZXX o4Yc4hVnn4QmQr3ZrDIVY8iC3heKS9MK+iGRWtp5BPSIlrRFDkhjezYr1DuPxhNY OnFzDDM7cHTVzVMgmBzh4kbCy2Z5Op7mTp4R5PZqCX3cbWIB6J5eY72j0geCtjnz gJAHKHNZ6VK8I0ltGvRuqa/0+jXTqoKGT6hGVBOJUk3Cplz1y/oJzctWdW3oPYg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qD6lN2 BCGW5IUOLNlB6PcqUWZ5aMdBgmc6GYBWS5Hkk=; b=FCPUxbU9xcCYTn0RvtLkZ4 PtROL6A57h1cVu8t2aA/J7De1c8vP2gme6c6rdOuGJjHwh28t9Z5Us5OGDtdxwS4 DdnRvy0NxW3Yu2SCwtSuc2a8zmTbZ5DJMqjVmPYZhofNHt8NaYJOaWADFF2BCCjH Iqunf3y9NdHIydcaxiW3vXmWzXutv686upgfsu3DIk5hWQYLnBv9x+RE95ogXr9G YPCgOHw4zNjeONqXsorulPAT3WxRYCmdQjW5+rSC60blU5uR8d8nBZ/hiwOYyKvb K3HTCDkw/TvE5TTMuaUfCUwLilaqrZowlY9p+XK4cJO9jdWqZn7wspueJg0QBjQg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehgedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthfkmhhgffhomhgrihhnucdlfe dtmdenucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedf ofgrrhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnh gvtheqnecuggftrfgrthhtvghrnhepgfegheelleeuieetheetkeekjeevtdduvdevfeek feefvdeiuefffeeiheduhffgnecuffhomhgrihhnpehivghtfhdrohhrghdpmhgrrhgtsg hrrggushhhrgifrdhnvghtpdhtfihithhtvghrrdgtohhmnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhgtsehmrghrtggsrhgrughshh grfidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 554B21EE0068; Thu, 16 Sep 2021 08:18:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1291-gc66fc0a3a2-fm-20210913.001-gc66fc0a3 Mime-Version: 1.0 Message-Id: <11afacce-f677-4f5e-92b9-1fb80f0bab0e@beta.fastmail.com> In-Reply-To: References: <20210913193220.9938527CD4BF@ary.qy> Date: Thu, 16 Sep 2021 22:18:07 +1000 From: "Marc Bradshaw" To: arc@ietf.org Content-Type: multipart/alternative; boundary=eeb8f97b47a9419292acd7b5d6a9c2ca Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 12:18:38 -0000 --eeb8f97b47a9419292acd7b5d6a9c2ca Content-Type: text/plain This is how I approach reputation for ARC. We're just not seeing enough mail which is ARC sealed, modified, and not from the top senders we all already know and have reputation for. The volume right now is so low it isn't feasable to apply any automated reputation. This may be a chicken and egg thing. On Wed, 15 Sep 2021, at 3:03 AM, Todd Herr via Arc wrote: > On Mon, Sep 13, 2021 at 3:32 PM John Levine via Arc wrote: >> >> One time I asked one of the authors of ARC why they don't just >> whitelist mail from known mailing lists. They said the problem is that >> lists do lousy spam filtering, and legit lists leak bursts of spam all >> the time. For example, spammer steals someone's address book and >> starts sending spam to a mailing list with a From: that happens to be >> a subscriber. Most lists only check the From: address and let the spam >> through. ARC lets the final recpient peek back and see whether a >> message was DMARC aligned when it arrived at the list. Real mail from >> the sender would be, the spam wouldn't. > > This kind of thing makes me think that people are tying signer/sealer reputation to the quality of mail that they're signing and forwarding, and I just don't understand that approach. > > To my mind, signer/sealer reputation should be determined based on whether or not one feels it can trust the authentication results being reported by the signer/sealer. In private conversations with some mailbox providers, I've proposed an idea that signer reputation can be measured by comparing the reputation earned by authenticated indirect mail flows to authenticated direct mail flows. At a rudimentary level, that would look like this: > * Domain D sends some quantity of mail directly to Mailbox Provider M, and D earns a reputation for its authenticated mail; call this R1 > * ARC signer/sealer S is an intermediary on some quantity of mail that originated at D and is ultimately delivered to M, and D earns a reputation for mail that was successfully authenticated as reported by S; call this R2 > * If and only if R1 and R2 are reasonably similar, then S can be trusted to have reported correct authentication results > This idea was shot down because it wouldn't scale, due to too many paths to keep track of, what with the endless number of originating domains that a large mailbox provider might see, but I still believe in the idea that signer/sealer reputation should be based on the trustworthiness of its ARC Header Sets and nothing else. I just haven't figured out a good way to instrument and measure that trustworthiness. > > Am I misunderstanding the discussion here, or am I wildy off base? > > -- > > > *Todd Herr *** | Technical Director, Standards and Ecosystem > *e:* todd.herr@valimail.com > *m:* 703.220.4153 > > This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. > > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --eeb8f97b47a9419292acd7b5d6a9c2ca Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is how I a= pproach reputation for ARC. We're just not seeing enough mail which is A= RC sealed, modified, and not from the top senders we all already know an= d have reputation for. The volume right now is so low it isn't feasable = to apply any automated reputation. This may be a chicken and egg thing.<= br>

On Wed, 15 Sep 2021, at 3:03 AM, Todd Herr = via Arc wrote:
<= div dir=3D"ltr">
On Mon, Sep 13, 2021= at 3:32 PM John Levine via Arc <arc@= ietf.org> wrote:

One time I asked one of the authors of AR= C why they don't just
whitelist mail from known mailing l= ists. They said the problem is that
lists do lousy spam f= iltering, and legit lists leak bursts of spam all
the tim= e. For example, spammer steals someone's address book and
= starts sending spam to a mailing list with a From: that happens to be
a subscriber. Most lists only check the From: address and = let the spam
through. ARC lets the final recpient peek ba= ck and see whether a
message was DMARC aligned when it ar= rived at the list. Real mail from
the sender would be, th= e spam wouldn't.

This kind of thi= ng makes me think that people are tying signer/sealer reputation to the = quality of mail that they're signing and forwarding, and I just don't un= derstand that approach.

To my mind, signer/sealer = reputation should be determined based on whether or not one feels it can= trust the authentication results being reported by the signer/sealer. I= n private conversations with some mailbox providers, I've proposed an id= ea that signer reputation can be measured by comparing the reputation ea= rned by authenticated indirect mail flows to authenticated direct mail f= lows. At a rudimentary level, that would look like this:
    =
  • Domain D sends some quantity of mail directly to Mailbox Provider M,= and D earns a reputation for its authenticated mail; call this R1
  • ARC signer/sealer S is an intermediary on some quantity of mail t= hat originated at D and is ultimately delivered to M, and D earns a repu= tation for mail that was successfully authenticated as reported by S; ca= ll this R2
  • If and only if R1 and R2 are reasonably similar, = then S can be trusted to have reported correct authentication results
This idea was shot down because it wouldn't scale, due t= o too many paths to keep track of, what with the endless number of origi= nating domains that a large mailbox provider might see, but I still beli= eve in the idea that signer/sealer reputation should be based on the tru= stworthiness of its ARC Header Sets and nothing else. I just haven't fig= ured out a good way to instrument and measure that trustworthiness.
<= /div>

Am I misunderstanding the discussion here, or a= m I wildy off base?

--


Todd Herr | Technical Director, Standards and Ecosystem
m: 703.220.4153
=

<= span class=3D"size" style=3D"font-size:10.6667px;">This email and all da= ta transmitted with it contains confidential and/or proprietary informat= ion intended solely for the use of individual(s) authorized to receive i= t. If you are not an intended and authorized recipient you are hereby no= tified of any use, disclosure, copying or distribution of the informatio= n included in this transmission is prohibited and may be unlawful. Pleas= e immediately notify the sender by replying to this email and then delet= e it from your system.

<= /div>
-- 
Arc mailing list


--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw


--eeb8f97b47a9419292acd7b5d6a9c2ca-- From nobody Thu Sep 16 05:40:56 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B574A3A27A8 for ; Thu, 16 Sep 2021 05:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 8ldz8K2Oh5ya for ; Thu, 16 Sep 2021 05:40:50 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 443F93A27A6 for ; Thu, 16 Sep 2021 05:40:50 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id 73so2057165qki.4 for ; Thu, 16 Sep 2021 05:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hQnAyF9kRgmHB7KEh3zVd13CDKIDi0BrycFBDGWdnL8=; b=IKflx6ujiyV/U0nFZ3VGnwLSBGbhbo8u6KZRiPxHQye9Fl3Fq9Sza+rTsrrzPo6R1w YTR1R10H/oWjQMT6B0Jd+5TZleHm2aNyb+gsh/rlMVQdFlRpsnDGzHUvdsSsWDsbwflo rdhRb4+yVnHOzXQhxJaRheHNQOz6/DQSAE5qo0MlRrbmelHGi5GVYT1Xy1UA+mWa0ba3 ItDYgRl5mlf43uBfzsGP5yvWSTgHWgH5Upe2Kybz8ALei02iDoH9/3uIeUmw5IPd8LlS CJq7yX70OtvkXNc59GvMjE4NM6T0xhXf9ieQfM7O5CddA/Yv8YS4/bwroZNo08+bhEI+ 9i7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hQnAyF9kRgmHB7KEh3zVd13CDKIDi0BrycFBDGWdnL8=; b=g2f8u9+0KUprALbUDX2FuXfm6gchyIOPRYa47b3ebhm4TBT657F3KwGLUpOg0d/ezL WQdaPXPFIsmTVmofho5d0n7LOZfjJ+1zJv34k5CFP1vpfuGCFzjwgSYQGJAvBM9K3fQ3 SDujD5iAGc34m+wYH+ii94/DLKaCx59R3IpnxS8wEeLogwGIWQXvwV1K0tpiGejKdSXm C1NxuOKbTNeUxai92gYK4XSlHsK1IsAPmXwHwibLtMzOnOe/UjoF6PnLr0zUDKfyRSCg 2LsjqYubNty4ZJGBqlol5Nw5+rgwx+HvUwDAao+7iCGFr8jKgVHaLawtHTSUs7JdAfYx OWlw== X-Gm-Message-State: AOAM531zgrHUbWWbfUTh6YTCxmhS4Hvued6vI2pFB4memjEsrI/advgz ldoS6DsbTyZg41LyUOLEWLkOzVZ+Sb6FZqDQPj15ClByHis= X-Google-Smtp-Source: ABdhPJy1yjzaZtZbHsd4Fp3z524dFoyiHRLFJwZv+nBW7Vwvj8II4XBipcGRq1KWOUqj4Cp8YjjS6R6DVx/iUgYvaBk= X-Received: by 2002:a05:620a:12e4:: with SMTP id f4mr4589663qkl.373.1631796048531; Thu, 16 Sep 2021 05:40:48 -0700 (PDT) MIME-Version: 1.0 References: <20210916061550.CB60A28307D6@ary.qy> In-Reply-To: <20210916061550.CB60A28307D6@ary.qy> From: Todd Herr Date: Thu, 16 Sep 2021 08:40:32 -0400 Message-ID: To: arc@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1a24f05cc1c1f88" Archived-At: Subject: Re: [arc] what ARC does, was ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 12:40:55 -0000 --000000000000d1a24f05cc1c1f88 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 16, 2021 at 2:15 AM John Levine wrote: > It appears that Todd Herr said: > > - If XD and XI are similar (by my definition of "similar" based on how > I > > calculate sender domain reputation), then I know I can trust S to > properly > > seal X's mail, because the quality of X's mail is the same whether it's > > direct or indirect through S. ... > > Oh. I see what you're saying. I suppose it would work although it'd be > hard to > tell from a perverse setup where S rejected all of the unaligned mail from > X > and a lazy programmer put a fake seal on everything. I realize that's > unlikely. > > So here's my low(ish) tech counterapproach. If a mail source has a > generally > good reputation, assume its ARC seals are real. What's the downside? > > I suspect that any system designed to measure signer/sealer reputation will likely rely on multiple data sets, simply because of a lack of uniformity on how identities are able to be established for intermediaries. Your counter approach would seemingly work just fine for an intermediary that has already established a domain-based reputation through DKIM signing all mail it handles or rewriting the From header to use its domain rather than the domain of the original sender. For those intermediaries that don't leave fingerprints on mail they handle beyond Received headers, they'll likely only have an IP-based reputation and so their domain-based seals may be harder to automatically match to the traffic seen. Not impossible given enough resources, but that's pretty much true for everything we say about tracking ARC reputation. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000d1a24f05cc1c1f88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 16, 2021 at 2:15 AM John Levine <johnl@taugh.com> wrote:
It a= ppears that Todd Herr=C2=A0 <todd.herr@valimail.com> said:
>=C2=A0 =C2=A0- If XD and XI are similar (by my definition of "simi= lar" based on how I
>=C2=A0 =C2=A0calculate sender domain reputation), then I know I can tru= st S to properly
>=C2=A0 =C2=A0seal X's mail, because the quality of X's mail is = the same whether it's
>=C2=A0 =C2=A0direct or indirect through S. ...

Oh. I see what you're saying.=C2=A0 I suppose it would work although it= 'd be hard to
tell from a perverse setup where S rejected all of the unaligned mail from = X
and a lazy programmer put a fake seal on everything.=C2=A0 I realize that&#= 39;s unlikely.

So here's my low(ish) tech counterapproach.=C2=A0 If a mail source has = a generally
good reputation, assume its ARC seals are real.=C2=A0 What's the downsi= de?


I suspect that any system designed to measure sig= ner/sealer reputation will likely rely on multiple data sets, simply becaus= e of a lack of uniformity on how identities are able to be established for = intermediaries.

Your counter approach=C2=A0would seemingly work just fin= e for an intermediary that has already established a domain-based reputatio= n through DKIM signing all mail it handles or rewriting the From header to = use its domain rather than the domain of the original sender. For those int= ermediaries that don't leave fingerprints on mail they handle beyond Re= ceived headers, they'll likely only have an IP-based reputation and so = their domain-based seals may be harder to automatically match to the traffi= c seen. Not impossible given enough resources, but that's pretty much t= rue for everything we say about tracking ARC reputation.
--

Todd Herr | = Technical Director, Standards and Ecosystem
= e: todd.herr@valimail.com
m: 703.220.4153

This email and all data transmitted with it contains confidential a= nd/or proprietary information intended solely for the use of individual(s) = authorized to receive it. If you are not an intended and authorized recipie= nt you are hereby notified of any use, disclosure, copying or distribution = of the information included in this transmission is prohibited and may be u= nlawful. Please immediately notify the sender by replying to this email and= then delete it from your system.

--000000000000d1a24f05cc1c1f88-- From nobody Thu Sep 16 12:14:03 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF843A08CF for ; Thu, 16 Sep 2021 12:14:00 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Dqj/3zj3; dkim=pass (2048-bit key) header.d=taugh.com header.b=c87OqoL7 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 qNGIiD6h4tXS for ; Thu, 16 Sep 2021 12:13:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 92DB33A08CC for ; Thu, 16 Sep 2021 12:13:54 -0700 (PDT) Received: (qmail 25187 invoked from network); 16 Sep 2021 19:13:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=6261.6143976e.k2109; bh=NMV/O5UBtqtlaYT207XcDvhBE/JOzhzyMEFHUbAeZVM=; b=Dqj/3zj3+92KGNMf9gEyQcsXwba4iShlBYFDyRCw5F0aWsZlwEvkYksN7WrzRZaxvG6uxBSDbnC2t+Lge8cxo/ER6oZgY9iEZ70oBj/+rDbOlz78+/2jWyWt1fAZn9w/5FADqEtwZa7o+ZrWvu//tNsuIjGB6ozlao0JB133i2o+d56EWSj4qyyDYCG0EuLdgCI87Bt6FIFQOuRxwvVdlUvO93tBnOSAPAh6unuYkr7WXtAmwCqwUgZoJCXoalJWukMbptCa07JS+/iLuguG9DuYmx5Ffmc0+gTk91regoU3NL36NDB/SH9BS8RjY2N4YiBpDVenk7+Wm3JFJUTQfg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=6261.6143976e.k2109; bh=NMV/O5UBtqtlaYT207XcDvhBE/JOzhzyMEFHUbAeZVM=; b=c87OqoL7sZRsLieeFCC7O1BzqBDPsaQbO4U+IyZ/9r/9C4aS2dZwzYA/6H8EN5ibEi3USqtVxkWp2Xx8M+40cNcT2WD34werKGTgdkmi45wUDQrZa/tR6qKIld6juLBbGtEnXk12b5PyXzgdz0ZFVfW7tikj5bDrfYcODU4McnagPrkxxOruukwklXYpOqwMOrt2FMOiaBg2iGXYCyJxZnwgFJI3Ch3uTB+je4COR3W7vw2I1WvbAsH7Lqwxr7Dff9BC7Wkfo9qRHNAR7t5L4G7fLuqMBZmh8yp4xOwMT5d5uWrwgGhfUATM0kagDsoy/Ub0SV85u9HRazFBLbkj4Q== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Sep 2021 19:13:50 -0000 Received: by ary.qy (Postfix, from userid 501) id EAAD3283408A; Thu, 16 Sep 2021 15:13:49 -0400 (EDT) Date: 16 Sep 2021 15:13:49 -0400 Message-Id: <20210916191349.EAAD3283408A@ary.qy> From: "John Levine" To: arc@ietf.org Cc: marc@marcbradshaw.net In-Reply-To: <11afacce-f677-4f5e-92b9-1fb80f0bab0e@beta.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] ARC anywhere X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 19:14:00 -0000 It appears that Marc Bradshaw said: >-=-=-=-=-=- > >This is how I approach reputation for ARC. We're just not seeing enough mail which is ARC sealed, modified, and >not from the top senders we all already know and have reputation for. The volume right now is so low it isn't >feasable to apply any automated reputation. This may be a chicken and egg thing. So how about my lazy guy approach: if a source has a good reputation, assume it's ARC seals are real. What's the downside? If the reputation is good, it is unlikely to be making naughty changes with or without ARC. R's, John From nobody Sat Sep 18 10:56:56 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEE83A1A89 for ; Sat, 18 Sep 2021 10:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 i98xUdwAePFM for ; Sat, 18 Sep 2021 10:56:49 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 94C273A1A86 for ; Sat, 18 Sep 2021 10:56:49 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id m11so16423645ioo.6 for ; Sat, 18 Sep 2021 10:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aprT8n7RW4jAJU/1iYchSJzYgAcYHVDsWVwS84g7lYI=; b=f4gF4DT0XzRIXs1uhtp7hLlEKq4+FmuOeZegKHhIat79SOiBpNT91NXejEqnA65rR8 w5ThlMgAwyIF/q563B8lZsAM8q8WorLH7j6OpaTaVHA0bSCjecdKfTFGMxOKuYqYYjXH xuqIuNuFsWKtcqELEXs1WMP/aiyob90C2YWoqTzniLNN6a7z28XgQ/pxsfd+oCJOkdze O6OyGpYn3w9ttK4ba8/r61OiMScuVf1VohGyiVXN1IhK42nnlphS00YKMfJToBCdFO5W Rfv8dPY6IXjsUQuF1/LOv65dc7bXLM6TcQ2qqcoDms8jvB5Orn2+Ey1RowXPJWUGekzn Ezsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aprT8n7RW4jAJU/1iYchSJzYgAcYHVDsWVwS84g7lYI=; b=wfyCxodCabcy+mDRXf2tFEsj63M0he4tV16rDoWLg/LjfJJgADGSvFNxahOYi2GokX FhEU4bVFswKXQ4EZCOQJDxFxh7+gVEiWhszd7JXBIdM4ogGDGmNWA0VbyITBZiVp4sbP lE1hHWdouzk0KdV54cFJyQhi+7a6tnwRyj5TVNTXMLMs1CBB4jXEfmeVWAQHVjETGPrS NzBSoM/vl02dsLQ17phmQB0ctyhInPVzW3xGgRiEUkUFtZMd1TFLr2nHcskVEvDuciGK ICFW3q2gvFhR4dQIgc6NCbBjfLXI4wlZjDhCQbS2BEwCr1DiSxZ2IuL5fktIXz+D1/LJ o5fg== X-Gm-Message-State: AOAM533x5SBn/0lMkCKkioifsAbwVqkUtGO3y5I1K20l228b1gDvd+I7 bKO8mfTGF9+LOpgzUQfMO3vD0x9T/asxyBaIrU2G66PCANc= X-Google-Smtp-Source: ABdhPJyqQsijqpIUGhnQrDEs8iPnqkGSxq3FXFs+EZtH5QCrxmS8r2/OpQPjpql3iMyiPZVDsQQqBMtIi6dUlH4oCs0= X-Received: by 2002:a02:9082:: with SMTP id x2mr13539111jaf.44.1631987807954; Sat, 18 Sep 2021 10:56:47 -0700 (PDT) MIME-Version: 1.0 References: <20210913193220.9938527CD4BF@ary.qy> <11afacce-f677-4f5e-92b9-1fb80f0bab0e@beta.fastmail.com> In-Reply-To: <11afacce-f677-4f5e-92b9-1fb80f0bab0e@beta.fastmail.com> From: Wei Chuang Date: Sat, 18 Sep 2021 10:56:33 -0700 Message-ID: To: Marc Bradshaw Cc: arc@ietf.org Content-Type: multipart/alternative; boundary="00000000000092943b05cc48c5e7" Archived-At: Subject: Re: [arc] ARC path header X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2021 17:56:55 -0000 --00000000000092943b05cc48c5e7 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 16, 2021 at 5:18 AM Marc Bradshaw via Arc wrote: > This is how I approach reputation for ARC. We're just not seeing enough > mail which is ARC sealed, modified, and not from the top senders we all > already know and have reputation for. The volume right now is so low it > isn't feasable to apply any automated reputation. This may be a chicken and > egg thing. > What ARC traffic I see is from a few already very well known senders and then a modest sized tail whose volume drops off very quickly. Agree that the low traffic rate in the tail will already make using automated reputation difficult. I worry the proposal will further segment that small traffic volume. Another issue I see is that while ARC is meant to override mistaken DMARC policy enforcement, if ARC reputation has insufficient volume to be applied, it may fall back to DMARC and some reject policy is applied. Such a domain may not be able to establish sufficient traffic volume to change its reputation. -Wei > On Wed, 15 Sep 2021, at 3:03 AM, Todd Herr via Arc wrote: > > On Mon, Sep 13, 2021 at 3:32 PM John Levine via Arc wrote: > > > One time I asked one of the authors of ARC why they don't just > whitelist mail from known mailing lists. They said the problem is that > lists do lousy spam filtering, and legit lists leak bursts of spam all > the time. For example, spammer steals someone's address book and > starts sending spam to a mailing list with a From: that happens to be > a subscriber. Most lists only check the From: address and let the spam > through. ARC lets the final recpient peek back and see whether a > message was DMARC aligned when it arrived at the list. Real mail from > the sender would be, the spam wouldn't. > > > This kind of thing makes me think that people are tying signer/sealer > reputation to the quality of mail that they're signing and forwarding, and > I just don't understand that approach. > > To my mind, signer/sealer reputation should be determined based on whether > or not one feels it can trust the authentication results being reported by > the signer/sealer. In private conversations with some mailbox providers, > I've proposed an idea that signer reputation can be measured by comparing > the reputation earned by authenticated indirect mail flows to authenticated > direct mail flows. At a rudimentary level, that would look like this: > > - Domain D sends some quantity of mail directly to Mailbox Provider M, > and D earns a reputation for its authenticated mail; call this R1 > - ARC signer/sealer S is an intermediary on some quantity of mail that > originated at D and is ultimately delivered to M, and D earns a reputation > for mail that was successfully authenticated as reported by S; call this R2 > - If and only if R1 and R2 are reasonably similar, then S can be > trusted to have reported correct authentication results > > This idea was shot down because it wouldn't scale, due to too many paths > to keep track of, what with the endless number of originating domains that > a large mailbox provider might see, but I still believe in the idea that > signer/sealer reputation should be based on the trustworthiness of its ARC > Header Sets and nothing else. I just haven't figured out a good way to > instrument and measure that trustworthiness. > > Am I misunderstanding the discussion here, or am I wildy off base? > > -- > > > *Todd Herr * | Technical Director, Standards and Ecosystem > *e:* todd.herr@valimail.com > *m:* 703.220.4153 <(703)%20220-4153> > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > > > -- > > Marc Bradshaw > marcbradshaw.net | @marcbradshaw > > > -- > Arc mailing list > Arc@ietf.org > https://www.ietf.org/mailman/listinfo/arc > --00000000000092943b05cc48c5e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 16, 2021 at 5:18 AM Marc = Bradshaw via Arc <arc@ietf.org> w= rote:
This is how I approach reputation for ARC. We're just not seeing= enough mail which is ARC sealed, modified, and not from the top senders we= all already know and have reputation for. The volume right now is so low i= t isn't feasable to apply any automated reputation. This may be a chick= en and egg thing.

What ARC = traffic I see is from a few already very well known senders and then a mode= st sized tail whose volume drops off very quickly.=C2=A0 Agree that=C2=A0th= e low=C2=A0traffic rate in the tail will already make using automated reput= ation difficult.=C2=A0 I worry the proposal will further segment that small= traffic volume.=C2=A0 Another issue I see is that while ARC is meant to ov= erride mistaken DMARC policy enforcement,=C2=A0if ARC reputation has insuff= icient volume to be applied, it may fall back to DMARC and some reject poli= cy is applied.=C2=A0 Such a domain may not be able to establish sufficient = traffic volume to change its reputation.=C2=A0

-We= i
=C2=A0
<= div>
On Wed, 15 Sep 2021, at 3:03 AM, Todd Herr via Arc wrote:
On Mon, Sep 13, 20= 21 at 3:32 PM John Levine via Arc <arc@ietf.org> wrote:
=

One time I asked one of the= authors of ARC why they don't just
whitelist mail from = known mailing lists. They said the problem is that
lists do = lousy spam filtering, and legit lists leak bursts of spam all
the time. For example, spammer steals someone's address book and
<= /div>
starts sending spam to a mailing list with a From: that happens = to be
a subscriber. Most lists only check the From: address = and let the spam
through. ARC lets the final recpient peek b= ack and see whether a
message was DMARC aligned when it arri= ved at the list. Real mail from
the sender would be, the spa= m wouldn't.

This kind of thing makes me think that people are ty= ing signer/sealer reputation to the quality of mail that they're signin= g and forwarding, and I just don't understand that approach.
<= div style=3D"font-family:tahoma,sans-serif">
To my mind, signer/sealer reputation should be dete= rmined based on whether or not one feels it can trust the authentication re= sults being reported by the signer/sealer. In private conversations with so= me mailbox providers, I've proposed an idea that signer reputation can = be measured by comparing the reputation earned by authenticated indirect ma= il flows to authenticated direct mail flows. At a rudimentary level, that w= ould look like this:
=
  • Domain D sends some quantity of mail directly to Mailbox Provider M= , and D earns a reputation for its authenticated mail; call this R1
  • ARC signer/sealer S is an intermediary on some quantity of mail that o= riginated at D and is ultimately delivered to M, and D earns a reputation f= or mail that was successfully authenticated as reported by S; call this R2<= br>
  • If and only if R1 and R2 are reasonably similar, then S can be = trusted to have reported correct authentication results
T= his idea was shot down because it wouldn't scale, due to too many paths= to keep track of, what with the endless number of originating domains that= a large mailbox provider might see, but I still believe in the idea that s= igner/sealer reputation should be based on the trustworthiness of its ARC H= eader Sets and nothing else. I just haven't figured out a good way to i= nstrument and measure that trustworthiness.

Am= I misunderstanding the discussion here, or am I wildy off base?
<= /div>

--


<= /p>

Todd Herr | Technical Director, Standards and Ecosystem

= Th= is email and all data transmitted with it contains confidential and/or prop= rietary information intended solely for the use of individual(s) authorized= to receive it. If you are not an intended and authorized recipient you are= hereby notified of any use, disclosure, copying or distribution of the inf= ormation included in this transmission is prohibited and may be unlawful. P= lease immediately notify the sender by replying to this email and then dele= te it from your system.

--=C2=A0
Arc mailing list


--

=C2=A0 Marc Bradshaw
=C2=A0= =C2=A0marcbradshaw.n= et |=C2=A0@marcbradshaw

--
Arc mailing list
Arc@ietf.org
https://www.ietf.org/mailman/listinfo/arc
--00000000000092943b05cc48c5e7-- From nobody Mon Sep 20 10:48:48 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448353A0E3C for ; Mon, 20 Sep 2021 10:48:46 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 pqp9GWnVJ5Xp for ; Mon, 20 Sep 2021 10:48:40 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2AE623A0E3B for ; Mon, 20 Sep 2021 10:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1632160113; bh=hPy0kqlbp7BpoqH99A9Ok+3qfr4DrcTiNoVdJ1jGptg=; l=587; h=To:References:From:Date:In-Reply-To; b=BmyBlN8M1Q4J0lF+XNaARUnhiolEFa6A2S96gX0VtUxygYrbT3Cyp5sTw1MTUZ7uJ Zu10TWmxNYFnJDluvt/jCs1kA7UJadudgC5fAT3nlWvASWP3eyOjm1d0B2kK1f8b1N +fcBkA7QtAKjnfU0CJtmnHf6Df8pffAJHTbzzsQMt3X1oyQSq344bgHNFBNJI Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CF.000000006148C971.00007840; Mon, 20 Sep 2021 19:48:33 +0200 To: arc@ietf.org References: <20210912174804.BB7E527C37B9@ary.qy> From: Alessandro Vesely Message-ID: <3c7e9570-4faf-35ff-c9dc-846a1b405a54@tana.it> Date: Mon, 20 Sep 2021 19:48:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arc] Replay attacks (was Re: ARC path header) X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 17:48:46 -0000 On Thu 16/Sep/2021 14:12:24 +0200 Marc Bradshaw via Arc wrote: > A good forwarder can and will forward bad messages, this isn't about the > quality of mail, it is about whether or not we believe that an intermediary > which modifies messages makes only reasonable and legitimate modifications. For a limited set of modifications and author's signatures following DKIM's Recommended Signature Content, it is feasible to undo the modifications and check the original author's signature: https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform Best Ale -- From nobody Mon Sep 20 22:32:18 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417053A2242 for ; Mon, 20 Sep 2021 22:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 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, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=IKmKqnK4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e41gXU2B 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 PVWk3aTCFyPi for ; Mon, 20 Sep 2021 22:32:13 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40A13A2240 for ; Mon, 20 Sep 2021 22:32:12 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3080A3201DDC for ; Tue, 21 Sep 2021 01:32:11 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute2.internal (MEProxy); Tue, 21 Sep 2021 01:32:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=gtnm5OF dXz+DrFFcFaNqEJLQmQ4Ft3j0djXbGi/GuYA=; b=IKmKqnK4BoTMV9KzE6rOSce Zz4colfqCF1Ee+Ij+6vi77tuykTik9Ik1SZ/L4cetjkxFmV9z4ukxT5Mg1z3EiBZ 5UZIhn9zmNXM14arZR2U5ZvQsc7U+UZA75g3734KpRhRfttzaEC4xiw2T2XEIaZ6 bD00qNg3hshp8rHf9CuNHNJGyHCrzlqDIXvG3VuQpqD+hL4eacZFwsuq6/b9vvA1 c/G31eiNd98TVx3/4oOdGB9MKrUzn1hH7JQC3drzlqNQOvBsWmq0nMJ8a9XeSuNf NeBl1IBDJvZEKWfT1vv3EqMtj3X1R9o+z486EqHhKWs4GqumpSoWm/+Q+e654Pg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gtnm5O FdXz+DrFFcFaNqEJLQmQ4Ft3j0djXbGi/GuYA=; b=e41gXU2BSjXbDshBrge1R2 RujWkGCSuOWCUM64Ytn+lpyfDfwpqpYTvnvNX/eHwNS9u1VUyGWGpiBsAwwO8j1u HR0BA5z1u1/G0SWuHJ5+ye00uHRprw6LzIVZSsUDwm9T9MawwkzdzLmkhYznzlIC E8LBOM3RPmjpkM4kGS3nViTdb/x07+A1j2GJU1QXnse9EwmIYO9mDKfjTsGMtO1Z FtGDtp+CUPZUwdUHyvr2uQRlO+ZLcR7e7zbBVSB/5a8py1LqLJ219hahfHMeDxQJ AzoYtIX/WiYiO2ZRP/0+8Tp+2RecmwVyb5wicH9SdE+kma2zdaVkRrVmSc241xVQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeifedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthfkmhhgffhomhgrihhnucdlfe dtmdenucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedf ofgrrhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnh gvtheqnecuggftrfgrthhtvghrnhepgfegheelleeuieetheetkeekjeevtdduvdevfeek feefvdeiuefffeeiheduhffgnecuffhomhgrihhnpehivghtfhdrohhrghdpmhgrrhgtsg hrrggushhhrgifrdhnvghtpdhtfihithhtvghrrdgtohhmnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhgtsehmrghrtggsrhgrughshh grfidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7F6711EE006E; Tue, 21 Sep 2021 01:32:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1291-gc66fc0a3a2-fm-20210913.001-gc66fc0a3 Mime-Version: 1.0 Message-Id: In-Reply-To: <3c7e9570-4faf-35ff-c9dc-846a1b405a54@tana.it> References: <20210912174804.BB7E527C37B9@ary.qy> <3c7e9570-4faf-35ff-c9dc-846a1b405a54@tana.it> Date: Tue, 21 Sep 2021 15:31:50 +1000 From: "Marc Bradshaw" To: arc@ietf.org Content-Type: multipart/alternative; boundary=b9f4066e63694f21a6613d28745948ed Archived-At: Subject: Re: [arc] Replay attacks (was Re: ARC path header) X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2021 05:32:18 -0000 --b9f4066e63694f21a6613d28745948ed Content-Type: text/plain I believe that draft-vesely-dmarc-mlm-transform needs some work before it can be applied at scale. The intent is good, but there are some issues. However this isn't the forum to discuss those. The issue still remains, a large number of good forwarders will make modifications outside of those in that draft, but those may still be legitimate modifications. On Tue, 21 Sep 2021, at 3:48 AM, Alessandro Vesely via Arc wrote: > On Thu 16/Sep/2021 14:12:24 +0200 Marc Bradshaw via Arc wrote: > > A good forwarder can and will forward bad messages, this isn't about the > > quality of mail, it is about whether or not we believe that an intermediary > > which modifies messages makes only reasonable and legitimate modifications. > > For a limited set of modifications and author's signatures following DKIM's > Recommended Signature Content, it is feasible to undo the modifications and > check the original author's signature: > https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform > > > -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --b9f4066e63694f21a6613d28745948ed Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I believe that = draft-vesely-dmarc-mlm-transform needs some work before it can be applie= d at scale. The intent is good, but there are some issues. However this = isn't the forum to discuss those. The issue still remains, a large numbe= r of good forwarders will make modifications outside of those in that dr= aft, but those may still be legitimate modifications.

=
On Tue, 21 Sep 2021, at 3:48 AM, Alessandro Vesely via Arc wr= ote:
On Thu= 16/Sep/2021 14:12:24 +0200 Marc Bradshaw via Arc wrote:
&= gt; A good forwarder can and will forward bad messages, this isn't about= the 
> quality of mail, it is about whether or no= t we believe that an intermediary 
> which modifie= s messages makes only reasonable and legitimate modifications.
=

For a limited set of modifications and author's sign= atures following DKIM's 
Recommended Signature Conten= t, it is feasible to undo the modifications and 
chec= k the original author's signature:
=




--

  Marc Bradsh= aw
  marcbradshaw.net | @marcbradshaw


<= /html> --b9f4066e63694f21a6613d28745948ed-- From nobody Fri Sep 24 12:12:35 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12D53A120F for ; Fri, 24 Sep 2021 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 ngEfg6uMGJCg for ; Fri, 24 Sep 2021 12:12:27 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 897D53A120D for ; Fri, 24 Sep 2021 12:12:27 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id f130so29197914qke.6 for ; Fri, 24 Sep 2021 12:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=qNZXfBNLoGzk86j/5O989RF/2gxfvKnAyIg+dMqBAH4=; b=X8yEDjv4bQIwQt/c+oI5aZP96FSdmDdVMtMmdpt7KjXb13ANTOvb5xdiQbHQKykpyO twfqEHDI2hZl9ZN038CZ7IP3X8AfEzbyVwMzJ0bcZcJOBKiCLBFUyquJlnl9SYxxBkZZ wtHc0UahwQpIsUObk/+3SWuSAmkoBWKKSDWtBP8lPNkHTdTxxibHyHgc2y7agh6acfJ9 2Syc7ZqwGie3EJODiJ9IVgOn8rGmAw5+ShwKJL1kGOlKCi5/MErnVexSFQ8ZYogHOClT hqzwoQtyInqQXCsodzr5KHPqCWYihOW4p42F5oZg8F2ws16IEMveDvUkMqgLeiRWG6B5 VfHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qNZXfBNLoGzk86j/5O989RF/2gxfvKnAyIg+dMqBAH4=; b=tR5ISgWCy22tlIxEFu6Q5hM/ow1Jx8KbyKM3Wz8CB3ZZbZ8KrbJsxT/u/BJPocrxQ6 v28/LONYPHDMS3pT3y/i9A+i6yzFBsqq7yOE5dmF3jASTHC+yhhsFimF90tdgVqMS4s3 OIXMdD0BR3ncVfaYqdiRoiKDJoWHRLd57P9+4ngNopbpSC5fJpM5udn4v0MAZxnWgtpy zAbq6zi2AOeuVHQsR3czJG8+dFUjqUSbHBb/NECZoTqM8VOsZoDN5jVxpmjdEr5QQoOE XRRJuDRO+0Ck4AJuCKzlvFXo7jlZVzymHdwBQgyEzi80QbVD+msKdrkkjG9M//KFE0Z2 5AGw== X-Gm-Message-State: AOAM533+mro0bmBn6OQzJV8ymjMQ7+JdlIaUvXb7EsuvoDZeCUX9B06o di+7WL4ihtJET3gcvwaRxBh9TB+rz1Ai+IPY3FJF6aAoopw= X-Google-Smtp-Source: ABdhPJy8sXdLuoT8QCKEyXX14hwHjthCw4peRq3T/F9nru2EiF5c04+hv4MW8WAJZ8vI5rSED3zSr49OA9k8PQRYbfE= X-Received: by 2002:a37:b142:: with SMTP id a63mr12211831qkf.393.1632510746087; Fri, 24 Sep 2021 12:12:26 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Fri, 24 Sep 2021 15:12:10 -0400 Message-ID: To: arc@ietf.org Content-Type: multipart/alternative; boundary="0000000000001ce49505ccc287e0" Archived-At: Subject: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2021 19:12:33 -0000 --0000000000001ce49505ccc287e0 Content-Type: text/plain; charset="UTF-8" As a result of an internal conversation at my employer on the topic of trusting ARC header sets, I would like to throw an idea out there for the list membership to chew on. "If you accept a message from an intermediary, you trust that any ARC header set inserted by that intermediary that passes your validation checks contains information that is true and correct." This makes no value judgement regarding the quality of the mail that caused the ARC header set to be inserted; it only stipulates that if you accept a message from the intermediary foo.com and find an ARC header set inserted by foo.com, if that ARC header set validates then you trust that the information contained in the ARC header set is true. You can then use the information in the ARC header set to aid in your message disposition decision. Deciding whether or not to trust ARC header sets is, to my mind, the chief hurdle to widespread ARC adoption. This provides a simple way to make that decision, and it's a decision that's no more permanent than the decision to accept the message itself from the intermediary. Appreciate any feedback y'all might have. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000001ce49505ccc287e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a result of an internal conversation at my employer on the to= pic of trusting ARC header sets, I would like to throw an idea out there fo= r the list membership to chew on.

"If you accept a message=C2=A0from an int= ermediary, you trust that any ARC header set inserted by that intermediary = that passes your validation checks contains information that is true and co= rrect."

This m= akes no value judgement regarding the quality of the mail that caused the A= RC header set to be inserted; it only stipulates that if you accept a messa= ge from the intermediary foo.com and find an= ARC header set inserted by foo.com, if that= ARC header set validates then you trust that the information contained in = the ARC header set is true. You can then use the information in the ARC hea= der set to aid in your message disposition decision.

=
Deciding whether or not to trust ARC header sets is, to my mind, the c= hief hurdle to widespread ARC adoption. This provides a simple way to make = that decision, and it's a decision that's no more permanent than th= e decision to accept the message itself from the intermediary.
=
<= br>
Appreciate any feedback y'all might have.

--

Todd Herr | Technical Director, Standards and E= cosystem
m: 703.220.4153

This email and all data trans= mitted with it contains confidential and/or proprietary information intende= d solely for the use of individual(s) authorized to receive it. If you are = not an intended and authorized recipient you are hereby notified of any use= , disclosure, copying or distribution of the information included in this t= ransmission is prohibited and may be unlawful. Please immediately notify th= e sender by replying to this email and then delete it from your system.

--0000000000001ce49505ccc287e0-- From nobody Sat Sep 25 18:05:27 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06A03A10A8 for ; Sat, 25 Sep 2021 18:05:24 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Gmcelib/; dkim=pass (2048-bit key) header.d=taugh.com header.b=MP7ZUw63 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 AdU6juS2u8kU for ; Sat, 25 Sep 2021 18:05:19 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 143EB3A10B3 for ; Sat, 25 Sep 2021 18:05:18 -0700 (PDT) Received: (qmail 18504 invoked from network); 26 Sep 2021 01:05:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=4846.614fc74d.k2109; bh=z4mkj2rxGVf0y8A6jt2InEb1HJC5pLZcgCPq6BAGFGU=; b=Gmcelib/rdLEso91nUI87K/KlPOisJONQjKalE4o6F8BlR/G2NGce5ErNMBEIb5C4wvOR4V7s0CMPdQfTYaB7cr6kzJF3SgoJZQ8eHNHoRNWloiaemOcBIstWc2CaadjlzBUIXmdIUdN5oKcP7OlxmvRwQe6STGqfAnSjddAtpORYNipKGq05Z/qYpfT8hwa/3TZUAxr7fHRtl7LhEuoQMSh3vGDb51jbULY2OLB4ESCYYFn734b5KzIxc5zt429dv/v0TdziAxO34fyS3B4ggaMa0L917HK2FqJCU2LtJjz3dlxRKEg64newsd90lQvgGlxRFAR16t/QQYfzXmsBQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=4846.614fc74d.k2109; bh=z4mkj2rxGVf0y8A6jt2InEb1HJC5pLZcgCPq6BAGFGU=; b=MP7ZUw63WJF+jD1tzyLd79yuS23bXYEovAOMn8O19lt3ajZqwkwN8LJgILkvd5HAR2R2JdrXaVQ2Upx1zwzLFjDWx/L9i2Ya3yF0KhdcGaNAmBwYjy/LaI6tRaU51qAc0YpO6RUBELUl6VtnwHlWhtoVPzwnb5hjmtjUmh0sZzphyz3Yybk8v6io8GyVB1GCi4q4LDvWRUAOGYZZ9DwRmA3jNM/MHMQqBta0ds1/80tJhKQefWAB5EJCZ5AZPoszLOHo9guLbKngAsh1QERqOrAAcYsJxMdA5PwSNVNCInyjOzStt/Ny8Ds2dDIANfPgYB2kgkExUh4A767YrAcFFg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 26 Sep 2021 01:05:16 -0000 Received: by ary.qy (Postfix, from userid 501) id 3678A2957399; Sat, 25 Sep 2021 21:05:16 -0400 (EDT) Date: 25 Sep 2021 21:05:16 -0400 Message-Id: <20210926010516.3678A2957399@ary.qy> From: "John Levine" To: arc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 01:05:25 -0000 It appears that Todd Herr said: >-=-=-=-=-=- > >As a result of an internal conversation at my employer on the topic of >trusting ARC header sets, I would like to throw an idea out there for the >list membership to chew on. > >"If you accept a message from an intermediary, you trust that any ARC >header set inserted by that intermediary that passes your validation checks >contains information that is true and correct." I think I agree although it depends on what you mean by "accept". Assuming it's something along the lines of messages that you plan to deliver unless they have some other spam sign, that seems reasonable. Another way to look at it is that anyone who would go to the effort of adding fake ARC seals to try to evade spam filters will be doing other bad stuff so you'll catch them soon enough. R's, John From nobody Mon Sep 27 01:41:58 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D933A08C4 for ; Mon, 27 Sep 2021 01:41:55 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 YV2I5DA_zFbY for ; Mon, 27 Sep 2021 01:41:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 29FD83A08B8 for ; Mon, 27 Sep 2021 01:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1632732105; bh=t92rSqDKvCK0REHQXcGfRnavueIs6tyA0QVFqSZSuEI=; l=1076; h=To:References:From:Date:In-Reply-To; b=C5gV0BPGmfP97j3fBZaiTwKuPSpshmiMNn27/M6TFbkPIsqj5IpbQvO+R2FzBzp+/ kxZ+lhebHhviYYCBdAWYF50tSj/S5EfczFBGIezkkb1R2UNvh3VjhW7v3I6PJxqazx Irx0V8t9hmznYM8AypLM0A0LcxDPMpXlb8r3CADlWTuYZK6waEek41vwZTAze Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [192.168.1.108] (host-95-232-196-128.retail.telecomitalia.it [95.232.196.128]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.00000000615183C9.00007742; Mon, 27 Sep 2021 10:41:45 +0200 To: arc@ietf.org References: <20210926010516.3678A2957399@ary.qy> From: Alessandro Vesely Message-ID: <6a99c29d-e418-416d-ce5b-d59441a8c905@tana.it> Date: Mon, 27 Sep 2021 10:41:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210926010516.3678A2957399@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2021 08:41:56 -0000 On Sun 26/Sep/2021 03:05:16 +0200 John Levine Via Arc wrote: > It appears that Todd Herr said: >> -=-=-=-=-=- >> >> As a result of an internal conversation at my employer on the topic of >> trusting ARC header sets, I would like to throw an idea out there for the >> list membership to chew on. >> >> "If you accept a message from an intermediary, you trust that any ARC >> header set inserted by that intermediary that passes your validation checks >> contains information that is true and correct." > > I think I agree although it depends on what you mean by "accept". Assuming it's > something along the lines of messages that you plan to deliver unless they have > some other spam sign, that seems reasonable. Except that phishing messages, formally from BANK.example, with failed DKIM and SPF validation, are going to make it to the user's INBOX, despite the p=reject mark the bank put on their record. That position relegates both protocols, DMARC and ARC, to the rank of futile programming exercises. Best Ale -- From nobody Mon Sep 27 12:47:24 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEE03A1714 for ; Mon, 27 Sep 2021 12:47:21 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=gTBXZrOX; dkim=pass (2048-bit key) header.d=taugh.com header.b=a6cfQa4I 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 fFuCKiRtnZfa for ; Mon, 27 Sep 2021 12:47:15 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 75B5A3A1712 for ; Mon, 27 Sep 2021 12:47:15 -0700 (PDT) Received: (qmail 48665 invoked from network); 27 Sep 2021 19:47:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=be15.61521fc2.k2109; bh=/AYyzistx1UgTdMvCkckx+2CAWomo6/ueWVTEoYqoOY=; b=gTBXZrOXHT5euH4g3EbUrGSNMj2LK31Cy3MUfdjpie6mwyDVGWby2GWuqhD2ziPfpj+8L1hELl67Ynww8hVmuUMsUgdwT9h8vHiGzVO4SEle10bywUrA9FfMBrq9BJednSTdItnmTIkdmshs4jkp+B330Z4mnZu8QqKvz2CNQNfKR9pTs0DWMS3PU5JxV9JedstN/gD33oudc5o95AaoGPHmDNrhko3vYCE/BbAzLKYIO72n4cw+XLyY9t/5nPNX92To4szsMOBTN6mWn2fUGAd1q+PDjMWy9A/pUneF4ySYAk3gAxgbTWPWhrz7kuxnduG9udsHxxhB0YubrgaKVQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=be15.61521fc2.k2109; bh=/AYyzistx1UgTdMvCkckx+2CAWomo6/ueWVTEoYqoOY=; b=a6cfQa4IWeZDMQFK0VWOyly7mQe+wRWdJkOKiKSHtURLkcu62MS+58JOdD7tkeE7KQMUjkULxdiJQk9VEQ3vd6+IjgiQjXiajNTE515gqLWDU5WnSzbxw7jvMxNkeWyCc+X2SYXV0dSfLoBt9+x6VxP9mjairMIsMqOQm1prsljtdqp8luz7+yk2m6iXdLYX53NR8eE9r6JgI+UJvFj4o0gyEshIfD/JQUnsxyYcW0YCEwkoJMkv+WrgnZcJ9XsVWM42Ob5Dy/IBvOSFkYU2AK7ZAgQC/qRoUT8dx5wWQ/+E0q6JtOkycXAFOgLSFRFh5TBJW7AUzLI7XomTD3ZTlA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 27 Sep 2021 19:47:13 -0000 Received: by ary.qy (Postfix, from userid 501) id 2F31029652FB; Mon, 27 Sep 2021 15:47:11 -0400 (EDT) Date: 27 Sep 2021 15:47:11 -0400 Message-Id: <20210927194713.2F31029652FB@ary.qy> From: "John Levine" To: arc@ietf.org Cc: vesely@tana.it In-Reply-To: <6a99c29d-e418-416d-ce5b-d59441a8c905@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2021 19:47:22 -0000 It appears that Alessandro Vesely said: >>> "If you accept a message from an intermediary, you trust that any ARC >>> header set inserted by that intermediary that passes your validation checks >>> contains information that is true and correct." >> >> I think I agree although it depends on what you mean by "accept". Assuming it's >> something along the lines of messages that you plan to deliver unless they have >> some other spam sign, that seems reasonable. > >Except that phishing messages, formally from BANK.example, with failed >DKIM and SPF validation, are going to make it to the user's INBOX, Why do you think so? If someone sends a phish to a mailing list which adds genuine ARC headers, those headers will record that the phish failed DMARC alignment when it arrived at the list, and receivers can filter appropriately. Surely we don't have to explain that valid ARC doesn't mean that you always deliver a message, any more than valid DKIM or aligned DMARC does. R's, JOhn From nobody Tue Sep 28 01:46:15 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AF53A24AC for ; Tue, 28 Sep 2021 01:46:13 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 BT-dju3Frw5V for ; Tue, 28 Sep 2021 01:46:07 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 923EE3A24AB for ; Tue, 28 Sep 2021 01:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1632818761; bh=WxD8c5KywjR2QooH/Su3vi9fewUuI9IMJpy1eRcF8o4=; l=1824; h=To:References:From:Date:In-Reply-To; b=AdAE+sTzkDzmpeZa8FmJ9ROlNHDwivV4qBtCjrQwtRXK3/PtiqpVwkFNqU7Gh7QTF 3IgE6hyQbcdovEQ1SEjLeWpBwoowpk3JH78joKt9QWvIYJnL3D+0bSSDD4FZfahjLH PEapgyIOva0C+qNjzo11XVXyyuTVqB3gipH8U9VtKe+XI7p7Qu2UKMwkPBtHg Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [192.168.1.108] (host-95-232-196-128.retail.telecomitalia.it [95.232.196.128]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.000000006152D649.000069DC; Tue, 28 Sep 2021 10:46:01 +0200 To: John Levine , arc@ietf.org References: <20210927194713.2F31029652FB@ary.qy> From: Alessandro Vesely Message-ID: <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> Date: Tue, 28 Sep 2021 10:46:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210927194713.2F31029652FB@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2021 08:46:13 -0000 On Mon 27/Sep/2021 21:47:11 +0200 John Levine Via Arc wrote: > It appears that Alessandro Vesely said: >>>> "If you accept a message from an intermediary, you trust that any ARC >>>> header set inserted by that intermediary that passes your validation checks >>>> contains information that is true and correct." >>> >>> I think I agree although it depends on what you mean by "accept". Assuming it's >>> something along the lines of messages that you plan to deliver unless they have >>> some other spam sign, that seems reasonable. >> >> Except that phishing messages, formally from BANK.example, with failed >> DKIM and SPF validation, are going to make it to the user's INBOX, > > Why do you think so? > > If someone sends a phish to a mailing list which adds genuine ARC headers, > those headers will record that the phish failed DMARC alignment when it > arrived at the list, and receivers can filter appropriately. I was thinking of someone forging a phish and sending it directly to the victim. The phish has an invalid DKIM signature by BANK.example and a valid ARC set which says the BANK signature was valid when it reached the forwarder. Fake assertions about SPF, forged Received: and the like, possibly also an X-MIME-Autoconverted or similar hint at what might have invalidated DKIM are all in place. > Surely we don't have to explain that valid ARC doesn't mean that you always > deliver a message, any more than valid DKIM or aligned DMARC does. Right, that phish must not be delivered. However, the message was accepted by an intermediary, and since the ARC header set inserted by that intermediary passed your validation checks, you automatically trust it. On what element would you base, then, the decision to not deliver it? Best Ale -- From nobody Tue Sep 28 05:25:34 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0833A2BA3 for ; Tue, 28 Sep 2021 05:25:32 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=uIjyEKa9; dkim=pass (2048-bit key) header.d=taugh.com header.b=w1FnlObx 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 xaxucEIWiHnT for ; Tue, 28 Sep 2021 05:25:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 CEAD93A2B9D for ; Tue, 28 Sep 2021 05:25:26 -0700 (PDT) Received: (qmail 29674 invoked from network); 28 Sep 2021 12:25:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=73e6.615309b4.k2109; bh=1S7C13qY2SAgge5FYWCam0hvIg8Pwh8QuZns/OwkRb8=; b=uIjyEKa9s6ZAiXi7NHyr9VtGBPQOkeW9fI/1DmxakDdhDn7Saxtn1xYAwfibzcAbeT5xnOxuWB+ZEexIL6KhTasfTYjX1V/I3NyP6qk3A0VpQnCxO8xCd575si8y+J9NDiAjNhLh8O4tWnwXN/dohH9vM1hXluAD/0iHP+9dgtCVusTBb2Vz8SvWMH1l0AulggDsTXO5PG856Dmx2eS2E/WNdcaEqhwv8x2OA5FH0kQR3SUwBdqwluVGK3+/zetDlgMlCj8qRVCRJfBaraCH0KcGVe2eUTzQzl5btM2dx9CmV0cNZPRuN+Blvt4MnJ7GeqKLq+/XyL6bEz8Y9Eqbhg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=73e6.615309b4.k2109; bh=1S7C13qY2SAgge5FYWCam0hvIg8Pwh8QuZns/OwkRb8=; b=w1FnlObxvqyiHv/VSUth+ZmoTCX+nW+7gpzmohR7L9Ez/TVdSbJCl10yb+MgiH9VB5rUZNLrA7YzTmM93rhzBFiWh6ETLp9b5xPyj+1o9mEIWDsXCqyES/4f0xQ/so8VBdVDD3zSev0Pigiw8e6KDlpm+x+IOdQ0uFaLaW2MEqelcGjFkwqBuzUKnCIgrS73xFOkwHYme16XSVGxEBgd0Ms6Q/X/a1t1PB/E96c3i57+uBok11VTW/bv7S5hJnWXS2kh48mEOGKuji5f3d/sWjjXQxBKqFVMN9she4wkgUvCfRYR3NaF8zf2EjMBmyC1VgeU/JMxj0y+tdW/2OWh8g== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 28 Sep 2021 12:25:24 -0000 Received: by ary.qy (Postfix, from userid 501) id A7430296C54E; Tue, 28 Sep 2021 08:25:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 491B6296C530; Tue, 28 Sep 2021 08:25:23 -0400 (EDT) Date: 28 Sep 2021 08:25:23 -0400 Message-ID: <8ae28aac-fece-76bb-6fd8-f18ae2dc74cc@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , arc@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> References: <20210927194713.2F31029652FB@ary.qy> <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2021 12:25:33 -0000 >>> Except that phishing messages, formally from BANK.example, with failed >>> DKIM and SPF validation, are going to make it to the user's INBOX, >> >> Why do you think so? >> >> If someone sends a phish to a mailing list which adds genuine ARC headers, >> those headers will record that the phish failed DMARC alignment when it >> arrived at the list, and receivers can filter appropriately. > > I was thinking of someone forging a phish and sending it directly to the > victim. The phish has an invalid DKIM signature by BANK.example and a valid > ARC set which says the BANK signature was valid when it reached the > forwarder. As I said a few messages ago, if they do that, they are likely doing other bad stuff and the sender will have a bad reputation. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Sep 29 04:06:18 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99D73A0E11 for ; Wed, 29 Sep 2021 04:06:13 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 rTQX5bdqQE3N for ; Wed, 29 Sep 2021 04:06:08 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 529273A0E0A for ; Wed, 29 Sep 2021 04:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1632913562; bh=8BBfgg6fXpFaJydywsvrhbSgQZyaO5BNhyFuY1jNMKw=; l=1510; h=To:References:From:Date:In-Reply-To; b=DH/t3lftSeVWVso6pZPSirNnMFvLMFy+dpQMkJsMVFqXgAgUxT9hmPJI006Ntg+4n ld+qHNFMuS2glvThKwVYy+jmDr0iaAS1bOds2bd831vXCTJ7tE5cgNxdhTbeufzQWc AXTNuNgsBbnhHdkeHfY7QjxUAbUgjhh5yv1dTWxTVTxATL70/Fznj0tAac3Xf Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000006154489A.000054C9; Wed, 29 Sep 2021 13:06:02 +0200 To: John R Levine , arc@ietf.org References: <20210927194713.2F31029652FB@ary.qy> <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> <8ae28aac-fece-76bb-6fd8-f18ae2dc74cc@taugh.com> From: Alessandro Vesely Message-ID: <0735bbb9-2679-baa6-a53b-d8bd2bb5bc58@tana.it> Date: Wed, 29 Sep 2021 13:06:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8ae28aac-fece-76bb-6fd8-f18ae2dc74cc@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 11:06:14 -0000 On Tue 28/Sep/2021 14:25:23 +0200 John R Levine via Arc wrote: >>>> Except that phishing messages, formally from BANK.example, with failed >>>> DKIM and SPF validation, are going to make it to the user's INBOX, >>> >>> Why do you think so? >>> >>> If someone sends a phish to a mailing list which adds genuine ARC headers, >>> those headers will record that the phish failed DMARC alignment when it >>> arrived at the list, and receivers can filter appropriately. >> >> I was thinking of someone forging a phish and sending it directly to the >> victim.  The phish has an invalid DKIM signature by BANK.example and a valid >> ARC set which says the BANK signature was valid when it reached the forwarder. > > As I said a few messages ago, if they do that, they are likely doing other bad > stuff and the sender will have a bad reputation. That's an essential addition to the idea Todd proposed: "If you accept a message from an intermediary, you trust that any ARC header set inserted by that intermediary that passes your validation checks[*] contains information that is true and correct." [*] NOTE: Validation checks for ARC are not limited to formal cryptographic verifications, but MUST include assessing the intermediary against a reliable reputation database. That note characterizes ARC as a sort of reputation accounting tool for use by global mailbox providers. Certainly not a generic means to cure DMARC effects on indirect mail flows. Best Ale -- From nobody Wed Sep 29 12:46:36 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6A43A0ADD for ; Wed, 29 Sep 2021 12:46:33 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=QbFl+WaP; dkim=pass (2048-bit key) header.d=taugh.com header.b=NRMYexsF 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 rLQTIghDr1EE for ; Wed, 29 Sep 2021 12:46:29 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 C15303A0AD7 for ; Wed, 29 Sep 2021 12:46:28 -0700 (PDT) Received: (qmail 59612 invoked from network); 29 Sep 2021 19:46:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=e8da.6154c292.k2109; bh=5I/nASXZHY08ABryPlsjFJK52Rap8mbSx8TgLcmoHpw=; b=QbFl+WaPSRHY2ePQsMRxvnM3noAErZyjZrBKhs84cy+YGcChWRmr4kuJ2yRkNzvcZrd9+vECwmskGNK4K+SQCnYi35LoTLSWNOltv2D1JFd3QrewZMSF4kCtDp2Nnh13eyWDkcviu5psKRnRskbzyNN0aJ8hzCUaSlW7zmgjVIqVbE6imUJimlIEXSAoQqySpdt5CjW2kt1wvAfXVQrXzzOaEBPC68ESWgYUu5XHJ2zSV03Jut9YzSvwwu03/7eLix2JiBf59QlhR68Nm9q6Uo9bLzqNsyRjmrVIAVbpZ6HB/CsjJcl8rKJ/kRYncyGP1pXwTcyL/jmRZiOATnR5HA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=e8da.6154c292.k2109; bh=5I/nASXZHY08ABryPlsjFJK52Rap8mbSx8TgLcmoHpw=; b=NRMYexsF1rOOiw4g5zkaHx1dolFTeAJ2nSAjK+2CDxZAHRd6KsV8mx70FakVS4lrT78LVX89tlVZA//3RRuR2fwAh4C3nFDvwT4auRfYb8Lwg+0DcTssZgjTb8uqOjmAL2QHTwrWuNdy2+/c+SuW3OdAH5WhI+asgZy6NhRkGzy/Wex3RuveOe+L241MCTCROUI2JOzh1ckY3rhefDd66lMxZVsD3CIBV9KDZwgtTlXt/A3OGPEpcnui0j1L90vazhCD1/cxQoYez3pb1y5W/hjro9TtYZWOaYDoXCTxu/+LFZZ5oO8wiOj+4SoI1j9ZNQyFiHCUD3GH+UhRtjQJCQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 29 Sep 2021 19:46:26 -0000 Received: by ary.qy (Postfix, from userid 501) id 27523298EA2B; Wed, 29 Sep 2021 15:46:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 7E6BE298EA0D; Wed, 29 Sep 2021 15:46:24 -0400 (EDT) Date: 29 Sep 2021 15:46:24 -0400 Message-ID: <33a31441-7ced-a06c-bf25-7a5713e6a4dc@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , arc@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <0735bbb9-2679-baa6-a53b-d8bd2bb5bc58@tana.it> References: <20210927194713.2F31029652FB@ary.qy> <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> <8ae28aac-fece-76bb-6fd8-f18ae2dc74cc@taugh.com> <0735bbb9-2679-baa6-a53b-d8bd2bb5bc58@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 19:46:34 -0000 > [*] NOTE: Validation checks for ARC are not limited to formal > cryptographic > verifications, but MUST include assessing the intermediary against a > reliable reputation database. No, that's not what he said. Trying to rewrite other people's messages is not helpful. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Sep 30 05:55:35 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A0F3A0B98 for ; Thu, 30 Sep 2021 05:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 trFLQazq6kN9 for ; Thu, 30 Sep 2021 05:55:29 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 1EF373A0B52 for ; Thu, 30 Sep 2021 05:55:28 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id f130so5629423qke.6 for ; Thu, 30 Sep 2021 05:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uqcOMcPEM/HjsS/86pmYHGZAY/E15LMyTLruzuZf1qk=; b=f2bRShWCV719M3IivPHOJgjjWUcG1M9Dk9JqXIUZK89o8B7QRtgF3kX3cQp0K+jXjI 2Qh9PvhbNNsokappY0hx0xTONEhZ6yoShoTwWp7q8c70jrENoE8wLi1J63bOrgsXulqQ sVrFG65jllb1TYvgXezVwoL1qD+nfhxtZf3GXt/n+GZtPsBxqAGHzJXb37pY8DazRZ4s JMV9OcHqt2jyQz5IrTsw5yymlrEXDDj+ZkC4VK4AeXORPE1/88xrXlwjWlkZi7Rmm0PX T92gXWLvSRIgS8/MYcx8SJnDDqc89XxEAxKKtu/YaPYuVuhseU5TAKzsj20204dGoL2M G2Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=uqcOMcPEM/HjsS/86pmYHGZAY/E15LMyTLruzuZf1qk=; b=3ZDVK1VKGKMAVe4WHGANUodDb0sPjc3t+vNhckO7LGg6sJxsW1HoBfnGbr1bEBuvA3 c7NB7WiPfw0pxuHn2I2GrzXMhE7fp6dgdf4SRSw2loAnlWa48TU6bqEX6FADHOIJ0aXe wC4AgRbiiHJ61EwXxHvgp9eVVcjppdA9i7irNhOGUp/W416ZvRatW9zRiKj6Ek/5Df6Y 8mOau9JV3S4fBlL1H/wgNGaAvL6H19vK90gqbLr7xTSKPQFdiNkPJdrlQtLuLOF8FSIN SUoFiJ6/Bs7fFn8xAslINO7hyn7hsVM97hOhdUViG0hJmwqKtiZl+XieJadXv8JAvf1O qcQw== X-Gm-Message-State: AOAM533JXrQLxh5Fos3WHZf90oZG28XVO3MpjVrCKneSp8AJrPYS1P95 Gl2xgRoo6TOSJCcJriy692P5eAbev1WC66ryEmsS7JopMtGDsg== X-Google-Smtp-Source: ABdhPJzFYLRl6ZmCpeMVH2QFMF6Gdi44O+qEAwUG/7h3I2Qf2joPepPJcI0M6kYLgz71iTl6tMxZ+Vfk0mOonuwv1Rk= X-Received: by 2002:a37:b142:: with SMTP id a63mr4578832qkf.393.1633006526181; Thu, 30 Sep 2021 05:55:26 -0700 (PDT) MIME-Version: 1.0 References: <20210927194713.2F31029652FB@ary.qy> <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> <8ae28aac-fece-76bb-6fd8-f18ae2dc74cc@taugh.com> <0735bbb9-2679-baa6-a53b-d8bd2bb5bc58@tana.it> <33a31441-7ced-a06c-bf25-7a5713e6a4dc@taugh.com> In-Reply-To: <33a31441-7ced-a06c-bf25-7a5713e6a4dc@taugh.com> From: Todd Herr Date: Thu, 30 Sep 2021 08:55:10 -0400 Message-ID: To: arc@ietf.org Content-Type: multipart/alternative; boundary="000000000000e8c70405cd35f556" Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 12:55:34 -0000 --000000000000e8c70405cd35f556 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 29, 2021 at 3:46 PM John R Levine via Arc wrote: > > [*] NOTE: Validation checks for ARC are not limited to formal > > cryptographic > > verifications, but MUST include assessing the intermediary against a > > reliable reputation database. > > No, that's not what he said. Trying to rewrite other people's messages is > not helpful. > > John is correct; the NOTE added here has nothing to do with my proposal. The "validation checks" to which I referred in my proposal are those that are currently described in RFC 8617, Section 5.2 - https://datatracker.ietf.org/doc/html/rfc8617#section-5.2 - no more, no less. The decision by a server to accept a message from a client is made based on whatever criteria the operators of that server establish. My proposal is simply: - IF you accept a message from a client, AND - IF that client has inserted an ARC header set that passes validation checks (RFC 8617 Section 5.2), THEN - The information in that header set (and any previously-inserted header sets that pass validation checks) must be accepted by you to be true and correct Note that "true and correct" does not mean: - The message isn't spam - The message passed previous authentication checks; dmarc=fail is information that can appear in an ARC header set and be true and correct -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000e8c70405cd35f556 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 29, 2021 at 3:46 PM John R Levine via Arc <arc@ietf.org> wrote:
=
John is correct; the NOTE added here has nothing = to do with my proposal.

The "validation checks" to which I ref= erred in my proposal are those that are currently described in RFC 8617, Se= ction 5.2 - https://datatracker.ietf.org/doc/html/rfc8617#section-5.2 - no m= ore, no less.

The decision by a server to accept a message from a client= is made based on whatever criteria the operators of that server establish.= My proposal is simply:
  • IF you accept a message from a client, AND
  • IF that client has inserted an ARC header set that passes validation= checks (RFC 8617 Section 5.2), THEN
  • The information in that header= set (and any previously-inserted header sets that pass validation checks) = must be accepted by you to be true and correct
Note tha= t "true and correct" does not mean:
  • The message isn't = spam
  • The message passed previous authentication checks; dmarc=3Dfai= l is information that can appear in an ARC header set and be true and corre= ct

--

Todd He= rr | Technical Director, Standards and Ecosystem
e: <= a href=3D"mailto:todd.herr@valimail.com" target=3D"_blank">todd.herr@valima= il.com
m: 703.= 220.4153

This email and all data transmitted with it con= tains confidential and/or proprietary information intended solely for the u= se of individual(s) authorized to receive it. If you are not an intended an= d authorized recipient you are hereby notified of any use, disclosure, copy= ing or distribution of the information included in this transmission is pro= hibited and may be unlawful. Please immediately notify the sender by replyi= ng to this email and then delete it from your system.

--000000000000e8c70405cd35f556-- From nobody Thu Sep 30 10:31:04 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF583A0E14 for ; Thu, 30 Sep 2021 10:31:02 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 g5SSWonLar43 for ; Thu, 30 Sep 2021 10:30:56 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 7AE133A0E13 for ; Thu, 30 Sep 2021 10:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1633023049; bh=o4guJ1juXlciq/u3D0qzHu8ehUTuANClmEasGJ51/1s=; l=2035; h=To:References:From:Date:In-Reply-To; b=BtqETeew55zyEAXyTCGvCV9/cswpo0jLTC68q9xvH1S6R6ZHgEuDEXP1nJQNzuIP0 wUZxb3fOzRlg+Nj1RBodWOSBf3D6fJzqFi+0Ax+85X3CMkC3PJj+y6nb4I8PL4lIjC mmhr+aN/6fnrpMjeljwG5bNpKx71wCUdxIsUqVMpToXL5SrhnaSCD8aW0tJPG Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BA.000000006155F449.00002050; Thu, 30 Sep 2021 19:30:49 +0200 To: arc@ietf.org References: <20210927194713.2F31029652FB@ary.qy> <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> <8ae28aac-fece-76bb-6fd8-f18ae2dc74cc@taugh.com> <0735bbb9-2679-baa6-a53b-d8bd2bb5bc58@tana.it> <33a31441-7ced-a06c-bf25-7a5713e6a4dc@taugh.com> From: Alessandro Vesely Message-ID: Date: Thu, 30 Sep 2021 19:30:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 17:31:03 -0000 On Thu 30/Sep/2021 14:55:10 +0200 Todd Herr via Arc wrote: > On Wed, Sep 29, 2021 at 3:46 PM John R Levine via Arc wrote: > >>> [*] NOTE: Validation checks for ARC are not limited to formal > cryptographic >>> verifications, but MUST include assessing the intermediary against a >>> reliable reputation database. >> >> No, that's not what he said. Trying to rewrite other people's messages is >> not helpful. > > John is correct; the NOTE added here has nothing to do with my proposal. > > The "validation checks" to which I referred in my proposal are those that > are currently described in RFC 8617, Section 5.2 - > https://datatracker.ietf.org/doc/html/rfc8617#section-5.2 - no more, no > less. > > The decision by a server to accept a message from a client is made based on > whatever criteria the operators of that server establish. My proposal is > simply: > > - IF you accept a message from a client, AND > - IF that client has inserted an ARC header set that passes validation > checks (RFC 8617 Section 5.2), THEN > - The information in that header set (and any previously-inserted header > sets that pass validation checks) must be accepted by you to be true > and correct Where would you insert John's objection about sender reputation? I'd propose after accept, because servers who don't have a reliable reputation database need to accept messages from unknown senders. For example, like so: - IF you accept a message from a client, AND - IF you can swear the client is not malicious, AND - IF that client has inserted an ARC header set that passes validation checks (RFC 8617 Section 5.2), THEN - The information in that header set (and any previously-inserted header sets that pass validation checks) must be accepted by you to be true and correct Swearing about the client is not quite practicable, but I don't know how to express assessment so as to include 0-day exploits, such as a trusted server having just been compromised. Best Ale -- From nobody Thu Sep 30 10:41:18 2021 Return-Path: X-Original-To: arc@ietfa.amsl.com Delivered-To: arc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36773A0DDE for ; Thu, 30 Sep 2021 10:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 rOygn1AFWxGy for ; Thu, 30 Sep 2021 10:41:11 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 A09153A0E17 for ; Thu, 30 Sep 2021 10:41:11 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id q81so6653001qke.5 for ; Thu, 30 Sep 2021 10:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jBZj+3BdAKKAGQ7yFm6sRexpe1oygZF7DA90rwTT0Qo=; b=Iq3guRku3SGvbCs4nPxQF+qfUzt6qamiexD5HyY+fcJcqd/nHnzIsh9f3qGv02W2Ky yLozG8vIb0XgNFRrsz4e1HBH+2Ci2uVVPQVmwqv26SK+glr9rh9WCorb5b4CH5mBQ4Xm fwtrNw0dfqBEAmemsITk1ev4gsYtf9GCdd/OJi6eh/eaFbnv5G1UdmGUssJkx5WKrChk OahoyDRUUYlR8KYMFcuNvveeffdoj+RLHnTUMQPyC53u2KPVMPyWzX3UN4bYKVSG0byZ 3XaYZLVsgHy5uJM1SRUqhoPbbBfXdStNdXsy+D/JNtHKGzz6Zh/hmXgaKeJjU9fJ0Kcu +z2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jBZj+3BdAKKAGQ7yFm6sRexpe1oygZF7DA90rwTT0Qo=; b=kCHNaSS+LwgpaoNyAvSONW2ROw95KbWYOouEMB/5LdAotMaQoc865+ZrKcZCAblwaJ ex3yeHLm0DzX+Si0MsqO+J6acIc2zJehzxCZGqh3pN0Hc9my9MOHgdwMMT6b++jxe2lT szUTdieb5uNsUo/Zl67ibqnT3zOZoI1MsWPMPDiJwJMNsGBsA+1HE4HGU/XhC+w2br4t Wrg0NM97ROs/4EqzHvyP2WGmGRDvLL6yPqMmXQE5TSlWD50BZKBOm3+1sT1BlujEOkTw bxqlj7DLpYx2rLYCIiN38d2Jz4CT6i5IR+Ea9T9rMlJKGsqqLYM9gKfZS6a+SgFwWBNz GnTA== X-Gm-Message-State: AOAM531bkz/mGP8NA9Oxeem7gKeu2piUvJ7BMzsukWEbeELegc+blHIC OgvYOmTAajyFM/Wp3iyfA/pdxaD/ZgoeRxI7c+e/ehsqfvw= X-Google-Smtp-Source: ABdhPJz/Mx9K9DQsLfYgeKNUc2xRjB+G/cRCER68qQDlHBZjhXesjEn2lOy7MDZBj0HqKpgB/V8IZ10pn9Umla/QDPY= X-Received: by 2002:a37:b087:: with SMTP id z129mr5842688qke.392.1633023670348; Thu, 30 Sep 2021 10:41:10 -0700 (PDT) MIME-Version: 1.0 References: <20210927194713.2F31029652FB@ary.qy> <2192d51b-8fc1-6e56-701d-75a0aeb5054c@tana.it> <8ae28aac-fece-76bb-6fd8-f18ae2dc74cc@taugh.com> <0735bbb9-2679-baa6-a53b-d8bd2bb5bc58@tana.it> <33a31441-7ced-a06c-bf25-7a5713e6a4dc@taugh.com> In-Reply-To: From: Todd Herr Date: Thu, 30 Sep 2021 13:40:54 -0400 Message-ID: To: arc@ietf.org Content-Type: multipart/alternative; boundary="000000000000c8016e05cd39f303" Archived-At: Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set X-BeenThere: arc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authenticated Received Chain \(ARC\) protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 17:41:17 -0000 --000000000000c8016e05cd39f303 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 30, 2021 at 1:31 PM Alessandro Vesely via Arc wrote: > On Thu 30/Sep/2021 14:55:10 +0200 Todd Herr via Arc wrote: > > > > The decision by a server to accept a message from a client is made based > on > > whatever criteria the operators of that server establish. My proposal is > > simply: > > > > - IF you accept a message from a client, AND > > - IF that client has inserted an ARC header set that passes > validation > > checks (RFC 8617 Section 5.2), THEN > > - The information in that header set (and any previously-inserted > header > > sets that pass validation checks) must be accepted by you to be > true > > and correct > > > Where would you insert John's objection about sender reputation? I'd > propose > after accept, because servers who don't have a reliable reputation > database > need to accept messages from unknown senders. For example, like so: > > I have reviewed the thread, and for the life of me I can't find something I would call "John's objection about sender reputation". Can you point it out to me, please? > - IF you accept a message from a client, AND > - IF you can swear the client is not malicious, AND > - IF that client has inserted an ARC header set that passes validation > checks (RFC 8617 Section 5.2), THEN > - The information in that header set (and any previously-inserted > header > sets that pass validation checks) must be accepted by you to be true > and correct > > Swearing about the client is not quite practicable, but I don't know how > to > express assessment so as to include 0-day exploits, such as a trusted > server > having just been compromised. > > The locally-known reputation of the client is factored into the decision to accept the message, and has nothing itself to do with ARC, in my opinion. I would expect senders without a locally-known reputation to be judged differently from those with a locally-known good reputation and from those with a locally-known bad reputation, in that unknown senders should be treated as suspicious until proven otherwise by your users (e.g., route all mail to spam until your users tell you it's not spam, perhaps). That suspicion may, and probably should, carry over to your trust in any ARC header sets inserted by the previously unknown sender. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000c8016e05cd39f303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 30, 2021 at 1:31 PM Alessandro Vesely via Arc <arc@ietf.org> wrote:
On Thu 30/Sep/2021 14:55:10 +0200 Todd Herr via Arc wrote:
>
> The decision by a server to accept a message from a client is made bas= ed on
> whatever criteria the operators of that server establish. My proposal = is
> simply:
>
>=C2=A0 =C2=A0 =C2=A0- IF you accept a message from a client, AND
>=C2=A0 =C2=A0 =C2=A0- IF that client has inserted an ARC header set tha= t passes validation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0checks (RFC 8617 Section 5.2), THEN
>=C2=A0 =C2=A0 =C2=A0- The information in that header set (and any previ= ously-inserted header
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sets that pass validation checks) must be ac= cepted by you to be true
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and correct


Where would you insert John's objection about sender reputation?=C2=A0 = I'd propose
after accept, because servers who don't have a reliable reputation data= base
need to accept messages from unknown senders.=C2=A0 For example, like so:

I have reviewed the thread, and for the life of m= e I can't find something I would call "John's objection about = sender reputation". Can you point it out to me, please?
=C2=A0 =C2=A0 - IF you accept a message from a client, AND
=C2=A0 =C2=A0 - IF you can swear the client is not malicious, AND
=C2=A0 =C2=A0 - IF that client has inserted an ARC header set that passes v= alidation
=C2=A0 =C2=A0 =C2=A0 checks (RFC 8617 Section 5.2), THEN
=C2=A0 =C2=A0 - The information in that header set (and any previously-inse= rted header
=C2=A0 =C2=A0 =C2=A0 sets that pass validation checks) must be accepted by = you to be true
=C2=A0 =C2=A0 =C2=A0 and correct

Swearing about the client is not quite practicable, but I don't know ho= w to
express assessment so as to include 0-day exploits, such as a trusted serve= r
having just been compromised.


The locally-know= n reputation of the client is factored into the decision to accept the mess= age, and has nothing itself to do with ARC, in my opinion.

I would expe= ct senders without a locally-known reputation to be judged differently from= those with a locally-known good reputation and from those with a locally-k= nown bad reputation, in that unknown senders should be treated as suspiciou= s until proven otherwise by your users (e.g., route all mail to spam until = your users tell you it's not spam, perhaps). That suspicion may, and pr= obably should, carry over to your trust in any ARC header sets inserted by = the previously unknown sender.


= --

Todd Herr | Technica= l Director, Standards and Ecosystem
m: 703.220.4153=

= This email and all data transmitted with it contains confidential and/or pr= oprietary information intended solely for the use of individual(s) authoriz= ed to receive it. If you are not an intended and authorized recipient you a= re hereby notified of any use, disclosure, copying or distribution of the i= nformation included in this transmission is prohibited and may be unlawful.= Please immediately notify the sender by replying to this email and then de= lete it from your system.

--000000000000c8016e05cd39f303--