On Tue, Aug 30, 2022 at 06:26:41PM -0400, Michael Richardson wrote:
> bc> Right. So I'm not yet convinced we should repurpose the session ID for
> bc> this. If we're going to focus on signing objectives, maybe we need to
> bc> decouple this aspect completely from the session ID?
>
> I
Brian E Carpenter wrote:
tte> So, the question is what attack vector we would open up if we used
tte> sequential session-ids. Given how the signature protects the
tte> message, i will claim there is no new attack vector as long as the
tte> signature is checked. But if GRASP forw
I think Toerless wrote:
>> I don't really know what "all epoch" mechanisms would mean. Ideally we
>> would look for the most easily adopted replay protection mechanism
>> that had in some othr protocol passed IETF SEC standards
>> approval. Whether its called epoch or not.
Brian E
On 30-Aug-22 00:13, Toerless Eckert wrote:
On Sat, Aug 27, 2022 at 09:41:20AM +1200, Brian E Carpenter wrote:
The way i see it, whenever i hae to send another periodical instance of my own
M_FLOOD(s), then i would use a new session-id, and that would perfectly be valid
as a Epoch-ID... except th
On Sat, Aug 27, 2022 at 09:41:20AM +1200, Brian E Carpenter wrote:
> > The way i see it, whenever i hae to send another periodical instance of my
> > own
> > M_FLOOD(s), then i would use a new session-id, and that would perfectly be
> > valid
> > as a Epoch-ID... except that if i randomnly assign
On 26-Aug-22 21:26, Toerless Eckert wrote:
On Thu, Aug 25, 2022 at 11:55:13AM -0400, Michael Richardson wrote:
Ah.
A trusted third party would rain Epoch IDs down on all nodes, both transmitters
and
receivers. They could use signed M_FLOODs.yes, that creates a circular
problem, but the Epo
On Thu, Aug 25, 2022 at 11:55:13AM -0400, Michael Richardson wrote:
> Ah.
> A trusted third party would rain Epoch IDs down on all nodes, both
> transmitters and
> receivers. They could use signed M_FLOODs.yes, that creates a circular
> problem, but the EpochIDs could be arranged to be a hash
