Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15

Pete Resnick <presnick@qualcomm.com> Fri, 16 March 2012 18:18 UTC

Return-Path: <presnick@qualcomm.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BAA21F858B; Fri, 16 Mar 2012 11:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Level:
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yWhEzoE7f8z; Fri, 16 Mar 2012 11:18:49 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D872D21F857A; Fri, 16 Mar 2012 11:18:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331921925; x=1363457925; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F638401.1030007@qualcomm.com>|Date:=20Fr i,=2016=20Mar=202012=2013:18:41=20-0500|From:=20Pete=20Re snick=20<presnick@qualcomm.com>|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Aaron=20Stone=20<aaron@serendi pity.cx>|CC:=20<apps-discuss@ietf.org>,=0D=0A=09<draft-ie tf-marf-dkim-reporting.all@tools.ietf.org>,=20The=20IESG =20<iesg@ietf.org>|Subject:=20Re:=20APPSDIR=20review=20of =20draft-ietf-marf-dkim-reporting-15|References:=20<CAEdA YKXXpW2UnwOuNGO=3DVG9M__zuM4hk4jjLYKzbqzORHch++Q@mail.gma il.com>|In-Reply-To:=20<CAEdAYKXXpW2UnwOuNGO=3DVG9M__zuM4 hk4jjLYKzbqzORHch++Q@mail.gmail.com>|Content-Type:=20text /plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=WvW5zzBM0yPhEhj+T187clLy/Tr49xF8m8/V74QrEGY=; b=pqGDVaotLlqodIMYzJPkiE3EeJvF2Y3VLw6EumIKMhnrwaCVjopgGXRd 7MWfjQNP/p0Pn2LRtUZYsZmR1YQlBG0D9hEBae/h2VGwYc8YIoY1AdvhJ y4Jz+s2jyZLrHjS2QfApty+3GBVXIoqjQTwb6PeVpHoIWmy0L4SJ3kK1S w=;
X-IronPort-AV: E=McAfee;i="5400,1158,6650"; a="173194290"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 16 Mar 2012 11:18:45 -0700
X-IronPort-AV: E=Sophos;i="4.73,598,1325491200"; d="scan'208";a="191776502"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 16 Mar 2012 11:18:45 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 16 Mar 2012 11:18:44 -0700
Message-ID: <4F638401.1030007@qualcomm.com>
Date: Fri, 16 Mar 2012 13:18:41 -0500
From: Pete Resnick <presnick@qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Aaron Stone <aaron@serendipity.cx>
References: <CAEdAYKXXpW2UnwOuNGO=VG9M__zuM4hk4jjLYKzbqzORHch++Q@mail.gmail.com>
In-Reply-To: <CAEdAYKXXpW2UnwOuNGO=VG9M__zuM4hk4jjLYKzbqzORHch++Q@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: The IESG <iesg@ietf.org>, apps-discuss@ietf.org, draft-ietf-marf-dkim-reporting.all@tools.ietf.org
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2012 18:18:51 -0000

Hi Aaron,

Thanks for the review. Murray has addressed many of the issues, but I 
had a few questions:

> === Minor Issues:
>
> Introduction:
>
> UPDATED
>     DomainKeys Identified Mail [DKIM] introduced a mechanism for message
>     signing and authentication.  It uses digital signing to associate a
>     domain name with a message in a reliable manner.
>     The verified domain name can then be evaluated before
>     the message is delivered, e.g., checking advertised sender
>     policy, comparing to a known-good sender list, submitting to a reputation
>     service, and so on.
>
>     A message sender employing [DKIM] may want to know when and why
>     messages received by others fail verification. This applies equally to
>     verification failures in a message containing DKIM headers, as well as
>     published signing practices (e.g., Author Domain Signing
>     Practices, [ADSP]) in an Administrative Management Domain
>     (ADMD; see [EMAIL-ARCH]).
>
>     This document extends [DKIM] and [ADSP] to add an optional reporting
>     address and some reporting parameters.  Reports are generated using
>     the format defined in [I-D.IETF-MARF-AUTHFAILURE-REPORT].
>    

That's an awful lot of rewrite and, even though it's in the intro, I am 
worried about introducing something that the WG would not agree with. 
What about the current text are you trying to clarify? Is there 
something wrong with the current text, or is this just a stylistic 
change? Similary below:

> OLD
>     When a Signer wishes to advertise that it wants to receive failed
>     verification reports, it also places in the DNS a TXT resource record
>     (RR).  The RR is made up of a sequence of tag-value objects (much
>     like DKIM key records, as defined in Section 3.6.1 of [DKIM]), but it
>     is entirely independent of those key records and is found at a
>     different name.  In the case of a record advertising the desire for
>     authentication failure reports, the tags and values comprise the
>     parameters to be used when generating the reports.  A report
>     generator will request the content of this record when it sees an
>     "r=" tag in a DKIM-Signature header field.
> NEW
>     When a Signer wants to receive reports of failed DKIM verifications,
>     it adds a TXT resource record (RR) in the DNS, advertising how to
>     notify the Signer of such failures.  The RR contains a sequence of
>     tag-value objects in a similar format as DKIM key records, specifying
>     parameters to be used when generating failure reports.
>
>     The TXT record containing failure reporting information MUST be
>     "_report._domainkey" within the relevant DNS domains.  A report
>     generator will request the contents of this record when it sees an
>     "r=" tag in a DKIM-Signature header field.
>    

Same issue (but moreso) as in the introduction. What is the 
clarification you are making or the issue that you are trying to fix?

> Section 5: remove extra sentence
>
> OLD
>     This memo also includes, as the "ro" "rr" tags defined above, the means by
>     which the signer can request reports for specific circumstances of
>     interest.  Verifiers MUST NOT generate reports for incidents that do
>     not match a requested report, and MUST ignore requests for reports
>     not included in this list.
> NEW
>     The "ro" and "rr" tags allow a Signer to specify the types of errors it
>     is interested in receiving reports about. This section defines
>     the error types and corresponding token values.
>
>     Verifiers MUST NOT generate reports for incidents that do
>     not match a requested report, and MUST ignore requests for reports
>     not included in this list.
>
>    

Again, why?

> OLD
>     Implementers are therefore strongly advised not to advertise that DNS
>     record except when reports desired, including the risk of receiving
>     this kind of attack.
>
>     Positive caching of this DNS reply also means turning off the flow of
>     reports by removing the record is not likely to have immediate
>     effect.  A low time-to-live on the record needs to be considered.
> NEW
>     Domain owners are therefore strongly advised not to advertise the DNS
>     records specified in this document except when failure reports are desired.
>     Domain owners ought to be prepared to receive unexpected traffic and attacks.
>
>     Negative caching offers some protection against this pattern of
>     abuse, although it will work only as long as the negative time-to-
>     live on the relevant SOA record in the DNS.
>
>     Positive caching of DNS records also means turning off the flow of
>     reports by removing the record is not likely to have immediate
>     effect.  A low time-to-live on the record needs to be considered.
>    

And this one too. Please explain.

Nits I've got no concerns about, and some of the re-ordering and the 
like is just nits. But since you put these in the "Minor issues" 
section, I'd like to understand the issues.

Thanks again for your thorough review.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102