From nobody Sat May 2 23:39:04 2020 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 791363A161D; Sat, 2 May 2020 23:38:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: last-call@ietf.org, draft-ietf-secevent-http-push.all@ietf.org, id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158848793845.30822.14865138131669756772@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Sat, 02 May 2020 23:38:58 -0700 Archived-At: Subject: [Id-event] Secdir last call review of draft-ietf-secevent-http-push-10 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 06:38:59 -0000 Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines push-based Security Event Tokens (SET) delivery using HTTP transport. I think the document has few issues that are easy to fix. Major issue: 1. Section 5.1: In scenarios where HTTP authorization or TLS mutual authentication are not used or are considered weak, JWS signed SETs SHOULD be used (see [RFC7515] and Section 5 of [RFC8417]). I think this "SHOULD" is inconsistent with RFC8417, which states: Unless integrity of the JWT is ensured by other means, it MUST be signed using JWS [RFC7515] by an issuer that is trusted to do so for the use case so that the SET can be authenticated and validated by the SET recipient. If you believe that there are valid use-cases when unsigned SETs can be transferred over unauthenticated transport (violating MUST from RFC8417), then please describe them. 2. Section 6. I think that Privacy Considerations lack discussion of what information an attacker can learn by analyzing HTTP responses if the HTTP connection is not protected by TLS. In this case even if the SET itself is encrypted, the attacker is able to get some useful information if it can read HTTP responses (e.g. if it is on the path). In particular, it can learn whether the SET is accepted or not and the reason for its rejection. Minor issues: 1. Section 5.1: This [using JWS] enables the SET Recipient to validate that the SET Transmitter is authorized to deliver the SET. I think this sentence is formally wrong, because SET signature allows to identify SET Issuer, but not SET Transmitter. From my reading of the draft they can be different entities. The SET Transmitter in this case remains mostly anonymous. 2. Section 5.2: As stated in Section 2.7.1 of [RFC7230], an HTTP requestor MUST NOT generate the "userinfo" (i.e., username and password) component (and its "@" delimiter) when an "http" URI reference is generated with a message, as they are now disallowed in HTTP. This requirement is already in RFC7230, so is there any need to repeat it? Is it related to security or to interoperability? In the latter case it's better to mention this requirement in Section 2.1. In the former case a few words explaining security implications of this requirement would help. 3. Section 5.4: This may be mitigated by authenticating SET Transmitters with a mechanism with low runtime overhead, such as mutual TLS. I don't think that TLS can be attributed as "a mechanism with low runtime overhead" when you talk about DoS protection. TLS itself may be a target for DoS attacks, because server have to do quite a lot of computations before client presents its authentication information, which may be bogus. So, it has exactly the same problem you described earlier in this para. 4. Section 6. In some cases, subject identifiers themselves may be considered sensitive information, such that their inclusion within a SET may be considered a violation of privacy. SET Transmitters should consider the ramifications of sharing a particular subject identifier with a SET Recipient (e.g., whether doing so could enable correlation and/or de-anonymization of data) and choose appropriate subject identifiers for their use cases. In my understanding of the draft SET Transmitters may be different entities from SET Issuers. I think it is SET Issuers who prepare SETs, not SET Transmitters. In general SET Transmitters don't know what's inside the SET (if JWE is used) and cannot modify it (if JWS is used). 5. (not related to security) Section 2.4: Implementations SHOULD expect that other Error Codes MAY also be received, as the set of Error Codes is extensible via the IANA "Security Event Token Delivery Error Codes" registry established in Section 7.1. I think that the normative "MAY is used improperly here and should be "may" instead. I also think that some words of what implementations should do with unknown error codes would help. Nits: 1. Table 1 is difficult to read due to unusual text formatting within the cells. From nobody Sun May 3 23:52:21 2020 Return-Path: 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 642F83A0CBE; Sun, 3 May 2020 23:52:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mnot.net header.b=T9UKRbUc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DBDJC2OF 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 NGNo9JVphtxJ; Sun, 3 May 2020 23:52:18 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006E13A0CB2; Sun, 3 May 2020 23:52:17 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 3FEE651E; Mon, 4 May 2020 02:52:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 04 May 2020 02:52:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Z Ny/EeQWspvjC3FssNLTj4XFMpUjq1W8NYUBVyDVr7o=; b=T9UKRbUc41IXe2BBc 6UUDEkEBKzhPUqKACA6S9NirbCfzsVaYPB86r3oQkUMePkr/v27v2FhjZEgc0jq7 YLAW2jAbSAqh5kjGmxceTz9O2YK2sdvwLRCEV7yYrVnmsjPNj2TZxhAnITrSHTw8 6XDmYLy21gga2ZP24XQM5rrl3FhHHlaF6OXDb1ASFVHrnt9p7kN0Z4go6TThhYdR 9rOmQzl9DDv8cy41GmQGlHYYaAb+82fxJ+l5JPGubf/sBVYkZj7AcLHxyrYOeFBa VMvnkgGJcPJAMkd+RMgQ2M0TClkDdEAz6V1fmTs2WBRQpzJQ7+uZ9u51z+F0EDTZ geLgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ZNy/EeQWspvjC3FssNLTj4XFMpUjq1W8NYUBVyDVr 7o=; b=DBDJC2OFCmYQMhsPUk2UEClXd2UroFJeSRRTVsp6EQv5yOtWEDPcU/P/p u2OeS6AknM/PorXRnbgegZSWzty7w0OveInG+ielYM827SbSzwZ2tN+Av3naumsq S9YOOpO9WmIbmr5+XRPuokajgWOIpL9OBK2TKCRBCTJnEwA+iD8SMXbKQNZieE0s cPt1UfgvfpRwliwBXQ8s2V+JiVUM1WzijA6DBm5dRt2h22XTjUx1sGQAFuJObuav zEkeeE0hQqDnAJSy7HEPXdkq/CPnCi7oIbvigaOs4oYtSsULgMVc92Lr2ruo8IA3 S8CAurLZQCe/XEMf3y+a6ige5Lpxg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeefgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepvefffffhudetveevhfeuffeigedtue dtheffleetffeftddtgeegjeehieeuteetnecuffhomhgrihhnpehmnhhothdrnhgvthen ucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BAFF3065FF7; Mon, 4 May 2020 02:52:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <158820314329.8065.5649161881109410292@ietfa.amsl.com> Date: Mon, 4 May 2020 16:52:10 +1000 Cc: secevent-chairs@ietf.org, draft-ietf-secevent-http-poll@ietf.org, id-event@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <28F85EC1-B149-48E2-827A-24BD551D7732@mnot.net> References: <158820314329.8065.5649161881109410292@ietfa.amsl.com> To: last-call@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Id-event] Last Call: (Poll-Based Security Event Token (SET) Delivery Using HTTP) to Proposed Standard 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 06:52:19 -0000 Just two comments, based upon a quick read: 1. In section 2: POST is not specific to HTTP/1.1, and it's not good = practice to specify a HTTP version. Just say "HTTP POST". 2. I'm not intimately familiar with the use case, but using POST in this = manner precludes caching as well as fan-out (i.e., "collapsed = forwarding"). Have you considered just using Atom or a similar event = feed structure? Cheers, > On 30 Apr 2020, at 9:32 am, The IESG wrote: >=20 >=20 > The IESG has received a request from the Security Events WG (secevent) = to > consider the following document: - 'Poll-Based Security Event Token = (SET) > Delivery Using HTTP' > as Proposed Standard >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Fri May 8 11:57:01 2020 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C86513A0C18; Fri, 8 May 2020 11:56:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-secevent-http-poll.all@ietf.org, last-call@ietf.org, id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158896421673.10670.4441228115784457096@ietfa.amsl.com> Reply-To: Robert Sparks Date: Fri, 08 May 2020 11:56:56 -0700 Archived-At: Subject: [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 18:56:58 -0000 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 . 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. From nobody Fri May 8 17:04:50 2020 Return-Path: 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 D49D83A02BB; Fri, 8 May 2020 17:04:30 -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 1WquLOlkaqrc; Fri, 8 May 2020 17:04:27 -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 08E203A011F; Fri, 8 May 2020 17:04:26 -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 04904MOL024391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 May 2020 20:04:24 -0400 Date: Fri, 8 May 2020 17:04:22 -0700 From: Benjamin Kaduk To: Mark Nottingham Cc: last-call@ietf.org, secevent-chairs@ietf.org, id-event@ietf.org, draft-ietf-secevent-http-poll@ietf.org Message-ID: <20200509000422.GY27494@kduck.mit.edu> References: <158820314329.8065.5649161881109410292@ietfa.amsl.com> <28F85EC1-B149-48E2-827A-24BD551D7732@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28F85EC1-B149-48E2-827A-24BD551D7732@mnot.net> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Id-event] [Last-Call] Last Call: (Poll-Based Security Event Token (SET) Delivery Using HTTP) to Proposed Standard 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 00:04:32 -0000 Hi Mark, On Mon, May 04, 2020 at 04:52:10PM +1000, Mark Nottingham wrote: > Just two comments, based upon a quick read: > > 1. In section 2: POST is not specific to HTTP/1.1, and it's not good practice to specify a HTTP version. Just say "HTTP POST". Thanks for noting that, it's a good point (and probably just an oversight, as "HTTP POST" is used sevarl times but "HTTP/1.1 POST" just the once). > 2. I'm not intimately familiar with the use case, but using POST in this manner precludes caching as well as fan-out (i.e., "collapsed forwarding"). Have you considered just using Atom or a similar event feed structure? There's a bit of discussion on this point at https://tools.ietf.org/html/draft-ietf-secevent-http-push-08#appendix-A, though Atom itself is not listed there. -Ben From nobody Thu May 14 08:52:55 2020 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B23303A0AFB; Thu, 14 May 2020 08:52:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Joe Clarke via Datatracker To: Cc: last-call@ietf.org, id-event@ietf.org, draft-ietf-secevent-http-push.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158947154667.2243.10642307324359970815@ietfa.amsl.com> Reply-To: Joe Clarke Date: Thu, 14 May 2020 08:52:26 -0700 Archived-At: Subject: [Id-event] Opsdir last call review of draft-ietf-secevent-http-push-10 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 15:52:27 -0000 Reviewer: Joe Clarke Review result: Ready I have been asked to review this documented on behalf of the Ops Directorate. This document describes how to use a push-based method (with HTTP POST) to deliver Security Event Tokens (SETs). Overall, I think this document is ready. It's easy to read, offers clear examples, and discusses various operational issues such as processing required and mitigation of potential DoS attacks. In my reading of the document, I did find a few nits or things I think may want a bit more attention: Section 2: The phrase "business logic" is nebulous. It may be sufficient to say, “anything beyond” the required validation steps. Then you can say further logic to processes SETs SHOULD be executed asynchronously. === Section 2.3: In your error examples, especially the second one, is HTTP 400 always the right error code? I was thinking 403 in this case. === Section 2.4: Similar to me comment above, should this table have recommended HTTP codes? I was thinking invalid_request==422, invalid_key==400, authentication_failed==403, and access_denied==403. === Section 6: Typo s/Transmistters/Transmitters/ From nobody Mon May 18 08:17:38 2020 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7747F3A0765; Mon, 18 May 2020 08:17:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vijay Gurbani via Datatracker To: Cc: draft-ietf-secevent-http-push.all@ietf.org, last-call@ietf.org, id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158981504843.19606.18098780664868333518@ietfa.amsl.com> Reply-To: Vijay Gurbani Date: Mon, 18 May 2020 08:17:28 -0700 Archived-At: Subject: [Id-event] Genart last call review of draft-ietf-secevent-http-push-10 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 15:17:29 -0000 Reviewer: Vijay Gurbani Review result: Ready with Nits 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 . Document: draft-ietf-secevent-http-push-?? Reviewer: Vijay K. Gurbani Review Date: 2020-05-18 IETF LC End Date: 2020-05-13 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready as a Proposed Standard with minor changes as indicated below. Major issues: 0 Minor issues: 1 Nits/editorial comments: 1 Below, "Sn" denotes "Section n". - S2, page 4: "The SET Recipient SHOULD NOT perform extensive business logic that processes the event expressed by the SET prior to sending this response. Such logic SHOULD be executed asynchronously from delivery, in order to minimize the expense and impact of SET delivery on the SET Transmitter." ==> I understand the need for this normative text, however, what happens if at some later point from when the SET Recipient sent a response, the business logic is executed and the logic decides that the SET is invalid. What does a SET Recipient do now? Nits: - S2.3, page 7: s/Access token is expired./Access token has expired./ or s/Access token is expired./Access token expired./ (Reason: "is" is present tense, "expired" is past, so the grammar in the original sentence is incongruous.) From nobody Wed May 27 10:25:54 2020 Return-Path: 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 492CA3A0A86; Wed, 27 May 2020 10:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 t0q8J1qOR5Dx; Wed, 27 May 2020 10:25:50 -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 B10A13A0F79; Wed, 27 May 2020 10:25:50 -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 04RHPkuV030171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 May 2020 13:25:48 -0400 Date: Wed, 27 May 2020 10:25:46 -0700 From: Benjamin Kaduk To: draft-ietf-secevent-http-push@ietf.org, draft-ietf-secevent-http-poll@ietf.org Cc: id-event@ietf.org Message-ID: <20200527172546.GB58497@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Id-event] IETF LC comments on push and poll 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 17:25:52 -0000 Hi all, The IETF LCs for push and poll have completed, getting a few directorate reviews and other comments. I'd like to have a sense of the plan for addressing (or not) those comments in place before I move the documents into IESG Evaluation (and, ideally, to have updated drafts, since the comments suggest some not-entirely-trivial changes). Thanks, Ben