Hi from DNS land. >pinning, but i won't go too far into the weeds here. Just a quick >summary of my understanding: > > * The existence of a pin only requires that the service operator > maintain the ability to respond to this extension in the future -- it > doesn't require specific keys, or even the use of DANE itself. It is > not nearly as large a risk as HPKP's pins were. > > * Pinning fears are based on two scenarios: (a) footgun, where the > service operator makes a mistake, or (b) a malicious pin is set by an > adversary who has owned your domain. (a) is overwhelmingly more > common, and is what we should focus on. In the (a) scenario, the > admin has already deployed the extension, so there is no risk. The > (b) scenario only matters if a service cannot deploy the extension as > intended, which is more of a chicken/egg problem of deployment and > implementation. I don't think that's a huge risk but if we really > want to try to cover it, i think there are ways that we could > minimize it as well.
Something like "require DANE certs until time N" should be plenty. Remember that you can also unpin by publishing a signed NXDOMAIN or NODATA. Since you need to have DNSSEC working to get the pin in the first place, that doesn't seem unduly onerous. If your system goes totally kerflooie and your DNS was signed yesterday and for some reason you can't sign it today, you have a problem, but that doesn't sound like a very likely problem. It it does happen, it's as likely as not an attack in which case you'd want attempts to unpin to fail. R's, John _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
