Hacker News Reader

Comment by zozbot234 | Hacker News Reader

Is this intended to include the featureset of Signed HTTP Exchanges (SXG) as well?

I was wondering how much overlap the two technologies have too.

What I'd really like to see supported is a way for a web app to specify a public key and a version number, and for the browser to then prompt you every subsequent time you access that page if the key or version number has changed. This would effectively allow web apps to use the same security model as desktop apps, i.e. TOFU.

Arguably, though, auto-updating desktop apps are less secure than even TOFU, but I don't know users can be expected to judge whether v1.2.3 is more secure than v1.2.2, so perhaps the prompt doesn't provide any practical benefit.

Is this solveable by including a cache key in the URL or other client-side storage?

Well, there is the SecureBookmarks trick[0], which uses integrity hashes and Data URLs, so you're right that signatures aren't strictly needed (especially at the HTTP level). I think the difficult part is the UX, and how to handle the failure modes, which is why browsers might reasonably be reluctant to support something like this.

[0] https://github.com/coins/secure-bookmark

Are there additional HTTP status code-like error codes that need to be specified?

What [same origin, SXG,] failure modes are there?

From "HTTP 402: Payment Required" https://news.ycombinator.com/item?id=22214156 :

> The new W3C Payment Request API [4] makes it easy for browsers to offer a standard (and probably(?) already accessible) interface for the payment data entry screen, at least.

> https://www.w3.org/TR/payment-request/

The failure modes I was imagining are things like what happens if you visit a site and it is no longer serving signed content any more, or it's serving content signed by a key you haven't seen before? Either the user needs to be able to decide (based on information received out-of-band) which keys to trust, or you have to trust a site to never lose control of its keys (which reintroduces all the problems of HPKP, like ransoming).

Even in the happy path, there are questions of how you present to the user that the content has been signed (and by which key), separately from the guarantees that the TLS transport gives. Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app?

You said HPKP and I misread it

Re: HKP, WKD, GPG Linked Data signatures, Keybase+Zoom and ACME https://westurner.github.io/hnlog/#comment-28814802

https://westurner.github.io/hnlog/#comment-26127879

Ctrl-F "trillian" re: CT cert grant and revocation events on a blockchain

> Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app?

blockcerts/cert-verifier-js ?

> Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app?

There do need to be standards for displaying such errors and requesting key verification in the browser. e.g. DNSSEC and DoH/DoT errors should also propagate up to the browser eh? How do web3 browsers handle keychains?

https://github.com/blockchain-certificates/cert-verifier-js#...

From (an obscure comment with pictures on) "Roadmap update for TUF support " https://github.com/pypa/warehouse/issues/5247#issuecomment-9... :

> Only users with package release permissions can create a new SoftwareRelease record for that project

You can log hashes to sigstore now, which is a centralized db supported by The Linux Foundation. https://sigstore.dev/ :

> How sigstore works: sigstore is a set of tools developers, software maintainers, package managers and security experts can benefit from. Bringing together free-to-use open source technologies like Fulcio, Cosign and Rekor, it handles digital signing, verification and checks for provenance needed to make it safer to distribute and use open source software.

> A standardized approach: This means that open source software uploaded for distribution has a stricter, more standardized way of checking who’s been involved, that it hasn’t been tampered with. There’s no risk of key compromise, so third parties can’t hijack a release and slip in something malicious.

> Building for future integrations: With the help of a working partnership that includes Google, the Linux Foundation, Red Hat and Purdue University, we’re in constant collaboration to find new ways to improve the sigstore technology, to make it easy to adopt, integrate and become a long-lasting standard.

But then DIDs and ld-proofs (with at least the current trust root in a trustless DLT of some sort) are even more standardized.

Software Releases, [Academic, Professional, Medical,] Credentials, Legal Documents, Server Certs, ScholarlyArticles: all of these things can be signed and may already be listed in the Use Cases documents for W3C DID Decentralized Identifiers [1] and W3C VC Verifiable Credentials [2] which are summarized in context to Keybase here: https://news.ycombinator.com/item?id=28814802

[1] https://www.w3.org/TR/did-use-cases/

[2] https://www.w3.org/TR/vc-use-cases/

Notably: DNSSEC errors do not propagate up to the browser; when DNSSEC fails, sites simply fall off the Internet as if they never existed. It's a major fault of the DNSSEC design.

Unfortunately, because all domains don't yet have DNSSEC DNS records, a strict resolver that requires DNSSEC signatures will fall to resolve all domains unless it's configured to e.g. "allow-downgrade" to non-DNSSEC-signed records for any lookup.

FWIR, the same is basically true of DoH and DoT: if it's not configured to ~allow-downgrade, DNS will fall to resolve when connected to e.g. a captive portal hotspot; and there's no indication that DoH/DoT aren't working in the browser.

How do DNS resolution APIs need to change to accommodate basic DNSSEC and DoH/DoT error handling?

DoH and DoT don't have the same failure modes as DNSSEC --- a TLS failure during a DoH lookup is much more likely to actually be the result of a break in the chain of trust than a DNSSEC failure is.

What fields are there in the error structs?

FWIU, Status quo: In browsers we have:

- a broken lock icon, a cert failure error page for manual error resolution, and a cert information dialog

From https://news.ycombinator.com/item?id=28543911 :

```

From https://blog.cloudflare.com/automatic-signed-exchanges/ :

> The broader implication of SXGs is that they make content portable: content delivered via an SXG can be easily distributed by third parties while maintaining full assurance and attribution of its origin. Historically, the only way for a site to use a third party to distribute its content while maintaining attribution has been for the site to share its SSL certificates with the distributor. This has security drawbacks. Moreover, it is a far stretch from making content truly portable.

> In the long-term, truly portable content can be used to achieve use cases like fully offline experiences. In the immediate term, the primary use case of SXGs is the delivery of faster user experiences by providing content in an easily cacheable format. Specifically, Google Search will cache and sometimes prefetch SXGs. For sites that receive a large portion of their traffic from Google Search, SXGs can be an important tool for delivering faster page loads to users.

> It’s also possible that all sites could eventually support this standard. Every time a site is loaded, all the linked articles could be pre-loaded. Web speeds across the board would be dramatically increased.

"Signed HTTP Exchanges" draft-yasskin-http-origin-signed-responses https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

"Bundled HTTP Exchanges" draft-yasskin-wpack-bundled-exchanges https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle... :

> Web bundles provide a way to bundle up groups of HTTP responses, with the request URLs and content negotiation that produced them, to transmit or store together. They can include multiple top-level resources with one identified as the default by a primaryUrl metadata, provide random access to their component exchanges, and efficiently store 8-bit resources.

From https://web.dev/web-bundles/ :

> Introducing the Web Bundles API. A Web Bundle is a file format for encapsulating one or more HTTP resources in a single file. It can include one or more HTML files, JavaScript files, images, or stylesheets.

> Web Bundles, more formally known as Bundled HTTP Exchanges, are part of the Web Packaging proposal.

> HTTP resources in a Web Bundle are indexed by request URLs, and can optionally come with signatures that vouch for the resources. Signatures allow browsers to understand and verify where each resource came from, and treats each as coming from its true origin. This is similar to how Signed HTTP Exchanges, a feature for signing a single HTTP resource, are handled.

```

Reply on news.ycombinator.com