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

Eric Rescorla <ekr@rtfm.com> Wed, 06 January 2021 18:19 UTC

Return-Path: <ekr@rtfm.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 934D53A11B7 for <quic@ietfa.amsl.com>; Wed, 6 Jan 2021 10:19:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Nlq6IgLNuvev for <quic@ietfa.amsl.com>; Wed, 6 Jan 2021 10:19:10 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 2713D3A119E for <quic@ietf.org>; Wed, 6 Jan 2021 10:19:09 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id l11so8744891lfg.0 for <quic@ietf.org>; Wed, 06 Jan 2021 10:19:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DrdkM0M5oMCyI06DkEZU5wHs1gvm9/DfGJsT3J0Or8M=; b=FOr4xW5KiOpQNWA2xeiW7mM5qK/9s1+7/H3gIl0qgm4gHGAhLTwSXNB5QTyEx+uDwr erifiZ2kVCA7g8jCFn/r8hNwkiKei5TcfiI3VczoLrQYciK9m3On3LlMd8Hj3MNF67xM moiOJjgPUjzJM+rH5Q5ZVjxE+y95uMG9D86uw5Tt77O6WDA3AF9q1yMgEakYbuVv8Kx8 TACrOC5Hn3HnkHyqJZ6ebJ7MGABUNr+G89NNeh2a3koxP6c6BV6/LfpYxQzyEJWHtP8+ Fg1ZRR1lE/6WuZwkjVYl1OqsO78IiqDowgyRIPbihkd094Ai5QN0UCIXnOegqbi3pBWo R0qA==
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=DrdkM0M5oMCyI06DkEZU5wHs1gvm9/DfGJsT3J0Or8M=; b=dAlYV8hdtuiUTHG3IslpS5Mhs1D/YgudBqAYMtkaX3cvInIffbAWW6ifVXSg61mvYP AZZN4GNv5VjvFQW6O+TdEpkp37qV7Jafgl6OBnSdfsAI9rVknQ+GocPu1tECY5hq5nL0 hAT6YKZVnpG6Z6armNbwExbRtQWjC20d/pq4Uh1mbPE8c2hEdpsvCcUaPrXnNAGLVG7W EaCmhA7rH80E05hj6bRjhVoTsQeuMxIh/DrUOYJpoFbysOc+Tz6WlJEVKBdzjh8wrGjA r1I2+mNAty3BdZA6yN/0SseQ7Xza3hLapNlXpal9l1Fr0Ef1CilzIczsuFy+WVNWjFZe lPfA==
X-Gm-Message-State: AOAM5310ecw7AU7rtZhEStQ9zbHIIy7HclhTDueamAB9Q57VydwVs0H4 UY3j/wMA90Ds7cgHkBQZjR5N63q+tqODxHouUzI8vQ==
X-Google-Smtp-Source: ABdhPJzC6iSRH9DJXi+8oC/sPC31v1W2i+aQPCyDma1AC3ybX3u0Ld1dsAmWXizgX5/FrVkUNpbHYz6NiZSve9KsD+o=
X-Received: by 2002:a19:4f4b:: with SMTP id a11mr2170804lfk.579.1609957147473; Wed, 06 Jan 2021 10:19:07 -0800 (PST)
MIME-Version: 1.0
References: <160982240167.15696.6063503687030193256@ietfa.amsl.com> <fe55a7ad-5b57-416d-bc07-2562491c04d6@www.fastmail.com> <20210106035341.GW93151@kduck.mit.edu>
In-Reply-To: <20210106035341.GW93151@kduck.mit.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 6 Jan 2021 10:18:31 -0800
Message-ID: <CABcZeBM43Gx=QCE=EmYrv_o8R3_AogcA6jNrqxUAP0VOY+-Zrg@mail.gmail.com>
Subject: Re: QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Martin Thomson <mt@lowentropy.net>, "<tls@ietf.org>" <tls@ietf.org>, Mark Nottingham <mnot@mnot.net>, WG Chairs <quic-chairs@ietf.org>, The IESG <iesg@ietf.org>, IETF QUIC WG <quic@ietf.org>, draft-ietf-quic-tls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e1161405b83f5b15"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4NyK3sKJFGPLbuduXBL7A5Mp7aw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 06 Jan 2021 18:19:19 -0000

On Tue, Jan 5, 2021 at 7:54 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Changing Subject: and adding tls@ ...
>
> On Wed, Jan 06, 2021 at 02:04:02PM +1100, Martin Thomson wrote:
> > Hi Ben,
> >
> > I'm going to respond here to your DISCUSS points, but leave the comments
> to our issue tracker.  Lucas has volunteered to do transcription for that.
>
> Sounds good.
>
> > On Tue, Jan 5, 2021, at 15:53, Benjamin Kaduk via Datatracker wrote:
> > > (1) Rather a "discuss-discuss", but we seem to be requiring some
> changes
> > > to TLS 1.3 that are arguably out of charter.  In particular, in Section
> > > 8.3 we see that clients are forbidden from sending EndOfEarlyData and
> it
> > > (accordingly) does not appear in the handshake transcript.  The
> > > reasoning for this is fairly sound; we explicitly index our application
> > > data streams and any truncation will be filled in as a normal part of
> > > the recovery process, so the attack that EndOfEarlyData exists to
> > > prevent instrinsically cannot happen.  However, the only reason we'd be
> > > required to send it in the first place is if the server sends the
> > > "early_data" extension in EncryptedExtensions ... and we already have a
> > > bit of unpleasantness relating to the "early_data" extension, in that
> we
> > > have to use a sentinel value for max_early_data_size in
> NewSessionTicket
> > > to indicate that the ticket is good for 0-RTT, with the actual maximum
> > > amount of data allowed indicated elsewhere.  TLS extensions are cheap,
> > > so a new "quic_early_data" flag extension valid in CH, EE, and NST
> would
> > > keep us from conflating TLS and QUIC 0-RTT semantics, thus solving both
> > > problems at the same time.  On the other hand, that would be requiring
> > > implementations to churn just for process cleanliness, so we might also
> > > consider other alternatives, such as finessing the language and/or
> > > document metadata for how this specification uses TLS 1.3.
> > > (There are a couple other places in the COMMENT where we might suffer
> > > from scope creep regarding TLS behavior as well, but I did not mark
> them
> > > as DISCUSS since they are not changing existing specified behavior.)
> >
> > I don't think that you will find much appetite for changes.  However, I
> think that your suggestion here shows how we can rationalize the change:
> negotiating the quic_transport_parameters extension results in the
> suppression of EndOfEarlyData.  No need for any additional extensions.
>
> 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.


I agree with MT, especially in view of the fact that DTLS also omitted
EOED, which, I think, reflects the TLS WG view that this is OK technically.

https://tlswg.org/dtls13-spec/draft-ietf-tls-dtls13.html#section-5.5

If QUIC weren't at the IESG now we could just make this change cleanly in
8446-bis (details TBD but something about how datagram protocols don't need
it) but in the real world, we should just do it in QUIC and DTLS and then
retroactively bless it.

-Ekr