Subject: [secdir] Secdir last call review of draft-ietf-emu-eaptlscert-06

From: Stefan Santesson via Datatracker <[email-masked]>
Date: Thu, 29 Oct 2020 16:13:02 -0700

Reviewer: Stefan Santesson
Review result: Has Nits

The document in general is good and well written.

Some nits needs attention before publication as the general review also points
out. Ex in the abstract "This document looks at the this problem"

Some abbreviations needs to be spelled out at first usage, such as MTU (Maximum
Transmission Unit)

On the content itself I have two questions:

- Wouldn't it be relevant to also discuss the risks with regard to introduction
of quantum safe crypto, if that leads to significantly increased key sizes? It
could be troublesome if transition to a safer crypto is made impossible due to
size limitations. - Would it be relevant to discuss usage of AIA extension as
means of possibly excluding intermediary certs from the path as they could be
located using AIA?

Finally, I agree with the general review that this document reference quite
some work in progress. If this document is to be published before these
referenced works are concluded, are there alternatives to make the same point?

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 29 Oct 2020 20:04:15 -0700

Hi Stefan,

Thanks for the review; it raises some good topics.
Replying on a couple points...

> Some abbreviations needs to be spelled out at first usage, such as MTU (Maximum

MTU may actually be okay; per
https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as
"well-known" and does not always need to be expanded.

> referenced works are concluded, are there alternatives to make the same point?

They seem to mostly be informative references, and so would not require us
to hold publication of this document.  It is probably still worth
considering if there are alternatives anyway, though.

-Ben

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 30 Oct 2020 13:48:36 +0000

Hi Stefan,

Thank you for the review. I have updated the draft in github 
(https://github.com/emu-wg/eaptls-longcert). Here is the diff for your 
convenience: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt&url2=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptlscert.txt.

The following text was added:

>    The size of certificates (and certificate chains) may also increase
>    manifold in the future with the introduction of quantum-safe
>    cryptography.  For example, lattice-based cryptography would have
>    public keys of approximately 1000 bytes and signatures of
>    approximately 2000 bytes.
and in Section 4.2.5

>    The Authority Information Access (AIA) extension specified in
>    [RFC5280] can be used with end-entity and CA certificates to access
>    information about the issuer of the certificate in which the
>    extension appears.  For example, it can be used to provide the
>    address of the OCSP responder from where revocation status of the
>    certificate (in which the extension appears) can be checked. It can
>    also be used to obtain the issuer certificate.  Thus, the AIA
>    extension can reduce the size of the certificate chain by only
>    including a pointer to the issuer certificate instead of including
>    the entire issuer certificate.  However, it requires the side
>    receiving the certificate containing the extension to have network
>    connectivity.  Naturally, such indirection cannot be used for the
>    server certificate (since the EAP peer in most deployments does not
>    have network connectivity before authen

Let me know what you think. I am not an expert on quantum cryptography 
or on the AIA extension. I will wait for all the comments to come in 
before submitting a new version.

--Mohit

On 10/30/20 5:04 AM, Benjamin Kaduk wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 30 Oct 2020 15:40:26 +0100

Hi,

I think the text is great. 
However I'm not entirely convinced that AIA requires network connectivity at all times.
The AIA CA cert url is static and works fine as identifier for a locally cached cert
The fact that it is the correct cert is assured by the path validation process.
As such, the AIA works fine with a http cache implementation or similar or any other solution using locally stored data.
If used in a local corporate context, a cache mechanism could be provided with pre-loaded relevant certs.

But I don’t know how this may or may not interoperate with deployed base of EAP implementations.

Stefan Santesson 

On 2020-10-30, 14:48, "Mohit Sethi M" <[email-masked]> wrote:

    Hi Stefan,

    and in Section 4.2.5

    --Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Sat, 31 Oct 2020 14:19:31 +0000

Hi Stefan,

I made a minor update to reflect your feedback (https://github.com/emu-wg/eaptls-longcert/compare/3ac0a18..2093026):

Thus, the AIA extension can reduce the size of the certificate chain by only including a pointer to the issuer certificate instead of including the entire issuer certificate. However, it requires the side receiving the certificate containing the extension to have network connectivity (unless the information is already cached locally). Naturally, such indirection cannot be used for the server certificate (since EAP peers in most deployments do not have network connectivity before authentication and typically do not maintain an up-to-date local cache of issuer certificates).

Hope this is correct (and sufficient).

--Mohit

On 10/30/20 4:40 PM, Stefan Santesson wrote:

Hi,

Stefan Santesson

On 2020-10-30, 14:48, "Mohit Sethi M" <[email-masked]><mailto:[email-masked]> wrote:

    Hi Stefan,

    and in Section 4.2.5

    --Mohit

    On 10/30/20 5:04 AM, Benjamin Kaduk wrote:
    > [email-masked]<mailto:[email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 31 Oct 2020 22:56:24 +0100

I think that is great!

Stefan Santesson 

From: Mohit Sethi M <[email-masked]>
Date: Saturday, 31 October 2020 at 15:19
To: Stefan Santesson <[email-masked]>, Mohit Sethi M <[email-masked]>, Benjamin Kaduk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06

Hi Stefan,

--Mohit

 
 
Stefan Santesson 

    Hi Stefan,

 
    >    The size of certificates (and certificate chains) may also increase
    >    manifold in the future with the introduction of quantum-safe
    >    cryptography.  For example, lattice-based cryptography would have
    >    public keys of approximately 1000 bytes and signatures of
    >    approximately 2000 bytes.
    and in Section 4.2.5
 
    >    The Authority Information Access (AIA) extension specified in
    >    [RFC5280] can be used with end-entity and CA certificates to access
    >    information about the issuer of the certificate in which the
    >    extension appears.  For example, it can be used to provide the
    >    address of the OCSP responder from where revocation status of the
    >    certificate (in which the extension appears) can be checked. It can
    >    also be used to obtain the issuer certificate.  Thus, the AIA
    >    extension can reduce the size of the certificate chain by only
    >    including a pointer to the issuer certificate instead of including
    >    the entire issuer certificate.  However, it requires the side
    >    receiving the certificate containing the extension to have network
    >    connectivity.  Naturally, such indirection cannot be used for the
    >    server certificate (since the EAP peer in most deployments does not
    >    have network connectivity before authen

    --Mohit
 
    On 10/30/20 5:04 AM, Benjamin Kaduk wrote:
    > Hi Stefan,
    >
    > Thanks for the review; it raises some good topics.
    > Replying on a couple points...
    >
    > On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatracker wrote:
    >> Reviewer: Stefan Santesson
    >> Review result: Has Nits
    >>
    >> The document in general is good and well written.
    >>
    >> Some nits needs attention before publication as the general review also points
    >> out. Ex in the abstract "This document looks at the this problem"
    >>
    >> Some abbreviations needs to be spelled out at first usage, such as MTU (Maximum
    >> Transmission Unit)
    > MTU may actually be okay; per
    > https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as
    > "well-known" and does not always need to be expanded.
    >
    >> On the content itself I have two questions:
    >>
    >> - Wouldn't it be relevant to also discuss the risks with regard to introduction
    >> of quantum safe crypto, if that leads to significantly increased key sizes? It
    >> could be troublesome if transition to a safer crypto is made impossible due to
    >> size limitations. - Would it be relevant to discuss usage of AIA extension as
    >> means of possibly excluding intermediary certs from the path as they could be
    >> located using AIA?
    >>
    >> Finally, I agree with the general review that this document reference quite
    >> some work in progress. If this document is to be published before these
    >> referenced works are concluded, are there alternatives to make the same point?
    > They seem to mostly be informative references, and so would not require us
    > to hold publication of this document.  It is probably still worth
    > considering if there are alternatives anyway, though.
    >
    > -Ben
    >
    > _______________________________________________
    > Emu mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/emu