On 08/24/2018 04:56 PM, Paul Hoffman wrote: >> Figuring out what SNI to use using insecure DNS sort of negates any advantage >> TLS authentication offers. > I don't understand this at all. The SNI is the host in the URI template.
There remains the general problem with bootstrapping a "secure" channel without using another secure anchor. DHCP has the same problem - it's not validable (reportedly, I don't know the protocol well). You get a name (for SNI) and thus you can verify that you connect to that name (https/tls), but you can't distinguish whether you got a spoofed name in the first place, and I can't see a possible workaround for that. Both DHCP and this draft are essentially like not validating identity of the other side but otherwise using a "secure" transport. Well, I think many people consider such opportunistic security schemes to be noticeably better than cleartext. Still, personally I'd probably prefer to choose someone from a list of providers, as we might have quite a lot soon, and "I" might trust some of the names already, and the handshake will then verify that the name matches. I assume this draft is meant as yet another fallback when such user selection isn't suitable. (Well, I'd most prefer to run a per-SOHO or per-device validating resolver, in future maybe with TLS-forwarding somewhere else, but that doesn't belong to this thread, and it isn't suitable for most people anyway.) --Vladimir
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
