On Mon, Feb 16, 2015 at 10:35:44AM -0700, ? Matt Miller wrote:
> Thanks for the feedback! More inline ...
>
> > Section 3.4 (Impact on TLA Usage) second bullet:
> >
> > Revert change from -08 to -09. The -08 language:
> > [...]
>
> The original language did not account for the lack of records, but I
> can see how this is too permissive. Perhaps the following is more
> acceptable (replacing the last two bullets in dane-srv-09)?
>
> o If the TLSA response is "bogus" or "indeterminate" (or the lookup
> fails for reasons other than no records), then the client MUST
> NOT connect to the target server (the client can still use other
> SRV targets).
>
> o If the TLSA response is "insecure" (or no TLSA records exist),
> then the client SHALL proceed as if the target server had no TLSA
> records. It MAY connect to the target server with or without
> TLS, subject to the policies of the application protocol or
> client implementation.
Much better and basically correct, provided that it is clear that
"indeterminate" is the 4035 (not 4033) definition, and the phrase
"fails for reasons other than no records" is sufficiently clear to
the document's audience. It is a somewhat informal phrase...
In the SMTP draft ([1] below my signature) "no records" (be it
NOERROR with ancount==0 or NXDOMAIN) is defined as a non-error (a
successful empty result). Your taxonomy is different, but my guess
is that the text is good enough.
[ Is denial of existence of a success or a failure? How many
angels can dance on the head of a pin? ... ]
----
Question to the WG at large:
Anyone see any room for confusion about the meaning of the
proposed text?
----
> The parenthetical is meant to account for the lack of SRV records, but
> I can see how that might be too permissive. Is the following more
> acceptable?
>
> If the SRV lookup fails because the RRset is "bogus" (or the lookup
> fails for reasons other than no records), the client MUST abort its
> attempt to connect to the desired service. If the lookup result is
> "insecure" (or no SRV records exist), this protocol does not apply
> and the client SHOULD fall back to its non-DNSSEC, non-DANE (and
> possibly non-SRV) behavior.
Thanks. Looks fine, provided the "fails for reasons other than no
records" bit is clear enough to the world at large.
--
Viktor.
[1] SMTP draft section 2.1.1 (middle of page 10):
There is an important non-failure condition we need to highlight in
addition to the obvious case of the DNS client obtaining a non-empty
"secure" or "insecure" RRset of the requested type. Namely, it is
not an error when either "secure" or "insecure" non-existence is
determined for the requested data. When a DNSSEC response with a
validation status that is either "secure" or "insecure" reports
either no records of the requested type or non-existence of the query
domain, the response is not a DNS error condition. The DNS client
has not been left without an answer; it has learned that records of
the requested type do not exist.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
