Re: Disappointing ARIN - A great advertisement for the USA ?

[bmanning]

On Mon, Sep 12, 2011 at 10:15:10PM -0500, Ryan Gelobter wrote:
> I e-mailed Marco (md) the creator of 'whois' back in July when this started
> and he stated he was going to try to work around the rWHOIS issue in the
> next release. Sadly there hasn't been a new release yet but I am hopeful.

I don't remember Marco creating "whois"...  
there was the Network Service Center Phonebook - and Dan Long/BBN
mashed it into something you could query ... like finger!  (circa 1990)

/bill

Re: Disappointing ARIN - A great advertisement for the USA ?

[Always Learning]

On Mon, 2011-09-12 at 20:07 -0700, Michael Sinatra wrote:

> Unfortunately, the original poster, against advice given to him,
> posted an insulting, jingoistic, inane, and even more derogatory
> version of his NANOG post, apparently in an effort to spur discussion.
> What was once a legitimate issue (and I agree one that needs to be
> addressed) now looks more like troll-bait.  Unsurprisingly, nobody has
> responded.

I was attempting to write in 'Obama-style'.

I do make a perfectly valid point, perhaps oblivious to many North
Americans who generally are insular, that the world does expect the
Americans to do Internet things properly.

Many North Americans appear not to understand the general world-wide
attitude towards the USA. When something goes wrong at ARIN which
affects American IPs, the world seems to blame the Americans. Although
there is a clear distinction, certainly in my mind, between one rather
small organisation and a state of circa 280 million, never-the-less the
world generally blames the Americans. The only noticeable exception when
the USA is not blamed for the faults and omissions of an American
organisation is Micro$oft.

Why does it take the concerns of an European to waken-up the Americans
to the outstanding ARIN problem?  Perhaps some of you can continue the
campaign for the restoration of a basic North American WHOIS ?  The rest
of the world has a fully functioning WHOIS but not the USA (or Canada).

My posting was never meant to be insulting or jingoistic or inane and
certainly not derogatory. I was attempting to make those that can
influence ARIN have some pride in presenting their country's
achievements and services in the best possible way.

Like it or not, the Americans run the Internet: Google (the world's
biggest spying operation), Micro$oft, Facebook, Yahoo, Twitter, Ebay and
their Paypal, Cisco etc. etc. and of course ARIN.

>  What was once a legitimate issue 

Remains "a legitimate issue" until ARIN resolves it, if ever.


-- 
With best regards,

Paul.
England,
EU.

Re: Disappointing ARIN - A great advertisement for the USA ?

[Ryan Gelobter]

I e-mailed Marco (md) the creator of 'whois' back in July when this started
and he stated he was going to try to work around the rWHOIS issue in the
next release. Sadly there hasn't been a new release yet but I am hopeful.

Re: Disappointing ARIN - A great advertisement for the USA ?

[Michael Sinatra]

On 09/12/11 17:49, Jimmy Hess wrote:

I think arin-discuss would be a better place for this than arin-ppml.

You're suggesting using ARIN's private members-only mailing list over
a public one?
That doesn't make sense,  because this is a public issue, not a members issue.
PPML isn't right either, that's a numbering policy discussion list,
and this is an operational issue,
not a policy matter.


I meant arin-tech-discuss, and Mark properly corrected me on that. 
arin-tech-discuss is a public mailing list, and much more appropriate 
for this sort of discussion than PPML.



I think  this is a very simple matter, however...  in some way ARIN
changed their WHOIS service that introduced major
serious breakage.

They need to fix that and revert their WHOIS service to its original
query syntax and responses, which worked just fine.


Unfortunately, the original poster, against advice given to him, posted 
an insulting, jingoistic, inane, and even more derogatory version of his 
NANOG post, apparently in an effort to spur discussion.  What was once a 
legitimate issue (and I agree one that needs to be addressed) now looks 
more like troll-bait.  Unsurprisingly, nobody has responded.


michael

Re: vyatta for bgp

[Tony Varriale]

On 9/12/2011 3:12 PM, Dobbins, Roland wrote:

On Sep 13, 2011, at 2:45 AM, Owen DeLong wrote:


In your typical enterprise environment, a 1G DoS will zorch the link long 
before it zorches the router at the enterprise side.

This contradicts my experience - I've repeatedly witnessed only a few mb/sec of 
64-byte packets making software-based routers fall over, including just last 
month.

---
Roland Dobbins  //

The basis of optimism is sheer terror.

  -- Oscar Wilde




+1

tv

Re: vyatta for bgp

[Jimmy Hess]

On Mon, Sep 12, 2011 at 2:35 PM, Nick Hilliard  wrote:
> I presume by "a fair amount", I presume you mean "barely any"?
> At large packet sizes, an "enterprise level" router will just about handle
> a 1G DoS attack.  Thing is, bandwidth DoS / DDoS is sufficiently easy to
[snip]
How much "zorching" a software router can take  depends on a lot of factors.
If the hardware necessary to size appropriately for the link is
economical and sufficient,
zorching is not the largest concern.   1G link speed and 100M  link
speed offer very different
worst-case scenarios;  the link can be zorched long before the router is.

A software router running in a 32bit OS on an old Pentium 4   can take
a lot less zorching than a router running
on a server with  6-core  4Ghz  CPUs,  when interrupt coalescing is
present and utilized efficiently.

Hardware basic routers have a lower forwarding latency,  which makes
them more suitable for
ISP/carrier  networks,  the "hop delay" penalty is lower,  and  jitter
might be a concern on a router running
a non real-time OS such as a vanilla Linux kernel or other OS not
specially designed for the router task,
but there's otherwise nothing wrong with appropriately specc'ed
software forwarders.


One thing..  the OP was asking about anyone using Vyatta for BGP.
Using Vyatta for BGP doesn't necessarily mean the Vyatta unit is
actually a device
forwarding the packets...  someone could be using it as a route server, or for
otherwise populating forwarding  tables of other devices with
third-party next hops :-)


--
-JH

RE: Saudi Telecom sending route with invalid attributes 212.118.142.0/24

[Schiller, Heather A]

Could be this..?

http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/configuration-statement/independent-domain-edit-routing-options.html
  

"unrecognized transitive attributes" depend on whatever code version you are 
running... What's more important is how the unrecoginized attribute is handled. 
 Ideally you accept and pass the route and log it.  The problem is with devices 
that aren't so graceful.. dropping sessions and wreaking havoc:

http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml

--Heather 

-Original Message-
From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] 
Sent: Saturday, September 10, 2011 6:49 PM
To: Richard Barnes
Cc: Jonas Frey (Probe Networks); nanog@nanog.org
Subject: Re: Saudi Telecom sending route with invalid attributes 
212.118.142.0/24

with in the span of couple of hours this prefix was originated from 3 ASN i.e. 
AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).

As per the STC it was orginated by one of their customer having Juniper router. 
but I still don't understand why/how they are adv this prefix with unrecog 
transitive attributes.

Can any one suggest.

Regards,

Aftab A. Siddiqui


On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes wrote:

> Looks like the RIS collectors are seeing it originating mostly from 
> STC and KACST ASNs:
> 
>
> Some of the "show ip bgp" reports on that screen are also showing
> AS8866 "BTC-AS Bulgarian Telecommunication Company".  Not sure what's 
> up with that.
>
> --Richard
>
>
>
> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow 
>  wrote:
> > On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren 
> wrote:
> >> Is this announcement still showing up this way (no easy way to 
> >> check myself).
> >
> > ripe ris?
> >
> >> -Kyle
> >>
> >> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes 
> >> 
> wrote:
> >>
> >>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) < 
> >>> j...@probe-networks.de> wrote:
> >>>
> >>> > Hello,
> >>> >
> >>> > anyone else getting a route for 212.118.142.0/24 with invalid 
> >>> > attributes? Seems this is (again) causing problems with some 
> >>> > (older) routers/software.
> >>> >
> >>> >   Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 
> >>> > 1 6-Resolve tree 2
> >>> >AS path: 6453 39386 25019 I Unrecognized Attributes:
> 39
> >>> > bytes
> >>> >AS path:  Attr flags e0 code 80: 00 00 fd 88 40 
> >>> > 01 01
> 02
> >>> > 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 
> >>> > 40 05
> 04
> >>> > 00 00 00 64
> >>> >Accepted Multipath
> >>> >
> >>> >
> >>> > -Jonas
> >>> >
> >>> >
> >>> Yup! We're seeing the same thing too, and we're filtering it out.
> >>> Originating AS is 25019
> >>>
> >>> -Clay
> >>>
> >>
> >
> >
>
>

Re: vyatta for bgp

[Robert Bays]

> On Sep 13, 2011, at 2:45 AM, Roland Dobbins wrote:
> This contradicts my experience - I've repeatedly witnessed only a few mb/sec 
> of 64-byte packets making software-based  routers fall over, including just 
> last month.


It's easy to get 6Mpps using Vyatta or most other software based routers on 
modern server grade hardware.  If both your link and hardware capacity don't 
exceed the maximum load the bad guys can throw at you, then you are doomed to 
failure regardless without upstream cooperation.  In the case of an enterprise, 
neither of those two things are always guaranteed.  Software based routers work 
great for many use cases, it just depends on what you are looking for.  And 
sometimes they are the only option, for example as services migrate into the 
cloud.

Software based routers are only going to get better.  Roland, if you are in the 
Bay Area I invite you to drop by Vyatta HQ in Belmont and I will show you a 
demo of our next generation software which is doing an 5x increase in 
throughput over our last generation on the same off the shelf Intel X86 
processors.  We expect that number to only increase over the short term.  Lot's 
of CPU horsepower solves a multitude of woes.

The one thing I do agree with you on is…
> One can and should test the specific performance envelope of any prospective 
> infrastructure purchase, of course.

cheers,
robert.

Re: EV SSL Certs

[Coy Hile]

On Mon, Sep 12, 2011 at 11:39 PM, Jimmy Hess  wrote:
> On Mon, Sep 12, 2011 at 7:08 AM, Coy Hile  wrote:
>> As an academic aside, exactly what would one set on his (internal)
>> root CA so that internally-trusted certs signed by that CA would show
>> up as EV certs?
>
> This is not possible without changing browser source code and recompiling
> (or debugging/editing the browser binary).
> The IDs of certificates that are allowed to sign EVSSL CAs are
> hard-wired in the browser.
> In some browsers, this also means it's impossible for an end user to
> "untrust"  or  remove
> an EVSSL CA.
>
> It also means you cannot as a site adminsitrator, make an
> administrative decision to internally
> add an internal EVSSL CA,  without customizing every browser.
>
> If you ask me...  it's shoddy software design.   EVSSL CAs should be
> configurable,
> but none of the major browsers provide the knobs to  manually add or
> remove EVSSL
> access to/from a trusted CA.
>

Thanks. I saw something about it on TechNet.  (I'm using Windows for
my internal CA).  I'm guessing those instructions may work for IE
only.  If I find anything interesting, I'll let you know.

Re: Disappointing ARIN - A great advertisement for the USA ?

[Jimmy Hess]

>>I think arin-discuss would be a better place for this than arin-ppml.
You're suggesting using ARIN's private members-only mailing list over
a public one?
That doesn't make sense,  because this is a public issue, not a members issue.
PPML isn't right either, that's a numbering policy discussion list,
and this is an operational issue,
not a policy matter.

I think  this is a very simple matter, however...  in some way ARIN
changed their WHOIS service that introduced major
serious breakage.

They need to fix that and revert their WHOIS service to its original
query syntax and responses, which worked just fine.

--
-JH

Re: EV SSL Certs

[Jimmy Hess]

On Mon, Sep 12, 2011 at 7:08 AM, Coy Hile  wrote:
> As an academic aside, exactly what would one set on his (internal)
> root CA so that internally-trusted certs signed by that CA would show
> up as EV certs?

This is not possible without changing browser source code and recompiling
(or debugging/editing the browser binary).
The IDs of certificates that are allowed to sign EVSSL CAs are
hard-wired in the browser.
In some browsers, this also means it's impossible for an end user to
"untrust"  or  remove
an EVSSL CA.

It also means you cannot as a site adminsitrator, make an
administrative decision to internally
add an internal EVSSL CA,  without customizing every browser.

If you ask me...  it's shoddy software design.   EVSSL CAs should be
configurable,
but none of the major browsers provide the knobs to  manually add or
remove EVSSL
access to/from a trusted CA.

--
-JH

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Jimmy Hess]

On Mon, Sep 12, 2011 at 6:23 AM, Gregory Edigarov
 wrote:
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...
More lines of defense on top of the CA model.
Consider instead of abandoning the CA model altogether, you utilize
DNSSEC binding of the certificate
that must also be signed by a CA.

If _either_  the DNSSEC record isn't present,  doesn't validate,  OR
the certificate is not properly signed
by a CA,  then the certificate is considered invalid.

In this manner,   DNSSEC protects you against interception by a rogue
CA -- chances
are the rogue CA has not also discovered your DNSSEC secret keys,
and the  CA signature protects you against a compromise of the DNS, or an attack
by your domain registrar--  your domain registrar is probably not
a CA and doesn't
have the right paperwork,
therefore can't get a CA signed certificate with your company's name.


The browsers then just need to revise their trust model  to require no
CA be affiliated with or
owned by any organization affiliated with a provider of domain
registration or DNS hosting services,
to ensure there's no domain registrar  entrusted to sign certs, and no
CA entrusted to maintain
DNSSEC data.

--
-JH

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Marcus Reid]

On Mon, Sep 12, 2011 at 11:00:47PM +0100, Tony Finch wrote:
> Note that a big weak point in the DNS is the interface between the
> registrars and the registry. If you have a domain you have to trust the
> registry to impose suitable restrictions on its registrars to prevent a
> dodgy registrar from stealing your domain. Another, of course, is the
> interface between a registrar and its customers.

Just in case anybody missed it, ups.com, theregister.co.uk, and others
were hijacked in this way last week.

http://www.theregister.co.uk/2011/09/05/dns_hijack_service_updated/

Marcus

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[fredrik danerklint]

Tony,

Thanks for this explanation! 

I think this is what I've been looking for regarding securing DNSSEC.


> > and how about a end user, who doesn't understand a computer at all, to
> > be able verify the signatures, correctly?
> 
> The current trust model for DNSSEC relies on the vendor of the validator
> to bootstrap trust in the root key. This is partly a matter of pragmatism
> since the validator is a black-box agent acting on the user's behalf, like
> any other software.
> 
> It is also required by the root key management policies, since a root key
> rollover takes a small number of weeks, much shorter than the
> not-in-service shelf life of validating software and hardware. This means
> that a validator cannot simply use the root key as a trust anchor and
> expect to work: it needs some extra infrastructure supported by the vendor
> to authenticate the root key if there happens to have been a rollover
> between finalizing the software and deploying it.
> 
> Tony.

-- 
//fredan

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Tony Finch]

> > > > with dane, i trust whoever runs dns for citibank to identify the cert
> > > > for citibank.  this seems much more reasonable than other approaches,
> > > > though i admit to not having dived deeply into them all.
> > > If the root DNS keys were compromised in an all DNS rooted world...
> > > unhappiness would ensue in great volume.

Compromise of DNSSEC == compromise of one or more DNS registries.
This is a fate sharing situation. A few single points of failure
rather than hundreds.

Note that a big weak point in the DNS is the interface between the
registrars and the registry. If you have a domain you have to trust the
registry to impose suitable restrictions on its registrars to prevent a
dodgy registrar from stealing your domain. Another, of course, is the
interface between a registrar and its customers.

> It also drives up complexity too and makes you wonder what the added
> value of those cert vendors is for the money you're forking over.

During rollout the cert vendors will be providing backwards compatibility.

> Especially when you consider the criticality of dns naming for everything
> except web site host names using tls.

If a website using TLS loses its DNS then (a) you can't reach it, and (b)
the attacker can trivially obtain a new domain validated certificate.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fisher, German Bight, Humber, Thames, Dover: Southwest 7 to severe gale 9.
Rough or very rough, becoming high in Fisher. Showers. Moderate or good.

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[Tony Finch]

fredrik danerklint  wrote:
>
> and how about a end user, who doesn't understand a computer at all, to
> be able verify the signatures, correctly?

The current trust model for DNSSEC relies on the vendor of the validator
to bootstrap trust in the root key. This is partly a matter of pragmatism
since the validator is a black-box agent acting on the user's behalf, like
any other software.

It is also required by the root key management policies, since a root key
rollover takes a small number of weeks, much shorter than the
not-in-service shelf life of validating software and hardware. This means
that a validator cannot simply use the root key as a trust anchor and
expect to work: it needs some extra infrastructure supported by the vendor
to authenticate the root key if there happens to have been a rollover
between finalizing the software and deploying it.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Biscay, FitzRoy: Southwesterly 4 or 5, veering northerly or northwesterly 5 or
6, occasionally 7 later in southeast Fitzroy. Rough or very rough. Rain or
showers. Good, occasionally poor.

Re: [NANOG-announce] NANOG 53 draft agenda available

[David Meyer]

 Sure. NANOG support can you update please?

Thanks,

Dave

On Mon, Sep 12, 2011 at 2:40 PM, Aaron Hughes  wrote:
> David,
>
> I am also running the Peering Track (which will be good for IXs and such to 
> know to contact me ahead of time). Can you please add 'Aaron Hughes, CTO 
> 6connect' to the Peering Track as well?
>
> Thanks!
>
> Cheers,
> Aaron
>
> On Mon, Sep 12, 2011 at 02:28:03PM -0700, David Meyer wrote:
>> Please see http://www.nanog.org/meetings/nanog53/agenda.html.
>>
>> Note that the Loews room block expires on 09/23/2011. Note also that
>> the standard registration fee runs through 10/04/2011.
>>
>> Looking forward to seeing you in Philadelphia.
>>
>> Thanks,
>>
>> Dave
>>
>> (for the NANOG PC)
>>
>> --
>> NANOG-announce mailing list
>> nanog-annou...@nanog.org
>> https://mailman.nanog.org/mailman/listinfo/nanog-announce
>
> --
>
> Aaron Hughes
> aar...@bind.com
> +1-831-824-4161
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> http://www.bind.com/
>

___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: vyatta for bgp

[Nick Hilliard]

On 12/09/2011 20:45, Owen DeLong wrote:
> In your typical enterprise environment, a 1G DoS will zorch the link long
> before it zorches the router at the enterprise side.

It sure will, unless you have multiple 1G links into your router, in which
case the ddos will effectively trash all the links.

> I agree that software-based routers are not a good choice for a backbone
> provider, but, for an enterprise that is dealing with <1gbps links coming
> in from ≤3 providers, the difference in cost makes a software router an
> attractive option in many cases.
> 
> Of course it is important to understand the limitations of the solution you
> choose, but, in such an environment, a USD100,000+ ASIC based router
> may be like trying to kill a mosquito with a sledge hammer.

Indeed - as you implicitly point out, it's a cost / benefit thing.  So then
the question becomes this: for the set of organisations which are large
enough to warrant multiple 1G upstreams, how long an outage can they
sustain before the price difference becomes worth it?

Let's throw some figures around (ridiculously simplified):  a company has a
choice between a pair of $10k software routers or something like a pair of
MX80s for $25k each.  So, one solution costs $20k; the other $50k.  $30k
cost difference works out as $625 per month depreciation (4 year).  I.e.
not going to affect the bottom line in any meaningful way.

Now say that this company has a DoS attack for 24h, and the company
effectively loses one day of revenue.  On the basis that there are 260
office working days per year, the point at which spending an extra $30k for
a hardware router would be of net benefit to the company would be 260*30k =
$7.8m.  I.e. if your annual revenue is higher than that, and if spending
that cash would mitigate against your DoS problems, then it would be worth
your while in terms of direct loss mitigation.

Of course, this analysis is quite simplistic and excludes things like
damage to reputation, online stores, the likelihood of DoS attacks
happening in the first place, the cost of transit and many other points of
reality.  However, the point is that the break-even point for getting
serious horsepower for your transit requirements is surprisingly low once
you take into account the relationship between functional corporate
internet connectivity and either or both of corporate revenue and corporate
productivity.

It's extraordinary how much attention senior management starts paying when
everyone in the office starts twiddling their thumbs because connectivity
has been down for the day.

Nick

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Tony Finch]

Mike Jones  wrote:
>
> DNSSEC deployment is advanced enough now to do that automatically at the
> client.

Sadly not quite. DNSSEC does have the potential to provide an alternative
public key infrastructure, and I'm keen to see that happen. But although
it works well between authoritative servers and recursive resolvers, there
are a lot of shitty DNS forwardersin CPE and captive portals and so on
which do not understand DNSSEC. And DNSSEC does not work unless all the
forwarders and recursors that you are using support it. So DNSSEC on the
client has a long way to go.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Hebrides, Southeast Bailey: Westerly 5 to 7 until later in south Hebrides,
otherwise northwesterly 3 or 4, increasing 5 to 7. Rough or very rough,
occasionally high in south Hebrides. Rain or showers. Good, occasionally
poor.

Re: vyatta for bgp

[Martin Millnert]

Brent,

On Mon, Sep 12, 2011 at 11:13 PM, Brent Jones  wrote:
> Lots of devices can have trouble if you direct high PPS to the control
> plane, and will exhibit performance degradation, leading up to a DoS
> eventually.
> That isn't limited to software based routers at all, it will impact
> dedicated ASICs. Vendors put together solutions for this, to protect
> the router itself/control plane, whether its a software based routed
> or ASICs.
> Now if this was a Microtik with an 1Ghz Intel Atom CPU, sure, lots of
> things could take that thing offline, even funny looks. But a modern,
> multi-core/multi-thread system with multi-queued NICs will handle
> hundreds of thousands of PPS directed to the router itself before
> having issues, of nearly any packet size.
> A high end ASIC can handle millions/tens of millions PPS, but directed
> to the control plane (which is often a general purpose CPU as well,
> Intel or PowerPC), probably not in most scenarios.
>
> I think its very fair for a small/medium sized organization to run
> software based routers, Vyatta included.
>

Speaking of Mikrotik there, I recently pushed 350kpps small packets
through an x86 routeros image running under kvm (using vt-d for nic)
on my desktop machine (which is a number i seem to run into more than
once when it comes to linux/linux-derivative forwarding on single
queue & core). I saw a release note claiming their next sw release
will do 15-20% more on both mips and x86. Unsurprisingly is open
source software forwarding very far from 10G linerate of small pps
through single cpu core still.
350kpps of 64B packets is of course merely 180 Mbps (notably, actually
sufficient for handling incoming small packets on a 100 Mbps uplink).

Re adversaries or random scum filling your uplinks with useless bits,
I think I hear the largest DDoS'es now have filled 100G links, so..
don't make yourself a packeting target if you happen to run smaller
links than that? :)

Generally on staying alive through DDoS by anything else than some
degree of luck, I guess having more bandwith between your network and
your peers than what your peers all have to their peers is advised
(the statement could possibly be improved upon using some minimum cut
graph theory language).

Best,
Martin

Re: Disappointing ARIN - A great advertisement for the USA ?

[Randy Bush]

> I'm not sure if all of NANOG wants to hear about the various behaviors
> of different whois clients dealing with different whois servers around
> the globe.

i doubt if there is anything which *all* of nanog wants to hear.

but i suspect a damned lot of us care about whois behavior, as we either
deal with whois (i do daily) or help our csas and nocs who do.

randy

[NANOG-announce] NANOG 53 draft agenda available

[David Meyer]

Please see http://www.nanog.org/meetings/nanog53/agenda.html.

Note that the Loews room block expires on 09/23/2011. Note also that
the standard registration fee runs through 10/04/2011.

Looking forward to seeing you in Philadelphia.

Thanks,

Dave

(for the NANOG PC)

___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: vyatta for bgp

[Dobbins, Roland]

On Sep 13, 2011, at 4:13 AM, Brent Jones wrote:

> A high end ASIC can handle millions/tens of millions PPS, but directed
> to the control plane (which is often a general purpose CPU as well,
> Intel or PowerPC), probably not in most scenarios.

CoPP.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Disappointing ARIN - A great advertisement for the USA ?

[Mark Kosters]

On 9/12/11 4:58 PM, "Michael Sinatra"  wrote:

>On 09/12/11 10:13, Always Learning wrote:
>
>> Primarily IP ranges to block and/or abuse email addresses.
>>
>>>   https://www.arin.net/participate/mailing_lists/
>>
>> Thank you.  I will try it.
>>
>>> Oh, and there they also like to see your real name and not a junk mail
>>> address. Just like on the RIPE mailinglists, you know in the old
>>>country.
>>
>> The ARIN web page http://lists.arin.net/mailman/listinfo/arin-ppml
>> states
>>
>>  Your name (optional):
>
>I think arin-discuss would be a better place for this than arin-ppml.

Actually, I think the best place to have this particular conversation is
arin-tech-discuss. ARIN engineering hangs out there and does respond. I'm
not sure if all of NANOG wants to hear about the various behaviors of
different whois clients dealing with different whois servers around the
globe. If you are interested in the more global whois directory service
problem, there is emerging work going on in the IETF to tackle the
directory service problem called WEIRDS.

Regards,
Mark
ARIN CTO

Re: vyatta for bgp

[Brent Jones]

On Mon, Sep 12, 2011 at 1:52 PM, Dobbins, Roland  wrote:
> On Sep 13, 2011, at 3:43 AM, Everton Marques wrote:
>
>> Would Cisco ISR G2 3925E classify as software-based router?
>
> Yes.
>
>> Do you expect it to bend itself down under a few Mbps of 64-byte packets?
>
> Especially if they're directed at the router itself, at some point, sure - 
> though the ISR2 certainly has more horsepower than the original ISRs, and 
> I've personally yet to witness an ISR2 being DDoSed, so I've no feel for the 
> specific numbers.  Features also play a role.
>
> This isn't to say that the ISR2 isn't a fine router - but rather that one 
> must be cognizant of performance envelopes prior to deployment in order to 
> determine suitability to purpose.  One can't reasonably expect vendors to 
> exceed their design constraints in any type of equipment.
>
> ;>
>
> One can and should test the specific performance envelope of any prospective 
> infrastructure purchase, of course.
>
> ---
> Roland Dobbins  // 
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>
>

Lots of devices can have trouble if you direct high PPS to the control
plane, and will exhibit performance degradation, leading up to a DoS
eventually.
That isn't limited to software based routers at all, it will impact
dedicated ASICs. Vendors put together solutions for this, to protect
the router itself/control plane, whether its a software based routed
or ASICs.
Now if this was a Microtik with an 1Ghz Intel Atom CPU, sure, lots of
things could take that thing offline, even funny looks. But a modern,
multi-core/multi-thread system with multi-queued NICs will handle
hundreds of thousands of PPS directed to the router itself before
having issues, of nearly any packet size.
A high end ASIC can handle millions/tens of millions PPS, but directed
to the control plane (which is often a general purpose CPU as well,
Intel or PowerPC), probably not in most scenarios.

I think its very fair for a small/medium sized organization to run
software based routers, Vyatta included.

-- 
Brent Jones
br...@servuhome.net

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Jasper Wallace]

On Mon, 12 Sep 2011, Gregory Edigarov wrote:

> On Mon, 12 Sep 2011 12:12:08 +0200
> Martin Millnert  wrote:
> 
> > Mike,
> > 
> > On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones  wrote:
> > > It will take a while to get updated browsers rolled out to enough
> > > users for it do be practical to start using DNS based self-signed
> > > certificated instead of CA-Signed certificates, so why don't any
> > > browsers have support yet? are any of them working on it?
> > 
> > Chrome v 14 works with DNS stapled certificates, sort of a hack. (
> > http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
> > 
> > There are other proposals/ideas out there, completely different to
> > DANE / DNSSEC, like http://perspectives-project.org/ /
> > http://convergence.io/ .
> 
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...

The point of perspectives and convergence is this. The browser says:

>From my point of view site X has a certificate with fingerprint Y, what do 
you guys all see from your points of view?

If the perspectives/convergence servers see a different certificate then 
you know that you are the victim of a mitm attack..

I.E. the perspectives and convergence system does not attempt to assert 
anything about a sites identity, just that everyone sees the same cert for 
a site.

(of course if the mitm is happening close enough to the site 
networktopologicly speaking than all the perspectives/convergence servers 
will see the same, fake, cert and your out of luck).

> Well, I do not even see how can one trust any certificate that is
> issued by commercial organization. 

perspectives and convergence don't issue certs.

-- 
[http://pointless.net/]   [0x2ECA0975]

Re: Disappointing ARIN - A great advertisement for the USA ?

[Randy Bush]

>> Now, I agree on the part that ARIN should be doing RPSL, or even
>> more, just start using the RIPE whois server for serving their data.
> Now wait one moment until I bog you down with 20 years worth of legacy
> paranoia, "Not Invented Here" and useless history about why this
> shouldn't ever have happened...

you omitted looking at the code

randy

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[Måns Nilsson]

Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy, releases 
Date: Mon, Sep 12, 2011 at 10:42:35PM +0200 Quoting fredrik danerklint 
(fredan-na...@fredan.se):

> > Quite trivial, in fact.
> 
> and how about a end user, who doesn't understand a computer at all, to be 
> able 
> verify the signatures, correctly?

Joe Sixpack clicks through today. He will, too, later, but, one of
the Fine Things with DANE is that no entity can produce valid data for
anything outside its own domain(s). Damage limitation is quite important,
while admittingly not being the silver bullet.

The existence of a free and secure chain of trust will put a price
pressure on DV certificates, which just might create a situation where
the marginal cost for doing TLS is so low that it is hard to set up a
web site without.

Taken together, this creates a situation where valid, verified
certificates are the norm, for real, which makes it all the more possible
to flag the exceptions much more annoyingly. Perhaps even refuse to
open them.
-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
... this must be what it's like to be a COLLEGE GRADUATE!!


signature.asc
Description: Digital signature

Re: Disappointing ARIN - A great advertisement for the USA ?

[Michael Sinatra]

On 09/12/11 10:13, Always Learning wrote:


Primarily IP ranges to block and/or abuse email addresses.


  https://www.arin.net/participate/mailing_lists/


Thank you.  I will try it.


Oh, and there they also like to see your real name and not a junk mail
address. Just like on the RIPE mailinglists, you know in the old country.


The ARIN web page http://lists.arin.net/mailman/listinfo/arin-ppml
states

Your name (optional):


I think arin-discuss would be a better place for this than arin-ppml.


The 'old country' sounds a bit South African to me. I'm European and
English.


I think Jeroen's point was that you didn't need to pass judgement on all 
of North America and/or the USA because ARIN did something you didn't like.


michael

Re: vyatta for bgp

[Dobbins, Roland]

On Sep 13, 2011, at 3:43 AM, Everton Marques wrote:

> Would Cisco ISR G2 3925E classify as software-based router?

Yes.

> Do you expect it to bend itself down under a few Mbps of 64-byte packets?

Especially if they're directed at the router itself, at some point, sure - 
though the ISR2 certainly has more horsepower than the original ISRs, and I've 
personally yet to witness an ISR2 being DDoSed, so I've no feel for the 
specific numbers.  Features also play a role.

This isn't to say that the ISR2 isn't a fine router - but rather that one must 
be cognizant of performance envelopes prior to deployment in order to determine 
suitability to purpose.  One can't reasonably expect vendors to exceed their 
design constraints in any type of equipment.

;>

One can and should test the specific performance envelope of any prospective 
infrastructure purchase, of course.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: vyatta for bgp

[Ben Albee]

Thanks for the all the feed-back. 

 

We will only have two ipv4 BGP peers (both 5mb/sec links) to the same
ISP. We are doing BGP because we plan to add a second ISP at one of our
locations in the future.  We are not any near a large enterprise, this
will be replacing two DSL lines and a T1. 

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[fredrik danerklint]

> > > > How about a TXT record with the CN string of the CA cert subject in
> > > > it? If it exists and there's a conflict, don't trust it.  Seems
> > > > simple enough to implement without too much collateral damage.
> > > 
> > > Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> > > to attacks via DNS poisoning (either insert a malicious TXT that
> > > matches your malicious certificate, or insert a malicious TXT that
> > > intentionally *doesn't* match the vicitm's certificate)
> > 
> > And how do you validate the dnssec to make sure that noone has tampered
> > with it.
> 
> Since you are from Sweden, and in an IT job, you probably have personal
> relations to someone who has personal relations to one of the swedes
> or other nationalities that were present at the key ceremonies for the
> root. Once you've established that the signatures on the root KSK are good
> (which -- because of the above -- should be doable OOB quite easily for
> you) you can start validating the entire chain of trust.
> 
> Quite trivial, in fact.

and how about a end user, who doesn't understand a computer at all, to be able 
verify the signatures, correctly?

-- 
//fredan

Re: vyatta for bgp

[Everton Marques]

On Mon, Sep 12, 2011 at 5:12 PM, Dobbins, Roland  wrote:
> On Sep 13, 2011, at 2:45 AM, Owen DeLong wrote:
>
>> In your typical enterprise environment, a 1G DoS will zorch the link long 
>> before it zorches the router at the enterprise side.
>
> This contradicts my experience - I've repeatedly witnessed only a few mb/sec 
> of 64-byte packets making software-based routers fall over, including just 
> last month.

Would Cisco ISR G2 3925E classify as software-based router?
Expected NDR performance is about 1845 pps (64-byte packets).
That should deliver room for some 100s of Mbps.
Do you expect it to bend itself down under a few Mbps of 64-byte packets?

http://www.anticisco.ru/pubs/ISR_G2_Perfomance.pdf

Everton

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[Valdis . Kletnieks]

On Mon, 12 Sep 2011 22:31:59 +0200, Måns Nilsson said:

> Since you are from Sweden, and in an IT job, you probably have personal
> relations to someone who has personal relations to one of the swedes
> or other nationalities that were present at the key ceremonies for the
> root. Once you've established that the signatures on the root KSK are good
> (which -- because of the above -- should be doable OOB quite easily for
> you) you can start validating the entire chain of trust.
> 
> Quite trivial, in fact.

I'll note that the PGP "strongly connected set" has grown all the way to 45,000
or so keys in 2 decades of growth.  There are several billion Internet users. 
What
may be workable for Fredrik is probably *not* scalable to Joe Sixpack.


pgpHk6Uevbz09.pgp
Description: PGP signature

Re: vyatta for bgp

[Dobbins, Roland]

On Sep 13, 2011, at 3:34 AM, Chuck Church wrote:

> Is the concern over a DDOS aimed against the router itself, or just massive 
> flows passing through?

Yes, but mainly the former.

;>

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: vyatta for bgp

[Valdis . Kletnieks]

On Mon, 12 Sep 2011 20:12:43 -, "Dobbins, Roland" said:
> This contradicts my experience - I've repeatedly witnessed only a few mb/sec
> of 64-byte packets making software-based routers fall over, including just 
> last
> month.

On the flip side, there's a *lot* of sites that have to make trade-offs, and the
risk that their $10K software-based router may fall over doesn't justify adding
another zero to the price tag, especially if their network includes a lot of
branch offices that would all add another zero


pgpzyUSU71dRV.pgp
Description: PGP signature

RE: vyatta for bgp

[Chuck Church]

Original Message-
From: Dobbins, Roland [mailto:rdobb...@arbor.net] 
Sent: Monday, September 12, 2011 2:56 PM
To: North American Network Operators' Group
Subject: Re: vyatta for bgp

>zorched.

---

Zorch.  I like that.  Sounds like a Batman fight-scene bubble word.

Is the concern over a DDOS aimed against the router itself, or just massive
flows passing through?

Chuck

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[Måns Nilsson]

Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy, releases 
Date: Mon, Sep 12, 2011 at 11:46:04AM +0200 Quoting fredrik danerklint 
(fredan-na...@fredan.se):
> > > How about a TXT record with the CN string of the CA cert subject in it?
> > > If it exists and there's a conflict, don't trust it.  Seems simple
> > > enough to implement without too much collateral damage.
> > 
> > Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> > to attacks via DNS poisoning (either insert a malicious TXT that matches
> > your malicious certificate, or insert a malicious TXT that intentionally
> > *doesn't* match the vicitm's certificate)
> 
> And how do you validate the dnssec to make sure that noone has tampered with 
> it.

Since you are from Sweden, and in an IT job, you probably have personal
relations to someone who has personal relations to one of the swedes
or other nationalities that were present at the key ceremonies for the
root. Once you've established that the signatures on the root KSK are good
(which -- because of the above -- should be doable OOB quite easily for
you) you can start validating the entire chain of trust.

Quite trivial, in fact. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Am I in GRADUATE SCHOOL yet?


signature.asc
Description: Digital signature

Re: vyatta for bgp

[Dobbins, Roland]

On Sep 13, 2011, at 2:45 AM, Owen DeLong wrote:

> In your typical enterprise environment, a 1G DoS will zorch the link long 
> before it zorches the router at the enterprise side.

This contradicts my experience - I've repeatedly witnessed only a few mb/sec of 
64-byte packets making software-based routers fall over, including just last 
month.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Eliot Lear]

On 9/12/11 4:32 PM, Jason Duerstock wrote:
> Except that this just shifts the burden of trust on to DNSSEC, which
> also necessitates a central authority of 'trust'.  Unless there's an
> explicitly more secure way of storing DNSSEC private keys, this just
> moves the bullseye from CAs to DNSSEC signers.

I said "some", not all, of the responsibility.  By adding an independent
PKI there is an additional control put in place to confirm that in fact
the signer is authorized to sign.  Should one go as far as to remove CA
caches from browsers altogether?

Eliot

Re: vyatta for bgp

[Owen DeLong]

On Sep 12, 2011, at 12:35 PM, Nick Hilliard wrote:

> On 12/09/2011 20:08, Michael K. Smith - Adhost wrote:
>> How do you come to this conclusion?  I think a software-based router for
>> enterprise level (let's say on the 1G per provider level) can handle a
>> fair amount of zorching.
> 
> I presume by "a fair amount", I presume you mean "barely any"?
> 
> At large packet sizes, an "enterprise level" router will just about handle
> a 1G DoS attack.  Thing is, bandwidth DoS / DDoS is sufficiently easy to
> pull off on a large scale that a 1G DoS is pretty easy.
> 
> Incidentally, most service providers use "enterprise level" as a by-word
> for mediocre quality kit, lacking in both stability and useful features.
> 
> Nick

In your typical enterprise environment, a 1G DoS will zorch the link long
before it zorches the router at the enterprise side.

I agree that software-based routers are not a good choice for a backbone
provider, but, for an enterprise that is dealing with <1gbps links coming
in from ≤3 providers, the difference in cost makes a software router an
attractive option in many cases.

Of course it is important to understand the limitations of the solution you
choose, but, in such an environment, a USD100,000+ ASIC based router
may be like trying to kill a mosquito with a sledge hammer.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: vyatta for bgp

[Jared Geiger]

On Mon, Sep 12, 2011 at 2:42 PM, Ben Albee  wrote:

> Does anybody currently use vyatta as a bgp router for their company? If
> so have you ran into any problems with using that instead of a cisco or
> juniper router?
>
>
There was a bug where you couldn't use two IPv4 peers and then add IPv6. I
haven't tested the newest versions yet to see if it still exists. Works
great for two IPv4 peers.

Re: vyatta for bgp

[Dobbins, Roland]

On Sep 13, 2011, at 2:08 AM, Michael K. Smith - Adhost wrote:

> How do you come to this conclusion?

Unhappy experiences.

;>

>  I think a software-based router for enterprise level (let's say on the 1G 
> per provider level) can handle a fair amount of zorching.

My experiences indicates otherwise, FWIW.  It's very easy to packet a 
software-based router over a relatively small transit link in the mb/sec range, 
much less gb/sec - it happens all the time, FYI.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: vyatta for bgp

[Nick Hilliard]

On 12/09/2011 20:08, Michael K. Smith - Adhost wrote:
> How do you come to this conclusion?  I think a software-based router for
> enterprise level (let's say on the 1G per provider level) can handle a
> fair amount of zorching.

I presume by "a fair amount", I presume you mean "barely any"?

At large packet sizes, an "enterprise level" router will just about handle
a 1G DoS attack.  Thing is, bandwidth DoS / DDoS is sufficiently easy to
pull off on a large scale that a 1G DoS is pretty easy.

Incidentally, most service providers use "enterprise level" as a by-word
for mediocre quality kit, lacking in both stability and useful features.

Nick

RE: vyatta for bgp

[Michael K. Smith - Adhost]

> -Original Message-
> From: Dobbins, Roland [mailto:rdobb...@arbor.net]
> Sent: Monday, September 12, 2011 11:56 AM
> To: North American Network Operators' Group
> Subject: Re: vyatta for bgp
> 
> On Sep 13, 2011, at 1:42 AM, Ben Albee wrote:
> 
> > Does anybody currently use vyatta as a bgp router for their company?
> 
> The days of public-facing software-based routers were over years ago - you
> need an ASIC-based edge router, else you'll end up getting zorched.
> 
How do you come to this conclusion?  I think a software-based router for 
enterprise level (let's say on the 1G per provider level) can handle a fair 
amount of zorching.  I checked the Cisco and Juniper docs and neither vendor is 
anywhere near releasing their anit-zorching ASICs.

Mike 

Re: vyatta for bgp

[fredrik danerklint]

> The days of public-facing software-based routers were over years ago - you
> need an ASIC-based edge router, else you'll end up getting zorched.

wait, what?

-- 
//fredan

Re: vyatta for bgp

[Dobbins, Roland]

On Sep 13, 2011, at 1:42 AM, Ben Albee wrote:

> Does anybody currently use vyatta as a bgp router for their company?

The days of public-facing software-based routers were over years ago - you need 
an ASIC-based edge router, else you'll end up getting zorched.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

vyatta for bgp

[Ben Albee]

Does anybody currently use vyatta as a bgp router for their company? If
so have you ran into any problems with using that instead of a cisco or
juniper router?

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Mike Jones]

On 12 September 2011 18:39, Robert Bonomi  wrote:
> Seriously, about the only way I see to ameliorate this kind of problem is
> for people to use self-signed certificates that are then authenticated
> by _multiple_ 'trust anchors'.  If the end-user world raises warnings
> for a certificate 'authenticated' by say, less than five separate entities.
> then the compomise of any _single_ anchor is of pretty much 'no' value.
> Even better, let the user set the 'paranoia' level -- how many different
> 'trusted' authorities have to have authenticated the self-signed certificate
> before the user 'really trusts' it.

So if I want my small website to support encryption, I now have to pay
5 companies, and hope that all my users have those 5 CAs in their
browser? Much better to use the existing DNS infrastructure (that all
5 of them would likely be using for their validation anyway), and not
have to pay anyone anything.

- Mike

Re: Disappointing ARIN - A great advertisement for the USA ?

[Brandon Ewing]

On Mon, Sep 12, 2011 at 12:53:47PM -0400, Jon Lewis wrote:
> Prepending the query with a + "works" for me, in that I get the expected 
> data, but there's additional unexpeced data (full record for the Parent, 
> even if the Parent is just an ARIN /8) in the output that will probably 
> still cause problems for scripts.

I'm just sad I can't get the RWHOIS referral from an ip query for jwhois to
follow automatically anymore.

-- 
Brandon Ewing(nicot...@warningg.com)


pgpW2IMlw88Mz.pgp
Description: PGP signature

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Christopher Morrow]

On Mon, Sep 12, 2011 at 1:39 PM, Robert Bonomi  wrote:
>
>> Date: Mon, 12 Sep 2011 11:22:11 -0400
>> Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy,
>>  releases updates
>> From: Christopher Morrow 
>>
>> I think I need a method that the service operator can use to signal to my
>> user-client outside the certificate itself that the certificate
>> #1234 is the 'right' one.
>
> A certificate that cdrtifies the crertificate is valid, maybe?

so the DANE work does this, sort of... you sign (with dnssec) your
cert fingerprint, the client does a lookup (requiring dnssec signed
responses) to verify that the cert FP matches that which is in DNS.

> And why would you trust that any more than the origial certificate?

at least in this case the domain owner (presumably the service owner
in question) has signed (with their private key) the DNS content you
get back.

There are failure modes, but it's more in line with the
service-owner/service-user level not some oddball thirdparty.

> Seriously, about the only way I see to ameliorate this kind of problem is
> for people to use self-signed certificates that are then authenticated
> by _multiple_ 'trust anchors'.  If the end-user world raises warnings
> for a certificate 'authenticated' by say, less than five separate entities.
> then the compomise of any _single_ anchor is of pretty much 'no' value.
> Even better, let the user set the 'paranoia' level -- how many different
> 'trusted' authorities have to have authenticated the self-signed certificate
> before the user 'really trusts' it.
>

this almost sounds like GPS position fixing... 'require 4 satellites
in view', or something along those lines. Interesting as an idea
though.

-chris

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Damian Menscher]

On Mon, Sep 12, 2011 at 7:09 AM, Martin Millnert  wrote:

>
> Something similar, including use of purchased (not only limited to
> stolen certs), is ongoing already, all of the time.  (I had a fellow
> IRC-chat-friend report from a certain very western-allied middle
> eastern country that there's ISP/state-scale SSL-MITM ongoing there,
> for all https traffic.)


If this were true, don't you think your friend would provide an SSL cert?

Damian
-- 
Damian Menscher :: Security Reliability Engineer :: Google

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Robert Bonomi]

> Date: Mon, 12 Sep 2011 11:22:11 -0400
> Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy,
>  releases updates
> From: Christopher Morrow 
>
> I think I need a method that the service operator can use to signal to my 
> user-client outside the certificate itself that the certificate
> #1234 is the 'right' one.

A certificate that cdrtifies the crertificate is valid, maybe?

And why would you trust that any more than the origial certificate?

And, if you do trust *that* certificate, what do you need the original
one for?


Seriously, about the only way I see to ameliorate this kind of problem is
for people to use self-signed certificates that are then authenticated
by _multiple_ 'trust anchors'.  If the end-user world raises warnings
for a certificate 'authenticated' by say, less than five separate entities.
then the compomise of any _single_ anchor is of pretty much 'no' value.  
Even better, let the user set the 'paranoia' level -- how many different
'trusted' authorities have to have authenticated the self-signed certificate
before the user 'really trusts' it.

Similarly, the certificate 'owner' can decide how much 'redundancy' it
wants in the 'authentiation' of it's identity -- how many separate 
authorities it gets to 'co-sign' it's certificate.

Re: Disappointing ARIN - A great advertisement for the USA ?

[Nick Hilliard]

On 12/09/2011 17:17, Jeroen Massar wrote:
> You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

and you are confusing RPSL with RIPE-181 syntax.  RIPE-181 and its
grandchildren is a specification for whois information.  RPSL is a routing
policy language which uses ripe-181 format.  The two are not the same.

> Now, I agree on the part that ARIN should be doing RPSL, or even more,
> just start using the RIPE whois server for serving their data.

Now wait one moment until I bog you down with 20 years worth of legacy
paranoia, "Not Invented Here" and useless history about why this shouldn't
ever have happened...

Nick

Re: Disappointing ARIN - A great advertisement for the USA ?

[Jon Lewis]

On Mon, 12 Sep 2011, Christopher Morrow wrote:


my guess is that ARIN is hoping folks turn to the actual RESTful
interface for many scripted purposes...I keep expecting to see some
example python/perl/etc off:




 Should I change my code to parse the RESTful Interface instead of the
 NICNAME/WHOIS TCP port 43 service?

 Absolutely. We encourage use of the new RESTful service for the purposes
 of programmatic consumption. ARIN plans to make more features available
 on the RESTful interface. The NICNAME/WHOIS service will remain accessible,
 but it may not support the enhanced features we intend to incorporate
 within Whois-RWS.

It'd be nice if the NICNAME/WHOIS was left alone as far as default 
behavior is concerned.


So, our tools that use the NICNAME/WHOIS service for lookups at all the 
other RIRs, now need to be updated to support ARIN's overcomplicated 
web/XML, which nobody else uses?...and it seems even with RWS you still 
need to do multiple queries to go from having an IP to having the full 
whois record.


How does the community (other than some programmers) benefit from this?

--
 Jon Lewis, MCP :)   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Disappointing ARIN - A great advertisement for the USA ?

[Always Learning]

On Mon, 2011-09-12 at 18:17 +0200, Jeroen Massar wrote:
> On 2011-09-12 17:40 , Always Learning wrote:
> 
> Dear person who is to scared to setup a regular email account in his own
> full name.

Beste Fuzzel,

Mijn naam is Paul. It was at the bottom of my posting.

Sorry I have never ever had a Hotmail account. I prefer to use
na...@u61.u22.net for this list. I really do not want to set-up another
email account for your personal benefit.

> You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

No I am not.  A basic WHOIS enquiry is what I was writing about.

> Next to that the bigger question is of course what you are looking for
> in the whois data.

Primarily IP ranges to block and/or abuse email addresses.

>  https://www.arin.net/participate/mailing_lists/

Thank you.  I will try it.

> Oh, and there they also like to see your real name and not a junk mail
> address. Just like on the RIPE mailinglists, you know in the old country.

The ARIN web page http://lists.arin.net/mailman/listinfo/arin-ppml
states

Your name (optional):

The 'old country' sounds a bit South African to me. I'm European and
English.

> Greets,

Groet in Dutch or Greetings in English.

Have a nice day.


Paul
Always Learning, hopefully until I die.

Re: Disappointing ARIN - A great advertisement for the USA ?

[Christopher Morrow]

On Mon, Sep 12, 2011 at 12:53 PM, Jon Lewis  wrote:
> On Mon, 12 Sep 2011, Eric Krichbaum wrote:
>
>> That was on June 25th according to Mark Kosters.  They started to answer
>> with both the parent and delegated objects.  That hosed the way RWHOIS
>> data
>> was being reported to most things as the client won't know which to send
>> through to the rwhois servers.  Still works from an old SCO box but not
>> from
>> anything current.
>>
>> A "+" flag on the query from some clients will get it to recurse, but for
>> my
>> tests kicked back "%error 350 Invalid Query Syntax".
>
> Prepending the query with a + "works" for me, in that I get the expected
> data, but there's additional unexpeced data (full record for the Parent,
> even if the Parent is just an ARIN /8) in the output that will probably
> still cause problems for scripts.


my guess is that ARIN is hoping folks turn to the actual RESTful
interface for many scripted purposes...I keep expecting to see some
example python/perl/etc off:



but at least the api is documented, it ought to be fairly
straightforward to make a simple whois client.
(that could be extended to be used in whatever scripty thing you were
using before)
-chris

RE: Disappointing ARIN - A great advertisement for the USA ?

[Jon Lewis]

On Mon, 12 Sep 2011, Eric Krichbaum wrote:


That was on June 25th according to Mark Kosters.  They started to answer
with both the parent and delegated objects.  That hosed the way RWHOIS data
was being reported to most things as the client won't know which to send
through to the rwhois servers.  Still works from an old SCO box but not from
anything current.

A "+" flag on the query from some clients will get it to recurse, but for my
tests kicked back "%error 350 Invalid Query Syntax".


Prepending the query with a + "works" for me, in that I get the expected 
data, but there's additional unexpeced data (full record for the Parent, 
even if the Parent is just an ARIN /8) in the output that will probably 
still cause problems for scripts.



--
 Jon Lewis, MCP :)   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: Disappointing ARIN - A great advertisement for the USA ?

[Eric Krichbaum]

That was on June 25th according to Mark Kosters.  They started to answer
with both the parent and delegated objects.  That hosed the way RWHOIS data
was being reported to most things as the client won't know which to send
through to the rwhois servers.  Still works from an old SCO box but not from
anything current.

A "+" flag on the query from some clients will get it to recurse, but for my
tests kicked back "%error 350 Invalid Query Syntax". 

My issue with that response is that the general whois query shouldn't have
to have an extra flag passed to get the data you asked for in the first
place.   This traps out most of the standard users from ever getting the
correct data.  It also makes the rwhois data almost impossible for the
general public to get.

Eric




-Original Message-
From: Jon Lewis [mailto:jle...@lewis.org] 
Sent: Monday, September 12, 2011 11:32 AM
To: Jeroen Massar
Cc: p...@arin.net; NANOG
Subject: Re: Disappointing ARIN - A great advertisement for the USA ?

On Mon, 12 Sep 2011, Jeroen Massar wrote:

> On 2011-09-12 17:40 , Always Learning wrote:
>
> Dear person who is to scared to setup a regular email account in his 
> own full name.
>
> [..]
>> The Internet was created in North America. Many people around the 
>> world would appreciate your help in getting ARIN to revert to normal 
>> WHOIS displays. ARIN wants enquirers to click on web page after web 
>> page to try and find the information previously displayed in a single
response.
>> Frankly that weird attitude is stark raving bonkers!
>
> You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

No he's not.  He's complaining that sometime in the past few weeks (or is it
months now?) ARIN changed the behavior of their whois server.  New output
for the query 209.208.0.1 is (omitting comments):

Internet Connect Company, Inc. ICC-1 (NET-209-208-0-0-1) 209.208.0.0 -
209.208.127.255 American Registry for Internet Numbers NET209
(NET-209-0-0-0-0) 209.0.0.0 - 209.255.255.255

The old behavior was that ARIN's whois server would respond with the data
from NET-209-208-0-0-1.  i.e.

NetRange:   209.208.0.0 - 209.208.127.255
CIDR:   209.208.0.0/17
OriginAS:
NetName:ICC-1
NetHandle:  NET-209-208-0-0-1
Parent: NET-209-0-0-0-0
NetType:Direct Allocation
...

This is rather an annoying change for anyone who uses whois much as it means
every ARIN query is now at least two queries and there are doubtless scripts
in use to grab information from whois that broke as a result of this change.
NANOG isn't the place to complain about this though. 
Perhaps PPML is closer to the right place.

--
  Jon Lewis, MCP :)   |  I route
  Senior Network Engineer |  therefore you are
  Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Disappointing ARIN - A great advertisement for the USA ?

[Always Learning]

On Mon, 2011-09-12 at 12:32 -0400, Jon Lewis wrote:

> No he's not.  He's complaining that sometime in the past few weeks (or is 
> it months now?) ARIN changed the behavior of their whois server.  New 
> output for the query 209.208.0.1 is (omitting comments):
> 
> Internet Connect Company, Inc. ICC-1 (NET-209-208-0-0-1) 209.208.0.0 - 
> 209.208.127.255
> American Registry for Internet Numbers NET209 (NET-209-0-0-0-0) 209.0.0.0 - 
> 209.255.255.255
> 
> The old behavior was that ARIN's whois server would respond with the data 
> from NET-209-208-0-0-1.  i.e.
> 
> NetRange:   209.208.0.0 - 209.208.127.255
> CIDR:   209.208.0.0/17
> OriginAS:
> NetName:ICC-1
> NetHandle:  NET-209-208-0-0-1
> Parent: NET-209-0-0-0-0
> NetType:Direct Allocation
> ...
> 
> This is rather an annoying change for anyone who uses whois much as it 
> means every ARIN query is now at least two queries and there are doubtless 
> scripts in use to grab information from whois that broke as a result of 
> this change.  NANOG isn't the place to complain about this though. 
> Perhaps PPML is closer to the right place.

Thank you for confirming the problem. I'll try your PPML @ ARIN
suggestion.


-- 
With best regards,

Paul,
England,
EU.

Re: Disappointing ARIN - A great advertisement for the USA ?

[Jon Lewis]

On Mon, 12 Sep 2011, Jeroen Massar wrote:


On 2011-09-12 17:40 , Always Learning wrote:

Dear person who is to scared to setup a regular email account in his own
full name.

[..]

The Internet was created in North America. Many people around the world
would appreciate your help in getting ARIN to revert to normal WHOIS
displays. ARIN wants enquirers to click on web page after web page to
try and find the information previously displayed in a single response.
Frankly that weird attitude is stark raving bonkers!


You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).


No he's not.  He's complaining that sometime in the past few weeks (or is 
it months now?) ARIN changed the behavior of their whois server.  New 
output for the query 209.208.0.1 is (omitting comments):


Internet Connect Company, Inc. ICC-1 (NET-209-208-0-0-1) 209.208.0.0 - 
209.208.127.255
American Registry for Internet Numbers NET209 (NET-209-0-0-0-0) 209.0.0.0 - 
209.255.255.255

The old behavior was that ARIN's whois server would respond with the data 
from NET-209-208-0-0-1.  i.e.


NetRange:   209.208.0.0 - 209.208.127.255
CIDR:   209.208.0.0/17
OriginAS:
NetName:ICC-1
NetHandle:  NET-209-208-0-0-1
Parent: NET-209-0-0-0-0
NetType:Direct Allocation
...

This is rather an annoying change for anyone who uses whois much as it 
means every ARIN query is now at least two queries and there are doubtless 
scripts in use to grab information from whois that broke as a result of 
this change.  NANOG isn't the place to complain about this though. 
Perhaps PPML is closer to the right place.


--
 Jon Lewis, MCP :)   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Disappointing ARIN - A great advertisement for the USA ?

[Jeroen Massar]

On 2011-09-12 17:40 , Always Learning wrote:

Dear person who is to scared to setup a regular email account in his own
full name.

[..]
> The Internet was created in North America. Many people around the world
> would appreciate your help in getting ARIN to revert to normal WHOIS
> displays. ARIN wants enquirers to click on web page after web page to
> try and find the information previously displayed in a single response.
> Frankly that weird attitude is stark raving bonkers!

You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

Now, I agree on the part that ARIN should be doing RPSL, or even more,
just start using the RIPE whois server for serving their data.
Converting that all over though is not something that will happen
easily. (and ARIN has an RPSL server somewhere, but it is not that well
populated if at all remotely current)

Next to that the bigger question is of course what you are looking for
in the whois data.


NANOG is not ARIN btw, thus you are posting to the wrong mailinglist for
your rant, for that see:
 https://www.arin.net/participate/mailing_lists/

Oh, and there they also like to see your real name and not a junk mail
address. Just like on the RIPE mailinglists, you know in the old country.

Greets,
 Jeroen

Disappointing ARIN - A great advertisement for the USA ?

[Always Learning]

Hallo North Americans,

I am from Europe. A contributor on the Centos (the largest Red Hat
clone) list suggested I reposted my ARIN item on your list.


I have a BASH script called .w
It contains

#! /bin/bash
whois $1
host $1

When I type

.w 51.51.51.51 

I receive a normal and conventional display of data because that IP
address is not 'organised' by ARIN. When I type:-

.w 64.64.64.64

I receive a one line summary of possible matches, which always
includes ARIN, but omits the details we used to receive before ARIN
implemented its much criticised "improved" service.

My second script .wa is more useful for North American IP enquiries:-

#! /bin/bash
whois -h whois.arin.net n + $1
host $1

On some occasions I get a normal display of Northern American data. The
'n' and '+' are not part of WHOIS. They are ARIN's own parameters. This
example produces a 'near-as-possible-because-it-is-ARIN' display:-

.wa 65.65.65.65

However when ARIN automatically forwards the query to a North American
RWHOIS the query is apparently malformed and nothing useful is
displayed. For example:-

.wa 66.66.66.66


The Internet was created in North America. Many people around the world
would appreciate your help in getting ARIN to revert to normal WHOIS
displays. ARIN wants enquirers to click on web page after web page to
try and find the information previously displayed in a single response.
Frankly that weird attitude is stark raving bonkers!


-- 
With best regards,

Paul.
England,
EU.

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Ted Cooper]

On 13/09/11 01:12, Randy Bush wrote:
>>> as eliot pointed out, to defeat dane as currently written, you would
>>> have to compromise dnssec at the same time as you compromised the CA at
>>> the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
>>> CA trust.
>> Yes, I saw that. It also drives up complexity too and makes you wonder
>> what the added value of those cert vendors is for the money you're
>> forking over.  Especially when you consider the criticality of dns
>> naming for everything except web site host names using tls. And how
>> long would it be before browsers allowed
>> self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?
> 
> agree

I would have thought that was a perfectly acceptable end point.

The multiple CA's go away (oops), replaced with everyone being able to
publish and authenticate their own certificates. The DNS has to be
compromised to publish certificates, but if they've managed to do that,
it doesn't matter what certificate you had in the first place.

There are already public keys in the DNS for DKIM which work quite well.

It lowers the cost for getting an SSL cert for your domain, but
certainly not the security. Getting a cert for a domain is laughable
these days. It's either too easy, or stupendously hard and ridiculous.
EV certs are a joke as demonstrated by the thousands of people still
getting phished since end users don't look at the address bar anyway.

So long as it's encrypted and in some way secured against the domain,
it's good enough isn't it?

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Michael Thomas]

Martin Millnert wrote:

On Mon, Sep 12, 2011 at 5:09 PM, Michael Thomas  wrote:

And how long would it be before browsers allowed 
self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?


As previously mentioned, Chrome >= v14 already does.


The perils of coming in late in a thread :)

Mike

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Christopher Morrow]

On Mon, Sep 12, 2011 at 4:39 AM,   wrote:
> On Sun, 11 Sep 2011 22:01:47 EDT, Christopher Morrow said:
>> If I have a thawte cert for valdis.com on host A and one from comodo
>> on host B... which is the right one?
>
> You wouldn't have 2 certs for that... I'd have *one* cert for that. And if 
> when
> you got to the IP address you were trying to reach, the cert didn't validate 
> as
> matching the hostname, you know something fishy is up.
>
> And if you *do* have two certs for it, I'd like to talk to the bozos at
> Thawte and Comodo who obviously didn't check the paperwork. ;)

this has already happened with mozilla.com, google.com, microsoft.com
 my point was that as a user, and as a service operator, what in
today's CA world helps me know that the service operator's certificate
is what my user-client sees? some 'trust' in the fact that
thawte/comodo/verisign/cnnic didn't issue a cert for the
service-operator's service incorrectly?

I think I need a method that the service operator can use to signal to
my user-client outside the certificate itself that the certificate
#1234 is the 'right' one.

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Martin Millnert]

On Mon, Sep 12, 2011 at 5:09 PM, Michael Thomas  wrote:
> And how long would it be before browsers allowed 
> self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?

As previously mentioned, Chrome >= v14 already does.

Regards,
Martin

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Randy Bush]

>> as eliot pointed out, to defeat dane as currently written, you would
>> have to compromise dnssec at the same time as you compromised the CA at
>> the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
>> CA trust.
> Yes, I saw that. It also drives up complexity too and makes you wonder
> what the added value of those cert vendors is for the money you're
> forking over.  Especially when you consider the criticality of dns
> naming for everything except web site host names using tls. And how
> long would it be before browsers allowed
> self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?

agree

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Michael Thomas]

Randy Bush wrote:

with dane, i trust whoever runs dns for citibank to identify the cert
for citibank.  this seems much more reasonable than other approaches,
though i admit to not having dived deeply into them all.

If the root DNS keys were compromised in an all DNS rooted world...
unhappiness would ensue in great volume.


as eliot pointed out, to defeat dane as currently written, you would
have to compromise dnssec at the same time as you compromised the CA at
the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
CA trust.


Yes, I saw that. It also drives up complexity too and makes you wonder what
the added value of those cert vendors is for the money you're forking over.
Especially when you consider the criticality of dns naming for everything
except web site host names using tls. And how long would it be before browsers
allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?

Mike

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Gregory Edigarov]

On Mon, 12 Sep 2011 07:53:57 -0700
Michael Thomas  wrote:

> Randy Bush wrote:
> >> But Gregory is right, you cannot really trust anybody completely.
> >> Even the larger and more respectable commercial organisations will
> >> be unable to resist  when they ask
> >> for dodgy certs so they can intercept something..
> >>
> >> No, as soon as you have somebody who is not yourself in control
> >> without any third party verifiably independent oversight then you
> >> have to carefully define what you mean by trust.
> > 
> > i am having trouble with all this.  i am supposed to only trust
> > myself to identify citibank's web site?  and what to i smoke to get
> > that knowledge?  let's get real here.
> > 
> > with dane, i trust whoever runs dns for citibank to identify the
> > cert for citibank.  this seems much more reasonable than other
> > approaches, though i admit to not having dived deeply into them all.
> 
> It seems to me that this depends a lot on how much you can tolerate
> single points of failure. The current de-trusting is certainly going
> to cause trouble for whoever used that CA, but the internet didn't
> roll over and die either. If the root DNS keys were compromised in an
> all DNS rooted world... unhappiness would ensue in great volume.
> 
> Mike, poison and choices...
> 
let me state clearly what am I writing about:
ok, suppose, there is a site on the internet, that has a certificate
issued by one of the major CAs. how could one know, that certificate
wasn't issued to forged identity?  

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Randy Bush]

>> with dane, i trust whoever runs dns for citibank to identify the cert
>> for citibank.  this seems much more reasonable than other approaches,
>> though i admit to not having dived deeply into them all.
> If the root DNS keys were compromised in an all DNS rooted world...
> unhappiness would ensue in great volume.

as eliot pointed out, to defeat dane as currently written, you would
have to compromise dnssec at the same time as you compromised the CA at
the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
CA trust.

randy

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Michael Thomas]

Randy Bush wrote:

But Gregory is right, you cannot really trust anybody completely. Even
the larger and more respectable commercial organisations will be
unable to resist  when they ask for
dodgy certs so they can intercept something..

No, as soon as you have somebody who is not yourself in control
without any third party verifiably independent oversight then you have
to carefully define what you mean by trust.


i am having trouble with all this.  i am supposed to only trust myself
to identify citibank's web site?  and what to i smoke to get that
knowledge?  let's get real here.

with dane, i trust whoever runs dns for citibank to identify the cert
for citibank.  this seems much more reasonable than other approaches,
though i admit to not having dived deeply into them all.


It seems to me that this depends a lot on how much you can tolerate single
points of failure. The current de-trusting is certainly going to cause trouble
for whoever used that CA, but the internet didn't roll over and die either.
If the root DNS keys were compromised in an all DNS rooted world... unhappiness
would ensue in great volume.

Mike, poison and choices...

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Randy Bush]

> But Gregory is right, you cannot really trust anybody completely. Even
> the larger and more respectable commercial organisations will be
> unable to resist  when they ask for
> dodgy certs so they can intercept something..
> 
> No, as soon as you have somebody who is not yourself in control
> without any third party verifiably independent oversight then you have
> to carefully define what you mean by trust.

i am having trouble with all this.  i am supposed to only trust myself
to identify citibank's web site?  and what to i smoke to get that
knowledge?  let's get real here.

with dane, i trust whoever runs dns for citibank to identify the cert
for citibank.  this seems much more reasonable than other approaches,
though i admit to not having dived deeply into them all.

randy

Re: DANE and DNSSEC, was Microsoft deems all DigiNotar

[John Levine]

In article 
 you 
write:
>Except that this just shifts the burden of trust on to DNSSEC, which also
>necessitates a central authority of 'trust'.  Unless there's an explicitly
>more secure way of storing DNSSEC private keys, this just moves the bullseye
>from CAs to DNSSEC signers.

It does, but it also limits the damage.  If you lose your DNSSEC key,
bad guys can forge names below you in the DNS tree.  If you lose your
CA key, bad guys can forge any name they want.

Or to look at it another way, if I put effort into securing my own
DNS, and I am careful about the providers above me in the tree, I can
limit the chance of DNSSEC compromise.  With SSL, it doesn't matter
what I do, I'm always at the mercy of the next Diginotar.

R's,
John

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Jason Duerstock]

Except that this just shifts the burden of trust on to DNSSEC, which also
necessitates a central authority of 'trust'.  Unless there's an explicitly
more secure way of storing DNSSEC private keys, this just moves the bullseye
from CAs to DNSSEC signers.

Jason

On Mon, Sep 12, 2011 at 5:30 AM, Eliot Lear  wrote:

> Hank and everyone,
>
> This is a very interesting problem.  As it happens, some folks in the
> IETF have anticipated this one.  For those who are interested, Paul
> Hoffman and Jakob Schlyter have been working within the DANE working
> group at the IETF to provide for a means to alleviate some of the
> responsibility of the browser vendors as to who gets to decide what is a
> valid certificate, by allowing for that burden to be shifted to the
> subject through the use of secure DNS.  A list of hashes is published in
> the subject's domain indicating what are valid certificates.  And so if
> a CA went rogue, the subject domains would be able to indicate to the
> browser that something is afoot.  For more information, please see
> http://datatracker.ietf.org/wg/dane/.
>
> Eliot
>
> On 9/12/11 7:22 AM, Hank Nussbacher wrote:
> > At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
> >> Damian Menscher wrote on 2011-09-11:
> >>
> >> > Because of that lost trust, any cross-signed cert would likely be
> >> > revoked by the browsers.  It would also make the browser vendors
> >> > question whether the signing CA is worthy of their trust.
> >>
> >> And therein is the root of the problem:  Trustworthiness is assessed
> >> by what you refer to as the "browser vendors".  Unfortunately, there
> >> is no Trustworthiness assessment of those vendors.
> >>
> >> The current system provides no more authentication or confidentiality
> >> than if everyone simply used self-signed certificates.  It is nothing
> >> more than theatre and provides no actual security benefit
> >> whatsoever.  Anyone believing otherwise is operating under a delusion.
> >
> > The problem is about lack of pen-testing and a philosphy of security.
> > In order to run a CA, one not only has to build the infrastructure but
> > also have constant external pen-testing and patch management in
> > place.  Whether it be Comodo or RSA or now Diginotar, unless an
> > overwhelming philosphy of "computer and network security" is
> > paradigmed into the corporate DNA, this will keep happening - and not
> > only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read -
> > APT attacks).
> >
> > If 60% of your employees will plug in a USB drive they find in the
> > parking lot, then you have failed:
> >
> http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-shows-nothing-prevents-idiocy.html
> >
> >
> > The problem for us as a community if to find a benchmark of which
> > company "does have a clue" vs those that don't.  Until then, it will
> > just be whack-a-mole/CA.
> >
> > -Hank
> >
> >
> >
> >
> >
> >
> >> --- Keith Medcalf
> >> ()  ascii ribbon campaign against html e-mail
> >> /\  www.asciiribbon.org
> >
> >
> >
>
>

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Christopher J. Pilkington]

On Sep 11, 2011, at 11:06 PM, Hughes, Scott GRE-MG wrote:

> Companies that wrap their services with generic domain names (paymybills.com 
> and the like) have no one to blame but themselves when they are targeted by 
> scammers and phishing schemes. Even EV certificates don't help when consumers 
> are blinded by subsidiary companies and sister companies daily (Motorola 
> Mobility a.k.a. Google vs. Motorola Solutions.)


GE Money Bank is notorious for this… from a retail store's main page they 
redirect you to https://www3.onlinecreditcenter6.com.  (No-EV certificate, 
either.)

-cjp

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Martin Millnert]

Steinar,

On Sun, Sep 11, 2011 at 8:12 PM,   wrote:
>> To pop up the stack a bit it's the fact that an organization willing to
>> behave in that fashion was in my list of CA certs in the first place.
>> Yes they're blackballed now, better late than never I suppose. What does
>> that say about the potential for other CAs to behave in such a fashion?
>
> I'd say we have every reason to believe that something similar *will*
> happen again :-(

Something similar, including use of purchased (not only limited to
stolen certs), is ongoing already, all of the time.  (I had a fellow
IRC-chat-friend report from a certain very western-allied middle
eastern country that there's ISP/state-scale SSL-MITM ongoing there,
for all https traffic.)

The comment on starting out with an empty /etc/ssl is valid.  Most of
the normally included CA's you almost never run into on the wild web
anyway. There were some blog postings about this last time a CA was
busted. Shave off 90% of them and you have at least come a bit on the
way (goal 100%).

The absence of proof is *not* proof of absence, and in this particular
case it's pretty safe to assume some abuse is ongoing somewhere, 24/7.

Cheers,
Martin

Re: Re: EV SSL Certs

[Cody Rose]

On Monday, September 12, 2011 12:08:56 PM Coy Hile wrote:
> > On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow
> > 
> >  wrote:
> >> what's the real benefit of an EV cert? (to the service owner, not the
> >> CA, the CA benefit is pretty clearly $$)
> > 
> > The benefit is to the end user.
> > They see a green address bar  with the company's name displayed.
> > 
> > Yeah, company's name displayed -- individuals cannot apply for EVSSL
> > certs.
> > 
> > 
> > With normal certs, the end user doesn't see a green address bar, and
> > instead of the company's
> > name displayed "(unknown)" is displayed and
> > "This web site does not supply ownership information."  is displayed.
> > 
> > If you ask me, hiding the company's name even when present on a
> > non-EVSSL
> > cert is tantamount to saying  "Only EV-SSL certs are really trusted
> > anyways".
> > 
> > So maybe  instead of these shenanigans browser makers should have just
> > started displaying a "don't trust this site" warning for any non-EVSSL
> > cert.
> As an academic aside, exactly what would one set on his (internal)
> root CA so that internally-trusted certs signed by that CA would show
> up as EV certs?

The certificate would need a authority specific OID included in the extension 
field and you would have to modify the browser to acknowledge the OID as 
legitmate.

Regards,
 
Cody Rose
NOC & Sys Admin 


signature.asc
Description: This is a digitally signed message part.

RE: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Leigh Porter]

> -Original Message-
> From: Gregory Edigarov [mailto:g...@bestnet.kharkov.ua]
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...
> Well, I do not even see how can one trust any certificate that is
> issued by commercial organization.
> 

There should be a government body to issue certificates then ;-)

But Gregory is right, you cannot really trust anybody completely. Even the 
larger and more respectable commercial organisations will be unable to resist 
 when they ask for dodgy certs so they can 
intercept something..

No, as soon as you have somebody who is not yourself in control without any 
third party verifiably independent oversight then you have to carefully define 
what you mean by trust.

--
Leigh Porter


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: EV SSL Certs

[Coy Hile]

>
> On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow
>  wrote:
>
>> what's the real benefit of an EV cert? (to the service owner, not the
>> CA, the CA benefit is pretty clearly $$)
>
> The benefit is to the end user.
> They see a green address bar  with the company's name displayed.
>
> Yeah, company's name displayed -- individuals cannot apply for EVSSL certs.
>
>
> With normal certs, the end user doesn't see a green address bar, and
> instead of the company's
> name displayed "(unknown)" is displayed and
> "This web site does not supply ownership information."  is displayed.
>
> If you ask me, hiding the company's name even when present on a non-EVSSL
> cert is tantamount to saying  "Only EV-SSL certs are really trusted anyways".
>
> So maybe  instead of these shenanigans browser makers should have just
> started displaying a "don't trust this site" warning for any non-EVSSL cert.
>

As an academic aside, exactly what would one set on his (internal)
root CA so that internally-trusted certs signed by that CA would show
up as EV certs?

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[Joe Greco]

> > I think that it's hard to cope with SSL.  It doesn't do the right things
> > for the right reasons.  Many of us, for example, operate local root CA's
> > for signing of "internal" stuff; all our company gear trusts our local
> > root CA and lots of stuff has certs issued by it.  In an ideal world,
> > this would mean that our gear talking to our gear is always secure, but
> > with other root CA's able to offer certs for our CN's, that isn't really
> > true.  That's frustrating.
> 
> You don't have to have the big fat Mozilla root cert bundle on your
> machines.  Some OSes "ship" with an empty /etc/ssl, nobody tells you who
> you trust.

You don't have to have a web browser on your machines, either.  Also
solves the problem FSVO "solves."

Users don't really want to figure out SSL, and we shouldn't *want* them
to have to figure out SSL.  When your grandfolks (or parents or whatever)
connect up to the Internet with a PC, they just sort of expect that things
will work.  We should have found a way to make that happen - instead we
gave them SSL.  :-)

> > The reality is that - for the average user -  SSL doesn't work well 
> > unless about 99% of the CA's used by the general public are included 
> > as "trusted."  If a popular site like Blooble has a cert by DigiNotar
> > and the Firerox browser is constantly asking what to do, nothing really
> > good comes out of that ...  either people think Firerox blows, or they
> > learn to click on the "ignore this" (or worse the "always trust this")
> > button.  In about 0.0% of the cases do they actually understand the
> > underlying trust issues.  So there's a great amount of pressure to
> > just make it magically work.
> 
> How about a TXT record with the CN string of the CA cert subject in it?
> If it exists and there's a conflict, don't trust it.  Seems simple
> enough to implement without too much collateral damage.

I don't know.  It may have some potential.

> > However, as the number of CA's accepted in most browsers increases, 
> > the security of the system as a whole decreases dramatically.  Yet
> > the market for $1000/year SSL certs is rather low, and the guys that
> > are charging bargain rates for low quality certs are perhaps doing
> > one good thing (enabling encryption) while simultaneously doing another
> > bad thing (destroying any "quality" in the system).  SSL is going to
> > have these problems as long as we maintain the current model.
> 
> I like the added "chrome" that the new browsers have for EV certs, but
> users need to be stabbed in the face, green vs. blue doesn't really do
> it.

Perhaps what we need is to stab some Internet folks in the face too,
though, for allowing the perpetuation of Much Badness(tm).  We might
really be better off, for example, if we could get a ".bank" TLD that
was operated in a rational manner, where only the bank's proper name
was registered, all websites had to run as subdomains, and SSL certs
for .bank could only be issued by ... well maybe even just one CA, or
at most two or three.

I mean, there's still so much wrong with that model too, but it has
some more-correct things built into it.

> > In the long run, I expect all the CA's to behave something like this -
> > especially the ones that have more to lose if they were to become
> > suddenly "untrustworthy." 
> 
> Yes, how do you think Verisign/Thawte/Symantec would behave if they
> found that their keys were compromised?  They might do the right thing,
> because they're not stupid enough to think they could get away with
> trying to cover it up. 

Wow, you're ... pleasantly naive? (not meant as an insult AT ALL!)  Or 
maybe I'm just hopelessly cynical.  But I do see that as naive; I expect
that at a minimum the spin machine would be running at full tilt and
it would be downplayed as much as possible.

> What would the browser vendors do in that case?

Interesting question.

> I hope there's a contingency plan, and if there is it seems like it
> should be made public.

Okay.  :-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Martin Millnert]

Gregory,

On Mon, Sep 12, 2011 at 1:23 PM, Gregory Edigarov
 wrote:
> On Mon, 12 Sep 2011 12:12:08 +0200
> Martin Millnert  wrote:
>
>> Mike,
>>
>> On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones  wrote:
>> > It will take a while to get updated browsers rolled out to enough
>> > users for it do be practical to start using DNS based self-signed
>> > certificated instead of CA-Signed certificates, so why don't any
>> > browsers have support yet? are any of them working on it?
>>
>> Chrome v 14 works with DNS stapled certificates, sort of a hack. (
>> http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
>>
>> There are other proposals/ideas out there, completely different to
>> DANE / DNSSEC, like http://perspectives-project.org/ /
>> http://convergence.io/ .
>
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...
> Well, I do not even see how can one trust any certificate that is
> issued by commercial organization.


As I understand it the idea is that you would have the
power/capability to assign trust yourself to friends, CAs and your
cat.  This then forms some form of (washed out word-warning) web of
trust, when you connect up with others and get their
one-step-away-trust imported.


Outsourcing trust is a pretty hard problem... there's no way to get
around it, really, so this approach (as per my limited research) at
least gives you some power to control it.

Regards,
Martin

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Gregory Edigarov]

On Mon, 12 Sep 2011 12:12:08 +0200
Martin Millnert  wrote:

> Mike,
> 
> On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones  wrote:
> > It will take a while to get updated browsers rolled out to enough
> > users for it do be practical to start using DNS based self-signed
> > certificated instead of CA-Signed certificates, so why don't any
> > browsers have support yet? are any of them working on it?
> 
> Chrome v 14 works with DNS stapled certificates, sort of a hack. (
> http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
> 
> There are other proposals/ideas out there, completely different to
> DANE / DNSSEC, like http://perspectives-project.org/ /
> http://convergence.io/ .

I.e. instead of a set of trusted CAs there will be one distributed net
of servers, that act as a cert storage?
I do not see how that could help...
Well, I do not even see how can one trust any certificate that is
issued by commercial organization. 


-- 
With best regards,
Gregory Edigarov

Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)

[Martin Millnert]

Mike,

On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones  wrote:
> It will take a while to get updated browsers rolled out to enough
> users for it do be practical to start using DNS based self-signed
> certificated instead of CA-Signed certificates, so why don't any
> browsers have support yet? are any of them working on it?

Chrome v 14 works with DNS stapled certificates, sort of a hack. (
http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )

There are other proposals/ideas out there, completely different to
DANE / DNSSEC, like http://perspectives-project.org/ /
http://convergence.io/ .

Regard,
Martin

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[fredrik danerklint]

> > How about a TXT record with the CN string of the CA cert subject in it?
> > If it exists and there's a conflict, don't trust it.  Seems simple
> > enough to implement without too much collateral damage.
> 
> Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> to attacks via DNS poisoning (either insert a malicious TXT that matches
> your malicious certificate, or insert a malicious TXT that intentionally
> *doesn't* match the vicitm's certificate)

And how do you validate the dnssec to make sure that noone has tampered with 
it.

-- 
//fredan

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Eliot Lear]

Hank and everyone,

This is a very interesting problem.  As it happens, some folks in the
IETF have anticipated this one.  For those who are interested, Paul
Hoffman and Jakob Schlyter have been working within the DANE working
group at the IETF to provide for a means to alleviate some of the
responsibility of the browser vendors as to who gets to decide what is a
valid certificate, by allowing for that burden to be shifted to the
subject through the use of secure DNS.  A list of hashes is published in
the subject's domain indicating what are valid certificates.  And so if
a CA went rogue, the subject domains would be able to indicate to the
browser that something is afoot.  For more information, please see
http://datatracker.ietf.org/wg/dane/.

Eliot

On 9/12/11 7:22 AM, Hank Nussbacher wrote:
> At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
>> Damian Menscher wrote on 2011-09-11:
>>
>> > Because of that lost trust, any cross-signed cert would likely be
>> > revoked by the browsers.  It would also make the browser vendors
>> > question whether the signing CA is worthy of their trust.
>>
>> And therein is the root of the problem:  Trustworthiness is assessed
>> by what you refer to as the "browser vendors".  Unfortunately, there
>> is no Trustworthiness assessment of those vendors.
>>
>> The current system provides no more authentication or confidentiality
>> than if everyone simply used self-signed certificates.  It is nothing
>> more than theatre and provides no actual security benefit
>> whatsoever.  Anyone believing otherwise is operating under a delusion.
>
> The problem is about lack of pen-testing and a philosphy of security. 
> In order to run a CA, one not only has to build the infrastructure but
> also have constant external pen-testing and patch management in
> place.  Whether it be Comodo or RSA or now Diginotar, unless an
> overwhelming philosphy of "computer and network security" is
> paradigmed into the corporate DNA, this will keep happening - and not
> only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read -
> APT attacks).
>
> If 60% of your employees will plug in a USB drive they find in the
> parking lot, then you have failed:
> http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-shows-nothing-prevents-idiocy.html
>
>
> The problem for us as a community if to find a benchmark of which
> company "does have a clue" vs those that don't.  Until then, it will
> just be whack-a-mole/CA.
>
> -Hank
>
>
>
>
>
>
>> --- Keith Medcalf
>> ()  ascii ribbon campaign against html e-mail
>> /\  www.asciiribbon.org
>
>
>

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Valdis . Kletnieks]

On Sun, 11 Sep 2011 22:01:47 EDT, Christopher Morrow said:
> If I have a thawte cert for valdis.com on host A and one from comodo
> on host B... which is the right one?

You wouldn't have 2 certs for that... I'd have *one* cert for that. And if when
you got to the IP address you were trying to reach, the cert didn't validate as
matching the hostname, you know something fishy is up.

And if you *do* have two certs for it, I'd like to talk to the bozos at
Thawte and Comodo who obviously didn't check the paperwork. ;)





pgp8spbP9GxtJ.pgp
Description: PGP signature

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[Valdis . Kletnieks]

On Mon, 12 Sep 2011 04:39:52 -, Marcus Reid said:

> You don't have to have the big fat Mozilla root cert bundle on your
> machines.  Some OSes "ship" with an empty /etc/ssl, nobody tells you who
> you trust.

And for those OS's (who are they, anyhow) that ship empty bundles,
how many CAs do you end up trusting anyhow?

> How about a TXT record with the CN string of the CA cert subject in it?
> If it exists and there's a conflict, don't trust it.  Seems simple
> enough to implement without too much collateral damage.

Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
to attacks via DNS poisoning (either insert a malicious TXT that matches your
malicious certificate, or insert a malicious TXT that intentionally *doesn't* 
match
the vicitm's certificate)


pgpNi8okd9oAi.pgp
Description: PGP signature