[Ietf-dkim] Re: Manipulation of signed messages

[Murray S. Kucherawy]

On Thu, May 30, 2024 at 9:13 AM Alessandro Vesely  wrote:

> z= saves all fields, which would be too much in most cases.  Moreover,
> doing so
> suggests treating all fields as a whole, rather than dealing with each
> one's
> peculiarity.
>

That's not what the RFC says.

Of course, if an Original- field is tampered with the original signature
> won't
> verify after replacing it, just like if you altered z=.  But then,
> reverting
> without cooperation is not the same as doing it with active opposition.
> Why
> would someone alter Original- fields?  A mediator wanting to disrupt the
> possibility to reverse had better removing the signature directly.
>

Space munging applied to all fields, for example, is enough to break this
scheme.  "z=", by contrast, is immune to such mutations, because it's
encoded.

-MSK
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: Manipulation of signed messages

[Murray S. Kucherawy]

On Thu, May 30, 2024 at 3:30 AM Alessandro Vesely  wrote:

> z= is a valuable tool for debugging and learning why signatures fail.  For
> reversing purposes, instead, Original-* fields are preferable as they can
> be
> individually added and possibly signed also by different operators.
> Reversal
> must not blindly replace altered fields so as to force verification.  It
> should
> check whether the applied changes meet per-field acceptance criteria.
>

I don't understand your "preferable" claim given that an Original-* field
is subject to mutation just as any other field is.  It's just as fragile as
any other solution.  At least with "z=", you're far more likely to get back
an actual original.

-MSK
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: Manipulation of signed messages

[Murray S. Kucherawy]

On Wed, May 29, 2024 at 11:09 AM Alessandro Vesely  wrote:

> On Wed 29/May/2024 19:29:27 +0200 John Levine wrote:
> > It appears that Alessandro Vesely   said:
> >>My verifier, in particular, works every time on my messages.  It doesn't
> mean
> >>it doesn't work at scale.
> >
> > Nor, of course, does it mean that it does.
>
> However, if it doesn't work for a given list, it's always possible to add
> more
> stuff in the header that will help the verifier restore the original
> values and
> evaluate if the amount of change the list applied is acceptable.  Since
> the
> signer and the verifier is the same program, it's easy to coordinate.
>

I'm generally an advocate of experimenting with the notion of at least
attempting reversible mutations, but I just realized that there might be
data that the notion is a futile one.

"z=" has been around since RFC 4871.  The "z=" tag, when used, typically
contains an encoding of the entire original header.  This could be used to
recover a signature that was invalidated by a header field modification of
some kind.  Has anyone heard of a verifier actually doing so?

OpenDKIM can do this.  It won't then switch the result to a valid one, but
it will at least tell you what change was made to the header that
invalidated the signature so you can pass that information back to the
signer if you wish.  I thought this was a valuable thing to add at the
time, but I don't think I've ever heard of anyone trying to extend it to
change the validation result.

All of that is meant to say that the idea of undoing mutations you're able
to identify has existed for a while, at least in one implementation.
However, since it hasn't been identified as an interesting capability in
the intervening years, it would seem to support Barry's claim that a broken
signature oughta just stay broken.

-MSK
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Murray S. Kucherawy]

On Thu, May 23, 2024 at 11:13 AM John Levine  wrote:

> On the other hand, I see that the perl and python DKIM modules sign
> the MIME Content-* headers by default. Do you remember what opendkim
> does? A quick look at the code wasn't too enlightening.
>

It signs them all unless you configure it to sign only specific ones.

-MSK
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Murray S. Kucherawy]

On Thu, May 23, 2024 at 7:44 AM Wei Chuang  wrote:

> Just specifically in regards authenticating mailing list modifications:
> fair enough that the ideas should be implemented first before any sort of
> IETF publication for it.  Still there ought to be a place for informal,
> early discussion of ideas on authenticating mailing lists.  For this
> proposal, I think there are issues around the intersection of DKIM signing
> and Content-type, and in particular, there will be advice such as in the
> researcher's blogpost
>  that
> calls for "h=" oversigning the Content-type header to help prevent the
> delimitter modification as was done.  While understandable, I suspect this
> prevents adding a mailing list footer as a new MIME part and perhaps too
> restrictive.  Instead would it be reasonable to say there be sufficient
> protection if the forwarder takes ownership of appended footers?  If not,
> another approach would be to version the Content-type header?  Yet another
> approach would be to resign the DKIM signature by the forwarder, but that
> hides who the sender is causing UI and spam filtering problems.  Going back
> to my original point, would the ietf-dkim list be the right place for this
> cross-cutting discussion?  I think there are a few targeted questions that
> need some discussion.  (We're interested prototyping but that's at least a
> quarter or so away)
>

I think this is a fine place to have the discussion.  Or at least I can't
think of a better one.

I've read the middle part a few times and I don't understand either the
attack or the proposed mitigation, so I think some examples might help.
Taking a multipart message that signs (but does not oversign) Content-Type
in order to add a footer or something would still invalidate the message
because the body would be different, even near the top (within any "l="
that is not zero).  That's also true for adding Content-Type that wasn't
there; the top of the message would need to change.

-MSK
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: WG Action: Formed Mail Maintenance (mailmaint) / Commitment

[Murray S. Kucherawy]

On Tue, May 21, 2024 at 10:05 AM Jim Fenton  wrote:

> One thing that hasn’t been clear to me:
>
> On 21 May 2024, at 9:48, Murray S. Kucherawy wrote:
>
> > * Prior to accepting any Standards Track document for development, there
> must
> > be a commitment to implement the resulting proposed standard from at
> least
> > two independent parties, as recorded on a related IETF mailing list.
>
> Am I correct that “accepting…for development” means WG adoption of an
> internet draft that is intended for Standards Track?
>

I think that's literally what the "..." part says, yes.  :-)

-MSK
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: Fwd: WG Action: Formed Mail Maintenance (mailmaint) / Commitment

[Murray S. Kucherawy]

Before diving into this thread, I think it's important to underscore that
we're not taking anything away here.  None of the previously available
paths (ISE, AD sponsorship, DISPATCH handling, new WG, any I've forgotten)
are suddenly unavailable as a result of chartering this working group.  The
only constraint being established is: If you want this particular working
group to process your work, there's a specific minimum you need to meet.

On Sun, May 19, 2024 at 7:22 PM Dave Crocker  wrote:

> On 5/10/2024 2:33 PM, Dave Crocker wrote:
>
> On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote:
>
> * Prior to accepting any Standards Track document for development, there
> must
> be a commitment to implement the resulting proposed standard from at least
> two independent parties, as recorded on a related IETF mailing list.
>
> Just realized this concern did not get attention:
>
> Simply put this is a thoroughly unreasonable burden.
>
> Companies don't work that way.
>
> Companies do not make public, future commitments for implementing
> standards.  And when there are attempts to get them to, they waffle and
> evade.
>
Companies aren't the only participants here.  The vast majority of
proposals I've worked on have been instigated by the community, not by a
company.

Again, if the goal is to limit this working group to only take on
> specifications that are already in use, then just say that.   It's simpler,
> clearer, more direct and, frankly, more pragmatic.
>

That's not the goal.  The goal is to limit this specific path to
publication by strongly preferring things that either already interoperate,
or are likely to interoperate after publication, because someone (well, 2+
someones) actually tried it.

> Because that is the practical effect of what's in the charter.
>
I don't think it goes that far.

-MSK
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Murray S. Kucherawy]

On Sun, May 19, 2024 at 9:27 AM Wei Chuang  wrote:

> As many of you know there was a DKIM security vulnerability disclosure
> Friday around the signature header body length tag "l=". The blog post is
> here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
> The authors state that an adversary can append a malicious footer to a
> message with DKIM w/body length, then rewrite the Content-type header mime
> delimitter, that will cause the apparent body to be that of the footer but
> will authenticate as the original DKIM signature.  This enables spoofing
> the original sender's identity, hence can spoof DMARC and BIMI but with a
> malicious message body.  DKIM RFC6376 section 8.2  already
> describes this problem, which the authors acknowledge, but according to
> them what is new is that there actually is mail traffic with DKIM-Signature
> w/body length which includes Fortune 500 companies.
>
> [...]
>

As everyone seems to be agreeing, there's nothing new here.  The only
concern is that people actually do use "l=" for some reason in spite of the
warnings.

There's talk here of revising RFC 6376 to remove the tag.  That's certainly
one option, and it's worth noting that we did consider doing so when RFC
4871 became RFC 6376 (STD 76), but as I recall a constraint of removing a
feature when upgrading something to Internet Standard states that the thing
you want to remove has to be unused, and "l=" was found to be in non-zero
use, so we were forced to keep it, even with the warnings.

Also, deleting it from the specification now will in my view not be much of
a solution given:

(a) Inertia will mean "l=" is generated and/or accepted for a long time to
come no matter what we say or do; and

(b) Even if (a) weren't true, "l=" then becomes an unrecognized tag at
verifiers, which will mean those signatures break and we have an
interoperability problem (though likely a tolerable one).

DKIM also warns signers to sign anything that goes to the content or
structure of the message.  RFC 4871 used to include a list of fields that
SHOULD be signed, and I think Content-Type was one of them; RFC 6376
removed the explicit list in favor of more abstract guidance that should
lead anyone toward the same original list at least.  So even that aspect of
this attack was anticipated.

It seems to me this is solved easier with local policy changes.  DKIM
allows for rejection of signatures for any local policy reason, so
operators could just start rejecting messages that use "l=" or that fail to
sign/oversign "Content-Type".  This could be an Informational document
rather than one that updates the standard.

Dave Crocker mentioned that there is a pathway to do a narrow update to the
> RFC6376 as an individual submission.  I agree that it is a good idea as
> hopefully a narrow update can be done relatively quickly.  I understand
> that body length "l=" was meant to help DKIM tolerate adding a footer
> that a mailing list might do and that there is pressure from the DMARC
> world to think about this.  Perhaps that still can be done except in a
> better secure way, and that work could be a separate document to permit it
> time to figure out how to do it.  One idea is to have the forwarder sign
> with an ARC Message-Signature and would take ownership of the new message.
> The forwarder would describe the offsets to recover the original body
> length and some receiver can validate the original DKIM signature.  Those
> offsets will also describe the forwarder's contribution to the message.
> There would also be problems around secure footer modification of
> Content-type header that are unsolved e.g. what to do if Content-type is
> oversigned.  All this work might be good candidates for the newly chartered
> Mailmaint WG.
>

Before we make suggestions about ARC, I would strongly suggest someone try
that as a solution or mitigation to this problem.  I would not like us to
publish something that shouts about this being a serious problem but then
presents untested solution(s).  And frankly, I'd like to see ARC graduate
out of Experimental status if that's what we want to put forward as a
solution.

As to MAILMAINT as a venue, we'll have to see whether the community thinks
this is "big" or "small"; if the former, it should probably get its own WG.

-MSK, presently hatless
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Fwd: WG Action: Formed Mail Maintenance (mailmaint)

[Murray S. Kucherawy]

FYI

-- Forwarded message -
From: IESG Secretary 
Date: Thu, May 9, 2024 at 1:01 PM
Subject: WG Action: Formed Mail Maintenance (mailmaint)
To: IETF Announcement List 
Cc: , , 


A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information, please contact the Area Directors or the WG Chair.

Mail Maintenance (mailmaint)
---
Current status: Proposed WG

Chairs:
  Kenneth Murchison 

Assigned Area Director:
  Murray Kucherawy 

Applications and Real-Time Area Directors:
  Murray Kucherawy 
  Orie Steele 

Mailing list:
  Address: mailma...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/mailmaint
  Archive: https://mailarchive.ietf.org/arch/browse/mailmaint/

Group page: https://datatracker.ietf.org/group/mailmaint/

Charter: https://datatracker.ietf.org/doc/charter-ietf-mailmaint/

Internet Messaging (“email”) is one of the oldest applications still
supported by the IETF.  It consists of numerous layers and extensions that
support the robust construction, transport, retrieval, and interpretation of
messages.

(For the purposes of this charter, “email” starts in RFC 5321 which covers
transport and RFC 5322 which covers message format, and extends into
specifications based on those documents and their antecedents.  It also
includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et
seq].)

>From time to time, new work in the email space is brought to the IETF for
consideration and development.  Where there is enough critical mass to
create
a working group to develop and publish the work, this is the preferred
case.
More often, however, a proposal is brought that lacks enough critical mass
to
independently support chartering of a working group, but would still be
useful to publish as a standard.  Such projects must then either seek the
assent of an Area Director willing to sponsor it as a standards track
document, or support via the Independent Stream Editor (ISE) without
standards track status.

The MAILMAINT (“Mail Maintenance”) working group will consider projects in
the email space that are too small to warrant construction of a dedicated
working group.  This will take advantage of a common community to consider
these proposals rather than forming a series of disparate but related
communities.

Work proposed for MAILMAINT may arrive via direct proposals, or it may be
referred via one or more DISPATCH-style working groups.  Recorded Calls for
Adoption are required for all work proposals.

Proponents of work that is not taken up within the IETF may, of course,
decide to bring their proposal to the Independent Stream.  The working group
should discuss such proposals with the ISE and share the results of the
working group’s consideration.

Further, MAILMAINT will observe the following constraints when considering
the adoption of new work directly:

* Prior to accepting any Standards Track document for development, there
must
be a commitment to implement the resulting proposed standard from at least
two independent parties, as recorded on a related IETF mailing list.

* When deciding to send any Standards Track work to the IESG, there must
first be produced a report documenting at least two (preferably more)
independent implementations with at least partial interoperation based on
the
developed specification.

* The above constraints do not apply to documents that are not intended for
the Standards Track.

* Chartering of a dedicated working group with a custom charter is strongly
preferred when engaging any work that updates any base email documents,
including but not limited to those identified above.

All work will be announced to appropriate non-WG lists such as ietf-822,
ietf-smtp, ietf-dkim, etc., at the time a Call For Adoption or Working Group
Last Call begins.

Standards work being taken up by MAILMAINT should be checked with other
relevant areas (mainly Security) to confirm appropriate oversight or
possible
assignment to that area.

Milestones will be used to track all approved work, including during
chartering and rechartering.

Milestones:

  Jul 2024 - Call For Adoption of draft-dweekly-wrong-recipient
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Re: [Ietf-dkim] Question regarding RFC 6376

[Murray S. Kucherawy]

On Mon, Mar 11, 2024 at 2:04 PM David Harris 
wrote:

> Thank you for taking the time to answer my questions - most appreciated.
>
> Your answer has addressed questions 1 and 2 for me. I'm still unclear on
> certain aspects of question 3, though:
>
> [...]
>
> The pseudocode for "sig-alg" says:
>
> signature=  sig-alg (d-domain, selector, data-hash)
>
> I took this as meaning that the d-domain and selector strings need to be
> passed to something before the data-hash; the problem was what that
> "something" was - I had been assuming that it was a third hash that was
> then
> signed, yet the rest of the section says (in more than one place) that
> only two
> hashes are required.
>
> Having read through your response, which describes the process as I was
> originally expecting to follow it, I now wonder if this is another case of
> the
> pseudocode having confused me as it did in question (1)... Are we perhaps
> intended to read "d-domain" and "selector" as parameters that are used to
> choose the appropriate signing key, rather than as input to the signed
> data
> itself?
>

Yes.  The d-domain and selector are used to compose the DNS name at which
the verifier will look for the public key, so naturally that tuple also
identifies the corresponding private key you need to use when signing.

I suppose you could think of it this way as well:

signature = sig-alg(private_key(d-domain, selector), data-hash)

...where the private_key() function yields the private key matching the
(d-domain, selector) tuple.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question regarding RFC 6376

[Murray S. Kucherawy]

On Mon, Mar 11, 2024 at 6:50 AM David Harris 
wrote:

> Question 1:
>
> My first question is the exact meaning of this piece of pseudocode:
>
>body-hash=  hash-alg (canon-body, l-param)
>
> Does this mean:
>
> 1:  Pass the canonicalized body to the hash algorithm, then pass the value
> of
> any l= tag to the hash algorithm as well.
>
> -- or --
>
> 2:  Pass the canonicalized body to the hash algorithm, restricting the
> amount
> passed to the value of any "l=" tag.
>
> >From the way the other two pseudocode items are written, (A) would seem
> to
> be the correct interpretation, but that raises the question of what should
> be
> passed - a binary form of the l= value? Or a string representation? And
> what
> should be done if there is no l= tag at all?
>

(2)  It's a pseudocode function to which the value of the "l=" tag (if
present) is a parameter.  The result is a hash of canon-body; digest all of
it if l-param is not present, otherwise digest the first l-param bytes only.


> Question 2:
>
> I am puzzled by the reference to an item called "a-hash-alg" in the NOTE
> part at the end of this section: "a-hash-alg" does not appear anywhere
> else in
> the document, and since it has not been mentioned in an erratum anywhere
> (as far as I could see), I assume it must have some specific meaning
> defined
> somewhere else. Could someone direct me to a reference explaining this
> term?
>

Looks like this is a typo, perhaps warranting an erratum of its own.  It
should be just "hash-alg".


> Question 3:
>
> The main problem I am having is understanding exactly how the signing
> process is meant to be handled: traditionally, you would either use your
> hash
> algorithm (SHA-256 in this case) to generate a digest of the content, then
> have your crypto library (OpenSSL in my case) generate a signature for
> that
> digest. There are also "streaming" APIs available that perform the hashing
> and signing as a combined task.
>
> I would have assumed from the pseudocode that the intended action here
> was to do one of the following:
>
> *  Pass d-domain, selector, and data-hash in that order to an SHA-256 hash
> algorithm, then generate an RSA signature using the hash generated by that
> process as its digest.
>
> *  Call a streaming RSA-SHA256 API passing each of the three items in the
> correct order then finalizing the signature.
>
> Either of these approaches *should* generate the same signature. The
> problem comes from the NOTE section, where it says:
>
> -- Cut here 
>When using such an API, the last two steps in the
>algorithm would probably be combined into a single call that would
>perform both the "a-hash-alg" and the "sig-alg".
> -- Cut here 
>
> It is difficult to interpret this without knowing what "a-hash-alg" means,
> but on
> the assumption that it is a typo, that suggests that the pseudocode
> sections
> "data-hash" and "sig-alg" would be rolled into one step -- but I can't see
> how
> that could work, since "sig-alg" requires "data-hash" (which I understand
> to
> be an actual hash result) as its input. The NOTE comment seems so at odds
> with the two intended actions I described above that I am not sure which
> approach is the one I need to take.
>
> I have spent quite some time trying to perform internet searches to
> clarify this
> section, but it's historically something I do quite poorly, so if there is
> a nice
> clean explanation of this somewhere, I'd be really grateful if someone
> could
> send me a link to it.
>
> I'm sorry to send such a long message, but hope someone will feel
> charitable
> enough to help me out on these issues.
>

The signature is the result of base64-encoding the RSA encryption of the
data-hash.

The data-hash is the result of passing the canonicalized headers, in order,
to the SHA algorithm.  The canonicalized headers include, at the end, the
incomplete DKIM-Signature field that's under construction.  You then append
the base64-encoded form of that signature to the incomplete DKIM-Signature
field and attach it to the message.

In some cases (e.g., OpenSSL) , the call sequence would be:

* create a digest object (one API call)
* feed it the header fields and so forth, as described (N API calls,
depending on how you do the work)
* finalize the digest (one API call)
* encrypt the digest using the specified key (one API call)

Some APIs (e.g., GNUTLS, as I recall) provide a different interface,
allowing you to do all of that in a single call.  I believe the NOTE you're
citing is just emphasizing that the four-step method and the one-step
method are equivalent as far as DKIM is concerned; as long as what you end
up with is an RSA encryption of the SHA digest, you have what you need.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

[Murray S. Kucherawy]

On Thu, Mar 7, 2024 at 1:05 PM A. Schulze  wrote:

> I enabled double signing years ago on my personal domain and last year at
> an medium scale ESP.
> So far, we didn't noticed negative effects.
> Intentionally I removed SPF on my personal domain last year, also without
> any delivery issues.
>
> I also validate both signatures if present but didn't any statistics.
>
> One interesting point is the signature order. Without specific reasons I
> sign rsa first, then ed25519.
> This message is the first, I send with the opposite order: ed25519 first,
> then rsa.
> Let's see, what will happen... My naive assumption: order don't matter.
>

Section 4.2 of RFC 6376 is pretty nebulous about this.  You can do them in
any order, and you can stop after you get one that you like based on
whatever local policy you choose or do them all.

Given the time that's passed since RFC 8463 was published, I'd expect to
have heard that order matters in one way or another if indeed it does.  The
absence of such experience might be telling.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Murray S. Kucherawy]

On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso  wrote:

> If a graphical user interface gives you a green "ok" button to
> click, or "red" otherwise, that is even better as in browser URL
> lines.  Then pop up a tree-view of message modifications and
> alertize where it broke, checkbox for is-this-really-an-evil.
>

I remember seeing a study presented at a conference that showed people
sometimes[*] click on links found in their spam folders.  If the act of
moving a suspect message out of the way is not enough to protect users from
bad actors, I can't imagine how a green-yellow-red light icon in the inbox
is going to do any better.

-MSK

[*] By this, I mean a statistically significant portion of them do.  The
number I remember is 18%, but I wouldn't be shocked to see it higher.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Murray S. Kucherawy]

On Mon, Feb 5, 2024 at 8:50 AM Dave Crocker  wrote:

> OpenDKIM will not sign a message that fails basic RFC5322 header checks
> (e.g., "From" or "Date" is missing), but will place an
> Authentication-Results field indicating the message is malformed.  At some
> point, though, someone talked me into making it possible to bounce such a
> message in the filter.  I wish I could remember the full context.
>
> So you are enforcing an RFC5322 requirement for From and Date to be
> present, although the DKIM spec only requires signing From.
>
> Why are you doing that?
>
> Imagine RFC5322++ removes the requirement for Date. (In fact I had not
> remembered Date is required, going all the way back to RFC733. sigh.)  That
> requires remembering and changing DKIM code.
>
> I understand the desire to do this extra checking, but not the
> justification for giving in to it, inside DKIM.
>

Yeah, as I said, I wish I could remember.  It's a bit of a contradiction.
My best guess is that something was injecting messages without a Date field
knowing the MTA (sendmail, in this case) would add one.  But this had the
effect of causing the filter to oversign that field, so the MTA adding one
immediately invalidated the signature.  Adding this check avoided that
problem.


> It also allows for specification of things that are likely to be rewritten
> downstream (e.g., address canonicalization), which it can then simulate
> when computing its hashes, in order to make validation of the signature at
> the verifier more likely to succeed.[*]
>
> "likely to be rewritten downstream" is clearly part of local
> implementation design choices.
>

Yes indeed, though in my case I was compensating for an implementation
choice in the MTA to which the filter provides a service, and I don't have
direct control over the MTA's choices.

> While possibly quite reasonable to make for the implementation, they have
> nothing to do with the standards specification, other than to encourage
> writing standards that neither require nor inhibit such choices.
>
Yes, I agree that the specification should follow what I call the "pure"
angle, but also be abstract enough not to constrain implementation to
enable reality.

> (*) Lon ago, Knuth visited UCLA when I was there, and 'structured
> programming' was a hot topic.  He did a presentation to test a perspective
> that he later wrote up.  He observed that fully structured programs,
> without gotos, could sometimes make code /worse/.  He shows some code
> without any gotos that was correct but extremely difficult to read and
> understand.  Then he showed a version, with two loops -- one after the
> other -- and inside each was a goto into the other.  OMG.  But this code
> was clear, concise and easy to understand.
>

Interesting.  Is that online anywhere?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Murray S. Kucherawy]

On Sat, Feb 3, 2024 at 1:54 PM John R Levine  wrote:

>
> > It also optionally does LF to CRLF translation.  I'm fairly certain this
> is
> > to accommodate local/human SMTP injections since humans can't be expected
> > to type CRLFs when entering manual tests from a shell. ...
>
> Unix MTAs strip out the CR in CRLF, often on the way in, so by the time
> opendkim sees the message, the line endings are just LF.
>

That might be true when it's handing a message to an LDA, but it's not true
for SMTP ingress filters.  For milter, CRs are preserved in the body, so
opendkim sees exactly what came in over the wire.

https://pythonhosted.org/pymilter/milter_api/xxfi_body.html

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Murray S. Kucherawy]

On Sat, Feb 3, 2024 at 5:40 AM Dave Crocker  wrote:

> Having a DKIM module check for one aspect of RFC5322 conformance -- raises
> a need to make it a full RFC5322 compliance engine.
>
> If it doesn't, then the  attention to compliance is a random walk through
> whatever concerns are fashionable at the moment.  That is, is sprinkles
> stray bits of compliance code in a place that won't be -- and shouldn't be
> -- expected to have it.
>

I generally agree with the idea that there's a layering problem here, i.e.,
that a DKIM filter should be able to safely presume that its input will
comply with RFC5322 and not alter the message at all other than adding the
signature.  But on review, it seems like I've tiptoed over that line from
time to time in support of robustness in some form or another.  For
instance:

OpenDKIM will not sign a message that fails basic RFC5322 header checks
(e.g., "From" or "Date" is missing), but will place an
Authentication-Results field indicating the message is malformed.  At some
point, though, someone talked me into making it possible to bounce such a
message in the filter.  I wish I could remember the full context.

It also allows for specification of things that are likely to be rewritten
downstream (e.g., address canonicalization), which it can then simulate
when computing its hashes, in order to make validation of the signature at
the verifier more likely to succeed.[*]

It also optionally does LF to CRLF translation.  I'm fairly certain this is
to accommodate local/human SMTP injections since humans can't be expected
to type CRLFs when entering manual tests from a shell.  Again, though, this
only alters what's fed to the hash, as it expects the MTA will do this
conversion before the message is relayed en route to its destination; not
doing so dooms the signature to failure.

I think most of this is because the original milter interface, on which
this work was based, is an SMTP input filter.  Output filtering wasn't
originally available, meaning the filter saw the raw form of the input
rather than a "treated" form, and had to anticipate what the recipient
would see.

Maybe this illustrates the difference between pure software engineering and
applied software engineering?

-MSK

[*] The success of this feature is what makes me think a "list transforms"
extension to DKIM might also succeed.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Murray S. Kucherawy]

On Thu, Feb 1, 2024 at 10:03 AM John Levine  wrote:

> It appears that Murray S. Kucherawy   said:
> >-=-=-=-=-=-
> >
> >On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso 
> wrote:
> >
> >> But i cannot read this from RFC 6376.
> >
> >Sections 2.8 and 3.4.4 don't answer this?
>
> Not really.  They say what to do with CRLF but not with a lone CR or lone
> LF.
>

Ah, I misunderstood the question.

I agree that by the time you're talking to a DKIM (or any) filter, I expect
that this has been handled somehow.  CRLF ends a line, anything before that
is part of the line, and WSP is just a space or a tab.  Past that, garbage
in, garbage out.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Murray S. Kucherawy]

On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso  wrote:

> But i cannot read this from RFC 6376.
>

Sections 2.8 and 3.4.4 don't answer this?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Murray S. Kucherawy]

On Wed, Jan 31, 2024 at 9:35 AM Hector Santos  wrote:

> First time I have come across the term (“oversign”)  and it appears to be
> a feature with several products in the market. But checking the RFC, unless
> I missed it, it’s not a RFC defined term.  Replay is the term used.
>

You won't find it in any RFC or other formal place.  I think I
(accidentally) coined the term when I first added this capability to my
open source work.  I needed a short keyword to stick into a configuration
file to turn this on, and that's what came out.  We never went back and
added it to the RFC.

To me, the term connotes “redundant signing” beyond what is necessary or
> desired for a particular signing rule.


In a sense it is, but doing so also has a specific preventative side effect
that RFC 6376 describes.


> [X] Enable DKIM Replay Protection
>
> The F1 help will indicate the addition of headers, i.e.  To:, Subject:,
> etc. as empty field values are used to enforce the hashing binding of these
> potentially missing headers to the signature. If enabled, then these
> specific headers MUST be included in the list of headers to be signed and
> the headers MUST exist.  If not, the headers with empty values will be hash
> bound to the signature.
>
> Is that “Oversigning?”


To protect against this header attack, there's more to it than this.

RFC 6376 says that for each field named in "h=", find the next (bottom-up)
unused instance of that field and feed it to the hash; if there are no more
unused instances, skip it.  What this means for "From", for example, is
that if you oversign "from" (by listing it an extra time) on a
normally-formed message, the signer will always hash the one "From" you
have and then skip the extra one.  But on verification, if someone has
added an extra "From" field, both of them will get hashed, which means the
signature won't validate because what got hashed at the signer and what got
hashed at the verifier aren't the same.

So more generally, to "oversign" means to include an extra instance of the
field name(s) you want to protect from such insertions by adding one more
instance in "h=" beyond what's in the message at signing time.

It's not true that the header field MUST exist.  (You could add that
constraint, but it's not strictly necessary.)  I can say "h=banana:..." on
a regular message when that's not a field you expect to be on the message.
If a "Banana" field gets added anywhere, validation will fail, but it
otherwise doesn't interfere with anything.

For the code I wrote, the list of fields to sign and the list of fields to
oversign are separate.  The oversign list is just tacked on to the end of
the "h=" before the header hash is finalized.  The two lists don't have to
overlap at all (though they usually do).

Finally, I'd be careful about calling this "Replay Protection".  It
addresses only one type of replay attack.  The sort of replay attack that
caused this group to recharter isn't prevented by oversigning, for example.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Shutdown deadline

[Murray S. Kucherawy]

Hi all, welcome back from the holidays.

It's been about ten weeks since Laura posted about the status of the WG,
and a final plea was made for energy and activity.  Since then, despite a
handful of people expressing interest at the M3AAWG meeting in Brooklyn,
there has been no activity of any kind; the promise of progress has once
again been a false one.  Even granting extra time for the holidays that
just passed, I think we've waited long enough.

Accordingly, a deadline seems in order: This WG will close sometime after
January 15th if no sustained push to be productive toward the charter's
goals has developed by then.  Anything after that will need to be sponsored
by a willing Area Director, seek publication via the ISE, or start the
DISPATCH process over again, and surviving that latter option will probably
face a high credibility bar.

-MSK, ART Area Director
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Signature

[Murray S. Kucherawy]

On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko 
wrote:

> I would like to ask to consider the possibility of defining a DKIM
> signature using Ed448. [...]


Which DKIM implementations are known to be willing to support this if it
were added?

ED25519 support was added by a working group called DCRUP.  Although that
WG has since closed, the list is still open and you could try posting there
to see if there's interest.

I don't think there are any working groups currently operating whose
charters include taking up work like this.  The registry rules require an
RFC with IETF Consensus, which would mean either a working group or
sponsorship of an Area Director.  You would just need to produce a short
document like RFC 8463 to get this done.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] [Lists] DKIM Working Group Status Update

[Murray S. Kucherawy]

On Fri, Oct 27, 2023 at 6:33 AM 
wrote:

> Appreciate all the work and effort you’ve put into this. I would like to
> help out as much as I can. I know Monitoring isn’t part of this from IETF
> POV, however, I think it’s something that is important and I will bring
> this up on the M3AAWG side.
>

Please don't discount the IETF's interest in measurement too quickly.
Actual operating experience (represented by data) is far more persuasive
than opinion a lot of the time when it comes to shaping protocols.

"Data, data, data!  I cannot make bricks without clay."
-- from the works of Sir Arthur Conan Doyle

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM-FBL

[Murray S. Kucherawy]

I'm betting the chairs would want this not to consume any of the
so-far-meager energy this WG is showing.  I can imagine that ietf-smtp
would be a reasonable place to at least announce that you're working on
this.  I don't know that that's a good home for ongoing discussion either
though.

We don't really have a venue that talks about feedback loops that I can
find, which seems to me to be the primary thing here.  It almost seems like
the old MARF list (if it's still open) might be, though I don't know who
might be paying attention.  Or you could always use the ART list.

If you're trying to identify a venue for processing it, there's no WG that
comes to mind.  You could take it to DISPATCH and see what they recommend.
But unless lots of people show up and want this to happen inside the IETF,
I would consider using the ISE route.

-MSK

On Wed, Sep 27, 2023 at 4:37 AM Brotman, Alex  wrote:

> Hey folks,
>
> I'm not entirely sure this is the right place for this.  Someone else
> suggested the DMARC list, and I thought perhaps the "smtp" list might make
> more sense.  If I'm shuffled off to one of those lists, I'll let this
> thread know.
>
> I've attached a draft that uses attributes of a passing DKIM signature to
> create a DNS label that can be used to discover an FBL address.  This
> feedback address can be used by message receivers to provide a copy of FN
> (and potentially FP) (Spam/Not-Spam) reports to the DKIM signers.  This
> allows for entities to perhaps sign with more than one signature, and
> provide feedback to each signer if desired (or each can list multiple rcpts
> if desired).  With traditional FBLs, the lookup is likely based off the
> final sender IP address, which could be the original sender, or an
> intermediary.  This DKIM-based method could aid both MBPs and ESPs in
> fighting outbound abuse from their platforms.  There are also methods in
> the document to attempt to do more to make reports smaller, aiding storage
> and PII concerns.  Thanks for your time and feedback.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Murray S. Kucherawy]

On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson  wrote:

>
> Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in
> control of the signer, as opposed to the attacker.
>
>
> Has anyone (else) implemented it?
>
>
> That's what I want to understand. Or, more specifically, if no one
> implemented it, why? And have those blockers changed due to the changed
> landscape with dkim replay, etc.
>

When DKIM was young, a mechanism like the one defined in RFC 6651 was
enormously valuable to me when two implementations were trying to debug
interoperability problems.  It allowed us to see why signatures were
failing.  Once all the bugs were worked out and things like
canonicalization and common MTA mutations were well understood, the need
for this sort of thing faded away.

Thus, I never heard of any implementations besides the first one.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Murray S. Kucherawy]

On Thu, Sep 7, 2023 at 9:38 PM Jesse Thompson  wrote:

> Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in
> control of the signer, as opposed to the attacker.
>

Has anyone (else) implemented it?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Murray S. Kucherawy]

On Thu, Sep 7, 2023 at 3:15 PM Evan Burke  wrote:

> To be clear, for us x= was one of the most effective defenses against
> large-scale replay attacks. Not perfect, obviously, but applied carefully
> and in conjunction with header oversigning, it created a significantly
> narrower window for attacks, and reduced the potential financial return to
> attackers from replay spam.  I would note that the effectiveness of x= for
> reducing replay risk will likely vary considerably from signer to signer,
> depending on a number of factors; we may be better positioned than many
> signers in that respect.
>

So this is interesting, in the sense that:

(1) RFC 7489 warns against using "x=" for this purpose, so if that turns
out to have been the wrong advice and there's evidence to back that up,
then this is an opportunity for us to say so; and

(2) If such a combined (e.g., with oversigning) technique isn't terribly
IPR-encumbered, you're free to put forward a description of what you did as
a mitigation strategy, which this WG was hoping to produce; even if DKIM
itself isn't modified, this could be an Applicability Statement.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Murray S. Kucherawy]

On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker  wrote:

>
> The "new header field" (or similar) approach alone would not open any
> doors for revocation/invalidation of the fact that the signature was
> applied on that first single message. Relying solely on fast key
> rotation/invalidation would mean TTLs would need to be very low to have any
> effect.
>
> Keys cannot be rotated fast enough to be useful within the time frame that
> attackers work in.
>
> Key rotation works in a timeframe of days or weeks.  Attackers work in the
> timeframe of minutes.
>

I think we disqualified use of "x=" as a mitigation on the same basis.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Murray S. Kucherawy]

On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker  wrote:

> On 8/29/2023 7:46 PM, Grant Taylor wrote:
> > On 8/29/23 9:02 PM, Dave Crocker wrote:
> >
> > Why not re-use the existing DKIM solution, just with a different
> > domain / set of keys?
>
> Because it does not provide the affirmative information that I am
> postulating/guessing the originating platform can supply.
>

I have to agree.  It's compelling to consider that a high-trust domain
might flag something for my extra consideration.  This could be done
per-message, rather than per-key, which was Grant's counterproposal; the
equivalent is to generate a selector per message, which appears at least on
the surface to suffer problems of scale.

Rather than doing it in a header field, though, could it be done simply
with a new tag?

> Let a domain establish a bad reputation.  Especially if it's being
> > used for sending messages that are considered to be questionable.
>
> Establishing a reputation takes time.  The likely behavior of a bad
> actor is within a very short time-frame.
>
> And it is a single account, not the entire domain, that is the problem.
>

Or even a single message.

And I've never understood why people get enamored of the idea of relying on
bad reputations to spot bad actors.  A bad actor who thinks it has
attracted a negative reputation need only move to a new name in an
otherwise gigantic public namespace (domain name or IP address) to start
over from zero.


> > Just use different domains / keys to indicate different things.
> >
> > No new standards.  No new code.  No new config.
>
> And no new information.  Hence, current mechanisms only, which are not
> all that successful for this problem.
>

This also presumes that operators currently develop reputation based on
(d=, s=) pairs.  Is that so?  I thought it was mostly just the d= that
matters.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Murray S. Kucherawy]

On Tue, Aug 29, 2023 at 11:10 AM Dave Crocker  wrote:

> Two thoughts:
>
>1. If the substance of the message should fail a quality assessment,
>why does it pass at the outbound (sending) site?
>2. If the problem is reasonable content, but sent to many unintended
>(or, rather, undeclared) recipients, then the only characteristic of note
>is the fact of multiple transmissions.  So I'd guess it is only a real-time
>network of receivers, working in /very/ close coordination, to detect and
>deal with the attack. (it's not difficult to imagine scattered
>retransmissions, over time, to hide the coordination.  Sort of a spread
>spectrum transmission style...)
>
>
For (1), I presume the outbound site did not make a quality assessment that
identified the message as "likely to be replayed".  Does this reduce to the
"don't sign spam" argument?

 -MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Replay attack definition discussion

[Murray S. Kucherawy]

On Thu, Aug 17, 2023 at 3:30 AM Alessandro Vesely  wrote:

> > I'm not convinced advice is necessary here.  Do you really need signs in
> > banks that say "Don't put your signature on random financial
> documents"?  I
> > have to believe that people understand what it means to sign something,
> and
> > why they shouldn't do that.
>
> Well, when banks don't do that, they're in bad faith.  Consider, for
> example,
> derivative financial contracts conceived so that nobody is able to read
> them
> —banks don't even try to print them.  Decadent practices.
>

I don't know what you mean by "decadent", here or below.

I disagree about the "bad faith" claim.  I think everyone with their own
agency understands what it means to affix their signature to something.
It's on them to understand that fully, or assume the risks of not being
diligent.

In the case of high volume operations like scanning email, the scale forces
you to play the odds that your inbound filtering gets it right a high
enough percentage of the time that you're able to cope somehow with the
things that slip through.


> Domains cannot "read" the messages they sign.  Some MPs may have wonderful
> anti-spam filters, but that's still not the same as reading and signing an
> agreement.  We need to dismantle the agreement metaphor a bit.
>

The logical extension of this line of thinking is that message
authentication isn't meaningful.  Is that where you're going with this?


> On the other hand, there are domains which blindly sign anything their
> users
> write, enacting only minimal limits to prevent abuse in case of
> compromised
> credentials.  They can afford doing so because, for example, users are
> employees and are known in person.  Do such domains experience replay
> attacks?
>

Likely.  So?


> What I'm trying to address is the relationship between users and mailbox
> providers.  Free MPs want anyone to be able to create a free account, and
> that
> was at the root of their success.  When domain authentication arrived,
> they
> considered that /all/ messages from their domain must be authenticated.
> DMARC
> reporting is specifically aimed at such goal.
>

For something that signs at a domain level, why is this something with
which we should concern ourselves?


> The arms race you refer is the result of indiscriminately accepting all
> users.
> A small percentage of them are bad actors, but cannot be identified
> because, in
> general, the real IDs of users is not ascertained.  At what point does
> claiming
> responsibility for non-ascertained entities results in decadent practices?
>

Again, I don't know what this means.


> There is no equivalence between authenticating subscribers and scanning
> what
> they write.  Both tasks need human intelligence, but the former doesn't
> have to
> be done on each message.  Scanning w/o intelligence is only heuristic and
> relies heavily on volume limits, which is where replay attacks get away
> with it.
>

...and this is entirely an internal matter.  Are you arguing that this
deserves protocol-level consideration?

If you're going to assert that Gmail should authenticate their users before
allowing them to send stuff that will be signed, then I'm pretty sure they
do that already.

-MSK, participating, but currently quite confused
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Replay attack definition discussion

[Murray S. Kucherawy]

On Wed, Aug 16, 2023 at 11:19 AM Dave Crocker  wrote:

> On 8/16/2023 10:48 AM, Murray S. Kucherawy wrote:
> > Yet, an open
> > signer is for DKIM the equivalent of what an open relay is for SPF.
>

> It is nothing of the sort.
>
> [...]
>

For the record, the attribution here is wrong.  That was Alessandro's
comment, not mine.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Replay attack definition discussion

[Murray S. Kucherawy]

On Wed, Aug 16, 2023 at 10:25 AM Alessandro Vesely  wrote:

> On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote:
> >> On 16 Aug 2023, at 12:59, Alessandro Vesely  wrote:
> >> On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:
>  On 16 Aug 2023, at 09:57, Alessandro Vesely  wrote:
>  How about enacting common sense rules such as Never sign anything
> without reading the small print?  In the same way that users agree to any
> Terms & Conditions without reading, domains sign any mail their users send
> without knowing.  Decadent practices, aren't they?
> >>> Can you expand on this? I’m not sure I understand how reading the
> content will fix the problem. Spam is an issue of volume mostly.
> >>
> >> Avoiding to /sign without knowing/ could perhaps partially solve the
> problem. Reading the content was just for comparison with signing
> agreements.
> >
> > Without knowing what, though? I am just not understanding what
>
> Sorry, I meant without knowing who is the author.
>
> According to RFC 6373, "DKIM separates the question of the identity of the
> Signer of the message from the purported author of the message."  Yet, an
> open
> signer is for DKIM the equivalent of what an open relay is for SPF.
>

I'm not convinced advice is necessary here.  Do you really need signs in
banks that say "Don't put your signature on random financial documents"?  I
have to believe that people understand what it means to sign something, and
why they shouldn't do that.

We're already saying that a valid DKIM signature means the signer takes
"some" responsibility for the message.  Saying "Don't sign random things"
seems redundant to me; it presumes the first sentence is somehow deficient
or hard to understand.  Is that what you're claiming?

If this reduces to "Don't sign spam," then I don't think we need to say
that.  Wei or Emmanual can confirm to be sure, but I'm pretty certain
Google doesn't sign absolutely anything, in the sense that if you connect
to them, authenticate, and then start spraying spam, it's going to get
detected and disallowed somehow.

The problem occurs when someone finds a way through the spam filters.  I
worked for a spam filtering company for a few years, but it doesn't take
such direct experience to realize that it's an arms race: Attackers are
trying to figure out what won't get caught and then exploiting that until
the service provider catches up; rinse, repeat.  That gap will always come
and go, and to assert that the gap should never ever be there and the
service provider should be ashamed of itself if it ever occurs seems
unrealistic to me.

To repeat my questions, then, would limiting (qualified) DKIM signatures to
> verified accounts diminish replay attacks by any amount?  Is this kind of
> solution acceptable?
>

Sure, you should only sign things if you have reason to believe the source
and the content are such that you're willing to attach your good name to
it.  Whether that's authentication of the submitter or scanning of the
content, or both, or other checks, is entirely up to you.  But by saying
"you take some responsibility" for messages, I think we're already saying
that and don't need to repeat ourselves.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Sun, Aug 13, 2023 at 8:34 PM Jesse Thompson  wrote:

> If I understand based on my limited view of history, DKIM was designed for
> authentication between two hops. Signature survival across intermediaries
> was only achievable by encouraging intermediaries to not make any changes
> to the message "inside the envelope" such as standards-allowed MIME
> re-encoding (which, notably, prevents intermediaries from improving MIME
> interoperability)
>

That's not how I recall it.  DKIM was designed to attach, with
cryptographic protection, the domain name of a handling agent to the
message.  There's no expectation that the agent doing so asserts anything
about the content of the message (i.e., "this is not spam"), nor is there
any expectation that the domain signing it is the domain originating it.
There's no constraint about which agent (receiver or intermediary) attempts
to validate it.  Also, there are numerous things that can happen to a
message en route that could invalidate a signature.  Accordingly, the only
thing you know when you see a message whose signature validates is that it
has not been modified since the signer signed it.  The absence of a valid
signature (or even of an invalid one) isn't indicative of anything.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Sat, Aug 12, 2023 at 12:31 PM Steffen Nurpmeso 
wrote:

>  |> The aspect of DKIM-subsignatures revealing Bcc: presence (of 1+
>  |> recipients of a domain) if a Bcc: recipient replies to a message
>  |> that Murray Kucherawy adduced i obviously have not fully addressed
>  |> with my response.
>  |
>  |If I reply to a message that contains no Bcc header I am revealing \
>  |the fact that I received the message. I don't understand this issue. \
>
> So it is.  If you are the member of the blind carbon copy list,
> noone will know you have received the message until you reveal
> this yourself by replying to it.
>
> It is just that *if* per-recipient-host DKIM subsignatures would
> be used those subsignatures *could* be a vivid part of the
> message.  And despite all the trace fields which do exist they
> would add onto "that privacy issue".
>
> [...]
>

If I'm able to follow your "subsignatures" idea, this is a different
approach to what is ultimately the same method proposed in my draft(s)*,
namely binding the signature to the envelope recipient list.  It has the
same limitations, such as inability to tolerate any sort of envelope
rewriting, which includes simple aliasing/forwarding, and splitting of the
envelope if it had more than one recipient.

It seems to me that the notion of a subsignature per receiving domain
doesn't scale well to a single message that goes to hundreds or thousands
of domains, and a subsignature per recipient doesn't scale well to a single
message that goes to hundreds or thousands of recipients irrespective of
their domains.  In either case, it won't be long before we run into MTA
limitationsThe optimal case is generation of a single message, and
corresponding signatures, per recipient, but that means we fail to take
advantage of the "common factoring" feature of SMTP, with unknown aggregate
costs.  It's been argued that most email these days is single-recipient
anyway, so maybe some of this isn't a big deal, but we should collect some
data about that before proceeding with that as a general assumption.

You could sign a message such that it binds the message to a particular
sender domain and receiver domain, but in a target-rich environment like
Gmail or Yahoo, all I need is one such pair and I can replay to a pretty
huge number of users.

Lastly, I suggest that we've wandered pretty far afield from talking about
the problem statement document.

-MSK, participating

[*] I discovered that it seems we went through this exercise once before
about seven years ago, and the same idea came up then as now:
https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-rcpts-01
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso  wrote:

> And couldn't it become standardized that verification results then
> must be included in future DKIM signatures?
> So then a verifier inserts a RFC 7001 header, and that will be
> covered by a further DKIM signature.
>

Aren't you basically describing ARC here?


> And when a mailing-list or so changes fields, it could create
> a "DKIM-Backup: h1=b1, h2=b2, .." where b1 could be base64 encoded
> (gzip compressed), so that the original values could be restored.
> It should be straightforward and easy to handle this for the few
> headers like Subject:,From:,Sender: and not much more to come
> which are normally the culprit of problems.  And that to be
> included in a further DKIM signature.
> A DKIM verifier can then restore the original content and verify
> it accordingly.
>
> This all not today, but the road is not that long and winding.
>

Even if you could revert header field values to their signature-time
content, it's what's there now that gets shown to the user.  So if I have a
DKIM-Backup field that lets the original DKIM-Signature validate, but the
new Subject has a spam URL in it, then I'm using that signer's domain to
show you content they didn't intend.

It's the same problem, isn't it?

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Wed, Aug 9, 2023 at 9:07 AM Steffen Nurpmeso  wrote:

> All these problems are long known to (and "solved" by) the OpenPGP
> (and S/MIME) communities, no?
> In OpenPGP you can either encrypt-to a single or many recipients.
> (With at least GnuPG you can also "hide" those recipients:
>
>‐‐hidden‐recipient name
>‐R Encrypt  for  user  ID  name, but hide the key ID of this
> user’s
>   key. This option helps to hide the receiver of the  message
> and
>   is  a  limited  countermeasure against traffic analysis. If
> this
>   option or ‐‐recipient is not specified, GnuPG asks for the
> user
>   ID unless ‐‐default‐recipient is given.
>
> ).  (Also GnuPG just recently introduced a "company-super-key" like
> thing, as it seems many work groups etc. need to encrypt to each
> member, and then the communication must be archived, with the
> possibility to decrypt years later.  But, eh, only for
> completeness.)
>

There aren't per-user DKIM keys.  I mean, there could be, but that's not
how it's designed or maintained.

So the best you could do is per-recipient-domain signatures, but I don't
think that solves much: If I launch a replay attack from gmail.com at
yahoo.com, or even simply back at gmail.com, I can still hit a large number
of recipients without needing an array of signatures or revealing that
replay is occurring.

Isn't this discussion about Bcc: off-topic and solely RFC 5322?
> I have never seen a MUA implementation which does anything else
> but "throwing recipients into" To:/Cc:/Bcc:.  And then there is
> "undisclosed-recipients", where anything is consciously not part
> of IMF/5322, but only in SMTP/5321, but still per-recipient DKIM
> should work out, then.
>

"Bcc" came up in the context of supporting DARA as a solution to the replay
problem, I believe.


> It seems to me that adding a per-recipient DKIM "sub-signature"
> can be accomplished very cheaply, and "scales to
> super-parallelism".
>

If by that you mean a distinct signing key per user, I don't think this
scales.  That's not because DKIM can't handle it, but because I don't think
large operators like Gmail or Yahoo want to maintain millions of public
keys in their DNS.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Wed, Aug 9, 2023 at 2:54 AM Laura Atkins  wrote:

> If there are multiple BCCs that implies that whatever is creating the mail
> must make individual copies of the message with only the BCC recipient in
> that line before it’s signed with DKIM. So for a message with 3 BCCs, there
> are 4 separate copies of the message to be created, one with no BCC header
> and 3 for each of the BCC recipients. Then each message must be
> individually signed.
>
> I’m not sure how that’s going to work in practice.
>

I have heard, but have not verified, that some MLMs do this
one-recipient-per-copy thing already, despite RFC 5321 encouraging the
opposite.  If true, I don't know whether this was done to allow
per-instance signing or because it allows for better tracking and
association of bounces, or for some other reason.  It occurs to me that
unless the Date field changes for each instance, the DKIM signature would
be the same for each instance anyway.

However, if it is already the case that MLMs generally produce a copy per
recipient, then any Bcc scheme would work, and much of the fragility with
the "include the recipient in the signature" approach vanishes.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Wed, Aug 9, 2023 at 2:54 AM Laura Atkins  wrote:

> It seems to me there is a lot of heavy lifting to be done to make sure
> that the individual recipient only sees a copy of the message with their
> address in the BCC header.
>
> If there are multiple BCCs that implies that whatever is creating the mail
> must make individual copies of the message with only the BCC recipient in
> that line before it’s signed with DKIM. So for a message with 3 BCCs, there
> are 4 separate copies of the message to be created, one with no BCC header
> and 3 for each of the BCC recipients. Then each message must be
> individually signed.
>
> I’m not sure how that’s going to work in practice.
>

+1.  It also flies in the face of advice in RFC 5321 to curtail duplication
of message instances.

Of the three Bcc schemes described in RFC 5322, this one is the most
expensive and complicated.  I surmise that they were describing legacy
behavior rather than encouraging a particular approach.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Tue, Aug 8, 2023 at 8:21 PM Jesse Thompson  wrote:

>
> As you cited, RFC 5322 describes three ways that the "Bcc" field is
> typically used.  You're talking about just one of those, and I'm not sure
> it's the most common one.  In any case, I suggest that "should" is a bit of
> a leap, especially given that the choice of which of the three to use is
> described as "implementation dependent".
>
> The second part of your citation confirms the risk to which I was
> referring.
>
>
> I don't understand why it's a privacy issue that an individual recipient
> sees their own address in the Bcc header.
>

It isn't.  But that's not what DARA is proposing, and that's what I was
replying to.

And "Bcc" can have many values under the first of the three models in RFC
5322.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Murray S. Kucherawy]

On Tue, Aug 8, 2023 at 9:25 AM Alessandro Vesely  wrote:

> On Tue 08/Aug/2023 14:47:37 +0000 Murray S. Kucherawy wrote:
> > On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman 
> wrote:
> >
> >> That's true of all indirect mail flows.  It's not a distinguishing
> feature
> >> of the attack.
> >
> > Quite right, making this harder to pin down.
> >
> > But, to Alessandro's point, I do think the description in the document is
> > accurate.
>
> Agreed, except for narrating an actual case.  However widespread, there
> are
> people like me who never recognized a replay attack.
>

What do you mean by "narrating an actual case"?  Section 1.1 does contain a
narrative of how one executes the attack.

Are you talking about a narration of how one detects the attack, as
distinct from a typical indirect mail flow?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Murray S. Kucherawy]

On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman 
wrote:

> That's true of all indirect mail flows.  It's not a distinguishing feature
> of the attack.
>

Quite right, making this harder to pin down.

But, to Alessandro's point, I do think the description in the document is
accurate.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Murray S. Kucherawy]

On Tue, Aug 8, 2023 at 2:16 AM Alessandro Vesely  wrote:

> On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote:
> > On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote:
> >>
> >> I think the document does describe the attack.  An instance of the
> attack
> >> is when a replayed message lands someplace it wasn't originally
> intended to
> >> land, assuming normal usage.
>
> That's ambiguous.  Obviously, since the attack was planned, it may well be
> that the potential victims were originally intended.  The meaning is
> tweaked by the "normal usage" assumption, which could be interpreted as
> trying to pretend that the message author wasn't aware that the message
> was
> going to be replayed...?
>

I don't understand what ambiguity you're talking about.

The document lays out how the attack is accomplished.  It also indicates
that the only difference between typical DKIM operation (the original
recipient set is the only recipient set) and the attack (the final
recipient set is not the same).


> >> But my point above is simpler: "Replay Attack", when capitalized that
> way,
> >> has me going to look for a formal definition of that term someplace.
> That
> >> is, if we're going to use it that way, we should define it that way.
> So,
> >> just add it to the Glossary at least, or say in Section 1.1 that this
> term,
> >> in this document, means the attack described by that section.  Or
> something.
>
>
> Would it be enough to say "Replay Attacks are described in Section 8.6 of
> DKIM", somewhere in Section 1.1 of the I-D?
>

Sure.


> > It will be interesting to see what develops.  It's not a mystery that I'm
> > skeptical of a protocol solution to the issue.
>
> The definition cannot include a method to recognize the attack.  The I-D
> implies that attacks are being recognized (became commonplace), but omits
> the anecdotical narration of how it happens.
>

Including a sentence or two about how the attack is recognized, even
outside of the protocol, would indeed be helpful.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 9:23 PM Jesse Thompson  wrote:

> On Mon, Aug 7, 2023, at 10:54 PM, Murray S. Kucherawy wrote:
>
> On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch  40google@dmarc.ietf.org> wrote:
>
> If there are not that many BCC recipients for a message then it is likely
> not necessary as the duplicate message counting is unlikely to have a
> negative impact. If there are a large number of BCC recipients for a given
> message then I think the solutions proposed in Wei's DARA draft are
> helpful: standardizing the way to indicate BCC/Forwarded-To and signing a
> separate copy of the message for each BCC recipient so that it can still be
> verified as direct mail.
>
>
> Doesn't putting "invisible" recipients into an actual field like Bcc
> create a privacy concern, i.e., they're no longer invisible?  You need to
> hope that the agents in the handling chain that are supposed to delete that
> field will actually do it, which presumes the entire deployed base will
> adopt DARA in a reasonable period of time.
>
>
> According to RFC 5322 it should be handled correctly by "but the
> recipients on the "Bcc:" line get a separate copy of the message containing
> a "Bcc:" line"
>
> [...]
>

As you cited, RFC 5322 describes three ways that the "Bcc" field is
typically used.  You're talking about just one of those, and I'm not sure
it's the most common one.  In any case, I suggest that "should" is a bit of
a leap, especially given that the choice of which of the three to use is
described as "implementation dependent".

The second part of your citation confirms the risk to which I was referring.

-MSK, participant
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch  wrote:

> If there are not that many BCC recipients for a message then it is likely
> not necessary as the duplicate message counting is unlikely to have a
> negative impact. If there are a large number of BCC recipients for a given
> message then I think the solutions proposed in Wei's DARA draft are
> helpful: standardizing the way to indicate BCC/Forwarded-To and signing a
> separate copy of the message for each BCC recipient so that it can still be
> verified as direct mail.
>

Doesn't putting "invisible" recipients into an actual field like Bcc create
a privacy concern, i.e., they're no longer invisible?  You need to hope
that the agents in the handling chain that are supposed to delete that
field will actually do it, which presumes the entire deployed base will
adopt DARA in a reasonable period of time.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 7:43 PM Jesse Thompson  wrote:

> Similar to what Emmanuel is saying about detecting SPF/DKIM zone
> misalignment, the solution to DKIM replay is for receivers to maintain some
> state and feed it into bespoke replay detection algorithms. If all
> receivers can maintain this kind of state, then there's nothing senders
> need to do, I suppose? Given that *normally* all of the messages we emit
> have unique message-ids, receivers can just limit the amount of duplicative
> message-ids they accept from us. Assuming they know the situations in which
> message-ids would not be unique. That's another thing that maybe needs to
> be communicated somehow as "this is normal in this situation".
>

Isn't this a derivative of the "Count DKIM signatures" approach identified
in the current problem statement document?  If so, do you have any comments
on the points against such an approach?

Since you specifically mention Message-IDs, does anyone have data on how
often that header field is included in signatures?  If it's not, then
rotating Message-IDs at random defeats such an approach and drives up the
receiver's operational cost to boot.

-MSK, the usual
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman 
wrote:

> On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
> ...
> > (2) Throughout the document, the proper term "Replay Attack" (and
> sometimes
> > "Replay") is used, but it's never directly defined.  I don't think you
> need
> > it to be formal, but if you really want to do it that way, please add a
> > definition for it.
> ...
>
> I think a definition that describes a condition that's technically
> distinguishable from normal DKIM operations is essential if we are going
> to
> make any progress.  "I know it when I see it" may work for the US Supreme
> Court, but it's not adequate here.
>

I think the document does describe the attack.  An instance of the attack
is when a replayed message lands someplace it wasn't originally intended to
land, assuming normal usage.

The document also describes that the payload itself in normal usage is
indistinguishable from an instance of the attack; the obvious implication
is that there's no solution based solely on the payload format.

Your point that we possibly can't go much further than that is one for the
WG to deliberate, to be sure.  And I suggest that that's one possible
outcome of this WG.

But my point above is simpler: "Replay Attack", when capitalized that way,
has me going to look for a formal definition of that term someplace.  That
is, if we're going to use it that way, we should define it that way.  So,
just add it to the Glossary at least, or say in Section 1.1 that this term,
in this document, means the attack described by that section.  Or something.

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Murray S. Kucherawy]

Hi,

Some comments after a review of the adopted document:

(1) I find the abstract is more readable if broken into three paragraphs,
with the second starting "DKIM survives ..." and the third "This document
discusses ...".

(2) Throughout the document, the proper term "Replay Attack" (and sometimes
"Replay") is used, but it's never directly defined.  I don't think you need
it to be formal, but if you really want to do it that way, please add a
definition for it.

(3) The first sentence/paragraph of Section 1 isn't necessary.

(4) The last paragraph of Section 1 refers to the "DKIM domain" but I don't
think this is defined anywhere.  It's also not clear that if the signature
doesn't validate, there is no output from DKIM in terms of an authenticated
identifier.  Maybe "DKIM-authenticated domain"?

(5) In Section 1.1, "The presence of a validated DKIM signature" begins two
sentences.  I suggest some wordsmithing here.

(6) In Section 1.1, the sentence ending "particularly for systems" reads
funny.  I suggest: "However, that attack has become commonplace, and
typically manifests itself as follows:"

(7) In Section 1.1, for the first bullet, suggest:

"Attackers create, obtain access, or compromise an account at some
Originator that signs messages with DKIM, preferably one that has developed
a positive reputation;"

(8) Second bullet:

"Attackers locate a Receiver that consumes DKIM to make a delivery
decision."

(9) Third bullet:

"Attackers send an email from that account to an external account also
under their control."

(10) Fifth bullet:

"Attackers then post the message to a new and large set of additional
recipients at the Receiver."

(11) s/in the content/in the visible/

(12) De-bullet the "Further, a message used ..." paragraph.

(13) Define the term "re-posting flows", or give an example.

(14) Add "experimental" to the ARC reference.

(15) In Section 1.2, strike the "NOTE".  This is an Informational document
so this isn't necessary (and this way you can drop the BCP 14 reference).

(16) Also in Section 1.2, importing definitions from RFC 5598 verbatim is
not necessary and risks editorial drift; simply making the reference and
advising the reader to be familiar with it is sufficient.

(17) Also in Section 1.2 at the end, two things: (a) Mentioning that DKIM
is an authentication protocol used by the above described actors is, IMHO,
redundant; and (b) on review of the document as a whole, I don't think
mentioning SPF adds anything, so I suggest we consider removing it.

(18) In Section 2.2, we refer to "author".  If this should be "Author" as
defined in RFC 5598, be sure to capitalize it.  If we mean something else,
what?

(19) Also in Section 2.2 it talks about sending a different message.
Different how?

(20) Section 2.3 talks about an alias replacing the envelope sender.  Is
this true?  I don't think, for instance, that sendmail replaces the
envelope sender when it routes a message through an alias.

(21) In Section 3.1, the first paragraph is effectively a restatement of
Section 1.1.  Can we drop it?

(22) Also in Section 3.1, I suggest not mentioning "spam folder" as that's
one of any number of possible handling choices.  Maybe just talk about
"misclassification"?

(23) Also in Section 3.1, the last sentence seems to be redundant; I
suggest removing it.

(24) Sections 3.2 and 3.3 are too short to be their own sections, and end
the same way.  I suggest common factoring.

(25) Section 4 says things like "SMTP Envelope RCPT-TO", but we already
have a notation for this (RFC5321.RcptTo), which other specifications
related to DKIM use.  I suggest using those.

(26) In Section 5.1, s/original sending/original message/

(27) Section 5.1, first bullet:

"This prevents a valid signature from being replayed to destination
addresses not anticipated by the DKIM signer"

(28) Second bullet: s/ENVELOPE-TO/envelope recipients/, or use the notation
mentioned above.

(29) Section 5.2, "known DKIM signatures" needs a better definition; known
how?  Are we talking about the whole header field, or just the "b" value?

(30) Section 5.4, I remember mentioning at M3AAWG that RFC 6376 recommends
against using "x=" for replay mitigation. I also think there's been
evidence presented (I forget where) that enforcement of "x=" is not
universal, so it's not a reliable mitigation.  We should mention these.

(31) In Section 5.5, s/spec/protocol/ (two instances)

(32) Suggest replacing Section 6 with:

"Readers interested in this problem space should already be familiar with
the Security Considerations described in [RFC6376].  The problem described
in this document amounts to a privilege escalation attack against email
content filters.  Mitigation or solution documents may follow."

-MSK, just participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Murray S. Kucherawy]

On Fri, Aug 4, 2023 at 2:46 PM Michael Thomas  wrote:

> Well, for starters ARC doesn't have broad deployment. But the author
> doesn't say why ARC is needed or relevant. That is the point here. *All*
> changes need to be justified including any imported mechanisms. The less
> rat holes the better. Same with the mailing list modification draft. Why is
> that even relevant?
>

With respect to ARC: There's a difference between asking for justification
and demanding that the discussion be stopped before it even starts.  One of
those is not okay.

With respect to the MLM draft: Since this is the only IETF list that covers
DKIM specifically, that makes it a reasonable venue for raising
DKIM-related ideas that might exceed the charter.  I would agree that this
WG shouldn't take up any DKIM topics not related to the replay problem, but
I don't see an issue with announcing in this venue that you have an idea
and invite discussion off-list or in some other venue for as long as this
list is allocated to an active working group.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Murray S. Kucherawy]

Colleagues,

On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas  wrote:

> Exactly. Any proposed modifications to DKIM should be based on DKIM
> itself. Anything else is off-topic. It's not like you can't propose the
> ARC modifications to DKIM in terms of DKIM itself, though all of those
> modifications have nothing to do with the current charter.
>

Two things:

1) Please endeavor to lower the temperature on this thread.

2) If the chairs have decided, or decide in the future, that ARC has been
discussed and consensus is to consider that topic closed, that's their
purview.  However, such a decision cannot be derived directly from the
charter text I'm looking at.  In particular, this text:

"The DKIM working group will first develop and publish a clear problem
statement.
Then, it will produce one or more technical specifications that propose
replay-resistant mechanisms. The working group will prefer solutions
compatible
with DKIM's broad deployment, and there will be an expectation that these
solutions
will have been through implementation and interoperability testing before
publication."

...does not, to me, constrain the solution space to DKIM itself.  If
there's a solution to DKIM replay outside of DKIM itself, then it's fair
game.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Thu, Aug 3, 2023 at 10:01 AM Suresh Ramasubramanian 
wrote:

> Would this effort be better targeted at the various open source as well as
> proprietary implementations of DKIM libraries, to flag if not eliminate the
> various edge cases that are being gamed by the spammers?
>
>
>
> Rolling out software with a sane set of configuration defaults would
> typically mean that they’d be baked into production implementations, that’d
> put considerable thought into overriding any such default setting
>

What sort of changes do you have in mind?

-MSK, participating
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Murray S. Kucherawy]

On Tue, Aug 1, 2023 at 8:29 AM Laura Atkins  wrote:

> We have a current version of the draft problem statement available on the
> data tracker. Murray and a few others made a few comments that were added
> in the -03 version.
>
>
> https://mailarchive.ietf.org/arch/msg/ietf-dkim/Q5ybHiYkMlg5QFaFp28Y8uSme1Q/
>
> Based on discussions, there seems to be favor to documenting what has been
> tried and not worked.
>
> Question for the working group: Should the discussion of what hasn’t
> worked be in the problem statement as an Appendix? Or should it be in a
> separate document as working group output?
>
> Along the same lines, do members of the working group feel we should
> include some of the solution space in the problem statement? Or should the
> discussion  be reworked?
>
> Perhaps instead of "possible solution space" maybe "scenarios and how they
> affect dkim replay" ? We welcome any suggestions of wording changes.
>

I just did an informal poll of the IESG members that happened to be active
in the IESG slack channel at the time I asked.

There's a previous IESG statement on this topic that's relevant:
https://www.ietf.org/about/groups/iesg/statements/support-documents/

Generally, this informal poll suggests the IESG disfavors a document that
is nothing more than a problem statement.  This aligns, unsurprisingly,
with the IESG statement.  Such documents, by themselves, have uncertain
archival value.  So if we want to publish a problem statement, with or
without a "what we've tried" appendix, we should consider merging the
proposed solution(s) into such a document before advancing it to the IESG.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Murray S. Kucherawy]

On Tue, May 16, 2023 at 7:00 AM Jan Dušátko  wrote:

> 1) At this moment, the use of the tag "v=DKIM1;" is only RECOMMENDED and
> if this tag is used, it must be the first. Unlike, for example, SPF and
> DMARC, this is not a REQUIRED (MANDATORY) record. In case of an attempt
> to identify DKIM records, then there is a situation where it is not
> possible to determine which records are DKIM keys. Often, these keys are
> in other places where they allow to create CNAME to the expected
> location of the selector. These locations may be application dependent
> or may be with third parties configuration. From my perspective,
> MANDATORY record "v=DKIM1;" could help to identify DKIM keys much easily.
>

I don't get the impression that identifying a record that contains a valid
DKIM key record is hard.  The ABNF is pretty clear.  It's certainly easier
to say "does this start v=DKIM1;?" than it is to run a full parser on it,
but I imagine if you try to stuff a random string through a DKIM key
parser, it'll know pretty quickly most of the time that the record isn't
valid given the second character pretty much has to be "=" which is going
to trim a lot of cruft right away.

Also, a change to make this REQUIRED would take forever for the world to
adapt.  There's a great deal of inertia out there, and the benefit of such
a change isn't going to be obvious to the broader community, so you're
going to find records in the current format for years to come, and
implementations would justifiably accept the old format for some long
transition period.

Are you talking about DKIM records out in the general Internet, or only
within domains you control?


> 2) Is it possible to specify precisely under which conditions the DKIM
> key is valid? Some third party records contain only an empty record "",
> others contain only revoked key like "p=" or it is a reference to a
> non-existent record. Unfortunately, RFCs do not provide unambiguous
> information on under which conditions this record is invalid. From my
> perspective, use of non-existing records or empty strings can draw that
> key useless, but rules specifying that in RFC or BCP will be welcome.
>

I disagree that this is ambiguous.  An empty string isn't a valid DKIM key
record.  An empty "p=" value is a valid DKIM key record indicating "there
was a key here, but it's been revoked".


> 3) The "p=key" information containing the key material information
> encoded by Base64 should occur in the key exactly once. I did not find a
> condition in RFC for the existence of this record. I found only
> information on implementation behavior, when "p=", i.e. an empty key
> material, is considered revoked. However, it is not unambiguous whether
> this approach is acceptable. Also specification of that rules can make
> my life much easier.
>

I also disagree that this is ambiguous.  The RFC is pretty clear about what
an empty "p=" means.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Moving forward - from the chairs

[Murray S. Kucherawy]

On Mon, Apr 10, 2023 at 11:24 AM Scott Kitterman 
wrote:

> On Monday, April 10, 2023 2:05:28 PM EDT Laura Atkins wrote:
> ...
> > There is currently an active Call for Adoption for a draft.
> ...
>
> What's the plan for closing this out?  I haven't seen any objections to
> the
> idea and as of tomorrow it will have been over a week since the formal
> call
> for adoption.  This happens rarely enough in my experience that I don't
> recall
> how long these normally run.
>

Usually a week or two.  The original post wasn't specific, so at this point
I think the chairs could call consensus at their discretion unless someone
wants to argue it should stay open longer.

The datatracker normally asks what the CFA duration is, but in the
"History" tab for this document it doesn't look like one was recorded.
Might be something for the tools team to look at.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Cooling things off

[Murray S. Kucherawy]

Colleagues,

Things have gotten somewhat heated in here.  I think we need to take a step
back.

While I have no doubts whatsoever that the participants and chairs are
well-intentioned and would like to see this working group make progress in
an appropriate direction, even if we may not all agree yet on what that
direction is, it is critical to follow process and, more importantly, to
behave in a respectful and professional manner.

The IETF's Code of Conduct can be found in BCP 54 (RFC 7154).  If you have
not read it, please take the time to do so.  As with the IPR rules of the
IETF, everyone on this list is expected to observe those guidelines, and
consistently straying from them makes you eligible for corrective handling
under BCP 25.

To be clear, I have no concerns with questions about proper procedure.
Questions are welcome.  I need reminders of proper process from time to
time.  Also, a procedural error does not constitute evidence of malice.
Any public challenges to authority or procedural decisions must be
delivered respectfully and professionally.  If you can't, or won't, then do
it privately.

Laura is a new chair and is still learning our processes.  I would like to
thank her for taking on this work in any working group, especially this
one.  Development of new talent in the IETF is to be supported, and I
intend to do so.  Tim and I are providing support, but this week has been
challenging as we're spread very thin during IETF 116.  This has been
baptism by fire for her.  I would appreciate it if people provided her with
guidance when we aren't able to do so.  I want to make clear that openly
assaulting her integrity as she undergoes this onboarding will not be
tolerated.

As any of us, the chairs are allowed missteps, especially while learning,
so I would like to help here by correcting two of them.  Also, as
mentioned, we need to cool off.  Thus, effective immediately:

(1) The action under BCP 25 (RFC 3934) regarding Michael Thomas is reversed
by one step; the "communicating privately" step has been completed, but the
public warning is struck.

(2) The chairs should initiate a Call For Adoption of a reasonable period
on one of the problem statement drafts.  The working group is reminded that
adopting a draft does not endorse its content as final or even close to
final; it's merely a starting point for discussion and iteration.  The
chairs may select one of the candidate documents at their discretion.

(3) The working group's list is to be set for moderation until next week to
provide a cooling off period.  Working group business may still be
conducted, but the chairs will review posts to ensure they are moving the
WG's purposes forward, and comply with BCP 54, before approving them.
Anything else will be rejected.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Murray S. Kucherawy]

On Tue, Mar 28, 2023 at 1:05 AM Michael Thomas  wrote:

> Lastly: cutting off debate because of time is bogus. Murray already said
> that the milestone dates were fairly arbitrary. Using them as a tool to
> get the chair's preferred result is... disingenuous.
>

The milestones are negotiable, but if the chairs would prefer not to do so
and instead choose to try to push the WG to meet the current target, that
is their prerogative.

I echo Barry's question.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Murray S. Kucherawy]

On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas  wrote:

> On 3/24/23 6:19 PM, Barry Leiba wrote:
> > I don't agree with the premise.  I think what was tried and didn't
> > work should be documented in the result that the working group comes
> > out with, but not in the problem statement.
>
> There isn't a place in the charter/milestones for that.


The charter identifies these possible outputs in some combination:

(1) a clear problem statement;

(2) one or more protocol update document(s);

(3) a statement of some kind that the WG determined no feasible protocol
solution exists (and, one would hope, how it reached this conclusion);

(4) an update to current DKIM operational advice with respect to the stated
problem.

The only constraint in the charter is that (2) and (3) are mutually
exclusive.

I believe that a history of what techniques were previously tried and
failed could arguably go into any of them.  The charter is neither
prescriptive or proscriptive on this point.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Clarifying the problem

[Murray S. Kucherawy]

On Fri, Mar 24, 2023, 10:10 Michael Thomas  wrote:

> On 3/24/23 9:58 AM, Laura Atkins wrote:
>
>
> On 24 Mar 2023, at 16:48, Michael Thomas  
> wrote:
>
>
> On 3/24/23 6:14 AM, Laura Atkins wrote:
>
> Please, let’s focus on the current issue with is addressing  and refining
> the problem statement.
>
>
> So you agree with me that any discussion of ARC and its complete failings
> should be out of scope? I would appreciate the chairs enforcing that.
>
>
> I said we should be focusing on addressing and refining the problem
> statement.
>
> Maybe you should have a conversation with your AD who brought up ARC in
> one of the threads here.
>
Just to be clear:

A participant (me) made a suggestion.  The AD (as it happens, also me)
didn't say anything that should be taken as proscriptive.

The content of this and any WG document has to represent the consensus of
the WG participants.  If consensus is to keep ARC in the document, then
that's what goes forward.

I have a long history of participation in this area, and I am not barred
from continuing to do so just because of the role to which I have been
appointed.  I obviously have to be careful about conflict of interest or
undue influence, but I'm working with the chairs and the IESG to keep that
all clean and above board.  If it means I find a different AD to support
this WG to avoid confusion, then that's what we'll do.

So unless I say something clearly indicating that I'm talking as an AD,
please assume that I'm just talking as a participant.

-MSK

>
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Murray S. Kucherawy]

On Fri, Mar 24, 2023 at 9:59 AM Dave Crocker  wrote:

> On 3/24/2023 9:38 AM, Murray S. Kucherawy wrote:
> > I think I concur with the suggestion that wa should drop discussion of
> > ARC.  This WG, or the DMARC WG, can develop an update to ARC based on
> > the outcome here if the community chooses to do so, but I don't think
> > it should be part of this WG's premise.
>
> sigh.  The draft only makes a quick, careful reference to ARC's having a
> similar vulnerability.  Given it's underlying similarity to DKIM and
> given that this is an introductory document rather than a specification,
> I think it appropriate to give the reader a heads up.  (FWIW, for early
> versions of the draft I was also inclined to want it out.  I think the
> current, brief text is, however, apt.)
>

Fine with me, it's far from a showstopper overall.  I just made the
suggestion.


> > Section 1.2:
> >
> > The opening sentence that emphasizes non-use of RFC 2119, amusingly,
> > forces you to include a reference to RFC 2119.  I suggest instead:
> > "This document is not normative in any way."
>
> As I recall, there was some discussion about this.  For one thing, the
> IETF really likes seeing the reference.  Including it ensures no hiccups
> in the mechanics of handling the document. (And, yes, it is amusing.)
>

I've seen at least the current IESG encourage removal of the reference when
it's not really needed.  It's harmless to leave it in, I suppose, but I'd
be unsurprised to get the question again during IESG Evaluation.


> > Section 6 can simply say there are no security considerations for a
> > problem statement document, though you anticipate some interesting
> > ones in documents to follow.  :-)
>
> Hmmm.  On the other hand, have some discussion of security-related
> issues in a section identified for that topic, might be useful for
> highlighting dangers or concerns.
>

I've always thought of Security Considerations as a place to hold a
discussion about what security issues are being introduced by the material
in the document.  I don't think any are or will be here, which was the
point I was making.  Those would come in any follow-on protocol or best
practices work.

Then again, I don't think anyone's going to complain if we do have an
informative security discussion.  So, as before, just a suggestion.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Murray S. Kucherawy]

Informal comments only here.  I know a merger with Dave's draft is in
progress, so some of these may not apply by the time you're done.

Section 1.1:

It feels a little presumptuous to assume any DKIM receiver has also built
out a reputation system, or has access to one.  I guess it might depend on
what you consider a reputation system though; are there DNSxLs for DKIM
domains that are open to the public?  I don't think SpamAssassin carries
with it a set of domains that should be dropped if they carry valid DKIM
signatures.  Either way, I think the generalization is peculiar.  At a
minimum, say "some systems develop reputations" etc.

I think I concur with the suggestion that wa should drop discussion of
ARC.  This WG, or the DMARC WG, can develop an update to ARC based on the
outcome here if the community chooses to do so, but I don't think it should
be part of this WG's premise.

Section 1.2:

The opening sentence that emphasizes non-use of RFC 2119, amusingly, forces
you to include a reference to RFC 2119.  I suggest instead: "This document
is not normative in any way."

"administratively" should be "administrative functions" or similar.
("users" and "services" are nouns, so this should be too.)S

The "List-*" header fields are defined in RFC 4021.

In "trace and operational headers", "headers" should be "header fields".

Are we actually defining new Mail Handling Services here, or rather
declaring special cases of Originators and Relays?  Do they become Authors
again after they've handled/filtered a message?

Are we sure SPF and DMARC should be in scope for this work?  SPF feels
irrelevant, and DMARC feels like a layer violation.  If we want to do so,
we could refer the reader to the RFCs defining those protocols just to make
them aware of the bits of the ecosystem, but then I would leave them out of
the rest of the document.

Section 2:

"headers" should be "header fields"

"customized by" the ultimate recipient?  or should that be "for"?

Involvement of SPF here doesn't seem to be needed either.  We only need to
tall the DKIM story.
I think the notion of folders also exceeds DKIM's scope.  That's a handling
choice post-DKIM.  It's enough to highlight that a false positive is
procured by the attacker, to the attacker's benefit.

Section 3:

Does including SPF in this part of the discussion contribute to the problem
statement or muddy it?  This is about DKIM, not about spam handling in
general.

Section 3.1's "DKIM" bullet talks about signature survival, while Section
3.2's "DKIM" bullet talks about who does the signing.  This seems
dissonant, or at least makes them hard to compare and contrast since they
talk about different things.

Section 4:

Caching known signatures, a con: adds a potentially expensive database
component to the receiving service, and will require tinkering to figure
out what cache duration is appropriate to catch replays while not also
catching legitimate mail.

The "sign for the next hop" proposal could use a language tweak of some
kind.  I can't quite put my finger on it.  If it's "sign for the next hop"
at a host level, I have to know that host; today, I just sign and toss it
in the queue, and my MTA figures out which MX is going to take it, but if I
have to know which MX that is, I can't sign until connection time;
milter-based filters at least don't work that way because the integration
point doesn't allow it.  If it's actually "sign for the next ADMD", that
problem goes away, but the definition of "ADMD" gets a bit muddy because
now you have to include in that definition any MX that might be providing
transparent store-and-forward.

Section 5 you won't need.

Section 6 can simply say there are no security considerations for a problem
statement document, though you anticipate some interesting ones in
documents to follow.  :-)

Lastly, you can drop the "yet" from Section 7.  :-)

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Welcome to the rechartered working group

[Murray S. Kucherawy]

On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch  wrote:

> In my mind, there are two important things I would like to see achieved:
>
> 1) Distinguish indirect from direct flows (encode in some way which server
> / mailingList the original DKIM message was intended to come from). This is
> needed for domains that aren't easily identifiable as direct flows (SPF
> isn't aligned by DKIM in the direct case).
>

Wasn't ARC meant to solve this?  What have the results been?


> 2) Give more info to identify benign indirect flows (E.g. "forwarded on
> behalf of"). This is helpful for recognizing a recipient's desired indirect
> flows.
>

I'm pretty sure this is easily spoofed.  So is any sort of tagging or
header field manipulation mechanism.  The spammer just needs to make its
mail look sufficiently like something you consider legitimate, and they're
in.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Clarifying the problem

[Murray S. Kucherawy]

On Tue, Mar 21, 2023 at 8:37 PM Scott Kitterman 
wrote:

>
> >>1.  Do receivers keep tabs on which users are using things like
> >>mailing lists to differentiate users who expect to get indirect mail
> vs
> >>those who don't?
> >>
> >> The large mailbox operators might have hints about this, but I'm not
> sure
> >the answer would serve to further constrain the problem statement.
>
> I think it relates to the largest challenge to the problem statement: what
> distinguishes these 'bad' messages from 'good' indirect mail flows such as
> mailing lists.  As far as I can tell, the answer is nothing, which leaves
> it challenging to produce an effective protocol change which addresses
> replay that doesn't also have substantial side effects on non-replay
> traffic.
>

I agree, but:

Do you believe knowing the answer to this question would allow us to amend
the problem statement to something that might allow a protocol solution?
My point is that I don't think it would.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Clarifying the problem

[Murray S. Kucherawy]

There was one prior answer to this.  Here's another.

There's a claim here that the problem statement(s) is/are too vague.  I'm a
little worried that tightening up the problem definition along these 20
vectors will give us such a tight problem statement that any solution is so
targeted as to be of limited value.  The sweet spot we're looking for
probably lies somewhere in between.

Gmail's auto-formatting made a mess of the numbers as I went through this,
so sorry if that confuses things.

On Fri, Feb 17, 2023 at 11:11 AM Michael Thomas  wrote:

> I've said in multiple threads that the current problem both in the charter
> and the problem draft are far too vague for us to address. Here are some
> from me at least:
>
>1. Who are the victims? Just bulk senders? Are the bulk senders
>signing using their domain?
>
> In my view, there are two: The receiver of the unwanted spam (that might
not otherwise have been delivered), and the owner of the domain whose
signature got replayed as it might now suffer a degraded reputation.

>
>1. If there are different types of senders who suffer from replay
>attack reputation, are the attacks using the same or different techniques
>to create the signed spam?
>
> I haven't heard much variance in the attack technique.  It's always
something close to this:

* send something that gets signed by a large operator to a single recipient
I control
* capture that signed message, assuming the signature still validates
* replay it all I want from other servers

>
>1. Do senders filter outbound traffic for spam?
>
> I think it's safe to assume that the case we're most interested in does do
this, but it seems to me that irrespective of the answer, the attack is
working.

>
>1. Do spammers who get a piece of email signed by a sender also send
>mail to target domains to see if it passes their filters?
>
> I would guess "yes", though perhaps not specifically as part of a replay
campaign.  That is, they were doing this long before anyone claimed replay
was a rising problem.

>
>1. What are the characteristics of the spammer wrt to the sending
>domain? Are they brand new accounts or established ones?
>
> This one I don't have a guess about.  I would say "either".  Does this
need to be known, or does it need to constrain the problem definition?

>
>1. Do sending domains keep track of users who are sending spam in the
>eyes of their filters? Do they correlate that with other characteristics of
>their users such as freshness?
>
> Also "either".

>
>1. Do senders pay any attention to the To domain?
>
> I can't imagine this being valuable signal, given the additional use of
various other address fields.

>
>1. Do receivers pay attention to the To domain(s)?
>
> Same.

>
>1. Does the To domain spammers use remain more or less static, or do
>they mutate at a high rate?
>
> The "To" field, or the RCPT TO(s) in the envelope?  It seems like the To
field (if signed) never changes, or it's whatever the spammer wants it to
be if it's not signed.  In the latter case, it's easy to make "To" and RCPT
TO match, thwarting that check.

>
>1. Can we quantify the reputation bump (or hit) on the receiver from
>these spam bursts? (I'm sure the spammers know the answer to this)
>
> I imagine this is a property of the spam campaign itself and the response
it draws, and probably varies from one receiver to the next as reputation
is their varying secret sauce.

>
>1. Do spammers with a replay server sign and/or set up SPF records for
>their spam sending domain?
>
> Also "either".

>
>1. Do spammers provide an unsubscribe link which is typical on normal
>email blasts? If not, is that unusual and/or against the rules of the bulk
>provider? If so can the sender keep track of that?
>
> Do we need to know this to define the problem space?

>
>1. Can senders verify that opt-out links actually work especially for
>new accounts?
>
> Same question.

>
>1. Can filters be adjusted at a more fine grain in the face of
>different conditions? That is, accept a higher false positive rate in
>certain conditions?
>
> This seems to me to be part of the answer we might provide rather than
part of the problem definition.

>
>1. Are there receivers out there that treat an x= expired message
>different than a missing or broken signature? It's ambiguous in the DKIM
>text about that, I think.
>
> Right, DKIM doesn't require enforcement or even checking of "x=", other
than if present it must be greater than the "t=" value.  OpenDKIM's library
will consider the signature invalid and tell you this was the reason; the
consumer is free to make whatever handling decision it wants based on
that.  The filter is configurable.

>
>1. Can receivers take advantage of the signalling of a small x= value
>as also a clue that the sender is concerned about replays?
>
> I don't think I've ever seen such guidance documented or 

Re: [Ietf-dkim] Process Questions

[Murray S. Kucherawy]

On Fri, Mar 10, 2023 at 11:19 AM Michael Thomas  wrote:

> On 3/10/23 7:46 AM, Laura Atkins wrote:
>
>
> On 10 Mar 2023, at 00:30, Michael Thomas  
> wrote:
>
> Now that we have a chair, I have a question about process wrt to the
> charter. The charter states that either the working group will produce
> documents addressing the problem, or it will produce a document saying why
> it can't do anything about it within the IETF confines. I strongly suspect
> that that the latter will be the conclusion but I don't know what the
> process would look like to come to that conclusion. It seems like it
> entails a long list of "can't do this"'s etc followed by "we give up". But
> that list could be nearly endless if it is allowed to get out of hand. So
> what does it take to come to that conclusion from a process standpoint?
>
>
> Our current milestones are:
>
> Apr 2023 - Post a consensus problem statement draft to the datatracker (may
>
>  not go to the IESG)
>
>  Jun 2023 - Proposal regarding plans for remaining document(s) presented to
>
>  the AD
>
>  Dec 2023 - Submit technical specifications for replay-resistant DKIM
>
>  enhancement(s) to the IESG at Proposed Standard
>
>
> Per the charter, Or Not. That is what I'm asking about.
>

Between the milestones and the charter text, the charter text is typically
the more important of the two.  Milestones can be edited without full IESG
review, while the charter can't.  So if the working group needs more time
than April or June, that can be negotiated.

Plus, frankly, I made up those dates during chartering.  The chairs and I
haven't discussed whether they're reasonable or whether something else
should be there.  If people want to propose adjustments, I'm all ears.

-MSK, this time with the AD hat on
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM update - header tag

[Murray S. Kucherawy]

On Fri, Mar 10, 2023 at 10:48 AM Jan Dušátko  wrote:

> I got recommendation to propose changes in that mailing group.
> My work depend on appropriate protection of our brand, however this
> tasks require also management of records required for that protection.
> We have huge problem with identification of selector records required by
> DKIM and also this make for us problem with compatibility. We would like
> to strongly follow RFCs, but sometimes v=DKIM1 tag are resolved like
> issue as well as sometime missing of that tag do the same. This is a
> reason, why I would like to propose mitigation of problem, caused by
> word RECOMMENDED in standard RFC 6376:
> [...]
>

Just to clarify: Are you saying the identification of a DKIM record in the
DNS is uncertain unless "v=DKIM1" is present?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Sun, Feb 19, 2023 at 11:49 AM Dave Crocker  wrote:

> This is a very basic point about protocols vs. implementations. A
> protocol defines the 4 walls of its sandbox.  It owns that sandbox and
> defines whatever it needs to, within the confines of that space.
>
> [...]
>
> But again, this is protocol and standards 101.  Seems odd to be
> rehashing something this basic, in a forum like this
>

I didn't see this as a rehashing, just a clarification of the nomenclature
being used.  Reviewing the last few posts in this thread have me thinking
we're all otherwise agreeing.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas  wrote:

>
>
>> Beyond this SHOULD, I think we need to consider whether the caller needs
>> to be told specifically when a failure occurs for this reason.  Right now
>> an implementation might return just a PERMFAIL without noting that it's
>> because of "x=" versus the signature failing for some other reason.  Should
>> the caller be given this extra detail to enhance the decision tree, or will
>> this just complicate things?
>>
>> Why would it permfail? Does it permfail email without a signature too?
>>
>> Absent p=reject, there is nothing wrong with unsigned email.
>>
>
> I'm using the language of the DKIM RFC, so "PERMFAIL" here refers to
> evaluation of the signature, not of the message.
>
> But DKIM doesn't return status to anybody. That's completely internal to
> the verifier. At most they might want to create an A-R, but that isn't
> required and it's definitely not sent back to the sender.
>
I think we're talking about different layers here.  Otherwise, DKIM has to
return status someplace, otherwise why do the evaluation?  That status
might be in the form of an A-R header field, or a recommended final action,
or a log entry, or whatever that operator wants.

The RFC just talks about returning PERFMAIL when the evaluation fails for
one reason or another.  It's abstract, of course; the implementer is free
to decide what that actually means in each case.  In the implementation I
did, the library receives all the details and returns a status (with its
own detail) about each signature, and the caller is free to do what it
wants with that information.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Sat, Feb 18, 2023 at 12:10 PM Michael Thomas  wrote:

>
>
> Beyond this SHOULD, I think we need to consider whether the caller needs
> to be told specifically when a failure occurs for this reason.  Right now
> an implementation might return just a PERMFAIL without noting that it's
> because of "x=" versus the signature failing for some other reason.  Should
> the caller be given this extra detail to enhance the decision tree, or will
> this just complicate things?
>
> Why would it permfail? Does it permfail email without a signature too?
>
> Absent p=reject, there is nothing wrong with unsigned email.
>

I'm using the language of the DKIM RFC, so "PERMFAIL" here refers to
evaluation of the signature, not of the message.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman 
wrote:

> Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think
> the practical effect as described in protocol terms would be to change the
> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions.  Not
> that I'd expect to see this appear in a protocol document (maybe some kind
> of applicability statement).
>

Beyond this SHOULD, I think we need to consider whether the caller needs to
be told specifically when a failure occurs for this reason.  Right now an
implementation might return just a PERMFAIL without noting that it's
because of "x=" versus the signature failing for some other reason.  Should
the caller be given this extra detail to enhance the decision tree, or will
this just complicate things?

I think, for instance, libopendkim does identify the reason for the
failure, but I'm not sure whether any consumers of that API make use of
that detail beyond maybe logging it.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba  wrote:

> I like this approach: if the issue is that an "expired" signature is
> treated as unsigned, I think we have an unacceptable level of false
> positives.  But if the fact that a signature is valid but expired is
> simply another factor in the decision, I think we might be OK, keeping
> in mind that "x=" is purely advice to the validator.  To *really*
> expire a signature, one has to stop publishing the key associated with
> the selector.
>

One thing that would impede the success of this approach is whether current
implementations make the distinction between "invalid" and "valid but
expired", and for those that do not, how much churn and for how long it
would take to make that change to the ecosystem.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Wed, Feb 15, 2023 at 10:49 PM Evan Burke 
wrote:

>
>> I don't think we're saying different things.  I remember the point of the
>> answer I got in that session being that most, but not all, implementations
>> check or enforce signature expiration.  But that means if "x=" is the
>> solution we land on, we have to accept that a possibly-significant part of
>> the ecosystem won't be able to use that solution.
>>
>> Then again, anything new we roll out is going to take a while to become
>> universal anyway.
>>
>
> The short version is that x= works where it matters at the moment. As far
> as I've seen and heard from others, DKIM replay spam currently focuses
> heavily on replaying to recipients at just a few of the top 10 global
> mailbox providers. This is for reasons of economies of scale - roughly
> speaking, it might be viable to spend 1000 hours finding a way through the
> filters of a provider operating 200 million mailboxes, where it is not for
> a provider hosting 20 million. This is part of why I don't think we'll see
> replay attacks expand significantly to more domains; replay is just one
> ingredient in a larger spam recipe that takes a lot of other fine-tuning to
> achieve its intended effect.
>

If my prior formulation is right, i.e., that the attack only takes a few
seconds to complete, what "x=" value are we proposing that will work here
without also bringing undesirable side effects?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas  wrote:

>
> There's also the question of whether "x=" is properly enforced.  RFC 6376
> says verifiers "MAY" choose to enforce it.  I think I asked about this at a
> conference recently and was told that it's not universally supported by
> implementations.
>
> Others have said that the enforcement is pretty good. But I have no way to
> evaluate if that's true.
>

I don't think we're saying different things.  I remember the point of the
answer I got in that session being that most, but not all, implementations
check or enforce signature expiration.  But that means if "x=" is the
solution we land on, we have to accept that a possibly-significant part of
the ecosystem won't be able to use that solution.

Then again, anything new we roll out is going to take a while to become
universal anyway.

> Going the route of some kind of duplicate signature detection alleviates
> the risk of that approach, but also sort of inverts it: If you assume each
> signature will only appear once, there's a window during which the first
> signature works, and then a second window during which duplicates will be
> blocked, but then that process recycles when the cache expires.  That could
> mean replays work if I just out-wait your cache.  You also introduce the
> risk of false positives, where a legitimate message tries to arrive in
> separate envelopes with the same signature, and all but the first one get
> blocked.
>
> I would imagine that the cache should be valid for a small x= expiry.
> That's really a tuning problem on the sending domain.
>
Possibly.  I get the impression that a good chunk of the industry would
like something more from us than "you have to tune this" (i.e., something
laying out specific values), but maybe we can't do anything beyond general
advice because there are too many other variables at play.  RFC 6647
avoided laying out specific values for greylisting, for example.

> There are *tons* of external dependencies on the filtering MTA. I really
> can't imagine that this would be the straw that breaks the camel's back.
>

Depends (as I think Scott said) on the size and resources available to the
operator, and how much they're a target of this attack.  We've generally
shied away in the past from solutions of the form "you have to be at least
this tall to play".

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman 
wrote:

> Any reputation based solution does have down scale limits.  Small mail
> sources
> (such as your random Nebraska forwarder) generally will have no reputation
> vice a negative one and so wouldn't get penalized in a scheme like the one
> I
> suggested.  This does, however, highlight where the performance challenge
> is.
> We've moved it from duplicate detection to rapid assessment of reputation
> for
> hosts that have sudden volume increases.
>

I wonder if this could be separated into "reputation" and "hosts that have
sudden volume increases".

Reputation is hard.  Large operators spend a lot of R time coming up with
algorithms that accurately (for some value thereof) compute the reputation
it should associate with an identity.  That investment means they're not
inclined to share that secret sauce.  Small operators without those
resources long for an open source solution, or a cheap or free service from
which they can reliably get reputation data.  Companies that offer
reputation data for public consumption have been sued out of existence by
people that get marked as suspect, so really good ones don't seem to abound
last I checked.

There's a lot less secret sauce involved in the latter.  It would be
interesting to see if some simple recordkeeping of this nature could make a
dent in the problem space we're discussing.  But that might just encourage
further distribution of the attack to avoid detection.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:

> At maximum, isn't it just the x= value? It seems to me that if you don't
> specify an x= value, or it's essentially infinite, they are saying they
> don't care about "replays". Which is fine in most cases and you can just
> ignore it. Something that really throttles down x= should be a tractable
> problem, right?
>

Remember that the threat model is:

1) send a message through A to B, acquiring A's signature
2) collect the message from B
3) re-post the message to C, D, E, ...

These days, this attack is complete within seconds.  If you select an "x="
small enough to thwart this, you have to expect that all legitimate
deliveries will happen even faster.  But email delivery can be slow for
lots of legitimate reasons.  So I would argue that "x=" alone can't really
solve this problem without introducing other constraints that we don't
really want.

There's also the question of whether "x=" is properly enforced.  RFC 6376
says verifiers "MAY" choose to enforce it.  I think I asked about this at a
conference recently and was told that it's not universally supported by
implementations.

Going the route of some kind of duplicate signature detection alleviates
the risk of that approach, but also sort of inverts it: If you assume each
signature will only appear once, there's a window during which the first
signature works, and then a second window during which duplicates will be
blocked, but then that process recycles when the cache expires.  That could
mean replays work if I just out-wait your cache.  You also introduce the
risk of false positives, where a legitimate message tries to arrive in
separate envelopes with the same signature, and all but the first one get
blocked.

> But even at scale it seems like a pretty small database in comparison to
> the overall volume. It's would be easy for a receiver to just prune it
> after a day or so, say.
>
It creates an additional external dependency on the SMTP server.  I guess
you have to evaluate the cost of the database versus the cost of the
protection it provides, and include reasonable advice about what to do when
the database is not available.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:

> Have you considered something like rate limiting on the receiver side for
> things with duplicate msg-id's? Aka, a tar pit, iirc?
>

As I recall that technique is sometimes not suggested because (a) we can't
come up with good advice about how long you need to cache message IDs to
watch for duplicates, and (b) the longer that cache needs to live, the
larger of a resource burden the technique imposes, and small operators
might not be able to do it well.

> And to be clear, what do you mean by "oversigning"? Is it something
> different than just signing the Subject, etc, header in the first place?
>
This was a term invented to refer to the technique described in Section
8.15 of RFC 6376.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] replay clues

[Murray S. Kucherawy]

On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas  wrote:

>
> It's certainly possible to collect data that might correlate something
> like "Subject signed vs. not signed" with a spam score, and that could feed
> in to a best practices document.  I don't know who might be up for
> investing the time into such a survey, however.  OpenDKIM used to collect
> such summaries from volunteer participants; I can see if the data sitting
> around in those tables had enough information for such a survey, but it
> almost certainly won't be current data.
>
> What I'm starting to think is that if we can collect that into the problem
> statement that may well be all we need to do if we determine that there is
> no there there in the solution space (given the solutions on offer now,
> that seems to be the case). Also: we can't write a BCP if we can't know
> what they may be because of the proprietary nature of the
> filtering/reputation. If the clues we find are well known to them then,
> well, it's sort of like what are we supposed to do?
>
I'm doubtful, but I'll see if the data I still have can reveal this sort of
correlation given the participants I had and the data they submitted.

If there are any large operators that could run such a survey, I'm sure the
WG would appreciate it.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Setting a stage for detection

[Murray S. Kucherawy]

On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker  wrote:

> There appears to be no perfect way to distinguish a Replay attack from a
> legitimate re-posting by an Alias or even a Mailing list (that preserves
> the original DKIM signature.)
>
> The only 'signal' that is valid, also is ambiguous.  The signal is that
> the rfc5321.Mail command has an address that is not in any of the
> rfc5322 address fields.   The ambiguity, of course, is that that's also
> true for Alias.
>
> I'm wondering about designing some assistance by the author's platform
> and the Aliasing platform, to flag what they've done.
>
> Imagine adding a header field like "Separate-Envelope:", possibly
> listing the domain name of the site putting the flag there, and having
> them add a DKIM signature to cover it and the rest of the message.
>

Interesting.

Would this work if it passes through more than one layer of aliasing?  That
is, can this work if "Separate-Envelope" appears more than once?  Do they
all have to be signed, order preserved, etc.?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Setting a stage for detection

[Murray S. Kucherawy]

On Sun, Feb 12, 2023 at 1:21 PM Dave Crocker  wrote:

> One of the continuing problems with anti-abuse discussions is that
> discussion always goes to detecting bad actors.  While of course there need
> to be discussions about them, the problem is that there seem to be no
> discussions about good actors.
>
> DKIM and a mechanism such as I'm proposing gives the receiver a noise-free
> message flow to evaluate.  It can be used for finding bad actors, of
> course, but I think its primary benefit is in finding good actors.
>
I think this is a strong point.  One of the things that's stuck with me
since we were working on what became RFC 4871 is the notion that you only
really know anything when DKIM succeeds.  (But then, of course, you need to
be cautious about over-interpreting exactly what it's telling you.)  You
can't conclude anything from a failure because there are so many legitimate
failure modes.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas  wrote:

> Another thing that should probably be discussed is outbound spam
> filtering. At a high level, this is really about the sender sending spam.
> But email afaik is silent on whether senders or receivers should filter for
> spam (and if there is, it would be good to reference it). Sender filtering
> is especially pertinent and may well have clues of how a sender can
> mitigate it. A breakdown of how spammers defeat that outbound filtering
> would be really useful. For example, is the spam intended for mailboxes on
> the sending domain (eg, gmail)? Or do they go through a two stage process
> where they first get the spam through the sender, and then test it on the
> intended receiving domains? All of that would be really helpful.
>

I think it's sufficient for us to acknowledge that, in either direction, no
spam filter is 100% accurate.  It can be tempting to say "You shouldn't
sign spam, and if you do, you're the problem", but I'm sympathetic to those
in that business who are faced with the reality that they'll never get it
100% right.  Instead, I think we have to accept that reputable signers will
occasionally be tricked into signing spam, and the goal then is to try to
develop some new signal that can be provided to verifiers to handle those
cases.

The problem statement document proposed for the WG does spell this out, I
think.  What do you find missing in terms of the details?  Some of the
nitty gritty probably varies from one email provider to the next, for
example.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] replay clues

[Murray S. Kucherawy]

On Sat, Feb 11, 2023 at 2:35 PM Michael Thomas  wrote:

> It's never been especially clear to me whether deployments do their
> filtering up front, ie at the MX, or farther down the line. There are
> certainly advantages to do it right at the MX with less burden on using AR
> to signal all of what the filters consider the interesting bits that
> standard A-R might not support. But there may be good architectural reasons
> to postpone the filtering to later in the pipeline even if means that
> you're holding the spam longer before discarding it
>

Yep; there's no "right" way.  I've seen both kinds of architecture work,
and A-R tries to anticipate all sorts of options (by not precluding any of
them).

> But regardless of A-R just cataloging what those interesting bits might be
> could be useful in documenting how they can be used to detect replay spam.
> Also: I think there is more to it than whether the signature verifies, per
> say. The signature actually verifies, but it's the scrutiny that matters.
> Saying it doesn't verify essentially decouples from any reputation of the
> domain. But that is hardly the only way to look at it. Saying it verifies,
> but has problems is another way to view it. For wetware investigators an
> A-R that did that could be really confusing.
>

It's certainly possible to collect data that might correlate something like
"Subject signed vs. not signed" with a spam score, and that could feed in
to a best practices document.  I don't know who might be up for investing
the time into such a survey, however.  OpenDKIM used to collect such
summaries from volunteer participants; I can see if the data sitting around
in those tables had enough information for such a survey, but it almost
certainly won't be current data.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] replay clues

[Murray S. Kucherawy]

On Sat, Feb 11, 2023 at 4:48 PM Stephen Farrell 
wrote:

> FWIW, as this discussion has a bit of a flavour of one person
> arguing with a bigger bunch of people, I'd like to say that
> Mike is asking good questions that deserve consideration.
>

Have they not been getting consideration?  I know I've been replying to
many of his comments.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Fri, Feb 10, 2023 at 12:06 PM Evan Burke  wrote:

>
> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker  wrote:
>
>> On 2/10/2023 11:35 AM, Wei Chuang wrote:
>> > ARC is a tool to help support modern Indirect Mail Flows, and I
>> > believe belongs in the solution space to be explored.
>>
>> Since ARC uses the same technology as DKIM and uses it in pretty much
>> the same was, my understanding is that it, too, has the potential for
>> replay.  Having a reference to this fact makes sense to me.
>>
>> It doesn't need more than a mention, at this point, I believe, which
>> makes the current quick, reference exactly the right text, IMO.
>>
>
> +1
>
> I realize there are some mixed opinions on ARC, but it's actively used on
> several of the world's largest email systems - some of the same ones where
> DKIM replay attacks are focused - so it's worth consideration as part of
> the solution space. It may not end up being a viable option, but now isn't
> the time to write it off.
>

Speaking only as a participant:

I also don't think a comment like "ARC has the same problem, for largely
the same reasons" is by itself harmful here.

What I think we should be sure to avoid is expending WG energy trying to
solve this problem in ARC-space.  That, I would argue, is outside the
charter.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] replay clues

[Murray S. Kucherawy]

On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas  wrote:

> I've always thought that the likelihood of a protocol level solution for
> this issue is pretty close to zero if not zero. The various proposed
> solutions in the problem draft haven't given me any reason to dissuade
> me of that notion.
>
> That said, I think that we might be able to catalog some clues that
> something is suspicious which taken with many other clues can be used to
> by a receiver to make an ultimate decision of spamminess. A good example
> is the unsigned To: and Subject: lines. Even if it's strictly allowed by
> the spec, that doesn't mean it's not suspect. It could be really useful
> to collect this clues as input signals to a larger preponderance of
> evidence.
>

Authentication-Results already noted the idea that a signature, even a
valid one, might still be considered not acceptable to the verifier and
reported differently for one reason or another.  An unsigned Subject was
the classic example.

Dealing with this in A-R nicely removes it from being dealt with at the
protocol level, where I would argue this sort of logic doesn't belong.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Chartering update

[Murray S. Kucherawy]

On Sat, Feb 4, 2023 at 11:11 AM Michael Thomas  wrote:

> There are architectural ramifications regardless of whether it's mandatory
> or not. It would be a lot more reassuring if this were a common and
> accepted practice. I don't know the answer to that. If it's uncommon, there
> needs to be wider discussion imo.
>

What sort of ramifications?

There have been multiple cases presented in the past of good reasons to
double-sign something, if that's what you're referring to.  Key rotation
comes to mind.  Algorithm deprecation.  With and without "i=" or "l=" for
people experimenting with them.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Chartering update

[Murray S. Kucherawy]

On Thu, Feb 2, 2023 at 3:26 PM Michael Thomas  wrote:

> I guess my concern is more along the lines of what solutions *aren't*.
> There are a bunch of drafts trying to tie the envelope to the email and I
> think there needs to be a meta discussion of whether that is a good idea or
> not in general. Frankly that seems like an email architecture question not
> just a DKIM question. It would be nice to know if there is precedent for
> that in the larger community and what the implications are. Fwiw, I don't
> really consider the DMARC "alignment" as tickling the larger question
> because all it is doing is reporting on it, but a case could certainly be
> made that it is.
>

For what it's worth, the proposals that seek to offer a binding between the
envelope and the message aren't making any sort of mandatory change to
DKIM.  It's entirely optional to the signer whether to make that connection
using one of those proposals; conventional DKIM isn't being taken off the
table.  For instance, the idea I put forward suggests using two signatures,
one that makes the binding and a typical one that does not.  Such a tactic
would leave the original signal about a message intact while possibly
providing more, which seems to me to be strictly an improvement.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] sender signing practices

[Murray S. Kucherawy]

On Fri, Feb 3, 2023 at 5:14 PM Michael Thomas  wrote:

> That said, I don't know why we didn't make To:, Cc: and Subject:
> mandatory signed fields. But even if it's not mandatory, that should be
> a signal that the message should be given increased scrutiny.
>

RFC 4871 included those as SHOULD when selecting what to sign.  In RFC 6376
we backed off of that to more general guidance rather than listing specific
header fields.  In RFC 5451, we carved out the possibility that a verifier
might decide a DKIM signature not covering Subject (for example) might
reject such a signature even if it validates because it's not covering
important displayed content.  I know OpenDKIM exposed this as a
configuration option.

But with respect to replay: Even if To and Cc are signed, there's nothing
in DKIM requiring that they reflect any identities present in the envelope.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Chartering update

[Murray S. Kucherawy]

Colleagues,

The IESG is prepared to approve the charter overall.  There was one
blocking point about publishing the problem statement, which is that the
IESG would like that not to be a "maybe".  I think that's a reasonable
change to make.

There is also the fact that I have not secured co-chairs.  I only have one
volunteer, and I'd like to pair up that person with someone that's been an
IETF working group chair before.  I've approached a few people, all of whom
have declined.  We're stuck here until I can resolve that blank spot in the
plan.

If you have any suggestions, or have chaired before and are willing to
volunteer, please feel free to reach out to me.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Lars Eggert's Block on charter-ietf-dkim-04-05: (with BLOCK and COMMENT)

[Murray S. Kucherawy]

On Tue, Jan 31, 2023 at 2:12 PM Michael Thomas  wrote:

> Also: the date on the problem statement seems awfully aggressive. My
> thinking is that the problem statement should at least discuss (as is
> mentioned in the charter) how "replays" are completely legitimate uses
> of DKIM, and thus limit the solution space to not break those uses.
>

Milestones are negotiable, and the one(s) I used for this are largely dart
throws.  We can change them to be something more practical once chairs have
been secured.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Mon, Jan 9, 2023 at 12:57 AM Alessandro Vesely  wrote:

> On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote:
> > On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
> >> How about "replay-resistant protocol"?
> >
> > btw, it isn't clear that 'protocol' is what a solution will be. might
> be.
> > might not.  might be purely operational conventions, for example.
>
> That's right.  "Replay-resistant solution"?
>

The current charter text says "replay-resistant mechanisms", which avoids
constraining us only to protocol solutions.

I'm not seeing any other proposed changes to the charter; the milestones
are negotiable in flight so they don't need to be perfect out of the
starting gate, but suggestions there are welcome.

Absent any other proposed changes to the charter's text, I'll release this
for the next phase of review ("External Review", i.e., the whole IETF) in
the next few days.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 31, 2022 at 3:02 PM Murray S. Kucherawy 
wrote:

> On Sat, Dec 31, 2022 at 2:43 PM Dave Crocker  wrote:
>
>> The initial effort to form a working group in the IETF was pretty casual
>> and surfaced a lack of sufficient consensus among advocates.  The IETF
>> said go away until there's more agreement.
>>
>> We went away for a year, during which we developed the original version
>> of DKIM, which demonstrated the coherence.
>>
>> The current effort has none of that existing critical mass of work and
>> agreement.  This makes the effort quite a lot riskier.
>>
>> The fact that things are taking quite a few months doesn't help.
>>
>
> That's true.  I'd forgotten this bit of the history.
>
> If we think this constraint is appropriate, I'm fine to include it.  Does
> someone want to propose a sentence or two?  I need to avoid getting my
> wrist slapped for both championing the charter and writing it.
>

The IESG approved the proposed charter to go out for external review.  I've
added a few proposed milestones with dates (these can be edited later) and
taken a run at editing the text to add the constraints people were
proposing.  Please review and let me know if I got it wrong or missed any
feedback, or if the dates on the milestones are not realistic.  They were
selected on the assumption that we charter and have co-chairs in place by
the end of January.

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Lastly, I have one co-chair volunteer, but I need a second, preferably
someone who has chaired something in the IETF before.  Please let me know
if you'd like to either volunteer or nominate someone.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 31, 2022 at 2:43 PM Dave Crocker  wrote:

> The initial effort to form a working group in the IETF was pretty casual
> and surfaced a lack of sufficient consensus among advocates.  The IETF
> said go away until there's more agreement.
>
> We went away for a year, during which we developed the original version
> of DKIM, which demonstrated the coherence.
>
> The current effort has none of that existing critical mass of work and
> agreement.  This makes the effort quite a lot riskier.
>
> The fact that things are taking quite a few months doesn't help.
>

That's true.  I'd forgotten this bit of the history.

If we think this constraint is appropriate, I'm fine to include it.  Does
someone want to propose a sentence or two?  I need to avoid getting my
wrist slapped for both championing the charter and writing it.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas  wrote:

>
> On 12/29/22 7:20 PM, Murray S. Kucherawy wrote:
>
> On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:
>
>>
>>
>> Done, and thanks for that text.
>>
>> One nit, Barry's text should be above the proposals not below. It makes
>> it look like those are the only proposals on the table which I'm nearly
>> certain is not your intent.
>>
> One other thing though, should there be some bounds on what appears to be
>> the possibility of writing a BCP like document? I mean, I can think of some
>> things that could help mitigate this but they are pretty wonky and
>> definitely untested. Do we actually have that operational experience to
>> recommend anything?
>>
>
> The charter as-is is now up for IESG Evaluation and one AD has already
> commented on it, so I'm going to hold any edits until after the next
> telechat (on January 5th) so as not to give them a moving target.  After
> that I'll apply this and any other feedback.
>
> That's fine, but we can talk about it in the mean time, right? I'm not
> suggesting a specific change on the BCP part because I'm not exactly sure
> what we should do. I know that it seems "obvious" but it also seems to me
> that we could get out in the weeds really easy and recommend stuff that we
> probably shouldn't. That's what I'm struggling with respect to "bounds".
> I'm not sure that we have the operational knowledge -- or more likely
> operational knowledge that can be shared -- to recommend something?
>
I expect that one of two things will happen: (1) We will attract a
sufficiently broad set of contributors that whatever consensus they come up
with will be defensible because it collectively has the operational
knowledge and expertise to make appropriate BCP-style recommendations to
the industry, or (2) we will not, and we'll know it, and thus we'll know we
can't produce defensible advice suitable for publication.

I don't know off the top of my head what charter text I need to add to
capture this.  This is how consensus works, in my mind.  I take as evidence
of this the fact that the first incarnation of the DKIM working group knew
itself well enough to completely avoid the topic of user interfaces, for
example.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:

>
>
> Done, and thanks for that text.
>
> One nit, Barry's text should be above the proposals not below. It makes it
> look like those are the only proposals on the table which I'm nearly
> certain is not your intent.
>
One other thing though, should there be some bounds on what appears to be
> the possibility of writing a BCP like document? I mean, I can think of some
> things that could help mitigate this but they are pretty wonky and
> definitely untested. Do we actually have that operational experience to
> recommend anything?
>

The charter as-is is now up for IESG Evaluation and one AD has already
commented on it, so I'm going to hold any edits until after the next
telechat (on January 5th) so as not to give them a moving target.  After
that I'll apply this and any other feedback.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba  wrote:

> I agree with Mike and Scott on the point that it’s worth explicitly
> allowing the result to be a “can’t do it” publication.  Implicit “couldn’t
> do it” is fine in most cases, but here we might say something like, “If the
> working group decides that none of the proposed approaches will work
> acceptably well and is unable to find an acceptable alternative, it may
> instead publish a report describing the problem and summarizing the reasons
> that proposed approaches are not acceptable.”  Making that explicit will
> avoid arguments about whether such a document is within the charter scope.
>

Done, and thanks for that text.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sat, Dec 24, 2022 at 9:12 PM Michael Deutschmann 
wrote:

> On Mon, 12 Dec 2022, you wrote:
> > > Blind-carbon-copy is already a sign of spam.
> >
> > Except when it's not, like this very mailing list.
>
> Only if you don't whitelist *all* forwarders you set up and mailing lists
> you have joined first, overriding the Bcc filter on a match.
>

I've always expected that requiring users to register and deregister every
mailing list they join or depart would be interpreted as tedious and a
disincentive, resulting in complaints (and thus support costs or lost
customers) when they forget or get it wrong.  It seems like a tactic that
won't succeed at scale.


> It's easy to sort wanted mail between forwards/mailing-lists and normal
> narrow-casted mail.  Spam can masquerade as either; but if possible a
> spammer would want to look like narrow-casted mail as that is the only
> kind that could be expected to arrive from a stranger.  To use this
> exploit, they must give that up.
>

If you're talking about replay, I don't understand "must".  The replay
attack under discussion works fine if it's unicast.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas  wrote:

> Shouldn't the problem statement explore whether there is a plausible
> tractable solution before it moves on to protocol work? That is, if there
> isn't a tractable solution the wg should go into hibernation again. I'm
> pretty sure that I brought this quite a while ago. Of if not the problem
> statement, afterward just evaluating for a go-no go decision before
> starting any work.
>

A working group is implicitly allowed to admit defeat if it decides it
can't solve the problem it thought it was supposed to solve.  DBOUND comes
to mind; it deadlocked on whether the problem was tractable, or even well
enough understood, to advance a consensus protocol solution, and closed
without producing anything.

I don't think the charter has to say that expressly.  It's part of the
process.  The charter stipulates an ordering, and I think that's sufficient.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy 
wrote:

>
> I've synthesized the feedback to date into a new update to the charter
> text.  It calls out the order of operations the group seems to prefer, and
> makes explicit the possible output of a "best practices" update.  Let me
> know if this is a step in the right direction or the wrong one.
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>
> Note that the next IESG telechat with room on it won't be until the new
> year at this point, so this won't advance before then.
>

Having heard no further feedback, I've moved the draft charter to the next
state, which will trigger the first of two IESG reviews early in the new
year.  It will go out for full IETF review after it passes the first of
those.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Tue, Dec 13, 2022 at 5:00 PM Michael Thomas  wrote:

> On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:
>
>
> This tactic appears to me to have three problems: (1) negative reputations
> are of little value to receivers, because attackers can easily shed them;
> (2) if I have to remember everything with a negative reputation for some
> undetermined period of time, I now have a resource problem; (3) I can just
> not sign my mail, because maybe no reputation is better than a negative one.
>
> I don't understand #1. As in they can move to another service? Or what?
>
Right.  IP address gets a bad reputation?  Move to another one.  Domain
blocklisted?  Register another one.  etc.  Any bad reputation is trivially
exchanged for a neutral one.  That leaves us in a world where only positive
reputations are meaningful, and presumably once you have one you'll work to
protect it.

> As for 3, it's pretty easy to cons up a new domain with fresh neutral
> reputation and still enjoy the supposed benefit of mail being signed for
> awhile. If you factor SPF in though it probably gets harder because now you
> need not only a new domain, but the underlying network connectivity to
> avoid detection.
>
Yep, but if a receiver values DKIM more than SPF, for instance, then maybe
they're willing to forgive that lack of support.  Maybe the forwarding
problem bugs you enough that you're forced into such a position, for
instance.

>  Which brings up a question: even though they pass on DKIM they should
> fail on SPF, right? For transactional email that seems like a big old red
> flag, right?
>
Yes, but that doesn't work for all applications or flows.  It depends on
what tolerances work for your use case and your users.

> In both cases you need to keep track of both as somebody with a bad rep
> might get better and one with a good rep might get worse, right? That is,
> this isn't static. Preferential of course is pretty subjective. I suspect
> that most of these filters operate much like spamassassin which gives
> weights to various factors, so good and bad are both useful.
>

Sure but on my email, I would like you to have only positive signal, to the
extent I can control that.  Or, at least, as little negative signal as
possible.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Tue, Dec 13, 2022 at 2:54 AM Alessandro Vesely  wrote:

> Perhaps they could devise better methods than asking _accountable? (Y/N)_
> on a
> questionnaire.  Linking to bank accounts is an example.
>

Would you link a free email account to your bank account for any reason?  I
don't think I would.  I'll go somewhere else.

A discernment possibility is to sign differently.  RFC 6376 specified an
> Agent
> or User Identifier tag, i=, as a finer grained identity.  One having
> i=bullshit...@example.com would still be a valid DKIM signature.
> Alternatively, could use subdomains, d=bullshit.example.com.  How long
> would it
> take receivers to learn it?
>

This tactic appears to me to have three problems: (1) negative reputations
are of little value to receivers, because attackers can easily shed them;
(2) if I have to remember everything with a negative reputation for some
undetermined period of time, I now have a resource problem; (3) I can just
not sign my mail, because maybe no reputation is better than a negative one.

In contrast, positive reputations are far fewer in number, far more
valuable to collect and protect, and very likely last a lot longer.  Giving
preferential treatment to a domain that earns a positive reputation seems
like a much better approach.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Murray S. Kucherawy]

On Mon, Dec 12, 2022 at 5:03 PM Michael Thomas  wrote:

> Note that in both cases it requires the good will of the receiver (or
> client in the web case). We already have the equivalent of expired certs
> with the x= option. If senders are concerned about this, there is
> already solution in the current specs.
>

At a recent meeting where I heard some mass senders talk about this
problem, the use of "x=" as a mitigation technique was raised.  I was
curious to know what their experience was in terms of (a) success overall,
but also (b) how broadly they found "x=" to have been properly implemented
by receivers.  I have to admit that was some months ago and now I forget
the answer; maybe someone else who was there can fill in that blank.

But I'm not sure that "x=" by itself is enough, given that it takes only a
matter of seconds for the attack to succeed, and it seems unlikely to me
that the "t=" and "x=" values would ever be that close together.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas  wrote:

> But I want to return to my previous point of whether reputation is even
> quantifiable, and whether somebody has actually gone out and researched it.
> We can say that this is a problem in theory, but do we have any data to
> back it up? I kinda think that should be table stakes before talking about
> rechartering.
>

The industry appears to think it's a factor.  This work comes to us from
M3AAWG where there's a critical mass that believes reputation abuse of this
nature is real.  Though I agree it would be helpful to have metrics to
describe it more precisely, it's my perception that there's enough momentum
here to back chartering.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim