On Apr 05, 2020, Adrian Zaugg wrote:
> Hi Dan
>
> On 05.04.20 13:12, Dan Purgert wrote:
> > OK, so now you've "verified(tm)" that you successfully got
> > "devuan_a1gn1ng_key" from https://devane.com/pgp.asc. Great that
> > you were able to verify the server. But you still got a bogus key
> > :)
> >
> > Which was pretty much my point -- TLS doesn't protect you from getting
> > sent the wrong key, if you somehow got directed to the wrong site...
> You will copy the link from the manual or the mail. Yes things can go
> wrong everywhere, even there. Because so many things can go wrong, one
> should reduce the risk that they do (and as well make it harder for
> attackers to succeed). It's a none argument to say a technique doesn't
> protects you from everything, so renounce on using it. In contrary, use
> what you can as long as its somewhat reasonable in resource consumption
> and effort it needs to set up. Writing https instead of http in a manual
> for one package is not so much of a job and for that one package the
> server will not go down because of increased load.

I'm not saying to throw away TLS in every case. I'm only saying that
TLS offers nothing for the transfer of a public PGP key. Frankly,
blindly trusting a public pgp key "just because you got it from
"https://somewhere.com" is actively detrimental in that now you're just
giving yourself a false sense of security.


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281