Commit 4c7247bf833245fe0dd7f7e8e724268450965822
Destroyed desirable properties for a secure channel (markdown)
Paul Frazee committed on 9/18/2015, 4:36:20 PMParent: 08da36bf7bab0e03d018d98ad3eae44b6983914b
Files changed
| desirable-properties-for-a-secure-channel.md | deleted |
| desirable-properties-for-a-secure-channel.md | ||
|---|---|---|
| @@ -1,86 +1,0 @@ | ||
| 1 | -here is a list of properties that I think are desirable in a p2p secure channel. It is assumed that peers already know the pubkeys of a server. It may not be possible to support _all_ of these properties in one protocol. | |
| 2 | - | |
| 3 | -1. content is forward secure | |
| 4 | -2. server verifies client identity | |
| 5 | -3. client verifies server identity | |
| 6 | -4. server knows client has verified | |
| 7 | -5. client knows server has verified | |
| 8 | -6. resists replay attack | |
| 9 | -7. resists man-in-the-middle attack | |
| 10 | -8. prevents cold calling/war-dialing (only accept calls from clients that know who server is) | |
| 11 | -9. eavesdropper cannot learn client key | |
| 12 | -10. eavesdropper cannot learn server key | |
| 13 | -11. eavesdropper cannot confirm client key | |
| 14 | -12. eavesdropper cannot confirm server key | |
| 15 | -13. replay attack cannot learn who is authorized | |
| 16 | -14. unauthorized client cannot learn server key. | |
| 17 | -15. unauthorized client cannot confirm server key | |
| 18 | -16. man in the middle cannot learn or confirm client or server keys | |
| 19 | - | |
| 20 | -## requirements | |
| 21 | - | |
| 22 | -how to achieve the above properties | |
| 23 | - | |
| 24 | -## 1. forward secure content | |
| 25 | - | |
| 26 | -Use diffie-helman style key exchange, an ensure a different key is used every connection. | |
| 27 | - | |
| 28 | -## 2,3. verify identities | |
| 29 | - | |
| 30 | -challenge the remote peer to provide a signature of a nonce. | |
| 31 | - | |
| 32 | -## 4,5. know the remote has verified you | |
| 33 | - | |
| 34 | -acknowledge their signed challenge by signing it. | |
| 35 | - | |
| 36 | -## 6. resist replay attack | |
| 37 | - | |
| 38 | -force peer to respond (sign) something you know is unique (nonce) (see 2,3) | |
| 39 | - | |
| 40 | -## 7. resist man in the middle attack | |
| 41 | - | |
| 42 | -verify identities & client must abort connection if response was from unexpected server. | |
| 43 | -Use diffie-helman to exchange keys (or box every message) | |
| 44 | - | |
| 45 | -## 8. prevent cold-calling/war-dialing | |
| 46 | - | |
| 47 | -client must prove it knows the server's pubkey. | |
| 48 | -This treats the pubkey as a write capability. | |
| 49 | - | |
| 50 | -one method would be to box the hello to the server's pubkey. | |
| 51 | -Another option, would be to hmac with the server's pubkey. | |
| 52 | - | |
| 53 | -## 9, 10. protect client/server keys from eavesdropper | |
| 54 | - | |
| 55 | -do not send long term keys as plaintext. | |
| 56 | -It shouldn't be necessary to send the server key at all, given that the client has know business connecting to a server they don't know (see 8, prevent war dialing) | |
| 57 | - | |
| 58 | -## 11, 12. eavesdropper cannot confirm client/server | |
| 59 | - | |
| 60 | -If an eavesdropper happens to know the client or server's key, are they able to know it is those peers talking? This property protects the client's privacy in particular. The server is likely to be a staticly addressed server, so their key is likely to eventually become public knowledge. Although, in a p2p protocol it's likely that the server may also move. | |
| 61 | - | |
| 62 | -The client on the other hand, is likely to be a mobile device that changes ip addresses. Being able to identify / observe their key would allow you to know track their location. | |
| 63 | - | |
| 64 | -This property is stronger than 9,10 even if the eavesdropper knows the keys, they are unable to confirm the identity of the peer. | |
| 65 | - | |
| 66 | -## 13. a replay attack cannot learn whether a given client is authorized on this server. | |
| 67 | - | |
| 68 | -It would be easy for a eavesdropper to record client hellos, and then send them to random servers to see whether that client is authorized on that server. If the server rejects that connection before the client has proven their identity then this leaks information from the server's access list. The server should wait until the client has proved their identity before rejecting a connection. | |
| 69 | - | |
| 70 | -## 14. unauthorized client cannot learn server key. | |
| 71 | - | |
| 72 | -To realize this property it would be necessary for the client to auth to the server first. | |
| 73 | -This property seems reasonable - "hi this is Alice, is Bob there?" if Bob isn't talking to Alice, or if it's a wrong number the server responds "sorry wrong number" and hangs up. This will require an extra round trip, because a challenge must be issued to the client. | |
| 74 | - | |
| 75 | -This property would prevent an active attacker from learning who a given server is. | |
| 76 | - | |
| 77 | -## 15. unauthorized client cannot confirm server key. | |
| 78 | - | |
| 79 | -This property is stronger than 14, because 14 means the server shouldn't reveal their key to an unauthorized client, but this property means the server should not give the client evidence incase the client already knows happens to know that key. This means a malicious client cannot get a list of keys (by some other mechanism) and check that those servers really are those keys. | |
| 80 | - | |
| 81 | -to realize this property it is necessary for the client to authorize to the server first, and for the server to be able to reject the client without revealing any more information. | |
| 82 | - | |
| 83 | -## 16. MITM/wrong number cannot learn or confirm keys. | |
| 84 | - | |
| 85 | -The client needs asymmetrically encrypt their authorization to the server, such that the server will act the same way whether the client is unauthorized, or just dialed a wrong number (unauthorized server) | |
| 86 | - | |
Built with git-ssb-web