I will also say that this is another reason why not to set desktop expectations on ARM devices given a chance to reset. Why offer major upgrades via retail at all rather than only with purchase of new devices. Now *there* is a way to really win over manufacturers. Android already exhibits this behavior to a large extent with locked down devices, so this may be a lost cause no matter how they position it.
Microsoft's success with end-users is almost entirely predicated on compatibility for third party software. Windows for ARM would not be able to execute Windows for x86 code in any reasonable way. MS would want to have stringent licensing restrictions at significant cost while Google just doesn't care or have reason to care and will let OEMs do what they will. For end-users, no benefit is available from Windows, for manufacturers, the software is an expense that is not recoverable via crapware preloads like in x86 world.
Of course, MS could have an advantage with the device manufacturers here, but only if it is willing to nearly give away the OS for free to manufacturers. A *large* part of the consumer electronics experience is governed by the software. A software update can give a customer everything they wanted in a new device without buying a new device. If the software is consumer friendly and let's the user update to latest edition for free, many will opt to do so instead of buying a new device, to the chagrin of the manufacturers who want to move more volume. Meanwhile, if MS offers an OS that would cost $100 to update and the cost of a new device (including the update they wanted) is $200, a lot of customers will just go ahead and get a new device, giving a bump for the market. For manufacturers to get the numbers so close MS would have to take away a relatively small revenue amount per purchase. Essentially amounts to colluding with manufacturers to screw the consumer over by artificially keeping retail prices up and precluding any other inexpensive path to updates. Microsoft surely would never do such a thing...
Oh and finally, chasing Google's tail on this is the wrong way to do it anyway. Google's ChromeOS *and* android is a mistake, and MS probably would do better by having a converged phone+netbook+tablet platform instead of trying to copy over the desktop platform and suffer odd overlap between their 'phone' and 'desktop' platform on smallish arm systems.
I'll take the latter. Honestly though, I forgot about that aspect, but at least *now* I really dislike Tectia SSH Windows client compared to PuTTY even if both were free.
I really was only thinking of the use of it on Unix and Linux systems. I know companies uninstalling OpenSSH from RedHat and doing Tectia, which I cannot begin to fathom.
I'm hoping this will be the impetus for the forks to abandon all pretense of interoperability with NoMachine's crap session management and do it right.
SSH lives on as Tectia and still has quite the revenue stream selling to companies that presume it's more secure because they have to pay for it. Commercial SSH has always just pretty much been for suckers and continues to be, the open source aspect being pretty well a moot point.
Well, not always the mac address, stateless addressing without privacy will generally do that, but you can still arbitrarily manage your host portion as you wish like you do with ipv4 today.
Specifically, the core tech isn't too shabby. Their session management stuff with awkward use of ssh keys and a separate user on top of the user's real account, a real awkward mess. I use a complete separate management of nxagent/nxproxy that doesn't use any extraneous user and it's nice.
The real shame is their strategy seemed to be oriented around selling their crappy session management stuff and giving away the quality stuff.
If ssh used DNSSEC to update the known hosts file without asking the user for confirmation, it would be a significant drop in security
Depends. In some environments, measures are taken to alleviate the problem of ssh requiring to go interactive to deal with key updates (can be induced by reinstalls or by things like fixing the debian host key generation problem a while back). Those measures frequently either compromise the secrecy of the host keys or provide known_hosts via a shared filesystem strategy that is likely to be less than secure. If DNSSEC works perfectly (i.e. data cryptographically validated on the local host), then it may displace some insecure workarounds commonly in place.
Nice, I didn't know about RFC 4255 before now. This is the kind of thing I had in mind, I didn't know it already existed.
Yes, already implemented in current OpenSSH. Been playing with it and it will provide enhanced trust if AD flag is set, so it won't help for locally authoritative data. I haven't tried it, but have been wanting to play with https://www.dnssec-tools.org/wiki/index.php/Ssh. I've been getting on a soapbox in the hopes some OpenSSH developer will take note of that.
I'd not trust it as an alternative to known hosts, but as a supplement it sounds like a good idea.
I'll admit that perhaps it shouldn't be by default, but it should be an option for places that torture the ssh config today in worse ways in order to simplify ssh administration at the cost of security.
With NAT64, an IPv6 only host can reasonably initiate connections to IPv4 servers. While guaranteeing a server may be reached by everyone still requires IPv4, mostly-client-only hosts can be IPv6 and enjoy the benefit of being on a true peer-to-peer capable network with respect to other entities doing IPv6.
Just take a look at the hair-pulling in mixed IPv4 and 6 networks with things like Windows Server
I have that set up, there really isn't anything special to it, my hair is intact.
weenies decided that we should be 'saved' from all of the mistakes of IPv4.
I kind of have to agree with you in part, they really really seemed reluctant to discuss NAT64 which should have been part of the conversation from the beginning. Also, they have mucked with a lot of other related technologies setting things back a long way, particularly DHCP. Standards are just now getting close to parity for most use cases in theory, though many established best practices still won't work as-is.
Your points 1 and 2 may continue to apply for servers seeking for universal exposure in the interim.
Point 3 would be a given *if* IPv6 can't happen (I finally think it can happen for most participants.
For point 4, carrier grade NAT I will only find acceptable if it is NAT64. If you advocate a world where a house has no public IPv4 address anyway, why not give the house IPv6 addresses and use NAT64 to get to the rest of the world? The ISP doesn't have to spare a rare IPv4 and the house still gets a 'real' address that allows similar residences to direct connect (for things like swarm downloading and gaming).
For ppoint 5, just... no. We are closer to having IPv6 as a usable solution than some awful hack like having the browser using SRV records for fully identifying a server location.
IT and computing people need to voice their workflows that still don't work and get through it so we have a sane IPv6 internet instead of a horribly broken IPv4 network.
Maybe I'm just seeing the parts of the debates I want, but it seems the sentiment at least in NANOG is maybe down to/56 or maybe even/60, but not to/64 even for residential. The reason being that if routers for example wanted to make the wireless and wired two segments, then a/64 would be impractical. Today those are generally bridged networks, but that's only an example of the notion that even a house may have need/desire of routing. You should only do a/64 if you are managing the specific details and know that is truly an endpoint. Even in the case of a residential customer, you are not administering their internal topology, but delegating it to them/their router vendor.
I do not want allocation to be so overly stingy that I can't split my allocation into multiple segments without breaking the rules of reasonable IPv6 allocation, so I'm really against the notion than/64 for a residence is fine.
Though things aren't likely to exhaust any time soon, that's a fairly naive perspective on it.
2^121 addresses are knocked out by ULAs, 2^118 knocked out by link-local addressing, 2^120 are only available for multicast. In aggregate, a small chunk, but sizable.
Then, there is the inefficiency of distribution. Nothing smaller than/64 is ever supposed to be given to any single network segment. Currently, nothing smaller than a/48 is supposed to be given to an entity allowed to do routing (e.g. houses), though some have proposed allowing/56. Just like some places have 16.7 million IP addresses that don't need them, similar inefficient allocations will be made in IPv6 world.
In order to do a competent assessment, a more complex projection is required.
Anybody who could do that could probably pull off the same hijacking without spoofing a DNS record
Only if the protocol is crappy. Sure, telnet, http without SSL and friends would be vulnerable, but https and ssh would not be directly attackable in this way. If SSH however uses DNSSEC assurance as a trusted way of updating known_hosts, it becomes a vector for man in the middle.
The real case for ssh using DNSSEC would actually be if host keys could be put in DNS as well. However it is unclear to me if that would be anymore secure or easier to maintain than a known hosts file.
Guess I should say that is SPECIFICALLY what I am talking about. SSHFP records are fingerprints of host public keys. *If* DNSSEC were implemented in a way where validity is assured by the local system, then known_hosts isn't needed, validity is assured via a chain of trust, and people don't blindly accept new keys for lack of convenient alternatives.
The notable issue being things like SSHFP, where the application must know how secure it is to provide reasonable treatment. If the result is not thoroughly validated in a way that is impervious to hijack, then ssh can treat that as an authoritative source wherease without that guarantee, it's nothing more than a hint.
Admittedly, if things were perfect, then the resolver returning anything always guarantees that the result was validated *on your machine specifically*. But we have this partial implementation where an application has no idea how much assurance backs the data unless it digs into things deeper.
I understand, but OpenSSH right now only does anything *particularly* interesting wrt SSHFP records and DNSSEC by checking the AD flag in the response from the nearest nameserver instead of doing the cryptographic validation itself, leaving a hole open as well as making it awkward when your nearest nameserver is authoritative for the SSHFP record of interest.
I'm not sure if DNS is fundamentally better than x509. I'm not sure compromised DNSSEC keys would be any more obvious than compromised CA keys. I think before x509 was defined, that DNSSEC would have had a whole lot of value. I think for applications that by and large ignore x509 (e.g. OpenSSH) there is an opportunity, but only because they ignored an existing approach.
I say that because people make too big a deal of the differences between interpreted languages. I have done python extensively. Admittedly, I've only spot checked ruby code. Preferences are a matter of subjective taste and not so much slam-dunk, absolutely better. I will admit I have a hard time imagining anyone preferring perl's XS strategy for writing perl bindings to C/C++ API to python's, but I'm hard pressed to think of another area where perl cannot be used to the same effect as python without undue difficulty.
If those DNS servers implement DNSSEC and check records properly, all the computers on the network get the basic benefit of non-forgeable DNS records (if the signatures don't verify, the local DNS servers will return an error to the client).
One thing I never quite got. While DNSSEC is not ubiquitous, if someone hijacks some part of it in a way that DNSSEC would protect against in theory, what stops them from skipping all the DNSSEC stuff they can't fake. The resolvers will drop incorrect DNSSEC data, but will accept records with no DNSSEC, and just not set AD flag that most things don't care about (and really can't know whether to care or not).
The best I can suggest off hand would be ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf and other things linked from http://www.isc.org/software/bind/dnssec. That one presumes 9.7 which means they got to skip a lot of the nastiness other commonly referenced guides go over. I don't think I've seen a guide that doesn't present it as more complicated than it is, but that isn't too bad.
That all assumes ISC bind, and I particularly recommend BIND 9.7 or newer as a starting point (it had some *major* simplifications on DNSSEC).
Want federated authentication in OpenSSH that actually scales?
Is OpenSSH actually going to do crypto-verification or are you advocating the current mess where it just checks AD flag and nothing more?
Want servers able to autogenerate TLS keys that will be recognized and secured worldwide, even against broken certificate authorities?
It really just replaces one web of trust with another. Replace broken certificate authorities with broken DNS key anywhere between your domain and root.
Want secure email, without the mess that is PGP key management?
Sure, PGP key management is all sorts of fubar for establishing trust. x509 certs would be fine here. The obvious issue is that the accepted x509 CAs frequently charge a bit and the dream is that DNSSEC will provide equally quality protection without your parent domain charging you to establish the trust relationship. I wonder if that will happen in practice, it's too much of an unknown right now. I'll predict that ultimately, either parent domains will be too fast and loose about getting the trust relationship going compared to current CAs, or else those parent domains will charge probably an equivalent 'processing fee' to cover their costs of validation. Also, there is a presumption here that all applications will do the right thing. SSH could have done x509 instead of known_hosts but they *chose* to do their own thing, I suspect that will continue to be the case, that the DNS web of trust will be as likely to be ignored as the x509 web of trust. The optimal thing could happen, but I'm skeptical that DNSSEC will really offer anything new/better than x509 certificates today once the dust clears.
The problem for *any* web oriented 'benefit' of DNSSEC is if the client is in a position where DNSSEC would help, they are already in trouble. If they don't assure the browser is talking securely (SSL) to the peer with the existing mechanisms to show the user, then they are hosed no matter what you do. If they are a customer that does check, DNSSEC doesn't validate things any more than the x509 certificate the server has. It's an alternative, redundant validation of DNS data now.
So yes, you can build a DNSSEC island and have that island internally consistent. However, some things about how DNSSEC is done bug me that make me question its value:
-Applications are generally not cryptographically validating the DNS response, they simply check the AD flag. This means that anyone able to spoof their way between you and your nameserver can *still* compromise DNS. This is better than the current state of things which is subject to shenanigans in a much wider scope, but still.
-When certain applications that are particularly careful about checking the AD flag, you are unable to trigger their 'secure' features on records for which you are authoritative, because the AD flag will not be set for local records. I'm looking at OpenSSH particularly hard here.
Now if you push things so that the software does cryptographic validation (like in SSL), it becomes very very hard to maintain a private infrastructure without full path protection to the root zone because you have to push all your islands key data to applications. DNSSEC would be great if it was there from the beginning. Part of SSL addressed dubious DNS results and now with DNSSEC, there is a bit of redundancy in practice for the common cases of DNS hijacking. I really really wished SSH had used x509 as the framework for their public-private keys instead of doing their own thing, ssh is probably the application that has the most to gain from DNSSEC and that isn't enough for most things to care.
Perl's biggest problem in new developer 'recruitment' is a world that is obsessed with concepts of 'new is better'. This is at least the case in academia and discussion places like slashdot. In industry, I find many hands-off architects that never touch code and have next to no ongoing commitment to any particular project push hard for starting or converting to Python or Ruby (the latter is only ever mentioned with 'on Rails' at the end by these guys, even if having nothing to do with the web for some particularly clueless people). In practice, the people dealing with where the rubber meets the road most often go with perl of the scripting languages. The reason is simple, it is sufficient, relatively unchanging, and well-known. I'd rather have an 'odd' language that doesn't change it's mind about things than a language striving to be 'clean' and deprecating things left and right when people decide there is a 'cleaner' way of doing it (mainly some experiences with python projects coping with 2.x series changes over time, though admittedly going from using a project pre-adoption into python core to having that project pulled in and changed).
When it comes down to it, currently used interpreted languages are alive for a reason and generally you can choose any one you like and get to the goal without too much difficulty. Python, Perl, Ruby, even Powershell (as of 2k8r2 and 7) represent pretty capable languages to write in. Personal preference and available experience outweigh the technical differences in my opinion.
Well, you can, but it's optional (like a lot of perl). I actually like one aspect of an argument list that is more obviously nothing more than an open ended stack, it gets developers to think more open ended about arguments they can receive. In C, it's a relative pain, you must know the number of arguments you need. If you treat it as simple arguments being passed in, it's extremely static. If you are going to accept arbitrary number of parameters, you need the caller to tell you how deep the stack is rather than being able to tell implicitly.
object oriented features are stuck on with duct tape
When you get deep into it, this is probably still a fair criticism. However, an interesting side effect is that the well equipped programmer becomes more cognizant of the structure of things and is not confined by arbitrary simplifications in the name of ease-of-use. Of course, a good programmer will exercise self-restraint and make things comprehensible to others.
you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different sidgils
Most languages have something like that, a feature that is not required that isn't obvious at first blush. In my case, I avoid those operations in favor of more readable code. For example, 'my $arrlength = @array;' is something I avoid in favor of the more explicit and obvious 'my $arrlength = scalar(@array);'. They are exactly the same, but the sidgils may get overlooked in the first example. I suppose you'll say 'scalar' does not eliminate the need to have a 'deep understanding', I would say that it isn't a particularly deep bit of knowledge to know that arrays assigned to a simple variable is doing the length. deep knowledge is trying to write XS code or use gdb to debug perl at the level of C.
huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.
True enough there, but many are unused and again, from a style perspective, I avoid many of them (like $_ in particular).
I've read a few articles saying the problem is the government granting exceptional protections to lenders in college loans. This may be viewed as a somewhat indirect subsidy, but a direct subsidy would probably incite fewer shenanigans between lenders and universities that amount to collusion to raise prises.
Of course, the simple fact that culturally a longer than 4-year term at one college with some reputation is perceived as simply mandatory for success. This includes a good couple of years of generic filler courses that are in no way specific to your field and in many cases will never apply to your professional life.
When it comes to the obscenely successful, I think generally education doesn't make much of a difference one way or another. Luck is the critical component, and beyond that sufficient capability developed well before college graduation to take advantage of that luck. With a sufficiently large population of dropouts, you will have those few special cases of millionaires, just like you have a few coming out of college. In this case, a drop-out credits the act of dropping out as an impetus of his success, just as some graduates in the same position view their graduation as the critical factor. In both cases they are wrong and it's mostly a case of being in the right place at the right time with the right capabilities and the nearly arbitrary point of acquiring the degree usually has nothing to do with it.
Now in the more realistic case for everyone, the degree is critical. 99% of people won't be a bigshot leader of highly sucessful businesses no matter how you slice it and the vast majority of people will have to settle for coming in as a faceless resource and not receiving an in depth examination of qualification unless a degree prerequisite is met. While the exceptionally lucky show equal or better success than the lucky graduates, there are many many more drop-outs with dead-end jobs.
Slashdot Mirror
I will also say that this is another reason why not to set desktop expectations on ARM devices given a chance to reset. Why offer major upgrades via retail at all rather than only with purchase of new devices. Now *there* is a way to really win over manufacturers. Android already exhibits this behavior to a large extent with locked down devices, so this may be a lost cause no matter how they position it.
Microsoft's success with end-users is almost entirely predicated on compatibility for third party software. Windows for ARM would not be able to execute Windows for x86 code in any reasonable way. MS would want to have stringent licensing restrictions at significant cost while Google just doesn't care or have reason to care and will let OEMs do what they will. For end-users, no benefit is available from Windows, for manufacturers, the software is an expense that is not recoverable via crapware preloads like in x86 world.
Of course, MS could have an advantage with the device manufacturers here, but only if it is willing to nearly give away the OS for free to manufacturers. A *large* part of the consumer electronics experience is governed by the software. A software update can give a customer everything they wanted in a new device without buying a new device. If the software is consumer friendly and let's the user update to latest edition for free, many will opt to do so instead of buying a new device, to the chagrin of the manufacturers who want to move more volume. Meanwhile, if MS offers an OS that would cost $100 to update and the cost of a new device (including the update they wanted) is $200, a lot of customers will just go ahead and get a new device, giving a bump for the market. For manufacturers to get the numbers so close MS would have to take away a relatively small revenue amount per purchase. Essentially amounts to colluding with manufacturers to screw the consumer over by artificially keeping retail prices up and precluding any other inexpensive path to updates. Microsoft surely would never do such a thing...
Oh and finally, chasing Google's tail on this is the wrong way to do it anyway. Google's ChromeOS *and* android is a mistake, and MS probably would do better by having a converged phone+netbook+tablet platform instead of trying to copy over the desktop platform and suffer odd overlap between their 'phone' and 'desktop' platform on smallish arm systems.
I'll take the latter. Honestly though, I forgot about that aspect, but at least *now* I really dislike Tectia SSH Windows client compared to PuTTY even if both were free.
I really was only thinking of the use of it on Unix and Linux systems. I know companies uninstalling OpenSSH from RedHat and doing Tectia, which I cannot begin to fathom.
I'm hoping this will be the impetus for the forks to abandon all pretense of interoperability with NoMachine's crap session management and do it right.
SSH lives on as Tectia and still has quite the revenue stream selling to companies that presume it's more secure because they have to pay for it. Commercial SSH has always just pretty much been for suckers and continues to be, the open source aspect being pretty well a moot point.
Well, not always the mac address, stateless addressing without privacy will generally do that, but you can still arbitrarily manage your host portion as you wish like you do with ipv4 today.
A great number of local scope standards are explicitly designed for /64 and could break if violating the less than /64 rule.
Most blatant/basic example is the concatenation of advertised routing prefixes and EUI-64 for stateless addressing.
Specifically, the core tech isn't too shabby. Their session management stuff with awkward use of ssh keys and a separate user on top of the user's real account, a real awkward mess. I use a complete separate management of nxagent/nxproxy that doesn't use any extraneous user and it's nice.
The real shame is their strategy seemed to be oriented around selling their crappy session management stuff and giving away the quality stuff.
If ssh used DNSSEC to update the known hosts file without asking the user for confirmation, it would be a significant drop in security
Depends. In some environments, measures are taken to alleviate the problem of ssh requiring to go interactive to deal with key updates (can be induced by reinstalls or by things like fixing the debian host key generation problem a while back). Those measures frequently either compromise the secrecy of the host keys or provide known_hosts via a shared filesystem strategy that is likely to be less than secure. If DNSSEC works perfectly (i.e. data cryptographically validated on the local host), then it may displace some insecure workarounds commonly in place.
Nice, I didn't know about RFC 4255 before now. This is the kind of thing I had in mind, I didn't know it already existed.
Yes, already implemented in current OpenSSH. Been playing with it and it will provide enhanced trust if AD flag is set, so it won't help for locally authoritative data. I haven't tried it, but have been wanting to play with https://www.dnssec-tools.org/wiki/index.php/Ssh. I've been getting on a soapbox in the hopes some OpenSSH developer will take note of that.
I'd not trust it as an alternative to known hosts, but as a supplement it sounds like a good idea.
I'll admit that perhaps it shouldn't be by default, but it should be an option for places that torture the ssh config today in worse ways in order to simplify ssh administration at the cost of security.
IPv6 is completely incompatible with IPv4
With NAT64, an IPv6 only host can reasonably initiate connections to IPv4 servers. While guaranteeing a server may be reached by everyone still requires IPv4, mostly-client-only hosts can be IPv6 and enjoy the benefit of being on a true peer-to-peer capable network with respect to other entities doing IPv6.
Just take a look at the hair-pulling in mixed IPv4 and 6 networks with things like Windows Server
I have that set up, there really isn't anything special to it, my hair is intact.
weenies decided that we should be 'saved' from all of the mistakes of IPv4.
I kind of have to agree with you in part, they really really seemed reluctant to discuss NAT64 which should have been part of the conversation from the beginning. Also, they have mucked with a lot of other related technologies setting things back a long way, particularly DHCP. Standards are just now getting close to parity for most use cases in theory, though many established best practices still won't work as-is.
Your points 1 and 2 may continue to apply for servers seeking for universal exposure in the interim.
Point 3 would be a given *if* IPv6 can't happen (I finally think it can happen for most participants.
For point 4, carrier grade NAT I will only find acceptable if it is NAT64. If you advocate a world where a house has no public IPv4 address anyway, why not give the house IPv6 addresses and use NAT64 to get to the rest of the world? The ISP doesn't have to spare a rare IPv4 and the house still gets a 'real' address that allows similar residences to direct connect (for things like swarm downloading and gaming).
For ppoint 5, just... no. We are closer to having IPv6 as a usable solution than some awful hack like having the browser using SRV records for fully identifying a server location.
IT and computing people need to voice their workflows that still don't work and get through it so we have a sane IPv6 internet instead of a horribly broken IPv4 network.
Houses will do just fine with /64.
Maybe I'm just seeing the parts of the debates I want, but it seems the sentiment at least in NANOG is maybe down to /56 or maybe even /60, but not to /64 even for residential. The reason being that if routers for example wanted to make the wireless and wired two segments, then a /64 would be impractical. Today those are generally bridged networks, but that's only an example of the notion that even a house may have need/desire of routing. You should only do a /64 if you are managing the specific details and know that is truly an endpoint. Even in the case of a residential customer, you are not administering their internal topology, but delegating it to them/their router vendor.
I do not want allocation to be so overly stingy that I can't split my allocation into multiple segments without breaking the rules of reasonable IPv6 allocation, so I'm really against the notion than /64 for a residence is fine.
Though things aren't likely to exhaust any time soon, that's a fairly naive perspective on it.
2^121 addresses are knocked out by ULAs, 2^118 knocked out by link-local addressing, 2^120 are only available for multicast. In aggregate, a small chunk, but sizable.
Then, there is the inefficiency of distribution. Nothing smaller than /64 is ever supposed to be given to any single network segment. Currently, nothing smaller than a /48 is supposed to be given to an entity allowed to do routing (e.g. houses), though some have proposed allowing /56. Just like some places have 16.7 million IP addresses that don't need them, similar inefficient allocations will be made in IPv6 world.
In order to do a competent assessment, a more complex projection is required.
Anybody who could do that could probably pull off the same hijacking without spoofing a DNS record
Only if the protocol is crappy. Sure, telnet, http without SSL and friends would be vulnerable, but https and ssh would not be directly attackable in this way. If SSH however uses DNSSEC assurance as a trusted way of updating known_hosts, it becomes a vector for man in the middle.
The real case for ssh using DNSSEC would actually be if host keys could be put in DNS as well. However it is unclear to me if that would be anymore secure or easier to maintain than a known hosts file.
Guess I should say that is SPECIFICALLY what I am talking about. SSHFP records are fingerprints of host public keys. *If* DNSSEC were implemented in a way where validity is assured by the local system, then known_hosts isn't needed, validity is assured via a chain of trust, and people don't blindly accept new keys for lack of convenient alternatives.
The notable issue being things like SSHFP, where the application must know how secure it is to provide reasonable treatment. If the result is not thoroughly validated in a way that is impervious to hijack, then ssh can treat that as an authoritative source wherease without that guarantee, it's nothing more than a hint.
Admittedly, if things were perfect, then the resolver returning anything always guarantees that the result was validated *on your machine specifically*. But we have this partial implementation where an application has no idea how much assurance backs the data unless it digs into things deeper.
I understand, but OpenSSH right now only does anything *particularly* interesting wrt SSHFP records and DNSSEC by checking the AD flag in the response from the nearest nameserver instead of doing the cryptographic validation itself, leaving a hole open as well as making it awkward when your nearest nameserver is authoritative for the SSHFP record of interest.
I'm not sure if DNS is fundamentally better than x509. I'm not sure compromised DNSSEC keys would be any more obvious than compromised CA keys. I think before x509 was defined, that DNSSEC would have had a whole lot of value. I think for applications that by and large ignore x509 (e.g. OpenSSH) there is an opportunity, but only because they ignored an existing approach.
I say that because people make too big a deal of the differences between interpreted languages. I have done python extensively. Admittedly, I've only spot checked ruby code. Preferences are a matter of subjective taste and not so much slam-dunk, absolutely better. I will admit I have a hard time imagining anyone preferring perl's XS strategy for writing perl bindings to C/C++ API to python's, but I'm hard pressed to think of another area where perl cannot be used to the same effect as python without undue difficulty.
If those DNS servers implement DNSSEC and check records properly, all the computers on the network get the basic benefit of non-forgeable DNS records (if the signatures don't verify, the local DNS servers will return an error to the client).
One thing I never quite got. While DNSSEC is not ubiquitous, if someone hijacks some part of it in a way that DNSSEC would protect against in theory, what stops them from skipping all the DNSSEC stuff they can't fake. The resolvers will drop incorrect DNSSEC data, but will accept records with no DNSSEC, and just not set AD flag that most things don't care about (and really can't know whether to care or not).
The best I can suggest off hand would be ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf and other things linked from http://www.isc.org/software/bind/dnssec. That one presumes 9.7 which means they got to skip a lot of the nastiness other commonly referenced guides go over. I don't think I've seen a guide that doesn't present it as more complicated than it is, but that isn't too bad.
That all assumes ISC bind, and I particularly recommend BIND 9.7 or newer as a starting point (it had some *major* simplifications on DNSSEC).
Want federated authentication in OpenSSH that actually scales?
Is OpenSSH actually going to do crypto-verification or are you advocating the current mess where it just checks AD flag and nothing more?
Want servers able to autogenerate TLS keys that will be recognized and secured worldwide, even against broken certificate authorities?
It really just replaces one web of trust with another. Replace broken certificate authorities with broken DNS key anywhere between your domain and root.
Want secure email, without the mess that is PGP key management?
Sure, PGP key management is all sorts of fubar for establishing trust. x509 certs would be fine here. The obvious issue is that the accepted x509 CAs frequently charge a bit and the dream is that DNSSEC will provide equally quality protection without your parent domain charging you to establish the trust relationship. I wonder if that will happen in practice, it's too much of an unknown right now. I'll predict that ultimately, either parent domains will be too fast and loose about getting the trust relationship going compared to current CAs, or else those parent domains will charge probably an equivalent 'processing fee' to cover their costs of validation. Also, there is a presumption here that all applications will do the right thing. SSH could have done x509 instead of known_hosts but they *chose* to do their own thing, I suspect that will continue to be the case, that the DNS web of trust will be as likely to be ignored as the x509 web of trust. The optimal thing could happen, but I'm skeptical that DNSSEC will really offer anything new/better than x509 certificates today once the dust clears.
The problem for *any* web oriented 'benefit' of DNSSEC is if the client is in a position where DNSSEC would help, they are already in trouble. If they don't assure the browser is talking securely (SSL) to the peer with the existing mechanisms to show the user, then they are hosed no matter what you do. If they are a customer that does check, DNSSEC doesn't validate things any more than the x509 certificate the server has. It's an alternative, redundant validation of DNS data now.
So yes, you can build a DNSSEC island and have that island internally consistent. However, some things about how DNSSEC is done bug me that make me question its value:
-Applications are generally not cryptographically validating the DNS response, they simply check the AD flag. This means that anyone able to spoof their way between you and your nameserver can *still* compromise DNS. This is better than the current state of things which is subject to shenanigans in a much wider scope, but still.
-When certain applications that are particularly careful about checking the AD flag, you are unable to trigger their 'secure' features on records for which you are authoritative, because the AD flag will not be set for local records. I'm looking at OpenSSH particularly hard here.
Now if you push things so that the software does cryptographic validation (like in SSL), it becomes very very hard to maintain a private infrastructure without full path protection to the root zone because you have to push all your islands key data to applications. DNSSEC would be great if it was there from the beginning. Part of SSL addressed dubious DNS results and now with DNSSEC, there is a bit of redundancy in practice for the common cases of DNS hijacking. I really really wished SSH had used x509 as the framework for their public-private keys instead of doing their own thing, ssh is probably the application that has the most to gain from DNSSEC and that isn't enough for most things to care.
Perl's biggest problem in new developer 'recruitment' is a world that is obsessed with concepts of 'new is better'. This is at least the case in academia and discussion places like slashdot. In industry, I find many hands-off architects that never touch code and have next to no ongoing commitment to any particular project push hard for starting or converting to Python or Ruby (the latter is only ever mentioned with 'on Rails' at the end by these guys, even if having nothing to do with the web for some particularly clueless people). In practice, the people dealing with where the rubber meets the road most often go with perl of the scripting languages. The reason is simple, it is sufficient, relatively unchanging, and well-known. I'd rather have an 'odd' language that doesn't change it's mind about things than a language striving to be 'clean' and deprecating things left and right when people decide there is a 'cleaner' way of doing it (mainly some experiences with python projects coping with 2.x series changes over time, though admittedly going from using a project pre-adoption into python core to having that project pulled in and changed).
When it comes down to it, currently used interpreted languages are alive for a reason and generally you can choose any one you like and get to the goal without too much difficulty. Python, Perl, Ruby, even Powershell (as of 2k8r2 and 7) represent pretty capable languages to write in. Personal preference and available experience outweigh the technical differences in my opinion.
How about no visibly defined function parameters
Well, you can, but it's optional (like a lot of perl). I actually like one aspect of an argument list that is more obviously nothing more than an open ended stack, it gets developers to think more open ended about arguments they can receive. In C, it's a relative pain, you must know the number of arguments you need. If you treat it as simple arguments being passed in, it's extremely static. If you are going to accept arbitrary number of parameters, you need the caller to tell you how deep the stack is rather than being able to tell implicitly.
object oriented features are stuck on with duct tape
When you get deep into it, this is probably still a fair criticism. However, an interesting side effect is that the well equipped programmer becomes more cognizant of the structure of things and is not confined by arbitrary simplifications in the name of ease-of-use. Of course, a good programmer will exercise self-restraint and make things comprehensible to others.
you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different sidgils
Most languages have something like that, a feature that is not required that isn't obvious at first blush. In my case, I avoid those operations in favor of more readable code. For example, 'my $arrlength = @array;' is something I avoid in favor of the more explicit and obvious 'my $arrlength = scalar(@array);'. They are exactly the same, but the sidgils may get overlooked in the first example. I suppose you'll say 'scalar' does not eliminate the need to have a 'deep understanding', I would say that it isn't a particularly deep bit of knowledge to know that arrays assigned to a simple variable is doing the length. deep knowledge is trying to write XS code or use gdb to debug perl at the level of C.
huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.
True enough there, but many are unused and again, from a style perspective, I avoid many of them (like $_ in particular).
I've read a few articles saying the problem is the government granting exceptional protections to lenders in college loans. This may be viewed as a somewhat indirect subsidy, but a direct subsidy would probably incite fewer shenanigans between lenders and universities that amount to collusion to raise prises.
Of course, the simple fact that culturally a longer than 4-year term at one college with some reputation is perceived as simply mandatory for success. This includes a good couple of years of generic filler courses that are in no way specific to your field and in many cases will never apply to your professional life.
When it comes to the obscenely successful, I think generally education doesn't make much of a difference one way or another. Luck is the critical component, and beyond that sufficient capability developed well before college graduation to take advantage of that luck. With a sufficiently large population of dropouts, you will have those few special cases of millionaires, just like you have a few coming out of college. In this case, a drop-out credits the act of dropping out as an impetus of his success, just as some graduates in the same position view their graduation as the critical factor. In both cases they are wrong and it's mostly a case of being in the right place at the right time with the right capabilities and the nearly arbitrary point of acquiring the degree usually has nothing to do with it.
Now in the more realistic case for everyone, the degree is critical. 99% of people won't be a bigshot leader of highly sucessful businesses no matter how you slice it and the vast majority of people will have to settle for coming in as a faceless resource and not receiving an in depth examination of qualification unless a degree prerequisite is met. While the exceptionally lucky show equal or better success than the lucky graduates, there are many many more drop-outs with dead-end jobs.