[Tails-dev] [RFC] Dropping requirement for OpenPGP communica…

このメッセージを削除

このメッセージに返信
著者: intrigeri
日付:  
To: tails-dev
題目: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
Hi,

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?


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


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

* More?

I'm now less convinced that these advantages are worth the drawbacks,
and could be ready to drop the OpenPGP communication requirement.

Thoughts?

Cheers,
--
intrigeri