gmane.ietf.dkim

Stephen Farrell's Yes onstatus-change-dkim-to-internetstandard-03:(with COMMENT)

Stephen Farrell — 2013-05-13T01:41:45

Stephen Farrell has entered the following ballot position for
status-change-dkim-to-internetstandard-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)





----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


As a former co-chair of the DKIM wg, but never having been a
real axe-grinder, I think this transition is entirely fine and is a good
plan if we believe in standards-track progression.

And BTW, DKIM deployment got as far as tcd.ie - that really does
mean that this signing mechanism has become near universal. I'm
not at all clear that the corresponding verification mechanism is
as widely deplloyed, but that's ok.

Support for DKIM to become an Internet Standard

Franck Martin — 2013-05-08T01:21:38

It is time for DKIM to become an Internet Standard, it has wide adoption and it is time to be able to build upon it with protocols like DMARC or to improve the usage of DKIM with BCP for key strength and key rotation. DMARC reporting has helped fix some bugs in different implementations making it even more reliable. DKIM operations are not anymore resource intensive for a MTA (in comparison to other operations). Finally as an Internet Standard this may encourage some MTA implementations to not break DKIM when simply forwarding emails.

DMARC working group charter proposal

Murray S. Kucherawy — 2013-04-01T05:26:01

At the IETF meeting in Atlanta, Tim Draegen presented a proposal for DMARC,
which is an email authentication and reporting layer atop SPF and DKIM.
The externally-developed proposal is now in widespread deployment by a
number of large-scale providers.  The group that developed it is seeking to
bring it to the IETF for further development and broad review, and
development of operational guidance.

A first draft of a charter can be found linked from
http://wiki.tools.ietf.org/wg/appsawg/trac/wiki.

There is a dmarc< at >ietf.org list available for discussing the technical
contents of the work and also this draft charter.  Please follow up there
with any charter contents so we don't innundate this list with that
discussion.  To subscribe to that list:

https://www.ietf.org/mailman/listinfo/dmarc

-MSK

Re: Authentication-Results

Hector Santos — 2013-03-27T05:11:23

Our "extant" product supports AUTH-RES for DKIM and ADSP.  Without a 
thorough review again and confirmation, I feel, unfortunately, probably 
not 100% according your specification. At the time it was implemented, 
over a few years ago, I had found it inadequate to cover all bases. I do 
recall it was mentioned.  I think this may be ADSP only.   When no MFA 
(Mail Filter Agent) standards, and AFAIK, no one is filtering on this 
stuff, I didn't think it passed all the information necessary for a 
future MFA.

Example, a record for triple signatures via a list submission.

Authentication-Results: dkim.winserver.com;
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 adsp=fail policy=unknown author.d=resistor.net signer.d=ietf.org 
(unauthorized signer);
 dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=opendkim.org 
header.s=mail2010 header.i=opendkim.org;
 adsp=fail policy=unknown author.d=resistor.net signer.d=opendkim.org 
(unauthorized signer);
 dkim=fail (DKIM_SIGNATURE_BAD_BUT_TESTING) head

Authentication-Results

Murray S. Kucherawy — 2013-03-22T16:54:51

Colleagues,

(with apologies for the cross-posting if you get more than one copy of this)

As you may have seen already, I'm working on a revision to RFC5451.

A Proposed Standard "bis" effort always benefits from describing extant
implementations.  I know about the ones I've written, and about some very
public uses of it (Gmail, Yahoo, for example).  If there's anyone in this
audience that knows of others, I'd love to hear about it.

Reviews of the update are also welcome:

https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/

Thanks,
-MSK

Re: "IETF work is done on the mailing lists"

Eliot Lear — 2012-11-29T07:53:53

Hi Geoff,

On 11/29/12 3:56 AM, Geoff Huston wrote:

In my experience, when the IETF has been offered work that the other
party felt was "complete" and would refuse to allow changes to, we've
demurred (c.f., html).  On the other hand, in the instances I'm aware,
when the IETF did accept the work, it was always made clear that the
IETF had change control (and used it).  A perfect current example of
this right now is scim.  There were numerous implementations of scim,
and it was brought to the IETF not only for the imprimatur but also to
improve the work.

A simpler explanation is that the authors and editors of work are more
immersed than others, and therefore project more authority.  Certainly
that has been the case in nearly all efforts I've been involved, with a
notable exception that also is illustrative: oauth, where an editor left
the IETF precisely because he could not agree with the results.  that's
a good indication that we're striking a balance.

Eliot

Re: The good ol' "t=" tag in key records

Dave Crocker — 2012-07-26T21:38:26


On 7/23/2012 8:20 AM, Murray S. Kucherawy wrote:


Verification doesn't matter.

Again, the current normative text is straightforward and reads:

     "Verifiers MUST NOT treat messages from Signers in testing mode 
differently from unsigned email,..."

That's an absolute.  It's does not depend upon whether the signature 
validated or didn't validate.  It says that the processing of the 
signature is not to affect the handling behavior.

All I did with the modifications is to add some brute force assurance 
that the reader will not misinterpret or miss criteria or implications. 
  The changes do not change the existing semantics.

d/

Re: The good ol' "t=" tag in key records

Murray S. Kucherawy — 2012-07-26T21:32:40

On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner <
roland.turner< at >trustsphere.com> wrote:


Pretty much.


We could, if we ever want to change DKIM again.  It sounds like Barry's
approach to register a new "t=" value, or a new tag altogether, is a viable
path forward until someone decides to take up the reins and push DKIM to
Internet Standard status.

-MSK

Re: The good ol' "t=" tag in key records

Hector Santos — 2012-07-23T17:06:11

It shouldn't matter what t=y is or not, where the final result came 
from, technical or reputation. Unless there is a strong exclusive 
policy involved based on ADSP or some FUTURE REP-POLICY idea saying;

  ADSP:       This mail must be signed.
  REP-POLICY: This mail must be a good reputation.

The bad guy does not need to give any sort of signature or rep hints 
in the mail, and the mail is accepted anyway (or passes this test). 
At the very least, with ADSP we have the Author-Domain anchor always 
available to do policy test, but for reputation its dependency on a 
signer-domain, there is no technical possibility to get that 
information. So you need a signature (valid or not) for reputation in 
order for it to even work.

Anyway, for t=y, verifiers SHOULD NOT treat testers any different from 
production mode signers.  I think that is what is the intent now is 
for the current DKIM text, if not, it should be clarified.

Re: The good ol' "t=" tag in key records

Hector Santos — 2012-07-23T16:42:48

It is if POLICY is applied.  If the conditions are:

    DKIM record has t=y
    ADSP record has DISCARDABLE
    MAIL is unsigned (or failed to verify)

Should ADSP processor honor the DKIM t=y?  I don't think so since this 
opened the door to abuse. This is why the t=y flag was pulled from SSP 
draft rev2.  This is why the text in I-D DSAP was:

     The t=y tag is optional.  If defined, the domain is currently testing
     DKIM.  Verifiers SHOULD NOT treat testers any different from
     production mode signers.  It SHOULD NOT be used as a way to bypass a
     failed signature classification policies.  However, verifiers SHOULD
     track testers for over extended usage of test signatures and MAY
     consider using the results to provide feedback to the domain.

The issue is mixed up with the concept of domain experimentation and 
reporting, the desire to report results to domains during a 
testing/exploration phase and to make sure the receiver processor does 
not reject their bugs during the testing ph

Re: The good ol' "t=" tag in key records

Murray S. Kucherawy — 2012-07-23T15:20:12

This isn't quite right, I think.  For a signed message that verifies, a
negative reputation should still be considered applicable.  A positive one
should not.  That's not equivalent to unsigned.

-MSK

Re: The good ol' "t=" tag in key records

Michael Thomas — 2012-07-23T13:42:09

On 07/23/2012 06:13 AM, Barry Leiba wrote:

There seems like there are many things wrong with this sort of
"helpfulness". If a given selector is dodgy, the reputation system
should figure that out for itself. Believing even a vaguely
positive-assertion from the source is almost certainly a mistake,
and likely to be gamed if you do.

Mike

Mike

Re: The good ol' "t=" tag in key records

Michael Thomas — 2012-07-23T13:51:13

Yes, I got that. I still think it's a bad idea to pay attention to it as it's
very likely that the reputation service will be gamed if it does.

Mike

Re: The good ol' "t=" tag in key records

Dave Crocker — 2012-07-23T14:28:34


On 7/21/2012 9:50 PM, Murray S. Kucherawy wrote:


When Murray and I talked, I didn't review the existing text.  Having 
just done that:


I see that its semantics already cover the case that is being discussed, 
specifically with the core clause:  "Verifiers MUST NOT treat messages 
from Signers in testing mode differently from unsigned email,..."

That any reader does not readily see this suggests to me that some 
clarification language would be useful to apply, as well as an 
annotation about report.

The clarification attempted in the remainder of that sentence appears to 
cause readers to think that successful verification is excluded!

Here are two small tweaks that might correct things:

       y  This domain is testing DKIM.  Verifiers MUST NOT treat messages
          from Signers in testing mode differently from unsigned email.
          This covers both successful and failed verification.
          Verifiers MAY wish to track and report testing mode results to
          assist the Signer.


d/

Re: The good ol' "t=" tag in key records

Murray S. Kucherawy — 2012-07-23T13:44:58


Right.



Since RFC6376 ascribes almost no real meaning to "t=", what's the harm with
revising its definition, perhaps with an "Updates" draft?

Otherwise, I'm fine with that path if others are.

-MSK

Re: The good ol' "t=" tag in key records

Barry Leiba — 2012-07-23T14:04:11

What I should have said was "overloading t=y", which seems like what
you're proposing... and RFC 6376 absolutely ascribes a meaning to t=y:
it indicates some sort of testing mode.

If you want to do this, you need a new flag ("t=r", or some such) or a
new tag, and it should be specifically aimed at reputation, not at any
sort of testing mode.  I don't think "Updates 6376" is needed nor
appropriate; it's a straight extension.

That said, I'm inclined to agree with Mike T that input from the
reputation target is suspicious, so it's not clear how much value it
will have nor whether it might be gamed (by the reputation target) or
hacked (by someone wanting to hurt the target's reputation).

Barry

Re: The good ol' "t=" tag in key records

Murray S. Kucherawy — 2012-07-23T13:47:44

To be precise, the thinking was more "Don't ascribe any positive benefit to
this message based on our reputation."  You could still adjust your
reputation of the signer based on the quality of what that domain is
signing.  It's a voluntary negative-only assertion.

-MSK

Re: The good ol' "t=" tag in key records

Murray S. Kucherawy — 2012-07-23T13:41:59

On Mon, Jul 23, 2012 at 6:26 AM, Richard Dawe
<rich.dawe< at >messagesystems.com>wrote:

I don't understand what you're after here.  How would a mail receiver apply
"p=none" as different from handling a bad signature?  In both cases,
delivery is supposed to be unaffected.

-MSK

Re: The good ol' "t=" tag in key records

Barry Leiba — 2012-07-23T13:13:47

"Should't have been signed by us" clearly can't mean that someone
stole the private key or otherwise hacked things, so you're saying,
"Our processes might not be set up right, and we might be signing crap
sent by bad guys.  Give us a break until we get things straight."


No, it absolutely doesn't, and please don't do that.  This was not
something that had been considered during the development of 6376, but
didn't make it into the document correctly.  You might consider that
it's something that *should* have been considered, and oops, we blew
it... but that's not what the errata system is for.  There's a DKIM
wiki and issue tracker still available on the former working group's
tools page ( http://tools.ietf.org/wg/dkim/ ), and we can change the
permissions on the issue tracker if folks want to use that to track
these sorts of things for future updates.

But more to the point, it seems that this isn't a specific "we're
testing our system" issue, but a separate issue related to reputation:
"Do not use signatu

Re: The good ol' "t=" tag in key records

Murray S. Kucherawy — 2012-07-23T02:01:04

That's certainly true, but then again actual reputation services based on
DKIM hadn't been developed back then.  Maybe an applicability statement
will be a good thing to do once this has been explored a little more, or it
could be included in progression to IS status.

-MSK

Re: The good ol' "t=" tag in key records

Hector Santos — 2012-07-22T15:00:16

Its not the first time John.  No Tolerance for continued failure with 
a t=y has long been advocated hence the current text for opening the 
door for tracking.  The threads and discussions are long and deep on 
this matter.

It was actually pulled from SSP.