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
