[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
The current triage panel is not anonymous, and the feedback they gave on RFC8773bis included the complete input from all current members. Post it. All of it. To the WG mailing list. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Consensus Call: -rfc8446bis PRs #1360
Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that addresses an Issue submitted by Stephen; links to both follow: Issue: https://github.com/tlswg/tls13-spec/issues/1359 PR: https://github.com/tlswg/tls13-spec/pull/1360 As this has been suggested post WGLC, we need to ensure we have consensus to merge this PR. We did spend some time on this (and other -rfc8446bis) PRs at IETF 120. At the session, we did a poll to 1st determine whether it is appropriate to make this change in this I-D, which was supposed to be just for clarifications. The result of the poll was to not make this change. To verify this, please review the PR in its entirety and indicate whether you support not merging this PR by 9 September 23:59 UTC. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
All of it was posted to the list in May: https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/ On Mon, Aug 26, 2024, 9:22 AM Salz, Rich wrote: > The current triage panel is not anonymous, and the feedback they gave > on RFC8773bis included the complete input from all current members. > > > > Post it. All of it. To the WG mailing list. > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
I support *not* making Curve 25519 MTI in TLS 1.3. Cheers, Andrei -Original Message- From: Sean Turner Sent: Monday, August 26, 2024 6:23 AM To: TLS List Subject: [EXTERNAL] [TLS]Consensus Call: -rfc8446bis PRs #1360 Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that addresses an Issue submitted by Stephen; links to both follow: Issue: https://github.com/tlswg/tls13-spec/issues/1359 PR: https://github.com/tlswg/tls13-spec/pull/1360 As this has been suggested post WGLC, we need to ensure we have consensus to merge this PR. We did spend some time on this (and other -rfc8446bis) PRs at IETF 120. At the session, we did a poll to 1st determine whether it is appropriate to make this change in this I-D, which was supposed to be just for clarifications. The result of the poll was to not make this change. To verify this, please review the PR in its entirety and indicate whether you support not merging this PR by 9 September 23:59 UTC. Cheers, spt ___ 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: Consensus Call: -rfc8446bis PRs #1360
Please do not merge. Russ > On Aug 26, 2024, at 9:23 AM, Sean Turner wrote: > > Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that > addresses an Issue submitted by Stephen; links to both follow: > Issue: https://github.com/tlswg/tls13-spec/issues/1359 > PR: https://github.com/tlswg/tls13-spec/pull/1360 > > As this has been suggested post WGLC, we need to ensure we have consensus to > merge this PR. We did spend some time on this (and other -rfc8446bis) PRs at > IETF 120. At the session, we did a poll to 1st determine whether it is > appropriate to make this change in this I-D, which > was supposed to be just for clarifications. The result of the poll was to not > make this change. To verify this, please review the PR in its entirety and > indicate whether you support not merging this PR by 9 September 23:59 UTC. > > Cheers, > spt > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
Andrei Popov writes: >I support *not* making Curve 25519 MTI in TLS 1.3. Same here, there's already enough new stuff required by 1.3 without adding even more. Peter. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
Let's try to disentangle two questions: Unfortunately, the Chairs keep entangling the questions. Look at the message at the start of this thread, which clearly gives the panel summary as justification. Rather, it turns on whether you think that this is a significant enough change with unclear enough properties that we should develop higher confidence before advancing it at PS. Is your position that that's not the case? I am not answering your question, nor stating my opinion. I am opposed because the IETF core principles are being repeatedly violated, especially in view of expressed WG concerns about that. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
➢ 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]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
I am also opposed to the merge. 8446bis changes are editorial and clarifications, not semantic ones. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
My feelings exactly match Rich's here. On Mon, Aug 26, 2024 at 10:15 AM Salz, Rich wrote: > I am also opposed to the merge. 8446bis changes are editorial and > clarifications, not semantic ones. > > > ___ > 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: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
I also support *not* making Curve 25519 MTI. On Mon, Aug 26, 2024 at 10:18 AM Richard Barnes wrote: > My feelings exactly match Rich's here. > > On Mon, Aug 26, 2024 at 10:15 AM Salz, Rich 40akamai@dmarc.ietf.org> wrote: > >> I am also opposed to the merge. 8446bis changes are editorial and >> clarifications, not semantic ones. >> >> >> ___ >> 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 mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
WRT the draft, yes I think more formal analysis is likely warranted. WRT Rich's complaint: I think the chairs would be wise to try to explicitly address the points he makes and that were raised at the IETF-120 session. I got the distinct impression that a bunch of active WG participants were not happy with the state of the triage panel thing, and also the distinct impression that the chairs weren't quite grokking that. (It can be hard to pickup the overall message from the front of the room sometimes.) My take on the panel is roughly: yes, I don't get why there seems no desire to collaborate with ufmrg (but I'm biased there:-), and I also think that the anonymity thing means we shouldn't take panel comments as seriously as ones made in public - but there is nothing preventing the chairs from encouraging panel members to just copy the list with their comments as the norm and handle any situation where someone can't do that as an exception. (I've also, as a sorta-bogus member of the the CFRG crypto panel, seen some issues with people taking CFRG crypto panel output more seriously than sometimes warranted - many of those reviews are very good, but not all are equal, and those reviews are not as directly affecting the IETF standards process, so what's ok there may not be ok here.) 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: Consensus call for RFC8773bis Formal Analysis Requirement
I vote for Option 1: Let's see if/how this changes existing proofs before we move to standards track. From a quick look, it doesn't seem like implementing this extension should cause anyone trouble, but we might as well be sure. Chris P. On Mon, Aug 26, 2024 at 3:46 PM Stephen Farrell wrote: > > WRT the draft, yes I think more formal analysis is likely > warranted. > > WRT Rich's complaint: I think the chairs would be wise to try > to explicitly address the points he makes and that were raised > at the IETF-120 session. I got the distinct impression that > a bunch of active WG participants were not happy with the state > of the triage panel thing, and also the distinct impression > that the chairs weren't quite grokking that. (It can be hard to > pickup the overall message from the front of the room sometimes.) > > My take on the panel is roughly: yes, I don't get why there seems > no desire to collaborate with ufmrg (but I'm biased there:-), and > I also think that the anonymity thing means we shouldn't take > panel comments as seriously as ones made in public - but there > is nothing preventing the chairs from encouraging panel members to > just copy the list with their comments as the norm and handle any > situation where someone can't do that as an exception. (I've also, > as a sorta-bogus member of the the CFRG crypto panel, seen some > issues with people taking CFRG crypto panel output more seriously > than sometimes warranted - many of those reviews are very good, > but not all are equal, and those reviews are not as directly > affecting the IETF standards process, so what's ok there may not > be ok here.) > > Cheers, > S. > > ___ > 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
