On Tue 2015-03-03 21:01:55 +0100, intrigeri wrote: > [@dkg: I know you read the last, but in this email there's one > question for you, and I would be sad if you missed it, so Cc'ing you > explicitly. Look for your handle below.]
thanks for the explicit callout, this thread has been mostly off my radar, and i might not have noticed it otherwise. > * we could advise users to set up something to automatically refresh > they GnuPG keyring (the OpenPGP best practices has several > suggestions iirc, and not just parcimonie). This addresses the > revocation handling problem you're mentioning in the "About the > removal of Seahorse Nautilus" section. This sounds like it makes a lot of sense. I wish this kind of action was more trivially accessible via gpg itself, or some other common wrapper. > * ... and then, we could also advise them *not* to import our signing > key if they've already done it in the past, which gives them "TOFU > done right". For key rollover, this can be handled with a blog post > and transition statement. I suspect for most new users, the validation process is complex and foreign enough that they don't understand which parts need to be done only once ever, and which parts need to be done at each download. I don't have a good recommendation of how to improve this situation, because by definition they're using some O/S that we don't know about and can't control. Maybe there are ways that we could leverage Microsoft or Apple's built-in CAs somehow to provide certified ISOs on those platforms using the same identity, but "certified" by MS or Apple's pre-trusted roots? I don't really know what kinds of mechanisms exist for that, though. a bit of digging turns up some pretty silly UI for Apple's code signing (which isn't something we can use directly anyway, but probably should be better-protected than expecting users to notice a lock in the upper-right of the taskbar: http://support.apple.com/en-us/HT202369 >> When the user clicks on the HTTP download button from the download >> page, we propose to install the extension. This seems like it's just moving the goalposts from verifying the ISO to verifying the extension; and given that extensions themselves can be tampered with by other extensions, it seems like it *could* raise issues. Though otoh we're expecting users to install gnupg on their systems to verify anyway, and doing that wrong (or fetching the wrong binaries) could result in even worse outcomes. > I guess this means that JavaScript will be needed on our download > page, so that we can detect if the extension is already installed, as > you note in the open questions below. I agree with Giorgio that it seems like this shouldn't require javascript if the extension is clever enough and the placement of the warning/recommendation is sensible but not overwhelming. Note that some browsers won't be able to install any extension we're likely to ship (e.g. IE or Safari), so direct download does still need to be supported. >> * The extension checks the size of the download to verify that the >> download was complete. >> * If the download was complete, the extension verifies the >> ISO image. > > (Just curious, since it's cheap:) The idea is to provide different > feedback on failure, depending on whether the download wasn't complete > or corrupted, right? > >> tails-i386-x.x.x-VERIFIED.iso if the verification is successfully. > > I find it a bit surprising that a verified ISO hasn't its canonical > name in the end, given we call it differently otherwise. But well, you > have read more about UX than I did. Perhaps the reasons behind this > design decision could be explained on the blueprint so that I, or > someone else, doesn't propose to change that again in a year ;) fwiw, i share intrigeri's intuitions on both points above, here. I wouldn't object to the name change, if it's backed up by a plausible-sounding argument, but my instincts suggest that changing the name of the file may well confuse people (how many guides out there mention the tails ISO without the "-VERIFIED" string? how does the name change help (e.g. if an attacker gets between the user and the server, couldn't it just ship the "-VERIFIED" name in the first place via HTTP 302 reidirect or something similar) >> (B) Do a man-in-the-middle attack by providing a rogue HTTPS >> certificate for https://tails.boum.org/ signed by a certificate >> authority trusted by the browser but under the control of >> the attacker. > > This feels outdated (or the other way round), since the "Checksum > verification" section says we'll be doing CA pinning. Please clarify. if you want to do pinning, you can start doing it now. fwiw, i don't actually recommend CA pinning, i recommend end-entity pubkey pinning using HPKP. You can introduce this basically any time (once you've done a bit of operational planning to ensure you don't shoot yourself in the foot), and you can even get it included upstream in the baked-in HPKP lists. If you have questions about how to do this operationally and what the best strategy is, i'd be happy to talk further with you about it. For something like tails.boum.org, i recommend making two backup end-entity keys on an offline machine, and pinning to your active key + these two others. > Explicitly Cc'ing dkg who'll surely can correct me or make our rough > understanding of these things clearer, and add the details > I'm missing. dkg, this is about: > > https://tails.boum.org/blueprint/bootstrapping/extension/ > https://labs.riseup.net/code/issues/8931 I need to think a bit more about this whole proposal. I don't know enough about what kind of scope an extension can have -- for example, can it dig around in your Downloads folder? can it find things that were torrented and placed elsewhere on disk? Do you plan to ship gpgv.exe (e.g. from debian's gpgv-win32 package) or do you plan to do the OpenPGP signature verification via something like OpenPGP.js? I'm assuming that you plan to ship the signing key in the extension as well. How do the extensions get updated, if you need to change either the signing key or the code/ui/etc? Can the extension itself check for its own updates? I'm assuming y'all are aware of the recent change in mozilla policy that they're only going to allow addons that were signed by addons.mozilla.org: https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/ Is that something that's OK for your expectations for the tails extension? --dkg _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
