Subject: RE: [ietf-dkim] Base issue: multiple linked signatures

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Jan 2007 06:28:12 -0800

> [mailto:[email-masked]] On Behalf Of Dave Crocker
> 
> Stephen Farrell wrote:
> >> If anything, change this text:
> ...
> > 
> > I think we need some text containing no MUST/SHOULD/MAY at all,
> 
> The current text was the result of significant discussion and 
> a rather careful effort to focus on the primary concern.
> 
> Take out the normative quality to the text and you lose the 
> real stricture that was the entire intent we chose.
> 
> Turn the MUST to a MAY has you reverse the agreement that was 
> developed about that concern.

That is a meta-argument.

At this point we have a last-call objection to close. 'We decided differently' is not a valid move in a last call discussion. 

If the point was argued and consensus reached there should be someone who can give a rationale for MUST NOT as opposed to SHOULD NOT.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Jan 2007 07:19:40 -0800

On Jan 4, 2007, at 6:28 AM, Hallam-Baker, Phillip wrote:

> That is a meta-argument.
>
> At this point we have a last-call objection to close. 'We decided  
> differently' is not a valid move in a last call discussion.
>
> If the point was argued and consensus reached there should be  
> someone who can give a rationale for MUST NOT as opposed to SHOULD  
> NOT.

The problem stems from a mandate to sign specific headers or require  
that domains match within the 'i=' identity.  Protection is  
established by an association between the signing domain and an  
originating entity digitally "recognized" by the recipient.  The  
mistake within the base draft stems from an erroneous  
predetermination of which headers are to be signed and removal of an  
ability to link headers containing different domains.  "Repairs" can  
not rely upon a signer making copies and thereby ignore recipient  
recognitions, (the purpose of using different headers or perhaps even  
"downgrading" headers).

The underlying premise used by the base draft is fundamentally  
flawed.  There is little if any protection afforded by a visual  
recognition process anyway.  The recognition process must be based  
upon information held by the recipient.  This approach means  
protection is afforded by actions of the MUA or MDA.  This could  
exclude a transit MTA, unless protection identifies phishing attempts  
by comparing message content against known valid signing domains.   
Even that protection depends upon a type of recognition not covered  
by any header, nor should this be limited to specific domain matches  
either.

The base draft contains fundamental flaws with respect to a  
protection strategy.  Reconsider how protection can be afforded and  
how private key sharing or zone delegation can be voided (an  
expensive prerequisite that also removes normal freedoms).

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Jan 2007 15:34:17 +0000

Doug,

You are repeating yourself, yet again. As far as I can see
all this was raised by you before and none of it achieved
WG consensus.

Feel free to try convince Barry and I otherwise, *off-list*,
but please do not continue to try to reopen closed issues
on the list.

I see all this as being covered by issues 1265, 1272 (raised
by you and accepted), 1274, 1285, 1288 and probably others
(I got bored in the issue tracker). I see no WG consensus to
re-open those issues.

Stephen.

PS: I repeat, please feel free to convince us that there's
something new here, but not on the list.

Douglas Otis wrote:
>> If the point was argued and consensus reached there should be someone 
>> who can give a rationale for MUST NOT as opposed to SHOULD NOT.
> 
> that domains match within the 'i=' identity.  Protection is established 
> by an association between the signing domain and an originating entity 
> digitally "recognized" by the recipient.  The mistake within the base 
> draft stems from an erroneous predetermination of which headers are to 
> be signed and removal of an ability to link headers containing different 
> domains.  "Repairs" can not rely upon a signer making copies and thereby 
> ignore recipient recognitions, (the purpose of using different headers 
> or perhaps even "downgrading" headers).
> 
> The underlying premise used by the base draft is fundamentally flawed.  
> There is little if any protection afforded by a visual recognition 
> process anyway.  The recognition process must be based upon information 
> held by the recipient.  This approach means protection is afforded by 
> actions of the MUA or MDA.  This could exclude a transit MTA, unless 
> protection identifies phishing attempts by comparing message content 
> against known valid signing domains.  Even that protection depends upon 
> a type of recognition not covered by any header, nor should this be 
> limited to specific domain matches either.
> 
> The base draft contains fundamental flaws with respect to a protection 
> strategy.  Reconsider how protection can be afforded and how private key 
> sharing or zone delegation can be voided (an expensive prerequisite that 
> also removes normal freedoms).
> 
> -Doug
> 
> 
> 
> 
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Jan 2007 08:50:26 -0800

On Jan 4, 2007, at 7:34 AM, Stephen Farrell wrote:

>
> Doug,
>
> You are repeating yourself, yet again. As far as I can see all this  
> was raised by you before and none of it achieved WG consensus.
>
> Feel free to try convince Barry and I otherwise, *off-list*, but  
> please do not continue to try to reopen closed issues on the list.
>
> I see all this as being covered by issues 1265, 1272 (raised by you  
> and accepted), 1274, 1285, 1288 and probably others (I got bored in  
> the issue tracker). I see no WG consensus to
> re-open those issues.

My apologies.

Header copies as a "remedy" should be viewed from the aspect of  
DKIM's purpose.  Header copies to be used as a means to "verify" a  
signature increases the distance between "verified" and what a  
recipient might "see" (in any manner of seeing).  It would be a  
mistake to depend upon this mode of operation.  The "remedy" can be  
found elsewhere if and when that time ever comes.

-Doug