Stephen Farrell wrote: > Hi, > > On 03/06/15 21:00, Tony Hain wrote: > > While I don't object to making the IETF content available via > > https/tls, > > That's been done for ages. This just makes it the default. Which does > require some minor changes. > > > this proposed statement reads as political knee-jerk BS that is both > > unnecessary and uncalled for. What the statement MUST focus on is > > 'data integrity', and SHOULD NOT stoop to fear mongering over > > 'privacy'. > > I have to say the above seems somewhat overstated. (Where my use of > "somewhat" is understatement:-) How is taking a position that technical accuracy of the IETF content is critical an overstatement? > > > "It is public data ..." For the very small subset that is truly > > restricted access, it is fine to acknowledge 'privacy' > > as a concern, but for the vast majority of the content in question, > > 'data integrity' is the only real concern. > > I would assert that the existence of the dprive WG is good evidence that the > IETF does not consider data-integrity as the only real concern for public > data. And I would assert that it shows a group-think knee-jerk overreaction to threats that hypothetically could be applied in broader contexts than history documents. We are both free to express our own assertions. > > I'd also note that there is no TLS ciphersuite that satisfies BCP195 and that > only provides data integrity. That very recent IETF consensus document says > one MUST NOT negotiate any of the ciphersuites with NULL encryption > (essentially outside of testing/debug). So what you appear to want this > statement to say would seem to be inconsistent with IETF consensus. I never argued FOR null encryption. My point was that 'privacy' is not a technical need in this case. It may come about as a side effect, but the proposed statement as written is not focused on the technical requirement of the IETF. It is instead a political statement that has no technical justification based on the needs of the community. To be clear, the technical need is data integrity. The implementation MAY provide privacy, and given current technologies likely will. Tony > > Cheers, > S. > > > > > > As such, I oppose the statement as written. Fix the tone and I will be > > a strong supporter. > > > > Tony > > > > > >> -----Original Message----- From: IETF-Announce > >> [mailto:ietf-announce-bounces@xxxxxxxx] On Behalf Of The IESG Sent: > >> Monday, June 01, 2015 9:44 AM To: IETF Announcement List Subject: > >> Proposed Statement on "HTTPS everywhere for the IETF" > >> > >> Hi All, > >> > >> The IESG are planning to agree an IESG statement on "HTTPS Everywhere > >> for the IETF," please see [1] for the current text. > >> > >> We are seeking community feedback on this and welcome assistance > from > >> the community in identifying any cases where a change or additional > >> guidance is needed to put this into effect. > >> > >> The IESG plans to finalise this statement just after IETF-93 in > >> Prague. > >> > >> * Please send general feedback intended for discussion to > >> ietf@xxxxxxxx > >> > >> * Comments about specific issues arising can be sent to iesg@xxxxxxxx > >> or tools-discuss@xxxxxxxx as appropriate (use iesg@xxxxxxxx if not > >> sure) > >> > >> Regards, Terry & Stephen (for the IESG) > >> > >> [1] > >> https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere > > > > > >