@Eric Are you referring to this " ... completing the handshake with
EndOfEarlyData following (which follows) the ClientFinished ..."? Well, I meant
EOED and then ClientFinished. Anyhow, the client part seems to do it correctly.
Thx,
Kristijan
> On 10 Aug 2022, at 00:05, Eric Rescorla wrote:
>
On Tue, Aug 09, 2022 at 04:12:37PM -0700, Eric Rescorla wrote:
> n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote:
>
> > On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
> > >
> > > Be that as it may, the browsers generally require conformance to the BRs
> > > (see, for
> > >
n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote:
> On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
> >
> > Be that as it may, the browsers generally require conformance to the BRs
> > (see, for
> > instance
> >
>
On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
>
> Be that as it may, the browsers generally require conformance to the BRs
> (see, for
> instance
>
Folks,
Let’s keep the discussion here professional and on topic. It’s fine to disagree
with one another, but please do so in a respectful manner per the IETF Code of
Conduct.
Thanks,
Chris, for the chairs
On Tue, Aug 9, 2022, at 6:47 PM, Rob Sayre wrote:
> On Tue, Aug 9, 2022 at 3:40 PM Eric
On Tue, Aug 9, 2022 at 3:47 PM Rob Sayre wrote:
> On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote:
>
>>
>> P.S. I don't think that this tone "...but go on" is particularly helpful
>> in this discussion.
>>
>
> Well, it's easy. You said "require", and I just give very little credence
> to the
On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote:
>
> P.S. I don't think that this tone "...but go on" is particularly helpful
> in this discussion.
>
Well, it's easy. You said "require", and I just give very little credence
to the CABF, because I think it is nonsense.
That can be a point of
On Tue, Aug 9, 2022 at 3:33 PM Rob Sayre wrote:
> On Tue, Aug 9, 2022 at 3:15 PM Eric Rescorla wrote:
>
>>
>>
>> On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
>> wrote:
>>
>>> Hal Murray writes:
>>>
>>> >Many security schemes get tangled up with time. TLS has time limits on
>>>
On Tue, Aug 9, 2022 at 3:15 PM Eric Rescorla wrote:
>
>
> On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
> wrote:
>
>> Hal Murray writes:
>>
>> >Many security schemes get tangled up with time. TLS has time limits on
>> >certificates. That presents a chicken-egg problem for NTP when getting
>>
On Mon, Aug 08, 2022 at 03:18:22PM +0200, Dmitry Belyavsky wrote:
> Dear colleagues,
>
> RFC 8446 refers to "completed handshake" as a prerequisite for some
> messages. But looking for the word "completed", I don't see any definition.
> Could you please point me to it (and probably, include this
On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
wrote:
> Hal Murray writes:
>
> >Many security schemes get tangled up with time. TLS has time limits on
> >certificates. That presents a chicken-egg problem for NTP when getting
> >started.
> >
> >I'm looking for ideas, data, references, whatever?
On Mon, Aug 8, 2022 at 11:52 PM Ilari Liusvaara
wrote:
> On Mon, Aug 08, 2022 at 08:15:41PM +0200, Kristijan Sedlak wrote:
> > Hello everyone.
> >
> > I decided to get involved here since I hit a dead end when resolving
> > an Alert(20) error that I get from almost all servers when using PSK
> >
On Tue, Aug 9, 2022 at 2:47 PM Martin Thomson wrote:
> On Tue, Aug 9, 2022, at 17:49, Ben Smyth wrote:
> > A handshake partially completes on sending/receiving a server's Finished
> > message
>
> I don't see this as "partially complete",
>
The discussion is somewhat misguided anyway. No one is
On Tue, Aug 9, 2022 at 1:57 PM Robert Relyea wrote:
> hybrid is where we should be now. We should have some confidence in Kyber,
> but we have a lot of confidence in RSA and ECC
>
Could you cite the sources of confidence?
thanks,
Rob
___
TLS mailing
On Tue, Aug 9, 2022, at 17:49, Ben Smyth wrote:
> A handshake partially completes on sending/receiving a server's Finished
> message
I don't see this as "partially complete", the way I frame this is that a server
can send prior to the completion of the handshake under some conditions. The
Robert,
I can’t agree more.
Except: Structured Lattices indeed have been around not as long as, e.g., RSA
or ECC - but for how long have RSA or ECC have been around Bauer they were
included in cryptographic protocols? Without Hybrid?
Thanks!
Regards,
Uri
> On Aug 9, 2022, at 16:58, Robert
On 8/6/22 11:40 AM, Phillip Hallam-Baker wrote:
+1
Anything the WG does has to be proof against Quantum Cryptanalysis and
LoW (Laptops on Weekends). The fact that the broken algorithms did not
get picked does not change the fact that they made it to the third round.
Lumping all the
Alright,
1. I tested 0-RTT+EarlyData by removing EOED from the transcript - has no
effect. This should fail, but it seems that the server goes processing ED
immediately and forgets about the rest of the handshake.
2. It's very hard to find a server that accepts EarlyData. I searched the web
On Tue, Aug 9, 2022 at 12:40 AM Hal Murray wrote:
> I work on NTP software. NTS (Network Time Security) uses TLS.
>
> Many security schemes get tangled up with time. TLS has time limits on
> certificates. That presents a chicken-egg problem for NTP when getting
> started.
>
IIRC, this is one
On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
wrote:
> Hal Murray writes:
>
> >Many security schemes get tangled up with time. TLS has time limits on
> >certificates. That presents a chicken-egg problem for NTP when getting
> >started.
> >
> >I'm looking for ideas, data, references, whatever?
On Tue, Aug 09, 2022 at 09:05:31AM +0200, Kristijan Sedlak wrote:
>
> thank’s for replying. I did verify the transcript as well. Everything
> seems to be correct. I bet if it wasn't the 1-RTT and
> 0-RTT(no-early-data) would fail too. Something weird is going on only
> in 0-RTT(early-data) case.
That is not the expected behavior. Likely what is happening is the server
(at the http layer) sees the Connection: close header, and goes to close
the socket for the underlying transport (in this case, the tls stack). The
server’s tls stack, when getting that signal, closes the tls connection,
and
After some sleep, I went playing with the content of the EarlyData sent to the
server and it turned out that the "Connection: close" header must be present in
the HTTP1.1 request. After adding it, the error was gone and the connection
closed with Alert(0).
Is this the expected behavior and
On Tue, 9 Aug 2022 at 08:50, Martin Thomson wrote:
> On Tue, Aug 9, 2022, at 16:36, Ben Smyth wrote:
> > On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote:
> >> "Upon receiving the server's messages, the client responds with its
> Authentication messages, namely Certificate and
On Mon, Aug 08, 2022 at 08:15:41PM +0200, Kristijan Sedlak wrote:
> Hello everyone.
>
> I decided to get involved here since I hit a dead end when resolving
> an Alert(20) error that I get from almost all servers when using PSK
> with EarlyData.
>
> Here's the initial issue I opened
>
On Tue, Aug 9, 2022, at 16:36, Ben Smyth wrote:
> On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote:
>> "Upon receiving the server's messages, the client responds with its
>> Authentication messages, namely Certificate and CertificateVerify (if
>> requested), and Finished. At this point, the
On Mon, Aug 8, 2022 at 4:19 PM Dmitry Belyavsky wrote:
> RFC 8446 refers to "completed handshake" as a prerequisite for some
messages. But looking for the word "completed", I don't see any definition.
On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote:
> "Upon receiving the server's messages,
27 matches
Mail list logo
