Subject: [keyassure] An interesting twist

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 14:34:57 -0400

While writing I came across a very interesting little twist on this problem.

RFC4396 does not specify any semantics for the certificate binding. Nor does
it need to since the certificate is a self authenticating object and does
not require any additional verification.

What that means is that it is not possible to redefine the semantics for the
use of this mechanism for key assurance.
In other words it is not possible to make any conclusion from the presence
of:

example.com CERT PKIX 76 5 <evil cert>
<signature>

In order to infer that the domain owner intended to assert that the
certificate was to be used as a key for the domain it is absolutely
necessary to use a new algorithm type.

In other words, even if the certificate is NOT being transported in the
channel it is obligatory to have an assurance record, ie you need to have:

example.com CERT PKIX 76 5 <cert>
example.com CERT DPKIX 0 2 <SHA256 (<cert>)>
<signature>

This distinction had not occurred to me earlier on when we were talking
about everything being prefixed.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 9 Sep 2010 11:44:36 -0700

On Sep 9, 2010, at 11:34 AM, Phillip Hallam-Baker wrote:

> RFC4396 does not specify any semantics for the certificate binding. Nor does it need to since the certificate is a self authenticating object and does not require any additional verification.
> 
> What that means is that it is not possible to redefine the semantics for the use of this mechanism for key assurance.
> In other words it is not possible to make any conclusion from the presence of:
> 
> In order to infer that the domain owner intended to assert that the certificate was to be used as a key for the domain it is absolutely necessary to use a new algorithm type. 

I don't quite get why?  

The CERT RR does't carry the real assurance, its the corresponding RRSIG record for the CERT record that carries the assurance, no?

This is why I believe what's needed is APIs: a way for the application to know about the RRSIG records and whether they validate from an application specified (or default set) root of trust.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 15:13:49 -0400

On Thu, Sep 09, 2010 at 11:44:36AM -0700, Nicholas Weaver wrote:

> The CERT RR does't carry the real assurance, its the corresponding
> RRSIG record for the CERT record that carries the assurance, no?

Exactly.  This is why DNSSEC is important.  Obviously, some random
CERT RR without any evidence that it was legit would be bad.

> This is why I believe what's needed is APIs: a way for the
> application to know about the RRSIG records and whether they
> validate from an application specified (or default set) root of
> trust.

Fully agree.  BTW, SPARTA/Cobham has a proposed API, which is part of libval:

    http://www.dnssec-tools.org/download/

I don't know whether it's the right answer.  But it is an answert that
is available.  (I can think of others.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 15:28:34 -0400

The point here is that CERT(PKIX) + DNSSEC on its own is not enough.

The way that 4398 is written means that putting a cert in the DNS
using the cert types they specifies does not and cannot establish an
assertion that the cert should be used for that domain.

4398 is a mechanism for throwing certs at people. It does not specify
any restrictions on the certs involved or how to use them. It would be
entirely OK according to 4398 to go to example.com and pull Mallet's
self-signed cert.

What this means is that since 4398 does not specify processing rules
we have to make sure that we do.

On Thu, Sep 9, 2010 at 3:13 PM, Andrew Sullivan <[email-masked]> wrote:
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 16:13:15 -0400

> The point here is that CERT(PKIX) + DNSSEC on its own is not enough.

Uh, duh?  I thought that's what we were here to address?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 17:12:32 -0400

My point is that we are changing the semantics of the CERT record in what
some might consider a pretty radical fashion.

We have to be very precise about the fact that we can only add semantics to
the new code points we define and that the assurance characteristics we are
creating ONLY apply to those certificate types and not to other certificate
types even if they are signed with DNSSEC.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 9 Sep 2010 14:26:29 -0700

> assertion that the cert should be used for that domain.

Um, I am confused -- please drive slow...

Are you speaking to " 3.  Appropriate Owner Names for CERT RRs" and the fact that it only *recommends* that the CERT RR is stored under the domain related to their subject  and:

  1.  If a domain name is included in the identification in the
       certificate or CRL, that ought to be used.

but that that isn't a hard and fast requirement? 

And what is the attack here? An attacker would publish a cert under boop.foo.com and have the subject be wurble.net?

Just trying to understand the issue here...

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 20:22:35 -0400

The main practical import of this is that it is not possible to just
throw out a couple of new CERT certificate types and rely on the text
describing the binding in 4398 because it isn't actually there.

If CERT records were being used on any significant scale this would be
a major problem as we would be redefining the semantics of running
security code.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 9 Sep 2010 17:27:26 -0700

> a major problem as we would be redefining the semantics of running

I still don't get your point:  The problem is APIs and usages: there IS no running code relying on CERT RRs with DNSSEC signatures for anything.  So there is no 'redefining the semantics going on'

And thus by providing an API and usage convention, you get what you need.  

And both of these are required regardless of the RR type being protected, so its not like doing FUBARCERT would be any different a problem: we need to define APIs where applications can get meaningful information about the CERT record and the associated RRSIG, and conventions for how to include meaningful CERT RRs in DNS and how the associated RRSIGs should be treated.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Sep 2010 17:50:05 -0700

>describing the binding in 4398 because it isn't actually there.

Correct. Fortunately, no one has done that.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Sat, 11 Sep 2010 01:01:37 +0000

> is available.  (I can think of others.)

	the original API ideas were discussed in a series of workshops
	circa 2005.  http://www.rs.net/rva/index.html

--bill

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 13 Sep 2010 14:12:47 +0200

> types even if they are signed with DNSSEC.

Right.  I believe that should be fairly obvious: if you introduce a new
CERT sub-type, you get to chose what semantics it should have.  That
choice has no bearing whatsoever on other CERT sub-types.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Sep 2010 20:53:50 -0400

OK, so now the consequence.

I already have a proposal for two new CERT certificate types DPKIX and DPTR
as specified in my draft.

According to my current draft a party that wanted to achieve assurance for a
certificate distributed through a DNS CERT record would also have to publish
a complimentary DPKIX record alongside it to provide the assurance.

My question is whether this is acceptable or should we define a third new
certificate type to cover this particular option?

On the plus side this makes the draft a little bit more idiot proof and
makes it less likely that we have to explain this all again in the Security
Area. On the minus side it is more to write.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Sep 2010 08:43:19 -0700

At 8:53 PM -0400 9/13/10, Phillip Hallam-Baker wrote:
>I already have a proposal for two new CERT certificate types DPKIX and DPTR as specified in my draft.
>
>According to my current draft a party that wanted to achieve assurance for a certificate distributed through a DNS CERT record would also have to publish a complimentary DPKIX record alongside it to provide the assurance.
>
>My question is whether this is acceptable or should we define a third new certificate type to cover this particular option?
>
>
>On the plus side this makes the draft a little bit more idiot proof and makes it less likely that we have to explain this all again in the Security Area. On the minus side it is more to write.

With all due respect, it is impossible to determine the answer to your question until your draft has all of the security semantics filled in, not TBD. Please complete a -01 so we can understand what you are actually proposing, not just the on-the-wire formats.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Sep 2010 12:05:13 -0400

> With all due respect, it is impossible to determine the answer to your question until your draft has all of the security semantics filled in, not TBD. Please complete a -01 so we can understand wha…

I agree.  As I already mentioned, I am finding it hard to work out the
details from sketchy mails to the list.  If there are decision points
in the draft, list them in as complete detail as you understand them
now, and then one can look at those and attempt to draw some
conclusions.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Sep 2010 19:28:48 +0200

> Area. On the minus side it is more to write.

I believe that as far as the general CERT record goes, you can chose any
approach you want for the sub-types.  It is up to your document to
describe how each sub-type the document defines is to be used.

I don't immediately see what benefit there is in your approach compared
to draft-josefsson-keyassure-tls-00 though?

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 13:32:06 -0400

The issue is fairly simple. I really don't see how more words clarifies
matters.

We can only provide an assurance by defining a new cert type

At the moment we have a PKIX cert type for the raw cert data but it does not
provide an assurance. Therefore if people want to express an assurance for
raw cert data we need to define a second cert type for PKIX cert data which
asserts an assurance.

Do we think that there is going to be sufficient demand for raw cert data in
the DNS to define the second PKIX record or should we define it anyway to
avoid confusion?

On Tue, Sep 14, 2010 at 11:43 AM, Paul Hoffman <[email-masked]>wrote:

> >According to my current draft a party that wanted to achieve assurance for
> a certificate distributed through a DNS CERT record would also have to
> publish a complimentary DPKIX record alongside it to provide the assurance.
> >
> With all due respect, it is impossible to determine the answer to your
> question until your draft has all of the security semantics filled in, not
> TBD. Please complete a -01 so we can understand what you are actually
> proposing, not just the on-the-wire formats.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Sep 2010 19:35:05 +0200

> raw cert data we need to define a second cert type for PKIX cert data which

What do you mean by 'assurance' here?  As far as I understand, any
assurance comes from DNSSEC so adding another CERT sub-type does nothing
to improve assurance.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Sep 2010 11:10:33 -0700

At 1:32 PM -0400 9/14/10, Phillip Hallam-Baker wrote:
>The issue is fairly simple. I really don't see how more words clarifies matters.

The fact that you don't see that is the root of the problem. I haven't seen anyone who agrees with you, however.

>We can only provide an assurance by defining a new cert type

That is demonstrably false. We can redefine the semantics of current cert types if we want. It would be stupid to do so, but it is allowed.

>At the moment we have a PKIX cert type for the raw cert data but it does not provide an assurance.

That too is demonstrably false. Receiving the PKIX cert type in a DNSSEC-protected transaction assures the recipient that it came from the DNS operator of the host name in question. It does not assure the user of any additional semantics, which is what I hope you meant, but because you "really don't see how more words clarifies matters", I cannot be sure.

Please consider not posing questions like these until you have a complete Internet Draft ready.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 14:45:11 -0400

Paul,

You are not the working group chair here and you are really not adding value
by sniping and snarking at everyone who makes contributions that you do not
immediately understand.

This is a complex and subtle problem and some people here are attempting to
get a handle on those issues.

You are not going to convince the ADs that the subject matter is understood
with these attempts to suppress and close down any discussion that you fear
might raise the possibility of doubt.

I would really like to avoid another fiasco like the DNSEXT NXT/NSEC record
which could have been fixed in a few weeks if people had actually allow the
issues to be discussed. Instead it dragged on for eight years because people
thought that nothing should happen until they understood everything.

I am pretty sure that you understood the question and could answer it if you
choose to. And I am pretty sure that would be much easier than trying to
start another of your flame wars.

Given the state of your own draft, I really do not think you have standing
to badger others to explain themselves in greater detail.

My approach to writing specs is to understand the problem first.

On Tue, Sep 14, 2010 at 2:10 PM, Paul Hoffman <[email-masked]> wrote:

> That is demonstrably false. We can redefine the semantics of current cert
> types if we want. It would be stupid to do so, but it is allowed.
>
> That too is demonstrably false. Receiving the PKIX cert type in a
> DNSSEC-protected transaction assures the recipient that it came from the DNS
> operator of the host name in question. It does not assure the user of any
> additional semantics, which is what I hope you meant, but because you
> "really don't see how more words clarifies matters", I cannot be sure.
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Sep 2010 14:59:08 -0400

> thought that nothing should happen until they understood everything.

As I've suggested before -- perhaps more kindly than this last time --
I do not see what various WGs' histories have to do with the current
problem.  Part of the reason I am increasingly just giving up on
ploughing through your snide and condescending emails is because half
of them are completely irrelevant _ad hominem_ passages like the
above.  There's no reason for you to behave like a sulking child.
You're asking for others' time and consideration of your point of
view, so the least you can do is avoid needlessly insulting people who
aren't even here to defend themselves -- not that we want to spend the
next month in that rathole.

> My approach to writing specs is to understand the problem first.

And, as I said up thread, the volume of your questions is simply too
great for me, at least, to synthesize the problems, understand what
you are asking, and (to the extent of my admittedly little competence)
answer.  What this means is that I'm just dropping packets like a DNS
server that's overloaded.  So you can either put together a more
complete, somewhat digested outline of your understanding of the
problem so that others of us might have a look at it in one go, or
else expect the kind of response you're getting.  Sorry, but I don't
have the time to wade through the number of messages you're sending,
especially since half of every message appears to be devoted to
settling (old) scores.

Regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Sep 2010 12:34:58 -0700

At 2:45 PM -0400 9/14/10, Phillip Hallam-Baker wrote:
>You are not the working group chair here and you are really not adding value by sniping and snarking at everyone who makes contributions that you do not immediately understand.

I waited until two other people whom I respect said they didn't understand you before I turned on my snark hose.

>This is a complex and subtle problem and some people here are attempting to get a handle on those issues.

Earlier you said "The issue is fairly simple" and followed it with firm assertions. I'm missing something here.

>You are not going to convince the ADs that the subject matter is understood with these attempts to suppress and close down any discussion that you fear might raise the possibility of doubt.

In the IETF, repeated requests to write a complete Internet Draft stating your assumptions and listing what you see as open issues is not considered an attempt "suppress and close down any discussion": just the opposite. And I stand by the IETF practice.

>I am pretty sure that you understood the question and could answer it if you choose to.

And here, again, you are probably wrong. I can imagine many things that you might have meant, but short of having some clear, specific wording about your intended semantics, only one of those many things is going to be correct.

>And I am pretty sure that would be much easier than trying to start another of your flame wars.

And here, again, you are wrong. Me saying "you probably mean X and so the answer is Y" is not easier than me asking you repeatedly to say what you mean. It wastes everyone's time as much as you saying "I don't need to explain what I mean, but I want this list to answer my questions".

--Paul Hoffman, Director
--VPN Consortium

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 14 Sep 2010 15:43:21 -0400

> assurance comes from DNSSEC so adding another CERT sub-type does nothing

The claim is that records of the existing CERT subtypes are purely
informational, and a new subtype is needed to indicate the specific
intent that clients should use the public key for TLS connections to the
host name in question without further verification.  DNSSEC protection
of the records is also necessary, but a separate issue.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Sep 2010 12:53:54 -0700

>of the records is also necessary, but a separate issue.

That is exactly correct.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 14 Sep 2010 16:03:49 -0400

> of the records is also necessary, but a separate issue.

To be more precise, *some* *signal* is necessary to indicate that a  
given CERT record should be used in conjunction with TLS.  It doesn't  
necessarily have to be a new subtype; it could be either a layer down  
(e.g., an SRV-style service label) or a layer up (e.g., an X.509  
attribute).  I'm not advocating any of these approaches, just  
clarifying the bounds of the design space.

--Richard

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 14 Sep 2010 13:08:25 -0700

On Sep 14, 2010, at 1:03 PM, Richard L. Barnes wrote:

> To be more precise, *some* *signal* is necessary to indicate that a given CERT record should be used in conjunction with TLS.  It doesn't necessarily have to be a new subtype; it could be either a layer down (e.g., an SRV-style service label) or a layer up (e.g., an X.509 attribute).  I'm not advocating any of these approaches, just clarifying the bounds of the design space.

Or the signaling could be implicit in the addition of DNSSEC in the validation, since currently there exists no current usage that fetches both an RR and the associated RRSIG and performs validation that the RRSIG is valid and is derived on a valid path from a set of roots of trust.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 16:38:48 -0400

I agree with Matt and Roger.

If we need assurances for complete certs in the DNS I prefer to define a new
certificate type since that seems to be the simplest approach.

My original question was whether there is actually sufficient need for full
certs to do this.

I would much prefer to know people's preferences before writing the draft
because getting this type of text precise takes a lot of work.

On Tue, Sep 14, 2010 at 4:03 PM, Richard L. Barnes <[email-masked]> wrote:

> To be more precise, *some* *signal* is necessary to indicate that a given
> CERT record should be used in conjunction with TLS.  It doesn't necessarily
> have to be a new subtype; it could be either a layer down (e.g., an
> SRV-style service label) or a layer up (e.g., an X.509 attribute).  I'm not
> advocating any of these approaches, just clarifying the bounds of the design
> space.
>
> --Richard
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 16:54:14 -0400

They were questions about security issues.

I was really not expecting either you or Paul to understand them. Nor is
that a particular concern to me.

This is a proposed security area group. You will find that we do things very
differently.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 14 Sep 2010 17:49:43 -0400

On Tue, 2010-09-14 at 13:08 -0700, Nicholas Weaver wrote:
> Or the signaling could be implicit in the addition of DNSSEC in the
> validation, since currently there exists no current usage that fetches
> both an RR and the associated RRSIG and performs validation that the
> RRSIG is valid and is derived on a valid path from a set of roots of
> trust.

The question is, is it safe to assume that an admin who places a CERT
record in a signed zone intends for clients to use the public key
without further verification?  (What if one admin adds a CERT record to
an unsigned zone, thinking there will be no security implications, and
someone else later sets up DNSSEC for the zone?)  The Security
Considerations section of the RFC for CERT records does describe this
use case:

        Alternatively, if certificates are retrieved from a secure DNS
        zone
        with DNS security checking enabled and are verified by DNS
        security,
        the key within the retrieved certificate may be trusted without
        verifying the certificate chain if this conforms with the user's
        security policy.

        https://tools.ietf.org/html/rfc4398#section-7

But if that is true, it is an essential semantic property of a CERT
record that I would expect to be stated much more prominently, i.e., in
the Introduction.  We can argue about this, but adding a new flag is
definitely a safe approach.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 14 Sep 2010 17:58:03 -0400

> clarifying the bounds of the design space.

I commend you for doing so, but the X.509 attribute at least is a bad
idea.  Phillip's claim (which I'm not certain if I agree with, but I'm
working with) is that the certificate in a traditional CERT record is
untrusted data.  An attribute that is part of this untrusted data can't
make it trusted.  Put another way, starting to recognize a special
attribute in the certificate would be a breaking change to the semantics
of the existing CERT subtypes.

I'm not sure what you mean by "an SRV-style service label", but maybe I
just lack the background.

-- 
Matt

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 14 Sep 2010 15:03:58 -0700

> definitely a safe approach.

Ah, good point.  However, I do find this discussion somewhat silly, because nobody seems to be using CERTs, so who cares about an additional flag.

In addition, IF the CERT has some other validation path, I believe that DNS SHOULD NOT preclude such validation also being performed, and only if both validations are valid is it acceptable.  DNSSEC-only validation makes sense only for self-signed material and the like, where the CERT can't be validated in some other manner..

But the key (pun intended) is that one of the CERTs in the RRSET MUST be used by the final protocol, which is already corresponding to the meaning of CERT: 'This is the certificate that should be used for this service', and which gives the big advantage of DNSSEC to non-self-signed CERTs: eliminating downgrade and cert-replacement attacks.

One additional worry: I don't know if CERT even works in DNS:  There is a remarkable amount of crap that doesn't properly respect unknown RRTYPES.  CERT is probably safer than most, but there is a reason why TXT might actually be preferable once people nail down the semantics of what the DNSSEC signature means to data: TXT does work.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 14 Sep 2010 18:09:17 -0400

> because getting this type of text precise takes a lot of work. 

It's not clear to me how the choice between certificates and hashes
affects the precise writing of the security semantics of assuring a
certificate (however identified) this way, which is what Paul was asking
for.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 18:09:46 -0400

Sorry, that was intended to be off list.

The point I keep trying to make is that if people would only answer the
design question I asked (i.e. do we expect to need to assure full
certificate data frequently) it may well make the issue moot and both
understanding and explanation will become unnecessary.

On Tue, Sep 14, 2010 at 4:54 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> This is a proposed security area group. You will find that we do things
> very differently.
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 18:36:13 -0400

The difference between digests and certs is that the existing CERT record
already has a type for PKIX while the digest type is completely new. Thus we
can define any semantics we like for the digest type but redefining the
existing types is another matter.

Reading RFC 4398, section 3 begins

" It is recommended that certificate CERT RRs be stored under a domain name
related to their subject, i.e., the name of the entity intended to control
the private key corresponding to the public key being certified..."

RFC 2538 is similarly loose.

I strongly recommend that everyone review both documents now that we have
settled on CERT records since it answers some of the questions raised on
this list such as whether using records in the reverse DNS is appropriate
(yes, there is an example in 2538).

Now the reason that 4398 and 2538 can get away with 'recommendations' and
rather loose language is that all the certificate formats specified are
self-authenticating. The fact that they were retrieved from the DNS, whether
there is a signature RR is completely irrelevant as far as the relying
application is concerned.

Now while I agree with Matt that the argument is almost certainly 'silly'
because nobody uses CERT, that is not exactly an argument that I want to
rely on. Someone will inevitably pop up at last call claiming that they do
rely on the existing semantics.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 14 Sep 2010 18:45:23 -0400

On Tue, 2010-09-14 at 18:36 -0400, Phillip Hallam-Baker wrote:
> because nobody uses CERT 

That was Nicholas, not me.

http://www.ietf.org/mail-archive/web/keyassure/current/msg00518.html

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 18:08:01 -0400

Oops, sorry.

Gmail coloured you both slightly different hues of red.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Sep 2010 01:16:50 -0400

On Tue, 2010-09-14 at 15:03 -0700, Nicholas Weaver wrote:
> Ah, good point.  However, I do find this discussion somewhat silly,
> because nobody seems to be using CERTs, so who cares about an
> additional flag.

We shouldn't gratuitously introduce a potential vulnerability with the
use of traditional CERT records, however rare, when there is an easy
alternative.  Also see below.

> In addition, IF the CERT has some other validation path, I believe
> that DNS SHOULD NOT preclude such validation also being performed, and
> only if both validations are valid is it acceptable.  DNSSEC-only
> validation makes sense only for self-signed material and the like,
> where the CERT can't be validated in some other manner..

I don't see the point of such a stipulation.  If the DNS admin wants
clients to require the other validation, she will just use a traditional
CERT record.  Otherwise, since we are granting her the authority to
assure any key via a self-signed certificate, there's no benefit to
placing restrictions on public-CA-signed certificates.

A TLS server can only present one certificate (for a given indicated
server name).  It may have to be a public-CA-signed certificate to
satisfy legacy clients, yet we might as well let DNSSEC-aware clients
use the assured certificate even if the public PKI goes down for some
reason.

This issue does make me wonder, though, if we really want to assure
certificates or some other object that contains a public key and
extensions but specifically lacks a validation path.

> But the key (pun intended) is that one of the CERTs in the RRSET MUST
> be used by the final protocol, which is already corresponding to the
> meaning of CERT: 'This is the certificate that should be used for this
> service',

Where do you see that?

> and which gives the big advantage of DNSSEC to non-self-signed CERTs:
> eliminating downgrade

A requirement to use TLS when accessing a service is not part of the
semantics of a DPKIX record.  It would have to be a separate record.

> and cert-replacement attacks.

That's just a question of the trustworthiness of the DNS root compared
to the public CAs.

-- 
Matt