-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At the end of January Dave Crocker posted a review of the then current
"-01" version of draft-gondwana-dkim2-motivation. This document has now
been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over
14 (sorry) emails... ">>" is a quote from our document, ">" a quote from
Dave Crocker ... lines that do not start with a ">" are me speaking.
- -=-=-=-=-=-=-=-=-=-=-=-=-
>> 4. How the aims of DKIM2 are achieved
>>
>> 4.1. Simplification & codification
>>
>> *Issue*:
>>
>> Every DKIM1 signature specifies an explicit list of which email
>> header fields have been signed. This leads to inconsistent signing
>> of headers, and allows a signature to be created in which security-
>> critical headers are not covered.
>
>Rather, it simplified the specification and permitted operational flexibility,
>leaving this particular configuration choice to be specified later, based on
>operational experience and independent community rough consensus. It was not
>clear what the right set would be and it was (and remains) possible that
>different scenarios would benefit from different sets.
>
>In other words, there was no definitive basis for specifying the exact set to
>cover. To my knowledge, there still isn't.
>
> *So the concern, here, is not with something left out of DKIM but
> something left out of community discussion and consensus. Worse,
> there has not been any public discussion that has demonstrated this
> to be a problem.*
>
>One of the problems in the assumption about this item is that DKIM is supposed
>to be 'protecting' data integrity of 'security-critical' header fields. That
>was never a design goal. The design goal was simply a means of affixing an
>accountable domain name.
>
>Data integrity protection is a collateral benefit, given the method used to
>affix the d= domain name.
>
>So the movement to 'protecting security-critical fields' is a major change in
>goals for the mechanism.
>
> *That said, the change does not require a new 'protocol'. *
>
> *It requires a new BCP declaring a signing practice to cover a
> specific set of header fields (and body).*
If all that was being done was to try and improve the list of headers
that people sign then I would agree. But that's not what is happening
here ...
>> To prevent bad actors from adding
>> headers which were not originally present it is common to oversign by
>> signing null versions of headers that are not present. This
>> oversigning may be extended to signing two, for example, Subject
>> header fields because some recipients may not enforce the [RFC5322]
>> requirement of uniqueness.
>>
>> *Mitigation:*
>>
>> DKIM2 will specify a fixed set of headers in accordance with now
>> well-established best practice (and insist they are unique) so there
>> will be no need to list what is signed.
>
>"insist they are unique"
>
>Sigh. Another step in making email a rigid, limited service, based on a
>snapshot in time, with a specific set of uses.
Our current thinking, which will be reflected in documents Real Soon Now
is that we will provide a standard list of header fields that will be
required to be signed by default -- signers can add to this if they
wish. In each case we will sign all instances of a header field that are
present (in the order they occur in the email) -- viz: we will specify
oversigning by default.
The list of header fields is currently
Author
Bcc
Cc
Content-Base
Content-Description
Content-Disposition
Content-Features
Content-ID
Content-Language
Content-Location
Content-Transfer-Encoding
Content-Translation-Type
Content-Type
Disposition-Notification-Options
Disposition-Notification-To
Date
From
In-Reply-To
List-Unsubscribe
List-Unsubscribe-Post
MIME-Version
Reply-To
Require-Recipient-Valid-Since
Sender
Subject
To
we believe that not securing these header fields would enable a bad guy
to take a message and cause it to be processed or displayed or responded
to in a way that the originator of the message did not intend.
Note that all DKIM2-* header fields will also be included
> *Note that this purports to fix a problem, but it isn't one. It's
> ugly, but that's different from being a problem. *
the problem it fixes is that people don't currently sign for all of the
headers I have listed and this affects the security of email
> *So this is a move to make email a lot more rigid, in order to make
> a few folk more comfortable, rather than to fix an actual,
> significant problem.*
in what way ... you can supply any number (from 0 upwards) of any of
these header fields in your message and (provided you get the
modification algebra right) add or remove any number of these headers
you can also put in any other header fields you wish, and you can
declare them to be signed from that "hop" (that i= value) onward
you may not end up with a valid RFC5322 message but that's not
immediately relevant
>> However, some exotic headers may need to be signed for unusual or
>> future use-cases. DKIM2 will allow this with an h= field.
>
>ahhh.
if it is clear that further header fields should be added to the default
list whilst the Working Group is active we should of course do so --
some people seem keen on Expires, for example.
> *So the proposal is not to eliminate listing of fields to be signed,
> but to have a core set of required/default fields and not list them.*
>
>That's quite different from what was being claimed..
>
>It also, again, is solving a non-existent problem.
We've explained what issue it addresses.
It also reduces the size of every (cautious) email by 383 bytes (766 if
the oversigning is not default) ... and there's a carbon footprint issue
here that we should not ignore without careful consideration
This article talks about deleting email, calculations for reducing the
size of billions upon billions of emails per day are left as an exercise
for the reader.
<https://mycarbonfootprint.id/references/358/wow-menarik-ternyata-
menghapus-email-bisa-kurangi-emisi-karbon>
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBZ/l0wWHfC/FfW545EQJz8QCgxZl0BJiFC2iSiHKppihh9eNOJ0IAoJc6
FiFCPHrVKTZudfs6fFZth29Q
=dvzt
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
