Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
On Wed, Apr 5, 2023 at 12:53 PM Eric Rescorla wrote: > > > On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre wrote: > >> On Wed, Apr 5, 2023 at 12:26 PM 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 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. 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 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
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre wrote: > On Wed, Apr 5, 2023 at 12:26 PM 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 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 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
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
On Wed, Apr 5, 2023 at 12:26 PM 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 PM Rob Sayre 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
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
This was discussed extensively when 8446 was published and there wasn't consensus to make such a change. If the chairs want to re-open this issue, please weigh in. -Ekr On Tue, Apr 4, 2023 at 7:32 PM 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 “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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
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 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
[TLS] Fwd: WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
Too fast. Very sorry, it is already linked to that thread. Weitergeleitete Nachricht Betreff: Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis Datum: Wed, 5 Apr 2023 10:47:11 +0200 Von: Achim Kraus An: Martin Thomson , tls@ietf.org Let me try to link this thread to the similar question raised during the implementation of RPK in openssl. https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/ My personal "favorite interpretation" of RFC5246 7.4.6. Client Certificate is to stick to that definition there regardless of the certificate type, which isn't mentioned there. "If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero." Means: no xYz (e.g. RPK) certificate results in an empty list (3x 0x00). From the other thread, there seems to be also other certificate types, which defined this different, but for all, which starts with a 3-bytes length, the "empty list" will do it. best regards Achim Am 05.04.23 um 08:02 schrieb Martin Thomson: I mentioned this to Ekr off-list, but I thought I would add one more thing. What did we conclude about a client that refuses to provide a raw public key when asked by a server? Are we in a position to change the minimum length from 1 to 0 in the response? The thread didn't really end with a solid conclusion, other than a note from Ilari indicating that maybe a zero length RPK would be OK in some libraries. See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/ On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote: https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07 might be helpful to others. I opened a few issues, but the TLS 1.3 revision is very much ready to be published. For the 8447 revision, I found that our decision to remove the definition of the fields for each registry to be difficult. The draft lists changes, so now this document is no longer an easy reference for how to register TLS extension bits. Not a big deal and I don't want to ask the authors to flip flop here, but I wanted to flag it. On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote: As mentioned during yesterday's meeting, this email starts the working group last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located here: - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis The WG Last Call will end on April 18, 2023. Please review the documents and submit issues or pull requests via the GitHub repositories, which can be found at: - https://github.com/tlswg/tls13-spec - https://github.com/tlswg/rfc8447bis Alternatively, you can also send your comments to tls@ietf.org. Thanks, Chris ___ 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 ___ 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
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
Let me try to link this thread to the similar question raised during the implementation of RPK in openssl. https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/ My personal "favorite interpretation" of RFC5246 7.4.6. Client Certificate is to stick to that definition there regardless of the certificate type, which isn't mentioned there. "If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero." Means: no xYz (e.g. RPK) certificate results in an empty list (3x 0x00). From the other thread, there seems to be also other certificate types, which defined this different, but for all, which starts with a 3-bytes length, the "empty list" will do it. best regards Achim Am 05.04.23 um 08:02 schrieb Martin Thomson: I mentioned this to Ekr off-list, but I thought I would add one more thing. What did we conclude about a client that refuses to provide a raw public key when asked by a server? Are we in a position to change the minimum length from 1 to 0 in the response? The thread didn't really end with a solid conclusion, other than a note from Ilari indicating that maybe a zero length RPK would be OK in some libraries. See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/ On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote: https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07 might be helpful to others. I opened a few issues, but the TLS 1.3 revision is very much ready to be published. For the 8447 revision, I found that our decision to remove the definition of the fields for each registry to be difficult. The draft lists changes, so now this document is no longer an easy reference for how to register TLS extension bits. Not a big deal and I don't want to ask the authors to flip flop here, but I wanted to flag it. On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote: As mentioned during yesterday's meeting, this email starts the working group last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located here: - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis The WG Last Call will end on April 18, 2023. Please review the documents and submit issues or pull requests via the GitHub repositories, which can be found at: - https://github.com/tlswg/tls13-spec - https://github.com/tlswg/rfc8447bis Alternatively, you can also send your comments to tls@ietf.org. Thanks, Chris ___ 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 ___ 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
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
I mentioned this to Ekr off-list, but I thought I would add one more thing. What did we conclude about a client that refuses to provide a raw public key when asked by a server? Are we in a position to change the minimum length from 1 to 0 in the response? The thread didn't really end with a solid conclusion, other than a note from Ilari indicating that maybe a zero length RPK would be OK in some libraries. See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/ On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote: > https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07 > > might be helpful to others. > > I opened a few issues, but the TLS 1.3 revision is very much ready to > be published. > > For the 8447 revision, I found that our decision to remove the > definition of the fields for each registry to be difficult. The draft > lists changes, so now this document is no longer an easy reference for > how to register TLS extension bits. Not a big deal and I don't want to > ask the authors to flip flop here, but I wanted to flag it. > > On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote: >> As mentioned during yesterday's meeting, this email starts the working >> group last call for "The Transport Layer Security (TLS) Protocol >> Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located >> here: >> >> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis >> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis >> >> The WG Last Call will end on April 18, 2023. >> >> Please review the documents and submit issues or pull requests via the >> GitHub repositories, which can be found at: >> >> - https://github.com/tlswg/tls13-spec >> - https://github.com/tlswg/rfc8447bis >> >> Alternatively, you can also send your comments to tls@ietf.org. >> >> Thanks, >> Chris >> ___ >> 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
