CAA is HTTPS only today. That’s the reality.
I don’t have to want to argue in favor of reality. Reality wins regardless of what I do. -Tim From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, May 14, 2018 11:55 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: r...@sleevi.com; Pedro Fuentes <pfuente...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: question about DNS CAA and S/MIME certificates I'm not sure how that's advancing the discussion forward or adding new information. The discussion of CAA and wanting to get feedback predates even the IETF finalization, as multiple browsers kept encouraging CAs to experiment with and attempt to deploy CAA so that we could make sure the kinks were ironed out. Regardless of posturing and grandstanding for past statements, can we at least agree that a model that argues "fail open" as a solution is a fundamentally insecure one? If there are proponents of a 'fail open' model, especially amongst CAs, then does it behove them to specify as quickly as possible a 'fail closed' model, so that we don't have to try and divine intent and second guess site operators as to whether they meant to restrict HTTPS or everything? Put differently, if you want to argue that CAA is HTTPS only, then you need to define a way to ensure it's not HTTPS-only, and ASAP. Otherwise, the solution is that when S/MIME BRs come around, we simply cannot and should not second guess site operators and try to argue CAA was only 'those' type of certs - and instead require anyone with a CAA record to explicitly opt-in to allowing (potentially unbounded) S/MIME. I don't see any other realistic or practical solution - you can't say "This protects you" and then propose 2 years down the road, with S/MIME BRs, that it didn't actually 'protect' the site operator - the same way you can't say "Restrict access to these five email addresses" and then introduce a dozen more 2 years down the road. On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Normally I’d agree that IETF cannot and should not be a blocker for action at Mozilla and/or CABF, but based on our experience with CAA for web certificates, I would encourage people to get in their time machines and go back two to three years, and listen to Tim standing up and saying “I like CAA for the Web PKI, but what have we not thought of?” -Tim From: Ryan Sleevi [mailto:r...@sleevi.com <mailto:r...@sleevi.com> ] Sent: Monday, May 14, 2018 8:24 PM To: Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; Pedro Fuentes <pfuente...@gmail.com <mailto:pfuente...@gmail.com> >; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: question about DNS CAA and S/MIME certificates I don't actually think there is any IETF component to this. There can be, but it's not required to be. On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> <mailto:dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > > wrote: There’s an IETF component, but minimum necessary standards for email certificate issuance is a policy issue, not a technical one. Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in accordance with CAA-bis.” -Tim With CABF governance reform coming into effect on July 3rd, I'm cautiously optimistic we can start writing requirements for e-mail certificates and phasing out bad practices and phasing in good practices soon. CAA for e-mail certificates is definitely worth considering as part of that process. Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin looking at the level of authentication provided for domains today? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> <mailto:dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto: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
