[TLS] TLS interim meeting notes

[Paul Wouters <[e-mail]>]

My rough notes of the meeting. All mistakes are mine, please speak up to the list if I got something wrong

2018-10-14 TLS interim meeting

problem statement
viktor: authors seemed focus on dprive but not scoped as such. Scope in document is DANE PKI.
         dprive can make extension mandatory.
ekr: doing DANE as alternative to x509/webpki been around forever. been failing for long time
      two purposes of DANE: assert keys without X.509 and restrict webpki. DNSSEC unreliable
      for clients. from browser vendor, we need to be able to distinguish between bad network
      and attack. we cannot hard fail ever.
      ekr: mainly to not need CA based certs ("tax")
viktor: with acme, the really only use case is DANE restrictive use case
richard: 1) incremental deployment, 2) downgradability
         baseline: same properties as DNSSEC over a clean wire
         1) dont understand incremental deployment issue.
ben: two incremental scenarios: 1) enable the use of DANE.. seems richard 2) use case is not wanted?
nico: Its my (server)'s choice of cert not TLS client.
viktor: its another road block
paul: just like selfsigned cert or bad_ca is a hard fail, dane failure can be a hard fail
       protocol shoudl allow hardfail so implementors can make a choice
       re: richard: is a downgrade attack too and additional roadblock
ekr: let me clarify hard fail. if we do dnssec and get a malformed A record, we would ignore.
      bogus seldsigned cert, we fall back to dialog for user.
      extra hardfail if server hsts, we wont allow override.
      not viable for generic client to act on dnssec failures.
nico/viktor: an operator should have the choice to be on the webpki, dane or both.
              pinning of extension gets us the last mile problem solved.
viktor: can't tell operators with a downgrade attack they get no benefits for years.
nico: that's why the extension pinning is so important. To get immediate benefit for cost
nico: in real life, it will be the same key/cert whether it is webpki or dane.
viktor/nico: give operators choice, make no value judgement about webpki or dane
richard: you cannot expect this tls extension to become mandatory
paul: TLSA is the authoritatve source. the tls extension is a temporary solution to fix the last mile
ekr: SNI example.... coordinated actions in community. that is how things are done.
viktor: SNI doesnt cost. Deploying DANE has a cost. if the new signal is downgradable it makes no sense
         to pay the cost. You dont pay anything to use SNI.
richard:  if we want restrictive DANE, we need pinning.
paul: yes, it is the main use case in my opinion.

ben: strawman proposal:   what if client signals server 'i am willing to do dnssec, or surely doing dnssec
      and 'i already have records' or 'i need records'
viktor: can we decide the restrictive use case on this call?
ben: not sure if we can make further process on this call. we need consensus
nico: real question is, should we say "no one can get it". The question is not what we want.
       the question is what are we letting the operators do?
richard: some want restrictive usage for restrictive usage. some want additive usage.[ did not understand
          what richard said here]
ekr: Q is not what the server operators want. but what the internet wants. comes back to cost / benefit
       analyses of pinning. 
nico: cost of changing deployment is free. i can change it whenever i want.
viktor: HPKP is people shooting themselves in the foot, not really real attackers.
         Here [with extension pinning] you cannot shoot yourself in the foot. you can immediate fix anything
         [implies ekr's cost is not really there, other then some imaginary near zero risk cases]
richard: even in waterdown pinning, if my dnssec blows up there is breaking risk
paul: 
ekr: i think there was bricking but also hijacking with HPKP. user's at risk, should we give them the option?
viktor: there is no real longterm risk, just a very small narrow if-chain of events that could go wrong
ben: pinning semantics is an open question. HPKP lesson is about why it was unexpected and then pulled as
      failure, not the specific technical issues within that proposal.
nico: there is 1 pinning proposal and has 1 analyses. it is fundamentally different.
ben: there is no consensus on the approach
viktor: there is no concensus on whether we can have pinning  [?]
ekr: pinning also depends on being able to create the tls-dnssec-chain to get usable data for the extension
ekr: new failure mode is bad extension data 
nico: but you can fix instantly. there is no pinning time period of failure in the future
ekr: important to know commitment with pin. I dont say it is catastrophic
ekr: someone maybe ben can write up neutral description . then re-discuss in WG
nico: i wish we could agree that TLSA is always restrictive. would be nice to agree on that fact as well
nico: it would be nice to know the specific objections to pinning, like risk to the internet, or two bytes,
       or what it is.
ekr: I am happy to answer that. [didnt get what he said]
nico: would be good to talk about the pinning risk scenario and likeliness/impact
viktor: think we have more work to do as focus group do an interim before going back to the WG
ben: going to be more discussion. logistically, we have to see.
ekr: lets see. this was productive, lets see how it goes
ben: it is one big diff, can you break it up
viktor: it is 24 commits
ben: ok