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

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

Phillip and all,

I agree.  What Jakob is essentially saying doesn't firm up in the wild right now but

I also can understand the desire that there be a somehow confirmed means or method

by which only known hashes be considered 'Trustable'...

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

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

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.

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.

--
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: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Sep 2010 23:17:46 +0300

<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

---

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

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.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Sep 2010 14:07:44 -0700

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

---

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

On 22 sep 2010, at 22.56, 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. It is not actually stated in their draft, but that is what they claim to be proposing.

The draft currently says:

   An application that requests TLS certificate associations using the
   method described in the previous section obtains zero or more usable
   certificate associations.  If the application receives zero usable
   certificate associations, it process TLS in the normal fashion.

   If a match between the certificate association(s) and the server's
   end entity certificate in TLS is not found, the TLS client MUST abort
   the handshake with an "access_denied" error.

If this is not clear enough, we might need to improve this text.

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

The situation your are describing is the very same one Alice would have when deploying new SSH host keys and publish them using DNS, something that we have experience with since 2006.  We should keep in mind that any changes to DNS requires careful planning and using DNS for key assurance does not change that and neither does DNSSEC in general.

IMHO, describing pathological examples of how things could go wrong if you mismanage your DNS service and/or your certificates does not move this discussion forward.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Sep 2010 17:21:34 -0400

I agree that it is wrong.

But the reason that we are having this discussion is that some of your
collaborators want to express semantics of the form 'must use EV' and they
state that they have written code that does not process the TLS chain if a
cert record is found but no matching FP.

I absolutely agree about the importance of the use case that is motivating
this. Where we apparently disagree is whether this should be part of the key
assurance mechanism or a separate policy mechanism (e.g. the ESRV proposal
made by Brian and myself).

On Wed, Sep 22, 2010 at 5:07 PM, Paul Hoffman <[email-masked]> wrote:

> cert chain entirely if there is no corresponding CERT record.
>
> Wrong.
>

---

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

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

>
> IMHO, describing pathological examples of how things could go wrong if you
> mismanage your DNS service and/or your certificates does not move this
> discussion forward.
>

In my view looking at how things can go wrong is precisely what a security
spec should be doing.

If this was accepted as a standard people would be getting fired for
deploying it.

Think about it, that tends to delay deployment in my experience. Getting
people to deploy security is hard enough at the best of times.

SSH is not usually a mission-critical service. It may be required to
maintain mission critical services, it is not critical in itself and the end
user is expected to be able to do the necessary steps to make it work - such
as flush their DNS cache if necessary.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Sep 2010 14:29:29 -0700

>I agree that it is wrong.

Good!

>But the reason that we are having this discussion is that some of your collaborators want to express semantics of the form 'must use EV' and they state that they have written code that does not process the TLS chain if a cert record is found but no matching FP.

I have just looked through the archives, and I do not see any such assertion from my collaborators. Instead of you speaking for them, it would be more useful to paste a copy of the message you think says this.

--Paul Hoffman, Director
--VPN Consortium

---

From: Warren Kumari <[email-masked]>
Date: Wed, 22 Sep 2010 18:57:43 -0400

On Sep 22, 2010, at 4:56 PM, Phillip Hallam-Baker wrote:

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

Signature validity != RR TTL....

> 
> 
> Now let us imagine that Alice decides she needs more processing power and deploys a second server and CERT record:
> 
> 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.
> 
> 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.

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

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. 

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

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

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

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

> 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:
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Sep 2010 19:58:46 -0400

On Wed, Sep 22, 2010 at 6:57 PM, Warren Kumari <[email-masked]> wrote:

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

Nobody can say with any confidence that they know all the possible ways to
screw up with original DNSSSEC.

I would not be so cavalier about adding to them.

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

Or, protocol designers have to do their job and design protocols that are
robust.

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

Why, what has it managed to do for the customer except DoS their site?

People deploy certificates on their sites so that they can sell stuff. They
pay more for EV certs because they increase the amount of stuff they can
sell. If there is the slightest risk that a security measure is going to
harm site availability they are not going to use 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..."?
>
> "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.
>

That is not a message that any customer support rep is going to give.

The message I would give them is:

"Unfortunately you have used the TLSFP certificate type. We have previously
issued a warning to our customers that they should not use the TLSFP cert
type in any circumstances and should instead use the ESRV and ASSERT
mechanism that do not cause the problems that you are facing."

And I would imagine most other security providers would follow the same
script.

If you want to have these semantics for your type then we need two separate
sets of records, one for key assertions and one for key assertions that are
also restrictions.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 23 Sep 2010 08:40:36 +0200

On 23 sep 2010, at 01.58, Phillip Hallam-Baker wrote:

> Or, protocol designers have to do their job and design protocols that are robust.

I believe the same set of problems applies to other protocols as well. E.g., if you start signing your email with a DKIM key that is not yet published in the DNS (and your ADSP says "discard") or if your SPF records refers to MX and your MX record TTL is misaligned with your TXT record TTL, a lot of things will go bad all because of an out of sync DNS.

If you want to rely on DNS for publishing this type of information, you need to plan ahead and do it right. If you can't do that (and you can't hire someone do to it for you), you are free to use some other means of assurance.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Sep 2010 08:02:41 -0400

OK, first for the benefit of Paul, by cert restriction semantics, I mean the
feature by which presence of a CERT record means that only certificates that
match the specified fingerprint are to be accepted.

What I am objecting to is the fact that

1)  Some people are going to want to have key assurance semantics without
the cert restriction semantics.

Proposal: Either separate certificate types for key assurance with and
without cert restriction semantics, or better, have one record for
expressing key assurance and a separate record for expressing all types of
security policy, including cert restriction semantics.

This is not something that I can accept as being a sub-field encoding. It
has to be possible for someone to read the master zone and immediately see
that key restriction semantics are being declared.

2) If people do want the cert restriction semantics then they have to be
clearly and explicitly called out as the purpose of the certificate type. It
should be specified explicitly in the WG charter, in the abstract and
introduction of the draft.

Not only do none of the materials make this intention clear. It took a
considerable amount of digging to find out that this was the intention.

Proposal: Specify cert restriction clearly in the WG charter. Authors who
wish to propose such semantics make it clear that this is their intention.

3) If the IETF is going to support expression of cert restriction semantics
in the DNS, this should not require them to use mechanisms that support
their existing PKIX infrastructure. They should be able to express the cert
restriction without having to deploy a new mechanism for assuring end-entity
certs

Proposal: The charter require the WG to come to consensus with both the PKIX
and TLS working groups before any proposal that causes otherwise valid and
acceptable PKIX cert chains is adopted as a WG item or published as a
proposed standard.

I will in any case be raising these issues in both forums in advance of
Beijing.

Note that the criteria for both formation of a Working Group and adoption of
a Proposed Standard is IETF Consensus, not Working Group Consensus.

Here we have a proposal that the authors intend to use to override semantics
for PKIX certificates.

On Thu, Sep 23, 2010 at 2:40 AM, Jakob Schlyter <[email-masked]> wrote:

> I believe the same set of problems applies to other protocols as well.
> E.g., if you start signing your email with a DKIM key that is not yet
> published in the DNS (and your ADSP says "discard") or if your SPF records
> refers to MX and your MX record TTL is misaligned with your TXT record TTL,
> a lot of things will go bad all because of an out of sync DNS.
>
> If you want to rely on DNS for publishing this type of information, you
> need to plan ahead and do it right. If you can't do that (and you can't hire
> someone do to it for you), you are free to use some other means of
> assurance.
>
>
>        jakob
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Sep 2010 08:47:06 -0700

At 8:02 AM -0400 9/23/10, Phillip Hallam-Baker wrote:
>OK, first for the benefit of Paul, by cert restriction semantics, I mean the feature by which presence of a CERT record means that only certificates that match the specified fingerprint are to be accepted.

As I said to Phill offline, I think a better term for what we are proposing is "enumeration of certificates usable for authentication". "Restriction" is definitely too vague.

>1)  Some people are going to want to have key assurance semantics without the cert restriction semantics.
>
>Proposal: Either separate certificate types for key assurance with and without cert restriction semantics, or better, have one record for expressing key assurance and a separate record for expressing all types of security policy, including cert restriction semantics.

But you have not defined "key assurance" there, and people's attempts yesterday to get you to clarify were not answered. Let me offer what I think you mean, and if I'm wrong, please correct me. I think you mean "a key that is part of a certificate that chains to this trust anchor". If so, a much clearer parallel construct to what I said above about our proposal would be "enumeration of PKIX trust anchors usable for authentication". Does that work for you?

>This is not something that I can accept as being a sub-field encoding. It has to be possible for someone to read the master zone and immediately see that key restriction semantics are being declared.

It is a tad early in the process to say what you can and cannot accept.

>2) If people do want the cert restriction semantics then they have to be clearly and explicitly called out as the purpose of the certificate type. It should be specified explicitly in the WG charter, in the abstract and introduction of the draft.
>
>Not only do none of the materials make this intention clear. It took a considerable amount of digging to find out that this was the intention.
>
>Proposal: Specify cert restriction clearly in the WG charter. Authors who wish to propose such semantics make it clear that this is their intention.

That works for me, as long as we use clearer wording than "cert restriction".

>3) If the IETF is going to support expression of cert restriction semantics in the DNS, this should not require them to use mechanisms that support their existing PKIX infrastructure. They should be able to express the cert restriction without having to deploy a new mechanism for assuring end-entity certs

This seems like a new proposal, and it is not worded in a way that I can understand. Are you saying that the mechanisms for "enumeration of certificates usable for authentication" and "enumeration of PKIX trust anchors usable for authentication" need not be deployed at the same time? If so, that seems reasonable to add to charter.

>Proposal: The charter require the WG to come to consensus with both the PKIX and TLS working groups before any proposal that causes otherwise valid and acceptable PKIX cert chains is adopted as a WG item or published as a proposed standard.

This is rare in the IETF. Can you point to other WG charters that have such hard linkages? The ones I am familiar with say "must work with" and so on.

>I will in any case be raising these issues in both forums in advance of Beijing.
>
>
>Note that the criteria for both formation of a Working Group and adoption of a Proposed Standard is IETF Consensus, not Working Group Consensus.

That seems obvious, because there is no Working Group yet.

>Here we have a proposal that the authors intend to use to override semantics for PKIX certificates.

And there you go off the deep end again. The proposal deals with whether or not a certificate that is presented in TLS needs to be validated. Not validating a certificate does not override the certificate's PKIX semantics: it ignores them. Validating the cert (which is fully allowed, and sometimes encouraged, by our proposal) certainly does not override any PKIX semantics.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Sep 2010 16:55:54 -0400

On Thu, Sep 23, 2010 at 11:47 AM, Paul Hoffman <[email-masked]>wrote:

>
> As I said to Phill offline, I think a better term for what we are proposing
> is "enumeration of certificates usable for authentication". "Restriction" is
> definitely too vague.

Enumeration is one specific mechanism for the requirement of expressing
restrictions.

And no, telling people to ignore valid certs is not a minor issue you can
lump in with assurance.

> But you have not defined "key assurance" there, and people's attempts
> yesterday to get you to clarify were not answered.

My constant requests for some clarity from you have gone unanswered from the
start. Instead of answering them you demand explanations for terms where no
real ambiguity arises.

Assure means to tell people that they can trust something. So key assurance
means telling people they can trust the key.

Key assurance does not imply any statement about what keys should not be
trusted, must not be trusted or can be ignored. Key assurance in my view
only means providing additional ways to trust a certificate.

Unfortunately, we cannot use the term 'assurance' at all. In US legal
terminology it is a synonym for insurance and use is regulated by statute. I
only realized that this morning while driving.

> Let me offer what I think you mean, and if I'm wrong, please correct me. I
> think you mean "a key that is part of a certificate that chains to this
> trust anchor". If so, a much clearer parallel construct to what I said above
> about our proposal would be "enumeration of PKIX trust anchors usable for
> authentication". Does that work for you?

No, I have no idea what you mean there.

My proposal is to separate out:

* Statements that provide additional and independent ways to establish keys
as trustworthy

* Statements that change processing of certificates that would otherwise be
considered to have a valid PKIX certificate path, including but not limited
to revoking, ignoring, invalidating, exorcising or any other synonym.

> It is a tad early in the process to say what you can and cannot accept.

Not really, we have a draft that is very close to being ready for trial
deployment for the purpose of providing and independent ways to establish
keys as trustworthy. We are down to arguing over the placement of one bit
and a minor style point on bit packaging.

Since we have multiple certificate type codes it seems fairly obvious to me
that there should be separate codes for assertions that are independent of
PKIX processing rules and those that tell people to 'ignore' them.

> >3) If the IETF is going to support expression of cert restriction
> semantics in the DNS, this should not require them to use mechanisms that
> support their existing PKIX infrastructure. They should be able to express
> the cert restriction without having to deploy a new mechanism for assuring
> end-entity certs
>
> This seems like a new proposal, and it is not worded in a way that I can
> understand. Are you saying that the mechanisms for "enumeration of
> certificates usable for authentication" and "enumeration of PKIX trust
> anchors usable for authentication" need not be deployed at the same time? If
> so, that seems reasonable to add to charter.

OK

> >Proposal: The charter require the WG to come to consensus with both the
> PKIX and TLS working groups before any proposal that causes otherwise valid
> and acceptable PKIX cert chains is adopted as a WG item or published as a
> proposed standard.
>
> This is rare in the IETF. Can you point to other WG charters that have such
> hard linkages? The ones I am familiar with say "must work with" and so on.

I can't think of a time when an established WG has allowed another WG to be
established that would affect the semantics of their protocol.

> And there you go off the deep end again. The proposal deals with whether or
> not a certificate that is presented in TLS needs to be validated. Not
> validating a certificate does not override the certificate's PKIX semantics:
> it ignores them. Validating the cert (which is fully allowed, and sometimes
> encouraged, by our proposal) certainly does not override any PKIX semantics.
>
>
Whenever you use a phrase like that a completely ridiculous claim follows.

Ignoring a valid cert chain is not changing the semantics?

"I didn't run the red light officer, I was ignoring it"
"I didn't prevent the man from voting, I was ignoring him"

Of course this is a big deal. That is why I want to do it.

The difference is that I want to address this problem explicitly and do the
job right and you seem to want to do it as a side effect of a completely
different scheme.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 25 Sep 2010 05:40:00 -0700

> acceptable PKIX cert chains is adopted as a WG item or published as a

What? What business of PKIX is it if I decide to deploy a cert that is
certified in a different way? We are not proposing to modify the PKIX
mechanisms, we are proposing a new mechanism. Anyone who wants the
existing PKIX rules can have that trivially, by not publishing
anything new in the DNS.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Sep 2010 12:31:26 -0400

If it is a PKIX cert and you are specifying mechanisms to circumvent PKIX
path processing, you are changing their spec and affecting interoperability.

Given that Google is a member of CA-Browser forum and this is intended to
change EV validation semantics, you should also at least tell the forum that
you have made this proposal and what the implications are.

On Sat, Sep 25, 2010 at 8:40 AM, Ben Laurie <[email-masked]> wrote:

> semantics
> PKIX

---

From: Ben Laurie <[email-masked]>
Date: Sat, 25 Sep 2010 09:41:17 -0700

> you have made this proposal and what the implications are.

It seems to me that there are three cases that should perhaps be
considered separately:

1. self-signed certificates: no damage can be done to these by
introducing dnssec validation, since currently they are not validated
at all.

2. DV certs. I am pretty happy to claim that these are also made no
worse off and, in fact, are (possibly only marginally) improved by the
addition of dnssec as an alternate validation path.

3. EV certs: can of worms. I am not sure how best to proceed with
these, but it seems complex.

Would it make sense to treat DV+self-signed as completely independent of EV?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Sep 2010 16:20:55 -0400

I am perfectly happy to have a mechanism to use the DNS with DNSSEC to
provide an additional and independent mechanism for binding keys to a domain
name.

I am also happy to have a mechanism to specify statements like 'must use
SSL' and 'must have a cert with characteristic X'.

What I am really unhappy about is joining the two mechanisms together. And I
am really really unhappy about the idea that I can only use DNS based
assurance if it is going to over-ride existing PKIX semantics.

One reason for this is that I have been thinking about ways to automate the
whole process of managing keys.

We are talking here about TLS as if it was a single protocol. But TLS can be
used with any application protocol. So what if the mail server wants to use
a DNSSEC validated cert and but the Web server does not?

I would like the authors of Sendmail and similar to be able to add code to
their programs so that they will automatically generate, install and manage
the necessary DNS records.

That can't happen if there is any possibility that an action on the part of
the sendmail installer program could affect the Web server use of SSL or
affect any other program.

On Sat, Sep 25, 2010 at 4:06 PM, Jakob Schlyter <[email-masked]> wrote:

> On 25 sep 2010, at 18.41, Ben Laurie wrote:
>
> I agree.
> Likewise.
> IMHO, if the TLS client wants honor the EV status, it needs to perform full
> PKIX validation. If it does not care about EV it can choose to accept the
> cert as it would have done with any other cert.
>
>
>        jakob
>
>

---

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

> Would it make sense to treat DV+self-signed as completely independent of EV?

No, because EV has the same built-in race to the bottom as 1990s PKIX
certs. In five or ten years time any decision to treat them differently
will look silly.

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: Tony Finch <[email-masked]>
Date: Mon, 27 Sep 2010 15:33:56 +0100

> a DNSSEC validated cert and but the Web server does not?

Give the CERT records a _service name prefix like SRV records.

Tony.

---

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

I agree.

Likewise.

> these, but it seems complex.

IMHO, if the TLS client wants honor the EV status, it needs to perform full PKIX validation. If it does not care about EV it can choose to accept the cert as it would have done with any other cert.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 27 Sep 2010 16:39:31 +0200

> Give the CERT records a _service name prefix like SRV records.

Or put the CERT records at the (RDATA) name of the SRV record.

Even though it is possible to call both the mail- and web-server www.example.com - if you want to use different certs for those services; don't do that.

	jakob