[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] Security Considerations (pass 2)
-----BEGIN PGP SIGNED MESSAGE-----
{I think that this is a dead horse, but I didn't get all the emails
in this thread sorted right...}
>>>>> "JJ" == Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr> writes:
JJ> Question: what do you mean by: "In cases where the end-to-end integrity
JJ> of the IPSECKEY RR is suspect" ?
JJ> Do you mean:
JJ> a) Implementation detected (how ?) or expects with a
JJ> reasonnable probability that an active attack is
JJ> under way. Then I
JJ> agree the end client MUST restrict the use of the
JJ> record.
JJ> or:
JJ> b) When there is no end-to-end integrity, (or when a
JJ> gateway cannot
JJ> know surely about that), the end client MUST restrict
JJ> the use of
JJ> the record.
I mean (b). I don't know when one can determine (a) without DNSSEC, and if
you have DNSSEC, well...
So, if my gateway knows that it is loading good data for some zone,
because, for instance, it *is* the DNS server for that zone, then it might
be more lax.
JJ> I'm really sorry to mess around with these problems of MAY/SHOULD/MUST,
JJ> but I fear current statements let opened too many questions or may lead
JJ> to restrict too much.
Your text is reasonable. Am I to figure out how to integrate your text,
or would you like to provide a straight diff where you feel it fits in?
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPt1A8IqHRg3pndX9AQF2LgQAzdh2a4pzgt2blhUOjOR2RXHXyrdacIux
tD+DUntD+kTwHznT4V4eCrz0bITE8y7/AWnuqjlXssnf8HtIA0aXs9bBA7Syjdpj
RcX2yIUGY7GybbmSXAr+J7aQdr1SXz9CyF+z2KTKjti/MSGfwVypTg6Vmyl/Ji6r
tU3NQigsMwA=
=GEjk
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.