Re: [Lake] proposed scoping text

[Göran Selander <[e-mail]>]

Hi Chris,

Thanks for quick response, comments inline.

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

    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://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?

    > 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. 

    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.

    > 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?

[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.

    > 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:

    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