From ondrej.mikle at nic.cz Wed Feb 8 05:51:40 2012 From: ondrej.mikle at nic.cz (Ondrej Mikle) Date: Wed, 08 Feb 2012 14:51:40 +0100 Subject: [Sovereign Keys] Transitional considerations - MECAI discussion Message-ID: <4F327DEC.6080806@nic.cz> Hi, there's a thread in mozilla.dev.tech.crypto discussing solutions to the same issues noted in Sovereign Keys' "transitional considerations": https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/dac7cd303825d49e/b4178b57b393f1f2?q=#b4178b57b393f1f2 Ondrej From erik at datenzone.de Tue Feb 14 07:13:25 2012 From: erik at datenzone.de (Erik Tews) Date: Tue, 14 Feb 2012 16:13:25 +0100 Subject: [Sovereign Keys] Design proposals for SK Message-ID: <1329232405.3161.14.camel@lap19.cdc.informatik.tu-darmstadt.de> Hi I have read and analyzed the design document, and I have some ideas how one could improve SK. I have uploaded them to: https://github.com/eriktews/Sovereign-Keys/tree/ideas-from-erik-tews/issues In a nutshell, I would like to hear comments about the following ideas: signing-sk-data-on-master.txt - We could just sign the timeline data on the timeline master server. Mirror will not need to sign an response anymore, making them more performant and secure, and less powerful. using-dns-as-protocol.txt - If the data doesn't need to be processed by a mirror server anymore, we can also use DNS as a distributed cache for it, and solve the captive portal problem. including-the-server-certificate-in-the-request.txt - This is more a first thought than a cange request, should we include the server certificate in the request from the client? This makes it easier to detect certificates from a compromised CA. realtime-data-for-none-sk-names.txt - And the second question is, should we extend SK so that it can be used as a kind of observatory and also give some protection to sites not using SK. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From erik at datenzone.de Mon Feb 27 17:18:34 2012 From: erik at datenzone.de (Erik Tews) Date: Tue, 28 Feb 2012 02:18:34 +0100 Subject: [Sovereign Keys] A design question: How should timelines and mirrors operate? Message-ID: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> Hi I would like to ask an intresting design question: Assuming that all timeline data is signed by the timeline operator, and it is distribute to mirror servers. How should freshness be ensured, and what can do to improve the availability of the timeline? One possible solution could be, that every mirror operator adds an addtitional freshness signature to every response or every entry in the timeline. The key used for this signature is different from the timeline operators key. If the primary server for the timeline goes down for a while, mirror operators can still sign their responses, and client can have some trust in the freshness of the responses. On the other hand, this makes the protocol a bit more complex. A client needs to check two signatures, one for the integrity and authenticity of the data (from the timeline operator), and one for the freshness. Also, a mirror operator must be trusted to some extended, because he can prevent the client from receiving updates from the timeline. Also, a timeline operator needs to operate a backup server anyway, because the primary timeline server should copy all entries that are added to the timeline, should be copied to a remote side, if the primary server dies after having added and distributed a new entrie to the timeline. An alternative would be, that the timeline operator would need to operate multiple servers at different locations. All servers have access to the private key of the timeline, and need to be syncronized, whenever the timeline is updated. If one or a few of the servers go down, the rest of the servers just continue to operate the timeline. The signature of the timeline opeator is often renewed, to prove integrity, authenticity and freshness of the responses. This makes the protocol design for the clients much easier, because only a single signature needs to be checked, but operating a timeline is much more difficult. Also, a timeline operator needs to make sure that all these server never divergate, and all servers are hosted at secure locations, because they all have access to the private key. Also, a good question is how to handle permanent failures of a timeline. For example a timeline operator could go bankrupt, or loose the private key. All client, that insist opon this timeline would act like under an attack, because no fresh responses from this timeline are available anymore. I look forward to hearing comments about this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From g.koppen at jondos.de Tue Feb 28 00:09:42 2012 From: g.koppen at jondos.de (Georg Koppen) Date: Tue, 28 Feb 2012 09:09:42 +0100 Subject: [Sovereign Keys] A design question: How should timelines and mirrors operate? In-Reply-To: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> References: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> Message-ID: <4F4C8BC6.2020002@jondos.de> > Also, a good question is how to handle permanent failures of a timeline. > For example a timeline operator could go bankrupt, or loose the private > key. Then it dies, I guess. Like in: "The timeline servers might have their private keys compromised or revoked, in which case they will die." > All client, that insist opon this timeline would act like under an > attack, because no fresh responses from this timeline are available > anymore. Clients are not insisting on a particular timeline, rather: 'Clients query one of the M comprehensive mirrors of timelines with a query that asks "what are all the timeline entries that pertain to name X since entry Y?"' (see the mirror's response in section 4.a. Queries to Mirrors for the full context) Mirrors in turn "keep full, up to date copies of *all* [emphasis added] the trusted timelines." (all quotes are from the current spec) Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From g.koppen at jondos.de Tue Feb 28 00:27:13 2012 From: g.koppen at jondos.de (Georg Koppen) Date: Tue, 28 Feb 2012 09:27:13 +0100 Subject: [Sovereign Keys] A design question: How should timelines and mirrors operate? In-Reply-To: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> References: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> Message-ID: <4F4C8FE1.5060507@jondos.de> > All client, that insist opon this timeline would act like under an > attack, because no fresh responses from this timeline are available > anymore. Forgot to point you to "MAX_DERELICT_TIMELINES=2 # Timelines are derelict if nobody is seeing updates # from them. We will tolerate this number of them" in the algorithm outlined in section 4.b. as well... Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From erik at datenzone.de Tue Feb 28 12:28:13 2012 From: erik at datenzone.de (Erik Tews) Date: Tue, 28 Feb 2012 21:28:13 +0100 Subject: [Sovereign Keys] A design question: How should timelines and mirrors operate? In-Reply-To: <4F4C8FE1.5060507@jondos.de> References: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> <4F4C8FE1.5060507@jondos.de> Message-ID: <1330460893.3730.6.camel@lap19.cdc.informatik.tu-darmstadt.de> Yes, my question was more, how does the client decide, which timelines it trusts/tracks, and how is this updated? At the moment, this point is a bit vague in the design document. As you outlined, when too many timelines are not operational anymore, the whole system stops working. So if a timeline goes down, it needs to be replaced rather soon then late. Am Dienstag, den 28.02.2012, 09:27 +0100 schrieb g.koppena: > > All client, that insist opon this timeline would act like under an > > attack, because no fresh responses from this timeline are available > > anymore. > > Forgot to point you to > > "MAX_DERELICT_TIMELINES=2 # Timelines are derelict if nobody is > seeing updates > # from them. We will tolerate this number > of them" > > in the algorithm outlined in section 4.b. as well... > > > Georg > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 455 bytes > Desc: OpenPGP digital signature > URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From g.koppen at jondos.de Wed Feb 29 13:02:45 2012 From: g.koppen at jondos.de (Georg Koppen) Date: Wed, 29 Feb 2012 22:02:45 +0100 Subject: [Sovereign Keys] A design question: How should timelines and mirrors operate? In-Reply-To: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> References: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> Message-ID: <4F4E9275.4070900@jondos.de> > I would like to ask an intresting design question: Assuming that all > timeline data is signed by the timeline operator, and it is distribute > to mirror servers. How should freshness be ensured, It is already ensured using the Timeline Freshness Messages. What is the problem with these? > and what can do to > improve the availability of the timeline? I am actually not sure whether this is/should be in the scope of the SK spec at all. Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From erik at datenzone.de Wed Feb 29 13:12:08 2012 From: erik at datenzone.de (Erik Tews) Date: Wed, 29 Feb 2012 22:12:08 +0100 Subject: [Sovereign Keys] A design question: How should timelines and mirrors operate? In-Reply-To: <4F4E9275.4070900@jondos.de> References: <1330391914.7717.20.camel@lap19.cdc.informatik.tu-darmstadt.de> <4F4E9275.4070900@jondos.de> Message-ID: <1330549928.3896.4.camel@lap19.cdc.informatik.tu-darmstadt.de> Am Mittwoch, den 29.02.2012, 22:02 +0100 schrieb Georg Koppen: > > I would like to ask an intresting design question: Assuming that all > > timeline data is signed by the timeline operator, and it is distribute > > to mirror servers. How should freshness be ensured, > > It is already ensured using the Timeline Freshness Messages. What is the > problem with these? If I understand the current design correctly, the TFM doesn't allow a client to check the correctness of the response instandly. Instead, he can use this to find out that a mirror was not giving a correct answer later, or by using cached responses. If every entry in the timeline would be signed by the timeline server in regular intervals, a client could check the freshness of the response directly after each query. Here, the mirror cannot surpress some entries. > > and what can do to > > improve the availability of the timeline? > > I am actually not sure whether this is/should be in the scope of the SK > spec at all. One could tweak the design a bit, but it doesn't need to be covered by the SK specs. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: