<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"Préformaté HTML Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Texte de bulles Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.PrformatHTMLCar
{mso-style-name:"Préformaté HTML Car";
mso-style-priority:99;
mso-style-link:"Préformaté HTML";
font-family:"Courier New";
mso-fareast-language:FR;}
span.TextedebullesCar
{mso-style-name:"Texte de bulles Car";
mso-style-priority:99;
mso-style-link:"Texte de bulles";
font-family:"Tahoma","sans-serif";
mso-fareast-language:FR;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=FR link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi, <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am an administrator of DNS resolvers to Djibouti Telecom.<o:p></o:p></span></p><pre style='background:white'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I updated the root key to our DNS resolvers servers. Is there a way to tell if DNSSEC is using the last trusted anchor </span><b><span lang=EN-US style='font-family:Consolas;color:#333333;background:white'>( </span></b><b><span lang=EN-US style='font-size:11.0pt;font-family:Consolas;color:#333333;background:white'>Update on the Root KSK </span></b><b><span lang=EN-US style='font-size:11.0pt;font-family:Consolas;color:#333333'>Rollover<span style='background:white'> Project</span></span></b><b><span lang=EN-US style='font-family:Consolas;color:#333333;background:white'>)</span></b><span lang=EN-US style='font-family:"Arial","sans-serif";color:#545454;background:white'> </span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>?<o:p></o:p></span></pre><pre style='background:white'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></pre><div style='mso-element:para-border-div;border:solid #CCCCCC 1.0pt;padding:7.0pt 7.0pt 7.0pt 7.0pt;background:whitesmoke'><pre style='margin-bottom:7.5pt;background:whitesmoke;word-break:break-all;border:none;padding:0cm'><b><span lang=EN-US style='font-family:Consolas;color:#333333;background:white'># dig @127.0.0.1</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><b><span lang=EN-US style='font-family:Consolas;color:#333333;background:white'>dnssec-failed.org a +dnssec<o:p></o:p></span></b></pre></div><p class=MsoNormal><img width=558 height=202 id="Image_x0020_1" src="cid:image001.png@01D450CC.A6C89260"><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Link: </span><b><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><a href="https://www.icann.org/dns-resolvers-checking-current-trust-anchors">https://www.icann.org/dns-resolvers-checking-current-trust-anchors</a></span></b><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you for your answer. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Coordialement <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Djibril ROBLE <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>De :</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> dns-operations [mailto:dns-operations-bounces@dns-oarc.net] <b>De la part de</b> Warren Kumari<br><b>Envoyé :</b> vendredi 7 septembre 2018 21:38<br><b>À :</b> Steve Crocker<br><b>Cc :</b> dnsop; dns-operations<br><b>Objet :</b> Re: [dns-operations] [DNSOP] DNSSEC threshold signatures idea<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><div><div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Sep 6, 2018 at 2:15 PM Steve Crocker <<a href="mailto:steve@shinkuro.com">steve@shinkuro.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In parallel, there is work on open source hardware crypto that can easily be extended to include this functionality.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>Yup. Two of my concerns are:<o:p></o:p></span></p></div></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>1: the HSM has to have a bunch more complexity / content awareness than is usual - most HSMs simply take a blob and sign it / store keys. This will require the HSM to have much more understanding of the content, and understand who the "owner" of each RR is, NSEC / NSEC3 , etc. This logic all needs to live inside the security envelope, not in the system driving it. Any "interesting" new resource record types will require updating of the secure logic. This will be largely a one-off bit of code, and will require careful code review of the initial, and any new code (and based upon the amount of review of <a href="https://github.com/iana-org/dnssec-keytools">https://github.com/iana-org/dnssec-keytools</a> I'm not sure the community has the time / desire). Any scewup by the HSM makes 1: that TLD or 2: the entire zone unavailable. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>2: Based upon things like <a href="https://ianix.com/pub/dnssec-outages.html">https://ianix.com/pub/dnssec-outages.html</a>, it is clear that even TLD operators sometimes manage to shoot themselves in the foot. Yes, the majority of these are expirations, but it is clear that people will mess this up. The root KSK is well protected, with people being really careful, but even that has some risk - multiply that by the number of TLDs (or opted in TLDs) and the risks multiply. This means that you really really need a fast, reliable way to regain access in the event of an Oops... and now you have what looks awfully like a backdoor. <o:p></o:p></span></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal>There are some important governance and process details alluded to but not fleshed out in the paper.. Happy to discuss with anyone interested.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>Thank you, happy to discuss further, but the above concerns are why I think (at least at the beginning) why something similar to Certificate Transparency but for the root zone is much safer - yes, it provides deterrence through transparency instead of inviolate crypro protection - but this same reason prevents a minor mistake turning into a major outage.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>This is a summary of a document from back in ~2015 (before the PTI transition, and so the terminology / focus is historic):<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>------------------------<o:p></o:p></span></p></div><div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>*Sunlight is the best disinfectant.*</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>Currently, the entity that generates the root zone has full control over the contents. While this is not a new issue or concern, it is being brought to the public eye because of the IANA transition. To ensure that that entity doesn’t abuse the power/privilege, or make incorrect or unauthorized changes, we propose the following.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>Transparency and accountability are both fundamental to the safe and successful management of IANA, regardless of under whose management IANA sits. To that end, we propose a publicly verifiable, published audit trail for any and all changes to the root zone. No invisible/unaudited changes will be able to be made to the root zone by any party. The entity generating the root zone has full control over what ends up in the file; in order to ensure that there are no abuses of this power, any and all changes to the root zone would require a full audit trail.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>To implement this technically, each TLD operator will cryptographically sign and publicly publish any requested updates to their entries in the root zone. No changes will be made to the root zone without accompanying signatures. The entity generating the root zone will validate all signatures before making the changes. Because all of this will be public, auditors will be able to see from whom the request originated, how it was validated, and when it was implemented. This is a general case/solution; emergency backup procedures will also be in place as needed (i.e., if a country loses its signing key).</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>So, if the ‘example’ TLD wanted to update its nameservers, it would generate a change request (format to be discussed later) and digitally sign the request. It would then publicly publish this change request. The IANA Functions Operator would then validate the change request for technical accuracy, and publically sign the change request to confirm that it is technically correct. The root zone maintainer will validate that the change request is correctly signed by both the requester and the IANA functions operator, and will then make that change in the root zone.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>Note that this solution does not prevent malfeasance by the IANA functions operator, or the root zone maintainer; but as all changes are published with cryptographic signatures, auditors can validate this.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>There will also need to be solutions in place to deal with loss of keys by the TLD operator, and the IANA. The TLD operator can roll to a new key by signing it with their old one, which invalidates the old key.</span><o:p></o:p></p></div></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>-----------------------<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>Somewhere I still have the full document, a proposed encoding, a modified Certificate Transparency log which will accept arbitrary text blobs (and an extension to allow templates in certificates), client software, etc.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Verdana","sans-serif"'>W<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Steve<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Sep 6, 2018 at 1:34 PM, Hugo Salgado-Hernández <<a href="mailto:hsalgado@nic.cl" target="_blank">hsalgado@nic.cl</a>> wrote:<o:p></o:p></p><p class=MsoNormal>Hi Mukund.<br>I talked about this to Davey in Montreal. There's an implementation<br>in github[1] and presentations in OARC[2] and ICANN[3].<br><br>I'm not sure if its being used right now in a live zone, but certainly<br>in labs and testing. There's been some interests with academic<br>institutions, but don't think they're ready yet.<br><br>We've been trying to focus this technology as a "poor-man" HSM, as<br>having similar security features without buying an expensive HW.<br>But I think the root and similar high-value zones will benefit for<br>having an split of the private key AND the fact of not needing a<br>"root key ceremony" to sign, because you can sign remotely with<br>each piece of the private key, and transmit the "signature pieces"<br>to a central place.<br><br>Hugo<br><br>[1] <a href="https://github.com/niclabs/docker/tree/master/tchsm" target="_blank">https://github.com/niclabs/docker/tree/master/tchsm</a><br>[2] <<a href="https://indico.dns-oarc.net/getFile.py/access?contribId=22&sessionId=3&resId=1&materialId=slides&confId=20" target="_blank">https://indico.dns-oarc.net/getFile.py/access?contribId=22&sessionId=3&resId=1&materialId=slides&confId=20</a>><br>[3] <<a href="http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-dnssec-cryptographic-20nov13-en" target="_blank">http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-dnssec-cryptographic-20nov13-en</a>><o:p></o:p></p><div><div><p class=MsoNormal> <br><br>On 21:42 06/09, Mukund Sivaraman wrote:<br>> During a coversation about the Yeti project, Davey Song brought up an<br>> idea about using threshold signatures within DNSSEC. While he talked<br>> about it primarily for the root zone within the context of having<br>> multiple signers for it, I'm curious to know what operators think about<br>> the concept for other zones, and if there's any interest in having a<br>> working implementation.<br>> <br>> DNSKEY RRs contain public keys. Corresponding secret keys are managed by<br>> signing entities in various ways:<br>> <br>> * It may be for a low-risk zone and a human may leave the key on the<br>> nameserver itself<br>> <br>> * The key may be held by some number of trustworthy staff offline and<br>> when signing is required, one of them signs the zone and returns the<br>> signed zone<br>> <br>> * It may be managed by an automated system under the control of one or<br>> more people<br>> <br>> * It may be held in a locked computer system which may be accessed when<br>> multiple trustworthy "keepers" are present<br>> <br>> * There may be schemes like this:<br>> <a href="https://www.icann.org/news/blog/the-problem-with-the-seven-keys" target="_blank">https://www.icann.org/news/blog/the-problem-with-the-seven-keys</a><br>> <br>> In many of these cases, it may be possible for one rogue person to sign<br>> records against the wish of the rest of the trustworthy group appointed<br>> by a zone owner. Even though it's unlikely, it's possible to do so<br>> because the control over secret key material may be available to one<br>> person, even if it is wrapped in multiple layers.<br>> <br>> The concept of threshold crypto is that there is a public DNSKEY, for<br>> which the secret key is not available in a single form where it can be<br>> reconstructed. Instead, N members of a group have some key material each<br>> respectively, and any M (< N) members of the group may work together to<br>> prepare RRSIGs by using their respective key materials individually, and<br>> collaborating to generate the signatures.<br>> <br>> It may be possible for such a scheme to be compatible with existing<br>> DNSSEC algorithms. Is there any operator interest in this?<br>> <br>> Mukund<br>> <br>> _______________________________________________<br>> DNSOP mailing list<br>> <a href="mailto:DNSOP@ietf.org" target="_blank">DNSOP@ietf.org</a><br>> <a href="https://www.ietf.org/mailman/listinfo/dnsop" target="_blank">https://www.ietf.org/mailman/listinfo/dnsop</a><br>> <o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>DNSOP mailing list<br><a href="mailto:DNSOP@ietf.org" target="_blank">DNSOP@ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/dnsop" target="_blank">https://www.ietf.org/mailman/listinfo/dnsop</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>_______________________________________________<br>DNSOP mailing list<br><a href="mailto:DNSOP@ietf.org" target="_blank">DNSOP@ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/dnsop" target="_blank">https://www.ietf.org/mailman/listinfo/dnsop</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><p class=MsoNormal>I don't think the execution is relevant when it was obviously a bad idea in the first place.<br>This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.<br> ---maf<o:p></o:p></p></div></div></div></div></div></div></body></html>