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

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

On Wed 2022-03-30 13:46:51 +0200, Stefan Santesson wrote:
> 1) This is not a new design:
>
> This is not a new standard we are designing. If I was designing this
> extension today, my approach would be much more pragmatic and I would
> simplify this quite a bit. But that is not a luxury we have. The purpose
> of this update is to merge 2 existing RFC:s and basically get rid of
> mandatory use of SHA-1. That's it.
>
> Therefore, even how much I can agree on structural issues on the design,
> we have to stick with it, or alternatively stop this update and let the
> old RFC:s keep living instead.

Thanks for this clarification of the constraints.  I understand them,
and i'm not asking to actually change the structure of the wire format
objects.

I very much appreciate the move from SHA-1 to the digest algorithm used
in the signature -- that strikes me as the right approach.  But it also
occurs to me that i don't know whether all possible future signature
X.509 certificates will even have a "one-way hash function associated
with the certificate signature" -- maybe the draft can describe an
algorithmic way to identify the one-way hash algorithm in question?  I
mean, i know that a Certificate's signatureAlgorithm field
AlgorithmIdentifier OID of sha256WithRSAEncryption (1 2 840 113549 1 1
11) maps to id-sha256 (2 16 840 1 101 3 4 2 1).  But i don't know for
certain that all possible Certificate.signatureAlgorithm
AlgorithmIdentifiers have a well-defined hash.

Is there a straightforward mapping from the
Certificate.signatureAlgorithm AlgorithmIdentifier to
HashAlgAndValue.hashAlg AlgorithmIdentifier?

More work is needed here for a variety of different reasons that don't
touch the bits on the wire:

The document is internally-contradictory at several points; the text is
frequently unclear; the title and introduction don't offer a
straightforward description of what is provided; there are at least two
serious security considerations (the phishing attack that i outlined;
the risks of large attack surface of polymorphic image or audio
renderers) that are not discussed; there are multiple privacy
considerations that are not discussed; the examples are not easy to use
to confirm interoperability.

An update represents the opportunity to resolve *all* of these issues
without affecting the bits on the wire at all.  The point of these
specfications is to provide clarity for implementers so that we get a
robust, secure, interoperable ecosystem, right?

> 2) Privacy concerns
>
> On the privacy issues, I don't say that we should add some well thought
> out sentences in a privacy considerations section. I personally do not
> feel qualified enough to do it. I would welcome a few sentences that
> would do the job that we could include in this draft.

I don't think that a few sentences are sufficient to address the privacy
considerations raised by these mechanisms in today's network
environment.  Some text and some framing will need to change at the very
least.

If it turns out that a clearer understanding of the privacy concerns
happens to also spur ideas for a backward-compatible extension of the
wire format to make it cheaper/easier to embed the media directly, that
would be an elegant outcome but i won't hold my breath on that.

> 3) Mime type for LogotypeData
>
> I see no advantages of registering a mime type for this. As the expected
> structure of the referenced data is known, and must be validated anyway
> both i terms of content and structure, I'm not helped by learning what
> mime type the server provides in HTML. I will simply extract the bytes
> of the data, validate it against the hash and then attempt to parse it
> as DER encoded LogotypeData.
>
> Clients should disregard any mime type declarations and should not fail
> because this header is not set as expected.

In this case, i agree with you -- the client can probably ignore the
server's offered media type, or at least accept an
application/octet-stream media type.

But if the server says "this is an image/png" when you're expecting a
DER-encoded LogotypeData, shouldn't a defensively-programmed system
reject the HTTP response?

That doesn't mean that we shouldn't register a media type for this
specific format, though.  Media type registration is a mutual aid sort
of situation.  For example, there may be implemetnations of other
protocols that expect some other data types, and they themselves might
do ugly things if they receive a DER-encoded LogotypeData instead.

By defining and encouraging an explicit label of what sort of data the
HTTP server is emitting, we can help isolate these protocols from each
other.

Is there a specific objection to registering the media type?  As far as
i can tell, media type registrations have no cost, and this looks to me
like a very well-defined binary format, with a clear reference that the
media type registration can point to.  what would be the downside?

> 4) The rest.
>
> I feel bad that I don't provide detailed responses to all the effort you
> put into this, but I have to save that to later. Better to provide a
> quick response than no response. But if any of my comments would change
> the way you feel about things you just posted, it would make it easier
> to respond to them.

I understand, and i don't expect repsonses or fixes to each point all at
once-- there are a lot of issues that need fixing, unfortunately, and
it's easy for some to get lost in this back-and-forth format, despite my
trying to give each distinct issue a separate identifier.

Anyway, i appreciate your giving a prompt response, and i'm game to help
work through the details if you're interested in my help.

If you want to make collaboration easier, i'll reiterate my
recommendation for revision control of the document's markdown source
and an issue tracker.

I set up https://gitlab.com/dkg/lamps-rfc3709bis and populated the repo
with the markdown source from the first three drafts as an example of
how that kind of collaboration could work if you're interested.  Pushes
to the main branch there will automatically update a putative "editor's
copy" at https://dkg.gitlab.io/lamps-rfc3709bis/ after a few minutes.

If you want to use this repo, please let me know what your gitlab handle
is and i'll add you as an owner to that group.  I can then work on
transferring the points i raised into specific issues, which we can then
try to fix.

If you have a different way that you'd prefer to keep track of
outstanding issues and work through their fixes, let me know and i can
try to populate it with the concerns that i've found.

All the best,

    --dkg