Subject: [TLS] TLS 1.2 Long-term Support Profile draft posted

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Mar 2016 12:36:05 +0000

After a number of, uh, gentle reminders from people who have been waiting for
this, I've finally got around to posting the TLS-LTS draft I mentioned a while
back.  It's now available as:

http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt

Abstract:

   This document specifies a profile of TLS 1.2 for long-term support,
   one that represents what's already deployed for TLS 1.2 but with the
   security holes and bugs fixed.  This represents a stable, known-good
   profile that can be deployed now to systems that can't can't roll out
   patches every month or two when the next attack on TLS is published.

Several people have already commented on it off-list while it was being
written, it's now open for general comments...

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Mar 2016 08:02:42 -0700

> written, it's now open for general comments...

Several comments:

As written supporting this draft requires adopting the
encrypt-then-MAC extension. But there already is a widely implemented
secure way to use MACs in TLS: AES-GCM. Likewise, this draft modifies
the way the master secret is computed, despite a widely implemented
different solution to the problem, namely the EMS triple handshake
fix. I don't see why these other solutions should be adopted over the
ones that already are there.

The use of uncompressed points makes off-curve attacks much easier
than with compressed points. Recommendations to not reuse randoms for
ECDH and to use Curve25519 would actually solve the problems, instead
of what the draft has right now.

The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more
extensively analyzed then TLS 1.2. It's almost like you don't believe
cryptography exists: that is a body of knowledge that can demonstrate
that protocols are secure, and which has been applied to the draft.

The ladder diagram/state machine discussion ignores the real problem,
which is not having either represented in the code. It doesn't direct
readers to do anything that helps solve the problem, such as testing
for the correct state transitions.

>
> Peter.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 16 Mar 2016 08:31:06 -0700

> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt

Section 3.4. "Implementation Issues" says:

   TLS-LTS requires that RSA signature verification be done as encode-
   then-compare, which fixes all known padding-manipulation issues:

   o  TLS-LTS implementations MUST verify RSA signatures by using
      encode-then-compare, meaning that they encode the expected
      signature result and perform a constant-time compare against the
      recovered signature data.

This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section
8.2.2, with the additional requirement that the comparison in Step 4
be constant-time, right?

https://tools.ietf.org/html/rfc3447#section-8.2.2

and the alternative procedure outlined in the Note at the end of that
section shall not be used?

   Note.  Another way to implement the signature verification operation
   is to apply a "decoding" operation (not specified in this document)
   to the encoded message to recover the underlying hash value, and then
   to compare it to a newly computed hash value.  This has the advantage
   that it requires less intermediate storage (two hash values rather
   than two encoded messages), but the disadvantage that it requires
   additional code.

Thanks,
Wan-Teh Chang

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 16 Mar 2016 18:22:37 +0000

Hi

On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" <[email-masked]

>> written, it's now open for general comments...

<snip>

>that protocols are secure, and which has been applied to the draft.

This is patently untrue. There is a vast body of research analysing TLS
1.2 and earlier. A good survey article is here:

https://eprint.iacr.org/2013/049

(but even this is quite out of date in several respects). The literature
for TLS 1.3 is growing, but is an order of magnitude smaller in size. It
is pretty much represented in its entirety by the list of presentations at
the recent TRON workshop:

http://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-n
ot-tron-workshop-programme

As far as I know, the only complete analysis so far is this one:

http://tls13tamarin.github.io/TLS13Tamarin/

(full disclosure: two of my PhD students are involved). However, even
there, the analysis is symbolic and does not include 0-RTT (IIRC).

Maybe you'd care to revise your bold statement above?

Cheers

Kenny

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Mar 2016 11:44:02 -0700

> https://eprint.iacr.org/2013/049

There's a vast literature, but much of it makes simplifying
assumptions or doesn't address the complete protocol. The first really
complete analysis was miTLS AFAIK. Furthermore, a lot of the barriers
to analysis in TLS 1.2 got removed in TLS 1.3. The question is not how
many papers are written, but how much the papers can say about the
protocol as implemented. And from that perspective TLS 1.3's Tamarin
model is a fairly important step, where the equivalent steps in TLS
1.2 got reached only much later.

It's true 0-RTT isn't included: so don't do it. But I think if we
subset (not add additional implementation requirements) TLS 1.3
appropriately we end up with a long-term profile that's more useable
than if we subset TLS 1.2, and definitely more than adding to the set
of mechanisms. I think claims that TLS 1.3 outside of 0-RTT is likely
to have crypto weaknesses due to newness are vastly overstated.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 16 Mar 2016 19:26:59 +0000

Hi

On 16/03/2016 18:44, "Watson Ladd" <[email-masked]> wrote:

>assumptions or doesn't address the complete protocol.

Correct, but that does not make it irrelevant or valueless. Or are you
actually saying that it does? Quite a sweeping presumption; see
immediately below.

>The first really
>complete analysis was miTLS AFAIK.

Yes, and even there the analysis was done step by step, spread out over a
series of papers which gradually built up the complexity of the code-base
being handled. And, in parallel, various other groups were doing hand
proofs of abstractions of the core protocol. And I believe it's fair to
say - from having discussed it extensively with the people involved - that
the miTLS final analysis benefitted a lot from the experience gained by
the teams doing the hand proofs, going right back to a paper in 2002 by
Jonsson and Kaliski Jr.

My point is that the TLS 1.2 "final" analysis represented by the miTLS
work was the culmination of a long line of research involving many people
and influenced by many sources.

> Furthermore, a lot of the barriers
>to analysis in TLS 1.2 got removed in TLS 1.3.

Unfortunately, some of them may be coming back again. But again, this has
nothing to do with the argument you were making.

>The question is not how

The timing is entirely irrelevant to the argument you were making.

I agree though that it's about the depth and reach of the analysis. And
from this perspective, I'd say that TLS 1.3 is still way behind TLS 1.2,
despite the very nice analyses done by Sam and Thyla (and their
collaborators), by Hugo & Hoeteck, and by Felix & co.

I could go further, but I expect that, by now, only you and I are actually
reading this.

>to have crypto weaknesses due to newness are vastly overstated.

I didn't make that claim.

Cheers

Kenny

"If I have seen further it is by standing on the shoulders of Giants"
-- Newton, in a letter to Robert Hooke

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Mar 2016 04:00:35 -0400

> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt

Allowing CBC+encrypt-then-MAC seems like a messy route when AEAD is already available and deployed more widely. If you want to permit it, please make it optional and only have AEAD ciphers as MTI.

Also, you should add a recommendation/requirement of ChaChaPoly support in there so that there will be a backup in the long-term in the event of the need to panic disable AES under TLS 1.2 for some unforeseen reason. This is aiming to be an LTS, after all.

The big glaring problem, however, in multiple places, are the statements that something is "implicit in TLS-LTS, there is no need to signal it" via its designated extension. No! These features MUST be implemented in full, according to their specifications, such that they will work fully with servers that support them but not this new LTS proposal. Skimping on this just makes this messy situation even messier, which is the opposite of what you're trying to do here.

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Mar 2016 08:57:26 +0000

Watson Ladd <[email-masked]> writes:

>As written supporting this draft requires adopting the encrypt-then-MAC
>extension. But there already is a widely implemented secure way to use MACs
>in TLS: AES-GCM. 

This is there as an option if you want it.  Since it offers no length hiding,
it's completely unacceptable to some users, for example one protocol uses TLS
to communicate monitoring commands to remote gear, they're very short and
fixed-length, different for each command, so if you use GCM you may as well be
sending plaintext.  In addition GCM is incredibly brittle, get the IV handling
wrong and you get a complete, catastrophic loss of both integrity and
confidentiality.  The worst that happens with CBC, even with a complete abuse
like using an all-zero IV, is that you drop back to ECB mode.

>Likewise, this draft modifies the way the master secret is computed, despite
>a widely implemented different solution to the problem, namely the EMS triple
>handshake fix. 

Firstly, that solves an entirely different problem, and secondly I don't
recall ever seeing EMS support in any embedded device, it may be widely
implemented in Windows and OpenSSL but I don't know how much further it goes.

>The use of uncompressed points makes off-curve attacks much easier than with
>compressed points. 

Everything uses uncompressed points at the moment without any problems, and
compressed points are patented.

>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively
>analyzed then TLS 1.2. 

As the rationale points out, the mechanisms in SSL were also very heavily
analysed when they were released.  It didn't protect the protocol from 20
years of subsequent attacks, which we've leared about over those 20 years of
implementation and deployment experience.  With TLS 1.3 we have zero
implementation and deployment experience.  Do you really believe there will
never be any attacks on it after it's rolled out?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Mar 2016 08:59:00 +0000

Wan-Teh Chang <[email-masked]> writes:

>This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section 8.2.2,
>with the additional requirement that the comparison in Step 4 be constant-
>time, right?

Good catch, thanks!  I've added it to the draft.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Mar 2016 09:05:50 +0000

Dave Garrett <[email-masked]> writes:

I've already replied to the other parts in an earlier reply, leaving:

>The big glaring problem, however, in multiple places, are the statements that
>something is "implicit in TLS-LTS, there is no need to signal it" via its
>designated extension. No! These features MUST be implemented in full,
>according to their specifications, such that they will work fully with
>servers that support them but not this new LTS proposal. Skimping on this
>just makes this messy situation even messier, which is the opposite of what
>you're trying to do here.

Good point, I've changed the text to say that for TLS-LTS purposes you don't
need it, but you do if you need to interop with non-LTS servers/clients.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 18 Mar 2016 20:12:52 +0100

On Friday 18 March 2016 08:57:26 Peter Gutmann wrote:
> >Likewise, this draft modifies the way the master secret is computed,
> >despite a widely implemented different solution to the problem,
> >namely the EMS triple handshake fix.
> 
> Firstly, that solves an entirely different problem, and secondly I
> don't recall ever seeing EMS support in any embedded device, it may
> be widely implemented in Windows and OpenSSL but I don't know how
> much further it goes.

it may solve a different problem, but its solution is a superset of what 
you propose

I haven't seen support for X9.42 DHE parameters or selective mixing in 
of them to master secret in embedded devices either...

you modify behaviour of Master Secret calculation one way or another, 
let's do this in a way that is interoperable with other implementations, 
not add a third way to do that

also, if it really is supposed to be Long Term Support, why it doesn't 
say anything about implementation explicitly being able to handle big 
key sizes? both RSA and DHE?

I might have missed, but where is the specification of the acceptable 
signature algorithms (hash especially) on Server and Client Key Exchange 
messages?

Finally, I'd prefer the tls-lts to mostly say "see those other 
extensions? I really do mean it" + some pleasantries like the "no 
rehandshake".
-- 
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

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Mar 2016 09:30:26 +0000

Hubert Kario <[email-masked]> writes:

>also, if it really is supposed to be Long Term Support, why it doesn't say
>anything about implementation explicitly being able to handle big key sizes?
>both RSA and DHE?

I've deliberately avoided getting into that because it's such a rathole,
you've got everything from the NIST numerologists at one extreme to the "good
enough for now" folks at the other, and you'll never get any consensus because
there are completely different worldviews involved.  A possible median is:

Implementations SHOULD choose public-key algorithm key sizes that are
appropriate for the situation, weighted by the value of the information being
protected, the probability of an attack, and the ability of the hardware to
deal with large keys.  For example a SCADA system being used to switch a
ventilator on and off doesn't require anywhere near the keysize-based security
of a system used to transfer classified information.  One way to avoid having
to use very large public keys is to switch keys periodically.  This can be
done by regenerating DH parameters in a background thread and rolling them
over from time to time, or if this isn't possible, by pre-generating a
selection of DH parameters and choosing one at random for each new handshake,
or again rolling them over from time to time.

>signature algorithms (hash especially) on Server and Client Key Exchange

That's implicit in the cipher suites, RSA or ECDSA + SHA256.

Peter.

---

From: Sven Schäge <[email-masked]>
Date: Sat, 19 Mar 2016 22:06:31 +0100

Dear Kenny,

thank you for clarifying the state of the cryptographic analysis of TLS 1.2
and 1.3! I also do not see TLS 1.3 being nearly as good understood from a
security standpoint as the previous version. This is only natural given
that it is so recent. I am also not quite happy with the existing results
and their meaning for the final version of the standard (although I really
am happy that the cryptographic community in general accompanies the
standard development process.)
I would expect the most valuable results to be published once there is an
entirely fixed candidate specification. As Hugo has mentioned several times
details really matter. Therefore I really like the idea of giving
cryptographers time to analyse the final candidate quite thoroughly before
acceptance.

And no, you guys are not the only ones reading this.

Many greetings,
Sven

---

From: Dave Garrett <[email-masked]>
Date: Sat, 19 Mar 2016 19:30:35 -0400

https://tools.ietf.org/html/draft-gutmann-tls-lts-01#section-3.2

>   TLS-LTS adds a hash of the domain parameters into the master secret
>   to protect against the use of manipulated curves/domain parameters:
>
>   o  TLS-LTS implementations MUST include a SHA-256 hash of the EDH or
>      ECDH parameters in the master secret computation by concatenating
>      the hash to the pre_master_secret value.  In the case of EDH, the
>      value that's hashed is the ServerDHParams structure.  In the case
>      of ECDH the value that's hashed is the ServerECDHParams structure.
>      This means that the master_secret computation becomes:
>
>   master_secret = PRF(pre_master_secret || param_hash, "master secret",
>                       ClientHello.random + ServerHello.random)
>                       [0..47];

It would be a lot simpler, safer, and interoperable to just mandate use of the Extended Master Secret Extension [RFC 7627].

https://tools.ietf.org/html/rfc7627

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 20 Mar 2016 06:36:09 +0000

Dave Garrett <[email-masked]> writes:

>It would be a lot simpler, safer, and interoperable to just mandate use of
>the Extended Master Secret Extension [RFC 7627].
>

Yeah, in hindsight it makes more sense, I'll update the draft, although the
update may not get in before the IETF freeze.  I was trying to avoid having to
run two parallel hashing operations throughout the handshake (the other one
being for the Finished message), but EMS is just a much more comprehensive
solution (like EtM, it's one of those things where you think "why wasn't this
added to TLS years ago") even if it means running two lots of hashing.

The other update is to clean up the wording around which extensions TLS-LTS
implies, replacing the current wording scattered all over the draft.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 20 Mar 2016 13:09:45 +0200

> added to TLS years ago") even if it means running two lots of hashing.

Well, if you have suitable implementation for it, the hash in EMS is over
prefix of what hash in Finished is over (so if you can finalize multiple
times, you can get away with just one computation).

Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello
and ServerHello. This was famously exploited for FREAK and LOGJAM (and
then there is the DHE vs. ECDHE issue). Sadly, this was found out too late
for changing EMS extension to extend the signature.

Then there is the problem that DHE parameter sizes are not negotiated.
This is severe enough problem that it renders DHE effecively unusable
in some contexts[1][2].

And if you want ciphers that are actually not fragile, look at various
MRAE algorithms, not generic composition of CBC mode with HMAC (I have
seen even cryptographers get the latter wrong).

[1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has
negotiated DHE parameter sizes, there is nothing preventing down-
negotiation to TLS 1.2, followed by server dumping some bad para-
meter sizes (forcing client to either break connection or being vuln-
erable to downgrade attacks).

[2] If you wonder why Chrome is deprecating DHE, it is exactly this
problem.

-Ilari

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 20 Mar 2016 11:49:23 +0000

>times, you can get away with just one computation).

The problem with this is that the standard hash API is { Init, [ Update,
Update, ... ], Final }, so this only works if you've got access to a custom
API that allows you to fork the state so one branch goes to Final and the
other continues with Update.  It's good if you've got it, but a lot of
implementations don't.

>Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello and
>ServerHello. This was famously exploited for FREAK and LOGJAM (and then there
>is the DHE vs. ECDHE issue). Sadly, this was found out too late for changing
>EMS extension to extend the signature.

Hmm, what do people feel about adding this as a fix?  Given that the attacks
were based on implementations supporting crippled crypto when they shouldn't
have and accepting an export cipher suite when they shouldn't have (i.e. they
were pretty broken to begin with), is it worth the compatibility-breaking
change to try and address this?

>Then there is the problem that DHE parameter sizes are not negotiated. This
>is severe enough problem that it renders DHE effecively unusable in some
>contexts

That's such a can of worms there that I don't really want to get into it in 
-LTS, unless lots of people really want to see it addressed...

Peter.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sun, 20 Mar 2016 13:02:18 +0100

> implementations don’t.

Indeed, the hash required for EMS is usually the same as that required for client authentication,
so implementations that support client auth already support this, others may not.

> change to try and address this?

Adding the handshake hash to the ServerKeyExchange (a la EMS) provides
some nice protections against downgrade and seems to be worth the effort.

Of course, for all of these LTS improvements, we need to assume that the
LTS extension itself cannot be deleted by the attacker. That is, we’d assume
that the client or server supports *only* LTS mode. Otherwise, we’d have
to look closer to eliminate other downgrade attacks.

-Karthik

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 20 Mar 2016 12:37:15 +0000

Karthikeyan Bhargavan <[email-masked]> writes:

>Adding the handshake hash to the ServerKeyExchange (a la EMS) provides some
>nice protections against downgrade and seems to be worth the effort.

My only real concern with this is that if you've got an API that doesn't allow
forking, you're now running three hashes in parallel.  Still, for everything
else it'd be pretty straightforward, fork once after Server Hello for the
Server Keyex sig and a second time after Client Keyex for EMS.

So presumably instead of hashing the bare nonces for the keyex sig you'd hash
the entire hello message that contains them?

>Of course, for all of these LTS improvements, we need to assume that the LTS
>extension itself cannot be deleted by the attacker. That is, we’d assume that
>the client or server supports *only* LTS mode. Otherwise, we’d have to look
>closer to eliminate other downgrade attacks.

There's an SCSV-shaped hole in the draft for that :-).

Peter.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sun, 20 Mar 2016 13:53:36 +0100

> the entire hello message that contains them?

Yes, I’d suggest hashing in the log up to ServerHello, or if you don’t want to clone the hash state,
then maybe the log up to ServerCertificate. 

I agree that the benefit of this is not so clear for known-weak/export ciphersuites which should simply be disabled.
The main advantage is that it is a uniform way to prevent potential future downgrades on things like the elliptic curve.
It also prevents some downgrade attacks on False Start in case LTS enables it (I assume it doesn’t). 

> There's an SCSV-shaped hole in the draft for that :-).

Yeah, SCSV-like mechanisms can prevent downgrades from LTS to non-LTS, but only
as long as the non-LTS version does not support weak key exchanges like export RSA/DHE.
Otherwise, the attacker first deletes LTS, then downgrades to a weak key exchange, 
then breaks it to complete and hijack the connection.

So to get the full gain of LTS, we must require LTS implementations to blacklist weak ciphers even
for non-LTS TLS 1.2 connections. 

-Karthik

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Mar 2016 10:01:42 -0700

> erable to downgrade attacks).

The ServerRandom anti-downgrade mechanism should prevent this downgrade
from 1.3 to 1.2 even in this setting.

-Ekr

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2016 14:33:55 -0000

Peter Gutmann writes:
> compressed points are patented

Which patent are you referring to?

US 6141420, I suppose. Let's ignore the question of what's in the prior
art (1992 Harper--Menezes--Vanstone) and what's actually claimed in the
patent. Are you aware that this patent expired in July 2014?

> Everything uses uncompressed points at the moment without any problems

The same way that everyone uses C and C++ without any problems?

https://www.nds.rub.de/research/publications/ESORICS15/ completely broke
two implementations of uncompressed (x,y) ECDH in TLS. The problem, of
course, is that the implementors forgot to check that the input (x,y)
was on the curve.

OpenSSL _does_ try to check, but it seems that this check is sometimes
affected by recently announced bugs in OpenSSL's carry handling. The
impact isn't clear---analyzing this sort of thing is very difficult.
Using compressed (x,y) significantly reduces the amount of rarely tested
checking code for the implementor to screw up.

More importantly, there's a third option (introduced in Miller's
original ECC paper), namely using just x-coordinates. Section 4.1 of
https://cr.yp.to/papers.html#nistecc explains how X25519 uses this third
option to proactively and robustly avoid this type of attack.

---Dan

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 21 Mar 2016 06:17:37 +0000

Karthikeyan Bhargavan <[email-masked]> writes:

>Yes, I’d suggest hashing in the log up to ServerHello, or if you don’t want
>to clone the hash state, then maybe the log up to ServerCertificate.

OK, I've posted another update that specifies this, as well as use of EMS, and
cleans up a few other areas.  It's a bit of a rush job because of the
impending lockdown for IETF 95, but hopefully the gist is there:

http://www.ietf.org/id/draft-gutmann-tls-lts-02.txt

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 21 Mar 2016 12:29:27 +0100

On Saturday 19 March 2016 09:30:26 Peter Gutmann wrote:
> >also, if it really is supposed to be Long Term Support, why it
> >doesn't say anything about implementation explicitly being able to
> >handle big key sizes? both RSA and DHE?
> 
> I've deliberately avoided getting into that because it's such a
> rathole, you've got everything from the NIST numerologists at one
> extreme to the "good enough for now" folks at the other, and you'll
> never get any consensus because there are completely different
> worldviews involved.  A possible median is:
> 
> appropriate for the situation, weighted by the value of the
> information being protected, the probability of an attack, and the
> ability of the hardware to deal with large keys.  For example a SCADA
> system being used to switch a ventilator on and off doesn't require
> anywhere near the keysize-based security of a system used to transfer
> classified information.  One way to avoid having to use very large
> public keys is to switch keys periodically.  This can be done by
> regenerating DH parameters in a background thread and rolling them
> over from time to time, or if this isn't possible, by pre-generating
> a selection of DH parameters and choosing one at random for each new
> handshake, or again rolling them over from time to time.

Note that I asked for "being able to handle", not "selects and uses".

Yes, server which now uses 2048 bit DH parameters now is fine. It's not 
like it will use RSA keys that are any stronger, but it should be 
possible for the administrator to tell it to use 4096 bit (probably 
larger). Similarly, implementation shouldn't halt and catch fire if the 
server gives it big asymmetric keys. It's not Long Term otherwise.

> >signature algorithms (hash especially) on Server and Client Key
> >Exchange messages?
> 

no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1. of 
RFC 5246, you need to be explicit about it.
I really don't see the upside for decreasing the number of extensions 
the Client Hello carries. The implementation will need to interoperate 
with normal (i.e. already deployed) TLS 1.2 implementations anyway, why 
prevent code reuse?

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 21 Mar 2016 12:35:25 +0000

>Note that I asked for "being able to handle", not "selects and uses".

The issue here is that a Cortex M3 isn't going to be able to handle RSA-2048,
no matter what an RFC says :-).  That's what the "ability of the hardware to
deal with large keys" was meant to say.

When I've run into upper limits, it's almost always because the hardware can't
go much beyond the given upper-limit value (Sun's Java implementation with its
braindamaged 1024-bit upper limit for DLP keys was a notable exception).  So I
could perhaps say something like "implementations SHOULD handle key sizes of
up to 2048 bits, and MAY expect to see key sizes up to 4096 bits" or something
similar.

>no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1. of RFC
>5246, you need to be explicit about it.

Maybe I'm missing something here, but the text that refers to signing with
"RSA-SHA-256" and "ECDSA-P256-SHA-256" seems to be pretty unambiguous.  Is
there something else I need to add there?

>The implementation will need to interoperate with normal (i.e. already
>deployed) TLS 1.2 implementations anyway, why prevent code reuse?

Right, and if you need that you can include all the extensions you want.  If
you only need TLS-LTS, you can leave them out.

Peter.

---

From: Joachim Strömbergson <[email-masked]>
Date: Mon, 21 Mar 2016 14:07:56 +0100

Aloha!

Peter Gutmann wrote:
> The issue here is that a Cortex M3 isn't going to be able to handle
> RSA-2048, no matter what an RFC says :-).  That's what the "ability
> of the hardware to deal with large keys" was meant to say.

When you say that "a Cortex M3 isn't going to be able to handle
RSA-2048", what do you mean specifically? Considering that it is being
done by for example SharkSSL [1], is supported by ARM mbed TLS (nee
PolarSSL) [2] I fail to see what hardware limits you are seeing. Yes,
the speed you get is not impressive (1-2 seconds to decrypt), but it
might be ok, depending on your application.

[1] https://realtimelogic.com/products/sharkssl/Cortex-M3/
[2] https://tls.mbed.org/

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

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Mar 2016 13:19:55 +0000

> cleans up a few other areas.  It's a bit of a rush job because of the impending
> lockdown for IETF 95, but hopefully the gist is there:
> 

So is someone "in the camp" coming to BA and can present this?  Or remotely?

---

From: Hubert Kario <[email-masked]>
Date: Mon, 21 Mar 2016 15:38:43 +0100

> of the hardware to deal with large keys" was meant to say.

even 10 seconds to establish a session that is then kept up for days 
and/or uses session resumption is something many environments would be 
able to handle.

If your hardware really can't do anything better than 2048 bit RSA, it's 
not LTS, it's a crippled embedded system, and it definitely shouldn't 
get a stamp of approval "good for next X0 years" or anything similar 
like a LTS moniker would imply.

Also, you're explicitly saying that this proposal is limiting the TLS 
parameter set to "known-good subset". 1024 bit RSA and DHE are not 
known-good, if Cortex M3 really can't handle RSA-2048, for crypto it's 
as good as a coaster already.

the system is only as strong as the weakest link

> When I've run into upper limits, it's almost always because the
> hardware can't go much beyond the given upper-limit value (Sun's Java
> implementation with its braindamaged 1024-bit upper limit for DLP
> keys was a notable exception).  So I could perhaps say something like
> "implementations SHOULD handle key sizes of up to 2048 bits, and MAY
> expect to see key sizes up to 4096 bits" or something similar.

there's a similar limit in NSS with client certificates, although I 
don't remember the exact number now, I'm quite sure that a 8k key would 
get rejected.

> >no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1.
> >of RFC 5246, you need to be explicit about it.
> 
> Maybe I'm missing something here, but the text that refers to signing
> with "RSA-SHA-256" and "ECDSA-P256-SHA-256" seems to be pretty
> unambiguous.  Is there something else I need to add there?

it doesn't explain where this "RSA-SHA-256" is used. IMHO it is 
ambiguous.

The "no MAC truncation" is also not explicit about what the sizes should 
be.

> >The implementation will need to interoperate with normal (i.e.
> >already deployed) TLS 1.2 implementations anyway, why prevent code
> >reuse?
> Right, and if you need that you can include all the extensions you
> want.  If you only need TLS-LTS, you can leave them out.

my point is, that the code path of the tls-lts extension should check 
the sanity of extensions passed and abort if anything is not according 
to the LTS when LTS is supposed to be enforced.

in other words, LTS should be an addition to already existing code, not 
a replacement.

You may be dealing with hardware that often requires careful pruning of 
code base to make it fit. Thing is, that there are also millions of 
devices which can handle full OpenSSL/PolarSSL/etc. just fine. And for 
those it's better if the code paths used are the same or as similar as 
possible in all situations. Any other approach leads to subtle and hard 
to find bugs. Exactly what we don't want to see in LTS code.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 21 Mar 2016 15:42:00 -0400

> like a LTS moniker would imply.

+1

Frankly, I think this document should be renamed "Extended Support Profile", rather than "Long-term Support Profile" (and ESP instead of LTS). In anything even approaching the long-term, TLS is dead due to the need for post-quantum crypto, yet to be defined. I'm not even convinced this document is capable of defining a known-good set that can survive for ten years, so that text should really be relaxed significantly. (in this context, 10 years is not "long-term")

The bare minimum anyone should be stating for a 10 year window is something like 3248 bit RSA or ~256 bit ECDSA/EdDSA, and only with the qualifier that upgrades will probably be needed at some point over the next decade. Hardware that can't handle this is not short or medium-term viable, let alone long-term.

https://www.keylength.com/en/3/

Hardware needs to accommodate the viable specifications, not the other way around. If it takes a second or two to perform a handshake, then that's what it takes until it's upgraded/replaced.

Dave

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Mar 2016 00:43:52 +0200

> On 21 Mar 2016, at 3:19 PM, Salz, Rich <[email-masked]> wrote:
> 
> 

I don’t know who’s “in the camp”. I don’t think I am. But if someone would like to prepare slides and request a slot, I can volunteer to present them.

This usually turns out better than presenting remotely.

Yoav

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 21 Mar 2016 18:59:27 -0700

On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett <[email-masked]>
wrote:

> Frankly, I think this document should be renamed "Extended Support
> Profile", rather than "Long-term Support Profile" (and ESP instead of LTS).

Legacy Support Profile? Then you don't have to change the acronym

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Mar 2016 00:26:46 -0400

On Monday, March 21, 2016 09:59:27 pm Tony Arcieri wrote:
> On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett <[email-masked]> wrote:

I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"...  ;)

Dave

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 21 Mar 2016 21:32:00 -0700

> I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"...  ;)

Haha, oops. LSP?

-- 
Tony Arcieri

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 22 Mar 2016 09:48:51 +0000

Joachim Strömbergson <[email-masked]> writes:

>When you say that "a Cortex M3 isn't going to be able to handle RSA-2048",
>what do you mean specifically? Considering that it is being done by for
>example SharkSSL [1], is supported by ARM mbed TLS (nee PolarSSL) [2] I fail
>to see what hardware limits you are seeing. Yes, the speed you get is not
>impressive (1-2 seconds to decrypt), but it might be ok, depending on your
>application.

It's not just RSA, it's DH as well (looking at the SharkSSL library link it
looks like it doesn't do DH at all, only RSA key transport).  I've seen PLCs
where DHE+RSA leads to handshake times of 10-15s (not an M3, I just use that
as a convenient mental model for an embedded CPU, this was using an industrial
Power SoC), which isn't a good thing when what you're trying to communicate is
an emergency shutdown command.

In these situations, crypto comes at about position 77 in the priority list,
with most of the previous ones taken up by "reliability" and "availability".
If you write a spec that in effect mandates a 15-second delay in communicating
commands to a controller, guess what vendors are going to do?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 22 Mar 2016 09:55:07 +0000

Hubert Kario <[email-masked]> writes:

>it doesn't explain where this "RSA-SHA-256" is used. IMHO it is ambiguous.
>
>The "no MAC truncation" is also not explicit about what the sizes should be.

Well can you suggest some wording?  I can't see how much more unambiguous a
statement like "no MAC truncation" can be.

Peter.

---

From: Joachim Strömbergson <[email-masked]>
Date: Tue, 22 Mar 2016 11:04:55 +0100

Aloha!

Peter Gutmann wrote:
> In these situations, crypto comes at about position 77 in the
> priority list, with most of the previous ones taken up by
> "reliability" and "availability". If you write a spec that in effect
> mandates a 15-second delay in communicating commands to a controller,
> guess what vendors are going to do?

They are going to do the handshake once every day (or even less) and
keep the session alive. Or use session resumption. Based on what I've
seen in PLCs you normally don't start a new session for every single
command. YMMV.

- --

---

From: Hubert Kario <[email-masked]>
Date: Tue, 22 Mar 2016 11:42:23 +0100

On Tuesday 22 March 2016 09:48:51 Peter Gutmann wrote:
> >RSA-2048", what do you mean specifically? Considering that it is
> >being done by for example SharkSSL [1], is supported by ARM mbed TLS
> >(nee PolarSSL) [2] I fail to see what hardware limits you are
> >seeing. Yes, the speed you get is not impressive (1-2 seconds to
> >decrypt), but it might be ok, depending on your application.
> 
> It's not just RSA, it's DH as well (looking at the SharkSSL library
> link it looks like it doesn't do DH at all, only RSA key transport). 
> I've seen PLCs where DHE+RSA leads to handshake times of 10-15s (not
> an M3, I just use that as a convenient mental model for an embedded
> CPU, this was using an industrial Power SoC), which isn't a good
> thing when what you're trying to communicate is an emergency shutdown
> command.
> 
> In these situations, crypto comes at about position 77 in the priority
> list, with most of the previous ones taken up by "reliability" and
> "availability". If you write a spec that in effect mandates a
> 15-second delay in communicating commands to a controller, guess what
> vendors are going to do?

attacks only get better

if the hardware can't do crypto securely now, it certainly won't be able 
to do it tomorrow (you know, in the "Long Term")

it's a waste of time to patch up attacks that are still largely 
theoretical if you leave a mile wide hole in the fence
-- 
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

---

From: Hubert Kario <[email-masked]>
Date: Tue, 22 Mar 2016 11:57:31 +0100

On Tuesday 22 March 2016 09:55:07 Peter Gutmann wrote:
> Well can you suggest some wording?  I can't see how much more
> unambiguous a statement like "no MAC truncation" can be.

The Finished hash comes from PRF, which in turn comes from P_hash 
construct which has practically unlimited output. The MAC is not 
truncated there, the PRF output is, because it must be, as it is 
defined.

I was thinking of something like the following:

  The length of verify_data (verify_data_length) in the Finished message
  MUST be equal to the length of output of the hash function used as the 
  basis of the PRF selected for the ciphersuite. That is, in case of 
  SHA-256 based PRF 32 octets MUST be used. This overrides the 
  requirement from Section 7.4.9. of RFC 5246 that all ciphersuites 
  defined at that time have verify_data_length of 12.
-- 
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

---

From: Hubert Kario <[email-masked]>
Date: Tue, 22 Mar 2016 12:29:30 +0100

On Tuesday 22 March 2016 00:26:46 Dave Garrett wrote:
> > > Profile", rather than "Long-term Support Profile" (and ESP instead
> > > of LTS).> 

given that we're trying to predict future, Extra Sensory Perception is a 
good acronym to use ;)
-- 
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

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Mar 2016 09:11:52 +0000

>  defined at that time have verify_data_length of 12.

Thanks, I've added words to that effect to the draft, and also added a few
other cleanups as well.

Peter.

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 29 Mar 2016 03:23:09 +0200

On 2016-03-18 09:57, Peter Gutmann wrote:
> Watson Ladd<[email-masked]>  writes:
>

Indeed. For instance, if VM reset attacks are a concern, GCM is arguably 
a worse option than CBC, in particular if the CBC record IV generation 
can be made to be random even in the case of a VM reset attack.

http://crypto.stackexchange.com/questions/32203/is-tls-secure-against-vm-reset-attacks