Fw: Re: Mercury

[defdefred]

sorry list email missing in my reply...

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday 25 June 2020 11:16, Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great defdefred once stated:
>
> > On Thursday 25 June 2020 00:03, Sean Conner sean at conman.org wrote:
> >
> > > How do you safely get my public key?
> >
> > By asking to you?
> > By checking on https://keys.openpgp.org/?
> > By checking on several server on a dedicate page of known public keys?
> > all of this...
>
> Okay, I'll be replying to several of your messages here because I'm
> getting mixed signals here. And then I can answer your questions.
>
> First:
>
> > It will also permit surfing at the speed of ligth with instant display of
> > clicked link... something that is no more existing in the
> > old-school-too-much dynamic web.
>
> and
>
> > Having TLS is better, but it come with a latency cost with the one
> > connection per request behavior. Freedom is also having the choice.
>
> It seems a primary concern of yours is overhead of establishing a
> connection. Well, TCP itself has overhead---three packets (at 40 bytes per)
> before the connection is considered "up". Yes, TLS increaases that bit
> more, but to say that there will be no latency without TLS is not a good
> argument. UDP has no latency, but there are other issues with using it [1].
>
> Continuing ...
>
> > Optional PGP signature is enough to provide integrity.
> > Are you sure that TLS is safe? States are allowing communication they
> > can't decipher?
>
> and
>
> > The fun fact is:
> >
> > -   with TLS, the whole server is using only one certficat and the integrity
> >     of publication rely only on this security and you don't know if it is a
> >     compromised server.
> >
> > -   with PGP signature, each writer using the server have his own certificat
> >     to secure his writing integrity.
> >
>
> and
>
> > When you are reading pgp signed document from a server where you own a
> > defined set of public pgp keys, you don't fear MITM attack (the same way
> > TLS is secure only with a PKI).
> > The difference is that external PGP signature are all computed only at
> > document publication time and not on the fly for each user request.
>
> It also seems you have reservations about the PKI infrastructure, which is
> fine, I do too. It seems you really distrust TLS. Okay. But PGP (for GPG
> for that matter) isn't the silver bullet you think it is. So let me answer
> you questions now.
>
> > By asking to you?
>
> Okay.HOW do I get you the public key and ensure you have it correctly?
> Yes, it's a public key, so there's no issue with people seeing it, but how
> do you know I am the one giving you the key?
>
> The only way I know of to be 100% certain is to exchange keys in person.
>
> > By checking on https://keys.openpgp.org/?
>
> I'll throw your own statement back at you: "you don't know if it is a
> compromised server." I don't know, and I think you don't know either.
> Again, your own words back at you: "Are you sure that TLS is safe? States
> are allowing communication they can't decipher?"
>
> > By checking on several server on a dedicate page of known public keys?
>
> Reduces the likelyhood of MITM, but still a pain.
>
> The hardest part of cryptography, by far, is key management. There is
> still no good way to distribute public keys that aren't subject to various
> attacks.
>
> -spc
>
> [1] Namely, you open yourself up to participate in amplified denial of
> service attacks. I used to run the QOTD service on UDP, until I
> realized I was getting requests from forged IP addresses and sending
> data to said forged IP addresses. This is why we can't have nice
> things on the Internet. [2]
>
> [2] QUIC. Yes, I know about it. Yes, I don't like it, and it will have
> similar issues to TCP. Yeah, yeah, Google says it has 0-connection
> overhead, but I don't know how hard it's been attacked yet. And
> guess what? That's yet another library dependency for a "simple
> client" because QUIC has no support in any kernel I know of, and
> probably won't for several years. I also don't trust Google, but
> that's my issue.