On Wed, Jul 18, 2018 at 08:41:59AM -0400, Shumon Huque wrote: > At yesterday's WG meeting, Sam Weiler suggested that the pinning > information could be conveyed via the DNS. That way you would not need new > holes/fields in the TLS extension. Paul said it doesn't work. But Willem > Toorop and I discussed it after the meeting, and think that it does.
I agree that it _could_ be done with a DNS RR. However, that has two negative effects: 1) it will bloat the extension's payload more than the two bytes we're asking for, 2) it complicates deployment / the operator's life. With a pin TTL in the extension the server operator can change it at any time without further ado -- it's just a config file setting. With a pin TTL in a DNS RR the server operator has to make a zone file update. That could be easy or not -- it varies. > This could also express a generic DANE pinning capability that is not tied > only to a TLS channel. That's more like the other flavors of pinning we've been told have rougher operations characteristics. It's certainly true that we could specify and implement such a thing, and that it would be useful for some applications. However, it wouldn't be as convenient as just the extension pinning in this case. For example, with pinning to the extension + DoE, a server could implement the extension asynchronously from deploying DANE. In fact, it could just be enabled by default, and always send DoE when you don't have DANE deployed. And then the moment you deploy DANE, presto, you're protected. And if you want to turn off pinning? Just edit the server's configuration file -- no need to go update the zone(s). We should always look to make deployment easier, and extension pinning does that more than a DANE pin DNS RR type would. Surely we want our protocols to be deployable. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
