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

From: Ondrej Mikle <[email-masked]>
Date: Mon, 23 Jan 2012 19:06:41 +0100

On 12/29/2011 12:13 AM, Jim Schaad wrote:
> From my point of view this text is far improved.
> 
> Of course I still have some suggestions

Updated version of current A.1 section is below (it's shortened output
from xml2rfc, I'll post link to git source tomorrow). Typos and errors
mentioned in other threads should be fixed as well.

I mostly adopted Jim's suggestion/replacement texts without changes.

What caused probably most confusion in the text is the difference in
RFCs and actual PKIX implementations:
AFAIK the only implementation that can return all chains is MS
CryptoAPI, others don't implement it - NSS definitely doesn't and I
didn't find it in Java libs (security API and bouncycastle) or OS X's
Security.framework.

I removed references to "first match only" behavior from the text, but
we need to keep in mind that in the "transitional period" such behavior
is likely to cause some issues (and given that many implementations are
not even close to RFC 3280/5280 compliant, it will take some time).

--- begin text ---

A.1.  Creating TLSA Records

   When creating TLSA record with certificate usage type 0 (CA
   Certificate) or type 2 (Trust Anchor), the implications need to be
   understood taken when choosing between selector type 0 (full
   certificate) and 1 (SubjectPublicKeyInfo).  Careful choice is
   required due to the different methods various TLS clients employed to
   build trust-chains.  We first outline cases to be aware of and then
   discuss implications on choice of selector type.

   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.

A.1.1.  Ambiguities and corner cases of trust-chain building by TLS
      clients

   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:

   1.  client's trust anchors

   2.  certificates cached locally

   3.  certificates retrieved via URI listed in Authority Information
       Access X.509v3 extension.

   CAs frequently issue/reissue certificates with different validity
   period, signature algorithm (updated hash), CA key pair (cross-
   certificate) or extensions (public key, subject remain intact).
   Those are the certificates TLS client can use in place of an 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.  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.  The client may not have associated root certificate in trust
       store and uses a cross-certificate with identical subject and
       public key instead.

A.1.2.  Discussion on choice of selector type

   Definition: "false-negative failure" means that client will not
   accept the TLSA association for certificate designated by DNS
   administrator.

A.1.2.1.  Choosing selector type 0 (full certificate)

   "Full certificate" selector provides most precise specification of
   TLS certificate association, capturing all fields of X.509
   certificate.  For DNS administrator, best course to avoid false-
   negative failures at client's side when using this selector are:

   1.  don't associate to CA certificates having signature algorithm
       with hash that is considered weak if CA issued a replacement
       certificate

          - hash algorithms considered weak at moment of writing: MD2
          (RFC 6149), MD5 (RFC 6331)

   2.  check how common client programs process the TLSA association on
       fresh client installations - local certificate cache needs to be
       empty

A.1.2.2.  Choosing selector type 1 (SubjectPublicKeyInfo)

   SubjectPublicKeyInfo selector gives greater flexibility in avoiding
   share of false-negative 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-
   negative 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:

   1.  administrator must know or trust the CA not to engage in bad
       practices (not sharing key of I1 for unrelated CA certificates
       leading to trust-chain redirect)

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

--- end-text ---

Ondrej Mikle

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 15:41:30 -0800

I have edited the earlier text to use this new batch. It will appear in -15.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 23 Jan 2012 22:35:01 -0800

> -----Original Message-----
> From: Ondrej Mikle [mailto:[email-masked]]
> Sent: Monday, January 23, 2012 10:07 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [dane] New "operational considerations" text (was: Addition
to
> "Security considerations")
> 
from
> xml2rfc, I'll post link to git source tomorrow). Typos and errors
mentioned in
> other threads should be fixed as well.
> 
> What caused probably most confusion in the text is the difference in RFCs
> and actual PKIX implementations:
> AFAIK the only implementation that can return all chains is MS CryptoAPI,
> others don't implement it - NSS definitely doesn't and I didn't find it in
Java
> libs (security API and bouncycastle) or OS X's Security.framework.
> 
> I removed references to "first match only" behavior from the text, but we
> need to keep in mind that in the "transitional period" such behavior is
likely
> to cause some issues (and given that many implementations are not even
> close to RFC 3280/5280 compliant, it will take some time).
> 
> --- begin text ---
> 

We need to set off the last parenthesis expression since they are not
extensions.  Suggest

... or extensions where the public key and subject remain the same.

>    accept the TLSA association for certificate designated by DNS

I don't care for this definition of false-negative failure.  It implies that
if the association was actually incorrect then it would still be a false
negative failure. 

I would also want to look at the other side of this.  

Definition: "false-positive acceptance" means that the client accepts a TLSA
association for a certificate not designated by the DNS administrator.

Is that really what you want to say?

Jim

---

From: Ondrej Mikle <[email-masked]>
Date: Tue, 24 Jan 2012 16:12:43 +0100

> ... or extensions where the public key and subject remain the same.

Fixed, new wording:

   CAs frequently issue/reissue certificates with different validity
   period, signature algorithm (updated hash), CA key pair (cross-
   certificate) or extensions where the public key and subject remain
   the same.  Those are the certificates TLS client can use in place of
   an original certificate.

> Is that really what you want to say?

Mostly yes. I added "a correct TLSA association" to the false-negative
case and added the false-positive definition:

   Definition: "false-negative failure" means that the client will not
   accept a correct TLSA association for certificate designated by DNS
   administrator.

   Definition: "false-positive acceptance" means that the client accepts
   a TLSA association for a certificate not designated by the DNS
   administrator.

Full text of section is here (for easier copy&pasting later):

https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/draft-ietf-dane-protocol_creating_tlsa_section.txt
https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/draft-ietf-dane-protocol_creating_tlsa_section.xml
git://git.nic.cz/ietf (whole repository git access)

Ondrej Mikle

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jan 2012 09:09:31 -0800

> Fixed, new wording:

Note that Jakob and I are not using your wording as-is, but are also honing the English some as we include it in the document. I have made the change that Jim proposed in the next draft.

> git://git.nic.cz/ietf (whole repository git access)

I'll grab this text and try to work it in. We'll clearly need to spend more time editing this section after the next draft is out.

--Paul Hoffman