[Ietf-dkim] Re: DKIM with body length

[Jon Callas]

> On May 25, 2024, at 09:49, John R Levine  wrote:
> 
> On Fri, 24 May 2024, Jon Callas wrote:
>>> blank lines.) Maybe you can tell it's from a list and the crud is
>>> benign, or maybe you can't and you should treat it as suspicious.
>> 
>> And yet, I didn't make up the word robustness, it's there in the spec as 
>> Dave quoted.
> 
> When I read the whole paragraph, the message I get is that l= is intended to 
> survive mailing lists but it has many problems so don't use it.  My 
> recollection is that for a few features like l=, most of us found them 
> useless, a few people really really wanted them, so that paragraph was a way 
> to get the document out the door.

Well --- kinda? It's really hard to discuss "mailing list" as if it's a thing. 
For example, there's Mailman (and there's a lot of crap in Mailman that is 
related to how to do a mailing list in a world of signed messages) which is 
very different thing from say, Google Groups, which is a very different thing 
from (handwave) an exploder similar to what happens in virtual entry in Postfix.

Certainly, it's common (perhaps expected) that a mailing list will add a 
trailer to a message. However, that's not the only thing a mailing list does, 
and I don't want to go down that rathole in this thread. I'm happy to go down 
it in another thread.

Lots of business mail has (or had) trailers put on them to declare that 
scanning had been done, or bogus legal threats, or many other things. The 
intent of l= was for the administrative domain to make an affirmative statement 
about the content they are willing to be responsible for.  


> I do not ever recall l= being an proposed as an invitation to recipient 
> systems to do surgery on incoming mail.  If anyone had ever suggested that, 
> I'm sure I'm not the only list manager who would have been sure to strip any 
> l= signatures to prevent downstream funny business.

Well, I do. As I said, it's the thing that turned me from being bewildered by 
it to thinking it was a good idea. It's why I remember it. I think there needs 
to be more surgery on emails in a number of places, but that too is a side 
discussion. (Among others, Received: headers.)

> 
>> 1) It appears that the issue with l= is that implementers are not doing it 
>> correctly, ...
> 
> If there ever was a correct way to use l=, there sure isn't now.  But per 
> your next message we seem to agree on the outcome.

Yes, I was thinking about it and was reminded by advice of an old boss/mentor 
not to confuse the world one is in with the world one wants to see. Also 
another situation where an idea that would have been a good one if implemented 
correctly was implemented badly, so we removed it from the -bis on that.

Jon


___
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

[Jon Callas]

I was thinking about this, and have come around to the other side -- if the 
real-world problem is that people are doing a feature wrong, pulling it is a 
completely reasonable response. That it could be a good idea, if only it were 
implemented right doesn't matter. The reality is that it's wrong in the real 
world. So put me down on the side of just axing it.

Jon

___
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

[Jon Callas]

> On May 24, 2024, at 19:55, John Levine  wrote:
> 
> It appears that Jon Callas   said:
>> And look at it -- l= is intended to increase robustness and strictness of 
>> interpreting the message.
> 
> I don't see how that followes. In all the years I've been futzing with
> email I can't ever think of a time where a message showed up with
> added crud at the end and the right thing to do was to discard the
> crud and keep going. (I'm ignoring the old sendmail bug that added
> blank lines.) Maybe you can tell it's from a list and the crud is
> benign, or maybe you can't and you should treat it as suspicious.

And yet, I didn't make up the word robustness, it's there in the spec as Dave 
quoted.

> 
> The rationale I recall for l= is that it would let mailing lists put a
> footer on messages. That never seemed very persuasive, both because
> lists make a lot of other changes to messages, and because it opens up
> a hole you can drive an ocean liner throught.

And also lots of other trailers, like AV scanners, and so on. For mailing 
lists, there are plenty of other issues, too, and let's not get into that, as 
it's a mess that's orthogonal to this discussion.

> 
> I also recall people claiming with a straight face that MUAs would
> show the signed and unsigned parts of a message in different colors so
> the user could decide which parts of it to believe. I hope I don't
> have to explain why that was a terrible idea.

You don't, at least not to me. I think it's a horrible idea, too. The Yahoo 
guys considered it, and I vaguely remember there was some mail client that did 
it once. 

The bottom line for me is twofold:

1) It appears that the issue with l= is that implementers are not doing it 
correctly, and that there's even lazy-unto-hostile use of it. If this is the 
case, that implementers are not doing the spec properly, I don't see that 
changing the spec is going to fix the issue, that of implementers not doing the 
spec.

2) If we get a couple implementers to lean hard in the other direction -- an 
anti-Postel's Law if you were, be conservative in what you generate and really 
obsessive about compliance on receipt -- then it wouldn't need to be changed in 
the spec.

I was originally against it because I thought it would be hinkey in ways not 
dissimilar to the way it's got issues today. I was convinced that it was a good 
idea if it were implemented well, which it's not. At the end of the day, 
implementers have to either implement it right or not at all. I'm on board with 
that. Removing it from the spec is a fine way to address the problem, providing 
that we end up with implementers implement not doing it correctly. 

I still think that implementers implementing it correctly is a better solution 
than implementers removing it correctly, in part because removing it correctly 
means handling some error condition when it's there (unless we agree that 
ignoring it is fine).

Jon


___
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

[Jon Callas]

> Jon,
> 
> Sorry to be finicky, but I don't recall any statement in the DKIM 
> specification that matches or approximate that semantic for any aspect of 
> DKIM, never mind l=.
> 
> As for l= semantics, this is all of the relevant text, none of which is 
> nearly as interesting as the interpretation you've invoked:
> 
You are indeed being finicky, as well as correct. I wasn't talking about the 
approved RFC, but the discussion around it.

Nonetheless, I think the essence of that discussion and my comments are 
embodied in:
>> 8.2 .  Misuse of 
>> Body Length Limits ("l=" Tag)
>> 
>>Use of the "l=" tag might allow display of fraudulent content without
>>appropriate warning to end users.  The "l=" tag is intended for
>>increasing signature robustness when sending to mailing lists that
>>both modify their content and do not sign their modified messages.

And look at it -- l= is intended to increase robustness and strictness of 
interpreting the message.

Jon



___
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

[Jon Callas]

I feel like I ought to comment. I've always had mixed emotions about l=, and I 
also agree with some of the things John Levine said.

When we first talked about l=, I thought it was kinda silly. What brought me 
around to it was a comment someone made that the receiver of a message with l= 
ought to cut the message at the end of l= and just drop all message content 
after that. With that observation, I turned around. The silly thing about was 
that it was essentially the statement by the authoritative domain, "well, I 
attest to generating this message, but only the first 1234 bytes of it, after 
that, well -- you're on your own." And this is indeed a silly thing. Why attest 
to a part of the message? However, once one looks at this and decides that the 
remaining characters ought to go into the bit bucket, it makes sense. 

When the sender is using l= to tell you they're only signing that, they're also 
saying that the tail end of the message is detritus or even passive forgery. 
That trailer really ought to go. We have a signed statement that it's not part 
of the message, after all. Now, all of a sudden it made sense to me. I even got 
excited about it. It has real meaning. (Now, one could also argue that without 
l= an MTA oughta chuck any unsigned parts of the message, as well, but let's 
not go there quite at this moment.)

John Levine pointed out two important things: that the issues with l= stem from 
its misuse, not its use (and often misuse that is in violation of the 
standard), and also that we can't expect that people who are not following the 
standard are suddenly going to start following the standard if we change it. 
Each of these are important things to discuss.

Let's take the case of someone who stupidly signed a message with l= and a 
small number, thus permitting a spammer to put actual bad stuff at the end (and 
not just an irrelevancy like whose antivirus product is failing to flag the 
malware in it). If a receiving MTA cut off the message at the end of l=, not 
only would this eliminate the bad content, it would deliver a message that 
would very likely look strange or bogus to the human who looked at it. "WTF, 
this message cuts off after only 12 characters -- huh, I guess I'll delete it."

If software did this -- actually implemented what l= says (albeit passively, 
not actively) that the message is only N bytes long -- then the problem would 
go away, and this is a *better* solution than getting rid of l=.

Now let me get to John's very important point. A standard is a description. 
It's almost like a grammar. It's a way that an implementor can use to know that 
if they want to express a concept X, they should lay out the bytes in that 
standard's form. At the same time, it says to the receiving implementor that 
when someone says X, here's what they were trying to say.

If someone is not emitting a message according to the standard, then our 
changing the standard is rather like a photo of a gravestone I saw last week 
that read, "Here lies (not LAYS) ..." of an English teacher. My comment was 
that although I'm a descriptivist, I stan the message.

That is relevant to us, because much of the discussion -- and John's point -- 
is that if implementors are not doing what the standard says (let alone things 
it implies), no amount of changing the standard is going to do something. Heck, 
we might as well put l= on DKIMs gravestone.

Secondarily, implementors have a lot of leeway in what they do. There's nothing 
wrong with (also mentioned as a thing some people do) to consider wacky use of 
l= to be a sign that it's spam and just toss it. Moreover, that apparently got 
people to fix their code. 

From a standards and implementation standpoint, the best fix to this situation 
is not to get rid of l= as that's letting the shoddy implementors win. The best 
fix is for implementors to double down on l= and interpret it in the way that I 
think is the best way. If there's an l=, then drop everything afterwards. (Note 
that one could also implement this concept passively -- excising unsigned 
content from a message in a lot of places. If someone did it, it's outside the 
standard anyway, and would be a Good Thing for the integrity of the email 
ecosystem.)

Summing up: I completely agree with John's real point. If people aren't 
following the standard, you aren't going to fix that by changing the standard, 
no matter what change you make. Secondarily, I think that a better fix for this 
situation to strictly interpret l= than get rid of it because a strict 
interpretation leads to messages being delivered to humans that are exactly 
what was said, but not what was meant. Make them say what they mean and mean 
what they say.

Jon



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

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

[Jon Callas]

On Feb 1, 2024, at 10:03, 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.

RFC5322 says:

  o  CR and LF MUST only occur together as CRLF; they MUST NOT appear
 independently in the body.

So I think the answer is that a thing with a lone CR or LF is not a
valid message so signers shouldn't sign them and validators shouldn't
validate them. If you want to allow them, OK, but no promises that
anyone at the other end will treat the brokenness the same way you
dod.

We can get into some theological arguments about BINARYMIME which
allows arbitrary bytes in a MIME part but I expect that DKIM
canonicalization code will choke on other stuff in binary MIME before
it gets to a \x0a or \x0d.

I went down the rabbit hole of RFC5322 syntax around CR and LF, and yes, it 
seems to me that 5322 is definitely saying no bare CR or LF. However. Section 
4.0 and 4.1 (in detail) describe obsolete syntax and bare CR and LF is in there 
with the interesting comment in 4.1:

   Bare CR and bare LF appear in messages with two different meanings.
   In many cases, bare CR or bare LF are used improperly instead of CRLF
   to indicate line separators.  In other cases, bare CR and bare LF are
   used simply as US-ASCII control characters with their traditional
   ASCII meanings.

Which means that yes, it's forbidden, but it's also obsolete, and there's 
this note about how someone might want to use (e.g.) an LF
   for some quote-quote
traditional ASCII meaning, like a real line feed that I emulated here with a 
CRLF and a bunch of spaces. (I am thoroughly amused at how constructing this 
weird paragraph is making my MUA hyperventilate. I'm even wondering if the droll
humor even goes through.)

So that gets to the tacit question -- what should a DKIM implementor do? Me, I 
would *not* put in code looking for bare CRs or LFs. My major rationale is an 
appeal to layering, or bluntly, it's not my job to enforce RFC 5322 syntax. 
Someone else in the pipeline is supposed to do that, and all I can do is screw 
things up.

5322§4.1 doesn't just talk about CR and LF. It also talks about how NUL is also 
an obsolete character. §4.2 is all about obsolete folding whitespace. §4.3 is 
about obsolete time zones, and there's a whole lot more in there of obsolete 
things. If I'm going to parse for CR, shouldn't I also be parsing for someone 
saying GMT when they meant UTC? Shouldn't I be checking line lengths, too? And 
we haven't even gotten to other things like your observation about BINARYMIME.

If I look at it from a failure-mode analysis, if I generate a false positive on 
5322 parsing, or even am totally annoyingly correct -- nuh, uh, I'm not going 
to sign that message because you said GMT -- it's going to piss people off and 
I'll look at best like a clenchpoop and at worst like a fool. On the other hand 
if I sign something that was not 5322-compliant and the signature breaks then 
well, perhaps the MUA should canonicalize it, or the MSA should reject it. I 
think it's totally reasonable for a DKIM implementation to just declare that 
the thing it's given is 5322-compliant, and if it is, it's not DKIM's problem.

So I'd assume 5322ness in DKIM, because there are many dragons in the 
alternative.

Jon

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

Re: [Ietf-dkim] Replay attack definition discussion

[Jon Callas]

> On Aug 16, 2023, at 11:21, Jim Fenton  wrote:
> 
> On 16 Aug 2023, at 10:57, Jon Callas wrote:
> 
>>> On Aug 16, 2023, at 10:25, Alessandro Vesely  wrote:
>>> 
>>> 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?
>> 
>> There's two reasons that this isn't acceptable. One is that DKIM is 
>> domain-level signing, not user-level signing, and that's been so since the 
>> beginning. DKIM is *intentionally* designed with that as an anti-goal. The 
>> second is the historical use of email, where addresses are not accounts.
> 
> Deciding whether to apply a DKIM signature based on the submitting user is 
> not the same thing as user-level signing. Signers can use any criteria they 
> want in deciding whether to sign an outgoing message.

I think that's another facet of what I'm trying to say. The statements in the 
message are only loosely connected to the account underneath.

> 
>> In that second historic case, it's not acceptable because there are lots of 
>> cases out there where there are virtual addresses, not really an account, 
>> and yet from time to time a message has to be sent with a `From` of that 
>> address.
> 
> I have lots of virtual addresses. When submitting a message to my outgoing 
> MTA, I still authenticate to it as myself. If my outgoing MTA served multiple 
> users, it should check whether the From address corresponded to my account. 
> In the situation Ale is considering, the decision on whether to sign or not 
> would depend on the submitting user, which is not necessarily the From 
> address on the message.

Yes, this is exactly my use case, too, and many MTAs let an authenticated user 
send anything they want. Many others accept an arbitrary message, but might 
later on, bounce it back to user. 

I think we're in violent agreement on this?

Jon


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

Re: [Ietf-dkim] Replay attack definition discussion

[Jon Callas]

> On Aug 16, 2023, at 10:25, Alessandro Vesely  wrote:
> 
> 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?

There's two reasons that this isn't acceptable. One is that DKIM is 
domain-level signing, not user-level signing, and that's been so since the 
beginning. DKIM is *intentionally* designed with that as an anti-goal. The 
second is the historical use of email, where addresses are not accounts.

In that second historic case, it's not acceptable because there are lots of 
cases out there where there are virtual addresses, not really an account, and 
yet from time to time a message has to be sent with a `From` of that address.

Example: there's i...@example.com, and that goes to both Alice and Bob, via a 
Postfix virtual address (or an internal organization group). There's no account 
of info, the vast majority of the time email is only incoming, but from time to 
time a message has to be sent From that. On that, take the case where spam 
starts coming in from ads@store and to unsubscribe they have to send a message 
from info, not Alice nor Bob. 

There's even a single-person version of this, the user+t...@example.com 
convention, and variations on that, such as the way that Gmail considers a dot 
to be optional. The address first.last@gmail is the same as firstlast@gmail and 
even f.i.r.s.t.l.a.s.t@gmail.  

In a real-world example of the broader issue, my partner and I have an email 
address that goes to the both of us. It's the contact email for airlines, 
concerts, and so on, so that we both get it. A few years ago, it was literally 
a Postfix virtual entry. Presently, it's a Google Group because there's no 
equivalent of a virtual fan-out there. Once or twice a year one of us has to 
send a message from there. We don't want a separate account because that costs 
money (and is annoying).

The bottom line is that ambiguous, organizational, and virtual addresses exist, 
and have to be taken into consideration. 

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

[Jon Callas]

> On Aug 13, 2023, at 20:31, 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).

I'm not the first to say it, but it was  the opposite. The original statement 
from the Domain Keys folks from Yahoo was that when your bank sends an email to 
you, your ISP can know that, even though it's bounced through your alumni 
association. It was *specifically* a three-hop thing in the distilled elevator 
pitch.

Remember as well that for two-hop sending, SPF was a preferred thing and there 
was a lot of conversation that tried to put them as competitors. We argued 
against that. I think it's pretty obvious that the two together are much better 
than either alone.

Here's a vastly oversimplified case. Consider someone who runs email on a 
small, NATted network. Under SPF, if a spammer sends a message from any host 
outward, it has the same path and thus passes SPF despite being spam. 
DKIM is domain-to-domain authentication, not user-to-user, because user 
relationships are complex. Here's a not-uncommon example:

Incoming email sent to info@domain goes into Alice's mailbox, via something 
akin to virtual users in Postfix. From time to time Alice sends a message from 
info@, without there being an actual user. The DKIM edge MTA signs it. That 
means that the mail architecture has to deal with the gap between Alice and 
that signing MTA. Any given setup is either a bug or a feature that they, not 
we, have to manage. Delegated email is a thing.

Pulling in what you said above that:

> [...] If DKIM is what is used by ESPs to authenticate message submissions, 
> and the fallback for non-DKIM signed mail is to allow the submission, then 
> certainly that is something spammers would leverage. That seems like an 
> unlikely scenario since ESPs require other forms of authenticating message 
> submission.

I'm not sure I really understand your case here.

DKIM authenticates the "administrative domain" of the sender, not the user. As 
noted above, the domain has to do a bunch of user management that's outside the 
scope of DKIM. That management can be strict (any user can only send email with 
their own From on it) or loose (any user can just telnet to port 25 and start 
sending emails from anything) or anything in between, and any decision has 
consequences the sysadmins have to adapt on their own.

I think you're saying more or less what I was saying, but I'm not sure.

As a last note, internal signatures like OpenPGP, and S/MIME, and anything else 
are inside the message and thus orthogonal to DKIM (and SPF).

Thus, SPF is a verification of the network path. DKIM is an authentication of 
the sending MTA. S/MIME etc. is an authentication of the sender. Each has its 
own failure modes, and each has weird edge conditions and gray areas. I look at 
it as they go up a stack of sorts -- network -> domain -> user.

Jon


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

Re: [Ietf-dkim] not removing signatures

[Jon Callas]

> On Dec 6, 2022, at 14:23, Michael Thomas  wrote:
> 
> 
> On 12/6/22 2:05 PM, mikespec...@gmail.com wrote:
>> I very much disagree with everything the above poster said.
>> 
>> Deniability is a default property of all e2ee messaging apps; it’s both 
>> surprising and disheartening that email — a largely unencrypted medium — 
>> fails to provide deniability for its users. If we said that signal was 
>> behaving this way, or TLS, or any other e2ee protocol, we’d be up in arms.
>> 
> If you want deniability you need to do it some other way. You have absolutely 
> no control over the receiving domain and little to no control over the 
> sending domain as well. Even if this wg produced a BCP, BCP's are toothless 
> and rely on good will when there may be none or can't be bothered. Even 
> unsigned mail can make for good circumstantial evidence.

I'm very much pro-signature removal. 

I'm going to disagree with Mike a bit in that *deniability* is not what we 
want. What we want is not creating a mostly-valid non-repudiation. (Me, I don't 
think deniable encryption is possible, but that's another long discussion.)

There have been a few cases where DKIM signatures were used to verify hacked 
email accounts. 

However, as you know, DKIM authenticates the Administrative Domain not the 
user. We know that if someone were to be able to do simple SMTP forging to an 
outgoing MTA, the MTA would sign the message despite it not coming from the 
user.

The purpose of a DKIM signature is, as our original statement put it, to make 
sure that a message from your bank actually came from your bank, even if it 
passed through your alumni association. Once it arrives to your real mailbox, 
that signature is not needed.

Frankly, there are plenty of other headers that ought to be removed as well. 
That is also another long discussion that I don't want to rathole on. In any 
event, email leaks all sorts of information about senders, intermediate 
domains, and more and this is a real issue. It's just one we're used to.

Jon

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

Re: [Ietf-dkim] Rechartering

[Jon Callas]

> On Dec 3, 2022, at 11:42, Dave Crocker  wrote:
> 
> On 12/3/2022 11:35 AM, Jon Callas wrote:
>> Agreed, and we need some other weasel word than "lightweight" because there 
>> are lots of people working on "lightweight" symmetric ciphers. Something 
>> like "appropriate"?
>> 
>> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
>> signature that is secure for a year (or more), it needs one that is secure 
>> for somewhere between a minute and a week.
> 
> transit-time, cryptographic authentication ?
> 

I like that.

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

Re: [Ietf-dkim] Rechartering

[Jon Callas]

> On Dec 3, 2022, at 11:01, Stephen Farrell  wrote:
> 
> One nit though, that you should feel free to ignore if it
> was discussed already - the phrase "in a secure way" doesn't
> quite capture what the DKIM WG was trying to produce, e.g.
> we consider unsigned DNS fine for DKIM public keys, even
> though that'd not be described as "secure."
> 
> Maybe s/in a secure way/using a lightweight cryptographic
> mechanism/ would be better? But again, it's a nit.

Agreed, and we need some other weasel word than "lightweight" because there are 
lots of people working on "lightweight" symmetric ciphers. Something like 
"appropriate"?

Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
signature that is secure for a year (or more), it needs one that is secure for 
somewhere between a minute and a week. 

Moreover, one of the ways that we could deal with some of the knock-on issues 
of not wanting DKIM to be a non-repudiation system (the Podesta Problem) is to 
use signatures that could be  forged by someone who put a CPU(s)-week's effort 
into it after the fact.

Even if we never get around to the actual issues, we don't want to cut off 
someone in the future at the knees.

Jon

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Jon Callas]

> On Nov 21, 2022, at 14:01, Dave Crocker  wrote:
> 
> On 11/21/2022 1:56 PM, Murray S. Kucherawy wrote:
>> I don't want to get into implementation discussions before we even have a 
>> charter, but I'm curious about how this could be made effective.
> 
> I'd count it as a simple tool that might have incremental benefit.
> 
> Simply give guidance that an MDA SHOULD remove the DKIM signature, unless 
> there is a local arrangement with the recipient not to.  (Obviously the local 
> detail could swap the default the other way.)
> 
> I would expect anything more elaborate to be in the range of diminishing 
> returns and, therefore, not worth the complexity, effort, etc.

As another original author, it was hard for me to understand what this was 
talking about when the discussion first came up. I even considered replying to 
this thread asking something like, "isn't replay just sending the message 
again?" before I understood.

I really like the guidance that an MDA SHOULD remove a DKIM signature. I have 
memories that we discussed just that even at the time, for a number of reasons.

This is a fine solution to this problem. The replay issue just goes away if the 
header lines are removed.

It also addresses my long-standing complaint that DKIM is not supposed to be a 
tracking and authenticity mechanism. Moreover, this is a much better solution 
to my complaint than anything anyone has come up with, including my eccentric 
foot-stamping about keys.

Lastly, it also addresses the inevitable issue that we aren't thinking of 
today, but five years from now we're going to discover.

Let's just do it. Let's advise to people that they remove the signature in 
their MDA. We don't even need an RFC for it (though we could do one), we just 
need some reasonable implementation.

Jon

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

Re: [Ietf-dkim] DKIM key rotation best practice

[Jon Callas]

> On Aug 6, 2020, at 3:42 PM, Shana Bagherian  
> wrote:
> 
> I was looking over rfc 4871 and emailed Eric who suggested I ask the question 
> of you all on this DL.  So, I was wondering if any of the RCSs related to 
> DKIM list a best practice, or if some other authority has given a best 
> practice, regarding how often the keys should be changed?  It seems that best 
> practice is
> every 6 months, but it would be nice for an authority to state so.  Of 
> course, an acceptable answer is ‘it depends’ upon the security needs to the 
> organization, but is if that is the answer – it depends – is there a minimum 
> time frame for generating new keys?
>  

I apologize for being late to this party. As another of the authors of 4871 -- 
and one who is known to have opinions on key lifetimes -- I feel I should chime 
in.

DKIM protects an email in transit. Once it's been delivered, the 
key/signature's job is complete. Typically, this is a matter of seconds or 
minutes. If retries are needed, most servers stop after four or five days. If 
we wave our hands and say two weeks, that would cover nearly everything.

Moreover, if a DKIM key vanishes, then the receiver is supposed to process it 
like it would without DKIM, and typically that is that the content-based spam 
filtering would kick in. Thus, there's no real need to keep one around for two 
weeks, and if you then made it be thirty days, it's utter overkill.

If I were building an infrastructure for DKIM, my first approximation would be 
that there would be a key per day. I'd have a job make sure that there's a key 
for seven days in the future and delete keys older than 14 days ago. I'd see 
what my stakeholders said. I would object to keeping them around longer than 
fourteen days, but would only argue a little bit about thirty days. I'd be 
adamant it would not be longer than sixty. As Mark Delany pointed out, the Web 
PKI people are replacing keys for TLS every ninety days, and there's utterly no 
reason for longer than that. As Dave Crocker points out, DKIM is not data at 
rest and so it doesn't need anything fancy. 

Summarizing, some job should make sure there are keys for seven days in the 
future, N days in the past, with 14 being a really good value of N, 30 being 
meh, and anything longer than 60 utterly overkill.

An alternate strategy would be a Key Of The Month, and do one month ahead and 
one behind.

Lastly, I'm a huge fan of Michael Specter's paper, and would love it if someone 
implemented that -- it's a better solution to key retirement for DKIM than 
gonzo things I've suggested. It's also not germane to your issue.

Jon

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

[Ietf-dkim] Thinking About DKIM and Surveillance

[Jon Callas]

I know that I've written about this before, so please bear with me a bit. A 
continuing concern of mine is the way that DKIM contributes to overall 
surveillance smog that the Internet has.

When we designed DKIM, this was something we considered; it was a concern. It 
wasn't so big a concern that we thought it should derail DKIM, and it wasn't 
even a concern when it was taken over by the IETF. Nonetheless, it was an 
issue, is an issue, and becomes a bigger issue nearly every day. The most 
notorious failure here is the Podesta email dump, where the stolen emails were 
verified against the DKIM signatures. This is precisely what we didn't want to 
happen -- that DKIM was used for things beyond fighting inauthentic emails. We 
ought to do something, the question is what. 

When I think about how to reduce the tracking and surveillance issues, the 
solution space includes: (1) Better management of the keys (e.g. lifecycle 
management of some sort); (2) Better management of the emails (e.g. strip out 
surveillance-friendly headers in an MDA between the MTA and MUA -- think 
procmail filter that removes information leaks); (3) Better crypto. If I wave 
my magic wand and can cause software to appear and be deployed, I'd do them 
all. None of them are perfect. A crawler that would collect all DKIM keys would 
blunt the benefits of better key management; building and deploying better 
header handling is a huge task; better crypto needs an addendum to the DKIM 
standard.

Nonetheless, I recently came across an interesting article, "KeyForge: 
Mitigating Email Breaches with Forward-Forgeable Signatures". It's on the IACR 
eprint archive at . I think that everyone 
here should look at it. The TL;DR is that they have a signing mechanism that 
blunts attributable signatures and introduces some interesting new concepts. 
They call it, "Delayed universal forgeability." Yes, that's vague, and it's my 
point; consider that an advert for the paper. It's an interesting way to look 
at better crypto that allows for spam-fighting without open-ended tracking.

I don't know that their solution is the answer, but I do know that it's asking 
the right questions. In 2005-7, we were concerned about surveillance smog, but 
we didn't have a good answer (or even consensus, but this was pre-Snowden). The 
stated answer of the day was proper key management of keys, but it's not clear 
that anyone has ever deleted a DKIM key out of DNS. (Okay, I'm exaggerating for 
effect.) They have very good comments about that; I'm not sure I agree, but I 
really like what they're saying. We also briefly considered some sort of ring 
or group signature to blunt attribution. That a mediocre mitigation at best, 
and one of our core goals was to boil the crypto down to essentials, using bare 
keys rather than certs or any other uniforms for the keys. It's DKIM, not DCIM.

I think their signatures take that *intent* -- a mix of math and operation -- 
and creates something really worth considering. Even if it's not the answer, 
the questions that we punted on in 2005 are vital for 2020 and beyond.

Thus, any discussion of it is good. I really liked it. Please read it.

Jon

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