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

[Paul Wouters <[e-mail]>]

On Mon, 28 Mar 2011, Zack Weinberg wrote:

> The exceptions are: First, it is not clear to me whether the present
> intent of the spec is that a TLSA record for site S specifying
> certificate X forbids a compliant client from proceeding with the
> handshake if it receives certificate Y.  I think the answer to this
> question must be an unambiguous "yes", and I have made changes to that
> effect in my edits.  If the answer is meant to be "no", then I will
> have to raise a formal objection, because that would IMHO mean that
> DANE provided no improvements over the status quo.

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 ")

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

> Third, I have added text about a potential non-security use of TLSA
> records -- to enable TLS handshake optimizations -- and about user
> override of TLSA-based rejection of a certificate.  These were not
> addressed in the current draft, but I believe they add value.


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

> Section 1.3: Delete the entire second paragraph.

Agreed. My reasoning being that DANE should not exlucde PKIX (just like PKIX
should not be allowed to exclude DANE). This should be a client choice.
See above on the contraction in the original section 3.

> Section 2.2: Replace the paragraph that begins "Both types are
> structured ..." with this text:
>
>    Certificates of type 1 and 2 MUST be in PKIX format: that is, they
>    must be structured according to the formatting rules in RFC 5280,
>    and encoded using ASN.1 DER.  However, as described in section 3.4,
>    type 1 certificates do not need to adhere to all the semantic
>    rules in RFC 5280.

This sounds okay.


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

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.

> Section 3: Replace entire section with this text:
>
> 3. Client application behavior in the presence of TLSA records
>
>    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. In fact, that
is pretty much what my draft for "TLS Extensions for out of bound public
key validation" adds an option for. However, the above paragraph stating
something like "you can use this info but not treat it as secure" makes me
very nervous. I would be uncomfortable introducing a concept of "insecurely
obtaining TLS public keys from DNS". My TLS extension draft addresses this
by saying the TLS client could have cached the TLS public key from a previous
handshake or have obtained this via another secure(!) method like DANE or LDAP.

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

> 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. I also get
nervous about terms lie "byte for byte" since we have things like network
ordered bytes.

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

>    o  The TLSA record has certificate type 1, and it matches the
>       end-entity certificate in the bundle; or
>
>    o  The TLSA record has certificate type 2, it matches one of the
>       non-end-entity certificates in the bundle, and the end-entity
>       certificate in the bundle has a valid chain to the certificate
>       that matched the TLSA record.
>
> 3.2. DNSSEC validation
>
>    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.

>    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. Either you
obtained it securely outside of DANE to use, in which case DANE does not apply,
or you only got it via DANE, in which case you should not use it if it was not
secured. One DoS attack I could imagine here is spoofing bogus DANE records and
the client trying to "optimise" to the server and botching the TLS handshake
repeatedly.

>    DANE clients MUST also ignore TLSA records whose certificate type
>    or hash type they do not understand.
>
>    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.

> 3.3. DANE validation
>
>    The presence in the DNS of a trusted TLSA record is an assertion
>    by the zone administrator that the legitimate server(s) for that
>    host, protocol, and port will use certificate bundles that can be
>    associated with the domain name by that record (as defined in
>    section 3.1), and no others.

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.

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

This is the fundamental problem of storing things like "Validity"
of the PKIX into a DNS record with a validatity based on TTL/RRSIG
lifetimes. This is also why I am writing the DANE public key draft, which
has as one of its goals not to add possibly contradicting information
from PKIX into DNS.

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. Especially if a method is available where you can store the
bare public key in DNS and avoid all these conflicts.

One of the advantages of DANE is you can put your public key in DNS and
forget about things like re-signing your certificate and expiration.

>    For instance, if a certificate anywhere in the server's bundle has
>    expired or has been revoked by its issuing CA, a DANE client
>    SHOULD reject the end-entity certificate, even if the TLSA record
>    matches a point in the chain before the invalid certificate.

Should it? I am not sure I agree (or disagree)
If we have a bare public key option, then I can agree with this, as
anyone who cares can then pub just the pubkey in DNS and then for
compat reasons (or other) keep a valid PKIX on the server as well.

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

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

And again, this assumes the alternative of bare public keys in DANE
exist for those who only want to assure the port/transport/name and
public key.

>  Most importantly, DANE does _not_ assure any non-DNS name records.

How is an implementation supposed to keep track? I would strongly suggest
people who desire this should use bare public keys in DANE instead.

> 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. Leave that up to the
application developers to deal with. Even if you state it here, it will
get ignored. But I don't think the protocol should tell me how much I
should trust it. Just like I want to decide how much to trust (or not)
PKIX, I will decide how much to trust DANE. That not every enduser can
make an informative decision is something the application people are
much better suited to address properly then network protocol engineers.

Paul