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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
