Re: [mile] Artart last call review of draft-ietf-mile-rolie-10

Martin Thomson <martin.thomson@gmail.com> Mon, 16 October 2017 00:46 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8D1332D4; Sun, 15 Oct 2017 17:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 i9G13exjYFbK; Sun, 15 Oct 2017 17:46:01 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 F2FF11321A4; Sun, 15 Oct 2017 17:46:00 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id c77so22552556oig.0; Sun, 15 Oct 2017 17:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=sLzsNn++IwhX3r92s4rlJrfjSX9RMYx9Su6zRyqsKBOGx1QN3l2gSzYbcG7766I5YC KGxLONbgYY4BrGt1Qm1OyCGV/pAhAM4gK6doNjFHSK3TFmKnoNmjVM9H6ItlAhZ6Dsxd oiprNsLOP1MPjToiOWxpLMT9mwHMTkotbEYYewbYv0f/Y9kzQ+xg0eo0vRvMYAKaSwHm Cwz2kbOpQrTE+6NPuqvWp6TWLQz+KzgtCZEo+BDj3lDzb2KQ4hWQDIsN06gA53dzmhLQ O1+/g8/2JIZ9GdRCqshYCe39lSJfgAT/OcIw9v/MrH2h4I9PjHHf6Z4Ll03DqWtLVBPG mOrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=F9e9EaWqw3U8o5w8DWUfFts4sM7Se0mapE+Lt5ELRifhE97/3zpNyRi8fVBmaTkBCL NGD1m5N8ywHcfEpL/yrL3CM+83xcvSFxPuffRq7RdDDMYMDWCwXcd8bZFID7fjZXvVHH In6ixh8YIjiy46bR870keb0fndoPu7ue+3ZNyA4jUDNp/tfblvKwyjmoFTKosmWZSADQ 3kIavwAwEsoYV8M7lKMVvi+41ztf8u2xQQSEZ9Dkuu3KIoRTaUAjzwMKEC57wbOz7KvR R6+c4WTDI2ULylgKslC1+mBaN1m1ZLjP0lZnOV0ogJH+I5ryXjJVwJSzMrwzjpu+ZwKe CVhg==
X-Gm-Message-State: AMCzsaWzMD0yD3J4JeJ2kufV2RPvp/RnPoEgjmj7qnecOSUF29+aY7sj AepipArSSdxnEJJErhE0NuD52fW2+K8EQ+LLn/c=
X-Google-Smtp-Source: ABhQp+R+nsaXB6wXT7UXf53FTH8UvyE9ceffNHzXtg3FCa2wanZRvG9KinR4McP+SvcrmwsumkXDp3dqr8fuTg8KMt8=
X-Received: by 10.157.53.17 with SMTP id o17mr2687144otc.35.1508114760103; Sun, 15 Oct 2017 17:46:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 17:45:59 -0700 (PDT)
In-Reply-To: <CAHbuEH7dC7TcgzYmEEjfRh5HHcu4Mu1eOm9MWzq8EH9v3EGTmw@mail.gmail.com>
References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <CABkgnnXdq6GKBXrowPTva1MU+X6WSMR2uB7df-2oHaKv=_2rdA@mail.gmail.com> <CAHbuEH5C_GAkeLj6Pda5usY4PYXb1uwY8jzwnnvAV6Ao7v+d2A@mail.gmail.com> <CABkgnnU8BAdaB05-VQR6R=Ei-E_Ji=OZvVXa=JzX=UoFFDS2wA@mail.gmail.com> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> <CABkgnnU=FJvYzjK0B8z3Ry=W9DXzd98Miw8YB2cP9r0tFeef8A@mail.gmail.com> <CAHbuEH7dC7TcgzYmEEjfRh5HHcu4Mu1eOm9MWzq8EH9v3EGTmw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 16 Oct 2017 11:45:59 +1100
Message-ID: <CABkgnnVS+h_A8Yz5fYn0SLXnnCHLLO6vFRnU+6kvnedR-=rPWg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, ART Area <art@ietf.org>, MILE IETF <mile@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, draft-ietf-mile-rolie.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/Ty8G5VZfrR331ZfeK33eC1QkWdI>
Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Oct 2017 00:46:03 -0000

On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> wrote:
> The systems running ROLIE will be ones that enterprises will regard as
> high value assets. Replay attack and lack of forward secrecy aren't
> acceptable.  The same will be true of many other HTTP enabled
> services.  A performance gain isn't worth the trade off.

My point isn't to reject this sort of analysis, which is possibly
correct, but to point out that this analysis is one that a deployment
makes based on the circumstances

Everyone thinks that their thing is a special snowflake, and that's
OK, but you are asking for a levy on all implementations that would
prevent use of 0-RTT in all deployments.  I think that is
inappropriate.  I don't want to see every draft that the IETF ever
published making its own assessment and a policy statement regarding
this particular feature.  (We don't mandate a particular
authentication mechanism here either.)

Note that TLS 1.3 permits resumption without forward secrecy.  It's
not widely implemented that way, but it is possible.  If you care
about forward secrecy (I'm not sure that it's especially critical in
this context given the time-sensitive nature of the information you
are talking about), then you have to make statements about that as
well.  But again, I would not on the same grounds: the purpose of this
work is to define what interoperability looks like, not to legislate
deployment configuration.  Explain the trade-off and let the
operational teams do their work.