Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Sun, 04 November 2018 02:35 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D273812F1A6; Sat, 3 Nov 2018 19:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=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 50eLcRHB-kT8; Sat, 3 Nov 2018 19:35:07 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 DA89112F1A5; Sat, 3 Nov 2018 19:35:06 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id u6-v6so5002425ljd.1; Sat, 03 Nov 2018 19:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iNJEnZkvV2SUt3pe1Qu4TrfwwC5Jvk4j0y6RK8QdPK8=; b=BM1uu2zUX2cL/QVJaElgYxutW1AnRFRiAx1UEi2E49x5NXQTRL1a/VJwN1nWFBfSVe fRQ7u63t9AZ+ReZOIkdHBNGbfT88mGhz40pquL+r++6yvWMc9Rv+ms1anOzqbrgxaK2w +RfQ2wQX7Ao+Tgi8Qo68BbHElasHRtuitzSKyslGb1Qui0q/5FiOaunplHrLPjuglukI 3SirmG37lTNv+d8H+6vW463Snd6DZ8mr/oOZ+4o05TavJRyCvF6eZ7Ba3sZhvw1F3kjz x2V1p7iAPL8bA/RN1HImQdNgXMcmK1VA70TUdIVsgPfPwL881Z1bY4dE/cHIJ5wX72PY RYuQ==
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=iNJEnZkvV2SUt3pe1Qu4TrfwwC5Jvk4j0y6RK8QdPK8=; b=bScAsJVIbWdn/KVRZJM2iABxNyPMOyOtwEyqTPRmiD/+UV70bxtwt8qh6dwZQnJ+Mr gyfhftd4G5TOtiSw9QmdKKHg1WgLcQLH3QmUSR7Q4Ltwn4gZoUXD7k1avw978x0U6vhk LEX+akaFarbnZWYTuvSxUQ/uSZaAn83INinL6ffq7kKareW5jUuzbBbvtCRpwq71zll+ m0wUfMZJucRPVEyP2DNoyVoXj37NyTANsyOIQTuHEEWIZoy3ni1ALeQwcHjNfUVjMq6u Jz85/t9x5T6XP0RuOrzPlIqgVHRFt6lAY3n7hsTG5aq4Q2C9ZvdD8vkZW6OgjWzJoJ+O Eo+g==
X-Gm-Message-State: AGRZ1gIkL5QOrQsb2XABnP/KBtBM7sOPrsy5Qt3EpB2G6qXic3FJehlg HRPUAfMrGlS12cNrB7/p8qgL0r5RLIeZzoz4quw=
X-Google-Smtp-Source: AJdET5fxNT/R1FfS5i7U1PSt6Ob8iEywK83KjRzQfmUSEpOi+iBnOZQG6g0HUzu2lEA+iGsFhddX3uFwa6rWZBrTmM4=
X-Received: by 2002:a2e:851a:: with SMTP id j26-v6mr1060626lji.163.1541298904637; Sat, 03 Nov 2018 19:35:04 -0700 (PDT)
MIME-Version: 1.0
References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> <A6F37FDD-77F6-497B-B35F-652CF0A29C48@akamai.com> <CAO8oSXnQ4caha7R6buzb3J67WEzjKd7qiBKY+9qCwNymdoeoRw@mail.gmail.com> <CAKKJt-dL2x4U43YcFn1PALR5txNwQRE4mhyZqE0__UDs6TdgxQ@mail.gmail.com>
In-Reply-To: <CAKKJt-dL2x4U43YcFn1PALR5txNwQRE4mhyZqE0__UDs6TdgxQ@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Sun, 04 Nov 2018 09:34:53 +0700
Message-ID: <CAKKJt-dv+FxXWV4oCES59NogC4B1g--sQQ9Ae5K8JgbOy=dWWA@mail.gmail.com>
To: Christopher Wood <christopherwood07@gmail.com>
Cc: "Falk, Aaron" <aafalk@akamai.com>, taps WG <taps@ietf.org>, Theresa Enghardt <theresa@inet.tu-berlin.de>, draft-ietf-taps-transport-security@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b426e60579cd9d1a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/nweFoUO2zAJlVjUPKCYdUfHgNSI>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 02:35:10 -0000

Just following up ...

On Fri, Nov 2, 2018 at 4:34 AM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Hi, Christopher,
>
> On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood <
> christopherwood07@gmail.com> wrote:
>
>> Hi Aaron,
>>
>> On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk <aafalk@akamai.com> wrote:
>>
>>> Dear Authors,
>>>
>>> We agreed at the last IETF that the authors would send a note when this
>>> draft was ready for SecDir review. Is it ready? Do you want to talk about
>>> Theresa's comments in Bangkok first?
>>>
>>
>> It is not yet ready. We will send it to SecDir when that changes. I don’t
>> think Theresa’s comments are blockers here. (I’ll spin a new version with
>> her comments for submission when the tracker reopen.)
>>
>
I spoke to Tero, who is the SecDir secretary, and he told me that they get
requests for early SecDir review that say "this document isn't ready for a
reviewer to look at all of it, but what we think is stable, is Section Foo,
on Bar, and we'd like for you to look at that" (or, "we finished everything
except Section Mumble on Fratz, so you don't need to look at that"). He's
OK with assigning those reviews, and providing those directions.

So, there's that possibility as well.

Spencer


> Given that TAPS meets fairly late on Wednesday, if you think there will be
> discussion that a SECDIR reviewer might benefit from, it is likely possible
> to let the secdir secretaries at
> https://datatracker.ietf.org/group/secdir/about/ know that a request for
> early review will be coming, so that a reviewer could be identified early
> enough to be present.
>
> If that won't be a helpful discussion for a reviewer to listen to, of
> course, no need. Do the right thing :-)
>
> Spencer
>
>
>> Best,
>> Chris
>>
>>
>>> --aaron
>>>
>>> On 26 Oct 2018, at 5:15, Theresa Enghardt wrote:
>>>
>>> Dear TAPS,
>>>
>>> having shepherded the minset draft, and, in the process, having seen a
>>> lot of discussion around security, where we mostly pointed to the
>>> security survey draft, I gave this draft another read in the current
>>> version, with a focus on Section 5.
>>>
>>> Thanks for the update, this document was a good read.
>>>
>>> However, I have some comments, which I'm sharing now rather than later,
>>> just in case there's anything which is better discussed in-person in
>>> Bangkok.
>>>
>>>
>>> Right now, the abstract states that this document is a survey of
>>> security protocols. I suggest to add text saying that the document also
>>> provides a minimal set of security features. Essentially, this document
>>> and minset together cover the "minimum requirements of a secure
>>> transport system".
>>>
>>>
>>> In Section 5, the document groups security features into mandatory and
>>> optional features, and states their transport dependency and application
>>> dependency. Application dependency, for me, relates to whether a feature
>>> is "functional", "optimizing", or "automatable" (in minset terminology).
>>> For example, if there is no application dependency, the feature is
>>> "automatable" and does not have to be exposed to the application. In
>>> contrast, a "function" feature needs to be exposed to the application.
>>>
>>> In Section 5.1, I am missing transport dependency and application
>>> dependency for the mandatory transport features. For example, I would be
>>> interested to know what is the minimum that the transport system needs
>>> to expose to the application for public-key based authentication?
>>>
>>> In Section 5.1, what is "unilateral responder authentication", which I
>>> haven't found in other places in the document under this name?
>>>
>>> In Section 5.2, "Session caching and management" has no application
>>> dependency. However, later in Section 6.1, we do expose Session Cache
>>> Management to the application. My interpretation is that this is just an
>>> "optimizing" feature, which is why there is no application dependency,
>>> but it is still useful to expose. It might help to make this explicit in
>>> the text.
>>>
>>> In Section 5, do we want to mention any security features related to
>>> integrity protection?
>>>
>>>
>>> As far as I can see, none of the protocols we survey provide any
>>> features explicitly providing privacy. Maybe this is worth highlighting
>>> in the Security considerations section, beyond saying that no claims of
>>> privacy properties are made.
>>>
>>>
>>> Finally, I would be in favor of asking for a Secdir early review to make
>>> sure we're not missing anything in the survey.
>>>
>>>
>>> Thank you again for this draft. I really appreciate that we're
>>> discussing transport security features in this way.
>>>
>>>
>>> Best,
>>> Theresa
>>>
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>>
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>>
>>