Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/4/2022 7:52 PM, Murray S. Kucherawy wrote:

On Sat, Dec 3, 2022 at 12:20 PM Jon Callas  wrote:

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


I've edited in this change, minus "transit-time".  I acknowledge that 
this is what Jon and Dave are saying was the intent all along, and I'm 
not arguing the point, but RFC 4686 -- which presumably recorded what 
was our consensus at the time, and which RFC 6376 references as 
foundational material -- disagrees, holding out an additional 
possibility that no DKIM document since then has dispelled.  I don't 
think we should ignore this conflict; I think it's important to 
resolve and record that resolution, and this revised perspective can 
be part of the document(s) this working group produces.



I'll start by noting that, other than Jon Callas, I haven't seen other 
support for the view I'm espousing.  So my response here is more a 
matter of due diligence than in an expectation of swaying the group's 
decisions.


DKIM was developed to facilitate delivery handling decisions. The 
language in the RFC 4871 and RFC 6376 doesn't make this as explicit as 
I'd wish, given the perspective I'm advocating, but it's got some 
implicating language.  References to validation by MTAs or MDAs 
obviously has to do with transit or delivery, and not after.  Reference 
to MUAs might imply long-term term.  Or not. Certainly there is no 
discussion about long-term use of the signature.


It's probably worth noting that the RFC examples, in Sec tion A.3 says 
"The signature is normally verified by an inbound SMTP server or 
possibly the final delivery agent." And Section B.2 is similarly limited 
to delivery-related use of DKIM.


Further, the semantics about the signature are:  "permits a person, 
role, or organization to claim some responsibility for a message" which 
is quite far from claims of authorship, or the like.  Not to deny the 
fact of forensic use of DKIM, but a serious intention to have DKIM be 
used for longer-term validations would (or at least should) have 
attended to its requirements explicitly.


I don't see either RFC clearly "disagreeing" with the view that DKIM is 
for transit-related work.  That's contrary to Murray's assessment.  But 
again, the RFC doesn't make that limitation clear (enough, IMO), either.


So much for the specification's position on transit vs. later. Now we 
have some operational realities.


Retaining the signature facilitates replay.  Arguments about how easy it 
is to move reception to a friendlier site, closing off less friendly 
sites is like closing off open SMTP relays.  It can be circumvented, but 
is still worth doing.


There is a nice article detailing the problems of using DKIM for 
longer-term forensic purposes and even suggesting defeating that use by 
publishing the private keys:


   blog.cryptographyengineering.com

   Ok Google: please publish your DKIM secret keys <#>

   The Internet is a dangerous place in the best of times. Sometimes
   Internet engineers find ways to mitigate the worst of these threats,
   and sometimes they fail. Every now and then, however, a major …

   🔗
   
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/
   



Lastly, a current working group is working from current realities.  If 
specifications written some time ago are either not clear about and 
issue or have become problematic in the face of current use, it is not 
unreasonable for a current working group to fix things.  In fact, that's 
it's job.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] not removing signatures

[Michael Thomas]

On 12/6/22 3:22 PM, mikespec...@gmail.com wrote:
That's not true in all cases. Spam and phishing slips through 
filters, etc, regularly and doing forensics may happen well past 
delivery windows. Part of DKIM is a "blame me" mechanism. If you 
remove the signature how do they know they are actually responsible?


Perhaps the domain can keep the signatures separate, just not when 
sent out to the MUA. Or we can figure out something more creative.


. And even if you remove the signature, there is a lot of other 
evidence that a leaked email provides. DKIM with Her Emails made a 
pretty watertight case that they were real, but even without it it 
would have been really hard to disclaim them, especially if people 
get access to the receiving domain's logs in a legal setting.


Not all versions of adversarial attribution are done publicly or in a 
legal setting, and journalistic authentication is always possible. 
This is materially different than not offering any protection to users 
at all, and offering authenticated proof of private communications. A 
user may be able to disclaim specific messages, for example, even if 
others appear to be correct (“that message was modified!”)


I (and others) wrote a usenix paper on the subject. Perhaps taking a 
look at the paper’s motivation will be helpful in understanding our 
complaint with how DKIM works now: 
https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge



Frankly using Her Emails as a motivation to do something is rather 
pointless. The valid DKIM signature was icing on the cake. The cake 
would have been eaten with our without it though. Nobody actually cared 
about whether it could standup in court or not. Even I for years didn't 
know that DKIM was part of the picture but it really didn't matter one 
way or the other whether I thought they were legit or not.


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

Re: [Ietf-dkim] not removing signatures

[mikespecter]

> That's not true in all cases. Spam and phishing slips through filters, etc, 
> regularly and doing forensics may happen well past delivery windows. Part of 
> DKIM is a "blame me" mechanism. If you remove the signature how do they know 
> they are actually responsible?

Perhaps the domain can keep the signatures separate, just not when sent out to 
the MUA. Or we can figure out something more creative. 

> . And even if you remove the signature, there is a lot of other evidence that 
> a leaked email provides. DKIM with Her Emails made a pretty watertight case 
> that they were real, but even without it it would have been really hard to 
> disclaim them, especially if people get access to the receiving domain's logs 
> in a legal setting.

Not all versions of adversarial attribution are done publicly or in a legal 
setting, and journalistic authentication is always possible. This is materially 
different than not offering any protection to users at all, and offering 
authenticated proof of private communications. A user may be able to disclaim 
specific messages, for example, even if others appear to be correct (“that 
message was modified!”)

I (and others) wrote a usenix paper on the subject. Perhaps taking a look at 
the paper’s motivation will be helpful in understanding our complaint with how 
DKIM works now: 
https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge

==Mike

> On Dec 6, 2022, at 2:50 PM, Michael Thomas  wrote:
> 
> 
>> On 12/6/22 2:33 PM, Jon Callas wrote:
>> 
 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.
> Yes, imagine my surprise when I found out about Her Emails only about a year 
> ago. But that isn't the only use of forensics.
>> 
>> 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.
> That's not true in all cases. Spam and phishing slips through filters, etc, 
> regularly and doing forensics may happen well past delivery windows. Part of 
> DKIM is a "blame me" mechanism. If you remove the signature how do they know 
> they are actually responsible? Or how do you complain to their upstream 
> provider without proof that it actually came from their customers? Especially 
> when it's not in their interest to accept blame. And even if you remove the 
> signature, there is a lot of other evidence that a leaked email provides. 
> DKIM with Her Emails made a pretty watertight case that they were real, but 
> even without it it would have been really hard to disclaim them, especially 
> if people get access to the receiving domain's logs in a legal setting.
> 
> Mike
> 
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] not removing signatures

[Michael Thomas]

On 12/6/22 2:33 PM, Jon Callas wrote:



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.
Yes, imagine my surprise when I found out about Her Emails only about a 
year ago. But that isn't the only use of forensics.


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.
That's not true in all cases. Spam and phishing slips through filters, 
etc, regularly and doing forensics may happen well past delivery 
windows. Part of DKIM is a "blame me" mechanism. If you remove the 
signature how do they know they are actually responsible? Or how do you 
complain to their upstream provider without proof that it actually came 
from their customers? Especially when it's not in their interest to 
accept blame. And even if you remove the signature, there is a lot of 
other evidence that a leaked email provides. DKIM with Her Emails made a 
pretty watertight case that they were real, but even without it it would 
have been really hard to disclaim them, especially if people get access 
to the receiving domain's logs in a legal setting.


Mike

___
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] not removing signatures

[Michael Thomas]

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.


Mike

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

Re: [Ietf-dkim] not removing signatures

[mikespecter]

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. 

==Mike

> On Dec 6, 2022, at 12:11 PM, Michael Thomas  wrote:
> 
> 
> Murray wrote:
> 
> >> Post-delivery survival of the signature is not only not a goal, it is
> >> arguably (or possibly demonstrably) a problem.
> 
> 
> > Can we say more about this if we're going to take that position?  A naked
> > "not a goal" doesn't jive with RFC 4686, which explicitly says it is a
> > goal, or at least that it was one.
> 
> > I guess that means it comes down to making an argument about what
> > experience has shown us: Does Barry's use case, plus the Thunderbird
> > plug-in use case, together carry more weight than the perceived problem
> > that replay causes?
> 
> > Also, a reminder that the WG hasn't actually rechartered yet; maybe some of
> > these debates should wait until that's happened.
> 
> 
> I completely disagree with the notion that signatures should be removed. I 
> don't recall it ever being discussed one way or the other, so saying that it 
> is "not a goal" is just a bald assertion. Having the signature survive has 
> forensic value, for better or worse. Yes, and there is "for better" too. Not 
> to mention that MUA's have a stake in this too. Nothing requires MDA's to 
> create an Auth-Res header, for example. Plus there is information in the 
> signature header that can be useful for MUA's.  
> 
> Also: this is clearly BCP material that everybody is free to ignore. There 
> are no interoperability considerations.
> 
> This working group should go back to sleep.
> 
> Mike
> 
> ___
> 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

[Ietf-dkim] Problem Statement

[Michael Thomas]

I think that any charter should specifically call out the need for a 
problem statement. The problem is far more nuanced than the few lines in 
the proposed charter and I think that the charter should be neutral 
about whether the problem can be solved because that isn't clear at all. 
Doing something to do something is how the ARC abomination came about, 
and we don't need to repeat that kind of  behavior.


In particular it needs to lay out the problems caused by the specific 
use case and how they overlap with legitimate use cases, and how 
complete that overlap is. It should also explore if there are ways to 
mitigate it with tools other than DKIM. Like for example, why is the 
sending domain signing spam in the first place?


That should be the only deliverable from the wg along with an evaluation 
of whether the problem is tractable. If it is tractable, the wg should 
recharter with a plan of how to implement it.


Mike

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

[Ietf-dkim] not removing signatures

[Michael Thomas]

Murray wrote:


Post-delivery survival of the signature is not only not a goal, it is
arguably (or possibly demonstrably) a problem.




Can we say more about this if we're going to take that position?  A naked
"not a goal" doesn't jive with RFC 4686, which explicitly says it is a
goal, or at least that it was one.



I guess that means it comes down to making an argument about what
experience has shown us: Does Barry's use case, plus the Thunderbird
plug-in use case, together carry more weight than the perceived problem
that replay causes?



Also, a reminder that the WG hasn't actually rechartered yet; maybe some of
these debates should wait until that's happened.



I completely disagree with the notion that signatures should be removed. 
I don't recall it ever being discussed one way or the other, so saying 
that it is "not a goal" is just a bald assertion. Having the signature 
survive has forensic value, for better or worse. Yes, and there is "for 
better" too. Not to mention that MUA's have a stake in this too. Nothing 
requires MDA's to create an Auth-Res header, for example. Plus there is 
information in the signature header that can be useful for MUA's.


Also: this is clearly BCP material that everybody is free to ignore. 
There are no interoperability considerations.


This working group should go back to sleep.

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