Hi Adam,
Thanks for your comments.
I'm going to let the Chairs handle the Abstract one.
Responses below (I'm ignoring a bunch which I just agree with).
> §4.2.1:
>
> > TLS SHOULD support TLS 1.2. Servers should be prepared to receive
> > ClientHellos that include this extension but do not include 0x0304 in
> > the list of versions.
>
> This "should" reads as if it should be normative. It also seems that
making this
> "should" instead of "MUST" could result in the same "can't negotiate to
earlier
> versions" implementation situation that is mentioned elsewhere in the
document.
> Consider a server that supports TLS 1.2 and TLS 1.3. It receives a
ClientHello
> from a client that supports TLS 1.2 and a future TLS 1.4. Let's postulate
that
> this client doesn't support 1.3 (say, because of some uncurable flaw that
> exists in 1.3, but not in 1.2 or 1.4). If the server isn't prepared to
deal
> with this situation, we end up in the same "can't move versions forward"
> corner that led to freezing the legacy version string at 0x0303.
Yes, I agree. This should be a MUST.
> §4.2.3:
>
> > /* Reserved Code Points */
> > private_use(0xFE00..0x),
> > (0x)
> > } SignatureScheme;
>
> When a node supports both TLS 1.2 and TLS 1.3, this private use space only
> allows for the definition of two private-use hashes that can be used in
both
> circumstances (as only 0xFE and 0xFF will be recognized by 1.2 as
specifying
> hashes). I don't know what the use cases for this private use space is;
but
> given the relatively generous allocation in RFC 5246, is two going to be
enough?
I am not sure anyone has every used this space at all, so I tend to think
this
is OK.
> §5.5:
>
> > There are cryptographic limits on the amount of plaintext which can
> > be safely encrypted under a given set of keys. [AEAD-LIMITS]
> > provides an analysis of these limits under the assumption that the
> > underlying primitive (AES or ChaCha20) has no weaknesses.
> > Implementations SHOULD do a key update as described in Section 4.6.3
> > prior to reaching these limits.
>
> Implementing this "SHOULD" is predicated on understanding the contents of
> [AEAD-LIMITS], which means [AEAD-LIMITS] needs to be a normative
reference.
Agreed.
> > - TLS SignatureScheme Registry: Values with the first byte in the
> > range 0-253 (decimal) are assigned via Specification Required
> > [RFC8126]. Values with the first byte 254 or 255 (decimal) are
> > reserved for Private Use [RFC8126]. Values with the first byte in
> > the range 0-6 or with the second byte in the range 0-3 that are
> > not currently allocated are reserved for backwards compatibility.
>
> Unless I misunderstand the compatibility mechanisms here, the reservation
of
> first byte=0-6 seems to assume that no further assignments will be made
from
> the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the
case, I
> would expect the IANA considerations section to include a request that
the IANA
> close the table to further registrations. The same comment applies to TLS
> SignatureAlgorithm Registry.
Agreed, but I'd like to hear from the chairs.
> This is a consolidation of the structures found in the document.
Presumably,
> Appendix B is normative and the other versions are illustrative? To help
deal
> with the possibility of conflicts between the two versions, it would be
nice if
> this were stated explicitly.
B is machine generated from the rest of the text, but I'm happy to add
something here.
>
===
> Editorial Nits
>
---
>
> General:
>
> ** There are 33 instances of too long lines in the document, the longest
> one being 8 characters in excess of 72.
I expect the RFC Editor to fix this.
>
---
>
> General:
>
> Although both "implementor" and "implementer" are acceptable spellings,
> it is unusual for a document to switch back and forth. I recommend
consistency.
OK.
>
---
>
> §4.4.3:
>
> > The context string for a server signature is "TLS 1.3, server
> > CertificateVerify" and for a client signature is "TLS 1.3, client
> > CertificateVerify". It is used to provide separation between
> > signatures made in different contexts, helping against potential
> > cross-protocol attacks.
>
> Although the example makes it clear, the preceding is the normative
description
> of behavior. Since the limitations of the RFC format result in line
wrapping in
> the middle of two strings that must be bit exact for the protocol to
function,
> it is probably worthwhile setting them off on their own lines so that
they don't
> contain extra line feeds and indenting spaces.
Thanks. I can do this.
> §7.4.1:
>
> > For finite
