Re: [Id-event] AD review of draft-ietf-secevent-http-poll-06

Benjamin Kaduk <kaduk@mit.edu> Sat, 25 April 2020 00:53 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286D73A0BF4; Fri, 24 Apr 2020 17:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 wb0XAwCZp60N; Fri, 24 Apr 2020 17:53:00 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 702333A125C; Fri, 24 Apr 2020 17:52:57 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03P0qrE1002983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Apr 2020 20:52:55 -0400
Date: Fri, 24 Apr 2020 17:52:52 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "draft-ietf-secevent-http-poll.all@ietf.org" <draft-ietf-secevent-http-poll.all@ietf.org>, "id-event@ietf.org" <id-event@ietf.org>
Message-ID: <20200425005252.GC27494@kduck.mit.edu>
References: <DM6PR00MB0682195CCCE92C19A2585777F51C0@DM6PR00MB0682.namprd00.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM6PR00MB0682195CCCE92C19A2585777F51C0@DM6PR00MB0682.namprd00.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/VEf9JxDa-RgfNo0jFVScHtgPvMY>
Subject: Re: [Id-event] AD review of draft-ietf-secevent-http-poll-06
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Apr 2020 00:53:02 -0000

Hi Mike,

Thanks for the updates, and I continue to be sorry for the long response
times.

Poll is in quite good shape (well, I guess it's mostly just that -push is
taking the brunt of the work for harmonizing the differences in text); just
a couple more changes to make and we should be good to start the IETF LCs
in parallel.  I'll again trim the resolved bits.

In Section 3 we have a note about DoS protections embedded in a larger
block of text:

   Authorization for the eligibility to provide actionable SETs can be
   determined by using the identity of the SET Issuer, validating the
   polling endpoint URL, perhaps using TLS, or via other employed
   authentication methods.  Among other benefits, authentication can
   help prevent denial-of-service attacks.  Because SETs are not
   commands, SET Recipients are free to ignore SETs that are not of
   interest after acknowledging their receipt.

I am not 100% sure, but I think this may have been text that originates
before the split of documents, and in push got extracted and made into a
separate section.  Does it still make sense here?  The DoS risk would
typically be for a server getting lots of inbound connections, but there's
not quite as clear a case for (client) authentication helping with that for
poll, since the client is not sending huge amounts of stuff that would need
to be dropped.  Am I misunderstanding the intent here, or should the
sentence just get dropped?

On Fri, Feb 07, 2020 at 05:18:04PM +0000, Mike Jones wrote:
> draft-ietf-secevent-http-poll-07<https://tools.ietf.org/html/draft-ietf-secevent-http-poll-07> was published to address these review comments.  (-08<https://tools.ietf.org/html/draft-ietf-secevent-http-poll-08> addressed additional editorial nits.)  Descriptions of the changes made for these comments are inline, prefixed by "Mike>".
> 
> 
> 
> -----Original Message-----
> From: Id-event <id-event-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> Sent: Tuesday, December 10, 2019 4:37 PM
> To: draft-ietf-secevent-http-poll.all@ietf.org
> Cc: id-event@ietf.org
> Subject: [Id-event] AD review of draft-ietf-secevent-http-poll-06
> 
> 
> Section 3
> 
> 
> Since poll has the TLS server as the SET Transmitter, we could potentially pull in RFC 6125 and talk about validating DNS-IDs to authenticate the Transmitter.  Given that the name to be authenticated would be part of the information conveyed out-of-band, though, it's not entirely clear how much value there would be in doing so.
> 
> 
> Mike> As in Push, this section was formerly poorly worded, and has largely been rewritten.

As for -push, I'd really like to be able to say something about the other
half of the name comparison.  In this case would it be something like
"discovery of SET Transmitters (and the names used to authenticate them) is
out of scope for this document"?

Thanks for the updates,

Ben