Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services
Hi there, > On 19. May 2020, at 19:55, Nick Mathewson wrote: > If we do decide to finally deprecate v2 onion services, that would be > a significant maintenance burden reduced for us, but we'd have to > handle the transition carefully. Unlike all the other migrations > we've done, there isn't a drop-in path to get the same functionality > or keep the same identities with v3 onion services. (And the problem > is that there _can't_ be: the identities are strongly tied to > 80-bit-truncated-SHA1 and RSA-1024, and the lack of key blinding makes > them enumerable.) I would be exstatic about not having V2 onions around anymore. This would reduce a huge attack vector that incentivizes people to set up malicious relays, which causes huge amounts of time lost, the relays shouldn't have this opportunity to harvest onions, etc. > The main reason I wrote this proposal is this: Any deprecation will > probably cause a few users to stick with the old versions of the code > for as long as they still work on the network, even if those versions > become unsupported and insecure. (After all, people who listen to our > advice about what is secure and what isn't have already stopped using > v2 onion services.) . I kind of don't buy the statement in the parentheses, we don't seem to discourage v2 strongly at all afaict. Or is there a warning when you use it or connect to it, for example? A question, is the HSDir flag for both v2 and v3 onions? If not we could just take that away to break v2 at some point. > Is it time to start this deprecation? If so we need to start working > on a timeline, and I agree with Teor that we'd need to figure out how > that timeline would work with any walking onions timeline. I think it should have been started a while ago :) > What do others think? Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services
On Wed, May 13, 2020 at 10:09 AM David Goulet wrote: > > On 11 May (16:47:53), Nick Mathewson wrote: > > Hello! > > > ``` > > Filename: 320-tap-out-again.md > > Title: Removing TAP usage from v2 onion services > > Author: Nick Mathewson > > Created: 11 May 2020 > > Status: Open > > ``` > > > > (This proposal is part of the Walking Onions spec project. It updates > > proposal 245.) > > > > # Removing TAP from v2 onion services > > > > As we implement walking onions, we're faced with a problem: what to do > > with TAP keys? They are bulky and insecure, and not used for anything > > besides v2 onion services. Keeping them in SNIPs would consume > > bandwidth, and keeping them indirectly would consume complexity. It > > would be nicer to remove TAP keys entirely. > > > > But although v2 onion services are obsolescent and their > > cryptographic parameters are disturbing, we do not want to drop > > support for them as part of the Walking Onions migration. If we did > > so, then we would force some users to choose between Walking Onions > > and v2 onion services, which we do not want to do. > > I haven't read the entire proposal so I won't comment on its technical aspect. > I was reading and got here and that made me very uncertain about the whole > proposal itself. > > I will propose that we revisit the overall idea of changing v2 here. > > I personally think this is the wrong approach. Onion services v2 should be > deprecated as in removed from the network instead of being offered as a choice > to the users. > > We haven't properly done a deprecation path yet for v2 primarly due to our > lack of time to do so. But at this point in time, where the network is 100% > composed of relays supporting v3 now (which took 3+ years to get there), it is > time for v2 to not be presented as a choice anymore. > > It is a codebase that is barely maintained, no new features are being added to > it and thus moving it to ntor means another at least 3 years of network > migration. This would mean a major new feature in that deprecated code base... > > So thus, I personally will argue that moving v2 to ntor is really not the > right thing to do. Onion service v2 are, at this point in time, _dangerous_ > choice for the users. Hi, David! I'm sympathetic to this point of view: I certainly don't like carrying around old code either. If we do decide to finally deprecate v2 onion services, that would be a significant maintenance burden reduced for us, but we'd have to handle the transition carefully. Unlike all the other migrations we've done, there isn't a drop-in path to get the same functionality or keep the same identities with v3 onion services. (And the problem is that there _can't_ be: the identities are strongly tied to 80-bit-truncated-SHA1 and RSA-1024, and the lack of key blinding makes them enumerable.) The main reason I wrote this proposal is this: Any deprecation will probably cause a few users to stick with the old versions of the code for as long as they still work on the network, even if those versions become unsupported and insecure. (After all, people who listen to our advice about what is secure and what isn't have already stopped using v2 onion services.) . Is it time to start this deprecation? If so we need to start working on a timeline, and I agree with Teor that we'd need to figure out how that timeline would work with any walking onions timeline. One possible role for this proposal is to be kept in reserve, in case somebody feels so strongly that they want v2 services to work that they want to maintain them themselves, or pay for somebody else to do it. If so, we can indicate this proposal as "the right way to keep v2 services working without TAP", make it clear that we don't plan to implement it, and move along. There are other ways to keep TAP working with walking onions, but they seem kludgey too, and would also require implementation changes for v2 onion services. What do others think? -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services
On Mon, May 11, 2020 at 8:52 PM teor wrote: > > Hi Nick, > > > On 12 May 2020, at 06:48, Nick Mathewson wrote: > > > > ## Migration steps > > > > First, we implement all of the above, but set it to be disabled by > > default. We use torrc fields to selectively enable them for testing > > purposes, to make sure they work. > > Can you expand on the testing plan here? > > One of the risks with multi-year migration projects is that unrelated > changes break the migration, and we don't notice. > > For example, you might need to create a chutney network for each > stage, and run them on every pull request and merge. In our current > CI, that's 30-60 seconds of extra time per network, or 2-4 extra > minutes of CI time. > > If you need to test different combinations of features for each stage, > let's try to do that in the same networks. Otherwise, the testing matrix > expands out very quickly. I agree here think that the right approach here is to test for the various ways that we expect the network to exist at a time. The trickiest stage of the migration will be the one where some services support ntor keys and some don't, some clients do and some don't. If we add a chutney network for that case specifically and make sure that all clients can reach all services, we should be fine here. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 319: RELAY_FRAGMENT cells
On Thu, May 14, 2020 at 3:15 PM David Goulet wrote:
>
> On 11 May (16:47:24), Nick Mathewson wrote:
[...]
> > # Onion service concerns.
> >
> > We allocate a new extension for use in the ESTABLISH_INTRO by onion
> > services,
> > to indicate that they can receive a wide INTRODUCE2 cell. This extension
> > contains:
> >
> > struct wide_intro2_ok {
> > u16 max_len;
> > }
> >
> > We allocate a new extension for use in the `ESTABLISH_RENDEZVOUS`
> > cell, to indicate acceptance of wide `RENDEZVOUS2` cells. This
> > extension contains:
> >
> > struct wide_rend2_ok {
> > u16 max_len;
> > }
> >
> > (Note that `ESTABLISH_RENDEZVOUS` cells do not currently have a an
> > extension mechanism. They should be extended to use the same
> > extension format as `ESTABLISH_INTRO` cells, with extensions placed
> > after the rendezvous cookie.)
>
> Why would a client need to announce wide cells in the ESTABLISH phase as
> opposed to using protover "Relay=N" ?
This is not for announcing support of wide cells -- this is for
reporting a setting for how wide fragmented cells should be.
> The maximum length of a fragmented cell is capped to 2^16 (u16) so we don't
> really need the establish process to inform us of the maximum expected length
> but rather use the max_len in the first fragment?
This all comes back to an earlier part of the proposal:
Not all lengths up to 65535 are valid lengths for a fragmented
cell. Any length under 499 bytes SHOULD cause the circuit
to close, since that could fit into a non-fragmented RELAY cell.
Parties SHOULD enforce maximum lengths for cell types that
they understand.
In other words, I'm imagining that there is a maximum length for each
cell type that is much shorter than 65535, even though we're using two
bytes for the length field.
The extension in the establish_intro cell is to tell the intro point
the longest introduce1 cell that it should accept; this extension in
the establish_rend cell is to tell the rendezvous point the longest
rendezvous1 cell that it should accept.
Another way we could do this would be with a set of network parameters
to describe the maximum length of each fragmented cell. Do you think
that would be simpler?
(I can't quite remember why I specified it this way in the first place.)
> Furthermore, ESTABLISH_INTRO has extensions (only 1 as of today) so they could
> also be fragments themselves and thus I'm not sure I see the point of having
> two different ways of "expecting" fragments for the ESTABLISH_* cells and the
> INTRO/RENDEZVOUS cells?
The difference thing here is that everybody can tell which protocols
that a relay supports, but there is no automatic way to tell which
protocols an onion service or client supports. Since
INTRODUCE2/RENDEZVOUS2 cells are handled by these clients, they need
to get opted into by the relays.
(I'm not sure I understood the question completely.)
> > # Compatibility
> >
> > This proposal will require the allocation of a new 'Relay' protocol version,
> > to indicate understanding of the RELAY_FRAGMENTED command.
>
> Here is a thought about a DoS vector. Here goes:
>
> As an upper limit of 65KB total fragment size, it represents ~126 cells in
> total so I could basically send *125* cells and then stop which will put in
> memory a bit more than 64KB and it will stay there until the last fragment is
> received.
>
> And then I do that on 1000 different circuits bringing the total count in
> memory to 64GB. All stuck there, all "waiting" for the last fragment.
>
> Our OOM would kick in killing circuits but it just seems to me a very easy way
> to continously kick the OOM of a _service_ which is pretty bad side channel.
A few responses here:
First, we shouldn't allow 65535-byte fragmented cells. The actual
maximum length should be something more like 1024 or 4096 bytes.
Second, we should make sure that when we are reassembling cells, we
use the same buf_t buffers that we use for other stuff. Our buffers
are timestamped, so we can tell which buffer has had data stalling for
the longest, and we should use that to make sure we're killing off the
right circuits preferentially.
Third, fragments should only be allowed at an onion service for
INTRODUCE2, and those should only come one at a time from each
introduction point, so the number that it's reassembling at the time
will be limited by the number of intro circuits it has open. It'll be
the the intro points that have to be keeping a bunch of cells in
assembly at once, and be ready to kill off circuits that dawdle too
long.
Does this make more sense? If so I'll try to clarify it in the proposal.
--
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
