Re: Proposal: Run QUIC over DTLS
Eric Rescorla <ekr@rtfm.com> Tue, 13 March 2018 16:53 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 26979127775 for <quic@ietfa.amsl.com>; Tue, 13 Mar 2018 09:53:32 -0700 (PDT)
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 nS54JcWmFKeq for <quic@ietfa.amsl.com>; Tue, 13 Mar 2018 09:53:29 -0700 (PDT)
Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 7A689124D37 for <quic@ietf.org>; Tue, 13 Mar 2018 09:53:29 -0700 (PDT)
Received: by mail-qk0-x241.google.com with SMTP id 132so319769qkd.5 for <quic@ietf.org>; Tue, 13 Mar 2018 09:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=djLwU5eqvZAwnKhuDkXcKgj/bb9egDj2/A56ovgITFU=; b=d+NqObMycH8gFkUlSaUOSCn+nCB0v9NMKUsQ9MfuszLp7Hn50/DscuO7BFBYDC7jFW +6MlyyVjGArqCtUw/W3KfKye/JshA4cInS89gOLsc1GurP9JJD+/qM+ODUphdcWnVeJy LqdWJW5ZjRJvZ/hLDcR5vDAw414qNFZFcA7I6gbSFqoTpZznAoemYeOM7XE69AtfEadN yzad6/geaFBriYhJrNdZ5zNo0VSVQSCZ6kkt+K/ccxoGH2WvcPR71y/NAMWlCERerZDo uChOlDJEbrtpYnkO/kFuPTHuuS4sWspSdJV46n8NTMfrmJ2cGnirfpWLjPCHCZN+WtqU k4fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=djLwU5eqvZAwnKhuDkXcKgj/bb9egDj2/A56ovgITFU=; b=Sc/TIdwPpd7f/N/b+AVF0OHN6ZM8P9Y0EFPAZJ012Q7jPCsDLCUEO9KVD0dt/q8Xh2 vsNwnq4TiNvcyJRtVgNdXHh87DhIPLtmS8+Q40XNd4hEo/ZxjI8VMpY0FVL7RWSlE5mt b9cqq4m0ufDByUBWZFVyIQ9RTuR+50cCZP43gPvnx/EsBCHRG7jywWDU/+r2Fhm+Sy1V WX7ACXw6pXOY/tHEwt9tCA1A22b7Bu9XJ0/WC9KF3Hiuuhhi/kvznUPQNpT70LBlD2rR U1VLLNQfEyh2bLazRZH8oleddRAx8jb/bhmPvOziwz1ovYUreZXix9opuXOAnyFyOsKD 8srQ==
X-Gm-Message-State: AElRT7F7G5AZbbiu1BgC7tbsb0cxm0zQ5P3hvnm2/Y76UC9IyPa9IwHY WN+kXhA9mWNz6nN9KH6yqwHlKa3NKdTIVi6CQySMZtSk
X-Google-Smtp-Source: AG47ELt/rU+kKFFHbUdrxu+toYniON8IcwrfCjyoBIMz347lNX2EGhJvUguurkMRg/ZDrtVI+MVdIDLJT9z3Y+8/de8=
X-Received: by 10.55.22.28 with SMTP id g28mr1991128qkh.152.1520960008098; Tue, 13 Mar 2018 09:53:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Tue, 13 Mar 2018 09:52:47 -0700 (PDT)
In-Reply-To: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 13 Mar 2018 09:52:47 -0700
Message-ID: <CABcZeBNAYiTzdyE+UcqvThgnKhDthuq2-UyjEBoJkpep8-t5vg@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114746300026a305674e19ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/XV0L0tl0aD2_LqFiUfc7yN-OtPY>
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: Tue, 13 Mar 2018 16:53:32 -0000
Hi folks, Thanks to everyone who commented. Trying to consolidate my responses a bit, it seems like things fit into three major buckets: - Whether we have a stream 0 problem - Whether a layered architecture is the right thing/solves those problems - Schedule impact I'd like to focus on the architectural question for the moment. I think there's broad -- though not universal -- agreement that the stream 0 thing is not great, but a fair amount of debate about what the right architecture and architectural principles are. It's not really productive to talk about schedule impact until we understand what the right thing is. In this note (the first of what I expect to be many) I want to focus on the question of reliability for the cryptographic handshake, namely that the DTLS handshake provides its own reliability layer which to some extent duplicates the QUIC one. I say to some extent because because it's rather simpler and doesn't provide congestion control, etc. A number of people raised concerns about this, for example Ian Swett: From an architectural perspective, I would like transport at the bottom of the stack and I only want to run one transport. Having two different transports creates more problems than it solves. TLS over TCP is massively successful, and the current TLS mapping is the most analogous approach I can come up with. I'm not sure I agree entirely with this characterization, because it kind of overloads the word "transport" [0] but I do think this is the biggest technical weakness in the DTLS proposal (or any proposal which is layered like this): if you're going to create the cryptographic association before you want to send transport-level traffic, then you need to provide transport services at the crypto level. However, I think this is also the cause of a lot of our problems with stream 0, namely that we're trying to use transport services at the same time as we're trying to establish the connection: note that this isn't the situation with TLS over TCP, because you set up the entire TCP connection before the first packet is sent (or at least, with TFO, TCP pretends that that's the case to TLS). So, you have a very clean abstraction in which layer N+1 is able to assume that layer N is ready and count on its services, but that's not the case in QUIC. In the current QUIC design, we've attempted to address this by making stream 0 a special snowflake that uses the QUIC transport services but gets to relax a bunch of the rules (flow control, always encrypted, arbitrary mapping of writes to frames, etc.) The DTLS design deals with this by having the handshake be entirely out of band to QUIC, which of course means it needs to duplicate those services. I'd like to drill down a bit more on people's concerns are here. It seems like there are three potential objections: - It's duplicate code - The DTLS reliability/handshake machinery is going to be less good than the QUIC machinery - It's going to create new forms of architectural inconvenience The first point is of course true, though having done the code here, I don't think it's that big a deal, and of course TLS 1.3 stacks will in many cases be growing DTLS 1.3 stacks anyway. The second point is possibly true as a general question, but I'm not sure it actually matters, given that in the vast majority of cases you won't have any loss in the DTLS handshake at all. Arguably, however, the fact that the DTLS machinery only needs to be used in the handshake is actually an advantage here: the amount of data we want to send is very small and so we can lean more on the side of trading bandwidth for fast setup. For instance, AIUI QUIC early retransmit fires after about 1.25 SRTT, but in DTLS 1.3, you retransmit immediately upon receiving an ACK for a partial flight. This is probably too aggressive for a general transport, but it's not unreasonable when you're likely to have no more then 3ish packets in flight anyway. Again, I doubt this matters most of the time, but as an architectural matter, it's not clear this is a disadvantage. I'm more fuzzy on the third point. The only pieces of architectural inconvenience I am aware of are listed in the draft, namely: - Needing access to the DTLS record numbers to make the ACKs work. - The fact that QUIC doesn't get any RTT information from the handshake, although as noted we can compensate that by having DTLS provide an estimate. Are there other infelicities I'm missing here? Thanks, -Ekr [0] Arguably, we already have two transports, QUIC and UDP, but nobody is bothered by that. My argument here would be that from the perspective of QUIC, DTLS is a lot more like UDP than it is like a real transport. It's true that there is the handshake machinery, but as I said above, that's out of band to QUIC and from QUIC's perspective, you can either send packets, in which case DTLS sends them out directly (with a predictable overhead) you cannot, in which case QUIC needs to hold them (note that it's already true that QUIC has to do this if the TLS negotiation is unfinished). So, I don't think the more general argument is very persuasive here. On Mon, Mar 5, 2018 at 3:05 PM, Eric Rescorla <ekr@rtfm.com> wrote: > 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