intrigeri:
> We'll soon be in a position to add more servers to the pool of HTTP
> mirrors that server our ISO images and IUKs. Before I publish the
> corresponding call for help, and get in touch with operators of
> potential fast mirrors (#11079), I'd like to make sure we get the
> requirements right.
>
> So far, we (or was it perhaps just me?) have insisted on having a way
> to communicate using OpenPGP with each operator of a HTTP mirror in
> our pool. I'm starting to question this. [In case anyone here didn't
> get that memo: yes, it often takes me years to change my mind.]
>
> This requirement has one clear disadvantage: it excludes some fast
> mirrors, e.g. lots of those that are run in universities (I have to
> trust people who are more in touch with operators of such candidate
> mirrors, on this one, as I have personally no idea). Also, on our side
> it adds to the burden of maintaining our pool of mirrors: maintaining
> a keyring isn't easy, and it gets quite hard if one wants to try to do
> it seriously.
>
> We are in the process of dropping at least another requirement of ours
> (the need for a dedicated hostname) that might have been a blocker, so
> I think it's time to check our list of requirements.
>
> I think the main advantages of requiring OpenPGP -enabled
> communication with mirror operators are:
>
> * We can authenticate requests sent to us by mirror operators: e.g.
> "please remove my mirror from the pool", that could otherwise be
> used to degrade our pool of mirrors, just by spoofing the sender
> address.
>
> - Are we seriously checking the OpenPGP signature on such requests?
> I used to do it, and used to require a good trust path for key
> updates, but I am under the impression that this might all have
> been handled in a more flexible way recently. sajolida?
I'm definitely not. It's been a while since I gave up on bugging mirror
operators for their key if they don't provide me one themselves or ask
for a trust path on key updates. I gave up on this because I was never
really convinced that the advantages ("preventing artificial degradation
of the pool") outweighs the disadvantages (sending additional email just
for that, asking people to do obscure OpenPGP rituals that often fail,
dealing with mismatching key ids, do manual trust path verifications,
sending and monitoring Schleuder commands, raising the bar for new
mirrors, etc.).
> - Perhaps we would notice if too many mirrors were removed (this
> calls for a monitoring check, I guess), and perhaps mirror
> operators would notice if they don't get the traffic they expect?
> IOW, perhaps we have other ways to avoid such attacks from being
> effective enough to be attractive in the first place.
I saw the scenario "please remove my mirror from the pool" mentioned
several times in this thread and almost be the foundation of all this
and I don't think it. Until now we've been managing the pool manually
and we would have noticed and reacted if the pool was being seriously
degraded.
Also, this can be dealt with without OpenPGP signature: we can ask
operators to put a token file with some random number on their server
when requesting to be removed (as we've done some times I think). Having
a template answer for this would make it a breeze to enforce.
> * Mirror operators can authenticate instructions we send them, e.g.
> "please add this option to your nginx configuration". Without this,
> anyone can quite trivially DoS our pool of HTTP mirrors, until
> someone notices. The thing is, we have no idea if the operators of
> our mirrors check this, i.e. whether they would notice if some
> email apparently coming from us was not signed.
This is about *us* sending authenticated email and doesn't require
having the keys of the mirror operators. I'm all for continuing doing
this (supposing that this comes for free from Schleuder though I didn't
check).
