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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Viktor,

Thanks for the speedy response! Just a couple of things ... everything else
you said, is fine with me.

On Mon, Aug 3, 2015 at 11:59 PM, Viktor Dukhovni <[e-mail]>
wrote:

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


Ack. I'm trying to understand if it's always a best practice.


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


Something like this (especially explaining the tradeoff, as you did) seems
helpful.


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

You could reasonably have asked if I was overreacting to the word
"appropriate", but since you didn't ... :-)


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


It was really helpful for me.

Maybe just saying "may modify the above requirements, if (a sentence or two
that points toward your elaboration)"?


>
> > 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've seen RFC 2119 language used in even stranger ways in published RFCs.
I'm not sure that's a good thing.


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


If you're not convinced that using RFC 2119 language in this way is the
right thing to do, you might say "need to X, because if they don't Y
happens". That might be more helpful than a SHOULD.

Does that help?

Spencer