Mozilla plots TLS 1.3 future for Firefox Mozilla has decided it needs to lift its HTTPS game, and will default to TLS 1.3 in next year's Firefox 52. Mozilla principal engineer Martin Thomson let developers know about the decision in an e-mail last Friday. “TLS 1.3 removes old and unsafe cryptographic primitives, it is built using modern analytic techniques to be …
it is vulnerable to replay attacks, but the standard will include information about mitigation and kinds of data client can send in the 0-RTT.
So yes, it's correct that your spider senses are tingling, and unless you're a real Time To First Byte junkie, you're better off not using it. Especially as browsers will need to figure out what is 0-RTT viable or not.
It's all very well rushing ahead with new protocols, but it only encourages the payment card industry to insist they are implemented while major players can drag their feet. For instance, Apple only implemented TLS1.2 in their mail client a couple of months ago, while PayPal still haven't implemented it in some of their mail servers, but it's been a requirement to pass a PCI scan for well over a year.
Sometimes, people can't be bothered. Consider the EMV requirement that was SUPPOSED to have enforceable liability backing since the beginning of the year. And yet how many firms STILL insist on swiping? Think about it, the threat of LOSING MONEY, and they STILL won't switch.
I think that's because DANE has problems of its own: namely because DNSSEC uses old ciphers (like a signed root that uses 1024-bit RSA when the minimum standard is I think 4096-bit) that browsers like Chrome are trying to retire. Not worth jumping out of the frying pan only to end up in the fire.
DNSSEC does not use "old" ciphers, or any ciphers. A cipher encrypts, DNSSEC does not encrypt. Stop spreading your ignorance. DNSSEC uses cryptography for validation, not encryption. Learn the difference.
There are two kinds of private keys with DNSSEC - a Key Signing Key (often referred to as KSK) and a Zone Signing Key (often referred to as ZSK)
A KSK is typically 2048-bit and is on the root server and the TLDs I have looked at. A KSK is generally rotated once a year but there is no official requirement.
A ZSK is typically 1024-bit and is typically rotated once a month (sometimes once a week) - you are not going to brute force a 1024-bit private signing key in a month. Or even six months.
DNSSEC also has ECDSA keys available, and once more recursive resolvers and DNS-aware applications support them, they will start to be used providing even stronger cryptography with smaller signatures.
DNSSEC does not have problems, nor does DANE. DANE provides higher confidence that the server you are talking to is who it claims to be than a CA signed cert does.
"A ZSK is typically 1024-bit and is typically rotated once a month (sometimes once a week) - you are not going to brute force a 1024-bit private signing key in a month. Or even six months."
Two words: Shor's Algorithm. Don't assume the State doesn't have a working high-qubit quantum computer humming away as a black project (such as under that data center in Utah).
Given such a paranoid world, why stick with such short keys at all? Why not make 4096 the LOW end and go from there?
4096-bit keys result in much larger signatures, which would increase the bandwidth needed for the RRSIG records and the cycles needed for validating the signatures.
Sorry, but real world considerations take priority over black box paranoia that has zero evidence of existing.
If you want stronger signatures, ECDSA is the way to go, and is the direction DNSSEC is headed. 4096-bit RSA is the wrong solution.
.deb packages The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
