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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Stefan--

Thanks for your followup!  comments inline.

On Mon 2022-03-28 22:38:29 +0200, Stefan Santesson wrote:
> I'm not convinced that this document is the palace to regulate or advice
> on caching or storage. My main motivation for this position is that the
> potential use-cases are not specific to the degree where you can give
> specific meaningful guidance. Any guidance will therefore be generic to
> the degree that it should belong in generic documents. Implementers can
> chose their approach to this issue from the context of how the
> certificates are issued and used.

I'm sure you didn't mean it this way, but this kind of reads like "as
protocol designers we can't be bothered to think through the privacy
implications of our work" or "privacy implications are left as an
exercise to the reader".

I'm not suggesting that every single detail i outlined in my earlier
message belongs explicitly in the draft.  But i don't think it's
reasonable in 2022 to omit privacy considerations entirely on a document
that is going to ask the relying party to fetch some (possibly multiple)
additional network resources in some circumstances, especially in
security-critical circumstances (like inspecting the certificate of a
communications partner).

The systems we design and specify in the IETF and other SDOs are
routinely used across the globe to identify and target people, for
purposes ranging from counting advertising conversions to offering
customized content to tracking down criminals, debtors, and dissidents
to deliberate killing.

I'm not saying that this mechanism on its own is necessarily going to
result in any of these outcomes, but i am saying that how it is deployed
in the world will have an effect on people's lives and the risks they
face.  As designers and specifiers we need to consider that, and to help
implementers consider it and implement responsibly.

> Obviously things becomes much easier if all data is embedded, but this
> has the the cost of larger size.

I understand this constraint, and agree that there is an inherent
tradeoff between certificate size, caching behavior, and privacy
concerns.  Unfortunately, that tradeoff is not adequately discussed in
the draft.

Furthermore, the draft doesn't do much to try to alleviate size concerns
at all -- it almost looks like an afterthought.  For example, if the
draft really wanted to prioritize minimizing certificate size, then it
would offer an ASN.1 native OCTET STRING representation for the embedded
objects, rather than stuffing another layer of base64-encoding with the
data: URL.

Even worse, the text in the draft says:

   There is no need to significantly increase the size of the
   certificate by including image and audio data of logotypes when a URI
   identifying the location to the logotype data and a one-way hash of
   the referenced data is included in the certificate.

This "no need" appears to encompass the privacy rationale, if i'm
reading it right.

So as it stands, the document not only dismisses the privacy concerns,
but appears to actively discourage privacy-motivated embedding by
inflating the size of an embedded resource by base64's 33% overhead.

It even warns against embedding with scary-but-unquantified,
non-actionable guidance like:

     NOTE: Implementations need to be cautious about the size of images
     included in a certificate in order to ensure that the size of the
     certificate does not prevent the certificate from being used as
     intended.

What are these limits?  Where do they come from?  Do they also apply to
the size of images fetched over the network?  I'm fine with establishing
sensible, even arbitrary limits for the sake of interoperability.  But
then they need to be well-defined and measurable limits with clear scope
as to where they apply.


If the draft tried to take privacy seriously, it would at least
contemplate the following questions:

 - If i'm a certificate issuer, and i want to avoid my relying parties
   from being tracked, and i'm asked to produce a certificate by a
   subscriber, what should i do to minimize the risk of harm to my
   relying parties? At what cost?  what if i'm concerned about my
   *subscriber* being tracked by an entity observing activity of the
   relying parties?

 - If i'm a subscriber, and i don't want to expose my users (the relying
   parties) to additional risks of tracking and surveillance, what
   should i request from my certificate issuer?  At what cost?  If i
   have such a certificate, are there ways I can operate my service to
   reduce risks to my users?

 - If i'm a relying party, and i want to minimize my tracking, how
   should i handle certificates with these logotypes in them?  At what
   cost?

 - As an implementer of client software used by the relying party, what
   affordances should i make in my implementation to defend the user's
   privacy?

 - How do these four different perspectives interact?

(or, you could approach this the way a security analysis is typically
done: put yourself in the shoes of the tracker/surveillor and see how
you would deploy this to maximum tracking effect, against the wishes of
the subscriber or the relying party)

It's ok to not have all the answers to all of these questions, but the
document needs to acknowledge that they're relevant, and either describe
some simple, widely-applicable mitigations, call for further research,
or point to existing already-documented strategies that can reduce the
risks to privacy.

> Another argument for not giving specific guidance here is that caching
> may also be handled on another layer that is completely independent of
> this specification and its implementation, such as generic http caching
> by the application or the network.

I think you're saying the privacy implications of those additional
layers are themselves not well understood.  I don't think i'd argue with
you about that.

That's why a draft that tries to clarify the mechanisms for including
media in certificates (potentially by multiple layers of indirection)
should include a privacy considerations section that attempts describe
or point to the potential known risks at least, even if it can't
describe all possible mitigations.

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

This point didn't seem to get a response.  can you comment on it?  Did i
misunderstand the draft?

>> A few additional concerns about the draft (sorry this is all smushed
>> into a single e-mail -- if there is an issue tracker for this draft,
>> please reference it in subsequent versions of the draft so that these
>> notes can be broken out separately):
>>
>>  i) not clear how to map the elements in the logotypeHash sequence of
>>     hashes to the elements in the logotypeURI sequence of URIs.  Should
>>     every reference within a given logotypeDetails refer to the same
>>     underlying object?  (this is related to (c) above).
>
> The text says: "Both direct and indirect addressing accommodate
> alternative URIs to obtain exactly the same item"

the text is confusing as written because:

- there are multiple layers of plurals involved (do direct and indirect
  addresses need to both point to the exact same item?  what about the
  layers between the LogotypeReference and the LogotypeDetails?), and

- "exactly the same item" is unclear.

Does "exactly the same item" mean that the contents of the HTTP
responses should be byte-identical?  or that their *headers* are also
byte-identical?  what if the URL points to a resource that has different
body content based on the Accept: or Accept-Language: (or Accept-*?)
headers in the HTTP request?

Some of the metadata variants described here seem to be recapitulation
of (or hints that can be used to populate?) the http content negotiation
mechanisms.  Being clearer about how those things interact (or don't
interact) would be useful.  If the answer is "we don't trust HTTP
content negotiation to work right, so we're giving you all this data up
front and we recommend that servers host this data in distinct urls
without using content-negotiation for selection" that belongs in the
draft.

Also, i note that the ASN.1 for refStructURI contains this comment:

                    -- Places to get the same LogotypeData
                    -- image or audio object

But the ASN.1 for LogotypeURL has no such comment.  why?

just to be clear, we have this nested set of SEQUENCEs in the data
structure (i'm using "*" to mean "contains more than one of")

  LogotypeExtn
   * LogotypeData (assuming "direct")
    * LogotypeImage (assuming image, not audio)
     * LogotypeDetails
      * LogotypeURL

And that's just one path through the ASN.1 maze to get to where the
multiple LogotypeURLs show up.

Are all the LogotypeURLs within a LogotypeData expected to point to the
same underlying data?  Or could there be multiple LogotypeImage objects
within a LogotypeData, where each image has distinct underlying data?

Assuming that the "exact same item" idea applies only to the final layer
of SEQUENCEs, clearer text would be something like:

   Within a single LogotypeDetails, every LogotypeURL MUST point to a
   bytewise-identical resource.

The categorization as i think i understand it is:

 - How the media relates to the certificate is governed by where the
   LogotypeInfo sits in the top-level LogotypeExtn, *or* (if it sits in
   otherLogos) by the logotypeType OID.

 - The LogotypeImage object can have multiple digital representations of
   the same conceptual piece of media, differentiated by the associated
   metadata (format, bitdepth, language, etc).

 - The LogotypeDetails can point to multiple ways to retreieve the same
   digital object.

what i still don't understand, after several re-reads of the draft, is
why the LogotypeData can have more than one image and more than one
audio element.  Or maybe LogotypeData offers multiple distinct digital
representations of the same object by enclosing a sequence of
LogotypeImage objects?  but then i don't understand why there are
multiple LogotypeDetails objects within a LogotypeImage object.

Maybe the draft itself could offer a succinct explanation of why each of
these layers is present?

>>  k) this draft implies a range of types of logotype: subjects, issuers,
>>     loyalty schemes, etc.  It's pretty easy to see this as expanding
>>     beyond use of logos (e.g. photo IDs for an S/MIME cert).  i'd hope
>>     to see some considerations either explicitly ruling out non-logo use
>>     of these objects, or at least addressing the privacy implications of
>>     using them for non-logo use.
>
> There are already non-logo use. Se section 4.4.3, and that is one of the
> RFCs that used to be a spin-off RFC (6170) that not is merged into this
> document.

It's pretty weird that the document is titled with the word "logotypes",
and it has a terminology section, and yet there is no direct
acknowlegement of the word "image" or "audio" or even "media" until §3.
It appears to offer a generic mechanism to embed media resources in
X.509 certificates, which happens (by historical accident) to be named
"logotype".

If i didn't already know what i was looking at, it would be very hard to
make sense of the draft.  I'm not saying to drop the term "logotype"
entirely, but at least give the document a title like:

   Internet X.509 Public Key Infrastructure: Media ("Logotypes") in X.509 Certificates

And explain the historical accident in the introduction and/or in the
terminology section.

The reason i raised the logo vs. non-logo use is that logo-specific use
at least offers users that fetch a given logo an anonmity set of all
certificates using the same logo
(e.g. "https://www.visa.com/favicon.ico").

But non-logo media are likely to uniquely identify a particular
subscriber.  For example, "Certificate Image" is basically guaranteed to
differ between certificates.

Consequently, any network fetch for a resource that corresponds to the
subscriber risks identifying the subscriber.

TLS 1.3 only recently got finished protecting the server's certificate
in the TLS handshake's encryption layer, so that a network observer
can't see the offered endpoint identity.

If this draft expects the client to make a separate network fetch for a
given resource, potentially over http(!) then it risks undoing that
metadata minimization work.  Even if the resource is fetched over https,
if the size of the request/response pair for the resource is unique to
the host in question, then a network observer can guess with high
confidence the identity of the service being visited.

Furthermore, if the cert-specific media is reused across certificates
over time, then it can produce a long-lived data trail, capable of
linking otherwise unlinkable identities.

>>  l) when fetching an indirect logotype, what Content-Type should the
>>     relying party expect for the LogotypeData?   I'm assuming it's
>>     supposed to be DER-encoded?
>
> You are right. This is not specified, nor is the encoding of the present
> data. This should be fixed.
>
> I would suggest application/octet-stream and DER encoding

Shouldn't this document register a specific MIME type?  I understand
that some webservers are slow to be able to announce new MIME types, and
it's possible that this thing will get served as
application/octet-stream by those servers, so maybe we don't want a
client to reject an application/octet-stream necessarily. But this is
why we have MIME type registration, right?

How about application/logotypedata since that's the (downcased) name of
the ASN.1 structure that it is supposed to contain?  I think there are
people in this WG who know how to navigate the media type registration
process and can help with that.

>>  m) no security considerations for folding polymorphic image renderers
>>     into certificate handling code?  we have recent evidence that there
>>     can be pretty disastrous bugs lurking there:
>>     https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html
>>     guidance about ensuring narrow, well-audited codepaths would be
>>     great.
>
> I don't feel qualified to answer this one. If there is something that
> should be said, then we should say that.

My preferred guidance here would be related to the guidance i asked for
in point (f), about what to do if the metadata in the logoType extension
doesn't match the metadata in the logotype extension (mediaType,
LogotypeImageInfo, LogotypeAudioInfo, etc) doesn't ultimately match the
retreived resource.  the only place where guidance is currently provided
for a metadata mismatch is when the x and y (width and height) don't
match, as described in §4.2.

Conservative/defensive parsing, rejection of non-compliant or mismatched
formats (at both the cert issuer initially, and by the relying party in
the field) keeps the attack surface significantly smaller.




So in the course of writing this message, i re-read the document again,
and found several more concerns.  If you have an issue tracker, these
would be easier to ensure that they get fixed (and to make sure i'm not
repeating myself); if you have the source for this in some reasonable
revision-controlled repository, i could maybe even offer you fixes
directly for some of them.  But as it stands, i'll just continue from
where i left off:

n) There seems to be a mismatch between the ASN.1 and the text about
   whether an image must be present.  The text says yes:

      Each logotype present in a certificate MUST be represented by at least one image data object.

   but the ASN.1 seems to say that audio-only is OK:

    LogotypeData ::= SEQUENCE {
       image           SEQUENCE OF LogotypeImage OPTIONAL,
       audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
          -- At least one of the OPTIONAL components MUST be present
          ( WITH COMPONENTS { ..., image PRESENT } |
            WITH COMPONENTS { ..., audio PRESENT } )


o) It would be great if each example were supplied within an simple
   X.509v3 certificate represented in PEM form, in addition to whatever
   dumpasn1 data and commentary the draft provides.  This would make the
   draft something actionable, which implementers could confirm works
   with their tooling (or doesn't).

   I recommend using the sample certificate authorities in
   draft-ietf-lamps-samples to create the sample certificates.

p) It would be great to see more examples/test vectors, including:

    - examples that exercise the audio functionality

    - examples where any given SEQUENCE in the twisty maze of SEQUENCEs
      has more than one element

    - examples of all Logotypes and "Other logotype type OIDs" defined
      in the draft

   If there isn't enough space (?) to include these examples in an
   appendix, then at least point to a place where these things will
   reliably exist so that an implementer can confirm the rough consensus
   with their own running code.

q) §3 ("Logotype Data") says: "If a logotype of a certain type (as
   defined in Section 1.1)" but section 1.1 is "Certificate-based
   Identification".  Maybe it means "Section 2" or some subpart of
   section 4.1?  I recommend including these references in the
   underlying source by symbolic identifier, so that when sections get
   renamed, the output matches automatically.

   The security considerations section also references section 1.1 when
   it appears to be talking about either section 2 or section 4.1.

r) https://www.ietf.org/archive/id/draft-ietf-lamps-rfc3709bis-01.html#section-4.4.3 says:

     When a certificate image logotype appears in the otherLogos, it
     MUST be identified by the id-logo-background object identifier.

   I think this is meant to be:

     When a certificate image logotype appears in the otherLogos, it
     MUST be identified by the id-logo-certImage object identifier.

   (that is, the OID name appears to have been copy/pasted from the
   §4.4.2)

s) the ASN.1 for refStructURI contains this comment:

                    -- Places to get the same LogotypeData
                    -- image or audio object

   is it really "image or audio"? or is it "image and/or audio" or is it
   just a LogotypeData object, since that object itself might refer to
   multiple different image or audio objects?

t)  "4.3. Embedded Images" says:

      If the logotype image is provided through direct addressing, then
      the image MAY be stored within the logotype certificate extension
      using the "data" scheme [RFC2397]. The syntax of the "data" URI
      scheme defined is included here for convenience:

   The implication here seems to be that if the LogotypeData object
   included by reference ("indirect addressing") then the LogotypeURI
   within that LogotypeData *can't* use the "data" URI.  If this is
   right, it means that indirect addressing will actually incur two
   distinct network lookups if the cache is empty, resulting in both
   latency and privacy losses.

   Why not allow the LogotypeURI contained with remotely-fetched
   LogotypeData to use a data: URI?

   It seems possible that this text was introduced in confusion over the
   multiple layers of indirection that are possible in this draft: i can
   understand why there's no point in sending a data: URI in a
   LogotypeReference, because you might as well just send a LogotypeData
   directly.


u) §4.4.3 says:

     Applications providing a Graphical User Interface (GUI) to the
     certificate user MAY present a certificate image according to this
     standard in any given application interface, as the only visual
     representation of a certificate.

   I'm assuming here that "certificate user" may be either the
   subscriber or a relying party.  I think this text is problematic for
   a relying party.

   As a relying party, the application has to have some level of
   knowledge about how it will *act* on the cert (the draft calls this
   "automated certificate path validation").  The draft makes it very
   clear that the images here have no bearing on the functional aspect
   of the certificate.

   I might trust a given CA (or its intermediate CAs) to validate the
   functional parts of a certificate mechanically (via ACME, for
   example; i can rely on a CA to say "we know this cert belongs to
   foo.example because we executed ACME challenge X").  That validates
   the functional parts, which are what my tooling relies on.  But i
   have *no idea* how any of my "trusted" root CAs (or their
   intermediaries) are going to produce or vet these images. Indeed,
   since the spec says that the images won't be used in path validation,
   the CAs might deliberately not vet them much, because there are no
   CA/B Forum Baseline Requirements about them (are there?)

   But when i ask my tooling to render information about a peer's
   certificate, the most salient features that i'm looking for are the
   verified, functional elements, not just the branding.

   Consider a certificate with a subjectAltName of foo.example, but an
   embedded certificate image that prominently displays the VISA logo
   and say "foo.example" in 8 point font near the bottom right.  If the
   operator of foo.example knows that Alice has a Visa credit card and
   will use this mechanism to confirm the identity of whatever site she
   visits, this strikes me as a clear phishing risk.  the operator can
   just make, say, https://visa.foo.example mimic the visa webpage and
   when the user clicks on the site info button in their browser to try
   to understand what's going on, there's the visa logo, with no other
   info!

   So I can't tell whether the cited paragraph is acknowledging that some
   implementations will fail to give the user visible detail about the
   functional mechanics of a certificate, or if it is actually
   encouraging implementations to hide their functional interpretation
   of the cert.

   If the cited paragraph is just an acknowledgement that some
   implementations will be dangerously insecure, I think we should (a)
   offer a more explicit lamentation, and (b) add a sentence that
   indicates that an implementation that can only offer this visual
   representation MUST at least offer a certificate export mechanism
   (coupled with an export of any related cached LogotypeData or media
   objects that were retrieved over the network), so that an interested
   user can debug the underlying certificate with different tooling.
   This is more of a "MUST (BUT WE KNOW YOU WON'T)" from RFC 6919§1 but
   hey it's better than an idle lamentation.  Even better would be to
   drop this MAY entirely, and convert it to a MUST NOT.

v) "5. Type of Certificates" says:

     logotypes MUST NOT be part of certification path validation or any
     type of automated processing.

   but this seems to be in conflict with requirements like "The
   background image MUST allow black text to be clearly read when placed
   on top of the background image." which would presumably be enforced
   by the certificate issuer via automated processing.

   Perhaps this is supposed to mean "any type of automated processing by
   the relying party" or "any type of automated processing during
   certificate validation"?

w) section 4.1 says:

     Avoid the use of otherLogos whenever possible.

   Is this a guidance for the subscriber, the issuer, the relying party,
   or future specifiers?  As a relying party, it's easy to avoid the use
   of otherLogos: just ignore them.  For the issuer, it's also easy to
   avoid their use, by refusing a certificate signing request that asks
   for one.  Both of these seem possible, but if the issuer and the
   relying party both act on this guidance, then there's no point in the
   subscriber even asking for one.  And that's possible too.  If any of
   those are taken seriously, then we might as well not specify
   otherLogos here.  But we do, so maybe it's saying to future document
   writers "please don't abuse the otherLogos mechanism by defining more
   logotypeType OIDs?  The way to defend against that is to ask IANA for
   a registry and ask for some kind of expert review before adding
   entries, but the draft doesn't do that either.  I don't know who
   should act on this guidance, or how they should behave differently
   having read it.

x) section 4.1 says:

    The LogotypeReference and LogotypeDetails structures explicitly
    identify one or more one-way hash functions employed to authenticate
    referenced image or audio objects. CAs MUST include a hash value for
    each referenced object, calculated on the whole object. CAs SHOULD
    include a hash value that computed with the one-way hash function
    associated with the certificate signature, and CAs MAY include other
    hash values. Clients MUST compute a one-way hash value using one of
    the identified functions, and clients MUST discard the logotype data
    if the computed hash value does not match the hash value in the
    certificate extension.

  This paragraph is doing too much work at once and mixing up (or
  forgetting about) what it's talking about.  LogotypeReference doesn't
  refer to "image or audio objects" -- it refers to a LogotypeData
  object.  But of course LogotypeDetails *does* refer to image or audio
  objects, but not to LogotypeData objects.  Likewise, the last sentence
  seems to imply that hash mismatch should trigger rejection only for
  LogotypeReferences ("discard the logotype data") but not for
  LogotypeDetails.

  Functionally, it also seems to imply that an object should be rejected
  when any hash doesn't match, but verification terminates successfully
  when any hash tried does match.  The implication here is that when
  multiple hashes are offered, and some of them are miscalculated, the
  rejection or acceptance will depend on the order in which the client
  tries the hashes.  the outcome would be more stable if the requirement
  was either "try all hashes you have an implementation for, accept if
  one of them matches" or "try all hashes you have an implementation
  for, reject if one of them doesn't match".  Then the outcome for a set
  of mismatched hashes will only vary based on which hashes are
  implemented, not on the implementation's choice of ordering.

y) section 6 ("Use in Clients") says:

     The logotype is to be displayed in conjunction with other identity
     information contained in the certificate. The logotype is not a
     replacement for this identity information.

   but section 4.4.3 ("Certificate Image Logotype") says:

     Applications providing a Graphical User Interface (GUI) to the
     certificate user MAY present a certificate image according to this
     standard in any given application interface, as the only visual
     representation of a certificate.

   These seem to be in direct contradiction to one another.

z) section 3 "logotype data" says:

     Compliant applications MUST NOT display more than one of the image
     objects and MUST NOT play more than one of the audio object for any
     logotype type at the same time.

     A client MAY simultaneously display multiple logotypes of different
     logotype types. For example, it may display one subject
     organization logotype while also displaying a community logotype,
     but it MUST NOT display multiple image variants of the same
     community logotype.

   but section 4.4.1 ("loyalty logotype") says "The logotype extension
   MAY contain more than one Loyalty logotype." and section 4.1 also
   says:

      If more than one Community logotype is present, they MUST be
      placed in order of preferred appearance. Some clients MAY choose
      to display a subset of the present community logos; therefore the
      placement within the sequence aids the client selection. The most
      preferred logotype MUST be first in the sequence, and the least
      preferred logotype MUST be last in the sequence.

   This is pretty unclear.  It sounds like multiple logotypes of the same
   type can be displayed, but also only one logotype of any given type
   can be displayed.

zz) section 4.4.2 says

    "The logotype extension MUST NOT contain more than one certificate
    background logotype."

   But section 4.4.3 doesn't offer any such constraint for the
   "Certificate Image" logotype.  Surely it should have the same
   constraint?

   While we're looking at it, does "logotype" in the cited sentence
   refer to a LogotypeDetails, a LogotypeData, a LogotypeImage, a
   LogotypeReference, some combination, or something else?

zzz) The draft should have distinct subsections for each logotype type,
     as well as for each otherType OID.  This will make it easier to
     refer to things in the future.

OK, i'm past out of letters, so i'll stop now.  Sorry for the volume of
this message.  I think this draft still needs a lot of work,
unfortunately.

I appreciate your working on it.

   --dkg