Minutes interim-2018-tls-01: Fri 10:00
minutes-interim-2018-tls-01-201809141000-00

Viktor: Stated as DPRIVE-only mechanism as a way to do DANE through TLS channel
as an extension. Question: DPRIVE-only mechanism, or for existing (not
greenfield) applications (IMAP clients, browsers, XMPP). Incremental use case
is cause of disagreement due to security model Does protocol make sense if it’s
downgradeable?

Ekr: DANE serves two purposes: allow people without X509 certificates to assert
keys, and allow those with X509 certificates to restrict scope so that they’re
less exposed to compromise. Browsers and apps can’t tell difference between
network failure or active attack with respect to DNS delivery. Cannot hard fail
on DNSSEC failure, but could hard fail for clients which aren’t in possibly
nefarious network conditions. Initially started on the first use case (do not
have X509 certificates), and did not provide security against active attacker,
text was not clear on active attacker possibilities

Viktor: Seems to be large agreement about Internet edge and lack of DNSSEC
usage. With LetsEncrypt and free certificates, restrictive use case for DANE is
only what makes sense.

Barnes: Incremental deployment and downgrade attacks are open issues. Security
objective: provide same security properties as DNSSEC over the wire (on clean
network, without edge issues). Incremental deployment: certificate switching
based on CH is standard practice, so incremental deployment can be done by just
looking at the CH, and can start serving DANE compatible clients if they offer
the extension.

Ben: Clarifying question: two incremental deployment scenarios: (1) enable DANE
auth cert based on CH, or (2) get to a place where using DANE to restrict which
WebPKI CAs client use for site validation when still presenting a valid PKIX
cert and supplying DANE restrictions on top of it.

Barnes: If one can do incremental deployment, would there be interest in the
restrictive case?

Nico: Server operators want to tell clients how clients should authenticate the
server. Do not want to offer up two certificates at once. Share Viktor’s
opinion on motivation.

Paul: Goal was to have DANE PKI that is independent of WebPKI, using DNS as
source of material with full authentication (DNSSEC) and no failure mode or
downgrade attack. Browsers currently hard fail on self-signed certificates. Can
we not have another type of hard fail? DANE failures could be hard fail based
on client policy. Protocol should allow implementors to make hard fail
decision. Certificate switching could be another downgrade attack, and could be
another roadblock to making the DANE PKI from happening.

Viktor: Ekr’s comment about hard fail was for apparent DNS failures. At the
moment, Internet edge is not friendly to hard fail on DNS lookup failure.

Ekr: At present if we did DNSSEC resolution and received A record with bogus
signature, would ignore signature (soft fail). If we receive X509 certificate
(self signed, does not chain to root), fall back to dialogue for users to
override decision (hard fail in this context). Extra hard fail: server is
marked for HSTS, does not allow opportunity to override. Not viable for generic
clients to respond to DNSSEC failures by refusing to connect and forcing user
to override.

Viktor: Agree with Ekr.

Ben: (To Paul) Why is certificate selection a blocker to DANE PKI deployment?

Paul: Seems to delay things unnecessarily.

Barnes: (To Paul) Server operators using WebPKI and DANE PKI at same time is
blocker? How does deployment work if this not supported?

Paul: Natural way: one cert that can be used by both, and WebPKI step could be
removed later on.

Ekr: TLS servers for generic clients mostly have WebPKI-valid certificates. To
transition to DANE PKI, servers continue serving WebPKI certificate and (at
same time) post and TLSA record to the WebPKI cert. People do this for a while.
Server offers up TLSA record to clients that support it and eventually makes a
decision to stop offering the certificate to non-DANE clients.

Paul: TLS extension is mechanism for clients to get records.

Ekr: At some point client should not be getting the WebPKI cert, and to do so
one needs signal from client about its expectations. If client got TLSA record
OOB, then how do servers tell learn this? (SHA1 deprecation as example for how
to phase out technology.)

Viktor: Yes, if you want to gauge where one can turn off WebPKI, then “cert
switching” proposal makes sense. This does not seem to be the barrier.

Barnes: Incremental deployment is an issue, and Ekr is discussing how this done
in the modern Internet.

Ekr: (On Viktor) Wouldn’t do this because it doesn’t give you any value until
the switch is made (full deployment).

Viktor: No server operator would do this because they have no benefit in the
interim, until it’s fully deployed.

Ekr: This is point of disagreement. View incremental deployment as in the
certificate switching proposal.

Paul: Signalling could happen through another extension, doesn’t need to be the
TLS extension.

Barnes: Server must know which certificate it must offer up.

Nico: It would be the same certificate each time. Would like world where one
PKI, and not many. Not the goal of going towards a single aligned PKI.
Interested in what the server operator gets to say. Some may want to be on DANE
PKI, others will not. Extension might need to become mandatory. As transport
for TLSA, with extension support pinning, gets us to the place where clients do
this after asking for clients to do it. This means making it a requirement for
clients. Making value judgment as to what server operators want.

Viktor: When operator says that they want this to happen and get nothing for
years while adoption increases, they won’t do it.

Nico: That’s why pinning of extension support is essential. Allows on operator
to rely on this working. Private keys for any one name will be the same
regardless of client used extension or not. It will be the same certificate for
either PKI. Can rotate keys by updating TLSA records.

Viktor: Amounts to sort-of CAA record between you and verifier that says “don’t
accept any verifiers other than LetsEncrypt,” for example. (Restrictive case.)

Ben: End state is that you get LetsEncrypt, but you also have TLSA record that
points to this key.

Nico: Not making judgement about where we end up. Want to end up in a place
where operators can get this today if they want it.

Ben: Operators that do want to do DNS PKI are still getting LetsEncrypt
certificates?

Viktor: Maybe, maybe not. Most are issued through DV, so no more secure than
DNS today.

Nico: With mandatory support for clients, operators using LetsEncrypt and TLSA
can eventually stop using LetsEncrypt. They cannot do this before then.

Barnes: Highly unlikely for this extension to become mandatory. Need to really
focus on certificate switching case.

Paul: Does not expect extension to become mandatory, but DNSSEC will become
clear enough for path to application that this extension is not needed. TLSA
records are authoritative source. Extension is just conduit for TLSA records
due to last mile problems.

Ekr: (On deployment incentives) SNI started off slow with varying support, is
now supported by most, and servers eventually started to say that it’s required.

Viktor: SNI is a good example, though slightly misleading. Unclear if clients
will adopt in large swaths as with SNI. And downgrade is still a problem.

Barnes: Want to get to world where clients support this extension. To get
there, servers need an incentive to balance the pain of managing certificates.
Restrictive DANE is something that could provide server incentive. And if we
want restrictive DANE, then we need pinning. Correct?

Nico: Yes, pinning by eliminating downgrade, gives you value you need to make
this worthwhile tradeoff. Clients also start getting value by supporting this.
Goes from something that has 0 deployment to eventual avalanche (if worthwhile).

Viktor: Pin also renews itself upon reach visit to site.

Paul: Yes, restrictive DANE is the most important use case. Without it, we are
just shipping things that can fail.

Barnes: Value of pinning in restrictive DANE is that it creates incentive for
server operators to support this, and that gives clients incentives to support
this.

Viktor: End goal is the restrictive use case.

Barnes: Was it not the case that the end goal was to use different (non-Web)
PKIs?

Paul: Do not need to agree on end goals. Need to agree on options.

Barnes: One option was to only support assertive use case. Why does one need
restrictive use case then?

Paul: If you ever want to use DANE PKI that is independent of WebPKI then you
need the restrictive use case.

Barnes: Also want to say, “do not use the WebPKI”

Nico: TLSA is always assertive, each record tells you one way to authenticate
the server, and they are choices on the server side. One of them must work.

Ekr: One of the TLSA modes requires WebPKI validation.

Paul: Can pin on public key if you want.

Nico: There is no use case wherein TLSA says “any PKI will do”

Ekr: There is such a use case. You pin end-entity and require WebPKI validation.

(Lots of cross talk)

Ben: What if client signals to server that there is support for (and
willingness to do?) DNSSEC validation, and already have TLSA records or need to
get them? Does this change the situation with respect to what needs to be
pinned, if anything? Or what signal servers would need to send to the client?

Viktor: Do not understand Ben’s suggestion. Client is already sending a signal
via the extension. Does not signal that pin or DNSSEC is supported. Possible if
client could do pinning if client had working DNSSEC fallback, e.g., when
channel through server does not work. Can talk about how pinning can be made
less fragile.

Ben: Will write up idea and send to the list.

Viktor: One of tensions is whether we’re supporting viability of restrictive
use case, or whether that’s still getting pushback? Can we answer restrictive
use case question here?

Joe: Not clear if we’ll get consensus on restrictive vs non-restrictive use
case on the call. May need to frame question to the list and ask for consensus.

Nico: Care whether operators that want restrictive use can get it. The question
is whether or not we want this, but whether or not want let operators get
there. Do we want to give operators an extra degree of freedom?

Barnes: Some folks want restrictive usage for restrictive usage, and an
assertive-only document will not work. Others want restrictive usage as interim
incentive to get to assertive use case. If we can identify alternative
incentive story, then there may not be need for restrictive case.

Ekr: The problem is not what server operators want, but what the Internet
wants. Brings us back to pinning and anti-HPKP discussions. If server operators
could opt in for themselves only, it could work, but that’s not free.

Nico: Even for DPRIVE, extension is not sufficiently mandatory that it would
benefit from the pinning. Do not agree with comparison to HPKP. This pinning is
low cost and clients can NOT do it. Only pinning to the extension itself.
Servers can choose to not do it (via DoE). Can rotate at any time, stop,
restart, etc.

Viktor: Agree that HPKP is a problem. Reality of HPKP is losing keys and
shooting selves in the foot. One cannot shoot oneself in the foot with this
sort of pinning.

Nico: Implementation is also simple on the server-side.

Barnes: If DNSSEC blows up and records are unavailable, there is a self-brick
risk. One of pushback for DANE PKI is that parents can mess with children,
there’s no transparency, etc.

Paul: There are efforts underway to protect against self from parent in DNS
(power bind?). If DNS blows up on server, yes, things break. That is not
different from mistaken or expired certificate on server. These sorts of brick
age can be fixed immediately. There’s no long-term broken.

Viktor: If DNS is broken then A records can’t be trusted either.

Ekr: Do not know why HPKP was banned from Chrome. Question at hand is what is
the cost-benefit?

Paul: If you decide that you do not like this, do not publish TLSA records.

Ekr: Point of hijacking is a real concern whether TLSA records are pushed or
not.

Viktor: Hijacking works as follows: hijack DNS, publish TLSA records that match
their server, configure their servers to serve long-term pin, get users, get
them pinned, and then have them come back to you (target) to have them break.
This is a narrow but detectable risk. Do not agree that this risk is
substantial enough to not pin, as this is an edge case.

Ben: Two points: pinning semantics and what is being pinned are open question,
and point of HPKP reference is to make sure we do our due diligence and make
sure that we assess it from a similar security posture. Do not think we’ve done
great job in considering HPKP-like risks to the Internet ecosystem as a whole
in our analyses.

Nico: There is only one pinning proposal, and we’ve done the analysis. It’s
different from HPKP.

Ben: There is no consensus that this is the pinning mechanism.

Viktor: Contents of the pin are not agreed upon. Whether or not the pin is for
the extension is not a point of tension.

Nico: Server has cron job that generates, for each SNI name, generates TLSA
record lists and DNSSEC chains. Only three valid options, get valid chains,
valid DoE chains, or get served fail. TLS server implementation uses SNI to
choose the right TLSA record.

Ekr: Must generate valid response that contains valid response (record or DoE).

Nico: DNS always does this for you. DNS returns the truth. Monitor DNS and fix
things at any time things go wrong.

Viktor: SNI name comes from client DNS zone. If customer screws up, might not
be able to server their domain.

Nico: Important point is that if something break then something does not stay
broken for the duration of the pin.

Ekr: Important to be specific about what pin commits to: starts with extension
and ends with valid DNS. These are not difficult, but not free.

Viktor: Feel as though progress is being made.

Ekr: Agree on facts, but disagree on the importance. Write down summary of what
works and does not work, and send it to the list.

(Chairs to work on writeup of technical facts.)