Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

[Eric Rescorla <[e-mail]>]

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..0xFFFF),
> >         (0xFFFF)
> >     } 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 field groups, a conventional Diffie-Hellman computation is
> >  performed.  The negotiated key (Z) is converted to a byte string by
> >  encoding in big-endian and padded with zeros up to the size of the
> >  prime.
>
> Presumably "...and left padded...", correct?

Yes, thanks.

>
---------------------------------------------------------------------------
>
> §12.3:
>
> This section seems superfluous.

Agreed.

> It seems that this should cite "Chosen ciphertext attacks against
protocols
> based on the RSA encryption standard PKCS #1".

Agreed.


>
===========================================================================
>
> General (deferred to the end due to length):
>
> As a rule of thumb, "that" is used to start restrictive clauses ("Two
doors
> are in front of you. The door that is on the right leads outside"), while
> "which" is used to start non-restrictive clauses ("The only door in the
room,
> which is made of wood, leads outside.") This document uses "which" where
"that"
> is called for in numerous locations. Although there are several more than
listed
> below, I'm highlighting the locations where a literal reading of "which"
> technically leads to ambiguity. Each instance has a leading line for
context
> (except those that occur at the beginning of a paragraph).

I appreciate that many people hold to this rule of thumb, but it is,
unfortunately, an invented rule:

http://itre.cis.upenn.edu/~myl/languagelog/archives/000918.html
http://itre.cis.upenn.edu/~myl/languagelog/archives/001461.html

  There is an old myth that which is not used in integrated relative
  clauses (e.g. something which I hate) and that has to be used instead
  something that I hate). It is completely untrue. The choice between
  the two is free and open.