Secure submission of sensitive data to committees/entities

[Daniel Gruno <ru...@cord.dk>]

Hello, infra-dev lurkers,

As was seen in the latest board report (should be public in about a
month, if you're not on the infra ML), there was a request from several
people at ApacheCon for infra to create a tool that automates secure
submission of data of a sensitive nature to PMCs or other entities in
the foundation, and we'd like some feedback on this.

We have put up a solution for this at https://secsubmit.apache.org/ that
does the following:

1) Jane Doe has something sensitive she wishes to share with the PMC and
only the PMC (or another entity within the ASF)
2) Jane visits SecSubmit
3) Jane selects project Foo
4) Jane enters the data she'd like to send

5) The site fetches the PGP keys associated with members of this PMC
6) The site composes an email to the PMC/entity

7.a) The site encrypts this using the PGP keys and sends it to
private@foo.apache.org (or security@ if applicable)
7.b) In cases of security issues (exploits etc), the Apache Security
Team is also CC'ed and their keys are coupled in.
7.c) The site also informs the PMC/entity about the current PGP status
of the respective PMC/entity (how many have valid keys etc)

This process can already be done manually by anyone, this site simply
automates it, making it easier to send encrypted information to an
Apache entity.

Note: Currently, the submissions end up in my inbox, it is not enabled
for projects yet. We'd like some feedback before we activate the service
for the public. If you'd like to see the end result of a submission,
please ping me on #asfinfra, and I can flip some bits to make it land in
your inbox.

Also note that this is NOT a replacement for security@. If people use it
for submitting security flaws, so be it, but the original intent is to
make it easier to submit confidential information of any character to a
PMC or other entity in the ASF, whether it be a bug, someone dying of
cancer or what have you, and be assured that only the PMC can read it,
even in cases of compromised email transport or clients.

What do you think? Is this something you could imagine using (or imagine
others could use), or is it simply a waste of space?

If there are questions about how the current set-up works, I'd be happy
to explain it in more detail.

With regards,
Daniel.

Re: Secure submission of sensitive data to committees/entities

[Ben Reser <be...@reser.org>]

On 4/23/14, 10:18 AM, Daniel Gruno wrote:
> What do you think? Is this something you could imagine using (or imagine
> others could use), or is it simply a waste of space?

I think it's great.  It takes all of the hassle of trying to do something like
this off the submitter.  While I'm sure there are plenty of people that are
comfortable using PGP/GPG and choosing the right keys, there are far more that
are not.  If people aren't comfortable using it they're probably going to send
things just in plain text so I think this is a huge improvement.

I hope this moves forward.

Full disclosure: I started this whole thing by making the suggestion to Daniel
at ApacheCon.

Re: Secure submission of sensitive data to committees/entities

[Daniel Gruno <ru...@cord.dk>]

On 04/24/2014 08:35 PM, sebb wrote:
> On 23 April 2014 18:18, Daniel Gruno <ru...@cord.dk> wrote:
>> Hello, infra-dev lurkers,
>>
>> As was seen in the latest board report (should be public in about a
>> month, if you're not on the infra ML), there was a request from several
>> people at ApacheCon for infra to create a tool that automates secure
>> submission of data of a sensitive nature to PMCs or other entities in
>> the foundation, and we'd like some feedback on this.
>>
>> We have put up a solution for this at https://secsubmit.apache.org/ that
>> does the following:
>>
>> 1) Jane Doe has something sensitive she wishes to share with the PMC and
>> only the PMC (or another entity within the ASF)
>> 2) Jane visits SecSubmit
>> 3) Jane selects project Foo
>> 4) Jane enters the data she'd like to send
>>
>> 5) The site fetches the PGP keys associated with members of this PMC
>> 6) The site composes an email to the PMC/entity
>>
>> 7.a) The site encrypts this using the PGP keys and sends it to
>> private@foo.apache.org (or security@ if applicable)
>> 7.b) In cases of security issues (exploits etc), the Apache Security
>> Team is also CC'ed and their keys are coupled in.
>> 7.c) The site also informs the PMC/entity about the current PGP status
>> of the respective PMC/entity (how many have valid keys etc)
>>
>> This process can already be done manually by anyone, this site simply
>> automates it, making it easier to send encrypted information to an
>> Apache entity.
>>
>> Note: Currently, the submissions end up in my inbox, it is not enabled
>> for projects yet. We'd like some feedback before we activate the service
>> for the public. If you'd like to see the end result of a submission,
>> please ping me on #asfinfra, and I can flip some bits to make it land in
>> your inbox.
>>
>> Also note that this is NOT a replacement for security@. If people use it
>> for submitting security flaws, so be it, but the original intent is to
>> make it easier to submit confidential information of any character to a
>> PMC or other entity in the ASF, whether it be a bug, someone dying of
>> cancer or what have you, and be assured that only the PMC can read it,
>> even in cases of compromised email transport or clients.
>>
>> What do you think? Is this something you could imagine using (or imagine
>> others could use), or is it simply a waste of space?
> 
> I can see that it could be very convenient for the sender.
> 
> But I suspect some of the recipients may not be expecting encrypted
> mail and may not know how to deal with it, so I think there would need
> to be clear instructions posted somewhere on how to proceed, ideally
> with a link in clear text in the mail. Otherwise infra may have to
> deal with lots of FAQs...

The email is sent partially encrypted, with some information in plain
text. This text contains instructions as well as a summary of the PGP
status of the respective PMC, encouraging people to add their keys.

> 
> Also, how are PMC members supposed to co-operate on dealing with such a mail?
> Perhaps by using the same system for follow-ups?
> Any unencrypted discussions on the private@list would need to be very
> careful not to expose the content of the mail inadvertently.
> 
They could use the system, sure, but perhaps it would be a good idea to
include a command string that they can use to encrypt text with.

>> If there are questions about how the current set-up works, I'd be happy
>> to explain it in more detail.
> 
> For e-mail addressed to the PMC, would it be sent to the PMC mailing
> list or to individual members?
> 
It would be sent to private@ and have reply-to set to private@

> It would be useful if a PMC member could find out who else had been
> sent the mail (and who can potentially decrypt it) so they can
> co-operate on dealing with it.
> 
> With any system that allows web-mail, there is the possibility that it
> will be used for sending junk - are there any safeguards against this?
> 
There is a small Turing test at the bottom. If this proves inadequate,
we can always add a proper captcha. This has however worked okay for the
blog system we have, but you never know.

You could already send junk to a private list, this would have to be
moderated just like any other message, it's not forced onto the ML.
(and thus, it's a really good idea if the ML mods have PGP keys)

> Is there a way to authenticate the sender?

Authenticate how?
> 
>> With regards,
>> Daniel.

Re: Secure submission of sensitive data to committees/entities

[sebb <se...@gmail.com>]

On 23 April 2014 18:18, Daniel Gruno <ru...@cord.dk> wrote:
> Hello, infra-dev lurkers,
>
> As was seen in the latest board report (should be public in about a
> month, if you're not on the infra ML), there was a request from several
> people at ApacheCon for infra to create a tool that automates secure
> submission of data of a sensitive nature to PMCs or other entities in
> the foundation, and we'd like some feedback on this.
>
> We have put up a solution for this at https://secsubmit.apache.org/ that
> does the following:
>
> 1) Jane Doe has something sensitive she wishes to share with the PMC and
> only the PMC (or another entity within the ASF)
> 2) Jane visits SecSubmit
> 3) Jane selects project Foo
> 4) Jane enters the data she'd like to send
>
> 5) The site fetches the PGP keys associated with members of this PMC
> 6) The site composes an email to the PMC/entity
>
> 7.a) The site encrypts this using the PGP keys and sends it to
> private@foo.apache.org (or security@ if applicable)
> 7.b) In cases of security issues (exploits etc), the Apache Security
> Team is also CC'ed and their keys are coupled in.
> 7.c) The site also informs the PMC/entity about the current PGP status
> of the respective PMC/entity (how many have valid keys etc)
>
> This process can already be done manually by anyone, this site simply
> automates it, making it easier to send encrypted information to an
> Apache entity.
>
> Note: Currently, the submissions end up in my inbox, it is not enabled
> for projects yet. We'd like some feedback before we activate the service
> for the public. If you'd like to see the end result of a submission,
> please ping me on #asfinfra, and I can flip some bits to make it land in
> your inbox.
>
> Also note that this is NOT a replacement for security@. If people use it
> for submitting security flaws, so be it, but the original intent is to
> make it easier to submit confidential information of any character to a
> PMC or other entity in the ASF, whether it be a bug, someone dying of
> cancer or what have you, and be assured that only the PMC can read it,
> even in cases of compromised email transport or clients.
>
> What do you think? Is this something you could imagine using (or imagine
> others could use), or is it simply a waste of space?

I can see that it could be very convenient for the sender.

But I suspect some of the recipients may not be expecting encrypted
mail and may not know how to deal with it, so I think there would need
to be clear instructions posted somewhere on how to proceed, ideally
with a link in clear text in the mail. Otherwise infra may have to
deal with lots of FAQs...

Also, how are PMC members supposed to co-operate on dealing with such a mail?
Perhaps by using the same system for follow-ups?
Any unencrypted discussions on the private@list would need to be very
careful not to expose the content of the mail inadvertently.

> If there are questions about how the current set-up works, I'd be happy
> to explain it in more detail.

For e-mail addressed to the PMC, would it be sent to the PMC mailing
list or to individual members?

It would be useful if a PMC member could find out who else had been
sent the mail (and who can potentially decrypt it) so they can
co-operate on dealing with it.

With any system that allows web-mail, there is the possibility that it
will be used for sending junk - are there any safeguards against this?

Is there a way to authenticate the sender?

> With regards,
> Daniel.

Re: Secure submission of sensitive data to committees/entities

[Ben Reser <be...@reser.org>]

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.

Re: Secure submission of sensitive data to committees/entities

[Ben Reser <be...@reser.org>]

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.)
> 
> 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?
> 
> 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).
> 
> 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.
> 
> Mark
> 

Re: Secure submission of sensitive data to committees/entities

[Mark Thomas <ma...@apache.org>]

On 23/04/2014 18:18, Daniel Gruno wrote:
> Hello, infra-dev lurkers,
> 
> As was seen in the latest board report (should be public in about a
> month, if you're not on the infra ML), there was a request from several
> people at ApacheCon for infra to create a tool that automates secure
> submission of data of a sensitive nature to PMCs or other entities in
> the foundation, and we'd like some feedback on this.

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.

> We have put up a solution for this at https://secsubmit.apache.org/ that
> does the following:
> 
> 1) Jane Doe has something sensitive she wishes to share with the PMC and
> only the PMC (or another entity within the ASF)
> 2) Jane visits SecSubmit
> 3) Jane selects project Foo
> 4) Jane enters the data she'd like to send
> 
> 5) The site fetches the PGP keys associated with members of this PMC
> 6) The site composes an email to the PMC/entity
> 
> 7.a) The site encrypts this using the PGP keys and sends it to
> private@foo.apache.org (or security@ if applicable)
> 7.b) In cases of security issues (exploits etc), the Apache Security
> Team is also CC'ed and their keys are coupled in.
> 7.c) The site also informs the PMC/entity about the current PGP status
> of the respective PMC/entity (how many have valid keys etc)
> 
> This process can already be done manually by anyone, this site simply
> automates it, making it easier to send encrypted information to an
> Apache entity.
> 
> Note: Currently, the submissions end up in my inbox, it is not enabled
> for projects yet. We'd like some feedback before we activate the service
> for the public. If you'd like to see the end result of a submission,
> please ping me on #asfinfra, and I can flip some bits to make it land in
> your inbox.
> 
> Also note that this is NOT a replacement for security@. If people use it
> for submitting security flaws, so be it, but the original intent is to
> make it easier to submit confidential information of any character to a
> PMC or other entity in the ASF, whether it be a bug, someone dying of
> cancer or what have you, and be assured that only the PMC can read it,
> even in cases of compromised email transport or clients.
> 
> What do you think? Is this something you could imagine using (or imagine
> others could use), or is it simply a waste of space?

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.

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

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?

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

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.

Mark