On 26 April 2017 at 23:44, Ilari Liusvaara wrote:
> But stopping on receiving EncryptedExtensions with EarlyData extension
> is racy.
How so?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Apr 26, 2017 at 10:00:19PM +1000, Martin Thomson wrote:
> On 26 April 2017 at 17:19, Ilari Liusvaara wrote:
> > AFAIK, the only situations where client can abort sending 0-RTT data
> > is noticing lack of server EarlyData extension (so server isn't
> > listening anyway), or if the entiere
On 26 April 2017 at 22:25, Martin Rex wrote:
>> The code I was talking about was handling the special case that the
>> server might receive either encrypted or unencrypted alert in response
>> to its flight. And the difference it makes is just what error is
>> declared as abort reason.
>
> Up to T
Ilari Liusvaara wrote:
>> In effect, we assume that the entire flight is processed atomically
>> and generate errors based on that. Only when the entire flight is
>> processed cleanly do we install keys and respond.
>
> My implementation processes message-by-message. So it installs the
> client h
On 26 April 2017 at 17:19, Ilari Liusvaara wrote:
> AFAIK, the only situations where client can abort sending 0-RTT data
> is noticing lack of server EarlyData extension (so server isn't
> listening anyway), or if the entiere handshake is aborted.. Doing it
> in other situations leads to subtle ra
On Wed, Apr 26, 2017 at 04:35:31PM +1000, Martin Thomson wrote:
> You are allowed to out NSS. We know that it's not ideal.
>
> I wrote that code and it's unencrypted for what I think is a good
> reason (others very much disagree). In part, it has to do with 0-RTT.
>
> In 0-RTT, we want to ensur
You are allowed to out NSS. We know that it's not ideal.
I wrote that code and it's unencrypted for what I think is a good
reason (others very much disagree). In part, it has to do with 0-RTT.
In 0-RTT, we want to ensure that the client is able to continue
sending 0-RTT until the entire server
On Wed, Apr 26, 2017 at 03:01:40AM +, Roelof Du Toit wrote:
> During interop testing with an open-source stack I ran into the following:
> CH >
> < SH,{EE,Cert,CV,Fin}
> alert >
>
> The alert was due to a decode error on CV, and the stack in question
> sent the alert in a plaintext
On 04/25/2017 10:01 PM, Roelof Du Toit wrote:
>
> During interop testing with an open-source stack I ran into the following:
>
> CH >
>
> < SH,{EE,Cert,CV,Fin}
>
> alert >
>
>
>
> The alert was due to a decode error on *CV*, and the stack in question
> sent the alert in a *plaintext*
During interop testing with an open-source stack I ran into the following:
CH >
< SH,{EE,Cert,CV,Fin}
alert >
The alert was due to a decode error on CV, and the stack in question sent the
alert in a plaintext record.
The current draft specification has the following text in section 6
10 matches
Mail list logo
