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

[Jacob Appelbaum <[e-mail]>]

On 9/16/15, Jeffrey Walton <[e-mail]> wrote:
> On Wed, Sep 16, 2015 at 4:45 AM, Stephen Farrell
> <[e-mail]> wrote:
>>
>>
>> On 16/09/15 09:19, Peter Gutmann wrote:
>>> Jeffrey Walton <[e-mail]> 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.
>>
>> 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.)
>>
> This kinda begs the question, who should be responsible for high level
> TLS configurations to ease management, maximize security and minimize
> interoperability issues.

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

> 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.*

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.
> A small selection of profiles could be a strategic move to cut-off
> that avenue if it is being taken advantage of.

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?

> Jeff
>
> * Maybe I should say, "not actively influence them", like the case of
> 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