Draft: draft-ietf-tls-dnssec-chain-extension-05

Commentary: Draft 05 . Tried to address all the outstanding comments during the WGLC . Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version .
Servers receiving a "dnssec_chain" extension in the ClientHello, and
which are capable of being authenticated via DANE, SHOULD return a
serialized authentication chain in the Certificate message associated
with the end entity certificate being validated, using the format
described below.  The authentication chain will be an extension to
the certificate_list to which the certificate being authenticated
belongs.
Servers receiving a "dnssec_chain" extension in the ClientHello, and
which are capable of being authenticated via DANE, SHOULD return a
serialized authentication chain in the extension block of the
Certificate message containing the end entity certificate being
validated, using the format described below.
The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRSIG) records.
The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRSIG) record sets.
Each RRset in the chain is composed of a sequence of wire format DNS
resource records.  The format of the resource record is described in
RFC1035, Section 3.2.1.  The resource records SHOULD be presented in
the canonical form and ordering as described in RFC4034.
RRs within the RRset MAY be ordered canonically, by treating the
RDATA portion of each RR as a left-justified unsigned octet sequence
in which the absence of an octet sorts before a zero octet.
Each RRset in the chain is composed of a sequence of wire format DNS
resource records.  The format of the resource record is described in
RFC1035, Section 3.2.1.
A TLS client making use of this specification, and which receives a
DNSSEC authentication chain extension from a server, SHOULD use this
information to perform DANE authentication of the server.  In order
to do this, it uses the mechanism specified by the RFC4035.  This
mechanism is sometimes implemented in a DNSSEC validation engine or
library.
If the authentication chain is correctly verified, the client then
performs DANE authentication of the server according to the DANE TLS
protocol RFC6698 RFC7671.
A TLS client making use of this specification, and which receives a
DNSSEC authentication chain extension from a server, SHOULD 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.
Clients MAY cache the server's validated TLS RRset or other validated
portions of the chain as an optimization to save signature
verification work for future connections.  The period of such caching
MUST NOT exceed the TTL associated with those records.
A TLS server certificate MAY mandate the use of this extension by
means of the X.509 TLS Feature Extension described in RFC7633.  This
X.509 certificate extension, when populated with the dnssec_chain TLS
extension identifier, indicates to the client that the server must
deliver the authentication chain when asked to do so.  (The X.509 TLS
Feature Extension is the same mechanism used to deliver other
mandatory signals, such as OCSP "must staple" assertions.)  Mandating
this extension for Raw Public Key authentication (where there are no
X.509 certificates) could employ configuration mechanisms external to
the TLS protocol.
The security considerations of the normatively referenced RFCs (1035,
4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this
extension.  Since the server is delivering a chain of DNS records and
signatures to the client, it MUST rebuild the chain in accordance
with TTL and signature expiration of the chain components as
described in sec_caching.  TLS clients need roughly accurate time in
order to properly authenticate these signatures.  This could be
achieved by running a time synchronization protocol like NTP RFC5905
or SNTP RFC5905, which are already widely used today.  TLS clients
MUST support a mechanism to track and rollover the trust anchor key,
or be able to avail themselves of a service that does this, as
described in sec_trustmaint.
Green field applications that are designed to always employ this
extension, could of course unconditionally mandate its use.
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.
The security considerations of the normatively referenced RFCs all
pertain to this extension.  Since the server is delivering a chain of
DNS records and signatures to the client, it MUST rebuild the chain
in accordance with TTL and signature expiration of the chain
components as described in sec_caching.  TLS clients need roughly
accurate time in order to properly authenticate these signatures.
This could be achieved by running a time synchronization protocol
like NTP RFC5905 or SNTP RFC5905, which are already widely used
today.  TLS clients MUST support a mechanism to track and rollover
the trust anchor key, or be able to avail themselves of a service
that does this, as described in sec_trustmaint.