RE: Proposal: Run QUIC over DTLS
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 06 March 2018 08:49 UTC
Return-Path: <mikkelfj@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 B3515124D37 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 00:49:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZJJxC0T1b6QH for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 00:49:31 -0800 (PST)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 4ECC1120724 for <quic@ietf.org>; Tue, 6 Mar 2018 00:49:31 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id e7so21220307ioj.1 for <quic@ietf.org>; Tue, 06 Mar 2018 00:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=fGuBLosc33akxaeI5umKGD1XWpNq4yKKLMhtQ3E6nCE=; b=FaoE2paxAnmN8RPRtRCVKU9CcIOQU8G7QwdlV60TboQpWSLpdD9NDHQ//TcMcp18rl 536nQGP7UKwhxecsfAEvcoMJE0unmL9qDeSbO66IwtHnSuvT+dfLS9X6CFx4p7LC7Sba lhllLE475/IpfHVNPnzMWjlvnmqTJdZ78W/cYiiaWhPWX1BTKRm1pbMIcu3GtvJv5573 dxWybvv8zQ9oOIm+kavbzEFF4nIjKpu2kDlYyo3oYCaZz9xgguZwbaQRBKKyU6GeSQsh SLnRDDJ51Fhtw0M/XC5v+jO3tVgpPi8ku5aGCp7+62YA1Hqii+3TNXf2UhY3ewbIzuXK 7RVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=fGuBLosc33akxaeI5umKGD1XWpNq4yKKLMhtQ3E6nCE=; b=tmKqgfv/GidQLXpXM7znfaA7US7v0ZvojHND2cJu98Ik3EacaD4+WBoe0VBXSe+15f Jiz1NS4HxwqVCkhwCQTqfKxlIWEeOUDB6+Vzs4ilhCu2erOrvZFrDnKtMfKE33RsgPKK dhLJq97jvZGIwenqACRGhgVRidzHYQVxEYkuUizn7r8OnoJRJfhh8oSlcuEs7mEg7qS3 y7V75WBmCZKNZcXO9BhUSA0jP0SHAWW0gVNdM6cqUSTlp6SmzEBa1nyrGZzjiAGGY+WW 5w8ASz5S4rlUNBLnu1AaIvNVqe/KTIxmwCvsbRffFT81VMhcr0uhwIV+ELncfLjPydZ1 LR/w==
X-Gm-Message-State: APf1xPBr6AmZDyumGDpySXQsQbp1rUGpFgWB6H7JL47UddMwY57zyhZL cAPK20Y/e9mv1WcDhYsabiA0/faepdJa5EmW/MXC0w==
X-Google-Smtp-Source: AG47ELtoE1/WstwtmGCWuep9LIPdsvEDS3zQgJm/oG+/LGrSH0iF5oGBAWNpye1oUlODGvz9BdOpiqmloxlHyXcDsRY=
X-Received: by 10.107.17.20 with SMTP id z20mr20758920ioi.274.1520326170553; Tue, 06 Mar 2018 00:49:30 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Mar 2018 00:49:29 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <VI1PR0801MB2112334B8D33EFA40A863F7EFAD90@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com> <VI1PR0801MB2112334B8D33EFA40A863F7EFAD90@VI1PR0801MB2112.eurprd08.prod.outlook.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 06 Mar 2018 00:49:29 -0800
Message-ID: <CAN1APdepfkZuHFjk8adOSc2pHhrwLBJ0Jq-nk6O5L_9o_SVDxQ@mail.gmail.com>
Subject: RE: Proposal: Run QUIC over DTLS
To: Hannes Tschofenig <hannes.tschofenig@arm.com>, Eric Rescorla <ekr@rtfm.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113eda8a56b54a0566ba85ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/bN-pi1_-xJw_O83z7c6DRm2QZ1c>
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 08:49:34 -0000
This is an interesting proposal. - It clearly points out that the current crypto handshake does not map as cleanly as it could be - also noting the recent discussion on list about truncating stream 0 early. - It makes it much simpler to layer QUIC over other transports. For example, a low-end device on a very secure line, such as an ABS breaking system, could send QUIC without crypto framing to a central core, but still use all of the QUIC semantics. - It could simplify/accelerate use of QUIC in web browsers. - It is a hammer allowing applications to deploy DTLS without only using QUIC. Sometimes QUIC may be need a lot of spec work to map a concept - for example IoT MQTT over QUIC is not clear cut, but it is easy to use DTLS. Having to use both DTLS and QUIC in app may be a bit much if they are not fundamentally the same. That said, I agree with Ian and others - there are a bit too many moving parts and dependencies. It is very nice to have a single self-contained construct. Already the need to depend on TLS adds a lot of complexity (even if it can be hidden by third party libraries). I would suggest how to reconsider a much cleaner crypto mapping inside QUIC based on these findings as Ian, Kazuhu, and Sudbodh also touches upon. Even if this fails due to timeline - it may be worthwhile goal for v2. If QUIC invariants were tied to DTLS it might not be possible to move out of that tie-in - even for custom or special purpose versions of QUIC - i.e. too much friction. Kind Regards, Mikkel Fahnøe Jørgensen On 6 March 2018 at 08.48.09, Hannes Tschofenig (hannes.tschofenig@arm.com) wrote: To be honest, I have been wondering why the QUIC group started with TLS 1.3 instead of DTLS 1.3 all along. For me this makes sense. Ciao Hannes *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla *Sent:* 06 March 2018 00:06 *To:* IETF QUIC WG *Subject:* Proposal: Run QUIC over DTLS 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. 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
- 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