www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject Re: Secure submission of sensitive data to committees/entities
Date Thu, 24 Apr 2014 20:39:55 GMT
Let's try this without me accidentally prematurely sending the message.

On 4/24/14, 12:01 PM, Mark Thomas wrote:
> This service needs to be limited to only those PMCs (or other entities)
> that have explicitly requested it and are therefore expected to be
> capable of correctly handling OpenPGP encrypted email.
> 
> I'm concerned that enabling by default for all PMCs creates as many, if
> not more, problems than it solves. The majority of commiters, members
> and PMCs are not capable of correctly (i.e. securely) working with
> OpenPGP as we see every time we have an enforced password reset.

Being able to deal with this mail should be pretty easy for anyone.  If your
mail client doesn't support encrypted mail you can simply copy the encrypted
portion out run gpg on the command line, paste the message in, respond to the
prompt to provide the passphrase to your key, and finally hit Ctrl+D.  Those
basic instructions could easily be included in the plain text portion of the email.

This problem is ultimately a chicken or egg issue.  If you don't start sending
people encrypted mail they have no incentive to learn what to do with it.  If
they don't know how to receive it you'll probably avoid sending it.  If you
want people to learn how to deal with the mail, start sending them encrypted
mail on a more regular basis.

> Limiting the service to PMCs that grok OpenPGP removes a lot of the
> problems but a number of issues remain. The ones I can think of right
> now are:
> - It renders part of the PMC archives inaccessible to ASF members
> - It renders part of the PMC archives inaccessible to the ASF board
> - In the worse case scenario where every PMC members loses their
>   private key it renders the PMC archives inaccessible to anyone.
> - None of the previous issues I am aware of where private information
>   was mis-handled would have been prevented by this system
> - This looks like a solution in search of a problem. I'm aware that this
>   was requested by a PMC but I'm not convinced that that request is
>   backed up by a genuine use case nor that the effort involved in
>   creating and, more importantly, maintaining this service is justified
>   by the benefits it would provide
> 
> (Yes, some of the above is solvable by encrypting to a key accessible by
> root, by sending a non-encrypted version to the archive, etc.)

Or by always encrypting to the board members keys as well.  Or several other
possible solutions.

> Let me approach this another way.
> 
> What security risks is this system attempting to mitigate? That
> information sent by by some random, external, non-security savvy person
> is encrypted and unreadable while in transit? What information is
> expected to be sufficiently valuable that someone (from a malicious user
> in an internet cafe to a nation state) is going to want to the trouble
> of intercepting it?

I suggested it because I saw someone submit a security issue to
security@apache.org.  A member of the security team proceeded to decrypt the
message and post it in plain text to the private list for the project.  That
seems like a ridiculous manual step for a human being to have to do. It also
nullifies the effort the reporter went to in trying to submit the issue
securely.  Why even bother to advertise PGP submissions if we're just going to
resend them in plain text?  Do we really trust that the plain text connections
between ASF and the PMC members receiving the report are secure?

The assumption you're working on is that the mishandling of private information
that you're aware of is the only mishandling that has happened.  If I was a
intelligence agency I would be finding a way to listen to the ASF's
private/security lists.  This would give me advance notice of flaws, in which I
could exploit the flaw until it became public.  If they were doing this and
using the vulnerabilities exceedingly sparingly, I doubt we would know that
this was ocuring.  In fact the Snowden leaks have pretty much showed that
they're using vulnerabilities this way, the only thing we don't know is if
they're monitoring our lists.  In my opinion they'd be stupid not to.  I'd
summarize your position as the guy who never bothers to lock the door because
he hasn't been robbed yet.

I've argued that we should have MX servers that support TLS to help mitigate
this.  There are two problems with this.  Not everyone supports TLS on their MX
servers and not all the TLS servers have CA verifiable certs, meaning you can
still man in the middle them.  So the only real solution is end to end encryption.

As it is I don't think very many of the security reports coming in are
encrypted.  That shows that the existing PGP process is either too difficult
for people to use or that they're discouraged by the comment about issues that
are encrypted are handled slower.

Fortunately, most of our security issues aren't terribly interesting to
governments.  But I also think we should be prepared for massive issues now.
We have projects that are significant pieces of the Internet infrastructure.

> Whichever way I look at this, I am having a hard time coming up with a
> requirement that justifies the ongoing maintenance costs (I'm ignoring
> the initial development effort since most of it has been done and
> because this looks like an itch you want to scratch).

I think you're vastly underestimating the value of a secure submission system
or you're vastly overestimating the maintenance costs, I'm not sure which.

> If this is a service that has only been requested by a single PMC then
> perhaps that PMC should take on the responsibility of creating and
> managing this service rather than passing it to infra.

I think saying that a PMC asked for this would be an exaggeration.  I made the
suggestion, I'm on 2 PMCs, but I didn't start a discussion with those PMCs and
gain consensus to ask for this.  In a lot of respects my comment to Daniel was
a somewhat offhand remark, not so much as a formal request.  I'm pleasantly
surprised that he's taken my idea so far so quickly.  I'd plan to start a
discussion asking for it, but haven't gotten to doing so.


Mime
View raw message