<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>For ease of discussion I'll refer to the idea of bypassing encryption on the web for P97 compliance as "NO-CRYPT."<br></div><div><br></div><div>First a couple of general comments:<br></div><div><br></div><div>1) My expectation is that NO-CRYPT would be most useful during times of non-emergency. During declared emergencies, and assuming a permissive stance by the FCC, NO-CRYPT or equivalent should be immediately disabled. This would address the issue of "civilians" like hospital employees not having unfettered access to content on the web via HamWAN.<br></div><div><br></div><div>2) Perfection would be nice, but it's not a design requirement. If NO-CRYPT increases the usefulness of HamWAN even to a modest degree during non-emergency operations by enabling access to additional web content, I would count that as a win. <br></div><div><br></div><div>3) There's nothing to prevent any particular HamWAN connected sites from simply not using the NO-CRYPT scheme if they choose to. The main intention is to find a way to make as much web content accessible as possible during non-emergency times, and thereby increase the usefulness of HamWAN for any participants wanting to do so. Maybe google.com can't be accessed via HamWAN during non-emergency times. If so, I'll still sleep at night.<br></div><div><br></div><div>Echoing Bryan's comment, I too would be concerned that any clarification of Part 97 could be made to the detriment of us all. As lawyers are apt to say: Never ask a question unless you already know the answer. That applies well to the FCC.<br></div><div><br></div><div>As to Doug's comment, I would like as much as possible to avoid a user having to do much of any config or tweaking on their browser, such as specifying a web proxy. That may end up being unavoidable, but I'm starting with goal of not requiring that. That's why I'm focused (for the moment) on using a transparent proxy. <br></div><div><br></div><div id="Zm-_Id_-Sgn"><div><div><br></div><div>I'm aware of Expect-CT, certificate pinning, and HSTS. There are other obstacles that have not even been mentioned. But I guess we'll have to see what testing shows. <br></div><div><br></div><div>I repeat: Implementing NO-CRYPT for web traffic is very non-trivial, but it may be workable. <br></div><div><br></div><div>John C. Miller<br></div><div><a href="mailto:kx7jm@jmit.com" target="_blank">kx7jm@jmit.com</a><br></div><div>(530)873-9005<br></div></div><div><br></div></div><div class="zmail_extra" style=""><div><br></div><div id="Zm-_Id_-Sgn1">---- On Fri, 16 Aug 2019 19:13:50 -0700 <b>Jake Visser <visser.jacob@outlook.com></b> wrote ----<br></div><div><br></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); padding-left: 6px; margin: 0px 0px 0px 5px;"><meta><meta><div class=" zm_-7921335677902783707_parse_-595698474028852375"><div class="x_1080696893WordSection1"><p class="MsoNormal">> From reading the draft, it looks like adding a root cert will still allow over<br> riding this</p><p class="MsoNormal"> <br></p><p class="MsoNormal">Your right – that is the intent; but in current implementations, it’s the “it is acceptable” wording that is interpreted. In all cases so far the “SHOULD NOT” submit a report is honored, but Chrome isn’t going to let you load google using
any certificate not issued by a google. There are ways around this for enterprise deployments; and it probably is a fair assessment that hams could deploy a second browser configured in that manner… but for a general user, its going to be a lot harder than
just installing a new root cert.<br></p><p class="MsoNormal"> <br></p><div style="border: none;border-top: solid rgb(225,225,225) 1.0pt;padding: 3.0pt 0.0in 0.0in 0.0in;"><p class="MsoNormal" style="border: none;padding: 0.0in;"><b>From: </b><a href="mailto:Bryan@bryanfields.net" target="_blank">Bryan Fields</a><br> <b>Sent: </b>Friday, August 16, 2019 6:58 PM<br> <b>To: </b><a href="mailto:psdr@hamwan.org" target="_blank">Puget Sound Data Ring</a><br> <b>Subject: </b>Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN</p></div><p class="MsoNormal"> <br></p><p class="MsoNormal">On 8/16/19 9:40 PM, Jake Visser wrote:<br> > Much like HSTS; Expect-CT is starting to be deployed too (this replaces<br> > certificate pinning). <br> > <a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FHeaders%2FExpect-CT&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809698674&sdata=kzuM9RFUO816UaYPT%2FpYBwcR1khLM86O1QLIK6PeMj0%3D&reserved=0" target="_blank"> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FHeaders%2FExpect-CT&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809698674&sdata=kzuM9RFUO816UaYPT%2FpYBwcR1khLM86O1QLIK6PeMj0%3D&reserved=0</a><br> > <br> > This will prevent users from accessing sites that are signed by a<br> > certificate that does not appear in the public transparency logs…<br> <br> From reading the draft, it looks like adding a root cert will still allow over<br> riding this. Is that not what 2.4.1 speaks of in there? I'll admit I'm not<br> up on the newest SSL standards.<br> <br> > The best option – if this is truly to be used for emergency communications<br> > – is to try the proposed FCC path.<br> <br> I would say we not try that. The FCC rules can be interpreted a number of<br> different ways now, it's likely if we ask for clarification they may do so in<br> a way making this all a violation. Right now the FCC rules are moot on<br> encryption, the word doesn't appear in part 97 at all.<br> <br> -- <br> Bryan Fields<br> <br> 727-409-1194 - Voice<br> <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbryanfields.net&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=B5gtHYNuNHid52YmaWu205rclAQzDiRyC5sMXi%2FKix4%3D&reserved=0" target="_blank">https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbryanfields.net&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=B5gtHYNuNHid52YmaWu205rclAQzDiRyC5sMXi%2FKix4%3D&reserved=0</a><br> _______________________________________________<br> PSDR mailing list<br> <a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br> <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hamwan.net%2Fmailman%2Flistinfo%2Fpsdr&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=XPLFa%2FJlJkZanR4uB4CGLo9GAwhvREibuhu3NMnxLZs%3D&reserved=0" target="_blank">https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hamwan.net%2Fmailman%2Flistinfo%2Fpsdr&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=XPLFa%2FJlJkZanR4uB4CGLo9GAwhvREibuhu3NMnxLZs%3D&reserved=0</a></p><p class="MsoNormal"> <br></p></div></div><div>_______________________________________________<br></div><div>PSDR mailing list<br></div><div>PSDR@hamwan.org<br></div><div>http://mail.hamwan.net/mailman/listinfo/psdr<br></div></blockquote></div><div><br></div><style><br><br></style><div><br></div></div><br></body></html>