Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni <[e-mail]>]

On Tue, Jul 03, 2018 at 10:41:18AM -0400, Allison Mankin wrote:

> I haven't chimed in on the mailing list on this draft, but I'm one of the
> people who had discussions with browserfolk in hallways, in the corners of
> interim meetings for HTTP2, and other such places, in order to see what it
> would take to get a start on TLSA use by browsers.

The present dilemma for this draft is how to ensure that it has
enough security benefit to warrant deployment and sufficient scope
to cover would-be applications.  The draft as originally approved
had two major defects:

    * Required not only extension support, but also DNSSEC and DANE
      TLSA records in order to support "greefield" applications that
      mandate the extension from the get-go.

    * No plausible path to incremental adoption by existing WebPKI
      applications, that can't mandate the extension (let alone
      DNSSEC and DANE), but might employ DANE when present, but
      otherwise continue with WebPKI alone.

The first defect is addressed by incorporating denial of existence.
This allows a server to present an extension that proves lack of
DNSSEC for a containing DNS zone or just absence of the associated
TLSA records.  In this way "greenfield" applications that mandate
the extension can interoperate with servers that have not yet
deployment DNSSEC or DANE.

The second defect requires at least the ability to mandate the
extension, when a server commits to continue to present it for some
time.  Since pinning is potentially fragile, we should be pinning
as little as possible.  Hence once again only support for the
extension, rather than a continued expectation of DNSSEC, DANE,
particular certificate details, ...  This is NOT HPKP.  This requires
denial of existence support, adding which fortunately seems to have
broad consensus.

> Looking forward to discussion in Montreal.

I'd like to see as much of the discussion as possible on list, where
we can get responsive comments from informed participants, and not
just "humming".

> > 1.  Do you support the working group taking on future work on a pinning
> > mechanism (based on the modifications or another approach)?
>
> I support future work if there is extensive engagement and involvement by
> members of the browser community who have expressed concerns about pinning.

    * TLS is not exclusively for HTTPS.

    * This extension is NOT just about browsers. It should support
      IMAP, SUBMIT, POP, XMPP, NNTP, ...

    * The "concerns about pinning" are often related to the
      unsurprising failure of HPKP.  It is unfortunate that HPKP
      has tainted "pinning".  And yet the IETF has just approved
      MTA-STS, which pins a commitment to WebPKI authentication along
      with a list of the domain's MX hosts.

      It is easy to taint the proposed downgrade protection mechanism
      by associating it (incorrectly) with HPKP.  The proposal DOES
      NOT pin the peer certificates or keys.  This is an STS-lite
      proposal, that pins only a capability: support for the extension
      for a particular TLS service endpoint.  And in this case no
      "testing" mode is applicable, and sub-domain pinning is
      impactical.  Looking at the existing STS-like protocols, it is
      easy to see that only their TTL applies here.

> Reserving the bytes without a mechanism is not a good idea, so no.

I don't see a rationale for this.  The mechanism is a TTL to be
carried in those bytes.  We're willing to accept a variable-length
field in order to accommodate objections that a TTL *might* not be
enough, and a compelling case for additional attributes might be
made in the future.  I'm confident that no such case will hold up
to scrutiny.

-- 
	Viktor.