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

["Martin Thomson" <[e-mail]>]

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.