Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

[Michael Thomas]

On 02/11/2018 06:20 PM, Dave Crocker wrote:

On 2/11/2018 5:54 PM, Michael Thomas wrote:

You clearly have no idea what you are talking about.

Mike

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




Mike,

Please review the participation rules applicable to this list. They 
are the same as you had so much trouble with, previously.


Then please consider unsubscribing, since restraint within the bounds 
of professional behavior appears to (continue to) be absent from your 
repertoire.


d/



Sorry, you don't know what you are talking about. I wrote code every day 
for a living. I wrote the first implementation of DKIM, followed
very quickly by Murray's. I know what I'm talking about here. You 
don't.  When is the last time you've written code? This is all very silly

to me, and your impugning my 30+ years of experience is a joke.

Mike

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

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

[Michael Thomas]

On 02/11/2018 05:46 PM, Dave Crocker wrote:

On 2/10/2018 10:47 AM, Michael Thomas wrote:
But I still think this entire conversation is silly in its 
theoreticality.



Extra design complexity and consuming development resources -- 
programming, bench testing, interoperability testing -- for something 
that is not essential, nevermind offers no actual value, is about as 
practical as any standards issue can get.


Protocol complexity matters, especially for features that have no 
immediate use.


d/

You guys have already spent 10 times the amount of effort prattling on 
about these theoretical differences than any amount
of supposed savings for us poor, poor programming types. You clearly 
have no idea what you are talking about.


Mike

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

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

[Michael Thomas]

On 02/10/2018 10:22 AM, Dave Crocker wrote:

On 2/10/2018 10:12 AM, Michael Thomas wrote:

DKIM-Signature-v2: vs DKIM-Signature: v=2;

Angels, meet the pinhead.


equal semantics does not mean equal implementation.  the processing 
for each of these takes place in very different parts of the system.  
the latter requires new code, albeit internal to the DKIM module.  the 
former merely requires a new table entry.


I don't know when the last time you've written a line of code (my last 
time was about 5 minutes ago), but this is just silly.
It makes not a particle of difference code-wise, but it would require 
reconfiguration of the mailer configurations for a new
header. I'll take that back, code-wise. My assumption is that the actual 
header is passed into the DKIM library. If that's not
true, it would be more work vs. v=2. But I still think this entire 
conversation is silly in its theoreticality.


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

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

[Michael Thomas]

On 02/10/2018 10:04 AM, Dave Crocker wrote:

On 2/10/2018 9:47 AM, John R Levine wrote:
Well, OK, other than DKIM-Improved-Signature how would you do 
conditional signatures, where the signature has to fail if the 
semantics of the re-sign tag aren't satisified?  Remember that the 
current rule is that verifiers ignore tags they don't understand.


The current point of departure into DKIM is by the header field name. 
So I'm not sure why 'other than' is being queried, since it's the 
natural, existing point for going to a different protocol.


Different protocol?  Yes.  Current DKIM does not require support for 
unrecognized tags, beyond the initial set.  You want to require 
support for additional tags.  That's a fundamental change; so it isn't 
'DKIM'. It's something different.


DKIM-Signature-v2: vs DKIM-Signature: v=2;

Angels, meet the pinhead.

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

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

[Michael Thomas]

On 2/8/18 4:45 PM, Dave Crocker wrote:

On 2/8/2018 4:42 PM, Michael Thomas wrote:
Besides if you wanted to go from DKIM to EKIM, you'd be opening 
pandora's box imo.



The pandora's box is creating an incompatible new version.  All the 
rest is just engineering and operations tradeoffs.


Thankfully nobody's seriously talking about that from what i can tell, 
so this strikes me as so many angels on a pinhead.


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

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

[Michael Thomas]

On 2/8/18 12:32 PM, Mark Delany wrote:

I think this is the biggest flaw with the whole v= rationale. There is never
going to be a v=2 change that doesn't leave everyone continuing to
generate/validate a v=1 header. Is a new header by stealth better engineering
than formalizing a new header?

I dunno, it's not like there isn't precedent for this. oh say, like ipv4 
vs. ipv6?


Besides if you wanted to go from DKIM to EKIM, you'd be opening 
pandora's box imo.


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

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

[Michael Thomas]

On 11/15/16 11:57 AM, Murray S. Kucherawy wrote:
On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten 
mailto:mart...@lapsedordinary.net>> 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.


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?

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

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

[Michael Thomas]

On 11/15/2016 11:17 AM, Martijn Grooten wrote:

On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote:

Not at all.  As I understand the scenario, the provider knows it's
bad, doesn't send the mail on to the outside world, but still gives a
signed copy back to the originator (which is then available for
replay).

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.



That's not how i read it, but even if it was it would still require the 
mail be signed by a provider which presumably should pass judgment on it
to decide to sign or not. If they signed something bad, they own the 
ding on their reputation, or whatever.


It's not like you can change the bits in the mail once they're signed 
and still keep a valid signature, so I'm not seeing what the problem is 
here.


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

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

[Michael Thomas]

On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote:
On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany > wrote:


Hi Murray.


Mark!

> RFC6376 and even RFC4871, but now it's apparently happening

I'd be interested to hear about the actual scenarios. Are the targeted
users somehow given an indication that the email verifies and it's
from a credible domain and yet it contains a malevolent payload?


As I understand the attack:

Spammer tries to send spam to a victim.  The MSA blocks this because 
it's spam.  However, the spam filter is not applied to mail sent by 
the spammer to itself, because why would that be a problem?  So the 
spammer sends itself a piece of spam, which the MSA dutifully signs.  
Then the spammer downloads that message and remails it using whatever 
envelope it likes.  The signature will continue to validate, carrying 
the reputation of the signing domain through any whitelist or other 
system that says this signer tends to send good mail.




This sounds like a misconfiguration problem.It's a problem because it's 
$spam/$malware/$bad regardless of who the recipient is.


The rule is: if you think it's bad, don't sign it. If you sign it, you 
own it.


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

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

[Michael Thomas]

On 10/20/2013 06:35 AM, Barry Leiba wrote:
> This one's right, of course: no one uses "v=DKIM1"; it's always "v=1".
>   Authors, was this just left in from the "transition from DK" days?

Hmm, my implementation (the first) has it as DKIM1. That says that it's been
that way for a long time. Iirc, DK didn't have a version tag. I wouldn't 
count
on any sort of consistency here -- what it does say is that it's most likely
not being enforced though.

Mike


>
> Barry
>
> On Sun, Oct 20, 2013 at 8:01 AM, 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&eid=3758
>>
>> --
>> Type: Technical
>> Reported by: Majid Tajamolian & Nazilla Karkon 
>>
>> Section: 3.6.1.
>>
>> Original Text
>> -
>> v= Version of the DKIM key record (plain-text; RECOMMENDED, default
>>is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
>>(without the quotes).  This tag MUST be the first tag in the
>>record.  Records beginning with a "v=" tag with any other value
>>MUST be discarded.  Note that Verifiers must do a string
>>comparison on this value; for example, "DKIM1" is not the same as
>>"DKIM1.0".
>>
>> Corrected Text
>> --
>> v= Version of the DKIM key record (plain-text; RECOMMENDED, default
>>is "1").  If specified, this tag MUST be set to "1"
>>(without the quotes).  This tag MUST be the first tag in the
>>record.  Records beginning with a "v=" tag with any other value
>>MUST be discarded.  Note that Verifiers must do a string
>>comparison on this value; for example, "1" is not the same as
>>"1.0".
>>
>> Notes
>> -
>> The "DKIM" prefix in the version field is unnecessary.
>> for example the followings are snipped from an actual email via gmail.com:
>>
>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>>  d=gmail.com; s=20120113;
>>  h=mime-version:from:date:message-id:subject:to:content-type;
>>  bh=46j07/8gDec8jTto/znsrAKiXDj6YJ7Wa2DCoZuhwXc=;
>>  b=h6SViP6DcHgPwydJD6aztqyKd0UmCN3SdwmqZd0uCHmqrprphjN8qQ8AnBDhbwDhAa
>>   
>> DfHIDS8RSegELKtzsp95u+DnIFg1uNhIukKVpGT+9MqxfCSAFk7WpMe2O/2gcLruilTe
>>   
>> MxkKJ29s64NGevYewKtI8s73xHmbzD1NFH9ugdow8i9E16kgQ+vAx56qvbFTBwdEEw8I
>>   
>> 6Bteu3tXEsYYbU/9Akm2GXS+6PFiDSbv47u3EmhRQIOK3e8DvcobrpicjL7vUwBCpQuf
>>   
>> J/c+Acdq4GZQoMoG9imzku0K2o0w33CZ1xUR1bARJKCVaJfWeHiEMQ2OJ9A6ZtqpyK0z
>>   1Ftg==
>>
>> Instructions:
>> -
>> This errata 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] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

[Michael Thomas]

On 9/11/13 8:18 PM, MH Michael Hammer (5304) wrote:
>
> I think you need to look more closely. Many people realized very quickly that 
> ADSP had significant flaws that made implementation extremely risky for both 
> senders and mailbox providers. There were a number of private efforts to move 
> email authentication forward. DMARC was only one of them. Some of those 
> private efforts were premised on a pay-to-play model. DMARC was premised on 
> creating an open standard that worked instead of a private club. A number of 
> the participants in DMARC.org were also active participants in the ADSP 
> discussions. We all learned from operational experience interacting through 
> private channels. The problems with ADSP and how to move past them were 
> certainly a point of discussion (in all the groups I participated in - how 
> could it not be?). The initial attempts were one-on-one pairs of senders and 
> receivers and it was very quickly realized that a standard way of 
> communicating and reporting was needed. ADSP never had reporting on the radar 
> screen and al!
 ignment with SPF wasn't a factor either.
>
>

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.

Mike


___
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

[Michael Thomas]

On 9/12/13 12:10 PM, Murray S. Kucherawy wrote:
> On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas  <mailto: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?

That we pissed away 6 years for no good reason.

Mike
___
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

[Michael Thomas]

On 9/11/13 9:32 PM, Dave Crocker wrote:
> On 9/11/2013 6:41 PM, Michael Thomas wrote:
>> It doesn't help that ADSP's author actively wanted to subvert it.
>>
>> As far as I can tell, DMARC is warmed over ADSP with a different set of 
>> participants
>> to claim credit for their original ideas.
>
>
> I don't understand how these assertions are at all relevant to this thread, 
> nor the first at all within IETF participation guidelines.

Ho hum, Dave Crocker threatening to get me kicked off working groups again even
if the sentence doesn't actually make any sense.  It still doesn't alter the 
fact that
he was against it until he was for it.

Mike, credit grabbers, feh.
___
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

[Michael Thomas]

On 9/11/13 6:15 PM, Murray S. Kucherawy wrote:
> 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.

It doesn't help that ADSP's author actively wanted to subvert it.

As far as I can tell, DMARC is warmed over ADSP with a different set of 
participants
to claim credit for their original ideas.

Mike

>
> -MSK
>
>
> On Wed, Sep 11, 2013 at 5:46 PM, Terry Zink  > wrote:
>
> 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 mailto:dcroc...@bbiw.net>>
> Organization: Brandenburg InternetWorking
> To: Barry Leiba  >,  Pete Resnick 
>  >
>
> Folks,
>
> This is a formal request, to have DomainKeys Identified Mail (DKIM) 
> Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.
>
> It has garnered almost no deployment and use, in the 4 years since its 
> advancement to IETF Proposed Standard.
>
> In addition, newer work, DMARC, covers the same general email functional 
> area and already has garnered quite a bit of deployment and use. Hence
> it will clarify things for the marketplace to remove standards status 
> from the apparently-competing, but actually-useless ADSP specification.
>
> Today I sent a query to the MAAWG Technical committee and the IETF DMARC 
> mailing lists, to assess support for the status change. Within only a
> few hours, I've already seen quite a few +1s, and no -1s.
>
> Thanks.
>
>
> d/
>
> --
> 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

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

Re: [ietf-dkim] Weird i= in client mail

[Michael Thomas]

On 06/18/2013 07:18 AM, Tony Hansen wrote:
> On 6/18/2013 12:43 AM, Dave Crocker wrote:
>> On 6/17/2013 9:20 PM, Franck Martin wrote:
>>> On Jun 17, 2013, at 8:58 PM, John Levine  wrote:
> At one stage i= was thought to represent different mail streams with 
> different reputation,
> however this did not get any traction...
>> ...
>>> The question was raised and dispelled 
>>> onhttp://blog.wordtothewise.com/2007/10/dkim-i-equal-vs-d-equal/, proving 
>>> the idea was in the air, and I read it in some deliverability documents in 
>>> the early days (tho wrong too)...
>> As I said, there were a variety of intentions, descriptions, desires and
>> claims for i=.  Different people had different views.  None of the
>> alternatives was in the spec and therefore none were standardized.
>
> Yes, it was an unfortunate turn of events that wasn't discovered until it was 
> rather late in the game, so we wound up punting on the issue of what should 
> be in the i= value and essentially said that it was an opaque value that was 
> site dependent.

It was known really early on, it's just that some people wanted to wait 8 years 
to
do the work.

Mike
___
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

[Michael Thomas]

On 07/23/2012 06:13 AM, Barry Leiba wrote:
>> 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."
>
> 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=.
>

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

Mike

Mike
___
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

[Michael Thomas]

On 07/23/2012 06:47 AM, Murray S. Kucherawy wrote:
> On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas  <mailto: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.

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

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

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

[Michael Thomas]

On 05/25/2011 01:05 AM, Murray S. Kucherawy wrote:
> 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.
>

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.

Mike

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

Re: [ietf-dkim] Certifying the DKIM public key?

[Michael Thomas]

On 05/23/2011 11:17 AM, Dave CROCKER wrote:
> As an impressive example of even deeper misunderstanding:
>

More of CROCKER's famed civility.

>> On 5/22/2011 10:49 AM, Michael Thomas wrote:
>>  
>>> But this is exactly what DKIM is. You prove yourself fsvo "prove"
>>> to the registrar who "certifies" you by virtue of placing your NS
>>> records in the root servers instead of issuing a cert. Nothing
>>> different in *essence* to x.509 certs.
>>>
> DKIM has almost literally nothing to do with proofs made to a DNS registrar.
> For example, it says nothing about the relationship between a domain name and 
> a
> brand or company name.
>

Where exactly did I say anything about a "brand" or a "company"?
Oh, I didn't.

> DKIM merely says that who ever owns use of a domain name is asserting "some"
> responsibility for the signed message.
>

Yes, and the way that they got to "assert" that was by convincing
a registrar to allow them to create and maintain NS records in the
root servers.

> In extremely abstract terms, a DKIM signature relates to a reasonably constant
> construct that one might call an "identity" but it does not label the 
> identity,
> except with the domain name.
>

A domain name is an identity. RFC4871 calls it the signing identity.

> More importantly, there are none of the claims, assertions or endorsements 
> that
> go along with Certs, except for the mild one noted above.
>

Assertion of identity is "mild"? It's the *key* assertion.

> One would have expected a former author of the spec who so-often proclaims 
> their
> expertise to understand the semantics of DKIM better.  On the other hand, it
> does nicely show that implementing code doesn't mean understanding what it is 
> for...
>

I'm not a "former" author.  But thanks for the smear anyway.

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

Re: [ietf-dkim] Certifying the DKIM public key?

[Michael Thomas]

On 05/22/2011 10:27 AM, John R. Levine wrote:
> It occurs to me that since mail certification is likely to make assertions
> about behavior as well as identity, the SSL model in which certs last for
> a year won't work, since behavior can change rapidly.  Either the
> certifier has to issue a stream of short-term certs to everyone it
> certifies, or the verifiers have to check CRLs, which is tedious.  By the
> time you do all that, a DNS check, even one with DNSSEC, looks pretty
> attractive.
>
>

But this is exactly what DKIM is. You prove yourself fsvo "prove"
to the registrar who "certifies" you by virtue of placing your NS
records in the root servers instead of issuing a cert. Nothing
different in *essence* to x.509 certs. The "advantage" that
x.509-style certs have is that you can verify them offline. Except
when you factor in CRL's which in any reasonable scheme you
must do. So yes, DKIM saves quite a bit of overhead by not
caring about the problematic offline verification problem.

There's really not a need of yet another certifier that I can see:
if your DNS is compromised, you have far, far larger problems than
DKIM.

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

Re: [ietf-dkim] Certifying the DKIM public key?

[Michael Thomas]

On 05/22/2011 08:02 AM, Dave CROCKER wrote:
>
> 3. As noted, certification was explicitly de-coupled from DKIM.  I'll claim 
> that
> it really is a separate, value-added service and any support of it should be
> through a separate, value-added mechanism.  My own preference would be for 
> using
> a special header-field that contains the cert, with the specification of using
> such certs as saying that they are enabled when included in the set of h=
> covered header fields.
>

Well, x.509 style certification certainly was. But using DNS is a
form of certification which is arguably not much worse than going
to godaddy and proving that you can receive email from the domain
or whatever weak tests they use to establish that you have control
of the domain. The weak part of DKIM/DNS chain isn't the certification
part (if you believe that godaddy et al aren't problematic), it's the
lack of data integrity in the transport of the dkim rr. Which can
be solved with DNSSEC.

Given how problematic x509 has been for people to get their heads
around, I think that DKIM has done a service in providing an
alternative mechanism/trust root for establishing identity
that is workable and especially with its solution to the revocation
problem.

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

Re: [ietf-dkim] 8bit downgrades

[Michael Thomas]

On 05/19/2011 07:20 PM, John Levine wrote:
>> 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.
>>  
> I think Pete's analysis is correct, but my advice would be to take
> it out altogether.  We don't have any great insight into the warts
> of what paths are likely to downcode a message and what paths aren't,
> so I would prefer not to purport to offer advice about it.
>

Miracles... my implementation never bothered to worry about
that SHOULD and I don't feel dirty about it in the least: it
never made any difference that I could determine. This
was mostly an academic piece of advice, IMO. Since dev
managers literally looks at MUST's and SHOULD and ignore
MAY's to determine what gets implemented, this is not
quite as academic.

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

Re: [ietf-dkim] 8bit downgrades

[Michael Thomas]

On 05/19/2011 07:11 PM, Pete Resnick wrote:
> On 5/19/11 6:09 PM, Michael Thomas wrote:
>> We send things that get forwarded through all kinds of manglers,
>> 8bit manglers just being one variety. In the abstract, you can never 
>> know
>> as a signer that a path is "clean"... it can always be forwarded. So 
>> by your
>> argument it should be a MUST since you can never know.
>
> (I'll assume here that you're using a loose definition for "forwarded" 
> and are really talking about either relaying or resending. Forwarding 
> in the usual sense is not something that DKIM *should* survive.)

Yes.

>> But that creates
>> the silly-state of DKIM wagging the 8bit SMTP tail, which is a wrong
>> outcome.
>
> I'm not sure what you mean here. What is the "right" outcome?

DKIM should never be in the position of dictating what is "right"
for the email world at large. If that world says that 8 bit is a
Good Thing, it would be a pretty ridiculous situation to have
DKIM being the impediment: it's a tail wagging the dog situation
which is always a wrong outcome.

Like I said, this is sort of academic... I don't think we're in any
huge danger here :)

Mike

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

Re: [ietf-dkim] 8bit downgrades

[Michael Thomas]

On 05/19/2011 02:53 PM, Pete Resnick wrote:
> In this case, the spec says that you MUST downgrade prior to signing 
> *unless you know that the end-to-end path is 8-bit clean and will not 
> downgrade later*. That's what SHOULD downgrade means. If there is an 
> implementation that doesn't downgrade and sends a message without 
> knowing that the path is end-to-end 8-bit clean, then it is in 
> violation of the spec. Changing it to MUST doesn't change anything for 
> such an implementation; it is already in full violation.

This is all a rather academic argument, but it doesn't really seem quite
right. We send things that get forwarded through all kinds of manglers,
8bit manglers just being one variety. In the abstract, you can never know
as a signer that a path is "clean"... it can always be forwarded. So by your
argument it should be a MUST since you can never know. But that creates
the silly-state of DKIM wagging the 8bit SMTP tail, which is a wrong
outcome.

In reality, I haven't ever seen a failure that was attributable to 8bit
mangling, and I've probably seen sample sizes as big or bigger than
Murray's. Maybe it's happened, but it seems extremely rare.

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

Re: [ietf-dkim] 8bit downgrades

[Michael Thomas]

On 05/19/2011 10:50 AM, Murray S. Kucherawy wrote:
>
> 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.
>

I don't remember the original rationale, but it would be bizarre for
DKIM to hem in any future SMTP improvements/standards regarding 8 bit.

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

Re: [ietf-dkim] New canonicalizations

[Michael Thomas]

On 05/16/2011 09:39 AM, Dave CROCKER wrote:
> Sorry, but I believe the above also does /not/ help us to understand actual
> survivability differences.
>
> To assess that difference, the experiment needs to send the same set of 
> message
> twice, one with each type of canonicalization, and then see what the survival
> differences are.
>
> The problem with the above is the biasing factor of signers' choosing to use 
> one
> or the other, based on criteria we can't know about.  Their criteria might 
> have
> greatly affected actual survival rates.  Or might not have...
>
>

My guess is that admins just don't understand any of the subtleties,
have heard lore that "relaxed" is "better" and just click "relaxed"
wherever they find it. It may also be the case that some implementations
don't even have separate nerd knobs for headers and body canonicalization.

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

Re: [ietf-dkim] New canonicalizations

[Michael Thomas]

On 05/16/2011 07:40 AM, Mark Delany wrote:
> On 16May11, Alessandro Vesely allegedly wrote:
>> OTOH, comparing the "count" fields of those two lines, 86% relaxed vs
>> 14% simple, says that such kind of benefit is really really wanted.
>>  
> But that's a perceived benefit, not an actual one.
>
> Folk think they need "relaxed" to significantly increase survivability
> but that's not the case given the stats above. So yo may be right that
> folk really really want it, but they don't really really need it.
>

It was our experience that relaxed body didn't make much
difference. Relaxed headers was a different story.

I don't have access to all of the ways signatures broke any
more, but if you factor out "real" mailing lists it was pretty
low and sort of random, iirc.

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

Re: [ietf-dkim] Issue: Consider deprecating "l="

[Michael Thomas]

On 05/09/2011 02:28 PM, Barry Leiba wrote:
> Semantics first: we don't "vote" here.
>
> OK, that taken care of, it's a fair request, because there's been a
> lot of discussion about it.  We certainly have a good base of support
> for deprecating "l=".
>
> So I'll ask it this way, starting a new thread for it:
> I determine from discussion that there's enough support for
> deprecating "l=" to qualify as rough consensus *if* there's not much
> objection to it.  It's the objection we need to gauge.  Please post to
> this thread if you object to deprecating "l=" in 4871bis.  You may say
> why you object, but please keep it brief, and let's not have a lot of
> discussion of it here.  If there's enough objection to derail
> deprecation, we will leave it alone.
>

I object. I've already asked whether there's been one
documented case of ill effect in 5+ years. Crickets.

Mike

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

Re: [ietf-dkim] Issue: Consider deprecating "l="

[Michael Thomas]

On 05/09/2011 02:39 PM, Murray S. Kucherawy wrote:

> - the PS-DS promotion "rules" say we should cut stuff that's not actually in 
> use, but this is;
> - we therefore don't have any data to conclude that there isn't anyone out 
> there that finds it exceptionally useful despite the dangers
>

Yes we do have plenty of data supporting its use. It works great
irrespective of the FUD spread about it, and I provided that data
at  great length in the past.

This process has run amok.

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

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

[Michael Thomas]

On 05/06/2011 08:12 AM, Rolf E. Sonneveld wrote:
> John, the opendkim project gathers information from various sources,
> they're not necessarily the users of Murray and they're not necessarily
> subscribed to mailing lists. The statistics also doesn't tell which
> inbound mail is from legitimate sources and which inbound mail is from
> spammers/bad guys. Maybe the 95% you mention, are the spammers who try
> to abuse l= in DKIM...
>

Good luck with spammers trying abuse that. A naive filter wouldn't
know at all about l= but are well acquainted with spammers inserting
good looking text with spammy text. A dkim aware filter would be even
less impressed as the unsigned content would stick out like a sore
thumb. For all of the hysterical warnings in the spec, it would be
nice to hear about even ONE successful abuse. It's been, what, 5
years now?

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

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

[Michael Thomas]

On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
> Technical: The AUID is an unvetted value.  The local-part and the subdomain 
> could be garbage.  It's inappropriate for a security protocol to return a 
> possibly false value in the context of saying something was cryptographically 
> validated.
>

I don't think this is correct. The signer creates and signs the i= value,
so it's not "garbage", and it can't be "false" either. I don't even know
what false means in this context. It's just a value which  is guaranteed
to be within the to the d= domain's bailiwick.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/05/2011 03:35 AM, Rolf E. Sonneveld wrote:
> Excuse me for my poor English, I shouldn't have used the word 'certify'
> here. I'm not talking about validity of content. Were I used the word
> 'certify' I mean:
>
> if a DKIM signature verifies successfully, the consumer can be sure that
> the body of the message (or the part thereof indicated by l=) and the h=
> headers, used to construct this signature, has not been changed between
> signer and verifier, and there is a one-to-one relation between the h=
> headers and the corresponding headerlines in the header of the message,
> that leaves no room for ambiguity. And in my view neither the consumer
> nor the assessor should have to re-do the work of the verifier, to get
> the assurance, described in the previous line.
>

Yes, that sounds right. Excuse me because the list volume has
been so high, but what's the problem? Btw, I _think_ the phrase
appropriate here is "data integrity".

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 04:40 PM, Dave CROCKER wrote:
[]

I'll do Barry the favor of stopping this inane conversation, much
as it amuses me.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 03:55 PM, Rolf E. Sonneveld wrote:
>
> Well, I think you both are right in reading what my concern/objection 
> against 4871bis is. And maybe you're also right in that RFC4871 wasn't 
> that much different of RFC4871bis.
>
> I think in the early days of DKIM most people assumed DKIM would 
> become a protocol where:
>
> * the body hash and header hash, using various header fields,
>   certifies the DKIM signature and
> * the DKIM signature certifies the body and header fields, that
>   had been used to create the DKIM signature.
>

Rolf,

By "certify" do you mean "assert that they are true/correct/something 
along those lines"?
DKIM doesn't make such assertions because there's no way absent a good 
deal more
infrastructure that a receiver should believe such an assertion. The 
addition of
ADSP adds one mechanism that allows a very narrow assertion about From to
the author domain be believable, but we certainly do not have anything 
beyond
that. If there was some verbiage in the security analysis, it is likely 
because
the precise delineation of signing protocol (DKIM) and policy protocol 
(ADSP)
was was not completely gelled at the time -- 4686 was put together mainly to
get past some process hurdles (imo) to form the wg, so it's pretty 
early. But
even then there was no intent to "certify" other header fields other 
than From.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 02:53 PM, Dave CROCKER wrote:
>
>
> On 5/4/2011 2:47 PM, Michael Thomas wrote:
>> On 05/04/2011 02:32 PM, Dave CROCKER wrote:
>>>
>>> On 5/4/2011 2:29 PM, Michael Thomas wrote:
>>>> I should also expand that this entire situation started with Crocker
> ...
>>> Right. It was all me. Another ad hominem. Nice.
>>
>> History is a personal attack? Who knew?
>
>
> Ahh.
>
> Before using a term -- especially one with social and legal import -- 
> it's worth doing the work of understanding what the term means.
>
> As usual, wikipedia is a reasonable reference:
>
> <http://en.wikipedia.org/wiki/Ad_hominem>

Golly, Dave. I'm trying to figure out how history qualifies as ad hominem.
Maybe it's the guilt by association section that has you all riled up? I'd
think that you'd be proud that it was your idea. I'm all confused now.

Mike

PS: I remember very clearly at the interop at Alt-N when you brought this
   all up.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 02:32 PM, Dave CROCKER wrote:
>
> On 5/4/2011 2:29 PM, Michael Thomas wrote:
>
>> I should also expand that this entire situation started with Crocker
>> insisting that we must "choose" between between i= and d=
>> as The Output. It was a false dilemma then, and it remains
>> a false dilemma. And as with all false dilemmas it only causes
>> heat instead of light.
>>  
>
> Right.  It was all me.  Another ad hominem.  Nice.
>

History is a personal attack? Who knew?

> But then I suppose the question is why you "should" have included that 
> explansion.
>
> Anyhow, its bad there wasn't any working group consensus on the changes.  I
> guess that means that the published, normative Update RFC was a violation of
> IETF principles and process.
>

One of the principles of DS is to remove things which aren't
implemented or serve no purpose. I think it's quite fitting to
ask that DS remove something that was added after the fact
in an errata update and has proved to be problematic. Does
the implementation report say who has implemented this
MUST? If not, why not? Could it be that it's untestable?

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 02:11 PM, Michael Thomas wrote:
> On 05/04/2011 01:57 PM, Murray S. Kucherawy wrote:
>
>> And who gets to define "appropriate"?
>>
>> It's already been pointed out that we could list every current tag's value 
>> and a pile of other stuff to pass on to the next layer, which may or may not 
>> find it useful, but that would make for an extremely messy protocol.
>>
>> Protocols need to be kept simple.
>>
>>
>>  
> 4871 was simpler yet: it had no notion of an "output". It relied on the
> developer to consider what was appropriate to deliver up the food
> chain.
>

I should also expand that this entire situation started with Crocker
insisting that we must "choose" between between i= and d=
as The Output. It was a false dilemma then, and it remains
a false dilemma. And as with all false dilemmas it only causes
heat instead of light.

Mike

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 01:57 PM, Murray S. Kucherawy wrote:
> And who gets to define "appropriate"?
>
> It's already been pointed out that we could list every current tag's value 
> and a pile of other stuff to pass on to the next layer, which may or may not 
> find it useful, but that would make for an extremely messy protocol.
>
> Protocols need to be kept simple.
>
>
4871 was simpler yet: it had no notion of an "output". It relied on the
developer to consider what was appropriate to deliver up the food
chain.

Manifestly this is very confusing. What is the "output" of IKE/KINK?
Patterned after DKIM, it would be the identity in the cert/ticket. But
it is profoundly the wrong question, which is what is leading to all
of these non-sequiturs.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 11:26 AM, Dave CROCKER wrote:
>> It's because I didn't want to imply that those were the only two.
>
> This is quite a remarkable premise for refusing to provide concrete 
> substance.
>
> I'm trying to imagine how a working group could ever make progress, 
> were this premise prevalent.  Don't offer substance without providing 
> a massive tome to cover everything that qualifies it enough to avoid 
> misunderstanding what hasn't been said...
>

More ad-hominems. I've written a DKIM stack. The first one in fact, followed
a week or so later testing with Murray. Call it an argument from 
authority, but
I at least have some experience in what subtle and seemingly inconsequential
wording changes can do to implementations.

44 pages of diffs scares the living hell out of me.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 12:08 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Michael Thomas [mailto:m...@mtcc.com]
>> Sent: Wednesday, May 04, 2011 12:08 PM
>> To: dcroc...@bbiw.net
>> Cc: Dave CROCKER; Murray S. Kucherawy; ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain 
>> Identity"
>>
>> Verifiers must not ignore them, assessors on the other hand may.
>>  
> Either could.  It's an implementation choice.
>
> If the verifier wants to enable the assessor to make the call, it's free to 
> export "l=" information.
>

I agree that it's an implementation issue. All of this is. But choosing
a single "output" formally makes that a no-no for the assessor, which
is a silly outcome. And it's but one silly outcome. What of the h= values?
How does an assessor know which ones were signed? That's a layering
violation according to -bis. Silly.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 11:53 AM, Dave CROCKER wrote:
>>   Considerations Section 8.  To avoid this attack, signers should
>>   be extremely wary of using this tag, and verifiers might wish
>>   to ignore the tag.
>>  
> To avoid this attack, signers need to be extremely wary of using this tag, and
> verifiers might choose to ignore signatures containing it.
>
>
>

Verifiers must not ignore them, assessors on the other hand may.
But assessors cannot because the existence of l= is not part of
the DKIM output. This results in an inconsistency in the protocol.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 11:03 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Michael Thomas [mailto:m...@mtcc.com]
>> Sent: Wednesday, May 04, 2011 10:54 AM
>> To: Murray S. Kucherawy
>> Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain 
>> Identity"
>>
>>  
>>> The advice that a verifier can ignore the "l=" tag was in RFC4871, so
>>> copying it to RFC4871bis doesn't seem like a problem to me.
>>>
>> You can't ignore the *tag*. That's the normative change. Whether you
>> ignore the *output* is another matter. But of course you can't ignore
>> the output because l= is "internal". Yet another problem.
>>  
> But RFC4871 also said you could ignore the tag, so I don't understand the 
> distinction you're making.
>
Like I said, i only looked at this for a few minutes -- 4871 is wrong or 
sloppy
here too. But my other objection still stands: with the procrustean "output"
as it stand right now, an upper level entity would not be able to ignore
signatures with l= because that's "internal".

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 10:43 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Michael Thomas [mailto:m...@mtcc.com]
>> Sent: Wednesday, May 04, 2011 10:29 AM
>> To: Murray S. Kucherawy
>> Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain 
>> Identity"
>>
>> It's because I didn't want to imply that those were the only two. It's just
>> what I found in my quick scan. But they were the advise about ignoring
>> signatures with sha1, and another saying you could ignore an l= *tag*.
>>  
> I can't recall the history of the first one, other than it being consistent 
> with general IETF movement away from use of SHA1.  Perhaps someone else can 
> comment there.
>
Saying that receivers can ignore signatures with sha1 is a serious
difference. What does that do for interoperability if followed? Nothing
good is my guess. The advise I've always heard is "walk, but don't run"
away from sha1. Let's be real: DKIM's crypto guarantees are already low;
sha1 is the least of its weaknesses.

> The advice that a verifier can ignore the "l=" tag was in RFC4871, so copying 
> it to RFC4871bis doesn't seem like a problem to me.
>
You can't ignore the *tag*. That's the normative change. Whether you
ignore the *output* is another matter. But of course you can't ignore
the output because l= is "internal". Yet another problem.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 10:25 AM, Murray S. Kucherawy wrote:
> I count at least two new normative changes -- in informational notes 
> of all places -- by scanning
 *half* the document, both of which are wrong.
  
> What were the two normative changes in informational notes that were wrong in 
> the half of the document you scanned?
>

It's because I didn't want to imply that those were the only two. It's just
what I found in my quick scan. But they were the advise about ignoring
signatures with sha1, and another saying you could ignore an l= *tag*.

And that's what I found in 15 minutes.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 10:13 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Michael Thomas
>> Sent: Wednesday, May 04, 2011 10:11 AM
>> To: dcroc...@bbiw.net
>> Cc: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain 
>> Identity"
>>
>> 44 pages of diffs.
>>  
> Updating an RFC number causes a diff.  That's not a valid metric.
>

These aren't updates to just the rfc number though. This document
has been changing and changing and changing up until the weeks
before last call, and through last call. It's impossible to keep up with
unless it is your full time job, which it most certainly isn't in my case --
unless you can figure out how this relates to public key substitution
attacks in android market in-app purchases.

That is why I'm so alarmed.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 09:14 AM, Dave CROCKER wrote:
> I've uploaded Murray's helpful effort to the DKIM site:
>
>  
>
> I had assumed that the complete diff would be unreadable, which is why I
> originally put up the incremental diffs.
>
> However in looking through the complete diff, I'm surprised to discover that 
> it
> is quite easy to see and evaluate all of the changes.
>
> We really ought to stop responding to criticisms that provide no 
> substantiation.
>For criticism to be constructive, it needs to contain meaningful substance.
>
> Complaining is easy; substantiating criticism takes effort.
>

44 pages of diffs. That is not by stretch of the imagination 
inconsequential.
I count at least two new normative changes -- in informational notes of all
places -- by scanning *half* the document, both of which are wrong. And that
does not count the normative change with Output.

Thanks for reinforcing my impression that this is a process run amok.

Mike

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 09:15 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Michael Thomas [mailto:m...@mtcc.com]
>> Sent: Wednesday, May 04, 2011 9:03 AM
>> To: Murray S. Kucherawy
>> Cc: Rolf E. Sonneveld; dcroc...@bbiw.net; ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain 
>> Identity"
>>
>> My sense is that what Rolf is asking at its base is that the there is
>> a conflict between the two documents and it's not clear why they
>> exist, and which should be believed. If 4686 is inconsistent, then
>> we should make a case for why it's wrong and document that. It
>> may be process-wise "informational", but it served at the time as
>> a guiding document for the creation of 4871, and had working
>> group consensus at a time of extremely high scrutiny. We do not
>> have anywhere close to that level of scrutiny now, and as such
>> any changes made should be viewed with a very high level of
>> caution and scepticism.
>>  
> My read is that Rolf is objecting to RFC4871bis on the grounds that it 
> conflicts with RFC4686.  (He can and should correct me if I'm wrong.)
>
> If his concerns would be satisfied by a change (perhaps an appendix?) that 
> simply acknowledges some evolution in thinking based on experience since 
> RFC4686 was published, I imagine that wouldn't meet with much resistance.
>
> But if the point is to use RFC4686 to compel some change in something trying 
> to get to DS (or even PS), that's a non-starter.
>

"Compel" and "non-starter" are not helpful. Everything past publication of
4871 should be viewed in the light that fewer and fewer people were paying
attention. The set of people paying attention now are extremely few, and
many of them have self-interest in revisiting and/or changing the previous
consensus -- taking advantage of the much smaller set of participants. Not
that 4686 and 4871 are some sort of ideal residing in a platonic cave, but
they do have the virtue that they were widely reviewed and in the case of
4871, implemented. We risk screwing things up with every edit; the law
of unintended consequences isn't being given the respect it deserves.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 08:51 AM, Murray S. Kucherawy wrote:
>> Both documents refer to rfc4686, albeit only in the Informative
>> References section. rfc4871 refers to rfc4686 only in section 8,
>> rfc4871bis in section 8 as well as in section 1.1.
>>  
> There are two main fallacies that appear to be behind the arguments of a few 
> people here:
>
> (1) RFC4686 is gospel.  It isn't.  Its status is "Informative" which means it 
> doesn't bind anyone to do anything.
>
> (2) A working group is not entitled to change its mind about something based 
> on experience.  It is.
>
> Since RFC4686 was published, some of the consensus view of how this 
> does/should/might all work has shifted.  There's nothing wrong with that.
>
> If someone wants to undertake the work of publishing an update because it's 
> seen as important, there are several of us that could assist with procedure, 
> though it's unlikely to be done by this working group at this point.
>

My sense is that what Rolf is asking at its base is that the there is
a conflict between the two documents and it's not clear why they
exist, and which should be believed. If 4686 is inconsistent, then
we should make a case for why it's wrong and document that. It
may be process-wise "informational", but it served at the time as
a guiding document for the creation of 4871, and had working
group consensus at a time of extremely high scrutiny. We do not
have anywhere close to that level of scrutiny now, and as such
any changes made should be viewed with a very high level of
caution and scepticism.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 08:16 AM, Dave CROCKER wrote:
> Michael,
>
>
> On 5/4/2011 7:58 AM, Michael Thomas wrote:
>> This is a good example of why this effort has come off the rails.
>> Going from 4871 to DS should have been a fairly straightforward
>> effort considering the high degree of interoperability we achieved.
>> Instead of just removing a few unused features, we've seen a
>> wholesale rewrite when one was manifestly not needed. Worse,
>> is that when that history is mentioned it is either disregarded
>> or sneered at by the senior editor. That is a problem.
>
>
> "Wholesale rewrite"?  Well, that should be easy for you to document, 
> given how convenient it is to point to the existing diffs.  The task 
> when citing a problem with changes is to point to /specific/ changes 
> that are problematic.  That requires some work.
>
> In particular, please cite normative differences.

As I've already mentioned: the notion of "output" is a huge NORMATIVE
change. It should have never been allowed as a piece of errata, and
continues to cause all manner of issues. 4871 was NOT BROKEN in this
respect. We have no business telling developers what the layering
relationship is between the DKIM verifier and its consumers.

> As for the particular difference between rfc4871's statement of DKIM's 
> purpose and rfc4871bis' statement, you might want to review the 
> language in the Service Overview and the Deployment documents.  On 
> this issue, the working group's learning process has been incremental 
> and well documented.

Asleep at the switch is a more accurate portrayal. By the time any of this
effort started, we had a wealth of interoperability information which 
resulted
in the non-controversial parts of the errata, and stable unchanging
implementations. The "learning" should be to leave well enough alone,
instead of changing things just for aesthetics and quite likely breaking
things in the process, either purposefully or inadvertently.

>
> As for 'sneering' at history, please do cite that occurrence, too.  
> Please distinguish between citing history versus sneering at it.  
> Explaining the criteria that qualifies as 'sneering' would be helpful.

You need look only at the piece that I quoted from. Your continuous use of
ad hominem attacks is well documented.

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

On 05/04/2011 07:08 AM, Dave CROCKER wrote:
> The claim that rfc4871bis has the goal you claim is yours.
>
> So you need to do the work of subtantiating it.
>
> So far, as you acknowledge, your only reference is quite old, merely
> informative, and not a specification.  In contrast, rfc4871bis declares the 
> goal
> of its specification and it's not the one you assert.
>
> You've now had multiple people responding to this thread with various
> explanations why it is off the mark.
>
> We should be done.
>
>

This is a good example of why this effort has come off the rails.
Going from 4871 to DS should have been a fairly straightforward
effort considering the high degree of interoperability we achieved.
Instead of just removing a few unused features, we've seen a
wholesale rewrite when one was manifestly not needed. Worse,
is that when that history is mentioned it is either disregarded
or sneered at by the senior editor. That is a problem.

This entire process needs a reset, starting with the choice of
editors. We are so far afield of what RFC 4871 was that it's impossible
to understand the implications of the subtle changes that have been
introduced. RFC 4871 worked. It did not need anywhere close to this
level of "fixing".

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

[ietf-dkim] "Output" considered harmful

[Michael Thomas]

On 05/04/2011 05:04 AM, John R. Levine wrote:
>> For a scenario where a caller is calling a DKIM milter which in turn calls an
>> API, this is all true. But DKIM will be/is deployed in many more scenarios.
>>  
> Indeed, but you're misunderstanding the point of a standard.  The DKIM
> spec tells signers how to create a signature that recipients can verify,
> and it tells verifiers how to check whether a signature is valid.  The
> spec is not an implementation guide for every possible implementation
> scenario.
>
Indeed, this is precisely why it's silly to say there is a single
"output" of the protocol. Take IKE and KINK, for example: the
"output" is a complex set of parameters that eventually lead
to the keying of a SA given the identity in the cert/ticket. They
are *all* relevant and not just "internals". Similarly, DKIM
signatures have a lot of relevant information for filters to do
the magic that filters do, and they by their nature find utility
in information that is being walled off by -bis as being "internal".

And please stop trying to have it both ways: it's either "internal"
or it isn't. Developers have a funny way of taking these documents
literally and when you say it's "internal", they make them internal
in fact. We need to pick a lane, and "single output" clearly does
not match the real needs of all DKIM consumers.

4871 had it right on this account. Everything since then has
screwed the pooch. Put it back.

Mike

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

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Michael Thomas]

Dave CROCKER wrote:
> 
> On 4/30/2011 9:10 PM, Hector Santos wrote:
>> So perhaps to help shut down this ambiguity we should add a DKIM
>> terminology to clearly separate it from AUID.
>>
>> 3.x  Originating Domain Identity (ODID)
>>
>> The ODID is the domain part of the From: address.  This identity
>> MAY be considered as an output communicated to an advanced
>> Identity Assessor module.
> 
> 
> Oh heck, let's just declare that the DKIM Signing module MAY output anything 
> it 
> wants.  

That's what 4871 did. Manifestly it worked just fine. We had a tremendous number
of interoperable implementations. The procrustean insistence that there be a
single "output" has not helped interoperability one iota.

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

Re: [ietf-dkim] Output summary

[Michael Thomas]

Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Michael Thomas [mailto:m...@mtcc.com]
>> Sent: Friday, April 29, 2011 4:37 PM
>> To: Rolf E. Sonneveld
>> Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary
>>
>> Indeed, the chickens have come to roost. This was ill-conceived at the
>> time of the errata, and it is ill-conceived here. It is yet another reason
>> why I believe that the protocol described in 4871bis only bears passing
>> resemblance to 4871 and interoperation will be purely coincidental.
> 
> I don't agree.  I don't know of any current implementations that would be 
> hampered by what's being done here.

Current implementations are irrelevant. They will completely and utterly ignore 
what is in
4871bis, because they are done and work fine. The problem is whether we've 
introduced problems
which will cause new implementations to not interoperate with current 
implementations. Given
the huge number of changes, it's impossible to tell without getting real life 
data.

This wholesale rewrite of 4871 needs to cause the document to be recycled to PS 
so that we
can have evidence that we haven't broken something. There is far too small an 
audience to
vet the changes going on here, and few if any of them are writing code from it.

Going to DS isn't an invitation to change all of the things the few remaining 
interested
parties didn't like in PS. But that's what I see going on here.

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

Re: [ietf-dkim] Output summary

[Michael Thomas]

Rolf E. Sonneveld wrote:
> Don't get me wrong, I just wanted to demonstrate that, IF we follow the 
> logic of not crossing protocol boundaries strictly, THEN communicating 
> the d= payload /without additional information/, we
> 
> * either enforce upper layers to violate layers or
> * in advance we discourage in advance the design and development of
>   a number of useful applications that otherwise could have been
>   built on top of DKIM.
> 
> 
> In the archives I found exactly this same concern and discussion, see 
> for example the contribution of Jim: 
> http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg11105.html

Indeed, the chickens have come to roost. This was ill-conceived at the
time of the errata, and it is ill-conceived here. It is yet another reason
why I believe that the protocol described in 4871bis only bears passing
resemblance to 4871 and interoperation will be purely coincidental.

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

Re: [ietf-dkim] despair

[Michael Thomas]

On 04/27/2011 12:19 PM, Barry Leiba wrote:
> 
>
>
>> Complaining is easy.
>>  
> Indeed so.  And so let's cut the meta-discussion and not go back to
> throwing darts around.  To the points:
>
> Mike's concern is valid.
>
> Murray's and Dave's notes have addressed it.
>

I don't see how getting a list of diffs after last call ends addresses it.

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

Re: [ietf-dkim] despair

[Michael Thomas]

On 04/27/2011 09:45 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Michael Thomas [mailto:m...@mtcc.com]
>> Sent: Tuesday, April 26, 2011 4:31 PM
>> To: Murray S. Kucherawy
>> Cc: DKIM IETF WG
>> Subject: Re: [ietf-dkim] despair
>>
>> When you commit a 20 page diff without the benefit of a debugging
>> pass and dev test, how much confidence do you have in that commit?
>>  
> I've been keeping up with the specification changes both in terms of the 
> documentation and the impact of the changes on live source code.  That's 
> really helped to keep us honest in terms of backward compatibility.
>

Uh, this completely misses the point. It's not about you or opendkim.
It's about whether somebody starting out fresh would write a dkim
stack that interoperates with it solely from the -bis draft. Given the
rate of change, I don't have a lot of confidence in that. If 4871 were a
mess then this wholesale tinkering might be justified, but it wasn't.

The larger problem is that nobody that actually matters is paying
attention any more. Any bugs introduced here will take years to be
noticed. I had some trepidation about attempting to go to DS and
it has borne itself out.

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

Re: [ietf-dkim] despair

[Michael Thomas]

On 04/27/2011 09:53 AM, Dave CROCKER wrote:
> With that sort of documented history, the responsibility to claim otherwise
> falls on the critic.  Otherwise the wg is essentially being asked to prove a
> negative and almost serves as a DOS attack...
>

Denial of service on what/whom? As far as I can see, the
only thing that this effort is serving is the process itself.
It certainly isn't helping DKIM.

> Complaining is easy.  Trying to put the work on others is easy.  Doing
> foundational work to support a claim is not.
>

This is rich coming from somebody who's never written a
DKIM stack to somebody who wrote the first.

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

Re: [ietf-dkim] despair

[Michael Thomas]

On 04/26/2011 04:03 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of Michael Thomas
>> Sent: Tuesday, April 26, 2011 2:43 PM
>> Cc: DKIM IETF WG
>> Subject: [ietf-dkim] despair
>>
>> There sure seems to be an awful lot of changes going on for a
>> supposed draft standard document. I for one can't keep up with
>> the rate of change, and I doubt anybody else can either. I really
>> don't care if each individual piece can -- microscopically -- be
>> justified within the process of draft standard:  I have no way
>> to determine whether these changes as a whole constitute a
>> compatible protocol with 4871 or not.
>>  
> Barry has asked me to prepare a "diff" of sorts that compares RFC4871 with 
> RFC4871bis so that we can all see the distillation of the proposed changes.  
> I'll be doing that in the next day or so.
>
When you commit a 20 page diff without the benefit of a debugging
pass and dev test, how much confidence do you have in that commit?

At this point, we have no reason to believe that a new implementation
from this draft would interoperate with existing implementations.

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

[ietf-dkim] despair

[Michael Thomas]

There sure seems to be an awful lot of changes going on for a
supposed draft standard document. I for one can't keep up with
the rate of change, and I doubt anybody else can either. I really
don't care if each individual piece can -- microscopically -- be
justified within the process of draft standard:  I have no way
to determine whether these changes as a whole constitute a
compatible protocol with 4871 or not.

Bugs happen. Going from proposed to draft should be akin to
making changes to a running system -- few and only when
urgently needed. I can't believe that the bulk of the changes
are anywhere close to that threshold. And it seems to be
getting worse in the home stretch, not better. This is made
far worse because the vast majority of people who contributed
to 4871 aren't paying attention to the changes.

Mike, recycle or rollback at this point seems more fitting
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Issue: Section 4.3 Hash method Note

[Michael Thomas]

On 04/25/2011 01:57 PM, Barry Leiba wrote:
> Dave further tweaks:
>
>>   INFORMATIVE NOTE: Although use of rsa-sha256 is strongly encouraged,
>>   some senders might prefer to use rsa-sha1 when balancing security
>>   strength against performance, complexity, or other needs.  However,
>>   compliant verifiers might not implement rsa-sha1; they will treat
>>   such messages as unsigned.
>>  
> WFM.
>

This seems rather extreme. Last thing I've heard is that
SHA1 has been shown to have a weakness, but it hasn't
been broken. Given that we're using unsecured DNS to
deliver public keys, this seems a like a hysterical
overreaction.

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

Re: [ietf-dkim] ADSP stats

[Michael Thomas]

On 04/20/2011 04:13 PM, Murray S. Kucherawy wrote:
>> That isn't a helpful metric. The 99% most likely domains to
>> have a ADSP record are ones where you see DKIM signatures
>> and they pass. So if you're only checking domains without
>> DKIM signatures (broken or otherwise), you're going to get
>> a self fulfilling prophecy.
>>
>> A much better test would be compile a list of DKIM signing
>> domains, and do the ADSP query on them.
>>  
> Yeah, that's what I meant when I referred to doing five figures worth of TXT 
> queries.
>

I think it would be worth it, since the numbers are almost
certainly going to be better, even if they're not great. There's
nothing worse than a stat-as-meme that originate from highly
flawed studies.

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

Re: [ietf-dkim] ADSP stats

[Michael Thomas]

On 04/20/2011 01:29 PM, Murray S. Kucherawy wrote:
> There has been no uptake at all in OpenDKIM for ATPS, and almost none is 
> apparent with ADSP, although in the latter case our data can only give a 
> range for adoption because we don't query when an author signature passes.
>

That isn't a helpful metric. The 99% most likely domains to
have a ADSP record are ones where you see DKIM signatures
and they pass. So if you're only checking domains without
DKIM signatures (broken or otherwise), you're going to get
a self fulfilling prophecy.

A much better test would be compile a list of DKIM signing
domains, and do the ADSP query on them.

Mike, not that i think it's going to be terribly high either
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] ADSP stats

[Michael Thomas]

Murray S. Kucherawy wrote:
> If ADSP is too weak or dangerous a protocol, and there are no current viable 
> alternatives, then failing to beat the streets to get the industry to deploy 
> it is an act of responsibility, not one of omission or laziness.

My feeling is that it conflicts with too many (would-be) industry third 
parties' self interest in
selling reputation/policy, and hence why the FUD bullhorn was on full blast 
through the entire
exercise, and remains on to this day. If DKIM itself were given the same 
treatment, we'd be looking
at the same sorry stats for it. That vested interests don't like something 
isn't an indication of
absolute worth, it's just an indication of its worth with respect to their 
perceived bottom line.

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

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

[Michael Thomas]

On 04/06/2011 01:18 PM, Steve Atkins wrote:
>> Yes it does. In your example, a second signer who isn't
>> privy to whether it knows the birth date could either sign
>> it because it wants to keep transport integrity, or not
>> sign it because it doesn't actually know the veracity of
>> the X-Birthdate: header. The receiver is then left trying
>> to figure out who is asserting what, most likely by putting
>> new rules/requirements on the DKIM signer.
>>  
> If you look at the example I gave, it mentions
> which DKIM identity is making the assertion.
>
> Authenticated-Birthdate: version=0.1; dkim=corp.example.com; 
> birthdate=1970-02-24
>
> It's not particularly pretty, but it's fairly obvious to the recipient
> what's going on, and unlikely to break anything.
>

   Bletch. At least this is all theoretical now. Thankfully.

> (There's an obvious hole if you have access to a signer that
> just signs every header, rather than a fixed list of headers,
> but that's fairly far in to "don't do that" territory).
>

I think it's a little worse than that. It sort of also expects
corp.example.com's mail infrastructure to be consistent,
and that you don't get multiple trips through the signer
infrastructure tickling those inconsistencies. Weird
stuff does happen, especially when you get companies
bolted together.

>> Messy and error prone. At least if you put it into the signature
>> header you know for certain what the signer's intention is.
>>  
> I don't think you do. If you put it in the signature header in an existing
> field (e.g. i= or s=) then there's no common understanding of the
> semantics beyond what 4871 has to say about them.
>
> If you put it in the signature field in an ad-hoc way, you risk
> clashing with someone else's use of it.
>

I'm only talking about a standards based approach here.
Non-standard use would make a messy situation even messier.

> That's certainly a reasonable approach, but the overhead
> of doing that (vs adding an ad-hoc field or using a 5322
> header) makes me think it unlikely people will do that.
>

The net-net is that either way, the DKIM signer code would
need to change. So do you want the DKIM signer to need to
parse/understand the semantics of another RFC, or understand
an extension to DKIM itself. I'd worry that the DKIM considerations
in the rush to have the all important X-Brithdate rfc would be
lost on the DKIM signer maintainers. By putting it into the
DKIM header itself, you have to *force* them to pay attention
to the problem if you want the feature.

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

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

[Michael Thomas]

On 04/06/2011 12:34 PM, Steve Atkins wrote:
> On Apr 6, 2011, at 11:05 AM, Michael Thomas wrote:
> \
>
>> The alternative would be very squirrelly when you think
>> of the general case of multiple signers in the path.
>>  
> The approach I suggest has no problems with multiple
> signers even if they, for some reason, all want to add
> conflicting metadata.
>

Yes it does. In your example, a second signer who isn't
privy to whether it knows the birth date could either sign
it because it wants to keep transport integrity, or not
sign it because it doesn't actually know the veracity of
the X-Birthdate: header. The receiver is then left trying
to figure out who is asserting what, most likely by putting
new rules/requirements on the DKIM signer.

Messy and error prone. At least if you put it into the signature
header you know for certain what the signer's intention is.

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

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

[Michael Thomas]

On 04/06/2011 10:53 AM, Murray S. Kucherawy wrote:
>
>> Having cross semantic correlation of what headers mean with the
>> presence of dkim signatures from various different signers seems
>> like a lot more of layer violation to me.
>>  
> That a DKIM hash covers a header field doesn't assign any new meaning to the 
> field.  It only guarantees its integrity.
>

But that's the basic problem with the approach that Steve
laid out: we don't enforce any semantics about why a signer
signs something. Doing so would open a large can of worms.
Limiting new additions to the dkim header itself at least
would limit the problem of adding new semantics of a
signature header to exactly the entity doing the signing.
The alternative would be very squirrelly when you think
of the general case of multiple signers in the path.

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

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

[Michael Thomas]

On 04/06/2011 10:25 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Michael Thomas
>> Sent: Wednesday, April 06, 2011 9:43 AM
>> To: Steve Atkins
>> Cc: DKIM WG
>> Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
>>
>>  
>>> As long as the Authenticated-Birthdate header is included in the
>>> DKIM signature it references, that's pretty much equivalent as
>>> far as senders and receivers who are both using the same
>>> authenticated birthdate spec are concerned, just more flexible
>>> and less likely to clash with or break other DKIM usage.
>>>
>> As I said, that would be a completely new requirement for
>> headers -- something that we don't do today. Also: you could
>> get into awkward situations where you'd be required to not
>> sign something that was present in the message if you couldn't
>> vouch for its correctness, even if you wanted to vouch for its
>> transport integrity.  If it's in the signature header itself, there's
>> no such ambiguity.
>>  
> Either method can ensure the data make it to the verifier intact, to be sure. 
>  But this smells a bit like a layering violation to me.  Using a new DKIM tag 
> to relay meta-data about the signer, rather than the actual signer's identity 
> (or equivalent), strikes me as something that doesn't belong in DKIM.
>

Huh? What is a= or d= or s= if not "meta-data about the signer"?
Having cross semantic correlation of what headers mean with the
presence of dkim signatures from various different signers seems
like a lot more of layer violation to me. In any case, we haven't
gone down the route of giving semantics to *why* a signer
signs a given header which is really at the heart of this discussion.
The closest we have is From: that we require to be signed but
the "why" part is still something of a hand wave -- essentially
being "because we said so".

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

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

[Michael Thomas]

On 04/06/2011 09:29 AM, Steve Atkins wrote:
> On Apr 6, 2011, at 9:07 AM, Michael Thomas wrote:

> There is something to be said about using tags in the signature
> rather than signed headers. Signers don't have to have any
> reason -- and none should be inferred -- for signing any given
> header. There are no semantics associated with that. Putting
> something in the signature on the other hand carries
> the exact semantics of what the value means _in the context of
> the DKIM signature_.
>
> So unless we want to start making new headers have a presence
> of a DKIM semantics requirement -- which would probably be
> hopeless -- it's probably better to keep extensibility within
> the narrow confines of the DKIM header itself.
>
> Not all new headers. (And the DKIM header doesn't really have
> any proper extensibility, and the use of single or two letter names
> for fields makes ad-hoc addition of new fields to that header - without
> a registry or version bump - quite a bit riskier than the "Full-English-Word:"
> approach 5322 headers use.)
>
> Rather, if anyone wants to release a specification that "requires"
> some sort of data be associated with a dkim signature then they
> can equally well release a spec that defines a new 5322 header
> that holds the same data.
>
> As a concrete example, if I wanted to include the authenticated
> age of each email sender (something the gambling industry might
> be interested in) then I can do that within the DKIM signature:
>
> DKIM-Signature: v=1; d=corp.example.com;; db=19700224
>
> Or I can specify that that should be done with a dedicated 5322
> header that both references and is signed by a DKIM signature.
>
> DKIM-Signature: v=1; d=corp.example.com;; 
> h=To:Authenticated-Birthdate:
> Authenticated-Birthdate: version=0.1; dkim=corp.example.com; 
> birthdate=1970-02-24
>
> As long as the Authenticated-Birthdate header is included in the
> DKIM signature it references, that's pretty much equivalent as
> far as senders and receivers who are both using the same
> authenticated birthdate spec are concerned, just more flexible
> and less likely to clash with or break other DKIM usage.
>
>

As I said, that would be a completely new requirement for
headers -- something that we don't do today. Also: you could
get into awkward situations where you'd be required to not
sign something that was present in the message if you couldn't
vouch for its correctness, even if you wanted to vouch for its
transport integrity.  If it's in the signature header itself, there's
no such ambiguity.

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

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

[Michael Thomas]

On 04/06/2011 08:48 AM, Steve Atkins wrote:
> That sounds like a fragile way to extend things - leave a little used feature
> around and hope someone who wants something new hijacks that
> field in a non-conflicting way instead. (Which may not be what you're
> suggesting, but it's an implication I've seen in some comments about i=).
>
> Outside of the information that is needed to validate the DKIM signature
> (v, a, b, bh, c, d, h, l, q, s, t, x) there doesn't seem to be any real need 
> for
> information to be recorded in the DKIM-Signature field at all. Rather, it can
> use the 5322 extensibility to add a header containing the information
> that needs to be included (with an understanding that the receiver should
> require that header be covered by the DKIM signature).
>

There is something to be said about using tags in the signature
rather than signed headers. Signers don't have to have any
reason -- and none should be inferred -- for signing any given
header. There are no semantics associated with that. Putting
something in the signature on the other hand carries
the exact semantics of what the value means _in the context of
the DKIM signature_.

So unless we want to start making new headers have a presence
of a DKIM semantics requirement -- which would probably be
hopeless -- it's probably better to keep extensibility within
the narrow confines of the DKIM header itself.

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

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

[Michael Thomas]

John R. Levine wrote:
>> Flip that around: I want to give positive warm fuzzies to mail from the
>> users that are authenticated by bigisp.com and are on my positive list.
> 
> I believe that's what we call "human shields."  Um, no.  This whole model 
> of bigisp sending a mixture of legit and forged mail, and using i= to 
> assert nice things about the legit mail seems awfully strained.  In my 
> experience, if I get a message with a credible signature, one of the 
> things that "credible" means is that the From: address is real enough to 
> use for message sorting.

An assertion from a large ISP-like domain with only the d= is essentially
useless. Ok, it came though bigisp.com, now what? Bigisp by definition is
going to have some bad actors, so without some other means of differentiation
the signature's domain only tells you that it's from somebody who's going to
have bad actors.

i= is one means for identifying sub-domain level granularity, but it could be
done other ways as well. You could sign an "X-Evil: yes" header as well. The
bigger problem with i= is that its semantics were underspecified because the
working group didn't want to go there. So unsurprisingly we're now in a position
where we have a large user base of signers who put something in i= and we're
not quite sure what they mean by it. Chickens: roost.

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

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

[Michael Thomas]

Dave CROCKER wrote:
> The distinction that needs to be made is between formally-specified output 
> vs. 
> implementation-specific access to DKIM internals.
> 

i= was never intended to be "DKIM internals". That's why the entire gambit to
make d= the only show in town sucked.

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

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

[Michael Thomas]

Murray S. Kucherawy wrote:
>> The working group was bamboozled into the false dilemma
>> that DKIM had to produce a singular "output". It has all
>> gone down hill from there. Things that use heuristics like
>> spam filters thrive with more information, and suffer with
>> less. So we've destroyed information in the name of aesthetics
>> while the main consumers of the output thrive on the messy
>> details.
> 
> My recollection was that we decided DKIM has to produce at least one specific 
> output, and that the spec needed to identify what that one particular item 
> was.  We never precluded it from making other information available.
> 
> OpenDKIM makes the entire signature and result available to the caller, so it 
> can use whatever it wants.  And that doesn't make it non-compliant.

Read: All outputs are equal, but some outputs are more equal than others.

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

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

[Michael Thomas]

On 03/31/2011 02:33 PM, Jim Fenton wrote:
> The direction of the DKIM specifications since RFC 4871 have been to
> rely less and less on the AUID (agent or user identifier, the i= value
> on the signature) to the point that it provides no security benefit.
>

The working group was bamboozled into the false dilemma
that DKIM had to produce a singular "output". It has all
gone down hill from there. Things that use heuristics like
spam filters thrive with more information, and suffer with
less. So we've destroyed information in the name of aesthetics
while the main consumers of the output thrive on the messy
details.

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

Re: [ietf-dkim] DKIM using old RSA padding?

[Michael Thomas]

Hanno Böck wrote:
> Am Mon, 28 Feb 2011 09:44:25 -0500
> schrieb Dave CROCKER :
> 
>> Just for archive completeness (and to comfort folks like me who lack
>> crypto clue) could you offer a very brief summary of the difference
>> between what DKIM currently uses and what is being suggested,
>> especially in terms of how the newer one is better and why that might
>> be important?  
> 
> The difference is merely protection against hypothetical weaknesses in
> the padding scheme. Old padding schemes have been made more or less in
> a naive way (usually hash-then-sign), while PSS (specified in PKCS #1
> 2.1) provides provable security properties under certain model
> asumptions.

Thanks for the explanation. I've always approached these kinds of problems
for dkim with a test like "if I could exploit a weakness at great expense,
would dkim signatures be on the short list?" The answer is invariably no.
It's similarly why the SHA1 brouhaha wasn't _that_ big a deal, IMO.

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

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

[Michael Thomas]

Snatching defeat from the jaws of victory:

-1

Mike

Barry Leiba wrote:
> The chairs are happy with how this discussion has been going so far,
> except that we remind people that discussion of any details of
> iSchedule or any other protocol that might cite DKIM is entirely out
> of scope -- we need to accept that people want to use parts of the
> DKIM mechanism, and not, at this point, criticise their design.
> 
> We'll let the discussion go through the end of next week -- let's say,
> through the end of the day on Thursday, 20 Jan -- and then we'll make
> a consensus call.  Between now and then, please continue to discuss
> specifically the idea of whether the right answer for the overall good
> of the DKIM specification is to make the proposed split now, or not
> to.  And at some point between now and then, please make it clear
> where you stand on the question, so we can fairly judge consensus.
> 
> We also thought that the outline of the proposed split would be enough
> to work with, but there've been a lot of questions of the details.  We
> understand that the editors have done a draft of the split that they
> will soon be ready to post as (individual) Internet drafts, and we've
> asked them to post them.  When they do, please keep in mind that they
> are there to answer the questions that are coming up, and NOT to has
> out all the split details now.  If the working group approves the
> split, we can hammer out the details then.  Use these drafts to see,
> specifically, what's being proposed, understand that IF we agree to go
> in that direction they will still be up for changes, and don't get
> mired in arguing the details now.
> 
> On a procedural note: the chairs think that it's within the charter to
> decide to satisfy charter work item 1 (DKIM to Draft Standard) by
> making this split, and we do not think there's a procedural issue
> raised here.  Should we decide NOT to make the split and to proceed to
> Draft Standard with a single 4871bis document, the chairs DO think
> that revisiting the question is splitting the documents later -- a
> fair approach to this -- would require rechartering.
> 
> Again, please continue the discussion of the proposed split through 20
> January, and let us know where you stand as we evaluate consensus.
> 
> Barry, as chair
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html

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

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

[Michael Thomas]

J.D. Falk wrote:
> On Jan 11, 2011, at 4:12 AM, Eliot Lear wrote:
> 
>> 2.  The mechanisms in DOSETA were designed for DKIM.  If we are generalizing 
>> along the lines that Dave has mentioned, I would prefer that DOSETA in 
>> particular not advance to draft status, as it ought to be tested in at least 
>> two separate applications for a time.  Otherwise we run the risk of 
>> ossifying something prematurely.
> 
> This is a good point.
> 
> But also, speaking of ossification, seems like it'd be far more annoying in 
> the long run to create DOSETA as something entirely parallel to DKIM, and 
> have DKIM not reference it -- in other words, two nearly-identical parallel 
> specifications.
> 
> It's not an easy or obvious decision, and I appreciate that we're having a 
> frank and friendly discussion about it.

There comes a time when it's best for all to just admit that the train has left 
the station.
I may well have supported this 3 or 4 years ago even with my disinclination for 
stacks of specs.

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

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

[Michael Thomas]

Oh, good. I'm not the only party pooper. To what Jim wrote, I'll
add:

1) As a developer, multiple documents generally suck. IKE,
 ISAKMP, and their friends. Need I say more?
2) Frameworks almost invariably fail, and that's what I sense
 here. We gave some passing thought to making this usable
 in other contexts, and heck I even wrote a SIP/DKIM signer
 to tweak Fluffy's nose about sip-identity, but the reality
 is that actually getting refactoring done in a way that
 wouldn't ultimately require a new spin of one or more
 documents is, IMO, close to hopeless.
3) Differing document maturity levels. You have one that's
 advancing to draft, and one that one day may be PS. It just
 doesn't seem reasonable to have those two be linked even
 weakly.

I really don't see what the problem would be to take what
we did and just insert it as a whole and then start editing.
If this second use had come a couple three years ago, it
might have been worth considering to rationalize things, but
given how far along we are this is just setting up to be a
big fail.

Mike

On 01/10/2011 05:28 PM, Jim Fenton wrote:
> On 1/7/11 12:37 PM, Barry Leiba wrote:
>
>> As the 4871bis editors worked on resolving the last sets of comments
>> in the 4871bis document, the chairs and the editors had some
>> discussion about other efforts that are interested in re-using
>> portions of the DKIM signing/verifying/key-distribution mechanism
>> outside the email context.  See, for example,
>> http://tools.ietf.org/html/draft-desruisseaux-ischedule.  This would
>> mean using a DKIM-like mechanism to secure the distribution of
>> scheduling events.  That effort is currently referencing (and
>> updating) RFC 4871, but that includes what for them are many
>> irrelevant and inappropriate details that have to do with email.
>>
>> One way we can handle this and other use cases, as we move the DKIM
>> specification along, is to split the specification into two documents,
>> one that describes the underlying components, and a second that
>> describes the email-specific bits.
>>  
> I'm quite unhappy with the proposal to split RFC4871, for a number of
> reasons (in no particular order):
>
> 1. Review Abuse:  We held a Last Call on rfc4871bis that closed on 22
> October 2010.  Many of us put considerable focus into a detailed edit of
> the document at that time, and to hear that other than surgical changes
> to the document in response to Last Call comments is an abuse of many
> peoples' time, and not just mine.  The cited other usage of DKIM
> signatures, iSchedule, was published in March 2010 so it should have not
> been the gating factor.
>
> 2. Charter: The DKIM WG charter states "1. Advance the base DKIM
> protocol (RFC 4871) to Draft Standard.
> This is the first priority for the working group."  A reorganization of
> 4871bis into two documents is inconsistent with the "first priority"
> requirement of the charter.
>
> 3. Risk:  The amount of violence that will need to be done to the text
> of RFC4871 introduces significant risk that the specifications will be
> unclear or inconsistent with 4871.  While the rules for advancing to
> Draft do refer to specifications and not documents, I would be
> uncomfortable with doing anything other than recycling at Proposed to
> see if errata, etc. result from the changes.  But recycling at Proposed
> is inconsistent with the charter.
>
> 4. Usage:  DKIM has quite a bit that is tailored specifically for mail:
> the syntax of the header field, canonicalization, etc.  The proposed
> split includes canonicalization as part of DOSETA, and wonder if that
> really makes sense.  While the syntax of a DKIM signature may be close
> to what's required for iSchedule, will we next need to consider yet
> another split to permit signatures to be expressed in JSON, XML, or
> other formats?  Are there other uses considered besides iSchedule at
> this time?
>
> 5. Security properties:  DKIM was designed to provide a modest level of
> security limited by the security properties of DNS.  This was considered
> acceptable because it's comparable to the level of security afforded
> message routing (since MX records could be spoofed).  Other uses of DKIM
> need to be examined carefully to make sure that we do not depend on an
> insufficiently secure key infrastructure.  While use of DNSSEC mitigates
> this, I'm concerned about whether it will really be used everywhere needed.
>
> 6. Redundancy: Section 10.1 of the iSchedule draft requires the use of
> TLS for all transactions.  Why is DKIM then also needed (if the
> certificate verification happens in both directions, of course)?  Why
> are two very different mechanisms in use?
>
> 7. Openness and Timeliness: Barry has apologized for not announcing this
> a month ago, but I sense that this has been going on in a private design
> team longer than that.  BCP 9 section 1.2 talks to openness and
> timeliness; this fails on both accounts.
>
> -Ji

Re: [ietf-dkim] Statistics about DKIM and MIME

[Michael Thomas]

On 10/25/2010 10:01 AM, Murray S. Kucherawy wrote:
  In the particular case of multipart/signed there were 106 messages where the 
RSA verification failed, but 122 where it passed but the body hash at the 
verifier didn't match the one in the signature.  So more failures occur from 
body changes than do from header changes.

This smells suspiciously like middle boxen doing HIPAA-like things
with SMIME. Let's just blame Jon Callas :)

Mike
___
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

[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] detecting header mutations after signing

[Michael Thomas]

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

Re: [ietf-dkim] sophistry is bad, was Data integrity claims

[Michael Thomas]

Far be it for me to defend Dave, but I think you two are in
violent agreement. I think you misread some of Dave's comment
because they were posed as rhetorical.

Mike

On 10/16/2010 11:56 AM, Scott Kitterman wrote:
> On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote:
>> On 10/16/2010 10:26 AM, John R. Levine wrote:
 Yes, it ties an identifier to a bag of bits, and yes it specifies what
 those bits are, but it really does deal only with those bits and not
 (necessarily) the entire message.
>>>
>>> Technically. you are correct.  Semantically, that's silly.
>>>
>>> We went through backflips trying to figure out how to design the
>>> signatures so that the message modifications they allowed would preserve
>>> the same message, for an ill defined but I think well understood version
>>> of the same.
>>
>> Yes that was the goal.  No that was not the result.
>
> -1.  I think we did that just fine.
>
>> Which header fields are essential to protect?  How much of the message body
>> is essential to protect?
>
> This is completely orthogonal to the question.  As long as a receiver can
> reliably determine what is protected and what is not, then the protection goal
> is achieved.  It does not require that there is agreement on what that should
> be.
>
>> The current DKIM spec does not answer these questions and easily permits
>> protecting very little of the message.  Almost certainly too little to
>> ensure the protection you assert.
>
> One can also point a gun at ones own head.  That doesn't make a gun a suicide
> device of no value for anything else.  The spec does permit people to do silly
> things, but so what.
>
>> That's an example of what I mean when I says that there are assumptions
>> about DKIM that go beyond what it (always) delivers.
>
> Saying it's possible to use DKIM in ways that doesn't support this is not the
> same as saying DKIM doesn't support it.
>
> It's possible to operate any modern MTA as an open relay, but it doesn't
> follow that all MTAs are open relays or that they fail to protect against open
> relaying.
>
>> I guess I should thank you for demonstrating my point.
>
> If you had one that relevant to the discussion, it's not at all clear to me
> what it was or how it was demonstrated.
>
>>> While it's always been possible to sign messages in ways
>>> that allow gross changes, e.g. don't sign the subject or MIME headers,
>>> set l=0, if you sign a message using a normal set of options, the idea
>>> was always that the message the recipient saw would be the one you
>>> signed. Throwing up our hands at the double header trick is, one might
>>> say, ahistoric.  Claiming it's an MUA problem is simply wrong.
>>
>> 1. Your first sentence concedes my basic point
>>
>> 2. There is no commonly-agreed upon and documented concept of "normal set
>> of options" that I'm aware of.  What is normal for you might or might not
>> be normal for the next person configuring DKIM.
>
> True, but irrelevant.
>
> Scott K
> ___
> 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] Last call comment: Changing the g= definition

[Michael Thomas]

On 10/15/2010 10:45 AM, Stephen Farrell wrote:
> In this case, I don't recollect an objection, so thus far, it seems
> to me that Dave's correct on this one. I think its perfectly fine
> for an editor to try to close off things that seem to have a clear
> consensus like this.

Stephen -- the issue here is the procedural one that Dave ignores
*any* input *at all* from people he filters. It doesn't matter
whether it's a typo -- ignored. This has been true of every document
in this working group that he has edited. In the case of 4871-bis
that means that I can have *no* input whatsoever, even though I'm
one of the authors of 4871 and have made substantial contribution
to the community with stats, running code, and general insight about
what running DKIM was like in a large enterprise setting.

I'm fine with Dave not liking me as an individual and choosing to
ignore me, but not with an editor's hat on. If he can't put that
aside as an editor, he should recuse himself and step down.

Mike, nothing I say here makes any difference because of who
   gates the changes.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Michael Thomas]

On 10/15/2010 11:19 AM, Dave CROCKER wrote:
>
>
> On 10/15/2010 1:32 PM, Barry Leiba wrote:
>>>  Dave killfile's
>>> many participants, therefore any consensus he sees will merely reflect
>>> the echo chamber of his own making.
>>>
>>> So I strongly object on procedural grounds
> ...
>>
>> Mike, you needn't object unless the chairs put people in our
>> kill-files, and I can assure you that we don't.
>
>
> Folks,
>
> (First rule of politics and legal trials:  if you can't win on the substance,
> try to win on the process.)

Chairs: I object to the ad hominem attack.

In this case, it is a monkey trail, because Dave simply ignores
(by kill file, or by whatever other means he chooses to employ)
any suggestions of people he has assigned to his bozo filter,
a filter purely of his own making, and not driving by any sort
of working group consensus.

This is why he is an extremely poor choice for being named
editor, a choice that I objected to at the time for this very
reason.

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

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

[Michael Thomas]

On 10/15/2010 10:32 AM, Barry Leiba wrote:
>> I'd like to ask a procedural question of the chairs: Dave killfile's
>> many participants, therefore any consensus he sees will merely reflect
>> the echo chamber of his own making.
>>
>> So I strongly object on procedural grounds for authors who kill file
>> people in general, and for those asking for consensus in particular.
>
> Mike, you needn't object unless the chairs put people in our
> kill-files, and I can assure you that we don't.  There's nothing that
> requires any participant to read the posts by any other participant --
> although as a chair, I'd rather the editors did read all posts related
> to their documents -- but it's up to the chairs to evaluate consensus.

Barry, would that it worked that way. I have on many occasions
supplied text, alternative wording, etc, only be completely
ignored because I'm in Dave's killfile. Editors with killfiles
should not be editors. Period. It completely breaks down the working
group process. It's particularly galling since I'm one of the
AUTHORS and FIRST IMPLEMENTER of the spec under revision.

Remove Dave immediately.

Mike, I prefer this discussion remain public

>
> Therefore, the consensus that goes into the document will reflect what
> the chairs see.
>
> Barry, as chair

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

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

[Michael Thomas]

On 10/15/2010 08:28 AM, Dave CROCKER wrote:
>
>
> On 10/15/2010 10:28 AM, Jeff Macdonald wrote:
>> On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER   wrote:
>>>
>>> Although some folk have done a +1 for one (or another) removal, I'd like to 
>>> get
>>> a round of explicit reactions to the specific idea of removing /both/.
>>
>> +1
>
>
> Folks,
>
> The pattern is completely consistent, so I will take this as agreement to 
> remove
> both.
>
> Anyone objecting very strongly needs to speak up.

I'd like to ask a procedural question of the chairs: Dave killfile's
many participants, therefore any consensus he sees will merely reflect
the echo chamber of his own making.

So I strongly object on procedural grounds for authors who kill file
people in general, and for those asking for consensus in particular.

Mike
___
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

[Michael Thomas]

On 10/15/2010 06:51 AM, Charles Lindsey wrote:
> On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas  wrote:
>
>> I would hope so because this would be a really stupid thing to do.
>> Without the next line of defense -- virus, malware, spam, phishing --
>> you'd be setting your users up for big problems. Just because it's
>> DKIM signed from a good source doesn't mean it's not still evil.
>
> Have you ever seen an evil message from Ebay?

s/Ebay/Yahoo!, etc, yes.

> And yet the current protocol will allow an evil mail _apparently_ from
> Ebay to appear, with no means for the recipient to detect the difference.

They're not apparently from them. They *are* from them.

DKIM is not any indication of whether the content is evil or not,
per se. It just says who to complain to if it is evil.


> And as regards using current malware detection software, can you please
> explain to us how that is supposed to catch an eveil mail signed by a
> brand-new throwaway domain that has not yet had time to acquire any
> reputation, good or bad?

Irrelevant for the current discussion.

Mike
>>
>> That's why all of this hand wringing is silly.
>
> We are not hand wringing. We are pointing out a protocol that, when
> applied in the current (and likely future) Real World, fails to deliver
> what it was intended to deliver.
>

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

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

[Michael Thomas]

On 10/14/2010 11:54 AM, Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen  wrote:
>> Even though I supported the addition of wording on how to improve the
>> compatibility with DomainKeys records, I would support removing the new
>> proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to
>> ask the question: Is it still worth changing that section into a WARNING
>> for people upgrading from DomainKeys, saying to make darn sure that they
>> REMOVE g=; in their old DNS records because of interoperability issues?
>>
>> So the question becomes: if we remove the section on how DKIM and DK can
>> play nice together, 1) do we chop out all references to DomainKeys, or
>> 2) do we keep a short warning on what needs to be changed in the DK
>> record to make it work with DKIM?
>
> I don't see the problem.  If we just remove 3.6.1.1, then, yes, we
> have an issue with migration.
>
> If we remove g= altogether, then we remove the problem: ALL key
> records will be treated as though they had "g=*", which means that the
> problematic situation is treated just as it was in DK, and the key
> records are compatible.
>
> Or am I missing something?

No, that doesn't solve the problem for all of the implementations
that are out there now that implement 4871. Removing g= is only going
to make the situation even worse because you've now taken away the
documentation.

Mike
___
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

[Michael Thomas]

On 10/14/2010 10:47 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: John R. Levine [mailto:jo...@iecc.com]
>> Sent: Thursday, October 14, 2010 10:45 AM
>> To: Murray S. Kucherawy
>> Cc: DKIM List
>> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations 
>> after signing
>>
>>> I think if it becomes well-known that users of MUA 1 are easier to phish
>>> than users of MUA 2, a lot of people will gravitate to the safer
>>> implementation, don't you?  I sure would.
>>
>> Aw, come on.  How many millions of people still use Outlook Express on
>> Windows XP?  Switching MUAs is painful, people rarely do it.
>
> ...meaning MUA developers won't bother to do something about it once the 
> attack is plainly visible and they're used as examples, because since users 
> won't switch anyway, there's no motivation?

Not to mention the false dilemma that this needs to be handled in the
MUA exclusively. It doesn't.

Mike
___
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

[Michael Thomas]

On 10/14/2010 10:15 AM, John R. Levine wrote:
>> If you really think this is such a great big problem, maybe you should be
>> banging the drums at MAAWG or other venues where the correct set of ears
>> is potentially listening.
>
> I would rather not have to run a session at MAAWG entitled "How to fix the
> security holes in DKIM", but I certainly could.
>
> Am I really the only person who wants to be able to whitelist mail signed
> with known good signatures, drop it into user inboxes and expect
> reasonable results with existing MUAs?

I would hope so because this would be a really stupid thing to do.
Without the next line of defense -- virus, malware, spam, phishing --
you'd be setting your users up for big problems. Just because it's
DKIM signed from a good source doesn't mean it's not still evil.

That's why all of this hand wringing is silly.

Mike
___
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

[Michael Thomas]

On 10/14/2010 09:45 AM, John R. Levine wrote:
>> Unless there's *really* something they can't figure out without protocol
>> help, I'm not sure what the point of this is. This double added From thing
>> is trivial to detect with the current spec.
>
> Well, yeah.  That's why I don't understand why people are so opposed to a
> SHOULD saying they should.

Because the audience who ought to be dealing with the larger problem has little 
to
nothing to do with the audience that would have to deal with that MUST/SHOULD.
It's a useless requirement to put on DKIM.

If you really think this is such a great big problem, maybe you should be
banging the drums at MAAWG or other venues where the correct set of ears
is potentially listening.

Mike
___
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

[Michael Thomas]

On 10/14/2010 07:56 AM, Mark Delany wrote:
> On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote:
>>> What is essential is that it perform the task of validating and delivering a
>>> signing domain that is associated with a collection of bits.  Anything that
>>> defines how to do this is essential.  Anything that can make this break 
>>> needs to
>>> be covered, especially if there are ways to protect against the breakage.
>>
>> But isn't the problem that the signing domain is being incorrectly
>> associated with a different collection of bits?
>
> And just to elaborate on my own point. We went thru a lot of
> hand-wringing over canonicalization and the l= tag and so forth
> precisely because we were concerned about associating a signing domain
> with the wrong bits.
>
> But now it seems that making the wrong association is not treated with
> as much concern.
>
> If it is true that the DKIM effort is about associating an identifier
> with a collection of bits, it equally must be true that we want to
> make a similar effort to ensure that identifier is not associated with
> an unrelated collection of bits.

Mark, with a signed bunch of bits you get two prizes for the price
of one: you know which bits are signed, and then you know which bits
aren't. There is no ambiguity in the spec about which bits are signed,
so we're quibbling about the ones that aren't. Isn't this where we
want to have people's secret sauce take over? That is, we want MTA,
MDA, and MUA's to take those two piece of information and make better
decisions about, oh say, rendering? We already know that the DKIM
spec alone is not going to force the hand of recalcitrant or uncaring
MUA's, but it is potentially quite helpful to ones that are receptive.
Unless there's *really* something they can't figure out without protocol
help, I'm not sure what the point of this is. This double added From thing
is trivial to detect with the current spec.

Mike
___
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

[Michael Thomas]

On 10/14/2010 07:58 AM, John R. Levine wrote:
>> Perhaps surprisingly, having redundant header fields does not make
>> DKIM break.
>
> We must have some vastly different definition of "break".
>
> If allowing through modified messages that render very differently isn't
> broken, shouldn't we remove the advice against signing with l=0? The
> advice in favor of signing Subject: and To: fields? None of those has
> any technical effect on the ability of a verifier to compute and compare
> hashes.

There is an enormous difference between the situations with DKIM and,
say, TLS+X509. With TLS, you take the output of the checks and use
THAT ALONE to decide to deliver the bits or not. DKIM has *never*
been such a protocol: there is a vast backstop of security infrastructure
where DKIM is a just helper.

Like I said, give spam/phishing filter writers some credit. They
are not idiots.

Mike


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

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

[Michael Thomas]

On 10/13/2010 02:47 PM, John Levine wrote:
>
>> DKIM simply highlights an issue that's been there for a very long time now.
>
> No.  No, no, no, no, no.  Malformed messages only become an issue when
> someone aserts that they're not malformed.  In the absence of DKIM
> signatures, the reasonable thing to do with a malformed message is to
> render it.  In the presence of a DKIM signature, the reasonable thing
> is something else.  That's why this is a DKIM issue.

Huh? I think it's highly debatable about whether it's reasonable to just
render a malformed message, especially in this day and age. Which is why the
addition of DKIM is largely orthogonal.

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

Re: [ietf-dkim] What DKIM provides, again

[Michael Thomas]

On 10/13/2010 12:47 PM, Jeff Macdonald wrote:
>> Then you send me a piece of signed mail, I change everything except the 
>> Message-ID and Date, and send it to someone else.  And the verifier will 
>> green-light it, meaning you've taken responsibility for it.  Are you OK with 
>> that?
>>
>> My way of thinking about this is that verification of a message is 
>> equivalent to collecting all the pieces (header, body, signature) and coming 
>> to you and saying "Do you take responsibility for this?"  If I get your 
>> public key from DNS and everything lines up, you're implicitly saying "yes".
>>
>> Now, if I remove the whole body and most of the header from what I'm 
>> presenting to you for that question, you're now possibly saying "yes" to 
>> content you didn't create.  Are you OK with that?
>
> The only thing I'm willing to say "yes" to is that I created that
> identifier and nothing more.
>
> Enhancements to my rant would be to include the To: header as well.
>
> The point is DKIM provides a verifiable identifier. If there is
> anything in the spec that leads one to believe it provides more than
> that, it needs to be fixed.
>
> But like I said, I was ranting.

Jeff, an identifier that's not bound to something is useless. It's
like "Mike" just bouncing around the aether. Until it binds to
something, it's not providing anything useful and certainly not
something you'd want to alter the message disposition.

Mike

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

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

[Michael Thomas]

On 10/13/2010 11:25 AM, Scott Kitterman wrote:
> On Wednesday, October 13, 2010 11:55:25 am Steve Atkins wrote:
>> On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote:
>>> or
>>> a special selector (e.g. s=notifications), to identify the different
>>> nature of this mail stream?
>>
>> No. Never do this.
>>
>> Selectors are an operational convenience for key rotation and
>> ease of domain delegation. They have no semantics beyond
>> being used to query DNS to find the public key.
>
> Sure.  That's the right answer from a standard POV, but if I can extract
> statistically significant information by segregating mail streams by selector,
> I'll do it anyway, I don't care what the standard says (no, I haven't done
> this analysis yet, so I don't have an opinion on if one actually could do it
> or not).

Better: how does one slap the wrist of a Bayesian filter?

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

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

[Michael Thomas]

On 10/07/2010 05:01 PM, John R. Levine wrote:
>>> I'd say that it would be better to just say that if you sign a
>>> non-compliant 5322 message that its verification is undefined,
>>> and move on. That at least matches reality, and hasn't hurt
>>> anything that I'm aware of.
>
> Except that's not the situation we have here.
>
> a) Author creates a 100% compliant message
>
> b) Signer signs 100% compliant message
>
> c) Bad guy adds an extra header, making it non-compliant, and sends it to
> someone
>
> d) Receiver receives it and, uh, well, what?
>
> Nobody has signed a non-compliant message, so while there is nothing wrong
> with Mike's advice, it completely misses the point.

You're right, it does miss the point. What I'm trying to get my
head around is whether this is a real problem in the real world.
Any reasonable spam filter would notice evil double From:'s in
a New York minute, so I can't get particularly worked up about
this being some sort of existential threat. Can someone come
up with a scenario where this really could be evil and isn't
trivially fixed by... making spam filters insist that they're
really receiving valid 5322 as one of their rules?

Mike, I only have vague recollection of the h= trick anymore...

>
> As far as I can tell, this problem, detecting header changes, is a
> security problem that has never come up before.  PGP, S/MIME, and PEM only
> protect the body, in some cases by wrapping the entire message as a
> message/rfc822 MIME body part and signing that.  RFC 2822 and its
> predecessors tell you what is a valid message, but say approximately
> nothing about invalid messages other than a few historically motivated
> notes like bare linefeeds really are invalid.  I think I can safely say
> that there is no chance at all that Pete Resnick et al. would agree to
> change 2822bis to fix holes in DKIM.
>
> I'm scratching my head to see if there is any advice we can offer to make
> signing and verification more robust while not changing the behavior of
> existing code for normal (for some definition of normal messages).
>
> A) You have to sign either all occurences of a header or none of them, and
> a message with some but not all occurences signed fails verification. This
> is probably too strong, although I doubt that there are many places in
> practice where it would matter.
>
> B) Same as A, but limited to an enumerated set of headers that are
> supposed to occur only once.
>
> c) Same as B, but tell signers to use the h= trick to make verification
> fail if extra headers show up.
>
> R's,
> John
> ___
> 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] THIS IS A MULTIPLE 5322.FROM MESSAGE

[Michael Thomas]

On 10/07/2010 11:01 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Michael Thomas
>> Sent: Thursday, October 07, 2010 9:09 AM
>> To: Charles Lindsey
>> Cc: DKIM
>> Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
>>
>> I'm with Steve on this one. Forcing implementations of DKIM to
>> determine whether a message is compliant is a pretty high bar. I
>> for one wouldn't be in any particular big hurry to add a batch of
>> code to insure that that MUST was fulfilled. I doubt anyone else
>> would be either. The net effect of this MUST would be to make a
>> lot of compliant DKIM implementations non-compliant. And for what?
>
> I disagree that it's all that tough.  Any DKIM implementation already has to 
> have some code to isolate particular header fields so that they can be 
> replayed in the order "h=" states, for example.  Code to verify there's only 
> one From: (plus the rest of the min/max counts that RFC5322 defines) in that 
> set can't be that expensive.  Granted that only covers the chart in section 
> 3.6 of RFC5322, but it would completely handle this problem vector.
>
> And there are plenty of open source MTA implementations, the union of which 
> contains a variety of validity checking code that can be used to come up with 
> a valid solution to satisfying the entire RFC.

The larger issue here is would anybody rush out to close this MUST.
I think that it is highly unlikely that anybody is going to care at this
point. That goes for *any* new MUST, IMO: unless it's really a serious
protocol endangering problem, it shouldn't be in the -bis document. Save
new MUST's for genuine emergencies.

>> I'd say that it would be better to just say that if you sign a
>> non-compliant 5322 message that its verification is undefined,
>> and move on. That at least matches reality, and hasn't hurt
>> anything that I'm aware of.
>
> Generally I agree, but does saying "verification is undefined" satisfy those 
> concerned that this is a security vulnerability?  The example of double-From: 
> shows verification succeeds.  It's the interpretation of those results that 
> is the problem.

These are two separate questions, I think. I'm only commenting on whether
DKIM should be the SMTP police.

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

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

[Michael Thomas]

On 10/07/2010 03:40 AM, Charles Lindsey wrote:
> On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkins
> wrote:
>
>> On Oct 6, 2010, at 1:47 AM, Mark Delany wrote:
>
>>> Right. We could attempt to enumerate the 1,000 edge-cases we know
>>> today and then re-bis 4871 for the additional 1,000 edge-cases we
>>> learn tomorrow, or we could simply say that invalid 2822 messages
>>> MUST never verify and call it a day.
>>
>> To comply with that MUST every DKIM verifier would have to
>> include a full 5322 verifier. That's a fairly high bar.
>
> No, that is not true, as I have demonstrated in the text I have proposed.
>
> You only need to look at whatever headers are actually mentioned in the
> "h=" tag of the signature, and you only need to verify those properties of
> those headers that could lead to trouble, and that would seem to be a
> simple count of the number of occurrences of those headers.

I'm with Steve on this one. Forcing implementations of DKIM to
determine whether a message is compliant is a pretty high bar. I
for one wouldn't be in any particular big hurry to add a batch of
code to insure that that MUST was fulfilled. I doubt anyone else
would be either. The net effect of this MUST would be to make a
lot of compliant DKIM implementations non-compliant. And for what?

I'd say that it would be better to just say that if you sign a
non-compliant 5322 message that its verification is undefined,
and move on. That at least matches reality, and hasn't hurt
anything that I'm aware of.

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

Re: [ietf-dkim] signing and verifying invalid messages

[Michael Thomas]

On 10/05/2010 01:36 PM, John Levine wrote:
>> Still, though, it's a solution to deal with malformations to which
>> MUAs are susceptible, and not strictly a DKIM problem.
>
> Would it be a good idea to recommend in 4871bis that DKIM
> implementations should not sign or verify invalid messages?  I
> cheerfully admit that I haven't thought out all the implications
> thereof.

I'd suggest that it would be better to take that up with
rfc5822-bis since this is hardly a dkim-specific problem.

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