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

From: Joseph Salowey <[email-masked]>
Date: Wed, 4 Apr 2018 10:50:15 -0700

Hi Folks,

Some objections were raised late during the review of
the draft-ietf-tls-dnssec-chain-extension. The question before the working
group is either to publish the document as is or to bring the document back
into the working group to address the following issues:

- Recommendation of adding denial of existence proofs in the chain provided
by the extension
- Adding signaling to require the use of this extension for a period of
time (Pinning with TTL)

This is a consensus call on how to progress this document.  Please answer
the following questions:

1) Do you support publication of the document as is, leaving these two
issues to potentially be addressed in follow-up work?

If the answer to 1) is no then please indicate if you think the working
group should work on the document to include

A) Recommendation of adding denial of existence proofs in the chain
provided by the extension
B) Adding signaling to require the use of this extension for a period of
time (Pinning with TTL)
C) Both

This call will be open until April 18, 2018.

Thanks,

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 4 Apr 2018 17:33:27 -0400 (EDT)

On Wed, 4 Apr 2018, Joseph Salowey wrote:

> This is a consensus call on how to progress this document.  Please answer the following questions:
> 
> 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed
> in follow-up work?

I do NOT support publication of the document as-is.

> If the answer to 1) is no then please indicate if you think the working group should work on the document to
> include 
> 
> A) Recommendation of adding denial of existence proofs in the chain provided by the extension
> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)
> C) Both

These options need a bit of clarification.

If you do A) then by publishing the proof of non-existance records, you
can cancel any outstanding kind of pin done. And you would not need B)

But that requires the server farm consistently send the TLS extension at all
times. If they stop doing this, you have to somehow determine if this is
an attack or an administrative discontinuation. Doing a pin as per B)
would help identify if this is an attack or not. And a pin whose value
meants "no commitment" would allow for a farm of TLS servers where not
all servers have the extension (obviously at a price of reduced security)

So to support all cases, I would say C) but I think B) would get us
pretty far on a lot of deployments.

The document's intension is clearly to staple DNSSEC answers for the
TLSA query on the TLS handshake. Omiting proof of non-existence means
it fails to achieve its specified goal and makes this TLS extension
completely useless[*]

Paul
[*] The only use case would to accept WebPKI _or_ DNSSEC, which only
reduces the currently available security levels instead of increasing
it.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 4 Apr 2018 17:53:13 -0400

On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey <[email-masked]> wrote:

> the draft-ietf-tls-dnssec-chain-extension. The question before the
> working group is either to publish the document as is or to bring the
> document back into the working group to address the following issues:
>
> - Recommendation of adding denial of existence proofs in the chain

I support publication of the document as is.  I would also be comfortable
with a minor modification to say that TLSA certificate usages 0 and 1 (the
restrictive ones) MUST NOT be used with this mechanism.

Even if this document is restricted to the assertive use cases, it can
still be used in cases where clients and servers have agreed to forego the
"normal" PKI and rely on DANE, or in cases where servers are able to switch
between DANE and non-DANE authentication depending on the client's
capabilities.  The former pattern could be made to work in the web if there
were interest; I believe DKG has indicated that DPRIVE might fall in the
former category.

While there may be utility in the restrictive use cases, the discussion to
date indicates that there is sufficient complexity and controversy involved
in making that work that we should not block this document from enabling
assertive use cases while that is in progress.

--Richard

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 4 Apr 2018 15:12:02 -0700

On 4/4/18 2:53 PM, Richard Barnes wrote:
> I support publication of the document as is.  I would also be
> comfortable with a minor modification to say that TLSA certificate
> usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism.

The addition of text that clarifies that seems absolutely reasonable
to me.

I do think there would be a problem with adding additional complexity
to the extension to support functionality that nobody has said that
they intend to use (including the proponents of the changes), given
that the changes would not be introduced to correct an error in
the existing spec.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Apr 2018 19:27:36 -0400

> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <[email-masked]> wrote:
> 
> - Recommendation of adding denial of existence proofs in the chain provided by the extension
> - Adding signaling to require the use of this extension for a period of time (Pinning with TTL)

These are indeed the immediate proposed fixes, and ultimately the consensus call will be about
whether the fixes should be formalized and integrated or the document advanced as-is, but before
we consider them in a vacuum, I'd like to explain in some detail *why* they are needed.  This
requires firstly an examination of why the extension is needed in the first place, and what
use-cases it should address.  This will be detailed below, but first:

> 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed in follow-up work?
> 
> If the answer to 1) is no then please indicate if you think the working group should work on the document to include 
> 

For the record, (C) both.  And now to explain why:

The first thing to understand is why this extension is needed in the first place.  A partial
answer can bee seen in the introduction to the draft. Please pardon burying the lede, below
I quote from the text of the introduction in order of presentation, but the main point is closer
to the end:

  -----------------
  This draft describes a new TLS [RFC5246] [TLS13] extension for
  transport of a DNS record set serialized with the DNSSEC signatures
  [RFC4034] needed to authenticate that record set.
  -----------------

We should note that an empty record set (NXDOMAIN or NODATA) is still
a record set, and DNSSEC *authenticates* denial of existence, and it
is necessary to also support denial of existence, in order to support
downgrade-resistance against "TLSA-stripping".  The reason is that this
extension is not being introduced into brand new internet in which the
CA/B forum WebPKI does not exist and DANE will be the *only* way for
TLS clients to authenticate servers.  For this extension to coexist
with the WebPKI clients will need to be able to *some* servers via
DANE and others (those that don't have DANE TLSA records) via the
existing WebPKI.

Suppose that, in the absence of authenticated denial of existence,
and clients being able to rely on continued support for the extension:

   * As will be the cast for most existing applications, the client
     is willing to use the WebPKI when DANE TLSA records don't appear
     to be availble.

   * An attacker is able to obtain a fraudulent WebPKI certificate.

Then the attacker can impersonate the target server by leaving out
the extension and presenting just the fraudulent WebPKI certificate,
and the client will have to accept this even when the real server
previously employed the extension and provided TLSA records.

What the above establishes is that in mixed environments, i.e.
almost all use-cases for this specification, TLSA records provide
no additional protection, if WebPKI fails, security is compromised
even with DANE.

Some have argued that this is OK, that even though the above
"restrictive" use-case is unavailable we still get an "additive"
use case, where servers can be authenticated with DANE when
that happens to be present and otherwise WebPKI.  Sadly, that
use-case is largely a mirage.  Firstly, given the existing
dominant client base that only supports WebPKI, any server
would in any case still need WebPKI certificates (say from
Let's Encrypt), and that will suffice for all clients both
those that support DANE and those that don't.  Thus enabling
DANE on the server, only makes it possible to impersonate
the server if DANE is compromised, but does not defend against
WebPKI compromise.  So the server gets more complexity, and
reduced security, and maybe even increased risk of failure
if the TLSA records are managed carelessly and fail to match.

No rational server operator will employ the "additive" mode.
Some DANE idealists might do it to signal their support for
the technology, but this will be futile, they'll get no real
benefit from doing so.

Continuing on with the introduction:

  -----------------
  The intent of this
  proposal is to allow TLS clients to perform DANE Authentication
  [RFC6698] [RFC7671] of a TLS server without performing additional DNS
  record lookups and incurring the associated latency penalty.  It also
  provides the ability to avoid potential problems with TLS clients
  being unable to look up DANE records because of an interfering or
  broken middlebox on the path between the client and a DNS server
  [HAMPERING].  And lastly, it allows a TLS client to validate the
  server's DANE (TLSA) records itself without needing access to a
  validating DNS resolver to which it has a secure connection.
  -----------------

Here we see the promise of being able to get by without having
access to a validating resolver, but validating resolvers deliver
both signed data when present and signed proof of non-existence when
the requested records are absent.  But most importantly:

  -----------------
  This mechanism is useful for TLS applications that need to address
  the problems described above, typically web browsers or SIP/VoIP
  [RFC3261] and XMPP [RFC7590].
  -----------------

This plainly shows that browser HTTPS was a motivating use-case
for the extension.  Indeed earlier mention of latency concerts is
also based on the reasons why browsers don't (want to) do DANE even
when direct DNSSEC lookups are possible.

Not just browsers, no existing application can adopt specification
incrementally.  Even if the extension is required in the application,
it is unrealistic to expect that all server domains will rapidly
adopt DNSSEC.  At the moment there are ~6 million DNSSEC-signed
domains, substantially concentrated in northern Europe, with
fairly thin adoption generally (only ~800K domains out of ~120
million in .com).  An application that expects the extension
should expect to not find TLSA records for many servers it
connects to, indeed many server domains will be unsigned, and
the server would only be able to present denial of existence
for the DS records of a parent domain, proving its domain
"insecure" (in DNSSEC terms).

The modifications in (A) and (B) are most similar to STS (not HPKP)
and harden DANE-authenticated HTTPS against downgrade to just DV,
and make going to all the trouble of supporting the extension at
the server a tangible security benefit.  Absent such a benefit,
no reasonable server operator will implement the extension. Just
deploying a WebPKI certificate, which is necessary in any case,
provides the same protection with less effort.

The pin-time in (B) also allows servers to signal a zero pin time,
and thus indicate an incomplete deployment, reducing breakage when
clients find the extension partially deployed, but decide to expect
it anyway for security reasons.

The pin (pinning just the boolean presence of the extension, like
STS pins availability of TLS) would not pin any of the TLSA data,
that's subject to the normal, and typically short, DNS TTLs should
the client choose to cache the presented DNS records.  Its lifetime
would be measured in hours (not seconds) and I'd go with a 16-bit
value that represent any time from 0 hours (partial deployment)
to 65535 hours which is close to 7.5 years.

The pin is set (or reset to a new value) when the server performs
a handshake in which the extension is present with a non-zero TTL,
and either provides matching TLSA records or a valid denial of
existence (and is authenticated via WebPKI).

For browser HTTPS, (in a separate specification) in might make
sense to limit DANE support to just the "restrictive" case,
PKIX-TA(0) and PKIX-EE(1).  There are many in the TLS and
browser communities who don't trust the security of DNSSEC,
and would be reluctant to authenticate sensitive browser
connections based on DANE alone.  That's fine.  Just as
DANE for SMTP limits the scope to DANE-TA(2) and DANE-EE(3)
for reasons explained in section 1.3 of RFC7672, the converse
can reasonably be argued for browsers.  This suggests even
more strongly that DANE stripping matters (if "restrictive"
turns out to be the main purpose of DANE in that space) and
that this specification needs to harden DANE against downgrades.

I should also mention that there is a user community that expects
the IETF to make DANE support work in browsers and which would be
once again left frustrated with the specification failing to meet
their expectations.  For a published example:

  https://service.networking4all.com/hc/en-us/articles/115001319589-Wat-is-DANE-en-DNSSEC-

but I've certainly been party to various conversations with users
where want DANE to work for their Web servers and browsers, the
finer points to be worked out by this WG and browser/web server
developers.

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

I think that users deserve better than that, and that the extension should have tangible
security benefits not only in greenfield applications where DANE is the mandatory authentication
mechanism, but also in legacy applications where deployment would necessarily be incremental and
initially slow.

Yes, there is not today an immediate backlog of implementations waiting to adopt the
specification into legacy spaces.  The same was true for DANE in RFC6698 when the
specification was completed in Aug 2012.  The first substantive implementation work
did not begin until Feb/Mar of 2013 and its later adoption was substantially driven
by the unanticipated news in June of that year.

We don't know what the future will bring, the WebPKI is certainly looking much more
fragile lately than it did in the past with multiple failures at various CAs, and
the health of the ecosystem threatened by a new economic reality.  It is prudent
to have alternatives "in the wings", even if there is not an immediate rush to
adopt.

This specification should be sufficiently robust to support not only the immediate
narrow DPRIV use-case, but also other use-cases.  What's more adding support for
(A) and (B) in no way burdens the immediate adopters, all they suffer is a short
delay in the publication of the final document.  They can ignore the pin TTL,
and given mandatory TLSA records are certainly not compelled to generate denial
of existence given that they're planning to have TLSA records.  It may however
turn out that even there a capability to vend denial of existence could prove
useful.

In summary, the present specification fails to address its motivating use-cases,
provides no incremental adoption path, and is only narrowly fit for purpose with
some new applications, but provides no alternative security mechanisms in the
existing application spaces where direct use DNSSEC by the client (bypassing
this extension) is not an option.

This is why my "hum" is for both (A) and (B), i.e. (C).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Apr 2018 19:38:09 -0400

> On Apr 4, 2018, at 6:12 PM, Melinda Shore <[email-masked]> wrote:
> 

That addition is fundamentally flawed.  THere is no realistic scalable
adoption model in which a server publishes DANE-only certificates to
and expects thereby to support a meaningful set of clients that would
don't trust Let's Encrypt (for example).  Nor do I see the browser
community accepting DANE alone as a sufficient security mechanism.

> I do think there would be a problem with adding additional complexity

Ignoring a 16-bit field in the extension adds ZERO complexity.  Not
sending a denial of existence response and not accepting one if
given (in applications that don't need this feature) likewise adds
ZERO complexity.  The complexity argument is a mirage.

> that the changes would not be introduced to correct an error in

The changes are needed to support the extension in any application
where adoption is necessarily incremental (i.e. all existing WebPKI
applications).  To refute that, one would need to refute the security
and cost-benefit analyses in my post and somehow demonstrate
"alternative facts" that establish the viability of an additive
model, and some other way to compensate for the fact the present
extension has a major downgrade hole.

It is precisely the "restrictive" use-case that Richard says can be
left out that users expect from DANE, that is tangible benefit over
and above just using WebPKI, from say Let's Encrypt.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Apr 2018 12:07:57 +1000

Given what we've learned about pinning (it is being removed from
browsers), this seems like a bad plan to me.

Your cost benefit analysis seems about right though.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Apr 2018 22:15:25 -0400

> On Apr 4, 2018, at 10:07 PM, Martin Thomson <[email-masked]> wrote:
> 

Question, are you thinking of HPKP or STS?  HPKP pins rather volatile
data, and is too fragile to be used (something I would have predicted
without even running the experiment).  STS and this proposal pin a
capability:

	* STS:  I can be relied on to support TLS
	* option (B): I can be relied on to support the TLS extension
          for the specified itme (or not when the TTL is 0).

So I rather that the unsurprising failure of HPKP is the wrong lesson
to apply.  STS seems successful enough, indeed in the UTA working
group Google, Microsoft, Yahoo et. al. are standardizing an STS for
SMTP (as a work-around for lack of DNSSEC in their domains) and this
pins an STS policy for timescales comparable to the proposal here.

The UTA STS draft has just cleared WG last call, Should I expect that the
folks in this WG opposing the pin for the DANE chain extension are strongly
opposed to SMTP STS and will argue against it in IETF last call and if
IESG members in IESG review?

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Apr 2018 19:22:38 -0700

>           for the specified itme (or not when the TTL is 0).

I don't think that this comparison is particularly apt.The representation
in HSTS
is simply "I support HSTS". The representation in HPKP is "I will use
either consistent
keying material *or* a consistent set of CAs". The representation here is
"I will
continue to have DNSSEC-signed DANE records". That is a significantly more
risky
proposition than continuing to support TLS (and I'm ignoring the risk of
hijacking
attacks that people were concerned with with HPKP), and so this seems rather
more like HPKP to me.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 21:16:25 -0500

> into the working group to address the following issues:

For the record, I've had a document need changes after IESG publication
approval that were then made with a WG LC for those changes rather than
a repeat of WG LC, IETF LC, and IESG review.

I'm surprised that this changes should require "bring[ing] the document
back into the working group" if by that you mean going through the full
process all over.  Though, to be sure, I don't object if that's the
required path now, but I don't want people to feel compelled to be
against this LC on account of the delay in publication being much
bigger, not if there's a shorter method.  (Also, I don't mind a delay
all that much: it's hardly that big a deal; RFCs often end up stuck in
AUTH48 for much much longer!)

> issues to potentially be addressed in follow-up work?

I do not.

> B) Adding signaling to require the use of this extension for a period of

At least (B), and preferably (C).

My rationale for (B) is that this is the sort of thing where adding it
from the get-go will yield deployment where DANE is not mandatory for
the application whereas not adding it now will yield non-deployment of
DANE in such applications for a very long time.

My rationale for (C) is that (A) is trivial, so might as well throw it
in.  Mind you, (B) is also trivial (two bytes! to be conveyed however
you want, with 0 -> clear the pin to DANE).

Thanks,

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 21:20:07 -0500

On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> I don't think that this comparison is particularly apt.The
> representation in HSTS is simply "I support HSTS". The representation
> in HPKP is "I will use either consistent keying material *or* a
> consistent set of CAs". The representation here is "I will continue to
> have DNSSEC-signed DANE records". That is a significantly more risky
> proposition than continuing to support TLS (and I'm ignoring the risk
> of hijacking attacks that people were concerned with with HPKP), and
> so this seems rather more like HPKP to me.

Without a TTL (with zero meaning "clear the pin to DANE") this extension
can only really be used with mandatory-to-use-with-DANE protocols, where
the commitment to "continue to have DNSSEC-signed DANE records" is
implied.

The TTL allows one to put a bound on that commitment, thus alleviating
the risk.

That's the whole point: to alleviate the risk of commitment to DANE in
order to not discourage opportunistic deployment.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 21:22:29 -0500

> browsers), this seems like a bad plan to me.

You can use this TTL, or not.  You're not required to set it to any
value other than the max ("infinity") or min (zero) if you don't want
to.  You can pin or not pin.  You can make DNAE mandatory (TTL set to
infinity) or not.

Adding this TTL cannot have a negative impact on the initial application
of this extension.

Nico
--

---

From: Richard Barnes <[email-masked]>
Date: Thu, 05 Apr 2018 02:39:43 +0000

Re-adding the list.

On Wed, Apr 4, 2018, 22:39 Richard Barnes <[email-masked]> wrote:

>
>
> On Wed, Apr 4, 2018, 22:34 Nico Williams <[email-masked]> wrote:
>
> This is just not true.  As I said in my earlier message, servers can
> switch based on the ClientHello.
>
> Clients advertise which methods they support, servers switch, and they
> both see how often DANE gets used.  When it gets high enough, they turn off
> the fallback.  Just like every other TLS feature we've ever done.
>
> --Richard
>
>
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 21:25:32 -0500

> can cancel any outstanding kind of pin done. And you would not need B)

Hmm, not quite.  You might want to publish the "clear the pin" (TTL ==
zero) without having to first stop publishing TLSA RRs.

The idea is to first ramp up the TTL, and if there's any problems /
change of mind, ramp it down and remove the TLSA RRs when the last
possible extant pin must have expired.

Therefore I think (B) is more urgent.  (A) is even more trivial than
(B), so there's no reason not to do both ((C)).

> [..]

+1

> it fails to achieve its specified goal and makes this TLS extension

+1

Thanks,

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Apr 2018 19:44:53 -0700

> the commitment to "continue to have DNSSEC-signed DANE records" is

This simply isn't true, for the reasons Richard Barnes indicated in his
response
to you.

> order to not discourage opportunistic deployment.

HPKP had a TTL and yet as a practical matter, people found it very
problematic.
And, of course, if you're concerned with hijacking attacks, the hijacker
will
just advertise a very long TTL.

-Ekr

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 21:31:07 -0500

> Re-adding the list.

Removing one level of quotes.

> the fallback.  Just like every other TLS feature we've ever done.

If clients and servers just negotiate the use of DANE, then there's a
downgrade attack when DANE is the only outcome desired by the server
operator but some WebPKI CA is willing to issue a rogue certificate for
it.

That downgrade is a fatal flaw for any protocols where this extension
isn't mandatory.

QED.

We cannot be serious about security while promoting a protocol with a
glaring downgrade attack.

The TTL with pin-to-DANE semantics alleviates this by allowing the use
of DANE to become mandatory-like for some time after first-use.  It's
TOFU-ish (Trust On First Use).  TOFU has worked rather well for some
protocols, and it will probably work well in the future.

This mechanism to make this extension mandatory-for-some-time negates
the downgrade attack *and* simultaneously provides a path to undo the
use of DANE -- something that operators can reasonably be expected to
demand for any protocol where this extension is not mandatory.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 21:34:57 -0500

> This simply isn't true, for the reasons Richard Barnes indicated in his

See my response to him.  For any non-mandatory use of this extension,
without the pinning semantics there is a glaring downgrade attack.

> HPKP had a TTL and yet as a practical matter, people found it very

I can see why: you have to commit to one certificate in the chain not
changing.  Whereas here you only have to commit to continue to publish
TLSA RRs (and signing them and your zone).  This is a big difference.

> And, of course, if you're concerned with hijacking attacks, the
> hijacker will just advertise a very long TTL.

But it's a TOFU-ish thing.  The server impersonator has to have the
right timing or else be detected -- that's very risky for them, and a
deterrent to even trying.  It's not fool-proof, but it's not nothing
either.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Apr 2018 19:56:37 -0700

> glaring downgrade attack.

Unfortunately, you are conflating the assertive and restrictive use cases.

To recap, there are two potential reasons why one might want thi
technology:

1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's
a pain). This rationale was stronger back before Let's Encrypt, but
I suppose some people may still feel that way.

2. Restrictive: To protect yourself from compromise of the WebPKI.

Yes, if your motivation is #2, then the flow you suggest is a real problem,
but it's not a problem for #1. While not an author of this document, I'd
understood it's primary motivation to be #1, and that's what Richard's
earlier notes have said as well.

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Thu, 05 Apr 2018 03:04:03 +0000

And just to be clear, by "downgrade attack", you mean "normal PKI
authentication that we rely on today".  There's nothing in here that
degrades security (except maybe the legacy crypto in the DNS); it's just
not meeting the bar that you are setting.   That doesn't mean there's not
still some utility to be had.

--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Apr 2018 20:06:42 -0700

> without the pinning semantics there is a glaring downgrade attack.

I've responded to this separately.

> changing.

No, this isn't correct, in two respects.

1. HPKP pins the SPKI, not the certificate, it's about the *key* not
changing,
and intermediates and roots change quite infrequently.
(https://tools.ietf.org/html/rfc7469#section-2.1.1)

2. It's not one key. HPKP allowed you to pin multiple keys and in fact
*required* you to set a backup pin
(https://tools.ietf.org/html/rfc7469#section-2.5)

Whereas here you only have to commit to continue to publish
> TLSA RRs (and signing them and your zone).  This is a big difference.

I don't think that's it all obvious that this is going to be easier to
guarantee,
especially given the rather high DNSSEC misconfiguration rate
(https://link.springer.com/content/pdf/10.1186%2Fs13388-015-0023-y.pdf,
https://indico.dns-oarc.net/event/14/contribution/14/material/slides/0.pdf).

> deterrent to even trying.  It's not fool-proof, but it's not nothing

Given that the motivation for this kind of hijacking was generally
expected to be vandalism or ransom, this doesn't seem very comforting.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 21:59:18 -0500

> Unfortunately, you are conflating the assertive and restrictive use cases.

I'm conflating nothing.  I want to be able to use this HTTPS with DANE,
but this extension as-is cannot be used in any protocol where it isn't
mandatory.

(Richard B. proposes that one can use this with HTTPS when using a CA
that is not likely to be trusted by some clients.  But that's hardly the
enticing use of this extension for HTTPS.  The interesting use-case is
DANE for HTTPS, with or without WebPKI, and having a method of possibly
deploying this.  By "possibly" I mean "incremental".)

> [...]

You're not being serious.  You're rationalizing the document as-is.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 22:03:20 -0500

> authentication that we rely on today".  There's nothing in here that

It's NOT that using WebOKI is a downgrade.

It's that if an operator wants to use DANE (with any usage), then they
want to use DANE.  If an impersonator can make that not happen, it's a
downgrade from the operator's perspective (because they then don't get
what they wanted).

> degrades security (except maybe the legacy crypto in the DNS); it's
> just not meeting the bar that you are setting.   That doesn't mean
> there's not still some utility to be had.

Nonsense.  The operator wants DANE?  They should be able to get it.  If
an active attacker can make that not happen at will, then that is and
can only be called a downgrade attack.  Waving your hands doesn't make
this go away.  The WebPKI's security is irrelevant to this discussion.
Only the server operator's desired outcome is relevant.  If they can't
get it, then this protocol is not useful to them.  And this protocol is
all about using DANE in TLS applications!!!

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Apr 2018 23:30:01 -0400

> On Apr 4, 2018, at 10:34 PM, Nico Williams <[email-masked]> wrote:
> 

Even more strongly NOT ONLY do you not actually commit to publishing
TLSA records going forward since with (A) (denial of existence) you
can just prove they don't exist.  You can even stop using DNSSEC for
your domain entirely.  And yet still support the extension and just
furnish proof (again denial of existence) that your domain is no
longer signed (i.e. no DS records in the parent or ancestor thereof
as signed by that parent or ancestor).

THEREFORE, the pin is *precisely* just a capability pin (like STS),
saying I can present the extension, there is NO obligation to
provide any specific content in that extension.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Apr 2018 22:09:46 -0500

On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote:
> changing, and intermediates and roots change quite infrequently.

Either way it's the same impact: you cannot roll that key over.

Whereas with pin-to-DANE there's no such problem.  I thought I made that
clear.

> (https://tools.ietf.org/html/rfc7469#section-2.5)

The problem remains: you're pinning to key material, which complicates
key management.

> guarantee, especially given the rather high DNSSEC misconfiguration
> rate

I flubbed that up a bit.  With the pin you commit to continue to using
this extension for as long as the clients have pinned it (which you
control via the TTL).  You can actually stop signing your zone provided
that you continue to use the extension.

> expected to be vandalism or ransom, this doesn't seem very comforting.

The motivation for opportunistically using this is to be able to
incrementally deploy DANE for HTTPS (and browsers).  Without that it
won't get deployed at all for HTTPS.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Apr 2018 20:39:37 -0700

> Whereas with pin-to-DANE there's no such problem.  I thought I made that

Yes, I agree that you're relying on a different guarantee from your parent
zone, I just don't think it's particularly obvious that that guarantee is
easier
to ensure, for the reasons I indicated previously.

> won't get deployed at all for HTTPS.

I don't see how this is responsive to the concern that this technique will
be used for hijacking.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Apr 2018 14:19:57 +1000

> won't get deployed at all for HTTPS.

Do you have both clients and servers that are interested in this
particular approach?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Apr 2018 02:46:12 -0400

> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)

The discussion so far has demonstrated the need for an important clarification about the nature of the pinning in B):

  * The pin would not require *anything* more than continuing support for the extension.
  * In particular, it would not require continued presence of TLSA records, nor even
    continued DNSSEC support by the server's domain.
  * This is because the server can respond with denial of existence of either its TLSA
    records, or even of the the DS records for its domain or some parent domain.

This is why my claim that this is essentially like STS, and nothing like HPKP is valid.

A corollary of the above is that (B) requires (A).  Just (B) alone is not sufficient,
it is too limited a mechanism without denial of existence.

If support for the extension itself is mandatory in some application context (implicit
unbounded pin), then of course (A) alone is enough, but we should note that such implicit
indefinite pinning is fragile during partial deployment and does not protect applications
where the implicit requirement is not an option (incremental deployment).

Therefore, the real choice before us is (C) or not (C), the choices of (A) alone or (B)
alone are unsound half-measures.

(C) is essentially STS for dane chains over TLS with downgrade protection after first
contact, and imposes no burden on the present implementors.  If they were willing to
implement without a pin or denial of existence, they can ignore the pin TTL and never
transmit denial of existence (which their clients would not expect to process).

On the other hand, they may find after some experience that the proposed features
are actually useful, and might add them to their application logic.  I don't know
whether DANE is mandatory with DPRIV or is just an "additive" alternative to WebPKI.
If the latter, with the present draft it is trivially stripped, and again there is
little incentive to not just use WebPKI, especially if DANE support is not required
from all clients (thus servers need at least WebPKI).

Looking at RFC8310, I see hints of support for both WebPKI and DANE, with no guidance
as to how a client is to choose between them, accept either both, avoid downgrades
to one when the other is preferred, ...

So I rather suspect that even the DPRIV use-case, which supposedly does not need
the proposed changes, actually does need them for meaningful security from using
DANE, and we've not just not looked at the details closely enough yet.  It may
well turn out not substantially different from the browser use-case that is not
adequately met by the current draft.

Can someone explain briefly how DPRIV avoids the same downgrade issues, and
negative adoption incentives (cost-benfit comparison)?  If it turns out that
no adequate explanation is possible, and indeed the same issues are present,
then the proposed changes (which are still needed elsewhere) are all the
more pressing.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Apr 2018 05:02:59 -0400 (EDT)

On Wed, 4 Apr 2018, Eric Rescorla wrote:

> HPKP had a TTL and yet as a practical matter, people found it very problematic.
> And, of course, if you're concerned with hijacking attacks, the hijacker will

By publising DANE records with either a TLSA record or a denial of
existence proof, you can override any longterm TTL.

If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension
containing a valid NSEC proof of non-existence overrides the previous
TTL/PIN.

In fact, this is one of the reasons the WG should decide to fix the
current draft to include proofs of denial of existence.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Apr 2018 05:06:47 -0400 (EDT)

> earlier notes have said as well.

The primary use case of the author's is not relevant. The document is a
working group document, and people who have contributed to this document
from the start also have valid use cases.

For example, I proposed to use the DNS wire format early on and the WG
made that change. My use case was never to create a "DANE or WebPKI is
enough" security model, as I do not think that model helps anyone.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Apr 2018 05:13:42 -0400 (EDT)

On Thu, 5 Apr 2018, Richard Barnes wrote:

> And just to be clear, by "downgrade attack", you mean "normal PKI authentication that we rely on today".  There's nothing in here that degrades security

You mean other then LetsEncrypt destroying the ecosystem and leading to
a "one key to rule them all" situation?

The webpki is changing dramatically. The amount of CAB/forum violations
seems to be increasing, partially as a result of these violations getting
exposed by certificate transparancy and perhaps partially because of
the financial strain caused by the free LetsEncrypt. Allowing people to
deploy another PKI is not harmful - forcing people to stick with the
webpki could prove harmful.

> That doesn't mean there's not still some utility to be had. 

Your tls-extension use case can be supported regardless of the outcome
of this consensus call. That is not at stake today. Other people's valid
use cases are the ones that are at stake now.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Apr 2018 05:22:42 -0400 (EDT)

> I don't see how this is responsive to the concern that this technique will

To hijack a DANE TLSA record, an attacker has to take over the DNS
domain. Controlling the DNS is equally fatal for the webpki, as you
can just ACME a new certificate at that point. So the hijacking case
is not made worse at all. But the compromise/coercion of only 1 of
600+ (sub)CA's is actually protected against, making DANE a stronger
authentication alternative.

Additionally, in the case of forced domain transfer in relation to an
ownership dispute being litigated, the DANE based pinning is actually
superior to any other kind of pinning, because it gives the (new) domain
owner full control to cancel any outstanding long term pins distributed
by the old/previous/malicious owner.

Paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 5 Apr 2018 12:35:37 +0300

> alone are unsound half-measures.

I agree that both (A) and (B) are bad idea, while (C) is sound idea.
 
> transmit denial of existence (which their clients would not expect to process).

If one wants to save bandwidth in "cancel pin" case, one could add
a flag into request that tells the server if it should transmit DoE
or not (if it has actual chain, that should be transmitted anyway).

That way, the cancel would only need to be transmitted once to each
client, instead of potentially multiple times, and clients that do
not support pinning would not waste downstream bandwidth downloading
cancels they would ignore anyway.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Apr 2018 06:33:10 -0700

On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters <[email-masked]> wrote:

> TTL/PIN.'

Thanks. This is a good point that I agree does not apply to HPKP.

However, that doesn't mean that hijacking isn't a problem (though I agree a
less
serious one). If I have no provisions for DNSSEC at all and the attacker
does
pin hijacking I could be offline for hours to days while I figure out how
to get
and serve them.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Apr 2018 06:34:06 -0700

> from the start also have valid use cases.

Of course. I'm merely responding here to the claim that the document is
useless
as-is.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Apr 2018 10:08:07 -0400

> On Apr 5, 2018, at 9:33 AM, Eric Rescorla <[email-masked]> wrote:
> 
> However, that doesn't mean that hijacking isn't a problem (though I agree a less
> serious one). If I have no provisions for DNSSEC at all and the attacker does
> pin hijacking I could be offline for hours to days while I figure out how to get
> and serve them.

Perhaps you did not see my explanation of why the pin imposes no obligation beyond
supporting the extension in the server software.  A server for an unsigned domain
can just serve denial of existence of the domain's (or a parent's) DS record.

So you don't need to "get and serve them", you just need to forward whatever is
the true data in DNS about the server's domain.  Only the capability to present
the actual DNS chain is required.

	* If server's zone is not DNSSEC-signed, forward NSEC records showing
          existence of NS and non-existence of DS at or above the requested:

		 _443._tcp.server-fqdn.example

          domain and the requisite signatures up to the root.

        * If server's zone is DNSSEC-signed, but no TLSA records are present, serve
          NSEC records proving non-existence (or NODATA) of the requested

		_443._tcp.server-fqdn.example IN TLSA ?

	  records and the requisite signatures up to the root.

        * If the server's zone is DNSSEC-signed, and TLSA records are present, serve
          the requested TLSA records along with the requisite signatures up to the root.

All three of these would be obtained and cached (up to most of the advertised TTL) in
the same way from a suitable resolver that supports chain queries, it is up to that
resolver to return the appropriate response each of the above cases, the server can
treat the data as opaque, modulo determining the time for which it may cache the
response so that the chain need not be re-fetched for each client connection.

If one is worried about hijack by someone who can cause the domain to be signed
with TLSA records published (so as to set a non-zero pin), then one might be
motivated to have server software that is capable of returning the extension.
Just as with STS one might need software that supports TLS if the hijacker
deployed STS.  I don't think that such hijacking is a major risk, but if that
risks drives adoption of the extension (without any other changes in tbe
domain's practices wrt. DNSSEC or DANE adoption) all the better. :-)
The domain might need the extension some day for more than just hijack recovery,
and it will already be available.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Apr 2018 07:20:35 -0700

> can just serve denial of existence of the domain's (or a parent's) DS

Yes, so quite possibly I need to upgrade my entire server farm, which might
be running
on some software which has no version which implements this extension. This
could
be an enormous effort.

-Ekr

-

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Apr 2018 10:36:33 -0400

> On Apr 5, 2018, at 10:20 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> Yes, so quite possibly I need to upgrade my entire server farm, which might be running
> on some software which has no version which implements this extension. This could
> be an enormous effort.

Yes, module hijack.  The same applied with STS, if the server farm had no TLS support,
or insufficient capacity to handle the load with TLS.  This is not substantially
different, other than that TLS support is fairly mainstream now.

Note that the hijack would also need obtain WebPKI certificates (as I would expect
DANE for browsers to insist on the restrictive PKIX-TA(0) / PKIX-EE(1)).  So the
that would be a full takeover of the domain, and the affected clients would have
to have visited the hijacked site during the time it was controlled by the malicious
party.

Note also that clients that support the extension will also be rare for some time,
so the impact of any hijack that improbably pins the extension will be modest.

So, if some users running early adopter browsers that support the extension have
to manually clear the pin after a domain hijack, and visiting the hijacked site,
potentially disclosing sensitive information to the wrong party, etc. then becoming
aware of that when the browser warns them about missing extension support seems like
a feature and not a bug.  They can and probably should contact the legitimate site's
help desk and figure out what to do to secure their account, change passwords, ...

This scenario is not impossible, but a rather low risk, and would initially, as
server support ramps up, affect few users.  The pin can be cleared by the user
in such a situation, and having the user be aware of the fact that he/she visited
a hijacked site is not a bad thing.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Apr 2018 09:47:41 -0500

On Thu, Apr 05, 2018 at 06:33:10AM -0700, Eric Rescorla wrote:
> > containing a valid NSEC proof of non-existence overrides the
> > previous TTL/PIN.'
> 
> However, that doesn't mean that hijacking isn't a problem (though I
> agree a less serious one). If I have no provisions for DNSSEC at all
> and the attacker does pin hijacking I could be offline for hours to
> days while I figure out how to get and serve them.

I've been calling this pin-to-DANE because it's short, but, really, it's
pin-to-using-this-extension.

You can use this extension even if your domain is not signed because the
proof that it isn't signed would be delivered in this extension.

I believe the only way pinning to this extension can cause the hijacking
you propose is if the root zone stops being signed as then there would
be no way to prove that you're no longer using DANE :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Apr 2018 09:54:55 -0500

On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote:
> Yes, I agree that you're relying on a different guarantee from your
> parent zone, I just don't think it's particularly obvious that that
> guarantee is easier to ensure, for the reasons I indicated previously.

Sure it is.  As long as the root zone is signed you can use this
extension and prove that you are / are not using DANE.

> I don't see how this is responsive to the concern that this technique will

You're right.  I believe this has been answered now separately by
others, and also by me.

This is not a pin-to-DANE feature we're asking for, but a
pin-to-using-this-extension.  I shouldn't have called it pin-to-DANE,
but I did because it's short -- short, but not sufficiently pithy :(

Now, it's true that an impersonator could force you to use this
extension when you were not ready to, and that's a DoS, though an easy
one to fix, relatively.  I'll take that DoS over a downgrade attack.

We could mitigate the DoS by saying that the pin TTL must be coerced to
zero (or maybe 1) if the extension only bore an authenticated denial of
existence.  I would prefer to not have to do this, but I'd accept it.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Apr 2018 11:51:17 -0400

> On Apr 5, 2018, at 10:54 AM, Nico Williams <[email-masked]> wrote:
> 

When we get past this consensus call, and get to craft the actual text
describing the pin TTL, I would expect a non-zero PIN to only be possible
when proving TLSA records.  A denial of existence should not be able to
set a new pin TTL, and should clear any previous pin TTL.  If DANE is not
actually deployed, there's little reason to pin the extension, and clearing
the pin via denial of existence is a useful mechanism.

A client might then lose access to continued denial of existence until
it again sees actual TLSA records with a non-zero pin, but that seems
OK to me.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 Apr 2018 14:21:02 -0500

> then the proposed changes (which are still needed elsewhere) are all the

Oh, right, DPRIV isn't a work-in-progress.  It's already here.  Thus it
cannot be an application that makes draft-ietf-tls-dnssec-chain-extension
mandatory.  Therefore it's subject to the downgrade attack we want to
address with (C).

I think now the WG should really want this LC to succeed and get this
change made.

Nico
--

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 9 Apr 2018 18:33:22 +0000

> exposed
> by certificate transparancy and perhaps partially because of the financial
> strain
> caused by the free LetsEncrypt.

Uniformed speculations that are just flat out wrong do not help anyone.

LetsEncrypt, if anything, has been a big help to the CA industry.  Both free 
and paid offerings are seeing significant growth.  Let's not spread FUD about 
"financial strain" that does not actually exist.  And furthermore, it's best 
not suggest hypothetical unproved ("seems to be") observations are caused by 
the previously mentioned cause that doesn't actually exist.  That's 
irresponsible.

Tools like cablint have actually contributed far more to improvements in the 
technical compliance of certificates from vendors who previously didn't adhere 
that closely to strict compliance with RFCs, CABF requirements, required 
certificate profiles, and so on.  CT is less responsible, as it is only 
required for EV (though many large CAs have voluntarily started logging all 
certificates).  Many bad certificates were still found the old fashioned way: 
by crawling for them.

There's an old story about an intelligence analyst who found a handful of 
suspicious structures in a remote desert.  More resources were assigned to 
figure out what they were.

A few months later, the number of structures was observed to be increasing 
rapidly.  More resources were assigned.

Pretty soon, new ones were found every day.  People started panicking, and 
someone was dispatched to investigate on the ground.

It turned out to be a kind of water condenser common in the region, and the 
increase in numbers was only because people had started looking for them. 
They had always been there, just no one paid attention to them.

The truth is that the increase in activity around problems with various 
certificates is because people are just paying far more attention to even the 
smallest, most obscure details of every issued web PKI certificate these days: 
far, far more than they did even just two or three years ago.

And that's a good thing, not a bad thing.  Progress is being made.  The 
certificates being issued by almost every CA out there are much technically 
cleaner than they  were when I first started doing CA things, maybe five years 
ago.

The Symantec swamp cleanup effort is also responsible for a significant 
fraction (the majority?) of recent reports.

-Tim

---

From: Willem Toorop <[email-masked]>
Date: Tue, 10 Apr 2018 12:04:01 +0200

I support separation of concerns: publish as is, and start new work to
extend existing Strict Transport Security mechanisms to include DANE
authenticated TLS.

Currently the draft is describing only a single mechanism: Letting
owners of a (DNSSEC signed) domain vouch for their own TLS services.
Not needing a third party for this is IMHO already valuable.

HTTP Strict Transport Security (HSTS) [RFC6797] is extensible with
directives.  A new document could provide a useDANE directive for HSTS.
That document could furthermore make more explicit, that when the chain
extension delivers a denial of existence proof or a proof of insecurity,
that a fallback to non-DANE PKIX has to be done.

The chain extension already contains verification of Denial Of Existence
proofs, because that is needed for verifying wildcard expansions.  It
does not explicitly mention the fallback to non-PKIX with a Denial of
Existence proof or insecurity proof for the TLSA record, because it is
(currently) irrelevant when the extension could simply be left out too.
However, it does implicitly by referring to the DANE RFCs in paragraph 2
of section 6. Verification:

>   If the authentication chain is correctly verified, the client then
>   performs DANE authentication of the server according to the DANE TLS
>   protocol [RFC6698] [RFC7671].

Because the current draft is describing only the embedding of DANE
records to authenticate the TLS service, it is quite short and to the
point.  I am afraid that built-in STS would bloat it with a lot of
concerns that are not specific for the simple mechanism of embedding DANE.

The extension as currently is does not add security like DANE over DNS
protocol would have. This is pointed out in in the draft in Section 8,
in which a mechanism like STS is also already suggested.

I have a few questions too.

Currently the extension contains only DNSSEC data, which can be verified
to be authentic and correct.  Is this also true for an additional TTL
value?  Is it safe to do STS at TLS ClientHello time?  Why is there not
a STS specification at TLS level already (which would also cover imaps,
pops etc.), but only for protocols one layer above TLS?

-- Willem

---

From: Shumon Huque <[email-masked]>
Date: Tue, 10 Apr 2018 09:48:24 -0400

> issues to potentially be addressed in follow-up work?

Yes. I support the publication of the document as is.

and would like to explain my position a bit.

I'm very sympathetic to Viktor's desire to enhance this protocol
to provide downgrade resistance against PKIX attacks, and I
generally would share that desire too.

But I would also like to publish a document that has the solid
consensus of the community that is one of key potential target
consumers of this draft (web browsers and servers). So I'm giving
more weight to their views and preferences. To date, the only
people from that community that have spoken up have expressed
strong opposition to Viktor's proposed enhancement.

I also feel that the amount of time it has taken to finish up
this draft has significantly hurt its deployment chances. In the
early days of this draft there was (in my view) a window of opportunity
where some browsers had actual interest in implementing this spec.
But in the intervening time, there have been enough bandaids (CT
and strengthed CAB forum requirements) applied to the WebPKI that
to many people in the web community, the risk of bad actors has been
sufficiently mitigated. But to the extent that there are still some
folks interested in this proposal, I see no benefit in proposing an
additional feature that they've stated doesn't work for them, or
that they will not use.

Another important facet of this debate that so far has not surfaced
on recent mailing list discussions is an assessment of the relative
benefits of webpki versus dane, and the recognition that there are
strongly divergent views on this topic. In the early days of this
draft, a number of web folks made it quite clear to me that this
protocol can't be used to compel the use of DANE, and that the browser
gets to decide what to use (and so dane-to-pkix downgrade attacks were
not a concern for them). The large majority of DNSSEC proponents I
know (and I'll state upfront that I'm one of them) clearly feel that
DANE is superior to webpki, and that it's logical that DANE should be
used to address webpki security issues. But this view is not shared by
many others, most particularly in the web community. I've been
involved in many lengthy debates on this topic, and the arguments
against DANE usually boil down to: (1) widespread use 1024-bit RSA
as the weak link in the majority of DNSSEC chains, (2) mistrust of
registrars and their potential security failings, (3) mistrust of
registries and/or other ancestor zones that could mount targeted
attacks that could only be detected by a DNSSEC key transparency
system, ala CT. These are legitimate arguments, and until we have
better answers to them, I'm not inclined to aggressively push DANE,
and position it as unconditionally superior, on communities that have
expressed these concerns.

Viktor has asserted that no-one will be motivated to deploy DANE
without protection against PKIX downgrade, because there is no
compelling enough additional gain of security. He may be right or
wrong, but I've already heard several web folks disagree with him.
And furthermore, they've expressed what I think are legitimate
concerns about the fragility of the pinning proposal. Yes, I agree
that it's not as bad as HPKP, but I also agree that there are more
risks and failure possibilities than HSTS.

As for other applications, we've already heard from a number of
folks in the DNS over TLS camp that the draft works for them in
the current form. Most DNS over TLS clients are expected to have
explicit configuration of their resolver addresses and DANE
capabilities.

Some possible ways forward I see for folks wanting to develop a version
of this spec with PKIX downgrade resistant capabilities (I've already
stated earlier, that I would be happy to participate in such efforts):

* Develop a new spec, with a new codepoint, and let the specs compete
  for adoption.
* Develop a -bis document - if we manage to get WG consensus on the
  approach at a later date.
* Do something outside the protocol, and specific to applications
  that want to include mechanisms to mandate DANE usage (like a HTTP
  header).

-- 
Shumon Huque

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Apr 2018 10:20:01 -0400

> On Apr 10, 2018, at 9:48 AM, Shumon Huque <[email-masked]> wrote:
> 

There'll be negligible adoption of this draft as-is by Web Server
operators on the public Internet.  It offers them all pain and no
gain.  ZERO additional security over and above what they get with
Let's Encrypt, only additional operational complexity and a new
way to fail when the client supports DANE and the TLSA records
are stale.

Outside a few bilateral or intramural arrangements for mandatory
DANE by clients when accessing specific destination servers, anyone
deploying the present specification for the Web, is a masochist, or
simply ignorant of what they're getting.

What your response omits is any sort of cost/benefit analysis of
the applicability of the present proposal to the Web. To be a
proponent of adoption, you need to propose a specification that
delivers tangible benefits at [plausibly] acceptable cost.

No amount of wishful thinking or expedited publication will lead
to meaningful adoption of a technology that is all cost and no
benefit.  If there's a flaw in my cost/benefit analysis posted
earlier in this thread, please post a correction.

  From: Martin Thomson <[email-masked]>
  Date: Thu, 5 Apr 2018 12:07:57 +1000
  To: TLS WG <[email-masked]>
  Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

  [skepticism re pinning, addressed in follow-ups]
  Your cost benefit analysis seems about right though.

To Willem's point, moving the TTL negotiation out of the TLS
extension into HTTP STS metadata means that each application
protocol (IMAP, JMAP, POP, SMTP submission, ...) that would
employ this specification to address the "last mile" problems
with DNSSEC at mobile client systems, would need to be extended
with a similar protocol extension.  That's rather a lot of
duplicate work (and a lot more delay) for something that can
be done just once and promptly in this specification.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Apr 2018 11:22:28 -0400 (EDT)

On Tue, 10 Apr 2018, Willem Toorop wrote:

I just want to clarify one misconception in Willem's statement. See my
previous emails to thist list for my full arguments on this issue.

> proofs, because that is needed for verifying wildcard expansions.

This might confuse people. I am talking about denial of existence of any
TLSA record. You are talking about proof of non-existance of other TLSA
records besides the one you are returning. These are completely
different issues. I just want to ensure people realise when I said we
need proof of non-existence, that people do not read your line "already
contains this" as me being wrong.

> It does not explicitly mention the fallback to non-PKIX with a Denial of

So that's not one bug, but two bugs. Defining them out of scope is not
what we should do. For instance, the document could already assume that
the proof of TLS extension (pinning) is going to be solved elsewhere,
and therefor a full denial of existence proof in this document would be
valuable.

The document does not specify what to do when it does not find a TLSA
record to include. It does state:

     If the server is configured for DANE
    authentication, then it performs the appropriate DNS queries, builds
    the authentication chain, and returns it to the client.

So if the server is configured for DANE, and it only finds denial of
existence proofs of its own TLSA record, what is the expected behaviour?

This hints at returning the proof of non-existence, but clearly even the
authors are now saying they did not mean this and a server is not
required to do this. Clearly the text needs clarification, and if it
then leaves out denial of existence, it needs a justification for that
as well.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Apr 2018 11:32:54 -0400

> On Apr 10, 2018, at 11:22 AM, Paul Wouters <[email-masked]> wrote:
> 

Paul makes a good point.  If indeed at some later time (as Willem
suggests) a commitment to deliver the extension is made at some
application layer, then the underlying TLS extension code will need
to be able to return denial of existence of TLSA records when these
are deleted or not yet present.

And yet there is nothing in the document that describes returning
denial of existence for the requested TLSA records, except to
validate a wildcard TLSA RRset (which is still a positive response).
So indeed the present document does not support responses that are
a denial of existence *of the requested TLSA RRset*.

So at the very least this defect will need to be addressed, (option
(A)). This in no way weakens the imperative for (C) (both denial of
existence support and an extension support TTL).

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Apr 2018 11:48:58 -0500

Hi Viktor,

With no hats.

> way to fail when the client supports DANE and the TLSA records

I'd like to expand the discussion a little bit, on the question of
what the goals of this document are, as well as that they should be.
Your text above seems to imply that you see the goal of the document
as being a security mechanism to DANE-authenticate TLS connections.
But it's not clear to me that this is the best reading of the current
document text.  Re-quoting some text you had included in the thread
previously:

   [...] The intent of this

   This mechanism is useful for TLS applications that need to address
   the problems described above, typically web browsers or SIP/VoIP
   [RFC3261] and XMPP [RFC7590]. [...]

I'd like to see if we can agree on what "the problems described above" are.
I am reading the quoted text to say that the problems are:

1) needing to incur additional latency by doing DNS lookups
2) interfering/broken middleboxes that drop DANE records
3) needing a secure connection to a validating resolver

While it is true that performing DANE Authentication generally does have
a security role, the three items I list above are essentially matters of
convenience, and not themselves relevant for security.  In this sense, the
immediate goal of the document is more to play a role as a transport than to
provide security directly.

I concede that it remains useful to consider what the client will do
with the received DANE records or denial thereof, so as to not unduly
block off future routes for development.  But it seems at least possible to take
a very broad view in this space, including even the possibility of additional
TLS extensions that can modify the behavior of this one (such as a modification
to provide pinning-like behavior).  Such extensions could be introduced closer
in time to when the desire to implement and use such behavior appears.

So, can we ask ourselves what we intend to get from the document?  I suspect
that the vehemence of disagreement being presented stems from a disagreement
in the goals we are seeking to achieve.

-Ben

---

From: Shumon Huque <[email-masked]>
Date: Tue, 10 Apr 2018 13:25:02 -0400

On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk <[email-masked]> wrote:
[...]

> to provide pinning-like behavior).

Maybe that's the best option. Advance the current document as-is. And also
develop a separate DANE pinning extension (now'ish ..)

-- 
Shumon Huque

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Apr 2018 13:14:12 -0500

> develop a separate DANE pinning extension (now'ish ..)

Perhaps, but we should come to agreement on the actual goals before we
get too far...

-Ben

---

From: Shumon Huque <[email-masked]>
Date: Tue, 10 Apr 2018 14:43:03 -0400

> then leaves out denial of existence, it needs a justification for that

Personally, I would be okay with relaxing/clarifying the language in the
draft a bit so that it does not rule out the possibility that a DNSSEC
(NSEC/NSEC3) chain corresponding to an NXDOMAIN or NODATA response can be
returned.

I wonder if that, together with a new extension that can convey DANE
pinning information is a way forward ..

-- 
Shumon Huque

---

From: James Cloos <[email-masked]>
Date: Tue, 10 Apr 2018 17:35:51 -0400

[I only have part of the thread available, and so am replying to the
last message I see.]

I agree that the draft MUST explicitly support chains corresponding to
a NXDOMAIN or NODATA responses to have sufficient value.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Apr 2018 18:53:21 -0500

> consensus of the community that is one of key potential target

Assertion of facts not in evidence.  We're here because there is a
question as to consensus (and/or process).  We need to address that.

The earlier consensus is not just applicable, as if it were, we would
not be having this LC.

Using the earlier consensus as justification is not responsive to the
substantive issues, and is just not a good argument.

A valid argument would be that this extension works for DPRIV, but you
should consider that even for DPRIV there is a downgrade unless the
client knows a priori that the server does (or does not) support this
extension.

> this draft has significantly hurt its deployment chances. In the

I'll be blunt: I do not care about how long it's taken and neither
should anyone else (besides, it will take longer on the RFC-Editor queue
anyways; as an RFC author myself, I know this all too well).  I care
about the quality of the end result, and so should you, and so should
the WG, IETF, and IESG.

There is bug in the spec.

The bug affects DPRIV as well as other applications -- it affects any
application where the client does not know a priori whether the server
will or will not be using this extension.

> where some browsers had actual interest in implementing this spec.

See the point that even DPRIV is affected.  You might argue that your
DPRIV clients will know a priori whether the server supports this
extension, but that would have to be true of all DPRIV clients.

> additional feature that they've stated doesn't work for them, or

Contradition.  Then why bother with DANE and this extension?

Your argument is to cancel the Internet-Draft, not to publish it as-is,
yet you are also arguing to publish as-is.  Pick one.

> strongly divergent views on this topic. [...]

This is not the subject matter of this LC.

> wrong, but I've already heard several web folks disagree with him.

You're not addressing the glaring downgrade attack.

> explicit configuration of their resolver addresses and DANE

"Most" != "all".

To live with the downgrade you'd have to make that "all".

You might want to think about all the deployment scenarios ruled out by
having this bug.

>   that want to include mechanisms to mandate DANE usage (like a HTTP

Needless to say, I oppose your proposal for reasons I've stated before.

Two specs is not better than one, and we can count on implementors
missing one.

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Tue, 10 Apr 2018 16:17:14 -0800

> The earlier consensus is not just applicable, as if it were, we would

I have no idea what that even means, to be honest.  We're through
last call, and it's not that the earlier wg consensus isn't
"applicable," it's that you've raised new issues.  So let's be
clear about that.

I've been watching this discussion and trying to get a handle
on what's been going on (and how this fits into several other
IETF issues more generally), and I think this discussion would
be over if the people arguing in favor of changing the use
of the extension had plans to implement it.  But so far nobody
has said that they do.  It's been suggested that if we intend to
stick with the original, intended use we can just ignore the extra
bytes, which strikes me as an exceedingly odd argument for including
new protocol features.

It's unfortunate that over in DNS-land they're discussing how
to get rid of unused features that increase complexity, while over
here we're having a discussion of how to add unused features that
increase complexity.

I think those of us who care about the institutional effectiveness
of the IETF and the value of the standardization process care
quite a bit about the amount of time it takes to push a document
through to publication.  Aside from negatively affecting the chances
of the success of a given protocol, it's harmful to the standards
process more broadly and discourages participation from people who want
to get work done.  There's an unfortunate number of IETF protocols that
people worked on for years and that never saw implementation, and
it seems to me that we ought to be trying to minimize the chances
of that happening with the protocols we're working on.  I haven't seen
anything in this discussion that leads me to believe that the
extension as specified is fundamentally broken or insecure for its
intended use.  I'm good with adding clarifying text or scoping it
more clearly, but beating this thing to death for a use case that
nobody intends to implement seems a bit misguided to me.

Melinda

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Apr 2018 19:15:09 -0500

> what the goals of this document are, as well as that they should be.

I don't think that's necessary for settling this LC, but let's follow

> as being a security mechanism to DANE-authenticate TLS connections.

Without precluding DANE + WebPKI.

>    validating DNS resolver to which it has a secure connection.

The last-mile problem described in the last sentence in the above quote
is the most important point.

This extension is not merely an optimization so that the client need not
perform those additional DNS queries: it is a workaround to the
last-mile problem.

Moreover, this isn't just a run-time optimization, but also a developer
optimization.

Lastly, sometimes run-time and/or developer optimizations are actually
necessary to get traction.

> 3) needing a secure connection to a validating resolver

(2) -> this extension is for clients to be able to use DANE when they
otherwise could not.

In order to be able to mix WebPKI and/or DANE, it is necessary to have
the proofs of non-existence in order to be able to decide to dispense
with DANE.  Therefore this isn't just an optimization for when you want
to use DANE: it is for when you are willing to use DANE, and willing to
not do DANE, but you need to know which to do.

It is because the choice is WebPKI and/or DANE that the downgrade
attack, and the pinning mitigation (with TOFU semantics) matter.

For example, on the web, in IMAP, ..., the WebPKI *and* (not *or*) DANE
usage (DANE usages PKIX-TA #0 and PKIX-EE #1) are likely to matter.

> provide security directly.

I don't follow.  The security role for DANE here is the whole story, and
it is essential.  How can we say that this is just about latency or
last-mile problems when what DANE is doing at the end of the day is...
provide authentication (security).

> block off future routes for development.  But it seems at least
> possible to take a very broad view in this space, including even the
> possibility of additional TLS extensions that can modify the behavior
> of this one (such as a modification to provide pinning-like behavior).
> Such extensions could be introduced closer in time to when the desire
> to implement and use such behavior appears.

Again, my concern is that the follow-on will not happen.  I don't
believe the authors are interested in it.  It is perfectly possible that
without this "feature" in on day one it may never get added because
people throw their hands up and move on.  This happens in our industry.

But what really bugs me is that the only reason anyone seems to want to
avoid these minimal changes is "so we can be done already".  After 16
years of participation at the IETF, I find that... a bit surprising.

It's not that we never shoot-the-engineers-and-ship, but that we try not
to have glaring problems in our specs.  We're the sort of SDO that has
enough review to find and fix such problems, and we're a large
community, and we try to serve that community's needs, not just each
draft's authors' immediate needs.

> So, can we ask ourselves what we intend to get from the document?  I
> suspect that the vehemence of disagreement being presented stems from
> a disagreement in the goals we are seeking to achieve.

OK:

  We need a general-purpose extension for stapled-DANE in TLS.

  Because for many (all existing) TLS applications this is an upgrade,
  we also need downgrade protection.  Full stop.  To me this is
  self-evident, and I don't understand how it is not to anyone else,
  except because of an urge to "be done", and I don't see how that could
  possibly be justification.

FYI, I've had to go back to a WG before to correct a problem post-IESG
approval.  It happens.  It's not a big deal.  We'll almost certainly
spend more time and effort arguing about this than about actual proposed
text.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Apr 2018 19:26:34 -0500

> "applicable," it's that you've raised new issues.  So let's be

It means that because we are having this LC, we cannot use the previous
consensus as evidence for ending this LC with a "no".  We might as well
never have had the LC in that case, and it is not a substantive response
to the LC anyways.  It's a "please go away" response.

> of the extension had plans to implement it.  But so far nobody [...]

Viktor began implementing DANE 8 months after it was published.  That
spec was ready.  This spec is not.

> here we're having a discussion of how to add unused features that

Sure, this is true, but it doesn't mean that we should exclude features
that are necessary to making the protocol work in the first place.

This is a TLS extension for stapled DANE, not a DPRIV extension to TLS.

> through to publication.  Aside from negatively affecting the chances

What is it to "care about the institutional effectiveness of the IETF
..."?  Is it to care only about speediness?  Or only about correctness?
How about a bit of both?

Honestly, if all you want is speediness, why not go to OASIS?  Register
the extension codepoint with IANA and publish elsewhere, why not?

Doing things in the IETF means... the peanut gallery are not just
spectators.  Bringing work to the IETF means incurring the risk that
others may glom onto it.  It happens *all the time*, it's happened to
me, and it will happen to others.  There is nothing special to this
piece of work that should exempt it.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Apr 2018 21:28:59 -0400

> On Apr 10, 2018, at 8:17 PM, Melinda Shore <[email-masked]> wrote:
> 
> There's an unfortunate number of IETF protocols that
> of that happening with the protocols we're working on.

Exactly, which is why we need to make sure that the protocol does
not fail to address its natural use-cases.  This is a protocol for
stapled DANE in TLS, and many potential applications will run in
mixed WebPKI + DANE environments and will need to be able to do
DANE *when possible*, in a downgrade-resistant manner (in this case
after first contact).

> I haven't seen
> intended use.

The intended use in the introduction does not preclude Web browser
HTTPS, JMAP, IMAP, POP, NNTP, SMTP Submission, XMPP, ... with only
statically configured DANE for DPRIV in scope.  DPRIV may well be
the application that's ready now, but closing the door on others
is surely unwise.

> I'm good with adding clarifying text or scoping it

It is a mistake to confuse lack of immediate adoption plans with
evidence that no such implementations will ever happen, and should
be precluded at the outset.

I had no idea DANE existed (too busy implementing comprehensive
TLS  support in Postfix to follow IETF work) when the DANE WG
concluded work on RFC6698.  8 months later Tony Finch brought
DANE to my attention, and I began implementation at that time.
My implementation was the first non-toy implementation of DANE
that got used in real systems.

Was I ready to implement in August of 2012?  No.  Did I then
never implement?  Of course not, indeed we'd not be talking
about DANE at all (it would be dead) if it were not for that
work, and subsequent work to eliminate hurdles in the form of
buggy authoritative servers at some major providers, integration
into OpenSSL, Exim, ...

The arguments against the proposal continue to ignore the
technical issues and focus on perceived delay.  If you
really want to avoid delay, let's adopt the changes, and we'll
be done.  If there are technical flaws in the cost/benefit
analysis that motivates the changes, please address those
in detail.  I see nothing in the draft that justifies limiting
its scope to just a narrow application profile in which DANE
is statically mandated by client policy.  That limitation fails
to scale.

Even with DPRIV it should be possible for a server that no
longer has TLSA records to provide a denial of existence proof
(thus at least option (A) from the consensus call message) and
employ PKIX instead (a domain may become unsigned if they change
their mind about implementing DNSSEC).  Option (B) supports
incremental adoption, and provides downgrade protection after
first contact, dramatically increasing the applicability.

The changes are small, but needed to not preclude further
implementation work in new application areas.  There may not
be implementors right away, but we should leave the door open
for when they are.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Apr 2018 22:42:04 -0500

Let me synthesize one new argument, though I've implied it before, but I
think making it explicit may be useful:

  The cost of making the requested changes is fixed and can be estimated
  -- measured even, after the fact.  I argue that cost is low.  But the
  cost/risk of not making the requested changes is intangible -- could
  be very high, or barely more (but not less) than the cost of making
  the changes.

  We'd have to be sanguine to dismiss my estimate of the cost/risk of
  fixing this later.  Perhaps that's right anyways, but it can plausibly
  be very large too, and that surely should trump a small fixed cost,
  therefore we're better off taking this hit now.

I might clarify other points on the main thread, but, really, for me,
the whole thing boils down to: are we looking out for the future, and is
our contention of risk to future DANE deployment even plausible.

It won't surprise anyone that I believe my estimate of the risk to
future DANE deployment is not merely plausible.

It won't surprise anyone either that I believe that even if the
likelihood of reduction of future DANE deployment were low, we, the
IETF, and in particular the IESG, ought to care about making our
protocols sufficiently generic when the cost of doing so is low, as
surely it would be here.

We've already incurred what should be much of the cost of making the
requested changes.  A wee bit little more won't hurt.  Let us now then
proceed to proposed text.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Apr 2018 12:33:48 -0500

> Assertion of facts not in evidence.  We're here because there is a

That argument cuts in many directions, of course.

> question as to consensus (and/or process).  We need to address that.

I don't really agree with that characterization.  To state my understanding,
as responsible AD, of the status of this document: this document is in the
RFC Editor's queue being processed.  The WG is being asked if the late-breaking
issues, raised after consensus was determined, are severe enough to merit
clawing the document back from the RFC Editor to make further changes.
This is, in effect, asking the WG to overturn a previous consensus, which
requires a stronger bar than obtaining an initial consensus from vacuum.

[takes AD hat off]

> There is bug in the spec.

This appears to be an assertion of fact without (immediately local) supporting
evidence.  :)

You believe there is a bug in the details of the spec, sure, and I suspect that
this follows naturally from your related belief that there is a bug in the
target scope of the spec.  If we don't agree on what the target scope of the
document should be, then it's unsurprising that we will fail to agree on the
protocol details.

> This is not the subject matter of this LC.

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.  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.

> You're not addressing the glaring downgrade attack.

I think this argument would be more compelling if phrased differently.
(N.B. that I don't know *how* compelling it would be, and whether that
would be *sufficiently* compelling to effect change; I just think it could be
more compelling than this phrasing makes it.)

In particular, the question of scope arises again.  My impression is
that at least some proponents of the document as-is want to treat the
scope as something like "we allow for the transport of DNSSEC records over
channels where they were not previously available in a useful fashion" (whether
due to actual blocking or latency considerations), in particular, leaving
the question of how those records are used at the endpoing as out of scope.
You want to bring in the downgrade attack as being a significant risk/drawback
for several, not necessarily all, potential use cases for consumers of the
transport.  The question in this framing then becomes a balance between the
potential/expected scale and importance of the affected use cases and the
unaffected use cases.  This ties in nicely to your new argument about the cost/risk
tradeoff being considered.  To you, the "affected use cases" are potentially
huge (e.g., "all web TLS connections"), and even if someone thinks that the
chance of that happening is somewhat small, the risk of it happening but being
broken by the downgrade attack is magnified by the scale into something that
merits consideration now.  This is to be balanced against
more-certain/more-expected use cases that might be perceived as more "fringe"
and probably as smaller in scale than "all web connections".

I don't expect to get unanimous agreement about the potential scale and likelihood
of various perceived use cases, but would hope that people will consider the
tradeoff to be made, as you have framed it.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Apr 2018 15:12:50 -0400

> On Apr 11, 2018, at 1:33 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> 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

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.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Apr 2018 04:40:25 -0400 (EDT)

On Wed, 11 Apr 2018, Benjamin Kaduk wrote:

> RFC Editor's queue being processed.

That was a process mistake.

1) ekr filed a DISCUSS
2) other people raised issues in response
3) ekr's DISCUSS was resolved but not the other people's concern
4) document was placed in RFC Editor queue despite this
5) TLS consensus call done on the list
6) here we are....

I think it is not good to use this process as a way of approving things.
A process mistake was made.

Paul

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Apr 2018 08:58:36 -0400

> A process mistake was made.

The question Ben was asking, though, is whether the impact of that process
mistake is serious enough to merit pulling back the doc from the RFC editor.

Personally, I think the answer is no, and I'm not hearing clear consensus
in either direction in this thread.  So ISTM the best information the
chairs and ADs have to go on is the hum taken in the room (which all of the
litigants here participated in), which was pretty clearly in favor of
proceeding.

--Richard

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Apr 2018 09:46:48 -0400 (EDT)

On Thu, 12 Apr 2018, Richard Barnes wrote:

> The question Ben was asking, though, is whether the impact of that process mistake is serious enough to merit pulling back the doc from the RFC editor.

That can only be answered after the consensus call. I don't think anyone
is really objecting as long as the document isn't forwarded to publication
without completing the current discussion.

> Personally, I think the answer is no, and I'm not hearing clear consensus in either direction in this thread.  So ISTM the best information the chairs and ADs have to go on is the hum
> taken in the room (which all of the litigants here participated in), which was pretty clearly in favor of proceeding.

Again, from a process point of view, we do work on the lists. Humms can
be used to gage the room on what direction to suggest to the WG, but
all those actions are confirmed on their respective lists.

In this case, both Viktor and I believe the room was not sufficiently
aware of the issues raised. And I believe it was a good call for the
IESG to move this discussion back onto the list. It would be odd to
then take that hum back into account again for the consensus call on
the list.

Paul

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Apr 2018 09:49:22 -0400

On Thu, Apr 12, 2018 at 9:46 AM, Paul Wouters <[email-masked]> wrote:

>> chairs and ADs have to go on is the hum
>> taken in the room (which all of the litigants here participated in),
>> which was pretty clearly in favor of proceeding.
>>
>
> Again, from a process point of view, we do work on the lists.

It seems noteworthy, however, that nobody is chiming in on the list who was
not also part of the discussion in the room.  That seems to me to indicate
that their views were already heard and taken into account in the in-person
discussion.

--Richard

> Humms can

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 12 Apr 2018 09:50:20 -0400

There's a few steps Paul is missing in his summary of the process.

>> 3) ekr's DISCUSS was resolved but not the other people's concern

The concerns were discussed at the meeting in London.  The chairs
reviewed 3 separate issues.  The first was agreed upon that a simple
wording change that was not significant to hold up for approval was
made.  No change was needed with one of the other issues.  With the
third, the room was in full agreement that this should be done in a
separate draft.  I went to the mic and summarized this and asked for
agreement that it was ok to approve the document as a result and there
was no opposition, just agreement.

It was right of the chairs to put this back out to the list for
confirmation as they have the ability to pull a document back if they
decide that is the right course of action.

The AD can also override the chairs if they decide it should go
forward and the AD does not agree (although I don't see that in his
messages).

Best regards,
Kathleen

> Personally, I think the answer is no, and I'm not hearing clear consensus in
> either direction in this thread.  So ISTM the best information the chairs
> and ADs have to go on is the hum taken in the room (which all of the

-- 

Best regards,
Kathleen

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Apr 2018 12:54:41 -0500

> was no opposition, just agreement.

It's also worth noting that Ekr explicitly disavowed the other concerns
as outside the range of his DISCUSS
(https://www.ietf.org/mail-archive/web/tls/current/msg25536.html), and
the entire IESG had plenty of opportunities to indicate support for
these other concerns as being DISCUSS-worthy, but none did so.

> forward and the AD does not agree (although I don't see that in his

I'm waiting to see if anything else comes out of this thread.
In particular, I am hoping that some authors/proponents of leaving the
document in the RFC Editor queue would speak to the question of the
target scope, given the arguments that have been presented regarding
the risk/reward tradeoff of the current narrow scope.

-Ben

---

From: Willem Toorop <[email-masked]>
Date: Thu, 12 Apr 2018 20:20:22 +0200

Sorry for being confusing.  I meant to say full Denial of Existing is in
the draft implicitly already (because of the reference to DANE
authentication according to RFC6698 and RFC7671 (which do mention it) in
Section 6).

I do like the idea of STS for this extension (and augment it with the
more restrictive DANE use cases), but I'm unsure about the security of a
built-in version.

I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
[draft-ietf-uta-mta-sts]) are all one layer above TLS.  Is a STS TTL
conveyed in a ServerHello message secure when it would be just for SSL?

I can see this might be different for the DANE use case because of the
signed statements that come alongside the TTL, but for example...
In case of built-in STS with the extension, what does a 0 TTL mean?

  - When 0 has been the only value seen ever, it is clear to me that the
    mechanism is equivalent with what we have in the draft now, but..

  - When another value has been seen before, is a value of 0 then enough
    to clear the pin?  Or would a DoE proof (or insecurity proof)
    alongside it be necessary?

    In case of the latter, what does that mean for sites that do have
    DANE records, but no servers that support the extension?  Can they
    be hampered (for an indefinite period) by a MiTM?  That would be
    really bad for DANE deployment.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 14:32:10 -0400

> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)

While I am a vocal supporter of (C), I'd like to take a moment to explain why AT LEAST (A)
is needed.

  * The present text requires (Section 3.4) that the server's response
    present a validated TLSA RRset:

	   The first RRset in the chain MUST contain the TLSA record set
           being presented

  * The present text (Section 8) says:

	   Green field applications that are designed to always employ this
           extension, could of course unconditionally mandate its use.

Therefore such "green field" applications (presumably some of the ones
ready to implement now) effectively mandate DNSSEC and TLSA records
at the server, NOT JUST support for the extension.

This needlessly limits the usability of such applications.  The
server domain cannot continue to support the extension and
interoperate with the client if it at some points decides to
stop publishing TLSA records or perhaps even stop using DNSSEC.

It makes a lot more sense for servers to be able to continue to
support the extension, but respond with denial of existence when
when the have no TLSA records or the zone is unsigned (no DS
RRs at some ancestor).  That way a server can communicate its
change of status to a client, which may *then* be willing to
accept alternative authentication (WebPKI, for example).

Option (A) does not change the wire formats, it just relaxes
the requirement to provide TLSA records, and would allow or
encourage the server to return whatever is the truth about
its TLSA records (presense, absence or unsigned zone).  The
client can then act accordingly.

Just (A) would of course still many clients in the dark about
when it might be safe to "mandate" the extension for particular
domains, and I'd be sad about that (if anyone cares :-), but it
is important to realize that not doing (A) is a significant
omission.

I'd like to encourage the authors and WG to amend the draft to
relax section 3.4 to allow (and encourage when applicable)
denial of existence replies.  This would better serve the
"green field" applications that would like to avail themselves
of this extension and require it of all servers, whether they
have DNSSEC and TLSA records or not.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Thu, 12 Apr 2018 11:44:52 -0700

> at the server, NOT JUST support for the extension.

Viktor, I believe you have confused a "could" with a "mandate".

The text of this RFC does not require future green field applications
to mandate the use of this exension.  It merely allows them to do so.
None need ever do so.  If any ever did, the future RFC could specify
how servers which do not have validated TLSA records should handle the
situation.  Different future protocols might choose different ways
to handle this (e.g. don't send the extension at all; or send a validated
denial; or send some kind of flag saying that the server doesn't even have
a validated denial because it isn't using DNS or because some domain on
its path to the DNS root isn't doing DNSSEC or isn't using NSECx records).

Please, let this RFC go, rather than requiring that this committee
first insert into it a paper spec for what some future protocol should
do, without even knowing what the future protocol is.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 14:45:02 -0400

> On Apr 12, 2018, at 2:20 PM, Willem Toorop <[email-masked]> wrote:
> 

The reason for that of course is that those "STS-flavours" are
commitments to do TLS vs plaintext, and so can't presume TLS as
a transport.  The question being settled is whether the peer does
TLS or not.

> signed statements that come alongside the TTL, but for example...

Here the issue not whether TLS is supported, but whether the TLS
support includes support for this extension, and so TLS as a
transport is both natural and simultaneously supports all
relevant applications, rather than having to add per-application
mechanisms.

>    mechanism is equivalent with what we have in the draft now, but..

	Yes.  Don't pin, we're not promising ongoing support for the
	extension.

>    really bad for DANE deployment.

	* Positive TTL values require TLSA records, denial of existence
          should not be able to set a positive value.

	* Once a positive TTL is in effect it can only be set back to 0
	  in one of two ways:

		1.  Along with TLSA records that authenticate the handshake.
                    (possibly limited to PKIX-EE/TA per application profile)

		2.  Along with DNSSEC-authenticated denial of existence of
                    said TLSA records or of zone security.

That is downgrades to not pinning require more than a mis-issued WebPKI
certs.  The domain should either prove non-existence of signed TLSA
RRs, or signal a 0 TTL along with valid TLSA RRs that match the cert
chain.

You can think of the above as an initial draft of the text for
option (C).

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Apr 2018 21:46:27 +0300

> conveyed in a ServerHello message secure when it would be just for SSL?

One has to wait for the handshake to complete for most cases (basically
all except the "clear pins with DoE" case).

>     alongside it be necessary?

The way I understand it would work, it would clear the pin at end of
handshake (one could clear immediately on DoE, but maybe better to
delay that too).
 
>     really bad for DANE deployment.
 
That type of attack is possible in some scenarios:

- The DANE records pin a CA and MITM can get misissued certificate from
  that CA.
- The server private keys get stolen.

Since the MITM would need to present a key that exists in the DANE
records in order to actually activate this pinning.

Recovery would need deploying the extension (the data needed is
public in DNS).

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 14:53:14 -0400

> On Apr 12, 2018, at 2:44 PM, John Gilmore <[email-masked]> wrote:
> 
> If any ever did, the future RFC could specify
> situation.

They'd have to violate the text of this draft:

> Different future protocols might choose different ways
> denial;

The draft precludes sending denial of existence in Section 3.4 which
requires to the first RRset to be the requested TLSA records.  Hence
option (A) in the initial last-call announcement.

> or send some kind of flag saying that the server doesn't even have
> a validated denial because it isn't using DNS

That'd be vulnerable to downgrade, defeating the purpose of this
extension to support DANE.

> or because some domain on

This can be handled by sending denial of existence.  The denial of existence
can either prove lack of TLSA records in the server's signed zone, or can
prove lack of signatures on that zone.

> do, without even knowing what the future protocol is.

The present draft limits its own applicability, and neither (A) nor (C)
close off future options.  Indeed (A) specifically lifts an unfortunate
restriction, and (C) provides additional information from the server that
would be quite useful to clients.  It is hard to see how either preëmpt
future use-cases.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 15:05:09 -0400

> Viktor, I believe you have confused a "could" with a "mandate".

As to this point, I'm not now and have never been confused about
that.  The present draft, as explained upthread, perhaps in too
many ways and in too many words, offers no value to applications
that don't mandate the use of the extension, if the application
also excepts WebPKI, and the extension is optional, then a
cost/benefit analysis shows that use of the DANE extension offers
only complexity and no security benefit.  Opportunistic use-cases
of the present draft won't get deployed, they make no sense.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Apr 2018 13:41:28 -0800

> the risk/reward tradeoff of the current narrow scope.

I'm also waiting to see if something new comes up in the
discussion, but it seems at this point we're just rehashing
previous discussion and nothing much is changing.  In
particular, no new information is being contributed.

The one thing that could change my mind about this would be
if there was an intent to actually attack the problem described
in the changed scope (well, also if the proposed change could -
in fact - lead to the deprecation of the web PKI, but the chance
of that seems vanishingly small).  Absent that I really don't
like adding goo to protocols on the off chance that at some
unforeseeable point in the future there's a possibility that
someone might actually want to use that feature.  I think we've
got other ways of handling that eventuality and very little
assurance that it will ever happen, anyway.

Melinda

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 07:47:47 +1000

If this is indeed about adding [goo], what prevents Viktor or Paul
from proposing a new addition to the protocol in the form of a new I-D
that enacts the changes they wish to see?

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Apr 2018 17:49:26 -0400

This is in fact what I proposed in the room in London.  Let's publish draft
this as-is, and handle what they want as a follow-on.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Apr 2018 13:52:19 -0800

> that enacts the changes they wish to see?

Clearly nothing, and I think this would be a reasonable way forward.

Melinda

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 18:09:31 -0400

> On Apr 12, 2018, at 5:47 PM, Martin Thomson <[email-masked]> wrote:
> 

Why publish a crippled specification that needs immediate amendments that would
require a second parallel extension to be defined and used by clients and servers
to fix the issues in the current specification?  And the time to get that second
extension would effectively delay the publication of a usable protocol.

The protocol as described prohibits denial of existence responses.  Willem
acknowledged (thus far in an off-list message) that that's an oversight that
should be corrected, and such a correction is the substance of option (A).

The protocol as described does not provide any mechanism for client to
distinguish between servers that are ready to commit to the extension
and those are not.  This negates applicability in applications that
exist in a world dominated by the WebPKI.  Note that I also don't
advocate any magical vision of the WebPKI going away any time soon.
Indeed some of these applications (e.g. browsers) might choose
to support only *at least* WebPKI, with DANE for optional hardening
(PKIX-TA(0), PKIX-EE(1)), but the present draft provides no downgrade
protection for this use-case.

The additional commitment signal is a hint to clients, not an obligation,
it carries negligible cost, and can be finalized now.  It enables more
potential applications, without going back to square-zero and doing another
year in the IETF WG process to address the gap.

Let's do the right thing and fix now.  The entire cost is just a small
delay, there is zero downside after that.  No imposed complexity.  Just
an improved scope.  We all want to get stuff published and out the door,
but let's take a *little* extra time to make sure it is not needlessly
crippled.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 12 Apr 2018 18:34:02 -0400

> should be corrected, and such a correction is the substance of option (A).

As I said in a previous message, I'll support relaxing the language in the
draft
to permit delivery of authenticated denial chains for future applications
of the
protocol - I think that's just adding or modifying a couple of lines to the
draft,
and no wire changes.

Someone actually argued to me in person that the draft could be read as
not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), but
if we want to allow it, I think it's best to be crystal clear.

If we can get consensus on that, then you could write a separate extension
to convey the pinning information and describe the additional behavior.
That
in combination with the existing draft would satisfy your use case. That
would in
fact be an incremental addition, and not a whole new parallel protocol.

Implementers that are opposed to pinning would then just ignore this second
draft (and not bother with the authenticated denial part of the first
draft). Since it
seems pretty clear you're not going to consensus on adding pinning to the
current
draft, I think you should pursue this approach. And then you can try to
convince
implementers and deployers, now or in the future, that they need to use both
extensions in combination.

-- 
Shumon Huque

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 08:36:07 +1000

On Fri, Apr 13, 2018 at 8:09 AM, Viktor Dukhovni <[email-masked]> wrote:
> to fix the issues in the current specification?

Three reasons:

1. It clears the current bind.

2. It's abundantly clear (to me at least) that there is no consensus
that the specification is indeed crippled.

3. We build by increments all the time.

---

From: Willem Toorop <[email-masked]>
Date: Fri, 13 Apr 2018 00:44:21 +0200

> should be corrected, and such a correction is the substance of option (A).

Well... I find it unfortunate that the line you were quoting from
section 3.4 could be interpreted as prohibiting the possibility of
denial of existence.  So I am open to relaxing that text so that it can
not be interpreted as such anymore yes.

---

From: James Cloos <[email-masked]>
Date: Thu, 12 Apr 2018 19:03:07 -0400

>>>>> "RB" == Richard Barnes <[email-masked]> writes:

RB> It seems noteworthy, however, that nobody is chiming in on the list who was
RB> not also part of the discussion in the room.

Not true.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 19:06:04 -0400

> On Apr 12, 2018, at 6:44 PM, Willem Toorop <[email-masked]> wrote:
> 

Current text:

   The first RRset in the chain MUST contain the TLSA record set being
   presented.  However, ...

Proposed text:

   When the server has DNSSEC-signed TLSA records, the first RRset in
   the chain MUST contain the TLSA record set being presented.
   However, ...

   When the server either has no TLSA records, or its domain is not
   DNSSEC-signed, it is RECOMMENDED that the server return a denial
   of existence of either the TLSA records, or proof of insecure
   delegation at some parent domain, rather than omit the extension.
   Clients that are willing to fall back from DANE to some alternative
   mechanism may require the denial of existence to make that possible.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Apr 2018 16:07:15 -0700

> should be corrected, and such a correction is the substance of option (A).

It would be good to get clarity on this. My understanding is that option a
involved
recommending (at some unspecified level) that people provide those
responses,
not just making it possible for them to do so.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Apr 2018 16:10:27 -0700

>    mechanism may require the denial of existence to make that possible.

I believe that that this text would harm ineteroperability.

The difficulty here is what the server knows about the clients behavior.
Specifically, if the server serves TLSA records and then ceases doing
without serving authenticated denial of existence, then it is unable to
determine if this would cause clients to fail because it doesn't know if
the client implements the text in the final paragraph. One could argue
that current clients could pin, but that's totally extratextual, as opposed
t having a noninteroperable behavior in the document.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 19:11:10 -0400

> On Apr 12, 2018, at 6:34 PM, Shumon Huque <[email-masked]> wrote:
> 
> draft (and not bother with the authenticated denial part of the first draft).

The pin hint is NOT an obligation on the client or the server.  It is OPTIONAL.
Servers can send 0, and clients can just IGNORE the pin.  It is far easier
to ignore the additional field, than to specify a separate extension.

> Since it 
> seems pretty clear you're not going to consensus on adding pinning to the current 
> draft, I think you should pursue this approach.

The consensus call is open until Apr 18th, we may not have heard from everyone yet...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 19:14:45 -0400

> On Apr 12, 2018, at 7:10 PM, Eric Rescorla <[email-masked]> wrote:
> 

How exactly does telling the client the truth (conveying correct
DNS state about the TLSA records) harm interoperability???

Please explain the scenario in which something now fails???

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Apr 2018 16:47:10 -0700

> Please explain the scenario in which something now fails???

I already did this in my previous email, but I'll try again.

In the current document, there is no expectation that clients will pin the
server's use of TLSA and therefore the server can safely stop using
TLSA (or run a mixed server farm). However, because this text implies
that the client *could* pin, in order to ensure interoperability the server
would have to provide authenticated denial at the risk of connection
failure with such clients. However the text also does not require that
the server do so. Thus, a conformant client and a conformant server
can fail if the server just stops using TLSA.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 21:08:35 -0400

> On Apr 12, 2018, at 7:47 PM, Eric Rescorla <[email-masked]> wrote:
> 

Section 8 already says that some clients may require the extension.
Providing denial of existence improves interoperability when all
that the client requires is the extension, and given denial of
existence might accept something else.

Servers that support the extension really ought to provide denial
of existence, if that's all they can do.  Rather than suppress the
extension, if the client demands the extension and the server can't
provide it, interoperability is lost either way.

If your concern is that the new text is "license" for the clients
to arbitrarily require the extension in applications where servers
have no reason to expect such behaviour, I have no objection to
text that says that "the foregoing does not constitute a license
for clients to require the extension where this is not expected
application behaviour" or some such.

The idea is however to encourage servers to provide the denial
of existence, because it may be useful, and is not less interoperable
than eliding the extension.  Giving license to clients to then
expect this from servers is not the intent here.  I'm trying to
sneak in underhanded pinning.  That's not the goal.

I'd like to see explicit pinning (or not) hints from the server,
so we don't need to play guessing games.  Servers that consistently
return a TTL of zero would then be at liberty to drop the extension
rather than deliver DoE (denial of existence) at any time.

In your shoes I'd strongly advocate for the pin TTL, and make sure
that it is set to zero by any servers that be sure to avoid the
concerns that you're expressing.  That way we don't have to play
guessing games about client behaviour.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 22:55:49 -0400

> can fail if the server just stops using TLSA.

Another way of looking at this argument is that we should not recommend
that servers should return denial of existence, because if we do, then
servers that don't return denial of existence might find themselves less
interoperable than those that do.  So everyone should be less interoperable,
so not that nobody is relatively disadvantaged.

An honest assessment of the situation is that indeed returning denial
of existence is more generally interoperable in the face of unknown
client behaviour, and so should be recommended as suggested.

I am only mildly sympathetic to the slippery slope argument that this
may facilitate expectations of such behaviour in clients.  We are not
here to police future design decisions for fidelity to pure
interpretations of the draft.  If client expectations are desirable
in future applications, and servers coöperate, then hooray, we have
a specification that meets real world needs.

That said, the proposed language is not intended to be ann a-priori
license to "pin as you see fit" with no prior application-specific
standard defining what constitutes interoperable behaviour.  This
specification provides a mechanism, not policy.  Applications will
have to define the relevant policy options.  My goal all along has
been to make sure that the mechanism is sufficiently flexible to
accommodate a range of application policies.  [ Thus also the proposal
for the additional TTL hint, which supports a broader range of possible
policies. ]

If you'd like me to craft revised option (A) text, that includes a suitable
caveat, I can try.  Or you or someone else can propose an alternative.
I only ask that it be honest about the server's options: serving the denial
of existence (DoE) records does interoperate with a broader range of client
policies.

In an application where the extension is absolutely optional, i.e. clients
MUST NOT (and do not in practice) expect consistent use by the server,
returning the DoE records would not be substantively different from simply
leaving out the extension.  The client must be able to function in some
fashion with the extension missing, whether legitimately or stripped.

In applications where some clients expect downgrade protection the server
returning DoE records continues to work and the one not returning them might
not interoperate with clients that expect to consistently learn the truth
(good news or bad) about the servers TLSA records.

Does anyone want to propose better text?

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Apr 2018 20:07:55 -0800

On 4/12/18 6:55 PM, Viktor Dukhovni wrote:
> caveat, I can try.  

I'm okay with putting denial-of-existence in there as a should,
but I do feel strongly that pinning belongs in a separate document.
As I  said earlier, I have a problem with putting features in protocols
that  nobody intends to use.  It's bad enough when it happens by
circumstance but doing it deliberately strikes me as a bad idea.

And while this may not be your problem, it's very much mine: this
kind of thing is bad for the IETF.  It discourages participation
(and, ironically, implementation) and it slows the process down
further, with no clear benefit (getting back to the implementation
question).  I've gotten an earful from several implementers about
this, and it concerns me.

Melinda

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 13 Apr 2018 00:40:41 -0400

> On Apr 13, 2018, at 12:07 AM, Melinda Shore <[email-masked]> wrote:
> 

The great irony of the situation, is that present draft already
describes pinning:

   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.

And I've seen no discussion or working group consensus to *prohibit*
such pinning, only observations that it would be rather fragile in
general.

What my proposal (B) (really (C), since (B) requires (A) as a foundation)
provides first and *foremost* is the ability for servers to DISABLE
pinning, by giving clients an upper bound pinning TTL of 0.

If you don't want to see pinning, voice your support for (B) (really C)
and have servers send a TTL of ZERO!

Keep in mind that the proposed TTL is an upper bound, it is NOT an
obligation to pin, and therefore is always a restriction on pinning,
while at the same supporting a signal that pinning may be safe at
the server's discretion.

So this both serves the overall interoperability objectives voiced
by Eric Rescorla, allows servers to disavow any pinning and supports
future cases.  It is a win-win, and carries ZERO implementation cost,
on the server, if pinning is explicitly unwanted, just the field to
zero and move along.  On the client if no pinning is desired, just
ignore the TTL.  This feature is a win/win and carries no implementation
burden, and the document is about to get a revision for (A) and still
awaits an IANA code point assignment.

If we act promptly on both (A) and (B) (i.e. (C)) there'll be zero
additional delay.

I sympathize strongly with the desire to keep specifications lean
and mean, but that desire is misplaced here.  The technical details
do matter, and both supporting DoE and setting a max "pin" TTL are
well motivated, improve interoperability and allow the server to
opt-out of the sort of fragile ad-hoc pinning described in the draft.

So please, let's not allow the general argument to deafen us to the
specific context of this document.  Though it needs at least (A) it
also needs (B) (i.e. (C)).

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Apr 2018 21:51:12 -0700

> such pinning, only observations that it would be rather fragile in

Thanks for pointing this out. I agree that this text is likely to cause
interop problems and should be removed or at least scoped out in
the case where client and server are unrelated. I regret that I didn't
catch it during my IESG review.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 13 Apr 2018 01:41:23 -0400

> On Apr 13, 2018, at 12:51 AM, Eric Rescorla <[email-masked]> wrote:
> 

Well (B) is a proposal for doing just that, making it
possible for servers to suppress any such pinning, but it
also allows for future use-cases in which pinning might be
desirable.

If we're revising the text anyway, and given that implementors
suffer no burden to insert (on the server) or ignore (on the
client) an extra two bytes in the extension, (so Melinda's
issue of added complexity is not a barrier here), the sensible
responsive change is to add support for (B) with a requirements
that clients not pin longer than requested, and servers should
generally set the TTL to zero, unless pinning is understood to
be fit for purpose in the given application, and the operator
is willing to commit for the indicated time.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Apr 2018 12:01:14 -0500

> A process mistake was made.

Yes, though this consensus call cures that (and moots that grounds for
appeal).

However, since it's become clear that the I-D undeniably has a problem
because it describes pinning behavior and lacks sufficient functionality
for that -- we really must now make a change.

IMO, the question is no longer whether to make changes, but which
changes to make.

Nico
--

---

From: Jim Fenton <[email-masked]>
Date: Fri, 13 Apr 2018 12:16:43 -0700

I haven't been following this WG closely but read the draft and
discussion to see what this was all about, so here's an opinion from a
somewhat external reviewer, not in the room in London:

> of time (Pinning with TTL)

From reading the abstract and introduction to this draft, it appears to
be proposing mostly a performance improvement for retrieving web pages
using DANE authentication. There is some security improvement, but that
seems to be incidental to the performance improvement. That would argue
in favor of publishing the draft as-is. However:
> If the answer to 1) is no then please indicate if you think the
> working group should work on the document to include 
>

There seems to be some disagreement whether the draft as written allows
inclusion of denial-of-existence proofs. So that's an ambiguity in the
spec, and I support resolving that ambiguity (hopefully in favor of
including them).

> of time (Pinning with TTL)

From the discussion I have read, there seems to be disagreement about
what even the semantics of this pinning would be. And if it's unclear to
the WG participants, it's going to be even less clear to others that are
implementing this. I am also of the opinion that pinning is somewhat
subtle; it requires a detailed understanding of the mechanism to remove
(expire) the pin, and if done wrong can result in availability problems.
In addition, the pins here would be maintained in individual browsers.
There is less benefit from pinning because unlike some other pinning
mechanisms, there isn't any leverage of the TOFU experience had by others.

This requires further thought, and I do not support adding pinning to
this draft. Perhaps as a separate draft, but the WG needs to decide on that.

> C) Both

Summary: (A)

-Jim

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Apr 2018 15:05:35 -0500

> catch it during my IESG review.

I think that means we'll end up with consensus to make a change, and
indeed, we cannot not make some change.  We can still debate whether to
do (A), (B), (C), or, now, (D) (remove the text quoted by Viktor).

I think it will be easier to get consensus for (A) or (C) than (D),
though, of course, that's to be seen.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Apr 2018 15:30:07 -0500

> t having a noninteroperable behavior in the document.

It's better to send the denial of existence than no extension -- the
client could just as well be pinning (because the I-D said it could, or
because the client does it regardless), and not having extension then
will cause failure.

Now, clients that don't do opportunistic pinning would have to... notice
the lack of TLSA RRs, but not necessarily bother validating the denial
of existence chain.  There's not even a need to say that the client
SHOULD (let alone MUST) validate the denial of existence chain.  It
suffices that the server SHOULD send it.

Nico
--

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2018 16:38:55 -0400

On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams <[email-masked]>
wrote:

> > On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni <[email-masked]
> >
> > wrote:
> > > Proposed text:
> > >

Sure seems like it would be simpler to say "Client MUST NOT cache TLSA
state".  Yes, that cuts off some use cases.  But it avoids all the
transition pain that EKR has pointed out.

--Richard

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 Apr 2018 10:31:11 -0500

> state".  Yes, that cuts off some use cases.  But it avoids all the

That's not the right way to say "no pinning".

> transition pain that EKR has pointed out.

The I-D needs *some* updates.  You and I disagree about which updates,
but it needs updates.  It cannot be published as-is.  Even removing any
kind of pinning requires WG consensus at this point.

And we've already seem that at least one author support (A), and we
could probably easily get support for a (C') where we get the two bytes
we're asking for as well but with as much semantics as possible left for
a follow-on I-D.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 Apr 2018 11:31:23 -0500

> in favor of publishing the draft as-is. However:

It's not just a performance improvement.  It's also a last-mile
technology: for clients that cannot perform DNS lookups due to being in,
e.g., hotel networks.  And it adds security.

Using DANE adds security, that's for sure, since one can then rely on
both, PKIX *and* DNSSEC, which can only add security.  Or, if one does
not trust the WebPKI, then only DNSSEC.  I have no opinion as to which
of WebPKI alone, WebPKI + DNSSEC, or DNSSEC alone, is best, but I have
an opinion as to who ought to decide that: the server operator.  This
document gives the server operator that power, but it does not give the
server operator any power over client pinning behavior, which means that
operators will not turn this on for apps where it's not mandatory.

That is, without revision, this document really does not help security
as much as with a rather minor revision.  We should want that minor
revision because the (at-this-time-intangible) gain is potentially
large, while the (at-this-time-intangible) cost/risk of not making that
revision is equally large.

> what even the semantics of this pinning would be. And if it's unclear to

Among proponents there are no disagreements over pinning semantics.
Pinning would be only to the use of the _extension_, not to the use of
DANE, nor to any particular DANE usage.  That is, if the server does not
have TLSA RRs, it could still use this extension [to satisfy a client
pin] to send the denial of existence proof, and the client's pin would
be satisfied.

> implementing this. I am also of the opinion that pinning is somewhat

How would that follow?  Shouldn't we see proposed text before we can
tell if it would be unclear to implementors?

> (expire) the pin, and if done wrong can result in availability problems.

Exactly!

(A) gives us a modicum of pin-clearing capability: if you get a denial
of existence then you could clear the pin on the client.

However, (A) + (B) (i.e., (C)) would give us the ability to separate the
pin set/clear from the DNSSEC payload of the extension.  *This* would
give server operators all the control they need to feel safe enabling
pinning behavior.

It is much simpler to change a TTL in a server configuration than to
make changes in the relevant DNS zone(s).  Thus (C) or some (C') (see
below) would be much better than (A).

> In addition, the pins here would be maintained in individual browsers.

And other user-agents for other application protocols (e.g., MUAs).

> mechanisms, there isn't any leverage of the TOFU experience had by others.

TOFU works reasonably well.  It's risky for an attacker to mount an
active attack that will be detected if the client has a pin -- this risk
acts as deterrent.

> this draft. Perhaps as a separate draft, but the WG needs to decide on that.

I wouldn't mind a (C'): a variant of (C) where we get denial of
existence and a one- or two-byte TTL (one by count of weeks or two-byte
count of hours) with de minimis text about it, leaving pinning semantics
to a separate document.  In such a (C') we'd elide all pinning (or most*)
in this document.

* We might want to say that if the TTL is zero then the clients MUST NOT
  pin and must clear any pin.  And we might do this in spite of not
  describing any pinning semantics -- explicitly leaving pinning
  semantics to a future document.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 Apr 2018 13:06:44 -0400

> On Apr 16, 2018, at 12:31 PM, Nico Williams <[email-masked]> wrote:
> 

Specifically, this actually would help the cause of those who don't
want pinning, because in (C') we can specify:

  * Client's MUST NOT employ any pinning for downgrade protection
    when the extension support TTL sent by the server is ZERO.
    Only a-priori local policy that mandates DANE TLSA records
    for particular domains can require the extension, in all other
    cases the extension MUST be optional in future connections
    when an authenticated server returns a ZERO extension TTL.

  * Pending future specifications, the server MUST set the extension
    support TTL to ZERO.

With this, we get to explicitly specify that clients MUST NOT pin,
rather than removing text and leaving the option up to the implementors
imagination.  And implementors will want downgrade protection, and the
current list of half-baked downgrade protection measures in Section 8
was in place at the time of the WG LC consensus for moving the draft
forward, and these were added in lieu of tackling downgrades in a more
systematic way, so ripping it all out does not seem like a minor tweak.

If we add a two byte extension support TTL field, that servers will
set to ZERO, and tell clients to not attempt downgrade protection
when it is so set, we leave room for future downgrade protection
without having to change the extension wire format.

With the TTL always returned as ZERO in the recent past, the server
is equally free to return denial of existence or just not present the
extension.  Operator's choice.

This way, the draft retains the option of future downgrade protection,
thus not completely abandoning its promised scope, while deferring any
pinning for now, and indeed making it very clear to clients that they
MUST NOT (yet) do any TOFU or similar pinning.

>  semantics to a future document.

Exactly.  I'd like to suggest that this is the most reasonable
common ground, and would urge the WG and authors to get behind
this as a consensus position.

-- 
	Viktor.

---

From: Bill Frantz <[email-masked]>
Date: Mon, 16 Apr 2018 10:29:20 -0700

>to a separate document.  In such a (C') we'd elide all pinning (or most*)

I have always worried about the trust model in PKIX, and thought 
that some form of pinning would an excellent enhancement -- 
modeling how individuals work in the real world:

   Alice, I'd like you to meet Bob. He is an expert in... (Alice 
learns Bob's voice pattern.)

   Bob, this is Alice, I'd like you to... (Alice recognizes 
Bob's voice in the reply.)

I strongly support C or C' as the best way forward, allowing a 
future RFC to address the pinning details. Viktor has some good 
suggestions as well.

Note: I have not been involved in any face-to-face meetings or hums.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 
Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, 
CA 95032

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Apr 2018 16:21:27 -0400 (EDT)

> this as a consensus position.

This seems dangerous. If an attacker can re-route and get a rogue
cert, they can set TTL to 0, negating a previously set TTL, without
requiring proof by presenting the denial-of-existence of the TLSA
record. That is also a downgrade attack.

How to go from TTL != 0 to TTL == 0 should be specified carefully,
either in this document or its own document.

The only known save way of going to TTL == 0 is by presenting DoE of
TLSA records (but it does bind using the TLS extension to the existence
of TLSA records)

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 Apr 2018 16:33:18 -0400

> On Apr 16, 2018, at 4:21 PM, Paul Wouters <[email-masked]> wrote:
> 

I did not spell out all the details, which would belong in the
later pinning specification (some of this was described upthread).
Once a non-zero pin is in place, a pin TTL of 0 would require a
denial of existence proof or a handshake authenticated with extant
TLSA RRs.

> TLSA records (but it does bind using the TLS extension to the existence

While some previous TTL has not expired, getting to zero requires either
DoE or TLSA-authenticated handshake with TTL == 0.

But, if we're compromising on (C'), then this discussion becomes out of
scope for the present draft, and will be one of the key design elements
of the future downgrade protection ("pinning") draft.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 Apr 2018 16:16:29 -0500

> record. That is also a downgrade attack.

The extension would have to be present and contain either the TLSA RRs
and chain, OR the denial of existence chain, in order to even to carry
any TTL value.

Only in the denial of existence case could an impersonator set a TTL
value of the impersonator's choice, and in this case the client must
treat it as zero in order to avoid a DoS.  In the other case, the
impersonator could *not* set a TTL of their choice without compromising
DNSSEC.

> either in this document or its own document.

If the server sends a denial of existence, then the TTL can't be fully
trusted, and there is a DoS if the client uses non-zero TTL values.  If
the server sends TLSA RRs and chain then all TTL values can be trusted
and should be used, though we might specify how in a later document.

> TLSA records (but it does bind using the TLS extension to the existence

The TTL will be coerced zero on DoE, but it can be set to zero in the
TLSA case as well.

Nico
--

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 18 Apr 2018 11:22:24 -0700

We've had a lot of discussion on this thread that has pointed out that
there are enough issues with the current document that we should recommend
that the AD pull it back from the RFC editor.

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

I understand that not everyone is happy with publishing the document scoped
down in this way, but there is a community of users who would find it
useful.  I am soliciting suggestions for text for the 1-3 and I encourage
proponents of the more restrictive use case to get a draft together that we
can consider for adoption by the working group.

I also want to thank the participants for keeping the discussion mostly
civil and having patience as we go through this process.

Joe

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2018 15:23:02 -0400

> extension that supports pinning

SGTM

>
> I understand that not everyone is happy with publishing the document
> scoped down in this way, but there is a community of users who would find
> it useful.  I am soliciting suggestions for text for the 1-3 and I
> encourage proponents of the more restrictive use case to get a draft
> together that we can consider for adoption by the working group.
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 18 Apr 2018 12:20:21 -0800

On 4/18/18 10:22 AM, Joseph Salowey 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:
> 

This sounds reasonable.  I'll talk with co-editors about text
changes.

Melinda

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Apr 2018 16:42:42 -0400 (EDT)

On Wed, 18 Apr 2018, Joseph Salowey wrote:

This is a combined response of Viktor, Nico and Paul.

>  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:

A slight correction here. The call that there is no consensus on pinning
is not entirely correct. The discussion showed a majority of people in
favour of some kind of pinning, but with most people being agreeable that
this can be in its own document and not hold up this document further. A
pinning document is inevitably coming.

>  1. Scope the document to the assertive use cases

This means actually leaving out what some of us think are the most
important use case - an alternative for webpki. While we are okay
to reduce the scope of this document, it seems logical that such
decision comes with some guarantees to allow the other use cases.
Which gets us back to a new document about pinning (see below)

>  2. Explicitly allow (but do not require) DoE be included

The document does not currently allow the extension to be empty. So if
there is no TLSA record and the extension would be present, it therefore
can only contain a DoE chain. So what do you mean with item 2? Possibly
you mean to say "if there is no TLSA record, the extension can be omited
or the extension can be included with a DoE chain" ? That would be okay
with us.

>  3. Remove current text about pinning

That is fine, but one caveat below.

>  extension that supports pinning

While we agree we can move pinning to a separate document, it makes much
less sense for this to become an additional fully independent TLS
extension, especially since the pinning will depend on DNSSEC properties
only delivered by the TLS-DNSSEC extension. So as we suggested before, the
best solution therefore would be to define this two byte pin in the
current document, and be defined as "ignore completely unless you
implement this other RFC". That is,

      The proposed 16-byte "extension support lifetime" field will:

        * Have 0 as the only value defined in the present draft
        * Servers that implement only the present draft SHALL send 0.
        * Clients that implement only the present draft SHALL treat
          any value received as though it were 0.
        * A zero "extension support lifetime" field prohibits the
          client from unilaterally mandating the extension based
          on prior observation of its presence (pinning).

This a win-win for both opponents and proponents of pinning. And not
only that, it will allow us to put the pinning inside the extension
it relates to.

Additionally, with no pin set to 0 in the current document, and no
mentioning of pinning since the consensus agrees to remove it that,
client implementations will not be told to not pin, and will start doing
something like TOFU like pinning. It would actually be better to specify
this zero pin to prevent this from happening.

If you take it as a given that we will write this document, then it only
makes logical sense to already reserve these two bytes in the current
document, even it if states "must be 0". Our document will Update:
this document to describe the pinning in detail.

Nico, Paul and Viktor

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2018 16:47:25 -0400

On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters <[email-masked]> wrote:

>> and I
> important use case - an alternative for webpki.

A down-scoped document can perfectly well be used as an alternative to the
Web PKI.  As noted before, clients can offer what they support, and servers
can switch.

> While we are okay

I do not support adding a field to the protocol with semantics to be
defined later.  Especially a 16-byte field, which is a fair bit of cruft to
carry around.

This seems perfectly suitable for a separate extension.

--Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 16:48:47 -0400

> On Apr 18, 2018, at 4:47 PM, Richard Barnes <[email-masked]> wrote:
> 
> I do not support adding a field to the protocol with semantics to be defined later.  Especially a 16-byte field, which is a fair bit of cruft to carry around.

The 16-byte is a typo.  It was supposed to be 16-bit.  My fault. Sorry.

-- 
	Viktor.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2018 16:52:14 -0400

> The 16-byte is a typo.  It was supposed to be 16-bit.  My fault. Sorry.

Secondary point.  Still don't think we should deliberately include
undefined fields, e.g., because part of the discussion is whether 16 bits
is the right size.

--Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 16:53:53 -0400

> I do not support adding a field to the protocol with semantics to be defined later. 

And the semantics are defined.  The server must send zero, and the client must read it as zero.  The propose semantics PROHIBIT pinning, which is what everyone seems to want presently.

Future semantics when BOTH client and server implement a forthcoming spec will to support pinning as described for up to the indicated time (in suitable units).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 16:56:39 -0400

> On Apr 18, 2018, at 4:52 PM, Richard Barnes <[email-masked]> wrote:
> 
> Secondary point.  Still don't think we should deliberately include undefined fields, e.g., because part of the discussion is whether 16 bits is the right size.

16 bits is clearly enough.  If the units are hours that gets you ~7.5 years.  Pinning for less than an hour is pointless, it then becomes smaller than typical DNS TTLs for the TLSA  RRset the client got previously, which it can cache without any pinning.

Pinning for more than 7.5 years is absurd, it only protect clients that connect less than twice per decade...

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2018 15:56:04 -0500

> undefined fields, e.g., because part of the discussion is whether 16 bits

It's not as if we've never had reserved fields.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2018 17:01:54 -0400

On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni <[email-masked]>
wrote:

> 16 bits is clearly enough.  If the units are hours that gets you ~7.5
> years.  Pinning for less than an hour is pointless, it then becomes smaller
> than typical DNS TTLs for the TLSA  RRset the client got previously, which
> it can cache without any pinning.
>

640k should be enough for anyone.

`preload`?  `includeSubdomains`?  Experience with HSTS and HPKP shows you
need more than an integer.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2018 17:03:58 -0400

On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams <[email-masked]>
wrote:

> > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni <[email-masked]
> >
> > wrote:
> >
> > >
> > >

The only "reserved" in RFC 5246 is a few code points that are reserved for
private use.  No reserved fields.

--Richard

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2018 16:06:16 -0500

> 640k should be enough for anyone.

That's just silly.  Really, 7.5 years (relative, not absolute) measured
in hours is plenty good enough, and more than outlives current device
obsolescence.  This isn't subject to Moore's law or anything like it.

> need more than an integer.

No, we need none of those things.  We want only to pin the presence of
this extension.  Anything else would be operationally difficult (as seen
with HPKP).  As to subdomains, we're willing to live with TOFU semantics
for all of them.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 17:15:12 -0400

> On Apr 18, 2018, at 5:03 PM, Richard Barnes <[email-masked]> wrote:
> 
> The only "reserved" in RFC 5246 is a few code points that are reserved for private use.  No reserved fields.

The field is NOT reserved, it carries an "extension support lifetime" of 16-bits whose zero value means "DO NOT PIN".  Other values will be defined in a follow-on draft, but clients must interpret those also as zero unless they implement the other draft.

Therefore, a client implementing this draft has complete semantics for the field, it explicitly prohibits pinning, which might otherwise happen, especially if no follow-on document materializes.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Apr 2018 18:35:43 -0400

> or the extension can be included with a DoE chain" ? That would be okay

Yes, my understanding is that's what it means.

Note that Section 8 ("Mandating Use") already did hint at the future
possibility of
this extension carrying a DoE chain that could be deployed in a TLS
application
ecosystem where all servers understood and were prepared to respond to this
extension. The plan is to now add text that allows DoE chains more
generally,
with details of use defined in subsequent documents.

Shumon.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 19 Apr 2018 03:25:24 +0000

Nico Williams <[email-masked]> writes:

>That's just silly.  Really, 7.5 years (relative, not absolute) measured in
>hours is plenty good enough, and more than outlives current device

I don't know what devices you work with, but for the ones where my code is
used ten years is the baseline life expectancy, going out to 15-20 years for
longer-life ones (I still have to deal with SSH bugs from the late 1990s,
because the lifetime of the equipment that's used in is 20 years and counting.
I think I've finally managed to get away from having to do SSLv3 within the
last year or two).

OTOH I doubt any of these devices will do pinning, they just bake in the certs
at manufacture/provisioning, so I'm fine with any kind of lifetime.  Just
wanted to point out, yet again, that the entire world doesn't live in a "we
can patch the entire deployed base in 24 hours" situation.

peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 23:34:14 -0400

> On Apr 18, 2018, at 11:25 PM, Peter Gutmann <[email-masked]> wrote:
> 

Indeed, but if pinning were desired, all the device would have to do is call the mother ship at least twice per decade, it can then work for multiple decades.

I agree for many devices that don't wander the web in search of the latest cute kitten photos, and just "call home", a single fixed cert is a more plausible security model than either WebPKI or DANE.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2018 22:25:17 -0500

On Wed, Apr 18, 2018 at 11:34:14PM -0400, Viktor Dukhovni wrote:
> Indeed, but if pinning were desired, all the device would have to do
> is call the mother ship at least twice per decade, it can then work
> for multiple decades.

Exactly.

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 19 Apr 2018 21:09:00 -0700

On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters <[email-masked]> wrote:

<snip>
> this document to describe the pinning in detail.
[Joe] This can also be done with a new extension code point that defines a
replacement extension that adds the pinning policy.  This seems like viable
possibility, we are not running short on extension code points.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Apr 2018 01:33:23 -0400

> On Apr 20, 2018, at 12:09 AM, Joseph Salowey <[email-masked]> wrote:
> 
> [Joe] This can also be done with a new extension code point that defines a replacement extension that adds the pinning policy.  This seems like viable possibility, we are not running short on extension code points.  

This looks like the lose-lose version.

  * The present extension loses all downgrade from original LC,
    and gets a reduced scope, all without a clear consensus to
    limit the scope or lose all downgrade protection, with the
    path forward on restoring it more uncertain.

  * No explicit do not pin signal in the present extension.

  * Should a second extension be defined later, clients have
    to signal two separate extensions, and servers have to
    respond with two separate extensions. Complicating
    implementation, all to save two bytes in the present
    extension, with those two bytes providing a clear do
    not pin signal, not pinning at this time does have
    consensus.

  * With the extra two bytes the next specification merely
    needs to allow new interpretations of non-zero values,
    with no new wire formats for anyone to implement.
    THe upgrade path for both clients and servers becomes
    simple, just extend the capabilities of an extension
    they may already support, or which existing code can
    be found.

The requested 2-bytes carry no implementation burden for
parties that would implement the extension without those
bytes.  Worst-case they'll never be used, but they do
signal good-will on the part of those who want a minimal
extension now to allow the follow-on specification to be
developed.

The close attention to the content of this document that
resulted from the disparate views of its proper scope has
found important issues that were missed, and corrected an
unnecessary limitation (prohibition of denial of existence).

Though some delay has resulted, the document is better off
for it.  I think it is fair to ask for good faith in return,
at a negligible cost of 16 bits that might if things don't
go to plan forever remain zero, but will at least explicitly
signal to the client that pinning based on prior observation
of the extension should not take place.

Refusing to make a trivial concession to gain a broader
base of support for the document, just to save two bytes
does not look like an inclusive process to me.

-- 
	Viktor.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 23 Apr 2018 21:42:13 -0700

When your revisions are ready please post them to the list in OLD and NEW
format so the working group can evaluate them.

Thanks,

Joe

On Wed, Apr 18, 2018 at 1:20 PM, Melinda Shore <[email-masked]