Subject: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)

From: Jeffrey Walton <[email-masked]>
Date: Wed, 16 Sep 2015 03:29:08 -0400

P
This seems like another one of those bikeshed questions that will be
endlessly debated....

Somewhat off-topic, why does TLS not produce a few profiles. One can
be "Opportunistic TLS Profile" with a compatible security posture and
include ADH. Another can be a "Standard TLS Profile" and include
things like export grade crypto, weak and wounder ciphers SSLv3, etc.
Finally, there can be a "TLS Defensive profile" where you get mostly
the strong the protocols and ciphers, HTTPS Pinning Overrides are not
allowed so the adversary cannot break the secure channel by tricking a
user, etc.

Would this make it easier to create consensus and align with user
expectations (and make it easier to administer)?

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Sep 2015 08:19:51 +0000

Jeffrey Walton <[email-masked]> writes:

>Somewhat off-topic, why does TLS not produce a few profiles. One can be
>"Opportunistic TLS Profile" with a compatible security posture and include
>ADH. Another can be a "Standard TLS Profile" and include things like export
>grade crypto, weak and wounder ciphers SSLv3, etc. Finally, there can be a
>"TLS Defensive profile" where you get mostly the strong the protocols and
>ciphers, HTTPS Pinning Overrides are not allowed so the adversary cannot
>break the secure channel by tricking a user, etc.

+1.  At the moment you're stuck with everything-all-the-time (or alternatively
one-size-misfits-all) where you have to support every single mechanism and
quirk and add-on, when all you want most of the time is to set up a basic
secure tunnel from A to B.  Having profiles would be a great help, so all the
other standards groups that build on TLS can refer to, say, the emebedded-
device profile or the PFS-with-PSK profile rather than having to hack around
the standard themselves.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Sep 2015 09:45:14 +0100

> device profile or the PFS-with-PSK profile rather than having to hack around

We have BCP195 [1] that aims for the "general" case (for
up to TLS1.2) and a draft [2] (current in IESG evaluation)
for the embedded case. Are those the kind of thing you're
after?

If so, and you wanted more, the UTA WG [3] (which produced
BCP195) would maybe be the best place to see if there's
enough interest in doing more. (The embedded one was done
in the DICE WG [4] which was setup mostly for that as it's
to some extent a different set of folks. And that could be
done again if needed.)

Cheers,
S.

[1] https://tools.ietf.org/html/bcp195
[2] https://tools.ietf.org/html/draft-ietf-dice-profile-16
[3] https://tools.ietf.org/wg/uta/
[4] https://tools.ietf.org/wg/dice/

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

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 16 Sep 2015 06:47:01 -0400

> to some extent a different set of folks. And that could be
This kinda begs the question, who should be responsible for high level
TLS configurations to ease management, maximize security and minimize
interoperability issues.

For that, I'd argue it falls squarely within TLS WG purview.

One of the things I've noticed (maybe incorrectly): the NSA and other
who want to exert influence do not have to influence a group like the
TLS WG.* There's enough mass and dissension that weakening is organic.
A small selection of profiles could be a strategic move to cut-off
that avenue if it is being taken advantage of.

Strategic planning is something that should to be led by leadership.

Jeff

* Maybe I should say, "not actively influence them", like the case of
RSA Data Securities and the Dual EC generator.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Sep 2015 10:48:57 +0000

> This kinda begs the question, who should be responsible for high level TLS
> configurations to ease management, maximize security and minimize
> interoperability issues.
> 

The security area has a hand in reviewing all of them, as part of the IESG review.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Sep 2015 11:18:56 +0000

Stephen Farrell <[email-masked]> writes:

>We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a
>draft [2] (current in IESG evaluation) for the embedded case. Are those the
>kind of thing you're after?

Sort of, but since they're not part of the TLS spec they essentially don't
exist (I've never seen then quoted, cited, or referenced in any third-party
standard that deals with TLS).

Another problem is that they're defined as a large collection of (often rather
waffly) "don't do this" comments, so as a somewhat wooly blacklist rather than
a clear whitelist.  So the BCPs aren't really a profile but more like 20-30
pages of hand-wringing.

An actual profile of TLS would be something like MUST TLS 1.1 or above, MUST
PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication what isn't
explicitly permitted is denied).

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Sep 2015 14:22:28 +0000

> An actual profile of TLS would be something like MUST TLS 1.1 or above,
> MUST PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication
> what isn't explicitly permitted is denied).

HTTP-2 did this kind of thing, and IIRC are the first to do so.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Sep 2015 15:44:07 +0100

> standard that deals with TLS).

I'm not sure how to process that comment. You ask for X, I ask is Y==X
and your answer is that Y doesn't exist? Seems odd. ;-)

Anyway, so far 5 RFCs reference BCP195. [1] I'd say that'll grow over
time. Hopefully folks implementing will find it useful too and not only
those writing RFCs that need TLS, but I guess we'll see over time if
BCP195 got it right or not.

  [1] http://www.arkko.com/tools/allstats/citations-rfc7525.html

> a clear whitelist.  So the BCPs aren't really a profile but more like 20-30

Feel free to collect a bunch of your own emails (hand-wringing or
not:-) and shoot those out as an I-D.

> explicitly permitted is denied).

Yes, life would be lovely if things were so simple.

S.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Sep 2015 14:59:32 +0000

Stephen Farrell <[email-masked]> writes:

>I'm not sure how to process that comment. You ask for X, I ask is Y==X and
>your answer is that Y doesn't exist? Seems odd. ;-)

There's a difference between "X/Y exists" (but no-one knows about it) and "X/Y
exists and is actively used".  As I said, I've never seen the BCP quoted,
cited, or referenced in any third-party standard that deals with TLS (and by
third-party standard I don't mean other RFCs but industry standards like IEC
61850 or IEC 62351).

>Feel free to collect a bunch of your own emails (hand-wringing or not:-) and
>shoot those out as an I-D.

That makes it worse, not better, because it's just creating one more I-D or
RFC or BCP or whatever to languish in obscurity.  The profiles need to be part
of the TLS spec where they'll be noticed and used by other standards
referencing it.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Sep 2015 15:02:36 +0000

>HTTP-2 did this kind of thing, and IIRC are the first to do so.

Some PKI standards have done it too, but mostly because the base standard was
such a mess that you needed a profile just to sort out what needed to be
implemented for anything to work (for some level of "work").  They're such a
design counterexample that I didn't want to mention them in my original
message :-).

Peter.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Sep 2015 10:44:56 -0700

> design counterexample that I didn't want to mention them in my original

Yes.  I wouldn't recommend following this path to others; it's not
easy and the return on that investment isn't all good.  The mess we
were attempting to clean up with HTTP/2 was the state of TLS
deployment on the web, not so much the spec itself.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 14:10:36 -0400

> deployment on the web, not so much the spec itself.

The profiles idea feels like a way to justify having a crap profile in the mix. HTTP/2 didn't so much as have a profile, as restrict the TLS defaults. We should be focusing on restricting TLS to always actually be competent. The other "profiles" we have are application profiles (already a thing) and the "let's ignore the spec" profile that is popular with some.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Sep 2015 18:21:05 +0000

On Wed, Sep 16, 2015 at 02:10:36PM -0400, Dave Garrett wrote:

> The profiles idea feels like a way to justify having a crap profile in the mix.

I see no basis for that dismissive throw-away.

> We should be focusing on restricting TLS to always actually be competent.

All profiles are restrictions by definition, they don't add new
features.  Competence is context dependent.

The advantage of profiles is that they standardize sensible
combinations of features, and encourage toolkits to provide interfaces
for applications to track a particular profile.

This also makes it easier for toolkits to harden some profiles
selectively without breaking other profiles.

Explicit profiles make some sense.  They need not be defined by
the TLS WG per-se, it might be enough for the TLS specification to
reference an IANA profile registry, with the TLS-WG defining a
"base" profile.  Then other WGs (including the[ TLS WG) can define
additional profiles.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 15:03:54 -0400

> I see no basis for that dismissive throw-away.

I do:

> allowed so the adversary cannot break the secure channel by tricking a

The suggestion that started this thread was to have a "Standard TLS Profile" that actually allowed EXPORT ciphers & SSL3. So yeah, this proposal feels like a suggestion to keep allowance of obsolete junk as the norm with "defensive" as a separate option, because that's what it specifically says.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Sep 2015 21:38:27 +0000

On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote:

> The suggestion that started this thread was to have a "Standard TLS Profile"
> that actually allowed EXPORT ciphers & SSL3. So yeah, this proposal feels
> like a suggestion to keep allowance of obsolete junk as the norm with
> "defensive" as a separate option, because that's what it specifically
> says.

Object to such a profile, and rather than the idea of profiles.
There is no need for the TLS WG to define any profiles that include
SSL3 or EXPORT ciphers.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 18:37:21 -0400

> There is no need for the TLS WG to define any profiles that include

That's a fair point, but I don't see the need for a profile once that stuff is not allowed anywhere. I could accept the notion of a TLS strict mode, where it's TLS 1.2 + PFS + AEAD + no SHA1/DSA/SSL2HELLO/etc. only, but that's not really a "profile" so much as one paragraph that could be added. Application profiles are already a thing, so I don't see why we also need a new mechanism here.

Let me put it this way, I see no way for the WG to reasonably agree on this without a proposed _set_ of profiles to go with it that we all could also live with. Just the vague notion of more profiles in abstract isn't sounding great on its own.

Dave

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 18:00:25 -0500

On Wed, Sep 16, 2015 at 06:37:21PM -0400, Dave Garrett wrote:
> That's a fair point, but I don't see the need for a profile once that
> stuff is not allowed anywhere. I could accept the notion of a TLS

<mentally splice in long and never-ending debate about opportunistic use
of weaker ciphers, so that we don't have physically splice it in here>

> strict mode, where it's TLS 1.2 + PFS + AEAD + no
> SHA1/DSA/SSL2HELLO/etc. only, but that's not really a "profile" so
> much as one paragraph that could be added. Application profiles are
> already a thing, so I don't see why we also need a new mechanism here.

It's a profile.  Call it what you will.  The rest of us call this a
profile.  All the more so when profiles are named in an IANA registry.
Applications can then very trivially select an appropriate TLS profile
using standard profile naming.

> Let me put it this way, I see no way for the WG to reasonably agree on
> this without a proposed _set_ of profiles to go with it that we all
> could also live with. Just the vague notion of more profiles in
> abstract isn't sounding great on its own.

We've certainly had a few proposed profiles over time.  Your estimation
of what the WG would or would not agree to is not as interesting as, you
know, actually attempting to get consensus.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 19:14:48 -0400

> of weaker ciphers, so that we don't have physically splice it in here>

Understood and agreed with. Opportunistic encryption gets to do things weird, and that's fine. It could get it's own document, which you could call a profile, but again, that's not the core of what was actually suggested. The start of this was a suggestion of OE, "standard" as crap, and "defensive" for non-crap.

> using standard profile naming.

Yeah, we don't need to argue semantics. My point is that I'd agree with a more strict profile than what we have now as an addon, but not a more permissive profile, as was the initial suggestion.

> know, actually attempting to get consensus.

Agreed, which is why I think this discussion would be more useful with actual specific profiles to talk about. ;)

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 16 Sep 2015 19:57:40 -0400

> Yeah, we don't need to argue semantics. My point is that I'd agree with a more strict profile than what we have now as an addon, but not a more permissive profile, as was the initial suggestion.

I think it would be wise to acknowledge the "compatibility" use case,
and capture it in a profile. It would be more permissive because it
provides compatibility, like SSLv3.

And because SSLv3 is represented in a down level profile for those who
need it, then it could be removed from standard and more defensive
profiles without much fuss.

For me, its about acknowledging "one size does not fit all" and
managing debates. One size fits all ultimately draws out the process
and weakens things even though its not anyone's agenda.

> Agreed, which is why I think this discussion would be more useful with actual specific profiles to talk about. ;)

Right, a concrete list would probably be helpful. The list should
probably be based on use cases.

* Compatibility - down level servers that can't be upgraded, and
clients/UAs that must connect to them
* Embedded - low(er) capability crypto, like CAC/PIV cards, smart
cards and Hotelier Locks, and similar use cases
* Opportunistic - capture email, FTP, etc here. Viktor makes the best
arguments here; defer to him
* Standard - where the working group would like to be in a typical
security posture.
* Defensive - where risk adverse folks would like to be in a defensive
security posture.

Defensive is an interesting profile. I imagine it would include TLS
1.2 and/or 1.3 only, no key transport, authenticated encryption mode
ciphers, no HTTPS Pinning Overrides, etc. Then, auditors in industry
like healthcare or PCI can call it out by name and everyone is on the
same page. The auditors and organizations can worry less about patient
or card holder data being leaked because a user was phished or visited
another organization (that required a configuration change to use the
wireless network).

It might also be wise to use "Standard 2015" because in 3 or 5 years,
its going to be revised. Then there's no confusion when things are
updated an "Standard 2019" becomes available.

Jeff

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 17 Sep 2015 00:37:44 +0000

On Wed, Sep 16, 2015 at 07:14:48PM -0400, Dave Garrett wrote:

> Yeah, we don't need to argue semantics. My point is that I'd agree with
> a more strict profile than what we have now as an addon, but not a more
> permissive profile, as was the initial suggestion.

I don't think that "permissive" vs. "strict" is the right axis to
distinguish between profiles.  Rather one axis is "Constrained"
vs. "General", and another axis is "Opportunistic" vs. "Mandatory".

What's different will be the MTI ciphers, and recommended preferred
ciphers.  Adding crap banned by the base protocol is not the point.
In other words, a profile will have:

    * MUST support parameters	(required interop)
    * SHOULD support parameters (additional preferred)
    * MAY support parameters
    * MUST NOT support parameters

that can vary over time independently of other profiles.

Then folks can go ahead and drop RC4 with prejudice from "Mandatory",
while initially leaving it enabled in "Opportunistic".

Which profiles are developed depends on how much interest there is
in from particular "market segment" to define said profile.

The main question is whether enough interested parties will be
willing to work on such profiles.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 20:47:11 -0400

> profiles without much fuss.

What's confusing things here is that SSL3 is _already_ removed from the standards.

RFC 7568 was published to say it MUST NOT be negotiated from any version of TLS:
https://tools.ietf.org/html/rfc7568#section-3

I already added this to the TLS 1.3 draft as well:
https://tools.ietf.org/html/draft-ietf-tls-tls13-08#appendix-C.3

There is no legitimate use of SSL3 by any implementation/organization which acknowledges any new IETF standards. Mention of it at all is a proposal to undo this in some form. It's already supposed to be dead and buried and only in use by obsolete junk which isn't keeping up with new standards.

> and weakens things even though its not anyone's agenda.

This is certainly true for IoT, in current practice, and that's why there's a separate I-D for that.

> probably be based on use cases.

Yes.

> clients/UAs that must connect to them

I argue that this is not a legitimate use case, not because I consider it bogus, per se, but because those in this use-case are already not following standards and thus adding a new one for them is not particularly helpful. There is also no such thing as a server that can't be upgraded; just ones for which someone has decided to not allocate the proper resources to do so because security is not considered a priority.

> arguments here; defer to him

Yes & Yes

> * Defensive - where risk adverse folks would like to be in a defensive

I'm sort of neutral on this, but it could just be about how we frame it. I'm thinking standard and strict, in that strict simply permits no obsolete features for the purposes of backwards compatibility (e.g. TLS 1.2+ with only features which TLS 1.3 allows). This is somewhat different in that I don't think anything else should change, e.g. recommendations of key strengths or algorithms should not change to accommodate a more defensive posture. The standard should be sufficient on its own. What I'm thinking of is a strict profile that would essentially just be the basis of TLS 1.4's expectations, for those who can do it now, not for any special security need. I'm largely against the idea that we should pick and choose who deserves "good" security and who deserves "ideal" security. Special-casing just lets one group race to the bottom, or stay there.

> updated an "Standard 2019" becomes available.

Good point on naming and versioning by year is a very very good idea.

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Sep 2015 02:07:11 +0000

Profiles are out of scope for the currently-chartered WG and, as we've seen from previous times these discussions have come up, they tend to overwhelm everything.

Please take it off-list.

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 17 Sep 2015 02:20:23 +0000

> TLS configurations to ease management, maximize security and minimize

Isn't that the goal of a reasonable protocol, generally?

> TLS WG.*

None the less, they (NSA) work to do exactly that for various aspects
of the IETF.

> There's enough mass and dissension that weakening is organic.

Why not design a protocol that is secure regardless of how it is
deployed absent issues with entropy?

> Strategic planning is something that should to be led by leadership.

Democratic participation is strategic - positions of leadership are
subject to capture. Should we really follow the leadership when
sometimes they are literally paid by the NSA?

> RSA Data Securities and the Dual EC generator.

Those were ECI BULLRUN (and friends) and thus very much active. The
IETF is targeted by FVEY (and likely others) for human infiltration
and considered fair game. Lots more about BULLRUN remain to be found,
I'm sure of it.

All the best,
Jacob

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Sep 2015 03:27:22 +0000

Viktor Dukhovni <[email-masked]> writes:

>Explicit profiles make some sense.  They need not be defined by the TLS 
>WG per-se, it might be enough for the TLS specification to reference an 
>IANA profile registry, with the TLS-WG defining a "base" profile.  Then 
>other WGs (including the[ TLS WG) can define additional profiles.

That would be good, so the base spec could contain text like "This document 
describes every possible option that the protocol can support.  It is not 
expected that TLS applications implement every one of these options, since 
many will be inappropriate or unnecessary in many situations.  Profiles for 
specific situations like web browsing, secure tunnels, IoT, embedded 
devices, and SCADA use can be found  at ...".

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 17 Sep 2015 12:45:30 +0200

On Thursday 17 September 2015 03:27:22 Peter Gutmann wrote:
> >Explicit profiles make some sense.  They need not be defined by the
> >TLS WG per-se, it might be enough for the TLS specification to
> That would be good, so the base spec could contain text like "This
> document describes every possible option that the protocol can
> support.  It is not expected that TLS applications implement every
> one of these options, since many will be inappropriate or unnecessary
> in many situations.  Profiles for specific situations like web
> browsing, secure tunnels, IoT, embedded devices, and SCADA use can be
> found  at ...".

You can count on one hand the Mandatory-to-Implement ciphersuites.

It's quite obvious that if you don't support anything but non-export RSA 
key exchange, you don't need to be able to parse Server Key Exchange 
messages...
-- 
Regards,
Hubert Kario
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: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 17 Sep 2015 16:28:01 +0000

On 9/16/15, 4:19 , "TLS on behalf of Peter Gutmann" <[email-masked]

>device profile or the PFS-with-PSK profile rather than having to hack

+2. I think this is necessary, *and* falls (or should fall) under the TLS
WG prerogative.