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 > > > > > ᐧ
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
