[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

[Salz, Rich]

I am opposed. Anonymous email recommendations are not how the IETF operates.

Attached below is a note I wrote a month ago to the Chairs.  None of the points 
written there – and MOST of them were a summary of WG discussion – were 
addressed.



From: Rich Salz mailto:rs...@akamai.com>>
Date: Tuesday, July 30, 2024 at 1:49 PM
To: "tls-cha...@ietf.org" 
mailto:tls-cha...@ietf.org>>
Subject: Rethinking the formal analysis triage

TLS Chairs,

I wasn’t sure whether to send this to you or the entire WG. I let another 
person read this and they suggested the Chairs.  So here you go.

I re-read all the messages in the archive [1] and re-watched the 119 and 120 
segments on the triage panel.  I believe that, as currently set up, it is so 
flawed that it should be taken down and rebuilt from scratch.

After the idea was proposed in March, the two most common feedback suggestions 
were
• Collaborate with UFMRG
• Make all communications open and on the mailing list
Neither of these were done. In fact, there was no response from the Chairs on 
either point.

From the beginning, the stated intent was the that one thing the panel would 
provide is an estimate of how much work any suggested analysis would take. The 
one review that was done so far did not include that, other than “feasible.”

Many people have already commented that collating all responses is a bad idea. 
I want to add one point that I have not seen before: if a subset of the triage 
reviewers recommends analysis, the WG has no information about the 
qualifications of those making the recommendation and no way to evaluate how to 
accept it.

This brings up a related point. Anonymous evaluations are against the very 
nature of the IETF. How can we assess the value of someone’s contributions when 
we don’t know who they are? Will “Reviewer 1” always be the same person? If the 
entire panel did not do a review, are WG members expected to treat all members 
as equally competent and qualified?

The WG is strongly in favor of more formal analysis. The Chairs tried to do too 
much and failed. Start over, respond to the feedback you got from the WG, and 
pick something easier.

[1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage


___
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

[Bob Beck]

On Aug 25, 2024, at 13:56, Salz, Rich  wrote:








I am opposed. Anonymous email recommendations are not how the IETF operates.I would also count myself as opposed. While I understand and am sympathetic to a reviewer possibly not wanting to get deluged in email or opinions unrelated to the task at hand, I think if this is truly a problem it is symptomatic to participation in a working group as a whole and should be addressed across the board for everyone. Anonymous reviewers have a number of problems as Rich has pointed out. 
 
Attached below is a note I wrote a month ago to the Chairs.  None of the points written there – and MOST of them were a summary of WG discussion – were addressed.

 

 

From: Rich Salz 
Date: Tuesday, July 30, 2024 at 1:49 PM
To: "tls-cha...@ietf.org" 
Subject: Rethinking the formal analysis triage
 
TLS Chairs,
 
I wasn’t sure whether to send this to you or the entire WG. I let another person read this and they suggested the Chairs.  So here you go.
 
I re-read all the messages in the archive [1] and re-watched the 119 and 120 segments on the triage panel.  I believe that, as currently set up, it is so flawed that it should
 be taken down and rebuilt from scratch.
 
After the idea was proposed in March, the two most common feedback suggestions were
    • Collaborate with UFMRG
    • Make all communications open and on the mailing list
Neither of these were done. In fact, there was no response from the Chairs on either point.
 
From the beginning, the stated intent was the that one thing the panel would provide is an estimate of how much work any suggested analysis would take. The one review that
 was done so far did not include that, other than “feasible.”
 
Many people have already commented that collating all responses is a bad idea. I want to add one point that I have not seen before: if a subset of the triage reviewers recommends
 analysis, the WG has no information about the qualifications of those making the recommendation and no way to evaluate how to accept it.
 
This brings up a related point. Anonymous evaluations are against the very nature of the IETF. How can we assess the value of someone’s contributions when we don’t know who
 they are? Will “Reviewer 1” always be the same person? If the entire panel did not do a review, are WG members expected to treat all members as equally competent and qualified?
 
The WG is strongly in favor of more formal analysis. The Chairs tried to do too much and failed. Start over, respond to the feedback you got from the WG, and pick something
 easier.
 
[1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage
 
 




___TLS mailing list -- tls@ietf.orgTo 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

[Eric Rescorla]

Let's try to disentangle two questions:

1. Whether we should require this document to have some sort of formal
analysis prior to advancing
2. Whether the feedback from the triage panel should be handled in some
other way

I don't have a strong opinion on (2), but I don't see that the answer to
(1) turns on that. 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?

-Ekr


On Sun, Aug 25, 2024 at 12:56 PM Salz, Rich  wrote:

> I am opposed. Anonymous email recommendations are not how the IETF
> operates.
>
>
>
> Attached below is a note I wrote a month ago to the Chairs.  None of the
> points written there – and MOST of them were a summary of WG discussion –
> were addressed.
>
>
>
>
>
>
> * From: *Rich Salz 
> *Date: *Tuesday, July 30, 2024 at 1:49 PM
> *To: *"tls-cha...@ietf.org" 
> *Subject: *Rethinking the formal analysis triage
>
>
>
> TLS Chairs,
>
>
>
> I wasn’t sure whether to send this to you or the entire WG. I let another
> person read this and they suggested the Chairs.  So here you go.
>
>
>
> I re-read all the messages in the archive [1] and re-watched the 119 and
> 120 segments on the triage panel.  I believe that, as currently set up, it
> is so flawed that it should be taken down and rebuilt from scratch.
>
>
>
> After the idea was proposed in March, the two most common feedback
> suggestions were
>
> • Collaborate with UFMRG
>
> • Make all communications open and on the mailing list
>
> Neither of these were done. In fact, there was no response from the Chairs
> on either point.
>
>
>
> From the beginning, the stated intent was the that one thing the panel
> would provide is an estimate of how much work any suggested analysis would
> take. The one review that was done so far did not include that, other than
> “feasible.”
>
>
>
> Many people have already commented that collating all responses is a bad
> idea. I want to add one point that I have not seen before: if a subset of
> the triage reviewers recommends analysis, the WG has no information about
> the qualifications of those making the recommendation and no way to
> evaluate how to accept it.
>
>
>
> This brings up a related point. Anonymous evaluations are against the very
> nature of the IETF. How can we assess the value of someone’s contributions
> when we don’t know who they are? Will “Reviewer 1” always be the same
> person? If the entire panel did not do a review, are WG members expected to
> treat all members as equally competent and qualified?
>
>
>
> The WG is strongly in favor of more formal analysis. The Chairs tried to
> do too much and failed. Start over, respond to the feedback you got from
> the WG, and pick something easier.
>
>
>
> [1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage
>
>
>
>
> ___
> 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

[Deirdre Connolly]

>  Anonymous reviewers have a number of problems

The current triage panel is not anonymous, and the feedback they gave
on RFC8773bis included the complete input from all current members.

On Sun, Aug 25, 2024 at 4:51 PM Bob Beck  wrote:

>
>
> On Aug 25, 2024, at 13:56, Salz, Rich 
> wrote:
>
> 
>
> I am opposed. Anonymous email recommendations are not how the IETF
> operates.
>
>
> I would also count myself as opposed. While I understand and am
> sympathetic to a reviewer possibly not wanting to get deluged in email or
> opinions unrelated to the task at hand, I think if this is truly a problem
> it is symptomatic to participation in a working group as a whole and should
> be addressed across the board for everyone. Anonymous reviewers have a
> number of problems as Rich has pointed out.
>
>
>
> Attached below is a note I wrote a month ago to the Chairs.  None of the
> points written there – and MOST of them were a summary of WG discussion –
> were addressed.
>
>
>
>
>
>
> * From: *Rich Salz 
> *Date: *Tuesday, July 30, 2024 at 1:49 PM
> *To: *"tls-cha...@ietf.org" 
> *Subject: *Rethinking the formal analysis triage
>
>
>
> TLS Chairs,
>
>
>
> I wasn’t sure whether to send this to you or the entire WG. I let another
> person read this and they suggested the Chairs.  So here you go.
>
>
>
> I re-read all the messages in the archive [1] and re-watched the 119 and
> 120 segments on the triage panel.  I believe that, as currently set up, it
> is so flawed that it should be taken down and rebuilt from scratch.
>
>
>
> After the idea was proposed in March, the two most common feedback
> suggestions were
>
> • Collaborate with UFMRG
>
> • Make all communications open and on the mailing list
>
> Neither of these were done. In fact, there was no response from the Chairs
> on either point.
>
>
>
> From the beginning, the stated intent was the that one thing the panel
> would provide is an estimate of how much work any suggested analysis would
> take. The one review that was done so far did not include that, other than
> “feasible.”
>
>
>
> Many people have already commented that collating all responses is a bad
> idea. I want to add one point that I have not seen before: if a subset of
> the triage reviewers recommends analysis, the WG has no information about
> the qualifications of those making the recommendation and no way to
> evaluate how to accept it.
>
>
>
> This brings up a related point. Anonymous evaluations are against the very
> nature of the IETF. How can we assess the value of someone’s contributions
> when we don’t know who they are? Will “Reviewer 1” always be the same
> person? If the entire panel did not do a review, are WG members expected to
> treat all members as equally competent and qualified?
>
>
>
> The WG is strongly in favor of more formal analysis. The Chairs tried to
> do too much and failed. Start over, respond to the feedback you got from
> the WG, and pick something easier.
>
>
>
> [1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage
>
>
>
>
> ___
> 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

[Deirdre Connolly]

> I think if this is truly a problem it is symptomatic to participation in
a working group as a whole and should be addressed across the board for
everyone.

I agree that it is a problem and should be addressed across the IETF.
Unfortunately we keep making changes to TLS 1.3 in the meantime, so. 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

On Sun, Aug 25, 2024 at 4:51 PM Bob Beck  wrote:

>
>
> On Aug 25, 2024, at 13:56, Salz, Rich 
> wrote:
>
> 
>
> I am opposed. Anonymous email recommendations are not how the IETF
> operates.
>
>
> I would also count myself as opposed. While I understand and am
> sympathetic to a reviewer possibly not wanting to get deluged in email or
> opinions unrelated to the task at hand, I think if this is truly a problem
> it is symptomatic to participation in a working group as a whole and should
> be addressed across the board for everyone. Anonymous reviewers have a
> number of problems as Rich has pointed out.
>
>
>
> Attached below is a note I wrote a month ago to the Chairs.  None of the
> points written there – and MOST of them were a summary of WG discussion –
> were addressed.
>
>
>
>
>
>
> * From: *Rich Salz 
> *Date: *Tuesday, July 30, 2024 at 1:49 PM
> *To: *"tls-cha...@ietf.org" 
> *Subject: *Rethinking the formal analysis triage
>
>
>
> TLS Chairs,
>
>
>
> I wasn’t sure whether to send this to you or the entire WG. I let another
> person read this and they suggested the Chairs.  So here you go.
>
>
>
> I re-read all the messages in the archive [1] and re-watched the 119 and
> 120 segments on the triage panel.  I believe that, as currently set up, it
> is so flawed that it should be taken down and rebuilt from scratch.
>
>
>
> After the idea was proposed in March, the two most common feedback
> suggestions were
>
> • Collaborate with UFMRG
>
> • Make all communications open and on the mailing list
>
> Neither of these were done. In fact, there was no response from the Chairs
> on either point.
>
>
>
> From the beginning, the stated intent was the that one thing the panel
> would provide is an estimate of how much work any suggested analysis would
> take. The one review that was done so far did not include that, other than
> “feasible.”
>
>
>
> Many people have already commented that collating all responses is a bad
> idea. I want to add one point that I have not seen before: if a subset of
> the triage reviewers recommends analysis, the WG has no information about
> the qualifications of those making the recommendation and no way to
> evaluate how to accept it.
>
>
>
> This brings up a related point. Anonymous evaluations are against the very
> nature of the IETF. How can we assess the value of someone’s contributions
> when we don’t know who they are? Will “Reviewer 1” always be the same
> person? If the entire panel did not do a review, are WG members expected to
> treat all members as equally competent and qualified?
>
>
>
> The WG is strongly in favor of more formal analysis. The Chairs tried to
> do too much and failed. Start over, respond to the feedback you got from
> the WG, and pick something easier.
>
>
>
> [1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage
>
>
>
>
> ___
> 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

[Muhammad Usama Sardar]

I agree with Ekr that the two things should be kept separate. In 
addition, may I also suggest to keep this thread only for discussion 
about #1, please? In this thread, the chairs are asking a simple 
question, namely:


On 23.08.24 19:30, Joseph Salowey wrote:
Please respond to the list with a brief reason why you think the 
document requires formal analysis or not. 


For issues/recommendations about #2, please use the thread where the 
process was actually proposed.


Thanks,

Usama

On 25.08.24 22:54, Eric Rescorla wrote:

Let's try to disentangle two questions:

1. Whether we should require this document to have some sort of formal 
analysis prior to advancing
2. Whether the feedback from the triage panel should be handled in 
some other way


I don't have a strong opinion on (2), but I don't see that the answer 
to (1) turns on that. 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?


-Ekr



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org