[TLS] [Editorial Errata Reported] RFC8446 (6820)

The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6820 -- Type: Editorial

Re: [TLS] [Uta] OCSP in RFC7525bis

Hi Ryan-- I share your skepticism, but i'm still trying to salvage something useful -- for the purpose of defending against CA malfeasance -- from the mechanisms we have available. On Thu 2022-01-20 23:51:22 -0500, Ryan Sleevi wrote: > There are good reasons that clients have not, and

Re: [TLS] [Uta] OCSP in RFC7525bis

On Fri 2022-01-21 15:23:56 +, Salz, Rich wrote: > Second, there is the history of poor behavior by some CA's, which > leads to the primary user agent (browsers, or perhaps TLS runtimes) > not being able to just completely trust them. Perhaps that historic > era has passed, and it is time for

Re: [TLS] [Uta] OCSP in RFC7525bis

>I share your skepticism, but i'm still trying to salvage something useful -- for the purpose of defending against CA malfeasance -- from the mechanisms we have available. For that, you mainly want certificate transparency, no? > If certificate validation is the process of

Re: [TLS] [Uta] OCSP in RFC7525bis

On Fri, Jan 21, 2022 at 01:30:38PM -0500, Ryan Sleevi wrote: > > > Do you think that DNSSEC should be soft-fail for CAA checks, or should > > > we urge the CAs to be more strict here? Perhaps that would be another > > > recommendation. > > > > CAA lookups must not softfail. This needs to be the

Re: [TLS] [Uta] OCSP in RFC7525bis

This discussion seems kind of out of scope for 7525-bis, which is about how to use TLS, but doesn't seem to say much of anything in terms of how to operate a CA. The current draft seems not to say anything about what clients ought to do and to say that servers SHOULD support OCSP and OCSP

Re: [TLS] [Uta] OCSP in RFC7525bis

> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor > wrote: > >> Without wanting to detract too much from the core question of the thread, >> how does this address the routing gap? The adversary at the routing layer >> just redirects the host being validated to control the key that way, and >>

Re: [TLS] [Uta] OCSP in RFC7525bis

On Fri, Jan 21, 2022 at 9:52 AM Daniel Kahn Gillmor wrote: > I share your skepticism, but i'm still trying to salvage something > useful -- for the purpose of defending against CA malfeasance -- from > the mechanisms we have available. > Indeed, I think the goal is admirable, but I'm not sure

Re: [TLS] [Uta] OCSP in RFC7525bis

On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni wrote: > > Do you think that DNSSEC should be soft-fail for CAA checks, or should > > we urge the CAs to be more strict here? Perhaps that would be another > > recommendation. > > CAA lookups must not softfail. This needs to be the case whether

Re: [TLS] [Uta] OCSP in RFC7525bis

On Fri 2022-01-21 11:56:04 -0500, Viktor Dukhovni wrote: >> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor >> wrote: > >> Do you think that DNSSEC should be soft-fail for CAA checks, or should >> we urge the CAs to be more strict here? Perhaps that would be another >> recommendation. > > CAA

[TLS] rfc6066 ->Server Name extension sending issue from server

Hi All, In this below RFC->RFC 6066 - Transport Layer Security (TLS) Extensions: Extension Definitions (ietf.org) 3 . Server Name Indication A server that receives a client hello containing