My $0.02: absolutely not on the Standards Track (for reasons already expressed by others), might be discussable if Informational.
--
Regards,
Uri Blumenthal
On 7/10/17, 15:03, "TLS on behalf of Nico Williams" <tls-boun...@ietf.org on
behalf of n...@cryptonector.com> wrote:
On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
> > On 10 Jul 2017, at 17:16, Stephen Farrell <stephen.farr...@cs.tcd.ie>
wrote:
> >> 2. this proposal offers
> >> significantly better security properties than current practice
> >> (central distribution of static RSA keys)
> >
> > I fail to see any relevant difference in security properties
> > between those two, never mind a significant improvement.
>
> I can see one way in which it is worse.
>
> With static RSA keys, you can configure the server to use only PFS
> ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS,
> you need to switch to RSA ciphersuites, and that would be obvious to
> any client. In fact, I think today a server would stick out if it
> only supported RSA ciphersuites.
>
> There is no way to know that a server is doing what it says in the
> draft. It’s completely opaque to the client.
>
> However, in both cases the server does get FS. As long as the server
> has not enabled RSA ciphersuites or exportable private key shares, any
> recorded TLS stream is safe even if the attacker later gets the
> private key.
Well, a client could observe reuse of server ECDHE public keys...
And servers can always share session keys with an auditing system.
There's no way a client could detect this.
I don't think we need to have the client KNOW what the server is doing
because... how the heck can the server prove it's not publishing the
client's secrets?? The server simply cannot prove that it is adhering
to any privacy policy.
Brief reuse of server ECDHE public keys is an optimization. I _think_
it's a safe optimization, and it's safer the shorter the reuse period is
-- and correspondingly less safe the longer the reuse period.
But I would prefer that anyone wanting auditability just build that into
their implementations as a proper audit capability. Yes, it's more
complex to later decrypt sessions, but it also doesn't mess with the
protocol in any way.
That said, I wouldn't object to the proposal if it meant to be
Informational. I don't see how a document that describes a possible a
configuration (not protocol!) that is not relevant to the Internet
should be a Standards-Track RFC, or BCP for that matter. Informational
will do.
Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
