On 8/19/14, 1:46 PM, Viktor Dukhovni wrote:
On Tue, Aug 19, 2014 at 01:01:46PM -0600, Peter Saint-Andre wrote:I think that's a more precise way to put it. Thus I propose the following revised text: Developers of application clients that depend on DANE-SRV often would like to prepare as quickly as possible for making a connection to the intended service, thus reducing the wait time for end users. To make this possible, a DNS library might perform the SRV queries, address queries, and TLSA queries in parallel (although the TLSA records are not usable if the address records are not secure, performing the TLSA queries in parallel is not harmful from a security perspective).Almost right, but note that the reason to "supress" TLSA RRs when address RRs are insecure is that TLSA RR lookups have been observed to generate spurious lookup errors in that case (which one might misconstrue to be an attack). If TLSA RRs are actually returned, they are most likely to be also "insecure" when the A records are insecure. In fact any other outcome would require a DLV configuration for say either _tcp.imap.example.com or _143._tcp.imap.example.com to re-establish trust below the "insecure" imap.example.com. Such configurations seem most unlikely. Also avoid "not usable", since that has special meaning in 6698. So the thing to say is something along the lines that when the A/AAAA results are "insecure" errors in TLSA lookup can be ignored, but otherwise, any errors in TLSA lookup should be considered equivalent to an active attack and cause the peer to be skipped.
How about this? (because the TLSA records can be ignored if the address records are not secure, performing the TLSA queries in parallel is not harmful from a security perspective). Peter _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
