Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

[Matt Miller <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2/11/14, 4:34 PM, Viktor Dukhovni wrote:
> On Tue, Feb 11, 2014 at 03:17:35PM -0700, Matt Miller wrote:
> 
>> Viktor (and DANE),
>> 
>> Peter and I believe this revision addresses all of your
>> feedback. Please let us if anything is missing or inconsistent.
>> 
>> Also added an SRV example for the expected records, updated 
>> referenced, and author information.
> 
> The draft seems to use "indeterminate" in the sense of RFC 4033, 
> where-in there is no trust-anchor for the domain or any of its 
> ancestors.  Unfortunately, there is a conflicting definition in RFC
> 4035, which I am told is more appropriate in this context.
> 
> All 4035-style "indeterminate" results (and "bogus" results) are 
> essentially lookup errors and must treated as such. See section 2.1
> of the SMTP draft.  As for 4033-style indeterminacy it is indeed to
> be treated as equivalent to "insecure".
> 
> For DANE-EE(3) CU records to have meaningful semantics for the 
> publisher.  For example for a publisher to use the same
> certificate for many SRV hosts or without worrying about using a
> matching name, the use of non-use of name checks must be specified
> precisely.
> 
> Therefore I would suggest that the "MAY be ignored" in the second 
> paragraph of section 5, should be changed to "MUST be ignored". 
> Otherwise, the published TLSA records have unknown semantics.
> 
> When the service domain is the head of a CNAME chain, with the SRV 
> record obtained after indirection via at least one CNAME RR, the 
> SMTP and ops drafts specify that name checks must include both the 
> service domain and its full CNAME expansion (in addition to any SRV
> target host name).
> 
> The SMTP draft also specifies that servers MUST not refuse to 
> complete the TLS handshake when no certificate matching the SNI 
> name is present.  Rather they must then present the default 
> certificate, because clients may be willing to match other names in
> addition to that sent in the SNI extension.
> 
> - In the first paragraph of 4.2, change "as describes" to "as
> described".
> 
> - In the third paragraph of 5. change "the the 'to' address" to 
> eliminate the duplicate "the".
> 

Thank you for the feedback, Viktor.  These comments make sense to me.
We'll try to get an update out before the cutoff to address them.


- -- 
- - m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS+7ATAAoJEDWi+S0W7cO1ZMIH/3BGTSq6xROIU3VODM0+JHuj
Ygl7KsMYk2N9SA/LAE6Bf5RhxAYsGusvduVY5Xgh01hAmbGEJDDJBaM1zOtFaFs4
yZb3HVBr9bN9618i811+kIGEnP3noYKc2eo/np5lw3jay/18bPHbWfGICJW97nGx
wmoQnUJp1LcUwHOAk4q6pIAbnvwTTXyAiczo4WMNYjWOPbGm2tIU4CWWZTVWEZWi
qEr0nWiiD9Mzmz/d9qcEV/bs8T9SdJiN1LXnSv/DhQnE2MjRAa8XC/KNm93zyxSW
M58pDT16vyGxA6dZQPC7/7flBuBX/oDNbGgbfW0dXnLaYGLm9vaC5vu3FCYXXBw=
=geO4
-----END PGP SIGNATURE-----