Re: Proposal: Run QUIC over DTLS

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Tue, 06 March 2018 11:29 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 01F80120047 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 03:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 0aMqmGTRhrEs for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 03:29:54 -0800 (PST)
Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB0A12708C for <quic@ietf.org>; Tue, 6 Mar 2018 03:29:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zwZLm1tc4z15M8b; Tue, 6 Mar 2018 12:29:52 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch
Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBQeYmn1cNn7; Tue, 6 Mar 2018 12:29:50 +0100 (CET)
X-MtScore: NO score=0
Received: from [192.168.133.28] (i577BCE60.versanet.de [87.123.206.96]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 6 Mar 2018 12:29:50 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: Proposal: Run QUIC over DTLS
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
Date: Tue, 06 Mar 2018 12:29:49 +0100
Cc: IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <58F5AA93-3E63-4550-8668-FC9515BEFD96@tik.ee.ethz.ch>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KOyn6LLvG3ltqxWQ8qvrPvX4p5k>
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 11:29:57 -0000

Hi Ekr, hi all,

I agree that it is architecturally not great to use stream 0 for the crypto handshake and send data unencrypted over this stream. However, layering the crypto above (old school TLS) or below (DTLS) is architecturally also not great and rather a hack given that encryption was not build in from the beginning in the transports we have. Security should be a function on each layer and not something own above or below. The problem here is that the crypto handshake itself needs a transport for its negotiation. So I think separating the handshake/control protocol from the actually record protection is the key point here. TLS already nicely has this separation but then we try to squeeze it on the same transport again. This is also some we discus in TAPS and I have a draft on:

https://datatracker.ietf.org/doc/draft-kuehlewind-taps-crypto-sep/

While I’m in principle supportive with the goal of taking the handshake out of the quic and thereby design quic as a fully encrypted protocol, the one think that I really don’t like about your proposal is that later on also all quic communication needs to run on top of DTLS; that seems unnecessary overhead and also adds a second complete unnecessary reliability layer below the actual transport.

So I guess the alternative, and architectural more clean approach from my point of view, would be to run the crypto handshake completely separate and potentially in parallel to the quic connection, either using DTLS or even TLS over TCP, and then provide the respective keys to the quic crypto engine that than handles the actual record protection. 

However, I don’t think this is something that should be addressed in the current state of the quic design process as we really should focus on the goal to get a first version out quickly. However, my intent was from the beginning to make such a solution possible. QUIC does nicely separate the crypto engine from the rest, such that is should be possible to import keys from an „external“ source. The parts that are less clear separated are the handshake (and other control messages to maintain the crypto engine), especially one would need a separate mechanism to negotiate the transport parameter.

As a side, another nice thing when separating the crypto handshake completely for the HTTP2 use case is also that you in many case already have a TCP/TLS connection to discover the HTTP2 (and quic) support and it would be really nice to reuse these credentials directly to start with quic 0-RTT :-)

Mirja



> Am 06.03.2018 um 00:05 schrieb Eric Rescorla <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.
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
>