Re: Proposal: Secure Key revocation for APT repositories
On Sun, Aug 20, 2017 at 04:17:41PM +0200, David Kalnischkies wrote:
> On Thu, Aug 17, 2017 at 09:11:08PM +0200, Julian Andres Klode wrote:
> > # 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?
Correct.
>
> 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).
Right.
>
> 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?
My idea here was to error out if the list is outside its validity
period, or: An expired list has the same result as every key being
listed inside of it.
But you're right, what you really want is to have an inner content
signature paired with an outer time stamp signature, and require both
to be valid, and just have the time stamp signature coupled to the valid
until. Then you could resign it daily with the time stamp stuff, but can
keep the KRL key offline.
> > 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.
That's true.
>
> #####
>
> 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.
Interesting. I think I like this approach somehow because it basically
crowdsources key revocation. It also allows us as a distribution to
revoke commonly used 3rd party repository keys in case they were
compromised and/or ship malware. Or well, any group could build its
own blacklist repository.
> 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?
Yes, I think that's a reasonable expectation. Or two subkeys of
a given master key. A repository should specify two (sub)keys to
be used in its InRelease file's Signed-By field; one of them should
be kept offline, the other can be kept online.
It might make sense to give the ability to repository owners to
specify thresholds, where stuff is always signed offline - that
would be easy to implement (just count number of valid sigs and
compare) and allow them to specify "stronger" policies like there
must be 3 valid signatures or something; but not sure.
> 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.
Sounds complicated.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: