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

[Alain Wolf]

On 11.01.2018 20:06, Andrew Gallagher wrote:
> On 11/01/18 17:16, Alain Wolf wrote:
>> 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. ;-)

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

> 
> 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?

> 
> 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?

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

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

I did 106 days ago.


-- 
pgpkeys.urown.net 11370 # <address@hidden> 0x27A69FC9A1744242

signature.asc
Description: OpenPGP digital signature