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

[Rob Sayre <[e-mail]>]

On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla <[e-mail]> wrote:

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

I agree concerning most of them. One just finds nitpicks if you read the
whole thing carefully.

The one thing I think is really substantive is the deprecation of TLS 1.0 /
1.1, since you have a strange nesting of MUSTs.

I think a descriptive "NOT RECOMMENDED" approach would be better here.
Then, describe that servers might choose to accept 1.0/1.1 if they don't
actually care whether the traffic is secure. This is a very common pattern.
I found a survey that showed popular public sites were likely to accept
almost anything (SSL3, unencrypted traffic, etc).*

I think this approach is more accurate, but also more critical in terms of
security than what you have now.

thanks,
Rob

*
"In fact, the top 100 sites were more likely to still support SSL 3, TLS
1.0, and TLS 1.1 than servers with much less traffic."
<
https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report
>



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