Paul wrote:
It is important enough, the problem is we don't want to a back port to cause regression or other sidee effects, and to me that is the scariest thing about the SNI patch(es).
There might be a compromise position here: As long as the SNI patch causes no problem to other services, this could be ok. If later on SNI users had to put up with some fast fixes, this wouldn't be so much of an issue.
Serious users of TLS (e.g., banks) won't be using SNI for a while. It is the grass roots people, the LAMPS vhost people, that we want to get into TLS. Right now they are not. Getting them into TLS/SNI even with a few potential scary events, is still a huge win.
(Indeed, if TLS/SNI is thought to be wobbly by the mainstreet TLS operators for a while, that's fine.)
Normally, this aggressive approach might not be so good. But in the case of real live attacks, if we delay a year for a perfect secure implementation, then we lose a year, over-all, and the victims lose another billion. Those numbers are much scarier than a few hiccups over SNI.
iang
smime.p7s
Description: S/MIME Cryptographic Signature
