Subject: stats from the text conferencing experiment

From: Marshall Rose <[email-masked]>
Date: Sat, 23 Nov 2002 15:45:30 -0800

hi. i've attached some stats from the text conferencing experiment.

basically, there was a chatroom available for anything that met at ietf55.
that's 104 rooms. of those 52 were "active" in the sense that at least two
people showed up. 52/104 = 50%

the text file shows the stats for 104 configured rooms.
    
the png files show the stats for the 52 active rooms.
    
feel free to generate (and share) other diagrams using the .txt file.

obviously, the two plenaries got the most usage; however, the per-area
stuff has some minor patterns in terms of speakers:
    
    app/int seem to make the most use
    followed by rtg/sec/tsv
    followed by ops
    
(sub-ip seems to have ignored it.)
    
/mtr

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Nov 2002 20:04:47 -0500

Hi Marshall,

It looks like the experiment was a success!

Do we have any way to tell how many of the chatroom attendees were
not at the IETF in person?  I'd be interested to know how well
this served as a way to allow people to participate from home.

Margaret

---

From: Dean Willis <[email-masked]>
Date: 24 Nov 2002 02:17:48 -0600

> this served as a way to allow people to participate from home.

The conference administrator for SIP and SIPPING told me they didn't
think that anybody had logged in remotely, although the chat rooms were
actually fairly active during the meeting. 

Just another point of interest -- the chat administrator for the second
SIPPING session actually logged into the chat room using the Microsoft
Windows Messenger running SIP, using a SIP/SIMPLE to JABBER gateway
hosted at iptel.org. Yes, we DO really have some kind of interop story.

--
Dean

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 09:08:57 -0800

> hosted at iptel.org. Yes, we DO really have some kind of interop story.

and this is without CPIM, right?  hmmm... almost makes one want to task a
certain troublesome question...

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 09:08:04 -0800

> this served as a way to allow people to participate from home.

briefly no: there's no scientific way of telling whether someone was:

	- in the room,
	- in another room at atlanta, or
	- nowhere near atlanta

based on a few anecdotal descriptions i've heard, i think the distribution is
something like 70-20-10, but that's very fuzzy.

/mtr

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 24 Nov 2002 12:59:01 -0500

>briefly no: there's no scientific way of telling whether someone was:

Do the logs not contain what IP addresses were connected?  I know it
wouldn't be foolproof, but it would probably be safe to assume that
IP addresses from the IETF55 network were folks in Atlanta and other
IP addresses were not...

Margaret

---

From: Derek Atkins <[email-masked]>
Date: 24 Nov 2002 14:27:11 -0500

> certain troublesome question...

Yea, the question is: what is the end-to-end security model of this
gateway?

> /mtr

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 13:22:54 -0800

> IP addresses from the IETF55 network were folks in Atlanta and other

as a matter of architecture, it doesn't work that way.

my client (in atlanta) connects to its server (in sacramento), which it turn
forward traffic to the conference server (in denver). the best the conference
server can do is know where the last hop originates from...

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 13:21:15 -0800

> Yea, the question is: what is the end-to-end security model of this

or, is it even appropriate to have an end-to-end security model when gatewaying
between messaging systems? i don't seem to recall that being necessary for the
mhs/smtp stuff...

/mtr

---

From: Dean Willis <[email-masked]>
Date: 24 Nov 2002 16:30:23 -0600

> certain troublesome question...

Well, it was plain ASCII text only. Not particularly compelling, but it's a start.

--
Dean

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 14:22:27 -0800

> > or, is it even appropriate to have an end-to-end security model when
> > gatewaying between messaging systems? i don't seem to recall that being
> > necessary for the mhs/smtp stuff...
> 
> RFCs 2778/9 require it, so, yes, it is absolutely appropriate to have
> an end-to-end security model when gatewaying between messaging
> systems.  I want authoritative source identification of my IMs
> whenever possible, even across multiple IM systems.  Or better,
> end-to-end message encryption across the gateway.

well, ok, i don't want to argue with dogma. the fact that e2e security has never
been successfully deployed between heterogeneous messaging system gateways
suggests that we'll be needing quite a bit of thrust to get that particular cow
into orbit...

/mtr

---

From: Derek Atkins <[email-masked]>
Date: 24 Nov 2002 17:24:27 -0500

> suggests that we'll be needing quite a bit of thrust to get that particular cow

Said "thrust" is called CPIM.  :)

-derek

---

From: Derek Atkins <[email-masked]>
Date: 24 Nov 2002 17:18:18 -0500

-derek

---

From: Randy Bush <[email-masked]>
Date: Sun, 24 Nov 2002 15:09:50 -0800

i do want

  o authentication of the party with whom i am conversing, though i
    realize that i may not be talking to someone who is on a cheapo
    system which does not support compatible indentity mechanisms

  o privacy of my conversations, both from monkeys in the middle and
    from snoopers on either end

and i don't think these needs are strange.  but jis has a piece on
this that goes into much more cogent detail.

randy

---

From: Melinda Shore <[email-masked]>
Date: Sun, 24 Nov 2002 18:07:36 -0500

> well, ok, i don't want to argue with dogma. the fact that
> e2e security has never been successfully deployed between
> heterogeneous messaging system gateways suggests that
> we'll be needing quite a bit of thrust to get that
> particular cow into orbit...

I dunno.  It's yet another argument for separating signaling
from data, which SMTP doesn't do and jabber doesn't do but
which FTP does and telephony signaling protocols typically
do.  The security model for signaling needn't and shouldn't
match that for data since the threats are different.  The
only real issue here is that making that separation makes
the protocol firewall/NAT unfriendly, which I think needs to
be understood more as a deficiency in firewalls and NATs
than a reason not to properly secure an application.

Melinda

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 15:17:40 -0800

> than a reason not to properly secure an application.

uh, don't think we're talking about the same thing.

i know that i can make e2e-security work for email. ditto for jabber. i use it
every day.

10 years ago, i was able to make e2e-security work for x.400.

what no one was able to do was make e2e-security work when one endpoint was
using x.400 and the other using smtp...

/mtr

ps: i think that smtp does a fine job of separating signaling from data, even if
it does do both over a single connection...

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 15:31:05 -0800

> this that goes into much more cogent detail.

randy - hi.

these are perfectly reasonable requirements, but they may not be realistic
requirements if you and i are using systems with fundamentally different
architectures and expectations.

i use the x.400/smtp analogy simply because both are email systems, but the
philosophies that drove the architecture of each system are radically different.
while it was possible to gateway between them, the gatewaying was limited to the
LCD, which would not meet the requirements above. one can argue as to whether
that's a good or a bad thing, but when combine a squirrel with a hunk of
mozarella cheese, you tend to get something that behaves very, very oddly...

/mtr

---

From: Melinda Shore <[email-masked]>
Date: Sun, 24 Nov 2002 18:39:30 -0500

> using x.400 and the other using smtp...

Right, but you can protect media streams across gateways
(i.e. the gateway doesn't have to look at or modify the
contents) if the data are separated from signaling - the
gateway needs to translate the signaling but it does *not*
have to translate the data as long as the data formats are
the same on either side of the gateway, which they typically
are with telephony.  (Everybody uses pretty much the same
basic codecs, all of the major signaling protocols
encapsulate them using RTP.)  You cannot, however, provide
signaling protection end-to-end, but it's a somewhat
different issue.

Melinda

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 15:44:46 -0800

> signaling protection end-to-end, but it's a somewhat

and this is the problem because the formats are *different* in each system.

some folks think you can impose a common format on systems with fundamentally
different architecture, and it's that wish which is at variant with "the real
world"(or at least that part of the real world known as "the market")...

/mtr

---

From: Melinda Shore <[email-masked]>
Date: Sun, 24 Nov 2002 19:17:34 -0500

> world"(or at least that part of the real world known as "the market")...

I don't think that's true - if there were sufficient
pressures to provide some greater measure of
interoperability or if users *really* cared about meaningful
security (and I think the evidence is clearly that it's only
a small minority of users who do), there's no reason why
this couldn't be handled by something like an RTP payload
format for text (which we've already defined) and a
separation of data streams from signaling streams.  

The issue is not whether or not it's doable (it is), but
rather whether or not interested parties think it's worth
the effort.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Sun, 24 Nov 2002 19:59:55 -0500

> the problem is that historically, the market hasn't valued
> value-rich gatewaying between existing systems...

The market doesn't value security much, either, so here we
sit.

Melinda

---

From: Randy Bush <[email-masked]>
Date: Sun, 24 Nov 2002 16:53:59 -0800

> some folks think you can impose a common format on systems with
> fundamentally different architecture, and it's that wish which is at
> variant with "the real world"(or at least that part of the real world
> known as "the market")...

ahhh.  that explains why the IP hourglass model doesn't work

randy

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 17:03:23 -0800

> The market doesn't value security much, either, so here we

i suspect there are different dynamics at work, but, regardless, to ignore the
market is to purposefully avoid success...

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 16:52:07 -0800

> rather whether or not interested parties think it's worth

we're all entitled to our world views, of course.

the problem is that historically, the market hasn't valued value-rich gatewaying
between existing systems...

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Sun, 24 Nov 2002 17:02:14 -0800

> ahhh.  that explains why the IP hourglass model doesn't work

heh, heh. if only we were talking about a solution in which we could layer on
top of, instead of layering in between.

the problem isn't trying to find the "glue" that will sit on top of messaging
systems based on radically different architectures.

the problem is trying to find the "glue" that will sit between messaging systems
based on radically different architectures.

of course, i'm happy to stick with the "ip" analogy... simply explain how to
build a gateway between an application sitting on top of ip, and another
application sitting on top of clnp, and i'll concede the point (and blissfully
forget about spending 5 years trying to do that).

sure, it's desirable to build appliation-layer gateways that are feature rich;
but the cost of doing so is typically disproportionate for the demand...

/mtr

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 25 Nov 2002 09:49:43 +0100

--On søndag, november 24, 2002 13:21:15 -0800 Marshall Rose 
<[email-masked]> wrote:

>> > > Just another point of interest -- the chat administrator for the
>> > > second SIPPING session actually logged into the chat room using the
>> > > Microsoft Windows Messenger running SIP, using a SIP/SIMPLE to
>> > > JABBER gateway hosted at iptel.org. Yes, we DO really have some kind
>> > > of interop story.
>> >
>> > and this is without CPIM, right?  hmmm... almost makes one want to
>> > task a certain troublesome question...
>>

until the X.400 proponents lost interest, the thread about gatewaying 
S/MIME messages between X.400 and SMTP resurfaced about every 6 months.
Apparently some deployments even had running code that allowed this - 
problem was that you had to have a MIME parser in X.400-land to make sense 
out of the content.

we seem to have MIME parsers running out of our ears all over the place 
anyway, so there might be a chance it could work...

                Harald

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Nov 2002 06:47:10 -0500

>ahhh.  that explains why the IP hourglass model doesn't work

Actually, I think that hourglass model doesn't work because
it is very hard for consensus-based organizations to exercise
discipline.  I'm still trying to figure out a way to make
engineering discipline seem as enticing as chasing every
new (good or bad) idea that comes along.

...but, that's pretty off-topic. :-)

Margaret

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Nov 2002 06:27:15 -0800

> ...but, that's pretty off-topic. :-)

imiho, that should be highly on topic for the wgchairs list

randy

---

From: avri doria <[email-masked]>
Date: Sun, 24 Nov 2002 03:15:23 +0100

I think the majority were attendees, though often they
were in another meeting at the time.  During the iesg
plenary I think all but about 4 or 5 were in the room.
I don't think this this necessarily makes it less of
a success as an experiment.

However, I think that we may end up seeing an unintended
consequence from this.  Some of the background conversation
among the attendees was interesting and some was even useful.

One thing I do know, being scribe is hard.  And getting
all the conversation even close, with names, is a real
challenge. I did the iesg-pelanary.  And in addition to doing,
at best, a mediocre job, I was so busy trying to type, I had
no chance to really pay attention to what was being said or to
think about it.

a.

-- 
Avri Doria
http://www.sm.luth.se/~avri/

---

From: Dean Willis <[email-masked]>
Date: 25 Nov 2002 13:37:05 -0600

> no chance to really pay attention to what was being said or to

We tried to use the chat rooms as more of a "back channel" with the
assumption that MBONE would provide the primary channel for remote
participants (and yes, I know that's unlikely -- I've never actually had
an MBONE connection, despite once being involved in the largest
commercial multicast network in production).

I asked the chat-coordinators in my meetings to limit their reporting of
in-meeting activity to introducing current topics as the meeting
advanced through its agenda. Their main task was to bring questions
asked in the chat room to the microphone should there be a need to do
so. There apparently wasn't any such need, as there appear to have been
no remote participants in those meetings.

--
Dean

---

From: [email-masked]
Date: Mon, 25 Nov 2002 11:11:48 -0800 (PST)

> problem was that you had to have a MIME parser in X.400-land to make sense

FWIW, my experience was more or less the dual of this. Specifically, I saw zero
willingness to augment X.400 implementations with MIME capability. What
happened in the situations where I saw where the gatewaying issue come up was
the deployment of X.400 content handlers in the MIME world. 

> anyway, so there might be a chance it could work...

I'm still on the fence on this whole issue.

On the one hand I'm acutely aware of the fact that past attempts to get end to
end security to deploy have been largely unsuccessful. This means a possible
outcome of mandating some specific form of end to end security will either be
that we are ignored or that end to end security gets deployed but is
unused/unusable in practice.

It is also possible that end to end security may deploy selectively, that is,
it works in the homogeneous case but can't be used when gateways to
environments that use other formats are involved. And finally, it arguable that
this will become a case where the best is the enemy of the good: To the extent
that a focus on end to end distracts us from hop by hop schemes (which we have
ample evidence are deployable) we may end up with less overall security, not
more.

On the other hand, end to end security is clearly valuable in its own right and
clearly something many people want. Additionally, solutions to the problem
surrounding secure group conferencing may depend critically on having end to
end security facilities in place. And as Harald points out above, format
tunneling, although messy, may be an option for some gateways.

It is also arguable that both end to end security and hop by hop security are
needed, the former for privacy and the latter to defend against traffic
analysis, so the argument that focusing on one would lessen the focus on the
other isn't valid and we might as well try to both even if we end up with only
one.

So how do we proceed from here? I'd like to suggest that instead of continuing
to debate the efficacy of end to end security we instead turn our attention to
assessing why end to end security hasn't deployed in the past and what, if
anything, we can do to make it work this time. I think there are a lot of
assumptions built into the positions of both sides of this debate and we need
see if those assumptions are valid.

				Ned

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Nov 2002 11:50:18 -0800

what is the real/main channel in the meeting?  i contend it is the
voice/face channel.  after all, if it was not, we would not be
there.

the chat channel is a back channel.  and, having a few minutes to
look at the recorded chats [0], it is very sketchy and even then
varies greatly depending on the 'scribe'.  i would guess is has 10%
or less of the fidelity of the voice/face channel, even when there
is a scribe.

so, the chats are great for a back channel, and i do use them for
private back channels during conf calls and meetings.  but they
don't cut it by a long-shot for the main channel, and certainly not
for the remote participants or delayed (passive) participation.

randy

---

[0] - circumstances forced me to leave atlanta on saturday before
      the meeting

---

From: Dean Willis <[email-masked]>
Date: 25 Nov 2002 16:10:33 -0600

> see if those assumptions are valid.

Right on!

I'd personally take e2e security a lot more seriously if we (the IETF) actually 
used it ourselves.

One of our time-suckers is mailing list management. We get spam and viruses,
so we implement semi-closed lists requiring list membership in order to post.
Even then we still get spam, as some of the spam sourcers know how to send a
"subscribe" request. Of course, non-subscribers who are participants in other 
parts of the IETF process (such as IESGers or secretariat or people in other
groups) DO occasionally need to post, and the semi-closed lists require their 
messages to await approval by a list admin who might well be on a two-week
vacation, which is badness. Then there are the viruses and worms and . . .

Suppose instead we "drank our own kool-aid" and required S/MIME signing of all
messages posted to IETF lists, and had server validation of the signing with a 
policy that allows known IETF participants to post or subscribe to any IETF 
list. 

Unsigned stuff could still go to a moderator, who would help the sender get
properly registered.

This raises lots of questions, like what exactly would the policy be, and how
would we manage the cert distribution, etc. But it IS a fairly closed problem
space, and I suggest that if we can't solve the problem in this contained space,
then we have no business mandating that ANY protocol use e2e security.

There's also the vague possibility that by ATTEMPTING to use e2e security,
which nobody really uses, that we'd learn something about the practical
aspects of reality and learn to write BETTER security mechanisms.

--
Dean

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Nov 2002 18:06:58 -0500

>aspects of reality and learn to write BETTER security mechanisms.

The IETF list is NOT an example of an easy context in which to use 
signed messages. it is not a closed list within a company where a 
single CA might issue all the certs to users and a central IT 
organization might be able to ensure that all mail clients had S/MIME 
capability. Instead what we have is almost the hardest possible 
context, where every possible mail client is in use by some IETF list 
member, there is no single CA appropriate for all the participants, 
who, in turn, represents thousands of companies, ...

So I have to disagree with the suggestion that this would be a good 
environment to show how easy it is to use signed e-mail.

Steve

---

From: Melinda Shore <[email-masked]>
Date: Mon, 25 Nov 2002 18:23:06 -0500

I don't think it's that mysterious - we have a big problem
with secure credentials provisioning and management.  In
terms of rigor, I think we're already seeing some headway in
that there seems to be greater willingness on the part of
the security ADs and security-wise IAB members to compromise
a bit, allowing slightly weaker security in favor of
slightly greater deployability.  I wouldn't want to go too
far in that direction but I think there's clearly no risk of
that.

Melinda

---

From: Derek Atkins <[email-masked]>
Date: 25 Nov 2002 18:49:15 -0500

> environment to show how easy it is to use signed e-mail.

Sounds like the perfect environment for a PGP solution :)

Seriously, we don't need strong trust for this to work -- we just need
to add a hurdle large enough to get some security but enough that the
spammers can't get it.

For example, the list could be "gain unmoderated posting ability by
'subscribing' with a PGP Key".  Messages signed with one of these
"subscriber" keys get passed through.  Unsigned messages await a
moderator.

Sure, this doesn't give us end-to-end encryption, but it does give us
end-to-end origin-linkability.

-derek

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 25 Nov 2002 16:10:49 -0800

>far in that direction but I think there's clearly no risk of

The needed change isn't to "slightly weaker security", it is to "less 
rigorous authentication". Unfortunately, authentication is 
all-or-nothing. Either you can validate the signature on the message 
(based on hierarchical trust or web of trust), or you can't.

If you get a message whose signature is based on a public key that 
you have no reason to believe, you either throw it away or you read 
it anyway. Doing the former prevents new people who aren't yet part 
of the trust scheme to send mail to you; doing the latter is no 
different than what we have today, with the slight exception that 
there is now a big red "X" in your GUI for the message.

The bigger question is: why should we authenticate email in the IETF? 
Are the benefits of rejecting unauthenticated email greater than the 
costs? I believe the answer is "no", and will always be "no" if we 
want new people to be able to join conversations easily and if we 
want to be able to post messages from multiple mailing addresses as 
we travel around.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 25 Nov 2002 17:30:15 -0700

I agree that the IETF context is not an easy one, but it *is* the
canonical example of where certs and sigs *should* be easy, if that
kind of authentication is to be useful wrt the Internet.

IF I could manage my IETF list subscriptions based on a public key,
even a self-signed one, and if I could have my email accepted based on
a sig using that key, then I'd be a happy camper.  If the IETF would
be so kind as to issue me a cert, I'd be happy to use it to manage my
email subscriptions and to sign messages.

Whatever process accepts an arbitrary character string as the email
address of "a known IETF participant" can certainly translate to a
process that accepts a key for use in authenticating the known
participant.

Yes, PGP can be used for the keys.  Are there servers that can handle
the validation-before-publication and tools that allow users to
manage their subscriptions using signature-based authentication?
And why not?

Hilarie

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Nov 2002 16:47:55 -0800

> capability.

good.  because i find the hierarchic and centralized control model
unsuited to much of what i want to do on the internet.  pfui on CAs,
centralized IT departments, and the like.

pem is one of the ideas that did not fly.  try pgp or some similar
non-centralized model.

randy

---

From: Dean Willis <[email-masked]>
Date: 25 Nov 2002 19:10:02 -0600

> environment to show how easy it is to use signed e-mail.

Well, it's transformable. For example, we COULD set up an IETF CA. 
I bet we could even convince the big CA-players to help out.

And if you have a non-conformant email client, well, you have a 
non-conformant email client. I'm sorry, you'll have to get a real 
one. That's what we have to tell people who say they can't get S/MIME 
into their SIP systems. Why shouldn't we say the same about email?

What's the good of a mandating a standard that we aren't willing to use?
Isn't it worth some pain and some sacrifice to make it happen?

Or we COULD stop mandating it if we realize it isn't really achievable.

Obligatory problem statement:

Problem: The current process tends to mandate "best of breed" features in
all work items. Sometimes, that's good. Sometimes, it's bad. We have no 
mechanism for telling the difference beyond rough consensus and running code, 
which we ignore at our peril. 

--
Dean

---

From: Melinda Shore <[email-masked]>
Date: Mon, 25 Nov 2002 22:44:46 -0500

> And for my part I'm quite happy that IAB is not involved in
> approving IETF standards.

One IAB member in particular is reviewing security issues in
transport area documents.  It's been enormously helpful, and
while I don't think anybody misunderstands that there's a
formal approval process here, his advice is being treated as
consequential to the process of getting documents done.

Melinda

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 26 Nov 2002 10:35:12 +0100

--On mandag, november 25, 2002 16:10:49 -0800 "Paul Hoffman / IMC" 
<[email-masked]> wrote:

> The bigger question is: why should we authenticate email in the IETF? Are
> the benefits of rejecting unauthenticated email greater than the costs? I
> believe the answer is "no", and will always be "no" if we want new people
> to be able to join conversations easily and if we want to be able to post
> messages from multiple mailing addresses as we travel around.

another question is "why not".

The mailer I'm currently sending from checks PGP signatures on mail. It 
loses me about half a second for each signed message, and a dialog box I 
have to dismiss when I get a signature I can't validate.

Is that a big enough cost not to do it?

This message is signed....

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 26 Nov 2002 14:21:05 -0800

At 10:35 AM +0100 11/26/02, Harald Tveit Alvestrand wrote:
>The mailer I'm currently sending from checks PGP signatures on mail. 
>It loses me about half a second for each signed message, and a 
>dialog box I have to dismiss when I get a signature I can't validate.
>

No, but those aren't the only costs. If everyone keeps dismissing the 
dialog box mindlessly, we get used to it and may dismiss it when the 
authentication becomes more important. If we require that mail be 
signed but show absolutely no regard for the signatures, it indicates 
that the act of signing someone else's keys is a joke.

Further, signing capability is not easily added to all mail user 
agents. Users of PGP plug-ins are familiar with having the plug-in 
fail for no apparent reason (and having no tech support), having 
problems updating from one version of their mail software to another, 
and so on. Saying "we insist that you add this feature even though we 
are not serious about it, and doing so will be a pain in the ass for 
about 20% of you" is not a good thing.

This is completely the wrong way to get people to think about the 
value of signing and encrypting messages. A much better idea is to 
have groups that have even minimal need for authentication (such as 
the IESG, the IAB, and the IETF Secretariat) to do so and report 
honestly on the experience. There was anecdotal stories of companies 
trying this a few years ago, mostly reporting lots of failures and 
lack of need; this was true for both hierarchical and web-of-trust 
authentication.

--Paul Hoffman, Director

---

From: Stephen Kent <[email-masked]>
Date: Tue, 26 Nov 2002 17:32:07 -0500

>I bet we could even convince the big CA-players to help out.

the IETF is a good reference for identifying me as a Wg chair, but 
we've always had a problem defining who is an IETF "member" in  a 
fashion that is rigorous enough to warrant issuing a cert. also, 
there is a cost associated with issuing certs, mostly in terms of 
labor. how will it be paid for in a fashion that does not favor any 
specific CA service/technology vendor?

>into their SIP systems. Why shouldn't we say the same about email?

I have three responses to this:
	-= experience shows that people become attached to their 
e-mail clients and and not readily to change in order to use secure 
e-mail
	- who died and appointed you arbiter of acceptable e-mail clients?
	- since when is Eudora (for the Mac) not a real e-mail client?

>Isn't it worth some pain and some sacrifice to make it happen?

I'm all in favor of pain and sacrifice for a good cause. signing 
e-mail for the IETF list doesn't cut it.

>Or we COULD stop mandating it if we realize it isn't really achievable.

As I noted, there is a big difference between using any security 
technology in a closed, tightly managed context, vs. a very open one. 
it is silly to argue that this technology is not useful unless it is 
readily deployable for what is arguably the hardest type of context.

Steve

---

From: Derek Atkins <[email-masked]>
Date: 25 Nov 2002 19:54:44 -0500

> manage their subscriptions using signature-based authentication?

There have been, yes.  I've seen a few PGP-based mlm systems (pgpdomo
was the first, and I've heard of others).

-derek

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Nov 2002 20:20:46 -0500

> far in that direction but I think there's clearly no risk of

A sidebar on roles & responsibilities:

Folks might want to peruse the IAB charter (documented online
in an RFC).  IAB does not have a role in approving standards;
at least since 1992 that is an IESG-only function.  So IAB
isn't really in the decision tree about when to "compromise
a bit" or not in the IETF standards space.  IESG folks make
those decisions.  IAB does hear an appeal of an IESG decision,
after several other levels of appeal have already occurred,
but that's it for IAB involvement in what does/doesn't become
an IETF standard.

(personal opinion)

Speaking for myself only,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Nov 2002 20:20:46 -0500

(personal opinion)

Ran

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 29 Nov 2002 22:08:23 -0600

> 	- who died and appointed you arbiter of acceptable 

The God of Security, apparently . . . ;-)

Seriously, we're a bunch of hippocrites, asking the world to change and
embrace security when we're not willing to do it ourselves. Two ways to
fix that -- either change, or stop asking the world to do so.

But this has gotten far afield, so I'll try and shut up now, at least on
this idea.

--
dean