On Tue, Mar 05, 2013 at 11:08:29AM -0500, Tom Ritter wrote:
> I think that name checks MUST be performed when validating
> certificates marked with usage 1. (And 0 & 2 obviously)
Thanks Tom, I think you give a clear explanation for the
position that 1 means name checking. So I'll try to state
my final objection in-line, and leave it at that...
> I feel it violates the intention of the RFC with regards to Usage 1:
> To assert validity through BOTH DNSSEC and the CA system.
I agree only to the extent that the intension has a rational basis
in added security. If we compel the client (via MUST name check)
to reject some certificate, there must be a real reason for this,
otherwise we're just breaking valid connections because it feels
more PKI compliant.
I have a proof that no such rational basis is possible, see below.
It seems we're mistaking a server SHOULD (have a certificate with
a matching name) for a client MUST (check for such a name), which
limits flexibility and likely offers no additional security. This
is I think the result of an incomplete threat model analysis.
> > Does anyone have a real example in which a validator that ignores
> > the CA signed name with certificate usage 1 (but not revocation, ...)
> > faces a new tangible risk they don't face if they perform the name
> > check? If there are no such examples, no RFC should compell the
> > TLS client to check the (inside the cert) name bindings from the
> > issuing CA in cert usage 1.
>
> Stated simply: No, not today. (Because if you can change the record
> you could change it to Usage Mode 3)
Lemma. If the attacker has compomised the DNS to the extent that
he can sign new RRsets that the domain owner never signed, he wins,
whether the client checks names or not.
Proof 1: The attacker publishes a 3 1 1 usage for a new
certificate of his choice, and even puts in the right name,
though name checks in usage 3 are not needed.
Proof 2: The attacker publishes a 2 1 1 usage for a new
issuing CA of his choice, which signs a new certificate of
his choice which bears the right name.
Note 1: Such an attacker can subvert all other DNSSEC validated
policy, so if there is anything in DNS published by the compromised
domain that asserts that the domain never issues valid 2/3 TLSA
records and always uses 0/1, this too can be subverted by the
attacker, so it is not clear how say DPF would mattter.
Note 2: How many potentially overlapping policy sources do we expect
a DANE-aware client to consult? MUST a DANE-aware MTA also implement
the future DPF, and then later yet another policy source? Surely
complying with the semantics of TLSA records should not be a game
of RFC whack-a-mole! Must I hold-off implementing DANE in Postfix
until DPF is published, what else must I wait for?
Corollary. Any justification for name checks must assume the attacker
is not able to generate fraudulent TLSA records for the target
domain. Therefore, in any attack thwarted by name checks the client
acts on authentic (possibly stale, but not yet expired) TLSA records
for the target domain.
Proof:
Since we're considering whether client name checks in usage 1 thwart
active attacks, we focus on an authentic usage 1 RR signed by the
target domain. When such an authentic record was issued, it
legitimately bound the end-entity certificate to the service.
Therefore, the certificate in question was the right one at that
time. It was at that time properly signed by some public CA, and
bound by the domain owner to the service in question.
If the binding was once valid for the given service, and is not
yet expired nor is the TLSA RR expired, to make it invalid one must
revoke the certificate. PKIX trust chain validation gives us
revocation checks and expiration checks. Therefore, there is
nothing to be gained from name checks, as the name in the certificate
is immutable. Q.E.D.
Comment:
The name check only serves to bind the hands of the domain owner.
If name checks are mandatory on the client, the client must reject
the EE certificate even though it was authentically bound to the
service by the domain owner via DANE. This limits the domain owner
to deploy said certificate only on the hosts originally anticipated
when the certificate was obtained.
Example:
Consider an expensive 2-year certificate for mail.example.com, for
a then small business which hosts POP, IMAP and inbound MX on a
single host.
The business has a good year and grows to the point that it makes
sense to separate the MX host from the POP/IMAP service.
The POP/IMAP MUAs predominantly do traditional PKI, so the
mail.example.com name and certificate stay with the new mailbox
host. Most MTAs on the other hand do opportunistic TLS at best,
but some business partners already have explicit SMTP TLS security
policy to connect to and verify mail.example.com.
The business wants to improve mail security and use DANE to allow
more partners to deliver email securely. So it makes sense to
publish a 1/1/1 TLSA record binding mx.example.com to the existing
certificate which still has 1 year of validity. This is thwarted
by Tom's reading of the consensus interpretation. :-(
I don't see any reason for DANE to prevent the domain owner from
binding the still valid mail.example.com certificate to the new
mx.example.com (split-off host) via a 1/1/1 TLSA record.
Gut feeling is sometimes just indigestion. :-) What rational basis
do we have to exclude this and other related use-cases?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
