[TLS] Draft updates: tls-dnssec-chain

[Shumon Huque <[e-mail]>]

> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey <[e-mail]> wrote:

> Concerns have been raised about the trade-offs associated with pinning
and I do not think we currently have consensus to add pinning.  While I
think it may be possible to come to consensus on pinning I think it may
take some time.  I believe we can quickly get consensus for the following
approach:
>
> 1. Scope the document to the assertive use cases
> 2. Explicitly allow (but do not require) DoE be included
> 3. Remove current text about pinning
> 4. Re-submit the document for publication and start work on a separate
extension that supports pinning


Hi Joe,

Here is the proposed text for items 1, 2, and 3. It's also in the
tls-wg github repo. We'll probably tweak and wordsmith some more,
but this is the gist of it.


> 1. Scope the document to the assertive use cases

* Added scope description to Intro:

   This specification can also be used to optionally convey
   authenticated denial of existence of TLSA records.  Restrictive uses
   that might require such proofs (such as the PKIX constraining modes
   of DANE, or where DANE should always be preferred over other modes of
   authentication such as traditional PKIX) are thus not in its intended
   scope.  Such restrictive uses can however be supported
   opportunistically.


> 2. Explicitly allow (but do not require) DoE be included

(Note: I've noticed Viktor has submitted some expanded text
describing denial of existence. We'll review and likely incorporate
much of that)

* New section: 3.4.1, that permits but doesn't require authenticated denial:

3.4.1.  Support for Authenticated Denial of Existence

   TLS servers that do not have a signed TLSA record MAY instead return
   a DNSSEC chain that provides authenticated denial of existence.  This
   specification does not require TLS servers to provide such a denial
   of existence chain, otherwise it could not be deployed incrementally
   in environments where not all TLS servers support this extension.

   Authenticated denial chains include NSEC or NSEC3 records that
   demonstrate one of the following facts:

   o  The TLSA record does not exist.

   o  There is no signed delegation to a DNS zone which is either an
      ancestor of, or the same as, the TLSA record name.


* Text in Section 8 (Mandating) that rewrites language that in the
  previous draft stated that it doesn't support denial of existence:

   This protocol allows TLS servers to prove that they don't have a
   signed TLSA record by returning a denial of existence chain.
   However, as explained in Section 3.4.1, it does not require TLS
   servers to do so.  In the absence of such a proof, a TLS 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.  Application ecosystems where all TLS
   servers are expected to implement this extension could require such
   authenticated denial proofs to be delivered by TLS servers that don't
   have signed TLSA records.


> 3. Remove current text about pinning

* Remove client initiated pinning para from Section 8:

  This paragraph was entirely deleted:

   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.


Thanks,
-- 
Shumon Huque