On Wed, Jun 04, 2014 at 01:44:41PM +0000, Viktor Dukhovni wrote:
> If you are suggesting that the strategy I have in mind for "safe"
> TLSA RRset updates is be a mandate, we can discuss that. If indeed
> the server is obligated to avoid non product-set mixed states, then
> clients can always expect each C/U/M combination to contain at
> least one RR that matches the servers "active" chain.
Sorry, the C/U/M abbreviation (created in error) is likely opaque.
I meant:
U/S/M
* U = usage
* S = selector
* M = matching type.
instead while thinking "certificate usage" I typed C/U/M. It is
possible (with care) to ensure that server TLSA records always
contain at least one "active" record per U/S/M. We can recommend
appropriate record management strategies to server operators.
That way no matter which subset of U/S/M values a client either
supports or elects to use, authentication will succeed.
If use of such strategies becomes a *requirement* (failure to do
so is a "misconfiguration), then I'm open to relaxing the client
"oob" constraints from "SHOULD NOT" (under list of conditions) to
"may choose not to" (under list of conditions just in case the
server fails to handle state transitions properly). Clients that
decide to proceed with "oob" anyway (but are capable of handling
X.509 chains), should then retry without "oob" if authentication
fails.
If on the other hand servers are not required to enforce the above
requirement (each U/S/M contains an "active" record). Then (under
list of conditions where server's chain is mixed, ...) clients
capable of both "oob" and not "oob" have no reason to go out of
their way to shoot themselves in the foot with "oob" and needing
to fall back. The "oob" extension in that case is just a minor
optimization that is best skipped when potentially problematic.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
