-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/16/15 11:08 AM, Viktor Dukhovni wrote: > 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. >
I'll submit -10 presently. Thanks again, - -- - - m&m Matt Miller < [email protected] > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU4mWjAAoJEDWi+S0W7cO178sIAJO+FPG1S1IsU9Ubsfkojnyl z4wkU7JGolLJ4eZUY+YMndYWpYo2CpxIdyOWN/dSDzIAiVZmgcQk0/3Rf+Z2BUKw /EZXtpzXKLXhTK2qdM2Frb10UjUZ6pmuwZY6eVz00qPJrVqRJF+g9101YNS92gM5 npY1mBX9FWE2Kww9/HV98og6zKxUltlYGb4qhzpKWkLCQRXuWPLUHEKkJZulPpIU 22ECLP1RRp3cBdZwu+QjeKQZsfyj/fg56afVMEawOKdIKHYQXSWJ0tCkzkRq+mv6 6vwEOFnztHaQtFz7+DKOgHKpGpCuN3SfIQ3acmjxea4YbjEL57fbbSG3QYFvUYk= =XWQQ -----END PGP SIGNATURE----- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
