Re: Proposal: Run QUIC over DTLS

Victor Vasiliev <vasilvv@google.com> Tue, 06 March 2018 18:21 UTC

Return-Path: <vasilvv@google.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 58B581250B8 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 10:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 HTRQb2eFv81l for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 10:21:46 -0800 (PST)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 5B743124F57 for <quic@ietf.org>; Tue, 6 Mar 2018 10:21:46 -0800 (PST)
Received: by mail-qt0-x22a.google.com with SMTP id z14so25692439qti.2 for <quic@ietf.org>; Tue, 06 Mar 2018 10:21:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QvKPC+KXgLzB0sn5oLsiTeBf32OFFV/GVqLntdbgOuk=; b=W1M6E3x5Lcz08CNk4BtDVlL/FvKJ+8+avrwLFuV44weh/CNRP8w+Mbxrf2k0pnNL1t NoEWtNr7VURFXczjoqBcTG3UTTgmBrAacjJUG/xv9fdSygIrfSPxIgJ+IUPv8iAL9SXN HsBzwoYZMOho/t5jAk4Q0fb356YaPICJpodLmdfbIZCBO9Yr+66TXs1Ktm8595zbYHBu yILE6L+t/o0DH5Cf1HeLqbubX43G0eyNe0JKt4FTDfQda9uFzcZSvAE3OA92CS2b44Xx Evc3uTWSePwBR5U4X2RbuKEYBhLvvYOxw/E5iuIWvVIqXA/xRKtOOzHKxbFxKzh6xqvC 7j4Q==
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=QvKPC+KXgLzB0sn5oLsiTeBf32OFFV/GVqLntdbgOuk=; b=smQe6ejAUZ+KRXZtaOtR/5E9+5pT/7+C8L+FwWXmxR7g6U7RfEaYS2FsHLPcD5oCf2 aGBWJvsEGh2FjAdVeYFXHJejzJVV9mv4EXyInIC7Mi47HJ0Nk3CP1U2KMDTJGXI/ScgN owkqTZJFY99it0pQdEowXkYiM4nY25Nsx7j/bqrvfIJFJ/1O8Vj6MOy9XVPyjee+mdqX 8oFkfnpLeWfkLOpBj8AHbr7KvtBBqNantlDXHH+r0l/bEslS2dAI0XkZEeFlNFq5DY6/ lOLW5B4G6yOimqSzteCJD6yyrLDc469UkebDD8RaNZXUQmBXM85KSJLzDq6lIZF/y3Ou 7QLA==
X-Gm-Message-State: AElRT7Fet4RvQXv1ujtK4Lck9xciVvFMJkLXtpNu0Mw41dksMQ5gx1Ut 6x9QuK9WxguCf5h+ECcwIUJLbgNX8+cWN1YiRG8gkKe3ilw=
X-Google-Smtp-Source: AG47ELuoDd6fia5eRKYbWoavDMuwyU+RyatG2/bscaCYZRvXuVj0sSL/4MSOSOpNLwuY647Ecx2uIRczHue8dl4syFg=
X-Received: by 10.200.23.235 with SMTP id r40mr29289804qtk.314.1520360505088; Tue, 06 Mar 2018 10:21:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.80.87 with HTTP; Tue, 6 Mar 2018 10:21:44 -0800 (PST)
In-Reply-To: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Tue, 6 Mar 2018 13:21:44 -0500
Message-ID: <CAAZdMafC-=zgCvTwnrz=UJGPeA5UoQcYriM5aAH0aRffZ9Jg1w@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: Eric Rescorla <ekr@rtfm.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f403045d6246d6e78e0566c2838b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2VOLldH7aRuRDWi6HOiXenw5fic>
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 18:21:49 -0000

On Mon, Mar 5, 2018 at 6:05 PM, Eric Rescorla <ekr@rtfm.com>; wrote:

> 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.
>

Hi Ekr,

Thanks for sending out the proposal!

I appreciate the idea of using DTLS, but I'm afraid it just makes things
worse.  Comments inline.

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.
>

I am not sure where the complexity comes from?  If anything, not closing
the stream seems easier than closing it.


>   * Retransmission of stream 0 frames from lost packets needs special
>     handling to avoid accidentally encrypting them.
>

Agreed, you have to handle retransmission of encrypted and handshake data
differently.


>   * Stream 0 is not subject to flow control; it can exceed limits and
>     goes into negative credit after the handshake completes.
>

Again, we can close stream 0 -- I am not entirely sure what's the cost
you're concerned about here, though.


>   * There are complicated rules about which packets can ACK other
>     packets, as both cleartext and ciphertext ACKs are possible.
>

I can see the complexity here, but I don't think there are that many issues
with it -- if anything, this sounds like a reason to simplify the ACK rules.

  * 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'm slightly confused here -- by crypto stack, you mean TLS or the crypto
framing 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.
>

I think this is actually making layering worse than in current
situation.  See this diagram:
http://web.mit.edu/vasilvv/www/quic-tls-layerings.png

The proposed tradeoff is that we get rid of the complexity of having to
deal with both encrypted and unencrypted packets, but as a result we
have to implement two transport stacks -- one inside the TLS library and
one inside the QUIC library.  Having one transport stack is painful
enough.  In practice, DTLS handshake transport mechanisms are always
less polished than commonly used transport stacks.

The layering will still be ugly and leaky, just in different ways -- for
example, you'd have to export the RTT information from your DTLS stack
to your QUIC stack.

It might be interesting to play around with idea of whether we can
actually make unencrypted and encrypted part behave as "two connections
in one" -- i.e.  a cleaner way to reuse the QUIC transport logic while
avoiding painful cross-interactions between them.


> 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.
>

Agreed that we should discuss the merits of the proposal before talking
about the schedule.  That said.  If this miraculously solves all of our
problems, we should definitely go for it; if this kinda-sorta solves
some of the problems we've already worked through while introducing a
whole host of new yet-untackled problems, I am much more skeptical.


> 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.
>

Is there that much of implementation and deployment experience with DTLS
1.3?


> 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
>