On Sat, 11 Jul 2015, Viktor Dukhovni wrote:
* 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?
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.
CT checks are designed to help keep public CAs honest (detect
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
CA is involved, so CT (for the X.509 WebPKI) is logically out of
scope.
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.
* 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.
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).
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.
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?
No, I think you should not try to dictate the local policy behaviour.
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 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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
