On Thu, Oct 31, 2019 at 04:25:57PM +, Mohit Sethi M wrote:
>Hi Ben,
>
>Thanks for the customary careful review. Answers in-line:
>
>On 10/31/19 4:24 PM, Benjamin Kaduk via Datatracker wrote:
>
> Benjamin Kaduk has entered the following ballot position for
&
A couple things that stand out to me from having basically read the whole
thread in one go (this is not intended to be an exhaustive list of open
questions):
It was implied but not fully clear to me, that Ryan thinks that someone so
inclined could, right now, go around trying to connect to wifi
Hi Michael,
You mention in a couple places that EAP server certificate should be
identifying an rfc822Name DN, and I think I'm confused about what you mean.
(I suspect I'm seeing "rfc822Name" and jumping to what ACP does, which is
wrong.) Could you walk through an example of what that would look
On Sat, Apr 04, 2020 at 10:48:03PM -0700, Murray Kucherawy via Datatracker
wrote:
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/
>
>
>
>
Hi all,
I'm not 100% sure if I'll be present for the whole session on Friday, so
just in case I'm not: it looks like there's a figure in the slides to
adjust the TLS 1.3 key schedule and put another input slot in place.
I don't expect any of these comments to be a big surprise (especially given
Hi Mohit,
Sorry for the slow response.
On Fri, Jul 31, 2020 at 02:08:44PM +, Mohit Sethi M wrote:
> Dear all,
>
> Thanks all for the discussion on the commitment message.
>
> draft-ietf-emu-eap-tls13-10
> (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows
> the
On Sat, Jul 11, 2020 at 03:40:25PM +0200, Carsten Bormann wrote:
> Hi Mohit,
>
>
> > On 2020-07-11, at 15:27, Mohit Sethi M
> > wrote:
> >
> > EAP-NOOB also relies on the JWK specification for encoding public keys.
> > While CBOR equivalent is defined in RFC 8152, it is a rather large
On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M wrote:
> > What I am gathering is that this commitment message should instead be
> > made into a confirmation message, i.e. it should only be sent after
> > receiving TLS Finished from the
list (cc'd).
Thanks,
Ben
On Wed, Dec 16, 2020 at 02:36:50PM -0800, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-emu-eap-tls13-13: Discuss
>
> When responding, please keep the subject line intact and reply to
On Wed, Nov 04, 2020 at 04:41:07PM +, Mohit Sethi M wrote:
> Hi Ben,
>
> This should hopefully address your feedback:
> https://github.com/emu-wg/eaptls-longcert/commit/d39c1411c908844cc74bc0a6fa689a73ecd5b7a8
>
> Answers in-line.
Thanks Mohit!
I left one wording tweak
Hi Stefan,
Thanks for the review; it raises some good topics.
Replying on a couple points...
On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatracker
wrote:
> Reviewer: Stefan Santesson
> Review result: Has Nits
>
> The document in general is good and well written.
>
> Some
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 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
On Tue, Jan 05, 2021 at 11:12:21AM -0500, Alan DeKok wrote:
> On Jan 5, 2021, at 11:05 AM, Michael Richardson wrote:
> >
> > Alan DeKok wrote:
> >> Therefore, we need an explicit signal to the EAP-TLS layer that the
> >
> > Do you mean, "to the EAP layer"?
> > s/EAP-TLS layer/EAP/ ??
>
> If
Hi Mohit,
The quoting in your note is not coming across usefully in my MUA, so I'm
trimming to (what I think are) just your remarks without other history.
On Fri, Jan 29, 2021 at 07:34:42PM +, Mohit Sethi M wrote:
> Hi Ben,
>
> RFC 5705 says:
>
>If no context is provided, it then
Hi Alan,
With my apologies to everyone on the thread for so many mails in
succession...
On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote:
> On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk wrote:
> > With respect to the exporter usage, I do see you had asked about using the
>
On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote:
> On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote:
> > DISCUSS: the EAP-TLS draft should also explain that session tickets may be
> > sent either before or after the 0x00 octet. Does the packet flow look any
> > different for the
On Mon, Feb 01, 2021 at 06:21:16AM +, Peter Gutmann wrote:
> Alan DeKok writes:
>
> >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages
> >*after* the Finished message. i.e. the Session Ticket, etc. When an
> >application calls SSL_Read(), all of the TLS data is
On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote:
> On Feb 1, 2021, at 1:30 PM, Joseph Salowey wrote:
> > [Joe] This could also address the early export of keys before the peer is
> > authenticated. RFC 5216 provides a canonical way to create these IDs, but
> > I'm not sure anyone
On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote:
> On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk wrote:
> > That's a scenario that I was starting to puzzle over this weekend as well
> > -- with EAP-Success "completely unauthenticated", it would be fairly easy
&g
Hi Alan,
I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.
On Sat, Jan 23, 2021 at 05:28:10PM
Hi Alan,
I'll second the thanks for putting this together; I think it covers the
important open points.
I did belatedly remember one more thing that is perhaps not critical, but
would also be good to get an answer for:
On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote:
[...]
>
>
On Wed, Feb 10, 2021 at 10:48:10AM +, John Mattsson wrote:
> With Alan's comments, I think we are down to 3 alternatives:
>
> (1a). Use close_notify alert as protected success.
> Use error alerts as protected failure.
>
> - Forbid close_notify except as success indication
> -
rl2=draft-ietf-emu-eap-noob-05.
>
> Answers inline.
>
> --Mohit
>
> On 4/22/21 7:26 AM, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-emu-eap-noob-04: Discuss
> >
> > When resp
Benjamin Kaduk has entered the following ballot position for
charter-ietf-emu-05-02: No Objection
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.)
The document, along
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-rfc5448bis-07: No Objection
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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-session-id-04: 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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-session-id-05: No Objection
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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-tls13-13: 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 to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eaptlscert-06: Yes
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 to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-noob-04: 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 to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-noob-05: No Objection
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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-tls13-20: No Objection
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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-tls13-20: 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 to https
35 matches
Mail list logo
