Proposal: Run QUIC over DTLS
Eric Rescorla <ekr@rtfm.com> Mon, 05 March 2018 23:06 UTC
Return-Path: <ekr@rtfm.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 22EF512EAFC for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 15:06:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 VTBH2IdzUH1r for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 15:06:37 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 CA7B112EB40 for <quic@ietf.org>; Mon, 5 Mar 2018 15:06:31 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id g60so22426533qtd.11 for <quic@ietf.org>; Mon, 05 Mar 2018 15:06:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=fJzF/d/HnC0QkFZk0EknYKaJfQJM/IwlFu3q7xiKSVM=; b=hqVVcpIlC/WctJ5e0ilclc6N8JWWBbKH6RiAtbLVEOg1uc9WGnnRkwUPx4nlUQ6LJO QfGxh4piaoacNI7a3tqXTXiy8wjqAxKxv/YF0f3Nct0L/h4XyjixowauKO73Wd5Twtpa zCcwi/C+PyHk8vPWONb6DC8zP9bO6mhqj/UqEAc9L8PjIHYTkZzKPVDjsm916k+xKeCs F1Y2b36ede6xIlaSoSsuwBFQNhp8CMQm7ex0bjY7EXVSrqkW23Vje0PiCECcOmtWZTym I6mlJ9UTPvVU9srzjlHRJXmPSu2rbbGT0GV0qENevkKVT9V0Bd8wzaXXB4rVQRIXdARQ CDXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fJzF/d/HnC0QkFZk0EknYKaJfQJM/IwlFu3q7xiKSVM=; b=U7Rh9RdqI6Wy5wMnkGJ0NFArYtDyAnKiUEdttKlExKfSXpyhc4khN5rmiO4zwDtoRM pXjdjRjDirTysS6peHRTfzkkYZoEmokMfQBVwSXmU5mbdxNc+XW/AyvmCBXNRKcO2/xZ ZLfiQt7DmLSambDIa2FmnTTpR44ZM1XDLzHcYoZBINH7pJL5LKpVxuk18EZIsJrrik+T Y/FhcSmdMJUy8HdtbNG+/KI3cyCRe+/5AjZbqPnhKQDqflkRC2QrosNt+zSNYIMhqTPY IIjOpOCCvFegkiu+cDF3ZfZOMN9nl7ojHmdBVg42Pep5DwHa86z4uEgi5iRxe1RyWQN5 RX2Q==
X-Gm-Message-State: AElRT7GQKpGjZpqgiBdFhpgEQcjGDxxyLd8egPKGiSIJkSE7dWeRjQBx yu1a0I4UDnv3q4g9XhMq4tRyKPI4ebCNVi0UKPFeVrf4geU=
X-Google-Smtp-Source: AG47ELsgYtpt8GJgcOsPqOTFbHcNaHjLz/vHaM2KR6kx7bfRdPq8F/wWY6GYKbcUJMVypjzB6nmXtk5mYdWE6U7PMrI=
X-Received: by 10.237.32.135 with SMTP id 7mr25037750qtb.287.1520291190619; Mon, 05 Mar 2018 15:06:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 5 Mar 2018 15:05:50 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 05 Mar 2018 15:05:50 -0800
Message-ID: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
Subject: Proposal: Run QUIC over DTLS
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c114ed05f53b80566b2601c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/I4lMWsVNpBvldNDVgPQDE4pS6tY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 05 Mar 2018 23:06:44 -0000
Hi folks, Sorry to be the one randomizing things again, but the asymmetric conn-id thing went well, so here goes.... TL;DR. I'd like to discuss refactoring things to run QUIC over DTLS. DETAILS When we originally designed the interaction between TLS and QUIC, there seemed like a lot of advantages to embedding the crypto handshake on stream 0, in particular the ability to share a common reliability and congestion mechanism. However, as we've gotten further along in design and implementation, it's also become clear that it's archictecturally kind of crufty and this creates a bunch of problems, including: * Stream 0 is unencrypted at the beginning of the connection, but encrypted after the handshake completes, and you still need to service it. * Retransmission of stream 0 frames from lost packets needs special handling to avoid accidentally encrypting them. * Stream 0 is not subject to flow control; it can exceed limits and goes into negative credit after the handshake completes. * There are complicated rules about which packets can ACK other packets, as both cleartext and ciphertext ACKs are possible. * Very tight coupling between the crypto stack and the transport stack, especially in terms of knowing where you are in the crypto state machine. I've been looking at an alternative design in which we instead adopt a more natural layering of putting QUIC on top of DTLS. The basic intuition is that you do a DTLS handshake and just put QUIC frames directly in DTLS records (rather than QUIC packets). This significantly reduces the degree of entanglement between the two components and removes the corner cases above, as well as just generally being a more conventional architecture. Of course, no design is perfect, but on balance, I think this is a cleaner structure. I have a draft for this at: https://datatracker.ietf.org/doc/draft-rescorla-quic-over-dtls/ And a partial implementation of it in Minq at: Mint: https://github.com/ekr/mint/tree/dtls_for_quic Minq: https://github.com/ekr/minq/tree/quic_over_dtls I can't speak for anyone else's implementation, but at least in my case, the result was considerable simplification. It's natural at this point to say that this is coming late in the process after we have a lot invested in the current design, as well as to worry that it will delay the process. That's not my intention, and as I say in the draft, many of the issues we have struggled over (headers especially) can be directly ported into this architecture (or perhaps just reused with QUIC-over-DTLS while letting ordinary DTLS do its thing) and this change would allow us to sidestep issued we are still fighting with, so on balance I believe we can keep the schedule impact contained. We are designing a protocol that will be used long into the future, so having the right architecture is especially important. Our goal has always been to guide this effort by implementation experience and we are learning about the deficiencies of the Stream 0 design as we go down our current path. If the primary concern to this proposal is schedule we should have an explicit discussion about those relative priorities in the context of the pros and cons of the proposal. The hackathon would be a good opportunity to have a face to face chat about this in addition to on-list discussion. Thanks in advance for taking a look, -Ekr
- Proposal: Run QUIC over DTLS Eric Rescorla
- RE: Proposal: Run QUIC over DTLS Lucas Pardue
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Salz, Rich
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Mark Nottingham
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Ian Swett
- Re: Proposal: Run QUIC over DTLS Kazuho Oku
- Re: Proposal: Run QUIC over DTLS Subodh Iyengar
- RE: Proposal: Run QUIC over DTLS Hannes Tschofenig
- RE: Proposal: Run QUIC over DTLS Mikkel Fahnøe Jørgensen
- Re: Proposal: Run QUIC over DTLS Kazuho Oku
- Re: Proposal: Run QUIC over DTLS Marten Seemann
- Re: Proposal: Run QUIC over DTLS Mirja Kühlewind
- RE: Proposal: Run QUIC over DTLS Lubashev, Igor
- RE: Proposal: Run QUIC over DTLS Lucas Pardue
- Re: Proposal: Run QUIC over DTLS Patrick McManus
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Christian Huitema
- Re: Proposal: Run QUIC over DTLS Eggert, Lars
- Re: Proposal: Run QUIC over DTLS Roberto Peon
- RE: Proposal: Run QUIC over DTLS Mike Bishop
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Christian Huitema
- Re: Proposal: Run QUIC over DTLS Victor Vasiliev
- Re: Proposal: Run QUIC over DTLS Subodh Iyengar
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Martin Duke
- Re: Proposal: Run QUIC over DTLS Benjamin Kaduk
- Re: Proposal: Run QUIC over DTLS Phillip Hallam-Baker
- Re: Proposal: Run QUIC over DTLS Brian Trammell (IETF)
- RE: Proposal: Run QUIC over DTLS Hannes Tschofenig
- Re: Proposal: Run QUIC over DTLS Christopher Wood
- Re: Proposal: Run QUIC over DTLS Brian Trammell (IETF)
- Re: Proposal: Run QUIC over DTLS Leif Hedstrom
- RE: Proposal: Run QUIC over DTLS Gabriel Montenegro
- Re: Proposal: Run QUIC over DTLS Christian Huitema
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Mirja Kühlewind
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Mikkel Fahnøe Jørgensen
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Brian Trammell (IETF)
- Re: Proposal: Run QUIC over DTLS Philipp S. Tiesel
- Re: Proposal: Run QUIC over DTLS Mark Nottingham
- Re: Proposal: Run QUIC over DTLS Eric Rescorla