Subject: Re: [Uta] Brief summary of the UTA WG meeting @IETF 91, Honolulu

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Dec 2014 19:03:28 -0700

On 11/26/14, 2:55 AM, Alexey Melnikov wrote:
> Hi Peter,
>
> On 26 Nov 2014, at 03:38, Peter Saint-Andre - &yet <[email-masked]> wrote:
>
>>>> This document is not an application profile standard, in the sense of
>>>>     Section 9 of [RFC5246].  As a result, clients and servers are still
>>>>     REQUIRED to support the mandatory TLS cipher suite,
>>>>     TLS_RSA_WITH_AES_128_CBC_SHA.
>>>
>>> A BCP defining cipher suite recommendations should not have a higher
>>> level of requirement for TLS_RSA_WITH_AES_128_CBC_SHA than it has for
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, at least. I think it is OK to just
>>> say that the TLS specification was wrong to mandate
>>> TLS_RSA_WITH_AES_128_CBC_SHA, or don't mention it at all.
>>
>> I don't know if RFC 5246 was *wrong*, but the situation on the ground has changed since 2008.
>
> I was wondering about the above as well. I think your document is updating MTI or at least narrowing down recommended choices, and CBC_SHA is not one of them. So deleting the two sentences quoted above is the best.

And in fact the text currently says:

    This document is not an application profile standard, in the sense of
    Section 9 of [RFC5246].  As a result, clients and servers are still
    REQUIRED to support the mandatory TLS cipher suite,
    TLS_RSA_WITH_AES_128_CBC_SHA.

So I'd agree with Yaron here.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Dec 2014 19:12:07 -0700

On 11/26/14, 1:04 AM, Bodo Moeller wrote:
> Peter Saint-Andre - &yet <[email-masked] <mailto:[email-masked]>>:
>
>         Section 3.1.3 "Fallback to Lower Versions" is unclear: Does it apply
>         to the standard, "secure," type of version rollback that is
>         protected
>         by the TLS handshake, or does it apply to the non-secure
>         fallback that
>         the TLS_FALLBACK_SCSV is designed to protect.
>
>     Speaking only for myself, I don't think the authors differentiated
>     between *how* you might get to TLS 1.0 or SSLv3 - only that you end
>     up there at all.
>
>     In any case TLS_FALLBACK_SCSV is probably too new for us to
>     recommend it as a best *current* practice.
>
>
> Not that I'd necessarily disagree with that conclusion, but disabling
> SSL 3.0 entirely everywhere is much newer than the SCSV :-)
>
> You might want to consider a non-normative reference to the
> TLS_FALLBACK_SCSV draft (so that implementors will look at its current
> status).

Noted!

> My main complaint with the content of this section of
> draft-ietf-uta-tls-bcp-06, though, is that "fallback" should be spelt
> "fall back" when used as a verb. The one-word form ("fallback") is
> correct for the noun.

Good point, we'll correct that grammatical oversight.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 2 Dec 2014 11:00:08 +0000

Hi Peter/Yaron,

> On 2 Dec 2014, at 02:03, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 

IMHO, a distinction without a difference. Anybody complying with your spec will need to implement a larger set of ciphers, so you are effectively extending the MTI list.

Which reminds me of something else: some application protocols specify explicit MTI TLS ciphers, which are different from the above. So now that I thought about that, I really dislike the paragraph you quoted above. So maybe change it to something more neutral:

This document doesn't change mandatory-to-implement TLS cipher suite(s) prescribed by TLS and application protocols using TLS.

But I would rather drop the whole paragraph, as it weakens the whole document.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 02 Dec 2014 19:55:59 +0200

> But I would rather drop the whole paragraph, as it weakens the whole document.

I think we should be explicit about the cipher suite, even if we dislike 
it. So how about:

This document doesn't change mandatory-to-implement TLS cipher suite(s) 
prescribed by TLS and application protocols using TLS. To maximize 
interoperability, RFC 5246 REQUIRES implementation of the 
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly weaker 
than the cipher suites recommended here. Implementers should consider 
the interoperability gain against the loss in security when deploying 
this cipher suite. Other application protocols specify other cipher 
suites as mandatory to implement (MTI).

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 02 Dec 2014 17:25:47 -0700

On 12/2/14, 10:55 AM, Yaron Sheffer wrote:
>>>> I was wondering about the above as well. I think your document is
>>>> updating MTI or at least narrowing down recommended choices, and
>>>> CBC_SHA is not one of them. So deleting the two sentences quoted
>>>> above is the best.
>>>
>> IMHO, a distinction without a difference. Anybody complying with your
>> spec will need to implement a larger set of ciphers, so you are
>> effectively extending the MTI list.
>>
>> Which reminds me of something else: some application protocols specify
>> explicit MTI TLS ciphers, which are different from the above. So now
>> that I thought about that, I really dislike the paragraph you quoted
>> above. So maybe change it to something more neutral:
>>
>> This document doesn't change mandatory-to-implement TLS cipher
>> suite(s) prescribed by TLS and application protocols using TLS.
>>

WFM. I do think it's best to be explicit about the matter.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Brian Smith <[email-masked]>
Date: Tue, 2 Dec 2014 17:59:25 -0800

Peter Saint-Andre - &yet <[email-masked]> wrote:
> On 11/11/14, 9:10 PM, Brian Smith wrote:
>>>    o  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>>>
>>>    o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>
>>>    o  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>>>
>>>    o  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>
>> I generally agree with these recommendations, but I think it is
>> inappropriate to recommend that clients support
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 at this time.

> Do I understand correctly that you would recommend the ECDHE
> ciphers but not the DHE ciphers?
> Or would you recommend some other DHE ciphers?

Because of the various serious problems with DHE key agreement that
are mentioned in the draft (and some not even mentioned in the draft),
it doesn't make sense to recommend the TLS_DHE_* variants of the
AES-GCM cipher suites like the TLS_ECDHE_RSA_* variants are
recommended, or for them to be recommended more highly than the
TLS_ECDHE_ECDSA_* variants, which currently aren't recommended at all.

It is important for servers to support TLS_ECDHE_* (with ECDSA
certificates) to support Windows SChannel-based applications, because
Windows SChannel has a large marketshare (all of MSIE, MS Outlook,
etc.), and Windows SChannel does not support TLS_ECDHE_RSA_* until
Windows 10. Similarly, it is important for clients to implement them
due to the large marketshare of MS Exchange and IIS.

Further, my opinion is that clients SHOULD NOT enable TLS_DHE_* or
TLS_RSA_* cipher suites at all, unless they know they need to
interoperate with servers that only support those cipher suites. But,
if you are going to enable TLS_RSA_x, then you should also enable
TLS_DHE_RSA_x for all x, and clients should ensure that the server's
DHE key meets minimum security criteria that aren't currently defined
in the draft, and clients should probably implement a fallback
mechanism for when the server uses a DHE key that does not meet the
minimum security criteria.

> I don't know if RFC 5246 was *wrong*, but the situation on the ground has

Right. My point is that it is strange, for example, to have
TLS_RSA_WITH_AES_128_CBC_SHA be mandatory, while
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is only recommended, and when
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 isn't even recommended.

Cheers,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Dec 2014 07:34:55 +0000

Hi Brian,

I'm not seeing what part of your email is new and not
something already discussed by the WG. Can you clarify?

Thanks,
S.

On 03/12/14 01:59, Brian Smith wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Brian Smith <[email-masked]>
Date: Tue, 2 Dec 2014 23:38:33 -0800

> something already discussed by the WG. Can you clarify?

I answered the question that was asked of me.

Cheers,
Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 3 Dec 2014 10:34:21 +0000

Hi,

On 2 Dec 2014, at 17:55, Yaron Sheffer <[email-masked]> wrote:

> I think we should be explicit about the cipher suite, even if we dislike it. So how about:
> 
> This document doesn't change mandatory-to-implement TLS cipher suite(s) prescribed by TLS and application protocols using TLS. To maximize interoperability, RFC 5246 REQUIRES implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly weaker than the cipher suites recommended here. Implementers should consider the interoperability gain against the loss in security when deploying this cipher suite. Other application protocols specify other cipher suites as mandatory to implement (MTI).

This is much better, thank you!