On Feb 1, 2021, at 1:00 AM, Joseph Salowey wrote:
[ re: commitment message ]
> [Joe] I'm not sure why it's needed. It's not clear to me why the peer can't
> hold the TLS session open until it receives more TLS messages (handshake or
> alert) or an EAP failure or EAP Success.
I suspect tha
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
> for an on-path attacker to send the EAP-Success the EAP peer was expecting
> and make the EAP
Hi,
It is unclear to me if the current version is expected to address the
comments received during the WGLCs or if further versions are expected.
Just to clarify the current version does not address my comments concerning
the related work section [1].
Yours,
Daniel
[1] https://mailarchive.ietf.o
On Fri, 29 Jan 2021 at 23:38, David Benjamin wrote:
>
> 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_TABL
Oh, and I should say this out loud: my attitude to ALPS has softened
in the past two months or so. I definitely don't want my comments to
be perceived as being in opposition to the adoption of new work by
this WG: I just want to flesh out exactly what problems we're trying
to solve, so that we can
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 CloseNotify meets those. I'll
> ignore the exporter chang
>Asking as the author of a TLS library that has always done this, why would
> you
stop immediately after the Finished and leave metadata messages sitting
unread
in the input stream? Was it just some arbitrary implementation decision, or
is there a technical reason for it?
The mi
Works for me.
> On Jan 31, 2021, at 11:58 PM, Sean Turner wrote:
>
> Do you think this would be clearer:
>
> The maximum validity period is set to 7 days unless
> an application profile standard specifies a shorter
> period.
>
> spt
>
>> On Jan 25, 2021, at 11:14, Russ Housley wrote:
>>
On Feb 1, 2021, at 9:55 AM, Eric Rescorla wrote:
> Let's take the second case first. If the server is sending (or
> potentially sending) post-handshake messages after the client's second
> flight (e.g., after reading its certificate), then it can easily send
> a close_notify after sending all of t
On Mon, Feb 1, 2021 at 7:42 AM Alan DeKok wrote:
> On Feb 1, 2021, at 9:55 AM, Eric Rescorla wrote:
> > Let's take the second case first. If the server is sending (or
> > potentially sending) post-handshake messages after the client's second
> > flight (e.g., after reading its certificate), then
On Feb 1, 2021, at 11:09 AM, Eric Rescorla wrote:
> That's not what I'm proposing. I'm only talking about the case where the
> server says this after flight (2).
OK, my misreading of the text.
> Right. But close_notify is the message that more matches the TLS semantics.
I agree.
> Ignorin
On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok wrote:
> On Feb 1, 2021, at 11:09 AM, Eric Rescorla wrote:
> > That's not what I'm proposing. I'm only talking about the case where the
> server says this after flight (2).
>
> OK, my misreading of the text.
>
> > Right. But close_notify is the message
The IESG has approved the following document:
- 'TLS Ticket Requests'
(draft-ietf-tls-ticketrequests-07.txt) as Proposed Standard
This document is the product of the Transport Layer Security Working Group.
The IESG contact persons are Benjamin Kaduk and Roman Danyliw.
A URL of this Internet Dr
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:
[...]
>
> DISCUS
On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk wrote:
> 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,
On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote:
> Yes, this is what I have in mind. So, maybe there's never any need for the
> server to say "I won't say anything more" after just one round trip?
I think so, yes.
That means of course EAP-TLS will always require 4.5 round trips.
Alan De
On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok
wrote:
> On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote:
> > Yes, this is what I have in mind. So, maybe there's never any need for
> the server to say "I won't say anything more" after just one round trip?
>
> I think so, yes.
>
> That means of c
There has been a lot of discussion on the ending of the handshake that I hope I
have parsed. Here is my perspective as an client implementor (not an author):
1. I don't see a strict requirement for an authenticated signal at the end of
the handshake. No prior version of EAP-TLS needed this and
On Mon, Feb 1, 2021 at 8:46 AM Cory Benfield wrote:
> On Fri, 29 Jan 2021 at 23:38, David Benjamin
> wrote:
> > To clarify, are you unconvinced that ALPS is easier than leaving H2
> alone, or that ALPS is easier than solving this problem with half-RTT? The
> document’s aim is the latter. Your co
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 follows it today
FreeRADIUS does not officially expose Peer-Id or Ser
On Feb 1, 2021, at 2:32 PM, Joseph Salowey wrote:
>
>
>
> On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok wrote:
> On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote:
> > Yes, this is what I have in mind. So, maybe there's never any need for the
> > server to say "I won't say anything more" after j
On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok
wrote:
> On Feb 1, 2021, at 2:32 PM, Joseph Salowey wrote:
> >
> >
> >
> > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok
> wrote:
> > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote:
> > > Yes, this is what I have in mind. So, maybe there's never any ne
On Feb 1, 2021, at 3:00 PM, Joseph Salowey wrote:
> [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
> CloseNotify.
With TLS 1.2, the server sends TLS Finished to the client *after* it sees the
client cert.
With TLS 1.3, the server sends TLS Finished to the client
On Feb 1, 2021, at 2:48 PM, Jorge Vergara wrote:
>
> There has been a lot of discussion on the ending of the handshake that I hope
> I have parsed. Here is my perspective as an client implementor (not an
> author):
>
>
> 1. I don't see a strict requirement for an authenticated signal at the e
On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok
wrote:
> On Feb 1, 2021, at 3:00 PM, Joseph Salowey wrote:
> > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
> CloseNotify.
>
> With TLS 1.2, the server sends TLS Finished to the client *after* it
> sees the client cert.
>
>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : A Flags Extension for TLS 1.3
Author : Yoav Nir
Filename: draft-ietf-tls-tlsflags-0
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 foll
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
> > for an on-path attacker t
RFC 2246 has been reclassified as Historic.
RFC 2246
Title: The TLS Protocol Version 1.0
Author: T. Dierks,
C. Allen
Status: Historic
Stream: IETF
Date: January 1999
Pages: 80
RFC 4346 has been reclassified as Historic.
RFC 4346
Title: The Transport Layer Security (TLS)
Protocol Version 1.1
Author: T. Dierks,
E. Rescorla
Status: Historic
Stream: IETF
Date
RFC 4347 has been reclassified as Historic.
RFC 4347
Title: Datagram Transport Layer Security
Author: E. Rescorla,
N. Modadugu
Status: Historic
Stream: IETF
Date: April 2006
Pages: 25
RFC 5469 has been reclassified as Historic.
RFC 5469
Title: DES and IDEA Cipher Suites
for Transport Layer Security (TLS)
Author: P. Eronen, Ed.
Status: Historic
Stream: IETF
Date: February 2009
Dear all,
After reading all 50 odd emails I'm perpetually confused as to what is
going on, each email and the doc confusing me further. It seems that
similar to QUIC there is an attempt to put TLS over a non TCP
transport and then use for signaling user authentication via X509
certificates, and th
On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk wrote:
> 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 unauth
34 matches
Mail list logo
