Subject: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 5 Nov 2018 07:01:57 -0600

Hi all,

I do not know whether Wednesday's discussions will end up in a place where
these thoughts will be useful, but in the spirit of having discussions on
the list, I decided to write up some thoughts I've been pondering for a
while.  Hopefully the written form will be more clear than if I had to try
to express them in the mic line, and perhaps they will even inspire
thoughts from other people as well.

That said, I recognize that I am posting this pretty late and the one day
between now and then is already packed with meeting sessions, so I do not
expect to have a complete discussion on the list before the Wednesday
session.  (As always, happy to be proven wrong.)  So...

Once we start talking about pinning of any sort, we move from this
extension just being "transport some DNS records" into conveying some
sort of additional semantics.

It seems that we have not really had a structured discussion about what
semantics and information flows we might or might not want to convey in
this extension (in one or both directions!), and I'm reluctant to consider
adding such semantics without such a discussion.

If we accept the premise that the intention of DANE as relevant in this
space is to allow the server to convey to the client the server's
preferences for how the client should authenticate the server, we may also
want to consider the case where a server operator wants to eventually get
to a DANE-only state where it can ignore the web PKI.  (There may not be
many or any servers that actually end up wanting to do this, but it's not
unreasonable to consider the possibility.)  In order for a server to do
that, the server needs to know that all clients are not only willing to do
DANE, but able to get the records they need, whether via this extension or
otherwise!  Without such information, the server risks breaking clients
with the transition, and not knowing what population of clients have been
broken.

Doing some brainstorming on what the client might be able to tell the
server in this space, I can come up with things like:

(1) the client is willing to use DANE to authenticate the server
(2) the client already has the DANE records it needs to do (1)
(3) the client needs the server to give it the DANE records to do (1)
(4) the client requires the server to be DANE authenticated
(5) the client already has the DANE records it needs to do (4)
(6) the client needs the server to give it the DANE records to do (4)
(7) the client is willing to commit to one or more of the above for some
    time period

Similarly, the server may want to indicate things like:

(a) the server wants to be authenticated via DANE (yes, this is just the
    contents of the DNS)
(b) the server can provide DANE/DoE records in a TLS extension
(c) the server will commit to (a) for some time
(d) the server will commit to (b) for some time

Some of these might be always a consequence of or very strongly implied by
the presence of some information (e.g, sending the extension probably
implies (1), and having TLSA records at all probably implies (a)).  My
understanding is that the pinning proponents want a field in the server
response that conveys (d).  Note that this does not necessarily imply (a)
or (c), at least not with the same timer!

I deliberately am not trying to come to a conclusion in this message, as I
am not confident that I have even come up with all the potential semantics
worth thinking about, and I think that any motion in this space should only
be taken with WG consensus.

I would love to hear others' thoughts on what I am missing from the above
lists, reasoning for/against including protocol elements to indicate
the listed semantics, and whether/which existing protocol elements already
convey which of the enumerated semantics.

Thanks,

Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 5 Nov 2018 09:00:29 -0500

> On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

Transporting some bits *always* carries additional semantics, otherwise
why carry the bits.  For example, already in -07 there is clear text
specifying that the transported records can be cached for their DNS TTL,
and that once delivered DANE records should not be ignored on failure.

   https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-6

   A TLS client making use of this specification, and which receives a
   DNSSEC authentication chain extension from a server, MUST use this
   information to perform DANE authentication of the server.  In order
   to do this, it uses the mechanism specified by the DNSSEC protocol
   [RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
   DNSSEC validation engine or library.

   Clients MAY cache the server's validated TLSA RRset or other
   validated portions of the chain as an optimization to save signature
   verification work for future connections.  The period of such caching
   MUST NOT exceed the TTL associated with those records.  A client that
   possesses a validated and unexpired TLSA RRset or the full chain in
   its cache does not need to send the dnssec_chain extension for
   subsequent connections to the same TLS server.  It can use the cached
   information to perform DANE authentication.

That rather looks like semantics to me, much more than transport some bits.

> adding such semantics without such a discussion.

I really don't think that at this juncture it is productive to wipe the
slate clean and consider all possible proposals, even ones that nobody
has put forward as yet.  Why would we want to do that.  There is clearly
just one primary contentious issue to resolve, and I rather think your
train of thought is a distraction from the issue at hand.

> to a DANE-only state where it can ignore the web PKI.

Nobody is looking for this.  There's no point.  WebPKI certificates are
free (and worth every penny).  DANE adoption is far too light to even
begin to contemplate abandoning WebPKI, and we're probably two decades
away from being able to do that, by which point the quantum computer
apocalypse may have made many of the current designs moot.

> (There may not be
> unreasonable to consider the possibility.)

It seems unreasonable to me, because no such signalling was for example
proposed for raw public keys or various PSK methods, etc.  And of course
the server operator can log the use of the extension and draw conclusions
about client support based on that, and the overall technology landscape.
There's no need to include this in the discussion.

> (a) the server wants to be authenticated via DANE (yes, this is just the

And any client with a decent network environment can just query the
DNS directly, and never use the extension and have the record hot
in the local cache.  So there's no need for anything to complicated
here.  We just need to provide as much of the downgrade-resistance
that DNSSEC gives automatically, also to clients that for some time
will be able to do DNSSEC.

> be taken with WG consensus.

I think at this point hypothetical semantics is not a helpful direction.
If you have a concrete proposal, that has merit in addition to or in
place of what has been proposed, please explain.  If there are problems
or lack of clarity with what has been proposed, please explain.

I very much fear that the only possible outcome of sky's-the-limit
brainstorming is paralysis.  Please try and focus on actual proposals.

> convey which of the enumerated semantics.

The proposal on the table is to a minimal form of time-limited commitment
to the extension by mutual agreement between client and server, to address
downgrade attacks via extension stripping by attackers with unauthorised
WebPKI credentials.  This is need because while DNS lookups either deliver
the relevant DNSSEC data or clearly fail, the extension is optional and
failure to deliver it is a-priori not in any way anomalous.

We're just trying to address that gap.  If you can make a strong case
for addressing some additional gaps, or addressing this gap in a better
way, please do.  Once again, I'm very concerned that the direction you're
setting out on is counter-productive.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 5 Nov 2018 14:37:26 +0000

Is it fair to describe the draft as enabling a trust model based on DNSSEC, rather than the default X.509 hierarchy and trust store which is implemented by default?

Please try very hard to keep the answer brief.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 5 Nov 2018 09:22:33 -0600

> Please try very hard to keep the answer brief.

In my mind that's one of the things it could do, but need not be the only one.
In https://www.ietf.org/mail-archive/web/tls/current/msg27088.html I
tried to consider the possibility for clients that currently default to
the X.509 hierarchy but also clients that use opportunistic TLS or other
default behaviors.  The analysis of the security properties of adding
DANE depends on what we use as a starting point.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 5 Nov 2018 10:33:12 -0500

[ I hope the below is short enough...]

> On Nov 5, 2018, at 9:37 AM, Salz, Rich <[email-masked]> wrote:
> 

The original (-07) draft only does the job for applications that
go all in on DANE and statically skip the WebPKI.

What we're trying to do is to make DANE meaningfully available
also to existing applications where the WebPKI still rules the
roost, and where clients can only determine which servers support
DANE "opportunistically", but for that to be useful, the signal
needs some downgrade resistance.

The ultimate goal is to be able to use DANE either instead of,
or in combination with the WebPKI.  Which it is depends on the
DANE certificate usages that the application supports and server
publishes.  We're not trying to kill the WebPKI, rather we want
the *option* to use DANE when client and server opt-in.

Finally, of course, the reason for the extension is last-mile
issues with DNSSEC in captive portals and behind DNS-challenged
home routers, plus a bit of latency concern (that may be overblown,
but still seems an issue for some).

-- 
	Viktor.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Nov 2018 11:11:59 -0600

> sort of additional semantics.

The I-D lost consensus over one issue.  We should resolve that issue.

There are some minor other things (like the fact that TLSA RR names
include a port number and the TLS server needs to know, or that we
shouldn't specify an RR sort order, or that the age of the chain payload
needs to be included), but they are minor by comparison.  Whether we
discuss those first or the main event is not that interesting to me, but
if we're going to make progress I think we should have time for the main
event.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 5 Nov 2018 13:44:18 -0500

> On Nov 5, 2018, at 1:22 PM, Salz, Rich <[email-masked]> wrote:
> 
> I need to review things some more, but FYI I believe I will say that mixing
> trust models is a bad idea, and opportunistic fallback seems both premature
> optimization and adding in the risk. I would support bringing back -07 semantics.

That's the trouble with "short responses", they are too short to get the key
details across.  This is NOT a simple issue that can adequately be reduced
to a couple of pithy paragraphs.

The -07 document is broken and has lost consensus.  It has a broken unilateral
client-side TOFU pinning downgrade protection mechanism, that nobody wants.
Removing it entirely severely limits the scope of the draft to much less than
was intended and was promised in the introduction.

We're not "mixing" trust models, DANE explicitly supports either augmenting
WebPKI (certificate usage 0/1) with CA or EE certificate assertions, or 
bypassing it with usages 2/3.  SMTP does 2/3 only, I would expect browsers
to look to do 0/1, which has the benefit of getting both DANE and CT, DANE
provides stronger authentication than DV cert issuances, while CT provides
some measure of auditability.

There are many problems with -07 beyond just pinning, various gaps in the
smaller design that really should be addressed.

I could write more, but then folks are liable to stop reading, I don't know
how to get past that, except by becoming an author, and finally issuing
a new version of the draft for review (~25 commits pending on github waiting
for the green light), that folks might have to actually read all the way
through... :-(

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 5 Nov 2018 21:54:19 -0500 (EST)

> Is it fair to describe the draft as enabling a trust model based on DNSSEC, rather than the default X.509 hierarchy and trust store which is implemented by default?

The draft tries to enable a trust model based on DNSSEC, but due to
missing pinning, fails to deliver that.

A better way is saying the draft enables a trust model that restricts
the webpki, addressing the problems of too many unrestricted root CA
players being accepted by  TLS clients these days [provided the draft
adds a mechanism like pinning to prevent downgrade attacks]

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 5 Nov 2018 21:27:47 -0600

> adds a mechanism like pinning to prevent downgrade attacks]

If we don't agree on what the draft is trying to do, it seems rather
difficult to attempt to claim that there is WG consensus to publish it.

This seems to suggest that we may need more precise text in the
document about what it is (and is not) trying to do.  The slides Sean
posted for the Wednesday session note that fairly early in the timeline
we thought:

    Primarily aimed at making
    DANE practical for HTTPS,
    where last-mile considerations
    on the client end are a
    significant part of the adoption
    barrier.

Paul, are you proposing that this would only be PKIX-{EE,CA} to the
exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)

Thanks,

Ben

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Nov 2018 00:01:52 -0500 (EST)

> posted for the Wednesday session note that fairly early in the timeline

I havent looked at the slides yet, I didnt see anything last time I
looked to see what te Wednesday slot would be like.

> exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)

No. The restriction of webpki can be to restrict to 0 webpki root CA's
and instead restrict to an EE cert or public key, as per TLSA usage selectors.

I was trying to be as short as possible for Rich, and keep the focus on
ensuring the draft gains support for restricting, for which we currently
have one proposal (pinning).

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 Nov 2018 00:02:14 -0500

> On Nov 5, 2018, at 10:27 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

I think that deciding which DANE usage are most appropriate for
browsers is up to the folks who think deeply about Web browsers
and Web servers, and I would not presume to tell them which model
they should find more attractive.  My expectation would be that
they would be more comfortable with PKIX-{EE,TA}, because that
gives both the strongest security guarantee and preserves
certificate transparency as an option.

In SMTP, I got consensus for just specifying DANE-{EE,TA}, but
for HTTP I can well imagine a different outcome.  The key reason
for the divergence is that SMTP security depends critically on
the integrity of MX records, so if you DNS is compromised PKI
does not help much.

HTTP does not use MX, SRV or similar indirection, so the analysis
comes out differently.

This draft will not define a single approach for all applications,
that's up to the various application area specialists to figure out.

-- 
-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 5 Nov 2018 23:11:39 -0600

> have one proposal (pinning).

Okay, thanks.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Nov 2018 10:05:14 -0600

> Transporting some bits *always* carries additional semantics, otherwise

Of course!  But if we don't precisely specify those semantics, we expect
to get DISCUSS positions at IESG evaluation (as "not interoperably
implementable").

> and that once delivered DANE records should not be ignored on failure.
[...]
> That rather looks like semantics to me, much more than transport some bits.

Is it new semantics for this TLS extension, or just the semantics of "you
have a DANE record; this is what you do with it"?

> has put forward as yet.  Why would we want to do that.  There is clearly

When we do work at the IETF, proposals are not presented as a "take it
or leave it" option -- usually, they are starting points for further
analysis and discussion: "is this optimal?", "is it better if we tweak
it in this way?", etc.  I am presenting a framework in which to try to
answer these questions, starting from the proposal on the table.

In other words, I am pointing out that there is a process step that
needs to happen before this draft can be published.  This need not start
from a "clean slate", but we do need to be confident that we understand
what we are publishing.

> train of thought is a distraction from the issue at hand.

The IETF process requires reaching a consensus understanding of the
technical facts of an issue.  My train of thought is an effort to seek
that understanding in the area of downgrade countermeasures, since in my
judgement it has not been achieved by the previous WG discussions.  If
we have no WG consensus understanding of pinning, we cannot publish
pinning.  That could mean not publishing at all, or publishing something
that lacks pinning.  The latter would of course not preclude other work on
pinning by interested parties.

> apocalypse may have made many of the current designs moot.

That's good input; thanks.

> There's no need to include this in the discussion.

The chairs should feel free to shut this down if needed.
But I'll note that the server's logging is not going to get any signal
from clients that can get DANE records via their normal resolver, with
the current proposal.

> in the local cache.  So there's no need for anything too complicated

I think I'm confused about what you mean by "the downgrade-resistance
that DNSSEC gives automatically".

> I think at this point hypothetical semantics is not a helpful direction.

I'm sorry you feel that way.  We've seen a few participants raise a
specific pinning proposal but they seem to have squelched discussion of
any other pinning options.  It seems that in any case the semantics are
hypothetical until we have a consensus and/or deployment experience.

> or lack of clarity with what has been proposed, please explain.

I have made my proposals to the list.  The WG as a whole does not have
consensus on a conclusion or the relative merits of the concrete
proposals that have been made to the list.

> brainstorming is paralysis.  Please try and focus on actual proposals.

My original mail, trimmed in your response, did list actual proposals.
Some of them are probably easy to find flaws in, which is the sort of
response I was asking for.  Having a written record of what has been
proposed and how the various proposals compare on a technical basis is
very helpful when judging consensus.

> setting out on is counter-productive.

I, on the other hand, am very concerned that you are pushing for the WG
to publish a solution without proper discussion of its merits and
potential alternatives.  I am trying to help you frame such a discussion
and come to a consensus conclusion following IETF process, and you are
avoiding a technical discussion.  Continuing down your path is likely to
either cause the document to die or to revert to the previous consensus
"HTTPS" use case, leaving any particular pinning policy to be determined
outside this TLS extension, whether at the application protocol layer or
in the implementation.

If you believe that I, acting as Area Director, am attempting to abuse
process to stymie consensus work, you have various appeal and recall
options available.  I'm happy to chat further with you about those
options if you want.

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 7 Nov 2018 00:20:55 +0700

My question would be "what will the HTTP community do if they find this
whole process unwieldy and long"?
Answer  They will come up with a solution that does nothing with DANE.

is that an excuse to do something less than perfect for the better good, or
do we live in the world of smug satisfaction of being perfect?

Sorry, from reading this discussion that's my simple minded view.

Tim

On Tue, Nov 6, 2018 at 11:07 PM Benjamin Kaduk <[email-masked]> wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 Nov 2018 13:16:22 -0500

> to get DISCUSS positions at IESG evaluation (as "not interoperably

Yes, that's why the draft once updated will need to explain the
semantics, rationale, limitations, risks, ... of any approach it
ultimately takes.

> have a DANE record; this is what you do with it"?

Well, in -07 there is also a TOFU unilateral pinning proposal, added
in a hasty (and little noticed at the end of the original process)
attempt to close the gap between promised and viable scope.  Otherwise,
yes, it mostly tries to parallel what happens when TLSA records are
obtained directly from DNS.

> answer these questions, starting from the proposal on the table.

Please pardon my frustration with the recent deadlock.  If my
objection is excessive, I apologise.  That said, I do hope that the
discussion will have some focus.

* We've made a substantive proposal, explaining both the need for
  downgrade protection to make the extension more widely applicable,
  and that risks do not entail anything like an HPKP footgun.
* The chairs have summarized the issues, and asked for any substantive
  objections to the summary... none were made.
* I do think it is time to actually settle two basic questions:

    * Expand the scope to cover existing applications, or
      rewrite the introduction to say this is a DPRIVE-only
      extension to TLS, and explain why the scope should not
      be any wider.

    * Get past instinctive reactions to pinning the extension
      (which bears little resemblance to HPKP), and if so move on
      to figuring out the design parameters.  Maximum duration,
      any gradual scaling to give server operators time to adopt,
      or no scaling because the risk of hostile pinning is minor
      and not worth the complexity, ...

Yes, of course other topics can also be discussed, but I hope not
to the exclusion of moving past the present roadblocks.  This is
not the end of the process, more of a new beginning, which once
progress resumes will leave room for additional considerations.

> that DNSSEC gives automatically".

When a client using this extension asks the server for a DNSSEC
chain, absent any prior commitment by the server, it cannot expect
the answer, and not getting one will be the default "normal", not
a failure

When a validating DNS resolver asks a DNS question it always expects
a DNS answer, failing to get an answer, or getting an invalid answer
is a failure.  Sadly in some captive portals and behind some crippled
home CPE equipment, failure is more common than we'd like, but still
it is clear that getting no answer, or an invalid answer is a
failure.

> any other pinning options.

There have been no substantive alternative pinning proposals.  All
I've seen is suggesting for a "testing" mode, which is not viable
here, as already explained, and out-of-band reporting is also not
a good option, an in-band alert would be far simpler and better.

Once again sorry if you feel shut down, not my intention, just
trying to get some focus on specific refinements or objections, so
we can move forward (or not) and if so then entertain more suggested
refinements.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Nov 2018 16:43:54 -0600

We've had a couple of conference calls to discuss the I-D.

One call ended up causing the consensus on the I-D to collapse.

The second call ended too soon, but it was not unproductive.  Indeed, I
think at that call and in the subsequent off-list threads we identified
the concerns with pinning:

 - footgun concerns
 - hostile abuse concerns

Now, I believe we have demonstrated that there is no footgun: whenever
you can set the pin, you can also clear the pin.  At worst one might
first upgrade a server to gain support for the extension, set a pin,
then downgrade for some reason and thus footgun -- but the fix is to
upgrade again, or not set the pin immediately upon upgrade.  We also
have a mitigation for upgrade-set-pin-downgrade case (exponential
scaling of the pin timer with age of the RFC).

The second concern is, IMO, a non-concern, but granting for argument's
sake that it might be anyways, our answer to it is that sufficiently far
into the future the victim's server will support the extension, thus it
will be able to clear a hostile pin, therefore the exponential pin timer
scaling idea will give servers time to gain support for the extension
before anyone could ever make hostile use of the pin.

I believe we have put away those two concerns.  If we have not, please
say so and explain such that we might (or that we might see the errors
of our ways).

Are there any other reasons not to accept the proposed pinning scheme?

If no one can state any such reasons, why shouldn't we just accept the
proposal?

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Nov 2018 23:10:39 -0500 (EST)

> that DNSSEC gives automatically".

You cannot filter DNSSEC without the target being aware of being
filtered (where filtering == downgrading)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Nov 2018 23:13:08 -0500 (EST)

On Wed, 7 Nov 2018, Tim Wicinski wrote:

> My question would be "what will the HTTP community do if they find this whole process unwieldy and long"? Answer  They will come up with a
> solution that does nothing with DANE. 

They dont need to do anything to not have DANE. They already not have it.

> do we live in the world of smug satisfaction of being perfect? 

100% downgradable security is not security. It is not about being smug
or perfect.

Paul