Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On 21 May 2018 14:59, Ryan Sleevi wrote:Given the TTLs and the key sizes in use on DNSSEC records, why do you believe this?This is a smoking gun because it's extremely strong circumstantial evidence. Why else would these records exist except that in fact the "victim" published these DNS records at the time of (or shortly before) issuance?As with a real smoking gun there certainly could be other explanations, but the most obvious (that these were the genuine query answers) will usually be correct.If the reality is that fake records were supplied by a MitM using cracked 512 bit keys in order to fool the CA, the name owner victim is humiliated perhaps but they can take action to secure their names with a better key in future. And the Ecosystem gets a free warning as to the safety (rather otherwise) of short keys.If we suppose the CA systematically produced these fake records afterwards to justify a mis-issuance I'd say that's quite a credibility jump from the level of shenanigans we've gotten used to from CAs and it depends upon their victim having a short key for it to even be possible.These both sound like reasons to increase RSA keylengths for any names that are important for you, not justifications for inadequate logging.___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
InfoCert Acquisition of Camerfirma
On Thursday, a representative of AC Camerfirma sent an email informing Mozilla that InfoCert [1] has taken control of Camerfirma. News of the deal was first published on May 4th. [2] Section 8.1 of our policy applies here (quoting version 2.6 draft): If the receiving or acquiring company is new to the Mozilla root program, > it must demonstrate compliance with the entirety of this policy and there > MUST be a public discussion regarding their admittance to the root program, > which Mozilla must resolve with a positive conclusion in order for the > affected certificate(s) to remain in the root program. If the entire CA > operation is not included in the scope of the transaction, issuance is not > permitted until the discussion has been resolved with a positive conclusion. > InfoCert is new to the Mozilla root program, so a public discussion regarding their admittance to the root program is in order. I have requested clarification, but my current understanding is that AC Camerfirma's entire CA operation is part of the transaction. Thus, according to our new policy, certificate issuance may continue during our discussion period. Camerfirma has informed me that they will not be able to answer our questions until the transaction "has been done in the Spanish government's public registry", which they expect to take approximately 4 weeks. Meanwhile, I have created a bug [3] to track this request and have posed a number of questions to InfoCert. - Wayne [1] https://infocert.digital/about-us/ [2] https://www.corrierecomunicazioni.it/digital-economy/infocert-sbarca-allestero-acquisito-il-51-della-spagnola-camerfirma/ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1463597 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Fwd: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
Copying message accidentally sent directly to a list participant. -- Forwarded message -- From: Matthew Hardeman Date: Tue, May 22, 2018 at 3:47 PM Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident To: Ryan Sleevi Ultimately it seems reasonable to, as Mr. Lamb suggested, log the DNS result set such that it is possible to reproduce the point-in-time signed confirmation of the CAA record (or signed non-existence) to within the constraints of the DNSSEC mechanisms available and provisioned for the zone, following the delegations down from the root zone. Are there badly chosen keys and TTLs out there today in practice? Yes, but they're a decreasing proportion of zones. Some TLDs are aggressively deploying DNSSEC and encouraging proper implementation. There's an opportunity here to provide for a best effort cryptographic proof to within the boundaries of what the domain holder has configured. Why not match the domain holder's effort with proportionate supporting documentation? On Tue, May 22, 2018 at 11:43 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek < > tim.holleb...@digicert.com> > wrote: > > > What precisely was the antecedent of “this” in your message? Re-reading > > it, I’m not clear which sentence you were referring to. > > > > > > > > The only reasons I can think of for not keeping DNSSEC signed RRs are > > storage and/or performance, and we think those concerns should not be the > > driving force in logging requirements (within reason). > > > > > > > > Are there other good reasons not to keep the DNSSEC signed RRs associated > > with DNSSEC CAA lookups? > > > > I believe you are operating on a flawed understanding of the value of > DNSSEC for forensic purposes, given the statement that "I absolutely would > expect Let's Encrypt to produce DNSSEC signed RRs that match up to their > story. The smoking gun for such scenarios exists, and CAs are, or should > be, under no illusions that it's their job to produce it." > > To me, this demonstrates a flawed, naive understanding of DNSSEC, and in > particular, its value in forensic post-issuance claims, and also a flawed > understanding about how DNS works, in a way that, as proposed, would be > rather severely damaging to good operation and expected use of DNS. While > it's easy to take shots on the basis of this, or to claim that the only > reason not to store is because disk space, it would be better to take a > step back before making those claims. > > DNSSEC works as short-lived signatures, in which the proper operation of > DNSSEC is accounted for through frequent key rotation. DNS works through > relying on factors such as TTLs to serve as effective safeguards against > overloading the DNS system, and its hierarchal distribution allows for > effective scaling of that system. > > A good primer to DNSSEC can be had at > https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , although I'm > sure > many other introductory texts would suffice to highlight the problem. > > Let us start with a naive claim that the CA should be able to produce the > entire provenance chain for the DNSSEC-signed leaf record. This would be > the chain of KSKs, ZSKs, the signed RRSets, as well as the DS records, > disabling caching for all of these (or, presumably, duplicating it such > that the .com KSK and ZSK are recorded for millions of certs). > > However, what does this buy us? Considering that the ZSKs are intentionally > designed to be frequently rotated (24 - 72 hours), thus permitting weaker > key sizes (RSA-512), a provenance chain ultimately merely serves to > establish, in practice, one of a series of 512-bit RSA signatures. Are we > to believe that these 512-bit signatures, on whose keys have explicitly > expired, are somehow a smoking gun? Surely not, that'd be laughably > ludicrous - and yet that is explicitly what you propose in the quoted text. > > So, again I ask, what is it you're trying to achieve? Are you trying to > provide an audit trail? If so, what LE did is fully conformant with that, > and any CA that wishes to disagree should look inward, and see whether > their audit trail records actual phone calls (versus records of such phone > calls), whether their filing systems store the actual records (versus > scanned copies of those records), whether all mail is delivered certified > delivery, and how they recall the results of that certified delivery. > > However, let us not pretend that recording the bytes-on-the-wire DNS > responses, including for DNSSEC, necessarily helps us achieve some goal > about repudiation. Rather, it helps us identify issues such as what LE > highlighted - a need for quick and efficient information scanning to > discover possible impact - which is hugely valuable in its own right, and > is an area where I am certain that a majority of CAs are woefully lagging > in. That LE recorded th
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi wrote: > Overall, I think this would be good to proceed, but there's certain > discrepancies called out under Questions that I think should be resolved > before doing so. I would suggest contacting WISeKey for follow-up on these, > and not proceed until we've got a satisfactory response. With the upcoming > CA/Browser Forum F2F, I think that effectively means a delay of > approximately two weeks, to allow both WISeKey to respond and the community > (and maintainers) to review for sufficiency. I think that, provided a > response is provided, than barring any further feedback raising additional > concerns, proceeding by June 14 would be a reasonable timeframe? Does that > seem like a reasonable set of expectations and timing? > > This sounds reasonable, but I will note that there is no time limit on public discussions - this one will end after WISeKey has responded to these questions and sufficient time has passed for any additional concerns to be raised. > > * As noted, the key generation was performed in May, and this audit is a > period of time audit beginning in September. This does mean that there is a > gap in the audit coverage - from May through September - that's difficult > to reason about. Are there any other supporting documents that would help > assuage these concerns? > > I would have expected this new root to be included on WISeKey's next regular audit statements for the period ending June 2nd 2017, but WISeKey apparently chooses to perform separate audits (or at least procure separate audit statements) for each of it's roots. Given these circumstances, I share Ryan's concerns and would like an explanation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Thanks for the reminder, Wayne. I've reviewed the CPS and Audit Reports and have the following comments. I will note that, due to having already had someone else look at it, I only focused on information validation related to domains and IPs, and did not examine the policies around OV and EV, as those are generally not applicable to trust on the Web. Overall, I think this would be good to proceed, but there's certain discrepancies called out under Questions that I think should be resolved before doing so. I would suggest contacting WISeKey for follow-up on these, and not proceed until we've got a satisfactory response. With the upcoming CA/Browser Forum F2F, I think that effectively means a delay of approximately two weeks, to allow both WISeKey to respond and the community (and maintainers) to review for sufficiency. I think that, provided a response is provided, than barring any further feedback raising additional concerns, proceeding by June 14 would be a reasonable timeframe? Does that seem like a reasonable set of expectations and timing? == Good == * 2.1 notes that they make a public repository of issued certificates available, which is good to see positive affirmation of certificates being public * 3.1.4 and Annex B provide ample detail about the certificate fields and their validated context, which provides a reasonable basis for understanding their certificate profile and validation practices * 3.1.6 "In any event, the OWGTM will not attempt to intermediate nor resolve conflicts regarding ownership of names or trademarks." - It is good to CA recognize its role in not independently trying to determine trademark issues, and instead defer those to proper adjudication. I wish all CAs would recognize this. * 4.9.7 publishes CRLs in 3 days, effectively half the BR-required time (of 7 days), leading to more effective revocation distribution. * 7.2.2 notes a quality profile for CRLs * Note: It could be improved to document the maximum size (worst case) of CRLs or how sharding is done (across issuerDistributionPoint extensions), to ensure that the worst case CRL size (if all certs pointing to that CRL were revoked) is kept within a reasonable size limit, such as 64K. That's an opportunity for improvement, but admittedly requires more careful engineering design to implement. * 9.4.2 notes that "private information" does NOT include information contained within a certificate or CRL, which is the correct interpretation * 9.6.1 explicitly notes MITM is prohibited. While implicit, it's also encouraging to see this explicitly called out. * Annex E notes that they support IODEF, and the supported methods (this is a SHOULD, not a MUST, in the BRs) == Meh == * 1.4.1.2, which details the validation process for server certificates, explicitly calls out domain verification for DV, but not for OV/EV. * It's unclear if this implies the use of the (deprecated) 3.2.2.4.1 / 3.2.2.4.5 as demonstrations of domain "ownership" independent of domain "control" * Annex E makes it clear that .1 and .5 are in scope as validation methods, which should be phased out by August. * 1.5.4 requires a full meeting of the CAA to convene for updates, which may make it difficult to have the CPS (and the attendant CA policies) reflect the BRs * 3.2.6 notes an accreditation process for interoperating, but doesn't note whether that includes audits consistent with section 8 of the BRs * 4.3 states "The OWGTM is not responsible for monitoring, research or confirmation of the correctness of the information contained in a certificate during the intermediate period between its issuance and renewal, ", which in one read, is entirely consistent with 9.6.1 of the BRs (consistent in that it's at time of issuance), but in another read, could be seen as conflicting with 4.9.1.1 of the BRs * Section 4.9.1 lists 13 items, but there are 15 in the corresponding BRs. Item #4 from the BRs is combined with Item #3 in the CPS, and Item #7 is missing from the BRs as an explicit callout. #14 and #15 in the BRs are seemingly not present, as the place where they would be expected - #12 and #13 - from the CPS are different. * Section 5.2.2 / 5.2.4 don't detail the minimum number of people required for certain activities. * Section 6.2.4 states that CA backup keys are "typically" store encrypted. What protections are in place if they're not encrypted? * Section 7.3.2 misunderstands OCSP extensions as being about the certificates, rather than extensions within OCSP responses (such as CT extensions, should that be supported, or nonces, if that should unfortunately be supported [and it shouldn't]) * Annex B, 11.3.1, lists SAN in the base certificate profile, rather than as an X.509v3 extension, and doesn't explicitly list the CN as being one of the SAN values == Bad == * Annex B, 11.3.1, does not list the extendedKeyUsage in the profile for SSL certificates which is mandatory per the BRs 7.1.2.3. * Other profiles under Annex B do list it (under the misnamed "E
Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On Tuesday, May 22, 2018 at 1:32:51 PM UTC-4, vduk...@gmail.com wrote: > On Tuesday, May 22, 2018 at 1:04:31 PM UTC-4, Paul Wouters wrote: > > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > > > > However, what does this buy us? Considering that the ZSKs are > > > intentionally > > > designed to be frequently rotated (24 - 72 hours), thus permitting weaker > > > key sizes (RSA-512), > > > > I don't know anyone who believes or uses these timings or key sizes. It > > might be done as an _attack_ but it would be a very questionable > > deployment. > > > > I know of 12400 512 bit RSA ZSK's in a total of about 6.5 million. And I > > consider those to be an operational mistake. > > These are "legacy" zones where ~3 operators are having some trouble getting > better keys in place, but the swamp is slowly getting drained, a few months > back the total was ~12900, out of a smaller overall total. ZSKs are > predominantly 1024-bit, with a noticeably large minority using 1280 bits. > Latest stats: > > https://lists.dns-oarc.net/pipermail/dns-operations/2018-May/017628.html As for ZSK lifetime, among still extant domains the average (last seen - first seen) time of no longer published ZSKs is 59 days. This is strongly indicative of a 60-day cycle at the larger DNSSEC-hosting providers. The sample size is "5187051" retired ZSKs. The standard deviation is 34 days. So we can estimate that most ZSKs are rotated in 30-90 days. The sample size is ~5.2 million domains. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On Tuesday, May 22, 2018 at 1:04:31 PM UTC-4, Paul Wouters wrote: > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > > However, what does this buy us? Considering that the ZSKs are intentionally > > designed to be frequently rotated (24 - 72 hours), thus permitting weaker > > key sizes (RSA-512), > > I don't know anyone who believes or uses these timings or key sizes. It > might be done as an _attack_ but it would be a very questionable > deployment. > > I know of 12400 512 bit RSA ZSK's in a total of about 6.5 million. And I > consider those to be an operational mistake. These are "legacy" zones where ~3 operators are having some trouble getting better keys in place, but the swamp is slowly getting drained, a few months back the total was ~12900, out of a smaller overall total. ZSKs are predominantly 1024-bit, with a noticeably large minority using 1280 bits. Latest stats: https://lists.dns-oarc.net/pipermail/dns-operations/2018-May/017628.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On Tue, May 22, 2018 at 1:03 PM, Paul Wouters wrote: > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > However, what does this buy us? Considering that the ZSKs are intentionally >> designed to be frequently rotated (24 - 72 hours), thus permitting weaker >> key sizes (RSA-512), >> > > I don't know anyone who believes or uses these timings or key sizes. It > might be done as an _attack_ but it would be a very questionable > deployment. > > I know of 12400 512 bit RSA ZSK's in a total of about 6.5 million. And I > consider those to be an operational mistake. http://tma.ifip.org/wordpress/wp-content/uploads/2017/06/tma2017_paper58.pdf has some fairly damning empirical data about the reliability of those records, which is not in line with your anecdata. > > > However, let us not pretend that recording the bytes-on-the-wire DNS >> responses, including for DNSSEC, necessarily helps us achieve some goal >> about repudiation. Rather, it helps us identify issues such as what LE >> highlighted - a need for quick and efficient information scanning to >> discover possible impact - which is hugely valuable in its own right, and >> is an area where I am certain that a majority of CAs are woefully lagging >> in. That LE recorded this at all, beyond simply "checked DNS", is more of >> a >> credit than a disservice, and a mitigating factor more than malfeasance. >> > > I see no reason why not to log the entire chain to the root. The only > exception being maliciously long chains, which you can easilly cap > and error out on after following about 50 DS records? "Why not" is not a very compelling argument, especially given the complexity involved, and the return to value being low (and itself being inconsistent with other matters) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
I think your position is both misguided and unrealistic, and I think you're using it as an opportunity to pursue a technical issue, when there is both a systemic issue at play (and can be demonstrated through all validation methods) and a fundamental misunderstanding as to the value it would provided. I'm glad you find the technical explanation a wall of text. Bad ideas do take disproportionately more effort to shoot down then they do to propose. That is an unfortunate asymmetric cost, and one the Web PKI has had to bear for quite some time. I'm not opposed to systemic improvements. I am opposed to unnecessary grand-standing and hand-wringing, when demonstrably worse things are practiced. On Tue, May 22, 2018 at 12:51 PM, Tim Hollebeek wrote: > What that wall of text completely misses is the point I and others have > been trying to make. > > > > The logs have to have enough information so you don’t end up in the > situation Let’s Encrypt is currently, and unfortunately, in. Yes, what > they did is compliant, and that’s exactly what most concerns me. It’s not > about Let’s Encrypt, which just appears to have made a mistake, it > happens. It’s about whether the rules need to be improved to reduce the > likelihood of another CA ending up in the same situation. > > > > As a separate issue, we’re looking into making sure we never end up in > that situation, and as you say, other CAs should be too. We always reserve > the right to do things that vastly exceed minimal compliance. > > > > That should be something you should support, instead of producing > increasingly long and condescending walls of text. I know how DNSSEC works. > > > > -Tim > > > > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Tuesday, May 22, 2018 12:43 PM > *To:* Tim Hollebeek > *Cc:* r...@sleevi.com; Nick Lamb ; > mozilla-dev-security-policy ; > Jacob Hoffman-Andrews > *Subject:* Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity > incident > > > > > > > > On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek < > tim.holleb...@digicert.com> wrote: > > What precisely was the antecedent of “this” in your message? Re-reading > it, I’m not clear which sentence you were referring to. > > > > The only reasons I can think of for not keeping DNSSEC signed RRs are > storage and/or performance, and we think those concerns should not be the > driving force in logging requirements (within reason). > > > > Are there other good reasons not to keep the DNSSEC signed RRs associated > with DNSSEC CAA lookups? > > > > I believe you are operating on a flawed understanding of the value of > DNSSEC for forensic purposes, given the statement that "I absolutely would > expect Let's Encrypt to produce DNSSEC signed RRs that match up to their > story. The smoking gun for such scenarios exists, and CAs are, or should > be, under no illusions that it's their job to produce it." > > > > To me, this demonstrates a flawed, naive understanding of DNSSEC, and in > particular, its value in forensic post-issuance claims, and also a flawed > understanding about how DNS works, in a way that, as proposed, would be > rather severely damaging to good operation and expected use of DNS. While > it's easy to take shots on the basis of this, or to claim that the only > reason not to store is because disk space, it would be better to take a > step back before making those claims. > > > > DNSSEC works as short-lived signatures, in which the proper operation of > DNSSEC is accounted for through frequent key rotation. DNS works through > relying on factors such as TTLs to serve as effective safeguards against > overloading the DNS system, and its hierarchal distribution allows for > effective scaling of that system. > > > > A good primer to DNSSEC can be had at https://www.cloudflare.com/ > dns/dnssec/how-dnssec-works/ , although I'm sure many other introductory > texts would suffice to highlight the problem. > > > > Let us start with a naive claim that the CA should be able to produce the > entire provenance chain for the DNSSEC-signed leaf record. This would be > the chain of KSKs, ZSKs, the signed RRSets, as well as the DS records, > disabling caching for all of these (or, presumably, duplicating it such > that the .com KSK and ZSK are recorded for millions of certs). > > > > However, what does this buy us? Considering that the ZSKs are > intentionally designed to be frequently rotated (24 - 72 hours), thus > permitting weaker key sizes (RSA-512), a provenance chain ultimately merely > serves to establish, in practice, one of a series of 512-bit RSA > signatures. Are we to believe that these 512-bit signatures, on whose keys > have explicitly expired, are somehow a smoking gun? Surely not, that'd be > laughably ludicrous - and yet that is explicitly what you propose in the > quoted text. > > > > So, again I ask, what is it you're trying to achieve? Are you trying to > provide an audit trail? If so, what LE did is fully conformant with that, > and any CA that wi
Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: However, what does this buy us? Considering that the ZSKs are intentionally designed to be frequently rotated (24 - 72 hours), thus permitting weaker key sizes (RSA-512), I don't know anyone who believes or uses these timings or key sizes. It might be done as an _attack_ but it would be a very questionable deployment. I know of 12400 512 bit RSA ZSK's in a total of about 6.5 million. And I consider those to be an operational mistake. However, let us not pretend that recording the bytes-on-the-wire DNS responses, including for DNSSEC, necessarily helps us achieve some goal about repudiation. Rather, it helps us identify issues such as what LE highlighted - a need for quick and efficient information scanning to discover possible impact - which is hugely valuable in its own right, and is an area where I am certain that a majority of CAs are woefully lagging in. That LE recorded this at all, beyond simply "checked DNS", is more of a credit than a disservice, and a mitigating factor more than malfeasance. I see no reason why not to log the entire chain to the root. The only exception being maliciously long chains, which you can easilly cap and error out on after following about 50 DS records? Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
What that wall of text completely misses is the point I and others have been trying to make. The logs have to have enough information so you don’t end up in the situation Let’s Encrypt is currently, and unfortunately, in. Yes, what they did is compliant, and that’s exactly what most concerns me. It’s not about Let’s Encrypt, which just appears to have made a mistake, it happens. It’s about whether the rules need to be improved to reduce the likelihood of another CA ending up in the same situation. As a separate issue, we’re looking into making sure we never end up in that situation, and as you say, other CAs should be too. We always reserve the right to do things that vastly exceed minimal compliance. That should be something you should support, instead of producing increasingly long and condescending walls of text. I know how DNSSEC works. -Tim From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Tuesday, May 22, 2018 12:43 PM To: Tim Hollebeek Cc: r...@sleevi.com; Nick Lamb ; mozilla-dev-security-policy ; Jacob Hoffman-Andrews Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: What precisely was the antecedent of “this” in your message? Re-reading it, I’m not clear which sentence you were referring to. The only reasons I can think of for not keeping DNSSEC signed RRs are storage and/or performance, and we think those concerns should not be the driving force in logging requirements (within reason). Are there other good reasons not to keep the DNSSEC signed RRs associated with DNSSEC CAA lookups? I believe you are operating on a flawed understanding of the value of DNSSEC for forensic purposes, given the statement that "I absolutely would expect Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The smoking gun for such scenarios exists, and CAs are, or should be, under no illusions that it's their job to produce it." To me, this demonstrates a flawed, naive understanding of DNSSEC, and in particular, its value in forensic post-issuance claims, and also a flawed understanding about how DNS works, in a way that, as proposed, would be rather severely damaging to good operation and expected use of DNS. While it's easy to take shots on the basis of this, or to claim that the only reason not to store is because disk space, it would be better to take a step back before making those claims. DNSSEC works as short-lived signatures, in which the proper operation of DNSSEC is accounted for through frequent key rotation. DNS works through relying on factors such as TTLs to serve as effective safeguards against overloading the DNS system, and its hierarchal distribution allows for effective scaling of that system. A good primer to DNSSEC can be had at https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , although I'm sure many other introductory texts would suffice to highlight the problem. Let us start with a naive claim that the CA should be able to produce the entire provenance chain for the DNSSEC-signed leaf record. This would be the chain of KSKs, ZSKs, the signed RRSets, as well as the DS records, disabling caching for all of these (or, presumably, duplicating it such that the .com KSK and ZSK are recorded for millions of certs). However, what does this buy us? Considering that the ZSKs are intentionally designed to be frequently rotated (24 - 72 hours), thus permitting weaker key sizes (RSA-512), a provenance chain ultimately merely serves to establish, in practice, one of a series of 512-bit RSA signatures. Are we to believe that these 512-bit signatures, on whose keys have explicitly expired, are somehow a smoking gun? Surely not, that'd be laughably ludicrous - and yet that is explicitly what you propose in the quoted text. So, again I ask, what is it you're trying to achieve? Are you trying to provide an audit trail? If so, what LE did is fully conformant with that, and any CA that wishes to disagree should look inward, and see whether their audit trail records actual phone calls (versus records of such phone calls), whether their filing systems store the actual records (versus scanned copies of those records), whether all mail is delivered certified delivery, and how they recall the results of that certified delivery. However, let us not pretend that recording the bytes-on-the-wire DNS responses, including for DNSSEC, necessarily helps us achieve some goal about repudiation. Rather, it helps us identify issues such as what LE highlighted - a need for quick and efficient information scanning to discover possible impact - which is hugely valuable in its own right, and is an area where I am certain that a majority of CAs are woefully lagging in. That LE recorded this at all, beyond simply "checked DNS", is more of a credit than a disservice
Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek wrote: > What precisely was the antecedent of “this” in your message? Re-reading > it, I’m not clear which sentence you were referring to. > > > > The only reasons I can think of for not keeping DNSSEC signed RRs are > storage and/or performance, and we think those concerns should not be the > driving force in logging requirements (within reason). > > > > Are there other good reasons not to keep the DNSSEC signed RRs associated > with DNSSEC CAA lookups? > I believe you are operating on a flawed understanding of the value of DNSSEC for forensic purposes, given the statement that "I absolutely would expect Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The smoking gun for such scenarios exists, and CAs are, or should be, under no illusions that it's their job to produce it." To me, this demonstrates a flawed, naive understanding of DNSSEC, and in particular, its value in forensic post-issuance claims, and also a flawed understanding about how DNS works, in a way that, as proposed, would be rather severely damaging to good operation and expected use of DNS. While it's easy to take shots on the basis of this, or to claim that the only reason not to store is because disk space, it would be better to take a step back before making those claims. DNSSEC works as short-lived signatures, in which the proper operation of DNSSEC is accounted for through frequent key rotation. DNS works through relying on factors such as TTLs to serve as effective safeguards against overloading the DNS system, and its hierarchal distribution allows for effective scaling of that system. A good primer to DNSSEC can be had at https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , although I'm sure many other introductory texts would suffice to highlight the problem. Let us start with a naive claim that the CA should be able to produce the entire provenance chain for the DNSSEC-signed leaf record. This would be the chain of KSKs, ZSKs, the signed RRSets, as well as the DS records, disabling caching for all of these (or, presumably, duplicating it such that the .com KSK and ZSK are recorded for millions of certs). However, what does this buy us? Considering that the ZSKs are intentionally designed to be frequently rotated (24 - 72 hours), thus permitting weaker key sizes (RSA-512), a provenance chain ultimately merely serves to establish, in practice, one of a series of 512-bit RSA signatures. Are we to believe that these 512-bit signatures, on whose keys have explicitly expired, are somehow a smoking gun? Surely not, that'd be laughably ludicrous - and yet that is explicitly what you propose in the quoted text. So, again I ask, what is it you're trying to achieve? Are you trying to provide an audit trail? If so, what LE did is fully conformant with that, and any CA that wishes to disagree should look inward, and see whether their audit trail records actual phone calls (versus records of such phone calls), whether their filing systems store the actual records (versus scanned copies of those records), whether all mail is delivered certified delivery, and how they recall the results of that certified delivery. However, let us not pretend that recording the bytes-on-the-wire DNS responses, including for DNSSEC, necessarily helps us achieve some goal about repudiation. Rather, it helps us identify issues such as what LE highlighted - a need for quick and efficient information scanning to discover possible impact - which is hugely valuable in its own right, and is an area where I am certain that a majority of CAs are woefully lagging in. That LE recorded this at all, beyond simply "checked DNS", is more of a credit than a disservice, and a mitigating factor more than malfeasance. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
What precisely was the antecedent of “this” in your message? Re-reading it, I’m not clear which sentence you were referring to. The only reasons I can think of for not keeping DNSSEC signed RRs are storage and/or performance, and we think those concerns should not be the driving force in logging requirements (within reason). Are there other good reasons not to keep the DNSSEC signed RRs associated with DNSSEC CAA lookups? -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: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On Tue, May 22, 2018 at 11:17 AM, Tim Hollebeek wrote: > > > Given the TTLs and the key sizes in use on DNSSEC records, why do you > believe > > this? > > DigiCert is not sympathetic to disk space as a reason to not keep > sufficient > information > in order to detect misissuance due to CAA failures. > > In fact, inspired by this issue, we are taking a look internally at what we > log, and > considering the feasibility of logging even more information, including > full > DNSSEC > signed RRs. > Hi Tim, I'm not sure why you mentioned disk space - could you help me understand why you brought that up? It doesn't actually seem to respond to the question - which is the TTLs and key sizes of DNSSEC records affect both the verifiability of such information and its ability to be used for non-repudiation (which is ostensibly the goal of such record keeping) I think your response presently rather severely misunderstands DNSSEC or what the implications of what you propose mean, but I look forward to DigiCert actually sharing what it proposes to do, so that the community can discuss whether it reasonably achieves those goals with a proposed implementation. Otherwise, we are arguably no different from where we are today, in which CAs do what they believe is reasonable for one purpose, but perhaps fail to achieve that in light of potential risks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
> Given the TTLs and the key sizes in use on DNSSEC records, why do you believe > this? DigiCert is not sympathetic to disk space as a reason to not keep sufficient information in order to detect misissuance due to CAA failures. In fact, inspired by this issue, we are taking a look internally at what we log, and considering the feasibility of logging even more information, including full DNSSEC signed RRs. -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