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

[Peter Saint-Andre - &yet <[e-mail]>]

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

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

-- 
Peter Saint-Andre
https://andyet.com/