Re: Proposal: Run QUIC over DTLS
Eric Rescorla <ekr@rtfm.com> Tue, 06 March 2018 17:46 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 4CAAC1270AC for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 09:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] 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 TE0gxzRZObjC for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 09:46:19 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 AEDF8120726 for <quic@ietf.org>; Tue, 6 Mar 2018 09:46:18 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id n9so10672530qtk.6 for <quic@ietf.org>; Tue, 06 Mar 2018 09:46:18 -0800 (PST)
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 :cc; bh=/aWIFjvkufL0eMtHhQ5/SVsPLLH7veG+1rCkHZybmmY=; b=sFlVN0YEcXN+NKiR9DMjpvCwiordmST+N17Ag1Z5mL1xuucUaZ5QvnslizxI7NNw1b MTq5YKvl4rWMdMy224pz9D01Nvn00pYvJOM6Y2fn6I9pv4Ol64pGOA8NM286MkQ/9dRF 24Wx7mHftlU0Pbnd3wBsG0owVSJXea4CQesrg/o8TQDJ7nyAP3krEWLifsw+0gBAh49/ i8ot1upz2r2mq86tFp6zBMgjadV/VSZ7lKeYrSZ7iBDXTPvIGOsUtFwN03r26DbsPa/R Jv95GObtpVbyPg4z/EK9HQ9fG+v5/5OvGjg4hRW3JUgOb3wNYut7CsMsmDHnH7ujzE6t U7Qw==
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=/aWIFjvkufL0eMtHhQ5/SVsPLLH7veG+1rCkHZybmmY=; b=fqBO9XQabaD4qGEax/ljL4FunQkyaxJh86ItrAp8eUhSg3+PmtdrxQ1ic/pBhprrUG UmvLlfttATbsLeQZsZsgZmzL9llmtCwEJwUnVvuhukgbhF86ZOJt0HBuT51NFw7A8sTJ mP0hrnPRjkMJ1aMcRH14WAm/JbUk95Hsqcjogfm9mg69B15UZO3S5MmZ9/oj8GQjrHF6 G1h+PM3xxq6kAMvMjHR3P5A7S9y/tECAr4G24ojS41y9LeEqRlqR/Ejv9U92fNWJDJkX P0uOfQb8yyelqxx4NFzo+37TW9oijHZFb1lcVqlOoXnm51qfs3hZnhev/89UiH8ctJWB 54Bg==
X-Gm-Message-State: AElRT7EeHF2SP7r0Z5sOXyf0NztSZcu475R8P2r9Wg5Pn8bWpSUJ3peU D2uVeLAesb12rD/STgHzItR3iKLV0kzzA5Y1H0WtQA==
X-Google-Smtp-Source: AG47ELsu5HcXQOzFamkDrrQOL0Hh3P6AMHBmIMX8LTHD8meNQMMVOcuYhjZGx6fO56RBnzzp74Kh1X/8v7GCiv0vkx8=
X-Received: by 10.237.56.34 with SMTP id j31mr30430581qte.208.1520358377535; Tue, 06 Mar 2018 09:46:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Tue, 6 Mar 2018 09:45:36 -0800 (PST)
In-Reply-To: <SN1PR08MB1854297E8E944ECE7EA89B56DAD90@SN1PR08MB1854.namprd08.prod.outlook.com>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com> <CANatvzyevZrZciO3fTWFspp9utjKv9Z+PQ5F=yHKNBabssEsNw@mail.gmail.com> <MWHPR15MB182183BE8E6E0C3A97795315B6D90@MWHPR15MB1821.namprd15.prod.outlook.com> <CANatvzzARjNdr6Rms0r0yVn41JwtU6p9uNueq_ZROVzU19-1+A@mail.gmail.com> <b32d00a03ca148eca5a16e572d1030a0@usma1ex-dag1mb5.msg.corp.akamai.com> <CABcZeBMyKY8d3OUwF11NqYvgNswD7F1S8R7rXrKYXTaNPTkOxw@mail.gmail.com> <SN1PR08MB1854297E8E944ECE7EA89B56DAD90@SN1PR08MB1854.namprd08.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 06 Mar 2018 09:45:36 -0800
Message-ID: <CABcZeBNp11BUKTf8Qt6M6pnOjvJSfTeu-p=7ZeDNLBnnZS+w0g@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: Mike Bishop <mbishop@evequefou.be>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, "subodh@fb.com" <subodh@fb.com>, "quic@ietf.org" <quic@ietf.org>, "kazuhooku@gmail.com" <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="001a113b7f180648cb0566c2052b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Uw1S8Hwu0_DdIYOb8iWMfpqna-I>
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 17:46:24 -0000
On Tue, Mar 6, 2018 at 9:32 AM, Mike Bishop <mbishop@evequefou.be> wrote: > My concern with this specific idea, as with the broader DTLS draft, is > that you’re making some very fundamental assumptions about things we’ve > tried hard to keep flexible. That is, you’re ossifying the protocol. > While our plans to rev versions more quickly means that v1 doesn’t have to > be perfect, we’re going to be living with the invariants a *long* time, > so they should be as general as possible. TLS isn’t part of the > invariants, and what you’re proposing makes TLS an invariant. > > > > On the contrary, we decided relatively early on that the version > negotiated implied the crypto handshake to be used, which would be TLS for > v1. If QUIC runs on top of DTLS, or negotiates versions via TLS extension, > that’s no longer true. If (D)TLS is a required component to do version > negotiation, you’re kind of backed into a corner. I know that TLS itself > is designed for crypto agility, and perhaps you’re correct that we’ll never > need a handshake protocol that isn’t TLS, but I don’t want to make that > assumption. > Hi Mike, Thanks for your note. A few points in no particular order. There are a couple of questions about the invariants here. I think this would make the DTLS record wire image (or whatever we ended up using) an invariant, but I think it would be possible to use the VN-style version negotiation to switch off of DTLS if we had to, the same way as we would if we wanted to with TLS. I do agree that the new replacement would need its own version negotiation mechanism to confirm that -Ekr > > With the existing QUIC version negotiation and packet protection model, > these concerns are well-separated and I think that’s a valuable feature. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Tuesday, March 6, 2018 7:13 AM > *To:* Lubashev, Igor <ilubashe@akamai.com> > *Cc:* subodh@fb.com; quic@ietf.org; kazuhooku@gmail.com > > *Subject:* Re: Proposal: Run QUIC over DTLS > > > > FWIW it is possible to move the style of version negotiation from my draft > directly into the current draft if we so wanted. It's just that it's > necessary if QUIC is at the bottom of the stack and so is a nice extra win. > > > > Specifically, we would have the version in the long header In Initial > refer not to the QUIC version we want to negotiate but rather to the > version whose obfuscation method we are using (probably the client's > minimum). The CH would then have an extension which contained the QUIC > versions we support (as in TLS.supported_versions) and then the SH would > contain both selected versions. We could have the remaining obfuscated long > header packets could use *either* obfuscation version. The encrypted long > header packets would of course use the negotiated versions. > > > > A few notes: > > > > - The CH always comes in one packet so that you don't have to worry about > it being immediately available to the server > > - The SH may be broken up but as noted above, the obfuscation version > isn't part of the negotiation. > > > > As with my draft, this would give you 1-RTT negotiation if the client > obfuscated with a version the server knew and 2-RTT if the client > obfuscated with a version the server didn't know, as opposed to always > having 2-RTT > > > > If people think they like this idea, I'd be happy to write it up a > separate PR. > > > > -Ekr > > > > > > > > On Tue, Mar 6, 2018 at 4:54 AM, Lubashev, Igor <ilubashe@akamai.com> > wrote: > > If it requires an extra rtt to do version negotiation, it is likely that > extensions will be created by other means. If we improve version > negotiation to look more like one in Ekr's draft (no extra rtt), standard > extensions are more likely to come in via new versions. > > - Igor > > > > -----Original Message----- > *From:* Kazuho Oku [kazuhooku@gmail.com] > *Received:* Tuesday, 06 Mar 2018, 4:29AM > *To:* Subodh Iyengar [subodh@fb.com] > *CC:* Eric Rescorla [ekr@rtfm.com]; IETF QUIC WG [quic@ietf.org] > *Subject:* Re: Proposal: Run QUIC over DTLS > > > > > > 2018-03-06 15:39 GMT+09:00 Subodh Iyengar <subodh@fb.com>: > > While using DTLS is not unworkable, the WG has put a lot of work put into > the current header and packet format which shows that controlling the > header format has several advantages for the transport to accomplish its > goals. That being said, I think the spirit of ekr's proposal has several > salient ideas which we could incorporate into the existing QUIC drafts > irrespective of deciding to adopt this draft. > > One of the salient ideas is a more clear layering structure. I believe it > is possible to implement even QUIC as currently specified with a layered > API, even if the current drafts make no assumptions about layering of the > protocol. > > > > Even though our implementation, mvfst, is not layered, I can imagine an > implementation creating a layering structure to be like > > > [ QUIC transport layer] > > [ QUIC encryption and "record" layer ] > > [ UDP ] > > > > The roles of these layers are well defined (note that I have not > implemented this yet). > > > > The transport layer > > -------------------------- > > It maintains the transport state and gets signals from the encryption > layer on what type of data is appropriate to write, i.e. no data, 0rtt > data, or 1rtt data. > > > > Record layer > > ------------------- > The record layer would decide to encrypt the bytes with the appropriate > keys. > > > > The record layer would also send packets for handshake data. Since the > transport and the record layer would share the same packet number space it > would be appropriate to give ownership of packet number counting to the > record layer. Before the transport layer constructs a packet it would ask > the record layer to assign it a packet number to use for its state > accounting. > > Receiving a packet > > --------------------------- > The handshake layer decrypts the packet and hands the transport layer a > packet number and the decrypted frame data. If the handshake layer has any > handshake packets outstanding it would go into a mode where it would read > all acks from all packets to make a decision on whether its handshake data > needs to be retransmitted. The handshake layer would only be responsible > for transmission of stream 0 data. > > > > This allows acks for non handshake data to be used to re-transmit > handshake data even though they are in different "layers". If the transport > layer assumes that any gaps of data were transmitted by the handshake > layer, it would also allow acks for handshake packets to be used for loss > recovery of data packets as well by the transport layer. > > I could see the current draft adopt a more layered editorial structure, or > it might be simpler to have a separate draft that describes the layering > design of QUIC. I would be happy to work with ekr on this if this needs a > separate draft. The spec could incorporate some features to address the > issues ekr brought up. 3 changes that might bring us closer are: > > > > - We could move crypto out of stream 0 and giving it it's own frame > type. This separates the "channel" of communication of crypto data from > "streams" which the transport has to maintain state for. In several > implementations, including ours, crypto streams are treated special for > everything anyway. The only resemblance to a stream is in the state needed. > - Multiple QUIC packets in 1 UDP packet. There is already an open > issue for this. > - Getting rid of regular packet gaps so that multiple layers can use > gaps to decide which layer handled the data. I believe we are on a path to > doing this anyway. > > > I'm not sure how to resolve the issue on version negotiation though. > > > > Honestly speaking, I do not understand why people are interested in doing > QUIC v2 soon. > > > > If we want to extend QUIC v1, we can add new extensions to TLS to > negotiate additional features. > > > > Regarding preventing ossification, I think that can be (and should be) > achieved through greasing and obfuscation. > > > > If my assumptions listed here are correct, requiring additional round-trip > is a non-issue. Assuming that a non-compatible change will come only once a > decade, we can just do happy eyeballs with QUIC version N and version N+1. > > > > > > Subodh > > > ------------------------------ > > *IFrom:* QUIC <quic-bounces@ietf.org> on behalf of Kazuho Oku < > kazuhooku@gmail.com> > *Sent:* Monday, March 5, 2018 8:32:28 PM > *To:* Eric Rescorla > *Cc:* IETF QUIC WG > *Subject:* Re: Proposal: Run QUIC over DTLS > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__ > datatracker.ietf.org_doc_draft-2Drescorla-2Dquic- > 2Dover-2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r= > h3Ju9EBS7mHtwg-wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s= > jI8gErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e= > > draft-rescorla-quic-over-dtls-00 - QUIC over DTLS > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=jI8gErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e=> > > urldefense.proofpoint.com > > QUIC over DTLS (Internet-Draft, 2018) > > > > > > And a partial implementation of it in Minq at: > > > > Mint: https://github.com/ekr/mint/tree/dtls_for_quic > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > ekr/mint > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > *github.com* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > mint - A Minimal TLS 1.3 Implementation in Go > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > -- > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > Kazuho Oku > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=> >
- 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