On Tue, Jul 21, 2015 at 5:21 PM, Martin Thomson
wrote:
> On 21 July 2015 at 08:17, Ilari Liusvaara
> wrote:
> >> > *deadlock*.
> >>
> >>
> >> Is this the case where the server is accepting 0-RTT or rejecting it?
> >
> > Apparently, only for accepting case.
> >
> > (If the server rejects, it can
On Tuesday, July 21, 2015 07:04:14 am Eric Rescorla wrote:
> struct {
>select (Role) {
> case client:
>opaque identifier<0..2^16-1>;
>CipherSuite cipher_suite;// NEW
>Extension extensions<0..2^16-1>; /
On 21 July 2015 at 08:17, Ilari Liusvaara wrote:
>> > *deadlock*.
>>
>>
>> Is this the case where the server is accepting 0-RTT or rejecting it?
>
> Apparently, only for accepting case.
>
> (If the server rejects, it can reply immediately, avoiding this
> deadlock).
I don't think that this is a
On Tue, Jul 21, 2015 at 05:09:31PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
> >
> > Also, with regard to ending 0RTT, even without encrypted content
> > types. Either I am misunderstanding something, or:
> >
> > - Client:
On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote:
> > On 21 July 2015 at 06:08, Ilari Liusvaara
> wrote:
> > > Well, if it is about supported ciphers, there could be multiple, and
> > > the prop
On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote:
> On 21 July 2015 at 06:08, Ilari Liusvaara wrote:
> > Well, if it is about supported ciphers, there could be multiple, and
> > the proposal has slot for only one.
>
> The proposal is for what the client selects and uses for its firs
On 21 July 2015 at 06:08, Ilari Liusvaara wrote:
> Well, if it is about supported ciphers, there could be multiple, and
> the proposal has slot for only one.
The proposal is for what the client selects and uses for its first flight.
___
TLS mailing li
On Tue, Jul 21, 2015 at 02:55:33PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
>
> > For 0-RTT/Early handshake data you want cipher that the server
> > supports and accepts. If it is about this, there could be multiple
> >
On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> >
> > > On 21 July 2015 at 04:12, Eric Rescorla wr
On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson
> wrote:
>
> > On 21 July 2015 at 04:12, Eric Rescorla wrote:
> > >
> > > Yes, that's an issue. Not entirely sure what to do about other than
> > > have the server provide its negotia
Yeah, or it could just have the semantics "this is my most preferred
configuration and if you send me anything compatible with it, I will
pick it"
-Ekr
On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson
wrote:
> On 21 July 2015 at 04:12, Eric Rescorla wrote:
> >
> > Yes, that's an issue. Not ent
On 21 July 2015 at 04:12, Eric Rescorla wrote:
>
> Yes, that's an issue. Not entirely sure what to do about other than
> have the server provide its negotiation preferences out of band
> in that case.
I think that we could handle that at the point we define an
out-of-band configuration priming me
On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson
wrote:
> On 21 July 2015 at 04:04, Eric Rescorla wrote:
> > - The client indicates configuration ID and cryptographic configuration,
> > including the cipher suites and cryptographic extensions. This
> > MUST replicate the server's selection fr
On 21 July 2015 at 04:04, Eric Rescorla wrote:
> - The client indicates configuration ID and cryptographic configuration,
> including the cipher suites and cryptographic extensions. This
> MUST replicate the server's selection from a previous handshake
That's not going to work if there was n
The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This h
15 matches
Mail list logo
