Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

Benjamin Kaduk <kaduk@mit.edu> Thu, 07 January 2021 04:04 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A40D3A14EC; Wed, 6 Jan 2021 20:04:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 nLLaSjHcgy2i; Wed, 6 Jan 2021 20:04:39 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2393A14EB; Wed, 6 Jan 2021 20:04:38 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10744UIO024592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Jan 2021 23:04:35 -0500
Date: Wed, 6 Jan 2021 20:04:30 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Thomson <mt@lowentropy.net>
Cc: tls@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-quic-tls@ietf.org, WG Chairs <quic-chairs@ietf.org>, quic@ietf.org, Mark Nottingham <mnot@mnot.net>
Message-ID: <20210107040430.GF93151@kduck.mit.edu>
References: <160982240167.15696.6063503687030193256@ietfa.amsl.com> <fe55a7ad-5b57-416d-bc07-2562491c04d6@www.fastmail.com> <20210106035341.GW93151@kduck.mit.edu> <9b950156-7b73-4bd2-8cd7-b0f4caa9d7af@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9b950156-7b73-4bd2-8cd7-b0f4caa9d7af@www.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1uKEHu1JLFmDKj_N4JLnIg2QUFA>
Subject: Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 04:04:42 -0000

On Thu, Jan 07, 2021 at 02:50:43PM +1100, Martin Thomson wrote:
> Trimming this down.
> 
> On Wed, Jan 6, 2021, at 14:53, Benjamin Kaduk wrote:
> > I didn't expect to find much appetite for changes, but I wouldn't be doing
> > my job if I didn't ask the question.  It's a little unusual for something
> > outside the core protocol to change the behavior of an extension defined in
> > the core protocol, but perhaps not unheard of.  There is also the question
> > of whether it would merit an "Updates:" relationship ... since you have to
> > implement the rest of the new thing to get the new semantics, it may not be
> > needed.
> 
> This isn't an "Updates: X" moment at all in my view.  Extensions to TLS have added new handshake messages (certificate status for instance) without updating what it means to implement the core protocol.  It's only an update in my view if the functions defined in the updated document.

(incomplete?)

> > Which behavior is that, exactly?  The QUIC 0-RTT keys are different than
> > the TLS ones, and the data itself is carried in a different place...
> 
> I referred to all of the code that involves 0-RTT.

At what layer?  I honestly do not understand which parts you see as "the
same behavior".  The application will have some data to send early, sure,
but at some point your interface has to know if it's running over TCP+TLS
or over QUIC, and the only differences I see are below that point.  Any
given TLS handshake is intrinsically destined for QUIC or not-QUIC, so
you're never in a situation where you would send both extensions at the
same time.

> > I think the key question for the TLS WG might be how similar something has
> > to be before it's a good idea to reuse an extension codepoint vs. getting a
> > new one.
> 
> If you like.
>  
> > For what little it's worth, the patches to enable building a QUIC stack on
> > top of OpenSSL (that have been rejected by upstream at this point
> 
> (incomplete?)

Yes, sorry -- interrupted mid-compose.

For what little it's worth, the patches to enable building a QUIC stack on
top of OpenSSL (that have been rejected by upstream at this point in the
3.0.0 release cycle and are now maintained by Akamai and used by several
parties) don't implement support for early data at all, so I don't have any
direct implementation insight to provide.  OTOH, that suggests that people
might not be using QUIC 0-RTT with the openssl TLS stack at all.

-Ben