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

[Rob Sayre <[e-mail]>]

On Wed, Apr 5, 2023 at 1:05 PM Rob Sayre <[e-mail]> wrote:

>
>
> On Wed, Apr 5, 2023 at 12:53 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre <[e-mail]> wrote:
>>
>>> 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 don't see how we can use NOT RECOMMENDED here, because we already have
>> an RFC which prohibits the use of TLS 1.0 and TLS 1.1 and we're not
>> contradicting
>> that. The purpose of the text you highlight is to address people who are
>> nonconformant
>> with that RFC.
>>
>
> I see your point. RFC8996 does say "MUST NOT", but that's not deprecation.
> It's prohibition, as you say. So, the title of the document is confusing.
>
> I still think what it's in this document is confusing, because it says "if
> you don't follow this MUST, you have to follow this MUST...".
>
> But I can see this situation is kind of messy, so I think it's editorial.
>

Hi, sorry to be a pest here, but maybe this isn't editorial.

First, one nit: "negotation" here:

4.1.3 Server Hello:
>   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.

Here's my effort, just to make it more than a complaint. I'm not attached
to the exact wording:

"In order to preserve the security properties enumerated in the
Introduction, [RFC8996] and Appendix E.5 forbid the negotiation of TLS
versions below 1.2. Implementations willing to accept obsolete TLS versions
MUST behave as described above."

Appendix E.5:
>   The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246],
>   and TLS 1.1 [RFC4346] are considered insufficient for the reasons
>   enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT
>   be negotiated for any reason.

Here, I would end with "...for any reason in applications that require a
secure channel."

>   Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
>   HELLO.  Implementations MUST NOT negotiate TLS 1.3 or later using an
>   SSL version 2.0 compatible CLIENT-HELLO.  Implementations are NOT
>   RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
>   order to negotiate older versions of TLS.

Without the little trailing text I added above, this seems a little
contradictory. The thinking here is the document says this is NOT
RECOMMENDED, but it's something they MUST NOT do, unless you only mean TLS
1.2 here.

thanks,
Rob







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