search

mozilla / pkipolicy

Documents for Mozilla's PKI policies - certificate root program, etc.
48 stars 21 forks source link

Require CAA Checking for Email Certificates #135

Open wthayer opened 6 years ago

wthayer commented 6 years ago

Since the BRs only apply to TLS certificates, most CAs are not enforcing CAA validation on S/MIME certificates. Consider adding this requirement to Mozilla policy.

R-Adrian commented 6 years ago

This will require careful planning by domain administrators, it is nice to have but will cause head-scratches for some, especially those that use the same domain name for both free email for anyone on the internet and for their main site. For corporate use though, it is absolutely needed - it allows administrators to require use of a particular set of CAs for issuance for corporate emails.

I checked some random domains (usually used for free email) for this:

  1. works fine, no CAA policy published in DNS (users are not restricted when choosing their email certificate provider): (in the random testing order that i used)

    • gmail.com
    • outlook.com, live.com, msn.com
    • mail.com
    • aol.com
    • zoho.com
    • protonmail.com
    • gmx.com
    • yahoo.ro

  2. breaks:

    • yahoo.com, yahoo.it, yahoo.fr, yahoo.co.uk - as it is now, their CAA only allows DigiCert to issue certificates, so anyone with an '@yahoo.com / it / fr / insert other yahoo tld here ' email address will only be able to obtain email certificates from DigiCert. Oddly, yahoo.ro does not have CAA published in DNS at the moment, so that one would actually work without problem. 
      # dig +short yahoo.com CAA
0 iodef "mailto:security@yahoo.com"
0 issue "symantec.com"
0 issue "digicert.com"
#
ghost commented 6 years ago

Should there be a new S/MIME-specific version of issue? I could see Google using CAA to limit gmail.com as they’ve done for some of their other domains..

With a S/MIME-specific issue one could restrict ‘TLS’ certificates to their chosen CA(s) whilst allowing their users to get S/MIME certificates freely (or, should they wish, restrict S/MIME as well).

R-Adrian commented 6 years ago

such a change would require a modification of https://tools.ietf.org/html/rfc6844

either as a new errata supplement or a new RFC, but since it's an important protocol change that introduces new syntax keywords, that will probably require the assignment of a new RFC number.

Section 3 and 5 of RFC 6844 define the current properties, section 5 ends with sub-section 5.4 for iodef.

There is room there for new sub-sections, let's call them something like "5.5 CAA issue-clients property" respectively "5.6 CAA issuewild-clients property" to cover issuance for non-server domain clients, either individual clients or groups of clients.

BUT, those new property keywords need to be discussed at IETF, using the regular process for standards, not by a policy change at Mozilla. Here they can only require the full enforcement of the existing protocol standards as defined by IETF.

floatingatoll commented 6 years ago

Do the S/MIME RFCs clearly indicate that plaintext signed or encrypted with an untrusted (self-signed) certificate MUST NOT be shown to the user? If they do not, then an issuer whose root-signed certificates would be constrained by CAA records could simply switch to self-signed certificates to avoid the burden of compliance — correctly realizing that users will add, trust, bypass any permissive UX and warning dialogs necessary to read the email.

On Sat, May 12, 2018 at 7:23 AM Adi notifications@github.com wrote:

such a change would require a modification of https://tools.ietf.org/html/rfc6844

either as a new errata supplement or a new RFC, but since it's an important protocol change that introduces new syntax keywords, this will probably require the assignment of a new RFC number.

section 5 of RFC 6844 defines the current properties and ends with sub-section 5.4 for iodef.

There is room there for new sub-sections, let's call them something like "5.5 CAA issue-clients property" respectively "5.6 CAA issuewild-clients property" to cover issuance for non-server domain clients, either individual clients or groups of clients.

BUT, those new property keywords need to be discussed at IETF, using the regular process for standards, not by a policy change at Mozilla. Here they can only require the full enforcement of the existing protocol standards as defined by IETF.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mozilla/pkipolicy/issues/135#issuecomment-388558622, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFqDAZXMfEg_xEaVNxg33tgh8TfXdUpks5txvBugaJpZM4T8NQ4 .

sleevi commented 6 years ago

Hey all, this should really be discussed on m.d.s.p. rather than here, Thanks!

R-Adrian commented 5 years ago

just a note: I updated my comment above with strikethrough text because sometime in the past year these domains have added CAA records and they now belong in the "breaks" category:

# dig +short gmail.com CAA
0 issue "pki.goog"
# dig +short aol.com CAA
0 issue "digicert.com"
0 issue "globalsign.com"
0 iodef "mailto:security@oath.com"
# dig +short mail.com CAA
0 issue "Digicert.com"
0 issue "telesec.de"
# dig +short gmx.com CAA
0 issue "Digicert.com"
0 issue "telesec.de"
RufusJWB commented 5 years ago

Wouldn't this be a good topic for the upcoming S/MIME WG of the CA/B forum?

R-Adrian commented 5 years ago

yes, hopefully it is, if someone can bring it up with them.

also, the m.d.s.p. thread for where it started might be useful reading material: https://groups.google.com/d/topic/mozilla.dev.security.policy/NIc2Nwa9Msg/discussion

sleevi commented 5 years ago

Wouldn't this be a good topic for the upcoming S/MIME WG of the CA/B forum?

Only to delay things. There’s no such WG chartered yet, nor even an acceptable charter. However, long before the Forum, browsers had policies and requirements, so it doesn’t seem unreasonable to define such here, now.

RufusJWB commented 5 years ago

On the meta-level:

Wouldn't this be a good topic for the upcoming S/MIME WG of the CA/B forum?

Only to delay things.

Which is a rather biased view on the things. My intention is more to keep discussions in the correct forum so that any interested party is able to participate even if they are not monitoring this github project. I think, we all are aware that whatever is decided here, it will be a de-facto-standard and a decision that later in the S/MIME working group can't be changed.

But coming back to the technical level of the discussion: I believe the major thing to be discussed is the question "who 'owns' an email address and can decide on the CA that might issue certificates". Let me give you an example what I mean. I do use the email address rufus.buschart@gmail.com and I feel, that I'm the 'owner' of this email address - regardless what might be stated in the Terms-and-Conditions. And I definitely don't want the technical owner of the DNS record for gmail.com to decide which CA I can use to purchase a certificate from for this email address. Maybe I even want to be able to define a CAA record that prohibits pki.goog to issue one, if I don't trust in your organization (of course I trust you, but well, there are people with tin foil hats). On the other hand side I'm using the email address rufus.buschart@siemens.com at work. Here I fully understand, that for legal reasons Siemens has every right and even the duty to forbid and prevent its employees to purchase certificates from anyone else than pki.siemens.com. This is the stress field we have to deal with. Maybe CAA records are not even the tool to solve the problems.

sleevi commented 5 years ago

On Thu, May 2, 2019 at 7:34 AM Rufus Buschart notifications@github.com wrote:

On the meta-level:

Wouldn't this be a good topic for the upcoming S/MIME WG of the CA/B forum?

Only to delay things.

Which is a rather biased view on the things. My intention is more to keep discussions in the correct forum so that any interested party is able to participate even if they are not monitoring this github project.

This is precisely why I said earlier that this GitHub project is not an appropriate place, and the discussion should be on m.d.s.p. if there is a discussion to be had.

We do not need to defer discussing until a hypothetical WG, but I’m in clear agreement that this is not the place for that discussion. This is why I won’t be responding to your hypothetical scenarios, other than to highlight that the domain holder - the entity of control of DNS - is always right and authoritative.

R-Adrian commented 3 years ago

2020 quick status update: i have now also marked with strikethrough text on my sample list up there: outlook.com, live.com, msn.com, protonmail.com, yahoo.ro since they now have CAA records.

weirdly, now yahoo.ro has a CAA issue ";" record and no mention ever of a public server certificate previously logged in crt.sh with the result that all web browser connections to https on that website will end up in a SSL_ERROR_BAD_CERT_DOMAIN message.

pfuentes69 commented 3 years ago

Another update is to remind that now there's a S/MIME WG where this should be discussed...

BenWilson-Mozilla commented 3 years ago

I've referenced this issue/discussion on the listserv for the CABF's SMIME WG. https://archive.cabforum.org/pipermail/smcwg-public/2020-December/000073.html