On Thu, Sep 6, 2018 at 2:15 PM Steve Crocker wrote:
> I've been thinking about a version of this problem for several years.
> Attached are a short paper and presentation on the topic of a tamperproof
> root zone update system. The ideas are also applicable to other levels in
> the DNS tree.
>
>
Great stuff Steve. John Gilmore and I talked about the use of byzantine
quorum systems for key management at ISOC in 1998. And Olaf Kolkman, Johan
Ihren and I proposed such a system in 2005 as an alternative to what became
RFC 5011. I built a DNS system that used these ideas for DNS key
managemen
My focus is on preventing the orchestrator from faking the signatures.
Steve
Sent from my iPhone
> On Sep 6, 2018, at 3:52 PM, Hugo Salgado-Hernández wrote:
>
>> On 15:25 06/09, Steve Crocker wrote:
>> Let me flag a key point. You said this scheme will *detect* faked
>> signatures. If you wa
On 9/6/2018 3:08 PM, Steve Crocker wrote:
How do you prevent compromise of the central service?
The "Dealer" is only doing confidential processing during the key
generation phase. Once that's done, you can do a wipe. The
subsequent signature operations are all distributed. The combine
o
On 15:25 06/09, Steve Crocker wrote:
> Let me flag a key point. You said this scheme will *detect* faked
> signatures. If you want to *prevent* faked signatures, you need additional
> structure.
The orchestrator can detect faked signature pieces when is
merging them, before going live. So for th
Let me flag a key point. You said this scheme will *detect* faked
signatures. If you want to *prevent* faked signatures, you need additional
structure.
Steve
On Thu, Sep 6, 2018 at 3:22 PM, Hugo Salgado-Hernández
wrote:
> On 15:08 06/09, Steve Crocker wrote:
> > How do you prevent compromise
On 15:08 06/09, Steve Crocker wrote:
> How do you prevent compromise of the central service?
>
For the initial setup a physical ceremony is necessary,
to check there's no extra subkeys and for secure transmision
of them. But afterwards there's no need. Each node can check
the final signature vali
How do you prevent compromise of the central service?
Steve
On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández
wrote:
> On 23:19 06/09, Mukund Sivaraman wrote:
> > On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández wrote:
> > > Hi Mukund.
> > > I talked about this to Davey in
On 23:19 06/09, Mukund Sivaraman wrote:
> On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández wrote:
> > Hi Mukund.
> > I talked about this to Davey in Montreal. There's an implementation
> > in github[1] and presentations in OARC[2] and ICANN[3].
>
> Aha so you're the original source
On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández wrote:
> Hi Mukund.
> I talked about this to Davey in Montreal. There's an implementation
> in github[1] and presentations in OARC[2] and ICANN[3].
Aha so you're the original source :)
> I'm not sure if its being used right now in a
Hi Mukund.
I talked about this to Davey in Montreal. There's an implementation
in github[1] and presentations in OARC[2] and ICANN[3].
I'm not sure if its being used right now in a live zone, but certainly
in labs and testing. There's been some interests with academic
institutions, but don't think
During a coversation about the Yeti project, Davey Song brought up an
idea about using threshold signatures within DNSSEC. While he talked
about it primarily for the root zone within the context of having
multiple signers for it, I'm curious to know what operators think about
the concept for other
12 matches
Mail list logo
