I am trying to figure out if every implementation compliant with
RFC8446 is also necessarily interoperable with an RFC5246 peer, or if this
is just a likely common, but still completely optional implementation choice.
I could not find any explicit statement that backward compatibility
with RFC5246
Thanks for the explanation.
My main concern was just to understand clearly what requirements
have to be written into RFC when one wants to ensure that TLS 1.2 needs
to be supported as the fallback in a particular solution.
With TLS 1.3 not mandating support for TLS 1.2, in such cases one
still n
3:23:42PM -0700, Eric Rescorla wrote:
> On Thu, Aug 5, 2021 at 2:37 PM Toerless Eckert wrote:
>
> > Thanks for the explanation.
> >
> > My main concern was just to understand clearly what requirements
> > have to be written into RFC when one wants to ensure that TLS 1
any better, but TLS just has the biggest interest
surface so it makes most sense to encourage authors to write the most easily
read text.
Cheers
Toerless
On Thu, Aug 05, 2021 at 03:57:07PM -0700, Eric Rescorla wrote:
> On Thu, Aug 5, 2021 at 3:52 PM Toerless Eckert wrote:
>
> >
> —Richard
>
> On Thu, Aug 5, 2021 at 13:12 Toerless Eckert wrote:
>
> > Sure, i like playing TLS cluedo ;-)
> >
> > But for uneducated readers, i was thinking more about text that uplevels
> > to the operational
> > aspect of interoperability:
> >
s no need to explain
> > when that’s the case.
> >
> > —Richard
> >
> > On Thu, Aug 5, 2021 at 13:12 Toerless Eckert wrote:
> >
> > > Sure, i like playing TLS cluedo ;-)
> > >
> > > But for uneducated readers, i was thinking more ab
Whether that's
> a good idea is something that the market will decide...
>
> -- Christian Huitema
>
> On 8/5/2021 5:14 PM, Toerless Eckert wrote:
> > RFC9001/4.2:
> >"Clients MUST NOT offer TLS versions older than 1.3. A badly configured
> > TLS im
Thanks, Benoit
[hope it's ok. to cross-port and redirect replies to TLS]
I have not followed TLS 1.3 in detail, so a quick question first:
Will TLS 1.3 still permit servers to send their certificate and/or SNI in the
clear as an option or
will it force server operators to encrypt either/or ? If
On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote:
> Operators trying to do this by inspecting TLS (and not decrypting) are
> going to have a bad time anyway. With HTTP/2 connection coalescing, even
> if they can see the certificate, the actual HTTP request could be for any
> name in
On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote:
> > If a web service hoster does not provide any useful demultiplexer then it
> > can of course not
> > expect not to get blacklisted across services. Is it not already common
> > practice to assign
> > separate certificates to separate "
So no options in TLS 1.3 that make it possible to see the server cert in the
clear ?
On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote:
> On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> > Another candidate use case coming to mind eg: auditing tht is required in
&g
stead of MitMing. See old
> threads for more detail.
>
>
> Dave
>
>
> On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote:
> > So no options in TLS 1.3 that make it possible to see the server cert in
> > the clear ?
> >
> > On Sun, Jun 04, 201
12 matches
Mail list logo
