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 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 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
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,
There are currently 12 open PRs [1] against the DTLS 1.3 specification
generated in response to Ben's review [2]:
- Require that cipher suites define a record number encryption algorithm (#166)
- PMTU estimates (#168)
- Updates to cookie text (#169)
- Clarify buffering and retransmission requirem
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
Yoav,
Thanks for pulling together this PR
(https://github.com/tlswg/tls-flags/pull/5). There’s already some comments in
the PR. If anybody has comments please jump in. Note that this is the last
outstanding issue and we would like to close this in order to progress the I-D.
spt
> On Jan 1, 20
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
The TLS WG will meet at IETF 110. The chairs have requested a 2 hour slot [0]
and would like to solicit input from the WG for agenda topics. Please send your
agenda topics request and an estimate for how much time you will need to
tls-cha...@ietf.org. Please note that we will prioritize existing
Martin Duke has entered the following ballot position for
draft-ietf-tls-external-psk-importer-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
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 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 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 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.
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
15 matches
Mail list logo
