Re: [ietf-dkim] DKIM and EAI

[Murray S. Kucherawy]

On Fri, Feb 9, 2018 at 3:22 PM, John Levine  wrote:

> In article <1707398.kN3rUcK64s@kitterma-e6430> you write:
> >Does this need to update RFC 7208 since there are SPF related MUST
> >requirements?
>
> I would think so, also 6376, 7489, 7601 since it updates DKIM, DMARC, and
> A-R specs.
>

Since 7601bis is now a live DMARC WG document, you might want to make some
suggestions over there since 7601 will be obsoleted.

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

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[Murray S. Kucherawy]

On Thu, Feb 8, 2018 at 5:22 AM, John R. Levine  wrote:

> someone asked me about case sensitiveness of the header field name.  I
>> looked
>> for an ABNF in RFC6376, but only found examples and informative notes.
>>
>
> I was going to say that can't possibly be true, but it's true, there's no
> ABNF for the header.  So, for example, I don't know whether the v= field
> has to come first.  Send an erratum, we'll probably accept it as hold for
> update.
>

"v=1" doesn't have to come first.  It just usually does.  I think there was
a version of RFC4871 that did that, but then when challenged we couldn't
come up with a good reason to keep it that way.

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

Re: [ietf-dkim] Mailsploit

[Murray S. Kucherawy]

On Tue, Dec 5, 2017 at 2:52 PM, Pawel Lesnikowski 
wrote:

>
> DKIM works as expected, but as you said it may re-enforce an incorrect
> assumption that email is from respected source.
>
>
Only if it's abused by saying "DKIM signature verified, it's safe!" rather
than " signed this, hope that's cool".

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

Re: [ietf-dkim] Mailsploit

[Murray S. Kucherawy]

I disagree that it's specifically a DMARC issue, because from that I infer
that you think DMARC is at fault here, i.e., that you expected it to deal
with this.

On Tue, Dec 5, 2017 at 1:44 PM, Steve Atkins 
wrote:

> That's DMARC working exactly as designed but not as commonly understood,
> which makes it a DMARC issue (though a usability one of unmet expectations
> rather than anything technical).
>

Then it's also an email issue generally, because it's probably not commonly
understood that there doesn't have to be a relationship between the display
name and the email address, or between either of those and any other
identifier on the message.

This is just another display name attack.  The only thing that's
breathtaking this time is that some MUAs have evidently chosen to say it's
a server problem.

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

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4926)

[Murray S. Kucherawy]

On Tue, Feb 7, 2017 at 10:25 AM, Barry Leiba 
wrote:

> >>Murray, Tony, or someone else: Can you independently check that these
> >>examples need the extra space in order to be verified correctly?
> >
> > Murray did that for us a decade ago -- it's one of the test cases that
> opendkim uses.
>
> Yes, but the point is: did Murray (or anyone) extract the text *from
> the published RFC* and use that as input?  That is apparently what
> Simon did, which resulted in this report.
>

It looks to me like this was some loss of precision in the transition from
RFC4871 to RFC6376.  The former has six spaces, and the latter has five.  I
very likely didn't change my test suite in between, or re-test the examples
in RFC6376 before it shipped.

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

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

[Murray S. Kucherawy]

Yes, later in the thread we all agreed that "don't do this" is far better
than any protocol solution.

On Mon, Nov 28, 2016, 11:30 Jim Fenton <fen...@bluepopcorn.net> wrote:

> 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 <sx6un-fc...@qmda.emu.st>
> 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
>
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Tue, Nov 22, 2016 at 7:45 AM, Michael Storz  wrote:


>
>> The negative side of the proposal is the requirement to split all
>>> multi-recipient-emails to single-recipient-emails, which is a show
>>> stopper for me.
>>>
>>
>> That's curious; why?
>>
>
> Because SMTP is defined as a multi-recipient transport. If this extension
> would require a mandatory split of every message, then this has to be
> discussed at IETF-SMTP because the semantics of SMTP are changed. It is a
> big difference if the implementation of a mta decides to split all messages
> on arrival or if some ISPs decide to send only singe-recipient emails, or
> if a protocol extension requires mandatory splitting.
>

As I understand it, the vast majority of mail you receive is very likely
single-recipient, and the vast majority of what you send is probably the
same.  Operationally this wouldn't change much.  On my personal machine,
the distribution looks like this so far today:

  23 nrcpts=0,
 319 nrcpts=1,
  17 nrcpts=2,

So forcing 100% of those messages to be single-recipient would add 17 more
messages, or just under 5% of today's flow so far.  I don't have immediate
access to data from a larger source.

SMTP is not "defined" as a multi-recipient transport.  It supports that as
an option but doesn't require it.  At best this proposal establishes a
required profile of its use, but doesn't change any protocol fundamentals.
MTAs would not have to be reimplemented, though the things that pass
messages to the MSA might.

If a sender splits all emails because of some local advantage the sender
> forces the receiver to waist a lot of ressources for nothing. Instead of
> one message going through anti-spam several messages must be processed. For
> example, we are runnig amavisd+spamassassin in pre-queue mode to be able to
> reject spam on arrival (legal reasons). Splitting means we have to provide
> more ressources for parallel connections and/or to limit the number of
> connections per ip address or network which results in delayed messages.


That's true, but it doesn't change the SMTP model directly.  And given the
fact that statistically the vast majority of your mail is already
single-recipient, the cost you're concerned about here will likely be
minimal.  Or do you have contrary data?

I don't buy this argument. I would assume that every program which
> manipulates an email will use a library for this.
>

I don't think that's a valid assumption.  OpenDKIM happens to have the one
you cited, but in a pure sense no DKIM implementation actually needs it.
In fact OpenDKIM doesn't even really need it anymore now that it no longer
supports ADSP.  I should actually drop it.


> How high is the probability that a new sender or recipient header field
> will be registered? And even if that's the case, that's not a big problem.
> The program would treat the addresses as BCCs until the administrator
> changes the config to use the additional field or an update of the program
> would incorporate this field.
>

Betting on who will do what in the future hasn't served us well in the
past.  Either way, I'm talking about the standards here.  RFC6376 did a
more hand-wavy job of listing, for example, which header fields to sign
than RFC4871 did, because we can't predict what sorts of header fields
might be registered later.  Instead, we talked about the general theory of
what should be signed versus which specific fields are in and which are out.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz  wrote:

> Normal DKIM-Signatures give us a way to check if the body and/or header of
> an email has been changed on the way from the signer to the verifier. The
> new extension extends this to the recipients of the email. A change means
> the email was either relayed (now indirect mail) or replayed. I think this
> is a new valuable information for an anti-spam-system. However, we have not
> discussed how this gets propagated from the verifier to the consumer of the
> information.
>

That's certainly possible to do if it's useful.  The pseudo-API described
by RFC6376 is vague; it just says the signature has to fail.  Whatever
reporting mechanism you want to provide in an actual implementation is fine
as long as it complies just to that.  A specific error code, or sub-code (a
la enhanced status codes) is certainly a valid choice.  OpenDKIM has a
large number of them.


> The negative side of the proposal is the requirement to split all
> multi-recipient-emails to single-recipient-emails, which is a show stopper
> for me.


That's curious; why?


> But I don't think this requirement is needed. I would allow a list of
> recipients and have a paragraph which states:


> ===
> Every compliant implementation of this extension MUST check if the signing
> of the message as is would result in the leakage of hidden BCC recipients.
> The check has to be done in the following way:
>
> - Collect the set of visible recipients from the header fields
>
>   * From
>   * Sender
>   * Reply-To
>   * To
>   * CC
>   * Resent-From
>   * Resent-Sender
>   * Resent-To
>   * Resent-CC
>
> - For each address from the set of envelope recipients check if the
> address is included in the set of visible recipients.
>
>   If not, then either
>
>   * refuse to sign with this extension or
>   * split the message and sign and send a single-recipient-copy of the
> message with this recipient
>

We discussed the idea of tying it directly to To and Cc.  The downside of
doing so is that participating DKIM implementations would have to know the
syntax and semantics of RFC5322 header fields; right now it needs only very
basic syntax information about them, just enough to run canonicalization.
It adds a whole lot of code complexity we'd rather avoid.  On top of that,
if someone were to later register some other sender or recipient header
field that should be included in this list, we'd have to update everything
on the DKIM side by updating this list.

Simplicity is very desirable here, as is reaching across the layer boundary
as little as possible.

===
>
> If the submission MTA already enforces the handling of bcc recipients as
> described in https://tools.ietf.org/search/rfc5322#section-3.6.3 the
> signing can always be done.
>

This sort of thing might work if you also specify the way both ends will
process this symmetrically.  Any ambiguity will result in interoperability
problems.


> Depending on an underlying policy from the administrator the "refuse to
> sign with this extension" could mean
>
> - to sign without the extension
> - wave the message through without signing
> - to reject the message with an error like "Configuration error: DKIM
> signing this message would leak BCC recipients"
>

These are purely implementation policy choices.  At best a specification
like this one would lay them out as options in a non-normative way.


> This check and the resulting split action is RFC 5322 compliant. However
> it would need to use the second variant of the bcc handling with the
> single-bcc-recipient-email.
>
> In this multi-recipient scenario the hashing of the recipient makes sense.
> It protects against passive attacks (just looking at the header) but not
> against active attacks.
>
> How about this?


It's worth considering further if we were to become convinced that this is
a problem that needs to be solved in the form of changes to DKIM.  Right
now I think we should wait for operators to explain why going down any of
these paths is the best option.  My main worry is that it seems to invite a
lot of complexity in code and either solution would introduce a lot of
complexity into the problem space, possibly more than they really would
solve.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz  wrote:

>
> Thanks, I see. That means the recipient is bound to the message and an
> attacker cannot delete or change the new tags. Great solution, I like it,
> though I do not like the consequences when this extension will go into
> production.
>
>
You may not need to worry about that.  We've reached a point where I think
we can legitimately say, "We took a serious look, and this is the best we
could come up with.  It has some pretty ugly side effects.  Are you sure
you can't just stop signing spam?"  And absent a compelling answer to that
question, there's no need to roll this out even as an experiment.

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

Re: [ietf-dkim] Intended status (was: Re: [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts)

[Murray S. Kucherawy]

On Fri, Nov 18, 2016 at 1:11 AM, Rolf E. Sonneveld <
r.e.sonnev...@sonnection.nl> wrote:

> Hi, Murray,
>
> On 16-11-16 02:45, Murray S. Kucherawy wrote:
>
>> There's been a lot of great feedback here.  I just cranked out an update
>> based on the discussion so far:
>>
>> https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01
>>
>> I forgot to update the title of Section 3, but other than that I think I
>> captured what's been discussed.  Please let me know what I've missed.
>>
>
> the intended status field is empty, but do you have some intended status
> in mind or not yet?


All of the versions I can see at
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ show
"Standards Track" as the Intended Status field, meaning it would get
"Proposed Standard" on publication.  I think if we get more than one
operator interested in trying this, then that's the right thing.  If we get
no commitment, "Experimental" is fine, if we go ahead with it at all.

If you're talking about the "Intended RFC Status" in the datatracker, which
still says "(None)", that's not set by the document author; it's set by the
working group chair, sponsoring Area Director, or Independent Submission
editor once it formally enters one of the two possible processing streams.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Thu, Nov 17, 2016 at 7:28 PM, Alessandro Vesely  wrote:

>
> Yes.
>>
>
> Well, if its title were *Incompatibility with Current Infrastructure*, I
> would agree there is a statement on the risk of disrupting how DKIM works.
>

That section talks about some things that are compatible (ignored tags are
harmless, for example) and some that are not.


>
>
>> I wouldn't say a salted hash qualifies as "racking my brains".  The idea
>> is
>> to make it difficult to see who the envelope recipient is simply by
>> looking.  A one-way transformation forces an interloper to make guesses
>> and
>> try to confirm, and the salt guarantees that your email address does not
>> always hash to the same thing.  It's not perfect security by any means,
>> but
>> it's a cheap way to limit what gets leaked.  This too is spelled out in
>> Section 7.
>>
>
> "To make guesses" is not the specified implementation.  Section 4.2 says
> envelop recipient must match exactly.
>

I'm completely confused about the flow of the conversation here.  The
guessing has to be done by an attacker, not by the true verifier.  See
below.


> This requirement not only forces single-recipient mode, but also rules out
> verifiers which run after acceptance or after alias expansion.  An
> incredibly narrow scope, overall.
>

Correct.  The -00 version of the document had better text about it that got
lost somehow.  I'll put it or something equivalent back in a future version.


> If instead you really allow some guessing, as mentioned in Section 7, you
> may rehabilitate a range of verifiers, but undoubtedly do so at the cost of
> full scale brains racking.


A verifier doesn't have to guess.  It has a recipient in hand that either
passes the test or does not.

To illustrate: The value of "rh" is base64(rs + rcpt) and the proposal
asserts that both the signer and the verifier have to arrive at the same
value.  The actual signer and verifier have "rs" and "rcpt", the two
inputs, so they get the same result for "rh"; there is no guessing.  An
attacker, however, has an "rh" and "rs" value, but no "rcpt".  It has to
guess.  The weakness is that the mechanism allows for such guesses to be
confirmed when they're right, and it's often the case that there's
information available to narrow the scope of such guessing.  But I think
the document already discusses that.


>
> If you hand me a printed copy of a message without the envelope, and the
>> Received didn't use the (non-standard) "for" clause, I cannot be certain
>> it
>> was delivered to whatever the To and Cc say, if they're even present.
>>
>
> I don't think I'm with you.  You seem to mean you don't know if, say,
> Terry actually received a copy of this.


Correct, I don't.  In fact, given a printed copy of this message, I don't
know who actually received it, as I no longer have the envelope.  The To
and Cc don't have to have any relationship with the delivery envelope at
all.


> For example, one might arrange social engineering by adding CC:'s to your
> boss, the press, the police, et cetera, none of which corresponds to the
> envelope.  Is that concern part of the problem at hand?
>

I wouldn't call it a concern, but yes, it explains this aspect of the
proposal.


>
> It may have gone only to an envelope recipient that isn't visible.  That
>> is, if there was a Bcc, it's not revealed to me.  If you insist on using
>> "for" or "Disclosed-Bcc", that information is guaranteed to be exposed,
>> and
>> I can see who that secret recipient was.
>>
>
> Invisible recipients may come from BCCs or other sources.  When you get
> the message, you may want to know why it was delivered to you, and, yes,
> "for" or "Disclosed-Bcc" let you know that.  Why should that info be kept
> secret?
>

Exactly for the reason I gave: If you force a Bcc to be visible by sticking
it in a header field, and then print it, the "B" in "Bcc" is gone; the
secret recipient is fully revealed.  I don't know why that would be
desirable.


>
> By contrast, including these tags at most reveals to me that there was a
>> Bcc, but I have to do some complex (though these days, cheap) math to
>> guess
>> whether a specific address was in there.  If I never make the correct
>> guess, the secret is never revealed.
>>
>
> I fail to see why that would be an advantage:
>
> The address is likely shorter than its hash.
>

Your logic is puzzling here.  I don't know about you, but I'm willing to
trade a few bytes to retain privacy.


> In general, it would be nice to have a standard means to tell recipients
> on what grounds a message was delivered to their mailboxes.  For example,
> was it a role address or a personal one?  If the message body is ambiguous
> (e.g. short messages) knowing the original recipient address may help.
>

That seems to be a goal wholly outside of the scope of this proposal.


> In the scenario you are proposing, only mailbox providers know the
> envelope, and can verify if that was what the sending domain signed.

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Thu, Nov 17, 2016 at 3:09 AM, Terry Zink 
wrote:

> > This means ARC will be needed not only for mailing lists which modify
> the header or
> > body of an email, but for EVERY mailing list and EVERY forwarded email
> or EVERYTIME
> > the recipient has been modified and the email leaves the ADMD boundary.
> From a
> > DMARC point of view DKIM will not be needed anymore because it has now
> the same
> > function as SPF - verifiying the origin of direct emails - and SPF is
> easier to implement
> > for most administrators.
>
> +1.
>
> It basically (almost) turns DKIM into SPF. That's not that appealing a
> solution.


Yep, it does.  And as we've already said on this thread, "Don't do that"
(i.e., don't sign spam in the first place) is far and away the preferred
solution, but it does happen resulting in increased reputation-enhanced
spam delivery to inboxes.  So we have a choice now between not doing
something like this which enables the attack described in the document to
continue, or doing something like this and making DMARC have to go through
some kind of unpleasant permutation.

It's funny you should mention ARC, because this was first raised on the
mailing list where ARC is developed, and then discussed further at MAAWG
this fall, and then brought to us to brainstorm on a solution.  So far,
this is where we've landed as being the least damaging thing to do when
"don't sign spam in the first place" is rejected as a solution.

Maybe we should take this back to the MAAWG technical discussions list.
I'll do that later today.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely  wrote:

>
> That way it will stay dormant until someone gets hurt and has to activate
>>> it, at which time it may cause more damage than improvement.  A loose
>>> cannon.
>>>
>>
>> The document makes that risk clear, or so I thought.
>>
>
> You mean Section 5?
>

Yes.


>
> Finally, if you stick to one recipient per message, why do you rack your
>>> brains about encryption?  I suggest adding a Disclosed-BCC: header field
>>> with the recipient address in the same 5322.address-list cleartext format
>>> as the other address fields, and sign it FWIW.  It won't break more
>>> privacy
>>> than Delivered-To: does.
>>>
>>
>> I don't follow.  There's no additional encryption going on here.
>>
>
> I mean the SHA transformation.  Cleartext is obviously easier to
> understand and debug.


I wouldn't say a salted hash qualifies as "racking my brains".  The idea is
to make it difficult to see who the envelope recipient is simply by
looking.  A one-way transformation forces an interloper to make guesses and
try to confirm, and the salt guarantees that your email address does not
always hash to the same thing.  It's not perfect security by any means, but
it's a cheap way to limit what gets leaked.  This too is spelled out in
Section 7.


>
> Adding a "Disclosed-BCC" field guarantees disclosure, rather than only
>> disclosing if the MDA adds a Delivered-To.  I don't think we should make
>> that worse.
>>
>
> So long as you disclose it to the very recipient, there is no worry.  NDNs
> customarily report SMTP chit-chat in cleartext, betraying users who attempt
> to hide their real address behind a dot-forward.  Log files are plenty of
> envelope citations.  Received: fields feature a FOR clause which is not
> deprecated for single recipient messages.  We're not worsening anything.
>

If you hand me a printed copy of a message without the envelope, and the
Received didn't use the (non-standard) "for" clause, I cannot be certain it
was delivered to whatever the To and Cc say, if they're even present.  It
may have gone only to an envelope recipient that isn't visible.  That is,
if there was a Bcc, it's not revealed to me.  If you insist on using "for"
or "Disclosed-Bcc", that information is guaranteed to be exposed, and I can
see who that secret recipient was.

By contrast, including these tags at most reveals to me that there was a
Bcc, but I have to do some complex (though these days, cheap) math to guess
whether a specific address was in there.  If I never make the correct
guess, the secret is never revealed.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 11:50 PM, Michael Storz 
wrote:

>
> Ok, I see you have removed the hashing of the recipient together with the
> email itself. But how do you prevent a replay attack, if the new tag is not
> bound to the email and signed with the DKIM-key (that's how I read 4.1.4)?
> The spammer could remove the tag or provide his own tag with the new
> recipient before resending the email.
>

The signature signs itself, so removing or changing the tag invalidates the
signature.  Have a look at RFC6376, Sections 3.5 and 5.1.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

(dropping DMARC again)

On Wed, Nov 16, 2016 at 9:51 PM, Michael Storz  wrote:

> Version 01 is purely incremental, meaning you can just ignore the new
>> tags if you're more worried about breakage of forwarding than the
>> attack it's trying to address.
>>
>
> Optional for the sender, yes, but not for the receiving MTA. If the sender
> decides to use the new Anti-Replay-DKIM-Signature and has published a DMARC
> policy with reject or quarantine, then this policy is implicitly extended
> with


> "ooh, and btw reject/quarantine ALL indirect emails, even if a normal DKIM
> signature could be verified"
>

That's not correct.  The verifying MTA, if it doesn't know the new tags, is
unaffected by the new tags because RFC6376 directs the verifier to ignore
them.  It's as if they weren't there.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely  wrote:

> That way it will stay dormant until someone gets hurt and has to activate
> it, at which time it may cause more damage than improvement.  A loose
> cannon.  I'd keep it in its own header field [Ned's (1)(a)], so as to avoid
> the risk Rolf points out.
>

The document makes that risk clear, or so I thought.  I'd be happy to get
proposals for stronger language if needed.

Why does it need its own header field?  It's harmless expressed as tags in
the existing header field since they're ignored by verifiers that don't
know the new tags.


> Besides forwarding, use of this method worsens mailing lists breakage
> further, which makes it totally out of scope for dmarc-ietf.  At this
> point, I follow Dave's directive and remove that Cc:.
>

Yes, I agree.


> Finally, if you stick to one recipient per message, why do you rack your
> brains about encryption?  I suggest adding a Disclosed-BCC: header field
> with the recipient address in the same 5322.address-list cleartext format
> as the other address fields, and sign it FWIW.  It won't break more privacy
> than Delivered-To: does.
>

I don't follow.  There's no additional encryption going on here.

Adding a "Disclosed-BCC" field guarantees disclosure, rather than only
disclosing if the MDA adds a Delivered-To.  I don't think we should make
that worse.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 1:05 PM, John R Levine  wrote:

>
> So far this exercise has mostly served to persuade me that putting
> envelope info in the DKIM signature is a bad idea, and our advice to people
> who have problems with recipients remailing spam they've signed remains
> "don't do that."
>
>
I agree, and I'm certainly fine with saying that more forcefully than the
text that's currently there.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink 
wrote:

> Large email receivers forward tons of email. This proposal causes email
> from DMARC-passing messages to be incapable of forwarding. As a large email
> receiver who gets tons of complaints about breakage of DKIM signatures on
> forwarded messages which causes DMARC failures [1], this proposal is not
> all that appealing.
>

Version 01 is purely incremental, meaning you can just ignore the new tags
if you're more worried about breakage of forwarding than the attack it's
trying to address.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 10:56 AM, John R Levine  wrote:

> https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01
>>
>> I forgot to update the title of Section 3, but other than that I think I
>> captured what's been discussed.  Please let me know what I've missed.
>>
>
> How come rh= has one hash instead of several?  You can put all the
> addresses in the To: and Cc: headers in one header without leaking, then do
> separate single hash if there are bcc's.


I found Ned's comments about signing only individual recipients convincing,
so that's the direction I took in this revision.  It's hardly final; by all
means, let's hash it out.

So you want to pack all the envelope recipients into, say, a
colon-separated list in "rh=", and then just confirm each envelope
recipient is represented in that list?

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

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

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 5:11 AM, Michael Thomas  wrote:

> So, when the filters catch up, it will then mark it as spam again
> regardless of the DKIM signature.
>
> So what exactly is the problem here?
>

I suppose when the filters catch up, the spammer can no longer get
$HIGH_REPUTATION_MAIL_SERVER to sign that message until the next hole is
discovered.  But everything submitted and replayed prior to that has
already gone out and been delivered on the basis of that reputation.

That's the problem here.

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

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

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten  wrote:

> My understanding is an attack where the email is sent to an outside
> address owned by the sender, who then gets a copy of the email, signed
> by the provider who didn't think the email was bad.
>
> Signing an email that you know is bad does indeed sound like a bad
> idea.


There's always some time window between a spammer discovering a new
technique that gets past filters and those filters learning about the new
attack via whatever ML is in use.  That might be when this attack is most
effective.  You can't label as spam that which you don't identify as spam.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin <dubro...@corp.mail.ru>
wrote:

> 15.11.2016 2:07, Murray S. Kucherawy пишет:
>
> On Mon, Nov 14, 2016 at 10:36 PM, <ned+dm...@mrochek.com> wrote:
>
>> Let's break this down. If we're going to include recipients in the DKIM
>> signature, it seems we have at least three key design decisions to make:
>> [...]
>>
>
> That's a pretty excellent summary.  A couple of points:
>
> I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being
> the ideal choices.  Is that correct?  If so, we would just need to
> determine the algorithm for generating the signed content that would be
> included in the augmented signature.  If we do something like the random
> salt suggestion, is this sufficient?
>
> - pick a random string S of length L using only printable ASCII characters
> (I like 8 for L but that's arbitrary)
> - SHA the string produced by prepending S to the recipient address, and
> express the result in base64 string R
> - include R in a new "er" (envelope recipient) tag and the salt S in an
> "rs" (recipient salt) tag
>
> This is not reversible so nothing is leaked, but as we've all conceded by
> now it's not hard to attack this to recover the hashed address especially
> since one might have good guesses as to what that address would be.
>
> I can't see the point of actually encrypting the hashed content, because
> anybody can decrypt it with the public key.
>
> What am I missing?
>
>
> There is no need to reverse if you know e-mail address. Alice can check
> Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail and
> check if he is in 'er'.
>

Yes.  I wasn't identifying "not reversible" as a shortcoming, but rather as
a benefit.

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Mon, Nov 14, 2016 at 10:36 PM,  wrote:

> Let's break this down. If we're going to include recipients in the DKIM
> signature, it seems we have at least three key design decisions to make:
> [...]
>

That's a pretty excellent summary.  A couple of points:

I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being
the ideal choices.  Is that correct?  If so, we would just need to
determine the algorithm for generating the signed content that would be
included in the augmented signature.  If we do something like the random
salt suggestion, is this sufficient?

- pick a random string S of length L using only printable ASCII characters
(I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and
express the result in base64 string R
- include R in a new "er" (envelope recipient) tag and the salt S in an
"rs" (recipient salt) tag

This is not reversible so nothing is leaked, but as we've all conceded by
now it's not hard to attack this to recover the hashed address especially
since one might have good guesses as to what that address would be.

I can't see the point of actually encrypting the hashed content, because
anybody can decrypt it with the public key.

What am I missing?

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

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

Hi Rolf,

On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld <
r.e.sonnev...@sonnection.nl> wrote:

> At the time SenderID was proposed, back in 2004 or something, the act of
> propagating header information into the transport stream was seen by many
> as a layering violation. The proposal of Murray and Johns suggested kludge
> alternative do the reverse: propagating envelope information to the header.
> In my view this is, again, a layering violation. The downside of crossing
> layer borders is that transport and header information are (too) tightly
> coupled, which makes that the flexibility of the original mail design
> (RFC821/RFC822)  is lost.
>

There's obviously some truth to this, but there's also truth to the fact
that humans, the ones this community seeks to serve, routinely cross layers
in both directions whether or not we do so in protocols.  End user
education has never been a viable answer to protocol limitations as far as
I'm aware, much as we all wish it were so.

I'm willing to hold my nose -- a little -- at a reach across a layer
boundary if there's potentially a large win.  Whether this proposal or some
variant of it qualifies is why I brought the question to this group.

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

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

[Murray S. Kucherawy]

On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed  wrote:

> > Actually same message to same destination may be
> > sent to different MTAs (e.g. different MXs with same weight).
> > 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> > lowercase the domain of recipient.
>
> Our default is to leave the case of addresses alone by default, but sites
> often
> do configure things to "right case" their business name. That said, Early
> validation would avoid such issues for us. I think.
>

Long ago some MTAs use to mess with the case of the domain names in the
envelope.  Assuming some of them are still out there, wouldn't we want to
fold everything to lowercase (or uppercase; pick one) before doing the sort?

> All problems except 2.1 may be fixed by adding additional header, like
> e.g.
> > DKIM-Transport-recipients
> > which contains salted hashes (with some random salt) of all recipient
> > addresses, and require this header to be added to DKIM signature and
> > existence for every recipient's address' hash to be checked in this
> > header. It is compatible with any current DKIM implementation.
>
> If you're talking about hashing all recipients together, then I don't see
> this
> solving all the problems except 2.1.
>
> And if you're talking about hashing them separately, then why would you
> insist that they all be present?
>

I think he's trying to avoid being clobbered by an envelope that gets split
downstream.  If you as a verifier have the full original recipient set,
then all you care about is that your recipient set is a subset of the
original set.


> But limiting the number of recipients to 1 when this extension is used
> would be
> a much simpler approach. Of course there's some overhead involved in doing
> this, but given the idiotically limited spam report mechanisms in place at
> some
> sites single copy may be a requirement already.
>

It's also the most common use case in threat space, as I understand it.


> Finally, my biggest concern here is that this, like most proposals that
> involve complex linkages between the header and envelope, is complex
> and loaded with pitfalls. (Just look at these two messages...) And at least
> some of this spills over to both implementations and operational policy.
>

Indeed; I don't think that's avoidable if we want to try to tackle this
problem versus punting it back up to layers 8 and 9.  But maybe that's the
best thing one can do.

Can we really expect people to get this right?
>

I wonder that every time I write a draft anymore.  :-)

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

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

[Murray S. Kucherawy]

On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin 
wrote:

> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form it
> can not be implemented in most MTAs (see below)
> 2. This standard mixes transport standards (SMTP) and message standard.
> There are multiple issues as a result of this:
> 2.1 Same message may have multiple recipients on different MTAs while each
> MTA only sees it's own recipients. So, destination MTA can not verify
> signature, because it doesn't know all recipients. This can be fixed if
> message to every destination is  signed independently, but it breaks
> existing mail flows, because in most cases message is signed before placing
> to MTA queue.
> 2.2 Recieving MTA may e.g. limit the number of recipients and single
> message may be sent to different final recipients on the same MTA in
> multiple session as few different messages, each message with partial list
> of recipients. Actually same message to same destination may be sent to
> different MTAs (e.g. different MXs with same weight).
>

Yes the current text in the document already calls all of those issues out.


> 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> lowercase the domain of recipient.
>

That's a good point.


> All problems except 2.1 may be fixed by adding additional header, like e.g.
> DKIM-Transport-recipients
> which contains salted hashes (with some random salt) of all recipient
> addresses, and require this header to be added to DKIM signature and
> existence for every recipient's address' hash to be checked in this header.
> It is compatible with any current DKIM implementation.
>
2.1 can also be solved in this case, but it disclosures BCCs of the message
> (even if this header is removed before delivery to mailbox)
>

Also an interesting idea.


> All problems may be solved by using asymmetric encryption instead of
> hashing, e.g. require domains with support for this standard to publish
> some public key (or to use special DKIM selector) via DNS record and
> encrypt recipient's addresses in the additional header with public key and
> only sign recipients for systems with this key published.
>

If you do asymmetric encryption, with or without a distinct selector,
aren't you basically doing the same thing I'm proposing, other than where
it gets recorded in the message?

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

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

[Murray S. Kucherawy]

On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman 
wrote:

> Wouldn't a DMARC option to allow senders to specify only messages that
> pass verification and alignment for BOTH SPF and DMARC accomplish the same
> result with less complexity and without the layering violation inherent in
> this proposal?
>

Doesn't that presuppose point-to-point handling?  The proposal here doesn't.


> DMARC seems to be the policy engine of choice in the community (for better
> or for worse).  I think addressing this at the policy level makes more
> sense than changing the semantics of DKIM signatures after almost a decade
> of deployment.
>

As the problem was presented to me, I haven't heard that DMARC is
specifically involved here.  It might be (maybe even "probably" is apt),
but I haven't heard that, so I limited this idea to just the DKIM signing
and verifying components of the system.


> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately
> convinced I'd want to enable this feature.  I don't know if other distro
> maintainers are on this list or not, but that's one opinion.  It's not
> guaranteed to be widely deployed.
>

Why is this a distribution issue?

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

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

[Murray S. Kucherawy]

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 some sort of quarantine system which only looks at
> verification status.
>

Sort of, yeah.  It's any receiver that gives preferential treatment to
messages signed by particular domains.


> It's too bad formal communication to the MUA was eliminated in
> DKIM. The original hope was that after a decade or so, MUAs would have
> evolved to participate and make some rendering indication in such
> situations. After all, an unknown-to-the-MUA to:/cc: recipient or
> domain in a verified email is highly actionable.
>

Which channel was eliminated?  I think RFC7601 could help if that's what
you're referring to.


> Anyway, based on your draft I presume the desire is still to retain
> the binary verification status as a strong dispositional attribute
> that is handled by anything *but* the MUA?
>

Right, that seems to be the attack that needs addressing.


> In the section that discusses the impact on forwarded and list email
> you might want to highlight that the proposal could further reduce
> email to a point-to-point protocol. In which case an alternative
> long-term strategy might be simply to insist on strong SPF checks
> rather than signatures. Or do SPF checks not help the scenario you're
> addressing here?
>

SPF might indeed help for cases where there are no intermediate hops.

Both good suggestions.  Thanks!

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

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

[Murray S. Kucherawy]

I've posted a draft that attempts to address an attack that's begun to
appear with DKIM.  Interestingly, we called it out as a possible attack in
RFC6376 and even RFC4871, but now it's apparently happening and being
annoying enough that people (I believe from the MAAWG community) are asking
if there's a protocol solution that's possible.

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/

Comments welcome.

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

Re: [ietf-dkim] DKIM and EAI

[Murray S. Kucherawy]

On Tue, Sep 27, 2016 at 8:15 PM, Jiankang Yao  wrote:

> Since EAI deployment is on the way, gmail, outlok2016, postfix, yandex,
> xgenplus and many more have adopted EAI.
> In order to make EAI environment more friendly,  I suggest that this WG
> considers to move this document/work forward.
>

Which working group?  DKIM hasn't existed in years.  We'd have to spin up
another one.

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

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4810)

[Murray S. Kucherawy]

That looks correct to me.  Barry or Dave?

On Mon, Sep 26, 2016 at 2:55 PM, Stephen Farrell 
wrote:

>
> If someone familiar with the dkim abnf could comment I'd be
> happy to approve/reject this as appropriate.
>
> S
>
> On 26/09/16 20:15, RFC Errata System wrote:
> > The following errata report has been submitted for RFC6376,
> > "DomainKeys Identified Mail (DKIM) Signatures".
> >
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=6376=4810
> >
> > --
> > Type: Technical
> > Reported by: Juan Altmayer Pizzorno 
> >
> > Section: 3.5
> >
> > Original Text
> > -
> > x-sig-q-tag-args = qp-hdr-value
> >
> > Corrected Text
> > --
> > x-sig-q-tag-args = dkim-quoted-printable  ; with ":" encoded
> >
> > Notes
> > -
> > sig-q-tag-methods are ":"-separated in sig-q-tag, so ":" shouldn't be
> permitted
> > within x-sig-q-tag-args.  Note that qp-hdr-value (which I believe was
> originally
> > defined for sig-z-tag, which includes "|"-separated values) is defined as
> >
> >qp-hdr-value=  dkim-quoted-printable; with "|" encoded
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC6376 (draft-ietf-dkim-rfc4871bis-15)
> > --
> > Title   : DomainKeys Identified Mail (DKIM) Signatures
> > Publication Date: September 2011
> > Author(s)   : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
> > Category: DRAFT STANDARD
> > Source  : Domain Keys Identified Mail
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> >
> >
>
>
> ___
> 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 Key Size Constraints

[Murray S. Kucherawy]

On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten 
martijn.groo...@virusbtn.com wrote:

  Why remove 512 support from the verification side?  Does this mean the
  verifier will take valid 512 signature and make it invalid, no signature
  message?  Is there a correlation out there that 512 bits signers are more
  prune to be Bad Guys? Spammers?

 The problem here is that 512-bit keys can be trivially broken: it takes
 less than 8 hours and about 100 USD to do so[1]. So there is no way to be
 certain that the signer of the message is the same organisation that
 published the (512-bit) DKIM key, even if that organisation only were to
 send email that everyone would want to receive.

 You are right to point out that the RFC says that [t]he security goals of
 this specification are modest, which indeed they are, but I think 100 USD
 is well within the means of the kind of adversary DKIM is trying to protect
 against. The story of Google's 512-bit key that Scott already pointed to[2]
 gives at least some anecdotal evidence about why this matters in practice.


Is it appropriate to change the protocol document for this?  Isn't it
really more of a BCP?

The size of the key doesn't affect interoperability, but rather the
receiver's choice to accept the signature as valid when it's based on a
weak key.

I'm not arguing that it's a bad idea to discourage this practice, but
rather ruminating about whether this is the right way to do it.

Then again, RFC6376 doesn't expressly say that keys smaller than 512 have
to be accepted either.  Hmmm.

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

Re: [ietf-dkim] DKIM Key Size Constraints

[Murray S. Kucherawy]

On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman ietf-d...@kitterman.com
wrote:

  Is it appropriate to change the protocol document for this?  Isn't it
  really more of a BCP?

 I think when key size got put in the protocol, then it's a protocol update
 to
 change it.


Is it part of the protocol, or is it part of the prose around the protocol?

The DKIM algorithms don't break if you use weak keys any more than they
break if you put false information in a header field.  More generally, I
don't believe DKIM itself cares about the size of the key.  All of our
advice absolutely does, and rightly so.

Do we have any other crypto-related protocols where the protocol itself
legislates the appropriate key parameters for the encoding, decoding,
signing or verifying?  Section 6 of RFC3207 (STARTTLS) explains explicitly
that it's a local matter and out of scope, for example.  I scanned
RFC4033-4035 (DNSSEC) and didn't see any restrictions or advice about key
size selection at all.  I always go cross-eyed when I try to read the TLS
RFCs so I'll stop there for now.  ;-)

 The size of the key doesn't affect interoperability, but rather the
  receiver's choice to accept the signature as valid when it's based on a
  weak key.

 To me that's equivalent to saying choice of crypto algorithm doesn't affect
 interoperability since it only affects the receivers choice to accept the
 signature as valid.


There's also nothing wrong with a receiver deciding it doesn't like
signatures that use relaxed canonicalization, SHA1, or decline to sign the
Subject header field.  The algorithm itself worked fine -- that's
interoperability -- but the receiver doesn't like one of the parameters the
signer used and thereby makes a local policy decision.

You have to set a floor below which it's not reasonable to accept
 signatures as
 valid.  Since receivers have no way to vet sender's key rotation policies,
 taking an out like RFC 6376 and its predecessors do and say that keys
 smaller
 that 1024 bits are OK for keys that aren't long lived is not tenable.  That
 and since DKIM was first deployed, at least for 512 bit keys, the not long
 lived required to meet even the modest security goals of DKIM are
 substantially shorter than the amount of time typically needed to ensure
 that
 mail deliveries are completed (some fraction of a day at longest).

 Key lengths less than 1024 need to be killed dead.


I don't argue with any of that, except to say again that I'm not convinced
DKIM, the protocol, has to suddenly break for small keys.  I absolutely
agree with a BCP statement of some kind, and I also agree in retrospect
that the not-long-lived key advice in RFC6376 is probably not helpful.
(You could in theory observe the timestamp of when you first saw a key and
then watch how long it gets used, but that puts an unreasonable burden on
receivers.)

Do we also want to issue a BCP more generally that tries to compel all
implementations of TLS or anything doing signatures to flatly decline to
operate if someone tries to use a sub-1024-bit key size?

BTW (for reference), I'm prompted to do the work to make this change by a
 recent change in opendkim [1] that removed the ability to mark messages
 with
 small keys as DKIM fail.


The change I think you're talking about (you didn't include a reference
URL; I think it's https://sourceforge.net/p/opendkim/bugs/221/) appears to
agree with what I'm saying above.  When talking about unacceptably small
keys, the unacceptable decision is not made by the protocol, but by the
receiver.  DKIM didn't fail, so it shouldn't be treated as a DKIM failure.
Accordingly, OpenDKIM now reports those as failures for policy reasons
rather than failures for protocol reasons.

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

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

[Murray S. Kucherawy]

On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas m...@mtcc.com wrote:

 The list of things DMARC does that ADSP doesn't in its appendix, is a trip
 down memory lane
 of constraints that were placed on it by the
 against-it-before-they-were-for it set. True
 SPF wasn't ever on its radar -- SPF has its own policy language, so nobody
 wanted to touch
 that. And ARF was progressing at the time as it's own spec, so we weren't
 completely clueless
 about its need. But instead of actually working to make a better spec at
 the time, we had an
 author whose goal was to subvert it, and endless idiotic flamewars about
 what the actual name
 of the draft should be as the main priorities. The really sad thing about
 this is that they pissed
 away 6+ years due to the intrigue.


I'm lost.  What's the purpose of this branch of the original thread, other
than venting old frustration and lobbing invective?

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

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

[Murray S. Kucherawy]

I also agree with this proposal.  I don't have much to add over the text in
the formal request; it lays out the case based on my experience
implementing DKIM and ADSP in open source.  I can also say that I have
never encountered an operation that actively uses it, including current and
previous employers.

-MSK


On Wed, Sep 11, 2013 at 5:46 PM, Terry Zink tz...@exchange.microsoft.comwrote:

 I agree with this proposal.

 -- Terry

 -Original Message-
 From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org]
 On Behalf Of Dave Crocker
 Sent: Wednesday, September 11, 2013 4:52 PM
 To: DKIM IETF WG; Apps Discuss
 Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

 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 dcroc...@bbiw.net
 Organization: Brandenburg InternetWorking
 To: Barry Leiba barryle...@computer.org,  Pete Resnick 
 resn...@episteme-software.com

 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/

 --
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net
 ___
 apps-discuss mailing list
 apps-disc...@ietf.org
 https://www.ietf.org/mailman/listinfo/apps-discuss
 ___
 apps-discuss mailing list
 apps-disc...@ietf.org
 https://www.ietf.org/mailman/listinfo/apps-discuss

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

Re: [ietf-dkim] IPR Disclosure: ENTERKHAN CO., LTD's Statement about IPR related to RFC 6376, draft-allman-dkim-base-01, and Creative Commons

[Murray S. Kucherawy]

On Thu, Aug 15, 2013 at 8:46 AM, Stephen Farrell
stephen.farr...@cs.tcd.iewrote:


 That looks weird. Do we know its not spam?
 S


First I've heard of it.

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

Re: [ietf-dkim] Seeking Clarification of the l= Tag

[Murray S. Kucherawy]

On Sun, Aug 4, 2013 at 1:35 PM, Pawel Lesnikowski
lesnikow...@limilabs.comwrote:

 There are few details I'd like to clarify.

 Body hash for this message is correctly computed by the sender.
 Entire signature of this message in fact valid - this is why Port25,
 Gmail, and Mail.dll validate DKIM signature with 'pass' result.

 The only problem is the value of l= parameter of DKIM-Signature header
 (l=2).
 The value is greater than total number of bytes after body
 canonicalization (0 bytes).
 This is easy to spot and all parsers simply ignore incorrect l= value.
 Hash is computed for entire canonicalized body (of length 0).

 Now the question is should the validation fail or pass in such case?


It's an error.  The RFC says this pretty clearly:

  This value MUST NOT be
  larger than the actual number of octets in the canonicalized
  message body.


You're probably right that most (if not all) parsers simply interpret l=2
as don't feed more than 2 bytes to the hash, but the fewer case gets
silently ignored.  They are wrong.

I'll make sure OpenDKIM has this right and fix it in the next release if
not.

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

Re: [ietf-dkim] Seeking Clarification of the l= Tag

[Murray S. Kucherawy]

If the message is totally empty or consists only of CRLF sequences, or not
even that, then the l= value should be zero since they would all be
ignored and not fed to the hash; the total number of bytes fed to the hash
would be zero.  I suggest reaching out to Gmail to find out what's going on.

-MSK


On Sat, Aug 3, 2013 at 5:53 AM, henry+d...@unlocktheinbox.com 
henry+d...@unlocktheinbox.com wrote:

 I received and email with a l=2 tag in the DKIM Signature and after body
 canonicalization put the length at zero, since the body was blank. I notice
 that some email processors fail this condition (smartermail) and other
 passes this condition (gmail, port25).

 According to the spec This value MUST NOT be larger than the actual
 number of octets in the canonicalized message body.

 To me that implies that it should PermFail, when this condition takes
 place. So why does gmail consider this valid? What are your thoughts?

 Henry Timmes
 www.UnlockTheInbox.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] That weird i= is most probably EDSP

[Murray S. Kucherawy]

On Sat, Aug 3, 2013 at 2:09 AM, Michael Deutschmann 
mich...@talamasca.ocis.net wrote:

 Your question about drafts has two possible implications.  The first is
 I'm not going to pay any attention to Michael until he takes up RFC
 lawyering. In which case I can't help you.


My problem is that absent a draft, you're lobbing a vague proposal over the
wall and hoping the community will do all of the work for you.  If your
idea is a workable solution, I think it's reasonable for people to be
convinced first that it's worth taking up the work.  Popular forms of
evidence are detailed specifications that can be analyzed and/or prototype
implementations.

As for your proposal, assuming I've understood it:

The idea of requiring a first-party signature relative to the MAIL FROM,
and using SPF to signal the requirement, runs into a couple of problems.
The most obvious of these is that it presumes the author is covered by SPF,
which is not universally true; the sending infrastructure may have chosen
not to publish SPF due to false positives.  That means this proposal is
only useful to a subset of the community.  That's a significant barrier.

The community reached consensus some time ago that the absence of a valid
first-party signature is not a reason in and of itself to distrust the
message, because there are legitimate reasons DKIM can fail, and legitimate
cases where a third party signs the message instead of the author domain.
The DKIM RFC does state this fairly clearly.  It's only the case where DKIM
passes that you have actually learned something useful about the message.

From a protocol design perspective, using one protocol to signal an option
in another almost orthogonal protocol is pretty weird.  Coming up with
standards-worthy signaling between the two, since SPF is almost always
upstream of DKIM in terms of MTA processing, would be an interesting
exercise.  Otherwise you're presuming a single component is doing both
tests, which is not commonly how it's done.

All that said, I invite you to spend some time building an implementation
and gathering statistics on its efficacy.  Such data speak pretty loudly.
There are plenty of APIs that would enable you to build something like this
and try it in short order.  If you decide to use libopendkim as part of the
experiment, I pledge to support it; if it looks like your solution is
useful, and the signalling question can be resolved, I'll add it to
OpenDKIM.

Another more general problem is that you appear to reject all of my mail
because Gmail generates HTML mail, so hopefully you check the archives of
this list once in a while.

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

Re: [ietf-dkim] The problem with the DKIM design community

[Murray S. Kucherawy]

On Sun, Jun 30, 2013 at 9:21 AM, John R. Levine jo...@iecc.com wrote:

 What I'm asking for is nothing like SES.  I want the signature to be
 based on the envelope MAIL FROM:, but it is still the body that gets
 signed.  No VERPing is called for. ...


 Where can we read the draft?


+1.  I pledge open source support if a workable draft appears.

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

Re: [ietf-dkim] The problem with the DKIM design community

[Murray S. Kucherawy]

On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann 
mich...@talamasca.ocis.net wrote:

 On Mon, 1 Jul 2013, Alessandro Vesely wrote:
  Well, not really.  MAIL FROM: is only visible after delivery, so to
  avoid dangling signatures one should store its value in some other
  header field or... in the i= tag.

 ITYM only visible *before* delivery


He means after.  There is no guarantee that the MAIL FROM address appears
anywhere in the signed content of the message; its addition to Received is
non-standard, and although RFC5321 says the addition of Return-Path at the
time of delivery is mandatory, there are some legacy systems that don't
insert it.  If the sender inserts it, it could be removed or replaced in
transit or upon delivery, invalidating the signature.

One could do what you're talking about by inventing a DKIM canonicalization
that includes the MAIL FROM address in one of the two hashes DKIM generates
to produce its signature.  That's easy enough.  I'd like to know what the
gain is, however.  As far as I can tell, by itself, that simply ensures the
same content re-injected anywhere will not produce a valid result unless
the MAIL FROM is unchanged.

It seems to me this renders your scheme even more sensitive to failures
than DKIM already is.  Specifically, a mailing list server that resends the
message byte-for-byte identical to the original and only changes the
envelope will cause the signature to be invalid, while DKIM will survive
such re-mailing.


 It does mean that if the mail passes through an SPF Sender Rewriting
 Scheme forwarder, then it will end up with an unbroken but irrelevant
 signature.  Even if that forwarder knows about EDSP, it can't strip the
 signature because it can't know that it isn't there to serve a different
 accessory protocol yet to be invented.  After all, most of the time MAIL
 FROM: = From:, so the signature added for the sake of EDSP will
 simultaneously be serving ADSP or DMARC.


There are legitimate cases where this is not true, such as mailing lists
(which was your original complaint about accessory protocols).



 But I don't think that's a problem.  The message will get through,
 because the forwarder now owns the MAIL FROM and it's up to him whether an
 EDSP check is needed.


The forwarder would have to be EDSP-aware and re-sign the message when
changing the envelope.  That makes a lot of assumptions about all the hosts
through which the message will pass.

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

Re: [ietf-dkim] The problem with the DKIM design community

[Murray S. Kucherawy]

On Sat, Jun 22, 2013 at 9:49 PM, Michael Deutschmann 
mich...@talamasca.ocis.net wrote:

 (I have deployed DKIM alone senderside, but that's just to keep in
 practice in case someone invents an accessory protocol that's actually
 sane.  Allowing me to declare that all mail bearing my RFC821 MAIL FROM:
 without a corresponding signature is bogus while saying nothing about
 that which merely bears my RFC822 From: would be a good start.)


If that's the magic you seek, I propose writing it up as an I-D and doing
some practical interoperability experiments, and see if it takes off.

It's easy to lob you should've done it this way grenades without actually
putting any energy behind it other than a critical missive here and there.

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

Re: [ietf-dkim] value-added DKIM-ish enhancements )was - Re: Weird i= in client mail)

[Murray S. Kucherawy]

On Tue, Jun 18, 2013 at 7:59 AM, Dave Crocker dcroc...@bbiw.net wrote:

 On 6/18/2013 7:18 AM, Tony Hansen wrote:
  I always thought it would be a nice follow-on to DKIM to provide a way
  for a site to specify how that site was using i=; that is, to provide
  some clarity and comprehension for that value. For example, our
  implementation placed the authenticated userid into i=. I know of one
  site that appears to use a hash of the authenticated userid. John L says
  his site uses how the mail was injected (submit, webmail, whatever) and
  who the user was if it knows. When there is a deterministic mechanism
  used to create i=, and the mechanism is known, then it is possible for
  additional logic to be added to the receiving side as well.


It would also have to be something trustable.  Otherwise, why should you
believe the party making such a statement?  A bad guy will put any value
there that increases the likelihood of making it to the inbox, whether it's
true or not.


 I'm sure Tony already knows this, but just to make sure it's part of the
 thread:

   Anyone can define a value-added protocol layer on top of DKIM.  It
 can define all sorts of additional semantics.

   It needs a method of declaring its presence, such as an extra
 header field or a special external query, but after that, it's free to
 define anything it wants, including a public meaning for i=


ATPS did exactly this.  It may be a poor example in that it has seen
approximately zero uptake due to lack of demand, but it does demonstrate
the mechanism Dave's describing here.

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

[ietf-dkim] DMARC working group charter proposal

[Murray S. Kucherawy]

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 dm...@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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Authentication-Results

[Murray S. Kucherawy]

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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] The good ol' t= tag in key records

[Murray S. Kucherawy]

On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner 
roland.tur...@trustsphere.com wrote:

 This appears to be the inverse of the use case that was originally put
 forward (we're concerned that we're signing rubbish, please disregard
 signatures made with this selector); the very case that you're arguing
 should be sustained despite t=y (considering negative reputation gained
 because rubbish is being signed) is exactly the one the ignoring of which
 started this discussion, no?


Pretty much.



 I wonder whether it would make more sense to view t=y as a holdover from
 DomainKeys and its o=-; that the need for a testing mode in fact only
 arose from the need to be able to tread carefully around making a we want
 some (presumably fraudulent) mail with our name on it blocked assertion.
 If this view prevails then t=y is merely a vestige that should have been
 removed when o= was punted to SSP/ASP/ADSP.

 I'd suggest that the opportunity to remove the (small) complexity
 represented by a feature that's not solving a useful problem (and has to
 some extent been superseded by DMARC: if you're not yet confident then
 stay at p=none) is worth taking.


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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] The good ol' t= tag in key records

[Murray S. Kucherawy]

On Mon, Jul 23, 2012 at 6:26 AM, Richard Dawe
rich.d...@messagesystems.comwrote:


 Do you think that DMARC provides a better way of testing your DKIM
 signatures than DKIM's t=y? E.g.: p=none DMARC policy.



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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] The good ol' t= tag in key records

[Murray S. Kucherawy]

On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas m...@mtcc.com 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.


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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] The good ol' t= tag in key records

[Murray S. Kucherawy]

On Mon, Jul 23, 2012 at 6:13 AM, Barry Leiba barryle...@computer.orgwrote:

 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.


Right.


 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 signatures made with this key as input to your evaluation
 of our reputation.  It would seem best to propose a new tag, in a
 DKIM extension, for that purpose, rather than re-using and overloading
 t=.


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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] The good ol' t= tag in key records

[Murray S. Kucherawy]

On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net wrote:

 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.


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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] The good ol' t= tag in key records

[Murray S. Kucherawy]

And you thought this list was dead.

I was asked to consult recently on some DKIM questions raised by a customer
of a former employer.  The questions involved the meaning of t= in DKIM
keys and the text in RFC6376.  The focus of this tag has always been, to
the best of my recollection, the notion that We're only testing DKIM, so
please don't punish this mail if the signature fails to verify.  We nearly
deleted this during the Draft Standard update because that's effectively
the same advice we give to failed signatures in general, making t=y
pretty much meaningless.  The only interesting thing we say about it now is
that if a verifier wants to be extra helpful, it could collect extra
information about failed signatures referencing t=y keys to help the
signer figure out what went wrong.

That customer brought up an interesting point.  t=y could also be useful
for messages whose signatures do verify.  Specifically, it could be used by
a signer to say It's possible this message shouldn't have been signed by
us.  Please don't give it any preferential treatment based on our name's
reputation if the signature verifies, which could then tarnish our
reputation.  Unlike the verification failure case, I don't think this has
any practical use by an attacker because it's explicitly declining any
special positive treatment.  That means it's actually useful in the success
case.

Any comments about this?  I talked to Dave last week as we happened to be
at the same event, and he thought this warranted a new erratum against
RFC6376.

I've opened a ticket to arrange that t=y suppresses any positive impact
domain reputation has in the next version of OpenDKIM, as an experiment.

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

Re: [ietf-dkim] Is TLS-OBC for SMTP (in theory) a good alternative to SPF?

[Murray S. Kucherawy]

On Tue, Jun 19, 2012 at 5:49 AM, Chris Lamont Mankowski 
makerofthing...@gmail.com wrote:

 I realize my last message talked about TLS-OBC for SMTP but didn't preface
 it with any information on how I see how it can replace, or compliment SPF
 in a given situation. First, does anyone know of a working group that is
 getting TLS-OBC to work in conjunction with the SMTP protocol?  Perhaps
 some of this information is written elsewhere.
 *
 *
 TLS-OBC allows for a SMTP server to publish its public keys into DNS,
 while removing any dependency (or 
 vulnerabilityhttp://security.stackexchange.com/q/2268/396)
 on the PKI hierarchy.  The approach works at the envelope layer (just like
 SPF) and has the potential to allow a sender to simply have a private key,
 instead of sending mail from a particular IP address.  This alone
 simplifies configuration and allows for many deployment models.

 Based on what I've read, in order for TLS-OBC to be secure the
 corresponding DMARC-TLS policy should define if DNSSec should be used for
 the certificate, CRL and OCSP links.  I personally want to also specify
 cipher and encryption levels as well, but I can see how that can fall out
 of DMARC's scope of message authentication.  Conversely, if a certificate
 is being used in situations to replace SPF, then we should specify the
 minimum crypto allowed (we don't want MD5 for example)

 For those who are interested, here is information on why DNSSec is
 required  http://security.stackexchange.com/q/6824/396 and additional
 information on how easy it is to spoof 
 DNShttp://security.stackexchange.com/q/6827/396
  .



This also sounds like it's on the wrong list.  I suggest ietf-s...@ietf.org.
Seems to have very little to do with DKIM.

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

[ietf-dkim] FW: RFC 6541 on DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures

[Murray S. Kucherawy]

FYI

-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On 
Behalf Of rfc-edi...@rfc-editor.org
Sent: Wednesday, February 29, 2012 10:59 AM
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: rfc-edi...@rfc-editor.org
Subject: RFC 6541 on DomainKeys Identified Mail (DKIM) Authorized Third-Party 
Signatures


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


RFC 6541

Title:  DomainKeys Identified Mail (DKIM) Authorized 
Third-Party Signatures 
Author: M. Kucherawy
Status: Experimental
Stream: IETF
Date:   February 2012
Mailbox:m...@cloudmark.com
Pages:  16
Characters: 31655
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-kucherawy-dkim-atps-16.txt

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

This experimental specification proposes a modification to DomainKeys 
Identified Mail (DKIM) allowing advertisement of third-party signature 
authorizations that are to be interpreted as equivalent to a signature added by 
the administrative domain of the message's author.  This document defines an 
Experimental Protocol for the Internet community.


EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet 
community.  It does not specify an Internet standard of any kind. Discussion 
and suggestions for improvement are requested.
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
Association Management Solutions, LLC


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

[ietf-dkim] FW: [marf] Last Call: draft-ietf-marf-dkim-reporting-11.txt (Extensions to DKIM for Failure Reporting) to Proposed Standard

[Murray S. Kucherawy]

FYI, in case anyone wants to comment.

-Original Message-
From: marf-boun...@ietf.org [mailto:marf-boun...@ietf.org] On Behalf Of The IESG
Sent: Wednesday, February 29, 2012 6:58 AM
To: IETF-Announce
Cc: m...@ietf.org
Subject: [marf] Last Call: draft-ietf-marf-dkim-reporting-11.txt (Extensions 
to DKIM for Failure Reporting) to Proposed Standard


The IESG has received a request from the Messaging Abuse Reporting Format WG 
(marf) to consider the following document:
- 'Extensions to DKIM for Failure Reporting'
  draft-ietf-marf-dkim-reporting-11.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action. Please send substantive comments to the i...@ietf.org 
mailing lists by 2012-03-14. Exceptionally, comments may be sent to 
i...@ietf.org instead. In either case, please retain the beginning of the 
Subject line to allow automated sorting.

Abstract


   This memo presents extensions to the DomainKeys Identified Mail
   (DKIM) specification to allow for detailed reporting of message
   authentication failures in an on-demand fashion.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ballot/


No IPR declarations have been submitted directly on this I-D.


___
marf mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/marf

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

[ietf-dkim] FW: Document Action: 'DKIM Authorized Third-Party Signers' to Experimental RFC (draft-kucherawy-dkim-atps-16.txt)

[Murray S. Kucherawy]

Hi all,

This got approved by the IESG.  Note that it is slightly different than the 
last time it was discussed here, courtesy of some suggested changes during IESG 
evaluation.

OpenDKIM has already implemented the revised version and is thus available for 
interop testing if anyone wants to try this out.

-MSK

-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On 
Behalf Of The IESG
Sent: Monday, January 09, 2012 2:01 PM
To: IETF-Announce
Cc: RFC Editor
Subject: Document Action: 'DKIM Authorized Third-Party Signers' to Experimental 
RFC (draft-kucherawy-dkim-atps-16.txt)

The IESG has approved the following document:
- 'DKIM Authorized Third-Party Signers'
  (draft-kucherawy-dkim-atps-16.txt) as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an IETF 
Working Group.

The IESG contact person is Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/




Technical Summary

  DKIM deliberately makes no binding between the DNS domain of the signer of a
  message and any other identity found in the message.  Despite this, there is 
an
  automatic human perception that an author domain signature (one for which the
  RFC5322.From domain matches the DNS domain of the signer) is more valuable or
  trustworthy than any other.  There is currently no protocol by which an ADMD 
can
  announce that DKIM signatures on its mail added by other ADMDs should also be
  considered trustworthy by verifiers.  This presents an experimental mechanism
  for doing so.

Working Group Summary

  This is an individual submission, but was discussed with the former DKIM
  participants, on the DKIM mailing list.  Note that there is NOT general
  agreement that this protocol is important, or even useful.  There is good
  consensus that experimentation is needed to determine utility, and this 
document
  sets up that experiment by proposing a protocol for it.

Document Quality

  ATPS has been prototyped, in preparation for this experiment, and is available
  in an open-source implementation.  Other implementations are expected as
  the experiment proceeds.

Personnel

  Barry Leiba is the Document Shepherd.
  Sean Turner is the responsible Area Director.


IANA Note

  The new registry should be nested under DKIM Parameters.

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Monday, July 11, 2011 3:52 AM
 To: DKIM
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
  Agents that evaluate or apply DKIM output need to be aware that a DKIM
  signer can sign messages that are malformed (e.g., violate RFC5322), or
  become malformed in transit, or contain content that is not true or
  valid.  Such an action might constitute an attack against a receiver,
  especially where additional credence is incorrectly given to a signed
  message without evaluation of the signer.  Moreover, an agent would be
  incorrect to infer that all instances of a header field are signed just
  because one is.  Agents will need to account for these issues when
  deciding how to apply DKIM results to message, especially when
  displaying them to users.
 
 OK, there is much good stuff in that. In particular, it makes it clear
 that Bad Stuff can originate from the signer as well as from
 men-in-the-middle and replayers. But I am still concerned that multiple
 occurrences of singleton headers fields are not explicitly mentioned,
 even as just one possible example.

That's what the violate RFC5322 and displaying them to users covers.  
Again, I don't think it's smart to name a specific attack in case it leads one 
to believe that it's the only interesting one.

 After all, you were seemingly happy to mention that particular trap in
 8.14 in draft-12.

That this stuff is in there at all is compromise to me, so you're not quite 
accurate in your use of happy.

 Not sure about the word incorrectly, but s/without evaluation/without
 adequate evaluation/ might make your point better. Though I expect, of the
 millions of perfectly legitimate domains that will exist without special
 recognition in any reputation system, it will be hard to spot a newly
 appearing 'badguy' one.

I don't think conversation about how reputation is applied is in scope; some 
systems could be used to give preferential treatment to good actors, some 
negative treatment to bad actors, some both.

 I still don't think that paragraph is what we really need, but I will
 withold judgement on that until I see how it gets incorporated into the
 other bits of text that are around.

Given that today's the deadline, we will have to go with something like this or 
nothing at all (which in fact I would prefer because I think all of this is 
adequately covered by existing text, and I believe consensus and the AD 
concurs), so withhold judiciously.


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

Re: [ietf-dkim] Doublefrom language should be in ADSP, not core

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Michael Deutschmann
 Sent: Sunday, July 10, 2011 12:53 AM
 To: DKIM List
 Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
 
 The attack only matters if the user believes that forgery is impossible
 because his ISP and the putative sender both deploy ADSP -- and thus the
 fact that the message made it to his mailbox means it has to be validly
 signed.  (Of course, such users are suckers for messages from
 0bama...)

I think the attack only matters if the MUA believes that the only thing ever 
present in the inbox is a validly-formed message, *and* the presence of a DKIM 
signature (regardless of signing domain) means the message is somehow more 
valid than one without.

 Otherwise, Obama messages with an alternate From: (which the forger
 hopes the MUA will ignore) and signature for that second From:, are no
 more convincing than plain old forgeries with a single From: and no
 signature at all.

+1

 In fact, they can be less effective, since:
 
 1. At any step on the way, the message may be rejected as a protocol
 violation.

Right, or have the extra From: arbitrarily removed.

 2. The MUA might display to the user, the From: instance that was
 intended by the forger for the validator's eyes only.
 
 3. The lazy validator might act on the From: instance that was intended
 by the forger for the MUA to display.
 
 Failures (from the forger's perspective) 1 and 2 produce a result less
 convincing than a simple unsigned forgery.  Failure 3 produces a result
 no more convincing than the simple unsigned forgery.

+1

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

Re: [ietf-dkim] Doublefrom language should be in ADSP, not core

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Scott Kitterman
 Sent: Sunday, July 10, 2011 6:46 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
 
 I think we should make it clear that singleton header fields like From (and
 Subject and Date) can be added without breaking signatures unless one is
 careful as a signer and/or a verifier.  This is related to a core DKIM design
 principle and doesn't need ADSP (or other non-standard measures) for it to be
 something we should care about.

I think the language we've proposed in response to the DISCUSS covers this 
appropriately.

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Sunday, July 10, 2011 6:00 AM
 To: DKIM
 Cc: Pete Resnick
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 Implementors of identity assessors and other agents need to be aware that
 DKIM signers can sign a message in such a way some header field at the top
 of the message (whether present originally or added later by an
 intermediary) is unverified, even though another instance of that field
 further down is signed, and even where the presence of such multiple
 instances violates RFC 5322. This can lead to a variety of attacks which
 take advantage of lenient MUAs which neither display nor warn about the
 duplicated header field.

Too specific.  All along I've been worried about naming specific attack vectors 
as such a list could be taken as exhaustive.  Try this:

Agents that evaluate or apply DKIM output need to be aware that a DKIM signer 
can sign messages that are malformed (e.g., violate RFC5322), or become 
malformed in transit.  Such an action might constitute an attack against a 
receiver, especially where additional credence is incorrectly given to a signed 
message without evaluation of the signer.  Moreover, a verifier would be 
incorrect to infer that all instances of a header field are signed just because 
one is.  Agents will need to account for these issues when deciding how to 
apply DKIM results to message, especially when displaying them to users.

I think that covers just about everything.  I don't agree with calling out 
Section 5.4.2 specifically, as there could be some other way to mount a 
receiver attack we haven't seen yet; calling attention there might divert it 
from other places where it's also needed.

I also don't think this is strictly necessary because the text we've proposed 
for 8.15 covers it already, but I find this to be a palatable compromise.

 Then what on earth IS the purpose of DKIM? There is an expectation that
 identity assessors will treat properly signed messages more favourably
 than signed ones (just how thay do that, and what other information they
 take into account is carefully not said).

You've answered the question yourself there (though I assume the second 
signed was supposed to be unsigned).

 The malicious signer is hoping
 that the treatment his scam gets is favourable enough to get past the
 assessor unscathed and so reach that lenient MUA, where the real damage
 happens.

I think the above text covers that as well.


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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Murray S. Kucherawy
 Sent: Sunday, July 10, 2011 8:39 PM
 To: Charles Lindsey; DKIM
 Cc: Pete Resnick
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 Agents that evaluate or apply DKIM output need to be aware that a DKIM
 signer can sign messages that are malformed (e.g., violate RFC5322), or
 become malformed in transit.  Such an action might constitute an attack
 against a receiver, especially where additional credence is incorrectly
 given to a signed message without evaluation of the signer.  Moreover,
 a verifier would be incorrect to infer that all instances of a header
 field are signed just because one is.  Agents will need to account for
 these issues when deciding how to apply DKIM results to message,
 especially when displaying them to users.

Actually, let me revise that a bit:

Agents that evaluate or apply DKIM output need to be aware that a DKIM signer 
can sign messages that are malformed (e.g., violate RFC5322), or become 
malformed in transit, or contain content that is not true or valid.  Such an 
action might constitute an attack against a receiver, especially where 
additional credence is incorrectly given to a signed message without evaluation 
of the signer.  Moreover, an agent would be incorrect to infer that all 
instances of a header field are signed just because one is.  Agents will need 
to account for these issues when deciding how to apply DKIM results to message, 
especially when displaying them to users.

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Friday, July 08, 2011 3:59 AM
 To: DKIM
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
  My favourite counterexample, which I've used many times already, is
  Mailman.  It doesn't even check DKIM signatures, but you can still fake
  your way through its authorization process such that a different From:
  is shown to the user for some MUAs.
 
 Can you please give me a pointer to that?

The source code.  I also recall looking at Spamassassin and/or procmail, and 
majordomo, and finding the same thing.

 If DKIM is not intended to give added credance to messages, then what on
 earth is its purpose at all.

That question is answered numerous times in the draft, namely the Abstract and 
Sections 1, 1.2, 1.5, 2.5, 2.7, 3.9, 3.11, 6.3, and 8.15 (and other parts of 8).

 Yes, it needs to be interpreted with care and
 understanding, and our Security Considerations are the vehicle for
 improving that understanding.

Indeed.

 I suspect may assessors will use a scoring system (like Spamassassin),
 where a signed message, even from a totally unknown domain, will add some
 positive contribution.

The text in the current draft spells that out as a bad idea.  Moreover, I see 
on Apache's website that right now Spamassassin penalizes a message 0.001 for 
being signed, but removes that penalty if the signature verifies.

-MSK

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Friday, July 08, 2011 3:52 AM
 To: DKIM
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 1. The fact that DKIM choose headers to sign from the bottom up (for good
 reason) facilitates certain attacks (not against DKIM, but certainly
 against somone/something) needs to be drawn to the attention of
 implementors of identity assessors, so that they can take appropriate
 action.

That's not part of what DKIM tells an assessor, nor is the list of signed 
header fields, so I don't see why that would be a useful thing to highlight.  
For example, if a message contains two Subject: fields, the assessor doesn't 
know which was signed; could be neither.  It still gets an SDID out of the 
verification and nothing more (possibly not even that if the signature failed).

 2. The fact that an attacker (whilst following DKIM to the letter) can use
 it, in conjunction with duplicated headers, to add credence to his message
 also needs to be drawn to their attention.

Same answer.  All you get is an SDID, if that.  The credence you add to the 
content comes from what you do with that value.  An assessor that gives a 
thumbs-up to any signed message without at least considering which SDID signed 
it is faulty.  But how the assessor works is not in scope here.

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Thursday, July 07, 2011 3:09 AM
 To: DKIM
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 The signer most certainly CAN attack, but what he is attacking is not
 DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in
 fact, his weapon of attack.

But all of those attacks exist today even without DKIM, so I don't see how DKIM 
becomes the weapon.  Even more simple attacks involve use of the display name, 
something none of this work has even tried to handle (nor should it).

It seems to me we're anticipating improper application of a DKIM pass here by 
MUAs or other agents and thus making the leap to calling DKIM a weapon.  In 
that light, MIME is also a weapon.  And so is RFC5322.  And so is HTML.

The current 8.15 text explains what a DKIM pass does and doesn't tell us 
rather clearly.  I'm wary of enumerating specific attacks and would prefer to 
use more general terms, as we have done here; such an effort might be taken as 
exhaustive.

 I carefully included two scenarios in my paragraph, which you quote above,
 because they are subtly different attacks. The 1st is the more pernicious
 IMHO and the hardest to counter, since the 'h=from:from:' defence does not
 work. I therefore regard it as ESSENTIAL that our Security Considerations
 give warning of that scenario. Moreover, it is also necessary to draw
 attention to the 'working upwards' signing order, which is at the heart of
 both scenarios, since that might not otherwise be clear to the reader.

In your scenario, the modules that operate on the signature result are able to 
observe that the signer took responsibility for a malformed message and can 
take appropriate action, degrading the signer's reputation, interfering with 
inbox delivery, or both.

 I would be happy to reword my paragraph to make it clear that these
 attacks are not against DKIM (although that point is also made strongly in
 a later paragraph). How about the following?
 [...]

I believe the current text is adequate in that it lays out the semantics of a 
pass more clearly.  I don't think calling out the two-froms-one-signed case 
explicitly will improve what's there.


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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Alessandro Vesely
 Sent: Thursday, July 07, 2011 4:56 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 I'd s/to be liberal/to be exceedingly liberal/ (we don't want to
 revise Postel's statement, do we?)

You're either liberal in your application of the RFCs, or you're not.  I don't 
see how adding that word improves things here.

 DKIM signs and validates the data it is told to and works correctly.
 So in this case, DKIM has done its job of delivering a validated
 domain (the d= value) and, given the semantics of a DKIM signature,
 essentially the signer has taken some responsibility for a
 problematic message.  It is up to the identity assessor or some other
 subsequent agent to act on such messages as needed, such as degrading
 the trust of the message (or, indeed, of the signer), or by warning
 the recipient, or even refusing delivery.
 
 I'd omit any allegation on what an assessor's needed actions might be.

Such as makes it clear these are only possible actions (and the obvious 
ones).  It's not an exhaustive list.

  (Actually, we'd need yet another policy or authentication method in
 order to allow the outcome of an identity assessor to be formally
 expressed.  Without it, the quick-n-dirty approach of degrading the
 trust of a message by tampering with its DKIM verification's results
 may seem the easiest remedy --much like what Doug et al. proposed.)

If the role of the identity assessor is reputation, and we decide later that we 
want reputation to be relayed to downstream agents, we can extend RFC5451 by 
such a registration then.  It doesn't make sense to do it here though.

 An agent consuming DKIM results needs to be aware that the validity
 of any header field, signed or otherwise, is not guaranteed by DKIM.
 
 Please, s/validity/reliability/: someone might believe a field is
 valid if it retains the value that was given to it originally.

Isn't that conclusion precisely what this sentence is countering?

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Scott Kitterman
 Sent: Thursday, July 07, 2011 6:32 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 I'm working with someone on an implementation and I think we're going to
 assume one more From than listed in h= when verifying to ensure nothing has
 been added.

This intentionally causes the verifier to assume what the signer really meant 
when it signed a message using a single From: field.  That may look safe but it 
isn't what DKIM actually says.

We might do this for libopendkim somewhere down the line, but it would default 
off.

In any case, interesting idea.

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Scott Kitterman
 Sent: Thursday, July 07, 2011 9:44 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 I agree it's not exactly what is specified in the protocol, but this is an
 implementation design issue.  I think it's safe.  If the DKIM protocol says I
 can't do something like this, then I think we have a problem with the current
 describe it and let implementors deal with it plan.

It's definitely not proscribed by DKIM.  All I meant was that you're preventing 
a signer from deliberately accepting responsibility for a message thus modified 
(by doing only one from in h=), knowing the risks of doing so.


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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Thursday, July 07, 2011 12:31 PM
 To: DKIM
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 I think Murray is wrong. There is no benefit to the Bad Guy in using two
 From: fields if he is not going to sign one of them. By signing, he hopes
 to gain sufficient extra credibility to get through.

My favourite counterexample, which I've used many times already, is Mailman.  
It doesn't even check DKIM signatures, but you can still fake your way through 
its authorization process such that a different From: is shown to the user for 
some MUAs.

This still supports the notion that we fear people will misapply DKIM results 
as the basis for the attack.  Your proposed changes here won't remedy that.

 Oh yes there is! Because identity assessors will undoubtedly give more
 credence to messages where the signature domain is the same as the author
 (i.e.From:) domain, even if they do not go to the extent of doing full
 ADSP, and that is just what the BadGuy hopes will happen.

Whose?  Mine don't, and the text doesn't support that notion either.

 And if implementors are not warned of this attack, they will tend to take a
 report of signed by the domain that DKIM regards as the appropriate
 From: at its face value and act accordingly.

Where in the bis document is that notion supported or even suggested?  I think 
the opposite is done in several places.

 Signers who are BadGuys don't give a damn about the reputation of their
 domains. Having displatched a million or so phishes with d=badguy.com,
 they will abandon that domain and use d=son-of-badguy.com for the next
 batch. All that can be said of the reputation of badguy.com is that it is
 a new domain, never seen before (but new domains are appearing all the
 time, and must be assumed more-or-less innocent until proven
 otherwise).

Certainly true, and certainly fodder for a BCP for using DKIM or even 
reputation, but not for the DKIM protocol specification (especially since we 
declared reputation out-of-scope ages ago).


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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Douglas Otis
 Sent: Thursday, July 07, 2011 6:47 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 Unfortunately, the norm is not to make these checks because only DKIM
 invites the possible exploit.  DKIM MUST accept the role of preventing
 the exploit it invites.

This is logically equivalent to saying SSL or TLS has to ensure the validity of 
the payload it is securing, because since that payload has been secured, people 
will assume it's also valid.  Will you be taking your fight to the TLS working 
group as well, then?

Otherwise, this is merely a repetition of the same argument that got us the 
DISCUSS in the first place.  One might even call it a replay attack...

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Barry Leiba
 Sent: Wednesday, July 06, 2011 9:32 AM
 To: Charles Lindsey
 Cc: DKIM
 Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
 
 As Pete has pointed out -- and has he's adamant about -- the signer
 can't attack... that is, DKIM can't do anything about attacks by the
 signer.  And that's as Charles's text itself points out.  So I'd be
 happy merging just the last sentence with the next paragraph, and
 eliminating the rest:

Interesting side note: Given the reference to Postel's Law being 
not-such-a-good-idea-after-all, it would be nice if this could make a forward 
reference to the malformed mail BCP under development.  That can't happen, so 
instead, we can perhaps just refer to this text from that document.

Anyway, with a few nitty edits from me as well, here's the current 8.15 for -15 
for everyone's consideration.  I concur with Barry with respect to the DISCUSS 
complaint about who's attacking what.  Also, the second paragraph already 
alludes to the fact that multiple From: fields is a problem regardless of 
whether or not one of them is signed.  I think it covers the bases and flows 
nicely.

Also, to be more precise about the deadline for this review, the cutoff for 
posting this is July 11th at 5pm PDT, so I would like to post it that morning 
if possible, giving the ADs time to look at it and bounce it to us for changes 
if needed.


8.15.  Attacks Involving Extra Header Fields

   DKIM is able to sign and validate many types of messages that might
   cause problems elsewhere in the message system.  The message might
   violate some part of [RFC5322], such as having multiple From: fields
   (or of other fields that are supposed to occur only once), or other
   malformed fields.  Equally, it might contain data that constitutes an
   attack on the recipient, such as falsely indicating the name of the
   author.  These can represent serious attacks, but they have nothing
   to do with DKIM; they are attacks on the recipient, or on the wrongly
   identified author.

   Many email components, including MTAs, MSAs, MUAs and filtering
   modules, implement message format checks only loosely.  This is done
   out of years of industry pressure to be liberal in what is accepted
   into the mail stream for the sake of reducing support costs;
   improperly formed messages are often silently fixed in transit,
   delivered unrepaired, or displayed inappropriately (e.g., by showing
   only one of multiple From: fields).

   A genuine signature from a domain under attack can be obtained by
   legitimate means, but extra header fields can then be added, either
   by interception or by replay.  In this scenario, DKIM can aid in
   detecting addition of specific fields in transit.  This is done by
   having the signer list the field name(s) in the h= tag an extra
   time (e.g., h=from:from:... for a message with one From field), so
   that addition of an instance of that field downstream will render the
   signature unable to be verified.  (See Section 3.5 for details.)
   This in essence is an explicit indication that the signer repudiates
   responsibility for such a malformed message.

   DKIM signs and validates the data it is told to and works correctly.
   So in this case, DKIM has done its job of delivering a validated
   domain (the d= value) and, given the semantics of a DKIM signature,
   essentially the signer has taken some responsibility for a
   problematic message.  It is up to the identity assessor or some other
   subsequent agent to act on such messages as needed, such as degrading
   the trust of the message (or, indeed, of the signer), or by warning
   the recipient, or even refusing delivery.

   An agent consuming DKIM results needs to be aware that the validity
   of any header field, signed or otherwise, is not guaranteed by DKIM.

   All components of the mail system that perform loose enforcement of
   other mail standards will need to revisit that posture when
   incorporating DKIM, especially when considering matters of potential
   attacks such as those described.

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Barry Leiba
 Sent: Saturday, July 02, 2011 8:27 PM
 To: DKIM Mailing List
 Subject: [ietf-dkim] Final update to 4871bis for working group review
 
 We have a week.  Murray will be posting the update (-14) very soon.
 Please review and comment by 11 July.

The update has been posted.  For your convenience:

http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/

You can also get the diffs here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-dkim-rfc4871bis-14


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

Re: [ietf-dkim] Pete's review of 4871bis

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Thursday, June 30, 2011 7:05 AM
 To: DKIM
 Subject: Re: [ietf-dkim] Pete's review of 4871bis
 
 The problem is that an apparently valid signature (albeit atching the
 wrong From) is likely to give a false impression of validity somewhere
 along the line unless modules down the line are watchig for this case (and
 for sure MUAs will not be watching for it for a long time, so it is the
 ISPs/boundary agents that need to do it).

If the advent of DKIM means that numerous modules implementing other 
specifications loosely suddenly have to pay a price for doing so, then that's 
the reality, and I still don't see how that's a problem DKIM needs to fix.  
Sure, we need to document the nuances DKIM introduces, but it's still not an 
attack against DKIM, so this remains the wrong place to deal with it in a 
normative sense.

If you prefer the loose application of other standards, don't use DKIM (and 
lose out on its benefits).

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

Re: [ietf-dkim] Pete's review of 4871bis

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Wednesday, June 29, 2011 9:20 AM
 To: DKIM
 Subject: Re: [ietf-dkim] Pete's review of 4871bis
 
 I agree that 8.14 is poorly written (and it was even worse a while back).
 However, there most certainly IS an attack here, which is NOT the same as
 the related attack discussed in 8.15, and cannot be prevented by putting
 extra entries in the 'h=' tag. Unfortunately, many WG members have failed
 to understand the difference between the two.

That's a mischaracterization of the objection.  h=from:from:... was not meant 
to address the attack about which you are complaining.

 In my opinion, there needs to be some REQUIRED action in the verifier which
 will result in a PERMFAIL, and which would then catch all attacks of this
 nature. But the WG consensus has been against this.

This was discussed ad nauseam.  The consensus reached was that DKIM is the 
wrong place to enforce compliance of RFC5322.  Rather, we stipulate that we 
expect those modules to do their jobs properly.

Nobody has said either of the two variants of this attack are not valid 
concerns.  The dispute is about what module in the handling of a message is 
responsible for detecting and dealing with it.

Since the problem exists even with a message that is not DKIM-signed, I still 
fail to understand how this is specifically a DKIM problem.

-MSK

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

Re: [ietf-dkim] Pete's review of 4871bis

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Dave CROCKER
 Sent: Wednesday, June 29, 2011 11:56 AM
 To: Pete Resnick
 Cc: DKIM
 Subject: Re: [ietf-dkim] Pete's review of 4871bis
 
 If I missed it, I apologize, but have you define what you mean by attack on
 DKIM?  And why is it important to distinguish which category an attack
 falls into?

I'll offer this up:

Something is an attack on DKIM if it involves input that can cause DKIM to 
report a pass when it should report a fail, or report d=example.com when 
it should've said d=example.org.

Since the general output of DKIM is pass/fail and a domain name plus some other 
optional signature stuff, I fail to see how double-From type attacks are 
attacks on DKIM.  Rather, I think these things we're discussing are attacks on 
MUAs (or on ADSP implementations) that fail to do RFC5322 enforcement or fail 
to understand what DKIM is telling them.


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

Re: [ietf-dkim] spam filtering 101

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Alessandro Vesely
 Sent: Tuesday, June 28, 2011 12:13 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] spam filtering 101
 
 +1, revising RFC 2505, whose date is in last century, should be due.

Actually I suspect this might be a different document, since the claimed attack 
isn't necessarily specific to spam.  Such a new document might make a lot of 
references to RFC2505.

On the other hand, if RFC2505bis was geared (and re-titled) toward more general 
abuse prevention, it would make more sense.

In any case, it seems unlikely this group will re-charter to do that, so 
someone could take it up as an independent submission or bring it to the 
APPSAWG or something like that.

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

Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting for Dutch 'comply or explain' list

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Monday, June 27, 2011 2:43 AM
 To: DKIM
 Subject: Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting 
 for Dutch 'comply or explain' list
 
 On Fri, 24 Jun 2011 17:58:19 +0100, Dave CROCKER d...@dcrocker.net
 wrote:
  Let's simplify this discussion:
 
  Spammers do a variety of techniques to trick filters and users.
 
  We should have the DKIM signing specification normatively require
  checking
  for every known technique, since we cannot be sure that any other part
  of the
  system will perform the necessary checks.
 
 +100
 
 But sadly the consensus of this WG was otherwise :-(

Mmm, I think Dave was being sarcastic.


___
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-13.txt

[Murray S. Kucherawy]

 -Original Message-
 From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On 
 Behalf Of internet-dra...@ietf.org
 Sent: Friday, June 24, 2011 12:08 PM
 To: i-d-annou...@ietf.org
 Cc: ietf-dkim@mipassoc.org
 Subject: I-D Action: draft-ietf-dkim-rfc4871bis-13.txt
 
 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   : DomainKeys Identified Mail (DKIM) Signatures
   Author(s)   : D. Crocker
   Tony Hansen
   M. Kucherawy
   Filename: draft-ietf-dkim-rfc4871bis-13.txt
   Pages   : 78
   Date: 2011-06-24
 [...]

IESG-requested tweaks only, plus an IPR statement adjustment since we don't yet 
have consent from all of the RFC4871 authors.

-MSK

___
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-11.txt

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Ian Eiloart
 Sent: Friday, June 17, 2011 2:41 AM
 To: dcroc...@bbiw.net
 Cc: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-11.txt
 
 The change in 3.4.5 has introduced a grammatical error:  the domain
 name is need not be The word is should have been removed.

Fixed.

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

Re: [ietf-dkim] Certified DKIM verification

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Alessandro Vesely
 Sent: Friday, June 17, 2011 8:13 AM
 To: ietf-dkim@mipassoc.org
 Subject: [ietf-dkim] Certified DKIM verification
 
 Hi all,
 does anybody know about commercial/free DKIM verifiers that produce a
 certificate of valid email message, or similar, for archival usage
 by the requesting party?

What, other than an Authentication-Results field, did you have in mind?

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

Re: [ietf-dkim] New canonicalizations

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Steve Atkins
 Sent: Monday, May 30, 2011 9:14 AM
 To: DKIM List
 Subject: Re: [ietf-dkim] New canonicalizations
 
 The most obvious thing that MLMs do that invalidate signatures are 1.
 append content to the body and 2. prepend content to the subject line.
 Any approach that allows me to replay messages while making those
 changes seems to open the door to abuse.

Agree on all counts.  And I talked to the Mailman people, for example, about a 
modified header canonicalization that deals with Subject: tagging, and they 
also agreed it wouldn't help that much since that's not the most common change 
made that would invalidate the signatures.

So as far as I can tell, we're at a point where lots of people think they want 
MLM survivability of signatures, or at least the chain-of-trust capability, but 
no proof that the increased risk is worth the increased gain.

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

Re: [ietf-dkim] New canonicalizations

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Alessandro Vesely
 Sent: Saturday, May 28, 2011 9:29 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] New canonicalizations
 
 On 27/May/11 19:16, Murray S. Kucherawy wrote:
  I'm all for including experimental code in future releases of our
  stuff, especially if it's an experiment other implementations are
  trying.  But I need to see a spec first, or enough detail that I
  could write one.
 
 For the body, I brought some ideas[1].  For MIME header fields,
 punctuation and boundaries need to be omitted as well.  For other
 header fields, including the DKIM-Signature, it is probably enough to
 remove just any white space.
 [1] http://mipassoc.org/pipermail/ietf-dkim/2011q2/016692.html
 
 IMHO, the hard parts of the code are (i) selecting a MIME parser,
 and (ii) finding a good way to structure experimental C14Ns and handle
 double (triple?) signatures in the existing code.

One of the elegant things about the current canonicalizations is that they can 
stream.  I think a system that's MIME-aware can too, but possibly not, and in 
any case having to teach a DKIM implementation about MIME will make it a lot 
more complicated and expensive.  If we have to go down that road, I think 
working on DOSETA and MIMEAUTH is the way to go.

If we want the lower-hanging fruits, we might take the list of things MLMs like 
to do to messages and find ways to canonicalize those.  Fortunately, we made a 
list of the common ones in the MLM document.


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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Alessandro Vesely
 Sent: Friday, May 27, 2011 9:08 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
  Certainly a possible feature, but it seems like it won't scale very
  well.
 
 Why not?  Of course, having a copy of each subscription record would
 roughly double the database, globally.  Twice is scalable, though.

An automated system to monitor mail flows to figure out lists to which users 
have subscribed or unsubscribed can't scale unless there are standards around 
how to do that, and everyone participates.  That's a high bar to set.

A manual system requires users to register lists they join or depart.  That's 
bound to be increasingly inaccurate over time.  And if every Gmail user 
subscribes to just two lists, that's an awfully large number of relationships 
to track and check on each message transiting their MTAs.

I could be wrong, but it sounds like a nightmare.


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

Re: [ietf-dkim] New canonicalizations

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Alessandro Vesely
 Sent: Friday, May 27, 2011 10:09 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] New canonicalizations
 
 By introducing a loose canonicalization we may learn whether signature
 survivability affects DKIM adoption.  If wider usage introduces
 attacks, we can switch back to current canonicalizations --in case
 downgrades will have gone away-- or design yet another one,
 approaching just the tightness we need.  My appeal is for not imposing
 monotonicity to successive approximations, and allow erring on the
 too-lose side as well.

So what, for example, would you do differently?  The unfortunate thing about 
the way the crypto works is that you get a failure, but you don't know for sure 
what changed other than it was in the header or it was in the body.  z= 
sometimes gives you details about the former but it's not in widespread use.

I'm all for including experimental code in future releases of our stuff, 
especially if it's an experiment other implementations are trying.  But I need 
to see a spec first, or enough detail that I could write one.


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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Hector Santos
 Sent: Thursday, May 26, 2011 10:44 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
 This sounds like you are missing a point here.

And what point is that?

 But it might help to
 know a general makeup of the volume collection you have from the
 standpoint if it was already pre-filtered.  I guess you won't readily
 know that without asking your contributors, but it would be good know
 what level, if any, filtering was already done.

All reporting sites are doing at least some RBL filtering, and all 
spam/not-spam flags are Spamassassin verdicts plus a few user-provided verdicts 
thrown in.

 For your collection analysis, you will need a majority of the system
 with always accept first operations so that you can get the large
 spectrum of bad vs good mail. Then you will need a criteria for what
 is considered bad.

I think that's unnecessary.  If we can assume our reporting sites are typical, 
then the results are typically meaningful.  It just means the results have to 
be taken in the same context in which the data were collected, which seems 
reasonable to me.

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

Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Ian Eiloart
 Sent: Thursday, May 26, 2011 3:08 AM
 To: John R. Levine
 Cc: DKIM List
 Subject: Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
 
 I think the long term solution would be for mailing list software to
 stop mucking around with the message body, and for MUAs to work better
 at exposing meta data added by lists (like the list-unsubscribe
 header).

The MLM document does say that such a thing is preferable, but not expected to 
become a reality any time soon.  So really, we've already been down this road.

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

[ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of John R. Levine
 Sent: Thursday, May 26, 2011 6:40 AM
 To: Ian Eiloart
 Cc: DKIM List
 Subject: Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
 
 Mailing lists have worked quite well for 40 years with no signatures at
 all, making all sorts of random changes to the mail, so it has to be
 something more than that.

Applying the same logic: Email in general has been fine without DKIM for 40 
years, so why do we need it?

Thinking in abstract terms: If you accept the premise that DKIM delivers a 
validated domain name as its payload, and that domain name represents an ADMD 
that takes some responsibility for a message, then it's not clear to me why 
one would claim it's not valuable to have two responsible parties instead of 
just one.  You can then evaluate both of those names and decide if either of 
them, or perhaps the combination of them, warrant additional filtering or, 
instead, priority handling.

The question really is: How valuable is this?  Or put another way: Is it worth 
the work to make the two identities available instead of only that of the MLM?  
I suspect the answer is yes as it can only improve your accuracy.  The only 
remaining issue is how hard it will be to make that happen, and whether or not 
the payoff is big enough to offset the pain.  That, I think, is the real thing 
that needs to be evaluated.

Now, those are abstract terms.  When argued in terms of passing an author 
signature through an MLM given modern realities, it does indeed sound like it's 
not worthwhile, because in that particular context you're not likely to see the 
stuff you want to filter coming via such paths in the first place.

But now invert that thinking.  Let's say your domain manages to acquire a 
positive reputation, but now you and I are on a re-signing MLM whose domain has 
no reputation or maybe even a slightly negative one.  Your reputation could 
trump that of the list, or could improve that of the list by your participation 
in it, at least from my perspective.  But for that to happen, your signature 
has to survive.

I don't think that's a concept that should be discarded out of hand just 
because MLMs have been the way they are for a long time and they're in the way 
of such innovations.  Updating them even a little might enable a host of useful 
new applications.


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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Steve Atkins
 Sent: Thursday, May 26, 2011 12:21 PM
 To: DKIM List
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
 In my experience with traditional discussion MLMs (which is the
 situation we're talking about) if I trust the MLM, I generally don't
 care about who the participants are.

Good, that's useful data.

 If the reputation of the MLM is poor enough that mail from it is not
 being delivered, trumping that with an authors reputation may get
 individual emails delivered - but not threads, so it doesn't really
 improve the value provided to the recipient (it probably decreases it -
 a mailing list that delivers one in ten posts to my inbox is less
 useful than one that delivers none at all).

Perhaps an MLM's reputation is pulled up or down as the average of those of its 
participants, so if the MLM can attract good senders, suddenly entire threads 
start getting through.  But that would only be possible with signature survival.

I don't know, I'm mostly brainstorming here.  The abstract idea seems 
reasonable but the MLM instance of it carries with it so much baggage that it's 
perhaps the worst possible example.

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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: John R. Levine [mailto:jo...@iecc.com]
 Sent: Thursday, May 26, 2011 1:29 PM
 To: Murray S. Kucherawy
 Cc: DKIM List
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
 If anyone's claiming that contributors' DKIM signatures on list mail are
 important, a good start would be to look at how PGP and S/MIME signatures
 have been treated during the many years they've been in use.  I don't see
 any harm in experiments like having an MLM adding a signed A-R header to
 the mail, since it doesn't break anything that works now, but I would want
 rather concrete evidence from anyone claiming that people pay any more
 attention than they do to S/MIME signatures now.

There are parties that want to do that experiment because they see potential in 
it.  (In fact they're doing it now through a non-standard hack; I need to ask 
them for results.)  What would probably be helpful is some decent description 
from them of why they think it's valuable and how they plan to use it.

You're absolutely right that nobody's cared up until now, but I'm not as sure 
as you are that this makes the question utterly uninteresting.

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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Franck Martin
 Sent: Thursday, May 26, 2011 1:13 PM
 To: Steve Atkins; DKIM List
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
 side note: do
 mail receivers treat mailing list differently than any other emails?

That's a local policy question.  Personally, I don't know of any that do.

 2) do we need a mechanism to alert the receiving MTA that you have
 subscribed to a mailing list, and all messages should pass through?

Certainly a possible feature, but it seems like it won't scale very well.

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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Steve Atkins
 Sent: Thursday, May 26, 2011 3:20 PM
 To: DKIM List
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
 That's relying on an awful lot of vaporware in the MUA, orthogonal to
 any sort of authentication. I don't think any MUAs really track sender
 reputation in any way[1].

It's not vapourware in general.  Such feedback systems exist, and could easily 
be tied to DKIM domains.

 Well, d= won't identify the original sender at all, in the case of
 individuals sending to a mailing list. It'll identify the domain of
 their ISP, nothing more.

Well, right.  You'd be basing decisions on validated DKIM d= values.

 Tunneling DKIM signatures through MLMs doesn't seem to be the missing
 bit of technology needed to do this.
 
 If the MLM signs any email it sends then you have some level of trust
 in any information it annotates the mail with.

Yes, and A-R provides a mechanism for doing that as well.  It's mentioned in 
the MLM draft too.

 *If* it were possible to identify the original email author in some way
 (S/MIME, PGP, some private shared secret approach) the MLM could
 annotate the mail with that information, and you could trust it enough
 to filter on. If the MLM doesn't have enough information to identify
 the original email author, it's unlikely you do either - whether
 there's a second DKIM signature or not.

Why the last part of that?

 [1] It's something that'd be useful, though - it's been on my TODO list
 for about two years to add exactly this to our CRM system, via end-user
 thumbs-up / thumbs-down buttons.

We have that at Cloudmark, and there's an open one as well.  I'm trying to 
figure out if and how such a system could be used when correlated with DKIM 
signatures.

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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Steve Atkins
 Sent: Thursday, May 26, 2011 3:47 PM
 To: DKIM List
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
  It's not vapourware in general.  Such feedback systems exist, and
  could easily be tied to DKIM domains.
 
 I don't think they exist at the MUA level, keyed on senders. I'd
 be interested to hear about them if they do.
 
 (There are bunches of end-user visible reputation systems that
 have UI in the MUA, of course, but they don't track reputation
 on a per-end-user basis, rather they feed end-user perception
 into a shared reputation system).

Whether the reputation is made visible as a property in the UI versus in the 
accept/reject/discard decision at delivery time isn't an important distinction, 
is it?

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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of MH Michael Hammer (5304)
 Sent: Thursday, May 26, 2011 4:15 PM
 To: Scott Kitterman; ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
 The other piece of the equation is how often do I see abusive mail
 purporting to be from this domain with no signature while mail from this
 domain that is normally signed has no significant problems.

I posted the results of some research on that very question earlier this week:

http://mipassoc.org/pipermail/ietf-dkim/2011q2/016656.html


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

Re: [ietf-dkim] MLMs and signatures again

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Scott Kitterman
 Sent: Thursday, May 26, 2011 5:36 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] MLMs and signatures again
 
 My experience is it varies a lot by domain.  Some domains are phishing targets
 and some aren't.  If it's not a phishing target DKIM doesn't matter much
 either way.  If it is, then if they can manage to sign all their outbound mail
 signed/not signed gets to be useful.  So I don't think looking at global
 status is a very useful basis for deciding the question.

So you'd rather I run this on some signing domains that aren't obvious phish 
targets?  I can do that.  If you have a few you think might be interesting, 
send me the names; if not, I can see if I can come up with some just based on 
the numbers.

And I can constrain it to a specific reporting site (e.g., my own) instead of 
all reporters if you think that gives a more interesting view.


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

Re: [ietf-dkim] New canonicalizations

[Murray S. Kucherawy]

 -Original Message-
 From: Dave CROCKER [mailto:d...@dcrocker.net]
 Sent: Tuesday, May 24, 2011 5:33 PM
 To: Murray S. Kucherawy
 Cc: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] New canonicalizations
 
 Let's make it be the right work.
 
 To make a canonicalization algorithm that is more robust -- such as having it
 based on canonical forms of data, independent of encoding -- makes some sense.
 Trying to create the ability to reverse changes strikes me as far to complex
 and fragile to be reasonable.

I think your last sentence is what I was getting at.

One could have a 7-bit canonicalization that does the same sort of thing MIME 
does, I suppose, at least in terms of content conversion.  Not having given it 
much thought yet, though, I suspect doing this at the MIME level is more likely 
to be successful rather than at the message level, which is where DKIM lives.

I could swear I heard that idea presented recently...


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

Re: [ietf-dkim] New canonicalizations

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Charles Lindsey
 Sent: Monday, May 23, 2011 2:21 AM
 To: DKIM
 Subject: Re: [ietf-dkim] New canonicalizations
 
 Could you get the effect of this by including the
 Content-Transfer-Encoding header in the 'h=' and doing some fancy checks
 involving the 'bh=' (to detect whether it was the body or the headers or
 both that were broken)?

I don't think so, because a re-encoding causes a change to 
Content-Transfer-Encoding itself, which in turn changes both hashes, not just 
one of them.

You could use an extension tag to capture the original 
Content-Transfer-Encoding as a hint to the canonical form that was signed, but 
that means the verifier has to undo the conversion before computing the hashes, 
and it has to do that bytewise precisely as well as reconstructing the original 
MIME header fields.  Getting that even a byte off (modulo relaxed) means 
you're toast.

At that point I suspect you may as well bite the bullet and start down the road 
of defining a new canonicalization that accommodates possible downgrades in 
transit, picking either 7-bit or 8-bit as the canonical form, and feeding that 
form to the hash to be used in signature generation.  But once you consider 
that a multipart can have some 7-bit and some 8-bit, this can get real messy 
real fast.

Once this becomes an actual problem, I imagine MIMEAUTH will start to get even 
more interesting.


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

[ietf-dkim] No signatures, bad signatures, cousin domains

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Scott Kitterman
 Sent: Monday, May 23, 2011 10:12 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] 8bit downgrades
 
  Do you have numbers to show that broken signatures indicate that messages
  are malicious, or spam, or otherwise worse than otherwise?
 
 None that I can share unfortunately.  IME no signature is more suspicious than
 a broken one (as you suggest, I think most breakage is innocent), but putting
 broken and no signature into the same bucket is the most sensible and RFC
 compliant way to approach it.

Interesting.  I ran some queries on our data for ebay.com, paypal.com, 
chase.com and bankofamerica.com.  In all cases, messages with failed signatures 
were never tagged by Spamassassin, and at most 7% (usually less) of unsigned 
mail where the From: field contained those domains was tagged.  This seems to 
concur with the most breakage is innocent theory and also supports the notion 
that treating a broken signature as equal to no signature is almost always the 
right way to go.


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

Re: [ietf-dkim] No signatures, bad signatures, cousin domains

[Murray S. Kucherawy]

 -Original Message-
 From: Michael Thomas [mailto:m...@mtcc.com]
 Sent: Wednesday, May 25, 2011 7:03 AM
 To: Murray S. Kucherawy
 Cc: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] No signatures, bad signatures, cousin domains
 
 Heuristic based systems like SA are subject to the phases of the moon
 with respect to what they find valuable and for how long. If they find
 it useful to educe something from DKIM or lack thereof, more power to
 them. Heck, if they just used the signature header pattern to determine
 spam from ham for different senders, that would be cool too. This is not
 in conflict from the statement that _cryptographically_ a broken signature
 is no different than a missing signature. SA and its ilk just don't operate
 on the plane of mathematical provables is all; nothing wrong with that.

My use of Spamassassin for correlation of DKIM verification versus message 
classification is really only a proof-of-concept thing.  Certainly connecting 
this stuff to a much more robust spam feedback system like the one Cloudmark 
has would produce far better results.  It's somewhere on my to-do list.


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

Re: [ietf-dkim] 8bit downgrades

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Hector Santos
 Sent: Sunday, May 22, 2011 10:43 AM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] 8bit downgrades
 
 Please refrain from passing the buck to the WG. The document editors
 are:
 
 D. Crocker (editor)
 Tony Hansen (editor)
 M. Kucherawy (editor)
 
 If the WG was technically incapable as you are implying, then the
 *onus* was on the editors to make sure it was writing it correctly.

Given that it's been pointed out the use of SHOULD in this case is entirely 
appropriate, I'm happy to accept blame on behalf of the other authors for 
getting it right.


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

Re: [ietf-dkim] New canonicalizations

[Murray S. Kucherawy]

 -Original Message-
 From: Ian Eiloart [mailto:i...@sussex.ac.uk]
 Sent: Thursday, May 19, 2011 4:00 AM
 To: Murray S. Kucherawy
 Cc: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] New canonicalizations
 
 Right, but you can't address that by examining only the traffic from
 the high traffic domains. If the spammers are spreading across domains,
 then you won't see their traffic in that analysis.

But that's not what the report I ran produced.  There's no doubt spammers are 
spreading across domains, but their choice of canonicalization doesn't seem to 
make a difference in that regard.

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

Re: [ietf-dkim] New canonicalizations

[Murray S. Kucherawy]

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Ian Eiloart
 Sent: Thursday, May 19, 2011 3:21 AM
 To: John Levine
 Cc: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] New canonicalizations
 
 Probably true, but if the difference between 10% broken and 8% broken
 signatures is independent of whether the email is spam, then actually
 relaxed seems to be producing a 20% reduction in signature breakage.
 
 I'd argue that a 20% reduction in broken signatures *is* actually much
 better.

That statistic is largely meaningless unless there's a basis for comparison.  
For example, it would be useful to observe that the same message, sent with 
each of the four canonicalizations, to the same set of destinations using the 
same endpoint software, produced different results given that one changing 
variable.  But if domain X only ever tried sending with relaxed/relaxed and 
generally gets good results, there's nothing in that datum to say that 
simple/simple would not have worked just as well for the same sender with the 
same mail.  Thus I don't believe there's enough data to support your conclusion.

That relaxed/relaxed appears to survive 20% more might be based on the fact 
that the people using it send clean mail through clean paths, and it's as 
simple as that.

 To determine that, we'd need a pareto analysis of breakage modes.
 Presumably lists that aren't re-signing are responsible for some of
 this, as are broken signing mechanisms. The questions remaining are,
 is there anything left after excluding those two cases?, and how
 much of that could be fixed easily?.

Our stats are unable to tell what the problem is in all cases, but for mail 
we've received where the signer used the z= tag, the biggest signature 
breaker in terms of header changes is modified To: fields.  I suspect that's 
either rewriting by lists to add the list description as a comment, or 
improperly quoted comment fields that are corrected along the way.


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

[ietf-dkim] 8bit downgrades

[Murray S. Kucherawy]

Can anyone remember why there's a SHOULD for the downgrade to 7-bit in RFC4871 
Section 5.3, rather than a MUST?  The likelihood of breakage is so high when 
sending 8-bit data that DKIM almost becomes pointless without the upgrade.

Not advocating for this to be changed in -bis (yet), but someone's asking me 
for the history behind that decision.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html