Subject: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

From: Joseph Salowey <[email-masked]>
Date: Thu, 29 Oct 2020 09:23:40 -0700

An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the
mandatory requirement for OCSP stapling [1].  The document makes the use of
OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this
may not be feasible in all deployments.  This is a quick consensus call for
this issue.   Please indicate which option below you support and why.
Please respond by November 5, 2020.

1. Keep the text as is with OCSP mandatory for all implementations

2. Require Servers to Implement and Recommended to Use OCSP with text
similar to the following:

“EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
verifying the status of server certificates as specified in Section 4.4.2.1
of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
status of the EAP-TLS server, it MUST use Certificate Status Requests for
the server's certificate chain and it MUST treat a CertificateEntry (except
the trust anchor) without a valid CertificateStatus extension as invalid
and abort the handshake with an appropriate alert.“

Thanks,

Joe

[1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
[2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Oct 2020 17:52:52 +0100

Hi Joe,

My suggestion is that we add some discussion about what to do in the case of no connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in industrial use cases.

Eliot

> On 29 Oct 2020, at 17:23, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
> 
> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the mandatory requirement for OCSP stapling [1].  The document makes the use of OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this may not be feasible in all deployments.  This is a quick consensus call for this issue.   Please indicate which option below you support and why.  Please respond by November 5, 2020. 
> 
> 2. Require Servers to Implement and Recommended to Use OCSP with text similar to the following:
> 
> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying the status of server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, it MUST use Certificate Status Requests for the server's certificate chain and it MUST treat a CertificateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert.“
> 
> Thanks,
> 
> Joe
> 
> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/ <https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/>
> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 <https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4>_______________________________________________
> Emu mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/emu

---

From: Max Pala <[email-masked]>
Date: Thu, 29 Oct 2020 11:30:36 -0600

Hi Eliot, all,

In our industry we solved this issue by requiring OCSP stapling if and only if the certificate being validated carries the OCSP URI in the certificate. 

This allows us to live in a mixed environment where support for OCSP might have been introduced later on and allows the CA to explicitly support OCSP for the certificate by including the URL in it.

If the “ecosystem” policy allows it – you might suggest that if OCSP responses are not not provided but the URL where to get OCSP responses is known to the device (or it is in the certificate), the device/entity can continue with the authentication but it should not enable any device/entity functionality before successfully executing (and validating) the OCSP protocol first (and disconnect if not reachable/invalid/revoked).

Just my 2 cents.

Cheers,
Max

From: Emu <[email-masked]> on behalf of Eliot Lear <lear=[email-masked]>
Date: Thursday, October 29, 2020 at 10:53 AM
To: Joseph Salowey <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

Hi Joe,

Eliot

On 29 Oct 2020, at 17:23, Joseph Salowey <[email-masked]> wrote:

Thanks,

Joe

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________ Emu mailing list [email-masked] https://www.ietf.org/mailman/listinfo/emu

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Oct 2020 18:37:01 +0100

Hi Max

> On 29 Oct 2020, at 18:30, Max Pala <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Eliot, all,
>  

Perfectly reasonable.

> This allows us to live in a mixed environment where support for OCSP might have been introduced later on and allows the CA to explicitly support OCSP for the certificate by including the URL in it.

Yep.

> If the “ecosystem” policy allows it – you might suggest that if OCSP responses are not not provided but the URL where to get OCSP responses is known to the device (or it is in the certificate), the…

Worth more.

Eliot

> Cheers,
> Max
>  
> From: Emu <[email-masked] <mailto:[email-masked]>> on behalf of Eliot Lear <lear=[email-masked] <mailto:lear=[email-masked]>>
> To: Joseph Salowey <[email-masked] <mailto:[email-masked]>>
> Cc: EMU WG <[email-masked] <mailto:[email-masked]>>
>> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 <https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4>
>> https://www.ietf.org/mailman/listinfo/emu <https://www.ietf.org/mailman/listinfo/emu>
>  
> _______________________________________________ Emu mailing list [email-masked] <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/emu <https://www.ietf.org/mailman/listinfo/emu>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Oct 2020 14:09:36 -0400

+1

> On Oct 29, 2020, at 1:37 PM, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hi Max
> 
>> On 29 Oct 2020, at 18:30, Max Pala <[email-masked]> wrote:
>> 
>> Hi Eliot, all,
>>  
>> _______________________________________________ Emu mailing list [email-masked]://www.ietf.org/mailman/listinfo/emu
>

---

From: Tim Cappalli <[email-masked]>
Date: Thu, 29 Oct 2020 19:19:20 +0000

+1

From: Emu <[email-masked]>
Date: Thursday, October 29, 2020 at 14:10
To: Eliot Lear <lear=[email-masked]>
Cc: Max Pala <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11
  +1

>>> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2F0DnfUWPqvKX0_Wo8s-ZypergMHI%2F&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=KrJVJ6Un4%2BHpycHthG7MZPKDJUCHxrCPqib4bMrtRMQ%3D&amp;reserved=0
>>> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-emu-eap-tls13-11%23section-5.4&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xuERey5ZNv3DjwO10WKS0f2cK87ObmQ6H2WXTzqtBDA%3D&amp;reserved=0
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=sl%2B4jNsThcZ8381i7AxlQ7z38dBM%2Bqz1Stox7h7ThLw%3D&amp;reserved=0
>>
>> _______________________________________________ Emu mailing list [email-masked]://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=sl%2B4jNsThcZ8381i7AxlQ7z38dBM%2Bqz1Stox7h7ThLw%3D&amp;reserved=0
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=sl%2B4jNsThcZ8381i7AxlQ7z38dBM%2Bqz1Stox7h7ThLw%3D&amp;reserved=0

_______________________________________________
Emu mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459844854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Erp6hV0dny9j3vyAbFhDmqHLxrn66Aet9XtjOwCKSLw%3D&amp;reserved=0

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 29 Oct 2020 12:37:00 -0700

On Thu, Oct 29, 2020 at 10:30 AM Max Pala <[email-masked]> wrote:

> Hi Eliot, all,
>
>
>
> In our industry we solved this issue by *requiring OCSP stapling if and
> only if the certificate being validated carries the OCSP URI in the
> certificate*.
>
>
>
> This allows us to live in a mixed environment where support for OCSP might
> have been introduced later on and allows the CA to explicitly support OCSP
> for the certificate by including the URL in it.
>
>
>
> If the “ecosystem” policy allows it – you might suggest that if OCSP
> responses are not not provided but the URL where to get OCSP responses is
> known to the device (or it is in the certificate), the device/entity can
> continue with the authentication but it should not enable any device/entity
> functionality before successfully executing (and validating) the OCSP
> protocol first (and disconnect if not reachable/invalid/revoked).
>
>
>

[Joe] So you are in favor of both clients and servers
mandatory implementing OCSP, but only requiring it be used when it is
signalled in the certificate?

> Just my 2 cents.
>
>
>
> Cheers,
> Max
>
>
>
> *From: *Emu <[email-masked]> on behalf of Eliot Lear <lear=
> [email-masked]>
> *Date: *Thursday, October 29, 2020 at 10:53 AM
> *To: *Joseph Salowey <[email-masked]>
> *Cc: *EMU WG <[email-masked]>
> *Subject: *Re: [Emu] Consensus Call on OCSP usage in
> draft-ietf-emu-eap-tls13-11
>
>
>
> Hi Joe,
>
>
>
> My suggestion is that we add some discussion about what to do in the case
> of no connectivity to the CA.  This will be a not-uncommon occurrence,
> IMHO, in industrial use cases.
>
>
>
> Eliot
>
>
>
> _______________________________________________ Emu mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/emu
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Oct 2020 18:12:52 -0400

> similar to the following:

I don't think that this text is quite right.

I note that "RECOMMENDED" is a synonym for SHOULD, and usually we ask
documents to explain what a reasonable exception might look like.
This text does not do that.

    > and abort the handshake with an appropriate alert.“

I suggest:

“EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
recovation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446].

It is RECOMMENDED that EAP-TLS peers and servers use OCSP (with stapling) for
verifying the status of server certificates as specified in Section 4.4.2.1
of [RFC8446].
<MCR: BUT, I think that section 4.4.2.1 is not where certificate status is
mandated for TLS. I can't find the right place>

When an EAP-TLS peer uses OCSP to verify the certificate status of the
EAP-TLS server, it MUST use Certificate Status Requests for the server's
certificate chain and it MUST treat a CertificateEntry (except the trust
anchor) without a valid CertificateStatus extension as invalid and abort the
handshake with an appropriate alert.“

I don't know much about the last part.
I suggest it be split as three paragraphs for readability.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 29 Oct 2020 21:26:30 -0700

> I suggest it be split as three paragraphs for readability.
[Joe] Thanks Michael,  I think your suggestion is a better way to phrase it

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2020 07:44:53 -0400

> [Joe] Thanks Michael,  I think your suggestion is a better way to phrase it

Just so that we are clear:  this mandates OCSP+stapling for systems that do
revocation checks.

Systems that don't do revocation checks (current mbedtls), therefore don't
need to do OCSP or stapling.

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 30 Oct 2020 09:26:01 -0700

> need to do OCSP or stapling.

[Joe] That's not how I read your text.  I think your text mandates
OCSP+stapling for systems that use OCSP for revocation.

TLS 1.3 RFC 8446 does not mandate a particular revocation mechanism either,
as revocation is part of PKIX.

Also to be clear you text does not mandate that either servers or clients
support OCSP Stapling.

I think it would be appropriate to modify your text to replace "use" with
support.

"EAP-TLS servers supporting TLS 1.3 that support OCSP to do certificate
revocation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446]."

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2020 13:21:26 -0400

> as revocation is part of PKIX.

I thought that someone said that it did.
In which case, we are under no additional compulsion to support revocation
than we were before.

Hannes and Eliot have brought up significant operational challenges in
supporting OCSP in some environments.  I think that it should be a local decision.

    > stapling as specified in Section 4.4.2.1 of [RFC8446]."

okay.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------