Fix sentance structure, include reference to Cappos et al work and the existing signed HTTP snapshots.

1 files changed, 23 insertions, 9 deletions

diff --git a/users/robbat2/tree-signing-gleps/00-proposal-overview b/users/robbat2/tree-signing-gleps/00-proposal-overview
index 98834a8b01..9c27b2bd9b 100644
--- a/users/robbat2/tree-signing-gleps/00-proposal-overview
+++ b/users/robbat2/tree-signing-gleps/00-proposal-overview
@@ -1,11 +1,7 @@
-TODO: 
-- Add mention of signed HTTP snapshots from 01
-- Add replay attacks from Cappos et al.
-
 GLEP: xx
 Title: Security of distribution of Gentoo software - Overview
-Version: $Revision: 1.10 $
-Last-Modified: $Date: 2008/07/13 06:45:03 $
+Version: $Revision: 1.11 $
+Last-Modified: $Date: 2008/10/09 21:33:53 $
 Author: Robin Hugh Johnson <robbat2@gentoo.org>
 Status: Draft
 Type: Informational
@@ -96,8 +92,8 @@ are not maintained by Gentoo Infrastructure.
 Attacks may be conducted against any of these entities. Obviously
 direct attacks against Upstream and Users are outside of the scope of
 this series of GLEPs as they are not in any way controlled or
-controllable by Gentoo - however attacks using Gentoo as a conduit (such
-as adding a payload at a mirror) must be considered.
+controllable by Gentoo - however attacks using Gentoo as a conduit
+(including malicous mirrors) must be considered.
 
 Processes
 ---------
@@ -141,6 +137,11 @@ by syncing from one of the community-provided mirrors. We will show that
 protection against this class of attacks is very easy to implement with
 little added cost. 
 
+At the level of mirrors, addition of malicious content is not the only
+attack. As discussed by Cappos et al [C08a,C08b], an attacker may use
+exclusion and replay attacks, possibly only on a specific subset of
+user to extend the window of opportunity on another exploit.
+
 Security for Processes
 ------------------------
 Protection for process #1 can never be complete (without major
@@ -165,7 +166,9 @@ objective is actually much closer than it seems already - most of the
 work has been completed for other things!. This is further discussed in
 [GLEPxx+1]. As this process has the most to gain in security, and the
 most immediate impact, it should be implemented before or at the same
-time as any changes to process #1.
+time as any changes to process #1. Security at this layer is already
+available in the signed daily snapshots, but we can extend it to cover
+the rsync mirrors as well.
 
 Requirements pertaining to and management of keys (OpenPGP or otherwise)
 is an issue that affects both processes, and is broken out into a
@@ -291,6 +294,17 @@ spelling, grammar, research (esp. tracking down every possible
 vulnerability that has been mentioned in past discussions, and
 integrating them in this overview).
 
+==========
+References
+==========
+
+[C08a] Cappos, J et al. (2008). "Package Management Security".
+    University of Arizona Technical Report TR08-02. Available online
+    from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf
+[C08b] Cappos, J et al. (2008). "Attacks on Package Managers"
+    Available online at:
+    http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
+
 Copyright
 =========
 Copyright (c) 2006 by Robin Hugh Johnson. This material may be