Re: [dane] Spencer Dawkins' No Objection on draft-ietf-dane-ops-14: (with COMMENT)

[Viktor Dukhovni <[e-mail]>]

On Mon, Aug 03, 2015 at 09:06:56PM -0700, Spencer Dawkins wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for producing this document. I wish the IETF could produce more
> like it.

Wow, thanks!

> I was sort of surprised that the first two paragraphs of the introduction
> were about TLS and DTLS, and DANE wasn't mentioned until the third
> paragraph. Maybe move the third paragraph to the top of the section?

In the latest version, the first two paragraphs of the introduction are:

    The Transport Layer Security (TLS) [RFC5246] and Datagram
    Transport Layer Security (DTLS) [RFC6347] protocols provide
    secured TCP and UDP communication, respectively, over IP. In
    the context of this document, channel security is assumed to
    be provided by TLS or DTLS. By convention, "TLS" will be used
    throughout this document and, unless otherwise specified, the
    text applies equally well to DTLS over UDP.  Used without
    authentication, TLS provides protection only against eavesdropping
    through its use of encryption. With authentication, TLS also
    provides integrity protection and authentication, which protects
    the transport against man-in-the-middle (MiTM) attacks.

    The DNS-Based Authentication of Named Entities (DANE) specification
    ([RFC6698]) introduces the DNS "TLSA" resource record type
    ("TLSA" is not an acronym). TLSA records associate a certificate
    or a public key of an end-entity or a trusted issuing authority
    with the corresponding TLS transport endpoint. DANE relies on
    the DNS Security Extensions (DNSSEC, [RFC4033]). DANE TLSA
    records validated by DNSSEC can be used to augment or replace
    the use of trusted public Certification Authorities (CAs).

I think it is simple enough to switch these while keeping TLS
expanded on first use.  Will do, thanks for the suggestion.

> In section 1.1, in this text:
> 
>    TLSA parameters:  In [RFC6698] the TLSA record is defined to consist
>       of four fields.  The first three of these are numeric parameters
>       that specify the meaning of the data in the fourth and final
>       field.  This document refers to the first three fields as "TLSA
>       parameters", or sometimes just "parameters" when obvious from
>       context.
> 
> I was pretty lost until I got to section 2, where at least the first
> three fields were named - the fourth wasn't named until the last line of
> Section 2.1. Any chance all four fields could be named here? 

Yeah, we should avoid the needless suspense .

> In section 4, in this text:
> 
>    Protocol designers need to carefully consider which set of DANE
>    certificate usages to support.  Simultaneous support for all four
>    usages is NOT RECOMMENDED for DANE clients.  Protocol designers are
>    encouraged to specify use of either the PKIX-TA(0) and PKIX-EE(1)
>                                 ^^^^^^                ^^^
>    certificate usages, or the use of the DANE-TA(2) and DANE-EE(3)
>                        ^^                           ^^^
>    usages.  When all four usages are supported, an attacker capable of
>    compromising the integrity of DNSSEC needs only to replace server's
>    TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2)
>    records, effectively bypassing an added verification via public CAs.
>    In other words, when all four usages are supported, PKIX-TA(2) and
>    PKIX-EE(1) offer only illusory incremental security over DANE-TA(2)
>    and DANE-EE(3).

This paragraph is being rewritten as we speak to address earlier
comments about ensuring clarity of who these "protocol designers"
are, and being more clear about what we want them to do.

> I'm sure the third sentence is accurate, but it took me a while to parse
> the logical operators and figure out that the point was XOR ((A and B),
> (C and D)) (I think). I think the paragraph would actually be clearer
> with that sentence completely removed.

I am always of fixing bugs by deleting code.  Thanks.  I think that works.

> About six paragraphs down into section 5.1, I see
> 
>    TLSA records published for DANE servers should, as a best practice,
>    be "DANE-EE(3) SPKI(1) SHA2-256(1)" records.
>    
> Is this an unqualified "do this in all cases"? If so, it's buried really
> deeply. If not, it wasn't obvious to me what the qualifications might
> be.

This is a best-practice, not a mandate.  

At some sites, it makes sense to use "DANE-TA(2) Cert(0) SHA2-256(1)",
when many services have certificates from a common CA (trust-anchor),
and the domain operator prefers to decouple ceritificate rotation
from DNS updates.  In the "2 0 1" variant (also described), the
server TLSA RRsets are CNAMEs to the shared RRset that lists the
digests of trusted CA certificates.

The "3 1 1" case will be by far more numerous, but the "2 0 1" case
is also an equally valid alternative, for sites with lots of DANE
services (the downside is that virtual hosting becomes more complex).

Perhaps there's a better way to describe a situation where there's
a best-practice for 95% of users and a second best practice for
the remainin 5% (numbers made up, but the idea is right)?

> Just as a nit, in section 5.2.2, I see
> 
>    With DANE-TA(2), a complication arises when the TA certificate is
>    omitted from the server's certificate chain, perhaps on the basis of
>    Section 7.4.2 of [RFC5246]:
> 
>    The sender's certificate MUST come first in the list.  Each
>    following certificate MUST directly certify the one preceding
>    it.  Because certificate validation requires that root keys be
>    distributed independently, the self-signed certificate that
>    specifies the root certification authority MAY be omitted from
>    the chain, under the assumption that the remote end must
>    already possess it in order to validate it in any case.
>    
> Is that where the quote stops? I didn't check, but indenting the quote
> would help.

It was indented in the .html version produced by xml2rfc, but not
in the .txt.  Fixed.  Thanks.

> Thanks for including section 10.1.1, UDP and TCP Considerations.
> 
> In section 10.1.2,
> 
>    While TLSA records using a TLSA Selector of SPKI(1) and a TLSA
>    Matching Type of Full(0) (which publish the bare public keys without
>    the overhead of a containing X.509 certificate) are generally more
>    compact, these are also best avoided as when significantly larger
>                                         ^^^^^^^
>    than their digests.
>    
> The ^^^^ text wasn't parsing for me. "because they are/can be
> significantly larger"? But I'm guessing.

Thanks, the problem was already queued to be fixed in the final
version.  It now reads:

    While TLSA records using a TLSA Selector of SPKI(1) and a TLSA
    Matching Type of Full(0) (which publish the bare public keys
    without the overhead of a containing X.509 certificate) are
    generally more compact, these are also best avoided when
    significantly larger than their digests.

(For 256-bit EC keys, it is likely that the key size and the digest
size are close in size, and the full key is fine in that case).

> In section 10.3,
> 
>    If, on the other hand, the use of TLS is "opportunistic", then the
>    client SHOULD generally use the server via an unauthenticated TLS
>    connection, but if TLS encryption cannot be established, the client
>    MUST NOT use the server.  Standards for DANE specific to the
>    particular application protocol may modify the above requirements, as
>    appropriate.
>    
> I found myself wondering how you'd know modifying those requirements is
> appropriate. Is there any guidance you could give, or an example?

Hard to say what makes the most sense in some hypothetical
opportunistic application.  

For opportunistic applications a key consideration is whether we're
asking for more security than we can realistically expect (see
RFC7435).  If not, then the design is fine, if yes, then even in
the absense of active attacks clients run into problems with various
peers that do not interoperate "securely enough".  That's a problem,
because there are then strong incentives to just disable "OS" and
stick with cleartext.

So the bar needs to be set at a realistic level.  I'd expect that
requiring at least some form of (unauthenticated) TLS from sites
that publish TLSA RRs (even if unusable) is likely safe, but perhaps
that's too much to expect in some cases, or not worth the small
security gains.

Should some version of the above elaboration go in the text?

> In section 11,
> 
>    When the registrar is also the DNS operator for the domain, one needs
>    to consider whether the registrar will allow orderly migration of the
>    domain to another registrar or DNS operator in a way that will
>    maintain DNSSEC integrity.  TLSA Publishers SHOULD ensure their
>    registrar publishes a suitable domain transfer policy.
>    
> I'm thinking that's not an RFC 2119 SHOULD, but if it is, I wonder why
> it's not a MUST ...

Excellent observation.

Perhaps 2119 is indeed too strong here.  Failure to do that may
make it difficult for the domain owner to ever move the domain to
another registrar without breakage.  But there's no interoperability
issue while the domain stays put.  If we want to ensure that domains
can be moved without downtime (or downgrades to unsigned during
the move) then this is a MUST (on operational, rather than
interoperability grounds).  So not sure where to go with this.

> I have the same thoughts about this text in section 11,
>    
>    DNS Operators SHOULD use a registrar lock of their domains
>    to offer some protection against this possibility.
> 
> and this text, in the following paragraph.
> 
>    TLSA Publishers SHOULD ensure their
>    registrar publishes a suitable domain transfer policy.

These address a security issue, without a lock, another registrar
might claim the domain without authorization, and then replace the
DS RRset, and publish rogue keys.  This is again operational advice
with a security impact.  Whether 2119 is the right way to state
that advice, I am not sure.  Guidance from the IESG would be great.

-- 
	Viktor.