RE: A vision of an entirely different WebPKI of the future...
The only thing I'm going to say in this thread is that ICANN, registrars, and registries had two years to figure out how to handle GDPR and email addresses in WHOIS, and we all know how that turned out. Maybe we should let them figure out how to handle their existing responsibilities before we start giving them new ones. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
Matthew Hardeman via dev-security-policy writes: >That's very interesting. I would be curious to know the timing of this. Was >this before or after massive deployment of DNSSEC by the registries? Some time before. To the best of my knowledge DNSSEC considerations had nothing to do with this either way, it just seemed a commonsense way to get sites issued with certs without doing the same validation and whatnot twice over. Having the registry you buy your domain name from also be the one that issues the cert saying you own the domain name seems like a complete no- brainer. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
On Friday, August 17, 2018 at 2:01:55 AM UTC-5, Peter Gutmann wrote: > That was actually debated by one country, that whenever anyone bought a domain > they'd automatically get a certificate for it included. Makes perfect sense, > owning the domain is a pretty good proof of ownership of the domain for > certificate purposes. It eventually sank under the cost and complexity of > registrars being allowed to operate CAs that were trusted by browsers [0]. That's very interesting. I would be curious to know the timing of this. Was this before or after massive deployment of DNSSEC by the registries? Also, I wish to clarify one tiny point again: I submit that only the Registries would be operating CAs and performing signature operations. Registrars would merely interface with the registries. This is an important and noteworthy distinction as there are far fewer Registries than Registrars (and additionally the burdens and complexities of operating as a Registry are significantly greater than the challenges of running a Registrar). As to the questions of the complexity of gaining trust by the browsers, I assume this question arose because the discussion centered around trying to fit such a scheme to the current WebPKI and its assumptions. I'm inclined to believe that if the browsers and the Registries and/or ICANN on their behalf wanted to create a secure and trustable mechanism that it could happen. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
On Thursday, August 16, 2018 at 6:18:47 PM UTC-5, Jakob Bohm wrote: > The main cause of this seems to be that CT has allowed much more > vigorous prosecution of even the smallest mistake. Your argument > is a sensationalist attack on an thoroughly honest industry. I certainly didn't mean it as an attack. I do agree that CT has allowed for greater scrutiny and in turn we find more issues. Some of those issues are insignificant, some are of concern. I did not mean to in any way imply that there is currently a controversy involving malfeasance at a CA. In fact, my proposal stemmed in equal part from the concern that today's domain validation methods are susceptible to problems in network service layers which are known to be insecure and where vulnerabilities have been demonstrated. > That is a viewpoint promoted almost exclusively by a company that has > way too much power and is the subject of some serious public > prosecution. Cow-towing to that mastodont is not buy-in or agreement, > merely fear. In this particular aspect, I suspect you and I substantially agree. I don't hold any strong opinion against that particular company, but they certainly can bring much weight to any argument they make. I do see both sides of the argument. I'm on the record in several other threads in this group advocating for the value of strong identity in WebPKI certificates and advocating for continued inclusion of this information. My overall position on that has not changed and to reiterate clearly, one again, I'm definitely on the other side of that argument versus that certain large company. Having said that, IF and only IF consensus arrived in the other direction -- that the only meaningful subject identifiers in WebPKI certificates are the covered domain labels -- then I would assert that it makes sense to pursue a WebPKI in which the existing authority hierarchy be directly responsible for certificates within that hierarchy and in a manner constrained directly to the limits of each Registry's authority over the DNS. This, I believe, would be preferable to a multi-party system in which the best practices, at best, determine issuing authority on the basis of insecure proxies and consequences of the authoritative data. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
Matthew Hardeman via dev-security-policy writes: >What if the various user agents' root programs all lobbied ICANN to impose a >new technical requirement upon TLD REGISTRY operators? That was actually debated by one country, that whenever anyone bought a domain they'd automatically get a certificate for it included. Makes perfect sense, owning the domain is a pretty good proof of ownership of the domain for certificate purposes. It eventually sank under the cost and complexity of registrars being allowed to operate CAs that were trusted by browsers [0]. Peter. [0] Some details simplified, and identities protected. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
On 16/08/2018 21:51, Matthew Hardeman wrote: Of late, there seems to be an ever increasing number of misissuances of various forms arising. Despite certificate transparency, increased use of linters, etc, it's virtually impossible to find any CA issuing in volume that hasn't committed some issuance sin. The main cause of this seems to be that CT has allowed much more vigorous prosecution of even the smallest mistake. Your argument is a sensationalist attack on an thoroughly honest industry. Simultaneously, there seems to be an increasing level of buy-in that the only useful identifying element(s) in a WebPKI certificate today are the domain labels covered by the certificate and that these certificates should be issued only upon demonstrated control of the included domain labels. That is a viewpoint promoted almost exclusively by a company that has way too much power and is the subject of some serious public prosecution. Cow-towing to that mastodont is not buy-in or agreement, merely fear. The rest of your proposal follows from your bad premises and must be rejected. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
On Thursday, August 16, 2018 at 3:34:01 PM UTC-5, Paul Wouters wrote: > Why would people not in the business of being a CA do a better job than > those currently in the CA business? I certainly do not assert that there would be no learning curve. However, these same registries for the generic TLDs are already implementing cryptographic signatures and delegations at scale for DNSSEC, including signatures over the delegation records to authoritative DNS as well as cryptographic assurances that DNSSEC is not enabled for a given domain, many of the operational concerns of a CA are already being undertaken today as part of the job routinely performed by the registries. > If you want a radical change that makes it simpler, start doing TLSA in > DNSSEC and skip the middle man that issues certs based on DNS records. The trouble that I see with that scheme is the typical location of DNSSEC validation. DNSSEC + a third party CA witnessing point-in-time correctness of the validation challenge as DNSSEC signed allows for DNSSEC to provide some improvement to issuance-time DNS validation. However, as soon as you take a third party CA out of the picture, you no longer have a "witness" with controlled environment (independent network vantage point, proper ensuring of DNSSEC signature validity, etc). Desktop clients today don't generally perform DNSSEC validation themselves, relying upon the resolver that they reference to perform that task. This opens a door for a man in the middle between the desktop and the recursive resolver. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
On Thursday, August 16, 2018 at 3:18:38 PM UTC-5, Wayne Thayer wrote: > What problem(s) are you trying to solve with this concept? If it's > misissuance as broadly defined, then I'm highly skeptical that Registry > Operators - the number of which is on the same order of magnitude as CAs > [1] - would perform better than existing CAs in this regard. You also need > to consider the fact that ICANN has little authority over ccTLDs. One issue that would be solved in such a scheme as I've proposed is that only a single administrative hierarchy may issue certificates for a given TLD and further that that hierarchy is the same as that which has TLD level responsibility over domains within that TLD. Pedantic as it may be, there's virtually no such thing as a misissuance by a registry, if only because literally whatever they say about a domain at any given moment is "correct" and is the authoritative answer. A scheme such as I've proposed also eliminates all the other layers of failure which may occur that can yield undesirable issuances today: concerns over BGP hijacks of authoritative DNS server IP space are eliminated, concerns over authoritative DNS server compromise of other forms is eliminated, concern over compromise of a target web server is eliminated. In the scheme I propose, the registry is signing only upon orders from the registrar responsible for the given domain within the TLD and the registrar gives such orders only upon authenticated requests that are authenticated at least to the same level of assurance as would be required to alter the authoritative DNS delegations for the domain. (Consequently, that level of access today is certainly sufficient to achieve issuance from any CA that issues automatically upon validation against DNS records.) I concede that ICANN would have no means to impose this upon the CC TLDs, leaving a gap to be figured out. I recognize that this is a maverick idea, nearly completely divorced from the current WebPKI's structure. Having said that, I do think it aligns the capability to issue a certificate to the administrative structures which already determine the very definition of what is meant by a given dnsName. In addition, it reduces many diverse attack surface areas down to a single one (account takeover / infrastructure takeover of registrar/registry) that is already in the overall threat model. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
On Thu, 16 Aug 2018, Matthew Hardeman via dev-security-policy wrote: 1. Run one or more root CAs Why would people not in the business of being a CA do a better job than those currently in the CA business? I recognize it's a radical departure from what is. I'm interested in understanding if anything proposed here is impossible. If what's proposed here CAN happen, AND IF we are confident that valid certificates for a domain label should unambiguously align to domain control, isn't this the ultimate solution? If you want a radical change that makes it simpler, start doing TLSA in DNSSEC and skip the middle man that issues certs based on DNS records. Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
What problem(s) are you trying to solve with this concept? If it's misissuance as broadly defined, then I'm highly skeptical that Registry Operators - the number of which is on the same order of magnitude as CAs [1] - would perform better than existing CAs in this regard. You also need to consider the fact that ICANN has little authority over ccTLDs. - Wayne [1] https://icannwiki.org/Category:Registries On Thu, Aug 16, 2018 at 12:51 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Of late, there seems to be an ever increasing number of misissuances of > various forms arising. > > Despite certificate transparency, increased use of linters, etc, it's > virtually impossible to find any CA issuing in volume that hasn't committed > some issuance sin. > > Simultaneously, there seems to be an increasing level of buy-in that the > only useful identifying element(s) in a WebPKI certificate today are the > domain labels covered by the certificate and that these certificates should > be issued only upon demonstrated control of the included domain labels. > > DNS is already authoritatively hierarchical. > > ICANN has pretty broad authority to impose requirements upon the gTLDs... > > What if the various user agents' root programs all lobbied ICANN to impose > a new technical requirement upon TLD REGISTRY operators? > > Specifically, that all registry operators would: > > 1. Run one or more root CAs (presumably a Root CA per TLD under their > management), to be included in the user agents' root program trust stores, > such that each of these certificates is technically constrained to the > included gTLD(s) contractually managed by that registry operator. > > - and further - > > 2. That all such registries be required to make available to the > registrars an automated interface for request of certificates signed by > said CA (or a registry held and controlled issuing CA descendent of said > root) over domain labels within that TLD on behalf of the customer holding > a domain. (For example, Google Domains has an interface by which it can > request a certificate to be created and signed over a customer provided > public key for requested labels within that registrar's customer's account.) > > - and further - > > 3. The registrars be required to provide appropriate interfaces to their > customers (just as they do for DNSSEC DS records today) to have the > registry issue certificates over those domains they hold. > > If you wanted to spice it up, you could even require that the domain > holder be able to request a signature over a technically constrained > SubCA. Then the domain holders can do whatever they like with their > domains' certificates. > > Perform validation of technical requirements (like no 5 year EE certs) > into the product and enforce at the product level. > > If the WebPKI is truly to be reduced to identifying specific domain labels > in certificates issued only for those demonstrating control over those > labels, why do we really need a marketplace where multiple entities can > provide those certificates? > > The combination of registrar and registry already have complete trust in > these matters because those actors can hijack control of their domains in > an instant and properly ask any CA to issue. That can happen today. > > What this would improve, however, is that there's one and only one place > to get a certificate for your example.com. From the registrar for that > domain, with the signing request authenticated by the registrar as being > for the customer of the registrar who holds that domain and then further > delegated for signature by the registry itself. > > Such a mechanism could even be incrementally rolled out in parallel to the > current scheme. Over time, modern TLS endpoints meant to be accessed to > browsers would migrate to certificates issued descending from these > registry held and managed roots. > > From a practicality perspective, I don't see why this couldn't happen, > should enough lobbying of ICANN be provided. Today, ICANN already imposes > certain technical requirements upon both Registries and Registrars as well > as constraints upon their interactions with each other. As a not entirely > unrelated example -- this one involving cryptography and key management -- > today registries of generic TLDs are required to implement DNSSEC. > > I recognize it's a radical departure from what is. I'm interested in > understanding if anything proposed here is impossible. If what's proposed > here CAN happen, AND IF we are confident that valid certificates for a > domain label should unambiguously align to domain control, isn't this the > ultimate solution? > > Thanks, > > Matt Hardeman > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security
A vision of an entirely different WebPKI of the future...
Of late, there seems to be an ever increasing number of misissuances of various forms arising. Despite certificate transparency, increased use of linters, etc, it's virtually impossible to find any CA issuing in volume that hasn't committed some issuance sin. Simultaneously, there seems to be an increasing level of buy-in that the only useful identifying element(s) in a WebPKI certificate today are the domain labels covered by the certificate and that these certificates should be issued only upon demonstrated control of the included domain labels. DNS is already authoritatively hierarchical. ICANN has pretty broad authority to impose requirements upon the gTLDs... What if the various user agents' root programs all lobbied ICANN to impose a new technical requirement upon TLD REGISTRY operators? Specifically, that all registry operators would: 1. Run one or more root CAs (presumably a Root CA per TLD under their management), to be included in the user agents' root program trust stores, such that each of these certificates is technically constrained to the included gTLD(s) contractually managed by that registry operator. - and further - 2. That all such registries be required to make available to the registrars an automated interface for request of certificates signed by said CA (or a registry held and controlled issuing CA descendent of said root) over domain labels within that TLD on behalf of the customer holding a domain. (For example, Google Domains has an interface by which it can request a certificate to be created and signed over a customer provided public key for requested labels within that registrar's customer's account.) - and further - 3. The registrars be required to provide appropriate interfaces to their customers (just as they do for DNSSEC DS records today) to have the registry issue certificates over those domains they hold. If you wanted to spice it up, you could even require that the domain holder be able to request a signature over a technically constrained SubCA. Then the domain holders can do whatever they like with their domains' certificates. Perform validation of technical requirements (like no 5 year EE certs) into the product and enforce at the product level. If the WebPKI is truly to be reduced to identifying specific domain labels in certificates issued only for those demonstrating control over those labels, why do we really need a marketplace where multiple entities can provide those certificates? The combination of registrar and registry already have complete trust in these matters because those actors can hijack control of their domains in an instant and properly ask any CA to issue. That can happen today. What this would improve, however, is that there's one and only one place to get a certificate for your example.com. From the registrar for that domain, with the signing request authenticated by the registrar as being for the customer of the registrar who holds that domain and then further delegated for signature by the registry itself. Such a mechanism could even be incrementally rolled out in parallel to the current scheme. Over time, modern TLS endpoints meant to be accessed to browsers would migrate to certificates issued descending from these registry held and managed roots. >From a practicality perspective, I don't see why this couldn't happen, should >enough lobbying of ICANN be provided. Today, ICANN already imposes certain >technical requirements upon both Registries and Registrars as well as >constraints upon their interactions with each other. As a not entirely >unrelated example -- this one involving cryptography and key management -- >today registries of generic TLDs are required to implement DNSSEC. I recognize it's a radical departure from what is. I'm interested in understanding if anything proposed here is impossible. If what's proposed here CAN happen, AND IF we are confident that valid certificates for a domain label should unambiguously align to domain control, isn't this the ultimate solution? Thanks, Matt Hardeman ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
