Hi Derek, > Having encryption params within the scheme being renegotiated seems likely, > but not > changing the scheme, as such I can't see the need to preclude reuse of the > option > values for per scheme use once the scheme is selected. The actual use I was > expecting > was that the per scheme renegotiation would/could use those values for > negotiating > new keys, or other per-scheme values.
Hmm - looks like I may have misread this text last night as releasing the option for arbitrary usage. I suppose what is there is ok, but I'd prefer to see another option kind allocated for encryption spec usage (if we anticipate that being needed) rather than overloading the TCP-ENO option kind. Thanks, --David > -----Original Message----- > From: Tcpinc [mailto:[email protected]] On Behalf Of Derek Fawcus > Sent: Wednesday, June 29, 2016 2:29 AM > To: [email protected] > Subject: Re: [tcpinc] TCP-ENO: David Black's review > > On Wed, Jun 29, 2016 at 12:17:05AM +0000, Black, David wrote: > > [G] Section 4.2 - NO, don't do this! The option kind will be assigned to > > TCP- > ENO by > > IANA, and allowing this class of reuse: > > a) almost certainly violates the rules for the registry from which that > > kind > > value is assigned. > > b) prematurely closes off opportunities to use the option after the > > initial > > handshake (e.g., possibly for encryption renegotiation). > > Actually, that section (4.2) struck me as reasonable. > > Ignoring 'a' for the moment, and looking at 'b': the whole point of this > mechanism > is to pick / negotiate an encryption scheme. Once picked for a given TCP > connection > I can't really see the scheme being changed (i.e. between tcpcrypt and > use-tls). > > Having encryption params within the scheme being renegotiated seems likely, > but not > changing the scheme, as such I can't see the need to preclude reuse of the > option > values for per scheme use once the scheme is selected. The actual use I was > expecting > was that the per scheme renegotiation would/could use those values for > negotiating > new keys, or other per-scheme values. > > DF > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
