On 17 Oct (13:35:24), George Kadianakis wrote:
> George Kadianakis <desnacked@xxxxxxxxxx> writes:
>
> > [ text/plain ]
> > Hello,
> >
> > we've reached the point in prop224 development where we need to pin down
> > the precise cell formats, so that we can start implementing them. HS
> > client authorization has been one of those areas that are not yet
> > finalized and are still influencing cell format.
> >
> > Here are some topics based on special's old notes, plus some further
> > recent discussion with David and Yawning.
> >
>
> Hello again,
>
> I read the feedback on the thread and thought some more about this. Here
> are some thoughts based on received feedback. A torspec branch coming
> soon if people agree with my points below.
>
> I'd also like to introduce a new topic of discussion here:
>
> d) Should we introduce the concept of stealth auth again?
>
> IIUC the current prop224 client auth solutions are not providing all
> the security properties that stealth auth did. Specifically, if Alice
> is an ex-authorized-client of a hidden service and she got revoked,
> she can still fetch the descriptor of a hidden service and hence
> learn the uptime/presense of the HS. IIUC, with stealth auth this was
> not previously possible.
I think this has value if client revocation is a something that actually
happens and the operator wants that revoked client to NEVER know anything
about the service anymore.
My guts tells me that it might be a very small portion of operators that do
that and have concerns on hidding the service. I could be wrong so we can try
to ask around on our public channels and see what's the response.
I can see this feature being added _after_ deployment as well.
>
> > a) I think the most important problem here is that the authorization-key logic
> > in the current prop224 is very suboptimal. Specifically, prop224 uses a
> > global authorization-key to ensure that descriptors are only read by
> > authorized clients. However, since that key is global, if we ever want to
> > revoke a single client we need to change the keys for all clients. The
> > current rend-spec.txt does not suffer from this issue, hence I adapted the
> > current technique to prop224.
> >
> > Please see my torspec branch `prop224_client_auth` for the proposed changes:
> > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth
> >
> > Some further questions here:
> >
> > i) Should we fake the client-auth-desc-key blob in case client authorization
> > is not enabled? Otherwise, we leak to the HSDir whether client auth is
> > enabled. The drawback here is the desc size increase (by about 330 bytes).
> >
> > Alternatively, we can try to put it in the encrypted part of the
> > descriptor. So that we require subcredential knowledge to access the
> > encrypted part, and then client_auth_cookie knowledge to get the
> > encryption key to decrypt the intro points etc. I feel that this
> > double-encryption design might be too annoying to implement, but perhaps
> > it's worth it?
> >
>
> Seems like people preferred the double-encryption idea here, so that we
> reveal the least amount of information possible in the plaintext part of
> the desc.
>
> I think this is a reasonable point since if we put the auth keys in the
> plaintext part of the descriptor, and we always pad (or fake clients) up
> to N authorized clients, it will be obvious to an HSDir if a hidden
> service has more than N authorized clients (since we will need to fake
> 2*N clients then).
>
> ---
>
> WRT protocol, I guess the idea here is that if client auth is enabled,
> then we add some client authorization fields in the top of the encrypted
> section of the descriptor, that can be used to find the client-auth
> descriptor encryption key. Then we add another client-auth-encrypted
> blob inside the encrypted part, which contains the intro points etc. and
> is encrypted using the descriptor encryption key found above.
Well, I would only encrypt the key that was used to encrypt the introduction
points but I'm sure this is what you meant!
>
> So the first layer is encrypted using the onion address, and the second
> layer is encrypted using the client auth descriptor key. This won't be
> too hard to implement, but it's also different from what's currently
> coded in #17238.
Indeed, we need to change stuff but I think it's fine. We can get #17238
merged and then simply apply those changes after. I'm not too concerned about
the engineering logistics personally.
>
> Do people feel OK with this?
>
> Also, what should happen if client auth is not used? Should we fall back
> to the current descriptor format, or should we fake authorized clients
> and add a fake client-auth-encrypted-blob for uniformity? Feedback is
> welcome here, and I think the main issue here is engineering time and
> reuse of the current code.
Right, the fake client might be the big question mark. Discussing more below.
>
> ---
>
> Now WRT security, even if we do the double-encryption thing, and we
> consider an HSDir adversary that knows the onion address but is not an
> authorized client,we still need to add fake clients, otherwise that
> adversary will know the exact number of authorized clients. So fake
> clients will probably need to be introduced anyhow.
>
> As David pointed out, this all boils down to how much we pad the
> encrypted part of the descriptor, otherwise we always leak info. If we
> are hoping for a leakless strategy here, we should be generous with our
> padding.
>
> Let's see how much padding we need:
>
> - Each intro point adds about 1.1k bytes to the descriptor (according to
> david).
>
> - Each block of 16 authorized clients adds about 1k bytes to the
> descriptor (according to the format described below).
>
> - Apart from intro points and authorized clients, the rest of the
> descriptor is not that heavy: less than 1k bytes (right?)
>
> To get an average size here, let's consider a normal descriptor with 5
> intro points and 16 authorized clients. With the above values, the
> overhead on the encrypted part of the descriptor is about 7k bytes.
>
> To get a maximum size here, let's consider a phat descriptor that
> contains 20 intro points and 160 authorized clients. With the above
> values, the overhead on the encrypted part of the descriptor will be 32k
> bytes.
>
> Hence, here are some suggestions (read: magic numbers):
>
> - We always pad the encrypted section of the descriptor to the nearest
> multiple of 10k bytes (read: we pad the plaintext before we encrypt).
>
> This should be enough to obfuscate the number of IPs and authorized
> clients on most hidden services out there.
>
> - If client auth is enabled, we always include a multiple of 16
> authorized clients (and fake the extra if needed) in the encrypted
> portion.
Interesting, so if I have 3 IPs (default) and 42 clients, the descriptor will
be much bigger than the "normal" 3 IPs and 16 clients but yet the HSDir
observer won't be able to know for sure if it's actually a shit ton of IPs or
clients.
20 IPs == ~22k (considering 1.1k, a mix of legacy and normal ones)
160 clients == ~16k
This is good (and supports the increase to 20 IPs) in this case adding IPs or
clients doesn't really tell anyone which one is being used. And padding make
it confusing more...
Would be fun to run a table of the IP/client combination and see how much the
sizes differ but for that we would need the _real_ numbers instead of
estimation +/- 200 bytes.
>
> - We set the maximum allowed size of descriptors on HSDirs to 40k bytes.
> This should be enough to accomodate the fat descriptor described above.
Current hardcoded maximum directory object size which is 10MB.
#define MAX_DIRECTORY_OBJECT_SIZE (10*(1<<20))
So we are good on that front. If the maximum is really 32k than 40k sounds
good to me! Worst case, we go to 50k.
>
> As said, I was quite generous with the max size here. even though I
> doubt any actual hidden services will have such enormous descriptors,
> but I guess allowing those might prove to be a good idea in the future.
>
> I don't think 40k is that much in terms of size, especially when
> compared to things like the microdesc-consensus which is like 1.4MB, and
> is required for Tor to run.
>
> The main issue with big max sizes here, are assholes using our DHT as
> cloud storage. I don't think 40k is that bad in this regard, but I'm not
> sure how to evaluate this properly.
Ok, let me do a crazy calculation:
Considering ~50k unique .onion in the network (and we assume they all move to
prop224 at some point), it means 40KB * 50000 * 6 HSDir == 12000000 KB or
12000MB. We have what ~3k HSDirs thus 12000/3000 == 4MB per relay.
It's around of what I see on my relay last time I checked, I'm at ~130
descriptors at all time thus ~5.2MB for a 40KB descriptor.
If we scale that to a factor of 10 (assuming we go to 100k .onion), relays
will end up with ~40MB in RAM which is not that crazy nowadays. And we have an
OOM as well.
It's still a pretty big maximum but most HS will have a much smaller size
anyway.
>
> > ii) Should we use the descriptor ASCII format to encode all the
> > client-auth-desc-key data? Or is that weird binary format OK?
> >
>
> People said this is a good idea and I agree.
>
> Here is a suggested informal format, that gets placed in the beginning
> of the encrypted section of the descriptor:
>
> desc-auth-type <auth-type>
> desc-auth-nonce <8-byte-nonce-base64>
> auth-client <client-id> <iv> <encrypted-cookie>
>
> and we always include a multiple of 16 clients.
> Here is how it would look like in real life:
>
> =======================================================================
> desc-auth-type cookie
> desc-auth-nonce JMk/8BTbhB4
> auth-client dkW2nw OTqqSv29icTL5TSZ5TVQ3A +PIt0D9oWlDfbpGtRxGmeA
> auth-client z0/MMQ dw+pwJcLk9LB/FPfxFBL3g rFX9f6WUVZVUPEwFet428Q
> auth-client tH/BEQ zFWL1T9H/1fyV6bYW5Ol/Q /hjW1SgF0S3BANJhZZZ/OQ
> auth-client 2lxnoQ ggm/IraIMQ+L56V3R0OyHQ gI9Lh5azwxcunYwyFXxJSg
> auth-client S88yFw S4072NBKCwbwGep7/bJv+Q j3GdtDLAiZWI2jv0z6wfNw
> auth-client T7KbqA zhj5vu+HghqcMBRYpsGE0Q nQQtScbK91xx1G5l5gUWYg
> auth-client xPROzQ /OAH9FwXOufKGmFlBkqEJQ sqzeo6n4uMnqyghv3Vj3ZA
> auth-client l7lqEQ iZrRNH1Lg636j32tg7XfLQ HXeqg6nViGb7H4T1dYMK9Q
> auth-client +9ZUZw FReeAD5/mQD03J+YiffTKw oK1q7l/4JX+P08dLKYOmlw
> auth-client 0L9rXg xp9hvTWcWSmLBcyLN96Msg THWHP2nLlHBWWrwECOIg+A
> auth-client +kJcyQ nl7dkTOA9r10jk3Bo6I5WQ sGqMNtLMOiLDVDOr9YxJAw
> auth-client sa5PQQ oGqjP0Ko72fopFw2aAm2QA f+enrvjiDSXGJ3t77vDfAQ
> auth-client m87zTQ Pl5ITgw/6nb5zJPXjl9GPA X0lIhGNjXZqhGf+oHDX/wQ
> auth-client t8Ki0g GOPiP3WM+FQlDXLK1vUEOg 8bBZRrlxj6Ca392exkNuog
> auth-client 1D9wbQ 0Y5FZJGg30M2WPWu+xahbQ aXwcRLMS5MFAYcBrGEibVA
> auth-client UoLbLw jwM4/d5BUfch4FLpGogouQ r9P/aNX3pWseC7tlXx1I5Q
> ======================================================================
>
> with a total size of 1090 bytes.
>
> I think this looks much nicer than the binary format and easier to parse
> with the routerparse API as well.
+1
... but hrm, I thought that auth-client line should also provide the key to
decrypt the introduction point section no?
>
> > iii) Should we use a fresh IV for each ENCRYPTED_DESC_COOKIE? rend-spec.txt
> > does not do that, and IIUC that's OK because it uses a fresh key for
> > every encryption (even though the plaintext and IV is the same).
> >
>
> People said this is a good idea, so in the example above I did it.
>
> My main counter argument is the size increase, but perhaps being stingy
> here is stupid.
>
> In any case, the size overhead comes to 23 bytes of base64 for every IV,
> so it's not that bad.
I think it's fine.
Thanks!
David
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev