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 > <mailto: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
