Slashdot Mirror

If we only had the Security Flag first discussed here

Read RFC 2555. It gives an interesting view of inside of the RFC world. It's written by some of the key people that invented and have made RFC's what they are today.

While "important" is a matter of opinion, it's probably RFC 768, User Datagram Protocol.

You have reached this web page by typing "example.com", "example.net", or "example.org" into your web browser.

These domain names are reserved for use in documentation and are not available for registration. See RFC 2606, Section 3.

You can always use the reserved (and therefore hopefully nullrouted) example.com domains as described in RFC 2606, eg info@example.com

This protocol is RFC 3514 compliant.

Just because an protocol is proposed on 1 April doesn't mean someone won't try to implement it. Consider RFC 2549.

That can be particularily difficult if an application has priority 10+ years back.

Except RFC1034 (aka STD0013) was approved 1 Nov 1987.

Data that's encrypted for transport through a text-only environment (e.g., email), and to be decrypted by a piece of software supporting multiple ciphers, looks like that -- a header describing what kind of encryption you're using, followed by the encrypted data, which is encoded using the base64 algorithm.

But the encrypted data itself, after stripping the header and de-base64ing it, just looks like random binary noise.

If your recipient knew what encryption algorithm you were going to use to encrypt, you could just leave the header off, and if you're hiding the encrypted data in an image format that allows binary data (SVG, being XML, doesn't, but most image formats, such as JPEG, GIF, PNG, are binary), you wouldn't even need to base64 it.

RFC 3675 has some good reasons not to do this.

Now would this "adult bit" be incorporated into the evil bit? Or what?

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.

For what it's worth, removing the username:password parsing from URL's, brings Windows in line with published RFC standards. It was never intended to be used as an authentication mechanism for HTTP URL's.

Section 3.3 of RFC 1738, which defines the format of HTTP URL's, explicitly states, "No user name or password is allowed."

Let me repeat that, in capital letters with bold, so that it is crystal-clear:

THE STANDARD STATES THAT NO USER NAME OR PASSWORD IS ALLOWED IN HTTP URL'S.

This what the standard says, and Microsoft is now adhering to it, at the cost of breaking sites that didn't follow the standard. Microsoft *fixed* Windows by removing this ability from HTTP URL's. Note that FTP URL's still support this feature.

A real-time form of HTML would be a completely new concept altogether.

Oh, sure. If it's 1997. Try checking. Section 8.1.1, page 43.

Moderators: don't moderate something insightful that claims X Topic would be revolutionary unless you know about X Topic, please. Push HTTP has been there since day one. It started push, not pull.

By the way, I do xhtml 1.1 strict, no tables.

Then either you're serving your pages with the wrong MIME type, or they can't be seen in IE at all.

You're not supposed to serve XHTML 1.1 as text/html: you should use application/xhtml+xml. See the W3C's XHTML Media Types. If you're labelling your XHTML 1.1 as text/html, then your browser isn't treating it as XML (note that Mozilla is using Quirks mode, for instance).

Snag is, Internet Exploder (to IE6SP1) doesn't know what to do with application/xhtml+xml, even though there's been a built-in XML parser since IE5, and application/xhtml+xml was defined in RFC 3236 over 2 years ago (and was presumably floating around the standards track for some months before that). But don't worry: just remember that Internet Explorer 6 SP1 gives you the freedom to experience the best of the Internet. At least, that's what it says on the box.

Assuming you're not prepared to be held hostage to the Great Beast, the best workaround at the moment seems to be to use Apache's content negotiation (MultiViews) to lie to IE (and anything else that doesn't know about application/xhtml+xml) that you're giving it text/html.

There's more on this here and here.

Time for another update to RFC1149 ;)?

Can someone help me understand the differences between SIP & XMPP?

I see people post that 'finally we have an IM standard', but it seems that SIP is an existing standard; it's not targeted directly at instant messaging, but covers a lot of the functionality.

The latest version of the actual standards-track URI spec is RFC 2396 (1998-08).

An informational RFC on the meaning of the terms URL and URN in comparison to URI is RFC 3305 (2003-09)

BTW, The old informational RFC on URI's on the WWW is RFC 1630 (1994-06)

The latest version of the actual standards-track URI spec is RFC 2396 (1998-08).

An informational RFC on the meaning of the terms URL and URN in comparison to URI is RFC 3305 (2003-09)

BTW, The old informational RFC on URI's on the WWW is RFC 1630 (1994-06)

The latest version of the actual standards-track URI spec is RFC 2396 (1998-08).

An informational RFC on the meaning of the terms URL and URN in comparison to URI is RFC 3305 (2003-09)

BTW, The old informational RFC on URI's on the WWW is RFC 1630 (1994-06)

What standards are they breaking be removing user/password information from http(s) URLs?

RFC 1738 doesn't mention them. RFC 2396 says some things about a general scheme for include user/password information in a URL (but only for protocols that to not have their own URL schemes like HTTP does), and RFC 1945 again confirms that user/password information do not belong to the HTTP URL scheme.

Finally this is a thing Microsoft does right.

What standards are they breaking be removing user/password information from http(s) URLs?

RFC 1738 doesn't mention them. RFC 2396 says some things about a general scheme for include user/password information in a URL (but only for protocols that to not have their own URL schemes like HTTP does), and RFC 1945 again confirms that user/password information do not belong to the HTTP URL scheme.

Finally this is a thing Microsoft does right.

What standards are they breaking be removing user/password information from http(s) URLs?

RFC 1738 doesn't mention them. RFC 2396 says some things about a general scheme for include user/password information in a URL (but only for protocols that to not have their own URL schemes like HTTP does), and RFC 1945 again confirms that user/password information do not belong to the HTTP URL scheme.

Finally this is a thing Microsoft does right.

Is it possible to differ "good" traffic from "bad" traffic?

Yes.

I don't think E-Mail would be the right set of protocols to be upgraded with "p2p file sharing features".

I mean, y'know.. *cough*complexity*cough*

Be careful which RFC, and which TCP, you mean: RFC 675, "SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM," or RFC 760, "DOD STANDARD INTERNET PROTOCOL." The original TCP was the precursor to IP, and Cerf and Kahn invented it. The RFC for IP edited by Postel (a later RFC replaced it) was a refinement of Cerf and Kahn's work.

A universal ID is simple. Just piggyback it on top of some unique identifier we already have. The article mentions using a SIM, but we could also easily piggyback it on top of DNS. Every customer gets a unique identifier as in "username@realm" from his ISP, where realm is a fully qualified domain name of the ISP.
In fact, that is exactly what RFC 2486, The Network Access Identifier does. No need for anything new there.

Is the "@-spoof" really a spoof? According to RFC2396, section 3.2.2 "Server-based Naming Authority", this is a feature of the URI and not a bug or a spoof.

Certainly it can be made to fool even an enlightened user, but isn't it wrong to cripple a browser's ability to adhere to the "Uniform Resource Identifiers (URI): Generic Syntax" RFC -- and even more so with spyware ;)

Browsing the "test page" at Openwares with my Konqueror gives me the spoof page. Good. That just means that Konqueror is RFC2396-compliant (but should i patch anyway? ;).

I first came across this "bug" about two years ago when i was forwarded an "authentic" page from Microsoft Support: Q209354 - HOWTO (mirror). It took me a while to realize that nobody at M$ was going to be fired for this type of creativity.

See The Reg for an article for some coverage -- although the host hwnd.net is off the net, so you can't really try to get spoofed.

• ~llauren

Jane, you ignorant....

No, no, no, that's the World Wide Web, invented in 1989 by Tim Berners-Lee, which RUNS ON the Internet. The Internet predates that by a couple decades-- RFC #1 is dated Apr-07-1969-- and was developed as a result of a (D)ARPA project.

Now, I'm not saying that putting it under UN control is an inherently bad idea, but these UN ----ers are planning on screwing with the foundations, which is #$%^ing lunacy if you don't consult with someone who knows what they're talking about.

Those who cannot remember the past are condemned to repeat it. -- Santayana

It's too bad that the godfather of internet is no longer with us. RFC was such a better system for internet governance.

Diskless workstations? Try

• this guy (RFC826),
• or this guy (RFC903),
• or even this guy (RFC951), with some options (RFC2132),
• or finally this guy (RFC2131).

Truly there is no need for more, closed protocols.

Diskless workstations? Try

• this guy (RFC826),
• or this guy (RFC903),
• or even this guy (RFC951), with some options (RFC2132),
• or finally this guy (RFC2131).

Truly there is no need for more, closed protocols.

Diskless workstations? Try

• this guy (RFC826),
• or this guy (RFC903),
• or even this guy (RFC951), with some options (RFC2132),
• or finally this guy (RFC2131).

Truly there is no need for more, closed protocols.

Diskless workstations? Try

• this guy (RFC826),
• or this guy (RFC903),
• or even this guy (RFC951), with some options (RFC2132),
• or finally this guy (RFC2131).

Truly there is no need for more, closed protocols.

Diskless workstations? Try

• this guy (RFC826),
• or this guy (RFC903),
• or even this guy (RFC951), with some options (RFC2132),
• or finally this guy (RFC2131).

Truly there is no need for more, closed protocols.

The main difficult case is end-users who have multiple ISP connections and may send packets out their ISP2 connection with their ISP1 address, but even that's manageable.

Routers have traditionally not been very good at doing this kind of filtering, at least without burning large amounts of CPU because it's not implemented in the ASICs, but there's been increasing support recently. For ISPs using Cisco routers, the common approach is uRPF reverse packet filtering, which drops packets with a Source IP address that the router doesn't have a valid route for. Typically on end-user connections you run it in strict mode (which drops it if there isn't a route using the interface that the packet came from), and in the middle or peering edges of the network you'd run loose mode, which drops it if there isn't _some_ route known to the router.

Some ISPs implement this, including one of the largest in the US (Disclaimer: my employer hasn't authorized me to give a shameless plug here, so I won't name them) and most ISPs are at least pretty good about filtering BGP route announcements to only permit addresses that the customer actually owns. That's not universal, and it's sometimes harder to validate ownership than you'd expect, so there's a certain amount of IP address space hijacking, typically of space where the original owners are a dead.com so they're not around to complain when somebody forges a request to one of the registries.

The Internet today doesn't have a structure that reflects IP address allocation, thus requiring huge routing tables to be maintained by routers.

RFC 3587: Moreover, the allocation of IPv6 addresses is related to policy and to the stewardship of the IP address space and routing table size, which the RIRs have been managing for IPv4.

The general format for IPv6 global unicast addresses as defined in "IP Version 6 Addressing Architecture" [ARCH] is as follows:
<global routing prefix> <subnet ID> <interface ID>
where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnets/links), the subnet ID is an identifier of a subnet within the site, and the interface ID is as defined in section 2.5.1 of [ARCH]. The global routing prefix is designed to be structured hierarchically by the RIRs and ISPs. The subnet field is designed to be structured hierarchically by site administrators.

... in other words, a hierarchically structured internet = small routing tables. An internet where every /24 can be located geographically anywhere = BGP gets overloaded.

I'd advise you to have a look at RFC 3041. It deals with this very issue.

Basically, the RFC describes a method to use address es in stateless autoconfig which change over time. Takes care of the privacy issue.

Any more questions?

is to use IP over Carrier Pigeon.

Then the only remaining issue is number of pigeons.

Well, it's really not necessary to RFC the CARP protocol as it will not prevent it from being patented, if that is the case with VRRP. VRRP had been published in RFC form for quite some time(April 1998):Virtual Router Redundancy Protocol I'm not familiar with the detail regarding Cisco appropriating this protocol, though I though VRRP was developed as an alternate to Cisco's HSRP, and had been included in various competing load balancers(Alteon?), prior to Cisco implementing the protocol(actually prior to purchasing the CSS product line)

SRV. Some SIP projects use this already, carriers do not because they (wisely) do not trust DNS. I expect that even if an open standard is used to relay this kind of information it will be done over semi-private networks rather than the public internet.

There are actually quite a few workable schemes for preventing spam. Tim Bray is right that any system where sending is both free and anonymous will always be open to spam, but it's not necessary to charge on a per-message basis. One system that is beta-testing right now is Bonded Sender. With this system, the owner of an outgoing mail-sending server puts up money to guarantee that his system won't be sending spam (on the order of $1000 per server, with $500/year renewal). There's a contract that specifies what is spam and a third-party arbitrator for handling disputes. Existing mail-filtering software can easily check the BondedSender status via the DNS system, as they generally already check the DNS status of senders.

There are a couple of drawbacks to this. First, the IP verification won't work with dynamically-assigned addresses. Second, some smaller email senders may not want to spend as much as $1000 on this. Third, it doesn't help you if your ISP is not participating. All of these can be overcome by using a paid relayer, as Tim Bray suggests. It would be up to the relayer to determine how to prevent abuse of its own system.

Other systems work by verifying a digital signature and certificate of the sender, either on a per-message basis (S/MIME or PGP) or on a per connection-basis (using SMTP over TLS). This doesn't require a static IP address to verify identity.

Although it may seem complex and even chaotic, more than one mechanism will exist to prevent spam, even in the long-term. For a variety of legal, political, and financial reasons, no one solution will please everyone. We need to have some sort of meta-email system for allowing these to co-exist effectively.

What I propose is that an independent group be established which will provide a framework for interoperability. What needs to be done?

• A description of anti-spam policies. For example, Tim Bray's proposed SMTP4ALL charges $.01 per message. Or FirstClassEmail may charge $1 per message. BondedSender contractually forbids spam and requires a cash bond up front, as well as identity verification.

  There are a lot of possible policies. It should be up to the recipient to specify what policy is acceptable, but there needs to be a concise list so that the decision can be coded in a program.

• There also needs to be a way for the recipient to find the policy. For certificate-based systems, the policy can be encoded directly into the certificate, but the exact syntax needs to be defined. For other systems, something else needs to be devised.
• A way to describe the properties of an individual sender or message. It may be part of the sender's anti-spam policy that unsolicited mailings are allowed, but that each mail will be labeled with what type of mail it is, e.g. commercial, personal, political, charitable soliciting, etc. Similarly, a system such as Hotmail may want to label each user as to whether they are a verified, paying customer, or an anonymous, free customer.
• Some sort of meta-enforcement scheme. There needs to be a way of knowing if SMTP4ALL is really charging $.01 per message or if it's letting spammers send through at 1/1000 of that price. Is a CA shirking its duties?

  We don't want the chaos of the current RBL system. This is not something that should be c

http://www.rfc-editor.org/howtopub.html
ftp://ftp.isi.edu/in-notes/rfc2026.txt (The Internet Standards Process -- Revision 3)

Yeah, innovation. He starts off okay, to catch the "first three paragraph's crowd", but he really doesn't get it. He starts losing the careful reading with a strawman, claiming that ICANN said that "the Internet had broken or would break"., which is a blatant exagerration of what ICANN said - which was expressing concern that certain servcies that depended on DNS following documented standard practices had or could break. Every mail domain now exists for starters, which confuses some anti-spam systems.

He goes on to bemoan the lack of innovation inherent in an Internet that is "flat" and of proscribed boundaries. Write an RFC buddy. Or better yet, read one.

This type of approach doesn't sound totally rubbish - but I'd be happier if ISP's would ALL impliment anti-spoofing filters on their routers as in RFC2827.

Obviously the porn is the stuff with the dirty bits

...and the copyrighted material's packets apparently have the evil bit.

One of the nicest ways is a "teergrube" (tarpit) - a special SMTP server that is tuned to process incoming mail really, really slow, thus making the spammer's tools very ineffective. It doesn't take much bandwith or other resources to run one - everybody who has a computer connected to the net and doesn't need to run a "real" mail server (or is willing to configure a teergrubing proxy that only traps spammers and lets the real MTA take care of ham mail) should do so.

Most spam is sent via open mail relays. If you are bored or annoyed enough, take the time to read spam mail headers (the interesting one is the last "recieved" line, usually), and inform the admin of the open relay, so that they can close it or get the fuck out of the internet. Also, inform a blacklist like the Open Relay Database, so that mail servers will reject mails from these hosts.

Try to poison they address databases. Set up a web page invisible for human users that contains lots of addresses that don't exist. But be sure that these addresses also will never exist - only use subdomains that you control, or those mentioned in RFC 2606 (Reserved Top-Level Domain Names), hoping that stupid spamware will try to send to these addresses anyway.

None of this is at odds with client-side filtering or legislative initiatives, just some additional ideas. And annoying these bastards feels good.

With the data uri scheme, I can include the whole internet in my URIs!

Your statement:

SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication")

is misleading.

The secsh draft for protocol 2 states that:
"The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged."

This indicates that the encryption and authentication keys are *not* the same. The draft continues and explains that the hash function associated with the key exchange method in use is used to generate 4 keys, an encryption key for the client, one for the server, and an integrity (authentication) key for the client, and one for the server. This indicates there are four keys generated, not one used for both authentication and encryption.

Also, the ssh1 protocol uses crc32 for integrity/authentication of packets sent between the two hosts. Since crc32 doesn't use a key, you can't be referring to ssh1.