I think that's okay, since this is only for use in applications where both parties are in on the deal. But the problem with the static ecdh proposal is the the server is not compelled to reveal that it is doing it.
On Jul 20, 2017 8:01 AM, "Russ Housley" <hous...@vigilsec.com> wrote: > Ted, if we use a new extension, then the server cannot include it unless > the client offered it first. I am thinking of an approach where the server > would include information needed by the decryptor in the response. So, if > the client did not offer the extension, it would be a TLS protocol > violation for the server to include it. > > Russ > > > On Jul 19, 2017, at 1:14 PM, Ted Lemon <mel...@fugue.com> wrote: > > Provably involved, or involved setting an evil bit? > > On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley <hous...@vigilsec.com> > wrote: > >> The hum told us that the room was roughly evenly split. In hind sight, I >> wish the chairs had asked a second question. If the split in the room was >> different for the second question, then I think we might have learned a bit >> more about what people are thinking. >> >> If a specification were available that used an extension that involved >> both the client and the server, would the working group adopt it, work on >> it, and publish it as an RFC? >> >> I was listening very carefully to the comments made by people in line. >> Clearly some people would hum for "no" to the above question, but it >> sounded like many felt that this would be a significant difference. It >> would ensure that both server and client explicitly opt-in, and any party >> observing the handshake could see the extension was included or not. >> >> Russ >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
