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