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, 6 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=>
>