ietf-smime
[Top] [All Lists]

RE: application/signed vs. application/mime vs. signedData

1997-08-03 10:27:59
Whether or not multipart/signed is recent or not is irrelevant. It didn't
contain any language about gateway conformance. As such, it was simply 
ignored
by the customers seeking compliant gateways and hence it was also igored by
the gateway development community.

Right, and now that at least three secure mail specifications are using
it, customers will start asking for it, and gateways will start
implementing it.  I don't see how gateway-specific language would change
the adoption rate.  The market demands the change, which is what you're
pointing out.

My experience says otherwise. I've run into many cases where gateways don't
handle various things properly, including but not limited to multipart/signed,
and when taxed with this by customers the gateway vendor simply said "show us
the standard that says we have to do this". Long silence, followed by an
admission that the functionality isn't required, at which point the vendor says
"we'll put it on our may implement someday list, nice talking to you". And the
person who wants the functionality, who happens not to be the ones who operate
the gateway, says "that's unacceptable, change the gateway". But the people
running the gateway say "sorry, since functionality you're asking for is a nice
to have feature, not a mandatory one, we're not interested in changing gateway
products to get it".

I've seen this scenario played out countless times in the marketplace. As I
said, I have 15 years of experience in the gateway market, so I think I know
what I'm talking about.

The problem here, of course, is a chicken and egg one. If there was serious
market pressure to deploy security services across gateways the vendors would
of course change their practices. But such pressure only arises _after_ such
services are deployed to some extent. And we cannot get deployment in place
without first getting some amount of deployment of security-capable gateways.
It's a loop, and the only way I know of to break it is through the standards
process. I originally got started doing standards because I realized this, as a
matter of fact.

The past five years of near-total non-deployment of security services
illustrates this point rather nicely. And do not confuse pressure in the market
for security services with pressure for secure end-to-end email. The market
isn't that aware of the issues. So what we're seeing deployed isn't end-to-end
services, it is stuff like encrypted tunnels and (soon) SSL/TLS secured email.
And no, from a security standpoint these solutions are inferior. But the market
doesn't see it that way. If we're to have any chance of getting end-to-end
security for email widely deployed we need to address the issues gateways bring
up.

Now, if I thought that use of application/[s]mime would enable enough
deployment to create the market and break us out of loop we're in I would
support it a lot more than I do. But I don't think it is sufficient to have
this effect. What we really need is to define gateway compliance. I believe
this will get us enough deployment of capable gateways that we'll then be
able to create the critical mass to change the rest of them.

And why not put in client-specific language also?  Or X-specific
language, where X is some other faction of the overall Internet
community?

Because we already have client-specific language. The language in the
multipart/signed document specifically deals with what a conformant client must
do. So if I build clients I might actually care about this. Now, I happen to
think the language is inadequate in several ways (in particular, it doesn't
deal with the case where the verifier is separate from the client and what the
security concerns in this case are), but what's there is all we could get
through the process. We used to have more specific and detailed requirements
but the WG had us remove them.

I don't understand why the consideration is to the gateway,
and yet the client is not important to consider also.

The client is equally if not more important. But we've addressed the client
already, in detail. And we haven't said a single, solitary word _anywhere_
about gateways.

Or the international concerns.  Or whatever.  The reason why gateway-specific
issues can get passed over is because they are specific to some faction,
regardless of its size.

Blake, you lack the experience in the process to make such assessments. And you
are simply wrong about this: The reasons gateway issues get passed over in the
IETF are complex, but they do not include the notion that they are specific to
a particular faction. In fact I would argue that gateways are by definition not
a single single faction -- this is part  of the problem dealing with them. But
in any case, dealing with faction-specific issues in the IETF all the time and
in fact have no problem in doing so.

But even if this was true, so what? The point is that this WG has identified a
problem that manifests most prevalently in gateways. But rather than try and
solve the problem, the group seems intent on building more infrastructure that
_will_ _not_ _solve_ _the_ _problem_. Why not simply deal with the problem?

This of course begs the question of why the IETF hasn't dealt with gateways at
all. One of the primary reasons is obvious: Gateways by their very nature
restrict services to the intersection of the capabilities of the environments
they interconnect. This is unpleasant, and to a bunch of engineers who work
very hard to develop services in a particular arena, this is in effect and
attack on what they do, and one which they regard as evil. (I've lost track of
the times I've heard IETFers speak of gateways as evil.) And the obvious
solution is to avoid them, on the principle of "lie down with dogs get up with
fleas", and to instead stick to our little mostly-standards-compliant world of
IP/TCP/SMTP/MIME or whatever.

For example, Donald Eastlake has been trying literally for years to get a
specification covering the issues that arise when security services are
provided at an intermediate point rather than an endpoint. I chaired one such
session, and I quickly learned that the G-word would bring us a veritable
hailstorm of protest. The amount of fancy footwork I had to do as a result
literally left me gasping.

As soon as you introduce faction-specific
language, you are inviting every other faction to participate in the
same process.

Again, so what? What faction are you worried about? The fact of the matter
is that I would _welcome_ the opportunity to address additional issues that
cause interoperability problems.

You and I are both capable of writing informational RFCs that document
the support that some faction should have for some RFC.  Anything else
written by an original author of an RFC should carry as much weight as
the original RFC, but I might be mistaken.

I think you are mistaken, unfortunately. There are people out there who don't
pay attention to an RFC's standard's status. But when a vendor is asked to
implement something in an RFC they absolutely do pay attention, because they
have lots of things to do and they have to prioritize. And implementing the
random raving in an informational RFC gets low priority. And an informational
document will be ignored.

I certainly associate a
certain brand awareness with Dave Crocker's work, Nathaniel Borenstein's
work and your work, so anything that these people write carries with it
the expertise that I expect.

I have not noticed this phenomenon to any significant degree. And I think
I should be the one who is able to tell... Not that it doesn't sound nice...

If there's a significant number of gateways that support MIME but have now 
been
abandoned I am unaware of their existance. And I deal with gateways at
thousands of customer sites on a dailly basis. If you have specific examples
I've love to hear about them, but until I see a list of such gateways I'm 
not
inclined to believe in their existance, much less their widespread 
existance.

I'm referring to the AOL, MCI, CompuServe and other online service
gateways.

I have first-hand knowledge of one of these and second hand knowledge of the
the other two. And that knowledge says you're wrong about one of them (I am
under nondisclosure so I cannot say which one) and that it will in fact be
transitioning to software that handles multipart/signed correctly, largely
because of standards compliance issues. As for the other two, while my
knowledge is second-hand, I have found both of them to be quite responsive to
compliance to standards-track IETF documents, and I suspect that they would
rapidly deploy a compliant solution if there was any standard to conform to.

As such, I know you are wrong in your assessment here in one case and believe
you are wrong in the other two cases.

"Abandoned" is too strong a word, and I apologize for its
use.  Let's say "conservatively modified".  They cannot handle
multipart/signed right now, since they treat multipart/signed as
multipart/mixed, and the original MIME data is lost on the way to the
client.  These gateways are not significant in number, but are
significant in customer base.

Far from being abandoned, these are all gateways in active development. And if
the standards said that gateways need to provide the option to tunnel
multipart/signed I know one of them is already on this course and I believe the
other two would be as well if there was a standard to back it up.

You cannot make a sweeping generalization about an entire market and
claim that because of your experience that no one in that market will
ever care about something, or that you have enough of a pulse that you
can say definitively without hesitation that no one cares about that
thing now.  We have dozens of customers that are lining up and buying
our gateway product *EXPLICITLY* because of our consideration for S/MIME
digital signatures.

I never said that nobody cared. Of course some people care, and I'm sure you
have customers lining up and so on.  I also have customers who care about this
stuff, for that matter. I would probably have imlemented proper handling of
multipart/signed in our products without them, but it was nice to have a
business justification for it.

But this is beside the point. A standard for secure email isn't successful if a
few people line up to buy into it. It is only successful if it is widely
deployed. And what I was saying is I have a nontrivial number of customers who
not only aren't jumping on the signedData bandwagon, they will be actively
hostile to the signedData approach and will go out of their way to deploy
solutions that wreck it. Not only do I have such customers, I have a lot more
of them than I have that fall into the "security first, readability second"
camp.

Please, be very, very careful about your adamancy.  I qualified my
statement as being my opinion, yet yours went so far as to put two
qualifiers to emphasize how wrong I was.  The customers you talk to
don't care, the customers we talk to do.  I consider at least some of
them to be in the same market.

The problem is that you only talk to the customers who are at least partly sold
on end-to-end security as the right thing to do. But this entire effort depends
on the willingness of those who are not sold on your program to come to the
table as well. The nature of my business, however, is that I talk to every type
of gateway user you could imagine (and probably some nobody could imagine -- I
certainly couldn't have dreamt them up). This is why I claim that my
perspective is better than yours on this issue.

No one said that it would require a superhuman level of intelligence to
implement the ripping of the MIME data out of signedData (I'm a Pretty
Smart Guy myself, and given something with similar complexity to PKCS
#7, I could probably figure out how to get the MIME out if it too).  The
point is that when you *do* implement it, you have identified it as PKCS
#7, and then gotten the PKCS #7 spec.  And then you have determined that
it is digitally signed data.  And then you have ripped it apart without
thinking "gee, maybe someone had a reason for sending this, and I should
incorporate some new level of intelligence in my gateway product for
dealing with data of this type, since the universe is now changing to
start using digital signatures".

I don't get paid to think this way. I get paid to solve problems for gateway
users. And if signedData presents a problem I will solve it in the fashion the
customer wants. And while I might be able to stave off a few of them with a
standard that says "gateways should not do this", without one I don't have a
leg to stand on.

And I'll tell you something else. There's a phenomenon here that I simply do
not understand, yet I've observed time and again to be true. The customers who
want proper handling of security services seem to have a significant degree of
overlap with the ones who cannot change out a gateway that doesn't handle
multipart/signed properly for one that does. But the customers who want things
to "just work", even if it compromising security services, are the ones who
will drop us as a vendor in a heartbeat even if what we're asked to do utterly
compromises security. I don't know why this alignment occurs, but it does.

And when you do strip off the signature, we have a phone also.  And the
customer on that phone will say "what happened to our signatures" and
we'll say "some gateways like to yank apart our signedData messages
which trashes the signatures", and they'll say "but it's because we want
to scan for viruses" and I'll say "they can scan for viruses and do
other things, and in the event that no content needs to be modified,
they can send the original message through.  However if they need to
modify the content such as removing a virus, then by definition you
cannot have valid digital signatures, so the signature is useless
anyway.  What kind of a gateway would remove the digital signature when
they didn't perform any content modification?"  And when they get mad
because they can't have virus scanning and digital signatures at the
same time, I'll say "but of course you can if you buy our gateway
product that does both!"

You're arguing something I never said (or at least never intended to
say). I brought up the point about virus scanning in response to your stated
intention to use encryption as a means to thwart gateway translations. In
looking back over my message I see I associated it with multipart/signed as
well. BUt that's incorrect -- I meant to associate it with encryption, not
signature. A gateway cannot take apart an encrypted object to scan for viruses
without the keys, and many companies have policies against using encryption
because of this. And this makes your approach of using encrypted data a
nonstarter for many people.

As a matter of fact our gateway can scan multipart/signed for viruses. And
multipart/encrypted for that matter if the necessary decryption software and
keys are available.

You are saying that your customers are more important than our customers
-- that the recipient mail gateway customer is more important than the
sender mail client customer.  This is subjective, and I suspect that it
isn't a good point to discuss, since it is futile.  I appreciate your
loyalty to your customers, as I hope you appreciate mine.

This is not what I'm saying at all. I'm saying that the success of a secure
email solution depends on widespread buy-in, the existance of a significant
faction in the industy that will oppose a particular solution is a compelling
reason not to adopt that solution, and that my experience indicates that
such a group does in fact exist.

Nor do I claim that a standard for gateway behavior will solve the problem
completely. It won't. But make no mistake about it: It does provide a very
powerful tool and it _will_ change the shape of the marketplace significantly.

The one difference between Innosoft and another gateway vendor is that we'll
take care to implement the right sorts of tunneling options as well as
signature removal options. Other vendors will not do this.

I'm glad you do, and as a scumbag client that always tries to thwart
you, I thank you.  The other vendors that you refer to don't do this --
at their own peril (the suicide that I mentioned).  These vendors are
part of the market that we can sell our gateway to, I will enjoy
participating in it, and I thank them for creating the market.

I've been trying to sell things this way for years. Sometimes it works and
sometimes it doesn't. But it works a heck of a lot better if there's a standard
to back it up with.

You seem to be arguing that such a standard will have some sort of harmful
effect. But you haven't given specifics as to what the harmful effect will be
other than to say that dealing with the "gateway faction" will cause us to be
deluged with work from other, unspecified factions.

Once again, "Standards Track" is just as good as "STD" for me.  Is that
what you mean by telling them that they have to implement it?  The fact
that the word "gateway" doesn't appear in the document doesn't have
anything to do with it, in my opinion.

On the contrary, it has everything to do with it. People have little check
boxes for standards compliance and will buy software on the basis of what boxes
get checked. And a gateway can claim full compliance to the security multiparts
standard and not handle multipart/signed correctly. And if you take issue with
them and say they were lying (actually this will never happen because the
customer just bought the other product and not yours and you don't know why),
they will counter by saying "show us the place that the specification says
gateways are supposed to do such and such".  And you won't be able to.

Creative reading of standards is real problem, and it is our job to make it as
hard to do as we can.

If you are implementing MIME
stuff, then you must follow, understand, and accommodate the RFCs that
deal with MIME stuff.  Whether you are HTTP, a gateway, a mail client, a
mail server, or a MIME filesystem (sorry, ran out of examples), you must
understand and potentially interpret these documents in a way consistent
with your customer's goals, and consistent with the philosophy behind
those RFCs.  multipart/alternative is *completely* different than
multipart/mixed which is *completely* different than multipart/signed,
and everyone damn well better understand that.

All this "truth, justice, mom and apple pie" stuff sure is nice, but I'm sorry
to say that I don't find very much of it out in the real world.

I think what we're talking about is the slow adoption of a particular
standard.

No, the adoption by gateway vendors has for all intents and purposes been
instantaneous. This is because security multiparts imposed absolutely no
additional implementation burdeon on them at all. And this is the real
problem -- it should have.

The problem with RFC 1847 isn't that it isn't far enough along on the 
standards
track, it is that it doesn't impose any requirements on gateways. In fact 
the
word "gateway" appears nowhere in the document. Nor does the word "tunnel". 
(I
believe both of these words used to appear but the entire discussion got
removed because that's what the PEM WG wanted.)

I'm upset that the concept was removed.  I believe that you are correct
that the gateway tunneling should be considered, since I believe that we
are trying to solve that very problem with signedData, application/mime,
and application/signed.  If I were around for that discussion (before my
time, alas), then I would have participated in favor of a tunneling
mechanism.

I sure could have used your voice at the time. At the time I was the only one
saying this. (Jim Galvin, Steve Crocker, and the rest of the TIS crew also said
it but he came into this game somewhat late and by the time he was involved it
was mostly over.)

There is no such text in RFC1847. The text that is there talks specifically
about message transfer agents not altering the content. But an MTA isn't a
gateway. They are different things. As such, this text cannot possibly be 
read
to impose any sort of restriction on a gateway. A gateway can in fact claim
full compliance with RFC1847 and do whatever it likes with multipart/signed.

So what you're saying is that because RFC1847 does not explicitly call
out the fact that the content and the signature must be passed intact
through the gateway, that's why gateways don't do it?

Close. I'm saying this is why gateways haven't had to do it. They originally
didn't do it because most of them were in development before mulipart/signed
even existed. But when it came out they looked and found nothing new to
implement.

It seems to me that the interpretation really needs to be left up to the
gateway.  As you have pointed out before, some users behind a gateway
couldn't care less about the signature, and want the content.  As I have
pointed out, some users behind a gateway care explicitly about the
signature.  This is a semantic that must be enforced by the gateway, and
is specific to the market in which the gateway vendor wishes to
participate.  This can't be dictated in faction-specific language in the
RFC, can it?  

Sure it can. A specification can say that a gateway may be called upon to
provide access to content for security-incapable clients as its primary goal or
security tunneling as its primary goal, that you cannot have both, and as such
a compliant gateway MUST implement both options, and SHOULD allow option choice
on  a per-destination basis.

Specifying that certain options be implemented is done routinely in IETF
standards. There is simply no problem with having such language in a standard
and writing it is easy.

How will the customer be served by that?

The text I've suggested above would be the single best thing that has happened
to gateway users in a standards document in years.

And these provisions that you speak of for dealing with MIME at the
gateway should provide for the basis for your informational RFC.  I
suspect that it cannot be standards track, because it tarnishes The
Vision, and will prolong the amount of time that it takes for us to
reach it.

If I thought an informational document would work I would have written one
years ago. My assessement is, and continues to be, that only a standards track
document will work, that this vision stuff you talk about is largely
irrelevant, and that the only real problem with getting such a document through
the process will be: the knee-jerk response to talking about gateways in a
standard.

A document which talks about removing encryption at the gateway, on the other
hand, would be problematic, because such removal obviously compromises
security. (I nevertheless think such a document should in fact be written, but
I doubt if it stands any chance of making it through the process if it is.)
Removing a signature on the other hand, doesn't compromise anything per se --
it may compromise functionality, but not security.

To a certain extent, I think you are beating yourself up because you
have not been able to change human / business nature.  When push comes
to shove, someone can simply ignore or misread a document that says how
you should do something.  You can document something until you are blue
in the face, and it still won't get implemented right.

I'm not beating myself up on this issue at all. What I am doing is beating on
the IETF for having failed to deal with this issue and continuing to think that
more messing around with solutions like application/[s]mime and signedData will
accomplish something. My assessment is that it won't, and as such I do not
support the development of such things. MInd you, I don't oppose them either
(actually I do oppose signedData but as its already basically a nonstarter my
support or lack of it is irrelevant) since I think they're mostly harmless.

                                Ned