Subject: [dane] AD review of draft-ietf-dane-protocol-18

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Mar 2012 12:28:23 +0000

Hi all,

First, good job all!

My AD review is below. I've a number of questions
and a bunch of nitty comments. The latter are ok
to handle before, during or after IETF LC as the
WG prefer, but I'd like to see answers to the former
before starting IETF LC.

Note: I'm not saying I'm insisting on any particular
answer for any of those questions, I just want to
check whether the WG are ok with -18 or want some
change for those.

Cheers,
S.

Questions to which I'd like to see answers:

1. What does this, in 1.3, mean? "This document does not specify how
DNSSEC validation occurs because there are many different proposals for
how a client might get validated DNSSEC results." We've just said that
DNSSEC signatures MUST be validated and referenced DNSSEC RFCs, so what
"different proposals" do you mean and why have they no references?

2. Is usage 0 clear enough? For example, a CA cert that's not a trust
anchor will have a basicConstraints extension with cA set, but a trust
anchor need not have that, so should usage 0 mean "CA certificate or
trust anchor" or is it just worth noting that the associated certificate
in this usage can be either?

3. In another context the fact that sha-384 is part of the US' suite-B
(see e.g. RFC 5430) was brought up recently.  Should there be a
code-point for sha-384?  I don't care, but I don't recall if that was
considered in the WG discussion.

4. 2.1.4 says nothing about the length of this field.  Although that can
be figured out in all cases either because its fixed or because its
specified in the DER encoding of a full cert or SPKI, I wonder would all
readers know that. Could be well worth adding a bit of text about that,
even though I can't think of a way to get that wrong that wouldn't be
immediately obvious.

5. If the PKI underlying TLS has fallen into disrepute, (as -18 says)
how is it that a DANE-client chosen validator to which DNSSEC has been
offloaded will be any better since that validator can be as
disreputable as a PKI with the same effects?

Arguably, allowing a DANE client to depend on such a beast is worse
that the current PKI, since the chances we'll hear about a hacked
validator are much lower than for a higher profile CA. (I don't
have a concrete suggestion here other than to really require DNSSEC at
the DANE client, but I do want to see an answer to the question
above.)

6. Section 4, last para: if the application gets N usable certificate
associations, none of which match the TLS server then what? Should the
client treat that like zero received (i.e. continue normal TLS) or like
one bogus TLSA record, which'd mean barfing the TLS handshake?

7. Section 8, 2nd para - usage #3 is particularly vulnerable here
right? I think that'd be worth calling out, or am I wrong?

Misc. comments, all ok to handle as part of IETF LC:

- abstract: why doesn't this say that we're putting public keys or
hashes thereof in the DNS?

- abstract: is is ok to say "...enabling the administrator of a domain
name to certify the keys..."? Would it be better to say "...enabling the
administrators of domain names to specify the keys..."?

- 1.1, 1st para maybe s/privacy/security/

- 1.1, 2nd para maybe s/published/public/

- 1.1, 5th para, I don't think "broken down" is right here, better would
be to say something like  "Real problems have become apparent because
some CAs have become untrustworthy." Reason to change is that PKI is
arguably not broken, depending how you interpret the term PKI, so
better to say something correct and less controversial

- 1.1, 5th para, a bad CA doesn't compromise "any other certificate" but
rather the name-public key binding. (The presumably pre-existing good
certificate is still the same and not compromised.)

- 1.1, 5th para, I don't think the entire CA model is considered
disreputable, but mainly the fact that any CA can issue for any web
site, so maybe s/brought/brought aspects of/

- 1.2, 1st para, typo, s/get Internet/get an Internet/

- 1.2, 4th para, 2nd sentence needs fixing.

- 1.3, 1st para, a trust anchor doesn't identify a certificate, maybe
just delete the mention of anchors in the parenthesis and then add a
sentence that a trust anchor plus a domain name can also be a
certificate association.

- 1.3, 1st para says a DNS query can return >1 association which is fine
but with the port-specific queries used here is there really a case
where different server s/w might be listening on the same port? I guess
there might be but it seems too much of a corner case. That's not a
corner case for queries on different ports of course, so that example
may be misleading.

- 1.3 already has 2119 language before 1.4 introduces that, maybe best
to move 1.4 earlier

- 2.1, The term selector is already used related to public keys and DNS
by DKIM. Not sure its worth changing this or even adding a sentence
saying this is different from the DKIM case, but the editors/WG might
want to think about it.

- 2.1.1, Usage 1: are there any corner cases where a CA cert can be used
with this usage? I suspect not. Would it be worth saying that explicitly
as well?

- 2.1.3, The SHOULD says "use the same hash." There are lots of
rsaWithSHA1 certs out there, but there's no SHA-1 matching field. Is
that an example of when the matching type and cert signature is not
going to be the same function. Worth a mention?

- 2.3 has the "_443._tcp" parts in the DNS names but the handling of
ports and protocols weren't mentioned so far, maybe worth adding
something in the intro so the reader gets this more easily or move the
examples later?

- section 4, 3rd para, is "run under TLS" right? Normally we'd say "HTTP
over TLS" not under.

- Section 4, 5th para, is it really "a host" that "uses" TLSA records?
Probably doesn't matter but maybe administrator (who chooses or uses)
could be kept distinct from the host (that does the TLS handshake).

- section 4: Can a DANE client that uses a validator, e.g. via IPsec,
ever get a bogus validation state? Does that need a mention?

- section 5 could be made into an appendix easily and would disrupt the
flow less that way maybe

- section 8, 2nd para, maybe s/issued anyway/issued by some CA anyway/
might be better

- section 8, do we have a reference for SSL proxies that's not just a
product data sheet? Be nice to add if it exists. (I doubt it'll be an
RFC, but I'd bet there's a paper to be found on the topic.)

- A1.1, s/from original chain/from the original chain/

- A2.1.3, how would that interact with certificate content? It'd be
good to note that the cert in that TLSA record can't usefully be
a wildcard cert for *.example.com maybe.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:47:45 -0700

Given that the questions are wide-ranging, and Jakob and I are going to need clear guidance if the answers lead to changes, I'm going to pre-emptively split them into separate threads.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:48:43 -0700

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:49:23 -0700

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:50:06 -0700

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:51:09 -0700

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:52:13 -0700

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:52:55 -0700

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 06:54:18 -0700

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Mar 2012 10:24:38 -0400

IETF standard track not a forum for making contentious ideological
statements. If the specification tries to do so it is not going to
achieve IETF consensus.

I don't see why it is necessary or useful to make any statement of
this sort at all.

On Tue, Mar 20, 2012 at 9:52 AM, Paul Hoffman <[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 20 Mar 2012 07:55:27 -0700

The length of the field is well known because it is every left in the TLSA
RDATA record.  The more interesting question is what happens if there are
extra bytes on the end of the data block.  This should probably be an error.
But the length of the data field is computed from the TLSA RDATA record and
not from the contents of the record.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Tuesday, March 20, 2012 6:51 AM
> To: dane list
> Subject: [dane] 4: Length of certificate association data field
> 
> > 4. 2.1.4 says nothing about the length of this field.  Although that
> > can be figured out in all cases either because its fixed or because
> > its specified in the DER encoding of a full cert or SPKI, I wonder
> > would all readers know that. Could be well worth adding a bit of text
> > about that, even though I can't think of a way to get that wrong that
> > wouldn't be immediately obvious.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 20 Mar 2012 07:59:26 -0700

Fair enough comment.
Suggested text

If an application fails to match any certificate association, then the TLS
session is aborted or never started.

Jim

> Sent: Tuesday, March 20, 2012 6:53 AM
> To: dane list
> Subject: [dane] 6: No matching associations
> 
> > client treat that like zero received (i.e. continue normal TLS) or
> > like one bogus TLSA record, which'd mean barfing the TLS handshake?
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Mar 2012 15:31:20 +0000

> Given that the questions are wide-ranging, and Jakob and I are going to need clear guidance if the answers lead to changes, I'm going to pre-emptively split them into separate threads.

Thanks Paul.

Just to be clear: I'm almost certainly ok with whatever the
WG want in terms of answers to these, and a pointer to the
conclusion of the previous list discussion is a fine answer
if I've asked something that was already considered. (I.e. if
my little brain has forgotten, which is quite possible:-)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Mar 2012 15:32:08 +0000

Hi Jim,

> not from the contents of the record.

Right, I guess there are two things here really, a) are there any
decoding errors we want to call out and the corresponding action
to take, and, separately, b) do we want to give any more guidance
to help the programmer get it right more easily when creating or
decoding records.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 08:36:00 -0700

> not from the contents of the record.

Agree. I'm pretty sure this is an error that would be caught in the software signing the zone. I don't see what we can say in 2.1.4 that would not just be confusing, but am open to suggestions.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 08:39:22 -0700

> session is aborted or never started.

I think that is OK, but would rather be clearer:

During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake.

--Paul Hoffman

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 20 Mar 2012 09:50:58 -0600

I agree.  In paragraph 1.1's statement of the problem, the solution has not
"gradually broken down".  The issue is that there are any number of attack
vectors out there on the internet.  Real-world occurrences have not brought
"the CA model into disrepute." That is just unsubstantiated posturing to
sell an argument.  Unless  This kind of editorializing should not be used to
slant what would otherwise be a neutral specification. As Stephen Farrell
points out, when you attack any particular trust anchor, you essentially
attack all trust anchors and all who have made trust decisions for you
(clients, servers, ICANN, whomever).  The problems of last year were not
caused by single points of failure or a single "weak link". Revocation
checking and system behavior are multi-faceted and DANE alone is not a
silver bullet.  The only way to improve TLS security is for people in
different areas of interest to work toward a collaborative, holistic
solution.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Phillip Hallam-Baker
Sent: Tuesday, March 20, 2012 8:25 AM
To: Paul Hoffman
Cc: dane list
Subject: Re: [dane] 5: PKI disrepute

IETF standard track not a forum for making contentious ideological
statements. If the specification tries to do so it is not going to achieve
IETF consensus.

I don't see why it is necessary or useful to make any statement of this sort
at all.

On Tue, Mar 20, 2012 at 9:52 AM, Paul Hoffman <[email-masked]> wrote:
>> how is it that a DANE-client chosen validator to which DNSSEC has 
>> been offloaded will be any better since that validator can be as 
>> validator are much lower than for a higher profile CA. (I don't have 
>> a concrete suggestion here other than to really require DNSSEC at the 
>> DANE client, but I do want to see an answer to the question
>> above.)
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 09:16:54 -0700

>> the DANE client, but I do want to see an answer to the question

Stephen: can you clarify your question? The first two respondents have objected to the document's statement about the PKIX-based PKI being in disrepute, but I don't see that as being the thing you are questioning. My reading is that you are questioning a DANE client trusting an external validator, not the second, DNSSEC-based PKI. Which did you intend, or did you intend something else?

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Mar 2012 16:46:57 +0000

On 03/20/2012 04:16 PM, Paul Hoffman wrote:
> Stephen: can you clarify your question?

Sure.

 > The first two respondents have objected to the document's statement 
about the PKIX-based PKI being in disrepute, but I don't see that as 
being the thing you are questioning. My reading is that you are 
questioning a DANE client trusting an external validator, not the 
second, DNSSEC-based PKI. Which did you intend, or did you intend 
something else?

It was probably a mistake for me to use disrepute
here. (I had a separate comment on the editorial
aspect I think.) Its a question about comparing
the risk today for TLS clients vs. the risk for
DANE clients using external DNSSEC validators.

It seems to me that a DANE client trusting an external
DNSSEC validator is as vulnerable as a current TLS
client trusting a set of CAs in that any CA or any
external validator can assert any key for any domain.

If that's true, and if we're less likely to hear about
DNSSEC validators being hacked (compared to public CA
compromises) then a DANE client with an external
validator could be worse off than a current TLS client
depending on the current public CAs.

The counter-argument is probably that a random DNSSEC
validator is a less interesting target than a public
CA which may affect the probability of a problem
occurring that affects a given DANE client. OTOH,
public CAs ought to have more defenses compared to
that random DNSSEC validator, and some external
DNSSEC validators will be attractive targets, so
its not clear to me how the overall risk for a
client pans out, when comparing the status quo
(today's TLS client) vs. a DANE client with an
external DNSSEC validator.

But the impact on the client is the same, its
vulnerable to being presented with the wrong key
for any domain and accepting that.

So my question might be better phrased as: is the
above correct, and if so, is text needed to call
that out in the draft?

Hope that helps,
S.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 10:13:50 -0700

> above correct, and if so, is text needed to call

I would say "yes", this seems like a reasonable security consideration that isn't covered in the security considerations in the DNSSEC specs.

--Paul Hoffman

---

From: Jim Fenton <[email-masked]>
Date: Tue, 20 Mar 2012 15:24:12 -0700

> depending on the current public CAs.

But a given DANE client is likely to trust only one (or a small number)
of DNSSEC validators, as compared with the 100+ root CAs that usually
need to be trusted. Or looking at it another way, compromise of a given
DNSSEC validator is likely to impact a smaller number of clients than
compromise of a given root CA.

And a client has the choice whether to use an external DNSSEC validator
at all, which isn't really practical with public CAs.

I would say that both of these factors mitigate the risk.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Mar 2012 22:57:26 +0000

Hi Jim,

> But a given DANE client is likely to trust only one (or a small number)

Hopefully. I do wonder though how long it'll be until someone
wants to define a DHCP option to give me a zeroconfig way to
get the IP address of a "trusted" validator though;-)

> need to be trusted.

Well, the "need" there is down to client implementation only and
nothing to do with PKI protocols. The same could happen for DANE,
but one would hope we've learned something.

 > Or looking at it another way, compromise of a given

I agree. And what you say (with quibbles as noted above) is
worth mentioning as it does factor into the risk analysis.

S.

---

From: John Gilmore <[email-masked]>
Date: Tue, 20 Mar 2012 16:59:36 -0800

> > considered in the WG discussion.

TLSA does not need a code point for sha-384.  The only use that TLSA
makes of the specified hash function is for matching the hash in the
TLSA record with the certificate or its SubjectPublicKeyInfo.  This
matching is independent of the use of hashes within the TLS protocol
itself (where sha-384 is mandatory among products designed for US
government TOP SECRET use under NSA's "Suite B" program).  The
presence of TLSA record(s) do not interfere with the use of sha-384 in
TLS itself.

A Suite B server operator who wishes to use TLSA to associate their
domain name with a certificate or a public key, without using an
unapproved hash function, need only supply the entire
SubjectPublicKeyInfo, or the entire certificate, in their TLSA record.
They can simply avoid the use of hashes in their TLSA records.
This option is fully supported by the draft as it stands, and
provides better security than any hash they could have picked.

In addition, I suspect that NSA would, upon reflection, also approve
the use of SHA-512 in cases where SHA-384 is not available, such as
this one.  (If they wouldn't, then we'd like to know why they trust
SHA-384 but don't trust SHA-512!)

We do recommend in 2.1.3 that if the host operator uses a hash in the
TLSA record, the record "SHOULD" use the same hash that was used in
the signature in the certificate, to assist clients that support a
small number of hash algorithms.  This SHOULD does not come into play
if the operator does not use a hash, as recommended above.  Also,
it's a SHOULD, not a MUST, and given the ready availability of free
software that implements it, most clients that support any SHA-xxx
algorithm will support all three SHA-256, -384, and -512 algorithms.

	John

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Mar 2012 01:05:56 +0000

On 03/21/2012 12:59 AM, John Gilmore wrote:
> TLSA does not need a code point for sha-384.

FWIW, I've no problem with the argument below.

S

 > The only use that TLSA

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Mar 2012 13:28:13 +0100 (MET)

> SHA-384 but don't trust SHA-512!)

SHA-384 and SHA-512 are exactly the same algorithm.  SHA-384 only uses
a different internal start value than SHA-512 and truncates the output.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2012 14:34:35 -0400

What I would say is:

The public CA model upon which browsers and OS's depend is 
fundamentally vulnerable, not because it is PKI-based, but because it 
allows any of these CAs to issue any certificate, with no 
constraints. Business models adopted by browser and OS vendors, and 
by the public CAs, have allowed this model to be exploited, with 
predictable consequences. Recent experiences with compromises of CAs 
or RAs have lead to very serious secruity problems that undermine 
confidence in this system.

DANE is envisioned as a preferable basis for binding public keys to 
DNS names (a subset of what PKIs can do in general) because the 
entities that vouch for the binding of public key data to DNS names 
are the entities responsible to managing the DNS names in question. 
While the resulting system still has residual security 
vulnerabilities, it restricts the scope of assertions that can be 
made by any entity, consistent with the naming scope imposed by the 
DNS hierarchy. As a result, DANE embodies the security "principle of 
least privilege" that is lacking in the current public CA model.

Steve

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Mar 2012 18:43:15 +0000

> compromise of a given root CA.

Also, with DANE the DNSSEC validator is chosen by the client, either as a
side-effect of the client's choice of connectivity provider, or by a
deliberate choice to use a third party DNS service. Either way the client
has some control over the trustworthiness of the validator.

With bare X.509 users are vulnerable to hundreds of organizations that
have no relationship with either the client or the server. The client
and server have no control over the trustworthiness of authentication.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes, South-east Iceland: Southwesterly 5 to
7, occasionally gale 8 at first except in Fair Isle, backing southerly 5 or 6.
Rough or very rough, occasionally high at first in Bailey. Rain and drizzle
then mainly fair. Good, occasionally poor.

---

From: Rick Andrews <[email-masked]>
Date: Wed, 21 Mar 2012 12:08:12 -0700

> and server have no control over the trustworthiness of authentication.

Browsers give users control today by allowing them to untrust any of those root CAs. Granted, it's not too easy to do, but it's possible. If I hear about a breach at a particular CA, it's possible to edit my trust settings to untrust all certs signed by that CA.

In a DANE world, assuming CAs still exist and sign at least some certs, it will be impossible to untrust all certs signed by a particular CA.

-Rick

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2012 10:55:49 +0000

Rick Andrews <[email-masked]> wrote:
>
> Browsers give users control today by allowing them to untrust any of
> those root CAs. Granted, it's not too easy to do, but it's possible. If
> I hear about a breach at a particular CA, it's possible to edit my trust
> settings to untrust all certs signed by that CA.

Trust wrt a validation service is not the same thing as trust wrt a CA (an
authentication service). Clients don't have a free choice about which CAs
they trust, because CAs are chosen by servers. The alternative to trusting
CAs is for clients to authenticate each name themselves, which is not a
PKI.

With DANE clients have a free choice of which validator to trust,
independent of which names they want to authenticate.

> In a DANE world, assuming CAs still exist and sign at least some certs,
> it will be impossible to untrust all certs signed by a particular CA.

You are assuming that client software doesn't provide a CA blacklist.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea, Shannon: East or southeast 4 or 5, increasing 6 at
times, except in Irish Sea. Slight or moderate, occasionally rough in Shannon.
Occasional thundery rain. Moderate or good, occasionally poor.