Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]

[Heiko Richter]

Am 14.01.2018 um 12:40 schrieb Gabor Kiss:
>> 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.
> 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.
> (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.
>
> At this point I don't understand exactly this sentence:
>
>> 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.
>
> 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

>
> Did I miss something?
Just everything.....
>
> Regards
>
> Gabor

signature.asc
Description: OpenPGP digital signature