Hi,
I can live with any version, the important thing is that interoperable
implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS
1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.
We (the authors) have addressed all the comments from IESG/TLS WG in GitHub
On Jan 29, 2021, at 5:31 AM, John Mattsson wrote:
>
> I can live with any version, the important thing is that interoperable
> implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS
> 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.
Then our choices a
On Jan 29, 2021, at 8:10 AM, Alan DeKok wrote:
> Then our choices are:
>
> a) draft-13 in February. There are multiple interoperable implementations,
> including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.
>
> b) ??? in 2021.
Typo: 2022. :(
__
Hi,
I think Section 6.1 Closure Alerts is a bit unclear:
First it is stated the user_canceled SHOULD be followed by close_notify
"This alert SHOULD be followed by a "close_notify"."
Then it is stated that it MUST be followed by close_notify
"Each party MUST send a "close_notify" alert b
Good catch. I have filed https://github.com/tlswg/tls13-spec/issues/1208 to
address it.
-Ekr
On Fri, Jan 29, 2021 at 6:29 AM John Mattsson wrote:
> Hi,
>
> I think Section 6.1 Closure Alerts is a bit unclear:
>
> First it is stated the user_canceled SHOULD be followed by close_notify
>
>"T
> On Dec 16, 2020, at 00:18, Barry Leiba via Datatracker
> wrote:
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-tls-ticketrequests-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and C
Hi,
3GPP has historically to a large degree used IPsec to protect interfaces in the
core and radio access networks. Recently, 3GPP has more and more been
specifying use of (D)TLS to replace or complement IPsec. Most 3GPP usage of
(D)TLS are long-term connections.
Current best practice for lon
> On Dec 14, 2020, at 02:52, Éric Vyncke via Datatracker
> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-tls-ticketrequests-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and C
> On Dec 14, 2020, at 01:50, Murray S. Kucherawy wrote:
>
> On Sun, Dec 13, 2020 at 10:41 PM Benjamin Kaduk wrote:
> > Some places in this document use "reuse", others "re-use". I'm not sure
> > which
> > one is right, but it should be consistent throughout.
>
> Both are (or, rather, can b
> > — Section 1.1 —
> > Please use the exact BCP 14 boilerplate from RFC 8174 (this one is missing
> > “BCP 14”).
>
> Eagle eye! I would like to propose that we leave this one to the RFC editor.
Sure; maybe Ben can stick in an RFC Editor note to make sure they notice it.
Thanks,
Barry
_
Sean,
Thank you for your reply. I am of course happy with them ;-)
Regards
-éric
-Original Message-
From: Sean Turner
Date: Friday, 29 January 2021 at 16:54
To: Eric Vyncke
Cc: The IESG , "draft-ietf-tls-ticketreque...@ietf.org"
, TLS Chairs , TLS
List
Subject: Re: Éric Vyncke's N
> We need to get agreement on how to proceed here asap. I would like
> implementors and security AD to agree on the way forward before submitting
> -14. Four ways forward:
>
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)
My preference is D.
> Do we need to
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 -050
> On Jan 21, 2021, at 16:50, Daniel Migault wrote:
>
> Hi,
>
> First I deeply apologize for taking so long to respond, I just realized now
> these responses.
No worries it does happen that I miss email from time to time too ;)
> I do not believe a review of IoT protocol is needed, I am mo
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
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other TLS-using
Hi Ben,
On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
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 li
This is a new message to summarize history, requirements, etc. for EAP-TLS
and TLS 1.3. The focus here is the requirements for EAP-TLS, and how the 0x00
commitment message versus CloseNotify meets those. I'll ignore the exporter
changes here, as those are less controversial.
The original
On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M wrote:
> Hi Ben,
> On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
>
> 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 becau
HI Alan,
THanks for this message, comments inline below:
On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok
wrote:
> This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message versus
>>DISCUSS: We have interoperable implementations of -13. Does this mean that
>>the EAP state machines *implicitly* work with the TLS state machines? There
>>is no *explicit* requirement in the draft about ordering, and no discussion
>>thereof. I suspect that this means the implementations wor
Hi all,
Thanks all for the feedback. I’ve tried to address it below, but there's a
lot of text, so please let me know if I’ve missed or misunderstood any of
your points.
Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in
draft-vvv-httpbis-alps-00. I agree that is odd. We’ve uploaded a dr
21 matches
Mail list logo
