[ I hope the below is short enough...]
> On Nov 5, 2018, at 9:37 AM, Salz, Rich <rs...@akamai.com> wrote:
>
> Is it fair to describe the draft as enabling a trust model based on DNSSEC,
> rather than the default X.509 hierarchy and trust store which is implemented
> by default?
>
> Please try very hard to keep the answer brief.
The original (-07) draft only does the job for applications that
go all in on DANE and statically skip the WebPKI.
What we're trying to do is to make DANE meaningfully available
also to existing applications where the WebPKI still rules the
roost, and where clients can only determine which servers support
DANE "opportunistically", but for that to be useful, the signal
needs some downgrade resistance.
The ultimate goal is to be able to use DANE either instead of,
or in combination with the WebPKI. Which it is depends on the
DANE certificate usages that the application supports and server
publishes. We're not trying to kill the WebPKI, rather we want
the *option* to use DANE when client and server opt-in.
Finally, of course, the reason for the extension is last-mile
issues with DNSSEC in captive portals and behind DNS-challenged
home routers, plus a bit of latency concern (that may be overblown,
but still seems an issue for some).
--
Viktor.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
