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

[Eric Rescorla <[e-mail]>]

Thanks for your feedback. Most of these are editorial comments and
so I think they're my decision as editor about which ones to take
absent some instruction from the chairs.

On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre <[e-mail]> wrote:

> 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]
>

Not all editorial improvements are clarifications.


>
> > 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]
>

This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0
and TLS 1.1" so I think this
is fine.



> > 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.
>

It is. The PSKs here are resumption PSKs. They're not external. The out of
band in
question is knowledge about the server behavior.



>
> > 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"]
>

I believe this is editor discretion.


>
> > 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.
>

I don't understand this argument. The point of this text is that people are
forbidden
to do previous versions by 8996, but we know some people won't so this is
backup guidance. I think this is fine.




>
> > 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.
>

This is actually fairly standard language.



> > 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.
>

I don't follow your argument here either. It's a MUST for any extension you
understand.
Obviously, if you don't understand it, you can't comply with this. I'll
attempt to clarify.


> > 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.
>

I don't think this one is unclear.


> > 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.
>

They're intentional because we know there is actually such an RFC, but you
have to
actually use it.


> > 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..."
>

It is possible, but I prefer to leave it as-is.


> 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.
>

I'll take a look.



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

See above.


>
> > 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".
>

Thanks. Good catch.


>
> > 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..."?
>

I don't think this is a problem.


>
> > 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..."
>

The purpose of this text is to signpost that we know that there might be or
in fact is is such a specification, as opposed to other requirements which
we don't have any reason to think that about.


>
> > 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. Will fix.

-Ekr


>
> 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
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>