On Thu, Aug 17, 2017 at 09:11:08PM +0200, Julian Andres Klode wrote: > A new Release file key, called Key-Revocation-List is added. This > field contains a http(s) URL (and https URIs has its advantages, > but some users do not want to enable the TLS stack, so it probably > has to be http-only in practice). [Sidenote: The fields containing URL should perhaps be made multiline with each line giving a different source for the same content, so that we could mention https, http and gopher here and apt (& user) would pick the right one based on config and installed methods (+ allowing user to route e.g. http(s) requests via another method like tor+http(s))] > # How to use it > Before updating a repository, we first update our copy of the > revocation key file URL. So, that works only if you have an old Release file around mentioning the URL, not for bootstraps and similar? And where is this URL located? I guess it is not in the same repository aka not on the same mirror, which means we have problems with proxy configurations and perhaps more importantly (for some at least) introduce a central service which could be considered phoning home (as you can't use a mirror). Lastly, you say the Revocation list includes its own Valid-Until – that can only really work if the key is online to resign frequently or a MITM could block the check by serving an old list? > When fetching the release file of a repository, we consult the KRL KRL > KRL file and ignore any valid signature for any subkey listed > in the KRL file. What about the time between "key compromise" and "revocation pusblished"? It looks for me as if all the attacker must do is using the key to generate a Release file without a Key-Revocation-List (or with a changed one) before the revocation is published and be happy just as before. We could go with a "hey, that field changed, are you sure?" but that seems rather technical for a user – and could get funny if the sidenote from me above is followed and some sources are added/removed as adding e.g. httpss¹ could be perfectly legit or an attacker-controlled now potentially preferred source with different content. ##### How about having a key revocation list be part of a "normal" repository, but so that every repository can distribute revocations for any other repository. So that Debian, Debian-Security and Davids-Playground can all declare that (Debians) key A was revoked on the premise that the attacker isn't going to be able to compromise all three repositories. Running revocation-list-only repositories would also be an option. The main problem I see with this is that we parse files we don't "trust" yet as we will only later find out that the key used to sign the Release file is indicated as revoked in a(nother) repository – but how likely is it really that a key is compromised and the attacker has an apt exploit at the same time?² On the upside that would work for bootstrappers as well as anyone not having a persistent /var/lib/apt/lists (like mobile, minimal chroots, …), uses our existing repository infrastructure instead of adding a new one just for this failure case and could help in distributing the news faster as an attacker isn't going to compromise all and for replays the window is reduced from "until valid-until expires for this repository" to "… for any repository (with revocation data)". Regarding how that would work, I guess just a list of fingerprints will be good enough, but for the unlikely case of two repositories having different keys with the same fingerprint lets pick Origin as field to match which fingerprints apply to which repo [an attacker can't change the field value without raising an error in libapt 1.5]. I don't think we need apt to check if that revoke by fingerprint is legit as I don't see what someone would gain by faking a revoke in a repo. Sure, it blocks updates for unrelated repositories but if that is your goal you have everything from replay as a MITM to DDoS available, so compromising a repository for that seems overkill, especially as it is very visible… And misuse like trying to block your competition seems like a surefire way to loose trust aka users… What this buys is that a key can be revoked even if no proper revocation certificate is available (yet) like if Davids-Playground is compromised while I am on holiday (or worse). We could allow for both through and use the "revocation certificate" as a way to distribute further info about the compromise like where to get more info and how to upgrade now… Mediumterm, what is going to happen after the revoke? Are we going to suggest to generate two archive keys from the get go declaring that either can sign the Release, but only use one (and keep the other in reserve), so that after the revoke of key A you get key B out of the bunker and use that from now on? Longterm I would actually like to allow repositories to ship more information about other repositories than "just" revocation lists like repo A saying "repo B should have a Date of at least …" so that a user could opt with repo A for being warned if his copy of repo B isn't that recent (indicating a stale mirror, replay, …) long before repo Bs Valid-Until expires – and users could (not) opt in to such repos e.g. based on their paranoia vs local mirror opinion. Best regards David Kalnischkies ¹ not a typo, but an imaginary "HTTP Super Secure" ² what you could do to combat this is to allow defining update stages as in first update repo A & B and only after that C & D. A & B could be two revocation-list-only repos (e.g. A with Valid-Until of a month, signed manually with an offline key and B with a Valid-Until of an hour signed automatically) with the idea that A & B will catch in the longterm the revoked keys before we parse files signed with them, but still allow C & D to revoke in 'retrospective'; especially if a user opted for whatever reason to not use B.
Attachment:
signature.asc
Description: PGP signature