RE: Proposal: Run QUIC over DTLS

Gabriel Montenegro <> Fri, 09 March 2018 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32C98127241 for <>; Fri, 9 Mar 2018 09:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DsRmr0UqoICU for <>; Fri, 9 Mar 2018 09:24:15 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe48::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 983C9124235 for <>; Fri, 9 Mar 2018 09:24:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ycmOV4+FHS3B/+WVlSCuXWBfIyd8I9yTjldwXposeMs=; b=GIXS7Ye6uy80XnUOsRnK+lkzq22GeFuUTwr4gpswfcWjj3YFbd8Fy0j06WMsa74cnooVT97qVZa2GhuDpnYxcVSGCrw6HTHf+BywelPZfEMo1NFx+zErU2FlNTb6yyvsILmewG7A3vdIi/xUhZ2AXogKty5Oz+Ka+dRxRQ6QuKw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.3; Fri, 9 Mar 2018 17:24:13 +0000
Received: from ([fe80::cc8b:e7ad:279f:c1df]) by ([fe80::cc8b:e7ad:279f:c1df%4]) with mapi id 15.20.0588.009; Fri, 9 Mar 2018 17:24:13 +0000
From: Gabriel Montenegro <>
To: Leif Hedstrom <>, Martin Duke <>
CC: Ted Hardie <>, "" <>, Eric Rescorla <>
Subject: RE: Proposal: Run QUIC over DTLS
Thread-Topic: Proposal: Run QUIC over DTLS
Date: Fri, 9 Mar 2018 17:24:13 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN4PR2101MB0814; 20:02/SB4WrIusGaBVbSd6U/6HOVz5d4N/tKxoJSdIfmIdSPaih5Mjkp68oRmsu/KqYV40vchYL4WmY/Yd42UX00EGZj/desC0V/f8/2yyS5bNfPz6UbzTNPrcgSH3Nbtr96XAo6/4U3uy4Kufomw2zXPvRItD/h+rPnz/BFnsfZsc=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d66cfd92-cd5f-4254-530a-08d585e29435
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:SN4PR2101MB0814;
x-ms-traffictypediagnostic: SN4PR2101MB0814:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231220)(944501255)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:SN4PR2101MB0814; BCL:0; PCL:0; RULEID:; SRVR:SN4PR2101MB0814;
x-forefront-prvs: 0606BBEB39
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(376002)(39860400002)(39380400002)(189003)(13464003)(199004)(3846002)(3280700002)(68736007)(6506007)(8936002)(305945005)(53936002)(105586002)(53546011)(6116002)(26005)(99286004)(7736002)(33656002)(186003)(59450400001)(76176011)(6346003)(9686003)(5660300001)(2900100001)(55016002)(316002)(2950100002)(81156014)(8676002)(561944003)(2906002)(74316002)(7696005)(8990500004)(22452003)(229853002)(106356001)(81166006)(6246003)(5250100002)(25786009)(72206003)(110136005)(54906003)(6436002)(478600001)(14454004)(10290500003)(10090500001)(86362001)(86612001)(3660700001)(66066001)(39060400002)(4326008)(102836004)(93886005)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN4PR2101MB0814;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-message-info: wn2aVjqFm2wZ5O1XZkAm+phwFdHSJ0w+QNvegryfmIA/TV6X30KbpPNBGd6XdejGPHaDqS0NRiURflyy98fbHyo89m673PJ/4kI14OZDBe2qz19Lv6M07DpmKt3cOrzw4u32YDluJnKHdls8rPRHqzxdekQvDdRzZ8dCHDk9awRYJmTscQwjgWUwIEQ6IaQD0Fdit1RZJQVs9QzXL2RvGFYXOHwb6Fa/is1GINTQJa0bt11K8+sirS+9H2yDfKoWCbiCV0FF8DYWpNDYs7rEhBs1vo5MGu/qFn8XZGI++9DBqR7qN72JEvDWdlyr1hlFoxjHimrCm+mc1RR26sROHw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d66cfd92-cd5f-4254-530a-08d585e29435
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2018 17:24:13.6787 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR2101MB0814
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Mar 2018 17:24:17 -0000


Thanks Ekr for the proposal, it is interesting and it would have been different to see it, say, a year ago.

But now, I wouldn’t want to layer over DTLS. I discussed this with people involved in the QUIC effort at Microsoft and they came to similar conclusions

I agree with others that this is too late in the process, and would not want to throw away all the interop efforts and progress with the bathwater, which would represent a significant slip in the schedule, as would the fact that dTLS 1.3 is not as mature as TLS 1.3.

The point about having only one transport is important, as is the point about not augmenting the invariants with a given handshake flavor.

My preferred approach would be to—at most—take some ideas and incorporate into the current QUIC framework, so I’m  looking forward to the version negotiation modeled after the QUIC-over-dtls proposal.

Another interesting result of this discussion is Subodh’s suggestion to clarify the interfaces between subsystems (“layering structure”): QUIC transport and packetization vs crypto on stream 0 vs UDP. 



> -----Original Message-----
> From: QUIC <> On Behalf Of Leif Hedstrom
> Sent: 7 March, 2018 10:21
> To: Martin Duke <>
> Cc: Ted Hardie <>om>;; Eric Rescorla
> <>
> Subject: Re: Proposal: Run QUIC over DTLS
> > On Mar 6, 2018, at 3:44 PM, Martin Duke <>
> wrote:
> >
> > I like the QUIC-over-DTLS architecture, and if it had come out a year ago, I
> might have been a supporter. However, I think the idea that we could possibly
> stay on schedule with this change is a fantasy.
> >
> > 1. For all its problems, the QUIC handshake is one thing that pretty much all
> the implementations have working. We've overcome the design inelegance,
> and would now have to redo the handshake without really reducing
> implementation time going forward, with the possible exception of not needing
> to handle key phase.
> >
> > 2. DTLS 1.3 is apparently less mature, as a standard, than TLS1.3, and even
> less so if we're about to go add a bunch of requirements.
> This was my initial reaction as well. TLS v1.3 being such a moving target for the
> last ~12 months has been one of the biggest challenges to QUIC interop /
> development. I don’t know what state the various TLS implementations are for
> DTLS v1.3, but I’d be concerned that we start that circus up all over again.
> I think assessing the state of DTLS v1.3 specifications and implementations is
> critical before making a technical decision. [I’m saying this with very little
> knowledge of the DTLS v1.3 world :-].
> Cheers,
> — Leif