On 12/4/2022 7:52 PM, Murray S. Kucherawy wrote:
On Sat, Dec 3, 2022 at 12:20 PM Jon Callas <[email protected]> wrote:
> On Dec 3, 2022, at 11:42, Dave Crocker <[email protected]> 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/
<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:@[email protected]
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
