subject:"Re\: \[cabfpub\] Continuing the discussion on CAA"

Re: [cabfpub] Continuing the discussion on CAA

2016-10-27 Thread Ryan Sleevi via Public

On Thu, Oct 27, 2016 at 3:44 PM, Richard Barnes via Public <
public@cabforum.org> wrote:

>
>
> On Thu, Oct 27, 2016 at 6:33 PM, Jody Cloutier via Public <
> public@cabforum.org> wrote:
>
>> Question: If a company has trusted roots, but it does not issue roots to
>> the general public, would it still have to check the CAA database?
>>
>
> I assume you mean "issue certificates"?
>
> I'm not sure what you mean by "not issuing to the general public", but I'm
> concerned about heading back toward the "internal names" exception that we
> killed not so long ago.
>

I don't think that's the direction Jody is speaking of, but moreso speaking
to the pattern of organizationally operated, contractually (but not
technically constrained) subordinate CAs. A perhaps concrete example of
this is Google Intermediate Authority - G2, which is signed by Symantec,
but which Google operates for Google domains.

The matter speaks to the heart of what degrees of (sub-)CAs there are, and
whether contractual enforcements are sufficient. On the one hand, we can
see that all such sub-CAs are expected to be operated to the same standard
as the roots signing them - c.f. WebTrust audits and BR compliance - but on
the other-hand, we can suspect that the need/use of this is restricted to a
certain subset.

Jody: As a concrete counterpoint, would you feel there should be exemptions
or carveouts (of any nature), for CAs that say, only issue to citizens, or
only to contractually-negotiated with parties?

I can see arguments both for and exist, so I'm mostly trying to see if
there's a common principal we can apply here for the question of sub-CAs
and CAA.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-27 Thread Jody Cloutier via Public

Correct, but remember that in this discussion Microsoft is both a Browser and a 
CA. 

-Original Message-
From: Rick Andrews [mailto:rick_andr...@symantec.com] 
Sent: Thursday, October 27, 2016 3:47 PM
To: CA/Browser Forum Public Discussion List 
Cc: Jody Cloutier 
Subject: RE: [cabfpub] Continuing the discussion on CAA

Jody, did you mean to say "it does not issue _certs_ to the general public"?
I think the answer is: if those certs are in scope for the BRs, then any
rules in the BRs about CAA take effect. 

Currently, the only rule in the BRs concerning CAA is that the CA has to
publish their CAA policy in their CP/CPS. It says nothing about what
browsers have to do ;^)

-Rick

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jody Cloutier
via Public
Sent: Thursday, October 27, 2016 3:34 PM
To: public@cabforum.org
Cc: Jody Cloutier 
Subject: Re: [cabfpub] Continuing the discussion on CAA

Question: If a company has trusted roots, but it does not issue roots to the
general public, would it still have to check the CAA database? 

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Andrew Ayer
via Public
Sent: Tuesday, October 25, 2016 10:32 AM
To: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Mon, 24 Oct 2016 18:52:06 +
Jeremy Rowley via Public  wrote:

> "CAA records MAY be used by Certificate Evaluators as a possible
>indicator of a security policy violation.  Such use SHOULD take
>account of the possibility that published CAA records changed 
> between the time a certificate was issued and the time at which the
>certificate was observed by the Certificate Evaluator."
> 
> I know it says this, but I'm not sure how this would ever happen in 
> practice. That seems more like the role of CT over CAA.

CT finds certificates but doesn't tell you whether a certificate was
authorized or not.  A CT monitor could check CAA records and raise an alarm
if a certificate was issued by an unauthorized CA.

Regards,
Andrew
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-27 Thread Jody Cloutier via Public

I’m just trying to rationalize the security benefit of a company like Microsoft 
checking CAA on every certificate it issues when it’s never going to issue to a 
third party. The amount of work is high and there’s almost no return for that 
for us because we only issue certs to Microsoft and Microsoft properties like 
Azure and Office.

From: Richard Barnes [mailto:rbar...@mozilla.com]
Sent: Thursday, October 27, 2016 3:45 PM
To: CA/Browser Forum Public Discussion List 
Cc: Jody Cloutier 
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Thu, Oct 27, 2016 at 6:33 PM, Jody Cloutier via Public 
mailto:public@cabforum.org>> wrote:
Question: If a company has trusted roots, but it does not issue roots to the 
general public, would it still have to check the CAA database?

I assume you mean "issue certificates"?
I'm not sure what you mean by "not issuing to the general public", but I'm 
concerned about heading back toward the "internal names" exception that we 
killed not so long ago.
--Richard

-Original Message-
From: Public 
[mailto:public-boun...@cabforum.org<mailto:public-boun...@cabforum.org>] On 
Behalf Of Andrew Ayer via Public
Sent: Tuesday, October 25, 2016 10:32 AM
To: public@cabforum.org<mailto:public@cabforum.org>
Subject: Re: [cabfpub] Continuing the discussion on CAA
On Mon, 24 Oct 2016 18:52:06 +
Jeremy Rowley via Public mailto:public@cabforum.org>> 
wrote:

> "CAA records MAY be used by Certificate Evaluators as a possible
>indicator of a security policy violation.  Such use SHOULD take
>account of the possibility that published CAA records changed
> between the time a certificate was issued and the time at which the
>certificate was observed by the Certificate Evaluator."
>
> I know it says this, but I'm not sure how this would ever happen in
> practice. That seems more like the role of CT over CAA.

CT finds certificates but doesn't tell you whether a certificate was authorized 
or not.  A CT monitor could check CAA records and raise an alarm if a 
certificate was issued by an unauthorized CA.

Regards,
Andrew
___
Public mailing list
Public@cabforum.org<mailto:Public@cabforum.org>
https://cabforum.org/mailman/listinfo/public
___
Public mailing list
Public@cabforum.org<mailto:Public@cabforum.org>
https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-27 Thread Rick Andrews via Public

Jody, did you mean to say "it does not issue _certs_ to the general public"?
I think the answer is: if those certs are in scope for the BRs, then any
rules in the BRs about CAA take effect. 

Currently, the only rule in the BRs concerning CAA is that the CA has to
publish their CAA policy in their CP/CPS. It says nothing about what
browsers have to do ;^)

-Rick

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jody Cloutier
via Public
Sent: Thursday, October 27, 2016 3:34 PM
To: public@cabforum.org
Cc: Jody Cloutier 
Subject: Re: [cabfpub] Continuing the discussion on CAA

Question: If a company has trusted roots, but it does not issue roots to the
general public, would it still have to check the CAA database? 

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Andrew Ayer
via Public
Sent: Tuesday, October 25, 2016 10:32 AM
To: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Mon, 24 Oct 2016 18:52:06 +
Jeremy Rowley via Public  wrote:

> "CAA records MAY be used by Certificate Evaluators as a possible
>indicator of a security policy violation.  Such use SHOULD take
>account of the possibility that published CAA records changed 
> between the time a certificate was issued and the time at which the
>certificate was observed by the Certificate Evaluator."
> 
> I know it says this, but I'm not sure how this would ever happen in 
> practice. That seems more like the role of CT over CAA.

CT finds certificates but doesn't tell you whether a certificate was
authorized or not.  A CT monitor could check CAA records and raise an alarm
if a certificate was issued by an unauthorized CA.

Regards,
Andrew
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-27 Thread Richard Barnes via Public

On Thu, Oct 27, 2016 at 6:33 PM, Jody Cloutier via Public <
public@cabforum.org> wrote:

> Question: If a company has trusted roots, but it does not issue roots to
> the general public, would it still have to check the CAA database?
>

I assume you mean "issue certificates"?

I'm not sure what you mean by "not issuing to the general public", but I'm
concerned about heading back toward the "internal names" exception that we
killed not so long ago.

--Richard



>
> -Original Message-
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Andrew
> Ayer via Public
> Sent: Tuesday, October 25, 2016 10:32 AM
> To: public@cabforum.org
> Subject: Re: [cabfpub] Continuing the discussion on CAA
>
> On Mon, 24 Oct 2016 18:52:06 +
> Jeremy Rowley via Public  wrote:
>
> > "CAA records MAY be used by Certificate Evaluators as a possible
> >indicator of a security policy violation.  Such use SHOULD take
> >account of the possibility that published CAA records changed
> > between the time a certificate was issued and the time at which the
> >certificate was observed by the Certificate Evaluator."
> >
> > I know it says this, but I'm not sure how this would ever happen in
> > practice. That seems more like the role of CT over CAA.
>
> CT finds certificates but doesn't tell you whether a certificate was
> authorized or not.  A CT monitor could check CAA records and raise an alarm
> if a certificate was issued by an unauthorized CA.
>
> Regards,
> Andrew
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-27 Thread Jody Cloutier via Public

Question: If a company has trusted roots, but it does not issue roots to the 
general public, would it still have to check the CAA database? 

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Andrew Ayer via 
Public
Sent: Tuesday, October 25, 2016 10:32 AM
To: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Mon, 24 Oct 2016 18:52:06 +
Jeremy Rowley via Public  wrote:

> "CAA records MAY be used by Certificate Evaluators as a possible
>indicator of a security policy violation.  Such use SHOULD take
>account of the possibility that published CAA records changed 
> between the time a certificate was issued and the time at which the
>certificate was observed by the Certificate Evaluator."
> 
> I know it says this, but I'm not sure how this would ever happen in 
> practice. That seems more like the role of CT over CAA.

CT finds certificates but doesn't tell you whether a certificate was authorized 
or not.  A CT monitor could check CAA records and raise an alarm if a 
certificate was issued by an unauthorized CA.

Regards,
Andrew
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-26 Thread Jacob Hoffman-Andrews via Public

On Tue, Oct 25, 2016 at 11:52 PM, Jeremy Rowley via Public <
public@cabforum.org> wrote:
> Basically, I’d like a way for the domain owner to opt-out of CAA checks
for performance reasons, which I think resolves the concerns you raised.

The performance problems may not be as bad as you think, with automation
and parallelization. For instance, Let's Encrypt recently issued over a
million certificates on a single day, with full CAA checking, and did not
find CAA to be a performance bottleneck.

I realize that may seem at odds with my earlier statement, so I'll quote it
here and add detail:

On Tue, Oct 18, 2016 at 11:26 AM, Jacob Hoffman-Andrews <
j...@letsencrypt.org> wrote:
> Let's Encrypt checks CAA at validation time rather than issuance time,
because DNS checks are slow and unreliable. Doing the check at validation
time allowed us to consolidate the external-facing parts of our process
into a single component, and monitor the performance of that component with
the knowledge that it is affected by factors outside our control.

Specifically, I mean that most of our internal RPCs complete in under a
second, and are monitored for such. However, validation requests are
allowed much longer because of variability in remote services. Also, it's
normal for some fraction of validation requests to timeout because some
fraction of our customers have misconfigured servers. That said, for a
given customer who has a correctly configured DNS responder, DNS lookups,
including CAA, are typically not a bad bottleneck.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-26 Thread Jeremy Rowley via Public

Thanks Ryan. For some reason “Reply All” is dropping the public list.

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, October 26, 2016 11:20 AM
To: Jeremy Rowley 
Cc: Eneli Kirme ; CABFPub 
Subject: Re: [cabfpub] Continuing the discussion on CAA

Reposting to the public list since, for some reason, Jeremy's reply-all dropped 
it.

On Wed, Oct 26, 2016 at 8:54 AM, Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

Plus, DNS records aren’t exactly hard to change. Considering the general lack 
of support for CAA, getting a CAA record in the DNS is a lot more difficult 
than changing the record once established.

From: Public [mailto:public-boun...@cabforum.org 
<mailto:public-boun...@cabforum.org> ] On Behalf Of Ryan Sleevi via Public
Sent: Wednesday, October 26, 2016 9:52 AM
To: Eneli Kirme mailto:eneli.ki...@sk.ee> >
Cc: CABFPub mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Oct 25, 2016 10:38 PM, "Eneli Kirme via Public" mailto:public@cabforum.org> > wrote:

>
> Hi, 
>
> In practice CAA record are subject to be manipulated by UI provided by DNS 
> records management. We have no way to control it and once there is a 
> “default” listed for customer convenience then the damage for fair market has 
> been placed. Without actually much thinking customers make a business 
> decision of one area in the context of another without much thinking about it.
> Can we from CABForum somehow protect against such “defaults”?
>

This has been discussed rather at length over the past two years. In Rick's 
slides from past meetings, you can find the discussion of differences between 
Kirk Hall and I on this, with Gervase supporting the position I put forward: 
No, we cannot.

I appreciate the concern, but I believe it is largely hypothetical, I believe 
that as a concern it prevents real security without any demonstrable risk, and 
should the situation ever arise in reality, we can actually evaluate it rather 
than the hypothetical.

But I do want to highlight that this argument has been used against CAA since 
2011, as the archives show, was previously made by Kirk Hall, and otherwise has 
prevented progress by raising the spectre of an issue without any real evidence.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-26 Thread Ryan Sleevi via Public

Reposting to the public list since, for some reason, Jeremy's reply-all
dropped it.

On Wed, Oct 26, 2016 at 8:54 AM, Jeremy Rowley 
wrote:

> Plus, DNS records aren’t exactly hard to change. Considering the general
> lack of support for CAA, getting a CAA record in the DNS is a lot more
> difficult than changing the record once established.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Wednesday, October 26, 2016 9:52 AM
> *To:* Eneli Kirme 
> *Cc:* CABFPub 
> *Subject:* Re: [cabfpub] Continuing the discussion on CAA
>
>
>
> On Oct 25, 2016 10:38 PM, "Eneli Kirme via Public" 
> wrote:
>
> >
> > Hi,
> >
> > In practice CAA record are subject to be manipulated by UI provided by
> DNS records management. We have no way to control it and once there is a
> “default” listed for customer convenience then the damage for fair market
> has been placed. Without actually much thinking customers make a business
> decision of one area in the context of another without much thinking about
> it.
> > Can we from CABForum somehow protect against such “defaults”?
> >
>
> This has been discussed rather at length over the past two years. In
> Rick's slides from past meetings, you can find the discussion of
> differences between Kirk Hall and I on this, with Gervase supporting the
> position I put forward: No, we cannot.
>
> I appreciate the concern, but I believe it is largely hypothetical, I
> believe that as a concern it prevents real security without any
> demonstrable risk, and should the situation ever arise in reality, we can
> actually evaluate it rather than the hypothetical.
>
> But I do want to highlight that this argument has been used against CAA
> since 2011, as the archives show, was previously made by Kirk Hall, and
> otherwise has prevented progress by raising the spectre of an issue without
> any real evidence.
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-26 Thread Ryan Sleevi via Public

On Oct 25, 2016 10:38 PM, "Eneli Kirme via Public" 
wrote:
>
> Hi,
>
> In practice CAA record are subject to be manipulated by UI provided by
DNS records management. We have no way to control it and once there is a
“default” listed for customer convenience then the damage for fair market
has been placed. Without actually much thinking customers make a business
decision of one area in the context of another without much thinking about
it.
> Can we from CABForum somehow protect against such “defaults”?
>

This has been discussed rather at length over the past two years. In Rick's
slides from past meetings, you can find the discussion of differences
between Kirk Hall and I on this, with Gervase supporting the position I put
forward: No, we cannot.

I appreciate the concern, but I believe it is largely hypothetical, I
believe that as a concern it prevents real security without any
demonstrable risk, and should the situation ever arise in reality, we can
actually evaluate it rather than the hypothetical.

But I do want to highlight that this argument has been used against CAA
since 2011, as the archives show, was previously made by Kirk Hall, and
otherwise has prevented progress by raising the spectre of an issue without
any real evidence.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-26 Thread Jeremy Rowley via Public

Thanks Gerv. "Subdomains" is a much better tag than the validation property I 
proposed in the email last night.

The scenario you described is exactly the one I'm trying to solve. Although 
the .example.com scenario you describe is uncommon ( I wouldn't 
say rare) on a customer basis, it's a large percentage of the number of 
certificates.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Wednesday, October 26, 2016 3:37 AM
To: Ryan Sleevi ; Jeremy Rowley

Cc: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 26/10/16 04:08, Ryan Sleevi wrote:
> A concrete example of why I believe this is fundamentally a flawed
> design, and do not support it, is situations where 'example.com
> <http://example.com>' delegates subdomains to different marketing
> companies, who are then responsible for hosting and providing the
> content on those subdomains. Expressing CAA in this 'top down'
> approach means that, for the 'base domain', you must express the union
> of all possible CAs. We know, empirically, this is not viable.

Indeed, it would be unwise to change CAA to _only_ work this way.

> Further, I want to challenge your notion of 'base domain',

I agree that making correct implementation of CAA depend on the PSL is
problematic - the more we can avoid using the PSL, the better.

Here is a straw-man proposal which does not require use of the PSL, although
it does require some caching outside of DNS in the case where the new feature
is used.

I don't think this solution is the most elegant technically, but Jeremy raises
the reasonable point about "what if I have to issue N million certs for
1.example.com, 2.example.com etc.?" Because caching doesn't help here, you
would have to do a full CAA check from scratch for everyone one of the N
million. This is a rare situation, to be sure, but I can see how it might be
problematic when it does occur.

So here's the idea:

1) CA is asked to issue for foo.bar.example.com
2) CA does CAA check for foo.bar.example.com - no record
3) CA does CAA check for bar.example.com - no record
4) CA does CAA check for example.com - record found

The record is "issue 0 superca.com; subdomains=true"

What this means is that Super CA is permitted to use this CAA record for all
issuances under example.com for the TTL specified on the DNS CAA record,
without doing further CAA checks on subdomains. Once that TTL expires, the
process would begin again from scratch.

The obvious question which arises then is: what happens when records conflict?
Say a few minutes after the above events, example.com adds a CAA record for
bar.example.com saying "issue 0 ahmedscerts.com". The answer is that the CA is
allowed to use the cached info about example.com for the DNS TTL, and after
that they re-check CAA from scratch, and hit this record, and so never get as
far as checking example.com. They instead refuse to issue, because only
Ahmed's Certs is allowed to.

OK, you ask, so what happens if the next domain they check is
wibble.example.com, which eventually gives them back the example.com CAA
record with "subdomains=true", and then they cache that, and use it to issue
later for bar.example.com, in "violation" of the CAA record attached directly
to bar.example.com? The answer is "don't put conflicting CAA records into your
DNS if you want defined and predictable behaviour". But it still remains true
that even in the worst and most badly configured case, the only CAs which can
issue anywhere under example.com are the ones named in a CAA record somewhere
within the domain, which is still a massive improvement on the current
situation.

Gerv

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-26 Thread Gervase Markham via Public

On 26/10/16 04:08, Ryan Sleevi wrote:
> A concrete example of why I believe this is fundamentally a flawed
> design, and do not support it, is situations where 'example.com
> ' delegates subdomains to different marketing
> companies, who are then responsible for hosting and providing the
> content on those subdomains. Expressing CAA in this 'top down' approach
> means that, for the 'base domain', you must express the union of all
> possible CAs. We know, empirically, this is not viable.

Indeed, it would be unwise to change CAA to _only_ work this way.

> Further, I want to challenge your notion of 'base domain', 

I agree that making correct implementation of CAA depend on the PSL is
problematic - the more we can avoid using the PSL, the better.

Here is a straw-man proposal which does not require use of the PSL,
although it does require some caching outside of DNS in the case where
the new feature is used.

I don't think this solution is the most elegant technically, but Jeremy
raises the reasonable point about "what if I have to issue N million
certs for 1.example.com, 2.example.com etc.?" Because caching doesn't
help here, you would have to do a full CAA check from scratch for
everyone one of the N million. This is a rare situation, to be sure, but
I can see how it might be problematic when it does occur.

So here's the idea:

1) CA is asked to issue for foo.bar.example.com
2) CA does CAA check for foo.bar.example.com - no record
3) CA does CAA check for bar.example.com - no record
4) CA does CAA check for example.com - record found

The record is "issue 0 superca.com; subdomains=true"

What this means is that Super CA is permitted to use this CAA record for
all issuances under example.com for the TTL specified on the DNS CAA
record, without doing further CAA checks on subdomains. Once that TTL
expires, the process would begin again from scratch.

The obvious question which arises then is: what happens when records
conflict? Say a few minutes after the above events, example.com adds a
CAA record for bar.example.com saying "issue 0 ahmedscerts.com". The
answer is that the CA is allowed to use the cached info about
example.com for the DNS TTL, and after that they re-check CAA from
scratch, and hit this record, and so never get as far as checking
example.com. They instead refuse to issue, because only Ahmed's Certs is
allowed to.

OK, you ask, so what happens if the next domain they check is
wibble.example.com, which eventually gives them back the example.com CAA
record with "subdomains=true", and then they cache that, and use it to
issue later for bar.example.com, in "violation" of the CAA record
attached directly to bar.example.com? The answer is "don't put
conflicting CAA records into your DNS if you want defined and
predictable behaviour". But it still remains true that even in the worst
and most badly configured case, the only CAs which can issue anywhere
under example.com are the ones named in a CAA record somewhere within
the domain, which is still a massive improvement on the current situation.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Jeremy Rowley via Public

I do think we are talking past each other, which is understandable because this 
idea was a pivot from the first one. Basically, I’d like a way for the domain 
owner to opt-out of CAA checks for performance reasons, which I think resolves 
the concerns you raised.

 

To put the idea in terms of the RFC:

  3.  The CAA RR Type

   A CAA RR consists of a flags byte and a tag-value pair referred to as a 
property.  Multiple properties MAY be associated with the same domain name by 
publishing multiple CAA RRs at that domain name.  The following flag is defined:

…

   {new} reverse  [; = ]:  The validation 
property entry authorizes Issuers to apply the policy set by the CAA record 
applies to all subordinate domains under the domain, effectively reversing the 
Certificate Authority Processing order described in [4]. 

 

As I mentioned before, the RFC is already established in a way that permits 
adding properties to the specification. This is an easy to way to match 
validation to the CAA record for those entities who are concerned with issuance 
times. Anyone wanting to ensure subdomains are separately delegated wouldn’t 
set the property.

 

Specific points:

I believe this is irrelevant. We're discussing scope of authority, not the 
presented information. DNS's scope of hierarchal authority flowing down 
involves delegating authority at each subordinate, which is why CAA works from 
the most authoritative scope (the fully qualified domain) and then works 
upwards.

 

{JR} I don’t think it’s irrelevant. We’re discussing how to distribute policy. 
CAA doesn’t have implications on DNS operations. 

 

 A simpler way to do this would simply have the base domain indicate whether 
the policy applies to all other domains. 

 

I appreciate your perspective, but I disagree. We (Google, the Internet 
community) have substantial experience in such 'top-down' policy expressions, 
via methods such as HSTS and HPKP, and we repeatedly receive concerns about 
that approach.

 

A concrete example of why I believe this is fundamentally a flawed design, and 
do not support it, is situations where 'example.com  ' 
delegates subdomains to different marketing companies, who are then responsible 
for hosting and providing the content on those subdomains. Expressing CAA in 
this 'top down' approach means that, for the 'base domain', you must express 
the union of all possible CAs. We know, empirically, this is not viable.

 

{JR} It is possible unless your name is Google, Microsoft, or some other large 
org. Government entities especially have a lot of domain names expressed in odd 
combinations. Using an express tag for validation lets the domain holder choose 
how to process the information, giving them control over the policy. It seems 
aligned with your goals of permitting domain owners to set policy. 

 

Further, I want to challenge your notion of 'base domain', which I know you 
mean in good intent, but for which I tried to highlight in my previous message 
is problematic in scope and determination. As you know, dependencies on the 
public suffix list are not at all desirable, in the general case, and there is 
substantial ambiguity and difference between information expressed in WHOIS 
(which I believe you're referring to, inasmuch as you mean 'registerable 
domain') and that expressed in DNS.

 

{JR} The CAA text doesn’t address this as is. Plus, the validation property 
only authorizes the issuer to rely on the CAA record already shown. It does not 
preclude standard CAA processing. For example:

 

   $ORIGIN example.com
   .   CAA 0 validation issue "ca.example.net"

 

And 

   $ORIGIN domain.example.com
   .   CAA 0 validation issue "ca2.example.net"

 

CA1 could issue to example.com or domain.example.com based on the validation 
flag. CA2 could still issue to domain.example.com (based on the CAA record) but 
could not issue to example.com.

 

This is already permitted in CAA with wildcards so simply adding a tag that 
specifies “apply to all domains” would be easier (Indeed – the spec is designed 
for this). How about PHB adds a tag of “base-approval=1” as a flag to indicate 
all superior labels are considered approved IF the flag is set. If the flag is 
not set, validation would have to occur at each node.

 

I've tried to explain why I believe your proposal is technically unsound and 
unworkable, but perhaps we're simply not communicating. I do encourage you to 
re-read the CAA spec, however, because your description of wildcards and tags 
is something that is quite ambiguous and problematic, so it would help if you 
could be more precise in your terms.

{JR} Sorry, all I was referencing here was that PHB already designed the RFC to 
accept additional properties (one example is the issuewild property). I was 
also emphasizing that this is totally optional for CAA users. If the validation 
property is not included, domain proces

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Eneli Kirme via Public

Hi,

In practice CAA record are subject to be manipulated by UI provided by DNS 
records management. We have no way to control it and once there is a “default” 
listed for customer convenience then the damage for fair market has been 
placed. Without actually much thinking customers make a business decision of 
one area in the context of another without much thinking about it.
Can we from CABForum somehow protect against such “defaults”?


Best regards,

Eneli



On 26 Oct 2016, at 06:08, Ryan Sleevi via Public 
mailto:public@cabforum.org>> wrote:



On Tue, Oct 25, 2016 at 7:54 PM, Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:
Although CAA was designed around DNS, the actual record isn’t relevant DNS 
information.

I believe this is irrelevant. We're discussing scope of authority, not the 
presented information. DNS's scope of hierarchal authority flowing down 
involves delegating authority at each subordinate, which is why CAA works from 
the most authoritative scope (the fully qualified domain) and then works 
upwards.

 A simpler way to do this would simply have the base domain indicate whether 
the policy applies to all other domains.

I appreciate your perspective, but I disagree. We (Google, the Internet 
community) have substantial experience in such 'top-down' policy expressions, 
via methods such as HSTS and HPKP, and we repeatedly receive concerns about 
that approach.

A concrete example of why I believe this is fundamentally a flawed design, and 
do not support it, is situations where 'example.com' 
delegates subdomains to different marketing companies, who are then responsible 
for hosting and providing the content on those subdomains. Expressing CAA in 
this 'top down' approach means that, for the 'base domain', you must express 
the union of all possible CAs. We know, empirically, this is not viable.

Further, I want to challenge your notion of 'base domain', which I know you 
mean in good intent, but for which I tried to highlight in my previous message 
is problematic in scope and determination. As you know, dependencies on the 
public suffix list are not at all desirable, in the general case, and there is 
substantial ambiguity and difference between information expressed in WHOIS 
(which I believe you're referring to, inasmuch as you mean 'registerable 
domain') and that expressed in DNS.

This is already permitted in CAA with wildcards so simply adding a tag that 
specifies “apply to all domains” would be easier (Indeed – the spec is designed 
for this). How about PHB adds a tag of “base-approval=1” as a flag to indicate 
all superior labels are considered approved IF the flag is set. If the flag is 
not set, validation would have to occur at each node.

I've tried to explain why I believe your proposal is technically unsound and 
unworkable, but perhaps we're simply not communicating. I do encourage you to 
re-read the CAA spec, however, because your description of wildcards and tags 
is something that is quite ambiguous and problematic, so it would help if you 
could be more precise in your terms.

For example, your suggestion that PHB "add a tag" is, as explained on past 
discussions, unnecessary. In CAA, there are are 'parameter tag' (also called 
'property tag'), such as 'issue', which are additive. That is, they expand the 
scope, not restrict it. Within a given 'issue' or 'issuewild' parameter tag, 
you can have issuer-parameters, but those are defined to further constrain the 
issuance, which again, is the opposite of what you intend.

I'm trying to highlight that there are substantial technical concerns, and 
resolving them to accommodate what you propose would require significant IETF 
action, even if they were agreed upon as desirable, which I do not believe they 
are. Further, I do not believe it aligns with what we concretely and 
empirically know about the experience and desires of site operators, both with 
respect to CAA and in related policy expressions.

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Ryan Sleevi via Public

On Tue, Oct 25, 2016 at 7:54 PM, Jeremy Rowley 
wrote:

> Although CAA was designed around DNS, the actual record isn’t relevant DNS
> information.
>

I believe this is irrelevant. We're discussing scope of authority, not the
presented information. DNS's scope of hierarchal authority flowing down
involves delegating authority at each subordinate, which is why CAA works
from the most authoritative scope (the fully qualified domain) and then
works upwards.

>  A simpler way to do this would simply have the base domain indicate
> whether the policy applies to all other domains.
>

I appreciate your perspective, but I disagree. We (Google, the Internet
community) have substantial experience in such 'top-down' policy
expressions, via methods such as HSTS and HPKP, and we repeatedly receive
concerns about that approach.

A concrete example of why I believe this is fundamentally a flawed design,
and do not support it, is situations where 'example.com' delegates
subdomains to different marketing companies, who are then responsible for
hosting and providing the content on those subdomains. Expressing CAA in
this 'top down' approach means that, for the 'base domain', you must
express the union of all possible CAs. We know, empirically, this is not
viable.

Further, I want to challenge your notion of 'base domain', which I know you
mean in good intent, but for which I tried to highlight in my previous
message is problematic in scope and determination. As you know,
dependencies on the public suffix list are not at all desirable, in the
general case, and there is substantial ambiguity and difference between
information expressed in WHOIS (which I believe you're referring to,
inasmuch as you mean 'registerable domain') and that expressed in DNS.

> This is already permitted in CAA with wildcards so simply adding a tag
> that specifies “apply to all domains” would be easier (Indeed – the spec is
> designed for this). How about PHB adds a tag of “base-approval=1” as a flag
> to indicate all superior labels are considered approved IF the flag is set.
> If the flag is not set, validation would have to occur at each node.
>

I've tried to explain why I believe your proposal is technically unsound
and unworkable, but perhaps we're simply not communicating. I do encourage
you to re-read the CAA spec, however, because your description of wildcards
and tags is something that is quite ambiguous and problematic, so it would
help if you could be more precise in your terms.

For example, your suggestion that PHB "add a tag" is, as explained on past
discussions, unnecessary. In CAA, there are are 'parameter tag' (also
called 'property tag'), such as 'issue', which are additive. That is, they
expand the scope, not restrict it. Within a given 'issue' or 'issuewild'
parameter tag, you can have issuer-parameters, but those are defined to
further constrain the issuance, which again, is the opposite of what you
intend.

I'm trying to highlight that there are substantial technical concerns, and
resolving them to accommodate what you propose would require significant
IETF action, even if they were agreed upon as desirable, which I do not
believe they are. Further, I do not believe it aligns with what we
concretely and empirically know about the experience and desires of site
operators, both with respect to CAA and in related policy expressions.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Jeremy Rowley via Public

Although CAA was designed around DNS, the actual record isn’t relevant DNS 
information. Since CAA is a policy decision that is being included in DNS as a 
convenient means of dissemination, any suitable replacement should be just as 
good if it has the same reliability of conveying info as the DNS records. 
Therefore, the structure of CAA doesn’t necessarily need to reflect the 
structure of DNS.  What if the primary label just contained all the CAs 
authorized for the domain? A simpler way to do this would simply have the base 
domain indicate whether the policy applies to all other domains. This is 
already permitted in CAA with wildcards so simply adding a tag that specifies 
“apply to all domains” would be easier (Indeed – the spec is designed for 
this). How about PHB adds a tag of “base-approval=1” as a flag to indicate all 
superior labels are considered approved IF the flag is set. If the flag is not 
set, validation would have to occur at each node. 

 

Jeremy

 

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, October 25, 2016 6:49 PM
To: Jeremy Rowley 
Cc: Gervase Markham ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

 

 

 

On Tue, Oct 25, 2016 at 4:26 PM, Jeremy Rowley via Public mailto:public@cabforum.org> > wrote:

Why not change how CAA so it works? Make it a base-domain check rather than a
hierarchy. Or have the base domain list all of the approved CAs? I realize
this will require a bis, but perhaps if the CAA record contained a "master
list" with a limit on who can approve at the base domain then that would work.
I was thinking of a system where you could specify the labelset property tag
applicable to the permission:

CAA 0 lbl=0 iodef "http://iodef.example.com/";

Where lbl is optional and defines the scope of the permission. This does put
the burden on the base domain holder to specify the acceptable root CAs, but
that burden is essentially already there with the permitted validation
processes.

 

The choice of how CAA was designed was to reflect how DNS works, and the DNS 
hierarchy. As proposed, this would allow, for example, the operators of .com, 
.cn, or .ru to restrict which CAs can be used within their countries - which, 
while perhaps possible today, is certainly not an intended use case for CAA. 
Unless, of course, you're suggesting it requires multiple labels - but now 
you're into the problem of determining scope of authority, which is an unsolved 
problem, if you're not explicitly working from the top down.

 

I'm not sure about your proposed syntax and how it maps into how CAA is 
defined, but that sounds like an even more substantive update that would 
necessitate fully replacing/obsoleting the existing CAA record.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Ryan Sleevi via Public

On Tue, Oct 25, 2016 at 4:26 PM, Jeremy Rowley via Public <
public@cabforum.org> wrote:

> Why not change how CAA so it works? Make it a base-domain check rather
> than a
> hierarchy. Or have the base domain list all of the approved CAs? I realize
> this will require a bis, but perhaps if the CAA record contained a "master
> list" with a limit on who can approve at the base domain then that would
> work.
> I was thinking of a system where you could specify the labelset property
> tag
> applicable to the permission:
>
> CAA 0 lbl=0 iodef "http://iodef.example.com/";
>
> Where lbl is optional and defines the scope of the permission. This does
> put
> the burden on the base domain holder to specify the acceptable root CAs,
> but
> that burden is essentially already there with the permitted validation
> processes.
>

The choice of how CAA was designed was to reflect how DNS works, and the
DNS hierarchy. As proposed, this would allow, for example, the operators of
.com, .cn, or .ru to restrict which CAs can be used within their countries
- which, while perhaps possible today, is certainly not an intended use
case for CAA. Unless, of course, you're suggesting it requires multiple
labels - but now you're into the problem of determining scope of authority,
which is an unsolved problem, if you're not explicitly working from the top
down.

I'm not sure about your proposed syntax and how it maps into how CAA is
defined, but that sounds like an even more substantive update that would
necessitate fully replacing/obsoleting the existing CAA record.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Jeremy Rowley via Public

Why not change how CAA so it works? Make it a base-domain check rather than a 
hierarchy. Or have the base domain list all of the approved CAs? I realize 
this will require a bis, but perhaps if the CAA record contained a "master 
list" with a limit on who can approve at the base domain then that would work. 
I was thinking of a system where you could specify the labelset property tag 
applicable to the permission:

CAA 0 lbl=0 iodef "http://iodef.example.com/";

Where lbl is optional and defines the scope of the permission. This does put 
the burden on the base domain holder to specify the acceptable root CAs, but 
that burden is essentially already there with the permitted validation 
processes.

Jeremy

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, October 25, 2016 2:57 AM
To: Jeremy Rowley ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 24/10/16 17:26, Jeremy Rowley wrote:
> 1)  CAA is currently an issuance check rather than a validation check.
> As mentioned during the face-to-face, this is a hurdle in fast
> issuance of certificates. We liked Ryan's proposal of simply doing a
> refresh every X days as a solution. By moving it to a validation
> check, CAs can have fast issuance times without CAA holding up the
> process after the initial validation is complete.

I think this is definitely worth exploring, and I am confident we can work out 
some reasonable parameters. However, I wonder if, if we are not checking CAA 
at every issuance, it would be wise for CAs to be required to implement a "no 
more certs, please" procedure where the customer can tell the CA to throw away 
all cached validation information, including the CAA check results. This could 
be automated in circumstances where the customer has a login.

> 2) If a customer has a single base domain and needs to issue 6 million
> certs an hour for the various sub domains, then there isn't a way for
> the CA to simply accept the base domain's CAA record.

I'm not sure how to address this without changing the way CAA works.
AIUI it's specced to work from the requested domain down to the root. So I'm 
not sure I'd say this problem is "easily solved". Does PHB have a comment?

Gerv

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Ryan Sleevi via Public

On Tue, Oct 25, 2016 at 2:38 PM, Rick Andrews 
wrote:

> Ryan, I don’t think it makes sense to me, but to be fair, it might be due
> to my limited knowledge of DNS. As for technical complexity, it seems
> simpler than CT ;^)
>
>
>
> I wasn’t proposing re-implementing DNS within our validation
> infrastructure. As far as I know, we already have recursive resolvers in
> our infrastructure (I think they’re also called stub resolvers), and again,
> as far as I know, they implement caching according to the DNS spec. Even if
> we didn’t have recursive resolvers in our infrastructure, and we used, say,
> Google’s 8.8.8.8, isn’t that also a recursive resolver that caches?
> Consulting my internal recursive resolver will be a bit faster than
> consulting one outside of my infrastructure, but it seems to me that the
> net effect is the same; caching prevents clients from seeing immediate
> changes made at the authoritative name servers.
>

I was trying to head off the suggestion, that say, within your validation
database, you do an authoritative lookup, see the TTL at some large value
(e.g. 48 hours), and then record that information within your validation
database.

With respect to the distinction between stub and recursive resolver, I was
specifically referring to the notion that some element of the CAs
infrastructure itself would be responsible for the recursive hierarchal
resolution - that is, root servers to authoritative servers, etc. The
implications of the term "stub resolver" would be that, say, you might
trust your ISP - or Google's 8.8.8.8 - to correctly perform that
resolution, which I don't think is the desirable outcome here with respect
to auditability nor the netsec requirements.

In either event, I think we're in agreement that DNS allows caching, and my
point is that I think it's unwise to add *additional* caching.

An example of additional caching which was discussed in the F2F, and which
is practiced by CAs today, but I think is potentially problematic, is that
the CA records in their validation database that they performed the CAA
check on some date (e.g. 1/1/2016), but then ignore DNS TTL and use that
cached result for some indefinite period.

This is not specific to CAA either - we know that CAs rely on cached
validation of domain ownership for up to 39 months after issuance. This is
useful with respect to general DNS cases, as for some TLDs, WHOIS
information simply isn't available, or isn't programatically accessible. So
I can understand the argument for allowing some degree of caching of what
may be a manual process. However, CAA doesn't require that manual
inferrence, and every domain can express CAA records themselves, and the
TTLs can be controlled by the domain administrator, so I was suggesting
that such a form of a caching - admistrative rather than technical - is
undesirable.

> Which concerns of Jacob’s are you’re referring to? The fact that
> LetsEncrypt does CAA checking at validation but not issuance time because
> it’s too expensive?
>

Jacob didn't suggest that it was too expensive -
https://cabforum.org/pipermail/public/2016-October/008576.html instead
states because it's externally facing, slow, and unreliable. That may have
been what you meant by expensive, but given that it's an overloaded term, I
thought it best to point directly to what Jacob stated.

> It sounds like your ideal case would require everyone to use DNS in a way
> that it wasn’t intended to be used (no caching). That makes me think that
> DNS isn’t the best place to keep this type of info, but I can’t think of a
> better place.
>

Sorry I wasn't clear, because that's not at all what I was saying. I was
suggesting that the ideal world is no caching *outside* of the methods of
caching defined within DNS. That is, no administrative databases of "Oh
yeah, we checked this via DNS a week ago, so we don't need to" - but
instead, using DNS resolvers (within the CAs control and scope) to perform
the lookup - and, incidentally, supporting caching as defined by DNS.

>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Rick Andrews via Public

Ryan, I don’t think it makes sense to me, but to be fair, it might be due to my 
limited knowledge of DNS. As for technical complexity, it seems simpler than CT 
;^)

 

I wasn’t proposing re-implementing DNS within our validation infrastructure. As 
far as I know, we already have recursive resolvers in our infrastructure (I 
think they’re also called stub resolvers), and again, as far as I know, they 
implement caching according to the DNS spec. Even if we didn’t have recursive 
resolvers in our infrastructure, and we used, say, Google’s 8.8.8.8, isn’t that 
also a recursive resolver that caches? Consulting my internal recursive 
resolver will be a bit faster than consulting one outside of my infrastructure, 
but it seems to me that the net effect is the same; caching prevents clients 
from seeing immediate changes made at the authoritative name servers. 

 

Which concerns of Jacob’s are you’re referring to? The fact that LetsEncrypt 
does CAA checking at validation but not issuance time because it’s too 
expensive?

 

It sounds like your ideal case would require everyone to use DNS in a way that 
it wasn’t intended to be used (no caching). That makes me think that DNS isn’t 
the best place to keep this type of info, but I can’t think of a better place.

 

-Rick

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, October 25, 2016 11:55 AM
To: Rick Andrews 
Cc: Gervase Markham ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

 

As mentioned during the meeting, this doesn't sound fundamentally problematic, 
just exceptionally technically complex - and we know that the greater the 
technical complexity, the harder it is for CAs to implement.

 

It's unclear whether your proposal is, in effect, suggesting that CAs should 
"re-implement" DNS within their validation databases. Isn't an alternative 
solution for the CA to run a recursive resolver within their infrastructure, 
have their CAA lookups utilize this internal recursive resolver (either 
immediately or within some tightly-bounded time, as appropriate for operational 
concerns), and then allow that recursive resolver to properly implement the DNS 
RFCs (which includes caching based on TTL)

 

I think this would split the difference between the concerns you raised, and 
Jacob raised, in as much as you still benefit from the 'don't communicate with 
outside services' goal, by utilizing a CA-maintained recursive resolver that 
strictly implements the DNS specification, while also allowing some flexibility 
with the integration of the systems.

 

Certainly, my 'ideal' world would be no 'implicit' caching (that is, always 
"check" CAA at issuance time), but for which CAs can utilize a recursive 
resolver as part of their CA infrastructure, and that recursive resolver 
implements any DNS-defined caching semantics. This at least gives relying 
parties - and perhaps more importantly, auditors - objective criteria for which 
they can threat model and evaluate these systems.

 

Does that make sense?

 

On Tue, Oct 25, 2016 at 11:43 AM, Rick Andrews mailto:rick_andr...@symantec.com> > wrote:

Ryan, one week may be appropriate for reuse of cached CAA records, but during 
the face-to-face meeting in Redmond, I realized that the time-to-live (TTL) of 
the CAA record could make that completely ineffective.

 

RFC 6844 doesn’t provide guidance on what TTL should be used on a CAA, but if a 
domain owner sets a TTL longer than one week, repeated checks by the CA would 
be served from cache and wouldn’t be served from the authoritative name server.

 

What do you think of allowing the CA to cache the CAA record for the TTL 
specified in the record? We could augment that with instructions to domain 
owners to pay careful attention to the TTL they specify in their CAA records.

 

-Rick

 

From: Public [mailto:public-boun...@cabforum.org 
<mailto:public-boun...@cabforum.org> ] On Behalf Of Ryan Sleevi via Public
Sent: Tuesday, October 25, 2016 8:22 AM
To: Gervase Markham mailto:g...@mozilla.org> >
Cc: public@cabforum.org <mailto:public@cabforum.org> 
Subject: Re: [cabfpub] Continuing the discussion on CAA

 

 

 

On Tue, Oct 25, 2016 at 1:57 AM, Gervase Markham via Public 
mailto:public@cabforum.org> > wrote:

I think this is definitely worth exploring, and I am confident we can
work out some reasonable parameters. However, I wonder if, if we are not
checking CAA at every issuance, it would be wise for CAs to be required
to implement a "no more certs, please" procedure where the customer can
tell the CA to throw away all cached validation information, including
the CAA check results. This could be automated in circumstances where
the customer has a login.

 

I think it may also be useful to do this for non-customers, but domain holders.

 

Consider the following certificate: https://crt.sh/?id=35360532

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Ryan Sleevi via Public

As mentioned during the meeting, this doesn't sound fundamentally
problematic, just exceptionally technically complex - and we know that the
greater the technical complexity, the harder it is for CAs to implement.

It's unclear whether your proposal is, in effect, suggesting that CAs
should "re-implement" DNS within their validation databases. Isn't an
alternative solution for the CA to run a recursive resolver within their
infrastructure, have their CAA lookups utilize this internal recursive
resolver (either immediately or within some tightly-bounded time, as
appropriate for operational concerns), and then allow that recursive
resolver to properly implement the DNS RFCs (which includes caching based
on TTL)

I think this would split the difference between the concerns you raised,
and Jacob raised, in as much as you still benefit from the 'don't
communicate with outside services' goal, by utilizing a CA-maintained
recursive resolver that strictly implements the DNS specification, while
also allowing some flexibility with the integration of the systems.

Certainly, my 'ideal' world would be no 'implicit' caching (that is, always
"check" CAA at issuance time), but for which CAs can utilize a recursive
resolver as part of their CA infrastructure, and that recursive resolver
implements any DNS-defined caching semantics. This at least gives relying
parties - and perhaps more importantly, auditors - objective criteria for
which they can threat model and evaluate these systems.

Does that make sense?

On Tue, Oct 25, 2016 at 11:43 AM, Rick Andrews 
wrote:

> Ryan, one week may be appropriate for reuse of cached CAA records, but
> during the face-to-face meeting in Redmond, I realized that the
> time-to-live (TTL) of the CAA record could make that completely ineffective.
>
>
>
> RFC 6844 doesn’t provide guidance on what TTL should be used on a CAA, but
> if a domain owner sets a TTL longer than one week, repeated checks by the
> CA would be served from cache and wouldn’t be served from the authoritative
> name server.
>
>
>
> What do you think of allowing the CA to cache the CAA record for the TTL
> specified in the record? We could augment that with instructions to domain
> owners to pay careful attention to the TTL they specify in their CAA
> records.
>
>
>
> -Rick
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Tuesday, October 25, 2016 8:22 AM
> *To:* Gervase Markham 
> *Cc:* public@cabforum.org
> *Subject:* Re: [cabfpub] Continuing the discussion on CAA
>
>
>
>
>
>
>
> On Tue, Oct 25, 2016 at 1:57 AM, Gervase Markham via Public <
> public@cabforum.org> wrote:
>
> I think this is definitely worth exploring, and I am confident we can
> work out some reasonable parameters. However, I wonder if, if we are not
> checking CAA at every issuance, it would be wise for CAs to be required
> to implement a "no more certs, please" procedure where the customer can
> tell the CA to throw away all cached validation information, including
> the CAA check results. This could be automated in circumstances where
> the customer has a login.
>
>
>
> I think it may also be useful to do this for non-customers, but domain
> holders.
>
>
>
> Consider the following certificate: https://crt.sh/?id=35360532
>
>
>
> It was issued 2016-09-26 to a customer on Google service's
>
> Since roughly 2016-03-31, googleusercontent.com has had a CAA record of 0
> issue symantec.com
>
>
>
> So why was this certificate issued? Well, as Jacob mentioned in
> https://cabforum.org/pipermail/public/2016-October/008576.html , Let's
> Encrypt checks CAA at validation time, not issuance time. Despite our CAA
> record helpfully preventing any new validations, this particular user had a
> pre-existing cached validation, according to Let's Encrypt, and so the new
> certificate was issued using the pre-existing validation.
>
>
>
> Ironically/unfortunately, it was this pre-existing validation (
> https://crt.sh/?id=14639682 ) that lead us to place CAA on the domain to
> begin with.
>
>
>
> Now, I'm not suggesting Let's Encrypt has misissued this certificate -
> it's why I've been continuing to call it 'unauthorized' issuance - and with
> respect to the BRs, everything LE did was correct. In particular, the
> re-use of cached information is fully permitted in the BRs (as many CAs
> know). However, from a our perspective, this was certainly 'a surprise' and
> not intended.
>
>
>
> So if we're going that route, I do believe we need to set a much tighter
> upper-bound than the current

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Rick Andrews via Public

Ryan, one week may be appropriate for reuse of cached CAA records, but during 
the face-to-face meeting in Redmond, I realized that the time-to-live (TTL) of 
the CAA record could make that completely ineffective.

RFC 6844 doesn’t provide guidance on what TTL should be used on a CAA, but if a 
domain owner sets a TTL longer than one week, repeated checks by the CA would 
be served from cache and wouldn’t be served from the authoritative name server.

What do you think of allowing the CA to cache the CAA record for the TTL 
specified in the record? We could augment that with instructions to domain 
owners to pay careful attention to the TTL they specify in their CAA records.

-Rick

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, October 25, 2016 8:22 AM
To: Gervase Markham 
Cc: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Tue, Oct 25, 2016 at 1:57 AM, Gervase Markham via Public 
mailto:public@cabforum.org> > wrote:

I think this is definitely worth exploring, and I am confident we can
work out some reasonable parameters. However, I wonder if, if we are not
checking CAA at every issuance, it would be wise for CAs to be required
to implement a "no more certs, please" procedure where the customer can
tell the CA to throw away all cached validation information, including
the CAA check results. This could be automated in circumstances where
the customer has a login.

I think it may also be useful to do this for non-customers, but domain holders.

Consider the following certificate: https://crt.sh/?id=35360532

It was issued 2016-09-26 to a customer on Google service's

Since roughly 2016-03-31, googleusercontent.com <http://googleusercontent.com>  
has had a CAA record of 0 issue symantec.com <http://symantec.com> 

So why was this certificate issued? Well, as Jacob mentioned in 
https://cabforum.org/pipermail/public/2016-October/008576.html , Let's Encrypt 
checks CAA at validation time, not issuance time. Despite our CAA record 
helpfully preventing any new validations, this particular user had a 
pre-existing cached validation, according to Let's Encrypt, and so the new 
certificate was issued using the pre-existing validation.

Ironically/unfortunately, it was this pre-existing validation ( 
https://crt.sh/?id=14639682 ) that lead us to place CAA on the domain to begin 
with.

Now, I'm not suggesting Let's Encrypt has misissued this certificate - it's why 
I've been continuing to call it 'unauthorized' issuance - and with respect to 
the BRs, everything LE did was correct. In particular, the re-use of cached 
information is fully permitted in the BRs (as many CAs know). However, from a 
our perspective, this was certainly 'a surprise' and not intended.

So if we're going that route, I do believe we need to set a much tighter 
upper-bound than the currently permissible 39 months. Unlike WHOIS information, 
for which we know some registrars don't provide or some registries make it 
considerably more difficult (c.f. the CAPTCHA/OCR issues of Comodo recently), 
CAA is something that any domain holder can express or maintain themselves, and 
any CA can query.

So it seems like one week or so should be the upper-bound to how long this 
information can be re-used.

As for how we're dealing with this unauthorized issuance, at least with an LE 
model, we need to submit every one of these 'unauthorized' certificates as 
problem reports, and hope that Let's Encrypt agrees with us on the basis of 
domain holder, and then hope that the associated cached data is thrown away. 
Further, for what it's worth, the BRs do not require that such cached info be 
thrown away on a problem report - that's simply Let's Encrypt going above and 
beyond the BRs to do what is common sense and necessary for security, and which 
other CAs may not be at that same level of maturity.

> 2) If a customer has a single base domain and needs to issue 6 million certs
> an hour for the various sub domains, then there isn't a way for the CA to
> simply accept the base domain's CAA record.

I'm not sure how to address this without changing the way CAA works.
AIUI it's specced to work from the requested domain down to the root. So
I'm not sure I'd say this problem is "easily solved". Does PHB have a
comment?

I'm not PHB, but you're absolutely correct that it's "not how CAA works". 

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Andrew Ayer via Public

On Mon, 24 Oct 2016 18:52:06 +
Jeremy Rowley via Public  wrote:

> "CAA records MAY be used by Certificate Evaluators as a possible
>indicator of a security policy violation.  Such use SHOULD take
>account of the possibility that published CAA records changed
> between the time a certificate was issued and the time at which the
>certificate was observed by the Certificate Evaluator."
> 
> I know it says this, but I'm not sure how this would ever happen in
> practice. That seems more like the role of CT over CAA.

CT finds certificates but doesn't tell you whether a certificate
was authorized or not.  A CT monitor could check CAA records and raise
an alarm if a certificate was issued by an unauthorized CA.

Regards,
Andrew
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Ryan Sleevi via Public

On Tue, Oct 25, 2016 at 1:57 AM, Gervase Markham via Public <
public@cabforum.org> wrote:
>
> I think this is definitely worth exploring, and I am confident we can
> work out some reasonable parameters. However, I wonder if, if we are not
> checking CAA at every issuance, it would be wise for CAs to be required
> to implement a "no more certs, please" procedure where the customer can
> tell the CA to throw away all cached validation information, including
> the CAA check results. This could be automated in circumstances where
> the customer has a login.
>

I think it may also be useful to do this for non-customers, but domain
holders.

Consider the following certificate: https://crt.sh/?id=35360532

It was issued 2016-09-26 to a customer on Google service's
Since roughly 2016-03-31, googleusercontent.com has had a CAA record of 0
issue symantec.com

So why was this certificate issued? Well, as Jacob mentioned in
https://cabforum.org/pipermail/public/2016-October/008576.html , Let's
Encrypt checks CAA at validation time, not issuance time. Despite our CAA
record helpfully preventing any new validations, this particular user had a
pre-existing cached validation, according to Let's Encrypt, and so the new
certificate was issued using the pre-existing validation.

Ironically/unfortunately, it was this pre-existing validation (
https://crt.sh/?id=14639682 ) that lead us to place CAA on the domain to
begin with.

Now, I'm not suggesting Let's Encrypt has misissued this certificate - it's
why I've been continuing to call it 'unauthorized' issuance - and with
respect to the BRs, everything LE did was correct. In particular, the
re-use of cached information is fully permitted in the BRs (as many CAs
know). However, from a our perspective, this was certainly 'a surprise' and
not intended.

So if we're going that route, I do believe we need to set a much tighter
upper-bound than the currently permissible 39 months. Unlike WHOIS
information, for which we know some registrars don't provide or some
registries make it considerably more difficult (c.f. the CAPTCHA/OCR issues
of Comodo recently), CAA is something that any domain holder can express or
maintain themselves, and any CA can query.

So it seems like one week or so should be the upper-bound to how long this
information can be re-used.

As for how we're dealing with this unauthorized issuance, at least with an
LE model, we need to submit every one of these 'unauthorized' certificates
as problem reports, and hope that Let's Encrypt agrees with us on the basis
of domain holder, and then hope that the associated cached data is thrown
away. Further, for what it's worth, the BRs do not require that such cached
info be thrown away on a problem report - that's simply Let's Encrypt going
above and beyond the BRs to do what is common sense and necessary for
security, and which other CAs may not be at that same level of maturity.

> > 2) If a customer has a single base domain and needs to issue 6 million
> certs
> > an hour for the various sub domains, then there isn't a way for the CA to
> > simply accept the base domain's CAA record.
>
> I'm not sure how to address this without changing the way CAA works.
> AIUI it's specced to work from the requested domain down to the root. So
> I'm not sure I'd say this problem is "easily solved". Does PHB have a
> comment?

I'm not PHB, but you're absolutely correct that it's "not how CAA works".
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-25 Thread Gervase Markham via Public

On 24/10/16 17:26, Jeremy Rowley wrote:
> 1)  CAA is currently an issuance check rather than a validation check. As 
> mentioned during the face-to-face, this is a hurdle in fast issuance of 
> certificates. We liked Ryan's proposal of simply doing a refresh every X days 
> as a solution. By moving it to a validation check, CAs can have fast issuance 
> times without CAA holding up the process after the initial validation is 
> complete.

I think this is definitely worth exploring, and I am confident we can
work out some reasonable parameters. However, I wonder if, if we are not
checking CAA at every issuance, it would be wise for CAs to be required
to implement a "no more certs, please" procedure where the customer can
tell the CA to throw away all cached validation information, including
the CAA check results. This could be automated in circumstances where
the customer has a login.

> 2) If a customer has a single base domain and needs to issue 6 million certs 
> an hour for the various sub domains, then there isn't a way for the CA to 
> simply accept the base domain's CAA record.

I'm not sure how to address this without changing the way CAA works.
AIUI it's specced to work from the requested domain down to the root. So
I'm not sure I'd say this problem is "easily solved". Does PHB have a
comment?

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Peter Bowen via Public

Kirk,

I can comment on amazonaws.com.  AWS only has three CAs we use - 
Symantec/VeriSign, DigiCert, and Amazon.  

Here are some certificates that were not authorized by the domain registrant:
https://crt.sh/?id=31536432 <https://crt.sh/?id=31536432> (StartCom)
https://crt.sh/?id=30860174 <https://crt.sh/?id=30860174> (WoSign)
https://crt.sh/?id=30103632 <https://crt.sh/?id=30103632> (GlobalSign)
https://crt.sh/?id=42702005 <https://crt.sh/?id=42702005> (GeoTrust)
https://crt.sh/?id=3608723 <https://crt.sh/?id=3608723> (Vodafone)
https://crt.sh/?id=8271636 <https://crt.sh/?id=8271636> (Agencia Catalana de 
Certificacio)

I don’t believe these were ordered by people falling into either of the 
categories you list — they were not employees nor were they fraudsters.  I am 
sure the CAs followed one of the 3.2.2.4 methods and probably even followed a 
method that will still be allowed after ballot 169 comes into force.  However, 
I’m 100% confident that the domain owner would prefer to have all certificates 
using FQDNs and Wildcard DNs under the domain follow corporate policies.

Does that help?

Thanks,
Peter

> On Oct 24, 2016, at 2:04 PM, Kirk Hall via Public  wrote:
> 
> Thanks Ryan – that is helpful.
>  
> Can you tell us who ordered the two certificates you listed?  By an employee, 
> or by a fraudster?
>  
> In what way was the googleusercontent.com <http://googleusercontent.com/> 
> cert “not authorized”?
>  
> From: Ryan Sleevi [mailto:sle...@google.com <mailto:sle...@google.com>] 
> Sent: Monday, October 24, 2016 1:58 PM
> To: Kirk Hall  <mailto:kirk.h...@entrustdatacard.com>>
> Cc: Jeremy Rowley  <mailto:jeremy.row...@digicert.com>>; public@cabforum.org 
> <mailto:public@cabforum.org>
> Subject: Re: [cabfpub] Continuing the discussion on CAA
>  
>  
>  
> On Mon, Oct 24, 2016 at 1:50 PM, Kirk Hall  <mailto:kirk.h...@entrustdatacard.com>> wrote:
> Ryan, your response is cryptic and confusing.  I think we are wasting time.
>  
> I literally and specifically gave you multiple examples - both of where CAA 
> *could have* prevented unauthorized issuance to third parties and where CAA 
> *has* prevented unauthorized issuace to third parties, with specific domain 
> names and CAs.
>  
> I cannot help you if you are unable to participate in a technical discussion, 
> but it's very clear that the bar is not "convince you", but "explain to you" 
> - and the latter is something that's only possible if you're honestly 
> interested in learning, which, at this point, I can only conclude is yet 
> another attempt to avoid productive discussions.
>  
> Can you please avoid quoting other stuff (not sure what it proves or how it 
> helps)
>  
> It shows me attempting to honestly engage in your request that I "restate 
> whatever evidence you have"
>  
> and just lay out on the Public list your examples in simple English of cases 
> where CAA would have prevented misissuance of a certificate to a fraudster 
> not associated with the organization that owns or controls the domain 
> requested?  I don’t believe this has explicitly been discussed on the Public 
> list before.
>  
> And yet again, you're disrespectfully changing the conversation when it's 
> been pointed out you're mistaken.
>  
> In this case, after providing you the examples you specifically claimed were 
> absent, and reminding you of specific conversations you were part of in which 
> they were answered, you've now suggested that they're insufficient because 
> they weren't discussed on the public list. As the Chair, this does not bode 
> well at all for the future of the Forum that you would engage in such tactics 
> so brazenly.
>  
> I will attempt to repeat for you:
> googleusercontent.com <http://googleusercontent.com/>
> - Certs were not authorized, but conformed to 3.2.2.4. They were issued.
> - We added CAA
> - Certs are prevented now
>  
> amazonaws.com <http://amazonaws.com/>
> - Certs were not authorized, but conformed to 3.2.2.4. They were issued.
> - Amazon has not added CAA
> - Unauthorized certs are still possible
>  
> Microsoft Azure
> - Microsoft expressed repeatedly concerns with 3.2.2.4 about certs that were 
> not authorized being issued.
>  
> I'm not sure how much simpler I can make it for you. But I'm certainly 
> unwilling, at this point, to continue to engage with you on this topic, 
> considering how dismissive you've been throughout the 2.5 years that we've 
> been discussing this. Perhaps it would be better if someone more technically 
> capable engaged on your behalf, so we can at least have productive 
> disc

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Ryan Sleevi via Public

Kirk,

It's sad to see your promise was so short lived. That is, the " I promise I
will read the links carefully for the details you have provided. " promise
you made one hour ago.

Since your message is not appearing in the archives, I'll link you to the
reply in which I quoted you, in the hopes it will jog your memory of you
making that promise -
https://cabforum.org/pipermail/public/2016-October/008630.html

And then I'll link you to the post where I already answered this for you,
less than an hour ago, in the hopes it will continue to jog your memory:
https://cabforum.org/pipermail/public/2016-October/008630.html

Perhaps you can read the above link carefully for the details I have
provided? That'd be great. Thanks.

On Mon, Oct 24, 2016 at 2:04 PM, Kirk Hall 
wrote:

> Thanks Ryan – that is helpful.
>
>
>
> Can you tell us who ordered the two certificates you listed?  By an
> employee, or by a fraudster?
>
>
>
> In what way was the googleusercontent.com cert “not authorized”?
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Monday, October 24, 2016 1:58 PM
> *To:* Kirk Hall 
> *Cc:* Jeremy Rowley ; public@cabforum.org
> *Subject:* Re: [cabfpub] Continuing the discussion on CAA
>
>
>
>
>
>
>
> On Mon, Oct 24, 2016 at 1:50 PM, Kirk Hall 
> wrote:
>
> Ryan, your response is cryptic and confusing.  I think we are wasting time.
>
>
>
> I literally and specifically gave you multiple examples - both of where
> CAA *could have* prevented unauthorized issuance to third parties and where
> CAA *has* prevented unauthorized issuace to third parties, with specific
> domain names and CAs.
>
>
>
> I cannot help you if you are unable to participate in a technical
> discussion, but it's very clear that the bar is not "convince you", but
> "explain to you" - and the latter is something that's only possible if
> you're honestly interested in learning, which, at this point, I can only
> conclude is yet another attempt to avoid productive discussions.
>
>
>
> Can you please avoid quoting other stuff (not sure what it proves or how
> it helps)
>
>
>
> It shows me attempting to honestly engage in your request that I "restate
> whatever evidence you have"
>
>
>
> and just lay out on the Public list your examples in simple English of
> cases where CAA would have prevented misissuance of a certificate to a
> fraudster not associated with the organization that owns or controls the
> domain requested?  I don’t believe this has explicitly been discussed on
> the Public list before.
>
>
>
> And yet again, you're disrespectfully changing the conversation when it's
> been pointed out you're mistaken.
>
>
>
> In this case, after providing you the examples you specifically claimed
> were absent, and reminding you of specific conversations you were part of
> in which they were answered, you've now suggested that they're insufficient
> because they weren't discussed on the public list. As the Chair, this does
> not bode well at all for the future of the Forum that you would engage in
> such tactics so brazenly.
>
>
>
> I will attempt to repeat for you:
>
> googleusercontent.com
>
> - Certs were not authorized, but conformed to 3.2.2.4. They were issued.
>
> - We added CAA
>
> - Certs are prevented now
>
>
>
> amazonaws.com
>
> - Certs were not authorized, but conformed to 3.2.2.4. They were issued.
>
> - Amazon has not added CAA
>
> - Unauthorized certs are still possible
>
>
>
> Microsoft Azure
>
> - Microsoft expressed repeatedly concerns with 3.2.2.4 about certs that
> were not authorized being issued.
>
>
>
> I'm not sure how much simpler I can make it for you. But I'm certainly
> unwilling, at this point, to continue to engage with you on this topic,
> considering how dismissive you've been throughout the 2.5 years that we've
> been discussing this. Perhaps it would be better if someone more
> technically capable engaged on your behalf, so we can at least have
> productive discussions about where to draw the line between technical and
> policy solutions.
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Kirk Hall via Public

Thanks Ryan – that is helpful.

Can you tell us who ordered the two certificates you listed?  By an employee, 
or by a fraudster?

In what way was the googleusercontent.com cert “not authorized”?

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Monday, October 24, 2016 1:58 PM
To: Kirk Hall 
Cc: Jeremy Rowley ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Mon, Oct 24, 2016 at 1:50 PM, Kirk Hall 
mailto:kirk.h...@entrustdatacard.com>> wrote:
Ryan, your response is cryptic and confusing.  I think we are wasting time.

I literally and specifically gave you multiple examples - both of where CAA 
*could have* prevented unauthorized issuance to third parties and where CAA 
*has* prevented unauthorized issuace to third parties, with specific domain 
names and CAs.

I cannot help you if you are unable to participate in a technical discussion, 
but it's very clear that the bar is not "convince you", but "explain to you" - 
and the latter is something that's only possible if you're honestly interested 
in learning, which, at this point, I can only conclude is yet another attempt 
to avoid productive discussions.

Can you please avoid quoting other stuff (not sure what it proves or how it 
helps)

It shows me attempting to honestly engage in your request that I "restate 
whatever evidence you have"

and just lay out on the Public list your examples in simple English of cases 
where CAA would have prevented misissuance of a certificate to a fraudster not 
associated with the organization that owns or controls the domain requested?  I 
don’t believe this has explicitly been discussed on the Public list before.

And yet again, you're disrespectfully changing the conversation when it's been 
pointed out you're mistaken.

In this case, after providing you the examples you specifically claimed were 
absent, and reminding you of specific conversations you were part of in which 
they were answered, you've now suggested that they're insufficient because they 
weren't discussed on the public list. As the Chair, this does not bode well at 
all for the future of the Forum that you would engage in such tactics so 
brazenly.

I will attempt to repeat for you:
googleusercontent.com<http://googleusercontent.com>
- Certs were not authorized, but conformed to 3.2.2.4. They were issued.
- We added CAA
- Certs are prevented now

amazonaws.com<http://amazonaws.com>
- Certs were not authorized, but conformed to 3.2.2.4. They were issued.
- Amazon has not added CAA
- Unauthorized certs are still possible

Microsoft Azure
- Microsoft expressed repeatedly concerns with 3.2.2.4 about certs that were 
not authorized being issued.

I'm not sure how much simpler I can make it for you. But I'm certainly 
unwilling, at this point, to continue to engage with you on this topic, 
considering how dismissive you've been throughout the 2.5 years that we've been 
discussing this. Perhaps it would be better if someone more technically capable 
engaged on your behalf, so we can at least have productive discussions about 
where to draw the line between technical and policy solutions.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Ryan Sleevi via Public

On Mon, Oct 24, 2016 at 1:50 PM, Kirk Hall 
wrote:

> Ryan, your response is cryptic and confusing.  I think we are wasting time.
>

I literally and specifically gave you multiple examples - both of where CAA
*could have* prevented unauthorized issuance to third parties and where CAA
*has* prevented unauthorized issuace to third parties, with specific domain
names and CAs.

I cannot help you if you are unable to participate in a technical
discussion, but it's very clear that the bar is not "convince you", but
"explain to you" - and the latter is something that's only possible if
you're honestly interested in learning, which, at this point, I can only
conclude is yet another attempt to avoid productive discussions.

> Can you please avoid quoting other stuff (not sure what it proves or how
> it helps)
>

It shows me attempting to honestly engage in your request that I "restate
whatever evidence you have"

> and just lay out on the Public list your examples in simple English of
> cases where CAA would have prevented misissuance of a certificate to a
> fraudster not associated with the organization that owns or controls the
> domain requested?  I don’t believe this has explicitly been discussed on
> the Public list before.
>

And yet again, you're disrespectfully changing the conversation when it's
been pointed out you're mistaken.

In this case, after providing you the examples you specifically claimed
were absent, and reminding you of specific conversations you were part of
in which they were answered, you've now suggested that they're insufficient
because they weren't discussed on the public list. As the Chair, this does
not bode well at all for the future of the Forum that you would engage in
such tactics so brazenly.

I will attempt to repeat for you:
googleusercontent.com
- Certs were not authorized, but conformed to 3.2.2.4. They were issued.
- We added CAA
- Certs are prevented now

amazonaws.com
- Certs were not authorized, but conformed to 3.2.2.4. They were issued.
- Amazon has not added CAA
- Unauthorized certs are still possible

Microsoft Azure
- Microsoft expressed repeatedly concerns with 3.2.2.4 about certs that
were not authorized being issued.

I'm not sure how much simpler I can make it for you. But I'm certainly
unwilling, at this point, to continue to engage with you on this topic,
considering how dismissive you've been throughout the 2.5 years that we've
been discussing this. Perhaps it would be better if someone more
technically capable engaged on your behalf, so we can at least have
productive discussions about where to draw the line between technical and
policy solutions.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Kirk Hall via Public

Ryan, your response is cryptic and confusing.  I think we are wasting time.

Can you please avoid quoting other stuff (not sure what it proves or how it 
helps) and just lay out on the Public list your examples in simple English of 
cases where CAA would have prevented misissuance of a certificate to a 
fraudster not associated with the organization that owns or controls the domain 
requested?  I don’t believe this has explicitly been discussed on the Public 
list before.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Monday, October 24, 2016 1:41 PM
To: Kirk Hall 
Cc: Jeremy Rowley ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA



On Mon, Oct 24, 2016 at 1:38 PM, Kirk Hall 
mailto:kirk.h...@entrustdatacard.com>> wrote:
Ryan, this discussion is happening on the Public list, and members of the 
public were not at our meeting.

Which is why minutes of our phone calls and meetings are so important.

  So please drop your quibbling, and just restate whatever evidence you have – 
on the Public list, so everyone can evaluate it – that CAA would have prevented 
any known misissuance of certificates to a fraudster not associated with the 
certificate applicant.

It looks like the paragraph beginning "In the case of Google domains, we went " 
may have been dropped, so I've provided it again for you, in the hopes it might 
make it through this time, and your memory might be jogged.

"In the case of Google domains, we went and added CAA records to our 
properties, which has prevented unauthorized issuance. I was precise in my 
terminology here - unauthorized - because it's not authorized by the domain 
holder, even if it's valid according to the language of Section 3.2.2.4"
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Ryan Sleevi via Public

On Mon, Oct 24, 2016 at 1:38 PM, Kirk Hall 
wrote:

> Ryan, this discussion is happening on the Public list, and members of the
> public were not at our meeting.
>

Which is why minutes of our phone calls and meetings are so important.

>   So please drop your quibbling, and just restate whatever evidence you
> have – on the Public list, so everyone can evaluate it – that CAA would
> have prevented any known misissuance of certificates to a fraudster not
> associated with the certificate applicant.
>

It looks like the paragraph beginning "In the case of Google domains, we
went " may have been dropped, so I've provided it again for you, in the
hopes it might make it through this time, and your memory might be jogged.

"In the case of Google domains, we went and added CAA records to our
properties, which has prevented unauthorized issuance. I was precise in my
terminology here - unauthorized - because it's not authorized by the domain
holder, even if it's valid according to the language of Section 3.2.2.4"
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Kirk Hall via Public

Ryan, this discussion is happening on the Public list, and members of the 
public were not at our meeting.  So please drop your quibbling, and just 
restate whatever evidence you have – on the Public list, so everyone can 
evaluate it – that CAA would have prevented any known misissuance of 
certificates to a fraudster not associated with the certificate applicant.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Monday, October 24, 2016 1:29 PM
To: Kirk Hall 
Cc: Jeremy Rowley ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On Mon, Oct 24, 2016 at 12:09 PM, Kirk Hall 
mailto:kirk.h...@entrustdatacard.com>> wrote:
Yes, please provide the links to all – I certainly don’t remember any details 
from what you have said in the past, and others feel the same way.  I promise I 
will read the links carefully for the details you have provided.

Considering that you actively participated in a discussion about this, less 
than a week ago, and that we've previously discussed this on calls, you've 
really exhausted all good faith for participating in these discussions.

But I have to say, Ryan, it’s not useful when you always say “I answered that 
before” instead of going ahead and answering it again – just humor us, please.

Kirk, it's not useful when you can engage in a discussion, and within days of 
it completing, ask the same question and be ignorant of the discussion you 
participated in.

Perhaps it would be better if you wait for the minutes to be posted, so you can 
remember what you asked, and how you were answered.

You and others are asking a lot of CAs when you push us to hard stop on CAA, so 
you really owe it to all of us to be patient and try to persuade us your 
preferred course of action is, in fact, a good idea.

Well, as Gerv said, I think an alternative is for root programs to mandate this.

We've been discussing this for years. You've continued to use this argument 
time and time again, and every time it's answered, in good faith, you then wait 
a few weeks, and ask it again. It's incredibly disrespectful - and suggests you 
either don't care about the response or don't care to engage in good faith.

I've been debating CAA with you for over two years - consider posts like 
https://cabforum.org/pipermail/public/2014-May/003291.html or your strawmen 
like https://cabforum.org/wp-content/uploads/Current-State-of-CAA-Sep2014.pdf , 
or attempts at things like 
https://cabforum.org/pipermail/public/2014-September/003843.html .

You've tried to ask variations of this question before - consider 
https://cabforum.org/2015/10/29/2015-10-29-minutes/

But since you're going to continue this line of inquiry, let me restate to you 
what was shared at the F2F:

You asked, during the F2F, whether any CA's had been prevented of misissuance. 
When I attempted to respond, you got upset, feeling that I was interrupting you 
and asked to be allowed to finish your question. You then further re-iterated 
your desire to understand third-party issuance cases. I described to you two 
types of unauthorized issuances, to third-parties, that had been observed by 
members in the room.

One example discussed was googleusercontent.com<http://googleusercontent.com>, 
which allows third-parties to host content, but for which TLS termination is 
always handled by Google. In this case, users were able to obtain certificates 
from Let's Encrypt, because we lacked CAA records at the time, but allowed user 
content on some sub-domains for this domain.

I then pointed to Peter, and discussed that Amazon had encountered a nearly 
identical situation with Amazon AWS, which also provides TLS termination for 
the clients. Amazon lacked CAA records, and customers were able to obtain 
certificates from WoSign, using WoSign's file-based validation method.

In the case of Google domains, we went and added CAA records to our properties, 
which has prevented unauthorized issuance. I was precise in my terminology here 
- unauthorized - because it's not authorized by the domain holder, even if it's 
valid according to the language of Section 3.2.2.4

During this discussion, I engaged with Bruce Morton, your colleague, to discuss 
how CAA is complementary to what is already afforded in the BRs, but due to a 
wording error, seen as nuance. That is, if you have a pre-existing relationship 
with a CA, you can define a set of authorized requestors, but you cannot do so 
unless and until the CA has already issued a certificate for your domain. This 
was seen, by members in the room, as 'unintentional' - that is, that the intent 
was to cover both cases. Bruce and I, with microphones, discussed the 
challenges that a CA would have processing such requests, and where CAA affords 
a technical solution to a problem that was incompletely solved via policy.

Later on in that day, during the same discussion, whil

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Ryan Sleevi via Public

On Mon, Oct 24, 2016 at 12:09 PM, Kirk Hall 
wrote:

> Yes, please provide the links to all – I certainly don’t remember any
> details from what you have said in the past, and others feel the same way.
> I promise I will read the links carefully for the details you have
> provided.
>

Considering that you actively participated in a discussion about this, less
than a week ago, and that we've previously discussed this on calls, you've
really exhausted all good faith for participating in these discussions.

> But I have to say, Ryan, it’s not useful when you always say “I answered
> that before” instead of going ahead and answering it again – just humor us,
> please.
>

Kirk, it's not useful when you can engage in a discussion, and within days
of it completing, ask the same question and be ignorant of the discussion
you participated in.

Perhaps it would be better if you wait for the minutes to be posted, so you
can remember what you asked, and how you were answered.

> You and others are asking a lot of CAs when you push us to hard stop on
> CAA, so you really owe it to all of us to be patient and try to persuade us
> your preferred course of action is, in fact, a good idea.
>

Well, as Gerv said, I think an alternative is for root programs to mandate
this.

We've been discussing this for years. You've continued to use this argument
time and time again, and every time it's answered, in good faith, you then
wait a few weeks, and ask it again. It's incredibly disrespectful - and
suggests you either don't care about the response or don't care to engage
in good faith.

I've been debating CAA with you for over two years - consider posts like
https://cabforum.org/pipermail/public/2014-May/003291.html or your strawmen
like
https://cabforum.org/wp-content/uploads/Current-State-of-CAA-Sep2014.pdf ,
or attempts at things like
https://cabforum.org/pipermail/public/2014-September/003843.html .

You've tried to ask variations of this question before - consider
https://cabforum.org/2015/10/29/2015-10-29-minutes/

But since you're going to continue this line of inquiry, let me restate to
you what was shared at the F2F:

You asked, during the F2F, whether any CA's had been prevented of
misissuance. When I attempted to respond, you got upset, feeling that I was
interrupting you and asked to be allowed to finish your question. You then
further re-iterated your desire to understand third-party issuance cases. I
described to you two types of unauthorized issuances, to third-parties,
that had been observed by members in the room.

One example discussed was googleusercontent.com, which allows third-parties
to host content, but for which TLS termination is always handled by Google.
In this case, users were able to obtain certificates from Let's Encrypt,
because we lacked CAA records at the time, but allowed user content on some
sub-domains for this domain.

I then pointed to Peter, and discussed that Amazon had encountered a nearly
identical situation with Amazon AWS, which also provides TLS termination
for the clients. Amazon lacked CAA records, and customers were able to
obtain certificates from WoSign, using WoSign's file-based validation
method.

In the case of Google domains, we went and added CAA records to our
properties, which has prevented unauthorized issuance. I was precise in my
terminology here - unauthorized - because it's not authorized by the domain
holder, even if it's valid according to the language of Section 3.2.2.4

During this discussion, I engaged with Bruce Morton, your colleague, to
discuss how CAA is complementary to what is already afforded in the BRs,
but due to a wording error, seen as nuance. That is, if you have a
pre-existing relationship with a CA, you can define a set of authorized
requestors, but you cannot do so unless and until the CA has already issued
a certificate for your domain. This was seen, by members in the room, as
'unintentional' - that is, that the intent was to cover both cases. Bruce
and I, with microphones, discussed the challenges that a CA would have
processing such requests, and where CAA affords a technical solution to a
problem that was incompletely solved via policy.

Later on in that day, during the same discussion, while you were also
present, with Jeremy standing up with a microphone, with Peter having the
microphone that offered feedback, and with me in the back with a
microphone, we discussed how 3.2.2.4's different means of authorizing
requests provide different levels of assurances. This was during the
discussion about whether the "domain admin" has the authorization to
express such policy. After Alex Wright pointed out that the domain admin
already has great capability to exceed the policy, Peter pointed out that
not all authorization methods used DNS, and that DNS is not in a special
position with respect to issuance. I disagreed with Peter, pointing out the
case raised by Anoosh at Microsoft during Anoosh's time participating, with
the previously-numbered method

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Ryan Sleevi via Public

On Mon, Oct 24, 2016 at 11:32 AM, Kirk Hall 
wrote:

> Ryan, I have to admit I have not always understood your response on
> Jeremy’s question (which I have asked myself).  You have said at times “we
> already answered that”, but I think many of us can’t recall what your exact
> answer was.
>

I do hope that the minutes from the F2F will show that Andrew and I
responded to this, in person. I believe Jeremy was present, but you were
certainly present.

In the F2F, we discussed cases where Amazon could have benefited from CAA
(due to unauthorized issuance), and cases where Google has benefited from
CAA - preventing letsencrypt certificates for domains where we allow
customer-controlled content.

You, specifically, have raised this several calls, and I've responded both
on list and in person, so I'm really not sure how I can more productively
and clearly communicate the value of CAA, as perceived by Google. It is
precisely because of this repeated question - and the ability to
conveniently forget answers - that it increasingly becomes harder to see
this as a benign question born of genuine curiouisity, but rather an active
attempt to disrupt a valuable security improvement by feigning ignorance or
conveniently forgetting.

To assist in the future, I'll just link you this message in the archives.

> However, as I understand it Google wants to prevent a genuine Google
> employee from buying a cert from a CA that is not on a corporate-approved
> list of CAs shown in a CAA record, and so Google is supporting CAA as a way
> of preventing genuine Google employees from ordering a cert from a CA not
> on Google’s CAA list.  I can see why an enterprise like Google might want
> that, but to my mind a cert issued with the approval of a genuine Google
> employee from a CA not on the corporate CAA list of approved CAs is *not*
> “misissuance” in the sense that we normally use the term – instead, it is
> non-compliance by a Google employee with an internal corporate policy,
> which is normally handled internally by the corporation, and not pushed out
> to CAs to help in enforcing internal corporate policies.
>

While I appreciate your attempt to educate me on terminology, please
re-read that I communicated: unauthorized issuance.

We discussed this at the F2F as well - the challenges provided in the
current BRs for the language provided, which allows restricting authorized
cert requestors, but only to CAs for which the company has a pre-existing
relationship. The specific nature of this conversation was with your
employers' other representative, Bruce Morton, and in the context of
discussing how, in the absence of a strict enforcement of CAA, it would be
necessary to address this loophole (which some members present expressed as
'unintentional') via policy.

If it appears that I'm frustrated with you, it is the case, because you in
particular have asked this question. If you recall, you asked the same
question Jeremy did, during the F2F not even a week ago, and I responded to
you, in person, immediately following your asking it.

So please don't position it that I haven't answered this before - on the
list, on calls, and less than a week ago in person.

> So – *excluding* cases where a genuine Google employee has ordered or
> obtained a cert for a Google domain from a CA not on Google’s CAA list of
> approved CAs (not considered “misissuance” for the purpose of this
> question) – can you provide any details as to other cases where CAA would
> have prevented true “misissuance” of a cert to a fraudster not connected to
> the organization that owns the domain in question?  Those examples would be
> very helpful to this discussion.
>

The examples I provided you, in person, at Meeting 39, were specifically
about third-parties, not Google employees. The same examples I've provided
you every time you've asked, but for which I'll link to this thread from
now on.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Ryan Sleevi via Public

Jeremy,

This has been repeatedly asked on calls, and each time Google provides
details about how it has prevented unauthorized issuance?

Can we accept CAA has worked, helped for those CAs that check, and move on?


On Mon, Oct 24, 2016 at 8:40 AM, Jeremy Rowley via Public <
public@cabforum.org> wrote:

> Has there been an issuance to a third party that CAA would have prevented?
> Since there's no way to ensure compliance with a hard-fail CAA requirement,
> will CAA do anything useful? We don't mind CAA as a validation check, but
> I'm curious if anyone knows of an issued cert that would have been rejected
> if CAA were fully implemented.
>
> -Original Message-
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase
> Markham via Public
> Sent: Monday, October 24, 2016 5:38 AM
> To: Eneli Kirme ; public@cabforum.org
> Subject: Re: [cabfpub] Continuing the discussion on CAA
>
> Hi Eneli,
>
> On 24/10/16 12:08, Eneli Kirme via Public wrote:
> > But consider this scenario: a hypothetical CoolCA approaching a DNS
> > service provider, be it an ISP, domain registrar or some kind of
> > hosting provider, with a proposal to include a CAA record pointing to
> > the CoolCA into their default configuration.
>
> I would expect the DNS service provider to refuse, because otherwise
> they'll
> have a lot of angry customers ringing them up, saying "my CA tells me I
> can't have a certificate, and it's your fault".
>
> However, to address this, would it be reasonable to add a clause in the
> CAA-related change which said something like: "CAs MUST NOT add (or cause
> or
> request to be added) CAA records to the DNS without the explicit permission
> of the domain owner."
>
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Doug Beattie via Public

Jeremy,

I agree - For the Managed service model where CAs pre-vet domains we’d like to 
check CAA at the domain level and re-use that for all subdomains.  Maybe we can 
tie CAA into the domain validation process and allow the application of CAA and 
domain validation to the same Authorization Domain value which would enable 
high speed/volume issuance under a common domain (or a common subdomain).   
Requiring the CA to check every FQDN for CAA compliance at the time of issuance 
will hinder performance and could result in denial of service vectors not 
previously available (DNS DDoS attacks).

Doug

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Monday, October 24, 2016 12:26 PM
To: Gervase Markham; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

Thanks Gerv. Very useful.

I think there are just three concerns with CAA I'd like to address before 
hard-fail is required:
1)  CAA is currently an issuance check rather than a validation check. As 
mentioned during the face-to-face, this is a hurdle in fast issuance of 
certificates. We liked Ryan's proposal of simply doing a refresh every X days 
as a solution. By moving it to a validation check, CAs can have fast issuance 
times without CAA holding up the process after the initial validation is 
complete.
2) If a customer has a single base domain and needs to issue 6 million certs an 
hour for the various sub domains, then there isn't a way for the CA to simply 
accept the base domain's CAA record.
3) The validation process is actually opposite of what is required by CAA. 
The order required for CAA descends in scope rather than ascends (ie, check 
third level, then second level). Validation under 169 takes the opposite 
approach. The base domain is often used for validation without regard to 
anything specified in sub domains. Seems like we should pivot CAA to match the 
actual validation process and have the CAA scope match the domain authorization 
scope. Without doing this you run into an inconsistency where the customer 
could obtain *.example.com but not secure.example.com. This doesn't make sense 
as we like to encourage customers to use non-wildcard names when possible.

Problems #2 and #3 are easily solved together. Permitting verification of a sub 
domain to override the higher level domains solves performance issues, still 
restricts the scope of what CAs can issue, and permits high speed/volume 
issuance off a base domain.

Thoughts?
Jeremy

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Monday, October 24, 2016 9:43 AM
To: Jeremy Rowley ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 24/10/16 16:40, Jeremy Rowley via Public wrote:
> Has there been an issuance to a third party that CAA would have prevented?
> Since there's no way to ensure compliance with a hard-fail CAA 
> requirement, will CAA do anything useful? We don't mind CAA as a 
> validation check, but I'm curious if anyone knows of an issued cert 
> that would have been rejected if CAA were fully implemented.

https://github.com/letsencrypt/boulder/issues/1231 :-)

Gerv

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Jeremy Rowley via Public

Thanks Gerv. Very useful.

I think there are just three concerns with CAA I'd like to address before 
hard-fail is required:
1)  CAA is currently an issuance check rather than a validation check. As 
mentioned during the face-to-face, this is a hurdle in fast issuance of 
certificates. We liked Ryan's proposal of simply doing a refresh every X days 
as a solution. By moving it to a validation check, CAs can have fast issuance 
times without CAA holding up the process after the initial validation is 
complete.
2) If a customer has a single base domain and needs to issue 6 million certs 
an hour for the various sub domains, then there isn't a way for the CA to 
simply accept the base domain's CAA record.
3) The validation process is actually opposite of what is required by CAA. 
The order required for CAA descends in scope rather than ascends (ie, check 
third level, then second level). Validation under 169 takes the opposite 
approach. The base domain is often used for validation without regard to 
anything specified in sub domains. Seems like we should pivot CAA to match the 
actual validation process and have the CAA scope match the domain 
authorization scope. Without doing this you run into an inconsistency where 
the customer could obtain *.example.com but not secure.example.com. This 
doesn't make sense as we like to encourage customers to use non-wildcard names 
when possible.

Problems #2 and #3 are easily solved together. Permitting verification of a 
sub domain to override the higher level domains solves performance issues, 
still restricts the scope of what CAs can issue, and permits high speed/volume 
issuance off a base domain.

Thoughts?
Jeremy

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Monday, October 24, 2016 9:43 AM
To: Jeremy Rowley ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 24/10/16 16:40, Jeremy Rowley via Public wrote:
> Has there been an issuance to a third party that CAA would have prevented?
> Since there's no way to ensure compliance with a hard-fail CAA
> requirement, will CAA do anything useful? We don't mind CAA as a
> validation check, but I'm curious if anyone knows of an issued cert
> that would have been rejected if CAA were fully implemented.

https://github.com/letsencrypt/boulder/issues/1231 :-)

Gerv

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Gervase Markham via Public

On 24/10/16 16:40, Jeremy Rowley via Public wrote:
> Has there been an issuance to a third party that CAA would have prevented?
> Since there's no way to ensure compliance with a hard-fail CAA requirement,
> will CAA do anything useful? We don't mind CAA as a validation check, but
> I'm curious if anyone knows of an issued cert that would have been rejected
> if CAA were fully implemented.

https://github.com/letsencrypt/boulder/issues/1231 :-)

Gerv

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Gervase Markham via Public

On 24/10/16 16:39, Eric Mill wrote:
> Would this _only_ apply to CAs which also control DNS? I don't think
> that addresses the scenario that Eneli described, where a DNS provider
> or ISP is persuaded (or fooled) by an external CA into adding a CAA
> record on their system for their customers.

No, my drafting was intended to apply to all CAs.

Gerv

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Eric Mill via Public

On Mon, Oct 24, 2016 at 7:37 AM, Gervase Markham via Public <
public@cabforum.org> wrote:

> Hi Eneli,
>
> On 24/10/16 12:08, Eneli Kirme via Public wrote:
> > But consider this scenario: a hypothetical CoolCA approaching a DNS
> > service provider, be it an ISP, domain registrar or some kind of hosting
> > provider, with a proposal to include a CAA record pointing to the CoolCA
> > into their default configuration.
>
> I would expect the DNS service provider to refuse, because otherwise
> they'll have a lot of angry customers ringing them up, saying "my CA
> tells me I can't have a certificate, and it's your fault".
>
> However, to address this, would it be reasonable to add a clause in the
> CAA-related change which said something like: "CAs MUST NOT add (or
> cause or request to be added) CAA records to the DNS without the
> explicit permission of the domain owner."
>

Would this _only_ apply to CAs which also control DNS? I don't think that
addresses the scenario that Eneli described, where a DNS provider or ISP is
persuaded (or fooled) by an external CA into adding a CAA record on their
system for their customers.

-- Eric


>
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>



-- 
konklone.com | @konklone 
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Jeremy Rowley via Public

Has there been an issuance to a third party that CAA would have prevented?
Since there's no way to ensure compliance with a hard-fail CAA requirement,
will CAA do anything useful? We don't mind CAA as a validation check, but
I'm curious if anyone knows of an issued cert that would have been rejected
if CAA were fully implemented.

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Monday, October 24, 2016 5:38 AM
To: Eneli Kirme ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

Hi Eneli,

On 24/10/16 12:08, Eneli Kirme via Public wrote:
> But consider this scenario: a hypothetical CoolCA approaching a DNS 
> service provider, be it an ISP, domain registrar or some kind of 
> hosting provider, with a proposal to include a CAA record pointing to 
> the CoolCA into their default configuration.

I would expect the DNS service provider to refuse, because otherwise they'll
have a lot of angry customers ringing them up, saying "my CA tells me I
can't have a certificate, and it's your fault".

However, to address this, would it be reasonable to add a clause in the
CAA-related change which said something like: "CAs MUST NOT add (or cause or
request to be added) CAA records to the DNS without the explicit permission
of the domain owner."

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Gervase Markham via Public

On 24/10/16 14:58, Peter Bowen wrote:
> This could be very problematic for CAs that also do DNS hosting, as
> it could result in a situation where a user who has authorization to
> modify any DNS record in a zone could not modify CAA records because
> they are not the "domain owner”.

Then we need a better definition of "domain owner". The intent is clear
- CAs should not be editing the DNS, or asking ISPs etc. to edit the
DNS, to add themselves to CAA. The only person they should suggest this
to is the _customer_ - the certificate purchaser. If they are the DNS
host, they can have a checkbox on the control panel or some other
affirmative method of gaining consent, but they can't simply add a CAA
record for themselves without asking the domain owner.

If you can think of better wording, shoot :-)

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Peter Bowen via Public

> On Oct 24, 2016, at 4:37 AM, Gervase Markham via Public  
> wrote:
> However, to address this, would it be reasonable to add a clause in the
> CAA-related change which said something like: "CAs MUST NOT add (or
> cause or request to be added) CAA records to the DNS without the
> explicit permission of the domain owner."

This could be very problematic for CAs that also do DNS hosting, as it could 
result in a situation where a user who has authorization to modify any DNS 
record in a zone could not modify CAA records because they are not the "domain 
owner”.

While this sounds similar to the argument against CAA, the key difference is 
that this rule would change permissions without any action.  CAA leaves a 
default action as “allow”, while this would change a default action to “deny”.

Thanks,
Peter
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Gervase Markham via Public

Hi Eneli,

On 24/10/16 12:08, Eneli Kirme via Public wrote:
> But consider this scenario: a hypothetical CoolCA approaching a DNS
> service provider, be it an ISP, domain registrar or some kind of hosting
> provider, with a proposal to include a CAA record pointing to the CoolCA
> into their default configuration. 

I would expect the DNS service provider to refuse, because otherwise
they'll have a lot of angry customers ringing them up, saying "my CA
tells me I can't have a certificate, and it's your fault".

However, to address this, would it be reasonable to add a clause in the
CAA-related change which said something like: "CAs MUST NOT add (or
cause or request to be added) CAA records to the DNS without the
explicit permission of the domain owner."

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-24 Thread Eneli Kirme via Public

Hi all,

Although we appreciate your concerns on protecting users from incapable CA-s, 
we’d like to point out that we as a small CA, fear a side-effect of it being an 
instrument for market manipulation.

Most of the concerns brought up here so far have been about corporations where 
there’s different admins for DNS, certificates, web content and whether this 
would create any trouble to them or risk to users.

But consider this scenario: a hypothetical CoolCA approaching a DNS service 
provider, be it an ISP, domain registrar or some kind of hosting provider, with 
a proposal to include a CAA record pointing to the CoolCA into their default 
configuration. Falling to it means that lots of small customers, who just want 
to set up a homepage or e-mail and who might not (yet) know anything about 
certificates, all of a sudden get a preferred choice of a CA. This cannot be 
considered an incorrect configuration, but nevertheless our first step with 
potential customers in a hard-fail scenario would then be to ask them to go to 
the DNS provider and request changing the CAA from our competitor to us and 
only then come back. This is definitely extra hassle to her, it might also be 
extra cost to her and it is us promoting our competitor.


Best regards,

Eneli Kirme
AS Sertifitseerimiskeskus (SK)


On 19 Oct 2016, at 00:49, Ryan Sleevi via Public 
mailto:public@cabforum.org>> wrote:



On Tue, Oct 18, 2016 at 12:01 PM, Jacob Hoffman-Andrews via Public 
mailto:public@cabforum.org>> wrote:
On Sat, Sep 10, 2016 at 10:42 PM, Eric Mill 
mailto:eric.m...@gsa.gov>> wrote:
CAA could be a straightforward way for enterprises to set an actual security 
policy that can be technically enforced, without the same level of risk or 
technical sophistication required by HPKP.

To clarify a bit on this point: I think CAA doesn't work well as a way to 
enforce top-down enterprise policy in the presence of delegated subdomains, 
because CAA records are checked starting from the leftmost label, and only the 
first record found is considered: https://tools.ietf.org/html/rfc6844#section-4.

For instance, say you have a CAA record on example.com 
forbidding all issuance, and have a CNAME from 
blog.example.com to a hosting provider. That hosting 
provider can answer CAA queries for blog.example.com 
with a response that permits issuance.

CAA has a lot of value, but I think this is not one of the things it is useful 
for.

I agree it's not useful for the specific case you highlighted, but I don't 
think it's correct to paint all of the situations Eric raised as fitting that 
mold. So CAA absolutely is useful for that case - but if and only if you 
structure it in a way you can express CAA. But some (many?) enterprises can do 
that, and it is valuable for the level Eric highlights.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-18 Thread Ryan Sleevi via Public

On Tue, Oct 18, 2016 at 12:01 PM, Jacob Hoffman-Andrews via Public <
public@cabforum.org> wrote:

> On Sat, Sep 10, 2016 at 10:42 PM, Eric Mill  wrote:
>>
>> CAA could be a straightforward way for enterprises to set an actual
>> security policy that can be technically enforced, without the same level of
>> risk or technical sophistication required by HPKP.
>>
>
> To clarify a bit on this point: I think CAA doesn't work well as a way to
> enforce top-down enterprise policy in the presence of delegated subdomains,
> because CAA records are checked starting from the leftmost label, and only
> the first record found is considered: https://tools.ietf.org/html/
> rfc6844#section-4.
>
> For instance, say you have a CAA record on example.com forbidding all
> issuance, and have a CNAME from blog.example.com to a hosting provider.
> That hosting provider can answer CAA queries for blog.example.com with a
> response that permits issuance.
>

> CAA has a lot of value, but I think this is not one of the things it is
> useful for.
>

I agree it's not useful for the specific case you highlighted, but I don't
think it's correct to paint all of the situations Eric raised as fitting
that mold. So CAA absolutely is useful for that case - but if and only if
you structure it in a way you can express CAA. But some (many?) enterprises
can do that, and it is valuable for the level Eric highlights.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-18 Thread Jacob Hoffman-Andrews via Public

On Tue, Oct 18, 2016 at 1:44 PM, Gervase Markham  wrote:

> > our investigations we've found that 0.1% of domains with a current Let's
> > Encrypt certificate return SERVFAIL for CAA.
>
> Does that tend to be a permanent or a temporary condition?
>

In this particular investigation, I ran a script that first attempted to
resolve A records for a hostname three times over the space of a couple of
days. For any hostname that had at least one successful response for an A
record, I then attempted CAA lookups three times over the space of a couple
of days, including lookups for parent domains. Any hostname that failed all
CAA lookups went in the "failed" bucket. So, on a timescale of days, they
are mostly permanent failures.

We've found one specific case of a Kemp load balancer that returns SERVFAIL
to all query types other than A. We'll be working with the vendor to see if
they can fix that in future releases.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-18 Thread Gervase Markham via Public

On 18/10/16 11:26, Jacob Hoffman-Andrews wrote:
> DNS fail open or closed: Let's Encrypt currently treats a SERVFAIL when
> looking up CAA as "no CAA record present, okay to issue." However, we
> are working to change this, so a CAA SERVFAIL will prevent issuance. In
> our investigations we've found that 0.1% of domains with a current Let's
> Encrypt certificate return SERVFAIL for CAA.

Does that tend to be a permanent or a temporary condition?

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-18 Thread Jacob Hoffman-Andrews via Public

On Sat, Sep 10, 2016 at 10:42 PM, Eric Mill  wrote:
>
> CAA could be a straightforward way for enterprises to set an actual
> security policy that can be technically enforced, without the same level of
> risk or technical sophistication required by HPKP.
>

To clarify a bit on this point: I think CAA doesn't work well as a way to
enforce top-down enterprise policy in the presence of delegated subdomains,
because CAA records are checked starting from the leftmost label, and only
the first record found is considered:
https://tools.ietf.org/html/rfc6844#section-4.

For instance, say you have a CAA record on example.com forbidding all
issuance, and have a CNAME from blog.example.com to a hosting provider.
That hosting provider can answer CAA queries for blog.example.com with a
response that permits issuance.

CAA has a lot of value, but I think this is not one of the things it is
useful for.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-18 Thread Jacob Hoffman-Andrews via Public

On Mon, Oct 17, 2016 at 11:11 AM, Rick Andrews via Public <
public@cabforum.org> wrote:

> Posting to public list (seems to have been dropped)
>
> I'll need to poll folks internally, but Symantec would probably support
> this.
> How do other CAs feel?
>
> -Rick
>
> -Original Message-
> From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
> Sent: Monday, October 17, 2016 7:41 AM
> To: Gervase Markham ; Bruce Morton
> ; Ryan Sleevi ; Rick Andrews
> 
> Subject: RE: [cabfpub] Continuing the discussion on CAA
>
> I'd support a position if CAA was a validation check rather than an
> issuance
> check. That way there isn't a difference between "enterprise" and "retail".
> Instead, it's tied to the domain validation process and is required
> whenever
> domain validation is required.
>

Let's Encrypt checks CAA at validation time rather than issuance time,
because DNS checks are slow and unreliable. Doing the check at validation
time allowed us to consolidate the external-facing parts of our process
into a single component, and monitor the performance of that component with
the knowledge that it is affected by factors outside our control.

So, we also have a preference for checking CAA at validation time.

Regarding Gervase's comment about where in the process to do a high-risk
domain check: Let's Encrypt does a high-risk domain check against a static
list both at validation time and at issuance time, because it is very cheap
to do.

Hard vs soft CAA enforcement: Let's Encrypt doesn't allow human override
when we find a CAA record that forbids issuance. The number of support
requests we get due to incorrect CAA records is vanishingly small, though I
acknowledge that providers with a different customer mix might get
different results.

DNS fail open or closed: Let's Encrypt currently treats a SERVFAIL when
looking up CAA as "no CAA record present, okay to issue." However, we are
working to change this, so a CAA SERVFAIL will prevent issuance. In our
investigations we've found that 0.1% of domains with a current Let's
Encrypt certificate return SERVFAIL for CAA.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-18 Thread Kirk Hall via Public

I agree that CAA is much more comprehensive, and would achieve what you 
describe.  Just wanted to point out that there are already many safeguards in 
place for many / most CAs to prevent accidental issuance of very high value 
domains that would likely come before a CAA check, so we are not defenseless 
today.  But you are right, this hard-wired stop list would not reach or protect 
all companies who put a CAA limit in their DNS record.  I doubt that many of 
these domains are targets of fraudsters compared to the highest level targets.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Tuesday, October 18, 2016 1:36 AM
To: Kirk Hall ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

Hi Kirk,

On 17/10/16 18:07, Kirk Hall via Public wrote:
> Gerv, one other point to consider is that many CAs already have hard 
> stops that can't be easily overridden for the highest value names you 
> listed ("Google or Yahoo or Microsoft" - or Mozilla), so a hard stop 
> with CAA would never even be reached via automated requests for those 
> domains.

Indeed, I am aware of this. However, one problem with such a system is that the 
domains chosen may well be culturally-conditioned and perhaps not updated often 
- what are the key popular websites in Indonesia? Or Brazil? Or Turkey? And are 
they the same ones that were important last year?

Still, it's very relevant that you point out this fact, because the point in a 
CA's issuance process where this happens is exactly the point where I would 
tell them to insert the CAA check.

In other words, instead of having a static list of high value names assembled 
by the CA (which no-one seems to have a problem with, and all would say is best 
practice), I am saying we should have a dynamic list of high value names 
assembled by the domain owners, with membership of that list indicated by 
setting a CAA record. And the effect on the CA's issuance process should be the 
same "hard stop that can't be easily overridden" that you mention is now the 
case for Google, Yahoo and Microsoft.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-18 Thread Gervase Markham via Public

Hi Kirk,

On 17/10/16 18:07, Kirk Hall via Public wrote:
> Gerv, one other point to consider is that many CAs already have hard
> stops that can't be easily overridden for the highest value names you
> listed ("Google or Yahoo or Microsoft" - or Mozilla), so a hard stop
> with CAA would never even be reached via automated requests for those
> domains. 

Indeed, I am aware of this. However, one problem with such a system is
that the domains chosen may well be culturally-conditioned and perhaps
not updated often - what are the key popular websites in Indonesia? Or
Brazil? Or Turkey? And are they the same ones that were important last
year?

Still, it's very relevant that you point out this fact, because the
point in a CA's issuance process where this happens is exactly the point
where I would tell them to insert the CAA check.

In other words, instead of having a static list of high value names
assembled by the CA (which no-one seems to have a problem with, and all
would say is best practice), I am saying we should have a dynamic list
of high value names assembled by the domain owners, with membership of
that list indicated by setting a CAA record. And the effect on the CA's
issuance process should be the same "hard stop that can't be easily
overridden" that you mention is now the case for Google, Yahoo and
Microsoft.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-17 Thread Kirk Hall via Public

Gerv, one other point to consider is that many CAs already have hard stops that 
can't be easily overridden for the highest value names you listed ("Google or 
Yahoo or Microsoft" - or Mozilla), so a hard stop with CAA would never even be 
reached via automated requests for those domains.  So many CA systems would not 
benefit all that much with CAA for those types of high value domains - they are 
already thrown into extra manual scrutiny.

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, October 17, 2016 5:21 AM
To: Eric Mill 
Cc: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 15/10/16 22:49, Eric Mill wrote:
> a clear threat model. It seems to me that CAA is valuable if it 
> provides meaningful technical controls that restrict issuance from the 
> vast majority of CAs with whom an organization will have no business 
> relationship.

If for "vast majority", you read "all", then I agree. But my point is, "what is 
a technical control"? Something a human can override by checking a checkbox is 
not a technical control, it's a policy control (CA policy, not domain owner 
policy).

We have had various instances in the past (Comodogate, DigiNotar) where hackers 
have gained control of the ability to issue certificates with varying 
parameters, but have not gained the ability to override the logic built into 
the CA's issuance code. And it is in precisely situations such as this that the 
Web PKI is at greatest risk, because the attacker can (and did) issue 
certificates at will for major sites. I know of no other way to implement a 
technical control preventing this (assuming the CA doesn't simply want to 
hard-code a list of important domains they will never issue for, which might be 
the right thing for e.g. government CAs or academic CAs) except for a 
non-overrideable CAA check.

If I were a CA, not only would I have such a check, but I'd tie it to a DEFCON 
1 alert alarm if triggered. Because the first thing any cocky attacker is going 
to try once they've broken in is issuing a cert for Google or Yahoo or 
Microsoft.

Having said that, Bruce makes some reasonable points about enterprise customers 
issuing from e.g. name-constrained sub-CAs. I need to study his message more 
carefully. So we should talk more this week about where we can draw some clear 
lines that provide this protection while exempting situations where the damage 
of misissuance is limited.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-17 Thread Rick Andrews via Public

Posting to public list (seems to have been dropped)

I'll need to poll folks internally, but Symantec would probably support this. 
How do other CAs feel?

-Rick

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
Sent: Monday, October 17, 2016 7:41 AM
To: Gervase Markham ; Bruce Morton 
; Ryan Sleevi ; Rick Andrews 

Subject: RE: [cabfpub] Continuing the discussion on CAA

I'd support a position if CAA was a validation check rather than an issuance
check. That way there isn't a difference between "enterprise" and "retail".
Instead, it's tied to the domain validation process and is required whenever
domain validation is required.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Monday, October 17, 2016 6:36 AM
To: Bruce Morton ; Jeremy Rowley
; Ryan Sleevi ; Rick Andrews

Subject: Re: [cabfpub] Continuing the discussion on CAA

On 14/10/16 20:45, Bruce Morton wrote:
> For retail, perform hard fail CAA record check for all new requests
> and renewals. Do not perform CAA record check for a reissue.

ISTR that previously there has been some controversy about whether "reissue"
is a separate class of thing to a renewal (with some CAs doing "reissues" with
forbidden in-cert constructs that would not be allowed for new issuances or
renewals).

Can you quickly define the difference for us, in words? And how would you
programmatically distinguish between reissues and renewals?

> For enterprise, perform hard fail CAA record check when the domain is
> being pre-validated. Also perform hard fail CAA record check when the
> domain is re-verified in the 13 or 39 month cycle. Do not perform CAA
> record check when an Enterprise RA logs in to approve certificate issuance.

Does such an Enterprise RA issuance come from a name-constrained intermediate,
or not always?

If there are cases where it does not, presumably the CA (but not the RA) has
control over the list of domains for which issuance is permitted.
How is such a list maintained and changed?

> Also, could we create a variable which could be included in the CAA
> record for strict CAA compliance. This variable would be in the CPS
> for all CAs and if used would make the CAA record the superior
> statement for CA authorization. The CA would still follow the checking
> cycle above, so would not impact a currently approved CA without
> re-verification or subscriber agreement cancellation.

The CAA RFC mandates it as a hard-fail thing. Making it default to some form
of softer fail and doing hard fail only with an extra token present would be
semantically very confusing. I would be less concerned with a "soft fail"
token, with hard fail being the default, but I suspect that would not address
the issues you raise.

Gerv

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-17 Thread Gervase Markham via Public

On 15/10/16 22:49, Eric Mill wrote:
> a clear threat model. It seems to me that CAA is valuable if it provides
> meaningful technical controls that restrict issuance from the vast
> majority of CAs with whom an organization will have no business
> relationship.

If for "vast majority", you read "all", then I agree. But my point is,
"what is a technical control"? Something a human can override by
checking a checkbox is not a technical control, it's a policy control
(CA policy, not domain owner policy).

We have had various instances in the past (Comodogate, DigiNotar) where
hackers have gained control of the ability to issue certificates with
varying parameters, but have not gained the ability to override the
logic built into the CA's issuance code. And it is in precisely
situations such as this that the Web PKI is at greatest risk, because
the attacker can (and did) issue certificates at will for major sites. I
know of no other way to implement a technical control preventing this
(assuming the CA doesn't simply want to hard-code a list of important
domains they will never issue for, which might be the right thing for
e.g. government CAs or academic CAs) except for a non-overrideable CAA
check.

If I were a CA, not only would I have such a check, but I'd tie it to a
DEFCON 1 alert alarm if triggered. Because the first thing any cocky
attacker is going to try once they've broken in is issuing a cert for
Google or Yahoo or Microsoft.

Having said that, Bruce makes some reasonable points about enterprise
customers issuing from e.g. name-constrained sub-CAs. I need to study
his message more carefully. So we should talk more this week about where
we can draw some clear lines that provide this protection while
exempting situations where the damage of misissuance is limited.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-15 Thread Eric Mill via Public

On Fri, Oct 14, 2016 at 1:49 PM, Gervase Markham via Public <
public@cabforum.org> wrote:

> On 14/10/16 18:32, Bruce Morton via Public wrote:
> > I think that the CA can limit risk by checking CAA records where there
> > has been no verified Enterprise RA or a Certificate Approver
> > established. In this condition, I think that the CAA record check should
> > be a hard fail.
>
> How would you code that, in practice? What would the UX look like for
> the validation specialist?
>
> Any version of this where CAA is not a hard-coded non-overrideable hard
> fail deprives CAs of the misissuance protection they could get when it
> is. Imagine if, even if an attacker got control of your entire infra he
> still couldn't issue for google.com, yahoo.com or other high profile
> sites because of CAA.

You could also say that any CA where domain control checks are not
"hard-coded non-overrideable hard fail" miss out on misissuance protection,
or really about any other technical checks on misissuance.

I don't think providing resistance to full compromise of a CA is what CAA
addresses. CAA is self-enforced, so it can address the threat of
misissuance caused by weaknesses in other *parts* of the CA's
infrastructure (like issuance protocols). SCT enforcement/auditing and HPKP
can provide some protection against *full* CA compromise, because they are
ultimately enforced by devices outside the CA's infrastructure.

In my experience, Bruce's description of organizations where the DNS team
isn't in effective coordination with the people requesting certs is
unfortunately common. How much weight that should have regarding CAA policy
is worth debating, but a debate on CAA should be oriented around a clear
threat model. It seems to me that CAA is valuable if it provides meaningful
technical controls that restrict issuance from the vast majority of CAs
with whom an organization will have no business relationship.

-- Eric

> That would make the consequences of the compromise
> significantly less bad for the internet, and therefore less bad for the
> CA. Protection against malicious misissuance (as opposed to an employee
> violating policy, say) is not the only benefit of CAA, but I think it's
> a useful one.
>
> Making mistakes with an organization's DNS can lead to all sorts of
> types of outage or disruption. Why is the disruption caused by a
> mistaken CAA record (which seems a fairly unlikely scenario to me, but
> let's run with it) so much worse that it needs specially protecting
> against?
>
> If an organization allows random employees to make unreviewed changes to
> its DNS, surely it has bigger problems than not being able to get certs?
>
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>

-- 
Eric Mill
Senior Advisor on Technology
Technology Transformation Service, GSA
eric.m...@gsa.gov, +1-617-314-0966
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-14 Thread Gervase Markham via Public

On 14/10/16 18:32, Bruce Morton via Public wrote:
> I think that the CA can limit risk by checking CAA records where there
> has been no verified Enterprise RA or a Certificate Approver
> established. In this condition, I think that the CAA record check should
> be a hard fail.

How would you code that, in practice? What would the UX look like for
the validation specialist?

Any version of this where CAA is not a hard-coded non-overrideable hard
fail deprives CAs of the misissuance protection they could get when it
is. Imagine if, even if an attacker got control of your entire infra he
still couldn't issue for google.com, yahoo.com or other high profile
sites because of CAA. That would make the consequences of the compromise
significantly less bad for the internet, and therefore less bad for the
CA. Protection against malicious misissuance (as opposed to an employee
violating policy, say) is not the only benefit of CAA, but I think it's
a useful one.

Making mistakes with an organization's DNS can lead to all sorts of
types of outage or disruption. Why is the disruption caused by a
mistaken CAA record (which seems a fairly unlikely scenario to me, but
let's run with it) so much worse that it needs specially protecting against?

If an organization allows random employees to make unreviewed changes to
its DNS, surely it has bigger problems than not being able to get certs?

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-10-14 Thread Bruce Morton via Public

I agree with Ryan that the hard fail per item number 3 is the sticking point. 
My concern is that in many organizations, the certificate requesters are not 
the DNS administrators and there could be some disconnect.

I think that Peter asked the question, “how does the CA currently know that 
they are allowed to issue certificates for a specific domain?”

I think we did a good job with the BR and EV documents. We have defined 
certificate approvers with the Enterprise RA and the Certificate Approver. We 
have also defined access controls and limits on certificate requesters.

So my answer is that we know we are allowed to issue certificates for a 
specific domain as we have a subscriber agreement which allows us to honor the 
requests of verified Enterprise RAs and Certificate Approvers.

Per the BRs, an Enterprise RA is defined and has the following privileges:

·BR 1.6.1 – Definition: An employee or agent of an organization 
unaffiliated with the CA who authorizes issuance of Certificates to that 
organization.

·BR 1.3.2 - The CA MAY designate an Enterprise RA to verify certificate 
requests from the Enterprise RA’s own organization.

·Note that if the Enterprise RA has the ability to issue a certificate 
then they must meet the multi-factor requirement of BR 6.5.1, “The CA SHALL 
enforce multi‐factor authentication for all accounts capable of directly 
causing certificate issuance.”

·Also note that per BR 3.2.5, “the CA SHALL establish a process that 
allows an Applicant to specify the individuals who may request Certificates.” 
This generally limits requests which have not been approved by an Enterprise RA 
or a Certificate Approver.

For EV certificates, there is a Certificate Approver:

·EV 4 – Definition: A natural person who is either the Applicant, 
employed by the Applicant, or an authorized agent who has express authority to 
represent the Applicant to (i) act as a Certificate Requester and to authorize 
other employees or third parties to act as a Certificate Requester, and (ii) to 
approve EV Certificate Requests submitted by other Certificate Requesters.

·Note if the Subscriber had established the BR 3.2.5 restriction, then 
a new Certificate Approver would not be verified unless they could be added to 
the approved list.

In both cases the roles have the privilege to verify/approve certificate 
requests. As such, I do not think that we need a hard fail on CAA if the 
request has been approved by an Enterprise RA or a Certificate Approver.

I think that the CA can limit risk by checking CAA records where there has been 
no verified Enterprise RA or a Certificate Approver established. In this 
condition, I think that the CAA record check should be a hard fail.

Bruce.

From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On 
Behalf Of Ryan Sleevi
Sent: Thursday, September 8, 2016 6:35 PM
To: Rick Andrews 
Cc: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA



On Thu, Sep 8, 2016 at 2:40 PM, Rick Andrews 
mailto:rick_andr...@symantec.com>> wrote:
Additionally, I'd like to address this point: 'Ryan pointed out that, at
present, nothing would prevent Neil from stating in his CP/CPS that his CA
will issue certificates if he sees a CAA record for 
"symantec.com<http://symantec.com>" '. If
Neil adopted that policy, wouldn't it violate RFC 6844, which says "The
issue property entry authorizes the holder of the domain name  or a party acting under the explicit authority of the holder of that
domain name to issue certificates for the domain in which the property is
published."?

Rick,

As you know, the IETF historically shies away from discussions of policy, and 
instead focuses on the technological side. We can see that certainly with PKIX 
(RFC 5280 & friends), and it was actually a frequently reiterated point during 
the discussion of CAA through its standardization.

As such, we should imagine that CAA defines the structural representation, but 
it's up to the CA/B Forum to specify the policy that applies here. You can see 
that the document intentionally shies away from this discussion in Sections 6.1 
and 6.2, and that's arguably the right thing.

The extent of my comments was to make sure that, in developing a policy for CAA 
(which I'm strongly supportive of, so appreciate you continuing the 
discussion), we make it clear what is and is not acceptable. If we were to 
accept that Neil doing so would violate RFC 6844, then we must also accept that 
the only RFC 6844-compliant method of a CA running into the situation you 
propose is to Not Issue At All. That is, not even Option 1 is acceptable (since 
you included the parenthetical escape clause).

My "ideal" outcome for CAA within the CA/B Forum would be:
1) A requirement in the CPS to state that the CA respects CAA
2) A requirement that the CPS documents which domains

Re: [cabfpub] Continuing the discussion on CAA

2016-09-13 Thread Gervase Markham

On 13/09/16 14:51, Bruce Morton wrote:
> The expectation for an enterprise account is that the information is all
> pre-validated. This allows the subscriber to issue OV and EV
> certificates 24/7/365. Performing a CAA check at time of issuance would
> mean that the data is not all pre-validated. A failed CAA check could
> stop a certificate from being issued.

Could we permit this to be contracted around? In other words, allow a CA
to contract with an enterprise that the enterprise will notify them by a
means other than CAA if they wish to stop using their services, and in
return the CA is allowed not to check CAA at time of issuance.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-13 Thread Bruce Morton

I think the issue is the failure scenario.

The expectation for an enterprise account is that the information is all 
pre-validated. This allows the subscriber to issue OV and EV certificates 
24/7/365. Performing a CAA check at time of issuance would mean that the data 
is not all pre-validated. A failed CAA check could stop a certificate from 
being issued.

From the EV point of view, there would appear to be limited value in performing 
EV validation (confirming authorization of the Certificate Approver), providing 
a subscriber with 2-factor login to issue a certificate, then fail due to CAA.

Bruce.

From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On 
Behalf Of phill...@comodo.com
Sent: Tuesday, September 13, 2016 9:28 AM
To: Doug Beattie 
Cc: Rick Andrews ; public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

As the CAA author, the reason the spec doesn’t talk about ‘validation’ is that 
the distinction between validation and issue is something that is a policy 
issue and the IETF does not do policy.

That said, why wouldn’t you want to do a check on each issue? Its only a DNS 
lookup.


On Sep 13, 2016, at 8:29 AM, Doug Beattie 
mailto:doug.beat...@globalsign.com>> wrote:

If we adopt CAA as a requirement, when in the process will the CAA check be 
mandated?
-  When the certificate request is received (part of request validation 
similar to high risk checks)
-  When the certificate request is approved (at time of issuance) – 
which could be minutes, hours or days after the request was received
-  When the “Certificate Data” is collected and domain validation is 
performed

I believe the CAA spec says at time of issuance, but I’m hoping that for the 
BRs we can move the CAA check up in the issuance process to the point in time 
the Certificate Data is validated.  For enterprise type accounts we shouldn’t 
need to validate CAA for every issuance if CAA was validated as part of Domain 
Validation for that enterprise.

Doug


From: public-boun...@cabforum.org<mailto:public-boun...@cabforum.org> 
[mailto:public-boun...@cabforum.org] On Behalf Of Rick Andrews
Sent: Monday, September 12, 2016 6:56 PM
To: Eric Mill
Cc: public@cabforum.org<mailto:public@cabforum.org>
Subject: Re: [cabfpub] Continuing the discussion on CAA

Eric, the discussions around CAA have often included less-than-strict 
enforcement because some CAs were opposed to CAA deployment. Some thought that 
it might be easier to achieve broad adoption by mandating a lax minimum and 
then ratcheting it up over time.

-Rick




___
Public mailing list
Public@cabforum.org<mailto:Public@cabforum.org>
https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-13 Thread phill...@comodo.com

As the CAA author, the reason the spec doesn’t talk about ‘validation’ is that 
the distinction between validation and issue is something that is a policy 
issue and the IETF does not do policy.

That said, why wouldn’t you want to do a check on each issue? Its only a DNS 
lookup.


> On Sep 13, 2016, at 8:29 AM, Doug Beattie  wrote:
> 
> If we adopt CAA as a requirement, when in the process will the CAA check be 
> mandated?
> -  When the certificate request is received (part of request 
> validation similar to high risk checks)
> -  When the certificate request is approved (at time of issuance) – 
> which could be minutes, hours or days after the request was received
> -  When the “Certificate Data” is collected and domain validation is 
> performed
>  
> I believe the CAA spec says at time of issuance, but I’m hoping that for the 
> BRs we can move the CAA check up in the issuance process to the point in time 
> the Certificate Data is validated.  For enterprise type accounts we shouldn’t 
> need to validate CAA for every issuance if CAA was validated as part of 
> Domain Validation for that enterprise.
>  
> Doug
>  
>   <>
> From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On 
> Behalf Of Rick Andrews
> Sent: Monday, September 12, 2016 6:56 PM
> To: Eric Mill
> Cc: public@cabforum.org
> Subject: Re: [cabfpub] Continuing the discussion on CAA
>  
> Eric, the discussions around CAA have often included less-than-strict 
> enforcement because some CAs were opposed to CAA deployment. Some thought 
> that it might be easier to achieve broad adoption by mandating a lax minimum 
> and then ratcheting it up over time. 
> 
> -Rick
> 
> 
> 
>  
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-13 Thread Doug Beattie

If we adopt CAA as a requirement, when in the process will the CAA check be 
mandated?

-  When the certificate request is received (part of request validation 
similar to high risk checks)

-  When the certificate request is approved (at time of issuance) - 
which could be minutes, hours or days after the request was received

-  When the "Certificate Data" is collected and domain validation is 
performed

I believe the CAA spec says at time of issuance, but I'm hoping that for the 
BRs we can move the CAA check up in the issuance process to the point in time 
the Certificate Data is validated.  For enterprise type accounts we shouldn't 
need to validate CAA for every issuance if CAA was validated as part of Domain 
Validation for that enterprise.

Doug


From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On 
Behalf Of Rick Andrews
Sent: Monday, September 12, 2016 6:56 PM
To: Eric Mill
Cc: public@cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

Eric, the discussions around CAA have often included less-than-strict 
enforcement because some CAs were opposed to CAA deployment. Some thought that 
it might be easier to achieve broad adoption by mandating a lax minimum and 
then ratcheting it up over time.

-Rick



___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-12 Thread Rick Andrews

Eric, the discussions around CAA have often included less-than-strict 
enforcement because some CAs were opposed to CAA deployment. Some thought that 
it might be easier to achieve broad adoption by mandating a lax minimum and 
then ratcheting it up over time.

-Rick

On Sep 10, 2016, at 10:50 PM, Eric Mill 
mailto:eric.m...@gsa.gov>> wrote:

* Any failures occur at issuance-time, not request-time. While an issuance 
failure might lead to request failures when replacing expired or 
imminently-expiring certificates, many (most?) issuance failures will give 
service operators time to respond before request failures, including adjusting 
DNS records as necessary.

To clarify this paragraph, by "request" I meant "HTTP request", not 
"certificate request".

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-10 Thread Eric Mill

>
> * Any failures occur at issuance-time, not request-time. While an issuance
> failure might lead to request failures when replacing expired or
> imminently-expiring certificates, many (most?) issuance failures will give
> service operators time to respond before request failures, including
> adjusting DNS records as necessary.
>

To clarify this paragraph, by "request" I meant "HTTP request", not
"certificate request".
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-10 Thread Eric Mill

*(Just noting for my first email from this address - when I email from
eric.m...@gsa.gov , I'm participating as an Interested
Party in my capacity as a GSA employee.)*

I wasn't present at Bilbao and so I don't know the full context from there,
but my perspective is that for CAA to be at all relevant to enterprise
security decisions, it has to be strictly enforceable to the greatest
technical extent possible.

In the context of this thread, that is to Not Issue At All if the CA sees a
CAA record that does not permit the CA to issue for the domain, with the
only solution being that the domain owner updates the CAA record to include
the CA.

Given that DNS is unreliable, allowing it to "fail open" seems permissible,
mitigated by CAs being required to keep clear audit logs like the kind Ryan
described in (4). DNS unreliability is already a fact of life in validating
domain ownership, so this seems inevitable, and hopefully CAs that perform
DNS-based domain validation already keep audit logs to that level of detail
anyway. Mechanisms to mitigate DNS unreliability (such as performing DNS
validation from multiple vantage points) are already useful for domain
validation.

The enterprises I tend to work with are federal agencies, who often wish to
employ only a subset of CAs in their enterprise environment, with the
intent of limiting their exposure to CA failure in the broader web PKI. The
general approach they take is to have human policies restricting what CAs
their employees are allowed to use. This alone adds no security value and
doesn't reduce any exposure to CA failure whatsoever, but as far as I have
seen it is consistently employed alone, making it security theater.

CAA could be a straightforward way for enterprises to set an actual
security policy that can be technically enforced, without the same level of
risk or technical sophistication required by HPKP. However, each of the
proposed ways of loosening CAA enforcement ("High Risk" treatment, EV
treatment, contacting a human from whois, and maybe just issuing anyway)
moves CAA out of the realm of technical enforcement and into the realm of
CA discretion. In my opinion, this would put CAA at major risk of being
security theater.

In general, relying on technical enforcement is always much preferable to
CA discretion, but it's particularly necessary for CAA. A major part of the
rationale for CAA (and HPKP) is to allow domain owners to avoid exposure to
failures in weaker CAs in the web PKI. A CAA enforcement policy that relied
on CA discretion would mean that CAA is effectively as strong as the
weakest CAs, undermining one of CAA's main benefits.

On Fri, Sep 9, 2016 at 9:41 AM, Gervase Markham  wrote:

>
> I suggest this because I think it might be a good way to meet Google's
> needs for absolute bans, without making CAA, like HPKP, a technology
> that only large sites will deploy because of the near-"bricking" potential.
>

While I get what you are saying, there are some very significant
differences in potential severity between hard-bricking a site through HPKP
vs hard-denying issuance through CAA. Two major ones:

* Any failures occur at issuance-time, not request-time. While an issuance
failure might lead to request failures when replacing expired or
imminently-expiring certificates, many (most?) issuance failures will give
service operators time to respond before request failures, including
adjusting DNS records as necessary.

* HPKP policies are cached in clients for a potentially significant number
of days, making some kinds of hard-failures impossible (by design) to fix
in a rapid timeframe. CAA policies can be changed centrally, server-side,
and issuance attempts repeated immediately afterwards, ensuring that a
rapid fix is always theoretically possible and often quite practical.

So even though a hard-fail CAA might intimidate some classes of domain
owners from using it, I don't think CAA and HPKP are similar enough to
suggest that current deployment of HPKP could be used to project the impact
of a hard-fail CAA.

And even if it does intimidate some class of domain owners, it seems better
to provide direct security guarantees for the domain owners who choose to
use it, than for a looser policy to put a low ceiling on the security it
could possibly provide any domain owner.

> I agree with Ryan that, even if the process is loose, we need proper
> audit trails to make sure the CA does the checks and follows the
> exception process properly.
>

Just for clarity's sake, I read Ryan's proposed requirement around audit
trails to be part of a "strict" process, not a looser one -- and that the
unreliability of DNS and the necessity of failing open makes a specific
audit trail especially necessary even for a strict policy.

Eric Mill

Senior Advisor on Technology
Technology Transformation Service 
U.S. General Services Administration
eric.m...@gsa.gov
___
Public mailing list
Public@c

Re: [cabfpub] Continuing the discussion on CAA

2016-09-09 Thread Phillip Hallam-Baker

I concur with a few quibbles.

Given the use of DNS for domain validation, an attacker who can successfully 
spoof DNS can apply for a cert from the authorized CA. The ability to get a 
bogus cert from the CA of their choice does increase the attack surface but not 
by a huge amount.

DNSSEC may improve things or it may not. If DNSSEC is in place then it can be 
used to lock down DV as well as CAA. But that doth not necessarily make the 
system secure. The security of DNSSEC depends on the security of DNS registrars 
and it is not clear that these people understand the issues. 

[Right now, my private Web sites are all off line because the hosting provider 
has made an unauthorized change to the config and done so incompetently.]


I have maintained from the start that CAs can choose to implement strict CAA 
checking now or wait until it becomes a requirement. Unless of course you 
happen to be the CA that is the cause of CAA becoming a mandatory requirement 
in which case you might not have any need to implement anything ever at all.


> On Sep 9, 2016, at 3:41 PM, Gervase Markham  wrote:
> 
> Everything Ryan says seems to make sense to me, except I have a further
> comment here:
> 
> On 08/09/16 23:34, Ryan Sleevi wrote:
>> #3 is clearly a sticking point. I think we're all pretty aware of CAs'
>> objections to this, but I do feel strongly that, without this, CAA is
>> not an effective security mitigation. As you know, Google holds a
>> variety of domains, and we routinely receive requests from other CAs
>> attempting to confirm that an applicant was duly authorized to make a
>> request, and we routinely have to contact CAs and request revocation for
>> certificates that were not authorized according to our company policy.
>> Allowing escape clauses, even at the EVGL level, significantly weaken
>> our ability to proactively prevent this, which we believe would reduce
>> both ours and CAs' administrative burdens.
> 
> This seems to be sort of a question of whether CAA is actually like HPKP
> ("deny access, come what may, if things get configured wrong") or more
> like an expired cert is currently treated in browsers ("allow an
> override with a warning/extra care").
> 
> As I see it, we have three options:
> 
> 1) Strict is the only way to go - Ryan's preference.
> 2) Loose(r) is the only way to go - let's pick one of Rick's 4 options.
> 3) Allow domain owner to decide, with loose(r) as default.
> 
> There may be better extension mechanisms than this in CAA, but 3) could
> be achieved by adding a CAB Forum-defined domain ("strict.cabforum.org")
> to the CAA record. If a CA sees this, they may not under any
> circumstances issue the certificate until they see the CAA record
> change, and to do so is a misissuance. If they don't see it, we use the
> High Risk process, or some EV process, or whichever of Rick's options we
> decide. I don't think this is much extra complexity - if we are going to
> require CAA checking, we can require CAA checking and
> strict.cabforum.org recognition too.
> 
> I suggest this because I think it might be a good way to meet Google's
> needs for absolute bans, without making CAA, like HPKP, a technology
> that only large sites will deploy because of the near-"bricking" potential.
> 
> I agree with Ryan that, even if the process is loose, we need proper
> audit trails to make sure the CA does the checks and follows the
> exception process properly.
> 
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-09 Thread Gervase Markham

Everything Ryan says seems to make sense to me, except I have a further
comment here:

On 08/09/16 23:34, Ryan Sleevi wrote:
> #3 is clearly a sticking point. I think we're all pretty aware of CAs'
> objections to this, but I do feel strongly that, without this, CAA is
> not an effective security mitigation. As you know, Google holds a
> variety of domains, and we routinely receive requests from other CAs
> attempting to confirm that an applicant was duly authorized to make a
> request, and we routinely have to contact CAs and request revocation for
> certificates that were not authorized according to our company policy.
> Allowing escape clauses, even at the EVGL level, significantly weaken
> our ability to proactively prevent this, which we believe would reduce
> both ours and CAs' administrative burdens.

This seems to be sort of a question of whether CAA is actually like HPKP
("deny access, come what may, if things get configured wrong") or more
like an expired cert is currently treated in browsers ("allow an
override with a warning/extra care").

As I see it, we have three options:

1) Strict is the only way to go - Ryan's preference.
2) Loose(r) is the only way to go - let's pick one of Rick's 4 options.
3) Allow domain owner to decide, with loose(r) as default.

There may be better extension mechanisms than this in CAA, but 3) could
be achieved by adding a CAB Forum-defined domain ("strict.cabforum.org")
to the CAA record. If a CA sees this, they may not under any
circumstances issue the certificate until they see the CAA record
change, and to do so is a misissuance. If they don't see it, we use the
High Risk process, or some EV process, or whichever of Rick's options we
decide. I don't think this is much extra complexity - if we are going to
require CAA checking, we can require CAA checking and
strict.cabforum.org recognition too.

I suggest this because I think it might be a good way to meet Google's
needs for absolute bans, without making CAA, like HPKP, a technology
that only large sites will deploy because of the near-"bricking" potential.

I agree with Ryan that, even if the process is loose, we need proper
audit trails to make sure the CA does the checks and follows the
exception process properly.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Continuing the discussion on CAA

2016-09-08 Thread Ryan Sleevi

On Thu, Sep 8, 2016 at 2:40 PM, Rick Andrews 
wrote:

> Additionally, I'd like to address this point: 'Ryan pointed out that, at
> present, nothing would prevent Neil from stating in his CP/CPS that his CA
> will issue certificates if he sees a CAA record for "symantec.com" '. If
> Neil adopted that policy, wouldn't it violate RFC 6844, which says "The
> issue property entry authorizes the holder of the domain name  Domain
> Name> or a party acting under the explicit authority of the holder of that
> domain name to issue certificates for the domain in which the property is
> published."?
>

Rick,

As you know, the IETF historically shies away from discussions of policy,
and instead focuses on the technological side. We can see that certainly
with PKIX (RFC 5280 & friends), and it was actually a frequently reiterated
point during the discussion of CAA through its standardization.

As such, we should imagine that CAA defines the structural representation,
but it's up to the CA/B Forum to specify the policy that applies here. You
can see that the document intentionally shies away from this discussion in
Sections 6.1 and 6.2, and that's arguably the right thing.

The extent of my comments was to make sure that, in developing a policy for
CAA (which I'm strongly supportive of, so appreciate you continuing the
discussion), we make it clear what is and is not acceptable. If we were to
accept that Neil doing so would violate RFC 6844, then we must also accept
that the only RFC 6844-compliant method of a CA running into the situation
you propose is to Not Issue At All. That is, not even Option 1 is
acceptable (since you included the parenthetical escape clause).

My "ideal" outcome for CAA within the CA/B Forum would be:
1) A requirement in the CPS to state that the CA respects CAA
2) A requirement that the CPS documents which domains the CA recognizes in
CAA records. As a consequence, if a CA wishes to recognize additional
domains in CAA records, this requires a CPS update.
3) A requirement that the CA honor the CAA record exactly as presented,
with no overriding allowed, short of changing the DNS record.
4) A requirement that the CA maintain audit records regarding their CAA
evaluation, such as:
  - The order and sequence of DNS records they attempted to resolve
  - The results of those DNS records and the source of the information.

Each of these I suspect is controversial in some way, and will no doubt
require more discussion, but to briefly justify this:

#1, without #2-4, is largely toothless. However, my goal is to ensure that
auditors have a consistent framework to evaluate a CA's compliance, and for
the public at large as well to evaluate. If a CA says it supports CAA, and
a misissuance event occurs that contravenes that, it's natural that both
auditors and the public should want to understand why and how, and setting
this up within the CPS makes it clear that the CA is committed to
explaining that.

#2 is about making it clear for Subscribers and Applicants the "Right Way"
to configure things. Each CA naturally is free to manage their customer
relations as they wish, but it can be hard to find consistent information
(such as where to report misissuance events), and the CPS is the one
universal aspect that all CAs must have and abide by, so it naturally makes
sense to ensure it's in a consistent and discoverable place.

#3 is clearly a sticking point. I think we're all pretty aware of CAs'
objections to this, but I do feel strongly that, without this, CAA is not
an effective security mitigation. As you know, Google holds a variety of
domains, and we routinely receive requests from other CAs attempting to
confirm that an applicant was duly authorized to make a request, and we
routinely have to contact CAs and request revocation for certificates that
were not authorized according to our company policy. Allowing escape
clauses, even at the EVGL level, significantly weaken our ability to
proactively prevent this, which we believe would reduce both ours and CAs'
administrative burdens.

#4 is less obvious. During Bilbao, we discussed how DNS resolution can be
unreliable for CAs; for example, network hiccups due to peering
interconnects can manifest as a DNS timeout, rather than a successful
(negative) response. We also know that CAA policies are only applicable at
time of issuance, and may change, so we can't examine post-facto the CAA
record of a domain and make a declarative judgement of misissuance.
However, unfortunate as it is, CAA is a "fail open" rather than "fail
closed" model - any misconfiguration on the CA's part (such as forgetting
to configure their DNS clients or firewalls correctly) can result in
issuance, even when a domain holder explicitly requests that the CA not
issue (via CAA). So we need to have some sort of way to audit this, so
that, in the event of claimed conflict, we can better ascertain what
happened, and why. This is a rough sketch of an attempt to do so, but the
point in particular

68 matches

Mail list logo