netdev - Re: [PATCH v3 net-next 0/4] kernel TLS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170614220626.GB72301@davejwatson-mba.dhcp.thefacebook.com>
Date:   Wed, 14 Jun 2017 15:06:26 -0700
From:   Dave Watson <davejwatson@...com>
To:     Hannes Frederic Sowa <hannes@...essinduktion.org>
CC:     David Miller <davem@...emloft.net>, <ilyal@...lanox.com>,
        <aviadye@...lanox.com>, <borisp@...lanox.com>,
        <liranl@...lanox.com>, <matanb@...lanox.com>,
        <netdev@...r.kernel.org>, <tom@...bertland.com>,
        <herbert@...dor.apana.org.au>, <linux-crypto@...r.kernel.org>,
        <eric.dumazet@...il.com>, <alexei.starovoitov@...il.com>,
        <nmav@...tls.org>, <fridolin.pokorny@...il.com>
Subject: Re: [PATCH v3 net-next 0/4] kernel TLS

Hi Hannes, 

On 06/14/17 10:15 PM, Hannes Frederic Sowa wrote:
> one question for this patch set:
> 
> What is the reason for not allowing key updates for the TX path? I was
> always loud pointing out the problems with TLSv1.2 renegotiation and
> TLSv1.3 key update alerts. This patch set uses encryption in a
> synchronous way directly in the socket layer and thus wouldn't suffer
> from problems regarding updates of the key. My hunch is that you leave
> this option open so you can later on introduce asynchronous crypto which
> might be used on hardware? It looks also be doable in case of MSG_MORE.
> Otherwise by allowing key updates to the data path I would not see any
> problems with key updates in TLS.

I don't currently have any reasons to not support renegotation, we
just don't currently use it, so I didn't add support for it.  I don't
work on the hardware, but yes it looks like it would have to keep the
old keys around until everything sent using them has been acked.

> Anyway, this patch seems easy and maybe with key updates added later on
> doesn't seem to have any problems pointed out by me so far.

Indeed, it would be easy to flush any unencrypted data, and then
change the keys.