[keyassure] PROPOSAL: Revision of DANE client requirements

[Zack Weinberg <[e-mail]>]

I'd like to propose some revisions to the text of DANE.
Specifically, I want to make the requirements upon TLS clients that
implement the spec clearer, and I also want to consolidate them in one
place.  The current draft
(http://tools.ietf.org/html/draft-ietf-dane-protocol-06) scatters
client requirements all around the text, and it is IMO a bit too vague
about exactly what *is* a requirement.  I want to avoid a situation
where not all clients interpret TLSA records the same way, and I also
want to avoid a situation where a site administrator might be confused
about the effects of adding TLSA records to their zones.  With a few
exceptions, I believe all my proposed changes are strictly editorial
-- that is, I have not removed or added any requirements upon TLS
clients, I have just made it clearer what they are.

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.

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.

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.

I am speaking as a security researcher and as a Web browser
implementor.  I am not speaking on behalf of any other individual or
organization; however, I have received positive feedback on earlier
drafts of these edits from other browser implementors.

Thanks for your attention,
zw

---- proposal begins ----

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

Section 1.3: Delete the entire second paragraph.

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

Delete the paragraph that begins "Certificate types 1 and 2 explicitly
only apply ..." (having been folded into the above).

Section 2.3:  Delete all text before the beginning of section 2.3.1.
(Equivalent but clearer text will reappear in section 3.)

Section 2.3.1: Move contents to section 3.4 (marked below).

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.

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

 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.

    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:

    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.

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

 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.

    Therefore, a DANE client in possession of a trusted TLSA record
    for a server MUST determine whether that TLSA record associates
    the server's domain name with the certificate bundle it provides
    in the TLS handshake.  If it does not, a DANE client MUST reject
    the end-entity certificate and abort the TLS handshake with an
    "access_denied" error.  This rule applies even if the end-entity
    certificate would have been trusted in the absence of the TLSA
    record.

    Conversely, if the TLSA record _does_ associate the server's
    certificate bundle with its domain name, a DANE client MUST treat
    the end-entity certificate as possessing a valid chain to a trust
    anchor, until the TTL of the TLSA record expires.  In other words,
    under these circumstances a DANE client MUST NOT reject a server's
    end-entity certificate solely for lack of a trust anchor.
    Furthermore, if the TLSA record providing the association has
    certificate type 1, a DANE client MUST NOT reject an end-entity
    certificate for violation of the PKIX rules that are relaxed by
    section 3.4 of this specification.

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

    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.

    DANE does not assure any information in a certificate other than
    the public key and its binding to host, protocol, and port.  Most
    importantly, DANE does _not_ assure any non-DNS name records.

 3.4. Relaxation of PKIX semantics for self-signed certificates

    (insert former contents of section 2.3.1 here)

 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.

    A client that has good reason not to comply with this requirement,
    such as a forensic tool, SHOULD assume that the other end of a
    forced connection is actively malicious.  Therefore, the client
    SHOULD take precautions to avoid compromising the local computer
    or any of the user's data, such as:

    o  Not transmitting "cookies" or any other information that should be
       confidential to the legitimate server;
    o  Not executing any code (e.g. JavaScript) received over the
       connection;
    o  Not triggering further network traffic based on the normal
       semantics of the data received (e.g. images referenced by an
       HTML page) without explicit user instructions to do so.

---- proposal ends ----