Subject: Re: [keyassure] Approaches for expressing root restrictions.

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Sep 2010 14:29:13 -0500 (GMT-05:00)

Phillip, Ilari, and all,

Yes Ilari's suggestion is seemingly an improvement from an operations view.

Here is still what bothers me:

1.) How does anyone know at any given point in time if any of the 'Trust Anchors'

are trustworthy?

2.) What definition that can be universaly excepted and expected for a

high assurance CA?

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Sep 22, 2010 10:59 AM
To: Ilari Liusvaara
Cc: Tony Finch , "[email-masked]" , Carl Wallace
Subject: Re: [keyassure] Approaches for expressing root restrictions.

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.

On Wed, Sep 22, 2010 at 11:50 AM, Ilari Liusvaara <[email-masked]> wrote:

On Tue, Sep 21, 2010 at 10:52:44PM -0400, Phillip Hallam-Baker wrote:
> There are two possible types of trust anchor publication:
>

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

> 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.

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

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

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Sep 2010 15:36:40 -0500 (GMT-05:00)

Phillip and all,

I read tony's concern as being one that self certifying certs are not acceptable and need

further 'Checking' before they can be trusted.  He has a good point there.  However how

is such a determination by a third party to be accurately or correctly made by whatever

third party, and what are the criterian explicitly that the 'checking third party' is itself

to be trusted?  From my experiance some of the larger or better known CA's are not IMO always

trustworthy and as such are disqualified as being able to be a third party by which other

CA's are to be evaluated.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Sep 21, 2010 7:24 PM
To: Tony Finch
Cc: "[email-masked]" , Carl Wallace
Subject: [keyassure] Approaches for expressing root restrictions.

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.

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Sep 2010 16:08:25 -0500 (GMT-05:00)

Phillip and all,

Yep, and as such poor Alice < in this possible/likely example > is discredited unjustifiably and

perhaps forever accordingly.  Any policy, standard, proposed of otherwise and/or practice that

would allow for this to occur is not rationably acceptable, IMO.

Nicely outlined BTW Phillip! >;)

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Sep 22, 2010 3:56 PM
To: Ilari Liusvaara
Cc: "Jeffrey A. Williams" , Jakob Schlyter , Tony Finch , "[email-masked]" , Carl Wallace
Subject: Re: [keyassure] Approaches for expressing root restrictions.

Under the hoffman et. al proposal, a client is expected to IGNORE the PKIX cert chain entirely if there is no corresponding CERT record. It is not actually stated in their draft, but that is what they claim to be proposing.

So let us consider what happens when Alice who is running one web server at www.example.com and has specified a cert record:

www.example.com    A 10.0.0.1

www.example.com    CERT TLSFP 0 0 <fp of cert1>

Her DNS records are signed every 4 hours with a 24 hour TTL. Note that this is on the aggressive side. Some people are proposing much longer signature validity. I know some people have periods of many days.

Now let us imagine that Alice decides she needs more processing power and deploys a second server and CERT record:

www.example.com    A [10.0.0.1  10.0.0.2] <i.e. round robin>

www.example.com    CERT TLSFP 0 0 <fp of cert1>

www.example.com    CERT TLSFP 0 0 <fp of cert2>

She updates her DNS, the new records are signed. Unfortunately for Alice she has just halved the probability that people can access her Web site and it will be 24 hours before the updates filter through the DNS.

Although some clients are going to pull the A record and CERT record in parallel, there is no guarantee that this is the case. In fact the majority of clients will only ask for the A record. It is thus very likely that the A record and the CERT record will end up with different cache expiry times.

So it is entirely possible that a client ends up receiving the following

www.example.com    A 10.0.0.2

www.example.com    A 10.0.0.1

www.example.com    CERT TLSFP 0 0 <fp of cert1>

And if the client chooses 10.0.0.2, the cached value of the CERT record is going to cause them to reject the perfectly good certificate.

The only way that Alice can avoid this race condition is to plan her Web server deployment so that she publishes her CERT records a signature expiry interval before her A records. In other words a single administrative update has just become two updates with a time delay between.

Now there are assumptions that could be made as to how DNS caches should work and you can assume that if one record expires at a node then all of them will, but that is not what happens in the real world.

Another very common use case that will lead to race conditions is when Alice has to install an updated certificate.

What Alice would normally do is to install the cert in the right location, edit her config files and tell her server to start using the new cert. That is one single procedure.

What you are asking her to do to in the TLSFP world is to update her CERT record, wait 24 hours (or longer if thats her expiry interval) and only then update her server cert. So one administrative task has become two and there is a far greater chance that it is going to be botched.

Quite often a customer will only come for their replacement cert after their original one has already expired. So now Alice has to explain that the Web site is going to be out of order for 24 hours.

Using self-signed certs does not change the race condition issue at all. All that it does is to ensure that Alice has no customer support rep to talk to.

Now CAs could in theory develop tools to warn the user that they have deployed TLSFP records and these might cause issues. But I really can't see CAs wanting to lend the idea any more credibility. Most customer support reps are going to tell the customer to shut TLSFP off completely and some will probably advise shutting off DNSSEC.

This group should not and cannot create a customer service meltdown with a flawed protocol.

I am somewhat more sympathetic to IIari's proposal of allowing the CERT records to be used to authenticate any cert in the chain, but that approach would still cause problems.

On Wed, Sep 22, 2010 at 4:17 PM, Ilari Liusvaara <[email-masked]> wrote:

<Snip almost unreadable HTML mess>

Some of the points raised there... Sorry, I can't parse who said what.

Well, what trust anchor is trustworthy is up to the client. The client might
require chaining to some set of trust roots (regardless of CERT records), or
it might trust all CERT records that are properly signed.

Regarding bringing up new webserver... Presumably this webserver has its own
name, so one only takes the negative caching time. And if it is truly new,
you have to take that anyway for A/AAAA records... So bringing up new hostname
with webserver is just as fast as before from DNS perspective.

Also, certificate changes are usually predictable beforehand. Pretty much the
only exception is if certificate gets compromised.

-Ilari

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Sep 2010 16:23:49 -0500 (GMT-05:00)

Paul and all,

  Well isn't what the draft says/as you indicated, essentially 
saying the same thing as what Phillip articulated however differently 
parsed?

  Also and still, what is, or how is/are 'usable certificate
associations' to be explicitly understood or determined as part
of the draft?  Too much linguistic semantics here IMHO...

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Sep 22, 2010 4:07 PM
>To: Phillip Hallam-Baker <[email-masked]>, Ilari Liusvaara <[email-masked]>
>Cc: Tony Finch <[email-masked]>, "[email-masked]" <[email-masked]>, Carl Wallace <[email-masked]>
>At 4:56 PM -0400 9/22/10, Phillip Hallam-Baker wrote:
>>Under the hoffman et. al proposal, a client is expected to IGNORE the PKIX cert chain entirely if there is no corresponding CERT record.
>
>Wrong.
>
>>It is not actually stated in their draft, but that is what they claim to be proposing.
>
>Wrong. The draft says:
>   If the application receives zero usable
>   certificate associations, it process TLS in the normal fashion.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 23 Sep 2010 15:30:34 -0500 (GMT-05:00)

Warren and all,

  Good points and I agree with most of them.  BUT, many of these
decisions are not likely to be Alice'es necessarly.  So we need to
make this 'stupid proof' to the extent possible accordingly.

-----Original Message-----
>From: Warren Kumari <[email-masked]>
>Sent: Sep 22, 2010 5:57 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: Tony Finch <[email-masked]>, Carl Wallace <[email-masked]>, "[email-masked]" <[email-masked]>
>On Sep 22, 2010, at 4:56 PM, Phillip Hallam-Baker wrote:
>
>Signature validity != RR TTL....
>
>> 
>> 
>Sorry, no, you are incorrect... 
>Alice could have chosen a shorter TTL on her CERT RR, she could have pre-generated and pre-published additional CERT records, ready for such an occurrence, or she could have used the same cert on 10.0.0.1, 10.0.0.2 (as is what she is probably doing now anyway)... Just because it is possible to design a system where someone can shoot themselves in the foot if they are sufficiently stupid doesn't mean the system is bad. Alice already has multiple ways to screw herself with DNS / DNSSEC, this is just another place were folk have to pay a bit of attention....
>
>> 
>> 
>> Now there are assumptions that could be made as to how DNS caches should work and you can assume that if one record expires at a node then all of them will,
>
>Um, who would be assuming that?... 
>
>> but that is not what happens in the real world.
>> 
>> 
>Once agin, you are assuming that Alice has chosen 24hours as the TTL for her records --- if she has chosen to do stupid things, there is no helping her. She has exactly the same problem if she wants to suddenly move hosting providers because her current one has burn to the ground, her webserver dropped a drive, the ISP is getting DoSed, etc. If people want to have a reliable service they have to plan a little... 
>
>In the DNSSEC works there are a variety of interesting ways to screw up -- if Alice had allowed her KZK / ZSK to expire, if she had bothed rollover, etc etc etc she would also be in a world of hurt. I'm sorry, but you need to have big boy pants on if you want to play... 
>
>
>> 
>> Using self-signed certs does not change the race condition issue at all.
>
>Well, it could be argued that Alice can now generate a cert that is valid for longer, and so doesn't need to roll it as often ;-)
>
>But, once again, if folk are sufficiently stupid they will find all sorts of interesting ways to mess up...
>
>> All that it does is to ensure that Alice has no customer support rep to talk to. 
>
>That is Alice's choice -- if she wanted a customer support rep she could have paid someone for this service. 
>
>> 
>Wow... I'm sorry, I thought that you were trying to demonstrate that customer support is a useful service / feature for Alice.... If "shut off DNSSEC" is the sort of advice she gets she may have been better off without it...
>
>> 
>These are DNS records, and follow the same rules and logic that other DNS records follow -- are you currently experiencing customer service meltdowns with folk calling up and saying "I configured the wrong IP in my A record and now traffic isn't reaching my webserver. Please fix this by reissuing my cert..."? 
>
>Perhaps a script for your CS reps that says:
>Conditions:
>1: Customer published TLSFP.
>2: Customer chose pathological TTLs.
>3: Customer somehow inserted the wrong TLSFP info.
>4: The rest of Customers DNS / network is fine.
>
>Response:
>"I'm sorry sir, you have chosen to publish *in the DNS* information that is not correct. This happens to be CERT data, it could just have easily been MX / A / <a whole selection of other RRs>. You will have to wait XXX for this information to time out of caches. 
>
>Did I mention that we are a company that REALLY REALLY understands crypto and hard things like key management, just like you need for DNSSEC? We also have a brilliant new product offering where we can do this DNSSEC thing for you, keep the keying material safe, publish DS records, handle key rollover, sign your RRs, etc. It's only $49.95 per month, or $44.95 if you have an EV cert from us...  If you had signed up for this service last week you wouldn't be in this mess now... 
>
>Great, thank you... A Visa you say... Lemme just read that back to you and make sure I have the number right... And it expires when? Excellent, thank you sir..."
>
>(I'm only 1/2 joking...).
>
>Yes, it is easy to design all sort of scenarios where poor Alice or Bob manage to make their lives unpleasant by doing stupid things, but many of them end up being FUD.
>
>W
>
>

Regards,
Jeffrey A. Williams