From: Dave Garrett <davemgarrett@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Date: Wed, 16 Sep 2015 19:14:48 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAH8yC8=eHzQPL6cROVK4Pm0V2FSYTL7C7csLG7p49W5LEmfo=Q@mail.gmail.com>
 <201509161837.21743.davemgarrett@gmail.com>
 <20150916230024.GS13294@localhost>
In-Reply-To: <20150916230024.GS13294@localhost>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201509161914.48720.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/GZa9vVUpu8OpojlKBBXwmaLSl10>
Cc: tls@ietf.org
Subject: Re: [TLS] TLS Provfiles (Was: Call for consensus to remove
 anonymous DH)
Precedence: list

On Wednesday, September 16, 2015 07:00:25 pm Nico Williams wrote:
> On Wed, Sep 16, 2015 at 06:37:21PM -0400, Dave Garrett wrote:
> > On Wednesday, September 16, 2015 05:38:27 pm Viktor Dukhovni wrote:
> > > 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.
> > 
> > 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>

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.

> > 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.

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.

> > 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.

Agreed, which is why I think this discussion would be more useful with actual specific profiles to talk about. ;)


Dave