Sat, Aug 10
WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:
Tue, Aug 6
DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.
Jul 16 2019
Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.
I see. I am also mostly testing with ntbtls so I was wondering about the report. Thanks for reporting and fixing.
While I understand incorrectness, the risk in practice is not that high. So, I put this as "normal" priority.
Pushed the change to master as well as 2.2 branch.
Jul 15 2019
Jul 14 2019
Jul 11 2019
Is this really necessary to duplicate functionality that already is provided by Web Key Directory?
With NTBTLS, it seems it works correctly.
Jul 10 2019
I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.
Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.
Ah, that makes sense, good catch. Seems this is just an issue of documentation, then.
Jul 4 2019
And of course, thanks for your fix.
Applied to both branches. I have run no tests myself, though.
Fix will be in 2.2.17
I tried to implement this but this is troublesome for other programs using the interface because a common patter is to use --search-keys to get a listing and then use --recv-key to import the keys - That won't work and will require changes to --recv-key too. Thus this change will not go into 2.2. Anyway, it is not dangerous to have --search-keys because the new default for import from keyservers will be to strip all key-signatures.
Jul 3 2019
I asked you to carry this to a mailing list and not re-open this task.
My plan is to let --search-key be the same as locate-key but without local lookups, thus it will be the same as
That was pretty easy to reproduce thanks to your still not working server.
I did some manual tests using netcat and KS_FETCH to test the redirection.
I think you're suggesting accepting *any* path if the hostname of the proposed redirection matches openpgpkey.example.org when querying the WKD direct URL for an @example.org address. That would also be a fine solution from my point of view.
I head the same idea when I read your configuration. Given that the advanced lookup was not reallydeployed (see T4590) I also expect that we will receive complains now that it works. Thus white listing any "openpgpkey." seems to me a reasonable easy solution.
Will be in 2.2.17
Oh dear, that happens if one is always on master. I simply forgot to cherry pick the change from master back in November.
Two commits, though.
@werner, thanks for the pointer to the report, that's certainly useful. And i'm happy that organizations like SektionEins are doing GnuPG audits and publishing their results regardless of who paid for them.
See https://sektioneins.de/en/blog/18-11-23-gnupg-wkd.html for details. In short they fear that companies using IP based security for internal services can be attacked via redirect request and in particular becuase that can happen in the background without the user noticing. I am not concerned but we had long lasting discussions also with protonmail about this and the result was that we need to have this protection. We do not know who requested and paid for the audit from SektionEins and they won't tell us.