Re: Proposal: Run QUIC over DTLS
Kazuho Oku <kazuhooku@gmail.com> Tue, 06 March 2018 04:32 UTC
Return-Path: <kazuhooku@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 47A73127444 for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 20:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 0k6AroaackKg for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 20:32:30 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 29483124D6C for <quic@ietf.org>; Mon, 5 Mar 2018 20:32:30 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id g12so7844698pgs.0 for <quic@ietf.org>; Mon, 05 Mar 2018 20:32:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OoaaE1Ds9k1Uk7uOyno6OK1bUQzpY64omhaZie1s1o0=; b=eem2sNk9iFnVaJlrM8IeviwchT9TZ/LDwX/ev4RWqkNVXgMaYQroTMA11nXko4OC4B 5HJS4Vf49mXaHBdO10iIiPMVOg4BVcwBLriPq0CY2kcZ0rVymFqWEMph+Rz/mTx4s9Ps 9un9uMmBsmZraWTC4+7zgqLqzLYjQ/NUZuu/VqoWAGLKQdwOoDgNrvbR7w95urFswUBi Nq8Q/paGMBh3vdtFpUfrYz656A08fmrokYhoJR1gSjaUIiQRV2b3tb5QCUte3jj6bLzj 2OJdfe5nKfDwaGNcxLS/wASzbDqow9LaB7/9jEbM3H27HmWrm2sVviIMZRDN70S4JTNS cfmw==
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:cc; bh=OoaaE1Ds9k1Uk7uOyno6OK1bUQzpY64omhaZie1s1o0=; b=kRXQppywALiiBAc1SNJeJBDbVATT18SBpvDDtz34j2NUvImgC3amyyOeQWf43oY6XA wGNGcjXeLa1s3C3wu9Emcb9gIeZ/7aOzcJe9XjSoM1WRiZ2iNhmxkiletmeStuAT78YI euhjwPbCWKF83eTjBmzFcOBi5IVqmCFgopgT1tEB7hXN46DLTs004kAar0lVZ/HZH4Ww /d/laneInF8MImNubFOsZ4C9icLmVti83F/gWNYz87UEhOQpqHTObvxj7VcTjMHneD2T nG/fH/zNnKuwI+a/bE34KVFyiAp8R6wWUrOqfk+HrScr4WKEghv+GNk7LumGopP2vjCa CmNg==
X-Gm-Message-State: APf1xPCodkrVzcFllqJNPkZmkSi2hZcBE5aRKq8dEH2OshObKTvKgr2Z wm/liKOSh2EnGk6aCqbS/KHEFHR6I1tcRBNHKWa9TA==
X-Google-Smtp-Source: AG47ELt+qkwjiZIyATQp+JEgva+6jJeH0KA9XAd76QQYUhcSfKdAp392p++nuvltjGtAbewg1vl8v+mn4sEBxcGcLLc=
X-Received: by 10.99.151.26 with SMTP id n26mr14159249pge.370.1520310749494; Mon, 05 Mar 2018 20:32:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.154.23 with HTTP; Mon, 5 Mar 2018 20:32:28 -0800 (PST)
In-Reply-To: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 06 Mar 2018 13:32:28 +0900
Message-ID: <CANatvzyevZrZciO3fTWFspp9utjKv9Z+PQ5F=yHKNBabssEsNw@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: Eric Rescorla <ekr@rtfm.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4Z5NLW1YDbj92u__U6dlXya97LM>
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, 06 Mar 2018 04:32:32 -0000
2018-03-06 8:05 GMT+09:00 Eric Rescorla <ekr@rtfm.com>: > 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. EKR, Thank you for writing this. This is a very interesting proposal! I can see the point that the QUIC specification will become more straightforward if we adopt the DTLS-based approach, while, as an implementor of TLS 1.3 and QUIC, I do not think that the total cost of maintaining crypto and transport would change a lot. One thing that I like about the proposed approach in particular is the negotiation. As your draft points out, current approach has the overhead of requiring additional round-trip when the server's preferred version differs from that of the client. It makes sense to negotiate the QUIC version using the negotiation scheme available in (D)TLS. That said, I feel uneasy about building QUIC **on top of** DTLS. My understanding is that the intent of the working group is to build a transport. We have spent maybe about a half of our time discussing things that need to be implemented below the crypto (e.g., connection ID, stateless reset, path migration, etc.), while the other half being above the crypto (e.g., streams and multiplexing). I think that that reflects the nature of what transport is, and that the two need to be discussed together. In other words, I am afraid that moving half of the design to TLSWG while retaining the other half in QUICWG is likely to lead to the need for much more discussion (would we holding interims for two workgroups?) as well as making the decision process more complex. In my view, that increases the risk of QUIC standardization process being either delayed or ultimately failing. Therefore, I am sorry to say that I am negative to the proposal. I would feel safer if the proposal is adjusted to retain the sandboxing approach (i.e. define the layers below and above the crypto layers in QUIC WG while switching to DTLS). However, I also believe that the issues of the current approach that have been pointed out by the proposal can be adjusted without switching to DTLS, and I would prefer doing so unless we unanimously agree to switch to DTLS. PS. If we decide to adopt the proposal, I am happy to implement DTLS in picotls. It would not take a lot of time to do so. > > 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 > > > > > > > > > > -- Kazuho Oku
- 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