Re: [Lake] proposed scoping text

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
wrote:

>
> 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.
> --
> Lake mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lake
>