Slashdot Mirror

I'm wondering how much overlap there will be compared to Better-than-nothing-security.

The rfc is broken, as it assumes no one would lie in their 'MAIL FROM' field. Will you fix it for us?

The fix is called S/MIME.

I'd like to add that alek's scenario has more than one 'example domain.' The names he has chosen clearly illustrate which domain belongs to whom - mydomain.com, frienddomain.com. If he were to use example.com, and then example.net, he would need to further state what function each domain performs in the scenario, because it's not intuitive.

As the beginning of the RFC states the reserved names are To reduce the likelihood of conflict and confusion, alek's strict adherence to the RFC would run contrary to its purpose.

Besides, RFCs shouldn't be read as nerd scripture. Unless you mean to tell me IP over carrier pigeon is a valid protocol.

• example.com
• example.net
• example.org

Carrier Pigeons? Everyone needs them, especially when all our communication lines go out...

IP over Avian Carriers

It's possible that there is more to this than what I have divined from the 'uber-secret-vendor-only' disclosure but this seems to be little more than traditional cache poisoning with random-number-generator (RNG) prediction. Both of these situations have been well known and documented within the security community for a number of years.

Cache poisoning was predicted long ago by Dan Bernstein (as mentioned by a previous poster or two)[1]. (Nobody listens to me either, DJB.) The combination of this and RNG prediction was wrapped up nicely by Joe Stewart in his 2002 (I think) paper [2]. Joe used Michal Zalewski's free TCP/IP sequence number prediction software [3] to visualize random number generator attacks on DNS responses from various resolvers. The paper is well worth a look if you made it through the last sentence and are still reading this one.

Incidentally, Paul Vixie (BIND author,) posted a potential fix to this (or a surprisingly similar) problem to the Namedroppers mailing list at the end of February [4]. Time will tell whether the two events are connected.

This whole saga appears to be another case of 'marketing department run amok' but we'll have to wait for the BlackHat presentation to find out if all of this is just regurgitated previously ignored security advice.

[1] http://cr.yp.to/djbdns/dns_random.html
[2] http://www.lurhq.com/dnscache.pdf
[3] http://razor.bindview.com/publish/papers/tcpseq/vseq.tgz (currently down)
[4] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00378.html

Oh, I thought /. supported RFC 1149.

I've just been made aware of RFC 3383: http://www.ietf.org/rfc/rfc3833.txt dated August 2004.

Section 2.2 clearly discusses the "security flaw" that Kominsky "discovered" early this year.

HTML has had a tag for video, from the very beginning: anchor.

There are a few problems with using <a href="URI of video file">watch</a>.

First, no widely used specification recommends any specific Content-type for video that browsers SHOULD support. W3C tried to specify Content-type: application/ogg, but Nokia bitched. So all your users will see is "Windows cannot open this file. To open this file, Windows needs to know what program created it. Windows can go online to look it up automatically, or you can manually select from a list of programs on your computer."

In your code example, you recommend ".mpg", which commonly represents MPEG-1 video with MPEG-1 layer 2 audio. This codec isn't as space-efficient as FLV, nor does it have the vector animation capability of SWF.

An anchor link to does not allow the end user to interact with the video other than by fast-forwarding or rewinding. Even interactions comparable to DVD menus, which are straightforward to implement in something like SWF, have no counterpart.

Finally, some people who publish their video on the web want some soft security to deter people from downloading and redistributing videos and watching them out of context. SWF provides ways to obfuscate the FLV URL from casual users; <a href="URI of video file">watch</a> does not.

ah, you will never gat a goot IT guy then.
They usually follow the RFCs, like http://tools.ietf.org/html/rfc1178 "Choosing a Name for Your Computer"

I noted a similar incident a long time ago, as I pointed out once in this message which was nothing more than one organization filing for the domain name of another, (Sprint registering for the name "MCI.NET") but rather humorous in the result.

> Web applications are becoming more AJAX'y all the time, and they are not sequential at all.

AJAX is not CPU intensive. In fact, everything on the web is bound pretty much by your network connection and the load on the server. Yes, serves will benefit from lots of cores, but you, on the desktop, will not.

> Watching a video while another tab checks my Gmail is a parallel task.

With a modern video card, your video decoding is offloaded almost completely to the GPU. That is, of course, unless you are running Linux and have no specs for that... Checking Gmail requires no CPU time at all, since Gmail supports IMAP, which notifies the client when new mail is available without any need to poll. See IMAP IDLE RFC.

> Have you ever listened to a song through your computer while coding,
> running an email program, and running an instant messaging program?

Email is already idle, as explained in the above RFC. IM is pretty much the same way, waiting on the network 99.99% of the time. Your editor spends the majority of its time waiting on you. Your music is processed by the sound card, unless you are a cheapskate and use AC97 onboard crap. In fact, the only time you put any appreciable load on your CPU is when you are compiling. The compiler does benefit from multiple cores, but only to a point. 2 cores I can fill, 4 or 8 might get used with a large project. Anything more might help, but is probably not worth paying for. You need to think now and then, you know; might as well do it during the four seconds it takes to build your subproject.

> Imagine the song compressed with a new codec that is twice as
> efficient in terms of size but twice as compute intensive.

So you process half the data at half the speed? :) Can you divide?

> Imagine the email program indexing your email for efficient search,
> running algorithms to assess the email's importance to you, and
> virus checking new deliveries.

Most of us get email rather infrequently. I don't think I've ever had more than ten messages a day. But say you're Linus, and get a thousand messages per day. Each one might have a few kilobytes of text. So let's say, 10M total input. My hard disk can read 10M in 0.2s, actual indexing is a single pass through the data, and you might write 10-20k of index results. I doubt this will take more than a few seconds. You can use a PIII for that. If you do it on the fly, it will take even less time. Virus checking is a little more intensive, but if the mail program is smart enough to do it in the background, you won't notice that either.

> Imagine your code editor doing on the fly analysis of what you are coding, and making suggestions.

You mean like Visual Studio does with its API lookup dropdowns? That probably takes no CPU at all, being a database lookup. If you are thinking about AI, I'll laugh at you. It ain't happening any time soon. Anything that is happening any time soon will not be computationally expensive.

> Now that fast computers are cheap, people who never edited video or photos are doing it.

Photo editing is not CPU intensive, with the exception of filters, which can indeed be parallelized. But the performance improvement is again not something worth paying for. Filters aren't even used all that often.

> If you want a significant market besides gamers who need more cores,
> it is people making videos, especially HD videos.

Yeah, that's what we need. More idiots making fools of themselves in HD video. As if YouTube didn't teach you anything.

> And don't forget about virus writers. They need a few cores to run on as well!

Are you suggesting I support virus writers?

> Computer power keeps its steady progress higher, and we keep finding interesting things to do with it all.

I'm sorry, but I just don't see any of those interesting new things. Even video editing was around and quite usable bac

Actually, port 465 is not the correct port to use. If you maintain a mail server, you should switch it to the official SMTP submission port, 587.

http://www.ietf.org/rfc/rfc2476.txt (see section 3.1)

It's not quite what you are after, but there is something available to make servers more robust in the face of Slashdottings. RFC 2782 was published eight years ago, with previous drafts over 12 years old, but no browsers have implemented it to my knowledge. It was reported as a Mozilla bug nine years ago and remained unfixed.

Shouldn't you be using port 587 for that?

This is basically what NAT-PT (RFC 2766 http://www.ietf.org/rfc/rfc2766.txt) does. Unfortunately the IETF deprecated NAT-PT without offering a replacement, although Cisco and other vendors continue to offer the feature in their code.

Correct me if I'm wrong, but it is my understanding that IPv6 adresses are not a superset of IPv4 ones. That means, that absolutely no current internet site is reachable by IPv6.
...
IPv6 address should be a superset of IPv4 ones. (or example : 1.2.3.4 is IPv4, 1.2.3.4.5.6.7.8 would be IPvX. you type the former in IPvX, it gets padded to 1.2.3.4.0.0.0.0 and still works). I fail to understand why it isn't so.

Well, it would be hard to expect old software to be able to send and receive packets in a new format automatically--the packet header would at least require a longer address field, but probably other changes as well that will improve performance and flexibility. On the other hand, it should be possible for programs that use the new version of the networking API to communicate with machines on IPv4. And this is possible using IPv4 mapped IPv6 addresses (RFC reference).

There is only one usable/scalable QoS tag - DSCP. And it seems that finally there may be agreement on common classes, see RFC 4594 and RFC 5127.

There is only one usable/scalable QoS tag - DSCP. And it seems that finally there may be agreement on common classes, see RFC 4594 and RFC 5127.

I can see it coming already: TCP/IP over snails. A follow up to RFC-1149 A Standard for the Transmission of IP Datagrams on Avian Carriers.

Can lost packets be partially attributed to interference from RFC 1149?

1. Strong cert (RSA, 2048 bits), make sure it's also self-signed, and a subsidiary cert that is not issued by a US or SE exposed MNC. Each should sign the other. Put both in well known places, and have well known places to look for the revocation.

2. Throw away the Apache mod_ssl default SSLCipherSuite which is worse than useless. Use:

SSLCipherSuite "HIGH:MEDIUM"

and consider forcing EDH/ADH, which the line above enables but does not require from the client.

Ephemeral Diffie-Hellman has the main advantage that if ever the cert is forced open, the sessions protected ephemerally cannot be forced. Without ephemeral session key negotiation, a baddie can just record all the crypto text, and once the key is forced (rubber-hose, insider job...) the baddie can trivially get all the plaintext from the recorded sessions.

EDH/ADH is a bit CPU intensive, but the tradeoff is that AES-128 (and even AES-256) is generally faster than any of the weaker (DES based) modes.

Out-of-the-box use of SSL sadly just wastes actual power doing more computations that provide little extra security for a determined, well-funded attacker.

They should call what they are doing TLS, to avoid any confusion about support for weaknesses in SSLv3 or even any support at all for the (long obselete, and no longer secure) SSLv2.

3. Finally, they should also have someone on their sysadmin team get current with the IETF TLS wg mailing list which discussed some of these issues recently, and which is full of talented people who are able to offer useful advice on being secure against real attackers.

Get your ISP to add DNS LOC records to the DNS.

LOC records exist so that ISPs (or, at least, hostmasters, can add longitude and lattitude-based location information, either at the zone or record level.

The major players already mentioned will use LOC information as part of their mapping process.

From the DHCP RFC

"3.1 Client-server interaction - allocating a network address...

      1. The client broadcasts a DHCPDISCOVER message on its local physical subnet...
      2. Each server may respond with a DHCPOFFER message that includes an available network address..." [emphasis added]

So the server not only replied to your discover request, it offered you a choice of addresses.

Tsk. Tsk. Tsk. They should've used the RFC designed especially for this purpose instead.

http://tools.ietf.org/html/rfc2324

Sorry I gave the wrong URL. DHCP is described in RFC 2131. RFC 2132 only lists valid options. http://www.ietf.org/rfc/rfc2131.txt

The client sends a DHCPREQUEST packet that contains options it is requesting from the server. The server is then supposed to craft a DHCPACK packet containing values for the options requested by the client.

http://www.ietf.org/rfc/rfc2132.txt

Seems silly to spend all that time and money trying to get the FCC to change its regulations when this situation seems tailor made for a good RFC 1149 implementation. Latency is still an issue with such a setup, but bandwidth can be virtually unlimited if you have the resources.

Finally, we will get an application to correctly implement rfc 3514 for "The Security Flag in the IPv4 Header".

Server Name Identification in RFC 3546 is supposed to help with this, if it ever gets adopted.

NAK is negative acknowledgment, which means that the sender recognized that it received an incorrect packet / missed a packet.
RFC 4828

And we know this is wrong since as most of us know, Al Gore invented the internet.

Actually, Vint Cerf, who practically did invent the Internet (or at very least the protocol upon which it currently operates) has said that Al Gore really does deserves a great deal of credit for his role in making the Internet available to civilian and commercial use.

While ARINs web site indicates they were formed in December of 1997, IANA indicates that ARIN was delegated the 134/8 subnet in May of 1993.

IANA is responsible for global coordination the Internet Protocol addressing systems, as well as the Autonomous System Numbers used for routing Internet traffic.

RFC1466, section 4.2.1, states: Organizations applying for a Class B network number must submit an engineering plan that documents its need for a Class B network number. This document must demonstrate that it is unreasonable to engineer its network with a block of class C network numbers. The engineering plan must include how many hosts the network will have within the next 24 months and how many hosts per subnet within the next 24 months. I really doubt a marketing company could honestly come up with such a plan. In addition to this, RFC1466 has many other guidelines regarding allocation of IP addresses -- too many to mention here.

This Wired article says that Mr. Medin served at NASA until 1995. As such, policies enforced by the above mentioned RFCs were already in place, regardless of whether ARIN was conceived in 1993 or 1997. There's a good chance that the 134.17/16 network block was most likely still allocated to his research team up until 1995.

RFC1166, in its Introduction section, states: This Network Working Group Request for Comments documents the currently assigned network numbers and gateway autonomous systems. This RFC will be updated periodically, and in any case current information can be obtained from Hostmaster at the DDN Network Information Center (NIC). It looks like someone has forgotten about this RFC or it's been superseded by another RFC that I'm not aware of, as it has not been updated, as they still think that the IP block is still allocated to BAY-PR-NET. While it may still be allocated to "BAY-PR-NET", it's not the same BAY-PR-NET. There may also be a communication gap between IANA and ARIN, as ARIN is responsible for tracking network block transfers.

In summary, Trudy's shit is looking pretty weak.

While ARINs web site indicates they were formed in December of 1997, IANA indicates that ARIN was delegated the 134/8 subnet in May of 1993.

IANA is responsible for global coordination the Internet Protocol addressing systems, as well as the Autonomous System Numbers used for routing Internet traffic.

RFC1466, section 4.2.1, states: Organizations applying for a Class B network number must submit an engineering plan that documents its need for a Class B network number. This document must demonstrate that it is unreasonable to engineer its network with a block of class C network numbers. The engineering plan must include how many hosts the network will have within the next 24 months and how many hosts per subnet within the next 24 months. I really doubt a marketing company could honestly come up with such a plan. In addition to this, RFC1466 has many other guidelines regarding allocation of IP addresses -- too many to mention here.

This Wired article says that Mr. Medin served at NASA until 1995. As such, policies enforced by the above mentioned RFCs were already in place, regardless of whether ARIN was conceived in 1993 or 1997. There's a good chance that the 134.17/16 network block was most likely still allocated to his research team up until 1995.

RFC1166, in its Introduction section, states: This Network Working Group Request for Comments documents the currently assigned network numbers and gateway autonomous systems. This RFC will be updated periodically, and in any case current information can be obtained from Hostmaster at the DDN Network Information Center (NIC). It looks like someone has forgotten about this RFC or it's been superseded by another RFC that I'm not aware of, as it has not been updated, as they still think that the IP block is still allocated to BAY-PR-NET. While it may still be allocated to "BAY-PR-NET", it's not the same BAY-PR-NET. There may also be a communication gap between IANA and ARIN, as ARIN is responsible for tracking network block transfers.

In summary, Trudy's shit is looking pretty weak.

There are canned solutions. My primary OS is linux, but OSX is similar in a lot of ways.

OTPW also runs on the BSDs and might therefore be suitable for a MAC. Link: http://en.wikipedia.org/wiki/OTPW

You may want to look at http://tools.ietf.org/html/rfc2289 for the fundamentals.

I have no idea whether there is a S/Key implementation for the MAC, but there might be.

If you are going to implement your own proxy, tehre are password list generators on the web.

The problem is that software other than OpenOffice.org generates the documents, and then OpenOffice.org (the canonical implementation of ODF) opens them. There appears to be data-loss, but in fact, it's an OpenOffice.org bug. But your suggestion (at best) works until OpenOffice.org 3.0 is released, in which case, application vendors have to go back to following the ODF standard again.

Not if they check the version number, which is supposed to be included in the element per the ODF 1.1 spec, Section 3.1.1:

"The element contains a string that identifies the application or tool that was used to create or last modify the XML document. This string should match the definition for user-agents in the HTTP protocol a specified in section 14.43 of [RFC2616]. The generator string should allow product versions to differ between all released versions of a user agent, for instance by including build ids or patch level information.

"Conforming applications may use the generator string to work around bugs that exist or existed in certain applications, but shall not deliberately implement a different behavior depending on a certain generator string."

The fact that there is, for some set of documents, a work-around is irrelevant to my point. The bug report is not showing that AbiWord isn't compliant with ODF. It's showing that OpenOffice.org isn't compliant with the ODF standard. This story is about Microsoft Office generated documents not being compliant with the OOXML standard, and that being intrinsically "bad".

You're comparing apples to oranges. ODF doesn't have the explicit written objective of being compatible with existing Microsoft content. OOXML does. Thus, non-conformance by Microsoft means that OOXML has failed to achieve an objective for which it was specifically created. The same cannot be said for ODF, which was from the beginning intended as a vendor-neutral format to be implemented after it was specified.

But I wonder why it's ok for application vendors to implement "quirks" to work around OpenOffice.org ODF bugs, but not ok to work around OOXML quirks. What's good for the goose is good for the gander.

See my previous response. Not only is it within the ODF spec to allow vendors to provide workarounds for the bugs of other vendors, but no one ever claimed that ODF was a documentation of preexisting content.

If you think that MSFT is going to sue you for implementing a few quirks (because the documents they've generated differ from the actual OOXML standard), I've got a bridge to sell you...

Well, let's see. First, you'd need to know what the differences are between OOXML and the actual Office 2007 format, and because Microsoft is likely not going to document those differences, you'll have to reverse engineer Office 2007 in violation of the EULA. Then you'd have to implement both OOXML and the documented differences, and do so with sufficient quality that it doesn't drive your customers screaming into the open arms of your competitors. Oh, and you need to finish implementing your support before Microsoft comes out with the next version of Office and makes it obsolete.

So, I guess you're right. Microsoft will never bother to sue anyone because the only people who can get far enough with it to be a threat to Microsoft are companies that have the necessary legal, financial and patent assets to negotiate with Microsoft for the information directly.

That's quite a leap. ODF is massive too[...]

OOXML was about 9 times larger before the BRM changes.

[...] and I contest your point that the OOXML spec is poorly written.

Oh, please! You're talking about a spec doesn't even use RFC2119, which is part of pretty much every W3C spec in existence, inc

So you think widely-adopted standards are generally just pulled out of someone's backside?

I suggest you read BCP 9.

You may want to look at the way the Internet Engineering Task Force works.

They are the ones that manage the RFCs that we take for granted today...

Here it is.

to RFC 1149.

I don't think you're understanding the problem at all. The issue is not sending lots of messages to a single address, or the necessity of rate-limiting. The problem is that Google's mail server automatically generates and sends a new mail message to each individual invalid address, even though there is no reason whatsoever to trust the "from" address on a message. *That* fundamental problem is made even worse because in aggregate you usually wind up with tens of thousands of those messages hitting certain domains at a time because spammers generally use a dictionary list on a random valid domain as the return address of their messages.

I realize you're not talking about SMTP bounces here, but someone nearby was, so I want to point out that when a mail server accepts an e-mail message but later realizes it can't deliver it, it's required by the SMTP protocol to generate a bounce and send it to the purported sender. SMTP isn't authenticated, so this will generate backscatter.

In this particular situation, Google has a service where, when you e-mail it, a response is automatically generated. You assert that any service that responds to an unauthenticated e-mail address is effectively spamming everyone that e-mails it. I disagree with that. This would preclude any and every service that responds to "unauthenticated" e-mails, including, paradoxically, everyone that uses e-mail. The solution to this problem is to replace SMTP with something that can be authenticated, which, while theoretically possible, is completely impractical.

Yes, Google should try to classify incoming e-mail to these domains as spam, and avoid responding if it gets classified as such, but it should not feel obligated to eliminate a service that responds to e-mails just because some of those e-mails might have forged senders. But that's just my two cents.

I'm sure somebody is likely to bring it up, so it may as well be me with some additional relevant facts. The HTTP 1.1 specification, RFC 2616, says that:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.

This "improved connection parallelism" is simply changing Firefox from using the RFC-suggested 2 persistent connections, to 6. Now, SHOULDs and SHOULD NOTs are not set in stone, but they do require careful thought before ignoring.

The Bugzilla entry debating this has a comment that points out that other browsers have also started to ignore this part of the specification:

• Firefox 2: 2 connections
• Opera 9.26: 4 connections
• Opera 9.5 beta: 4 connections
• Safari 3.0.4: 4 connections
• IE 7: 2 connections
• IE 8: 6 connections

I'm sure somebody is likely to bring it up, so it may as well be me with some additional relevant facts. The HTTP 1.1 specification, RFC 2616, says that:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.

This "improved connection parallelism" is simply changing Firefox from using the RFC-suggested 2 persistent connections, to 6. Now, SHOULDs and SHOULD NOTs are not set in stone, but they do require careful thought before ignoring.

The Bugzilla entry debating this has a comment that points out that other browsers have also started to ignore this part of the specification:

• Firefox 2: 2 connections
• Opera 9.26: 4 connections
• Opera 9.5 beta: 4 connections
• Safari 3.0.4: 4 connections
• IE 7: 2 connections
• IE 8: 6 connections

I always get a chuckle out of the April Fools RFCs, though there haven't been many the last few years.

Our standing joke around the office for a long time was RFC 3514 RFC 3514, The Security Flag in the IPv4 Header. RFC 2324 is probably my personal favourite. RFC 3252 may have been too clever for its own good, and some people may not have gotten the joke.

...laura

I always get a chuckle out of the April Fools RFCs, though there haven't been many the last few years.

Our standing joke around the office for a long time was RFC 3514 RFC 3514, The Security Flag in the IPv4 Header. RFC 2324 is probably my personal favourite. RFC 3252 may have been too clever for its own good, and some people may not have gotten the joke.

...laura

I always get a chuckle out of the April Fools RFCs, though there haven't been many the last few years.

Our standing joke around the office for a long time was RFC 3514 RFC 3514, The Security Flag in the IPv4 Header. RFC 2324 is probably my personal favourite. RFC 3252 may have been too clever for its own good, and some people may not have gotten the joke.

...laura

URGENT NEWS UPDATE: A ship anchor dragged across communications cables, struggling smaller country, Antigua reports by carrier pigeon that they lost all Internet connectivity. They are considering implementing a RFC 1149 compliant pigeon net as a stop gap.

Thats acually in the FA, there seeing 75% utilization on fat pipes due to P2P.

Also, see the appendix in
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-relax-fairness-00.txt