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 <rsalz= 40akamai....@dmarc.ietf.org> 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
