Re: [ietf-dkim] DKIM and EAI

[Scott Kitterman]

On Friday, February 09, 2018 05:02:00 PM John R. Levine wrote:
> > If I may once again change the topic for a moment ...
> > 
> > https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/
> 
> I pushed out a new version that says something about SPF macros,
> attempting to say that if you try to expand a UTF-8 local part, it doesn't
> match anything.  I figure this is consistent with what would happen if
> your local part was something like foo..bar which won't match anything
> either.
> 
> I would appreciate if people would take a look and see if anything seems
> obviously wrong.  I'm doing some EAI whitepapery things for ICANN and it
> would be nice if, for a change, the advice they offer matches reality.

Thanks.  I think that's a reasonable resolution of the SPF macro issue that I 
raised.  Not ideal, in theory, but plenty good enough for the corner case it 
is.

Does this need to update RFC 7208 since there are SPF related MUST 
requirements?

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

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

[Scott Kitterman]

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

That's great to hear.

You might suggest (if it's someone that does DMARC p=reject) that if they can 
manage to stop signing reasonably likely (FSVO reasonable) spam they'll get 
roughly what the proposed protocol change would have provided for that mail 
without having to wait for the world to upgrade.  Direct mail would still pass 
DMARC due to SPF.

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

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

[Scott Kitterman]

Note: Not cc'ing the DMARC list as this is a DKIM only draft.

Given the discussions about twice ranging implications of a change like this 
(the end of email where RCPT TO changes in transit to start), the document 
needs far more discussion regarding the impact on the current email 
architecture before it can be considered in any way complete.

As much as I appreciate having my input acknowledged, please remove me from the 
acknowledgement section.  If this proposal is going to go forward, I don't want 
my name on it anywhere.

Scott K

On November 15, 2016 7:45:52 PM CST, "Murray S. Kucherawy" 
 wrote:
>There's been a lot of great feedback here.  I just cranked out an
>update
>based on the discussion so far:
>
>https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01
>
>I forgot to update the title of Section 3, but other than that I think
>I
>captured what's been discussed.  Please let me know what I've missed.
>
>-MSK
>
>
>On Tue, Nov 15, 2016 at 8:07 AM, Murray S. Kucherawy
>
>wrote:
>
>> On Mon, Nov 14, 2016 at 10:36 PM,  wrote:
>>
>>> Let's break this down. If we're going to include recipients in the
>DKIM
>>> signature, it seems we have at least three key design decisions to
>make:
>>> [...]
>>>
>>
>> That's a pretty excellent summary.  A couple of points:
>>
>> I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b)
>being
>> the ideal choices.  Is that correct?  If so, we would just need to
>> determine the algorithm for generating the signed content that would
>be
>> included in the augmented signature.  If we do something like the
>random
>> salt suggestion, is this sufficient?
>>
>> - pick a random string S of length L using only printable ASCII
>characters
>> (I like 8 for L but that's arbitrary)
>> - SHA the string produced by prepending S to the recipient address,
>and
>> express the result in base64 string R
>> - include R in a new "er" (envelope recipient) tag and the salt S in
>an
>> "rs" (recipient salt) tag
>>
>> This is not reversible so nothing is leaked, but as we've all
>conceded by
>> now it's not hard to attack this to recover the hashed address
>especially
>> since one might have good guesses as to what that address would be.
>>
>> I can't see the point of actually encrypting the hashed content,
>because
>> anybody can decrypt it with the public key.
>>
>> What am I missing?
>>
>> -MSK
>>
>
>
>
>
>___
>dmarc mailing list
>dm...@ietf.org
>https://www.ietf.org/mailman/listinfo/dmarc

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

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

[Scott Kitterman]

On November 15, 2016 10:53:19 AM CST, Martijn Grooten 
<mart...@lapsedordinary.net> wrote:
>On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote:
>> OK.  Ultimately, "don't sign spam" has got to be the solution or
>reputation is 
>> going to suffer, so I think they are going to have to eventually bite
>the 
>> bullet and fix it.
>
>I think you underestimate how difficult it is to detect spam in cases
>like this. Good spam, from a spammer's point of view, looks like
>legitimate email, except that it's sent in bulk, or links to some bad
>site (malware/phishing), or has a malicious attachment. The attachment
>aside, none of this has to be present when the first instance of the
>email is sent (and signed). And even detecting new malware isn't as
>trivial as it may sound.

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).

Given that scenario, they've already done the hard part.

All the protocol solutions being discussed have huge negative implications for 
email.  I've yet to see a proposal I think should be implemented (my suggestion 
about a now DMARC policy option still seems the least bad to me, but I don't 
particularly like it).

Scott K

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

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

[Scott Kitterman]

On Monday, November 14, 2016 05:34:19 PM Murray S. Kucherawy wrote:
> On Mon, Nov 14, 2016 at 4:37 PM, Scott Kitterman <ietf-d...@kitterman.com>
> 
> wrote:
> > >Doesn't that presuppose point-to-point handling?  The proposal here
> > >doesn't.
> > 
> > Your proposal breaks all non-point-to-point handling, if I understand it
> > correctly, so whether you make DKIM signatures non-forwardable or do it in
> > DMARC policy, it's the same end result.
> 
> How does it break all non-point-to-point handling?  It does break if the
> envelope has to change, but that's not what I think of when you say
> "point-to-point"; it makes me think of mail from A to C that happens to
> transit B, which should survive just fine.

Within an ADMD, internal relaying should survive just fine, since, as you say, 
RCP TO doesn't change, but I don't think that's an interesting case.  Email 
authentication check tend to be very fragile if not done at the edge of the 
ADMD for lots of reasons.

What I was thinking of was non-point-to-point handling while between two 
ADMDs.  Typically mailing lists or transparent forwarding.  In both of those 
cases, RCPT TO changes.  One set of advice given to mailing list operators 
about DMARC has been to change their list setup so that they don't break DKIM 
signatures (and some have done that).  This proposal would make that 
impossible.

Between two ADMDs, you would not be able to change RCPT TO, so it would have 
to go direct.  At that point, if you engage DMARC alignment requirements on 
the SPF check, you achieve the same result.

Also, if you make this a DMARC policy choice, then the added restrictions 
associated with restricting changes to RCPT TO only affect senders that have 
opted into the policy choice.

> > I think your pushing a substantial change to DKIM and to the extent this
> > is a reasonable problem to solve, DKIM isn't the right layer in the email
> > authentication stack to do it.
> 
> Ah, yes, that's a plausible argument.
> 
> > I think the solution to "I have a problem that results when I sign spam"
> > is "don't do that", not the entire community turns on its head to work
> > around someone's local configuration problems.
> 
> Yes, I agree that's the preferable solution.  It sounds as if there are
> some operators (well, at least one, I think) that are having a problem for
> which "don't do that" is an expensive solution, and a question has been
> posed about the possible existence of an easy, incremental protocol
> solution for it.  It's fine if the answer is "no", but I'd like to have the
> discussion without prematurely slamming any doors.

OK.  Ultimately, "don't sign spam" has got to be the solution or reputation is 
going to suffer, so I think they are going to have to eventually bite the 
bullet and fix it.  I don't think an opt-in extension to DMARC like I suggest 
above is unreasonable and I think it would be able to be deployed more 
quickly.  So far though, I don't see fixing it in DKIM as a good way to go.

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

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

[Scott Kitterman]

On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy" 
<superu...@gmail.com> wrote:
>On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman
><ietf-d...@kitterman.com>
>wrote:
>
>> Wouldn't a DMARC option to allow senders to specify only messages
>that
>> pass verification and alignment for BOTH SPF and DMARC accomplish the
>same
>> result with less complexity and without the layering violation
>inherent in
>> this proposal?
>>
>
>Doesn't that presuppose point-to-point handling?  The proposal here
>doesn't.

Your proposal breaks all non-point-to-point handling, if I understand it 
correctly, so whether you make DKIM signatures non-forwardable or do it in 
DMARC policy, it's the same end result.
>
>> DMARC seems to be the policy engine of choice in the community (for
>better
>> or for worse).  I think addressing this at the policy level makes
>more
>> sense than changing the semantics of DKIM signatures after almost a
>decade
>> of deployment.
>>
>
>As the problem was presented to me, I haven't heard that DMARC is
>specifically involved here.  It might be (maybe even "probably" is
>apt),
>but I haven't heard that, so I limited this idea to just the DKIM
>signing
>and verifying components of the system.

I think your pushing a substantial change to DKIM and to the extent this is a 
reasonable problem to solve, DKIM isn't the right layer in the email 
authentication stack to do it.
>
>> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately
>> convinced I'd want to enable this feature.  I don't know if other
>distro
>> maintainers are on this list or not, but that's one opinion.  It's
>not
>> guaranteed to be widely deployed.
>>
>
>Why is this a distribution issue?

Because so far this looks like a source of interoperability problems and bug 
report headaches I could do without.

I think the solution to "I have a problem that results when I sign spam" is 
"don't do that", not the entire community turns on its head to work around 
someone's local configuration problems.

Scott K

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

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

[Scott Kitterman]

On November 13, 2016 1:50:05 AM EST, "Murray S. Kucherawy" 
 wrote:
>I've posted a draft that attempts to address an attack that's begun to
>appear with DKIM.  Interestingly, we called it out as a possible attack
>in
>RFC6376 and even RFC4871, but now it's apparently happening and being
>annoying enough that people (I believe from the MAAWG community) are
>asking
>if there's a protocol solution that's possible.
>
>https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/
>
>Comments welcome.

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

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

Scott K

P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately convinced 
I'd want to enable this feature.  I don't know if other distro maintainers are 
on this list or not, but that's one opinion.  It's not guaranteed to be widely 
deployed.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM Key Sizes

[Scott Kitterman]

On Sunday, October 30, 2016 05:50:33 PM John R. Levine wrote:
> > It's also probably worth ensuring that the major open source DKIM
> > implementations support both signing and verifying with 4096-bit keys.
> > Aside from OpenDKIM and dkimpy, are there any others that should be
> > checked?
> Perl Mail::DKIM is still widely used.  It calls Crypt::OpenSSL::RSA which
> is a wrapper around openssl so I'd be surprised if it had trouble with
> large keys.

There's also https://sourceforge.net/projects/libdkim/ by ALT-N.

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

Re: [ietf-dkim] DKIM Key Size Constraints

[Scott Kitterman]

On Tuesday, May 12, 2015 09:27:51 PM Murray S. Kucherawy wrote:
 On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman ietf-d...@kitterman.com
 
 wrote:
   Is it appropriate to change the protocol document for this?  Isn't it
   really more of a BCP?
  
  I think when key size got put in the protocol, then it's a protocol update
  to
  change it.
 
 Is it part of the protocol, or is it part of the prose around the protocol?
 
 The DKIM algorithms don't break if you use weak keys any more than they
 break if you put false information in a header field.  More generally, I
 don't believe DKIM itself cares about the size of the key.  All of our
 advice absolutely does, and rightly so.
 
 Do we have any other crypto-related protocols where the protocol itself
 legislates the appropriate key parameters for the encoding, decoding,
 signing or verifying?  Section 6 of RFC3207 (STARTTLS) explains explicitly
 that it's a local matter and out of scope, for example.  I scanned
 RFC4033-4035 (DNSSEC) and didn't see any restrictions or advice about key
 size selection at all.  I always go cross-eyed when I try to read the TLS
 RFCs so I'll stop there for now.  ;-)
 
  The size of the key doesn't affect interoperability, but rather the
  
   receiver's choice to accept the signature as valid when it's based on a
   weak key.
  
  To me that's equivalent to saying choice of crypto algorithm doesn't
  affect
  interoperability since it only affects the receivers choice to accept the
  signature as valid.
 
 There's also nothing wrong with a receiver deciding it doesn't like
 signatures that use relaxed canonicalization, SHA1, or decline to sign the
 Subject header field.  The algorithm itself worked fine -- that's
 interoperability -- but the receiver doesn't like one of the parameters the
 signer used and thereby makes a local policy decision.
 
 You have to set a floor below which it's not reasonable to accept
 
  signatures as
  valid.  Since receivers have no way to vet sender's key rotation policies,
  taking an out like RFC 6376 and its predecessors do and say that keys
  smaller
  that 1024 bits are OK for keys that aren't long lived is not tenable. 
  That
  and since DKIM was first deployed, at least for 512 bit keys, the not long
  lived required to meet even the modest security goals of DKIM are
  substantially shorter than the amount of time typically needed to ensure
  that
  mail deliveries are completed (some fraction of a day at longest).
  
  Key lengths less than 1024 need to be killed dead.
 
 I don't argue with any of that, except to say again that I'm not convinced
 DKIM, the protocol, has to suddenly break for small keys.  I absolutely
 agree with a BCP statement of some kind, and I also agree in retrospect
 that the not-long-lived key advice in RFC6376 is probably not helpful.
 (You could in theory observe the timestamp of when you first saw a key and
 then watch how long it gets used, but that puts an unreasonable burden on
 receivers.)

It's been known for years (see the original reference I provided) the 512 bit 
keys were trivially spoofable.  All open source implementations I'm aware of 
have not accepted keys  1024 bits for several years.  The only sudden is in 
an abstract sense if one hadn't been paying any attention at all to 
operational reality regarding DKIM.  I don't view this as a functional change 
to the operational protocol as much as making the IETF paperwork match that 
reality (which I think is important).  We're already several years late 
writing this, so I don't think any alleged suddenness should be considered at 
all.

If you take out the poorly considered aspect of giving an exception to the 
existing MUSTard about short lived keys (which is never defined), 1024 bits has 
always been the limit, it's just that people often ignored it.  Rapid key 
rotation is not something that's generally done.

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

I think the considerations for other protocols might be different.  I'd rather 
focus on DKIM for the moment.  Once you get to all, it's no longer a quick, 
easy update.

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

That is the issue in question.  I copied the URL

Re: [ietf-dkim] DKIM Key Size Constraints

[Scott Kitterman]

On May 12, 2015 7:28:25 AM EDT, Hector Santos hsan...@isdg.net wrote:
-1

Please stop! No more DKIM code changes ok?  The IETF just made it a
STD.

Maybe we should remove the STD status first, move it back to proposed 
standard or experimental if this and other changes are coming.

If signers want 1024 bits, then can do so ready.

True, but irrelevant.

The change that's needed is to remove the requirement for receivers to verify 
signatures with keys to small to be secure. 

Any cryptographic protocol will need periodic adjustment to remain secure.  I'm 
surprised you are surprised. 

Presumably your implementation already checks for the current minimum key size 
of 512 bits. If changing that constant to 1024 is too hard, I think you're 
doing it wrong. 

Scott K

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

Re: [ietf-dkim] DKIM Key Size Constraints

[Scott Kitterman]

On Tuesday, May 12, 2015 03:35:37 PM Murray S. Kucherawy wrote:
 On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten 
 
 martijn.groo...@virusbtn.com wrote:
   Why remove 512 support from the verification side?  Does this mean the
   verifier will take valid 512 signature and make it invalid, no signature
   message?  Is there a correlation out there that 512 bits signers are
   more
   prune to be Bad Guys? Spammers?
  
  The problem here is that 512-bit keys can be trivially broken: it takes
  less than 8 hours and about 100 USD to do so[1]. So there is no way to be
  certain that the signer of the message is the same organisation that
  published the (512-bit) DKIM key, even if that organisation only were to
  send email that everyone would want to receive.
  
  You are right to point out that the RFC says that [t]he security goals of
  this specification are modest, which indeed they are, but I think 100 USD
  is well within the means of the kind of adversary DKIM is trying to
  protect
  against. The story of Google's 512-bit key that Scott already pointed
  to[2]
  gives at least some anecdotal evidence about why this matters in practice.
 
 Is it appropriate to change the protocol document for this?  Isn't it
 really more of a BCP?

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

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

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

I think that of course it's an interoperability issue.  There has to be a 
meeting of the minds on key signing and key verification in order for DKIM to 
be interoperable.

 I'm not arguing that it's a bad idea to discourage this practice, but
 rather ruminating about whether this is the right way to do it.
 
 Then again, RFC6376 doesn't expressly say that keys smaller than 512 have
 to be accepted either.  Hmmm.

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

Key lengths less than 1024 need to be killed dead.

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

Scott K

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

Re: [ietf-dkim] DKIM Key Size Constraints

[Scott Kitterman]

On Monday, May 11, 2015 07:23:58 PM John Levine wrote:
 I propose a short draft that updates 6376 to say MUST use at least 1024
 bits and setting that as the minimum size verifiers must be able to
 validate.  I'm volunteering to write it if people agree it's appropriate.
 
 That seems fine.  This makes the usable range fairly small, since keys
 longer than 1536 run into the 512 byte DNS packet limit which shouldn't
 still be an issue 16 years after EDNS0 was introduced, but is anyway.  I
 don't see that as a problem, but it's likely worth mentioning.

The last time I saw an interoperability problem related to EDNS0 was this 
month, so while I generally agree, the impact is still non-zero (it may be 
time to decide we don't care), but either way, I'm not proposing we do 
anything other than raise the floor for this update in order to avoid having to 
decide about things like this.

 With regards to Doug's point, yeah, we could have other ways to
 distribute keys like, say, a new DNS record type that has a binary
 key.  For some reason, that gives me a bad feeling.

Even if it was a good idea, it wouldn't be a quick update.

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

[ietf-dkim] DKIM Key Size Constraints

[Scott Kitterman]

RFC 6376 (which I think is the latest) includes:

 3.3.3.  Key Sizes
 
Selecting appropriate key sizes is a trade-off between cost,
performance, and risk.  Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
long-lived keys.  Verifiers MUST be able to validate signatures with
keys ranging from 512 bits to 2048 bits, and they MAY be able to
validate signatures with larger keys.  Verifier policies may use the
length of the signing key as one metric for determining whether a
signature is acceptable.

Since receivers have no good way of knowing what keys are long-lived, there's 
no way on the receiver side to reliably determine if a key shorter than 1024 
bits is being appropriately used or not.  I think it's time to kill keys 
shorter than 1024 bits dead.  It's not like the risks associated with them are 
new [1].

I propose a short draft that updates 6376 to say MUST use at least 1024 bits 
and setting that as the minimum size verifiers must be able to validate.  I'm 
volunteering to write it if people agree it's appropriate.

Scott K


[1] http://www.wired.com/2012/10/dkim-vulnerability-widespread/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Scott Kitterman]

On Saturday, July 09, 2011 07:19:17 PM Michael Deutschmann wrote:
 One additional thought on the whole double-From: argument -- if RFC
 language on the issue is justified at all, it really belongs in the
 ADSP RFC, not a core DKIM one.
 
 A double-From: doesn't even rise to the level of theoretical threat
 except when dealing with ADSP (or a successor).

The abstract for RFC 4871 starts ...

 DomainKeys Identified Mail (DKIM) defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology to permit verification of the source and
   contents of messages by either Mail Transfer Agents (MTAs) or Mail
   User Agents (MUAs).  The ultimate goal of this framework is to permit
   a signing domain to assert responsibility for a message, thus
   protecting message signer identity and the integrity of the messages
   they convey  ...

Verification of source and contents is fundamental to the DKIM requirements.  
If it's not, the assertion of responsibility is meaningless (maintaining the 
assertion of responsiblity even though the message has been modified in a 
meaningful way is nonsense).  

I wish we could have removed l= for this reason.

I think we should make it clear that singleton header fields like From (and 
Subject and Date) can be added without breaking signatures unless one is 
careful as a signer and/or a verifier.  This is related to a core DKIM design 
principle and doesn't need ADSP (or other non-standard measures) for it to be 
something we should care about.

I haven't had time to carefully parse all the proposed language, so I'm not 
going to comment on the specifics of the current proposals, but I think it's 
just flat out wrong to claim that payload integrity is unrelated to DKIM.  

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

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

[Scott Kitterman]

On Thursday, July 07, 2011 01:59:17 AM Michael Deutschmann wrote:
...
 In real life, however, if you don't have the power to demand that a
 recipient mail admin block incoming double-From: messages, then you don't
 have the power to demand that they deploy DKIM at all.
...
I think you are confusing protocol with implementation.  There's nothing the 
prevents receivers from ensuring messages that have been modified after signing 
with an additional From fail verification.

I'm working with someone on an implementation and I think we're going to 
assume one more From than listed in h= when verifying to ensure nothing has 
been added.

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

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

[Scott Kitterman]

On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
  Sent: Thursday, July 07, 2011 6:32 AM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
  
  I'm working with someone on an implementation and I think we're going to
  assume one more From than listed in h= when verifying to ensure nothing
  has been added.
 
 This intentionally causes the verifier to assume what the signer really
 meant when it signed a message using a single From: field.  That may look
 safe but it isn't what DKIM actually says.
 
 We might do this for libopendkim somewhere down the line, but it would
 default off.
 
 In any case, interesting idea.

It only assumes that the signer signed all the From: fields present in the 
message (note: I said one more than in h=, not two).  I think it's fair to say 
that if someone is sending messages with multiple From: fields (or 
Date:/Subject:) and trying to sign something less than all of them they are 
fairly deep into unsupported territory and shouldn't find any result 
surprising.

I agree it's not exactly what is specified in the protocol, but this is an  
implementation design issue.  I think it's safe.  If the DKIM protocol says I 
can't do something like this, then I think we have a problem with the current 
describe it and let implementors deal with it plan.

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

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

[Scott Kitterman]

I don't think so, but I'll definitely test it.  If it does, then we won't do it 
that way.

Scott K

On Thursday, July 07, 2011 12:51:06 PM McDowell, Brett wrote:
 Will your assume one more From than listed in h= lead to failed
 verifications on messages that actually follow the advice in the RFC to
 list duplicate headers in their h= values?
 
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
  boun...@mipassoc.org] On Behalf Of Scott Kitterman
  Sent: Thursday, July 07, 2011 12:44 PM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
  
  On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
Sent: Thursday, July 07, 2011 6:32 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group
review

I'm working with someone on an implementation and I think we're
going to assume one more From than listed in h= when verifying to
ensure nothing has been added.
   
   This intentionally causes the verifier to assume what the signer
   really meant when it signed a message using a single From: field.
   That may look safe but it isn't what DKIM actually says.
   
   We might do this for libopendkim somewhere down the line, but it would
   default off.
   
   In any case, interesting idea.
  
  It only assumes that the signer signed all the From: fields present in
  the message (note: I said one more than in h=, not two).  I think it's
  fair to say that if someone is sending messages with multiple From:
  fields (or Date:/Subject:) and trying to sign something less than all of
  them they are fairly deep into unsupported territory and shouldn't find
  any result surprising.
  
  I agree it's not exactly what is specified in the protocol, but this is
  an implementation design issue.  I think it's safe.  If the DKIM
  protocol says I can't do something like this, then I think we have a
  problem with the current describe it and let implementors deal with it
  plan.
  
  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] Final update to 4871bis for working group review

[Scott Kitterman]

On Thursday, July 07, 2011 12:47:52 PM Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
  Sent: Thursday, July 07, 2011 9:44 AM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
  
  I agree it's not exactly what is specified in the protocol, but this is
  an implementation design issue.  I think it's safe.  If the DKIM
  protocol says I can't do something like this, then I think we have a
  problem with the current describe it and let implementors deal with it
  plan.
 
 It's definitely not proscribed by DKIM.  All I meant was that you're
 preventing a signer from deliberately accepting responsibility for a
 message thus modified (by doing only one from in h=), knowing the
 risks of doing so.

Yes.  I can live with that.

Thanks,

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

Re: [ietf-dkim] MLMs and signatures again

[Scott Kitterman]

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

I think this has it rather backwards.  If mail From (body From) a certain 
domain arrives 999 time with a valid DKIM signature and on the 1,000th time it 
arrives with either no signature or a broken one, then that's a negative 
anomaly in the mail stream that receivers are quite likely to take notice of.  
While ADSP is the public whipping boy for this, there are plenty of private 
efforts based on doing exactly this.

The question isn't do I trust the ML or not.  For domains with a non-trivial 
number of users the overall mail system will have no idea about what ML should 
be trusted or not.  The question is how harshly do I treat this message based 
on the lack of a good signature.

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

Re: [ietf-dkim] MLMs and signatures again

[Scott Kitterman]

On Thursday, May 26, 2011 07:15:25 PM MH Michael Hammer (5304) wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
  boun...@mipassoc.org] On Behalf Of Scott Kitterman
  Sent: Thursday, May 26, 2011 7:07 PM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] MLMs and signatures again
  
  On Thursday, May 26, 2011 03:21:19 PM Steve Atkins wrote:
   If the reputation of the MLM is poor enough that mail from it is not
   being
   delivered, trumping that with an authors reputation may get
   individual
   emails delivered - but not threads, so it doesn't really improve the
   value
   provided to the recipient (it probably decreases it - a mailing list
   that
   delivers one in ten posts to my inbox is less useful than one that
   delivers none at all).
  
  I think this has it rather backwards.  If mail From (body From) a
  certain
  domain arrives 999 time with a valid DKIM signature and on the 1,000th
  time it
  arrives with either no signature or a broken one, then that's a
  negative
  anomaly in the mail stream that receivers are quite likely to take
  notice of.
  While ADSP is the public whipping boy for this, there are plenty of
  private
  efforts based on doing exactly this.
  
  The question isn't do I trust the ML or not.  For domains with a non-
  trivial
  number of users the overall mail system will have no idea about what
  ML should
  be trusted or not.  The question is how harshly do I treat this
  message based
  on the lack of a good signature.
  
  Scott K
 
 The other piece of the equation is how often do I see abusive mail
 purporting to be from this domain with no signature while mail from this
 domain that is normally signed has no significant problems.

True.  That could be a factor as well.  

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

Re: [ietf-dkim] MLMs and signatures again

[Scott Kitterman]

On Thursday, May 26, 2011 07:40:17 PM Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer
  (5304) Sent: Thursday, May 26, 2011 4:15 PM
  To: Scott Kitterman; ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] MLMs and signatures again
  
  The other piece of the equation is how often do I see abusive mail
  purporting to be from this domain with no signature while mail from this
  domain that is normally signed has no significant problems.
 
 I posted the results of some research on that very question earlier this
 week:
 
 http://mipassoc.org/pipermail/ietf-dkim/2011q2/016656.html

My experience is it varies a lot by domain.  Some domains are phishing targets 
and some aren't.  If it's not a phishing target DKIM doesn't matter much 
either way.  If it is, then if they can manage to sign all their outbound mail 
signed/not signed gets to be useful.  So I don't think looking at global 
status is a very useful basis for deciding the question.

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

Re: [ietf-dkim] MLMs and signatures again

[Scott Kitterman]

On Thursday, May 26, 2011 11:00:04 PM Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
  Sent: Thursday, May 26, 2011 5:36 PM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] MLMs and signatures again
  
  My experience is it varies a lot by domain.  Some domains are phishing
  targets and some aren't.  If it's not a phishing target DKIM doesn't
  matter much either way.  If it is, then if they can manage to sign all
  their outbound mail signed/not signed gets to be useful.  So I don't
  think looking at global status is a very useful basis for deciding the
  question.
 
 So you'd rather I run this on some signing domains that aren't obvious
 phish targets?  I can do that.  If you have a few you think might be
 interesting, send me the names; if not, I can see if I can come up with
 some just based on the numbers.
 
 And I can constrain it to a specific reporting site (e.g., my own) instead
 of all reporters if you think that gives a more interesting view.

I was thinking the opposite.  Look at phish targets that sign pretty reliably.  
I'll contact you offlist with some ideas on which.

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

Re: [ietf-dkim] 8bit downgrades

[Scott Kitterman]

On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote:
...
 When I remove the domains I know, the rest is pretty much spam.
...

Isn't that pretty generally true, DKIM or no DKIM.  

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

Re: [ietf-dkim] 8bit downgrades

[Scott Kitterman]

Ian Eiloart i...@sussex.ac.uk wrote:

On 23 May 2011, at 15:19, Hector Santos wrote:  Ian Eiloart wrote: 
On 20 May 2011, at 05:24, Hector Santos wrote:   In this case, if
this is enforced with a MUST, for a system that is  not 8BITMIME
ready but is adding DKIM signing support, to remain  compliant it is
far more feasible to add a rule to a DKIM signing  component: 
 If mail is 8bit then SKIP signing.   But why skip? Usually the
message won't be downgraded. And even if they  are, usually a broken
signature will cause no harm.   Thats the problem - define usually
and also define no harm.  Well, harm will only be done when someone
incorrectly punishes a broken signature. They should not do that, so
the damage is actually done by the recipient, not by the downgrading.

In the real world signature reliability matters. If a domain signs mail as a 
rule then an absent or broken signature will be treated as suspicious.

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

Re: [ietf-dkim] 8bit downgrades

[Scott Kitterman]

On Monday, May 23, 2011 12:35:02 PM John R. Levine wrote:
  In the real world signature reliability matters. If a domain signs mail
  as a rule then an absent or broken signature will be treated as
  suspicious.
 
 I hope you're wrong, since that violates an explicit SHOULD in RFC 4871,
 and in my experience, most broken signatures are due to innocent
 modification in transit, not malice.

Which one is that?  AFAIK treating a broken signature the same as no signature 
is what the RFC wants me to do.

 Do you have numbers to show that broken signatures indicate that messages
 are malicious, or spam, or otherwise worse than otherwise?

None that I can share unfortunately.  IME no signature is more suspicious than 
a broken one (as you suggest, I think most breakage is innocent), but putting 
broken and no signature into the same bucket is the most sensible and RFC 
compliant way to approach it.

 For that matter, since we're not talking about ADSP, what do you mean by
 an absent signature?  Do you track which domains sign what mail? How do
 you tell what signature you're expecting?  From line domain? Sender?
 Message ID? Something in the Received lines?

The specific cases (which are non-ADSP) that I'm aware of use the body From as 
a key.

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

Re: [ietf-dkim] 8bit downgrades

[Scott Kitterman]

On Friday, May 20, 2011 01:18:39 AM Murray S. Kucherawy wrote:
  -Original Message-
  From: John Levine [mailto:jo...@iecc.com]
  Sent: Thursday, May 19, 2011 7:20 PM
  To: ietf-dkim@mipassoc.org
  Cc: Murray S. Kucherawy
  Subject: Re: [ietf-dkim] 8bit downgrades
  
  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.
 
 Actually, I kinda prefer to leave it in.  It seems to me assume a
 downgrade will happen unless you're certain it won't, and plan
 accordingly is good advice without having to know the details of a
 transport path.  And the paragraph gives discussion of the how and why.

+1.

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

Re: [ietf-dkim] 8bit downgrades

[Scott Kitterman]

On Thursday, May 19, 2011 02:16:47 PM Wietse Venema wrote:
 We could pretend that the future is 8-bit clean, and hope the
 problem will go away eventually.

I have a vague recollection that this is the reason it's SHOULD vice MUST. 

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

Re: [ietf-dkim] Protocol layering / Software vs. Protocol

[Scott Kitterman]

On Wednesday, May 04, 2011 01:01:57 PM Dave CROCKER wrote:
 In terms of working group process, one line of criticism demands
 re-opening  (and, apparently, reversing) the work of the Update (RFC
 5672).  I haven't seen any working group consensus to do this nor any
 industry feedback indicating this is necessary.  Consequently, attempts to
 pursue the content of that work is entirely out of scope for the current
 working group effort.

If you're looking for consensus, count me in.  I don't think it was progress.

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

Re: [ietf-dkim] Issue: Operations Note in 6.4 redundant and should be removed

[Scott Kitterman]

On Friday, April 29, 2011 09:22:15 AM Hector Santos wrote:
 I think the rev8 version of section 6.5 is much better, but I have a
 change proposal with the background reasoning listed below it:
 
...

I've had no time recently, so I've been attempting to avoid looking at last 
call messages since I didn't have time to follow it closely.  In this case I 
failed

Looking at 6.5, and then looking back at 6.4 (Determine the Header Fields to 
Sign), it seems to me that the INFORMATIVE OPERATIONS NOTE in 6.4 attempts 
to describe the considerations that are normatively described in 6.5.  It's 
redundant and ought to be deleted.  Given what's in 6.5 now, it's just a 
potential source of confusion.

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

Re: [ietf-dkim] ADSP stats

[Scott Kitterman]

On Wednesday, April 20, 2011 08:01:21 PM John R. Levine wrote:
  A much better test would be compile a list of DKIM signing
  domains, and do the ADSP query on them.
 
 That's what I did.  The only ADSP I see this year is Paypal.

That's a success story of a sort.  We know that ADSP is only potentially 
useful in a narrow set of circumstances.  Data that indicates the protocol 
isn't being widely deployed for domains for which is not suited is good news.

Scott K
___
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)

[Scott Kitterman]

On Saturday, April 02, 2011 02:49:49 PM Michael Thomas wrote:
 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.

+1.

I don't particularly agree with the idea that the work of the working group is 
'done', but it does seem that we'd be better off if we stopped 'improving' 
things sooner rather than later.

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

Re: [ietf-dkim] FW: Getting resolution on the double header issue

[Scott Kitterman]

On Wednesday, February 16, 2011 03:52:24 pm Murray S. Kucherawy wrote:
 This is the last text that I circulated on the bogus header matter, in
 reply to Barry's proposed path to resolution.  The group was pretty
 exhausted from debate at that point so there was little response.
 
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent:
  Monday, November 08, 2010 1:20 AM
  To: IETF DKIM WG
  Subject: [ietf-dkim] Getting resolution on the double header issue
  
  Proposal:
  
  1. The DKIM spec is responsible for describing the problem in terms of
  how it relates to signed and unsigned versions of the fields.  That's
  the stuff in 8.14.
 
 Concur.  I worked through an 8.14 proposal a couple of weeks ago using
 input from the list.  The last text I have was:
 
 8.14 Malformed Inputs
 
 DKIM allows additional header fields to be added to a signed message
 without breaking the signature.  This tolerance can be abused, e.g. in a
 replay attack, by adding additional instances of header fields that are
 displayed to the end user or used as filtering input, such as From or
 Subject, to an already signed message in a way that doesn't break the
 signature.
 
 The resulting message violates section 3.6 of [MAIL].  The way such input
 will be handled and displayed by an MUA is unpredictable, but in some
 cases it will display the newly added header fields rather than those that
 are part of the originally signed message alongside some valid DKIM
 signature annotation. This might allow an attacker to replay a previously
 sent, signed message with a different Subject, From or To field.
 
 Because of this, DKIM implementers are strongly advised to reject or treat
 as suspicious any message that has multiple copies of header fields that
 are disallowed by section 3.6 of [MAIL], particularly those that are
 typically displayed to end users (From, To, Cc, Subject).  A signing
 module could return an error rather than generate a signature;  a
 verifying module might return a syntax error code or arrange not to return
 a positive result even if the signature technically validates.
 
 Senders concerned that their messages might be particularly vulnerable to
 this sort of attack and who do not wish to rely on receiver filtering of
 invalid messages can ensure that adding additional header fields will
 break the DKIM signature by including two copies of the header fields
 about which they are concerned in the signature (e.g. h= ...
 from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further
 discussion of this mechanism.
 
 Specific validity rules for all known header fields can be gleaned from the
 IANA Permanent Header Field Registry and the reference documents it
 identifies.
 
  2. The DKIM spec should probably say that signers need to sign valid
  messages, and, therefore, SHOULD NOT sign things like this.  Text
  along the line of this might work well:
  Signers SHOULD take reasonable steps to ensure
  that the messages they're signing are valid according to [RFC 5322,
  etc].  Leaving the definition of reasonable out allows flexibility.
  It may be waffly, but I like the approach in this case.
 
 Works for me.  How about:
 
 3.10. Input Requirements
 
 DKIM's design is predicated on valid input.  Therefore, signers and
 verifiers SHOULD take reasonable steps to ensure that the messages they
 are processing are valid according to [MAIL], [MIME], and any other
 relevant message format standards.  See Section 8.14 for additional
 discussion and references.
 
  3. It'd be reasonable for the DKIM spec to remind verifiers that
  signers aren't supposed to sign stuff like this, so they might
  consider that when deciding what to do with it after verification.
  It'd be reasonable to remind them of this particular case.  But
  I think that all ought to be informative text.
 
 Yup; the above two amendments cover both cases.

+1.

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

Re: [ietf-dkim] DKIM Japan has been set up

[Scott Kitterman]

John R. Levine jo...@iecc.com wrote:

We really need a FAQ for this group.

 Simply publishing an ADSP record does not change this fact.  ADSP
can
 perhaps be used productively for specific signers and verifiers, but
it
 does not work for all legitimate scenarios.

 What does work for all legitimate scenarios?

Short answer: nothing.

Right. It also doesn't wax my car, which is equally relevant.

ADSP certainly isn't ideal, but (unlike the rest of your message) saying 
something does not work for all legitimate scenarios is not a useful 
contribution to the discussion.

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

Re: [ietf-dkim] DKIM Japan has been set up

[Scott Kitterman]

On Monday, November 22, 2010 01:37:13 pm Dave CROCKER wrote:
 On 11/21/2010 6:43 PM, Tsuneki Ohnishi wrote:
  But there is a small problem. It is rather polical.
  We have a telecommunication law that allows ISPs to discard
  forged email, but our Ministry so far does not acknowledge
  that failure of DKIM verification immediately equals to
  forgery, because there could be other reasons to fail.
 
 There are technical and operational reasons that can cause legitimate mail
 that was originally signed with a legitimate DKIM signature, to fail to
 verify.
 
 The fact that a signer signs all their mail does not mean that all their
 mail will arrive with a valid signature.
 
 Simply publishing an ADSP record does not change this fact.  ADSP can
 perhaps be used productively for specific signers and verifiers, but it
 does not work for all legitimate scenarios.
 
What does work for all legitimate scenarios?

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

Re: [ietf-dkim] Getting resolution on the double header issue

[Scott Kitterman]

On Monday, November 08, 2010 04:20:19 am Barry Leiba wrote:
 As participant:
 
 Here's how I see the situation.  It's purely as a participant, and has
 no chair weight.  I think it does represent a compromise position that
 should work.
 
 Problem description:
 An attack has been described that can be mounted by adding a second
 from, subject, or possible other header field that is only
 supposed to appear once.  This situation might fool a UA, filtering
 software, or some other software into considering the added, unsigned
 field as the real one.
 
 Who is responsible for dealing with this situation?  If the DKIM spec
 is at least partially responsible, to what extent, and what should it
 say?
 
 
 Proposal:
 
 1. The DKIM spec is responsible for describing the problem in terms of
 how it relates to signed and unsigned versions of the fields.  That's
 the stuff in 8.14.
 
 2. The DKIM spec should probably say that signers need to sign valid
 messages, and, therefore, SHOULD NOT sign things like this.  Text
 along the line of this might work well:
 Signers SHOULD take reasonable steps to ensure
 that the messages they're signing are valid according to [RFC 5322,
 etc].  Leaving the definition of reasonable out allows flexibility.  It
 may be waffly, but I like the approach in this case.
 
 3. It'd be reasonable for the DKIM spec to remind verifiers that
 signers aren't supposed to sign stuff like this, so they might
 consider that when deciding what to do with it after verification.
 It'd be reasonable to remind them of this particular case.  But
 I think that all ought to be informative text.
 
 4. We should agree to this or some variant of it, and then move on.
 This is not meant to satisfy everyone.  In fact, it isn't what I'd prefer,
 if I had my full choice.  But it takes care of the problem in a way
 that I think is sufficient, and allows us to resolve the issue.

I think this oversimplifies the issue from a DKIM perspective.  

If this were added, should signatures that sign a second (non-existant) from 
header specifically to ensure header addition breaks the signature verification 
be verified if in fact the message hasn't been modified?  

Rather than fall back purely on 5322, I'd prefer to see something in security 
considerations that says if the count of a particular header field that is 
supposed to be limited (e.g. From and Subject) present in a message exceeds 
the number of signed fields, then the signature shouldn't be verified.  

Additionally, signing a message with (for example) two From: fields is not a 
problem in the context of this issue, so the advice not to sign such messages 
isn't particularly related.

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

Re: [ietf-dkim] Commments and clarifications to 4871bis-02

[Scott Kitterman]

On Friday, October 22, 2010 09:38:47 pm John Levine wrote:
 This is one of those places where I don't know how much we can change
 without the IESG deciding to recycle.  

I think we should decide what's best for the long term health of the protocol 
and then let the IESG worry about recycling or not.  Getting it right is more 
important than advancing up the standards ladder.

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

Re: [ietf-dkim] double header reality check

[Scott Kitterman]

Michael Thomas m...@mtcc.com wrote:

On 10/20/2010 04:36 PM, Steve Atkins wrote:

 On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote:

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

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

 I think we're close to converging here.

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

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

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

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

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

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

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

Um. That's not how I read what he wrote. He specifically said no to security 
considerations and I understand that's what you're in favor of.

Confusedly yours,

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

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

[Scott Kitterman]

On Monday, October 18, 2010 02:19:06 pm Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
  Sent: Saturday, October 16, 2010 11:56 AM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] sophistry is bad, was Data integrity claims
  
   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.
 
 Doesn't this statement advocate for informative advice rather than
 normative requirements?

I'm OK with that, but the informative advice needs to be in security 
considerations, IMO.

Scott K
___
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

[Scott Kitterman]

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Scott Kitterman]

On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote:
 why don't we just deprecate l=?

Yes.  Please.

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

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

[Scott Kitterman]

On Friday, October 15, 2010 01:58:07 pm Barry Leiba wrote:
 On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote:
  Murray S. Kucherawy wrote:
  I appreciate the desire to put more information in there to help, but
  we really can't be writing a tutorial on managing DNS records.
  
  +1.  However, I'd be fine with adding some informative guidance to DKIM
  implementers reflecting current experience, something like: The use of
  wildcard TXT records in the DNS often result in something coming back
  from a query that isn't a valid DKIM key record (and ADSP will encounter
  the same thing).  Verifiers should expect this to occur and plan
  accordingly.
  
  Thank you Murray.  Something small and sweet will be useful, and your
  text is good enough.
 
 Good; we have a start.  Will others please indicate support (or not)
 for adding this or similar text ?
 
 Barry, as chair

I'm neutral on the subject of covering this topic, but if we are going to 
cover it, this or similar text is good.

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

Re: [ietf-dkim] Data integrity claims

[Scott Kitterman]

On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent:
  Friday, October 15, 2010 2:30 PM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] detecting header mutations after signing
  
  Citing a layer violation makes little sense.  With DKIM, the message
  body does not stand on its own.  DKIM binds elements related to the
  RFC5322 header fields with the message body, for the purpose of
  extending favorable message handling, such as white-listing.   Since
  DKIM has this property, citing layer violations lacks any basis.
 
 I thought the What DKIM does thing was a long-dead horse, as we'd long
 ago reached consensus that what DKIM does is provide a stable identifier
 on the message, and nothing more.  That makes this assertion inapposite.

Does it?  If the identifier is bound to the hashed information, I think it 
makes complete sense to believe one can make something of that content and 
it's relation to the identifier.  It provides a stable identifier, but that 
identifier is inextricably tied to the signed content.

 I think perhaps now would be a good time to make that explicit, since a lot 
of people (including some in here) are continuing to infer that DKIM should be 
used to protect the body.  So I propose this be added to 4871bis:
   1.4 Data Integrity
   
   A DKIM signature associates the d= name with the computed hash of
   some or all of the message (see Section 3.7) in order to prevent the
   re-use of the signature with different messages.  Verifying the
   signature asserts that the hashed content has not changed since it
   was signed, and asserts nothing else about protecting the end-to-end
   integrity of the message.
 
 I apologize in advance if that causes yet another traffic maelstrom, but
 it's something we need to settle.  And since the discontinuous expectation
 of DKIM exists outside the working group as well as inside it, that means
 consensus needs to be codified.

Your proposed wording sounds a lot to me like what I think of as protecting 
the end-to-end content.  I feel there's a lot of talking past each other here.

If we were doing what you think of as protecting, what would be different?

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

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

[Scott Kitterman]

Barry Leiba barryle...@computer.org wrote:

On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote:
 At 17:31 13-10-10, Hector Santos wrote:
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one existing need for a TXT record
and that is SPF and incorrectly believe since its a TXT record, adding
the DKIM public key data to it will work.

 There is an assumption that people managing DNS zones will have a
 basic understanding of DNS.  I don't think that the DKIM
 specification should get into badly designed GUIs.

I agree, more generally, that the DKIM spec can't tell people the
right way to manage their DNS records.  DKIM already separates its TXT
records with the _domainkey identifier, as SPF does with _spf.  If,
given that separation, people still merge the TXT records and whatnot,
that problem's well beyond the scope of our work to fix.

I appreciate the desire to put more information in there to help, but
we really can't be writing a tutorial on managing DNS records.

Barry, as participant


+1.

Just as a note of clarification, SPF doesn't prefix TXT records, but I don't 
think that affects the analysis.

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

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

[Scott Kitterman]

On Wednesday, October 13, 2010 03:59:27 pm Jeff Macdonald wrote:
 On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman
 
 ietf-d...@kitterman.com wrote:
  On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote:
  And even if there was a DKIM signature, it is the BAD GUY'S signature,
  which should cause it to go into the SPAM folder, with a large
  phishing warning.
  
  No.  That misses the point entirely.  The problem here is that one can
  take a DKIM signed message that is signed by any entity and add
  additional From/Subjects and the message may still appear to be the one
  signed by the original entity even though it's been modified
  post-signature.
 
 Right. I had understood that and then forgot.
 
 If DKIM is just viewed as providing an identifier and nothing more,
 then this is a MUA problem.
 
 If DKIM is viewed as providing more than an identifier, then this is a
 DKIM problem.

The identifier only makes sense within a context.  For DKIM that context is the 
signed content.  For the identifier to be meaningful, it has to be connected to 
the actual content of the message, if not, the identifier could be arbitrarily 
reused and would serve little purpose.

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Scott Kitterman]

Dave CROCKER d...@dcrocker.net wrote:



On 10/12/2010 11:21 AM, Murray S. Kucherawy wrote:
 -1; I like the wording that's there.
 Concur; -1 on the change.  I furthermore submit that we are compelled to 
 describe the known attack, as that's precisely what we are supposed to 
 include in Security Considerations.


We should keep in mind that DKIM's job is to deliver a validated domain name.  
I 
believe none of the attacks that have been discussed have anything to do 
with 
that task.  Instead, they pertain to other forms of attack on perceived 
message 
content validity, which is entirely outside of DKIM's scope.

Seriously.


-1. Seriously.

DKIM also attempts to provide assurance that content is unmodified. Without 
that the identity assurance is meaningless.

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

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

[Scott Kitterman]

On Friday, October 08, 2010 12:33:38 pm Dave CROCKER wrote:
 On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote:
  I'm still cringing at the layering violation of fixing in DKIM the fact
  that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't
  bother to enforce normative portions of that specification.
  
  Is there precedent of this being done elsewhere, i.e. compensating in one
  protocol for abundant lousy implementations of a layer below it?
 
 I'm a bit confused.
 
 We want to re-submit DKIM Signing to Proposed Standard, in order to fix an
 edge condition that is only a theoretical issue and only fixes a problem
 that is actually outside of the scope of what DKIM is trying to achieve?
 
 d/

Detecting modification in transit is outside the scope of what DKIM is trying 
to achieve?

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

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

[Scott Kitterman]

On Friday, October 08, 2010 01:41:15 pm Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org
  [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
  Sent: Friday, October 08, 2010 10:01 AM
  To: ietf-dkim@mipassoc.org
  Subject: Re: [ietf-dkim] detecting header mutations after signing
  
   We want to re-submit DKIM Signing to Proposed Standard, in order to fix
   an edge condition that is only a theoretical issue and only fixes a
   problem that is actually outside of the scope of what DKIM is trying
   to achieve?
  
  Detecting modification in transit is outside the scope of what DKIM is
  trying to achieve?
 
 Doesn't DKIM try to detect modification of the portion covered by the
 hashes, which is unchanged in this scenario?

For what I view as a very abstract definition of unchanged, sure.  I think 
adding additional From or Subject does change the content of the message From 
or Subject.  If one takes the view that we've defined things such that this is 
OK from a protocol definition perspective, so it's not an issue, I think we've 
lost sight of the original goal of this requirement in the protocol.

I think that this can be dealt with through an additional security 
consideration and doesn't have to disrupt the rush to get this advanced 
through the standards process.

Scott K
___
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

[Scott Kitterman]

Dave CROCKER d...@dcrocker.net wrote:



On 10/6/2010 8:00 AM, Steve Atkins wrote:
 It also changes what DKIM means,
...
 Either the message has a valid DKIM signature, or it does not. If the
 signature is valid, then the signing domain takes responsibility for the
 message, subtly malformed or not. Just because the message lacks a Date:
 header or has bare linefeeds doesn't mean that the signing domain isn't
 responsible for it.

THis is a particularly clean and precise attention to DKIM's job, nicely 
filtering out issues that are not part of DKIM's job.

In particular, it makes the multiple From: issue entirely irrelevant to DKIM.


In a normative sense, perhaps, but in real world terms, it doesn't. Since this 
does away with It's not valid 5322, so it can't be valid DKIM, it puts the 
question of how implementors should deal with such things back on the table.

I'd like to see us include a general helpful note to implementors about 
covering the case where a duplicate header field is added after signing. Maybe 
this is an added item for security considerations?

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

Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From

[Scott Kitterman]

Dave CROCKER d...@dcrocker.net wrote:



On 10/5/2010 8:15 AM, Ian Eiloart wrote:
 It has been observed by implementations that is it possible to replay
   a message with a 2nd 5322.From header at the top which wouldn't break
   the DKIM signature validity, but would often be displayed by MUAs to
   display the new 5322.From display rather than the signature bound
   5322.From header.
 Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to
 display the signed header? Are there really MUA's that will display the
 unsigned headers*and*  assert that it was validated? If so, that's surely a
 bug in the implementation of the MUA.


Your comments underscore the importance of being careful about what we expect 
from DKIM.  As you note, if software is DKIM-aware, it also needs to be 
DKIM-intelligent.

At a deeper level, there is a continuing problem with casting DKIM as a 
mechanism to protect a message.  That's something that OpenPGP and S/Mime 
do; 
it's not something DKIM does.  DKIM merely tries to do enough to ensure that 
the 
d= is valid, to provide a basis for reputation assessment.

Hence, I recommend that this ISSUE be declined and closed.


Nack. DKIM also purports to provide assurance that the signed content of the 
message is unmodified. I think mentioning that all instances of a header that 
is signed should be used for signing and verification is a useful data point 
for implementors.

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

Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From

[Scott Kitterman]

Murray S. Kucherawy m...@cloudmark.com wrote:

 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Scott Kitterman
 Sent: Tuesday, October 05, 2010 12:24 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 
 5322.From
 
 Nack. DKIM also purports to provide assurance that the signed content
 of the message is unmodified. I think mentioning that all instances of
 a header that is signed should be used for signing and verification is
 a useful data point for implementors.

I'm having trouble parsing that.  Aren't all instances of a signed field used 
for verifying already?  Or are you proposing an If you sign one, you have to 
sign them all sort of approach?

That will wreak havoc with Received:, if so.

I'm suggesting making it clear that if one signs a type of field they should 
sign all of them. I'm not suggesting adding any requirements that additional 
types of fields be signed.

Scott K

P.S. I'm not sure I parsed your question correctly. 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

[Scott Kitterman]

John R. Levine jo...@iecc.com wrote:

 The law requires that there be an easy to use address for unsubscribing.
 The List-unsubscribe header: would do the job nicely, if the majority of
 people were using mail clients that expose it by default. I don't know of
 any mail client which does that.

pine/alpine does, but I agree, most MUAs don't show headers other than To, 
From, Cc, and Subject.

This might be a good time to remind people that MLMs in their current form 
are not broken, and any proposal that requires them to stop doing 
something that they're currently doing, like rewriting messages or adding 
message tags, is a non-starter.

Since nothing requires anyone do anything with respect to DKIM, I'm hard 
pressed to imagine something that doesn't meet that requirement.

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

Re: [ietf-dkim] draft-vesely-dkim-joint-sigs

[Scott Kitterman]

On Thursday, September 23, 2010 03:16:53 pm John R. Levine wrote:
  Ian, this makes no sense to me. If a signing domain is concerned enough
  to choose to implement ADSP, why would they reduce what they are signing
  to accommodate a small percentage of their mail going to MLMs that they
  may or may not be able to identify?
 
 I'm with you.  All of this emphasis on complex designs for MLMs strikes me
 as a waste of time, since it's a tiny corner of the mail space that has
 not historically been a vector for abuse, and shows no sign of becoming
 one.
 
 That's why my advice is that lists should sign their mail, which is easy
 and at worst harmless, and we're done.
 
 R's,
 John

In that case, we should just say we're done.  I see zero value in a document 
that says people should sign mail. 

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

Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.

[Scott Kitterman]

On Thursday, September 16, 2010 03:23:15 am Hector Santos wrote:
 Scott Kitterman wrote:
  My Technical recommendation.
  
  1) For 4871bis, we should consider relaxing the 5322.From
  
 binding requirement from a MUST to a SHOULD.  This will help
 justify its new words of separating the signer domain from
 the author domain.  There is no separation until the 5322.From
 binding requirement is relaxed.
  
  As discussed during the original DKIM development effort, this
  is about protecting content from modification. The base DKIM spec
  already doesn't treat 5322.from specially, so such a change in not
  needed to meet your specified goal.
 
 Excuse me if I don't understand your reading.  5322.From is the only
 header that is required hashing. Is that not a special consideration?
 
 I think it will serve the community interest to find out why this
 large MTA vendor revised there open source software three years later
 presumably after extensive field operations to include a new option to
 relaxed the 5322.From binding.

Finding out why sounds reasonable.  What you propose isn't finding out why, but 
assuming it's valuable without bothering to find out.

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

Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.

[Scott Kitterman]

Hector Santos hsan...@isdg.net wrote:

Based on existing open source DKIM API code from a large MTA, they 
must of come across signatures that did not include the 5322.From 
signature binding requirement of RFC 4871 because it contains an 
option to not enforce 5322.From hash binding in the DKIM.H header.

I don't think that's a reasonable conclusion do draw from this data point. 

In other words, if the DKIM-Signature h= header does not have the 
from value, then this code has an option to ignore this RFC 4871 
requirement and allow this type of DKIM-Signature.

Although the API is technically violating RFC 4871, they must of did 
this for a reason but I am not totally clear what all scenarios this 
will cover with Author Domains who sign without the 5322.From bind.

Protecting messages from in transit modification was one of the DKIM design 
goals. Excluding this user visible header from such protections is not a good 
idea. This is an even worse idea than l=.

The main point is they found an implementation reason to add an 
verification option to relax the RFC 4871 MUST hash 5322.From requirement.

People implement all kinds of thing for all kinds of reasons. Don't depend very 
much on the mere fact of an implementation tidbit.

My Technical recommendation.

1) For 4871bis, we should consider relaxing the 5322.From
binding requirement from a MUST to a SHOULD.  This will help
justify its new words of separating the signer domain from
the author domain.  There is no separation until the 5322.From
binding requirement is relaxed.

As discussed during the original DKIM development effort, this is about 
protecting content from modification. The base DKIM spec already doesn't treat 
5322.from specially, so such a change in not needed to meet your specified goal.

2) We should consider a 5617bis (ADSPbis) to codify its semantics
regarding Author Domain only signature policies to include a:

Always sign by *anyone* Policy.

Currently 5617 (ADSP) defines the two policies:


 all   All mail from the domain is signed with an Author
   Domain Signature.

 discardable   All mail from the domain is signed with an Author
   Domain Signature

Many people felt we were missing the Signed by Anyone concept which 
did not help authorized 3rd party signers or the list servers who 
are going to be resigning.  To compensate, many viewed ADSP=ALL to 
mean it allowed any signer, not just the Author Domain as defined by 
the spec.

In fact, this same DKIM API includes ADSP support and it also 
interprets ADSP=ALL as an anyone can sign concept as long as there is 
a valid signature. There is no option in the software to follow 
ADSP=ALL exactly how it it defined in 5871.

It sounds to me like a bug.

Since this is an API from a large MTA vendor, I would not ignore this 
implementation data point. If the suggestion is made the software is 
buggy then we are back to a status quo of non-resolution of 
conflicting issues regarding the author domain, 3rd party signers 
and/or list servers.

Since anyone can generate a DKIM signature with a signing domain they control, 
an unconstrained 3rd party signing policy means precisely nothing. Without some 
kind of constraint (1st party only or a defined set of third party signers) 
arbitrary senders could meet the policy requirements.

- 1.

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

On Tuesday, September 14, 2010 09:18:23 am John R. Levine wrote:
 As I keep saying over and over, discardable really means discardable: if 
 in doubt, throw it away.  It does NOT, repeat NOT, mean high value mail. 
 It means low value mail.

I think your view is to narrow.  It means that the domain owner prefers it be 
discarded if not signed.  This means they view the risks of having legitimate 
mail discarded as lower than the risks associated with having unsigned mail 
delivered.  This is a relative assessment.  Your low value mail assertion 
only addresses one part of that equation.

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

On Friday, September 10, 2010 03:17:47 pm Steve Atkins wrote:
 On Sep 10, 2010, at 11:27 AM, Charles Lindsey wrote:
  On Fri, 03 Sep 2010 15:15:37 +0100, Hector Santos hsan...@isdg.net 
wrote:
  I think you need to better appreciate and understand how fundamental
  the Message From field for any forms of communications and/or mail
  networks is.  It would be a radical change to open up this door and
  Pandora box to make it the norm and mindset that a From: is
  unreliable. Not saying it is not prone to abusive, but fundamentally,
  when people believe in the message, they also make that natural
  trusted tie to the author of the message.
  
  Yes, but nobody is trying to change that. We seem to be agreed that what
  a mailing list sends is, from some POV, a new message, and so
  logically a new From: is not wholly out of order.
 
 What's the benefit to this, though, other than obscuring the original
 author?

If you agree with John Levine's proposal that mailing list mail is, in 
general, not a problem then there is negative value in mailing lists throwing 
away (discarding) good mail from domains that happen to use ADSP Discardable 
(or any other mechanism for inferring something from the lack of a signature - 
this isn't really ADSP specific, it's just the implementation we have at the 
moment).  If this negative event can be avoided by the simple mechanism of 
using a mailing list specific Message From, then that is a benefit.  This is 
not the only potential use of such a feature.  I've spoken to one MLM 
developer who told me the feature has been previously requested for privacy 
reasons nothing to do with DKIM or ADSP.

I think this is quite reasonable as it would inoculate MLM users from ADSP (or 
similar) problems in a way that does not limit their ability to promote 
communication among their subscribers (which is what mailing lists do).

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

On Friday, September 10, 2010 05:53:57 pm J.D. Falk wrote:
 On Sep 10, 2010, at 12:34 PM, John R. Levine wrote:
  The problem is that too many people on this WG take the view I believe
  in solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't
  use mailing list if you advertise 'discardable') and I will vote down
  any solution other than X.
  
  Call me old-fashioned if you will, but I take the view that a purely
  hypothetical paper design to address a largely hypothetical problem, with
  unknown security problems, unknown user interface problems, and unknown
  interoperation problems have no place in a document about actual e-mail
  practice.
 
 +1
 
 It's the difference between Best Current Practices and Things We Thought Of
 But Haven't Tried Yet.  Either could be published as an I-D, but we
 shouldn't try to fit both approaches into the same BCP.

It's not clear to me that there's consensus that anything qualifies as Best 
Current.  We have some small samples of a few things that some people have 
tried, but I don't sense we're there yet.

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

On Friday, September 10, 2010 06:37:46 pm Steve Atkins wrote:
 On Sep 10, 2010, at 2:31 PM, Scott Kitterman wrote:
  On Friday, September 10, 2010 03:17:47 pm Steve Atkins wrote:
  On Sep 10, 2010, at 11:27 AM, Charles Lindsey wrote:
  On Fri, 03 Sep 2010 15:15:37 +0100, Hector Santos hsan...@isdg.net
  
  wrote:
  I think you need to better appreciate and understand how fundamental
  the Message From field for any forms of communications and/or mail
  networks is.  It would be a radical change to open up this door and
  Pandora box to make it the norm and mindset that a From: is
  unreliable. Not saying it is not prone to abusive, but fundamentally,
  when people believe in the message, they also make that natural
  trusted tie to the author of the message.
  
  Yes, but nobody is trying to change that. We seem to be agreed that
  what a mailing list sends is, from some POV, a new message, and so
  logically a new From: is not wholly out of order.
  
  What's the benefit to this, though, other than obscuring the original
  author?
  
  If you agree with John Levine's proposal that mailing list mail is, in
  general, not a problem then there is negative value in mailing lists
  throwing away (discarding) good mail from domains that happen to use
  ADSP Discardable (or any other mechanism for inferring something from
  the lack of a signature - this isn't really ADSP specific, it's just the
  implementation we have at the moment).  If this negative event can be
  avoided by the simple mechanism of using a mailing list specific
  Message From, then that is a benefit.
 
 Rather than go into the general reasons why I think this is not
 something that ADSP users really want, I'll give a concrete
 example.
 
 Lets say this mailing list rewrites the From: address in some
 reasonably mechanical manner, and the From: field of
 this message were rewritten as (making up syntax on
 the fly)...
 
 From: steve%blighty.com%ietf-d...@mipassoc.org
 
 ... such that recipients (or their MUAs) know that this mail
 was sent by st...@blighty.com via a mailing list at
 dkim.org.
 
 There's nothing to stop me from sending mail
 From: billing%paypal.com%ietf-d...@mipassoc.org, as
 the mailing list isn't using ADSP. And there's certainly
 nothing to prevent me from sending mail from
 billing%paypal.com%ietf-d...@blighty.com that has
 a valid first-person signature.
 
 That means that, as far as the end user is concerned,
 I can send them email that is from bill...@paypal.com,
 even though paypal.com is using ADSP to ask receivers
 to discard mail that claims to be from paypal.com but
 is not validly signed by paypal.com.
 
 Given the whole point of ADSP is Discard if you're not
 sure, I don't think that's what an ADSP using domain
 would want.
 
 (The effect is softened somewhat if you use random
 from addresses with no connection to the real address,
 but only somewhat. And that damages the communication
 between users quite a bit more. That's what I meant when
 I talked about obscuring the author, upthread).
 
   This is
  
  not the only potential use of such a feature.  I've spoken to one MLM
  developer who told me the feature has been previously requested for
  privacy reasons nothing to do with DKIM or ADSP.
 
 That would be for obscuring the original author, and
 it's certainly possible for MLMs to do that now, though few
 do.
 
  I think this is quite reasonable as it would inoculate MLM users from
  ADSP (or similar) problems in a way that does not limit their ability to
  promote communication among their subscribers (which is what mailing
  lists do).
 
 I don't think it inoculates them against ADSP problems - rather
 it opens them up to violations of the security model that ADSP
 would like to impose.
 
This is only true if John is wrong and mailing lists are a vector that we need 
to worry about.  I happen to generally agree with him on this.

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

Steve Atkins st...@wordtothewise.com wrote:


On Sep 10, 2010, at 3:46 PM, Scott Kitterman wrote:

 On Friday, September 10, 2010 06:37:46 pm Steve Atkins wrote:
 On Sep 10, 2010, at 2:31 PM, Scott Kitterman wrote:
 
 
 I don't think it inoculates them against ADSP problems - rather
 it opens them up to violations of the security model that ADSP
 would like to impose.
 
 This is only true if John is wrong and mailing lists are a vector that we 
 need 
 to worry about.  


Doing what you suggest would avoid the problems of legitimate
email being discarded due to ADSP/mailing list interactions at
the cost of allowing phishers to send email from a sender
violating the ADSP security model simply by pretending to be
a mailing list.

 I happen to generally agree with him on this.

Me too. But you're breaking the ADSP security model for all
email with your suggestion. Note that neither of the examples
I gave involved me sending a phishing email via a mailing
list.

I don't think it breaks it. It avoids it and I think that's fine.

Whatever limited value ADSP provides, it is only relevant to exact domain 
phishing.  What we are describing is a putative weakness that's already beyond 
it's design scope.

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

John Levine jo...@iecc.com wrote:

It's not clear to me that there's consensus that anything qualifies as Best 
Current.  We have some small samples of a few things that some people have 
tried, but I don't sense we're there yet.

I hope that lists signing their outbound mail qualifies.  Large
providers Googlegroups and Yahoogroups do it, small providers
including MAAWG and myself also do.

Beyond that, you're right, we're at best guessing and at worst pulling
stuff out of our whatevers.

Which brings us back to the question of the value of the DKIM working group 
writing an RFC that suggests people should sign mail.  I don't think it has 
much.

I think an experimental document that amounts to something like We've thought 
about this a lot and discussed it and collectively we've got NFC yet what's 
best yet. Here are some ideas ... is what's most needed.

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

On Wednesday, September 01, 2010 05:18:02 am John Levine wrote:
  ANNEX A - MUA Considerations
 
 Is a draft about mailing lists the right place to make recommendations
 to MUA developers?  Seems like those should probably be in a separate
 document.
 
 No, but the entire document is riddled with advice that has no basis
 in experience and is unlikely ever to be implemented.
 
 We have a serious problem that people in this group have deeply
 incompatible ideas of what DKIM does.  A lot of the arguments seem to
 be from people who believe that a DKIM signature can or should
 identify the individual author of a message, and that subscribers to
 mailing lists need assurances about the identity of list authors
 beyond the minimal level that has been adequate for the past twenty
 years.  I have trouble understanding how anyone who is familiar with
 DKIM or with the operation of mailing lists could hold these
 positions, but it is quite obvious that some do.
 
 At this point, unless we can cut back the MLM document to stick to
 items that we have consensus about, e.g., that it is typical for
 signatures applied to incoming mail not to verify after a message
 passes through an MLM, and that it would be nice if a list or its MTA
 signed its outgoing mail, I don't think we will produce anything that
 is useful to anyone.

If that's all we can say, I'd say don't bother.  I don't see much value in the 
DKIM working group saying it thinks mail should be signed by DKIM.

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

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[Scott Kitterman]

On Wednesday, September 01, 2010 08:23:19 am John Levine wrote:
  At this point, unless we can cut back the MLM document to stick to
  items that we have consensus about, e.g., that it is typical for
  signatures applied to incoming mail not to verify after a message
  passes through an MLM, and that it would be nice if a list or its MTA
  signed its outgoing mail, I don't think we will produce anything that
  is useful to anyone.
 
 If that's all we can say, I'd say don't bother.  I don't see much value in
 the DKIM working group saying it thinks mail should be signed by DKIM.
 
 e.g. means such as or for example.
 
 I expect there's a fair amount we agree on.  Maybe it's enough to be
 worth documenting, maybe not, but I think it would be more productive
 to see what we agree on rather than trying to force our pet projects
 into the document.
 
 I'll cheerfully give up references to S/MIME, if other people will
 give up on telling software developers how to rewrite MLMs to do
 things they've never done before.
 
 Don't forget that an experimental RFC is the accepted way to document
 a paper design to see if it gets any traction, as the EAI group did
 with various ways to represent non-ASCII e-mail addresses.

Since things to do to get signatures to survive on mailing lists doesn't seem 
to be on your list of stuff we agree on, what else is?  I know you said e.g., 
but given what I understand you to not agree on, I'm not sure what else is 
left.

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

Re: [ietf-dkim] Proposed changes to MLM draft

[Scott Kitterman]

On Monday, August 30, 2010 02:03:45 pm Murray S. Kucherawy wrote:
 I'd like some help tackling the next version of the MLM draft.  People seem
 to have varying ideas about what should be removed and perhaps appear in
 other documents now.  I need some consensus on a direction in which to
 proceed.
 
 So can I please get some +1s/-1s on each of the following:
 
 (1) Split the document into three documents: A DKIM MLM BCP that discusses
 signing and verifying in the context of MLMs with no value-add items
 addressed, a DKIM MLM Informational that discusses possible value-add
 enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing
 lists irrespective of DKIM (Dave's proposal);

-1.  I don't think the first part has much value without the second (if I 
understand the split correctly).  

 (2) Tear out everything having to do with making author signatures survive
 list relaying, dropping all that text altogether, and instead pointing
 people at S/MIME or PGP (John's proposal);

-1.  While I think it's premature to specify THE way to solve such problems, 
I think it's useful to present possibilities for implementers to consider.  I 
don't think redefining the problem so that a class of failures are no longer 
failures is helpful.

 (3) Something else (and specify what that might be).
 
 AND...
 
 If you support any of the above, please take a few minutes to include some
 pointers to what text you want changed/exported and in what way.  Actual
 diffs would be ideal, but I'll take point-form commentary as well.

I'll try and do this, but not today.

 AND...
 
 If you advocate for a general MLM BCP, this will be a non-WG document (it's
 outside of our charter) so I'd love to get some MLM operators and
 developers involved.  (Maybe this should take place on ietf-822 or maybe
 on a new non-WG list; suggestions welcome.)  Expressions of interest in
 that work would be appreciated.  I'll approach the APPS ADs about a venue.
 
 Thanks,
 -MSK


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

Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion

[Scott Kitterman]

Dave CROCKER d...@dcrocker.net wrote:



On 8/2/2010 11:34 AM, Steve Atkins wrote:
 A -1 on ever altering the From: field for any reason other than special
 requirements of the people running a specific mailing list.


A +1 in support of that -1.

The view that modifying the From: is helpful has no empirical basis.  I'll 
claim 
that there is a pretty good theoretical basis for believing it makes things 
worse, not better.

As always, the instant the IETF gets into user interface design, it steps out 
of 
its group competence.  As a group, we do not have the training in cognitive 
models, UXE, or the rest of what's needed to work in this space.

That seems pretty orthogonal to the discussion so far.  Declaring discussion of 
From off limits because it is also displayed makes me wonder why you thought it 
was alright for the IETF to take on the work codified in RFC 822 and its 
descendants? 

Just because it's displayed doesn't mean any change is driven by UX 
considerations.  I get that you're intent on avoiding anything that might make 
ADSP deployment less difficult, but please stick to the arguments that make 
some sense. 

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

Re: [ietf-dkim] Straw poll results

[Scott Kitterman]

On Monday, August 09, 2010 04:11:57 pm John R. Levine wrote:
  Why do you simplify handling of list mail to sorting and filtering,
  ignoring two other important list handling activities:
  
  1. reading mail
  2. responding to mail
 
 Well, OK.  Can you offer some non-hypothetical situations where you would
 read or respond to list mail differently if there were extra assurance on
 identity of the list contributor?
 
 Or to put it another way, if someone has put an S/MIME signature on a
 messsage sent through a list, does that affect the way you respond?
 
It's not at all clear to me that the answer to that question is in any way 
related to the work of the working group.  What would we design differently if 
the answer was yes (or no)?

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

Re: [ietf-dkim] Straw poll results

[Scott Kitterman]

On Monday, August 09, 2010 05:38:18 pm Rolf E. Sonneveld wrote:
 Scott Kitterman wrote:
  On Monday, August 09, 2010 04:11:57 pm John R. Levine wrote:
  Why do you simplify handling of list mail to sorting and filtering,
  ignoring two other important list handling activities:
  
  1. reading mail
  2. responding to mail
  
  Well, OK.  Can you offer some non-hypothetical situations where you
  would read or respond to list mail differently if there were extra
  assurance on identity of the list contributor?
  
  Or to put it another way, if someone has put an S/MIME signature on a
  messsage sent through a list, does that affect the way you respond?
  
  It's not at all clear to me that the answer to that question is in any
  way related to the work of the working group.  What would we design
  differently if the answer was yes (or no)?
 
 Let me try to explain. If the identity of the list contributor is of any
 value to the receiver of an MLM-distributed message, then it is
 important to (try to) preserve the original DKIM signature across an MLM
 redistribution of the message (if at all possible). If however the
 identity of the list contributor is of no value whatsoever, we should
 not bother about preserving the original DKIM signature.
 
Not at all.

If the receiver is going to act differently to signed or unsigned mail from 
certain domains, then it's important to preserve the signature or change the 
domain.  For receivers of non-trivial scale they aren't in a position to know 
what mail they are receiving is MLM-distributed, so the question of how they 
would treat MLM-distributed mail is irrelevant because they don't and can't 
segregate it that way.

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

Re: [ietf-dkim] Straw poll results

[Scott Kitterman]

On Monday, August 09, 2010 05:22:35 pm Steve Atkins wrote:
 On Aug 9, 2010, at 1:26 PM, Scott Kitterman wrote:
  On Monday, August 09, 2010 04:11:57 pm John R. Levine wrote:
  Why do you simplify handling of list mail to sorting and filtering,
  ignoring two other important list handling activities:
  
  1. reading mail
  2. responding to mail
  
  Well, OK.  Can you offer some non-hypothetical situations where you
  would read or respond to list mail differently if there were extra
  assurance on identity of the list contributor?
  
  Or to put it another way, if someone has put an S/MIME signature on a
  messsage sent through a list, does that affect the way you respond?
  
  It's not at all clear to me that the answer to that question is in any
  way related to the work of the working group.  What would we design
  differently if the answer was yes (or no)?
 
 If a recipients handling of an inbound email from a mailing list varies
 depending on whether you can authenticate the original author (the
 
 From field) or not, then there may be some value in helping mailing
 
 lists tunnel authentication through in a way that allows you to
 authenticate the original author.
 
 If it doesn't, there isn't.
 
 If none of the members of this list would handle an inbound email from
 a mailing list depending on whether they can authenticate the original
 author or not, nor point at a concrete example of people ding so, that
 would suggest it's not a common requirement. Which would suggest it's
 not worth considering how to support it for DKIM, which seems to be at
 least tangentially related to what we're doing here.

This assumes mail from MLMs is treated differently than other mail.  While 
individual users may (and probably do) treat it differently, receivers of non-
trivial scale don't and can't.

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

Re: [ietf-dkim] Straw poll results

[Scott Kitterman]

On Monday, August 09, 2010 06:48:51 pm John Levine wrote:
 This assumes mail from MLMs is treated differently than other mail.
 While individual users may (and probably do) treat it differently,
 receivers of non- trivial scale don't and can't.
 
 Sigh. Anyone who uses gmail would know that your assertion is just
 plain wrong.

There's a difference between claims to be from an MLM and From an MLM.  
Today there isn't much value in making the claim, so no one bothers.  It would 
be unfortunate if we recommended something that caused List-ID headers to be 
less useful because people found value in spoofing them.
 
 And in any event, even if your assertion were true, so what?  Our
 working assumption is that receivers will use valid DKIM signatures to
 whitelist mail from signers they like.  How does it matter whether the
 signer happened to be a related to a list?
 
If I'm a consumer of your list of domains that you're convinced sign all their 
mail and I get an unsigned message from one of them, I'm bound to be extra 
suspicious of that.  Oooh, it came from a mailing list so I don't care isn't 
the most likely response.

Which is why the whole straw poll is irrelevant.  Since the D in DKIM is 
Domain, it's really no concern how individuals filter mail.

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

Re: [ietf-dkim] Straw poll results

[Scott Kitterman]

On Monday, August 09, 2010 06:52:04 pm Steve Atkins wrote:
 On Aug 9, 2010, at 3:13 PM, Scott Kitterman wrote:
  This assumes mail from MLMs is treated differently than other mail. 
  While individual users may (and probably do) treat it differently,
  receivers of non- trivial scale don't and can't.
 
 I agree, in general.
 
 One implication of that is that if you're planning to do something with
 email that will break if there's a MLM involved, it's broken[1].
 
 Cheers,
   Steve
 
 [1] We could call this The SRS lemma.

Yes.  It's very similar.

One needs to decide what factors one cares about the most.  I said a few 
threads ago that I don't think there is a completely satisfactory solution.  I 
think the possibilities are roughly:

1.  Fix lists so that signatures survive.

2.  Have MLMs change the domain of the message.

3.  Have mail get rejected/discarded/etc.

There are variants of all three possibilities, but none that will satisfy 
everyone. 

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

Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature

[Scott Kitterman]

On Tuesday, August 03, 2010 08:02:34 am Hector Santos wrote:
 It seems much easier for MLS (Mail List Servers) to preempt 
 restrictive ADSP Domains from subscribing and from submitting mail to 
 the list enabled with DKIM resigning.

This would also give you the use case to deal with of restrictive ADSP 
published after someone has already subscribed.

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

Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion

[Scott Kitterman]

On Monday, August 02, 2010 02:13:39 pm Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
  boun...@mipassoc.org] On Behalf Of Jeff Macdonald
  Sent: Monday, August 02, 2010 10:53 AM
  To: DKIM List
  Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for
  discussion
  
   c) A -1 to the idea of altering From: to cope with ADSP; the reason
  
  given:
   This presumes endpoints will understand a DKIM-related From:-altered
   message.
  
  I must of missed that point in Daniel's thread. I hadn't realized that
  the From would of been conditionally re-written. Today, endpoints (I
  take that to mean MUAs), don't seem to have a standard way of dealing
  with mailing lists anyway. So I'd say -1 to the reason.
 
 I don't think there's anything conditional about it.  The suggestion is to
 rewrite From: when the MLM remails its modified content.
 
 It sounds like you're saying that's a good idea.  By my count that's three
 in favour and two against, and I suspect that's not rough consensus in
 either direction, but is probably enough to add some discussion about it
 to the draft, unless of course there's objection to even mentioning the
 idea.

I think this is worth considering.  In discussions with one of the developers 
of a major open source MLM, he mentioned to me that they've had feature 
requests over the years to alter From due to privacy/spambot harvesting 
reasons, so this isn't something that would only serve to mitigate damage due 
to ADSP.

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

Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglis ts for discussion

[Scott Kitterman]

On Monday, August 02, 2010 02:39:05 pm Michael Thomas wrote:
 On 08/02/2010 11:21 AM, Scott Kitterman wrote:
   I think this is worth considering.  In discussions with one of the
 developers
 
  of a major open source MLM, he mentioned to me that they've had feature
  requests over the years to alter From due to privacy/spambot harvesting
  reasons, so this isn't something that would only serve to mitigate damage
  due to ADSP.
 
 Yeahbut... given the inertia how much could we possibly expect? There's
 going to be breakage and hence resistance to this were it a good idea
 (which I'm not sure of). Suppose only 10% by volume of lists did this,
 would it still be a net benefit?
 
I don't think there are any solutions to ADSP and MLMs that are unadulterated 
good.  I think each option has risks and benefits.  I think this is one 
reasonable approach that may suit some lists and be implemented for some MLMs. 

I think it doesn't risk mail loss and is consistent with existing standards.  
It does require some change in practices, but I think that's rather the point 
of the document.

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

Re: [ietf-dkim] Alternative MAiling List Approach

[Scott Kitterman]

On Friday, July 30, 2010 11:48:22 am Steve Atkins wrote:
 On Jul 30, 2010, at 12:26 AM, Murray S. Kucherawy wrote:
  -Original Message-
  From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
  boun...@mipassoc.org] On Behalf Of Steve Atkins
  Sent: Thursday, July 29, 2010 8:56 PM
  To: DKIM List
  Subject: Re: [ietf-dkim] Alternative MAiling List Approach
  
  On Jul 29, 2010, at 3:45 PM, Murray S. Kucherawy wrote:
  Should the MLM draft suggest From: replacement and addition of Reply-
  
  To: as a specific example of DKIM-friendly MLM behavior?
  
  No. DKIM doesn't really say much about either the From: address or the
  Reply-To: address, so such a suggestion for DKIM-friendly behaviour
  would be nonsensical.
  
  It might be a reasonable suggestion for the benefit of other protocols,
  but that's a different question.
  
  Is it not an ADSP issue though?  Covering ADSP issues is (at least
  implicitly) in scope for this document.
 
 It may well be an ADSP issue - I've not looked in detail at the
 proposal - and it may be in scope for this document. (I suspect
 it's also a bad idea, but that's a separate discussion).
 
 It's definitely not a DKIM issue, though, and any labeling of a
 non-DKIM issue as DKIM-friendly would be misleading.

IIRC we used to refer to the DKIM base signing spec and ADSP (and all the 
names it previously had, most of which I've fortunately forgotten) as both 
being part of DKIM.  It seems a bit odd to me to refer to issues with specs 
produced by the DKIM working group as non-DKIM.

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

Re: [ietf-dkim] Alternative MAiling List Approach

[Scott Kitterman]

On Thursday, July 29, 2010 12:46:34 pm Alessandro Vesely wrote:
 On 29/Jul/10 13:21, Charles Lindsey wrote:
  The REAL cause of the problem is that From: line. My proposal is that MLM
  should change the From: header in such a way that the mail appears to
  have come from MLM.example and not from discardable.example. Clearly,
  this removes the cause of the problem at a stroke (the mail will no
  longer be discarded), but obviously it raises several other issues
  instead.
 
 SRS on From?  It is intriguing that, after having taken a rather
 different approach, DKIM faces much the same problems that SPF had
 been criticized for, for the same minor fraction of the email traffic.
 
 IMHO, the real cause of the problem is that the same From field is
 being used for entirely different message streams.  On the one hand,
 the MLM wants the input message to be signed, so it can authenticate
 the poster.  On the other hand, MLM output isn't the land of the
 author domain (including IPR, usually) even if the original From
 stays there to identify the author.

First, it's a different minor fraction of email traffice (forwarding versus 
mailing lists), but more importantly there's clear support in the standards 
for treating mailing list mails as a new transmission, rather than a 
continuation of the old one.

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

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

[Scott Kitterman]

John Levine jo...@iecc.com wrote:

Similarly, with ADSP you don't have to rely on published information, and 
when information is published, you don't have to guess whether the 
publisher is competent. You can maintain your own list of domains that you 
trust to get ADSP right, and use standard software to apply that judgement. 

Manual drop lists are a fine idea, but what do they have to do with ADSP?

1. Code reuse: Although you may choose to maintain your drop list, you 
don't have to write software for your MTA, you can just configure it.

I'm happy to reuse the manual drop code in Spamassassin.  I still don't
see what it has to do with ADSP.

2. Discoverability: You can find out from ADSP publications that the sender 
cares about this stuff. OK, it's still a leap to add them to your drop 
list, but you do at least have somewhere to start.

Here's a thought experiment: let's say you have your list of domains
that are known to be phish targets that sign their mail, so you drop
unsigned mail, and they all happen to publish ADSP.  Someone's ADSP
record goes away.  Is it more likely that they've stopped signing
their mail, or that their ADSP record is temporarily messed up?  Why?

Or, I suspect most likely, they thought they were signing everything and then 
later something changed or they discovered they missed a piece of their 
infrastructure,  so they've retracted the policy until they've corrected the 
problem. 

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

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

[Scott Kitterman]

...
   1. Do we want to reduce the DKIM broken signature rate or do we want to
 make ADSP less vulnerable to it. Or both, I guess.

   2. If we want to reduce the DKIM broken signature rate, do we need to
 rework DKIM at all, or do we need to make operational recommendations to
 the generator and signer of the mail, or do we need to provide
 operational advice to forwarders and mailing list managers. For any of
 those we need to balance the improvement against the reduction in
 deployment and reduction in correct deployment the increased complexity
 will cause. The history of SPF-all and SRS is likely relevant there.
...

I'm curious what level of reliability you think DKIM signatures have
currently?  And are you measuring at a border MTA or somewhere later in
the delivery chain?

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

Re: [ietf-dkim] more on discardable, was Lists BCP draft

[Scott Kitterman]

Roland Turner roland.tur...@boxsentry.com wrote:

On 26/05/2010 22:48, Steve Atkins wrote:

 However, domain B is not an innocent bystander, as they intentionally 
 configured their mail system to reject mail it shouldn't, and the 
 recipients at domain B support that decision, on some level.

Domains don't subscribe to mailing lists, individual recipients do. The 
recipients in a domain may oppose the domain[-administrator]'s decision, 
but often lack the power to have it changed. Failure to quit your job 
cannot reasonably be construed as consent/support in this context.

This just brings us back to the Do domain owners have a right to control how 
their domains get used in email question. 

If they do, the point is irrelevant. 

If they don't,  email authentication policy is wrong and we should just stop.

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

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

[Scott Kitterman]

Steve Atkins st...@wordtothewise.com wrote:


On May 27, 2010, at 2:22 PM, Steve Atkins thinkoed:
 
 Legitimate email from paypal:
 
72% rejected by ADSP
28% not rejected
 
 Phishing emails using paypal in the From line:
 
39% rejected by ADSP
61% rejected.

That should be

 Legitimate email from paypal:
 
72% rejected by ADSP
28% not rejected
 
 Phishing emails using paypal in the From line:
 
39% rejected by ADSP
61% not rejected.

Why paypal in the from line and not from payal.com? It sounds like you are 
capturing messages unrelated to any ADSP assertions paypal.com might make. 

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

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

[Scott Kitterman]

Brett McDowell brett.mcdow...@me.com wrote:
...
As a newbie to this list, I have to say I agree.  This has been a far less 
collegial debate than what I'm used to.  That said, I may be guilty of 
reciprocating, and if anyone feels they have been on the receiving end of 
such, I apologize.
...

I think your only offense is presenting a perspective based on operational 
experience that varies from the preconceived notions of a substantial fraction 
of the participants of this working group.

There has been considerable resistance to doing any standardized policy work 
relative to DKIM.  It's unfortunate that this resulted in policy having to be 
bolted on to DKIM after it was designed because we were prohibited from doing 
policy work as a part of DKIM development. 

As far as I can see, the only problem with ADSP and your discussion of it is 
that ADSP is guilty of doing exactly what it was designed to do with exactly 
the limitations we said it would have when we designed it.  The same people 
that didn't like it then, don't like it now.

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

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

[Scott Kitterman]

Steve Atkins st...@wordtothewise.com wrote:


On May 27, 2010, at 7:38 PM, Scott Kitterman wrote:

 Steve Atkins st...@wordtothewise.com wrote:
 
 That should be
 
 Legitimate email from paypal:
 
   72% rejected by ADSP
   28% not rejected
 
 Phishing emails using paypal in the From line:
 
   39% rejected by ADSP
   61% not rejected.
 
 Why paypal in the from line and not from payal.com? It sounds like you are 
 capturing messages unrelated to any ADSP assertions paypal.com might make. 

No, I'm capturing (a subset of) phishes that were targeting paypal. That 
subset was those that were using the string paypal somewhere in the From: 
field, either in the local part or domain part of the email address or the 
friendly from. Some of those would have been rejected by ADSP, some 
wouldn't. See the message the one you quote was a reply to for the methodology.

This is just a quick and dirty way to identify a subset of paypal related 
phishes, though, as I don't want to grovel through hundreds of thousands of 
messages looking for phishes by hand. A more thorough approach would have 
found a number of additional phishes that did not have the string paypal 
anywhere in the From: line, and so which would not have been rejected by ADSP. 
In other words, were I more thorough I would have found exactly the same 
number of phishes that were rejected by ADSP and I would have found more that 
were not rejected.

(If you were to define phishes targeting paypal as phishing mail that would 
have been rejected by ADSP then that would lead to 100% of phishes rejected 
by ADSP and 0% that weren't. That would be nonsensical, though.)

Selecting messages that are by design outside the scope of what ADSP is 
intended to deal with to prove ADSP doesn't work is even more so.

ADSP does only deal with exact domain forgery. Some people think that's worth 
doing and others don't. The fact that it is not the miracle solution to all 
phishing is neither surprising nor particularly interesting. 

The working group went through this exact discussion when ADSP was being 
developed. The rough consensus of the group was to go forward and unless there 
is some new information to cause us to reconsider the decision,  hauling the 
same arguments out again is just wasting time better spent on other things. 

ADSP is not the policy component for DKIM that I would have designed, but it's 
the one we have and I'd rather see what can be done with it than rehash 
preconceived notions.

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

Re: [ietf-dkim] ADSP, was Lists BCP draft available

[Scott Kitterman]

Brett McDowell brett.mcdow...@me.com wrote:

On May 25, 2010, at 8:43 PM, Scott Kitterman wrote:

 Like I said, throw away anything that doesn't have our signature has 
 some chance of broad adoption.  Every extra word you add to the message 
 makes it less likely that people will do it.
 
 I agree with this. I have yet to see any proposals for additions that didn't 
 either add enough complexity to act as a barrier to deployment or 
 alternately make it trivially possible to allow third parties to create 
 messages that render discardable moot. 

I agree that adding anything to throw away anything that doesn't have our 
signature add complexity to implementation and therefore, by definition, is a 
barrier to adoption.  That's not what we are debating.  What we are debating 
is whether such complexity is a necessary evil that we should provide a 
specification to support -- as an optional mechanism for stakeholders who want 
to opt-in to the authenticated email ecosystem.  I *think* the answer is 
yes.  But we haven't yet had the meaningful debate that will resolve that 
question.

Let's debate whether transient trust through a MLM is actionable.  Would a new 
header that enabled the MLM to report to the receiver that they indeed 
validated the original signature actually make any difference in the 
deliverability of that message to the receiver, and if yes, is that actually a 
good thing?  I say yes and yes.  But I expect that if we debate this 
specific point one of you might highlight an unintended consequence that would 
tip the balance away from pursuing such a model.  

Thoughts?

That's not quite the question. 

Such transient trust can't be spoofable. It needs to have properties such that 
if it asserts trust me, it was signed by PayPal when I got it,  so you can 
ignore their discardable flag it can't be used by arbitrary senders to bypass 
PayPal's ADSP.

I don't know of a way to do that which doesn't require a trust relationship 
with the mail list provider. If you have such a relationship then it's 
relatively trivial to just not bother with ADSP checks for mail from such lists.

I'm left not knowing what advantage there would be from a more complex 
standardized approach. 

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

Re: [ietf-dkim] ADSP, was Lists BCP draft available

[Scott Kitterman]

John R. Levine jo...@iecc.com wrote:

 Colorful, but those were not my/our words or sentiment.

 Once again, our use case is:

Maybe, I'm dim, but I don't see any practical difference between what 
you're saying and what I'm saying, other than perhaps that you have a far 
more optimistic idea of what people will deploy that doesn't directly 
benefit them.

Like I said, throw away anything that doesn't have our signature has 
some chance of broad adoption.  Every extra word you add to the message 
makes it less likely that people will do it.

I agree with this. I have yet to see any proposals for additions that didn't 
either add enough complexity to act as a barrier to deployment or alternately 
make it trivially possible to allow third parties to create messages that 
render discardable moot. 

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

Re: [ietf-dkim] besides mailing lists...

[Scott Kitterman]

Dave CROCKER d...@dcrocker.net wrote:



On 4/30/2010 9:37 AM, Jeff Macdonald wrote:
 ESPs have a forward-to-a-friend feature for their clients. Its a
 feature in which the ESPs creates the content and sends a message from
 a friend, to a friend. It would be discarded. However, I'm willing to
 say this is a bogus practice.


F2F is a well-established and helpful feature.  That some uses of receive-side 
authentication cannot cope with it is a limitation of the authentication-based 
service, not a flaw in F2F.

If authentication has to be shoehorned into email without disturbing any 
existing practices then we may as quit and spend our time on something else.

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

Re: [ietf-dkim] DKIM charter update proposal

[Scott Kitterman]

On Sat, 24 Oct 2009 18:13:41 -0400 Barry Leiba 
barryleiba.mailing.li...@gmail.com wrote:
As I see it, the reasons to go to DS would be

Y1. to progress a fairly stable standard along a defined track, and
Y2. to review it and perhaps clean it up a little along the way, and
Y3. to get broader deployment as a result of higher maturity.

As to Y3, there's evidence, as Murray has pointed out and as many of
the rest of us are aware, that most deployment comes from publication
as PS, and from other sorts of publicity... and DS probably doesn't
create the swell of deployment that we might like.  Still, as long as
the IETF considers the three-stage standards track to have value, I
think there's some value in working within it.

The reasons not to go to DS would be

N1. to avoid wasting our time on nominal advancement that has little
or no real value, or
N2. to avoid wasting any more time working on something that's not
very useful, or
N3. in recognition that it's not stable, and that, while it certainly
meets stated criteria for DS now, we think we're likely to change it
significantly after more experience with it.

My opinion is that N1 is arguable, but that N2 and N3 are not the
case, and that we shouldn't resist advancing DKIM base to DS for
reasons N2 and N3.  My opinion is also that, while N1 might be true,
the fact the IETF considers it worthwhile overrides that.

And note that I'm only advocating advancement for DKIM base at this
point; I think we DO need more experience with ADSP before we have any
clue whether it's stable (or useful).

I think it's a reasonable set of criteria.

Where I disagree is that we have a sufficient basis to declare it stable.

It has not been very long at all since we rushed a new RFC out to clarify 
things.  What's the basis for confidence that that was it?

It is my expectation that if there are any significant warts left in the 
basic protocol it will become apparent in large scale deployments where 
DKIM signature data is being used as an input to other processes (like ADSP 
or private reputation services).  I don't see a lot of evidence that such 
deployments are at all common yet.  If other participants have significant 
experience with these, I'd appreciate hearing about it.

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

Re: [ietf-dkim] DKIM charter update proposal

[Scott Kitterman]

On Fri, 23 Oct 2009 16:54:52 -0700 Dave CROCKER d...@dcrocker.net wrote:


Jim Fenton wrote:
 It's fairly easy to demonstrate interoperability of protocols, but
 usefulness is much more difficult.  DKIM is an infrastructure protocol,
 designed to provide a basis for other mechanisms, such as domain-based
 reputation, to operate.  Those other mechanisms are as yet nascent; how
 does one judge usefulness at this point?


Jim,

This appears to be imposing criteria that go considerably beyond the 
IETF's 
requirements for Draft.

 From the standpoing of IESG process, how is this legitimate?

So is it your position that a protocol must be advanced if it meets a 
minimal set of criteria even in the face of engineering judgement that the 
protocol is not yet sufficiently deployed to have a reliable understanding 
of the adequacy of the current design?

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

Re: [ietf-dkim] How about that DKIM charter update proposal

[Scott Kitterman]

On Mon, 19 Oct 2009 09:58:55 -0700 Murray S. Kucherawy 
m...@cloudmark.com wrote:
 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
 boun...@mipassoc.org] On Behalf Of John Levine
 Sent: Sunday, October 18, 2009 1:31 PM
 To: ietf-dkim@mipassoc.org
 Cc: barryle...@computer.org
 Subject: Re: [ietf-dkim] How about that DKIM charter update proposal
 
 Re the ADSP data collection, I'd like to add a third option to move it
 to Historic if ADSP turns out to be as useful as I think, but I
 realize this is unlikely to be a popular suggestion.

How about Experimental?

Why is it more experimental now than when it was published?

From the beginning, I have not had the impression that the policy piece of 
the charter has not been taken very seriously.  Publishing All/Discardable 
does take some significant effort to make sure all of an entities MTAs are 
reliably signing.  I think it's way premature to have an opinion about if 
it will get used or not.

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

Re: [ietf-dkim] DKIM charter update proposal

[Scott Kitterman]

On Sun, 18 Oct 2009 11:54:47 -0400 Barry Leiba 
barryleiba.mailing.li...@gmail.com wrote:
Some have opined that it's even too early to consider taking the base
DKIM protocol to Draft Standard; let's make sure we have consensus on
that point, one way or the other.

I'm going to re-iterate my point for this perspective.  We do not yet have 
a broad experience base with deployment of DKIM by large, heterogeneous 
organizations.  This is a hard problem for them because they first have to 
get their outbound mail architecture under control.  

My view is that these types of deployments are the ones that will teach us 
the most about the protocol and we are at least a year and maybe two or 
three from getting significant experience/feedback to support progressing 
DKIM along the standards track.

The methaphorical ink is barely dry from our last update (which was eith 
much ado about nothing or a correction of a serious problem, I'm not quite 
sure which).

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

Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)

[Scott Kitterman]

On Sun, 11 Oct 2009 15:26:52 -0700 (PDT) Michael Deutschmann 
mich...@talamasca.ocis.net wrote:
On Sun, 11 Oct 2009, Michael Thomas wrote:
 On 10/11/2009 02:41 AM, Michael Deutschmann wrote:
  If this is indeed the official semantics of the protocol, then I would
  petition to add a dkim=except-mlist policy.  Which means I sign
  everything that leaves my bailiwick, but may post to signature-breaking
  MLs.

 No need. That is exactly what the semantics of all is.
That appears to be a contentious issue.

While I don't think the Hector/Levine interpretation is very useful, I
think it would be a sound strategic move to yield to them regarding
dkim=all, and instead create our own dkim=except-mlist space where our
semantics are in place with *no ambiguity*.

Except that the ADSP RFC is already published and so it is what it is.  It is 
definitely 
premature to crack ADSP open again (of course I thought that about DKIM too).

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

Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)

[Scott Kitterman]

On Mon, 12 Oct 2009 13:45:21 +1200 (FJT) Franck Martin fra...@genius.com 
wrote:

- Scott Kitterman ietf-d...@kitterman.com wrote:

 
 Except that the ADSP RFC is already published and so it is what it is.
  It is definitely 
 premature to crack ADSP open again (of course I thought that about
 DKIM too).
 
But as ADSP states, that the problem of 3rd party signing is not covered, 
and it seems the issue of mailing lists, then an addendum can be done.

The rough consensus of the group resulted in the ADSP we have now.  These 
issues were discussed before and until there's some reason to believe the 
rough consensus has shifted, I think it's not the best use of my time.

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

Re: [ietf-dkim] DKIM charter update proposal

[Scott Kitterman]

If advancing DKIM/ADSP along the standards heirarchy is all that's on the 
table, I think it should wait.  

Effective rollout of DKIM in large hetrgenous organizations is complex and 
takes time.  I think it's better to pause for a while and give broad 
operational experience more of a chance to exercise what has just been 
standardized.

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

Re: [ietf-dkim] Escaping things in key/ADSP records

[Scott Kitterman]

On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen t...@att.com wrote:
I'm wondering if there is a need for a web interface at dkim.org that 
would validate someone's _domainkey TXT record.

I'd say yes.  It would provide a good way to isolate record specific issues 
from other potential problems people are having error sources when 
troubleshooting.

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

Re: [ietf-dkim] DKIM adoption

[Scott Kitterman]

On Sat, 1 Aug 2009 12:51:01 +1200 (FJT) Franck Martin fra...@genius.com 
wrote:
Yes the reputation of the domain override things, but what happens when it 
is the first time a domain is seen? Does DKIM help or not? 

It can't.

Also, I'm thinking in terms of points like for spammassin. Seeing some 
patterns in the email increase or lower the points.


Some of the people involved early in the SPF project had the same idea.  It 
did encourage spaammer to adopt it, but it also had a big backlash after 
people noticed spammers could publish SPF record just fine and the positive 
points were just helping spammers.

I don't suggest a repeat.

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

Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)

[Scott Kitterman]

On Tue, 30 Jun 2009 17:01:42 -0400 hector gmail.sant9...@winserver.com 
wrote:
 Like wise, SPF 
also has sender MTA rewriter technology and that includes a standard 
protocol as well - RFC 4405 (SUBMITTER SMTP Service Extension).


I know it's OT, but in the interests of correctness, RFC 4405 is tied to 
Microsoft's Sender ID and not at all related to SPF.  Sender Rewriting 
Service/System (SRS) is, I'm pretty sure, what Hector was thinking of.  It 
has never been standardized.

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

Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

[Scott Kitterman]

On Tue, 16 Jun 2009 14:53:20 -0700 Murray S. Kucherawy 
m...@cloudmark.com wrote:
...
The intent here, I believe, is to specify that d= is mandatory output of 
a DKIM verifier module.  i= (and everything else, frankly) is optional.  
...

OK, so now I guess I'm confused.  My understanding is that if i= isn't 
specified it takes the value of d=, so I'm not clear how it can be 
undefined?

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

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

[Scott Kitterman]

On Tue, 9 Jun 2009 22:03:10 -0400 Barry Leiba barryle...@computer.org 
wrote:
Does anyone else remember anything vaguely similar to what I've said?


Yes.  That matches my recolloection.

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

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871-errata-03.txt

[Scott Kitterman]

On Sun, 5 Apr 2009 11:53:34 -0400 Barry Leiba barryle...@computer.org 
wrote:
 This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures.
 Specifically the document clarifies the nature, roles and
 relationship of the two DKIM identifier tag values that are
 candidates for payload delivery to a receiving processing module.
 The Update is in the style of an Errata entry, albeit a rather long
 one.

 I would much prefer that it created a new RFC to _Supersede_ RFC 4871,
 containing the full text as amended, and with an Appendix listing the
 changes made (whether in full old/new format like this draft, or
 otherwise), and pointing out that NO change to the protocol was intended
 or implied.

Thanks, Charles; noted.  What you say was one of the original choices
the chairs posed.
This was not, though, the consensus we arrived at in the meeting, and
there hasn't been enough support for this choice on the mailing list
either.

I'll confess that my available mental bandwidth for this wg has been 
somewhat limited lately, but I hadn't considered that we were not doing a 
complete replacement of 4871. This is confusing enough without having to do 
mental gymastics between two RFCs to understand DKIM.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Scott Kitterman]

On Fri, 20 Mar 2009 16:42:30 -0400 Barry Leiba barryle...@computer.org wrote:
Mike says...
 Dave CROCKER wrote:
 Based on Pasi's comments, I had thought we were going the RFC route.

 Well, he has a preference for /only/ going that route, but he can't
 actually veto our issuing the Errata under the Errata mechanism.  Anyone can
 post anything they want under the Errata mechanism.  Some pretty silly stuff
 has gotten posted, over the years.

 I believe that what Dave is suggesting is an end run around the IESG.
 In which case, I suggest that the working group insist on s/our/my/g;
 above so that it has similar status.

Mike, I take what you're saying to mean that you don't think the
working group is behind an end run around the IESG, and that the
errata should not be saying that it is.

What path we take to publish the errata beyond the ID that it is now,
and whether the WG is behind publishing it without Pasi's (or the
IESG's) approval, are things we'll be discussing in San Francisco and
on the mailing list.  I hope that when we leave SF we'll have most of
the answer to these, which answer we'll confirm on the mailing list.

I think we need the high-bandwidth discussion, with Pasi in the room
and responding, to get this point resolved in a way that doesn't leave
everyone waving scimitars at everyone else.  We need to be discussing
things productively as we go into final processing of ADSP and into
4871bis and Draft Standard consideration.  (I'm going to try to get a
conference call set up and use Skype and a microphone to allow remote
participants to talk.  I know we've failed at that before, but I want
to try again.)

So while I'm on the cooperation and productivity bit
To everyone: Please say what you mean calmly and clearly, so there's
less chance of misunderstanding or the taking of offense where none
was meant.  And please don't mean offense, either, of course.  Digs,
snarkiness, and passive-aggressiveness won't keep us moving forward.


Then in the spirit of plain speaking:

I do think that the current draft attempts to alter IETF consensus via the 
erata process in a way that is inappropriate.

While I think that Mike's objection was formulated in a way that unfortunately 
strucutred around personality, I agree that the content to which he was 
referring should be dropped from an eratum and addressed when the RFC is 
revised.

Scott K

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

Re: [ietf-dkim] Acronyms

[Scott Kitterman]

On Thu, 12 Mar 2009 19:51:04 +0100 Eliot Lear l...@cisco.com wrote:
On 3/12/09 3:56 PM, Dave CROCKER wrote:
 Is anyone  /against/  using AUID?


In so far as we cannot avoid a new acronym, I am not against AUID.

Eliot

+ 1

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Scott Kitterman]

On Wed, 11 Mar 2009 08:54:35 -0700 Dave CROCKER d...@dcrocker.net wrote:
Folks,

Question to the working group...


DKIM Chair wrote:
 To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, 
that we 
 will be using draft-ietf-dkim-rfc4871-errata to move forward, and the 
other 
 choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata 
as 
 written?  If not, will you post specific changes, in OLD/NEW format, that 
 would 
 make it acceptable to you?  


Unless I've missed or misread other postings, the only item lodged, so far, 
has 
been Jim Fenton's suggest that the UAID acronym be replaced, and discussion 
about that is proceeding.

Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?


I won't propose any.  I don't have time to do a proper job of rewriting it.  I 
think it alters 
the IETF conensus view via errata and adds needless complexity.  

Silence or lack of change proposals does not equate to thinking the current 
draft is good.

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

Re: [ietf-dkim] Do over? was Re: Moving on to ADSP

[Scott Kitterman]

On Wed, 11 Mar 2009 15:55:05 -0700 Jim Fenton fen...@cisco.com wrote:
Before I attempt to answer Dave's question, I have two questions for the
Chairs:

1. Is discussion of ADSP on the list in order again?

2. It sounds like what's being proposed here is a do over of the WG
and IETF Last Calls on the ADSP specification, by making a substantial
change.  Is that in order?

I have a somewhat related question.  It seems to me that this latest round of 
let's redo ADSP 
again was kicked off by a need to change ADSP due to the pending DKIM-base 
errata.

How is it possible that a design that has been through WGLC needs to be changed 
due to errata 
for an RFC it is built on and that errata is not making changes to the IETF of 
what the 
protocol is?  Compared to most of you I'm pretty new to IETF processes and 
so I' appreciate some help understanding this.

Scott K

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