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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 03 Aug 2015 21:06:56 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-dane-ops-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dane-ops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for producing this document. I wish the IETF could produce more
like it.

I had a bunch of editorial comments and questions. I see how nuanced the
recommendations are, so I might just lack the background to understand
some of the material, but I wanted to pass them along.

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

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

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.

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.

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.

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?

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

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 4 Aug 2015 04:59:52 +0000

Wow, thanks!

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

> Section 2.1. Any chance all four fields could be named here? 

Yeah, we should avoid the needless suspense .

>    encouraged to specify use of either the PKIX-TA(0) and PKIX-EE(1)

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.

> with that sentence completely removed.

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

> deeply. If not, it wasn't obvious to me what the qualifications might

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

> Is that where the quote stops? I didn't check, but indenting the quote

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

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

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

> I'm thinking that's not an RFC 2119 SHOULD, but if it is, I wonder why

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.

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 4 Aug 2015 00:50:13 -0500

Hi, Viktor,

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

> This is a best-practice, not a mandate.

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

> the remainin 5% (numbers made up, but the idea is right)?

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

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

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

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

> 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