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

Delete this message

Reply to this message
Autor: u
Data:  
A: tails-dev
Assumpte: Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
Hi,

intrigeri:
[...]
> 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


I don't know how exactly universities or ISPs proceed when hosting ISO
images of distributions.

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


Ack.

[..]

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


Encrypting would keep a veil on who of the Tails team sends which
requests for which reasons. That might be information which does not
seem interesting at the moment, but it's some kind of interesting
metadata after all :)

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


If signing requests in both directions is absolutely necessary (and I am
in favour of this), then encryption is only a step away and we still
need to maintain the mirror keyring.

I cannot imagine another way of authenticating such requests as of today.

As for proposing a choice to the operators on whether they'd like to
encrypt emails or not would probably add even more overhead of
maintaining such a list.

Cheers!
u.