Re: [TLS] 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: 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 1C36E3A11AF for <tls@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=ham 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 PWiSvE-nVCnq for <tls@ietfa.amsl.com>; Wed, 6 Jan 2021 10:19:10 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 2FDFC3A114D for <tls@ietf.org>; Wed, 6 Jan 2021 10:19:09 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id b26so8613117lff.9 for <tls@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=UBQioLPPd+90fXyDSJ/FaCwg1sm3UF3hzk+jr5Q7EgfV5VN2jsRgKV+0HHIJ4FEb9X 9aA5BTvAtTX/zVbp7kmmVGoNBvhgK98dGvUCJtv60HCiyxiE8Tztn2wAAcy5+10A25ll vXQdQUQ7QXOXIN5OpO3rdiDuQYZD4PDdbT6IjeIODMjkgtvh7vln0SFZNsTCYgt8MLRu dX6katZz7emWH8tgVokaOx9raA8MsFPLRrpHwRvmYuD1GNu6ryL94LnrMWNyT2+VCUPu WZq8P3JQq5KBVteB7K+lGHw9ifRQr+5Ey7fF/1WZ39u+5oweJJbabnHFhigmqsER2uZK QQOw==
X-Gm-Message-State: AOAM532xnWllmzfSm0g7mELG9La+sXRgCKh5GHKKb86I2ljZz27D7Cgb mxUZT+CxxUCt7wDF5bFIyc9oyeflG6sx1zJakhGolXD+XO9/IxrC
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>
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/tls/5S9eHZiaCdImOWuhj28BJwrb1lo>
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: Wed, 06 Jan 2021 18:19:18 -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