On Fri, Aug 26, 2011 at 1:12 PM, Ned Freed <ned.freed@xxxxxxxxxxx> wrote: >> It ensures that what you're getting is the same as what the IETF has >> on file, > > No, it really doesn't do that. There can be, and usually are, a lot of steps > involves besides the one https hop. > What other steps are there? HTTPS prevents what the web server sends from being tampered with on its way to the browser. If the web server storing the archives is itself trusted, this would seem to be all that is needed. Obviously HTTPS is not a solution to long-term preservation of the integrity of the mailing list database itself. What protections, if any, are currently in place to protect the archive from tampering on IETF's end? Perhaps the whole thing should be signed by someone official at regular intervals? > > I'm sorry, but the notion that the present use of https provides any > sort of protection against this sort of thing is just silly. The simple > facts that the archives are also available via regular http and that > there is no stated policy about the availability of archives via https > means the present setup is completely vulnerable to downgrade attacks. > A downgrade attack is certainly possible. But there are measures available to ensure that, once an HTTPS connection has been established once, future HTTP sessions will be rejected client-side. And creating an official policy and going HTTPS-only could be done relatively easily. If HTTPS everywhere is where the Web should be going, then IETF should be leading the charge. > 10+ years of experience with multiple certificates having multiple failures > says this is, at best, a crapshoot. > For what reasons? Is it that things scheduled every year or every ten years are easy for admins to miss? Or is it that it's hard to stay on top of certificate revocations when they occur? _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf