Re: [tor-dev] Proposal 176: Proposed version-3 link handshake for Tor

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Tue, Sep 20, 2011 at 2:13 PM, Roger Dingledine <arma@xxxxxxx> wrote:

Hi!  I'm going to snip every point where I agree with you, and just
patch the proposal accordingly.

> On Mon, Jan 31, 2011 at 09:50:06PM -0500, Nick Mathewson wrote:
[...]
>>      2) We should make it harder to probe for a Tor server.  Right
>>         now, you can just do a handshake with a server,
>>         renegotiate, then see if it gives you a VERSIONS cell.
>>         That's no good.
>
> Does this proposal address this goal in any way? I don't see why it's
> on the list.

Hm.  I think we had hoped to solve that in an earlier version of the
proposal, but decided that we probably couldn't do so in any really
reasonable way.  Adam Langley suggested that we could add a new
'be-a-tor' cell with a hash of the server's identity key that the
client has to send after the TLS handshake but before any cells, but
that would require that the client know the server's identity to
connect to it, which would break some bridge users.

I'll take this goal out, since we don't have a solution.  But should
we try to get one?  It seems like it will be really annoying to add
later.

 [...]
>>   An AUTH_CHALLENGE cell is a variable-length cell with the following
>>   fields:
>>       Challenge [32 octets]
>
> On IRC you suggested that the AUTH_CHALLENGE cell might want to list the
> authtypes it knows how to parse. Thus if we bump the AuthType version,
> we may not need to bump the whole link version.

Agreed; I'll add such a list.

[...]
>>        TIME: The time of day in seconds since the POSIX epoch. [8 octets]
>>        NONCE: A 16 byte value, randomly chosen by the client [16 octets]
>
> In the server section you specify that the randomness needs to be strong.
> Does the omission of that specification for the client mean it doesn't
> need to be? :)

Hah.

> (I'd hate for somebody to misinterpret 'nonce' as 'value that was not
> previously used', and implement it as a counter, which would do perfectly
> fine for the protocol but also reveal how many authenticate cells we've
> sent since the last time you saw one.)

We already have a note in tor-spec.txt that tries to say that
everything that we say is "random" has to really be random.  I'm
strengthening it to:

   All "random" values MUST be generated with a cryptographically
   strong pseudorandom number generator seeded from a strong entropy
   source, unless otherwise noted.

Additionally, I'm renaming it the field to RAND.

>>        SIG: A signature of a SHA256 hash of all the previous fields
>>          using the client's "Authenticate" key as presented.  (As
>>          always in Tor, we use OAEP-MGF1 padding; see tor-spec.txt
>>          section 0.3.)
>>           [variable length]
>>
>>    To check the AUTHENTICATE cell, a server checks that all fields
>>    containing a hash contain the correct value, then verifies the
>>    signature.  The server MUST ignore any extra bytes after
>>    the SHA256 hash.
>
> You mean extra bytes after the signature?

No.  I mean that if you check the signature and you do the signature
check (RSA public-key decrypt, then check and remove padding), you get
the thing that was signed.  The thing that was signed must start with
a SHA256 hash, but it is allowed to contain other stuff (so that we
can, say, add a SHA3 hash seamlessly later on).

>> 8. Open questions:
>>
>>   - May we cache which certificates we've already verified?  It
>>     might leak in timing whether we've connected with a given server
>>     before, and how recently.
>
> Would this be much of a win anyway? Seems like more code for not much
> of a win.

It saves a couple of public-key operations every time we do a connect.
 I think these will in practice be swamped by DH costs.

>>   - With which TLS libraries is it feasible to yoink client_random,
>>     server_random, and the master secret?  If the answer is "All
>>     free C TLS libraries", great.  If the answer is "OpenSSL only",
>>     not so great.
>
> Good question.

I continue to believe that the answer is "all free C TLS libraries,
and Java libraries where you can hack them or ".

If RFC5705 is ever widely implemented, we can use that instead for TLS
1.2 and later, so we don't need to go mucking about in the crypto
library's guts.  I am currently not so happy about using the RFC5705
construction with TLS 1.1 and earlier, though, because of the
wackypants SSL PRF.  ("Split your key in two, and use one half of it
to key a SHA1 PRF and the other half to key a MD5 PRF!")

I think on reflection that we should change the TLSSECRETS field from
optional to required in all AUTHENTICATE cells.  Only relays need to
send it, after all.

>>   - Should we do anything to check the timestamp in the AUTHENTICATE
>>     cell?
>
> Does having the timestamp give us anything that having the nonce doesn't
> already provide?

I added it because Adam told me I should.  I don't know for sure.
Maybe it helps defend against bad nonces?

> I pondered for a while that it might actually be bad to have the timestamp
> there, since its offset from 'real' time is a cookie that lets us track
> the user. But there are plenty of other ways that we can learn the
> client's time, like the NETINFO cell.

Right, also keep in mind that "client" here means "connection
initiator."  Regular clients shouldn't send AUTHENTICATE cells at all.

[...]
>>   - What should servers that don't have TLS renegotiation do?  For
>>     now, I think they should just stick with V1.  Eventually we can
>>     deprecate the V2 handshake as we did with the V1 handshake.
>>     When that happens, servers can be V3-only.
>
> Who are these servers you're thinking of?

AFAIK there are none.  I have no idea what January-Nick was thinking.

-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev