Subject: [Lake] proposed scoping text

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Apr 2020 16:41:04 +0100

Hiya,

We had quite a discussion in the virtual interim about
scoping and how to get done wrt the requirements so as
to enable the WG to move forward.

Our esteemed AD Ben came up with a proposal that seems
like it may provide the basis for a way forward.

We'd like to get comments on this on the list so that
the editors of the requirements draft can make changes
that get us to a successful end of WGLC. Please try
send those comments before next Tuesday if you can.

Ben's proposal is:

"
Strip down the requirements document a lot, to have a
qualitative sense of "these are the combinations of crypto
primitives that we consider important *right now*" (e.g.,
PSK and RPK). Have an acknowledgment that extensibility is
inevitable, but disclaim that we are focusing on getting it
right for these narrow cases right now, and if someone
wants to do a broader case in the future, then more
analysis will need to be done at that time.  But for now,
we focus on getting RPK and PSK into:

 3 flights, 51-byte messages, and do that well.

If we end up with protocol X that does RPK well and
someone has it deployed but wants to expand their
deployment to also use certificates, they can extend
protocol X to do that and have a fairly homogeneous
deployment, vs. having to have a mix of protocol X
and TLS.  It may well be that TLS would do fine for
their extended use case, but not the original use
case, and having a homogeneous deployment is valuable.
"

Thanks,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Apr 2020 08:45:13 -0700

This seems like it's on the right track. Some more detailed comments below.

    Strip down the requirements document a lot, to have a qualitative
    sense of "these are the combinations of crypto primitives that we
    consider important right now" (e.g., PSK and RPK) Have an
    acknowledgment that extensibility is inevitable, but disclaim that we
    are focusing on getting it right for these narrow cases right now, and
    if someone wants to do a broader case in the future, then more
    analysis will need to be done at that time.

This sounds right. I think I would also focus on limiting extensibility
points, because that's certainly a real design time suck, and perhaps
less necessary if we are sharply limiting scope.

    But for now, we focus on
    getting RPK and PSK into 3 flights, 51-byte messages, and do that
    well.

Yes. I would sharpen this text slightly:

    But for now, we focus on getting RPK and PSK into 3 flights of one
    < 51-byte message each, and do that well.

    If we end up with protocol X that does RPK well and someone has
    it deployed but wants to expand their deployment to also use
    certificates, they can extend protocol X to do that and have a fairly
    homogeneous deployment, vs. having to have a mix of protocol X and
    TLS.  It may well be that TLS would do fine for their extended use
    case, but not the original use case, and having a homogeneous
    deployment is valuable.

Yes, this seems right, though note that there's a tension here because
having a homogenous TLS deployment also is of some value, so in the
long run, this may run us into some sadness. Also, it seems like
trying to have a homogenous deployment with a lot of diverse use
cases is going to put a lot of pressure on the kind of extensibility
mechanisms we are deliberately hoping to minimize here.

-Ekr

On Wed, Apr 8, 2020 at 8:41 AM Stephen Farrell <[email-masked]>
wrote:

> --
> Lake mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lake
>

---

From: Göran Selander <[email-masked]>
Date: Thu, 9 Apr 2020 10:08:53 +0000

All,

TL;DR: I propose LAKE to initially focus on RPK, and certificate by reference.

=========

Apologies for a long mail. Comments on Ben's proposal for a way forward at the end, but first we need to take a step back and try to understand what we are discussing.

We are working on requirements for an AKE for OSCORE. We require a lightweight AKE, since OSCORE may be applied in constrained IoT applications. Now there is a discussion about restricting the functionality of LAKE to address only the most lightweight scenarios, so that another AKE should be used in non-lightweight settings. While this may be an economy of standardization, this does not make sense for many reasons.

* Note that OSCORE is expected to be applied in both in constrained and non-constrained environments. OSCORE works whereever CoAP does, and CoAP is expected to be applied in PSK, RPK and certificate settings.

* Implementation-wise OSCORE is more or less integrated with CoAP, because it reuses CoAP processing. A combined OSCORE/AKE implementation will thus be more or less integrated in CoAP. So how should a developer handle the situation that there is a specification of AKE1 addressing part of the credential space and another completely incompatible specification AKE2 addressing another part? 

* OSCORE is designed for end-to-end security from constrained device to cloud. To be sure to support OSCORE based security you need to implement both AKE1 and AKE2.

* How could it be better security-wise to have two different AKEs for one security protocol? Twice the number of security analyses, etc. are needed. 

* Many companies want to move away from symmetric-key based IoT deployments to public key based, ideally to device certificates. If their current technology does not support transport of certificates, but maybe will later,  should they implement AKE1 or AKE2?

* etc.

Summarizing: At some point in time there needs to be one single AKE for OSCORE that is sufficiently lightweight to perform well in the most constrained settings but also has the functionality to protect CoAP for whatever settings it is expected to be deployed in, and that involves PSK, RPK and certificates.

=======================================

Having said this, it may still be relevant to discuss which cases are most important right now, bearing in mind that this scoping should not prevent later adding the remaining components.  

One way to prioritize the scope of the first work on the AKE is to address a) the needs from current use cases, and b) the potential to provide something useful that is not already available:

a) There is a general request to deploy a lightweight AKE with OSCORE targeting general CoAP use cases 
i.e. based on PSK, RPK as well as certificates. More specific work items I'm aware of include RPK-based solutions (e.g. LoRa Alliance) and mixed RPK/certificate based solution (e.g. draft-selander-ace-ake-authz). As mentioned in my previous email, a PKI-based solution is necessary to handle IoT deployments with a large number of devices and many manufacturers, but the certificate does not necessarily have to be transported.

b) It is possible to do PSK and RPK by reference for the most constrained benchmark (1,1,1). RPK by value and certificate by reference can also be very lightweight, but may require more than one fragment per message. However, in case of transporting a chain of X.509 certificates, or even a single X.509 certificate, it is not clear that a lightweight AKE performs significantly better. 

The intersection of a) and b) correspond to where there is an active interest in a solution and where the solution can be made lightweight: RPK (by reference and value) and certificate by reference. 

This restricted scope leaves out the most lightweight and the least lightweight options. Removing symmetric key based authentication from first scope is a significant simplification since this is a different protocol in many respects compared to the asymmetric version. Moreover, since PSK and RPK by reference can be handled with the same transmission cost, there is less motivation for using PSK ECDHE as an intermediate deployment step.

Now for Ben's proposal:

On 2020-04-08, 17:41, "Lake on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    Ben's proposal is:
    
    "

    But for now,

[GS] Focus on RPK (by value and by reference) and certificate by reference, and do that well. For RPK by reference: 3 flights in (1,1,1) fragments. For RPK by value and certificate by reference the number of fragments should be kept at a minimum.

    case, and having a homogeneous deployment is valuable."

[GS] Agree.

Göran

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Apr 2020 06:16:38 -0700

On Thu, Apr 9, 2020 at 3:09 AM Göran Selander <goran.selander=
[email-masked]> wrote:

>
>
> On 2020-04-08, 17:41, "Lake on behalf of Stephen Farrell" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Ben's proposal is:
>
>     "
> [GS] Focus on RPK (by value and by reference) and certificate by
> reference, and do that well. For RPK by reference: 3 flights in (1,1,1)
> fragments. For RPK by value and certificate by reference the number of
> fragments should be kept at a minimum.
>

This seems to put us back in exactly the same situation we were in before
Ben's proposal, which is "as small as possible".

-Ekr

---

From: Göran Selander <[email-masked]>
Date: Thu, 9 Apr 2020 13:56:35 +0000

From: Eric Rescorla <[email-masked]>
Date: Thursday, 9 April 2020 at 15:17
To: Göran Selander <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lake] proposed scoping text

On Thu, Apr 9, 2020 at 3:09 AM Göran Selander <goran.selander=[email-masked]<mailto:40ericsson.com@dmarc..ietf.org>> wrote:

On 2020-04-08, 17:41, "Lake on behalf of Stephen Farrell" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Ben's proposal is:

    "

    But for now,

This seems to put us back in exactly the same situation we were in before Ben's proposal, which is "as small as possible".

We can quantify this if necessary. Probably 1 additional fragment for RPK by value, 1 additional fragment for certificate by reference, in total max 5 fragments.

Göran

---

From: Göran Selander <[email-masked]>
Date: Wed, 15 Apr 2020 12:19:23 +0000

Hi,

Here is a proposal how to formulate the scoping in the requirements draft:
https://github.com/lake-wg/reqs/pull/26

Göran

On 2020-04-09, 12:09, "Lake on behalf of Göran Selander" <[email-masked] on behalf of goran.selander=[email-masked]> wrote:

    All,

    =========

    

    

    * etc.

    

    

    
    Now for Ben's proposal:

        Ben's proposal is:
        
        "
    
        But for now,

    
    [GS] Agree.
    
    Göran

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 20 Apr 2020 14:25:41 +0200

Hi all,

This is a kind reminder to take a look at the proposed PR and provide feedback, especially if you disagree with the proposed text. With the remaining issues on the requirements documents resolved, we would like to converge on the best way forward for the working group, so please provide your comments by the end of this week, Friday the 24th.

Mališa

> On 15 Apr 2020, at 14:19, Göran Selander <goran.selander=[email-masked]> wrote:
> 
> Hi,
>

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 24 Apr 2020 17:17:16 -0700

Apologies for the delay, all! I thought Ben's suggestion to focus only on PSK and RPK modes to start was fine, though this recent proposal seems to also support certificates, albeit only by "reference." While this seems like a small addition at face value -- what's different from a certificate reference with size equal to an RPK? -- I think it changes the shape of the desired AKE in ways that are perhaps unintentional. For example, it assumes some type of PKI in which these certificates exist and through which endpoints handle tasks such as revocation and transparency. That may impose requirements on the AKE. TLS had to carve out extension support for CT and OCSP. Is that something we want to take on when starting down the path towards an efficient AKE? I'm not sure. Moreover, it does seem like the environment in which this type of AKE exists and would be used is different from one that only supports PSKs and RPKs. (The latter being an environment with less dependencies.)

Overall, while I appreciate the attempt to clarify scope, I think including certificates complicates the story and will make progress on an efficient AKE -- the goal of this group -- more difficult. I strongly suggest we limit this to PSKs and RPKs only.

Best,
Chris

On Mon, Apr 20, 2020, at 5:25 AM, Mališa Vučinić wrote:
> Hi all,
> 
> This is a kind reminder to take a look at the proposed PR and provide 
> feedback, especially if you disagree with the proposed text. With the 
> remaining issues on the requirements documents resolved, we would like 
> to converge on the best way forward for the working group, so please 
> provide your comments by the end of this week, Friday the 24th.
> 
> Mališa
>

---

From: Göran Selander <[email-masked]>
Date: Mon, 27 Apr 2020 09:23:09 +0000

Hi Christopher,

As you remember, the scope of this work have been discussed (outside ACE) since Jan 2019. Support for PKI and certificates has been included throughout the different steps, the virtual Secdispatch interim March 2019, the LAKE BoF July 2019, etc., each occasion followed by a consensus call with large support. Removing all kind of PKI support from the scope would be a drastic last minute change.

The use of certificates is important for efficient trust management in deployments with large numbers devices, and is one of the driving forces for moving away from PSK-based IoT deployments. The number of IoT devices is projected to surpass the number of web servers world wide by orders of magnitude. A common building automation deployment can have thousands of devices from several manufactures. If this is not the setting where we want to use a PKI, then what is? 

If we want the IETF to provide a relevant contribution to securing constrained IoT we cannot exclude device certificates. Instead we should design the AKE so that these deployments can use certificates in a simple and efficient way. Referencing certificates instead of transporting them over constrained links is a key component here.

> I think including certificates complicates the story and will make 
> progress on an efficient AKE

I am not convinced by the "complication" argument because it is hard to measure at this stage. I think the scope should to be defined by what we need to solve and what we believe we can solve efficiently, as was motivated in the proposal.

> I thought Ben's suggestion to focus only on PSK and RPK modes to start 
> was fine, though this recent proposal seems to also support certificates, '
> albeit only by "reference." 

Please read the first line in the proposal again. The proposed scope is RPK + certificate by reference, not PSK + RPK + certificate by reference. So, this is in fact good news for those who are concerned about complications, since removing the PSK based authentication protocol is a significant simplification of design, specification, analysis, implementation and testing. But, again, I think we should refrain from the "complication" argument and instead focus on what we need to solve (and to get started!). 

In contrast to removing certificates from the AKE, removing PSK seems not to notably impact the desirable scenarios where this can be applied, since RPK by reference can perform as good as PSK. Furthermore, I interpreted Ben's mentioning of PSK and RPK as just an example, based on the discussion we had at the latest LAKE virtual interim about the cases where a candidate protocol can perform optimally. Not that this subset necessarily was the subset we should restrict to. 

> it assumes some type of PKI in which these certificates exist and through 
> which endpoints handle tasks such as revocation and transparency. 
> That may impose requirements on the AKE. TLS had to carve out 
> extension support for CT and OCSP. Is that something we want to take 
> on when starting down the path towards an efficient AKE?

The efficiency of the AKE need not be restricted by allowing validation of certificates. This discussion really belongs to the design phase but starting it anyway, there are two cases:

1. The endpoint receiving the certificate reference can retrieve information about the validity of the certificate over a non-constrained link, see e.g. draft-selander-ace-ake-authz. In this case no validation information needs to be carried in the AKE. The validation is performed by the endpoint according to policy and is essentially decoupled from the AKE.

2. The endpoint has access to the certificate but not timely validation information. For example if the device is built-to-order and pre-provisioned with the target network certificate(s). In this case some validation information may need to be carried in the AKE. 

I think we should keep also case 2 in the initial scope, at least to allow us to determine during the design phase if there is a simple lightweight solution that matches existing standards and tools, or else leave it for later. I committed one change to the PR to this point:

https://github.com/lake-wg/reqs/commit/91d32c2

Göran

On 2020-04-25, 02:17, "Lake on behalf of Christopher Wood" <[email-masked] on behalf of [email-masked]> wrote:

    Best,
    Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 27 Apr 2020 06:09:31 -0700

On Mon, Apr 27, 2020, at 2:23 AM, Göran Selander wrote:
> Hi Christopher,
> 
> As you remember, the scope of this work have been discussed (outside 
> ACE) since Jan 2019. Support for PKI and certificates has been included 
> throughout the different steps, the virtual Secdispatch interim March 
> 2019, the LAKE BoF July 2019, etc., each occasion followed by a 
> consensus call with large support. Removing all kind of PKI support 
> from the scope would be a drastic last minute change.

I'm aware, but I think it's the right thing to do in the near term. 

> The use of certificates is important for efficient trust management in 
> deployments with large numbers devices, and is one of the driving 
> forces for moving away from PSK-based IoT deployments. The number of 
> IoT devices is projected to surpass the number of web servers world 
> wide by orders of magnitude. A common building automation deployment 
> can have thousands of devices from several manufactures. If this is not 
> the setting where we want to use a PKI, then what is? 

I can't comment on whether or not this makes sense. I don't work in the space. All I'm suggesting is to focus on small cases first. 

I'll note also that it's *possible* to have your cake and eat it too, as demonstrated by Tailscale [https://tailscale.com/blog/how-tailscale-works/]. We could design an AKE that works with only public keys, or even PSKs for that matter, and move everything else to the application layer. To me, this demonstrates the certificates need not be baked into the protocol to solve the use case you (may?) have in mind.

> If we want the IETF to provide a relevant contribution to securing 
> constrained IoT we cannot exclude device certificates. Instead we 
> should design the AKE so that these deployments can use certificates in 
> a simple and efficient way. Referencing certificates instead of 
> transporting them over constrained links is a key component here.
> I am not convinced by the "complication" argument because it is hard to 
> measure at this stage. I think the scope should to be defined by what 
> we need to solve and what we believe we can solve efficiently, as was 
> motivated in the proposal.
> 
> Please read the first line in the proposal again. The proposed scope is 
> RPK + certificate by reference, not PSK + RPK + certificate by 
> reference. 

This is *your* proposal, not Ben's. I'm referring to (and prefer) Ben's suggestion, for the reasons stated in my email. 

> So, this is in fact good news for those who are concerned 
> about complications, since removing the PSK based authentication 
> protocol is a significant simplification of design, specification, 
> analysis, implementation and testing. 

Are you suggesting that the holistic design and implementation of an AKE that uses certificates is less complicated than use of PSKs?

> But, again, I think we should 
> refrain from the "complication" argument and instead focus on what we 
> need to solve (and to get started!). 
> 
> In contrast to removing certificates from the AKE, removing PSK seems 
> not to notably impact the desirable scenarios where this can be 
> applied, since RPK by reference can perform as good as PSK. 
> Furthermore, I interpreted Ben's mentioning of PSK and RPK as just an 
> example, based on the discussion we had at the latest LAKE virtual 
> interim about the cases where a candidate protocol can perform 
> optimally. Not that this subset necessarily was the subset we should 
> restrict to. 
> 
> The efficiency of the AKE need not be restricted by allowing validation 
> of certificates. This discussion really belongs to the design phase but 
> starting it anyway, there are two cases:

I think the important bit here is that the AKE (TLS) had to be extended to support these emerging technologies after-the-fact. This suggests the AKE should minimally be extensible if things such as revocation are not in scope for an initial certificate-focused design. It may have other implications not yet known, too. Have we carved out enough space for these sorts of things? I'm not sure.

Best,
Chris

> 1. The endpoint receiving the certificate reference can retrieve 
> information about the validity of the certificate over a 
> non-constrained link, see e.g. draft-selander-ace-ake-authz. In this 
> case no validation information needs to be carried in the AKE. The 
> validation is performed by the endpoint according to policy and is 
> essentially decoupled from the AKE.
> 
> 2. The endpoint has access to the certificate but not timely validation 
> information. For example if the device is built-to-order and 
> pre-provisioned with the target network certificate(s). In this case 
> some validation information may need to be carried in the AKE. 
> 
> I think we should keep also case 2 in the initial scope, at least to 
> allow us to determine during the design phase if there is a simple 
> lightweight solution that matches existing standards and tools, or else 
> leave it for later. I committed one change to the PR to this point:
> 
> On 2020-04-25, 02:17, "Lake on behalf of Christopher Wood" 
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     Apologies for the delay, all! I thought Ben's suggestion to focus 
> only on PSK and RPK modes to start was fine, though this recent 
> proposal seems to also support certificates, albeit only by 
> "reference." While this seems like a small addition at face value -- 
> what's different from a certificate reference with size equal to an 
> RPK? -- I think it changes the shape of the desired AKE in ways that 
> are perhaps unintentional. For example, it assumes some type of PKI in 
> which these certificates exist and through which endpoints handle tasks 
> such as revocation and transparency. That may impose requirements on 
> the AKE. TLS had to carve out extension support for CT and OCSP. Is 
> that something we want to take on when starting down the path towards 
> an efficient AKE? I'm not sure. Moreover, it does seem like the 
> environment in which this type of AKE exists and would be used is 
> different from one that only supports PSKs and RPKs. (The latter being 
> an environment with less dependencies.)
> 
>     Overall, while I appreciate the attempt to clarify scope, I think 
> including certificates complicates the story and will make progress on 
> an efficient AKE -- the goal of this group -- more difficult. I 
> strongly suggest we limit this to PSKs and RPKs only.
> 
>     Best,
>     Chris
> 
>     > > On 15 Apr 2020, at 14:19, Göran Selander 
> <goran.selander=[email-masked]> wrote:
>     > > 
>     > > Hi,
>     > > 
>     > > On 2020-04-09, 12:09, "Lake on behalf of Göran Selander" 
> <[email-masked] on behalf of 
> goran.selander=[email-masked]> wrote:
>     > > 
>     > >    All,
>     > > 
>     > >    Apologies for a long mail. Comments on Ben's proposal for a 
> way forward at the end, but first we need to take a step back and try 
> to understand what we are discussing.
>     > > 
>     > >    We are working on requirements for an AKE for OSCORE. We 
> require a lightweight AKE, since OSCORE may be applied in constrained 
> IoT applications. Now there is a discussion about restricting the 
> functionality of LAKE to address only the most lightweight scenarios, 
> so that another AKE should be used in non-lightweight settings. While 
> this may be an economy of standardization, this does not make sense for 
> many reasons.
>     > > 
>     > >    * Note that OSCORE is expected to be applied in both in 
> constrained and non-constrained environments. OSCORE works whereever 
> CoAP does, and CoAP is expected to be applied in PSK, RPK and 
> certificate settings.
>     > > 
>     > >    * Implementation-wise OSCORE is more or less integrated with 
> CoAP, because it reuses CoAP processing. A combined OSCORE/AKE 
> implementation will thus be more or less integrated in CoAP. So how 
> should a developer handle the situation that there is a specification 
> of AKE1 addressing part of the credential space and another completely 
> incompatible specification AKE2 addressing another part? 
>     > > 
>     > >    * OSCORE is designed for end-to-end security from 
> constrained device to cloud. To be sure to support OSCORE based 
> security you need to implement both AKE1 and AKE2.
>     > > 
>     > >    * How could it be better security-wise to have two different 
> AKEs for one security protocol? Twice the number of security analyses, 
> etc. are needed. 
>     > > 
>     > >    * Many companies want to move away from symmetric-key based 
> IoT deployments to public key based, ideally to device certificates. If 
> their current technology does not support transport of certificates, 
> but maybe will later,  should they implement AKE1 or AKE2?
>     > > 
>     > >    * etc.
>     > > 
>     > >    Summarizing: At some point in time there needs to be one 
> single AKE for OSCORE that is sufficiently lightweight to perform well 
> in the most constrained settings but also has the functionality to 
> protect CoAP for whatever settings it is expected to be deployed in, 
> and that involves PSK, RPK and certificates.
>     > > 
>     > >    Having said this, it may still be relevant to discuss which 
> cases are most important right now, bearing in mind that this scoping 
> should not prevent later adding the remaining components.  
>     > > 
>     > >    One way to prioritize the scope of the first work on the AKE 
> is to address a) the needs from current use cases, and b) the potential 
> to provide something useful that is not already available:
>     > > 
>     > >    a) There is a general request to deploy a lightweight AKE 
> with OSCORE targeting general CoAP use cases 
>     > >    i.e. based on PSK, RPK as well as certificates. More 
> specific work items I'm aware of include RPK-based solutions (e.g. LoRa 
> Alliance) and mixed RPK/certificate based solution (e.g. 
> draft-selander-ace-ake-authz). As mentioned in my previous email, a 
> PKI-based solution is necessary to handle IoT deployments with a large 
> number of devices and many manufacturers, but the certificate does not 
> necessarily have to be transported.
>     > > 
>     > >    b) It is possible to do PSK and RPK by reference for the 
> most constrained benchmark (1,1,1). RPK by value and certificate by 
> reference can also be very lightweight, but may require more than one 
> fragment per message. However, in case of transporting a chain of X.509 
> certificates, or even a single X.509 certificate, it is not clear that 
> a lightweight AKE performs significantly better. 
>     > > 
>     > >    The intersection of a) and b) correspond to where there is 
> an active interest in a solution and where the solution can be made 
> lightweight: RPK (by reference and value) and certificate by reference. 
>     > > 
>     > >    This restricted scope leaves out the most lightweight and 
> the least lightweight options. Removing symmetric key based 
> authentication from first scope is a significant simplification since 
> this is a different protocol in many respects compared to the 
> asymmetric version. Moreover, since PSK and RPK by reference can be 
> handled with the same transmission cost, there is less motivation for 
> using PSK ECDHE as an intermediate deployment step.
>     > > 
>     > >    Now for Ben's proposal:
>     > > 
>     > >    On 2020-04-08, 17:41, "Lake on behalf of Stephen Farrell" 
> <[email-masked] on behalf of [email-masked]> wrote:
>     > > 
>     > >        Ben's proposal is:
>     > > 
>     > >        "
>     > >    [GS] Focus on RPK (by value and by reference) and 
> certificate by reference, and do that well. For RPK by reference: 3 
> flights in (1,1,1) fragments. For RPK by value and certificate by 
> reference the number of fragments should be kept at a minimum.
>     > > 
>     > >

---

From: Göran Selander <[email-masked]>
Date: Mon, 27 Apr 2020 15:18:09 +0000

Hi Chris,

Thanks for quick response, comments inline.

On 2020-04-27, 15:10, "Christopher Wood" <[email-masked]> wrote:

    I'll note also that it's *possible* to have your cake and eat it too, as demonstrated by Tailscale [https://protect2.fireeye.com/v1/url?k=0bc73d2d-574ee76a-0bc77db6-0cc47ad93c18-4e312ba1cd3cf468&q=1&e=20eb74ed-8a0d-4c42-a29c-06c545b31b25&u=https%3A%2F%2Ftailscale.com%2Fblog%2Fhow-tailscale-works%2F]. We could design an AKE that works with only public keys, or even PSKs for that matter, and move everything else to the application layer. To me, this demonstrates the certificates need not be baked into the protocol to solve the use case you (may?) have in mind.

[GS] I glanced at the reference and it looks interesting but I'm not sure how it fits with the IoT device deployment setup. Could you please elaborate?

[GS] I probably should not continue this argument, but just to clarify: I'm talking about the "also" in your text above. And about the "e.g." in Ben's proposal, see also the "Furthermore  ... " in my previous response, below.

[GS] I was thinking about the part which we need to specify in LAKE, not the use of existing protocols for outside the AKE. We could compare the case of passing a reference to a device certificate to that of passing a reference to a device public key. What does the receiver have to do in the different cases? Both certificate and public key needs to be "validated" by the receiver. If the public key is pre-provisioned and never revoked that is of course a simpler case, but also has management and security implications. For the certificate reference it could be a simple validation request similar to or simultaneously with the certificate retrieval. Although the security considerations of the AKE need to prescribe validation, the validation step can be outside the AKE (assuming case 1 in my previous email). I don't know how to measure the difference but I was thinking that part to be not so complicated in comparison to a separate PSK based protocol. For the case of passing revocation information in the AKE (case 2 in my previous email) that is of course an additional effort, but there may be some low hanging fruit in that context.

    > starting it anyway, there are two cases:

    I think the important bit here is that the AKE (TLS) had to be extended to support these emerging technologies after-the-fact. This suggests the AKE should minimally be extensible if things such as revocation are not in scope for an initial certificate-focused design.

[GS] Good suggestion. I think allowing some simple mechanism for verifying validity should be in the initial scope, but having it as an extension would be the backup plan.

Thanks
Göran

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 27 Apr 2020 08:32:31 -0700

Hi Göran,

Please see inline below!

On Mon, Apr 27, 2020, at 8:18 AM, Göran Selander wrote:
>     I can't comment on whether or not this makes sense. I don't work in 
> the space. All I'm suggesting is to focus on small cases first. 
> 
>     I'll note also that it's *possible* to have your cake and eat it 
> too, as demonstrated by Tailscale 
> [https://protect2.fireeye.com/v1/url?k=0bc73d2d-574ee76a-0bc77db6-0cc47ad93c18-4e312ba1cd3cf468&q=1&e=20eb74ed-8a0d-4c42-a29c-06c545b31b25&u=https%3A%2F%2Ftailscale.com%2Fblog%2Fhow-tailscale-works%2F]. We could design an AKE that works with only public keys, or even PSKs for that matter, and move everything else to the application layer. To me, this demonstrates the certificates need not be baked into the protocol to solve the use case you (may?) have in mind.
> 
> [GS] I glanced at the reference and it looks interesting but I'm not 
> sure how it fits with the IoT device deployment setup. Could you please 
> elaborate?

Again, I don't work in this space. I simply claim -- with a great deal of hand waving -- that it may be possible!

>     This is *your* proposal, not Ben's. I'm referring to (and prefer) 
> Ben's suggestion, for the reasons stated in my email. 
> 
> [GS] I probably should not continue this argument, but just to clarify: 
> I'm talking about the "also" in your text above. And about the "e.g." 
> in Ben's proposal, see also the "Furthermore  ... " in my previous 
> response, below.
> 
>     Are you suggesting that the holistic design and implementation of 
> an AKE that uses certificates is less complicated than use of PSKs?
> 
> [GS] I was thinking about the part which we need to specify in LAKE, 
> not the use of existing protocols for outside the AKE. We could compare 
> the case of passing a reference to a device certificate to that of 
> passing a reference to a device public key. What does the receiver have 
> to do in the different cases? Both certificate and public key needs to 
> be "validated" by the receiver. If the public key is pre-provisioned 
> and never revoked that is of course a simpler case, but also has 
> management and security implications. For the certificate reference it 
> could be a simple validation request similar to or simultaneously with 
> the certificate retrieval. Although the security considerations of the 
> AKE need to prescribe validation, the validation step can be outside 
> the AKE (assuming case 1 in my previous email). I don't know how to 
> measure the difference but I was thinking that part to be not so 
> complicated in comparison to a separate PSK based protocol. For the 
> case of passing revocation information in the AKE (case 2 in my 
> previous email) that is of course an additional effort, but there may 
> be some low hanging fruit in that context.

Surely if we're considering the cost of implementing the AKE, we ought to consider all its dependencies too, right? That is, if we support certificates, we should probably consider the cost in doing so, and that cost is a measure of the AKE and whatever else is needed to "validate" them. 
 
>     I think the important bit here is that the AKE (TLS) had to be 
> extended to support these emerging technologies after-the-fact. This 
> suggests the AKE should minimally be extensible if things such as 
> revocation are not in scope for an initial certificate-focused design.
> 
> [GS] Good suggestion. I think allowing some simple mechanism for 
> verifying validity should be in the initial scope, but having it as an 
> extension would be the backup plan.

That might work. I'd like to hear from others about what they think here.

Best,
Chris

---

From: Göran Selander <[email-masked]>
Date: Wed, 29 Apr 2020 06:57:14 +0000

Hi Chris, 

Please see response inline.

[GS] Yes, there is a cost associated to a PKI. But there is an even higher cost associated to managing PSK, in terms of provisioning, managing secret keys, etc.  If we consider all dependencies we should also add the costs associated with a compromise, the damage to the asset which is intended to be protected, the loss of brand value, etc., and that the risks associated with PSK-based deployments are much higher. Total cost of ownership is in fact one of the reasons why companies want to move away from manual provisioning towards automated certificate based trust management.

I think it would be hard to prove that the total cost associated with PSK is lower than with certificates, which is the difference between your proposal and what is currently in the requirements draft.

Göran

    Best,
    Chris

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 29 Apr 2020 13:40:01 +0200

Hi all,

Göran will publish the next version of the requirements document, i.e. the authors’ best guess at resolving the issues based on the current state of discussion on the list and on github. The aim is to solicit comments on the diff and see if we can converge on this document.

Mališa

> On 29 Apr 2020, at 08:57, Göran Selander <goran.selander=[email-masked]> wrote:
> 
> Hi Chris, 
> 
> On 2020-04-27, 17:33, "Christopher Wood" <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Göran Selander <[email-masked]>
Date: Wed, 29 Apr 2020 12:04:25 +0000

Hi all,

Version -03 submitted:
https://datatracker.ietf.org/doc/html/draft-ietf-lake-reqs-03

This version is intended to address the WGLC comments and the following discussion. One editorial comment by Stephen is not addressed yet:
https://github.com/lake-wg/reqs/issues/28
Please let us know if we missed some other comment.

Diff against -02 is here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lake-reqs-03

Göran

From: Mališa Vučinić <[email-masked]>
Date: Wednesday, 29 April 2020 at 13:40
To: Göran Selander <[email-masked]>
Cc: Christopher Wood <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lake] proposed scoping text

Hi all,

Mališa

On 29 Apr 2020, at 08:57, Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>> wrote:

Hi Chris,

On 2020-04-27, 17:33, "Christopher Wood" <[email-masked]<mailto:[email-masked]>> wrote:

Göran

But, again, I think we should
refrain from the "complication" argument and instead focus on
what we

In contrast to removing certificates from the AKE, removing PSK
seems

not to notably impact the desirable scenarios where this can be
applied, since RPK by reference can perform as good as PSK.
Furthermore, I interpreted Ben's mentioning of PSK and RPK as
just an

example, based on the discussion we had at the latest LAKE
virtual

interim about the cases where a candidate protocol can perform
optimally. Not that this subset necessarily was the subset we
should

restrict to.

it assumes some type of PKI in which these certificates exist
and through

which endpoints handle tasks such as revocation and
transparency.

That may impose requirements on the AKE. TLS had to carve out
extension support for CT and OCSP. Is that something we want to
take

The efficiency of the AKE need not be restricted by allowing
validation

of certificates. This discussion really belongs to the design
phase but

   Best,
   Chris

--
Lake mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lake