Re: [lamps] draft-ietf-lamps-rfc3709bis-01 security, reliability, and privacy considerations

[Russ Housley <[e-mail]>]

DKG:

Sorry it has taken so long to get through you comments.  They were extensive, and some were quite thought provoking.

Some of you comments were resolved in the earlier discussion with Stefan.  I am only addressing the privacy-related comments in this response.

> I did a quick skim of
> https://www.ietf.org/archive/id/draft-ietf-lamps-rfc3709bis-01.html and
> observed that while the Security Considerations section describes some
> of the "phone home" or "web bug" concerns about logotypes-by-reference,
> they aren't particularly well fleshed out.
> 
> The current text is:
> 
>> Logotype data is fetched from a server when it is needed. By
>> watching activity on the network, an observer can determine which
>> clients are making use of certificates that contain particular
>> logotype data. This observation can potentially introduce privacy
>> issues. Since clients are expected to locally cache logotype data,
>> network traffic to the server containing the logotype data will not
>> be generated every time the certificate is used. In cases where
>> logotype data is not cashed, monitoring would reveal usage
>> frequency. In cases where logotype data is cached, monitoring would
>> reveal when a certain logotype image or audio sequence is used for
>> the first time.
> 
> This and at least one other paragraph in the Security Considerations
> section might belong better in a separate Privacy Considerations
> section.

A separate Privacy Considerations section has been added.  The two paragraphs have been moved to that section.

> Below i unpack a bit why these "web bugs" features are not well-fleshed
> out in the draft as it stands.  This spec is surprisingly twisty and
> complex, so i'm not sure that this covers everything:
> 
> a) there are at least two different things that a relying party might
>    need to make a network call when trying to render a certificate:
> 
>    - an indirect LogotypeData object
>    - the image or audio file referenced from a LogotypeData object
> 
>    If the client is going to cache these things to avoid leaking
>    information on the network, it presumably needs to cache both types
>    of object.

There are two alternatives, direct and indirect,  With direct, the LogotypeData is in the certificate itself.  Withe indirect, the LogotypeData is fetched from a URI.  I think the paragraph, by using the term "logotype data" is covering the LogotypeData data structure as well as image and audio files.  This is muddled in the last sentence.  I'll explicitly add "remote LogotypeData" to make sure it is covered.

I suggest:

   In cases where logotype data is cached, monitoring would reveal
   when a remote LogotypeData, image, or audio sequence is fetched
   for the first time.

> b) to minimize the number of network requests the relying party's cache
>    should be indexed by cryptographic digest of the objects it
>    holds. Since a single object might be referenced by multiple
>    cryptographic digests, a maximally privacy-protective local cache
>    should probably contain one index per supported digest algorithm.

> 
> c) If any one of the elements in logotypeHash is already in the relying
>    party's local cache, the privacy-preservng thing for the client to
>    do is to ignore all logotypeURI elements, even if some of the
>    logotypeHash objects are not found in the cache.
> 
> d) note that the *lack* of a network request for a given URI can also
>    be used for fingerprinting (depending on how the client deals with
>    newly-encountered certs, this could be analogous to HSTS
>    fingerprinting, for example:
>    https://datatracker.ietf.org/doc/html/rfc6797#section-14.9)
> 
> e) If a subscriber asks the issuer to include an image or audio via
>    URL, or if they ask the issuer for an indirect logotype, the issuer
>    can't be sure that any logo data suggested by the subscriber is
>    going to be available for the lifetime of the certificate at the URL
>    proposed.  Furthermore, the issuer has no control over privacy
>    policies that govern metadata collection by the host of any remote
>    resource.  This draft should encourage an issuer who cares about
>    potential privacy risks for its relying parties to copy any
>    referenced data to a server that it already controls and can make
>    reasonable guarantees about privacy, reliability, etc.  Note also
>    that if the subscriber asks the issuer to refer to an indirect
>    LogotypeData object, and the issuer decides to host that data itself
>    in addition to hosting the underlying image or audio resource, the
>    logotypeData object will need to be rewritten to change the
>    underlying URLs (and will therefore have a different digest than the
>    requested object).  This at least makes the privacy situation
>    comparable to CA-controlled OCSP, rather than subscriber-controlled
>    resources.
> 
> f) i didn't see any guidance to relying parties about how to handle a
>    mismatch between the MIME type referenced in the mediaType field of
>    the logotypeData and the Content-Type HTTP header of the retrieved
>    resource.  Consider a polymorphic bytestream that could be
>    interpreted by either a png renderer or a pdf renderer.  As the spec
>    is currently written, it looks like a client could accept a
>    Content-Type from the https server that doesn't match the mediaType
>    field, and it might accept the HTTP header as ground truth.
> 
> g) the draft should offer additional guidance for a CA that wants to
>    demonstrate a commitment to not planting web bugs in its
>    certificates.  here are several approaches, including:
> 
>      - Always using direct LogotypeInfo objects (no network access)
> 
>      - Self-host referenced objects (as in (e))
> 
>      - Consolidate hosted objects (all objects with the same hash are
>        always at the same URI, to avoid path-based fingerprinting)
> 
>      - ensure that encoded non-data URIs are as low-entropy as
>        possible, to limit the amount of individualized tracking that
>        could be done (a distinct URL per cert would be the most
>        dangerous)
> 
> h) advise relying parties on how to constrain their HTTP resource
>    fetches to minimize fingerprinting (e.g., no cookies, no e-tags,
>    anonymized user-agent, no client certificates, and so on) -- is
>    there some sort of anonymous HTTP client profile we could point to?
>    (note that this might contradict the guidance about performing
>    "appropriate security controls" for privacy-sensitive logos)

I think the best way to respond if to offer the revised Security Considerations and the new Privacy Considerations.

9.  Security Considerations

   Implementations that simultaneously display multiple logotype types
   (subject organization, issuer, community, or other), MUST ensure that
   there is no ambiguity as to the binding between the image and the
   type of logotype that the image represents.  "Logotype type" is
   defined in Section 1.1, and it refers to the type of entity or
   affiliation represented by the logotype, not the of binary format if
   the image or audio.

   Logotypes are very difficult to securely and accurately define.
   Names are also difficult in this regard, but logotypes are even
   worse.  It is quite difficult to specify what is, and what is not, a
   legitimate logotype of an organization.  There is an entire legal
   structure around this issue, and it will not be repeated here.
   However, issuers should be aware of the implications of including
   images associated with a trademark or servicemark before doing so.
   As logotypes can be difficult (and sometimes expensive) to verify,
   the possibility of errors related to assigning wrong logotypes to
   organizations is increased.

   This is not a new issue for electronic identification instruments.
   It is already dealt with in a number of similar situations in the
   physical world, including physical employee identification cards.  In
   addition, there are situations where identification of logotypes is
   rather simple and straightforward, such as logotypes for well-known
   industries and institutes.  These issues should not stop those
   service providers who want to issue logotypes from doing so, where
   relevant.

   It is impossible to prevent fraudulent creation of certificates by
   dishonest or badly performing issuers, containing names and logotypes
   that the issuer has no claim to or has failed to check correctly.
   Such certificates could be created in an attempt to socially engineer
   a user into accepting a certificate.  The premise used for the
   logotype work is thus that logotype graphics in a certificate are
   trusted only if the certificate is successfully validated within a
   valid path.  It is thus imperative that the representation of any
   certificate that fails to validate is not enhanced in any way by
   using the logotype data.

   This underlines the necessity for CAs to provide reliable services,
   and the relying party's responsibility and need to carefully select
   which CAs are trusted to provide public key certificates.

   This also underlines the general necessity for relying parties to use
   up-to-date software libraries to render or dereference data from
   external sources, including logotype data in certificates, to
   minimize risks related to processing potentially malicious data
   before it has been adequately verified and validated.

   Referenced image objects are hashed in order to bind the image to the
   signature of the certificate.  Some image types, such as SVG, allow
   part of the image to be collected from an external source by
   incorporating a reference to an external file that contains the
   image.  If this feature were used within a logotype image, the hash
   of the image would only cover the URI reference to the external image
   file, but not the referenced image data.  Clients SHOULD verify that
   SVG images meet all requirements listed in Section 7 and reject
   images that contain references to external data.

   CAs issuing certificates with embedded logotype images should be
   cautious when accepting graphics from the certificate requestor for
   inclusion in the certificate if the hash algorithm used to sign the
   certificate is vulnerable to collision attacks.  In such a case, the
   accepted image may contain data that could help an attacker to obtain
   colliding certificates with identical certificate signatures.

   Certification paths may also impose name constraints that are
   systematically checked during certification path processing, which,
   in theory, may be circumvented by logotypes.

   Certificate path processing as defined in [RFC5280] does not
   constrain the inclusion of logotype data in certificates.  A parent
   CA can constrain certification path validation such that subordinate
   CAs cannot issue valid certificates to end-entities outside a limited
   name space or outside specific certificate polices.  A malicious CA
   can comply with these name and policy requirements and still include
   inappropriate logotypes in the certificates that it issues.  These
   certificates will pass the certification path validation algorithm,
   which means the client will trust the logotypes in the certificates.
   Since there is no technical mechanism to prevent or control
   subordinate CAs from including the logotype extension or its
   contents, where appropriate, a parent CA could employ a legal
   agreement to impose a suitable restriction on the subordinate CA.
   This situation is not unique to the logotype extension.

   When a relying party fetches remote logotype data, a mismatch between
   the media type provided in the mediaType field of the LogotypeDetails
   and the Content-Type HTTP header of the retrieved object should be
   treated as a failure and the fetched logotype data should not be
   presented to the user.

   When a subscriber requests the inclusion of remote logotype data in a
   certificate, the CA cannot be sure that any logotype data will be
   available at the provided URI for the entire validity period of the
   certificate.  To mitigate this concern, the CA may provide the
   logotype data from a server under its control, rather than a
   subscriber-controlled server.

   The controls available to a parent CA to protect itself from rogue
   subordinate CAs are non-technical.  They include:

   *  Contractual agreements of suitable behavior, including terms of
      liability in case of material breach.

   *  Control mechanisms and procedures to monitor and follow-up
      behavior of subordinate CAs.

   *  Use of certificate policies to declare an assurance level of
      logotype data, as well as to guide applications on how to treat
      and display logotypes.

   *  Use of revocation functions to revoke any misbehaving CA.

   There is not a simple, straightforward, and absolute technical
   solution.  Rather, involved parties must settle some aspects of PKI
   outside the scope of technical controls.  As such, issuers need to
   clearly identify and communicate the associated risks.

10.  Privacy Considerations

   Certificates, and hence their logotype images, are commonly public
   objects and as such usually will not contain privacy-sensitive
   information.  However, when a logotype image that is referenced from
   a certificate contains privacy-sensitive information, appropriate
   security controls should be in place to protect the privacy of that
   information.  Details of such controls are outside the scope of this
   document.

   Logotype data might be fetched from a server when it is needed.  By
   watching activity on the network, an observer can determine which
   clients are making use of certificates that contain particular
   logotype data.  This observation can potentially introduce privacy
   issues.  Since clients are expected to locally cache logotype data,
   network traffic to the server containing the logotype data will not
   be generated every time the certificate is used.  In cases where
   logotype data is not cashed, monitoring would reveal usage frequency.
   In cases where logotype data is cached, monitoring would reveal when
   a remote LogotypeData, image, or audio sequence is fetched for the
   first time.

   When the the "data" URI scheme is used, there is no network traffic
   to fetch logotype data, which avoids the concerns described above,
   but the certificate will likely be larger than one that contains a
   URL.  For this reason, the "data" URI scheme will be the only one
   that is supported by some CAs.

   In cases where logotype data is cached, the cache index should
   include the hash values of the associated object with the goal of
   fetching the object only once, even when it is referenced by multiple
   URIs.  The index should include hash values for all supported hash
   algorithms.  Give preference to logotype data that is already in the
   cache when multiple alternative are offered in the LogotypeExtn
   certificate extension.

   When fetching remote logotype data, relying parties should used the
   most privacy-preserving options that are available to minimize the
   opportunities for servers to "fingerprint" clients.  For example,
   avoid cookies, e-tags, and client certificates.

   When a relying party encounters a new certificate, the lack of
   network traffic to fetch logotype data might indicate that a
   certificate with references to the same logotype data has been
   previously processed and cached.

Thanks again for you very thoughtful comments,
   Russ