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 ar
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
discussion
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 10:29
On Mon, Sep 19, 2016 at 1:35 PM, David Woodhouse
wrote:
> On Mon, 2016-09-19 at 09:53 -0700, Eric Rescorla wrote:
>
> > > > I would address this either by:
> > > >
> > > > 1. Registering a new extension which is used to indicate the right
> worker
> > > > process, but using existing TLS 1.2 PSK.
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 say
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 to offer two PSK identi
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 to offer two PSK identities — one for the real identity, and one
> > for the session resu
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 which was being offered
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 an
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 to fix it, this is just
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 observation
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 clear.
>
> Note that if w
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 clear.
Note that if we really want to be more compact, we might also observe
that there is
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
> > TLS
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.
>
>
15 matches
Mail list logo