Re: CAA Certificate Problem Report
On Tuesday, September 12, 2017 at 5:36:56 AM UTC-5, Gervase Markham wrote: > > As the drafter of the section :-), my intent was to make it so that if a > site owner were concerned about the possibility that their CAA record or > DNS could be spoofed, they could use DNSSEC to solve the problem. I > agree that there is an implicit assumption in this requirement, that it > is possible to efficiently determine the presence or absence of what we > might call "attempted DNSSEC" for a particular domain. (That's not the > same thing as "correct, valid, properly-signed, whatever DNSSEC.) If > that assumption is not true, we may have to reconsider. The proper mechanism is, of course, proper DNSSEC validation of each step of each of the CAA queries. The only "light" mechanism I can imagine is likely to shave only a little time off of common cases and is more likely to introduce bugs and errors for edge cases than it will help, but here goes: I _think_ the only "light" DNSSEC validation shortcut that might pass muster would be: 1. Chase validation to TLD from root zone. 2. Query for DS record delegation for second-level-domain from the TLD servers, validating proper signature on the DS results or proper signature on the proof-of-non-existence of the DS records for the SLD. 3. If the SLD has DS records at the registry and these DS results are signed by the registry, assume that the SLD and all downline subordinates of the SLD have DNSSEC configured and perform full DNSSEC validation on each CAA query. If the SLD has no DS records in the TLD registry and this has been _proven_ by a validly signed proof-of-nonexistence by the TLD registry servers, then DNSSEC for the SLD and subordinate zones is moot and could be ignored. For the common case, I don't think that will shave off much time. Additionally, in terms of complexity, if you implement the above correctly, you've written the vast majority of the code necessary to finish it out the rest of the way. Ultimately, a decision must be made as to whether or not the CA is responsible to ensure that the CAA records (or in the alternative that the non-existence of the CAA records) are fully DNSSEC validated wherever there is not a cryptographic proof that the zone doesn't support DNSSEC (Exempting for TLDs not supporting DNSSEC). Matt Hardeman ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA Certificate Problem Report
I concur in full with Nick Lamb's comments and positions on this matter. There is no reasonable short cut to actually doing the DNSSEC thing if we want to usefully intertwine those technologies at all. There IS significant benefit in enforcing complete DNSSEC validation for (all) the domain validation DNS queries where DNSSEC has been configured for the relevant zones. This is especially the case for CAA records, which have an explicit security function: controlling, at a minimum, who may issue publicly trusted certificates for a given FQDN. I will note that from the software development perspective, I concede that many of the DNS query APIs don't surface (at least in a friendly way) exactly what the nature of the DNSSEC validation failure is or at what layer of delegation the validation fails. My position is that ultimately, that doesn't really matter: If a CA wanted a quick and easy path to differentiating whether a domain has a DNSSEC problem or a CAA problem, chase the queries from the root down both with DNSSEC validation on and with DNSSEC validation off. If no errors arise (because DNSSEC is not configured, etc) then rely on the CAA records alone. If, however, a DNSSEC validated response comes back but errors exist on DNSSEC enabled queries for the CAA records, presume there's a DNSSEC problem of some sort and let the DNS / site admin work out the specific failure. Alternatively, do further digging for the mode of failure outside of the issuance path, in a separate after-adverse-decisioning debug / diagnostic path. It is undeniable that DNSSEC validated query resolution takes longer than queries without DNSSEC. Regardless, these are not terribly lengthy. If the finding is that they are lengthy, reduce the local max timeout for whatever phases are taking too long. I'm having trouble understanding how even several seconds of (asynchronous) delay can be a factor of great concern for a commercial CA. I would assume that all kinds of checks are going on in parallel with callbacks hitting and the certificate advancing to signing when all the necessary callbacks have updated the test status to good. I'm certain that one absolutely could build such a set of asynchronous work queues which would perform tests in a significantly parallel fashion for a great many pending certificates and then push each pending certificate to the actual signer in the moment that the last callback for a given required test posts GOOD on a particular pending issue. Let them process out-of-order prior to hitting the signer, submitting to the final FIFO signing queue in the instant that the last test which clears the issuance decisions transitions to positive. I'd like to comment that DNSSEC and CAA in combination are, to my mind, the only presently available solution of an unambiguous nature for prevention of fraudulent domain-validation success results in a world where a significantly connected BGP participant might hijack ones IP space. On this basis, I assert that there is real and distinct value in enforcing the sanctity of CAA or sanctity of lack of CAA via DNSSEC validation wherever DNSSEC has been configured. Without managing to hoodwink the TLD registry or associated TLD registrar for a domain, there is no way for a successful IP space hijack to yield manipulated results to DNS queries answered by authoritatives in said hijacked IP space -- if and only if DNSSEC validation is performed. I put forth that the security of the root zone delegation, and delegation from the TLD registrar/registry to the authoritative zone IS or CAN BE far more secure than DNS queries without cryptographic validation in a world where the IP space underpinning an authoritative DNS server can be (fairly) easily hijacked. For what it's worth, I'd also LOVE to see an extension option to CAA records which standardize ways of indicating acceptable domain validation methodologies along with acceptable CAs. For example, it would be nice to be able to say "Allow only Let's Encrypt to issue; Allow issuance only when domain validation mechanism relies exclusively upon DNS". In this environment, even if someone hijacks the IP space of a web server within the domain, they are unable to get a certificate issued because they can't skip the CAA and the DNSSEC is keeping the issuance from occurring because it requires a DNS proof for issuance, rather than allowing the random-verification-content-in-a-well-known-url validation. Just my thoughts on the matter... Thanks, Matt Hardeman ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA Certificate Problem Report
Gerv, rather than start by digging into the specific technical details, let me ask a high level question. Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA record saying to only permit the non-existent Gotham Certificates gotham.example to issue. You say you don't want CAs to need to implement DNSSEC. But you also don't want them issuing for my domain. How did you imagine this circle would be squared? If a CA doesn't implement DNSSEC bad guys can send them a forged answer to any query and they'll believe it. We might say to ourselves "Oh, the CA should take reasonable precautions to prevent that" but er, the reasonable precaution is to implement DNSSEC. The arguments against DNSSEC in ordinary clients end up being about practicality, it would be difficult and costly. Ok. But running a public CA is already difficult and costly. Trustworthiness is not cheap. I've also seen a few complaints about DNSSEC being slow at scale. As I understand it Let's Encrypt used DNSSEC at scale from its inception. Whether they're really "biggest" in some sense is debatable, but they're definitely not a boutique outfit, if they can do it then it's clearly not impossible. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: [EXT] CAs not compliant with CAA CP/CPS requirement
Our Policy Management Authority completed review of this and numerous other
changes on September 8. The GeoTrust and Thawte CPS updated that day. The
Symantec CP and CPS were updated the following day
Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Andrew Ayer via dev-security-policy
> Sent: Friday, September 08, 2017 3:25 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] CAs not compliant with CAA CP/CPS requirement
>
> The BRs state:
>
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy
> and/or Certification Practice Statement (section 4.1 for CAs still conforming
> to RFC 2527) SHALL state the CA's policy or practice on processing CAA
> Records for Fully Qualified Domain Names; that policy shall be consistent
> with these Requirements. It shall clearly specify the set of Issuer Domain
> Names that the CA recognises in CAA 'issue' or 'issuewild' records as
> permitting it to issue. The CA SHALL log all actions taken, if any, consistent
> with its processing practice."
>
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes of
> some CAs.
>
> At time of writing, the latest published CP/CPSes of the following CAs are
> not compliant with the above provision of the BRs:
>
> Amazon
> (https://clicktime.symantec.com/a/1/NmZ9sYttj7vKv6t18I35QRQ0FMHxkP
> NpP8WSJXL-eYo=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.amazontrust.com%
> 2Frepository%2F) - Does not check CAA
>
> Comodo
> (https://clicktime.symantec.com/a/1/7dk4IPNLHeQgWaoO8HJ5ksv2_spTr
> Mwd0vsOAxU735E=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.comodo.com%2Fab
> out%2Fcomodo-agreements.php) - Does not specify issuer domain names
>
> DigiCert
> (https://clicktime.symantec.com/a/1/xlVibpoycRtW78OkiI3usE639u_3QGd
> RehxP5QhPWPs=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.digicert.com%2Flega
> l-repository%2F) - Does not specify issuer domain names, and processing is
> not compliant with BRs ("If a CAA record exists that does not list DigiCert as
> an authorized CA, DigiCert verifies that the applicant has authorized
> issuance, despite the CAA record.")
>
> Google Trust Services
> (https://clicktime.symantec.com/a/1/FDXLCPoMms9u5GaLDCj2Qk1jqwAV
> PQjmvvu2wergGPg=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fpki.goog%2F) - Does not
> check CAA
>
> Identrust (https://clicktime.symantec.com/a/1/-
> hcYCELwi2ejxzoC9hWCgVYMAFr-ZM4ljorelCgIGqk=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t
Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Hi, just wanted to update that Certum has also issued on this domain: https://crt.sh/?id=209378608 I have opened a support ticket, which has led to revocation but not a qualified statement as to what happened yet. Kind regards Quirin 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: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
Dear Nikos, On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky > wrote: > > Hello, > > > > Here is the new version of the draft updated according to the discussion > on > > mozilla-dev-security list. > > Hi, > It seems that most of the details of the underlying format are > missing. As far as I understand it is mostly an intentions document at > this point right? I have few comments: > The format will be CRL-like. > > 1. requiredX509extensions: What's the reasoning behind this? If these > extensions are required and not present why keep the root certificate > in the trust store? > The main intended case is "require Certificate Transparency". Currently using the CT is not mandatory for all CAs. > > 2. What is the difference between issuedNotAfter and trustNotAfter? > The description text is unclear to me. > issuedNotAfter - we do not trust to the certificates issued after the date. trustNotAfter - we do not trust certificates after the date XXX, if they have notAfter > XXX > > 3. applicationNameConstraints: very useful, however it is unclear from > the ASN.1 description how are these stored. > I'm not so familiar with ASN1 format. I think that syntax from RFC5280 will fit here. > > 4. How do you handle extensions to this format? > > Simillary to CRL. Do you have ideas of the extensions? > Overall, why not use X.509 extensions to store such additional > constraints? We already (in the p11-kit trust store in Fedora/RHEL > systems) use the notion of stapled extensions to limit certificates > [0, 1] and seems quite a flexible approach. Have you considered that > path? > > regards, > Nikos > > [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > Thank you very much, I'll look at it. -- SY, Dmitry Belyavsky ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky wrote: > Hello, > > Here is the new version of the draft updated according to the discussion on > mozilla-dev-security list. Hi, It seems that most of the details of the underlying format are missing. As far as I understand it is mostly an intentions document at this point right? I have few comments: 1. requiredX509extensions: What's the reasoning behind this? If these extensions are required and not present why keep the root certificate in the trust store? 2. What is the difference between issuedNotAfter and trustNotAfter? The description text is unclear to me. 3. applicationNameConstraints: very useful, however it is unclear from the ASN.1 description how are these stored. 4. How do you handle extensions to this format? Overall, why not use X.509 extensions to store such additional constraints? We already (in the p11-kit trust store in Fedora/RHEL systems) use the notion of stapled extensions to limit certificates [0, 1] and seems quite a flexible approach. Have you considered that path? regards, Nikos [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Thanks Quirin, we´re working with Primekey to know what happened (we´ll generate a report once known) and will contact you if necessary to check that info you have. Regarding the logs, the log message actually means that CAA either explicitly permitted the issuance, or implicitly permitted issuance (e.g. by the lack of a CAA record, that according to this email that´s no the case). We´re also checking if the DNS resolver server was caching the timeout failure and sent a SERVFAIL or similar response the second time, rather than letting the query time out again. But, as said, we´re still investigating the issue. Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Quirin Scheitle via dev-security-policy Sent: martes, 12 de septiembre de 2017 20:30 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone Hi all, Thank you for the replies. I am glad that there is agreement these certificates should not have been issued. I am confident that the test behaved correctly, the last edit on the zone file was on Aug 31 17:24, and it reads: crossbear.org. 0 CAA 0 issue ";" So even if requests would somehow have gotten through the iptables rule dropping them, it would definitely not have gotten a permitting record. I also have full pcaps from both name servers serving this domain and can confirm that not a single query response was sent to any server on September 8th and 9th. crossbear.net is a different domain with a different configuration, it is unrelated to this issue. Inigo, I am very happy to debug this in detail offline -- I have plenty of records and data to assist debugging. Kind regards Quirin ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy 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
