Re: [Lake] proposed scoping text

Eric Rescorla <ekr@rtfm.com> Wed, 08 April 2020 15:45 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF1B3A0F11 for <lake@ietfa.amsl.com>; Wed, 8 Apr 2020 08:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7C6grDG3LaI for <lake@ietfa.amsl.com>; Wed, 8 Apr 2020 08:45:52 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E0C3A08C5 for <lake@ietf.org>; Wed, 8 Apr 2020 08:45:51 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id m2so5482100lfo.6 for <lake@ietf.org>; Wed, 08 Apr 2020 08:45:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/yoh7C5LYOrQrGF0dJ2EnBlT2KYUsyyL3VoM+YZy33c=; b=wae1kgIohmNDe7EGRM3P9jTyKseJDDjmFZbURWcxKL4JM4hJ9BBkfSj+YnaOM4Q2/4 tCbtLQr8JhgfHf6PCe1MEq6lEffgfxtmtf8K6E7jm3VKCyM7Obq1BiXlkQ74OrwhqaUI WNCrsPAe6z3Zaor9VkQ4ULHkTa8uy8blY3uvJ/jHbihC0L9sfHJA/X8D497rKCEhyos8 fJwepplVzIOea5+5WlO/E83MtjBXY+dMovJCeaqOdG5ZX6rRwG9yvZR4bU0NGCvXCCae hhrOPEHKQtOayjpIsI9IN2noyyNsbSOfo7ce3jdJPOrGh49L9Q8e/235PLusOfhqhZig CGXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/yoh7C5LYOrQrGF0dJ2EnBlT2KYUsyyL3VoM+YZy33c=; b=dnxwKfFRuSG+cwCaMhONpFEsm8VgAJz+9wyqEJLoNg5UYtC8CtUZGBkB533PEdtTL6 kJw0WjaQyk864svzXE3NgQKuap+rTLp/spmJa3GIiQcZhMEyBnfzhLeyFf0KqdgVb3ru /FKm0BGcR9T+fKiDUshIcFLqU4NMD4Ogxw/3VCHAUMoUcFFT+Xq7NRC0PCnEeLYSC/0A eJyoSny8T3/VlAPbARd0YA8D2QJh6Mypc888Z1ra4wnwxX+p8GdIEu/uODOPvZ7PlHAg Xjbsv6/mNACmtkSX5errgQC5G2ARrPcdvnbHSWCx9IKWXR25zTeWsZ2qWyVqWf+y+b6J +yLA==
X-Gm-Message-State: AGi0PubdhBG6hvECAOtWEXXdSEMOlep2PZu3IkVfXRtRMU/2HfYtwS6y A98dr1fwnXRN7t6+1kwHqzJBwfR7m4SurV8C0Fsrc3Ei4Vh1sA==
X-Google-Smtp-Source: APiQypJDSNyZOlq1c+1XM+DOZrgSkohISh3js88YxIumi5tzu/vL598HAWVPO08UiR0CNz7g6addAzIkIXFKwGKXb94=
X-Received: by 2002:ac2:4d07:: with SMTP id r7mr3927969lfi.14.1586360750095; Wed, 08 Apr 2020 08:45:50 -0700 (PDT)
MIME-Version: 1.0
References: <3780afd5-7012-d808-9584-07e04913cd19@cs.tcd.ie>
In-Reply-To: <3780afd5-7012-d808-9584-07e04913cd19@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 8 Apr 2020 08:45:13 -0700
Message-ID: <CABcZeBMu8=2_KmoW0FCK7N9spcWZX7ZEe-dmFWQ0r6AM_yv5Kg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "lake@ietf.org" <lake@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fed1df05a2c96404"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/svArhNbhniestGIczHd-oZ3epfE>
Subject: Re: [Lake] proposed scoping text
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 15:45:54 -0000

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 <stephen.farrell@cs.tcd.ie>
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
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake
>