On Thu, 5 Jun 2014, Viktor Dukhovni wrote:
The text can offer clients a choice.* Suppress oob public keys when it might well lead to authentication failure with servers rolling over keys and the client can handle full cert chains.
You'd have to carefully lay out which kind of failures, eg BOGUS versus missing "3 1 x" TLSA record.
* Otherwise, be prepared for authentication to fail, and retry without "oob".
It all seems local policy to me that does not need to be specified in the document.
Finally, the WG could decide that servers which publish U/S/M combinations in their TLSA RRset that contain only future or only past keys are "misconfigured", and that servers SHOULD NOT do that.
Why does the WG need to decide that? It's simply the case now? AFAIK, all thoughout DANE the policy is "grab the TLSA RRset - if you find no usable record, authentication fails". No one prevents you from writing a TLS client that first checks for TLSA "3 1 x" records usable for oob before starting a connection, and if you fail to find these records to start TLS without the oob extension. The problem I have is your desire to drop oob when finding a non-"3 1 x" record AND a "3 1 x" record, and argue that the latter record "might be incorrect and the server admin might not realise this when he updated the other type of TLSA record and therefor we should not allow mixed types ever".
In that case arguably the burden to get this right is on the server and the client can be let off the hook.
I don't see why this is ever NOT the case.
The rationale is that servers have no knowledge of which combinations of usages, selectors or matching types are unsupported, administratively disabled or otherwise unavailable/ignored by the client. The safest assumption is that each U/S/M combination might be the only one supported by a given client, and therefore should always match current (not future or past) server keys.
For any set of X TLSA records of various types, to rollover you add a matching X sets of TLSA records with the new pubkey/cert/chain record. T=1 one set of TLSA records in DNS. T=2 prepare new certs/pubkeys - add another whole st of TLSA records in DNS. T=3 wait for 2x TTL T=4 update the key/cert of the TLS server(s) - Take as long as you want T=5 all TLS servers only have the new cert/key, so remove the old set from T=1 from DNS Where in all of this MUST we say "should always match current (not future or past) server keys."
And thus client caution is approriate where there is little to lose by suppressing a minor TLS optimization.
That's your personal subjective value judgement. I would say, when the operator publishes a TLSA record to match SPKI, they are working hard to get rid of this legacy X.509 container disaster using a very important new TLS extension. Restricting the TLSA RRset or pro-actively dropping the oob extension based on a mixture of TLSA U/S/M records is undesirable, and your justification of "the admin might make an erorr" is an extremely weak reason for it. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
