Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT)

Martin Thomson <mt@lowentropy.net> Wed, 06 January 2021 03:04 UTC

Return-Path: <mt@lowentropy.net>
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 6C40B3A0688; Tue, 5 Jan 2021 19:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=lowentropy.net header.b=gdjJJ2A8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pMKJAi1F
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 aRQgOfv2z4ub; Tue, 5 Jan 2021 19:04:27 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA073A0657; Tue, 5 Jan 2021 19:04:27 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6AD525C010F; Tue, 5 Jan 2021 22:04:25 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 05 Jan 2021 22:04:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=97LxFwPBoPhSi7tSIvYqXLgu6kiM aeKMcl0u4sMMmgI=; b=gdjJJ2A804FwqWxydPeVMk1zyiG6lJvMtlvxj4FA/zgW eqIaJ5dKQ9unFDohgIkWwspeklcj4bsav5uJL83zLsL+K2QXBKMtlP/6vlSgcxgi wHmIjef8doRxRGGhG5o+vF25S2g20nLDVAljhXO0EK5efTgINKI+1e1ltfgkufcL BE4I3E0o8u0cr9NUdvX+8B5bPwy2Bj+qNuJeTLJsxWawiL2u8WnBhDWnd4Z1N86D FH4op3AQRdsgE8FTqZymr2MHB9Y84iQGr22wibAobcK1Bl2hHQS/qb/Qm62vAWpc ng0CpAUsODGO13LJTUAlwuNTwUZ5qMpj3GKpiTA+Kg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=97LxFw PBoPhSi7tSIvYqXLgu6kiMaeKMcl0u4sMMmgI=; b=pMKJAi1F5a3Exjui+qF1O9 0QVzZ5Hy1PyT3/rc0Iz/aAZfbwIIZb95IJclShUwbUsQQ0Wj6pjlXcGKwwDFXyzS m1n09EqpBVM/5KyfLawZS6KghaI+fPT/MDX4+KlHgiOeBGutKFVLHNFOeZck46cX KysF9jQSuSSQqyGwKowAEvFyGjOup87zXisc/9WCF18jIG7F8QSNpyhatwr5EUwW yto/lhwvw/lr15NNEWAqTWMmA7tNKGqRHE6J4cCdxpTWrBUDQIAn/1G4a+mpd5ng RbHGCDbrgqYNI1Q9vLGprLCqyyPL8UoE3w6iD6YDyo+faOSDlpO8jhn+Gu8k4YPA ==
X-ME-Sender: <xms:uCj1X-e2iJi8EHAcsQib5qti7UZj9OzHGnD-1etxHgH-fDeO4N97Yw> <xme:uCj1X4OGc_3HK4zyarD-r3pFphOKZTMsvw3DJtP1bmKpuzsl2DGAK4NF-z0dTOP7T z7dWzXs46b1ZU2zfmE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefkedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepleefudfgleegiefgueevledujeejuedtleegvdetheeuvefhvdeh gfegueffiedvnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhn vght
X-ME-Proxy: <xmx:uCj1X_hPLkf6KgD0rPEzIQvAPbEqTRQYatW3rED_GTTpwmfg_yMNog> <xmx:uCj1X79IFPiAGMaAu98VqDNZ93xDaTCK0KchjBwZdlgjhXFZ2WCt-g> <xmx:uCj1X6tXVshrSUUs1i-VUzUKH4sYlUN3rGZjV67xTsw71j1FBwZtvA> <xmx:uSj1X-K6c2tr-XTR11HEasweSsF9nP2ARn-h6j80F0UKJ2x2NAdBIw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1FCB220066; Tue, 5 Jan 2021 22:04:24 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <fe55a7ad-5b57-416d-bc07-2562491c04d6@www.fastmail.com>
In-Reply-To: <160982240167.15696.6063503687030193256@ietfa.amsl.com>
References: <160982240167.15696.6063503687030193256@ietfa.amsl.com>
Date: Wed, 06 Jan 2021 14:04:02 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "'Benjamin Kaduk'" <kaduk@mit.edu>, "The IESG" <iesg@ietf.org>
Cc: draft-ietf-quic-tls@ietf.org, "WG Chairs" <quic-chairs@ietf.org>, quic@ietf.org, "Mark Nottingham" <mnot@mnot.net>
Subject: =?UTF-8?Q?Re:_Benjamin_Kaduk's_Discuss_on_draft-ietf-quic-tls-33:_(with_?= =?UTF-8?Q?DISCUSS_and_COMMENT)?=
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ueTjTSUPXtqEGGZUPGa2A8zOjS8>
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 03:04:31 -0000

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.

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.

Having been responsible for implementing a lot of TLS early data and the QUIC extensions, I can say that your suggestion would be more difficult to manage, because it requires checking two different extensions that independently govern the same behaviour.  (I would concede that I did make some architectural choices that are questionable in light of the above rationalization, but my point stands nonetheless.)

>From a process perspective, if you consider this change to TLS to be out of scope, even though it is specifically limited to QUIC's usage of TLS, then I'm happy to have the TLS working group discuss the change.  It is true that this extension does alter the protocol in a non-trivial way, so requesting specific review is sensible.

I will be strongly advocating for no change, of course.  I will note that we did circulate the draft for review already and this issue did not arise, nor did it arise as it was implemented in many stacks, so I would not expect there to be much support for a different design.

> (2) Let's check whether the quic_transport_parameters TLS extension
> should be marked as Recommended or not.  The document currently says
> "Yes", and the live registry say 'N'.  That said, the earliest mention I
> can see of using 'N' in the archives is in
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/z8MOW0bYNP2KIj4XcCXBe2IOKfI/
> which seems to just be stating what IANA did when they changed what
> codepoint (since there were issues with the initially selected value
> '46') and not a reasoned decision.

The reason that the codepoint has an 'N' is that an early allocation (which we used to obtain the number) cannot be recommended.  However, the intent has always been to recommend the extension.  I don't think that conditional applicability necessarily disqualifies an extension from being recommended.  Just from a quick scan, I can immediately pick out use_srtp as one we recommend, despite it being highly specific.  

I think that recommended means that an extensions comes with the recommendation of the IETF if it provides a relevant function.  Choosing between max_fragment_length vs. record_size_limit is an example of how this might be consumed.

I would strongly prefer that the IETF indicate that they think this extension is good through use of a 'Y'.  That is my understanding of the intent of the signaling.