Subject: [dane] Restrictive assertions in scope of charter?

From: Matt McCutchen <[email-masked]>
Date: Sat, 11 Jun 2011 19:16:52 -0400

Restrictive assertions about name-bound credentials [1] are in the use
cases document and the protocol document (though the latter has a lot of
reworking yet to come), but whether they are in scope of the current
charter is less clear.  The whole charter is written with additive
assertions in mind and contains no mention of restrictive assertions
that would serve to include them, and there is the statement "More
general statements of policy for a domain are out of scope", which
definitely excludes orthogonal stuff like HASTLS and might exclude
restrictive assertions.

So it's possible that the current charter excludes restrictive
assertions, and it's possible that the exclusion is unintentional, or at
least desirable to change now.

Phill says restrictive assertions are out of scope
(https://www.ietf.org/mail-archive/web/pkix/current/msg29356.html).  How
do others interpret the charter?  If it is believed necessary, I would
support a charter update to place restrictive assertions in scope,
matching the current use cases document.  Others?  If consensus was that
restrictive assertions should be out of scope, I'd appreciate if people
could remind me of the pertinent arguments.

[1] I.e., an assertion that a legitimate credential for a given name
will satisfy a constraint, which a client may use as grounds to reject a
credential it would have accepted in the absence of the assertion.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Jun 2011 20:53:49 -0400

What I said was that the charter does not make an explicit claim.

I think that if people who wrote the charter for one WG want to go off and
wave it at another with some sort of exclusivity claim then the charter
claim has to at least be clear and unambiguous.

On Sat, Jun 11, 2011 at 7:16 PM, Matt McCutchen <[email-masked]>wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
Website: http://hallambaker.com/

---

From: John Gilmore <[email-masked]>
Date: Sat, 11 Jun 2011 18:09:03 -0700

Deconfuse me a minute here.

DANE was created because there's a significant problem with being able
to trust the hundreds of trust-roots in current TLS CA practices.
(The problem is that some of them are not trustworthy - but we don't
know which ones until we're burned, and even then, if we mark the
whole CA as untrusted, we also mark many valid keys, certified by
that CA, as untrusted.)

Phillip seems to be claiming that DANE can't "restrict" current TLS
practice, by which he seems to mean that if current TLS practice says
"accept that this key belongs to this site", DANE can't provide clients
any information saying "no it doesn't -- the CA must have been hacked".
Nor even, "Use this key instead - it's signed by the domain holder."

On this theory, DANE could certify a key that old TLS practice didn't
provide any information about, or could provide additional assurance
for an already CA-certified key, but couldn't decertify a key that old
TLS practice validates.

If Phillip is right, I don't see how DANE could improve the security
of TLS, absent a mass migration away from the old insecure TLS
practices (CA's).

	John

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 11 Jun 2011 23:00:22 -0400

> What I said was that the charter does not make an explicit claim.

Ah, thanks for the clarification.

> I think that if people who wrote the charter for one WG want to go off
> and wave it at another with some sort of exclusivity claim then the
> charter claim has to at least be clear and unambiguous.

I'm not sure whether you are referring to (1) DANE restrictive
assertions or (2) the proposal to drop CAA RP in favor of DANE.

Regarding (1), DANE does not claim any kind of exclusivity as a
mechanism for TLS server authentication.  It is just defining the
semantics for RPs that choose to use DANE, and those semantics induce a
set of acceptable certificates that need not be a superset of the PKIX
set.  (If you even read that much into it.  The latest viewpoint seems
to be to describe the DANE data as an assertion and leave client
behavior unspecified to avoid objections about forcing policy on the
client.)

Re (2), I believe the proposal was based not on charters, but on the
fact that DANE has the express purpose of supporting relying party
enforcement in full generality, and thus can be presumed to give a
better solution than a simple copy-and-paste of an issuance enforcement
scheme.  If you see technical shortcomings of DANE compared to CAA RP, I
urge you to raise them.  So far, you have raised only cultural and
political objections (see previous discussion:
https://www.ietf.org/mail-archive/web/dane/current/msg02624.html ).

The upshot is that I have yet to be convinced of the value of pursuing
CAA RP.  But I do not intend to stand in the way of it.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 12 Jun 2011 00:10:09 -0400

On Sat, Jun 11, 2011 at 11:00 PM, Matt McCutchen <[email-masked]>wrote:
> enforcement in full generality,

No it does not, its not even explicit in the charter.

> and thus can be presumed to give a

That is an insult to my work. I do not do superficial proposals.

We have considerable expertise in the field. We put in a great deal of time
and effort.

The use case document I submitted is considerably more comprehensive than
the one DANE chose to work from.

scheme.  If you see technical shortcomings of DANE compared to CAA RP,
> I urge you to raise them.

Well the fact that it is expressed in non PKIX style would seem to me to be
a pretty big obstacle to having it included in PKIX based applications.

And the fact that you still haven't proposed a scheme that meets the DNS
constraints you acknowledged in the earlier exchange.

It is quite possible that you will come up with another way to meet those
constraints, but until you have done so, I have a proposal and you don't. It
is also possible that you will work out a better way to navigate those
constraints than I have.

But at the end of the day CAA RP has a much easier problem to solve because
it is only doing restriction, not restriction plus distribution of end
entity keys. So I don't need to use prefixing at all for CAA which is
inescapable if you are going to do end entity keys.

There are only two technical proposals currently on the table that allow you
to meet all the DNS constraints.

The first is that you decide not to distribute EE keys an to only distribute
key signing keys in the DNS. This obviates the need for prefixing entirely
and makes DANE logically equivalent to CAA. So since you are going to need a
CA in there anyway (possibly run locally) why not just adopt CAA as the
basis for DANE as well?

The second is that you decide you want to put the EE keys in the DNS because
you don't want to have to run a CA everywhere. That is fine but you will
then have to adopt at least part of the GSRV/ESRV approach and have an
unprefixed record for the first round of lookup which may involve a
canonical name and then apply the prefix to the canonical if that is
necessary to continue at finer grain discovery.

Again, I have solved the technical problem, so why not just consider doing
it my way?

I mean seriously, when have you ever seriously considered the possibility of
doing anything I suggest?

I have a complete system and it has a compelling value proposition in the
Web Services space, one of the hotest, fastest growing spaces in the field.
How to make PKI work for Web Services is currently an unsolved problem.

If you want to affect the way browsers work you will find it much easier to
do so by establishing a critical mass of users and proving the value in the
Web Services field.

>  So far, you have raised only cultural and

Which is what the standards process is entirely about.

If you think that the core problem here is a fault in PKIX then the
appropriate response is to propose a solution to PKIX or CABForum or both.

If you think that the issue here is an opportunity to use DNSSEC to replace
the need for DV certs in certain use cases then the appropriate response is
to start a WG to put keys in the DNS.

Trying to do both in the same WG is a terrible idea. It forces you to
address the legacy constraints of both the DNS and PKIX at the same time.
And both systems are now infrastructures and the legacy constraints are far
more complex than any single individual can hope to understand.

What I am saying here is that far from having a turf battle with PKIX
demanding to keep the RP restriction issue to themselves, the DANE group
should be begging them to take it off their hands.

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 12 Jun 2011 12:54:46 +0200

> for an already CA-certified key, but couldn't decertify a key that old

IMHO, this is the most important use case for DANE - we need DANE to keep a leash on PKI, and restrictive assertions is the way we do this.  I want tell the my users what certs (or issuers) I intend to use, and that other certs are not valid.

DANE clients can always implement their own policy accepting the certs anyway, just as many people today - based on my experience - just click "continue" whenever the annoying certificate warning goo pops up their browser. 

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 12 Jun 2011 08:54:53 -0400

On Sun, Jun 12, 2011 at 6:54 AM, Jakob Schlyter <[email-masked]> wrote:

> IMHO, this is the most important use case for DANE - we need DANE to keep a
> leash on PKI, and restrictive assertions is the way we do this.  I want tell
> the my users what certs (or issuers) I intend to use, and that other certs
> are not valid.
>
> DANE clients can always implement their own policy accepting the certs
> anyway, just as many people today - based on my experience - just click
> "continue" whenever the annoying certificate warning goo pops up their
> browser.

Which is not at all what you advertised to the rest of the IETF at the
start.

If you want to 'keep a leash on PKI' as in PKIX then you are proposing to
change the semantics of PKIX BY DEFINITION. There is no way that you can do
that without affecting PKIX clients.

So you have to do that in PKIX if that is what you want to do.

Here is an idea, first propose a mechanism for publishing keys in the DNS
that actually works with the DNS (CNAME, SRV, Wildcards) before you try
proposing to 'keep a leash' on other people's existing work.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 12 Jun 2011 07:37:23 -0600

Apologies to all for the latency in responding -- I'm traveling (and will be for a month or so) and haven't been checking email as frequently as I should….

> to trust the hundreds of trust-roots in current TLS CA practices.

Yup, that was one of the driving forces behind the creation.

If I'm example.com and I get my certs from GoodCerts, I'd like a way to "protect" users who access example.com from accepting a certificate issued for example.com by BadCerts. I know which CA (and, more specifically, which cert I am using) and want to provide a means for relying parties to know this too.

Now that I have this ability, if I wish to generate and use my own certificate (which I have signed with the key itself (see how I avoided using "self-signed" there? ;-) )) I should be able to tell relying parties this as well -- they  can use this information as input to decide if the certificate should be trusted.

> whole CA as untrusted, we also mark many valid keys, certified by

I would have worded that differently :-)

Actually I think that I have a whole different spin on this -- the folk who get certificates choose a particular CA to obtain the cert from -- their reasons for choosing X over Y over Z are not important, what is it that they have made this decision, and gotten a certificate (let's call it A). *This* is the certificate that relying parties should use, not one from Y, not one from Z, not a different one from X, but A (ok, or multiple A's).

Someone who operates example.com knows definitively (well, should!) which certificate (or set thereof) are in use -- they should be able to communicate this so that folk who connect to example.com can know that there are shenanigans if they see a different cert….

> of TLS, absent a mass migration away from the old insecure TLS

Ok, so -- seeing as this question keeps coming up (for whatever reason) it seems that the we need to clearly and concisely define the question, record it in the issue tracker and get our AD's to weigh in here (I think that questions that clarify if something is in scope should have the AD's input, especially if the chairs think that it is in scope). 

So, can folk please help me clearly define the question? I'm having a hard time wording it clearly, concisely and unambiguously.
Matt's "an assertion that a legitimate credential for a given name will satisfy a constraint, which a client may use as grounds to reject a
credential it would have accepted in the absence of the assertion." comes close, but is (IMO) a little hard to read.

Something along the lines of:
----------------------------------------
Is the "restrictive" case within the charter?
The restrictive case is: If a relying party finds information in the DNS (for example in a TLSA record) that states that certificates X and Y are the certificates that should be accepted, it may use this information to reject certificate Z (even if it would have accepted Z without this information).
----------------------------------------------
or
----------------------------------------
Is the "restrictive" case within the charter?
The restrictive case is: If a relying party finds information in the DNS (for example in a TLSA record) that states that the credentials to be use must satisfy the following criteria, it may use this information to reject credentials that to not satisfy these criteria. An informal example of the criteria  could be: "Must match the following set of certificates"
----------------------------------------------

I think that this needs some serious word-smithing :-P . I am trying to keep it general and informal enough so that it is easily understood (I tried this with various words instead of "certificate" and credentials,  but they all sounded klunky, which leads me to think that they were not good choices). I am looking for something that clearly outlines the intent, not something too formal (I don't want us to end up in the "Ha, but that doesn't apply on Thursdays in March if it's also a full moon.")

W
P.S: Apologies for the grumpy (and rushed) tone, I'm a: grumpy and b: rushed!

---

From: Warren Kumari <[email-masked]>
Date: Sun, 12 Jun 2011 07:43:40 -0600

> What I said was that the charter does not make an explicit claim.

Yes, you are correct, the charter is not explicit here.

Let's get the question clear and unambiguous, get our ADs to confirm if the "restrictive assertions" case is within the scope, clearly record this and move on. If the ADs thing it is necessary we can discuss getting the clarification inserted / appended to the charter. 

W

> I think that if people who wrote the charter for one WG want to go off and wave it at another with some sort of exclusivity claim then the charter claim has to at least be clear and unambiguous.
> 
> 
> 
> 
> On Sat, Jun 11, 2011 at 7:16 PM, Matt McCutchen <[email-masked]> wrote:

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 12 Jun 2011 10:52:00 -0400

On Sun, 2011-06-12 at 07:37 -0600, Warren Kumari wrote:
> Ok, so -- seeing as this question keeps coming up (for whatever
> reason) it seems that the we need to clearly and concisely define the
> question, record it in the issue tracker and get our AD's to weigh in
> here (I think that questions that clarify if something is in scope
> should have the AD's input, especially if the chairs think that it is
> in scope). 
> 
> So, can folk please help me clearly define the question? I'm having a
> hard time wording it clearly, concisely and unambiguously.
> Matt's "an assertion that a legitimate credential for a given name
> credential it would have accepted in the absence of the assertion."
> comes close, but is (IMO) a little hard to read.
> 
> The restrictive case is: If a relying party finds information in the
> DNS (for example in a TLSA record) that states that certificates X and
> Y are the certificates that should be accepted, it may use this
> information to reject certificate Z (even if it would have accepted Z
> without this information).
> The restrictive case is: If a relying party finds information in the
> DNS (for example in a TLSA record) that states that the credentials to
> be use must satisfy the following criteria, it may use this
> information to reject credentials that to not satisfy these criteria.
> An informal example of the criteria  could be: "Must match the
> following set of certificates"
> I think that this needs some serious word-smithing :-P . I am trying
> to keep it general and informal enough so that it is easily understood
> (I tried this with various words instead of "certificate" and
> credentials,  but they all sounded klunky, which leads me to think
> that they were not good choices). I am looking for something that
> clearly outlines the intent, not something too formal (I don't want us
> to end up in the "Ha, but that doesn't apply on Thursdays in March if
> it's also a full moon.")

I was treading very carefully around the policy objection.  The "must"
and "should" in your formulations may be problematic.

Also, your first formulation describes the restrictive use of an
assertion that is both additive and restrictive.  Since we do want to
support purely restrictive assertions, it would be better to describe
that case and let the reader realize that, with both additive and
restrictive assertions in scope, a site owner could use both (or one
assertion that works both ways; the difference is immaterial).

The second formulation, with "must" replaced by "will", is pretty good.
I would just mention that the assertion applies to the protocol endpoint
identified by a tuple that contains a DNS name.  For TLS, it is a
service identified by (DNS name, transport protocol, port), but I want
to be general to S/MIME, IPsec, etc.

-- 
Matt

---

From: Stephen Kent <[email-masked]>
Date: Sun, 12 Jun 2011 12:40:46 -0400

At 7:37 AM -0600 6/12/11, Warren Kumari wrote:
>Apologies to all for the latency in responding 
>-- I'm traveling (and will be for a month or so) 
>and haven't been checking email as frequently as 
>I shouldŠ.
>

I concur.

If the WG adopts a requirements statement that 
includes this (IMHO important) case, then it 
follows that DANE-enabled clients MUST be allowed 
to reject a cert from a server, if that cert is 
inconsistent with the DANE data retrieved and 
validated by the client.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Jun 2011 23:51:42 +0100

On 12/06/11 17:40, Stephen Kent wrote:
>> Apologies to all for the latency in responding -- I'm traveling (and
>> will be for a month or so) and haven't been checking email as
>> frequently as I shouldŠ.
>>
> If the WG adopts a requirements statement that includes this (IMHO
> important) case, then it follows that DANE-enabled clients MUST be
> allowed to reject a cert from a server, if that cert is inconsistent
> with the DANE data retrieved and validated by the client.

Same here. (As AD, since I was asked.)

To be clear, I had a look at the charter again, and I think that
the phrase "validate these bindings in the execution of specific
applications" implicitly puts the restrictive semantic within the
scope of the charter. The only alternative reading of that would
be that DANE would have to either just define ways to make TLS/IPsec
more liberal or else define entirely new ways to make TLS/IPsec
work, neither of which would make sense. I see no need to recharter
for this. If we do recharter maybe make a note that it should be
clearer, if still needed at that point in time.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Jun 2011 10:22:08 -0400 (EDT)

On Sun, 12 Jun 2011, Phillip Hallam-Baker wrote:

> Again, I have solved the technical problem, so why not just consider doing it my way?

Because CAA is based on the goodwill and competence of a group that
seems to be doing worse over time instead of improving over time. Plus,
with browers (and particularly open source browsers) we seem to have a
much better control on the security implementations, especially when
talking to DNSSEC data directly instead of via X.509 indirectly.

> If you want to affect the way browsers work you will find it much easier to do so by establishing a critical mass of users and
> proving the value in the Web Services field.

I'd say that's what the DANE draft various DANE code snippets have done.

>       political objections (see previous discussion:

I'd argue DANE is much less about politics and more about veriable code then
CAA and CA's are, after all CA's and EVR et all is more lawyer enforced then
technology enforced. DANE is about removing politics and lawyers.

The security check ultimately has to be on the end client, not some middle man
organisation. CAA is just a signaling method for CA's that uses DNSSEC as
transport security. Whether the signal gets used or lost is totally up to
the CA, the lawyers and the push of the free market. None of which are good
security enforcers. While I don't mind the CAA, I have no use for it, I do
object to CAA and other proposals slowing down DANE for non-technical reasons.

> If you think that the issue here is an opportunity to use DNSSEC to replace the need for DV certs in certain use cases then the
> appropriate response is to start a WG to put keys in the DNS.

These reoccuring motions for delaying DANE are becoming repetitive and I am
losing my patience with these. The IETF is about enabling new technologies,
not about limiting new technologies. DNSSEC is not an accidental "opportunity".
DANE grew out of the shortcomings and failures of PKIX on the open market.

> What I am saying here is that far from having a turf battle with PKIX demanding to keep the RP restriction issue to themselves,
> the DANE group should be begging them to take it off their hands.

Good security usually does not involve begging nor shoving problems to eager
recipients.

In the last two months we have seen how dismal the state of security on the
internet is. 17 year old high school dropouts are shaming one company after
the other while some actual sophisticated hackers have taken the crown
jewels. We're long overdue in replacing some of the old school technologies
that failed to adequately protect us. Those who wish to remain using the
old stuff, are free to do so. Just don't stand in our way of trying 
something else, because those 20 years of experience aren't doing us any
good right now.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 13 Jun 2011 17:38:56 +0200

On 12.6.2011 15:43, Warren Kumari wrote:
> Let's get the question clear and unambiguous, get our ADs to confirm
> if the "restrictive assertions" case is within the scope, clearly
> record this and move on. If the ADs thing it is necessary we can
> discuss getting the clarification inserted / appended to the charter.

Which has happened in <[email-masked]> and at least on of
our AD think it is within the charter.

I agree that if we ever recharter we could try to polish the charter to
make it more clearer on the restrictive assertions, but now we can just
move on with a fact that "Restrictive assertions are in the scope of the
charter."

Now when we have -03 of use cases document (after WGLC) Paul and Jacob
can resume on the protocol draft (and they already did).

O.
-- 
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------