From touch at ISI.EDU Wed Dec 1 08:21:23 2004 From: touch at ISI.EDU (Joe Touch) Date: Wed Dec 1 08:22:20 2004 Subject: [anonsec] request for posts on separate WG vs. merged In-Reply-To: <4636.1101847634@marajade.sandelman.ottawa.on.ca> References: <419E366E.5020800@isi.edu> <20041119181617.GZ473487@binky.central.sun.com> <419E40D4.4090203@isi.edu> <419E4289.9000006@isi.edu> <4636.1101847634@marajade.sandelman.ottawa.on.ca> Message-ID: <41ADEF83.8030706@isi.edu> mcr@sandelman.ottawa.on.ca wrote: > My opinion is that it isn't enough to get better-than-nothing > security. One has to also let the application know that it got that. Does an application know whether you've chosen a certificate signed by a crummy CA? Or when you use a shared key that's been compromised or is easy to guess? I agree that passing 'strength' information back up to the layers is useful, as is being able to let the upper layers pass info back down that their layer has done extra work that increases the strength of the association, as well as 'binding' the two together. I don't see how any of that is unique to BTNS, though. Insofar as some of that work has already been done, as I've said before, BTNS should comply with and not defeat these capabilities. However, I don't see that BTNS is a good place to further develop those ideas, unless their developed in ways that are needed to support BTNS use. On that last point, I haven't seen anyone make a case that BTNS needs such unique extensions. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20041201/3dd7508f/signature.bin From Julien.Laganier at Sun.COM Thu Dec 2 01:33:16 2004 From: Julien.Laganier at Sun.COM (Julien Laganier) Date: Thu Dec 2 01:33:54 2004 Subject: [anonsec] request for posts on separate WG vs. merged In-Reply-To: References: Message-ID: <41AEE15C.2050402@Sun.COM> Black_David@emc.com wrote: > One proviso (as I've said earlier) is that I think the basic > channel binding work should be done in BTNS: > - Format and computation of the bits/bytes for binding > - Principles for binding in higher-layer protocols > - Warnings about things that SHOULD NOT or MUST NOT > be done in higher-layer channel binding > OTOH, channel binding for specific upper layer protocols belongs > in the WGs for those protocols (e.g., some combination of KITTEN > and NFSv4 will need to work this out for NFSv4). FWIW, what you propose looks to me somewhat similar to what was done within the Host Identity Protocol (HIP) WG, where the base protocol draft (draft-itef-hip-base) specifies both: - Format and computation of a fixed sized identifier (Host Identity Tag) for use in ULPs, derived from the public key (Host Identity): HIT=SHA1_128(HI) - These ULPs identifiers (i.e. HITs) SHOULD be used in ULPs pseudo-headers and checksum computation. Thanks, --julien From mcr at sandelman.ottawa.on.ca Sun Dec 26 08:25:11 2004 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun Dec 26 08:27:02 2004 Subject: [anonsec] Re: request for posts on separate WG vs. merged In-Reply-To: <41ADEF83.8030706@isi.edu> (Joe Touch's message of "Wed, 01 Dec 2004 08:21:23 -0800") References: <419E366E.5020800@isi.edu> <20041119181617.GZ473487@binky.central.sun.com> <419E40D4.4090203@isi.edu> <419E4289.9000006@isi.edu> <4636.1101847634@marajade.sandelman.ottawa.on.ca> <41ADEF83.8030706@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> Does an application know whether you've chosen a certificate signed Joe> by a crummy CA? Or when you use a shared key that's been compromised Joe> or is easy to guess? yes. Right now applications that want security and can not get it from a common security layer, use TLS. Aside from HTTPS, if you look at actual usage of TLS, in for instance, SMTP (where we have actual anonymous encryption working very frequently according to my logs), one thing that applications commonly due is make relay/do-not-relay decisions when they see that the peer is "trusted" Joe> I don't see how any of that is unique to BTNS, though. Insofar as Joe> some of that work has already been done, as I've said before, BTNS Joe> should comply with and not defeat these capabilities. However, I Joe> don't see that BTNS is a good place to further develop those ideas, Joe> unless their developed in ways that are needed to support BTNS Joe> use. On that last point, I haven't seen anyone make a case that BTNS Joe> needs such unique extensions. It is my belief that without such an extension, that BTNS has no value other than for BGP. -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20041226/5dbd7c53/attachment.bin From mcr at sandelman.ottawa.on.ca Sun Dec 26 09:42:29 2004 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun Dec 26 09:52:59 2004 Subject: [anonsec] Re: Bare RSA keys instead of self-signed certs References: <16805.52559.784298.819272@fireball.kivinen.iki.fi> <4640.1101847645@marajade.sandelman.ottawa.on.ca> <20041201073626.GW556007@binky.central.sun.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Nicolas" == Nicolas Williams writes: >> As the maintainer of one, I can tell you that pre-exchanged bare RSA >> keys is a major godsend. In teaching students how to do this, they >> rapidly realize how easy it is to set up systems this way. Nicolas> Does your implementation do this with IKEv1? Raw RSA keys in CERT payloads in IKEv1? Not in publically available code. The only reason it didn't get off my desk was time pressure. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUBQc74CIqHRg3pndX9AQEI5gQAmmPH20xa8Fzl6K794pO/awzchYOBgakN qfiIgbA3wiesZTavmJFP1pcjGsV2hEukhHpaJUmR6oTTrUWHJFN4oyMh7p9pHw0k l/j9WXBHaw9JFBEut3Zwh+cCZ4zrIvdEnzG8UcEPny1VAuKav/RT26JCD0DpagH+ o7YOCMG86Ks= =rDPd -----END PGP SIGNATURE----- From paul.hoffman at vpnc.org Tue Dec 28 13:55:27 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Tue Dec 28 21:49:04 2004 Subject: [anonsec] Re: request for posts on separate WG vs. merged In-Reply-To: References: <419E366E.5020800@isi.edu> <20041119181617.GZ473487@binky.central.sun.com> <419E40D4.4090203@isi.edu> <419E4289.9000006@isi.edu> <4636.1101847634@marajade.sandelman.ottawa.on.ca> <41ADEF83.8030706@isi.edu> Message-ID: At 11:25 AM -0500 12/26/04, Michael Richardson wrote: > Joe> I don't see how any of that is unique to BTNS, though. Insofar as > Joe> some of that work has already been done, as I've said before, BTNS > Joe> should comply with and not defeat these capabilities. However, I > Joe> don't see that BTNS is a good place to further develop those ideas, > Joe> unless their developed in ways that are needed to support BTNS > Joe> use. On that last point, I haven't seen anyone make a case that BTNS > Joe> needs such unique extensions. > > It is my belief that without such an extension, that BTNS has no value >other than for BGP. There is an important difference between "no value to me" and "no value to anyone else". If you are claiming the latter, that's an awfully big jump. Off the top of my head, I can think of another: DNS. In the absence of DNSSEC, I still want to know that the answers I am getting from my ISP are what they sent, and I don't want anyone knowing that I asked. --Paul Hoffman, Director --VPN Consortium From mcr at sandelman.ottawa.on.ca Fri Dec 31 15:50:39 2004 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri Dec 31 15:51:36 2004 Subject: [anonsec] Re: request for posts on separate WG vs. merged References: <419E366E.5020800@isi.edu> <20041119181617.GZ473487@binky.central.sun.com> <419E40D4.4090203@isi.edu> <419E4289.9000006@isi.edu> <4636.1101847634@marajade.sandelman.ottawa.on.ca> <41ADEF83.8030706@isi.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- mcr> It is my belief that without such an extension (for channel mcr> bindings), that BTNS has no value other than for BGP. >>>>> "Paul" == VPNC writes: Paul> There is an important difference between "no value to me" and "no Paul> value to anyone else". If you are claiming the latter, that's an Paul> awfully big jump. I think that it will have sufficiently low value that it will not be available in common desktop operating systems. Paul> Off the top of my head, I can think of another: DNS. In the absence Paul> of DNSSEC, I still want to know that the answers I am getting from Paul> my ISP are what they sent, and I don't want anyone knowing that I Paul> asked. DNSSEC would never make the questions/answers private, which I think is valuable. I am not really sure that you could infer anything else about the answers. It certainly would keep mis-BEHAVE-ing systems off of your packets, though, but only if you do leap-of-faith-save-to-disk. (Because the nefarious boxes could just participate in the exchange...) My question: would you wish to *AVOID* making certain queries if you knew that DNS wasn't over BTNS? If so, then you need to make the ability to notify the applications about the BTNS status. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUBQdXl0oqHRg3pndX9AQE9DAQAu26nNjwGKVuNhStvK02P5Z2/PtuLamYu KttBdoIcVdDwM1RctP6aOmMa0Zf0FIkO1FloRisxk3ZoXRsPHhXLG367xRnnTT/v tYY7UMfxJMKGLqDfFo87jqNTRv8BIJuIb4mFh95pB83ot5/9L7y/wNzdpp0i9jZP ieKhZ5YhnUs= =sFDx -----END PGP SIGNATURE-----