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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 10 October 2017 01:23 UTC

Return-Path: <kathleen.moriarty.ietf@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 293DD134460; Mon, 9 Oct 2017 18:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 vg-Uxlv5Apr8; Mon, 9 Oct 2017 18:23:34 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 D25BC1342E6; Mon, 9 Oct 2017 18:23:34 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id x7so5236424pfa.1; Mon, 09 Oct 2017 18:23:34 -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=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=ZkafJ6AXRlHlWmiJ5FE3SFH6pXyV84GlRNnhnr3HNdbpuITRdipzIXTYDnMbvIbWRZ NeZ/gkSGLNuVyCZEqMey8uLxABgLWMgIHZDrL3M7hVOYHw/abjGSBPEk6Uu7qKP4x6zk gHPmFIYqxne6c7NOm0g52z6hJs/c/uIOQ/QxMKDbCv9IkoraE6+/bxvvu+3HJn9xocNJ pIlLBIfQU5GFGKdOKB+gdzWtkRmPsRSuJUTUL3XInAvyzQ8VM2BWjWGYr/rxEuE/n+h5 Pdah/F5SWbuw9rx0sAACG7oXsebLD/2yIXcosPQ2TQPeZ3Ts6sWZAY3pVaV1MQBEGyCp ZUEw==
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=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=K1R/eZgQMxhq8jWCYcATV7bxVl7Y0GRtmdJq3RNG/mhltSKwEK8QeTr4rnP2Cap2HT mYAZp5V8YGtLr1my3O28XqsfOQ2BzbneHoIdfSbX3G3Ue2sfgt8ozOOVgxZPxeOki14Q jmSJ7AdmvmZ7W9E5s0o/Id/+jfm6KlBMsZPNmutjbzrEhDuNhYSMFR2Oz8WnERweRUuL kWE+nEwJhpokEfZkDxY5NCx6HnDn6srU+WC6ADY86P6F7PfCi6CY588up2tOZ7TAsPpG e58X8kmzh8F4zxIJCDrMKTnjtn968jhwwHnLO9WUoOSnCgL7pLG9AAuUauPMJyR/mqCU sr+g==
X-Gm-Message-State: AMCzsaVGCVzzgrA+R8JQzExFoMOchOFuY0N5B11EHoD/8g80LbDyL+sR /AwbwEQMwzjZUYgOpf+QFlNB6na+YfE2h8mOLwc=
X-Google-Smtp-Source: AOwi7QC7LFUH+TeEYcHhSL69MpNxhqjwhZfgro+msbntCYP4OqbKNKoFsWI/Y6w/YVt/esTiMqL3zuiTXPzt4KCAjy0=
X-Received: by 10.159.244.23 with SMTP id x23mr4494575plr.64.1507598614371; Mon, 09 Oct 2017 18:23:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:22:53 -0700 (PDT)
In-Reply-To: <20171009235717.GN96685@kduck.kaduk.org>
References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 09 Oct 2017 21:22:53 -0400
Message-ID: <CAHbuEH7L1_m8DUFA6eSXDh0zE5kjHTZT-Q2PF7o7b-vdmKWg-w@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Martin Thomson <martin.thomson@gmail.com>, "gen-art@ietf.org" <art@ietf.org>, MILE IETF <mile@ietf.org>, IETF <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/2M1hEWl9CWNneZSifTLJDIsBr7o>
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: Tue, 10 Oct 2017 01:23:36 -0000

On Mon, Oct 9, 2017 at 7:57 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote:
>>
>> The requirements in Section 5.3 on TLS use are unnecessarily strict.  It's
>> great to recommend the use of TLS 1.2, but given that the document has no real
>> requirement on any particular version of TLS, the use of "MUST" here is not
>
> I think that one could make the case that using TLS 1.2 (or higher) greatly
> facilitates having a secure system, and so it could plausibly be required
> by a consuming protocol.

+1 and this has pretty much been standard practice on all protocols
using TLS for at least the last 3 years.  RFC7525 has been a
requirement on most protocols using TLS since it was published.  This
is a protocol that will carry sensitive data and strict requirements
are necessary.  Examples of data that might be exchanged with this
protocol include threat actor information or indicators of compromise.
Strict security is necessary and completely expected by those
deploying this protocol.

>
>> needed.  Similarly, the prohibition on the use of 0-RTT is groundless.  The
>
> I am a little surprised to hear you say that this prohibition is "groundless".
> Given that we require consumers of TLS 1.3 0-RTT data to explictly specify
> an application profile for how it may be used, with the intent to induce
> a careful analysis of the security considerations for sending early data
> messages, it seems quite reasonable to me that a protocol author might
> wish to defer such a painstaking analysis and take the easy choice of
> prohibiting early data.

+1.  In the case of this protocol, there is no tolerance for replay
attacks.  Many other protocols use TLS and will have similar
requirements.  This is likely to be a theme.  The performance gain
isn't worth the tradeoffs - of defining a profile, risking
configuration mistakes, the careful analysis, and weighing the
security considerations.  The 0-RTT decision in the TLS WG has a big
impact on other protocols using it.

Kathleen

>
> -Ben
>
>> lengthy list of requirements around certificate validation only risk creating a
>> conflict with advice in other RFCs.  Many, if not all, of these requirements



-- 

Best regards,
Kathleen