Re: [TLS] Terminology clarification around SSL & TLS

2016-09-01 Thread Dave Garrett 
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/TLS implementations keep the SSL name living.

Arguably, renaming SSL to TLS and restarting the version numbering was a bad 
decision. SSL/TLS is a 21 year old protocol. It's got more than a few bad 
decisions in it, at least in hindsight.

I too wish that major organizations would ditch the SSL naming for TLS, however 
until very recently many still supported SSL in some form (which is it's own 
problem). It is unfortunately not easy to convince everyone to update things.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

2016-09-01 Thread Dave Garrett 
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 signatures with those hashes then?
> > >
> > > Why does it need to be part of the core spec instead of a separate
> > document?
> > 
> > because: we also are adding RSA-PSS to TLSv1.2 in this document, I don't see
> > why it needs to be delayed. Finally, TLSv1.2 added SHA-2 just like that, it 
> > was
> > not tacked on later.
> 
> IIRC, SHA-2 was a special case; SHA-1 was demonstrated to be 
> cryptographically weaker than expected and so we needed to have a secure 
> alternative ASAP.
> 
> The SHA-3 is not like that; there's no evidence that suggests that SHA-2 is 
> weak; the only incentive to implementing SHA-3 is "we'll, it is a standard, 
> and so we might as well support it".

The reason I see is that we currently specify exactly one valid hash algorithm 
(in a variety of sizes). The precedent argument is good enough for me. I think 
adding it in this document is definitely worth considering. I don't want to 
wait until SHA-2 is considered weak to provide an alternative, if we can avoid 
it.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing

2016-09-01 Thread Eric Rescorla 
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 perspective, this outweighs the messing around with
the ClientHello buffer.
-Ekr


On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:

> 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
> of Finished and resumption_ctx. This PR makes the following changes:
>
> - Replace the 0-RTT Finished with an extension you send in the
>   ClientHello *whenever* you do PSK.
> - Get rid of resumption context (because it is now replaced by
>   the ClientHello.hello_finished.
>
>
> RATIONALE
> The reasoning for this change is:
>
> - With ordinary PSK you don't get any assurance that the other side
>   knows the PSK.
>
> - With 0-RTT you get some (subject to the usual anti-replay
>   guarantees) via the Finished message.
>
> - If we were to include the 0-RTT Finished message in the handshake
>   transcript, then we wouldn't need the resumption context because
>   the transcript would transitively include the PSK via the Finished.
>
> So the natural thing to do would be to always send 0-RTT Finished
> but unfortunately:
>
> 1. You can't just send the 0-RTT Finished whenever you do PSK because
>that causes potential compat problems with mixed 1.3/1.2 networks
>(the same ones we have with 0-RTT, but at least that's opt-in).
>
> 2. You also can't send the 0-RTT Finished with PSK because you can
>currently offer multiple PSK identities.
>
> The on-list discussion has suggested we could relax condition #2 and
> only have one identity. And we can fix condition #1 by stuffing the
> Finished in an extension (with some hacks to make this easier). This
> PR enacts that.
>
>
> FAQS
> - What gets included in the handshake transcript?
>   The whole ClientHello including the computed hello_finished extension.
>
> - Isn't this a hassle to implement?
>   It turns out not to be. The basic reason is that at the point where
>   the client sends the ClientHello and the server processes, it doesn't
>   yet know which Hash will be chosen for HKDF and so NSS (and I believe
>   other stacks) buffers the ClientHello in plaintext, so hashing only
>   part of it is easy. I've done it in NSS and this part is quite easy.
>
>
> POTENTIAL VARIATIONS/TODOs
> There are a number of possible variations we might want to look at:
>
> 1. Moving obfuscated_ticket_age to its own extension (out of
>early_data_indication). This provides additional anti-replay
>for the CH at the 0.5RTT sending point. I believe we should
>make this change.
>
> 2. Tweaking the data to be hashed to just hash the ClientHello
>prefix without the 0-filled verify_data. This is not significantly
>harder or easier to implement and basically depends on whether
>you prefer the invariant of "always hash complete messages" or
>"always hash valid pieces of transcript". See above for notes
>on buffering.
>
> 3. Allow multiple PSKs. Technically you could make this design
>work with >1 PSK but stuffing multiple verify_data values in
>the ClientHello. E.g,,
>
>   opaque FinishedValue<0..255>;
>
>   struct {
>  FinishedValue finisheds<0..2^16-1>;
>   } HelloFinished;
>
>Based on the list discussion, it seems like nobody wants >1 PSK,
>so I think one is simpler; I just wanted to note that these
>changes weren't totally coupled.
>
> 4. External context values. Several people have pointed out that it
>might be convenient to have an external context value hashed
>into the transcript. One way to do this would be to include
>it under the Finished. That's not difficult if people want to,
>with the default being empty.
>
> 5. Hugo brought up on the list that we need to make very clear that
>the "hello_finished" is being used to bind the handshakes and
>that it depends on collision resistance. I have not forgotten this
>and text on that point would be appreciated.
>
> Comments welcome.
> -Ekr
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Finished stuffing

2016-09-01 Thread Eric Rescorla 
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
of Finished and resumption_ctx. This PR makes the following changes:

- Replace the 0-RTT Finished with an extension you send in the
  ClientHello *whenever* you do PSK.
- Get rid of resumption context (because it is now replaced by
  the ClientHello.hello_finished.


RATIONALE
The reasoning for this change is:

- With ordinary PSK you don't get any assurance that the other side
  knows the PSK.

- With 0-RTT you get some (subject to the usual anti-replay
  guarantees) via the Finished message.

- If we were to include the 0-RTT Finished message in the handshake
  transcript, then we wouldn't need the resumption context because
  the transcript would transitively include the PSK via the Finished.

So the natural thing to do would be to always send 0-RTT Finished
but unfortunately:

1. You can't just send the 0-RTT Finished whenever you do PSK because
   that causes potential compat problems with mixed 1.3/1.2 networks
   (the same ones we have with 0-RTT, but at least that's opt-in).

2. You also can't send the 0-RTT Finished with PSK because you can
   currently offer multiple PSK identities.

The on-list discussion has suggested we could relax condition #2 and
only have one identity. And we can fix condition #1 by stuffing the
Finished in an extension (with some hacks to make this easier). This
PR enacts that.


FAQS
- What gets included in the handshake transcript?
  The whole ClientHello including the computed hello_finished extension.

- Isn't this a hassle to implement?
  It turns out not to be. The basic reason is that at the point where
  the client sends the ClientHello and the server processes, it doesn't
  yet know which Hash will be chosen for HKDF and so NSS (and I believe
  other stacks) buffers the ClientHello in plaintext, so hashing only
  part of it is easy. I've done it in NSS and this part is quite easy.


POTENTIAL VARIATIONS/TODOs
There are a number of possible variations we might want to look at:

1. Moving obfuscated_ticket_age to its own extension (out of
   early_data_indication). This provides additional anti-replay
   for the CH at the 0.5RTT sending point. I believe we should
   make this change.

2. Tweaking the data to be hashed to just hash the ClientHello
   prefix without the 0-filled verify_data. This is not significantly
   harder or easier to implement and basically depends on whether
   you prefer the invariant of "always hash complete messages" or
   "always hash valid pieces of transcript". See above for notes
   on buffering.

3. Allow multiple PSKs. Technically you could make this design
   work with >1 PSK but stuffing multiple verify_data values in
   the ClientHello. E.g,,

  opaque FinishedValue<0..255>;

  struct {
 FinishedValue finisheds<0..2^16-1>;
  } HelloFinished;

   Based on the list discussion, it seems like nobody wants >1 PSK,
   so I think one is simpler; I just wanted to note that these
   changes weren't totally coupled.

4. External context values. Several people have pointed out that it
   might be convenient to have an external context value hashed
   into the transcript. One way to do this would be to include
   it under the Finished. That's not difficult if people want to,
   with the default being empty.

5. Hugo brought up on the list that we need to make very clear that
   the "hello_finished" is being used to bind the handshakes and
   that it depends on collision resistance. I have not forgotten this
   and text on that point would be appreciated.

Comments welcome.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-01 Thread David Benjamin 
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 handshake traffic secret is needed for deriving client
> > > Finished, and client application traffic secret is only needed after
> > > that point. However, the derivation of client application traffic
> > > secret uses handshake hash post Server Finished.
> > >
> > > So you either need to buffer the handshake hash value, or have two
> > > overlapping client traffic secrets.
> > >
> > > Changing the client application traffic secret context to extend
> > > up to Client Finished would solve the issue.
> > >
> >
> > Hmm having the keys in one direction cover the client's certificate
> and
> > certverify
> > and the keys in the other direction not seems pretty sketchy.
> >
> > As I understand this, it's just an aesthetic issue, right?
>
> I don't think this is just aesthetic issue:
>
> - If you derive the traffic secret at the moment the right hash is
>   available, you need to stash the traffic secret for later (one
>   can't overwrite the existing one, since you will need that for
>   ClientFinished).
> - If you derive the traffic secret just before use, you need to
>   have saved the hash value used for derivation, since the
>   ClientFinished (and possibly Certificate(Verify)) has altered it.
>

I do rather like never splitting the DeriveTrafficKey() and UseTrafficKey()
operations. We have to hold on to an extra copy of traffic_secret_0 today
in the single-ladder version for very similar reasons. That only one set of
keys covesr the client certificate is certainly kind of weird. Although I
assume we can just analyze as if it didn't since we were clearly okay with
not including it before.

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-01 Thread Eric Rescorla 
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 handshake traffic secret is needed for deriving client
> > > Finished, and client application traffic secret is only needed after
> > > that point. However, the derivation of client application traffic
> > > secret uses handshake hash post Server Finished.
> > >
> > > So you either need to buffer the handshake hash value, or have two
> > > overlapping client traffic secrets.
> > >
> > > Changing the client application traffic secret context to extend
> > > up to Client Finished would solve the issue.
> > >
> >
> > Hmm having the keys in one direction cover the client's certificate
> and
> > certverify
> > and the keys in the other direction not seems pretty sketchy.
> >
> > As I understand this, it's just an aesthetic issue, right?
>
> I don't think this is just aesthetic issue:
>

Perhaps I should have said "minor implementation inconvenience"


- If you derive the traffic secret at the moment the right hash is
>   available, you need to stash the traffic secret for later (one
>   can't overwrite the existing one, since you will need that for
>   ClientFinished).
>

Yes, but this was already true for handshake_secret, no?

-Ekr

- If you derive the traffic secret just before use, you need to
>   have saved the hash value used for derivation, since the
>   ClientFinished (and possibly Certificate(Verify)) has altered it.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-01 Thread Eric Rescorla 
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
> > weekend
> > absent some violent objections or direction to the contrary from the
> chairs.
> >
> > -Ekr
>
> I tried to implement this, and discovered an issue:
>
> The client handshake traffic secret is needed for deriving client
> Finished, and client application traffic secret is only needed after
> that point. However, the derivation of client application traffic
> secret uses handshake hash post Server Finished.
>
> So you either need to buffer the handshake hash value, or have two
> overlapping client traffic secrets.
>
> Changing the client application traffic secret context to extend
> up to Client Finished would solve the issue.
>

Hmm having the keys in one direction cover the client's certificate and
certverify
and the keys in the other direction not seems pretty sketchy.

As I understand this, it's just an aesthetic issue, right?

-Ekr



>
> Additionally:
> - That would make the implementation look nicely symmetric
> - Would also prevent having "not yet" keys. One can derive keys
>   from present state and install them immediately.
>
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-01 Thread Eric Rescorla 
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:

> Eric:
>
> > Yes, I agree separate ladders would fix this. I don't necessarily object
> to this
> > change, but I'm not sure it's that big a deal either, because you really
> only get
> > into this case when there's a big asymmetry in sending rate, so much that
> > one side wants to send multiple updates before the other side has sent
> > any data at all.
>
> I can think of many situations where one side sends a lot more data than
> the other.
>
> > Note: it's also possible to avoid the rollback problem with the existing
> > single-ladder system: when you send a key update you compute:
> >
> > traffic_secret_N+1
> > read_key_N+1
> > write_key_N+1
> >
> > You then discard traffic_secret N, write_key_N, but key read_key_N, so
> if you
> > are M updates ahead of the other side, you have M read keys outstanding,
> > but these cannot be used to produce the write keys. However, this
> probably
> > isn't simpler than just running two ladders if we think this is
> important.
>
> That seems to work.  However, I think that splitting the ladders seems to
> marry well with the many situations where one side sends a lot more than
> the other.  So, I suggest that we split the ladders.
>
> Russ
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

2016-09-01 Thread Joseph Lorenzo Hall 
+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 downside.
>
> --Richard
>
> On Wednesday, August 31, 2016, Nick Sullivan 
> wrote:
>>
>> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a
>> few immediate issues with the proposal:
>> - it causes confusion with SSL 2.0
>> - it implies wire incompatibility with TLS 1.2
>> - it suggests there will be a forthcoming TLS 2.1 with only minor changes
>>
>> If we're dead set on bumping the major version for a mostly backwards
>> compatible protocol change, we should just drop the minor version and go
>> with TLS/2.
>>
>> Nick
>>
>> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
>> wrote:
>>>
>>> We could call it TLS 3.4 which would match the internal ID. :-)
>>>
>>> BTW, I think using something other than 1.3 is a good idea.
>>>
>>> Cheers - Bill
>>>
>>> -
>>> Bill Frantz| When it comes to the world | Periwinkle
>>> (408)356-8506  | around us, is there any choice | 16345 Englewood Ave
>>> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Terminology clarification around SSL & TLS

2016-09-01 Thread Julien ÉLIE 

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 a proprietary protocol name for a standard protocol.
Conveniently, all SSL is broken now, long live TLS!


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/TLS implementations keep the SSL name living.


When people look for TLS implementations, they will find OpenSSL, 
BoringSSL, LibreSSL, MatrixSSL, wolfSSL, etc.

Besides, a developer will often use "-lssl" to link against TLS libraries.

So, if the consensus is to prevent people who speak about or work on TLS 
from constantly viewing the SSL name, will forthcoming software releases 
change their name?

Otherwise, confusion keeps being sustained...

--
Julien ÉLIE

« En voyant le lit vide, il le devint. » (Ponson du Terrail)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-01 Thread Kyle Rose 
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 devices is
putting the cart before the horse. Security has to be a primary objective
here, in the standards world in general and in CFRG in particular. We can
surely consider tradeoffs---more frequent key rotations, security
guarantees reduced in a well-defined way, shorter lifetimes for
credentials, etc.---but these should be explicitly chosen, not determined
after the fact based on what happened to be in our toolbox at the time.
Keeping 3DES around in a general-purpose protocol headed for
standardization in spite of the known problems with small block sizes is
almost certain to create more work in the coming years for everyone simply
to benefit implementors of systems for which security is clearly not the
primary concern.

>From following the discussion, low power crypto seems like a research area
at this point, not an implementation effort. (Of course, the flaws in
whatever ill-advised schemes get implemented will generate their own
research efforts and inevitable transitive trust problems with supposedly
more-secure systems. Alas, we haven't yet figured out a way to keep people
from generating sufficient rope to hang themselves with.)

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

2016-09-01 Thread Hubert Kario 
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 a separate document?

because: we also are adding RSA-PSS to TLSv1.2 in this document,
I don't see why it needs to be delayed. Finally, TLSv1.2 added SHA-2 just like 
that, it was not tacked on later.

Note that I do not suggest that implementation of SHA-3 signature algorithms 
should be recommended, let alone mandatory for TLSv1.3, just that the standard 
include the codepoints.

> >  1 - https://www.federalregister.gov/articles/2015/08/05/2015-19181/
> > 
> > announcing-approval-of-federal-information-processing-standard-fips-202-sh
> > a-3- standard
> 
> I think we generally end up with a RFC specifying how to use them in
> IETF protocols and then cite the RFC instead of the NIST publication
> directly.

I would see that as necessary for RSASSA-PKCS1_v1.5, as it needs the values 
for hash info, but neither ECDSA nor RSASSA-PSS require them. I think that RFC 
3447 is enough to implement RSASSA-PSS with SHA-3.

Also, is see RFC 5246 referencing the NIST publication directly, not the RFC 
4634...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

2016-09-01 Thread Benjamin Kaduk 
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/08/05/2015-19181/
> announcing-approval-of-federal-information-processing-standard-fips-202-sha-3-
> standard
>

I think we generally end up with a RFC specifying how to use them in
IETF protocols and then cite the RFC instead of the NIST publication
directly.

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLSv1.2 connection renegotiation to TLSv1.3

2016-09-01 Thread Hubert Kario 
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 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 think
> > the
> > document should be a bit more explicit about it.
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-01 Thread Hilarie Orman 
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 battery.

>  Look at the STM32L0 series from ST for example. These devices can run on
>  energy harvesting and very tiny physically and very, very cheap (ten-ish
>  cents in high volume):

>  
> http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html?querycriteria=productId=SS1817

>  The STM32L021 has an AES-128 core. Not very fast (200+ cycles), but
>  several times faster than SW. You can also run the AES core wile the CPU
>  core is in power save mode.

>  Another example is the Zero Gecko from Silicon Labs. Same price range, a
>  huge number of power modes. And an AES core that is really fast. 50+
>  cycles for AES-128, which basically means 4 cycles/round (which implies
>  4 S-boxes)

>  
> https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx

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?

Hilarie

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread Eric Rescorla 
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  wrote:
>>> >
>>> > > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <
>>> ilariliusva...@welho.com>
>>> > >>
>>> > >> Should there be recommendation for clients to cut transfer and send
>>> > >> Finished if the client receives EncryptedExtensions without
>>> > >> early_data extension?
>>> > >>
>>> > >
>>> > > I thought that was implicit, but i'd take a PR that did that.
>>> > >
>>> >
>>> > (s/EncryptedExtensions/ServerHello/, but whatever.)
>>>
>>> According to the table it is EncryptedExtensions (but there have been
>>> errors in it before)...
>>>
>>
>> It goes in EE, because it should be encrypted.
>>
>
> Hrm. Most of the text currently says ServerHello, except for the table
> which says EncryptedExtensions.
>
> ServerHello:
> https://tlswg.github.io/tls13-spec/#rfc.section.4.2.6
> https://tlswg.github.io/tls13-spec/#rfc.section.2.3
>
> EncryptedExtensions:
> https://tlswg.github.io/tls13-spec/#rfc.section.10
>
> I'm a little wary of putting something that tells you the handshake
> "shape" in EncryptedExtensions. Accepting early_data comes with a host of
> constraints  the client must enforce like ALPN not being allowed to change,
> etc. But I think all the current constraints are with EncryptedExtensions,
> so maybe it's fine?
>

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 chickened out.

-Ekr




> > At this point the client must do much more than cut transfer anyway. It
>>> > probably should be phrased as starting over and retrying or so.
>>> Everything
>>> > sent has been rejected and all you thought you knew about the
>>> connection
>>> > may have changed, like ALPN. At sufficiently high layers, you should
>>> > probably just pretend you got a fresh connection and are repeating the
>>> > request (or whatever) from scratch.
>>>
>>> So server is supposed to continue on 0-RTT fail, but not client?
>>
>>
>> There are plenty of scenarios where the client can continue. For instance,
>> if the server has forgotten the ticket but is otherwise unchanged.
>>
>
> Right, I mean it's a logical starting over. I imagine most cases one can
> keep affinity with the old transport socket just fine, but data does likely
> need to be reset. (Although in some cases you can't.)
>
> David
>
>
>> -Ekr
>>
>>
>>>
>>> -Ilari
>>>
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

2016-09-01 Thread Yoav Nir 

> 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? Is it simply playing off the HTTP
>> start line specification? Does it have any relevance to TLS?
> 
> Did this slash form start with HTTP/2, or was there some other progenitor? 
> Why did they go with that, anyway? I just find it to be a weird choice. If we 
> actually have a consensus that it'd be better to go with TLS/2 than TLS 2.0, 
> officially, I'd only be ok with it if someone can actually explain why. :|

HTTP/1.0 and HTTP/1.1 had these strings as part of the on-the-wire format:

   GET / HTTP/1.1

The slash rather than a space makes it easier to parse with strtok(), I guess.

HTTP/2 is more binary so there is no “HTTP/2” string inside, but the name kept 
the format.

Yoav


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread David Benjamin 
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 Liusvaara <
>> ilariliusva...@welho.com>
>> > >>
>> > >> Should there be recommendation for clients to cut transfer and send
>> > >> Finished if the client receives EncryptedExtensions without
>> > >> early_data extension?
>> > >>
>> > >
>> > > I thought that was implicit, but i'd take a PR that did that.
>> > >
>> >
>> > (s/EncryptedExtensions/ServerHello/, but whatever.)
>>
>> According to the table it is EncryptedExtensions (but there have been
>> errors in it before)...
>>
>
> It goes in EE, because it should be encrypted.
>

Hrm. Most of the text currently says ServerHello, except for the table
which says EncryptedExtensions.

ServerHello:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2.6
https://tlswg.github.io/tls13-spec/#rfc.section.2.3

EncryptedExtensions:
https://tlswg.github.io/tls13-spec/#rfc.section.10

I'm a little wary of putting something that tells you the handshake "shape"
in EncryptedExtensions. Accepting early_data comes with a host of
constraints  the client must enforce like ALPN not being allowed to change,
etc. But I think all the current constraints are with EncryptedExtensions,
so maybe it's fine?

(The failure mode for getting this wrong is a risk of serious
implementation complexity and bugs, similar to why client
EncryptedExtensions was a problem. E.g. if ALPN were in SH but early_data
in EE , there would be a window of time where we have a new ALPN but aren't
sure if it's a 0-RTT reject or fatal error. It makes things a mess.)


> > At this point the client must do much more than cut transfer anyway. It
>> > probably should be phrased as starting over and retrying or so.
>> Everything
>> > sent has been rejected and all you thought you knew about the connection
>> > may have changed, like ALPN. At sufficiently high layers, you should
>> > probably just pretend you got a fresh connection and are repeating the
>> > request (or whatever) from scratch.
>>
>> So server is supposed to continue on 0-RTT fail, but not client?
>
>
> There are plenty of scenarios where the client can continue. For instance,
> if the server has forgotten the ticket but is otherwise unchanged.
>

Right, I mean it's a logical starting over. I imagine most cases one can
keep affinity with the old transport socket just fine, but data does likely
need to be reset. (Although in some cases you can't.)

David


> -Ekr
>
>
>>
>> -Ilari
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread Eric Rescorla 
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 recommendation for clients to cut transfer and send
> > >> Finished if the client receives EncryptedExtensions without
> > >> early_data extension?
> > >>
> > >
> > > I thought that was implicit, but i'd take a PR that did that.
> > >
> >
> > (s/EncryptedExtensions/ServerHello/, but whatever.)
>
> According to the table it is EncryptedExtensions (but there have been
> errors in it before)...
>

It goes in EE, because it should be encrypted.


> At this point the client must do much more than cut transfer anyway. It
> > probably should be phrased as starting over and retrying or so.
> Everything
> > sent has been rejected and all you thought you knew about the connection
> > may have changed, like ALPN. At sufficiently high layers, you should
> > probably just pretend you got a fresh connection and are repeating the
> > request (or whatever) from scratch.
>
> So server is supposed to continue on 0-RTT fail, but not client?


There are plenty of scenarios where the client can continue. For instance,
if the server has forgotten the ticket but is otherwise unchanged.

-Ekr


>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

2016-09-01 Thread Dave Garrett 
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 specification? Does it have any relevance to TLS?

Did this slash form start with HTTP/2, or was there some other progenitor? Why 
did they go with that, anyway? I just find it to be a weird choice. If we 
actually have a consensus that it'd be better to go with TLS/2 than TLS 2.0, 
officially, I'd only be ok with it if someone can actually explain why. :|


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread Ilari Liusvaara 
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 EncryptedExtensions without
> >> early_data extension?
> >>
> >
> > I thought that was implicit, but i'd take a PR that did that.
> >
> 
> (s/EncryptedExtensions/ServerHello/, but whatever.)

According to the table it is EncryptedExtensions (but there have been
errors in it before)...
 
> At this point the client must do much more than cut transfer anyway. It
> probably should be phrased as starting over and retrying or so. Everything
> sent has been rejected and all you thought you knew about the connection
> may have changed, like ALPN. At sufficiently high layers, you should
> probably just pretend you got a fresh connection and are repeating the
> request (or whatever) from scratch.

So server is supposed to continue on 0-RTT fail, but not client?


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread David Benjamin 
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 the connection open for
>> > > essentially arbitrary amount of time while it consumes garbage data
>> is not
>> > > unlike the Apache slowloris attack.
>> >
>> > It's not required to. It can close the connection at any time.
>>
>> Should there be recommendation for clients to cut transfer and send
>> Finished if the client receives EncryptedExtensions without
>> early_data extension?
>>
>
> I thought that was implicit, but i'd take a PR that did that.
>

(s/EncryptedExtensions/ServerHello/, but whatever.)

At this point the client must do much more than cut transfer anyway. It
probably should be phrased as starting over and retrying or so. Everything
sent has been rejected and all you thought you knew about the connection
may have changed, like ALPN. At sufficiently high layers, you should
probably just pretend you got a fresh connection and are repeating the
request (or whatever) from scratch.

In the general case, you may even need to bounce to a new connection.
Consider if our session was established with h2, we try to 0-RTT-resume it,
send 20 replayable HTTP requests across it... and only then to hear from
server, "Nope, no 0-RTT for you, try again. Oh, by the way, we're talking
http/1.1 now." At least 19 of those 20 requests must get fresh connections
anyway.

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread Eric Rescorla 
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 time while it consumes garbage data is
> not
> > > unlike the Apache slowloris attack.
> >
> > It's not required to. It can close the connection at any time.
>
> Should there be recommendation for clients to cut transfer and send
> Finished if the client receives EncryptedExtensions without
> early_data extension?
>

I thought that was implicit, but i'd take a PR that did that.

-Ekr


>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread Hubert Kario 
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 text in it:
> > > > If any of these checks fail, the server MUST NOT respond
> > > > with the extension and must discard all the remaining first
> > > > flight data (thus falling back to 1-RTT). If the client attempts
> > > > a 0-RTT handshake but the server rejects it, it will generally
> > > > not have the 0-RTT record protection keys and must instead
> > > > trial decrypt each record with the 1-RTT handshake keys
> > > > until it finds one that decrypts properly, and then pick up
> > > > the handshake from that point.
> > > > 
> > > > My understanding of that, in case client does 0-RTT but server rejects
> > 
> > it
> > 
> > > > (because the PSK is too old or its time is different enough) is that
> > 
> > the
> > 
> > > > server needs to keep on reading arbitrarily large amounts of data it
> > 
> > has
> > 
> > > > no
> > > > idea what to do with
> > > > 
> > > > Why is there no limit on the amount of data that can be encrypted
> > > > using
> > > > PSK keys (0-RTT)?
> > > 
> > > I don't think this would usefully improve things.
> > 
> > there's also second angle:
> > 
> > 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 slowloris attack.
> 
> It's not required to. It can close the connection at any time.

Then how about making it explicit by including following paragraph:

To protect against denial of service attacks, servers MAY close the 
connection at any point when processing records with
trial decryption, but SHOULD process at least four records before doing 
so. This is so that server can find the second Finished message in case 
client sent just one record of Application Data.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread Eric Rescorla 
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
> > > with the extension and must discard all the remaining first
> > > flight data (thus falling back to 1-RTT). If the client attempts
> > > a 0-RTT handshake but the server rejects it, it will generally
> > > not have the 0-RTT record protection keys and must instead
> > > trial decrypt each record with the 1-RTT handshake keys
> > > until it finds one that decrypts properly, and then pick up
> > > the handshake from that point.
> > >
> > > My understanding of that, in case client does 0-RTT but server rejects
> it
> > > (because the PSK is too old or its time is different enough) is that
> the
> > > server needs to keep on reading arbitrarily large amounts of data it
> has
> > > no
> > > idea what to do with
> > >
> > > Why is there no limit on the amount of data that can be encrypted using
> > > PSK keys (0-RTT)?
> >
> > I don't think this would usefully improve things.
>
> there's also second angle:
>
> 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 slowloris attack.
>

It's not required to. It can close the connection at any time.

-Ekr

--
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

2016-09-01 Thread Hubert Kario 
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 first
> > flight data (thus falling back to 1-RTT). If the client attempts
> > a 0-RTT handshake but the server rejects it, it will generally
> > not have the 0-RTT record protection keys and must instead
> > trial decrypt each record with the 1-RTT handshake keys
> > until it finds one that decrypts properly, and then pick up
> > the handshake from that point.
> > 
> > My understanding of that, in case client does 0-RTT but server rejects it
> > (because the PSK is too old or its time is different enough) is that the
> > server needs to keep on reading arbitrarily large amounts of data it has
> > no
> > idea what to do with
> > 
> > Why is there no limit on the amount of data that can be encrypted using
> > PSK keys (0-RTT)?
> 
> I don't think this would usefully improve things.

there's also second angle:

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 slowloris attack.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

2016-09-01 Thread Adam Caudill 
> 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 
> situation with TLS/2 or TLS 4.0. 
> 
> I like TLS/2 aesthetically, and represents a similar level of progress/reset 
> that HTTP saw when it jumped from 1.1 to /2.
> 
> -- Eric

If it was called TLS/2, I suspect most people would still view it as TLS 2.0 - 
personally I see the / naming scheme as more of a aesthetic 
choice than something that meaningfully impacts perception.

The mistakes that were made that set up the potential confusion between SSL 2 
and TLS 2 were made long ago, and are likely beyond correction at this point. 
While we could go with TLS 3.4 (to match the version on the wire), or TLS 4.0 
(to jump past the SSL versions), I agree with those that stated that it would 
cause additional confusion. And there’s more than enough confusion out there 
thanks to SSL vs. TLS, no need to further complicate matters.

As for moving from TLS 1.3 to TLS 2.0 - this is something that will have to be 
dealt with at some point. Calling this version 2.0 was debated quite some time 
ago, and as I recall, the consensus then was to go with 1.3 and keep the 
changes minimal, saving 2.0 for a later, larger set of changes. Looking at the 
current version of the draft, calling this 2.0 seems fitting to me - as the 
changes have been fairly significant, not the overhaul that some wanted, but 
still significant.

Personally, I don’t think what we call it actually has that much impact though 
- calling it 2.0 could cause some to jump on it quicker, could cause those that 
are highly risk-adverse to delay it, I doubt either of these groups would be 
large enough to have an impact. It’s still a new version, and will be treated 
the same as new versions were in the past, no matter what we call it.

Overall, I’m indifferent on calling it 2.0, generally against /2, 3.4, 4.0, 
etc. and perfectly fine leaving it as 1.3.

-- 
Adam Caudill
a...@adamcaudill.com
http://adamcaudill.com/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-01 Thread Joachim Strömbergson 
-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 the STM32L0 series from ST for example. These devices can run on
energy harvesting and very tiny physically and very, very cheap (ten-ish
cents in high volume):

http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html?querycriteria=productId=SS1817

The STM32L021 has an AES-128 core. Not very fast (200+ cycles), but
several times faster than SW. You can also run the AES core wile the CPU
core is in power save mode.

Another example is the Zero Gecko from Silicon Labs. Same price range, a
huge number of power modes. And an AES core that is really fast. 50+
cycles for AES-128, which basically means 4 cycles/round (which implies
4 S-boxes)

https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx

Pre-shared key is whats easiest. But I've implemented Curve25519 for key
exchange on the STM32 device and can achieve <1 sec performance with
about 1 kByte RAM and 8 kByte code. I'm sure Peter Schwabe has some much
better results.


Yes, you can limit yourself to an 8-bit MCU and shave off some cents and
a little bit of power. But for most applications I see, a Cortex M0+
meets technical and commercial requirements too.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.

 Joachim Strömbergson  Secworks AB  joac...@secworks.se

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJXx923AAoJEF3cfFQkIuyN4tkP+QGscSmBzUAPbamlaRqpm7sh
zVwhMwhllJMdTs+HozeSbMvtw7JlO5vu+PyD/El4sxP2SAQhv1LqJFaC0nxuCJ2P
I+RxISEkrxYYB2YDRGlPd3Cfm4cRrDBd/BQCPMZuAQurWxH7ptMMKIZ3hS6NuOIb
gyluKMDMrUW9qFx0lrpa3yAMPHrBqlhHl1GmcUMJwoRVGOxDdc243YjNB7J/FEDh
pJCzI8Dv4uyWEufr0cBv1xCiSY4eaalv25H/Cyc3rZ78Os7d52DUyuBD8IAuAkkH
i32L2gK7CbrCF/3zw+Tv2aDn1ncGOiucENmQIzO99hwWwtJFC7TN59rCtoArmh5U
EC0Ncq1IIbicrot+DLibHNvSWk0c15bvtg1c06UecME21SF2t8ZigF0OuYKGdeu1
a4h0dUcNUyQxUbAs9JDTXtwABvR7CMNZi3kD5Vh8NfvK7DmojPVThrQ1r/2x+6hS
QnPiZcuvedjkM19y1hRchZQT23qPJQ4TrC5MvQSHnU20oW3QomPJfTAXtCctsN5s
3b+ZdWh5/EAysPpgjzzwKP0mWN3tkeSKROsh6BabMku84zerKPzCn5MwhyhUqHLD
Sv453a5oK0ne5pD/b7CIPWRwK2Z6/6pFN+jWPG0SZtZTgEJjkSVPaskMd51SVSga
EkqJv7VnqIa5lP5es+Is
=ri48
-END PGP SIGNATURE-

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

2016-09-01 Thread Judson Wilson 
>
> 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 situation with TLS/2 or TLS 4.0.
>
> 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 specification? Does it have any relevance to TLS?


On Wed, Aug 31, 2016 at 7:01 PM, Eric Mill  wrote:

>
>
> 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 downside.
>>
>> --Richard
>>
>> On Wednesday, August 31, 2016, Nick Sullivan 
>> wrote:
>>
>>> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a
>>> few immediate issues with the proposal:
>>> - it causes confusion with SSL 2.0
>>> - it implies wire incompatibility with TLS 1.2
>>> - it suggests there will be a forthcoming TLS 2.1 with only minor changes
>>>
>>> If we're dead set on bumping the major version for a mostly backwards
>>> compatible protocol change, we should just drop the minor version and go
>>> with TLS/2.
>>>
>>> Nick
>>>
>>
> 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 situation with TLS/2 or TLS 4.0.
>
> I like TLS/2 aesthetically, and represents a similar level of
> progress/reset that HTTP saw when it jumped from 1.1 to /2.
>
> -- Eric
>
>
>
>>
>>> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
>>> wrote:
>>>
 We could call it TLS 3.4 which would match the internal ID. :-)

 BTW, I think using something other than 1.3 is a good idea.

 Cheers - Bill

 
 -
 Bill Frantz| When it comes to the world | Periwinkle
 (408)356-8506  | around us, is there any choice | 16345 Englewood
 Ave
 www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA
 95032

 ___
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls

>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>
> --
> konklone.com | @konklone 
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls