Re: [Smart] SMART Problems

[Bret Jordan <[e-mail]>]

Kristy,

Zero Trust, Borderless Networks, Firewall-less networks (Google’s BeyondCorp), LTE5, Direct-to-net / Direct-to-Telco, Employee owned devices, SDN, TLS1.3, DOH + DNSSEC, QUIC, Cloud Services, MicroServices, etc are going to collectively wreck havoc with traditional network defense. By themselves they are all manageable and great additions to the performance, management, security, and privacy of the network, however, when you start connecting all of these technologies together as a single solution, it is going to pose some serious challenges.

In a past life we had a saying that  “endpoints, operating systems, and software can all be made to lie, but the network never does. At some point the traffic has to flow over the network”.  So making sure we understand the risks associated with assuming that all security can be done on the endpoint, would be good. 

Understanding the risks of overlay protocols. What happens if organizations, ISPs, Telcos, start wrapping some of our secure protocols with less secure protocols to make them work across their networks. 


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Oct 11, 2018, at 2:58 AM, Kirsty P <Kirsty.p=[e-mail]> wrote:
> 
> Hi everyone,
> 
> We've heard from a few people on these initial ideas, but more discussion is welcome - are there any problems we're missing and should be focusing on? 
> 
> Kirsty
> 
> 
> From: Kirsty P
> Sent: 01 October 2018 14:22
> To: [e-mail] <mailto:[e-mail]>
> Subject: SMART Problems
>  
> Hi SMART folks,
> 
> I promised an initial problems list that the group could be working on, so here it is! Please comment and/or add your own research ideas/existing projects those we've sketched out below...
> 
> Kirsty
> Assessment methodology: Systematic analysis of attack defence impacts requires an evidence-based methodology. Research will start with a survey of existing attacks and existing detection methods. The information used by each detection method from Internet protocols and other sources (such as endpoints) shall be identified. Further research will determine the relative effectiveness of each detection method against each attack. In doing so, this research will define methodologies for detection, as known attacks change and detection methods develop. These methodologies can be used to provide the basis of evidence for assessment of protocol impact.
> Certificate Transparency: Certificate transparency can be used to spot mis-issued certificates for domains. But do certificate transparency logs highlight malicious domains? More research is needed to determine the effectiveness of this technology in finding malicious sites.
> DMARC: Implementation of DMARC across government correlates with the numbers of phishing emails claiming to be from these domains dropping dramatically. Research is needed to ascertain the exact effects of implementing this protocol and to discover what impact, if any, this has had on the behaviour of the actors behind such phishing emails.
> DNS: As protocols to encrypt DNS traffic are implemented and newly-proposed designs surface, existing techniques for restricting DNS lookups to blacklisted domains may be impacted and could increase the risk from malware to a network. The IRTF can bring together network operators and protocol experts to research and discover new ways to provide this security as DNS traffic becomes encrypted.
> IPv6: Adoption of IPv6 is now widespread, with statistics from 2017 indicating that 23% of networks advertise IPv6 connectivity. Evidence-based research is needed to establish what benefits or risks come from IPv6 adoption in terms of attack defence, and to find recommendations to optimise defence protections.
> TLS: With a new version of TLS recently standardised, existing attack defence methods need to adapt as implementations begin to adopt it. This area of research needs to grow quickly, with key questions such as: “Can malware be detected when it uses TLS 1.3? If so, how?” The IRTF is the ideal place to stimulate this thread of work, to bring together members with protocol expertise and members with defence experience.
> UDP: Some firewalls and middleboxes simply block UDP, in their efforts to protect networks from malicious traffic – so much so that this issue was considered in the design of QUIC. When QUIC is standardised, UDP traffic will only grow in volume, and it will be more important than ever to research techniques for detecting malicious activity in encrypted UDP streams, enabling a better malware defence than simply blocking UDP traffic in future.
> 
> 
> 
> This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [e-mail] <mailto:[e-mail]> -- 
> Smart mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/smart <https://www.irtf.org/mailman/listinfo/smart>