Subject: [saag] Should security requirements be MUST?

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Jun 2012 16:35:54 -0400

An issue that appears to cause a lot of controversy out in WGs is the
issue of whether a security requirement should be stated as a SHOULD
or a MUST. While it may appear obvious that a specification should
prohibit a bad practice, I now think this is the wrong approach.

Security is a balance of concerns that are often in conflict. When the
only concern is confidentiality, the best approach in cases of
ambiguity is usually going to be to refuse any action that might lead
to disclosure. But this approach is inevitably in conflict when
service availability is the prime concern.

When a specification says MUST in relation to a security concern it
most often says 'MUST refuse' or some other action that turns into
'MUST break'. These are not decisions that the specification writer is
in a position to judge. The only party that can make these judgments
are the application developers who understand the context in which the
application is to be deployed.

This is not an abstract concern. In recent months we have had two
cases where IETF working groups have take one approach and industry
has taken the other and in both cases the point at issue was whether a
specification should provide security advice or whether conformance
should require a specific security policy.

I don't think anyone is going to deploy DANE on a large scale with the
MUST reject feature implemented the way that the authors imagine.
Unless we have a means for automatically updating the DANE records to
the SSL service that the relate to the data in DANE records is just
not going to be accurate enough for direct client enforcement anyway.
Nobody uses DKIM policy records without some form of curator being
involved, why expect DANE to be any different.

On PKIX we have nonsense on stilts. The industry wants to use a
feature of X.509 but the PKIX specification mandates that this can
only be used if marked so as to mandate rejecting backwards
compatibility with deployed products (including Safari). This seems a
rather obvious shortcoming in the specification to me. But at root the
problem is that nobody with sense is going to be looking to a
consensus based process for direction on security policy. A consensus
based process can certainly advise but only stakeholders can make an
actual decision.

-- 
Website: http://hallambaker.com/

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Jun 2012 16:16:05 -0500

> based process can certainly advise but only stakeholders can make an

I assume you mean Name Constraints.  Too much deployed code doesn't
implement them but still understands criticality (i.e., breaks in the
presence of critical name constraints).

Breaking interop is the right thing to do when you're only just
getting started deploying the protocol.  Critical name constraints
would have been great to have seen deployed way, way bak in the
mid-90s.

But I'm not endorsing -not yet- non-critical name constraints. It'd be
useful to first understand what it'd take to get enough of the RPs
(browsers, mostly) fixed, and how much time that would take, so we can
understand how long we can expect to see critical extensions made
non-critical.  We've seen Google work hard with various vendors to
make Google's TLS extensions workable, and granted, that's only
servers, but in some cases TLS concentrators are harder to fix in the
field than browsers (which nowadays self-update).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Jun 2012 16:33:50 -0500

Thinking more about it:

 - I'd say that any CA wishing to use non-critical name constraints
   (which you didn't propose, but which I assume is what you're
   getting at) must be auditable, and its sub-CAs must be
   auditable -- in real-time.  And they must issue postdated certs
   only, with enough time to expect the public to audit them (say, a
   few days, or at least a few hours).  And the sub-CAs must use
   HSMs, and be setup by the CAs, ...

 - I'd like to see quantitative analyses of a) how much breakage
   we can expect to see if CAs deployed critical name constraints,
   b) how many users would be rendered vulnerable to MITM
   attacks by sub-CAs if CAs are allowed to issue sub-CA certs
   with non-critical name constraints.

Also, it's not what the RFCs say, it's what browser/OS vendors are
willing to allow into their trust anchor sets -- they are the
enforcers, and there is no IETF police.

Nico
--

---

From: Chris Palmer <[email-masked]>
Date: Tue, 26 Jun 2012 15:12:27 -0700

> enforcers, and there is no IETF police.

We (Google Chrome developers) want name constraints. Critical name
constraints blow up enough clients that it's a deal-breaker.

But imagine a client that says to itself, "The cert says these name
constraints are non-critical — presumably for backwards compat. But
I'll treat them as critical, since I was implemented in late 2012 and
my implementers knew that name constraints are spiffy." Fewer clients
will explode upon seeing an unknown-but-critical extension. (Some
clients will explode anyway, probably, but fewer; and we can much more
reasonably call those clients buggy.)

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Jun 2012 23:20:24 +0100

Hi Chris,

On 06/26/2012 11:12 PM, Chris Palmer wrote:
> We (Google Chrome developers) want name constraints. 

Is that really the case? ISTM, that what you and others want
is something very like, but is not, the existing NC extension.
(That's been part of the problem with that discussion, some
folks are making some bad arguments in a possibly good case.)

But - I think that's a discussion for the pkix list. Phill's
question is broader and different and probably more useful to
discuss here.

S

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Jun 2012 15:24:42 -0700

> reasonably call those clients buggy.)

Chris,

I'm not sure I am following this. Are you suggesting that this hypothetical
browser would recognize name constraints but not be able to process
them? As I understand 5280, criticality applies how you process
stuff you aren't able to process.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Jun 2012 18:28:15 -0500

> We (Google Chrome developers) want name constraints. Critical name

We all should.  Are you endorsing non-critical name constraints?  Or
just wishing you could use name constraints, and thinking that it may
be possible to make them non-critical with very limited loss of
security? (see below)

> constraints blow up enough clients that it's a deal-breaker.

Right.

> reasonably call those clients buggy.)

CAs issuing sub-CA certs with non-critical name constraints (NCNC?)
would effectively be issuing MITM sub-CA certs.  This can be
mitigated, perhaps to the point of such practices being acceptable.
I'd like to see a quantitative analysis of how many users would be
rendered vulnerable to MITMing sub-CAs, for starters.  If that number
is small enough then one could argue that the remainder confer a sort
of herd immunity on them, but it's not clear that that's correct.  If
vulnerable clients can be fingerprinted then the herd immunity
argument is weakened since the only incentives left to not MITM
vulnerable clients would be: getting caught via audits, or the number
of vulnerable clients being so small that it's not worth the effort to
MITM the few and far between that get exposed to an evil sub-CA.

Nico
--

---

From: Jeffrey Schiller <[email-masked]>
Date: Tue, 26 Jun 2012 23:12:11 -0400

Let's get back to Phill's main point which I believe is that
implementers are in a much better position to understand the security
trade-offs involved in a given deployment, then say the protocol
designers. That as protocol designers, we shouldn't presume to
understand all deployment environments and therefore should not
preclude security "settings" (for lack of a better term) that may not
make sense to us, but do make sense in some (unknown to us) context.

Let me expand a bit on this and give some history (as a Security AD
from 1994-2003, I have some history in my head!).

A lot of the security area's "strictness" evolved in the mid 1990's
when many (outside of the Security Area) folks in the IETF really
didn't care much about security. Internet Security threats were mostly
kids, not the organized crime and state actors that we see today. We
used to have (still do?) a requirement that all RFCs have a "Security
Considerations" section. The purpose of this requirement was to get
folks to think through security issues. It was only partially
successful. More people asked me "What weasel words should I put in
the Security Considerations Section to get it approved" then asked me
"How can we truly address security concerns in this protocol."

My favorite situation involved the elevation of a protocol to DRAFT
Standard. In order to become a DRAFT Standard, a protocol needed to
have at least two independent implementations of all features of the
protocol. Features that did not have independent implementations
needed to be removed from the standard prior to elevation to DRAFT. So
I was approached about removing all security from a protocol because
well... there weren't two implementations of the security features and
the document authors wanted to have the protocol go to DRAFT
Standard. Guess where that went!

In my model at the time there were three groups to consider.

  1) Protocol Designers (us).
  2) Protocol implementers (vendors, etc.)
  3) Protocol End-Users (the folks who bought the stuff).

Often members of group (2) overlapped with group (1). The problem that
I perceived was that group (3), the "real" users, wanted security (and
who really doesn't!) but group (2) didn't want to provide it (for a
number of reasons, but high on the list was the fear that it would be
hard and expensive to do).

So to compensate, we started leaning toward making security mechanisms
mandatory (MUST) as applied to implementers. But end-users could
always decide not to use them (for such things would be out-of-scope
for the IETF). Nice artful dodge that!

A good question to ask today (2012) is: "Is this too strict?" Should
we be more flexible in how security mechanisms are put into practice?

In some ways the problems are trickier today. The Internet is not just
for engineers anymore. Group (3) now includes some very non-technical
people. We cannot expect these folks to understand and make security
trade-offs. We can still offer them security controls, but we have to
decide what the defaults are for the average user.

Sorry for the length of this message.

                        -Jeff

_______________________________________________________________________
Jeffrey I. Schiller
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room E17-110A
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
http://jis.qyv.name
_______________________________________________________________________

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Jun 2012 08:34:59 +0300

On Jun 27, 2012, at 2:28 AM, Nico Williams wrote:

> would effectively be issuing MITM sub-CA certs.  

They would be issuing sub-CAs that can mount a MITM attack only against browsers that do not support name constraints. All it takes is one browser that does support name constraints to get that offending cert discovered.

I don't know about Chrome, but there are enough Firefox browsers out there to believe that if you place a certificate with a name that does not conform to the constraints of the CA, you are going to be discovered.

This isn't quite as secure as having all browsers break the connection either because the name mismatches or because they don't understand name constraints, but it actually is a good example of how mandating the best security can delay adoption practically forever.

Yoav

---

From: Barry Leiba <[email-masked]>
Date: Wed, 27 Jun 2012 07:20:00 -0400

> make sense to us, but do make sense in some (unknown to us) context.

Maybe the point, then, is that we really need to think separately:
that "Security Considerations" are *considerations*, and that if we
think there are security issues that MUST be handled in the protocol,
those are in the protocol definition itself, not pushed to the end of
the document in the Security Considerations section.

There's a big difference between specifying how you handle
authentication, authorization, integrity, and confidentiality *in the
protocol*, and discussing the things that need to be considered when
the protocol is implemented and deployed, and is in operation.

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Jun 2012 07:18:11 -0700

> the document in the Security Considerations section.

<furiously clicking the +1 button>

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Jun 2012 07:46:04 -0700

> <furiously clicking the +1 button>

IMO, the Security Considerations section should discuss concerns about when SHOULDs and MAYs apply (or do not), and discuss how security has been addressed (if the doc's main purpose isn't security).

It definitely should not contain any new SHOULD/MUST/MAYs - at best, it might reiterate points for emphasis.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Jun 2012 11:21:21 -0400

> reasonably call those clients buggy.)

There seems to be some confusion as to the nature of the critical bit here.

The critical bit was defined in X.509 (not IETF) and it has one and
only one purpose. It tells clients that do not understand the bit or
understand the bit but do not observe it to consider the certificate
to be invalid.

The critical bit has no other semantics. Marking an extension critical
does NOT mean 'yes I really mean this'. A client that only processes
NCs that have the bit set is just as non-compliant as one that does
not implement NCs at all.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Jun 2012 11:46:16 -0400

> question is broader and different and probably more useful to

Yes, that was my intention.

I think we need to limit specifications to providing security advice
and explanations and prohibit security directions.

One reason for this is that the security directions are very
frequently inappropriate in a real world situation. If you are
building an email application then maybe the right response to an
expired certificate is to break. If you are building a heart and lung
machine or an airplane then your imperative might well be to keep the
thing running at all costs unless there are very good, explicit
reasons to shut down.

Another reason is that I have noticed that arguments over security
directions tend to be the most acrimonious and heated. We come from
many different application areas and what is a requirement in one area
may not be in another.

Finally there is the fact that security directions almost never have a
bearing on interoperability. They are not necessary decisions for a
standards organization to take. So why spend hours of time debating an
issue that we don't need to discuss, that causes a lot of
unpleasantness and is going to be ignored anyway?

If people take a close look at PKIX they will see that all the spec
talks about is what steps MUST be taken to decide if a certificate is
valid. PKIX does not tell clients how to evaluate the trustworthiness
of a certificate or whether to accept or reject it (at least not as
far as I can remember).

So an Internet application is fully entitled to accept a certificate
that is invalid according to PKIX or reject one that is valid. And
there are many situations where this makes sense. I would prefer my
mail server to connect to another server via SSL and an expired
certificate is to connect en-clair with no encryption.

Rather than telling people what to do, specifications should state
what the consequences of different implementation choices.

The only places I would want to see security directions is in a
profile document whose sole purpose is to specify a set of security
directions for a specific audience.

So for example, a company outsourcing their email would likely want to
have some assurance that it was being processed in accordance with a
specific set of security and policy requirements. It would be very
useful if there was a document that said something like 'mail server
SHALL support STARTTLS, SHALL offer ciphersuites mumble, SHALL publish
its inbound and outbound security policy via DKIM, DANE, TBS and so
on.

These are important and useful discussions when they are centered on a
very specific application domain and completely useless when focused
on a single protocol that is in development.

We have a like issue when people argue over mandatory cipher suites
for platform specifications like XML Signature, JSON signature etc.
Its the type of argument that everyone can join in because everyone
can have an opinion. But the choice of cipher suite is really
something that should be part of a separate discussion.

---

From: Marsh Ray <[email-masked]>
Date: Wed, 27 Jun 2012 11:31:32 -0500

> the document in the Security Considerations section.

Would you be against giving them a mention or a reference in the 
Security Considerations section too?

I really find it valuable to be able to refer to that section for a 
reasonably thorough review of all the security-affecting aspects of the 
design, implementation, and deployment.

IOW, I don't think of it as being "pushed to the end of the document" I 
think of it as "this stuff is important enough to deserve its own 
section and not just scattered throughout the document".

- Marsh

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Jun 2012 11:03:43 -0800

> <furiously clicking the +1 button>

Here, too.  That's one of those things that seems obvious when someone
says it, but I don't think I've seen someone say this before.  So yes,
definitely.

Melinda

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 27 Jun 2012 07:59:56 +0000

Jeff,

Great and timely discussion!

I've just returned from this year's WEIS[1] that had a keen focus on your last point: it is very hard for users to make the right decision, and indeed the research challenged the whole permission-based approach in mobile devices in part due to UI design issues and in part because security wasn't top of mind.

What does this tell us? It's early days but perhaps it confirms that users are willing to make trade-offs and that should be respected... up to a point where externalities could be introduced, and that's when this discussion gets really fun!

As Nico hinted there's a body of epidemiological work that needs to be considered and is not always intuitive. Combine this with the fact that protocols and don't always get uses in ways that were envisioned by their designers and now we're REALLY off to the races!

Eliot
[1] http://weis2012.econinfosec.org/

On Jun 27, 2012, at 5:12 AM, "Jeffrey Schiller" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iD8DBQFP6nm68CBzV/QUlSsRAkwnAJ9tNjdGJQBYuoW0Sd5Z+BDCA/vpxQCgiRVY
> vG1aOcvHocFm+Ij4VDitMew=
> =fBXh
> -----END PGP SIGNATURE-----

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Jun 2012 12:52:07 -0400

At 3:12 PM -0700 6/26/12, Chris Palmer wrote:
>...
>constraints are non-critical - presumably for backwards compat. But
>my implementers knew that name constraints are spiffy."

I don't understand what you're trying to say above. An RP that
understands an extension is expected (i.e., MUST) process it, irrespective
of whether the extension is marked critical.  So the phrase of "I'll treat
them as critical ..." makes no sense to me.

The critical flag is used by a CA to force an RP to reject a cert if
the extension is marked critical AND the RP does not know how to process
the extension, period.  It's a way for a CA to say "if you can't process
(enforce) the data in this extension, I don't want you to rely on this cert,
because I (the CA) believe that the extension is very important to safe
use of the public key in the cert.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Jun 2012 13:36:33 -0400

At 11:31 AM -0500 6/27/12, Marsh Ray wrote:
>reasonably thorough review of all the security-affecting aspects of 
>the design, implementation, and deployment.
>
>IOW, I don't think of it as being "pushed to the end of the 
>document" I think of it as "this stuff is important enough to 
>deserve its own section and not just scattered throughout the 
>document".
>
>- Marsh

If the RFC is a security spec, the info will be scattered throughout 
the doc, and it would be onerous to repeat that info in the SCC. In 
such RFCs it makes sense to discuss deployment/use considerations in 
the SCC, apropos the section's name.  (After all, very few RFcs 
mandate use of secruity mechanisms; they mandate that implementations 
incorporate support of the mechanisms to enable their use when users 
and sys admins so choose.)

In RFCs that are not security-specific, the SCC does tend to be the place where
the secruity mechanisms described in the RFC are summarized and there 
is (should be) discussion of how and when to employ the mechanisms 
offered as part of the protocol. I admit that many RFCs that are not 
security-centric don't do a great job of this.

Steve

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 28 Jun 2012 11:23:30 -0700

> and explanations and prohibit security directions.

Disagree.

If the purpose of a protocol is to provide some level of security, then the specification MUST specify what must be done in order to provide that security.  I generally agree with Barry's comment about Security Considerations being "considerations" and not requirements.

I also happen to believe that if a protocol needs some security features in order for its results to be believed those MUST be specified somewhere.  If those features purely relate to deployment, they could be relegated to discussion in the Security Considerations section.  However, if specific deployment constraint must be satisfied to provide some important security property, then I'm OK with putting a MUST in the Security Considerations section for that.

> unpleasantness and is going to be ignored anyway?

Because the issues need to be understood in order to discover the best compromises among the possibilities.  I also deplore how acrimonious the discussions get because that prevents us from doing that discovery properly.  I suppose if someone thinks his/her job may depend on the decision going a particular way, I can sympathize, but it still gets in the way.

> of a certificate or whether to accept or reject it (at least not as

I generally agree with the concept of RFCs providing mechanisms which can be tailored to specific needs.  Taking that to a dysfunctional extreme you can wind up with standards that try to serve such a diverse set of customers that they wind up being too complex to implement (with realistically available resources anyway) and do not provide sufficiently visible (or understandable) tailoring advice.

> certificate is to connect en-clair with no encryption.

I would argue that if that situation occurs in a non-trivial number of cases then the standards in question have problems which need to be fixed in order to better serve their intended purpose.  Being easy to deploy properly is a necessary design goal.

> what the consequences of different implementation choices.

Agree, but I'm not sure that changes anything.

> directions for a specific audience.

Too narrow.  I think it's more complex than that.

For a simple spec, I think you should describe security properties w.r.t. deployment (or other) choices.  If it becomes difficult to relate the audience to all the properties, then a separate spec may be needed, especially if the choices are significantly disparate.

> its inbound and outbound security policy via DKIM, DANE, TBS and so

It's way too easy to overload the typical customer which choices they don't understand or (maybe legitimately) don't care about.

> on a single protocol that is in development.

???

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Jun 2012 14:36:13 -0400

> use of the public key in the cert.

Or phrased another way, because the extension contains information
restricting the use of the certificate or the public key contained
therein.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 28 Jun 2012 15:18:36 -0500

On 06/27/2012 10:46 AM, Phillip Hallam-Baker wrote:
> frequently inappropriate in a real world situation.

We're talking about IETF internet-oriented protocols. The end-to-end 
principle implies that security has to reside in the protocols 
implemented at the endpoints because it cannot reside in the network itself.

> If you are

One of these scenarios is far more relevant to the IETF scope than the 
other.

> directions tend to be the most acrimonious and heated.

Perhaps this a symptom that security is important.

> We come from

Document it! Seriously, working out the when, where, and why of security 
requirements sounds like a very valuable activity.

> bearing on interoperability.

Look at it another way: it's rarely possible for a protocol to provide 
both perfect security and perfect interoperability simultaneously. 
Consequently the entire purpose of many protocol security controls is to 
detect the possibility of an insecure connection and then refuse to 
interoperate.

> They are not necessary decisions for a

I agree with this, except in the cases where one endpoint relies on 
another to perform certain checks.

For example, an https server relies upon a web browser to validate the 
cert seen by the client. Short of requiring TLS client certs, the server 
has no ability to prove the absence of an active MitM attacker.

So unless we take the position that an https server has no interest in 
the security of the connection, we need to say that a correct 
implementation of https requires the client to do as good a job 
validating the cert as the legitimate server would have done had it been 
able to.

> something that should be part of a separate discussion.

There's a difference here between signature algorithms and encryption 
cipher suites.

A signature algorithm is relied upon to ensure the integrity of the 
negotiated information (such as the choice of cipher). What this means 
in practice is that when the signature algorithm is optional or 
negotiable usually the attacker ends up being free to choose among all 
supported options the weakest configuration to attack.

An example is what happened with XML encryption. The signature is 
optional, so rather than need to forge any type of signature the 
attacker is free to simply omit the signature altogether. This enabled a 
very practical attack on the encryption which, under the right 
circumstances, is severe enough to defeat the encryption entirely.
> http://blog.cryptographyengineering.com/2011/10/attack-of-week-xml-encryption.html

So it's essential that standards which rely on a signature algorithm for 
security specify a set of minimum acceptable algorithms from the very 
first version that will be expected to interoperate.

- Marsh

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jun 2012 13:23:30 -0700

> implemented at the endpoints because it cannot reside in the network

FWIW, that principle states that hop-by-hop security does not substitute 
for end-to-end security. It never says that hop-by-hop security isn't 
useful.

Joe

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Jun 2012 16:45:21 -0400

> for end-to-end security. It never says that hop-by-hop security isn't 

Actually, the principle we generally mean when we cite "end-to-end" says
that _state_ needs to reside in the end nodes, with the network itself
being stateless.  That makes communication between end nodes resilient
to network components discarding (or not having) state, and especially
to the notion inherent in a packet-switched network that not every
packet will always follow the same path.

That principle doesn't necessarily imply that security has to be
end-to-end, and it doesn't necessarily apply above the network layer.
While it is often "better" for security to be end-to-end, that is not
always the case, and it's certainly not essential.  As an example,
RADIUS' exclusive use of hop-by-hop security has contributed to making
it the most successful federated authentication system in the world.

-- Jeff

---

From: Marsh Ray <[email-masked]>
Date: Thu, 28 Jun 2012 16:37:58 -0500

> end-to-end, and it doesn't necessarily apply above the network layer.

I don't care if my packets are passed by untrusted routers over 
untrusted network links. The untrusted network has only ability to 
blindly DoS my packets by dropping them.

So any data integrity or confidentiality I obtain must be provided by 
systems I "trust", i.e., components I am willing to rely upon. Since the 
model allows endpoint systems to connect directly to untrusted networks 
(e.g. public Wifi), the primary security controls must live in the 
endpoints themselves.

> it the most successful federated authentication system in the world.

RADIUS packets are routable but the RADIUS protocol doesn't have the 
notion of multiple "hops", so we can't meaningfully distinguish 
hop-by-hop from end-to-end. For security, RADIUS relies upon a shared 
secret stored at each endpoint.

RADIUS can be routed over the internet, but it would be considered bad 
practice to do that because it would not be acceptably secure to modern 
standards. It sends the username and almost all attributes other than 
the password itself in the clear.

RADIUS is popular and works great in a datacenter or trusted WAN 
environment. But it is *not* an example of a good internet security 
protocol.

- Marsh

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jun 2012 14:58:43 -0700

On 6/28/2012 1:45 PM, Jeffrey Hutzelman wrote:
> being stateless.

It's really more that "end to end services cannot be created *solely* 
through the composition of hop-by-hop services" - that includes state, 
computation, and message exchanges.

FWIW, that doesn't discount the use of hop-by-hop services. They're 
useful between the hops (consider each hop its own "end" in an 
end-to-end way), and they can also help make an E2E service more 
efficient (consider per-hop ARQ, which in some cases can be more 
efficient than E2E).

 > That makes communication between end nodes resilient

A protocol is more than just state. No amount of state will make 
hop-by-hop security equivalent to end-to-end security because the 
intermediate nodes see cleartext.

> end-to-end, and it doesn't necessarily apply above the network layer.

The principle never says where the ends are, and it definitely applies 
to all layers.

> it the most successful federated authentication system in the world.

See above - hop-by-hop definitely protects the hops, and also can be 
helpful in E2E performance (e.g., by rejecting things that the hop can 
discard).

Joe

---

From: Marsh Ray <[email-masked]>
Date: Thu, 28 Jun 2012 17:01:56 -0500

On 06/28/2012 04:37 PM, Marsh Ray wrote:
>
> the RADIUS protocol doesn't have the notion of multiple "hops",

I take this back. The RFC 2865 defines a "Proxy-State" attribute
http://tools.ietf.org/html/rfc2865
specifically to support the idea of RADIUS proxies introducing multiple 
hops.

However, it also says "Usage of the Proxy-State Attribute is 
implementation dependent. A description of its function is outside the 
scope of this specification." In other words, it is an optional free 
form field available for a RADIUS proxy to use if it wants to.

In fact, where I work (PhoneFactor) we make a RADIUS proxy and we do not 
use this attribute. It was a long time before we encountered any other 
systems in the field using it.

> so we can't meaningfully distinguish hop-by-hop from end-to-end.

Because the protocol attaches no semantics this attribute, I think the 
conclusion is still generally valid.

- Marsh

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jun 2012 15:02:35 -0700

> blindly DoS my packets by dropping them.

It can delay them and reorder them too - both create work for you, 
depending on your goal.

An protected hop allows *anyone* on the path to inject load that can 
cause your packets to be dropped due to capacity limits. Protected hops 
reduce that possibility. I.e., this isn't just about protecting you from 
false packets, but also from protecting the network capacity and 
infrastructure. E2E security doesn't do either of those two latter things.

Joe

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Jun 2012 18:46:16 -0400

> the password itself in the clear.

  All major RADIUS proxying is done via IPSec tunnels.  EDUROAM uses
RADIUS over TLS.

> environment. But it is *not* an example of a good internet security

  The benefit of RADIUS is that it's simple.  This means it's deployed.
 Deployed security protocols are infinitely better than undeployed ones.

  e.g. see the uptake of TLS versus IPSec.  I won't argue about the
protocol complexity, but TLS was absolutely easier to deploy.  As a
result, it's used to secure all major web sites.  IPSec... less so.

  Alan DeKok.

---

From: Jeffrey Schiller <[email-masked]>
Date: Thu, 28 Jun 2012 19:04:36 -0400

On Thu, Jun 28, 2012 at 4:18 PM, Marsh Ray <[email-masked]>
wrote:
>> If you are building an email application then maybe the right
>> response to an expired certificate is to break. If you are building
>> a heart and lung machine or an airplane then your imperative might
>> well be to keep the thing running at all costs unless there are
>> very good, explicit reasons to shut down.
>
>
> One of these scenarios is far more relevant to the IETF scope than
> the other.

Don't be too sure. It is hard to know where our work will be
deployed. I remember the first time I saw a Boeing 777 cockpit
display. Sure looked like it was running the X Window System (and I
believe it does). You can bet that the authors of the X Window System
were not anticipating that as a usage case at the time they wrote the
code.

Some code I wrote, a long time ago, for talking to a TELEX machine
wound up inside an transformer monitoring application... where it was
in the loop for sending messages of the form "transformer about to
explode!"

                        -Jeff

- --

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Jun 2012 18:00:45 -0500

> result, it's used to secure all major web sites.  IPSec... less so.

<cue-record type='broken'>
Well, yeah, what makes IPsec complex is that it's in such a low layer
that it's been difficult (i.e., hasn't happened) to build proper APIs
to it.  IPsec for end-to-end is dead.
</cue-record>

There's lots of lessons to draw from our experiences.  But I think
it's too soon to say that if only we were less stringent about
security everything would be better, as some would seem to have it.
Interop is king, yes, but let's not throw the security baby out with
the bathwater.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Thu, 28 Jun 2012 18:28:58 -0500

> in the loop for sending messages of the form "transformer about to

Sure, but the point is that the medical, aviation, and power 
distribution industries each have their own dedicated regulatory bodies 
precisely because they each have unique and very critical requirements. 
They are certainly free to use and benefit from IETF standards like 
anyone else, but they are responsible for re-certifying them to their 
own purposes.

As such, they're probably not great examples to use for thinking about 
typical IETF standards. Maybe they could even be a little misleading.

At the very least, an email delivery operation seems like a better 
motivating use case.

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Jun 2012 18:39:10 -0500

On Thu, Jun 28, 2012 at 6:28 PM, Marsh Ray <[email-masked]> wrote:
> Sure, but the point is that the medical, aviation, and power distribution
> industries each have their own dedicated regulatory bodies precisely because
> they each have unique and very critical requirements. They are certainly
> free to use and benefit from IETF standards like anyone else, but they are
> responsible for re-certifying them to their own purposes.

Too many engineers will just pick something off the shelf.  And
regulations aren't remotely fail-safe -- too often it's possible to
get exemptions from various rules, and I'm sure this applies to many
industries.

Nico
--

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Jun 2012 20:40:53 -0400

> security everything would be better, as some would seem to have it.

  My point was about ease of use.  Being less stringent about security
is an orthogonal axis.

  Given a choice between "mostly" secure but simple, or "very" secure
but complex... history shows that the simpler system gets deployed.  The
complex and "very" secure system largely gets ignored.

  Alan DeKok.

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Jun 2012 19:54:41 -0500

>  My point was about ease of use.  Being less stringent about security

To a point.  Not having to worry at all about security sure makes
deployment and use much easier.

> complex and "very" secure system largely gets ignored.

Sure, but what's complex about IPsec?  IKE + ESP is very similar to
TLS in many ways, but I'd argue that the problem there has to do with
layering: IP is the wrong layer for security that applications and
users care about.  While TLS is very much at the right layer, being
above TCP.  In particular being above TCP means that implementations
can be purely in user-land, and they can deal in authenticating user
and hostnames/services rather than IP addresses (which are meaningless
to users).  The point: the complexity of something like IPsec is
implied, as opposed to being a question of how its messages are
encoded, or what crypto is used.  What makes something simple and easy
to use may not be obvious.

Nico
--

---

From: Alan DeKok <[email-masked]>
Date: Fri, 29 Jun 2012 07:55:06 -0400

Nico Williams wrote:
> Sure, but what's complex about IPsec?

  Integrating it, using it.  When FreeSWAN was starting, I had a
conversation at the Minneapolis Hotel bar:

FreeSWAN guy: Hey, you're using Linux, why not IPSec?

Me: Here's my laptop with a root shell

... 3 hours later ...

FreeSWAN guy: Huh.  I can't get it to work.

  In contrast, OpenSSL is an application library.  The API is horrible,
but I had a test program up and running in less than an hour.

  Since then, I do remote administration on occasion.  To be polite,
IPSec works well when they have a gateway from vendor X, and I use a
client from vendor X.  For any other combination, the success rate is
about 20%.

>  IKE + ESP is very similar to
> to users).

  And the application *knows* it's secure.  With IPSec, it's impossible
for the application to be sure.

  From a usability point of view, TLS could very well have been socket
options.  "Use this client certificate", or "require security".

>  The point: the complexity of something like IPsec is

  It was pretty obvious to me.  Kernel mods?  Hard.  User-space library?
 Easy.

  Alan DeKok.

---

From: Mouse <[email-masked]>
Date: Fri, 29 Jun 2012 11:22:51 -0400 (EDT)

>> [TLS, as compared to IPsec]

To the extent that the latter sentence is true, it's a missing feature
in the exported API, something which is entirely fixable.

> It was pretty obvious to me.  Kernel mods?  Hard.  User-space
> library?  Easy.

You can do IPsec in userspace too; you just need to, at most, move the
rest of the IP stack into userspace along with it.  There are already
multiple user-space IP stacks (or at least so I'm told, and I find it
hard to believe they wouldn't exist, though I've never played with one
myself); one of them might be a good place to start if you want to try
that.

But, really, what's the difference between a userspace library and a
kernel mod?  Unless you're grubbing around in the internals of
whichever one you're using, the major difference is that kernel APIs
tend to be better defined and more constrained.  (For poorly-tested
code, there's also the question of what happens when you tickle a bug,
but I consider that a minor issue for the purposes of this discussion.)

I think the reason IPsec is harder to use in practice is that it's a
good deal more complex; in particular, TLS's solving a significantly
smaller problem also means the solution is smaller and simpler.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Jun 2012 11:55:17 -0500

> in the exported API, something which is entirely fixable.

Exactly.  There was an effort a few years ago to add IPsec APIs (see
BTNS WG), but there was not enough interest.  Fifteen or twenty years
ago IPsec APIs would have come in handy.  Now there's no point.  IPsec
for end-to-end is dead (just don't tell iSCSI).

> kernel mod?  [...]

Ease of development.  Kernel space? -> difficult.  Though kernel space
forces more discipline, which is good.

> smaller problem also means the solution is smaller and simpler.

IPsec wants to authenticate IP addresses, which is useless.  With APIs
it could authenticate whatever identities the apps have credentials
for, but there are no IPsec APIs.  Other than that IPsec and TLS have
equivalent degrees of complexity, particularly when one throws in
DTLS.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Jun 2012 13:17:38 -0400

> restricting the use of the certificate or the public key contained

This is why I used the term 'Conditions' in SAML.

SAML conditions are intended to be used in precisely the same way that
the X.509v3 critical bit should be used. But I used the term
conditions because the conflation of 'critical bit set' and
'important' had been completely unhelpful in PKIX.

There is no place in a spec for a 'yes I really mean it' bit. Either
the cert issuer means it or they don't. 'Feel free to ignore this if
you don't understand' is perfectly acceptable (in SAML terms
'advice'). but a cert issuer should not say something they don't
understand and mean.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Jun 2012 13:28:11 -0400

On Thu, Jun 28, 2012 at 4:18 PM, Marsh Ray <[email-masked]> wrote:
> principle implies that security has to reside in the protocols implemented
> at the endpoints because it cannot reside in the network itself.

That is not the end-to-end principle described by Clark. His proposal
was descriptive, not normative.

Putting security in the network has certain consequences, putting them
at the endpoints has other properties. What a lot of people can't get
to grasps with is that end-to-end security really means something is
secured from one PERSON or ORANIZATION to another. The concept
pre-dates computer systems.

So no IETF protocol can ever offer true end-to-end security as we
specify protocols, not people.

End-to-end is a design choice and it comes with certain costs and
certain benefits. Effective real world security designs invariably use
multiple layers of security. S/MIME is not going to give you perfect
confidentiality (the subject lines are not encrypted for a start), nor
is STARTTLS. An effective security solution is going to require both
(plus some stuff we don't yet have).

I think we have tended to forgo a lot of good enough security that
could have been deployed on the Internet because people insisted on
'absolute' which was impractical. It only takes a small practical
limitation to render a whole spec useless. For example none of the
IPSEC implementations in the platforms was a practical enterprise
security solution because they didn't implement the necessary hacks to
enable NAT bypass. S/MIME use is crippled by the fact that client
certs expire and so on.

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 13:00:43 -0700

> but I had a test program up and running in less than an hour.

In contrast, I can shut down your OpenSSL connection by sending RSTs at 
your TCP connection, where I can't attack a TCP connection protected 
with either IPsec or TCP-AO (except as a DOS attack on the whole link).

SSL/TLS does nothing to protect the transport or network layers.

...
>> above TCP.

The "right layer" depends on the threats; if threats don't include 
direct attacks on your connection, you might be OK with TLS. If not, TLS 
will do nothing to help.

...
>    It was pretty obvious to me.  Kernel mods?  Hard.  User-space library?

It's obvious to me too:

Kernel mods - safe and fast.

User space mods - unsafe and slow.

So you have "easy" but not safe or fast. That means you get people to 
use it, but not that you're doing a better job protecting things.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 13:13:00 -0700

On Fri, Jun 29, 2012 at 1:00 PM, Joe Touch <[email-masked]> wrote:
> In contrast, I can shut down your OpenSSL connection by sending RSTs at your
> TCP connection, where I can't attack a TCP connection protected with either
> IPsec or TCP-AO (except as a DOS attack on the whole link).

This turns out to not be that important a practical issue for most scenarios,
especially for the Web where short connections are the norm.

> So you have "easy" but not safe or fast. That means you get people to use
> it, but not that you're doing a better job protecting things.

Why do you think user space is unsafe or slow?

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Fri, 29 Jun 2012 20:33:30 +0000

IPSEC and TLS are complementary. They solve different problems, at different layers.

Microsoft is using IPSEC extensively for our internal network. The basic rule is "you cannot set a TCP connection to one of the computer in the network if you cannot establish an IPSEC connection first." We market that as "service and domain isolation" (http://technet.microsoft.com/en-us/network/bb545651.aspx). What it does is effectively enforce a big distributed firewall around the domain's computers, independent of the particularities of network wiring and routing. This is one of the layers in the "defense in depth" approach.

But even with IPSEC, we also use TLS, for example if you want to connect to a high value server. IPSEC is good at preventing undesirable connections from unknown computers. TLS is good at securing application connections from identified users.

And yes, the deployment issues with IPSEC are interesting. Making the solution work fine took a lot of effort.

-- Christian Huitema

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 29 Jun 2012 16:34:17 -0400

/me parachutes into the thread

> especially for the Web where short connections are the norm.

Will this continue to be the case with WebSockets and/or HTTP/2.0 (==SPDY)?

> Why do you think user space is unsafe or slow?

Why do IP stacks usually reside in the kernel?

--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 13:40:51 -0700

> Will this continue to be the case with WebSockets and/or HTTP/2.0 (==SPDY)?

My impression is yes. There are just too many intermediate elements which
like to shut stuff down to be able to build an app which can't deal with
losing connections, especially on mobile.

> Why do IP stacks usually reside in the kernel?

Because they always have?

Seriously, the operating systems we are working with were designed in
an era where multiprocessing was taken seriously and the job of
the kernel was partly to protect one user from another. Hence the
restrictions on accessing port 1024, promiscuous mode, and
raw IP data transmission unless you are root on UNIX. AFAIK
this isn't a performance issue, nor is it really a safety issue from
the perspective of the application.

-Ekr

---

From: Mouse <[email-masked]>
Date: Fri, 29 Jun 2012 16:47:13 -0400 (EDT)

>>> User space mods - unsafe and slow.

Calling in-kernel "safe" and userspace "unsafe" betrays an interesting
bias with respect to what "safety" is.  There are kinds of safety I
care about for which userland is substantially safer than the kernel.

> Why do IP stacks usually reside in the kernel?

Honestly?  Because, "usually", the system is a conceptually monolithic
kernel that, because of its privilege design, can't really put it
anywhere else.  Under a microkernel design, rather than the traditional
kernel that's commonest these days, the IP stack _is_ in user space.

					Mouse

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 13:50:39 -0700

...
> Why do you think user space is unsafe or slow?

Kernel based implementations come from the OS manufacturer (ideally), or 
at least require privilege to modify. Not so for user-space.

User-space protocols are not nearly as efficient in dealing with 
drivers, and can't take advantage of hardware assist in outboard devices.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 14:01:46 -0700

On Fri, Jun 29, 2012 at 1:50 PM, Joe Touch <[email-masked]> wrote:
> Kernel based implementations come from the OS manufacturer (ideally), or at
> least require privilege to modify. Not so for user-space.

I don't understand what your threat model is. Say that tomorrow OS/X shipped
with an SSL/TLS stack in the kernel. How would this be any more secure
from the perspective a SSL/TLS using application, seeing as any attacker
who can modify the (formerly) userland stack can modify the application
that uses SSL/TLS?

> User-space protocols are not nearly as efficient in dealing with drivers,
> and can't take advantage of hardware assist in outboard devices.

I've written plenty of applications which use crypto accelerators. They
just need to have the kernel mediate the interaction.

More importantly, for the purposes of crypto (and that's the topic on
the table), either it's incredibly CPU intensive, in which case drivers
don't matter, or it's really fast, in which case the network is the
bottleneck. I don't think I've every seen a crypto-using application
on a modern system which woud have its performance significantly
improved by being in the kernel.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 14:07:43 -0700

Hi, Eric,

...
> who can modify the (formerly) userland stack can modify the application

That's why SSL/TLS is less secure than IPsec. Userland can't access IP 
directly without privilege.

> just need to have the kernel mediate the interaction.

The kernel needs to make sure that multiple users can share the 
hardware. That's not typically supported on most outboard protocol 
accelerators.

You can point to an exception perhaps, but it's not the typical case for 
hardware designers, drivers, or kernel support.

> bottleneck.

Or it is slow in software and fast in dedicated accelerator hardware, 
and the hardware isn't designed to be shared by userspace apps.

> I don't think I've every seen a crypto-using application

It would if being in the kernel gives it access to hardware that it 
can't get to otherwise.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 14:13:30 -0700

On Fri, Jun 29, 2012 at 2:07 PM, Joe Touch <[email-masked]> wrote:
>>> at

"less secure" is meaningless without a threat model. What threat model
are you operating under?

> Or it is slow in software and fast in dedicated accelerator hardware, and
> the hardware isn't designed to be shared by userspace apps.
>
>
> It would if being in the kernel gives it access to hardware that it can't
> get to otherwise.

I'd be interested in seeing an actual example where this matters. I can't
think of a system where (a) crypto performance was a bottleneck
and (b) multiple, noncooperating processes needed to do a lot of
crypto such that they would have to share a piece of crypto hardware.

Can you point me to such a real-world system?

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 14:17:31 -0700

On 6/29/2012 2:13 PM, Eric Rescorla wrote:
...
> Can you point me to such a real-world system?

You already did - userspace IPsec.

Kernel-space IPsec doesn't have that issue.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 14:22:41 -0700

> Kernel-space IPsec doesn't have that issue.

Crypto performance isn't a bottleneck for essentially any IPsec-using
user machine because the processor is so fast compared to the
available network resources. Really the only time when crypto
performance becomes a bottleneck is concentrators, but in
those cases it's just one application process, even if it's a bunch
of instances of it.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 14:33:57 -0700

On 6/29/2012 2:22 PM, Eric Rescorla wrote:
...
> available network resources.

For network speeds under 10Mbps maybe, but then you're tying up part of 
a CPU too.

 > Really the only time when crypto

Or servers. Or machines on work connections that use company-based 
resources.

USC has tens of thousands of such machines. That's not trivial.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 14:38:40 -0700

On Fri, Jun 29, 2012 at 2:33 PM, Joe Touch <[email-masked]> wrote:
> For network speeds under 10Mbps maybe, but then you're tying up part of a
> CPU too.

What kind of processer are you using, a Z80? My Macbook Air does 800 Mb/s of
AES on one core.

> Or servers.

Most servers have one dominant kind of traffic they generate
and even if you can't share the crypto resources (which I'm
not conceding, btw), that type of traffic can get it.

> Or machines on work connections that use company-based
> resources.

I don't see what "work connections" has to do with it.

Do you have any actual measurements of crypto load on some
real-world traffic profile that supports this argument?

-Ekr

---

From: Ted Ts'o <[email-masked]>
Date: Fri, 29 Jun 2012 18:58:54 -0400

> but I consider that a minor issue for the purposes of this discussion.)

<Blast from the past>
One of the problems, which was recognized back when I was the IPSEC
chair, althouh we were never able to do anything about it, was the
bias that "IETF doesn't do API's"; in many ways the GSSAPI was the
exception which proved the rule.  Part of the problem was not just the
institutional bias, but also the fact that most IETF attendees back
then (I can't really speak for now) didn't have API design as one of
their strengths / core competencies.

If we had designed a IPSEC API, much like the BSD Sockets layer was a
defacto standard API to TCP/IP, I think it would have done a lot to
help the situation.  That would have meant exposing things like x509
certificate names in a sane, easy-to-use, and platform independent way
via C bindings, which IMHO is still an unsolved problem, it would have
made it a lot easier for applications to use IPSEC for end-to-end
authentication.

There still would have been major deployment challenges, and this
might have not been enough (TLS still would have been easier from a
deployment perspective, which is really important if you are an
application provider/vendor), but IPSEC as an end-to-end application
security mechanism would have at least had a fighting chance.
</Blast from the past>

					- Ted

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 16:50:17 -0700

On 6/29/2012 2:38 PM, Eric Rescorla wrote:
...
> What kind of processer are you using, a Z80? My Macbook Air does 800 Mb/s of

It also matters for cellphones and even sensor nets.

> not conceding, btw), that type of traffic can get it.

Everything is a server in some systems.

> I don't see what "work connections" has to do with it.

Most people's workplaces have a higher bottleneck BW than home or coffee 
shops. And the rest of the world includes home connections in excess of 
several hundred Mbps, which can easily swamp a modern CPU's resources.

> real-world traffic profile that supports this argument?

My last graphed measurements of this were in an NPSEC 2006 paper, and 
show that an entire Xeon CPU (within noise of current ones) gets around 
50Mbps at 100% load.

Joe

---

From: Alan DeKok <[email-masked]>
Date: Fri, 29 Jun 2012 20:00:59 -0400

> show that an entire Xeon CPU (within noise of current ones) gets around

  Well... I've measured commodity systems doing 940+ Mbps with AES-256.
 This is in the last 4 months, using 2 year-old systems, and 1.5K packets.

  If you need crypto acceleration to fill a 1G pipe, then your system
has less CPU power than my iPhone.

  Alan DeKok.

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 17:11:46 -0700

>   This is in the last 4 months, using 2 year-old systems, and 1.5K packets.

It would be useful to know if that actually sent packets on the wire 
(not in-memory measurements), and if so, how much of your CPU was gone 
in the process.

> has less CPU power than my iPhone.

Your iPhone certainly can't run anywhere this fast.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 17:21:51 -0700

Hi, Ted,

On 6/29/2012 3:58 PM, Ted Ts'o wrote:
...
> bias that "IETF doesn't do API's";

Except that the best protocols we have - TCP being a good example - 
included APIs in their definition.

The sockets API in Unix is basically a direct implementation of the user 
interface specified in RFC 793.

It's not too late to do such an API, IMO. Or at least better late than 
never.

Joe

---

From: joel jaeggli <[email-masked]>
Date: Fri, 29 Jun 2012 17:37:25 -0700

> What kind of processer are you using, a Z80? My Macbook Air does 800 Mb/s of
I find the "we have an application for a processor too slow to use 
crypto" argument to be a little bothersome.

contact-less rfid tags  have crypto engines on them. motorola 68020's 
run ssh acceptably for some use cases. the performance envelope of low 
power embedded controllers  that exist now and into the future is 
sufficient to support crypto at rates necessary to meet application 
requirement's in many cases and where it is not is not itself a 
justification  for not pushing the stack and the applications in that 
direction. There are more devices in the future than in the past.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 17:43:06 -0700

On Jun 29, 2012, at 17:11, Joe Touch <[email-masked]> wrote:

> It would be useful to know if that actually sent packets on the wire (not in-memory measurements), and if so, how much of your CPU was gone in the process.
> 

You realize that an iPhone only allows one foreground process so it hardly matters if it doesn't share the hardware encryption chip (if there even is one)

Ekr

---

From: Alan DeKok <[email-masked]>
Date: Sat, 30 Jun 2012 08:18:50 -0400

Joe Touch wrote:
> (not in-memory measurements),

  If your best counter-argument is to assume I'm a complete idiot, that
explains why your tests only get 50Mbps.

  For more reality-based counter-arguments, see the "high performance
SSH" patches.  They're also getting better than 900Mbps with crypto on
commodity hardware.

  Alan DeKok.