Re: Proposal: Run QUIC over DTLS

Ian Swett <ianswett@google.com> Tue, 06 March 2018 02:57 UTC

Return-Path: <ianswett@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 5AECA1242EA for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 18:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, 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 FCKI_KvANaLv for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 18:57:00 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 67E451201FA for <quic@ietf.org>; Mon, 5 Mar 2018 18:57:00 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id k135so11946981ite.2 for <quic@ietf.org>; Mon, 05 Mar 2018 18:57:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UtU2p8pE7jxcUDy/UXS7HOoVfUGRA+28nKeKhYeyR/8=; b=TsCNk6jFhsbxeIxFv5iGhHMOsqnmcnAjB3djqyRm0hvaRJeo9erjY2/ocW5uaMurSP Omt3e5DNPl0i1Ov4VyOrZPNr+q6u/l2AM7PwQfaYylHncdAVgtTB79F1CYAPW1xSGeF1 dWh2Ga+FCYo16Gjqo+78uGRPsUrQBDSR4XLdc2K6aSakY9aMrUxE/7l1x4y1vI2qDuQt J35/L8JE/8XzHYUP1M8LhX8LQDjqxB0ctDHvUsxJMlj/SFVyT7+4E17dR9GRcTFlUnKB k9OZKNn8Pbt8HhqFHXGGp5vlqTkDF026Emqx8d2iZxiLow+XLOb4cMP8wpHoIOi3cFGh Xz2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UtU2p8pE7jxcUDy/UXS7HOoVfUGRA+28nKeKhYeyR/8=; b=IUL8/vHDYsQJVmIdwr99Z1tgbkUN1ukVw9ZWawbIYsK5zIKotXvFL4IxMpZHpao28d 2O9Y3hXXXWoo6cPmHA15ej/EDnxn9Gi6PHL7mcM07tj1FPBaxU83UsULGdo9GbPBoSMV 5tM3fsRMZ6v30iPC2qInYz6jw6RON2Cgt+yMB1wiEiifC6saz2EnanOfmLwXw/Xqu1t0 p3J5sXERRhN5m32/OsDNFWgN+7BF2ij5blKDyo0JH09/NFuy6zIrVHDJd7z8NQCWS27z lypYWOVLO8DtafS+DzaaFSqNiFL9m62oXrzeniBSwBaygZJvrrvOk3c2XZOLJsKOPWRM rjzw==
X-Gm-Message-State: AElRT7GLnDbYwQDnGVeFpmfJKc2gVmJ72ccOOaOi8ukuJg1R4voWkX55 oOD4q7tdPTxYkyVFt3rvFHrKS24AS5SiiINUVBXqKg==
X-Google-Smtp-Source: AG47ELvf/vbK/t3RO27oSz/cRM7ytVOvYHRDgvi3YrZZV/ARcGWpwVAxnDyByNYIyPc7HbWpZMTwknLp0LlL8c1jGus=
X-Received: by 10.36.78.14 with SMTP id r14mr16529842ita.146.1520305019336; Mon, 05 Mar 2018 18:56:59 -0800 (PST)
MIME-Version: 1.0
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com> <1F5ABFEF-64F2-4A53-A35B-DF8A4A2A4446@mnot.net> <CABcZeBPEPuOGQZ8ZXTz0Qgcs=Lj1H21_gsPFDZC329kBMTTHPw@mail.gmail.com>
In-Reply-To: <CABcZeBPEPuOGQZ8ZXTz0Qgcs=Lj1H21_gsPFDZC329kBMTTHPw@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Tue, 06 Mar 2018 02:56:47 +0000
Message-ID: <CAKcm_gMmQ=Vco=NtTk3+pB45upVOo5ohx1tmTof6k=tRCLxioA@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: Eric Rescorla <ekr@rtfm.com>
Cc: Mark Nottingham <mnot@mnot.net>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113a9986a139220566b59839"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kX0UwgJj1e9xdRK-3fdtLv4hhJc>
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 02:57:03 -0000

I do not think this is the right way forward for the QUIC WG(reasons
below), though if there are elements of DTLS worth bringing into the QUIC
handshake or TLS over QUIC mapping, I’m certainly open to them.

>From a working group perspective, the WG is finally reaching what is
feeling like convergence on the most critical issues(ie: Invariants), and
this opens many of those up again.  In particular, I'm worried both about
losing momentum and delaying Google's transition away from GQUIC.

>From an architectural perspective, I would like transport at the bottom of
the stack and I only want to run one transport.  Having two different
transports creates more problems than it solves. TLS over TCP is massively
successful, and the current TLS mapping is the most analogous approach I
can come up with.

>From a deployment perspective, having all HTTPS traffic using a single high
quality TLS implementation is very nice.  Unified crypto is definitely a
benefit of switching off QUIC crypto.

>From the perspective of implementation experience, the QUIC WG now has 9
implementations
<https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=207940156>
that achieve interop with the current TLS mapping.  My feeling is that
we're aware of most of the outstanding issues and they are fixable.

>From the Google implementation perspective, the most mature IETF QUIC code
we have is the TLS mapping code, which we now have in deployment quality
code on the client and server side.  We spent more time on this because we
felt the move to TLS 1.3 was one of the few items which had consensus in
the WG, since it was specified in the charter.

Thanks, Ian



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

>
>
> On Mon, Mar 5, 2018 at 5:46 PM, Mark Nottingham <mnot@mnot.net>; wrote:
>
>> Thanks for the proposal, EKR. We'll track this as <
>> https://github.com/quicwg/base-drafts/issues/1165>;.
>>
>> Since we're trying to nail down the invariants in London (or soon
>> afterwards), I'd like to figure out the WG's feelings on this pretty
>> quickly.
>>
>> I know folks need a chance to read and digest, but it would be extremely
>> helpful if we could have some initial discussion on-list now. Please focus
>> on the technical merit of the proposal, clarifying questions, and
>> statements of support/lack thereof.
>>
>> Assuming it's still a topic of interest in two weeks, we'll schedule some
>> time to discuss it in London. EKR, could you please submit a presentation
>> (say, max 20 minutes, plus discussion time afterwards) ASAP?
>>
>
> Willdo. It would be especially helpful to have clarifying questions
> soonish so that I can either clarify them on-list, or know to hit them in
> the preso.
>
> -Ekr
>
>
>>
>> Cheers,
>>
>>
>> > On 6 Mar 2018, at 10:05 am, 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.
>> >
>> > 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>