On Tue, Sep 20, 2011 at 2:13 PM, Roger Dingledine arma@mit.edu 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).
- 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.