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

[Sam Hartman <[e-mail]>]

I realize I'm not following the TLS working group.  I was asked to
review this issue by someone who was confused and hurt by the current
process and was asking for a less involved opinion.  Since I took the
trouble to review the document, to review a good chunk of the current
list discussion, I decided to share my opinions.  I understand that I'm
coming at this late.  There are both advantages and disadvantages to
this.

I will answer the questions, but I ask you to please focus more on my
analysis of the proposed change than my answers to the question.  I
don't think I have anything special to bring to the answers to the
questions other than the opinion of someone who is trying as hard as
they can to inform themselves.
I do think an outsider's evaluation of some of the assumptions and
implications of the change may help others make up their mind.


1) Do you support publication in its current form?

No.
I thought I was going to have to quibble about the question and say that
while I supported bringing the document back to the WG I wouldn't go so
far as to   say I didn't support publication.

However, reading the discussion, there are key statements related to the
scope of this document that based on current discussion don't seem to
have consensus now even though they mmay have had consensus in the past:

* The scope discussion in the introduction, particularly pointing out
  that this document is applicable to web browsers and SIP seems very
  much under debate in the current discussion.

* Section 8 states that using this extension in a TOFU manner would be a
  reasonable thing to do.  I think that absent a mechanism to limit the
  scope of pinning or to securly move away from this extension that
  claim is harmful to interoperability and ultimately security.

So, even if all we do is remove that text in the introduction and remove
the TOFU claim, I think a change is worth the cost.

2) Do you support denial-of-existence proofs and TTL for pinning?

Yes, I think this work would be valuable; here's why.

First I'd like to explain my understanding of the assumptions under
which this change is valuable.

You don't need this change if you have reliable client configuration.
Reliable client configuration  can come in an application where this extension is mandated.  That
is, you know all your code supports this extension and you know you're
being deployed with TLSA records signed up to a trust anchor that the
client supports.  So say you're only deployed on the public DNS in
signed zones.
Alternatively reliable client configuration could come in a list of
sites that are known to support this extension that is centrally
managed.

Without that reliable configuration, you won't be able to rely on this
extension to improve security for first contact.  That's true with or
without the proposed changes.

With the proposed changes you could implement TOFU semantics in a manner
that I and the proponents believe is operationally viable.
I think that will provide enhanced security under the following
assumptions:

* Clients talk to server more than once

* There is sufficient value in protecting second and follow-on sessions
  that mittigation is valuable even though we'll never protect the first
  session

* We trust the DNS root more than our X.509 PKI, or at least we gain
  enhanced security by validating against both

* Clients are willing to pin security information--namely that a given
  server uses this extension

* We're talking about an application where we cannot mandate use of this
  extension.  Remember that you need to mandate not only code support
  that people actually deploy only with signed dnssec zones and TLSA
  records before you
  can mandate the extension.  

I think those assumptions are common enough that it is worth fixing the
problem.

That said, I'd like to disagree with Victor on one point.  I think for
any change there is nontrivial work to be done to get it right and there
is a potential downside.  His cost analysis seems to imply that there's
no chance we'll make things worse with the change and that the only cost
is delay.  In my discussions, I quickly came across a number of issues
surrounding how the proposed changes would interact with private DNS
that were more complex than the person asking me to review implied.
Victor may have considered all those issues, but I think there is a cost
to the change.
I think it is worth paying, but I'd urge people to be a bit more
realistic about the potential cost of making a mistake or making it more
likely people will reduce interoperability by complicating the spec.


In conclusion, in ranked order, I prefer:

1) Working on Victor's changes

2) Removing the scope text and TOFU language

3) the current spec

4) no spec ever on this topic