10:57 a.m.
Fedora has been part of an GPG sks service[1] for a number of years running
off of keys.fedoraproject.org. Last year, there were a number of attacks
made on the service which due to its 'write-only' nature makes it
impossible to clean up [2] [3]. When the attacks came up, and it was clear
it was not easily fixable, we moved keys to a proxy only mode. However this
mode has not been too stable and caused other issues.
Fedora Infrastructure has tried to figure out ways to run a service
replacement, but currently has not found one which we can with the
resources we have available. We plan to turn off and decommission
keys.fedoraproject.org on 2020-02-10.
We currently recommend people to use https://keys.openpgp.org/ which offers
lookup capabilities.
[1] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
[2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
[3]
https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/
--
Stephen J Smoogen.
11:11 a.m.
On Wed, Feb 5, 2020 at 11:57 AM Stephen John Smoogen <smooge(a)gmail.com> wrote:
Fedora has been part of an GPG sks service[1] for a number of years running off of
keys.fedoraproject.org. Last year, there were a number of attacks made on the service
which due to its 'write-only' nature makes it impossible to clean up [2] [3]. When
the attacks came up, and it was clear it was not easily fixable, we moved keys to a proxy
only mode. However this mode has not been too stable and caused other issues.
Fedora Infrastructure has tried to figure out ways to run a service replacement, but
currently has not found one which we can with the resources we have available. We plan to
turn off and decommission keys.fedoraproject.org on 2020-02-10.
We currently recommend people to use https://keys.openpgp.org/ which offers lookup
capabilities.
[1] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
[2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
[3] https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/
We may want to replace it with a simple Web Key Directory server:
https://wiki.gnupg.org/WKD
That would make it easy to lookup keys based on @fedoraproject.org
email addresses, and since keys can be replaced in the directory, it
avoids the problems with SKS attacks.
--
真実はいつも一つ！/ Always, there's only one truth!
12:01 p.m.
On Wed, Feb 5, 2020 at 12:13 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Feb 5, 2020 at 11:57 AM Stephen John Smoogen <smooge(a)gmail.com> wrote:
>
>
> Fedora has been part of an GPG sks service[1] for a number of years running off of
keys.fedoraproject.org. Last year, there were a number of attacks made on the service
which due to its 'write-only' nature makes it impossible to clean up [2] [3]. When
the attacks came up, and it was clear it was not easily fixable, we moved keys to a proxy
only mode. However this mode has not been too stable and caused other issues.
>
> Fedora Infrastructure has tried to figure out ways to run a service replacement, but
currently has not found one which we can with the resources we have available. We plan to
turn off and decommission keys.fedoraproject.org on 2020-02-10.
>
> We currently recommend people to use https://keys.openpgp.org/ which offers lookup
capabilities.
>
> [1] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
> [2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
> [3] https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/
>
We may want to replace it with a simple Web Key Directory server:
https://wiki.gnupg.org/WKD
That would make it easy to lookup keys based on @fedoraproject.org
email addresses, and since keys can be replaced in the directory, it
avoids the problems with SKS attacks.
I don't see that being valuable enough to actually invest the effort
into doing it and maintaining it long term. If others are interested
in hosting such a service, that would likely be welcome.
josh
1:58 p.m.
Stephen John Smoogen wrote:
We plan to turn off and decommission
keys.fedoraproject.org on 2020-02-10.
FAS contains PGP key IDs, which are displayed as links to
keys.fedoraproject.org. Is there a plan to look up keys through some
other key server instead?
It says that these key IDs are used for password resets, so just
dropping that would be a decrease in security.
Björn Persson
1:59 p.m.
Josh Boyer wrote:
> We may want to replace it with a simple Web Key Directory
server:
> https://wiki.gnupg.org/WKD
>
> That would make it easy to lookup keys based on @fedoraproject.org
> email addresses, and since keys can be replaced in the directory, it
> avoids the problems with SKS attacks.
I don't see that being valuable enough to actually invest the effort
into doing it and maintaining it long term. If others are interested
in hosting such a service, that would likely be welcome.
If such others were to step up to do the work, would they be able to
get the access needed to run it on Fedora infrastructure and integrate
with FAS?
Note that a Web Key Directory can't be run as a third-party service.
It's a fundamental feature of the protocol that the directory server
exists in the same domain as the email address. Technically a subdomain
could be delegated, but this isn't a thing that should be tossed up on
the first cloud service handy, because an intruder in the server would
be able to replace people's keys and impersonate them.
I think a Web Key Directory server would be good for the Fedora
Project's security, but it should run on hardware under the Fedora
Project's control.
Björn Persson
4:19 p.m.
On Sat, Feb 08, 2020 at 08:58:11PM +0100, Björn Persson wrote:
Stephen John Smoogen wrote:
> We plan to turn off and decommission
> keys.fedoraproject.org on 2020-02-10.
FAS contains PGP key IDs, which are displayed as links to
keys.fedoraproject.org. Is there a plan to look up keys through some
other key server instead?
Not for fas most likely, but the replacement we are working on could
definitely handle this better.
RFE's at: https://github.com/fedora-infra/securitas
It says that these key IDs are used for password resets, so just
dropping that would be a decrease in security.
well, they are already pretty bad because fas just stores the short
version, which has been subject to duplicates for... years now?
Not sure what best to do here. I fear gpg is pretty much a failure these
days and we need something better, but I am not sure what that is.
kevin
4:24 p.m.
On Sat, Feb 08, 2020 at 08:59:40PM +0100, Björn Persson wrote:
Josh Boyer wrote:
> > We may want to replace it with a simple Web Key Directory server:
> > https://wiki.gnupg.org/WKD
> >
> > That would make it easy to lookup keys based on @fedoraproject.org
> > email addresses, and since keys can be replaced in the directory, it
> > avoids the problems with SKS attacks.
>
> I don't see that being valuable enough to actually invest the effort
> into doing it and maintaining it long term. If others are interested
> in hosting such a service, that would likely be welcome.
If such others were to step up to do the work, would they be able to
get the access needed to run it on Fedora infrastructure and integrate
with FAS?
Fas is on life support mode, but something could be added to the new
coming account system interface.
Note that a Web Key Directory can't be run as a third-party service.
It's a fundamental feature of the protocol that the directory server
exists in the same domain as the email address. Technically a subdomain
could be delegated, but this isn't a thing that should be tossed up on
the first cloud service handy, because an intruder in the server would
be able to replace people's keys and impersonate them.
keys.openpgp.org offers a WKD as a service thing:
https://keys.openpgp.org/about/usage
I think a Web Key Directory server would be good for the Fedora
Project's security, but it should run on hardware under the Fedora
Project's control.
Possibly. I'm really not sure how much it would be used.
kevin
9:05 a.m.
On Sat, Feb 8, 2020 at 10:25 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sat, Feb 08, 2020 at 08:59:40PM +0100, Björn Persson wrote:
> Josh Boyer wrote:
> > > We may want to replace it with a simple Web Key Directory server:
> > > https://wiki.gnupg.org/WKD
> > >
> > > That would make it easy to lookup keys based on @fedoraproject.org
> > > email addresses, and since keys can be replaced in the directory, it
> > > avoids the problems with SKS attacks.
> >
> > I don't see that being valuable enough to actually invest the effort
> > into doing it and maintaining it long term. If others are interested
> > in hosting such a service, that would likely be welcome.
>
> If such others were to step up to do the work, would they be able to
> get the access needed to run it on Fedora infrastructure and integrate
> with FAS?
Fas is on life support mode, but something could be added to the new
coming account system interface.
Feel free to add anything as an issue and tag myself (lgriffin) within the
issue and we can consider it for sure.
>
> Note that a Web Key Directory can't be run as a third-party service.
> It's a fundamental feature of the protocol that the directory server
> exists in the same domain as the email address. Technically a subdomain
> could be delegated, but this isn't a thing that should be tossed up on
> the first cloud service handy, because an intruder in the server would
> be able to replace people's keys and impersonate them.
keys.openpgp.org offers a WKD as a service thing:
https://keys.openpgp.org/about/usage
>
> I think a Web Key Directory server would be good for the Fedora
> Project's security, but it should run on hardware under the Fedora
> Project's control.
Possibly. I'm really not sure how much it would be used.
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
4:14 p.m.
Kevin Fenzi wrote:
well, they are already pretty bad because fas just stores the short
version, which has been subject to duplicates for... years now?
My FAS account shows a 64-bit key ID. Yours shows 32 bits. I guess it
displays what you give it. As far as I have heard only 32-bit key IDs
have been duplicated.
It would be better if the user interface didn't require users to know
such details.
Not sure what best to do here. I fear gpg is pretty much a failure
these
days and we need something better, but I am not sure what that is.
I think GnuPG is best thought of as a building block, essentially a
library that programs can use for their encryption and authentication
needs. It works well when used that way, for example by RPM/Yum. Viewed
as a tool, it's only usable to crypto nerds.
The "web of trust" is clearly not working. In the more than 21 years
I've had PGP keys I have never once been able to validate a key through
a chain of signatures. The attack on SKS is another nail in its coffin.
Another certification method is needed, and WKD is one candidate.
Björn Persson
4:15 p.m.
Kevin Fenzi wrote:
Fas is on life support mode, but something could be added to the new
coming account system interface.
I understand from this that the entire FAS will be replaced. I had
previously gotten a vague impression that the new project would replace
the authentication bits of FAS or something.
keys.openpgp.org offers a WKD as a service thing:
https://keys.openpgp.org/about/usage
Hmm. They state that they support the lookup protocol, but in their FAQ
I find this statement:
| The keys.openpgp.org service is meant for key distribution and
| discovery, not as a de facto certification authority. Client
| implementations that want to offer verified communication should rely
| on their own trust model.
That is, you're not supposed to trust that keys you receive from
keys.openpgp.org are genuine.
WKD, on the other hand, aims to solve that. The WKD Internet Draft
(https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-09)
says this about the Web Key Directory Update Protocol:
| To put keys into the key directory a protocol to automate the task is
| desirable. The protocol defined here is entirely based on mail and
| the assumption that a mail provider can securely deliver mail to the
| INBOX of a user (e.g. an IMAP folder).
Securely dropping an email in a user's mailbox is no problem for an
email provider that controls its own infrastructure. For a third party
like keys.openpgp.org it's another matter. They state that they use
MTA-STS and STARTTLS Everywhere to make sure that verification emails
are sent over TLS, but what do they do if your email provider doesn't
support SMTP over TLS? Do they refuse your key in that case? My guess
is that they send the verification email unprotected, and that that's
one reason why they say they're not a certification authority.
Forwarding aliases like the addresses in fedoraproject.org add another
complication. Even if Red Hat's mail servers support MTA-STS, there is
no way for keys.openpgp.org to know whether the next hop will be secure.
A directory server integrated with FAS's successor wouldn't have to try
to verify keys over insecure email. Users could upload their key to
their account, and that would be sufficient proof that the key is
theirs.
Björn Persson
4:44 p.m.
On Wed, Feb 12, 2020 at 11:14:32PM +0100, Björn Persson wrote:
Kevin Fenzi wrote:
> well, they are already pretty bad because fas just stores the short
> version, which has been subject to duplicates for... years now?
My FAS account shows a 64-bit key ID. Yours shows 32 bits. I guess it
displays what you give it. As far as I have heard only 32-bit key IDs
have been duplicated.
It would be better if the user interface didn't require users to know
such details.
Yeah, we may have added a change to let you specify the longer one at
some point. Not sure.
> Not sure what best to do here. I fear gpg is pretty much a failure these
> days and we need something better, but I am not sure what that is.
I think GnuPG is best thought of as a building block, essentially a
library that programs can use for their encryption and authentication
needs. It works well when used that way, for example by RPM/Yum. Viewed
as a tool, it's only usable to crypto nerds.
Agreed.
The "web of trust" is clearly not working. In the more than
21 years
I've had PGP keys I have never once been able to validate a key through
a chain of signatures. The attack on SKS is another nail in its coffin.
Another certification method is needed, and WKD is one candidate.
well, WKD just replaces the 'web of trust' part, the rest of gpg/pgp is
still there: horrible setup, poor docs, configuration thats a nightmare,
etc.
Sadly, I don't know what the answer is, but getting more than just nerds
using gpg is not going to happen. ;(
kevin
4:48 p.m.
On Wed, Feb 12, 2020 at 11:15:01PM +0100, Björn Persson wrote:
Kevin Fenzi wrote:
> Fas is on life support mode, but something could be added to the new
> coming account system interface.
I understand from this that the entire FAS will be replaced. I had
previously gotten a vague impression that the new project would replace
the authentication bits of FAS or something.
The new system is going to depend on freeipa as much it can for the
heavy lifting. There will just be a web interface and api on top of that
to talk to the freeipa backend for things. Hopefully this will be of
interest to other communities/etc and we can get a community to help
maintain things longer term.
...snip...
A directory server integrated with FAS's successor wouldn't have to try
to verify keys over insecure email. Users could upload their key to
their account, and that would be sufficient proof that the key is
theirs.
Sure, feel free to make the case to the team working on the interface.
I don't want to commit them to work, but I agree having something might
be nice. Perhaps if not in the initial version in a later one.
kevin
5:32 a.m.
On Wed, Feb 12, 2020 at 11:15:01PM +0100, Björn Persson wrote:
are sent over TLS, but what do they do if your email provider
doesn't
support SMTP over TLS? Do they refuse your key in that case? My guess
is that they send the verification email unprotected, and that that's
one reason why they say they're not a certification authority.
All CAs support verification via insecure protocols AFAIK because
usually the certificate is needed to secure the protocol. What other
option would they have?
Kind regards
Till
5:12 p.m.
New subject: CAs and verification security (was: Turning off
keys.fedoraproject.org)
Till Maas wrote:
All CAs support verification via insecure protocols AFAIK because
usually the certificate is needed to secure the protocol.
If you mean CAs who issue server certificates for use in HTTPS, and who
serve the general public, then that's probably true, but then we're not
talking about OpenPGP keys anymore.
As an example of another kind of certification authority that doesn't
rely on insecure protocols, I have a government-issued ID card that
contains a chip with a certificate that I can use to prove my identity
to some government agencies' websites. It can for example be used as a
client certificate in HTTPS. To get this I had to be physically present
and prove my identity with another valid ID document. (Unfortunately
it's lacking in standardization and requires some unfree software
components.)
What other option would they have?
As regards server certificates for HTTPS, all the other options I can
think of would use trust chains anchored in DNSsec in one way or
another.
Apparently Let's Encrypt performs DNSsec validation when using the
DNS-01 challenge type. If the zone is signed, then an attacker can't
get a fraudulent certificate by way of DNS poisoning:
https://community.letsencrypt.org/t/dnssec-with-own-soa-and-acme2/80239
So then attackers will try the other challenge types. To prevent that, a
new RFC specifies the validationmethods parameter for CAA records. Let's
Encrypt has at least been testing support for this:
https://www.rfc-editor.org/rfc/rfc8657
https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125
Björn Persson
10:46 a.m.
Neal Gompa wrote:
We may want to replace it with a simple Web Key Directory server:
For anyone who is interested, this possibility is being explored here:
https://github.com/fedora-infra/securitas/issues/118
Björn Persson
1523
days inactive
1542
days old
14 comments
7 participants
participants (7)
-
Björn Persson -
Josh Boyer -
Kevin Fenzi -
Leigh Griffin -
Neal Gompa -
Stephen John Smoogen -
Till Maas