[TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Christopher Wood <[e-mail]>]

Notes from the TLS interim meeting held in September are now online
[1]. To recap, the meeting attempted to focus on three primary
questions:

1. What is the fundamental security issue? What is the purpose of this
extension?
2. Under what circumstances should DNS records received in the
extension be cached and reused for future use?
3. Is pinning required? If so, what is pinned, and at what layer(s)
should it be implemented?

Most of the time was spent on question #1. In an attempt to get to the
root cause of the disagreement amongst participants, we have since
attempted to go back to a clean  slate, gaining an understanding of
the "facts on the ground" that motivate a need for this extension and
how current technologies operate, and move forward from that common
understanding to reach a shared picture of a clear problem statement.
Once a clear problem statement is agreed upon, it should be easier to
analyze proposed solution(s) for whether they solve that problem
statement without introducing unacceptable risks into the broader
ecosystem.

To that end, here are some facts for which there seems to be consensus:

1. DANE provides two major use models. In the first model, it requires
that the server supply a certificate which would pass WebPKI
validation but must also have a CA certificate (usage 0) or EE
certificate (usage 1) which matches the TLSA record. In the second
model, the server may have a certificate or raw public key which need
not pass WebPKI validation, but either must chain to a certificate
which matches the TLSA record (usage 2) or must itself match the TLSA
record (usage 3). In the former model, the server operator still must
participate in the Web PKI, whereas in the latter model, it need not
do so.
2. Currently, DNSSEC failures are common in the last mile. Residential
routers and ISPs, might give out DNS resolvers that fail to deliver
(accurate) DNSSEC records. This makes delivery of DNSSEC (and TLSA)
records difficult. Thus, any client which must work in any network
environment cannot safely fail on DNSSEC failures (whether that
failure is overridable by the user or not) because that would result
in an unacceptable rate of failures. Further, clients have been
reluctant to implement even opportunistic use of DANE records because
of errors and latency concerns.
3. Certificate switching based on ClientHello contents is standard
practice, e.g., as is done for SNI-based certificate selection or for
servers which support multiple algorithms such as RSA and ECDSA. This
may also be used to monitor the deployment rate of this extension.

At risk of discussing a solution to the wrong (or a different)
problem, we should first settle the question about the purpose of this
draft. Once we settle on the problem(s) and determine if the proposal
adequately addresses it, we can then discuss technical details. In the
interest of moving things forward before Bangkok, we plan to timebox
these discussions as follows:

- October 8 through October 19: Discuss the problem statement. In
particular, if anyone feels the problem statement captured in the
draft introduction [2,3] or in the above "facts" is incorrect,
imprecise, or misleading, please say so, and say why (in a succinct
fashion). Questions regarding client pinning of the TLS extension, the
risks involved in doing so, and how server operators can recover from
pin DoS attacks are out of scope for this discussion.
- October 22 through November 2: Discuss the draft [2,3]. The chairs
will circulate a list of concrete questions to address before the
22nd.
- Bangkok: Discuss the draft [2,3] and open issues.
- After Bangkok: Call for consensus to continue iterating on the draft
as a WG item or abandon it, and proceed accordingly.

Best,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/minutes-interim-2018-tls-01-201809141000/
[2] https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07
[3] https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim