Subject: [TLS] Reminders

From: Sean Turner <[email-masked]>
Date: Mon, 11 Jul 2016 10:27:21 -0400

Hi,

Just wanted to remind everybody that we’ve got two non-TLS1.3 items we’re looking for WG input on:

- 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

- Before 14 July, we’d like to know your thoughts on the proposed AUTH48 proposed changes (nobody has commented on this):
https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk

spt

---

From: Watson Ladd <[email-masked]>
Date: Mon, 11 Jul 2016 08:07:21 -0700

> https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk

I don't like the AUTH48 changes. I understand the need for changing to
MAY, but the proposed method of distinguishing offends my
sensibilities. Overloading the length field is just ugly.

>
> spt
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Jul 2016 08:34:22 -0700

I agree with Watson's assessment here. This seems like the wrong design
choice.

I'm not familiar with OpenSSL's cert selection, but I don't believe that
the issue
that this change is intended to address applies to NSS, for two reasons:

1. NSS does cert selection during client hello processing [0].
http://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#9569

2. Unless I misunderstand the design of cached-info, all the server needs
to have is the digest of the serialized chain and it could store that at
the time
that it configures the cert (or first uses it). This seems like quite a
small burden.

I believe the prior design was superior.

-Ekr

On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd <[email-masked]> wrote:

> > - Before 12 July, we’d like to know your thoughts about progressing
> draft-ietf-tls-pwd (Watson and ekr responded):
> > - Before 14 July, we’d like to know your thoughts on the proposed AUTH48
> proposed changes (nobody has commented on this):

---

From: David Benjamin <[email-masked]>
Date: Mon, 11 Jul 2016 16:16:44 +0000

OpenSSL determines which certificate to use during ClientHello processing,
but it has a mode where, if intermediates were not explicitly configured
and only a leaf, it path-builds right before sending the Certificate
message. But I don't see any reason why it can't be changed to compute this
earlier.

In general, we already require one know the certificate chain before
sending ServerHello. The cipher suite depends on the leaf key type, so that
must be selected already. If there are SCTs to deliver for any
intermediates, the server must know which intermediates will be sent. If
one wishes to consider intermediates' signature algorithms when selecting a
leaf, they must be known too.

If there are are other reasons we'd want to allow sending either hash or
contents (Caching a long-lived intermediate but sending a new short-lived
leaf? Looks like it's all-or-nothing right now. I dunno, I haven't been
paying attention to cached-info yet and assume this is well-trodden ground
by now.), the length still should not be a distinguisher. If needed,
negotiating the extension can tweak the syntax of Certificate message or
something.

David

On Mon, Jul 11, 2016 at 11:35 AM Eric Rescorla <[email-masked]> wrote:

>> > - Before 14 July, we’d like to know your thoughts on the proposed
>> AUTH48 proposed changes (nobody has commented on this):

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Jul 2016 11:22:42 -0500

I also don't like the AUTH48 changes -- there's no protocol-level reason
to weaken the MUST, since a server that can't handle the extra
state/processing can just not implement the extension at all.

-Ben

On 07/11/2016 10:34 AM, Eric Rescorla wrote:
> I agree with Watson's assessment here. This seems like the wrong
> design choice.
>
> I'm not familiar with OpenSSL's cert selection, but I don't believe
> that the issue
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__searchfox.org_mozilla-2Dcentral_source_security_nss_lib_ssl_ssl3con.c-239569&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=GGUhUgPsmo8P-zHms3do7kMl919w4Emye3THqWUMSgY&e=>
>
> to have is the digest of the serialized chain and it could store that
> at the time
> that it configures the cert (or first uses it). This seems like quite
> a small burden.
>
> On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Hi,
>     >
>     > - Before 12 July, we’d like to know your thoughts about
>     progressing draft-ietf-tls-pwd (Watson and ekr responded):
>     >
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_WrNa7PXTZn2ZhfmoQDA-5FpnUVuN4&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=ZzDtgI_TBc-Nia0FuETErOUeRUXahxu7BclcP8UXy7Q&e=>
>     >
>     > - Before 14 July, we’d like to know your thoughts on the
>     proposed AUTH48 proposed changes (nobody has commented on this):
>     >
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_aBvqMG7t8qkO5rPt-2DxaMHipuBVk&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=iGwvQ3uwrEzZ6N9yAb5yY5May3Sl2t1r2wy_HvSAhcg&e=>
>
>     > [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=4tEhM1I3VnCdJjY-hDncM9jWkxNdHLzpOzvwPBjikg8&e=>
>
>
>
>     --
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=4tEhM1I3VnCdJjY-hDncM9jWkxNdHLzpOzvwPBjikg8&e=>
>
>
>
>

---

From: Dave Garrett <[email-masked]>
Date: Mon, 11 Jul 2016 12:59:21 -0400

> 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

---

From: Anirudh Ramachandran <[email-masked]>
Date: Mon, 11 Jul 2016 22:27:52 +0000

On Mon, Jul 11, 2016 at 9:16 AM, David Benjamin <[email-masked]<mailto:[email-masked]>> wrote:

> OpenSSL determines which certificate to use during ClientHello processing, but it has a mode where, if intermediates were not explicitly configured and only a leaf, it path-builds right before sending the Certificate message. But I don't see any reason why it can't be changed to compute this earlier.

Correct, OpenSSL's late computation of the chain, plus other design decisions (one-state-at-a-time, same buffer for everything, etc) is the reason I proposed the change. Since the draft requires cached-info to be the hash of the serialized chain rather than individual certs, it does require the serialization code to be run outside of the usual state machine codepath, which is also cumbersome.

The MAY instead of MUST makes the server-side implementation almost plug-in - serialization happens as normal and the serialized message is replaced if it matches a cached-info. The client side implementation only slightly more complicated - check first for a length match and then a cached-info match (needed anyway); if either fail, the client treats the message as a normal certificate.

Having another way to indicate this besides length would suffice too, but I'm fine with not changing the draft either if that's what everyone feels.

--
Anirudh