Re: [secdir] FW: secdir review of draft-ietf-dane-srv-12

[⌘ Matt Miller <[e-mail]>]

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

On 4/13/15 2:10 PM, Peter Saint-Andre - &yet wrote:
> Hi Carl,
> 
> Thanks for your review and sorry about the trouble with the email 
> aliases. (Please note that I have not checked any of the proposed
> text with my co-authors, so this is all provisional.)
> 

Thanks for the review, Carl.

I agree with my co-author's response and proposed changes.


- -- 
- - m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.

> On 4/13/15 11:46 AM, Carl Wallace wrote:
>> My attempt at using the tools address for all document authors
>> failed, hence sending it directly. Please add [e-mail] and
>> [e-mail] back to any reply.
>> 
>> On 4/13/15, 1:43 PM, "Carl Wallace" <[e-mail]>
>> wrote:
>> 
>>> I have reviewed this document as part of the security
>>> directorate's ongoing effort to review all IETF documents being
>>> processed by the IESG. These comments were written primarily
>>> for the benefit of the security area directors. Document
>>> editors and WG chairs should treat these comments just like any
>>> other last call comments.
>>> 
>>> The document is basically ready. A few minor nits are below.
>>> The primary comment is that there are a few instances where
>>> abbreviated certificate checks are cited and potentially mask a
>>> need to do full certification path validation.
>>> 
>>> Therefore this document provides guidelines that enable
>>> protocols that rely on SRV lookups to locate and use TLSA
>>> records.
>>> 
>>> In section 1 - May be worth adding a note to the third bullet
>>> to clarify that multiple target endpoints may be defined for a
>>> given service domain, including a mix of endpoints that have
>>> and do not have TLSA records.
> 
> IMHO that's implicit, but maybe it would be clearer if we say
> something like this:
> 
> OLD o  When DNSSEC-validated TLSA records are published for a
> particular connection endpoint, clients always use TLS when
> connecting (even if the connection endpoint supports cleartext
> communication).
> 
> NEW o  When DNSSEC-validated TLSA records are published for a
> particular connection endpoint, clients always use TLS when
> connecting (even if the connection endpoint supports cleartext
> communication or some SRV records for the service domain map to
> connection endpoints that do not support TLS).
> 
> Is that what you had in mind? Do you feel it's helpful? I'm not so
> sure, myself. Instead, I wonder if the point would be better
> handled by adding another bullet point, such as:
> 
> o  Although in accordance with [RFC2782] a service domain can 
> advertise a number of SRV records (some of which might map to 
> connection endpoints that do not support TLS), the intent of this 
> specification is for an endpoint to securely discover connection 
> endpoints that support TLS.
> 
> Does that capture your suggestion?
> 
>>> - Should the "always use" in the third bullet be "MUST use"?
> 
> There is no normative text in the introduction. All of the
> normative rules are contained in the body of the document. I'd
> prefer to keep it that way.
> 
>>> - May be worth clarifying in the fifth bullet that no usable
>>> TLSA records for one target endpoint does not mean there are no
>>> usable TLSA records for another target endpoint. The security
>>> considerations address this point and the point in the first
>>> bullet above, but it seems worth reenforcing in the body as
>>> well.
>>> 
>>> - Bullet 5 should reference RFC5280 alongside RFC6125 and/or
>>> reference "non-DANE behavior" a la section 3.1 (but using the
>>> target server hostname).
> 
> Probably all of the bullet points in the introduction need to say 
> "usable TLSA record *for a given connection endpoint*" and then
> have a bullet point at the end that says something like this:
> 
> o  If there are no usable TLSA records for any connection endpoint 
> (and thus the client cannot securely discover a connection endpoint
> that supports TLS), the client's behavior is a matter for the
> application protocol or client implementation; this might involve a
> fallback to non-DANE behavior using the public key infrastructure
> [RFC5280].
> 
>>> In Section 4.2 - Should this reference RFC6698 section 2.1 or
>>> section 4? Section 4 seems like a better target to me.
> 
> That does seem better.
> 
>>> - Replace reference to "expiration checks from RFC5280" with
>>> "validation checks from RFC5280" unless you mean for some forms
>>> of 5280 checks to be honored here. Current wording could create
>>> a misimpression that only expiration checks need be performed.
> 
> Good point.
> 
>>> In section 10.2 - In the last sentence, clients must also
>>> validate the certificate back to the designated trust anchor,
>>> not just check the reference identifiers.
> 
> In RFC 6125 we had this paragraph:
> 
> This document does not supersede the rules for certificate
> issuance or validation provided in [PKIX].  Therefore, [PKIX] is
> authoritative on any point that might also be discussed in this
> document. Furthermore, [PKIX] also governs any certificate-related
> topic on which this document is silent, including but not limited
> to certificate syntax, certificate extensions such as name
> constraints and extended key usage, and handling of certification
> paths.
> 
> Even though there's no reason why anyone should expect this
> document to override RFC 5280 (and Section 10.2 is about matching
> of subject names only), it can't hurt to reinforce the point...
> 
> OLD Otherwise, while DNSSEC provides a secure binding between the
> server name and the TLSA record, and the TLSA record provides a
> binding to a certificate, this latter step can be indirect via a
> chain of certificates.  For example, a Certificate Usage "PKIX-TA"
> TLSA record only authenticates the CA that issued the certificate,
> and third parties can obtain certificates from the same CA.
> Therefore, clients need to check whether the server's certificate
> matches one of the expected reference identifiers to ensure that
> the certificate was issued by the CA to the server the client
> expects.
> 
> NEW Otherwise, while DNSSEC provides a secure binding between the
> server name and the TLSA record, and the TLSA record provides a
> binding to a certificate, this latter step can be indirect via a
> chain of certificates.  For example, a Certificate Usage "PKIX-TA"
> TLSA record only authenticates the CA that issued the certificate,
> and third parties can obtain certificates from the same CA.
> Therefore, clients need to check whether the server's certificate
> matches one of the expected reference identifiers to ensure that
> the certificate was issued by the CA to the server the client
> expects (naturally, this is in addition to standard
> certificate-related checks as specified in [RFC5280], including but
> not limited to certificate syntax, certificate extensions such as
> name constraints and extended key usage, and handling of
> certification paths).
> 
> Peter
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVLCREAAoJEDWi+S0W7cO13tAH/25IN+jxGgB4FaxKYAiXlKfL
ZwQFRz5/NV8MlW5ZByIkj0baoy9QbfJQxobUe9OR+kUT+qt9/x4v2Zmhlpz+xpKx
xiOnh8dPJGa2112Ljnyc2MlbKdB6cBMYY85dvwtaD+YYtgDK2nNFy38hrebkLu8H
kn6prwxxci8+chIo6fE5hF0c0KoEJ7Q8zCGZqwKbr6eAvgoqxfu9Ey2Wzki0jBCO
Lq5A8ltRLyl0aUVNtBY3l+M1MSkDJ6RK35xqeYPNNamLz1XUN/A4uCpRRxzjc2Is
+q+h9jr8UZPw6rX+IuoospP3zoOQoLBb0b26Pbtmgpkp66jnW4wPWKcNmr+AWLA=
=SmS2
-----END PGP SIGNATURE-----