<html 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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">This reminded me about SSL/certificate issues. Has been discussed before, but here it is again so folks can think about it before we meet.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The primary driver behind ACA/Honeypot is that it offers a superior client notification experience. This is primarily predicated on the “client” being a traditional browser and the honeypot sending some super-helpful
web content. (By the way, see the JAS 2012 report. This scenario is actually quite infrequent; the vast vast majority of traffic we saw while running honeypots of this type was machine-to-machine protocols not human web stuff. Alas. . . )<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">If we offer SSL, every modern browser will redirect 80 to 443 and display a scary SSL certificate warning. This is unavoidable (*) because we can’t know what FQDN the client is requesting and get proper certs.
Depending on the browser, the helpful content page may not be available without significant hoop jumping that non-experts simply will not do. Especially the non-experts suffering from collisions issues. This will materially reduce the value of this notification.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">If we don’t offer SSL, we won’t know what sorts of things are trying to connect over 443. We will be blind to that protocol and the notification experience will be no different than 2012 style CI (application
layer doesn’t work, check logs).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">It’s a tough spot.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">(*) One potential solution is to convince the CA-Browser Forum to issue someone (presumably ICANN) short-lived wildcard TLD certificates for applied-for domains. That will allow the preferred notification
mechanism to work. I don’t know if any CA will actually do that, but I expect someone will for enough money. The Let’s Encrypt people may be helpful, but I think a wildcard TLD cert violates CA-B policies so there is a larger conversation to be had. Some sort
of “just in time” cert is not completely out of the realm of possibility, but it’s a stretch. . .
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">See the JAS 2012 report, and the email thread on this list on or about February 25, 2022.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jeff<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Jeff Schmidt <jschmidt@jasadvisors.com><br>
<b>Date: </b>Wednesday, August 2, 2023 at 4:00 PM<br>
<b>To: </b>ncap-discuss@icann.org <ncap-discuss@icann.org><br>
<b>Subject: </b>FW: [NCAP-Discuss] Defining CI/CE<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">I think this is the latest </span>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">NCAP-Discuss <ncap-discuss-bounces@icann.org> on behalf of Jeff Schmidt via NCAP-Discuss <ncap-discuss@icann.org><br>
<b>Date: </b>Wednesday, November 9, 2022 at 11:39 AM<br>
<b>To: </b>ncap-discuss@icann.org <ncap-discuss@icann.org><br>
<b>Subject: </b>Re: [NCAP-Discuss] Defining CI/CE</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">Agreeing with Matt (L) - recall in Feb I sent the below/attached to this list attempting to pin down some pesky technical details on these techniques being promoted. My content
is only intended to be a starting point - I would love to see the promoters of these techniques make additions/corrections so at least we're debating from a common frame of reference.<br>
<br>
Jeff<br>
<br>
<br>
> -----Original Message-----<br>
> From: Jeff Schmidt <jschmidt@jasadvisors.com><br>
> Sent: Friday, February 25, 2022 6:28 PM<br>
> To: ncap-discuss@icann.org<br>
> Subject: Re: [NCAP-Discuss] Defining CI/CE<br>
> <br>
> Sorry, I was too imprecise in my SSL certificate language in the last one.<br>
> Please replace with this one.<br>
> <br>
> Thx,<br>
> Jeff<br>
> <br>
> <br>
> On 2/25/22, 6:20 PM, "NCAP-Discuss on behalf of Jeff Schmidt via NCAP-<br>
> Discuss" <ncap-discuss-bounces@icann.org on behalf of ncap-<br>
> discuss@icann.org> wrote:<br>
> <br>
> All:<br>
> <br>
> I think a very important point has come out of this discussion - one of the<br>
> reasons for the circular arguments is that we have never carefully defined CE<br>
> and therefore we're operating under a number of assumptions which have<br>
> vastly different implementation outcomes. Credit to Matt L and Danny for<br>
> pointing this out.<br>
> <br>
> Attached is my shot at a careful technical definition of the Controlled<br>
> Interruption and Controlled Exfiltration options. We need to come to<br>
> consensus on this before we can further discuss/recommend. The attached<br>
> is the most conservative technical approach I can think of. This is just a<br>
> strawman to start the conversation. I'm happy to be wrong on any/all of this.<br>
> But no more glossing over the details - let's be super specific.<br>
> <br>
> I would suggest the Chair(s) "force the issue" and call for consensus on this<br>
> as quickly as discussion allows. Our lack of fundamental agreement here is<br>
> blocking progress on this important item.<br>
> <br>
> Thx,<br>
> Jeff<br>
> <br>
> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>