Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
Dave CROCKER <dhc@dcrocker.net> Tue, 29 March 2011 11:54 UTC
Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA013A67D4 for <ietfarch-ietf-dkim-archive@core3.amsl.com>; Tue, 29 Mar 2011 04:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7qVKx9zK7Us for <ietfarch-ietf-dkim-archive@core3.amsl.com>; Tue, 29 Mar 2011 04:54:37 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 0AD753A6783 for <ietf-dkim-archive@ietf.org>; Tue, 29 Mar 2011 04:54:37 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [127.0.0.1]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2TBrYFK023496; Tue, 29 Mar 2011 04:53:41 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k00001; t=1301399627; bh=RUdwyC2vZMeNbhNlvCp/3vdjXxo=; h=Message-ID:Date: From:MIME-Version:To:References:In-Reply-To:Cc:Subject:Reply-To: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=DR mzASceHskriXAHPIC2xMRn7SemiAgZhsep6y2XjqnY/3bTaJaAYFh9PIButAaUiQTUH dTIZw7dDNJ1Z4050jKrCM5PJtsHGq0bBWyPetXe3h/nBekwykX+GTNx9vgro1GR/5YA Jr9/FEN9StbRzLo5Go5v3Pp4K7rTckp4QuM=
Received: from [130.129.87.14] (dhcp-570e.meeting.ietf.org [130.129.87.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2TBrOvs023486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 04:53:31 -0700
Message-ID: <4D91C830.8060602@dcrocker.net>
Date: Tue, 29 Mar 2011 13:53:20 +0200
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Jim Fenton <fenton@cisco.com>
References: <4D90FD25.1050007@cisco.com>
In-Reply-To: <4D90FD25.1050007@cisco.com>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [127.0.0.1]); Tue, 29 Mar 2011 04:53:47 -0700 (PDT)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 29 Mar 2011 04:53:32 -0700 (PDT)
Cc: IETF DKIM WG <ietf-dkim@mipassoc.org>
Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
Jim, I found that I got seriously bogged down on some parts of your note, as you and everyone else will surely see. I am glad to try to set up a phone call to get a better channel for discussing this. Beyond the obvious timezone challenges, this week, I've got quite a bit of flexibility in time and am glad to find a slot where I can call you. Also, everyone else is hereby invited to jump in and straighten me out. That said, here's where I got in responding: On 3/28/2011 11:27 PM, Jim Fenton wrote: >> 1. "authors and their organizations" could be misinterpreted to mean that the >> conjunction defines a single identity. > > But the current text says "...examples include the author, ..." so that > misinterpretation exists there as well. I'd be fine with just "authors' > organizations". How is the "examples" list a misinterpretation? The list was crafted carefully to draw some distinctions that can be significant. Your wording loses the distinction between author and author's organization. I think the distinction is worth maintaining. Just to be clear: A domain name is capable of being author-specific. I recognize that it's not typical, but the construct of 'author' is so fundamental in this game, it's worth acknowledging that it is (still) permitted. >> 3. One form of assessment service -- of which the late Goodmail was an example >> -- can give a priori assessment and then indicate tghe assessment by providing >> the signature to the message before it is sent. That is, the authoring >> organization passes the message to the assessment service and the assessment >> service hands back the signature to be included in the message. (The details >> can vary, of course, but this describes the basic model.) Hence the signature >> is somewhat akin to a capability token. [I thought I had explained this >> processing option a number of times over the years, specifically citing the >> Goodmail example.] > > That's a specific example of an ISP along the handling path. Goodmail was not an ISP and it was not along the path. ................. Goodmail .............. . . V V Client -> Mail -> Transfer -> Service -> Receiver -> Recipient Goodmail interacted with the creator of the document and, separately, with the receiving mail service, as an adjunct "back office" service. To repeat: /It was not in the direct handling path./ DKIM supports that mode of operation quite nicely and it is a particularly powerful operational mode, so it is worth keeping that "configuration" in mind explicitly. Given how persistent this confusion seems to be it might even be worth more language, though I'm not coming up with a suggestion, offhand. > The potential for > misinterpretation of this is greater than the benefit of explaining this > potential usage scenario, especially since "assessment" has a very specific > definition in the DKIM context. I think we've just seen a good example that indeed it is easily misunderstood. That begs explicit reference, not potentially confusing conflation. >>> Section 2.9, Common ABNF tokens: Two new tokens are defined based on >>> field-name and dkim-quoted-printable. But where are field-name and >>> dkim-quoted-printable defined? >> >> field-name is defined in Section 2.10 >> >> DKIM-Quoted-Printable is defined in Section 2.11 > > Would it be beneficial to rearrange the sections to avoid the forward reference? Sounds like moving the current 2.9 to be after the current 2.11 will solve your concern. >>> 6.3 paragraph 5 has changed "signing identity" to SDID. The signing identity >>> really corresponds to the AUID. >> >> That has not been correct for any version of rfc4871bis. The term Signing >> Identity has no normative value and is now only used in the introductory text. >> >> Also note that the Update removed any meaningful semantics for AUID: >> >> The AUID comprises a domain name and an optional >> <Local-part>. The domain name is the same as that used for the >> SDID or is a sub-domain of it. For DKIM processing, the domain >> name portion of the AUID has only basic domain name semantics; any >> possible owner-specific semantics are outside the scope of DKIM. >> >> In fact, the AUID is not part of DKIM's formal output. So the formal >> specification cannot then direct it be supplied to the assessment engine. > > Nevertheless, suppose a message with From address <joe@marketing.example.com> > was properly signed with i=marketing.example.com and d=example.com. What the Your example has d= using a 'parent' domain, not a sub-domain. Your following discussion refers to aspects of the spec that concern sub-domains and I am not understanding how the example is relevant to it. Yes, I see that i= has a subdomain but, again, I don't see how that relates to your comments. With obvious trepidation, I am going to raise a concern: On reviewing the text, I find, under the Section 3.5 text for i= includes: "The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID." I suggest that the first sentence change MAY to "might" in order to make it non-normative. I further suggest removing the second sentence "However...". It is giving (normative) usage guidance for something that it has already made out of scope. > text is telling us is that the mail system SHOULD take pains to ensure that > example.com is visible to the user. This is counter to all of the text in the The closest I can come to what you describe in Section 6.3 is: "If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader." As always, anything DKIM says in the space of human factors varies between problematic and bad. "clear to the reader" nicely falls within that range. I know something about user interface design and don't know how to satisfy this guidance, or what it's supposed benefit is. Offhand, it appears to reflect the original misunderstanding that DKIM "validates" the message. That said, I don't understand how making the SDID clear to the 'reader' is relevant to your concern about AUID. > DKIM specification that permits keys for a subdomain to be managed in a parent In what way is any of this counter (per your above assertion)? > domain. If these is consensus to eliminate signing for subdomains, there is a You've jumped to a specific conclusion that implies a significant, unstated logic sequence and I'm not yet understanding the premise, never mind the rest. Please clarify. > lot of other stuff that needs to be removed from the spec, including the i= tag > itself, the "s" flag in the key record, the text in section 3.9, and the > security consideration in section 8.13. > > The Update removed semantics associated with the local part of the AUID, and not > the domain-part. Whereas I think it made changes to the semantics for the entire value. Please point to the current version's specification of AUID "semantics". > If there is not consensus to remove subdomain signing, the wording described > here makes it meaningless. This goes to the heart of why I have been arguing > that the output of DKIM should be the AUID (or its default value, which is the > SDID), and not the SDID itself. I am not understanding how this language affects the use of AUID at all. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
- [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bi… Jim Fenton
- Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc48… Murray S. Kucherawy
- Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc48… Dave CROCKER
- Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc48… John Levine
- Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc48… Jim Fenton
- Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc48… McDowell, Brett
- Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc48… John Levine
- Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc48… Dave CROCKER