hi,
sajolida wrote (11 Mar 2016 16:40:08 GMT) :
> intrigeri:
>> 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.).
I was indeed under this impression.
>> - 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.
ACK.
So, dropping the requirement for mirror operators to maintain an
OpenPGP key we can see as valid would not imply any regression,
compared to the current state of things.
Rather, if we wanted to have "We can authenticate requests sent to us
by mirror operators", we would have to do extra work we're not
doing currently.
⇒ If anyone feels like we should really do that, then at this point
they'd better be ready to contribute some time to help with it (in
practice our mirrors team went from 2 active members to 1 in the last
6-12 months or so). But given we've not had these nice security
properties for months, and our world didn't end anyway, maybe it's no
big deal and we can just forget about it?
> 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).
For this to work, they need to drop --delete from their rsync cronjob,
or we have to be able to check the token file within 1 hour (don't
count on it), or we need to adjust all rsync cronjobs to ignore a new
directory where such token files would live. Nothing impossible, but
in this area, frankly I'm personally not going to do more than
reviewing good patches.
>> * 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).
Confirmed.
Cheers,
--
intrigeri
