Subject: [dane] New "operational considerations" text (was: Addition to "Security considerations")

From: Ondrej Mikle <[email-masked]>
Date: Sun, 18 Dec 2011 23:06:35 +0100

I've written new non-normative version of text concerning association of
certificate usage 0 and 2. Hopefully I did not miss any important point from the
discussions so far.

I tried to make text as clear as possible to DNS admins/operators who might have
no deep knowledge about minutiae in TLS clients' approaches when building
certificate chain.

Use cases are outlined and administrator/operator is advised why they happen,
which choice is better for given situation. I hoped to the balance between
possibility of (yet unknown) future attacks and false positive rate (clients
denying association).

Also see notes below the text with additional suggestions that could be
incorporated into the text.

RFC technicalities: RFC 4949 deprecates term "CA certificate", though RFC 5280
uses it. RFC 4949 suggests that is should be defined explicitly (as v3 X.509
public-key certificate that has a "basicConstraints" extension containing a "cA"
value of "TRUE"; possibly adding v1 certificates may be necessary).

Formatting notes: **line** stands for subsection, [--line--] for internal comment.

---begin text---

When creating TLSA record with certificate usage type 0 or 2, care should be
taken when choosing between selector type 0 (full certificate) and 1
(SubjectPublicKeyInfo). Careful choice is required due to algorithms in various
TLS clients employed to build client's trust-chain. We first outline cases to be
aware of and then discuss implications on choice of selector type.

Certificate usage 2 is unaffected if association is made to an end entity
certificate.

**Ambiguities and corner cases of trust-chain building by TLS clients**

TLS clients are known to implement methods that may cause any certificate except
end entity certificate in original certificate chain sent by server to be
exchanged or removed from the chain when client builds trust chain.

Certificates the client can use to replace certificates from original chain include:
- client's trust anchors
- certificates cached locally
- certificates retrieved via URI listed in Authority Information Access X.509v3
extension.

CAs frequently reissue certificates with different validity period, hash in
signature algorithm or extensions (public key, issuer and subject remain
intact). Those are the certificates TLS client can use in place of original
certificate.

Cases when clients are known to exchange or remove certificates that could cause
TLSA association by full certificate to fail are listed below:

1. client considers hash in signature algorithm of a certificate no longer
sufficiently secure
2. a cross-certificate issued to CA2 by CA1 is represented by a self-signed
root certificate of CA2 as a trust anchor in client's trust store
3. a CA certificate above cross-certificate in original chain may be removed
from chain, because client found a trust anchor below said CA certificate

**Discussion on choice of selector type**

1. Choosing selector type 0

"Full certificate" selector provides most precise specification of trust anchor.
Such non-ambiguity foils class of hypothetical future attacks on CA where CA
issues new certificate with identical SubjectPublicKeyInfo, but different
issuer, subject, extensions (which would allow redirect trust chain). This
selector would also foil bad practices or negligence of CA should CA use
identical key for unrelated CA certificates.

For DNS administrator, best course to avoid false-positive failures at client's
side when using this selector is:
- don't associate to CA certificates having signature algorithm with hash that
is considered weak if CA issued a replacement certificate
- check how common client programs process the TLSA association on fresh client
installations - local certificate cache needs to be empty.

2. Choosing selector type 1

SPKI selector gives greater flexibility in avoiding share of false-positive
failures caused by trust-chain-building algorithms used in clients.

One specific use-case should be noted: creating TLSA association to certificate
I1 that directly signed end entity certificate S1 of server. Since the key used
to sign S1 is fixed, association to I1 must succeed - if client swaps I1 for
other certificate I2, its SPKI must match SPKI of I1. Such association would not
suffer from false-positive failure on client's side should the client use a
reissued CA certificate I2 in place of I1.

The attack surface is a bit broader compared to "full certificate" selector:
- administrator must know or trust the CA not to engage in bad practices (not
sharing key of I1 for unrelated CA certs leading to trust-chain redirect)
- administrator should understand whether some X.509v3 extension may adversely
affect security of the association. If possible, administrator should overview
CA certificates sharing the SPKI.

Using SPKI selector for association with a certificate in chain above I1 is to
be decided on by-case basis. There are too many possibilities depending on
issuing CA. Unless full implications of such association are understood by
administrator, using selector type 0 might be better option security-wise.

[--following paragraph might need update--]
In practice, sharing keys in differently-purposed CA certificates is rare,
nevertheless not non-existent. Attack on association by SPKI would require
either gross negligence on CA's part or an attacker gaining control of CA.

---end text---

Some additions that could be made to the above text that I am not sure whether
they are suitable/allowed for RFC text:

I'd like to mention Valicert as a great example of CA issuing cross-certificates
(Valicert certificates are present in cert chains sent by at least 400000
hosts). I believe such example would be much more understandable to
administrators (target audience) than RFC 4949 definitions.

Preceding discussions raised point that cross-certificate cannot be identified
from its fields alone. Best document I've found so far identifying CAs issuing
cross-certificates is the CA graph done by EFF (I mean primarily the textual
discrete graph graphviz source - nodes being CAs and edges showing
certifications). Otherwise cross-signing CAs may be found only by reading CPS.

On a similar note, listing MD2 and MD5 as "hash algorithms considered weak at
the time of writing" would be clearer, too (again not sure whether allowed in RFC).

Ad last paragraph "needing update": I've dug a bit into collected CA certificate
data to see if CA certificate pairs sharing same public key might belong to
different entities. One sample pair found shows key sharing between UK CA and US
RA for different products (having different guarantees). This might also be a
good reason for suggesting TLSA associations are to be made to certificates
lower in the chain (for both selector types).

Ondrej Mikle

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 28 Dec 2011 15:13:43 -0800

>From my point of view this text is far improved.

Of course I still have some suggestions

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ondrej Mikle
> Sent: Sunday, December 18, 2011 2:07 PM
> To: [email-masked]
> Subject: [dane] New "operational considerations" text (was: Addition to
> "Security considerations")
> 
> certificate usage 0 and 2. Hopefully I did not miss any important point
from
> the discussions so far.
> 
> I tried to make text as clear as possible to DNS admins/operators who
might
> have no deep knowledge about minutiae in TLS clients' approaches when
> building certificate chain.
> 
> Use cases are outlined and administrator/operator is advised why they
> happen, which choice is better for given situation. I hoped to the balance
> between possibility of (yet unknown) future attacks and false positive
rate
> (clients denying association).
> 
> RFC technicalities: RFC 4949 deprecates term "CA certificate", though RFC
> 5280 uses it. RFC 4949 suggests that is should be defined explicitly (as
v3
> X.509 public-key certificate that has a "basicConstraints" extension
containing
> a "cA"

Given that we use the term CA certificate in other locations in the
document, we should just define the term in a glossary and continue to use
it.

> When creating TLSA record with certificate usage type 0 or 2, care should
be

s/type 0 or 2/type 0 (CA Certificate) or type 2 (Trust Anchor)/
s/care should be taken/the implications need to be understood/

> (SubjectPublicKeyInfo). Careful choice is required due to algorithms in

s/algorithms in/the different methods/

> various TLS clients employed to build client's trust-chain. We first
outline

s/client's trust-chain/trust-chains/

> cases to be aware of and then discuss implications on choice of selector
type.
> Certificate usage 2 is unaffected if association is made to an end entity
s/*/Certificate usage 2 is not affected by the issue of chain building when
the end entity certificate and the trust anchor certificate are the same./

> TLS clients are known to implement methods that may cause any certificate
> except end entity certificate in original certificate chain sent by server
to be
> exchanged or removed from the chain when client builds trust chain.

TLS clients may implement their own chain building code rather than rely on
the chain presented by the server.  This means that, except for the
end-entity certificate, any certificate presented in the suggested chain may
or may not be present in the final chain built by the client.

> 
> Certificates the client can use to replace certificates from original
chain
> include:

s$reissue$issue/reissue$
s/hash in signature algorithm/signature algorithm (updated hash), CA key
pair (cross-certificate)/
s/,issuer//
s/original/an original/

> 
> Cases when clients are known to exchange or remove certificates that could
> cause TLSA association by full certificate to fail are listed below:
> 
> sufficiently secure 2. a cross-certificate issued to CA2 by CA1 is
represented
> by a self-signed root certificate of CA2 as a trust anchor in client's
trust store
> from chain, because client found a trust anchor below said CA certificate

Formatting - this should be represented as a list rather than a single
sentence.  It is hard to follow this way.

1. The client considers the signature algorithm of a certificate to no
longer be sufficiently secure.  This may be because of the hash algorithm or
the signature key size.

2.  I cannot follow this sentence

3.  This seems to follow the case in #2 so I am not sure why it would be
true.  I would expect the case to be the opposite direction.

> identical key for unrelated CA certificates.

Why does the first sentence talk about trust anchors, and then the rest of
the paragraph basically talk about the case of CA certificates?  It would
not matter how the TA is specified in terms of preventing attacks on CAs in
the chain below the TA.

> side when using this selector is:

I don't understand what a false-positive failure would be.  This needs to be
defined.   I think that a false-positive failure would be that the client
accepts the certificate chain when as the administrator I don't think that
they should reject.  A false-negative would be when the client rejects a
chain that as the administrator I think that they should accept.  Under this
I think you are talking about false-negatives - that is the client should
accept the chain because I gave a valid one and they mucked it up.

> - check how common client programs process the TLSA association on fresh
> client installations - local certificate cache needs to be empty.
> 
> to sign S1 is fixed, association to I1 must succeed - if client swaps I1
for other
> certificate I2, its SPKI must match SPKI of I1. Such association would not
> - administrator should understand whether some X.509v3 extension may
> adversely affect security of the association. If possible, administrator
should
> overview CA certificates sharing the SPKI.
> 
> Using SPKI selector for association with a certificate in chain above I1
is to be
> decided on by-case basis. There are too many possibilities depending on
> [--following paragraph might need update--] In practice, sharing keys in
> differently-purposed CA certificates is rare, nevertheless not
non-existent.
> Attack on association by SPKI would require either gross negligence on
CA's
> part or an attacker gaining control of CA.
> 
> ---end text---
> 
> 
> Some additions that could be made to the above text that I am not sure
> whether they are suitable/allowed for RFC text:
> 
hosts). I
> believe such example would be much more understandable to

Are they doing it without the "permission" of certificate holder?

> On a similar note, listing MD2 and MD5 as "hash algorithms considered weak
> at the time of writing" would be clearer, too (again not sure whether
allowed
> in RFC).

On could easily reference RFC 6331 (MD5), RFC 6149 (MD2) .  I have not seen
one for SHA1 yet or it has gone stale.

> 
> Ad last paragraph "needing update": I've dug a bit into collected CA
> certificate data to see if CA certificate pairs sharing same public key
might
> belong to different entities. One sample pair found shows key sharing
> between UK CA and US RA for different products (having different
> guarantees). This might also be a good reason for suggesting TLSA
> associations are to be made to certificates lower in the chain (for both
> selector types).
> 
> 
> Ondrej Mikle
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane