Following Ben’s suggestion, this draft is being moved to SECDISPATCH for discussion.
Thanks! From: Ryan Sleevi <ryan-i...@sleevi.com> Date: Sunday, October 21, 2018 at 9:01 PM To: Benjamin Kaduk <ka...@mit.edu> Cc: Rich Salz <rs...@akamai.com>, Ryan Sleevi <ryan-i...@sleevi.com>, Tobias Fiebig <t.fie...@tudelft.nl>, "ke...@iseclab.org" <ke...@iseclab.org>, "acme@ietf.org" <acme@ietf.org> Subject: Re: [Acme] ACME DV Security Considerations Draft On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk <ka...@mit.edu<mailto:ka...@mit.edu>> wrote: On Sun, Oct 21, 2018 at 05:25:40PM +0000, Salz, Rich wrote: > * It does not seem to be related to ACME - that is, what you’re > describing is more broadly a set of concerns with the methods that may be > used to validate a domain. > > Perhaps ACME isn’t the right place for this, perhaps it should be reviewed by > SecDispatch, or whatever the DNS equivalent is, or coordinated between the > two area AD’s. Since there are proposed solutions in here, secdispatch would seem like a fine place (and the latest agenda I saw for them had some slots free, still). There might also be a place for a more open-ended discussion of problems with DV in SAAG, if someone were to volunteer to prepare some slides and structure the discussion. Thanks. I agree secdispatch is probably a better place for this. The CA/Browser Forum's Validation WG attempted to perform a similar analysis during it's F2F in Herdon, VA, as captured ever so briefly in https://cabforum.org/2018/03/08/final-minutes-for-ca-browser-forum-f2f-meeting-herndon-va-7-8-march-2018/<https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_2018_03_08_final-2Dminutes-2Dfor-2Dca-2Dbrowser-2Dforum-2Df2f-2Dmeeting-2Dherndon-2Dva-2D7-2D8-2Dmarch-2D2018_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=lSV2-wQf6qsDc7B3upJkBp4mBQIkoHvnsHwGEzVXzhI&s=QOfpyh2h4uto88ihDjPZuQj7aGQLe9zqEVXUjSkYlTk&e=> . This was the first (and only) meeting in which the Forum Chair extended blanket invitations for experts to participate, and while well-attended, is nowhere near the open participation model that the IETF represents. Work on attempting to resolve some of the security concerns is captured in http://cabforum.org/pipermail/validation<https://urldefense.proofpoint.com/v2/url?u=http-3A__cabforum.org_pipermail_validation&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=lSV2-wQf6qsDc7B3upJkBp4mBQIkoHvnsHwGEzVXzhI&s=UEjruCF6pq9gzj5WFV0vgCmoXHnK6tkQIiw_Y3HDU3Q&e=> , although the limited participation (largely of CAs) prevents a lot of the thorough analysis this work represents, and having a broader participation such as through secdispatch is better for the ecosystem as a whole. One minor pedantic quibble, however, is that I think the discussion would be better served by not speaking of it as ACME or DV. The notion of "DV/OV/EV" is an arbitrary marketing distinction with no security value - all certificate types rely on the same procedures for validating an assertion of control (organizational or operational) over a domain name. Indeed, in many cases, forms of certificates such as OV/EV have been demonstrated to be significantly weaker in practice - for example, that the organization name in WHOIS (i.e. "Google, Inc") matches an incorporated institution somewhere named the same - without any further validation about which "Google, Inc" is being referred to, soft-matches such as "Google, LLC", or even relationships such as "There's a Google LLC as a subsidiary of Alphabet, and this company's name is Alphabets, so that's probably OK". By speaking more generally of the challenges of validating a domain, we allow speaking with precision without the distinction of marketing or branding, and addressing the underlying security issues more directly.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
