Having read RFC 6698 multiple times recently, I would like to ask
for clarification of the semantics of Certificate usage "3", aka
"Domain-issued certificate".
https://tools.ietf.org/html/rfc6698#section-2.1.1
Given an explicit binding in the DNS for a specified service end-point
to a unique certificate (in full or by subject-publickey-info), it would
seem rather unnatural to apply subject name checks to the certificate so
bound. The binding in the DNS should ideally obviate any need for similar
(potentially conflicting) bindings inside the certificate.
In fact when one deploys a cluster of hosts with a shared key-pair
that provide the same service (possibly via MX or SRV records), it
would be surprising to find that a "TLSA 3 1 1" certificate binding"
needs to be updated when a new host is added to the cluster in
order to resign the public key with an additional name in the SAN
extension, merely to duplicate the DANE binding.
Thus my reading of 6698 is that usage 3 (and 1) obviate any
requirement for name validation, which should only apply with
certificate usage 2 and 0.
However, https://tools.ietf.org/html/rfc6698#section-4 in passing
and without any normative text mentions the issue of name verification
without specifically commenting on any distinction between 0/2 and
1/3. I think follow-on RFCs (dane-srv perhaps) should amend or
clarify this text.
What is the expected interpretation of 6698 in this respect? Does
it support DNS-only bindings to essentially bare public keys
encapsulated in minimal X.509 structures? Is it fair to say that
certificate usage 3 (and I would posit also 1) is such a binding?
This matters because the text in
https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-7.3
which is I hear nearing final review at the IETF seems to fly in
the face of (what I see as) a reanable interpretation of 6698 and
suggests semantics for previously unseen certificate usage values,
and in particular unconditional name checks.
I should note that in my opinion, as a matter of sound design, name
checks for usages "3" and "1" MUST not apply. The reason is that
name checks on already "bound" (via DNSSEC + DANE) certificates
add nothing to security, since a malicious DNS administrator is
free to create whatever certificate contents they see fit (including
a suitably matching name), and publish a "TLSA 3 1 1 <public-key-digest>"
for that certificate. Thus checking names for usage "3" (and usage
"1") is simply an extra opportunity for the handshake to fail, with
no tangile security benefit. So in my view a name check here is
an opportunity "to snatch defeat from the jaws of victory".
Thanks.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane