That's different. Encryption ciphers have a pretty standard interface and can be plugged in modularly by the dozens.
This interpretation was not intent. Term "cipher suite" rather than "cipher" was used intentionally to include combinations of *all* parameters. I could have just as easily said *SRP*
Key exchange protocols need more customization, and extend the protocol at its most vulnerable spot, before both parties have the keys they need to communicate securely.
Negotiation parameters are checked retroactively after session establishment regardless. Peers would have to be configured to allow a cipher suite so broken as to be compromised in real-time during TLS handshake. If RSA could be compromised in this way it is hard to imagine a scenario where binding of trust from RSA to ephemeral key could fair any better.
What the TLS designers need to think about is how to reduce the options to one well understood choice.
Putting all of your eggs in one basket yields global disaster with unacceptable lag times to recovery when dropped.
It is not the designers responsibility. Rather education campaigns to assist application developer and operator community in selecting appropriate cipher suites and or more work in security stacks to provide generally applicable options.
So the complexity of ciphersuite negoitation, rekeying and all the other absurd complexity can be removed. TLS will not be fixed. It will be replaced.
KISS is great and all but it falls apart when you go that one step further and try to oversimplify.
Anyone can look at a specific problem and provide a *relatively* simple custom crypto solution to solve that one problem. I'm not so sure a world with proliferation of fragmented technologies is necessarily better than a single albeit more complex than you need framework. Perhaps for some it is... I don't know.
I think it is a mistake for IETF to make value judgments about mandating a lowest acceptable level of security. Not everyone is faced with the same problems or places the same value on specific aspects of security.
Ability to decode encrypted sessions after the fact could in some instances offer more value than risks associated with retroactive effects of key compromise. TLS after all has ability to negotiate ciphers offering no encryption at all while still offering integrity protection for data.
If your using TLS for an industrial control application perhaps there is no value in keeping commands issued secret yet there is extreme value in maintaining integrity of data so harmful commands can't be injected by an attacker. In this scenario forward secrecy has no value, and you lose the ability to retroactively validate data stream with ephemeral keys.
For troubleshooting, auditing and political considerations (like it or not leakage prevention is a multi-billion dollar industry) an organization may deem properties of forward secrecy to be more of a liability than an asset.
Also session tickets and ephemeral keys don't mix.
Obviously you want to provide the strongest generally applicable level of security by default in any specification or implementation however if you want to provide a technological solution *everyone* can use it by necessity needs to support full range of tradeoffs where reasonable. In this case I am not hearing the "reasonable" argument for deletion of these suites.
Reasons Joe cites for removal sound like typical IETF jargon used to provide technical cover for political decisions.
lack of PFS
by identity/choice
pre-master secret contributed only by the client
No, this is an independently addressable (non)issue.
and the general weakening of RSA over time
If RSA is weak then using RSA at all to impart trust upon ephemeral keys is a receipt for disaster. This reduces to the general argument for PFS which everyone should and is free and encouraged to use.
It would make the security analysis simpler
There must be what hundreds of cipher suites by now.. seriously... analyze the ones you see value in using and disable the rest. This makes as much sense as telling the Russians you are deleting suites with *gost* in them or Japanese *camilla* simply because they would be easier to analyze.
IPv6 by design will always be slower over the same wire, it has more packet overhead
I think in principal there should not be (much of) a difference yet wouldn't discount those who report otherwise in specific deployments. I've heard the 20% figure tossed around at IETF meetings with major vendors and operators in the room but it is only applicable to some Internet latency measurements not LANs.
There is some small performance benefit in IPv6 in form of removal of IP layer checksums and per-hop fragmentation having effect of reduced per-hop processing overhead.
While additional IPv6 header overhead is non-existant (~1%) at full MTU it can be significant (~20%) for realtime VoIP and games where per-packet payloads often 100 bytes.
Have a feeling there are more interesting factors involved with people seeing IPv6 to be faster for them. On LANs some offload features (e.g. large send offload) are notorious for creating odd performance issues... and such features may have different behavior or simply be unavailable for IPv6 having effect of significantly reducing latency. There may be ICMP filtering in place different from IPv4 providing active port availability feedback rather than timing out connection and naming resources. On IPv6 name resolution might leverage LLMNR over a slower option.
Over Internet it could be different routing or simply relatively less resource utilization across IPv6 specific elements.
Parents NSA garbage is particularly amusing considering biggest media and biggest ISPs whom we all assume to be most in-bed with NSA were the *first* to deploy IPv6. Not to mention significant effect on IPv6 ecosystem due to administrative mandate forcing all US government sites to be IPv6 accessible.
Hard to imagine a currency requiring central coordination to facilitate all transactions would be looked upon as anything other than wet dream of any government/military industry.
2. Now instead of the otherwise mature, reliable technology of a mechanical ignition lock system, we're going to have to worry about zero-day vulnerabilities in a complex system?
Yep and annoyingly trivial denial of service attacks against key fobs carried out by teens with nothing better to do.
The Google Keyboard for Android sends what you're typing to Google servers 'to improve suggestions,'
Google keyboard provides an option to turn the feature off so there is that.
so I don't think that asking for your location a lot
Is it asking for your location? Is a list of take it or leave it demands most apps make these days really asking a question?
is the worst invasion of privacy of a mainstream on-screen keyboard app.
Perfectly happy to declare all of these fine contestants winners of the privacy invasion contest. I must say proliferation of cheesy excuses to collect data is truly inspired. We need to know where you are at all times physically to configure a localization setting...yea that's it...
I don't have anything coherent to say. I'm so disgusted with lemmings and fads running amok in this industry I am not going to bother stating the obvious.
This kind of asshattery certainly on par with Microsoft spending millions in meetings and committee design to perfect the most inane location to place shutdown/logoff buttons.
In the end this "useful" feature was kicked because it was flawed from the ground up at least for a security focused use and iirc only OpenSSL provided an implementation of that specific protocol so it couldn't have been that useful.
Sentiment seems to reflect a failure to understand the difference between TLS and DTLS. On a relative basis nobody uses DTLS either not sure where this leaves the "useful" argument.
The biggest mistake in my view was deploying this feature at all for TLS as there was nothing to be gained by doing so. DTLS is a completely different matter and even there they could have used a more conservative default without inconveniencing anyone.
Not to forget that this feature could be freely accessed by just about anyone as it lacked authentication
DTLS layer Keepalives post session setup are integrity protected and can't be forged without defeating session encryption. Also clients and servers negotiate support for transmit and receipt during handshake and applications retain full control over whether they are to be used at all.
The guy who screwed up the implementation apparently also screwed up the specification with the same amount of missing and vague error handling (lack of error codes, vague explanations, missing limits, etc.).
Commit comments speak volume to authors misunderstanding of use case.
Although in the DTLS can be trivially implemented within the app rather than transport layer
The point is to provide useful UDP compatible semantics so **existing** UDP protocols are able to leverage DTLS. In the UDP world concept of an underlying session needing to be maintained prior to transporting bytes is non-existent.
For example syslog over DTLS is one-sided. Without ability to detect aliveness of encrypted session messages would be forever black holed if session died or NAT state expired.
Obviously if built from ground up you can implement anything. Use of keep-alive for MTU probe and encrypted session aliveness probe is ultimately better implemented in transport stack than having to be constantly reinvented by each protocol.
Pardon me, but the ideology of "Anthropogenic CO2-caused Global Warming" is not based on the "insulation" properties of CO2. Instead it is based on a physics-challenged notion of "trapping radiation", which is not how thermal insulation works.
I should also point out that sucking really isn't sucking. Air is not being "sucked" instead the creation of a vacuum causes surrounding air to expand out filling the pressure gradient.
Nuclear disarmament is hardly the result of hard work of advocates.
Instead it is the work of improvements in delivery/targeting technology, ongoing cost of stockpile maintenance nobody wants to bear and unnecessary risk of weapons getting into the wrong hands. There simply is no point in anyone stockpiling such absurd numbers of nukes anymore... resulting stockpile reduction agreements were predictable no-brainers.
Likewise if you want to move the needle WRT climate change you need to deliver alternatives which are no-brainers for consumers. Everything else is just tree hugging nonsense that will be ignored no matter what you say or do.
I'm shocked... large ISPs (e.g. Comcast) would never deliberately load links to point of saturation in a bid to leverage access to millions of captive eyeballs.
In all seriousness TFA misses the larger point. It is impossible and foolish to even try and legislatively correct distortions arising from provider and content monopolies. The only viable solution is to deny monopoly status and break up large providers into little byte sized bits.
If only you are able to keep everyone from getting too fat then the problem solves itself as normal market forces keep the BS in check.
Negotiating in public means absolutely nothing will get done because no one will dare cross the line and compromise. While in theory 100% transparency in gov't sounds like a good idea, in practice it's a recipe for gridlock.
Given never ending stream of attacks from media and LEA's gridlock is preferable to "progress".
OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.
Too bad, heartbeats are quite useful in DTLS context. Yanking useful features just because someone screwed up in implementation space is not a rational response.
Better to remain silent and be thought a corrupt fool in dire need of replacement than to speak and remove all doubt.
When people successfully create their your own exchange and sell consulting services to help investors avoid the HFT tax it is no longer in the realm of being a question. You are arguing against objective reality at that point.
What benefits does this offer to NASA, or to the scientific community at large, that isn't already offered by one or more existing satellites in LEO?
TFA has something to say about this:
But NASA does feel that the data that ISEE-3 could generate would have real value and that a crowd funded effort such as ours has real value as an education and public outreach activity.
This is like any NASA mission.. the person asking "what is the point of" is entitled to make their own value judgment regarding what is or is not worthwhile use of funds.
They know how much you use over the course of the month, but the vast majority of meters do not know when in the month you used the energy. These types of smart metering devices are extremely useful for utility companies planning for peak load values, and for developing predictive models of energy use in response to weather changes.
Meters exist for billing. Utilities have access to all kinds of utilization metrics collected from the infrastructure itself in real-time at any time resolution they feel like collecting for purpose of developing predictive models separate from meters. Data including transformer / transmission loss and voltage/phase/power factor you don't get from residential meters.
If you live next to Sub-Zero or Pikachu their abnormal energy utilization is smoothed out by neighbors. Unless your into smelting aluminum fine grained meter data is mostly worthless for planning.
However from a billing perspective it can provide insights allowing utility companies to maximize profits especially in areas where cost per kw changes throughout the day.
I can see arguments for increasing data = better decisions and optimizations of production resources.. yet in the real world over time I think it more likely to see data be used to maximize profits and minimize infrastructure investments to the detriment to consumers.
One analogy what if Internet was metered from the very beginning like old school cell data access rates? We would consume a lot less and as a result the build out of infrastructure supporting tens to hundreds of GB fiber links would have been significantly delayed due to lack of demand. Residential 100mbit broadband packages would simply not exist.
By inconveniencing the user you no longer feel pressure to invest in infrastructure and development of supporting technology such as temporary energy storage to buffer peak demand.
Seriously think about it. Every issue you have with extensible fields you would have with a new protocol, while by virtue of being fully backward compatible.
The core problem is all about ADDRESSING. What protocol headers look like is largely irrelevant.
Quibbling about approach x vs. y when both only result in different arrangements of fields appearing in a header very few actually touch is counterproductive.
Asserting "fully backward compatible" naturally implies maintenance of two separate address spaces given untouched gear would not be able to "do anything about" new unimplemented bits.
One might argue it would be better to deploy support for an extended address space and designate a flag day after which we would expect the new space to be globally open for business.. yet this isn't a serious option that can be deployed in the real world. It has to be done incrementally and at the end there has to be pressure on outliers to switch or be left in the dark.
Sure, all you do is you define the behavior but do not require the devices to actually do anything about it. Only later do you require the behavior to take place.
Don't know how one goes about asking the whole world to start "doing something about it" without incurring massive cost.
Every issue you have with extensible fields you would have with a new protocol
My assertion is playing games with protocol fields does not make deployment appreciably any different or better than IPv6.
What you suggest could have been done in IPv4 you could have used options field to define extended addressing without having to burn separate L2 protocol number. Yet we still would have had to touch everything which sees an address.
Most importantly to enable ADDRESSING of new space while maintaining a fully reachable network for all participants you still need to concurrently deploy parallel addresses in both current and extended address spaces for duration of transition period. This includes CGN to make up for lack of available address space.
When I connect to www.google.com my system does an AAAA query because it knows I have IPv6 connectivity. If the AAAA query returns an IPv6 address it also knows the remote system can be reached via IPv6. If there is no AAAA then it knows to use IPv4 instead. The incremental and easily understood rules for use of one address space over the other is a critical part of a successful transition.
Some of it is counter-intuitive requiring appreciation for operational requirements of content and eyeball networks. A number of smart and well-intentioned people invented all manner of transition technologies to help bridge communications between networks yet in the end they only got in the way hindering adoption.
While by virtue of being fully backward compatible you would avoid some of the worst issues of "flag day" IPv6, which we haven't yet managed to roll out 16 years after first proposed.
IPv6 is in production use by millions currently enjoying exponential growth. >40% of my Internet traffic by volume is IPv6.
Slashdot Mirror
Pure brilliance I love it. Never occurred to me .. even if it only has sentimental effect.
That's different. Encryption ciphers have a pretty standard interface and can be plugged in modularly by the dozens.
This interpretation was not intent. Term "cipher suite" rather than "cipher" was used intentionally to include combinations of *all* parameters. I could have just as easily said *SRP*
Key exchange protocols need more customization, and extend the protocol at its most vulnerable spot, before both parties have the keys they need to communicate securely.
Negotiation parameters are checked retroactively after session establishment regardless. Peers would have to be configured to allow a cipher suite so broken as to be compromised in real-time during TLS handshake. If RSA could be compromised in this way it is hard to imagine a scenario where binding of trust from RSA to ephemeral key could fair any better.
Maybe because RSA has proven time and again that they
In this context by "RSA" we're talking about use of prime numbers as basis for a public key cryptosystem rather than the company "RSA".
http://en.wikipedia.org/wiki/R...
What the TLS designers need to think about is how to reduce the options to one well understood choice.
Putting all of your eggs in one basket yields global disaster with unacceptable lag times to recovery when dropped.
It is not the designers responsibility. Rather education campaigns to assist application developer and operator community in selecting appropriate cipher suites and or more work in security stacks to provide generally applicable options.
So the complexity of ciphersuite negoitation, rekeying and all the other absurd complexity can be removed. TLS will not be fixed. It will be replaced.
KISS is great and all but it falls apart when you go that one step further and try to oversimplify.
Anyone can look at a specific problem and provide a *relatively* simple custom crypto solution to solve that one problem. I'm not so sure a world with proliferation of fragmented technologies is necessarily better than a single albeit more complex than you need framework. Perhaps for some it is... I don't know.
I think it is a mistake for IETF to make value judgments about mandating a lowest acceptable level of security. Not everyone is faced with the same problems or places the same value on specific aspects of security.
Ability to decode encrypted sessions after the fact could in some instances offer more value than risks associated with retroactive effects of key compromise. TLS after all has ability to negotiate ciphers offering no encryption at all while still offering integrity protection for data.
If your using TLS for an industrial control application perhaps there is no value in keeping commands issued secret yet there is extreme value in maintaining integrity of data so harmful commands can't be injected by an attacker. In this scenario forward secrecy has no value, and you lose the ability to retroactively validate data stream with ephemeral keys.
For troubleshooting, auditing and political considerations (like it or not leakage prevention is a multi-billion dollar industry) an organization may deem properties of forward secrecy to be more of a liability than an asset.
Also session tickets and ephemeral keys don't mix.
Obviously you want to provide the strongest generally applicable level of security by default in any specification or implementation however if you want to provide a technological solution *everyone* can use it by necessity needs to support full range of tradeoffs where reasonable. In this case I am not hearing the "reasonable" argument for deletion of these suites.
Reasons Joe cites for removal sound like typical IETF jargon used to provide technical cover for political decisions.
lack of PFS
by identity/choice
pre-master secret contributed only by the client
No, this is an independently addressable (non)issue.
and the general weakening of RSA over time
If RSA is weak then using RSA at all to impart trust upon ephemeral keys is a receipt for disaster. This reduces to the general argument for PFS which everyone should and is free and encouraged to use.
It would make the security analysis simpler
There must be what hundreds of cipher suites by now.. seriously... analyze the ones you see value in using and disable the rest. This makes as much sense as telling the Russians you are deleting suites with *gost* in them or Japanese *camilla* simply because they would be easier to analyze.
IPv6 by design will always be slower over the same wire, it has more packet overhead
I think in principal there should not be (much of) a difference yet wouldn't discount those who report otherwise in specific deployments. I've heard the 20% figure tossed around at IETF meetings with major vendors and operators in the room but it is only applicable to some Internet latency measurements not LANs.
There is some small performance benefit in IPv6 in form of removal of IP layer checksums and per-hop fragmentation having effect of reduced per-hop processing overhead.
While additional IPv6 header overhead is non-existant (~1%) at full MTU it can be significant (~20%) for realtime VoIP and games where per-packet payloads often 100 bytes.
Have a feeling there are more interesting factors involved with people seeing IPv6 to be faster for them. On LANs some offload features (e.g. large send offload) are notorious for creating odd performance issues ... and such features may have different behavior or simply be unavailable for IPv6 having effect of significantly reducing latency. There may be ICMP filtering in place different from IPv4 providing active port availability feedback rather than timing out connection and naming resources. On IPv6 name resolution might leverage LLMNR over a slower option.
Over Internet it could be different routing or simply relatively less resource utilization across IPv6 specific elements.
Parents NSA garbage is particularly amusing considering biggest media and biggest ISPs whom we all assume to be most in-bed with NSA were the *first* to deploy IPv6. Not to mention significant effect on IPv6 ecosystem due to administrative mandate forcing all US government sites to be IPv6 accessible.
When can we expect to order Mammoth burgers from Mc Donald's?
Hard to imagine a currency requiring central coordination to facilitate all transactions would be looked upon as anything other than wet dream of any government/military industry.
2. Now instead of the otherwise mature, reliable technology of a mechanical ignition lock system, we're going to have to worry about zero-day vulnerabilities in a complex system?
Yep and annoyingly trivial denial of service attacks against key fobs carried out by teens with nothing better to do.
If you aren't ready for advancements in technology then what are you doing reading this website?
Seriously.
Technology is a tool to get things done. Advancement in technology implies better tools to get things done easier/better/faster/cheaper.
Never confuse invocations of "new" or otherwise throwing of transistors at a problem for technological advancement.
The Google Keyboard for Android sends what you're typing to Google servers 'to improve suggestions,'
Google keyboard provides an option to turn the feature off so there is that.
so I don't think that asking for your location a lot
Is it asking for your location? Is a list of take it or leave it demands most apps make these days really asking a question?
is the worst invasion of privacy of a mainstream on-screen keyboard app.
Perfectly happy to declare all of these fine contestants winners of the privacy invasion contest. I must say proliferation of cheesy excuses to collect data is truly inspired. We need to know where you are at all times physically to configure a localization setting...yea that's it...
and drew some somewhat odd and conspiratorial-sounding conclusions about the ordeal.
What is odd about noting "dual use" nature of services used to conceal ones identity?
http://info.publicintelligence...
I don't have anything coherent to say. I'm so disgusted with lemmings and fads running amok in this industry I am not going to bother stating the obvious.
This kind of asshattery certainly on par with Microsoft spending millions in meetings and committee design to perfect the most inane location to place shutdown/logoff buttons.
Keep up the good work.
In the end this "useful" feature was kicked because it was flawed from the ground up at least for a security focused use and iirc only OpenSSL provided an implementation of that specific protocol so it couldn't have been that useful.
Sentiment seems to reflect a failure to understand the difference between TLS and DTLS. On a relative basis nobody uses DTLS either not sure where this leaves the "useful" argument.
The biggest mistake in my view was deploying this feature at all for TLS as there was nothing to be gained by doing so. DTLS is a completely different matter and even there they could have used a more conservative default without inconveniencing anyone.
Not to forget that this feature could be freely accessed by just about anyone as it lacked authentication
DTLS layer Keepalives post session setup are integrity protected and can't be forged without defeating session encryption. Also clients and servers negotiate support for transmit and receipt during handshake and applications retain full control over whether they are to be used at all.
The guy who screwed up the implementation apparently also screwed up the specification with the same amount of missing and vague error handling (lack of error codes, vague explanations, missing limits, etc.) .
Commit comments speak volume to authors misunderstanding of use case.
Although in the DTLS can be trivially implemented within the app rather than transport layer
The point is to provide useful UDP compatible semantics so **existing** UDP protocols are able to leverage DTLS. In the UDP world concept of an underlying session needing to be maintained prior to transporting bytes is non-existent.
For example syslog over DTLS is one-sided. Without ability to detect aliveness of encrypted session messages would be forever black holed if session died or NAT state expired.
Obviously if built from ground up you can implement anything. Use of keep-alive for MTU probe and encrypted session aliveness probe is ultimately better implemented in transport stack than having to be constantly reinvented by each protocol.
Pardon me, but the ideology of "Anthropogenic CO2-caused Global Warming" is not based on the "insulation" properties of CO2. Instead it is based on a physics-challenged notion of "trapping radiation", which is not how thermal insulation works.
I should also point out that sucking really isn't sucking. Air is not being "sucked" instead the creation of a vacuum causes surrounding air to expand out filling the pressure gradient.
Nuclear disarmament is hardly the result of hard work of advocates.
Instead it is the work of improvements in delivery/targeting technology, ongoing cost of stockpile maintenance nobody wants to bear and unnecessary risk of weapons getting into the wrong hands. There simply is no point in anyone stockpiling such absurd numbers of nukes anymore... resulting stockpile reduction agreements were predictable no-brainers.
Likewise if you want to move the needle WRT climate change you need to deliver alternatives which are no-brainers for consumers. Everything else is just tree hugging nonsense that will be ignored no matter what you say or do.
Hopefully in the future the world has increasingly little tolerance for closed platforms where a single vendor reigns over all execution.
I'm shocked... large ISPs (e.g. Comcast) would never deliberately load links to point of saturation in a bid to leverage access to millions of captive eyeballs.
In all seriousness TFA misses the larger point. It is impossible and foolish to even try and legislatively correct distortions arising from provider and content monopolies. The only viable solution is to deny monopoly status and break up large providers into little byte sized bits.
If only you are able to keep everyone from getting too fat then the problem solves itself as normal market forces keep the BS in check.
Negotiating in public means absolutely nothing will get done because no one will dare cross the line and compromise. While in theory 100% transparency in gov't sounds like a good idea, in practice it's a recipe for gridlock.
Given never ending stream of attacks from media and LEA's gridlock is preferable to "progress".
OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.
Too bad, heartbeats are quite useful in DTLS context. Yanking useful features just because someone screwed up in implementation space is not a rational response.
Better to remain silent and be thought a corrupt fool in dire need of replacement than to speak and remove all doubt.
When people successfully create their your own exchange and sell consulting services to help investors avoid the HFT tax it is no longer in the realm of being a question. You are arguing against objective reality at that point.
What benefits does this offer to NASA, or to the scientific community at large, that isn't already offered by one or more existing satellites in LEO?
TFA has something to say about this:
But NASA does feel that the data that ISEE-3 could generate would have real value and that a crowd funded effort such as ours has real value as an education and public outreach activity.
This is like any NASA mission.. the person asking "what is the point of" is entitled to make their own value judgment regarding what is or is not worthwhile use of funds.
They know how much you use over the course of the month, but the vast majority of meters do not know when in the month you used the energy. These types of smart metering devices are extremely useful for utility companies planning for peak load values, and for developing predictive models of energy use in response to weather changes.
Meters exist for billing. Utilities have access to all kinds of utilization metrics collected from the infrastructure itself in real-time at any time resolution they feel like collecting for purpose of developing predictive models separate from meters. Data including transformer / transmission loss and voltage/phase/power factor you don't get from residential meters.
If you live next to Sub-Zero or Pikachu their abnormal energy utilization is smoothed out by neighbors. Unless your into smelting aluminum fine grained meter data is mostly worthless for planning.
However from a billing perspective it can provide insights allowing utility companies to maximize profits especially in areas where cost per kw changes throughout the day.
I can see arguments for increasing data = better decisions and optimizations of production resources.. yet in the real world over time I think it more likely to see data be used to maximize profits and minimize infrastructure investments to the detriment to consumers.
One analogy what if Internet was metered from the very beginning like old school cell data access rates? We would consume a lot less and as a result the build out of infrastructure supporting tens to hundreds of GB fiber links would have been significantly delayed due to lack of demand. Residential 100mbit broadband packages would simply not exist.
By inconveniencing the user you no longer feel pressure to invest in infrastructure and development of supporting technology such as temporary energy storage to buffer peak demand.
Seriously think about it. Every issue you have with extensible fields you would have with a new protocol, while by virtue of being fully backward compatible.
The core problem is all about ADDRESSING. What protocol headers look like is largely irrelevant.
Quibbling about approach x vs. y when both only result in different arrangements of fields appearing in a header very few actually touch is counterproductive.
Asserting "fully backward compatible" naturally implies maintenance of two separate address spaces given untouched gear would not be able to "do anything about" new unimplemented bits.
One might argue it would be better to deploy support for an extended address space and designate a flag day after which we would expect the new space to be globally open for business .. yet this isn't a serious option that can be deployed in the real world. It has to be done incrementally and at the end there has to be pressure on outliers to switch or be left in the dark.
Sure, all you do is you define the behavior but do not require the devices to actually do anything about it. Only later do you require the behavior to take place.
Don't know how one goes about asking the whole world to start "doing something about it" without incurring massive cost.
Every issue you have with extensible fields you would have with a new protocol
My assertion is playing games with protocol fields does not make deployment appreciably any different or better than IPv6.
What you suggest could have been done in IPv4 you could have used options field to define extended addressing without having to burn separate L2 protocol number. Yet we still would have had to touch everything which sees an address.
Most importantly to enable ADDRESSING of new space while maintaining a fully reachable network for all participants you still need to concurrently deploy parallel addresses in both current and extended address spaces for duration of transition period. This includes CGN to make up for lack of available address space.
When I connect to www.google.com my system does an AAAA query because it knows I have IPv6 connectivity. If the AAAA query returns an IPv6 address it also knows the remote system can be reached via IPv6. If there is no AAAA then it knows to use IPv4 instead. The incremental and easily understood rules for use of one address space over the other is a critical part of a successful transition.
Some of it is counter-intuitive requiring appreciation for operational requirements of content and eyeball networks. A number of smart and well-intentioned people invented all manner of transition technologies to help bridge communications between networks yet in the end they only got in the way hindering adoption.
While by virtue of being fully backward compatible you would avoid some of the worst issues of "flag day" IPv6, which we haven't yet managed to roll out 16 years after first proposed.
IPv6 is in production use by millions currently enjoying exponential growth. >40% of my Internet traffic by volume is IPv6.