Re: [dane] srv-09 comments

[Olafur Gudmundsson <[e-mail]>]

Matt, thank you for updating the draft based on last call comments. 
I have verified that you seem to have addressed all the comments that I noted. 
I like the new definitions you added they add clarity, thanks. 

But I noticed some “strange language” 
I section 3.1 you say in paragraph 2: 
For this specification to apply, the entire DNS RRset that is returned MUST be “secure” … 

Well the word entire is redundant if you are talking about single DNS RRset, 
BUT I think there are missing words i.e. the sentence should be:

For this specification to apply, the entire chain of  DNS RRset(s) that is returned MUST be “secure” …
 
If the second interpretation is right some minor word-smithing in paragraph 3 is also needed. 

Olafur as document Shepard 



> On Feb 16, 2015, at 4:48 PM, ⌘ Matt Miller <[e-mail]> wrote:
> 
> -----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 < [e-mail] <mailto:[e-mail]> >
> Cisco Systems, Inc.