Re: [TLS] Proposed text for dnsssec chain extension draft

[Eric Rescorla <[e-mail]>]

Hi Victor,

Thanks for producing some text. I understand why one might think that
having a
reserved 16-bit field is useful here, but I don't really agree.

The conventional reason to reserve this kind of field is that you need to
leave
space for an extension in some PDU, because it's hard to add later. But
that's
not true here (or in TLS in general) because we already have an extension
mechanism (indeed, the one that's being used by this specification). If we
end up having consensus to do pinning, then it's straightforward to define
a new TLS extension that provides it.

If you look at HPKP and Expect-CT, you will note that there are a number of
other fields besides just lifetime (report-uri, include subdomains). I
recognize
that opinions vary about whether these are good, but the advantage of having
a whole new extension is that we need not resolve those now in order to move
this document forward. As far as I can tell, the primary disadvantage of a
new
extension is a slight increase in the size of the TLS handshake if the
extension
is used (balanced against two wasted bytes in this proposed design if it is
not used). That doesn't seem like a good set of tradeoffs.

-Ekr



On Tue, Apr 24, 2018 at 10:33 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
> I've been asked to write up proposed changes to the DNSSEC chain
> extension draft (with the 16-bit extension support lifetime field).
> In doing that I've discovered that adding the 16-bit field is a
> minor tweak to the document text, but, ironically, describing
> denial of existence, though a simple idea, requires extensive
> surgery to the document.  Below I do both, in the hope that either
> or both will prove useful.  Perhaps a concrete proposal will make it
> easier to reach a mutually-agreeable consensus position, and make it
> clear that the requested 16-bits are a reasonable consensus outcome.
>
> I'm also willing to create a pull request against:
>
>    https://github.com/MelindaShore/dnssec-serialization
>
> if there's interest in me doing that.  Below I list OLD/NEW text
> chunks with the name of the section in which they fit.
>
> --- Change 1:  Section 2.  Introduction.
>   * Add denial of existence
>
> OLD:
>
>    The extension described here allows a TLS client to request that the
>    TLS server return the DNSSEC authentication chain corresponding to
>    its DANE record.  If the server is configured for DANE
>    authentication, then it performs the appropriate DNS queries, builds
>    the authentication chain, and returns it to the client.  The server
>    will usually use a previously cached authentication chain, but it
>    will need to rebuild it periodically as described in Section 5.  The
>    client then authenticates the chain using a pre-configured trust
>    anchor.
>
> NEW:
>
>    The extension described here allows a TLS client to request that the
>    TLS server return the DNSSEC authentication chain corresponding to
>    its DANE TLSA resource record set (RRset), or authenticated denial
>    of existence of that RRset.  If the server supports this extension
>    it performs the appropriate DNS queries, builds the authentication
>    chain, and returns it to the client.  The server will usually
>    use a previously cached authentication chain, but it will need
>    to rebuild it periodically as described in Section 5.  The client
>    then authenticates the chain using a pre-configured trust anchor.
>
>    When the requested TLSA RRset does not exist, and/or the containing
>    DNS zone is not DNSSEC-signed, the server MAY return a chain of
>    records that establish authenticated denial of existence of the
>    TLSA RRset, or prove insecure delegation (an ancestor) of that domain.
>    Alternatively, the server MAY simply not negotiate the extension.
>
>
> --- Change 2:  Section 3.4.  DNSSEC Authentication Chain Data
>   * Add 16-bit SupportLifetime field
>
> OLD:
>
>    The "extension_data" field of the "dnssec_chain" extension MUST
>    contain a DNSSEC Authentication Chain encoded in the following form:
>
>
>              opaque AuthenticationChain<1..2^16-1>
>
>
> NEW:
>
>    The "extension_data" field of the "dnssec_chain" extension MUST
>    contain a DNSSEC Authentication Chain encoded in the following form:
>
>         struct {
>              uint16 SupportLifetime;
>              opaque AuthenticationChain<1..2^16-1>;
>         } DnssecChainExtension;
>
>    A zero "SupportLifetime" prohibits the client from unilaterally
>    requiring ongoing use of the extension based on prior observation
>    of its use (pinning).
>
>    A future specification will define the semantics of non-zero
>    values of the SupportLifetime field.  Servers implementing only
>    the present specification MUST set the SupportLifetime element
>    to zero.  Clients implementing only the present specification MUST
>    treat any value received as though it were zero.
>
> --- Change 3:  Section 3.4.  DNSSEC Authentication Chain Data
>   * Add denial of existence
>
> OLD:
>
>    The first RRset in the chain MUST contain the TLSA record set being
>    presented.  [...]
>
>    The subsequent RRsets MUST contain the full set of DNS records needed
>    to authenticate the TLSA record set from the server's trust anchor.
>    [...]
>
> NEW:
>
>    When the response contains validated TLSA records,
>    the first RRset in the chain MUST contain the TLSA record set being
>    presented.  [...]
>
>    When the response is an authenticated denial of existence, after
>    any initial DNSSEC-signed CNAME and/or DNAME records redirecting
>    the requested TLSA RRset, the next RRset in the chain MUST be the
>    signed SOA record of the domain that is proving the non-existence
>    of the TLSA RRset or its insecure delegation.  The SOA record MUST
>    be followed by the relevant signed NSEC or NSEC3 records.
>
>    The subsequent RRsets MUST contain the full set of DNS records
>    needed to authenticate the TLSA record set or denial of existence
>    response via the server's trust anchor.  [...]
>
> --- Change 4:  Section 3.4.  DNSSEC Authentication Chain Data
>   * Add denial of existence examples:
>
> OLD:
>
>    The following is an example of the records in the AuthenticationChain
>    [...]
>              RRSIG(. DNSKEY)
>
> NEW:
>    The following is an example of the records in the AuthenticationChain
>    [...]
>              RRSIG(. DNSKEY)
>
>    The following is a TLSA RRset denial-of-existence example:
>
>              example.com. IN SOA
>              RRSIG(example.com. SOA)
>              example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC
>              RRSIG(example.com. NSEC)
>              example.com. DNSKEY
>              RRSIG(example.com. DNSKEY)
>              example.com. DS
>              RRSIG(example.com. DS)
>              com. DNSKEY
>              RRSIG(com. DNSKEY)
>              com. DS
>              RRSIG(com. DS)
>              . DNSKEY
>              RRSIG(. DNSKEY)
>
>    The following is an insecure delegation example (with NSEC3 opt-out):
>
>              com. IN SOA
>              RRSIG(com. SOA)
>              GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3 (1 1 0 -
>                 - GPIOVE5CC3CA0D1H14G1GI4J0835GEKB  NS DS RRSIG)
>              RRSIG(GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3)
>              com. DNSKEY
>              RRSIG(com. DNSKEY)
>              com. DS
>              RRSIG(com. DS)
>              . DNSKEY
>              RRSIG(. DNSKEY)
>
> --- Change 5: Section 6.  Verification
>   * Add denial of existence
>   * Note that TLSA records might not be "usable" (new issue
>     in the document, sorry, but clients should not have to
>     honour unusable TLSA records)
>
> OLD:
>
>    A TLS client making use of this specification, and which receives a
>    DNSSEC authentication chain extension from a server, MUST use this
>    information to perform DANE authentication of the server.  In order
>    to do this, it uses the mechanism specified by the DNSSEC protocol
>    [RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
>    DNSSEC validation engine or library.
>
> NEW:
>
>    A TLS client making use of this specification, which receives
>    a verifiable DNSSEC authentication chain extension from a server,
>    MUST use this information to perform DANE authentication of the
>    server when the response is not a denial of existence and has
>    at least one "usable" TLSA record as defined in [RFC6698], [RFC7671]
>    and any other applicable specifications (perhaps application-specific).
>
>    Verification of the authentication chain extension uses the
>    mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155].
>    This mechanism is sometimes implemented in a DNSSEC validation
>    engine or library.
>
>    [... New final paragraph for Section 6 ...]
>
>    Clients MAY also cache a denial of existence response up to the
>    validated negative TTL of such a response.
>
> --- Change 6: Section 8.  Mandating use of this extension
>   * Prohibit unilateral pinning, clarify downgrade.
>
> OLD:
>
>    If TLS applications want to mandate the use of this extension for
>    specific servers, clients could maintain a whitelist of sites where
>    the use of this extension is forced.  The client would refuse to
>    authenticate such servers if they failed to deliver this extension.
>    Client applications could also employ a Trust on First Use (TOFU)
>    like strategy, whereby they would record the fact that a server
>    offered the extension and use that knowledge to require it for
>    subsequent connections.
>
>    This protocol currently provides no way for a server to prove that it
>    doesn't have a TLSA record.  Hence absent whitelists, a client
>    misdirected to a server that has fraudulently acquired a public CA
>    issued certificate for the real server's name, could be induced to
>    establish a PKIX verified connection to the rogue server that
>    precluded DANE authentication.  This could be solved by enhancing
>    this protocol to require that servers without TLSA records need to
>    provide a DNSSEC authentication chain that proves this (i.e. the
>    chain includes NSEC or NSEC3 records that demonstrate either the
>    absence of the TLSA record, or the absence of a secure delegation to
>    the associated zone).  Such an enhancement would be impossible to
>    deploy incrementally though since it requires all TLS servers to
>    support this protocol.
>
> NEW:
>
>    Pending a future specification that defines the semantics of
>    non-zero values of the SupportLifetime element of the extension,
>    clients MUST NOT employ "pinning" to require use of the extension
>    by servers previously observed to support it.  Servers that
>    implement only this specification MUST set the SupportLifetime
>    element to zero.
>
>    In the absence of "pinning", when the extension is not mandatory,
>    a client cannot reliably determine which servers don't have TLSA
>    records. Hence, a client communicating with a server that has
>    fraudulently acquired a public CA issued certificate for the real
>    server's name, could be induced to establish a PKIX verified
>    connection to a rogue server that simply omits this extension.
>
>
> --- Editorial Appendix A.  Test vectors
>
>   s/reproducability/reproducibility/
>
>   This section should probably include new denial of existence test
> vectors.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>