[TLS] Re: Changing WG Mail List Reputation
> On Nov 3, 2024, at 4:31 PM, Joseph Salowey wrote: > > > Sent from my iPad > >> On Oct 25, 2024, at 3:03 PM, Viktor Dukhovni wrote: >> >> On Fri, Oct 25, 2024 at 08:30:45AM -0400, Sean Turner wrote: >> >>> The TLS list is infamous in that it is regarded by some as [insert >>> your descriptive word; where the chairs have heard the following words >>> used: noxious, toxic, unwelcoming, and rude]. The chairs want to >>> change this reputation and we hope you do too. A big part of this is >>> on the chairs to be be more proactive about moderating behavior that >>> goes against IETF WG procedures, code of conduct, etc. The chairs are >>> also going to send a monthly reminder, which is included below, that >>> will serve to remind everyone from those who joined just today to >>> those who joined many, many years ago of the policies and procedures >>> that apply to IETF mailing lists. >> >> One of the ways in which this WG is sometimes unwelcoming is not covered >> by the called out unprofessional behaviour. Rather, this list at times >> appears to be dominated by a single browser-centric world-view, and a >> dominant set of entrenched participants. Perspectives from less >> dominant sectors of the TLS user community may not always receive due >> consideration. >> >> I did not see being open to a broader set of perspectives on the list of >> goals. It was just the usual set of blatant violations of social norms. >> > > Hi Viktor, > > While there is overlap between professional behavior and the perceived focus > on browser specific use cases; I think we should try to separate out the > topic. > We should make sure that different perspectives are welcome and heard on the > list, however it will not always be the case that we will have consensus to > move the discussion forward on a particular topic, which will limit continued > discussion of that topic. For topics that are not broadly applicable to main > TLS use cases there may be more appropriate groups such as UTA or EMU. This > is probably something we can address better in the TLS WG FAQ [1]. > > [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md Hi! We have updated the TLS WG FAQ: https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md Feel free to comment on the wiki. Note that we are going to send two monthly reminders; one about mail list procedures and one about the FAQ. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Reminder: FAQ
Hi! Did you know the TLS WG has a FAQ? Well, we do; see [0]. Please consult it before: • Bringing new work to the WG • Registering Speciation Required code points for extensions, cipher suites, exporter labels, etc. • Requesting agenda time Also, please note that you too can submit FAQ entries for review. Thanks, The Chairs [0] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: Disallowing reuse of ephemeral keys
I strongly prefer 3. In the ML-KEM spec, the consistency checks on the public keys are marked as optional, so I think it would be a fair interpretation of FIPS 140-3 that the required consistency checks consist of the optionally allowed empty set in the case of ML-KEM. On Mon, Jan 13, 2025 at 7:11 PM Viktor Dukhovni wrote: > On Mon, Dec 16, 2024 at 07:02:43AM -0800, Eric Rescorla wrote: > > > Thanks. It seems like that would imply that Web clients cannot safely > > enforce a non-reuse requirement even if we had one. > > > > Do you plan to reuse ML-KEM keys as well? The situation seems to be > > different because, as Scott observes, it's the client who reaps the > benefit. > > It may be worth noting that FIPS 140-3 requires pairwise consistency > tests (PCTs) on generated (and imported) KEM keys before first use, with > no exception carved out for single-use keys. This factor of 2 or so > performance hit[1] on single-use keys does create a temptation to amortise > the cost by reusing the key a number of times (for a short time). > > Haven't taken any steps in that direction at this time. > > -- > Viktor. > > [1] Instead of keygen + decap, the single use cost becomes keygen + > encap + decap + decap. Whether this is more or less than a 2x > performance hit depends on implementation details. > > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
On 14/01/2025 18:48, Filippo Valsorda wrote: Two participants sending a dozen emails in support of solution A, and six participants sending one email each in support of solution B can look a lot like there is no consensus, or that there is consensus for solution A, especially if not all objections to solution B are painstakingly addressed. This is slightly adjacent to the point you were making, but I think there's an implicit assumption here which is different from 'rough consensus' as I understand it. RFC 2418 [1] lays out: In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) [...] Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. RFC 7282 [2], perhaps more an ideal rather than any actual description of IETF practice, explores the last part further in the sections: "One hundred people for and five people against might not be rough consensus" and "Five people for and one hundred people against might still be rough consensus". I know at least a few implementers that don't engage with the IETF because they don't have time for all that. Coming back to your main point, I agree this is a real problem. I don't know how it can be effectively addressed for when folks want to change the core Internet protocols which are stewarded by the IETF. However, I think many of the folks who are put off contributing are instead trying to bring their new ideas and designs to a wider community, rather than tinker with existing systems. The IETF could do a much better job of helping them share their work with the community by supporting and sign-posting lower process methods for publishing specs (e.g. informational) which produce similarly useful outputs (IMO) but don't incur the same overhead and drama on the mailing lists. Best, Dennis [1] https://datatracker.ietf.org/doc/rfc2418/ [2] https://datatracker.ietf.org/doc/rfc7282/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
It appears that Bob Beck said: > > >> On Jan 14, 2025, at 12:20 PM, Dang, Quynh H. (Fed) >> wrote: >> >> Maybe consensus calls can only be made and completed at the in-person >> meetings ? > >The problem with in-person (or even virtual at the in-person meetings) is it >then becomes even more of a pay-to-play proposition to participate. > >Not all valuable participants have an organization funding their participation >at IETF. I believe we still want to encourage such participation, not >discourage it. The IETF offers no-question fee waivers for remote meeting registrants. If you feel you can't pay, you can get a waiver: https://www.ietf.org/meeting/registration-fee-waivers/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
On Tue, Jan 14, 2025 at 11:44 AM Dennis Jackson wrote: > On 14/01/2025 18:48, Filippo Valsorda wrote: > > Two participants sending a dozen emails in support of solution A, and six > participants sending one email each in support of solution B can look a lot > like there is no consensus, or that there is consensus for solution A, > especially if not all objections to solution B are painstakingly addressed. > > I've certainly seen this before. Generally if the chairs are doing a good job they will not just count mail messages. With that said, I'm also not sure that in a WG of a hundred people 6 in favor and 2 against is really rough consensus. > This is slightly adjacent to the point you were making, but I think > there's an implicit assumption here which is different from 'rough > consensus' as I understand it. RFC 2418 [1] lays out: > > In general, the dominant view of the working group shall prevail. > (However, it must be noted that "dominance" is not to be determined on the > basis of volume or persistence, > but rather a more general sense of agreement.) > [...] > Note that 51% of the working group does not qualify as "rough consensus" and > 99% is better than rough. > > RFC 7282 [2], perhaps more an ideal rather than any actual description of > IETF practice, explores the last part further in the sections: "One > hundred people for and five people against might not be rough consensus" > and "Five people for and one hundred people against might still be rough > consensus". > Note that 7282 is an Informational document and doesn't have any normative force. Absent some edge case like sock puppets, I find it hard to believe either of these scenarios. -Ekr ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
On Tue, Jan 14, 2025, 10:49 AM Filippo Valsorda wrote: > 2024-10-25 14:30 GMT+02:00 Sean Turner : > > • Repetition of arguments without providing substantive new information > • Requesting an unreasonable amount of work to provide information > > > Personally, the reason I find the list (and generally the IETF) > unwelcoming is that arguments can easily prevail by attrition. Some > participants have the time and determination to reply to every email, > nitpick every argument, systematically reiterate their position, attack > other's positions and motivations, and demand explanation of every > assertion, while others don't. > > I know at least a few implementers that don't engage with the IETF because > they don't have time for all that. Myself I go months without opening the > list inbox because I know engaging is a tiny campaign every time. > > Two participants sending a dozen emails in support of solution A, and six > participants sending one email each in support of solution B can look a lot > like there is no consensus, or that there is consensus for solution A, > especially if not all objections to solution B are painstakingly addressed. > Having been in the position of defending solution A on another list (and good thing I did: the AD ultimately said we needed the change) I think there's more to be said here. Just sending support for B and shutting up doesn't really advance a consensus process or engage with the technical discussions. In the extreme its throwing the wheel out the car window when playing chicken. Its particularly bad if it's a few major implementations who are pushing something that doesn't take into account the interests of other participants without the same constraints. This is where some of our most contentious discussions happen, and that's not really a solveable problem without changing what rough consensus means. > I think this is what these two points in the reminder are getting at, but > I am curious how moderating such behavior would look like, because every > individual instance can be defended by arguing (probably at length!) that > actually there is new information in each post, or that the amount of work > being demanded is perfectly appropriate. > > I want to acknowledge this is a common and difficult problem to solve. > Famously, Wikipedia suffers from the same pathology. Maybe it's just the > downside of open forums and it should be accepted, but if the goal is > improving the reputation of the list, I feel there needs to be willingness > to engage these behaviors, which will not make everyone happy. > ___ > 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] I-D Action: draft-ietf-tls-hybrid-design-12.txt
Internet-Draft draft-ietf-tls-hybrid-design-12.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Hybrid key exchange in TLS 1.3 Authors: Douglas Stebila Scott Fluhrer Shay Gueron Name:draft-ietf-tls-hybrid-design-12.txt Pages: 24 Dates: 2025-01-14 Abstract: Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-12.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-12 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
Hi all, It is sad to know that many people would like to join in the discussions but decide not to do so because of their anticipation of the pain they would get and the time they would need to spend. There are ways to help the situation. For example, the chairs could decide to say that 80% agree on something is defined to have the consensus. The chairs can open a thread to discuss a technical matter then at some point the chairs make a consensus call: yes/no ( reasons not required because it has been discussed already). One of the things I am concerned about this method is that every email has a vote. Maybe consensus calls can only be made and completed at the in-person meetings ? Regards, Quynh. From: Filippo Valsorda Sent: Tuesday, January 14, 2025 1:48 PM To: tls@ietf.org Subject: [TLS] Re: Changing WG Mail List Reputation 2024-10-25 14:30 GMT+02:00 Sean Turner mailto:s...@sn3rd.com>>: • Repetition of arguments without providing substantive new information • Requesting an unreasonable amount of work to provide information Personally, the reason I find the list (and generally the IETF) unwelcoming is that arguments can easily prevail by attrition. Some participants have the time and determination to reply to every email, nitpick every argument, systematically reiterate their position, attack other's positions and motivations, and demand explanation of every assertion, while others don't. I know at least a few implementers that don't engage with the IETF because they don't have time for all that. Myself I go months without opening the list inbox because I know engaging is a tiny campaign every time. Two participants sending a dozen emails in support of solution A, and six participants sending one email each in support of solution B can look a lot like there is no consensus, or that there is consensus for solution A, especially if not all objections to solution B are painstakingly addressed. I think this is what these two points in the reminder are getting at, but I am curious how moderating such behavior would look like, because every individual instance can be defended by arguing (probably at length!) that actually there is new information in each post, or that the amount of work being demanded is perfectly appropriate. I want to acknowledge this is a common and difficult problem to solve. Famously, Wikipedia suffers from the same pathology. Maybe it's just the downside of open forums and it should be accepted, but if the goal is improving the reputation of the list, I feel there needs to be willingness to engage these behaviors, which will not make everyone happy. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
> On Jan 14, 2025, at 12:20 PM, Dang, Quynh H. (Fed) > wrote: > > Maybe consensus calls can only be made and completed at the in-person > meetings ? The problem with in-person (or even virtual at the in-person meetings) is it then becomes even more of a pay-to-play proposition to participate. Not all valuable participants have an organization funding their participation at IETF. I believe we still want to encourage such participation, not discourage it. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
2024-10-25 14:30 GMT+02:00 Sean Turner : > • Repetition of arguments without providing substantive new information > • Requesting an unreasonable amount of work to provide information Personally, the reason I find the list (and generally the IETF) unwelcoming is that arguments can easily prevail by attrition. Some participants have the time and determination to reply to every email, nitpick every argument, systematically reiterate their position, attack other's positions and motivations, and demand explanation of every assertion, while others don't. I know at least a few implementers that don't engage with the IETF because they don't have time for all that. Myself I go months without opening the list inbox because I know engaging is a tiny campaign every time. Two participants sending a dozen emails in support of solution A, and six participants sending one email each in support of solution B can look a lot like there is no consensus, or that there is consensus for solution A, especially if not all objections to solution B are painstakingly addressed. I think this is what these two points in the reminder are getting at, but I am curious how moderating such behavior would look like, because every individual instance can be defended by arguing (probably at length!) that actually there is new information in each post, or that the amount of work being demanded is perfectly appropriate. I want to acknowledge this is a common and difficult problem to solve. Famously, Wikipedia suffers from the same pathology. Maybe it's just the downside of open forums and it should be accepted, but if the goal is improving the reputation of the list, I feel there needs to be willingness to engage these behaviors, which will not make everyone happy.___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
Dang, Quynh H. (Fed) writes: >Maybe consensus calls can only be made and completed at the in-person >meetings ? Ugh, that would make the existing situation where a lot of important decisions are made at in-person meetings and then presented as a fait accomplis to the list even worse, only big players who can afford to stack the room would get to have any say. Peter. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
Moreover, it means that someone who is not available at the time of the meeting for whatever reason even if it’s not money (for example, they have a conflict with another wg) is now excluded. There is a good reason why we do consensus on mailing lists. If participants are engaging in dos attacks you can always ask on the mailing list for the equivalent of a hum, just as we do in meetings. Op wo 15 jan 2025 om 05:00 schreef Peter Gutmann > Dang, Quynh H. (Fed) writes: > > >Maybe consensus calls can only be made and completed at the in-person > >meetings ? > > Ugh, that would make the existing situation where a lot of important > decisions > are made at in-person meetings and then presented as a fait accomplis to > the > list even worse, only big players who can afford to stack the room would > get > to have any say. > > Peter. > > ___ > 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
