Slashdot Mirror

When I tried elbot I was disappointed to find that it was not as persuasive as the original Eliza. I knew Kenneth Colby when he was developing the contemporary program PARRY. To get a flavor of these early attempts at AI, check out the conversation between Eliza and PARRY memorialized in RFC 439.

In other news:

It is with great sadness that the Royal Society for the Protection of Birds report that the wild pigeon population is being totally decimated, yet strangely there is no evidence of the cause of the presumed deaths.

Wikipedia reports that the hit rate on a page about an interesting implementation of IP has increased by several orders of magnitude.

The IETF report that the RFC server for rfc1149 and rfc2549 have been pom-dotted into oblivion by millions of Britons determined to preserve their privacy.

The price of quality eggs of pure racing pigeon breeding stock has suddenly punctured the thousand pound barrier for the first time in history, resulting in the share value of the British Consolidated Pigeon Breeding Co. increasing by 500% per day for the last week.

Market analysts are dumbfounded.

In other news:

It is with great sadness that the Royal Society for the Protection of Birds report that the wild pigeon population is being totally decimated, yet strangely there is no evidence of the cause of the presumed deaths.

Wikipedia reports that the hit rate on a page about an interesting implementation of IP has increased by several orders of magnitude.

The IETF report that the RFC server for rfc1149 and rfc2549 have been pom-dotted into oblivion by millions of Britons determined to preserve their privacy.

The price of quality eggs of pure racing pigeon breeding stock has suddenly punctured the thousand pound barrier for the first time in history, resulting in the share value of the British Consolidated Pigeon Breeding Co. increasing by 500% per day for the last week.

Market analysts are dumbfounded.

I can't think of anyone more qualified.

Yes, I know he's dead, but I still can't think of anyone more qualified.

I believe DNSSEC is unnecessary to counter the Kaminski attack.

See draft-weaver-dnsext-comprehensive-resolver-00 for how I believe you can secure resolvers against attacks less powerful than MitM, including Kaminski (race-until-win) attacks.

I imagine they are following a format similar to vCard's format for names. It's an easy way of identifying what the different parts of the name are. The format is like this:

Last; First; Other Names; Hon. Prefixes; Hon. Suffixes

ex. Guy; Some;; Rt. Hon.

I imagine they're just trying to keep as much information in the name as possible, since the owner's names are pretty important in patents.

RFC 2817 is pretty badly broken - basically you can MITM and drop the Upgrade: header, and various other problems. The real solution for random sites that just want to protect passwords is RFC 5054 SRP-TLS, however it's not well supported at the moment, and Mozilla don't seem to be interested in pushing it, preferring to make excuses about why they're sticking with 10-year old technology.

RFC 2817 is pretty badly broken - basically you can MITM and drop the Upgrade: header, and various other problems. The real solution for random sites that just want to protect passwords is RFC 5054 SRP-TLS, however it's not well supported at the moment, and Mozilla don't seem to be interested in pushing it, preferring to make excuses about why they're sticking with 10-year old technology.

• Run your websites on different ports, you have 65535 of them per IP. Make http://site1/ redirect to https://site1:1111/, http://site2/ redirect to https://site2:2222/, etc. I concede this prevents users from directly typing the https url in their address bar as they don't know the port number in advance, but again 99% of the users let themselves be redirected to the https content on most websites anyway (except paranoids like me :P).
• Use certs with the "subjectAltName" X.509 extension that let you create a single cert valid for multiple DNS names. I do this (with a CA I created & control), it works very well. The downside is that I think commercial CAs make you pay extra bucks to sign such certs (if they even accept to do that).

Anybody remembers what hapenned to RFC 2817 ? It tried to address this very pb by introducing the "Upgrade: TLS/1.0" header and the "426 Upgrade Required" status code, but I don't think any browser or server implement them.

You should upgrade. I get 56kbps with RFC1149

The spec is a little odd in this regard. It says that GETs should be idempotent -- repeating the request shouldn't change anything. That is not the same as saying that performing the request the first time shouldn't change anything.

Have you actually read the spec? Yes, it says that GET requests should be idempotent. It also says that GET requests should be safe. These are two different things. Saying that it requires GET requests to be idempotent, but this doesn't mean that they should be safe is technically true, but ignorant of what the specification actually says.

For example, clicking a "remove this from my shopping cart" link twice would have the same result as only doing it once -- the item is gone. But the request is still idempotent. That doesn't mean that you should do that, but it does conform to spec.

Straight from the spec:

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

A close relative of the common '404 page not found' error, 418 I'm a Teapot is the response specified in the RFC 2324 - Hypertext Coffee Pot Control Protocol (HTCPCP).

Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.

on top of that if they would redo ssl so thatyou can support host headers that would allow allot of consolidation of webservices/sites by farm hosters..

That would be RFC 2817, which Apache already supports since version 2.2. Unfortunately, this is unsupported in most browsers.

Why? Does the mail server you are trying to connect to not support the latest SMTP RFC?

Using "EHLO" can give you extended information that tells you the capabilities of the mail server, and when you're trying to diagnose a problem, that's a good thing. Many times I have figured out a mail server is misconfigured from only the response to "EHLO".

There is no indication that Firefox sends any of the current browser cookies to Google in step #3

Evidence is here (section 3.7.1):

The client performs a datarequest by sending an HTTP POST request to the URI:

and here (section 4.3.4):

When it sends a request to an origin server, the user agent sends a Cookie request header to the origin server if it has cookies that are applicable to the request

I've heard these ideas for years but, even after RTFA, and the 6Lowpan and ROLL references, I'm still trying to understand the advantage of these proposals over the existing technology (like ZigBee, among others). To be practical at all, the "Internet of Things" would have to be wireless, so there has to be an access point somewhere to the wired Internet. And because IP routing performs poorly in a multihop wireless network, the wireless network will have to use a different routing scheme, but still use the compressed IPv6 headers, while maintaining the low power features needed for battery-powered devices. The access point would have to handle both routing algorithms.

There would be no IP-related economies of scale in the networked devices, since they would need a new, start-from-scratch routing algorithm (e.g., ROLL).

So why is this superior over existing wireless protocols designed for this application? Is it just the gateway design? It doesn't seem like the gateway design of existing protocols would be significantly more complicated but, even if it were, it seems like would be repaid by the simplicity and size reduction in the many "small objects" in the network -- sort of an economic version of Amdahl's law. No?

I've heard these ideas for years but, even after RTFA, and the 6Lowpan and ROLL references, I'm still trying to understand the advantage of these proposals over the existing technology (like ZigBee, among others). To be practical at all, the "Internet of Things" would have to be wireless, so there has to be an access point somewhere to the wired Internet. And because IP routing performs poorly in a multihop wireless network, the wireless network will have to use a different routing scheme, but still use the compressed IPv6 headers, while maintaining the low power features needed for battery-powered devices. The access point would have to handle both routing algorithms.

There would be no IP-related economies of scale in the networked devices, since they would need a new, start-from-scratch routing algorithm (e.g., ROLL).

So why is this superior over existing wireless protocols designed for this application? Is it just the gateway design? It doesn't seem like the gateway design of existing protocols would be significantly more complicated but, even if it were, it seems like would be repaid by the simplicity and size reduction in the many "small objects" in the network -- sort of an economic version of Amdahl's law. No?

This is an IETF working group - Routing Over Low power and Lossy networks (ROLL). Like all IETF WG, it has a Charter which you can read to find out more, and 4 outstanding Internet drafts (listed in the charter).

No. NAT-PT really was a bad idea, because it required the network address translator and the domain name rewriter to be tightly coupled in the same box, and that scales not at all well.

The new proposals in IETF to replace NAT-PT all separate these aspects of the problem into more loosely coupled components. You want to know more about them? See the wiki for the upcoming IETF Internet Area interim meeting.

Guess that might be an improvement over using carrier pigeons. Wonder if this will make the RIAA go postal?

Using RFC 1149 of course. Great news for Open Source since Linux's preferred carrier type placed severe limitations on overland RFC1149 performance*, but is ideally suited to a marine environment.

(*because penguins can't fly)

Technically, commas are legitimate URI characters: http://www.ietf.org/rfc/rfc2396.txt But I agree with you 100%. A simple FIFO check could be used to verify they occur after a first or third slash, and not within the domain name itself: (http://www.example.com/0,03882,page.html OR www.example.com/0,03882,page.html) This simple find and replace should recognize an out of place URI reserved character, and attempt to replace it with a dot, before sending it to search. Furthermore, your browser should keep a small database of acceptable TLDs to "spell-check" frequent .cpm and .xom fat-fingerings. But alas, these "everyday" features are lost on the Killer Enterprise App culture of the current Browser Wars.

IPv6 does support anonymity — see RFC 3041. But I ignored that since it would spoil my nice joke.

Traceable IP numbers would not help against spam and DOS, because that's perpetrated through botnets, not through direct contact.

There's an IETF group working on IPv6 over Low Power devices: 6LowPan (with RFC4944 already released). From what I know they are using header compression and adaptation to the normal IPv6 header to be able to use it over 802.15.4 (this is the "entry" MAC protocol, future objective is to be transparent to lower layers). A routing protocol is also under development in coordination with 6LowPan, the Routing Over Low power and Lossy networks (roll).

Don't know the status of Contiki regarding this.

What you're talking about is called Mobile IP, which is standardized by RFC 3344. Doesn't seem to be used very widely, probably because the density of 802.11 access points isn't high enough for it to be useful in most areas.

My hardware identifies traffic streams as 'Interactive', 'Download', and 'Bulk Download'. 'Interactive' is the obvious ssh, rdp, etc traffic. 'Download' is for stuff I want sooner rather than later, 'Bulk Download' is for stuff that I don't necessarily want so fast (eg torrents).

This technology has existed in IP itself since 1981 as the TOS bits. Your "Interactive" is IPTOS_LOWDELAY. Your "Download" is IPTOS_THROUGHPUT. Your "Bulk Download" is IPTOS_LOWCOST. See RFC 791 from 1981 and RFC 1349 from 1992.

My hardware identifies traffic streams as 'Interactive', 'Download', and 'Bulk Download'. 'Interactive' is the obvious ssh, rdp, etc traffic. 'Download' is for stuff I want sooner rather than later, 'Bulk Download' is for stuff that I don't necessarily want so fast (eg torrents).

This technology has existed in IP itself since 1981 as the TOS bits. Your "Interactive" is IPTOS_LOWDELAY. Your "Download" is IPTOS_THROUGHPUT. Your "Bulk Download" is IPTOS_LOWCOST. See RFC 791 from 1981 and RFC 1349 from 1992.

See 6LoWPAN. Or here.

I thought that bit had to be set if present - NO?

The bit field is laid out as follows:

                          0
                        +-+
                        |E|
                        +-+

Terminology

      The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
      SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
      document, are to be interpreted as described in [RFC2119].

RFC 3514 - The Security Flag in the IPv4 Header:

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

This is, unfortunately, the truth... Far too many programmer wannabees around...

It is also unfortunate that perfect e-mail parsing is extremely complex. The Perl regexp for e-mail address validation according to RFC 822 is about 6.3 kilobytes. If you try to do it yourself you are pretty much guaranteed to get it wrong.

Those crappy programmers could still make things much better with liberal validation, allowing some invalid addresses to make validation simpler. Something simple like /[^@]+@[^@]+\.[^@]+/, will match all valid e-mail addresses (I think, and the /. filter won't let me write anything more complex than that anyway) plus a bunch of invalid ones.

We already have a viable alternative to allow a kind of self signing with DNSSEC. DNSSEC requires a PKI infrastructure to be built into the DNS naming system that could make any other PKI infrastructure obsolete (see RFC-4398).

Why the fuck should a document markup language specify required codecs?!

It doesn't need to. It should specify recommended codecs to make the situation of The Article less likely to arise.

HTML 4 doesn't even specify any image formats required for the IMG tag.

W3C maintains a copy of the PNG specification as a Recommendation. It also maintains an informational web page about JPEG and JFIF. Where are the corresponding pages for audio and video formats?

If they were to force required codecs, text-only browsers would be required to support video

That's why I said SHOULD and not MUST, as in "user agents that implement streaming video and audio SHOULD be able to decode Ogg Theora and Ogg Vorbis."

and that's just ludicrous.

I'm glad you didn't misspell it :-)

It costs less to just design a page for W3C spec.

There is no W3C spec for codecs to be used for live streaming video and audio. When W3C tried to specify that browsers SHOULD decode Theora and Vorbis in an object element (HTML 4) or a video element (HTML 5), Nokia female-dogged.

You seem to be going out of your way to miss the point. Better than nothing security is better than nothing. You said so yourself. I don't trust "trusted" third parties. They have never proven to me personally that they are trustworthy. Verisign has proven the opposite by issuing Microsoft certificates to a party that false claimed to be Microsoft. I don't trust "trusted" CAs and I don't want to pay an annual fee to third parties that I don't trust in order to allow visitors to my web site to have the option of using encryption. But if I don't pay the CA tax, browsers tell my visitors that my site is not "secure". I am not collecting credit card data or any other personal information. I just want my visitors to have the option of an encrypted connection. I don't care who they are (hey I've been on /. since almost the beginning and I still post AC because who I am is not important), and I give them the choice of plain http, but the browser says that if I use a self-signed cert my site is not "secure". How do you think most users (not you, not me, but most users) will interpret that? Does 'not "secure"' mean no encryption? Does it mean no authentication? Does it mean Chinese, terrorists, crab people, PETA or Dick Cheney broke into my server? The broken UI lets users assume the worst. I just want to give visitors (yes, random visitors, whether they're the good guys or the bad guys, Chinese or Cheney, environmentalists or eco-terrorists, Austrian or Australian) the choice of making passive eavesdropping a little harder for whatever reason they may want that option. It's better than nothing.

This used to be true, but not anymore. Now there's Server Name Indication - RFC3546, that would allow this. However, OpenSSL (and by extension, mod_ssl) does not support it. GNUTLS does, however (and there's a corresponding mod_gnutls for Apache.

There is no fundamental incompatibility. A solution to this was proposed back in 1993. Bizarrely, it's still not a standard. Happily, the "server_name" Hello Extension (which lets the server pick the right certificate for the right virtual host) hasn't changed in years. Internet Explorer 7 supports it. There are patches for Apache that support it, but I don't know if it's in the mainline yet. And I don't know about firefox.

In summary, you can definitely support multiple https virtual hosts on a single IP using IE7 and patched Apache. And the situation may be better than that.

There is no fundamental incompatibility. A solution to this was proposed back in 1993. Bizarrely, it's still not a standard. Happily, the "server_name" Hello Extension (which lets the server pick the right certificate for the right virtual host) hasn't changed in years. Internet Explorer 7 supports it. There are patches for Apache that support it, but I don't know if it's in the mainline yet. And I don't know about firefox.

In summary, you can definitely support multiple https virtual hosts on a single IP using IE7 and patched Apache. And the situation may be better than that.

Uh. The post you replied to mentioned the square brackets?

The brackets are technically NOT part of the IPv6 address syntax spec though, they're a secondary convention that is now fairly widely adopted by various specs (such as http urls...) and applications.

Well, there's the RFC1924 option.

Then, IPv6 addresses would be represented in base85 encoding, delimited by something - The RFC strongly hints [].

Might be nice though e.g.:

[4)+k&C#VzJ4br<0wv%Yp]

- note that this is not confusable with the now-conventional [xxxx:xxxx::xxxx:xxxx] because : is not one of the allowed characters in the base85 scheme in the rfc.

Always 20 characters from a certain set between [ ] . Easily matched with regexes, shorter (much shorter) than a hex address.

Yes, it looks a bit line-noise-y, but it's far more regular.

Many large ISPs such as Hotmail and AOL, and I believe Yahoo, offer a "Feedback loop", which sends you an ARF-formatted e-mail every time someone reports your message as spam. Using that, you can automatically ban them from your list so they never get another message.

Also, make sure your list is double opt-in (so person A can't sign person B up without their consent). Also make sure your mail server isn't replying to spam/worm messages, otherwise you'll be sending lots of replies to real and fake addresses which may be considered spam trap hits by Yahoo's server.

Also set up DomainKeys for your outbound e-mails. I know Yahoo uses that, and it's one more way to make your message more legitimate-looking.

Also check http://help.yahoo.com/l/us/yahoo/mail/postmaster/ for more Yahoo hints.

wow, teapots at every turn for me today. first Russell's teapot, then HTTP Error 418 and now Alice and Lena and a teapot. oh my.

See RFC 3514 http://www.ietf.org/rfc/rfc3514.txt?number=3514

Vulnerabilities of Network Control Protocols: An Example, published in January 1981.

What do they say about those who ignore history?

Adler-32 wouldn't be a great choice. It's fast but it's weak for short messages and I've seen it fooled by multi-bit errors on large messages too.

See Koopman's paper 32-bit cyclic redundancy codes for Internet applications for some better ideas.

Then greylisting was implemented, which stopped the spam dead in its tracks, and completely nullified the spam that Double Dribble couldn't stop. That's when I turned over the account to another party. I still use greylisting personally with great success.

For me, between greylisting and requiring strict RFC compliance for the "HELO" parameter, pretty much no spam gets through to even be looked at by SpamAssassin.

For the "HELO" parameter, almost every spambot uses one of:

• something that isn't a fully qualified domain name ("laptop", "Notebook", and "PC-200806211153" are some recent examples)
• an IP address

Neither of these are acceptable (according to section 2.3.5 of the SMTP RFC) as the "HELO" parameter.

Then, I throw out a few more bogus things, like:

• my host/domain name
• my public IP address
• domain literals (i.e., an IP address surrounded by square brackets) that have an IP address in a bogon range

At this point, the e-mail gets to face greylisting, ClamAV, and SpamAssassin. About 1 in 100 "bad emails" get through to the end users.

But this problem has already been solved in a backwards-compatible way.

See RFC 2550 - Y10K and Beyond.

Use CP/IP (RFC 1149 ).

You'll get great bandwidth, especially during migratgory seasons.

What has changed since RFC 1123's clarifications of SMTP?

There really should be no expectation of privacy in e-mail. I've been hearing since at least 1989 that e-mailing sensitive information is about as secure as writing it on a postcard--and I never even used e-mail until 1998! It's no more private today than it ever was.

If you want to send evidence of your criminal activity by e-mail and keep it secure, learn to use encryption. Or better yet, don't, and get convicted and sentenced. Please.

I believe in the 4th Amendment, but I really don't think it applies here.

Too many RFCs are being blatantly ignored. To the interweb's detriment. RFC 821/2821, RFC 1178... need I go on?

You forgot RFC 1149

The Rules: (or DA RULZ)

http://www.isoc.org/internet/conduct/cerf-Aug-draft.shtml

http://www.dei.isep.ipp.pt/~acc/docs/arpa--1.html

http://www.ietf.org/rfc.html

http://rfc.net/rfc2430.html

Traffic Shaping Example:

http://rfc.net/rfc3514.html