I appreciate this answer, thank you
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday 7 December 2018 23:48, Sean Turner <s...@sn3rd.com> wrote: > There is no WG consensus to adopt this draft as no WG adoption call has been > made. draft-dkg-tls-reject-static-dh is an individual draft that is currently > being discussed on this list; in much the same way > draft-green-tls-static-dh-in-tls13 and draft-rhrd-tls-tls13-visibility were > individual drafts that were discussed on this list; there was no WG consensus > to adopt draft-rhrd-tls-tls13-visibility and there was never a call to adopt > draft-green-tls-static-dh-in-tls13. > > The chairs have been debating whether draft-dkg-tls-reject-static-dh is in > scope or whether the discussion should be moved elsewhere. Parts of this > draft we believe are in scope, e.g., providing guidance on handling key share > re-use and pitfalls for not following this guidance. (Note that how to handle > key share re-use is not the same thing as explicitly prohibiting re-use of > keys.) Other parts of the draft contain material for which we did not reach > consensus to address, such as Section 3.3 on prohibiting key-share reuse. We > are not the protocol police and have recently gotten out of that business, > e.g., by removing barriers for cipher suite code points. We do not want to > get back in that business. > > In order to ensure a focused discussion and avoid rehashing the previous > debate regarding draft-rhrd-tls-tls13-visibility, parts of this draft should > be rescoped or removed. Authors are free to take this material to an AD and > seek sponsorship, or to the ISE/IAB for further guidance. > > Cheers, > Joe, Chris, and Sean > > > On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF > > Arnaud.Taddei.IETF=40protonmail....@dmarc.ietf.org wrote: > > I am really surprised how the answers you don't like are systematically put > > on denial. Can you explain me what leads you to think that some people here > > are not concerned by the list of people you list? this is an assumption and > > the wrong assumption. > > Perhaps on the contrary we are concerned BOTH by what these people endure > > but too by what other consistencies are basically removed rights to defend > > themselves. > > As to the marketing aspect frankly this is an invention here and again I > > don't see what allows you to paint the answers you don't like because you > > don't like. > > So I could on the contrary hightight the dogmatism that reins here, with a > > smell of intimidation, and to some degree the sectarianism back to the > > latin roots of the word > > Regarding Human Rights, we DO care about Human Rights too and fact is that > > I had the chance to make more progress in 2 hours than I did in 2 years at > > IET and I had the chance to contribute to a magic moment with a Chinese > > Organization to comply a technical solution to Human Rights requirements. > > You know why? Because we took the time to TALK properly to each other, > > understand each other, learn from each other with no intimidation and no > > wrong assumptions that 'because we LOOK to be on the wrong side' we are > > foolish people, and respect to the fact that not everyone speaks and writes > > a proper English and sometimes words are dangerous when we don't know > > exactly the semantics in the right context > > The assumption that you are the only one who cares is tiresome. > > This group was offered a chance to control the development of a 360 degree > > solution for all parties and it was rejected. Fine. The ETSI took it and is > > taking its responsibly. > > I don't know what leads you to think that a model where security resides > > only on the 2 ends of the communication IS the answer to all the problems. > > The recent continuous scandals that are affecting a number of platforms and > > destroying trust, privacy and security is leading me to think about why > > should I trust this model. By analogy when I see how my body defends itself > > against bad stuff, it is using a battery of models, not one model. > > In any negotiation you can look for what is the right battle, and those who > > understand that point will know that the right battle (and the one which is > > harder for the opposition) is on providing guarantees. This would have been > > a better battle to pick and would have given a chance to work more > > collaboratively and not by confrontation. > > Now I don't understand what leads this group to try now to block the ETSI, > > can someone tell me and in particular the chairs if we have a consensus > > here? > > Finally I am calling on the chairs of this group. It was very interesting > > to observe the many comments at the last IETF103 about the vile and toxic > > atmosphere that prevails here. I have all my time to work in these > > conditions but perhaps the chair could try to think about a more positive > > atmosphere of work. > > A bon entendeur salut > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor > > d...@fifthhorseman.net wrote: > > > > > On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote: > > > > > > > > On Dec 5, 2018, at 7:33 PM, Stephen Farrell stephen.farr...@cs.tcd.ie > > > > > wrote: > > > > > > > > > > > On 05/12/2018 10:22, Bret Jordan wrote: > > > > > > I think we should be more open minded and look at the needs from a > > > > > > 360 degree deployment perspective. > > > > > > > > > > I think we should avoid marketing speak. > > > > > > > > This is not marketing speak. This is understanding how these solutions > > > > need to be deployed end to end in all of their scenarios from > > > > consumer, to small business, to enterprise, to service provider, to > > > > content provider, to telco, etc. > > > > > > Perhaps one of the reasons that this might across as marketing speak to > > > some people is that your list of "all their scenarios" appears to be > > > only business use cases (where the individual people involved are at > > > most consumers of business products). You haven't mentioned > > > journalists, disk jockeys, activists, flat earthers, dissidents, > > > students, medical professionals, juggalos, community organizers, gun > > > nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free > > > software developers, elected officials, religious minorities, senior > > > citizens, or any of the other non-business use cases that may depend on > > > TLS for confidentiality, integrity, authenticity, or any of the other > > > information security guarantees that are put at risk by proposals like > > > this. > > > One of the concerns the last time we danced this dance was that the > > > proposal claimed to be interested in one use case only: "the enterprise > > > data center", and yet offered no meaningful way to effectively limit its > > > (ab)use outside the data center. This objection was raised clearly, and > > > the proponents of the protocol change failed to address it. And now it > > > appears that instead of addressing the concern, they forum-shopped until > > > they found a place to publish the same approach without even > > > acknowledging the concern that this could have an impact beyond the data > > > center. > > > A full 360 degree view might acknowledge that doing harm to the core > > > priniciples of a security protocol that everyone relies on for the sake > > > of one particular use case out of many might not be an appropriate step > > > to take. (and that one use case might have other solutions, albeit > > > perhaps more expensive or inconveient ones for people who have already > > > made certain investments) > > > I'm pretty sure we don't want TLS to be all things to all people, right? > > > What are the core goals or guarantees of TLS that you would like to see > > > preserved? > > > --dkg > > > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
