Re: WKD proper behavior on fetch error
On Thu, Jan 14, 2021 at 1:50 AM Ángel wrote: > PPS: Another benefit would be that we could have avoided this long > thread. :-) The greatest benefit would have been if the author of WKD, namly Werner Koch, had been so kind to explain to us why WKD needs two methods and what security implications it has when an application falls back to a valid direct-method, instead of people defending him or his implementation. :-) Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote: > I'd like to clarify what Sequoia is doing (wrong). > (...) Hello Neal Thanks for chiming in and explaining the steps taken by sequoia. I'll try to re-focus this subthread back on the initial topic of your email. > The I-D says "Only if the required sub-domain does not exist, they > SHOULD fall back to the direct method." The text doesn't say: "If > there is an error, they SHOULD fallback to the direct method unless > the required sub-domain does not exist, in which case they MUST NOT > fall back to the direct method." So, strictly speaking, I don't > think Sequoia is violating the specification. I understand this to mean it as "only use the direct method if the required sub-domain does not exist", with the SHOULD meaning that the direct method is not required (not sure why, I would have probably used a MUST). As such, I do think sequoia is non-conformant, although I'm more interested in determining the proper behaviour of a WKD client. > We thought about this question, but we couldn't figure out a > satisfactory answer. The worst attack we could come up with is: > (...) > So sure, that's possible, but it seems like WKD shouldn't foo.com's > biggest worry in that case. I can make up some scenarios where foo.com is hosted on EvilCDN and openpgpkey.foo.com in a safe server. But I agree that's not too likely. I think it would be good that sq stopped after processing openpgpkey.foo.com, mainly to follow the principle of least surprise. If the key can only be placed in one place, then it MUST be good (or bad, but it will be consistent). If the admins wanted to use the advanced method, but misconfigured it, while testing only with sequoia (but having a good direct method), they would be misled to think WKD is properly implemented, while it is not. The team managing foo.com may be completely different (e.g. marketing) than those handling pgp keys (e.g. email sysadmins). By keeping the openpgpkey subdomain for themselves, the admins can give complete control of the apex website to marketing (known to fill their credentials on phishing pages from time to time) without letting them any access to publish pgp keys. Hard to debug errors: "when fetching your key via wkd, I do receive your key from your server, but it expired in 2018!" can have people scratching their head for a long time (the last key is there, there is no 2018 key stored here…) until figuring that the server certificate of openpgpkey.foo.com expired (and they had an old key on the main website). A direct error "Certificate of openpgpkey.foo.com expired 2 days ago" would have been much clearer. > On the other hand, implementing this prohibition means that a DNS > server can prevent its clients from using WKD by forcing all > openpgpkey subdomains to resolve to 127.1. That's hard to notice, > because everything else still appears to work. I think it's the other way round. If sequoia falls back to the direct method and returns "No WKD key published for j...@foo.com", it will get unnoticed. A hard error of "Couldn't connect to openpgpkey.foo.com (127.0.0.1)" or "The certificate of openpgpkey.foo.com (1.2.3.4) is not trusted" would make it noticeable. Probably the most important part of the rule: "all implementations of WKD should behave in the same way". I don't mind if it was gnupg that was changed to behave like sequoia, but given identical conditions, ideally all clients (and the draft reading) should produce the same result (find key X, an error, etc.). > we helped an organization deploy WKD, and they had a similar problem… It was misconfigured. Spawning a https server for openpgpkeys (as they did) is a way to solve it. They could as well have made a openpgpkeys record pointing to the same server as the apex domain, and use a certificate with both names. Or even install the keys on the server providing the 404. It seems the wrong to make it an issue for the client to figure out where the keys may be. There is a long story of browsers helpfully "fixing" the encoding or Content-type of files, which caused a lot of harm in the long term to avoid security issues derived from browser sniffing changing to insecure defaults, when people really meant what they said. It seems difficult the same could happen here, but the idea that the server should be properly set up, rather than the client fixing the errors for the user is the same. I would recommend to remove the or_else case and fail with an error if the advanced method is (supposedly) set up but fails. At least, I think there should be a diagnostic e.g. "WKD advanced method configured but broken. Connection to openpgpkey.foo.com (1.2.3.4) failed: Bad certificate. Trying direct method" although I would prefer a hard error. (Of course, if the user explicitly requested the client/library to only use the direct method, ignore certificate errors, etc. it'd be fine to do so) Best regards PS: If I'm reading your code cor
Re: WKD & Sequoia
On Wed, Jan 13, 2021 at 11:45 PM André Colomb wrote: > > Am 13. Januar 2021 21:44:07 MEZ schrieb Stefan Claas via Gnupg-users > : > >Hi Juergen, > > > >looks like you are a bit upset, like probably others as well. > > I hope others don't mind me speaking in their names. Stefan, we are upset by > you making false accusations about which software does something right or > wrong. Both softwares are reacting differently to an error which lies in your > TLS certificate usage (as several people have proven multiple times). You're > not even to blame for that root cause, because it is not under your control. > Don't only look at the end result, but please try to understand that the > cause lies deeper than just the spec or the clients you tried. I am fully ok with that. All my replies here where not intended to "accuse" someone! In my OP I kindly asked if a kind soul can help me and IIRC it was mentioned that the direct method is fine and I figured out that GnuPG seems not to try the direct method while sequoia-pgp tries the direct method. It had been *really* nice if Werner had chimed in, like Neal, and had explained by himself why this is a definetly a no-go to try the direct-method first, or in case why when the advanced method failed it does not try the direct method and what security implications this has. Maybe, I don't know, readers here on the ML are asking themselves now why do we have two methods, e.g. what is their purpose and what informations can one gain from an IMHO very nice WKD checker, Wiktor has created. If the draft will be changed in the future to only allow the advanced-method and the direct-method will be dropped, ok, I have to accept this, for GitHub usage and whatever sites have a similar set-up and that's it. Then maybe a question, from readers may come up, why it was dropped, when it was implemented in the first place, regardless of GitHub etc. > >I am not aware how their network is set-up and it is not my business, > >but would you not agree that it would be very nice to have a wildcard > >subdomain solution, for all their inhouse offices and employees email > >addresses, while managing themselves key distribution? > > It's a little unclear what *exactly* you mean with "a wildcard subdomain > solution". WKD can work perfectly with wildcards involved, both on the DNS > and TLS levels. But such things can be misconfigured and the spec even > explicitly mentions one possible pitfall including a solution. I think I have explained, at least for an expert like you, my set-up for 300baud.de, I would use. As soon as time permits I will do this, even if this cost me money I can spend for other things. But I gives me then a better overview and I can correct myself while thinking my set-up would be equally to GitHub's set-up. In case I get stucked I would like to ask you for advise. Please note: I will not use the advanced method, I like to see if this will work with sequoia-pgp and GnuPG. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
Am 13. Januar 2021 21:44:07 MEZ schrieb Stefan Claas via Gnupg-users : >Hi Juergen, > >looks like you are a bit upset, like probably others as well. I hope others don't mind me speaking in their names. Stefan, we are upset by you making false accusations about which software does something right or wrong. Both softwares are reacting differently to an error which lies in your TLS certificate usage (as several people have proven multiple times). You're not even to blame for that root cause, because it is not under your control. Don't only look at the end result, but please try to understand that the cause lies deeper than just the spec or the clients you tried. >I am not aware how their network is set-up and it is not my business, >but would you not agree that it would be very nice to have a wildcard >subdomain solution, for all their inhouse offices and employees email >addresses, while managing themselves key distribution? It's a little unclear what *exactly* you mean with "a wildcard subdomain solution". WKD can work perfectly with wildcards involved, both on the DNS and TLS levels. But such things can be misconfigured and the spec even explicitly mentions one possible pitfall including a solution. Reactions to that kind of misconfiguration should also be standardized in the spec. That's all there is to criticize, IMHO. Kind regards André -- Greetings... From: André Colomb ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
On Wed, Jan 13, 2021 at 10:00 PM Erich Eckner via Gnupg-users wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Wed, 13 Jan 2021, Juergen Bruckner via Gnupg-users wrote: > > > Hello Stefan! > > Hi all, > > > > > > > [...] > >> sequoia did the right step and I hope for people relying on GnuPG that > >> it is possible for them in the future too. > > > > So did Sequoia do that? > > You consider not to follow policies "the right step"? > > Sorry, but you dont have a clue about security! > > > > The only right way is to follow policies word by word. > > That is certainly correct. But: WKD is "just" a draft, so it's open to > suggestions for change. "Ignore invalid certificates of the advanced URL" > is one suggestion. Correct a suggestion and Neal for example discussed this with his team in the past and they gave users, like me, the ability for a working solution, without IMHO breaking the specs. > In my view, this whole, lengthy thread boils down to the question, whether > we want that or we don't want that. Well, I see this a bit different. If it comes to discussions or votes on this ML here or the IETF ML, than this is only a minority IMHO and it can also been down voted etc. As you said this is a draft It should formulated this way IMHO that it allows the greatest flexibility in a protokoll, to fulfill all use cases, when it comes to WKD. I also understand that WKD is Werner's baby but when a draft or an RFC is present than it should be allowed to have a healthy discussion. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 13 Jan 2021, Juergen Bruckner via Gnupg-users wrote: Hello Stefan! Hi all, [...] sequoia did the right step and I hope for people relying on GnuPG that it is possible for them in the future too. So did Sequoia do that? You consider not to follow policies "the right step"? Sorry, but you dont have a clue about security! The only right way is to follow policies word by word. That is certainly correct. But: WKD is "just" a draft, so it's open to suggestions for change. "Ignore invalid certificates of the advanced URL" is one suggestion. In my view, this whole, lengthy thread boils down to the question, whether we want that or we don't want that. Let me share my two cents: I *feel*, like invalid certificates of advanced WKD URLs should not be ignored, because this indicates, something is not as it should be (e.g. it is "unclean"). The fact, that this might slow down WKD deployment, because it makes the dns setup *slightly* harder, stands against this feeling. btw: I just recently changed (motivated by this thread) from the direct to the advanced method of WKD deployment, eliminating the need for a reverse proxy on archlinux32.org - and the need for a "no-wildcard" TXT record on openpgpkey.archlinux32.org. ... why on earth did I set it up with the direct method in the first place? ;-) regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl//XlgACgkQCu7JB1Xa e1rm+Q/+ImdVv9mimg7aRC5aceS/iYqqZwUhWdvVZEs6s/9bVJf1Ur1MyhoySU2U BhDZknlwJY9UUw54x1Pk2wASABlzpcpr2XmTLmgmpBr3ti3nMkhK/fDLT537EOlz H8ngzdUA/Hj3suGlhfMgGoUyh2PDsF9N3y3mPVKs0ym7qWaPwSc6NPi05pKzetYk Y4qPIezFD8vX3dWUJTShVgppdusWtekKmPJ8oFAb+J+Ccwc+G/oaTysfH2X5azF9 YOnWb5Sed61fqynPjTFcJ5uTwCnxl9e96plCaw2kricBGoH+/siskO0KYZ0aWGrB 5b4vKDJd+gmu8Iwb3vKSKUsFpK5ek9M9IThGKA8etNYjYDkLzWTmXjZ3+HjvaF/+ zf+koPNWZIPmd6g2HMGyM5k7nftfg3Qze8NDDvR1JN68+0kKxdMl5Hf0OAZ0Babj luRqFcLw8rLZWd93DsiTevYMFa3vTnao2S0fHgoBpgCeTpeW/euDJWKH/0N8Bnjk zarOhDXSDJQZEi76zIgicE7eWY7VgYJcf3xolAmuA90Qf7UOdor5Ub4KWLgrMgQd NTwsP7tqrXougtcmIoe7MXTdiacO7bSKxPso7z3e53FeDH+pvO9j8q8T99zWSvFR JXVxAZ8dTO3INA7GwLAY2pa5IY8WTeJCSh0fj0P+QArezFd1NeA= =tA3p -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
On Wed, Jan 13, 2021 at 9:24 PM Juergen Bruckner via Gnupg-users wrote: > > Hello Stefan! > > > [...] > > sequoia did the right step and I hope for people relying on GnuPG that > > it is possible for them in the future too. > > So did Sequoia do that? > You consider not to follow policies "the right step"? > Sorry, but you dont have a clue about security! > > The only right way is to follow policies word by word. > > So far you only presented us assumptions here, with a non working setup, > and also a setup which never was intended for such a case. Hi Juergen, looks like you are a bit upset, like probably others as well. That is good and I hope people understand what this whole thread is about! Regarding security, can you give us a valid example what security implications you see? I trust the sequoia team, for example, strongly assuming, that they know how to implement fetching a binary blob without any problems. BTW. If I remember correctly you once (or I did that?) presented a link from Austrian Goverment authorities using OpenPGP keys on their web pages. I am not aware how their network is set-up and it is not my business, but would you not agree that it would be very nice to have a wildcard subdomain solution, for all their inhouse offices and employees email addresses, while managing themselves key distribution? BTW. For GitHub users ... :-) ( a nice addition too, when it comes to OpenPGP keys) https://keyoxide.org/guides/github Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
Hello Stefan! [...] sequoia did the right step and I hope for people relying on GnuPG that it is possible for them in the future too. So did Sequoia do that? You consider not to follow policies "the right step"? Sorry, but you dont have a clue about security! The only right way is to follow policies word by word. So far you only presented us assumptions here, with a non working setup, and also a setup which never was intended for such a case. m2c Juergen -- /¯\ No | \ / HTML |Juergen Bruckner Xin |juergen@bruckner.email / \ Mail | smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
On Wed, Jan 13, 2021 at 7:26 PM André Colomb wrote: > > On 13/01/2021 17.56, Stefan Claas wrote: > >> What are droplets? For which domain did you generate a wildcard > >> certificate? What are the DNS settings on that domain? I could take a > >> look at what responses are returned from the real domain, but need some > >> information at least which OpenPGP user ID should be fetchable over WKD > >> from that domain. If you're even interested in learning about how to > >> set up WKD properly. > > > > Digital Ocean calls their VPS servers droplets and If I would set them up > > as a test rig, I would use three, like '300baud.de', 'foo.300baud.de' > > and 'bar.300baud.de'. In 300baud.de I would set up the WKD directory and > > the SSL cert, with an entry for wildcard subdomains which would cover then > > hosts foo and bar. In the WKD directory I would put then a couple of keys > > with > > proper sample email addresses from all three hosts. > > That's a lot of "ifs". Right now, 300baud.de has neither A nor nor > CNAME record, so there is no server IP address to contact. Obviously > there is also no wildcard record either, as e.g. www.300baud.de does not > resolve. It's not clear to me which (sub)domain you would want to use > in a fictional OpenPGP key's user ID? There is currently no server running under my 300baud.de domain. I had to shut them down due to recent changes in DO's TOS. > > > With this set-up, without noodling around with records settings at my domain > > service (for ease of use and managing WKD) I stronly assume that this > > set-up follows the direct method and works with sequoia-pgp properly and > > should fail currently with GnuPG and gpg4win,same as it fails with GitHub. > > It's actually pretty easy. If the openpgpkey... subdomain resolves > (explicit entry or DNS wildcard), then the advanced method is used. > Otherwise the simple method. That's the only difference, and it does > not depend on whatever your certificate contains. > > Depending on the chosen method, you need to make sure that there is a > web server answering with a *valid* TLS certificate and with the proper > expected directory structure. There is no reason at all to "strongly > assume" any malfunction or bug in GnuPG and I assure you that it's > possible to make either method work. Mmmh, probably we can discuss this *valid* until we get blue in the face ... > > The only difference for Sequoia is that it ignores your expressed intent > to use the advanced method if something is misconfigured, and falls back > to the simple method. GnuPG does not do that, because it correctly > follows the specification word by word. Which would make sense to me and thankfully sequoia-pgp does this. > > IIRC the (old) WKD specs did not mention nor did they said that it was > > required > > to noodle around witth domain settings, regarding the openpgpkey folder when > > setting up records for hosts with a domain service provider. > > WKD is still an Internet *Draft*, so it's expected to find corner cases > like yours that are not yet 100 % unambiguous. That's what the drafting > process and public discussion is intended for. Different > interpretations should not be possible, and you found a case where > Sequoia and GnuPG really do differ. But it still does *not* say one > needs to "noodle around with domain settings". It points you to the > right spice to add just in case your domain settings are already a > noodle soup. Draft, yes I know and I desperately hope with this whole thread that Werner and most important OpenPGP users and organizations around the globe think about this, because it could have IMHO a *major* impact for OpenPGP key distribution, when it comes to easy set-up and maintaining themselve a WKD service while not relying on third parties, like Hagrid or later the hockeypuck Network, for whatever reasons people may have. sequoia did the right step and I hope for people relying on GnuPG that it is possible for them in the future too. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
On 13/01/2021 17.56, Stefan Claas wrote: >> What are droplets? For which domain did you generate a wildcard >> certificate? What are the DNS settings on that domain? I could take a >> look at what responses are returned from the real domain, but need some >> information at least which OpenPGP user ID should be fetchable over WKD >> from that domain. If you're even interested in learning about how to >> set up WKD properly. > > Digital Ocean calls their VPS servers droplets and If I would set them up > as a test rig, I would use three, like '300baud.de', 'foo.300baud.de' > and 'bar.300baud.de'. In 300baud.de I would set up the WKD directory and > the SSL cert, with an entry for wildcard subdomains which would cover then > hosts foo and bar. In the WKD directory I would put then a couple of keys with > proper sample email addresses from all three hosts. That's a lot of "ifs". Right now, 300baud.de has neither A nor nor CNAME record, so there is no server IP address to contact. Obviously there is also no wildcard record either, as e.g. www.300baud.de does not resolve. It's not clear to me which (sub)domain you would want to use in a fictional OpenPGP key's user ID? > With this set-up, without noodling around with records settings at my domain > service (for ease of use and managing WKD) I stronly assume that this > set-up follows the direct method and works with sequoia-pgp properly and > should fail currently with GnuPG and gpg4win,same as it fails with GitHub. It's actually pretty easy. If the openpgpkey... subdomain resolves (explicit entry or DNS wildcard), then the advanced method is used. Otherwise the simple method. That's the only difference, and it does not depend on whatever your certificate contains. Depending on the chosen method, you need to make sure that there is a web server answering with a *valid* TLS certificate and with the proper expected directory structure. There is no reason at all to "strongly assume" any malfunction or bug in GnuPG and I assure you that it's possible to make either method work. The only difference for Sequoia is that it ignores your expressed intent to use the advanced method if something is misconfigured, and falls back to the simple method. GnuPG does not do that, because it correctly follows the specification word by word. > IIRC the (old) WKD specs did not mention nor did they said that it was > required > to noodle around witth domain settings, regarding the openpgpkey folder when > setting up records for hosts with a domain service provider. WKD is still an Internet *Draft*, so it's expected to find corner cases like yours that are not yet 100 % unambiguous. That's what the drafting process and public discussion is intended for. Different interpretations should not be possible, and you found a case where Sequoia and GnuPG really do differ. But it still does *not* say one needs to "noodle around with domain settings". It points you to the right spice to add just in case your domain settings are already a noodle soup. Kind regards André -- Greetings... From: André Colomb signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
On Wed, Jan 13, 2021 at 8:42 AM Daniele Nicolodi wrote: > > On 12/01/2021 23:30, Stefan Claas wrote: > > The reason why I like also the option for, let's say github.io pages > > is that, like I have shown in the whole thread that a very well known > > site like GitHub, with it's millions of software developes allows one > > to host, via WKD, a mutli-purpose usage public-key without revealing > > to much details. > > I still don't understand why you insist on WKD when it seems to do not > support your use case, nor to offer any advantage over a simpler > > wget -O- https://sac001.github.io/foobar.asc | gpg --import > > given that the relation between the identifiers > "ste...@sac001.github.io" or "https://sac001.github.io/foobar.asc"; and > the key you are retrieving is the same, ie none. Hi Dan, Good question, WKD is a valid option to retrieve pub keys with OpenPGP apps people use and rely on. I could for example also use curl to retrieve keys from Hagrid or SKS. ;-) Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
On Wed, Jan 13, 2021 at 4:36 PM André Colomb wrote: > > Hi Stefan, > > On 13/01/2021 17.07, Stefan Claas wrote: > > On Wed, Jan 13, 2021 at 10:22 AM André Colomb wrote: > > > >> So the core problem, as with Stefan's case, is the lack of control over > >> the domain's DNS settings. Which the WKD mechanism relies upon to > >> delegate trust to the domain operators. > > > > Hi Andre, I wouldn't formulate it this way. I already mentioned that I am > > able > > to set up for my 300baud.de domain a couple of droplets and use as suggested > > a valid wildcard subdomain cert, like I explained with the bund.de example > > and > > I am pretty sure that GnuPG and gpg4win will then fail, same as with GitHub. > > Sorry, I have no clue what is configured, what works and what should > work regarding WKD on your 300baud.de setup. Can we please stick to one > real example, not something made up about bund.de? > > What are droplets? For which domain did you generate a wildcard > certificate? What are the DNS settings on that domain? I could take a > look at what responses are returned from the real domain, but need some > information at least which OpenPGP user ID should be fetchable over WKD > from that domain. If you're even interested in learning about how to > set up WKD properly. Digital Ocean calls their VPS servers droplets and If I would set them up as a test rig, I would use three, like '300baud.de', 'foo.300baud.de' and 'bar.300baud.de'. In 300baud.de I would set up the WKD directory and the SSL cert, with an entry for wildcard subdomains which would cover then hosts foo and bar. In the WKD directory I would put then a couple of keys with proper sample email addresses from all three hosts. With this set-up, without noodling around with records settings at my domain service (for ease of use and managing WKD) I stronly assume that this set-up follows the direct method and works with sequoia-pgp properly and should fail currently with GnuPG and gpg4win,same as it fails with GitHub. IIRC the (old) WKD specs did not mention nor did they said that it was required to noodle around witth domain settings, regarding the openpgpkey folder when setting up records for hosts with a domain service provider. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
Hi Stefan, On 13/01/2021 17.07, Stefan Claas wrote: > On Wed, Jan 13, 2021 at 10:22 AM André Colomb wrote: > >> So the core problem, as with Stefan's case, is the lack of control over >> the domain's DNS settings. Which the WKD mechanism relies upon to >> delegate trust to the domain operators. > > Hi Andre, I wouldn't formulate it this way. I already mentioned that I am able > to set up for my 300baud.de domain a couple of droplets and use as suggested > a valid wildcard subdomain cert, like I explained with the bund.de example and > I am pretty sure that GnuPG and gpg4win will then fail, same as with GitHub. Sorry, I have no clue what is configured, what works and what should work regarding WKD on your 300baud.de setup. Can we please stick to one real example, not something made up about bund.de? What are droplets? For which domain did you generate a wildcard certificate? What are the DNS settings on that domain? I could take a look at what responses are returned from the real domain, but need some information at least which OpenPGP user ID should be fetchable over WKD from that domain. If you're even interested in learning about how to set up WKD properly. Kind regards André -- Greetings... From: André Colomb signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
On Wed, Jan 13, 2021 at 10:22 AM André Colomb wrote: > So the core problem, as with Stefan's case, is the lack of control over > the domain's DNS settings. Which the WKD mechanism relies upon to > delegate trust to the domain operators. Hi Andre, I wouldn't formulate it this way. I already mentioned that I am able to set up for my 300baud.de domain a couple of droplets and use as suggested a valid wildcard subdomain cert, like I explained with the bund.de example and I am pretty sure that GnuPG and gpg4win will then fail, same as with GitHub. Regarding Neal's attack example, I also posted here an idea to make it for Mallory harder, to exchange (a) key(s) from a host, serving a WKD directory, which also does not break the specs, by simply adding to the policy file the fingerpint(s) and putting verifiable .ots file(s), in for example, the hu folder. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
Hi Neal, thanks for chiming in with details about your implementation. It's now clear that the wrong certificate in fact triggers an alarm, which is good. Only the fall-back behavior differs from GnuPG. Since Stefan set up the direct method as well, that leads to his setup actually working with Sequoia. On 13/01/2021 10.12, Neal H. Walfield wrote: > So, the hostname mismatch is correctly identified, and it correctly > returns an error. > > Where sq's behavior diverges from gpg's is that sq then tries the > direct method, but gpg does not. I agree that this is the culprit why the two implementations differ. > The I-D says "Only if the required sub-domain does not exist, they > SHOULD fall back to the direct method." The text doesn't say: "If > there is an error, they SHOULD fallback to the direct method unless > the required sub-domain does not exist, in which case they MUST NOT > fall back to the direct method." So, strictly speaking, I don't think > Sequoia is violating the specification. The way I read it, "SHOULD fall back" means that it can opt not to fall back at all. The sentence begins with "Only if ... does not exist", so the whole SHOULD statement just doesn't apply if the subdomain does exist. Proper behavior when the subdomain exists, but some other error occurs, is undefined in the spec. There is certainly room for improvement / clarification here. > But, I don't want to be overly pedantic. Even if the spec were to > prohibit falling back to the direct method when the subdomain exists, > what exactly would this prohibition gain us? The whole point in my opinion is to give the domain admin control over the WKD resolution process. By blocking the openpgpkey subdomain from resolving, they can avoid needless HTTPS request handling, as I explained in detail before: https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064622.html > (If we overlooked possible attacks, I'd be happy to hear about them.) I don't see any big *security* implications either, but I'm really no expert on that topic. There seems to be good reasons for why the I-D specifies it exactly as it does, namely to give a way to control which server automated WKD requests go to and keeping the load as small as possible. > On the other hand, implementing this prohibition means that a DNS > server can prevent its clients from using WKD by forcing all > openpgpkey subdomains to resolve to 127.1. That's hard to notice, > because everything else still appears to work. One can't really prohibit anyone from *trying* to request a resource over some HTTPS URL, especially not in a protocol specification. But the current WKD draft tries to specify at which point a well-behaved WKD client makes the decision on the "correct" method. > Practically speaking, we helped an organziation deploy WKD, and they > had a similar problem to what Stefan is observing: the admins setup > the direct method, but it didn't work, because their DNS automatically > resolved all unknown subdomains to serve a 404. Unfortunately, they > had outsourced management of their DNS and couldn't (or didn't know > how) to disable this behavior. IIRC, in the end, they spun up an > https server for openpgpkeys.domain. So the core problem, as with Stefan's case, is the lack of control over the domain's DNS settings. Which the WKD mechanism relies upon to delegate trust to the domain operators. I think that is a legitimate concern regarding the current WKD Internet Draft. At least a clarification and maybe some adjustments to the advised fall-back behavior would be in order. Let's see what Werner has to say about it and if there are yet unclear reasons for the currently specified way. Kind regards André -- Greetings... From: André Colomb ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
Hi Andre, On Tue, 12 Jan 2021 20:13:42 +0100, André Colomb wrote: > It has also been pointed out repeatedly in this thread that Sequoia > apparently does not properly check the TLS certificate, which you have > proven with your example setup. That could be called "modern" or > "insecure". It has nothing to do with the ordering of the two methods. I'd like to clarify what Sequoia is doing (wrong). As per the I-D, sq first tries the advanced method. If that fails for any reason, it falls back to the direct method. You can see the three relevant lines of code here: https://gitlab.com/sequoia-pgp/sequoia/-/blob/c80d2ab0/net/src/wkd.rs#L288 If I remove the "or_else", which falls back to the direct method, then sq shows the following error when fetching ste...@sac001.github.io: $ sq wkd get ste...@sac001.github.io Error: error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) Caused by: 0: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) 1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: So, the hostname mismatch is correctly identified, and it correctly returns an error. Where sq's behavior diverges from gpg's is that sq then tries the direct method, but gpg does not. The latest WKD I-D says: 3.1. Key Discovery There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11 (FWIW, this was added to revision 7, which was published in Nov. 2018.) The I-D says "Only if the required sub-domain does not exist, they SHOULD fall back to the direct method." The text doesn't say: "If there is an error, they SHOULD fallback to the direct method unless the required sub-domain does not exist, in which case they MUST NOT fall back to the direct method." So, strictly speaking, I don't think Sequoia is violating the specification. But, I don't want to be overly pedantic. Even if the spec were to prohibit falling back to the direct method when the subdomain exists, what exactly would this prohibition gain us? We thought about this question, but we couldn't figure out a satisfactory answer. The worst attack we could come up with is: an attacker could force a WKD client to use an illegitimate WKD via the direct method instead of a legitimate WKD via the advanced method by: - Taking over foo.com's https, AND - Preventing a WKD client from correctly using the advanced method. But the attacker is NOT able to: - Take over openpgpkey.foo.com's https, OR - Prevent the WKD client from resolving openpgpkey.foo.com. So sure, that's possible, but it seems like WKD shouldn't foo.com's biggest worry in that case. (If we overlooked possible attacks, I'd be happy to hear about them.) On the other hand, implementing this prohibition means that a DNS server can prevent its clients from using WKD by forcing all openpgpkey subdomains to resolve to 127.1. That's hard to notice, because everything else still appears to work. Practically speaking, we helped an organziation deploy WKD, and they had a similar problem to what Stefan is observing: the admins setup the direct method, but it didn't work, because their DNS automatically resolved all unknown subdomains to serve a 404. Unfortunately, they had outsourced management of their DNS and couldn't (or didn't know how) to disable this behavior. IIRC, in the end, they spun up an https server for openpgpkeys.domain. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
On 12/01/2021 23:30, Stefan Claas wrote: > The reason why I like also the option for, let's say github.io pages > is that, like I have shown in the whole thread that a very well known > site like GitHub, with it's millions of software developes allows one > to host, via WKD, a mutli-purpose usage public-key without revealing > to much details. I still don't understand why you insist on WKD when it seems to do not support your use case, nor to offer any advantage over a simpler wget -O- https://sac001.github.io/foobar.asc | gpg --import given that the relation between the identifiers "ste...@sac001.github.io" or "https://sac001.github.io/foobar.asc"; and the key you are retrieving is the same, ie none. Cheers, Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
On 12/01/2021 22:17, Stefan Claas wrote: > On Tue, Jan 12, 2021 at 10:09 PM Daniele Nicolodi wrote: >> >> On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote: >>> On Tue, Jan 12, 2021 at 8:17 PM André Colomb wrote: Hi Stefan, >>> So there are two "bugs" involved here. 1. GitHub presenting an invalid certificate for the sub-subdomain and 2. Sequoia not noticing that. Neither of these are bugs in GnuPG. If you can accept these facts, then it makes sense to further discuss what could be changed where to make your desired setup work. Maybe that discussion will lead to a concise change proposal. >>> >>> Hi Andre, currently I can only accept the fact that these two "bugs" are >>> currently not resolved in GnuPG and gpg4win, if you allow me to >>> formulate it this way. >> >> How can GPG solve bugs that are not in the GPG code or infrastructure? I >> think André did a great job explaining what the issues are. How do you >> think they can be addressed by GPG? > > If you followed the whole thread you may agree that GnuPG and gpg4win, > due to the way of how WKD is implemented does not allow wildcard (sub)domains, > when fetching a pub key from, for example, github.io pages, because it gives > a cert error for a *valid* SSL cert, while other OpenPGP software, > like sequoia-pgp, > can handle this. It has been explained (several times now) that this is not the cases: the certificates are invalid for sub-subdomains. Why are you insisting that they are? Cheers, Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users