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

[Viktor Dukhovni <[e-mail]>]

On Sun, Jul 12, 2015 at 11:37:07PM -0400, Paul Wouters wrote:

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

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.

> >Furthermore such a certificate is only ever "rogue" if DNSSEC is
> >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.

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

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