-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Hilarie Orman wrote:
> An ARM is far too much hardware to throw at "read sensor/munge
> data/send data".
No, they are not. The Cortex M0+ is aimed at these kinds of very simple
systems that runs for many years on a single battery.
Look at t
> On Aug 31, 2016, at 10:01 PM, Eric Mill wrote:
>
>
> FWIW, I've definitely seen real-world confusion about SSLv3 being a more
> recent protocol than TLS 1.X, by organizations that should know better. If
> there's interest and consensus, this could be a good opportunity to reset the
> situat
On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote:
> On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario wrote:
> > Current draft has the following text in it:
> > If any of these checks fail, the server MUST NOT respond
> > with the extension and must discard all the remaining fir
On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario wrote:
> On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote:
> > On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario
> wrote:
> > > Current draft has the following text in it:
> > > If any of these checks fail, the server MUST NOT respond
>
On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario wrote:
> >
> > I'm afraid that requiring the server to keep the connection open for
> > essentially arbitrary amount of time while it consumes garbage data is not
> > unlike the Apache slo
On Thursday, 1 September 2016 05:48:02 CEST Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario wrote:
> > On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote:
> > > On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario
> >
> > wrote:
> > > > Current draft has the following t
On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote:
> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario wrote:
> > >
> > > I'm afraid that requiring the server to keep the connection open for
> > > essentially arbitrary amount of t
On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara
> wrote:
>
>> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote:
>> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario wrote:
>> > >
>> > > I'm afraid that requiring the server to keep
On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
> On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla wrote:
>
> > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara
> >>
> >> Should there be recommendation for clients to cut transfer and send
> >> Finished if the client receives Encrypte
On Thursday, September 01, 2016 02:05:25 am Judson Wilson wrote:
> > I like TLS/2 aesthetically, and represents a similar level of
> > progress/reset that HTTP saw when it jumped from 1.1 to /2.
>
> What is the slash in the name all about? Is it simply playing off the HTTP
> start line specificati
On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla wrote:
> >
> > > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > >>
> > >> Should there be
On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara
> wrote:
>
>> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
>> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla wrote:
>> >
>> > > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusva
> On 1 Sep 2016, at 6:31 PM, Dave Garrett wrote:
>
> On Thursday, September 01, 2016 02:05:25 am Judson Wilson wrote:
>>> I like TLS/2 aesthetically, and represents a similar level of
>>> progress/reset that HTTP saw when it jumped from 1.1 to /2.
>>
>> What is the slash in the name all about?
I didn't notice in the -15 draft anything explicitly prohibiting sending a
TLSv1.3 Client Hello inside established TLSv1.x connection (where x < 3).
Is this something that the protocol should allow? If yes, renegotiation_info
extension status would probably need to be updated. If not, then I thi
On Thu, Sep 1, 2016 at 8:46 AM, David Benjamin
wrote:
> On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla wrote:
>
>> On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara > > wrote:
>>
>>> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
>>> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla
joac...@secworks.se writes:
> Aloha!
Aloha auinala.
> Hilarie Orman wrote:
> > An ARM is far too much hardware to throw at "read sensor/munge
> > data/send data".
> No, they are not. The Cortex M0+ is aimed at these kinds of very simple
> systems that runs for many years on a single batte
This should be prohibited. A PR for this would be welcome.
-Ekr
On Thu, Sep 1, 2016 at 9:07 AM, Hubert Kario wrote:
> I didn't notice in the -15 draft anything explicitly prohibiting sending a
> TLSv1.3 Client Hello inside established TLSv1.x connection (where x < 3).
>
> Is this something tha
On Thu, Sep 01, 2016 at 09:01:27AM -0700, Eric Rescorla wrote:
> >
>
> ALPN is also in EE. My general principle was that only things that were
> required
> to decrypt the handshake messages should be in SH. Arguably, btw, this means
> that Server.signature_algorithms should be in EE, but I chicken
done:
https://github.com/tlswg/tls13-spec/pull/614
On Thursday, 1 September 2016 09:19:46 CEST Eric Rescorla wrote:
> This should be prohibited. A PR for this would be welcome.
>
> -Ekr
>
> On Thu, Sep 1, 2016 at 9:07 AM, Hubert Kario wrote:
> > I didn't notice in the -15 draft anything explici
The SHA-3 standard is already published and accepted[1], shouldn't TLSv1.3
include signatures with those hashes then?
I think at least the following signature algorithms should be added:
ecdsa_secp256r1_sha3_256
ecdsa_secp384r1_sha3_384
ecdsa_secp521r1_sha3_512
rsa_pss_sha3_256
rsa_pss_sha3_384
On 09/01/2016 12:38 PM, Hubert Kario wrote:
> The SHA-3 standard is already published and accepted[1], shouldn't TLSv1.3
> include signatures with those hashes then?
Why does it need to be part of the core spec instead of a separate document?
> 1 - https://www.federalregister.gov/articles/2015/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Hilarie Orman wrote:
> For devices you refer to, how many AES blocks can they encrypt on a
> AA battery, assuming that the usage is to encrypt one block every 10
> minutes?
That is actually a very interesting, but hard question to answer. Wi
On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote:
> On 09/01/2016 12:38 PM, Hubert Kario wrote:
> > The SHA-3 standard is already published and accepted[1], shouldn't TLSv1.3
> > include signatures with those hashes then?
>
> Why does it need to be part of the core spec instead of
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario
> Sent: Thursday, September 01, 2016 2:17 PM
> To: Benjamin Kaduk
> Cc:
> Subject: Re: [TLS] SHA-3 in SignatureScheme
>
> On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote:
> > On 09/0
On Mon, Aug 29, 2016 at 5:00 AM, Hubert Kario wrote:
>
> we have enough problems weeding out implementation mistakes in TLS, we
> don't
> need yet another protocol and two dozen implementations that come with it
>
Strongly agreed.
Focusing energy on getting "something" working for low-power dev
Hi,
The technology is SSL, and is sometimes also refered to as
SSL/TLS.
please no. the technology is TLS.
+
i would like to continue to be able to say unambiguously that all
known versions of SSL are badly broken and should be avoided. Let's
not muddy those waters further.
+
Let's not use
+1
On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes wrote:
> I am in total agreement with Nick here. "TLS 1.3" accurately describes what
> we're doing here, and it's consistent with our past naming scheme.
>
> There is no upside to changing away from 1.3, and as Nick notes, lots of
> potential do
I have created a PR for this at:
https://github.com/tlswg/tls13-spec/pull/611
As it seems there was rough consensus for this change, I will merge this
weekend
absent some violent objections or direction to the contrary from the chairs.
-Ekr
On Mon, Aug 29, 2016 at 3:06 PM, Russ Housley wrote:
On Aug 25, 2016 04:08, "Tony Arcieri" wrote:
> Should there be a 3DES "diediedie"?
Strongly +1.
Makers of tiny devices with legacy chips will simply keep on using whatever
they want anyway. This is not a good reason to drag risk for everyone with
us forevermore.
Richard
___
On Thu, Sep 01, 2016 at 12:55:29PM -0700, Eric Rescorla wrote:
> I have created a PR for this at:
> https://github.com/tlswg/tls13-spec/pull/611
>
> As it seems there was rough consensus for this change, I will merge this
> weekend
> absent some violent objections or direction to the contrary from
I think we have to oppose a change to KeyUpdate that adds P4 (bounded
write obligations) but not P3 (ability to learn that a KeyUpdate was
read by other side). These are orthogonal and easily achievable with a
pretty small tweak. Here are four options that would work for us:
1. No change to messag
On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 12:55:29PM -0700, Eric Rescorla wrote:
> > I have created a PR for this at:
> > https://github.com/tlswg/tls13-spec/pull/611
> >
> > As it seems there was rough consensus for this change, I will merge this
> > weeken
On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara
> wrote:
>
> > I tried to implement this, and discovered an issue:
> >
> > The client handshake traffic secret is needed for deriving client
> > Finished, and client application traffi
On Thu, Sep 1, 2016 at 2:29 PM, Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > I tried to implement this, and discovered an issue:
> > >
> > > The client
On Thu, Sep 1, 2016 at 5:29 PM Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > I tried to implement this, and discovered an issue:
> > >
> > > The client
Folks,
I have just posted a WIP PR for what I'm calling "Finished Stuffing"
https://github.com/tlswg/tls13-spec/pull/615
I would welcome comments on this direction and whether I am missing
anything important.
OVERVIEW
This PR follows on a bunch of discussions we've had about the redundancy
o
I should also mention that this makes the implementation a fair bit simpler
because:
1. You can make all the decisions on the server side immediately upon
receiving the ClientHello
without waiting for Finished.
2. You don't need to derive early handshake traffic keys.
>From an implementor's persp
On Thursday, September 01, 2016 02:30:54 pm Scott Fluhrer (sfluhrer) wrote:
> > On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote:
> > > On 09/01/2016 12:38 PM, Hubert Kario wrote:
> > > > The SHA-3 standard is already published and accepted[1], shouldn't
> > > > TLSv1.3 include sign
On Thursday, September 01, 2016 03:17:50 pm Julien ÉLIE wrote:
> There's still something I find confusing: on the one hand, SSL is badly
> broken and "diediedied", it is a proprietary protocol name, and the
> consensus in the TLS WG seems to be "long live TLS" but on the other
> hand major SSL/
39 matches
Mail list logo
