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

From: Carl Wallace <[email-masked]>
Date: Mon, 13 Apr 2015 13:43:53 -0400

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.
- Should the "always use" in the third bullet be "MUST use"?
- 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).

In Section 4.2
- Should this reference RFC6698 section 2.1 or section 4? Section 4 seems
like a better target to me.
- 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.

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.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 13 Apr 2015 14:10:04 -0600

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 [email-masked] and [email-masked]
> back to any reply.
>
> On 4/13/15, 1:43 PM, "Carl Wallace" <[email-masked]> wrote:
>

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.

>> "non-DANE behavior" a la section 3.1 (but using the target server

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

>> like a better target to me.

That does seem better.

>> expiration checks need be performed.

Good point.

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

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 13 Apr 2015 14:17:08 -0600

On 4/13/15 2:10 PM, Peter Saint-Andre - &yet wrote:
> 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 < [email-masked] >
Cisco Systems, Inc.

>> My attempt at using the tools address for all document authors
>> failed, hence sending it directly. Please add [email-masked] and
>> [email-masked] back to any reply.
>> 
>>> 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:
> 
> 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).
> 
> "usable TLSA record *for a given connection endpoint*" and then
> have a bullet point at the end that says something like this:
> 
> (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.
> 
> 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
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 13 Apr 2015 14:21:34 -0600

>        endpoints that support TLS.

That should be s/endpoint/client/ in the penultimate line, i.e.,

         specification is for a client to securely discover connection
         endpoints that support TLS.

Peter

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

---

From: Carl Wallace <[email-masked]>
Date: Tue, 14 Apr 2015 08:58:52 -0400

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

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

>rules are contained in the body of the document. I'd prefer to keep it

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

<snip>
>    usage, and handling of certification paths).

Seems fine.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 14 Apr 2015 11:02:09 -0600

On 4/14/15 6:58 AM, Carl Wallace wrote:
> publish TLSA.

Ah, thanks for the clarification - I had not understood your concern.

> The new bullet seems a little out of sync with the security
> effort is made to accommodate mixed results.

As I see it, the purpose of this spec is to document how SRV and TLSA 
records interact with the intent that a client can securely discover at 
least one connection endpoint that supports TLS, and then establish a 
TLS-protected connection to the service domain at that endpoint.

Although that is the focus here, of course we don't want to degrade 
security in any way, so it's important to mention appropriate caveats.

> Maybe: In accordance with

Strictly speaking, a connection endpoint does not publish TLSA records, 
since that's the responsibility of the service domain.

     o  In accordance with [RFC2782] a service domain can advertise a
        variety of SRV records; some of these might map to connection
        endpoints that do not support TLS, and others might map to
        connection endpoints that support TLS but for which no TLSA
        records are available. This specification makes no special
        effort to accommodate such mixed results, since it is focused on
        enabling a client to securely discover at least one connection
        endpoint that supports TLS and then to establish a TLS-protected
        connection to the service domain.

Somehow that feels awfully wordy for an informational summary, but if it 
is accurate and causes no harm then we might as well include it...

Peter