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

Reply via email to