Subject: [keyassure] Approaches for expressing root restrictions.

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Sep 2010 20:24:39 -0400

On Tue, Sep 21, 2010 at 7:04 PM, Tony Finch <[email-masked]> wrote:

> On 21 Sep 2010, at 22:13, Phillip Hallam-Baker <[email-masked]> wrote:
> >
> > I really do not accept that an assurance delivered via CERT should be
> exclusive.
> >
> > If we are going to define semantics of that type we need to consider
> other mechanisms for defining the allowable trust roots for a domain.
>
> There are three gaps that need to be filled:
>
> 1. Use the DNS as another x.509 trust anchor.
> 2. Assert that a service requires TLS.
> 3. Prevent tinpot CAs from claiming to authenticate a service.
>
> You want 3 to be out of scope.
>
> If you allow CERT records to identify a certificate that (transitively)
> signs the service's certificate, rather than just the service's
> certificate(s) directly, then you have a fair way of defining the allowable
> trust anchors, and of addressing the many-certificate problem.
>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/

No, I stated that I want the charter to be explicit and that either 2+3 are
both in scope or both out of scope.

I do not want to address 3 without 2 because I believe that restrictions on
roots of trust are a form of policy mechanism and that the correct way to
handle restricting roots of trust is through an explicit policy statement.

So I want either the whole problem to be on the table or none of it. What I
don't want is to have a charter where the scope is written round the
capabilities of one particular solution.

I think that the IETF needs to address all three problems. And I think that
if we decouple 1 from 2 and 3 then we don't need to bother with a charter or
a WG at all. All we need is to propose the additional cert types and get an
informational RFC out pronto. We would then charter the WG to address items
2 and 3 and to take the full set of drafts to standard status.

What I don't want at the protocol level is for this type of restriction to
be a side effect of publishing CERT records. I think that is an absolutely
terrible and indefensible design.

If people want to express a root restriction I see the following mechanisms
as being preferable.

1) CERT records combined with a policy record stating that a CERT record
MUST exist:

_http._tcp.example.com  ESRV  "ssl=required certassure=required"

2) Specify that certs must be cross certified to a particular trust anchor

_http._tcp.example.com  ESRV
 "ssl=required xa=SHA256:234f98yef9y293yr982yef982y3"

or (maybe better) specify a node where a CERT record lives:

_http._tcp.example.com  ESRV  "ssl=required xa=root.example.com"
root.example.com CERT 1 1 234f98yef9y293yr982yef982y3

3) Specify a list of CA issuing certs, one of which MUST be in the path:

_http._tcp.example.com  ESRV  "ssl=required
pc=sha256:234f98yef9y293yr982yef982y3 pc=sha256:298y2ew9fy2398fy98y98y98w"

or:

_http._tcp.example.com  ESRV  "ssl=required pc=ca.example.com"
ca.example.com CERT 1 1 234f98yef9y293yr982yef982y3
ca.example.com CERT 1 1 298y2ew9fy2398fy98y98y98w

These mechanisms are not exclusive.

This approach provides for clean separations of concerns with no surprises.
Telling people 'trust this cert' does nothing else.

The TLSFP approach has me deploying the cert fingerprints with one idea and
then having a completely unexpected set of semantics sprung on me after the
fact. The admin of the mail server is going to deploy a CERT record for use
with STARTTLS and the Web server will suddenly stop working.

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 21 Sep 2010 22:02:33 -0400

(3) is clearly out of scope.  TA selection is a local policy issue,  
not a standards matter.

On Sep 21, 2010, at 8:24 PM, Phillip Hallam-Baker wrote:

> > I really do not accept that an assurance delivered via CERT should  
> be exclusive.
> >
> > If we are going to define semantics of that type we need to  
> consider other mechanisms for defining the allowable trust roots for  
> a domain.
>
> If you allow CERT records to identify a certificate that  
> (transitively) signs the service's certificate, rather than just the  
> service's certificate(s) directly, then you have a fair way of  
> defining the allowable trust anchors, and of addressing the many- 
> certificate problem.
>
> Tony.
> --
> No, I stated that I want the charter to be explicit and that either  
> 2+3 are both in scope or both out of scope.
>
> I do not want to address 3 without 2 because I believe that  
> restrictions on roots of trust are a form of policy mechanism and  
> that the correct way to handle restricting roots of trust is through  
> an explicit policy statement.
>
> So I want either the whole problem to be on the table or none of it.  
> What I don't want is to have a charter where the scope is written  
> round the capabilities of one particular solution.
>
> I think that the IETF needs to address all three problems. And I  
> think that if we decouple 1 from 2 and 3 then we don't need to  
> bother with a charter or a WG at all. All we need is to propose the  
> additional cert types and get an informational RFC out pronto. We  
> would then charter the WG to address items 2 and 3 and to take the  
> full set of drafts to standard status.
>
>
> What I don't want at the protocol level is for this type of  
> restriction to be a side effect of publishing CERT records. I think  
> that is an absolutely terrible and indefensible design.
>
> If people want to express a root restriction I see the following  
> mechanisms as being preferable.
>
> 1) CERT records combined with a policy record stating that a CERT  
> record MUST exist:
>
> xa=SHA256:234f98yef9y293yr982yef982y3"
>
> This approach provides for clean separations of concerns with no  
> surprises. Telling people 'trust this cert' does nothing else.
>
> The TLSFP approach has me deploying the cert fingerprints with one  
> idea and then having a completely unexpected set of semantics sprung  
> on me after the fact. The admin of the mail server is going to  
> deploy a CERT record for use with STARTTLS and the Web server will  
> suddenly stop working.
>
> -- 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Sep 2010 22:02:50 -0400

On Sep 21, 2010, at 8:24 PM, Phillip Hallam-Baker wrote:

>> I really do not accept that an assurance delivered via CERT should be exclusive.
>> 
>> If we are going to define semantics of that type we need to consider other mechanisms for defining the allowable trust roots for a domain.
> 
> If you allow CERT records to identify a certificate that (transitively) signs the service's certificate, rather than just the service's certificate(s) directly, then you have a fair way of defining the allowable trust anchors, and of addressing the many-certificate problem.
> 
> Tony.
> --
> No, I stated that I want the charter to be explicit and that either 2+3 are both in scope or both out of scope.
> 

Great -- Do you have proposed text for the charter that clearly and concisely covers these? <not trying to be snide, I'd like to see it>

> I do not want to address 3 without 2 because I believe that restrictions on roots of trust are a form of policy mechanism and that the correct way to handle restricting roots of trust is through an explicit policy statement.

> So I want either the whole problem to be on the table or none of it. What I don't want is to have a charter where the scope is written round the capabilities of one particular solution.

Ok, when I initially read some of your messages I also got the impression that you wanted to just rule 3 out of scope... 

> 
> I think that the IETF needs to address all three problems.

Cool, as do I.

> And I think that if we decouple 1 from 2 and 3 then we don't need to bother with a charter or a WG at all. All we need is to propose the additional cert types and get an informational RFC out pronto. We would then charter the WG to address items 2 and 3 and to take the full set of drafts to standard status.

I don't think that these should be uncoupled -- I think that the additional cert types is an integral part of the work, and that having the semantics be clear is important, so I think that, if a WG is formed, it would be in the correct position to understand the implications of this... 

> 
> 
> What I don't want at the protocol level is for this type of restriction to be a side effect of publishing CERT records. I think that is an absolutely terrible and indefensible design. 
> 
> If people want to express a root restriction I see the following mechanisms as being preferable.
> 
> 1) CERT records combined with a policy record stating that a CERT record MUST exist:
> 
> _http._tcp.example.com  ESRV  "ssl=required xa=SHA256:234f98yef9y293yr982yef982y3"
> 

Ok, so to make sure that I am understanding you, I can generate a self-signed cert and publish it and a fingerprint (234f98yef9y293yr982yef982y3), and then chain to that? So I can create and reference my own trust anchor for use within example.com...

> _http._tcp.example.com  ESRV  "ssl=required pc=sha256:234f98yef9y293yr982yef982y3 pc=sha256:298y2ew9fy2398fy98y98y98w"
> 
> or:
> 

Cool...

> 
> This approach provides for clean separations of concerns with no surprises. Telling people 'trust this cert' does nothing else. 
> 
> The TLSFP approach has me deploying the cert fingerprints with one idea and then having a completely unexpected set of semantics sprung on me after the fact. The admin of the mail server is going to deploy a CERT record for use with STARTTLS and the Web server will suddenly stop working.
> 

Ok, I think I see where you are coming from now -- I think that we may have been speaking at cross purposes. I (and I suspect others too) had been working on the assumption that the CERT record for the mail server would be published at 'smtp.example.com' and the web server one would be at 'www.example.com' and so conflicts would be avoided in that way.

I still feel that collisions / conflicts would be avoided in this way, as folks naturally choose different labels for services. I don't really think that this point needs be be discussed in the charter, the WG can discuss and come to consensus on the best way to label / find these records.

I feel that this has been a useful discussion and that we are beginning to all arrive on the same page.... Amazing just how often discussions end up sounding more like arguments because parties are using different terminology and are working from different assumptions...

Thanks you,

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Sep 2010 22:21:11 -0400

On Sep 21, 2010, at 10:02 PM, Richard L. Barnes wrote:

> (3) is clearly out of scope.

I'm not so sure, I think we are talking about different things here...

>  TA selection is a local policy issue, not a standards matter.

Yes, TA selection is (and should be) local policy, but we need a standard manner to be able to refer to and publish them...

If I have a certificate that is chained to TA Foo (or if I decide to publish TA Blargh) you are (and should be) fully entitled to make your own decision as to the trustworthiness of Foo and Blargh and decide to ignore, trust, jump up and down on, etc.

What I think is a standards matter is for me (a site owner) to be able tosecurely publish that my cert is 0x85829bce32 and that it is chained to 0x533422c23.
If you get my cert and it looks like 0x123123123 and is chained to 0x343434334 you can still make whatever decision you like as it you trust 0x533422c23 and 0x343434334 (and anyone else), but knowing that the cert / TA you got isn't the one I intended you get seems like it is important...

W

>> I think that the IETF needs to address all three problems. And I think that if we decouple 1 from 2 and 3 then we don't need to bother with a charter or a WG at all. All we need is to propose the additional cert types and get an informational RFC out pronto. We would then charter the WG to address items 2 and 3 and to take the full set of drafts to standard status.
>> 
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Sep 2010 22:52:44 -0400

There are two possible types of trust anchor publication:

1) Tell relying parties that they SHOULD trust anchor = X
2) Tell relying parties that they MUST NOT trust anchor != X

What is being proposed here is the second (I hope).

I think we all agree that the first would be a really bad idea.

In particular they are concerned with a specific attack where the site has a
certificate from a high assurance CA and wants to prevent an attacker
obtaining a certificate from a minimal assurance CA.

On Tue, Sep 21, 2010 at 10:02 PM, Richard L. Barnes <[email-masked]> wrote:

> (3) is clearly out of scope.  TA selection is a local policy issue, not a
> standards matter.
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Sep 2010 23:20:45 -0400

On Tue, Sep 21, 2010 at 10:02 PM, Warren Kumari <[email-masked]> wrote:

> Great -- Do you have proposed text for the charter that clearly and
> concisely covers these? <not trying to be snide, I'd like to see it>

Well first of all I think I want to know if we are trying to include or
exclude the items from the charter.

I think we also need to get some feedback from the AD to see what his view
is.

>
> > And I think that if we decouple 1 from 2 and 3 then we don't need to
> additional cert types and get an informational RFC out pronto. We would then
> charter the WG to address items 2 and 3 and to take the full set of drafts
> to standard status.
>
> I don't think that these should be uncoupled -- I think that the additional
> cert types is an integral part of the work, and that having the semantics be
> clear is important, so I think that, if a WG is formed, it would be in the
> correct position to understand the implications of this...

The reason I want to decouple 1 is that I see it as a separate problem and a
much simpler one.

We already have a decades worth of experience in issuing certs, the number
of degrees of freedom are actually quite small. We have experience of
putting keys in the DNS.

As far as mechanism goes, this is the low hanging fruit. The hard part here
is precisely calibrating the level of risk control achieved and writing the
Security Considerations.

Items 2 and 3 are much harder. They take us into territory that has only
been travelled before in DKIM and was somewhat controversial then.

They are much harder, but they are also much more important. They are the
alpha and omega of DNSSEC in my view. There are plenty of better ways to fix
the Kaminsky bug and if people want free certs they are going to be getting
them long before DNSSEC is viable. The only reason for deploying DNSSEC that
justifies the investment made is to publish security policy.

> Ok, so to make sure that I am understanding you, I can generate a
> self-signed cert and publish it and a fingerprint
> (234f98yef9y293yr982yef982y3), and then chain to that? So I can create and
> reference my own trust anchor for use within example.com...

That would be one way to do it.

Many enterprises already have an LRA and their own CA cert which may or may
not be cross-certified into a well known root.

Ok, I think I see where you are coming from now -- I think that we may have
> been speaking at cross purposes. I (and I suspect others too) had been
> working on the assumption that the CERT record for the mail server would be
> published at 'smtp.example.com' and the web server one would be at '
> www.example.com' and so conflicts would be avoided in that way.
>

I don't think that scales.

Web services are going to come and they are going to be very different in
the way they use DNS.

Ten years from now I would expect Google to be supporting several hundred
different types of Web Service and upwards of a thousand different
protocols. Same for Amazon, EMC and ourselves. Many of those protocols are
going to be proprietary or pre-standards variants.

Now if the customer has to type in a different DNS name according to which
service or protocol is being used, that is going to result in
misconfiguration and that is going to result in customer service calls. And
once you get a customer service call you have just lost your entire margin
for that customer.

So I much prefer a model where we use SRV/NAPTR or something better and the
customer only has to think about one DNS name.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 22 Sep 2010 07:10:12 +0200

> Ok, I think I see where you are coming from now -- I think that we may have been speaking at cross purposes. I (and I suspect others too) had been working on the assumption that the CERT record for…

+1

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 22 Sep 2010 07:14:16 +0200

> What is being proposed here is the second (I hope).

Correct.

> In particular they are concerned with a specific attack where the site has a certificate from a high assurance CA and wants to prevent an attacker obtaining a certificate from a minimal assurance CA.

Correct.

Using the semantics I've described on this list, and that I believe is documented in our draft, we say:

  If you connect to host XXX and receive any other certificate hash than the ones I've listed in DNS; don't trust them.

I still believe that this is very simple and easy to understand for implementors and users, but if someone express this even better please do.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Sep 2010 08:50:56 -0400

On Wed, Sep 22, 2010 at 1:14 AM, Jakob Schlyter <[email-masked]> wrote:

>  If you connect to host XXX and receive any other certificate hash than the
> ones I've listed in DNS; don't trust them.
>

The draft is not at all clear that that is the objective. In fact the
section that sets out the MUST comes after a paragraph that says there will
be other validation modes not covered in the draft.

"This document only relates to securely getting the DNS information for the
certificate association using DNSSEC; other secure DNS mechanisms are out of
scope."

If other mechanisms are out of scope, this document cannot circumvent them.

Semantics as significant as this should be called out in both the abstract
and the introduction.

The CERT record is for telling relying parties that there is a cert they
might use. We can use DNSSEC to extend that to say that there is a cert that
they can trust. We cannot use the CERT record to invalidate existing trust
mechanisms.

You cannot go to the IESG with a proposal that in one go proposes a whole
new PKI trust mechanism and gives it trust semantics that sets it above the
existing mechanisms.

I still believe that this is very simple and easy to understand for
> implementors and users, but if someone express this even better please do.
>

It is not simple, it is simplistic.

The caching semantics of DNSSEC mean that it is impossible to bring a new
Web server on line or change the cert without waiting for all the previous
CERT records that might be cached to expire.

The assumptions that this group has been making as to how people run large
installations are very parochial. When deployment considerations are raised,
people say 'well run your shop my way'. That is not an acceptable approach.

Deployment would be a total horror show. If this feature survived review,
every customer service rep at every CA would be telling their customers not
to turn it on because doing so would be shooting themselves in the foot.

When we introduced EV, Todd Inskeep at BofA gave a talk at RSA where he
described some of what was involved in the BofA deployment. They decided at
the outset that they wanted to turn on all their sites with EV at the same
time. It took them over a year to work out how to do it.

You can't even turn these semantics off.

A mechanism should EITHER tell people that they can trust a key or specify
security policy. Mixing the two is not acceptable.

I am not opposed to doing policy, I just think that the mechanism MUST be
orthogonal. It must be possible to use policy without using CERT records on
the end entity keys.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 22 Sep 2010 09:00:58 -0400

On Sep 21, 2010, at 11:20 PM, Phillip Hallam-Baker wrote:

> Well first of all I think I want to know if we are trying to include or exclude the items from the charter.

I believe that it should be within the scope of the charter / group to investigate and decide what the answer to these questions is. I think that we are trying to include them, but that a perfectly acceptable outcome after including them an having the working group discuss them is to say "Wow, this doesn't work at all, we understand why now, and here is why other folk should tread carefully here." 
The WG would be investigating and understanding what is a complex topic, and should be allowed to investigate the implications of this without having their hand tied...

> 
> I think we also need to get some feedback from the AD to see what his view is. 

*NO* argument here.... 

> The reason I want to decouple 1 is that I see it as a separate problem and a much simpler one. 
> 
> We already have a decades worth of experience in issuing certs, the number of degrees of freedom are actually quite small. We have experience of putting keys in the DNS.
> 
> As far as mechanism goes, this is the low hanging fruit. The hard part here is precisely calibrating the level of risk control achieved and writing the Security Considerations.

Ok, so one of two things can happen here (well, I'm sure there are other things that can happen too :-))

1: The low hanging fruit can be snagged by someone outside the WG.
2: The WG can snag the low hanging fruit, and it can be published with the consensus of the WG.

While it is a simpler problem, having careful review and consensus by a WG seems to make sense to me...

> 
> 
> Items 2 and 3 are much harder. They take us into territory that has only been travelled before in DKIM and was somewhat controversial then.

YES, all the more reason to address it -- having this open for discussion seems important, sweeping the problem under the rug / burying our heads in the sand and having the issue will go away seems like a poor choice...

> 
> They are much harder, but they are also much more important. They are the alpha and omega of DNSSEC in my view. There are plenty of better ways to fix the Kaminsky bug and if people want free certs they are going to be getting them long before DNSSEC is viable.

Yes, folk are free to get free / cheap certs now and I suspect that the incidence of this will increase as time goes by. I do not view this as a win though -- in my opinion there are a small number well run, competent and trustworthy CAs and a large number of others that I do not enough about to make a judgement. As the prevalence of free / super cheap certs increases the market pressures will lead to those who compete on price taking larger and larger shortcuts, potentially being bought out by others with no experience in this space, the proliferation of free / community backed CAs, etc. With this happening there is a large potential for the emergence of poorly run (or even potentially malicious) organizations with certs in the browsers, and no practical way to manage this.  

By allowing those people who *do* want to have a free cert / would mainly be shopping on price and would have gotten their cert from EZCerts-R-US to instead be in control of their own destiny, we remove a large avenue of attack for them. This also avoids the market pressure / reason for the proliferation of super cheap / sketchy CAs.

Those folk to know better (and understand the importance / utility / security of choosing a *good* and well run CA) will of course still get their certs from the few good CAs, and the market will naturally convert on the competent...

(this brought to you by someone who is a techie and not a business person, so who knows how true it is...)

> The only reason for deploying DNSSEC that justifies the investment made is to publish security policy.
> 

> Many enterprises already have an LRA and their own CA cert which may or may not be cross-certified into a well known root.

Yup...

> Web services are going to come and they are going to be very different in the way they use DNS.
> 
> Ten years from now I would expect Google to be supporting several hundred different types of Web Service and upwards of a thousand different protocols. Same for Amazon, EMC and ourselves. Many of those protocols are going to be proprietary or pre-standards variants. 
> 
> Now if the customer has to type in a different DNS name according to which service or protocol is being used, that is going to result in misconfiguration and that is going to result in customer service calls. And once you get a customer service call you have just lost your entire margin for that customer.
> 
> So I much prefer a model where we use SRV/NAPTR or something better and the customer only has to think about one DNS name.

Ok, this seems like something for a group of people working on the problem to discuss and come to consensus on... :-P

W

---

From: Adam Langley <[email-masked]>
Date: Wed, 22 Sep 2010 10:05:56 -0400

> new PKI trust mechanism and gives it trust semantics that sets it above the

Personally, my faith in the PKIX trust system (esp DV/OV) is
luke-warm. I happen to know that I'm not unique in holding this
opinion, but I'm not going to call out anyone else publicly.

So the interest in having a alternative trust system which can
buttress PKIX comes from that. You might not share that opinion, in
which case I understand your aversion although, of course, I believe
your faith to be misplaced.

(I claim no knowledge of the IESG. It may well be the case that they
are likely to reject any such scheme out of hand.)

> people say 'well run your shop my way'. That is not an acceptable approach.

I think Google counts as a large HTTPS deployment and I haven't seen
anything so far which would be inimical to our setup. Of course, our
way isn't the only way and I wouldn't wish to ignore the other designs
that people use. We've already taken sites with large numbers of certs
per domain into account, I'm sure that we could accommodate other
needs also. Maybe they want to assert that they'll always use one or
two root CAs within a given DNS caching period (of, say, a week).

I think it's also important to remember we don't have to meet every
need immediately. The PKIX system isn't going away for a long, long
time (if ever). The danger is that we paint ourselves into a corner
given a possible need in the future. Careful protocol design is needed
to avoid that, but I think we can manage it.

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Sep 2010 10:31:31 -0400

I think we are all pretty much on the same page with regards to the set of
problems we want to address.

My recollection from DKIM was that the ADs told the group that they had to
develop a proposal to do keying first and only then do policy. Stephen F.
will know more about that though.

The reason I want to get finished with key assurance is that my real
interest is in the policy side. I think there are real operational reasons
to separate the two, but there are also significant tactical advantages:

1) I think the IESG will insist on separation in any case.

They certainly should.

2) Convincing people that the policy issues are understood is very hard.

Getting the policy work into the DKIM charter was not at all easy. There
were lots of people who came along to mumble 'security policy is tricky' and
then they would walk off without giving any reasons why.

It is not a mode of argument I think very productive, but it certainly was
effective for about a decade before DKIM.

3) It is much easier once you have some runs on the board to show.

I think that we can get a mechanism for policy-free key assurance agreed
amongst ourselves before Beijing. The reason I am concentrating on our areas
of disagreement is because that is how I believe consensus is reached. At
this point I think we are down to the question of which bits to use to
specify algorithms and whether to have flags to suggest/control
interpretation and if so what they should mean.

As far as I am concerned what really matters is getting the code points
assigned so that people can start testing the mechanism out. That is the
purpose of an experimental or informational draft in my view.

The reason that I was proposing ESRV separately was that I did not
understand that people were looking to open up the security policy argument
at all.

4) Simplify external review

The test for an IETF spec is IETF consensus, not merely working group
consensus. Historically drafts of the form 'here is a new way to validate
keys for your security protocol' have been very easy to get agreement on. I
do not anticipate a lot of resistance to the idea of sticking cert
fingerprints in the DNS and signing them with DNSSEC.

If you have a proposal that conflates key assurance with policy then you
should expect trench warfare.

My preferred charter would be to separate key assurance from policy as
follows:

Key Assurance:

1) Publish key assurance proposal based on merger of ASSERT and TLSFP drafts
as experimental immediately so that DNS code points for CERT certificate
types and/or algorithms can be assigned.

2) Continue development of key assurance proposal as a standards track work
item with a view to sending the draft to the IESG within 12 months.

In parallel, work on design of a policy mechanism that encompasses both
protocol security policies (MUST use SSL) and trust root restrictions (MUST
validate according to criteria X).

1) Publish experimental draft based on ESRV (and/or other proposals people
want to put on the table) as soon as possible.

2) Continue development as a standards track item with a view to sending a
standards track proposal within 18 months.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Sep 2010 18:50:38 +0300

> obtaining a certificate from a minimal assurance CA.
 
Couldn't this be addressed by changing how exclusion is defined sightly:

The server certificate must match at least one CERT-TLSFP record or there
must be valid chain of trust from at least one CERT-TLSFP record?

If one wants to certify server certificate directly, one can put it into DNS
and if one wants to say "valid certificates use TA X or Y", one can put that
into DNS (which of course makes one vulernable to keepers of TAs X and Y).

If one can track of cert changes fast enough to put the end-server certifcate
into DNS, then "bad CA" attack won't gain you anything because you can't
use the bad certificate without client really screaming (either due to TLS
handshake failing or due to DNS exclusion violation)...

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Sep 2010 11:59:04 -0400

That is better from an operations point of view.

But any draft making that proposal has to start off by stating that the
primary purpose of this mechanism is to publish trust restrictions. That has
to be specified in the abstract and at the start of the introduction.

We will also need to have two separate certificate types, one for publishing
key assurances and a second certificate type for publishing exclusive key
assurances.

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 22 Sep 2010 12:52:50 -0400

> What I think is a standards matter is for me (a site owner) to be able
> tosecurely publish that my cert is 0x85829bce32 and that it is chained
> to 0x533422c23.
> If you get my cert and it looks like 0x123123123 and is chained to
> 0x343434334 you can still make whatever decision you like as it you
> trust 0x533422c23 and 0x343434334 (and anyone else), but knowing that
> the cert / TA you got isn't the one I intended you get seems like it
is
> important...

The site owner's concern should be limited to the EE key and CA key(s)
in the path.  The TA is up to the client.  The site owner can't know how
all client trust anchor stores are configured and need not.

---

From: [email-masked]
Date: Fri, 24 Sep 2010 16:46:00 +0000

> obtaining a certificate from a minimal assurance CA.

	i think that Warren stated the position that at the 
	end of DNSSEC validation, one might find a cert 0x345234123 
	and that it may (maynot) be chained to cert 0x987876765

	as a relying party (i can only assume this is the application
	at the source), given that I have validated, to my satisfaction,
	that the DNS lookup is complete, intact, and untampered with,
	what information can I derive from examining the CERT RR data?

	ie

	3) Tell relying parties that they MAY trust anchor = X  if/onlyif

		- they have other reasons to trust the data in the CERT
		- there is no other data on which to base trust
		- the data in the cert matches the domain its attached to
		- the chain points to a CA that the source trusts
		- some additional criteria that may come to mind

	I worry about things like dynamic update for DNS zones and the
	failure to match node information with what is handed to the DNS.
	e.g.  my laptop has the canonical name:  mew.rs.net.   If I get
	an evCERT from VSGN for that name and install it in the DNS
	as a cert RR, what happens when I go to {IETF} and they hand me
	an IP address and name... which does not match the canonical name?
	(no I dont allow random parties across the Internet to update my DNS
	zones).

--bill

---

From: [email-masked]
Date: Fri, 24 Sep 2010 16:52:48 +0000

> I still believe that this is very simple and easy to understand for implementors and users, but if someone express this even better please do.

	how do you recover from a botched dynamic update?

--bill

---

From: [email-masked]
Date: Sat, 25 Sep 2010 04:14:05 +0000

On Fri, Sep 24, 2010 at 07:41:41PM +0200, Jakob Schlyter wrote:
> On 24 sep 2010, at 18.52, [email-masked] wrote:
> 
> I'm not sure what you are referring to here Bill - could you please elaborate on the problem?
> 
> 	jakob
> 

	presume your laptop.  it has what you think of as its canonical name...

		owl.kirei.se.

	you run a secure web service on this node, so you went to the trouble of getting
	a cert for it... (the httpsd) .... and the cert identifies itself as belonging
	to  "owl.kirei.se."

	you stuff that cert into the cert RR in the kirei.se zone and sign it.  all is well.

	until you visit me in LA...

	in my broadcast domain, non-trusted nodes are dumped into a holding pool, where your
	access is constrained...  your node does a DHCP poll and my DHCP server hands you
	back an IP(v6) address which is pre-mapped to a well-known domain name.  Your node
	also gets my DNS servers to use, since we are closer than you remote ones.

	i -might- let the secure dynamic dns update through, that you send back to kirei.se
	to remap the new IP address that owl.kirei.se has... or I may block it. In no case am
	I going to let you update the local reverse map w/ your name.  You don't have the
	right credentials to update my DNS servers.

	you petition and I take your CERT and stuff it into the DNS ... but the local-name
	you have is:   

		kirei-se.gulag.rs.net.

	oops... the domain name (signed and validatable) returns a cert that claims to belong
	to  "owl.kirei.se".

	I suspect this operational concern will emerge and become problematic.  (in another
	thread, John L. raises a simialr concern).  

--bill

---

From: Tony Finch <[email-masked]>
Date: Mon, 27 Sep 2010 15:15:24 +0100

> CERT records that might be cached to expire.

Not if the CERT record refers to a certificate that signs the server
certificates.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Sep 2010 13:23:17 -0400

I agree to this and I agree that prefixing can help address some of these
issues as you point out in the next post.

Prefixing can also bite you in the butt as I have been finding out with some
offlist discussions that are causing me to rewrite parts of ESRV.

What I think we need to do here is to start from the maximal set of
requirements and look at how we might address all of them, rather than focus
on a few particular requirements and try to optimize a solution just for
those.

It is really hard to add crypto features and improve performance. The most
you can expect is not to harm performance.

But one of the things that I realized when I started to write ESRV was that
if you have the ability to express 'always use ssl' then you can also
express 'you can also use this more efficient protocol', where the
efficiency is coming from pulling the data from a closer server or using a
binary transport or whatever.

What is a bit harder to achieve is to optimize for the new without
negatively impacting the legacy approach.

ESRV currently uses prefixes because I thought this would be more
efficient.

Now I am looking at a model where the first DNS lookup for SMTP would be for
MX and unprefixed ESRV and the first lookup for everything else would be for
A/AAAA record and ESRV

That approach allows me to avoid any penalty when the DNS server does not
support ESRV and allows for the server that fully supports ESRV to
aggressively push out the full chain of responses needed as additional
resource records.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Sep 2010 13:23:17 -0400

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 25 Sep 2010 22:02:41 +0200

> 	oops... the domain name (signed and validatable) returns a cert that claims to belong

How would anyone start using that name, instead of my roaming name, to access the services on my laptop?

How is this situation resolved today?

Following the semantics in our draft, this would work just fine as long as gulag.rs.net is signed and I'm allowed to put my CERT record in there.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 24 Sep 2010 19:41:41 +0200

jakob

---

From: [email-masked]
Date: Wed, 29 Sep 2010 05:21:19 +0000

> How would anyone start using that name, instead of my roaming name, to access the services on my laptop?

	because its on your business card, in the Internet Archive, they have a local cached copy.
	and they have _no_ way to figure out that your roaming name has changed from owl.kirei.se
	to some randomly assigned name handed out by Bill Manning.  And no, I'm not going to 
	issue you a cert with the new name.

> How is this situation resolved today?

	we don't do service mobility well, if at all.  doing this type of security (identity
	assertion) really argues that there should exist a non-transient ID.  IP addressing
	is often used for this in some form of pragmatic use. (you can always find a root DNS
	server at  xxx.sss.bbb.www) - however the overloading of identity and location are
	a persistant problem.  Domain names _could_ be an invarient - and some cert constructs
	re-enforce this idea.  

> Following the semantics in our draft, this would work just fine as long as gulag.rs.net is signed and I'm allowed to put my CERT record in there.

	and what does your cert say about the node?  does it reflect the random name I may 
	assign it?   and i'm not sure I would let you do a dynamic update of the rs.net zone 
	so that is problematic as well.

	mobility is hard.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 29 Sep 2010 08:24:55 +0200

Bill,

I'm not what you are proposing not that this problem is something we should address.

If I cannot update my A record from your site I will loose, as no one will know my address (at your site). There is no reason anyone would suddenly use the hostname you assigned to me, but if they do you are correct in the sense that there will likely not exist a CERT record at that hostname - at least not one I control and everyone loose.

	jakob

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Sep 2010 12:05:01 +0100

On Wed, 29 Sep 2010, [email-masked] wrote:
>
> 	we don't do service mobility well, if at all.

Right, so it's a bit of a waste of time to argue that cert RRs don't work
with mobile services when mobile services don't exist.

Tony.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Sep 2010 18:12:28 -0400

> I'm not what you are proposing not that this problem is something we  

Yah, I'm having a hard time seeing how this would all fit together...

>
> If I cannot update my A record from your site I will loose, as no  
> one will know my address (at your site). There is no reason anyone  
> would suddenly use the hostname you assigned to me, but if they do  
> you are correct in the sense that there will likely not exist a CERT  
> record at that hostname - at least not one I control and everyone  
> loose.

Yup...

W

--
"Real children don't go hoppity-skip unless they are on drugs."

     -- Susan, the ultimate sensible governess (Terry Pratchett,  
Hogfather)