[Sks-devel] Underserved areas?

[Eric Germann]

Colleagues,

As you may have noticed, I’ve spun up several SKS servers over the last several days. These are hosted in AWS regions.

So far, they’re up in:

Ohio,US
Mumbai,IN

Other available regions include:

Northern Virginia, US
Oregon, US
Northern California, US
Montreal, CA
Sao Paulo, BR
Dublin, IE
Frankfurt, DE
London, GB
Paris, FR
Singapore
Tokyo, JP
Sydney, AU
Seoul, KR


Announced but not yet active regions include:

Bahrain
Hong Kong
Sweden

They’re fairly cheap to operate, especially if they’re reserved instances.

My questions are twofold:

1. Is there merit to adding additional in any/all of the regions?
2. For HKPS, do I go with a standard cert?

Open to input and contributing.

Thanks

EKG

[Daniel Gnoutcheff]

Post by Eric Germann
2. For HKPS, do I go with a standard cert?

No. The sks-keyservers.net HKPS pool has its own, special-purpose CA
that server certs must be signed by. See:

https://sks-keyservers.net/verify_tls.php
https://sks-keyservers.net/overview-of-pools.php#pool_hkps

HTH,
Daniel
Operator of keys.sflc.info

[Timothy A. Holtzen]

I certainly wouldn't add to all the regions.  Much of Europe especially
Germany seems to be well served already.  I'd say the broader need is
for a better algorithm/system for determining which systems land in the
various regional pools.  It seems that the NA and OC pools quite often
contain hosts that are in Europe.  This could be because physical
geography and internet routing are two very different things but I think
more likely it is because the system(s) that are being used to measure
server performance are located in Europe and this skews the results.

For HKPS Kristian Fiskerstrand is the one maintaining the CA.  I believe
you can generate a CSR and send it in an encrypted message to him and he
will send you back the signed certificate. 

I would definitely say there is more need of HKPS hosts.  I think there
are only 6 and only two of those have IPv6 connectivity.

Timothy A. Holtzen
Campus Network Administrator
Nebraska Wesleyan University
Public PGP key CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7

Post by Eric Germann
They’re fairly cheap to operate, especially if they’re reserved instances.
1. Is there merit to adding additional in any/all of the regions?
2. For HKPS, do I go with a standard cert?
Open to input and contributing.
Thanks

[Alain Wolf]

Post by Timothy A. Holtzen
For HKPS Kristian Fiskerstrand is the one maintaining the CA.  I believe
you can generate a CSR and send it in an encrypted message to him and he
will send you back the signed certificate. 
I would definitely say there is more need of HKPS hosts.  I think there
are only 6 and only two of those have IPv6 connectivity.

It pains me a lot to see so little. Five to six percent HKPS, where
server-side HTTPS usage is now 67% according to Mozilla[1]. And we send
more interesting meta-data over HKP then over HTTP. Its a mildly
obfuscated personal contact list. There is no other unencrypted service
in my pool. Neither I use any as client nor do I provide any.

I don't know how Kristians SKS CA came to existence. Maybe it was about
avoiding additional costs for the volunteers, maybe about trust (or lack
of it) in the commercial CAs. Maybe just the DNS-pool-problem. Maybe
something else entirely.

But a lot of things have changed in this area in the last couple of
years. Maybe we could re-think this. Maybe there is a way, for an
ACME-challenge like DNS-01 or TLS-SNI to somehow work if a server is a
legitimate pool member? Maybe even just distribute a private key and
cert[2]? It should be automated. I want to have more green and less red
bricks in that wall[3]

Opinions, ideas anyone?

[1] https://letsencrypt.org/stats/
[2] Don't be shocked, its completely normal for coffee-shops to
distribute their WiFi password, just to avoid having their clients
connect unencrypted.
[3] https://sks-keyservers.net/status/

[Andrew Gallagher]

Post by Alain Wolf
I don't know how Kristians SKS CA came to existence. Maybe it was about
avoiding additional costs for the volunteers, maybe about trust (or lack
of it) in the commercial CAs. Maybe just the DNS-pool-problem. Maybe
something else entirely.

Distributing trust is *hard*. In order to have multiple machines serving
the same domain name, you either need to share a common certificate or
have a friendly intermediate CA that is willing to generate multiple
certs for the same domain name. Getting a browser-recognised
intermediate CA is expensive and, since we don't need browser
compatibility, irrelevant.

Post by Alain Wolf
But a lot of things have changed in this area in the last couple of
years. Maybe we could re-think this. Maybe there is a way, for an
ACME-challenge like DNS-01 or TLS-SNI to somehow work if a server is a
legitimate pool member?

Define "legitimate". ;-)

In principle, there's no reason why we couldn't have an ACME challenge
server somewhere that automatically signs the endpoint certs with the CA
cert.

In practice though, we'd need some way of preventing bad actors from
obtaining certs. Any pool member with a legit cert can MITM a target to
sniff their HKPS traffic. What's to stop $BOGEYMAN from joining the pool
(it's an automatic process after all), obtaining an HKPS cert and then
MITMing $VICTIM?

So we'd need manually verified user accounts. But that's no easier than
submitting a CSR. So it's a bit pointless.

Post by Alain Wolf
Maybe even just distribute a private key and cert[2]?

Distribute how? Once you start distributing private keys, you run the
risk of leakage. Your distribution mechanism becomes the weak link.

I should talk, of course. I never got around to applying for an HKPS
cert... :-)

[Alain Wolf]

Post by Andrew Gallagher

Post by Alain Wolf
I don't know how Kristians SKS CA came to existence. Maybe it was about
avoiding additional costs for the volunteers, maybe about trust (or lack
of it) in the commercial CAs. Maybe just the DNS-pool-problem. Maybe
something else entirely.

Distributing trust is *hard*. In order to have multiple machines serving
the same domain name, you either need to share a common certificate or
have a friendly intermediate CA that is willing to generate multiple
certs for the same domain name. Getting a browser-recognised
intermediate CA is expensive and, since we don't need browser
compatibility, irrelevant.

I see we are not (yet) on the same page here.

Define "trust" in the context of OpenPGP key servers today. ;-)

Post by Andrew Gallagher

Post by Alain Wolf
But a lot of things have changed in this area in the last couple of
years. Maybe we could re-think this. Maybe there is a way, for an
ACME-challenge like DNS-01 or TLS-SNI to somehow work if a server is a
legitimate pool member?

Define "legitimate". ;-)

Is running version >= 1.1.6, has Via header, no more then ~300 missing
keys, not vulnerable to CVE-2014-3207, Status OK.

Post by Andrew Gallagher
In principle, there's no reason why we couldn't have an ACME challenge
server somewhere that automatically signs the endpoint certs with the CA
cert.
In practice though, we'd need some way of preventing bad actors from
obtaining certs. Any pool member with a legit cert can MITM a target to
sniff their HKPS traffic. What's to stop $BOGEYMAN from joining the pool
(it's an automatic process after all), obtaining an HKPS cert and then
MITMing $VICTIM?

Whats stopping bad actors today?
A) from submitting a CSR to Kristian?
B) Listening in on an unencrypted connection to one of the 95% of
servers without a cert?

Post by Andrew Gallagher
So we'd need manually verified user accounts. But that's no easier than
submitting a CSR. So it's a bit pointless.

What do we gain from manual verification? Whats the procedure today
besides submitting a CSR with a not throughly verified PGP-key signature?

Post by Andrew Gallagher

Post by Alain Wolf
Maybe even just distribute a private key and cert[2]?

Distribute how? Once you start distributing private keys, you run the
risk of leakage. Your distribution mechanism becomes the weak link.

I mean distributing it publicly, so its already pre-leaked. Same as in
TLS ADH-AES256-GCM-SHA384 or maybe just use one of those. But I would
prefer the automated procedure with signed cert for every server with
its own key. I am just brainstorming here.

Post by Andrew Gallagher
I should talk, of course. I never got around to applying for an HKPS
cert... :-)

I did 106 days ago.

[Alain Wolf]

Post by Alain Wolf
Opinions, ideas anyone?

Maybe something along the line of ...

1) Server operator puts his PGP fingerprint in the servers contact
information (as we do today but would need to be mandatory HKPS).

2) Server operator creates server private key and CSR.

3) Server operator stores CSR on the server in something like
./well_known/hkps/0x27a69fc9a1744242.csr

3) Server operator signs the CSR with his PGP key and puts the signature
in ./well_known/hkps/0x27a69fc9a1744242.csr.asc

4) Kristian's hourly checking script does the usual tests but
additionally tries to fetch the CSR from its .well-known location.
Checks if the PGP signature of the CSR was done with the key who's
fingerprint is in the servers contact information.

5) The script signs the CSR with the CA key and sends the signed cert to
the server operator in a PGP encrypted mail.

6) Server operator installs the signed cert on his server.

7) The checking script could do some HKPS checks. Valid certificate? Not
expired? Deprecated ciphers? Perfect forward-secrecy? etc.
If everything checks-out server is added to hkps.pool (This might
already be the case today)

Cert expiry could be 3 months, checking script removes any server from
the pool who's cert expires in the next 24 or 48 hours. Cert should not
be valid longer then the operators PGP key.

For certificates renewals, the process could be the same, a new
certificate is issued as soon as the checking script finds a new CSR (or
the same CSR but a new PGP signature along with it).

Server cert revocations could be requested manually by asking the CA
operator or automatically by placing a PGP signed
0x27a69fc9a1744242.revoke.asc file in to the .well-known directory.

Revocation or expiry of the servers operators PGP key, should lead
automatically to the revocation of the server cert and removal of the
server from the pool.

After a while this could be made mandatory. So 100% of the sks-pool
servers are also in the hkps.pool

Creation of server keys, CSR and PGP signing could be automated (or
partly automated because of the PGP signing) by scripts distributed with
the SKS software package.

I don't think I am really qualified for designing new security
protocols, but the idea doesn't go out of my head. Sorry for the long post.

Regards

Alain

[Daniel Kahn Gillmor]

Post by Alain Wolf
Maybe something along the line of ...

sounds like you're (roughly) reinventing some sort of acme protocol.

if we're going to do that, then we should just encourage kristian to use
acme directly.

imho, having a dedicated CA for this particular pool is the *right*
answer -- certifying pools is bad enough from a security perspective and
we certainly don't need to get the full CA cartel involved in the
picture.

So the question isn't "why should kristian be in the loop?" -- it's "why
don't more people ask kristian to use hkps?"

I note that we have more tor hidden services than we have hkps servers!

I suspect this is because of certificate maintenance more than anything
else.

I confess i've let the hkps pool cert for zimmermann.mayfirst.org lapse
for months at a time (it's lapsed right now!) because i don't monitor it
as well as i should have. i wonder how many other people fall into the
same trap?

are there better ways to get members of the hkps pool to stay in the
pool?

--dkg, off to bug kristian to renew my cert


[Moritz Wirth]

I requested a certificate a few days ago, however only well known
keyservers receive a cert for HKPS (which is reasonable because the
certificates are valid for a year and there is no reliable way for
certificate revocation).

Another idea around the mitm problem - the client retrieves the current
list of servers in the pool, looks up their hostnames from the
sks-keyservers.net website (or somewhere else) and connects to the
server using the hostname, not the pool adress - Therefore, you would
not need additional names in the certificates and it would be easy for
operators to obtain own certificates. Malicious servers can be avoided
easily by kicking them out of the pool dns and the certificate itself is
useless as it only secures the own hostname.

Best regards,

Moritz

Post by Alain Wolf

Post by Alain Wolf
Opinions, ideas anyone?

Maybe something along the line of ...
1) Server operator puts his PGP fingerprint in the servers contact
information (as we do today but would need to be mandatory HKPS).
2) Server operator creates server private key and CSR.
3) Server operator stores CSR on the server in something like
./well_known/hkps/0x27a69fc9a1744242.csr
3) Server operator signs the CSR with his PGP key and puts the signature
in ./well_known/hkps/0x27a69fc9a1744242.csr.asc
4) Kristian's hourly checking script does the usual tests but
additionally tries to fetch the CSR from its .well-known location.
Checks if the PGP signature of the CSR was done with the key who's
fingerprint is in the servers contact information.
5) The script signs the CSR with the CA key and sends the signed cert to
the server operator in a PGP encrypted mail.
6) Server operator installs the signed cert on his server.
7) The checking script could do some HKPS checks. Valid certificate? Not
expired? Deprecated ciphers? Perfect forward-secrecy? etc.
If everything checks-out server is added to hkps.pool (This might
already be the case today)
Cert expiry could be 3 months, checking script removes any server from
the pool who's cert expires in the next 24 or 48 hours. Cert should not
be valid longer then the operators PGP key.
For certificates renewals, the process could be the same, a new
certificate is issued as soon as the checking script finds a new CSR (or
the same CSR but a new PGP signature along with it).
Server cert revocations could be requested manually by asking the CA
operator or automatically by placing a PGP signed
0x27a69fc9a1744242.revoke.asc file in to the .well-known directory.
Revocation or expiry of the servers operators PGP key, should lead
automatically to the revocation of the server cert and removal of the
server from the pool.
After a while this could be made mandatory. So 100% of the sks-pool
servers are also in the hkps.pool
Creation of server keys, CSR and PGP signing could be automated (or
partly automated because of the PGP signing) by scripts distributed with
the SKS software package.
I don't think I am really qualified for designing new security
protocols, but the idea doesn't go out of my head. Sorry for the long post.
Regards
Alain
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Kristian Fiskerstrand]

Post by Moritz Wirth
I requested a certificate a few days ago, however only well known
keyservers receive a cert for HKPS (which is reasonable because the
certificates are valid for a year and there is no reliable way for
certificate revocation).
Another idea around the mitm problem - the client retrieves the current
list of servers in the pool, looks up their hostnames from the
sks-keyservers.net website (or somewhere else) and connects to the
server using the hostname, not the pool adress - Therefore, you would
not need additional names in the certificates and it would be easy for
operators to obtain own certificates. Malicious servers can be avoided
easily by kicking them out of the pool dns and the certificate itself is
useless as it only secures the own hostname.
Best regards,
Moritz

Post by Alain Wolf

Post by Alain Wolf
Opinions, ideas anyone?

Maybe something along the line of ...
1) Server operator puts his PGP fingerprint in the servers contact
information (as we do today but would need to be mandatory HKPS).
2) Server operator creates server private key and CSR.
3) Server operator stores CSR on the server in something like
./well_known/hkps/0x27a69fc9a1744242.csr
3) Server operator signs the CSR with his PGP key and puts the

signature

Post by Alain Wolf
in ./well_known/hkps/0x27a69fc9a1744242.csr.asc
4) Kristian's hourly checking script does the usual tests but
additionally tries to fetch the CSR from its .well-known location.
Checks if the PGP signature of the CSR was done with the key who's
fingerprint is in the servers contact information.
5) The script signs the CSR with the CA key and sends the signed cert

to

Post by Alain Wolf
the server operator in a PGP encrypted mail.
6) Server operator installs the signed cert on his server.
7) The checking script could do some HKPS checks. Valid certificate?

Not

Post by Alain Wolf
expired? Deprecated ciphers? Perfect forward-secrecy? etc.
If everything checks-out server is added to hkps.pool (This might
already be the case today)
Cert expiry could be 3 months, checking script removes any server

from

Post by Alain Wolf
the pool who's cert expires in the next 24 or 48 hours. Cert should

not

Post by Alain Wolf
be valid longer then the operators PGP key.
For certificates renewals, the process could be the same, a new
certificate is issued as soon as the checking script finds a new CSR

(or

Post by Alain Wolf
the same CSR but a new PGP signature along with it).
Server cert revocations could be requested manually by asking the CA
operator or automatically by placing a PGP signed
0x27a69fc9a1744242.revoke.asc file in to the .well-known directory.
Revocation or expiry of the servers operators PGP key, should lead
automatically to the revocation of the server cert and removal of the
server from the pool.
After a while this could be made mandatory. So 100% of the sks-pool
servers are also in the hkps.pool
Creation of server keys, CSR and PGP signing could be automated (or
partly automated because of the PGP signing) by scripts distributed

with

Post by Alain Wolf
the SKS software package.
I don't think I am really qualified for designing new security
protocols, but the idea doesn't go out of my head. Sorry for the long

post.

Post by Alain Wolf
Regards
Alain
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

A misissued cert could still be used if attacker is persistent enough. Either through dns poision or other attack vectors.

And yes, I only issue certs to servers I recognize to have been in the pool for a while and operator should be in the openpgp wot strong-set.

--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP certificate at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

[dirk astrath]

Hi Kristian,

Post by Kristian Fiskerstrand
A misissued cert could still be used if attacker is persistent enough. Either through dns poision or other attack vectors.
And yes, I only issue certs to servers I recognize to have been in the pool for a while and operator should be in the openpgp wot strong-set.

Maybe it's wise if give some more details to the *.csr-file ... as you
will not sign certificate requests containing unneeded/unverifyable/...
information.

(Well ... at CAcert site we remove all data we couldn't verify from CSR
and create the certificate only with the details we're able to verify
... this could be a possibility for you, too.).

And ... (remembering a discussion we had at Fosdem last year):

Maybe you give some dates like (please provide CSR-requests before
2018-xx-01), so there will only some special days per year for your to
sign a bunch of requests instead of getting the requests all over the
year ...

Kind regards,

dirk

PS: Which reminds me, that i wanted to send you updated CSRs ... ;-)

[Heiko Richter]

Hi,

fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can
decide wether or not to publish a server's authentication token in the
dns zone or not. Furthermore you will receive "real" certificates where
the admins could add the pool hostname along with their own site
specific hostname into on certificates that is trusted by practically
all browsers and operating systems. If you want to kick somebody out you
just delete their token and their ip address from the dns zone so they
won't be able included in the pool and won't be able to renew their
shortlived-certificate. Furthermore you can first add the token and then
do some kind of automation to check if they have a valid certificate
before including them in the pool so you only need to manage the dns-01
authentication tokens.

That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Heiko

PS: On December 22nd you wanted to sign the certificate for my server.
Is there an update on that?

Post by dirk astrath
Hi Kristian,

Post by Kristian Fiskerstrand
A misissued cert could still be used if attacker is persistent
enough. Either through dns poision or other attack vectors.
And yes, I only issue certs to servers I recognize to have been in
the pool for a while and operator should be in the openpgp wot
strong-set.

Maybe it's wise if give some more details to the *.csr-file ... as you
will not sign certificate requests containing
unneeded/unverifyable/... information.
(Well ... at CAcert site we remove all data we couldn't verify from
CSR and create the certificate only with the details we're able to
verify ... this could be a possibility for you, too.).
Maybe you give some dates like (please provide CSR-requests before
2018-xx-01), so there will only some special days per year for your to
sign a bunch of requests instead of getting the requests all over the
year ...
Kind regards,
dirk
PS: Which reminds me, that i wanted to send you updated CSRs ... ;-)
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[dirk astrath]

Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or against
different styles of Web-Of-Trust, for or against different tools to be
installed to use the this Web-Of-Trust or inclusion in mail- or
webclients/browsers/distributions ... or not.

But we should not do it here ... ;-)

(NB: There is a difference between selfsigned and CAcert ... see below)

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be possible.

For your Keyserver you can use a Certificate issues by any CA as long as
it should not contain one of the pool names. On my server I decided to
use Let's Encrypt.

To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

But ...

Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

But ...

This special "Kristian-CA"-case has advantages even without being in the
mail-clients/browsers:

The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...

... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

Kind regards,

dirk

[Heiko Richter]

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.

Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be possible.

Sorry, but this is just a flat-out-lie.

Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

[Heiko Richter]

PS: Everything you wrote would have been true in 1998. The world of SSL
has evolved since then......



-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.

Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be possible.

Sorry, but this is just a flat-out-lie.

Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

[dirk astrath]

Hello,

Post by Heiko Richter

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Wrong.

If you use SNI, you can serve the LE-certificate for your server-name(s)
and the "Kristian-CA" for the poolserver-name(s).

Kind regards,

dirk

[Moritz Wirth]

Certificate Revocation is broken in most browsers today so there is no
reliable way to revoke a certificate (especially if you do not use OCSP). 

I don't think that it would be a big problem to get trusted certificates
for HKPS, however the trust problem stays the same and it comes with
other problems.

- You give up authority to a third party. Imagine, you validate the
chain of a certificate to the root and the intermediate changes (because
of compromise/BR Changes, whatever), it would break the HKPS
implementation of all clients.
- Trusted certificates may cost some money (except for Letsencrypt but
we have the validation problem there...)
- It is still possible for an attacker to get a certificate and do bad
things with it so there is no advantage of selfsigned/Kristians
certificates over trusted certificates (except the browser warnings..)

I am not sure how many people really use HKPS over the web browser, most
people just land on Port 11371 or Port 80.. For the SKS clients it does
not matter if the certificate is widely trusted as it has the root
included.

Best regards,

Moritz

Post by Heiko Richter
PS: Everything you wrote would have been true in 1998. The world of
SSL has evolved since then......
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.
Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be possible.

Sorry, but this is just a flat-out-lie.
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Heiko Richter]

Post by Moritz Wirth
Certificate Revocation is broken in most browsers today so there is no
reliable way to revoke a certificate (especially if you do not use OCSP).

They are ways to deal with that and any given trusted ca does so (OCSP
stampling and the must-staple header in certs just to name one of them).
Having an untrusted CA like "Kristian-CA" makes it impossible to deal
with that. Is there OCSP or any other kind of revocation checking
available that is supported by all (or most) clients? I think not...

Post by Moritz Wirth
I don't think that it would be a big problem to get trusted
certificates for HKPS, however the trust problem stays the same and it
comes with other problems.
- You give up authority to a third party. Imagine, you validate the
chain of a certificate to the root and the intermediate changes
(because of compromise/BR Changes, whatever), it would break the HKPS
implementation of all clients.

1) thats how it is with every CA (including "Kristian-CA").
2) exchanging the intermediate CA is completely immaterial as long as it
is not revoked. class-3-rollovers are happening daily and they are done
in a completely transparant way the users won't notice.
3) Is there an intermediate ca to encrease security on "Kristian-CA"? I
Think not....
4) I would trust a large, trusted, audited CA anyday over a
"Kristian-CA". That's why they have audits secure their Root-CAs offline
in vaults whereas "Kristian-CA" is just a selfsigned certificate,
probably stored on some server that's connected to the internet 24/7 and
has not class 3 cert to increase security.
4) What kind of stupid argument is that? What happens if "Kristian-CA"
is compromised? Or is that unthinkable? Perhaps you could set some time
aside to discuss what will happen to the certs if aliens invade, too....

Post by Moritz Wirth
- Trusted certificates may cost some money (except for Letsencrypt but
we have the validation problem there...)

We have no validation problem at Let's Encrypt. Just read my previous
message, I'm not willing to type it all again.

Post by Moritz Wirth
- It is still possible for an attacker to get a certificate and do bad
things with it so there is no advantage of selfsigned/Kristians
certificates over trusted certificates (except the browser warnings..)

Anything is possible. The problem is not if some social engineering can
give somebody a certificat. The problem is how can you revoke that cert
(with "Kristian-CA" you cannot, with Let's Encrypt and OCSP-stapling you
can). The other prblem is whether you are trusted by the users. If they
receive error messages on a daily basis or are asked to import
"Kristian-CA" that's just wrong and leaves them clueless and ignorant in
case such a message is really needed because of a revoked cert.
Selfsigned certs and untrusted ca certs belong in experimental
environments and learning children. In the real world there are better
ways to deal with security and trust and since letsencrypt you can have
them for free.

Post by Moritz Wirth
I am not sure how many people really use HKPS over the web browser,
most people just land on Port 11371 or Port 80.. For the SKS clients
it does not matter if the certificate is widely trusted as it has the
root included.

Well, just because GnuPG is fucked up in terms of certificate validation
doesn't mean you should use faulty certificates. Also Several Browsers
are moving to "All-HTTPS", so it's time to stop the 90s childish
self-signed certificate crap and get serious about using
well-established technologies. It's a sad day that your argument for not
caring about correctly established certificate chains is that GnuPG is
faulty and doesn't check certificates correctly.

Post by Moritz Wirth
Best regards,
Moritz

Post by Heiko Richter
PS: Everything you wrote would have been true in 1998. The world of
SSL has evolved since then......
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.
Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be possible.

Sorry, but this is just a flat-out-lie.
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Moritz Wirth]

All in all, what do you want to do? Just keep trusted certificates or
improve the numbers of HKPS Servers in the pool?

So how many certificates are issued with OCSP Stapling? 0.001%? And of
course you need OCSP for that (which is not the case right now, but yes
you do not have the problem with a trusted CA). And what about pool
servers that do not use/do not support OCSP? You want to kick out 95% of
all pool servers because they do not support HKPS? Great...

But let's go on and imagine we use Letsencrypt for HKPS. So I want a new
certificate, generate a DNS challenge and send it over to? Kristian?
Where is the difference with the current way of manually signing a CSR?
Or you want an API so you can change the records yourself? How do you
verify that and what keeps somebody from randomly issuing certificates
to other people over that API using his key? You really want anybody to
change the zone data? Or you really rely on Kristian to set the TXT
Records for 100 certificates every month? What do you do if something
happens and your certificate expires? Then you still have your browser
warning (or worse...).

Feel free to propose something how this might work (and maybe setup a
test environment for that)...

I agree that well audited, highly secured CAs are better than a single
CA running somewhere on a simple server. but what keeps the CA from
issuing certificates without OCSP stapling? And even with OCSP Stapling
and revocation checking, if I have a trusted certificate I can simply
set a HPKP Header (lets just imagine these things really work) so my
leaf certificate is the only one that is trusted and serve that to
everybody that connects to my server and kill all other trusted
certificates for a very long time :)

FWIW, if you really want a serious discussion about this, you probably
should stop calling everything you dont agree stupid, because right now
you are the one behaving childish. I think we have bigger problems if
aliens invade, but You are pretty sure that a CA would never issue rogue
certificates (remember Symantec and Google? ;)) 

But just my 2 cents...

Post by Heiko Richter

Post by Moritz Wirth
Certificate Revocation is broken in most browsers today so there is
no reliable way to revoke a certificate (especially if you do not use
OCSP).

They are ways to deal with that and any given trusted ca does so (OCSP
stampling and the must-staple header in certs just to name one of
them). Having an untrusted CA like "Kristian-CA" makes it impossible
to deal with that. Is there OCSP or any other kind of revocation
checking available that is supported by all (or most) clients? I think
not...

Post by Moritz Wirth
I don't think that it would be a big problem to get trusted
certificates for HKPS, however the trust problem stays the same and
it comes with other problems.
- You give up authority to a third party. Imagine, you validate the
chain of a certificate to the root and the intermediate changes
(because of compromise/BR Changes, whatever), it would break the HKPS
implementation of all clients.

1) thats how it is with every CA (including "Kristian-CA").
2) exchanging the intermediate CA is completely immaterial as long as
it is not revoked. class-3-rollovers are happening daily and they are
done in a completely transparant way the users won't notice.
3) Is there an intermediate ca to encrease security on "Kristian-CA"?
I Think not....
4) I would trust a large, trusted, audited CA anyday over a
"Kristian-CA". That's why they have audits secure their Root-CAs
offline in vaults whereas "Kristian-CA" is just a selfsigned
certificate, probably stored on some server that's connected to the
internet 24/7 and has not class 3 cert to increase security.
4) What kind of stupid argument is that? What happens if "Kristian-CA"
is compromised? Or is that unthinkable? Perhaps you could set some
time aside to discuss what will happen to the certs if aliens invade,
too....

Post by Moritz Wirth
- Trusted certificates may cost some money (except for Letsencrypt
but we have the validation problem there...)

We have no validation problem at Let's Encrypt. Just read my previous
message, I'm not willing to type it all again.

Post by Moritz Wirth
- It is still possible for an attacker to get a certificate and do
bad things with it so there is no advantage of selfsigned/Kristians
certificates over trusted certificates (except the browser warnings..)

Anything is possible. The problem is not if some social engineering
can give somebody a certificat. The problem is how can you revoke that
cert (with "Kristian-CA" you cannot, with Let's Encrypt and
OCSP-stapling you can). The other prblem is whether you are trusted by
the users. If they receive error messages on a daily basis or are
asked to import "Kristian-CA" that's just wrong and leaves them
clueless and ignorant in case such a message is really needed because
of a revoked cert. Selfsigned certs and untrusted ca certs belong in
experimental environments and learning children. In the real world
there are better ways to deal with security and trust and since
letsencrypt you can have them for free.

Post by Moritz Wirth
I am not sure how many people really use HKPS over the web browser,
most people just land on Port 11371 or Port 80.. For the SKS clients
it does not matter if the certificate is widely trusted as it has the
root included.

Well, just because GnuPG is fucked up in terms of certificate
validation doesn't mean you should use faulty certificates. Also
Several Browsers are moving to "All-HTTPS", so it's time to stop the
90s childish self-signed certificate crap and get serious about using
well-established technologies. It's a sad day that your argument for
not caring about correctly established certificate chains is that
GnuPG is faulty and doesn't check certificates correctly.

Post by Moritz Wirth
Best regards,
Moritz

Post by Heiko Richter
PS: Everything you wrote would have been true in 1998. The world of
SSL has evolved since then......
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.
Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be possible.

Sorry, but this is just a flat-out-lie.
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Gabor Kiss]

Post by Heiko Richter
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Folks,

I don't want to chip on your hot debate (Honey! Is there any popcorn yet?)
I just wish to clarify some technical details.

Now Kristian manages a single domain (sks-keyservers.net) and
he signes CSRs from a dozen operators.
All of these CSR are fabricated for subject "hkps.pool.sks-keyservers.net".
(So if a HKPS client (e.g. gnupg) connects to any pool servers
behind the hkps.pool.sks-keyservers.net entry it could verify
connection secureness.)
However pool operators have own distinguished key pairs and Kristian
signes them individually.
Using the suggested method above Kristian should put a new,
different TXT record into hkps.pool.sks-keyservers.net name
server every time a new operator need a certificate.
Also at every resigning.
(Corollary: Kristian cannot accept a new operator request
until the previous transaction is done.)

Post by Heiko Richter
If some admin needs to be thrown out Kristian can just remove the
challenge code for his server from the dns zone and the resigning will fail.

I assume Let's encrypt asks TXT record for the _same_ FQDN each time. E.g.

_acme-challenge.hkps.pool.sks-keyservers.net. TXT "funny string here"

How Kristian could "remove challenge code for _his_ server" selectively
if the DNS always contains the challenge _only_ of the latest
signing transaction?

Did I miss something?

Regards

Gabor

[Heiko Richter]

Post by Gabor Kiss

Post by Heiko Richter
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Folks,
I don't want to chip on your hot debate (Honey! Is there any popcorn yet?)
I just wish to clarify some technical details.
Now Kristian manages a single domain (sks-keyservers.net) and
he signes CSRs from a dozen operators.
All of these CSR are fabricated for subject "hkps.pool.sks-keyservers.net".
(So if a HKPS client (e.g. gnupg) connects to any pool servers
behind the hkps.pool.sks-keyservers.net entry it could verify
connection secureness.)

Sorry, but completely false. The subject line is only a tiny little part
of the verification process. The main part is checking the certificate's
ca signature against the known list of valid root certificates on the
client. The fact that your GPG client shows a secure connection is
either due to a faulty/incomplete validation algorithm that doesn't
check the ca signature of the servers cert or because "Kristian-CA" is
hardcoded into GnuPG. I don't know which one it is and don't really care
because both situations would be relics of 90s-incompetence that
compromise security and should have been removed from gnupg years ago.

Post by Gabor Kiss
However pool operators have own distinguished key pairs and Kristian
signes them individually.
Using the suggested method above Kristian should put a new,
different TXT record into hkps.pool.sks-keyservers.net name
server every time a new operator need a certificate.
Also at every resigning.

Also false. The code is only added *once* not for every cert renewal. As
long as it's there, the client will be able to renew the certificate
every 3 months.

Post by Gabor Kiss
(Corollary: Kristian cannot accept a new operator request
until the previous transaction is done.)

Also false. There can be an unlimited number of records of the same type
(in this case txt) for any given hostname. All verification codes stay
in place as long as there is no reason to remove them. Only that way
admins can renew their certs.

Post by Gabor Kiss

Post by Heiko Richter
If some admin needs to be thrown out Kristian can just remove the
challenge code for his server from the dns zone and the resigning will fail.

I assume Let's encrypt asks TXT record for the _same_ FQDN each time. E.g.
_acme-challenge.hkps.pool.sks-keyservers.net. TXT "funny string here"

Also completely false. There can be more then one txt record for a given
hostname. Also they are not just random strings or encrypted requests.
They are hash-codes derived from some values that will not change during
cert renewal (like the private key for example). It would look like this:

hkps.pool.sks-keyservers.net.    IN    TXT    180    "admin x
verificationstring"
hkps.pool.sks-keyservers.net.    IN    TXT    180    "admin y
verificationstring"
hkps.pool.sks-keyservers.net.    IN    TXT    180    "admin z
verificationstring"

If somebodys server is compromised or they are detected to do things
they shouldn't Kristian can remove their txt record from dns and stop
them from renewing their cert.

Post by Gabor Kiss
How Kristian could "remove challenge code for _his_ server" selectively
if the DNS always contains the challenge _only_ of the latest
signing transaction?

Every server has it's own challenge code that stays the same as long as
the cert is just renewed and not re-generated. So removing one admin's
key is quite simple. Let's assume Admin Y needs to be forced out of the
pool:

nsupdate -l
  zone sks-keyservers.net
  del hkps.pool.sks-keyservers.net TXT "admin y verificationstring"
  send
  quit

Post by Gabor Kiss
Did I miss something?

Just everything.....

Post by Gabor Kiss
Regards
Gabor

[Kristian Fiskerstrand]

Post by Heiko Richter
The fact that your GPG client shows a secure connection is
either due to a faulty/incomplete validation algorithm that doesn't
check the ca signature of the servers cert or because "Kristian-CA" is
hardcoded into GnuPG. I don't know which one it is and don't really care
because both situations would be relics of 90s-incompetence that
compromise security and should have been removed from gnupg years ago.

Quite the contrary, this is the correct behavior from a security
perspective. And yes, the CA is included for the pool specifically.

Using HKPS from web browser is less of an issue as that is wrong use of
keyservers in nine out of ten situations as a local client is anyways
needed to properly validate the packet information provided in the
OpenPGP keyblock.

That said I'm a bit surprised about this discussion, nobody is required
to use a single pool of keyservers.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Amantes sunt amentes
Lovers are lunatics

[Heiko Richter]

Post by Kristian Fiskerstrand

Post by Heiko Richter
The fact that your GPG client shows a secure connection is
either due to a faulty/incomplete validation algorithm that doesn't
check the ca signature of the servers cert or because "Kristian-CA" is
hardcoded into GnuPG. I don't know which one it is and don't really care
because both situations would be relics of 90s-incompetence that
compromise security and should have been removed from gnupg years ago.

Quite the contrary, this is the correct behavior from a security
perspective. And yes, the CA is included for the pool specifically.
Using HKPS from web browser is less of an issue as that is wrong use of
keyservers in nine out of ten situations as a local client is anyways
needed to properly validate the packet information provided in the
OpenPGP keyblock.
That said I'm a bit surprised about this discussion, nobody is required
to use a single pool of keyservers.

And another person fighting for things that were abolished decades ago.

Sorry Kristian, but hardcoding a root certificate into a program has
*never* been any kind of accepted security system. Quite the opposite,
any program doing this is insecure because there is no way of revocing
that root certificate. Roots don't belong into programs but into trusted
certificate stores that are distributed in regular intervals and can be
updates independent of the program. I understand why this was done when
there was no other way, because Open Source projects don't have the
money to buy trusted certificates. But with the establishment of Let's
Encrypt that's just a security hole nobody needs anymore. You sign
certificates that are valid for a year and you have no way of revocation
that will make its way to the clients. That's just wrong.

And again: It's not about the browsers, the fact that they seem to be
the only programs that do *real* certificate validation because most
other software uses concepts out of the stoneage is not a reason. It's
the definition of stupidity!

[Heiko Richter]

BTW: That certificate you wanted to sign at December 22nd will not be
needed anymore. My server will adhere to security standards that have
been around for decades. It will not use certificates signed by
homegrown ca certificates that are hardcoded into software as it is a
serious system not coming from Insecurity-Central.

Any first-year-student will laugh at the concept of hardcoding public
keys into software.....



-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 19:23:51 +0100

Post by Kristian Fiskerstrand

Post by Heiko Richter
The fact that your GPG client shows a secure connection is
either due to a faulty/incomplete validation algorithm that doesn't
check the ca signature of the servers cert or because "Kristian-CA" is
hardcoded into GnuPG. I don't know which one it is and don't really care
because both situations would be relics of 90s-incompetence that
compromise security and should have been removed from gnupg years ago.

Quite the contrary, this is the correct behavior from a security
perspective. And yes, the CA is included for the pool specifically.
Using HKPS from web browser is less of an issue as that is wrong use of
keyservers in nine out of ten situations as a local client is anyways
needed to properly validate the packet information provided in the
OpenPGP keyblock.
That said I'm a bit surprised about this discussion, nobody is required
to use a single pool of keyservers.

And another person fighting for things that were abolished decades ago.

Sorry Kristian, but hardcoding a root certificate into a program has
*never* been any kind of accepted security system. Quite the opposite,
any program doing this is insecure because there is no way of revocing
that root certificate. Roots don't belong into programs but into trusted
certificate stores that are distributed in regular intervals and can be
updates independent of the program. I understand why this was done when
there was no other way, because Open Source projects don't have the
money to buy trusted certificates. But with the establishment of Let's
Encrypt that's just a security hole nobody needs anymore. You sign
certificates that are valid for a year and you have no way of revocation
that will make its way to the clients. That's just wrong.

And again: It's not about the browsers, the fact that they seem to be
the only programs that do *real* certificate validation because most
other software uses concepts out of the stoneage is not a reason. It's
the definition of stupidity!

[Daniel Kahn Gillmor]

Post by Heiko Richter
hardcoding a root certificate into a program has
*never* been any kind of accepted security system.

pinning certificates (either end-entity or further up the chain) is
considered a good practice in a design where there is an expected
service that will be connected to, and that service has a known
certificate management lifecycle.

You see this regularly in mobile app development. for example:

https://stackoverflow.com/questions/15728636/how-to-pin-the-public-key-of-a-certificate-on-ios

GnuPG is not a mobile app, but it does ship with some built-in knowledge
about the keyserver pool, and it uses that knowledge *specifically* for
the sake of secure connections to the pool.

This is commonly-accepted best practice because it reduces the exposure
to all the rest of the CA cartel mishegas.

Many thanks to Kristian for managing the pool for so long!

--dkg

[Alain Wolf]

Post by Kristian Fiskerstrand
That said I'm a bit surprised about this discussion, nobody is required
to use a single pool of keyservers.

That is certainly not the direction I wanted it to go with my initial post.

I personally, and I assume must of us, welcomed the decision of GnuPG to
bundle sks-keyservers.net root certificate. Anything to increase the
change of an encrypted connection from a "default-user" is welcome.

Letsencrypt as any other CA does not care whats going on the servers
they issue certificates for. Kristian apparently does and he does not
seem to be prepared to change that anytime soon. This of course has its
benefits and I fully respect that he is not willing to throw out the
baby with the bath water.

My initial post and request for automation as well as my own CSR was
derived from the information on the sks-keyservers.net website. Maybe
this needs to be clarified.

Unfortunately the problem of 95% of the server pool not supporting
HKPS out of the box remains unresolved. For now.

My opinion is still the same: Unencrypted HKP should be the exception
and HKPS the rule. The majority of the pool servers need to be in the
HKPS pool and HKP then might be slowly phased out and deprecated.

I will continue to look for ideas and I hope others will too.

With much respect.

Alain

[Kristian Fiskerstrand]

Post by Alain Wolf
Unfortunately the problem of 95% of the server pool not supporting
HKPS out of the box remains unresolved. For now.
My opinion is still the same: Unencrypted HKP should be the exception
and HKPS the rule. The majority of the pool servers need to be in the
HKPS pool and HKP then might be slowly phased out and deprecated.

From a security perspective that isn't necessary. OpenPGP is utilizing
object based security, whereby the packets are signed. So HKP has no
security implication.

From a privacy perspective, then yes, using HKPS transport is better,
but it doesn't improve anything if malicious servers are included in
some way that records information anyways, so having all servers
included reduces privacy, it doesn't improve anything, as long as the
pool itself is operational.

And fwiw, none of the geographical sub-pools are doing anything re HKPS,
that is a single global pool.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Timendi causa est nescire
The cause of fear is ignorance

[Kristian Fiskerstrand]

Post by Kristian Fiskerstrand
From a privacy perspective, then yes, using HKPS transport is better,
but it doesn't improve anything if malicious servers are included in
some way that records information anyways, so having all servers
included reduces privacy, it doesn't improve anything, as long as the
pool itself is operational.

I should add here that same goes for the Tor OnionBalance service.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"If you are successful, you may win false friends and true enemies.
Succeed anyway."
(Mother Teresa)

[dirk astrath]

Hi,

various regional pools.  It seems that the NA and OC pools quite often
contain hosts that are in Europe.  This could be because physical
geography and internet routing are two very different things but I think
more likely it is because the system(s) that are being used to measure
server performance are located in Europe and this skews the results.

One of my servers ( sks.fidocon.de ) is currently running on a virtual
server in singapur (for some reasons).

So ... don't assume, that a ".de"-domain-endpoint has to be in germany
... it the ip-adress for this domain can be anywhere in the world ... ;-)

Kind regards,

dirk

[Heiko Richter]

didn't send that one to the list, sorry.

-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Fwd: Re: Unde(r)served HKPS [was: Underserved
areas?]
Datum: Sun, 14 Jan 2018 19:15:59 +0100

Post by Moritz Wirth
All in all, what do you want to do? Just keep trusted certificates or
improve the numbers of HKPS Servers in the pool?

I just wrote that in several e-mail. Use established technologies to
distribute valid certificates. That way it's easy to increase the number
of servers in the pool. So it not an either or, but both!

Post by Moritz Wirth
So how many certificates are issued with OCSP Stapling? 0.001%? And of
course you need OCSP for that (which is not the case right now, but
yes you do not have the problem with a trusted CA). And what about
pool servers that do not use/do not support OCSP? You want to kick out
95% of all pool servers because they do not support HKPS? Great...

Any kind of CA has OCSP, so enabling OSCP stapling is just a problem for
people using insecure systems like selfsigned certificates and untrusted
CAs. Furthermore wether OCSP is used or not is not the question. The
question was abolishing the freaky non-secure selfsigned certificates
and homegrown CAs. Enabling OCSP stapling (where available) was just an
answer to you out-of-topic question earlier.

Post by Moritz Wirth
But let's go on and imagine we use Letsencrypt for HKPS. So I want a
new certificate, generate a DNS challenge and send it over to?
Kristian? Where is the difference with the current way of manually
signing a CSR? Or you want an API so you can change the records
yourself? How do you verify that and what keeps somebody from randomly
issuing certificates to other people over that API using his key? You
really want anybody to change the zone data? Or you really rely on
Kristian to set the TXT Records for 100 certificates every month? What
do you do if something happens and your certificate expires? Then you
still have your browser warning (or worse...).

For you and anybody else who didn't read and/or understand the email
about dns-01 challenge here it is again:
1) you create the challenge colde and send it to dns dns admin (which is
kristian).
2) he publishes it into the dns zone and tells you when he's finished
3) as long as your code is there your letsencrypt client will be able to
get it's certificate signed and renewd any time.
So in case of verification it's the same as right now. You send
something to Kristian and hope he trustes you. At the moment this is a
CSR. With Let's Encrypt it would be a DNS01 challenge code.
And who is talking about sending something every month????? Obviously
you don't know what you are talking about. The challenge code is
calculated *_ONCE_*, then published in DNS and as long as it's there you
can renew your certificate without talking to Kristian. Whenever he
decides you are not to be trusted he can delete your challenge code from
the DNS and your next renewal will fail.

Post by Moritz Wirth
Feel free to propose something how this might work (and maybe setup a
test environment for that)...

I did at least three times today, including this email. I hope you read
it this time.

Post by Moritz Wirth
I agree that well audited, highly secured CAs are better than a single
CA running somewhere on a simple server. but what keeps the CA from
issuing certificates without OCSP stapling? And even with OCSP
Stapling and revocation checking, if I have a trusted certificate I
can simply set a HPKP Header (lets just imagine these things really
work) so my leaf certificate is the only one that is trusted and serve
that to everybody that connects to my server and kill all other
trusted certificates for a very long time :)

Obviously nothing is 100% secure, but everything is more secure than the
homegrown "Kristian-CA" which is just crap. Everything I read on this
list is people like you fighting to keep crappy things that have
hundrets of security holes in them. Furthermore breaking the system with
something like you wrote there is much easier with the "Kristian-CA"
than it is in a professional environment with real trusted certificates
and CAs. Furhtermore there can be steps taken with the daily chekup
script that will remove your ip addresses from the pool automatically if
there's something not up to specs (e.g. checking certificate validity,
enabled ocsp stapling, which headers are send ......).

Post by Moritz Wirth
FWIW, if you really want a serious discussion about this, you probably
should stop calling everything you dont agree stupid, because right
now you are the one behaving childish. I think we have bigger problems
if aliens invade, but You are pretty sure that a CA would never issue
rogue certificates (remember Symantec and Google? ;)) 

At least 2 people answering to the list (including you) didn't read my
previous e-mail and assumed facts that were 100% *not incorrect*. Also
fighting for things like homegrown CAs which were abolished decades ago
for insecurity is the definition of stupidity.

Post by Moritz Wirth
But just my 2 cents...

Post by Heiko Richter

Post by Moritz Wirth
Certificate Revocation is broken in most browsers today so there is
no reliable way to revoke a certificate (especially if you do not
use OCSP).

They are ways to deal with that and any given trusted ca does so
(OCSP stampling and the must-staple header in certs just to name one
of them). Having an untrusted CA like "Kristian-CA" makes it
impossible to deal with that. Is there OCSP or any other kind of
revocation checking available that is supported by all (or most)
clients? I think not...

Post by Moritz Wirth
I don't think that it would be a big problem to get trusted
certificates for HKPS, however the trust problem stays the same and
it comes with other problems.
- You give up authority to a third party. Imagine, you validate the
chain of a certificate to the root and the intermediate changes
(because of compromise/BR Changes, whatever), it would break the
HKPS implementation of all clients.

1) thats how it is with every CA (including "Kristian-CA").
2) exchanging the intermediate CA is completely immaterial as long as
it is not revoked. class-3-rollovers are happening daily and they are
done in a completely transparant way the users won't notice.
3) Is there an intermediate ca to encrease security on "Kristian-CA"?
I Think not....
4) I would trust a large, trusted, audited CA anyday over a
"Kristian-CA". That's why they have audits secure their Root-CAs
offline in vaults whereas "Kristian-CA" is just a selfsigned
certificate, probably stored on some server that's connected to the
internet 24/7 and has not class 3 cert to increase security.
4) What kind of stupid argument is that? What happens if
"Kristian-CA" is compromised? Or is that unthinkable? Perhaps you
could set some time aside to discuss what will happen to the certs if
aliens invade, too....

Post by Moritz Wirth
- Trusted certificates may cost some money (except for Letsencrypt
but we have the validation problem there...)

We have no validation problem at Let's Encrypt. Just read my previous
message, I'm not willing to type it all again.

Post by Moritz Wirth
- It is still possible for an attacker to get a certificate and do
bad things with it so there is no advantage of selfsigned/Kristians
certificates over trusted certificates (except the browser warnings..)

Anything is possible. The problem is not if some social engineering
can give somebody a certificat. The problem is how can you revoke
that cert (with "Kristian-CA" you cannot, with Let's Encrypt and
OCSP-stapling you can). The other prblem is whether you are trusted
by the users. If they receive error messages on a daily basis or are
asked to import "Kristian-CA" that's just wrong and leaves them
clueless and ignorant in case such a message is really needed because
of a revoked cert. Selfsigned certs and untrusted ca certs belong in
experimental environments and learning children. In the real world
there are better ways to deal with security and trust and since
letsencrypt you can have them for free.

Post by Moritz Wirth
I am not sure how many people really use HKPS over the web browser,
most people just land on Port 11371 or Port 80.. For the SKS clients
it does not matter if the certificate is widely trusted as it has
the root included.

Well, just because GnuPG is fucked up in terms of certificate
validation doesn't mean you should use faulty certificates. Also
Several Browsers are moving to "All-HTTPS", so it's time to stop the
90s childish self-signed certificate crap and get serious about using
well-established technologies. It's a sad day that your argument for
not caring about correctly established certificate chains is that
GnuPG is faulty and doesn't check certificates correctly.

Post by Moritz Wirth
Best regards,
Moritz

Post by Heiko Richter
PS: Everything you wrote would have been true in 1998. The world of
SSL has evolved since then......
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.
Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be
possible.

Sorry, but this is just a flat-out-lie.
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Heiko Richter]

Post by Heiko Richter
didn't send that one to the list, sorry.
-------- Weitergeleitete Nachricht --------
Underserved areas?]
Datum: Sun, 14 Jan 2018 19:15:59 +0100

Post by Moritz Wirth
All in all, what do you want to do? Just keep trusted certificates or
improve the numbers of HKPS Servers in the pool?

I just wrote that in several e-mail. Use established technologies to
distribute valid certificates. That way it's easy to increase the
number of servers in the pool. So it not an either or, but both!

Post by Moritz Wirth
So how many certificates are issued with OCSP Stapling? 0.001%? And
of course you need OCSP for that (which is not the case right now,
but yes you do not have the problem with a trusted CA). And what
about pool servers that do not use/do not support OCSP? You want to
kick out 95% of all pool servers because they do not support HKPS?
Great...

Any kind of CA has OCSP, so enabling OSCP stapling is just a problem
for people using insecure systems like selfsigned certificates and
untrusted CAs. Furthermore wether OCSP is used or not is not the
question. The question was abolishing the freaky non-secure selfsigned
certificates and homegrown CAs. Enabling OCSP stapling (where
available) was just an answer to you out-of-topic question earlier.

Post by Moritz Wirth
But let's go on and imagine we use Letsencrypt for HKPS. So I want a
new certificate, generate a DNS challenge and send it over to?
Kristian? Where is the difference with the current way of manually
signing a CSR? Or you want an API so you can change the records
yourself? How do you verify that and what keeps somebody from
randomly issuing certificates to other people over that API using his
key? You really want anybody to change the zone data? Or you really
rely on Kristian to set the TXT Records for 100 certificates every
month? What do you do if something happens and your certificate
expires? Then you still have your browser warning (or worse...).

For you and anybody else who didn't read and/or understand the email
1) you create the challenge colde and send it to dns dns admin (which
is kristian).
2) he publishes it into the dns zone and tells you when he's finished
3) as long as your code is there your letsencrypt client will be able
to get it's certificate signed and renewd any time.
So in case of verification it's the same as right now. You send
something to Kristian and hope he trustes you. At the moment this is a
CSR. With Let's Encrypt it would be a DNS01 challenge code.
And who is talking about sending something every month????? Obviously
you don't know what you are talking about. The challenge code is
calculated *_ONCE_*, then published in DNS and as long as it's there
you can renew your certificate without talking to Kristian. Whenever
he decides you are not to be trusted he can delete your challenge code
from the DNS and your next renewal will fail.

Post by Moritz Wirth
Feel free to propose something how this might work (and maybe setup a
test environment for that)...

I did at least three times today, including this email. I hope you
read it this time.

Post by Moritz Wirth
I agree that well audited, highly secured CAs are better than a
single CA running somewhere on a simple server. but what keeps the CA
from issuing certificates without OCSP stapling? And even with OCSP
Stapling and revocation checking, if I have a trusted certificate I
can simply set a HPKP Header (lets just imagine these things really
work) so my leaf certificate is the only one that is trusted and
serve that to everybody that connects to my server and kill all other
trusted certificates for a very long time :)

Obviously nothing is 100% secure, but everything is more secure than
the homegrown "Kristian-CA" which is just crap. Everything I read on
this list is people like you fighting to keep crappy things that have
hundrets of security holes in them. Furthermore breaking the system
with something like you wrote there is much easier with the
"Kristian-CA" than it is in a professional environment with real
trusted certificates and CAs. Furhtermore there can be steps taken
with the daily chekup script that will remove your ip addresses from
the pool automatically if there's something not up to specs (e.g.
checking certificate validity, enabled ocsp stapling, which headers
are send ......).

Post by Moritz Wirth
FWIW, if you really want a serious discussion about this, you
probably should stop calling everything you dont agree stupid,
because right now you are the one behaving childish. I think we have
bigger problems if aliens invade, but You are pretty sure that a CA
would never issue rogue certificates (remember Symantec and Google? ;)) 

Last thing I forgot while writing this e-mail:

You just made my point. Verisign/Symantec doing their illegal braindead
stuff was detected because of the existing structures. Hardcoded root
certificates, homegrown CA certificates and selfsigned
childplay-certificates are just as wrong as the things Symantec did and
they are far mor ease to roll back as soon as a private key gets lost.
What's to stop sombody from stealing the "Kristian-CA" private key and
signing their own certs with it? I bet the private key of "Kristian-CA"
is on a system that is permanently connected to the internet and as soon
as that key gets lost *all* GnuPG installations can't be trusted to do
secure HKPS because some brainbug who didn't know the first thing about
security hardcoded that certificate into the software.

Post by Heiko Richter
At least 2 people answering to the list (including you) didn't read my
previous e-mail and assumed facts that were 100% *not incorrect*. Also
fighting for things like homegrown CAs which were abolished decades
ago for insecurity is the definition of stupidity.

Post by Moritz Wirth
But just my 2 cents...

Post by Heiko Richter

Post by Moritz Wirth
Certificate Revocation is broken in most browsers today so there is
no reliable way to revoke a certificate (especially if you do not
use OCSP).

They are ways to deal with that and any given trusted ca does so
(OCSP stampling and the must-staple header in certs just to name one
of them). Having an untrusted CA like "Kristian-CA" makes it
impossible to deal with that. Is there OCSP or any other kind of
revocation checking available that is supported by all (or most)
clients? I think not...

Post by Moritz Wirth
I don't think that it would be a big problem to get trusted
certificates for HKPS, however the trust problem stays the same and
it comes with other problems.
- You give up authority to a third party. Imagine, you validate the
chain of a certificate to the root and the intermediate changes
(because of compromise/BR Changes, whatever), it would break the
HKPS implementation of all clients.

1) thats how it is with every CA (including "Kristian-CA").
2) exchanging the intermediate CA is completely immaterial as long
as it is not revoked. class-3-rollovers are happening daily and they
are done in a completely transparant way the users won't notice.
3) Is there an intermediate ca to encrease security on
"Kristian-CA"? I Think not....
4) I would trust a large, trusted, audited CA anyday over a
"Kristian-CA". That's why they have audits secure their Root-CAs
offline in vaults whereas "Kristian-CA" is just a selfsigned
certificate, probably stored on some server that's connected to the
internet 24/7 and has not class 3 cert to increase security.
4) What kind of stupid argument is that? What happens if
"Kristian-CA" is compromised? Or is that unthinkable? Perhaps you
could set some time aside to discuss what will happen to the certs
if aliens invade, too....

Post by Moritz Wirth
- Trusted certificates may cost some money (except for Letsencrypt
but we have the validation problem there...)

We have no validation problem at Let's Encrypt. Just read my
previous message, I'm not willing to type it all again.

Post by Moritz Wirth
- It is still possible for an attacker to get a certificate and do
bad things with it so there is no advantage of selfsigned/Kristians
certificates over trusted certificates (except the browser warnings..)

Anything is possible. The problem is not if some social engineering
can give somebody a certificat. The problem is how can you revoke
that cert (with "Kristian-CA" you cannot, with Let's Encrypt and
OCSP-stapling you can). The other prblem is whether you are trusted
by the users. If they receive error messages on a daily basis or are
asked to import "Kristian-CA" that's just wrong and leaves them
clueless and ignorant in case such a message is really needed
because of a revoked cert. Selfsigned certs and untrusted ca certs
belong in experimental environments and learning children. In the
real world there are better ways to deal with security and trust and
since letsencrypt you can have them for free.

Post by Moritz Wirth
I am not sure how many people really use HKPS over the web browser,
most people just land on Port 11371 or Port 80.. For the SKS
clients it does not matter if the certificate is widely trusted as
it has the root included.

Well, just because GnuPG is fucked up in terms of certificate
validation doesn't mean you should use faulty certificates. Also
Several Browsers are moving to "All-HTTPS", so it's time to stop the
90s childish self-signed certificate crap and get serious about
using well-established technologies. It's a sad day that your
argument for not caring about correctly established certificate
chains is that GnuPG is faulty and doesn't check certificates correctly.

Post by Moritz Wirth
Best regards,
Moritz

Post by Heiko Richter
PS: Everything you wrote would have been true in 1998. The world
of SSL has evolved since then......
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.
Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be
possible.

Sorry, but this is just a flat-out-lie.
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Kristian Fiskerstrand]

I bet the private key of "Kristian-CA" is on a system that is
permanently connected to the internet and as soon as that key gets lost
*all* GnuPG installations can't be trusted to do secure HKPS because
some brainbug who didn't know the first thing about security hardcoded
that certificate into the software.

To make sure this isn't un-challenged in the archives, the secret key
never touches an online system, all operations are done on airgapped setup.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Qui audet vincit
Who dares wins

[Moritz Wirth]

Please dont get me wrong on this, but I think you missed something here.

https://community.letsencrypt.org/t/do-dns-challenge-records-have-an-expiration/33658


I did not read through this very long, but it seems that the challenge
record expires after 30 days, so you would need to update it at least
every 120 days (the expiration is in the ACME Spec).
https://community.letsencrypt.org/t/expiry-of-valid-authorizations-reduced-from-60-days-to-30-days/32959?source_topic_id=33658

It would be worse if the code would be valid forever - that would mean
that everybody with your account key is able to issue new certificates
for the sks domains. You are crying that somebody could steal the root
key and issue new certificates, but if you think that it is more secure
to have hundreds of account keys flying around on (probably) unpatched
webservers with unknown security flaws and backdoors (You want an
example? Equifax, Yahoo... They all paid millions for their security and
lost.. And I am pretty sure somebody there said that they adhered to
security standards too...) instead of a single machine which you can
simply unplug, you should probably do something else.

The second thing is, that OCSP Must-Staple is not enforced in a
certificate, so everyone who gets a token can issue a certificate
without it - the same goes for OCSP stapling. It CAN be enabled, but
nothing stops you from disabling it. So, revocation checks do not work.

Third thing, there is no easy way to revoke the trusted certificate, as
you don't have the private key, so a rouge certificate can only be
revoked by going directly to the CA and telling them to do so...


I agree, that the current situation with HKPS can be way better, but
your approach just has as much flaws as the current solution - btw.
running around and insulting other people is probably not a good idea if
you want people to listen to you.


I'll go get my popcorn..

Post by Heiko Richter
didn't send that one to the list, sorry.
-------- Weitergeleitete Nachricht --------
Underserved areas?]
Datum: Sun, 14 Jan 2018 19:15:59 +0100

Post by Moritz Wirth
All in all, what do you want to do? Just keep trusted certificates or
improve the numbers of HKPS Servers in the pool?

I just wrote that in several e-mail. Use established technologies to
distribute valid certificates. That way it's easy to increase the
number of servers in the pool. So it not an either or, but both!

Post by Moritz Wirth
So how many certificates are issued with OCSP Stapling? 0.001%? And
of course you need OCSP for that (which is not the case right now,
but yes you do not have the problem with a trusted CA). And what
about pool servers that do not use/do not support OCSP? You want to
kick out 95% of all pool servers because they do not support HKPS?
Great...

Any kind of CA has OCSP, so enabling OSCP stapling is just a problem
for people using insecure systems like selfsigned certificates and
untrusted CAs. Furthermore wether OCSP is used or not is not the
question. The question was abolishing the freaky non-secure selfsigned
certificates and homegrown CAs. Enabling OCSP stapling (where
available) was just an answer to you out-of-topic question earlier.

Post by Moritz Wirth
But let's go on and imagine we use Letsencrypt for HKPS. So I want a
new certificate, generate a DNS challenge and send it over to?
Kristian? Where is the difference with the current way of manually
signing a CSR? Or you want an API so you can change the records
yourself? How do you verify that and what keeps somebody from
randomly issuing certificates to other people over that API using his
key? You really want anybody to change the zone data? Or you really
rely on Kristian to set the TXT Records for 100 certificates every
month? What do you do if something happens and your certificate
expires? Then you still have your browser warning (or worse...).

For you and anybody else who didn't read and/or understand the email
1) you create the challenge colde and send it to dns dns admin (which
is kristian).
2) he publishes it into the dns zone and tells you when he's finished
3) as long as your code is there your letsencrypt client will be able
to get it's certificate signed and renewd any time.
So in case of verification it's the same as right now. You send
something to Kristian and hope he trustes you. At the moment this is a
CSR. With Let's Encrypt it would be a DNS01 challenge code.
And who is talking about sending something every month????? Obviously
you don't know what you are talking about. The challenge code is
calculated *_ONCE_*, then published in DNS and as long as it's there
you can renew your certificate without talking to Kristian. Whenever
he decides you are not to be trusted he can delete your challenge code
from the DNS and your next renewal will fail.

Post by Moritz Wirth
Feel free to propose something how this might work (and maybe setup a
test environment for that)...

I did at least three times today, including this email. I hope you
read it this time.

Post by Moritz Wirth
I agree that well audited, highly secured CAs are better than a
single CA running somewhere on a simple server. but what keeps the CA
from issuing certificates without OCSP stapling? And even with OCSP
Stapling and revocation checking, if I have a trusted certificate I
can simply set a HPKP Header (lets just imagine these things really
work) so my leaf certificate is the only one that is trusted and
serve that to everybody that connects to my server and kill all other
trusted certificates for a very long time :)

Obviously nothing is 100% secure, but everything is more secure than
the homegrown "Kristian-CA" which is just crap. Everything I read on
this list is people like you fighting to keep crappy things that have
hundrets of security holes in them. Furthermore breaking the system
with something like you wrote there is much easier with the
"Kristian-CA" than it is in a professional environment with real
trusted certificates and CAs. Furhtermore there can be steps taken
with the daily chekup script that will remove your ip addresses from
the pool automatically if there's something not up to specs (e.g.
checking certificate validity, enabled ocsp stapling, which headers
are send ......).

Post by Moritz Wirth
FWIW, if you really want a serious discussion about this, you
probably should stop calling everything you dont agree stupid,
because right now you are the one behaving childish. I think we have
bigger problems if aliens invade, but You are pretty sure that a CA
would never issue rogue certificates (remember Symantec and Google? ;)) 

At least 2 people answering to the list (including you) didn't read my
previous e-mail and assumed facts that were 100% *not incorrect*. Also
fighting for things like homegrown CAs which were abolished decades
ago for insecurity is the definition of stupidity.

Post by Moritz Wirth
But just my 2 cents...

Post by Heiko Richter

Post by Moritz Wirth
Certificate Revocation is broken in most browsers today so there is
no reliable way to revoke a certificate (especially if you do not
use OCSP).

They are ways to deal with that and any given trusted ca does so
(OCSP stampling and the must-staple header in certs just to name one
of them). Having an untrusted CA like "Kristian-CA" makes it
impossible to deal with that. Is there OCSP or any other kind of
revocation checking available that is supported by all (or most)
clients? I think not...

Post by Moritz Wirth
I don't think that it would be a big problem to get trusted
certificates for HKPS, however the trust problem stays the same and
it comes with other problems.
- You give up authority to a third party. Imagine, you validate the
chain of a certificate to the root and the intermediate changes
(because of compromise/BR Changes, whatever), it would break the
HKPS implementation of all clients.

1) thats how it is with every CA (including "Kristian-CA").
2) exchanging the intermediate CA is completely immaterial as long
as it is not revoked. class-3-rollovers are happening daily and they
are done in a completely transparant way the users won't notice.
3) Is there an intermediate ca to encrease security on
"Kristian-CA"? I Think not....
4) I would trust a large, trusted, audited CA anyday over a
"Kristian-CA". That's why they have audits secure their Root-CAs
offline in vaults whereas "Kristian-CA" is just a selfsigned
certificate, probably stored on some server that's connected to the
internet 24/7 and has not class 3 cert to increase security.
4) What kind of stupid argument is that? What happens if
"Kristian-CA" is compromised? Or is that unthinkable? Perhaps you
could set some time aside to discuss what will happen to the certs
if aliens invade, too....

Post by Moritz Wirth
- Trusted certificates may cost some money (except for Letsencrypt
but we have the validation problem there...)

We have no validation problem at Let's Encrypt. Just read my
previous message, I'm not willing to type it all again.

Post by Moritz Wirth
- It is still possible for an attacker to get a certificate and do
bad things with it so there is no advantage of selfsigned/Kristians
certificates over trusted certificates (except the browser warnings..)

Anything is possible. The problem is not if some social engineering
can give somebody a certificat. The problem is how can you revoke
that cert (with "Kristian-CA" you cannot, with Let's Encrypt and
OCSP-stapling you can). The other prblem is whether you are trusted
by the users. If they receive error messages on a daily basis or are
asked to import "Kristian-CA" that's just wrong and leaves them
clueless and ignorant in case such a message is really needed
because of a revoked cert. Selfsigned certs and untrusted ca certs
belong in experimental environments and learning children. In the
real world there are better ways to deal with security and trust and
since letsencrypt you can have them for free.

Post by Moritz Wirth
I am not sure how many people really use HKPS over the web browser,
most people just land on Port 11371 or Port 80.. For the SKS
clients it does not matter if the certificate is widely trusted as
it has the root included.

Well, just because GnuPG is fucked up in terms of certificate
validation doesn't mean you should use faulty certificates. Also
Several Browsers are moving to "All-HTTPS", so it's time to stop the
90s childish self-signed certificate crap and get serious about
using well-established technologies. It's a sad day that your
argument for not caring about correctly established certificate
chains is that GnuPG is faulty and doesn't check certificates correctly.

Post by Moritz Wirth
Best regards,
Moritz

Post by Heiko Richter
PS: Everything you wrote would have been true in 1998. The world
of SSL has evolved since then......
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100

Post by dirk astrath
Hello,

Post by Heiko Richter
fist of all CACert is total crap. They have been removed from the linux
distributions they were (falsely) included in and no browser ever
trusted them because they can't seem to pass the security audits. I
realize this comment will probably cause me a lot of ranting but it has
to be said that having certficates signed by CACert is no better then
signing them yourself.

We could now start a flame-war against CAcert and/or PGP, for or
against different styles of Web-Of-Trust, for or against different
tools to be installed to use the this Web-Of-Trust or inclusion in
mail- or webclients/browsers/distributions ... or not.
But we should not do it here ... ;-)
(NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.
Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

Post by dirk astrath

Post by Heiko Richter
Just use Let's Encrypt certificates. They are short lived certificates
and through the dns-01 challenge you will stay in control as you can

(..)

Post by Heiko Richter
That way you can drastically increase the amount of servers included in
the hkps pool while decreasing your workload and and having a huge plus
in security and trust through the validatable certificates.

Using LE (or any other being-in-the-browser-CA) will not easily be
possible.

Sorry, but this is just a flat-out-lie.
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

Post by dirk astrath
For your Keyserver you can use a Certificate issues by any CA as long
as it should not contain one of the pool names. On my server I decided
to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

Post by dirk astrath
To contain one (or more) of the pool names the certificate has to be
issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

Post by dirk astrath
But ...
Kristian will not hand over the private key for a pool-certificate to
anybody. If he would nearly "anybody" would be able to get the private
key and CA-signed certificate (as it's outside of Kristians control)
... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

Post by dirk astrath
Another way is setting up a CA by Kristian especially for this purpose
to create certificates only for keyserver-pool-names (and your
servername). Unfortunately this local CA is in the same status as your
self-signed certificate or CAcert: Not included in any mail-clients or
browsers.

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

Post by dirk astrath
But ...
This special "Kristian-CA"-case has advantages even without being in
The software to be used to "ask" the keyserver-pools can contain the
root-certificate of this CA ...
... and ... signing your webserver-key by "Kristian-CA" will show
others, that your server is a trusted server of the keyserver-pool (a
status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

Post by dirk astrath
Kind regards,
dirk

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel