Top posting to explain the need for a reliable notification of protocol
completion:
On 1/4/21 5:44 AM, Martin Thomson wrote:
I have a much simpler one: the EAP layer has a signal that the protocol is
complete: EAP-Success
Alan Dekok explained in a separate email thread why this is not the cas
On Jan 3, 2021, at 10:44 PM, Martin Thomson wrote:
> # Key Schedule
>
> The other thing I observe is the way that this slices up the exporter output.
> This was something that old versions of TLS did, but TLS 1.3 did away with.
> Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok wrote:
> On Jan 3, 2021, at 10:44 PM, Martin Thomson wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output. This was something that old versions of TLS did, but TLS 1.3 did
> away with. Though
On Jan 4, 2021, at 9:40 AM, Eric Rescorla wrote:
> That's easy enough to change at this state. The question is what are those
> labels?
>
> They're just strings, so as long as they don't conflict, it's largely up to
> the EAP WG.
My point was more that we cannot afford to wait another yea
On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote:
> > I have a much simpler one: the EAP layer has a signal that the
> > protocol is complete: EAP-Success
> Alan Dekok explained in a separate email thread why this is not the
> case
> (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASo
On Jan 4, 2021, at 6:26 PM, Martin Thomson wrote:
> Your point about reliability is confusing. I've read Section 4.2 of RFC 3748
> and while it says "A peer MUST allow for this circumstance as described in
> this note.", I see no explanation of how to concretely make that allowance.
> Are you
Hi Alan,
On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
> On Jan 4, 2021, at 6:26 PM, Martin Thomson wrote:
> > Your point about reliability is confusing. I've read Section 4.2 of RFC
> > 3748 and while it says "A peer MUST allow for this circumstance as
> > described in this note.", I see n
Hi Martin,
Thanks for chiming in here; your insight has been quite helpful already.
(I am going to reply to the thread in reverse order so as to not duplicate
what you've already said.)
On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote:
> Hi Alan,
>
> On Tue, Jan 5, 2021, at 14:05,
On Tue, Jan 05, 2021 at 10:26:40AM +1100, Martin Thomson wrote:
> On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote:
> > > I have a much simpler one: the EAP layer has a signal that the
> > > protocol is complete: EAP-Success
> > Alan Dekok explained in a separate email thread why this is not
On Mon, Jan 04, 2021 at 02:44:01PM +1100, Martin Thomson wrote:
>
> I would instead either prohibit the use of application data outright or say
> that it carries no semantics unless otherwise negotiated. The current design
> has the effect of rendering application data unusable, so perhaps the
On Fri, Jan 01, 2021 at 05:03:45PM +, Mohit Sethi M wrote:
> Hi Ben,
>
> Thanks for the usual detailed feedback. I haven't yet addressed all the
> comments in your COMMENT section. Below, I copy the comments which have
> now been addressed in github:
> https://github.com/emu-wg/draft-ietf-e
Hi Alan,
I'll try to stick to the stuff that hasn't already progressed more in the
downthread discussions.
On Wed, Dec 16, 2020 at 07:23:45PM -0500, Alan DeKok wrote:
> On Dec 16, 2020, at 5:36 PM, Benjamin Kaduk via Datatracker
> wrote:
> > To start with the easy one: currently the way in whic
On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok wrote:
> On Jan 3, 2021, at 10:44 PM, Martin Thomson wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output. This was something that old versions of TLS did, but TLS 1.3 did
> away with. Though
13 matches
Mail list logo
