Fwd: Chat with [e-mail]

[Mark Miller-2]

Thomas, Kevin & I would like to thank you from prodding us into a
breakthrough simplification of CapTP prodded by your first question.
After the following chat, Kevin & I continued with a verbal
conversations whose insights we will be writing up at
<http://wiki.erights.org/wiki/The_lost_resolution_bug_isn%27t>. The
punch lines of these insights are:

* We decide that the Lost Resolution Bug
<http://www.erights.org/elib/equality/passing-rules.html#lost-resolution>
is a feature, not a bug ;). For reasons we did not previously
appreciate, this cannot ever be fixed, even with the WormholeOp
<http://www.erights.org/elib/distrib/captp/WormholeOp.html>.

* Since we no longer plan to ever solve the Lost Resolution feature
;), we no longer have any need for SwissHashes in the CapTP protocol.
SturdyRefs still need SwissNumbers of course. But object that are only
ever exported as live references no longer even need to be assigned
SwissNumber, also greatly reducing our hunger for new entropy.

* We also no longer have any need for Far3Desc or WormholeOp. They are
currently stubbed out. They should simply be removed.

* ConstMaps may have keys that are pass-by-proxy objects. Lost
Resolution means that a ConstMap containing far refs as keys, sent to
a third vat, will arrive as a promise that only resolves to a ConstMap
once it's keys become settled again. This requires an ability to
effectively to a whenSettled, which can mostly be coded in E. But one
problematic case to be explained and examined (non-transparent
potentially unsettled selfless objects) may require a new primitive.


---------- Forwarded message ----------
From: kpreid@... <kpreid@...>
Date: Fri, Aug 28, 2009 at 8:52 PM
Subject: Chat with kpreid@...
To: erights@...


7:10 PM kpreid: hello?
 me: hi!
7:15 PM kpreid: Any topics?
  It's that time of the week again.
7:16 PM me: I know. I was going to look at the recent e-lang thread
tonight. I saw there were questions for me.
 kpreid: ok
________________________________
16 minutes
7:33 PM kpreid: BTW, you have an IM status of "I am MarkM's status"...
 me: Yes, actually, that's my status' status.
________________________________
16 minutes
7:50 PM me: On the first question for me, from looking at the
E-on-Java implementation, it seems the swissHash is is only used for
the bad old EProxyResolver sameness comparison.
  What is it used for in your captp implementations?
7:52 PM kpreid: It is, in fact, not used. But since my captp
implementation is not well-tested especially on 3party stuff we should
not rely on that.
  Remember, my captp has never been actually used to communicate between vats.
 me: Not even your captp on E-on-CL?
7:53 PM kpreid: Right.
 me: ok. I'll look at the 3-party stuff some.
7:54 PM (vaguely) I do think I remember thinking it was needed there.
 kpreid: I think my captp assumes that since it's *New*FarDesc futhre
refs will be to the same object.
  That is, only one proxy will be constructed.
7:56 PM me: for 2 parties only, I'm confident that's correct.
8:00 PM http://www.erights.org/javadoc/net/captp/jcomm/CapTPConnection.html#getLookup%28org.erights.e.elib.tables.ConstList,java.lang.String,java.math.BigInteger,java.math.BigInteger,java.lang.Object%29
8:01 PM Only relevant in a system like your in which the lost
resolution bug has been fixed.
 kpreid: I HAVE NOT FIXED LOST RESOLUTION.
 me: s/your/yours/
 kpreid: I have only an idea about it.
 me: Ah.
  Still, only relevant in such a system. Stubbed out in E-on-Java.
8:02 PM kpreid: OK, relevant how?
8:03 PM OK, I seepartly. Far3desc is only used if WormholeOp is
available, right?
 me: VatB needs to unserialize the Far3Desc into a resolved reference
immediately, before hearing back from VatB.
  Yes.
 kpreid: Ah, so it has a swiss number which it looks up by the hash
8:04 PM me: I don't think that's the issue.
  If VatB already has a far ref to Carol on VatC, then VatB knows
Carol's swissHash but not her swissNumber.
8:05 PM However, the Far3Desc arriving from VatB has to unserialize
into the same far ref that vatB already has.
 kpreid: I was thinking that when VatB gets the Far3Desc, it hashes
the number and looks up the hasj in its own table.
8:06 PM me: Far3Desc has a swissHash, not a swissNumber.
 kpreid: Right, but you can hash the num to get the hash.
8:07 PM me: But in the live 3-party protocol, no one is assumed to
know the number, just the hash.
 kpreid: OK, I was confused...I thought getLookup used a SwissNumber
  But I see it does get a hash.
8:08 PM So where's the problem?
  Ah, the nonce should be sufficient?
  Oh. The swissHash is used to make sure identities are coherent, perhaps?
8:09 PM me: The nonce is sufficient to establish access once vatB
talks to VatC. The swissHash is used to ensure identities are coherent
immediately on arrival of the Far3Desc in VatB.
8:11 PM Nonce's grant access. SwissNumbers grant persistent access.
SwissHashes grant ability to claim sameness, for example, for a
capabilities-as-keys comparison based service on VatB.
 kpreid: SwissNumbers don't grant persistent access in general.
  The 3-vat protocol uses swiss numbers, doesn't it?
 me: This may be a bad design -- the swissHash may be granting more
access than it should. But that's what I was thinking.
8:12 PM kpreid: Well, swissnumber says you have access to the object.
And you can compute the shash from the snum. So the snum shouldn't be
authority-to-claim-to-be.
 me: No. Not since we switched to the nonce/table-based protocol.
 kpreid: the shash, I meant
 me: Yes, but only for Far3Desc. Promise3Desc doesn't carry a shash.
8:13 PM kpreid: Well, but that's wrong.
 me: Why?
 kpreid: I shouldn't be able to spoof an identity by knowing the hash...
  by knowing the snum (which implies knowing the shash) I mean
8:14 PM me: Why not?
________________________________
5 minutes
8:20 PM me: I think this is a really important question. Even if you
have a half baked objection, please voice it because it may lead to a
genuine flaw. I am worried about this issue -- it's the "This may be a
bad design" I mention above.
 kpreid: Access to an object does not imply authority to be an object
  This is the swisshash/swissbase distinction.
  I mean, swissnum/swissbase.
8:21 PM me: Swissbase = authority to be the object.
  SwissNum = authority to access the object.
8:22 PM SwissHash = designation without authority -- the object's
identity without access to it.
8:23 PM The hard question that got me started on this: What is
serialized when you send a DisconnectedRef?
 kpreid: You yourself said "SwissHashes grant ability to claim sameness"
8:24 PM me: A DisconnectedRef should be somehow comparable to a far
ref to the same object, but it shouldn't give access to that object.
8:25 PM This also dates from before the proxy revolution, when I think
DisconnectedRefs and live FarRefs to the same object actually compared
as the same. Perhaps the whole thing needs to be rethought in light of
our more principled remote sameness story.
8:27 PM kpreid: I remember this discussion.
  FarRefs and Disc.Refs are not equal.
8:28 PM As long as you have a connection from you (say VatA) to VatB,
there is only one connection.
  So there is only one far ref, and it turns into a DisconnectedRef.
 me: Yes indeed it does need to be rethought. The newly arriving
Far3Desc cannot unserialize into a far ref that's the same as a
preexisting one, because if the nonce lookup fails, the arriving
farRef will break whereas the preexisting one won't.
 kpreid: (Only one far ref per remote object, I mean)
8:29 PM If you later reconnect, you get a Far ref which is not the
same as the previous Disconnected ref
  This scheme has all the properties we want, I believe.
8:30 PM Wait, what's wrong with the arriving ref broken, provided it
is unconnected rather than disconnected?
  After all, the nonce lookup failed = protocol error
 me: So here's the problem. Say we fixed the comm delay problem
causing the lost resolution bug. I don't care whether we fix it by
WormholeOp or otherwise.
8:31 PM At the moment a Far3Desc arrives from VatA, VatB does not yet
know whether the non-lookup will succeed. What does VatB create in the
meantime for delivery to Bob?
8:32 PM s/non/nonce/
 kpreid: Why does it not know?
 me: Requires a round trip to VatC that hasn't happened yet.
 kpreid: Oh, I see.
  Thinking.
8:34 PM So the problem is that VatA tells VatB about a VatC object
that may not even exist.
  Yes?
  ...that VatB doesn't know about already.
8:35 PM me: If vatB actually doesn't know about it, then there's no
problem, since there's no preexisting far reference that creates the
sameness dilemma.
8:36 PM If VatB doesn't already know alleged carol, then VatB can
immediately create a fresh far ref to deliver to Bob. It'll break once
the round trip completes, but that's ok.
8:38 PM kpreid: OK, that makes sense. That process doesn't require a
swisshash at all, right?
  We just lookup the nonce on VatC, and VatC can send an ImportDesc if
VatC already sent it out meantime.
8:39 PM Oh, but if VatB knows it...
 me: exactly. that's the problem
 kpreid: ponders
8:40 PM OK, answer this question alone: Given that VatB knows Carol,
how does VatA securely identify the existing B-ref-to-Carol in talking
to VatB, in ignorance of B's knowledge of Carol?
8:41 PM me: The present answer is the swissHash. "SwissHashes grant
ability to claim sameness"
8:42 PM kpreid: OK, by "claim sameness" you mean something unobvious.
  You mean "ability to claim I have the ref you have" apparently
 me: yes
8:43 PM kpreid: It sounds like "ability to claim my ref is the same as
some other ref"
 me: Again, this may be a bad design. I am worried about it.
  yes.
 kpreid: Please find better terminology
 me: Please help me do so ;)
8:46 PM Perhaps the right answer is to just kill Far3Desc and the need
for swiss hashes in captp, and just live with the lost resolution bug,
even if we were to do something WormholeOp-like.
 kpreid: Don't give up yet...
8:47 PM Got skype?
 me: I think so. Lots of computer reconfig. But let's try.
8:48 PM kpreid: I don't hear you.
 me: I can hear you
8:52 PM Skype just told me "connection lost"
 kpreid: Me too


--
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood-2]

Mark Miller wrote:
[...]

> 8:11 PM Nonce's grant access. SwissNumbers grant persistent access.
> SwissHashes grant ability to claim sameness, for example, for a
> capabilities-as-keys comparison based service on VatB.
>  kpreid: SwissNumbers don't grant persistent access in general.
>   The 3-vat protocol uses swiss numbers, doesn't it?
>  me: This may be a bad design -- the swissHash may be granting more
> access than it should. But that's what I was thinking.
> 8:12 PM kpreid: Well, swissnumber says you have access to the object.
> And you can compute the shash from the snum. So the snum shouldn't be
> authority-to-claim-to-be.
>  me: No. Not since we switched to the nonce/table-based protocol.
>  kpreid: the shash, I meant
>  me: Yes, but only for Far3Desc. Promise3Desc doesn't carry a shash.
> 8:13 PM kpreid: Well, but that's wrong.
>  me: Why?
>  kpreid: I shouldn't be able to spoof an identity by knowing the hash...
>   by knowing the snum (which implies knowing the shash) I mean

[...]

We're probably missing some context, but the issue here seems to be
some prover, peggy, needs to be able to demonstrate to a verifier,
victor, that peggy holds a capability C, such that:

 - if victor already holds C, or comes to hold C, then it will recognize
   which of the capabilities it holds is the same as C, and know that
   peggy also holds it (and that C is associated with a particular proof);

 - if victor does not hold C then it obtains neither C, nor the ability
   to give a proof of holding C that will be accepted by other verifiers.

Ideally we want a noninteractive proof that does not require public key
cryptography, other than that required to set up a secure session.

Note that in the case where peggy and victor are vats communicating by
CapTP, there will already be a shared session secret, S_session. If S is
derived by a suitable Key Derivation Function from something like a TLS
master secret, then it is determined by random per-session contributions
from peggy and victor such that neither of them alone can force its value
to be the same as for any previous session between any pair of vats. The
ability to obtain a session secret would also be required by WormholeOp.


Unoptimized protocol to demonstrate feasibility:

Let the proof that peggy holds C in a given session be
P_{C,session} = H(S_session, SwissNum_C), where H is a collision-resistant,
second preimage-resistant, and oneway hash, and SwissNum_C is a globally
unique unguessable identifier for C.

To verify this proof, victor calculates
P_{X,session} = H(S_session, Swissnum_X) for all capabilities X that
it holds. If P_{X,session} = P_{C,session} for some X, then X is the
same as C.


Informal security analysis:

If an attacker can find P_{X,session} = P_{Y,session} for any session
and capabilities X and Y that are not the same, then either
SwissNum_X = SwissNum_Y (contradicting global uniqueness of Swiss numbers)
or the attacker has broken collision resistance of H.

If an attacker can obtain significant information about SwissNum_X
from H(S_session, SwissNum_X), then it has broken onewayness of H.
If given any P_{Y,session} it can generate a new SwissNum_Z such that
a proof of holding Y will also be valid for Z, then it has broken
second preimage resistance of H.

If victor can force S_session' with another verifier to be the same
as S_session with peggy, then it has broken the assumption stated
earlier about the session key of the secure transport protocol.
Without this ability it cannot replay proofs that will be accepted by
another verifier (or, assuming onewayness and second preimage resistance
of H, otherwise construct new valid proofs from old proofs).


Optimization:

The protocol as described above is inefficient because it requires
victor to calculate *per-session* hashes P_{X,session} for all of the
capabilities it holds.

This can be improved by associating each capability X with a "hint"
SwissHint_X (globally, not per-session). SwissHints need not be unique
nor high-entropy, although they should not give away information that
would aid in guessing their SwissNum. Each vat constructs a hash table
mapping SwissHints to the corresponding SwissNums for all the
capabilities it holds.

A proof of holding C becomes a pair (SwissHint_C, H(S_session, SwissNum_C)).
The verifier looks up SwissHint_C in the hash table, which tells it
the SwissNum(s) that *could* match, and then checks them as in the
original protocol. If SwissHint_C is not unique, then the verifier
just checks all potential matches.

Note that unlike proofs in the unoptimized protocol, a proof now does
give away transferrable information about the identity of the capability
it is associated with. It just isn't sufficient information to construct
a proof that will be accepted by an honest verifier. Even a dishonest
verifier (i.e. one that is prepared to accept any implication of the
proof without necessarily following the verification protocol) will
at most have reason to infer that the prover heard some proof that
someone holds the capability, not that it holds the capability itself.

> 8:40 PM OK, answer this question alone: Given that VatB knows Carol,
> how does VatA securely identify the existing B-ref-to-Carol in talking
> to VatB, in ignorance of B's knowledge of Carol?
> 8:41 PM me: The present answer is the swissHash. "SwissHashes grant
> ability to claim sameness"
> 8:42 PM kpreid: OK, by "claim sameness" you mean something unobvious.
>   You mean "ability to claim I have the ref you have" apparently
>  me: yes
> 8:43 PM kpreid: It sounds like "ability to claim my ref is the same as
> some other ref"
>  me: Again, this may be a bad design. I am worried about it.
>   yes.
>  kpreid: Please find better terminology
>  me: Please help me do so ;)

This is the "proof of holding" described above. I hope this is better
and more precise terminology.

--
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Thomas Leonard]

Hi Mark,

That's good to hear. Will the new version be backwards-compatible? How
stable is the protocol?

One thing that is slightly bothering me is that it doesn't seem to use
SSL/TLS. I found this page:

http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html

but it is dated 1998. I think I will have a hard time trying to convince
people that E's custom system is secure / will be updated if problems
are found. It would make my life easier if I could just say it uses the
Java SSL libraries for transport layer security.

Anyway, thanks for a wonderful language! I'm surprised it seems so
little-known.


On Fri, 2009-08-28 at 21:53 -0700, Mark Miller wrote:

> Thomas, Kevin & I would like to thank you from prodding us into a
> breakthrough simplification of CapTP prodded by your first question.
> After the following chat, Kevin & I continued with a verbal
> conversations whose insights we will be writing up at
> <http://wiki.erights.org/wiki/The_lost_resolution_bug_isn%27t>. The
> punch lines of these insights are:
>
> * We decide that the Lost Resolution Bug
> <http://www.erights.org/elib/equality/passing-rules.html#lost-resolution>
> is a feature, not a bug ;). For reasons we did not previously
> appreciate, this cannot ever be fixed, even with the WormholeOp
> <http://www.erights.org/elib/distrib/captp/WormholeOp.html>.
>
> * Since we no longer plan to ever solve the Lost Resolution feature
> ;), we no longer have any need for SwissHashes in the CapTP protocol.
> SturdyRefs still need SwissNumbers of course. But object that are only
> ever exported as live references no longer even need to be assigned
> SwissNumber, also greatly reducing our hunger for new entropy.
>
> * We also no longer have any need for Far3Desc or WormholeOp. They are
> currently stubbed out. They should simply be removed.
>
> * ConstMaps may have keys that are pass-by-proxy objects. Lost
> Resolution means that a ConstMap containing far refs as keys, sent to
> a third vat, will arrive as a promise that only resolves to a ConstMap
> once it's keys become settled again. This requires an ability to
> effectively to a whenSettled, which can mostly be coded in E. But one
> problematic case to be explained and examined (non-transparent
> potentially unsettled selfless objects) may require a new primitive.
>
>
> ---------- Forwarded message ----------
> From: kpreid@... <kpreid@...>
> Date: Fri, Aug 28, 2009 at 8:52 PM
> Subject: Chat with kpreid@...
> To: erights@...
>
>
> 7:10 PM kpreid: hello?
>  me: hi!
> 7:15 PM kpreid: Any topics?
>   It's that time of the week again.
> 7:16 PM me: I know. I was going to look at the recent e-lang thread
> tonight. I saw there were questions for me.
>  kpreid: ok
> ________________________________
> 16 minutes
> 7:33 PM kpreid: BTW, you have an IM status of "I am MarkM's status"...
>  me: Yes, actually, that's my status' status.
> ________________________________
> 16 minutes
> 7:50 PM me: On the first question for me, from looking at the
> E-on-Java implementation, it seems the swissHash is is only used for
> the bad old EProxyResolver sameness comparison.
>   What is it used for in your captp implementations?
> 7:52 PM kpreid: It is, in fact, not used. But since my captp
> implementation is not well-tested especially on 3party stuff we should
> not rely on that.
>   Remember, my captp has never been actually used to communicate between vats.
>  me: Not even your captp on E-on-CL?
> 7:53 PM kpreid: Right.
>  me: ok. I'll look at the 3-party stuff some.
> 7:54 PM (vaguely) I do think I remember thinking it was needed there.
>  kpreid: I think my captp assumes that since it's *New*FarDesc futhre
> refs will be to the same object.
>   That is, only one proxy will be constructed.
> 7:56 PM me: for 2 parties only, I'm confident that's correct.
> 8:00 PM http://www.erights.org/javadoc/net/captp/jcomm/CapTPConnection.html#getLookup%28org.erights.e.elib.tables.ConstList,java.lang.String,java.math.BigInteger,java.math.BigInteger,java.lang.Object%29
> 8:01 PM Only relevant in a system like your in which the lost
> resolution bug has been fixed.
>  kpreid: I HAVE NOT FIXED LOST RESOLUTION.
>  me: s/your/yours/
>  kpreid: I have only an idea about it.
>  me: Ah.
>   Still, only relevant in such a system. Stubbed out in E-on-Java.
> 8:02 PM kpreid: OK, relevant how?
> 8:03 PM OK, I seepartly. Far3desc is only used if WormholeOp is
> available, right?
>  me: VatB needs to unserialize the Far3Desc into a resolved reference
> immediately, before hearing back from VatB.
>   Yes.
>  kpreid: Ah, so it has a swiss number which it looks up by the hash
> 8:04 PM me: I don't think that's the issue.
>   If VatB already has a far ref to Carol on VatC, then VatB knows
> Carol's swissHash but not her swissNumber.
> 8:05 PM However, the Far3Desc arriving from VatB has to unserialize
> into the same far ref that vatB already has.
>  kpreid: I was thinking that when VatB gets the Far3Desc, it hashes
> the number and looks up the hasj in its own table.
> 8:06 PM me: Far3Desc has a swissHash, not a swissNumber.
>  kpreid: Right, but you can hash the num to get the hash.
> 8:07 PM me: But in the live 3-party protocol, no one is assumed to
> know the number, just the hash.
>  kpreid: OK, I was confused...I thought getLookup used a SwissNumber
>   But I see it does get a hash.
> 8:08 PM So where's the problem?
>   Ah, the nonce should be sufficient?
>   Oh. The swissHash is used to make sure identities are coherent, perhaps?
> 8:09 PM me: The nonce is sufficient to establish access once vatB
> talks to VatC. The swissHash is used to ensure identities are coherent
> immediately on arrival of the Far3Desc in VatB.
> 8:11 PM Nonce's grant access. SwissNumbers grant persistent access.
> SwissHashes grant ability to claim sameness, for example, for a
> capabilities-as-keys comparison based service on VatB.
>  kpreid: SwissNumbers don't grant persistent access in general.
>   The 3-vat protocol uses swiss numbers, doesn't it?
>  me: This may be a bad design -- the swissHash may be granting more
> access than it should. But that's what I was thinking.
> 8:12 PM kpreid: Well, swissnumber says you have access to the object.
> And you can compute the shash from the snum. So the snum shouldn't be
> authority-to-claim-to-be.
>  me: No. Not since we switched to the nonce/table-based protocol.
>  kpreid: the shash, I meant
>  me: Yes, but only for Far3Desc. Promise3Desc doesn't carry a shash.
> 8:13 PM kpreid: Well, but that's wrong.
>  me: Why?
>  kpreid: I shouldn't be able to spoof an identity by knowing the hash...
>   by knowing the snum (which implies knowing the shash) I mean
> 8:14 PM me: Why not?
> ________________________________
> 5 minutes
> 8:20 PM me: I think this is a really important question. Even if you
> have a half baked objection, please voice it because it may lead to a
> genuine flaw. I am worried about this issue -- it's the "This may be a
> bad design" I mention above.
>  kpreid: Access to an object does not imply authority to be an object
>   This is the swisshash/swissbase distinction.
>   I mean, swissnum/swissbase.
> 8:21 PM me: Swissbase = authority to be the object.
>   SwissNum = authority to access the object.
> 8:22 PM SwissHash = designation without authority -- the object's
> identity without access to it.
> 8:23 PM The hard question that got me started on this: What is
> serialized when you send a DisconnectedRef?
>  kpreid: You yourself said "SwissHashes grant ability to claim sameness"
> 8:24 PM me: A DisconnectedRef should be somehow comparable to a far
> ref to the same object, but it shouldn't give access to that object.
> 8:25 PM This also dates from before the proxy revolution, when I think
> DisconnectedRefs and live FarRefs to the same object actually compared
> as the same. Perhaps the whole thing needs to be rethought in light of
> our more principled remote sameness story.
> 8:27 PM kpreid: I remember this discussion.
>   FarRefs and Disc.Refs are not equal.
> 8:28 PM As long as you have a connection from you (say VatA) to VatB,
> there is only one connection.
>   So there is only one far ref, and it turns into a DisconnectedRef.
>  me: Yes indeed it does need to be rethought. The newly arriving
> Far3Desc cannot unserialize into a far ref that's the same as a
> preexisting one, because if the nonce lookup fails, the arriving
> farRef will break whereas the preexisting one won't.
>  kpreid: (Only one far ref per remote object, I mean)
> 8:29 PM If you later reconnect, you get a Far ref which is not the
> same as the previous Disconnected ref
>   This scheme has all the properties we want, I believe.
> 8:30 PM Wait, what's wrong with the arriving ref broken, provided it
> is unconnected rather than disconnected?
>   After all, the nonce lookup failed = protocol error
>  me: So here's the problem. Say we fixed the comm delay problem
> causing the lost resolution bug. I don't care whether we fix it by
> WormholeOp or otherwise.
> 8:31 PM At the moment a Far3Desc arrives from VatA, VatB does not yet
> know whether the non-lookup will succeed. What does VatB create in the
> meantime for delivery to Bob?
> 8:32 PM s/non/nonce/
>  kpreid: Why does it not know?
>  me: Requires a round trip to VatC that hasn't happened yet.
>  kpreid: Oh, I see.
>   Thinking.
> 8:34 PM So the problem is that VatA tells VatB about a VatC object
> that may not even exist.
>   Yes?
>   ...that VatB doesn't know about already.
> 8:35 PM me: If vatB actually doesn't know about it, then there's no
> problem, since there's no preexisting far reference that creates the
> sameness dilemma.
> 8:36 PM If VatB doesn't already know alleged carol, then VatB can
> immediately create a fresh far ref to deliver to Bob. It'll break once
> the round trip completes, but that's ok.
> 8:38 PM kpreid: OK, that makes sense. That process doesn't require a
> swisshash at all, right?
>   We just lookup the nonce on VatC, and VatC can send an ImportDesc if
> VatC already sent it out meantime.
> 8:39 PM Oh, but if VatB knows it...
>  me: exactly. that's the problem
>  kpreid: ponders
> 8:40 PM OK, answer this question alone: Given that VatB knows Carol,
> how does VatA securely identify the existing B-ref-to-Carol in talking
> to VatB, in ignorance of B's knowledge of Carol?
> 8:41 PM me: The present answer is the swissHash. "SwissHashes grant
> ability to claim sameness"
> 8:42 PM kpreid: OK, by "claim sameness" you mean something unobvious.
>   You mean "ability to claim I have the ref you have" apparently
>  me: yes
> 8:43 PM kpreid: It sounds like "ability to claim my ref is the same as
> some other ref"
>  me: Again, this may be a bad design. I am worried about it.
>   yes.
>  kpreid: Please find better terminology
>  me: Please help me do so ;)
> 8:46 PM Perhaps the right answer is to just kill Far3Desc and the need
> for swiss hashes in captp, and just live with the lost resolution bug,
> even if we were to do something WormholeOp-like.
>  kpreid: Don't give up yet...
> 8:47 PM Got skype?
>  me: I think so. Lots of computer reconfig. But let's try.
> 8:48 PM kpreid: I don't hear you.
>  me: I can hear you
> 8:52 PM Skype just told me "connection lost"
>  kpreid: Me too
>
>

--
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: [phone]
Fax: [phone]
mailto:tal@...
http://www.it-innovation.soton.ac.uk 

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller-2]

On Thu, Sep 17, 2009 at 10:11 AM, Thomas Leonard
<tal@...> wrote:

> Hi Mark,
>
> That's good to hear. Will the new version be backwards-compatible? How
> stable is the protocol?
>
> One thing that is slightly bothering me is that it doesn't seem to use
> SSL/TLS. I found this page:
>
> http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html
>
> but it is dated 1998. I think I will have a hard time trying to convince
> people that E's custom system is secure / will be updated if problems
> are found. It would make my life easier if I could just say it uses the
> Java SSL libraries for transport layer security.

There are four protocol transitions CapTP needs to make. Given the
current minuscule adoption, I'm inclined to make all four changes
simultaneously and not worry about compatibility.

* Switching from our custom DataComm to a VatTP layered on top of TLS.
Tyler and Kevin have both made progress towards this goal.
* Switching from Java serialization, as used by E-on-Java, to Data-E,
as used by E-on-CommonLisp and Caja-CapTP.
* Dropping the SwissHash from the live reference protocol as discussed
in this thread.
* Change the exposed object APIs (esp the Miranda Methods) to
something more language neutral, as already adopted by Caja-CapTP, so
that Caja-CapTP and E-CapTP can interoperate better.


> Anyway, thanks for a wonderful language! I'm surprised it seems so
> little-known.

You are quite welcome! Part of the reason for its obscurity is that,
once the ideas achieved a certain level of maturity, most of our
efforts since then have gone into adapting these efforts to other more
mainstream languages. E has had an enormous influence on Joe-E, Caja,
and EcmaScript. EcmaScript 5 is not an ocap language, but it is a much
friendlier base for Caja-like secure ocap subsettings. Going forward
after ES5, the EcmaScript committee seeks to make EcmaScript Harmony
an even friendlier base.

Goal 5 of <http://wiki.ecmascript.org/doku.php?id=harmony:harmony> says:
> Support a statically verifiable, object-capability secure subset.

Given that JavaScript is deployed on a platform used by more than a
billion people, it seems like a high leverage distraction.

Nevertheless, E remains important as the "scouting party" for
exploring the design space unburdened by legacy. The ideas we are
bringing to Java and EcmaScript respectively, we could never have
figured out in those contexts due to these legacy distractions.



--
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

On Sep 19, 2009, at 12:04, Mark Miller wrote:

> There are four protocol transitions CapTP needs to make. Given the
> current minuscule adoption, I'm inclined to make all four changes
> simultaneously and not worry about compatibility.
>
> * Switching from our custom DataComm to a VatTP layered on top of TLS.
> Tyler and Kevin have both made progress towards this goal.

I have done nothing related to this, but I agree it is the goal.

> * Change the exposed object APIs (esp the Miranda Methods) to
> something more language neutral, as already adopted by Caja-CapTP, so
> that Caja-CapTP and E-CapTP can interoperate better.

I have done nothing related to this, and I do not know what could be  
'more language neutral' and still accomplish the goals  
straightforwardly, besides placing them as out-of-band CapTP messages.

The only thing Caja-CapTP does in particular is give the miranda  
messages[*] longer names (to reduce the chance of conflicts with  
existing JavaScript programs) and only incorporate the ones which are  
necessary to CapTP.



[*] I distinguish between the miranda protocol, those significant  
messages, and the miranda *methods*, the default implementation thereof.

--
Kevin Reid                                  <http://switchb.org/kpreid/>




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller-2]

On Sat, Sep 19, 2009 at 12:11 PM, Kevin Reid <kpreid@...> wrote:

> On Sep 19, 2009, at 12:04, Mark Miller wrote:
>
>> There are four protocol transitions CapTP needs to make. Given the
>> current minuscule adoption, I'm inclined to make all four changes
>> simultaneously and not worry about compatibility.
>>
>> * Switching from our custom DataComm to a VatTP layered on top of TLS.
>> Tyler and Kevin have both made progress towards this goal.
>
> I have done nothing related to this, but I agree it is the goal.

I thought you had in E-on-CommonLisp. My mistake. Also, for Caja-CapTP
running as JavaScript in the browser, there's really no other choice
anyway.

>> * Change the exposed object APIs (esp the Miranda Methods) to
>> something more language neutral, as already adopted by Caja-CapTP, so
>> that Caja-CapTP and E-CapTP can interoperate better.
>
> I have done nothing related to this, and I do not know what could be
> 'more language neutral' and still accomplish the goals
> straightforwardly, besides placing them as out-of-band CapTP messages.
>
> The only thing Caja-CapTP does in particular is give the miranda
> messages[*] longer names (to reduce the chance of conflicts with
> existing JavaScript programs) and only incorporate the ones which are
> necessary to CapTP.
>
>
>
> [*] I distinguish between the miranda protocol, those significant
> messages, and the miranda *methods*, the default implementation thereof.

Yes, I had in mind your more explicit Miranda message names.


--
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

On Sep 19, 2009, at 14:23, Mark Miller wrote:

> On Sat, Sep 19, 2009 at 12:11 PM, Kevin Reid <kpreid@...> wrote:
>> On Sep 19, 2009, at 12:04, Mark Miller wrote:
>>
>>> There are four protocol transitions CapTP needs to make. Given the
>>> current minuscule adoption, I'm inclined to make all four changes
>>> simultaneously and not worry about compatibility.
>>>
>>> * Switching from our custom DataComm to a VatTP layered on top of  
>>> TLS.
>>> Tyler and Kevin have both made progress towards this goal.
>>
>> I have done nothing related to this, but I agree it is the goal.
>
> I thought you had in E-on-CommonLisp.

Either "Common Lisp" or "CL", please.

> My mistake. Also, for Caja-CapTP running as JavaScript in the  
> browser, there's really no other choice anyway.

There is as yet no working code in E-on-CL for VatTP purposes. I wrote  
some parts of the hub (the part which manages setting up connections)  
but haven't integrated them successfully with CapTP yet.

>>> * Change the exposed object APIs (esp the Miranda Methods) to
>>> something more language neutral, as already adopted by Caja-CapTP,  
>>> so
>>> that Caja-CapTP and E-CapTP can interoperate better.
>>
>> I have done nothing related to this, and I do not know what could be
>> 'more language neutral' and still accomplish the goals
>> straightforwardly, besides placing them as out-of-band CapTP  
>> messages.
>>
>> The only thing Caja-CapTP does in particular is give the miranda
>> messages[*] longer names (to reduce the chance of conflicts with
>> existing JavaScript programs) and only incorporate the ones which are
>> necessary to CapTP.
>>
>>
>>
>> [*] I distinguish between the miranda protocol, those significant
>> messages, and the miranda *methods*, the default implementation  
>> thereof.
>
> Yes, I had in mind your more explicit Miranda message names.

They aren't really part of CapTP, but rather the E reference system  
(promises and all that).

The CapTP__ prefix I chose is more like a package name: the Caja-CapTP  
project.

--
Kevin Reid                                  <http://switchb.org/kpreid/>




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Bill Frantz]

erights@... (Mark Miller) on Saturday, September 19, 2009 wrote:

>On Thu, Sep 17, 2009 at 10:11 AM, Thomas Leonard
><tal@...> wrote:
>> One thing that is slightly bothering me is that it doesn't seem to use
>> SSL/TLS. I found this page:
>>
>> http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html
>>
>> but it is dated 1998. I think I will have a hard time trying to convince
>> people that E's custom system is secure / will be updated if problems
>> are found. It would make my life easier if I could just say it uses the
>> Java SSL libraries for transport layer security.
>
>...
>
>* Switching from our custom DataComm to a VatTP layered on top of TLS.

I think the attributes we want to preserve from the existing VatTP are:

   Perfect forward security - Symmetric encryption and MAC keys exist only
   for the duration of the connection. They can not be recovered after the
   endpoints have removed them from memory.

   Distributed public key authentication - The sturdy-refs held by a vat
   contain enough information to authentic the public key sent by the
   remote vat.

   The system uses only known-secure algorithms, modes, and protocols.


When I wrote the web page Thomas referenced above, there was confusion in
my mind between supporting SSL/TLS and using SSL/TLS. In our case, we want
to use SSL/TLS, and do not need to worry about any of the many CipherSuites
(for example TLS_NULL_WITH_NULL_NULL), which are not applicable to our
use. The CipherSuites (from RFC 4346 and RFC 3268) which seem most
applicable to VatTP are:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA - This CipherSuite uses the same
algorithms as the current VatTP. All are somewhat dated.

TLS_DH_DSS_WITH_AES_128_CBC_SHA and TLS_DH_DSS_WITH_AES_256_CBC_SHA - These
update 3DES to the spiffy new AES.


When two vats connect, they exchange public keys. The vats check the public
key they receive against the SHA1 hash in any sturdy refs to be used,
providing assurance that the remote vat is indeed the correct vat. This
procedure is quite different from the certificate authority procedure used
by standard SSL/TLS. It is not clear that all SSL/TLS libraries will have
the user-exits to support this form of authentication. It may be necessary
to adopt an new approach to provide distributed public key authentication.


Note on the crypto algorithms:

3DES is old and well tested. It's 64 bit block size can cause some
weaknesses when large quantities of data are transmitted, so connections
should be re-keyed periodically. (I can't remember how much data it takes
to become exposed to this weakness, but I'm fairly sure it is greater than
2**32 bits.)

DSS - The largest DSS key is 1024 bits, but there are obvious extensions to
longer keys. RSA and ECDSS are other algorithms of interest for Vat public
keys. 1024 bits in both DSS and RSA is getting a bit short for the very
paranoid. Since the hash of the public key is the VatID, changing to a
different public key while maintaining vat identity is an unsolved problem.
Life in the crypto protocol world would be nicer if we didn't have to solve
this problem, perhaps by allowing sturdy-ref replacement in running
distributed applications.

AES - Recent work has shown that AES256 is only a bit stronger than AES128,
so it probably isn't worth supporting AES128 unless it just falls out of
all the libraries we use. Since the symmetric crypto algorithm is chosen at
connection establishment time, we can easily adopt new algorithms as they
become available and refuse old ones as they become broken.

SHA1 - Attacks against SHA1 have been getting better and better at an
impressive rate. NIST is currently involved in a process to select a new
secure hash algorithm. Most observers think SHA1 should last until that
process finishes. For people who want more security than SHA1 now, the
recommendation is to use SHA256. SHA256 shares may of the design approaches
as SHA1, so attacks on SHA1 may generalize to SHA256, but the extra bits
will probably greatly expand the number of computer cycles required to
actually mount an attack.

SHA1 is used to calculate the VatID, so adopting a new secure hash
algorithm is as much of a pain as changing the public key of the vat. Also,
any new secure hash algorithm is likely to have a different length output
than SHA1's 160 bits.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was working, the
408-356-8506       | rate of systems being compromised would be going down,
www.periwinkle.com | wouldn't it?" -- Marcus Ranum
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[zooko]

On Saturday,2009-09-19, at 10:04 , Mark Miller wrote:

> There are four protocol transitions CapTP needs to make.

Several of these changes seem to make CapTP become closer to Foolscap  
[1] (which was originally inspired by CapTP).

We rely heavily on Foolscap in the Tahoe-LAFS project, so I would be  
interested to see if Foolscap and CapTP can evolve to be closer to  
one another over time.

> * Switching from our custom DataComm to a VatTP layered on top of TLS.

Foolscap has always relied on TLS for its crypto.

> * Switching from Java serialization, as used by E-on-Java, to Data-
> E, as used by E-on-CommonLisp and Caja-CapTP.

Foolscap's serialization isn't Data-E, but I guess it is slightly  
more like Data-E than it is like Java serialization.  ;-)

> * Dropping the SwissHash from the live reference protocol as  
> discussed in this thread.

Hm, I don't know about this one.  Brian Warner is the author of  
Foolscap -- Cc:'ing him to ask if this makes CapTP more Foolscappish.

> * Change the exposed object APIs (esp the Miranda Methods) to  
> something more language neutral, as already adopted by Caja-CapTP,  
> so that Caja-CapTP and E-CapTP can interoperate better.

And this one, too.

By the way, Foolscap includes a logging system with Causeway-inspired  
causality tracing.  If you are using Python (the only language that  
Foolscap supports), you should definitely check it out.

Regards,

Zooko

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David Wagner-3]

Bill Frantz  wrote:
> AES - Recent work has shown that AES256 is only a bit stronger than AES128,

This is not an accurate summary of recent work, in my opinion.

For most purposes AES256 is just fine.  There are no known weaknesses
that are relevant to the way that AES256 is normally used in practice --
including, as far as I know, the way it is used in TLS.

That's not to say that the difference between AES128 vs AES256 is
likely to matter much.  It is very unlikely that AES128 will be the
weakest link in your system.  So either one is a perfectly respectable
choice, from the point of view of security.

For further details and explanation on how to interpret the recent
work on AES256, see my comments elsewhere:
  https://financialcryptography.com/cgi-bin/mt/mt-comments.cgi?entry_id=1180
  http://www.schneier.com/blog/archives/2009/07/another_new_aes.html#c387018
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Bill Frantz]

daw@... (David Wagner) on Sunday, September 20, 2009 wrote:

>Bill Frantz  wrote:
>> AES - Recent work has shown that AES256 is only a bit stronger than AES128,
>
>This is not an accurate summary of recent work, in my opinion.
>
>For most purposes AES256 is just fine.  There are no known weaknesses
>that are relevant to the way that AES256 is normally used in practice --
>including, as far as I know, the way it is used in TLS.
>
>That's not to say that the difference between AES128 vs AES256 is
>likely to matter much.  It is very unlikely that AES128 will be the
>weakest link in your system.  So either one is a perfectly respectable
>choice, from the point of view of security.
>
>For further details and explanation on how to interpret the recent
>work on AES256, see my comments elsewhere:
>  https://financialcryptography.com/cgi-bin/mt/mt-comments.cgi?entry_id=1180
>  http://www.schneier.com/blog/archives/2009/07/another_new_aes.html#c387018

I think David and I are in basic agreement about what this recent work means for our use of the SSL/TLS CipherSuites which include AES. To be specific, and to give David a chance to disagree:

  Related key attacks should not be a problem given the use of
  Diffie-Hellman key agreement and the way SSL/TLS generates keys.

  SSL/TLS VatTP should use AES-128.

  There isn't much practical benefit of using AES-192 or AES-256 over using
  AES-128, and there are costs in additional compution.


Where we may disagree, and please remember that David is a much better
cryptographer than me, is the long-term meaning of these attacks. I tend to
see them as the start of a slowly crumbling edifice which may fall in the
long term. David doesn't seem to see it that way.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David Wagner-3]

Bill Frantz  wrote:

> I think David and I are in basic agreement about what this recent work
> means for our use of the SSL/TLS CipherSuites which include AES. To be
> specific, and to give David a chance to disagree:
>
>  Related key attacks should not be a problem given the use of
>  Diffie-Hellman key agreement and the way SSL/TLS generates keys.
>
>  SSL/TLS VatTP should use AES-128.
>
>  There isn't much practical benefit of using AES-192 or AES-256 over using
>  AES-128, and there are costs in additional compution.

This all sounds reasonable to me.

> Where we may disagree, and please remember that David is a much better
> cryptographer than me, is the long-term meaning of these attacks. I tend to
> see them as the start of a slowly crumbling edifice which may fall in the
> long term. David doesn't seem to see it that way.

I guess the reason I don't see it as the start of a slowly crumbling
edifice is that I don't find it a great surprise that AES is not
highly secure against related-key attacks.  There were related-key
attacks against AES right from the start (even if they didn't penetrate
through all the rounds).  And I always had the impression that AES's key
schedule was minimalistic; my (unscientific) impression had always been
that you're on slightly thinner ice to use AES in a context that must
resist related-key attacks (e.g., for an application that requires AES
to act like an ideal cipher, not just a PRP).

For instance, in 2002, I wrote:

  "Note that the AES has not been evaluated very carefully for security
  against related-key attacks, and what analysis has been done suggests
  that AES may have less margin of security against related-key attacks
  than against non-related-key attacks."

  http://www.cs.berkeley.edu/~daw/papers/rmac-nist02.ps 

and:

  "I'm not very confident that the security of AES against related-key
  attacks has been well-studied. [...]  Also, if you look at the AES key
  schedule, you'll see that it has a lot less "cryptographic goo" than
  the AES round function.  This makes me worry about assuming that AES
  can be safely modelled as an ideal cipher -- at the least, it seems
  to be less safe than assuming that AES is secure against standard
  chosen-plaintext/ciphertext attacks."

  http://www.ietf.org/mail-archive/web/cfrg/current/msg00143.html

And in 2004 I wrote:

  "AES's key schedule has not been as well-studied, and doesn't seem
  to have as much mixing and nonlinearity, as its main round structure.
  Put another way, I don't have quite as much confidence in the security
  of AES against related-key attacks as I do in its security against
  chosen-plaintext/ciphertext attacks."

  http://www.ietf.org/mail-archive/web/cfrg/current/msg00592.html

If they had found a non-related key attack on the cipher itself,
that would be more surprising and might warrant re-evaluation of
whether the foundation was crumbling.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Thomas Leonard]

On Sat, 2009-09-19 at 12:40 -0700, Bill Frantz wrote:

> erights@... (Mark Miller) on Saturday, September 19, 2009 wrote:
>
> >On Thu, Sep 17, 2009 at 10:11 AM, Thomas Leonard
> ><tal@...> wrote:
> >> One thing that is slightly bothering me is that it doesn't seem to use
> >> SSL/TLS. I found this page:
> >>
> >> http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html
> >>
> >> but it is dated 1998. I think I will have a hard time trying to convince
> >> people that E's custom system is secure / will be updated if problems
> >> are found. It would make my life easier if I could just say it uses the
> >> Java SSL libraries for transport layer security.
> >
> >...
> >
> >* Switching from our custom DataComm to a VatTP layered on top of TLS.

[...]
> When two vats connect, they exchange public keys. The vats check the public
> key they receive against the SHA1 hash in any sturdy refs to be used,
> providing assurance that the remote vat is indeed the correct vat. This
> procedure is quite different from the certificate authority procedure used
> by standard SSL/TLS. It is not clear that all SSL/TLS libraries will have
> the user-exits to support this form of authentication. It may be necessary
> to adopt an new approach to provide distributed public key authentication.

I'm not sure about other languages, but in Java you should be able to do
something like this, creating a new socket factory for each connection
(untested):

  SSLContext ctx = SSLContext.getInstance("TLS");
  ctx.init(myKeyManagers, new TrustManager[] {new CapTPTrustManager(vatPublicKeyHash)}, null);
  SSLSocketFactory sslSocketFactory = ctx.getSocketFactory();
  ...

  class CapTPTrustManager implements X509TrustManager {
    ...

    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
      // compare chain[0]'s public key against vatPublicKeyHash...
    }
  }


--
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: [phone]
Fax: [phone]
mailto:tal@...
http://www.it-innovation.soton.ac.uk 

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang