Subject: https

From: "t.petch" <[email-masked]>
Date: Fri, 26 Aug 2011 09:18:41 +0200

Why does the IETF website consider it necessary to use TLS to access the mailing
list archives, when they all appeared without it, or any other security, in the
first place?

Besides all the usual hassle of TLS, today the certificate is reported by IE as
expired, which sort of sums it up.

Tom Petch

---

From: SM <[email-masked]>
Date: Fri, 26 Aug 2011 02:32:13 -0700

Hi Tom,
>expired, which sort of sums it up.

Already reported to ietf-action@.

Regards,
-sm

P.S. My experience of ietf-action@ is that they are responsive and do 
fix problems that are reported.

---

From: "t.petch" <[email-masked]>
Date: Fri, 26 Aug 2011 10:39:39 +0200

----- Original Message -----
From: "SM" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Subject: Re: https

> fix problems that are reported.

Yup, but why are we using https at all?  Who decided, and please would they
undecide?  Unexpired certificates can be circumvented, but all too often, the
https parts of the web site just do not work and, more importantly, I think it
wrong to use industrial grade security where none is called for.

Tom Petch

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 26 Aug 2011 12:12:26 +0200

> wrong to use industrial grade security where none is called for.

I agree with Tom here. In my understanding, all IETF communications
and (mailing list) discussions are open and public.
So why do we need to protect/encrypt?

I would say: protect what must be protected
                   but don't protect what is not supposed to be protected.

just encrypting everything seems incorrect to me.

Bert

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Aug 2011 12:23:59 +0200

Bert, Tom,

I don't see this as being a matter of encrypting, but rather providing
verifiable information the community.  What's more, in as much as the
IETF is a trusted site by many, it's probably a good idea to have at
least some confidence that when you click on a link, you're not going to
get hacked.  Finally, the IETF designed this system, and if we don't
like the fragility, perhaps we should fix it.  There's a saying about
eating one's own dogfood.  After all, if we won't eat ours, why should
anyone else?

By the way, Tom, you're not quite right.  Mail sent out from the IETF
list (including this one and the one you sent to the list) is signed by
the IETF with DKIM.  Again, eating our own dogfood.

Eliot

---

From: Scott Schmit <[email-masked]>
Date: Fri, 26 Aug 2011 06:50:38 -0400

On Fri, Aug 26, 2011 at 09:18:41AM +0200, t.petch wrote:
> Why does the IETF website consider it necessary to use TLS to access
> the mailing list archives, when they all appeared without it, or any
> other security, in the first place?

TLS provides more than confidentiality--it also provides authenticity.
If I were living in a hostile regime, I'd appreciate knowing that the
RFCs, etc that I'm getting really come from the IETF unmodified.

Also, as a general principle, I'd rather someone not be able to read
over my shoulder, even if it is harmless stuff. Using encryption only
when I need it makes all of my encrypted traffic less secure.

For example, if I were out to modify the traffic you read to make sure
that you didn't even know that a working group existed, I'd have a lot
easier time of it if you use DNS without DNSSEC, HTTP without TLS, TLS
without HASTLS, DANE, HSTS, etc. Now, not all of that is completed
protocol work, but one step at a time.

> Besides all the usual hassle of TLS, today the certificate is reported
> by IE as expired, which sort of sums it up.

Mistakes happen. Hopefully lessons are learned so that they don't get
repeated.

If it's a protocol problem, whose fault is that but ours?

-- 
Scott Schmit

---

From: Thomas Narten <[email-masked]>
Date: Fri, 26 Aug 2011 07:06:54 -0400

> other security, in the first place?

Archives have long been and continue to be available at
ftp://ftp.ietf.org/ietf-mail-archive/

Thomas

---

From: Eric Burger <[email-masked]>
Date: Fri, 26 Aug 2011 08:58:05 -0400

+100

On Aug 26, 2011, at 6:50 AM, Scott Schmit wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 26 Aug 2011 09:43:37 -0400

> wrong to use industrial grade security where none is called for.

The mail archives (and the minutes of the physical meetings) are the
official record of the Working Groups, IETF, etc. Those archives
should be available with a reasonably high level of integrity and
authenticity.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Tim Bray <[email-masked]>
Date: Fri, 26 Aug 2011 07:24:04 -0700

I'm increasingly coming to think that *everything* should be done with
TLS unless you can prove it's harmful.  Call me paranoid, but given
the general state of the world, secure-by-default seems like the way
to go.  -Tim

---

From: "t.petch" <[email-masked]>
Date: Fri, 26 Aug 2011 15:32:46 +0200

----- Original Message -----
From: "Donald Eastlake" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Sent: Friday, August 26, 2011 3:43 PM

<tp>
Yeeees but for the mail archives they provide authenticity and integrity only as
far as the Man In The Middle, namely the IETF server/process; this adds a
spurious, to me, impression of security for e-mails that could have come from
anyone masquerading as anyone.  And when there is some defence against
masquerade - DKIM (and yes I know what it does and its limitations) - then the
DKIM signature is invalidated by the list process, that MITM again.

If there are requirements for archives to be provided with a degree of trust, eg
in response to a subpoena, then that should be a separate process, leaving us
ordinary folk to access them in a simple and straighforward manner.

Tom Petch

Thanks,
Donald

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Aug 2011 10:41:21 -0400

--On Friday, August 26, 2011 09:43 -0400 Donald Eastlake
<[email-masked]> wrote:

>> Yup, but why are we using https at all?  Who decided, and
>> please would they undecide?  Unexpired certificates can be
>> circumvented, but all too often, the https parts of the web
>> site just do not work and, more importantly, I think it wrong
>> to use industrial grade security where none is called for.
> 
> The mail archives (and the minutes of the physical meetings)
> are the official record of the Working Groups, IETF, etc.
> Those archives should be available with a reasonably high
> level of integrity and authenticity.

Don,

If that is the goal, wouldn't we be lots better off just
digitally signing those things, just as we are gradually
starting to create signatures for I-Ds, etc.?  Verifying that
one is talking to the right server and that the content is not
tampered with in transit is all well and good, but it doesn't
protect against compromised documents or a compromised server at
all.

   john

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 26 Aug 2011 07:44:18 -0700

It doesn't...

http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html

---

From: Melinda Shore <[email-masked]>
Date: Fri, 26 Aug 2011 06:51:59 -0800

> should be available with a reasonably high level of integrity and

I'm not fully sold, but either way it seems to me that a technology
with such a very, very high error rate in deployment probably needs
some reconsideration.

Melinda

---

From: [email-masked]
Date: Fri, 26 Aug 2011 09:14:59 -0700 (PDT)

> protect against compromised documents or a compromised server at

+1. If you want signatures, do them properly. Don't pretend a transfer
protection mechanism covering exactly one hop provides real object security,
because it doesn't.

And as for the "encrypt so the really secret stuff doesn't stand out" argument,
that's fine as long as it doesn't cause inconvenience to anyone. That's clearly
not the case here. And I'm sorry, the "mistakes were made" notion doesn't
really fly: Certificates aren't a "set it and forget it" thing, so if you
haven't noted expiration dates on someone's to-do list so they can be updated
before expiration, you're not doing it right.

				Ned

---

From: "t.petch" <[email-masked]>
Date: Fri, 26 Aug 2011 17:45:23 +0200

----- Original Message -----
From: "Joel jaeggli" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Sent: Friday, August 26, 2011 4:44 PM
Subject: Re: https

> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html

Try the source of
http://www.ietf.org/list/discussion.html
where https: outumbers http: or
http://www.ietf.org/list/nonwg.html
where I run out of numbers before I run out of https:

Tom Petch

---

From: Adam Novak <[email-masked]>
Date: Fri, 26 Aug 2011 12:51:28 -0500

> protection mechanism covering exactly one hop provides real object security,

It ensures that what you're getting is the same as what the IETF has
on file, and (assuming you trust the IETF's archive integrity, which
is a separate problem) what everyone else on the list received. It
seems to me it's more important to know that than to know that stuff
sent to the list actually came from who it claims to come from. Does
it really matter if a proposed standard wasn't really designed by who
the archive says it was designed by?

> before expiration, you're not doing it right.

Yeah, it seems like the IETF would be on top of certificate
expiration, having invented it. But I think having the encryption is a
very good thing. Some government interests would be happy to keep
information about some aspects of IETF business away from their
citizenry, and have the resources to launch a MITM attack. (Of course,
those governments may also have the resources to sign a fake
certificate, but that is, again, a separate problem.)

Once the certificate expiration business is fixed, it should be fairly
simple to make sure it's kept up to date so that this sort of thing
doesn't happen again.

---

From: Adam Novak <[email-masked]>
Date: Fri, 26 Aug 2011 13:24:26 -0500

On Fri, Aug 26, 2011 at 1:13 PM, Hector Santos <[email-masked]> wrote:
> Makes you wonder. Why is the concept of expiration required?  Did the IETF
> expire, die?  Did its value as an Organization go down and only valid on a
> year to year basis?

As I understand it, expiration is supposed to solve the problem of
someone getting their hands on your old certificates and impersonating
you. In order to impersonate you, not only do they have to get into
your system, they have to have done it in the last year or so.

It also keeps certificates for domains from outliving domain
registrations for too long. If you don't have the domain when you go
to renew the certificate, the CA shouldn't renew it.

I guess it also keeps revocation lists short. You only have to
remember that a certain certificate was compromised until it expires,
instead of forever.

---

From: [email-masked]
Date: Fri, 26 Aug 2011 11:12:24 -0700 (PDT)

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

> and (assuming you trust the IETF's archive integrity, which
> is a separate problem)

On the contrary, it's the same problem. You're just pretending that solving an
insignificant subset of that problem is useful. It isn't.

> what everyone else on the list received.

This, OTOH, *is* a separate problem, one that isn't addressed in any way by
https on archive archive access. Nor does a signed archive address this issue.

Nonrepudiation of delivery is in fact a very difficult problem to solve - the
algorithms I'm aware of for it either involve a TTP or are exceptionaly ugly -
and the fact that the architecture of our email services isn't designed for it
doesn't exactly help. (In case you care, it's the nontransactional nature of
POP and IMAP that gets in the way of doing nonrepudiation of delivery at the
email protocol level.)

We're very lucky that we don't operate in a regime where this is actually a
requirement. (And such regimes do exist, although the solutions they actually
use tend to be hacks.)

> It

And now you're talking about yet a third problem - nonrepudiation of
submission. It's completely doable, but only by significantly increasing the
barriers to participation by requiring signed messages. I don't believe the
benefits come even close to the costs.

> certificate, but that is, again, a separate problem.)

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.

Again, if you really care about this sort of stuff, the archives need to be
timestamped and signed. 

> simple to make sure it's kept up to date so that this sort of thing

10+ years of experience with multiple certificates having multiple failures
says this is, at best, a crapshoot.

				Ned

---

From: Adam Novak <[email-masked]>
Date: Fri, 26 Aug 2011 14:22:07 -0500

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

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

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Aug 2011 15:27:27 -0400

> storing the archives is itself trusted, this would seem to be all that

There can be web proxies on the front end (if the client is configured to use them) and the web server itself can be implemented in such a way as to retrieve content from other servers (via a number of means, e.g. NFS, CIFS, web services calls, sql calls).  Though I don't know whether the latter is the case for content served from IETF's servers.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Fri, 26 Aug 2011 11:32:30 -0800

> top of certificate revocations when they occur?

Firewall researchers have found at least one error of some sort in
99% (yes, really) of the firewall rulesets they've examined.  If
I had to guess how many PKI deployments have problems, I'd put it in
the same ballpark.  They seem to fall into several broad categories
1) naming (including SANs), 2) expiration, 3) faulty trust
establishment.  These may or may not be fixable, but what doesn't
appear to be fixable is that too people don't really understand what 
certificates represent, the difference between a certificate and
a key, or what it means to TLS-protect traffic.

Listen to Ned, Adam.  He's right.

Melinda

---

From: Eric Burger <[email-masked]>
Date: Fri, 26 Aug 2011 16:15:55 -0400

Two thoughts.

On the one hand, Ned is absolutely correct: the thing we want to make absolutely sure of is the integrity of the object. The way of doing that is making sure the object itself can prove its integrity.  In the messaging world, we do this with S/MIME.  The use of TLS for SMTP or IMAP does not convey any integrity assertions for the object.  Note this object should be signed by me when you receive it, by the way.

On the other hand, while TLS is not at all sufficient for the integrity of the object, it is necessary to protect the individual accessing the object.  There are a number of countries where asking for the RFCs relating to privacy, security, and threats to such too many times could get you arrested.  Likewise, the presumption is the object might be signed, but it would be insane and useless to encrypt the object.  However, there are many, many times one would want the object encrypted, even if only to compress it.

Given that, the question should not be, "Why are we using TLS if the object is not private?," but "What are we not using secure connections for all IETF access, over any modality?"

One of the answers seems to be, "Because it sucks."  That is the sentiment of the message below.

So we are eating our dog food, and we are getting indigestion.  Sounds like an opportunity to fix it!

--
- Eric

On Aug 26, 2011, at 3:32 PM, Melinda Shore wrote:

> appear to be fixable is that too people don't really understand what certificates represent, the difference between a certificate and

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Aug 2011 14:00:13 -0700

Joel,

I don't know what "It doesn't" is supposed to mean, but visiting
https://www.ietf.org/* today with firefox it is still reporting that the
certificate expired yesterday.

Given the volume of discussion about the topic starting yesterday when
the problem started one could easily make a case for "it's still broken"
being a significant "issue."

cc'ing the address listed as "Report Website Errors" on the home page.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Aug 2011 19:43:35 -0400

--On Friday, August 26, 2011 16:15 -0400 Eric Burger
<[email-masked]> wrote:

> Two thoughts.
> 
> On the one hand, Ned is absolutely correct: the thing we want
> to make absolutely sure of is the integrity of the object. The
> way of doing that is making sure the object itself can prove
> its integrity.  In the messaging world, we do this with
> S/MIME.  The use of TLS for SMTP or IMAP does not convey any
> integrity assertions for the object.  Note this object should
> be signed by me when you receive it, by the way.

And it verifies too... sort of.  Note that the IETF mailing list
machinery tries to prevent it from doing so by appending a
footer to tell everyone who it is (independent of the standard
List-* headers that contain the same information).  Another
separate problem, but definitely falling into the "dogfood...
yum" category.

> On the other hand, while TLS is not at all sufficient for the
> integrity of the object, it is necessary to protect the
> individual accessing the object.  There are a number of
> countries where asking for the RFCs relating to privacy,
> security, and threats to such too many times could get you
> arrested.

Yes, although it isn't entirely clear that TLS actually provides
enough protection in practice.  A sufficiently paranoid
government with those concerns would either force the
connections through proxies that it controlled (see Keith's
note) or would notice connections to IETF servers and "inquire",
through out-of-band means, about what was being retrieved.
There are ways to protect against that risk, but assuming that
unadorned https is sufficient is almost certainly naive.

> Likewise, the presumption is the object might be
> signed, but it would be insane and useless to encrypt the
> object.  However, there are many, many times one would want
> the object encrypted, even if only to compress it.

Sure.  If TLS actually worked for its intended purpose in the
overwhelming number of cases, nothing that Ned or I have said
would argue against using it.  In that regard, the problems are
that it is assumed to solve several problems for which it is
useless and several others, including your example above, for
which its effectiveness is dubious against an attacker with
sufficient non-network resources.

> Given that, the question should not be, "Why are we using TLS
> if the object is not private?," but "What are we not using
> secure connections for all IETF access, over any modality?"
> 

> Sounds like an opportunity to fix it!

I think it is more than that.  If we (and the Secretariat and
IASA) cannot get it together to keep certs up to date, or at
least to get them updated _very_ quickly when someone notices
that they have expired (note that it is now only a few minutes
short of 24 hours since the thing expired), we are sending a
pretty strong message to the community that we don't care and no
one else should either.  Remember that the message browsers pop
up when an invalid or expired certificate is encountered is
totally incomprehensible to a typical luser, offering only
choices of not accessing a site that contains useful information
and that was valid before and accepting the cert, errors and
all.  The more valid sites there are with invalid certificates,
the more we train the user to accept those invalid certificates,
rendering the whole certificate idea (and TLS with it)
pointless.  By choosing to contribute to that problem, the IETF
undermines the utility of TLS for addressing the real issues of
server authentication and client-> server encryption that it was
primarily intended to address.

    john

---

From: Glen Zorn <[email-masked]>
Date: Sat, 27 Aug 2011 12:29:08 +0700

> protection mechanism covering exactly one hop provides real object security,

I could have sworn that TLS was an e2e mechanism.  Maybe you're using
the term "hop" in a manner unfamiliar to me?

> before expiration, you're not doing it right.

Isn't "not doing it right" pretty much the definition of "mistake"
(assuming no evil intent)?

---

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

----- Original Message -----
From: "Doug Barton" <[email-masked]>
To: "Joel jaeggli" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "IETF Discussion" <[email-masked]>;
<[email-masked]>
Sent: Friday, August 26, 2011 11:00 PM
Subject: Re: https

Doug

How I interpreted the reply is that some mailing list archives can be accessed
without using TLS, typically by going to the Working Group page and selecting
the archive from there; v6ops is such a one.

But as I pointed out yesterday, if you go to the ietf mailing list pages, such
as
http://www.ietf.org/list/nonwg.html
then that contains some 250 or more html anchors with a scheme of https:, and
that is the only way I know of accessing some of the archives (I was looking for
the IESG comments on the approval of an I-D, comments which I had missed at
announce time).

I tried editing the URI to remove the 's' but the IETF website puts it back
again:-(

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Sat, 27 Aug 2011 10:53:47 +0200

----- Original Message -----
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; "IETF Discussion" <[email-masked]>
Sent: Saturday, August 27, 2011 7:29 AM
Subject: Re: https

> the term "hop" in a manner unfamiliar to me?

Glen

Without a precise context, then e2e can mean anything, from ends of a fibre link
to ends of a communication between two sentient beings.

On other lists, there is sometimes disagreement as to what TLS is, transport,
application or what.  What it is not is a secure channel from application to
application, for that you need channel binding or some such, a problem which a
number of WGs have wrestled with, such as isms for SNMPv3 (which used its own
form of binding for both SSH and TLS between the secure transport and the
application).

I regularly hear, and cringe at, statements in the media that you must check for
the padlock to know that you are secure.

A) you do not know what cryptography is in use (my local library recently liked
SSL2 as a default)

B) you do not know where the endpoints of the channel are

TLS and padlocks are often a spurious miasma of security.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Sat, 27 Aug 2011 11:12:38 +0200

Glen

Me again.

Just after I posted my last message, I received a post on the ietf-ssh list,
hosted by netbsd.org, and looking through the 'Received: from' headers, as one
does on a wet Saturday morning of a Bank Holiday weekend, there was TLS, used to
submit the message to the server, so even spammers have caught on that TLS
should be used everywhere.  End to end?

Tom Petch

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sat, 27 Aug 2011 09:53:04 -0400

> the general state of the world, secure-by-default seems like the way

You're not alone.  I think one reason this discussion suddenly flared up so dramatically is that this is at least as much a political issue as a technical one, and therefore not exactly the IETF's bailiwick.  EFF certainly seems to think so:

	http://www.eff.org/https-everywhere

Nowadays the only reason I can see for not wanting to use any form of encryption you can, anywhere and anytime you can, is a desire to make it easier for governments to snoop on you.  Even flawed or partial schemes can provide some protection if deployed widely enough -- it's the same principle as steganography, more or less.  -- Nathaniel

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 27 Aug 2011 07:44:54 -0700

On 8/26/2011 12:18 AM, t.petch wrote:
 > Why does the IETF website consider it necessary to use TLS to access the
 > mailing list archives, when they all appeared without it, or any other
 > security, in the first place?

There is a general move towards using https for all web exchanges, as already 
noted on this thread.  When a server-side cert is used, this includes 
protection against man-in-the-middle attacks.

As for providing confidentiality when the data are actually public, yeah, that's 
kind of wasted, but the web service can't know whether the data needs 
protecting.  For example you might be logging in to your mailing list account.

However, as Eliot notes, there is a degree of data authentication this provides.

As for the alternative of object-based signing, that's good in theory, but not 
as well deployed -- and some current IETF wg activity seeks to remedy this(*) -- 
and therefore not an immediately superior choice.  (As a fan of object-based 
signing, I would rather have the authentication be object-based.)

> the term "hop" in a manner unfamiliar to me?

Evidently so.

The likely disparity is with applications that have their own store-and-forward 
model, as already noted on this thread.  TLS covers only one step (hop) in the 
sequence; by definition, that's not end2end.

And note that this is a rather larger set of apps than most people realize.

The modern web, for example, is highly store and forward at the application 
level.  First, the author is typically far removed from the server that provides 
the data.  Second, caches and proxies mediate the exchange.  TLS protects none 
of the intermediary processes.

In other words, with respect to application-level protection, TLS is equivalent 
to a link-level protocol.  It is 'direct' between two apps participants during 
an immediate exchange.  It does not cover the sequence of nodes at the 
application level.  Having a sequence of TLS sessions provides protection of the 
communication exchanges, but does not protect within the nodes mediating the 
(apps-level) e2e sequence.

In other words, "end to end" is a relative construct.  Even email is not 
end2end, relative to some processes that use email, such as EDI...

d/

(*) A fundamental issue that arises especially for object-based signing is which 
identifier to use.  There is a very large difference between having it signed by 
the author's organization, versus by the web server operator, for example.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: [email-masked]
Date: Sat, 27 Aug 2011 08:25:45 -0700 (PDT)

> the general state of the world, secure-by-default seems like the way

This sentiment always sounds nice, but the devil is in the details.

Back when STARTTLS was added to SMTP, a bunch of us thought this provided the
means to do opportunistic encyption of email transport, so there was a push to
deploy that. It was a total failure - it seems a certain large vendor with a
very popular implementation borked their server so it advertised STARTTLS even
though no certificate was installed and any attempt to negotiate TLS protection
would end in failure. And since the negotiation failure left the connection in
an unusable state, a new connection had to be tried, along with all the logic
to prevent the new one from ending up in the same state.

It tooks years before enough of the broken servers were fixed to try again, and
by then service defaults and deployment guidelines were well established and
the opportunity was gone as well.

Of course this set of issues was unique to the situation. But with TLS it's
always something - if it isn't broken default configurations, its incompatible
cipher suites, or problems with certificate formats, or expired certificates,
or dubious CAs, or major security holes in popular implementations, etc. etc.

The bottom line is this stuff is just too complicated for mere mortals to get
right, and the fact that they then proceed to get it wrong more often than not
causes an enormous amount of trouble.

In the present case, for example, you may think that an expired certificate is
not a big deal. Not so. For one thing, the more people have to click on the
"this really isn't secure, proceed anyway" button to get things done, the more
likely they are to do it when it's a real attack and not a maintenance problem.
And for another, there are some browser/certificate error combinations  where
there's no workaround - no amount of clicking "I agree" buttons will get you
the data you're after.

I don't have an anwwer here, but the one thing I'm fairly sure of is that
blindly pushing TLS everywhere is not the solution a lot of folks believe
it is.

				Ned

---

From: Melinda Shore <[email-masked]>
Date: Sat, 27 Aug 2011 08:25:01 -0800

> blindly pushing TLS everywhere is not the solution a lot of folks believe

I tend to think that the problem here (and I agree that it's a big one)
isn't TLS, but that PKI as defined by pkix is very difficult to deploy
correctly.  I've seen similar sorts of problems with digital signatures
on email, but in those cases as often as not someone simply got
the certificate contents wrong (or the user doesn't understand how to
configure his mail client correctly and is using a name that doesn't
appear in the certificate) rather that the cert has expired (although
there's a lot of that, too).  There's a substantial usability problem.

Melinda

---

From: [email-masked]
Date: Sat, 27 Aug 2011 10:07:03 -0700 (PDT)

> correctly.

Agreed.

> I've seen similar sorts of problems with digital signatures

Absolutely, and it's both architectural and operational - PKI is
full of complex and subtle concepts that implementations don't exactly
help you with.

				Ned

---

From: Glen Zorn <[email-masked]>
Date: Sun, 28 Aug 2011 11:43:08 +0700

> should be used everywhere.  End to end?

Apparently, from the POV of the spammer & his SMTP server.  Email is a
store & forward system.  In any case, my original question was not about
the definition of end-to-end, it was about Ned usage of the term "hop".
 Upon further analysis, however, it seems clear that he was referring to
the email archives as if they are something other than simple files (as
betrayed by his statement that "Don't pretend a transfer protection
mechanism covering exactly one hop provides real object security,
because it doesn't."); thus, the retrieval of the archived data would be
the last "hop" in the email system.  There seem to be two problems with
this statement: one is taking the file transfer mechanism as if it was
part of the email system itself, which it obviously is not (downloading
an archived message is no different than downloading an RFC from a Web
site); the other being that someone, somewhere was pretending that TLS
does something that it was never designed to do (a straw man of, AFAICT,
Ned's invention -- I don't recall anybody making such a claim on this
thread, nor for that matter saying they _wanted_ "real object security"
applied to the archives, merely that it's not really a bad idea for a
person retrieving them to have some assurance that they came from the
IETF server and that they weren't modified in transit).

...

---

From: [email-masked]
Date: Sun, 28 Aug 2011 09:25:09 -0700 (PDT)

> > should be used everywhere.  End to end?

As a side note, the reason spammers use TLS to submit mail is obvious: It's
required by many submission servers so they really don't have a choice. (The
reason it's required is to protect the authentication exchange, not because
there's any real expectation that it provides useful privacy protection for the
submitted email itself.)

> the definition of end-to-end, it was about Ned usage of the term "hop".

I used the term "hop" in a very generic sense to refer to moving the
data around.

> the last "hop" in the email system.

And that's incorrect. For one thing, I often retrieve material from web sites
and save it rather than looking at it right there on the screen. So the
transfer of the material from the web server is in no way, shape, or form the
final hop the information takes before it is consumed. As as Keith points out,
I and many others am often forced to do such access through corporate-mandated
proxies of various sorts - another hop.

> There seem to be two problems with
> part of the email system itself,

Nobody is making any such claim.

> which it obviously is not (downloading
> thread,

I was responding to the justification given for the use of https in this

> > level of integrity and authenticity.

Nor was I the only, or even the first, to suggest that object security
is needed for this sort of protection.

> nor for that matter saying they _wanted_ "real object security"

And once again, nobody is saying that TLS doesn't give some very limited
assurance along these lines - the notion that there are claims to the contrary 
is your own strawman. What we are saying is that there are also significant
costs, those costs appear to be greater than the benefits in this case, and if
there is real concern about archive integrity there are better ways to secure
them.

Anyway, this discussion is now well past it's sell-by date, so this will be my
final response on the topic.

				Ned

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 28 Aug 2011 11:31:39 -0700

> Joel,

"it doesn't" means that the mailing list archives do not require the use
of https, if the entry point urls point to the https server that bad in
this case...

If one has forgotten to renew a certificate before it expires, it takes
time to get a new one issued. as an operational pratice is is necessary
to track the issue and expiration dates  of such resources.

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 28 Aug 2011 12:55:01 -0700

> of https, if the entry point urls point to the https server that bad in

To be still more specific the mailman archives do not. the ibin archive
does.

---

From: "t.petch" <[email-masked]>
Date: Mon, 29 Aug 2011 12:19:56 +0200

----- Original Message -----
From: "Joel jaeggli" <[email-masked]>
To: "Doug Barton" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "IETF Discussion" <[email-masked]>;
<[email-masked]>
Sent: Sunday, August 28, 2011 9:55 PM
> To be still more specific the mailman archives do not. the ibin archive

Joel

Um, I do not understand that statement; mailman I know, ibin I do not, but
either way, I am an archive user, not an e-mail administrator, and while I can
access some archives with http:, notably from the web page for specific WG,
others I cannot, notably from
http://www.ietf.org/list/nonwg.html
which is the only way I can access some of them, as far as I know: and on that
page, there are some 250 html anchors with a scheme of 'https:'
Edit the scheme to http: and the web site puts the 's' back in so either way,
I am stuffed.

Tom Petch

> >>>> Why does the IETF website consider it necessary to use TLS to access the
mailing

---

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

> the general state of the world, secure-by-default seems like the way

That would be nice in a world where such security didn't slow everything down, especially on high RTT links. HTTPS really makes everything a whole lot slower on a mobile device, not to mention using extra battery power.

There is absolutely no reason mailinglist archives or most other stuff on www.ietf.org needs more protection than any other random web page and as such imposing the additional overhead on other people is very annoying.

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Aug 2011 14:13:14 -0400

> simple to make sure it's kept up to date so that this sort of thing

Makes you wonder. Why is the concept of expiration required?  Did the 
IETF expire, die?  Did its value as an Organization go down and only 
valid on a year to year basis?

It just seem so arbitrary for one to certify another and say to the 
world come X day, you are no longer the same trusted entity when what 
he is really saying "He didn't pay me like he suppose to every yet" 
Does that imply the IETF is now downgraded, in debt and can not be 
trusted?

All rhetorical questions. After all, they did "Invent" it. It should 
be free to the IETF. :)

Just consider there are some in the DKIM arena who wanted for the x= 
expiration tag to be deprecated and removed.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Aug 2011 14:49:33 -0400

I see, so as long as its not revoked, if compromised, you are hosed 
until it expires.

I wonder if OCSP (Online Certificate Status Protocol) can help 
addresses this? Expired or not, it can still be revoked with dynamic 
checking as long as the browser as OCSP enabled.  So I guess its a 
matter of reporting the theft as soon as it is discovered.

Adam Novak wrote:
>> Makes you wonder. Why is the concept of expiration required? �Did the IETF
>> expire, die? �Did its value as an Organization go down and only valid on a
>> year to year basis?
> 

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Aug 2011 18:41:31 -0400

Try it with Chrome and it makes you feel like the world blew up, I 
suppose intentionally as a fail-safe for the user-sake.

-- 
Sincerely

Hector Santos

---

From: "t.petch" <[email-masked]>
Date: Mon, 29 Aug 2011 19:06:23 +0200

---- Original Message -----
From: "Hector Santos" <[email-masked]>
To: "Adam Novak" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Sent: Friday, August 26, 2011 8:49 PM
Subject: Re: https

> addresses this?

Hector

Back in 2008, some people could not access the IETF website using
TLS because of OCSP; I think that the URI for the OCSP site for
the certificate was unavailable, at least for some parts of the
world.  Another potential vector for failure.

Tom Petch

>                Expired or not, it can still be revoked with dynamic