Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

Hi,

My understanding is that the updated version should not introduce any
profile. Am I correct ?

BR,
Daniel

On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <daniel.migault@ericsson.com
> wrote:

> Hi,
>
> I am not very clear on how to update the text of the draft. The problem
> seems to me that code point restriction are hard to implement. As a result,
> the session is aborted with - insufficient_security(71) or equivalent -
> when the code point does not match the security strength. I am encline to
> think that we should also provide some profiles that achieve 128/256 bit
> security. These profiles may be described in this document or in another
> document more related to cryptographic recommendation. What would be the
> most appropriated way to move forward ?
>
> BR,
> Daniel
>
>
>
> On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson <john.mattsson@ericsson.com>
> wrote:
>
>> Hi Dan, Sean, Nikos,
>>
>> First, let me state that I think requiring 128-bit key management for
>> AES-128 is quite reasonable.
>>
>> HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
>> when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes
>> smaller than the lower limits as a connection error (Section 5.4.1
>> <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type
>> INADEQUATE_SECURITY."
>>
>>
>> I think this is a question for TLS in general,
>> draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
>> as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
>> with insufficient security as an error.
>>
>> I think the real problem here are TLS libraries supporting 1024 MODP and
>> 160 ECC at all, support for these should have been removed before 2010.
>> Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
>> (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
>> than bundling it into a code-point assignment RFC. (My current plans for
>> the next update of 3GPP’s TLS and DTLS profiles is simply to forbid
>> support of anything weaker than 2048 MODP and 255-bit ECC).
>>
>> [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrl
>> BKvZs0BOQ
>>
>>
>>
>> Cheers,
>> John
>>
>>
>> On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <tls-bounces@ietf.org
>> on
>> behalf of dharkins@lounge.org> wrote:
>>
>> >
>> >  I'm glad I have to opportunity to make you happy Sean :-)
>> >
>> >On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>> >> I think I can take this bit:
>> >>
>> >> On Jul 10, 2016, at 06:51, Peter Dettman
>> >><peter.dettman@bouncycastle.org>
>> >> wrote:
>> >>>
>> >>> I'm also curious whether there is a precedent in other RFCs for an
>> >>> explicit minimum curve bits, or perhaps a de facto implementer's rule?
>> >>
>> >> I'd be happy to be wrong here. but to my knowledge no there's not been
>> >> an explicit minimum for curve bits.  There have however been similar
>> (at
>> >> least in my non-cryptographer mind) for RSA key sizes so if we wanted
>> to
>> >> define an explicit minimum curve bits then we could.
>> >
>> >  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
>> >the curves used provide commensurate strength with the ciphersuite
>> >negotiated. Section 10, "Implementation Considerations", says:
>> >
>> >   It is RECOMMENDED that implementations take note of the strength
>> >   estimates of particular groups and to select a ciphersuite providing
>> >   commensurate security with its hash and encryption algorithms.  A
>> >   ciphersuite whose encryption algorithm has a keylength less than the
>> >   strength estimate, or whose hash algorithm has a blocksize that is
>> >   less than twice the strength estimate SHOULD NOT be used.
>> >
>> >  And I would like to take this opportunity to remind everyone that
>> >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
>> >to dictionary attack and the former is not.
>> >
>> >  regards,
>> >
>> >  Dan.
>> >
>> >
>> >
>> >_______________________________________________
>> >TLS mailing list
>> >TLS@ietf.org
>> >https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>