Filename: 360-hsdesc-len-limit.md
Title: Limiting HSDesc size and amplification
Author: Nick Mathewson
Created: 8 April 2025
Status: Open

Introduction

Certain side-channels arise from possibility of creating unusually large onion service descriptors ("HSDescs"), or using a great many cells to transmit onion service descriptors over the network.

This proposal describes a set of protocol changes to limit an attacker's capability of carrying out these attacks.

For more background, see the relevant part of proposal 349. The mitigations discussed here are based on the ideas presented in that section.

Summary

We introduce new limits on the permissible size of an HSDesc. This limit will be declared in consensus documents, enforced by well-behaved relays, and double-checked by clients.

In order to limit inflation attacks, this limit will be enforced not only on HSDescs themselves, but on the DATA messages used to transmit them.

Details

There is a new consensus parameter, hsdesc_maxlen. It defines the maximum length in bytes of an HSDesc. Its minimum is 1 KiB; its maximum is 256 KiB. It defaults to 50 KiB.

50 KiB was chosen as the default because it is the current value of HS_DESC_MAX_LEN in C Tor.

Enforcing HSDesc lengths.

HSDirs MUST NOT accept any HSDesc longer than hsdesc_maxlen.

Onion services MUST NOT try to publish any HSDesc longer than this value.

If a client receives more bytes than this in response to an HSDesc request, it SHOULD close the circuit with a warning. The warning SHOULD include the identity of the HSDir that served the invalid information.

Since existing HsDir implementations only enforce a 50 KiB maximum, clients MAY consider the declared version of the HsDir when deciding how to warn.

Limiting in-request HSDesc extension

Clients SHOULD detect the presence of extra information at the end of an HSDesc reply, beyond the signed data. If any extra information is present, the client SHOULD issue a warning. The warning SHOULD include the identity of the HSDir that served the invalid information.

Limiting HSDesc reply extension

There are two new consensus parameters. hsdir_dl_max_reply_cells and hsdir_ul_max_reply_cells.

hsdir_ul_max_reply_cells is the maximum number of allowable relay cells to receive in a reply on an HSDir circuit used to upload an HsDesc. Its minimum is 1. Its maximum is 1024. Its default is 8.

hsdir_dl_max_reply_cells is the maximum number of allowable relay cells to receive in a reply on an HSDir circuit used to download an HsDesc. Its minimum is 1. Its maximum is 1024. Its default is 110.

Note: These maxima apply to all relay cells, not just those containing DATA messages.

Note also: we should investigate better maxima here. I've chosen this one based on dividing hsdesc_maxlen by our maximum DATA payload length, and adding a few extra for slop.

Possibly, we could instead formalize these maxima as a function of hsdesc_maxlen.

These limits are chosen such that a well-behaved HsDir will not send more than the specified number of cells when delivering an HsDesc.

Clients SHOULD count the total number of inbound cells received on every HSDir circuit from the final hop.

If more than the limited number of cells above is received, the client SHOULD issue a warning and close the circuit. The warning SHOULD include the identity of the HSDir that served the invalid information.

Acknowlegments

This proposal follows directly from ideas by Mike Perry. The mistakes and misunderstandings are my own.