launchpad development|
Size: 5068
Comment:
|
Size: 5630
Comment: reply jml, notes on dependencies
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 67: | Line 67: |
| * Do we want multiple levels of trust? Probably not; gpg in this context is so much stronger than DKIM that it's worth doing. | * Do we want multiple levels of trust? Probably not: gpg is stronger in theory but not clearly stronger in practice here, because the main weakness seems to be whether the user protects their credentials well, not which mechanism they use. Let's default to keeping it simple. |
| Line 69: | Line 69: |
| * It was a typo: I meant to say 'not so much'. -- [[LaunchpadHome:mbp]] <<DateTime(2010-05-20T20:30:40Z)>> * This doesn't help with cases where Launchpad sends encrypted mail. There is at least one such case, being addition of a new gpg key, but there are not many, so I propose to just ignore it for now. |
|
| Line 87: | Line 90: |
| * We'll need to add a new external dependency on pydkim (or whatever.) | * We'll need to add a new external dependency on pydkim (or whatever.) It is [[http://packages.ubuntu.com/python-dkim|packaged as python-dkim]] in Lucid, at least. |
Talk to the product strategist soon after cutting a first draft of this document
DKIMAuthenticatedMail
Mail with a DKIM signature should be trusted similarly to GPG-signed mail. See bug 316272.
As a developer who uses Launchpad and gmail
I want Launchpad to trust mail from me without demanding a separate GPG signature
so that I can more easily send Launchpad commands to control bugs, reviews, etc
Many mail services now send Domain Keys Identified Mail giving reasonably strong authentication that the mail was sent by the domain it claims to have been sent by. This is typically attached without needing any action by the user.
Rationale
Many of our users (50%?) use gmail, fastmail, yahoo mail, etc. This would make interaction with Launchpad somewhat easier with them.
It is also useful in a negative direction in that we can reject mail that claims to be from a DKIM-authenticated domain but that is not correctly signed. This may eliminate some amount of spam or forgery. (But this does not seem to be a very significant source of spam or abuse at the moment.)
This is not urgent: more like itch-scratching.
However, it may be easy to implement. There is already an IAuthenticatedMail interface in Launchpad, and there is already a pydkim library that tells whether a particular mail is
Stakeholders
- Launchpad users, especially those without GPG integrated into their prefered mail client
- Launchpad/Canonical security specialists (elmo, kees, ...?)
- Launchpad LOSAs (mthaddon?)
- Product strategist (jml)
Constraints
- When DKIM-signed mail is received by Launchpad, it should be treated as authenticated and be able to contain mp votes, bug commands, etc.
- When invalid DKIM mail is received, it should be rejected. (optional)
- Either way, we should log the sender, message-id, and outcome.
- This should be rolled out in a conservative way that does not risk suddenly rejecting or falsely trusting large amounts of mail.
Subfeatures
Deployment steps:
- Just log the results of the check, without taking any other action: date, sender, message-id, dkim outcome
- Let this run for a while and then look at the logs.
- For a subset of users, start treating messages with valid signatures as authenticated and every other case as unauthenticated.
- Do this for all users, and announce it
- For a subset of users, start rejecting messages with invalid signatures, with an explanation of the problem (bearing in mind the message may well have been forged.)
- Ditto globally
Workflows
When Launchpad receives mail, it checks whether it is DKIM-signed. The results of this can be: valid, invalid, or inconclusive, not signed, or internal error.
Success
How will we know when we are done?
Sending mail from gmail to new@bugs.l.n creates a new bug (rather than, as at present, complaining that it's not signed.)
How will we measure how well we have done?
- Graph the number of mails received with good or bad dkim signatures
- Blog about this and hope for positive responses
Thoughts?
Put everything else here. Better out than in.
- Do we want multiple levels of trust? Probably not: gpg is stronger in theory but not clearly stronger in practice here, because the main weakness seems to be whether the user protects their credentials well, not which mechanism they use. Let's default to keeping it simple.
This seems contradictory: "Probably not; gpg is so much stronger that it is worth doing"? -- jml, <<Date(2010-05-20T10:23:14Z)>>
It was a typo: I meant to say 'not so much'. -- mbp 2010-05-20 20:30:40
- This doesn't help with cases where Launchpad sends encrypted mail. There is at least one such case, being addition of a new gpg key, but there are not many, so I propose to just ignore it for now.
- Error messages and help must be set up to mention that both gpg and dkim would be acceptable.
Can we get a list of the templates to change on to this LEP? -- jml, <<Date(2010-05-20T10:23:14Z)>>
It looks like this can hook into authenticateEmail reasonably cleanly.
- There are some interesting cases like when Gmail is letting you send email with the From address in a non-gmail domain. It may be reasonable to check the launchpad Person has both addresses associated with their account.
gmail signs both the sender (foo@gmail.com) and from (foo@example.com) fields
- What if the DKIM is invalid but there's a valid GPG signature or vice versa?
- This may increase pressure to sign outgoing mail from Canonical/Launchpad.
- DKIM relies on DNS to fetch server public keys; it could be spoofed by a determined DNS attack.
- I'm assuming this will not create substantial additional server load: another hash and a DNS lookup should be cheap compared to a gpg check.
We'll need to add a new external dependency on pydkim (or whatever.) It is packaged as python-dkim in Lucid, at least.
