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

[Sean Turner <[e-mail]>]

I only have nits and then I approve:

0) s4.1.4: swap out the only contraction

s/aren’t/are not

1) some early data to 0-RTT swaps for consistency:

1.0) s4.1

s/early data/0-RTT data

1.1) s4.6.1:

OLD:
QUIC does not use TLS 0-RTT data. QUIC uses 0-RTT packets to carry early data. 

NEW:
QUIC does not use TLS early data. QUIC uses 0-RTT packets to carry early data. 

1.2) s4.6.3: 6 instance of

s/early data/0-RTT data

2) s5.1

OLD:
In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of 
[TLS13] is used, using the hash function from the negotiated cipher 
suite.

NEW:
In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of 
[TLS13] is used with the hash function from the negotiated cipher 
suite.

Cheers,
spt

> On May 19, 2021, at 18:35, Jean Mahoney <[e-mail]> wrote:
> 
> Martin,
> 
> We've noted your approval on the AUTH48 status page:
> 
>    https://www.rfc-editor.org/auth48/rfc9001
> 
> We will await word from Sean regarding other AUTH48 changes and/or approval.
> 
> Thank you!
> 
> RFC Editor/jm
> 
> 
> On 5/19/21 5:15 PM, Martin Thomson wrote:
>> 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, [e-mail] 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.