Subject: [TLS] Draft updates: tls-dnssec-chain

From: Shumon Huque <[email-masked]>
Date: Sat, 28 Apr 2018 12:19:49 -0400

> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey <[email-masked]> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 13:52:05 -0400

> On Apr 28, 2018, at 12:19 PM, Shumon Huque <[email-masked]> wrote:
> 

The last sentence makes no sense.  The term "Restrictive uses" is poorly
defined.  The reduction in scope is effectively a reduction to just the
cases where the extension is mandatory, if that's what you intend to do
then say so (expect pushback).

Please do not imply that any non-mandatory "additive" use-cases are
viable.  They are not.

-- 
	Viktor.

---

From: Richard Barnes <[email-masked]>
Date: Sat, 28 Apr 2018 18:17:10 +0000

> Please do not imply that any non-mandatory "additive" use-cases are

I agree with Viktor here.

You could imagine enforcing a restriction you see in a DANE extension the
cert you get milliseconds later, but that's pretty useless given that an
attacker can just not send the extension.  Let's just scope this to the
additive case.

>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 14:34:02 -0400

> On Apr 28, 2018, at 2:17 PM, Richard Barnes <[email-masked]> wrote:
> 
> Let's just scope this to the additive case.

When you say "additive case" do you mean to cover just applications
where the extension is mandatory?  Or you expect the extension to
also have some value when it is optional?

I thought I explained fairly well why optional use does not pan out,
there was no cost/benefit to refute the one I posted (quoted below).
Servers will never start deploying the non-mandatory 'additive case',
absent downgrade protection, it makes no sense for them to do that:

--- Viktor Dukhovni <[email-masked]>, 2018-04-08 19:27:36-0400 ---
  And yet, as it stands, the deployment cost-benefit analysis for this
  extension in existing applications plays out as follows:

  COSTS:

   * You still manage WebPKI certificates to support the majority of existing clients.
   * If the WebPKI is compromised, you're compromised.
   * If DNSSEC is compromised, you're compromised
   * You pay the complexity cost of also supporting the extension
   * You might present incorrect TLSA records and the connection might fail even when
     it would otherwise succeed with WebPKI

  BENEFITS:

   * Nothing other than bragging rights that you're cool enough to
     deploy a shiny new technology
---

Notably, just a confirmation that the above is basically sound:

--- Martin Thomson <[email-masked]>, 2018-04-05 12:07:57+1000 ---

  Your cost benefit analysis seems about right though.

---

So with downgrade protection out, the present scope is *exactly* the
applications where the extension is mandatory (whatever these might be).

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Apr 2018 14:34:45 -0400 (EDT)

On Sat, 28 Apr 2018, Shumon Huque wrote:

>    of existence chain,

The second sentence is just repeating the MAY and is not needed.

But more importantly, it does not specify what the extension content
should be in the absense of a signed TLSA record and not wanting to
put in the denial of existene. Are you expecting an empty payload?
A single NULL payload? Or are you expecting the extension should be
omitted entirely? And what is the expected client behaviour in that case?

>     otherwise it could not be deployed incrementally

It can be deployed incremendally as Viktor, Nico and I have shown
repeatedly with a two byte value.

>       ancestor of, or the same as, the TLSA record name.

"s/one of the following facts/either"

>    In the absence of such a proof, a TLS client

I think this belongs in the Security Section. It's a big security
problem and so should be explained in the Security Section.

>    offered the extension and use that knowledge to require it for

And as stated before, removing this is not enough. You need to explain
what the expected client behaviour is when the extension appears and
disappears, either in this section, a seperate section, or the Security
Section.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 14:51:18 -0400

> On Apr 28, 2018, at 2:34 PM, Paul Wouters <[email-masked]> wrote:
> 

The first commit in my pull-request provides a more complete description
of DoE processing.

  https://github.com/tlswg/dnssec-chain-extension/pull/14/commits/859b164a5369e8c997713711771cfb3f7d87c90a#diff-bcaaf747fc40b8dd4fe4e10917b518f2L370

Don't know whether the authors have had a chance to take a look.
The present text is IMHO still a bit too skimpy as you note:

  https://github.com/tlswg/dnssec-chain-extension/blob/master/draft-ietf-tls-dnssec-chain-extension-08.xml

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 28 Apr 2018 15:04:22 -0400

>> then say so (expect pushback).
Yeah, I agree the assertive and restrictive terms are poorly defined. I was
using terminology that this WG has been using for a while, but we can
reword.

> attacker can just not send the extension.  Let's just scope this to the
This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes
the latter case, I assume based on his (unproven) assertion that there will
no
incentive to deploy this. I don't agree. Lots of sites already publish DANE
for
HTTPS records even before browsers can use them (IETF, freebsd, debian,
torproject, defcon, ripe, etc). Once code is implemented/deployed they will
be
using it.

Shumon.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 15:21:54 -0400

> On Apr 28, 2018, at 3:04 PM, Shumon Huque <[email-masked]> wrote:
> 
> the latter case, I assume based on his (unproven) assertion that there will no
> incentive to deploy this.. I don't agree. Lots of sites already publish DANE for 
> torproject, defcon, ripe, etc). Once code is implemented/deployed they will be
> using it.

My arguments are sound.  Would you care to estimate what fraction of
published _443._tcp TLSA records actually match the site's certificate
chain?  What non-hobbyist sites publish such records?

It may be cool to play DANE for HTTPS when nobody is verifying, and
there's no operational burden of keeping the records correct, (the
one BENEFIT listed in my cost/benefit list), but real deployments
need real incentives.

With Let's Encrypt available, and no downgrade protection for
HTTPS with DANE (via this extension) the incentive to support
it is nil.

-- 
	Viktor.