Subject: [secdir] SecDir Review of draft-ietf-dane-ops-12

From: Tina TSOU <[email-masked]>
Date: Fri, 10 Jul 2015 03:42:06 +0000

Dear all,  

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 that arrive in timely manner, and not significantly belated.

I've found this document well-written. I believe it is ready for publication modulo some small issues that can hopefully be addressed prior to publication:

**** Technical *****

* Meta: I would have liked to find (if anything, in an appendix) the rationale for he changes being proposed by this document. Since the changes are said to originate on operational experience, I think that codifying the lessons (problems found, and a rationale for the workarounds). There seems to be a bit of this throughout the document, but not for most of the changes proposed.

* Section 4.8, page 8:
> Therefore, when a TLS client
>    authenticates the TLS server via a TLSA record with usage DANE-EE(3),
>    CT checks SHOULD NOT be performed.

What are the valid reasons for performing th CT checks? If there are not any, why not make this requirement a "MUST NOT" instead?

* Section 5.1, page 10:
> Servers SHOULD NOT rely on
>    "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
>    data for raw public keys.

Same here.

* Section 7, page 17:
>    Though CNAMEs are illegal on the right hand side of most indirection
>    records, such as MX and SRV records, they are supported by some
>    implementations.  For example, if the MX or SRV host is a CNAME
>    alias, some implementations may "chase" the CNAME.  If they do, they
>    SHOULD use the target hostname as the preferred TLSA base domain as
>    described above (and if the TLSA records are found there, use the
>    CNAME expanded domain also in SNI and certificate name checks).

If CNAMES on the right hand side of most indirection records are illegal, why trying to process them in the first place?

* Section 9, page 21:
> This order SHOULD be configurable by the MTA
>    administrator. 

Please expand "MTA". Also, why make the explanation mail-specific?

* Section 13, page 26:
>    The signature validity period for TLSA records should also not be too
>    long.  Signed DNSSEC records can be replayed by an MiTM attacker
>    provided the signatures have not yet expired. 

Please expand "MiTM".

**** Nits *****

Section 1.1, Page 4:
>       difficult to host multiple Customer Domains at the same IP-
>       addressed based TLS service endpoint (i.e., "secure virtual
>       hosting").

s/addressed based/address-based/

Section 4.2, page 8:
> Publication of the server
>    certificate or public key (digest) in a TLSA record in a DNSSEC
>    signed zone by the domain owner assures the TLS client that the
>    certificate is not an unauthorized certificate issued by a rogue CA
>    without the domain owner's consent.

Avoiding the double-negation improves clarity... i.e., please change to "...is an authorized certificate issued by a rogue CA
    without the domain owner's consent"

* Section 5.1, page 9:

>    With DANE-EE(3) servers that know all the connecting clients are
>    making use of DANE, they need not employ SNI

I'm having trouble parsing this sentence... could you please take a look and tweak it if necessary?

Thank you,
Tina

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Jul 2015 00:40:39 -0400

Thanks for the review, Tina.

Just reponding to one point:

Section 4.2, page 8:
> Avoiding the double-negation improves clarity... i.e., please change to
> "...is an authorized certificate issued by a rogue CA

You're right that it's best to avoid double negatives, but this actually
isn't one, and your suggestion changes the meaning completely.  Using
parentheses to show the word groupings, this is not saying that "the
certificate is (not an unauthorized certificate) issued by a rogue CA".
  It's saying that "the certificate is not (an unauthorized certificate
issued by a rogue CA)".  And this really is the best way to say that.  I
can't think of a way to reword it that isn't clunky and awkward.

Barry

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jul 2015 05:05:08 +0000

On Fri, Jul 10, 2015 at 03:42:06AM +0000, Tina TSOU 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 that arrive in timely manner, and not
> significantly belated.

Note that -13 has been published in the mean time and addresses at least
one of the concerns:

If it reasonable to ask you to glance over the diff from -12 to
-13 to see whether that introduces new issues or resolves any of
the ones you listed?

> Please expand "MTA". Also, why make the explanation mail-specific?

This text was modified in -13 to not mention MTAs.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 16:43:49 +0000

> * Meta: I would have liked to find (if anything, in an appendix) the
> rationale for he changes being proposed by this document. Since the changes
> are said to originate on operational experience, I think that codifying
> the lessons (problems found, and a rationale for the workarounds). There
> seems to be a bit of this throughout the document, but not for most of
> the changes proposed.

I'll reread the draft and see where additional rationale text might
usefully be added.  Specific pointers to such places, if anyone
has any in mind, would be great.

> What are the valid reasons for performing th CT checks? If there are not
> any, why not make this requirement a "MUST NOT" instead?

CT checks are designed to help keep public CAs honest (detect
surreptitiously misissued certificates).  With DANE-EE(3), no public
CA is involved, so CT (for the X.509 WebPKI) is logically out of
scope.  

If there is some day a CT for DNSSEC (or just DANE records validated
via DNSSEC), then this new CT might be applicable to keep registries
from signing rogue DS RRs, rogue evidence of non-existence of DS
RRs or rogue absense of delegation of a domain.  The present the
experimental CT does not apply to DNSSEC.  Also see changes in
the CT language in -13.

> > data for raw public keys.

I am open to MUST NOT, if that's better.  

Note that the impact of such inadvisable reliance, is that some
clients capable of using raw public keys (but also capable of
handling certificate chains) might choose to not do so.  And other
clients, that support only raw public keys, might go the extra mile
and support extracing the public key from a "3 0 0" record, assuming
they can parse X.509 certificates (part of the rationale for RPK
is to allow clients to shed such code).

So using "3 0 0" reduces opportunities to use RPK, and might fail
to interoperate with RPK-only DANE clients that don't go the extra
mile to support "3 0 0" (e.g. they may lack code to parse X.509
certificates).  Is that enough reason to say "MUST NOT rely"?

Is 2119 language appropriate here, we're not telling servers to
not publish "3 0 0", rather we're telling them that if they do,
they can't (must not) expect RPK to work.  Is "MUST NOT rely"
or "SHOULD NOT rely" a suitable means to say that, or should
this be downcased to non-normative english text?

> If CNAMES on the right hand side of most indirection records are illegal,
> why trying to process them in the first place?

Because this "illegal" configuration is both widely supported, and
actually practiced, sometimes by accident.  There are a lot of
domains with boiler-plate records configured by naive registrars
or users along the lines of:

	example.com.	IN A 192.0.2.1
	example.com.	IN MX 0 mail.example.com.
	; Note, no explicit mail.example.com RRsets
	*.example.com   IN CNAME example.com.

What this amounts to is that that the MX host for example.com is
mail.example.com which is in turn a CNAME right back to example.com.
Most MTAs seem to support this, RFCs notwithstanding.

So the draft explains what to do when such records are supported.
(A concession to the fact that MX hosts that are CNAMES are illegal
in theory, but not in practice).

> Please expand "MTA". Also, why make the explanation mail-specific?

Fixed in -13.

> >    provided the signatures have not yet expired. 

This was done in the introduction, but I notice a case difference
(MiTM vs MITM).  This should probably be made consistent in the
final version.  Queued for -14.

> s/addressed based/address-based/

Thanks, queued for -14.

> I'm having trouble parsing this sentence... could you please take a look and tweak it if necessary?

This was changed in -13:

   If a server uses just DANE-EE(3) TLSA records, and all its clients
   are DANE clients, the server need not employ SNI (i.e., they may
   ignore the client's SNI message) even when the server is known via
   multiple domain names that would otherwise require separate
   certificates.

I notice a singular/plural mismatch above, so in -14 I've queued-up

    s/they may/it may/.

Is the final result better?

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Jul 2015 22:54:07 -0400 (EDT)

>> any, why not make this requirement a "MUST NOT" instead?

CT auditors log EE-certs. Checking the CT logs also provides a way to
signal rogue EE-certs to the original webserver via a gossip/client
protocol. So I would not say Usage 3 should never check the CT logs.

> surreptitiously misissued certificates).

It's a litte more than just that:

    Certificate transparency aims to mitigate the problem of misissued
    certificates by providing publicly auditable, append-only, untrusted
    logs of all issued certificates.  The logs are publicly auditable so
    that it is possible for anyone to verify the correctness of each log
    and to monitor when new certificates are added to it.

>  With DANE-EE(3), no public

I don't think that whether or not public/private CA's are in used in
the TLSA record matters. A client that wants to confirm an EE-cert
via DNSSEC _and_ CT should be able to do so.

> is to allow clients to shed such code).

You keep trying to force different policies for raw public keys versus
(possibly throw away) x509 container based public keys. Because we know
software will only upgrade over a very long slow time, we know there
is going to be a substantial amount of time when "basically" raw keys
will go into a throw-away x509 container. Therefor, as I said before,
it is not wise to differentiate between the two. An EE-cert could be
a raw public key in disguise purely for compatibility reasons.

> this be downcased to non-normative english text?

No, I think you should not try to dictate the local policy behaviour.

>   multiple domain names that would otherwise require separate

I am confused. If DANE is only talking about how to verify a certain
certificate received over TLS, I do not think this document should
modify the TLS protocol with respect to SNI. It's out of scope.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Jul 2015 03:29:50 +0000

> protocol. So I would not say Usage 3 should never check the CT logs.

DANE-EE(3) certs are often self-signed, and there's no way to
control the "spam" problem on the CT logs with DANE-EE(3).
Furthermore such a certificate is only ever "rogue" if DNSSEC is
compromised to publish rogue TLSA RRs.  So the "CA" we're keeping
honest is the zone signing the TLSA RRset.  I don't believe we have
a CT specification for that yet.

>    and to monitor when new certificates are added to it.

Well, with DANE-EE(3) there is no X.509 trusted issuer to keep
honest.  With "3 1 1" an attacker can replace anything in the
certificate other than the public key, giving an astronomical number
of potential certificates to that match the TLSA RRset and might
be logged.  It makes no sense to log the "certificate" it is just
excess baggage.  The TLSA RRset, with DS/DNSKEY/RRSIG records all
the way back to the root ZONE make a lot more sense here, but there
is no CT spec for that I am aware of.

> via DNSSEC _and_ CT should be able to do so.

Perhaps if it were possible, but I'm afraid it is not.  From the
CT FAQ:

    Each CT log will have the power to choose which CAs it accepts
    certificates from. This could lead to a situation where a Root
    Certificate is trusted by one or more browsers, but is not
    permitted to submit newly issued certs to any of the trusted
    CT logs. How can we ensure that this sort of situation doesn't
    happen?

    We recommend that all logs accept a liberal list of CAs including
    at least the Apple, Microsoft and Opera roots. The CA check is
    for anti-spam and attribution only, so we do not foresee this
    becoming a problem in practice.

Thus CT logs will not accept self-signed, domain-issued, ...
certificates.  Since CT is just keeping the public CAs honest, and
DANE-EE(3) or DANE-TA(2) with a private CA do not use public CAs,
CT simply does not apply.

> No, I think you should not try to dictate the local policy behaviour.

You're misreading the text.  It is warning server operators that
"3 0 0" is less suitable for serving RPK clients (if that's what
the server wants) than "3 1 X" is.  This is true, because clients
that want to deal with just keys would have to support extracing
those from a "3 0 0" RRset, where-as with "3 1 X" the key or its
digest is right there.  Thus no local policy is dictated, rather
server operators are advised to be conservative in what they send.

> modify the TLS protocol with respect to SNI. It's out of scope.

You're confused.  The server is free to ignore the client's SNI
extension when it has a single certificate that works for all hosted
domains, because clients authenticate the server via the certificate
or key digest, and don't care about what name is in the certificate.
We're not modifying TLS, we're explaining that the server is free
to ignore the client's SNI extension.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Jul 2015 23:37:07 -0400 (EDT)

> control the "spam" problem on the CT logs with DANE-EE(3).

You don't know what audit logs will use for policies. Perhaps some
audit logs will be dedicated to only self-signed certs. I do not
think the dane document should dictate CT behaviour.

> compromised to publish rogue TLSA RRs.

Not if they use a CT log for prepublishing somehow. Although that is
unlikely to happen with SCT's without a CA, I still think you should
not make those decisions on this document.

> Thus CT logs will not accept self-signed, domain-issued, ...

The CT FAQ is not an IETF document.

> "3 0 0" is less suitable for serving RPK clients (if that's what

We disagree on the concept of "RPK" clients.

> to ignore the client's SNI extension.

How is that not modifying TLS server behaviour?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Jul 2015 04:00:59 +0000

> think the dane document should dictate CT behaviour.

The problem is that the CT documents are otherwise liable to dictate
DANE behaviour.  For example, require SCTs in DANE-EE validated
certs.  That would be unfortunate.  This document notes that the
present experimental CT in RFC 6962 is inapplicable to DANE.

CT logs that record leaf certificates would be essentially useless,
A rogue TLSA RRset with a "3 1 1" binding will work regardless of
the certificate content, just based on the public key.  A misissued
TLSA RRset will bind a certificate that contains no information as
to which domain was compromised.  Here's a certificate with an
empty subject and issuer name, what will the CT log make of that?

-----BEGIN CERTIFICATE-----
MIIBRjCB7aADAgECAgkAleIk6aMkXRwwCgYIKoZIzj0EAwIwADAeFw0xNTA3MTMw
MzUwNTlaFw0xNTA4MTIwMzUwNTlaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AAR50eOHUyMeHOMJNZTIXuj4QBJRbQrOLbYIftmZwzatO3/rG5BRyuUIfTQnzAq5
3K7A1pfq4hfseiOfT6prKKIVo1AwTjAdBgNVHQ4EFgQU7GD7zL/aLrBUaQIIKksc
cc6or+0wHwYDVR0jBBgwFoAU7GD7zL/aLrBUaQIIKksccc6or+0wDAYDVR0TBAUw
AwEB/zAKBggqhkjOPQQDAgNIADBFAiBr51OuJXf8N4Z79rStIXCIuYm6drChz39G
RBWvumsuhgIhANoW5K3bSqIFpIp2aXzH2PiiSgxnC3T9Mp5O70tXGS4L
-----END CERTIFICATE-----

And yet it will match

    _25._tcp.smtp.example.com. IN TLSA 3 1 1 20041CBFD6570C48ACD8D526572137B9090E8037D115FB3C21218D9E9992A9C2

The *only* way to do CT for DANE TLSA is to do CT for DNS, and there
is no CT for DNS in RFC 6962.

> not make those decisions on this document.

It is not a policy decision, it is just logic.  The impossible
cannot be done.

> How is that not modifying TLS server behaviour?

It is not modifying the TLS protocol, servers are already free to
ignore SNI and return whatever certificate chain they please.  This
document explains that with DANE-EE(3) this yields results that
are satisfactory to the client.

As for modifying TLS, we're for example mandating the transmission
of self-signed roots with DANE-TA(2), and that too is within the
realm of what TLS can do, we're just defining a behaviour profile
that makes DANE-TA(2) work (it does not otherwise).

-- 
	Viktor.