Re: [ietf-dkim] double header reality check

[Mark Delany]

On Wed, Oct 20, 2010 at 09:38:04PM -0700, Murray S. Kucherawy allegedly wrote:
> > -Original Message-
> > From: John R. Levine [mailto:jo...@iecc.com]
> > Sent: Wednesday, October 20, 2010 5:08 PM
> > To: Murray S. Kucherawy
> > Cc: ietf-dkim@mipassoc.org
> > Subject: Re: [ietf-dkim] double header reality check
> > 
> > > Here's maybe a better way to frame the question: Should we empower
> > > ourselves to label a DKIM implementation that doesn't do format
> > > enforcement as (a) non-compliant, or (b) low-security/low-quality?
> > 
> > The latter.  Hey, we agree.  I think I always said SHOULD rather than
> > MUST.
> 

> Damn, lost it.  I think we should talk about it, and even in detail,
> but without using those words.

> And I'd be fine converting the MUA advice to which you refer into
> something more general, like hammering home the point about what
> exactly a validated signature is telling you, and leave it to the
> implementers of those modules to figure out what to do with that
> information.

It's stating the obvious by now, but I'm with (a).

While it might be technically elegant to delegate (a) to another
layer or some "magic sauce", or some informative text, it misses the
bigger picture.

That bigger picture is that DKIM has no certainty of success simply by
being a technically neat and layer-compliant protocol.

DKIM will succeed only if it is picked up and used by a vibrant and
wide-spread community of DKIM consumers - MUAs, list servers,
reputation systems, email appliances, whatever.

Given the well-recognized inertia in the email biz, to maximize our
chance of success, we need to make it as easy as possible for this new
community of DKIM consumers to succeed. To my mind that means that
those consumers can write no-brainer code and reap the benefits of
DKIM.

So, every time we relegate or delegate parts of DKIM compliance to
those consumers - perhaps by way of informative text about 2822
compliance - we are simply creating barriers for the very consumers
that we need to make DKIM a success.

Are we so confident about DKIM adoption that we feel we can
effectively "order" this future community to do this sort of work?

I for one am not. I for one think that if we make DKIM as easy as
possible to consume and we market the heck out of it, we may, we just
may succeed in wide-spread adoption, maybe.

So, forget technical elegance. Forget layering violations. What are we
doing that makes DKIM compelling and easy to consume?


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

Re: [ietf-dkim] double header reality check

[Murray S. Kucherawy]

> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Wednesday, October 20, 2010 5:08 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] double header reality check
> 
> > Here's maybe a better way to frame the question: Should we empower
> > ourselves to label a DKIM implementation that doesn't do format
> > enforcement as (a) non-compliant, or (b) low-security/low-quality?
> 
> The latter.  Hey, we agree.  I think I always said SHOULD rather than
> MUST.

Damn, lost it.  I think we should talk about it, and even in detail, but 
without using those words.

And I'd be fine converting the MUA advice to which you refer into something 
more general, like hammering home the point about what exactly a validated 
signature is telling you, and leave it to the implementers of those modules to 
figure out what to do with that information.


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

Re: [ietf-dkim] double header reality check

[Steve Atkins]

On Oct 20, 2010, at 6:08 PM, Scott Kitterman wrote:

> 
> 
> "Michael Thomas"  wrote:
> 
>> On 10/20/2010 04:36 PM, Steve Atkins wrote:
>>> 
>>> On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote:
> 
>> Validating mail syntax belongs in the specification for the mail
>> components and DKIM work belongs in the DKIM components.
> 
> That's why, layer violation or no, I think it's important to distinguish
> between format errors that are likely to lead to misleading rendering in
> existing MUAs, and the much larger class that may produce nonsense but
> won't produce lies.
 
 I think we're close to converging here.
 
 I totally agree that that's an important distinction to make, document, 
 highlight and shout from the rooftops.  But... Does it *have* to use 
 RFC2119 normative language?
 
 Here's maybe a better way to frame the question: Should we empower 
 ourselves to label a DKIM implementation that doesn't do format 
 enforcement as (a) non-compliant, or (b) low-security/low-quality?
 
 I'm pushing for (b), while someone who insists the text be normative is 
 pushing for (a).
>>> 
>>> I'm pushing for neither. It's not the DKIM verifiers responsibility to 
>>> enforce that.
>>> 
>>> I do think that an informative note observing "Here are a couple of issues 
>>> that might theoretically be exacerbated by a DKIM-using world; you might 
>>> consider checking for these problems somewhere in your mail handling path, 
>>> if you aren't already" would be reasonable.
>>> 
>>> "Somewhere in your mail handling path" might be in the same binary as the 
>>> DKIM validator, or it may not - and implying that an implementation that 
>>> chooses to handle two entirely separate validation issues in two separate 
>>> modules is "non-compliant" or "low-security" or "low-quality" doesn't seem 
>>> helpful.
>> 
>> I think that Steve threads this just about right. No need to cast aspersions,
>> or kick them off the "compliant" island. Just lay out the security 
>> consideration
>> and let people deal with this however makes sense. I'm still puzzled how this
>> tempest entered this tea pot.
>> 
> Um. That's not how I read what he wrote. He specifically said no to security 
> considerations

I don't think I did. The "informative note" would probably be something 
informative, rather than prescriptive, in the security considerations section.

What I wouldn't favour would be a MUST or a SHOULD or anything morally 
equivalent to either, as it's outside the scope of a DKIM specification to do 
that.

> and I understand that's what you're in favor of.

Cheers,
  Steve


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

Re: [ietf-dkim] double header reality check

[Scott Kitterman]

"Michael Thomas"  wrote:

>On 10/20/2010 04:36 PM, Steve Atkins wrote:
>>
>> On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote:

> Validating mail syntax belongs in the specification for the mail
> components and DKIM work belongs in the DKIM components.

 That's why, layer violation or no, I think it's important to distinguish
 between format errors that are likely to lead to misleading rendering in
 existing MUAs, and the much larger class that may produce nonsense but
 won't produce lies.
>>>
>>> I think we're close to converging here.
>>>
>>> I totally agree that that's an important distinction to make, document, 
>>> highlight and shout from the rooftops.  But... Does it *have* to use 
>>> RFC2119 normative language?
>>>
>>> Here's maybe a better way to frame the question: Should we empower 
>>> ourselves to label a DKIM implementation that doesn't do format enforcement 
>>> as (a) non-compliant, or (b) low-security/low-quality?
>>>
>>> I'm pushing for (b), while someone who insists the text be normative is 
>>> pushing for (a).
>>
>> I'm pushing for neither. It's not the DKIM verifiers responsibility to 
>> enforce that.
>>
>> I do think that an informative note observing "Here are a couple of issues 
>> that might theoretically be exacerbated by a DKIM-using world; you might 
>> consider checking for these problems somewhere in your mail handling path, 
>> if you aren't already" would be reasonable.
>>
>> "Somewhere in your mail handling path" might be in the same binary as the 
>> DKIM validator, or it may not - and implying that an implementation that 
>> chooses to handle two entirely separate validation issues in two separate 
>> modules is "non-compliant" or "low-security" or "low-quality" doesn't seem 
>> helpful.
>
>I think that Steve threads this just about right. No need to cast aspersions,
>or kick them off the "compliant" island. Just lay out the security 
>consideration
>and let people deal with this however makes sense. I'm still puzzled how this
>tempest entered this tea pot.
>
Um. That's not how I read what he wrote. He specifically said no to security 
considerations and I understand that's what you're in favor of.

Confusedly yours,

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

Re: [ietf-dkim] double header reality check

[Michael Thomas]

On 10/20/2010 04:36 PM, Steve Atkins wrote:
>
> On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote:
>>>
 Validating mail syntax belongs in the specification for the mail
 components and DKIM work belongs in the DKIM components.
>>>
>>> That's why, layer violation or no, I think it's important to distinguish
>>> between format errors that are likely to lead to misleading rendering in
>>> existing MUAs, and the much larger class that may produce nonsense but
>>> won't produce lies.
>>
>> I think we're close to converging here.
>>
>> I totally agree that that's an important distinction to make, document, 
>> highlight and shout from the rooftops.  But... Does it *have* to use RFC2119 
>> normative language?
>>
>> Here's maybe a better way to frame the question: Should we empower ourselves 
>> to label a DKIM implementation that doesn't do format enforcement as (a) 
>> non-compliant, or (b) low-security/low-quality?
>>
>> I'm pushing for (b), while someone who insists the text be normative is 
>> pushing for (a).
>
> I'm pushing for neither. It's not the DKIM verifiers responsibility to 
> enforce that.
>
> I do think that an informative note observing "Here are a couple of issues 
> that might theoretically be exacerbated by a DKIM-using world; you might 
> consider checking for these problems somewhere in your mail handling path, if 
> you aren't already" would be reasonable.
>
> "Somewhere in your mail handling path" might be in the same binary as the 
> DKIM validator, or it may not - and implying that an implementation that 
> chooses to handle two entirely separate validation issues in two separate 
> modules is "non-compliant" or "low-security" or "low-quality" doesn't seem 
> helpful.

I think that Steve threads this just about right. No need to cast aspersions,
or kick them off the "compliant" island. Just lay out the security consideration
and let people deal with this however makes sense. I'm still puzzled how this
tempest entered this tea pot.

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

Re: [ietf-dkim] double header reality check

[John R. Levine]

> Here's maybe a better way to frame the question: Should we empower ourselves 
> to label a DKIM implementation that doesn't do format enforcement as (a) 
> non-compliant, or (b) low-security/low-quality?

The latter.  Hey, we agree.  I think I always said SHOULD rather than 
MUST.

The DKIM spec is a peculiar combination of instructions on how to produce 
a technically valid signature along with a great deal of non-normative 
advice, some of which is good (sign all the visible headers) and some of 
which is not so good (tell MUAs to highlight the signed parts.)  If I were 
redoing it, I think I would go through all the advice and either turn it 
into a SHOULD if it tells you how to do more robust signing and 
verification, or get rid of it.  If you recall my snarky message to Dave a 
few days ago, I actually do think we should get rid of that stuff.

There are already a zillion ways to produce a technically valid but 
useless signature, so I'm not concerned about yet another one.  I'd just 
like to give people who want to do useful signing and verification the 
best shot at it we can.  Keep in mind the "as if" rule, which says that 
your code can do whatever you want so long as the results are the same as 
if you followed the spec.  So if the spec says you SHOULD NOT sign or 
verify messages that have extra headers that MUAs are likely to render 
inconsistently, it would be entirely valid to have a validation prepass 
that ensured that the DKIM module never saw those messages at all.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] double header reality check

[Steve Atkins]

On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote:
>> 
>>> Validating mail syntax belongs in the specification for the mail
>>> components and DKIM work belongs in the DKIM components.
>> 
>> That's why, layer violation or no, I think it's important to distinguish
>> between format errors that are likely to lead to misleading rendering in
>> existing MUAs, and the much larger class that may produce nonsense but
>> won't produce lies.
> 
> I think we're close to converging here.
> 
> I totally agree that that's an important distinction to make, document, 
> highlight and shout from the rooftops.  But... Does it *have* to use RFC2119 
> normative language?
> 
> Here's maybe a better way to frame the question: Should we empower ourselves 
> to label a DKIM implementation that doesn't do format enforcement as (a) 
> non-compliant, or (b) low-security/low-quality?
> 
> I'm pushing for (b), while someone who insists the text be normative is 
> pushing for (a).

I'm pushing for neither. It's not the DKIM verifiers responsibility to enforce 
that.

I do think that an informative note observing "Here are a couple of issues that 
might theoretically be exacerbated by a DKIM-using world; you might consider 
checking for these problems somewhere in your mail handling path, if you aren't 
already" would be reasonable.

"Somewhere in your mail handling path" might be in the same binary as the DKIM 
validator, or it may not - and implying that an implementation that chooses to 
handle two entirely separate validation issues in two separate modules is 
"non-compliant" or "low-security" or "low-quality" doesn't seem helpful.

Cheers,
  Steve


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

Re: [ietf-dkim] double header reality check

[Douglas Otis]

On 10/20/10 3:19 PM, Murray S. Kucherawy wrote:
> []
> I totally agree that that's an important distinction to make, document, 
> highlight and shout from the rooftops.  But... Does it *have* to use RFC2119 
> normative language?
>
> Here's maybe a better way to frame the question: Should we empower ourselves 
> to label a DKIM implementation that doesn't do format enforcement as (a) 
> non-compliant, or (b) low-security/low-quality?
>
> I'm pushing for (b), while someone who insists the text be normative is 
> pushing for (a).
a) please.

In this case, "low quality" really means "misleading results".  Why are 
you reticent in adding obvious checks, that I am sure your code will 
include.  Not making this a MUST return PERMFAIL for multiple From 
header fields otherwise means DKIM results can never be trusted.  The 
results would not offer interchangeable implementations, since it is 
unreasonable to expect consumers of DKIM results will always make the 
relevant checks that might have been missed, or that SMTP will now 
suddenly alter its level of compliance checking.

This is really about checks that will consume only a few CPU cycles, 
since the information is already touched by the verification process.  
What is a few picoseconds between friends? :^)

-Doug


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

Re: [ietf-dkim] detecting header mutations after signing

[Douglas Otis]

On 10/20/10 8:10 AM, Ian Eiloart wrote:
>  --On 19 October 2010 11:35:53 -0400 "John R. Levine" 
>  wrote:
> >> True, but there already are UI designs that indicate when a From
> >> header is DKIM verified.
> >
> > So you're saying that all a spammer has to do is to put on a
> > throwaway domain's signature, and the MUA will highlight at least
> > parts of the message with green goodness? Surely our understanding
> > of domain reputation is better than that.
>
>  I believe that's the basis of this whole discussion, isn't it. The
>  point is that the MUA tells you whether the header was signed, and
>  leaves you to apply the domain or address reputation. I think that's
>  a step forward. At least, it is when I know the purported author.
>  And, surely I'm better at assigning reputation to -say- my brother
>  than any automated system is.

DKIM does not authenticate the From header field, however it provides 
authenticated DKIM domains that are, at a minimum, bound with the From 
header field.

When the DKIM domain is "Big-Bank.com", and you or your system trusts 
this domain, there should also be less concern related to whether a From 
header field containing "accou...@big-bank.com" offers deceptive 
information.

>  But, hey, I'm on your side here. I think we should put a warning in
>  the RFC so that vendors are informed that they need to be sure
>  they're highlighting the correct header.

Why?  There would not be a problem when DKIM verification results return 
PERMFAIL when there is any doubt which From header field might be 
selected when more than one exists.

-Doug

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

Re: [ietf-dkim] double header reality check

[Douglas Otis]

On 10/20/10 10:55 AM, Murray S. Kucherawy wrote:

>  I think a lot of this discussion conflates protocol specification
>  with implementation. I'm focused on the former. I maintain that
>  including wording intimating that a DKIM implementation is
>  non-compliant if it fails to do mail format validation prior to
>  accepting input or returning a result causes the specification not
>  to be clean. It's a layering violation. It's sloppy design. It
>  shouldn't be done.

Disagree.  Since DKIM /REQUIRES/, at minimum, the From header field be 
signed, are you suggesting layer violations when DKIM's verification 
process checks for non-compliant multiple From header fields?   It would 
be negligent of DKIM not to return a result of PERMFAIL when multiple 
 From header fields are detected.  Clean layering of a verification 
process is /not/ achieved when consumers of DKIM results must re-examine 
messages that receive a PASS result.

RFC5322 Section 6.4 amends the compliance required by SMTP, and removes 
strict enforcement.  There is not even a clearly defined error code to 
report non-compliance.  Since no layer below DKIM assures RFC5322 
compliance, it is negligent for the DKIM verification process to skip 
checks for multiple From header fields.   DKIM extends trust based upon 
the signing domain to include the From header field, as a minimum.  
Since normally there is no advantage obtained by introducing multiple 
 From header fields without the additional trust established by DKIM, it 
becomes fully incumbent upon DKIM to check for illegal conditions that 
might lead to erroneous placement of  trust.   Failure in this regard is 
likely to result in trust related exploitations.

>  The difference may be as subtle as what you're talking about above.
>  For example, although I am arguing that RFC4871bis shouldn't contain
>  any kind of normative enforcement of other specifications, my own
>  open source implementation already does it and has almost since day
>  one. I think that's the right thing to do, not because RFC4871 told
>  me to, but because RFC5322 did. And as a result, it's in the part
>  of the code that deals with mail, not the part that deals with DKIM.

Disagree.  DKIM MUST detect conditions that would allow trust 
established by DKIM to be exploited, where DKIM, at a minimum, includes 
the From header field.  Specifying a DKIM result for multiple From 
header fields impacts ONLY consumers of DKIM results.  This is not about 
enforcing RFC5322 compliance, this acknowledges that many processes 
assume there will be only a single From header field, as required by 
RFC5322.   Violation of this expectation prevents any DKIM status other 
than PERMFAIL to be safely returned.

>  It also does all kinds of validation that the data it got back from
>  the nameserver on a key or policy query conforms to the expected
>  format of a DNS query described in RFC1034, because if it doesn't
>  (which does happen sometimes, four so far today in the logs) then
>  running with those bits can have nasty side effects. But RFC4871
>  doesn't, and shouldn't, require that checking. That syntax is
>  defined in RFC1034.

DKIM Section 3.2 requires that tags with duplicate names *MUST NOT* 
occur within a single tag-list; if a tag name does occur more than once, 
the entire tag-list is to be considered invalid.  Because many had 
trouble with the format specified in Section 3.2 for tag values that are 
space delimited, many did not want to use the colon delimited structure 
specified in section 3.6.1.  Now many have decided to list the t= tag 
twice when adding the t=y value.  A similar problem also exists with the 
g= tag.  It is ironic that DKIM is having trouble ensuring strict format 
compliance for these unique DNS resource records.

RFC1034 clearly indicates valid results without expecting the consumers 
of DNS to second guess their validity.  However DKIM requires use of TXT 
resource records that are not required by SMTP.  An intrusion into DNS 
that is also being overlooked.  DKIM also specifies RFC3833 which warns 
against name chaining that also impacts the operation of DKIM validation.

>  Or are you folks also saying we should add text to RFC4871bis
>  mandating validation of the results returned by functions like
>  res_send()? Suppose a chthonic hacker could send DKIM-signed mail
>  that causes his DNS server to be queried, returning a reply that
>  will somehow always validate (or crash). And suppose res_send()
>  doesn't validate the payload, only passes it through to the caller.
>  Isn't this just as dangerous?

How would changing DKIM mitigate this type of threat?

>  We are most certainly obliged to emphasize to consumers of DKIM
>  output the distinction between what was covered by a signature and
>  what was not, and lay out the possibility that such consumers could
>  be confounded in the way that's been described. Failing to do so is
>  a disservice. I'm all for putting that into Security Consider

Re: [ietf-dkim] double header reality check

[Murray S. Kucherawy]

> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Wednesday, October 20, 2010 3:04 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] double header reality check
> 
> > Validating mail syntax belongs in the specification for the mail
> > components and DKIM work belongs in the DKIM components.
> 
> That's why, layer violation or no, I think it's important to distinguish
> between format errors that are likely to lead to misleading rendering in
> existing MUAs, and the much larger class that may produce nonsense but
> won't produce lies.

I think we're close to converging here.

I totally agree that that's an important distinction to make, document, 
highlight and shout from the rooftops.  But... Does it *have* to use RFC2119 
normative language?

Here's maybe a better way to frame the question: Should we empower ourselves to 
label a DKIM implementation that doesn't do format enforcement as (a) 
non-compliant, or (b) low-security/low-quality?

I'm pushing for (b), while someone who insists the text be normative is pushing 
for (a).


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

Re: [ietf-dkim] double header reality check

[John R. Levine]

> Validating mail syntax belongs in the specification for the mail 
> components and DKIM work belongs in the DKIM components.

Yes and no.

The problem for me is that in most situations only outgoing or relaying 
MSAs do format validation, and on incoming mail, some 5322 violations are 
considerably worse than others.  I've never seen a legit message with two 
>From or Subject headers, I've gotten plenty with a message-id with an 
extra at sign or a MIME-Type but no MIME-Version.  I can somewhat see 
inisisting on validating all of that before signing, to encourage people 
to clean up their sending software, but if you're that strict on 
verification, you're going to lose signatures on valid but sloppy mail.

That's why, layer violation or no, I think it's important to distinguish 
between format errors that are likely to lead to misleading rendering in 
existing MUAs, and the much larger class that may produce nonsense but 
won't produce lies.

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

Re: [ietf-dkim] double header reality check

[Michael Thomas]

On 10/20/2010 01:31 PM, Rolf E. Sonneveld wrote:
>On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote:
>> Seeing as the M in DKIM stands for Mail, we don't have to put a "but
>> only when used in the email context" clause. If a DKIM like approach is
>> used for other protocols then we might reasonably text specific to those
>> protocols - DKIH (Domain Keys Identified HTML as an example).
>
> Yep. Or other protocols will use parts of DKIM. Like with MIME
> (Multipurpose Internet /Mail/ Extensions); it has been used by other
> protocols as well.

Ages ago I, just for grins and giggles, implemented DKIM on SIP messages
mainly so that I could say that DKIM-on-SIP had been implemented, while
SIP-Identity (rfc 4474) had not. For all I know, that's still the case :)

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

Re: [ietf-dkim] What shows up with duplicated headers?

[Hector Santos]

John R. Levine wrote:
> Here's another batch of spam with extra From or Subject
> lines.  I see the same thing as last time, the extra
> subjects are all the same, and the extra From lines look
> like bugs, not attempts to evade filters.
> 
> The spam with 6,981 From lines is impressive in a wacky way.
> 
> R's,
> John
> 
> SNIP

wow!  I definitely have to pencil in time this weekend to scan the 
archives (I think I have some as far as 1998) to see how pervasive was 
this issue.

Good show john.

---
HLS



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

Re: [ietf-dkim] double header reality check

[Rolf E. Sonneveld]

  On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote:
>
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy
>> Sent: Wednesday, October 20, 2010 1:55 PM
>> To: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] double header reality check
>>
> 
>
>> There has been talk of applying DKIM to technologies like Usenet and
> HTTP
>> output.  Packing DKIM with mail-specific verification requirements
> could
>> prevent such things from happening.  Shall we also add a "but only
> when
>> used in the email context" clause?
>>
>
> Seeing as the M in DKIM stands for Mail, we don't have to put a "but
> only when used in the email context" clause. If a DKIM like approach is
> used for other protocols then we might reasonably text specific to those
> protocols - DKIH (Domain Keys Identified HTML as an example).

Yep. Or other protocols will use parts of DKIM. Like with MIME 
(Multipurpose Internet /Mail/ Extensions); it has been used by other 
protocols as well.

/rolf

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

Re: [ietf-dkim] What shows up with duplicated headers?

[John R. Levine]

Here's another batch of spam with extra From or Subject
lines.  I see the same thing as last time, the extra
subjects are all the same, and the extra From lines look
like bugs, not attempts to evade filters.

The spam with 6,981 From lines is impressive in a wacky way.

R's,
John

http://spample.iecc.com/oko/13513473 !!! from 2 subj 1
http://spample.iecc.com/mai/13527118 !!! from 1 subj 2 same
http://spample.iecc.com/wnq/13527333 !!! from 2 subj 1
http://spample.iecc.com/xdg/13644660 !!! from 2 subj 1
http://spample.iecc.com/ydd/13658310 !!! from 2190 subj 1
http://spample.iecc.com/yic/13695408 !!! from 1 subj 2 same
http://spample.iecc.com/gkj/13764008 !!! from 6981 subj 1
http://spample.iecc.com/joi/13772001 !!! from 2 subj 1
http://spample.iecc.com/sxt/13794463 !!! from 840 subj 1
http://spample.iecc.com/euf/13894583 !!! from 2 subj 1
http://spample.iecc.com/gix/13906201 !!! from 1 subj 2 same
http://spample.iecc.com/bds/13961106 !!! from 2 subj 1
http://spample.iecc.com/jha/14009391 !!! from 2 subj 1
http://spample.iecc.com/ptl/14009501 !!! from 1 subj 2 same
http://spample.iecc.com/ndg/14053973 !!! from 1 subj 2 same
http://spample.iecc.com/ddz/14108277 !!! from 1 subj 2 same
http://spample.iecc.com/pes/14209695 !!! from 2 subj 1
http://spample.iecc.com/kfd/14263497 !!! from 1 subj 2 same
http://spample.iecc.com/qdg/14263705 !!! from 1 subj 2 same
http://spample.iecc.com/eyp/14268312 !!! from 1 subj 2 same
http://spample.iecc.com/uib/14277824 !!! from 1 subj 2 same
http://spample.iecc.com/mcj/14278398 !!! from 1 subj 2 same
http://spample.iecc.com/rwz/14317049 !!! from 1 subj 2 same
http://spample.iecc.com/syi/14317050 !!! from 1 subj 2 same
http://spample.iecc.com/ewh/14337217 !!! from 1 subj 2 same
http://spample.iecc.com/keh/14349846 !!! from 1 subj 2 same
http://spample.iecc.com/jtl/14351633 !!! from 1 subj 2 same
http://spample.iecc.com/hqw/14360328 !!! from 1 subj 2 same
http://spample.iecc.com/slz/14363168 !!! from 1 subj 2 same
http://spample.iecc.com/oqu/14370756 !!! from 1 subj 2 same
http://spample.iecc.com/shu/14370764 !!! from 1 subj 2 same
http://spample.iecc.com/mqz/14390820 !!! from 1 subj 2 same
http://spample.iecc.com/dxb/14392591 !!! from 1 subj 2 same
http://spample.iecc.com/vcw/14393557 !!! from 1 subj 2 same
http://spample.iecc.com/gkj/14393579 !!! from 1 subj 2 same
http://spample.iecc.com/vef/14409312 !!! from 1 subj 2 same
http://spample.iecc.com/xus/14410639 !!! from 1 subj 2 same
http://spample.iecc.com/vta/14466945 !!! from 2 subj 1
http://spample.iecc.com/tvf/14477920 !!! from 1 subj 2 same
http://spample.iecc.com/nbq/14512851 !!! from 2 subj 1
http://spample.iecc.com/wbt/14514852 !!! from 977 subj 1
http://spample.iecc.com/muf/14519415 !!! from 385 subj 1
http://spample.iecc.com/thg/14542167 !!! from 2 subj 1
http://spample.iecc.com/scg/14542263 !!! from 2 subj 1
http://spample.iecc.com/bia/14572469 !!! from 1 subj 2 same
http://spample.iecc.com/hwd/14574906 !!! from 1 subj 2 same
http://spample.iecc.com/eeu/14595557 !!! from 2 subj 1
http://spample.iecc.com/wsf/14601350 !!! from 2 subj 1
http://spample.iecc.com/kyr/14602820 !!! from 2 subj 1
http://spample.iecc.com/hsg/14607445 !!! from 2 subj 1
http://spample.iecc.com/pva/14609226 !!! from 2 subj 1
http://spample.iecc.com/mur/14632131 !!! from 1 subj 2 same
http://spample.iecc.com/mua/14644824 !!! from 2 subj 1
http://spample.iecc.com/ych/14661976 !!! from 2 subj 1
http://spample.iecc.com/fuf/14689113 !!! from 1 subj 2 same
http://spample.iecc.com/dsd/14723463 !!! from 1 subj 2 same
http://spample.iecc.com/knx/14728696 !!! from 1 subj 2 same
http://spample.iecc.com/mux/14728748 !!! from 1 subj 2 same
http://spample.iecc.com/djd/14728829 !!! from 1 subj 2 same
http://spample.iecc.com/epb/14728832 !!! from 1 subj 2 same
http://spample.iecc.com/jdy/14740113 !!! from 1 subj 2 same
http://spample.iecc.com/mxi/14750851 !!! from 2 subj 1
http://spample.iecc.com/qbm/14754069 !!! from 1 subj 2 same
http://spample.iecc.com/yhz/14763567 !!! from 2 subj 1
http://spample.iecc.com/voc/14768732 !!! from 2 subj 1
http://spample.iecc.com/sal/14778601 !!! from 1 subj 2 same
http://spample.iecc.com/snw/14800456 !!! from 2 subj 1
http://spample.iecc.com/kzw/14805611 !!! from 2 subj 1
http://spample.iecc.com/kta/14837567 !!! from 1 subj 2 same
http://spample.iecc.com/cuw/14844705 !!! from 2 subj 1
http://spample.iecc.com/cwf/14844706 !!! from 2 subj 1
http://spample.iecc.com/paf/14884768 !!! from 1 subj 2 same
http://spample.iecc.com/qcz/14884769 !!! from 1 subj 2 same
http://spample.iecc.com/fpk/14887273 !!! from 1 subj 2 same
http://spample.iecc.com/eoz/14893324 !!! from 2 subj 1
http://spample.iecc.com/aas/14935218 !!! from 1 subj 2 same
http://spample.iecc.com/wcs/14935821 !!! from 2 subj 1
http://spample.iecc.com/dbf/14943578 !!! from 1 subj 2 same
http://spample.iecc.com/ndo/14949600 !!! from 1 subj 2 same
http://spample.iecc.com/ovs/14949602 !!! from 1 subj 2 same
http://spample.iecc.com/czc/14952912 !!! from 1 subj 2 same
http://spa

Re: [ietf-dkim] double header reality check

[Hector Santos]

MH Michael Hammer (5304) wrote:
> 
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy
>> Sent: Wednesday, October 20, 2010 1:55 PM
>> To: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] double header reality check
>>
> 
> 
> 
>> There has been talk of applying DKIM to technologies like 
>> Usenet and HTTP output.  Packing DKIM with mail-specific 
>> verification requirements could prevent such things from happening.  
>> Shall we also add a "but only when used in the email context" clause?

> Seeing as the M in DKIM stands for Mail, we don't have to put a "but
> only when used in the email context" clause. If a DKIM like approach is
> used for other protocols then we might reasonably text specific to those
> protocols - DKIH (Domain Keys Identified HTML as an example). 

I guess because we are already integrated with different mail formats, 
I don't see the difference other than having implementation specific 
setup features.

For example a signing setup with a target rule

 Signer Domain::Target Domain

where the association will enforce certain headers to be signed.

In the case of usenet (or nntp specifically), the considerations might be:

- enforce Path: header
- enforce (maybe) Newsgroups: header
- relaxed signing To: header (since its To: ALL for news)

But if you want to see how email is gated into public newsgroup areas, 
check out

 news://news.winserver.com

(use an anonymous account to login).

You will see how newsgroups are used for various list. One for the 
IETF-DRAFT submissions and other list areas shown as local public 
newsgroups.

One of interest where DKIM is used is the SPF-DISCUSS list/newsgroup 
where you can see the 10/17/2010 article titled:

   [spf-discuss] SPF Mail Summary Report

and if you view the message source and headers, you will see the 
Authorization-Results: header:

Authentication-Results: dkim.winserver.com;
   dkim=pass header.i=listbox.com header.d=listbox.com header.s=launch;
   adsp=fail policy=all author.d=winserver.com asl.d=listbox.com 
(unauthorized signer);
   dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=winserver.com 
header.d=winserver.com header.s=tms1;
   adsp=pass policy=all author.d=winserver.com signer.d=winserver.com 
(originating signer);

When our system generated the weekly Summary Report, it was DKIM 
signed and exported  to the spf-discuss mailing list. The list server 
than broke and resigned it and when the copy came back to us, it will 
DKIM verified and put into the newsgroup area.


-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


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

Re: [ietf-dkim] double header reality check

[MH Michael Hammer (5304)]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, October 20, 2010 1:55 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] double header reality check
> 



> 
> There has been talk of applying DKIM to technologies like Usenet and
HTTP
> output.  Packing DKIM with mail-specific verification requirements
could
> prevent such things from happening.  Shall we also add a "but only
when
> used in the email context" clause?
> 


Seeing as the M in DKIM stands for Mail, we don't have to put a "but
only when used in the email context" clause. If a DKIM like approach is
used for other protocols then we might reasonably text specific to those
protocols - DKIH (Domain Keys Identified HTML as an example). 

Mike

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

Re: [ietf-dkim] double header reality check

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Mark Delany
> Sent: Tuesday, October 19, 2010 5:53 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] double header reality check
> 
> > Any filter or agent that makes any kind of filtering, routing or
> > sorting decision based on any header field which in turn presumes
> > there's only one such field without actually checking is a potential
> > security concern.
> 
> I think this is a subtely different problem though.
> 
> All of the examples you cite (and all other pre-DKIM examples for that
> matter) are foolable with a single forged header today. That they
> could be further fooled with multiple headers is not an issue.
> 
> In a future world where such tools (and UAs) could act with authority
> because DKIM has assured the headers/payload is where we have the
> problem.
> 
> Only once tools and UAs take advantage of DKIM, do these attacks
> become relevant. That's why I think this is a DKIM problem. We are
> wanting tools and UAs to take advantage of DKIM but by doing so they
> are possibly making themselves more vulnerable to attackers.
> 
> [...]
> 
> IOW. Asking them to rely on DKIM is a backward step.

I do understand the difference.  And I am not ignorant to the fact that any 
mail system component that's offered some new trust mechanism which has 
inherent exposure risks is not likely to adopt that mechanism anytime soon.  
Plenty of examples exist, even in the email space, some of them fairly recent.

The job of a designer of such a mechanism (or any mechanism really) is twofold: 
(a) reduce risks as much as is practical, and (b) fully expose those that 
remain.  Both of these are easily accomplished by a specification that is clean 
and thorough.  Anyone who's shipped a product that can be tough to use knows 
that complete user documentation of the issues makes even a tricky product 
palatable to customers.  Forewarned is forearmed.

I think a lot of this discussion conflates protocol specification with 
implementation.  I'm focused on the former.  I maintain that including wording 
intimating that a DKIM implementation is non-compliant if it fails to do mail 
format validation prior to accepting input or returning a result causes the 
specification not to be clean.  It's a layering violation.  It's sloppy design. 
 It shouldn't be done.

The difference may be as subtle as what you're talking about above.  For 
example, although I am arguing that RFC4871bis shouldn't contain any kind of 
normative enforcement of other specifications, my own open source 
implementation already does it and has almost since day one.  I think that's 
the right thing to do, not because RFC4871 told me to, but because RFC5322 did. 
 And as a result, it's in the part of the code that deals with mail, not the 
part that deals with DKIM.

It also does all kinds of validation that the data it got back from the 
nameserver on a key or policy query conforms to the expected format of a DNS 
query described in RFC1034, because if it doesn't (which does happen sometimes, 
four so far today in the logs) then running with those bits can have nasty side 
effects.  But RFC4871 doesn't, and shouldn't, require that checking.  That 
syntax is defined in RFC1034.

Or are you folks also saying we should add text to RFC4871bis mandating 
validation of the results returned by functions like res_send()?  Suppose a 
chthonic hacker could send DKIM-signed mail that causes his DNS server to be 
queried, returning a reply that will somehow always validate (or crash).  And 
suppose res_send() doesn't validate the payload, only passes it through to the 
caller.  Isn't this just as dangerous?

We are most certainly obliged to emphasize to consumers of DKIM output the 
distinction between what was covered by a signature and what was not, and lay 
out the possibility that such consumers could be confounded in the way that's 
been described.  Failing to do so is a disservice.  I'm all for putting that 
into Security Considerations in intricate detail with lots of examples of 
possible exploits.  That, to me, is precisely why that section is mandated as 
part of all RFCs.  I will happily write a sesquipedalian treatise on this topic 
to be included there if it resolves this issue.

An aircraft comes with an operating handbook.  The manufacturer goes to great 
pains to make the aircraft as safe and secure as possible.  Ultimately, though, 
it's the pilot that crashes or lands, and thus learns the ins and outs of that 
particular aircraft by reading the ample documentation provided by the 
manufacturer before taking to the air.

No, Doug, I don't think these checks belong in POP3, or IMAP, or SIEVE.  They 
belong in whatever component is the one that decides when or whether seek or 
apply a DKIM result.  Like I said before, it should be perfectly reasonable for 
a protocol specification to require something proper from

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

[Douglas Otis]

On 10/20/10 7:27 AM, Alessandro Vesely wrote:
> On 20/Oct/10 13:23, Charles Lindsey wrote:
>> The scam I have described involves the use, by the phisher, of a
>> DKIM-signed (by himself) email with two From: headers, which is intended
>> to fool verifiers into not spotting that the first signature should have
>> triggered an ADSP lookup which would have revealed that the first From:
>> was 'discardable'.
>>
>> Naturally, the phisher signs with a throaway domain that has not yet
>> acquired any reputation, good or bad.
>>
>> Since the scam involves the use of DKIM, and since the only fix I am aware
>> of requires a change to the DKIM standard, then it is highly relevant to
>> the current discussion.
> IMHO, this issue has to be addressed refining the signing spec.  For
> example, the initial paragraph of section 5.4 could be modified so as
> to read:
>
> The From header field MUST be signed; that is, it MUST be included
> at least once in the "h=" tag of the resulting DKIM-Signature
> header field, and SHOULD be included twice (see Section 8.14).  In
> addition, the signer MUST ensure that at most one instance of the
> From field actually exists in the header.
>
> The current PS silently assumes that there is a single From, and I
> guess most interoperability and testing has been done in such
> conditions.  Hence an amendment like the text above can be understood
> as a clarification --rather than a change-- of the protocol.
>
> Verifiers would then discard any From field after the first one,
> whether signed or not.  Of course, a combo-verifier is always free to
> return some error due to bad message syntax, even if all signatures
> verify (although I'd consider it cleaner to return non-DKIM errors for
> non-DKIM failures.)
Alessandro,

While this represents a defensive posture that might be used prior to 
DKIM reliably returning PERMFAIL when multiple From header fields are 
contained within the message,  it only thwarts half of the threat 
created by multiple From header fields.   As both Charles and I have 
illustrated:

 From accou...@big-bank.com
 From some...@big-ips.com
Subject: Audit notification


This message could be sent directly, or distributed by replaying it to 
millions of recipients.

Nothing Big-Bank.com might do with their signing mitigates this variant 
of the double From header field attack.  The ONLY sure method is to 
ensure DKIM always returns PERMFAIL when multiple From header fields are 
detected, whether both or one of them are signed.

-Doug

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

Re: [ietf-dkim] detecting header mutations after signing

[John R. Levine]

> A reputation service can only say that a domain is
>BAD
>GOOD
> or NO EVIDENCE AVAILABLE EITHER WAY.
>
> I think the last case has to be treated pretty much like GOOD, otherwise
> newcomers to the internet will never even get their messages accepted.

Heck, no.  Treat it like there's no signature at all, and filter it like 
one does now.

I hope the difference between whitelisting and filtering doesn't require 
further explanation.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Wednesday, October 20, 2010 3:52 AM
> To: DKIM
> Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT
> records
> 
> >> By the way, has everyone tested their signing code to see what happens
> >> if there's no From: header at all?  Do we even agree what the right
> >> thing is?  I'd think it'd be approximately the same as if the private
> >> signing key (the only other mandatory input I can think of at the
> >> moment) wasn't present.
> >
> > OpenDKIM returns a syntax error in both cases.
> 
> And to complete the picture, what does it do when verifying?

I'm not sure what you think "both" meant, but I meant it as "when signing and 
when verifying".  I don't know of any other DKIM operating modes.

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

Re: [ietf-dkim] what do do with a signature, was detecting

[Ian Eiloart]

--On 20 October 2010 11:54:38 -0400 "John R. Levine"  wrote:

> [ I'm following this thread because it's related to advice in 4871 that
> we should probably remove from 4871bis ]
>
>>> So you're saying that all a spammer has to do is to put on a throwaway
>>> domain's signature, and the MUA will highlight at least parts of the
>>> message with green goodness?  Surely our understanding of domain
>>> reputation is better than that.
>>
>> I believe that's the basis of this whole discussion, isn't it. The point
>> is  that the MUA tells you whether the header was signed, and leaves you
>> to apply  the domain or address reputation. I think that's a step
>> forward. At least, it  is when I know the purported author.
>
> Hmmn.  You don't know the purported author, all you know is the actual
> signer.

I do know the *purported* author. It's right there in the From: header. 
DKIM tells me that it hasn't changed since it left the signer. My guess is 
that to get good reputation, domains won't be signing emails when that's 
spoofed. I know that we can't rely on that. YAHOO, for example, seem to be 
relaxed about their senders spoofing addresses. Hopefully they'll learn.

Even without changes in behaviour, I also know that a purported author in 
the yahoo.com domain is many times less likely to be spam if it has a valid 
DKIM signature from yahoo.com.

> We have a message offering you a job as an Internet Payment Processor.
> It's from recruitm...@reliable-home-work.com, and signed by
> reliable-home-work.com.  Do you paint it green and show it to your users?

Yes, because green doesn't mean this is a good email, it means this is 
really from that sender. You're then set to apply your personal reputation 
score to that sender.

> What if it was sent through gmail and had a google.com signature?

No, I wouldn't do that. I have no idea whether any MUAs would.

> How many of your users even know what a money mule is?

They have to be responsible for some stuff in life, but I certainly would 
not suggest that this should, would, or could replace spam filtering. All 
this has to be additional to what we already do, though it should permit 
more reliable whitelisting (say, of my brother's gmail.com address provided 
it was covered by a gmail.com signature).

> I think that if you look through papers at CEAS and similar fora, you'll
> find that manual classification of mail is not particularly accurate, and
> is a huge waste of time.  Well tuned filters do at least as good a job
> with far less human effort, and the reasonable things for humans to do is
> to tell the filtering engine when it guessed wrong either explicitly, or
> implicitly by moving stuff between inbox and junk folder.

Yes, I'm aware of all that.

>> And, surely I'm better at assigning reputation to -say- my brother than
>> any automated system is.
>
> Given the number of spam complaints I get about on-topic messages to COI
> discussion lists, don't count on it.  And in any event, unless your
> brother is one of us weenies with his own vanity domain, his mail is
> going to be signed by his employer or his ISP, so he won't have his own
> mailstream reputation anyway.
>
> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. http://jl.ly



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


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

Re: [ietf-dkim] detecting header mutations after signing

[Ian Eiloart]

--On 19 October 2010 11:35:53 -0400 "John R. Levine"  wrote:

>> True, but there already are UI designs that indicate when a From header
>> is  DKIM verified.
>
> So you're saying that all a spammer has to do is to put on a throwaway
> domain's signature, and the MUA will highlight at least parts of the
> message with green goodness?  Surely our understanding of domain
> reputation is better than that.

I believe that's the basis of this whole discussion, isn't it. The point is 
that the MUA tells you whether the header was signed, and leaves you to 
apply the domain or address reputation. I think that's a step forward. At 
least, it is when I know the purported author. And, surely I'm better at 
assigning reputation to -say- my brother than any automated system is.

But, hey, I'm on your side here. I think we should put a warning in the RFC 
so that vendors are informed that they need to be sure they're highlighting 
the correct header.

> Any chance you can tell me which MUAs have this misfeature, so I can tell
> people to return them and ask for a refund?
>
> R's,
> John



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


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

Re: [ietf-dkim] detecting header mutations after signing

[Ian Eiloart]

--On 19 October 2010 07:31:58 -0700 Michael Thomas  wrote:

> On 10/19/2010 06:18 AM, Wietse Venema wrote:
>> valid signature + good signer
>> + no suspicious unsigned content ->  good message
>
> Has nobody learned that "good" signers from "good" authors
> can still be evil? I mean come on, people, bot'd machines? This
> is horrible advice.
>
> s/unsigned/; and this works.
>
> Mike

Well, everything's relative. If we can get to the point where a bot'd 
machine can only send email "From:" it's real owner, that'll be a huge 
improvement on the current situation. At that point, we can start to 
pressure the real owner into fixing their machine (say, by emailing them or 
their domain support, or by blacklisting their email)

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


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

Re: [ietf-dkim] what do do with a signature, was detecting

[John R. Levine]

[ I'm following this thread because it's related to advice in 4871 that we 
should probably remove from 4871bis ]

>> So you're saying that all a spammer has to do is to put on a throwaway
>> domain's signature, and the MUA will highlight at least parts of the
>> message with green goodness?  Surely our understanding of domain
>> reputation is better than that.
>
> I believe that's the basis of this whole discussion, isn't it. The point is 
> that the MUA tells you whether the header was signed, and leaves you to apply 
> the domain or address reputation. I think that's a step forward. At least, it 
> is when I know the purported author.

Hmmn.  You don't know the purported author, all you know is the actual 
signer.

We have a message offering you a job as an Internet Payment Processor. 
It's from recruitm...@reliable-home-work.com, and signed by 
reliable-home-work.com.  Do you paint it green and show it to your users? 
What if it was sent through gmail and had a google.com signature?  How 
many of your users even know what a money mule is?

I think that if you look through papers at CEAS and similar fora, you'll 
find that manual classification of mail is not particularly accurate, and 
is a huge waste of time.  Well tuned filters do at least as good a job 
with far less human effort, and the reasonable things for humans to do is 
to tell the filtering engine when it guessed wrong either explicitly, or 
implicitly by moving stuff between inbox and junk folder.

> And, surely I'm better at assigning reputation to -say- my brother than 
> any automated system is.

Given the number of spam complaints I get about on-topic messages to COI 
discussion lists, don't count on it.  And in any event, unless your 
brother is one of us weenies with his own vanity domain, his mail is going 
to be signed by his employer or his ISP, so he won't have his own 
mailstream reputation anyway.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] detecting header mutations after signing

[Ian Eiloart]

--On 20 October 2010 15:12:47 +0100 Charles Lindsey  
wrote:

>
>> When I said good, I meant credible, not just one that mechanically
>> validates.  I hope that we all agree that a signature from a domain about
>> which one knows nothing is not usefully different from no signature at
>> all.
>
> A reputation service can only say that a domain is
> BAD
> GOOD
> or NO EVIDENCE AVAILABLE EITHER WAY.
>

Actually, a reputation service could offer a score that's more subtle than 
good/bad.

And, it could offer address reputation rather than domain reputation. That 
would be far more suitable for domains like the large email service 
providers, which have a mix of good and bad users.

 offers address based reputation 
service. I've not used the service, so can't vouch for it.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


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

Re: [ietf-dkim] Data integrity claims

[Charles Lindsey]

On Mon, 18 Oct 2010 20:18:16 +0100, Murray S. Kucherawy  
 wrote:

>> This is no more presumptuous than expecting that MUAs will adapt to
>> consume the output of DKIM as it stands now.
>
> In another message I indicated that I don't presume either, but assert  
> that there's no middle ground; they will or they won't.  If they will,  
> informative text is sufficient; if they won't, then we have to start  
> hardening MTAs to defend against MUA attacks because that's where header  
> changes and other enforcements are possible since, by definition, any  
> current annotations are invisible and will stay that way.
> I'm fine with accepting either model, but we have to understand the  
> implications of picking one.  The latter, in particular, involves some  
> major scope creep.

No it doesn't. I believe they "won't" (at least not on any short enough  
timescale). But we are already in the "hardening" business, because the  
basic assumption made by DKIM was that the verification (and resulting  
action) could and would be done at the boundary layer as part of, or  
closely associated with, the final MTA, and without any change to existing  
MUAs.

What options for 'action' are available at that point (or were envisaged  
as being available at that point when DKIM was first written)? I can think  
of

discarding (silently or noisily)
increased spamassassin score
warning to the end user (e.g. in a changed Subject header)

So all we need is to ensure that those same actions will be activated by  
this new threat; in which case the language to bring this about needs to  
be just as normative as in the rest of the DKIM specification.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Protecting messages, not MUAs, MTAs, or anything else

[Charles Lindsey]

On Tue, 19 Oct 2010 01:32:29 +0100, Hector Santos  wrote:

> John R. Levine wrote:
>
>> So, uh, can we agree that Jim's SHOULD language to tell people to do
>> this is a good idea?
>
> Yes. +1.  I think I was the first to agree with Jim's input and didn't
> see much follow up except you and maybe another person.
>
> Maybe Barry can provide a repeat of the exact change proposal and get
> a preliminary show of hands.

I would say +1, but only if it was a MUST rather than a SHOULD (which I  
think it can be provided you do not ask for excessively meticulous 5322  
checks).

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] detecting header mutations after signing

[Charles Lindsey]

On Tue, 19 Oct 2010 14:18:45 +0100, Wietse Venema   
wrote:

> My preference would be to enforce this within the existing protocol
> (that is: send h=from:from:subject:subject...),

But that only copes with some of the scams that are possible; for full  
protection you need

> ... but I could live
> with hard-coded checks for unsigned single-instance RFC 5322 and
> MIME headers (that is: no DKIM PASS for unsigned "extra" From,
> Subject, MIME-Version, Content-type, etc.  headers).

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] detecting header mutations after signing

[Charles Lindsey]

On Tue, 19 Oct 2010 16:23:39 +0100, John R. Levine  wrote:

>>   good signature -> good message.
>>
>> Don't you mean
>>
>>  Good signature -> authenticated message (that is, someone
>> accepts responsibility)

I think it needs to mean

Good signature -> authenticated message (that is, someone accepts  
responsibility, where "someone" is identifiable at least to the extent of  
being or not being  the domain in whatever From: is shown).
>
> When I said good, I meant credible, not just one that mechanically
> validates.  I hope that we all agree that a signature from a domain about
> which one knows nothing is not usefully different from no signature at
> all.

A reputation service can only say that a domain is
BAD
GOOD
or NO EVIDENCE AVAILABLE EITHER WAY.

I think the last case has to be treated pretty much like GOOD, otherwise  
newcomers to the internet will never even get their messages accepted.

There might be some merit in a repuation service responding with
DOMAIN CREATED WITHIN THE LAST 15 MINUTES
although even that should have been "Domain first used within the last 15  
minutes", except I cannot see how a reputation service coulr know that.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

[Alessandro Vesely]

On 20/Oct/10 13:23, Charles Lindsey wrote:
> On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy
>   wrote:
>>  These topics are distractions from the effort of solidifying the DKIM
>>  specification for advancement along the standards track.  That's what I
>>  believe he means by "irrelevant for the current discussion".
>
> The scam I have described involves the use, by the phisher, of a
> DKIM-signed (by himself) email with two From: headers, which is intended
> to fool verifiers into not spotting that the first signature should have
> triggered an ADSP lookup which would have revealed that the first From:
> was 'discardable'.
>
> Naturally, the phisher signs with a throaway domain that has not yet
> acquired any reputation, good or bad.
>
> Since the scam involves the use of DKIM, and since the only fix I am aware
> of requires a change to the DKIM standard, then it is highly relevant to
> the current discussion.

IMHO, this issue has to be addressed refining the signing spec.  For 
example, the initial paragraph of section 5.4 could be modified so as 
to read:

   The From header field MUST be signed; that is, it MUST be included
   at least once in the "h=" tag of the resulting DKIM-Signature
   header field, and SHOULD be included twice (see Section 8.14).  In
   addition, the signer MUST ensure that at most one instance of the
   From field actually exists in the header.

The current PS silently assumes that there is a single From, and I 
guess most interoperability and testing has been done in such 
conditions.  Hence an amendment like the text above can be understood 
as a clarification --rather than a change-- of the protocol.

Verifiers would then discard any From field after the first one, 
whether signed or not.  Of course, a combo-verifier is always free to 
return some error due to bad message syntax, even if all signatures 
verify (although I'd consider it cleaner to return non-DKIM errors for 
non-DKIM failures.)

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

Re: [ietf-dkim] double header reality check

[Mark Delany]

On Wed, Oct 20, 2010 at 01:41:03AM -0700, SM allegedly wrote:
> At 17:53 19-10-10, Mark Delany wrote:
> >In a DKIM world a list server could reasonable use DKIM to bypass this
> >"confirm" sequence and make your life a bit simpler. Perhaps it relies
> >on Authentication-Results or somesuch. In any event such a list server
> >is actually *more* vulnerable than it is today if we let thru bogus
> >payload that appear to be valid.
> 
> According to Section 7 of RFC 5672:
> 
>"For DKIM processing, the domain name portion of the AUID has
> only basic domain name semantics; any possible owner-specific
> semantics are outside the scope of DKIM."
> 
> Furthermore, in Section 8:
> 
>"A module that consumes DKIM's mandatory payload, which is the
> responsible Signing Domain Identifier (SDID).  The module is
> dedicated to the assessment of the delivered identifier.  Other
> DKIM (and non-DKIM) values can also be delivered to this module as
> well as to a more general message evaluation filtering engine.
> However, this additional activity is outside the scope of the DKIM
> signature specification."
> 
> Based on the above, I don't think that a list server could use DKIM 
> to bypass the "confirm" sequence.

Well, that's "should". It also assumes that all subsequent users of
DKIM bother to read and obey. It also assumes that future users of
DKIM won't get inventive and use DKIM in ways that we can't even
imagine. I think that undersells DKIM and future users.

Just ask the inventors of DNS whether they thought we'd be using it
the way we are... or whether we're using it the way they intended.


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

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

[Charles Lindsey]

On Mon, 18 Oct 2010 18:06:14 +0100, Murray S. Kucherawy  
 wrote:

>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org  
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine
>> Sent: Friday, October 15, 2010 7:14 PM
>> To: ietf-dkim@mipassoc.org
>> Cc: dcroc...@bbiw.net
>> Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
>>
>> By the way, has everyone tested their signing code to see what happens
>> if there's no From: header at all?  Do we even agree what the right
>> thing is?  I'd think it'd be approximately the same as if the private
>> signing key (the only other mandatory input I can think of at the
>> moment) wasn't present.
>
> OpenDKIM returns a syntax error in both cases.

And to complete the picture, what does it do when verifying?

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

[Charles Lindsey]

On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy  
 wrote:

>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org  
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Monday, October 18, 2010 4:24 AM
>> To: DKIM
>> Subject: Re: [ietf-dkim] layer violations, was detecting header  
>> mutations after signing
>>
>> > Irrelevant for the current discussion.
>>
>> On the contrary, that is precisely the attack of interest, so it is
>> supremely relevant. You claim it can be thwarted by other means, but  
>> have
>> failed to explain exactly how those "other means" would work.
>
> On the contrary, none of this is within the prescribed scope of DKIM.   
> ADSP and reputation (the latter of which is explicitly out of scope) are  
> predicated on DKIM's output, not part of its input or its mechanics.
>
> These topics are distractions from the effort of solidifying the DKIM  
> specification for advancement along the standards track.  That's what I  
> believe he means by "irrelevant for the current discussion".

The scam I have described involves the use, by the phisher, of a  
DKIM-signed (by himself) email with two From: headers, which is intended  
to fool verifiers into not spotting that the first signature should have  
triggered an ADSP lookup which would have revealed that the first From:  
was 'discardable'.

Naturally, the phisher signs with a throaway domain that has not yet  
acquired any reputation, good or bad.

Since the scam involves the use of DKIM, and since the only fix I am aware  
of requires a change to the DKIM standard, then it is highly relevant to  
the current discussion.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] double header reality check

[SM]

At 17:53 19-10-10, Mark Delany wrote:
>In a DKIM world a list server could reasonable use DKIM to bypass this
>"confirm" sequence and make your life a bit simpler. Perhaps it relies
>on Authentication-Results or somesuch. In any event such a list server
>is actually *more* vulnerable than it is today if we let thru bogus
>payload that appear to be valid.

According to Section 7 of RFC 5672:

   "For DKIM processing, the domain name portion of the AUID has
only basic domain name semantics; any possible owner-specific
semantics are outside the scope of DKIM."

Furthermore, in Section 8:

   "A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID).  The module is
dedicated to the assessment of the delivered identifier.  Other
DKIM (and non-DKIM) values can also be delivered to this module as
well as to a more general message evaluation filtering engine.
However, this additional activity is outside the scope of the DKIM
signature specification."

Based on the above, I don't think that a list server could use DKIM 
to bypass the "confirm" sequence.

Regards,
-sm 

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