Re: anonymous DH MITM
Ian Grigg [EMAIL PROTECTED]: I agree. As a side note, I think it is probably a good idea for TLS to deprecate ADH, simply because self-signed certs are more or less equivalent, and by unifying the protocol around certificates, it reduces some amount of complexity without major loss of functionality. Actually the anonymous DH ciphersuites can be (and are) employed to implement *authenticated* DH by using non-TLS means for authentication. (Specifically, what you can do is authenticate the TLS Finished messages, which involve hashes of the complete handshake.) This can be useful for using TLS in protocols without tainting them with X.509, and without creating specific new TLS ciphersuites. It is true that TLS would be (slightly) less complex if it didn't have both certificate-based and certificate-less ciphersuites. But TLS as employed in such protocols would become more complex if you had to use self-signed certificates (meaning that implementations would have to be able to parse X.509 stuff that currently can do without it). Also note that using a self-signed certificate means that you actually have to sign it (after all, the peer might try and verify it). This means additional private-key operations, and thus makes the protocol slower. Bottom line: Deprecating TLS ADH in favor of self-signed certificates would reduce complexity in a certain sense, but add complexity in other contexts. It also would make the handshake slower. I don't think it would be a good idea. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Tim Dierks [EMAIL PROTECTED]: Ian Grigg [EMAIL PROTECTED]: Steven M. Bellovin: What's your threat model? Self-signed certs are no better than ADH against MITM attacks. I agree. As a side note, I think it is probably a good idea for TLS to deprecate ADH, simply because self-signed certs are more or less equivalent, and by unifying the protocol around certificates, it reduces some amount of complexity without major loss of functionality. (AFAIK, self-signed certs in every way dominate ADH in functional terms.) In TLS, AnonDH offers forward secrecy, but there are no RSA certificate modes which do (except for ExportRSA). You can use ephemeral DH key agreement keys with static certified DSA keys, though. To be clear, this is a protocol issue, not really a self-signed certs vs. DH issue. From a different point of view, this is not even a protocol issue ... it is an RSA issue: When using self-signed certificates, nothing stops you from creating a new key and certificate every now and then. The only slight problem is that key generation for RSA is quite slow, compared with key generation for logarithm-based cryptosystems; you probably wouldn't want to create an RSA key for every incoming connection. But, on typical server hardware, it is no problem at all to create an RSA key every couple of minutes or so. While generally among the RSA-based TLS ciphersuites, only the RSA_EXPORT ones provide forward secrecy (thanks to an ephemeral 512-bit RSA key), in the case of self-signed certificates the distinction between export-restricted and other RSA ciphercuites is not an issue as far as forward secrecy is concerned. [Even when using proper certificates from some CA, you could provide forward secrecy for RSA ciphersuites: Instead of obtaining an end-entity certificate and directly using it on the TLS cipher, obtain a CA certificate with nameConstraints appropriately limited. Then the server can sign its own end-entity certificates without resorting to self-signed certificates in the usual sense. This allows the server to use newly created keys whenever it feels like it.] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
At 03:38 PM 10/6/03 -0400, Ian Grigg wrote: I'm asking myself whether anonymous DH is confusingly named. Perhaps it should be called psuedonymous DH because it creates psuedonyms for the life of the session? Or, we need a name that describes the creation of psuedonyms, de novo, from an anonymous starting position? Think of an identity is one endpoint of a communication link. Identities can have varying degrees of persistance and varying degrees of association with meatspace/bank accounts. These are orthogonal dimensions. An endpoint can maintain a reputation (persistant identity) but need not be linked to meatspace entity. A nom-de-plume is a traditional example. By itself, DH exchange only assures that the endpoints remain constant (plus, via the typical symmetric key exchange, also provides confidentiality) for the session. If there is a MITM, the endpoints are not what the distal endpoints (Alice Bob) might think. RSA-certs as administered by Verislime have very little meatspace linkage --you can't sue Verislime if their signed-claims about a meatspace entity are untrue, and the certholder ran off with your money, or if the cert was copied and your DNS cache poisoned. Similarly, publishing a RSA public key and email address does not guarantee anything. And since trust is *not* transitive, the so-called web of trust does little to help, because your personally trusted associates may have been compromised. And of course single meatspace entities may have several RSA keys which others do not know have a common user. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to defeat MITM using plain DH, Re: anonymous DH MITM
[Using multiple channels on the assumption that the MITM can't always get all of them.] This is starting to sound like some very old work - to which I don't have a reference - on what was called the wiretap channel. Basic idea: Alice and Bob wish to talk; Carol can listen in to everything, but her tap isn't perfect, so she gets a BER that's slightly higher. Alice and Bob can then choose a code (in the information-theory sense, not the crypto sense) that is fine-tuned to exactly match their BER - and also has the property that if you have one more bit error than the code supports, you can't decode at all. They get through, Carol gets nothing. The same idea has been revived in creating CD's that work in audio players but not PC's (which hvae CD drives that typically are not willing to tolerate as high an error rate.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Sat, 4 Oct 2003, Benja Fallenstein wrote: Does it work? Assume A() is Alice's series, B() is Bob's, MA() is the one Mitch uses with Alice, MB() the one Mitch uses with Bob. - Mitch sends first half of cyphertext of MA(1000) (to Alice) - Alice sends first half of cyphertext of her move + A(1000) (to Mitch) - Mitch sends second half - Alice sends second half Mitch can now decrypt Alice's move. - Bob sends first half of cyphertext of B(1000) (to Mitch) - Mitch sends first half of cyphertext of Alice's move + MB(1000) (to Bob) - Bob sends second half. - Mitch sends second half. Bob decides on his move. - Bob sends first half of ciphertext of his move + B(999) (to Mitch) - Mitch sends first half of ciphertext of MB(999) (to Bob) - Bob sends second half. - Mitch sends second half. Mitch can now decrypt Bob's move... Am I missing something? Yes, although I hadn't immediately realized it would be necessary: Timing information. If you require 30-45 seconds between packets, Mitch's game dies a rapid death. T:0 - Mitch sends first half of cyphertext of MA(1000) (to Alice) T:30 - Alice sends first half of cyphertext of her move + A(1000) (to Mitch) T:60 - Mitch sends second half T:90 - Alice sends second half Mitch can now decrypt Alice's move. T:60 - Bob sends first half of cyphertext of B(1000) (to Mitch) T:90 - Mitch sends first half of cyphertext of Alice's move + MB(1000) (to Bob) T:120 - Bob sends second half. T:135 - Alice times out waiting for Bob's response because it's 45 seconds since her last packet. Mitch must commit to a move ignorant of Bob's move by now, if he is to continue the game. T:150 - Mitch sends second half of Alice's move to Mitch Bob decides on his move. You could fiddle the intervals, within limits, or allow the players an I need more time to think move, but if they're not allowed to use it more than one time in three, then mitch isn't going to be able to make more than two moves. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
I'm lost in a twisty page of MITM passages, all alike. My point was that in an anonymous protocol, for Alice to communicate with Mallet is equivalent to communicating with Bob, since the protocol is anonymous: there is no distinction. All the concept of MITM is intended to convey is that in an anonymous protocol, you don't know who you're talking to, period. Mallet having two conversations with Alice Bob is equivalent to Mallet intermediating himself into a conversation between Alice Bob. If you have some unintermediated channel to speak with a known someone once, you can exchange a value or values which will allow you to authenticate each other forevermore and detect any intermediations in the past. But the fundamental truth is that there's no way to bootstrap a secure communication between two authenticated parties if all direct indirect communications between those parties may be intermediated. (Call this the 'brain in a jar' hypothesis.) - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Fri, 3 Oct 2003, Benja Fallenstein wrote: bear wrote: Why should this not be applicable to chess? There's nothing to prevent the two contestants from making nonce transmissions twice a move when it's not their turn. I.e., you would need a protocol extension to verify the nonces somehow-- if that's possible at all-- or are you just faster than me, and have thought about a way to do that already? Not faster per se, but I do happen to know the solution to that problem. :-) Suppose Alice picks a nonce A(zero). Then for n=one to a thousand (presumably no chess game will last 1000 moves) she calculates A(n) = hash (A(n-1)). Note, this has to be a ONE WAY hash function rather than any kind of encryption that can be decrypted. I'd suggest seventeenth-power mod K where K is prime, but lots of good irreversible hashing functions that aren't so expensive in CPU cycles are around. Bob also picks a nonce B(zero) on his side, and produces the same kind of sequence of B(one...one thousand) using the same hash function. Now let the moves of the chess game be numbered from 1000 down to 0. (ie, the first move they play will be move 1000, the second will be move 999, etc.) When it's Bob's turn, he sends his move padded with B(n), and Alice sends a random move padded with A(n). When it's Alice's turn, she sends her move padded with A(n) and Bob sends a random move padded with B(n). Bob can rapidly check to make sure that the A(n) recieved with each message has the right relation to the A(n+1) he recieved with the previous move, but there is no way he (or Mitch) can possibly predict A(n-1) to know what he'll get in the next move. Likewise Alice can rapidly check to make sure that the B(n) recieved with each move has the right relation to the B(n+1) she recieved with the previous move, but there is no way she (or Mitch) can predict B(n-1) to know what she'll get the next move. The only change to the rules of chess this requires is that if they ever exhaust the finite sequence of generated nonces, they have to call that game a draw. But a thousand moves, really, shouldn't be a problem for chess, and if it is you can just make the sequence longer and start a new game. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
| From: Tim Dierks [EMAIL PROTECTED] | | I'm lost in a twisty page of MITM passages, all alike. | | My point was that in an anonymous protocol, for Alice to communicate with | Mallet is equivalent to communicating with Bob, since the protocol is | anonymous: there is no distinction. All the concept of MITM is intended to | convey is that in an anonymous protocol, you don't know who you're talking | to, period. Mallet having two conversations with Alice Bob is equivalent | to Mallet intermediating himself into a conversation between Alice Bob. | | If you have some unintermediated channel to speak with a known someone | once, you can exchange a value or values which will allow you to | authenticate each other forevermore and detect any intermediations in the | past. But the fundamental truth is that there's no way to bootstrap a | secure communication between two authenticated parties if all direct | indirect communications between those parties may be intermediated. (Call | this the 'brain in a jar' hypothesis.) OK, let's set up two different scenarios: 1. Non-anonymous communication. Alice talks to Bob. Alice knows Bob is on the other end, Bob knows Alice is on the other end. They share some secret data; Alice wishes it to be known only to her and Bob. Mallet has a bug in Bob's home and copies the data. Can Alice or Bob detect that Mallet is there? Clearly not if Mallet never uses the data in a detectable way. No matter how many times Alice and Bob communicate, whether or not Mallet continues to bug Bob, neither Alice nor Bob can never learn of Mallet's presence. 2. Anonymous communication. Alice and Bob have a conversation. Mallet plays MITM. Alice and Bob don't know who their corresponding partner is, but they each tell the other that they will not reveal the secrets they exchange, and each believes the other - and indeed neither ever reveals those secrets. They wish to know if anyone else had a chance to learn their secret. On the face of it, there's no difference between these two cases. In each case, someone receives a copy of the secrets exchanged between Alice and Bob, but doesn't *do* anything with them that either Alice or Bob can see. However, in this case, unlike 1, if Alice and Bob continue to communicate - using private pseudonyms for each other to make continue to communicate a meaningful phrase - then, assuming Mallet cannot *always* interpose himself, they will eventually discover that someone has played a MITM game on them. If, indeed, you have a full brain in a jar, and Mallet *always* manages to interpose himself, then, yes, this situation is almost certainly undetectable. I've learned not to make snap judgements on stuff like this - too many clearly impossible things turn out not to be. In fact, I find the distinction between cases 1 and 2 quite surprising! -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
(about the Interlock Protocol) Benja wrote: The basic idea is that Alice sends *half* of her ciphertext, then Bob *half* of his, then Alice sends the other half and Bob sends the other half (each step is started only after the previous one was completed). The point is that having only half of the first ciphertext, Mitch can't decrypt it, and thus not pass on the correct thing to Bob in the first step and to Alice in the second, so both can actually be sure to have the public key of the person that made the other move. That sounds like an accurate summary to me. I think that the important thing is that the first message commits the sender to the contents while withholding knowledge of the contents from the recipient. The second message reveals the contents to the recipient. The fact that this is implemented by sending half of the ciphertext at a time seems peripheral. The same qualities would arise if this were implemented with a different commitment protocol, such as sending a secure hash of the tuple of (my_message, a_random_nonce). Regards, Zooko http://zooko.com/log.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
bear wrote: On Fri, 3 Oct 2003, Benja Fallenstein wrote: bear wrote: Why should this not be applicable to chess? There's nothing to prevent the two contestants from making nonce transmissions twice a move when it's not their turn. I.e., you would need a protocol extension to verify the nonces somehow-- if that's possible at all-- or are you just faster than me, and have thought about a way to do that already? Not faster per se, but I do happen to know the solution to that problem. :-) Ah, good ;-) Suppose Alice picks a nonce A(zero). Then for n=one to a thousand (presumably no chess game will last 1000 moves) she calculates A(n) = hash (A(n-1)). Does it work? Assume A() is Alice's series, B() is Bob's, MA() is the one Mitch uses with Alice, MB() the one Mitch uses with Bob. - Mitch sends first half of cyphertext of MA(1000) (to Alice) - Alice sends first half of cyphertext of her move + A(1000) (to Mitch) - Mitch sends second half - Alice sends second half Mitch can now decrypt Alice's move. - Bob sends first half of cyphertext of B(1000) (to Mitch) - Mitch sends first half of cyphertext of Alice's move + MB(1000) (to Bob) - Bob sends second half. - Mitch sends second half. Bob decides on his move. - Bob sends first half of ciphertext of his move + B(999) (to Mitch) - Mitch sends first half of ciphertext of MB(999) (to Bob) - Bob sends second half. - Mitch sends second half. Mitch can now decrypt Bob's move... Am I missing something? - Benja - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Perhaps I spoke too soon? It's not in Eurocrypt or Crypto 84 or 85, which are on my shelf. Where was it published? R. L. Rivest and A. Shamir. How to expose an eavesdropper. Communications of the ACM, 27:393-395, April 1984. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Thu, 2 Oct 2003, Zooko O'Whielacronx wrote: Perhaps I spoke too soon? It's not in Eurocrypt or Crypto 84 or 85, which are on my shelf. Where was it published? R. L. Rivest and A. Shamir. How to expose an eavesdropper. Communications of the ACM, 27:393-395, April 1984. Ah. Interesting, I see. It's an interesting application of a bit-commitment scheme. Hmmm. The key to this is that synchronous communications have to happen. When it's your turn to move, you create a message that gives the move, then pad it to some unsearchable length, encrypt, and send half. MITM can't tell what the move is without seeing the second half, so either has to make something up and send half of that, or just transmit unchanged. The second half is sent by each player when the first half has been recieved, and includes a checksum on the first half that was actually recieved. Mitch hast the choice of playing his own game of bughouse against each of the contestants, which just turns him into a third contestant. Or he has the choice of allowing the first two contestants to complete their game without interference. Why should this not be applicable to chess? There's nothing to prevent the two contestants from making nonce transmissions twice a move when it's not their turn. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
- Original Message - From: Tim Dierks [EMAIL PROTECTED] I think it's a tautology: there's no such thing as MITM if there's no such thing as identity. You're talking to the person you're talking to, and that's all you know. That seems to make sense. In anonymity providing systems often you want one side to be anonymous, and the other to identify itself (like in anonymous web surfing). In this case, if you are using DH to exchange keys, what you want is something like half-certified DH (see for example section 2.3 of [1]), where the web server authenticates itself. With half certified DH, Alice (the user that is browsing in my example) can be assured that she is really talking to Bob (web server she wanted to communicate with), and not a MITM. [1] http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Hi, bear wrote: starting with Rivest Shamir's Interlock Protocol from 1984. Hmmm. I'll go read, and thanks for the pointer. Perhaps I spoke too soon? It's not in Eurocrypt or Crypto 84 or 85, which are on my shelf. Where was it published? Communications of the ACM: Rivest and Shamir, How to expose an eavesdropper, CACM vol 24 issue 4, 1984. If you have an ACM Digital Library account, it's at http://portal.acm.org/ft_gateway.cfm?id=358053type=pdfcoll=ACMdl=ACMCFID=12683735CFTOKEN=40809148 I've started writing a short summary earlier today, after reading, but then I got distracted and didn't have time... sorry :) Hope this helps anyway. The basic idea is that Alice sends *half* of her ciphertext, then Bob *half* of his, then Alice sends the other half and Bob sends the other half (each step is started only after the previous one was completed). The point is that having only half of the first ciphertext, Mitch can't decrypt it, and thus not pass on the correct thing to Bob in the first step and to Alice in the second, so both can actually be sure to have the public key of the person that made the other move. - Benja - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Hi -- bear wrote: On Thu, 2 Oct 2003, Zooko O'Whielacronx wrote: R. L. Rivest and A. Shamir. How to expose an eavesdropper. Communications of the ACM, 27:393-395, April 1984. Ah. Interesting, I see. It's an interesting application of a bit-commitment scheme. Ok, so my other mail came far too late to be useful to you ;-) Why should this not be applicable to chess? There's nothing to prevent the two contestants from making nonce transmissions twice a move when it's not their turn. Maybe you have already a more advanced thing in mind than I do, but if your protocol would then look just like this-- - Alice sends first half of cyphertext of her move - Bob sends first half of cyphertext of random nonce - Alice sends second half - Bob sends second half and vice versa, consider this: - Alice sends first half of cyphertext of her move (to Mitch) - Mitch sends first half of cyphertext of random nonce (to Alice) - Alice sends second half - Mitch sends second half - Mitch sends first half of cyphertext of Alice's move (to Bob) - Bob sends first half of cyphertext of random nonce (to Alice) ... I.e., you would need a protocol extension to verify the nonces somehow-- if that's possible at all-- or are you just faster than me, and have thought about a way to do that already? Thx, - Benja - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
| Date: Fri, 3 Oct 2003 10:14:42 -0400 | From: Anton Stiglic [EMAIL PROTECTED] | To: Cryptography list [EMAIL PROTECTED], | Tim Dierks [EMAIL PROTECTED] | Subject: Re: anonymous DH MITM | | | - Original Message - | From: Tim Dierks [EMAIL PROTECTED] | | | I think it's a tautology: there's no such thing as MITM if there's no such | thing as identity. You're talking to the person you're talking to, and | that's all you know. | | That seems to make sense No; it's false. If Alice and Bob can create a secure channel between them- selves, it's reasonable to say that they are protected from MITM attacks if they can be sure that no third party can read their messages. That is: If Alice and Bob are anonymous, they can't say *who* can read the messages they are sending, but they might be able to say that, assuming that their peer is following the protocol exactly (and in particular is not releasing the shared secret) *exactly one other party* can read the message. Note that if you have this, you can readily bootstrap pseudonymity: Alice and Bob simply use their secure channel to agree on a shared secret, or on pseudonyms they will henceforth use between themselves. If there were a MITM, he could of course impersonate each to the other ever afterward. The Interlock Protocol doesn't provide this - it prevents the MITM from modifying the exchanged messages, but can't prevent him from reading them. It's not clear if it can be achieved at all. But it does make sense as a security spec. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
In message [EMAIL PROTECTED], Benja Fallenstein writes: Hi, bear wrote: starting with Rivest Shamir's Interlock Protocol from 1984. Hmmm. I'll go read, and thanks for the pointer. Perhaps I spoke too soon? It's not in Eurocrypt or Crypto 84 or 85, which are on my shelf. Where was it published? Communications of the ACM: Rivest and Shamir, How to expose an eavesdropper, CACM vol 24 issue 4, 1984. If you have an ACM Digital Library account, it's at http://portal.acm.org/ft_gateway.cfm?id=358053type=pdfcoll=ACMdl=ACMCFID=1 2683735CFTOKEN=40809148 I've started writing a short summary earlier today, after reading, but then I got distracted and didn't have time... sorry :) Hope this helps anyway. The basic idea is that Alice sends *half* of her ciphertext, then Bob *half* of his, then Alice sends the other half and Bob sends the other half (each step is started only after the previous one was completed). The point is that having only half of the first ciphertext, Mitch can't decrypt it, and thus not pass on the correct thing to Bob in the first step and to Alice in the second, so both can actually be sure to have the public key of the person that made the other move. You have to be careful how you apply it; sometimes, there are attacks. See Steven M. Bellovin and Michael Merritt, An Attack on the Interlock Protocol When Used for Authentication, in IEEE Transactions on Information Theory 40:1, pp. 273-275, January 1994, http://www.research.att.com/~smb/papers/interlock.ps for an example of how it's a bad protocol to use to send passwords. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
- Original Message - From: Jerrold Leichter [EMAIL PROTECTED] [...] | I think it's a tautology: there's no such thing as MITM if there's no such | thing as identity. You're talking to the person you're talking to, and | that's all you know. | | That seems to make sense No; it's false. If Alice and Bob can create a secure channel between them- selves, it's reasonable to say that they are protected from MITM attacks if they can be sure that no third party can read their messages. How do they create the secure channel in the first place? We are talking about MITM that takes place during the key agreement protocol. That is: If Alice and Bob are anonymous, they can't say *who* can read the messages they are sending, but they might be able to say that, assuming that their peer is following the protocol exactly (and in particular is not releasing the shared secret) *exactly one other party* can read the message. That's false. Alice and Bob can follow the basic DH protocol, exactly, but Mallory is in the middle, and what you end up with is a shared key between Alice and Bob and Mallory. The property you are talking about, concerning the *exactly one other party* can read the message is related to the *key authentication* property, discussed in [1] (among other places), which enables you to construct authenticated key agreements. Note that if you have this, you can readily bootstrap pseudonymity: Alice and Bob simply use their secure channel to agree on a shared secret, or on pseudonyms they will henceforth use between themselves. If there were a MITM, he could of course impersonate each to the other ever afterward. But how do they share the initial secret? And with true anonymity you don't want linkability. Pseudonymity is a different thing, with pseudonymity you have linkability. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
| From: Anton Stiglic [EMAIL PROTECTED] | From: Jerrold Leichter [EMAIL PROTECTED] | No; it's false. If Alice and Bob can create a secure channel between | themselves, it's reasonable to say that they are protected from MITM | attacks if they can be sure that no third party can read their messages. | | How do they create the secure channel in the first place? We are talking | about MITM that takes place during the key agreement protocol. I didn't say I had a protocol that would accomplish this - I said that the notion was such a protocol was not inherently self-contradictory. | That is: If Alice and Bob are anonymous, they can't say *who* can read the | messages they are sending, but they might be able to say that, assuming | that their peer is following the protocol exactly (and in particular is | not releasing the shared secret) *exactly one other party* can read the | message. | | That's false. Alice and Bob can follow the basic DH protocol, exactly, but | Mallory is in the middle, and what you end up with is a shared key between | Alice and Bob and Mallory. There's nothing to be true or false: It's a definition! (And yes, DH does not provide a system that meets the definition.) | The property you are talking about, concerning the *exactly one other party* | can read the message is related to the *key authentication* property, | discussed in [1] (among other places), which enables you to construct | authenticated key agreements. The reference was missing; I'd be interested in seeing it. | | Note that if you have this, you can readily bootstrap pseudonymity: Alice | and Bob simply use their secure channel to agree on a shared secret, or on | pseudonyms they will henceforth use between themselves. If there were a | MITM, he could of course impersonate each to the other ever afterward. | | But how do they share the initial secret? I have no idea! |And with true anonymity you don't | want linkability. Pseudonymity is a different thing, with pseudonymity you | have linkability. If Alice and Bob wish to establish pseudonyms for future use, they can. No one says they have to. On the other hand, linkability is a funny property. If Alice and Bob each keep their secrets, and they each believe the other party keeps their secrets, then if there is *anything* unique in their conversations with each other that they keep around - like the sessions keys, or the entire text of the conversation - they can use *that* to link future conversations to past ones. (No one without access to the secrets can do that, of course.) If you define anonymity as complete lack of linkability, even to the participants, you're going to end up requiring all participants to forget, not just their session keys, but everything they learned in their conversations. Perhaps there are situations where that's useful, but they strike me as pretty rare. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
| Date: Fri, 03 Oct 2003 17:27:36 -0400 | From: Tim Dierks [EMAIL PROTECTED] | To: Jerrold Leichter [EMAIL PROTECTED] | Cc: Cryptography list [EMAIL PROTECTED] | Subject: Re: anonymous DH MITM | | At 03:28 PM 10/3/2003, Jerrold Leichter wrote: | From: Tim Dierks [EMAIL PROTECTED] | | No; it's false. If Alice and Bob can create a secure channel between | | themselves, it's reasonable to say that they are protected from MITM | | attacks if they can be sure that no third party can read their messages. | | That is: If Alice and Bob are anonymous, they can't say *who* can read | | the messages they are sending, but they might be able to say that, | | assuming that their peer is following the protocol exactly (and in | | particular is not releasing the shared secret) *exactly one other party* | | can read the message. | | | | They've got exactly that same assurance in a MITM situation: | | unfortunately, | | Mallet is the one other party who can read the message. | But Mallet is violating a requirement: He is himself passing along the | information Alice and Bob send him to Bob and Alice. No notion of secrecy | can make any sense if one of the parties who legitimately *has* the secret | chooses to pass it along to someone else! | | In an authenticated protocol, you can have a risk model which includes the | idea that an authorized person will not choose to share a secret with an | unauthorized person. However, in an anonymous protocol, you cannot have | such a risk model, because there's no such distinction. Why not? | Are you saying that you're defining a protocol with rules of behavior which | cannot be enforced (namely that Mallet is breaking the protocol by | forwarding the data)? They can't be *enforced*, but violations can (perhaps) be detected. | Previously, you said that you were defining the thing | to be controlled as the shared secret, but now you're extending it to any | and all content transmitted over the link. The shared secret is the session key. Assuming the encryption is sufficient, the security of this shared secret implies the security of all data exchanged on the link. |Describing the format of | communications between parties is in a protocol; what they do with those | communications is in a risk model or trust model. | As long as Mallet continues to interpose himself in *all* subsequent | sessions between Alice and Bob, he can't be detected. But suppose each of | them keeps a hash value that reflects all the session keys they think they | ever used in talking to each other. Every time they start a session, they | exchange hashes. Whenever Mallet is present, he modifies the messages to | show the hash values for the individual sessions that he held with each | party seperately. Should they ever happen to form a session *without* | Mallet, however, the hashes will not agree, and Mallet will have been | detected. So the difference isn't just notional - it's something the | participants can eventually find out about. | | No disagreement with this: if you can ever communicate over an | unintermediated channel, you can detect previous or future intermediations. Every being able to communicate over an unintermediated channel can mean two things: 1. We can communicate over such a channel *and know we are doing so*. In that case, we can safely exchange keys, check our previous communications, etc. 2. We sometimes communicate over such a channel, but we can't recognize when it happens. Case 2 is much weaker than case 1, but is sufficient to detect that Mallet has been playing games. In fact, even case 2 is stronger than needed: Suppose that there are multiple Mallet_i playing MITM. Any given connection may go through any subset of the Mallets. Any time a connection happens not to go through a particular either Mallet that usually talks directly to Alice or Bob, the game is up. | There are easier ways to do it than maintaining a hash of all session keys: | you can just insist that the other party have the same public key they had | the first time you spoke, and investigate if that becomes untrue (for | example, ssh's authentication model). Sure. | In fact, if we assume there is a well-known bulletin board somewhere, to | which anyone can post but on which no one can modify or remove messages, we | can use it as to force a conversation without Mallet. Alice and Bob can: | | [...elided...] | | If not, Mallet was at work. (For this to work, the bulletin must have a | verifiable identity - but it's not necessary for anyone to identify himself | to the bulletin board.) | | This can be defeated by Mallet if he makes changes in his forwarding of | communications (that either have no semantic effect or have whatever | semantic effect he chooses to impose), but which causes the hashes to vary. | He then posts statements re: his communications
Re: anonymous DH MITM
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ian Grigg writes: M Taylor wrote: MITM is a real and valid threat, and should be considered. By this motive, ADH is not a recommended mode in TLS, and is also deprecated. Ergo, your threat model must include MITM, and you will pay the cost. (Presumably this logic is behind the decision by the TLS RFC writers to deprecate ADH. Hence, talking about ADH in TLS is a waste of time, which is why I have stopped suggesting that ADH be used to secure browsing, and am concentrating on self-signed certs. Anybody care to comment from the TLS team as to what the posture is?) What's your threat model? Self-signed certs are no better than ADH against MITM attacks. I agree. As a side note, I think it is probably a good idea for TLS to deprecate ADH, simply because self-signed certs are more or less equivalent, and by unifying the protocol around certificates, it reduces some amount of complexity without major loss of functionality. (AFAIK, self-signed certs in every way dominate ADH in functional terms.) Until you understand your threat model, you don't have any grounds to make that decision. I think we are in agreement on that!? MITM is certainly possible -- I've seen it happen. The dsniff package includes a MITM tool, as do many other packages; at the Usenix Security conference a few years ago, someone intercepted all web-bound traffic and displayed a page All your packets are belong to us. An appropriate security model for a security conference might be to put a sign up at the door saying All your assumptions are belong to us At least that way everyone would be in tune with the nature of the conference. Anything that happens at the Usenix Security Conference is, in my book, ruled out of ones regular, commercially relevant threat model. Same goes for demos in a Uni student lab. We all know it's possible. The question is, should we worry about it? And, following on from Perry's method, should we impose our own fears on others? A threat must occur sufficiently in real use, and incur sufficient costs in excess of protecting against it, in order to be included in the threat model on its merits. Anyone on the same LAN (switched or unswitched) could have done the same. If you're not on the same LAN, a routing attack or a DNS attack could result in the same thing, and those are happening, too, in the wild. I know a couple of instances were posted maybe 6 months back. What we need really is some sort of repository of MITM attacks in the wild. Costs would be very useful too. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Wed, 1 Oct 2003, Ian Grigg wrote: M Taylor wrote: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, Ah, there's the rub. ADH does not protect against MITM, as far as I am aware. DH is an open protocol; it doesn't rely on an initial shared secret or a Trusted Authority. There is a simple proof that an open protocol between anonymous parties is _always_ vulnerable to MITM. Put simply, in an anonymous protocol, Alice has no way of knowing whether she is communicating with Bob or Mallory, and Bob has no way of knowing whether an incoming communication is from Mallory or from Alice. (that's what anonymous means). If there is no shared secret and no Trent, then nothing prevents Mallory from being the MITM. You can have anonymous protocols that aren't open be immune to MITM And you can have open protocols that aren't anonymous be immune to MITM. But you can't have both. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Bear wrote: DH is an open protocol; it doesn't rely on an initial shared secret or a Trusted Authority. There is a simple proof that an open protocol between anonymous parties is _always_ vulnerable to MITM. Put simply, in an anonymous protocol, Alice has no way of knowing whether she is communicating with Bob or Mallory, and Bob has no way of knowing whether an incoming communication is from Mallory or from Alice. (that's what anonymous means). If there is no shared secret and no Trent, then nothing prevents Mallory from being the MITM. You can have anonymous protocols that aren't open be immune to MITM And you can have open protocols that aren't anonymous be immune to MITM. But you can't have both. I'd like to see the proof. I think it depends on what you mean by MITM. Take the Chess Grandmaster Problem: can Alice and Bob play a game of chess against one another while preventing Mitch (the Man In The CHannel) from proxying their moves to one another while taking the credit for being a good chess player? To make it concrete, suppose we limit it to the first two moves of a chess game. One player is going to make the first move for White, and the other player is going to make the first move for Black. Now, obviously Mitch could always act as a passive proxy, forwarding exactly the bits he receives, but in that case he can be defeated by e.g. DH. To make it concrete, suppose that the first player includes both his move and his public key (or his public DH parameters) in his message, and the second player encrypts his message with the public key that arrived in the first message. Mitch wins if the first player accepts the second player's move (the first move for Black). The players win if the first player accepts a different move that the second player didn't make. (This is the case where Mitch is no longer doing the Chess Grandmaster Attack, but is instead just playing two games of chess, one game with the first player and another game with the second player.) If the players reject a message and end the protocol, then neither Mitch nor the players win -- it is a tie. (A denial-of-service situation.) Now, you might intuitively believe that this is one of those situations where Mitch can't lose. But there are several protocols published in the literature that can help the players against Mitch, starting with Rivest Shamir's Interlock Protocol from 1984. The funny thing is that all of these published protocols seem to require a constraint on the game of chess. For example, the Interlock Protocol works only with full duplex games where both sides are making a move at the same time. You can't obviously apply it to chess, although you *could* apply it to a full-duplex game like chess variant Bughouse, or, um, children's card game War. Or a Real-Time Strategy computer game where both players are sending moves to one another simultaneously. Now, you might go back to the beginning of this message and say Well, Chess Grandmaster isn't MITM!. In that case, I would like to see a definition of what exactly is this MITM which can't be countered in the no- shared-trust setting. I'm not saying that there isn't such a thing -- indeed I can think of a definition of MITM which satisfies that requirement, but I'm not sure it is the same definition that other people are thinking of. Anyway, it is a funny and underappreciated niche in cryptography, IMO. AFAIK nobody has yet spelled out in the open literature what the actual theoretical limitations are. Regards, Zooko http://zooko.com/log.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
bear wrote: You can have anonymous protocols that aren't open be immune to MITM True. And you can have open protocols that aren't anonymous be immune to MITM. True. But you can't have both. False. In fact, it is possible to prove the existence of at least one open and anonymous protocol that is immune to MITM in any given, feasible scenario (ie, given a threat model). Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
anonymous DH MITM
Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
M Taylor [EMAIL PROTECTED] writes: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security. It doesn't protect against MITM. You could, however, use a static DH key and then client could cache it as with SSH. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
At 07:06 PM 10/1/2003, M Taylor wrote: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security. It does not, and most SSL/TLS implementations/installations do not support anonymous DH in order to avoid this attack. Many wish that anon DH was more broadly used as an intermediate security level between bare, insecure TCP authenticated TLS, but this is not common at this time. (Of course, it's not even clear what MITM means for an anonymous protocol, given that the layer in question makes no distinction between Bob Mallet.) - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
M Taylor wrote: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, Ah, there's the rub. ADH does not protect against MITM, as far as I am aware. and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security. View A: MITM is extremely rare. It's quite a valid threat model to say that MITM is a possibility that won't need to be defended against, 100%. E.g.1, SSH which successfully defends most online Unix servers, by assuming the first contact is a good contact. E.g.2, PGP, which bounces MITM protection up to a higher layer. Or, what's your threat model? Why does it include MITM and how much do you want to pay? View B: MITM is a real and valid threat, and should be considered. By this motive, ADH is not a recommended mode in TLS, and is also deprecated. Ergo, your threat model must include MITM, and you will pay the cost. (Presumably this logic is behind the decision by the TLS RFC writers to deprecate ADH. Hence, talking about ADH in TLS is a waste of time, which is why I have stopped suggesting that ADH be used to secure browsing, and am concentrating on self-signed certs. Anybody care to comment from the TLS team as to what the posture is?) iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Thu, Oct 02, 2003 at 12:06:40AM +0100, M Taylor wrote: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? No, it doesn't. If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security. The non DH suites are there in the spec for use when your security model allows. Not many uses of TLS do. Last time I checked, which was a while ago now, very few deployed https servers offered anon DH suites. Which is appropriate since MITM breaks the https security model. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Tim Dierks [EMAIL PROTECTED] writes: It does not, and most SSL/TLS implementations/installations do not support anonymous DH in order to avoid this attack. Uhh, I think that implementations don't support DH because the de facto standard is RSA, not because of any concern about MITM (see below). You can talk to everything using RSA, you can talk to virtually nothing using DH, therefore... Many wish that anon DH was more broadly used as an intermediate security level between bare, insecure TCP authenticated TLS, but this is not common at this time. RSA is already used as anon-DH (via self-signed, snake-oil CA, expired, invalid, etc etc certs), indicating that MITM isn't much of a concern for most users. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
At 10:37 PM 10/1/2003, Peter Gutmann wrote: Tim Dierks [EMAIL PROTECTED] writes: It does not, and most SSL/TLS implementations/installations do not support anonymous DH in order to avoid this attack. Uhh, I think that implementations don't support DH because the de facto standard is RSA, not because of any concern about MITM (see below). You can talk to everything using RSA, you can talk to virtually nothing using DH, therefore... Sure, although it's a chicken egg thing: it's not the standard because the initial adopters designers of SSL didn't have any use for it (not to mention the political strength of RSADSI in the era). Many wish that anon DH was more broadly used as an intermediate security level between bare, insecure TCP authenticated TLS, but this is not common at this time. RSA is already used as anon-DH (via self-signed, snake-oil CA, expired, invalid, etc etc certs), indicating that MITM isn't much of a concern for most users. There are so many different categories of users that it's probably impossible to make any blanket statements about most users. It's certainly true that a web e-commerce vendor doesn't have much use for self-signed certificates, since she knows that dialogs popping up warning customers that they have some problem they don't understand is going to lead to the loss of some small fraction of sales. (Not that she necessarily has any concern about the security implications: it's almost entirely a customer comfort and UI issue.) - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
