On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote:
> Martin Thomson writes:
>
> >The advantage with deploying a new protocol is that you can be strict. If,
> >for example, all of the browsers implement TLS 1.3 and are strict, then
> >Amazon won't be able to deploy a buggy 1.3 implem
> On 22 Sep 2016, at 8:11 AM, Peter Gutmann wrote:
>
> Martin Thomson writes:
>
>> The advantage with deploying a new protocol is that you can be strict. If,
>> for example, all of the browsers implement TLS 1.3 and are strict, then
>> Amazon won't be able to deploy a buggy 1.3 implementatio
Speaking of early assignments for code points, it'd be about time for one
for TLS-LTS as well, otherwise it'll end up with the de facto 0x42 hard-
coded into various implementations. So could I get an IANA early assignment
for that?
Peter.
___
TLS maili
Martin Thomson writes:
>The advantage with deploying a new protocol is that you can be strict. If,
>for example, all of the browsers implement TLS 1.3 and are strict, then
>Amazon won't be able to deploy a buggy 1.3 implementation without noticing
>pretty quickly. You might suggest that that'
Andreas Walz writes:
Peter Gutmann 21.09.16 17.54 Uhr >>>
>> If you're writing a strict validating protocol parser than disconnecting in
>> this case is a valid response, but if it's software that will be used by
>> actual humans then failing a connect based on something like this makes no
>
You describe the observation that leads to Postel's maxim, namely that
if you found the internet in a mess when you got there, then you have
to be tolerant of rubbish.
The advantage with deploying a new protocol is that you can be strict.
If, for example, all of the browsers implement TLS 1.3 and
On Wed, 2016-09-21 at 13:49 -0700, Eric Rescorla wrote:
>
> Is there a real-world use-case where this is relevant?
The number ten might be a little excessive. But there is talk of
multiple sessions being simultaneously for resumption, and multiple PSK
identities in the original meaning of that te
On Wed, Sep 21, 2016 at 1:43 PM, David Woodhouse
wrote:
> On Wed, 2016-09-21 at 13:36 -0700, Eric Rescorla wrote:
> > >
> > I don't see how this is appreciably easier than just having the
> > client offer one and then the server HRR.
>
> If I have ten PSK identities I can offer, it may take nine
On Wed, 2016-09-21 at 13:36 -0700, Eric Rescorla wrote:
> >
> I don't see how this is appreciably easier than just having the
> client offer one and then the server HRR.
If I have ten PSK identities I can offer, it may take nine round-trips
before I send the one you want.
If I list them all in m
On Wed, Sep 21, 2016 at 09:33:11PM +0100, David Woodhouse wrote:
> On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> > On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
>
> > [1] E.g. altering hello_finished to be a list, one entry for each
> > identity, or omitting it ent
On Wed, Sep 21, 2016 at 1:33 PM, David Woodhouse
wrote:
> On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> > On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> > >
> > > On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
> > >
> > > >
> > > > [ashok] : I feel sending
On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> >
> > On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
> >
> > >
> > > [ashok] : I feel sending the selected ID is better, otherwise while
> > > process "server hell
On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
>
> > [ashok] : I feel sending the selected ID is better, otherwise while
> > process "server hello" msg, client has to maintain the PSK ID list in
> > the same order in which it
On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
> [ashok] : PSK Identity extension specified in our extension differs
> from the extension specified in TLS1.3.
Agreed. I suspect it just makes sense to add a sentence to that effect,
to the draft?
> [ashok] : I feel sending the selected ID i
Hi David & Nikos,
My comments are inlined in below mail, please check it.
-Original Message-
From: David Woodhouse [mailto:dw...@infradead.org]
Sent: 19 September 2016 13:04
To: Nikos Mavrogiannopoulos; Raja ashok; jayaraghavendra...@huawei.com
Subject: Re: draft-jay-tls-psk-identity-ext
>>> Peter Gutmann 21.09.16 17.54 Uhr >>>
> If you're writing a strict validating protocol parser than disconnecting in
> this case is a valid response, but if it's software that will be used by
> actual humans then failing a connect based on something like this makes no
> sense.
Wouldn't this
On Wed, Sep 21, 2016 at 03:53:33PM +, Peter Gutmann wrote:
> Andreas Walz writes:
>
> Error: Couldn't connect to Amazon because decoding_error alert>.
>
> What would you put for the explanation for this case? And if you say "decode
> error" the user's response will be to switch
Andreas Walz writes:
>Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
>addresses this in the Presentation Language section:
>
> "Peers which receive a message which cannot be parsed according to the
> syntax (e.g., have a length extending beyond the message boundary o
On Wednesday, 21 September 2016 11:45:15 CEST Andreas Walz wrote:
> Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the
> fact that the TLS 1.3 draft now explicitly addresses this in the
> Presentation Language section:
>
> "Peers which receive a message which cannot
On Tuesday, 20 September 2016 18:24:42 CEST David Benjamin wrote:
> On Tue, Sep 20, 2016 at 2:14 PM Hubert Kario wrote:
> > I'll be running test looking for intolerances like this over the Alexa top
> > 1
> > million next month.
>
> (I've already done this, by the way. It's where the numbers in t
Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the
fact that
the TLS 1.3 draft now explicitly addresses this in the Presentation Language
section:
"Peers which receive a message which cannot be parsed according to the
syntax
(e.g., have a length extending b
On Mon, 2016-09-19 at 14:13 -0700, Eric Rescorla wrote:
>
> > It is purely a matter of software architecture — the initial
> > incoming
> > UDP packets reach a dispatcher that needs to hand the connection
> > off to
> > the appropriate worker process for that client and *really*
> > wants
> >
On 21 September 2016 at 17:21, Andreas Walz
wrote:
> Do you see any argument why ignoring such trailing data would be acceptable
> (or even desirable)?
No.
Well, we exploited that to add extensions to the protocol once, so I
won't categorically rule it out, but in the case of
supported_groups/su
Dear all,
sorry for bringing up this thread again. We were doing some further studies
with TLS implementations (all TLS 1.2) for embedded systems and found more
cases where, within substructures of handshake messages, trailing data without
any associated field in the specification is *not* reje
24 matches
Mail list logo
