Adam Langley <a...@imperialviolet.org> wrote:
> Since this defeats forward security, and is clearly something that
> implementations of previous versions have done, this change
> specifically calls it out as a MUST NOT. Implementations would then be
> free to detect and reject violations of this.
>
> This does have a cost because it also excludes the reasonable practice
> of amortising public value generation over all connections for a few
> seconds. The draft could attempt to specify a precise, maximum
> duration for reuse but that is more complex and no value is clearly
> optimal.
We should brainstorm the unintended negative consequences of this.
It would make self-hosting a small that can survive a spike in traffic
("slashdot effect") more difficult, thus encouraging sites to use
CDNs, which decrease the integrity, confidentiality, and privacy
properties of all connections between the client and the origin
server. Unfortunately I don't know how to quantify that.
Another unintended consequence is that it makes the PSK modes
relatively more attractive. For some very small devices doing ECDH
agreement on every connection and only doing a occasionally doing a
ECDH keygen could be at the edge of their performance/power limits,
and needing to do the ECDH keygen for every connection could easily
make using ECDH prohibitive. OTOH, we don't want these devices to use
have a fixed ECDH key burned into their ROM, or similar, either.
Another unintended consequence is that it makes resumption (formulated
as a sort of server-generated PSK in TLS 1.3) more necessary. Although
many implementations will probably implement resumption, I think there
are a lot of cases where one might prefer to avoid implementing and/or
enabling it. Also, even when it is enabled, making ECDH more expensive
relative to PSK/resumption would encourage building more complex
server software to distribute PSKs across machines. And/or the server
may choose to reuse PSKs longer. And/or the server may choose to use
the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I
can't quantify the effect here.
> Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse
> values and manage fine today. The generation of (EC)DH public values
> is also a fixed-based operation and thus can be much faster than DH
> key-agreement.
According to the paper, a large majority of servers in the Alexa top
1M are reusing keys. That 14.4% number is a fraction of the 80%
servers consistently in the Alexa top 1M that use browser-trusted
certificates and that use ECDHE. IIUC, approximately 20% of servers in
the Alexa top 1M that use browser-trusted certificates are using RSA
key exchange, which means they are also reusing the same key for every
connection. Also, according to the paper, more than half of servers
aren't using TLS or aren't using browser-trusted certificates, which
means that web browser connections to them are likely using the same
NULL key.
Also, the Alexa top 1M isn't representative of every use of TLS, but
rather only one kind of application.
> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling
> TLS connections to be decrypted and monitored by a middlebox. TLS is
> not designed to be decrypted by third-parties—that's kind of the
> point. Thus anyone doing this should not be surprised to hit a few
> MUST NOTs and, potentially, to have to configure implementations to
> allow such a deployment.
The (presumably) accidental reuse of keys for long periods of time is
bad, and this MitM idea is even worse. But, if reuse were made a MUST
NOT, wouldn't such systems just use a different, perhaps worse, more
complex, and undetectable mechanism, like the one Dan Brown suggested
in the earlier thread? I think we should assume that while we may be
able to help prevent the former accidental badness with such a rule,
such a mechanism probably isn't going to have much effect on the
latter intentional badness.
With all this in mind, absent other information. In the case of
servers hosting websites, I do think a limit of less than a minute is
reasonable. However, I think for the small device (IoT) case, the
limit should be longer, perhaps even hours.
Cheers,
Brian
--
https://briansmith.org/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
