Re: [Gen-art] [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09

Mike Jones <Michael.Jones@microsoft.com> Tue, 09 June 2020 01:18 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796A63A08CC; Mon, 8 Jun 2020 18:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 PvdK0KlptDxZ; Mon, 8 Jun 2020 18:18:14 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650120.outbound.protection.outlook.com [40.107.65.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FC23A08CB; Mon, 8 Jun 2020 18:18:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EDeg6kV9/+1LarodNDljJTE34VSJI/OvR1LnMk4YXDlpLsOxy9gROgeQrvYbjnscJELZs0x9gbCOyWJQY2abEKrC7/4JKqxOyR3SafAfWOMalz9XMvGiqQzqipaNFM8elY5emVfZrSk6o9S9umdwsHRwe7eBDmpxqm5psBBtjdt1mLJh6YeZ1YJZddg6toGt9BpBaeY5H13M+LBpcyr/b6q7RB5qJ7wzcDL6NQRNo08BIuUQPvXyyUE87oFpvoO7I9DKWd4yQNqokf/3IQ9viBnpGVLGxb1PdYhGtIYy8B9RecxZKbbsCYQvuPvNhf024ppt8ZnBho9mhWvA4jCxGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o1aWW42IngoncdL6LWB0L115ih33DamcGtiX9nDCEk8=; b=dvPZamBbV9c8vsswbIDQM/xRfQCq3PxMFAoHmIN0/pdSpmgB9YItl1BE3hXiwMaotdC323LIpepyGyNzvnCufLnRy4ECYyMpDox9RXP6OZAtHq+BZRqOmods2FSo6TA+MOtvKrLCvO/hYwIPfFv+6SThbQgz8VCMCUwHnO48Iw6q43QX5S5UUeJ/kTDTf2PGo2zx9ptrnYMdR+0og/vcADl9aaZMX28n8IifKJTIXBvBL9AiUepeXi9gQ5svY5g0W1VsqVj5AUiwYxN8Z9y+Q8xdo9aojrHFlm+gsqVfv1yrhs3Xv2Rmg87AaRbh0pHg6kzx7VrOGWRElozH4LpYgA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o1aWW42IngoncdL6LWB0L115ih33DamcGtiX9nDCEk8=; b=S9T76ICRhDYKtPuplmKpQsGtnkb76fuP34Y2c08vLjnLbjN90xVph8xAb+EggZphqr8erbT48VTCw89q8xTdflkKpjyW9nML+iMjl1xYz7lSvvmnNDEnvitEdkzRsXDWvTHWcJdZlG38bJFwfbn6ZDJgiXYQ7Y+qYHXUCk2sslY=
Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0861.namprd00.prod.outlook.com (2603:10b6:208:1da::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3120.0; Tue, 9 Jun 2020 01:18:12 +0000
Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::b816:9dfb:f80d:3b9f]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::b816:9dfb:f80d:3b9f%8]) with mapi id 15.20.3114.000; Tue, 9 Jun 2020 01:18:11 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Robert Sparks <rjsparks@nostrum.com>, "gen-art@ietf.org" <gen-art@ietf.org>, Valery Smyslov <svan@elvis.ru>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-secevent-http-poll.all@ietf.org" <draft-ietf-secevent-http-poll.all@ietf.org>, "id-event@ietf.org" <id-event@ietf.org>
Thread-Topic: [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09
Thread-Index: AdY60xKyY1QDrK2JRA2b52VtQpNZPAAennSAAAG2FFAAAMJ6AACofBOg
Date: Tue, 09 Jun 2020 01:18:11 +0000
Message-ID: <MN2PR00MB0686DEED5B3EFDB8E14E1FB1F5820@MN2PR00MB0686.namprd00.prod.outlook.com>
References: <CH2PR00MB0678026DC6A8BE87C1068B12F5860@CH2PR00MB0678.namprd00.prod.outlook.com> <AB3CE273-1CCE-4A7B-A95B-52A38C78C45C@gmail.com> <CH2PR00MB0678F645A6828D0C1C8986F0F5860@CH2PR00MB0678.namprd00.prod.outlook.com> <E37BB397-D02E-4B26-BAF6-7101D96D156E@gmail.com>
In-Reply-To: <E37BB397-D02E-4B26-BAF6-7101D96D156E@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1b986625-5be0-4911-a135-0000e3bbef3c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-09T01:00:31Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b885eed3-9baf-47d3-e6cd-08d80c12fa35
x-ms-traffictypediagnostic: MN2PR00MB0861:
x-microsoft-antispam-prvs: <MN2PR00MB0861415698C16EB498E42A16F5820@MN2PR00MB0861.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 042957ACD7
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 11GMUfpLngbt97i6YJwvdVcb+sLHzBHSZk+xltADDqGRPq9AJ1AuLINb/1BCqEGxOu0bWdpGtlypZS3KsHNgYGWE5ws1enF3AI9qfQNgLZ7gj+pjqN1/dFgJp2otcDDL5H82xUyh7tf9vjgEqw2uHKbZ/D0V3ztBhTLHW7/hi1AoWOWMPxLDMceq+ByesRCHma8o6nkIs3x4lLhKVYlq+vGRdhR9YanChNyli+81TGSokTaTTD/+KK/UrgrvjvJLOSAhWBwgujcgBZKFWEg8qYxwuNgJOvwodZJdZfjgdjm0vXNcdzMem3IhiGUGN/uYpc5yKLj87Bx8IQb70bRc/r5xoBs5/8GSiv8HlmE/Q5rTPtIzUQcq3BMBUWfoHI5SxMqJru4tNqbJLqq4oOWDWw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(39860400002)(346002)(396003)(136003)(86362001)(83380400001)(52536014)(8936002)(10290500003)(82950400001)(4326008)(478600001)(966005)(5660300002)(9686003)(82960400001)(26005)(33656002)(55016002)(53546011)(186003)(110136005)(2906002)(316002)(76116006)(64756008)(66556008)(6506007)(66446008)(66946007)(66476007)(54906003)(71200400001)(8676002)(8990500004)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: CeilUkpQcTX0TwwBG+KLAt1C7wMkctiWoPHD3XT1HqMlMIHC7Y7jzuHwV1ZohrwNH/OuD1W/mxnENRke90nPJrWqNrtD1mhG6vtLGFhIko6mS3KuxnEBHBSIa1TT2eTY6cspB92TIyknDJn53YkaxS3CZwrFSJz0woItUL7j8J2puFM+XGVw9OMT39bAH2JymVNwlOudInipzQvrnr0702xQT5sXrfykgI4pbvXfn7txRXe2z6pruU7ni0C2bdVbu1shoS2d61RJVv9BPDcOTkp5/hJXMsG+GWKLFpo122og9u6F2yB0Djk6K2CKmVkn3R1W+VyV5qNhphs92MljRICNDKVJPnQOuNx2YHetRHiWMuVgxJwaHbqs7TrfTFcWBNcZF/7SeqmDC0lUlMiayUnEpexKj2vhwUnvd5pHlLhxFxrpiuxqLpNA2FISIJai+o4yW/VfZx6Vk+tAum+KB+wgNGk0Nkggvr/0H73GM8c=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b885eed3-9baf-47d3-e6cd-08d80c12fa35
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 01:18:11.8402 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4TtBLDXzzL93SGRlQU+O7kh4nfAtwvl6gEG2ttlOZCLzw4IpvUrxx3CZkmnSvKINTl7KEoOxhMAneoHOncq3ng==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0861
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/iPkCBkYCCFMhuQfZ3AoJNNfX5n0>
Subject: Re: [Gen-art] [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 01:18:17 -0000

I agree that the spec should give clear guidance on whether TLS is required.  People should read Phil Hunt's comments (which I just forwarded to the list) and consider where we'd like to land in this regard.

I agree that if we decide to mandate TLS, rather than simply integrity-protected SETS, we should modify the Section 3 text below:
   The SET delivery method described in this specification is based upon
   HTTP and HTTP over TLS [RFC2818] and/or standard HTTP authentication
   and authorization schemes, as per [RFC7235].
to remove the "HTTP and".

Likewise, we'd need to revise 4.3 to remove the non-TLS choice.  We can also revise the first sentence of 4.4.1 to make it clear that 6750 requires TLS, regardless of other decisions we make.

Note that some of the language in question is also present in draft-ietf-secevent-http-push, so we should apply consistent changes there as well.

I hope to hear back from the working group with your thoughts this week.

				-- Mike

-----Original Message-----
From: Yaron Sheffer <yaronf.ietf@gmail.com> 
Sent: Friday, June 5, 2020 9:36 AM
To: Mike Jones <Michael.Jones@microsoft.com>; Robert Sparks <rjsparks@nostrum.com>; gen-art@ietf.org; Valery Smyslov <svan@elvis.ru>
Cc: last-call@ietf.org; draft-ietf-secevent-http-poll.all@ietf.org; id-event@ietf.org
Subject: Re: [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09

Hi Mike,

The document is very ambiguous regarding the use of TLS, and frankly I wish we noticed it earlier.

- The first sentence of Sec. 3 has TLS as one of two options: "The SET delivery method described in this specification is based upon HTTP and HTTP over TLS [RFC2818] and/or standard HTTP authentication and authorization schemes, as per [RFC7235]. "

- Similarly in Sec. 4.3, TLS is mentioned as one alternative, not a requirement: "In such cases, SET Transmitters and SET Recipients MUST protect the confidentiality of the SET contents by encrypting the SET as described in JWE [RFC7516], using a transport-layer security mechanism such as TLS, or both. "

- Sec. 4.4.1 (first sentence) also treats TLS as conditional.

My personal opinion is that nowadays we can simply mandate TLS, but I'm open to discuss it. Whatever the WG chooses, the document needs to be clear and consistent.

Thanks,
	Yaron

On 6/5/20, 19:22, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

    That TLS is used is specified in the first sentence of the introduction at https://tools.ietf.org/html/draft-ietf-secevent-http-poll-09#section-1.  It's also in the first paragraph of https://tools.ietf.org/html/draft-ietf-secevent-http-poll-09#section-3.

    The new privacy considerations text was requested by Valery Smyslov in the SecDir review of push.  I also added it here.  I did think it was odd that it was requested when TLS is required, but it seemed harmless to add it.  If you like, I could clarify that this should never occur.

    				-- Mike

    -----Original Message-----
    From: Yaron Sheffer <yaronf.ietf@gmail.com> 
    Sent: Friday, June 5, 2020 8:26 AM
    To: Mike Jones <Michael.Jones@microsoft.com>; Robert Sparks <rjsparks@nostrum.com>; gen-art@ietf.org
    Cc: last-call@ietf.org; draft-ietf-secevent-http-poll.all@ietf.org; id-event@ietf.org
    Subject: Re: [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09

    Hi Mike,

    I'm looking at the latest PR, specifically at the Poll document. I can see that you changed the text around signing SETs, but I don't see any new (or existing) text that requires HTTPS as you noted in your response to Robert.

    I even see this new text "If SETs are transmitted over unencrypted channels" that confuses me even more. For the latter, maybe you meant something like: If SETs are transmitted over unencrypted channels while being processed in an otherwise protected system.

    Thanks,
    	Yaron

    On 6/5/20, 03:49, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

        Thanks for the quick reply.  My responses are inline, prefixed by "Mike>".

        -----Original Message-----
        From: Robert Sparks <rjsparks@nostrum.com> 
        Sent: Thursday, June 4, 2020 2:51 PM
        To: Mike Jones <Michael.Jones@microsoft.com>; gen-art@ietf.org
        Cc: last-call@ietf.org; draft-ietf-secevent-http-poll.all@ietf.org; id-event@ietf.org
        Subject: Re: [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09


        On 6/4/20 4:27 PM, Mike Jones wrote:
        > Thanks for your review, Robert.  I'm working on addressing the review comments received and wanted to have a clarifying discussion on some of yours before deciding what corresponding edits to make.
        >
        > I think there's a misunderstanding about "jti" values and the security 
        > model.  Because communication is over a TLS-protected channel

        Not always, and that's an important part of my point.

        See the first sentence of section 4.1:

        "   In scenarios where HTTP authorization or TLS mutual authentication
            are not used or are considered weak, "

        Mike> Frankly, the text you're citing never seemed very clear or well motivated to me.  It was written by an earlier editor who since stopped working on the spec.  I'm going to just remove it and unambiguously require HTTPS.

        > between two parties, it would be fine if the JTI values were totally guessable, such as "A", "B", "C", etc.  There's no opportunity for an attacker to inject traffic into or to listen to the stream.  Does that make sense to you?
        _If_ it were never possible for authorization to be weak or for TLS auth to not be used, then sure. But the exception you call out at 4.1 exactly allows someone to be an attacker this way.
        >
        > As for limits on how long a transmitter is required to hold a SET, I propose to add this text:
        >        Transmitters may also discard undelivered SETs under deployment-specific conditions,
        >        such as if they have not been polled for over too long a period of time
        >        or if an excessive amount of storage is needed to retain them.
        That's better, but consider being a bit more specific about "too long".

        Mike> That's deployment-specific, but I'm open to wording suggestions.

        >
        > 				-- Mike
        >
        > -----Original Message-----
        > From: Id-event <id-event-bounces@ietf.org> On Behalf Of Robert Sparks 
        > via Datatracker
        > Sent: Friday, May 8, 2020 11:57 AM
        > To: gen-art@ietf.org
        > Cc: last-call@ietf.org; draft-ietf-secevent-http-poll.all@ietf.org; 
        > id-event@ietf.org
        > Subject: [Id-event] Genart last call review of 
        > draft-ietf-secevent-http-poll-09
        >
        > Reviewer: Robert Sparks
        > Review result: Ready with Issues
        >
        > I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
        >
        > For more information, please see the FAQ at
        >
        > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
        >
        > Document: draft-ietf-secevent-http-poll-09
        > Reviewer: Robert Sparks
        > Review Date: 2020-05-08
        > IETF LC End Date: 2020-05-13
        > IESG Telechat date: Not scheduled for a telechat
        >
        > Summary: Essentially ready but with some issues to consider before 
        > publishing as a Proposed Standard RFC
        >
        > This document is well-written and easy to follow.
        >
        > I have a couple of edge-case issues that I think should be considered though:
        >
        > This document allows, and anticipates, deployments where Recipients are not well authenticated. See, for example, the first sentence of section 4.1. There is also an unstated expectation in the document that the jti of each SET is hard to guess.  If it's reasonably easy to guess jti values, a malicious Recipient could ack SETs it has never received and the Transmitter will remove that state, preventing a valid Recipient from ever receiving that SET.
        >
        > If that's an explicit requirement in the jwt or SET base documents for the jti to be hard to guess, please point me to it? If there's not, perhaps a short discussion in the security considerations requiring this property would be worthwhile?
        >
        > Is there a discussion somewhere of how long the transmitter is required to hold a given SET for a Recipient? Forever seems unreasonable.
        >
        >
        >
        > _______________________________________________
        > Id-event mailing list
        > Id-event@ietf.org
        > https://www.ietf.org/mailman/listinfo/id-event