-----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 < mamil...@cisco.com > 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----- _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
