<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Jeff,<div class=""><br class=""></div><div class="">I'm just looking at this now (apparently I missed it back in February). I think that the issues (happily, but not surprisingly) correlate very well with those in the comparison doc. In particular:</div><div class=""><br class=""></div><div class="">1. "<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">TCP/!(80 & 443)" [1] -> </span>On SYN return RST" and <span style="color: rgb(0, 0, 0);" class="">"UDP/all -> Drop"</span></div><div class=""> - considered in "User Experience" under "Communication Interruption". The differences are:</div><div class=""> - the comparison doc doesn't really specify which ports/applications, but rather speaks more generically (because, again, it doesn't seek to define/specify).</div><div class=""> - the comparison doc proposes suggests that UDP is responded to with ICMP port unreachable for "quick response" rather than dropping.</div><div class=""><br class=""></div><div class="">2. "TCP/80"</div><div class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> - considered in "User Experience" under "Communication Interception" / "Web Browser / HTTP"</div></div><div class=""><br class=""></div><div class="">3. "TCP/443"</div><div class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> - considered in "User Experience" under "Communication Interception" / "Web Browser / HTTPS"</div></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">4. "Timestamp, IP, sport, dport":</span></font></div><div class=""><font color="#000000" class=""> - considered in "<span style="caret-color: rgb(0, 0, 0);" class="">Telemetry".</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">5. "SSL Certificate Note":</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""> - There is a whole discussion on this in the "User Experience" section under "Communication Interception" / "Web Browser / HTTPS".</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Casey</span></font></div><div class=""><br class=""></div><div class="">[1] Should be "!(80 | 443)" :)<br class=""><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 9, 2022, at 10:38 AM, Jeff Schmidt via NCAP-Discuss <<a href="mailto:ncap-discuss@icann.org" class="">ncap-discuss@icann.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">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 class=""><br class="">Jeff<br class=""><br class=""><br class=""><blockquote type="cite" class="">-----Original Message-----<br class="">From: Jeff Schmidt <<a href="mailto:jschmidt@jasadvisors.com" class="">jschmidt@jasadvisors.com</a>><br class="">Sent: Friday, February 25, 2022 6:28 PM<br class="">To: <a href="mailto:ncap-discuss@icann.org" class="">ncap-discuss@icann.org</a><br class="">Subject: Re: [NCAP-Discuss] Defining CI/CE<br class=""><br class="">Sorry, I was too imprecise in my SSL certificate language in the last one.<br class="">Please replace with this one.<br class=""><br class="">Thx,<br class="">Jeff<br class=""><br class=""><br class="">On 2/25/22, 6:20 PM, "NCAP-Discuss on behalf of Jeff Schmidt via NCAP-<br class="">Discuss" <<a href="mailto:ncap-discuss-bounces@icann.org" class="">ncap-discuss-bounces@icann.org</a> on behalf of ncap-<br class=""><a href="mailto:discuss@icann.org" class="">discuss@icann.org</a>> wrote:<br class=""><br class=""> All:<br class=""><br class=""> I think a very important point has come out of this discussion - one of the<br class="">reasons for the circular arguments is that we have never carefully defined CE<br class="">and therefore we're operating under a number of assumptions which have<br class="">vastly different implementation outcomes. Credit to Matt L and Danny for<br class="">pointing this out.<br class=""><br class=""> Attached is my shot at a careful technical definition of the Controlled<br class="">Interruption and Controlled Exfiltration options. We need to come to<br class="">consensus on this before we can further discuss/recommend. The attached<br class="">is the most conservative technical approach I can think of. This is just a<br class="">strawman to start the conversation. I'm happy to be wrong on any/all of this.<br class="">But no more glossing over the details - let's be super specific.<br class=""><br class=""> I would suggest the Chair(s) "force the issue" and call for consensus on this<br class="">as quickly as discussion allows. Our lack of fundamental agreement here is<br class="">blocking progress on this important item.<br class=""><br class=""> Thx,<br class=""> Jeff<br class=""><br class=""><br class=""></blockquote><br class=""><span id="cid:02E348B7-B38D-448E-AF3F-B1A4B9C1777F"><NCAP Implementation Spec2.pptx></span>_______________________________________________<br class="">NCAP-Discuss mailing list<br class=""><a href="mailto:NCAP-Discuss@icann.org" class="">NCAP-Discuss@icann.org</a><br class="">https://mm.icann.org/mailman/listinfo/ncap-discuss<br class=""><br class="">_______________________________________________<br class="">By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</div></div></blockquote></div><br class=""></div></div></body></html>