Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
Hadmut Danisch wrote: On Thu, Sep 16, 2004 at 12:41:41AM +0100, Ian Grigg wrote: It occurs to me that a number of these ideas could be written up over time ... a wiki, anyone? I think it is high past time to start documenting crypto patterns. Wikis are not that good for discussions, and I do believe that this requires some discussion. I'd propose a separate mailing list for that. It possibly requires both. A mailing list by itself tends to generate great thoughts that don't get finished by being turned into summaries. Also, those in charge tend to slow the process, just through being too busy. (I'm not talking about just this list, I've noticed the effect on RFC lists where the editor wakes up after a week and skips all the debate and starts again.) A wiki working with a mailing list might address both those issues. (It's just a guess, I've never really worked with a Wiki, just read some entries over at wikipedia.) iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
Steven M. Bellovin wrote: For RFCs, there are two paths. If the topic is general enough (and, of course, the advice is good enough), Russ Housley or I would consider sponsoring the document as a BCP. If it's narrow or we're not interested for some reason (other than quality, of course), it could be an individual submission. I encourage both paths. It sounds like an RFC / BCP would be a good target. I suspect given the controversy over a lot of these ideas an intermediate phase would be needed where the controversy could be aired in depth, before being summarised into a BCP. From that pov, a wiki + discussion list leading to a BCP would seem like a good idea. Alternatively, let all these things be thrown into the mixing pot and see what happens? iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
On Thu, Sep 16, 2004 at 12:41:41AM +0100, Ian Grigg wrote: > > It occurs to me that a number of these ideas could > be written up over time ... a wiki, anyone? I think > it is high past time to start documenting crypto > patterns. Wikis are not that good for discussions, and I do believe that this requires some discussion. I'd propose a separate mailing list for that. regards Hadmut - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
In message <[EMAIL PROTECTED]>, Ian Grigg writes: >Peter Gutmann wrote: >> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes: Maybe it's worth doing some sort of generic RFC for this security model to avoid scattering the same thing over a pile of IETF WGs, >>> >>>Sounds good. Who wants to write it...? >> >> Since there seems to be at least some interest in this, I'll make a start on >> it. If anyone else wants to add their $0.03 to it [0], let me know. > >It occurs to me that a number of these ideas could >be written up over time ... a wiki, anyone? I think >it is high past time to start documenting crypto >patterns. > For RFCs, there are two paths. If the topic is general enough (and, of course, the advice is good enough), Russ Housley or I would consider sponsoring the document as a BCP. If it's narrow or we're not interested for some reason (other than quality, of course), it could be an individual submission. I encourage both paths. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
Peter Gutmann wrote: "Steven M. Bellovin" <[EMAIL PROTECTED]> writes: Maybe it's worth doing some sort of generic RFC for this security model to avoid scattering the same thing over a pile of IETF WGs, Sounds good. Who wants to write it...? Since there seems to be at least some interest in this, I'll make a start on it. If anyone else wants to add their $0.03 to it [0], let me know. It occurs to me that a number of these ideas could be written up over time ... a wiki, anyone? I think it is high past time to start documenting crypto patterns. FWIW, on opportunistic cryptography (a la "SSH model") I wrote up a opportunistic draft paper here: http://iang.org/papers/spock.html (FTR, I've received substantial comments from TwanVDS and DigbytT.) iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
At 11:43 AM 9/11/2004, Peter Gutmann wrote: So in other words it's the same baby-duck security model that's been quite successfully used by SSH for about a decade, is also used in some SSL implementations that don't just blindly trust anything with a certificate (particularly popular with STARTTLS-enabled MTAs/MUAs where you don't want to bother with CA-issued certs), and is even used in various X.509 applications (via "certificate fingerprints"), although the X.509 folks don't like to admit that because it implies that a known-good cert fingerprint is more reliable than a CA :-). i've referred to it as identity agnostic ... as opposed to anonymous ... even with public key use. the scenario is that the original identity x.509 certificates created huge privacy issues. the the current credit card scenario, it carries a name ... in theory so that the merchant or point-of-sale can cross-check the name against additional forms of identification as a means of authentication (where the merchant is sort of a stand-in agent for the consumer's financial institution even tho the merchant and the consumer's financial institution may have significantly different and possibly opposing interests). in effect it is transforming something that should be purely an authentication operation (is the entity entitled to perform a transaction for the account) into a much more difficult (and privacy invasive) identification operation. the x9.59 scenario is that the transaction is simply authenticated with a digital signature that the merchant passes thru to the consumer's financial institution. the consumer financial institution verifies the digital signature with public key on file for that account. the verification of the digital signature implies some form of "something you have" authentication (implies that you uniquely have the corresponding private key). it becomes a straight-forward authentication operation and identity agnostic ... w/o the horrible identity and privacy invasive that can accompany a x.509 identity certificate. while it may be possible for various agents to associated the authentication operation the operations themselves, at least don't carry the possibly mandatory identity information & privacy invasive information that can be found in identity x.509 certificates. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes: >>Maybe it's worth doing some sort of generic RFC for this security model to >>avoid scattering the same thing over a pile of IETF WGs, > >Sounds good. Who wants to write it...? Since there seems to be at least some interest in this, I'll make a start on it. If anyone else wants to add their $0.03 to it [0], let me know. Peter. [0] Or $0.04 if you're paying in Euros. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
In message <[EMAIL PROTECTED]>, Peter Gutmann writes: >Eugen Leitl <[EMAIL PROTECTED]> writes: > > >Maybe it's worth doing some sort of generic RFC for this security model to >avoid scattering the same thing over a pile of IETF WGs, things like the >general operational principles (store a hash of the server key, compare it on >subsequent connects), how to present the value to the user (a format that's >consistent across protocols would be nice), maybe a simple /etc/passwd-type >file format listing servers and their matching hashes, etc etc etc. > Sounds good. Who wants to write it...? --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
On Fri, 10 Sep 2004, Eugen Leitl wrote: >From: Joe Touch <[EMAIL PROTECTED]> >>To clarify, this is not really "anonymous" in the usual sense. > >It does not authenticate the endpoint's identification, other than "same >place I had been talking to." > That's pseudonymity, not anonymity. >There's no difference between having no "name" and having a name you >cannot trust. I.e., I could travel under the name "anonymous" or "", or >under the name "A. Smith". If you don't know whether I am actually A. >Smith, the latter is identical to the former. This is just plain not true. When operating under a pseudonym, you are making linkable acts - linkable to each other even if not necessarily linkable to your own official identity. Anonymous actions or communications are those which cannot be linked to any other no matter how hard someone tries. We can expect the public to fail to grasp the distinction, but on this list "anonymous" is a very strong claim. Anonymity is *HARD* to do, not something that results from failing to check a credential. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
