<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"></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">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></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">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">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" rel="noreferrer" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div>
</blockquote></div>