On Monday, July 11, 2016 10:27:21 am Sean Turner wrote: > - Before 12 July, we’d like to know your thoughts about progressing > draft-ietf-tls-pwd (Watson and ekr responded): > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4
This document defines new cipher suites using obsolete crypto. Quoting https://tools.ietf.org/html/draft-ietf-tls-pwd-07#section-5 : > This memo adds the following ciphersuites: > > CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); > > CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); > > CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); > > Implementations conforming to this specification MUST support the > TLS_ECCPWD_WITH_AES_128_CBC_SHA ciphersuite; they SHOULD support > TLS_ECCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CCM_SHA, > TLS_ECCPWD_WITH_AES_128_GCM_SHA256, > TLS_ECCPWD_WITH_AES_256_GCM_SHA384; and MAY support the remaining > ciphersuites. Most of those should not be defined in any new document approved by this WG, let alone one based on a low entropy secret. In particular, the SHA1 suites shouldn't be there, and the CBC suites should be scrapped as well. The spec allows for these suites to be negotiated with TLS 1.0-1.1 (hence the CBC), which should just be dropped to focus on TLS 1.2 & TLS 1.3+. The MTI is not even supported by TLS 1.3. Don't define new crypto systems using obsolete crypto systems. I don't see how we could expect any implementations that don't even support TLS 1.2 to implement something new like this, anyway. If this draft moves forward in any way, it should be reduced to AES 128/256 GCM/CCM, with possible addition of a ChaCha/Poly suite. Quoting https://tools.ietf.org/html/draft-ietf-tls-pwd-07#section-1.1 : >1.1. The Case for Certificate-less Authentication > > TLS usually uses public key certificates for authentication > [RFC5246]. This is problematic in some cases: > > o Frequently, TLS [RFC5246] is used in devices owned, operated, and > provisioned by people who lack competency to properly use > certificates and merely want to establish a secure connection > using a more natural credential like a simple password. The > proliferation of deployments that use a self-signed server > certificate in TLS [RFC5246] followed by a PAP-style exchange over > the unauthenticated channel underscores this case. [...] If we're setting up new systems to lower the barrier to entry, ACME is the way to go, not this. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
