Re: Verisign's land grab - TCP-IP

This is a discussion on Re: Verisign's land grab - TCP-IP ; WS> To counter if Verisign changes the IP addresses daily or weekly, WS> you could check the returned IP with the return of a query for WS> actuall wildcard (i.e. *.dns a) and see if they match. .... thereby allowing ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Verisign's land grab

  1. Re: Verisign's land grab

    WS> To counter if Verisign changes the IP addresses daily or weekly,
    WS> you could check the returned IP with the return of a query for
    WS> actuall wildcard (i.e. *.dns a) and see if they match.

    .... thereby allowing Verisign to _fully automate_ any
    denial-of-service attack that it may make using the mechanism for
    doing so that you are handing to it, instead of waiting for human
    beings to catch up and modify their configuration files.



    If one is taking the view that Verisign has gone rogue, handing it
    further powers to do more damage (as these mechanisms all do) is not
    the way to proceed.

  2. Re: Verisign's land grab

    > ... thereby allowing Verisign to _fully automate_ any
    > denial-of-service attack that it may make using the mechanism for
    > doing so that you are handing to it, instead of waiting for human
    > beings to catch up and modify their configuration files.


    If that is what they wanted to do, they could do that anyway without this
    wildcard stuff, so your point is mute.

    Second, you have problems with your other assumptions:

    1) You say - "Verisign can change the IP address that it is publishing at
    any time. People employing these measures have manoeuvred themselves into
    playing a never-ending game of catch-up with Verisign. Verisign need only
    change the address, and they have to modify their proxy DNS server softwares
    to match. When Verisign says "hop!", they have to jump." Having the patch
    from BIND or matching wildcard IPs against returned IPs will stop this.
    They can change the IP all they want. So no problem here - next.

    2) You say - "Verisign can turn this measure against those who employ it.
    This measure is an effective denial-of-service weapon against any IP
    address. If, for example, one day Verisign changes the IP address that it
    publishes from 64.94.110.11 to 66.218.71.198, anyone employing this measure
    will find that they have just cut themselves off from Yahoo's HTTP server."
    First, your assuming things again. Your assuming people are matching
    against a fixed IP, the BIND P1 patch does not do this, they use the
    "delegation-only" attribute. Second, your assuming Verisign will purposely
    point an IP to yahoo to deny service - that is a joke. If they had such
    intentions, they could do far worse things with the power they have. Third,
    your assuming dns admins would just blindly change the IP they where
    blocking without checking to see what that IP pointed to. I give people far
    more credit then that. Besides, even if they did do it, your only talking
    about 1 site. This would not effect other sites and would be caught soon
    enough. As this is not how the patch works anyway, both of these points are
    mute and just a lot of talk. Use the patch if you need to.

    --
    William Stacey, DNS MVP



  3. Re: Verisign's land grab

    Jonathan de Boyne Pollard wrote in message news:<3F68837C.5E2EDCB6@Tesco.NET>...
    > WS> To counter if Verisign changes the IP addresses daily or weekly,
    > WS> you could check the returned IP with the return of a query for
    > WS> actuall wildcard (i.e. *.dns a) and see if they match.
    >
    > ... thereby allowing Verisign to _fully automate_ any
    > denial-of-service attack that it may make using the mechanism for
    > doing so that you are handing to it, instead of waiting for human
    > beings to catch up and modify their configuration files.
    >
    >
    >
    > If one is taking the view that Verisign has gone rogue, handing it
    > further powers to do more damage (as these mechanisms all do) is not
    > the way to proceed.


    Given that Verisign is rogue, there is one specific thing that people
    can do, and I did yesterday. On my Win2k box yesterday I revoked my
    trust on all Verisign and Thawte SSL certificates. Who wants to trust
    certifications from a rogue agency?
    (tools/options/content/certificates on MSIE)

    That created a problem when it comes to updating my win2k system. I
    went to install SP4 from the updates page. It turns out that although
    MSFT is itself a root certificate authority, and issues its own
    certificate, at least according to the certificates table on my box,
    it required me to trust one or more Verisign certificates to complete
    the SP4 update. It doesn't give you the option of one time accepting
    an untrusted certificate - remove Verisign and Thawte certs and the
    update will not complete. I had to go to the MSFT update site and
    restore them to my 'trusted root certification authorities' table to
    complete the SP4 update.

    If Microsoft shares the view of everyone else that Verisign is no
    longer reliable, it should sever that tie with Verisign and let us
    update our Microsoft systems on the basis of our trust of the
    Microsoft Root Authority certificate, not Verisign's. Requiring us to
    trust Verisign's certs instead as being somehow safer or more reliable
    than MSFT's own certs is alot like running MSFT's web site on an
    Apache server.

    If they aren't willing to do that, I'd at least like to know which of
    the multitude of Verisign/Thawte certs I can safely revoke without
    losing my ability to run Win2k updates.

+ Reply to Thread