question about DNS CAA and S/MIME certificates

[Adrian R.]

Hello,
this question is somewhat outside the current Baseline Requirements, but...

wouldn't it be normal for the same CAA rules for server certificates to also apply to client certificates when the email address is for a domain that already has a valid CAA policy published in DNS?


RFC 6844 doesn't seem to make any distinction between server and S/MIME client certificates, it combines them together by referring to certificates "for that domain" as a whole.


i tested this last night - i obtained an email certificate from one of the CAs participating here (not for this exact address though) and it was happily issued even if CAA records authenticated by DNSSEC do not allow their CA to issue for this domain.

Now, this is technically not a mis-issuance because it was a proper email-validated address and their CPS says that CAA is only checked for server-type certificates. It doesn't say anything about CAA validation for such client certificates.

I got in touch with them and they seemed equally surprised by such intended use case for CAA, so my second question is: is anyone actually checking CAA records for client certificates where an email address is included in the certificate subject info and the EKU includes Secure Email?


Or is CAA usually checked only for server-type certificates, even if RFC 6844 refers to certificates "for that domain" as a whole?


Thank you,
~~~~
Adrian R.

[Ryan Sleevi]

CAs are generally only checking CAA when they're required to in order to be
trusted.

Right now, CAs are only required to check CAA for server-type certificates
(by virtue of the Baseline Requirements Section 3.2.2.8).
CAs are not presently being required to check CAA for e-mail. They can, but
they are required to do it, so they are unlikely to do it.

[Wayne Thayer]

I created a new issue suggesting that we add this requirement to Mozilla
policy: https://github.com/mozilla/pkipolicy/issues/135

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Pedro Fuentes]

Just to say that looking at this from Europe, I don't see this feasible.

Citizens getting their personal eIDAS-compliant certificate go through face-to-face validation and will give virtually any valid e-mail address to appear in their certificate.

[Ryan Sleevi]

It seems perfectly reasonable and desirable to require that CAs, regardless
of the type of certificate they are issuing, respect CAA.

If an email provider wishes to restrict some types of certificates (e.g.
HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
additional expressions within the CAA syntax.

However, it would be a long-lasting, and tragic mistake if CAA was presumed
to 'only' apply to HTTPS - because it would make the same mistake of
nameConstraints - namely, everything that is not expressly listed as
permitted/restricted is implicitly permitted - rather than doing what
security practitioners have long known is the safe and secure base - forbid
unless expressly permitted (default-deny).

In terms of order of concerns and constituents, the domain holders needs
and security goals outweigh those of the notion of users 'owning' an email
address.

On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Just to say that looking at this from Europe, I don't see this feasible.
>
> Citizens getting their personal eIDAS-compliant certificate go through
> face-to-face validation and will give virtually any valid e-mail address to
> appear in their certificate.
>
> El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer escribió:

[Adrian R.]

Pedro Fuentes wrote:
> Just to say that looking at this from Europe, I don't see this feasible.
>
> Citizens getting their personal eIDAS-compliant certificate go through face-to-face validation and will give virtually any valid e-mail address to appear in their certificate.
>

Then that is a problem with eIDAS certificates not with CAA - eIDAS certificates identify the person, and (assuming that email validation is even performed) that they have temporary control of an email address, but if the email is on a corporate domain this does nothing to address the issuance against policies of that company.


>From this point of view, an email address should not even be part of an eIDAS certificate (and thus CAA would not apply), but an email is usually included for convenience. (why?)

This is because the eIDAS regulation 910/2014 does not contain the words "e-mail", "email" or "message" at all. (!!!)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910

As it is now, it is even possible to use and 'verify control' of anonymous disposable email services (e.g. mailinator) for an eIDAS certificate because the CA TSP doesn't care about the email or domain policies.


As is noted on the GitHub issue, many providers of free email services have been careful to avoid deploying CAA for the domain names used by their email users, but some have deployed restrictive CAA policies that might affect their users if CAA checking is done (e.g. Yahoo, Yandex).


~~~~
Adrian R.

[Neil Dunbar]

But it also seems reasonable for organisations making CAA assertions to know the scope of their stipulations before they make them, no?

So, if in the case of Yahoo, they make the assertion “All of our web certificates should come from DigiCert”, are they aware that they are also making the statement “And all of our user mail accounts should only be granted S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would just want all participants in the PKI world to know what their statements mean and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean ‘covering all possible forms of certificates’?

Just a thought,

Neil

> On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> It seems perfectly reasonable and desirable to require that CAs, regardless
> of the type of certificate they are issuing, respect CAA.
>
> If an email provider wishes to restrict some types of certificates (e.g.
> HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
> additional expressions within the CAA syntax.
>
> However, it would be a long-lasting, and tragic mistake if CAA was presumed
> to 'only' apply to HTTPS - because it would make the same mistake of
> nameConstraints - namely, everything that is not expressly listed as
> permitted/restricted is implicitly permitted - rather than doing what
> security practitioners have long known is the safe and secure base - forbid
> unless expressly permitted (default-deny).
>
> In terms of order of concerns and constituents, the domain holders needs
> and security goals outweigh those of the notion of users 'owning' an email
> address.
>
> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <

> dev-secur...@lists.mozilla.org> wrote:
>
>> Just to say that looking at this from Europe, I don't see this feasible.
>>
>> Citizens getting their personal eIDAS-compliant certificate go through
>> face-to-face validation and will give virtually any valid e-mail address to
>> appear in their certificate.
>>

>> El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer escribió:

[Jakob Bohm]

Another approach could be to have something akin to the (non-ICANN)
public suffix list, but for e-mail. This would list e-mail domains
where the e-mail address holders are not the subordinates (employees,
students, etc.) of the domain holder.

Such a list would have multiple uses (just like the public suffix list
for domain delegations):

1. E-mails from these domains are not presumed to represent the opinion
of the domain holder in various contexts (including validation of TLS
certs against non-reserved e-mail addresses).

2. Anti-spam systems could apply a more per-account algorithm for
computing reputation scores.

3. S/MIME certificate issuance does not assume the domain holder can
act on behalf of the e-mail users. Thus validation with
postm...@example.net would not be valid for joes...@example.net,
but on the other hand CAA records for example.net would not apply
to S/MIME (both if example.net was on the public e-mail domain list).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Tim Hollebeek]

Yes, but as you correctly point out, this should be taken care of as part of the CAA-bis
effort. The original RFC had enough errors with respect to web certificates; I think
it would be irresponsible to apply it to e-mail certificates right now without carefully
considering the consequences.

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.

Slightly higher priority is making sure authenticated encryption modes are used with
S/MIME, so people can't play silly games with CBC and harvested ciphertexts.
Everything really needs to start transitioning away from CBC ... but I digress.

-Tim

[Ryan Sleevi]

On Mon, May 14, 2018 at 11:48 AM, Neil Dunbar via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> But it also seems reasonable for organisations making CAA assertions to
> know the scope of their stipulations before they make them, no?
>
> So, if in the case of Yahoo, they make the assertion “All of our web
> certificates should come from DigiCert”, are they aware that they are also
> making the statement “And all of our user mail accounts should only be
> granted S/MIME certificates from DigiCert too”.
>
> Perhaps they are, perhaps not, but I’m willing to bet that a fair number
> of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift
> to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s
> customers.
>

Sure, but Yahoo still remains the authority as to what the localpart of the
mailbox means - and thus absolutely should have that control over issuance,
and should be treated as such.

> Please note: I’m not opposed to CAA stipulations applying to S/MIME. I
> would just want all participants in the PKI world to know what their
> statements mean and how far they reach.
>
> Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be
> restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean
> ‘covering all possible forms of certificates’?
>

And that still moves to an 'insecure-by-default', by making every site
operator that has taken steps to actually restrict issuance not have those
wishes respected. This is the same problem as introducing new forms of
certificate validation methods - if it leaves insecure someone who has
taken steps to secure things, then it's making things worse.

That's why a solution to opt-out, rather than opt-in, is the right approach.

Today this is a "non-issue" because nothing is obligating CAs to respect
CAA, and thus they can (and are) doing the thing that helps them issue more
certificates (and, presumably, make more money) - but that doesn't
necessarily mean its the right thing. Yes, it means that introducing CAA
restrictions for S/MIME necessarily means there will need to be a way to
distinguish these cases, so that an organization could restrict e-mail vs
HTTPS - so CAs that wish to issue S/MIME should start working on these.

[Ryan Sleevi]

The Public Suffix List is a model for failure, not success - and I say that
as one of the two PSL maintainers. As to the remaining points, I think each
and every one of them doesn't actually hold up to scrutiny, and in fact,
the opposite conclusion is more in line with reality.

For example, if anti-spam systems applied per-account algorithms, then
there's an incentive for spammers to add themselves to the list. This is
demonstrable by some CAs using rate limiting at the PSL boundary, causing a
surge in additions to bypass those rate limits - similarly for various
browser security mechanisms.

Regarding the domain holder acting as behalf as the user - it's absolutely
true they can. The position advocated is like suggesting that 3.2.2.4.6 is
more secure than 3.2.2.4.2/.3 - the domain holder has primacy over the
website operator, and the postmaster has primacy over individual mailboxes.

On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Another approach could be to have something akin to the (non-ICANN)
> public suffix list, but for e-mail. This would list e-mail domains
> where the e-mail address holders are not the subordinates (employees,
> students, etc.) of the domain holder.
>
> Such a list would have multiple uses (just like the public suffix list for
> domain delegations):
>
> 1. E-mails from these domains are not presumed to represent the opinion
> of the domain holder in various contexts (including validation of TLS
> certs against non-reserved e-mail addresses).
>
> 2. Anti-spam systems could apply a more per-account algorithm for
> computing reputation scores.
>
> 3. S/MIME certificate issuance does not assume the domain holder can
> act on behalf of the e-mail users. Thus validation with
> postm...@example.net would not be valid for joes...@example.net,
> but on the other hand CAA records for example.net would not apply
> to S/MIME (both if example.net was on the public e-mail domain list).
>
>
> On 14/05/2018 17:48, Neil Dunbar wrote:
>

> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>

[Ryan Sleevi]

On Mon, May 14, 2018 at 1:10 PM, Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Yes, but as you correctly point out, this should be taken care of as part
> of the CAA-bis
> effort. The original RFC had enough errors with respect to web
> certificates; I think
> it would be irresponsible to apply it to e-mail certificates right now
> without carefully
> considering the consequences.
>
> 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?

>
> Slightly higher priority is making sure authenticated encryption modes are
> used with
> S/MIME, so people can't play silly games with CBC and harvested
> ciphertexts.
> Everything really needs to start transitioning away from CBC ... but I
> digress.
>

Indeed, it would be extremely unfortunate if the CABF tried to prioritize
the encryption modes over reliable certificate authentication, considering
that the encryption modes are not related to the certificates themselves.

[Jakob Bohm]

On 14/05/2018 20:55, Ryan Sleevi wrote:
> The Public Suffix List is a model for failure, not success - and I say that
> as one of the two PSL maintainers. As to the remaining points, I think each
> and every one of them doesn't actually hold up to scrutiny, and in fact,
> the opposite conclusion is more in line with reality.
>
> For example, if anti-spam systems applied per-account algorithms, then
> there's an incentive for spammers to add themselves to the list. This is
> demonstrable by some CAs using rate limiting at the PSL boundary, causing a
> surge in additions to bypass those rate limits - similarly for various
> browser security mechanisms.
>

I was not aware that the domain PSL allowed random self-addition without
checks, and thus related abuses. The hypothetical mail PDL would be
based on external observation and confirmation, not self-declaration, as
true PDL entries (3rd party e-mail hosts) are in a partially adversarial
role to their (paying) users.

> Regarding the domain holder acting as behalf as the user - it's absolutely
> true they can. The position advocated is like suggesting that 3.2.2.4.6 is
> more secure than 3.2.2.4.2/.3 - the domain holder has primacy over the
> website operator, and the postmaster has primacy over individual mailboxes.
>

That's arguing the conclusion. The question is what the hierarchy of
supremacy should be for e-mail, given that e-mail is a different
landscape than website hosting. And I am arguing that the correct
answer depends heavily on the nature of the e-mail system involved.

A company postmaster has obvious supremacy over company e-mail accounts.

But a common carrier ISP postmaster should not have supremacy over their
users.

[Tim Hollebeek]

> Today this is a "non-issue" because nothing is obligating CAs to respect
> CAA,
> and thus they can (and are) doing the thing that helps them issue more
> certificates (and, presumably, make more money) - but that doesn't
> necessarily
> mean its the right thing.

I can think of at least one CA that values "# of right things done" more
highly than "# of certificates issued". Actually, I can think of two or
three.
There are probably more.

> Yes, it means that introducing CAA restrictions for
> S/MIME necessarily means there will need to be a way to distinguish these
> cases, so that an organization could restrict e-mail vs HTTPS - so CAs that
> wish
> to issue S/MIME should start working on these.

Right. CAA-bis is a pre-requisite here.

As Neil correctly notes, it would be foolish to try to impose semantics and
apply
policy from the web CAA records onto email certificate issuance without first
figuring out what the semantics, requirements and policies should be for email
certificate issuance.

-Tim

[Pedro Fuentes]

El lunes, 14 de mayo de 2018, 23:59:07 (UTC+2), Tim Hollebeek escribió:

> As Neil correctly notes, it would be foolish to try to impose semantics and
> apply
> policy from the web CAA records onto email certificate issuance without first
> figuring out what the semantics, requirements and policies should be for email
> certificate issuance.
>
> -Tim

Maybe I'd add to the equation too that sometimes end-users can't easily choose which CA can use in a certain jurisdiction or user community.

I will subscribe the statement above from Neil: "Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would just want all participants in the PKI world to know what their statements mean and how far they reach. "

[Tim Hollebeek]

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

[Ryan Sleevi]

I don't actually think there is any IETF component to this. There can be,
but it's not required to be.

[Tim Hollebeek]

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:ry...@sleevi.com]
Sent: Monday, May 14, 2018 8:24 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: ry...@sleevi.com; Pedro Fuentes <pfuen...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-s...@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-secur...@lists.mozilla.org <mailto:dev-secur...@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-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

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-secur...@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:ry...@sleevi.com]
> Sent: Monday, May 14, 2018 8:24 PM
> To: Tim Hollebeek <tim.ho...@digicert.com>
> Cc: ry...@sleevi.com; Pedro Fuentes <pfuen...@gmail.com>;
> mozilla-dev-security-policy <mozilla-dev-s...@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-secur...@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-secur...@lists.mozilla.org <mailto:dev-security-policy@
> lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy

[Neil Dunbar]

> On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> 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?

While this is in no way comprehensive or scientific, could we not just poll those (larger) domain owners who also operate publicly available mail services (like Yahoo) what they consider the scope of their CAA assertions? There can’t be a super abundance of them, surely?

I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of ninja-changing semantics either. If domain owners intended to only express a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS or whatever); then might they not be amenable to altering their expression to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the scope of their (in-)actions?

That would then enable a future move for CAs to respect ‘issue’ and ‘issuewild’ to cover all cert types, while still allowing domain owners finer grained expression of their policies. It’s pretty much an entire reversal of my earlier suggestion(!), but perhaps a modification which would preserve the expressions of (handwave, handwave) 95% of CAA records owners who don’t operate public mail services, and yet still can cover those mail providers?

But without the courtesy of at least asking those few domain owners what they meant, it just seems a bit rude to assume their intentions.

Regards,

Neil

[Jürgen Brauckmann]

Ryan Sleevi via dev-security-policy wrote on 14.05.2018 20:52:
> And that still moves to an 'insecure-by-default', by making every site
> operator that has taken steps to actually restrict issuance not have those
> wishes respected.

Today, site operators have taken steps to secure issuance of server
certificates, following the guidance of the BRs.

Email certificates are a different use case with different internal
requirements.

Current CAA syntax lacks the possibility to distinguish between those
two, which will come as a big surprise for organisations who whish to
limit issuance of server certificates, but want to set different (or
none at all) policies for email certificates.

Mandating CAA checks in its current form also for email certificates
destroys or at least greatly hinders the rather creative technique of
having a general "no-issuance" CAA record and setting short-lived
issue-properties, as described in 6.3 of
https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf

Jürgen

[Ryan Sleevi]

On Tue, May 15, 2018 at 12:13 AM Neil Dunbar via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> > On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy <

> dev-secur...@lists.mozilla.org> wrote:
> >
> > 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?
>
> While this is in no way comprehensive or scientific, could we not just
> poll those (larger) domain owners who also operate publicly available mail
> services (like Yahoo) what they consider the scope of their CAA assertions?
> There can’t be a super abundance of them, surely?
>

No. I am expressly opposed to any solution that is “ask the big guys and
let them decide what it means for the Internet”.

While I can’t speak for Mozilla, that definitely seems against the spirit
of Mozilla’s principles of open and equal access.

It has a recasting failure mode as well, in that anyone who isn’t aware of
the subtlety of this proposed redefinition ends up less secure.

Surely you would agree that both of these consequences should be
unacceptable?

> I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of
> ninja-changing semantics either. If domain owners intended to only express
> a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS
> or whatever); then might they not be amenable to altering their expression
> to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the
> scope of their (in-)actions?
>
> That would then enable a future move for CAs to respect ‘issue’ and
> ‘issuewild’ to cover all cert types, while still allowing domain owners
> finer grained expression of their policies. It’s pretty much an entire
> reversal of my earlier suggestion(!), but perhaps a modification which
> would preserve the expressions of (handwave, handwave) 95% of CAA records
> owners who don’t operate public mail services, and yet still can cover
> those mail providers?
>
> But without the courtesy of at least asking those few domain owners what
> they meant, it just seems a bit rude to assume their intentions.
>
> Regards,
>
> Neil

[Ryan Sleevi]

On Tue, May 15, 2018 at 3:53 AM Jürgen Brauckmann <brauc...@dfn-cert.de>
wrote:

> Isn’t this exactly what I said?

That CAs need to work out how to describe “disallow for server auth, allow
for S/MIME?”

I feel like proponents of the minimally scoped CAA interpretation are in an
indefensible position - and the very self-same arguments that it “only”
applies to server auth could be made, just as incorrectly, that CAA only
applies to HTTPS certs and not SMTPS or the like.

We absolutely have to take CAA as an expression of CA restriction. It’s in
the very name! If you want to allow some CAs for some use cases, you need a
syntax to describe that. But you cannot make a reasonable argument that
“Just because they locked the door, they didn’t mean for us to not break a
window” - which is what every proposal to suggest CAA is server-only
fundamentally amounts to.

[Tim Hollebeek]

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:ry...@sleevi.com]
Sent: Monday, May 14, 2018 11:55 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: ry...@sleevi.com; Pedro Fuentes <pfuen...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-s...@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-secur...@lists.mozilla.org <mailto:dev-secur...@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:ry...@sleevi.com <mailto:ry...@sleevi.com> ]
Sent: Monday, May 14, 2018 8:24 PM
To: Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> >
Cc: ry...@sleevi.com <mailto:ry...@sleevi.com> ; Pedro Fuentes <pfuen...@gmail.com <mailto:pfuen...@gmail.com> >; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@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-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> <mailto:dev-secur...@lists.mozilla.org <mailto:dev-secur...@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-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> <mailto:dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> >
https://lists.mozilla.org/listinfo/dev-security-policy




_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Neil Dunbar]

> On 15 May 2018, at 05:56, Ryan Sleevi <ry...@sleevi.com> wrote:
>
> No. I am expressly opposed to any solution that is “ask the big guys and let them decide what it means for the Internet”.
>
> While I can’t speak for Mozilla, that definitely seems against the spirit of Mozilla’s principles of open and equal access.
>
> It has a recasting failure mode as well, in that anyone who isn’t aware of the subtlety of this proposed redefinition ends up less secure.
>
> Surely you would agree that both of these consequences should be unacceptable?

Then it seems we are at an impasse. I am 100% in favour of allowing domain holders (defined broadly) being able to express policy via CAA (and since CAA tags are extensible, such policies have only just begun to be developed), I am not yet convinced that current CAA expressions intended to bind anything except TLS certificate issuance for end entities within the domain holders.

If I might rudely (and probably wrongly) paraphrase Tim, my opinion on what is or should be is all but irrelevant, if those are the facts on the ground.

I’m certainly not in favour of ‘ask the big players what it means’ if that means accepting everything they have to say as holy writ - but garnering expressions of intent, from a clearly impacted contingent, in order to better inform a debate, is not equivalent to that, to my way of thinking.

At the very least, Mozilla would want to publicise more widely the scope of any proposed reinterpretation of CAA records; having the reinterpretation happen within a relatively small, though not exclusive, conclave doesn’t seem like good policy.

Regards,

Neil

[Ryan Sleevi]

Tim,

I hope you can see how this sort of response doesn't really do much to
engender faith and trust in CAs. I am not sure if you're aware of how this
can be perceived, but I suspect if you were, it might not have been so
glibly dismissed.

The only reason that "CAA is HTTPS-only" today is because CAs are not
interested in doing the 'right' thing. That is, to actually treat the CAA
as part of an integrated system of domain validation. The only reason we
even have HTTPS today is because browsers - notably Mozilla taking the lead
- required that CAs check CAA for HTTPS as a condition for remaining
trusted.

It appears that you're stating that unless a CA is forced to do something,
they have no incentive to actually adopt it. Rather than help establish
what secure norms are - that is, treat CAA is exactly what it tries to be
(a restriction on what CAs can issue) - it seems that you're arguing "As
long as everyone else can do bad, we have no reason to be better."

CAA has been finalized for 6 years (modulo the delay in editorial
formatting), and as a concept, goes back 8 years. Every step along the way,
a number of CAs opposed to, because they were concerned they wouldn't be
able to issue certs. Now we're hearing the same argument.

I hope you can do better than that, and that this sort of response doesn't
sully what remaining good will that DigiCert has. Consider how you could,
as a CA, more productively contribute to the discussion:

>From a purely informational standpoint:
1) Check CAA during the issuance of S/MIME certificates, and share details
about how many S/MIME certificates would fail the CAA check
2) Require CAA checks to succeed for S/MIME by default. If they fail,
require the customer/applicant give details about why the failure

>From an actually lead in security, rather than hide in a crowd of bad
actors:
3) Require CAA checks to succeed for S/MIME. Require the domain holder to
demonstrate explicit intent to allow DigiCert S/MIME issuance (for example,
adding a parameter to their issue records)

There are ways in which DigiCert is uniquely capable of showing technical
leadership and contributing to the discussion. Glib replies like this do
not do that, and only further cement the "CAs are shady" idea that further
erodes trust in PKIs, particularly S/MIME.

On Tue, May 15, 2018 at 9:11 AM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> 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:ry...@sleevi.com]
> *Sent:* Monday, May 14, 2018 11:55 PM
>
> *To:* Tim Hollebeek <tim.ho...@digicert.com>
> *Cc:* ry...@sleevi.com; Pedro Fuentes <pfuen...@gmail.com>;
> mozilla-dev-security-policy <mozilla-dev-s...@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-secur...@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:ry...@sleevi.com]
> Sent: Monday, May 14, 2018 8:24 PM
> To: Tim Hollebeek <tim.ho...@digicert.com>
> Cc: ry...@sleevi.com; Pedro Fuentes <pfuen...@gmail.com>;
> mozilla-dev-security-policy <mozilla-dev-s...@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-secur...@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-secur...@lists.mozilla.org <mailto:dev-security-policy@
> lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
>

[Matthew Hardeman]

For that matter, can whoever is in charge of gmail.com speak to their
intent as to CAA for S/MIME?

I've certainly held certificates which include my personal gmail address
before. At no point did I need or seek Google's blessing to do so. I can
not imagine that was an uncommon case. (At least, not uncommon relative to
the universe of issued S/MIME certificates.)

On Mon, May 14, 2018 at 11:13 PM, Neil Dunbar via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> > On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy <

> dev-secur...@lists.mozilla.org> wrote:
> >
> > 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?
>

> While this is in no way comprehensive or scientific, could we not just
> poll those (larger) domain owners who also operate publicly available mail
> services (like Yahoo) what they consider the scope of their CAA assertions?
> There can’t be a super abundance of them, surely?
>

> I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of
> ninja-changing semantics either. If domain owners intended to only express
> a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS
> or whatever); then might they not be amenable to altering their expression
> to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the
> scope of their (in-)actions?
>
> That would then enable a future move for CAs to respect ‘issue’ and
> ‘issuewild’ to cover all cert types, while still allowing domain owners
> finer grained expression of their policies. It’s pretty much an entire
> reversal of my earlier suggestion(!), but perhaps a modification which
> would preserve the expressions of (handwave, handwave) 95% of CAA records
> owners who don’t operate public mail services, and yet still can cover
> those mail providers?
>
> But without the courtesy of at least asking those few domain owners what
> they meant, it just seems a bit rude to assume their intentions.
>
> Regards,
>
> Neil

[Jürgen Brauckmann]

Am 15.05.2018 um 15:01 schrieb Ryan Sleevi:
> On Tue, May 15, 2018 at 3:53 AM Jürgen Brauckmann <brauc...@dfn-cert.de>
> wrote:
>> Today, site operators have taken steps to secure issuance of server
>> certificates, following the guidance of the BRs.
>>
>> Email certificates are a different use case with different internal
>> requirements.
>>
>> Current CAA syntax lacks the possibility to distinguish between those
>> two, which will come as a big surprise for organisations who whish to
>> limit issuance of server certificates, but want to set different (or
>> none at all) policies for email certificates.
>>
>> Mandating CAA checks in its current form also for email certificates
>> destroys or at least greatly hinders the rather creative technique of
>> having a general "no-issuance" CAA record and setting short-lived
>> issue-properties, as described in 6.3 of
>> https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf
>>
>> Isn’t this exactly what I said?
>
> That CAs need to work out how to describe “disallow for server auth, allow
> for S/MIME?”

I don't see how this can be done on a CA level.

How does example.org express "server certs from letsencrypt, S/MIME from
anybody" with current CAA syntax? CA-specific issue values don't help
with that problem.

> We absolutely have to take CAA as an expression of CA restriction. It’s in
> the very name! If you want to allow some CAs for some use cases, you need a
> syntax to describe that.

Which is lacking today.

> But you cannot make a reasonable argument that
> “Just because they locked the door, they didn’t mean for us to not break a
> window” - which is what every proposal to suggest CAA is server-only
> fundamentally amounts to.

CAA was introduced by the BRs, and is thus felt as server-only and is
used as server-only. Changing that is absolutely possible, but should be
done with care, as there are use-cases which will break if CAA is
adopted naively for email certs.

This is all about responsible change.

Jürgen

[Ryan Sleevi]

On Tue, May 15, 2018 at 11:02 AM, Jürgen Brauckmann via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

>
> I don't see how this can be done on a CA level.
>
> How does example.org express "server certs from letsencrypt, S/MIME from
> anybody" with current CAA syntax? CA-specific issue values don't help with
> that problem.

Sure they do. A CA that wished to do the right thing could define a syntax
in the CA/Browser Forum that all issuers are supposed to understand, such
as "scope=https" or even 'ekus=[foo,bar,baz]'

Absent a scope issuer parameter, then it's presumed to be global scope.
Present a scope parameter, it's syntax is defined.

That's an application of policy - what to do when CAA restrictions exist -
and that can be 'easily' defined.

There is, of course, the route of adding new flags or properties, both with
spec-required registries, but a security-positive CA can and should be
exploring ways to issue scoped restrictions (e.g. could introduce an
'issueserverauth')

> CAA was introduced by the BRs, and is thus felt as server-only and is used
> as server-only. Changing that is absolutely possible, but should be done
> with care, as there are use-cases which will break if CAA is adopted
> naively for email certs.
>

Sure, and in the absence of a force that actually ensures CAs respect
domain holders, we know there's not going to be any 'naive' adoption - that
is, it's clear that unless and until Root Stores require it, CAs won't
adopt it.

>
> This is all about responsible change.
>

CAA was introduced in the BRs because, despite 5 years of discussion, CAs
were opposed to it, because it would restrict what they could issue. The
same story is now playing out, with the same set of overwrought concerns.

[Neil Dunbar]

> On 15 May 2018, at 07:59, Matthew Hardeman <mhar...@gmail.com> wrote:
>
> For that matter, can whoever is in charge of gmail.com <http://gmail.com/> speak to their intent as to CAA for S/MIME?

>
> I've certainly held certificates which include my personal gmail address before. At no point did I need or seek Google's blessing to do so. I can not imagine that was an uncommon case. (At least, not uncommon relative to the universe of issued S/MIME certificates.)

Well, I don’t see a CAA record for gmail.com <http://gmail.com/>, thus even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME, such issuance would not be prohibited (unlike, say, google.com <http://google.com/>, which does have a CAA record).

In other words, those certificates that you were issued hitherto could not have violated CAA policy, since there was no such expression of policy.

Regards,

Neil

[Matthew Hardeman]

It is disingenuous to apply CAA to S/MIME and other certificate purposes
after the fact.

As a domain holder myself, having implemented CAA in certain domains, I did
intent to restrict issuance of server certificates. I have never intended
this to be a restriction of S/MIME certificate issuance. The name spaces
are different for email addresses versus DNS names. CAA aligns cleanly to
DNS names. It does not align cleanly to rfc822 names.

Mr. Sleevi's complaints regarding fail-open security are reasonable.
However, they seem misplaced within the scope of CAA, which at the most
basic level is a fail-open mechanism: lack of a CAA record assumes all
issuance allowed.

Reinterpreting the scope of extant CAA records might well have a chilling
effect on further adoption of CAA.

When an expressed intent such as CAA has (by definition OR by real-world
effect) a limited scope, many participants will not appreciate that scope
being expanded.

I believe the "issue" and "issuewild" tags should be regarded as pertaining
only to certificates which either 1) lack any EKU OR 2) include either
anyPurpose EKU or serverAuth EKUs.

[Matthew Hardeman]

Agreed. My point was to query the position of the administration of a
large generic email service as to their understanding of the implications
of CAA on their domains.

Certificates have different types of SANs for good cause: the nuances of
the name space differ.

For example, SAN rfc822Names versus SAN dnsNames. The X.509 certificate
distinguishes these names as belonging to separate name spaces. CAA does
not presently have this concept. Yet the proposal here would have us
relying upon the more simplistic DNS names expressed in CAA records.

[Ryan Sleevi]

Disingenuous seems like an unreasonable stretch.

By the logic expressed here, applying CAA enforcement to HTTPS was applying
CAA "after the fact" - after all, until CAs were required to enforce CAA,
how do we know that domains (... such as google.com or opera.com) meant to
restrict server certificate issuance? Couldn't they have been (in this poor
stretch of logic) trying to restrict issuance of S/MIME certificates
instead?

That's why the argument makes no sense.

As to rfc822 names not being mapped onto DNS, that's just definitionally
inaccurate. RFC822 names include a domain component. The addr-spec is
local-part "@" domain. With domain being the routable definition that we
all know and love. You can't just pretend that's not part of the scoping or
authority here.

On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> It is disingenuous to apply CAA to S/MIME and other certificate purposes
> after the fact.
>
> As a domain holder myself, having implemented CAA in certain domains, I did
> intent to restrict issuance of server certificates. I have never intended
> this to be a restriction of S/MIME certificate issuance. The name spaces
> are different for email addresses versus DNS names. CAA aligns cleanly to
> DNS names. It does not align cleanly to rfc822 names.
>
> Mr. Sleevi's complaints regarding fail-open security are reasonable.
> However, they seem misplaced within the scope of CAA, which at the most
> basic level is a fail-open mechanism: lack of a CAA record assumes all
> issuance allowed.
>
> Reinterpreting the scope of extant CAA records might well have a chilling
> effect on further adoption of CAA.
>
> When an expressed intent such as CAA has (by definition OR by real-world
> effect) a limited scope, many participants will not appreciate that scope
> being expanded.
>
> I believe the "issue" and "issuewild" tags should be regarded as pertaining
> only to certificates which either 1) lack any EKU OR 2) include either
> anyPurpose EKU or serverAuth EKUs.
>
>
>

[Ryan Sleevi]

Both types share a common namespace. The domain name space.

On Tue, May 15, 2018 at 12:10 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Agreed. My point was to query the position of the administration of a
> large generic email service as to their understanding of the implications
> of CAA on their domains.
>
> Certificates have different types of SANs for good cause: the nuances of
> the name space differ.
>
> For example, SAN rfc822Names versus SAN dnsNames. The X.509 certificate
> distinguishes these names as belonging to separate name spaces. CAA does
> not presently have this concept. Yet the proposal here would have us
> relying upon the more simplistic DNS names expressed in CAA records.
>

[Matthew Hardeman]

They certainly do share a common namespace. The trouble is that the email
address has more than just that common namespace.

If CAA is proposed for email certificates, I should be able to define a CAA
policy that prevents any CA from issuing for
particular.maligned.user.un...@mydomain.com while
allowing the following CAs to issue for any email address over the same
domain.

[Matthew Hardeman]

Nobody bothered with deploying CAA records until the run-up to eventual
enforcement for issuance of server certificates.

It was the incentive of having control over who would be permitted to issue
server certificates that inspired those who have done so to deploy CAA
records.

It is, in practical terms, revisionist to change the impact of those extant
deployments.

On Tue, May 15, 2018 at 11:14 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

> Disingenuous seems like an unreasonable stretch.
>
> By the logic expressed here, applying CAA enforcement to HTTPS was
> applying CAA "after the fact" - after all, until CAs were required to
> enforce CAA, how do we know that domains (... such as google.com or
> opera.com) meant to restrict server certificate issuance? Couldn't they
> have been (in this poor stretch of logic) trying to restrict issuance of
> S/MIME certificates instead?
>
> That's why the argument makes no sense.
>
> As to rfc822 names not being mapped onto DNS, that's just definitionally
> inaccurate. RFC822 names include a domain component. The addr-spec is
> local-part "@" domain. With domain being the routable definition that we
> all know and love. You can't just pretend that's not part of the scoping or
> authority here.
>
>

> On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> It is disingenuous to apply CAA to S/MIME and other certificate purposes
>> after the fact.
>>
>> As a domain holder myself, having implemented CAA in certain domains, I
>> did
>> intent to restrict issuance of server certificates. I have never intended
>> this to be a restriction of S/MIME certificate issuance. The name spaces
>> are different for email addresses versus DNS names. CAA aligns cleanly to
>> DNS names. It does not align cleanly to rfc822 names.
>>
>> Mr. Sleevi's complaints regarding fail-open security are reasonable.
>> However, they seem misplaced within the scope of CAA, which at the most
>> basic level is a fail-open mechanism: lack of a CAA record assumes all
>> issuance allowed.
>>
>> Reinterpreting the scope of extant CAA records might well have a chilling
>> effect on further adoption of CAA.
>>
>> When an expressed intent such as CAA has (by definition OR by real-world
>> effect) a limited scope, many participants will not appreciate that scope
>> being expanded.
>>
>> I believe the "issue" and "issuewild" tags should be regarded as
>> pertaining
>> only to certificates which either 1) lack any EKU OR 2) include either
>> anyPurpose EKU or serverAuth EKUs.
>>
>>
>>

[Tim Hollebeek]

Blatantly false. I actually suspect DigiCert might already support CAA for email. I haven’t double-checked.



-Tim

[Ryan Sleevi]

That's shifting the goalposts in order to argue against a strawman.

The minimum necessary for CAA for email is to restrict the domain access.

Might some people desire more feature-rich syntax? Perhaps. Is that a
necessary requirement? No.

On Tue, May 15, 2018 at 12:22 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> They certainly do share a common namespace. The trouble is that the email
> address has more than just that common namespace.
>
> If CAA is proposed for email certificates, I should be able to define a CAA
> policy that prevents any CA from issuing for
> particular.maligned.user.un...@mydomain.com while
> allowing the following CAs to issue for any email address over the same
> domain.
>
> On Tue, May 15, 2018 at 11:15 AM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
> > Both types share a common namespace. The domain name space.
> >

> > On Tue, May 15, 2018 at 12:10 PM, Matthew Hardeman via
> dev-security-policy

> > <dev-secur...@lists.mozilla.org> wrote:
> >
> >> Agreed. My point was to query the position of the administration of a
> >> large generic email service as to their understanding of the
> implications
> >> of CAA on their domains.
> >>
> >> Certificates have different types of SANs for good cause: the nuances of
> >> the name space differ.
> >>
> >> For example, SAN rfc822Names versus SAN dnsNames. The X.509 certificate
> >> distinguishes these names as belonging to separate name spaces. CAA
> does
> >> not presently have this concept. Yet the proposal here would have us
> >> relying upon the more simplistic DNS names expressed in CAA records.
> >>

[Wayne Thayer]

I don't see how this debate is leading us to a solution. Can we just
acknowledge that, prior to this discussion, the implications of CAA for the
issuance of email certificates was not well understood by CAs or domain
name registrants?

I share the desire to have a system that fails closed in the presence of
any CAA record, but that is a challenge as long as ecosystem participants
view CAA as applicable only to server certificates. The sooner we address
this issue, the better.

Mozilla policy isn't a great place to define CAA syntax. The CA/Browser
Forum currently has no jurisdiction over email, so at best could define
syntax to limit CAA scope to server certificates. The scope of the LAMPS
recharter for 6844bis appears too narrow to include this. What is the best
path forward?

- Wayne

[Ryan Sleevi]

On Tue, May 15, 2018 at 12:25 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Nobody bothered with deploying CAA records until the run-up to eventual
> enforcement for issuance of server certificates.
>

This is also factually untrue. You can't just make up stories here to
support your argument. Unless the argument is that "Nobody bothered with
deploying CAA records until CAA existed", by presuming that the 'run-up'
was from existence to requirement, in which case, that's a tautologically
true statement being used to try to misrepresent and mislead. Which is,
itself, problematic.

> It was the incentive of having control over who would be permitted to issue
> server certificates that inspired those who have done so to deploy CAA
> records.
>

Similarly, this continues to present opinion as fact.

>
> It is, in practical terms, revisionist to change the impact of those extant
> deployments.
>
> On Tue, May 15, 2018 at 11:14 AM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
> > Disingenuous seems like an unreasonable stretch.
> >
> > By the logic expressed here, applying CAA enforcement to HTTPS was
> > applying CAA "after the fact" - after all, until CAs were required to
> > enforce CAA, how do we know that domains (... such as google.com or
> > opera.com) meant to restrict server certificate issuance? Couldn't they
> > have been (in this poor stretch of logic) trying to restrict issuance of
> > S/MIME certificates instead?
> >
> > That's why the argument makes no sense.
> >
> > As to rfc822 names not being mapped onto DNS, that's just definitionally
> > inaccurate. RFC822 names include a domain component. The addr-spec is
> > local-part "@" domain. With domain being the routable definition that we
> > all know and love. You can't just pretend that's not part of the scoping
> or
> > authority here.
> >
> >

> > On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via
> dev-security-policy

[Matthew Hardeman]

I concur with Wayne's position that the discussion up to this point isn't
leading to a solution.

I represent nothing further than that I'm a systems and DNS administrator
and domain holder (and thus, I submit, an interested and not entirely
uninformed ecosystem participant) who has had an understanding historically
(whether or not correct) that CAA pertained to server certificates.

[Ryan Sleevi]

Tim,

Could you clarify then. Are you disagreeing that CAA is HTTPS only? As
these were your words only 3 hours ago -
https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ

On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek <tim.ho...@digicert.com>

[Tim Hollebeek]

The LAMPS re-charter is still open for discussion. I personally have no problem with CAA for email being in scope for 6844-bis. I’m actually in favor of that if it really is currently out of scope (I haven’t checked). Best to ask on the LAMPS charter thread.



-Tim

From: Wayne Thayer [mailto:wth...@mozilla.com]
Sent: Tuesday, May 15, 2018 12:41 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; Pedro Fuentes <pfuen...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: question about DNS CAA and S/MIME certificates

I don't see how this debate is leading us to a solution. Can we just acknowledge that, prior to this discussion, the implications of CAA for the issuance of email certificates was not well understood by CAs or domain name registrants?



I share the desire to have a system that fails closed in the presence of any CAA record, but that is a challenge as long as ecosystem participants view CAA as applicable only to server certificates. The sooner we address this issue, the better.



Mozilla policy isn't a great place to define CAA syntax. The CA/Browser Forum currently has no jurisdiction over email, so at best could define syntax to limit CAA scope to server certificates. The scope of the LAMPS recharter for 6844bis appears too narrow to include this. What is the best path forward?



- Wayne

[Tim Hollebeek]

I think CAA is and should be HTTPS only until there are clear rules for how it should work for email, and how to keep web CAA from interfering with email CAA. E-mail is currently the wild west and that needs to be fixed.



I’m strongly in favor of email CAA, once we get it ‘right’. But there’s no document out there that specifies what ‘right’ is yet. And there isn’t much value to CAA if only a few CAs do it.



That’s why I think we need 8644-bis first. Or another RFC explaining CAA for email.

-Tim



From: Ryan Sleevi [mailto:ry...@sleevi.com]

Sent: Tuesday, May 15, 2018 12:44 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: ry...@sleevi.com; Pedro Fuentes <pfuen...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: question about DNS CAA and S/MIME certificates

Tim,



Could you clarify then. Are you disagreeing that CAA is HTTPS only? As these were your words only 3 hours ago - https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ

[Ryan Sleevi]

There's a lot of contradictory statements here, so I'm not sure how best to
unpack them.

"I think CAA is and should be HTTPS only" is inconsistent, it seems, with
https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/PZgO5Qe0CQAJ

"There isn't much value to CAA if only a few CAs do it" seems inconsistent
with "another RFC explaining CAA for email" - rough consensus and running
code.

I agree that it's useful to determine what the priorities should be.

CAs' CP/CPS can document today what they do with CAA in S/MIME. CAA, as
written today, absolutely can support email. In an ideal world, CAs would
take the maximally restrictive approach to issuance, recognizing that
domain operators have primacy over their domains compared to any other
entity within their management authority, and that necessarily includes
e-mail.

I do not think it's at odds with the LAMPS charter for 6844-bis, because I
do not think it's at odds with 6844.

That said, this is all largely moot, because CAs have strong incentives to
not do anything with CAA until they're forced to, and to try to make it
someone else's problem as much as possible (passing the buck between CABF,
IETF, and root stores for S/MIME), and in the mean time, site operators
lose because unless and until CAs do something about it, there's no way
they can restrict S/MIME issuance, and thus there's fundamentally
questionable value to S/MIME issuance today. To the extent CAs want to cut
off their nose to spite their face, I suppose that's their prerogative.

The principle at play here, though - that CAA is not an intent to do
exactly what it says, which is restrict the issuance of certificates
bearing that domain (in all forms), is deeply troubling for any future
PKIs, and merely shows the trouble with reliance on third-party CAs in any
new PKIs.

On Tue, May 15, 2018 at 3:42 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> I think CAA is and should be HTTPS only until there are clear rules for
> how it should work for email, and how to keep web CAA from interfering with
> email CAA. E-mail is currently the wild west and that needs to be fixed.
>
>
>
> I’m strongly in favor of email CAA, once we get it ‘right’. But there’s
> no document out there that specifies what ‘right’ is yet. And there isn’t
> much value to CAA if only a few CAs do it.
>
>
>
> That’s why I think we need 8644-bis first. Or another RFC explaining CAA
> for email.
>
>
>
> -Tim
>
>
>

> *From:* Ryan Sleevi [mailto:ry...@sleevi.com]

> *Sent:* Tuesday, May 15, 2018 12:44 PM

> *To:* Tim Hollebeek <tim.ho...@digicert.com>

> *Cc:* ry...@sleevi.com; Pedro Fuentes <pfuen...@gmail.com>;
> mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org
> >
> *Subject:* Re: question about DNS CAA and S/MIME certificates

>
>
>
> Tim,
>
>
>
> Could you clarify then. Are you disagreeing that CAA is HTTPS only? As
> these were your words only 3 hours ago - https://groups.google.com/d/
> msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ
>
>
>
> On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek <

[hal...@gmail.com]

When I wrote CAA, my intention was for it to apply to SSL/TLS certs only. I did not consider S/MIME certs to be relevant precisely because of the al...@gmail.com problem.

I now realize that was entirely wrong and that there is in fact great utility in allowing domain owners to control their domains (or not).

If gmail want to limit the issue of Certs to one CA, fine. That is a business choice they have made. If you want to have control of your online identity, you need to have your own personal domain. That is why I have hallambaker.com. All my mail is forwarded to gmail.com but I control my identity and can change mail provider any time I want.

One use case that I see as definitive is to allow paypal to S/MIME sign their emails. That alone could take a bite out of phishing.

But even with gmail, the only circumstance I could see where a mail service provider like that would want to restrict cert issue to one CA would be if they were to roll out S/MIME with their own CA.

[Ryan Sleevi]

As you note, the focus on gmail.com is to entirely miss the point of
paypal.com - and virtually every other organizational identity out there
that wishes to sign their certificates.

Further, even when using 'hosted' mail provisioning, it's possible to use
S/MIME, possibly even with auto-enrollment (and even server-mediated S/MIME
- https://support.google.com/a/answer/6374496?hl=en ).

It's the same distinction between, say, Google AppEngine (in which Google
manages the certs and TLS termination) versus Google Cloud Platform (in
which you could fully terminate TLS in your VM with your own domain).

[Tim Hollebeek]

I agree with Phillip; if we want email CAA to be a thing, we need to define
and
specify that thing. And I think it should be a thing.

New RFCs are not that hard and need not even be that long.

-Tim

> https://clicktime.symantec.com/a/1/XjZsJF4yykVlCzqgt57_FIwsOTe0fR6a3C5kS
> Yh_IZ4=?d=lJg-wcLQ8TKi5x2vK8SJOJCjdKNbOFzJppz0UZwOpX_uS1wS1Mw-
> 5j_nOlfxrvZ_g0tSYqMRWJezQvAWyNySPmWiq8oV2gEI6bF-
> MXCodHj66yn6adEuwqxiAwHJd6tamadI6Kf-
> pHadUoBbCN15Wb8AEG3D126zrUxw7umhl5JRMC5lYu4kHiYb5kss5F0cvapf8h_
> U7XuRliUCpAUdVY_VtggCy6Hbk0u6x2IlNY411Cb49wMqOGMavYTwrT8CADJZ_
> OJ3cmVnrJLAclZ2Y96VSVSZpzc4h5UeBneGuFjm8T-ikCgGY3kDZfTHOOex-
> VrdHh0nbhZf-yoOgGiXg0naMQ0MnoHA_-L9tUotMKl1e-yScY5S-
> BG6sVyAe68iMOFtJaUYcyEV14-JlCiHpK8pRgYpdvB1V8O3IASeKCzuOiTPvJLrn-
> gCM2xICBAH-
> QzxWPVhgGZtP9OqMlqRDCJUeiAg9PJt&u=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-security-policy

[Tim Hollebeek]

This is the point I most strongly agree with.



-Tim

[hal...@gmail.com]

On Wednesday, May 16, 2018 at 2:16:14 AM UTC-4, Tim Hollebeek wrote:
> This is the point I most strongly agree with.
>

> I do not think it's at odds with the LAMPS charter for 6844-bis, because I do
> not think it's at odds with 6844.

Updating 6844 is easy. Just define the tag and specify scope for issue / issuewild / issueclient sensibly.

But that is only half the job really. If we want to get S/MIME widely used, we have to do ACME for client certs and integrate it into the MUAs. Not difficult but something needing to be done.

More difficult is working out what an S/MIME CA does, where organizational validation etc. adds value and how this relates to the OpenPGP way of doing things.


It occurred to me last night that the difference between S/MIME and OpenPGP trust is that one if by reference and the other is by value. S/MIME is certainly the solution for Paypal like situations because the trust relationship is (usually) with Paypal, not the individual I am talking to. Key fingerprints have the advantage of binding to the person which may be an advantage for non organizational situations.

These are not disjoint sets of course and there is no reason to switch mail encryption technologies depending on the context in which we are communicating. I would rather add certificate capabilities to OpenPGP-as-deployed and/or S/MIME-as-deployed.

[Tim Hollebeek]

> On Wednesday, May 16, 2018 at 2:16:14 AM UTC-4, Tim Hollebeek wrote:

> > This is the point I most strongly agree with.
> >

> > I do not think it's at odds with the LAMPS charter for 6844-bis,
> > because I do not think it's at odds with 6844.
>

> Updating 6844 is easy. Just define the tag and specify scope for issue /
> issuewild / issueclient sensibly.

Yup. I'm optimistic it's something we can get done quickly.

-Tim