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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
