Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni <[e-mail]>]

> On Apr 11, 2018, at 1:33 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> You say this, but to me it seems a relevant factor when determining the
> target scope for the spec.  That is, if some individual believes that
> DANE is amazing and the Web PKI is crap, then that individual is likely
> to want to see DANE take over for the Web PKI in authenticating Web TLS
> connections, and as such see that as a vital motivating factor for
> any work involving bundling DANE records in the TLS handshake.

My motivation for updates to the draft is that *neither*

	1. WebPKI sucks, DANE rules
	2. WebPKI rules, DANE sucks

is a good zealous position.  Each have their strengths and weaknesses.
For, example, for DV certificates, I am of the opinion that DANE is
more resistant to mis-issuance.

Given that neither 1. or 2. is objective truth, the draft should
support "restrictive" use where neither is fully trusted, and
and a server operator publishes (for _443._tcp) *restrictive*
DANE TLSA records with certificate usage PKIX-EE(1) or PKIX-TA(0),
with the expectation that when/if browsers that adopt and support
this specification they'll enforce *both* WebPKI *and* DANE.  But
that requires downgrade protection.  This applies to not just browsers,
but to any application in which the installed base is WebPKI, and
DANE is of necessity incremental and so opportunistic (used when
published, but not a-priori mandated).  Examples, IMAP, JMAP, NTTP,
XMPP, SUBMIT, LDAP, ...

As it stands, this draft fails to provide the downgrade protection
needed for opportunistic adoption.  It mentions in Section 8 that
some clients might apply an infinite pin (a fragile strategy), but
fails to describe denial of existence as a valid way to comply with
such a pin should TLSA records be removed.  And without a server
TTL hint, the infinite pins make adoption in multi-datacentre
deployments impractical.

The draft has a serious scope deficiency.  And indeed you're right
that the key issue is *scope*, but an overly narrow scope is
a substantial technical issue.  Further, little attention has
been paid in the WG to the scope issue, and the document sailed
through with discussion mostly around just the data formats,
and the key issue of scope fell through the cracks.

> Someone
> who is less keen on DANE over the Web PKI may not share that enthusiasm
> or confidence for focusing the scope on that use case.

I would say that WebPKI adherents would also want to make sure that
any use in existing WebPKI applications would be *restrictive* and
not either WebPKI or DANE whichever is weaker.  But then the draft
needs to have downgrade protection, and the applications in question
might (converse of RFC7672) require any DANE TLSA records with
usages other than PKIX-TA(0) or PKIX-EE(1) to be treated as "unusable".

So it all comes down to whether it is appropriate to go forward
with a very narrow scope (perhaps even too narrow for the initial
applications, but that's debatable) and ask future adopters in
new spaces to write new drafts (and pay the delay of having to
wait for those to get reviewed and adopted), or amend the
draft to anticipate future uses beyond the immediate motivating
use case.

My view is clearly in favour of an anticipatory scope.  Future
implementors in new applications would likely not bother to
start if the cost of that is going through the IETF process
for a new extension to augment this one.

-- 
	Viktor.