I am thinking the decision process needs to be three valued.
* Success * Unknown * DNSSEC Fail Without DNSSEC, it is not going to be possible to distinguish ordinary network failures from attacks. I don’t see a problem with an incentive to deploy DNSSEC so long as it is not mandatory. From: Jacob Hoffman-Andrews [mailto:j...@letsencrypt.org] Sent: Friday, October 6, 2017 6:06 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: Phillip <phill...@comodo.com>; CA/Browser Forum Public Discussion List <public@cabforum.org>; Ryan Sleevi <sle...@google.com> Subject: Re: [cabfpub] CAA working group description On Thu, Oct 5, 2017 at 12:40 PM, Doug Beattie <doug.beat...@globalsign.com <mailto:doug.beat...@globalsign.com> > wrote: Yes, I agree that it seems IETF has left portions of the spec under defined, for example how to look up and validate CAA records given all of the types of errors that could be encountered. Do we expect the IETF WG to focus more heavily on those, or should this be done in CABForum? I think error handling would be a great topic to bring up at the IETF LAMPS WG. In particular the question of how to distinguish DNSSEC-based SERVFAIL vs other types of SERVFAIL is a very tricky technical one, and would benefit from the expertise present at IETF.
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
