Subject: Updating the rules?

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jul 2007 09:29:09 +0200

I posted draft-carpenter-rfc2026-changes-00.txt at
Russ Housley's request. Obviously, discussion is very much
wanted.

     Brian

http://www.ietf.org/internet-drafts/draft-carpenter-rfc2026-changes-00.txt

    This document proposes a number of changes to RFC 2026, the basic
    definition of the IETF standards process.  While some of them are
    definite changes to the rules, the intention is to preserve the main
    intent of the original rules, while adapting them to experience and
    current practice.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 06 Jul 2007 08:05:09 -0700

>     intent of the original rules, while adapting them to experience and

In:

3.  Detailed Proposals for Change

Acronyms could be structured to clarify extensions versus stand-alone.

Perhaps acronyms could look something like:

SMTP
SMTP/Text-Format
SMTP/Host-Reqs
SMTP/Msg-Size
SMTP/Anti-Spam
SMTP/Auth
SMTP/Pipelining
SMTP/Binary-Mime
SMTP/TLS
SMTP/DSN
SMTP/Multipart
SMTP/Enhanced-Status
SMTP/Ext-DSN
SMTP/Auto-Response
SMTP/Submission 

-Doug

---

From: "Robert Sayre" <[email-masked]>
Date: Sat, 7 Jul 2007 00:19:43 -0400

>From the draft:
"Is it acceptable if features A and B are shown to be interoperable
between implementations X and Y, and features C and D are shown to be
interoperable between implentations P and Q?"

Yes. The point of the requirement is to identify features that are
unimplementable, for technical or non-technical reasons. The
requirement does not exist to compel implementors to make identical
engineering trade-offs in order to arrive at the shangri-la of
"universal interoperability", where all features are present in all
implementations.

Also from the draft:
"At least for the strong security requirement of BCP 61 [RFC3365], the
Security Area, with the support of the IESG, has insisted that all
specifications include at least one mandatory-to-implement strong
security mechanism to guarantee universal interoperability."

I do not think this is a factual statement, at least when it comes to
HTTP, which is where my interest lies. There are no interoperable HTTP
authentication schemes, and the TLS requirements in drafts I've seen
consist of either obfuscation (recent DAV documents), or a choice
between TLS versions (recent Atompub documents). At least the Atompub
TLS requirements don't mislead implementors too badly.

The text reads "to guarantee". It should read "with the goal of" or
"to guarantee universal interoperability, in theory, by requiring
security mechanisms that won't be used in practice."

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Jul 2007 02:30:55 -0400

> HTTP, which is where my interest lies.
note that it is not necessary to have at least one
mandatory-to-implement strong security mechanism to guarantee
interoperability.  consider, for example, a client-server protocol for
which conforming servers are required to implement
_two_ strong security methods and for which clients are required to
implement _at least one_ of those two methods.  this
would ensure interoperability even though there were no single
mandatory-to-implement for clients.

depending on the circumstances, putting a greater burden on the server
than the client, or vice versa, might make sense.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Jul 2007 08:54:14 +0200

> than the client, or vice versa, might make sense.

As far as 2026bis goes, my idea would be to have language that defines
the bounding requirements. There are specifics in BCP 61 = RFC 3365
which would be out of place in 2026bis.

In the above quote I would suggest
s/to guarantee universal interoperability/in the interests of universal interoperability/

     Brian

[email-masked]>
Date: Sat, 07 Jul 2007 08:54:14 +0200
From: Brian E Carpenter <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: IETF discussion list <[email-masked]>
Subject: Re: Updating the rules?

> than the client, or vice versa, might make sense.

As far as 2026bis goes, my idea would be to have language that defines
the bounding requirements. There are specifics in BCP 61 = RFC 3365
which would be out of place in 2026bis.

In the above quote I would suggest
s/to guarantee universal interoperability/in the interests of universal interoperability/

     Brian

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 07 Jul 2007 18:36:40 +0900

> mandatory-to-implement strong security mechanism to guarantee

What, do you mean, strong security?

Given that CAs of PKI can be compromised as easily as ISPs
of the Internet, PKI is merely weakly secure as weakly as
the plain Internet.

						Masataka Ohta

---

From: Eliot Lear <[email-masked]>
Date: Sat, 07 Jul 2007 12:18:50 +0200

[I should know better, but...]

> of the Internet, PKI is merely weakly secure as weakly as

This can be said of any technology that is poorly managed.  On the other 
hand, can you cite examples of a well known certificate (say one that I 
might have found in Mozilla, Netscape, Firefox, etc) that has actually 
been compromised?  I know of precisely one example.

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 07 Jul 2007 19:58:29 +0900

> [I should know better, but...]

That's your problem.

> This can be said of any technology that is poorly managed.

So, you merely believe that the infrastructure of PKI is well
managed.

That's exactly why PKI is NOT strongly secure.

You can believe that the infrastructure of the Internet is well
managed, eaqually easilly.

> On the other 
> been compromised?

Can you cite examples of a tier1 ISP that has actually been
compromised for active attack against DH?

> I know of precisely one example.

That's a lot more than enough.

							Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Jul 2007 07:21:25 -0400

> What, do you mean, strong security?
valid question.  but that's a can of worms.
> of the Internet, PKI is merely weakly secure as weakly as
only if those CAs are stupid enough to connect their certificate signing
machines to the Internet.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 07 Jul 2007 06:43:18 -0700

Robert Sayre wrote:
> HTTP, which is where my interest lies. [...]

On the other hand, I've seen with SIP where forcing the working
group to do this has been extremely counter productive. The reason
is that since it was backend loaded, ramming in S/MIME and TLS
was rife with mistakes and in the case of S/MIME was a solution in
search of a problem. Since we're talking about how things actually
turn out from process, it would be good to acknowledge that the
process in this particular case was ultimately counter productive:
instead of taking the time to get security right, we institutionalized
incorrect/non-interoperable behavior.

I seriously doubt that SIP is the only offender here as general clue
as to how to do this right is still arguably lacking, and it most
certainly doesn't get done in a fevered month before last call. IMO,
the process needs to take into account the reality of when we are
trying to graft security protocols onto implemented/deployed
protocols like SIP, SMTP...  It's an effort unto itself and needs
to be carefully considered, and hopefully by a group of people
whose goal is to make something that's _useful_ and _interoperable_
rather than just squeaking through the IESG mandated process.

       Mike

---

From: Sam Hartman <[email-masked]>
Date: Sun, 08 Jul 2007 19:58:40 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    >> Also from the draft: "At least for the strong security
    >> requirement of BCP 61 [RFC3365], the Security Area, with the
    >> support of the IESG, has insisted that all specifications
    >> include at least one mandatory-to-implement strong security
    >> mechanism to guarantee universal interoperability."
    >> 
    >> I do not think this is a factual statement, at least when it
    >> comes to HTTP, which is where my interest lies.
    Keith> note that it is not necessary to have at least one
    Keith> mandatory-to-implement strong security mechanism to
    Keith> guarantee interoperability.  consider, for example, a
    Keith> client-server protocol for which conforming servers are
    Keith> required to implement _two_ strong security methods and for
    Keith> which clients are required to implement _at least one_ of
    Keith> those two methods.  this would ensure interoperability even
    Keith> though there were no single mandatory-to-implement for
    Keith> clients.

The IESG has in fact noted that and brought it up as an option in some
cases.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 08 Jul 2007 20:01:00 -0400

>>>>> "Masataka" == Masataka Ohta <[email-masked]> writes:

    >> mandatory-to-implement strong security mechanism to guarantee

    Masataka> What, do you mean, strong security?

    Masataka> Given that CAs of PKI can be compromised as easily as
    Masataka> ISPs of the Internet, PKI is merely weakly secure as
    Masataka> weakly as the plain Internet.

I'd consider DH a fine strong security mechanism in a number of cases.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 09 Jul 2007 09:05:06 +0900

> How the PKI process is managed is not generally part of the PKI Model 
> itself and that is what most ISP's and Network Geeks totally miss... 
> sorta like you did.

So are ISPs and telcos.

Secure operations of CAs, ISPs, telcos and banks are required by law,
which does not assure they observe legal rules.

> Actually it is... considering how many people use it for business and 
> personal use on a continuous basis.. Its one of the mostr reliable 
> things on this planet today.

So are telephone, financial and most other networks without PKI,
though they are considered weakly secure, which is why strong
security is required by some RFCs.

Even if you change the definition and call them strongly secure,
it does not affect the fact that PKI does NOT make them strongly
secure.

> a few hours as I recal

In general, CRL issue interval is a lot longer than a few hours,
I'm afraid, which is a cryptographical weakness of PKI compared
to shared key infrastructures with KDCs. In that sense, PKI is
less secure than the Internet.

> and no one really got dinged so I would say it wasnt the PKI that
> failed but the Human Operations Processes on top of that...

Human operation is not on top of but within PKI, which is why PKI
is merely weakly secure.

							Masataka Ohta

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Jul 2007 07:34:36 +0200

> So, you merely believe that the infrastructure of PKI is well

In all but a single instance I have no evidence to the contrary.  The 
one case of an exploit was extremely well publicized and ameliorated 
within days.  And that was years ago.

> That's exactly why PKI is NOT strongly secure.

And this is an over-generalization.  DH is or any other technology is 
just as easily insecure if the underlying keys are exposed.
> managed, eaqually easilly.

Some is, and some isn't.  That's my point.  But here's a question: 
what's the exposure in the case where some isn't?

> compromised for active attack against DH?

No, but many have been compromised, whether they used DH (in who knows 
what) or not.  Furthermore, the comparison is not appropriate.  DH is 
merely an encryption method and speaks nothing to how longer lived keys 
are exchanged (or not).

> That's a lot more than enough.

Well, there have been car accidents, train accidents, plane accidents, 
and boat accidents, as well as pedestrian accidents, and the most common 
cause of accident - a kitchen accident.  I take it you stay in your 
bedroom all day?

Eliot

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 9 Jul 2007 23:29:44 +0900 (JST)

> of the Internet, PKI is merely weakly secure as weakly as

	i would not word like this, you are asking for flamewar :-)

	i would say:
	- technologies that use hierarchical structure to combat scalability
	  problem is very tough to make a successful deployment
	- key distribution problem is almost like NP-complete problem, it is
	  way too difficult that you need some assumption to relax it (e.g.
	  ssh first-time contact weak authentication)

	you now know which RFC i do not really love :-P

itojun

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Jul 2007 11:31:34 -0400

>of the Internet, PKI is merely weakly secure as weakly as

The notion of CA compromise and ISP comprise are not completely 
comparable, which makes your comparison suspect.

Also, the security implications of errors (or sloppiness) by ISPs is 
very different from that of CAs, so I don't think your comparison 
makes sense in that regard as well.

Steve

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Jul 2007 12:17:01 -0600

> rather than just squeaking through the IESG mandated process.

As another data point, in the Jabber/XMPP community our experience with
TLS has been quite positive, probably because we were already using SSL
for channel encryption before we formalized the "XMPP 0.9" protocols in
the XMPP WG. So the switch from SSL on a dedicated port to TLS upgrade
over the registered XMPP port was relatively painless.

Unfortunately, our experience with S/MIME has been less positive (and
yes I even use S/MIME for email). In part, that's because it was grafted
on in a way that was unpalatable to the XMPP developer community, with
the result that the relevant specification (RFC 3923) is unimplemented
as far as I know. Perhaps more important, the effort to add end-to-end
encryption proceeded in a way that did not reflect a serious effort to
define security requirements before deciding on a technology. And as is
often the case, deciding on a technology without first defining the
requirements can lead one astray.

I agree that we need to "take the time to get security right"; but I'm
afraid that the time to do so may be measured in years...

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 10 Jul 2007 10:54:52 +0900

> I'd consider DH a fine strong security mechanism in a number of cases.

DH is, though not strong, pretty secure only *IF* you can securely
identify your peer.

If, for the identification, you use plain DNS or, so called secure
DNS, neither of which is strongly secure, TCP sequence number gives
proper level of security.

> comparable, which makes your comparison suspect.

As I already mentioned, social attacks on employees of CAs and
ISPs are equally easy and readily comparable.

> very different from that of CAs, so I don't think your comparison makes 
> sense in that regard as well.

Given the sloppiness of current DNS management, secure DNS CAs, which
is an PKI, will be no different from that of ISPs.

It hard for you to recognize that most, if not all, of the effort
of IETF security area has been wasted in vain. But that's the
reality.

						Masataka Ohta

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 9 Jul 2007 23:03:09 -0400

On 7/7/07, Keith Moore <[email-masked]> wrote:
> interoperability.

This response sounds suspiciously similar to responses from defenders
of technology and procedures that don't work. That is, the response
assumes that the questioner doesn't understand the finer points of the
system. I'm sure there are details and strategies I don't know about,
but the point about shifting implementation burden is usually one of
the first qualifiers to get dragged out in these arguments. Amusingly,
it sounds pretty pointless in the context of the qualifier that
usually follows: "mandatory-to-implement does not mean
mandatory-to-deploy". This distinction might make sense when
classifying routers and things, but there's no way to tell the
difference for application protocols.

I'm interested in MTI success stories in application protocols.
Anything related to HTTP is right out, because that stuff doesn't
work. Peter mentioned a small success in XMPP, where implementors were
convinced to allow switching from SSL to TLS.

I'm also interested in the reasoning behind the IESG's decision to
allow Atompub to avoid requiring a specific TLS version. That
certainly allows for incompatible conformant implementations. I don't
understand why WGs are not permitted to make similar judgments
regarding other security mechanisms--they usually know more about
their market than the IESG does.

-- 

Robert Sayre

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Jul 2007 11:16:29 -0400

At 10:54 AM +0900 7/10/07, Masataka Ohta wrote:
>...

the attacks may be comparable but not all of the effects are the same.

>is an PKI, will be no different from that of ISPs.

DNSSEC is very analogous to a PKI in many respects, but it too is not 
quite the same. A major difference is that the DNS hierarchy is 
authoritative for the bindings it establishes, whereas the common, 
trusted-third party CA model involves organization who are 
authoritative for nothing.

>of IETF security area has been wasted in vain.

As opposed to wasting efforts constructively?

>But that's the

It's so generous of you to provide the rest of us with your wisdom 
with regard to the reality of security. I'm not sure we are 
deserving, and so maybe it would be fairer to not share so much.

Steve

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 Jul 2007 09:24:10 -0600

Stephen Kent wrote:
>> of IETF security area has been_ wasted in vain_.
> 
> It's so generous of you to provide the rest of us with your wisdom with
> regard to the reality of security.

Wisdom is a positive attainment. I'm curious to know what positive
recommendations Mr. Masataka Ohta has regarding security, because all
I've seen so far is "X, Y, and Z are useless"...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 Jul 2007 11:47:39 -0700

Security is a property of systems and not of technologies.

In particular security is risk management and not the elimination of all risk. Even the best PKI will not provde you with the slightest protection against a meteor strike.

PKI provides opportunities for technical risk mitigation which are not available in normal circumstances. For example the root keys associated with high security embedded roots are created in high security facilities that have no network access and are kept in those facilities for their entire operational lives, at the end of which they are physically destroyed.

Such operational controls are not likely to be acceptable to network administrators at your average ISP.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 Jul 2007 12:55:47 -0700

The IETF rules met the objective that the IESG had when they proposed them - to make sure that at least we did not continue to invent yet more protocols that only support password authentication in the clear.
 
In the case of HTTP, the DIGEST proposal came within a week of BASIC. If the IESG rulling had been in place at the time we could have strangled BASIC at birth and exorcised it from the spec.
 
Instead the people behind BASIC rather liked it because you could simply plug your Web server into your existing UNIX password file which at the time was considered (by them) to be acceptably secure. Don't mind the fact that moving passwords over the Internet is a rather different proposition to moving them over a LAN. Don't mind the fact that even UNIX administrators were finally starting to get the message that they should be using shadow passwords, that the UNIX password algorithm was no longer acceptably secure in the era of Crack.
 
So BASIC went into the core HTTP specification and DIGEST did not. DIGEST would not have emerged as an RFC at all except for the fact that support for an acceptably secure authentication mechanism was now an IESG requirement to get to DRAFT status.

If I had got my way in 1993 the whole problem of bank credential phishing might have turned out rather different - if that is we had managed to get DIGEST implemented in HTML as well.

At this point I would not suggest that we require protocols to support strong authentication. In fact I would sugges we require the NOT to.
 
Instead I would like to see a requirement that an application protocol support a framework such as OpenID, WS-* or SAML which allows the authentication problem to be broken out as a separate service where a range of authentication technologies can be supported - including smartcard/ smarttoken/ OTP/ local keypair and if you must username/password are supported.

________________________________

From: Robert Sayre [mailto:[email-masked]]
Sent: Mon 09/07/2007 11:03 PM
To: Keith Moore
Cc: IETF discussion list
Subject: Re: Updating the rules?

--

Robert Sayre

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Jul 2007 13:13:41 -0700

On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:

> In all but a single instance I have no evidence to the contrary.   
> The one case of an exploit was extremely well publicized and  
> ameliorated within days.  And that was years ago.

Trust Models.

Once a CA is vetted, it can be leveraged as a point of trust.  The  
trust is of an association with a URL validated by the certificate.   
This works for the most part, with notable exceptions.  The fact that  
exceptions are notable is notable.

When short cuts are taken in PKI as with SMTP, there should be some  
concern.

DKIM voids vetted CAs, as the public key is obtained from DNS, this  
provides the URL association directly.

Although DKIM depends upon DNS, it makes two significant compromises.

1) The only anti-replay mechanisms available are:
  -  direct association of SMTP client with signing domain.
  -  per-user keys.
  -  SPF to associate SMTP client with signing domain.

2) The only authorization mechanisms available are:
  - ad-hoc exchange of public or private keys.
  - delegating DNS key zone.

Replay-abuse:

Direct association with an SMTP client is not always practical.

Timely per-user key cancelation is unlikely, and may even cause DNS  
to become inundated with short-lived key records.

SPF allows bad actors to "script" a series of transactions through  
_any_ remote DNS cache.

Granting this access via SPF to bad actors places potential victims  
at substantial risk of being inundated.  SPF is macro expanded for  
each email-address checked.  A spam campaign originating from a  
domain of many local-parts will be able to instantiate hundreds of  
DNS transactions per message.  Why not, the attack will be free to  
any spammer.  The victims of bad actors can be attacked from the same  
cached long lived SPF record.  Poisoning DNS usually starts by  
preventing an authoritative DNS from responding, where then directing  
remote domains to make a series of queries would be needed.  SPF  
enables both tasks.

Proponents of SPF scripts felt that granting bad actors such access  
to remote DNS resolvers was justified.  Their justification was based  
upon the level of damaged that might be caused by a chain of bogus NS  
records anyway.  Of course any such susceptibility to bogus NS record  
chaining can be handled with changes to the DNS protocol.  Damaged  
created by SPF can not be handled by such changes to DNS.  In  
addition, bogus NS record chaining can also be greatly amplified by  
SPF.  Bogus NS record chaining should have increased the concern,  
instead just opposite resulted. : (

Unfortunately, while DNSsec might avoid the cache poisoning enabled  
by SPF, it will also increase the odds of SPF of being successful at  
staging a DDoS attack.

Lack of authorization by-name:

The ad-hoc exchange of keys is a disaster waiting to happen.   
Thousands of private keys per server could be at risk.  In addition,  
who signed has been obfuscated.  There is no reason to obfuscate  
DKIM's signing process.  Users will not be examining signatures and  
are unable to understand how it was verified.

Deflecting accountability away from entities transmitting messages  
into a public SMTP servers is the reason for:

  - SPF's absurdly expansive IP address lists instead of  
authorization of by-name.

  - DKIM's lack of an authorization by-name mechanism.

DKIM and SPF are less than hopeful signs.  The intent of these  
schemes is to deflect accountability away from the SMTP client  
publicly transmitting the spam.  How does this instill trust?

-Doug

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Jul 2007 16:51:10 -0400

At 1:13 PM -0700 7/10/07, Douglas Otis wrote:
>>>So, you merely believe that the infrastructure of PKI is well managed.
>>

your reference to a URL is a very specialized (not generic) 
description of how one might interpret the security services 
associated with a CA.

Steve

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Jul 2007 16:41:46 -0700

> description of how one might interpret the security services  

Agreed.  I should have could be of an association with...  The intent  
was to relate this to DKIM, which of course is even more specialized.

-Doug

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Jul 2007 10:22:53 +0900

> Security is a property of systems and not of technologies.

Yes, of course. Though some often claims PKI were cryptographically
secure, it does not mean PKI is strongly secure. Cookies, too, are
cryptographically secure.

> In particular security is risk management and not the elimination
> of all risk.

So, I, quite constructively, showed how to archieve strong security
by securely sharing security information directly between the first
and the second party. It eliminates intermediate intelligent entities
and gives the ultimate (fate sharing) security archived by the end
to end principle.

On the other hand, you and others merely stating possibility that
some PKI could be made fairly secure if all the operational rules
could be observed by all the operators.

> PKI provides opportunities for technical risk mitigation which are
> not available in normal circumstances.

That's a totally unfounded statement and is not constructive.

> For example the root keys associated with high security embedded

Security is a property of systems and not of parts of systems.

Backbone routers can be protected equally securely.

> administrators at your average ISP.

Nor to PKI administrators near leaf where keys must be accessed
often to generate CAs.

						Masataka Ohta

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Jul 2007 09:55:38 +0200

Doug,

> provides the URL association directly.

It's really not the same.  The implications of a compromised DKIM key 
are bilateral *at best*, whereas a CA, particularly a well known one 
will have far broader impact.

But that's not what I was talking about.  What I was referring to was 
Ohta-san's implication that PKI is fundamentally flawed.  Perhaps it is, 
but I don't see anything better for key distribution to millions of 
people.  If you, he, or anyone else comes up with something better, I'm 
all ears.

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Jul 2007 18:04:54 +0900

Eliot Lear wrote:

> What I was referring to was 

Perhaps.

Though my statement so far is PKI is not strongly secure, it implies
that you can choose from equally secure design alternatives.

See below.

> people.  If you, he, or anyone else comes up with something better, I'm 

Though I'm not so sure about your requirement, if you need fairly
secure key distribution mechanism over the Internet, KDC, not CA,
based schems such as Kerberos, is better than PKI.

Though KDCs require real time communication, it's free over the
Internet.

Moreover, because key distribution is in real time, key invalidation
is instantaneous without complex mechanisms such as CRLs. That is, you
can shutdown spam site instantaneously.

Or, as you are trying to create a new key distribution network from
the beginning, it should be easier to create a new mail distribution
network from the beginning where mails are allowed only between
pre-recognized bodies.

A very good property of this approach is that we don't need any
cryptography nor new protocol. Just have a list of IP addresses of
thousands or tens of thousands of root mail servers and set up our
mail software to accept mails only from them or our own proxy and
send mails only to them through proxies registered to a root mail
server or two or three...

Setting up a new mail network is hard but, IMHO, much easier than
setting up a new PKI.

Though neither of the above protect us spams from cracked accounts,
we are not annoyed by delays with CRLs.

Of course,  CAs, ISPs, KDCs and root mail servers are not very
trustworthy but they should increase the cost of spammers.

						Masataka Ohta

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Jul 2007 08:14:12 -0700

> people.  If you, he, or anyone else comes up with something better, I'm 

I agree with your statements about PKI.  PKI helps formalizes safe
procedures to exchanging information.  PKI also reduces the number of
entities who's attention to these procedures needs to be vetted.

For DKIM, an ad-hoc exchange of keys or the delegation of a zone are the
methods available to authorize a third-party.  This authorization could
often be needed to permit a provider's added signature be recognized as
authoritative.  This is accomplished by making the signature by the
third-party transparently appear to be that of their customer. 

How keys are exchanged or handled might be accomplished in any number of
ways.  A provider may find it easier to collect private keys and
selector locations, issue public keys and selector locations, or obtain
a zone of their customers to permit them to directly deal with keys and
selectors to better manage key rollovers.

When a service provider becomes compromised in some manner, the many
domains they provide signatures for could be at risk. The private key or
keys the provider uses could be used to spoof the messages for any of
their customers from any SMTP client.  These keys are likely distributed
to many servers connected to the Internet.  This might also include keys
published in DNS when the service provider controls different zones for
thousands of other domains.  The use of these keys may not be limited to
just DKIM as well.

Without an authorization by-name mechanism for DKIM, the recipient is
unable to vet which third-party they are trusting.  The originator would
also need to hope their keys are handled safely using some ad-hoc
procedure.  When one of these third-parties becomes compromised, users
would need to be asked to check which key selectors were used to sign
messages for perhaps thousands of different domains.  This could be a
rather daunting list caused by just one compromise.

DKIM could prevent this type of unmanageable compromise situation by
using an by-name authorization scheme instead. DKIM should recommend
against an exchange of keys or the delegation of zones.  When keys used
by provider-x becomes compromised, all their customers will be able to
retract their authorization record, and just signatures made by
provider-x would then be suspect.  When dealing with a compromise
situation, a simple report is all that is needed.  As it is now, a
compromise report may look like an encyclopedia of keys and selectors.

The impact would be much more painful to those compromised as well.  The
report would need to list all their customers.  Those customers will
likely receive phone calls from competitors.  Knowing this, the
temptation would be to not report a breach, and require each of their
customers to report a problem as it gets discovered by them perhaps much
later.  One compromise may then sound like an epidemic of compromises.

Authorization by-name and not by key exchange is a much safer
alternative DKIM.  Authorization by-name would also permit the detect of
possible replay abuse made impractical with ad-hoc key exchanges.

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 11 Jul 2007 17:19:02 -0700

>From a business point of view I am equally happy selling symmetric key, KDC type approaches as PKI. In point of fact I am currently co-chair of a working group that is developing a symmetric key protocol.
 
However there are very few security advantages in the KDC model (e.g. resistance of symmetric key crypto to quantum cryptanalysis), plenty of security disadvantages (much more limited hardware support, not possible to apply same separation of duties controls) and some really serious operational constraints.
 
>From a historical point of view it is certainly true that we probably made a mistake in the original conception of PKI as making the KDC model obsolete. A synthesis of the two approaches would have been much more valuable. In particular if SSL had supported kerberos ticket like capabilities from the start. We later added KDC type capabilities to PKI with protocols like XKMS and OCSP. 
 
But the argument here strikes me as little more than an emacs/vi contest.

Regardless of the technical infrastructure you employ you still have to map the network identifiers to real world identities. And that is an excercise that requires expense and consistency and attention to detail and is as boring as sin for the people actually doing it.
 
Proposals to do away with commercial PKI come in two flavors. The first is technological magic which is founded not on a misunderstabing of the problem but a complete failure to understand that the problem exists. The second is the open source effort objection which is pretty much as viable as an open source effort to do people's tax returns for them.

From: Masataka Ohta [mailto:[email-masked]]
Sent: Wed 11/07/2007 5:04 AM
To: Eliot Lear
Cc: Douglas Otis; IETF discussion list
Subject: Re: PKI is weakly secure (was Re: Updating the rules?)

Perhaps.

See below.

                                                Masataka Ohta

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Jul 2007 12:01:41 -0400

No one had any concern with the version of TLS that was selected by 
the working group.  However, there were two things that cause me to 
want a change.  I'll let others provide their own point of view.

1) History has shown that TLS implementations do a very good job 
handling backward compatibility.  As a result, there has been a 
smooth transition from SSL 3.0 to TLS 1.0, and a similarly smooth 
transition has begun from TLS 1.0 to TLS 1.1.  TLS 1.2 is being 
developed in the TLS WG right now.  I expect the transition to TLS 
1.2 to be smooth as well.

2) We do not want to update the standards-track Atom RFC to track TLS 
developments.  The language that was put in the document made it easy 
for an implementor to use a TLS library and let the version 
negotiation naturally select the highest version supported by the two peers.

Russ

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jul 2007 20:33:26 +0200

Russ Housley wrote:
> No one had any concern with the version of TLS that was selected by the 
> working group.  However, there were two things that cause me to want a 
> change.  I'll let others provide their own point of view.
> ...

I'll have to point out that the preference of the working group IMHO was 
not to say anything at all with respect to this. As far as I recall, the 
text that ended up in the draft that was submitted to the IESG actually 
was proposed by the AD, and the WG just decided not to care.

Best regards, Julian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Jul 2007 12:11:18 -0700

What Russ is stating here seems to me to be simply good, modular design.
 
If the applications care about the lower levels the architecture is broken. An Atom client does not have the ability to specify the transport layer in the general case, nor should it need to do so. The transport is built into the operating system platform.
 
We want to be able to fix TLS without sending out notices to all the applications that rely on it. We want to be able to fix atom similarly.

To put it in the terms I learned from my college tutor, the transport protocol enters into a contract with the application protocol. Provided both sides meet the contract each is entirely free to implement in whatever way they like. In this case the contract is with TLS, not a particular version of TLS.

From: Russ Housley [mailto:[email-masked]]
Sent: Fri 13/07/2007 12:01 PM
To: Robert Sayre
Cc: IETF discussion list
Subject: Re: Updating the rules?

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Jul 2007 15:13:32 -0400

That is not the way the document arrived to the IESG.  It said:

    The type of authentication deployed is a local decision made by the
    server operator.  Clients are likely to face authentication schemes
    that vary across server deployments.  At a minimum, client and server
    implementations MUST be capable of being configured to use HTTP Basic
    Authentication [RFC2617] in conjunction with a TLS [RFC2246]
    connection as defined in [RFC2818] (but note that [RFC2246] has been
    superseded by [RFC4346]).  See [RFC4346] for more information on TLS.

The normative reference cites TLS 1.0, making it the only version 
that is permitted.

Russ

At 02:33 PM 7/13/2007, Julian Reschke wrote:
>I'll have to point out that the preference of the working group IMHO 
>was not to say anything at all with respect to this. As far as I 
>recall, the text that ended up in the draft that was submitted to 
>the IESG actually was proposed by the AD, and the WG just decided not to care.
>
>Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jul 2007 21:47:06 +0200

Russ Housley wrote:
> The normative reference cites TLS 1.0, making it the only version that 
> is permitted.
> 
> Russ

Yes, and that problem was known when it was submitted (together with 
confusing statement about RFC4346 which follows in the next sentence).

Originally the WG didn't want to put it any MTI requirement at all. As 
far as I can recall, we ended up with the text that was submitted 
because we were told that "this is what you need to do to get IESG 
approval".

The changes made in the latest draft clearly are an improvement over the 
text that was submitted, and hopefully the spec can now proceed.

Best regards and sorry for the confusion,

Julian

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 17:24:16 -0400

Hallam-Baker, Phillip wrote:
> If the applications care about the lower levels the architecture is
> broken.

false.  the implication of that statement is that an application should
be able to function no matter how much or little functionality the lower
layers provide, and thus, the application must provide all of the
functionality that it needs so that it can function with the most
minimal or dysfunctional of lower layers.  this defeats the entire
purpose of layering.
> To put it in the terms I learned from my college tutor, the transport
> protocol enters into a contract with the application protocol.
> Provided both sides meet the contract each is entirely free to
> implement in whatever way they like. In this case the contract is with
> TLS, not a particular version of TLS.
yes, but if the contract was originally defined in terms of a particular
version of TLS, and there is any drift at all in the functionality or
interface provided between one version and another, or if there's any
incompatibility between old and new versions of the protocol (as there
was between SSL 3.0 and TLS 1.0)  the application can no longer be
expected to work.
it's not as if the "contract" can automatically be assumed to be amended
just because a new version came out.

in applications (I mean this in the broader sense, not just software)
where reliability is important, it's not acceptable to substitute one
component for another without first doing an analysis of whether the new
component meets the requirements of the design, and whether substitution
of that component will cause any problems.

---

From: Russ Housley <[email-masked]>
Date: Sat, 14 Jul 2007 10:35:54 -0400

Julian:

I provided review and comment for the text that was sent forward to 
IESG Evaluation.  It sounds like your issues are in the process 
before I saw the text.

As I said in my first posting, I'll let others provide rationale for 
their own actions.

Russ

At 03:47 PM 7/13/2007, Julian Reschke wrote:
>Originally the WG didn't want to put it any MTI requirement at all. 
>As far as I can recall, we ended up with the text that was submitted 
>because we were told that "this is what you need to do to get IESG approval".
>
>The changes made in the latest draft clearly are an improvement over 
>the text that was submitted, and hopefully the spec can now proceed.
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 14 Jul 2007 10:53:38 -0400

>of that component will cause any problems.

Yes, care and engineering is needed.  I hope that WG review and IETF 
Last Call will detect any slips.  That is one of the things we expect 
to happen during these phases of document development.

I look forward to your participation in the review of TLS 1.2.

Russ

---

From: Philip Matthews <[email-masked]>
Date: Fri, 20 Jul 2007 11:16:21 -0400

From the draft:
    1.  Rename PS as Preliminary Standard.

I have often confused the order between "Proposed" and "Draft" standard.
[In my view, one needs to "draft" a standard before you can "propose"  
it,
but in the IETF, you "propose" first, and then "draft" it.]
So I would like to suggest that the name for the standards at each  
step must clearly indicate
their maturity level and where the standard is on the ladder.

With a two-step process, naming the first step "Proposed",  
"Preliminary" or "Draft"
and the second stage "Full" works well. With a three-stage process, I  
think we need
better names for the first two stages.

If we stick with the three-stage process, then perhaps the names
	"Preliminary Standard"
	"Intermediate Standard"
	"Full Standard"
might be used.

- Philip

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 20 Jul 2007 08:38:00 -0700

No, an I-D is a Draft Standard.  An RFC is a Standard.  :-)

-- Kurt

On Jul 20, 2007, at 8:16 AM, Philip Matthews wrote:

> [In my view, one needs to "draft" a standard before you can  
> "propose" it,
> and the second stage "Full" works well. With a three-stage process,  
> I think we need

---

From: Bob Braden <[email-masked]>
Date: Fri, 20 Jul 2007 12:12:21 -0700

>No, an I-D is a Draft Standard.  An RFC is a Standard.  :-)

No, and No.

Bob Braden for the RFC Editor

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Jul 2007 12:03:09 -0400

>>>>> "Bob" == Bob Braden <[email-masked]> writes:

    >> No, an I-D is a Draft Standard.  An RFC is a Standard.  :-)

    Bob> No, and No.

He just says that because under his rules he's probably published more
draft standards than the IETF.:-)