-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
>Richard, the question is not frequency of exploitation, it's whether the
>protocol regresses in security coverage relative to current practice.
>And a protocol that leaves a vector open is not justified by the
>observation that few are using it.
You claim there is a vector
You said that X-Spam-Status and X-Spam-Score were such a vector and that
spammers knew this and exploited it today "routinely". My data shows
that this is not the case.
So what other vector is there ?? because I do not believe that there is
any significant reliance on the security properties of X- header fields
placed into a message by organisations other than your own (and I see
that you do not sign any of the plethora of X- header fields in your own
message, either in DKIM1 or your own scheme).
>Header recipes declare voluntary modifications. An attacker injecting a
>forged X-Original-Sender will not declare it in a recipe.
so I should hope... though I don't think the text for validation
currently covers that. Perhaps it should
>Google Groups signs X-Original-Sender in its DKIM1 h= tag today.
yes, and when they add DKIM2 header fields they will provide the same
data in another, standardised and reliable manner (also are you sure
that it is the Sender: header field that they report?)
> The
>current DKIM2 blanket exclusion would remove that protection. That is a
>measurable regression, not speculation.
you are speculating .. or can you tell me what the security properties
are (to others: bonus points for a URL of the documentation) of
X-LinkedIn-Template
X-LinkedIn-fbl
X-LinkedIn-Class
X-Mailer-LID
X-Mailer-RecptId
X-Mailer-SID
X-Mailer-Sent-By
X-MC-User
X-MS-Exchange-AntiSpam-MessageData-ChunkCount
X-MS-Exchange-AntiSpam-MessageData-0
X-MS-Exchange-AntiSpam-MessageData-1
X-MS-Exchange-SenderADCheck
X-PHP-Originating-Script
which I find (look real data again) have been DKIM1 signed by somebody
or other in recent email to my site
>The X-* namespace is too broad and too varied in its security
>implications to be dismissed with a single statistic on two specific
>headers.
The X-* namespace has no security implications outside of the
organisations that add the headers and these organisations will use
transport information or their own crypto to ensure that the header
fields are trustworthy if they encounter them.
If it turns out down the line that X-Aardvark: does have security
properties the site can change it to Y-Aardvark: (or Aardvark:) and
immediately benefit from DKIM2 authentication. They may of course have
to keep track and provide recipes ... and it was to avoid the complexity
of that keeping track for organisations that do use X- extensively (see
my list above to see who they might be) that X- is being excluded in the
first place.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaiIHTGHfC/FfW545EQLwHwCgxyrnfu+RBPe0sVKQMIJeY48UjTAAoKZP
YZ1bc4jNMJ/fS77LJnk44U+I
=luC3
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
