On Wed, May 15, 2019 at 2:10 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > Thanks. I think this is desirable to forbid, as it is insecure, and I > > believe it's already forbidden, because the process of step (4) is > relying > > on GMAIL to act as a Delegated Third Party for the validation of the > e-mail > > address. > > > > There are a host of security issues here in the described flow. As > > demonstrated, Step (6) and (7) entirely absent any validation by the CA > of > > the e-mail address, which should be a dead-ringer for why it's > problematic. > > If you replace "SAAS" with "Attacker", this should be clear and obvious. > > [rmh] It is a diagram that shows a delegated RA; It doesn't, though. It doesn't describe the scope of the delegation, and appears to allow attesting based solely on something like OpenID Connect/OAuth, which isn't itself safe or secure to do so. Now, yes, you're eliding a number of details from this description, but the fact that we can't fit a one paragraph description of what or how the CA is validating the e-mail address, let alone the supposed RA, is a great reason to be concerned. > it is not insecure, it is not allowed under the current policy but my > point is that a delegated RA agreement that limited the RA to use cases > where these federated authentication providers attest that the user > controls an email they manage, given the nature of emails and > authentication, seems desirable to accommodate if we believe client > certificates should be used more. Who said they should be used more? ;) I'm concerned that we're conflating somewhat separate pieces - the localpart and the domain-part - and this is adding to the confusion. I'm concerned as well about the description of SAAS here and the role it plays - because it seems to be used interchangably in the discussion between the provider of the email services (e.g. GMail), a reseller/vendor, and the customer of such services (e.g. a customer of a GSuite instance). All of these make it problematic to understand your concerns, goals, and how to provide positive language to improve this. What I also want to separate is a specific implementation of an approach to validation, which it seems to be your focus, and the generalized principle that the policy is trying to capture. I agree that they're related, in as much as policy might prevent specific implementations, but I don't think we want to propose specific changes to policy to enumerate all the acceptable methods (... yet. Hopefully for an S/MIME WG) To save the rest of the list from Ryan-on-Ryan disagreement, let's try and follow-up offlist to see if we can come up with some clearer documentation about what you want to be allowed (which I think we're in agreement isn't now, at least as described), and then we can look at either how to achieve that under the current policy, or how the proposed policy would impact that. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
