---- Original Message -----
From: "John Levine" <johnl@xxxxxxxx>
To: <ietf@xxxxxxxx>
Sent: Saturday, August 27, 2011 4:31 PM
> I can't tell what problem we're trying to solve here. The original
> question (other than that whoever runs the IETF web site should
> buy a new cert) seemed to have something to do with mailing list
> archives.
John
Yes, more generally it is the creeping changes to the IETF service that
makes work progressively more difficult. https: access to the IETF web
site quite often fails for me, indeed access at all quite often fails. It never
used
to, and I am hard put to say just when it changed, but it was a year or two ago.
In the case of http: access, MSIE just times out. Repeat the request and it
usually works; something has changed (could even be DNS).
With https:, the CRL downloads as does the source of the web page and
then the process stalls, permanently; leaving it a couple of hours, or
refreshing
the page, with CRL now in place, and the little icon just goes on turning until
it
is time to stop work. Perhaps when I upgrade my PC it will work - or
perhaps not, without a diagnosis I cannot tell.
In the mean time, I would like TLS exterminated from the IETF website - any
reason
will do - since the cost to me far outweighs the benefit. So who decided to put
it in, and on what grounds?
Recently, DKIM was added to outgoing mail. The mail still works, the cost to
me is small and the benefit - to me -is nil. Who decided to put it in?
There has been a discussion about adding 'subject_prefix' on IETF_Discuss.
(This is a welcome change, actually discussing it before doing it). For me,
the added cost would be small, and the benefit nil.
What is going to come next, and will we get any warning, or will the cost of
IETF activity just go up again?
Tom Petch
I think it would be swell to know that the archives I
> retrieved were the real ones, but what does real mean here?
>
> A - The messages sent by authenticated senders
> B - The contents of the archive as of some past time when the
> archives were created
> C - The archives as they are on an IETF server now
> D - The archives as presented by some presumably reliable piece
> of software (pipermail)
> E - Something else
>
> While option A might be nice, it's not going to happen without an
> implausible level of S/MIME or PGP signing.
>
> Option B seems useful to me, since it defends against the threat of
> accidental or deliberate bitrot. (An example might be restoring an
> archived copy that had the addresses xxx'ed out.)
>
> Options C and D seem less useful.
>
> Harking back to a previous argument about signing RFCs, the way I
> would do option B would be to publish hashes of the archive files in
> enough places to be sure they're persistent, e.g., print the latest
> set of hashes on the back of everyone's name card at IETF meetings.
>
> TLS for session privacy is nice, but I find negligible value in a
> little lock icon in my browser that means only that one of the several
> dozen cert issuers configured into my browser, most of whom I've never
> heard of, and many of whom aren't even the organization in the cert
> name, signed something.
>
> R's,
> John
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf