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

[Eric Rescorla <[e-mail]>]

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.

-Ekr




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