Subject: Re: [ietf-dkim] Lingering discussion on draft-ietf-dkim-rfc4871-errata

From: Barry Leiba <[email-masked]>
Date: Fri, 1 May 2009 14:43:11 -0400

(I've changed the subject to take this out of the thread where it
didn't belong.)

On Fri, May 1, 2009 at 1:26 PM, Doug Otis <[email-masked]> wrote:
> Forgive the confusion about what was to be accomplished by the errata now
> heading to the IESG.  There was a vote in SF to _not_ make functional
> changes to RFC 4871, and that such changes were to be as a RFC 4871bis
> draft.  The errata however, either through error or by intent, made a
> significant change to RFC 4871 by excluding the i= value from being
> information passed to the MUA.  RFC 4871 indicates that the i= value IS the
> information passed to the MUA

I understand your concern, Doug, but I think things are really OK
there.  Here's why:

First, item 12 in the subject draft, updating section 3.9 of 4871, says this:
      A receive-side DKIM verifier MUST communicate the Signing Domain
      Identifier (d=) to a consuming Identity Assessor module and MAY
      communicate the User Agent Identifier (i=) if present.
In other words, it's up to the verifier how to handle d= and i=, and
the verifier can certainly take i= into consideration in assessing the
signature.

Second, note that the Identity Assessor module, for which we clarified
the definition after San Francisco, is NOT the MUA, so be sure not to
confuse the two.  The working group had consensus on the definition of
"Identity Assessor", with the recent update to it.

Third, remember that this update is trying to make a formal
distinction between the piece of code that does the "Identity
Assessor" function and any other code (including the MUA) that makes
other decisions.  We'll certainly see the i= value included in
Authentication-Results headers, for example, and this text won't
change anything there.

Finally, the working group decided not to try to address any changes
to the "MUA Considerations" section, where we might talk more about
this sort of thing, because it's something that probably should be
pulled from the base spec in a -bis effort, and re-worked as an
informational document on its own.

So... I concur with you that the i= value may be important for
deciding how to handle the message, and I don't think the text in this
update changes anything in that regard.  And I think the working group
expressed comfort with that as well, in arriving at consensus on this
text.

If someone disagrees with any of that and thinks the text should be
changed based on what Doug's said, please speak up right away.

Barry (as chair)

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

---

From: Doug Otis <[email-masked]>
Date: Fri, 1 May 2009 15:08:40 -0700

On May 1, 2009, at 11:43 AM, Barry Leiba wrote:
>> The errata however, either through error or by intent, made a  
>> information passed to the MUA.  RFC 4871 indicates that the i=  
>> value IS the information passed to the MUA
>
> communicate the User Agent Identifier (i=) if present. In other  
> words, it's up to the verifier how to handle d= and i=, and the  
> verifier can certainly take i= into consideration in assessing the  
> signature.

RFC 5451 passes information to "*Mail User Agent (MUA)* and downstream  
filters".

The MUA consideration section now in RFC 4871 refers to information  
passed to the *MUA* as does the incorrectly transcribed by the  
errata.  The Signing Identity (the i= value or its default), is what  
is defined as the information passed to the MUA.  RFC 4871 clearly  
indicates the i= value is optional, and its default is an empty Local- 
part followed by an "@" followed by the domain from the "d=" tag.    
The errata erroneously transcribed Signing Identity as being SDID.   
Change RFC 4871 back to AUID, otherwise the information available to  
the MUA is being changed.  The AUID always includes the SDID.   The  
correct transcription for Signing Identity into the new terminology is  
AUID.

> Second, note that the Identity Assessor module, for which we  
> clarified the definition after San Francisco, is NOT the MUA, so be  
> sure not to confuse the two.

Agreed. The new Identity Assessor terminology creates confusion.  We  
both appear to agree an MUA is not an Identity Assessor.  However, an  
MUA may include an Identity Assessor.

>  The working group had consensus on the definition of "Identity  
> Assessor", with the recent update to it.

Currently, RFC 4871 indicates the AUID is to be passed to the MUA.   
The AUID, or its default, is assured to contain the SDID.   
Importantly, the SDID does NOT contain the AUID.  This is a functional  
protocol change via errata.  In this case, the errata reduces  
information passed to the MUA.  In doing so, this potentially leaves  
the "on-behalf-of" identity ambiguous for recipients.  This errata  
reduces clarity and weakens the protections being sought.

> Authentication-Results headers, for example, and this text won't  

But the errata IS functionally changing what is to be passed to the  
MUA.  Defining the term "Identity Assessor" does not change what is  
currently defined as being provided to the MUA.  By the errata  
changing Signing Identity (AUID) into SDID within the MUA  
consideration section, the information that MUAs might expect is  
reduced.  It would be fine to replace Signing Identity with AUID or  
its default (@SDID) when not present.

> informational document on its own.

This was my understanding as well.  This section should only replace  
"Signing Identity" with AUID to be consistent with the terminology  
changes.

> deciding how to handle the message, and I don't think the text in  
> this update changes anything in that regard.  And I think the  
> working group expressed comfort with that as well, in arriving at  
> consensus on this text.

Agreed.  Defining MUA details in the RFC 4871bis draft or perhaps some  
other draft as you suggested.  Please don't  make functional changes  
in an errata that has the effect of reducing user protections.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 04 May 2009 11:45:22 -0600

> the verifier can certainly take i= into consideration in assessing the

It's worth noting that the draft also doesn't prevent the Identity Assessor 
module from considering the List-Unsubscribe header, the phase of the moon, 
or absolutely anything else.  That's a matter for the individual implementer 
to decide, not for the WG to dictate.

> "Identity Assessor", with the recent update to it.

That matches my recollection as well.

> Authentication-Results headers, for example, and this text won't

Exactly.

> changed based on what Doug's said, please speak up right away.

Thanks for these additional clarifications, Barry.  Hopefully we won't have 
to cover this material again for a while.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html