On 1 June 2010 10:11, Scott Kitterman <email address hidden> wrote:
> Note that gmail.com's dkim signatures are still marked as for testing
> only.
Specifically it says messages should not be bounced on the basis of
this, and we wouldn't do that. It seems reasonable to assume gmail
will not fail open by suddenly starting to sign messages that didn't
actually come from the named user.
> This kind of application is fundamentally NOT what DKIM was designed to
> do. It is meant to authenticate the domain, not the user.
RFC4870 says
The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today.
...
It is beyond the scope of this specification to describe what actions
a verifier system should make, but an authenticated email presents an
opportunity to a receiving system that unauthenticated email cannot.
Specifically, an authenticated email creates a predictable identifier
by which other decisions can reliably be managed, such as trust and
reputation.
If we back up and look at how Launchpad handles incoming mail: at the
moment a lot of it is just trusted to be from whoever it claims to be
from. In some cases, such as filing a new bug, we judge there is too
much risk that a forged message will cause trouble, so we want a
higher degree of assurance that the message is real. (The message may
be forged either maliciously or because of eg spam or backscatter.)
istm that DKIM will give us an acceptable level of assurance that the
message is authentic.
If a user associates <email address hidden> with their Launchpad account, then
evil.com could send mail falsely claiming to be from Jo. However,
evil.com can also intercept a password reset mail sent to Jo or do
various other attacks, so I don't think this is really a substantial
risk.
There will still be some Launchpad actions such as CoC-signing where
we insist on a GPG key. (Though whether that's actually more secure
is a bit debatable, considering we accept any GPG key uploaded to the
account.)
On 1 June 2010 10:11, Scott Kitterman <email address hidden> wrote:
> Note that gmail.com's dkim signatures are still marked as for testing
> only.
Specifically it says messages should not be bounced on the basis of
this, and we wouldn't do that. It seems reasonable to assume gmail
will not fail open by suddenly starting to sign messages that didn't
actually come from the named user.
> This kind of application is fundamentally NOT what DKIM was designed to
> do. It is meant to authenticate the domain, not the user.
RFC4870 says
The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today.
...
It is beyond the scope of this specification to describe what actions
a verifier system should make, but an authenticated email presents an
opportunity to a receiving system that unauthenticated email cannot.
Specifically, an authenticated email creates a predictable identifier
by which other decisions can reliably be managed, such as trust and
reputation.
If we back up and look at how Launchpad handles incoming mail: at the
moment a lot of it is just trusted to be from whoever it claims to be
from. In some cases, such as filing a new bug, we judge there is too
much risk that a forged message will cause trouble, so we want a
higher degree of assurance that the message is real. (The message may
be forged either maliciously or because of eg spam or backscatter.)
istm that DKIM will give us an acceptable level of assurance that the
message is authentic.
If a user associates <email address hidden> with their Launchpad account, then
evil.com could send mail falsely claiming to be from Jo. However,
evil.com can also intercept a password reset mail sent to Jo or do
various other attacks, so I don't think this is really a substantial
risk.
There will still be some Launchpad actions such as CoC-signing where
we insist on a GPG key. (Though whether that's actually more secure
is a bit debatable, considering we accept any GPG key uploaded to the
account.)
Thanks for your thoughts and feedback. launchpad. net/~mbp/>
--
Martin <http://