Re: Fwd: New Version Notification for draft-kazuho-quic-authenticated-handshake-00.txt
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 14 December 2018 13:05 UTC
Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C24212785F for <quic@ietfa.amsl.com>; Fri, 14 Dec 2018 05:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66RqsfjnT_6v for <quic@ietfa.amsl.com>; Fri, 14 Dec 2018 05:05:02 -0800 (PST)
Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AD81286E3 for <quic@ietf.org>; Fri, 14 Dec 2018 05:05:01 -0800 (PST)
Received: by mail-it1-x129.google.com with SMTP id a6so9147076itl.4 for <quic@ietf.org>; Fri, 14 Dec 2018 05:05:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SZWnzSZL68/gg1P2nTzdTOLcu0cmONxyxdznZ+rwDdA=; b=Zb7mbm88l/j3hmGHK1q4p6T8TK4VTutFxt9K7uRcXFTC40qMNF8YRAhI4jTQ1uJFu2 hEBRL0dgkv1NMrLDqXrIJkMi19rCFEm9/v5RTjMcgSvuWtPmURwo8RhYKuP25C8mRs0m l5P0zZCwRGS0SUN8ZyJoA/QHziWr4CUH800bujbqAo5UDQF3Z+xP9OV2Ay3alAv9/VHk 4eQ/OWuR0zUYwcPkO0DJbp4EthW5WkvhdhYpLUfoiU+mCpVUyRylNtp7tNOUAvzOMtGJ 9rdRVhlIIFDYGjJh/Tj0j0zgmzEWdlvndEA7G9o6NIuFYNDHJo83rC4fbLbO8zkwv50W YgWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SZWnzSZL68/gg1P2nTzdTOLcu0cmONxyxdznZ+rwDdA=; b=ueMxXe89UgDaaG+0eDJZpsemiSlHeYDRMtGDFPkoq0KJMv3qKy0U1SUXf010pgyWuR XxlHY/SWPQT0Ts+s34wZOmX82VsvoWEK5VyaIXd+Pc4kgK8/q+rsFaelWfG8etZmhKUj IeNRy0BvMs6eEPdQZroJTl6jZtWmvzp6MupaXiWzZBL4bQ6sC/dGDsbqnQTdAFvTQXUt 2AwZ/X9aui7q54X3s1yiflxbcexCU+4E9i+th6CVaEuaFchXchLlVdzDIlFcLEG44+Pp dHlyBeplHCzbTi+TvMXoB/aLvcEd9WGrcMcg5O2zX5L++BZey1mx5ZYIi22FV1Rsb7kt pUMw==
X-Gm-Message-State: AA+aEWYCLnTuUqD37TY0pK4Zc839DV2bFW3bDqw6okF/7VnZlGPMsIcl Urmne4xgOU2KV4cP0PxoKJPfRViKIsFyAXm1ZdAwjg==
X-Google-Smtp-Source: AFSGD/VzyGgvcjXj+x3aakryuxT/I9aoS5RzIOvYQO18hKlaMcdoz9kY0uZ4eiH34FPRnLMxILsi3G3Et+MPgSdlvjk=
X-Received: by 2002:a05:660c:58a:: with SMTP id g10mr2782005itk.167.1544792700220; Fri, 14 Dec 2018 05:05:00 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 14 Dec 2018 05:04:59 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CANatvzwbL-NoRK1boZmFkA8kEvJzCQTP26FCh31_c0rRrYvSOw@mail.gmail.com>
References: <154475462982.32005.8870303572182973327.idtracker@ietfa.amsl.com> <CANatvzwbL-NoRK1boZmFkA8kEvJzCQTP26FCh31_c0rRrYvSOw@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 14 Dec 2018 05:04:59 -0800
Message-ID: <CAN1APdcLc4j0D91mJ-PuunknQsbWWvRdCjrj=z=BrYs0uWkNLw@mail.gmail.com>
Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-authenticated-handshake-00.txt
To: IETF QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary="00000000000025fd71057cfb1450"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g68Fs8pu-CyEnqI9einKyxSc8qQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2018 13:05:08 -0000
Some thoughts: 1. this is the only way to go both due to SNI privacy / censoring, and injection attacks. 2. if this is not v1, we risk a split similar to http vs https, which could defer acceptance for a decade - but OTOH there are is complexity to discuss - maybe consider a simple v1 and a better v2. 3. depending on an external DNS service and signature design, this might be more vulnerable to gov. coercion than TLS records alone. Does this matter? 4. text should consider alternative key distribution mechanisms for private networks over public networks. I.e. I don’t trust/bother with DNS, but I can install public keys at all clients, or shared symmetric keys. 5. I am concerned about DoS attacks on public key crypto - it may take time to verify tag. 6. I don’t understand the initial crypto being the same as v1 - does this mean that client TP is still externally visible - shouldn’t that be avoided? 7. is this tied too heavily in with TLS considering other versions that might want to use more light weight crypto - e.g. version negotiation is now after public crypto, and public crypto flavour might be unfriendly to constrained devices. 8. The entire DNS infrastructure is in need of an overhaul, including possibly DNS over QUIC. How does that work? 9. HMAC - what about new hashes like SHA-3? Yes - QUIC v1 also uses HMAC same question, same answer. 10. This still doesn’t address rewriting source/target IP addresses either as a replacement, or a race, in handshake and migration, so some analysis is needed to state this is a significant improvement despite of this. Mikkel On 14 December 2018 at 03.34.20, Kazuho Oku (kazuhooku@gmail.com) wrote: TL;DR: Christian and I have submitted an I-D that proposes a flavor of QUIC v1 that uses the Encrypted SNI key to authenticate Initial packets. Initial packets are no longer vulnerable to man-on-the-side attacks; the entire handshake process becomes tamper-proof. https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/ ## Background So far, we have spent multiple efforts to make QUIC resistant to man-on-the-side attacks. Among them, mitigating injection attacks of Initial packets has been the biggest head-ache. There have been various proposals (including #2045, #2053, #2076), but the question has always been if it's worth the effort, because there are so many attack vectors (e.g. injection of a packet carrying a corrupt header, invalid or unknown frames, ACKs with unsent PNs, crafted TLS Hellos, HelloRetryRequests, crafted Version Negotiation or Retry packets) and it is doubtful if having mitigations for just one or few types of attacks are meaningful. We want to close all the attack vectors, however it is like building house of cards. ## The Proposed Approach The draft introduces a different approach. It relies on the Encrypted SNI [1]. For people not familiar with Encrypted SNI, it is an extension of TLS 1.3 that uses a public key distributed using DNS to encrypt the SNI. Encrypted SNI is currently a TLS WG draft, has multiple implementations, and it is already deployed by Cloudflare and Mozilla. The approach proposed by the draft is to use a shared secret that is derived from the Encrypted SNI key to authenticate the Initial packets, using HMAC. Because the shared key can only be calculated by the endpoints, an attacker cannot spoof the Initial packets. Spoofed packets will be detected by HMAC and will be to dropped. The draft disables Version Negotiation (because the DNS record of Encrypted SNI can carry a list of QUIC versions supported by the server), a different client-side behavior for handling Retry packets, and also introduces a CONNECTION_CLOSE packet to communicate handshake failures without affecting the transport state. And of course, it also uses a different QUIC version number in the long packet header field so that the Initial packets of QUIC v1 and the authenticated Initial packets of the proposal can be handled differently. Other than that, the protocol is identical to QUIC v1, including the handling of 0-RTT, Handshake, 1-RTT packets and the frames being contained by them. IMO, the differences are small and isolated well enough that QUIC v1 stacks can easily add support for the flavor proposed by the I-D. There are other benefits too. We have always hoped to have multiple versions of QUIC being deployed from early days in order to prevent ossification. The proposal makes that happen. Besides, one interesting aspect of the proposed protection of Initial packets is that MITM boxes (with root certificates) would not be possible to terminate the connection _unless_ they also block the distribution of Encrypted SNI DNS records, and that even then, the existence of such MITM boxes is detectable. Raising the bar of implementing and deploying MITM boxes as well as detecting them is beneficial for the evolution of the protocol. The downside of the proposal is that it only protects QUIC connections going to servers that provide the Encrypted SNI DNS records. But considering our failing attempts to address the Initial packet injection attacks, and considering the amount of interest we have seen for Encrypted SNI, I think that the proposed approach is the way forward. Please let us know what you think. Thank you in advance. PS. The GitHub repository of the I-D is: https://github.com/kazuho/draft-kazuho-quic-authenticated-handshake ---------- Forwarded message --------- From: <internet-drafts@ietf.org> Date: 2018年12月14日(金) 11:30 Subject: New Version Notification for draft-kazuho-quic-authenticated-handshake-00.txt To: Kazuho Oku <kazuhooku@gmail.com>, Christian Huitema <huitema@huitema.net> A new version of I-D, draft-kazuho-quic-authenticated-handshake-00.txt has been successfully submitted by Kazuho Oku and posted to the IETF repository. Name: draft-kazuho-quic-authenticated-handshake Revision: 00 Title: Authenticated Handshake for QUIC Document date: 2018-12-14 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-kazuho-quic-authenticated-handshake-00.txt Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/ Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-quic-authenticated-handshake Abstract: This document explains a variant of QUIC protocol version 1 that uses the ESNI Keys to authenticate the Initial packets thereby making the entire handshake tamper-proof. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Kazuho Oku
- Fwd: New Version Notification for draft-kazuho-qu… Kazuho Oku
- Re: Fwd: New Version Notification for draft-kazuh… Mikkel Fahnøe Jørgensen
- RE: New Version Notification for draft-kazuho-qui… Mike Bishop
- Re: Fwd: New Version Notification for draft-kazuh… Kazuho Oku
- Re: New Version Notification for draft-kazuho-qui… Kazuho Oku
- Re: New Version Notification for draft-kazuho-qui… Eric Rescorla
- Re: New Version Notification for draft-kazuho-qui… Christian Huitema
- Re: New Version Notification for draft-kazuho-qui… Kazuho Oku
- Re: New Version Notification for draft-kazuho-qui… Kazuho Oku
- Re: New Version Notification for draft-kazuho-qui… Christian Huitema
- Re: New Version Notification for draft-kazuho-qui… Kazuho Oku
- Re: New Version Notification for draft-kazuho-qui… Kazuho Oku