WKD v05: DNS problem when requesting pubkey

[Bernhard Reiter]

Am Donnerstag 05 April 2018 13:35:42 schrieb Peter Lebbing:
> On 05/04/18 12:50, Werner Koch wrote:
> > Which also means they can't do proper keyserver lookups.  Or implement
> > XMPP or any other protocol with mandatory SRV record.  SRV records are
> > in use for more than 18 years:
>
> My guess is all these use cases have so far been covered by helper
> routines (or complete clients) running on a server.

I did inspect one XMPP implementation offering for the webbrowser
(randomly found by using duckduckgo) to verify that thought and found they 
were indeed using a server component (based on php in this case).
In addition I saw problem reports of the webbrowser makers for http many years 
old that still recently got a won't fix. Browser makers claim:
 * for http is is a performance penalty
 * if it to be implemented in http it had to be agreed in an 
   (upcoming) standard for http
For understandable reasons the do not implement general networking
as it would violate their security model around the same origin policy.

> On 05/04/18 12:02, Bernhard Reiter wrote:
> > [...] using a service degrades the
> > security of the request as it gets to be attacked by the service
> > provider.
>
> I'm not convinced this is the case. If the service runs on the same
> server as the one hosting the web client, that server can already inject
> any code in the web client itself. [..]

> Is it really that black and white or am I missing a scenario?

A web-extension is code that runs locally in the browser, is bound to the API 
limitations (with some exceptions like "Native Messaging"). Thus it can do 
WKD requests based on HTTPS only independently of the server.
(For context see https://github.com/mailvelope/mailvelope/wiki/mw2018 where 
want to improve the Web-Extention Mailvelope, which triggered these 
thoughts.)


> But another fix would be to allow a special host record (A, AAAA or
> CNAME) with something like _wkd.example.com. I'm not saying that should
> be its form, it's the general idea.

Thanks for this additional idea and the feedback!

Best Regards,
Bernhard


-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/623d3174/attachment.sig>