On Sat, Jan 4, 2014 at 4:31 AM, Patrik Fältström <paf@xxxxxxxxxx> wrote:
I do not agree regarding the term "unlimited".
On 4 jan 2014, at 09:29, Jari Arkko <jari.arkko@xxxxxxxxx> wrote:
>> One important change is that every future application protocol proposal should be required to have an effectively unlimited code space for assignment.
>
> Agree.
What is needed is that the specification do have a consequence analysis regarding expansion of use.
Please read my words as carefully as a wrote them.
There are excellent reasons why variable length IPv6 addresses would have been a bad idea. That is why I separated considerations for IP layer, DNS and Applications.
At the application layer, the concerns are very different. Variable length identifiers are not a problem. We use them in RFC822, ASN.1, XML and JSON.
The only protocols above the bare IP layer where we don't use variable length identifiers are IPSEC and TLS. But these are merely design mistakes not to be repeated. Using fixed length identifiers in those protocols has negligible performance advantages but even a 32 bit identifier space is not big enough to make it a free for all. And so a technical choice creates an ongoing administrative requirement.
The problem in TLS is worse because the algorithms are joined together in suites and so there is a combinatorial issue. Since we have a key exchange cipher, an encryption cipher and a MAC for each we actually have an average of ten bits 32/3 per cipher. I can easily see us exhausting that.
What I would like is some architectural guidance from the IAB to the effect that all future protocols MUST use an identification mechanism that puts exhaustion of code points beyond the realm of practical possibility.
Since we are unlikely to be doing IPv7 any time soon and if we did it would be a whole new ball game, this requirement would only apply to major revisions of DNS, IPSEC, TLS like things and Application protocols.
I don't see an argument right now for a major revision of DNS. But if we were to revisit it in a backwards incompatible way we would surely change the protocol so that the number of possible resource records was more than 64K. The practical impact of the requirement is that the increase would have to be from 64K to 'effectively unlimited' rather than to 4G (32 bits).
For other protocols the consequence would be to use one of the following:
1) Pseudo identifiers of 128 bits (or more), i.e. UUIDs
2) ASN.1 Object identifiers
3) Simple text labels (e.g. AES-128)
4) URIs
IP addresses will always be a special case because they have to operate under some special constraints. We all use the same code point for text/plain but we all have to use a different IP Address.
To respond to some points made by John and others later in the thread, mere issue of a code point should not imply endorsement. I don't think that the IETF should be in the business of endorsing cryptographic algorithms or content types. There are certain cases where the IETF needs to be involved in identifying the authoritative definition though. Is the definitive definition of AES a document by NIST or someone else? Does Adobe define application/pdf or ISO? (these are not questions I am asking, they are illustration of the questions that IETF/IANA needs to answer).
I can certainly see potential for a situation where we start using some open source content type and there is a fork where two different groups claim to be the successor in interest and one true guardian of the spec.
For crypto, the situation is a little simpler and a lot more complicated than assumed. The standards are in practice defined by running code. And that code behaves in very particular ways.
If I add a crypto module to Windows (or most other well designed crypto platforms), it will become available to all the applications running on that platform. Which is all well and good of course. One consequence of this is that the way S/MIME uses AES and the way TLS uses AES have to be compatible. Otherwise large amounts of application code would need to be rewritten to special case each algorithm. And not having to do that is the objective of having a standard.
Fortunately the amount of variation possible is very small. There is the byte ordering for keys and a few other endian issues that might be underspecified or confused in the specs. But that is all. If an algorithm needs more than that then it is not ready for use and should be discarded (and new code points issued for the replacement).
What we do today is that we micromanage the process in ways that are counterproductive. People write documents describing how to use the <splunge> algorithm with IPSEC and S/MIME but any given platform is going to have code based on one or the other. What appear to be two independent specifications are in fact two variants of one specification since any deviation between the two documents is unambiguously an ERROR.
Website: http://hallambaker.com/