>>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
Perhaps I worded poorly. Trying again. It is OK for some document -- esp if it is a BCP -- to say that doing certain things can prove problemantic. But even for a tls client which likes to try oob, and which only uses dane to verify oob, it is not unreasonable to try oob and if it fails try normal tls. Without any need for user clicking, et alia. That procedure should be rare; it SHOULD only occur when a destination is changing from supporting oob to not supporting it, and even then only if the dns got changed before the server's config. OTOH, multiple types of tlsa can exist for servers which support both oob and full cert clients. Such servers may want to specify type 0, 1 or 2 for the full cert clients and type 3 for the oob clients. I'm an example, in fact. My web server has a paid cert for compatibility reasons, and I publish a 111 for it. Since I'm wasting money on the cert, full-cert clients might as well pkix verify it. But since I'm fine with oob, once that becomes available for my sw I'd be happy to add a 311 to support it. I'm certain other sites will have similar objectives. Avoiding oob in that case makes oob less useful than it might be. Especially if oob-only clients show up. Sites like goog may have the same ideas even for their MXs. Because tlsa mis-configuration should be so rare, it also is OK for a client which finds itself in such a circumstance to abort completely. Oob-only clients will have to. Either way, some alert -- popup, email, syslog, whatever -- is good. But if the client prefers to retry w/o oob doing so generally should not require user intervention. The fact that it occurred is strong evidence that the site is transitioning away from oob. VD> Authentication unnecessarily failing is indeed a big deal. But this particular case should be most unusual. Most changeovers will follow the add-new-tlsa, change-server-config, remove-old-tlsa pattern. Telling clients never to try oob when multiple tlsas are present means that transitions *to* oob would break if the middle step is change-server-only-to-do-oob or add-oob-too. I have no objection to a document explaining to server admins what is likely to work and what is likely to fail. And how each potential failure is likely to present. And although it seems like miniscule should is enough when advising admins how best to deploy, I won't argue against SHOULD in such a document. But telling clients they cannot TRY, or even SHOULD NOT TRY, just because a mis-configuration is possible, is too much. Even if all of the tlsas *are* 31x, there is no guarantee any will match. That failure case is really no different than the no-ee-spki- matches failure case, except that clients which can do both oob and full could, in the latter case, fall back to full and try again. That also might fail. I should note that I only just considerred the idea of oob-only. I think that I've edited that concept into the above missive, but I'm way too tired to be sure. -JimC -- James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
