Draft RFC: Cryptographic Hyperlinks (2021) | Hacker News Reader

Draft RFC: Cryptographic Hyperlinks (2021)

datatracker.ietf.org

47 pointswesturner22 comments

Just a note that this is an "Internet Draft", without any particular standards status. I.e., anyone can submit an I-D and the IETF will publish it.

As a general matter, if you see a document with the name "draft-ietf-<something>" that means it's been accepted by an IETF WG and so is potentially on its way to being an RFC (though of course some documents never make it). If it is named "draft-<someones-name>-<something>" then it's just a document someone submitted. That doesn't make it bad: most RFCs start this way, but it just means it's not anything the IETF is officially working on. This document is "draft-sporny" and AFAIK, no IETF WG has taken it up.

This is something that often confuses people about the IETF, so hopefully this helps.

That's true. However, I also note this:

   This specification is a work product of the W3C Digital Verification
   Community Group [1] and the W3C Credentials Community Group [2].
   Feedback related to this specification should be logged in the issue
   tracker [3] or be sent to public-credentials@w3.org [4].

So, while it isn't (at least thus far) an IETF WG RFC, it comes from a W3C "Community Group" – which is a step below even a W3C Working Group, yet simultaneously a step above "J. Random Hacker has some idiosyncratic ideas and decides to upload them as an Internet Draft" or even "MegaCorp has invented a proprietary standard to meet the specific needs of their product and now wants it published unchanged as an RFC to give them an advantage over their competitors"

Also worth noting us that the latest version of this draft (07) expired more than a year ago - November 3, 2021. The authors have not published a new version nor being able to get it moved forward through the IETF process.

This camps on the q-param namespace that normally belongs to the application. I'm shocked this would be considered. The only way to do this without camping on the q-param or fragment namespaces is via a new URI scheme, but then that would be very difficult to deploy anytime soon.

This is a quandary that is usually resolved by camping on the namespace, yes, but with some very unlikely name (think of the IDNA xn-- A-label prefix).

Also, there is some value to doing this via a fragment identifier as an alternative: you can distribute the link with the digest, but the server you request the link from doesn't get to know what digest you have. This could be useful for immutable resources. Also, maybe the request for a particular version identified by a particular digest could be done with an HTTP header, which then lends itself to making for a conditional request ("GET /this/thing, but only if it has different digest than I last saw"), which, again, would best be done using a fragment identifier if we're not going to do a new URI scheme.

My preference is still for a new URL scheme, much like the data URI scheme.

I suppose the conditional request thing is silly because it already exists with `If-Match`/`If-None-Match` and ETags.

This hashlink spec seems to duplicate the existing Named Information (ni:) URI scheme (RFC6920), as well as widely deployed non-standard solutions, namely magnet: URI's. These don't seem to currently support the Multihash format that's recommended here, but could easily be extended/amended to that effect. Not seeing the point of this.

Neither RFC6920 nor magnet: URIs appear to support the "just add a url parameter with the hash to the existing URL" use case, FWICS.

CAS Content-addressable storage: https://en.wikipedia.org/wiki/Content-addressable_storage#Op... : IPFS <CID>/path

RFC6920: https://www.rfc-editor.org/rfc/rfc6920.html

Magnet URI scheme: https://en.wikipedia.org/wiki/Magnet_URI_scheme

draft-sporny-hashlink-07 2021: https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-... :

  <url>?hl=<resource-hash>

The URL-parameter method is application-specific though, not sure it’s very useful to have a standard for that. Applications can just use whatever parameter name makes sense for them plus an existing hash/CAS encoding for the value.

How else can browsers check the hash of a file downloaded over HTTPS?

The main focus of the draft RFC is to define a new "hl" hashlink URL scheme. This doesn't necessariy target browsers, though they could certainly choose to support that scheme. The URL-parameter encoding, which is not the recommended encoding, is merely for "existing applications utilizing historical URL schemes", which may or may notinclude browsers. The draft explicitly states: "Implementers should take note that the URL parameter-based encoding mechanism is application specific and SHOULD NOT be used unless the URL resolver for the application cannot be upgraded to support the RECOMMENDED encoding."

What is the likelihood that all existing resolvers will be updated to support schemes in addition to HTTP:// and HTTPS:// instead of happening to support a less-than-uniquely-named URL parameter?

For a bit of history, this type of thing has been around a very long time:

https://lists.w3.org/Archives/Public/www-talk/2001NovDec/009...

HTTP SRI Subresource Integrity allows for specifying which cryptographic hash is presented, like ld-proofs has a "future-proof" signatureSuite attribute : https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

> Subresource Integrity with the <script> element

> You can use the following <script> element to tell a browser that before executing the https://example.com/example-framework.js script, the browser must first compare the script to the expected hash, and verify that there's a match.

  <script
    src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

  [...]

  Note: An integrity value may contain multiple hashes separated by whitespace. A resource will be loaded if it matches one of those hashes

To create a SHA384 SRI HTTP resource hash for the integrity= attr:

  cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

(Assuming this is not already solved in a way I do not know...) Extending your example, would it be possible to have:

    <a
    href="https://example.com/data.bin"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    >link</a>

I think this would be useful to have the browser check the integrity of the linked content, rather than asking the user to do it. You could have the hashsum being performed as the file is being downloaded.

I think we would then want to the browser to indicate that the link actually has this integrity check, although it would be difficult to do in a way that cannot be easily spoofed. You could have something happen on hover over, but this won't work for touch devices.

Adding support for the he integrity= SRI attribute on <a> tags probably does make sense.

Copying and pasting doesn't copy integrity= node attribute, but does copy URL query arguments and URI fragments.

Outside of the web, I already use a tool called HashCache [0][1] to ensure that I can repeatedly fetch the right upstream source tarball for a Linux distribution I maintain. A simple script I use to download is here [2], and example usage is here [3]

This has the advantage of being pretty transparent and self-maintaining. The disadvantage is that it doesn't work for things that are dynamic (duh) or not serialized.

[0] https://hashcache.rkeene.org/ [1] https://chiselapp.com/user/rkeene/repository/hashcache/ [2] https://kitcreator.rkeene.org/fossil/artifact?udc=1&ln=on&na... [3] https://appfs.rkeene.org/web/artifact/22239c774b50efa6

On the HTML level I would think of something like Subresource Integrity[1]:

  <a href="https://example.com/hw.txt" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC">Hello World</a>

This already exists for the <script> and <link> elements and could probably be added to the <a> element. The primary usecase would probably be downloads, but it could also be interesting for regular links to other HTML pages. You could get an error page similar to the one with invalid TLS certificates.

The main issue I see is that all this would be gone if you simply "Copy Link".

[1]: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Instead of

    http://example.org/hw.txt?hl=zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e

why not just let the url be the hash?

    http://example.org/zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e

Servers should return Content-Disposition (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...) for the filename

Assuming that hash is base64 encoded, this solution would conflict with RFC 2616 (and this approach caused Let's Encrypt to fail sometimes too [0] !)

[0] https://community.letsencrypt.org/t/may-19-2017-ocsp-and-iss...

  ### 1.1.  Multiple Encodings

   A hashlink can be encoded in two different ways, the RECOMMENDED way
   to express a hashlink is:

   hl:<resource-hash>:<optional-metadata>

   To enable existing applications utilizing historical URL schemes to
   provide content integrity protection, hashlinks may also be encoded
   using URL parameters:

   <url>?hl=<resource-hash>

   Implementers should take note that the URL parameter-based encoding
   mechanism is application specific and SHOULD NOT be used unless the
   URL resolver for the application cannot be upgraded to support the
   RECOMMENDED encoding.

  [...]

  #### 3.2.1.  Hashlink as a Parameterized URL Example

   The example below demonstrates a simple hashlink that provides
   content integrity protection for the "http://example.org/hw.txt"
   file, which has a content type of "text/plain":

   http://example.org/hw.txt?hl=
   zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e

Magnet links already exist...

"This Internet-Draft will expire on November 3, 2021."

Oh. Never mind then.

Reply on news.ycombinator.com