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" <[email protected]> wrote:
Thanks for the quick reply. My responses are inline, prefixed by "Mike>".
-----Original Message-----
From: Robert Sparks <[email protected]>
Sent: Thursday, June 4, 2020 2:51 PM
To: Mike Jones <[email protected]>; [email protected]
Cc: [email protected]; [email protected];
[email protected]
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 <[email protected]> On Behalf Of Robert Sparks
> via Datatracker
> Sent: Friday, May 8, 2020 11:57 AM
> To: [email protected]
> Cc: [email protected]; [email protected];
> [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
