Hi Peter/Yaron,

> On 2 Dec 2014, at 02:03, Peter Saint-Andre - &yet <[email protected]> wrote:
> 
>> On 11/26/14, 2:55 AM, Alexey Melnikov wrote:
>> Hi Peter,
>> 
>> On 26 Nov 2014, at 03:38, Peter Saint-Andre - &yet <[email protected]> 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.

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.

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to