Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP comm…

Borrar esta mensaxe

Responder a esta mensaxe
Autor: sajolida
Data:  
Para: The Tails public development discussion list
Asunto: Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
intrigeri:
> 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?


Sure.

>> 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.


Sure, I didn't think about this and that would be a pain. But I proposed
this because I remember you using similar tricks in the past already,
no? Could we ask people to drop a token file anywhere on they server
outside of the reach of rsync --delete?

But I don't mind dropping this idea as well :)

>>>  * 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.