Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
Hi, intrigeri wrote (14 Mar 2016 15:41:50 GMT) : > sajolida wrote (14 Mar 2016 15:21:21 GMT) : >> intrigeri: >>> sajolida wrote (11 Mar 2016 16:40:08 GMT) : >>> 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. > I'll wait a bit more, to let a chance to people who think differently > (those who have already expressed it, as well as those who haven't > yet) to digest the updates we provided, and check how they feel now. Six weeks later, with no updated argument raised against dropping this requirement, I am going to consider it's now a decision, and will update our doc for mirror operators accordingly. For the avoidance of doubt: I don't intend to drop any reference to OpenPGP communication from said documentation, I'll just make it optional. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
Yes, it's usually too much pain to encrypt and check sigs by hand, but security is critical for Tails. So let's do what we almost always do. Use software. > 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 If it's software we know, we're glad to help. Ease of use was an OpenPGP issue for decades, but in the last couple of years we are finally seeing some good open source solutions. Doug GoodCrypto Warning: Anyone could have read this message. Use encryption, it works. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
hey, sajolida wrote (14 Mar 2016 15:21:21 GMT) : > intrigeri: >> sajolida wrote (11 Mar 2016 16:40:08 GMT) : >> ⇒ 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. I'll wait a bit more, to let a chance to people who think differently (those who have already expressed it, as well as those who haven't yet) to digest the updates we provided, and check how they feel now. >>> 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? I think so too, but I don't remember the details, except that sometimes the timing was tricky. > Could we ask people to drop a token file anywhere on they server > outside of the reach of rsync --delete? Yes, this can work if they (can) host other stuff than ours on their webserver. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
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.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
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
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
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).
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
Hi, u wrote (06 Mar 2016 19:03:30 GMT) : > Encrypting would keep a veil on who of the Tails team sends which > requests for which reasons. I think that using Schleuder's remailing capabilities already provide this property, and I'm not sure I follow how encryption impacts it. >> 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), Heard. So I guess that we're back to wondering if those who maintain the pool of mirrors check such things strictly enough to make all this work useful against an actual attacker. I'll ignore the "who does this work" part for now, because for now I'd rather discuss "assuming we have people happy to do it, do we think it's worth it?", and avoid leaning on the discussion with how the decision may affect my personal commitments. > then encryption is only a step away and we still need to maintain > the mirror keyring. Yes, absolutely (I didn't mention it initially because I agree that encryption comes for free if we "keep" authentication). > 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. ... and I think that Schleuder doesn't allow us to have authentication only when emailing someone, so if we have their pubkey, we're going to sign + encrypt; and if we don't have their pubkey, then we're only going to sign. Cheers! -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
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. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
PS: If the OpenPGP requirement is removed, I'd strongly suggest at least
asking for a confirmation for significant requests (e.g. removal of a
server from the pool). The confirmation should contain a full quote of the
e-mail it is sent in reply to. That way, at least easy spoofing is
prevented. It provides no additional security against a man-in-the-middle
attacker, but sending an e-mail with a forged "From" header is probably
much, much easier ("trivial & legal" vs. "requiring illegal cracking or
being the NSA") than circumventing this additional protection.
2016-03-04 21:39 GMT+01:00 Tobias Frei :
> Hi,
>
> the requirement to use OpenPGP encryption has been somewhat annoying for
> me personally in the past, especially because it did not allow me to read
> mirror-related e-mails (sometimes relatively time-critical ones) on my
> smartphone. This has happened to me on vacation in another country (I don't
> have a laptop) and at the local university, during breaks that I could have
> used to fix a problem if I had known which one it was.
>
> Also, the information shared via encrypted e-mail about my mirror in any
> direction has never been so confidential that encryption would have been
> necessary in my opinion. I know that it is probably best to encrypt all
> communication to prevent an attacker (e.g. NSA) from understanding which
> e-mails are really interesting, but the cost of encryption has outweighed
> the benefits for me so far.
>
> What I'd absolutely keep, though, is the *signing* of e-mails. I need to
> be able to check if a request has really been sent by the undersigning
> person. If can be sure that the request is valid (e.g. "your server is
> down") without verifying the OpenPGP signature, I might react directly
> (e.g. restart the server) instead of verifying the signature. If I can't, I
> must verify the signature.
> Also, I hope that the same level of verification is applied when I send an
> e-mail about my mirror. If I quote the sender's e-mail in my reply and
> simply confirm fixing a problem, checking my signature might be
> unnecessary. If I request the removal of my mirror from the pool, I really
> hope that the request will be properly verified. If my signature is
> missing, I hope that I'd be asked to provide a valid OpenPGP signature, a
> message on my website or whatever else would be sufficient to identify me
> as the sender of the request.
>
> Sending and receiving encrypted e-mails is rather annoying, sending and
> receiving signed e-mails is necessary, I'd say.
>
> Best regards,
> Tobias Frei
>
>
> 2016-03-04 20:18 GMT+01:00 intrigeri :
>
>> 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,
>>
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
Hi, the requirement to use OpenPGP encryption has been somewhat annoying for me personally in the past, especially because it did not allow me to read mirror-related e-mails (sometimes relatively time-critical ones) on my smartphone. This has happened to me on vacation in another country (I don't have a laptop) and at the local university, during breaks that I could have used to fix a problem if I had known which one it was. Also, the information shared via encrypted e-mail about my mirror in any direction has never been so confidential that encryption would have been necessary in my opinion. I know that it is probably best to encrypt all communication to prevent an attacker (e.g. NSA) from understanding which e-mails are really interesting, but the cost of encryption has outweighed the benefits for me so far. What I'd absolutely keep, though, is the *signing* of e-mails. I need to be able to check if a request has really been sent by the undersigning person. If can be sure that the request is valid (e.g. "your server is down") without verifying the OpenPGP signature, I might react directly (e.g. restart the server) instead of verifying the signature. If I can't, I must verify the signature. Also, I hope that the same level of verification is applied when I send an e-mail about my mirror. If I quote the sender's e-mail in my reply and simply confirm fixing a problem, checking my signature might be unnecessary. If I request the removal of my mirror from the pool, I really hope that the request will be properly verified. If my signature is missing, I hope that I'd be asked to provide a valid OpenPGP signature, a message on my website or whatever else would be sufficient to identify me as the sender of the request. Sending and receiving encrypted e-mails is rather annoying, sending and receiving signed e-mails is necessary, I'd say. Best regards, Tobias Frei 2016-03-04 20:18 GMT+01:00 intrigeri : > 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 > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > ___
[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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
