On 9/16/15, 4:19 , "TLS on behalf of Peter Gutmann" wrote:
>Jeffrey Walton 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 t
On Thursday 17 September 2015 03:27:22 Peter Gutmann wrote:
> Viktor Dukhovni 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"
Viktor Dukhovni 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 addit
On 9/16/15, Jeffrey Walton wrote:
> On Wed, Sep 16, 2015 at 4:45 AM, Stephen Farrell
> wrote:
>>
>>
>> On 16/09/15 09:19, Peter Gutmann wrote:
>>> Jeffrey Walton writes:
>>>
Somewhat off-topic, why does TLS not produce a few profiles. One can be
"Opportunistic TLS Profile" with a compa
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/
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
>> 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
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
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
> "defens
On Wed, Sep 16, 2015 at 02:10:36PM -0400, Dave Garrett wrote:
> > 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, n
On 16 September 2015 at 08:02, Peter Gutmann wrote:
>>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 anyth
Salz, Rich writes:
>> 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.
Some PKI stan
Stephen Farrell 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 BC
On 16/09/15 12:18, Peter Gutmann wrote:
> Stephen Farrell 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 p
> 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.
___
Stephen Farrell 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 n
> 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.
The security area has a hand in reviewing all of them, as p
On 16/09/15 09:19, Peter Gutmann wrote:
> Jeffrey Walton 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 exp
Jeffrey Walton 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, e
19 matches
Mail list logo
