Re: [C430] AUTH48 [JM]: RFC 9001 <draft-ietf-quic-tls-34.txt> NOW AVAILABLE

"Martin Thomson" <mt@lowentropy.net> Wed, 19 May 2021 22:16 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: c430@rfc-editor.org
Delivered-To: c430@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id A01D3F407A3; Wed, 19 May 2021 15:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -97.978
X-Spam-Level:
X-Spam-Status: No, score=-97.978 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=0.01, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=2, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=0.01, SPF_PASS=-0.001, SUBJECT_IN_WHITELIST=-100, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=L2TBysvo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZtdpIHk6
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EB6xOAkgPUe; Wed, 19 May 2021 15:16:10 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by rfc-editor.org (Postfix) with ESMTPS id 19A1BF40767; Wed, 19 May 2021 15:16:10 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 566275C0145; Wed, 19 May 2021 18:16:10 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Wed, 19 May 2021 18:16:10 -0400
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:content-transfer-encoding; s=fm2; bh=Bw QpV261HvDis1DlJYM2GlhdlW80p++MDwdEF/NyI+A=; b=L2TBysvoGssdR4OE7h oxbl4nELwikvdyvyG4mQIsx18GCzYKFC3nJTNIm1LoTHz7H9Q/BviSwdgQZSfY/8 u3DHcvuz6D0JnC2EO1hl6j8fDyAzJnLzOXVsfA6eIXRuXkP0xNKA4Im8jMoElv0s XOo/q1mYgE2oll6I8r8hiq0Uu7fcVLe+Z14tHrqK/gHSVFdMci4eU+9TbkVcui6J OcZftddLcsn+/Z333Qvlo4S/PkNuxyrTJoOWMoU2WCHA8Cz7lRFkUpHHI1BkxYkj diJPhd6vhbk6WSA+tKwrlGJg1tM+czD8FVlwMIzKSRSDrrZcHofr+AP/qxpLeNmG et5Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=BwQpV261HvDis1DlJYM2GlhdlW80p++MDwdEF/NyI +A=; b=ZtdpIHk6sfjq7FZhCwJCT3GwGymvXfwwJcN8toHDTiDEhlsOAC5q6YOzn JEPydqH3GbF5pbyN2s9/iRQySvaSlzMefoXUxd0/02vjPXgjQYMdSiiEyEQjTI0s Eml8bWP3z7a3IstK4mRW66+f1mnvG1h7M0rgiIexYYcENYozcXe0ZysxlKK4zQYA TfzgFLAKhESKQvo8PU0MtXSVfvESInKkMrS3vBw6Ss1WCbrSa+2IWV6Ikz4Z/YoO tZMHdB4WlJTpSqH4GFtt6nGcr2za9RpRA3B2d6Spsm7nERQZCVQt/+GSxKOqYWR3 f/2qvFqLCq0LdR0cBkWH/4PI2nTZQ==
X-ME-Sender: <xms:KI6lYDCHYSZBFcdp1qjg9yKA5ulu6K3akDDZGMa9wlVe9XdGJQgqYg> <xme:KI6lYJjLMX_gs_LWmRTn5W51eg8Lb1awba6syUpbn73knQ2T0ADmkmEHxutQti1Ak gu_jv_9vmDGWpp1vqk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejtddgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeffveeugfffgfduieeggfeihedtvdffueeiffdvhfduffeufedu heejtdduteehhfenucffohhmrghinhepihgvthhfrdhorhhgpdhrfhgtqdgvughithhorh drohhrghdprhhhuhhlrdgrtgdruhhkpdhgihhthhhusgdrtghomhenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhoph ihrdhnvght
X-ME-Proxy: <xmx:KI6lYOmXnlzPikVeUbafLsPxNQwU6znPunAkdT1EpsUVeM4tDdNyUg> <xmx:KI6lYFxwsUndZ-sDulXoL7FIv8OtwmgMjFGDYkhlZjcLDmeDzerqgg> <xmx:KI6lYIRDk2Qy8j9bLePz_tuwEZw6I9VjjgXry3f_SQ8gsq8oWu9UeQ> <xmx:Ko6lYNRrheIFc69L3SSQz7wPKDdfpQJ9PzaOzEIoO7Wlfvy15BeNcw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 692234E00BE; Wed, 19 May 2021 18:16:08 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-Id: <a3b87aaa-2d6a-46fb-ad50-fb027d959dec@www.fastmail.com>
In-Reply-To: <dfc0b917-b631-12b2-9ccf-6b41db8233d4@amsl.com>
References: <20210427074149.B07ADF40797@rfc-editor.org> <3fac22d9-bbbc-4963-92f8-2a3aa399a390@www.fastmail.com> <1edada0f-0ecd-4d10-4ed6-a7642f83a8db@amsl.com> <a376f198-3d80-4adb-9639-217e2e49847e@www.fastmail.com> <dfc0b917-b631-12b2-9ccf-6b41db8233d4@amsl.com>
Date: Thu, 20 May 2021 08:15:49 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Jean Mahoney <jmahoney@amsl.com>, rfc-editor <rfc-editor@rfc-editor.org>, Sean Turner <sean@sn3rd.com>
Cc: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, Martin Thomson via C430 <c430@rfc-editor.org>, Matt Joras <matt.joras@gmail.com>, Mark Nottingham <mnot@mnot.net>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Lars Eggert <lars@eggert.org>, Martin Duke <martin.h.duke@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [C430] AUTH48 [JM]: RFC 9001 <draft-ietf-quic-tls-34.txt> NOW AVAILABLE
X-BeenThere: c430@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <c430.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/c430>, <mailto:c430-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/c430/>
List-Post: <mailto:c430@rfc-editor.org>
List-Help: <mailto:c430-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/c430>, <mailto:c430-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2021 22:16:14 -0000

Thanks Jean,

I've reviewed the changes and approve this document.

On Wed, May 19, 2021, at 03:02, Jean Mahoney wrote:
> Martin,
> 
> Thank you for the updated file. The discrepancy with the URLs in the RFC 
> references is indeed an xml2rfc issue. I have opened a ticket:
> 
>     https://trac.ietf.org/trac/xml2rfc/ticket/640
> 
> And I have explicitly set the URLs in the XML file:
> 
>     https://www.rfc-editor.org/authors/rfc9001-xmllastrfcdiff.html 
> (these changes in the XML)
>     https://www.rfc-editor.org/authors/rfc9001-lastrfcdiff.html (these 
> changes in the text)
> 
>     https://www.rfc-editor.org/authors/rfc9001.txt
>     https://www.rfc-editor.org/authors/rfc9001.pdf
>     https://www.rfc-editor.org/authors/rfc9001.html
>     https://www.rfc-editor.org/authors/rfc9001.xml
> 
> We will await further word from you and your coauthor regarding other 
> AUTH48 changes and/or approval.
> 
> Best regards,
> 
> RFC Editor/jm
> 
> 
> On 5/17/21 5:41 PM, Martin Thomson wrote:
> > When it comes to references, I think that it is best that you make those changes.  The changes you see are the result of automation.  I can fix the AEBounds one, but I'll need to coordinate with Carsten on the smart quote, and the rfc-editor.org one is down to either the XML files on rfc-editor.org (this is where we pull those references from) or xml2rfc.
> >
> > I'll try to track these all down, but in the interests of progress, if you can make those changes, I'd be happy to approve the document.
> >
> > On Tue, May 18, 2021, at 05:53, Jean Mahoney wrote:
> >> Martin,
> >>
> >> Thank you for updating the document! We found a few small issues in the
> >> References section:
> >>
> >>> The URLs for RFCs should point to the RFC landing page ("/info/" instead of "/rfc/"):
> >>>     Current:  <https://www.rfc-editor.org/rfc/rfcNNNN>
> >>>     Should be:  <https://www.rfc-editor.org/info/rfcNNNN>
> >>> The URL for [AEBounds] works but it's only http:
> >>>     Current: <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>
> >>>     Perhaps: <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>
> >>> A smart quote was introduced into the [GCM-MU] reference:
> >>>     Current: CCS ‘18: Proceedings of ...
> >>>     Should be: CCS '18: Proceedings of
> >>
> >>
> >> Would you like us to make these updates or would you like to update the file?
> >>
> >> Regarding the issue with line breaks within <sup>, the following ticket
> >> has been opened:
> >>
> >>     https://trac.ietf.org/trac/xml2rfc/ticket/631
> >>
> >> Best regards,
> >>
> >> RFC Editor/jm
> >>
> >> On 4/28/21 9:24 PM, Martin Thomson via C430 wrote:
> >>> Thanks for the work on this document.
> >> I've staged a bunch of changes in our source repository for review.  I
> >> will provide updated XML once that process is complete.  For now, I
> >> will try to note differences so that there are no surprises.
> >>
> >> The complete set of outstanding changes to this document are in
> >> progress, so they are either in our working copy:
> >>    
> >> https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-tls.md
> >> or they are in open pull requests that affect that document:
> >>    
> >> https://github.com/quicwg/base-drafts/pulls?q=is%3Apr+is%3Aopen+label%3A-tls
> >>
> >> I have only made very minor changes in this document on top of what has
> >> been suggested.
> >>
> >> One annoying little nit comes from unrelated edits in one paragraph
> >> that caused the string 2<sup>-57</sup> to render badly in text.  In
> >> text, this now renders with "2^-" on one line and "57" on the next.  Do
> >> we have any strategy for dealing with this?  I don't think that moving
> >> to a non-breaking hyphen is a good answer for this case.  Changes to
> >> xml2rfc so that it avoids line breaks before and inside <sup> (and
> >> <sub>) might be worth considering though.
> >>
> >> I have not yet worked out how to generate <th> elements instead of <td>
> >> for the left column of tables as proposed.  While the rendering from
> >> xml2rfc in text of a table like this is terrible enough that I was
> >> initially inclined to reject this change, that is a problem with
> >> xml2rfc, not the change.  The semantic change is good.  I just wanted
> >> to note that I've an open issue to work out how to manage this:
> >> https://github.com/quicwg/base-drafts/issues/4872
> >>
> >> I note that many <artwork> elements have been converted to
> >> <sourcecode>.  This is mostly good, but I don't think that it is
> >> appropriate to label the notation we've invented here as "pseudocode".
> >> I've not applied that change.  I note that RFC-to-be 8999 didn't
> >> include that change, which in this case is appropriate.  This is
> >> deliberately not a formal grammar, it's an illustration aid.
> >>
> >>> https://www.rfc-editor.org/authors/rfc9001-xmldiff2.html exists, but is broken.  The other XML diff currently shows numbered anchors.  The XML diff completely mangled the appendix, so I've applied changes based on the text diff only.
> >> Though I did say I wouldn't update references, I have done so for the
> >> two that had changes here.  We have another tooling issue to work
> >> through; <refcontent> is being stripped out for the moment, but I'm
> >> working on that.
> >>
> >> On Tue, Apr 27, 2021, at 17:41, rfc-editor@rfc-editor.org wrote:
> >>>> 2) <!-- [rfced] Please review the items marked "Note:" and let us know
> >> if any should be marked as <aside>.  Some are not clear to us,
> >> especially those that contain RFC 2119 keywords.
> >>
> >> For example:
> >>     Note:  An endpoint MUST NOT reject a ClientHello that offers a cipher
> >>        suite that it does not support, or it would be impossible to
> >>        deploy a new cipher suite.  This also applies to
> >>        TLS_AES_128_CCM_8_SHA256.
> >>
> >> -->
> >>> I found two such cases and have proposed changes that remove the "note: " lead-in.  The others are all appropriate uses of <aside/> and I've also proposed a matching change.  Now, if the rendering of <aside> in text weren't so terrible I'd be happy about this outcome.
> >> I would say that better support in the grammar for notes would be worth
> >> exploring.  <aside prologue="Note"> would be a very useful feature.
> >>
> >>>> 3) <!-- [rfced]  We are having difficulty parsing the following sentence.
> >> Current:
> >>     The same number of bytes are always sampled, but an allowance needs
> >>     to be made for the endpoint removing protection, which will not know
> >>     the length of the Packet Number field.
> >>
> >> Perhaps:
> >>     The same number of bytes are always sampled, but an allowance needs
> >>     to be made for the removal of protection by the endpoint, which
> >>     will not know the length of the Packet Number field.
> >> -->
> >>> That is better, though endpoint role here probably needs clarification.  I've used "receiving endpoint" instead.
> >>>> 4) <!-- [rfced]  FYI  We have updated the following cross reference to point
> >> to Section 9.5 (Header Protection Timing Side Channels) rather than
> >> 9.4 (Header Protection Analysis). Please let us know if changes are
> >> necessary:
> >>> Yes, this is a good change.  Thanks.
> >>>> 5) <!-- [rfced]  We are having difficulty parsing the following:
> >> Current:
> >>     Using dummy keys will generate no variation in the
> >>     timing signal produced by attempting to remove packet protection, and
> >>     results in all packets with an invalid Key Phase bit being rejected.
> >>
> >> Perhaps:
> >>     The use of dummy keys introduces no variation in the
> >>     timing signal, which could be altered by attempting to remove packet
> >>     protection, and results in all packets with an invalid Key Phase bit
> >>     being rejected.
> >> -->
> >>> That would subtly change the meaning.
> >> I'm going to suggest:
> >>
> >>>> Using randomized keys ensures that attempting to remove packet protection does not result in timing variations, and results in packets with an invalid Key Phase bit being rejected.
> >>> An aside: someone noted that "dummy" was problematic and so I've separately changed this to "randomized" in the preceding sentence also.
> >>>> 6) <!-- [rfced]  FYI  We have made the following edit to improve readability.
> >>     QUIC extensions MUST either describe how replay attacks affect their
> >>     operation or prohibit the use of the extension in 0-RTT.
> >>> This is good.
> >>>> 7) <!-- [rfced]  Note that we have updated the date and URL listed for
> >> [AEBounds]
> >>> Thanks.
> >>>> 8) <!-- [rfced]  FYI  We have made the following update to improve
> >> readability.
> >>     *  The number of ciphertext blocks an attacker uses in forgery
> >>        attempts is bounded by v * l, which is the number of forgery
> >>        attempts multiplied by the size of each packet (in blocks).
> >>> Also good, thanks.
> >>>> 9) <!-- [rfced] Throughout the text, the following term appears to be used
> >> inconsistently. Please review these occurrences and let us know if/how they
> >> may be made consistent.
> >>
> >> application data / Application Data / Application data
> >>
> >> Note that RFC-to-be 9000 <draft-ietf-quic-transport> uses the lowercase
> >> form consistently.
> >>> Yes. I have reviewed this and I think that I've made it more consistent.  The outcome is that figures will use title case for consistency (as appropriate) and text will use the lowercase form.  There is one reference to TLS Application Data, where I have kept the title case to match the usage in RFC 8446.
>