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

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-aT299BYrlBKvZs0BOQ
>
>
>
> 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
>