Hi Andreas,
I am not sure that people ignore the redundant length fields on purpose.
I think that the strange syntax that TLS uses invites these types of
mistakes and I had run into those myself as well.
Ciao
Hannes
On 10/05/2016 02:03 PM, Andreas Walz wrote:
> Hi Olivier,
>
> your findings
Hi Olivier,
your findings are interesting as they pretty much match with what we
have found when studying TLS implementations for embedded systems. In
many implementations there is a tendency to ignore redundant length
fields (or at least to not enforce consistency). There has been some
Hi list,
I have been working in the labs at ANSSI (the French Network and
Information System Agency) for several years and I just defended my PhD
thesis on the TLS ecosystem (documents are available at
http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/).
>> On Mon, 2016-09-19 at
On Mon, 2016-09-19 at 09:53 -0700, Eric Rescorla wrote:
> > Perhaps I should turn your question round, and ask: if PSK is a first-
> > class citizen as a key exchange and authentication method, why *should*
> > we be forbidden from resuming sessions which started that way...
>
> Well, I'm not
On Mon, Sep 19, 2016 at 8:37 AM, David Woodhouse
wrote:
> On Mon, 2016-09-19 at 07:55 -0700, Eric Rescorla wrote:
> > > What if my client authenticates with an actual pre-shared key, and I
> > > also want to resume a session? As it stands, that means I really do
> > > need
On Mon, Sep 19, 2016 at 7:07 AM, David Woodhouse
wrote:
> On Mon, 2016-09-19 at 05:46 -0700, Eric Rescorla wrote:
> >
> > > And then the client only needs to supply one copy of it for the
> > > identity which the server actually selected, not one for *each*
> > > identity
On Mon, 2016-09-19 at 05:46 -0700, Eric Rescorla wrote:
>
> > And then the client only needs to supply one copy of it for the
> > identity which the server actually selected, not one for *each*
> > identity which was being offered by the client.
>
> We're most likely going to allow only on PSK
On Mon, Sep 19, 2016 at 5:26 AM, David Woodhouse
wrote:
> On Mon, 2016-09-19 at 04:41 -0700, Eric Rescorla wrote:
> > > Do we care that the '0x00 0x12' bytes on my third line above are
> > > entirely redundant on the wire? Or have I interpreted it wrong?
> >
> > Not enough
On Mon, 2016-09-19 at 04:41 -0700, Eric Rescorla wrote:
> > Do we care that the '0x00 0x12' bytes on my third line above are
> > entirely redundant on the wire? Or have I interpreted it wrong?
>
> Not enough to fix it, this is just the way TLS rolls.
An interesting contrast to Nikos's
On Mon, Sep 19, 2016 at 2:49 AM, David Woodhouse
wrote:
> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> > > More compact and makes the option where server sends some bad option
> > > more
On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos
> wrote:
> >
> > Hello,
> > I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
> > draft [0], and I noticed quite some deviations (IMO) from typical
> >
On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
> I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
> draft [0], and I noticed quite some deviations (IMO) from typical TLS
> protocol behavior. No rationale is given about them so I ask on list.
>
Hello,
I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
draft [0], and I noticed quite some deviations (IMO) from typical TLS
protocol behavior. No rationale is given about them so I ask on list.
To summarize, the client sends a list of identitities and the server
replies with
13 matches
Mail list logo