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

[Carl Wallace <[e-mail]>]

On 4/13/15, 4:10 PM, "Peter Saint-Andre - &yet" <[e-mail]> wrote:
<snip>
>>> 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).

I think you are right a second bullet is better but if changing this
maybe: When DNSSEC-validated TLSA records are published for a particular
connection endpoint, clients always use TLS when connecting to that
connection endpoint even if the endpoint supports cleartext communication.

>
>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?

Mostly, though I was thinking of endpoints that supported TLS but did not
publish TLSA. The new bullet seems a little out of sync with the security
considerations w.r.t. the intent of the spec, which claims no special
effort is made to accommodate mixed results. Maybe: 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 or that
support TLS but do not publish TLSA records), this specification enables
clients to securely authenticate connection endpoints that support TLS and
publish TLSA records.

>
>>> - 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.

Right. That makes sense. I forgot that was introductory text.

<snip>
>
>>> 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).

Seems fine.