Paul C. van Oorschot’s research while affiliated with Carleton University and other places

The absence of security measures between DNS recursive resolvers and authoritative nameservers has been exploited by both inline and off-path attacks. While many security proposals have been made in practice and previous literature, they typically suffer from deployability barriers and/or inadequate security properties. The absence of a broadly adopted security solution between resolvers and nameservers motivates a new scheme that mitigates these issues in previous proposals. We present DNSSEC+, which addresses security and deployability downsides of DNSSEC, while retaining its benefits. DNSSEC+ takes advantage of the existent DNSSEC trust model and authorizes the nameservers within a zone for short intervals to serve the zone data securely, facilitating real-time security properties for DNS responses, without requiring long-term private keys to be duplicated (thus put at risk) on authoritative nameservers. Regarding name resolution latency, DNSSEC+ offers a performance comparable to less secure schemes. We define nine security, privacy, and deployability properties for name resolution, and show how DNSSEC+ fulfills these properties.

We provide a brief, accessible introduction to side-channel attacks, a growing subarea of computer security. We explain the key underlying ideas, give a chronological overview of selected classical attacks, and characterize side-channel attacks along several axes.

Web users are increasingly presented with multiple login options, including password-based login and common web single sign-on (SSO) login options such as "Login with Google" and "Login with Facebook". There has been little focus in previous studies on how users choose from a list of login options and how to better inform users about privacy issues in web SSO systems. In this paper, we conducted a 200-participant study to understand factors that influence participants' login decisions, and how they are affected by displaying permission differences across login options; permissions in SSO result in release of user personal information to third-party web sites through SSO identity providers. We compare and report on login decisions made by participants before and after viewing permission-related information, examine self-reported responses for reasons related to their login decisions, and report on the factors that motivated their choices. We find that usability preferences and inertia causes (habituation) were among the dominant factors influencing login decisions. After participants viewed permission-related information, many prioritised privacy over other factors, changing their login decisions to more privacy-friendly alternatives. Displaying permission-related information also influenced some participants to make tradeoffs between privacy and usability preferences.

We carry out a detailed analysis of the security advice coding method (SAcoding) of Barrera et al., which is designed to analyze security advice in the sense of measuring actionability and categorizing advice items as practices, policies, principles, or outcomes. The main part of our analysis explores the extent to which a second coder’s assignment of codes to advice items agrees with that of a first, for a dataset of 1013 security advice items nominally addressing Internet of Things devices. More broadly, we seek a deeper understanding of the soundness and utility of the SAcoding method, and the degree to which it meets the design goal of reducing subjectivity in assigning codes to security advice items. Our analysis results in suggestions for modifications to the coding tree methodology, and some recommendations. We believe the coding tree approach may be of interest for analysis of qualitative data beyond security advice datasets alone.

We consider memory errors and memory safety in the cases of the Java and Rust programming languages. We also give a view of how type safety fits in.

We provide an accessible, self-contained explanation of memory errors as they pertain to programming languages, and the related idea of memory safety. We use the C language as a concrete example.

TLS is an end-to-end protocol designed to provide confidentiality and integrity guarantees that improve end-user security and privacy. While TLS helps defend against pervasive surveillance of intercepted unencrypted traffic, it also hinders several common beneficial operations typically performed by middleboxes on the network traffic. Consequently, various methods have been proposed that “bypass” the confidentiality goals of TLS by playing with keys and certificates essentially in a man-in-the-middle solution, as well as new proposals that extend the protocol to accommodate third parties, delegation schemes to trusted middleboxes, and fine-grained control and verification mechanisms. We first review the use cases expecting plain HTTP traffic and discuss the extent to which TLS hinders these operations. We retain 19 scenarios where access to unencrypted traffic is still relevant and evaluate the incentives of the stakeholders involved. Second, we survey 30 schemes by which TLS no longer delivers end-to-end security, and by which the notion of an “end” changes, including caching middleboxes such as Content Delivery Networks. Finally, we compare each scheme based on deployability and security characteristics, and evaluate their compatibility with the stakeholders’ incentives. Our analysis leads to a number of key findings, observations, and research questions that we believe will be of interest to practitioners, policy makers and researchers.

In practice, the security of a system is often strongly impacted by the tools used to create, configure, and manage each of its constituent components. Here, we consider the role of such tools themselves in the body of knowledge comprising computer and Internet security.

Academic research has highlighted the failure of many Internet of Things (IoT) product manufacturers to follow accepted practices, while IoT security best practices have recently attracted considerable attention worldwide from industry and governments. Given current examples of security advice, confusion is evident from guidelines that conflate desired outcomes with security practices to achieve those outcomes. We explore a surprising lack of clarity, and void in the literature, on what (generically) best practice means, independent of identifying specific individual practices or highlighting failure to follow best practices. We consider categories of security advice, and analyze how they apply over the lifecycle of IoT devices. For concreteness in discussion, we use iterative inductive coding to code and systematically analyze a set of 1013 IoT security best practices, recommendations, and guidelines collated from industrial, government, and academic sources. Among our findings, of all analyzed items, 68% fail to meet our definition of an (actionable) practice, and 73% of all actionable advice relates to the software development lifecycle phase, highlighting the critical position of manufacturers and developers. We hope that our work provides a basis for the community to better understand best practices, identify and reach consensus on specific practices, and find ways to motivate relevant stakeholders to follow them.