Re: Proposal: Run QUIC over DTLS

Roberto Peon <fenix@fb.com> Tue, 06 March 2018 17:29 UTC

Return-Path: <fenix@fb.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABBF12946D for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 09:29:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1520357358; bh=25ixC2wPmnCdTRM3winEPWnhGxJUjwFec9rWkrOh08c=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=EhYTZ1FZIs2G59RGtGWtjNPMgqpiwAA368+KeonL0jG6K6FbjOMVjHeTTtQt+NeHo sgIUoxp5XxUUa3YOmupF6bZNUxspo24ITwIZMYciatxmuwfGQ2nb9mGN6P4Quk6JND eyuKZHbc1z8ihRcHwmp33aCD0mxmALRv3eJD8fd4=
X-Mailbox-Line: From fenix@fb.com Tue Mar 6 09:29:18 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 203D51201F8; Tue, 6 Mar 2018 09:29:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1520357358; bh=25ixC2wPmnCdTRM3winEPWnhGxJUjwFec9rWkrOh08c=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=EhYTZ1FZIs2G59RGtGWtjNPMgqpiwAA368+KeonL0jG6K6FbjOMVjHeTTtQt+NeHo sgIUoxp5XxUUa3YOmupF6bZNUxspo24ITwIZMYciatxmuwfGQ2nb9mGN6P4Quk6JND eyuKZHbc1z8ihRcHwmp33aCD0mxmALRv3eJD8fd4=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAA41270AC for <dmarc-reverse@ietfa.amsl.com>; Tue, 6 Mar 2018 09:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level:
X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=oJgIGaYo; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=gaA8o6VC
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 ydb4eYapnKTU for <dmarc-reverse@ietfa.amsl.com>; Tue, 6 Mar 2018 09:29:13 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C3D1201F8 for <ilubashe=40akamai.com@dmarc.ietf.org>; Tue, 6 Mar 2018 09:29:13 -0800 (PST)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w26HMv4D027962; Tue, 6 Mar 2018 09:29:13 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=25ixC2wPmnCdTRM3winEPWnhGxJUjwFec9rWkrOh08c=; b=oJgIGaYoaizfgkWm+wqmwBD43st2WxnFgJSsEdU2e8RANWNBtzGVWZvzeqXV8W/b/fG3 WFtBVM0yBhW8WQRhsciNH+MoN7urZi1G+8ZY07IuEqY++GBtLUcCBxKOhk81w0fJ7Rzt fGAdy/ozne0okf6ad26h8G+is2ny2d21scI=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2ghx4m0bjh-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 06 Mar 2018 09:29:13 -0800
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.11) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 6 Mar 2018 09:29:11 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=25ixC2wPmnCdTRM3winEPWnhGxJUjwFec9rWkrOh08c=; b=gaA8o6VCfQhJk8kisXgD5RzOHRYO66fE1qRc90Q6h2YONMD51Q4pW3IUikPiNREBraWuhZaWDAP44OK5H5vjQRiaXm3czkI8p/b5A59NhHRhrpOOdps9lXrwhQtx3G+WC8bmkn2KF5m2gWn4kaufyD6lSHegbHLTu9rGyd+Exek=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0824.namprd15.prod.outlook.com (10.164.171.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 6 Mar 2018 17:29:08 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0548.016; Tue, 6 Mar 2018 17:29:07 +0000
From: Roberto Peon <fenix@fb.com>
CC: "ekr@rtfm.com" <ekr@rtfm.com>, Subodh Iyengar <subodh@fb.com>, "quic@ietf.org" <quic@ietf.org>, "kazuhooku@gmail.com" <kazuhooku@gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
Thread-Topic: Proposal: Run QUIC over DTLS
Thread-Index: AQHTtNa+UG1w1LjHJk2FGe7PSbiLx6PCnpYAgAAjk4CAAC9oAIAAOVSAgAAiHwD//6RzAA==
Date: Tue, 6 Mar 2018 17:29:07 +0000
Message-ID: <EEBA54CC-EC03-45AC-BDDC-5A875F71135C@fb.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> <CAOdDvNo-gjMioyOMHRw9bJpckTa5bKbE6zBFgvx9HTpr4mepRg@mail.gmail.com>
In-Reply-To: <CAOdDvNo-gjMioyOMHRw9bJpckTa5bKbE6zBFgvx9HTpr4mepRg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:200::7:85ef]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0824; 7:3XqyjWHzuK8LnrFPk8QVZ+WZFGOTolrppknbPeO8LI/TsViXqw7kvQJ4CJqwwJvYn7hopH2pt44uYw5d8CW3UwFUjbkO8OfzsY9bGyArDoeg3S0qRJR2Nar6F0lC8XGhQLplDWCt+EWSGCdT4ds4XwvodLQuZMgWwQvn5IXnvn+NGUZvdev1fJQE1c3Lvl+t3ufZfl7p5pdJK95JxF5qjw912Tq2Y6D8QYgPoz1vQmMOWWxWosFt4Ya3+ljqQ/e+; 20:LTf2oghhNdazBgLxH1NyuZPOrSJc0h+69rp1SS3sZeUKJWluqPlIj84ocTazUKqusjLKggESbty2MTcYOGCCmeATOyY+cxpqpoC3oWgtqeu3bp4Gpg97VlPr25K1EmfxdqtTTpTucoi4l8zuJW0mGbMfQM19UpYcbF/IFtgol10=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(39380400002)(376002)(366004)(396003)(53754006)(51874003)(51444003)(377424004)(189003)(199004)(13464003)(33656002)(99286004)(6246003)(54896002)(478600001)(2950100002)(6116002)(36756003)(2900100001)(54556002)(6306002)(8676002)(25786009)(97736004)(606006)(236005)(93886005)(81156014)(8936002)(790700001)(81166006)(316002)(53936002)(110136005)(83716003)(5660300001)(53946003)(6512007)(105586002)(77096007)(186003)(86362001)(3280700002)(46003)(6486002)(7736002)(54906003)(106356001)(39060400002)(575784001)(6436002)(561944003)(2906002)(229853002)(14454004)(68736007)(4326008)(76176011)(82746002)(966005)(53386004)(6506007)(53546011)(345774005)(59450400001)(102836004)(733005)(3660700001)(42262002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0824; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 139e0ac1-256b-4e10-f5ec-08d58387c437
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0824;
x-ms-traffictypediagnostic: BY2PR15MB0824:
x-microsoft-antispam-prvs: <BY2PR15MB0824C29A546FEE78312BC029CDD90@BY2PR15MB0824.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(60795455431006)(158342451672863)(10436049006162)(166708455590820)(85827821059158)(67672495146484)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(11241501184)(944501244)(52105095)(10201501046)(93006095)(93001095)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:BY2PR15MB0824; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0824;
x-forefront-prvs: 06036BD506
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Zg2vJl2AmLoGdE4WdykjnFmYOnQYlQ4/+j6AhSs4g0/FxPC9s4ql1OAChoYFPipqWrYTuAdmAQIzrUBBIWWKX12BoZAQ6j8AN2Fc0EFCWRdCjbNU7joO+Twh9x8LzF+8Ks5qKsR9nhIFQH8712wi/fpsuZO7d2Mk3k4abbGSOGSkKbRECpBZ5/vLnTMhGJmVbIlRitASTVuVVQ1JWxf/l6s2d5ons2/RCAaynHEnQKHJf22c8OEWxX3lgyY4sh2PhLagkacKVArg8uKXLg3AFehiod6LU2Tg6E3QKFxB89gvwb+cYeG/QSPv6hNXbEyIhwdEpcIMVVD98dT8shmhYw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_EEBA54CCEC0345ACBDDC5A875F71135Cfbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 139e0ac1-256b-4e10-f5ec-08d58387c437
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 17:29:07.6743 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0824
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-06_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
To: Patrick McManus <pmcmanus@mozilla.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rWp6ZIF-nmxPIFJdB_vHGLRPKzk>
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:29:19 -0000

We’ve been using stream-0 as short-hand for things-which-relate-to-the-connection.

Putting connection-level data on a stream complicates the spec (and arguably the code, though not enough to really care, I suspect). I think we achieve better clarity at little to no cost by treating these transport-level control data as something 100% decoupled from the application-layer data, i.e. not a stream.

While I believe it can be done properly (and transport on DTLS is a much better approach than was TLS on TCP) I’m afraid of layering in implementations. We know from experience that such layerings often promote system complexity/degrade performance when such layering causes a loss of control/visibility. For instance, TLS layered poorly with HTTP/TCP, since the various semantic layers were not aligned—a loss of a byte (in another packet) from a separate HTTP request would HoL block another one, etc.

-=R

From: QUIC <quic-bounces@ietf.org>; on behalf of Patrick McManus <pmcmanus@mozilla.com>;
Date: Tuesday, March 6, 2018 at 6:57 AM
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>;
Cc: "ekr@rtfm.com"; <ekr@rtfm.com>;, Subodh Iyengar <subodh@fb.com>;, "quic@ietf.org"; <quic@ietf.org>;, "kazuhooku@gmail.com"; <kazuhooku@gmail.com>;
Subject: Re: Proposal: Run QUIC over DTLS

Hi All,

I'm thinking about this question as "Is Stream 0 a Design Flaw?".. The DTLS part is largely putting a solution to that problem out front and isn't really the determining question to me. Its a flashy distraction.

The nominal value of Stream 0 is more or less a replacement for TCP to run a well known and trusted (and therefore to some degree opaque) TLS over - a reliable in-order congestion controlled stream.

It turns out not to do that very well.

  1.  Acknowledgements are heavily intertwined with handshake state - both in sending and receiving. This results in duplicating acks both in protected and unprotected contexts and implementations dropping acknowledgments that they need after keying material has been established. The interactions with loss are very bad.
  2.  The acknowledgment problem is also going to rear its head when we make use of the key phase bit, which again.
  3.  which brings me to the 'opaque' things that happen on stream 0 when we just reuse the tls stack there. They aren't opaque.

     *   key phases - you better be aware of these
     *   session tickets - you better annotate these with source validation information
     *   retry - you better not send these in stream 0
     *   tls alert - you better change your state machine and generate a quic level frame here too

  1.  there are more..
There isn't much disagreement that this stream 0 behavior is ugly. however as a WG I think we're subtly taking on the mindset that these are established roadblocks we need to work around (i.e. a middlebox mentality). We're designing a protocol we expect to have for a long time and we agreed initially that what was in -00 was not to be given undue weight simply because it in was in -00.

so the question to me is - can we fix stream 0 in a way that is a significant net positive to the protocol? I think the draft makes a pretty decent case for that.

-P




On Tue, Mar 6, 2018 at 7:54 AM, Lubashev, Igor <ilubashe=40akamai.com@dmarc.ietf.org<mailto:ilubashe=40akamai.com@dmarc.ietf.org>> 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<mailto:kazuhooku@gmail.com>]
Received: Tuesday, 06 Mar 2018, 4:29AM
To: Subodh Iyengar [subodh@fb.com<mailto:subodh@fb.com>]
CC: Eric Rescorla [ekr@rtfm.com<mailto:ekr@rtfm.com>]; IETF QUIC WG [quic@ietf.org<mailto:quic@ietf.org>]
Subject: Re: Proposal: Run QUIC over DTLS


2018-03-06 15:39 GMT+09:00 Subodh Iyengar <subodh@fb.com<mailto: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<mailto:quic-bounces@ietf.org>> on behalf of Kazuho Oku <kazuhooku@gmail.com<mailto: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<mailto: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<http://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=>
[Image removed by sender.]

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=http-3A__github.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=pgQZdr9HiFSR57L7q08NFfOjV-4_s-sI_vyL3IEiFFQ&e=>
mint - A Minimal TLS 1.3 Implementation in Go


> Minq: https://github.com/ekr/minq/tree/quic_over_dtls<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_minq_tree_quic-5Fover-5Fdtls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=yL_l3GbAGI_L_5y9edwYPjxyiQy31uQ49rLJybFD1dw&e=>
>
>
> 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



--
Kazuho Oku