+1. Thanks Mike. Phil
> On Jun 12, 2020, at 12:12 PM, Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > > It appears to me that Yaron, Dick, Annabelle, and Atul Tulshibagwale (on the > OpenID RISC mailing list) have all advocated mandating TLS in response to > Robert Sparks’ and Valery Smyslov’s reviews. Phil Hunt’s response was that > TLS shouldn’t be necessary as long as the SET is “self protected”. > > Given these responses and the now near ubiquity of TLS on the Web, I plan to > edit the two drafts to make it clear that TLS is required to use these > transports. If it makes editorial sense, I plan to try to preserve the > informative guidance that’s currently present about considerations for using > non-secured transports, while making it clear that that guidance doesn’t > apply to these transport mechanisms. I’m thinking of moving those statements > to a non-normative appendix. > > Hopefully we can wrap this up soon and get the new versions scheduled for an > upcoming telechat. > > Cheers, > -- Mike > > From: Richard Backman, Annabelle <richa...@amazon.com> > Sent: Tuesday, June 9, 2020 4:40 PM > To: Dick Hardt <dick.ha...@gmail.com>; Mike Jones > <michael.jo...@microsoft..com> > Cc: last-c...@ietf.org; Valery Smyslov <s...@elvis.ru>; gen-art@ietf.org; > Yaron Sheffer <yaronf.i...@gmail.com>; > draft-ietf-secevent-http-poll....@ietf..org; id-ev...@ietf.org; Robert Sparks > <rjspa...@nostrum.com> > Subject: Re: [Id-event] Genart last call review of > draft-ietf-secevent-http-poll-09 > > While TLS may be redundant in some cases, in practice I don’t see the > requirement to use TLS materially impacting deployments that fit that edge > case. Transmitters/receivers that would be burdened by the > code/time/CPU/memory costs of TLS are probably not going to be communicating > via HTTP in the first place. > > – > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > From: Id-event <id-event-boun...@ietf.org> on behalf of Dick Hardt > <dick.ha...@gmail.com> > Date: Tuesday, June 9, 2020 at 12:04 PM > To: Mike Jones <michael.jo...@microsoft.com> > Cc: "last-c...@ietf.org" <last-c...@ietf.org>, Valery Smyslov > <s...@elvis.ru>, "gen-art@ietf.org" <gen-art@ietf.org>, Yaron Sheffer > <yaronf.i...@gmail..com>, "draft-ietf-secevent-http-poll....@ietf.org" > <draft-ietf-secevent-http-poll....@ietf.org>, "id-ev...@ietf.org" > <id-ev...@ietf.org>, Robert Sparks <rjspa...@nostrum.com> > Subject: RE: [EXTERNAL] [Id-event] Genart last call review of > draft-ietf-secevent-http-poll-09 > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > There were concerns mandating TLS for any SET as it restricts the use of SET > to TLS transports. I would guess the language in the > draft-ietf-secevent-http-pull and draft-ietf-secevent-http-poll followed that > thinking. > > I my personal opinion, mandating TLS for HTTP transports is reasonable (which > is what the specs in discussion use), and that should be changed in both > draft-ietf-secevent-http-pull and draft-ietf-secevent-http-poll > > /Dick > > On Mon, Jun 8, 2020 at 6:18 PM Mike Jones <michael.jo...@microsoft.com> wrote: > 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.i...@gmail.com> > Sent: Friday, June 5, 2020 9:36 AM > To: Mike Jones <michael.jo...@microsoft.com>; Robert Sparks > <rjspa...@nostrum.com>; gen-art@ietf.org; Valery Smyslov <s...@elvis.ru> > Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll....@ietf.org; > id-ev...@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.jo...@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.i...@gmail.com> > Sent: Friday, June 5, 2020 8:26 AM > To: Mike Jones <michael.jo...@microsoft.com>; Robert Sparks > <rjspa...@nostrum.com>; gen-art@ietf.org > Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll....@ietf.org; > id-ev...@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.jo...@microsoft.com> wrote: > > Thanks for the quick reply. My responses are inline, prefixed by > "Mike>". > > -----Original Message----- > From: Robert Sparks <rjspa...@nostrum.com> > Sent: Thursday, June 4, 2020 2:51 PM > To: Mike Jones <michael.jo...@microsoft.com>; gen-art@ietf.org > Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll....@ietf.org; > id-ev...@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-boun...@ietf.org> On Behalf Of Robert > Sparks > > via Datatracker > > Sent: Friday, May 8, 2020 11:57 AM > > To: gen-art@ietf.org > > Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll....@ietf.org; > > id-ev...@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-ev...@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > ᐧ > _______________________________________________ > Id-event mailing list > id-ev...@ietf.org > https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
