Subject: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Jul 2018 22:30:39 -0400

Below I shall try to address a few of the concerns raised in writing.
You can read just the high-level notes above my signature, diving
into the corresponding detailed exposition below my signature as
you see fit.  Apologies for lack of hypertext links.

0.  The draft as approved by the IESG, describes unilateral pinning
    by the client.  We all agree that was not a good idea, but it
    was a well-intended attempt to address a real security gap.

1.  The hypothetical "assertive use-case" Richard mentions that is
    based on just the current draft is a non-starter.  [ Sadly, Paul
    forgot to disabuse the audience of its possibility on Monday ]

    If the WebPKI is presumed never compromised then we don't need
    a DANE alternative.  With the present draft, DANE offers no
    protection when the WebPKI is compromised.

2.  Denial of existence reached consensus on list shortly after
    London, we just need to polish up the text.  It is also quite
    useful for the greenfield applications that can make do without
    pinning.  I was surprised to hear some suggest that denial of
    existence remains outside the WG consensus.

3.  Given denial of existence, a cached policy that strictly requires
    the extension (STS-like extension pinning) can be removed in
    multiple ways.  Clients can also initially limit the maximum
    pinned extension support lifetime, to avoid excessive exposure
    to any overly eager servers that promise more than they can
    deliver.

4.  Concern that the transport provider, not the domain owner commits
    to the downgrade protection of future connections.  This is
    mitigated by mutually agreed settings between the customer and
    the provider and the customer's freedom to drop TLSA records
    in advance of a provider switch.  The customer (domain owner
    can delete the TLSA records, and within one "extension support
    lifetime" all extant pins will expire.

5.  Concerns that more than a 2 byte lifetime is needed for a
    downgrade protection design.  Neither subdomain pinning nor a
    testing mode are good fit for a TLS-layer mechanism.  Other
    similar STS mechanisms have no additional knobs that might
    apply.

In summary, I'd like to propose that we get an updated draft out
the door *now* with denial of existence word-smithed and updated
security considerations based on Ben's text in the pull request.

We can then quickly follow that up with some final on-list discussion
around downgrade protection, be it a fixed two bytes of lifetime
(in TBD units with TBD implementation guidance for non-zero values),
or one byte of length (initially zero) for a TBD (initialy opaque,
TBD specification) payload.  I see no benefit from a nested extension
block.  This is just a needlessly more complex way of doing separate
extensions.

With either two bytes or an opaque<0..255>, libraries implement the
extension once, and applications can implement downgrade protection
with no new extensions needed in libraries once the TBD bits are
defined, just process the downgrade-protection payload.

My preference is for the two bytes, which simplifies the application
API (extension conveys a network short value rather than an opaque
octet string).  If all we need in addition is a testing bit, with
some sort of in-band signalling (new alert?) for the missing extension
halving the max lifetime from ~7.5 years, to ~3.8 years is fine,
and in any case we get to choose the scale to yield the right range,
15 bits of granularity is plenty.

That said, variable length (0 or up to 255) will do if there's
really a plausible use-case for more bells/whistles in the extension
that make sense at the TLS layer across the application ecosystem
(HTTPS, IMAP, XMPP, NTTP, SUBMIT, POP, ...).

The only remaining alternatives are to severely limit the application
scope or work on a separate (almost identical) extension that fixes
the issues in this one.  It would have all the features of this
one, plus the controversial payload, and would deprecate the present
draft on security grounds.

-- 
	Viktor.

0.  The draft as approved by the IESG, describes unilateral pinning
    by the client.  We all agree that was not a good idea, but it
    was a well-intended attempt to address a real security gap.

	This was added late in the original WG last call and went
	largely unnoticed by the community, including the IESG.  It
	was only when some of us tried to argue for a more robust
	downgrade-protection mechanism that the original unilateral
	pinning was noticed and pointed out, and at that juncture
	the draft went back to the WG to remove the unilateral TOFU
	pinning.  And yet the TOFU pinning was there in order to
	try to close the gap between the intended scope and actual
	security properties of the specification.

1.  The hypothetical "assertive use-case" Richard mentions that is
    based on just the current draft is a non-starter.  [ Sadly, Paul
    forgot to disabuse the audience of its possibility on Monday ]

    If the WebPKI is presumed never compromised then we don't need
    a DANE alternative.  With the present draft, DANE offers no
    protection when the WebPKI is compromised.

	For multiple years (perhaps a decade or more) of the initial
	deployment of the extension in some existing TLS application
	the majority of clients and servers will support only WebPKI
	and not DANE.  Servers that rely on this extension to
	authenticate a privately issued (or self-signed) certificate
	would therefore fail to interoperate with the vast majority
	of clients.  Clients that don't fall back to WebPKI in the
	absence of a DANE TLSA chain would not interoperate with
	the vast majority of servers.

	Rather than lose interoperability with the majority of
	potential clients, non-hypothetical servers will get a
	certificate from Let's Encrypt or similar and *then* perhaps
	consider getting *additional* security from DANE.  Only a
	negligible fraction of servers are going to select DANE-only
	just to save spending $0 on a WebPKI-certificate.  Similar
	considerations rule out a rapid transition to DANE-only
	clients.  The bast majority of clients will do WebPKI
	fallback.

	The extension, as defined in the present draft, can be
	trivially stripped by an attacker able to obtain a fraudulent
	WebPKI certificate.  Therefore, for existing applications,
	it neither obviates the need for WebPKI certificates, nor
	offers any additional security.  Some clients might by local
	policy mandate DANE with some servers, but this is not a
	scalable model for the Internet.

	So all that one gets from (assertive) WebPKI + DANE is the
	extra complexity cost of managing TLSA records in DNSSEC
	and the cost of possible failure if TLSA record update
	automation fails.  There is no benefit at all, so even
	correctly managed TLSA records are just extra baggage, that
	gains no security beyond WebPKI.  This guarantees negligible
	deployment.

	If DANE is to have any use at all, it MUST be downgrade
	resistant.  This is not controversial, when last discussed,
	even the majority (even those who've been rather reluctant
	to support "pinning") of responses broadly agreed with the
	cost/benefit analysis that showed DANE without downgrade
	protection to be all cost and no benefit.

2.  Denial of existence reached consensus on list shortly after
    London, we just need to polish up the text.  It is also quite
    useful for the greenfield applications that can make do without
    pinning.  I was surprised to hear some suggest that denial of
    existence remains outside the WG consensus.

	Denial of existence helps even/especially in the immediate
	"green field" use-case, i.e. in applications that mandate
	the extension.  Such clients can then interoperate with
	servers that are (to coin a term) "DANE chain ready", but
	don't yet have DNSSEC or have not yet worked out the
	operational details of publishing TLSA records.

	The server can send a denial of existence proof (even if
	its own zone is unsigned, in which case it sends proof of
	that from some ancestor domain), and then the client can
	securely fall back to WebPKI, or TOFU...

3.  Given denial of existence, a cached policy that strictly requires
    the extension (STS-like extension pinning) can be removed in
    multiple ways.  Clients can also initially limit the maximum
    pinned extension support lifetime, to avoid excessive exposure
    to any overly eager servers that promise more than they can
    deliver.

    a.  Start sending a TTL of zero, authenticated via the current
	DANE TLSA records.

    b.  Delete the TLSA records.  Send a denial of existence proof.

    c.  Stop doing DNSSEC.  Send a denial of existence proof,
	of insecure delegation of the domain.

    If any of the above happens at least one "pin lifetime" prior
    to moving the service to a new platform that does not support
    the extension, there is no friction for clients that reconnect
    after a long break.

    If the proposed scale of 1h-65536h (max out at ~7.5 years)
    is deemed too risky on the high end, perhaps we can reach
    consensus on units of minutes, which tops out at ~45.5 days.
    That would cover the majority of recurrent connections to
    a site, while allowing a timely planned move to a provider
    that does not support the extension.  It would still
    adequately cover MUAs sending and receiving email, NNTP and
    XMPP clients, connecting regularly to their servers, ...

4.  Concern that the transport provider, not the domain owner commits
    to the downgrade protection of future connections.  This is
    mitigated by mutually agreed settings between the customer and
    the provider and the customer's freedom to drop TLSA records
    in advance of a provider switch.  The customer (domain owner
    can delete the TLSA records, and within one "extension support
    lifetime" all extant pins will expire.

	Yes, the commitment signal comes from the transport provider,
	but denial of existence resets or prevents a strict extension
	requirement, so a strict policy can only be set when the
	domain has both DNSSEC and TLSA records.  The transport
	provider would *not* be able to pin the extension in the
	absence of DNSSEC and TLSA records at the served domain.
	Presumably, the domain owner would like to see the TLSA
	records used, else why publish them.

	One might also expect that the transport endpoint provider
	is operating the service for the benefit of and in concert
	with the domain owner.  If the domain owner wants no pinning,
	or pinning for just a short time (days or weeks, not months
	or years), then that's what the transport provider will be
	be delivering (or they'll not have very many customers).

5.  Concerns that more than a 2 byte lifetime is needed for a
    downgrade protection design.  Neither subdomain pinning nor a
    testing mode are good fit for a TLS-layer mechanism.  Other
    similar STS mechanisms have no additional knobs that might
    apply.

	a. At least an extension lifetime TTL is needed to address
	   the downgrade attack.  Zero bytes is definitely not
	   enough.

	b. DANE TLSA records are seervice-specific, they cover *one*
	   port on one named transport endpoint.  Pinning subdomains
	   as in some STS variants is not natural here.  DANE chain
	   stapling is a transport-layer (TLS) not an application-layer
	   mechanism.  Robust pinning for subdomains drags in the
	   public suffix list, and is much too complex for a
	   general-purpose TLS-layer mechanism.

	c. Testing is not a good fit at this layer, all that's
	   pinned is the ability to deliver the extension, after a
	   previous connection delivered DANE TLSA records and a
	   non-zero extension support lifetime.  There is no TLS-layer
	   mechanism for the client to inform servers that don't
	   offer the extension that this extension was expected
	   while continuing the connection.  The closest we get is
	   the TLS 1.3 missing_extension(109) alert, which does not
	   carry the id of the mission extension, and is a failure
	   alert.  Out-of-band notification would require HTTP
	   support in applications that can't generally be expected
	   to include an HTTP implementation.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jul 2018 01:54:09 -0700

>            to include an HTTP implementation.

To the extent to which this is true, it's an argument that one should be
pinning at a different layer.

-Ekr

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

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Jul 2018 08:41:59 -0400

> pinning at a different layer.
(I've mentioned this in private email to some of you, but for broader
input, I'm throwing it out on the list too.)

On the topic of other layers ..

At yesterday's WG meeting, Sam Weiler suggested that the pinning
information could be conveyed via the DNS. That way you would not need new
holes/fields in the TLS extension. Paul said it doesn't work. But Willem
Toorop and I discussed it after the meeting, and think that it does.

There could be a new DANEPIN RR type at the same TLSA record name (or TXT
if we're opposed to new types) that could carry the pinning TTL and
whatever else. This could be conveyed as just an additional record (and its
signature) in the dnssec_chain extension data (which is designed as a
sequence of RRsets), and authenticated in the same manner. It is of course
vulnerable to stripping on first contact, but so is the entire TLS
extension including any pinning fields, in the incremental deployment
scenario. So it has no worse or better security properties.

This could also express a generic DANE pinning capability that is not tied
only to a TLS channel.

Servers that don't want to be pinned would not advertise this record, and
clients that don't implement pinning would just ignore this record if it is
present in the chain.

(It is probably possible to convey this DNS info in other ways, such as
defining a new TLSA record usage field for pinning. So the TLSA RRset would
include an additional record for pinning if needed. But I suspect there
might be more arguments about such a design).

This does need the dnssec_chain extension to allow authenticated denial
chains to be delivered. Based on past list discussion, it appears to me
that there is rough consensus to allow that, and the yet unpublished draft
text in the github repo already includes it.

Shumon Huque

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Jul 2018 10:07:10 -0400 (EDT)

On Wed, 18 Jul 2018, Eric Rescorla wrote:

>     detailed response to concerns raised in the room on Monday
> 
> On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni <[email-masked]> wrote:

Those clients with clean DNS transport, like mail servers, already use
the TLSA records the moment these appear in DNS. The zone owner already
fully commited the service to this, regardless of what you do at other
layers. So you are already commited to the DATA in DNS.

Each transport has their own properties and we found that pinning the
TLS extension is needed when using TLS stappling. It is a property of
the transport lawyer, so anything about that transport layer should
not happen elsewhere.

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Jul 2018 13:37:33 -0500

Hi Viktor,

Thanks for writing up your thoughts; a couple notes inline:

> 1.  The hypothetical "assertive use-case" Richard mentions that is

I think that the use of the shorthand terms "assertive" and "restrictive"
for use cases is only causing confusion at this point, not least because
it could apply both to the TLSA Certificate Usage values and to whether
DANE is treated as less trusted, equally trusted, or more trusted than PKIX.
If I remember the detailed discussion below correctly, you refer to the
case of "DANE is equally trusted as PKIX", for which the analysis of "all
the costs of both with no benefits" is a tolerable summary.

>     existence remains outside the WG consensus.

I would also be surprised to hear such suggestions; text on denial of
existence is already staged in github and is just waiting on a decision
to publish a new draft.  (Which is, I presume, waiting for an indication
of whether we're likely to gain consensus soon on any other issues that
could be addressed in the same update.)

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Jul 2018 22:13:16 -0500

> pinning at a different layer.

Whichever layer the pinning is to be done at, the thing to pin, and for
how long, all need to be transported, and since that thing is in TLS, so
should the "for how long".

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Jul 2018 22:23:49 -0500

> Toorop and I discussed it after the meeting, and think that it does.

I agree that it _could_ be done with a DNS RR.  However, that has two
negative effects: 1) it will bloat the extension's payload more than the
two bytes we're asking for, 2) it complicates deployment / the
operator's life.

With a pin TTL in the extension the server operator can change it at
any time without further ado -- it's just a config file setting.

With a pin TTL in a DNS RR the server operator has to make a zone file
update.  That could be easy or not -- it varies.

> This could also express a generic DANE pinning capability that is not tied

That's more like the other flavors of pinning we've been told have
rougher operations characteristics.

It's certainly true that we could specify and implement such a thing,
and that it would be useful for some applications.  However, it wouldn't
be as convenient as just the extension pinning in this case.

For example, with pinning to the extension + DoE, a server could
implement the extension asynchronously from deploying DANE.  In fact, it
could just be enabled by default, and always send DoE when you don't
have DANE deployed.  And then the moment you deploy DANE, presto, you're
protected.  And if you want to turn off pinning?  Just edit the server's
configuration file -- no need to go update the zone(s).

We should always look to make deployment easier, and extension pinning
does that more than a DANE pin DNS RR type would.

Surely we want our protocols to be deployable.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 Jul 2018 12:16:18 -0400

> two bytes we're asking for, 2) it complicates deployment / the

In any realistic deployment, the publisher of the TLSA records is
the *same* entity that provisions the certificate chain, anything
else is operationally untenable.

In absence of indirection via SRV records, the only way to combine
DANE with hosting by a provider that is not also managing the
domain's DNS records is to use CNAMEs as follows:

    Customer1 DNSSEC zone:

	www.example.com. IN CNAME dane-host.example.net.
	_443._tcp.www.example.com. IN CNAME _443._tcp.dane-host.example.net.

    Provider DNSSEC zone:

	dane-host.example.net. IN A 192.0.2.1
	_443._tcp.dane-host.example.net. IN TLSA 3 1 1 b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34
	_443._tcp.dane-host.example.net. IN TLSA 3 1 1 8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f

The client will send an SNI of "www.example.com", which the server
needs to be pre-configured to accept.  The server will then return
the corresponding cached CNAME and shared TLSA RRset with all
approrpriate signatures, DNSKEY and DS records.

	; per-customer CNAME RR, cached on server.
	;
	_443._tcp.www.example.org. IN CNAME _443._tcp.dane-host.example.net.

	; shared target TLSA RRset, cached on servr.
	;
	_443._tcp.dane-host.example.net. IN TLSA 3 1 1 b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34
	_443._tcp.dane-host.example.net. IN TLSA 3 1 1 8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f

With the DANE TLSA records published by the provider, and extension
support deployment across the various server farms also in the hands
of the provider, there is little point in fetching the extension
support lifetime from DNS.  Either way the *provider* includes it
with the chain data, but it is much easier to manage it as just
configuration.

The extension support lifetime is a TLS-specific property, and has
no relevance for clients that can (afford to) do direct DNS lookups.
It belongs in the TLS extension and not in DNS.

--
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Jul 2018 14:44:06 -0500

> else is operationally untenable.

To make it short, the problem is that with A RRs the customer has to
update TLSA RRs to match the hosting site's, and has to do this on a
timely basis.  That can certainly be arranged, but I agree that at least
initially, and until this is generally automated, that will indeed be a
problem.  But I'm not too concerned because it is just a matter of
automation.

My issues with a new DNS RR for specification of pinning remain.

Nico
--

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 28 Jul 2018 08:32:36 -0700

(Reviving this thread to help the WG move forward on getting this 
document published)

> Toorop and I discussed it after the meeting, and think that it does.

In reading this thread, I agree with Shumon and others that the new RR 
proposal works, and it adds pinning in the DNS layer. However, I agree 
with Viktor and Niko that it is more complicated than an indicator in 
the chain extension about the pinning desired by the TLS server.

As was discussed by many people at the mic line at the meeting, pinning 
is both important and difficult to get correct. Picking the "right" 
layer at which to pin is probably one of those architectural guesses 
that we might just have to make. Given that, my preference is for the 
simplest solution that actually and fully gives pinning for the TLSA 
record, and at this point that would be in the extension itself.

--Paul Hoffman