Ok. My biggest concern is not you guys, who are pretty security conscious, but whether we need to improve the language to make it more clear that the logging has to be sufficient so that in the event of a bug in the CAA logic, it is possible to determine which issued certificates are affected and how.
It may be hard to come up with such language, but that was the intent of the language that was currently there, and if it failed to adequately express that and needs improvement, we should consider improvements. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of > jacob.hoffmanandrews--- via dev-security-policy > Sent: Friday, May 18, 2018 2:05 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident > > On Friday, May 18, 2018 at 10:52:25 AM UTC-7, Tim Hollebeek wrote: > > > Our logging of the CAA records processed does not provide the case > > > information we need to determine whether other issuances were > > > affected by this bug. > > > > We put a requirement in the BRs specifically so this problem could not occur: > > > > "The CA SHALL log all actions taken, if any, consistent with its > > processing practice." > > To be clear, we do log every CAA lookup > (https://clicktime.symantec.com/a/1/3HdZcXUFLJSV752s3qQoA0A6fzGR2WGY > aa8Vb4eW0is=?d=2Gn0FYgiBMMDYQjPk2an9e5zCmdH8aOEM_a2k8A8ew7ArD > v0URhjtIEPzgzNAA47eRfCIlwMe3ctM0pXRF0VTUqLXosrX- > i7uR64LKqy873Aqy3Mii7JCWLQHOPpQWcNp3FWnBu624ZZQANcMTNtqbgJea > RmalbiW1vABzoOte0IZNRfmkmQES8Nr67RP515OPIifYcBpDbj7_SzCddoRw_Im > KUgkD70LCvR8NLdXBfk2_bpdPsIPd2MYiWXCpp3qWI_1_XQ9z_eyC1QGzTtcxOF > DLgSe4rRoyLJQqTaoooPKFGFUX_3SIzP6bjz_SEXUqSWbBz7XRVk1YrZczQFl1NM > N2BdjOE5nsDTre28cQDZNQ-1dOqbirW3- > CbCQwcvVjIQBfy3i8vCqAUh4xoVlvk16SNfyCeF3pFZYJ_TtcaaO9Tr8cUp9RHfdwC > 20jfPFtyRHXscZwhVP2Lfucn9JLErK7kbSczQrqe3GrqCICQf27hRDOnBq5_C&u=ht > tps%3A%2F%2Fgithub.com%2Fletsencrypt%2Fboulder%2Fblob%2Fmaster%2Fv > a%2Fcaa.go%23L47). However, we do it at too high a level of abstraction: It > doesn't contain the unprocessed return values from DNS. We plan to improve > that as part of our remediation. > > Our ideal would be to log all DNS traffic associated with each issuance, > including A, AAAA, TXT, and CAA lookups. We initially experimented with this > by capturing the full verbose output from our recursive resolver, but concluded > that it was not usable for investigations because it was not possible to associate > specific query/response pairs with the validation request that caused them (for > instance, consider NS referrals, CNAME indirection, and caching). I think this is > definitely an area of improvement we could pursue in the DNS ecosystem that > would be particularly beneficial for CAs. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/OveGoqfqvlk5eSNt6tWZIf0e1XY5TBocWaY > xmYcWV4s=?d=2Gn0FYgiBMMDYQjPk2an9e5zCmdH8aOEM_a2k8A8ew7ArDv0 > URhjtIEPzgzNAA47eRfCIlwMe3ctM0pXRF0VTUqLXosrX- > i7uR64LKqy873Aqy3Mii7JCWLQHOPpQWcNp3FWnBu624ZZQANcMTNtqbgJea > RmalbiW1vABzoOte0IZNRfmkmQES8Nr67RP515OPIifYcBpDbj7_SzCddoRw_Im > KUgkD70LCvR8NLdXBfk2_bpdPsIPd2MYiWXCpp3qWI_1_XQ9z_eyC1QGzTtcxOF > DLgSe4rRoyLJQqTaoooPKFGFUX_3SIzP6bjz_SEXUqSWbBz7XRVk1YrZczQFl1NM > N2BdjOE5nsDTre28cQDZNQ-1dOqbirW3- > CbCQwcvVjIQBfy3i8vCqAUh4xoVlvk16SNfyCeF3pFZYJ_TtcaaO9Tr8cUp9RHfdwC > 20jfPFtyRHXscZwhVP2Lfucn9JLErK7kbSczQrqe3GrqCICQf27hRDOnBq5_C&u=ht > tps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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
