[TLS] Re: I-D Action: draft-ietf-tls-svcb-ech-05.txt
Thanks to the authors for updating the I-D to address the nits I noted while doing the Shepherd write-up. I will finish the Shepherd write-up and then this I-D can progress with the draft-ietf-tls-esni. spt > On Sep 3, 2024, at 19:19, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-svcb-ech-05.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings > Authors: Ben Schwartz >Mike Bishop >Erik Nygren > Name:draft-ietf-tls-svcb-ech-05.txt > Pages: 7 > Dates: 2024-09-03 > > Abstract: > > To use TLS Encrypted ClientHello (ECH) the client needs to learn the > ECH configuration for a server before it attempts a connection to the > server. This specification provides a mechanism for conveying the > ECH configuration information via DNS, using a SVCB or HTTPS record. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-05.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-05 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list -- i-d-annou...@ietf.org > To unsubscribe send an email to i-d-announce-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [TLS]Re: [Editorial Errata Reported] RFC6347 (8089)
Since this is correctly marked as “Editorial” are there any objections to
changing the state to “Hold For Document Update”?
spt
> On Aug 23, 2024, at 18:18, Eric Rescorla wrote:
>
> I don't think this is an erratum. I agree it would be better, but I don't
> think that rises to "error".
>
> -Ekr
>
>
> On Fri, Aug 23, 2024 at 11:17 AM Rebecca VanRheenen
> wrote:
> Hi Paul,
>
> We are unable to verify this erratum that the submitter marked as editorial,
> so we changed the Type to “Technical”. As Stream Approver, please review and
> set the Status and Type accordingly (see the definitions at
> https://www.rfc-editor.org/errata-definitions/).
>
> Notes:
> * RFC 6347 has been obsoleted by RFC 9147. We see similar blocks of code in
> Section 5.2 and Appendix A.2 of RFC 9147.
> * For information about errata on obsolete RFCs, see #7 in the IESG Statement
> on "IESG Processing of RFC Errata for the IETF Stream”
> (https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/).
>
> You may review the report at:
> https://www.rfc-editor.org/errata/eid8089
>
> Information on how to verify errata reports can be found at:
> https://www.rfc-editor.org/how-to-verify/
>
> Further information on errata can be found at:
> https://www.rfc-editor.org/errata.php
>
> Best regards,
> RFC Editor/rv
>
>
> > On Aug 23, 2024, at 6:26 AM, RFC Errata System
> > wrote:
> >
> > The following errata report has been submitted for RFC6347,
> > "Datagram Transport Layer Security Version 1.2".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid8089
> >
> > --
> > Type: Editorial
> > Reported by: Kamil Milewski
> >
> > Section: 4.2.2
> >
> > Original Text
> > -
> > struct {
> > HandshakeType msg_type;
> > uint24 length;
> > uint16 message_seq; // New field
> > uint24 fragment_offset; // New field
> > uint24 fragment_length; // New field
> > select (HandshakeType) {
> > case hello_request: HelloRequest;
> > case client_hello: ClientHello;
> > case hello_verify_request: HelloVerifyRequest; // New type
> > case server_hello: ServerHello;
> > case certificate:Certificate;
> > case server_key_exchange: ServerKeyExchange;
> > case certificate_request: CertificateRequest;
> > case server_hello_done:ServerHelloDone;
> > case certificate_verify: CertificateVerify;
> > case client_key_exchange: ClientKeyExchange;
> > case finished: Finished;
> > } body;
> > } Handshake;
> >
> > Corrected Text
> > --
> > struct {
> > HandshakeType msg_type;
> > uint24 length;
> > uint16 message_seq; // New field
> > uint24 fragment_offset; // New field
> > uint24 fragment_length; // New field
> > select (HandshakeType) {
> > case hello_request: HelloRequest;
> > case client_hello: ClientHello;
> > case server_hello: ServerHello;
> > case hello_verify_request: HelloVerifyRequest; // New field
> > case certificate:Certificate;
> > case server_key_exchange: ServerKeyExchange;
> > case certificate_request: CertificateRequest;
> > case server_hello_done:ServerHelloDone;
> > case certificate_verify: CertificateVerify;
> > case client_key_exchange: ClientKeyExchange;
> > case finished: Finished;
> > } body; } Handshake;
> >
> > Notes
> > -
> > Change the order of cases inside select field to keep it:
> > 1. In ascending order
> > 2. Consistent with the structure in 4.3.2
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > will log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC6347 (draft-ietf-tls-rfc4347-bis-06)
> > --
> > Title : Datagram Transport Layer Security Version 1.2
> > Publication Date: January 2012
> > Author(s) : E. Rescorla, N. Modadugu
> > Category: PROPOSED STANDARD
> > Source : Transport Layer Security
> > Stream : IETF
> > Verifying Party : IESG
> >
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] FATT Process
Hi Rich, Starting a new subject to separate discussions on the FATT. Please understand that we are working though defining the process here. The current structure of the FATT does not allow for direct attribution of FATT feedback to specific individuals. Perhaps we may be able to adjust this in the future, but this is as it stands now. Your point that "this is not the IETF way" has been heard, and we are working on a fix but it would be more helpful to have specifics about how we can improve and what is missing in the current process. Here are some of the main points I was able to parse from your message below that are specific that we can work on improving: - the summary of the FATT feedback is hard to follow. - no estimate of how much work the analysis will be Are there others that I missed? We owe the working group a revised definition of the current process which we will provide soon. Thanks, Joe On Mon, Aug 26, 2024 at 7:13 AM Salz, Rich wrote: > ➢ All of it was posted to the list in May: > ➢ https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/ > > Quoting that message: “Here is a summary across all participants:” It is > not the messages and discussion. > > Further, that summary is inconsistent and hard to follow: > >*Does the change merit an updated analysis?* > >I think so > >The main question to ask, other than whether this extension breaks prior >analyses, is what are the new guarantees it provides: that will indeed >require new analysis. > >I see much more need for analysis when it comes to the authentication >properties of the PSK (psk/cert combination), whereas the secrecy > (assuming >authentication is a non-goal) is much more straightforward. > >I agree with the above. > > Let's number those responses one through four. Were they four different > people? Are two and three from the same person? What is the "above" that > number four agrees with? > > Further, as I recently noted, a stated goal of the panel was to provide a > level of estimate of the amount of work required. The only response in the > summary was "seems feasible." > > By convention within the IETF, WGChairs are not supposed to weigh in *as > Chairs* on technical matters. (Recall EKR stepped down as Chair to work on > TLS 1.3.) Looking at the description in the not-really-current, > but-still-mostly-correct, RFC about this, > https://www.rfc-editor.org/rfc/rfc2418.html#page-16 there is *no mention* > of Chairs providing technical expertise. > > We consider an "anononymity set" a useful thing for TLS ECH, > privacy-preserving measurement, and so on. It is *not* appropriate here. > That's what this panel is, despite (almost?) everyone in the WG who > commented saying that they don't like it. A point to which the chairs neve > directly responded. > > "I was talking to more than one cryptographer at CRYPTO this week who have > sworn off all participation in the IETF after the curve flamewares in the > past, etc". And how many of them are on the triage panel? And what curve > wars, the ones that happened in CFRG? And what is etc? And really, > academia is better? > > I agree that IETF behavior has driven away people who could make useful > contributions. That is sad. Maybe we'll continue to improve our behavior > enough that they will come back. The trade-off, having feedback filtered > through the WG chairs, mixed in with other feedback, is not worth the > perversion of the IETF open policies and procedures. Perhaps teach them how > to contribute with a not-obvious email, "pskbrea...@protonmail.com" or > some such. > > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FATT Process
Hi Joe, On 9/4/24 17:23, Joseph Salowey wrote: The current structure of the FATT does not allow for direct attribution of FATT feedback to specific individuals. That "does not allow" seems odd to me. Say if all reviewers are fine with being accountable in the usual IETF manner, are you saying they still could not be identified? If so, something's broken with that process. Ta, S. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FATT Process
On Wed, Sep 4, 2024 at 9:45 AM Stephen Farrell wrote: > > Hi Joe, > > On 9/4/24 17:23, Joseph Salowey wrote: > > The > > current structure of the FATT does not allow for direct attribution of > FATT > > feedback to specific individuals. > > That "does not allow" seems odd to me. Say if all reviewers are fine > with being accountable in the usual IETF manner, are you saying they > still could not be identified? If so, something's broken with that > process. > > [Joe] As you say if all the reviewers are fine with being identified then they could be identified in the usual manner. That is not the situation we are in right now. > Ta, > S. > > > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FATT Process
* [Joe] As you say if all the reviewers are fine with being identified then they could be identified in the usual manner. That is not the situation we are in right now. You might want to remind the reviewers not to publish their reviews by themselves, as it could expose those who didn’t publish :) If the anonymity set gets down to one or two, that’s not helpful to those people. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FATT Process
On 9/4/24 18:03, Joseph Salowey wrote: [Joe] As you say if all the reviewers are fine with being identified then they could be identified in the usual manner. That is not the situation we are in right now. Perhaps fixing that would be a good next step then? I.e. maybe try see if a panel can be filled who'd be comfortable having their reviews made accountable? Seems like that'd be the easiest fix, if it's possible. And if it's really not, then perhaps the entire panel idea needs a more fundamental revisit. Cheers, S. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FATT Process
* Starting a new subject to separate discussions on the FATT. That’s sensible, thanks for doing this. Let me try to answer your question this way. Here is how I view the timeline: 1. Chairs proposed a review panel 2. WG commented (my summary: consensus in favor of more analysis, disagreed with some of the specifics) 3. Chairs published panel, no acknowledgement of the feedback, no changes made 4. Summary report of analysis given If anyone disagrees with this, please let me know. Ideally with URLs pointing to messages/changes that I am forgetting. If we take the above outline as correct, then what must happen is what I’ve said before: start over. Make sure to listen and acknowledge the WG feedback and act on it. * Please understand that we are working though defining the process here. The current structure of the FATT does not allow for direct attribution of FATT feedback to specific individuals. Perhaps we may be able to adjust this in the future, but this is as it stands now. Sure. To me that means it must get thrown out. * it would be more helpful to have specifics about how we can improve and what is missing in the current process. In addition to the above… * How does the WG incent people to do analyses that the WG wants? * How long would the WG be willing to hold up an optional feature? * A core feature? * Will there be consensus calls on the final process document? If not, there really should be a good explanation of why not. * We owe the working group a revised definition of the current process which we will provide soon. Looking forward to it. Seriously. Hope this helps. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FATT Process
On Wed, Sep 4, 2024 at 10:08 AM Joseph Salowey wrote: > > > > On Wed, Sep 4, 2024 at 9:45 AM Stephen Farrell > wrote: >> >> >> Hi Joe, >> >> On 9/4/24 17:23, Joseph Salowey wrote: >> > The >> > current structure of the FATT does not allow for direct attribution of FATT >> > feedback to specific individuals. >> >> That "does not allow" seems odd to me. Say if all reviewers are fine >> with being accountable in the usual IETF manner, are you saying they >> still could not be identified? If so, something's broken with that >> process. >> > [Joe] As you say if all the reviewers are fine with being identified then > they could be identified in the usual manner. That is not the situation we > are in right now. Because of a massive disaster that some people decided we needed to engage in out of a combination of (what in my admittedly biased view) was equal measures optimism, and a heubristic desire to do something we aren't good at to displace NIST from a perceived role it doesn't actually have, we antagonized a lot of people needlessly. A decade later and we still haven't been able to move past it. And just to make explicit: this working group decided to ask CFRG to do something that wasn't going to go well, and the results were worse than anticipated. Unless we acknowledge that we're not going to be able to come up with fixes. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-04.txt
Hi, We submitted a new version based on the comments received at IETF 119. https://mailarchive.ietf.org/arch/msg/tls/SuKV6R_Xc7QlrHstqE-espDOWpE/ https://mailarchive.ietf.org/arch/msg/tls/_YPAmOnqSPpw9wGDNokTpY9CepQ/ The technical conclusions were that larger records than 2^16 should be supported. This means that the records will not look like TLS 1.2 records anyway and that the fixed fields opaque_type and legacy_record_version are not needed. The new version makes these changes. The extension now works very similar to RFC 8449 but allows endpoints to negotiate a maximum inner plaintext size up to 2^32 - 256 bytes , while reducing overhead. The current suggestion is to let the size of the length field be uint16, uint24, or uint32 depending on the negotiated maximum inner plaintext. This minimizes overhead and allows inner plaintexts up to 2^16 - 256 bytes can be supported with 3 bytes less overhead than before. Cheers, John -- Abstract: TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type, and have a 3-byte overhead due to the fixed fields opaque_type and legacy_record_version. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^32 - 256 bytes, while reducing overhead. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-04.html A diff from the version 02 is available at: https://author-tools.ietf.org/iddiff?url1=draft-mattsson-tls-super-jumbo-record-limit-02&url2=draft-mattsson-tls-super-jumbo-record-limit-04&difftype=--html ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
