Re: [Tails-dev] Incremental upgrades: first draft to review
05/23/2012 04:18 PM, intrigeri: Hi, The design draft has been significantly reworked since then. A security discussion was written. Please review. I have reviewed the complete draft. I completely buy your argument regarding its security guarantees: We believe the update system described on this page is at least as secure as the old Tails update system. That's good enough for me, and hopefully it can be improved further with TUF/Thandy integration once they are in a good enough state. The IUK and update-description formats seem flexible enough to allow any kind of future update imaginable. All in all it looks great. Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Incremental upgrades: first draft to review
Hi, The design draft has been significantly reworked since then. A security discussion was written. Please review. See bellow answers to the questions and remarks Robert sent us a while ago. Robert Ransom wrote (02 May 2012 17:27:12 GMT) : *Everything* which the update downloader needs to authenticate must be in the *contents* of the file whose signature is checked. Currently, an update's product name, build target, and intended update channel are not authenticated. You must include the *hashes* of other files which are part of the update in the file whose signature is checked. Verifying that other files have, at some point in the past, been signed as a component of an update is not enough to verify that those other files are part of the update you want users to install. Thanks a lot. I think the current design draft fixes this. * questions to refine the idea, the requirements, whatever difficulty I may have missed... Include the specific command line that you plan to use to verify the signature on an update-description document. Please see the new signature verification paragraph (this is 5.3.f at the time I am writing). Specify terms/phrases to be used to describe (a) the YAML file that describes the update, (b) the whole set of files included by reference into an update, and (c) any file included by reference into an update, and stick with those terms/phrases. Done. (This is section 2 at the time I am writing.) Now come the signature verification tests you suggested. Note that I have run the signature verification tests against full-blown gpg, not gpgv, since GnuPG::Interface wraps the former, not the latter, and they have incompatible interfaces. If there are significant advantages in doing so, it is doable to point G::I at a wrapper that runs gpgv and exposes gpg's --verify syntax, though. Thinking how these results mix with our current time syncing system is left to be done. How does gpgv react when the system clock is set to before the time at which the signature claims to have been produced? amnesia@amnesia:~$ gpg --verify bla.asc bla gpg: Signature made Fri 04 May 2012 12:09:45 PM UTC using RSA key ID C77B4F91 gpg: Good signature from sdfsdfs s...@dsffs.com amnesia@amnesia:~$ echo $? 0 How does gpgv react when the system clock is set to before the time at which the signature-verification key claims to have been produced, amnesia@amnesia:~$ gpg --verify bla.asc bla gpg: Signature made Fri 04 May 2012 12:09:45 PM UTC using RSA key ID C77B4F91 gpg: key C77B4F91 was created 384178991 seconds in the future (time warp or clock problem) gpg: key C77B4F91 was created 384178991 seconds in the future (time warp or clock problem) gpg: key C77B4F91 was created 384178991 seconds in the future (time warp or clock problem) gpg: Can't check signature: timestamp conflict amnesia@amnesia:~$ echo $? 2 or after it is set to expire? amnesia@amnesia:~$ gpg --verify bla.asc bla gpg: Signature made Fri 04 May 2012 12:09:45 PM UTC using RSA key ID C77B4F91 gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Good signature from sdfsdfs s...@dsffs.com gpg: Note: This key has expired! Primary key fingerprint: F780 5DA6 39FB 05D2 C403 1500 0F9C 869C C77B 4F91 amnesia@amnesia:~$ echo $? 0 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Incremental upgrades: first draft to review
Hi, please review https://tails.boum.org/todo/incremental_upgrades/ I'm particularly interested in: * your thoughts about the general idea and process as described there * questions to refine the idea, the requirements, whatever difficulty I may have missed... * your thoughts about 3.1.c. Updates files -- this work-in-progress may be slightly over-engineered, but the potential future benefits seem big to me compared to the added complexity. What do you think? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Incremental upgrades: first draft to review
On 5/2/12, intrigeri intrig...@boum.org wrote: Hi, please review https://tails.boum.org/todo/incremental_upgrades/ I'm particularly interested in: * your thoughts about the general idea and process as described there *Everything* which the update downloader needs to authenticate must be in the *contents* of the file whose signature is checked. Currently, an update's product name, build target, and intended update channel are not authenticated. You must include the *hashes* of other files which are part of the update in the file whose signature is checked. Verifying that other files have, at some point in the past, been signed as a component of an update is not enough to verify that those other files are part of the update you want users to install. * questions to refine the idea, the requirements, whatever difficulty I may have missed... Include the specific command line that you plan to use to verify the signature on an update-description document. Specify terms/phrases to be used to describe (a) the YAML file that describes the update, (b) the whole set of files included by reference into an update, and (c) any file included by reference into an update, and stick with those terms/phrases. How does gpgv react when the system clock is set to before the time at which the signature claims to have been produced? How does gpgv react when the system clock is set to before the time at which the signature-verification key claims to have been produced, or after it is set to expire? Have you read the Thandy spec and the TUF paper? * your thoughts about 3.1.c. Updates files -- this work-in-progress may be slightly over-engineered, but the potential future benefits seem big to me compared to the added complexity. What do you think? It turned out to be under-engineered -- see above. Robert Ransom ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
