Re: [ietf-dkim] Acronyms
On Thu, 12 Mar 2009 19:51:04 +0100 Eliot Lear wrote: >On 3/12/09 3:56 PM, Dave CROCKER wrote: >> Is anyone /against/ using AUID? >> > >In so far as we cannot avoid a new acronym, I am not against AUID. > >Eliot + 1 Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Acronyms
On 3/12/09 3:56 PM, Dave CROCKER wrote: > Is anyone /against/ using AUID? > In so far as we cannot avoid a new acronym, I am not against AUID. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Acronyms
Dave CROCKER: > Is anyone /against/ using AUID? > > d/ > > Suresh Ramasubramanian wrote: > > On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba > > wrote: > >>> Somewhat whimsically but wholly serious: Would simply changing the > >>> acronym to AUID (for Agent or User IDentifier) avoid mistaken > >>> connotations associated with User Agents (UAs)? > >> WFM. > > > > +1 +1 Looks good to me. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving on to ADSP - removing i= value dependence
On Mar 12, 2009, at 6:24 AM, MH Michael Hammer (5304) wrote: > From: Douglas Otis, Mar 11, 2009 7:40 PM >> On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote: >>> >>> If the DKIM-Signature header field does not contain the "i=" tag, >>> the verifier MUST behave as though the value of that tag were >>> "@d", where "d" is the value from the "d=" tag. >> >> A signature lacking an i= value defaults to the d= value, but this >> does not represent a From email-address! As someone said, domains >> do not write emails, which leaves the "on-behalf-of" identity >> *undefined*. > > Whether i= or d=, when I go to look for the ADSP record I'm only > looking at the RHS of the address. Therefore, what does it matter if > a signature lacking an i= defaults to d=? Logically, unless I have a > constraining g value and even then (note well): elided > > Domains sign mail. Unless you can show that every user has access to > creating/modifying the keys in DNS. You have provided nothing that > shows there is an issue. Is this agreement with removing dependence upon the i= value? >>> There is nothing special about a DKIM signature missing an i= >>> filed. One simply uses the d= field. Seems pretty straight forward >>> to me. >> >> Why must an i= value only represent a From email-addresses when >> present, when it is equally okay for the i= value to be omitted? >> When a DKIM public key imposes a g= restriction, the i= value MUST >> contain the restricted local-part or the DKIM signature WILL NOT be >> valid. > > So what's the problem? Do you expect domains publishing an ADSP > policy to intentionally not provide an i= value and include a g= > value? The original motivation for ADSP imposing i= value dependence was in hope of causing non-From-g-restricted-signatures to be rejected. Ironically, few domains will double-sign exceptions to ADSP's requirement that i= values must matching against a From email- address. In effect, this inhibits both the intended use of the i= value and ADSP. If few domains use ADSP, few receiving MTA will reject messages on the basis of non-From-g-restricted-signature non- compliance with ADSP. When MUAs annotate using Authentication-Results headers, non-From-g- restricted-signatures represent less risk since MUAs can still determine the intended identity, whether the identity is the list- manager as Sender or the From header. Currently, ADSP dependence upon the i= value may require inclusion of a DKIM signature where the i= value is omitted, which can not be done by a non-g-restricted- signature. If non-From-g-restricted-signatures represent a significant risk, they should be considered invalid by the base specifications! > I admit that there will always be some people who will screw things > up regardless of how careful a framework is constructed and how many > warnings and cautions are provided.. so what? It's kind of like > publishing an SPF record that consists of only "-all" and then > complaining that people are not accepting your mail. By removing i= dependence, an ADSP assertion of "all" could then mean _all_ messages are signed. This reduces mistakes and keeps things simple, while also eliminating possible double signing requirements. >> It will be evident to an MUA whenever a restricted local-part does >> not match against a From header. It should also be safe for an MUA >> to annotate signed headers that match against the i= value, but not >> those that do not match, such as when the i= value is omitted or it >> omits everything but the d= value. In such cases, just the domain >> might be annotated. > > And where is the problem? Go do the lookup against the d= domain. > That is what the default is. Notwithstanding the g tag constraint, > this works fine thank you very much. In order to exclude non-From-g-restricted-signatures, all i= values that do not match against the From header must currently be double signed. This additional requirement is a problem when few wish to double sign otherwise perfectly valid DKIM signatures. >> In either case, the i= value (on-behalf-of identity) might become >> declared as being opaque and thus defined as not representing a >> specific email-address. When the i= value is declared opaque, no >> email-address should be annotated, even when it happens to match >> against the i= value. > > Conflating layers. Just because DKIM base considers it an opaque > value does not mean that ADSP must consider it an opaque value. By > choosing to publish an ADSP record one is at least indicating that a > receiver (again excepting the g tag case you specified with no i= > present - a quite artificial construct that should fail) should look > at the RHS of the string called an RFC2822From email address. ADSP records are not checked when there is a valid Author Signature. An Author Signature IS a DKIM signature! If i= value
Re: [ietf-dkim] DKIMcore
On Mar 11, 2009, at 2:48 PM, Franck Martin wrote: > http://dkimcore.org/dkimcore.pdf > > I just stumbled on this document, this seems strange to me. What do > you think? It's a work in progress to provide operational documentation for typical senders who want to use DKIM, but for whom the dry RFC-style specification isn't as helpful as a more HOWTO set of docs. There was some text around the intent of the document and it's relationship to DKIM in the mail you received in confidence prior to sharing it here, but that's not ready to go up publicly on the website yet. Maybe next week. (Part of the reason for the delay is that in the process of putting it together I may have found what looks like a hole in the DKIM spec or, more likely, some common implementations of it, and I want to see whether that's so or not first). > > I find that adding a hash on the body and putting it in the DKIM > record will certainly break the DKIM spec, as it stops mailing lists > to forward a DKIM email and add a footer to the email as the first > example that comes to mind. Well, that's the DKIM signing algorithm, so if it's broken you should take it up with the authors of 4871. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Acronyms
I'm still not convinced that adding acronyms makes the document clearer, but AUID seems fine to me. -Jim Dave CROCKER wrote: > Is anyone /against/ using AUID? > > d/ > > > Suresh Ramasubramanian wrote: > >> On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba wrote: >> Somewhat whimsically but wholly serious: Would simply changing the acronym to AUID (for Agent or User IDentifier) avoid mistaken connotations associated with User Agents (UAs)? >>> WFM. >>> >> +1 >> ___ >> 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] Acronyms
On Thu, Mar 12, 2009 at 10:30 AM, Siegel, Ellen wrote: > >> On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba >> wrote: Somewhat whimsically but wholly serious: Would simply changing the acronym to AUID (for Agent or User IDentifier) avoid mistaken connotations associated with User Agents (UAs)? >>> >>> WFM. +1 -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Acronyms
> On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba > wrote: >>> Somewhat whimsically but wholly serious: Would simply changing the >>> acronym to AUID (for Agent or User IDentifier) avoid mistaken >>> connotations associated with User Agents (UAs)? >> >> WFM. > > +1 > +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Chairs away
Stephen and I are both on the editorial board of IEEE Internet Computing magazine, and we'll both be at the board's meeting, in New Orleans, for the next couple of days. I don't know when Stephen will be back to normal, but don't count on my presence here 'til I catch up on Monday. Carry on with discussion until then, and please don't snipe at each other while we're not around to tidy up. Play nice. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Draft agenda for DKIM at IETF 74
There will, as always, be jabber and a live audio feed. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Acronyms
Is anyone /against/ using AUID? d/ Suresh Ramasubramanian wrote: > On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba wrote: >>> Somewhat whimsically but wholly serious: Would simply changing the >>> acronym to AUID (for Agent or User IDentifier) avoid mistaken >>> connotations associated with User Agents (UAs)? >> WFM. > > +1 > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Draft agenda for DKIM at IETF 74
I would be interested in participating through jabber as well. Mike > -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Hector Santos > Sent: Thursday, March 12, 2009 3:22 AM > To: DKIM Chair > Cc: DKIM Mailing List > Subject: Re: [ietf-dkim] Draft agenda for DKIM at IETF 74 > > Is there going to be any active Jabber sessions? > > -- > Sincerely > > Hector Santos > http://www.santronics.com > > > > DKIM Chair wrote: > > I've uploaded the following draft agenda to the IETF 74 meeting > materials page. > > https://datatracker.ietf.org/meeting/74/materials.html > > > > This is a first stab at a draft, and I've made wild guesses at the > times. If you > > have better suggestions for dividing up the time, let Stephen and me > know, at > > . Similarly, let us know if we've wildly > messed up > > on what we need to discuss, if you have a topic you'd like to have some > time for, > > or if there are any other sorts of adjustments we should make to the > agenda. > > > > --- > > DKIM working group > > Imperial A > > Wednesday, 25 March, 2009 > > 09:00 - 11:30 > > > > Chairs: > > Stephen Farrell > > Barry Leiba > > > > Agenda (document references [in brackets]): > > 09:00 - 09:10 : Introduction / Blue Sheets / Agenda Bashing (10 mins) > > 09:10 - 09:20 : Overview and Deployment status [1],[2] (10 mins) > > 09:20 - 09:40 : How to proceed with the errata (20 mins) > > - Discuss WG-approved errata vs "update" RFC vs > "replacement" RFC > > 09:40 - 10:20 : Discussion of errata draft [3] (40 mins) > > 10:20 - 10:50 : Discussion of ADSP and how to proceed with it [4] (30 > mins) > > - We may use "reputation hint" as an example of > extending DKIM [5] > > 10:50 - 11:20 : Draft Standard and beyond (30 mins) > > - Is DKIM ready to go to Draft Standard after the errata > are > > cleared up? > > 11:20 - 11:30 : Any other business (10 mins) > > > > Collected Documents for Review: > > [1] http://tools.ietf.org/html/draft-ietf-dkim-overview > > [2] http://tools.ietf.org/html/draft-ietf-dkim-deployment > > [3] http://tools.ietf.org/html/draft-ietf-dkim-rfc4871-errata > > [4] http://tools.ietf.org/html/draft-ietf-dkim-ssp > > [5] http://tools.ietf.org/html/draft-fenton-dkim-reputation-hint > > --- > > > > Barry > > > > -- > > Barry Leiba, DKIM working group chair (barryle...@computer.org) > > http://internetmessagingtechnology.org/ > > > > > > ___ > > 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Another take on "all email from us is dkim signed"
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Steve Atkins > Sent: Wednesday, March 11, 2009 4:36 PM > To: ietf-dkim WG > Subject: Re: [ietf-dkim] Another take on "all email from us is dkim > signed" > > > On Mar 11, 2009, at 1:20 PM, MH Michael Hammer (5304) wrote: > > >> > >> It seems to me that the domains likely to benefit from the ability to > >> state "All email we send is DKIM signed" share a few things in > >> common. > >> > >> 1. They're concerned about other people sending email claiming to > >> be "from" the domain. > >> > >> 2. They send email using the domain to, typically, a large number > >> of B2C recipients (excluding the null assertion "we send no email", > >> which can be handled in other ways) > >> > > > > I would not exclude B2B out of hand. Many financial institutions > > communicate with business customers. I would also point to this > > example > > http://www.webpronews.com/topnews/2007/10/31/grocery-store-falls-for-10- > > million-phishing-scam as to why businesses might want to assert that > > all > > their B2B mail is signed. > > The same reasoning applies to B2B email. > > > Which other ways would you assert "we send no mail" to protect the > > RFC2822 From email address? > > SPF is the obvious solution. MX 0 . is another. > There are a number of issues in using SPF in the manner you suggest. The first is that SPF is path based. It basically says "here are the hosts authorized to send mail for this domain" (transport layer). The RFC2822 >From is data, not transport layer. This is exactly the complaint against Microsoft/Sender-ID when they decided to misuse SPFv1 records for PRA evaluation. SPF protects the transport layer Mail From and EHLO. For most implementations I'm aware of the intent and practice is to reject at EHLO or reject on Mail From. At this point the RFC2822 From is not available for checking. If a receiver has already checked > However, given the supposed threat is phishing, "we send no email" > is mostly a red herring. > > > > > >> 3. All the email they send is DKIM signed. > >> > >> 4. They primarily care about mail appearing to be "from" their > >> domain being sent to users who also legitimately receive real email > >> from them. > >> > >> It also seems that the number of domains who want this will likely be > >> a small fraction of the total number of domains, and likely a small > >> fraction of the number of emails sent. > >> > > > > That may be true today but may not be true tomorrow. > > > >> The combination of 2, 3 and 4 means that any receiving ISP that > >> receives "forged" email that the domain cares about will also receive > >> legitimate email from that domain. > >> > > > > Perhaps, perhaps not. There is also the case of an ISP receiving > > fraudulent email prior to receiving legitimate email (race condition). > > If the threat is phishing, this is very unlikely. Phishing is pretending > to be an existing brand. If the existing brand is already in use then > it's very likely that there's going to be at least one existing user at > an ISP. It would also be very easy to setup your business model > such that you can ensure that every user has received at least > one legitimate email from you before they are in the situation > where they are at any risk of phishing. Sending them an email > with their username in it, for example. > A brand can have brand recognition without an individual (or receiving domain) having received an email from that domain before. Take the domain ibm.com. How many people are familiar with IBM as a company/brand? How many people know that IBM never sends email from the primary domain ibm.com? So how many receivers have received an email from ibm.com? (the correct answer is none). Consider the cases of Facebook, MySpace, and LinkedIn. Many people/receivers were aware of the brands long before they received an email from those brands. So, how would individuals/receivers know a priori what the characteristics of a legitimate email from those brands are or what a legitimate email from those brands should look like? > If the threat is not phishing, then we need to be explicit about what > the threat is before judging how different approaches affect it. > I've been talking about phishing. What other threats would you like to throw into the fire? > > > >> If there were another field in the DKIM-Signature header, or an > >> entirely separate email header covered by the DKIM signature, that > >> stated "all email sent using this domain in the From field will be > >> DKIM signed" then any receiving MTA or MTA cluster could keep track > >> of > >> that state (probably using their existing reputation tracking system > >> in the case of large receivers, and using a fairly trivial extension > >> to their DKIM plugins in the case of smaller ones). > >> > >> That would provide all the benefit of ADSP to senders who want it, > >> without
Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingthe errataafter the consensus call
> -Original Message-
> From: Douglas Otis [mailto:do...@mail-abuse.org]
> Sent: Wednesday, March 11, 2009 7:40 PM
> To: MH Michael Hammer (5304)
> Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingthe
> errataafter the consensus call
>
>
> On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote:
> >> On Mar 11, 2009 11:12 AM, Douglas Otis wrote:
> >>
> >> The only logic for requiring either a DKIM signature that lacks an
> >> i= value, or one that matches against the From header, would be
> >> there is something special about a DKIM signature that lacks the i=
> >> value. There does not appear to be any rational semantics to
> >> explain what is implied when the i= value is missing. On that
> >> point, Dave is correct.
> >
> > You are incorrect Doug. Look at RFC4871:
> >
> > If the DKIM-Signature header field does not contain the "i=" tag,
> > the verifier MUST behave as though the value of that tag were "@d",
> > where "d" is the value from the "d=" tag.
>
> A signature lacking an i= value defaults to the d= value, but this
> does not represent a From email-address! As someone said, domains do
> not write emails, which leaves the "on-behalf-of" identity
*undefined*.
>
Whether i= or d=, when I go to look for the ADSP record I'm only looking
at the RHS of the address. Therefore, what does it matter if a signature
lacking an i= defaults to d=? Logically, unless I have a constraining g
value and even then (note well):
g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a
key to a third party that should only be used for special
purposes. Wildcarding allows matching for addresses such as
"user+*" or "*-offer". An empty "g=" value never matches any
addresses.
Domains sign mail. Unless you can show that every user has access to
creating/modifying the keys in DNS. You have provided nothing that shows
there is an issue.
> > There is nothing special about a DKIM signature missing an i= filed.
> > One simply uses the d= field. Seems pretty straight forward to me.
>
> Why must an i= value only represent a From email-addresses when
> present, when it is equally okay for the i= value to be omitted? When
> a DKIM public key imposes a g= restriction, the i= value MUST contain
> the restricted local-part or the DKIM signature WILL NOT be valid.
So what's the problem? Do you expect domains publishing an ADSP policy
to intentionally not provide an i= value and include a g= value? I admit
that there will always be some people who will screw things up
regardless of how careful a framework is constructed and how many
warnings and cautions are provided.. so what? It's kind of like
publishing an SPF record that consists of only "-all" and then
complaining that people are not accepting your mail.
> It will be evident to an MUA whenever a restricted local-part does not
> match against a From header. It should also be safe for an MUA to
> annotate signed headers that match against the i= value, but not those
> that do not match, such as when the i= value is omitted or it omits
> everything but the d= value. In such cases, just the domain might be
> annotated.
>
And where is the problem? Go do the lookup against the d= domain. That
is what the default is. Notwithstanding the g tag constraint, this works
fine thank you very much.
> In either case, the i= value (on-behalf-of identity) might become
> declared as being opaque and thus defined as not representing a
> specific email-address. When the i= value is declared opaque, no
> email-address should be annotated, even when it happens to match
> against the i= value.
>
Conflating layers. Just because DKIM base considers it an opaque value
does not mean that ADSP must consider it an opaque value. By choosing to
publish an ADSP record one is at least indicating that a receiver (again
excepting the g tag case you specified with no i= present - a quite
artificial construct that should fail) should look at the RHS of the
string called an RFC2822From email address.
> >> Since the ADSP draft is already internally in conflict on this
> >> point, a simple solution would be to drop the i= value requirement
> >> in ADSP.
> >
> > I see no conflict.
>
> Oops. This has been corrected off-list since version 6. Section 3.2
> now states Author Signature. Well, Section 3.2 will need to change
> bac
Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errataafter the consensus call
On 3/11/09 6:28 PM, MH Michael Hammer (5304) wrote: > The use of i= allows multiple subdomains to have the same d= DKIM > signature. As I said, I can live with d= personally but viewing it from > a standards approach I recognize the value of using i= for organizations > that use a number of subdomains. > The difference between one record and two records per label is quite a bit smaller than the difference between no label and one. This group burnt the i= bridge when we required each and every subdomain to have a valid ADSP record. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Draft agenda for DKIM at IETF 74
Is there going to be any active Jabber sessions? -- Sincerely Hector Santos http://www.santronics.com DKIM Chair wrote: > I've uploaded the following draft agenda to the IETF 74 meeting materials > page. > https://datatracker.ietf.org/meeting/74/materials.html > > This is a first stab at a draft, and I've made wild guesses at the times. If > you > have better suggestions for dividing up the time, let Stephen and me know, at > . Similarly, let us know if we've wildly messed > up > on what we need to discuss, if you have a topic you'd like to have some time > for, > or if there are any other sorts of adjustments we should make to the agenda. > > --- > DKIM working group > Imperial A > Wednesday, 25 March, 2009 > 09:00 - 11:30 > > Chairs: > Stephen Farrell > Barry Leiba > > Agenda (document references [in brackets]): > 09:00 - 09:10 : Introduction / Blue Sheets / Agenda Bashing (10 mins) > 09:10 - 09:20 : Overview and Deployment status [1],[2] (10 mins) > 09:20 - 09:40 : How to proceed with the errata (20 mins) > - Discuss WG-approved errata vs "update" RFC vs "replacement" > RFC > 09:40 - 10:20 : Discussion of errata draft [3] (40 mins) > 10:20 - 10:50 : Discussion of ADSP and how to proceed with it [4] (30 mins) > - We may use "reputation hint" as an example of extending > DKIM [5] > 10:50 - 11:20 : Draft Standard and beyond (30 mins) > - Is DKIM ready to go to Draft Standard after the errata are > cleared up? > 11:20 - 11:30 : Any other business (10 mins) > > Collected Documents for Review: > [1] http://tools.ietf.org/html/draft-ietf-dkim-overview > [2] http://tools.ietf.org/html/draft-ietf-dkim-deployment > [3] http://tools.ietf.org/html/draft-ietf-dkim-rfc4871-errata > [4] http://tools.ietf.org/html/draft-ietf-dkim-ssp > [5] http://tools.ietf.org/html/draft-fenton-dkim-reputation-hint > --- > > Barry > > -- > Barry Leiba, DKIM working group chair (barryle...@computer.org) > http://internetmessagingtechnology.org/ > > > ___ > 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
