Re: [keyassure] PROPOSAL: Revision of DANE client requirements

[Zack Weinberg <[e-mail]>]

On Tue, Mar 29, 2011 at 2:24 AM, Paul Wouters <[e-mail]> wrote:
>
> I think the client should decide which trust models (DANE, PKIX, others)
> it intends to trust. I do not think these trust models should make
> statements about the other models. The original section 3 starts out
> with doing this ("MUST be marked as unusable." [Paul: by DANE])
> correctly, but then later on assumes DANE trumps everything ("MUST abort
> the handshake ")

We disagree so profoundly that I can only conclude you have an
entirely different notion of what DANE is good for than I do.

Here's how I see it: The gating audience for DANE is site admins, who
must be persuaded that adding TLSA records (and DNSSEC signatures) to
their zones is a valuable thing for them to do.  Site admins are not
going to go for this pitch:  "If you put TLSA records in your zone and
sign it, then DANE-compliant clients will do something with that
information.  We can't tell you what, because we thought that policy
should be up to the client.  Some of your users might get some sort of
security benefit out of it.  Others might find themselves unable to
use your site."

They are much more likely to go for this pitch: "If you put TLSA
records in your zone and sign it, then all DANE-compliant clients will
react to those records in this predictable fashion: [....] This
protects those users from these actual security threats: [....]
However, if your site is ever misconfigured in this specific way:
[...] then it will become inaccessible to DANE-compliant clients, so
you need to make sure that your operational procedures never let that
happen."

Therefore, I do not think the client should decide who to trust.  I
think DANE needs to decide and specify that decision with as little
wiggle room as possible, and I think it *especially* needs to specify
what to do when DANE disagrees with other trust models (PKIX being the
only such at present).  And that's what I've tried to do with my
revisions.

>> Second, I have added constraints on client behavior based on DNSSEC
>> status alone.  This is arguably out of scope for this standard, but
>> I think the additions are necessary to preserve the security benefits
>> of DANE in the presence of active tampering with the DNS.
>
> DNSSEC should be a requirement for DANE. I thought this was already in
> the 06 draft? Ah, it is in Section 3.

The new requirement I added is "MUST NOT proceed with a connection to
a server if the DNSSEC validation status is 'bogus' for _any_ DNS
records relating to that server".  The old language could be read to
say that TLSA records should be _ignored_ when DNSSEC validation came
back "bogus", and did not state anything about what should happen if
the TLSA record was properly signed but the A record was bogus.

With my wording, the only way an attacker with the power to tamper
with DNS responses can downgrade a client to backward-compatible
PKIX-only mode (for a server that does provide signed TLSA records) is
by suppressing _all_ DNSSEC information.  I think this is a valuable
property.

>> Section 1.2: Delete the sentence "The DNSSEC signature MUST be
>> validated on all responses in order to assure the proof of origin of
>> the data" and the subsequent paragraph break.  (An equivalent, but
>> more specific, requirement will reappear in section 3.)
>
> I think it would be good to state the relationship between DNSSEC and TLSA
> at the beginning of the draft. I agree that this sentence is not the best,
> because it kind of implies the client has to do the validation itself from
> the root down, and not trust the AD bit on responses received from its
> (secure) connection to a validating name server, which I think is not what
> the authors intended. Though it is clarified in the orignal section 3.

The main reason I proposed modifications to sections 1 and 2 is to
_consolidate_ all requirements upon the client in section 3, for
clarity's sake.  I'd be okay with leaving an informative sentence
early in the document along the lines of "TLSA records are only useful
for security when the DNS zone they appear in is protected from
tampering by DNSSEC signatures", but I want that to be redundant to
normative, MUST-requirement text in section 3.

...
>>    If it is desired to use other certificate
>>   formats with this specification in the future, those formats must
>>   be assigned their own certificate type numbers, and the definition
>>   of "associated" in section 3.1 of this specification must be revised
>>   appropriately.
>
> I am not sure if this is required after the previous paragraph.

I wouldn't especially miss it, but equivalent language was in the -06
draft and I didn't see any harm in preserving it.

> Note also that in the future, there will be other type of TLSA records not
> involving PKIX certificates, such as those containing just bare public keys.
> Ideally, I would like to see a different name for "certificate type" and
> call it "identifier type" or something. Then part of this text should move
> to the section describing the type 1 and type 2 identifiers specifically.

I would support that change.  However, I feel it is off-topic for this
change proposal, which I would prefer to keep focused on nailing down
client behavior.

>>   The primary purpose of TLSA records is security.  However, TLSA
>>   information might also be useful for protocol optimizations that
>>   require advance knowledge of what the server's end-entity
>>   certificate should be.  Clients that use TLSA information only for
>>   such optimizations, and not for security decisions, are exempt
>>   from all other requirements in this section.
>
> I assume you are trying to say that client/servers supporting this could
> skip the exchange of PKIX information in the TLS handshake.

Sort of.  I was specifically thinking of snap start [
http://tools.ietf.org/html/draft-agl-tls-snapstart-00 ] when I wrote
that paragraph - that perhaps having the end-entity certificate
out-of-band would allow a client to do snap start on the first
connection to a previously unknown server.  Having reread the snap
start spec, it looks like that won't work (the client needs to know
several other things) and even if it did, it would be a bad idea to do
it on insecure/indeterminate data.  And it's off topic anyway.  I will
drop this part of the proposal.

>>   Clients that make security decisions based on TLSA information
>>   MUST be, or have access to, security-aware DNS resolvers as
>>   defined by RFC 4033.  The rest of this section applies only to
>>   such clients, which will be referred to as "DANE clients".
>
> This is a DANE document, you cannot really say in the above paragraph that
> such a client using insecure TLSA from DNSSEC is not a "DANE client".
> Clients
> using this draft/rfc are "DANE clients".

Dropping the optimization-only text would render this moot, I think?
I could just say "Clients MUST themselves be, or have secure access
to, security-aware DNS resolvers" and scrap the "DANE client" wording
below.

>> 3.1. Definitions
>>
>>   A certificate received in the TLS handshake is said to _match_ a
>>   TLSA record if:
>>
>>   o  The TLSA record has reference type 0 and the certificate from
>>      the handshake is byte-for-byte identical to the certificate for
>>      association; or
>>
>>   o  The TLSA record has some other reference type, and the hash of
>>      the certificate from the handshake (using the hash algorithm
>>      specified by the reference type) is byte-for-byte identical to
>>      the certificate for association.
>
> With my proposed TLS extension, the whole PKIX transmission could be
> suppressed, but this paragraph assumes it is always sent.

Do you have a link to your proposal?  I'm happy to adjust the wording
appropriately - the intent is just to be clear about what exactly is
being "matched".

> I also get
> nervous about terms lie "byte for byte" since we have things like network
> ordered bytes.

Fair point, but the comparison function needs to be specified
precisely - "identical" is not precise in my book - and pace Peter
Gutmann's complaints about "memcmp() is the only way to compare PKIX
certificates", I don't know a better option than "byte-for-byte".
Maybe the thing to do is nail down the byte order of the certificate
for association in section 2.

>>   A certificate bundle received in the TLS handshake is said to be
>>   _associated_ with a domain name by DANE, if a TLSA record for the
>>   host, protocol, and port exists, the end-entity certificate in the
>>   bundle contains a name record that matches the host, and:
>
> I see more people using wildcard certs (*.xelerance.com) which would not
> match "a name record"....

I'm open to suggestions for better wording here.  I don't have a lot
of experience with DNS wildcards _or_ certificate wildcards.

>>   DANE clients MUST NOT proceed with a connection to a server if the
>>   DNSSEC validation status is "bogus" for _any_ DNS records relating
>>   to that server.
>
> Don't say "connection". Say that the "DANE trust path" must be aborted. The
> client might still do PKIX or other methods. The DANE specification should
> not forbid those so it should not dictate to close the connection.

On the contrary.  If DANE can't dictate a connection abort it is
useless, and if DANE allows a client to proceed with a connection when
DNSSEC signature checks have come back "bogus", a DNS-tampering
attacker can subvert it.

The DANE specification _absolutely must_ dictate a connection abort
under these circumstances.  If equivalent wording is not in the final
draft I will raise a formal objection (or whatever the appropriate
term is, sorry, I know W3C procedure a lot better than IETF
procedure).

>>   DANE clients MUST ignore TLSA records whose DNSSEC validation
>>   status is "insecure" or "indeterminate" (however, such records MAY
>>   be used for TLS handshake optimizations as mentioned above).
>
> See above. I still don't understand this "insecure use" of TLSA.

Will drop the parenthetical.  Do you agree that ignoring the record is
the Right Thing when DNSSEC validation comes back insecure or
indeterminate?

>>   A TLSA record whose DNSSEC status is "secure", and whose
>>   certificate and hash types are understood by the client processing
>>   it, will henceforth be referred to as a _trusted_ TLSA record.
>
> Again, I don't agree with a "untrusted TLSA record" concept.

This is just meant to make it unambiguous, below, that records that
were ignored for lack of a zone signature, or because the client
doesn't understand the type codes, do not count.  Maybe I should
replace "trusted" with "usable"?

> I think we definitely need to discuss the "no others" part. I can see
> its use to ignore any bogus PKIX issued certificates, but I don't think
> this should be a zone administrator decision. It should probably be a client
> decision to disable PKIX or disable PKIX in the precense of DANE records.

It has to be a zone administrator decision, so that the zone
administrator knows the consequences of adding TLSA records to their
zone (see discussion way up top).  Leaving this as an application
decision will only ensure that nobody uses DANE.

>>   However, if there is any _other_ reason why a server's end-entity
>>   certificate would have been rejected in the absence of TLSA
>>   information, a DANE client SHOULD still reject that certificate.
...
> I would say if you store full PKIX into DNS then you should ensure that
> both the DNS and the PKIX information is valid, and reject it if either
> one fails.

That was in fact the intent of my text.  How was it unclear?

> Especially if a method is available where you can store the
> bare public key in DNS and avoid all these conflicts.

I'm good with a bare-public-key option but I will not make this
proposal depend on the addition of a bare-public-key option.  The WG
has been arguing over bare public keys for weeks now, and I've got
plenty of potential for controversy in here already, thanks.

>>   DANE associations provide a trust anchor _only_ for end-entity
>>   certificates, even if the TLSA record has certificate type 2.
>>   A DANE client MUST NOT allow any non-end-entity certificate in
>>   a certificate bundle that is anchored by a DANE association to
>>   become trusted for any domain name other than the one in the
>>   original association.
>
> This might get complicated with wildcards, both in DNS as well as in
> the CN= or SubjectAltname=

The intent is to trust only the end-entity cert and only for the
domain name that was *queried*.  Please suggest wording improvements.

>>   DANE does not assure any information in a certificate other than
>>   the public key and its binding to host, protocol, and port.
>
> This is a real problem, as clients would have to store the certificate
> in their certificate pool, yet mark it was obtained by DANE and/or what
> parts were validated. I was told by at least one major browser vendor
> that this is a serious problem. I would say that if the entire cert
> was in DANE, then DANE assures ALL the information in that certificate.
> After all, the RRSIG was over the entire certificate.

What I'm really going after here is the DV/EV distinction; I want to
specify that DANE does _not_ provide EV.  However, EV is a marketing
term rather than a technical term, so it doesn't belong in a spec like
this.  The _effect_ of EV is, if a certificate is signed by a
particular CA certificate, then more of the name fields are considered
trustworthy.  So by saying "does not assure any information other than
..." I was trying to specify a similar effect (or rather, the absence
of a similar effect). Again, I'm open to wording improvements.

>> 3.5. User override
>>
>>   DANE clients SHOULD NOT allow their human users to force the
>>   establishment of a connection that has been aborted for any of the
>>   reasons listed in sections 3.2 or 3.3.
>
> That's not up to the network protocol to decide.

That's why it's a SHOULD rather than a MUST (and why there is a
specific example of an application that might ignore the
recommendation).  But I think it's important to have this advice to
applications in the spec, again, so that the behavior of clients is
predictable - in this case, so that site admins can assume fail-hard
behavior.

> Even if you state it here, it will get ignored.

I will be making efforts to ensure it doesn't for HTTPS (by working
with browser vendors).

zw