On Monday, 31 January 2022 21:18:52 CET, Ryan Sleevi wrote:
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote:
Browsers are the only software that use browser's implementation of
certificate
verification and revocation.
And while they are significant users of TLS, they're definitely not
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote:
>
> Browsers are the only software that use browser's implementation of
> certificate
> verification and revocation.
>
> And while they are significant users of TLS, they're definitely not the
> only important users of TLS.
In the context of
On Friday, 21 January 2022 05:51:22 CET, Ryan Sleevi wrote:
On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor
wrote:
This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a
client deliberately fail a connection when the problem might be a flaw
with an unrelated network
24 January 2022 at 17:19
To: u...@ietf.org , tls@ietf.org
Subject: Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon 2022-01-24 13:06:13 +, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often
On Mon, Jan 24, 2022 at 11:18 AM Daniel Kahn Gillmor
wrote:
> So, arguably, the advantage of revocation checking via OCSP stapling
> over short-lived certificates today has to do with keeping CT logs a
> manageable size, not with any particular security gain in terms of
> revocation
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
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
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
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
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
> 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
>>
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
>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
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
On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor
wrote:
> This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a
> client deliberately fail a connection when the problem might be a flaw
> with an unrelated network service or a client-specific routing failure?
>
> I think we can
On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote:
> * Add a SHOULD-level requirement (for TLS 1.3 implementations,
> possibly also TLS 1.2 implementations) to fail the handshake if the
> OCSP response is missing or invalid. (As far as we can tell, RFC 8446
> is silent on this.)
This sounds a
> On 19 Jan 2022, at 9:57 am, Yaron Sheffer wrote:
>
> But this raises a larger question: many client-side implementations soft-fail
> if they don’t get an OCSP response within the handshake, i.e. they just
> ignore the problem. As far as we understand, this makes OCSP stapling
> completely
On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer wrote:
> Hi,
>
>
>
> RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to
> use OCSP and OCSP stapling. We are changing these recommendations [2] in
> view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.
>
>
>
> But
For additional context, here's s research study we published a few years
back on OCSP must-staple in the Web context:
https://cbw.sh/static/pdf/chung-imc18.pdf
Nick
On Wed, Jan 19, 2022 at 11:58 AM Mohit Sahni wrote:
> Hi,
> > So for the new BCP, we have three options:
> >
> > Add a
* We would be grateful for feedback based on implementation experience. In
particular if you have quantitative data on the use or quality of OCSP that’s
more recent than Chung18 [3], that would be very useful.
For what it’s worth, *our* customers want OCSP stapling. (It’s enabled by
20 matches
Mail list logo
