Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Rob Sayre <[e-mail]>]

Hi,

I'm still not sure about the list/vector rename. Aside from that, here's
what I found:

> It tightens some requirements and contains
> updated text in areas which were found to be unclear as well as other
> editorial improvements.

"It contains clarifications and tightened requirements." [let's assume some
things were unclear and that editorial improvements are clarifications]

> In addition, it removes the use of the term
> "master" as applied to secrets in favor of the term "main" or shorter
> names where no term was necessary.  This document makes the following
> specific technical changes:

"It also removes the use of the term..."

--

> Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
[RFC8996].

I know what's meant here, but deprecated does not mean forbidden. I think
you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
reason for that. [but keep reading]

> The protocol does not provide any forward secrecy guarantees for this
data.
> The server's behavior determines what forward secrecy
> guarantees, if any, apply (see Section 8.1). This behavior is
> not communicated to the client as part of the protocol.
> Therefore, absent out-of-band knowledge of the server's behavior,
> the client should assume that this data is not forward secret.

Here, you use the term "out-of-band", but the PSK text replaced
"out-of-band" with "external[ly]". I can't tell whether this usage is
intentional.

> Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
> 1.3 and receives a ClientHello at any other time, it MUST terminate

"TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
receives a ClientHello at any other time, it MUST terminate..."

[No starting sentences with "Because"]

> Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
> versions below 1.2; implementations which do not follow that guidance
> MUST behave as described above.

I think this makes my "NOT RECOMMENDED" suggestion above correct. A
forbidden "MUST NOT" wouldn't need this text.

> Unless otherwise specified, trailing data is forbidden.
> That is, senders MUST NOT include data after the structure in the
> "extension_data" field.

This doesn't seem like "MUST NOT", since it could be "otherwise specified".
I think there needs to be a harsher choice made here, or just leave it out.

> When processing an extension, receivers MUST
> abort the handshake with a "decode_error" alert if there is data left
> over after parsing the structure. This does not apply if the
> receiver does not implement or is configured to ignore an extension.

Again, doesn't seem like a "MUST". But the following text says "This does
not apply", without clarifying what "this" is.

> After checking ServerHello.random to determine if the server
> handshake message is a ServerHello or HelloRetryRequest, clients MUST
> check for this extension prior to processing the rest of the
> ServerHello.  This will require clients to parse the ServerHello in ...

Another "this". Here, I think the text means "This requirement...", but
usually a rewrite can fix these ambiguities.

> In the absence of some other specification to the
> contrary, servers which are authenticating with an external PSK MUST
> NOT send the CertificateRequest message either in the main handshake
> or request post-handshake authentication.  [RFC8773] provides an
> extension to permit this, but has not received the level of analysis
> as this specification.

Another one of these "In the absence of..." paragraphs. Maybe these are
intentional? They still sound really redundant to me.

> With a 128-bit key as in AES-128, rekeying 2^64 times has a high
> probability of key reuse within a given connection.  Note that even...

It's almost always possible to drop "Note that..."

The rest of this paragraph is really heavy on em dashes, and needs to be
rewritten. Some of them seem to be parentheticals, but I would try to
rewrite it as short sentences.

> Note that it is common practice in some protocols to use the same

Another "Note that"

> Note that purely deterministic ECC signatures such as deterministic ECDSA
and EdDSA ...

...

> If the resumption_master_secret has been
> compromised, a resumption handshake with EC(DHE) gives protection
> against passive attackers and a full handshake with EC(DHE) gives
> protection against active attackers.

Here, you mean "resumption_secret".

> Note: This specification does not currently permit the server to send

The old text was better. No "Note:".

The "currently" part seems like the wrong thing to write in an immutable
document. Maybe "TLS 1.3 does not currently..."?

> In the absence of some other specification to the contrary,
implementations...

I must be missing the conversation on this stuff. How could anyone write a
spec if every requirement was prefaced with "in the absence of some other
specification to the contrary..."

> Amplifying existing information leaks caused by side effects like
> caching.  An attacker...

Not a complete sentence here. I think it's just a typo.

thanks,
Rob



On Tue, Apr 4, 2023 at 7:32 PM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it looks good” response.
>
> I looked at the diff between 8446bis-07 and 8446 and it seems
> fine to me. My only comment is that C.4 says one "SHOULD NOT
> reuse a key share" - I'd be happier if that was a "MUST NOT"
> but understand if we stick with SHOULD NOT. If there were a
> good reference showing that it's quite feasible to never
> deliberately re-use a key share, even at scale, that'd be a fine
> addition. (I don't have such a reference to offer,
> sorry;-)
>
> Cheers,
> S.
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>