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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
