Subject: Re: authenticated archives, was https

From: "John Levine" <[email-masked]>
Date: 27 Aug 2011 14:31:04 -0000

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.  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

---

From: Keith Moore <[email-masked]>
Date: Sat, 27 Aug 2011 10:44:43 -0400

> heard of, and many of whom aren't even the organization in the cert

+1.  IMO browser vendors have made TLS nearly useless for web browsing by including so many default CAs; some with dubious integrity, and a few with a demonstrated lack of integrity.

---

From: "t.petch" <[email-masked]>
Date: Sat, 27 Aug 2011 17:35:02 +0200

---- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, August 27, 2011 4:31 PM

> 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
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "John R. Levine" <[email-masked]>
Date: 27 Aug 2011 12:53:30 -0400

> usually works; something has changed (could even be DNS).

It works fine for me in IE on Windows 7 on an ordinary consumer DSL 
connection, click through the warning about the expired cert and the pages 
come right up.  I suspect you will find that "my tools are broken" is not 
a persuasive argument to get people to remove security features, even 
fairly lame ones like this.

> me is small and the benefit - to me -is nil.  Who decided to put it in?

The IAOC, I expect.  I find DKIM useful to skip mail filtering.  Are you 
saying that people are not allowed to use RFC-standard security features 
until you, Tom, approve of them?

R's,
John

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 27 Aug 2011 10:42:25 -0700

> it in, and on what grounds?

The datatracker, wikis, working group chairs pages, registration,
mailing list management and tools sites all support authentication, I
would find it completely unacceptable to pass my credentials  or
activities I engaged in once authenticated in the clear.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 29 Aug 2011 16:58:34 +0200

On 27 Aug 2011, at 19:42 , Joel jaeggli wrote:

>> reason will do - since the cost to me far outweighs the benefit.  So who decided to put it in, and on what grounds?

Good question. For me it also causes more trouble than benefits. But let's split the difference and let the HTTP and HTTPS sites exist side by side for all pages that contain public information.

> activities I engaged in once authenticated in the clear.

There's more to life than HTTPS. Such as digest authentication, which is probably sufficient for most of the above.

---

From: Hector Santos <[email-masked]>
Date: Sat, 27 Aug 2011 19:30:20 -0400

Keith Moore wrote:
> +1.  IMO browser vendors have made TLS nearly useless for web browsing 
> by including so many default CAs; some with dubious integrity, and a 
> few with a demonstrated lack of integrity.

Interesting viewpoint.  Are you advocating for a monopoly or oligopoly 
centralization?

I having read anyone mention OCSP (Online Certificate Status Protocol) 
which use to be off by default, but appears to be enabled by default 
now by updated browsers. It was a painful to solve a customer problem 
when most browser work fine with a brand new certificate but failed 
when newer browser had OCSP enabled.  Some miscommunication issue on 
the type of certificate brought and wildcard domains.  The CA has 
revoked it but only via OSCP was it detectable.

The ongoing direction of dynamic tracking of anything and anyone 
continues to amaze me.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Keith Moore <[email-masked]>
Date: Mon, 29 Aug 2011 12:03:26 -0400

On Aug 27, 2011, at 7:30 PM, Hector Santos wrote:

> Interesting viewpoint.  Are you advocating for a monopoly or oligopoly centralization?

no, replacing one flawed model for another won't help.

the root problem is that users are being expected to extend trust to whatever set of CAs the browser vendors find "convenient", and browser vendors can be influenced/coerced in these choices by various means.

but it's not as if users are in a better position to decide which CAs are trustworthy.