From nobody Wed Apr 5 12:50:37 2023 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F20C14CF15 for ; Wed, 5 Apr 2023 12:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpIhHIHKyW5L for ; Wed, 5 Apr 2023 12:50:33 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4183C14CF1F for ; Wed, 5 Apr 2023 12:50:33 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5002bb40596so765818a12.1 for ; Wed, 05 Apr 2023 12:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680724232; x=1683316232; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ONR4XfcRc5DxWiLa6N/EC44PkJAX1o46FCxJjOUZ/Bg=; b=QCedbel9qD00KJN3dTrPo3dq1jpF5TV4/x4y0IYg6pjfQrVyJ8/8DiYAos8+wYFGPD jwgLL7wadT4cQRgDAkt3wydys+Ph80ZoRa8rPy2BKs2WwDNLLe6ajX0QJcNFAPuRfwXR JkQlHG3v2ttPxkguk5WGktetpnQ273GK/CBYkhsrlPsSXNlFMayJwJTAn9e/zq0Hu8Ky AmcfjCtGfRI0IRuFeRO8R+0ahVO1ao9GwSHyUDSqN1wU1QBLtSd6xkxzCvSOlQDEfW8P hLVqChqmRF1m5rp0b01cgA3faTIo9ZhjRu4q/Du2eVaGnEk8CpTVsD7OzhhXHMD9+8pZ iBYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680724232; x=1683316232; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ONR4XfcRc5DxWiLa6N/EC44PkJAX1o46FCxJjOUZ/Bg=; b=cxRAkBuFc6dPM9ht0ZIsQZwKDt4v12pGb7hni/HVY4pMYYI8+skjri9LVtT7KNZBOR IurfxjtrtPw4+fJGlYI9It5uPUMpcWZDINhwu5Q0DGW7annZzb98jVhJLaSZFbOoplm2 pIfSY0PYgJ0ioAg1pAvMT0kBOuSForKm3hrN40wNqS8Mno1O+fFRF+J1MC0t84ZL6aOF seh9Lq01jW6dfNoqEtCggvFCqdI0j5t+wlXN+pPCOUM0jQKEGBFUeh9kRZmPdRcewUcy hOGiINzcJSe2BTNmQE+dvuU/H5PKrvD0Ih10n1lMua41ohFzap07hLQj995Uij7d36nO tY4A== X-Gm-Message-State: AAQBX9e35lY8WSLhHWc7VYGaHKQYxiSufhfm0+bGJGPSdTMdBCg4wY3f OsIvfZ58r7w3tgI1Dd79nK+Pyw9M5Vja17aU6no4GAl1kQQ= X-Google-Smtp-Source: AKy350ZcA0HAmMEATE4OV42cK7DOd1zoTux6L59LOdmdvRyNnxUcKHEtgGNGhuqPuGxD0wMS3N+f2VnelsJV/Autnjs= X-Received: by 2002:a50:d782:0:b0:501:d2f5:7da9 with SMTP id w2-20020a50d782000000b00501d2f57da9mr1834494edi.0.1680724231849; Wed, 05 Apr 2023 12:50:31 -0700 (PDT) MIME-Version: 1.0 References: <5CBA62B3-CFD0-4062-B66D-AFA6F887128B@sn3rd.com> In-Reply-To: From: Rob Sayre Date: Wed, 5 Apr 2023 12:50:20 -0700 Message-ID: To: Eric Rescorla Cc: Stephen Farrell , TLS List Content-Type: multipart/alternative; boundary="000000000000ce0fa005f89c1adc" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2023 19:50:37 -0000 --000000000000ce0fa005f89c1adc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 5, 2023 at 12:26=E2=80=AFPM Eric Rescorla 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=E2=80=AFPM Rob Sayre wrot= e: > >> 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 clarificati= ons] >> > > 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 thin= k >> 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 o= f > 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 jus= t >> 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 doe= s >> 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 yo= u > 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 ot= her >> 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 whic= h > 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=E2=80=AFPM Stephen Farrell >> 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 =E2=80=9CI read it and it looks good=E2=80= =9D 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 >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000ce0fa005f89c1adc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 5, 2023 at 12:26=E2=80=AFPM E= ric Rescorla <ekr@rtfm= .com> wrote:
=
Thanks for your feedback. Most of th= ese 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 c= oncerning most of them. One just finds nitpicks if you read the whole thing= carefully.

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

I think a descriptive "NOT RECOMME= NDED" 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 traff= ic is secure. This is a very common pattern. I found a survey that showed p= opular public sites were likely to accept almost anything (SSL3, unencrypte= d traffic, etc).*

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

thanks,
Rob

*<= /div>
"In fact, the top 100 sites were more likely to still suppor= t SSL 3, TLS 1.0, and TLS 1.1 than servers with much less traffic."

= =C2=A0
On Tue, Apr 4, 2023 at 10:43=E2=80=AFPM= Rob Sayre <sayrer= @gmail.com> wrote:
= Hi,

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

> It= tightens some requirements and contains
> updated text in areas whi= ch were found to be unclear as well as other
> editorial improvement= s.

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

Not a= ll 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 is= n't normative text. However 8996 is entitled "Deprecating TLS 1.0 = and TLS 1.1" so I think this
is fine.



> The protocol d= oes not provide any forward secrecy guarantees for this data.
> The s= erver's behavior determines what forward secrecy
> guarantees, i= f any, apply (see Section 8.1). This behavior is
> not communicated = to the client as part of the protocol.
> Therefore, absent out-of-ba= nd knowledge of the server's behavior,
> the client should assum= e that this data is not forward secret.

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

It is. The PSKs here ar= e resumption PSKs. They're not external. The out of band in
q= uestion is knowledge about the server behavior.

=C2=A0

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

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

[No= starting sentences with "Because"]
<= div>
I believe this is editor discretion.
=C2= =A0

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

I think this makes my "NOT RECOMMENDED&qu= ot; 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 forbi= dden
to do previous versions by 8996, but we know some people won= 't so this is
backup guidance. I think this is fine.
=


=C2=A0
=

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

This doesn&#= 39;t seem like "MUST NOT", since it could be "otherwise spec= ified". I think there needs to be a harsher choice made here, or just = leave it out.

This is actua= lly fairly standard language.



> When processing an extension, re= ceivers MUST
> abort the handshake with a "decode_error" a= lert 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&q= uot;. But the following text says "This does not apply", without = clarifying what "this" is.

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


> After checki= ng 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.=C2=A0 Th= is will require clients to parse the ServerHello in ...

Another &quo= t;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 so= me other specification to the
> contrary, servers which are authenti= cating with an external PSK MUST
> NOT send the CertificateRequest m= essage either in the main handshake
> or request post-handshake auth= entication. =C2=A0[RFC8773] provides an
> extension to permit this, = but has not received the level of analysis
> as this specification.<= br>
Another one of these "In the absence of..." paragraphs. Ma= ybe these are intentional? They still sound really redundant to me.
=C2=A0
They're intentional because we k= now there is actually such an RFC, but you have to
actually use i= t.


> = With a 128-bit key as in AES-128, rekeying 2^64 times has a high
> p= robability of key reuse within a given connection.=C2=A0 Note that even...<= br>
It's almost always possible to drop "Note that..."
=

It is possible, but I prefer t= o leave it as-is.
=C2=A0
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.

=C2=A0
> Note that it is common practice in som= e protocols to use the same

Another "Note that"
<= /div>

See above.
=C2=A0
=

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

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

Here, you mean "resumption_secret".

Thanks. Good catch.
=C2=A0

> Note: Thi= s 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=C2=A0write in an immutab= le document. Maybe "TLS 1.3 does not currently..."?

I don't think this is a problem.
=C2=A0

> In t= he absence of some other specification to the contrary, implementations...<= br>
I must be missing the conversation on this stuff. How could anyone w= rite 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 op= posed to other requirements which
we don't have any reason to= think that about.
=C2=A0

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

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

Thanks. Will fix.

-Ekr
= =C2=A0

thanks,
Rob



On Tue, Apr 4, 2023 at 7:32=E2=80=AFPM Stephe= n Farrell <stephen.farrell@cs.tcd.ie> 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 =E2=80=9CI read it and it looks good=E2=80= =9D 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&q= uot;
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ce0fa005f89c1adc--