<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Regardless of the ins and outs being discussed so far,  our "Dear
    Leaders" in the 5 eyes alliance were<br>
    already meeting to discuss taking it further in the past week or
    two.<br>
    This was a bit hidden as Australia took time out to roll yet another
    PM, which was likely convenient<br>
    for some of the players.<br>
    Never the less, the push is on against encryption by the spooks, and
    we need to push back in equal<br>
    response to this intrusion.<br>
<a class="moz-txt-link-freetext" href="https://www.stuff.co.nz/technology/106775413/internet-society-fears-five-eyes-could-be-about-to-undermine-the-net">https://www.stuff.co.nz/technology/106775413/internet-society-fears-five-eyes-could-be-about-to-undermine-the-net</a><br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 3/09/2018 7:47 p.m., Paul Wilkins
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMmROTK_sTkP_ki4k_AECC0aB4f1h6OhEKxJ30c39Xm43UY6rQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">3 - Also in this ideal world, this one
              government agency issuing the warrant SSL<br>
               certificates, and collecting warrant data, would have
              it's DNS DNSSEC signed ;)<br>
            </div>
            <div dir="ltr">
              <div><br>
              </div>
              <div><span style="color:rgb(0,0,0)">Kind regards</span></div>
              <div class="gmail-yj6qo gmail-ajU">
                <div id="gmail-:10f" class="gmail-ajR" tabindex="0"><span
                    style="color:rgb(0,0,0)"><img class="gmail-ajT"
                      src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"
                      moz-do-not-send="true"></span></div>
              </div>
              <span class="gmail-HOEnZb gmail-adL"><font color="#888888">
                  <div><span style="color:rgb(0,0,0)">Paul Wilkins</span></div>
                  <div><br>
                  </div>
                </font></span></div>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Mon, 3 Sep 2018 at 16:56, Paul Wilkins <<a
            href="mailto:paulwilkins369@gmail.com"
            moz-do-not-send="true">paulwilkins369@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir="ltr">
            <div>Point taken that the point of insertion is inband as
              opposed to existing procedures for wire taps.</div>
            <div><br>
            </div>
            <div>1 - Having multiple agencies all requiring access (as
              the bill does) is going to create a multitude of possible
              targets (m x n) to act as vectors. This is clearly a
              vulnerability. An alternate approach would be to have a
              single government agency with access, which would then
              relay the information to the original agency requesting
              access. Hence content providers would be required to allow
              only 1 VPN from law enforcement to the point of insertion.</div>
            <div><br>
            </div>
            <div>2 - In an ideal world, each warrant request could be
              accompanied by the issue of a specific SSL key. An
              identifier assigned to the warrant could be included in
              the SSL key as an OID Alternate Name. Then any transfer
              related to that warrant could be protected using that
              specific SSL key. It would then be up to this one law
              enforcement agency to ensure the key remains secure. This
              agency could operate as a CA for all such keys.<br>
            </div>
            <div><br>
            </div>
            <div>Kind regards</div>
            <div><br>
            </div>
            <div>Paul Wilkins<br>
            </div>
          </div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr">On Mon, 3 Sep 2018 at 15:33, Chris Ford <<a
                href="mailto:chris.ford@inaboxgroup.com.au"
                target="_blank" moz-do-not-send="true">chris.ford@inaboxgroup.com.au</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
              Paul,<br>
              <br>
              > I think we can envisage that the proposed regime
              could be made to work by issuing content providers<br>
              > with Technical Capability Notices that would require
              the content provider to create asecure channel for<br>
              > access to the clear text, similar to how secure OOB 
              can be enabled for remote users. Traditional AAA<br>
              > mechanisms could be used to ensure that access is
              secure, logged and audited to ensure all accesses<br>
              > have been duly authorised.<br>
              <br>
              I agree that this is probably one way it might work, but
              my problem is that the endpoint for this "secure" channel
              is not hidden in the carrier or CSPs network. It needs to
              be accessible by the service provider and LEA, and hence
              is open to the internet. It would only be a matter of time
              before that is exploited.<br>
              <br>
              Chris<br>
              _______________________________________________<br>
              AusNOG mailing list<br>
              <a href="mailto:AusNOG@lists.ausnog.net" target="_blank"
                moz-do-not-send="true">AusNOG@lists.ausnog.net</a><br>
              <a href="http://lists.ausnog.net/mailman/listinfo/ausnog"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
            </blockquote>
          </div>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
AusNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a>
<a class="moz-txt-link-freetext" href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a>
</pre>
    </blockquote>
    <br>
  <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">
<br /><br />
<hr style='border:none; color:#909090; background-color:#B0B0B0; height: 1px; width: 99%;' />
<table style='border-collapse:collapse;border:none;'>
        <tr>
                <td style='border:none;padding:0px 15px 0px 8px'>
                        <a href="https://www.avast.com/antivirus">
                                <img border=0 src="https://static.avast.com/emails/avast-mail-stamp.png" alt="Avast logo" />
                        </a>
                </td>
                <td>
                        <p style='color:#3d4d5a; font-family:"Calibri","Verdana","Arial","Helvetica"; font-size:12pt;'>
                                This email has been checked for viruses by Avast antivirus software.
                                <br><a href="https://www.avast.com/antivirus">www.avast.com</a>
                        </p>
                </td>
        </tr>
</table>
<br />
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>