> On Dec 17, 2018, at 8:58 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
> wrote:
>
> That said, I'd bet we're all generally unkeen on "do both" but
> maybe the above-mentioned PR avoids that by casting the HRR-mode
> as way to better handle a likely operational failure mode.
I guess the reason I started thinking along the lines of the alternative
proposal is because it would doing it *at all* might be too complex for
many sites, and privacy protection that is mostly not deployed is then
not very effective.
Thus, instead of trying to work around glitches caused by key management
glitches, my thinking was to avoid them entirely, by using ephemeral keys.
I don't dispute the obstacles:
* Additional round-trip for full handshakes.
* Possible middle-box concerns that I can't speak to.
The potential upside is:
* Supports stable local policy (no keys, means client used by users
with critical need can have a static fronting server config).
* Better forward secrecy.
* Much simpler operationally, so could have much broader deployment.
I'll take a look at David Benjamin's PR, to see whether it resolves
any of the motivating reasons for the alternative...
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
