RE: Announcing the QUIC Privacy & Security Workshop @ NDSS (Feb 23-26 2020)

[Antoine Delignat-Lavaud <[e-mail]>]

I’m looking into it – I hope we can offer some form of remote participation.

Best,
Antoine

From: QUIC <[e-mail]> On Behalf Of Christian Huitema
Sent: 07 October 2019 19:19
To: Antoine Delignat-Lavaud <antdl=[e-mail]>
Cc: QUIC Working Group <[e-mail]>
Subject: Re: Announcing the QUIC Privacy & Security Workshop @ NDSS (Feb 23-26 2020)

Will you consider remote participation to the workshop?
-- Christian Huitema


On Oct 7, 2019, at 10:02 AM, Antoine Delignat-Lavaud <antdl=[e-mail]<mailto:antdl=[e-mail]>> wrote:

Full call for papers: https://www.ndss-symposium.org/ndss2020/cfp-quic-privacy-and-security-workshop/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ndss-symposium.org%2Fndss2020%2Fcfp-quic-privacy-and-security-workshop%2F&data=02%7C01%7Cantdl%40microsoft.com%7C1887e47f3ca44399546108d74b4af290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637060657583748133&sdata=Qz2qPa3p3CE6Qc%2Bj1j8MJj7G7EnK7uVTVM3NKAODohw%3D&reserved=0>

We are pleased to announce that the Network and Distributed System Security symposium (NDSS, organized by the Internet Society) will be hosting a QUIC Privacy & Security [QUIPS] workshop next year. The goal of this workshop is to bring security analysis results reviewed by a panel of academic and industrial experts to the attention of the QUIC working group and developer communities in order to build confidence in and improve QUIC before its widespread deployment. We are seeking contributions covering many aspects of the design and implantation of QUIC, including (but not limited to):



  *   Integration with the TLS 1.3 handshake: QUIC is designed to re-use the TLS 1..3 [RFC8446] authenticated key exchange protocol that produces the traffic secrets used to encrypt QUIC packets. While the TLS 1.3 key exchange protocol has received extensive formal analysis effort during its standardization, QUIC’s modular use of the TLS handshake to generate secrets and authenticate negotiated transport parameters has not received as much attention. Some of the properties of TLS 1..3, such as the authentication by the handshake of the termination of 0-RTT data by the “end of early data” message, rely on assumptions that hold for the TLS record layer, but not for the QUIC record layer.


  *   Packet protection: analysis of TLS assume reliable, ordered delivery of network messages, which does not hold in QUIC. The effect of packet loss on QUIC’s record layer security is important and not well understood. Moreover, QUIC’s record layer provides features that TLS does not, such as header protection. Capturing the semantics of this new packet protection algorithm and proving its security is critical.


  *   Denial of Service (DoS) features: QUIC has a number of features designed to reduce the effects of DoS, both on individual connections, such as duplicate packet detection and complete packet protection, server resources, such as Retry, and the resources of bystanders, such as anti-reflection. It has yet to be shown whether or not these techniques achieve their desired goals.


  *   Privacy: many of QUIC’s new features account for and attempt to mitigate the linkability of packets to users across network paths and between connections. For example, voluntary connection migration requires endpoints to use new connection identifiers if possible as a way of preventing cross-path linkability. Also, as a means of improving endpoint privacy postures, among others, QUIC does not mandate endpoints provide any way for networks to measure per-connection Round Trip Time (RTT). The optional spin bit is the only signal made willingly available to the network. Currently, there is no strong analysis supporting the concrete privacy benefits these features provide to QUIC endpoints.


  *   Application security: while TLS exposes a socket-based send/recv interface, QUIC integrates most of the dynamic stream multiplexing interface from HTTP/2.. Applications must target this new interface, leading to new protocols such as HTTP/3. The security implications of the new transport interface for legacy and new applications are not well studied. For instance, it is unclear how an application can tell apart which parts of incoming messages have been protected with the 0-RTT or the 1-RTT secret.

Submissions are due on December 13 and must be submitted to https://easychair.org/conferences/?conf=quips20<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feasychair.org%2Fconferences%2F%3Fconf%3Dquips20&data=02%7C01%7Cantdl%40microsoft.com%7C1887e47f3ca44399546108d74b4af290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637060657583758128&sdata=Noj8hz4sa5mq786XqWE15Azax3PgkPR3yIDjoriwTBU%3D&reserved=0>
Registration to the workshop will be part of the registration process for NDSS (TBA on https://www.ndss-symposium.org/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ndss-symposium.org%2F&data=02%7C01%7Cantdl%40microsoft.com%7C1887e47f3ca44399546108d74b4af290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637060657583758128&sdata=Xcfpj8HYuWUAruvrZ10L3JQK19kDZcbkWfNB%2F3Vswyc%3D&reserved=0>)

We are looking forward to see you best work towards making a QUIC a secure protocol.

Best regards,
The QUIPS Chairs
Antoine Delignat-Lavaud & Christopher Wood