Interesting suggestion. As Ilari mentions, we did look at this a bit previously, but ended up with a signature-based scheme for compat reasons. I'd definitely be interested in seeing this fleshed out some more and will try to take a look soon...
On Thu, Oct 26, 2017 at 8:21 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > Lastly, I have had a look at extending this to TLS 1.3 and it seems > > pretty straightforward; however, there is no urgency and I feel we can > > defer that to after the TLS 1.3 draft has been approved. > > I don't think this is straightforward to extend to TLS 1.3. There > has been proposal which had mode similar to this, but the TLS 1.3 > key exchange looks pretty different from it. > > Especially annoying would be that since TLS 1.3 is three-flight key > exchange, the client authentication can not affect traffic keys. So > presumably the best thing that could be archived is mixing the DH > authentication terms into Finished messages. > It's pretty straightforward to mix the static server DH share into the final traffic keys (that last 0 input in the key schedule is kind of a placeholder for that). As you say, the client's key is more difficult, but mixing into the Finished MAC would be relatively straightforward, though we might need to mess with the key schedule a bit to make that work. -Ekr > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
