Thank you for your comment, while it is an interesting question, I think the wording is appropriate as is.
I believe the proper interpretation of this text is that renegotiation is not supported for TLS 1.3 and we have not designed anything to allow for renegotiation (i.e., for any version of TLS). If future versions of TLS do not support renegotiation, then there should not be any issue. If a future version of TLS does support renegotiation, then this RFC would likely need to be revisited anyway to determine if we want to allow its use. I am inclined to say that the current wording is reasonable as it does not strictly prohibit it but does indicate it is "not supported" and implies a level of discouragement as it would not be a standard feature. Of course, if TLS added the capability and we wanted to make it a standard feature, we could update this RFC to allow it - and I would expect that update would need to make additional revisions to accommodate the new capability. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > I was just wondering - as there is an intended impact on the future here, > > "Renegotiation of sessions is not supported as it is not supported by TLS > 1.3." > > what is the intended implication on the application of future versions of TLS? > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg