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

[Dick Hardt <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> Sent: Friday, June 5, 2020 9:36 AM
> To: Mike Jones <[e-mail]>; Robert Sparks <
> [e-mail]>; [e-mail]; Valery Smyslov <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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" <[e-mail]> 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 <[e-mail]>
>     Sent: Friday, June 5, 2020 8:26 AM
>     To: Mike Jones <[e-mail]>; Robert Sparks <
> [e-mail]>; [e-mail]
>     Cc: [e-mail]; [e-mail];
> [e-mail]
>     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" <[e-mail]> wrote:
>
>         Thanks for the quick reply.  My responses are inline, prefixed by
> "Mike>".
>
>         -----Original Message-----
>         From: Robert Sparks <[e-mail]>
>         Sent: Thursday, June 4, 2020 2:51 PM
>         To: Mike Jones <[e-mail]>; [e-mail]
>         Cc: [e-mail]; [e-mail];
> [e-mail]
>         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 <[e-mail]> On Behalf Of Robert
> Sparks
>         > via Datatracker
>         > Sent: Friday, May 8, 2020 11:57 AM
>         > To: [e-mail]
>         > Cc: [e-mail];
> [e-mail];
>         > [e-mail]
>         > 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
>         > [e-mail]
>         > https://www.ietf.org/mailman/listinfo/id-event
>
>
>
>
> ᐧ