Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

[Jim Fenton]

Waking up to this thread a little late...

On 11/14/16 7:38 AM, Michael Thomas wrote:
> On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote:
>> On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany > > wrote:
>>
>> Hi Murray.
>>
>>
>> Mark!
>>
>> > RFC6376 and even RFC4871, but now it's apparently happening
>>
>> I'd be interested to hear about the actual scenarios. Are the
>> targeted
>> users somehow given an indication that the email verifies and it's
>> from a credible domain and yet it contains a malevolent payload?
>>
>>
>> As I understand the attack:
>>
>> Spammer tries to send spam to a victim.  The MSA blocks this because
>> it's spam.  However, the spam filter is not applied to mail sent by
>> the spammer to itself, because why would that be a problem?  So the
>> spammer sends itself a piece of spam, which the MSA dutifully signs. 
>> Then the spammer downloads that message and remails it using whatever
>> envelope it likes.  The signature will continue to validate, carrying
>> the reputation of the signing domain through any whitelist or other
>> system that says this signer tends to send good mail.
>>  
>
> This sounds like a misconfiguration problem.It's a problem because
> it's $spam/$malware/$bad regardless of who the recipient is.
>
> The rule is: if you think it's bad, don't sign it. If you sign it, you
> own it.
So to put Mike's comment a different way: Why is the MSA signing
something that isn't subject to scrutiny? If the message is just going
back to the sender, it doesn't need a signature.  It sounds like this
problem could be addressed by putting signing after the outgoing spam
check, with no change to the protocol.

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

Re: [ietf-dkim] DKIM Key Sizes

[Jim Fenton]

On 10/30/16 4:05 PM, Jon Callas wrote:
>
> > On Oct 28, 2016, at 5:02 AM, Eliot Lear  wrote:
>
> > If it’s the same conversation I was engaged in, I think the person was
> > just confused.  A simpler approach to plausible deniability is simply
> > not to sign.  And further, just because a person can hack someone’s
> > personal message store, as seems to have happened to Podesta, doesn’t
> > mean that they can hack the private key out of Google.  Furthermore,
> > using the example above, the key would actually have to be around for a
> > while (e.g., not rotate out of DNS).  In fact, if the key really is
> > intended to verify the source over a longer period of time than, say,
> > delivery, certainly 512 is not enough.
>
> Yup! I agree completely. If the key is intended to verify the source
> longer than delivery, then 512 is not enough.
>
> And -- the key is *PRECISELY* intended to verify the source *NO*
> *LONGER* than delivery. 512 probably still isn't quite enough, since
> you can break a 512-bit key too easily. If I lick my finger and stick
> it into the wind, 600-700 bits is about where they should be.

I recall no discussion (prior to this leak) about non-repudiation
characteristics of DKIM. We were concerned about making sure the
signatures are verifiable for long enough for the recipient MTA to
verify them (~1 week, accounting for delivery delays) and that there is
no requirement that they be verifiable longer than that. But there was
no effort to constrain the validity beyond that. We were concerned that
requiring large DKIM keys would be a barrier to deployment, largely
because of the computational burden it might impose on bulk senders. But
nothing other than DNS concerns about discouraging large keys.

It was perhaps an oversight not to mention it somewhere, in a similar
manner to the brief mention of information leakage (RFC 6376 section 8.10).

> I think it was Mark Delaney's words in his mission statement for the
> DK part of DKIM that it lets Alice's ISP know that a message from her
> from her bank actually came from her bank, even when forwarded through
> her alumni association. DKIM gives source attribution that travels
> with the message.
>
> However, that source attribution has another side to it. That other
> side is that at its core, one might say a DKIM signature is in a
> similar moral space as the "super cookies" that some providers put
> into web connections (like Verizon, who the FTC fined $1.3M). It is a
> tracking thing that is put without the user's consent into their email
> that can be used for identification later without their knowledge.
> Worse, it's not merely a cookie that's a constant, it's a
> content-specific digital signature. Shock horror.

Ouch. I really don't get the analogy between an identifier that is
placed on a user's computer and, without their knowledge, permits
tracking their browsing, and this signature (that doesn't even represent
an individual) that travels with a message.
>
> Now of course, the counter-argument is about the semantic layer. Yeah,
> syntactically, there's a resemblance, but the reason they're different
> is many-fold and has to do with purpose, use, and so on.
>
> For one, the "super cookies" are a conversation between the network
> provider and an ad network that does not benefit the user in any way.
> They are an *exploitation* of the user. A DKIM signature benefits us
> all through that initial use case. They add to the public health of
> the Internet as a whole and the email infrastructure at large. I can
> mount a vigorous defense of DKIM, but I could also use DKIM in a
> defense of tracking cookies. I believe I could also shoot down that
> analogy.

Wandering off topic, but I'm positive the purveyors of super cookies
will cite "getting more relevant ads" as a benefit to the user. But what
does DKIM track?
>
> I also think that we can improve DKIM in a lot of ways operationally
> that further breaks whatever improper analogy there is. We also ought
> to re-examine a lot of the email infrastructure with a post-Snowden
> eye, and that eye should include a post-Yahoo-scanning scandal as
> well. We really should look at how much the email ecosystem as a whole
> has become part of the broader surveillance structure of the Internet.
>
> These include:
>
> - MDAs should strip out DKIM signatures. If they did, my whole silly
> comments about key sizes are moot. It means that they aren't part of
> the whole permanent record of email stores and their insecurity
> because of the peculiar legal status of email.
>
> - MDAs should also be stripping Received headers and a bunch of
> others. Received headers write in stone the geoposition someone was at
> when they pressed send. It's a 4-space pin in the map. You can track
> people in their business travels by looking through old mailing list
> archives. You can see what type of computer they run, what MUA they
> are using, and their upgrade patterns. All the better to spearphish
> them with.
>
> 

Re: [ietf-dkim] Timeouts retrieving keys from ietf.org

[Jim Fenton]

On 9/15/13 12:59 PM, John R. Levine wrote:
> Traceroutes confirm that it's dead, I sent a note to ietf-action.
>
> On Sun, 15 Sep 2013, Jim Fenton wrote:
>
>> Slightly off-topic for this list, but the dkim-ops mailing list seems to
>> be dormant...
>>
>> I'm getting a fair number of DKIM key lookup failures from ietf.org.  I
>> have run into this on two different mail servers with independent
>> resolver configurations, so I'm inclined to think the problem is not on
>> my end:
>>
>> Sep  7 12:58:19 v2 opendkim[1019]: r87JwCmq008446: key retrieval failed
>> (s=ietf1, d=ietf.org): timeout DNS query for `ietf1._domainkey.ietf.org'
>>
>> If anyone else is seeing this, let me know and I'll report it.  My
>> theory is that their DNS servers are struggling to respond to many key
>> requests after sending out signed messages to large mailing lists. The
>> TTL is 30 minutes, which may be too short.
>>
>> -Jim
>>
It turns out that the glue records for ietf.org were messed up. I sent a
note to ietf-action on that, and they have at least worked around the
problem (see below). I'm surprised Network Solutions had this problem.

I haven't seen any key retrieval timeouts since they implemented this.

On 10/5/13 7:51 AM, Glen via RT wrote:
> Jim -
>
> We've hit a wall with Network Solutions, and have been unable to get
> past it.  For reasons they cannot explain, they are unable to modify, or
> allow us to modify, the glue record for "ns0.ietf.org".
>
> Because this is clearly a problem, and one which will become much worse
> when we start moving to upgraded colocation facilities in the coming
> weeks, I have simply modified the domain itself to point to the more
> correct "ns0.amsl.com" record.  This is a record which we -do- have
> control over, and which is correctly configured on all levels.
>
> This should resolve any issues you've encountered, not to mention
> preventing future issues that might be very bad.
>
> I apologize for this confusion.  Thanks for bringing this to our
> attention, and thanks for your patience on this matter.  Please feel
> free to contact us if you require anything further at any time.
>
> Regards,
> Glen
> Glen Barney
> IT Director
> AMS (IETF Secretariat)
>
>
> On Tue Sep 24 14:09:49 2013, stevey wrote:
>> Hi Jim,
>>
>> Unfortunately Network Solutions seem unable to correct the record for
>> us, and we are escalating this to IETF leadership and Network Solutions'
>> Corporate level.
>>
>> This process could take a week or two but we will stay on top of it and
>> let you know when we get things fixed.
>>
>> Best regards,
>> Steve
>>
>> On Mon Sep 23 09:04:09 2013, stevey wrote:
>>> Hi Jim,
>>>
>>> We are working to get the glue records resolved, however, Network
>>> Solutions is having to escalate our request.  They have informed us it
>>> may take 2-3 days to correct this.  We'll keep you informed and let
>>> you know as soon as this is fixed.
>>>
>>> Best regards,
>>> Steve
>>>
>>> On Thu Sep 19 22:02:05 2013, fen...@bluepopcorn.net wrote:
>>>> I have been getting intermittent errors retrieving IETF's DKIM key
>>>> records from DNS, and upon investigation I ran into the what seems
> to be
>>>> an inconsistency in the "glue" records for the ietf.org domain.
>>>>
>>>> According to:
>>>>
>>>> http://www.dnssy.com/report.php?q=ietf.org
>>>>
>>>> the glue record for ns0.ietf.org says its address is 12.22.58.2 rather
>>>> than 64.170.98.2, which is the address given in the domain's zone
> file.
>>>> Please let me know when this is corrected (or if it's not really an
>>>> error) and I will check to see if there are further errors retrieving
>>>> DKIM keys.
>>>>
>>>> -Jim
>>>>

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

[ietf-dkim] Timeouts retrieving keys from ietf.org

[Jim Fenton]

Slightly off-topic for this list, but the dkim-ops mailing list seems to
be dormant...

I'm getting a fair number of DKIM key lookup failures from ietf.org.  I
have run into this on two different mail servers with independent
resolver configurations, so I'm inclined to think the problem is not on
my end:

Sep  7 12:58:19 v2 opendkim[1019]: r87JwCmq008446: key retrieval failed
(s=ietf1, d=ietf.org): timeout DNS query for `ietf1._domainkey.ietf.org'

If anyone else is seeing this, let me know and I'll report it.  My
theory is that their DNS servers are struggling to respond to many key
requests after sending out signed messages to large mailing lists. The
TTL is 30 minutes, which may be too short.

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

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

[Jim Fenton]

This might be the right thing to do, but it seems like the more
appropriate time might be to do this when DMARC becomes standards-track.

I will note that vanilla, uncustomized SpamAssassin does implement ADSP,
so there might be more checking of ADSP records than some realize.  See,
for example:

 http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED

-Jim

P.S. I owe the DMARC folks a review of the DMARC spec, which I have
begun and already have quite a few questions.  I expect to complete this
within a week.

On 9/11/13 4:52 PM, Dave Crocker wrote:
> Folks,
>
> Barry has agreed to sponsor the enclosed status change.
>
> He would like to see discussion formal request.
>
> (If you've already responded to my /in/formal query earlier today on the 
> dmarc@ietf list, please now lodge any formal comments you wish to make 
> on either of the two lists here.
>
> d/
>
>
>  Original Message 
> Subject: Request to move RFC 5617 (ADSP) to Historic
> Date: Wed, 11 Sep 2013 16:09:14 -0700
> From: Dave Crocker 
> Organization: Brandenburg InternetWorking
> To: Barry Leiba ,  Pete Resnick 
> 
>
> Folks,
>
> This is a formal request, to have DomainKeys Identified Mail (DKIM)
> Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.
>
> It has garnered almost no deployment and use, in the 4 years since its
> advancement to IETF Proposed Standard.
>
> In addition, newer work, DMARC, covers the same general email functional
> area and already has garnered quite a bit of deployment and use. Hence
> it will clarify things for the marketplace to remove standards status
> from the apparently-competing, but actually-useless ADSP specification.
>
> Today I sent a query to the MAAWG Technical committee and the IETF DMARC
> mailing lists, to assess support for the status change. Within only a
> few hours, I've already seen quite a few +1s, and no -1s.
>
> Thanks.
>
>
> d/
>

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

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

[Jim Fenton]

On 9/12/13 12:28 PM, Dave Crocker wrote:
> On 9/12/2013 12:20 PM, Jim Fenton wrote:
>
>> I will note that vanilla, uncustomized SpamAssassin does implement ADSP,
>> so there might be more checking of ADSP records than some realize.  See,
>> for example:
>>
>>   http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED
>
> There seems to be a pattern that has developed, of demanding that
> failure mean literally no adoption.  It doesn't mean that.  It means
> that it has no community traction.  ADSP more than qualifies on the
> pragmatics of failure.

This was a response to your statement to Barry and Pete, "It has
garnered almost no deployment and use." If that comment was relevant, so
is a comment that there is, in fact, some deployment.

-Jim

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

Re: [ietf-dkim] WG Action: Conclusion of Domain Keys Identified Mail (dkim)

[Jim Fenton]

Barry,

Thank you and Stephen for your leadership of this WG.

-Jim

On 9/26/11 11:23 AM, Barry Leiba wrote:
>> The Domain Key Identified Mail (dkim) working group in the Security Area
>> has concluded.
> And with that, ends an era.  I want to thank everyone who worked hard
> on getting the DKIM documents decided, written, and published.  I've
> been pleased to chair this group for more than five and a half years.
>
> Barry
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html

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

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

[Jim Fenton]

My draft is expired, and I'm not particularly passionate about this so 
it's probably best if you do your own draft.  I can send you the XML for 
my draft as a starting point if you want; feel free to use any of it 
that you want.

-Jim

On 4/1/11 4:53 PM, Franck Martin wrote:
> Yes, could be good to do it as a separate extension, I thought also about 
> specifying an X-Header that would be signed by DKIM.
>
> Another way is to have a dkim tag that specify the header that indicates the 
> stream classification
>
> Many ways to kill the same bird.
>
> As for the stream name, I think giving a few codified ones, would help the 
> receiver in making decision, but if sender wants to use his own, then be free 
> to do so.
>
> Should we resurrect your draft, or go another way? Which way you want to go? 
> (How does it work in IETF?)
>
> - Original Message -
> From: "Jim Fenton"
> To: "Franck Martin"
> Cc: "Rolf E. Sonneveld", "IETF DKIM 
> WG"
> Sent: Saturday, 2 April, 2011 9:33:10 AM
> Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)
>
> I'm told that adding something like this to 4871bis would require that
> it go around again at Proposed Standard, rather than progress to Draft
> Standard.
>
> It might be possible as a separate extension to DKIM, however.  I have
> an expired draft along these lines,
> draft-fenton-dkim-reputation-hint-00.  But it didn't include the
> specific stream names.
>
> -Jim
>
> On 4/1/11 2:04 PM, Franck Martin wrote:
>> I would suggest we deprecate i= and add st= (if not already used) that would 
>> let the sender specify a stream category. It would be limited to say 20 (or 
>> so) chars and we could specify a set of standard words (but not limited to). 
>> I'm thinking of things like transactional, marketing, password-reminder, 
>> sub-confirmation, billing, corporate, personal,...
>>
>> It would be left to the receiver to use them or not of course.
>>
>> I understand some of these words could be abused, but then the receiver 
>> could build a confidence factor in domain/stream association, etc...
>>
>> With IPv6 we may loose IP reputation, this is a way to bring it back within 
>> DKIM.
>>
>> PS: http://postmaster.facebook.com/outbound gives a good idea of streams in 
>> IPv4 world with DKIM equivalent, but they may be about the only ones to do 
>> that with DKIM.
>>
>> - Original Message -
>> From: "Rolf E. Sonneveld"
>> To: "Franck Martin"
>> Cc: "Jim Fenton", "IETF DKIM WG"
>> Sent: Saturday, 2 April, 2011 8:14:45 AM
>> Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)
>>
>> On 4/1/11 1:31 AM, Franck Martin wrote:
>>> I had the feeling that Y! was using the local part of i= to do 
>>> differentiation in reputation. ie various streams within the same domain.
>>>
>>> I know the spec intent recommends, different domains for different streams, 
>>> but then
>>>
>>> Intuition would tell me, that few people are willing (or understand) to 
>>> have different domains for different streams.
>> +1. And as DKIM d= information already is shown to end users by some UA
>> implementations (e.g. Gmail shows 'this message was signed by,
>> when clicking on details) the need/advise to use different domains for
>> different streams conflicts with the threat of phishers registering
>> look-alike domains.
>>
>> /rolf
>>
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

[Jim Fenton]

I'm told that adding something like this to 4871bis would require that 
it go around again at Proposed Standard, rather than progress to Draft 
Standard.

It might be possible as a separate extension to DKIM, however.  I have 
an expired draft along these lines, 
draft-fenton-dkim-reputation-hint-00.  But it didn't include the 
specific stream names.

-Jim

On 4/1/11 2:04 PM, Franck Martin wrote:
> I would suggest we deprecate i= and add st= (if not already used) that would 
> let the sender specify a stream category. It would be limited to say 20 (or 
> so) chars and we could specify a set of standard words (but not limited to). 
> I'm thinking of things like transactional, marketing, password-reminder, 
> sub-confirmation, billing, corporate, personal,...
>
> It would be left to the receiver to use them or not of course.
>
> I understand some of these words could be abused, but then the receiver could 
> build a confidence factor in domain/stream association, etc...
>
> With IPv6 we may loose IP reputation, this is a way to bring it back within 
> DKIM.
>
> PS: http://postmaster.facebook.com/outbound gives a good idea of streams in 
> IPv4 world with DKIM equivalent, but they may be about the only ones to do 
> that with DKIM.
>
> - Original Message -
> From: "Rolf E. Sonneveld"
> To: "Franck Martin"
> Cc: "Jim Fenton", "IETF DKIM WG"
> Sent: Saturday, 2 April, 2011 8:14:45 AM
> Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)
>
> On 4/1/11 1:31 AM, Franck Martin wrote:
>> I had the feeling that Y! was using the local part of i= to do 
>> differentiation in reputation. ie various streams within the same domain.
>>
>> I know the spec intent recommends, different domains for different streams, 
>> but then
>>
>> Intuition would tell me, that few people are willing (or understand) to have 
>> different domains for different streams.
> +1. And as DKIM d= information already is shown to end users by some UA
> implementations (e.g. Gmail shows 'this message was signed by,
> when clicking on details) the need/advise to use different domains for
> different streams conflicts with the threat of phishers registering
> look-alike domains.
>
> /rolf
>
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

[Jim Fenton]

On 4/1/11 10:01 AM, Hector Santos wrote:
> Jim Fenton wrote:
>
>> I am formally proposing that the i= tag
>> and supporting text be removed from 4871bis.
>>
>> [snip]
>>
>> In a conversation with Dave Crocker and Murray Kucherawy, they noted 
>> the use of the local part of i= as an opaque identifier.  Its use as 
>> such an identifier is not described in any standard, but the 
>> relaxation of the current restrictions on the use of i= (that the 
>> domain-part be a subdomain of d=, etc.) would result in an 
>> incompatibility with RFC 4871-compliant verifiers.  It is, however, 
>> possible to remove it entirely without creating a compatibility problem.
>
> By remove, does that mean implementators can safely begin to not offer 
> it for Domain signers to use or consider?

I should probably have used the term "deprecate" rather than "remove".  
That's correct, an implementation compliant with 4871bis would not 
normally use the i= tag/value in signatures.

>
> Documenting this stuff to layman operators is HARD especially when we 
> don't even have a firm grip of its utility or what value it offers. :)

That's part of the reason for deprecating the feature:  if people don't 
understand the utility of it, and it is not being used, then it is only 
adding complexity to the spec.

>
> If its one more useless thing we don't have to ambiguously document 
> for customer to understand and use with no real verification payoff, 
> then +1 to remove i= from DKIM.

Thanks.

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

[ietf-dkim] Proposal: Removal of AUID (i= tag/value)

[Jim Fenton]

The direction of the DKIM specifications since RFC 4871 have been to 
rely less and less on the AUID (agent or user identifier, the i= value 
on the signature) to the point that it provides no security benefit.  On 
the other hand, a malformed AUID can cause a DKIM signature not to 
verify, and i= currently adds to the complexity of the DKIM 
specification.  For this reason, I am formally proposing that the i= tag 
and supporting text be removed from 4871bis.

i= was introduced in RFC 4871 as a mechanism to:

(1) Allow a parent domain to sign for a subdomain, simplifying the 
management of keys.  So if example.com had several subdomains and wanted 
to use the same keys to sign for all of them, it could put the actual 
domain name being used in the i= value (e.g., marketing.example.com) and 
the location where the keys were stored in the d= value (e.g., example.com).

(2) Support finer-grained verification in conjunction with the g= 
tag/value in the key record.  We have already decided to remove the g= 
tag/value in 4871bis.

(3) Support matching with the From address to determine if a signature 
was an Author Signature in SSP.  SSP became ADSP, and WG consensus was 
to match the domain of the From address against the SDID instead.

In order to remove i= from the specification, we need to:

- Remove section 2.6 (definition)
- Remove i= tag definition from 3.5
- Remove i= from example at the end of 3.5
- Remove "s" flag from t= tag definition in 3.6
- Remove section 3.9 (Signing by Parent Domains)
- Remove section 3.10 (relationship between SDID and AUID) or change it 
to reflect SDID-only information
- Remove reference to i= tag in 6.1.1 paragraph 5
- Remove section 8.13 (Inappropriate Signing by Parent Domains)
- Remove i= from examples in A.2 and A.3
- Change IANA registries to retain i= tag in signature and "s" flag in 
key record as deprecated

That's what I could find, but I may have missed something.

In a conversation with Dave Crocker and Murray Kucherawy, they noted the 
use of the local part of i= as an opaque identifier.  Its use as such an 
identifier is not described in any standard, but the relaxation of the 
current restrictions on the use of i= (that the domain-part be a 
subdomain of d=, etc.) would result in an incompatibility with RFC 
4871-compliant verifiers.  It is, however, possible to remove it 
entirely without creating a compatibility problem.

Comments, please.

-Jim


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

Re: [ietf-dkim] mipassoc site is down?

[Jim Fenton]

It looks like the IPv6 address for mipassoc.org isn't working, although 
the IPv4 address is.

-Jim

On 3/31/11 1:26 AM, Dave CROCKER wrote:
> if you folks get this message, the problem must be fixed...
>
> sorry for the hiccup.
>
> d/
>
> On 3/31/2011 4:24 AM, Franck Martin wrote:
>> telnet mipassoc.org 80
>> Trying 2001:470:1:76:::4834:7146...
>> telnet: connect to address 2001:470:1:76:::4834:7146: Host is down
>> Trying 72.52.113.70...
>> Connected to mipassoc.org.
>>
>> and in my browser http://mipassoc.org/ returns a blank page (connects but 
>> result
>> is blank page).
>
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04

[Jim Fenton]

On 3/29/11 4:53 AM, Dave CROCKER wrote:
> 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.

With the output of DKIM being the SDID, the identity associated with the 
signature is of course that of the domain.  But when my author-specific 
domain signs a message for me, it's the domain that does that -- it 
doesn't matter that it's an organization of one.  Putting "author" here 
just hints that authors might sign messages as well, and I don't think 
that's intended.  I suggest removing "author" to make that clear.

>
>
>>> 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.

This still seems to me to be too specialized a use case to list in the 
specification, but would look to WG consensus on which way to go here.

>
>
>> 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.

Can you offer alternate text that avoids the overloading of the word 
"assessment"?

>
>>>> 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.
>>>
>&g

[ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04

[Jim Fenton]

Some comments on the new rfc4871bis draft.  Some of these comments are 
continued from the discussion on -03, where in many cases I dropped the 
ball on a previous thread.

A previous comment of mine, and Dave Crocker's response to which I will 
finally reply:
>
>> Section 2.3, Identity: I realize this is taken from RFC 5672, but the
>> definition is not clear to me. Suggest that the second sentence read,
>> "Identities that may be associated with DKIM signatures include 
>> authors and
>> their organizations, ISPs along the message handling path, and 
>> mailing list
>> operators." (I'm not sure how the independent trust assessment 
>> services apply
>> here, since their assessment happens AFTER signature verification). 
>> [same as
>> last call comment on -02]
>
> 0. Can you clarify what it is about the definition that is not clear?  
> (Any guidance at all will help for understanding the nature of what 
> needs fixing.) The initial text is the definition and it's simplicity 
> makes it difficult to guess what the problem is.
>
> 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".
>
> 2. It turns out that this sort of text is much clearer when it makes a 
> singular rather than plural reference, especially given that the term 
> being defined is singular.

I'm fine with singular.
>
> 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.  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.

>> 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?



Section 3.2, paragraph 2:  dkim-quoted-printable is now defined in 
section 2.11, not 2.6.


>> 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
> .  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 
 was properly signed with 
i=marketing.example.com and d=example.com.  What the 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 DKIM 
specification that permits keys for a subdomain to be managed in a 
parent domain. If these is consensus to eliminate signing for 
subdomains, there is a 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.

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.

=
In today's meeting, I took an action on the Jabber chat to write some 
informative text cautioning signers not to put empty g= values in their 
key records.  Here is an attempt:

Appendix C.  Key Record Considerations (IN

[ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-03

[Jim Fenton]

My comments on the -03 draft:

1. Introduction: The opening paragraph has lost the sense that the 
signer has to be authorized by the domain owner to apply a signature on 
behalf of that domain.  While the previous draft was a bit too 
restrictive (implied that the signer had to actually be the domain 
owner) this version is too loose.  For the opening sentence I suggest 
something like, "DomainKeys Identified Mail (DKIM) permits a person, 
role, or organization to claim some responsibility for a message by 
associating a domain name [RFC1034] for which they are authorized with 
the message [RFC5322]."

Section 2.3, Identity: I realize this is taken from RFC 5672, but the 
definition is not clear to me. Suggest that the second sentence read, 
"Identities that may be associated with DKIM signatures include authors 
and their organizations, ISPs along the message handling path, and 
mailing list operators." (I'm not sure how the independent trust 
assessment services apply here, since their assessment happens AFTER 
signature verification). [same as last call comment on -02]

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?

Section 3.7, Computing the Message Hashes: "ABNF of the algorithm" does 
not make sense; ABNF is a syntax specification, it does not specify 
algorithms (and this isn't ABNF, either).

Section 5.3 paragraph 2: remove comma after RFC 2047 (happy National 
Grammar Day!)

Section 6.1.2 Note: The first sentence is describing behavior of a 
number of queries, and should be plural, i.e., "The use of wildcard TXT 
records in the DNS will produce responses to DKIM queries that are 
likely not to be valid DKIM key records."

6.3 paragraph 5 has changed "signing identity" to SDID. The signing 
identity really corresponds to the AUID. As currently worded, the mail 
system is advised to take pains to ensure that the SDID is displayed for 
a message signed on behalf of a subdomain; this isn't necessary. Given 
the WG's past consensus to ignore the local part of the AUID, I suggest 
the following wording for the last sentence of the paragraph: "If the 
domain of the AUID is not the same as domain of the address in the From: 
header field, the mail system SHOULD take pains to ensure that the 
actual AUID domain is clear to the reader." [same as last call comment 
on -02; the point is that if the AUID references a subdomain of the 
SDID, it should still match]

8.14: Remove extraneous > in last paragraph.

(not sure where)  g= resolution:  As Murray pointed out 
(http://mipassoc.org/pipermail/ietf-dkim/2010q4/015030.html), we need to 
make the appropriate adjustments to the registries making g= obsolete, 
and an informative appendix cautioning signers not to put empty g= 
values in their key records because of the legacy behavior of many 
verifiers.

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

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

[Jim Fenton]

On 1/7/11 12:37 PM, Barry Leiba wrote:
> As the 4871bis editors worked on resolving the last sets of comments
> in the 4871bis document, the chairs and the editors had some
> discussion about other efforts that are interested in re-using
> portions of the DKIM signing/verifying/key-distribution mechanism
> outside the email context.  See, for example,
> http://tools.ietf.org/html/draft-desruisseaux-ischedule.  This would
> mean using a DKIM-like mechanism to secure the distribution of
> scheduling events.  That effort is currently referencing (and
> updating) RFC 4871, but that includes what for them are many
> irrelevant and inappropriate details that have to do with email.
>
> One way we can handle this and other use cases, as we move the DKIM
> specification along, is to split the specification into two documents,
> one that describes the underlying components, and a second that
> describes the email-specific bits.

I'm quite unhappy with the proposal to split RFC4871, for a number of 
reasons (in no particular order):

1. Review Abuse:  We held a Last Call on rfc4871bis that closed on 22 
October 2010.  Many of us put considerable focus into a detailed edit of 
the document at that time, and to hear that other than surgical changes 
to the document in response to Last Call comments is an abuse of many 
peoples' time, and not just mine.  The cited other usage of DKIM 
signatures, iSchedule, was published in March 2010 so it should have not 
been the gating factor.

2. Charter: The DKIM WG charter states "1. Advance the base DKIM 
protocol (RFC 4871) to Draft Standard.
This is the first priority for the working group."  A reorganization of 
4871bis into two documents is inconsistent with the "first priority" 
requirement of the charter.

3. Risk:  The amount of violence that will need to be done to the text 
of RFC4871 introduces significant risk that the specifications will be 
unclear or inconsistent with 4871.  While the rules for advancing to 
Draft do refer to specifications and not documents, I would be 
uncomfortable with doing anything other than recycling at Proposed to 
see if errata, etc. result from the changes.  But recycling at Proposed 
is inconsistent with the charter.

4. Usage:  DKIM has quite a bit that is tailored specifically for mail:  
the syntax of the header field, canonicalization, etc.  The proposed 
split includes canonicalization as part of DOSETA, and wonder if that 
really makes sense.  While the syntax of a DKIM signature may be close 
to what's required for iSchedule, will we next need to consider yet 
another split to permit signatures to be expressed in JSON, XML, or 
other formats?  Are there other uses considered besides iSchedule at 
this time?

5. Security properties:  DKIM was designed to provide a modest level of 
security limited by the security properties of DNS.  This was considered 
acceptable because it's comparable to the level of security afforded 
message routing (since MX records could be spoofed).  Other uses of DKIM 
need to be examined carefully to make sure that we do not depend on an 
insufficiently secure key infrastructure.  While use of DNSSEC mitigates 
this, I'm concerned about whether it will really be used everywhere needed.

6. Redundancy: Section 10.1 of the iSchedule draft requires the use of 
TLS for all transactions.  Why is DKIM then also needed (if the 
certificate verification happens in both directions, of course)?  Why 
are two very different mechanisms in use?

7. Openness and Timeliness: Barry has apologized for not announcing this 
a month ago, but I sense that this has been going on in a private design 
team longer than that.  BCP 9 section 1.2 talks to openness and 
timeliness; this fails on both accounts.

-Jim

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

Re: [ietf-dkim] Last call comment: Changing the g= definition

[Jim Fenton]

  On 10/15/10 7:28 AM, Jeff Macdonald wrote:
> On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER  wrote:
>> Although some folk have done a +1 for one (or another) removal, I'd like to 
>> get
>> a round of explicit reactions to the specific idea of removing /both/.
> +1

Given the lack of (useful) deployment of g=, and the consensus to move 
away from using actual mailbox addresses in the local-part of i= (which 
means that g= is matching with, potentially, an opaque value), I support 
this.

However, we still need to caution DKIM signers deploying DKIM that they 
need to make sure that their selector records don't contain empty g= 
values, because there will be verifiers that check g= for a very long 
time.  As I said before, my preference is to put that advice directly in 
4871bis, in order to make sure that it is seen.

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Jim Fenton]

  On 10/15/10 2:12 AM, Alessandro Vesely wrote:
> On 14/Oct/10 20:40, Barry Leiba wrote:
   6.1.1 Validate the Message Syntax

   The verifier SHOULD meticulously validate the format of the message
   being verified against the requirements specified in [RFC5322],
   [RFC2045], and [RFC2047].  In particular, limitations on the number of
   occurrences of particular header fields specified in [RFC5322] section
   3.6 SHOULD be verified. Messages found to be in violation of these
   checks MUST return a PERMFAIL (message syntax error) verification result.
>>>   -1
>>>
>>>   If we go for changing the protocol in order to avoid the exploit, we
>>>   should explicitly enumerate the header fields whose duplication
>>>   verifiers MUST check.  "SHOULD meticulously validate" + "MUST return
>>>   PERMFAIL" make for a fuzzy protocol.
>> I think this is clear in Jim's text, and not contradictory or fuzzy at
>> all.  They SHOULD check.  If they check and the message violates the
>> checks, they MUST return a PERMFAIL.  Where's the contradiction or
>> confusion?
> Fuzziness stems from the fact that a signature on a given message may
> either verify or not depending on how meticulously the verifier
> interprets that "SHOULD".  The "MUST" immediately following it is
> deceptive because it conveys the false impression that a signature is
> REQUIRED to fail in case a particular header field is added after signing.
>
> Because of the SHOULD, existing verifiers can still be considered
> compliant.  Thus, it may still make sense for a signer to still put
> "h=from:from".  Why did Jim remove that advice?

I wanted it to be clear that it's the verifier's job to detect the 
duplication, not the signer's job to work around the problem.  Recall 
that SHOULD means, roughly "Do it unless you have a valid reason not to, 
and have considered the implications."

Besides, as Mark Delany said yesterday, having to do

h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id

"strikes me as an ugly hack."

>>>   The spec should also state whether duplicated fields invalidate a
>>>   signature even when they are duly signed.
>> It does.  A message that has two "From" lines, for example, is in
>> violation of RFC 5322.  It makes no difference whether it's signed or
>> not.  RFC 5322 (and the other specs) doesn't know about the signature
>> and doesn't care, and anything that checks compliance with it doesn't
>> care either.
> MUAs often disallow writing a "From" with multiple mailboxes, thus a
> sender may happen to end up with two "From" fields after hacking in an
> attempt to recognize authorship to a second mailbox.

Are you saying that there are MUAs that disallow a From: with multiple 
addresses, but support the addition of multiple From: header fields?  If 
so, I hope it's not a popular MUA that's doing this.

-Jim

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Jim Fenton]

  On 10/15/10 6:06 AM, Charles Lindsey wrote:
> On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton  wrote:
>
>> 8.14.  Attacks Involving Addition of Header Fields
>>
>> Many email implementations do not strictly enforce the message syntax
>> specified in [RFC5322]. One potentially exploitable consequence of this
>> is that an attacker who is capable of modifying a message in transit
>> could insert additional header fields that, if properly placed, could be
>> rendered to the recipient in preference to the originally signed header
>> fields.
> I don't quite see what an attacker can usefully do by modifying messages
> in transit. If they message was already signed (say by ebay), then the
> attacker must somehow get ebay to sign a message with a useful (to him)
> text in its body. So what is the benefit to him of making it appear From:
> someone who is not Ebay (except maybe to ensure that replies get sent to
> him - since I assume that MUAs that only display the first header will
> also Reply-To that header)?

An attacker could compose a message from some other domain with a good 
reputation, and add a From header indicating it's really authored by 
someone at a different domain (say by ebay). Even if ebay has an ADSP 
record, it's possible that the invisible (originally)  From address 
would be used to in the author signature check, which would pass.

I'm also concerned about other header fields, like Subject, where a 
one-line spam could be substituted as the visible subject line for a 
signed message.


> So I think there is a wide range of possible attacks involving duplicated
> headers, and the text needs to be general enough to cover them.

Agree.

>> Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):
>>
>> 6.1.1 Validate the Message Syntax
>>
>> The verifier SHOULD meticulously validate the format of the message
>> being verified against the requirements specified in [RFC5322],
>> [RFC2045], and [RFC2047].  In particular, limitations on the number of
>> occurrences of particular header fields specified in [RFC5322] section
>> 3.6 SHOULD be verified. Messages found to be in violation of these
>> checks MUST return a PERMFAIL (message syntax error) verification result.
> I have a problem with "meticulously validate". That is so hard to do that
> most implepemters will take advantage of that "SHOULD" and omit the tests.
> Much better to specify a less meticulous validation (header counting for
> example) and then elevate that "SHOULD" to a "MUST".

We can drop the "meticulously" part.  It was put there for consistency 
with the validation of the signature header field (current section 
6.1.1) but I agree, probably isn't a practical requirement.



> Here is an alternative text that I published on Oct 6th (and on which
> nobody commented). It is intended to go in section 6.1.1, presumably after
> the paragraph beginning "If the "h=" tag ...":
>
> "If the "h=" tag includes any header field for which, according to
> [RFC5322], the maximum number within the header section is limited to 1,
> and if more than 1 occurrence of that header field is present in the
> message, the verifier MUST ignore the DKIM-Signature header field and
> return PERMFAIL (multiple occurrences of XXX header field). Moreover, it
> SHOULD so treat any header field defined in any other standards track
> document to have a maximum occurrence of 1."
>
> If you think that is a bit too vicious, here is a slightly more
> permnissive version:
>
> "If the "h=" tag includes any header field for which, according to
> [RFC5322], the maximum number within the header section is limited to 1,
> and if the number of occurrences of that header field present in the
> message exceeds its number of occurrences in the "h=" tag, ..".

The header field limitations are more complex than that (see 
Resent-Sender). I prefer to more simply refer to the appropriate section 
of RFC 5322 and say that it must be adhered to.

-Jim

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

Re: [ietf-dkim] Last call comment: Changing the g= definition

[Jim Fenton]

  On 10/14/10 3:30 PM, John R. Levine wrote:
>> No, that doesn't solve the problem for all of the implementations
>> that are out there now that implement 4871. Removing g= is only going
>> to make the situation even worse because you've now taken away the
>> documentation.
> I wouldn't be opposed to moving it to an appendix of deprecated features,
> if for nothing else to ensure that some future DKIM++ doesn't
> inadvertently reuse g= to mean something else.

Isn't that what the IANA registry is there to prevent?

-Jim

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

Re: [ietf-dkim] Last call comment: Changing the g= definition

[Jim Fenton]

  On 10/14/10 6:30 AM, Dave CROCKER wrote:
>
> On 10/14/2010 9:05 AM, Tony Hansen wrote:
>> Is it still worth changing that section into a WARNING
>> for people upgrading from DomainKeys, saying to make darn sure that they
>> REMOVE g=; in their old DNS records because of interoperability issues?
>>
>> So the question becomes: if we remove the section on how DKIM and DK can
>> play nice together, 1) do we chop out all references to DomainKeys, or
>> 2) do we keep a short warning on what needs to be changed in the DK
>> record to make it work with DKIM?
>
> For pragmatic guidance text that is not essential for direct implementation, 
> I'm
> finding myself increasingly fond of the idea of putting such wisdom into the
> Deployment document...

On the other hand, we have a fair amount of guidance (in the form of 
informative notes) in the spec already, and having it here would make it 
more likely to be seen.  This is short; we're talking about a couple of 
sentences here.

-Jim

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Jim Fenton]

  On 10/13/10 4:32 PM, Murray S. Kucherawy wrote:
>
> It seems to me you're saying the same thing bis-02 is saying, but with 
> perhaps less terse language.  In particular, bis-02 says "SHOULD NOT 
> validate" something that's malformed, while you're saying "SHOULD" validate 
> format before processing.  Those sound the same to me, but if people like 
> this expression of it better then I'm also happy with it.

Correct; I had problems with the wording and organization but not the 
intent.

> You're right about splitting the verifier advice out to Section 6.  Good 
> point.  And your rewrite of 8.14 is cleaner than what we have now.
>
> I agree that using a MUST is too strong; not only is it a very hard 
> requirement to achieve but it wanders into the realm of making DKIM modules 
> responsible for 5322 enforcement, and I don't like that at all.  Thus I think 
> SHOULD is appropriate, and MAY is even more so (but I'll settle for the 
> former).
>
> A minor point: I would like your proposed 5.3 and 6.1.1 (should that be 
> 6.1.2?) text to contain something like "See Section 8.14 for further 
> discussion."

I'm fine with that.  You may have picked up an inconsistency in section 
numbers between 6.1.1 and 6.1.2 because I was having trouble deciding 
whether to put this new section before or after the existing 6.1.1.

-Jim

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Jim Fenton]

  On 10/12/10 7:58 PM, Murray S. Kucherawy wrote:
> You're right, it's not limited to From:, but 8.14 only uses that as an 
> example. It does also contain a more general description of the issue.
> If the diff from RFC4871 doesn't say the right thing, can you propose 
> alternate text?

Here's some text I propose for section 8.14, in place of the current 
text. Bear in mind that this is in the context of the Security 
Considerations section of the spec, so it is really a discussion of the 
threat and how it is dealt with, rather than normative text.

I went back and looked at the corrected text Dave Crocker sent for 
section 5.3.  Most of this is good advice, but section 5.3 is in the 
context of section 5, "Signer Actions", and is therefore the wrong place 
to add normative language for verifiers.  So I have added a new section 
6.1.1 that adds the requirement for message syntax checking to 
verifiers.  I'm open to suggestions on the strength of the verification 
requirement; I made it a SHOULD, but perhaps it should be a MUST.  I'm 
reluctant, however, to point at three sizable specifications and say 
that the verifier MUST check everything; that sounds like an 
unverifiable requirement.  I'm open to ideas.
=

8.14.  Attacks Involving Addition of Header Fields

Many email implementations do not strictly enforce the message syntax 
specified in [RFC5322]. One potentially exploitable consequence of this 
is that an attacker who is capable of modifying a message in transit 
could insert additional header fields that, if properly placed, could be 
rendered to the recipient in preference to the originally signed header 
fields.

According to [RFC5322] section 3.6, certain header fields, including 
 From and Subject, MUST appear a maximum of once per message.  It is 
therefore possible for a verifier to detect the insertion and as 
discussed in Section 6.1.2, DKIM verifiers are expected to return a 
verification failure when the invalid insertion of signed header fields 
occurs.

Multiple occurrences of other header fields are not similarly 
constrained.  Should the signer wish to render a signature invalid if a 
particular header field is added, the signer has the option of listing 
the name of that header field (or an additional instance of it) in the 
h= value as discussed in Section 3.5.
=
Suggested update to paragraph 2 of section 5.3:

Similarly, a message not compliant with [RFC5322], [RFC2045], and 
[RFC2047] can be subject to attempts by intermediaries to correct or 
interpret such content. See the Section 8 of [RFC4409] for examples of 
changes that are commonly made. Such "corrections" may break DKIM 
signatures or have other undesirable effects. Therefore, a DKIM signer 
SHOULD confirm that a message is compliant with those specifications 
prior to processing. 
=

Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):

6.1.1 Validate the Message Syntax

The verifier SHOULD meticulously validate the format of the message 
being verified against the requirements specified in [RFC5322], 
[RFC2045], and [RFC2047].  In particular, limitations on the number of 
occurrences of particular header fields specified in [RFC5322] section 
3.6 SHOULD be verified. Messages found to be in violation of these 
checks MUST return a PERMFAIL (message syntax error) verification result.


-Jim




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

Re: [ietf-dkim] Last call comment: Changing the g= definition

[Jim Fenton]

  On 10/13/10 1:03 PM, Barry Leiba wrote:
> I thought we'd had this discussion before, and what's there was what
> we decided to do.  Search facilities are inadequate for easy checking.
>   I certainly think that pointing out the ambiguity issue is important,
> so I, as a participant, wouldn't want to remove it entirely.  Allow me
> to suggest the following alternative text, and ask other participants
> to weigh in on which you prefer:
>
>
> 3.6.1.1. Compatibility Note for DomainKeys
>
>Key records for DKIM are backward-compatible with key records
>for the now-obsolete DomainKeys [RFC4870], except in one
>circumstance: DomainKeys interpreted an empty "g=" value to
>match any signing address ("i=" in the signature).  In DKIM, that
>matching is done by "g=*", or by omitting "g=" and taking the
>default behaviour.  An empty "g=" value in DKIM will match only
>empty "i=" values.
>
>If a key record uses an empty "g=" value and also uses "v=",
>the key record can be identified as belonging to DKIM, and the
>DKIM interpretation will be used.  Absent a "v=" tag, though,
>the verifier cannot tell whether the signer intended the
>DomainKeys interpretation or the DKIM one.
>
>To avoid second-guessing in a security context, and because
>DomainKeys is an obsolete protocol, DKIM verifiers MUST
>interpret this situation in DKIM terms, matching only
>empty "i=" values.


Clarifying question:  What does "this situation" (in the last paragraph) 
refer to:  the use of an empty "g=" value, or an empty "g=" value absent 
a "v=" tag?

-Jim

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

Re: [ietf-dkim] Collected data

[Jim Fenton]

  On 10/13/10 10:53 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Jim Fenton
>> Sent: Wednesday, October 13, 2010 10:42 AM
>> To: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Collected data
>>
>> [sticking with Murray's subject line so as not to create two thread
>> breakages!]
>>
>> I don't have any data on how many messages had DK signatures as well as
>> DKIM signatures, but at least some do (I checked some I received). I
>> don't quite understand your question.  The ambiguity that is created
>> has to do with the DKIM result, not the DK result.
> With this change, a DKIM signature referencing a "g=" key might verify if the 
> verifier elects to enable this backward compatibility feature.
>
> Without this change (i.e. the more strict posture), a DKIM signature 
> referencing a "g=" key won't verify ever.  But that's the same as an unsigned 
> message.
>
> The harm in the apparent ambiguity seems minimal; it's no worse than if the 
> signature or key was completely malformed somehow.  So is the distinction 
> important?

With this change, a message signed referencing one of these keys MAY 
verify.  Wouldn't a signer want to fix the problem anyway (remove the 
empty g=), in order to have their signatures verify more consistently?

It also adds more complexity to the specification and to 
implementations.  Besides, DK compatibility should become less of an 
issue with time since it is a legacy protocol.

-Jim

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

Re: [ietf-dkim] Last call comment: Changing the g= definition

[Jim Fenton]

  On 10/13/10 9:53 AM, Barry Leiba wrote:
>> If a v= value is not found at the beginning of the DKIM key record,
>> the key record MAY be interpreted as for DomainKeys [RFC4870].  The
>> definition given here is upwardly compatible with what is used for
>> DomainKeys, with the exception of the "g=" value.  In a DomainKeys
>> key record, an empty "g=" value would be interpreted as being
>> equivalent to DKIM's "g=*".
> ...
>> I'm not in favor of creating an ambiguity in the specification in order
>> to accommodate a limited number of domains that can make a very simple
>> correction to their key records.  Especially when the majority of these
>> domains are represented by a single email sending provider that
>> obviously hasn't even taken the trouble to see whether their signatures
>> verify.
> What, specifically would you like to have done with the text?

I propose removing section 3.6.1.1 in its entirety.

-Jim

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

Re: [ietf-dkim] Collected data

[Jim Fenton]

  [sticking with Murray's subject line so as not to create two thread 
breakages!]

On 10/12/10 11:29 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Jim Fenton
>> Sent: Tuesday, October 12, 2010 9:53 PM
>> To: IETF DKIM WG
>> Subject: [ietf-dkim] Last call comment: Changing the g= definition
>>
>> Between June 1 and September 1, 2010, Cisco received invalid signatures
>> from 632 domains with "inapplicable keys" (meaning a g= mismatch). For
>> comparison, during that same period we received valid signatures from
>> 33054 domains.  [...]
> We don't track selector names, but our numbers are for the last six weeks, 
> during which time we saw 18198 unique signing domains and 370 unique domains 
> that sent signatures which failed due to the same cause.  Very similar data.
>
>> Going back to the proposed change, it would create an ambiguity in the
>> spec:  If a domain has a selector record with g=; and no v= tag, the
>> verifier MAY return a pass result.  Or it MAY return a fail result.  We
>> don't know what to expect; the result is undefined.  Signers are not
>> well-served by mechanisms that don't consistently work.
> We're talking about a DomainKeys signer here though, not a DKIM signer.  
> Since we're trying to be accommodating to a protocol DKIM ultimately 
> replaced, does it still create a problem?
I don't have any data on how many messages had DK signatures as well as 
DKIM signatures, but at least some do (I checked some I received). I 
don't quite understand your question.  The ambiguity that is created has 
to do with the DKIM result, not the DK result.

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Jim Fenton]

  On 10/13/10 8:04 AM, John Levine wrote:
>> Subject: Buy fake watches at fakewatch.example.com!
>>
>> Will some clients display the second subject line?  I suspect some
>> will.  Do we need to recommend that signers also add a protective second
>> subject: to their h= value?  Or do we need to require that verifiers
>> make sure that any header fields that are signed and aren't supposed to
>> be duplicated, aren't?  I'm not sure, but right now I'm leaning toward
>> the latter.
> I went through pretty much the same thought process and came to the
> same conclusion.
>
> It seems to me that there are some fairly cheap extra checks tht a
> verifier can make that will defend against malformed mail that would
> be likely to display confusingly in an MUA.  Yes, it's technically not
> DKIM's job to verifiy 5322 conformance of incoming mail, but as Barry
> noted, it's not anyone else's job, either.

My inclination is that the spec should say something like:

- The verifier SHOULD consider the signature invalid if a signed header 
field occurs an inappropriate number of times in the message header 
according to section 3.6 of RFC 5322.
- The verifier MAY consider the signature invalid if it detects other 
message syntax violations of RFC 5322.
- (??) The verifier SHOULD consider the signature invalid if the List-Id 
header field is signed and occurs more than once in violation of RFC 2919.

The last provision worries me a bit because it opens the door to other 
specifications that define header fields. On the other hand, I can 
picture an attack involving insertion of a bogus List-Id header field in 
order to influence the handling of the message.

The overall philosophy here is to strongly encourage verifiers to watch 
for this attack while not making current DKIM implementations obsolete, 
but without requiring essentially open-ended syntax checking of message 
by DKIM verifiers.

-Jim

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

[ietf-dkim] Last call comment: Changing the g= definition

[Jim Fenton]

  This is a comment on the new section 3.6.1.1, "Compatibility Note for 
DomainKeys", that suggests a different interpretation of the g= tag in 
the key record if the v= value is not present at the beginning of the 
record.  The section says:

If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870].  The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the "g=" value.  In a DomainKeys
key record, an empty "g=" value would be interpreted as being
equivalent to DKIM's "g=*".

For about the past year, I have been monitoring Cisco's DKIM 
verification and have collected data on verification and on verification 
errors.  An early summary of that effort is at 
http://blogs.cisco.com/security/common_errors_causing_dkim_verification_failures/

Between June 1 and September 1, 2010, Cisco received invalid signatures 
from 632 domains with "inapplicable keys" (meaning a g= mismatch). For 
comparison, during that same period we received valid signatures from 
33054 domains.  Of these 632 domains, 390 use the same selector name, 
which corresponds to the name of an email sending provider that has 
gotten these domains to publish key records for its use.  I have 
contacted this email sending provider twice to make them aware of the 
problem, but have apparently not succeeded in getting them to fix it.  
All they need to do is remove the g=; tag from the selector records and 
they will be compatible with both DomainKeys and DKIM.

Going back to the proposed change, it would create an ambiguity in the 
spec:  If a domain has a selector record with g=; and no v= tag, the 
verifier MAY return a pass result.  Or it MAY return a fail result.  We 
don't know what to expect; the result is undefined.  Signers are not 
well-served by mechanisms that don't consistently work.

I'm not in favor of creating an ambiguity in the specification in order 
to accommodate a limited number of domains that can make a very simple 
correction to their key records.  Especially when the majority of these 
domains are represented by a single email sending provider that 
obviously hasn't even taken the trouble to see whether their signatures 
verify.

-Jim

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

[ietf-dkim] Last Call comments on draft-ietf-dkim-rfc4871bis-02

[Jim Fenton]

  I'll go through my comments on rfc4871bis in this message, but will 
split a couple of the larger comments out into separate messages.

Section 2.3, Identity: I realize this is taken from RFC 5672, but the 
definition is not clear to me.  Suggest that the second sentence read, 
"Identities that may be associated with DKIM signatures include authors 
and their organizations, ISPs along the message handling path, and 
mailing list operators." (I'm not sure how the independent trust 
assessment services apply here, since their assessment happens AFTER 
signature verification).

Section 3.3: Is there now no requirement on hash algorithms that must be 
implemented by verifiers?  If the requirement for verifiers to implement 
rsa-sha1, the informative note acknowledging a preference to use sha1 on 
low-security messages such as newsletters doesn't make sense.  It should 
probably be removed.

Section 3.3.1:  rsa-sha1 should probably be marked as deprecated if no 
longer required by 3.3.

Section 3.4.5:

a=: Why has the ABNF been changed from sig-a-tag to a-tag?  It is 
inconsistent with the ABNF for all of the other tags.

d=: The introductory phrase of all of the tag definitions is a phrase, 
not a sentence with a verb.  Remove the word "Specifies" and capitalize 
"the" (nit).  Also s/address-literall/address-literal/

h=: The definition of hdr-name has gone away; is it defined elsewhere?

i=: second paragraph, "or a subdomain of the value of" is an essential 
phrase and should not be set off by commas.  Also in the informative 
note, "in come cases" should not be set off by commas.

z=: Where has the definition of qp-hdr-value gone?  It is also needed 
for the q= tag.

3.6.1.1:  I have a problem with this new provision for g= but that is a 
longer discussion for a separate message.

3.8: "or a subdomain of" should not be set off with commas. (This was in 
4871 as well).

3.9 paragraph 2: s/hnamas/has/

3.9: Paragraph 3 makes it sound like it conveys the SDID regardless of 
whether the signature verifies or not, and does not require the result 
(pass/fail) of the verification to be reported.  I suggest that the SDID 
only be reported if the verification was successful, in order to 
discourage assessors from inappropriately using the SDID of an invalid 
signature for anything.

3.9 Paragraph 4 + informative discussion seem to wander off into the 
realm of how (or more accurately how not) to use the results from DKIM.  
This text was in 5672, so there may already be WG consensus for 
including it, but I'd rather see this sort of thing in the operations 
spec (RFC 5863).  If fact, it is already there, although it references 
back to the text I'm talking about.

5.3 paragraph 2 first sentence doesn't make any sense.  Use either 
"conformant" or "compliant", but be consistent.  This paragraph needs a 
fair amount of work yet.

6.3 paragraph 5 has changed "signing identity" to SDID.  The signing 
identity really corresponds to the AUID.  As currently worded, the mail 
system is advised to take pains to ensure that the SDID is displayed for 
a message signed on behalf of a subdomain; this isn't necessary.  Given 
the WG's past consensus to ignore the local part of the AUID, I suggest 
the following wording for the last sentence of the paragraph: "If the 
domain of the AUID is not the same as domain of the address in the From: 
header field, the mail system SHOULD take pains to ensure that the 
actual AUID domain is clear to the reader."

8.14 needs some editing work and I don't think characterizes the threat 
quite accurately.  I have jumped into the active thread on this section 
to discuss that.

Appendix C, there is a stray "[" character in one of the sample outputs, 
just before -BEGIN PUBLIC KEY-




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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Jim Fenton]

  On 10/12/10 7:58 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Jim Fenton
>> Sent: Tuesday, October 12, 2010 5:29 PM
>> To: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
>>
>> The problem isn't limited to From, I suspect.  One attack that we had
>> considered early on was the modification of Subject, since it is
>> prominently displayed to the user.  We don't require signing of
>> Subject,
>> but it is recommended in section 5.5.  Suppose an attacker adds an
>> additional Subject header field, like:
>>
>> Subject: Buy fake watches at fakewatch.example.com!
>>
>> Will some clients display the second subject line?  I suspect some
>> will.  Do we need to recommend that signers also add a protective
>> second
>> subject: to their h= value?  Or do we need to require that verifiers
>> make sure that any header fields that are signed and aren't supposed to
>> be duplicated, aren't?  I'm not sure, but right now I'm leaning toward
>> the latter.
> Doesn't the text added to Section 5.3, which ends with "a verifier SHOULD NOT 
> validate a message that is not conformant", and the text added as Section 
> 8.14, make it clear that some agents forgive such malformations with 
> detrimental side effects, especially in MUAs, and thus admonish verifiers not 
> to validate such messages?  I'm not clear on what you're saying is missing 
> here.

I had trouble understanding that paragraph.  I couldn't parse the first 
sentence at all.  Then I got distracted by the mixed use of "compliant" 
and "conformant" and tried to guess whether those were the same thing.  
So I wasn't paying attention to this.  I'll be sending out a last call 
response in a little while, and those comments are included there.

> Section 5.3's new text warns everyone, but especially verifiers, to check for 
> these abnormalities.  Section 8.14 goes into detail about the issue, and 
> provides signers with a mechanism for guarding against it in case there are 
> verifiers that are not so careful.  So it seems to be both ends are addressed 
> by the proposed text.

As you point out, both 5.3 and 8.14 address this issue, but they're in 
separate places in the document. 8.14 refers to 5.2 and says that "DKIM 
processing is predicated on a valid email message" which, yes, says that 
signature verification should fail, but IMO not nearly clearly enough.  
Instead 8.14 goes into detail about how to force verification to fail if 
a duplicate header field is inserted (which is also covered in the 
description of h= in section 3.5).

The attack doesn't really have anything to do with the fact that the 
 From header field must be signed; the attack can be done on any signed 
header field that must be unique.


> I think the case you reference as "latter" here is actually the enforcement 
> of RFC5322 validity, and I agree that this should be done by anything that 
> handles the message.
>
> You're right, it's not limited to From:, but 8.14 only uses that as an 
> example.  It does also contain a more general description of the issue.

I missed the "for example" at the beginning of the paragraph.  It's easy 
to jump to the conclusion that From is the only special case because 
it's the only header field required to be signed.


> If the diff from RFC4871 doesn't say the right thing, can you propose 
> alternate text?

I'll write something tomorrow.

-Jim

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Jim Fenton]

  On 10/12/10 11:21 AM, Murray S. Kucherawy wrote:
> (Barry Leiba said:)
>> -1; I like the wording that's there.
> Concur; -1 on the change.  I furthermore submit that we are compelled to 
> describe the known "attack", as that's precisely what we are supposed to 
> include in Security Considerations.

I'm somewhere in the middle; I don't agree with Hector and I don't like 
the wording that's there either.

Let's consider what a Bad Actor might try to do and what the result 
might be.

Suppose that a Bad Actor successfully inserted a second From header 
field in such a way that the user's MUA displayed it in place of the 
original, signed, From header field.

If the added From header field is from a different domain than the SDID, 
then the advice in section 6.3 paragraph 5 applies: "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." (I'm seeing a problem with this wording now too, but I 
digress.)  Presumably this applies to whatever From header field is 
going to be displayed.

If the added From header field is from the same domain as the SDID, 
there's a different problem.  Perhaps the message had an Author 
Signature and the attacker intended to masquerade as a different user in 
that domain.   But since we don't use the local part to establish what 
is and isn't an Author Signature (i.e., we don't look at the local part 
of i=) that's not a problem that DKIM is designed to address.

The problem isn't limited to From, I suspect.  One attack that we had 
considered early on was the modification of Subject, since it is 
prominently displayed to the user.  We don't require signing of Subject, 
but it is recommended in section 5.5.  Suppose an attacker adds an 
additional Subject header field, like:

Subject: Buy fake watches at fakewatch.example.com!

Will some clients display the second subject line?  I suspect some 
will.  Do we need to recommend that signers also add a protective second 
subject: to their h= value?  Or do we need to require that verifiers 
make sure that any header fields that are signed and aren't supposed to 
be duplicated, aren't?  I'm not sure, but right now I'm leaning toward 
the latter.

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

Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-02.txt

[Jim Fenton]

  On 10/11/10 11:46 PM, Barry Leiba wrote:
> On Mon, Oct 11, 2010 at 4:44 PM, Jim Fenton  wrote:
>>   There's a Working Group Last Call in effect for -01.  Should we:
>>
>> - Continue to direct comments at -01
>> - Comment on -02 instead
>> - or will the WGLC be restarted on the -02 draft?
> I think it's not necessary for us to restart, but reviews should now
> go against -02.

Thanks for clarifying.

Dave, could you then update the diffs at 
http://dkim.org/specs/rfc4871-to-bis-diff.htm to show the diffs from -02 
to RFC 4871?  It would be nice to see all of the differences in one place.

-Jim

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

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-03.txt

[Jim Fenton]

  The same question on Working Group Last Call applies here as well.

Abort, retry or ignore?  :-)

-Jim

On 10/11/10 12:30 PM, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Keys Identified Mail Working Group of 
> the IETF.
>
>
>   Title   : RFC4871 Implementation Report
>   Author(s)   : M. Kucherawy
>   Filename: draft-ietf-dkim-implementation-report-03.txt
>   Pages   : 17
>   Date: 2010-10-11
>
> This document contains an implementation report for the IESG covering
> DomainKeys Identified Mail (DKIM) in support of the advancement of
> that specification along the Standards Track.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-02.txt

[Jim Fenton]

  There's a Working Group Last Call in effect for -01.  Should we:

- Continue to direct comments at -01
- Comment on -02 instead
- or will the WGLC be restarted on the -02 draft?

-Jim

On 10/11/10 10:47 AM, Dave CROCKER wrote:
>
>> Title: DomainKeys Identified Mail (DKIM) Signatures
>> Author(s): D. Crocker, M. Kucherawy, T. Hansen
>> Filename: draft-ietf-dkim-rfc4871bis-02.txt
> ...
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-02.txt
>
>
> Folks,
>
> Attached is the diff of the -02 version with the -01 one.
>
> d/
>
>
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Working group last call on draft-ietf-dkim-rfc4871bis

[Jim Fenton]

  The diffs at http://dkim.org/specs/rfc4871-to-bis-diff.htm and the 
differences between 4871 and the -00 version of the draft, not the Last 
Call revision.

Dave Crocker, can you update the diffs please?

-Jim

On 10/4/10 5:53 AM, Barry Leiba wrote:
> Thus begins working group last call on the DKIM-base update,
> draft-ietf-dkim-rfc4871bis-01:
> http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis
> The working group last call will run through Friday, 22 October, 2010.
>
> This is the version of the specification that will be advanced to
> Draft Standard.  Everyone please review it, and post comments/issues.
> Please also post here if you've reviewed it and think it's ready to
> go.
>
> There is one outstanding discussion on the -01 version:
> http://mipassoc.org/pipermail/ietf-dkim/2010q4/014608.html
> Please comment specifically on that, stating whether you agree with
> the proposed change or prefer leaving the text as it is.  Remember
> that a change will NOT be made without support, so if you like the
> change it's important to say so.
>
> Because this is moving the existing specification along the standards
> track, substantive changes are explicitly out of scope unless someone
> uncovers a serious error in the protocol.  In scope are clarifications
> and editorial issues.
>
> So: everyone please review draft-ietf-dkim-rfc4871bis-01, and comment
> here by 22 October.  Thanks.
>
> Barry, as chair
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM errata 1532 and 1596

[Jim Fenton]

Murray S. Kucherawy wrote:
> Hi Jim,
>
> I'm not clear on the objection here.  In particular, it seems to me Barry's 
> proposed language lines up nicely with what you said starting "but rather".
>   

My point is that it's already possible for the same selector record to 
be used for both DK and DKIM.  Just leave the "g=;" out of the key 
record.  It's not necessary for DK in any case.

> As for the statement that the result would be undefined, I'm also unclear.  
> Are you saying two different implementers might do two different things 
> because of that MAY?  If that's the case, then I think we're in some trouble 
> because (for example) there's a MAY in the definition of "x=" that permits 
> two results if the signature has expired.
>   

I have never been clear on the value of x= (especially since it says 
it's not intended as an anti-replay defense), but you are correct that 
the spec is ambiguous as to whether a signature with an expired x= is 
valid or not.  I would lean in the direction of correcting that 
ambiguity, rather than creating a new one.

As everyone is probably tired of hearing me say, I'm all for looking for 
reasons to call a signature valid rather than invalid.  But there gets 
to be a point where it's really easy for the signer to fix the problem, 
and they haven't bothered to.  I don't have a lot of sympathy for 
signers who aren't willing to do even a tiny bit of diligence to make 
sure that their signatures are valid.  I don't think we should change 
the spec to accommodate them.

-Jim

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

Re: [ietf-dkim] DKIM errata 1532 and 1596

[Jim Fenton]

Barry Leiba wrote:
> --- 1532
> What Tony says is not consistent with the WG consensus, which was NOT
> to REQUIRE the presence of "v=DKIM1", and the text (Tony's "N/A"
> notwithstanding) makes it clear that the absence of v= is interpreted
> as "v=DKIM1".
>
> He's correct, though, that the intent was for the DKIM key record to
> be backward compatible with DK (RFC 4870, Historical), but that the g=
> tag screws that up.  Perhaps what would be correct to say is this,
> added after the g= paragraph and before its ABNF:
>
>   Exception: if "g=" is specified with an empty value AND there is NO "v="
>   specified at all, implementations MAY interpret this in the context of
>   DomainKeys [RFC4870], treating it as DKIM's "g=*".
>   

I disagree with this proposed resolution.  I don't interpret backward 
compatibility as meaning that every DK selector must be usable with 
DKIM, but rather that it should be possible for the same selector record 
to be used by both DK and DKIM.

In any case, the change you're proposing introduces an ambiguity in the 
specification:  Under the circumstances cited, the verification result 
from DKIM is undefined.  That's a poor statement for a standard to make.

It's true that key records with empty g= values do contribute to 
verification failures; see

http://blogs.cisco.com/security/comments/common_errors_causing_dkim_verification_failures/

for a discussion of this.  The error we're talking about here is 
"inapplicable key".

As the discussion notes, there's an ESP out there that is giving their 
customers key records to publish that have empty g= values.  Yesterday, 
this single ESP accounted for 72% of all the Inapplicable Key errors we 
saw at Cisco.  I contacted this ESP last fall, and they have not 
corrected the problem.

There are lots of other syntax errors we see as well.  I don't think 
it's worth introducing an ambiguity in the specification to compensate 
for an easily correctable problem.  Do we next introduce a change in the 
spec to compensate for those that are publishing key records with 
extraneous backslashes?

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

Re: [ietf-dkim] Call for agenda items

[Jim Fenton]

Barry Leiba wrote:
> I'd like to hear about other agenda items people have to propose, or
> any other comments about the skeleton agenda below.  I'd also like a
> sort of "show of hands" to let me know who's going to be attending in
> person, and who will participate remotely, using the audio stream or
> jabber.  Please reply to this thread with answers to these questions,
> and other issues directly related to the Maastricht meeting.  (Please
> take any other discussion to a separate thread.)
>   

I plan on attending remotely via the audio stream and Jabber.

-Jim

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

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

[Jim Fenton]

MH Michael Hammer (5304) wrote:
>
> I'm still waiting for someone to produce use numbers (of domains) for
> ADSP. Just out of curiosity, what number do we have to reach to hit the
> technical term "massive"? Somehow I doubt that in it's current
> incarnation ADSP will ever have massive implementation.
>   

I recently surveyed the domains from which Cisco has received valid DKIM 
signatures:

dkim=unknown: 205 domains
dkim=all: 135 domains
dkim=discardable:  63 domains

There are perhaps some other domains that are publishing 'discardable' 
because they don't send any mail, but we wouldn't have seen them in this 
study.

There's only a weak motivation (involving better DNS caching) for 
publishing dkim=unknown, so it's hard to gauge ADSP deployment by that 
number.  In order to publish all or discardable, the domain's practices 
need to align with that, so unless there's a way to tell that a domain 
is signing all their mail and not publishing ADSP then it's challenging 
to gauge ADSP deployment for either of these categories.

Addressing a question from elsewhere else in this massive thread, my 
home MTA runs the stock version of spamassassin that comes with Fedora 
12.  I haven't tweaked anything.  Assuming my reading of the 
configuration files is correct, spamassassin is querying ADSP for 
incoming mail, and applying a positive bump to the "spamminess" score 
when a message comes from a domain with dkim=all, and a bigger bump for 
dkim=discardable.  This could account for many of the adsp lookups that 
people are seeing.

-Jim


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

Re: [ietf-dkim] forward to friend, was besides mailing lists...

[Jim Fenton]

John Levine wrote:
>> F2F was created in a kinder, gentler time, when address spoofing
>> wasn't nearly as much of a problem as it is now.  The fact that F2F
>> hasn't evolved to avoid spoofing users' addresses is a problem that
>> is only made more tangible by email authentication.
>> 
>
> I have to agree with Mike (alert the media!) that this seems to be a
> solution looking for a problem.  There are F2F systems all over the
> net, and the amount of spam or hostile spoofage we get from them is
> trivial.
>   

To clarify my content, I'm not referring to spam or hostile spoofing 
from the F2F systems.  I'm referring to the spoofing done by F2F in an 
environment where there is a lot of spam/hostile spoofing elsewhere in 
the environment, and that F2F could be doing more to differentiate 
themselves from the bad stuff (use their own From address, for example).

-Jim

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

Re: [ietf-dkim] besides mailing lists...

[Jim Fenton]

Dave CROCKER wrote:
> On 4/30/2010 9:37 AM, Jeff Macdonald wrote:
>   
>> ESPs have a "forward-to-a-friend" feature for their clients. Its a
>> feature in which the ESPs creates the content and sends a message from
>> a friend, to a friend. It would be discarded. However, I'm willing to
>> say this is a bogus practice.
>> 
>
>
> F2F is a well-established and helpful feature.  That some uses of 
> receive-side 
> authentication cannot cope with it is a limitation of the 
> authentication-based 
> service, not a flaw in F2F.
>   

F2F was created in a kinder, gentler time, when address spoofing wasn't 
nearly as much of a problem as it is now.  The fact that F2F hasn't 
evolved to avoid spoofing users' addresses is a problem that is only 
made more tangible by email authentication.

Telnet (on port 23) was also a well-established and helpful protocol.  
But the threat landscape changed, and today few of us send our passwords 
in the clear.  The email threat landscape has similarly changed.

-Jim

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

Re: [ietf-dkim] DKIM errata 1532 (v= and DomainKeys)

[Jim Fenton]

pasi.ero...@nokia.com wrote:
> Jim Fenton wrote:
>
> Hmm -- back in IETF73 we seemed to agree (at least according to the
> email below) that guessing is, while probably not a good idea,
> possibly less bad than the alternative:
>
> http://mipassoc.org/pipermail/ietf-dkim/2008q4/010820.html
>   

Hmm, that's right; I had forgotten completely about that.  However, 
errata 1532 still shows up as "reported"; that means it still needs to 
be acted on, right?  I'm still not entirely clear on the process for errata.

-Jim

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

Re: [ietf-dkim] DKIM errata 1532 (v= and DomainKeys)

[Jim Fenton]

Mark Martinec wrote:
> The draft-ietf-dkim-deployment-11 says:
>If a DKIM verifier finds a selector record that has an empty "g"
>field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its
>beginning, it is faced with deciding if this record was
>
>1.  from a DK signer that transitioned to supporting DKIM but forgot
>to remove the "g" field (so that it could be used by both DK and
>DKIM verifiers), or
>
>2.  from a DKIM signer that truly meant to use the empty "g" field
>but forgot to put in the "v" field.  It is advised that you treat
>such records using the first interpretation, and treat such
>records as if the signer did not have a "g" field in the record.
>
>
> For this to work, it requires one to provide an explicit "v=DKIM1"
> when a empty "g=" is intentional.  On the other hand, the RFC 4871
> clearly marks the v tag as entirely optional (yet recommended).
>
> While I agree that a recommendation on how a verifier should handle
> empty g tag does not belong into RFC 4871 (but only in dkim-deployment),
> I think that a 4871 section 3.6.1 on tag g (or v) should require that
> a 'v' is mandated if an empty granularity 'g=' is (intentionally) used.
>   

I guess I should be paying more attention to the dkim-deployment drafts.

RFC 4871 is very explicit about the meaning of the g= value.  Last 
paragraph of section 3.2:

   Tags that have an empty value are not the same as omitted tags.  An
   omitted tag is treated as having the default value; a tag with an
   empty value explicitly designates the empty string as the value.  For
   example, "g=" does not mean "g=*", even though "g=*" is the default
   for that tag.

The semantics of g= has no dependency on the presence or absence of the 
v= tag/value.  One of the ways of revoking a DKIM key is to apply a null 
g= tag (g=;) which makes it unusable.  Coming up with a way of guessing 
whether the signing domain really meant "g=;" is not a good idea and 
contradicts the specification.

-Jim


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

Re: [ietf-dkim] Broken signature analysis

[Jim Fenton]

There are really two parts to this:  (1) How to do the analysis of what 
failed, and (2) How to report the failure to the signing domain.

(1) Assuming it's a signature failure and not a body hash failure, 
analyzing z= gives the best chance of finding the cause.  There are 
going to be a lot of failures that one can't diagnose that way, of 
course, but z= should help with enough of them to be worth trying.  Some 
tools might help, like something that does an automated comparison of 
the z= value in a signature with the corresponding header fields and 
reports any discrepancy.

The best thing about this is that z= is already in the spec.

(2) I wouldn't give up on the reporting mechanism too quickly due to the 
potential for abuse.  Perhaps the use of the reporting address could be 
constrained in such a way that abuse gets dropped more easily, since 
this isn't a general-purpose address that has to deal with all sorts of 
use cases.  So perhaps the messages get dropped if they're not 
authenticated (maybe use SPF here to drop messages as they're received, 
and tell admins not to do forwarding on the reporting address).  Maybe 
additionally rate limit by domain.  I'm just brainstorming; other ideas?

-Jim

Michael Thomas wrote:
> I'm sort of dubious about this. Unless you're using z=, your chances of
> figuring out why something broke are slim to none. With z=, your chances
> of figuring it out are merely slim.
>
> Mike, with far too much experience at that
>
> On 02/24/2010 02:17 AM, Suresh Ramasubramanian wrote:
>   
>> I support this. The rest of Barry's charter proposal is OK by me.
>>
>> thanks
>> suresh
>>
>> On Wed, Feb 24, 2010 at 3:27 PM, Franck Martin  wrote:
>> 
>>> Shouldn't we move forward Murray's draft "quickly" that allows to report 
>>> back broken DKIM signature to the validating domain?
>>>
>>> This would allow to collect information on why signature gets broken making 
>>> the DKIM draft stronger.
>>>
>>>   
>>
>> 
>
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] RFC5322 reference in RFC1652bis?

[Jim Fenton]

I'm missing a bit of context on this.  What's the impact on DKIM?

-Jim

Dave CROCKER wrote:
> Folks,
>
> The technical details of RFC1652bis must cite MIME AND SMTP, of course.  
> However 
> it happens that the details do not absolutlely need to cite RFC5322.
>
> However it strikes me as too strange to have a standard that pertains to 
> message 
> objects not cite the /message/ standard.
>
> I'd like to have RFC5322 cited at the time MIME is cited, as Ned suggested 
> privately:
>
>
>In
>particular, a significant portion of the Internet community wishes to
>exchange messages in which the content body consists of a MIME
>message [RFC2045][RFC2046][RFC 5322] containing arbitrary octet-aligned
>material.
>
>
> Does anyone object?
>
> d/
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Collecting re-chartering questions

[Jim Fenton]

As I have said before, I'm in favor of going dormant for a while (#10).

But if we don't, I'm in favor of #1 and #7 and various places between 
neutral and highly negative on the others.

-Jim

Barry Leiba wrote:
> 1. Advance DKIM base to Draft Standard
>
> 2. 3rd-party authorization label:
> https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-label/
> If you have not read this draft, please do; we'd like to get a good
> sense of whether to work on this.
>
> 3. Other 3rd-party signing issues (New protocol?  Info doc?)
>
> 4. Mailing list cohabitation ("dkim=except-mlist")
>
> 5. Other mailing list issues (info doc)
>
> 6. Specifying ADSP/forwarder guidelines for re-signing (is this
> different from mailing list issues?)
>
> 7. Collect data on deployment and effectiveness of DKIM base
>
> 8. Collect data on deployment and effectiveness of ADSP, and consider
> future of ADSP
>
> 9. Update overview and deployment/operations documents (info), as new
> data are collected.
>
> 10. Go dormant for a while, and revisit these questions in 8 to 12 months.
>
>
> Let the polling begin.
>
> Barry (and Stephen), as chairs
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Interesting Dupe Signatures

[Jim Fenton]

Barry Leiba wrote:

  
But I have to consider customer sites patterns with heavy facebook
users seeing tons of fb notifications and see if a simple check can
add to the optimization.

  
  
Mike has a point, but I agree that this would be a problem for large
ISPs, where adding 10% more overhead for all Facebook messages would
be something they'd want to avoid.  But...
  


I'd go a little further than this:  If you already have a valid
signature from a given domain, why check any more signatures from that
domain?  It doesn't tell you any more than you already know.  It
doesn't matter if the signatures are identical or not.

-Jim



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

Re: [ietf-dkim] DKIM charter update proposal

[Jim Fenton]

Dave CROCKER wrote:
>
>
> Jim Fenton wrote:
>> It's fairly easy to demonstrate interoperability of protocols, but
>> usefulness is much more difficult.  DKIM is an infrastructure protocol,
>> designed to provide a basis for other mechanisms, such as domain-based
>> reputation, to operate.  Those other mechanisms are as yet nascent; how
>> does one judge usefulness at this point?
>
>
> Jim,
>
> This appears to be imposing criteria that go considerably beyond the
> IETF's requirements for Draft.
>
> From the standpoing of IESG process, how is this legitimate?

Good question.  I wasn't proposing that we judge usefulness at all; I
was responding to suggestions from others that measuring usefulness be
included in the charter.

-Jim

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

Re: [ietf-dkim] DKIM charter update proposal

[Jim Fenton]

Barry Leiba wrote:
> Coming back to this: I've still seen very little direct input on the
> charter proposal.  JD likes it.  Dave made some specific comments,
> which I responded to; there've been no other comments on what Dave's
> said.  There've been no other specific proposals for changes to the
> text.
>
> Franck suggested gathering data on whether DKIM has been useful.  I
> responded to that, saying that I don't think it's a necessary issue
> for chartering at this stage.  Agreement or disagreement with that
> would be useful.
>
> Bill suggested looking at extensions for additional signature
> delegation, Michael Hammer agreed, and a thread branched off from
> there.  Is that still an active consideration for the charter, or not?
>  Charles wants to see something more about guidance for mailing lists.
>  Is that an active consideration?
>
> Some have opined that it's even too early to consider taking the base
> DKIM protocol to Draft Standard; let's make sure we have consensus on
> that point, one way or the other.
>   

I'm generally in this latter camp.  The six-month timer might be useful
for some protocols, but the huge installed base and mission-critical
nature of email causes everything to move more slowly from a deployment
standpoint.

It's fairly easy to demonstrate interoperability of protocols, but
usefulness is much more difficult.  DKIM is an infrastructure protocol,
designed to provide a basis for other mechanisms, such as domain-based
reputation, to operate.  Those other mechanisms are as yet nascent; how
does one judge usefulness at this point?

If this working group does continue, I'd suggest that updates to the
service overview (RFC 5585) and deployment/operations document also be
on the table.  Those are the most appropriate places for the results of
operational experience to be described.

To summarize, I support waiting at least a year, perhaps more, before
progressing the WG specifications.  Whether that means that the WG shuts
down and restarts or just goes dormant is a question for the IETF
process wizards.

-Jim


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

Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the receiving side

[Jim Fenton]

Murray S. Kucherawy wrote:

  
-Original Message-
From: i...@sussex.ac.uk [mailto:i...@sussex.ac.uk]
Sent: Wednesday, October 14, 2009 4:53 AM
To: Murray S. Kucherawy; John R. Levine; Daniel Black
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the
receiving side



  Another data point: Google Mail won't use ADSP because they will not
discard someone's mail outright without a written agreement from the
sending domain agreeing to same, absolving them of responsibility for
mail that never arrives.
  

You mean that they won't publish ADSP records? Or that they won't
respect
any ADSP records? Or that they won't discard "discardable" messages?

  
  
They won't honour ADSP "dkim=discardable" records posted by others.

  


I recall also having heard that they would like to get feedback on what
(and how much) is being discarded.  Something along the lines of
draft-shafranovich-feedback-report most likely, although someone would
need to confirm that's sufficient.  I'm not sure this WG is the place
to take that on as a work item, but if not here, where?

-Jim


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

Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)

[Jim Fenton]

Ian Eiloart wrote:
> --On 12 October 2009 10:04:17 -0400 Wietse Venema  
> wrote:
>
>   
>> Michael Deutschmann:
>> 
>>> If this is indeed the official semantics of the protocol, then I would
>>> petition to add a "dkim=except-mlist" policy.  Which means "I sign
>>> everything that leaves my bailiwick, but may post to signature-breaking
>>> MLs."
>>>   
>> Are you going to announce all your users mailing list subscriptions
>> in the policy record? If you do, that could be a privacy problem.
>>
>> If you don't, then the spammer can add any mailing list header to
>> the message, and they can drive their truck through this hole.
>>
>>  Wietse
>> 
>
> Surely that's OK, if that's the policy. The point is that the recipient 
> must assign reputation to the list, not the original sender. If the list 
> proves trustworthy (presumably it applies its own DKIM sig, or has an SPF 
> pass, and also has a good reputation with the recipient), then the 
> recipient might go on to assess the reputation of the author - on the basis 
> that a trusted list is likely to be making a DKIM assessment of inbound 
> mail.
>   

Agreed, but the fact that it's a mailing list that is doing this isn't
significant.  It could be any intermediary that is willing to take
responsibility for the message by signing it.  Their reputation now
becomes a factor in the disposition of the message.

-Jim

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

Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)

[Jim Fenton]

[Sending this from my home domain that publishes dkim=all ADSP. All 
those domains that are dropping messages that fail dkim=all probably 
aren't interested in this message anyway :-) ]

Dave CROCKER wrote:
>   
 People who contribute to mailing lists shouldn't say dkim=all.  We
 argued this ad nauseam when we were hammering out ADSP, it shouldn't
 come as a surprise to anyone.
 
[Mike Thomas wrote]
>>> That is not true at all. They shouldn't be using discardable. "All" only
>>> says what the sender does, not what the receiver should expect.
>>>   
+1

[John Levine wrote]
>> They certainly shouldn't be using discardable.  I would advise not using
>> all either, due to the observed tendency of people to pay way too much
>> attention to DKIM and ADSP failures.
>> 
I'm (obviously) not as much of a fatalist when it comes using dkim=all. 
I believe there are things that one can usefully do, such as to "raise 
the bar" on content filtering, if a message fails a dkim=all ADSP. Yes, 
a lot of people are looking for ADSP to be a magic litmus test, just as 
there are domains that drop messages based on SPF softfail. These 
domains need counseling.
>
>
> Folks,
>
> To claim that one signs all mail is to imply that anyone receiving mail from 
> them should see a valid signature.
>   

Hardly. I thought that it was you that was making the point all this 
time that all SSP/ADSP could do is describe the sender's practices, and 
could not imply receipt of a valid signature.

> Mail sent through list servers invites the problem of receivers getting mail 
> that does not have the promised valid signature, since intermediaries are 
> re-posting the message and are free to make whatever changes they see fit.
>
> Hence, saying -all for mail that goes through intermediaries which might 
> affect 
> the signature is inviting receivers to treat the received mail with hostile 
> prejudice.
>   

Depends on what "hostile prejudice" means. If it means using other 
filtering measures more rigorously, I'm fine with that.

-Jim

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

Re: [ietf-dkim] third party signing, DKIM charter update proposal

[Jim Fenton]

John Levine wrote:
>> In light of the comments by Bill Oxley and my belief that the ability of
>> a domain to designate signing by a specified 3rd party is useful, I'd
>> like to see this included in the update. I believe this would be useful
>> for ISPs as well as ESPs. I don't have any specific wording or proposals
>> on this.
>> 
>
> If you want to do that, please start with a clear explanation of the
> reasons that the current methods to delegate signing to a third
> party are unusable.
>   

Yes, and please also explore the scaling characteristics of such a
scheme.  It's one thing to say that isp.com signs for a.com or z.com,
but this would also need to support the third party signers of a large
enterprise domain, like maybe cisco.com.  I don't know how many we have,
but there are lots:  benefits providers, events organizers, online
survey providers, and senders of various marketing campaigns.  Not to
mention, possibly, mailing list domains.  Whatever third-party signer
list is supported needs to support an effectively unbounded list of
third-party signers for some domains.

In addition, I foresee a problem with publishing such a list, in that it
would very conveniently show who we use for various services, which is
in the aggregate proprietary information.  At the very least it might be
viewed as an endorsement on the part of the domain being signed, which
the legal people won't like.

-Jim

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

Re: [ietf-dkim] DKIM charter update proposal

[Jim Fenton]

Stephen Farrell wrote:
> Scott Kitterman wrote:
>   
>> If advancing DKIM/ADSP along the standards heirarchy is all that's on the 
>> table, I think it should wait.  
>>
>> Effective rollout of DKIM in large hetrgenous organizations is complex and 
>> takes time.  I think it's better to pause for a while and give broad 
>> operational experience more of a chance to exercise what has just been 
>> standardized.
>> 
>
> When we last discussed this, and certainly at the Stockholm meeting,
> there did seem to be consensus for moving 4871 along to DS. If other
> folks want to wait they should speak up, but for now, I think we do
> have WG consensus to do that.
>   

I don't remember when we last discussed this, but of course consensus
"in the room" at Stockholm needs to be confirmed via the mailing list.

In any case, I generally agree with Scott -- pushing this along the
standards track seems to me to be premature given the number of use
cases that need to be considered in the case of DKIM.

-Jim

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

Re: [ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)]

[Jim Fenton]

Hector,

Here are my interpretations.  Everyone, please bear in mind that these
are just that and others are free to disagree.  I'm not interested in
getting into a debate about this.

It's not clear to me that this is really a standardization discussion at
this point, so perhaps we should take discussions of this sort to
another list such as dkim-...@mipassoc.org.

Comments inline...

hector wrote:
> Congratulations on getting this published.  Hopefully, it will taken
> serious by many domains to help provide a reasonable return on DKIM
> processing. In lieu of a standardized (and public) reputation system,
> network, ADSP can give some value.
>
> I have a few questions seeking clarification, confirmation mostly,
> because if I'm going to begin to implement DKIM with an ADSP focus for
> our customers, we will need to be able translate the information in
> the spec into easy to understand documented and online "Help" for
> customers.
>
> 1) With the policies:
>
>dkim=all vs dkim=discardable
>
> In layman terms, one is actionable (discardable) and one is not (all).
> One is an "Error" resulting in a reject, one is a "Warning" not
> resulting in a reject, in both cases, can be logged/recorded?  Our GUI
> setup may show it like so for example:
>
>   Author Domain: domain.example
>
>   DKIM Signing Policy:
>
>   (o) unknown - your mail may be signed
>
>   (_) all - Your mail are always sign, however
> verifiers SHOULD NOT reject invalid signatures.
>
>   (_) discardable - Your mail are always sign, and
> verifiers MUST reject invalid signatures.
>
>   [ PUBLISH ] [CANCEL ]
>
> Is that the basic translation and fair way to put it?

I disagree that "all" is not actionable.  There are several things the
verifier/assessor can do.  (1) Apply more stringent content checking
(perhaps changing the threshold values or something).  (2) If the GUI is
under the control of the assessor (such as a webmail client), display a
visual warning.  If not, do something like add [dkim unverified] to the
subject line.  Some of you may have seen that if I responded hastily to
a message without cleaning that up, because I have been trying that out
for quite some time now.

>
> 2) DKIM=UNKNOWN
>
> Is there any actionable logic for optional signing?
>
> I mean, you may not always sign, but if you do, it must not be invalid?
>
> I just want to make sure in our help/doc to indicate whether
> publishing with unknown is the same as no ADSP record. One is
> explicit, the other is implicit.  I may not always sign, but if I do,
> take it serious.  Having no records could be viewed you don't care
> either way.
>
> I guess as it seems to be now, it would be a "Warning" but still
> acceptable (no rejection on this basis).  But see the tail end of 3.

I would advise against treating a signature that is invalid any
differently from a signature that isn't present.  There are intermediate
agents that might break the signature, and we don't want to give the
impression that applying a signature might increase the risk of
non-delivery.  Furthermore, dkim=unknown has the same meaning as the
lack of an ADSP record.

>
> 3) Finally 3rd party signatures.
>
> Please believe me I don't wish to rehash this. It was the one thing
> that I really felt will help domains.  Not so much in defining the
> difficult task for valid use cases for the inclusion of 3rd signature
> policies, but rather the exclusion of 3rd parties.  For example,
> appendix B.4 says:
>
> B.4.  Third-Party Senders
>
>Another common use case is for a third party to enter into an
>agreement whereby that third party will send bulk or other mail on
>behalf of a designated Author or Author Domain, using that domain
>in the [RFC5322] From: or other headers.  Due to the many and
>varied complexities of such agreements, third-party signing is not
>addressed in this specification.
>
> Ok, I accept this, we had hard time defining 3rd party situations. But
> this is not the same as the one hard logical conclusion a domain
> may have:  He doesn't do 3rd party signatures nor expect it.
>
> So it seems me that the explicit declaration of a ADSP policy, the
> only options provided to prevent it are the explicit DKIM=ALL and
> DKIM=DISCARDABLE declarations.
>
> However, does the explicit DKIM=UNKNOWN declaration also imply
> exclusive Author Domain Signing?  An explicit DKIM=UNKNOWN should
> suggest ADSP operations only, even if the signature is optional.
>
> Is that a correct or incorrect consideration?

dkim=unknown doesn't imply that there is any Author Domain Signing going
on, and it is always (regardless of the ADSP value) OK for an
intermediary to apply a DKIM signature if it's willing to take
responsibility.  So ADSP is completely silent on the presence or absence
of third-party signatures.

Again, dkim=unknown has exactly the same semantics as the lack of an
ADSP record.  A published ADSP record will normally have a longer

[ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)]

[Jim Fenton]

I haven't seen this announcement here, probably because
rfc-edi...@rfc-editor.org doesn't subscribe to this list.

 Original Message 
Subject: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain
Signing Practices (ADSP)
Date: Wed, 12 Aug 2009 16:53:22 -0700 (PDT)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: ietf-dkim@mipassoc.org, rfc-edi...@rfc-editor.org
Newsgroups: gmane.ietf.announce,gmane.ietf.dkim


A new Request for Comments is now available in online RFC libraries.


RFC 5617

Title:  DomainKeys Identified Mail (DKIM) Author
Domain Signing Practices (ADSP)
Author: E. Allman, J. Fenton,
M. Delany, J. Levine
Status: Standards Track
Date:   August 2009
Mailbox:eric+d...@sendmail.org,
fen...@cisco.com,
markd+d...@yahoo-inc.com,
standa...@taugh.com
Pages:  21
Characters: 43093
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-dkim-ssp-10.txt

URL:http://www.rfc-editor.org/rfc/rfc5617.txt

DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages.  This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address.  It defines a
record that can advertise whether a domain signs its outgoing mail as
well as how other hosts can access that record.  [STANDARDS TRACK]

This document is a product of the Domain Keys Identified Mail Working
Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute

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

Re: [ietf-dkim] Escaping things in key/ADSP records

[Jim Fenton]

Tony,

If you still have the records, can you count the number of records with
g=; ?  That's used in an example in some of the DomainKey specs and
works for DK but means "match nothing" for DKIM.

-Jim

Tony Hansen wrote:
> Mark Martinec wrote:
>  > John Levine wrote:
>  >> It is certainly the kind of bug that occurs in PHP scripts when the
>  >> programmer doesn't perfectly understand the quoting rules.  It's
>  >> happened to me.
>  >
>  > I'm collecting a set of common mistakes breaking DKIM signatures.
>
> Pulling up a message from a while ago. Mark, did you ever get further 
> with your set of common mistakes?
>
> I had occasion to look at a number of DNS key records, and find the 
> following common mistakes:
>
> Sample size: 65456 DNS _domainkey (DKIM+DK) records
>
> 16missing semi-colons between fields
> 1 missing any separators (k=rsap=)
> 14invalid quotation marks (") surrounding the entire record
> 2 invalid \" surrounding the entire record
> 5 invalid parens or paren+quotes surrounding the entire record
> 47\-quoted characters, particularly \;
> 9 TTL value or other random DNS data showing up in the record
> 1 TTL value being in the record instead of the public key
> 17random characters in the record, e.g. {, CRLF, backspace, SUB, >
> 113   SPF records being returned
> 13key only, no p= or any other options
> 1 encoded ; as %3B
> 1 missing tag before =
> 8 other data in record (dkim=all, O=-, r=, &, ")
> 1 v=DKIM1 not first field in record
> 50other random errors
> ---
> 299
>
> I was not able to verify if any of the keys that had spaces within them 
> were actually valid keys or not.
>
> The good news is that of the sample, the majority of the records were 
> just fine.
>
> I'm wondering if there is a need for a web interface at dkim.org that 
> would validate someone's _domainkey TXT record.
>
> Thoughts?
>
>   Tony Hansen
>   t...@att.com
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Agenda for IETF 75

[Jim Fenton]

Tony,

Do you have any information on what options and features were tested in
the DKIM interoperability event in Fall 2007?  That should establish the
independent and interoperable implementations for a number of things?  I
found notes describing what had been found to need clarification, but
not on what had been tested.

-Jim

Tony Hansen wrote:
> The key document is RFC 2026. It's been updated by several other RFCs,
> but none of them affect the status transitions.
>
> The key section is "4.1.2 Draft Standard". It's five paragraphs can be
> summarized as follows:
>
>1) interoperable
>   a) 2 independent & interoperable implementations
>   b) "sufficient operational experience"
>   c) "a strong belief that spec is mature and will be useful"
>
>2) interoperability is applied on a option & feature basis
>   a) any options or features not demonstrated to be interoperable
>  by independent implementations must be removed
>
>3) WG chair responsible for documenting implementations
>   a) used for the qualification, and
>   b) documentation about the testing of the interopability.
>   c) Includes information on individual options/features.
>   d) Submits to AD.
>
>4) DS must be
>   a) well understood and
>   b) quite stable.
>   c) Wide spread field experience is NOT required. ("it is
>   possible ... [for DS specs] to demonstrate unforeseen behavior
>   when subjected to large-scale use in production environments.")
>
>5) Changes hereafter are only to fix specific problems encountered
>   while deploying widely.
>
> Section 6.2 further adds
>6) Must be at PS at least six months.
>
> That pretty much covers it.
>
>   Tony Hansen
>   t...@att.com
>
> Jim Fenton wrote:
>   
>> In order to level-set the group on the draft standard process, can
>> someone please send a pointer to the process for moving from PS to DS
>> (what the requirements are, and what is and isn't allowed to change)? 
>> If more of us are on the same page with understanding that process, the
>> discussion is likely to be more productive.
>>
>> -Jim
>>
>> Barry Leiba wrote:
>> 
>>> I have uploaded the following agenda to the IETF meeting materials manager:
>>>   https://datatracker.ietf.org/meeting/75/materials.html
>>>
>>> --
>>> Agenda for DKIM meeting at IETF 75, Stockholm
>>>
>>> We're currently scheduled for Tuesday, 28 July, 13:00-15:00 local time.
>>>
>>> The primary purpose of the meeting is to talk about next steps, which
>>> may include 4871bis work.
>>>
>>> Agenda:
>>> 1. Administrative: agenda review, WG status review, etc.  (5 mins)
>>> 2. Discussion of next steps.  (the rest of the time)
>>>
>>> Specific topics for discussion:
>>> - Is there enough energy to update DKIM base (RFC 4871) & go to draft 
>>> standard?
>>> - Is DKIM base ready for that?  Do we have enough experience to know
>>> it's stable?
>>> - Should we eliminate features in the process, to steamline?
>>> - If so, what features?
>>> - Do we have good statistics on what features are used on each side?
>>> --
>>>
>>> If anyone wants to make a specific presentation, please post here, or
>>> let us know at .
>>>
>>> Barry (as chair)
>>>   
>
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Agenda for IETF 75

[Jim Fenton]

In order to level-set the group on the draft standard process, can
someone please send a pointer to the process for moving from PS to DS
(what the requirements are, and what is and isn't allowed to change)? 
If more of us are on the same page with understanding that process, the
discussion is likely to be more productive.

-Jim

Barry Leiba wrote:
> I have uploaded the following agenda to the IETF meeting materials manager:
>   https://datatracker.ietf.org/meeting/75/materials.html
>
> --
> Agenda for DKIM meeting at IETF 75, Stockholm
>
> We're currently scheduled for Tuesday, 28 July, 13:00-15:00 local time.
>
> The primary purpose of the meeting is to talk about next steps, which
> may include 4871bis work.
>
> Agenda:
> 1. Administrative: agenda review, WG status review, etc.  (5 mins)
> 2. Discussion of next steps.  (the rest of the time)
>
> Specific topics for discussion:
> - Is there enough energy to update DKIM base (RFC 4871) & go to draft 
> standard?
> - Is DKIM base ready for that?  Do we have enough experience to know
> it's stable?
> - Should we eliminate features in the process, to steamline?
> - If so, what features?
> - Do we have good statistics on what features are used on each side?
> --
>
> If anyone wants to make a specific presentation, please post here, or
> let us know at .
>
> Barry (as chair)
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [Fwd: New Version Notification - draft-ietf-dkim-rfc4871-errata-07.txt]

[Jim Fenton]

Lest anyone interpret silence as agreement, I'm OK (not enthusiastic,
but OK) with most of the added text in this revision, but I have a
problem with the last two paragraphs.

> This does not state what the implicit value of "i=" is, relative to
> "d=". In this context, that fact is irrelevant.

I'm not sure what point is being made, but RFC 4871 does explicitly
define the default value of "i=" (an empty Local-part followed by an "@"
followed by the domain from the "d=" tag).  It isn't clear what "this"
context is, and the paragraph is likely to introduce confusion as to
whether the default value in RFC 4871 no longer exists.

> Another example is the difference between the socket interface to TCP
> versus the TCP protocol itself. There is the activity within the
> protocol stack, and then there is the activity within in the software
> libraries that are actually used.

This analogy isn't clearly stated, and in any case is discussion that is
irrelevant in the context of a protocol specification.

Both of these paragraphs should be removed.

-Jim

Dave CROCKER wrote:
>  Original Message 
> Subject: New Version Notification - draft-ietf-dkim-rfc4871-errata-07.txt
> Date: Fri, 26 Jun 2009 19:30:01 -0700 (PDT)
> From: internet-dr...@ietf.org
> To: dkim-cha...@tools.ietf.org, 
> draft-ietf-dkim-rfc4871-err...@tools.ietf.org, 
>pasi.ero...@nokia.com
>
> New version (-07) has been submitted for 
> draft-ietf-dkim-rfc4871-errata-07.txt.
> http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871-errata-07.txt
>
>
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-dkim-rfc4871-errata-07
>
> IETF Secretariat.
>
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

[Jim Fenton]

Dave CROCKER wrote:
>
> Meant to include this, for completeness:
>
>
> Replacing 'reputation' with 'assessment', here's the latest version:
>
>   

I'm better with this version; thanks.  I do feel that we're effectively
using "assessment" as a proxy for "the R-word" which goes back to the
concern I voiced long ago about not requiring the verifier to pass on
other values including i= if they're present.  It seems to me that this
is effectively dictating the operation of the (wink wink, nudge nudge)
assessor.But I won't belabor that, since it seems that the rough
consensus felt otherwise.

The important point now is responding to Cullen's concerns that the new
text doesn't clarify things adequately.

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

Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

[Jim Fenton]

pasi.ero...@nokia.com wrote:
> Jim Fenton wrote:
>
>   
>> Dave has proposed a change to the rfc4871-errata draft in response to a
>> concern from the IESG.  Can you clarify what concern the IESG has this
>> is attempting to address?  I'll repeat my original question below since
>> you may have missed it.
>> 
>
> It's attempting to address Cullen's comment (about this being
> competely incomprehensible to both him and three DKIM implementors he
> asked) *and* comments from several other ADs (voiced during the IESG
> telechat) that were similar to Cullen's (it's very hard to tell what 
> is being changed by this document, or who would be impacted by these 
> changes and should read the document).
>
> Currently, Section 1 does attempt to briefly summarize the change,
> explain why it's done and describe the consequences, but after
> re-reading it now, I think these comments have some merit, and 
> slightly longer explanation would be very helpful to readers who 
> didn't participate in the DKIM WG discussions. 
>   

Thanks.  I don't share the sense that this additional text clarifies
things much, but I'm perhaps too close to the specification to be a fair
judge of that.

I do have a problem with the last paragraph:

>For signers and assessors that have been using the i= tag for
>  reputation assessment a software change to using the d= tag is 
> intended.
>
>   
and some of the text in the preceding paragraph because it attempts to
do exactly what the WG charter says we won't, specifically:

> To prevent this task from becoming unwieldy, several related topics are
> considered out of scope for the DKIM working group. These topics
> include:
>
> * Reputation and accreditation systems. While we expect these to add
>   value to what is defined by the DKIM working group, their development
>   will be separate, and is out of scope for the DKIM working group.

Finally, will you be taking this proposed text to the ADs who had
concerns to determine whether this addresses their concerns?  I'm
wondering whether they expected a change to be made, since none of them
raised a DISCUSS on this issue (Cullen abstained).

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

Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

[Jim Fenton]

(sorry...I clicked the HTML button on the last try and my own PDA was
having problems with it)

Dave CROCKER wrote:
>
>
> Jim Fenton wrote:
>> Can you clarify what IESG concern this is attempting to address?  
>
>
> Frankly, for that level of question, I suggest you direct it to our
> area director.  That will be far more efficient than my attempting to
> channel him and the rest of the IESG.
>
OK.

Pasi:

Dave has proposed a change to the rfc4871-errata draft in response to a
concern from the IESG.  Can you clarify what concern the IESG has this
is attempting to address?  I'll repeat my original question below since
you may have missed it.

-Jim

Jim Fenton wrote:
> Can you clarify what IESG concern this is attempting to address?  I
> looked at the IESG evaluation record for the draft
> (https://datatracker.ietf.org/idtracker/ballot/3084/) and didn't see
> anything that this change would address, except possibly Cullen's
> comment that he asked three developers what changes to a 4871
> implementation might be required and they told him "this document was
> completely incomprehensible and they have no idea what needs to change."
>
> I don't see this modification as addressing that comment.
>
> -Jim
>
> Dave CROCKER wrote:
>   
>> Folks,
>>
>> In reviewing the errata (Update) draft, the IESG expressed concern that a 
>> reader 
>> could miss that there is a potential for software changes due to the change 
>> in 
>> the specification.  Indeed, some IESG readers and others did believe there 
>> was 
>> no software change needed.
>>
>> To clarify things, without producing text that makes integration into the 
>> base 
>> document a challenge later, a modification to the Introduction is proposed.  
>> I'm 
>> circulating it to the mailing list to be sure that there are no land mines 
>> in 
>> its interpretations.
>>
>> If the proposed changes causes you particular heartburn, please explain your 
>> concern in detail.
>>
>> Thanks.
>>
>> d/
>>
>>
>> Existing Introduction text:
>>
>>   
>> 
>>>This currently leaves signers and assessors with the potential for
>>>having differing -- and therefore non-interoperable --
>>>interpretations of how DKIM operates.
>>>
>>>This update resolves this confusion.  It defines new labels for the
>>>two values, clarifies their nature, and specifies their relationship.
>>>
>>> 
>>>   
>> Proposed text:
>>
>>This currently leaves signers and assessors with the potential for
>>  making different interpretations between the two identifiers and may
>>  lead to interoperability problems. A signer could intend one to be
>>  used for reputation, and have a non-reputation intent in setting the
>>  value in the other. However the assessor might choose the wrong 
>> value
>>  and produce an unintended (and inaccurate) reputation 
>> assessment.
>>
>>This update resolves that confusion.  It defines additional, 
>> semantic
>>  labels for the two values, clarifies their nature and specifies 
>> their
>>  relationship.  More specifically, it clarifies that the identifier
>>  intended for reputation lookups (such as white lists) by the
>>  assessor is the value of the "d=" tag. However, this does not
>>  prohibit message filtering engines from using the "i=" tag, or any
>>  other information in the message header, for filtering decisions. 
>> 
>>
>>For signers and assessors that have been using the i= tag for
>>  reputation assessment a software change to using the d= tag is 
>> intended.
>>
>>
>>   
>> 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Modified Introduction text for rfc4871-errata

[Jim Fenton]

Dave CROCKER wrote:

  
Jim Fenton wrote:
  
  Can you clarify what IESG concern this is
attempting to address?  
  
  
Frankly, for that level of question, I suggest you direct it to our
area director.  That will be far more efficient than my attempting to
channel him and the rest of the IESG.
  


OK.

Pasi:

Dave has proposed a change to the rfc4871-errata draft in response to a
concern from the IESG.  Can you clarify what concern the IESG has this
is attempting to address?  I'll repeat my original question below since
you may have missed it.

-Jim

Jim Fenton wrote:

  Can you clarify what IESG concern this is attempting to address?  I
looked at the IESG evaluation record for the draft
(https://datatracker.ietf.org/idtracker/ballot/3084/) and didn't see
anything that this change would address, except possibly Cullen's
comment that he asked three developers what changes to a 4871
implementation might be required and they told him "this document was
completely incomprehensible and they have no idea what needs to change."

I don't see this modification as addressing that comment.

-Jim

Dave CROCKER wrote:
  
  
Folks,

In reviewing the errata (Update) draft, the IESG expressed concern that a reader 
could miss that there is a potential for software changes due to the change in 
the specification.  Indeed, some IESG readers and others did believe there was 
no software change needed.

To clarify things, without producing text that makes integration into the base 
document a challenge later, a modification to the Introduction is proposed.  I'm 
circulating it to the mailing list to be sure that there are no land mines in 
its interpretations.

If the proposed changes causes you particular heartburn, please explain your 
concern in detail.

Thanks.

d/


Existing Introduction text:

  


 This currently leaves signers and assessors with the potential for
   having differing -- and therefore non-interoperable --
   interpretations of how DKIM operates.

   This update resolves this confusion.  It defines new labels for the
   two values, clarifies their nature, and specifies their relationship.


  


Proposed text:

   This currently leaves signers and assessors with the potential for
 making different interpretations between the two identifiers and may
 lead to interoperability problems. A signer could intend one to be
 used for reputation, and have a non-reputation intent in setting the
 value in the other. However the assessor might choose the wrong value
 and produce an unintended (and inaccurate) reputation assessment.

   This update resolves that confusion.  It defines additional, semantic
 labels for the two values, clarifies their nature and specifies their
 relationship.  More specifically, it clarifies that the identifier
 intended for reputation lookups (such as white lists) by the
 assessor is the value of the "d=" tag. However, this does not
 prohibit message filtering engines from using the "i=" tag, or any
 other information in the message header, for filtering decisions. 

   For signers and assessors that have been using the i= tag for
 reputation assessment a software change to using the d= tag is intended.
   

  

  
  




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

Re: [ietf-dkim] Modified Introduction text for rfc4871-errata

[Jim Fenton]

Can you clarify what IESG concern this is attempting to address?  I
looked at the IESG evaluation record for the draft
(https://datatracker.ietf.org/idtracker/ballot/3084/) and didn't see
anything that this change would address, except possibly Cullen's
comment that he asked three developers what changes to a 4871
implementation might be required and they told him "this document was
completely incomprehensible and they have no idea what needs to change."

I don't see this modification as addressing that comment.

-Jim

Dave CROCKER wrote:
> Folks,
>
> In reviewing the errata (Update) draft, the IESG expressed concern that a 
> reader 
> could miss that there is a potential for software changes due to the change 
> in 
> the specification.  Indeed, some IESG readers and others did believe there 
> was 
> no software change needed.
>
> To clarify things, without producing text that makes integration into the 
> base 
> document a challenge later, a modification to the Introduction is proposed.  
> I'm 
> circulating it to the mailing list to be sure that there are no land mines in 
> its interpretations.
>
> If the proposed changes causes you particular heartburn, please explain your 
> concern in detail.
>
> Thanks.
>
> d/
>
>
> Existing Introduction text:
>
>   
>>This currently leaves signers and assessors with the potential for
>>having differing -- and therefore non-interoperable --
>>interpretations of how DKIM operates.
>>
>>This update resolves this confusion.  It defines new labels for the
>>two values, clarifies their nature, and specifies their relationship.
>>
>> 
>
>
> Proposed text:
>
>This currently leaves signers and assessors with the potential for
>  making different interpretations between the two identifiers and may
>  lead to interoperability problems. A signer could intend one to be
>  used for reputation, and have a non-reputation intent in setting the
>  value in the other. However the assessor might choose the wrong value
>  and produce an unintended (and inaccurate) reputation assessment.
>
>This update resolves that confusion.  It defines additional, 
> semantic
>  labels for the two values, clarifies their nature and specifies their
>  relationship.  More specifically, it clarifies that the identifier
>  intended for reputation lookups (such as white lists) by the
>  assessor is the value of the "d=" tag. However, this does not
>  prohibit message filtering engines from using the "i=" tag, or any
>  other information in the message header, for filtering decisions. 
> 
>
>For signers and assessors that have been using the i= tag for
>  reputation assessment a software change to using the d= tag is 
> intended.
>
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Urgent: draft-ietf-dkim-ssp-10 and RFC 5451

[Jim Fenton]

Barry Leiba wrote:
> Pasi is putting draft-ietf-dkim-ssp-10 on the 4 June telechat.  But...
>
> This version has added registry entries for RFC 5451
> (Authentication-Results), which had been removed from that document to
> avoid having its publication block on a reference-wait from ADSP.
> Only, I can't find any discussion that the WG had about making that
> change.
>
> While I think this change will not likely fuel any controversy, we
> can't publish this without having it approved by the working group.
> So, ASAP, please:
>
> 1. If someone can find documentation of WG discussion about this, reply here.
>   

To my knowledge, there was no WG discussion about this.  John Levine
pointed out the change to the co-editors of the draft on March 31,
noting that this makes the dependencies between RFC 5451 and ADSP match
the timing of their publication, and that this shouldn't be
controversial.  I agree.

> 2. If anyone objects to its inclusion (see sections 5.3 and 5.4 of
> draft-ietf-dkim-ssp-10), reply here.
>   

Just to be thorough, I'll point out that the new section 6.4 describes a
consideration that largely stems from RFC 5451 as well.

No objection.
> 3. A few "Yes, adding this is groovy," messages would be good and all.
>   

Yes, adding this is groovy indeed.

-Jim

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

Re: [ietf-dkim] Whither 4871bis?

[Jim Fenton]

Dave CROCKER wrote:
>
>> Referring back to my message, I'm advocating that if we do anything, we
>> move to Draft Standard, and advocating that we not do another spin at
>> Proposed Standard.  So are we agreeing?
>
> I hadn't noticed anyone suggesting doing anything that cycled the
> specification at Proposed.  (The requirement placed on the Errata is
> different than we're discussing for the -bis effort.)
>
> Have you heard otherwise?
I don't know why it's my job to look this up in the list archives, but
anyway:

In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011923.html , Eliot
Lear says:

> I would recycle at proposed, if we are going to do anything at all.

In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011924.html , Suresh
Ramasubramanian says:

> -bis - yes. Definitely.
>
> > 2.  On whether to move to draft standard
> >
> > While I was initially in favor of this, I am now uncomfortable doing so,
> > based on the lengthy debate we just concluded about errata.  To me the
>
> Qualified approval based on consensus gained in the -bis draft.
Which I think says "do -bis as Proposed Standard, then maybe go to
Draft".  Hope I have interpreted Suresh's comments accurately.

In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011925.html , John
Levine says:

> >2.  On whether to move to draft standard
>
> I wouldn't bother.  It makes no difference in the outside world, so I'd
> rather direct our limited time to -bis.
>
In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011931.html , Jeff
Macdonald seems to agree with Suresh.

So, yes, I have heard otherwise.

-Jim

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

Re: [ietf-dkim] Whither 4871bis?

[Jim Fenton]

Dave CROCKER wrote:
> Jim,
>
> Jim Fenton wrote:
>> Having just reviewed yet another document referring to "recent activity
>> by the Internet Engineering Task Force (IETF) to create protocol
>> standards around SPF and DKIM", I am reminded how little the community
>> outside IETF grasps the difference between Informational, Experimental,
> > and Standards Track, never mind the differences between Proposed,
> Draft,
> > and Full Standard.  So I agree that, largely, no one cares whether DKIM
> > is PS or DS.
>
>
> Taken as stated, your example actually implies that we shouldn't
> bother with standards effort at all, since the folk you cite consider
> anything with 'RFC' in the name to be a standard.  Are you suggesting
> that because some people do not understand (or care about) the IETF
> standards imprimatur, no one else does?

I'm saying (recognizing this is well outside the scope of the working
group) that IETF has a problem in that it publishes informational,
experimental, and historic RFCs and many people outside IETF immediately
think anything with an RFC number is an "IETF standard".  That dilutes
the value of the IETF standards process and (talking like a marketing
person) the IETF "brand".

The distinctions between Proposed, Draft, and Full Standard are finer yet.
>
> Ultimately, a standards process is whatever it is and the outside
> world chooses how to deal with it.  A standards group can only define
> itself as it sees fit and try to conform to that. Some people ignore
> whether a document is standards track.  Some ignore level of
> maturity.  Others pay close attention to these distinctions.
>
> In the IETF, the purpose of moving to Draft is to formally declare
> that a specification has reached an additional level of maturity.
>
> IETF standards differ from ITU standards, for example, by having
> maturation levels.  ITU standards, from one version to the next, can
> be dramatically different and fundamentally incompatible.  IETF
> standards cannot.
>
>
>> I have been seeing significant uptake in DKIM adoption and am concerned
>> that, if we are seen to be making large changes to the specification,
>> we're likely to induce another round of waiting until we're "done" on
>> the part of implementers and adopters.  Regardless of how we describe
>> the compatibility between -bis and 4871, it's all about the perception
>> if large changes are being made.
>
> Basic concern about perceptions of substantial change is generic,
> serious and of course legitimate, IMO.
>
> But how does it apply to what might be done to move the specification
> from Proposed to Draft?  What particulars are you worried about?

Referring back to my message, I'm advocating that if we do anything, we
move to Draft Standard, and advocating that we not do another spin at
Proposed Standard.  So are we agreeing?
>
> IETF rules are rather forceful in this regard. The only substantive
> changes permitted, for a specification moving from Proposed to Draft,
> is to remove unused or problematic features.  That is, the only
> substantive changes permitted make a specification simpler.
>
> If, indeed, a feature is unused or problematic, then how will dropping
> it hurt adoption?  A simpler specification typically aids adoption,
> rather than hurting it.

Dropping unused features won't hurt adoption, so long as we handle the
backwards-compatibility issues properly (the dropped feature has
suitable defaults, and the IANA registries prevent re-use of previously
used names).  I'd need specifics to address the "problematic" case, though.

>
> And just to keep things real, can you cite some examples of the effect
> you are concerned about?

The example here would be a specification that was updated at Proposed
Standard where that caused deployment to stall.  No, I don't have the
depth of experience in IETF to cite any.  But I feel that if we go
directly to DS, the constraints in that process will help assure that
doesn't happen.

-Jim

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

Re: [ietf-dkim] Whither 4871bis?

[Jim Fenton]

Barry Leiba wrote:
>
> So the questions are whether DKIM base, with the recent update, would
> be ready by then, and whether we care to do it.  Mike and John, in a
> rare display of agreement, have both opined that "no one cares" about
> it.  There is that thought: the IETF three-stage standards track is
> meaningless, and that once something becomes Proposed Standard that's
> good enough.
>   

Having just reviewed yet another document referring to "recent activity
by the Internet Engineering Task Force (IETF) to create protocol
standards around SPF and DKIM", I am reminded how little the community
outside IETF grasps the difference between Informational, Experimental,
and Standards Track, never mind the differences between Proposed, Draft,
and Full Standard.  So I agree that, largely, no one cares whether DKIM
is PS or DS.

I have been seeing significant uptake in DKIM adoption and am concerned
that, if we are seen to be making large changes to the specification,
we're likely to induce another round of waiting until we're "done" on
the part of implementers and adopters.  Regardless of how we describe
the compatibility between -bis and 4871, it's all about the perception
if large changes are being made.

I'd like to see us fold in the errata and update, waiting if necessary
for the update to meet the age requirement, and take the resulting
document to DS.  The main reason I advocate that we go to DS is that it
constrains the changes, and supports the perception that this is a small
change that will not upset current deployment and isn't worth delaying
deployment for.  Being able to describe the change as "an IETF process
thing" can be reassuring to those who might otherwise be worried about
technical changes.

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

Re: [ietf-dkim] The "real" (remaining) errata

[Jim Fenton]

Barry Leiba wrote:
> Apart from the item that resulted in the "errata" draft, now heading
> to the IESG as an update to 4871, there are a bunch of other
> non-controversial errata that Pasi needs a response to.  Will the 4871
> authors please handle those, so the working group and Pasi can clear
> them?
>   

I'd need to go back through the archives, but I thought the authors had
already "nodded in agreement" to a number of the non-controversial
errata, and we had discussed that at IETF 73.  What's the process to
clear the obvious ones?

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Barry Leiba wrote:
> OK... there hasn't been anything more on this thread for a week, so
> it's time to tally.  And I'm afraid the tally tells us little more
> than what we had:
>
> Include the informative note:  3
> Do not include it: 4
> No opinion: 5
>
> This doesn't make for rough consensus in any direction.
>
> I'm inclined, as chair, to say that, lacking rough consensus to
> include it, we should not include it.  That might go against the
> "least harm" approach... but I think it's the most reasonable choice
> at this point.
>
> I'll give the three who voted to include (Jim, Scott, and Al), a final
> comment.  If you can't convince more people that it would be actively
> harmful not to have such an informative note, I think we have to move
> ahead with the draft without it.

This is just an informative note, after all, so it's not essential to
the spec.  I'm fine with proceeding without it, given this outcome.

Thanks for the consensus check and the ruling.

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

"Include the informative note."


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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Barry Leiba wrote:
> This discussion seems to have settled down, but I don't see a clear
> consensus on it.  Let's take a little poll, then, on this thread.  No
> further discussion, for now, just the poll, and please don't assume
> that silence means anything.
>
> Post to this thread, one of the following:
>
> "Include the informative note."
> "Do not include the informative note."
> "I don't care [or I have no opinion] either way."
>   

Just to clarify the version of the Informative Note that I believe is
"in play" at this point, it should be the one that's based on Ellen
Siegel's wording:

> Informative Note:  DKIM signatures by parent domains as described in  
> section 3.8 of [RFC4871] (in which a signer uses "i=" to assert that  
> it is signing for a subdomain) do not satisfy the requirements for  
> an Author Domain Signature as defined above.
-Jim

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Douglas Otis wrote:
>
> On Apr 12, 2009, at 10:54 PM, Jim Fenton wrote:
>
>> But this isn't a normative note, it's an informative note.  All I
>> want to do with it is to caution the reader that Parent Domain
>> Signing, as described in section 3.8 of RFC 4871, isn't a practice
>> that results in an Author Domain Signature as defined in ADSP, and
>> therefore they shouldn't plan on using it if they're saying that they
>> apply Author Domain Signatures to all their mail.
>
> Consider a domain that uses sub-domains for their mailing-lists that
> are signed using Parent Domain Signing.  Even when a parent domain has
> ADSP assertions of either an "all" or "discardable", users can still
> participate in these mailing-lists using Parent Domain Signing and be
> compliant with ADSP.  Compliance can not be defined in terms of Parent
> Domain Signing, since the i= value can contain sub-domains.

I don't understand what "users can participate in these mailing-lists
using Parent Domain Signing" means.  A signature applied by a mailing
list would be an Author Domain Signature, except in the special case
where the domain of the mailing list signature happens to be the same as
that of the author.  It's possible to avoid this special case by having
the mailing list domain be different from that of any author, and one
way to do that is to give the mailing list(s) a separate subdomain.  But
that doesn't have anything to do with the caution about Parent Domain
Signing.

-Jim

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Douglas Otis wrote:
>
> On Apr 11, 2009, at 9:22 PM, Jim Fenton wrote:
>>
>> The Informative Note I'd like to include, of course, changes
>> nothing.  I just see the potential for people to read RFC 4871, and
>> where it talks about possible uses for i=, and then read ADSP which
>> is otherwise completely silent on i=, and not make the connection
>> that ADSP is only looking at d= and therefore the parent domain
>> signing "feature" in 4871 doesn't satisfy the Author Domain Signature
>> requirements of ADSP.
>>
>> Yes, the ADSP specification is complete without this note (it's
>> informative, after all).  But the compelling argument that justifies
>> it is that it clarifies things in a way that may improve
>> interoperability. We should be trying to write specifications that
>> promote interoperability, not just ones that are technically complete.
>
> The ADSP compliance issue is limited to a relationship between the
> From email-address domain and the signing domain.  This relationship
> is not defined in the base draft and is not related to the i= value.

Agreed.
>
> A normative note might mention that parent domain signing for From
> email-addresses will not satisfy ADSP, but it should not reference i=
> values.  Parent domain signing for a mailing list within a sub-domain
> that includes messages with a From email-address of the signing domain
> _will_ satisfy ADSP, for example.  The issue is unrelated to the
> i=value and is only related to parent domain signing of the From
> email-address.   Sub-domains within the i= value are only limited by
> the "s" flag in the key record t= value, but this has nothing to do
> with ADSP compliance beyond defining a valid DKIM signature.

But this isn't a normative note, it's an informative note.  All I want
to do with it is to caution the reader that Parent Domain Signing, as
described in section 3.8 of RFC 4871, isn't a practice that results in
an Author Domain Signature as defined in ADSP, and therefore they
shouldn't plan on using it if they're saying that they apply Author
Domain Signatures to all their mail.

-Jim
>
> -Doug
>
>
>
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Dave CROCKER wrote:
>
>
> Jim Fenton wrote:
>> Yes, the i= value _is_ ignored when determining ADSP compliance.  The
>> text that refers to the i= value is in RFC 4871, not the ADSP spec, and
>> the point of the note is to point out that the comments about the use of
>> i= there don't apply to ADSP because ADSP doesn't use i=.
>
>
> I am getting increasingly confused about this topic.
>
> The Update substantially alters what RFC4871 says or implies about
> i=.  It could well be that when the -bis effort does a detailed review
> of RFC4871+Update it finds further clarification and removals to make
> about i=.

Chairs, correct me if I'm wrong, but I don't think we have a normative
dependence between the ADSP specification and the 4871 Update.  The ADSP
specification doesn't use any of the terminology used in the Update. 
Furthermore, the Update makes no changes to section 3.8 of 4871 which
the Informative Note is intending to address.
>
> Why, then, should ADSP make any comment about i= at all, given that
> ADSP no longer uses i=?
>
> Having tidbits of clarification language can be helpful, but providing
> them when there isn't any experience to suggest their need and
> especially when they refer to something that is not cited anywhere
> else in a specification is downright peculiar.
>
> Given how vigorously you seem to feel that it /should/ be included, I
> seem to keep missing the compelling argument that justifies it.

The Informative Note I'd like to include, of course, changes nothing.  I
just see the potential for people to read RFC 4871, and where it talks
about possible uses for i=, and then read ADSP which is otherwise
completely silent on i=, and not make the connection that ADSP is only
looking at d= and therefore the parent domain signing "feature" in 4871
doesn't satisfy the Author Domain Signature requirements of ADSP.

Yes, the ADSP specification is complete without this note (it's
informative, after all).  But the compelling argument that justifies it
is that it clarifies things in a way that may improve interoperability. 
We should be trying to write specifications that promote
interoperability, not just ones that are technically complete.

-Jim

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Doug Otis wrote:
> On Apr 9, 2009, at 10:11 AM, J.D. Falk wrote:
>
>   
>> Siegel, Ellen wrote:
>>
>> 
 Informative Note:  DKIM signatures by parent domains as described  
 in section 3.8 of [RFC4871] (in which a signer uses "i=" to assert  
 that it is signing for a subdomain) do not satisfy the  
 requirements for an Author Domain Signature as defined above.
 
>>  [ . . . ]
>> 
>>> Works for me.
>>>   
>> +1
>>
>> (I'd use commas instead of parentheses, but that's minor.)
>> 
>
> IMHO, this is still wrong.  The i= value should be _ignored_ when  
> determining ADSP compliance.  I'll try some examples.
>   

Yes, the i= value _is_ ignored when determining ADSP compliance.  The
text that refers to the i= value is in RFC 4871, not the ADSP spec, and
the point of the note is to point out that the comments about the use of
i= there don't apply to ADSP because ADSP doesn't use i=.

-Jim

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

John Levine wrote:
>> But what section 2.7 talks about has to do with the use of the i=
>> value.  
>> 
>
> Huh?  In our current draft, there's no mention of i= other than your
> proposed warning.
>
>   
Sorry; typo (shifted left on the keyboard).  I meant to say section 3.8
(of RFC 4871).

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

John Levine wrote:
>
> If you think these are silly, I wouldn't disagree, but I don't see any
> reason that some of them are sillier than others.
>   

Because none of those examples are specifically called out in RFC 4871,
while the one for which I am proposing the informative note is.

Why was the informative note that you added in -09, which also described
a signing practice not described in RFC 4871, not (to use your term) silly?

-Jim

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Douglas Otis wrote:
>
> On Apr 6, 2009, at 4:36 PM, Jim Fenton wrote:
>
>> There remains some disagreement on whether the "informative note"
>> contained in the last paragraph of the text I proposed on March 27
>> should appear in the ADSP draft.  The note said:
>>
>>> Informative Note:  ADSP is incompatible with DKIM signing by parent
>>> domains described in section 3.8 of [RFC4871] in which a signer uses
>>> "i=" to assert that a parent domain is signing for a subdomain.
>>
>> This would replace the Note in draft-ietf-dkim-ssp-09, section 2.7.
>
> ### This note is not correct.  The incompatibility is not dependent
> upon the i= value, which might be omitted.
>
> Informative Note:  ADSP is incompatible with DKIM signing by parent
> domains described in section 3.8 of [RFC4871] when a parent domain
> signs for a sub-domain within an email-address.  ADSP requires the
> From email-address domain (Author Domain) and the signing domain
> (SDID) to be the same.
>
But what section 2.7 talks about has to do with the use of the i=
value.  Without the i= value, Parent Domain Signing (as defined there)
doesn't exist.

Have a look at the alternate wording I proposed in response to Ellen's
message and let me know what you think of that.

-Jim

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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Siegel, Ellen wrote:
>> There remains some disagreement on whether the "informative note"
>> contained in the last paragraph of the text I proposed on March 27
>> should appear in the ADSP draft.  The note said:
>>
>> 
>>> Informative Note:  ADSP is incompatible with DKIM signing by parent
>>> domains described in section 3.8 of [RFC4871] in which a signer uses
>>> "i=" to assert that a parent domain is signing for a subdomain.
>>>
>>>   
>> This would replace the Note in draft-ietf-dkim-ssp-09, section 2.7.
>>
>> Thus far, I feel it should be included and John Levine and Dave Crocker
>> feel it shouldn't.  May we have guidance from others in the Working
>> Group, please?
>>
>> 
>
> [> ] 
>
> I think it may be the "incompatible" that's causing the disagreement. ADSP is 
> not incompatible with that signing configuration, it would just require that 
> a second signature be added. 
>
> Maybe something more like the following?
>
> "ADSP should not be used for domains that use "i=" values to enable a parent 
> domain to sign for a subdomain (as described in section 3.8 of [RFC4871]) 
> unless an additional signature where the "d=" domain matches the "i=" domain 
> is added."
>   

Good thought, but since parent domain signing is largely to simplify key
management (so that the public keys don't need to be published in each
subdomain), it's not necessary to apply a parent domain signature if a
signature where the d= value matches the actual From domain is also applied.

But you're right, "incompatible" may be a little harsh; I just followed
John Levine's wording in -09.  How about:

Informative Note:  DKIM signatures by parent domains as described in section 
3.8 of [RFC4871] (in which a signer uses "i=" to assert that it is signing for 
a subdomain) do not satisfy the requirements for an Author Domain Signature as 
defined above.

-Jim


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

Re: [ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Hector Santos wrote:
> Jim Fenton wrote:
>> There remains some disagreement on whether the "informative note"
>> contained in the last paragraph of the text I proposed on March 27
>> should appear in the ADSP draft.  The note said:
>>
>>> Informative Note:  ADSP is incompatible with DKIM signing by parent
>>> domains described in section 3.8 of [RFC4871] in which a signer uses
>>> "i=" to assert that a parent domain is signing for a subdomain.
>>>   
>> This would replace the Note in draft-ietf-dkim-ssp-09, section 2.7.
>>
>> Thus far, I feel it should be included and John Levine and Dave Crocker
>> feel it shouldn't.  May we have guidance from others in the Working
>> Group, please?
>
> My input:
>
> Maybe I don't quite see the issues, but I've been doing more testing
> later to see how this is all going to fit, and there seems to be a
> need to deal with issues for the high potential cases:
>
> 1) same primary domain name spaces
>
> From: user @ subdomain.primary-domain.com
> DKIM-Signature:  d=primary-domain.com
>
> or
>
> From: user @ primary-domain.com
> DKIM-Signature:  d=subdomain.primary-domain.com
>
> 2) "3rd party" or non-author domain name space
>
> From: user @ primary-domain.com
> DKIM-Signature:  d=some-other-domain.com
>
> As far as the i= is concern, as long as the h= binds the From: header
> (as it must per 4871) the i= appears to me as an "extra" bit of
> information that is not required for DKIM 4871 verification.
>
> Lacking applications for usage, I don't see how i= "helps".  I think I
> understand some people want to use it as feed to some future or
> current trust service in the works.  But I see that as gravy information.

Since there is indeed no defined application for the i= value, "gravy
information" is not a bad description.  Nevertheless, Section 3.8 of RFC
4871 says that it's possible to sign messages where the domain part of
the i= value is a subdomain of the d= value, which of course it is.  But
since such a signature won't serve as an Author Domain Signature in ADSP
(when the From address is in the subdomain), I think it's important that
the ADSP specification point that out.

-Jim


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

[ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

There remains some disagreement on whether the "informative note"
contained in the last paragraph of the text I proposed on March 27
should appear in the ADSP draft.  The note said:

> Informative Note:  ADSP is incompatible with DKIM signing by parent
> domains described in section 3.8 of [RFC4871] in which a signer uses 
> "i=" to assert that a parent domain is signing for a subdomain.
>   
This would replace the Note in draft-ietf-dkim-ssp-09, section 2.7.

Thus far, I feel it should be included and John Levine and Dave Crocker
feel it shouldn't.  May we have guidance from others in the Working
Group, please?

-Jim


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

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

[Jim Fenton]

Dave CROCKER wrote:

  
Barry Leiba wrote:
  
  
The new text has all been
agreed to on this list over the last week, in the three sub-threads
that Dave started... which is why we only need a brief check to make
sure they're OK.  We're not excluding anything.

  
  

Folks,

To emphasize:



Includes a pointer to a diff file between the latest draft and the pre-vote draft.

The editing exercise was a matter of folding in the 3 circulated texts and, I 
believe, the correction Ellen offered.
  


Nits:

Sections 6 and 7:  s/semantics is/semantics are/

Section 12:  s/single, Signing Domain Identifier/single Signing Domain
Identifier/

  s/DKIM's mandatory delivery/DKIM's mandatory output/
  s/semantics is/semantics are/

Otherwise looks fine.

What are we doing with the other errata in the queue?  Are they to be
included in this update or processed as errata?

-Jim




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

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

[Jim Fenton]

John Levine wrote:

  
   

  
  
Looks good to me.

Near the end of section 12, I'd change 

  The real-world efficacy of any but the most basic bindings between
  the SDID or AUID and other identities is not well established,

to:

  The real-world efficacy of bindings between the SDID or AUID and
  other identities is not yet established,

but if other people strongly prefer the current wording, I can live
with it.

I've seen plenty of hypotheses about what identities should match
what, but precious little operational data.
  


I like this new wording.

-Jim



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

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

[Jim Fenton]

Dave CROCKER wrote:
> I think there are two sources of confusion for this round of ADSP discussion.
>
> The first is that the term "Author Signature" encourages one to think that 
> DKIM 
> is used to sign with the full author email address, rather than with the 
> /domain/ of the author's address.  We fixed that error in the name of the 
> document, but forgot to carry it through to the details of the spec.
>
> DKIM is about domains, not email addresses.  And that's all ADSP should be. 
> Using i= encourages this cofusion.  Using "Author Signature" rather than 
> "Author 
> Domain Signature" also encourages it.
>   

If the definition changes from i= to d= (and it looks like there will be
consensus to do that), Author Domain Signature is the better name for
that.  The Chairs had tasked us to make only a surgical change to this
section, however, so we should check if that's OK.
> ps.  That includes dropping the "ADSP is incompatible" note.
>   
If you mean the note that I included in the alternative text that I
posted, I disagree.  Parent domain signing is a technique described in
RFC 4871.  If it can't be used with ADSP because ADSP compares against
the d= value rather than the domain part of i=, then that limitation
should be pointed out in an informative note so that domains don't get
stung by setting up parent domain signing and then find that ADSP
doesn't do what they expect.

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

Re: [ietf-dkim] Consensus point on ADSP

[Jim Fenton]

One more try to clarify things, then I'll stop trying.

Charles Lindsey wrote:
> On Tue, 31 Mar 2009 17:30:33 +0100, Jim Fenton  wrote:
>
>   
>>> So where is your problem?
>>>
>>>   
>> My problem is that the semantics of the signature that the mailing list
>> applies shouldn't depend on whether the original author happens to be in
>> the same domain as the list.
>> 
>
> BUT IT DOESN'T!
>
> I am perpetually amazed that people on this list still seem to have no  
> idea of how ADSP is supposed to work. They seem to think that the ADSP  
> record is somehow related to the domain in the d= of the signature. IT  
> ISN'T!
>   

If "people on this list" is referring to me, please say so.  I do not
think as you assert that ADSP is keyed to the d= of the signature.  That
wouldn't make sense, because ADSP has to function in the absence of any
[valid] DKIM signature.

> It is primarily related to the domain in the From: header.
>   

If "primarily related to" means "you use the domain in the From: header
and look up the ADSP for that domain", yes.

> The existence of an ADSP record states that "If you see this domain in the  
> From: header of any email, you should expect to see also a valid signature  
> with this same domain in its d= (and maybe we also invite you to discard  
> it if such a signature is absent)".
>   

Go look at draft-ietf-dkim-ssp-09.  It doesn't say anything about using
d= in this way; it requires a valid Author Signature.  See section 2.7
for the definition of Author Signature, which involves comparing the
>From address and the i= address.

> So if a particular mail happens to have foo.example in its From: header,  
> and has also been forwarded to a list by that same domain, then WHO CARES  
> whether the signature was put there by the mailing list expander, or by  
> the normal signing machine for that domain (maybe it had even acquired two  
> signatures, one from each and both using the same key)? IT DOESN'T MATTER,  
> since it is amply proved to be a genuine message vouched for by that  
> domain.
>
> Whether smart Assessors or smart humans choose to look at any i= that may  
> be present and may indicate whether the actual signature was put there by  
> the mail-list machinery or not is a minor secondary issue. Again, WHO  
> REALLY CARES?
>
> So I still don't see that you have raised an actual problem.
>   

So you're voting for the alternative that I posted the other day that
does the comparison with d= instead of i=.  Please correct me if I have
this wrong.

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

Re: [ietf-dkim] jabber logs into working group mailing list archives?

[Jim Fenton]

Dave CROCKER wrote:
> IETF meeting jabber sessions often hold some very useful gems.  And at their 
> worst, each one isn't all that big.
>
> It occurs to me that we should try to fold them into the regular email 
> archive, 
> perhaps simply by sending the wg mailing list a copy afterwards?
>   

Good idea.  Here is the log from the March 25 IETF 74 meeting.

03/25/2009    09:09:25 AMfrom Jim Fenton to All Participants:
Note that I have remotely muted some people -- you may need to
unmute yourself to speak
03/25/200909:09:33 AMfrom Dennis Dayman to All Participants:
thx
03/25/200909:10:02 AMfrom Eliot Lear to Host (privately):
if you remotely someone they may not be able to unmute themselves
03/25/200909:10:53 AMfrom Dennis Dayman to All Participants:
is that someone in teh audience speaking?
03/25/2009    09:10:57 AMfrom Jim Fenton to All Participants:
ok then nudge me here or on Jabber
03/25/200909:10:59 AMfrom Jon Callas to All Participants:
could the speakerget closer to the mic?
03/25/200909:11:07 AMfrom Jon Callas to All Participants:
what's the jabber room?
03/25/2009    09:11:37 AMfrom Jim Fenton to All Participants:
jabber room is d...@jabber.ietf.org
03/25/200909:12:25 AMfrom J.D. Falk to All Participants:
is there a better audio stream, or is webex it?
03/25/200909:12:56 AMfrom Jon Callas to All Participants:
Yes, can we get a mic to the speaker?
03/25/200909:13:48 AMfrom Dave Crocker to All Participants:
there is a conference audio stream from the
ietf:<http://tools.ietf.org/agenda/74/>
03/25/200909:14:53 AMfrom J.D. Falk to All Participants:
webex audio is working now (though it's kinda amusing to listen to
both at once)
03/25/200909:23:15 AMfrom J.D. Falk to All Participants:
can barely hear Dave
03/25/200909:24:20 AMfrom Dennis Dayman to All Participants:
audio is great using the stream from IETF website
03/25/200909:24:47 AMfrom J.D. Falk to All Participants:
thanks, I'll switch over -- though I noticed it's a few seconds delayed
03/25/200909:30:46 AMfrom Dave Crocker to All Participants:
"can barely hear Dave " - wow.  I don't get that very often.
03/25/200909:31:42 AMfrom J.D. Falk to All Participants:
Dennis was right: this 64k mp3 stream sounds way better than the
overcompressed audio  from webex
03/25/200909:32:21 AMfrom Hector Santos to All Participants:
The IETF audo stream is great!
03/25/200909:32:33 AMfrom Jon Callas to All Participants:
where is it?
03/25/200909:32:50 AMfrom J.D. Falk to All Participants:
http://feed.verilan.com:8000/imperial_a
03/25/200909:33:13 AMfrom Hector Santos to All Participants:
Jon, http://feed.verilan.com:8000/imperial_a.m3u
03/25/200909:33:52 AMfrom Michael Adkins to All Participants:
I'm guessing that we'll still need to stay on the phone if we want
to talk, right?
03/25/200909:34:10 AMfrom Jim Fenton to All Participants:
right, or we can channel you if you type here or on the jabber room
03/25/200909:35:33 AMfrom Hector Santos to All Participants:
    Love to know who is currently speaking.
03/25/200909:35:50 AMfrom Jim Fenton to All Participants:
this is barry
03/25/200909:37:00 AMfrom Michael Hammer to All Participants:
I think Hector means who is speaking voice
03/25/200909:38:01 AMfrom Michael Hammer to All Participants:
+1 to what Ellen is saying
03/25/200909:39:21 AMfrom Michael Adkins to All Participants:
d= is the required one
03/25/200909:40:40 AMfrom Hector Santos to All Participants:
I agree too.
03/25/200909:41:29 AMfrom Michael Hammer to All Participants:
How does one identify a spoofed message from DKIM base?
03/25/200909:42:05 AMfrom Hector Santos to All Participants:
I agree.
03/25/200909:42:43 AMfrom Hector Santos to All Participants:
who is speaking?
03/25/200909:43:07 AMfrom Michael Adkins to All Participants:
Murray K
03/25/200909:44:26 AMfrom J.D. Falk to All Participants:
some good side conversation on the jabber, BTW
03/25/200909:44:42 AMfrom Michael Adkins to All Participants:
d...@jabber.ietf.org?
03/25/200909:44:44 AMfrom Michael Hammer to All Participants:
My pidgin client keeps on blowing up when I try to join the room
03/25/200909:44:56 AMfrom J.D. Falk to All Participants:
madkins: yep
03/25/200909:45:17 AMfrom J.D. Falk to All Participants:
works fine in iChat... *shu rg*
03/25/200909:51:15 AMfrom Hector Santos to All Participants:
Is that not determine by the DOMAIN signer?
03/25/200909:51:51 AMfrom Hector Santos to All Participants:
The signer should have the alternate say what

Re: [ietf-dkim] Consensus point on ADSP

[Jim Fenton]

Charles Lindsey wrote:
> On Tue, 31 Mar 2009 06:13:41 +0100, Jim Fenton  wrote:
>
>   
>> The second two cases are not my example.  Concern #2 in my message has
>> to do with messages where the signing address is a different address in
>> the same domain as the From address.  The correct test case is:
>>
>> 
>>> From some...@foo.example
>>>   
>> Valid signature from ietf-examp...@foo.example
>>
>> Let's also use "all" instead of "discardable" as the test case because
>> it's the harder problem to solve.  As you point out, the mailing list
>> should be acting on the Discardable practice rather than trying to send
>> the message to the list.
>>
>> Let's say that ietf-examp...@foo.example is a mailing list that re-signs
>> mail sent to the list (or it could be a forwarder or similar agent).
>> foo.example's mail server gets a message from an address in the same
>> domain, some...@foo.example, that has no Author Signature or has a
>> broken one. ...
>> 
>
> But how come it had no Author signature? Presumably because it arrived  
> over some internal LAN, and internal mail is not signed (or all signing is  
> done at the point where mail is finally dispatched to the Big Wide World  
> outside).
>   

Perhaps that was the reason, but it could be a lot of things.  The
notion of "internal" is becoming harder and harder to define.

>   
>> ...  In accordance with the domain's policy, it subjects the
>> message to additional scrutiny because of the "all" practices and lack
>> of an Author Signature.  The message passes this test and is sent to the
>> mailing list manager.
>> 
>
> So the mailing list manager, or some agent just prior to it, has satisfied  
> itself that it was a valid message from some...@foo.example (hence no  
> reason not to send it out to the mailing list).
>   

Right.

>> At this point, the mailing list manager would normally sign the
>> message.  Let's examine this with the i= and d= choices:
>>
>> Using i= as the basis for Author Signature, the list can sign the
>> message, and the eventual verifier/assessor that does an ADSP check will
>> see that it (still) lacks an Author Signature since
>> ietf-examp...@foo.example does not match some...@foo.example.
>> 
>
> But we are agreed that (at least for now) we don't use i= as the basis for  
> Author Signature. The mailing list expander may well add  
> i=ietf-examp...@foo.example, but that is just so humans (and maybe some  
> super-smart Assessors) can observe what has been happening. But, for  
> normal Assessors, that i= is just "opaque" stuff that it can ignore.
>   

Go back and look at the message from the Chair that started this
thread.  I had thought that we were debating the merits of the current
wording vs. an alternative that I offered that replaces the definition
of Author Signature and that means we're still discussing i= vs. d= as a
basis for Author Signature.


>> Using d= as the basis for Author Signature, if the list signs the
>> message, an eventual verifier/assessor will erroneously see that
>> signature as an Author Signature, and therefore might not give the
>> message the desired treatment. ...
>> 
>
> Why ever not? It is From: some...@foo.example. The agent that signed it  
> has already satisfied itself that it is genuine ("additional scrutiny"  
> maybe), and it is signed with d=foo.example. It looks like a Author  
> Signature, it quacks like an Author Signature, therefore it IS an Author  
> Signature. Subsequent Assessors should be perfectly happy to accept it  
> (whether the ADSP for foo.example is "All", "Discardable", or anythng  
> else).
>
> So where is your problem?
>   

My problem is that the semantics of the signature that the mailing list
applies shouldn't depend on whether the original author happens to be in
the same domain as the list.

>   
>> ...  Another option would be for the mailing
>> list manager not to sign this message, which means it needs to do a
>> special case not to sign messages if they're from the same domain and
>> lack an Author Signature.  This is certainly possible, but would be more
>> challenging if the MTA manages many domains.  I also think it's the
>> wrong place to solve the problem.
>> 
>
> Why should that be? It is either signed by the mailing list manager, or it  
> is signed by the outgoing gateway to the Big Wide World, or maybe both. So  
> who cares? Either way, it is sufficiently well signed for it to be  
> acceptable everywhere.
>   

Perhaps.  Or the eventual verifier/assessor may have different criteria
that it uses to evaluate messages from ADSP=all domains that don't have
valid author signatures.

-Jim


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

Re: [ietf-dkim] Consensus point on ADSP

[Jim Fenton]

Charles Lindsey wrote:
> On Sat, 28 Mar 2009 01:09:29 -0000, Jim Fenton  wrote:
>
>
>   
>> 2. It has been noted that a domain might have different reasons for
>> signing a message.  It might, for example, sign a message on behalf of a
>> mailing list manager operating in that domain.  When Author Signature is
>> based on a d= comparison alone, any signature from the same domain as
>> the author is assumed to be a signature representing the original
>> introduction of the message into the mail stream.  That may or may not
>> be an important distinction, but I'm pointing out that information is
>> lost and I'm not sure we have enough experience to say that we don't
>> need it.
>> 
>
> I don't think that is quite right. Suppose foo.example has declared that  
> it signs everything, with strength "Discardable". Then four possibilities  
> arise:
>
> From: some...@foo.exampleFrom:some...@foo.example
> Valid signature from foo.example Absent/broken signature from  
> foo.example
>ACCEPT   DISCARD
>
>  From some...@bar.example From some...@bar.example
> Valid signature from foo.example Absent/broken signature from  
> foo.example
>???  
>
> The first two cases are obvious. The second two are Jim's example. What to  
> do?
>   

The second two cases are not my example.  Concern #2 in my message has
to do with messages where the signing address is a different address in
the same domain as the From address.  The correct test case is:

>From some...@foo.example
Valid signature from ietf-examp...@foo.example

Let's also use "all" instead of "discardable" as the test case because
it's the harder problem to solve.  As you point out, the mailing list
should be acting on the Discardable practice rather than trying to send
the message to the list.

Let's say that ietf-examp...@foo.example is a mailing list that re-signs
mail sent to the list (or it could be a forwarder or similar agent). 
foo.example's mail server gets a message from an address in the same
domain, some...@foo.example, that has no Author Signature or has a
broken one.  In accordance with the domain's policy, it subjects the
message to additional scrutiny because of the "all" practices and lack
of an Author Signature.  The message passes this test and is sent to the
mailing list manager.

At this point, the mailing list manager would normally sign the
message.  Let's examine this with the i= and d= choices:

Using i= as the basis for Author Signature, the list can sign the
message, and the eventual verifier/assessor that does an ADSP check will
see that it (still) lacks an Author Signature since
ietf-examp...@foo.example does not match some...@foo.example.

Using d= as the basis for Author Signature, if the list signs the
message, an eventual verifier/assessor will erroneously see that
signature as an Author Signature, and therefore might not give the
message the desired treatment.  Another option would be for the mailing
list manager not to sign this message, which means it needs to do a
special case not to sign messages if they're from the same domain and
lack an Author Signature.  This is certainly possible, but would be more
challenging if the MTA manages many domains.  I also think it's the
wrong place to solve the problem.

It's up to the WG to decide whether this is a problem that deserves a
solution or whether it's too much of a corner case to bother with
(mailing list manager with users in the same domain that uses
ADSP=all).  I do not like the idea of "just change someone's domain" or
"just change the list's domain" because it has always been DKIM's goal
to operate with existing addresses.

Hopefully this clarifies the test case so that this can be evaluated fairly.

-Jim

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

Re: [ietf-dkim] Consensus point on ADSP

[Jim Fenton]

John Levine wrote:
>
>> Informative Note:  ADSP is incompatible with DKIM signing by parent
>> domains described in section 3.8 of [RFC4871] in which a signer uses
>> "i=" to assert that a parent domain is signing for a subdomain.
>> 
>
> That's not fine, since we've just gone around and agreed that the
> signing identity is d=.  leave this paragraph out.
>   

I'm not sure what you think we have agreed, but the current (-09) ADSP
specification has an informative note pointing out incompatibility of
that version of ADSP with "valid DKIM usage" that isn't explicitly
mentioned in RFC 4871.  Since RFC 4871 does, explicitly, mention this
mode of usage of DKIM we really do need this informative note.

Or, we could just go with the -09 language, which I would prefer anyway.

-Jim

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

Re: [ietf-dkim] Consensus point on ADSP

[Jim Fenton]

Hector Santos wrote:
>
> I think these are addressed with an ADSP "valid signer domains" tag.

I'm sorry, Hector, I really don't see the relationship between the
choice d= and i= values as having anything to do with the "designated
signing domains" (I think it was called) proposal.

>
> The only reason I recall for ditching this "list" idea in SSP was the
> concern it can become large.

That was one reason, but there was working group consensus not to pursue
that idea and I'm fairly sure it's not the Chairs' intent to reopen
other issues that already have been decided by rough consensus.

-Jim

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

Re: [ietf-dkim] Consensus point on ADSP

[Jim Fenton]

Mark Delany wrote:
   Note:   ADSP is incompatible with valid DKIM usage in which a signer
  uses "i=" with values that are not the same as addresses in mail
  headers.  In that case, a possible workaround could be to add a
  second DKIM signature a "d=" value that matches the Author
  Address, but no "i=".

>>
>> I'll start by proposing text that we could use if we adopted an
>> alternate definition of Author Signature based on the d= value only.
>> Then I'll describe what I think we'll lose by going to that definition.
>
> Given that i= is an arbitrary value assigned by the signer, the
> question to me is what value does it add beyond what signed RFC2822
> headers can do just as well. Eg, why not set an rfc2822.Sender Field
> and sign that rather than invent i=?
>
> IOW, what is the value-add in inventing yet another identity called
> DKIM.i= when we already have rfc2822.From, rfc2822.sender,
> rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom?
>
> Are you suggesting that DKIM.i= should have preference over signed
> RFC2822 identifiers?

Not at all.  Signing a particular header field doesn't have any
semantics for DKIM other than to make sure that it doesn't change
between the signer and verifier.  In other words, signing the
rfc2822.Sender field doesn't change the meaning of the signature a bit. 
It just makes sure that a man-in-the-middle hasn't changed that header
field, potentially in a deceptive way.

The "signing identity", i=, is already in the DKIM specification and
isn't a new invention of ADSP.  It doesn't take precedence over signed
RFC2822 identifiers, although there is a suggestion in RFC4871 section
6.3:  "If the message is signed on behalf of any address other than that
in the From: header field, the mail system SHOULD take pains to ensure
that the actual signing identity is clear to the reader."  I take this
as a suggestion to display it in addition to the 2822 From address.

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

Re: [ietf-dkim] Consensus point on ADSP

[Jim Fenton]

DKIM Chair wrote:
> In the IETF 74 DKIM meeting, we had a brief discussion about the current 
> state of 
> ADSP, given the recent discussions on i= (and other things).  It seems to the 
> chairs that ADSP isn't severely affected, and that changes would be needed 
> only 
> in section 2.7, "Author Signature", which is the only place that d= and i= 
> are 
> mentioned.  Here's the current text (from -09), for reference:
>
>   
>> 2.7. Author Signature
>>
>>
>>An "author signature" is a Valid Signature that has the same domain
>>name in the DKIM signing identity as the domain name in the Author
>>Address.  If the DKIM signing identity has a Local-part, it is be
>>identical to the Local-part in the Author Address.  Following
>>[RFC5321], Local-part comparisons are case sensitive, but domain
>>comparisons are case insensitive.
>>
>>For example, if a message has a Valid Signature, with the DKIM-
>>Signature field containing "i...@domain.example", then domain.example
>>is asserting that it takes responsibility for the message.  If the
>>message's From: field contains the address "b...@domain.example", that
>>would mean that the message does not have a valid Author Signature.
>>Even though the message is signed by the same domain, it will not
>>satisfy ADSP that specifies "dkim=all" or "dkim=discardable".
>>
>>Note:   ADSP is incompatible with valid DKIM usage in which a signer
>>   uses "i=" with values that are not the same as addresses in mail
>>   headers.  In that case, a possible workaround could be to add a
>>   second DKIM signature a "d=" value that matches the Author
>>   Address, but no "i=".
>> 

I'll start by proposing text that we could use if we adopted an
alternate definition of Author Signature based on the d= value only. 
Then I'll describe what I think we'll lose by going to that definition.

Here's alternate text based on d=:
=

2.7 Author Signature

An "author signature" is a Valid Signature where the domain of the
signing entity ("d=" value) is the same as the domain name in the Author
Address.  This comparison is case insensitive.

For example, if a message has a Valid Signature with the DKIM-Signature
field containing "d=example.com" then example.com is asserting that it
takes responsibility for the message.  If the message's From field
contains the address "b...@sub.example.com", that would mean that the
message does not have a valid Author Signature because the message is
not signed by the same domain.

Informative Note:  ADSP is incompatible with DKIM signing by parent
domains described in section 3.8 of [RFC4871] in which a signer uses
"i=" to assert that a parent domain is signing for a subdomain.
=

Here is what I see are the problems with this alternative:

1. As noted above, the use of d= means that signing by parent domains,
specifically called out in RFC 4871, doesn't result in Author
Signatures.  This is arguably less of a problem because "ADSP by parent
domains" (the ability of a domain to assert ADSP for a subdomain) was
eliminated some time ago, so ADSP records would need to each for each
subdomain.  However, management of key (selector) records in each
subdomain would still be required, while ADSP records require little or
no management such as key rotation or revocation.

2. It has been noted that a domain might have different reasons for
signing a message.  It might, for example, sign a message on behalf of a
mailing list manager operating in that domain.  When Author Signature is
based on a d= comparison alone, any signature from the same domain as
the author is assumed to be a signature representing the original
introduction of the message into the mail stream.  That may or may not
be an important distinction, but I'm pointing out that information is
lost and I'm not sure we have enough experience to say that we don't
need it.


In the words of Dave Crocker,
> OK.  Start shooting.
>   
-Jim

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

Re: [ietf-dkim] errata revision: Assessor

[Jim Fenton]

Siegel, Ellen wrote:
>   
>> 8.  RFC4871 Section 2.11 Identity Assessor
>>
>>Old:
>>  The name of the module that consumes DKIM's primary
>> 
>> payload, the
>> 
>>  responsible Signing Domain Identifier (SDID).  It can
>> 
>> optionally
>> 
>>  consume the Agent or User Identifier (AUID) value, if
>> 
>> provided to
>> 
>>  the module.
>>
>>New:
>>  The name of the module that consumes DKIM's mandatory
>> 
>> payload, the
>> 
>>  responsible Signing Domain Identifier (SDID).  Other DKIM
>> 
>> values
>> 
>>  can also be delivered this module; however this additional
>> 
>> activity
>> 
>>  is outside the scope of the DKIM signature specification.
>> 
> Replace "Other DKIM values" to "Other information".
>
> My logic: what the assessor consumes beyond the SDID is outside the
> scope of the spec.
>   
 And add "by" between "delivered" and "this".

 After that, +1.
 
>>> +1
>>>   
>> +1
>>
>> 
> +1
>   

Me too.

-Jim

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

Re: [ietf-dkim] errata revision: opaque

[Jim Fenton]

Dave CROCKER wrote:

  darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn 
darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn

definition of AUID is screwed up.  didn't mean to change it.

so...

Dave CROCKER wrote:
  
  
7.  RFC4871 Section 2.10 Agent or User Identifier (AUID)

 Old:
   A single, opaque value that identifies the agent or user on behalf
   of whom the SDID has taken responsibility.

 New:
   A single domain name that identifies the agent or user on behalf
   of whom the SDID has taken responsibility.  For DKIM
   processing, the name has only basic domain name semantics; any
   possible owner-specific semantics is outside the scope of DKIM.

  
  

   New:
 A single value that identifies the agent or user on behalf
 of whom the SDID has taken responsibility.  For DKIM
 processing, the domain name portion of the AUID has only basic
 domain name semantics; any possible owner-specific semantics is
 outside the scope of DKIM.
  


Whew.  Thanks for the revision.  I'm happy with this and the other
definitions in your original message, although I'd suggest s/semantics
is/semantics are/

Just for completeness, I'll point out that some might feel that the
(indirect) statement that the domain name portion of the AUID has
domain name semantics is too strong.  The subdomain portion (the
portion, if any, that is a subdomain of the SDID) doesn't need to be an
actual domain at all.

I'm not sure it's necessary to clutter the definition with this detail,
however.  I'm happy with it the way it is.

-Jim



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

Re: [ietf-dkim] errata revision: Identity Assessor vs. Message Filtering engine

[Jim Fenton]

+1 with Ellen's change.

-Jim

Siegel, Ellen wrote:
>   
>> -Original Message-
>>
>> "Old" refers to the Errata I-D; "New" is the proffered replacement.
>>
>> CAVEAT:
>>
>> This last-of-three postings affects the same section of text as the
>> Assessor
>> revision posting, but attends to a different issue.  I've only just gotten
>> clarification on what this third item was to be, so here's another apology
>> for a
>> bit of confusion.
>>
>> Had I remembered all 3 items I would have tried to merge this with the
>> other
>> Assessor change, which is what the current note attempts:
>>
>>
>> 8.  RFC4871 Section 2.11 Identity Assessor
>>
>>
>> Old:
>>The name of the module that consumes DKIM's primary payload, the
>>responsible Signing Domain Identifier (SDID).  It can optionally
>>consume the Agent or User Identifier (AUID) value, if provided to
>>the module.
>>
>> New:
>>The name of the module that consumes DKIM's mandatory payload, the
>>responsible Signing Domain Identifier (SDID). The module is
>> dedicated
>>to the assessment of the delivered name.  Other DKIM (and non-DKIM)
>>values can also be delivered to this module as well as to a more
>> general
>>message evaluation filtering engine. However this additional
>> activity
>>is outside the scope of the DKIM signature specification.
>>
>> 
>
> Can you explain why you used "dedicated to the assessment of the delivered 
> name" rather than "... of the delivered identifier"? I can live with it 
> either way, but it seems strange to say that it consumes an identifier but 
> assesses a name. 
>
> Aside from that, it looks fine to me. 
>
> Ellen
>
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>   

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

Re: [ietf-dkim] Reading the entrails, was Moving to consensus

[Jim Fenton]

John R. Levine wrote:
> We've still got a fairly basic disconnect here.
>
>> The verifier doesn't need to do anything with the additional field, so
>> if it just passes all unknown fields to the assessor it doesn't need to
>> change at all.
>
> OK, so you're saying that the verifier should consume the fields it
> knows (let's say the fields listed in 4871), and pass along the
> unknown ones. But a couple of messages ago you said that the assessor
> should look at the existing h= value to see if an auxiliary header is
> signed.
>
> It's not my goal to tie you in knots here; I'm trying to figure out
> what you have in mind.  Expecting on people who read the spec to
> interpret vague sections in ways we approve of is not likely to lead
> to happy results.  Perhaps Dave can offer a few RFC 822 horror stories
> here.

If you remember, I started out using Jon Callas's suggestion of adding a
header field and signing it, and you and I agreed that a better approach
is to add a new tag/value instead.  So now I'm discussing the use of a
new tag/value, and not h=.  Requiring a modification to the verifier to
support a new tag/value that is not intended for its consumption is
unnecessary and inhibits deployment of new DKIM extensions.

>
>> Requiring the verifier to change in order to support a new tag/value
>> introduces a significant barrier to the deployment of new tags. ...
>
> The DNS analogy doesn't strike me as a useful one here.  Nearly
> everything in the DNS except for SOA and NS is intended for the
> consuming application*, but everything in DKIM beyond the signing
> identity is intended as ingredients for a complicated recipe producing
> one bit**, signed or not.  The more stuff you allow the assessor to
> peek at, the more you encourage people to invent bogus "more signed"
> or "almost signed" heuristics that will make it harder to interoperate
> reliably.

We may agree to disagree whether existing DKIM fields are useful to the
assessor, but DKIM is extensible and I can think of several things (one
of which is described in draft-fenton-dkim-reputation-hint) that might
be included in the signature and are specifically intended for the assessor.

The DNS analogy points out that there's a problem with APIs that
unnecessarily restrict information about unknown RR types, as there is
with unknown (to the verifier) tag types.

-Jim

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

Re: [ietf-dkim] Reading the entrails, was Moving to consensus

[Jim Fenton]

John R. Levine wrote:
>> I agree that it is better to include this information in the signature
>> itself, which is why draft-fenton-dkim-reputation-hint does it that
>> way.  But the constraints on the output of the verifier being proposed
>> would mean that the assessor can't depend on that additional tag/value
>> being available to it.
>
> Right.  You say this as though it's a bad thing, but as I've said
> three times, constraining the interface is key to interoperating.
>
>> How does one "say that field is passed...to the assessor"?  The
>> signer certainly can't, and it shouldn't be necessary to modify the
>> verifier to do that.
>
> I'd do it by writing up an I-D and specifically saying what to pass to
> the assessor.  Unless you expect the assessor to make an end run
> around the verifier, you're going to have to change the verifier
> anyway to expand the set of stuff it exports.

The verifier doesn't need to do anything with the additional field, so
if it just passes all unknown fields to the assessor it doesn't need to
change at all.  Requiring the verifier to change in order to support a
new tag/value introduces a significant barrier to the deployment of new
tags.

Consider the case of DNS resolvers.  Many resolvers can support new RR
types without modification, and for those resolvers the addition of new
RR types isn't a problem.  However, a few resolvers do require
modification, and it is because of these resolvers that it is extremely
difficult to add a new RR, contributing to the need to overload TXT. 
Let's not make the analogous mistake with DKIM.

>
> Here's a list of things that a verifier might pass to the assessor:
>
> * The number of fields in the DKIM-Signature header
> * The order of the header names in h= field
> * The number of headers in the message which are out of order relative to
>   their order in h=
> * Whether the signature includes q=dns/txt or defaults it
> * The number of characters in the DKIM-Signature header, mod 17
>
> I hope you'll agree that it would be pretty stupid for the assessor to
> depend on any of those.  So, for a standard protocol, one where the
> goal is to allow every mail system in the world to interoperate, where
> do you draw the line for verifier outputs?  If you want to
> interoperate, you make it as small as possible, which means it's just
> the signing domain in each valid signature.  (If you use ADSP, there's
> also two bits of ADSP output.)

The fact that there are silly things that a verifier could pass to an
assessor does not convince me that there aren't any useful ones.

-Jim

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