Feature #14977: Improve OpenPGP instructions based on Cody's and jaster's feedback

Feature #14977

Improve OpenPGP instructions based on Cody's and jaster's feedback

Added by sajolida 2017-11-17 15:14:40 . Updated 2018-03-02 17:16:58 .

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Installation

Target version:

Tails_3.6

Start date:

2017-11-17

Due date:

% Done:

Feature Branch:

web/14977-improve-openpgp-instructions

Type of work:

End-user documentation

Blueprint:

Starter:

Affected tool:

Installation Assistant

Deliverable for:

Description

Files

OpenPGP_2_jaster.pdf (295678 B)

sajolida, 2017-11-26 18:27:02

Subtasks

Related issues

Related to Tails - ~~Bug #14967~~: Informations about notification are outdated in "Download and verify using OpenPGP"	Resolved	2017-11-15
Related to Tails - Bug #13634: explain somewhere that in some cases the signing key may have to be updated	Confirmed	2017-08-15
Related to Tails - ~~Bug #11785~~: Users get confused by the particularities of the Tails signing key	Rejected	2016-09-08

History

#1 Updated by sajolida 2017-11-17 15:16:37

Subject changed from Improve OpenPGP instructions based on Cody's and jaster's feedback to Improve OpenPGP instructions based on jaster's feedback

#2 Updated by sajolida 2017-11-17 15:16:46

Description updated

#3 Updated by sajolida 2017-11-17 18:46:18

Subject changed from Improve OpenPGP instructions based on jaster's feedback to Improve OpenPGP instructions based on Cody's and jaster's feedback

See ~~Feature #14630#note-17~~:

>> Verifying using OpenPGP but without authenticating our signing key through the OpenPGP Web of Trust is equivalent in terms of security to verifying using our browser extension or BitTorrent because it relies on downloading a genuine signing key from our website.

> I’m going to try to clean that up. That’s a lot of words in one sentence.

>> Authenticating our signing key through the OpenPGP Web of Trust is the only verification technique that can protect you in case our website is compromised. It is also the most complicated technique and might not be possible for everyone to perform because it relies on trust relationships between individuals.

> These sentences seem to suggest that authenticating the Tails signing key is a verification technique, which it isn’t. I propose to rewrite these sentences as follows: “Authenticating our signing key through the OpenPGP Web of Trust is the only way you can be protected in case our website is compromised. However, it is complicated to do this and it might not be possible for everyone because it relies on trust relationships between individuals.”

#4 Updated by cbrownstein 2017-11-26 09:17:19

Status changed from Confirmed to In Progress
Assignee changed from sajolida to cbrownstein

#5 Updated by sajolida 2017-11-26 18:27:05

File OpenPGP_2_jaster.pdf added

Also from ~~Feature #14630#note-20~~ by spriver:

> Verifying with OpenPGP:
>
> we don’t tell users that the necessary tools (GPG4Win/GPGTools) have to be installed first. Maybe this explanation is not needed, as verifying via OpenPGP is for more skilled persons (perhaps we should mark it then as a verification method for skilled users who understand what a OpenPGP signature, etc. is).
>
> the screenshot verifying_in_tails.png does not comply with our screenshot guidelines (https://tails.boum.org/contribute/how/documentation/guidelines/#index5h1).

I’m attaching the comments from jaster that I’m referring to in the title.

#6 Updated by cbrownstein 2017-12-05 04:54:10

related to ~~Bug #14967~~: Informations about notification are outdated in "Download and verify using OpenPGP" added

#7 Updated by cbrownstein 2017-12-06 01:32:55

As jaster notes, “Verify the date of the signature to make sure that you downloaded the latest version” is ambiguous. How is the user to know that they’ve downloaded the “latest version”? And, the latest version of what? The ISO? The signature?

I propose to eliminate the sentence entirely. Verification will fail if the sig is for an older ISO. Likewise, verification will fail if the sig is for a newer ISO. Moreover, the purpose of verification isn’t to ensure that the user has downloaded the latest version of Tails.

#8 Updated by sajolida 2017-12-14 16:46:42

This sentence is here to prevent downgrade attacks. Imagine that someone is able to provide you with an ISO image and an OpenPGP signature of an older Tails version that has known security issues. You would then verify that old version with known security issues and install it.

The date is the only way to make sure that you really have the latest version.

We already have an include file with the date of the current release: https://tails.boum.org/inc/stable_amd64_date/. But the date of the OpenPGP signature might not be the same as it’s usually created a few days earlier.

We could either:

Ask the release managers to always create the signature on the day of the release. Doing so might force them to sign it twice (the testers need the ISO image before publication).
Have a second include file for the date of the OpenPGP signature.
Find another formulation that doesn’t ask more work to the release managers but still protects users from downgrade attacks.

NB1: I didn’t see you question earlier because the ticket is still assigned to you. If you want answers from me assign it to me and mark it as “Info Needed”.
NB2: This is pretty clearly out of scope regarding ~~Bug #12328~~ :)

#9 Updated by cbrownstein 2018-01-02 01:46:44

Assignee changed from cbrownstein to sajolida
QA Check set to Ready for QA

https://github.com/cbrownstein/tails/tree/web/14977-improve-openpgp-instructions

> Verifying using OpenPGP but without authenticating our signing key through the OpenPGP Web of Trust is equivalent in terms of security to verifying using our browser extension or BitTorrent because it relies on downloading a genuine signing key from our website.

I’ve changed that sentence to:

You can verify using OpenPGP without first authenticating our signing key through the OpenPGP Web of Trust. But, if you do not first authenticate our signing key, the verification will be no better than verifying using our browser extension or BitTorrent. This is because you are still relying on information (our key) being securely downloaded using HTTPS from our website.

> Authenticating our signing key through the OpenPGP Web of Trust is the only verification technique that can protect you in case our website is compromised. It is also the most complicated technique and might not be possible for everyone to perform because it relies on trust relationships between individuals.

I’ve changed that to:

Authenticating our signing key through the OpenPGP Web of Trust is the only way that you can be protected in case our website is compromised. However, it is complicated to do and it might not be possible for everyone because it relies on trust relationships between individuals.

We still need to address the “latest version” issue pointed out by jaster.

(Thank you for the education on downgrade attacks, by the way!) :-)

#10 Updated by Anonymous 2018-01-17 11:39:01

related to Bug #13634: explain somewhere that in some cases the signing key may have to be updated added

#11 Updated by sajolida 2018-01-17 22:25:26

Assignee changed from sajolida to cbrownstein
Feature Branch set to web/14977-improve-openpgp-instructions

Thanks for all your little fixes!

I pushed something to solve the issues around the date without much work. Please review 5ac181abfc.

#12 Updated by cbrownstein 2018-01-18 00:42:45

Assignee changed from cbrownstein to sajolida
QA Check changed from Ready for QA to Pass

Looks good!

#13 Updated by intrigeri 2018-01-18 11:35:07

sajolida wrote:
> * Ask the release managers to always create the signature on the day of the release. Doing so might force them to sign it twice (the testers need the ISO image before publication).

I think this would conflict with the design we came up with to integrate reproducible builds verification in our release process.

Elsewhere we’ve been asked if saying “at most three days earlier” is OK. I seem to remember I’ve sometimes built the ISO on Saturday morning so if the publication happens a bit late it could be more than 3 days (or at least look like it in some timezones). The best way to be sure would be to check the actual historical data that we have in Git (tails.git for the signatures + internal.git for the release date) but I assume you’ve already dismissed this option.

Anyhow, I guess that writing “5 days” instead should work all the time and limit the scope of downgrade attacks enough. It’s kinda funny that we protect against downgrade attacks the users who use our Verification Extension better than those who insist on OpenPGP :)