Re: [TLS] chairs - please shutdown wiretapping discussion...

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-bounces@ietf.org on behalf of nico@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.farrell@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

Re: [TLS] chairs - please shutdown wiretapping discussion...

Attachment: smime.p7s