Subject: RE: RE: Palladium (TCP/MS)

From: "Sean Jones" <[email-masked]>
Date: Tue, 22 Oct 2002 16:42:03 +0100

Forgive my ignorance, but what the heck do you mean?

> -----Original Message-----
> From: Chris Evans [mailto:[email-masked]]
> Sent: 22 October 2002 02:38
> To: [email-masked]
> Subject: Re: RE: Palladium (TCP/MS)

> access-list 100 deny ip 207.46.230.218 0.0.0.0 12.246.56.92 0.0.0.0 gt 1
> access-list 100 permit ip any any

> oh well.  :)
 
>> 10/21/02 9:37:42 AM, "Haren Visavadia" <[email-masked]> wrote:
 
> >If Microsoft can not produce secure products, what chance is there of
> >them producing a secure protocol?

> >IETF is more experienced than Microsoft at producing protocols.

Regards

Sean Jones
AKA No One in Particular

---

From: [email-masked]
Date: Tue, 22 Oct 2002 13:38:35 -0400

> Forgive my ignorance, but what the heck do you mean?

% dig -x 207.46.230.218

;;  ANSWER SECTION:
218.230.46.207.in-addr.arpa. 2665 IN    PTR     microsoft.com.
218.230.46.207.in-addr.arpa. 2665 IN    PTR     microsoft.net.
218.230.46.207.in-addr.arpa. 2665 IN    PTR     www.domestic.microsoft.com.
218.230.46.207.in-addr.arpa. 2665 IN    PTR     www.us.microsoft.com.

Of course, it isn't that simple - those 4 PTR entries each point back at a
multihomed host. I was about ready to throw a yellow flag and a 5-yard
procedural penalty until I double-checked RFC2181, section 10.2 - that's legal.

Gonna need a lot longer ACL on that Cisco to actually make it work (don't
forget all their msft.net servers.

Bringing it back to IETF territory now:  Is there a need for an RFC for
"best practices" in securing the download of software updates (DNSSEC,
PGP signatures, etc)?  The two scariest things about online updates (at least
while wearing my security hat) are the MITM attack (as demonstrated against
Apple) and the hacked download attack (as has hit windowsupdate, openssh,
sendmail, and others).  If it's WG fodder, I'd specifically declare the
question of whether the patch *works* as off-topic - the task is merely
verifying that the bits are the correct bits, and from the correct vendor.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech