Slashdot Mirror

If it's good enough for RFC 5321, it's good enough for me.

For "wide-area" and other proxy service for mDNS and DNS-SD, Stuart Cheshire (from Apple) is trying to standardize it at IETF: https://tools.ietf.org/html/dr... . Hope it can help make it more widespread.

Oh GOD!! Then we will never be able to rid ourselves of the scour that is APPLE!!

For "wide-area" and other proxy service for mDNS and DNS-SD, Stuart Cheshire (from Apple) is trying to standardize it at IETF: https://tools.ietf.org/html/dr... . Hope it can help make it more widespread.

Quiz: A client wants to connect to a remote endpoint without a passive network observer being able to learn the identity of the endpoint. Is this "malware talking to the control server" or "banned application attempting to evade ISP-enforced censorship"?

Well obviously it's neither/both because there is no damned difference. As far as the transport layer is concerned, an application is an application. If you make it a desirable property that clients can conceal the true identity of the remote endpoint then you sweep in both.

Maybe this will change if we get adoption of RFC 3514 though.

Point to a broadly supported RFC with service available from a wide range of trusted organizations, and not some unique solution (which I've already linked to), and then you can legitimately claim that "encrypted DNS already exists."

As you're no doubt aware, RFC 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, is primarily designed to prevent TCP SYN flood attacks. It is less beneficial for ICMP and UDP flood attacks.

Ignoring zone transfers the majority of DNS traffic, especially the problematic DNS Amplification Attacks, use the UDP protocol not the TCP protocol.

This is about the only situation where IP over carrier pigeon might be reasonably successful.

You forgot Avian Carriers: https://tools.ietf.org/html/rf...

Wrong on all counts. Krebs wrote *about* the method yesterday, but Punycode is far older: https://tools.ietf.org/html/rf... (A. Costello, March 2003).

Furthermore, you have it exactly backward: Chrome/IE/Edge DO display the non-Latin URL as Punycode (that is, rendered into normal ASCII gibberish). Firefox just displays it straight.

Perhaps the burden is on lewd content to identify itself (binarily, despite an obvious spectrum).

We could extend IPv4 and IPv6 to include a porn bit.

Because too many network admins don't bother to read and implement BCP 38 on top of too many network admins leaving memcached servers publicly accessible.

This algorithm enables the little guy, and is eventually fair to all. https://tools.ietf.org/html/rf...

The government didn't force banks to use ActiveX. It forced them to use South Korea's homegrown encryption algorithms. For a long time an ActiveX control was the only off the shelf way to deploy those algorithms. They have since been added to TLS and are natively supported by all major browsers by now.

It's only a matter of time before someone invents a pigeon coin based on RFC 1149

As Google, Facebook and Amazon have gobbled up more of the Internet

But you're missing the entire point here. That's not a technical failure. There isn't some line of code that went wrong or some flaw in OSI that caused that. That's how capitalism works. Build a new browser and it'll just become the next IE, Chrome, whatever, five - six years down the road.

Well, Google controls how most people find things on the web and a browser that controls how they see it.

You've got duckduckgo.com and firefox.com. You are welcome.

Amazon hosts a large percentage of web sites through AWS

Again, not a technical issue, that's a "I'm lazy as fuck to fire up or my boss is too cheap to buy a machine that I can touch and connect to the Internet directly." This kind of mentality is a tick-tock thing on long enough scales. Give it maybe another ten or so years and we'll be right back on the tock side of things.

Facebook is the dominant social network where people communicate with each other

THEN STOP FUCKING USING IT! Trust me, you'll feel a whole hell of a lot better. Shit you might even sleep better at night. I told everyone on Facebook they can call, email, snail mail, whatever but honestly I don't give a shit about your one like equals one prayer BS, and I have never looked back. It's that simple, just stop using it. I know people are all like, "but what about Aunt Rosey or..." No, no, no, no, you're thinking too much on this. Just... S-t-o-p using it. That's all.

Now that Net Neutrality is dead, ISPs now can control who goes over those pipes.

ISPs have been controlling what goes over those pipes which is why we needed NN in the first place. It's disappearance isn't the hearkening of some new dark era of the Internet, it's the return to the brain dead, the dollar is first, nickel and dime story that we use to have. It'll also more than likely be the thing that drives people to download once and store on hard media at home for local consumption (tick-tock).

The concern is real

Yeah, and I'm not saying you're wrong, the problem is that the problem isn't what you think the problem is. The problem is people being greedy as fuck and there isn't a technical means to stop human beings from being idiotic dumb fucks of human beings. Except, I will admit that I am keen to one purpose solution to the problem.

I have some good news for you: you don't need to pay $15/year for an SSL cert. There is at least one CA providing certs for free, via a generic and open protocol called ACME.

A few years ago you would have had a point, but not today.

Well there is a RFC for SONET to sonnet translation from the bard himself https://tools.ietf.org/html/rf...

Click on the link. The title is "The Secure Shell (SSH) Transport Layer Protocol". That is the name if the secure transport layer that SSH uses. SSH uses SSH-TRANS as a transport layer, and doesn't use SSL or TLS for anything. You asked for the specs for the SSH encryption mechanism, and you got them, so don't complain.

Here's another link: RFC 4251 - The Secure Shell (SSH) Protocol Architecture. That explains how the various parts of SSH work together. Here's an excerpt:

1. Introduction

      Secure Shell (SSH) is a protocol for secure remote login and other
      secure network services over an insecure network. It consists of
      three major components:

        - The Transport Layer Protocol [SSH-TRANS] provides server
            authentication, confidentiality, and integrity. It may optionally
            also provide compression. The transport layer will typically be
            run over a TCP/IP connection, but might also be used on top of any
            other reliable data stream.

        - The User Authentication Protocol [SSH-USERAUTH] authenticates the
            client-side user to the server. It runs over the transport layer
            protocol.

        - The Connection Protocol [SSH-CONNECT] multiplexes the encrypted
            tunnel into several logical channels. It runs over the user
            authentication protocol.

      The client sends a service request once a secure transport layer
      connection has been established. A second service request is sent
      after user authentication is complete. This allows new protocols to
      be defined and coexist with the protocols listed above.

      The connection protocol provides channels that can be used for a wide
      range of purposes. Standard methods are provided for setting up
      secure interactive shell sessions and for forwarding ("tunneling")
      arbitrary TCP/IP ports and X11 connections.

Encryption is handled by the lowest layer of SSH, SSH-TRANS - the secure transport layer, which in turn is typically implemented directly on TCP. No SSL or TLS involved.

The highest later, SSH-CONNECT, is used for whatever kind of connection you want from SSH. This can be a command line, or you could remotely use graphical applications through X forwarding, or you could forward ports or tunnel pretty much and TCP stream.

RFC 4253

Tunelling happens at the SSL/TLS layer. SSH is a protocol that leverages SSL (old school) or TLS (new school) to perform the tunneling.

Wrong. I've already told you that SSH doesn't use SSL or TLS at all. Encryption and tunnelling is all handled within the SSH protocol itself. Here is the RFC for the SSH transport layer protocol, which describes how it works.

Au contraire Blackadder.

Where we're going, we don't need cables...
https://tools.ietf.org/html/rf...

yeah, I try to stay out of the politics & stick to the technical realities. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers https://tools.ietf.org/html/rf...

QoS & neutrality are mutually exclusive. QoS is what manages traffic congestion that would otherwise break the interwebz. Net neutrality, while politically popular, is not technically desirable. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers https://tools.ietf.org/html/rf...

Porn, Netflix, Emergency 911 VoIP calls... Net Neutrality says to treat them all the same. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers https://tools.ietf.org/html/rf...

It's all defined in the contracts with the ISP. You expect your ISP to honor and provide the CiR agreed to in the contract. The way it's done is by classifying traffic, which necessarily implies no neutrality. RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers https://tools.ietf.org/html/rf...

You have to classify traffic to prevent congestion. Congestion will break the interwebz. As soon as you're classifying traffic, which is already happening, you have no neutrality If you want a simple example of how neutrality breaks shared and limited resources, remove quotas from your file system or schedulers from CPU resource management.

https://tools.ietf.org/html/rf...

Please don't be a moron. Proper network traffic management is perfectly ok under NN. Networks have to have traffic controls, you just can't have a network without it. ISPs already tried to put this forth as a reason for no NN. Where NN comes in is what traffic management ISPs are allowed to do. Doing it for network health and usability is perfectly ok. Giving some customers preferential treatment? No.

Learn the difference, stop spreading misinformation.

You have to classify traffic to prevent congestion. Congestion will break the interwebz. As soon as you're classifying traffic, which is already happening, you have no neutrality If you want a simple example of how neutrality breaks shared and limited resources, remove quotas from your file system or schedulers from CPU resource management. https://tools.ietf.org/html/rf...

I'm not going to do all your homework but you can start here. [comodo.com]

And, of course, you link to a completely unrelated document detailing one company's policy regarding issuing certificates. That page does link to a couple of standards documents (ratified RFCs), but neither of them support your position. Of course, I point this out, hoping that you simply linked the wrong URL and still might educate me further on this issue. In the end, I'm disappointed, of course.

The .dev TLD is not available. [...] It is no different than if you try to tie a .com address to a local address.

You go on about .dev although I've not mentioned .dev once at this point. You also continue limiting to .dev and .com and make yet another incorrect statement regarding tying (pointing) a domain to a local address. Still waiting on the standards document that disallows this.

You just confirmed that .dev isn't available and so you can't use it.

I never claimed otherwise; but you confirmed, there, that you thought I had. How, exactly? Since you read and understand perfectly what people write (even if they're not writing what they think they are), as you imply in the post you just wrote, surely you noticed that I hadn't mentioned .dev at all until just then. Clearly, I wasn't arguing anything relating to .dev.

No, I'm saying you still don't grasp what is going on. [...] For domains you own, so a VERY limited subset of .com, you can do that [...] I think you get that and we just got our signals crossed.

I don't grasp what is going on? Oh, no, I've gotten that you're a Slashdot troll since way before this particular conversation started. You've missed that I enjoy baiting the trolls here, it keeps me sharp. You also just changed your position yet again; remember when you said "you should not use .com for internal machines", "The .com and .dev TLDs are controlled by ICANN, who issues them and ties them to a public IP address", "All ICANN assigned TILes are for public hostnames, and should never resolve to hosts in the private IP range", and "It is no different than if you try to tie a .com address to a local address"? Now you're admitting that all of those statements are false and expecting me to carry on as though you never said them and I was the one who was wrong this whole time? No. Admit you were wrong, it's a learning experience and it's good for you. I do it all the time (though, less and less on Slashdot, lately); it's actually the first step in correcting an incorrect understanding of a subject. You can't very well let go of incorrect beliefs, even if you acknowledge the beliefs someone else expounds are in fact correct, if you can't admit that your beliefs are incorrect. You've just contradicted everything else you've said to this point so, clearly, one set of beliefs you are expressing is incorrect. Decide which it is and admit it.

And of course I get it, it's what I've been saying this whole time. Thus, I didn't get anything crossed; but you, very clearly, did.

As for the standards, see RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Specifically, note the complete lack of restriction on where a domain may be used, whether or not it is ICANN-managed and whether or not you own it. Read all 25 updates if you want to be extra sure, and go ahead and read all the updates to those, and so on, and so forth.

If I'm missing something, well, I've been asking you to point it out for the last 5 posts. 6 if you count this one. Which ratified RFC describes the standard you were previously claiming exists?

thank you. I meant localhost - my network admin read the papers and implemented it. I just knew not to use un-used domains because - someday they'll get used - so he figured it out. Plus the lab was off the grid - but we still allowed a select few sub-domains or specific servers to resolve (like our upstream WSUS server) via forward references on the private DNS server and get out through the firewall. .local appears to be the mDNS https://tools.ietf.org/html/rf...

And you will run into "conflict and confusion" if you do this. As I've pointed out already, there was an RFC for this in 1999. The "right" way to do this has been defined for almost two decades. So you can either be self-righteous and declare that it's your local network and you'll do what you want (in which case, you should probably disconnect it from the internet) or you can follow the well-defined standard and avoid difficulty. https://tools.ietf.org/html/rf...

Apparently neither the OP nor the mods understand how DNS works. If you have internal resources, use the TLDs reserved for this purpose. The RFC was published in 1999! https://tools.ietf.org/html/rf...

And CERT has warned against using your own internal made-up top level domains...

https://isc.sans.edu/forums/di... ...which is why there's an RFC listing reserved top level domains you can safely use:

https://tools.ietf.org/html/rf...

https://tools.ietf.org/html/rf...

We are also looking for hunters in the area to simulate dropped packages.

Why do they need to shout "Hey, here are all the access points that I have connected to in the past"?

It's part of the spec, not so much wifi specifically but DHCP and DNA protocols.

The idea was when you first connect to a wifi network, you use ARP at layer 2 and broadcast a DHCP request to get a valid IP to begin using layer 3.
When you are disconnected "briefly" and reconnect later, that IP is likely to still be valid for use.

Using DNA (direct network attachment), you can broadcast the previously used router MAC, device MAC, and SSID to verify you are on the same local link, and can begin reusing your previous IP without having to wait for a DHCP renewal.
If you send an ARP with the remembered MACs, and get a reply, something else is now on the IP you had and you must renew with DHCP to get another IP.
If you don't get a reply, its generally safe to assume it.

I presume it was assumed this would be a common and desired situation. Walking around in and out of wifi range, or maybe allowing the radio to go into a sleep mode where it basically is off and thus detached from the network, this does let you reconnect a bit faster.

I also presume the security implications were just not thought of or cared about.

https://www.ietf.org/rfc/rfc4436.txt

If there's no IRC client currently installed on a particular device, there isn't much other option.

Yes, there is. Especially with the current plethora of platforms which do rather similar stuff.

Say you're logged into a PC owned by a public library using the patron ID on your library card, and you want to use this PC to connect to an IRC server. Without administrative access to this PC, how do you arrange for the installation of a native client?

Say you've received a FaceTime invitation from a person with whom you wish to communicate, but you don't own a sufficiently recent Mac, iPhone, iPad, or iPod touch. Instead, your primary PC runs X11/Linux or Windows, and your primary mobile device runs Android. How do you communicate with this person?

The D2 system on Slashdot uses JavaScript.

Thats a prime example. Why (does it use JS) ? Composing a reply is a rather non-interactive activity.

Choosing which replies to expand and collapse is interactive.

And maybe you should not be buying devices which cannot do what you cannot do without ? :-)

If you had a good reason to run six applications, each exclusive to a different operating system, would you buy six devices, one to run the operating system for each of these applications? Many operating systems cannot be installed on generic hardware for legal or technical reasons, such as macOS and mobile phone operating systems.

You're warned everywhere not to open random email attachments and/or running executables from unknow sources, but in the case of JS there still is an "just download everything and run it" attitude (pushed by website designers).

There's more sandboxing with JavaScript than with the native executables that email worms used.

Most users would find a seconds-long throbber for only the part of the document that has changed less jarring than a seconds-long throbber for the entire document.

I think you are mixing up latency with bandwith there ...

Not necessarily. As long as the rest of the user interface of a single-page web application remains visible during loading, the user is more likely to accept the latency than if the application's interface were to disappear during loading (which is the case for script-free navigation and forms). In addition, TCP's slow start keeps a new connection at low bandwidth until it has received a few packet acknowledgments (or "acks"), and these acks take a while to come back on a high-latency connection. In the terminology of RFC 2488, satellite has a high "delay*bandwidth product" (DBP), which standard TCP limits to 65.5 kB (64 KiB).

Even on a 10Mbit line you would be able to download a respectable HTML page (below a meg) in less than a second.

A lot of the data links to which I refer are far slower than 10 Mbit. A single TCP connection with the standard 64 KiB window and the 560 ms minimum ping of satellite won't be able to exceed 0.9 Mbit. On a 1 Mbit link, 100 kB of changes load in 1 second, but 100 kB of changes and 900 kB of redundant unchanged data load in about 10 seconds. In addition, at a typical cellular data transfer price of $10 per GB, it costs one cent to load a 1 MB document, but ten 100 kB change sets fit in the same cent.

Cookies were added in HTTP/1.1 (RFC 2068) in 1997 after two years of specification development. Lots of things about cookies were naively permissive, but it took years to realize this. HTTP/2 (in 2015) did nothing to address cookie flaws.

And that's the problem with this proposal. IoT doesn't get updated because of a lack of standards for doing so (there's been firmware-update standards around for a lot longer than IoT, e.g. this one), but because the vendors don't care about it, or the device can't be updated. Proposing a standard isn't going to change this.

In any case this isn't a standard, it's a bunch of ruminations jotted down on paper. To be a standard, it has to be at least 100 pages long, include XML, HTTP, TCP, and LDAP, and require five different parsing engines for different portions of the protocol in order to work.

However if crypto toolkits would finally implement and actually validate certificates using "DNS-Based Authentication of Named Entities" (DANE), then all of this is moot since the DNS operator for a site would be able to specify which specific TLS key is being used by the site with a few DNS records. A government entity wouldn't be able to man in the middle a TLS connection without either cracking the TLS keys themselves or by compromising the the root DNS server keys.

Google invented a technology that does everything HPKP did, and also handles key rotations, allows you to monitor for someone else issuing keys in your name, doesn't have the "HPKP ransom" vulnerability and actually scales well. You should read about certificate transparency and the Expect-CT header.

It's really gauche to accuse Google of doing anti-security things when they're single-handedly advancing the state of the art and have caught state actors breaking PKI. In fact that's the incident which led Google to invent HPKP in the first place, and they knew the problems with it at the time which is why they then went on to invent certificate transparency to replace it.

Did you read the proposal? https://tools.ietf.org/html/dr...

PKI is being applied for end-to-end security (i.e.:signing the payloads and verifying them before install) so that the payloads can be transported over insecure HTTP, USB keys, etc. without compromising them (including broadcast updates).

While I'm not against securing the payloads with PKI there are three glaring problems with the proposal in this regard:

1. They don't recommend timestamping the PKI signatures. Without timestamps the payloads are only usable for as long as all keys in the chain are *not* expired. With timestamps the keys and payload are guaranteed valid at the point of timestamping and can continue to be used for installation after one or more keys in the chain have expired.
2. They recommend rejecting updates if they are older than the active firmware. This prevents security researchers from installing older versions for pentesting and regression analysis.
3. They fail to recommend a path for users installing their own PKI private keys so that they can install their own firmware. This means IoT devices will only be useful for as long as manufacturers provide updates. Look how well that works for owners of Lenovo devices - typically Lenovo provides NO UPDATES EVER for any of their Android devices.

Ah, finally a production implementation of RFC-2549...

I present to you RFC 2070 which extends the HTML 2.0 spec to use Unicode, and has since been included in HTML 3, 4, and 5.

In January of 1997 that happened.

This is a web site, is it not? It renders HTML, does it not? Have they not actually developed anything on it since 1997? Or are they just carrying around 20 years of technical debt because of stupid excuses like "its [sic] an english language site"?

Also, the apostrophe is a punctuation mark in the English language.

ZRTP: Media Path Key Agreement for Unicast Secure RTP

To all Cell towers - make all towers neutral infrastructure, true "unlimited", no slowing, no shaping, no tiers, no caps, no massive customer wallet raping.
When a "speed" is sold, that speed is "absolute, rock-bottom minimum" 24x7x52 not "up to".
Any signs of tampering by the ISPs or backbone carriers will ensue a minimum 50k fine

I read the Net Neutrality paper rule when it was released. Edge servers can throttle network traffic. Better known as BGP's https://tools.ietf.org/html/rf...

That would be:

• Internet Protocol
• Transmission Control Protocol

Both of which are abused heavily by DPI and data injection, and outright violated by port and traffic blocking. That leaves prioritization, which is not a bad thing if it's done correctly. In fact, it's plainly part of TCP (See page 4, under "Precedence and Security" and page 12, with the same subheading, in RFC 793 linked above). But the big ISP's want to screw over prioritization by basing it, not on technical need, but on payment. This is clearly against the intent of these RFC's.

If I had the chance, I'd present this exact argument to SCOTUS in the hope that they begin accepting RFC's as a sort of tech-law. They're actually quite likely to do so. And the tone of all of the IETF documentation is quite direct, but in a jovial way. It's calming. It wins friends and influences people. That can be worth a lot in a forum like SCOTUS.

That would be:

• Internet Protocol
• Transmission Control Protocol

Both of which are abused heavily by DPI and data injection, and outright violated by port and traffic blocking. That leaves prioritization, which is not a bad thing if it's done correctly. In fact, it's plainly part of TCP (See page 4, under "Precedence and Security" and page 12, with the same subheading, in RFC 793 linked above). But the big ISP's want to screw over prioritization by basing it, not on technical need, but on payment. This is clearly against the intent of these RFC's.

If I had the chance, I'd present this exact argument to SCOTUS in the hope that they begin accepting RFC's as a sort of tech-law. They're actually quite likely to do so. And the tone of all of the IETF documentation is quite direct, but in a jovial way. It's calming. It wins friends and influences people. That can be worth a lot in a forum like SCOTUS.

The problem with the expires header (or any HTTP header) is that it needs to be requested from the client side.

Cite a reference, please. The Expires header is an optional response header and has no request controls (i.e.: it's application-specific). You're probably confusing it with the Cache-Control headers. https://tools.ietf.org/rfcmark...

Modded +5, Informative, but both of its statements are inaccurate. .localhost is reserved for 127.0.0.1 and no other thing. .invalid is reserved for NO use, it should never resolve.

https://tools.ietf.org/html/rf...

Localhost:
Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

Invalid:
Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).

Neither of these are meant for use on a local internet. .localhost is meant to resolve to loopback, and .invalid is meant to never resolve but instead give NXDOMAIN.

Maybe there are domains reserved for private usage, but it ain't these two.

You know your comment is moot if you quote the entire sentence, right?

why are you doing web development without HTTPS unless you're planning on never using it?

If you're using multicast dns, why are you using .dev instead of .local, as is part of the mDNS RFC?
https://tools.ietf.org/html/rf...

If you're not using the Google sponsored .dev gTLD, this doesn't impact you at all.
They bought the rights to control who's allowed a .dev domain. Just like you need to abide by certain rules if you want to use .aero or lawyer, etc. Perhaps a condition of using .dev is to only host HTTPS web servers? I haven't looked in to it.

You should be using .test domains - that's recommended practice by W3C https://tools.ietf.org/id/draf....

The .dev domains, on the other hand, are valid gTLD and are owned by Google. It's not surprising that Google wants to force HTTPS on a gTLD that they own.