Regardless of the ins and outs being discussed so far, our "Dear
Leaders" in the 5 eyes alliance were
already meeting to discuss taking it further in the past week or two.
This was a bit hidden as Australia took time out to roll yet another PM,
which was likely convenient
for some of the players.
Never the less, the push is on against encryption by the spooks, and we
need to push back in equal
response to this intrusion.
https://www.stuff.co.nz/technology/106775413/internet-society-fears-five-eyes-could-be-about-to-undermine-the-net
On 3/09/2018 7:47 p.m., Paul Wilkins wrote:
3 - Also in this ideal world, this one government agency issuing the
warrant SSL
certificates, and collecting warrant data, would have it's DNS DNSSEC
signed ;)
Kind regards
Paul Wilkins
On Mon, 3 Sep 2018 at 16:56, Paul Wilkins <paulwilkins...@gmail.com
<mailto:paulwilkins...@gmail.com>> wrote:
Point taken that the point of insertion is inband as opposed to
existing procedures for wire taps.
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.
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.
Kind regards
Paul Wilkins
On Mon, 3 Sep 2018 at 15:33, Chris Ford
<chris.f...@inaboxgroup.com.au
<mailto:chris.f...@inaboxgroup.com.au>> wrote:
Paul,
> I think we can envisage that the proposed regime could be
made to work by issuing content providers
> with Technical Capability Notices that would require the
content provider to create asecure channel for
> access to the clear text, similar to how secure OOB can be
enabled for remote users. Traditional AAA
> mechanisms could be used to ensure that access is secure,
logged and audited to ensure all accesses
> have been duly authorised.
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.
Chris
_______________________________________________
AusNOG mailing list
AusNOG@lists.ausnog.net <mailto:AusNOG@lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog
_______________________________________________
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
