Slashdot Mirror

PGP is close, but no cigar as it works at MUA, not MTA level.

The domainkeys draft: http://www.ietf.org/internet-drafts/draft-delany-d omainkeys-base-04.txt is a much closer approximation of what is needed here as it also describes the way this fits at the MTA level.

There are also some obvious ways to build on this draft as far as trust chain management, but it will be better if they do not get in the draft and the draft is accepted "as is" for now. All other reasons aside, better to have an RFC to build on instead of having another draft-martini where there are 10 RFCs out before the original draft settles.

So to summarise the original article is an absolute POS. The person writing it did not even bother to check if the work is being done by someone else and if there is someone big enough out there using it (yahoo).

Everyone knows that TCP can't work to Mars - the transmission delays are too long.

I'd rather they just list tel:// URLs in messages and webpages where appropriate, but integration is a good thing. I haven't signed up for Skype because, between Yahoo!, MSN, ICQ and my cell phone, there are already too many ways to contact me instantly. Besides, I just use gaim for 90% of my IMing anyway...

Zfone, like Off-the-Record Messaging, doesn't use a pre-shared key to prevent man-in-the-middle attacks. Rather, it uses a code (conceptually similar to a key fingerprint) which each person reads for the key they have from the other person, to the other person. By ensuring this code matches what is expected, and observing that the voice is not being artificially replaced between the two people.

As long as those codes are correct, the call is secure.

The second part is that a bit of information is kept from each call, and used in an authentication process in the next call. Because both systems will know this information (if they are the same systems), authentication can occur without either person needing to deal with it directly. If the systems for the second coll are not the same as for the first, the code-reading process must occur again.

There is more to it than that, but that's the quick dirty summary.
For more details, try:
http://www.philzimmermann.com/EN/zfone/index-faq.h tml
http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.ht ml (not the same, but very similar)
http://en.wikipedia.org/wiki/Perfect_forward_secre cy
http://www.ietf.org/internet-drafts/draft-zimmerma nn-avt-zrtp-01.txt

You're forgetting massive biggie: RFC-1855 (Netiquette guidelines), why your email and news readers put the cursor before quoted text, and why you should think critically before using Earthlink's anti-spam. God knows September needs to end already.

http://www.ietf.org/rfc/rfc3675.txt explains why pretty clearly

It is all text only anyway:

MIME == Multipurpose Internet Mail Extensions === http://www.ietf.org/rfc/rfc0989.txt

Despite this, yes, all e-mail should be plain text only.

html in e-mails is a toy, not a communication tool.

Would you kindly please stop referring to RFC1149 as a "bizarre system"? The NO CARRIER jokes are bad enough, without this kind of FUD. Thank you.

we should be talking about how to encourage the deployment
dnssec and related protocol modifications/enhancements.

yes, re-creating the internet from the ground up to be safe from all harm would be nice. i suspect that this effort will take a little while. until then, interim measures should be pursued. dnssec is one of them.

You are correct. Greylisting (usually) has nothing to do with looking up the rDNS records for hosts, thats the MTA's job. On my mail servers, I do both. And no, rDNS lookup is not required for an MTA to accept mail; but according to this RFC: http://www.ietf.org/rfc/rfc2821.txt, the SENDING host should have a PTR record. But you are right, nothing to do with greylisting.
My point was, that these spam hosts are getting more sophisticated; i.e., they are acting more and more like MTA's by retrying and having thier fqdn host names in thier HELO, etc - thereby making it harder to distinguish from legitamate mail servers.
-Ponga

There is ONLY ONE valid Content-type for XHTML content, and that is application/xml+xhtml, not text/html.

This is simply not true. RFC 2854, the definition of text/html, explicitly permits XHTML 1.0 documents that follow Appendix C to be transmitted as text/html.

Doing so causes Mozilla and Opera to parse it as HTML and not XHTML, but that doesn't mean it's "invalid" or non-standard in any way.

Heh. I like to think that maybe, just maybe, a few of them actually took the time to look at RFC 3675.

A number of approaches can use DH. http://www3.ietf.org/proceedings/06mar/slides/raia rea-1/raiarea-1.ppt The tunneling aspect is not so straight forward with voip since the signalling and bearer channels are not necessarily going to the same place. Another challenge with VoIP encryption is how to deal with non point-to-point streams, ie. conference calls. The device doing the audio/video bridging needs to maintain key pairs with all connected participants which in itself isnt all that bad, but from a users perspective all you know is that you have a secure session to the bridge, you do not know who else the bridge has sessions with and if it is (intentionaly or not) leaking your audio to someplace it shouldnt be.

Unfortunately, the owner has recently become deceased, and the trousers, not programmed to account for little things like that still executes its normal routine...

Maybe they should borrow some ideas from RFC 2795 (Infinite Monkey Protocol Suite). The KEEPER Message Response Codes would be invaluable here.

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

unless you're doing some leftover-1980s hackery like implementing TCP over ISO CLNP

Actually TUBA was early to mid-90's.

(At least we ended up with IPv6 instead which is way, way, better because... um... never mind.)

>> Microsoft had rewritten the TCP/IP stack in Vista/Longhorn and added some of their own protocols.

They're doing precicely what they said in the Haloween documents, de-commoditizing protocols & services.

"OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."

http://os2.modfoo.com/halloween/halloween1.php

> They aren't changing TCP/IP. They are just adding API features to the stack and ..

By what logic is adding features to TCP/IP not changing it. Will third party apps that have to communicate with Windows processes have to use these extensions. Will third party companies have to sign a 'license` to use such extensions. Has Microsoft copyrighted such extensions.

Is the Internet Engineering Task Force (IETF) aware that Microsoft is now the prime arbiter as to what constitutes TCP/IP(TM)

http://www.ietf.org/

According to Wikipedia, WebNFS!=NFSv4. Also, a quick look at RFC 3530 seems to valide what is said on the Wikipedia.

That would be RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers". AKA Pigeon Protocol.

I'm sure Cheney approves.

iCal is a calendaring file standard.

Well strictly speaking icalendar (rfc 2445) is the standard, but (as with vcalendar) it's a bit of a mouthful. iCal (to me) is Apple's software, but ical is the standard.

This has been discussed to death, and RFC 3675 was the result. The onus is on proponents of the .xxx TLD to refute the RFC, not the other way around.

What do "conservative Christian groups" have to do...

Little or nothing. The MSNBC wording is suspiciously ambiguous:

Pressure from conservative Christian groups in the US, which has a veto over the internet addressing system, led the organisation last year...

Reading this quickly leads one to think ICANN must get sign-off from Jerry Falwell or somesuch. In fact, the veto power belongs to the US government, not a US church.

It isn't necessary to rely on religious zealots to provide reasons for opposing .xxx, .sex, etc. There are sound legal, philosophical and technical reasons why .xxx is a bad idea. Consider what some at the IETF have to say on the matter.

EU has full right to complain about us control over the domains

Yes. The EU and any other recognized government. Ommited from the /. blurb is opposition of .xxx from other nations...

The default /. Slashdot position appears to be; .xxx is cool and it's only those Benny Hinn types getting in the way! This is juvenile, naive and about par for the /. course, so take what you read here on the matter with a large grain of salt.

RFC 3675

Get the facts

Are you saying that these new websites implement the Infinite Monkey Protocol Suite?

You better re-examine your idea of security here. For starters, your ISP that you connect your server to can easily store both sides of a conversation...it has to pass through their server *both ways* for you to communicate.

Well, no.

If you truly run your own mail server, with MX records rather than using your ISP's POP box as a store-and-forward, then it isn't going through their server. Technically ;>. The only real difference this makes is that your communications clearly fall under the Pen Register rules rather than the Wiretap rules when the authorities try to legally obtain info about your communications.

It does still go through their network. But that's a (slightly) different matter. Yes, they can still sniff the traffic both ways. This is where StartTLS comes in. If your mail server offers StartTLS, and the remote mail server is willing to try it, then everything except the EHLO of the SMTP transaction is encrypted just as HTTPS web pages are.

You can easily set up most mail servers to run "Opportunistic" StartTLS. That is to say, "Offer it, and take advantage if someone else offers it, but don't require it." For the purposes of encryption, it doesn't matter that most people will use self-signed certificates. (Yes, that kills authentication.)

You can also require StartTLS, but that would impact your ability to send and receive mail to sites not configured to do StartTLS. (But for the paranoid, it bears mentioning.)

Google quickly found a few sites for various mail transfer agent configurations:

• Postfix
• Sendmail
• Exim
• Qmail
• Exchange (no good link, and may not allow opportunistic)

In short... my mail server secures mail with anyone else who cares to do so. If you are enough to run your own server, consider caring enough to offer and take advantage of StartTLS encryption.

N.B. - If self-signed certs are a pain (and they are), look into CAcert.

RFC3675: .sex Considered Dangerous

And, of course, .xxx == .sex; within the meaning of the RFC.

I wish more people were aware of this RFC - it seems to have fallen under the radar for the current spate of domain name based porn separation politics, which is a shame.

The short version is that it's unenforcable: domain names are _not_ cannonical names for internet activities, therefore, it's trivial to have multiple names for a host. Therefore you have to work out what to do when someone points a non .xxx domain at a host that has porn on it. This need not be an intentional 'Joe job', but can be perfectly legitimate.

This is all totally seperate from the whole debate over what is and isn't 'pornography' - that is not decidable outside a handful of special cases.

I personally dislike the idea of data urls, for the following reasons.

1. Embedded files can not be reused.
2. Embedded binary files are approximately 33% larger than their non-embedded versions, because they must be encoded first.
3. Section 6 of RFC2397.

Back to Acid2 guided tour. Here are the problems I see right off the bat.

1. The "version without data URLs" link brings you to a page that uses a data url in one of the tests. Oops.
2. The ACID2 page does not include the URI in the DTD line. This is in violation of HTML 4.01 Section 7.2, which states "HTML 4.01 specifies three DTDs, so authors must include one of the following document type declarations in their documents." (Emphasis mine) All 3 DTDs listed include URLs.
3. Acid2 claims "Acid2 assumes basic support for... CSS1..." but actually tests against CSS2.
4. The Acid2 test intentionally has an object of type application/x-unknown. This has a nasty tendancy to launch plugin finders in most browsers. application/octet-stream is the "official" unknown type.

I'm sure I'll find more later, but it's getting late here.

Fools. Politicians should learn to read technical documents and the recommendations of technical experts.

But the question is, why would anyone look up my.spam.com? I think the attack might be based on spoofing DNS NOTIFY messages to change the authoritative server for a really popular domain. Specifying a short timeout would prevent the reflector from caching the response, so all requests would be forwarded to the victim.

What's the difference between this and SRTP?

2.1 What is ssh?

To quote the README file:

Ssh (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp.

Additionally, ssh provides secure X connections and secure forwarding of arbitrary TCP connections.

2.3 What kinds of attacks does ssh protect against?

Ssh protects against:

• IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside.
• IP source routing, where a host can pretend that an IP packet comes from another, trusted host.
• DNS spoofing, where an attacker forges name server records
• Interception of cleartext passwords and other data by intermediate hosts.
• Manipulation of data by people in control of intermediate hosts
• Attacks based on listening to X authentication data and spoofed connection to the X11 server.

In other words, ssh never trusts the net; somebody hostile who has taken over the network can only force ssh to disconnect, but cannot decrypted or play back the traffic, or hijack the connection.

The above only holds if you actually use encryption. Ssh does have an option to use encryption of type "none" this is only for debugging purposes, and should not be used.

2.4 What kind of attacks does ssh not protect against?

Ssh will not help you with anything that compromises your host's security in some other way. Once an attacker has gained root access to a machine, he can then subvert ssh, too.

If somebody malevolent has access to your home directory, then security is nonexistent. This is very much the case if your home directory is exported via NFS.

2.5 How does it work?

For more extensive information, please refer to the README and RFC files in the ssh directory. The proposed RFC is also available as an Internet Draft from ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls- ssh-00.txt .

All communications are encrypted using IDEA or one of several other ciphers (three-key triple-DES, DES, RC4-128, TSS, Blowfish). Encryption keys are exchanged using RSA, and data used in the key exchange is destroyed every hour (keys are not saved anywhere). Every host has an RSA key which is used to authenticate the host when RSA host authentication is used. Encryption is used to protect against IP-spoofing; public key authentication is used to protect against DNS and routing spoofing.

RSA keys are also used to authenticate hosts.

There is already http://www.ietf.org/internet-drafts/draft-ietf-tsv wg-sctpsocket-12.txt
which defines a socket API for sctp use. (most implementation implements this)
If you want to use sctp just like TCP (not leveraging many of the other sctp features) you just change the last argument of the socket(2) call to IPPROTO_SCTP.

see http://www.ietf.org/internet-drafts/draft-ietf-tsv wg-addip-sctp-13.txt

That's why you need http://www.ietf.org/internet-drafts/draft-ietf-tsv wg-addip-sctp-13.txt

Ah, man: never encumbered by second thoughts about exploiting animals for warfare.

Why should we suddenly have qualms about sharks?

That's why we have RFC 2606

The problem for all 'governments-of-the-day' who enact stupid legislation is that there is always a way around the 'problem'. There is also clandestine high frequency high speed RTTY.

• sorting (by author, date, etc)
• read vs unread
• catchup

The rest would be nice to have, but aren't needed in most cases. This is hardly anything new - eg. NNTP is a pretty basic protocol, and a lot of the things commonly used with it are extensions. If you want them, there are extensions for your other complaints; threading, expiration . Commenting requires a protocol of some kind; the Atom Publishing Protocol would be nice, but it isn't through the IETF yet.

BTW, this is all Atom. RSS solutions probably exist, but the thought makes me feel very, very dirty.

• sorting (by author, date, etc)
• read vs unread
• catchup

The rest would be nice to have, but aren't needed in most cases. This is hardly anything new - eg. NNTP is a pretty basic protocol, and a lot of the things commonly used with it are extensions. If you want them, there are extensions for your other complaints; threading, expiration . Commenting requires a protocol of some kind; the Atom Publishing Protocol would be nice, but it isn't through the IETF yet.

BTW, this is all Atom. RSS solutions probably exist, but the thought makes me feel very, very dirty.

The 'Unipage Unifier' program instantly turns any online or local page into a 'Unipage' that can be viewed directly in a browser.

In case you're happy that "a browser" doesn't include Microsoft Internet Explorer, which doesn't support the data: URL spec (RFC 2397), be my guest. There isn't anything magically going on. According to RFC 2397 you can encode an external document, including all its data data, to an URL. Basically, you just need to prefix data:image/png;base64, to base64 encoded PNG image and paste the resulting string to SRC attribute of IMG element and you're done embedding the PNG image inside a HTML document.

Did I mention that MSIE does NOT support RFC 2397? So, you can use this method for every other browser but for MSIE and you have to use Microsoft's proprietary .MHT format for MSIE. IMO, it's not worth the trouble, just use PDF instead.

Wake me up again once somebody comes up with a way to put a HTML page with at least (originally) external PNG and CSS files inside a single file that can be viewed correctly without plugins with MSIE, Mozilla, Safari and Konqueror.

Does the PDF standard belong to Adobe? - Yes, but they publish the standard in enough detail so that anyone can use it to read/write standard PDFs. See http://partners.adobe.com/public/developer/pdf/ind ex_reference.html

Do they charge for this, their patents pertaining to PDF, etc? - No, not as long as you're trying to be compliant with the PDF standard. See http://www.ietf.org/ietf/IPR/adobe-ipr-draft-zille s-pdf.txt

Adobe could have created a proprietary format and tried to defend it via patents, but they haven't. They could have also tried to make money off of 3rd parties trying to create PDF reader/writers by charging for patent licenses, but they haven't.
This is the reason that the PDF format (and, by association, Adobe) is the leader in this area.

Programming Jabber
Publisher: O'Reilly Media, Inc.; 1st edition (January 1, 2002)

RFC 3923 (s/mime) is dated october 2004 (http://www.ietf.org/rfc/rfc3923.txt)
version 0.1 (current=0.9) of JEP 116 (Encrypted Sessions) is dated 2003-09-09 (http://www.jabber.org/jeps/jep-0116.html)

JEP 27 (current openPGP usage) version 0.1 is dated 2002-03-12 (http://www.jabber.org/jeps/jep-0027.html)
The basic XMPP RFC (3920) (inc. TLS) says the XMPP WG was founded in 2002. (http://www.ietf.org/rfc/rfc3920.txt)

So the book might include some info on OpenPGP and TLS, but not on S/MIME or Encrypted Sessions.
It also would not include a lot of other good stuff like Personal Eventing Protocol (PEP, AKA Simplified PubSub), anti-SPIM methods, Jingle Audio, the current method of File Transfer, etc.

So yeah, you might want to wait for a new edition or just use online resources

http://planet.jabber.org/
http://www.jabber.org/developer/
http://wiki.jabber.org/index.php/Main_Page
http://www.jabber.org/jeps/

Programming Jabber
Publisher: O'Reilly Media, Inc.; 1st edition (January 1, 2002)

RFC 3923 (s/mime) is dated october 2004 (http://www.ietf.org/rfc/rfc3923.txt)
version 0.1 (current=0.9) of JEP 116 (Encrypted Sessions) is dated 2003-09-09 (http://www.jabber.org/jeps/jep-0116.html)

JEP 27 (current openPGP usage) version 0.1 is dated 2002-03-12 (http://www.jabber.org/jeps/jep-0027.html)
The basic XMPP RFC (3920) (inc. TLS) says the XMPP WG was founded in 2002. (http://www.ietf.org/rfc/rfc3920.txt)

So the book might include some info on OpenPGP and TLS, but not on S/MIME or Encrypted Sessions.
It also would not include a lot of other good stuff like Personal Eventing Protocol (PEP, AKA Simplified PubSub), anti-SPIM methods, Jingle Audio, the current method of File Transfer, etc.

So yeah, you might want to wait for a new edition or just use online resources

http://planet.jabber.org/
http://www.jabber.org/developer/
http://wiki.jabber.org/index.php/Main_Page
http://www.jabber.org/jeps/

The XMPP RFC describes the useage of SASL and TLS:
http://www.ietf.org/rfc/rfc3920.txt
TLS can be used on client-sever connections and on sever-server connections.

JEP 27 describes the useage of OpenPGP for encryption:
http://www.jabber.org/jeps/jep-0027.html

RFC 3923 describes S/MIME useage:
http://www.ietf.org/rfc/rfc3923.txt

JEP 116 describes Encrypted Sessions, which seems to be somewhat reminiscent of SSH:
http://www.jabber.org/jeps/jep-0116.html
I don't know that anyone implements this yet.

BTW Can someone tell me whether the connection between the two people chatting with Jabber is P2P or whether it is routed via the server?

Normal chatting at least is all client-server. File transfer can be p2p (normal case) or client-server, while Jingle Audio is p2p.

The XMPP RFC describes the useage of SASL and TLS:
http://www.ietf.org/rfc/rfc3920.txt
TLS can be used on client-sever connections and on sever-server connections.

JEP 27 describes the useage of OpenPGP for encryption:
http://www.jabber.org/jeps/jep-0027.html

RFC 3923 describes S/MIME useage:
http://www.ietf.org/rfc/rfc3923.txt

JEP 116 describes Encrypted Sessions, which seems to be somewhat reminiscent of SSH:
http://www.jabber.org/jeps/jep-0116.html
I don't know that anyone implements this yet.

BTW Can someone tell me whether the connection between the two people chatting with Jabber is P2P or whether it is routed via the server?

Normal chatting at least is all client-server. File transfer can be p2p (normal case) or client-server, while Jingle Audio is p2p.

Hey, their problem has already been solved

A lot of people live in rural areas, and don't have anything. Not even dial up. On /., you don't hear a lot from these types, but they're out there.

AMT
http://www.ietf.org/internet-drafts/draft-ietf-mbo ned-auto-multicast-05.txt

Perhaps according to you, but not according to RFC 2854, which defines the text/html media type.

Actually, they say that the XHTML 1.0 mappings to "tag soup" can be marked as "text/html" but those markings are horrible anyway (and, best of all, invalid HTML 4.01). Calling XHTML "text/html" is still essentially broken. It's supposed to allow XHTML to be viewed with browsers that don't support XHTML, but it essentially removes the only advantage of XHTML - syntax checking.

It doesn't so long as it's a minority. When the overwhelming majority of the web uses XHTML, its draconian error handling that it inherits from XML will simplify browsers considerably.

It's always fun to take an "XHTML 1.0 site" and run it through an XML parser, see how far it gets before bombing. The "draconian error handling" essentially guarentees that it'll never take off, or even if it does, that most browsers will start allowing worse and worse XHTML.

That's completely wrong. Sure, you could make up your own semantics that you associate with the element types you use in your ad-hoc XML format, but nobody else would know about those semantics. That's why you use a common, specified XML format... like... XHTML

You do know that there are more XML schemas out there than just XHTML, right? There's no reason why you can't simply include xsi:schemaLocation and explain exactly what your XML contains. That's the entire point behind XML schemas. Theoretically, you can import various other schemas, so even if your site uses some custom XML markup, your schema can reference known other schemas and still make the data semantically meaningful.

However, suggesting that XHTML is magically more meaningful than a random XML document when it comes to semantics is just laughable. If you're trying to look at just the text, HTML offers various semantic meanings for the various tags. But if you want to go any further, like recognizing certain portions as addresses, XHTML offers no help. <div class="zipcode">1234</div> isn't any more semantically useful than <zipcode>1234</zipcode> - both require you to know the design of the specific document to be helpful.