From nobody Sat Nov 1 02:41:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E099E1A6F3C for ; Sat, 1 Nov 2014 02:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNjQbvMXzDpF for ; Sat, 1 Nov 2014 02:41:11 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1385B1A6EE7 for ; Sat, 1 Nov 2014 02:41:10 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA19f29B024838; Sat, 1 Nov 2014 05:41:03 -0400 Date: Sat, 1 Nov 2014 05:41:01 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Hugo Krawczyk Message-ID: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: OPTLS: Signature-less TLS 1.3 Thread-Index: xJgTdjMcmzr296usZXxmggcSP4UG7A== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VuV2NELMYq94eUXRngCe7CEfdXA Cc: tls@ietf.org, Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 09:41:13 -0000 ----- Original Message ----- > During the TLS interim meeting of last week (Oct 22 2014) I suggested that > TLS > 1.3 should abandon signature-based authentication (other than for > certificates) > and be based solely on a combination of ephemeral Diffie-Hellman for PFS and > static Diffie-Hellman for authentication. This has multiple benefits > including > major performance gain (by replacing the per-handshake RSA signature by the > server with a much cheaper elliptic curve exponentiation), compatibility > with > the mechanisms required for forward secrecy, natural accommodation of a > 0-RTT > option, and a simple extension without signatures for client authentication. That effectively deprecates all existing infrastructure used for TLS that pretty much only works with RSA and ECDSA certificates (from smart cards, to HSMs and acceleration hardware). That's not necessarily bad, and we may already be past the point where TLS 1.3 can be considered a minor revision of TLS 1.2. > PROTOCOL OPTLS: > > ClientHello > ClientKeyShare > ClientData* [K0] --------> > ServerHello > ServerKeyShare > ServerCertificate* [K1] > ServerFinished [K2] > <-------- ServerData* [K2] > ClientFinished* [K2] --------> > > > Protected Application Data [K3] > <-------> > 1-RTT CASE: > > The basic 1-RTT case omits the ClientData* field. It includes a > ClientKeyShare > g^x and a ServerKeyShare g^y and an optional (encrypted) server > certificate. > If the certificate is sent (it can be omitted if the client has indicated > that > it knows the server key as in the case in the 0-RTT scenario) and is > encrypted, > the encryption key K1 is derived from g^{xy}. > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used > to > authenticate-encrypt the ServerFinished and ClientFinished messages (which > include a hash of the previous traffic) and to encrypt data from the server > if > such data is piggybacked to the second message. How does the client get the DH (or ECDH) group parameters used by the server? > CLIENT AUTHENTICATION: > > Client authentication can be supported via an option or extension. It would > include a client certificate for a static DH key g^c sent in the third > message > (the certificate can be encrypted under key K2 to provide client's identity > protection). In this case, the key for computing the ClientFinished message > and > the application key K3 would be derived from a combination of the values > g^xy, > g^xs, g^yc (and possibly also g^{cs}). As I understand client authentication as above would only work if both the client and the server share the same DH/ECDH group for their certificates, and that cannot be assumed to be true on an infrastructure that is designed to upgrade (e.g., change client certs from secp192r1 to secp256r1). regards, Nikos From nobody Sat Nov 1 03:16:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900AD1A6FE3 for ; Sat, 1 Nov 2014 03:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv5NxBAeN0n2 for ; Sat, 1 Nov 2014 03:16:15 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E371A1A03 for ; Sat, 1 Nov 2014 03:16:14 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 878EA1887E2; Sat, 1 Nov 2014 12:16:11 +0200 (EET) Date: Sat, 1 Nov 2014 12:16:11 +0200 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20141101101611.GA25180@LK-Perkele-VII> References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/egrxTYlNLR1T0VLt1uuwyXel9RM Cc: Hoeteck Wee , tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 10:16:18 -0000 On Sat, Nov 01, 2014 at 05:41:01AM -0400, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > During the TLS interim meeting of last week (Oct 22 2014) I suggested that > > TLS > > 1.3 should abandon signature-based authentication (other than for > > certificates) > > and be based solely on a combination of ephemeral Diffie-Hellman for PFS and > > static Diffie-Hellman for authentication. This has multiple benefits > > including > > major performance gain (by replacing the per-handshake RSA signature by the > > server with a much cheaper elliptic curve exponentiation), compatibility > > with > > the mechanisms required for forward secrecy, natural accommodation of a > > 0-RTT > > option, and a simple extension without signatures for client authentication. > > That effectively deprecates all existing infrastructure used for TLS that pretty > much only works with RSA and ECDSA certificates (from smart cards, to HSMs and > acceleration hardware). That's not necessarily bad, and we may already be past the > point where TLS 1.3 can be considered a minor revision of TLS 1.2. The only reason it is called TLS 1.3 ("SSL 3.4") is because we can't use TLS 2.0 designation ("SSL 4.0") on wire because of compatiblity reasons. :-> Regarding the most basic ways to secure long-term private keys (but most servers don't do even that[1]), those are based on software that is rather easily upgraded. [1] Those would have easily stopped dumping of private keys via Heartbleed. > > PROTOCOL OPTLS: > > > > ClientHello > > ClientKeyShare > > ClientData* [K0] --------> > > ServerHello > > ServerKeyShare > > ServerCertificate* [K1] > > ServerFinished [K2] > > <-------- ServerData* [K2] > > ClientFinished* [K2] --------> > > > > > > Protected Application Data [K3] > > <-------> > > 1-RTT CASE: > > > > The basic 1-RTT case omits the ClientData* field. It includes a > > ClientKeyShare > > g^x and a ServerKeyShare g^y and an optional (encrypted) server > > certificate. > > If the certificate is sent (it can be omitted if the client has indicated > > that > > it knows the server key as in the case in the 0-RTT scenario) and is > > encrypted, > > the encryption key K1 is derived from g^{xy}. > > > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used > > to > > authenticate-encrypt the ServerFinished and ClientFinished messages (which > > include a hash of the previous traffic) and to encrypt data from the server > > if > > such data is piggybacked to the second message. > > How does the client get the DH (or ECDH) group parameters used by the server? Presumably from ServerHello (with CKS being optimistic). But the case where client misses all its guesses needs to be handled. > > CLIENT AUTHENTICATION: > > > > Client authentication can be supported via an option or extension. It would > > include a client certificate for a static DH key g^c sent in the third > > message > > (the certificate can be encrypted under key K2 to provide client's identity > > protection). In this case, the key for computing the ClientFinished message > > and > > the application key K3 would be derived from a combination of the values > > g^xy, > > g^xs, g^yc (and possibly also g^{cs}). > > As I understand client authentication as above would only work if both the client > and the server share the same DH/ECDH group for their certificates, and that cannot > be assumed to be true on an infrastructure that is designed to upgrade (e.g., change > client certs from secp192r1 to secp256r1). >From what I quickly read, the idea was to issue the parameters off EE certificates, so that getting appropriate group is little problem. However, this poses some challenges with respect to revocation. From what I understand, the parameters are intended to have limited lifetime (much shorter than EE certificates). The reason this is problematic is that one can't really rely on clocks: - Even if you happen to have sub-second accurate clock, a lot of computers don't. - The time protocols often aren't secured, allowing attacker to play tricks with endpoint time. -Ilari From nobody Sat Nov 1 07:47:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51EC1A88BF for ; Sat, 1 Nov 2014 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYi3-LMfYjbg for ; Sat, 1 Nov 2014 07:47:08 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAC41A88BB for ; Sat, 1 Nov 2014 07:47:08 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so3352958wiv.13 for ; Sat, 01 Nov 2014 07:47:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b7uptotVOAMupm8Vj9ecSF/ECRR4xYEIohJLZ9wD570=; b=V6criqM2DkEbyuvuy7MGrGNpR7fIVWN33oAkP+sr/Y93fXfpkiDWESg80PnfQc4WVx 3A4+11b8cdlay8xUhuJ5e2Gb/BegHvGxvc3hfJtFf+Nq0tVeY9vdV1DX9NY9V3CT9BXC bMDLFQiq3Wh9CKWN8GnxhvTlBZA11sLrnh09Rz4zXP216MPJMpjXMUeCR3akmX8VQMEE JdQzGEeeuRdEZRxgNt1d/rLEh/siBw27W8H9IMJ01CkZLEd9Xxo1ytbIHa1Z42kEDKFb QR9ar1X2ExCsBojBwe2OuNbBLAKk8ceKnfeyyhWaZPxGhTWVjx8vEylrm/ZYgKBSB/f8 sWnw== X-Gm-Message-State: ALoCoQnUHN8YMf43YR9UOQIVhL+XJenfp1sAepIKdcSovQlv00LA+Br8+Pk7IMLvYU+fsuyVJhDH X-Received: by 10.194.206.106 with SMTP id ln10mr35274293wjc.90.1414853226875; Sat, 01 Nov 2014 07:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Sat, 1 Nov 2014 07:46:26 -0700 (PDT) In-Reply-To: <20141101101611.GA25180@LK-Perkele-VII> References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 1 Nov 2014 07:46:26 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b874afeff641f0506cd2f64 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IRuTUVRiUJgxPd2z0HzrsjgFXv8 Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 14:47:11 -0000 --047d7b874afeff641f0506cd2f64 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara wrote: > > > > PROTOCOL OPTLS: > > > > > > ClientHello > > > ClientKeyShare > > > ClientData* [K0] --------> > > > ServerHello > > > ServerKeyShare > > > ServerCertificate* [K1] > > > ServerFinished [K2] > > > <-------- ServerData* [K2] > > > ClientFinished* [K2] --------> > > > > > > > > > Protected Application Data [K3] > > > <-------> > > > 1-RTT CASE: > > > > > > The basic 1-RTT case omits the ClientData* field. It includes a > > > ClientKeyShare > > > g^x and a ServerKeyShare g^y and an optional (encrypted) server > > > certificate. > > > If the certificate is sent (it can be omitted if the client has > indicated > > > that > > > it knows the server key as in the case in the 0-RTT scenario) and is > > > encrypted, > > > the encryption key K1 is derived from g^{xy}. > > > > > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is > used > > > to > > > authenticate-encrypt the ServerFinished and ClientFinished messages > (which > > > include a hash of the previous traffic) and to encrypt data from the > server > > > if > > > such data is piggybacked to the second message. > > > > How does the client get the DH (or ECDH) group parameters used by the > server? > > Presumably from ServerHello (with CKS being optimistic). > > But the case where client misses all its guesses needs to be handled. Unless I'm missing something, this can be handled the way that we currently handle missed guesses, I.e., by having a HelloRetryRequest followed by a new ClientHello/ClientKeyShare. Though of course the server does need to either keep their RSA private key online or periodically generate new signed DH shares for every group. > However, this poses some challenges with respect to revocation. From what I > understand, the parameters are intended to have limited lifetime (much > shorter than EE certificates). > > The reason this is problematic is that one can't really rely on clocks: > - Even if you happen to have sub-second accurate clock, a lot of computers > don't. > - The time protocols often aren't secured, allowing attacker to play tricks > with endpoint time. We're already starting to have that problem because of a desire to move to OCSP stapling, which, with staple, effectively gives the server a credential which is valid only within a fairly narrow window. However, I think you're right that this probably limits the range of lifetimes you can use with these signed DH keys. -Ekr --047d7b874afeff641f0506cd2f64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara <ilari.liusvaara= @elisanet.fi> wrote:
> > PROTOCOL OPTLS:
> >
> > ClientHello
> > ClientKeyShare
> > ClientData* [K0]=C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ServerHello
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ServerKeyShare
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ServerCertificate* [K1]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ServerFinished [K2]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Serv= erData* [K2]
> > ClientFinished* [K2]=C2=A0 =C2=A0-------->
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Applicat= ion Data [K3]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <------->
> > 1-RTT CASE:
> >
> > The basic 1-RTT case omits the ClientData* field. It includes a > > ClientKeyShare
> > g^x and a ServerKeyShare g^y and an optional (encrypted) server > > certificate.
> > If the certificate is sent (it can be omitted if the client has i= ndicated
> > that
> > it knows the server key as in the case in the 0-RTT scenario) and= is
> > encrypted,
> > the encryption key K1 is derived from g^{xy}.
> >
> > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. = It is used
> > to
> > authenticate-encrypt the ServerFinished and ClientFinished messag= es (which
> > include a hash of the previous traffic) and to encrypt data from = the server
> > if
> > such data is piggybacked to the second message.
>
> How does the client get the DH (or ECDH) group parameters used by the = server?

Presumably from ServerHello (with CKS being optimistic).

But the case where client misses all its guesses needs to be handled.

Unless I'm missing something, this can be ha= ndled the way that we
currently handle missed guesses, I.e., by h= aving a HelloRetryRequest
followed by a new ClientHello/ClientKey= Share. Though of course
the server does need to either keep their= RSA private key online
or periodically generate new signed DH sh= ares for every group.

=C2=A0
However, this poses some challenges with respect to revocation. From what I=
understand, the parameters are intended to have limited lifetime (much
shorter than EE certificates).

The reason this is problematic is that one can't really rely on clocks:=
- Even if you happen to have sub-second accurate clock, a lot of computers = don't.
- The time protocols often aren't secured, allowing attacker to play tr= icks
=C2=A0 with endpoint time.

We're alread= y starting to have that problem because of a desire to move to OCSP
stapling, which, with staple, effectively gives the server a credential = which is
valid only within a fairly narrow window. However, I thi= nk you're right that this
probably limits the range of lifeti= mes you can use with these signed DH keys.

-Ekr

--047d7b874afeff641f0506cd2f64-- From nobody Sat Nov 1 08:32:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673111A8909 for ; Sat, 1 Nov 2014 08:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAAORmh5FTax for ; Sat, 1 Nov 2014 08:31:59 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id F15661A8904 for ; Sat, 1 Nov 2014 08:31:58 -0700 (PDT) Received: (qmail 19222 invoked by uid 0); 1 Nov 2014 15:31:57 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 1 Nov 2014 15:31:57 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id AFXt1p00B2UhLwi01FXwar; Sat, 01 Nov 2014 09:31:56 -0600 X-Authority-Analysis: v=2.1 cv=W5+rC3mk c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=Fwsyk3WOAnQA:10 a=VJFHFPW5AAAA:8 a=48vgC7mUAAAA:8 a=qT6fSrqGr1XRdP9SFXUA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=t7IUYxZS3hUF5eXsqCUMlMN5q0qj2mx3sU62ip40XKg=; b=4ToPlhnLp1hcYSTLtKWX3kXTSLa9l+DdUDKp8JAWU31DsndutakVy0nlTa7AawQ6+3o3eaxoa2TijGjetUbc7+COgAOgIn+fV+/ol+8zVgzovDowW33NC0Ra3bRv2bAf; Received: from [24.5.2.144] (port=50691 helo=[192.168.11.19]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xkaeg-00072s-1r for tls@ietf.org; Sat, 01 Nov 2014 09:31:54 -0600 Message-ID: <5454FCE6.4000805@KingsMountain.com> Date: Sat, 01 Nov 2014 08:31:50 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.5.2.144 authed with jeff.hodges+kingsmountain.com} Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KKtAcMHDKAk0r5_1FqgkbiheiPw Subject: [TLS] wrt deprecating SSL (draft-turner-ssl-must-not-01) (was: Prohibiting SSL 3.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 15:32:00 -0000 Joseph Salowey > > SSL 3.0 is historic, but if but if someone wants to write a draft > prohibiting SSL 3.0 the working group can consider adopting it. Your co-chair (Sean plus Tim Polk) did so a while back.. Prohibiting SSL Version 3.0 and Earlier https://tools.ietf.org/html/draft-turner-ssl-must-not-01 8^) Offhand, seems to me that the working group could either resurrect draft-turner-ssl-must-not-01 with intention to obsolete RFC6176, or update the latter I-D to be SSLv3-specific with intention to update RFC6176. either way, then the BCP I-D could appropriately reference the outcome of the above decision. HTH, =JeffH From nobody Sat Nov 1 10:13:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710291A89E1 for ; Sat, 1 Nov 2014 10:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KRh0U2MCz4x for ; Sat, 1 Nov 2014 10:13:22 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45371A01A9 for ; Sat, 1 Nov 2014 10:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=kjVPSwlikin9eLRBprVV2di/8FilHWOp5xgXB+OkulA=; b=VmxEf1fyqN3h57dPc/3/gUzmjyiPJeD2hRgShEs+TscvamaFkdJ73db1uXT5O3osQrHXILnXnWCoictXQg2gB34p8ghcC9VkaP9w8/sfVTQyUULFRg9EbWHa0afIV6H+KOp55BQ6hR3vxch6AvlktK1t5qcc1FOjjZGQIJK491g=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XkcEj-0006bc-RE; Sat, 01 Nov 2014 18:13:14 +0100 Message-ID: <545514AE.9080100@polarssl.org> Date: Sat, 01 Nov 2014 18:13:18 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mrex@sap.com, Bodo Moeller References: <20141031012622.2D0721AF6E@ld9781.wdf.sap.corp> In-Reply-To: <20141031012622.2D0721AF6E@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xgreWcrSW2oeI2_3tPblmBd1mU4 Cc: "tls@ietf.org" Subject: Re: [TLS] Minutes from Tuesday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 17:13:24 -0000 On 31/10/2014 02:26, Martin Rex wrote: > Bodo Moeller wrote: >> I just don't think that the additional benefit (per connection) >> is worth the additional computational effort (per connection), and the >> extra latency: for many clients, there is *no* additional benefit at all. > > There is a *HUGE* benefit for clients. They will be able to properly > recognize accidental fallbacks that should not have happened in the > first place. Otherwise it takes bug reports and several years before > client connection management failures get fixed. > It seems to me the current draft allows that too, so I don't see how your proposal provides additional value compare to the draft on this exact point. (I agree it does provide value compared to current situation, obviously). >> clients will require additional code to handle this properly, >> whereas reacting to a fatal alert is something that all TLS >> implementations already know how to do. > > That reaction is called interop failure. That is the far opposite > of what IETF working groups are supposed to consciously cause to happen > when the alternative would be to make interop succeed. > I'm not so sure. There are already a lot of situations where implementations are requires to make the handshake fail, eg if the verify data from the Finished message don't match, which indicates the handshake data has been tampered with. This is not entirely different, the main difference is that the suspected tampering happened during the previous handshake. I'm not saying breaking the handshake is the only right thing to do, I can see the benefits of the solution you suggest, but I think the simplicity of the current draft is a big advantage in getting it widely (and correctly) deployed sooner rather than later, which IMO outweighs the advantages of a more complex approach. Manuel. From nobody Sat Nov 1 10:14:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF831A8A06 for ; Sat, 1 Nov 2014 10:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpGbaE4qMcJl for ; Sat, 1 Nov 2014 10:14:00 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727FB1A8A04 for ; Sat, 1 Nov 2014 10:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=tZORqQyW34bSGdH0KeOHCJu78vFt9PXTCavnr3KFLAI=; b=TruFoEr6U6NxjqGgwLVTIS87iqN8d9Zd5RknjB9c7CZq3hxYCQPM/VNpo3sO9d/S6SPIa7jCXN92qHiS59FTyY76Oryy7Vr/md0abyIuJsEvjyvjFfsOUJoclfVq9W/fctyEAzjIF8Lo7JOYglfFH7Ijh3QfErFSy7Jl5g+hw9s=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XkcFM-0006bx-28; Sat, 01 Nov 2014 18:13:52 +0100 Message-ID: <545514D4.6010900@polarssl.org> Date: Sat, 01 Nov 2014 18:13:56 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C739B9DC255@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DC255@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dVNIcjOXoE4BNPPV4um9TMeSzSU Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 17:14:01 -0000 On 30/10/2014 17:17, Peter Gutmann wrote: > My > concern is that adding a complex technical definition, while very precise, may > then require another erratum later on to explain it. > Yes, I agree. This was more an experimental thing: "let's see how it looks if we try to introduce a complete formal definition". Not suited for an erratum indeed. > If anyone can come up with a clear one-paragraph note (which, when posted to > the list, no-one complains about :-), I'd be happy to use that. > I didn't see people complain about your text here [1], nor about my fixed text here [2] so far :) [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs Manuel. From nobody Sat Nov 1 10:21:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2358B1A8A0C for ; Sat, 1 Nov 2014 10:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRNc8C-TpuOL for ; Sat, 1 Nov 2014 10:21:25 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A058A1A89EF for ; Sat, 1 Nov 2014 10:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=YicEfaddijpJXGqmM2iq/4SFt6yRsj7y2R98n2P+l7k=; b=jTO8aCaxGyPLyvQ+mWlhsrYDZdBL5Uu5uVdmW17sKZ9IFUbVn2vQnfjSj5oBqF453MB98F5EpnXN3LL4pKnI992GrXEJrQv0LrU9hzqI9XrH4WXWUo/UDivI1/tnN8o3gBKg06MgZs20F18R89YvSqx8Rzz/lZ7921aU+3amhMw=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XkcMX-0006cd-PD; Sat, 01 Nov 2014 18:21:18 +0100 Message-ID: <54551692.2070905@polarssl.org> Date: Sat, 01 Nov 2014 18:21:22 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ilari Liusvaara , Eric Rescorla References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org> <20141031183146.GA12592@LK-Perkele-VII> In-Reply-To: <20141031183146.GA12592@LK-Perkele-VII> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8QBxHjVjsOsz89r0b0kJgxubhmU Cc: "tls@ietf.org" Subject: Re: [TLS] Should we require compressed points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 17:21:27 -0000 On 31/10/2014 19:31, Ilari Liusvaara wrote: > On Fri, Oct 31, 2014 at 10:34:52AM -0700, Eric Rescorla wrote: >> This discussion seems to be settling, so I've prepared a pull request >> that implements Bodo's suggestion: >> >> https://github.com/tlswg/tls13-spec/pull/86 > > I think 8.1.2 (ECDHE premaster secret calculation) should be modified > as well, to specify using the fixed wire encoding of selected group for > premaster secret. > Just to be clear: this would change the way the PMS is computed for the existing curves, right? I'm not opposed to it, I just want to make sure we're on the same line. > This is to avoid problems with more "odd" encodings. > I think this is indeed a very desirable outcome, that is achieved by your proposal. > Note that 8.1.1 does not quite match that beheviour, since it specifes > leading zero octets to be stripped (whereas DHE "element" encoding > doesn't seem to specify if zeroes are stripped or not) > I think it makes sense to accept non-canonical representation of DHE elements as long as it's not ambiguous (be liberal in what you accept), while for the PMS it's necessary to be strict in order to ensure interop. But I wouldn't be oppose to something like "DHE elemens MUST be encoded without leading zeroes, but implementations MAY accept leading zeroes in their encoding". Manuel. From nobody Sat Nov 1 10:36:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2958E1A002C for ; Sat, 1 Nov 2014 10:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OfMUfoSSJHt for ; Sat, 1 Nov 2014 10:36:36 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35581A0006 for ; Sat, 1 Nov 2014 10:36:35 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x12so7906316wgg.3 for ; Sat, 01 Nov 2014 10:36:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=APdNSetd8s5BgSh6W0WUFExP26MzKgC58Audh3NXam8=; b=UL4pHfwkSFjDMYcm/6weD7GUmp5/TDP1Zq4uuUXOhxBr1J2QqKlGEDCPJp+vJ4TNyi tp01urkCT9crApVM1zeZiVACYJ6zJtzHnbMavOmkzANdOG/Ar3dJa1Eg/1AWCwq79qSi NLCj8VcrRNokqFcsKGEjaxN8o5Vd2LASwg3h+5kuFA128In/t1iziJl15A6zoF90Vt+p HSSiDb+sdO5kk2uaOd8xvyTfU7AevLZX9u8F+TJz1SZD30suy7snRgCG2h5S7kpeAL5a 1wzLY7WDzWgTWXhAJiULlkWqY3fZVoPr7NG7N70f366n5afDOxeCuR8HE7yldgxJDJ64 BUCQ== X-Gm-Message-State: ALoCoQkmdko/e2Yti2jye36yKnYCZoSpRXbKrpCeSTI0FZL7S7dg1F0S17/Us9AljveAiBb4Dv6G X-Received: by 10.194.236.232 with SMTP id ux8mr36673166wjc.96.1414863394431; Sat, 01 Nov 2014 10:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Sat, 1 Nov 2014 10:35:54 -0700 (PDT) In-Reply-To: <20141031183146.GA12592@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org> <20141031183146.GA12592@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 1 Nov 2014 10:35:54 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e01493f5808049a0506cf8e59 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7eLkC5m9WO3jGx8PVwyznuMx_nk Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] Should we require compressed points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 17:36:38 -0000 --089e01493f5808049a0506cf8e59 Content-Type: text/plain; charset=UTF-8 Can you send a Pull Request with what you are looking for here? Thanks, -Ekr On Fri, Oct 31, 2014 at 11:31 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Fri, Oct 31, 2014 at 10:34:52AM -0700, Eric Rescorla wrote: > > This discussion seems to be settling, so I've prepared a pull request > > that implements Bodo's suggestion: > > > > https://github.com/tlswg/tls13-spec/pull/86 > > I think 8.1.2 (ECDHE premaster secret calculation) should be modified > as well, to specify using the fixed wire encoding of selected group for > premaster secret. > > This is to avoid problems with more "odd" encodings. > > > Note that 8.1.1 does not quite match that beheviour, since it specifes > leading zero octets to be stripped (whereas DHE "element" encoding > doesn't seem to specify if zeroes are stripped or not) > > > -Ilari > --089e01493f5808049a0506cf8e59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you send a Pull Request with what you are looking for = here?

Thanks,
-Ekr

<= div class=3D"gmail_extra">
On Fri, Oct 31, 20= 14 at 11:31 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi= > wrote:
On Fr= i, Oct 31, 2014 at 10:34:52AM -0700, Eric Rescorla wrote:
> This discussion seems to be settling, so I've prepared a pull requ= est
> that implements Bodo's suggestion:
>
> https://github.com/tlswg/tls13-spec/pull/86

I think 8.1.2 (ECDHE premaster secret calculation) should be modifie= d
as well, to specify using the fixed wire encoding of selected group for
premaster secret.

This is to avoid problems with more "odd" encodings.


Note that 8.1.1 does not quite match that beheviour, since it specifes
leading zero octets to be stripped (whereas DHE "element" encodin= g
doesn't seem to specify if zeroes are stripped or not)


-Ilari

--089e01493f5808049a0506cf8e59-- From nobody Sat Nov 1 11:23:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605361A0049 for ; Sat, 1 Nov 2014 11:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYvsl4ZOSB4h for ; Sat, 1 Nov 2014 11:23:49 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA621A0030 for ; Sat, 1 Nov 2014 11:23:48 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id f51so7052073qge.16 for ; Sat, 01 Nov 2014 11:23:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uPdKabZFuyfFgDk96zXE7msmsjOC/0G4xXtAd1+Emo0=; b=X9cz1RcZcIOdDBbCbsqYtqObknNglKhD6zUcJr/v6zZx1b3NOzt1RSR8Ptr+Q5lmv0 LrglTTTAg/tKzbp/guTo0Ml83JlWL3B2cyAlkrm9e2VjQUp3rLcKiRiZF7sHKNazC7it M5Ni/895NyUKfAz9zKUFnqjmHdBrPJDQYGTLNRHOWSwMTPAkACQlbSw9l/BA6Z0xSVHx 0cmSnmylWFLNI9NV58d9CEUwX8E5/1qtBNGisp8uKMzLuGdHrEscPVcyb8aDxsZtR5gQ 4jN+i4TGu9lhDSRqwnPw9fqEHTLRLnAzL4C3txXzS3nPpTiTF9SY1O83RshVTldQG62W ObZA== X-Gm-Message-State: ALoCoQmdtbQakTcfa04/fOvjzt7QdJF/hGTZ+ELvtn9EVqTcD3sd15WTFl2pQyvP/kQnvE/wnvPU X-Received: by 10.224.28.193 with SMTP id n1mr19524228qac.93.1414866227652; Sat, 01 Nov 2014 11:23:47 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:e7:84b1:781c:6435:fe31? ([2601:a:2a00:e7:84b1:781c:6435:fe31]) by mx.google.com with ESMTPSA id g14sm12603170qar.46.2014.11.01.11.23.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Nov 2014 11:23:47 -0700 (PDT) Message-ID: <54552558.2030209@nthpermutation.com> Date: Sat, 01 Nov 2014 14:24:24 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org> <20141031183146.GA12592@LK-Perkele-VII> <54551692.2070905@polarssl.org> In-Reply-To: <54551692.2070905@polarssl.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pmug6nT0bIJMPopsQNNPyBiAHHA Subject: Re: [TLS] Should we require compressed points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 18:23:51 -0000 Below - inline. On 11/1/2014 1:21 PM, Manuel Pégourié-Gonnard wrote: > On 31/10/2014 19:31, Ilari Liusvaara wrote: >> On Fri, Oct 31, 2014 at 10:34:52AM -0700, Eric Rescorla wrote: >>> This discussion seems to be settling, so I've prepared a pull request >>> that implements Bodo's suggestion: >>> >>> https://github.com/tlswg/tls13-spec/pull/86 >> >> I think 8.1.2 (ECDHE premaster secret calculation) should be modified >> as well, to specify using the fixed wire encoding of selected group for >> premaster secret. >> > Just to be clear: this would change the way the PMS is computed for the existing > curves, right? I'm not opposed to it, I just want to make sure we're on the same > line. > >> This is to avoid problems with more "odd" encodings. >> > I think this is indeed a very desirable outcome, that is achieved by your proposal. > >> Note that 8.1.1 does not quite match that beheviour, since it specifes >> leading zero octets to be stripped (whereas DHE "element" encoding >> doesn't seem to specify if zeroes are stripped or not) >> > I think it makes sense to accept non-canonical representation of DHE elements as > long as it's not ambiguous (be liberal in what you accept), while for the PMS > it's necessary to be strict in order to ensure interop. But I wouldn't be oppose > to something like "DHE elemens MUST be encoded without leading zeroes, but > implementations MAY accept leading zeroes in their encoding". Sorry - this won't work. This (8.1.2) is about taking the derived shared secret and representing it as a byte string for input into a key derivation function (the TLS PRF for 1.2 basically). For example, the bignum value '1' can be represented as 01, as 00 00 00 01 or with any number of leading bytes. But KDF ({01}) gives you a different result than KDF ({00 00 00 01}) etc. In X9.42, X9.62 and in the NIST version of DH/ECDH, the bignum result of the ECDH operation is translated to a byte string via an "Integer to Octet String" conversion. In all of these, the length of the octet string is fixed to match the order of one of the parameters, is big endian, and is not variable in length (e.g. the leading 00 bytes are not truncated). TLS - for I'm sure what must have been good reasons at the time - decided to do it differently for DH (by truncating leading 0 bytes). However, TLS ECDH matches the guidances in X9.62 and in SP800-56A which preserves leading zeros and has a fixed shared secret length based on the curve parameters. (RFC4492, section 5.10). The point of the above is that the conversion from the bignum shared secret to the octet string used as the premaster secret prior to being input into the key derivation function needs to be of a well-known length for any given parameter set so MUST is a "MUST" for DH. Ideally, I'd really like to be able to use standard libraries rather than TLS specific ones, so I'd rather have the following going forward: "If TLS1.3 or later is negotiated, DHE octet strings representing derived shared secrets MUST be encoded according X9.42 7.6.3 and NIST SP800-56A C.1 and leading 0 octets to the required length (= CEIL(t/8) where t = log2(p) where p is the large prime field order) MUST be preserved; otherwise for TLS1.2 and before, those octet strings MUST be encoded without leading 0 octets." Note that I'm not adamant about the above - I expect that plain DH will begin to go away due to the relative benefits of ECDH, so negotiating an ECDH shared secret allows for the use of normal libraries. But whatever the choice it needs to be a MUST. Mike > > Manuel. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Nov 1 12:25:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124001A0396 for ; Sat, 1 Nov 2014 12:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YndZJ-p3E_z for ; Sat, 1 Nov 2014 12:25:47 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2274B1A0390 for ; Sat, 1 Nov 2014 12:25:46 -0700 (PDT) Received: from 151.170.251.212.customer.cdi.no ([212.251.170.151]:52511 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XkeIy-0002G7-Sv for tls@ietf.org; Sat, 01 Nov 2014 20:25:44 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> Date: Sat, 01 Nov 2014 20:25:32 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Opera Mail/12.17 (Win32) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KVtX4BW67fZeIYnatUYS1mVKFtc Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 19:25:50 -0000 Hi, Warning, long post. For reference, I have tried to implement RFC 7366 in my TLS Prober, but = I = have not been able to establish a connection with the "eid" server. It = seems to have some non-standard requirements to the client that AFAICT = have not been documented anywhere. On Wed, 29 Oct 2014 15:38:41 +0100, Peter Gutmann = wrote: > Manuel P=E9gouri=E9-Gonnard writes: > >> What I'm doing to get this is interpret TLSCipherText.length exactly = as = >> it is >> defined in RFC 5246 (6.2.3.2, page 22): >> >> The encrypted data length (TLSCiphertext.length) is one more than t= he >> sum of SecurityParameters.block_length, TLSCompressed.length, >> SecurityParameters.mac_length, and padding_length. >> >> Apparently to interoperate with the implementation at eid.vx4.net (an= d = >> with >> OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding >> SecurityParameters.mac_length. I couldn't find this explicitly stated= >> anywhere. > > Section 3 of RFC 7366 says: > > In [2] notation the overall packet is then: > > struct { > ContentType type; > ProtocolVersion version; > uint16 length; > GenericStream/BlockCipher fragment; > opaque MAC; > } TLSCiphertext; > > This is identical to the existing TLS layout with the only differen= ce > being that the MAC value is moved outside the encrypted data. I am starting to wonder if the confusion about this spec update is partl= y = due to the way the record structure is defined, with the length separate= = from the data vectors. This separation have been a problem in connectio= n = with at least some extensions. The way a TLS Protocol record is defined in previous versions (Using TLS= = 1.2), before this update is, can a generic way be rewritten as: struct { ContentType type; ProtocolVersion version; opaque record_data<0..maxlength> } TLS_Record; This is how all clients and servers will parse current SSL and TLS = versions' records on the wire, and also how all the intermediate servers= = (the ones that are causing concern for version rollback recovery) will b= e = parsing the TLS traffic. The field record_data containing a strucure of exactly the length of = record_data struct { select(encryption_mode) { case plaintext: TLS_Plaintext_data; case stream_encrypted: TLS_Stream_Encrypted_data; case block_encrypted: TLS_Block_Encrypted_data; } } TLS_Record_payload; struct { opaque plaintext[TLS_Record.record_data.length]; } TLS_Plaintext_data; stream-ciphered struct { opaque [TLS_Record.record_data.length-MAClength]; opaque MAC[MAClength]; } TLS_Stream_Encrypted_data; struct { opaque IV[SecurityParameters.record_iv_length]; block_encrypted_stream struct { opaque = [TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-p= addinglength-1]; opaque MAC[MAClength]; uint8 padding [paddinglength]; uint8 paddinglength; } encrypted; } TLS_Block_Encrypted_data; With RFC7366 the format for the encrypted record payloads got changes, a= nd = it seems to me that the problem is a disagreement of what the length fie= ld = in the TLSCipherText record applies to. In the following I will assume that we (the TLS WG) while implementing = peers that understand the Encrypt then MAC record format, also wants to = = Maintain backwards compatibility with all existing infrastructure (such = as = firewalls) that processes the TLS ciphertext records, but which do not = know about RFC 7366. Given these requirment, I think the TLS_Record_payload structure have to= = be redefined as struct { select(encryption_mode) { case plaintext: TLS_Plaintext_data; case stream_encrypted: TLS_EtM_Stream_Encrypted_data; case block_encrypted: TLS_EtM_Block_Encrypted_data; } } TLS_Record_payload; struct { stream-ciphered opaque = fragment[TLS_Record.record_data.length-MAClength]; opaque MAC[MAClength] } TLS_EtM_Stream_Encrypted_data; struct { opaque IV[SecurityParameters.record_iv_length]; block-ciphered struct { opaque = fragment[TLS_Record.record_data.length-SecurityParameters.record_iv_leng= th-MAC-paddinglength-1]; uint8 padding [paddinglength]; uint8 paddinglength; } encrypted; opaque MAC[MAClength]; } TLS_EtM_Block_Encrypted_data; I think one thing that is to be determined is whether this rewritten = structure definitions accurately describes both the old format and the n= ew = RFC 7366 format. Do they? If RFC 7366 means to say that the MAC field is no longer part of the = record_data field (and not counted in the length field), then that is = going to cause trouble, because processors that are not aware of the = extension will then read the first bytes of the MAX as the ContentType = field and the version field, probably resulting in a connection closure.= The second issue that seems to have developed is which value to use as t= he = length part of the MAC calculation. RFC 7366 version: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + TLSCipherText.length + IV + ENC(content + padding + padding_length)); Adapted to my rewritten structure the question is if the MAC (for block = = cipher encryption) is calculated as MAC(MAC_write_key, seq_num + TLS_Record.type + TLS_Record.version + TLS_Record.record_data.length + IV + ENC(content + padding + padding_length)); or MAC(MAC_write_key, seq_num + TLS_Record.type + TLS_Record.version + TLS_EtM_Block_Encrypted_data.fragment.length + IV + ENC(content + padding + padding_length)); As written, as I understand it, and assuming compatibility with ignorant= = intermediates, RFC 7366 specifies the first formula. However, I have the impression that some think that either 1) the MAC = field is not part of the bytes counted as TLSCipherText.length or 2) the= = length field in the MAC is really the length of the fragment field. IMO case 1 will lead to interoperability problems with intermediates, an= d = case 2 is not what the specification says if we assume interoperability.= I think that before we continue the discussion we need to decide what th= e = record format is on the wire, and if it is compatible with the old forma= t, = or not. Then we need to decide which value is used in the MAC formula. My suggestion for an answer to the first question is that we have to = maintain backwards compatibility with ignorant intermediates, which mean= s = that TLSCipherText.length MUST count the MAC bytes, not just the fragmen= t = (including padding). Regarding the second question, IMO it does not really matter much which = = value is used. However, it is probably easier to use the length of the = encrypted block, rather than TLSCipherText.length, since = TLSCipherText.length have to be calculated instead of derived from the = MACed encrypted block. Given the current confusion we need at least an errata that accurately = specifies which values include which data. However, given that such changes may modify the meaning more than a norm= al = errata do, perhaps a better idea is a new RFC that either replace RFC 73= 66 = or one that specifies a new extension ID and deprecate the old one, so = that we reduce the potential for confusion among implementations? After = = all, some implementers might miss the existence of the errata, and in th= is = case the errata would be important for the proper understanding of the = specification. -- = Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Sat Nov 1 13:59:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556E71A1A53 for ; Sat, 1 Nov 2014 13:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dnRce7ovv2y for ; Sat, 1 Nov 2014 13:59:23 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C725C1A1A33 for ; Sat, 1 Nov 2014 13:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=fIs62YzaxBqKNwwUEuZx6WgzyPJIfbh2e071N8q67HA=; b=C0c6nJH66ooj2RFSQY4EEHoD7BZijGL2owOpK57CIm+ydedBUEdku4k14P5gZxsBqsBCLVMnfprW4yn1urOcwXJkC7sDp/b1E5auH4a8kMzwfpwbhAk8gu4pKvBu19BWf43/d5rh+6mUKmsKUO9VxEkUjrPhpHtSejDA6o1HGKY=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XkflT-0006oh-Ox; Sat, 01 Nov 2014 21:59:16 +0100 Message-ID: <545549A8.60008@polarssl.org> Date: Sat, 01 Nov 2014 21:59:20 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael StJohns , tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org> <20141031183146.GA12592@LK-Perkele-VII> <54551692.2070905@polarssl.org> <54552558.2030209@nthpermutation.com> In-Reply-To: <54552558.2030209@nthpermutation.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gLNhO-zWGzM6HSdce7WUVBHRxhs Subject: Re: [TLS] Should we require compressed points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 20:59:25 -0000 On 01/11/2014 19:24, Michael StJohns wrote: > On 11/1/2014 1:21 PM, Manuel Pégourié-Gonnard wrote: >> On 31/10/2014 19:31, Ilari Liusvaara wrote: >>> Note that 8.1.1 does not quite match that beheviour, since it specifes >>> leading zero octets to be stripped (whereas DHE "element" encoding >>> doesn't seem to specify if zeroes are stripped or not) >>> >> I think it makes sense to accept non-canonical representation of DHE elements as >> long as it's not ambiguous (be liberal in what you accept), while for the PMS >> it's necessary to be strict in order to ensure interop. But I wouldn't be oppose >> to something like "DHE elemens MUST be encoded without leading zeroes, but >> implementations MAY accept leading zeroes in their encoding". > > Sorry - this won't work. > > This (8.1.2) is about taking the derived shared secret and representing > it as a byte string for input into a key derivation function (the TLS > PRF for 1.2 basically). > Sorry for not being clear: I was referring to the part about representing DHE elements on the wire, not as part of the PMS. Here we agree the representation has to be unique (I was trying to say that actually, but I must have missed a few words). Let me try and rephrase: - for the PMS the RFC needs to specify if the representation is fixed-length or without leading zeroes. - for the on-the-wire representation it doesn't matter AFAICS. - so I'm not shocked by the fact that the requirement about encoding on-the-wire and for the PMS are different for ff-dh. - but I wouldn't mind either if the on-the-wire requirements were aligned to the stricter requirements that are necessary for the PMS, for the sake of uniformity/simplicity, as long as implementations are allowed to be liberal about on-the-wire representation (unless there is a security risk in doing so, which I don't think there is). Manuel. From nobody Sat Nov 1 14:08:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E305B1A1A82 for ; Sat, 1 Nov 2014 14:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjrP60xJh1Bg for ; Sat, 1 Nov 2014 14:07:55 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B6C1A1A77 for ; Sat, 1 Nov 2014 14:07:54 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id q200so4245682ykb.13 for ; Sat, 01 Nov 2014 14:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0nXp1e5IfYPa5PD9ktbVySz2yaXxnKmpIOjUNXvby4k=; b=EIB8bAou0xgZlj2bXSTNUBuAkT0jsg+w6pON9Nu9uiJQnp58rEZ1TmFSz+1lD4SfZd M3SM4ZnEdSfl1iZwgO8zGWp/gBioy6tkRT7uPi3d4vY039b/gs8zCcpfC+lLkWK6peXX jOmHmdIU2vYFhMyiaagNetd+seAox0VbLkTvTPPXKYF9Igoc6NnTF0aU81rX93F5WFyl iosV9jHofsyqfFXXmM04wFg59Hyx8DrCnxB3gWKTuoWH+iMTKF5xfp6Dck62im74eoNu GrdQhyJ1gOTi2QZUUAe8yGEf6xhpHoaxASLxJj5OICP4wZeYh6wEC9mrxvB0nK73YrHU wJQg== MIME-Version: 1.0 X-Received: by 10.236.17.129 with SMTP id j1mr2932982yhj.143.1414876073938; Sat, 01 Nov 2014 14:07:53 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Sat, 1 Nov 2014 14:07:53 -0700 (PDT) In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> Date: Sat, 1 Nov 2014 14:07:53 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c5yRQqnV7_RJv1_rHeDYYhKo2ps Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 21:07:58 -0000 On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla wrote: > > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara > wrote: >> >> > > PROTOCOL OPTLS: >> > > >> > > ClientHello >> > > ClientKeyShare >> > > ClientData* [K0] --------> >> > > ServerHello >> > > ServerKeyShare >> > > ServerCertificate* [K1] >> > > ServerFinished [K2] >> > > <-------- ServerData* [K2] >> > > ClientFinished* [K2] --------> >> > > >> > > >> > > Protected Application Data [K3] >> > > <-------> >> > > 1-RTT CASE: >> > > >> > > The basic 1-RTT case omits the ClientData* field. It includes a >> > > ClientKeyShare >> > > g^x and a ServerKeyShare g^y and an optional (encrypted) server >> > > certificate. >> > > If the certificate is sent (it can be omitted if the client has >> > > indicated >> > > that >> > > it knows the server key as in the case in the 0-RTT scenario) and is >> > > encrypted, >> > > the encryption key K1 is derived from g^{xy}. >> > > >> > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is >> > > used >> > > to >> > > authenticate-encrypt the ServerFinished and ClientFinished messages >> > > (which >> > > include a hash of the previous traffic) and to encrypt data from the >> > > server >> > > if >> > > such data is piggybacked to the second message. >> > >> > How does the client get the DH (or ECDH) group parameters used by the >> > server? >> >> Presumably from ServerHello (with CKS being optimistic). >> >> But the case where client misses all its guesses needs to be handled. > > > Unless I'm missing something, this can be handled the way that we > currently handle missed guesses, I.e., by having a HelloRetryRequest > followed by a new ClientHello/ClientKeyShare. Though of course > the server does need to either keep their RSA private key online > or periodically generate new signed DH shares for every group. > > >> >> However, this poses some challenges with respect to revocation. From what >> I >> understand, the parameters are intended to have limited lifetime (much >> shorter than EE certificates). >> >> The reason this is problematic is that one can't really rely on clocks: >> - Even if you happen to have sub-second accurate clock, a lot of computers >> don't. >> - The time protocols often aren't secured, allowing attacker to play >> tricks >> with endpoint time. > > > We're already starting to have that problem because of a desire to move to > OCSP > stapling, which, with staple, effectively gives the server a credential > which is > valid only within a fairly narrow window. However, I think you're right that > this > probably limits the range of lifetimes you can use with these signed DH > keys. That's not the problem Illari was talking about: It's not that g^s has limited lifetime, but that there is no way to know that the lifetime is expired, so it has long lifetime. NTP is not secure, so we have to deal with bad clocks. In the case of certificates, this is usually not so bad as the lifetimes are long. It might not be a problem for this, as we can occasionally resign, keep s in memory and not be worse off than today, or say that TLS clients need trusted clocks to avoid compromise when s is revealed. I don't think this is worse than today, where short lived certificates can be wound back by similar means. However, the fact that this requires changes to the handling of secrets may prove a barrier to adoption of TLS 1.3. I hope people who are involved with more complex things than tiny herds of beefy boxes will comment on how this proposal does or doesn't work for them, and that these issues don't turn out to be a dealbreaker. Long term we need secure NTP if we want to limit things by time: there is a proposal in the NTP WG, but it is overly complex and will likely never be implemented due to gratuitous use of CMS. This time issue may very well need to go into Security Considerations as unresolveable. Sincerely, Watson Ladd > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Nov 1 14:32:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612C71A1A6F for ; Sat, 1 Nov 2014 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.397 X-Spam-Level: ** X-Spam-Status: No, score=2.397 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rMT2EMW1XH7 for ; Sat, 1 Nov 2014 14:32:21 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BE41A1A6A for ; Sat, 1 Nov 2014 14:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=6NKm3PusigNzvk4hfmNbb8FHaOrQBfripy3avNS0l3E=; b=hXuhJX0OQ2iVxPTFG7HLBZn0bNawkFi/RMUu/rfOalrzwxqtnnP1L621QgT8u6+2E7SnG3im/Ocyx0st7i3sqh/2kMhqOsAQX3VL4t8+vRIBPoVQfp+e38At8XE7WeOLG2ySyAaAc0vDQrq6CgrI4uu0CPLMOH/1DX9SRydyv2Y=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XkgHM-0006qz-VP; Sat, 01 Nov 2014 22:32:13 +0100 Message-ID: <54555161.1040606@polarssl.org> Date: Sat, 01 Nov 2014 22:32:17 +0100 From: =?ISO-8859-15?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Yngve N. Pettersen" , tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W4YZGsxZt6akvN6ezcO9m3H7vmU Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 21:32:23 -0000 On 01/11/2014 20:25, Yngve N. Pettersen wrote: > For reference, I have tried to implement RFC 7366 in my TLS Prober, but I > have not been able to establish a connection with the "eid" server. It > seems to have some non-standard requirements to the client that AFAICT > have not been documented anywhere. > IIRC, I found out that it doesn't like 03 00 as the record-level version number in the ClientHello. I was able to connect by setting the minimum version of my test client to TLS 1.0, which upped the record-level version number of the ClientHello to 03 01. > I am starting to wonder if the confusion about this spec update is partly > due to the way the record structure is defined, with the length separate > from the data vectors. This separation have been a problem in connection > with at least some extensions. > Out of curiosity, which ones? > The way a TLS Protocol record is defined in previous versions (Using TLS > 1.2), before this update is, can a generic way be rewritten as: > > struct { > ContentType type; > ProtocolVersion version; > opaque record_data<0..maxlength> > } TLS_Record; > > This is how all clients and servers will parse current SSL and TLS > versions' records on the wire, and also how all the intermediate servers > (the ones that are causing concern for version rollback recovery) will be > parsing the TLS traffic. > Agreed so far. (And AFAIK all implementations of RFC 7366 agreed on this point.) > The field record_data containing a strucure of exactly the length of > record_data > > struct { > select(encryption_mode) { > case plaintext: TLS_Plaintext_data; > case stream_encrypted: TLS_Stream_Encrypted_data; > case block_encrypted: TLS_Block_Encrypted_data; > } > } TLS_Record_payload; > And AEAD, and plaintext can be seen as a special case of Stream. > With RFC7366 the format for the encrypted record payloads got changes, and > it seems to me that the problem is a disagreement of what the length field > in the TLSCipherText record applies to. > As far as I'm concerned, I've always been convinced that it was the length of the rest of the record (in that case, padded-encrypted stuff plus unencrypted MAC), and I've only mentioned alternative hypothesis as a sort of reductio ad absurdum. > struct { > opaque IV[SecurityParameters.record_iv_length]; > block-ciphered struct { > opaque > fragment[TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-paddinglength-1]; > uint8 padding [paddinglength]; > uint8 paddinglength; > } encrypted; > opaque MAC[MAClength]; > } TLS_EtM_Block_Encrypted_data; > I find this one complicated: to me it looks more natural to defined the length of the record as content length + padding length + etc. than otherwise. > I think one thing that is to be determined is whether this rewritten > structure definitions accurately describes both the old format and the new > RFC 7366 format. Do they? > I guess they do, but I agree with Peter that such extensive redefinitions are not really suited to an erratum. > If RFC 7366 means to say that the MAC field is no longer part of the > record_data field (and not counted in the length field), then that is > going to cause trouble, because processors that are not aware of the > extension will then read the first bytes of the MAX as the ContentType > field and the version field, probably resulting in a connection closure. > I think it's pretty clear for everyone RFC 7366 never intended to say that. > The second issue that seems to have developed is which value to use as the > length part of the MAC calculation. > Which was actually the only issue causing interop failures. > Adapted to my rewritten structure the question is if the MAC (for block > cipher encryption) is calculated as > > MAC(MAC_write_key, seq_num + > TLS_Record.type + > TLS_Record.version + > TLS_Record.record_data.length + > IV + > ENC(content + padding + padding_length)); > > or > > MAC(MAC_write_key, seq_num + > TLS_Record.type + > TLS_Record.version + > TLS_EtM_Block_Encrypted_data.fragment.length + > IV + > ENC(content + padding + padding_length)); > If I follow correctly your new notation, the second one is not what the RFC meant: the length should be the length of TLS_EtM_Block_Encrypted_data.encrypted, not fragment (ie including the padding). > As written, as I understand it, and assuming compatibility with ignorant > intermediates, RFC 7366 specifies the first formula. > That's what I first thought too, but it turns out it was not the intention of the RFC and most importantly, it's not what the implementations deployed so far do. Unless you're aware of an implementation that is deployed and incompatible with the eid server (which I seriously hope not), there's not point discussing which choice makes the most sense: it's to match the deployed implementation(s). > My suggestion for an answer to the first question is that we have to > maintain backwards compatibility with ignorant intermediates, which means > that TLSCipherText.length MUST count the MAC bytes, not just the fragment > (including padding). > I think we all agree, and always agreed, on this one. > Regarding the second question, IMO it does not really matter much which > value is used. However, it is probably easier to use the length of the > encrypted block, rather than TLSCipherText.length, since > TLSCipherText.length have to be calculated instead of derived from the > MACed encrypted block. > Yes. (Just nitpicking: when doing authenticated decryption, it's the other way: the length of the encrypted block needs to be computed, while the length of the record is readily available, so the situation is quite symmetric actually.) > Given the current confusion we need at least an errata that accurately > specifies which values include which data. > I'm under the impression that Peter's paragraph in [1] suits this goal. [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw Do you agree? I reproduce the specific paragraph here for convenience's sake: Note that the value of the 'uint16 length' field in the TLSCiphertext record differs from the length value used in the MAC calculation, since the TLSCiphertext record contains both the ciphtertext and the MAC, while the MAC calculation is performed only over the ciphertext. So the length value encoded in the TLSCiphertext record is 'length' while the length value used in the MAC calculation is 'length - SecurityParameters.mac_length'. > However, given that such changes may modify the meaning more than a normal > errata do, perhaps a better idea is a new RFC that either replace RFC 7366 > or one that specifies a new extension ID and deprecate the old one, so > that we reduce the potential for confusion among implementations? Unless we have reasons to think there already are mutually incompatible implementations in the wild, I don't think it's worth the trouble allocating a new extension, which would delay adoption of the feature, while we want it available and actually usable sooner rather than later. > After > all, some implementers might miss the existence of the errata, and in this > case the errata would be important for the proper understanding of the > specification. > I'd expect any half-serious implementer to test interop with at least one other implementation before releasing. Unfortunately, experience proves people are not always serious about it. I honestly don't know. Manuel. From nobody Sat Nov 1 14:46:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC911A1AEA for ; Sat, 1 Nov 2014 14:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgndG4GQzdqG for ; Sat, 1 Nov 2014 14:46:31 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3851A1AC8 for ; Sat, 1 Nov 2014 14:46:31 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x13so8629664wgg.22 for ; Sat, 01 Nov 2014 14:46:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8ZnnwFFMpC+qce+5joUFnHawa0YglML9omB0GRLTbRc=; b=QJ6Zl/0qo9WKWiG+oFyrY5GP+ewO2WQbZkNdwD7EMIE5K1kcuD723pwTF+mlF5ITku TavgDWG2AmqglBktG9JP7r2GstWsIReyCyg+Ad1LcS/s2IMgmv3L8s1Q7QFfY6M10xyr L8u3uv810NyFBO/3/skvT+rMpDvOHgK9r0+79ZXxvCk9wdi8orv4W2uNLe0FwnCVTdIn 9KtnaUL/4Mg6iei51yMT/GkHNWSNK5+TgfkChyOh9RhjHs44LIQDYfZBt1yMriYoJqU3 2eK7IHlLnOQGMtcyrwyLRJfveKIvfQS8vHhbFTezBjqk0gGnj4VQ+p18ca3tmyZJqoEk XRng== X-Gm-Message-State: ALoCoQnKhhs3C9kj4mu3Yrs2zocBVp7ExgMUe0+9PxbfzOfb93s9DXmCEAhFOaqeZqjGC8091etZ X-Received: by 10.180.107.136 with SMTP id hc8mr5920763wib.78.1414878389774; Sat, 01 Nov 2014 14:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Sat, 1 Nov 2014 14:45:49 -0700 (PDT) In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 1 Nov 2014 14:45:49 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=e89a8f3bad45d2c6b40506d30b4c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o_BSCtLGoZt92z6djjlsvmM59Ms Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 21:46:34 -0000 --e89a8f3bad45d2c6b40506d30b4c Content-Type: text/plain; charset=UTF-8 On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd wrote: > On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla wrote: > > > > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara > > wrote: > >> > >> > > PROTOCOL OPTLS: > >> > > > >> > > ClientHello > >> > > ClientKeyShare > >> > > ClientData* [K0] --------> > >> > > ServerHello > >> > > ServerKeyShare > >> > > ServerCertificate* [K1] > >> > > ServerFinished [K2] > >> > > <-------- ServerData* [K2] > >> > > ClientFinished* [K2] --------> > >> > > > >> > > > >> > > Protected Application Data [K3] > >> > > <-------> > >> > > 1-RTT CASE: > >> > > > >> > > The basic 1-RTT case omits the ClientData* field. It includes a > >> > > ClientKeyShare > >> > > g^x and a ServerKeyShare g^y and an optional (encrypted) server > >> > > certificate. > >> > > If the certificate is sent (it can be omitted if the client has > >> > > indicated > >> > > that > >> > > it knows the server key as in the case in the 0-RTT scenario) and is > >> > > encrypted, > >> > > the encryption key K1 is derived from g^{xy}. > >> > > > >> > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It > is > >> > > used > >> > > to > >> > > authenticate-encrypt the ServerFinished and ClientFinished messages > >> > > (which > >> > > include a hash of the previous traffic) and to encrypt data from the > >> > > server > >> > > if > >> > > such data is piggybacked to the second message. > >> > > >> > How does the client get the DH (or ECDH) group parameters used by the > >> > server? > >> > >> Presumably from ServerHello (with CKS being optimistic). > >> > >> But the case where client misses all its guesses needs to be handled. > > > > > > Unless I'm missing something, this can be handled the way that we > > currently handle missed guesses, I.e., by having a HelloRetryRequest > > followed by a new ClientHello/ClientKeyShare. Though of course > > the server does need to either keep their RSA private key online > > or periodically generate new signed DH shares for every group. > > > > > >> > >> However, this poses some challenges with respect to revocation. From > what > >> I > >> understand, the parameters are intended to have limited lifetime (much > >> shorter than EE certificates). > >> > >> The reason this is problematic is that one can't really rely on clocks: > >> - Even if you happen to have sub-second accurate clock, a lot of > computers > >> don't. > >> - The time protocols often aren't secured, allowing attacker to play > >> tricks > >> with endpoint time. > > > > > > We're already starting to have that problem because of a desire to move > to > > OCSP > > stapling, which, with staple, effectively gives the server a credential > > which is > > valid only within a fairly narrow window. However, I think you're right > that > > this > > probably limits the range of lifetimes you can use with these signed DH > > keys. > > That's not the problem Illari was talking about: It's not that g^s has > limited lifetime, but that there is no way to know that the lifetime > is expired, so it has long lifetime. NTP is not secure, so we have to > deal with bad clocks. In the case of certificates, this is usually not > so bad as the lifetimes are long. It might not be a problem for this, > as we can occasionally resign, keep s in memory and not be worse off > than today, or say that TLS clients need trusted clocks to avoid > compromise when s is revealed. > Yes. I understand this. My point is that OCSP Stapling is effectively like short-lived certificates (and short-lived DHE shares) in that you have a credential which is valid for a relatively short period of time and which therefore requires that therefore requires tight clock synchronization. And since we're moving towards OCSP stapling and short-lived certs, we've got this problem in any case. Arguably, the situation is slightly better here because the server gets to select the key lifetime and so it can tune it depending on its assessment of client clock accuracy, which is unlikely to be the case with OCSP stapling. -Ekr --e89a8f3bad45d2c6b40506d30b4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd <watsonbladd@gmail.com= > wrote:
On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara
> <ilari.liusvaara@eli= sanet.fi> wrote:
>>
>> > > PROTOCOL OPTLS:
>> > >
>> > > ClientHello
>> > > ClientKeyShare
>> > > ClientData* [K0]=C2=A0 =C2=A0 =C2=A0 =C2=A0--------><= br> >> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ServerHello
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ServerKeyShare
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ServerCertificate* [K1]
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ServerFinished [K2]
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0ServerData* [K2]
>> > > ClientFinished* [K2]=C2=A0 =C2=A0-------->
>> > >
>> > >
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected= Application Data [K3]
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <------->
>> > > 1-RTT CASE:
>> > >
>> > > The basic 1-RTT case omits the ClientData* field. It inc= ludes a
>> > > ClientKeyShare
>> > > g^x and a ServerKeyShare g^y and an optional (encrypted)= server
>> > > certificate.
>> > > If the certificate is sent (it can be omitted if the cli= ent has
>> > > indicated
>> > > that
>> > > it knows the server key as in the case in the 0-RTT scen= ario) and is
>> > > encrypted,
>> > > the encryption key K1 is derived from g^{xy}.
>> > >
>> > > Key K2 is an encryption key derived from both g^{xs} and= g^{xy}. It is
>> > > used
>> > > to
>> > > authenticate-encrypt the ServerFinished and ClientFinish= ed messages
>> > > (which
>> > > include a hash of the previous traffic) and to encrypt d= ata from the
>> > > server
>> > > if
>> > > such data is piggybacked to the second message.
>> >
>> > How does the client get the DH (or ECDH) group parameters use= d by the
>> > server?
>>
>> Presumably from ServerHello (with CKS being optimistic).
>>
>> But the case where client misses all its guesses needs to be handl= ed.
>
>
> Unless I'm missing something, this can be handled the way that we<= br> > currently handle missed guesses, I.e., by having a HelloRetryRequest > followed by a new ClientHello/ClientKeyShare. Though of course
> the server does need to either keep their RSA private key online
> or periodically generate new signed DH shares for every group.
>
>
>>
>> However, this poses some challenges with respect to revocation. Fr= om what
>> I
>> understand, the parameters are intended to have limited lifetime (= much
>> shorter than EE certificates).
>>
>> The reason this is problematic is that one can't really rely o= n clocks:
>> - Even if you happen to have sub-second accurate clock, a lot of c= omputers
>> don't.
>> - The time protocols often aren't secured, allowing attacker t= o play
>> tricks
>>=C2=A0 =C2=A0with endpoint time.
>
>
> We're already starting to have that problem because of a desire to= move to
> OCSP
> stapling, which, with staple, effectively gives the server a credentia= l
> which is
> valid only within a fairly narrow window. However, I think you're = right that
> this
> probably limits the range of lifetimes you can use with these signed D= H
> keys.

That's not the problem Illari was talking about: It's n= ot that g^s has
limited lifetime, but that there is no way to know that the lifetime
is expired, so it has long lifetime. NTP is not secure, so we have to
deal with bad clocks. In the case of certificates, this is usually not
so bad as the lifetimes are long. It might not be a problem for this,
as we can occasionally resign, keep s in memory and not be worse off
than today, or say that TLS clients need trusted clocks to avoid
compromise when s is revealed.

Yes. I u= nderstand this. My point is that OCSP Stapling is effectively
lik= e short-lived certificates (and short-lived DHE shares) in that
y= ou have a credential which is valid for a relatively short period of
<= div>time and which therefore requires that therefore requires tight
clock synchronization. And since we're moving towards OCSP
stapling and short-lived certs, we've got this problem in any case.

Arguably, the situation is slightly better here beca= use the server
gets to select the key lifetime and so it can tune= it depending on
its assessment of client clock accuracy, which i= s unlikely to be
the case with OCSP stapling.

-Ekr

--e89a8f3bad45d2c6b40506d30b4c-- From nobody Sat Nov 1 14:50:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5581A1B01 for ; Sat, 1 Nov 2014 14:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwIdGPyZ85Tm for ; Sat, 1 Nov 2014 14:50:18 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C7D1A1B0E for ; Sat, 1 Nov 2014 14:50:17 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so3713640wiv.15 for ; Sat, 01 Nov 2014 14:50:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=9yVTy2TkLwANVCTwcRJ6re1uUFriw+lKjice+Z9C/50=; b=MvRDttGMc8XgujwT5z6GRz/4+ox7Z1xW9snPtvgiFuCKV0qRkqp/zWrhgg/i6jrDnl g7sEIibx3wCZJt9AwXdus8DQlqrUEMUJ7j5KtM7n0GsMHxa8DhjXCvgidVR403rVEkIl NgTeWS2OsF/q/SHJDMcqcZskA8/yFVyPm28XmVCIiMjXHMTusfWrjAywnQ4lO0qgI6c9 lkJT3dLsVUz++WywP2PdsKj2H2cAiFpDak6KTqnEsfH40VN3C3UuA0qq7jFGq8TmfQEv nbh35Dc0C7u82Kleix+cIFw6xFJWMhIallP82asbPd8weMzUxB0gDw5dCVMQe+ADR+up r5pg== X-Gm-Message-State: ALoCoQnGuPVlaXPpW7kCw6KDMF1vsjGymGRsb1SzhBj+yW1RBg7P+HBCkMLwvqORCpSoSCCfK98s X-Received: by 10.194.87.168 with SMTP id az8mr38140524wjb.65.1414878616329; Sat, 01 Nov 2014 14:50:16 -0700 (PDT) Received: from THINK2 (cable-158-181-87-250.cust.telecolumbus.net. [158.181.87.250]) by mx.google.com with ESMTPSA id hi8sm5392673wjc.34.2014.11.01.14.50.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 01 Nov 2014 14:50:15 -0700 (PDT) Message-ID: <54555597.c8c0c20a.51b2.fffffaa4@mx.google.com> X-Google-Original-Message-ID: <000001cff61d$d363a0c0$7a2ae240$@kahlo@ageto.net> From: "Christian Kahlo" To: "'Yngve N. Pettersen'" , References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Date: Sat, 1 Nov 2014 22:50:16 +0100 Organization: AGETO Innovation GmbH MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/2Cbdzb0LNLSvZRbq7naWbMDdjAgAE/cFw Content-Language: de Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zVwWVIY6xEe_WffvnMpv-ENgzQM Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: c.kahlo@ageto.net List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 21:50:23 -0000 > For reference, I have tried to implement RFC 7366 in my TLS Prober, but > I have not been able to establish a connection with the "eid" server. > It seems to have some non-standard requirements to the client that > AFAICT have not been documented anywhere. More details please. What did the server respond, how did you try to connect? From nobody Sat Nov 1 14:58:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A33A1A1AFD for ; Sat, 1 Nov 2014 14:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RRJyKXU8fLU for ; Sat, 1 Nov 2014 14:58:25 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567F51A1AF8 for ; Sat, 1 Nov 2014 14:58:25 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so8090465wgh.11 for ; Sat, 01 Nov 2014 14:58:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=GXNFKAJXRUIDq+e5dvz8tvoakCI3Y8EobQHpvEKRw8E=; b=Cfd1aReEodGAiRUhDcynfmDIXfvkZpCynIlkPZy5eF3RrJZ5wbwK66db25N/fv45nn wVD+/cYUXi0TyVcLmlbRmloR/p47rtO+ULneDy3v9SZe0Jnex5jJ+QRJsThHkohJELoh uD6wrDontSzg7WKlgUiUn09w3oaK28ZMxpitHf8lPuFzBV63e8ezIkehYQPuSEI1MzK2 pkDY6F6e5ANlFLV3Qmkbg/gjT26aQYHnSk5BtQp7pj1KXI+Ig+EMf2JuaRaqCOlK3Cwy cKCqmFgKWLBzY3VS/tTtBt3sMfpN7RJi5MUP0Um6LmOPfk1nKaW0dhFd20nHbBZa9sYn dlSA== X-Gm-Message-State: ALoCoQkSZ8lqT6s7HBOEVVkR2eiCxtcrGv3zvkcpjvY9CESFWUeXb8532UeIH/DpTpOHQcWsF6hX X-Received: by 10.180.208.100 with SMTP id md4mr6154911wic.53.1414879103935; Sat, 01 Nov 2014 14:58:23 -0700 (PDT) Received: from THINK2 (cable-158-181-87-250.cust.telecolumbus.net. [158.181.87.250]) by mx.google.com with ESMTPSA id 4sm16556964wjx.39.2014.11.01.14.58.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 01 Nov 2014 14:58:23 -0700 (PDT) Message-ID: <5455577f.e402c20a.6dee.2253@mx.google.com> X-Google-Original-Message-ID: <000101cff61e$f625d500$e2717f00$@kahlo@ageto.net> From: "Christian Kahlo" To: =?iso-8859-1?Q?'Manuel_P=E9gouri=E9-Gonnard'?= , "'Yngve N. Pettersen'" , References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> In-Reply-To: <54555161.1040606@polarssl.org> Date: Sat, 1 Nov 2014 22:58:23 +0100 Organization: AGETO Innovation GmbH MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/2G2jPupPc5GybTa6yRfBBtLAZ1wAAm4eg Content-Language: de Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cuga1ReCIfTnoKi3siiTr16PL74 Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: c.kahlo@ageto.net List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 21:58:27 -0000 > IIRC, I found out that it doesn't like 03 00 as the record-level > version number in the ClientHello. I was able to connect by setting the > minimum version of my test client to TLS 1.0, which upped the record- > level version number of the ClientHello to 03 01. Yes, SSLv3 is explicitly unsupported. As there is no handshake back- ward compatibility with SSLv3 "03 00" is forbidden at the record level. From nobody Sat Nov 1 15:03:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A751A1B19 for ; Sat, 1 Nov 2014 15:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpM12fCrNVpw for ; Sat, 1 Nov 2014 15:03:23 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222DE1A1B1F for ; Sat, 1 Nov 2014 15:03:22 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id dc16so6702800qab.4 for ; Sat, 01 Nov 2014 15:03:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0KEb7rVp/Cd4Vp+FH+TW4GkIrb6RixlwBh9kIIec2XY=; b=ZEOtrC6skdrLQFPcsYQ4pRpHa0AS9Z41uDXu1Z4bMgbAvIVgK6a7Kc1/LFKF3VXNP3 FNYr3mDlsiNucFL0fCRZGc9lkCCN6Akh3kjGKsVPkh3L+qTEgXZPArToZPql9THb61lo zlya73f9j2fQx4uubdvcihNXPIYB8sdGJvIu3KGEUB+Y0PkSWJLKUd/nxmzR1zOFj9Ms Mw57nnBkGQJege0jf67Nly7+oR3BgnOt1Bxo+EmuUAeHhegnsWqVXnMC/93OSHb7JbV2 4yi05AYNuj18BwymzU2xo6hgQn94QSF/9Uc+yGoX2penCKwcF0vz/1N5Z+c/ULQBFAXG YZQQ== X-Gm-Message-State: ALoCoQmZT8dZ76t6m4XoeTF/M7KCOiIjVtnfs8+h5Wm5qHjHQCTylo7UB6z4miK+QoCKklOIWBpc X-Received: by 10.224.74.135 with SMTP id u7mr31100404qaj.41.1414879402161; Sat, 01 Nov 2014 15:03:22 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:e7:84b1:781c:6435:fe31? ([2601:a:2a00:e7:84b1:781c:6435:fe31]) by mx.google.com with ESMTPSA id g93sm4798148qgg.48.2014.11.01.15.03.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Nov 2014 15:03:21 -0700 (PDT) Message-ID: <545558CE.2040306@nthpermutation.com> Date: Sat, 01 Nov 2014 18:03:58 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= , tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org> <20141031183146.GA12592@LK-Perkele-VII> <54551692.2070905@polarssl.org> <54552558.2030209@nthpermutation.com> <545549A8.60008@polarssl.org> In-Reply-To: <545549A8.60008@polarssl.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W7re0O4Bii_4zV26Kd47Kk55eqA Subject: Re: [TLS] Should we require compressed points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 22:03:25 -0000 On 11/1/2014 4:59 PM, Manuel Pégourié-Gonnard wrote: > On 01/11/2014 19:24, Michael StJohns wrote: >> On 11/1/2014 1:21 PM, Manuel Pégourié-Gonnard wrote: >>> On 31/10/2014 19:31, Ilari Liusvaara wrote: >>>> Note that 8.1.1 does not quite match that beheviour, since it specifes >>>> leading zero octets to be stripped (whereas DHE "element" encoding >>>> doesn't seem to specify if zeroes are stripped or not) >>>> >>> I think it makes sense to accept non-canonical representation of DHE elements as >>> long as it's not ambiguous (be liberal in what you accept), while for the PMS >>> it's necessary to be strict in order to ensure interop. But I wouldn't be oppose >>> to something like "DHE elemens MUST be encoded without leading zeroes, but >>> implementations MAY accept leading zeroes in their encoding". >> Sorry - this won't work. >> >> This (8.1.2) is about taking the derived shared secret and representing >> it as a byte string for input into a key derivation function (the TLS >> PRF for 1.2 basically). >> > Sorry for not being clear: I was referring to the part about representing DHE > elements on the wire, not as part of the PMS. Here we agree the representation > has to be unique (I was trying to say that actually, but I must have missed a > few words). > > Let me try and rephrase: > - for the PMS the RFC needs to specify if the representation is fixed-length or > without leading zeroes. > - for the on-the-wire representation it doesn't matter AFAICS. There are well defined formats for bignums as bignums (e.g. the DH public params): > Note that in some cases (e.g., DH parameters) it is necessary to > represent integers as opaque vectors. In such cases, they are > represented as unsigned integers (i.e., leading zero octets are not > required even if the most significant bit is set). The text is actually subject to some small quibbling - it should be "represented as unsigned big-endian integers" to avoid doubt. So the unique representation for DH stuff is the on-the-wire standard representation of a positive bignum. I don't think there really needs to be any further restriction of the on-the-wire format. > - so I'm not shocked by the fact that the requirement about encoding on-the-wire > and for the PMS are different for ff-dh. > - but I wouldn't mind either if the on-the-wire requirements were aligned to the > stricter requirements that are necessary for the PMS, for the sake of > uniformity/simplicity, as long as implementations are allowed to be liberal > about on-the-wire representation (unless there is a security risk in doing so, > which I don't think there is). The PMS is an octet string key, the DH params are bignums. I wish the TLS "DH shared secret-to-octet string PMS" function would align with the standards and with other common uses, but that boat sailed years ago. I don't think there's any good reason to further restrict the representation (among other things, some bignum libs return the magnitude array without leading zeros, while others return a leading zero array if the high bit of the value is set). The current encoding just lets you drop that value into the wire format. Mike > > Manuel. > > From nobody Sat Nov 1 15:11:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFA21A1B3B for ; Sat, 1 Nov 2014 15:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vNKbmixOgDh for ; Sat, 1 Nov 2014 15:11:09 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26C51A1B38 for ; Sat, 1 Nov 2014 15:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=BGeU63QZ7Dyw68rUzYscW8OV8Cbn6Z7ickMpfy/1Kks=; b=D5/aujv6ZgmQxIBz067CR3xZ2ln3HHG26le6H86HtFLfJMFal1KalX4K+xvdfOdtw15eiP0Z3lDAORO8OfJDpmrlo7iPNP6weNeCCrV5XGZxXt8JA0TjQJTMl2cPBdBAmeXVFr4wBYqjEW8jdPeXLgM8vWGoelKk+4rWasKRMAw=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xkgsv-0006uZ-88; Sat, 01 Nov 2014 23:11:01 +0100 Message-ID: <54555A79.30803@polarssl.org> Date: Sat, 01 Nov 2014 23:11:05 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: c.kahlo@ageto.net, "'Yngve N. Pettersen'" , tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> <5455577f.e402c20a.6dee.2253@mx.google.com> In-Reply-To: <5455577f.e402c20a.6dee.2253@mx.google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2tmhTTrei8r8w806mHtN_ZzH78E Subject: [TLS] record-level version number in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 22:11:10 -0000 [changing the subject line this it has nothing to do with RFC 7366] On 01/11/2014 22:58, Christian Kahlo wrote: >> IIRC, I found out that it doesn't like 03 00 as the record-level >> version number in the ClientHello. I was able to connect by setting the >> minimum version of my test client to TLS 1.0, which upped the record- >> level version number of the ClientHello to 03 01. > > Yes, SSLv3 is explicitly unsupported. As there is no handshake back- > ward compatibility with SSLv3 "03 00" is forbidden at the record level. > I certainly agree about not supporting SSLv3 at all, but I'm not convinced rejecting record-level 03 00 this is the best thing to do . In practice this mostly means rejecting clients that want to interoperate with old servers. My interpretation of the last paragraph of RFC 5246 E.1 below TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document. is life is already complicated enough for clients, and servers should help them by accepting any half-sensible value here (it's always time to be stricter later). Just my opinion. Manuel. From nobody Sat Nov 1 15:23:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9141A1B6C for ; Sat, 1 Nov 2014 15:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBbWbQldthuM for ; Sat, 1 Nov 2014 15:22:58 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DFF1A1B51 for ; Sat, 1 Nov 2014 15:22:58 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 10so4222010ykt.21 for ; Sat, 01 Nov 2014 15:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YTBQP2bzCxDOs/4uRjzqR3rhHkpsFYB9d+mIN90uBdQ=; b=Cf0+A4gIGm1LPLUw7GJB58UbJWYQPmWfEGA52ZJItr04pyasdZSrBo7TCHWJcgnLi3 +ZZGzHZqsFK1yFiR1OwSdeFPxJESOty0EOwYS9uQJ+esMuumyrdGLCANf7d5djMmWGNk JKeUaH9ZfY7jqTHMZTIjn27bQolPndUgpe2NyneQEfSo6X/KEM0jgtN7I3V5MewyXZx7 ueUmWYXYo1wV6jF6Br0+w0DgLDTc3ZKEe3aKL1o0F72PBRV2q/LwXTK2Y0gMsjVU2Qji 6eND4wxOgwcQnuAtdOqJyhil6D5SgNUV0CMgjemagEAYF/EKPbmX8HJQ/zHdCrbVqos2 iUVA== MIME-Version: 1.0 X-Received: by 10.170.140.84 with SMTP id h81mr17432676ykc.55.1414880577381; Sat, 01 Nov 2014 15:22:57 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Sat, 1 Nov 2014 15:22:57 -0700 (PDT) In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> Date: Sat, 1 Nov 2014 15:22:57 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p6q39peIVd-wQnkhayL269l3nsU Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 22:23:01 -0000 On Sat, Nov 1, 2014 at 2:45 PM, Eric Rescorla wrote: > > > On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd wrote: >> >> On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla wrote: >> > >> > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara >> > wrote: >> >> >> >> >> >> However, this poses some challenges with respect to revocation. From >> >> what >> >> I >> >> understand, the parameters are intended to have limited lifetime (much >> >> shorter than EE certificates). >> >> >> >> The reason this is problematic is that one can't really rely on clocks: >> >> - Even if you happen to have sub-second accurate clock, a lot of >> >> computers >> >> don't. >> >> - The time protocols often aren't secured, allowing attacker to play >> >> tricks >> >> with endpoint time. >> > >> > >> > We're already starting to have that problem because of a desire to move >> > to >> > OCSP >> > stapling, which, with staple, effectively gives the server a credential >> > which is >> > valid only within a fairly narrow window. However, I think you're right >> > that >> > this >> > probably limits the range of lifetimes you can use with these signed DH >> > keys. >> >> That's not the problem Illari was talking about: It's not that g^s has >> limited lifetime, but that there is no way to know that the lifetime >> is expired, so it has long lifetime. NTP is not secure, so we have to >> deal with bad clocks. In the case of certificates, this is usually not >> so bad as the lifetimes are long. It might not be a problem for this, >> as we can occasionally resign, keep s in memory and not be worse off >> than today, or say that TLS clients need trusted clocks to avoid >> compromise when s is revealed. > > > Yes. I understand this. My point is that OCSP Stapling is effectively > like short-lived certificates (and short-lived DHE shares) in that > you have a credential which is valid for a relatively short period of > time and which therefore requires that therefore requires tight > clock synchronization. And since we're moving towards OCSP > stapling and short-lived certs, we've got this problem in any case. Ah, I was thinking of a different problem with OCSP stapling, which is getting the response to staple periodically, and when you don't... Thinking about it more, I think I don't understand this. X509 certificates have expiration dates. Doesn't that mean the client needs a synchronized clock already? Why does the duration of the validity of the response affect the existence of this issue? With OCSP stapling this problem gets worse because there is no freshness: it's a stapled response, and one of the security goals was making revocation take hold quickly So I think an attacker who can play games with time can already break OCSP stapling. Here we're limiting the validity time of something equivalent to a certificate, to deal with all sorts of problems that could lead to disclosure of secrets. But it seems like this mechanism might not work, because of endpoint timing issues where the attacker gets to set the clock. How much worse off are we than when certificate expiration times or OCSP validity times get played with? > > Arguably, the situation is slightly better here because the server > gets to select the key lifetime and so it can tune it depending on > its assessment of client clock accuracy, which is unlikely to be > the case with OCSP stapling. The problem isn't that the client has an imprecise clock: +/- 10 minutes should not pose a problem. The problem is an that an attacker can set the clock to whatever they want if they control the network. Tuning the validity period doesn't change this. It's not an operational issue, but a security issue. > > -Ekr > Sincerely, Watson Ladd From nobody Sat Nov 1 15:23:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB41A1B69 for ; Sat, 1 Nov 2014 15:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxjSpAmshfGr for ; Sat, 1 Nov 2014 15:23:39 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2FD1A1B67 for ; Sat, 1 Nov 2014 15:23:36 -0700 (PDT) Received: from 151.170.251.212.customer.cdi.no ([212.251.170.151]:58067 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Xkh55-0002RT-5v; Sat, 01 Nov 2014 23:23:35 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, =?iso-8859-15?Q?Manuel_P=E9gouri=E9-Gonnard?= References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> Date: Sat, 01 Nov 2014 23:23:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <54555161.1040606@polarssl.org> User-Agent: Opera Mail/12.17 (Win32) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/teNJVNI1rg2XyYBRukrxv-2rdiA Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 22:23:43 -0000 On Sat, 01 Nov 2014 22:32:17 +0100, Manuel P=E9gouri=E9-Gonnard = wrote: > On 01/11/2014 20:25, Yngve N. Pettersen wrote: >> For reference, I have tried to implement RFC 7366 in my TLS Prober, b= ut = >> I >> have not been able to establish a connection with the "eid" server. I= t >> seems to have some non-standard requirements to the client that AFAIC= T >> have not been documented anywhere. >> > IIRC, I found out that it doesn't like 03 00 as the record-level versi= on = > number > in the ClientHello. I was able to connect by setting the minimum versi= on = > of my > test client to TLS 1.0, which upped the record-level version number of= = > the > ClientHello to 03 01. As I recall (don't have the branch checked out at the moment) my prober = = tested multiple variations and versions, and never got a connection = established, with or without extensions enabled >> I am starting to wonder if the confusion about this spec update is = >> partly >> due to the way the record structure is defined, with the length separ= ate >> from the data vectors. This separation have been a problem in = >> connection >> with at least some extensions. >> > Out of curiosity, which ones? I ran into the issue when writing the multiple certificate status = extension, and also noticed it in the Server Name Indication extension f= or = new types of names, although that had already been noticed and fixed in = an = updated spec. >> The way a TLS Protocol record is defined in previous versions (Using = TLS >> 1.2), before this update is, can a generic way be rewritten as: >> >> struct { >> ContentType type; >> ProtocolVersion version; >> opaque record_data<0..maxlength> >> } TLS_Record; >> >> This is how all clients and servers will parse current SSL and TLS >> versions' records on the wire, and also how all the intermediate serv= ers >> (the ones that are causing concern for version rollback recovery) wil= l = >> be >> parsing the TLS traffic. >> > Agreed so far. (And AFAIK all implementations of RFC 7366 agreed on th= is = > point.) Given the discussion I noticed, which seemed to be a discussion about = whether the MAC length was included in the TLSCipherText.length or not, = I = thought it best to have a structure for discussion that made it clear. T= he = goal of the restatement was to remove as much ambiguity as possible >> The field record_data containing a strucure of exactly the length of >> record_data >> >> struct { >> select(encryption_mode) { >> case plaintext: TLS_Plaintext_data; >> case stream_encrypted: TLS_Stream_Encrypted_data; >> case block_encrypted: TLS_Block_Encrypted_data; >> } >> } TLS_Record_payload; >> > And AEAD, and plaintext can be seen as a special case of Stream. I needed some cases to show the variation, and did not mean it to be = exhaustive. >> With RFC7366 the format for the encrypted record payloads got changes= , = >> and >> it seems to me that the problem is a disagreement of what the length = = >> field >> in the TLSCipherText record applies to. >> > As far as I'm concerned, I've always been convinced that it was the = > length of > the rest of the record (in that case, padded-encrypted stuff plus = > unencrypted > MAC), and I've only mentioned alternative hypothesis as a sort of = > reductio ad > absurdum. To me, before I lost track of all the details in the back and forth, it = = seemed like that was considered a possible contender. >> struct { >> opaque IV[SecurityParameters.record_iv_length]; >> block-ciphered struct { >> opaque >> fragment[TLS_Record.record_data.length-SecurityParameters.record_iv_l= ength-MAC-paddinglength-1]; >> uint8 padding [paddinglength]; >> uint8 paddinglength; >> } encrypted; >> opaque MAC[MAClength]; >> } TLS_EtM_Block_Encrypted_data; >> > I find this one complicated: to me it looks more natural to defined th= e = > length > of the record as content length + padding length + etc. than otherwise= . > >> I think one thing that is to be determined is whether this rewritten >> structure definitions accurately describes both the old format and th= e = >> new >> RFC 7366 format. Do they? >> > I guess they do, but I agree with Peter that such extensive = > redefinitions are > not really suited to an erratum. The restatement is not intended for any erratum, but as a way to better = = show the details of how the message is structured, which numbers go wher= e, = so that it is clearer which numbers come from where. >> If RFC 7366 means to say that the MAC field is no longer part of the >> record_data field (and not counted in the length field), then that is= >> going to cause trouble, because processors that are not aware of the >> extension will then read the first bytes of the MAX as the ContentTyp= e >> field and the version field, probably resulting in a connection closu= re. >> > I think it's pretty clear for everyone RFC 7366 never intended to say = = > that. I hoped so, but given all the back and forth, particularly about what wa= s = included in TLSCipherText.length, I was not sure if some might think tha= t. = Just to be on the safe side I think TLSCipherText.length should have a = comment in the structure as being length of fragment+padding+mac >> The second issue that seems to have developed is which value to use a= s = >> the >> length part of the MAC calculation. >> > Which was actually the only issue causing interop failures. > >> Adapted to my rewritten structure the question is if the MAC (for blo= ck >> cipher encryption) is calculated as >> >> MAC(MAC_write_key, seq_num + >> TLS_Record.type + >> TLS_Record.version + >> TLS_Record.record_data.length + >> IV + >> ENC(content + padding + padding_length)); >> >> or >> >> MAC(MAC_write_key, seq_num + >> TLS_Record.type + >> TLS_Record.version + >> TLS_EtM_Block_Encrypted_data.fragment.length + >> IV + >> ENC(content + padding + padding_length)); >> > If I follow correctly your new notation, the second one is not what th= e = > RFC > meant: the length should be the length of > TLS_EtM_Block_Encrypted_data.encrypted, not fragment (ie including the= = > padding). Sorry, I should have used TLS_EtM_Block_Encrypted_data.encrypted.length = in = the second one. Hope that makes it clearer. >> As written, as I understand it, and assuming compatibility with ignor= ant >> intermediates, RFC 7366 specifies the first formula. >> > That's what I first thought too, but it turns out it was not the = > intention of > the RFC and most importantly, it's not what the implementations deploy= ed = > so far do. > > Unless you're aware of an implementation that is deployed and = > incompatible with > the eid server (which I seriously hope not), there's not point = > discussing which > choice makes the most sense: it's to match the deployed = > implementation(s). I am currently not aware of any testable servers, except the eid server,= = and I have not been able to get more than protocol errors or handshake = errors from it, and I am not sure what it is objecting to. >> My suggestion for an answer to the first question is that we have to >> maintain backwards compatibility with ignorant intermediates, which = >> means >> that TLSCipherText.length MUST count the MAC bytes, not just the = >> fragment >> (including padding). >> > I think we all agree, and always agreed, on this one. Good. >> Regarding the second question, IMO it does not really matter much whi= ch >> value is used. However, it is probably easier to use the length of th= e >> encrypted block, rather than TLSCipherText.length, since >> TLSCipherText.length have to be calculated instead of derived from th= e >> MACed encrypted block. >> > Yes. (Just nitpicking: when doing authenticated decryption, it's the = > other way: > the length of the encrypted block needs to be computed, while the leng= th = > of the > record is readily available, so the situation is quite symmetric = > actually.) > >> Given the current confusion we need at least an errata that accuratel= y >> specifies which values include which data. >> > I'm under the impression that Peter's paragraph in [1] suits this goal= . > > [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8= Sw > > Do you agree? I reproduce the specific paragraph here for convenience'= s = > sake: > > Note that the value of the 'uint16 length' field in the TLSCiphertex= t = > record > differs from the length value used in the MAC calculation, since the= > TLSCiphertext record contains both the ciphtertext and the MAC, whil= e = > the > MAC calculation is performed only over the ciphertext. So the lengt= h = > value > encoded in the TLSCiphertext record is 'length' while the length val= ue = > used > in the MAC calculation is 'length - SecurityParameters.mac_length'. It seems to describe the conclusions above, indeed, but personally I wou= ld = prefer that the formula should not reference TLSCiphertext.length at all= , = but instead refer to the length of the field with the encrypted data, or= = specifically defined as avariable in a separate formula as 'length - = SecurityParameters.mac_length'. Less chance of confusion, that way, and = = having multiple values of a variable is never a good idea, unless it is = = inside an algorithm that explicitly update the values as part of a step,= = after it was used for something. >> However, given that such changes may modify the meaning more than a = >> normal >> errata do, perhaps a better idea is a new RFC that either replace RFC= = >> 7366 >> or one that specifies a new extension ID and deprecate the old one, s= o >> that we reduce the potential for confusion among implementations? > > Unless we have reasons to think there already are mutually incompatibl= e > implementations in the wild, I don't think it's worth the trouble = > allocating a > new extension, which would delay adoption of the feature, while we wan= t = > it > available and actually usable sooner rather than later. I'm just putting it on the table as a (worst case) possibility; an = intermediate solution might be a new RFC obsoleting 7366, just updating = = the text, if the errata text would be too extensive. >> After >> all, some implementers might miss the existence of the errata, and in= = >> this >> case the errata would be important for the proper understanding of th= e >> specification. >> > I'd expect any half-serious implementer to test interop with at least = = > one other > implementation before releasing. Unfortunately, experience proves peop= le = > are not > always serious about it. I honestly don't know. The possible issue is that a version might get widely deployed before a = = specific issue is properly documented; just as examples of such issues a= re = version and extension intolerance, and personally, the SNI implementatio= n = I originally wrote for Opera caused it to crash when actually encounteri= ng = a server responding to the SNI extension. Might not happen in this case,= = since I am not aware of any actually deployed servers or clients. -- = Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Sat Nov 1 16:22:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23FD1A1B9E for ; Sat, 1 Nov 2014 16:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkp4nnD1QDoK for ; Sat, 1 Nov 2014 16:22:47 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BEF1A1B9C for ; Sat, 1 Nov 2014 16:22:46 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id n3so3849348wiv.6 for ; Sat, 01 Nov 2014 16:22:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zhNWh/czQbukas/Nfn98JT0J74FgcBeLjI6RBAnIzRw=; b=kgyGPceSSTcbRm0BNQPgiD+ccwh2XPvkwnulTu275/rWC9L8PEVZAZ1u2gokJep4L1 x4wTRLgmMyKRld7QOIhwKTx4aCSQj6YVeLRzmqx2QVnLIelX75aHLSYw/1T/KJcTLrwu /9h739RAmjd3idd3N5T52+ZR+oeFZvgPY0OvOLXwwe0koxttbxmq0RLNm2B/mXGPJN8Q RTvZ7/xdDbbQxIh5rYMNeX7LGUD3uIg97LZ6RtTEmPLsrLjfU35nkxJCvEGpvqA+WJwF YUQ+g2qReO0n+k+b3XEmKzam72ef0yB5pbtM7c9i5SQE4sFLCk1cLtI2uWHmxsaBK1MU ooEg== X-Gm-Message-State: ALoCoQloykpv459HACyEslvxdBj7alF4BOv2rpVYsjD92VYbcK9GkhrYpjK74a1NGIZOj4M1UitP X-Received: by 10.194.76.202 with SMTP id m10mr15053102wjw.42.1414884165239; Sat, 01 Nov 2014 16:22:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Sat, 1 Nov 2014 16:22:05 -0700 (PDT) In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 1 Nov 2014 16:22:05 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bf0c1b2115d520506d4648e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g2NquXaeHdaKpha-InJrg25jrbU Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 23:22:49 -0000 --047d7bf0c1b2115d520506d4648e Content-Type: text/plain; charset=UTF-8 On Sat, Nov 1, 2014 at 3:22 PM, Watson Ladd wrote: > On Sat, Nov 1, 2014 at 2:45 PM, Eric Rescorla wrote: > > > > > > On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd > wrote: > >> > >> On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla wrote: > >> > > >> > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara > >> > wrote: > >> >> > > >> >> > >> >> However, this poses some challenges with respect to revocation. From > >> >> what > >> >> I > >> >> understand, the parameters are intended to have limited lifetime > (much > >> >> shorter than EE certificates). > >> >> > >> >> The reason this is problematic is that one can't really rely on > clocks: > >> >> - Even if you happen to have sub-second accurate clock, a lot of > >> >> computers > >> >> don't. > >> >> - The time protocols often aren't secured, allowing attacker to play > >> >> tricks > >> >> with endpoint time. > >> > > >> > > >> > We're already starting to have that problem because of a desire to > move > >> > to > >> > OCSP > >> > stapling, which, with staple, effectively gives the server a > credential > >> > which is > >> > valid only within a fairly narrow window. However, I think you're > right > >> > that > >> > this > >> > probably limits the range of lifetimes you can use with these signed > DH > >> > keys. > >> > >> That's not the problem Illari was talking about: It's not that g^s has > >> limited lifetime, but that there is no way to know that the lifetime > >> is expired, so it has long lifetime. NTP is not secure, so we have to > >> deal with bad clocks. In the case of certificates, this is usually not > >> so bad as the lifetimes are long. It might not be a problem for this, > >> as we can occasionally resign, keep s in memory and not be worse off > >> than today, or say that TLS clients need trusted clocks to avoid > >> compromise when s is revealed. > > > > > > Yes. I understand this. My point is that OCSP Stapling is effectively > > like short-lived certificates (and short-lived DHE shares) in that > > you have a credential which is valid for a relatively short period of > > time and which therefore requires that therefore requires tight > > clock synchronization. And since we're moving towards OCSP > > stapling and short-lived certs, we've got this problem in any case. > > Ah, I was thinking of a different problem with OCSP stapling, which is > getting the response to staple periodically, and when you don't... > > Thinking about it more, I think I don't understand this. X509 > certificates have expiration dates. Doesn't that mean the client needs > a synchronized clock already? Yes, it does. > Why does the duration of the validity of > the response affect the existence of this issue? > My argument here is that clients have some ability to sanity check network time information, and so it's not necessarily like the attacker can set the time to anything (I don't know how NTP clients currently work). So an attacker who can only move the clock by a day or two is going to of course be more effective attacking credentials with a short time window than with a long time window (though arguably that's because the latter is less secure to start out with). Does that make sense? -Ekr --047d7bf0c1b2115d520506d4648e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 1, 2014 at 3:22 PM, Watson Ladd <watsonbladd@gmail.com= > wrote:
On Sat, Nov = 1, 2014 at 2:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd <watsonbladd@gmail.com> wrote: >>
>> On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara
>> > <ilari.liusvaara@elisanet.fi> wrote:
>> >>
<snip>
>> >>
>> >> However, this poses some challenges with respect to revoc= ation. From
>> >> what
>> >> I
>> >> understand, the parameters are intended to have limited l= ifetime (much
>> >> shorter than EE certificates).
>> >>
>> >> The reason this is problematic is that one can't real= ly rely on clocks:
>> >> - Even if you happen to have sub-second accurate clock, a= lot of
>> >> computers
>> >> don't.
>> >> - The time protocols often aren't secured, allowing a= ttacker to play
>> >> tricks
>> >>=C2=A0 =C2=A0with endpoint time.
>> >
>> >
>> > We're already starting to have that problem because of a = desire to move
>> > to
>> > OCSP
>> > stapling, which, with staple, effectively gives the server a = credential
>> > which is
>> > valid only within a fairly narrow window. However, I think yo= u're right
>> > that
>> > this
>> > probably limits the range of lifetimes you can use with these= signed DH
>> > keys.
>>
>> That's not the problem Illari was talking about: It's not = that g^s has
>> limited lifetime, but that there is no way to know that the lifeti= me
>> is expired, so it has long lifetime. NTP is not secure, so we have= to
>> deal with bad clocks. In the case of certificates, this is usually= not
>> so bad as the lifetimes are long. It might not be a problem for th= is,
>> as we can occasionally resign, keep s in memory and not be worse o= ff
>> than today, or say that TLS clients need trusted clocks to avoid >> compromise when s is revealed.
>
>
> Yes. I understand this. My point is that OCSP Stapling is effectively<= br> > like short-lived certificates (and short-lived DHE shares) in that
> you have a credential which is valid for a relatively short period of<= br> > time and which therefore requires that therefore requires tight
> clock synchronization. And since we're moving towards OCSP
> stapling and short-lived certs, we've got this problem in any case= .

Ah, I was thinking of a different problem with OCSP stapling, w= hich is
getting the response to staple periodically, and when you don't...

Thinking about it more, I think I don't understand this. X509
certificates have expiration dates. Doesn't that mean the client needs<= br> a synchronized clock already?

Yes, it does.=

=C2=A0
Why d= oes the duration of the validity of
the response affect the existence of this issue?

<= /div>
My argument here is that clients have some ability to sanity chec= k
network time information, and so it's not necessarily like = the attacker
can set the time to anything (I don't know how N= TP clients currently
work). So an attacker who can only move the = clock by a day or
two is going to of course be more effective att= acking credentials
with a short time window than with a long time= window
(though arguably that's because the latter is less se= cure to start
out with).

Does that make = sense?

-Ekr



--047d7bf0c1b2115d520506d4648e-- From nobody Sat Nov 1 16:31:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A211A1BA5 for ; Sat, 1 Nov 2014 16:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.997 X-Spam-Level: X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lnk8HL_gNIs for ; Sat, 1 Nov 2014 16:31:02 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6AD1A1BA4 for ; Sat, 1 Nov 2014 16:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=wf2h75bjszmiggdM2Jkw+HF42MM5D8WrPGw6pTQuNso=; b=gLwsfM3ZAgz/tjqvFKYlcfvxJGHmUcMLHQI08/uJEMUTDa2QkVHsU2btWn5J/eeVV4yg7heyPs8JmAJN8cQJt65oq29J1FjBvRjzyHYJzYFfMgcewioZQsexXFBpmWPietsVxtU9fbB9LVTwLpkb9YEg+gdMElkPKK+xbLPzE8k=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xki8D-0006zu-Tg; Sun, 02 Nov 2014 00:30:54 +0100 Message-ID: <54556D32.80100@polarssl.org> Date: Sun, 02 Nov 2014 00:30:58 +0100 From: =?ISO-8859-15?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Yngve N. Pettersen" , tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BThNFeuWgUv2M-D4Nf3iHg-WA8Q Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 23:31:04 -0000 (Cutting a lot of details where we agree about the important points, to get to the "what should be done now" part.) On 01/11/2014 23:23, Yngve N. Pettersen wrote: > On Sat, 01 Nov 2014 22:32:17 +0100, Manuel Pégourié-Gonnard > wrote: >> I'm under the impression that Peter's paragraph in [1] suits this goal. >> >> [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw >> >> Do you agree? I reproduce the specific paragraph here for convenience's >> sake: >> >> Note that the value of the 'uint16 length' field in the TLSCiphertext >> record >> differs from the length value used in the MAC calculation, since the >> TLSCiphertext record contains both the ciphtertext and the MAC, while >> the >> MAC calculation is performed only over the ciphertext. So the length >> value >> encoded in the TLSCiphertext record is 'length' while the length value >> used >> in the MAC calculation is 'length - SecurityParameters.mac_length'. > > It seems to describe the conclusions above, indeed, but personally I would > prefer that the formula should not reference TLSCiphertext.length at all, > but instead refer to the length of the field with the encrypted data, or > specifically defined as avariable in a separate formula as 'length - > SecurityParameters.mac_length'. Less chance of confusion, that way, and > having multiple values of a variable is never a good idea, unless it is > inside an algorithm that explicitly update the values as part of a step, > after it was used for something. > 100% agreed, I think for me the use of the same name for two different values was the root cause of the confusion. How about combining Peter's above paragraph with my proposed rewriting of the MAC calculation as: In TLS [2] notation, the MAC calculation for TLS 1.0 without the explicit Initialization Vector (IV) is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + length of (ENC(content + padding + padding_length)) + ENC(content + padding + padding_length)); and for TLS 1.1 and greater with an explicit IV is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + length of (IV + ENC(content + padding + padding_length)) + IV + ENC(content + padding + padding_length)); where the length is encoded as two bytes in the usual way. It's admittedly not he most elegant, but at least it's clear and unambiguous, which is probably more important than elegance for an erratum. > I'm just putting it on the table as a (worst case) possibility; an > intermediate solution might be a new RFC obsoleting 7366, just updating > the text, if the errata text would be too extensive. > Ok, it never hurts to consider possibilities. I'm not experienced enough with the standards process to have an opinion on this one. I think it's clear that we want an erratum soon regardless of what is or isn't deemed necessary later. >> I'd expect any half-serious implementer to test interop with at least one >> other implementation before releasing. Unfortunately, experience proves >> people are not always serious about it. I honestly don't know. > > The possible issue is that a version might get widely deployed before a > specific issue is properly documented; just as examples of such issues are > version and extension intolerance, and personally, the SNI implementation > I originally wrote for Opera caused it to crash when actually encountering > a server responding to the SNI extension. Might not happen in this case, > since I am not aware of any actually deployed servers or clients. > Yes, that sort of thing is unfortunately can't be ruled out. As above, I honestly don't know what the best approach is, but it probably starts with an erratum, and hopefully also ends with the erratum! Manuel. From nobody Sat Nov 1 16:36:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FF81A1BA0 for ; Sat, 1 Nov 2014 16:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpM9tsov8Shh for ; Sat, 1 Nov 2014 16:36:55 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7AB1A1B9A for ; Sat, 1 Nov 2014 16:36:54 -0700 (PDT) Received: from 151.170.251.212.customer.cdi.no ([212.251.170.151]:59964 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XkiE0-0007B7-NI; Sun, 02 Nov 2014 00:36:52 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, =?iso-8859-15?Q?Manuel_P=E9gouri=E9-Gonnard?= References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> <54556D32.80100@polarssl.org> Date: Sun, 02 Nov 2014 00:36:40 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <54556D32.80100@polarssl.org> User-Agent: Opera Mail/12.17 (Win32) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1DWtnt5NekvoM8qx9A9v5umMeUA Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 23:36:58 -0000 On Sun, 02 Nov 2014 00:30:58 +0100, Manuel P=E9gouri=E9-Gonnard = wrote: > (Cutting a lot of details where we agree about the important points, t= o = > get to > the "what should be done now" part.) > > On 01/11/2014 23:23, Yngve N. Pettersen wrote: >> On Sat, 01 Nov 2014 22:32:17 +0100, Manuel P=E9gouri=E9-Gonnard >> wrote: >>> I'm under the impression that Peter's paragraph in [1] suits this go= al. >>> >>> [1] = >>> http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw= >>> >>> Do you agree? I reproduce the specific paragraph here for convenienc= e's >>> sake: >>> >>> Note that the value of the 'uint16 length' field in the TLSCiphert= ext >>> record >>> differs from the length value used in the MAC calculation, since t= he >>> TLSCiphertext record contains both the ciphtertext and the MAC, wh= ile >>> the >>> MAC calculation is performed only over the ciphertext. So the len= gth >>> value >>> encoded in the TLSCiphertext record is 'length' while the length = >>> value >>> used >>> in the MAC calculation is 'length - SecurityParameters.mac_length'= . >> >> It seems to describe the conclusions above, indeed, but personally I = = >> would >> prefer that the formula should not reference TLSCiphertext.length at = = >> all, >> but instead refer to the length of the field with the encrypted data,= or >> specifically defined as avariable in a separate formula as 'length - >> SecurityParameters.mac_length'. Less chance of confusion, that way, a= nd >> having multiple values of a variable is never a good idea, unless it = is >> inside an algorithm that explicitly update the values as part of a st= ep, >> after it was used for something. >> > 100% agreed, I think for me the use of the same name for two different= = > values > was the root cause of the confusion. How about combining Peter's above= = > paragraph > with my proposed rewriting of the MAC calculation as: > > In TLS [2] notation, the MAC calculation for TLS 1.0 withou= t > the explicit Initialization Vector (IV) is: > > MAC(MAC_write_key, seq_num + > TLSCipherText.type + > TLSCipherText.version + > length of (ENC(content + padding + padding_length)) + > ENC(content + padding + padding_length)); > > and for TLS 1.1 and greater with an explicit IV is: > > MAC(MAC_write_key, seq_num + > TLSCipherText.type + > TLSCipherText.version + > length of (IV + ENC(content + padding + padding_length)) + > IV + > ENC(content + padding + padding_length)); > > where the length is encoded as two bytes in the usual way. > > It's admittedly not he most elegant, but at least it's clear and = > unambiguous, > which is probably more important than elegance for an erratum. That looks fairly OK to me. A possible tweak one could add, is to define encrypted_content =3D ENC(content + padding + padding_length) and use that in the formula instead. -- = Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Sat Nov 1 16:43:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0081A1BA9 for ; Sat, 1 Nov 2014 16:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYY5DDOt10HG for ; Sat, 1 Nov 2014 16:43:35 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410281A1BA7 for ; Sat, 1 Nov 2014 16:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=zEG430W7bSo5qiyt4OHY2iEDmVKi/N6pwq02HD0FBDs=; b=A7m7S4e0yWMwbvhvv8+lblPzjEd6nVDqlB2Dq2EsguMt0a+tEhZCaMKnZeMP1Bkgv4qqfgSac+IRCB27LHnWxY23l5PpgQO2aFcQvALgQ9K59/GHedYEgG0EAHkIRgyEQmP8eVGZaghUb50W6IwkGbUDtYbX3tC34GL+SCv3Z7U=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XkiKM-000719-BM; Sun, 02 Nov 2014 00:43:26 +0100 Message-ID: <54557023.6040204@polarssl.org> Date: Sun, 02 Nov 2014 00:43:31 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Eric Rescorla , Watson Ladd References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XzmOWMF_HzSJ5CpWrTrlG3SZa2M Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 23:43:36 -0000 On 02/11/2014 00:22, Eric Rescorla wrote: > On Sat, Nov 1, 2014 at 3:22 PM, Watson Ladd wrote: >> Why does the duration of the validity of >> the response affect the existence of this issue? >> > > My argument here is that clients have some ability to sanity check > network time information, and so it's not necessarily like the attacker > can set the time to anything (I don't know how NTP clients currently > work). So an attacker who can only move the clock by a day or > two is going to of course be more effective attacking credentials > with a short time window than with a long time window > (though arguably that's because the latter is less secure to start > out with). > > Does that make sense? > I think it does, at least partially I'm by no means an expert on NTP security, but in my small experience, I've seen configurations on laptops where the NTP server is started when a network connection is established, and with an option that abruptly sets the time (rather than slowly shifting it) on startup (that's the -s option to openntpd for example). So, while I tend to agree that in theory clients could be able to sanity-check the network time if a precision of the order of days is desired, I'm afraid in practice it's not happening everywhere. But sure, needing a higher level of precision can only make more attacks practical in more circumstances. Manuel. From nobody Sat Nov 1 16:45:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7801A1B9A for ; Sat, 1 Nov 2014 16:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.997 X-Spam-Level: X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIToSy8btxsg for ; Sat, 1 Nov 2014 16:45:23 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D270E1A1A96 for ; Sat, 1 Nov 2014 16:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=CPqYoMbGiq54zF3pYMcznVe9WhJ6vY/RtCXWHd3W754=; b=KtTtdOfbU0ihLwIi5sTZQXslLmqGD5rDsPlkHPCjB0plJiy1vS5nWwrei9acR36U/EJiirHOmWehLTuplUK0Om+h8CpGlpjPSncWYWVtGvsQLouhtskobxrLD711sWlED6qNOwtCHFbfowiiM6fAodym1mDYpnSRv+s93POT/3E=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XkiM5-00071Z-WC; Sun, 02 Nov 2014 00:45:15 +0100 Message-ID: <5455708E.60606@polarssl.org> Date: Sun, 02 Nov 2014 00:45:18 +0100 From: =?ISO-8859-15?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Yngve N. Pettersen" , tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> <54556D32.80100@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YKvcj1pErWpzfBzdoBZbb962rwA Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 23:45:24 -0000 On 02/11/2014 00:36, Yngve N. Pettersen wrote: > On Sun, 02 Nov 2014 00:30:58 +0100, Manuel Pégourié-Gonnard > wrote: > > That looks fairly OK to me. > Cool, we're converging. > A possible tweak one could add, is to define > > encrypted_content = ENC(content + padding + padding_length) > > and use that in the formula instead. > As Peter pointed out after the first version of my proposal, we need two versions: one for TLS 1.0 (no IV) and one for higher versions, to point out the IV is included. Manuel. From nobody Sat Nov 1 17:45:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9216D1A1BCB for ; Sat, 1 Nov 2014 17:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3oOQNH9EQXv for ; Sat, 1 Nov 2014 17:45:52 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2BB1A1BCA for ; Sat, 1 Nov 2014 17:45:51 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id v1so759340yhn.12 for ; Sat, 01 Nov 2014 17:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G/JhGFd4x2qWvEQ3y6H3t9cDqEgsIxhiBMy0uCMxOEg=; b=kJWM8fbJB1/uDVfcmiLCsietGqwFzlawK5Ogm49x5psd/6oknwqmAN34eQvGWPzgYp nQb8O+x+xAsC5VHV0Xp/+QyvuJeONSuGkT1K8KOuTfvPDMj3s5bIXa7Q3cehb6Y7QH4Y gOXbFnBBZ/yOHnYJsnNp9Uo6+zM/DqDH5E9bnpMdNU7FhFmYc0m630YXM2H4rXxq/Mo/ +l7HSmdNddhCRY2AbF/XHZqPYGncSy32tRjskoVCZFzQZgLBvWchrELuwpCpkziGB7yA k5+Wt2wzbbCmsZwROaELRmR0aWxZwYbv2Na38mZJzBrpNhfXlwkZwQFvvV8CAO6+Tbff chlA== MIME-Version: 1.0 X-Received: by 10.236.41.71 with SMTP id g47mr21966360yhb.90.1414889151112; Sat, 01 Nov 2014 17:45:51 -0700 (PDT) Received: by 10.170.195.203 with HTTP; Sat, 1 Nov 2014 17:45:51 -0700 (PDT) In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> Date: Sat, 1 Nov 2014 17:45:51 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5cQxbjeXzR9mtIgdhoX2c8SJlLM Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 00:45:54 -0000 On Sat, Nov 1, 2014 at 4:22 PM, Eric Rescorla wrote: > > > On Sat, Nov 1, 2014 at 3:22 PM, Watson Ladd wrote: >> >> On Sat, Nov 1, 2014 at 2:45 PM, Eric Rescorla wrote: >> > >> > >> > On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd >> > wrote: >> >> >> >> On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla wrote: >> >> > >> >> > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara >> >> > wrote: >> >> >> >> >> >> >> >> >> >> However, this poses some challenges with respect to revocation. From >> >> >> what >> >> >> I >> >> >> understand, the parameters are intended to have limited lifetime >> >> >> (much >> >> >> shorter than EE certificates). >> >> >> >> >> >> The reason this is problematic is that one can't really rely on >> >> >> clocks: >> >> >> - Even if you happen to have sub-second accurate clock, a lot of >> >> >> computers >> >> >> don't. >> >> >> - The time protocols often aren't secured, allowing attacker to play >> >> >> tricks >> >> >> with endpoint time. >> >> > >> >> > >> >> > We're already starting to have that problem because of a desire to >> >> > move >> >> > to >> >> > OCSP >> >> > stapling, which, with staple, effectively gives the server a >> >> > credential >> >> > which is >> >> > valid only within a fairly narrow window. However, I think you're >> >> > right >> >> > that >> >> > this >> >> > probably limits the range of lifetimes you can use with these signed >> >> > DH >> >> > keys. >> >> >> >> That's not the problem Illari was talking about: It's not that g^s has >> >> limited lifetime, but that there is no way to know that the lifetime >> >> is expired, so it has long lifetime. NTP is not secure, so we have to >> >> deal with bad clocks. In the case of certificates, this is usually not >> >> so bad as the lifetimes are long. It might not be a problem for this, >> >> as we can occasionally resign, keep s in memory and not be worse off >> >> than today, or say that TLS clients need trusted clocks to avoid >> >> compromise when s is revealed. >> > >> > >> > Yes. I understand this. My point is that OCSP Stapling is effectively >> > like short-lived certificates (and short-lived DHE shares) in that >> > you have a credential which is valid for a relatively short period of >> > time and which therefore requires that therefore requires tight >> > clock synchronization. And since we're moving towards OCSP >> > stapling and short-lived certs, we've got this problem in any case. >> >> Ah, I was thinking of a different problem with OCSP stapling, which is >> getting the response to staple periodically, and when you don't... >> >> Thinking about it more, I think I don't understand this. X509 >> certificates have expiration dates. Doesn't that mean the client needs >> a synchronized clock already? > > > Yes, it does. > > >> >> Why does the duration of the validity of >> the response affect the existence of this issue? > > > My argument here is that clients have some ability to sanity check > network time information, and so it's not necessarily like the attacker > can set the time to anything (I don't know how NTP clients currently > work). So an attacker who can only move the clock by a day or > two is going to of course be more effective attacking credentials > with a short time window than with a long time window > (though arguably that's because the latter is less secure to start > out with). > > Does that make sense? It does make sense, but it's wrong. First, it's not clear that NTP works the way you think it does: my laptop has no problem imposing a 15-hour jump on the system clock when connecting to a timeserver after I fiddled with the clock. I'll try some more tests to be sure that is what is going on, but I see no description of such sanity checks in the OpenBSD manpage, or OpenNTPD.org documentation, and haven't found it in the OpenNTPD code yet. I've found documents indicating that OpenNTPD does change the time massively on boot, namely presentations by the developers. I've also had adventures when dual-booting where the RTC would get set strangely on reboots, and ntp would straighten it out. The protection that does exist on BSD systems is that the clock can only be set backwards by adjtime(2) when in secure modes greater than 1. I don't think this used as much as it should be. Secondly, suppose as an attacker I can twist time by a certain amount d. This means any credential valid at any time in the range [t-d, t+d] that I steal can be used at time t. The length of time the credential is valid for doesn't enter into this analysis: while the attacker would only be interested in doing this for short validity credentials, the longer validity credentials are still useful if stolen. I don't need to play any NTP games if I get the cert. So to the extent that short-lived credentials work in the sense that an attacker can only use them until a certain time in the future if they extract them, it depends entirely on the value of d, which currently is unbounded. Long-term credentials are just going to work until they expire, and then plus d, just as short-term credentials do. But it's more interesting in the case of short-term credentials. Maybe being able to screw with the clock isn't a realistic assumption, or we've already ruled it out. Certainly existing revocation mechanisms can also be avoided in similar ways, under similar conditions, and protecting system time isn't that hard conceptually: NTP is massive overkill for most systems, being designed to attain accuracies far beyond the few seconds a week computers can attain on their own. So I don't think this security issue necessarily dooms this proposal. Of course, this is all moot if RFC 5906 is supported. However, it seems that most NTP servers the public can use do not support autokey: the best source for this is a debian bug where a member of the pool.ntp.org team explains they can't set up an authenticated pool. Sincerely, Watson Ladd > > -Ekr > > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Nov 2 00:32:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C47D1A7003 for ; Sun, 2 Nov 2014 00:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA_epd7hfsMJ for ; Sun, 2 Nov 2014 00:32:48 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAB11A6FF3 for ; Sun, 2 Nov 2014 00:32:47 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA27WhTH009598; Sun, 2 Nov 2014 02:32:43 -0500 Date: Sun, 2 Nov 2014 02:32:42 -0500 (EST) From: Nikos Mavrogiannopoulos To: c kahlo Message-ID: <222598372.3223019.1414913562380.JavaMail.zimbra@redhat.com> In-Reply-To: <5455577f.e402c20a.6dee.2253@mx.google.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> <5455577f.e402c20a.6dee.2253@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: rfc7366: is encrypt-then-mac implemented? Thread-Index: Ac/2G2jPupPc5GybTa6yRfBBtLAZ1wAAm4eg61IkWm8= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T5zRa5NBeJvMp_DgVqkynovG0Fk Cc: Manuel =?utf-8?Q?P=C3=A9gouri=C3=A9-Gonnard?= , tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 07:32:54 -0000 ----- Original Message ----- > Yes, SSLv3 is explicitly unsupported. As there is no handshake back- > ward compatibility with SSLv3 "03 00" is forbidden at the record level. That's pretty pointless and harms interoperability. With that you are not forbidding SSL 3.0, but all implementations which use 3.0 in the record version for client hello. That was widely used as a mitigation in the past for other broken servers that only accepted SSL 3.0 version field. In any case, the version in TLS record indicates the record format, not the negotiated version, which is present in the client hello handshake packet. The last two paragraphs of http://tools.ietf.org/html/rfc5246#appendix-E.1 make that clear: "Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello.". regards, Nikos From nobody Sun Nov 2 09:30:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6E91A8983 for ; Sun, 2 Nov 2014 09:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F7kYg9SSRr3 for ; Sun, 2 Nov 2014 09:30:53 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59A31A896D for ; Sun, 2 Nov 2014 09:30:53 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id e131so7799435oig.16 for ; Sun, 02 Nov 2014 09:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7JAxtqDo/iclym43OaH5gy9PiE3AbNdkzrTCb8OolWs=; b=I8+qmf9vCDCekEICoDAEm1m459oyGrhBXXeDK0B8Dh+fxkGMZuYEVAGFFaMvbdk3Tv /fsK8rix3L/AvqX+SXuEcgjcoj/oS068xGytDMBBkzQ4VTRipoeYlgQgCmvXGq4jsHi7 0Q1DJwiJ/6P0V7PuTm3eBFsRFEZYeIGge617Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7JAxtqDo/iclym43OaH5gy9PiE3AbNdkzrTCb8OolWs=; b=K/a/z7dBem7iXtSNPgeCH8GJvWpzrWZqgPAKtD9+nh/WZ7AWw0zM67D8DAqADenyoc aVhbCDoVmoMpjTRgTxdCNWLzQnVNYkL0unC4v3Gwe6F7ZiA6Wl27LmbDFe665NNBgZZX i5SNqhBH4H4toFjw5lp4vz7KRT19LcWLqt/h1I47WvSnRlawufssj4bhJCEK1kOvd84f /lT7uEpj8vJqPSQnYBG+2blfdYQSdCogCfZyt+ap06lMbechVjsAwKLsDADBBxnC1Njj l8BqLHZKyICYaG5FZXyJiDUcKcAXHY5tc9/Nshez1PK7Ta93LWhZyZL6sfAIwJg202Fx AB8g== X-Gm-Message-State: ALoCoQlkGUFU89nipFeDM/2BwaJlQPRmvwzIzcmxNSqrrAzasAsKGQnccAo3pw4QgBN3hyieXN3z MIME-Version: 1.0 X-Received: by 10.60.160.33 with SMTP id xh1mr2343052oeb.57.1414949452887; Sun, 02 Nov 2014 09:30:52 -0800 (PST) Received: by 10.76.84.65 with HTTP; Sun, 2 Nov 2014 09:30:52 -0800 (PST) X-Originating-IP: [82.224.193.99] In-Reply-To: <20141006131625.5451.13842.idtracker@ietfa.amsl.com> References: <20141006131625.5451.13842.idtracker@ietfa.amsl.com> Date: Sun, 2 Nov 2014 18:30:52 +0100 Message-ID: From: Alfredo Pironti To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e010d8d8483ce4d0506e39721 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UZVNl2meucG1g6lF8P4MMsmF3mc Subject: Re: [TLS] I-D Action: draft-ietf-tls-session-hash-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 17:30:55 -0000 --089e010d8d8483ce4d0506e39721 Content-Type: text/plain; charset=UTF-8 Dear list, I've updated the session-hash and extended master secret draft, according to the feedback received on this mailing list and at the latest interim meeting in Paris. With respect to the previous version, I've made the following changes: - removed support for SSL 3.0 - populated the "security considerations" section - minor editorial improvements As the I-D submission tool is unavailable now, I've made a copy of draft-ietf-tls-session-hash-03.txt available at [1]. The link will become invalid as soon as the draft will be pushed on the IETF servers. Best, Alfredo [1] https://owncloud.pironti.eu/public.php?service=files&t=ffff684c90daea4a7b2327647e000d75&download On Mon, Oct 6, 2014 at 3:16 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > Title : Transport Layer Security (TLS) Session Hash and > Extended Master Secret Extension > Authors : Karthikeyan Bhargavan > Antoine Delignat-Lavaud > Alfredo Pironti > Adam Langley > Marsh Ray > Filename : draft-ietf-tls-session-hash-02.txt > Pages : 9 > Date : 2014-10-06 > > Abstract: > The Transport Layer Security (TLS) master secret is not > cryptographically bound to important session parameters such as the > client and server identities. Consequently, it is possible for an > active attacker to set up two sessions, one with a client and another > with a server, such that the master secrets on the two sessions are > the same. Thereafter, any mechanism that relies on the master secret > for authentication, including session resumption, becomes vulnerable > to a man-in-the-middle attack, where the attacker can simply forward > messages back and forth between the client and server. This > specification defines a TLS extension that contextually binds the > master secret to a log of the full handshake that computes it, thus > preventing such attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-session-hash-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e010d8d8483ce4d0506e39721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear list,

I've updated th= e session-hash and extended master secret draft, according to the feedback = received on this mailing list and at the latest interim meeting in Paris. W= ith respect to the previous version, I've made the following changes:
- removed support for SSL 3.0
- populated th= e "security considerations" section
- minor editori= al improvements

As the I-D submission tool is unava= ilable now, I've made a copy of draft-ietf-tls-session-hash-03.txt avai= lable at [1]. The link will become invalid as soon as the draft will be pus= hed on the IETF servers.

Best,
Alfredo

On Mon, Oct 6, 2014 at 3:16 PM, <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Transport Layer Security Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Transport Layer Security (TLS) Session Hash and Extended Master Secret Ext= ension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Kart= hikeyan Bhargavan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Antoine Delignat-Lavaud
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alfredo Pironti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Adam Langley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marsh Ray
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-session-hash-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-06

Abstract:
=C2=A0 =C2=A0The Transport Layer Security (TLS) master secret is not
=C2=A0 =C2=A0cryptographically bound to important session parameters such a= s the
=C2=A0 =C2=A0client and server identities.=C2=A0 Consequently, it is possib= le for an
=C2=A0 =C2=A0active attacker to set up two sessions, one with a client and = another
=C2=A0 =C2=A0with a server, such that the master secrets on the two session= s are
=C2=A0 =C2=A0the same.=C2=A0 Thereafter, any mechanism that relies on the m= aster secret
=C2=A0 =C2=A0for authentication, including session resumption, becomes vuln= erable
=C2=A0 =C2=A0to a man-in-the-middle attack, where the attacker can simply f= orward
=C2=A0 =C2=A0messages back and forth between the client and server.=C2=A0 T= his
=C2=A0 =C2=A0specification defines a TLS extension that contextually binds = the
=C2=A0 =C2=A0master secret to a log of the full handshake that computes it,= thus
=C2=A0 =C2=A0preventing such attacks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-session-ha= sh/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-session-hash-02<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-sess= ion-hash-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--089e010d8d8483ce4d0506e39721-- From nobody Sun Nov 2 13:32:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF441A1A29 for ; Sun, 2 Nov 2014 13:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulMMSUMlYgtc for ; Sun, 2 Nov 2014 13:32:20 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA1C1A0410 for ; Sun, 2 Nov 2014 13:32:20 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id d1so4958949wiv.15 for ; Sun, 02 Nov 2014 13:32:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:cc:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=tY4C/s04Nve+tijRdOxzkEnfiNbla6jkg61zeraCNmg=; b=RB1K1SAiTLij7s7TsfpzVDiIkXATfQ2DGh/KSaDaoHa1OInC8zoEaeG5rh6L1e+OF3 vRjDxhOLcHbyDYRjrxfFeMYysP6kJEU5kjEZYvlbHYvzO6v+3wLz4l6QjiX8IsUSOQTm hn2gEe3j5d/9NkMc+pcnyzJ7/VUKosW1Lbx3dvx//+P1hNfhtzLoKD9hr+CXPR7tjpp/ gFb9G5qO6VvNDzSW+JfjgCq19hxysv8h5yLSwBfY3CsZWnDh6WriYFEy7W/ZLaVBWqqq 5tXzgHt3VmkEYwteW9dtAtSKwS+O4AC3nYjVrGrIRhHgCz/zhio90cdVGIv0luuImw/d eN7w== X-Gm-Message-State: ALoCoQnqh7lBZrofHewTDQXG9fRVTE0ZNe/hR/SIJ6vjfK+JsUwUIoJJhi0dv+o3HV9KWRx/T9mX X-Received: by 10.180.12.136 with SMTP id y8mr11897670wib.73.1414963938913; Sun, 02 Nov 2014 13:32:18 -0800 (PST) Received: from THINK2 (cable-158-181-87-250.cust.telecolumbus.net. [158.181.87.250]) by mx.google.com with ESMTPSA id n4sm6499758wiz.17.2014.11.02.13.32.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Nov 2014 13:32:18 -0800 (PST) Message-ID: <5456a2e2.4456b40a.3bc8.25c1@mx.google.com> X-Google-Original-Message-ID: <002101cff6e4$7c751ce0$755f56a0$@kahlo@ageto.net> From: "Christian Kahlo" To: "'Nikos Mavrogiannopoulos'" References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> <5455577f.e402c20a.6dee.2253@mx.google.com> <222598372.3223019.1414913562380.JavaMail.zimbra@redhat.com> In-Reply-To: <222598372.3223019.1414913562380.JavaMail.zimbra@redhat.com> Date: Sun, 2 Nov 2014 22:32:20 +0100 Organization: AGETO Innovation GmbH MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/2G2jPupPc5GybTa6yRfBBtLAZ1wAAm4eg61IkWm/rUJe4sA== Content-Language: de Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Brs1tf3FV8FIrhU6ijerUemeflY Cc: =?UTF-8?Q?'Manuel_P=C3=A9gouri=C3=A9-Gonnard'?= , tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: c.kahlo@ageto.net List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 21:32:22 -0000 > ----- Original Message ----- > > Yes, SSLv3 is explicitly unsupported. As there is no handshake back- > > ward compatibility with SSLv3 "03 00" is forbidden at the record > level. > > That's pretty pointless and harms interoperability. With that you are > not forbidding SSL 3.0, but all implementations which use 3.0 in the > record version for client hello. That was widely used as a mitigation > in the past for other broken servers that only accepted SSL 3.0 version > field. In fact there are very few and rare clients using "03 00" in the record version field. The only clients I know of are some custom probers. > In any case, the version in TLS record indicates the record format, not > the negotiated version, which is present in the client hello handshake > packet. > > The last two paragraphs of http://tools.ietf.org/html/rfc5246#appendix- > E.1 > make that clear: "Thus, TLS servers compliant with this specification > MUST accept any value {03,XX} as the record layer version number for > ClientHello.". OK. Fixed. Checked In. Deployed. From nobody Sun Nov 2 13:53:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED91A1A5E for ; Sun, 2 Nov 2014 13:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jQEP-_iCwD7 for ; Sun, 2 Nov 2014 13:53:14 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D4D1A1A54 for ; Sun, 2 Nov 2014 13:53:14 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id x12so9889571wgg.32 for ; Sun, 02 Nov 2014 13:53:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:cc:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=jNFnbI2eYBIGk/deThz9JEynOmylE6ZcIufKDUEUr4Y=; b=imuA1JiNYStsuI1Dy/FMM/1n7w3se9IkJ0quNtD7yryrFfA5Qj/h4mAUt1pzf0t9sv ZSHF5eb+gXDcLX8JWRFpk/vNL5U7FERpsQ6reIpATmVbEG5JFGEmQTt5G510N71mwB20 ftuCsBwMZjRsA2JsCJUH8aDrHxoek8YLgx7KARKbs+iEDXlvhIWLqH47Fg3HlC22MG51 hFiQeZg8wdxssu47vcCJDyHD7B8+/DEpnnNQM5YhbNhwI7rRm+68+syOLVHqEHSO14R+ EIxQWdRzMVEKZEZFKbYR16362JwZEN9xkeJdpI7ZC2os3jXIprLIhJJC3bUPM+uFRi4C MXCw== X-Gm-Message-State: ALoCoQngA9MYLqGCRwizEOkT7lX9HqaEtpLIbNcusvTs2wlLn7/wzYuW/lsr8Qr0QaBpmA0+o3mD X-Received: by 10.180.212.42 with SMTP id nh10mr11828517wic.52.1414965193090; Sun, 02 Nov 2014 13:53:13 -0800 (PST) Received: from THINK2 (cable-158-181-87-250.cust.telecolumbus.net. [158.181.87.250]) by mx.google.com with ESMTPSA id f9sm19719622wjw.31.2014.11.02.13.53.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Nov 2014 13:53:12 -0800 (PST) Message-ID: <5456a7c8.e94bc20a.62d5.25f2@mx.google.com> X-Google-Original-Message-ID: <002301cff6e7$67fb1460$37f13d20$@kahlo@ageto.net> From: "Christian Kahlo" To: , "'Nikos Mavrogiannopoulos'" References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> <5455577f.e402c20a.6dee.2253@mx.google.com> <222598372.3223019.1414913562380.JavaMail.zimbra@redhat.com> In-Reply-To: Date: Sun, 2 Nov 2014 22:53:14 +0100 Organization: AGETO Innovation GmbH MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/2G2jPupPc5GybTa6yRfBBtLAZ1wAAm4eg61IkWm/rUJe4sNahKdVg Content-Language: de Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TY9_Ljz2DmZI1VDHFVge8_yqjeg Cc: =?UTF-8?Q?'Manuel_P=C3=A9gouri=C3=A9-Gonnard'?= Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: c.kahlo@ageto.net List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 21:53:16 -0000 > > The last two paragraphs of > http://tools.ietf.org/html/rfc5246#appendix- > > E.1 > > make that clear: "Thus, TLS servers compliant with this specification > > MUST accept any value {03,XX} as the record layer version number for > > ClientHello.". > > OK. Fixed. Checked In. Deployed. By the way this is an operational system. The server is PFS-only with ECDSA_RSA activated. RC4 and Camellia are not supported and 3DES is deactivated. TLS1.0 is supported but not enabled. From nobody Sun Nov 2 14:05:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E121A1A39 for ; Sun, 2 Nov 2014 14:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.023 X-Spam-Level: ** X-Spam-Status: No, score=2.023 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvbJGFYNcLrg for ; Sun, 2 Nov 2014 14:05:35 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7A71A1A28 for ; Sun, 2 Nov 2014 14:05:34 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n15so440058lbi.20 for ; Sun, 02 Nov 2014 14:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cBI7hV6nBR4rpZh+uGYCBR3LEVxPuYK5zx/UI44VU4c=; b=ab60Thpia/b7L7+yWEuFiO90kPzIEvOjouBAhU9N1b/pJAYjgviHHaAmCB3o6SBeJQ G/3/GA2C91lMG5UXYdOua0Tyq8ZbYMu+Qh7kgTokZWU+Gy4Srpl3nZQkcF0p2kIOk6e5 5ZbALg+JvT4u1RS//ST2eJHEKfF9jHhC0X0IKCpC08qiDCHpW/W4DmBmPmLnkveHZSRA GJOtmeoekg4dxiVRbwf+EAq77yTaEl1mxdEkKUz10KGqTXyozTVeKz+C9rOes2a+5kHP Hn1f/9Y3CrdJAQLyrFIgdC0CJWhvagogw8HBzdReNQRGVI3JrCPz2KrJ9x9xsnFxjkho 5BVA== X-Received: by 10.152.7.7 with SMTP id f7mr45509486laa.57.1414965932763; Sun, 02 Nov 2014 14:05:32 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Sun, 2 Nov 2014 14:05:02 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Mon, 3 Nov 2014 00:05:02 +0200 X-Google-Sender-Auth: UfZlLn6J55XhocAocQDqkzB42Tc Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c2870acab0060506e76d12 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iX8nOr-hzN_L12xU94Pu1lNBZjc Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 22:05:39 -0000 --001a11c2870acab0060506e76d12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable These are good questions as they point to some of the choices we need to consider before defining the actual key derivation mechanisms in the protocol. Below are some responses. On Sat, Nov 1, 2014 at 3:44 AM, Eric Rescorla wrote: > Hugo, > > Thanks for writing this up. I'm still digesting this, but I had a few > questions. > > 1. In the interim, I believe you suggested MAC of the transcript under > g^{xs} to authenticate g^y. This is fairly analogous to CertificateVerify= , > except using a MAC rather than a signature. In the current design, you > instead generate a combined key from g^{xs] and g^{xy}. Are there > advantages to this design or is it just a matter of style? > =E2=80=8BYour understanding of the MAC (in the Finished message) as replaci= ng the functionality of the signature in CertificateVerify is correct. Also correct is that we could use g^{xs} for such authentication and derive the session key(s) directly from g^{xy}. On the other hand, deriving the key from both g^{xs} and g^{xy} has the advantage that an attacker that learns the ephemeral exponent y cannot compute the session key; for that it needs to find both y and s. It also has the property that you get (implicit) authentication even without the ServerFinished message but this is not too significant in our case given that we mandate the Finished message. One additional consideration in chosing the key derivation is the number of exponentiations it requires. One could actually combine g^{xs] and g^{xy} without requiring two exponentiations by using a HMQV-like key derivation. However, this does not apply to our case where you either need to explicitl= y compute g^{xs} (for encrypting ClientData in the 0-RTT case) or explicitly compute g^{xy} (for encrypting ServerCertificate in the 1-RTT case). =E2=80=8B > > 2. I'm thinking about how to adapt this to PSK+PFS modes (i.e., > where you want the PSK for authentication but you want to do > a DHE exchange for PFS). In the design you propose, it seems > like the analogous thing to do would be to treat the PSK like > g^{xy}? Does this interact at all with whether to mix the keys > or use a MAC? > =E2=80=8BIndeed, this is one of the conceptual advantages of this design. You can replace g^{xs} (not g^{xy}) with the PSK shared between client and server. It is not hard to define the authentication and key derivation mechanisms so that they apply equally to the non-PSK and PSK settings. =E2=80=8B > > 3. WRT client auth, I think we've generally decided that the client's > certificate ought to be encrypted. Given that, I wonder if it would be > easier > for the client to just do a digital signature over the transcript and/or > an authenticator derived from the secret. Generally, the additional > cost of the RSA signature isn't a huge problem for most clients and > those which do should be able to quickly move to EC-based keys. > > =E2=80=8BI don't see the advantage of signatures in this case. It is possib= le to design a hybrid protocol with signature authentication at the client side and static DH at the server but I wouldn't do that without a clear advantage over the mor= e uniform approach using static DH on both sides. In any case, doing static DH at the client should not be a problem, it is already doing it to authenticate the server and compute keys. Hugo =E2=80=8B > Thanks, > -Ekr > > > On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk > wrote: > >> During the TLS interim meeting of last week (Oct 22 2014) I suggested >> that TLS >> 1.3 should abandon signature-based authentication (other than for >> certificates) >> and be based solely on a combination of ephemeral Diffie-Hellman for PFS >> and >> static Diffie-Hellman for authentication. This has multiple benefits >> including >> major performance gain (by replacing the per-handshake RSA signature by >> the >> server with a much cheaper elliptic curve exponentiation), compatibility >> with >> the mechanisms required for forward secrecy, natural accommodation of a >> 0-RTT >> option, and a simple extension without signatures for client >> authentication. >> >> Below I present a schematic representation of the proposed protocol >> referred >> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. >> The presentation is sketchy and omits the exact procedure for key >> derivation. >> The latter is a crucial component for the security of the protocol, but >> before getting into these details we want to get a sense of whether the >> WG is >> interested in this approach. In the meantime, Hoeteck Wee and myself are >> working on the details of the protocol and the security proof. >> >> We describe a setting with optional 0-RTT and server-only authentication= . >> Client authentication can be added as a further option or as an extensio= n >> (similar to the current 1.3 proposal) - see below. >> >> NOTATION AND TERMINOLOGY: >> >> [K] symbols represent pointers to key material whose exact derivation is >> not >> included here except for specifying the basic DH values from which the >> key is >> derived (actual derivation will include further information similar to t= he >> extended hash mechanisms or SessionHash proposal considered for 1.3). >> Asterisks represent optional fields that the WG can decide to leave as >> optional, >> mandatory, or simply remove without changing the core cryptographic >> security of >> the protocol. All references to encryption mean "authenticated encryptio= n" >> using the encrypt-then-mac paradigm (or any other secure AEAD >> mechanism). >> >> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the >> parties. >> All the public key and Diffie-Hellman operations are assumed to happen >> over a >> cyclic group with generator g of order q (typically implemented by an >> elliptic >> curve group). We use multiplicative notation where ^ denotes >> exponentiation as >> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), >> etc. >> Omitted from the current high level description is a mechanism for >> testing group >> membership of DH values or cofactor exponentiation (the specific mechani= sm >> depends on the group type and is typically very efficient for elliptic >> curves). >> >> SERVER PUBLIC KEY AND CERTIFICATE: >> >> The server has a long term private-public key pair denoted by (s,g^s) >> where >> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys")= . >> We assume that the server has a certificate that includes the server's >> public >> key g^s and a CA-signed binding of this key to the server's identity. >> We discuss the implementation of such certificates below. >> >> PROTOCOL OPTLS: >> >> ClientHello >> ClientKeyShare >> ClientData* [K0] --------> >> ServerHello >> ServerKeyShare >> ServerCertificate* [K1] >> ServerFinished [K2] >> <-------- ServerData* [K2] >> ClientFinished* [K2] --------> >> >> >> Protected Application Data [K3] >> <-------> >> >> >> >> 1-RTT CASE: >> >> The basic 1-RTT case omits the ClientData* field. It includes a >> ClientKeyShare >> g^x and a ServerKeyShare g^y and an optional (encrypted) server >> certificate. >> If the certificate is sent (it can be omitted if the client has indicate= d >> that >> it knows the server key as in the case in the 0-RTT scenario) and is >> encrypted, >> the encryption key K1 is derived from g^{xy}. >> >> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is >> used to >> authenticate-encrypt the ServerFinished and ClientFinished messages (whi= ch >> include a hash of the previous traffic) and to encrypt data from the >> server if >> such data is piggybacked to the second message. >> >> Key K3 is the "application key" used to derive key material for >> protection of >> application data. This key material will include (directional) >> Authenticated >> Encryption keys and, possibly, keys for derivation of further re-key >> material. >> K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its >> derivation >> will be different than K2, e.g., using a separating key expansion >> technique. >> >> SUPPORT FOR 0-RTT: >> >> The above protocol is compatible with a 0-RTT protocol such as QUIC. In >> this >> case, the client is assumed to have information about the server's publi= c >> key >> and other security parameters. The server is assumed to have some >> mechanism in >> place for detecting replay (e.g., via timestamps, stored client nonces, >> etc.). >> The resulting protocol is as described above where the ClientData field >> is sent >> encrypted under key K0 derived from g^{xs}. >> The rest of the protocol is identical to the above. >> Note: In this case, ServerCertificate is not sent as the client had to >> know >> the server's public key before the first message (one can imagine a >> setting >> where the server may send a different certificate in the second message = - >> if >> desired, this can be accommodated too as an option or extension). >> >> CLIENT AUTHENTICATION: >> >> Client authentication can be supported via an option or extension. It >> would >> include a client certificate for a static DH key g^c sent in the third >> message >> (the certificate can be encrypted under key K2 to provide client's >> identity >> protection). In this case, the key for computing the ClientFinished >> message and >> the application key K3 would be derived from a combination of the values >> g^xy, >> g^xs, g^yc (and possibly also g^{cs}). >> >> NOTES: >> >> Note on Finished messages: The above spec sets ServerFinished as >> mandatory and >> ClientFinished as optional. The latter option is needed for a 1-RTT >> protocol. >> In principle, both Finished messages could be omitted and still obtain >> security >> via implicit authentication (assuming the inputs to key derivation are >> chosen >> appropriately). But given the advantages of ServerFinished for providing >> explicit authentication, key confirmation, and active forward secrecy (s= ee >> below), it seems advisable to always include it. Including ClientFinishe= d >> provides key confirmation from client and also explicit client >> authentication >> when client certificate is included. ClientFinished also provides >> Universal >> Composable (UC) security (this is a result of the Canetti-Krawczyk proof >> that >> CK security implies UC security when a client confirmation step is >> included). >> >> Note on certificates: Since in current practice servers hold certificate= s >> for >> RSA signature keys rather than for static DH keys, the certificate field >> in the >> above protocol will be implemented by a pair consisting of (i) the >> server's RSA >> signature certificate and (ii) the server's signature using this RSA key >> on the >> server's static public DH key g^s. The latter signature by the server is >> performed only when a new static DH key is created (how often this >> happens and >> how many such keys are created is completely up to the server - it has t= he >> advantage that these keys can be changed often to increase security >> against >> leaked keys). This use of RSA also enjoys the high efficiency of RSA >> verification for the client. >> The handling of Client certificates would be similar. >> >> Note on forward security (a.k.a. as PFS for Perfect Forward Security): >> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys. >> The meaning of PFS is that an attacker that finds the (long-term) static >> private keys of the parties cannot compromise past session keys. Without >> the >> ServerFinished message the above protocol ensures forward secrecy agains= t >> passive attackers (i.e., for sessions where the attacker did not choose >> g^y). >> With ServerFinished, PFS holds also against active attackers. A similar >> consideration applies to ClientFinished. >> >> Client certificates in the first message: We note that in cases where >> client >> certificates can be sent in the clear in the first message of the >> protocol, one >> can provide PFS and mutual authentication in a 1-RTT at essentially the >> same >> cost of an unauthenticated DH exchange (i.e., a cost of little more than >> two >> exponentiations). In such a setting one can also obtain mutual >> authentication in >> a 0-RTT protocol (with forward secrecy with respect to the client's >> key). >> These options, however, require HMQV-like mechanisms and may raise IP >> issues (this >> can be investigated further if the WG is interested). >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --001a11c2870acab0060506e76d12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
These are good questions as they point to some = of the choices we need to
consider before defining the actual key deriva= tion mechanisms in the protocol.
Below are some responses.

On Sat, Nov 1, 2014 a= t 3:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Hugo,

Thanks for writing this up. I'm still digesting this, but I had a few=
questions.

1. In the interim, I believe= you suggested MAC of the transcript under
g^{xs} to authenticate= g^y. This is fairly analogous to CertificateVerify,
except using= a MAC rather than a signature. In the current design, you
instea= d generate a combined key from g^{xs] and g^{xy}. Are there
advan= tages to this design or is it just a matter of style?

=E2=80=8BYour understanding of the MA= C (in the Finished message) as replacing the
functionality of the signat= ure in CertificateVerify is correct. Also correct is
that we could use g= ^{xs} for such authentication and derive the session key(s)
directly fro= m g^{xy}. On the other hand, deriving the key from both g^{xs} and
g^{xy= } has the advantage that an attacker that learns the ephemeral exponent ycannot compute the session key; for that it needs to find both y and s. <= br>It also has the property that you get (implicit) authentication even wit= hout the
ServerFinished message but this is not too significant in our c= ase given that we
mandate the Finished message.

One additional c= onsideration in chosing the key derivation is the number of
exponentiati= ons it requires. One could actually combine g^{xs] and g^{xy}
without re= quiring two exponentiations by using a HMQV-like key derivation.
However= , this does not apply to our case where you either need to explicitly
co= mpute g^{xs} (for encrypting ClientData in the 0-RTT case) or explicitlycompute g^{xy} (for encrypting ServerCertificate in the 1-RTT case).
= =E2=80=8B
=C2=A0

2. I'm thinking about how t= o adapt this to PSK+PFS modes (i.e.,
where you want the PSK for a= uthentication but you want to do
a DHE exchange for PFS). In the = design you propose, it seems
like the analogous thing to do would= be to treat the PSK like
g^{xy}? Does this interact at all with = whether to mix the keys
or use a MAC?

=E2=80=8BIndeed, this is one of the c= onceptual advantages of this design.
You can replace g^{xs} (not g^{xy}= ) with the PSK shared between client and
server. It is not hard to defin= e the authentication and key derivation
mechanisms so that they apply eq= ually to the non-PSK and PSK settings.
=E2=80=8B
=C2=A0
=C2= =A0=C2=A0
3. WRT client auth, I think we've generally d= ecided that the client's
certificate ought to be encrypte= d. Given that, I wonder if it would be easier
for the client to j= ust do a digital signature over the transcript and/or
an authenti= cator derived from the secret. Generally, the additional
cost of = the RSA signature isn't a huge problem for most clients and
t= hose which do should be able to quickly move to EC-based keys.

=E2=80=8BI do= n't see the advantage of signatures in this case. It is possible to des= ign a
hybrid protocol with signature authentication at the client side a= nd static DH
at the server but I wouldn't do that without a clear ad= vantage over the more
uniform approach using static DH on both sides. In= any case, doing static DH at
the client should not be a problem, it is = already doing it to authenticate the
server and compute keys.

Hugo
=E2=80=8B
=C2=A0
Tha= nks,
-Ekr


On Fri, Oct 31, 201= 4 at 5:54 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wr= ote:
=
During the TLS interim meeting of last week (Oct 22 2= 014) I suggested that TLS
1.3 should abandon signature-based authenticat= ion (other than for certificates)
and be based solely on a combination o= f ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authent= ication. This has multiple benefits including
major performance gain (by= replacing the per-handshake RSA signature by the
server with a much che= aper elliptic curve exponentiation), compatibility with
the mechanisms r= equired for forward secrecy, natural accommodation of a 0-RTT
option, an= d a simple extension without signatures for client authentication.

B= elow I present a schematic representation of the proposed protocol referred=
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.= =C2=A0
The presentation is sketchy and omits the exact procedure for ke= y derivation.
The latter is a crucial component for the security of the = protocol, but
before getting into these details we want to get a sense = of whether the WG is
interested in this approach. In the meantime, Hoete= ck Wee and myself are
working on the details of the protocol and the se= curity proof.

We describe a setting with optional 0-RTT and server-o= nly authentication.
Client authentication can be added as a further opti= on or as an extension
(similar to the current 1.3 proposal) - see below.=

NOTATION AND TERMINOLOGY:

[K] symbols represent pointers to = key material whose exact derivation is not
included here except for spec= ifying the basic DH values from which the key is
derived (actual derivat= ion will include further information similar to the
extended hash mechan= isms or SessionHash proposal considered for 1.3).
Asterisks represent o= ptional fields that the WG can decide to leave as optional,
mandatory, o= r simply remove without changing the core cryptographic security of
the = protocol. All references to encryption mean "authenticated encryption&= quot;
using the encrypt-then-mac paradigm (or any other secure AEAD mech= anism).=C2=A0

KeyShare's represent ephemeral Diffie-Hellman val= ues exchanged by the parties.
All the public key and Diffie-Hellman oper= ations are assumed to happen over a
cyclic group with generator g of ord= er q (typically implemented by an elliptic
curve group). We use multipli= cative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here x= y denotes multiplication of the scalars x and y), etc.
Omitted from the = current high level description is a mechanism for testing group
membersh= ip of DH values or cofactor exponentiation (the specific mechanism
depen= ds on the group type and is typically very efficient for elliptic curves).<= br>
SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long term= private-public key pair denoted by (s,g^s) where
s is uniform random i= n [0..q-1] (we refer to s and g^s as "static keys").
We assum= e that the server has a certificate that includes the server's publickey g^s and a CA-signed binding of this key to the server's identity.=
We discuss the implementation of such certificates below.

PROTOC= OL OPTLS:

ClientHello
ClientKeyShare
ClientData* [K0]=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ServerHello=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerKeyShare=C2= =A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerCertificate* [K1]
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ServerFinished [K2]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ServerData* [K2]
ClientFinished* [K2]=C2=A0=C2= =A0 -------->


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Protected Application Data [K3]
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------->



1-RT= T CASE:

The basic 1-RTT case omits the ClientData* field. It include= s a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypt= ed) server certificate.
If the certificate is sent (it can be omitted i= f the client has indicated that
it knows the server key as in the case i= n the 0-RTT scenario) and is encrypted,
the encryption key K1 is derived= from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} a= nd g^{xy}. It is used to
authenticate-encrypt the ServerFinished and Cli= entFinished messages (which
include a hash of the previous traffic) and = to encrypt data from the server if
such data is piggybacked to the secon= d message.

Key K3 is the "application key" used to derive = key material for protection of
application data.=C2=A0 This key material= will include (directional) Authenticated
Encryption keys and, possibly,= keys for derivation of further re-key material.
K3 is computed from=C2= =A0 both g^{xs} and g^{xy} similarly to K2, but its derivation
will be d= ifferent than K2, e.g., using a separating key expansion technique.

= SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT pr= otocol such as QUIC. In this
case, the client is assumed to have informa= tion about the server's public key
and other security parameters. Th= e server is assumed to have some mechanism in
place for detecting replay= (e.g., via timestamps, stored client nonces, etc.).
The resulting proto= col is as described above where the ClientData field is sent
encrypted u= nder key K0 derived from g^{xs}.=C2=A0
The rest of the protocol is iden= tical to the above.=C2=A0
Note: In this case, ServerCertificate is not = sent as the client had to know
the server's public key before the fi= rst message (one can imagine a setting
where the server may send a diffe= rent certificate in the second message - if
desired, this can be accommo= dated too as an option or extension).

CLIENT AUTHENTICATION:
Client authentication can be supported via an option or extension. It woul= d
include a client certificate for a static DH key g^c sent in the third= message
(the certificate can be encrypted under key K2 to provide clie= nt's identity
protection). In this case, the key for computing the C= lientFinished message and
the application key K3 would be derived from a= combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}). =

NOTES:

Note on Finished messages: The above spec sets Server= Finished as mandatory and
ClientFinished as optional. The latter option = is needed for a 1-RTT protocol.
In principle, both Finished messages cou= ld be omitted and still obtain security
via implicit authentication (ass= uming the inputs to key derivation are chosen
appropriately). But given = the advantages of ServerFinished for providing
explicit authentication, = key confirmation, and active forward secrecy (see
below), it seems advis= able to always include it. Including ClientFinished
provides key confirm= ation from client and also explicit client authentication
when client ce= rtificate is included. ClientFinished also provides Universal
Composable= (UC) security (this is a result of the Canetti-Krawczyk proof that
CK = security implies UC security when a client confirmation step is included).= =C2=A0

Note on certificates: Since in current practice servers hold= certificates for
RSA signature keys rather than for static DH keys, the= certificate field in the
above protocol will be implemented by a pair c= onsisting of (i) the server's RSA
signature certificate and (ii) the= server's signature using this RSA key on the
server's static pu= blic DH key g^s. The latter signature by the server is
performed only wh= en a new static DH key is created (how often this happens and
how many s= uch keys are created is completely up to the server - it has the
advanta= ge that these keys can be changed often to increase security against
lea= ked keys). This use of RSA also enjoys the high efficiency of RSA
verifi= cation for the client.=C2=A0
The handling of Client certificates would = be similar.

Note on forward security (a.k.a. as PFS for Perfect Forw= ard Security):
PFS is provided by the (mandatory) use of ephemeral Diff= ie-Hellman keys.
The meaning of PFS is that an attacker that finds the (= long-term) static
private keys of the parties cannot compromise past ses= sion keys. Without the
ServerFinished message the above protocol ensures= forward secrecy against
passive attackers (i.e., for sessions where the= attacker did not choose g^y).
With ServerFinished, PFS holds also again= st active attackers.=C2=A0 A similar
consideration applies to ClientFini= shed.

Client certificates in the first message: We note that in case= s where client
certificates can be sent in the clear in the first messag= e of the protocol, one
can provide PFS and mutual authentication in a 1-= RTT at essentially the same
cost of an unauthenticated DH exchange (i.e.= , a cost of little more than two
exponentiations). In such a setting one= can also obtain mutual authentication in
a 0-RTT protocol (with forward= secrecy with respect to the client's key).=C2=A0
These options, ho= wever, require HMQV-like mechanisms and may raise IP issues (this
can be= investigated further if the WG is interested).


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls



--001a11c2870acab0060506e76d12-- From nobody Sun Nov 2 14:24:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D531A1A65 for ; Sun, 2 Nov 2014 14:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.223 X-Spam-Level: *** X-Spam-Status: No, score=3.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yw7FYYQ7YPy for ; Sun, 2 Nov 2014 14:24:46 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB131A1A8A for ; Sun, 2 Nov 2014 14:24:43 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id s18so4092425lam.28 for ; Sun, 02 Nov 2014 14:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Xs8MTiPXCppnsU26SeJ4raacwSpdYo7AeOjmeMTfA6Y=; b=u05/Z3rQ/ImHGIOAze1D3D+MjB0fTqK2+hXiqBd1o7i6g2mfPHNeN9QLNvrUT/pzJS mNfiQ0YcBvV9LIEvK0IlzczaS6Q+Tmdy3kZquIofVvPm+iWZ04wb2jLAzsqrvLqxRAyo qYCs4wOAOzNYo3tBY/rs5oX2u7DmEamLU2C7PTfHQEER1BauWN/koABXwpPDmM8Sz66c qL79El5GjLmERA6VFZB89FsGaXpFyJPA87qrIjfRN0Q3ayvuADVgjgPXjesZ/0MrSh/0 6ZQVTcQpfm18LSokop/E/fZJo1sv1w+6kzLDuqJrwg2UPgRpA8a82/9t7FZbL1WaFXJZ raIQ== X-Received: by 10.152.36.33 with SMTP id n1mr8042795laj.95.1414967081587; Sun, 02 Nov 2014 14:24:41 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Sun, 2 Nov 2014 14:24:11 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Mon, 3 Nov 2014 00:24:11 +0200 X-Google-Sender-Auth: hwIK6wjGIO1mMUYO_HzxOziHJ8s Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e0158b7ea445b900506e7b2b9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0UL-hmBA2EmxO7vpzH8vhpHZKyo Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 22:24:49 -0000 --089e0158b7ea445b900506e7b2b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 1, 2014 at 7:15 AM, Watson Ladd wrote: > Dear Hugo, > > There are some issues I can see: > > -Servers already supporting ECDSA certificates seem to not win. If I'm > understanding correctly, a server does three exponentiations, one of > which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The > servers that win are the ones with RSA certs. The only way to win vs > ECDSA is if DH only permits faster exponentiation, which it does, and > removing the ancillary junk in ECDSA. However, here we have two > variable base exponentiations after ephemeral reuse, as opposed to one > fixed, one variable, so there is a loss in performance on the same > group, made up for by removing inversions modulo the group order. > =E2=80=8BDon't forget that 0-RTT cannot be supported with a signature-based protocol so in that sense going to static DH is a win-win. As for performance, the gain with respect to (per-session) RSA signatures is huge. Comparison with ECDSA is indeed more complex as you point out, but static DH wins in comparison to the sign+verify performance and saves many complexities related to ECDSA optimization and (re)definition. It also avoids the vulnerability of Schnorr-like signatures where leakage of one ephemeral value compromises the long-term signature key. In contrast, static DH keys do not leak even if all ephemeral values are disclosed. Furthermore, one can design the protocol so that the disclosure of the ServerKeyShare does not even compromise the session key that uses this value. =E2=80=8B > > -I'm interested to see how different this is from ntor.[0] (To my eyes > it is very similar, which may make proving easier. OTOH, the 0-RTT and > 1-RTT options require care). Similarly, Michael Backes and coauthors > have proposed Ace[1], which does similar tricks to HMQV to reduce > server side cost, and provides a key exchange with some similar > properties. > =E2=80=8BI am not familiar with these works, but it is too early to compare= with other protocols as this one is yet not fully specified. Its details will be set when we get a better understanding of what is needed. One important element here is that we will be defining several key derivation operations and we will need to prove (appropriate) security with respect to each such key. =E2=80=8B > > -Estimations of the cost of group computations require care: while > those in the original email are correct, the estimates for shared-base > and multibase have to take into account the existence of ladders. A > seeming optimization might force the use of a slower representation. > In genus 1 this is no longer an issue. > =E2=80=8BI am not expert in implementing EC operations so I will appreciate= any guidance regarding these aspects of the protocol. =E2=80=8B > > -We've already had controversy on the list about removing > renegotiation as a mechanism for client authentication. While I would > really like to see a symmetric client authentication method, the fact > that some people want to change the client authentication state in the > middle of the connection limits the kinds of options we have. (I don't > know what exactly the requirements are or how they limit the options, > but I remember this being raised in an earlier proposal for removing > renegotiation) > > None of these issues look like showstoppers to me. I think the > benefits of this proposal, particularly with regards to 0-RTT and > 1-RTT exchanges where there is a solid proposal as opposed to none at > all, significantly outweigh the minor disadvantages. It opens the door > to massive performance increases by removing a dependency on signing, > and the consequent annoyances. And lastly, it will hopefully have a > proof that is understandable by humans with reasonable assumptions. > =E2=80=8BThat's the goal. Hugo =E2=80=8B > > Sincerely, > Watson Ladd > ----- > > > [0] http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf > [1] https://www.infsec.cs.uni-saarland.de/~mohammadi/paper/owake.pdf > > On Fri, Oct 31, 2014 at 6:59 PM, Eric Rescorla wrote: > > P.S. At first glance this kind of design seems to have some really nice > > properties and wouldn't be too hard to modify the draft (and > > implementations) > > to support. I'm looking forward to hearing what the WG thinks. > > > > Best, > > -Ekr > > > > On Fri, Oct 31, 2014 at 6:44 PM, Eric Rescorla wrote: > >> > >> Hugo, > >> > >> Thanks for writing this up. I'm still digesting this, but I had a few > >> questions. > >> > >> 1. In the interim, I believe you suggested MAC of the transcript under > >> g^{xs} to authenticate g^y. This is fairly analogous to > CertificateVerify, > >> except using a MAC rather than a signature. In the current design, you > >> instead generate a combined key from g^{xs] and g^{xy}. Are there > >> advantages to this design or is it just a matter of style? > >> > >> 2. I'm thinking about how to adapt this to PSK+PFS modes (i.e., > >> where you want the PSK for authentication but you want to do > >> a DHE exchange for PFS). In the design you propose, it seems > >> like the analogous thing to do would be to treat the PSK like > >> g^{xy}? Does this interact at all with whether to mix the keys > >> or use a MAC? > >> > >> 3. WRT client auth, I think we've generally decided that the client's > >> certificate ought to be encrypted. Given that, I wonder if it would be > >> easier > >> for the client to just do a digital signature over the transcript and/= or > >> an authenticator derived from the secret. Generally, the additional > >> cost of the RSA signature isn't a huge problem for most clients and > >> those which do should be able to quickly move to EC-based keys. > >> > >> Thanks, > >> -Ekr > >> > >> > >> On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk > >> wrote: > >>> > >>> During the TLS interim meeting of last week (Oct 22 2014) I suggested > >>> that TLS > >>> 1.3 should abandon signature-based authentication (other than for > >>> certificates) > >>> and be based solely on a combination of ephemeral Diffie-Hellman for > PFS > >>> and > >>> static Diffie-Hellman for authentication. This has multiple benefits > >>> including > >>> major performance gain (by replacing the per-handshake RSA signature = by > >>> the > >>> server with a much cheaper elliptic curve exponentiation), > compatibility > >>> with > >>> the mechanisms required for forward secrecy, natural accommodation of= a > >>> 0-RTT > >>> option, and a simple extension without signatures for client > >>> authentication. > >>> > >>> Below I present a schematic representation of the proposed protocol > >>> referred > >>> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three= . > >>> The presentation is sketchy and omits the exact procedure for key > >>> derivation. > >>> The latter is a crucial component for the security of the protocol, b= ut > >>> before getting into these details we want to get a sense of whether t= he > >>> WG is > >>> interested in this approach. In the meantime, Hoeteck Wee and myself > are > >>> working on the details of the protocol and the security proof. > >>> > >>> We describe a setting with optional 0-RTT and server-only > authentication. > >>> Client authentication can be added as a further option or as an > extension > >>> (similar to the current 1.3 proposal) - see below. > >>> > >>> NOTATION AND TERMINOLOGY: > >>> > >>> [K] symbols represent pointers to key material whose exact derivation > is > >>> not > >>> included here except for specifying the basic DH values from which th= e > >>> key is > >>> derived (actual derivation will include further information similar t= o > >>> the > >>> extended hash mechanisms or SessionHash proposal considered for 1.3). > >>> Asterisks represent optional fields that the WG can decide to leave a= s > >>> optional, > >>> mandatory, or simply remove without changing the core cryptographic > >>> security of > >>> the protocol. All references to encryption mean "authenticated > >>> encryption" > >>> using the encrypt-then-mac paradigm (or any other secure AEAD > mechanism). > >>> > >>> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the > >>> parties. > >>> All the public key and Diffie-Hellman operations are assumed to happe= n > >>> over a > >>> cyclic group with generator g of order q (typically implemented by an > >>> elliptic > >>> curve group). We use multiplicative notation where ^ denotes > >>> exponentiation as > >>> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y= ), > >>> etc. > >>> Omitted from the current high level description is a mechanism for > >>> testing group > >>> membership of DH values or cofactor exponentiation (the specific > >>> mechanism > >>> depends on the group type and is typically very efficient for ellipti= c > >>> curves). > >>> > >>> SERVER PUBLIC KEY AND CERTIFICATE: > >>> > >>> The server has a long term private-public key pair denoted by (s,g^s) > >>> where > >>> s is uniform random in [0..q-1] (we refer to s and g^s as "static > keys"). > >>> We assume that the server has a certificate that includes the server'= s > >>> public > >>> key g^s and a CA-signed binding of this key to the server's identity. > >>> We discuss the implementation of such certificates below. > >>> > >>> PROTOCOL OPTLS: > >>> > >>> ClientHello > >>> ClientKeyShare > >>> ClientData* [K0] --------> > >>> ServerHello > >>> ServerKeyShare > >>> ServerCertificate* [K1] > >>> ServerFinished [K2] > >>> <-------- ServerData* [K2] > >>> ClientFinished* [K2] --------> > >>> > >>> > >>> Protected Application Data [K3] > >>> <-------> > >>> > >>> > >>> > >>> 1-RTT CASE: > >>> > >>> The basic 1-RTT case omits the ClientData* field. It includes a > >>> ClientKeyShare > >>> g^x and a ServerKeyShare g^y and an optional (encrypted) server > >>> certificate. > >>> If the certificate is sent (it can be omitted if the client has > indicated > >>> that > >>> it knows the server key as in the case in the 0-RTT scenario) and is > >>> encrypted, > >>> the encryption key K1 is derived from g^{xy}. > >>> > >>> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It i= s > >>> used to > >>> authenticate-encrypt the ServerFinished and ClientFinished messages > >>> (which > >>> include a hash of the previous traffic) and to encrypt data from the > >>> server if > >>> such data is piggybacked to the second message. > >>> > >>> Key K3 is the "application key" used to derive key material for > >>> protection of > >>> application data. This key material will include (directional) > >>> Authenticated > >>> Encryption keys and, possibly, keys for derivation of further re-key > >>> material. > >>> K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its > >>> derivation > >>> will be different than K2, e.g., using a separating key expansion > >>> technique. > >>> > >>> SUPPORT FOR 0-RTT: > >>> > >>> The above protocol is compatible with a 0-RTT protocol such as QUIC. = In > >>> this > >>> case, the client is assumed to have information about the server's > public > >>> key > >>> and other security parameters. The server is assumed to have some > >>> mechanism in > >>> place for detecting replay (e.g., via timestamps, stored client nonce= s, > >>> etc.). > >>> The resulting protocol is as described above where the ClientData fie= ld > >>> is sent > >>> encrypted under key K0 derived from g^{xs}. > >>> The rest of the protocol is identical to the above. > >>> Note: In this case, ServerCertificate is not sent as the client had t= o > >>> know > >>> the server's public key before the first message (one can imagine a > >>> setting > >>> where the server may send a different certificate in the second > message - > >>> if > >>> desired, this can be accommodated too as an option or extension). > >>> > >>> CLIENT AUTHENTICATION: > >>> > >>> Client authentication can be supported via an option or extension. It > >>> would > >>> include a client certificate for a static DH key g^c sent in the thir= d > >>> message > >>> (the certificate can be encrypted under key K2 to provide client's > >>> identity > >>> protection). In this case, the key for computing the ClientFinished > >>> message and > >>> the application key K3 would be derived from a combination of the > values > >>> g^xy, > >>> g^xs, g^yc (and possibly also g^{cs}). > >>> > >>> NOTES: > >>> > >>> Note on Finished messages: The above spec sets ServerFinished as > >>> mandatory and > >>> ClientFinished as optional. The latter option is needed for a 1-RTT > >>> protocol. > >>> In principle, both Finished messages could be omitted and still obtai= n > >>> security > >>> via implicit authentication (assuming the inputs to key derivation ar= e > >>> chosen > >>> appropriately). But given the advantages of ServerFinished for > providing > >>> explicit authentication, key confirmation, and active forward secrecy > >>> (see > >>> below), it seems advisable to always include it. Including > ClientFinished > >>> provides key confirmation from client and also explicit client > >>> authentication > >>> when client certificate is included. ClientFinished also provides > >>> Universal > >>> Composable (UC) security (this is a result of the Canetti-Krawczyk > proof > >>> that > >>> CK security implies UC security when a client confirmation step is > >>> included). > >>> > >>> Note on certificates: Since in current practice servers hold > certificates > >>> for > >>> RSA signature keys rather than for static DH keys, the certificate > field > >>> in the > >>> above protocol will be implemented by a pair consisting of (i) the > >>> server's RSA > >>> signature certificate and (ii) the server's signature using this RSA > key > >>> on the > >>> server's static public DH key g^s. The latter signature by the server > is > >>> performed only when a new static DH key is created (how often this > >>> happens and > >>> how many such keys are created is completely up to the server - it ha= s > >>> the > >>> advantage that these keys can be changed often to increase security > >>> against > >>> leaked keys). This use of RSA also enjoys the high efficiency of RSA > >>> verification for the client. > >>> The handling of Client certificates would be similar. > >>> > >>> Note on forward security (a.k.a. as PFS for Perfect Forward Security)= : > >>> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman > keys. > >>> The meaning of PFS is that an attacker that finds the (long-term) > static > >>> private keys of the parties cannot compromise past session keys. > Without > >>> the > >>> ServerFinished message the above protocol ensures forward secrecy > against > >>> passive attackers (i.e., for sessions where the attacker did not choo= se > >>> g^y). > >>> With ServerFinished, PFS holds also against active attackers. A > similar > >>> consideration applies to ClientFinished. > >>> > >>> Client certificates in the first message: We note that in cases where > >>> client > >>> certificates can be sent in the clear in the first message of the > >>> protocol, one > >>> can provide PFS and mutual authentication in a 1-RTT at essentially t= he > >>> same > >>> cost of an unauthenticated DH exchange (i.e., a cost of little more > than > >>> two > >>> exponentiations). In such a setting one can also obtain mutual > >>> authentication in > >>> a 0-RTT protocol (with forward secrecy with respect to the client's > key). > >>> These options, however, require HMQV-like mechanisms and may raise IP > >>> issues (this > >>> can be investigated further if the WG is interested). > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > --089e0158b7ea445b900506e7b2b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 1, 2014 at 7:15 AM, Watson Ladd <wat= sonbladd@gmail.com> wrote:
Dear Hugo,

There are some issues I can see:

-Servers already supporting ECDSA certificates seem to not win. If I'm<= br> understanding correctly, a server does three exponentiations, one of
which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The
servers that win are the ones with RSA certs. The only way to win vs
ECDSA is if DH only permits faster exponentiation, which it does, and
removing the ancillary junk in ECDSA.=C2=A0 However, here we have two
variable base exponentiations after ephemeral reuse, as opposed to one
fixed, one variable, so there is a loss in performance on the same
group, made up for by removing inversions modulo the group order.

=E2=80=8BDon't forget that 0-= RTT cannot be supported with a signature-based protocol so in that sense go= ing to static DH is a win-win.
As for p= erformance, the gain with respect to (per-session) RSA signatures is huge.<= br>
Comparison with ECDSA is indeed more com= plex as you point out, but static DH wins in comparison to the sign+verify = performance and saves many=C2=A0 complexities related to ECDSA optimization= and (re)definition. It also avoids the vulnerability of Schnorr-like signa= tures where leakage of one ephemeral value compromises the long-term signat= ure key. In contrast, static DH keys do not leak even if all ephemeral valu= es are disclosed. Furthermore, one can design the protocol so that the disc= losure of the ServerKeyShare does not even compromise the session key that = uses this value.
=E2=80=8B
=C2=A0

-I'm interested to see how different this is from ntor.[0] (To my eyes<= br> it is very similar, which may make proving easier. OTOH, the 0-RTT and
1-RTT options require care). Similarly, Michael Backes and coauthors
have proposed Ace[1], which does similar tricks to HMQV to reduce
server side cost, and provides a key exchange with some similar
properties.

=E2=80=8BI a= m not familiar with these works, but it is too early to compare with other = protocols as this one is yet not fully specified. Its details will be set w= hen we get a better understanding of what is needed. One important element = here is that we will be defining several key derivation operations and we w= ill need to prove (appropriate) security with respect to each such key.
= =E2=80=8B
=C2=A0
=E2=80=8BI am not expert in implementing EC operations so I= will appreciate any guidance regarding these aspects of the protocol.
= =E2=80=8B
=C2=A0
=E2=80=8BThat's the goal.
Hugo
=E2=80=8B
=C2=A0
Sincerely,
Watson Ladd
-----


[0] http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf<= /a>
[1] https://www.infsec.cs.uni-saarland.de/~mohammadi/pa= per/owake.pdf

On Fri, Oct 31, 2014 at 6:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> P.S. At first glance this kind of design seems to have some really nic= e
> properties and wouldn't be too hard to modify the draft (and
> implementations)
> to support. I'm looking forward to hearing what the WG thinks.
>
> Best,
> -Ekr
>
> On Fri, Oct 31, 2014 at 6:44 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Hugo,
>>
>> Thanks for writing this up. I'm still digesting this, but I ha= d a few
>> questions.
>>
>> 1. In the interim, I believe you suggested MAC of the transcript u= nder
>> g^{xs} to authenticate g^y. This is fairly analogous to Certificat= eVerify,
>> except using a MAC rather than a signature. In the current design,= you
>> instead generate a combined key from g^{xs] and g^{xy}. Are there<= br> >> advantages to this design or is it just a matter of style?
>>
>> 2. I'm thinking about how to adapt this to PSK+PFS modes (i.e.= ,
>> where you want the PSK for authentication but you want to do
>> a DHE exchange for PFS). In the design you propose, it seems
>> like the analogous thing to do would be to treat the PSK like
>> g^{xy}? Does this interact at all with whether to mix the keys
>> or use a MAC?
>>
>> 3. WRT client auth, I think we've generally decided that the c= lient's
>> certificate ought to be encrypted. Given that, I wonder if it woul= d be
>> easier
>> for the client to just do a digital signature over the transcript = and/or
>> an authenticator derived from the secret. Generally, the additiona= l
>> cost of the RSA signature isn't a huge problem for most client= s and
>> those which do should be able to quickly move to EC-based keys. >>
>> Thanks,
>> -Ekr
>>
>>
>> On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
>> wrote:
>>>
>>> During the TLS interim meeting of last week (Oct 22 2014) I su= ggested
>>> that TLS
>>> 1.3 should abandon signature-based authentication (other than = for
>>> certificates)
>>> and be based solely on a combination of ephemeral Diffie-Hellm= an for PFS
>>> and
>>> static Diffie-Hellman for authentication. This has multiple be= nefits
>>> including
>>> major performance gain (by replacing the per-handshake RSA sig= nature by
>>> the
>>> server with a much cheaper elliptic curve exponentiation), com= patibility
>>> with
>>> the mechanisms required for forward secrecy, natural accommoda= tion of a
>>> 0-RTT
>>> option, and a simple extension without signatures for client >>> authentication.
>>>
>>> Below I present a schematic representation of the proposed pro= tocol
>>> referred
>>> to as OPTLS where OPT stands for OPTimized and/or for One-Poin= t-Three.
>>> The presentation is sketchy and omits the exact procedure for = key
>>> derivation.
>>> The latter is a crucial component for the security of the prot= ocol, but
>>> before getting into these details we want to get a sense of wh= ether the
>>> WG is
>>> interested in this approach. In the meantime, Hoeteck Wee and = myself are
>>> working on the details of the protocol and the security proof.=
>>>
>>> We describe a setting with optional 0-RTT and server-only auth= entication.
>>> Client authentication can be added as a further option or as a= n extension
>>> (similar to the current 1.3 proposal) - see below.
>>>
>>> NOTATION AND TERMINOLOGY:
>>>
>>> [K] symbols represent pointers to key material whose exact der= ivation is
>>> not
>>> included here except for specifying the basic DH values from w= hich the
>>> key is
>>> derived (actual derivation will include further information si= milar to
>>> the
>>> extended hash mechanisms or SessionHash proposal considered fo= r 1.3).
>>> Asterisks represent optional fields that the WG can decide to = leave as
>>> optional,
>>> mandatory, or simply remove without changing the core cryptogr= aphic
>>> security of
>>> the protocol. All references to encryption mean "authenti= cated
>>> encryption"
>>> using the encrypt-then-mac paradigm (or any other secure AEAD = mechanism).
>>>
>>> KeyShare's represent ephemeral Diffie-Hellman values excha= nged by the
>>> parties.
>>> All the public key and Diffie-Hellman operations are assumed t= o happen
>>> over a
>>> cyclic group with generator g of order q (typically implemente= d by an
>>> elliptic
>>> curve group). We use multiplicative notation where ^ denotes >>> exponentiation as
>>> in g^x, g^{xy} (here xy denotes multiplication of the scalars = x and y),
>>> etc.
>>> Omitted from the current high level description is a mechanism= for
>>> testing group
>>> membership of DH values or cofactor exponentiation (the specif= ic
>>> mechanism
>>> depends on the group type and is typically very efficient for = elliptic
>>> curves).
>>>
>>> SERVER PUBLIC KEY AND CERTIFICATE:
>>>
>>> The server has a long term private-public key pair denoted by = (s,g^s)
>>> where
>>> s is uniform random in [0..q-1] (we refer to s and g^s as &quo= t;static keys").
>>> We assume that the server has a certificate that includes the = server's
>>> public
>>> key g^s and a CA-signed binding of this key to the server'= s identity.
>>> We discuss the implementation of such certificates below.
>>>
>>> PROTOCOL OPTLS:
>>>
>>> ClientHello
>>> ClientKeyShare
>>> ClientData* [K0]=C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ServerHello
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ServerKeyShare
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ServerCertificate* [K1]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ServerFinished [K2]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0S= erverData* [K2]
>>> ClientFinished* [K2]=C2=A0 =C2=A0-------->
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Appli= cation Data [K3]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <------->
>>>
>>>
>>>
>>> 1-RTT CASE:
>>>
>>> The basic 1-RTT case omits the ClientData* field. It includes = a
>>> ClientKeyShare
>>> g^x and a ServerKeyShare g^y and an optional (encrypted) serve= r
>>> certificate.
>>> If the certificate is sent (it can be omitted if the client ha= s indicated
>>> that
>>> it knows the server key as in the case in the 0-RTT scenario) = and is
>>> encrypted,
>>> the encryption key K1 is derived from g^{xy}.
>>>
>>> Key K2 is an encryption key derived from both g^{xs} and g^{xy= }. It is
>>> used to
>>> authenticate-encrypt the ServerFinished and ClientFinished mes= sages
>>> (which
>>> include a hash of the previous traffic) and to encrypt data fr= om the
>>> server if
>>> such data is piggybacked to the second message.
>>>
>>> Key K3 is the "application key" used to derive key m= aterial for
>>> protection of
>>> application data.=C2=A0 This key material will include (direct= ional)
>>> Authenticated
>>> Encryption keys and, possibly, keys for derivation of further = re-key
>>> material.
>>> K3 is computed from=C2=A0 both g^{xs} and g^{xy} similarly to = K2, but its
>>> derivation
>>> will be different than K2, e.g., using a separating key expans= ion
>>> technique.
>>>
>>> SUPPORT FOR 0-RTT:
>>>
>>> The above protocol is compatible with a 0-RTT protocol such as= QUIC. In
>>> this
>>> case, the client is assumed to have information about the serv= er's public
>>> key
>>> and other security parameters. The server is assumed to have s= ome
>>> mechanism in
>>> place for detecting replay (e.g., via timestamps, stored clien= t nonces,
>>> etc.).
>>> The resulting protocol is as described above where the ClientD= ata field
>>> is sent
>>> encrypted under key K0 derived from g^{xs}.
>>> The rest of the protocol is identical to the above.
>>> Note: In this case, ServerCertificate is not sent as the clien= t had to
>>> know
>>> the server's public key before the first message (one can = imagine a
>>> setting
>>> where the server may send a different certificate in the secon= d message -
>>> if
>>> desired, this can be accommodated too as an option or extensio= n).
>>>
>>> CLIENT AUTHENTICATION:
>>>
>>> Client authentication can be supported via an option or extens= ion. It
>>> would
>>> include a client certificate for a static DH key g^c sent in t= he third
>>> message
>>> (the certificate can be encrypted under key K2 to provide clie= nt's
>>> identity
>>> protection). In this case, the key for computing the ClientFin= ished
>>> message and
>>> the application key K3 would be derived from a combination of = the values
>>> g^xy,
>>> g^xs, g^yc (and possibly also g^{cs}).
>>>
>>> NOTES:
>>>
>>> Note on Finished messages: The above spec sets ServerFinished = as
>>> mandatory and
>>> ClientFinished as optional. The latter option is needed for a = 1-RTT
>>> protocol.
>>> In principle, both Finished messages could be omitted and stil= l obtain
>>> security
>>> via implicit authentication (assuming the inputs to key deriva= tion are
>>> chosen
>>> appropriately). But given the advantages of ServerFinished for= providing
>>> explicit authentication, key confirmation, and active forward = secrecy
>>> (see
>>> below), it seems advisable to always include it. Including Cli= entFinished
>>> provides key confirmation from client and also explicit client=
>>> authentication
>>> when client certificate is included. ClientFinished also provi= des
>>> Universal
>>> Composable (UC) security (this is a result of the Canetti-Kraw= czyk proof
>>> that
>>> CK security implies UC security when a client confirmation ste= p is
>>> included).
>>>
>>> Note on certificates: Since in current practice servers hold c= ertificates
>>> for
>>> RSA signature keys rather than for static DH keys, the certifi= cate field
>>> in the
>>> above protocol will be implemented by a pair consisting of (i)= the
>>> server's RSA
>>> signature certificate and (ii) the server's signature usin= g this RSA key
>>> on the
>>> server's static public DH key g^s. The latter signature by= the server is
>>> performed only when a new static DH key is created (how often = this
>>> happens and
>>> how many such keys are created is completely up to the server = - it has
>>> the
>>> advantage that these keys can be changed often to increase sec= urity
>>> against
>>> leaked keys). This use of RSA also enjoys the high efficiency = of RSA
>>> verification for the client.
>>> The handling of Client certificates would be similar.
>>>
>>> Note on forward security (a.k.a. as PFS for Perfect Forward Se= curity):
>>> PFS is provided by the (mandatory) use of ephemeral Diffie-Hel= lman keys.
>>> The meaning of PFS is that an attacker that finds the (long-te= rm) static
>>> private keys of the parties cannot compromise past session key= s. Without
>>> the
>>> ServerFinished message the above protocol ensures forward secr= ecy against
>>> passive attackers (i.e., for sessions where the attacker did n= ot choose
>>> g^y).
>>> With ServerFinished, PFS holds also against active attackers.= =C2=A0 A similar
>>> consideration applies to ClientFinished.
>>>
>>> Client certificates in the first message: We note that in case= s where
>>> client
>>> certificates can be sent in the clear in the first message of = the
>>> protocol, one
>>> can provide PFS and mutual authentication in a 1-RTT at essent= ially the
>>> same
>>> cost of an unauthenticated DH exchange (i.e., a cost of little= more than
>>> two
>>> exponentiations). In such a setting one can also obtain mutual=
>>> authentication in
>>> a 0-RTT protocol (with forward secrecy with respect to the cli= ent's key).
>>> These options, however, require HMQV-like mechanisms and may r= aise IP
>>> issues (this
>>> can be investigated further if the WG is interested).
>>>
>>>
>>> _______________________________________________
>>> 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
>



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

--089e0158b7ea445b900506e7b2b9-- From nobody Sun Nov 2 14:29:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1541A1A9D for ; Sun, 2 Nov 2014 14:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZXrhL_jvruX for ; Sun, 2 Nov 2014 14:29:17 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A641A1A9C for ; Sun, 2 Nov 2014 14:29:16 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id hs14so8801440lab.33 for ; Sun, 02 Nov 2014 14:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PhbQv1XilKEvmY49S6lFnlOVQmCZf2pS+ALsP/rrOeo=; b=ScTsacj+slNZJD0Z74hpSx7RAyDGour157Pot8YiqKzLT+YWE0JTjwBFJKVv5Y7xUy 1dFBBO2rzYopuiFyHmg4JppeAn7INr0VPONQuNSgFn6MkULpfxeqVuX6g7v5X7soPZbo p8fN2jSDIE0xGj0nuy5Lrzq3ha2zkgd5jenrr7FdIBqwg4kBMl6HpIQle+kqkWlFfSn5 Zz+7uek02dhTMp0ntvrGuCEUe2/9DQ/JRkquq1lkcOKQk70jCcNfCRkjIMKmdn2h0Iv+ Ftajr2BcJWprGsGJ7Amd+Q6+HV3wB2bGodD/4FfXV0sA/dHsVYp3d30Ydr/KAE//xdPr uUNw== X-Received: by 10.112.97.175 with SMTP id eb15mr46192238lbb.12.1414967354933; Sun, 02 Nov 2014 14:29:14 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Sun, 2 Nov 2014 14:28:44 -0800 (PST) In-Reply-To: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> From: Hugo Krawczyk Date: Mon, 3 Nov 2014 00:28:44 +0200 X-Google-Sender-Auth: 5f5cqXYjBybfoob0q2DELkDudH4 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a1133b6348f4a420506e7c295 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AqVWsjSe1ia4fVC0m3vg-fiFHyQ Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 22:29:18 -0000 --001a1133b6348f4a420506e7c295 Content-Type: text/plain; charset=UTF-8 The issues regarding group matching (and mis-matching) raised here and discussed in other messages are indeed very important. In the case of server-only authentication this reduces to the client guessing the right g^x and thus requires dealing with wrong guesses (this only applies to the 1-RTT case as in the 0-RTT case the client learns the group together with the server's static key g^s). In the mutual authentication case, if server and client cannot agree on using the same group for authentication, then the client would need to choose its g^x in the server's group while authentication by the client would require the server to send an additional ServerKeyShare in the client's group. Note, however, that in the use case where the parties have certificates for signature keys and they sign their own static DH key, clients and servers can possess static DH keys in different groups (without requiring a CA-issued certificate for each such group), hence more easily support the peer's group. Hugo On Sat, Nov 1, 2014 at 11:41 AM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > During the TLS interim meeting of last week (Oct 22 2014) I suggested > that > > TLS > > 1.3 should abandon signature-based authentication (other than for > > certificates) > > and be based solely on a combination of ephemeral Diffie-Hellman for PFS > and > > static Diffie-Hellman for authentication. This has multiple benefits > > including > > major performance gain (by replacing the per-handshake RSA signature by > the > > server with a much cheaper elliptic curve exponentiation), compatibility > > with > > the mechanisms required for forward secrecy, natural accommodation of a > > 0-RTT > > option, and a simple extension without signatures for client > authentication. > > That effectively deprecates all existing infrastructure used for TLS that > pretty > much only works with RSA and ECDSA certificates (from smart cards, to HSMs > and > acceleration hardware). That's not necessarily bad, and we may already be > past the > point where TLS 1.3 can be considered a minor revision of TLS 1.2. > > > PROTOCOL OPTLS: > > > > ClientHello > > ClientKeyShare > > ClientData* [K0] --------> > > ServerHello > > ServerKeyShare > > ServerCertificate* [K1] > > ServerFinished [K2] > > <-------- ServerData* [K2] > > ClientFinished* [K2] --------> > > > > > > Protected Application Data [K3] > > <-------> > > 1-RTT CASE: > > > > The basic 1-RTT case omits the ClientData* field. It includes a > > ClientKeyShare > > g^x and a ServerKeyShare g^y and an optional (encrypted) server > > certificate. > > If the certificate is sent (it can be omitted if the client has indicated > > that > > it knows the server key as in the case in the 0-RTT scenario) and is > > encrypted, > > the encryption key K1 is derived from g^{xy}. > > > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is > used > > to > > authenticate-encrypt the ServerFinished and ClientFinished messages > (which > > include a hash of the previous traffic) and to encrypt data from the > server > > if > > such data is piggybacked to the second message. > > How does the client get the DH (or ECDH) group parameters used by the > server? > > > CLIENT AUTHENTICATION: > > > > Client authentication can be supported via an option or extension. It > would > > include a client certificate for a static DH key g^c sent in the third > > message > > (the certificate can be encrypted under key K2 to provide client's > identity > > protection). In this case, the key for computing the ClientFinished > message > > and > > the application key K3 would be derived from a combination of the values > > g^xy, > > g^xs, g^yc (and possibly also g^{cs}). > > As I understand client authentication as above would only work if both the > client > and the server share the same DH/ECDH group for their certificates, and > that cannot > be assumed to be true on an infrastructure that is designed to upgrade > (e.g., change > client certs from secp192r1 to secp256r1). > > regards, > Nikos > --001a1133b6348f4a420506e7c295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The issues regarding group matching (and mis-ma= tching) raised here and discussed
in other messages are indeed very impo= rtant. In the case of server-only
authentication this reduces to the cli= ent guessing the right g^x and thus
requires dealing with wrong guesses = (this only applies to the 1-RTT case as in
the 0-RTT case the client lea= rns the group together with the server's static
key g^s). In the mut= ual authentication case, if server and client cannot agree
on using the = same group for authentication, then the client would need to
choose its = g^x in the server's group while authentication by the client would
r= equire the server to send an additional ServerKeyShare in the client's = group.
Note, however, that in the use case where the parties have certif= icates for
signature keys and they sign their own static DH key, clients= and servers can
possess static DH keys in different groups (without req= uiring a CA-issued
certificate for each such group), hence more easily s= upport the peer's group.

Hugo



On Sat, Nov 1, 2014 at 11:41 AM, Nikos Mavrogiannopoulos <nmav@redhat.= com> wrote:
----- Original Message -----
> During the TLS interim meeting of last week (Oct 22 2014) I suggested = that
> TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for P= FS and
> static Diffie-Hellman for authentication. This has multiple benefits > including
> major performance gain (by replacing the per-handshake RSA signature b= y the
> server with a much cheaper elliptic curve exponentiation), compatibili= ty
> with
> the mechanisms required for forward secrecy, natural accommodation of = a
> 0-RTT
> option, and a simple extension without signatures for client authentic= ation.

That effectively deprecates all existing infrastructure used for TLS= that pretty
much only works with RSA and ECDSA certificates (from smart cards, to HSMs = and
acceleration hardware). That's not necessarily bad, and we may already = be past the
point where TLS 1.3 can be considered a minor revision of TLS 1.2.

> PROTOCOL OPTLS:
>
> ClientHello
> ClientKeyShare
> ClientData* [K0]=C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerHello
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerKeyShare
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerCertificate* [K1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerFinished [K2]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ServerDa= ta* [K2]
> ClientFinished* [K2]=C2=A0 =C2=A0-------->
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Application D= ata [K3]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <------->
> 1-RTT CASE:
>
> The basic 1-RTT case omits the ClientData* field. It includes a
> ClientKeyShare
> g^x and a ServerKeyShare g^y and an optional (encrypted) server
> certificate.
> If the certificate is sent (it can be omitted if the client has indica= ted
> that
> it knows the server key as in the case in the 0-RTT scenario) and is > encrypted,
> the encryption key K1 is derived from g^{xy}.
>
> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is= used
> to
> authenticate-encrypt the ServerFinished and ClientFinished messages (w= hich
> include a hash of the previous traffic) and to encrypt data from the s= erver
> if
> such data is piggybacked to the second message.

How does the client get the DH (or ECDH) group parameters used = by the server?

> CLIENT AUTHENTICATION:
>
> Client authentication can be supported via an option or extension. It = would
> include a client certificate for a static DH key g^c sent in the third=
> message
> (the certificate can be encrypted under key K2 to provide client's= identity
> protection). In this case, the key for computing the ClientFinished me= ssage
> and
> the application key K3 would be derived from a combination of the valu= es
> g^xy,
> g^xs, g^yc (and possibly also g^{cs}).

As I understand client authentication as above would only work if bo= th the client
and the server share the same DH/ECDH group for their certificates, and tha= t cannot
be assumed to be true on an infrastructure that is designed to upgrade (e.g= ., change
client certs from secp192r1 to secp256r1).

regards,
Nikos

--001a1133b6348f4a420506e7c295-- From nobody Sun Nov 2 14:34:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9CC1A1A3F for ; Sun, 2 Nov 2014 14:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAHqwwsk_LHQ for ; Sun, 2 Nov 2014 14:34:17 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AD31A0687 for ; Sun, 2 Nov 2014 14:34:17 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so9885854wgg.19 for ; Sun, 02 Nov 2014 14:34:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=csj2apvuKM9qli+4AJZnCvGk94lfQvqGfBYotWXYTnE=; b=LWqBk9ZkW4wDhncQ/Vwwz8r6JuxIz+dv7awynmpV4E0iE6Hl4CVWMioQAEOsekm6Lp fLd5BUGA2A97ZanuhXOlb3PXees3ydkfN2IntV028AzM4TtTQiRCxyN4xjOP5oqN7nK2 7aVGEENe8Yb0aibsIfqu0Ki1qE083ti9t8cdIE8RR0ppGfyR50cKiSIY4lu4dcAJMafW NrxB6JpcatAKTFzNwhzX7GGmUVGN3KIRlNUCmHhMHR2qjExQQFjXihpGAhLlsTEGYUz0 iotAvM4DQk0xGvnYVi648KLBTHDSlRml6WZtkJG5OmuX8Xf2XtJazIiDlJqiPDE/jf/t CQcw== X-Gm-Message-State: ALoCoQl0yb10iIpDnAeHdAXgPN51BA55xD9lB4/kyDQJD5sFbuEln3oMsGAFWnYq0L+379cg0G7t X-Received: by 10.180.108.43 with SMTP id hh11mr11828654wib.80.1414967655989; Sun, 02 Nov 2014 14:34:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Sun, 2 Nov 2014 14:33:34 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 2 Nov 2014 14:33:34 -0800 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=089e0122950a8117580506e7d47a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m0uqDPvzlSicXwLB5Spr2_z6g4k Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 22:34:19 -0000 --089e0122950a8117580506e7d47a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk wrote: > These are good questions as they point to some of the choices we need to > consider before defining the actual key derivation mechanisms in the protocol. > Below are some responses. Thanks for your explanations. > On Sat, Nov 1, 2014 at 3:44 AM, Eric Rescorla wrote: > > > > 3. WRT client auth, I think we've generally decided that the client's > > certificate ought to be encrypted. Given that, I wonder if it would be easier > > for the client to just do a digital signature over the transcript and/o= r > > an authenticator derived from the secret. Generally, the additional > > cost of the RSA signature isn't a huge problem for most clients and > > those which do should be able to quickly move to EC-based keys. > > > =E2=80=8BI don't see the advantage of signatures in this case. It is poss= ible to design a > hybrid protocol with signature authentication at the client side and static DH > at the server but I wouldn't do that without a clear advantage over the more > uniform approach using static DH on both sides. In any case, doing static DH at > the client should not be a problem, it is already doing it to authenticate the > server and compute keys. Thinking this through some more, if the client is doing certificate authentication, it is already provisioned with a long-term signature key and the corresponding certificate. In order to do static DH for authentication, it must either: - Generate a new "static" DH key on the fly and sign it. - Have some long-term storage where it stuffs the static DH key and its signature. The first option is obviously more computationally expensive than not doing so (though as I said above, not dramatically so if you are doing EC). As you suggest, this isn't an issue for servers since they are doing a lot of handshakes and can amortize the computation. However, because the client may be slow but not do a lot of exchanges, it may be an issue for clients. The second option may be trivial, if the client already has some generic key storage mechanism (e.g., one in software) though it's of course more work for the programmer. However, if the client has a non-generic key storage mechanism, such as a smart card with their key, then this becomes a significant problem, as it may not be able to store a DH key and/or use it for the kind of key derivation that would be required here. In that case, the client must find somewhere to store the DH key, which may entail significant effort. This last point points us to a larger issue we need to consider here, which is as follows. In TLS as it currently stands (both in 1.2 and the current TLS 1.3 draft), you can implement a system where the authentication keys are stored in hardware and an attacker who compromises either the client and the server cannot steal a credential which he can then use to establish new sessions [Note that if he steals the session cache, he can use it to resume old sessions.] In particular, because each signature is tied to a specific exchange, the attacker cannot reuse signed ephemeral values to impersonate the server. However, in a system where the server signs a long-term DH value, it may be the case that that value cannot be stored in the same hardware module that you are using for your signature key (purely for implementation reasons having to do with the interface the module exposes). In that case, the DH secret will be stored in software and compromise of the server potentially leaks a credential which can be used to impersonate the server for a significant period of time, where that time is dictated by the maximum amount of client-side clock error the server is willing to tolerate, so probably measured in days to weeks (and more if you are concerned about the time resetting attack Watson, Ilari, and I were discussing.) I haven't decided yet sure how serious an issue this is, but it's probably worth addressing explicitly. -Ekr --089e0122950a8117580506e7d47a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
>= These are good questions as they point to some of the choices we need to
> consider before defining the actual key derivation mechanisms= in the protocol.
> Below are some responses.

Thanks for your explanations.

=C2=A0
> On Sat, Nov 1, 2014 at 3:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > 3. WRT client auth, I think we've generally decided that the= client's
> > certificate ought to be encrypted. Given = that, I wonder if it would be easier
> > for the client to = just do a digital signature over the transcript and/or
> > = an authenticator derived from the secret. Generally, the additional
> > cost of the RSA signature isn't a huge problem for most cl= ients and
> > those which do should be able to quickly move= to EC-based keys.
>=C2=A0
>=C2=A0
>= =E2=80=8BI don't see the advantage of signatures in this case. It is p= ossible to design a
> hybrid protocol with signature authentic= ation at the client side and static DH
> at the server but I w= ouldn't do that without a clear advantage over the more
> = uniform approach using static DH on both sides. In any case, doing static D= H at
> the client should not be a problem, it is already doing= it to authenticate the
> server and compute keys.
<= br>

Thinking this through some more, if the client= is doing certificate
authentication, it is already provisioned w= ith a long-term signature
key and the corresponding certificate.= =C2=A0 In order to do static DH for
authentication, it must eithe= r:

- Generate a new "static" DH key on t= he fly and sign it.
- Have some long-term storage where it stuffs= the static DH key and
=C2=A0 its signature.

=
The first option is obviously more computationally expensive than not<= /div>
doing so (though as I said above, not dramatically so if you are = doing
EC). As you suggest, this isn't an issue for servers si= nce they are
doing a lot of handshakes and can amortize the compu= tation. However,
because the client may be slow but not do a lot = of exchanges, it may
be an issue for clients.

The second option may be trivial, if the client already has some
generic key storage mechanism (e.g., one in software) though it's= of
course more work for the programmer. However, if the client h= as a
non-generic key storage mechanism, such as a smart card with= their
key, then this becomes a significant problem, as it may no= t be able to
store a DH key and/or use it for the kind of key der= ivation that
would be required here. In that case, the client mus= t find somewhere
to store the DH key, which may entail significan= t effort.


This last point points us= to a larger issue we need to consider here,
which is as follows.= In TLS as it currently stands (both in 1.2 and
the current TLS 1= .3 draft), you can implement a system where the
authentication ke= ys are stored in hardware and an attacker who
compromises either = the client and the server cannot steal a credential
which he can = then use to establish new sessions [Note that if
he steals the se= ssion cache, he can use it to resume old sessions.]
In particular= , because each signature is tied to a specific exchange,
the atta= cker cannot reuse signed ephemeral values to impersonate the
serv= er.

However, in a system where the server signs a = long-term DH value, it
may be the case that that value cannot be = stored in the same hardware
module that you are using for your si= gnature key (purely for
implementation reasons having to do with = the interface the module
exposes). In that case, the DH secret wi= ll be stored in software and
compromise of the server potentially= leaks a credential which can be
used to impersonate the server f= or a significant period of time, where
that time is dictated by t= he maximum amount of client-side clock error
the server is willin= g to tolerate, so probably measured in days to
weeks (and more if= you are concerned about the time resetting attack
Watson, Ilari,= and I were discussing.) I haven't decided yet sure how
serio= us an issue this is, but it's probably worth addressing
expli= citly.

-Ekr














--089e0122950a8117580506e7d47a-- From nobody Sun Nov 2 14:39:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4D51A0687 for ; Sun, 2 Nov 2014 14:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AarVxdIx4Giv for ; Sun, 2 Nov 2014 14:39:24 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7C31A005F for ; Sun, 2 Nov 2014 14:39:24 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id ex7so5028304wid.10 for ; Sun, 02 Nov 2014 14:39:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=w9xa9XJaUD2WjVyPiZfrHYgZ9C6SuI8okJNHV1u9xeE=; b=lS3Hmk//ocsCkWRmsz70yUMagppM4F7VvLeHLhJISuSQkuItTOFzqIhmm/xcU58Uqb 8SJNYXq4JU6filYU7O+5bn12RR2CVCDIqkmxHwzhMZkvr/uJZeH3tSkeTAYB462I/RGR i6y/qyM0r8Ll3/qIsYfk3xTtyiKZSPJ959UJ0SxYVq0if7YvwPP3IM/474xx5CtB0dQH HAeKTn/2gSpkT1N6149Wt/My6BbrabqIB0u4XId5p9Sko7Dp1Z0G2oWtzZIZplDjSDGe KBVywfyMP6RIXLv1E/7WY5bm1QbYxTHWLTXJwwRnR2emWDWafdIT5Cr44MfJrgqJPUnb IVSg== X-Gm-Message-State: ALoCoQm4ATAK8419je+xN2TYcBCBxlRfVN710ghRSBI6J+yToz4GyESuch/Wi64dwjgSHSgni90l X-Received: by 10.180.103.233 with SMTP id fz9mr11831651wib.80.1414967963204; Sun, 02 Nov 2014 14:39:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Sun, 2 Nov 2014 14:38:43 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 2 Nov 2014 14:38:43 -0800 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=f46d044280cad0d1db0506e7e6b7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eDQhLQ_ZVzcsun9BUQT2TMfVfeo Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 22:39:25 -0000 --f46d044280cad0d1db0506e7e6b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 2, 2014 at 2:24 PM, Hugo Krawczyk wrote: > > > On Sat, Nov 1, 2014 at 7:15 AM, Watson Ladd wrote= : > >> Dear Hugo, >> >> There are some issues I can see: >> >> -Servers already supporting ECDSA certificates seem to not win. If I'm >> understanding correctly, a server does three exponentiations, one of >> which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The >> servers that win are the ones with RSA certs. The only way to win vs >> ECDSA is if DH only permits faster exponentiation, which it does, and >> removing the ancillary junk in ECDSA. However, here we have two >> variable base exponentiations after ephemeral reuse, as opposed to one >> fixed, one variable, so there is a loss in performance on the same >> group, made up for by removing inversions modulo the group order. >> > > =E2=80=8BDon't forget that 0-RTT cannot be supported with a signature-bas= ed > protocol > I'm not sure that this is correct. If a client does a 1-RTT exchange first (which he will have to do if he is naive about the server) then the server can provide a semi-static DH key for future use at that time and use a signature over the entire transcript to authenticate it, no? -Ekr --f46d044280cad0d1db0506e7e6b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 2, 2014 at 2:24 PM, Hugo Krawczyk <hugo@ee.technion.a= c.il> wrote:

=

= On Sat, Nov 1, 2014 at 7:15 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
D= ear Hugo,

There are some issues I can see:

-Servers already supporting ECDSA certificates seem to not win. If I'm<= br> understanding correctly, a server does three exponentiations, one of
which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The
servers that win are the ones with RSA certs. The only way to win vs
ECDSA is if DH only permits faster exponentiation, which it does, and
removing the ancillary junk in ECDSA.=C2=A0 However, here we have two
variable base exponentiations after ephemeral reuse, as opposed to one
fixed, one variable, so there is a loss in performance on the same
group, made up for by removing inversions modulo the group order.

=E2=80=8BDon't forget that 0-RTT cannot be sup= ported with a signature-based protocol


--f46d044280cad0d1db0506e7e6b7-- From nobody Sun Nov 2 14:42:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FCC1A1A3F for ; Sun, 2 Nov 2014 14:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCLtpCjlcIbh for ; Sun, 2 Nov 2014 14:41:56 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19291A0687 for ; Sun, 2 Nov 2014 14:41:55 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so5097242wiv.0 for ; Sun, 02 Nov 2014 14:41:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lT5lRV35l73Nli92MdoxZI1PZ5YuZxZk/JptJFxJ1Vc=; b=EwJev9iV7GPzYt07zpUtkC6FArMMsgnqZ5j/Bp61q4dMBtjy3z/m0UOW1AsymlTo6o RgLNixfz9EmsscAh+ru3wnHkI1AsExJ5Cd5LDRYjVuZWc9b34RjOnhmCYctl8045inMY OE9mf+gjfHU51Bgw5VpznDv9o0M64SXZ+z3YORgDqQ0ahObFt3alP6ASf2KoQBvl6Hv6 7AAPdW6g2Hd++KgNvOzFKjgQTGDzfIx/jQeHq39hyzBNVmPHWv/ph5txHpqoLDlr7NXn XLVsJ04JE3AlvpET6ED6q4opIQVFkg/mYg6BXjarmXZery6H5QDyvJO1MJJmvepId8UY hrqg== X-Gm-Message-State: ALoCoQlVYybLy9CaiRpWfeXO12KF4K0Wd2U6gaU2nCl922pp3nOdlKC5KsjQSwDFpp/b6BVai862 X-Received: by 10.194.119.193 with SMTP id kw1mr44080023wjb.37.1414968114379; Sun, 02 Nov 2014 14:41:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Sun, 2 Nov 2014 14:41:14 -0800 (PST) In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> From: Eric Rescorla Date: Sun, 2 Nov 2014 14:41:14 -0800 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=089e01228626d3b0860506e7ef57 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SyDcmqvpU6jzBXSRT8P_Lmzurww Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 22:41:58 -0000 --089e01228626d3b0860506e7ef57 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 2, 2014 at 2:28 PM, Hugo Krawczyk wrote: > The issues regarding group matching (and mis-matching) raised here and > discussed > in other messages are indeed very important. In the case of server-only > authentication this reduces to the client guessing the right g^x and thus > requires dealing with wrong guesses (this only applies to the 1-RTT case > as in > the 0-RTT case the client learns the group together with the server's > static > key g^s). In the mutual authentication case, if server and client cannot > agree > on using the same group for authentication, then the client would need to > choose its g^x in the server's group while authentication by the client > would > require the server to send an additional ServerKeyShare in the client's > group. > Note, however, that in the use case where the parties have certificates for > signature keys and they sign their own static DH key, clients and servers > can > possess static DH keys in different groups (without requiring a CA-issued > certificate for each such group), hence more easily support the peer's > group. > I believe the latter is the case we should optimize for, as existing systems which do client auth generally use signatures and so it's easier to continue to assume that then to expect that clients will get all-new certs. This seems like a natural extension of the reasoning which motivates the server signing their g^s in your proposal. -Ekr Hugo > > > > On Sat, Nov 1, 2014 at 11:41 AM, Nikos Mavrogiannopoulos > wrote: > >> ----- Original Message ----- >> > During the TLS interim meeting of last week (Oct 22 2014) I suggested >> that >> > TLS >> > 1.3 should abandon signature-based authentication (other than for >> > certificates) >> > and be based solely on a combination of ephemeral Diffie-Hellman for >> PFS and >> > static Diffie-Hellman for authentication. This has multiple benefits >> > including >> > major performance gain (by replacing the per-handshake RSA signature by >> the >> > server with a much cheaper elliptic curve exponentiation), compatibility >> > with >> > the mechanisms required for forward secrecy, natural accommodation of a >> > 0-RTT >> > option, and a simple extension without signatures for client >> authentication. >> >> That effectively deprecates all existing infrastructure used for TLS that >> pretty >> much only works with RSA and ECDSA certificates (from smart cards, to >> HSMs and >> acceleration hardware). That's not necessarily bad, and we may already be >> past the >> point where TLS 1.3 can be considered a minor revision of TLS 1.2. >> >> > PROTOCOL OPTLS: >> > >> > ClientHello >> > ClientKeyShare >> > ClientData* [K0] --------> >> > ServerHello >> > ServerKeyShare >> > ServerCertificate* [K1] >> > ServerFinished [K2] >> > <-------- ServerData* [K2] >> > ClientFinished* [K2] --------> >> > >> > >> > Protected Application Data [K3] >> > <-------> >> > 1-RTT CASE: >> > >> > The basic 1-RTT case omits the ClientData* field. It includes a >> > ClientKeyShare >> > g^x and a ServerKeyShare g^y and an optional (encrypted) server >> > certificate. >> > If the certificate is sent (it can be omitted if the client has >> indicated >> > that >> > it knows the server key as in the case in the 0-RTT scenario) and is >> > encrypted, >> > the encryption key K1 is derived from g^{xy}. >> > >> > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is >> used >> > to >> > authenticate-encrypt the ServerFinished and ClientFinished messages >> (which >> > include a hash of the previous traffic) and to encrypt data from the >> server >> > if >> > such data is piggybacked to the second message. >> >> How does the client get the DH (or ECDH) group parameters used by the >> server? >> >> > CLIENT AUTHENTICATION: >> > >> > Client authentication can be supported via an option or extension. It >> would >> > include a client certificate for a static DH key g^c sent in the third >> > message >> > (the certificate can be encrypted under key K2 to provide client's >> identity >> > protection). In this case, the key for computing the ClientFinished >> message >> > and >> > the application key K3 would be derived from a combination of the values >> > g^xy, >> > g^xs, g^yc (and possibly also g^{cs}). >> >> As I understand client authentication as above would only work if both >> the client >> and the server share the same DH/ECDH group for their certificates, and >> that cannot >> be assumed to be true on an infrastructure that is designed to upgrade >> (e.g., change >> client certs from secp192r1 to secp256r1). >> >> regards, >> Nikos >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e01228626d3b0860506e7ef57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 2, 2014 at 2:28 PM, Hugo Krawczyk <hugo@ee.technion.a= c.il> wrote:
The issues= regarding group matching (and mis-matching) raised here and discussed
i= n other messages are indeed very important. In the case of server-only
a= uthentication this reduces to the client guessing the right g^x and thusrequires dealing with wrong guesses (this only applies to the 1-RTT case a= s in
the 0-RTT case the client learns the group together with the server= 's static
key g^s). In the mutual authentication case, if server and= client cannot agree
on using the same group for authentication, then th= e client would need to
choose its g^x in the server's group while au= thentication by the client would
require the server to send an additiona= l ServerKeyShare in the client's group.
Note, however, that in the u= se case where the parties have certificates for
signature keys and they = sign their own static DH key, clients and servers can
possess static DH = keys in different groups (without requiring a CA-issued
certificate for = each such group), hence more easily support the peer's group.

I believe the latter is the case we shou= ld optimize for, as existing systems which
do client auth general= ly use signatures and so it's easier to continue to assume
th= at then to expect that clients will get all-new certs. This seems like a na= tural
extension of the reasoning which motivates the server signi= ng their g^s in your
proposal.

-Ekr

Hugo



On Sat, Nov 1, 2014 at 11:41 AM, Nikos Mavrogiannopoulos <nmav@redhat.= com> wrote:
----- Ori= ginal Message -----
> During the TLS interim meeting of last week (Oct 22 2014) I suggested = that
> TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for P= FS and
> static Diffie-Hellman for authentication. This has multiple benefits > including
> major performance gain (by replacing the per-handshake RSA signature b= y the
> server with a much cheaper elliptic curve exponentiation), compatibili= ty
> with
> the mechanisms required for forward secrecy, natural accommodation of = a
> 0-RTT
> option, and a simple extension without signatures for client authentic= ation.

That effectively deprecates all existing infrastructure used for TLS= that pretty
much only works with RSA and ECDSA certificates (from smart cards, to HSMs = and
acceleration hardware). That's not necessarily bad, and we may already = be past the
point where TLS 1.3 can be considered a minor revision of TLS 1.2.

> PROTOCOL OPTLS:
>
> ClientHello
> ClientKeyShare
> ClientData* [K0]=C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerHello
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerKeyShare
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerCertificate* [K1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerFinished [K2]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ServerDa= ta* [K2]
> ClientFinished* [K2]=C2=A0 =C2=A0-------->
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Application D= ata [K3]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <------->
> 1-RTT CASE:
>
> The basic 1-RTT case omits the ClientData* field. It includes a
> ClientKeyShare
> g^x and a ServerKeyShare g^y and an optional (encrypted) server
> certificate.
> If the certificate is sent (it can be omitted if the client has indica= ted
> that
> it knows the server key as in the case in the 0-RTT scenario) and is > encrypted,
> the encryption key K1 is derived from g^{xy}.
>
> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is= used
> to
> authenticate-encrypt the ServerFinished and ClientFinished messages (w= hich
> include a hash of the previous traffic) and to encrypt data from the s= erver
> if
> such data is piggybacked to the second message.

How does the client get the DH (or ECDH) group parameters used = by the server?

> CLIENT AUTHENTICATION:
>
> Client authentication can be supported via an option or extension. It = would
> include a client certificate for a static DH key g^c sent in the third=
> message
> (the certificate can be encrypted under key K2 to provide client's= identity
> protection). In this case, the key for computing the ClientFinished me= ssage
> and
> the application key K3 would be derived from a combination of the valu= es
> g^xy,
> g^xs, g^yc (and possibly also g^{cs}).

As I understand client authentication as above would only work if bo= th the client
and the server share the same DH/ECDH group for their certificates, and tha= t cannot
be assumed to be true on an infrastructure that is designed to upgrade (e.g= ., change
client certs from secp192r1 to secp256r1).

regards,
Nikos


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--089e01228626d3b0860506e7ef57-- From nobody Mon Nov 3 08:48:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350201A0A6B for ; Mon, 3 Nov 2014 08:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vkHT7DYUTw0 for ; Mon, 3 Nov 2014 08:48:10 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A48C91A00C5 for ; Mon, 3 Nov 2014 08:48:10 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 82B0C6B007E for ; Mon, 3 Nov 2014 08:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0x1J8XXy9FMo5V0oO7PE k3WfSYc=; b=TlwhWJ6T8FRFXw0BMTAFSGaMg2NhTtQ+/vHM8+zIxsNV3AImGMbL 7VWlvr7/yDoKrynBnD0LlyGgww5oJGwbJvfCmZezMYrj5nT5T3Q1VSP6aylBerZ3 gLOwTCOVeSLhQHsFlYqxwQTBwwS7nGzL1ygU3VRaXexLg1mKXcDLV58= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 2EA4B6B0070 for ; Mon, 3 Nov 2014 08:48:10 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi2so6958231wib.1 for ; Mon, 03 Nov 2014 08:47:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.181.8.98 with SMTP id dj2mr17470162wid.70.1415033273837; Mon, 03 Nov 2014 08:47:53 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 3 Nov 2014 08:47:53 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Nov 2014 10:47:53 -0600 Message-ID: From: Nico Williams To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8SPZtxInWXqX_ZNPOxyydKlcarU Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:48:16 -0000 On Sun, Nov 2, 2014 at 4:24 PM, Hugo Krawczyk wrote: > Don't forget that 0-RTT cannot be supported with a signature-based protocol > so in that sense going to static DH is a win-win. That was DJB's point a while back, and, really, this goes back to the old AUTH_DH concept back in 1986. It goes back further, actually, IIUC, all the way back to DH's invention. If you know the peer's public DH key a priori (from DNSSEC, from /etc/publickey [who remembers that?]) then you can send one security context establishment message and immediately start sending encrypted and authenticated data. You need a response message to get key confirmation, and you can't get PFS until after consuming that message. (The GSS-API deals with this, incidentally. A security context can be partially established but ready to encrypt application data with security caveats. This is called "prot_ready".) A proper static-static DH + PFS exchange would take the usual 1.5 round trips, but would be "prot_ready" in 0 round trips. There's a lot to be said for this. But note that RSA key transport also lends itself to being prot_ready in 0 rt, so we still need to quantify the total cost of static-static DH + PFS, and RSA key transport + PFS for a proper comparison. Nico -- From nobody Mon Nov 3 08:53:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73581A1A2D for ; Mon, 3 Nov 2014 08:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB6iyG3bSvQg for ; Mon, 3 Nov 2014 08:53:31 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 406C91A1A2A for ; Mon, 3 Nov 2014 08:53:31 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 1FF5D674059 for ; Mon, 3 Nov 2014 08:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=sr99nScYj4eh24We/PuX +pG4K5g=; b=hNT3dOr8MtpEU7qz2Gz4oIwXYV9zCWuBwlaUIc6dD89lcocRa295 gX3juu/rr7uz5HZnMQIIVN39y8NSRpOJI2KB/7AarbuK21THLK4bOOYcWW/mp8vL vVruWfyKN3b7mwjRxz5zHoa9vAyqp2rDvAVFh2RH1E0n3rBZs8v2rMQ= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id C445E674057 for ; Mon, 3 Nov 2014 08:53:30 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so11585967wgh.29 for ; Mon, 03 Nov 2014 08:53:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.211.70 with SMTP id na6mr17379717wic.3.1415033609729; Mon, 03 Nov 2014 08:53:29 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 3 Nov 2014 08:53:29 -0800 (PST) In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> Date: Mon, 3 Nov 2014 10:53:29 -0600 Message-ID: From: Nico Williams To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l4yBB0cYmfOEAjucDI-IbgOuTHU Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:53:32 -0000 On Sun, Nov 2, 2014 at 4:28 PM, Hugo Krawczyk wrote: > The issues regarding group matching (and mis-matching) raised here and > discussed > in other messages are indeed very important. [...] More reason to use DANE... With DANE the client could find out what groups/curves the server supports before sending the first message. Again, AUTH_DH/mech_dh worked that way. The client could find the service's pubkey and group in the publickey name services database. There was no question of in-band negotiation. The protocol was effectively 0rt to get started to send data, 1rt to get key confirmation. But it long predated DNSSEC, and has been obsolete for a long time, though mostly for lack of being updated to use DNSSEC and modern crypto. Nico -- From nobody Mon Nov 3 09:11:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F321A1A2D for ; Mon, 3 Nov 2014 09:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxgz3ZKeMTkp for ; Mon, 3 Nov 2014 09:11:21 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86921A0235 for ; Mon, 3 Nov 2014 09:11:21 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 191623AAFD; Mon, 3 Nov 2014 18:11:18 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D158543B39; Mon, 3 Nov 2014 18:11:18 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CA4FE1AF8D; Mon, 3 Nov 2014 18:11:18 +0100 (CET) In-Reply-To: <5456a7c8.e94bc20a.62d5.25f2@mx.google.com> To: c.kahlo@ageto.net Date: Mon, 3 Nov 2014 18:11:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141103171118.CA4FE1AF8D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tgwNZftlc2vsvozRyncyDbOe0Ok Cc: =?UTF-8?Q?=27Manuel_P=C3=A9gouri=C3=A9-Gonnard=27?= , tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 17:11:29 -0000 Christian Kahlo wrote: > > > The last two paragraphs of > > http://tools.ietf.org/html/rfc5246#appendix- > > > E.1 > > > make that clear: "Thus, TLS servers compliant with this specification > > > MUST accept any value {03,XX} as the record layer version number for > > > ClientHello.". > > > > OK. Fixed. Checked In. Deployed. > > By the way this is an operational system. The server is PFS-only with > ECDSA_RSA activated. RC4 and Camellia are not supported and 3DES is > deactivated. TLS1.0 is supported but not enabled. None of this matters. Server that reject the Handshake because the initial ClientHello on a new connection arrived in a TLS Record with an outer { 0x03, 0x00 } protocol_version is *ACTIVELY* hurting interop in an extremely serious fashion, and server misbehaviour like this is the reason why the "downgrade dance" heuristics that current browsers are performing. The original TLS protocol provides a means for protected negotiation of protocol features, and a regular/generic client that doesn't contain any complex reconnect fallback ("downgrade dance") logic at the application level will be using { 0x03, 0x00 } in the Record Layer for the initial ClientHello. This choice will provide out-of-the-box connectivity to a few remaining old SSLv3-only servers, while simultaneously ensuring that only newer protocol versions will get used with servers that support newer TLS protocol versions. A reason why even TLS clients that do not want to talk SSLv3, would sensibly be using { 0x03, 0x00 } here, is that they can normally expect to get an SSL alert in return if the server understands the SSL/TLS record format. -Martin From nobody Mon Nov 3 09:32:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7481A1A14 for ; Mon, 3 Nov 2014 09:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15g9jH5ZMGAS for ; Mon, 3 Nov 2014 09:32:44 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DF81A1B89 for ; Mon, 3 Nov 2014 09:32:44 -0800 (PST) Received: from pc (ip5b4001eb.dynamic.kabel-deutschland.de [::ffff:91.64.1.235]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 03 Nov 2014 18:32:41 +0100 id 0000000000000026.000000005457BC39.00002BF6 Date: Mon, 3 Nov 2014 18:32:47 +0100 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: tls@ietf.org Message-ID: <20141103183247.4031dbc8@pc> In-Reply-To: References: <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <20141101101611.GA25180@LK-Perkele-VII> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-11254-1415035961-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1xM_YJHbY4oExEOPH1qoffkh1sY Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 17:32:46 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-11254-1415035961-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While you are discussing clock issues: On Blackhat Amsterdam an attack on HSTS was presented involving an NTP MitM. (code available [1]) Basically there's already a bunch of TLS related features that require a reliable clock. And ntp is a zero-security protocol. The issue of a secure system time needs to be adressed anyway. I recently changed my servers from ntpd to tlsdated. That's probably what everyone should do. (this still leaves open the question whom you trust for your timesource - but it's certainly an improvement over insecure ntp) [1] https://github.com/PentesterES/Delorean --=20 Hanno B=F6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-11254-1415035961-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUV7w/AAoJEKWIAHK7tR5CwEsP/jSLB/kmecQkpSUTL/lj/W0D unLumEXN4EqfYdLkkV1ZO+8NDzh1TtWLKACvISiarTJIRQF/8ays0ciSo4FiDAKA b6oJrssUmkPplFTHjF3F6DrmVsjsZE6Lts84s5BaSjHerhy5ZgY6RYgxxY94mz3Q JnyOLlB0MdG56uiY4G2y7i+nlQJMDeTQToKHIyxk6qDkgX6xXDYrgyi44BBSB+I+ m0ZsKolG9nJ12j5wvUfsiDX1R0MEu0mazepQmrtX/ylaZbzD6laiLhyKJwBREKEl nJFGx+IgTk59bNcXV/tOLsGzqSYntdKJlweSFDBcXHZR3TcliNwX968zO9gGbJvV 80CtzxdY6TOf6v1x9luwJa3Ys/sBP9S8seLImGljhK27dwfrh7+bC6Cjm8HadSMO B4xt0tSAHzgBD8N59SeW17yimPJpNn1Lw7ND2/7SJhkyfZNkWNwvu8nk/xl5RhvI dh2fjC3q3HKq9/aJ8GFK6jCK1W3hEZvdDzU/T1Zv+PafbEj3HihbvOy2g8PIyuVt fkHGR7b5chie6MZF7VFptzaeSwvqoXA0LDpGa25M+eEBbXf4wv3LBvXGPHKtSZ8i 3z0p83dSUchgTa8TFSPatY6yR3uIYoxH85XsjWbUk2Fo22oon+U2NY12KT65Ntmk qzPT36lf36P0hp1rBSEf =PR7o -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-11254-1415035961-0001-2-- From nobody Mon Nov 3 10:00:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96091A6F57 for ; Mon, 3 Nov 2014 10:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edAMKCvFAqPO for ; Mon, 3 Nov 2014 10:00:37 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8132B1A6F53 for ; Mon, 3 Nov 2014 10:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415037638; x=1446573638; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lyaXZIvdpE0JWhU/kAFknGvzd0jWjnPhQR3+A5/j/EM=; b=pJyFJYf7Or9rtyQlF4rKYTyCmMyQdvJVZ5IbWk2afADwixOp/iR014mX ghOScc3w1qrgIA/4zwwtENSH7K9f4N71UD4FoiRDqV+TdcRCYtagMJpuZ zRz9RkiiNlxt5QLiNz42B9ZFgJbaLGa7Gf20DIpPysz2iK14T2Q7EKKvC A=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="287434906" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Nov 2014 07:00:36 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 07:00:35 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] OPTLS: Signature-less TLS 1.3 Thread-Index: Ac/3kBBMjHGwdVuoRFOXpz39asc67A== Date: Mon, 3 Nov 2014 18:00:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DEE2D@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wdsl-GZpLXJBk87NPO820jPHfqI Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 18:00:39 -0000 Hanno B=F6ck writes:=0A= =0A= >I recently changed my servers from ntpd to tlsdated. That's probably what= =0A= >everyone should do. (this still leaves open the question whom you trust fo= r=0A= >your timesource - but it's certainly an improvement over insecure ntp)=0A= =0A= See my recent post to the SAAG list where this is also being discussed, thi= s=0A= hack already doesn't work for some TLS servers and won't work at all in the= =0A= future when the nonce is just 32 random bytes.=0A= =0A= (Also, if everyone is trusting some TLS server as their time source then al= l=0A= you need to do is spoof that server's NTP source and you've spoofed the tim= e=0A= for every client that relies on it).=0A= =0A= Peter.= From nobody Mon Nov 3 10:03:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9331A6F61 for ; Mon, 3 Nov 2014 10:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui7RgwoiOpwz for ; Mon, 3 Nov 2014 10:03:54 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643B11A19E5 for ; Mon, 3 Nov 2014 10:03:52 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id m15so6308988wgh.21 for ; Mon, 03 Nov 2014 10:03:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:cc:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=Mi+IqICvHGV19wqbBxeY3PZmKIJceyAMsInCAFAz9Q8=; b=ELI3hGy87rDHa27ExdEQphCCTKmFOYcu8OiOOJwIpY2e8tivgR5bk5Y2lDr/w994ht 8KgmmnrlDEd+GahgrrZuG+2RKCz+jTqYQO425WrpJnWaZAjYNEZY5TJU79ewo8N97VnO /1AG9mj4ps9CStfycLvGR2w2zmDzI1D+e7f5L22zlsKpU+ganv6FOuTbjI05gk9YhhFx xLR3U5ffwlm+xkXX0h/VlsLe/GmQN6PfvOLa+NNbslrm9Vuo9tUsy02K/1Powdi68uKN m9gI/q33wiCHD32wSOvqwmTwT7rQ2FwHXFl7VQsVZD6eAsqfRRN5Dube04tciOWmPcYg 1k6Q== X-Gm-Message-State: ALoCoQlbm61j+Ph8aMjtkKmApnqJq1IKVZOu9vGjAZqzK9s8sDEnhMgy8GJI0QJ8I6kOYQ1Q1jBP X-Received: by 10.180.106.104 with SMTP id gt8mr17869710wib.51.1415037831002; Mon, 03 Nov 2014 10:03:51 -0800 (PST) Received: from THINK2 (cable-158-181-87-250.cust.telecolumbus.net. [158.181.87.250]) by mx.google.com with ESMTPSA id mw7sm9528104wib.14.2014.11.03.10.03.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Nov 2014 10:03:50 -0800 (PST) Message-ID: <5457c386.477eb40a.5456.4c41@mx.google.com> X-Google-Original-Message-ID: <000001cff790$855e8830$901b9890$@kahlo@ageto.net> From: "Christian Kahlo" To: References: <5456a7c8.e94bc20a.62d5.25f2@mx.google.com> <20141103171118.CA4FE1AF8D@ld9781.wdf.sap.corp> In-Reply-To: <20141103171118.CA4FE1AF8D@ld9781.wdf.sap.corp> Date: Mon, 3 Nov 2014 19:03:48 +0100 Organization: AGETO Innovation GmbH MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/3iTBN5VvtrYqNTqqU5IGlx5/gBAABGC5g Content-Language: de Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yL1y9rXJfp5dSVLYFMY0ZmxQYEQ Cc: =?iso-8859-1?Q?'Manuel_P=E9gouri=E9-Gonnard'?= , tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: c.kahlo@ageto.net List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 18:03:56 -0000 > Christian Kahlo wrote: > > > > The last two paragraphs of > > > http://tools.ietf.org/html/rfc5246#appendix- > > > > E.1 > > > > make that clear: "Thus, TLS servers compliant with this > > > > specification MUST accept any value {03,XX} as the record layer > > > > version number for ClientHello.". > > > > > > OK. Fixed. Checked In. Deployed. > > > > By the way this is an operational system. The server is PFS-only with > > ECDSA_RSA activated. RC4 and Camellia are not supported and 3DES is > > deactivated. TLS1.0 is supported but not enabled. > > None of this matters. Server that reject the Handshake because the > initial ClientHello on a new connection arrived in a TLS Record with an > outer { 0x03, 0x00 } protocol_version is *ACTIVELY* hurting interop in > an extremely serious fashion, and server misbehaviour like this is the > reason why the "downgrade dance" heuristics that current browsers are > performing. It seems we simply missed that when adding TLS1.2. TLS1.1, the original implementation target, http://tools.ietf.org/html/rfc4346#appendix-E is less strict about this and could be interpreted in a different way. The "MUST accept {03,XX}" section is completely missing there. [1] > The original TLS protocol provides a means for protected negotiation of > protocol features, and a regular/generic client that doesn't contain > any complex reconnect fallback ("downgrade dance") logic at the > application level will be using { 0x03, 0x00 } in the Record Layer for > the initial ClientHello. This choice will provide out-of-the-box > connectivity to a few remaining old SSLv3-only servers, while > simultaneously ensuring that only newer protocol versions will get used > with servers that support newer TLS protocol versions. Already understood and fixed as stated yesterday. > A reason why even TLS clients that do not want to talk SSLv3, would > sensibly be using { 0x03, 0x00 } here, is that they can normally expect > to get an SSL alert in return if the server understands the SSL/TLS > record format. Sounds reasonable. But this server was not meant to be a "web server" serving contents for a wide range of browsers and thus SSL/TLS client libraries. Within the last 4 years we never experienced any trouble with OpenSSL (mostly patched versions for RSA-PSK support), Bouncycastle, JSSE and completely custom TLS stacks you even don't know of and probably never will. I had not seen GnuTLS to be used in this somewhat closed infra- structure. Once upon a time we did some tests with V2.4.2 and I had never used it again since these tests. Thanks for the hint, it's now compliant to RFC5246. Time to calm down. Cheers, Christian 1:"Similarly, a TLS 1.1 server that wishes to interoperate with TLS 1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a version field of {3, 0} is received, denoting that this client does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a version field of {3, 1} is received, the server SHOULD respond with a TLS 1.0 hello with a version field of {3, 1}." It simply never wished to do so and was compliant with RFC 4346 and RFC 4279 (the original target required by the German Office for Information Security). From nobody Mon Nov 3 11:32:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398AA1A711A for ; Mon, 3 Nov 2014 11:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wK9gUjlUhCfX for ; Mon, 3 Nov 2014 11:31:57 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01AA1A701A for ; Mon, 3 Nov 2014 11:31:56 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so3208154lbv.10 for ; Mon, 03 Nov 2014 11:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=R6n2E5i2A9NmtTeo36MvkINlhypyxpOM+YbVAKXsem8=; b=CWD+GtQdR12QTv+5Np22Dk/gn2D+wOahAlWUmLX/X4bbVm3HNX5v7pDcOX2vSykPFZ O3pKLM5pNC8zIHndk/RtbxfklOvaomV3P5y3OUyyysYPl8NgWjE86fAgMR0X2cVytrGK bEsr7qUVMrrsYFxde3FzcCnMeo0ZiMyo6O/fw4FxhFp1EbjRSqhVHEx10zOZV8ZBXA8c XFNBHs2tM1Wu4RP5WZfs7uUopt1wVgnueJisX0MGpHZgDNRwwbWDX4+PotSOwi3sxl9e m287JeipXZBiGl08hr5aZqad4Ky9VzD0aZue1qxxxbUGEkGgIeakjyb2J6WGXrEBZXqn okqw== MIME-Version: 1.0 X-Received: by 10.112.146.229 with SMTP id tf5mr8691221lbb.73.1415043114748; Mon, 03 Nov 2014 11:31:54 -0800 (PST) Received: by 10.25.215.134 with HTTP; Mon, 3 Nov 2014 11:31:54 -0800 (PST) In-Reply-To: <54555A79.30803@polarssl.org> References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <54555161.1040606@polarssl.org> <5455577f.e402c20a.6dee.2253@mx.google.com> <54555A79.30803@polarssl.org> Date: Mon, 3 Nov 2014 11:31:54 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sUAB9iBdDe_AtKPj-UP1uU9rUq0 Cc: c.kahlo@ageto.net, "tls@ietf.org" Subject: Re: [TLS] record-level version number in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:31:58 -0000 On 1 November 2014 15:11, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > I certainly agree about not supporting SSLv3 at all, but I'm not convince= d > rejecting record-level 03 00 this is the best thing to do . In practice t= his > mostly means rejecting clients that want to interoperate with old servers= . Yes, our current guidance is that servers SHOULD accept these sessions, as long as they don't negotiate SSLv3. [1] [1] https://github.com/unicorn-wg/sslv3-diediedie From nobody Mon Nov 3 11:41:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BC71A6F84 for ; Mon, 3 Nov 2014 11:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuwRHt3mcFGJ for ; Mon, 3 Nov 2014 11:41:28 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B1A1A00CD for ; Mon, 3 Nov 2014 11:41:27 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id gd6so8775425lab.20 for ; Mon, 03 Nov 2014 11:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gU61vDukXHuGp+cIUa/GRF54GRmWhCbn7X8q6BK+nQw=; b=VLh7OQvFC2bntdlR7+h9cRwMPd1AH6vh/+dlSav6FRrDdsco6adDyJUVqFok1AMKKC OuG0i0ydzS2+17ufJGlScpnbGiS4NzbDGUtsEmUZhmXZBMKsMCTxbC9DMcSsdX8a1/zB JnvdROsjSifybXAL/59B1dhE5nwKiYYRmoQciIOIb4ZIdqC5qoiJgGoKHRm/NFJtOxx6 hajelCiyzed1YYGhWiwX7KIVBaIkngZ55v8jBGlXSjVhBHLd3H5Y+m7fWwcJOTXOHkSb fcl6j5CJYuzJ88PLOY1e1uiJsXikoXS4BDRXLGe/s8SmPZZyQB/12g8GVUi8QI6RgQNi BIng== MIME-Version: 1.0 X-Received: by 10.112.132.104 with SMTP id ot8mr53250698lbb.3.1415043686289; Mon, 03 Nov 2014 11:41:26 -0800 (PST) Received: by 10.25.215.134 with HTTP; Mon, 3 Nov 2014 11:41:26 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DEE2D@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE2D@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 3 Nov 2014 11:41:26 -0800 Message-ID: From: Martin Thomson To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e3YxSd18nDFG-f379sbzIfWADcY Cc: "" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:41:31 -0000 On 3 November 2014 10:00, Peter Gutmann wrote: > See my recent post to the SAAG list where this is also being discussed, this > hack already doesn't work for some TLS servers and won't work at all in the > future when the nonce is just 32 random bytes. Yes, the current TLS 1.3 draft says this: opaque client_random[32]; opaque server_random[32]; With no mention of times. Though you can get a similar capability by talking to an HTTPS server you trust. Date is a mandatory header field. From nobody Mon Nov 3 19:02:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A961A1F70 for ; Mon, 3 Nov 2014 19:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxoY-zjoN_nn for ; Mon, 3 Nov 2014 19:02:27 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982781A1C05 for ; Mon, 3 Nov 2014 19:02:27 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id z6so3053103yhz.6 for ; Mon, 03 Nov 2014 19:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ceifGLYm5XmnPMd3ReYLID943+Sx4hyclhLs7OyqpGk=; b=PM0qpQilpurf28rdYm5XiZY0y4ZtY/SBhhL6BQBjUyWbVgD1aKB7d0k7ND6LNT0GlT rMTtfQmSFlcP6Md/ijFYJnAtAli0vv8gbycRW8sl/Isy18HplDVrtUUuP4QeDejnXF22 19qdePJW8EoG3I3uWiUxNAXjESxMVd06o57GokYARwk+gCAlSnYvSx6rnzaSpm9A1gED kEiQjts5a+DIbpdRStLkKa1uY7PeaxtFauojEL00lfVAO8+B76t0KH2X/FC6mb/XMU8V LZ4G4lT3LHLpAR5OOLGDMqTWmCotL5hAa2nH50l4p0bqeKx57M4BYNmW+wkKed1Hnr6d DMBA== MIME-Version: 1.0 X-Received: by 10.170.100.215 with SMTP id r206mr19811398yka.19.1415070146945; Mon, 03 Nov 2014 19:02:26 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 3 Nov 2014 19:02:26 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Nov 2014 19:02:26 -0800 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vy6mt901zdCj83m8z39tgF3R0pk Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 03:02:32 -0000 On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla wrote: > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk > wrote: >> These are good questions as they point to some of the choices we need to >> consider before defining the actual key derivation mechanisms in the >> protocol. >> Below are some responses. > > Thanks for your explanations. > > >> On Sat, Nov 1, 2014 at 3:44 AM, Eric Rescorla wrote: >> > >> > 3. WRT client auth, I think we've generally decided that the client's >> > certificate ought to be encrypted. Given that, I wonder if it would be >> > easier >> > for the client to just do a digital signature over the transcript and/or >> > an authenticator derived from the secret. Generally, the additional >> > cost of the RSA signature isn't a huge problem for most clients and >> > those which do should be able to quickly move to EC-based keys. >> >> >> I don't see the advantage of signatures in this case. It is possible to >> design a >> hybrid protocol with signature authentication at the client side and >> static DH >> at the server but I wouldn't do that without a clear advantage over the >> more >> uniform approach using static DH on both sides. In any case, doing static >> DH at >> the client should not be a problem, it is already doing it to authenticate >> the >> server and compute keys. > > > Thinking this through some more, if the client is doing certificate > authentication, it is already provisioned with a long-term signature > key and the corresponding certificate. In order to do static DH for > authentication, it must either: > > - Generate a new "static" DH key on the fly and sign it. > - Have some long-term storage where it stuffs the static DH key and > its signature. > > The first option is obviously more computationally expensive than not > doing so (though as I said above, not dramatically so if you are doing > EC). As you suggest, this isn't an issue for servers since they are > doing a lot of handshakes and can amortize the computation. However, > because the client may be slow but not do a lot of exchanges, it may > be an issue for clients. The added cost is the cost of one fixed base and one variable base exponentiation, over the existing ECDHE. Whether this is enough to recommend making one side sign the transcript and other DH is a judgement call I can't make. > > The second option may be trivial, if the client already has some > generic key storage mechanism (e.g., one in software) though it's of > course more work for the programmer. However, if the client has a > non-generic key storage mechanism, such as a smart card with their > key, then this becomes a significant problem, as it may not be able to > store a DH key and/or use it for the kind of key derivation that > would be required here. In that case, the client must find somewhere > to store the DH key, which may entail significant effort. > > > This last point points us to a larger issue we need to consider here, > which is as follows. In TLS as it currently stands (both in 1.2 and > the current TLS 1.3 draft), you can implement a system where the > authentication keys are stored in hardware and an attacker who > compromises either the client and the server cannot steal a credential > which he can then use to establish new sessions [Note that if > he steals the session cache, he can use it to resume old sessions.] > In particular, because each signature is tied to a specific exchange, > the attacker cannot reuse signed ephemeral values to impersonate the > server. 1: If ephemerals are reused, you can MITM until they are refreshed. A time-bounded cert equivalent isn't worse in this regard. 2: "Can" is the operative word here. Many people didn't, as we learned the hard way with heartbleed. The reason for this complex, but part of the issue is that the spec for using hardware devices is inherently single-threaded, so making one request per connection starts to get old real fast. Furthermore, this proposal accommodates having the key on a single device, no matter how many connections you want to serve, with no downside. It makes key separation easy. 3: 0-RTT requires a certificate that can be used for encryption as well as signing, in ways that don't interfere. We need to use a DH share anyway for this, and might as well use it again. > > However, in a system where the server signs a long-term DH value, it > may be the case that that value cannot be stored in the same hardware > module that you are using for your signature key (purely for > implementation reasons having to do with the interface the module > exposes). In that case, the DH secret will be stored in software and > compromise of the server potentially leaks a credential which can be > used to impersonate the server for a significant period of time, where > that time is dictated by the maximum amount of client-side clock error > the server is willing to tolerate, so probably measured in days to > weeks (and more if you are concerned about the time resetting attack > Watson, Ilari, and I were discussing.) I haven't decided yet sure how > serious an issue this is, but it's probably worth addressing > explicitly. I'm not sure, because it wasn't explicitly addressed in Hugo's original email, but it seems that the relevant server question is how long it wants to receive 0-RTT without requiring the client to find the new address: I don't remember resumption being addressed one way or the other. So the server isn't picking the DH share lifetime for reasons of clock skew, but rather for PFS refreshment if 0-RTT is being used. Sincerely, Watson Ladd > > -Ekr > > > > > > > > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Nov 4 00:45:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2AF1A702C for ; Tue, 4 Nov 2014 00:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibKfEouXsEIU for ; Tue, 4 Nov 2014 00:45:36 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C4A1A7002 for ; Tue, 4 Nov 2014 00:45:35 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so11818318lbj.23 for ; Tue, 04 Nov 2014 00:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tBiAdgCqG0aeAg7dqiN++B99OjSeMqQXSKTxeRB1t2g=; b=R2UeJSvC0O1K2SXVSVUKqYzfEuBO9lQC83Xah4psILZX1sFHYLS7NDHhrjflafcRmK ndnqHl/vqmTsO1fTo6FqusGmjRJJ6hPYtbedyGBhIg4liRPojhcxwY1tX0bZiptqsMrO sEUs20FmPIs1F2XZymU7RY07lHr+f7CW2w2oo7ed9laeaBpSClwrySZ9u//uu/zJQSco 7yc289Rh7lSYB9LpUraVbcr/W46M55yfTm/w685MX8BQloKfvnD1Vm7SL6aZukmMmnpG DOL6Yxba4uGriu55gL1gygYPZMiK4i2vNmZxG32t4ez/8fb+hGahqlhXZg9s4mxUeydq ecbg== X-Received: by 10.112.97.175 with SMTP id eb15mr57466067lbb.12.1415090734186; Tue, 04 Nov 2014 00:45:34 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Tue, 4 Nov 2014 00:45:04 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Tue, 4 Nov 2014 10:45:04 +0200 X-Google-Sender-Auth: K9vaDm4vQT15HT53Gn_jc70SMYg Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1133b6348946030507047c52 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NgLMGLwV6PxiU-yyi540andWEVE Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 08:45:38 -0000 --001a1133b6348946030507047c52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 3, 2014 at 12:38 AM, Eric Rescorla wrote: > > > On Sun, Nov 2, 2014 at 2:24 PM, Hugo Krawczyk > wrote: > >> >> >> On Sat, Nov 1, 2014 at 7:15 AM, Watson Ladd >> wrote: >> >>> Dear Hugo, >>> >>> There are some issues I can see: >>> >>> -Servers already supporting ECDSA certificates seem to not win. If I'm >>> understanding correctly, a server does three exponentiations, one of >>> which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The >>> servers that win are the ones with RSA certs. The only way to win vs >>> ECDSA is if DH only permits faster exponentiation, which it does, and >>> removing the ancillary junk in ECDSA. However, here we have two >>> variable base exponentiations after ephemeral reuse, as opposed to one >>> fixed, one variable, so there is a loss in performance on the same >>> group, made up for by removing inversions modulo the group order. >>> >> >> =E2=80=8BDon't forget that 0-RTT cannot be supported with a signature-ba= sed >> protocol >> > > I'm not sure that this is correct. If a client does a 1-RTT exchange firs= t > (which he will have to do if he is naive about the server) then the > server can provide a semi-static DH key for future use at that time > and use a signature over the entire transcript to authenticate it, no? > =E2=80=8BWhen I said that "0-RTT cannot be supported with a signature-based protocol" I meant to say that the key exchanged in the 0-RTT client-to-server message (used to encrypt ClientData) cannot be authenticated by a server's session-specific signature and therefore it must use a DH-based mechanism (or other PK encryption). A signature by the server can still be used to sign the semi-static key as you point out but that's an offline signature. Or maybe I misunderstood your point? =E2=80=8B > > -Ekr > > --001a1133b6348946030507047c52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 3, 2014 at 12:38 AM, Eric Rescorla <ekr@rtfm.c= om> wrote:


On Sun, Nov 2, 2014 at 2:24 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:


On Sat, Nov 1, 2014 at 7:15 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
Dear Hugo,

There are some issues I can see:

-Servers already supporting ECDSA certificates seem to not win. If I'm<= br> understanding correctly, a server does three exponentiations, one of
which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The
servers that win are the ones with RSA certs. The only way to win vs
ECDSA is if DH only permits faster exponentiation, which it does, and
removing the ancillary junk in ECDSA.=C2=A0 However, here we have two
variable base exponentiations after ephemeral reuse, as opposed to one
fixed, one variable, so there is a loss in performance on the same
group, made up for by removing inversions modulo the group order.

=E2=80=8BDon't forget that 0-RTT cannot be sup= ported with a signature-based protocol

I'm not sure that this is correct. If = a client does a 1-RTT exchange first
(which he will have to do if= he is naive about the server) then the
server can provide a semi= -static DH key for future use at that time
and use a signature ov= er the entire transcript to authenticate it, no?

=E2=80=8BWhen I said that &quo= t;0-RTT cannot be supported with a signature-based protocol"
I mean= t to say that the key exchanged in the 0-RTT client-to-server message
(u= sed to encrypt ClientData) cannot be authenticated by a server's
ses= sion-specific signature and therefore it must use a DH-based mechanism
= (or other PK encryption). A signature by the server can still be used to si= gn the
semi-static key as you point out but that's an offline signa= ture.
Or maybe I misunderstood your point?
=E2=80=8B
=C2=A0

-Ekr


--001a1133b6348946030507047c52-- From nobody Tue Nov 4 00:47:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0351A7002 for ; Tue, 4 Nov 2014 00:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtUpj4NntJOS for ; Tue, 4 Nov 2014 00:47:39 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C5D1A8882 for ; Tue, 4 Nov 2014 00:47:38 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id mc6so452539lab.26 for ; Tue, 04 Nov 2014 00:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=duB39/5+icjvOV5GHcNc3D9aebHIv8j9F22FzV2u0gA=; b=FG9TmHHOkEKfu7suZeLehgYzZJzokJBRChmkmxb93wu7WhnGqsStQBwO8YI/RF64v7 JJbVIowKdk1MQAy5/uiYp2DKZGFvqO8jWqoQ08KWlBON3Xgbn3qoPZfUDD5MD2BMfi/x VfgOE4sJQAqRX1ZwvNYaHuzns9tWIX3XREKn6K4ZoI8HBwGFGvTD5NqjIua2DOSm1HjK hO9wZhqSsEGdfjH9IlwGBwZJCiGM5TUjUgDkXL/ADwNgNfvBUR1ipWzIz4qpuKLKq5Nu WB6E9bok+AO+blHItpx8H8uwrI/ybvvv4+EjH8DhypJ+8D4Fnje2GKxbNla++6QaTA03 rQuw== X-Received: by 10.152.8.100 with SMTP id q4mr56038806laa.48.1415090856910; Tue, 04 Nov 2014 00:47:36 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Tue, 4 Nov 2014 00:47:06 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Tue, 4 Nov 2014 10:47:06 +0200 X-Google-Sender-Auth: wO3MuXeesd19VSaxW1z6x11mpiU Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c34ee0d9e66205070483de Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uHBWgNzuHIZL3aAGvl2CaAWPKeg Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 08:47:40 -0000 --001a11c34ee0d9e66205070483de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 3, 2014 at 6:47 PM, Nico Williams wrote= : > On Sun, Nov 2, 2014 at 4:24 PM, Hugo Krawczyk > wrote: > > Don't forget that 0-RTT cannot be supported with a signature-based > protocol > > so in that sense going to static DH is a win-win. > > That was DJB's point a while back, and, really, this goes back to the > old AUTH_DH concept back in 1986. It goes back further, actually, > IIUC, all the way back to DH's invention. > > If you know the peer's public DH key a priori (from DNSSEC, from > /etc/publickey [who remembers that?]) then you can send one security > context establishment message and immediately start sending encrypted > and authenticated data. You need a response message to get key > confirmation, and you can't get PFS until after consuming that > message. > > (The GSS-API deals with this, incidentally. A security context can be > partially established but ready to encrypt application data with > security caveats. This is called "prot_ready".) > > A proper static-static DH + PFS exchange would take the usual 1.5 > round trips, but would be "prot_ready" in 0 round trips. > > There's a lot to be said for this. But note that RSA key transport > also lends itself to being prot_ready in 0 rt, so we still need to > quantify the total cost of static-static DH + PFS, and RSA key > transport + PFS for a proper comparison. > =E2=80=8BThe costs for the 0-RTT option in addition to the cost of an ephem= eral DH are as follows. DH+PFS: a single variable-base exponentiation for client and server. RSA+PFS: for server an RSA decryption, for client an RSA encryption. So the computational advantage of DH+PFS is very significant for the server= . For client RSA-PFS has some advantage as RSA encryption is faster than a DH exponentiation but the difference is less dramatic than for the server, in particular considering that the client is already doing two DH exponentiations. In addition, RSA encryption requires added protocol operations (and implementation care) to prevent Bleichenbacher attack (e.g., you'll need to dummy-decrypt ClientData even if the received ciphertext is illegal). And aren't we in the process of phasing out RSA wherever possible? =E2=80=8B =E2=80=8BHugo =E2=80=8B > Nico > -- > --001a11c34ee0d9e66205070483de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 3, 2014 at 6:47 PM, Nico Williams <ni= co@cryptonector.com> wrote:
On Sun, Nov 2, 2014 at 4:24 PM, Hugo K= rawczyk <hugo@ee.technion.ac.i= l> wrote:
> Don't forget that 0-RTT cannot be supported with a signature-based= protocol
> so in that sense going to static DH is a win-win.

That was DJB's point a while back, and, really, this goes back t= o the
old AUTH_DH concept back in 1986.=C2=A0 It goes back further, actually,
IIUC, all the way back to DH's invention.

If you know the peer's public DH key a priori (from DNSSEC, from
/etc/publickey [who remembers that?]) then you can send one security
context establishment message and immediately start sending encrypted
and authenticated data.=C2=A0 You need a response message to get key
confirmation, and you can't get PFS until after consuming that
message.

(The GSS-API deals with this, incidentally.=C2=A0 A security context can be=
partially established but ready to encrypt application data with
security caveats.=C2=A0 This is called "prot_ready".)

A proper static-static DH + PFS exchange would take the usual 1.5
round trips, but would be "prot_ready" in 0 round trips.

There's a lot to be said for this.=C2=A0 But note that RSA key transpor= t
also lends itself to being prot_ready in 0 rt, so we still need to
quantify the total cost of static-static DH + PFS, and RSA key
transport + PFS for a proper comparison.

=E2=80=8BThe costs for the 0-RTT option in addition to the= cost of an ephemeral DH are as
follows.
DH+PFS: a single variable-ba= se exponentiation for client and server.
RSA+PFS: for server an RSA decr= yption, for client an RSA encryption.
So the computational advantage of = DH+PFS is very significant for the server.
For client RSA-PFS has some a= dvantage as RSA encryption is faster than a DH
exponentiation but the di= fference is less dramatic than for the server, in
particular considering= that the client is already doing two DH exponentiations.
In addition, R= SA encryption requires added protocol operations (and
implementation car= e) to prevent Bleichenbacher attack (e.g., you'll need to
dummy-decr= ypt ClientData even if the received ciphertext is illegal).
And aren'= ;t we in the process of phasing out RSA wherever possible?
=E2=80=8B=C2=A0
=E2=80=8BHugo
=E2=80=8B


Nico
--

--001a11c34ee0d9e66205070483de-- From nobody Tue Nov 4 06:13:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519F21A8765 for ; Tue, 4 Nov 2014 06:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BImwj6Dkizvh for ; Tue, 4 Nov 2014 06:13:14 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500CE1A6F90 for ; Tue, 4 Nov 2014 06:13:14 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so9514419wiv.6 for ; Tue, 04 Nov 2014 06:13:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WGFIbYCVW9xQdpkRhD7D4AHcu0ADOY1Z5MtVI0nVMNg=; b=K7Wd10JSz8cmu228UemsFB+T/T4tTnYaCx+79Ix7PWITFdoUXEZcA857xPSEndEINN jwhUgUhPeO0Zg+jaikvv4Clv09SnZlg+bL1zGJRJCNNCwEbKhZc76MvA2jkmv5YGRgYf kQ3kLrrwZdV8cbaIfQYi2Xg1SB4KtCc3MprxQgRrIUy1TaIoRx1hrCylN0YhJWvL7Ucq WX6BCnyRbunr0C2sO67eJhB7iUIQcXbHtUFYuL4XrICAaV420wOW8Ry3AYF3TAhn5b2q YNa7p8JPOf4obuITUmj3D2JY1NnQ0wnb7nuOPVfomHNWaABgOeEvFWAfIqlSLjxcsifC rUeg== X-Gm-Message-State: ALoCoQkYG22boqQ49rR+p6nPoI8h3OkZWcjT/w7lVvdjNfel8yQyXZkCIj41lmMYZ3CelMvyqZKB X-Received: by 10.194.79.201 with SMTP id l9mr56767250wjx.59.1415110392948; Tue, 04 Nov 2014 06:13:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Tue, 4 Nov 2014 06:12:31 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 4 Nov 2014 06:12:31 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bf0d0f64a38570507091052 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oZkncPJH459Twnl-rjGYTBf0_DA Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:13:17 -0000 --047d7bf0d0f64a38570507091052 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd wrote: > On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla wrote: > > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk > > The second option may be trivial, if the client already has some > > generic key storage mechanism (e.g., one in software) though it's of > > course more work for the programmer. However, if the client has a > > non-generic key storage mechanism, such as a smart card with their > > key, then this becomes a significant problem, as it may not be able to > > store a DH key and/or use it for the kind of key derivation that > > would be required here. In that case, the client must find somewhere > > to store the DH key, which may entail significant effort. > > > > > > This last point points us to a larger issue we need to consider here, > > which is as follows. In TLS as it currently stands (both in 1.2 and > > the current TLS 1.3 draft), you can implement a system where the > > authentication keys are stored in hardware and an attacker who > > compromises either the client and the server cannot steal a credential > > which he can then use to establish new sessions [Note that if > > he steals the session cache, he can use it to resume old sessions.] > > In particular, because each signature is tied to a specific exchange, > > the attacker cannot reuse signed ephemeral values to impersonate the > > server. > > 1: If ephemerals are reused, you can MITM until they are refreshed. A > time-bounded cert equivalent isn't worse in this regard. > I'm not following your reasoning here. For convenience, let's restrict ourselves to thinking about 1-RTT handshakes. With TLS 1.2 (or the current TLS 1.3 draft), the server can stop future clients from accepting any DH share simply by refusing to sign any further handshakes with that share. If, for instance, it determines a share has been compromised, it can prevent any new connection initiations with that share. By contrast, with a time-bounded cert, an attacker can get clients to continue using that share until the time expires (or perhaps longer, as you suggested elsewhere). The situation is of course somewhat more complicated with 0-RTT because the server must provide the client with a DH share which he can use for future connections. However, he need not provide every client with the *same* key, and if the key is authenticated as part of the initial connection establishment, an attacker cannot convince other clients to use that key. This is not true with certificates (or of statically signed keys) which are inherently portable. 3: 0-RTT requires a certificate that can be used for encryption as > well as signing, in ways that don't interfere. We need to use a DH > share anyway for this, and might as well use it again. I'm not sure I follow what you're saying here either. It's true that the server needs to supply a semi-static DH share, but there's no inherent reason it needs to be supplied as part of a free-standing transferrable credential such as a certificate, though of course doing so allows you to amortize the signature. > However, in a system where the server signs a long-term DH value, it > > may be the case that that value cannot be stored in the same hardware > > module that you are using for your signature key (purely for > > implementation reasons having to do with the interface the module > > exposes). In that case, the DH secret will be stored in software and > > compromise of the server potentially leaks a credential which can be > > used to impersonate the server for a significant period of time, where > > that time is dictated by the maximum amount of client-side clock error > > the server is willing to tolerate, so probably measured in days to > > weeks (and more if you are concerned about the time resetting attack > > Watson, Ilari, and I were discussing.) I haven't decided yet sure how > > serious an issue this is, but it's probably worth addressing > > explicitly. > > I'm not sure, because it wasn't explicitly addressed in Hugo's > original email, but it seems that the relevant server question is how > long it wants to receive 0-RTT without requiring the client to find > the new address: I don't remember resumption being addressed one way > or the other. So the server isn't picking the DH share lifetime for > reasons of clock skew, but rather for PFS refreshment if 0-RTT is > being used. I think we may be talking past each other. Let me try again. Forget about 0-RTT and just consider the 1-RTT flow. In the first flight the server needs to supply a signed version of g^s. Unless we want that value to be acceptable to clients indefinitely, it must have some validity interval. However, because clients have inaccurate clocks, that interval can't be too narrow or it will cause clients to reject the g^s value. I'm not sure how narrow it can be, but I would be surprised if it were less than 12 hours or so. Perhaps someone who runs a large server farm can report on the values they have historically seen in the GMT field of the ClientRandom. -Ekr --047d7bf0d0f64a38570507091052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd <watsonbladd@gmail.com= > wrote:
On Sun, = Nov 2, 2014 at 2:33 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>> = The second option may be trivial, if the client already has some
<= /div> > generic key storage mechanism (e.g., one in software) though it's = of
> course more work for the programmer. However, if the client has a
> non-generic key storage mechanism, such as a smart card with their
> key, then this becomes a significant problem, as it may not be able to=
> store a DH key and/or use it for the kind of key derivation that
> would be required here. In that case, the client must find somewhere > to store the DH key, which may entail significant effort.
>
>
> This last point points us to a larger issue we need to consider here,<= br> > which is as follows. In TLS as it currently stands (both in 1.2 and > the current TLS 1.3 draft), you can implement a system where the
> authentication keys are stored in hardware and an attacker who
> compromises either the client and the server cannot steal a credential=
> which he can then use to establish new sessions [Note that if
> he steals the session cache, he can use it to resume old sessions.] > In particular, because each signature is tied to a specific exchange,<= br> > the attacker cannot reuse signed ephemeral values to impersonate the > server.

1: If ephemerals are reused, you can MITM until they are refreshed. = A
time-bounded cert equivalent isn't worse in this regard.

I'm not following your reasoning here. For conven= ience, let's
restrict ourselves to thinking about 1-RTT hands= hakes. With
TLS 1.2 (or the current TLS 1.3 draft), the server ca= n stop future clients
from accepting any DH share simply by refus= ing to sign any
further handshakes with that share. If, for insta= nce, it determines
a share has been compromised, it can prevent a= ny new connection
initiations with that share. By contrast, with = a time-bounded
cert, an attacker can get clients to continue usin= g that share until
the time expires (or perhaps longer, as you su= ggested elsewhere).

The situation is of course som= ewhat more complicated with 0-RTT
because the server must provide= the client with a DH share which
he can use for future connectio= ns. However, he need not provide
every client with the *same* key= , and if the key is authenticated
as part of the initial connecti= on establishment, an attacker cannot
convince other clients to us= e that key. This is not true with certificates
(or of statically = signed keys) which are inherently portable.



3: 0-RTT requires a certi= ficate that can be used for encryption as
well as signing, in ways that don't interfere. We need to use a DH
share anyway for this, and might as well use it again.
I'm not sure I follow what you're saying here either. I= t's true that the
server needs to supply a semi-static DH sha= re, but there's no inherent
reason it needs to be supplied as= part of a free-standing transferrable
credential such as a certi= ficate, though of course doing so allows you
to amortize the sign= ature.


> However, in a system where the server signs a long-term DH value, it > may be the case that that value cannot be stored in the same hardware<= br> > module that you are using for your signature key (purely for
> implementation reasons having to do with the interface the module
> exposes). In that case, the DH secret will be stored in software and > compromise of the server potentially leaks a credential which can be > used to impersonate the server for a significant period of time, where=
> that time is dictated by the maximum amount of client-side clock error=
> the server is willing to tolerate, so probably measured in days to
> weeks (and more if you are concerned about the time resetting attack > Watson, Ilari, and I were discussing.) I haven't decided yet sure = how
> serious an issue this is, but it's probably worth addressing
> explicitly.

I'm not sure, because it wasn't explicitly addressed in Hugo= 's
original email, but it seems that the relevant server question is how
long it wants to receive 0-RTT without requiring the client to find
the new address: I don't remember resumption being addressed one way or the other. So the server isn't picking the DH share lifetime for
reasons of clock skew, but rather for PFS refreshment if 0-RTT is
being used.

I think we may be talking past = each other. Let me try again.

Forget about 0-RTT a= nd just consider the 1-RTT flow. In the first flight
the server n= eeds to supply a signed version of g^s. Unless we want
that value= to be acceptable to clients indefinitely, it must have some
vali= dity interval. However, because clients have inaccurate clocks,
t= hat interval can't be too narrow or it will cause clients to reject the=
g^s value. I'm not sure how narrow it can be, but I would be= surprised
if it were less than 12 hours or so. Perhaps someone w= ho runs a
large server farm can report on the values they have hi= storically
seen in the GMT field of the ClientRandom.
<= br>
-Ekr



= =C2=A0

--047d7bf0d0f64a38570507091052-- From nobody Tue Nov 4 09:49:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B981ACCE3 for ; Tue, 4 Nov 2014 09:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCtHXfOyqzRs for ; Tue, 4 Nov 2014 09:49:24 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.70.11]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA171ACCEF for ; Tue, 4 Nov 2014 09:49:24 -0800 (PST) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 6CE66757EC5AD; Tue, 4 Nov 2014 11:49:23 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 56DBF757EC55A for ; Tue, 4 Nov 2014 11:49:23 -0600 (CST) Received: from [173.73.121.234] (port=53972 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XliEM-0006gr-RL for tls@ietf.org; Tue, 04 Nov 2014 11:49:22 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Date: Tue, 4 Nov 2014 12:49:21 -0500 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XliEM-0006gr-RL X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [173.73.121.234]:53972 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wrxnUDyd4mQSOKRHmVrxdKiPX3A Subject: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 17:49:30 -0000 Hi! At the TLS Interim meeting in Paris, the WG discussed the FF DHE draft = (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/). = The chairs would like to poll the WG on one of the issues in the draft = namely the size of the minimum group. The draft currently includes a minimum group size of 2432 but the WG = also discussed 2048. Groups smaller than 2048 were discounted for a = standards track document as too weak for use but might be documented in = a separate =93historic=94 draft. To help us reach consensus on this = point, please reply to this email indicating whether you favor a =932048" = or =932432=94 minimum group size. Note we=92re also looking to specify = the smallest number of options for groups as is acceptable - i.e., we=92re= not looking at specifying both 2048 and 2432. Background: Regardless of whether you agree with what follows or not, = the following has been put forward as the rationale. We don=92t need = comments on the rationale, we=92re just providing it for background. 1) 3DES has a 112-bit work factor and is still considered acceptable in = TLS 1.2 and the DLOG keying material shouldn=92t be any weaker than the = symmetric cipher. 2) There is some disagreement about the work factor for the DLOG keys - = e.g., NIST says 112-bit work factor correlates to 2048-bit DLOG keys but = ECRYPT-II says 112-bit work factor correlates to 2432-bit DLOG keys (see = references in draft). 3) The other point made about 2048-bit DLOG is that it=92s a power of 2 = and there=92s parity with the public key sizes. Cheers, j&s= From nobody Tue Nov 4 09:56:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D0D1ACCE8 for ; Tue, 4 Nov 2014 09:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlZdeF4FBAiK for ; Tue, 4 Nov 2014 09:56:51 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1391ACCF5 for ; Tue, 4 Nov 2014 09:56:50 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id u10so3239242lbd.11 for ; Tue, 04 Nov 2014 09:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J7dLz6fsYby8fG+U1FT9rzjURYdigzzb8zoPHvO7tDE=; b=0qoA18sjTMSmS1FLetcfxnaAMg4fDnhaTP/yf07PLeAOI/ESIazJj0bISb951FXOrO k//pLVnH+Y+Z+iHMOtzRY27OvSGHl+BqzWJ2SC8JTf3pf4YMcSNldri6PsoySrSc/BnX 4XT9Js9DAetwYXOeIg+gwnnVX2ce10mOYK3FhoRGuUlhChshJeOcJ4ftpQoLjUP8qozB 0rixXSC0p2aruVUi0U25BW9/fT+saPcSvSiTfn1lk5WRyuqVp8sXow9iuBZuKm58N0Aq 5ngTL6l0yce18yYAwfmu1gvBybx9J3dM+z8PJWnSbWt42ej3NiaG2kP4Q3Z0bJDikszX +F9Q== MIME-Version: 1.0 X-Received: by 10.112.146.229 with SMTP id tf5mr16511561lbb.73.1415123808796; Tue, 04 Nov 2014 09:56:48 -0800 (PST) Received: by 10.25.215.134 with HTTP; Tue, 4 Nov 2014 09:56:48 -0800 (PST) In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Date: Tue, 4 Nov 2014 09:56:48 -0800 Message-ID: From: Martin Thomson To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7IdNitK1qMN1ha44S6TOTNsRUvo Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 17:56:53 -0000 On 4 November 2014 09:49, Sean Turner wrote: > 3) The other point made about 2048-bit DLOG is that it=E2=80=99s a power = of 2 and there=E2=80=99s parity with the public key sizes. I don't find the power of 2 thing particularly compelling when the next point is 3072. What might be more compelling is support for an assertion that 2048 is more likely to cause the extension to be used over the current arbitrary groups. Otherwise, I'm all for having stronger keys. 2432 is an odd choice, 2560 might have been easier to understand, but more is better, right? From nobody Tue Nov 4 10:46:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD1B1ACD9C for ; Tue, 4 Nov 2014 10:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxBu02iNu56L for ; Tue, 4 Nov 2014 10:46:07 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50DF1ACD9D for ; Tue, 4 Nov 2014 10:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415126765; x=1446662765; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=u3k9Rg3hvLAIsJafuYbtw6XnihetPn7BIo15ih8SSsc=; b=Z4Nme8DOoAra8HI4/Yf2NXfXWOL4l7naqg3HIINyjrZloJ5R1sL02Dou oIoLUH+JR46DYBAXgvs7zER2AbhxcfD+ZR+QatUWOwrPPB8aNABTwiCZG SCpxxH59HTjAYAEXaC+vi6mQVRwNDsEtrrkW422Ftu/kPb4SbvlcPOfcr 4=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="287664316" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Nov 2014 07:46:04 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 07:46:03 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] STRAW POLL: Size of the Minimum FF DHE group Thread-Index: Ac/4X5U+UHOue9GYRdO7jfwZXzI8mA== Date: Tue, 4 Nov 2014 18:46:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DFCB9@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kzJV3J7WHwiK1SzXsB8ayRrjIHI Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 18:46:09 -0000 Sean Turner writes:=0A= =0A= >The draft currently includes a minimum group size of 2432 but the WG also= =0A= >discussed 2048. Groups smaller than 2048 were discounted for a standards= =0A= >track document as too weak for use but might be documented in a separate = =0A= >=3D93historic=3D94 draft.=0A= =0A= See my previous comments on this, these groups are still being actively use= d,=0A= and will continue to be used until the hardware they're used with dies. So= =0A= having them documented would be useful, not least because if the IETF doesn= 't=0A= do it then some (probably several) other standards groups will do it for th= em.=0A= =0A= >The chairs would like to poll the WG on one of the issues in the draft nam= ely=0A= >the size of the minimum group.=0A= =0A= If the only choice is between 2048 and 24something then I'll go with 2048.= =0A= What's the significance of 24something anyway?=0A= =0A= Peter.= From nobody Tue Nov 4 10:55:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC61ACD88 for ; Tue, 4 Nov 2014 10:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY2Q3pJMm7nr for ; Tue, 4 Nov 2014 10:55:07 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA0F1ACD7F for ; Tue, 4 Nov 2014 10:55:07 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so8927174wgh.27 for ; Tue, 04 Nov 2014 10:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LwIEuRFQ4NM+VxT76N6plekoNQtnd99vldbI1sb3ps4=; b=hF45tcG7ygUkctbc5oKhzK///JAteZjFKq9gAFOWQNGf/fMzbH+7c0ybW1XGdSjof2 FtViChWNEHrDcZjYUesz4Kfkk1zcZKLqEiHN3ZWZwajykfV9yR7wtJr1dSG0qB4joaN3 T+K/s75ZjVBMehdrzgPQcRHE0Fo+UN6i4uK8d3qUfqOCCKgpppj9sG27bi8rUULTvsDB edKCvu9XywPtMW6+dCRV8mvUhhz8Q4xDzFJMZUpjtCEQ/CKVfsCGbDeFbOArIclnt/WT 3IRTAe03GhaAASl2PBayyUBYRgP1ZGlYgccAIDNUF5pg0WAuH3atNQbSK5WVvXbKxuQq MWNA== X-Received: by 10.194.63.79 with SMTP id e15mr19208845wjs.79.1415127305449; Tue, 04 Nov 2014 10:55:05 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-87-161.inter.net.il. [84.228.87.161]) by mx.google.com with ESMTPSA id wx3sm1480543wjc.19.2014.11.04.10.55.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 10:55:05 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Date: Tue, 4 Nov 2014 20:55:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BBD35FD-9573-415F-AEAB-FAFF37BB0255@gmail.com> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qCpHTusoPDQcoQGtlpiRi5p2oc4 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 18:55:09 -0000 2048 I have very little use for FF DHE, but matching the strength of the = certificates that are in use (and RSA 2048 is overwhelmingly more = popular at this point than ECDSA or RSA with greater values).=20 Yoav > On Nov 4, 2014, at 7:49 PM, Sean Turner wrote: >=20 > Hi! >=20 > At the TLS Interim meeting in Paris, the WG discussed the FF DHE draft = (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/). = The chairs would like to poll the WG on one of the issues in the draft = namely the size of the minimum group. >=20 > The draft currently includes a minimum group size of 2432 but the WG = also discussed 2048. Groups smaller than 2048 were discounted for a = standards track document as too weak for use but might be documented in = a separate =93historic=94 draft. To help us reach consensus on this = point, please reply to this email indicating whether you favor a =932048" = or =932432=94 minimum group size. Note we=92re also looking to specify = the smallest number of options for groups as is acceptable - i.e., we=92re= not looking at specifying both 2048 and 2432. >=20 > Background: Regardless of whether you agree with what follows or not, = the following has been put forward as the rationale. We don=92t need = comments on the rationale, we=92re just providing it for background. >=20 > 1) 3DES has a 112-bit work factor and is still considered acceptable = in TLS 1.2 and the DLOG keying material shouldn=92t be any weaker than = the symmetric cipher. >=20 > 2) There is some disagreement about the work factor for the DLOG keys = - e.g., NIST says 112-bit work factor correlates to 2048-bit DLOG keys = but ECRYPT-II says 112-bit work factor correlates to 2432-bit DLOG keys = (see references in draft). >=20 > 3) The other point made about 2048-bit DLOG is that it=92s a power of = 2 and there=92s parity with the public key sizes. >=20 > Cheers, > j&s > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 4 10:56:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FADD1ACD8D for ; Tue, 4 Nov 2014 10:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jatxv3pkw9AR for ; Tue, 4 Nov 2014 10:56:35 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C735D1ACD7F for ; Tue, 4 Nov 2014 10:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=NqH2ZZwn1ohT0Un77ORwvFbi2cl9Brp6LRfg2Zuc3TA=; b=iuP9ZPlSYb5UYZd83jKvHQ29JQoYgvGfc4G26QL41YKgFRhrdSegcNGvYDk2vQAw0myBHnqA6B+rgxtsWSGZPLLiCavaLYBEyFB+TxIJwnfSH5d4lbZU0oJbUmEmIRw7Yw+UNWfuWIE+UcTQl6ZIvKETxT7RMsY8OI1XCmBUVXM=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XljHG-0002if-95; Tue, 04 Nov 2014 19:56:26 +0100 Message-ID: <5459215F.4070204@polarssl.org> Date: Tue, 04 Nov 2014 19:56:31 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Turner , "TLS@ietf.org (tls@ietf.org)" References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aA7MpYaewaTnpjlq1WhFbSuPJTQ Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 18:56:36 -0000 2048 Manuel. On 04/11/2014 18:49, Sean Turner wrote: > Hi! > > At the TLS Interim meeting in Paris, the WG discussed the FF DHE draft (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/). The chairs would like to poll the WG on one of the issues in the draft namely the size of the minimum group. > > The draft currently includes a minimum group size of 2432 but the WG also discussed 2048. Groups smaller than 2048 were discounted for a standards track document as too weak for use but might be documented in a separate “historic” draft. To help us reach consensus on this point, please reply to this email indicating whether you favor a “2048" or “2432” minimum group size. Note we’re also looking to specify the smallest number of options for groups as is acceptable - i.e., we’re not looking at specifying both 2048 and 2432. > > Background: Regardless of whether you agree with what follows or not, the following has been put forward as the rationale. We don’t need comments on the rationale, we’re just providing it for background. > > 1) 3DES has a 112-bit work factor and is still considered acceptable in TLS 1.2 and the DLOG keying material shouldn’t be any weaker than the symmetric cipher. > > 2) There is some disagreement about the work factor for the DLOG keys - e.g., NIST says 112-bit work factor correlates to 2048-bit DLOG keys but ECRYPT-II says 112-bit work factor correlates to 2432-bit DLOG keys (see references in draft). > > 3) The other point made about 2048-bit DLOG is that it’s a power of 2 and there’s parity with the public key sizes. > > Cheers, > j&s > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Nov 4 11:05:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8F61A6F61 for ; Tue, 4 Nov 2014 11:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZaMC8BU7tnM for ; Tue, 4 Nov 2014 11:05:05 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581FD1A6F41 for ; Tue, 4 Nov 2014 11:05:05 -0800 (PST) Received: from [10.20.30.90] (50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sA4J54U7046960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2014 12:05:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Date: Tue, 4 Nov 2014 11:05:03 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wVaKu8_Jqo3xUFzLGgTr4C5Xjg0 Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:05:07 -0000 2048 to match the strength of the (likely) certificates in use. From nobody Tue Nov 4 11:11:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DF51A6FC7 for ; Tue, 4 Nov 2014 11:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izLW1d3HdW3t for ; Tue, 4 Nov 2014 11:10:55 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id B32DC1A6F67 for ; Tue, 4 Nov 2014 11:09:54 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id sA4J9T6w002790 for ; Tue, 4 Nov 2014 14:09:30 -0500 From: "Blumenthal, Uri - 0558 - MITLL" To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: [TLS] STRAW POLL: Size of the Minimum FF DHE group Thread-Index: AQHP+Fe12MwJRInyrU+r3UqxJbPzDpxRJ5yA//+tN4A= Date: Tue, 4 Nov 2014 19:09:29 +0000 Message-ID: References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497954925_37525560" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-11-04_08:2014-11-04,2014-11-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411040168 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uME5dNago0FxOaLgh6e85NRcMuU Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:10:59 -0000 --B_3497954925_37525560 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 11/4/14, 14:05 , "Paul Hoffman" wrote: >2048 to match the strength of the (likely) certificates in use. +1 (and that doesn=E2=80=99t mean 2049 :) --B_3497954925_37525560 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCD/16ZG54pmEuR3L9iMEEmj3KQ/iZvQObMf+s07fAC/7DAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMDQxOTA4NDVaMA0GCSqGSIb3 DQEBAQUABIIBAK7h7wVHcLSgU0b0zSOJX9D7uedOc7o9ND/1Vn1KCqgBg+i2j0fODWXZ8qSJ niqCBxa9HZBcYN8IalajE8mNqAO9K9z993wL2NQ9QxQgyOlk5nWYMS9MQLh4euvOWGtVPI/n 6gOIbEEl3l8wr+Wk0O2It9MoEsFhU4LAcxAiAGy6E7CLmIVnkMXJtnBB/LJen4RFIxEgdyVr HdHCIheBMk1xwIu03yXeFtmwKbG7+B1dOw0HJYL3sRKikJ3/LZRl+hoO2j05G47Xrmjk5QTV fhzuPNsSVG/eJjz8HJgPumjPKNUlBOSkRkHIsOtaPEPHMaPqJpc5IvvAGPQduFtnZBU= --B_3497954925_37525560-- From nobody Tue Nov 4 11:14:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA1E1A6EE4 for ; Tue, 4 Nov 2014 11:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o23ionmdYmbR for ; Tue, 4 Nov 2014 11:14:53 -0800 (PST) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504961A6FD4 for ; Tue, 4 Nov 2014 11:14:53 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sA4JElt8032669; Tue, 4 Nov 2014 14:14:47 -0500 Date: Tue, 4 Nov 2014 14:14:47 -0500 (EST) From: Nikos Mavrogiannopoulos To: Sean Turner Message-ID: <1181732170.4489590.1415128487858.JavaMail.zimbra@redhat.com> In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: STRAW POLL: Size of the Minimum FF DHE group Thread-Index: wd5fT+EIUaIWnfIHzWVHaI1RcJP0WQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iC1_w9MhdV8ZjiP2Savn2KVAXOE Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:14:54 -0000 ----- Original Message ----- [...] > Background: Regardless of whether you agree with what follows or not, the > following has been put forward as the rationale. We don=E2=80=99t need co= mments on > the rationale, we=E2=80=99re just providing it for background. >=20 > 1) 3DES has a 112-bit work factor and is still considered acceptable in T= LS > 1.2 and the DLOG keying material shouldn=E2=80=99t be any weaker than the= symmetric > cipher. >=20 > 2) There is some disagreement about the work factor for the DLOG keys - e= .g., > NIST says 112-bit work factor correlates to 2048-bit DLOG keys but ECRYPT= -II > says 112-bit work factor correlates to 2432-bit DLOG keys (see references= in > draft). >=20 > 3) The other point made about 2048-bit DLOG is that it=E2=80=99s a power = of 2 and > there=E2=80=99s parity with the public key sizes. I vote for 2432. Since we have two conflicting advices (NIST and ECRYPT), I= MO the best is to go with the most conservative one (especially given that thi= s draft is going to be fully deployed years from now). regards, Nikos From nobody Tue Nov 4 11:20:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766C21A6FD5 for ; Tue, 4 Nov 2014 11:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-eu9haPqdbA for ; Tue, 4 Nov 2014 11:20:57 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63261A6FD4 for ; Tue, 4 Nov 2014 11:20:56 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id dc16so10322894qab.6 for ; Tue, 04 Nov 2014 11:20:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=nMKJZoglmxCQnL9Q0gFzCLfN3BwjOc5FqTItmBpj99Q=; b=ZTxZpECugFKHYeVWn+49PwntEn1LRYBk9W95rngd3zsWjKZ1vQC1j02PybV8t4u+AA 1mKiKQHzHYk1qVRP6S+F5HhhIqoCyGk54U0622Bjt7s4q8rxksgvhM5FqreY4pm2+tlY FC9+59fCGyomjhcYZSuXvOfLvnvDocdVYbd1BZoPC9esiJRIOADTix1+0SmGlUf37Kkq yaE5CFeDvFVlBEmHHsV7FitqNMp0EXr9zxbGMDHIidbrFNTjjygnHy9NqztSLpsnHmfl fdLlgCDHiXSfV9ZAfXAW3m9PFytOnN/1rCeMsXDLz2YYjD5yiKilmJkKKZ7Nnf91N9C3 1QlA== X-Gm-Message-State: ALoCoQlz826WnazJt/KYZgbh6e2nMeSo6Tf125zgzegpRZBlYyr3llyWhmzdPOCdcrhvWVWH3s0o X-Received: by 10.224.160.83 with SMTP id m19mr79851670qax.17.1415128855518; Tue, 04 Nov 2014 11:20:55 -0800 (PST) Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id 36sm1130138qgn.10.2014.11.04.11.20.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 11:20:54 -0800 (PST) Received: from [10.2.237.186] (unknown [67.51.141.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 8F4A7AC2869 for ; Tue, 4 Nov 2014 14:20:51 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <1181732170.4489590.1415128487858.JavaMail.zimbra@redhat.com> Date: Tue, 4 Nov 2014 12:20:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29FF590F-3091-43FA-8417-77DC3FD0F1BA@pahtak.org> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> <1181732170.4489590.1415128487858.JavaMail.zimbra@redhat.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4lmdcce5XiQi8QAu7v6FXU4xQM8 Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:20:58 -0000 On Nov 4, 2014, at 12:14 PM, Nikos Mavrogiannopoulos = wrote: > ----- Original Message ----- > [...] >> Background: Regardless of whether you agree with what follows or not, = the >> following has been put forward as the rationale. We don=92t need = comments on >> the rationale, we=92re just providing it for background. >>=20 >> 1) 3DES has a 112-bit work factor and is still considered acceptable = in TLS >> 1.2 and the DLOG keying material shouldn=92t be any weaker than the = symmetric >> cipher. >>=20 >> 2) There is some disagreement about the work factor for the DLOG keys = - e.g., >> NIST says 112-bit work factor correlates to 2048-bit DLOG keys but = ECRYPT-II >> says 112-bit work factor correlates to 2432-bit DLOG keys (see = references in >> draft). >>=20 >> 3) The other point made about 2048-bit DLOG is that it=92s a power of = 2 and >> there=92s parity with the public key sizes. >=20 > I vote for 2432. Since we have two conflicting advices (NIST and = ECRYPT), IMO > the best is to go with the most conservative one (especially given = that this > draft is going to be fully deployed years from now). Going with ECRYPT-II's recommendation of 2432 as it is the more = conservative advice gets my vote. --=20 Stephen Checkoway From nobody Tue Nov 4 11:23:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52BD1A6FD4 for ; Tue, 4 Nov 2014 11:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlfUJxzPThMj for ; Tue, 4 Nov 2014 11:23:04 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 923D11A6F58 for ; Tue, 4 Nov 2014 11:23:04 -0800 (PST) Received: from [10.70.10.71] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0E688F984 for ; Tue, 4 Nov 2014 14:23:01 -0500 (EST) Message-ID: <54592789.2030207@fifthhorseman.net> Date: Tue, 04 Nov 2014 14:22:49 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: IETF TLS WG References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ra7R6M1gQOsLRe5XRjDgVPg1xRQWip16p" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Mul0etdAxsFtpdJeBX2R-enGNN8 Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:23:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ra7R6M1gQOsLRe5XRjDgVPg1xRQWip16p Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/04/2014 12:49 PM, Sean Turner wrote: > The draft currently includes a minimum group size of 2432 but the WG al= so discussed 2048. Groups smaller than 2048 were discounted for a standa= rds track document as too weak for use but might be documented in a separ= ate =E2=80=9Chistoric=E2=80=9D draft. To help us reach consensus on this= point, please reply to this email indicating whether you favor a =E2=80=9C= 2048" or =E2=80=9C2432=E2=80=9D minimum group size. Note we=E2=80=99re a= lso looking to specify the smallest number of options for groups as is ac= ceptable - i.e., we=E2=80=99re not looking at specifying both 2048 and 24= 32. as the original author who selected 2432, i still think 2432 is the most reasonable choice based on ECRYPT's assessments. --dkg --Ra7R6M1gQOsLRe5XRjDgVPg1xRQWip16p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUWSeJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpc/LoP/jJP92OooxB7w7XckPeTV2za 2fNWbEP/YPU51qos8NALZbAvI3WiLyPsvFHKha4MRMR7pW7daOcuDIwGk7L1H/Yv Olgvi32cXU69xhcRzo3ZB9PazoTyeoWzFufTIMjWXKXyzdodtl1NAiCKKKV5Ftmy C1na2QWGqvHVJuk29YLnRlK3uaM3ZbcpaBao9KiViNubqdexbI2JtWYie+jZWIil jeHbGAobII6ahKhYTxzdEp10vwX8KNGHWCJleajWs9hhHAJMV6Z9JviM3VoR3XJW wlIZc1jCe472Pji4S90bP0Hhi/cW7FNUZ0ufuBUUuZwbkwmRE4ESDYajELgpKsHH vwf9EMO1R07AL8JseNBJY2v+J8oixcw1sAIGUeGoSKqnwM3DO+rbuFh+xJISGXYK kozkm58hJkoM/uDmztxO6mzaR1K3TsOS8sRLvUxRql79P4ax6F7/mfEtTiIiLTYP 6dwZvZODtmQrrgoiiGrT4hRGWk7+kaB0TMDRmAtgQTjFcdzcDgnbTLmZECmINuTB cKVHQTNnAcO4kjW1kwWyFaN+yt1CQPQ2uGzt5rnCIb/ZhzLFjzjCA5x+IyPByhpI eYlwPo2VJsIK5ZXCygHa01rWR+aCyEDzkmvjn0zQ/RU3duQbOhCM8dy1fBhheggR ylZhTkDhJ9Im8W3ed9zS =lViF -----END PGP SIGNATURE----- --Ra7R6M1gQOsLRe5XRjDgVPg1xRQWip16p-- From nobody Tue Nov 4 11:24:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0491A6FE8 for ; Tue, 4 Nov 2014 11:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWCfXryYFGHb for ; Tue, 4 Nov 2014 11:24:36 -0800 (PST) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE561A6FD4 for ; Tue, 4 Nov 2014 11:24:36 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sA4JOZEh030775; Tue, 4 Nov 2014 14:24:35 -0500 Date: Tue, 4 Nov 2014 14:24:35 -0500 (EST) From: Nikos Mavrogiannopoulos To: Paul Hoffman Message-ID: <1752530545.4492650.1415129075696.JavaMail.zimbra@redhat.com> In-Reply-To: References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: STRAW POLL: Size of the Minimum FF DHE group Thread-Index: 41R42FSzwRVmlyciHLZT1aa3qsU91w== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VL26R8bllcVzcM1_zCSqoeuWXRM Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:24:37 -0000 ----- Original Message ----- > 2048 to match the strength of the (likely) certificates in use. That's not a good argument. If in 4 years the 2048-bit certificates are broken, we can simply reissue stronger ones with no damage to past sessions. If the 2048-bit DH can be broken, all the past sessions could be read. The DH parameters relate more to the security of the encryption function, rather than the certificate's. regards, Nikos From nobody Tue Nov 4 11:51:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7241A7029 for ; Tue, 4 Nov 2014 11:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g0n9l2jF7UX for ; Tue, 4 Nov 2014 11:51:14 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6501A6FEB for ; Tue, 4 Nov 2014 11:51:13 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-03v.sys.comcast.net with comcast id BXqv1p0064yXVJQ01XrDUJ; Tue, 04 Nov 2014 19:51:13 +0000 Received: from [IPv6:::1] ([71.202.164.227]) by resomta-po-06v.sys.comcast.net with comcast id BXrC1p00N4uhcbK01XrCwD; Tue, 04 Nov 2014 19:51:13 +0000 Message-ID: <54592E30.2000208@brainhub.org> Date: Tue, 04 Nov 2014 11:51:12 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415130673; bh=4eW1HAyEevJ1w/ReejydiximhUlVp6MQizfMwCKFU4g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N9AX+tPMj19Mt/5gy/Zfww2aPTh1IxuRicqCPZo75wr2cBntTxvmLutqvVk49u4tl Lh7n3joAR/QNRXIxmCS3l/gTIIuXGemFUXHBwqTWLFYSgSxCsCcn1ctWrAf9rOegtJ FubXS9IFyTl5i/yxjoa7XFkf56YnB7J3RuIbhkYqwSmNw1PBUsn1k8hpfFRzpkDFuk 0wZ0ehC2OxYklPWg6Psr6MdJnYoiZY7Nls0bjSqFq03JEvgyV2WknrUA9up6KMRoCX xi9K17n7j+V4wGa77BSbQAxlUW0hkMU5f6S80IldZG22knQapgPEJvaN6/RkdP37pB 9AZhwq7saXCoA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v-LqfAujoiK1iVJFDC9nvWoO4OU Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:51:16 -0000 On 11/04/2014 09:49 AM, Sean Turner wrote: > 2) There is some disagreement about the work factor for the DLOG keys - e.g., NIST says 112-bit work factor correlates to 2048-bit DLOG keys but ECRYPT-II says 112-bit work factor correlates to 2432-bit DLOG keys (see references in draft). > > 3) The other point made about 2048-bit DLOG is that it’s a power of 2 and there’s parity with the public key sizes. An interesting question is if 2432 is optimal to accommodate wide words / vector arithmetic. 2^9 * 5 = 2560 (5 512-bit units, or 10 128-bit units) 2^7 * 19 = 2432 (128 bit units) Besides, there is a benefit to pick a round number. For example, RSA 2048 is much faster than 2432 in openssl master today on x86. So, while I am OK with a stronger size, 2432 looks like sub-optimal, so of these two I would select RSA 2048. From nobody Tue Nov 4 13:38:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FCC1A0012 for ; Tue, 4 Nov 2014 13:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvPkJDfA9G3H for ; Tue, 4 Nov 2014 13:37:57 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853F41A0019 for ; Tue, 4 Nov 2014 13:37:57 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id gd6so1652562lab.20 for ; Tue, 04 Nov 2014 13:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aiYNtZdnOEm7+QXG4L66+acGlVhZrSqwL1aPC2keuGU=; b=u1TOKW/1Y3+x4qdbK4Mo9QgaZRYLCllP0kOySArI3a6BbIdLPJdR/OBGPRqNvs7amG LNA6iFxtIgC+uPQs7h0SUdEYCZqE4rTYOHl94KkSYndZeA267z39XRonLKyUR93HRrWU llAAcEVyOMcDo7SrlkJSw3Fn+A28mnYNVkllWpvGgbvqvTr8ZaeDY7pMiQ7L10SjZwMh wm+iyANeqrVWxembbOWOdQY8G6w6ibD5OeEsWATL0QqMvux16Xyhp73MV2vii5/SRj6h yhLIBX9xQPKdWLbQsXWpDLydaOXN2HHCA+FKImD+1GAX92BAzzG5T3QtyXjRZliGTG4r 74WA== MIME-Version: 1.0 X-Received: by 10.112.54.229 with SMTP id m5mr62422426lbp.11.1415137075768; Tue, 04 Nov 2014 13:37:55 -0800 (PST) Received: by 10.25.215.134 with HTTP; Tue, 4 Nov 2014 13:37:55 -0800 (PST) In-Reply-To: <1752530545.4492650.1415129075696.JavaMail.zimbra@redhat.com> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> <1752530545.4492650.1415129075696.JavaMail.zimbra@redhat.com> Date: Tue, 4 Nov 2014 13:37:55 -0800 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/I4zMPLiq0edoV5TveXzJ63eMrN4 Cc: Paul Hoffman , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 21:37:59 -0000 On 4 November 2014 11:24, Nikos Mavrogiannopoulos wrote: > That's not a good argument. If in 4 years the 2048-bit certificates > are broken, we can simply reissue stronger ones with no damage to past > sessions. If the 2048-bit DH can be broken, all the past sessions could > be read. I'm actually not a big fan of the argument from alignment: A strong ephemeral exchange protects session confidentiality from some future break or brute forcing (if that's even feasible), outside of the window where an active attack (impersonation or hijacking) based on a break might be possible. If keys are properly ephemeral, an attacker only has while the session is active (or resumptions of the session). A strong authentication key protects a session from MitM attacks at the time of session creation. Authentication keys also have an applicability window, which is limited by the expiration of the associated certificate (plus the relevant clock skew under the NTP-style attacks). There's an argument to be had for stronger ephemeral keys on this basis. In the end, I don't care particularly. I'd like to know if anyone making arguments for either side feels so strongly that they would strongly object to either. If we're just assembling preferences, then it's hard to see a way we can reach consensus on whether number A is better than number B. p.s., Clearly 2^521-1 is the best number. It's not even clear that there is any point arguing about the minor placings. From nobody Tue Nov 4 17:23:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58A31A1ADC for ; Tue, 4 Nov 2014 17:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGehXpIquqb2 for ; Tue, 4 Nov 2014 17:23:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1426A1A1A31 for ; Tue, 4 Nov 2014 17:23:16 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BF7882AB04A; Wed, 5 Nov 2014 01:23:14 +0000 (UTC) Date: Wed, 5 Nov 2014 01:23:14 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141105012314.GG23599@mournblade.imrryr.org> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u36ra84CVvY3fnAiaBdoCMgVP98 Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 01:23:18 -0000 On Tue, Nov 04, 2014 at 12:49:21PM -0500, Sean Turner wrote: > The draft currently includes a minimum group size of 2432 but the WG also > discussed 2048. Groups smaller than 2048 were discounted for a standards > track document as too weak for use but might be documented in a separate > "historic" draft. To help us reach consensus on this point, please reply > to this email indicating whether you favor a "2048" or "2432" minimum > group size. Note we're also looking to specify the smallest number of > options for groups as is acceptable - i.e., we're not looking at specifying > both 2048 and 2432. > > Background: Regardless of whether you agree with what follows or not, the > following has been put forward as the rationale. We don't need comments > on the rationale, we're just providing it for background. Has any consideration been given to the question of how much of a barrier to the use of Forward-Secrecy larger key sizes might pose? If using DHE imposes a sufficient performance cost, sites might choose to disable (P)FS, and stick with RSA key exchange. I take it the new DHE $\mathbb{Z}^*_p$ subgroups will be cyclic with prime order $q$, where $q$ is a much shorter prime (twice the desired security level bits as with the various DSA groups). If so, how much of a performance advantage does this provide relative to using generic $F_p$ groups for which the order of the generator is not known (as with DHE in TLS today)? Basically, what's the expected ratio of DH-per-second between the two proposed field sizes, and between the 2048-bit group and $F_p$ with $q = (p-1)/2$ and $p$ a 2048-bit Sophie-Germain prime. Is the "new" 2432 as fast or faster than the "old" 2048? Choices of parameters are a trade-off. With unlimited CPU/network we could go with 16k-bit primes. It is difficult to make such a trade-off without some knowledge of the relative costs/benefits. What is our lowest estimated cost to the adversary of breaking 2048-bit DH with purpose-built hardware? What is the cost to the defender of using 2432 vs. 2048? -- Viktor. From nobody Tue Nov 4 17:39:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435861A1AF1 for ; Tue, 4 Nov 2014 17:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dHfykkxGMLo for ; Tue, 4 Nov 2014 17:39:52 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [64.5.38.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121FF1A1AE7 for ; Tue, 4 Nov 2014 17:39:52 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 8908E2C7B8D06; Tue, 4 Nov 2014 19:39:51 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 77D462C7B8CC0 for ; Tue, 4 Nov 2014 19:39:51 -0600 (CST) Received: from [173.73.121.234] (port=58963 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XlpZe-0000zz-D3 for tls@ietf.org; Tue, 04 Nov 2014 19:39:50 -0600 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> Date: Tue, 4 Nov 2014 20:39:48 -0500 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XlpZe-0000zz-D3 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:58963 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q_sPvpN8XegVR4fg_bB-UOlL_MM Subject: [TLS] TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 01:39:53 -0000 Posted draft minutes: http://www.ietf.org/meeting/interim/proceedings.html spt From nobody Tue Nov 4 18:19:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3405F1A8795 for ; Tue, 4 Nov 2014 18:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9j4do1smnAP for ; Tue, 4 Nov 2014 18:19:04 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4981A8794 for ; Tue, 4 Nov 2014 18:19:04 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 131so142599ykp.0 for ; Tue, 04 Nov 2014 18:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=M/I0FIFpujqTd1AKawc2n1nH9IyRo3FH1Ogn4iNqqjk=; b=vMaMrzYmUGcUeY3AtfW6JlbNEnv3LNGfqhH7H2kPpxqmuPtZI+lDKLslPKkaokmNo6 HN6yGZsZ99Bpn7k+kCmP92wIuo1wOdMZYpMuYYgiDRpSh028nG4SnZG0WZR3sW0gseOp Fj+Y0hfI+kdTDKSM88K0kmZAVMLA7kWRUJ0w1zniQp8iL8wNArcIURCdeBhK+qVCsi/j bqPsESaMwy86ojlkhTWVnapKMHq65yp2ncxw4kPjzI98eUWNWEPspuG4HQWTAGhWhBL9 sn8Ws3C2EMlLf+gkx7CJm5zK6+XHYnKDixT41TXFKQwqEG8Xb1pg2DOzZyDVJuZR7Y6J CEvQ== MIME-Version: 1.0 X-Received: by 10.170.213.130 with SMTP id e124mr14430123ykf.24.1415153943513; Tue, 04 Nov 2014 18:19:03 -0800 (PST) Received: by 10.170.195.203 with HTTP; Tue, 4 Nov 2014 18:19:03 -0800 (PST) In-Reply-To: <20141105012314.GG23599@mournblade.imrryr.org> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> <20141105012314.GG23599@mournblade.imrryr.org> Date: Tue, 4 Nov 2014 18:19:03 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uMUxyh3g4LBsleO4foVs1DQzAJk Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 02:19:06 -0000 On Tue, Nov 4, 2014 at 5:23 PM, Viktor Dukhovni wrote: > On Tue, Nov 04, 2014 at 12:49:21PM -0500, Sean Turner wrote: > >> The draft currently includes a minimum group size of 2432 but the WG also >> discussed 2048. Groups smaller than 2048 were discounted for a standards >> track document as too weak for use but might be documented in a separate >> "historic" draft. To help us reach consensus on this point, please reply >> to this email indicating whether you favor a "2048" or "2432" minimum >> group size. Note we're also looking to specify the smallest number of >> options for groups as is acceptable - i.e., we're not looking at specifying >> both 2048 and 2432. >> >> Background: Regardless of whether you agree with what follows or not, the >> following has been put forward as the rationale. We don't need comments >> on the rationale, we're just providing it for background. > > Has any consideration been given to the question of how much of a > barrier to the use of Forward-Secrecy larger key sizes might pose? > > If using DHE imposes a sufficient performance cost, sites might > choose to disable (P)FS, and stick with RSA key exchange. They could also adopt ECC if performance is a concern. > > I take it the new DHE $\mathbb{Z}^*_p$ subgroups will be cyclic > with prime order $q$, where $q$ is a much shorter prime (twice the > desired security level bits as with the various DSA groups). If > so, how much of a performance advantage does this provide relative > to using generic $F_p$ groups for which the order of the generator > is not known (as with DHE in TLS today)? They are not of that form, but rather q=(p-1)/2. However, short exponents can still be used to accelerate DHE: this is independent of the group's order. This cannot be done with signature keys. > > Basically, what's the expected ratio of DH-per-second between the > two proposed field sizes, and between the 2048-bit group and $F_p$ > with $q = (p-1)/2$ and $p$ a 2048-bit Sophie-Germain prime. Is > the "new" 2432 as fast or faster than the "old" 2048? Slower, by a quadratic factor assuming standard algorithms for bignum arithmetic. No acceleration of either is possible, and for good reason: SNFS uses the same characteristics as we would use to optimize arithmetic. > > Choices of parameters are a trade-off. With unlimited CPU/network > we could go with 16k-bit primes. It is difficult to make such a > trade-off without some knowledge of the relative costs/benefits. ECC is the best choice by a wide margin here. > > What is our lowest estimated cost to the adversary of breaking > 2048-bit DH with purpose-built hardware? Significantly worse than 2048-bit RSA, due to being able to reuse the relations and build a large factor base that will accelerate the finding of additional discrete logs. > > What is the cost to the defender of using 2432 vs. 2048? > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Nov 4 19:15:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469C41A1B82 for ; Tue, 4 Nov 2014 19:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXMGrcsZqr6E for ; Tue, 4 Nov 2014 19:15:55 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id C20501A1BDC for ; Tue, 4 Nov 2014 19:15:55 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 3F0219A448E; Tue, 4 Nov 2014 22:15:45 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5bB2gujJv1xp; Tue, 4 Nov 2014 22:15:24 -0500 (EST) Received: from [192.168.8.146] (unknown [64.129.13.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C4C0D9A448C; Tue, 4 Nov 2014 22:15:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Date: Tue, 4 Nov 2014 22:15:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q5GKm9oP4pPMiG5Hw4D8bbTUe2Y Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 03:15:57 -0000 I support inclusion of 2048-bit FF DHE kays. Russ On Nov 4, 2014, at 12:49 PM, Sean Turner wrote: > Hi! >=20 > At the TLS Interim meeting in Paris, the WG discussed the FF DHE draft = (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/). = The chairs would like to poll the WG on one of the issues in the draft = namely the size of the minimum group. >=20 > The draft currently includes a minimum group size of 2432 but the WG = also discussed 2048. Groups smaller than 2048 were discounted for a = standards track document as too weak for use but might be documented in = a separate =93historic=94 draft. To help us reach consensus on this = point, please reply to this email indicating whether you favor a =932048" = or =932432=94 minimum group size. Note we=92re also looking to specify = the smallest number of options for groups as is acceptable - i.e., we=92re= not looking at specifying both 2048 and 2432. >=20 > Background: Regardless of whether you agree with what follows or not, = the following has been put forward as the rationale. We don=92t need = comments on the rationale, we=92re just providing it for background. >=20 > 1) 3DES has a 112-bit work factor and is still considered acceptable = in TLS 1.2 and the DLOG keying material shouldn=92t be any weaker than = the symmetric cipher. >=20 > 2) There is some disagreement about the work factor for the DLOG keys = - e.g., NIST says 112-bit work factor correlates to 2048-bit DLOG keys = but ECRYPT-II says 112-bit work factor correlates to 2432-bit DLOG keys = (see references in draft). >=20 > 3) The other point made about 2048-bit DLOG is that it=92s a power of = 2 and there=92s parity with the public key sizes. >=20 > Cheers, > j&s From SRS0=YCei=73=acm.org=bmoeller@srs.kundenserver.de Wed Nov 5 00:30:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0441A8828 for ; Wed, 5 Nov 2014 00:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.677 X-Spam-Level: X-Spam-Status: No, score=0.677 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QICtId90YjKT for ; Wed, 5 Nov 2014 00:30:26 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9581A8824 for ; Wed, 5 Nov 2014 00:30:25 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0Lw14n-1Y6LiM1BzJ-017lJe; Wed, 05 Nov 2014 09:30:23 +0100 Received: by mail-ob0-f170.google.com with SMTP id nt9so208084obb.15 for ; Wed, 05 Nov 2014 00:30:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.225.212 with SMTP id y203mr23745164oig.16.1415176222144; Wed, 05 Nov 2014 00:30:22 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 00:30:22 -0800 (PST) In-Reply-To: <545514AE.9080100@polarssl.org> References: <20141031012622.2D0721AF6E@ld9781.wdf.sap.corp> <545514AE.9080100@polarssl.org> Date: Wed, 5 Nov 2014 09:30:22 +0100 Message-ID: From: Bodo Moeller To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: multipart/alternative; boundary=001a113d2dfe0400ae050718640e X-Provags-ID: V02:K0:jg4q5ljdJ/1rQ1etIK91Wybkcj91bLztc5fX1GHUApl vKIPs9L3jCUf69/bCuSDTSB0FiuFwfAndAoF2pWNydAQSMZwpt gWIjOzDAYypJz+L1j5v1YAnKpgyLUWjKy8cqkvW+Qb7C+91caN eHEOrfziPb2hFK38EIIkFEU1gkwNCsKULACzdnffEVnKUyR2Ki V5VbwHi/JCpMNDDl82I/GaEUI4Fg74CsIpWwhy622KFjPJRcpi RJHHbMpKqOIjdFESKvOgTyHydpFYoVgfoFZ0ItjdzQ8ucK6La1 +zV7SZm6PFHB9WpDeikRmLdIKEFqlLuaWI1hpgSy0WTwNsVrBb grKOq+j+7/Asd8AlkHqjMF1UNT9lWO74Eo63erBgku/v5Tt66d V4yVjpsMmgbU9pSfsCBtK6ON3te/TyYB4yxdrCn15K6eReYAZ0 jgrWN X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Nf2vhsBYcCFN4FFcaONmpWmP_Ds Cc: "tls@ietf.org" Subject: Re: [TLS] Minutes from Tuesday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 08:54:21 -0000 --001a113d2dfe0400ae050718640e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Manuel P=C3=A9gouri=C3=A9-Gonnard : > Martin Rex wrote: > > Bodo Moeller wrote: > >> [...] reacting to a fatal alert is something that all TLS > >> implementations already know how to do. > > > That reaction is called interop failure. That is the far opposite > > of what IETF working groups are supposed to consciously cause to happen > > when the alternative would be to make interop succeed. > > I'm not so sure. There are already a lot of situations where > implementations are > requires to make the handshake fail, eg if the verify data from the > Finished > message don't match, which indicates the handshake data has been tampered > with. > This is not entirely different, the main difference is that the suspected > tampering happened during the previous handshake. > > I'm not saying breaking the handshake is the only right thing to do, I ca= n > see > the benefits of the solution you suggest, but I think the simplicity of t= he > current draft is a big advantage in getting it widely (and correctly) > deployed > sooner rather than later, which IMO outweighs the advantages of a more > complex > approach. > Right. If we figure out how to make more handshakes succeed immediately without a fallback dance, that's completely orthogonal to TLS_FALLBACK_SCSV (which won't be needed in such handshakes). Any such proposal will be considerably more complex than the TLS_FALLBACK_SCSV mechanism, and I think there's no excuse for allowing downgrade attacks to happen until it is deployed. Bodo --001a113d2dfe0400ae050718640e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Manu= el P=C3=A9gouri=C3=A9-Gonnard <mpg@polarssl.org>:
Martin Rex wrote:
> Bodo Moeller wrote:
=C2=A0
>> [...] reacting to a fatal alert is something that all TLS
>> implementations already know how to do.
=C2=A0
> That reaction is called interop failure.=C2=A0 That is the far opposit= e
> of what IETF working groups are supposed to consciously cause to happe= n
> when the alternative would be to make interop succeed.
=C2=A0
I'm not so sure. There are already a lot of situations where imp= lementations are
requires to make the handshake fail, eg if the verify data from the Finishe= d
message don't match, which indicates the handshake data has been tamper= ed with.
This is not entirely different, the main difference is that the suspected tampering happened during the previous handshake.

I'm not saying breaking the handshake is the only right thing to do, I = can see
the benefits of the solution you suggest, but I think the simplicity of the=
current draft is a big advantage in getting it widely (and correctly) deplo= yed
sooner rather than later, which IMO outweighs the advantages of a more comp= lex
approach.

Right. If we figure out how t= o make more handshakes succeed immediately without a fallback dance, that&#= 39;s completely orthogonal to TLS_FALLBACK_SCSV (which won't be needed = in such handshakes).

Any such proposal will be con= siderably more complex than the TLS_FALLBACK_SCSV mechanism, and I think th= ere's no excuse for allowing downgrade attacks to happen until it is de= ployed.

Bodo

--001a113d2dfe0400ae050718640e-- From nobody Wed Nov 5 01:01:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545B71A882B for ; Wed, 5 Nov 2014 01:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCQFjfVE4JTD for ; Wed, 5 Nov 2014 01:01:48 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467861A87F0 for ; Wed, 5 Nov 2014 01:01:48 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0MH3Pq-1Xqs8p2x9e-00Dq7K; Wed, 05 Nov 2014 10:01:46 +0100 Received: by mail-ob0-f169.google.com with SMTP id va2so215802obc.28 for ; Wed, 05 Nov 2014 01:01:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.213.2 with SMTP id no2mr482422obc.76.1415178104303; Wed, 05 Nov 2014 01:01:44 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 01:01:44 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DFCB9@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9DFCB9@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 5 Nov 2014 10:01:44 +0100 Message-ID: From: Bodo Moeller To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a11c2de64337a79050718d4a6 X-Provags-ID: V02:K0:W6j1+l3P9C2UqN9yPIhmDtHRgPYAtwgsWjCrTsiuoNX J7slDcpk9oE5piWDxqy9a5hhQpLJY7zEyQi5IQpkoVLNLeCZkj WO95bjPVdcGniOTBlm3+HFLICLWKlyuRYwX8d5y0yKswIBZ5KD iCobvqSNe168j6uWCjkevRwZcuK8bhCV+1JlCd2Y1ZqHfuNMR5 J2grCcnvHHrjdrXw6/fuLjxgz2blmk22pPmVH++3xf2EIWJmBp ohpMucKqkm9n2FBgh18yi+vwFlzY/GudUnkNi/HAqLO1mjq8YO UAbqmwceFl+LcJ6Qv148A86YNoSSausaZFLvc4GIlRyr+7VZT9 WAS+uqvJ/ygVp4dYlq1fKicDlhMSc++DuuB19WH4OGz5fert+m KBDPMfyJLQ5v7OsOw9u0bz3oaLIMsmemrrbzrEfHiK4uN/dIcM K9f4N X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nOyXpVL4pBYaZ-Wvoa35Y_IzpJY Cc: "" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 09:01:49 -0000 --001a11c2de64337a79050718d4a6 Content-Type: text/plain; charset=UTF-8 Peter Gutmann : If the only choice is between 2048 and 24something then I'll go with 2048. > What's the significance of 24something anyway? 2048 = 0x0800 2432 = 0x0980 I.e., the authors of the 2012 ECRYPT II Yearly Report on Algorithms and Keysize still are fond of powers of two. Bodo --001a11c2de64337a79050718d4a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pete= r Gutmann <pgut001@cs.auckland.ac.nz>:

If the only choice is between 2048 and 24som= ething then I'll go with 2048.
What's the significance of 24something an= yway?

2048 =3D 0x0800
2432 =3D 0x0980
=

I.e., the a= uthors of the 2012 ECRYPT II Yearly Report on Algorithms and Keysize still = are fond of powers of two.

Bodo


--001a11c2de64337a79050718d4a6-- From nobody Wed Nov 5 02:00:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5911A8844 for ; Wed, 5 Nov 2014 02:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh7-O0ufRpX7 for ; Wed, 5 Nov 2014 02:00:53 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80C61A883C for ; Wed, 5 Nov 2014 02:00:52 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0MSVhA-1Xe9MD47QS-00RcKw; Wed, 05 Nov 2014 11:00:50 +0100 Received: by mail-oi0-f51.google.com with SMTP id g201so11769026oib.38 for ; Wed, 05 Nov 2014 02:00:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.65.85 with SMTP id o82mr711342oia.95.1415181648671; Wed, 05 Nov 2014 02:00:48 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 02:00:48 -0800 (PST) In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Date: Wed, 5 Nov 2014 11:00:48 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ce16c76603b050719a744 X-Provags-ID: V02:K0:wUyIhPFdU+yRnDK8njf6PumG+wSx6gSwnX5OaBb3KTU a2lhv3ghyn+2UKsMKNfnuLXr07epXSst/ZXb1tfehm+Ghsxysd +maYhe8ZUHV++lGs55T/ax1hI9prXzjkVFhp7C6Gz+E92cVDC7 oKWtMkXroJwoemzSiQlxSzSgWZCxBrSUEJkvM8ZRN954kQUvP7 oPYuON0J26XzV64p5u8hwVwsAr7jW8/Aj5UlFgVR9/aIKodwNl RadhyPSb78pvzkOXYXbxKxg97ldDv+vuq0zJ7kRQJqFs4hkltG CjTL2aneX/IZj6l/guUdduWgWl2f4SmxOm3edXFRAKOSnL4j3+ bMh4ZyM4IVwVFbSJ6VZ5O4mpBGznkDK0PXXp92Jetb6gEZlZsF JenVTRQMn8RDz9fe5KIwqIiFM5Mzi8zknmtd+74K9wa18WWUB/ ytnZ4 X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JB5tkTLMF65mZIqc5ZGNydmbfog Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 10:00:54 -0000 --001a113ce16c76603b050719a744 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sean Turner : > To help us reach consensus on this point, please reply to this email > indicating whether you favor a =E2=80=9C2048" or =E2=80=9C2432=E2=80=9D m= inimum group size. 2048. In applications where you're concerned that a 2048-bit DH group might be too small, you most certainly should not be using 112-bit or 128-bit symmetric encryption keys for your connections in the first place: as soon as there a multiple connections that an attacker may be interested in (which must be assumed for TLS), a k-bit symmetric key won't give you "k-bit security" in any meaningful sense anyway. (Apparently this important issue isn't well-understood, but see draft-ietf-tls-negotiated-ff-dhe-02's reference [ENISA] for some discussion; or see http://www.ietf.org/mail-archive/web/cfrg/current/msg04935.html etc.) Conversely, if 128-bit symmetric encryption is well above your required security level, having to use a 2432-bit group instead of a 2048-bit group would be unreasonable overhead. Bodo --001a113ce16c76603b050719a744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sean= Turner <turners@ieca.com>:
=C2=A0
To help us reach consensus on this point, please reply to this email in= dicating whether you favor a =E2=80=9C2048" or =E2=80=9C2432=E2=80=9D = minimum group size.

2048.

In applications where you're concerned that a 2048-bit DH group= might be too small, you most certainly should not be using 112-bit or 128-= bit symmetric encryption keys for your connections in the first place: as s= oon as there a multiple connections that an attacker may be interested in (= which must be assumed for TLS), a k-bit symmetric key won't give you &q= uot;k-bit security" in any meaningful sense anyway.

(Apparently this important issue isn't well-understood, but see= =C2=A0draft-ietf-tls-negotiated-ff-dhe-02's reference [ENISA] for some = discussion; or see=C2=A0http://www.ietf.org/mail-archive/web/cfrg/current/= msg04935.html etc.)

Conversely, if 128-bit sym= metric encryption is well above your required security level, having to use= a 2432-bit group instead of a 2048-bit group would be unreasonable overhea= d.

Bodo

--001a113ce16c76603b050719a744-- From SRS0=YCei=73=acm.org=bmoeller@srs.kundenserver.de Wed Nov 5 00:54:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555511A87F0 for ; Wed, 5 Nov 2014 00:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeScswY4BWpj for ; Wed, 5 Nov 2014 00:54:07 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99931A87EF for ; Wed, 5 Nov 2014 00:54:06 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mrelayeu.kundenserver.de (node=mreue002) with ESMTP (Nemesis) id 0LlMaV-1YMN6C34Mx-00bMdD; Wed, 05 Nov 2014 09:54:04 +0100 Received: by mail-ob0-f181.google.com with SMTP id uy5so217692obc.12 for ; Wed, 05 Nov 2014 00:54:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.80.231 with SMTP id u7mr47850156oex.27.1415177641609; Wed, 05 Nov 2014 00:54:01 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 00:54:01 -0800 (PST) In-Reply-To: <20141029202745.9CB281AF69@ld9781.wdf.sap.corp> References: <20141029202745.9CB281AF69@ld9781.wdf.sap.corp> Date: Wed, 5 Nov 2014 09:54:01 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013cc0549f6a77050718b80b X-Provags-ID: V02:K0:uaHvguqnMUFAtKqpEgOBjlrMhqEqp4ywLarftFuIJNC fwDKX0HyaKUXBJOmQYbI7W2+EfglIbKJDeLTTR78zX0hy+ZS4E wQ99q2QuLzPilBMYAgIgrJLUmRpX2wRSTzvu2Mcc/J5kepJmnW RmmxxBySkCpKumXuTxGMRPIo7vJ9vbsnHCPJJdQam1APt0mEoB /J1J2d4nFlIicGFZUlOZDGqTm7KJeHheiaVSdTuZGNAW++YeHT Kg+Jhz0wiL5eYi1v/bsIBKvLJUS6N5/rMHgJJT1JkI1OD3R8jj sPDHSOvvWT2/lTZYjFgKqJA73/WRyWKocjWFwQVk8oRWL7j7gy PGbIPdwpCLhy1VwRKM2sGrtBzV2+i0M4+XanOGEtZzcievkZrh ZtV+/WcJowcXtQXcvaTVk3/3rc+rGTjLLoEkZH3sjX/214Td1o MDahx X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kjSNvqJ1NgP2KD1n8eYKet2aw6g Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 10:11:34 -0000 --089e013cc0549f6a77050718b80b Content-Type: text/plain; charset=UTF-8 Martin Rex : > Bodo Moeller wrote: > > > Continuing the handshake would not require any app-level changes to > Servers > > > that have not been writing fatal SSL alerts to the network before > > > connection closure in the past, such as Microsoft IIS, so clients > > > with fallback heuristics will be in a *MUCH* better position to > > > recognize and distinguish accidental network glitches or connection > > > management bugs from attacks. I expect the false positives to > > > outnumber attacks by at least three orders of magnitudes. > > > If there's an *actual* attack and the client doesn't continue with the > > connection, the attacker can suppress alert details anyway. The alert (if > > it gets through) is useful for heuristics; the only definitive protection > > is from making sure that the client and server won't exchange application > > data. > > I believe we're still talking past each other. > > It will be impossible to protect the handshakes between two TLS peers > where one of them does not know about the FALLBACK_SCSV. > > We're discussing purely the situation where _both_ sides are patched. > Right. I was commenting on your remark about distinguishing non-attacks from attacks: this is never reliably possible, because the attacker could make its behavior look like network glitches. > If instead, the server includes a ServerHelloExtension when recognizing > the Fallback SCSV, then the client will have *MUCH* better information > available to make sensible risk management: [...] > It's up to you / the WG to decide what the contents / semantics of > such a ServerHelloExtension should be, i.e. whether the presence > of the extension is a simple Boolean with a meaning closer to > the currently suggested fatal alert (i.e. an encouragement for the > client to abort and reconnect), or whether there should be a more > fine grained response, such as a structure that conveys the highest > protocol version of the server, whether the TLS server understands > and would appreciate TLS extensions or even a list of TLS extensions > that the server would _really_ like to see (such as ECC, SNI, ...) > or whether the server would really appreciate being offered > a larger variety of TLS cipher suites. > I think this would amount to over-engineering (and due to that, unnecessarily delaying) the fix. With a well-functioning (version-tolerant!) server, there won't be fallback retries, except those caused by network glitches. For those, having the (necessarily unauthenticated) network glitch eventually result in an (also unauthenticated) fatal inappropriate_fallback alert shouldn't be problematic. Continuing with the handshake to authenticate a ServerHelloExtension that tells you more about the problem will make both parties spend more time and computational effort before they abort the connection, with little gain. Bodo --089e013cc0549f6a77050718b80b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:
Bodo Moeller wrote:
=C2=A0
> Continuing the handshake would not require any app-level changes to Se= rvers
> > that have not been writing fatal SSL alerts to the network before=
> > connection closure in the past, such as Microsoft IIS, so clients=
> > with fallback heuristics will be in a *MUCH* better position to > > recognize and distinguish accidental network glitches or connecti= on
> > management bugs from attacks.=C2=A0 I expect the false positives = to
> > outnumber attacks by at least three orders of magnitudes.
=C2=A0
> If there's an *actual* attack and the client doesn't continue = with the
> connection, the attacker can suppress alert details anyway. The alert = (if
> it gets through) is useful for heuristics; the only definitive protect= ion
> is from making sure that the client and server won't exchange appl= ication
> data.
=C2=A0
I believe we're still talking past each other.

It will be impossible to protect the handshakes between two TLS peers
where one of them does not know about the FALLBACK_SCSV.

We're discussing purely the situation where _both_ sides are patched.

Right. I was commenting on your remark a= bout distinguishing non-attacks from attacks: this is never reliably possib= le, because the attacker could make its behavior look like network glitches= .

=C2=A0
If instead, the server includes a ServerHelloExtension when recognizing
the Fallback SCSV, then the client will have *MUCH* better information
available to make sensible risk management:
[...]
It's up to you / the WG to decide what the contents / semantics of
such a ServerHelloExtension should be, i.e. whether the presence
of the extension is a simple Boolean with a meaning closer to
the currently suggested fatal alert (i.e. an encouragement for the
client to abort and reconnect), or whether there should be a more
fine grained response, such as a structure that conveys the highest
protocol version of the server, whether the TLS server understands
and would appreciate TLS extensions or even a list of TLS extensions
that the server would _really_ like to see (such as ECC, SNI, ...)
or whether the server would really appreciate being offered
a larger variety of TLS cipher suites.

= I think this would amount to over-engineering (and due to that, unnecessari= ly delaying) the fix.

With a well-functioning (ver= sion-tolerant!) server, there won't be fallback retries, except those c= aused by network glitches. For those, having the (necessarily unauthenticat= ed) network glitch eventually result in an (also unauthenticated) fatal ina= ppropriate_fallback alert shouldn't be problematic. Continuing with the= handshake to authenticate a ServerHelloExtension that tells you more about= the problem will make both parties spend more time and computational effor= t before they abort the connection, with little gain.

<= div>Bodo

--089e013cc0549f6a77050718b80b-- From nobody Wed Nov 5 02:43:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60491A883B for ; Wed, 5 Nov 2014 02:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Won90ZHrKJrf for ; Wed, 5 Nov 2014 02:43:09 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756D81A1B3C for ; Wed, 5 Nov 2014 02:43:09 -0800 (PST) Received: from pc (ip5b400265.dynamic.kabel-deutschland.de [::ffff:91.64.2.101]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 05 Nov 2014 11:43:07 +0100 id 000000000000004C.000000005459FF3B.00007172 Date: Wed, 5 Nov 2014 11:43:14 +0100 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: tls@ietf.org Message-ID: <20141105114314.45b0139b@pc> In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-29042-1415184187-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fy1tUuHaTER1aiXN4DyOnm5K78g Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 10:43:12 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-29042-1415184187-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I find it a bit odd to have this question without any numbers on benchmarks. I am usually in the "give me more bits"-camp, but I don't see anything even close to breaking 2048 bit dh. Ultimately, I think it's reasonable to assume that this will only fall when quantum computers will rise. But then all EC will fail earlier, so we'll have other things to worry than DH group size. If using 24xx or 25xx will significantly hinder adoption of fixed groups due to performance constraints I'd vote for 2048. But I feel I don't have the numbers to judge. --=20 Hanno B=F6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-29042-1415184187-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUWf9CAAoJEKWIAHK7tR5CsHcQAMI9PxK2q4bX2F5OZaGCjHMj B699V55rnl0CvRjJnj8+CE9jEySva/Ajt7hJ4MzvZ1mdV1EQiVcwO65bE03mh8Yv cjFKxlAYbrvgk78sXRkIZolEPs+pt8lqpjaQuda5kRw/mZ9Mo0Iks+Daqji63XXR dC7RRmiM88IP/W+JVCV0vRuH5BkV+/V8pq7mSLAqmQCYJY5zjqoiWw/7RxMATlAN 5n6epJEmuwDva/CraL195eqG2sV986bJnTFNwenKvPaXH80GzkXPLdvn2I4uF+4P s/4SwLVMjZ+lozXRidGhJWHibp7ijlNAd+kqzH8HeRHscTRlRaUdejXk4pDUf+m2 /Lux7Aiq137XM9//6CM81EC3x7RPHd48dC2SkNnNyczGmX1qlcHTDcQV1NGRrJnc 9Y4PWH6z+c9Lda6sULEYgfhA3ggsCCzRT7ZfO6C0WSxR1P7WAhWJ6SJwk0kwbpdi ydgJh5EAjZNfPvICi+Ett+PIKJ0RXXI+3IG6OOUppxfF6zqxew4aCnnP4tSNqQMn 1PsoEYodXC7zhunN5g2O2Hae6JMJ2c+812X92vaUTYXtK3lce3iCPFTi9JA4pe4U CagmKwUXzDNqhXj/QW6HeEFHYTcA77rJaz4rEwU00uhFnPjlG7js12qKmv4lSzv5 3kelROor8un4p8S87Knn =j4Em -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-29042-1415184187-0001-2-- From nobody Wed Nov 5 02:56:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F01A885B for ; Wed, 5 Nov 2014 02:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4SW4txUbTlq for ; Wed, 5 Nov 2014 02:55:57 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDF41A883B for ; Wed, 5 Nov 2014 02:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1415184952; x=2279098552; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8khqu7fCFLL3zmGUXXAcrQ3iLsJd988IGBrdzjZ8EZc=; b=a1qr0QRt3wlyUr+z1IS34nO912CmeixNSHF16DrthUnIShyFjH5CSeargvEePnZ6 G+2yXLsbqGf6s9dFFMxwqRljQMGvZdhx9yhPyDRMEu3buHfa5ommSkJxHyt26ljj dD3IZBWcVXh+rFlbM8CkWQHvPS8lz0jPZsBzLHWrG9WnODa2ej3qYxiPpBJ/BBgM xLnBmMpfZ34D94OcueQhiRa+IeJAwa8nZ+ViZLkbgt/q1OtwDvG/ft9MDo1jzc34 bii/rbJRB93gCa4l4PxXiXnLB9wxIqY52H8pSPSin886fZSj82evr5NJl8PZ4uR1 RrjXC1idy5YxBQmgko/Z5Q==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 6D.51.09658.8320A545; Wed, 5 Nov 2014 02:55:52 -0800 (PST) X-AuditID: 11973e16-f79aa6d0000025ba-c2-545a02380222 Received: from haralson.apple.com (haralson.apple.com [17.171.2.64]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id B8.01.04582.5220A545; Wed, 5 Nov 2014 02:55:33 -0800 (PST) Received: from [10.0.1.83] (208-96-68-49.eastlink.ca [208.96.68.49]) by haralson.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NEK00BIHBP2OA40@haralson.apple.com> for tls@ietf.org; Wed, 05 Nov 2014 02:55:50 -0800 (PST) Content-type: multipart/alternative; boundary=Apple-Mail-4CEE7DCF-B463-49D4-8048-67CB862B07C1 MIME-version: 1.0 (1.0) From: Michael Sweet X-Mailer: iPad Mail (12B410) In-reply-to: Date: Wed, 05 Nov 2014 05:55:52 -0500 Content-transfer-encoding: 7bit Message-id: <1498D16A-E16F-478A-B894-8C4F01BDB939@apple.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9DFCB9@uxcn10-5.UoA.auckland.ac.nz> To: Bodo Moeller X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FAYpWvBFBVisOyxjMWn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuDFTvuCdeMW95/ENjEtEuxg5OCQETCQ2zi/vYuQEMsUkLtxb z9bFyMUhJLCXUWJGwxx2iISJRFPPWSaIRD+TRFv3TVYIZx6TxOEXB1lAJjELxEv03nEEaeAV EJd4fXQKI0hYWMBe4tMMFpAwm4CaxO9JfawQM2UkdraeApvPKRAs8fx5MztIOYuAqsSFAxYg YWYBP4nTrb/YIGx5ic1r3jJDTLeR+HdxNpgtJDCbUeLlYVkQW0RAWWLqg+OMIJdJCExgk9i/ +h3LBEbhWQjHzUJy3CwkYyFKdCQmL4QKa0ssW/iaGcLWkOj8NpEVWXwBI/sqRqHcxMwc3cw8 c73EgoKcVL3k/NxNjKDYmG4ntoPx4SqrQ4wCHIxKPLwd+ZEhQqyJZcWVuYcYpTlYlMR5jXOB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhjn/XrkJHpptr3luv7q996/Z21x2bv+/L7Xzjo7 KtdIx3OV/tS3b74t1nlBeNFMz8UCql6rCio63lWw7mzgcuvL2Fmm+WnlPJcXYe3MCVvS3ylt c2ZSC5fRLl2l+jJHYv+qOT3HPmltWzW3bvq+yUmJCg1rJLmVT95KkxXdEPl9jpO/w9mEsFNK LMUZiYZazEXFiQAKleg7bgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiuJrJQVeVKSrEYM1BfYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWOmfME78Yp7z+MbGJeIdjFyckgImEg09ZxlgrDFJC7cW8/W xcjFISTQzyTR1n2TFcKZxyRx+MVBli5GDg5mgXiJ3juOIA28AuISr49OYQQJCwvYS3yawQIS ZhNQk/g9qY8VYqaMxM7WU+wgNqdAsMTz583sIOUsAqoSFw5YgISZBfwkTrf+YoOw5SU2r3nL DDHdRuLfxdlgtpDAbEaJl4dlQWwRAWWJqQ+OM05gFJiFcM8sJPfMQjIJokRHYvJCqLC2xLKF r5khbA2Jzm8TWZHFFzCyr2IUKErNSaw000ssKMhJ1UvOz93ECArmhsKoHYwNy60OMQpwMCrx 8HbkR4YIsSaWFVfmHmKU4GBWEuFV/gwU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmucC5QSSE8s Sc1OTS1ILYLJMnFwSjUwCj/e79/2X+Hs+8dKWXnrruoV3HT7/XbS4gLN9Vfj5J3errvcslnx SotkosLyUvb3V9N+KLvGOD44FrS8ZE27gL1mg/7R6nVrbW8v4/gsUcF66KT5vzWp5TLiZkca pb25tjz7efhG21I19dmlGhqFsmXRJ1aKaE1h5oi0XhOl9n/pzoWeobvZlViKMxINtZiLihMB jY0I1GICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YnwhIEhj4cC05Jz7Jj7xj6lY3EI Cc: "" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 10:55:59 -0000 --Apple-Mail-4CEE7DCF-B463-49D4-8048-67CB862B07C1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Um, I'm no TLS expert but I do know that 2432 (0x980) is not a power of 2. Sent from my iPad > On Nov 5, 2014, at 4:01 AM, Bodo Moeller wrote: >=20 > Peter Gutmann : >=20 >> If the only choice is between 2048 and 24something then I'll go with 2048= . >> What's the significance of 24something anyway? >=20 > 2048 =3D 0x0800 > 2432 =3D 0x0980 >=20 > I.e., the authors of the 2012 ECRYPT II Yearly Report on Algorithms and Ke= ysize still are fond of powers of two. >=20 > Bodo >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-4CEE7DCF-B463-49D4-8048-67CB862B07C1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Um, I'm no TLS expert but I do know th= at 2432 (0x980) is not a power of 2.

Sent from my iPad

= On Nov 5, 2014, at 4:01 AM, Bodo Moeller <bmoeller@acm.org> wrote:

=
= Peter Gutmann <pgut001@cs.auckland.ac.nz>:

If the only choice is between 2048 and 24somet= hing then I'll go with 2048.
What's the significance of 24something anyway?=

2048 =3D= 0x0800
2432 =3D 0x0980

I.e., the authors of the 20= 12 ECRYPT II Yearly Report on Algorithms and Keysize still are fond of power= s of two.

Bodo


____________________= ___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tls
= --Apple-Mail-4CEE7DCF-B463-49D4-8048-67CB862B07C1-- From nobody Wed Nov 5 03:07:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F821A0043 for ; Wed, 5 Nov 2014 03:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwj3sJ8Vy3AB for ; Wed, 5 Nov 2014 03:07:37 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE761A1AF6 for ; Wed, 5 Nov 2014 03:07:36 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LjJi3-1YJwPS2jj5-00dSqP; Wed, 05 Nov 2014 12:07:34 +0100 Received: by mail-ob0-f182.google.com with SMTP id nt9so391373obb.13 for ; Wed, 05 Nov 2014 03:07:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.126.233 with SMTP id nb9mr12805827obb.48.1415185652416; Wed, 05 Nov 2014 03:07:32 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 03:07:32 -0800 (PST) In-Reply-To: <1498D16A-E16F-478A-B894-8C4F01BDB939@apple.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9DFCB9@uxcn10-5.UoA.auckland.ac.nz> <1498D16A-E16F-478A-B894-8C4F01BDB939@apple.com> Date: Wed, 5 Nov 2014 12:07:32 +0100 Message-ID: From: Bodo Moeller To: Michael Sweet Content-Type: multipart/alternative; boundary=001a11c1e5501b61ba05071a96a3 X-Provags-ID: V02:K0:aC6+fnEhQlQjiSB8ClzMHIGgQznHrM73uCYTrJ3MMAJ RUrEULkAkzBLMUBqEh+JSmH8qlnnVjlpG3jbVq1KOzxJDs6gs2 iCpUHCaZJL44k8iZ+drI5Xr2iuADaoajsAaxCWGoFWb9QHywXR hq8KQM7GJ50tb5Uyf8DcsYTM2MLTFZktOI6D2U79od2VmkgOt1 m8IAccZmu1AZ/OJlvHlEWw1Lg9eu5KxGxFJz+W1t3f5zCvP+iR u7TeM4ps5SR+DeVEJfrsgTjiMvnu7lRb4wnmT9B7fmTdgGxZ5k URHb+MhsuWQbzCp5qbFjwLKKtTAvuyAyIyTJg/Oa9yM/2fGd2+ U2VHeUK4nfZXPiJfiaQf5E3IH7Ei1dw5uR6DOF24iu3ur91ZVf FbsIGeM3AJKU/6hgPoOTKREoqg6uEm6wHL/66+AzVYEVMeYUYz d1WHW X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SHLj1IgurA6mK1GN3mnHLl9SCGs Cc: "" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 11:07:38 -0000 --001a11c1e5501b61ba05071a96a3 Content-Type: text/plain; charset=UTF-8 Michael Sweet : > Um, I'm no TLS expert but I do know that 2432 (0x980) is not a power of 2. > It's a small multiple of a power of 2. --001a11c1e5501b61ba05071a96a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mich= ael Sweet <msweet@apple.com>:
Um, I'm no TLS expert but I do know that 243= 2 (0x980) is not a power of 2.

<= div>It's a small multiple of a power of 2.

--001a11c1e5501b61ba05071a96a3-- From nobody Wed Nov 5 03:23:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0AD1A1BA3 for ; Wed, 5 Nov 2014 03:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYgT7rahYZfS for ; Wed, 5 Nov 2014 03:23:21 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16421A1B3C for ; Wed, 5 Nov 2014 03:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=zcAD54BwE8AlW0x3bFvH4z6Zm8hTsv1appB9IIulPdQ=; b=ATTq26v8NCwF4d6RbhjPGYZUqbLJy1z2oVyvZaNMYPVdayl5ivAzjU04N6uL52DmHrM2Y2O7iCtPsCf7+hMjF9r/eUDk6QrRGKHB/0kLa0jSYL3H5JUte5RuwKKjb9MiZXGmkSFYGZSQFYujR92O2ApEuYJt5Ln+ZbpHNF4tgZk=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XlygC-0003jV-5J; Wed, 05 Nov 2014 12:23:13 +0100 Message-ID: <545A08A4.7090400@polarssl.org> Date: Wed, 05 Nov 2014 12:23:16 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Watson Ladd , "tls@ietf.org" References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> <20141105012314.GG23599@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ofiO_Vf3T-F9ujRCiahxVXBx-nE Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 11:23:23 -0000 On 05/11/2014 03:19, Watson Ladd wrote: > On Tue, Nov 4, 2014 at 5:23 PM, Viktor Dukhovni wrote: >> Basically, what's the expected ratio of DH-per-second between the >> two proposed field sizes, and between the 2048-bit group and $F_p$ >> with $q = (p-1)/2$ and $p$ a 2048-bit Sophie-Germain prime. Is >> the "new" 2432 as fast or faster than the "old" 2048? > > Slower, by a quadratic factor assuming standard algorithms for bignum > arithmetic. No acceleration of either is possible, and for good > reason: SNFS uses the same characteristics as we would use to optimize > arithmetic. > Unless I'm mistaken, if textbook multiplication is used, it's rather cubic: multiplication is quadratic, and the length of the exponent, which is roughly the number of multiplications, is linear in the size of the group. Which gives a 67% performance penalty for 2432 compared to 2048 Now, for this size, Karatsuba is probably the best multiplication algorithm, which is about n^1.58, so a total of n^2.58 for exponentiation, which gives a performance penalty of 58% with this algorithm. Manuel. From nobody Wed Nov 5 03:57:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594FC1A8873 for ; Wed, 5 Nov 2014 03:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FJR5-7TO30B for ; Wed, 5 Nov 2014 03:56:50 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A1D1A8870 for ; Wed, 5 Nov 2014 03:56:48 -0800 (PST) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0M1Fnc-1Y1bHC1fk8-00tClf; Wed, 05 Nov 2014 12:56:46 +0100 Received: by mail-oi0-f43.google.com with SMTP id e131so826922oig.16 for ; Wed, 05 Nov 2014 03:56:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.62.10 with SMTP id l10mr45778255oia.18.1415188603118; Wed, 05 Nov 2014 03:56:43 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 03:56:43 -0800 (PST) In-Reply-To: <20141105012314.GG23599@mournblade.imrryr.org> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> <20141105012314.GG23599@mournblade.imrryr.org> Date: Wed, 5 Nov 2014 12:56:43 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ccca2faadd205071b4569 X-Provags-ID: V02:K0:Wx7J9eUO7UXNfGMsD7bMJGPp3vLWxaHXGPsCTdpcDoo ds3aeWYcD4JNgP58NQOk9XqPPw6Jo9gZg7aUBgBLuondF7dlPH BN/PUQA8D7uzomOU/FH/3A2MYTdL1sNT5FqpkEMRLk00spFg3E XDHTQ84yw+WNaGEIrZri010m+LkqvGW8kjsin3+tvcxCbDF6wB +o2Dy4ILQ+Woc5qm+JLveS3qFtRaG5DOrTb2ftWSpjyx3vzten zgE9BmwDj2+/Ln3S1s1W8j3PRGjdKC3QVi5xTp6bmBvvj9C+96 uP9Q2HTrE+QuK7PBIC/E4E+czhhcj111QDQmSdOh4PGXeXKGGo 0bzq3/unGW0r2mHF1p4QIlAAvuPUbdvAXEPEZcFwW7umOnI7rW bZdNgqx8NBa3L7joZl9ImBzPdB5+euXEHCPMc80FBLmAjjlS++ 6hsQy X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xB5alBpO2tyBhrExK4EYxqnOQHQ Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 11:56:55 -0000 --001a113ccca2faadd205071b4569 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni : I take it the new DHE $\mathbb{Z}^*_p$ subgroups will be cyclic > with prime order $q$, where $q$ is a much shorter prime Wrong, see draft-ietf-tls-negotiated-ff-dhe-02. The new groups have prime group order q =3D (p-1)/2. Manuel P=C3=A9gouri=C3=A9-Gonnard : multiplication is quadratic, and the length of the exponent, which is > roughly > the number of multiplications, is linear in the size of the group. > No, because you can still use short exponents. If you're doing that, draft-ietf-tls-negotiated-ff-dhe-02 recommends (at least) 224 bits [*] for the exponent when using the 2432-bit modulus. Bodo [*] Minor editing issue: it actually says that you can use exponents in the [2,2^224] range, but also says that you "should choose a secret key of at least 224 bits". Since there's no discussion of leading zeros in the document (I think), the latter could be read as requiring a [2^223, ...] range. --001a113ccca2faadd205071b4569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Vikt= or Dukhovni <ietf-dane@dukhovni.org>:

I take it the new DHE $\mathbb{Z}^*_p$ subgroups will be cyclic
with prime order $q$, where $q$ is a much shorter prime
Wrong, see=C2=A0draft-ietf-tls-negotiated-ff-dhe-02.=C2=A0 The= new groups have prime group order q =3D (p-1)/2.

=
Manuel P=C3=A9gouri=C3=A9-Gonnard=C2=A0<= ;mpg@polarssl.org= >:

multiplication is quadratic, an= d the length of the exponent, which is roughly
the number of multiplicat= ions, is linear in the size of the group.

No, because you can still use short exponents. If you're doing that,= draft-ietf-tls-negotiated-ff-dhe-02 recommends (at least) 224 bits [*] for= the exponent when using the 2432-bit modulus.

Bod= o


[*] Minor editing issue: it actua= lly says that you can use exponents in the [2,2^224] range, but also says t= hat you "should choose a secret key of at least 224 bits". Since = there's no discussion of leading zeros in the document (I think), the l= atter could be read as requiring a [2^223, ...] range.

=
--001a113ccca2faadd205071b4569-- From nobody Wed Nov 5 04:03:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B871A1A5F for ; Wed, 5 Nov 2014 04:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgbAnLEMDoUO for ; Wed, 5 Nov 2014 04:03:16 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B041A0075 for ; Wed, 5 Nov 2014 04:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1415188995; x=2279102595; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3dOGhGcq5TmwNIknsVptaRAhpFIvhOJrMcjbpq23s3A=; b=O/rKmGimPMilSyeKGnMql6d8oW5xG5KbuIgr0+lHz9g7Fstic8gGAdDWBHID+93Q Id83n17/LCeGzdyLa3dLtk7G7N7HZ+CVKg6pQfLeGMc+2gw6n44Di+Anlj/5PP3j K5qPTkI7KhIfa9cDazDlk8yAz/DEd7NqQl7Id7S/YbCLtr8EyRtNALmPaxCcbTY0 KDEcOpZzyybhPA/Cgkny/wuvdnpwdjtK3P91wcqpsLoTBiFEYFtnqB/vSdSuI/bK ZHgM07SMjHiQJF7tV6dvMWegocp+7qWrLSoQD+kdl0LrMt5lANMo4HsLmmNEty1m SKuOAZYQJp6+3f/616O7aw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id CD.CA.02334.3021A545; Wed, 5 Nov 2014 04:03:15 -0800 (PST) X-AuditID: 11973e13-f79ee6d00000091e-d5-545a1203c74c Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 08.EF.29157.5021A545; Wed, 5 Nov 2014 04:03:17 -0800 (PST) Received: from [17.153.51.159] by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NEK00KG4ETDMK10@chicory.apple.com> for tls@ietf.org; Wed, 05 Nov 2014 04:03:15 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-type: multipart/signed; boundary="Apple-Mail=_D96B9FE2-FFF7-4A9F-9A35-EA96441AD62D"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Wed, 05 Nov 2014 07:03:12 -0500 Message-id: <83582340-5CEA-447E-9F83-5760E82D9A75@apple.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9DFCB9@uxcn10-5.UoA.auckland.ac.nz> <1498D16A-E16F-478A-B894-8C4F01BDB939@apple.com> To: Bodo Moeller X-Mailer: Apple Mail (2.1990.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUi2FCYpsssFBViMPmkpcWn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaNi7m6XgRVjF0UU/2BsYlwR2MXJySAiYSJzcdp0dwhaTuHBv PVsXIxeHkMA+Ron/n9YzwxTdnvmQFSLRzyTx+Mp0FgjnC6PEqRn3gdo5OIQF7CU+zWABaeAV MJC4dWYGI0gNs8AURon16/eAJdgE1CR+T+pjBbE5BYIlPs+9CRZnEVCVOLJ/DhOIzSygLDGr azkrxCAbiecTT0Itm8okcX3nYbCTRICKpj44zghxnrzEnAsnwO6WEDjAJrHlyDn2CYxCs5Bc MgvZJbPAtiRJzPvZwgxha0ssW/gayOYAsnUkJi9kRBWGsD+eP8IEYZtKPHm7nQ3Ctpb4OecR VL2ixJTuh+wLGLlWMQrlJmbm6GbmmeolFhTkpOol5+duYgRF13Q74R2Mp1dZHWIU4GBU4uHt yI8MEWJNLCuuzD3EKM3BoiTOa5QLFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4a7GQTn3d 1Yu/3JwsGC+H/3+0XdXvTXizBUP1CTvrS/fqAr/sOWzOvPuwE+8u5cn3RQoPcfm8Zf5x6MHm nPjPu+ZG5HwXvzevbEv96QMLHqzdveiR+z9FRb0TVv9q1P6pl8y+/czh6YysuEvvTfq8lpi2 /1l2jNFotsTL1qdRTnbCDMsP3y+6pcRSnJFoqMVcVJwIAAKrBhePAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUi2FCcrMsqFBVisHS3scWn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaNi7m6XgRVjF0UU/2BsYlwR2MXJySAiYSNye+ZAVwhaTuHBv PVsXIxeHkEA/k8TjK9NZIJwvjBKnZtxn72Lk4BAWsJf4NIMFpIFXwEDi1pkZjCA1zAJTGCXW r98DlmATUJP4PakPbCqnQLDE57k3weIsAqoSR/bPYQKxmQWUJWZ1LWeFGGQj8XziSahlU5kk ru88zAySEAEqmvrgOCPEefIScy6cYJvAyD8LyfJZyJbPAhucJDHvZwszhK0tsWzhayCbA8jW kZi8kBFVGML+eP4IE4RtKvHk7XY2CNta4uecR1D1ihJTuh+yL2DkWsUoUJSak1hpoZdYUJCT qpecn7uJERwNhWk7GJuWWx1iFOBgVOLh7ciPDBFiTSwrrsw9xKgCNOLRhtUXGKVY8vLzUpVE eK+xRoUI8aYkVlalFuXHF5XmpBYfYpTmYFES53XPBeoUSE8sSc1OTS1ILYLJMnFwSjUw1hk5 HurcvoCPw6prl/X1BU4asUUTLD+/jgvhljK1N3nwQGWOxDXLXWoO4vE1f8t2tmvU9wkFKvjk Prx4OevWx657ytx7BYOz8iP3RM/fWmb5g/XknaZvXN52jPN2LNqzZb2z3Wmfg0ffdqboy8bZ R808ukfOnoPVRGCZed2n0zPO7ple13FCiaU4I9FQi7moOBEAeo0kOI4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xWjEfvnSjtOFRwOvzTZWKwkaqUI Cc: "" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 12:03:17 -0000 --Apple-Mail=_D96B9FE2-FFF7-4A9F-9A35-EA96441AD62D Content-Type: multipart/alternative; boundary="Apple-Mail=_65AA2B36-3765-41A6-804F-53D098C7BA10" --Apple-Mail=_65AA2B36-3765-41A6-804F-53D098C7BA10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You can stretch the definition to say it's a non-integral power of 2 = (2^11.2479), but any number fits that definition. You could also say it is 19 x 2^7 or 1.1875 x 2^11. But there is no solution for "2432 =3D 2^n" where "n" is an integer. > On Nov 5, 2014, at 6:07 AM, Bodo Moeller wrote: >=20 > Michael Sweet >: > Um, I'm no TLS expert but I do know that 2432 (0x980) is not a power = of 2. >=20 > It's a small multiple of a power of 2. >=20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_65AA2B36-3765-41A6-804F-53D098C7BA10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii You can stretch the definition to say it's a non-integral = power of 2 (2^11.2479), but any number fits that definition.

You could also say it is = 19 x 2^7 or 1.1875 x 2^11.

But there is no solution for "2432 =3D 2^n" where "n" is an = integer.

On = Nov 5, 2014, at 6:07 AM, Bodo Moeller <bmoeller@acm.org> = wrote:

Michael Sweet <msweet@apple.com>:
Um, = I'm no TLS expert but I do know that 2432 (0x980) is not a power of = 2.

It's a small multiple of a power of = 2.


_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_65AA2B36-3765-41A6-804F-53D098C7BA10-- --Apple-Mail=_D96B9FE2-FFF7-4A9F-9A35-EA96441AD62D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO0jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUiMIIECqADAgECAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0xNDEyMTcyMzU5NTlaMCExHzAdBgkqhkiG9w0BCQEWEG1zd2VldEBhcHBsZS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXb0GGUQlc3NMCGLyDp/9D7+81MLiL2wHz P1txcnpqmcd33SsV+FsTdseTQt4YQRxq1FoqyR+65eiLddmxkOtbhwCuY7CYpFeZPpjmI2WijSCs Y9LmCJNzCkJrJjPLd53XauZqdpscFf1OwBT089X4IXZKk2/zZB2OXgPCqpLGnqsHzIKGohlXglIa bVp16LHGvDwJG/ovbuaxKJOc4GPkD9CLliyRDXwOKnRDLB/jgMDBjr/XzQoHHWqRZ43kmGo+9Juq lIquOOvvGtq4VLBFCkGsjjII55tm4FLjce6Tr7PyYMyJWaE8/5ZZhNR1kRBs0o0Zy1sEPfH7KX3m VgPvAgMBAAGjggHgMIIB3DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4E FgQU7SgSaBvZMWYrE6iYOPsK9dpeLLYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAbBgNVHREEFDASgRBtc3dlZXRAYXBwbGUuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAY OSi0CubvYBiO+bvr2B/4urjAypaUyCzv6/xaTdom6qcAAdpZ/aCrzyANf696PgwQvO06p5SQIj1u AAxR6UZqpaa29E7vaffJz/8JebQWYxD/HWOIh9Ewdwdq/SR8EcMCUNtAqiabgp/XZry9tebGUqry X5blZSHAEAi8ad2SjCAtqTSorbMHY4x3bmiro9kzHsa8zLa0RkbRRfaXDHJ7KhNkLSVKlz1e/zOF k9skVJiOE4T7fTvX5jx9pLudoXW+reKl78HUEpAx7caNyf1XP4w0dv33nnQ4UJhtFfY+rR7Lhum1 VYXBolp0pkqD34NdxZUMJcWU8hbYjGdoyC8qMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMAkGBSsOAwIaBQCgggHZMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTEwNTEyMDMxM1owIwYJ KoZIhvcNAQkEMRYEFHrCPPXh7uBSwS/Rk09awwZmpt2qMIG6BgkrBgEEAYI3EAQxgawwgakwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMIG8Bgsq hkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNV BAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUH t1fFyUsR52q4+8ZfwIYwDQYJKoZIhvcNAQEBBQAEggEAs8JXLYAlKRuB5EaKi7nZSX9+yyw+/wnd 7oqmwfldqBJilVBGb3jsdroV2bTDQL8dkQ7KCLKlRd6jeHUYvE8YxYo6WH89BRnr9PBvJ+n8dfiz 5KQXSgJ3UYCrtquFO/v372Kyc97BW05fWY+FzHkI/34thppD41W66jV5bCVsawjO8P8kX3MhdRNg 1hIwzsdj59xYCcHJnDSJR3qfq88ryn73Y9mI9zbcJrIvKBEdicWu+wdCnFmWTBvvKisrxOqNEESM s47TpyDPqIrCHPzICVntXGnvk8pr8NlxRpn18zYKlg2kEdZt0/PP7jY+xcp9CTXBYscO7qV27V1K Pz6aGAAAAAAAAA== --Apple-Mail=_D96B9FE2-FFF7-4A9F-9A35-EA96441AD62D-- From nobody Wed Nov 5 04:08:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C7B1A8862 for ; Wed, 5 Nov 2014 04:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEHKl2ERb81G for ; Wed, 5 Nov 2014 04:08:13 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6591A1A5F for ; Wed, 5 Nov 2014 04:08:12 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MhDFZ-1XQJfX2QOf-00MMrm; Wed, 05 Nov 2014 13:08:10 +0100 Received: by mail-ob0-f176.google.com with SMTP id va2so420217obc.21 for ; Wed, 05 Nov 2014 04:08:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.48.84 with SMTP id w81mr32549124oiw.30.1415189289135; Wed, 05 Nov 2014 04:08:09 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 04:08:09 -0800 (PST) In-Reply-To: <83582340-5CEA-447E-9F83-5760E82D9A75@apple.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9DFCB9@uxcn10-5.UoA.auckland.ac.nz> <1498D16A-E16F-478A-B894-8C4F01BDB939@apple.com> <83582340-5CEA-447E-9F83-5760E82D9A75@apple.com> Date: Wed, 5 Nov 2014 13:08:09 +0100 Message-ID: From: Bodo Moeller To: Michael Sweet Content-Type: multipart/alternative; boundary=001a113cc582de783e05071b6e18 X-Provags-ID: V02:K0:MGLNcVewvtk+gemkjvtQdOS22wuSTlJusGC41B3PaUT ePvqqjo7vgZVpmHT0r47sRRaRSZeufC8+vNWDxpFungXyyn6QO pbQMZC5f7yQyyA7LuboRBFcB9suQU3d80KVXuU8LuCnk3wmoj+ 09nhThP37o/xGrUobg6jzgQIaV/J3DPjOrAzX6+wlvlMQN7o6/ GkMGOosm4FQwn9bpYpDslJi07BvjvY68oFXXKDfRfpW4rvqWQJ Q32TVovDvF1D/8j9HUu2Yef8KdH4Cdx545VMUAZ7b8VsrrlNxQ 9W/VAIfEcf8MS86nlvCbued13AWWzMSp3ycvmuHOBO9TtKRH5F VRjw3JmUvY+40IpJGBc5dIJ1mPIWWvn09cKADZKPIw4UkVL2MQ uzCw80n24IAVdC9f4n2YNBZyhOJS622hmX/ZIja1DXKumjXGy5 jbFEs X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M1HUEjwV-oQMNXeuTlfxR2agv8E Cc: "tls@ietf.org" Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 12:08:16 -0000 --001a113cc582de783e05071b6e18 Content-Type: text/plain; charset=UTF-8 Michael Sweet : You can stretch the definition to say it's a non-integral power of 2 > (2^11.2479), but any number fits that definition. > > You could also say it is 19 x 2^7 or 1.1875 x 2^11. > > But there is no solution for "2432 = 2^n" where "n" is an integer. > Of course, but do you think it's a coincidence that all the ECRYPT-recommended prime sizes are small (integral) multiples of a (non-trivial) power of two? I think not. (Not that there's anything wrong with that.) Bodo --001a113cc582de783e05071b6e18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mich= ael Sweet <msweet@apple.com>:

Yo= u can stretch the definition to say it's a non-integral power of 2 (2^1= 1.2479), but any number fits that definition.

You could = also say it is 19 x 2^7 or 1.1875 x 2^11.

But ther= e is no solution for "2432 =3D 2^n" where "n" is an int= eger.

Of course, but do you thi= nk it's a coincidence that all the ECRYPT-recommended prime sizes are s= mall (integral) multiples of a (non-trivial) power of two? I think not.

(Not that there's anything wrong with that.)

Bodo

--001a113cc582de783e05071b6e18-- From nobody Wed Nov 5 04:17:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E031A8877 for ; Wed, 5 Nov 2014 04:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itlDBskG_ecc for ; Wed, 5 Nov 2014 04:17:22 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572131A0075 for ; Wed, 5 Nov 2014 04:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=FH/gw+BJnyYzR4C5xwqxuNW50EmJWSPkOD11kDfp0fg=; b=HhWJEZGulhn3blw8gRc9rGUEFtYJZPHVK8m5sMyzrINgt49hqTN0xRYUqz+b34NQsw9z0HHbNorTZfOC1wpGt1qTPGGaC6Fhxp4RHGtkPLp/Z4tJdUwsDNVP4dwC4ornc11fW2jLFCbT8jLC5z8uxHfwmYLpnOhOfQ9/zqY5ViQ=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XlzWS-0003no-Lj; Wed, 05 Nov 2014 13:17:13 +0100 Message-ID: <545A154D.1080701@polarssl.org> Date: Wed, 05 Nov 2014 13:17:17 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> <20141105012314.GG23599@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HxGxEPNsbt2IOMOFAmOD3THaRgQ Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 12:17:29 -0000 On 05/11/2014 12:56, Bodo Moeller wrote: > Manuel Pégourié-Gonnard : >> multiplication is quadratic, and the length of the exponent, which is >> roughly the number of multiplications, is linear in the size of the group. >> > No, because you can still use short exponents. If you're doing that, > draft-ietf-tls-negotiated-ff-dhe-02 recommends (at least) 224 bits [*] for > the exponent when using the 2432-bit modulus. > Right, thanks for pointing that out. For some reason I assumed the short exponent would be longer for the 2432-bit group than for the 2048-bit, but of course this is stupid because both target the 112-bit security level, and the question is which FF size corresponds to that level. Manuel. From nobody Wed Nov 5 04:20:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552DE1A0075 for ; Wed, 5 Nov 2014 04:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwTV3GLNMT3j for ; Wed, 5 Nov 2014 04:20:27 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF451A887A for ; Wed, 5 Nov 2014 04:20:26 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA5CKPkU003198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 5 Nov 2014 07:20:26 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA5CKOu3031950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 5 Nov 2014 07:20:25 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 05 Nov 2014 13:20:23 +0100 Message-ID: <4568901.9euKC2mo8R@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.1 (Linux/3.16.6-203.fc20.x86_64; KDE/4.14.1; x86_64; ; ) In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EVmZnj121cuRfJ9sLTzg35NXeDw Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 12:20:29 -0000 On Tuesday 04 November 2014 12:49:21 Sean Turner wrote: > Hi! >=20 > At the TLS Interim meeting in Paris, the WG discussed the FF DHE draf= t > (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/).= The > chairs would like to poll the WG on one of the issues in the draft na= mely > the size of the minimum group. >=20 > The draft currently includes a minimum group size of 2432 but the WG = also > discussed 2048. Groups smaller than 2048 were discounted for a stand= ards > track document as too weak for use but might be documented in a separ= ate > =E2=80=9Chistoric=E2=80=9D draft. To help us reach consensus on this= point, please reply > to this email indicating whether you favor a =E2=80=9C2048" or =E2=80= =9C2432=E2=80=9D minimum group > size. Note we=E2=80=99re also looking to specify the smallest number= of options > for groups as is acceptable - i.e., we=E2=80=99re not looking at spec= ifying both > 2048 and 2432. 2048 This is of issue only to legacy applications that don't implement ECC, = so=20 higher security margin is of limited importance. That's a work factor difference of around 10 bits, that's rather close = to the=20 difference between 3DES and AES128... implementations of "round" numbers are much more likely to be optimised= for=20 higher performance in currently deployed software It matches currently deployed base (around 4% of TLS-enabled Alexa top = 1=20 million servers use 2048 bit DH, while the ones that use any size betwe= en 2048=20 and 3072 can be counted on one hand) I don't know if there are HSMs that are used for DH key exchange, but o= f ones=20 that I used, all supported only very specific RSA key sizes. --=20 Regards, Hubert Kario From nobody Wed Nov 5 04:49:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8364A1A1ADF for ; Wed, 5 Nov 2014 04:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoLv8Nn1sJps for ; Wed, 5 Nov 2014 04:49:12 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A978E1A1A5F for ; Wed, 5 Nov 2014 04:49:11 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0LqpKo-1YGMxr1AA6-00eJKZ; Wed, 05 Nov 2014 13:49:09 +0100 Received: by mail-ob0-f177.google.com with SMTP id m8so462501obr.8 for ; Wed, 05 Nov 2014 04:49:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.102.90 with SMTP id a87mr881879oic.108.1415191747076; Wed, 05 Nov 2014 04:49:07 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 04:49:07 -0800 (PST) In-Reply-To: References: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> Date: Wed, 5 Nov 2014 13:49:07 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1140a8725fa97d05071c0116 X-Provags-ID: V02:K0:bLZivwGEC6MmCn4mrRZ7oWIKgMce8iuStUxTtf6Ffwv ByjaICBapxLFKSXKHKOJU8SeQ3AsYAHBguMX2G3+IcSMU7V4wW oIV2zZyrWuLOBw0hyKW/uF+D3FKOfYHca73iIAmTVqTt5SgMQG y8OHiRe+cm7uNUxuS4vgpQROk6tytTnhFY2zGPUNuCbAaLJLc+ 2oR33UQDHskEbl9YrpmAitojZnr38t54ZGjKPJP1rQE5iXOpGI 2FzARe+6f6dVuAin6I0fj/qXHlWbENjffUeaWo4i85PK/irqiE qjTHnzlNyDW/v8OXvDF2lkNsoHHg9ynREXp0ZZF6xIpQ7DXBQ6 3AEVHOKME/UU0wdPsGxLyTIrhGGNwMxhGJF/HD2t32lJx5vLrV 6Y32u6rQnZD2s9DPSvK+cFiAXpFd0062gI7VDO1ZScNaIanjg/ 66Bpf X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4ok-BqkLBpjzc1QwfjIQhRn7U4o Subject: [TLS] Fwd: TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 12:49:16 -0000 --001a1140a8725fa97d05071c0116 Content-Type: text/plain; charset=UTF-8 Sean Turner : Posted draft minutes: > > http://www.ietf.org/meeting/interim/proceedings.html My corrections to the previous draft (for Day 1) still apply: 1. The link https://github.com/tlswg/wg-materials/blob/master/20141021_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf should be replaced by http://www.ietf.org/proceedings/interim/2014/10/21/tls/slides/slides-interim-2014-tls-3-1.pdf . 2. Mention that youtube encodes video streams using RC4 only. This isn't correct, and isn't what was said at the meeting. As discussed at the meeting, YouTube currently allows two cipher suites for video streams, TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but Firefox doesn't support the former without ECDHE ( https://bugzilla.mozilla.org/show_bug.cgi?id=1029179). Bodo --001a1140a8725fa97d05071c0116 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sean Turner <<= a href=3D"mailto:turners@ieca.com" target=3D"_blank">turners@ieca.com&g= t;:

Posted draft minutes:

http://www.ietf.org/meeting/interim/proceedings.html

My corrections to the previous draft (for Day = 1) still apply:

1.


2.

Mention that youtu= be encodes video streams using RC4 only.

Th= is isn't correct, and isn't what was said at the meeting. As discus= sed at the meeting,=C2=A0YouTube currently allows two cipher suites for vid= eo streams, TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, b= ut Firefox doesn't support the former without ECDHE (https://= bugzilla.mozilla.org/show_bug.cgi?id=3D1029179).

Bodo


--001a1140a8725fa97d05071c0116-- From nobody Wed Nov 5 04:56:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390411A887A for ; Wed, 5 Nov 2014 04:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55GL3BAbsHcU for ; Wed, 5 Nov 2014 04:56:01 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECE01A1ADF for ; Wed, 5 Nov 2014 04:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=zpsPUaM2O0ZnUHeUurw5rnfrU/7Z9T+CyThk1XxYmHk=; b=IYGwNVisbBUHtHXetAOs/5CVKQb1dcvQ95PT1coSRHYGLDZKjadEfqiMPEDXk537gwLD87GM5AnvV1z/BBtAls7Gl39g16yX/nlVQcAl5+wkM4awdscUjkcCLPzBGz13Vh9FCnnBbzsnkZaSHDMNq05jmq1FADy9uLC1p38at7M=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xm07t-0003qZ-4t; Wed, 05 Nov 2014 13:55:53 +0100 Message-ID: <545A1E5E.6070700@polarssl.org> Date: Wed, 05 Nov 2014 13:55:58 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pdr1VOFcizn5_xQyxMRvUyG8TV0 Subject: Re: [TLS] Fwd: TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 12:56:04 -0000 On 05/11/2014 13:49, Bodo Moeller wrote: > Mention that youtube encodes video streams using RC4 only. > > This isn't correct, and isn't what was said at the meeting. As the person who raised that point at the meeting, I agree that this is not what was said at the meeting (and not correct either). Unrelated point: I think the last three lines (starting with "----") should be removed as they are not related to the meeting (it looks like something about PolarSSL that Hannes and I discussed on the day of the meeting). Manuel. From nobody Wed Nov 5 06:19:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812351A8915 for ; Wed, 5 Nov 2014 06:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA3jYhzBnULK for ; Wed, 5 Nov 2014 06:19:06 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449771A8916 for ; Wed, 5 Nov 2014 06:19:06 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id q108so11984424qgd.41 for ; Wed, 05 Nov 2014 06:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eQnB0h+agV0weC7pUgRQOrpS8jXaRe7926qnjckFcF4=; b=ArGYpE8MVR7lKADmL3tidmc9praD4alhiL9Wo5YUz0A2em8a6lkZzfBuUTBO2mnaBt Kmipyv6uP1GEPrmQtQz3NIxy/nER4Vhbesm/qIHWsEcBSM6ku/qSxsmn1dalTCCH6jw6 eBuI+puuq/RVoOFnik4SxcHUTImfyTYY2ET30kI+u8vPJjarcGeYJ8WIxnbA/5gcv7az n9m2sJtGqIGfmEMwvdw53pPCh2uezRni/g/MiMq//YQr4SgkDIPvD9ac594iwz3tILsX MvHpHgHNITeS81dRfX4+irpmf4tseDUrgEDsTp5t/HQHy4yczBPvcEzZuQPBwp+8SScH StnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eQnB0h+agV0weC7pUgRQOrpS8jXaRe7926qnjckFcF4=; b=REs95XhwGjHtyxc7+lI01RW4wxTC3ALTd7j0uU051AE8kWoVuUBuDOV/hB4QXuHIjG vhfokX4sWUUvGAUyiRRxQph5+V/AaPJ0rlr+W4iFh7kVgQbPDEYYgFU8GAfU5r8o5F5/ 7zYcgbTsiLDbOloImFNgfZ3Iye0n7GLPdq+025BNmF1wztw5+ZxRgkgKr7NciKKlA0ba rJfwdR1mdL5qCc4S/rJ3xD9MkVV4boxDvzIR0r8Woqt/DSsYH4agwpaXZf3vdGqXUVMG Oz9jtABWF7dTIc81FHX/H63WbgbVh+b/tBk1Ax1WKi3ZYJIY14il5pag2vqd+ikOUAoB 4Z7Q== X-Gm-Message-State: ALoCoQmK6BMr4ohsEONQoEGLfZv0YOG54OfdOUQuHB/4VnzDAn4XsDk/P+kJgmzZtiWPNvPMAABI X-Received: by 10.224.125.68 with SMTP id x4mr88393610qar.78.1415197145213; Wed, 05 Nov 2014 06:19:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.10.69 with HTTP; Wed, 5 Nov 2014 06:18:45 -0800 (PST) In-Reply-To: References: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> From: Adam Langley Date: Wed, 5 Nov 2014 06:18:45 -0800 Message-ID: To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_2rlk_zgljhu2WRzpKJhaLk74ZA Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:19:08 -0000 On Wed, Nov 5, 2014 at 4:49 AM, Bodo Moeller wrote: > This isn't correct, and isn't what was said at the meeting. As discussed at > the meeting, YouTube currently allows two cipher suites for video streams, > TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but Firefox > doesn't support the former without ECDHE > (https://bugzilla.mozilla.org/show_bug.cgi?id=1029179). Some locations additionally support ECDHE_RSA_AES_128_GCM_SHA256, which we are testing now. Cheers AGL From nobody Wed Nov 5 06:24:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8C71A890A for ; Wed, 5 Nov 2014 06:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1Hi-lzN4IXJ for ; Wed, 5 Nov 2014 06:24:00 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF41A1B46 for ; Wed, 5 Nov 2014 06:24:00 -0800 (PST) Received: from [10.70.10.71] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 60283F984 for ; Wed, 5 Nov 2014 09:23:57 -0500 (EST) Message-ID: <545A32EC.2040100@fifthhorseman.net> Date: Wed, 05 Nov 2014 09:23:40 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: IETF TLS WG References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> <20141105012314.GG23599@mournblade.imrryr.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5irbBN05Gi1F17THn9TpcS9Fgiik8dgRq" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PbbGnVcdg2lMNoUdHFw_8SXYCoM Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:24:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5irbBN05Gi1F17THn9TpcS9Fgiik8dgRq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/05/2014 06:56 AM, Bodo Moeller wrote: > [*] Minor editing issue: it actually says that you can use exponents in= the > [2,2^224] range, but also says that you "should choose a secret key of = at > least 224 bits". Since there's no discussion of leading zeros in the > document (I think), the latter could be read as requiring a [2^223, ...= ] > range. Thanks for this suggestion, Bodo. i'll incorporate it in the next revisi= on. --dkg --5irbBN05Gi1F17THn9TpcS9Fgiik8dgRq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUWjLwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpc8JMQALitC1yGN1nwc/BFKhQvLGbN vK1e8QowNggrkgL+0a6s4f242vrlGh3dIOloq2fd526lspNe79UDa2n1HvScefsX 29t0fgpKfPmL4J7oFRcR8UmHtSpztGxF9wWzNOIgNFlnRqKFPPS9K77ArtHUWxs3 EGXMwzYjIMh5pKYFUUs4qzcLImw9UMear5upGWoMOPVJpO+R2RLZcwDfn3Nx3I/q CAimwc3T39gqCp/OnRgGyN4LjFGAwYVx6xBorGuk/ggRhGqRZ3uMA3wQ9Gmsrbs7 C+BAKzx3U96HsCFsBloEXZy2FHn05OoJ9TNEtw1Z6d2kP3xYNtnI2QUMkl+ZJ84n Q9eHnbio8tg2EnPkfDbhigRiSvboIx/ICLpfBO1vDj5JtozdCceOGYIlUulJ9jES S9c7lpQAAhd2lkOHTwA4ehunC45t0MOPKHZYhcWZSX4y9nEHbCj+F8nIeUAL+E4C Xx5XD3trQUaFiExx3YotnP1RU2bJ4TxVle+2vOwUO02PdkLYoa/z5dZWGkjaAIU2 R3dKWan7SP3A5XgX+yZfOMeTMJE2YTsmApRUCFdidpnZFfuXUX7O8Ifsj3KLWmzj wI/mRWZ4VWogAf6qfZBEFRau+wl/GsU0Rpuz6HP1HX1JYw13kKWTVTwu4OaCJU9+ U3CmcomJ0bqpe4XXSxZo =J7hg -----END PGP SIGNATURE----- --5irbBN05Gi1F17THn9TpcS9Fgiik8dgRq-- From nobody Wed Nov 5 06:38:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575BA1A1B31 for ; Wed, 5 Nov 2014 06:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QweGdDKgkLux for ; Wed, 5 Nov 2014 06:38:04 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637291A890F for ; Wed, 5 Nov 2014 06:38:04 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn18so8794813igb.13 for ; Wed, 05 Nov 2014 06:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zi3DCJKtCHLnHEgdoD2vqJRIwrENFipMJko+jOqmMiY=; b=M5p17x3HdWB8XO9UL3GXwZ5Np5EquLBuREDSv8U9QgU1xgUD41QCy3eWEvOLb+DdLb fxYQ6BVYQ0zibIl72x3AMYPEwk4/yVadO3qkZ1D1mAy+rvpzEeSnvxjBIhDNN4VxUvJq wL5wlPpySDQQqyXHak8TeygK55ACfMOTcQwzenikyQZb/TpDgpqJUDV/DI/2B9maVWrR 90/TFbcfxL7nBW+EzFI7EzZkIsEBHzsc8+pI0jmhAjwnQUNWAhIPOdDpuMA99sB+zDXS ZZguApGNgaXQ0iHodAjLmc7WnWwU8Jo7rUPtcIB9/WsM1KfZO02VVC+kXY6T2JLdAdEC 45eA== X-Received: by 10.43.164.200 with SMTP id mt8mr4941545icc.22.1415198283618; Wed, 05 Nov 2014 06:38:03 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id t1sm168044ioe.17.2014.11.05.06.38.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 06:38:03 -0800 (PST) Message-ID: <545A3646.50807@gmail.com> Date: Wed, 05 Nov 2014 09:37:58 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Turner , "TLS@ietf.org (tls@ietf.org)" References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tvT3PkURANwVd8UlgKcV-rlVJvY Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:38:06 -0000 Hi Sean: I think supporting 2048-bit defined discrete log groups would be acceptable. Added note (not part of scope of the straw poll): It would be useful to explicitly state that if short exponents are used with these 2048-bit defined groups, these shall be drawn at random from the set of 224-bit integers. (The current draft does not spell this out explicitly.) Of course, the more conservative expression would be "drawn at random from the set of m-bit integers, where m is at least 224". Best regards, Rene On 11/4/2014 12:49 PM, Sean Turner wrote: > Hi! > > At the TLS Interim meeting in Paris, the WG discussed the FF DHE draft (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/). The chairs would like to poll the WG on one of the issues in the draft namely the size of the minimum group. > > The draft currently includes a minimum group size of 2432 but the WG also discussed 2048. Groups smaller than 2048 were discounted for a standards track document as too weak for use but might be documented in a separate “historic” draft. To help us reach consensus on this point, please reply to this email indicating whether you favor a “2048" or “2432” minimum group size. Note we’re also looking to specify the smallest number of options for groups as is acceptable - i.e., we’re not looking at specifying both 2048 and 2432. > > Background: Regardless of whether you agree with what follows or not, the following has been put forward as the rationale. We don’t need comments on the rationale, we’re just providing it for background. > > 1) 3DES has a 112-bit work factor and is still considered acceptable in TLS 1.2 and the DLOG keying material shouldn’t be any weaker than the symmetric cipher. > > 2) There is some disagreement about the work factor for the DLOG keys - e.g., NIST says 112-bit work factor correlates to 2048-bit DLOG keys but ECRYPT-II says 112-bit work factor correlates to 2432-bit DLOG keys (see references in draft). > > 3) The other point made about 2048-bit DLOG is that it’s a power of 2 and there’s parity with the public key sizes. > > Cheers, > j&s > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Wed Nov 5 06:44:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0831A896D for ; Wed, 5 Nov 2014 06:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lxx3jL8vhBV5 for ; Wed, 5 Nov 2014 06:44:49 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2587D1A894A for ; Wed, 5 Nov 2014 06:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=d5ZXZo/asyFrUivydWVEfEjk8h4ixkj5ozwe7iFNh1k=; b=noYy6Gz3KeCs+E1AleyJFzyAMMfy0htcHRVEjfJfzPc0y28FlMsdgL4Hz6V17tF3KISpLuqXfA1AzSdupTXp7Ksm0A8bJ4H+2N4+Pv3YpTwrh4OaA4RByS/5GliMtzWfBd6IvwkE3RgKn1vff09eqOjI3iFMaitsZrSXvXbC2zw=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xm1pB-0003yt-3m for tls@ietf.org; Wed, 05 Nov 2014 15:44:41 +0100 Message-ID: <545A37DE.6000501@polarssl.org> Date: Wed, 05 Nov 2014 15:44:46 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5NtqVpTsmmic_eo6x7CBzDACBLA Subject: [TLS] RFC 7366 and resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:44:50 -0000 Hi, Unless I missed it, RFC 7366 does not say what should happen during session resumption. So I checked what RFC 5246 has to say: In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption. Most current TLS extensions are relevant only when a session is initiated: when an older session is resumed, the server does not process these extensions in Client Hello, and does not include them in Server Hello. However, some extensions may specify different behavior during session resumption. It seems to me that RFC 7366 falls in the same category as "Most current TLS extensions" above, ie is only relevant when a session is initiated, and on resumption the server should ignore the extension and restore the state from the saved session. Eg: (Assuming a CBC ciphersuite is used.) Initial handshake: client sends EtM ext, server replies with EtM ext, EtM is used to protect traffic. Resumed handshake: client sends EtM ext + ticket/session ID, server chooses to resume session, server does not send back the EtM extension, EtM is used to protect traffic. For example, this is what RFC 6066 prescribes for the truncated_hmac extension that is very similar in the way it works (except it lowers security, while EtM strengthens it...), so it seems only logical to do the same here. But I thought it might not hurt to check, just to be sure. Thanks in advance for any comment, Manuel. From nobody Wed Nov 5 06:56:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23941A1F70 for ; Wed, 5 Nov 2014 06:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKH-c4FNKJ0S for ; Wed, 5 Nov 2014 06:56:05 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA4D1ACCF2 for ; Wed, 5 Nov 2014 06:56:05 -0800 (PST) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0M8opw-1Xtgz833kK-00C9PK; Wed, 05 Nov 2014 15:56:03 +0100 Received: by mail-oi0-f44.google.com with SMTP id h136so12189193oig.31 for ; Wed, 05 Nov 2014 06:56:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.212.207 with SMTP id l198mr30114215oig.12.1415199360429; Wed, 05 Nov 2014 06:56:00 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 06:56:00 -0800 (PST) In-Reply-To: References: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> Date: Wed, 5 Nov 2014 15:56:00 +0100 Message-ID: From: Bodo Moeller To: Adam Langley Content-Type: multipart/alternative; boundary=001a113d24222a3d6e05071dc7de X-Provags-ID: V02:K0:dYOtwi+fyoCDi0uV+C2ir1s8vp9tqdwe7rSH4HSHN4i 3Kj3v/3uBvQBYLV1CUq+bwKvvkdceZGo9YlT7CiDXW2uZ2jftD 8ritqijAFtwxLwbtjcDuK5rNRAbHaQtnOFBwn/0y7dFQ/pbOty yIerqmvaW77N1oWg5249GSt+WBGwXhKmJ/H9LEK7+uVDSZVref DOZwbYlLx17rpJhnrr6OxcBzXxyEDo9h8aO0rd7D/QSwsELE/h aEF1jLTiHArussAJhayHC6+tFw5GgwwRf7ArWoM82pUR8Zdexy TLfBa46dD5CBzUkM76VJe1ycuth/+I9n5Aay/gLZrV3ck8vcbp ixADNwtR2V2jUHqOhjA2h5Co+zjH5YJhkH2s/CrgEZskC4rHMG lf3snOuAvAfoU7UlkMRE6n9+6+u0tGPl1OAk0gC4YPQq62RHKy 6OqcW X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e0aHGSWpt-62hiIUnXhbnE2wcMs Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:56:11 -0000 --001a113d24222a3d6e05071dc7de Content-Type: text/plain; charset=UTF-8 Adam Langley : > On Wed, Nov 5, 2014 at 4:49 AM, Bodo Moeller wrote: > > > This isn't correct, and isn't what was said at the meeting. As discussed > at > > the meeting, YouTube currently allows two cipher suites for video > streams, > > TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but Firefox > > doesn't support the former without ECDHE > > (https://bugzilla.mozilla.org/show_bug.cgi?id=1029179). > > Some locations additionally support ECDHE_RSA_AES_128_GCM_SHA256, > which we are testing now. > Yes, but the above is about correcting the 2014-10-21 minutes, not updating them to reflect the current status. Bodo --001a113d24222a3d6e05071dc7de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam= Langley <agl@google.com>:
On Wed, Nov 5, 2014 at 4:49 AM, Bodo Moeller <bmoeller@acm.org> wrote:
=C2= =A0
> This isn't correct, and isn't what was said at the meeting. As= discussed at
> the meeting, YouTube currently allows two cipher suites for video stre= ams,
> TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but Fire= fox
> doesn't support the former without ECDHE
> (https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179)= .
=C2=A0
Some locations additionally support ECDHE_RSA_AES_128_GCM_SHA256, which we are testing now.

Yes, but the = above is about correcting the=C2=A02014-10-21 minutes, not updating them to= reflect the current status.

Bodo

--001a113d24222a3d6e05071dc7de-- From nobody Wed Nov 5 06:56:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D231AC413 for ; Wed, 5 Nov 2014 06:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GByxNAZRyx0 for ; Wed, 5 Nov 2014 06:56:10 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D741ACCF3 for ; Wed, 5 Nov 2014 06:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=lNCLsBcVA+o9z6A9YPK0HuZkHB4e5Q55YpLI3tSn9wA=; b=HkH45q4yMXsevOMISW0oM06S3801NCauWhR8UEutFb7y2PRujmuYBaxMZCl4ZpTNxv6FtxZXSG1wggqC+2doJoXcT9M7nlksfwWjd3Sh+bdYLqZUUxQr/w+xSdImipwtqmltUzog/6SyP1YeXEne4qhmcaTEc1R95W0hNScxgGg=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xm209-0003zk-J0 for tls@ietf.org; Wed, 05 Nov 2014 15:56:02 +0100 Message-ID: <545A3A86.9050806@polarssl.org> Date: Wed, 05 Nov 2014 15:56:06 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KAk6RydZKHH-Bju4J2HQZVKEiyI Subject: [TLS] IANA referencing obsolete RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:56:11 -0000 Hi, I'm not sure what is the right place to mention this, but I'm sure there are people here who know... I just noticed the IANA TLS extension registry is still referencing RFC 4507 for session tickets, while it has been obsoleted by RFC 5077. https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml Manuel. From nobody Wed Nov 5 08:28:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A107B1A899D for ; Wed, 5 Nov 2014 08:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76Mqrlv9c_bh for ; Wed, 5 Nov 2014 08:28:25 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3BF1A037F for ; Wed, 5 Nov 2014 08:28:24 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id ge10so979463lab.22 for ; Wed, 05 Nov 2014 08:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=d0EmQgqV1U6IOjivPh4pkkNZ6J8RWhtJDsZD9/Kg0Zk=; b=Guf6QhMZWfm2wHXJf3ZB4fyizaJ1p3sIU5dUiLrQ/jF04P4YsFiW/qTJHhi/lJoSSm yLL1OasnhYRZeOcMb7kN1X/5TAgtnbn0qFgcE0XTKnly69WOxjCgf3XiAtOaLxsAKrwM inKB8eoyf5M39Koul2eDeDeuaUe1gjnYrYcx02JfHUsiVqFOOsztpPSlUbCZrfN4d7ms 2BmAxapNhXaUlYLy3gMT1oBTl8oRVbu2cmM58k1PV666wZdyr7IT46CbbcvALuVLRAiS 2nM1x+Jbo9MF4klS/Kw2kbA2Qy7xpcLbWqfEAkh015pPeRQCtPri1KDxR4+4g6mGWz9d bisQ== X-Received: by 10.152.6.41 with SMTP id x9mr21726570lax.95.1415204902677; Wed, 05 Nov 2014 08:28:22 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Wed, 5 Nov 2014 08:27:52 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Wed, 5 Nov 2014 18:27:52 +0200 X-Google-Sender-Auth: B1GFEuzxBvQzyyUmXU0HTZ5GBFs Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0141a9a282326e05071f117f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d51slkkJw7hXxQcJcNM9vzwxfxM Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:28:27 -0000 --089e0141a9a282326e05071f117f Content-Type: text/plain; charset=UTF-8 The issue of validity period of the static key g^s is not different than that of a regular certificate except that the server can choose a shorter validity period for g^s than the one for the certificate. That is, if the client's clock is skewed by Delta and the validity of g^s is up to time T, the client will accept g^s till time T+Delta. Similarly, if the certificate expires at time T', the client will accept it until T'+Delta. In either case, if T wrote: > > > On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd wrote: > >> On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla wrote: >> > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk > >> The second option may be trivial, if the client already has some >> > generic key storage mechanism (e.g., one in software) though it's of >> > course more work for the programmer. However, if the client has a >> > non-generic key storage mechanism, such as a smart card with their >> > key, then this becomes a significant problem, as it may not be able to >> > store a DH key and/or use it for the kind of key derivation that >> > would be required here. In that case, the client must find somewhere >> > to store the DH key, which may entail significant effort. >> > >> > >> > This last point points us to a larger issue we need to consider here, >> > which is as follows. In TLS as it currently stands (both in 1.2 and >> > the current TLS 1.3 draft), you can implement a system where the >> > authentication keys are stored in hardware and an attacker who >> > compromises either the client and the server cannot steal a credential >> > which he can then use to establish new sessions [Note that if >> > he steals the session cache, he can use it to resume old sessions.] >> > In particular, because each signature is tied to a specific exchange, >> > the attacker cannot reuse signed ephemeral values to impersonate the >> > server. >> >> 1: If ephemerals are reused, you can MITM until they are refreshed. A >> time-bounded cert equivalent isn't worse in this regard. >> > > I'm not following your reasoning here. For convenience, let's > restrict ourselves to thinking about 1-RTT handshakes. With > TLS 1.2 (or the current TLS 1.3 draft), the server can stop future clients > from accepting any DH share simply by refusing to sign any > further handshakes with that share. If, for instance, it determines > a share has been compromised, it can prevent any new connection > initiations with that share. By contrast, with a time-bounded > cert, an attacker can get clients to continue using that share until > the time expires (or perhaps longer, as you suggested elsewhere). > > The situation is of course somewhat more complicated with 0-RTT > because the server must provide the client with a DH share which > he can use for future connections. However, he need not provide > every client with the *same* key, and if the key is authenticated > as part of the initial connection establishment, an attacker cannot > convince other clients to use that key. This is not true with certificates > (or of statically signed keys) which are inherently portable. > > > > 3: 0-RTT requires a certificate that can be used for encryption as >> well as signing, in ways that don't interfere. We need to use a DH >> share anyway for this, and might as well use it again. > > > I'm not sure I follow what you're saying here either. It's true that the > server needs to supply a semi-static DH share, but there's no inherent > reason it needs to be supplied as part of a free-standing transferrable > credential such as a certificate, though of course doing so allows you > to amortize the signature. > > > > However, in a system where the server signs a long-term DH value, it >> > may be the case that that value cannot be stored in the same hardware >> > module that you are using for your signature key (purely for >> > implementation reasons having to do with the interface the module >> > exposes). In that case, the DH secret will be stored in software and >> > compromise of the server potentially leaks a credential which can be >> > used to impersonate the server for a significant period of time, where >> > that time is dictated by the maximum amount of client-side clock error >> > the server is willing to tolerate, so probably measured in days to >> > weeks (and more if you are concerned about the time resetting attack >> > Watson, Ilari, and I were discussing.) I haven't decided yet sure how >> > serious an issue this is, but it's probably worth addressing >> > explicitly. >> >> I'm not sure, because it wasn't explicitly addressed in Hugo's >> original email, but it seems that the relevant server question is how >> long it wants to receive 0-RTT without requiring the client to find >> the new address: I don't remember resumption being addressed one way >> or the other. So the server isn't picking the DH share lifetime for >> reasons of clock skew, but rather for PFS refreshment if 0-RTT is >> being used. > > > I think we may be talking past each other. Let me try again. > > Forget about 0-RTT and just consider the 1-RTT flow. In the first flight > the server needs to supply a signed version of g^s. Unless we want > that value to be acceptable to clients indefinitely, it must have some > validity interval. However, because clients have inaccurate clocks, > that interval can't be too narrow or it will cause clients to reject the > g^s value. I'm not sure how narrow it can be, but I would be surprised > if it were less than 12 hours or so. Perhaps someone who runs a > large server farm can report on the values they have historically > seen in the GMT field of the ClientRandom. > > -Ekr > > > > > > --089e0141a9a282326e05071f117f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The issue of validity period of the static key = g^s is not different than that of a regular certificate except that the ser= ver can choose a shorter validity period for g^s than the one for the certi= ficate. That is, if the client's clock is skewed by Delta and the valid= ity of g^s is up to time T, the client will accept g^s till time T+Delta. S= imilarly, if the certificate expires at time T', the client will accept= it until T'+Delta. In either case, if T<T' the client will acce= pt g^s for less time than it would accept the certificate.

(Needless to say, a client should not accept a signed g^s past the = expiration date of the certificate signing g^s).

Am= I misunderstanding/missing something?

Hugo



On Tue, Nov 4, 2014 at 4:12 PM, Eric Resco= rla <ekr@rtfm.com> wrote:


<= span class=3D"">On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd <watsonbla= dd@gmail.com> wrote:
On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla &= lt;ekr@rtfm.com> w= rote:
 > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>> = The second option may be trivial, if the client already has some
<= /div> > generic key storage mechanism (e.g., one in software) though it's = of
> course more work for the programmer. However, if the client has a
> non-generic key storage mechanism, such as a smart card with their
> key, then this becomes a significant problem, as it may not be able to=
> store a DH key and/or use it for the kind of key derivation that
> would be required here. In that case, the client must find somewhere > to store the DH key, which may entail significant effort.
>
>
> This last point points us to a larger issue we need to consider here,<= br> > which is as follows. In TLS as it currently stands (both in 1.2 and > the current TLS 1.3 draft), you can implement a system where the
> authentication keys are stored in hardware and an attacker who
> compromises either the client and the server cannot steal a credential=
> which he can then use to establish new sessions [Note that if
> he steals the session cache, he can use it to resume old sessions.] > In particular, because each signature is tied to a specific exchange,<= br> > the attacker cannot reuse signed ephemeral values to impersonate the > server.

1: If ephemerals are reused, you can MITM until they are refreshed. = A
time-bounded cert equivalent isn't worse in this regard.

I'm not following your reasoning here. For= convenience, let's
restrict ourselves to thinking about 1-RT= T handshakes. With
TLS 1.2 (or the current TLS 1.3 draft), the se= rver can stop future clients
from accepting any DH share simply b= y refusing to sign any
further handshakes with that share. If, fo= r instance, it determines
a share has been compromised, it can pr= event any new connection
initiations with that share. By contrast= , with a time-bounded
cert, an attacker can get clients to contin= ue using that share until
the time expires (or perhaps longer, as= you suggested elsewhere).

The situation is of cou= rse somewhat more complicated with 0-RTT
because the server must = provide the client with a DH share which
he can use for future co= nnections. However, he need not provide
every client with the *sa= me* key, and if the key is authenticated
as part of the initial c= onnection establishment, an attacker cannot
convince other client= s to use that key. This is not true with certificates
(or of stat= ically signed keys) which are inherently portable.



3= : 0-RTT requires a certificate that can be used for encryption as
well as signing, in ways that don't interfere. We need to use a DH
share anyway for this, and might as well use it again.
I'm not sure I follow what you're saying here ei= ther. It's true that the
server needs to supply a semi-static= DH share, but there's no inherent
reason it needs to be supp= lied as part of a free-standing transferrable
credential such as = a certificate, though of course doing so allows you
to amortize t= he signature.


> However, in a system where the server signs a long-term DH value, it > may be the case that that value cannot be stored in the same hardware<= br> > module that you are using for your signature key (purely for
> implementation reasons having to do with the interface the module
> exposes). In that case, the DH secret will be stored in software and > compromise of the server potentially leaks a credential which can be > used to impersonate the server for a significant period of time, where=
> that time is dictated by the maximum amount of client-side clock error=
> the server is willing to tolerate, so probably measured in days to
> weeks (and more if you are concerned about the time resetting attack > Watson, Ilari, and I were discussing.) I haven't decided yet sure = how
> serious an issue this is, but it's probably worth addressing
> explicitly.

I'm not sure, because it wasn't explicitly addressed in Hugo= 's
original email, but it seems that the relevant server question is how
long it wants to receive 0-RTT without requiring the client to find
the new address: I don't remember resumption being addressed one way or the other. So the server isn't picking the DH share lifetime for
reasons of clock skew, but rather for PFS refreshment if 0-RTT is
being used.

I think we may be talkin= g past each other. Let me try again.

Forget about = 0-RTT and just consider the 1-RTT flow. In the first flight
the s= erver needs to supply a signed version of g^s. Unless we want
tha= t value to be acceptable to clients indefinitely, it must have some
validity interval. However, because clients have inaccurate clocks,
that interval can't be too narrow or it will cause clients to rej= ect the
g^s value. I'm not sure how narrow it can be, but I w= ould be surprised
if it were less than 12 hours or so. Perhaps so= meone who runs a
large server farm can report on the values they = have historically
seen in the GMT field of the ClientRandom.

-Ekr



=C2=A0


--089e0141a9a282326e05071f117f-- From nobody Wed Nov 5 09:45:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91AB1A9035 for ; Wed, 5 Nov 2014 09:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNDCpY6mOkGn for ; Wed, 5 Nov 2014 09:45:29 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEAB1A9028 for ; Wed, 5 Nov 2014 09:45:29 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id q1so1159726lam.10 for ; Wed, 05 Nov 2014 09:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ptukLXHLlDxx5RPTU9QtVVeHWtV2j+f7MVEF4lD4To=; b=HLZ1Z/O5iAIhSVys0THFHrjLdwpPwWNAdcXOoYotXeQClhuv8Iz99XCtfpbVP6sK76 2dXurDZET7u1qqEVj6SucjNSc69U6q/yJDZ7Hn5wUCvSeehmkQOrtf/QVqfv5e71Sn3f SHBSXPAUnPLobXzcQnPyr6QTaagu6uSh5hAUVSgtlsIRO4trnGk939U8SGIcQ6xgtJJs JBTNikjaHK/QSlf7/BZ1a8PQbYnB7E25auXZW3MlKnz54HfG+EuAndfBktLd+dk9PNhD WgNccmWs4vrkLgopQRXOVYLigKhDXap0ynXtfOhBBp9A8hAM7YU0CHKim40RyE+0DzAU RcUg== MIME-Version: 1.0 X-Received: by 10.112.146.229 with SMTP id tf5mr25049513lbb.73.1415209527665; Wed, 05 Nov 2014 09:45:27 -0800 (PST) Received: by 10.25.215.134 with HTTP; Wed, 5 Nov 2014 09:45:27 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Nov 2014 09:45:27 -0800 Message-ID: From: Martin Thomson To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/faRVAMi6tlTPx6-1vsvIG4KXu3I Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:45:31 -0000 On 5 November 2014 08:27, Hugo Krawczyk wrote: > The issue of validity period of the static key g^s is not different than > that of a regular certificate except that the server can choose a shorter > validity period for g^s than the one for the certificate. That is, if the > client's clock is skewed by Delta and the validity of g^s is up to time T, > the client will accept g^s till time T+Delta. Similarly, if the certificate > expires at time T', the client will accept it until T'+Delta. In either > case, if T the certificate. > > (Needless to say, a client should not accept a signed g^s past the > expiration date of the certificate signing g^s). > > Am I misunderstanding/missing something? I think that the core concern is that Delta is basically unbounded in some implementations (see [1]). To make realistic progress on TLS, I think that we have to consider this as either basically impossible to fix, or as a problem that will be solved somewhere else. That means, that until it is solved, we should instead acknowledge the problem and move on. It's a problem worth solving, but we could waste a lot of time on it. If someone solves it, then we can react appropriately at that time. [1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf From nobody Wed Nov 5 09:51:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB25D1A9069 for ; Wed, 5 Nov 2014 09:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBxF6NfG6wIi for ; Wed, 5 Nov 2014 09:51:31 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D97C21A9051 for ; Wed, 5 Nov 2014 09:51:28 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 8FA9D6B007C for ; Wed, 5 Nov 2014 09:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=s1YNs/8qjy74nX+0RKd9 64zdsbY=; b=bYjDaWTxy8XNHScXia25B4i317ZrHyEAMp46GOhp4QzxmWGabXBZ YjXbkFYjpel4h+GrcFfZ2kJOqTtTm9CFwXbm9sI/d0W2eYLNz8WG+8tohNSkMI+6 DN75UtQwEcOYLb2H1TwCfwZFS6SMjimOQcOetphtaniaOeBPu7+PdN4= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 455E86B0070 for ; Wed, 5 Nov 2014 09:51:28 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so1519588wgg.37 for ; Wed, 05 Nov 2014 09:51:27 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.181.8.98 with SMTP id dj2mr7698735wid.70.1415209887112; Wed, 05 Nov 2014 09:51:27 -0800 (PST) Received: by 10.216.32.135 with HTTP; Wed, 5 Nov 2014 09:51:26 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Nov 2014 11:51:26 -0600 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kgmh427DK3ikxQLD2H1tBCTzGhE Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:51:33 -0000 On Wed, Nov 5, 2014 at 11:45 AM, Martin Thomson wrote: > On 5 November 2014 08:27, Hugo Krawczyk wrote: >> The issue of validity period of the static key g^s is not different than >> that of a regular certificate except that the server can choose a shorter >> validity period for g^s than the one for the certificate. That is, if the >> client's clock is skewed by Delta and the validity of g^s is up to time T, >> the client will accept g^s till time T+Delta. Similarly, if the certificate >> expires at time T', the client will accept it until T'+Delta. In either >> case, if T> the certificate. > > I think that the core concern is that Delta is basically unbounded in > some implementations (see [1]). > > [...] > > [1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf Perhaps we should pin latest datetime advertised by the server for which other things are being pinned. This would prevent time travel into the past. Time travel into the far future is, presumably, not that big a deal, even with pinning, because server operators will strive to make sure that doesn't happen. Nico -- From nobody Wed Nov 5 09:57:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9F1A9041 for ; Wed, 5 Nov 2014 09:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6A-z1JRgppO for ; Wed, 5 Nov 2014 09:56:51 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA6B1A906D for ; Wed, 5 Nov 2014 09:56:50 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id t59so573815yho.36 for ; Wed, 05 Nov 2014 09:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4KZ3OJUnJLUQXKixcNa17wWQOekv0slTEQKyXBim2Ec=; b=FKXy5ENGjjgnsyp0hGMmG9mqg49CZvbdIFDTg4d9XgAMbs8Qd6gBQpUtobi+4GJnTb gjNtCklM8GI4dBCXuEMMy+LjcDTG3apaP/OiuGjbFx39Xp5tbXh1R8tXucmwemZvTdBE gkdiszgFMMyNBKAMY8+G9TmWcILs5bNo8cZIPn435TWghNFssXAbSSDnGfauhRbZfa6S UGYOFMNZdoHfhqc2N6wcjvKzqMD9lESyBSNKNUIVIVhBDFm2pylLibVu3kHGl7PQFsQK AWUJWxQEbA8X9HO+EJdLt7gdK+3AhDxqnQiHIfAQ7NMbg0cqMxF4gfc6hxOfnpDp9ele 3zpQ== MIME-Version: 1.0 X-Received: by 10.170.87.7 with SMTP id e7mr6333030yka.126.1415210210192; Wed, 05 Nov 2014 09:56:50 -0800 (PST) Received: by 10.170.195.203 with HTTP; Wed, 5 Nov 2014 09:56:50 -0800 (PST) Received: by 10.170.195.203 with HTTP; Wed, 5 Nov 2014 09:56:50 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Nov 2014 09:56:50 -0800 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: multipart/alternative; boundary=001a113a8c04dc741e0507204d83 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/34N6vGwdQjLuX-jxaTKRURj80yo Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:56:56 -0000 --001a113a8c04dc741e0507204d83 Content-Type: text/plain; charset=UTF-8 On Nov 5, 2014 9:51 AM, "Nico Williams" wrote: > > On Wed, Nov 5, 2014 at 11:45 AM, Martin Thomson > wrote: > > On 5 November 2014 08:27, Hugo Krawczyk wrote: > >> The issue of validity period of the static key g^s is not different than > >> that of a regular certificate except that the server can choose a shorter > >> validity period for g^s than the one for the certificate. That is, if the > >> client's clock is skewed by Delta and the validity of g^s is up to time T, > >> the client will accept g^s till time T+Delta. Similarly, if the certificate > >> expires at time T', the client will accept it until T'+Delta. In either > >> case, if T >> the certificate. > > > > I think that the core concern is that Delta is basically unbounded in > > some implementations (see [1]). > > > > [...] > > > > [1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf > > Perhaps we should pin latest datetime advertised by the server for > which other things are being pinned. This would prevent time travel > into the past. Time travel into the far future is, presumably, not > that big a deal, even with pinning, because server operators will > strive to make sure that doesn't happen. Or kernels can set the flag that stops this from being possible. We should note the issue, and, as with randomness, let the vendors solve it. For a problem solved by a configuration change, we are spending a lot of time on it. Sincerely, Watson Ladd > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a113a8c04dc741e0507204d83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 5, 2014 9:51 AM, "Nico Williams" <nico@cryptonector.com> wrote:
>
> On Wed, Nov 5, 2014 at 11:45 AM, Martin Thomson
> <martin.thomson@gmail.c= om> wrote:
> > On 5 November 2014 08:27, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
> >> The issue of validity period of the static key g^s is not dif= ferent than
> >> that of a regular certificate except that the server can choo= se a shorter
> >> validity period for g^s than the one for the certificate. Tha= t is, if the
> >> client's clock is skewed by Delta and the validity of g^s= is up to time T,
> >> the client will accept g^s till time T+Delta. Similarly, if t= he certificate
> >> expires at time T', the client will accept it until T'= ;+Delta. In either
> >> case, if T<T' the client will accept g^s for less time= than it would accept
> >> the certificate.
> >
> > I think that the core concern is that Delta is basically unbounde= d in
> > some implementations (see [1]).
> >
> > [...]
> >
> > [1] https://www.blackh= at.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Sec= urity-wp.pdf
>
> Perhaps we should pin latest datetime advertised by the server for
> which other things are being pinned.=C2=A0 This would prevent time tra= vel
> into the past.=C2=A0 Time travel into the far future is, presumably, n= ot
> that big a deal, even with pinning, because server operators will
> strive to make sure that doesn't happen.

Or kernels can set the flag that stops this from being possi= ble. We should note the issue, and, as with randomness, let the vendors sol= ve it.

For a problem solved by a configuration change,=C2=A0 we are= spending a lot of time on it.

Sincerely,
Watson Ladd
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a113a8c04dc741e0507204d83-- From nobody Wed Nov 5 10:01:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847851A906D for ; Wed, 5 Nov 2014 10:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBOXQA74FB17 for ; Wed, 5 Nov 2014 10:01:09 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B179B1A88EE for ; Wed, 5 Nov 2014 10:01:09 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 8A11520047D12 for ; Wed, 5 Nov 2014 10:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=2LH4K87fesJ7c+RUJVUP o3p+XwU=; b=cRO338b72CEosBidBCs1vkQsOuD7QQ1iB8gqCBmnbEfVt8cJ7dVT evsA5BB7NQ1ANxW6jhpQLxD5/rqcZSOB0bj7k1Fl/gt/we2XA+Jf2D4JLxyTcIcz xWYa2dQayJa9T87ddbdCNpikPHj9hTBYZ5ZiCm2OoMUWpoThRa7bFqM= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 3CDCD20046915 for ; Wed, 5 Nov 2014 10:01:09 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so1545457wgh.34 for ; Wed, 05 Nov 2014 10:01:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.98.233 with SMTP id el9mr24337983wib.3.1415210467869; Wed, 05 Nov 2014 10:01:07 -0800 (PST) Received: by 10.216.32.135 with HTTP; Wed, 5 Nov 2014 10:01:07 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Nov 2014 12:01:07 -0600 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sHwPwlQ2BPMsTzDXyV3ZmTC0vDg Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:01:10 -0000 On Wed, Nov 5, 2014 at 11:56 AM, Watson Ladd wrote: > On Nov 5, 2014 9:51 AM, "Nico Williams" wrote: >> Perhaps we should pin latest datetime advertised by the server for >> which other things are being pinned. This would prevent time travel >> into the past. Time travel into the far future is, presumably, not >> that big a deal, even with pinning, because server operators will >> strive to make sure that doesn't happen. > > Or kernels can set the flag that stops this from being possible. We should > note the issue, and, as with randomness, let the vendors solve it. User-land code can "correct" kernel time. For example, most Kerberos libraries record time offset between the client and the KDC, and correct local time when making AP-REQs for any service subsequently. Clients trust KDCs, so that's OK. But if TLS clients also attempt to correct local clocks on the basis of time advertised by arbitrary servers... Obviously, that's the problem: TLS clients should not use the TLS protocol to attempt to correct local clock skew. Nico -- From nobody Wed Nov 5 11:33:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32181A1B77 for ; Wed, 5 Nov 2014 11:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGJ5zRMF5MZA for ; Wed, 5 Nov 2014 11:33:27 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853181A6F17 for ; Wed, 5 Nov 2014 11:33:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415216007; x=1446752007; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Z1G2mME69U+MGQ3vdne3yUECAFXbO4+Jh9dh4pbIMso=; b=uXJMIcz8MnuDlkpKAsob+lWrYG1wArdZl/Gl/iE38Nc70wnIW/p+jeSg 8HJdgX11+Rin8Fj8xbmmYWGmujJt5r6Jgd3zI5tS+i2AeMxA/A9bkDg3v OZt6IudLSE/wddfqkRDZ6gn+7d7eLOMeVd+cFetgTNbbLUXhN4xkxawyw s=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="288021888" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Nov 2014 08:33:25 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 6 Nov 2014 08:33:24 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] RFC 7366 and resumption Thread-Index: Ac/5L10PbqvCu8SrQeawiXdvSsXfGg== Date: Wed, 5 Nov 2014 19:33:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9E0BD9@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fJEbKzH_336SZknkMlB_y5TBtnc Subject: Re: [TLS] RFC 7366 and resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 19:33:31 -0000 Manuel P=E9gouri=E9-Gonnard writes:=0A= =0A= >It seems to me that RFC 7366 falls in the same category as "Most current T= LS=0A= >extensions" above, ie is only relevant when a session is initiated, and on= =0A= >resumption the server should ignore the extension and restore the state fr= om=0A= >the saved session.=0A= =0A= Yes, it just follows standard practice from RFC 5246, so the server ignores= it=0A= if present in Client Hello.=0A= =0A= Peter.= From nobody Wed Nov 5 12:57:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7929E1ACD4F for ; Wed, 5 Nov 2014 12:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoFL-LHCY4bv for ; Wed, 5 Nov 2014 12:57:55 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720691A87E9 for ; Wed, 5 Nov 2014 12:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=5bEutAs+rYi9KaLqMhL96fg2575c/RKM1WrLEIdFNnI=; b=oiwyFGa1QvXk6bMs0HPhuntlidWFD/qCTXpP6PkjJdvqTcDa6iBj7du27LDenrjhLw5NG2PYJ2Qvb9/edioaY/BBKjJahBiEbSh8rRWRCS6+PiMEqwZvR+ZncxuFzQiFWpJhxtXfW9d73dfekiP99eCCn1C8vaw0q7M2p1xaTc8=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xm7e9-0004M0-FI; Wed, 05 Nov 2014 21:57:41 +0100 Message-ID: <545A8F49.70203@polarssl.org> Date: Wed, 05 Nov 2014 21:57:45 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C739B9E0BD9@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9E0BD9@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VjxKxkVY_DBQpV1JS8ISRKif9zE Subject: Re: [TLS] RFC 7366 and resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:57:56 -0000 On 05/11/2014 20:33, Peter Gutmann wrote: > Manuel Pégourié-Gonnard writes: > >> It seems to me that RFC 7366 falls in the same category as "Most current TLS >> extensions" above, ie is only relevant when a session is initiated, and on >> resumption the server should ignore the extension and restore the state from >> the saved session. > > Yes, it just follows standard practice from RFC 5246, so the server ignores it > if present in Client Hello. > Ok, thanks for the confirmation! Manuel. From nobody Wed Nov 5 14:44:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BEF1A00B9 for ; Wed, 5 Nov 2014 14:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeNw3UDq6BZ3 for ; Wed, 5 Nov 2014 14:44:40 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54FF1A008C for ; Wed, 5 Nov 2014 14:44:39 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id F044C3A18C; Wed, 5 Nov 2014 23:44:37 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 98AE841D13; Wed, 5 Nov 2014 23:44:37 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8E2081AF95; Wed, 5 Nov 2014 23:44:37 +0100 (CET) In-Reply-To: <545A8F49.70203@polarssl.org> To: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= Date: Wed, 5 Nov 2014 23:44:37 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20141105224437.8E2081AF95@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kAr9bNfKL6RwAhAbhuHBZ3Ys6Zo Cc: "" Subject: Re: [TLS] RFC 7366 and resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 22:44:42 -0000 Manuel P=E9gouri=E9-Gonnard wrote: > Peter Gutmann wrote: >> Manuel P=E9gouri=E9-Gonnard writes: >>=20 >>> It seems to me that RFC 7366 falls in the same category as "Most curren= t TLS >>> extensions" above, ie is only relevant when a session is initiated, and= on >>> resumption the server should ignore the extension and restore the state= from >>> the saved session. >>=20 >> Yes, it just follows standard practice from RFC 5246, >> so the server ignores it if present in Client Hello. > > Ok, thanks for the confirmation! Huh? I believe such behaviour to be partially WRONG (and a bad idea). Not returning the extension in ServerHello on resumption seems to be current worst^Wbest practice, but resuming a session that was originally negotiated with EtM when the resumption request is lacking the EtM extension looks like a bad idea to me. Btw. such behaviour means that any rfc5077-style TLS session tickets will have to accomodate all such properties, and all servers sharing the session tickets may have to be synchronously updated with a flag day... Btw. rfc6066 contains at least one self-inconsistency at this point: rfc6066 on the bottom of page 4 reads: *> Note also that all the extensions defined in this document are *> relevant only when a session is initiated. A client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extensions as it would send if it were not attempting resumption. When a client includes one or more of the defined extension types in an extended client hello while requesting session resumption: - The server name indication extension MAY be used by the server when deciding whether or not to resume a session as described in Section 3. - If the resumption request is denied, the use of the extensions is negotiated as normal. *> - If, on the other hand, the older session is resumed, then the *> server MUST ignore the extensions and send a server hello *> containing none of the extension types. In this case, the *> functionality of these extensions negotiated during the original *> session initiation is applied to the resumed session. And the definition of the Server Name Indication extension, that is part of this RFC 6066, explicitly contradicts the first sentence of the latter (*>) paragraph. But agrees with the second sentence: A server that implements this extension MUST NOT accept the request to resume the session if the server_name extension contains a different name. Instead, it proceeds with a full handshake to establish a new session. When resuming a session, the server MUST NOT include a server_name extension in the server hello. Personally, I would consider it much more logical for the EtM spec when it would "perform a full handshake instead" if a client proposes to resume a session that was originally established with EtM, but fails to include the EtM extension in the resumption request. This latter behaviour follows the "principle of least surprise". Whether the server has already flushed the session from the server-side cache that the client proposes for resumption should not affect the properties of the resulting security context. Otherwise the behaviour will become strangely non-deterministic, and the only part of one's software that should exhibit non-deterministic behaviour are those few functions that are officially labelled as random number generators. -Martin From nobody Wed Nov 5 15:06:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416DD1ACED1 for ; Wed, 5 Nov 2014 15:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZa4AUvHDKUP for ; Wed, 5 Nov 2014 15:06:20 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.82.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D43D1ACED6 for ; Wed, 5 Nov 2014 15:06:20 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id E6FF6E8FFC337; Wed, 5 Nov 2014 17:06:19 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id D642FE8FFC2EC for ; Wed, 5 Nov 2014 17:06:19 -0600 (CST) Received: from [173.73.121.234] (port=53683 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xm9ed-0004dI-5G; Wed, 05 Nov 2014 17:06:19 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Wed, 5 Nov 2014 18:06:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> To: Bodo Moeller X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1Xm9ed-0004dI-5G X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:53683 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n10GiyEVtJtaN2jd-pLNj1VabEs Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 23:06:23 -0000 On Nov 05, 2014, at 09:56, Bodo Moeller wrote: > Adam Langley : > On Wed, Nov 5, 2014 at 4:49 AM, Bodo Moeller wrote: > =20 > > This isn't correct, and isn't what was said at the meeting. As = discussed at > > the meeting, YouTube currently allows two cipher suites for video = streams, > > TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but = Firefox > > doesn't support the former without ECDHE > > (https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179). > =20 > Some locations additionally support ECDHE_RSA_AES_128_GCM_SHA256, > which we are testing now. >=20 > Yes, but the above is about correcting the 2014-10-21 minutes, not = updating them to reflect the current status. >=20 > Bodo I=92ll make sure these get updated. spt= From nobody Wed Nov 5 15:11:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA71A1A0F for ; Mon, 3 Nov 2014 13:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0rO2WB1WAA6 for ; Mon, 3 Nov 2014 13:51:12 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087EE1A1A12 for ; Mon, 3 Nov 2014 13:51:11 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id u7so8888194qaz.39 for ; Mon, 03 Nov 2014 13:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=NYbjcoc8dh9BbyUi8aeJ4fcGOHfKGe7B4Hi6bwUW1+k=; b=kk5ZEXv7vFNW/YTAjJ4KmHirDqlBbisrNrGNfOhDPKs2nOi6I8+OULlEfcPrV85X5+ +fPoG3W3Fmp1yO0xmarl57ynvgOpP5ZmgsGRJdL3PuLtWmTKQR9OA0maJBAS5nGmvJSP WY7+v/3S0M62p9Psj12Fmp/zoLrF+4dJMEqR+dWUfNw6d/mmuZLP0S78iNQ/xZ5hypFk 4wSbkFPXyjo3JhU5KFZSZpHTiv/Xqz4P7dNJMsgKrWN+128GvJ2f8ilroHSf+1RQoF8O trclCLpPIjvCT+ZQNQJ7S5aOuobBZxf4RQ07Kyxs6fV5iQMY4YuLRdxQWso0wtquHc4U G50A== X-Received: by 10.140.101.120 with SMTP id t111mr65903558qge.6.1415051471188; Mon, 03 Nov 2014 13:51:11 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id e49sm17880350qgf.15.2014.11.03.13.51.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Nov 2014 13:51:10 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Mon, 3 Nov 2014 16:51:09 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201411031651.09896.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pNp8gPaueT9qxK1S7eblNCHra3A X-Mailman-Approved-At: Wed, 05 Nov 2014 15:11:01 -0800 Cc: ietf-http-wg@w3.org Subject: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 21:51:14 -0000 It was suggested by an HTTP WG member that I propose this on the TLS WG list. HTTP WG list CCed. TL;DR: Please publish an improved TLS spec for HTTP/2 before working on an ideal one. HTTP/2 has a problem: Section 9.2.2 of the current draft imposes security restrictions onto the usage of TLS that some implementors believe may be difficult to properly handle based on their various situations. There are interoperability issues that must be considered because of it. There would be new interoperability issues if it were to be removed at this late stage. The general consensus, I believe, is that 9.2.2 imposes reasonable restrictions, however these restrictions do not ideally belong in an HTTP spec but rather a TLS spec. The pre-existing system to negotiate this topic is the TLS version, however TLS 1.3 is not and will not be ready in time for a final HTTP/2 specification. Section 9.2.2 could possibly be passed with some modification, however it is not the ideal solution. I would like to propose a relatively simple solution: 1) Move the current TLS 1.3 draft and all future development to TLS 1.4 2) Write a new TLS 1.3 draft based on TLS 1.2 with no compression and requiring AEAD and FS 3) Rewrite HTTP/2 section 9.2 with a requirement of TLS 1.3 instead of TLS 1.2 with restrictions This is more appropriately a proposal for a TLS 1.2.1, however the versioning scheme is not set up to handle this. The goal of this proposal is to merely take the TLS requirements that are desired for HTTP/2 and to publish them in a separate, more appropriate specification. This would notably simplify negotiating a valid HTTP/2 connection over TLS. A streamlined TLS 1.3 spec would also be available for usage with HTTP/1.1 connections as well as any other applications. This would make setting up properly configured TLS far simpler, as mitigations for known-bad portions of the TLS 1.2 spec would no longer be needed. (e.g. compression & RC4 need not be disabled; they are not supported in TLS 1.3) The minimum key size requirements of 9.2.2 could also be added to make them far easier to enforce. This TLS 1.3 proposal contains nothing fundamentally new. It merely aims to remove old no longer acceptable portions of the spec in order to simplify the process of implementing modern standards. As such, it would maintain on-the-wire compatibility with TLS 1.2 with the sole exception of the version number. The only differences would be restrictions what can be negotiated. The process of implementing and testing this would be relatively simple, making it feasible to finalize within the timeframe needed to be mandated by HTTP/2. (with possibly only a small delay, which already seems to be a possibility) Dave From nobody Wed Nov 5 15:16:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C0F1A01AA for ; Wed, 5 Nov 2014 15:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeOiiZogJ6Ws for ; Wed, 5 Nov 2014 15:16:10 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CC01A0194 for ; Wed, 5 Nov 2014 15:16:09 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id n15so1558774lbi.4 for ; Wed, 05 Nov 2014 15:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gEvZKKkiKsgGir9i8VkuU9K4Y3BzJnAQAJnLQjxO2ls=; b=GGxvri7ta6VSERbSD9x1+kFSF4OGhyxLmlSaIwQ0upfjDaNkWATCE1QyGPjynkRAQQ HytskkgOn5ybHAa69wv+k6t1DItBQRG9REHlyBrripnCnGtVvRIBFnmvNtYlulg2hGCA 5Fe3v1556ZR9D0H6D2yNmmV5oGB/51El3J5C68Wr/es6clFuUjvifLi0cVfpqZ8Qnom0 27OIDvE2CDviLdVBW2Di+kdWDgF3MDWXy4uQlxJbRsh74tDRTPF6hC4dLsM+z89pQeVr 3R7HzzlNuJNHnGfrhOemsj404cKKJe0gAO9iGSYuEeTzQVdKxND3Uh5ikkW0mEhkmDOj 6+6w== MIME-Version: 1.0 X-Received: by 10.152.27.38 with SMTP id q6mr530938lag.92.1415229367918; Wed, 05 Nov 2014 15:16:07 -0800 (PST) Received: by 10.25.215.134 with HTTP; Wed, 5 Nov 2014 15:16:07 -0800 (PST) In-Reply-To: <201411031651.09896.davemgarrett@gmail.com> References: <201411031651.09896.davemgarrett@gmail.com> Date: Wed, 5 Nov 2014 15:16:07 -0800 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/I5MTgJ5p7fFf0CHO04nv7F8qUr4 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 23:16:11 -0000 -HTTP On 3 November 2014 13:51, Dave Garrett wrote: > 2) Write a new TLS 1.3 draft based on TLS 1.2 with no compression and requiring AEAD and FS The reason we are all getting approval to spend inordinate amounts of time and money on TLS 1.3 is that it is going to make things better, not just with respect to security (TLS 1.1 and 1.2 tried that and it didn't make a material difference to actual security), but also with respect to latency. My prediction is that not doing the latency improvements, and doing a revision with a promise to follow with another revision a short time afterwards will result in virtually no one using this intermediate revision. But that's just my prediction. From nobody Wed Nov 5 15:58:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF211A0368 for ; Wed, 5 Nov 2014 15:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw4deHJT1qiB for ; Wed, 5 Nov 2014 15:58:25 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930B81A032D for ; Wed, 5 Nov 2014 15:58:25 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id CBBF23A1D0; Thu, 6 Nov 2014 00:58:23 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 98FE14196E; Thu, 6 Nov 2014 00:58:23 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 943381AF95; Thu, 6 Nov 2014 00:58:23 +0100 (CET) In-Reply-To: To: "Yngve N. Pettersen" Date: Thu, 6 Nov 2014 00:58:23 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141105235823.943381AF95@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5EGv74C2043bdacExjI_5sovBXo Cc: tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 23:58:27 -0000 Yngve, Yngve N. Pettersen wrote: > > The way a TLS Protocol record is defined in previous versions (Using TLS > 1.2), before this update is, can a generic way be rewritten as: > > struct { > ContentType type; > ProtocolVersion version; > opaque record_data<0..maxlength> > } TLS_Record; > > This is how all clients and servers will parse current SSL and TLS > versions' records on the wire, and also how all the intermediate servers > (the ones that are causing concern for version rollback recovery) will be > parsing the TLS traffic. Thanks for your elaborate discussion. I agree with many parts of your root cause analysis why the content of rfc7366 is a failure (beyond fixing through the errata process). I wrote a similar (much less elaborate) observation to Peter a day earlier (in a private mail), that the root cause of the confusion is likely the goof of the original SSLv3 and successor specs in failing to correctly specify the outer TLS protocol PDU and properly modeling of the inner PDU variations within the correct framework. struct { ContentType type; ProtocolVersion version; opaque record_data<0..(2^14+2048)> } TLS_Record; It doesn't really matter whether the seriously misleading and backwards-incompatible protocol in rfc7366 could be hacked to produce the same "bits-on-the-wire" as what was actually intended protocol-wise, by frobbing the semantics and content of the length field of the redefined rfc7366 TLSCiphertext and frobbing the MAC computation. > > The field record_data containing a strucure of exactly the length of > record_data > > struct { > select(encryption_mode) { > case plaintext: TLS_Plaintext_data; > case stream_encrypted: TLS_Stream_Encrypted_data; > case block_encrypted: TLS_Block_Encrypted_data; > } > } TLS_Record_payload; Your picture is lacking the TLSCompressed structure, which (although not used very often these days) is still a regular part of the SSLv3 and TLSv1.[012] protocols. One of my complaints about rfc7366 was to redefine the GenericBlockCipher PDU in a backwards-incompatible fashion, and actually use *TWO DIFFERENT* PDUs, rather than a single combined one. It is extremely silly to carry through the IV-less TLSv1.0 PDU on a backwards-incompatible PDU change, because this will require _more_ code and _repeat_ a known security problem in an alleged protocol security fix. -Martin From nobody Wed Nov 5 16:09:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E973F1ACED1 for ; Wed, 5 Nov 2014 16:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.997 X-Spam-Level: X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcygl7fr3fM8 for ; Wed, 5 Nov 2014 16:09:13 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB901A03AB for ; Wed, 5 Nov 2014 16:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=Jvhq6rAMgznkGMlF+E4D8Jl6ArzsvQ8H7Sr8cobsdsE=; b=UI4X27N0LP+c5+j0S+KrQQXH0lKMUCKADs2hMjBg2HB5vCq9Afrxjbk3JFh7dJvzpd6+xfY+JkmS34iqKi4vPQsWcB68TxLlm+Ek1S8pIBllmZYKWG7se6M4CVnRQwQcn69+meDvG9BR0S/Pmm11ZziVhcTTCqntwQlWOK2LXm4=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XmAd8-0004YK-Ai; Thu, 06 Nov 2014 01:08:50 +0100 Message-ID: <545ABC17.3090406@polarssl.org> Date: Thu, 06 Nov 2014 01:08:55 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mrex@sap.com References: <20141105224437.8E2081AF95@ld9781.wdf.sap.corp> In-Reply-To: <20141105224437.8E2081AF95@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vgNpOKjoRWkTr4hfweROdQUu2tM Cc: "" Subject: Re: [TLS] RFC 7366 and resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 00:09:15 -0000 On 05/11/2014 23:44, Martin Rex wrote: > Manuel Pégourié-Gonnard wrote: >> Peter Gutmann wrote: >>> Manuel Pégourié-Gonnard writes: >>> >>>> It seems to me that RFC 7366 falls in the same category as "Most current TLS >>>> extensions" above, ie is only relevant when a session is initiated, and on >>>> resumption the server should ignore the extension and restore the state from >>>> the saved session. >>> >>> Yes, it just follows standard practice from RFC 5246, >>> so the server ignores it if present in Client Hello. >> >> Ok, thanks for the confirmation! > > Huh? I believe such behaviour to be partially WRONG (and a bad idea). > > Not returning the extension in ServerHello on resumption seems > to be current worst^Wbest practice, but resuming a session that > was originally negotiated with EtM when the resumption request > is lacking the EtM extension looks like a bad idea to me. > I'm not sure if we're talking about the same thing here. Do we agree that a session that was started using EtM will still be using EtM on resumption, regardless of whether the client sent the extension the second time (and whether the server replied with the extension)? If so, I fail to understand what is bothers you. > Btw. such behaviour means that any rfc5077-style TLS session tickets > will have to accomodate all such properties, and all servers sharing > the session tickets may have to be synchronously updated with a flag > day... > I don't think the behaviour described in RFC 5246 is supposed to apply to RFC 5077, since the former states that In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption. and RFC 5077 indeed describes explicitly how the extension is supposed to be used both for full handshake and resumed handshakes. > Btw. rfc6066 contains at least one self-inconsistency at this point: > [...] > And the definition of the Server Name Indication extension, that is > part of this RFC 6066, explicitly contradicts the first sentence of > the latter (*>) paragraph. I noticed that too. I guess it's a leftover from the previous version, since Appendix A mentions changes regarding SNI use on resumption since RFC 4366. I would assume the author forgot to change the paragraphs you quote: they should now say something like "all the extensions defined in this document except SNI". > Personally, I would consider it much more logical for the EtM spec > when it would "perform a full handshake instead" if a client proposes > to resume a session that was originally established with EtM, but > fails to include the EtM extension in the resumption request. > > This latter behaviour follows the "principle of least surprise". > Whether the server has already flushed the session from the server-side > cache that the client proposes for resumption should not affect the > properties of the resulting security context. Both RFC 5246 and 6066 say that the client SHOULD include the extensions when attempting to resume a session, since they can't know if resumption or a full handshake will follow. If you're arguing that this SHOULD should be a MUST, I think I'm sympathetic with your argument. Manuel. From nobody Wed Nov 5 16:16:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FC91A19F7 for ; Wed, 5 Nov 2014 16:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ_0EHRfrZ9U for ; Wed, 5 Nov 2014 16:16:15 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A921A0A6A for ; Wed, 5 Nov 2014 16:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=H1r19uTIpg8TJIz2CHAR8kFBxZ2Cj4XKfXE4xX10kUc=; b=LoZPr01Z6/z45sLRIIIkTmtNKJddgfy13DwCcF7Tph4GiVBEPC1OlfHYc617bDGMsj6UoVMhmmyNZ64ZirnN+bgXAkl9NdA+lZzCksKgsHNChs5bi072hKClhlIrNoKBxjUcVoArWUxZK86yvjvuZsCZ/tS0P8RwPMd1YaS/Ry0=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XmAkB-0004Z0-9W; Thu, 06 Nov 2014 01:16:07 +0100 Message-ID: <545ABDCB.2050305@polarssl.org> Date: Thu, 06 Nov 2014 01:16:11 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mrex@sap.com, "Yngve N. Pettersen" References: <20141105235823.943381AF95@ld9781.wdf.sap.corp> In-Reply-To: <20141105235823.943381AF95@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vk7CosURqtjnQ4RTkHbzNwEibQM Cc: tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 00:16:16 -0000 On 06/11/2014 00:58, Martin Rex wrote: > I agree with many parts of your root cause analysis why the content > of rfc7366 is a failure (beyond fixing through the errata process). > Really? Could you please elaborate on why you think the proposed fixes in [1] (undoubling the doubled paragraph) and [2] are not correct fixes suitable for an erratum? [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs Manuel. From nobody Wed Nov 5 16:36:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B521A1A3D for ; Wed, 5 Nov 2014 16:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peLxtbidTtmz for ; Wed, 5 Nov 2014 16:36:06 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3A81A1A33 for ; Wed, 5 Nov 2014 16:36:06 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id EA6713A219; Thu, 6 Nov 2014 01:36:04 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 987DF41A4B; Thu, 6 Nov 2014 01:36:04 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8E3081AF95; Thu, 6 Nov 2014 01:36:04 +0100 (CET) In-Reply-To: <545ABDCB.2050305@polarssl.org> To: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= Date: Thu, 6 Nov 2014 01:36:04 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20141106003604.8E3081AF95@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3xXgVjkpp5m-rqmJsQo2kw9F0bo Cc: tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 00:36:08 -0000 Manuel P=E9gouri=E9-Gonnard wrote: [ Charset windows-1252 unsupported, converting... ] > On 06/11/2014 00:58, Martin Rex wrote: > > I agree with many parts of your root cause analysis why the content > > of rfc7366 is a failure (beyond fixing through the errata process). > >=20 > Really? Could you please elaborate on why you think the proposed fixes in= [1] > (undoubling the doubled paragraph) and [2] are not correct fixes suitable= for an > erratum? >=20 > [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw > [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs I had included the rationale in the mail from which you quote above: >> >> It doesn't really matter whether the seriously misleading and >> backwards-incompatible protocol in rfc7366 could be hacked to >> produce the same "bits-on-the-wire" as what was actually intended >> protocol-wise, by frobbing the semantics and content of the >> length field of the redefined rfc7366 TLSCiphertext and frobbing >> the MAC computation. It would be like publishing 2+2 =3D 5 and then posting an errata that says ...provided that the first instance of "2" is sufficiently close to "3". I've seen a number of discussion where longterm IETF folks (including ADs) were significantly opposed to adding a clarifying sentence through errata (which indicates that a sender will have to include a certain element in a list of elements or one specific scenario will fail interop), and among the reasons for why such a one-line clarification would go beyond the purpose of the errata process were: (1) not all implementors with read erratas (or notice that an errata exis= ts) (2) this is a new requirement and changes the protocol While (1) is certainly true, I believe that it didn't apply on the specific errata. (2) certainly was a bogus claim, because it did not change any requirements at all (it's just one of several implied requirements), and the purpose of the clarification was to make it known to implementors ahead of time _why_ they will face interop failures in specific scenarios if they didn't recognize or understand this implied requirement. The problem with rfc7366 is that what the published specification describes is not what folks have (or want to implement), and an implementation of what rfc7366 truely specifies will be entirely non-interoperable with what folks want and do. And rfc7366 is even more misleading about the _real_ TLS protocol PDUs than the original SSLv3 and TLS documents. -Martin From nobody Wed Nov 5 16:52:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8191A1A4B for ; Wed, 5 Nov 2014 16:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdDffA7eWhY7 for ; Wed, 5 Nov 2014 16:52:11 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E011A1A48 for ; Wed, 5 Nov 2014 16:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=n/Inuvl926d4nmQynAoOVRFJdxN63i0Yi6fhvCPAYRA=; b=ZAifnGtNQ7/zVNglM4rSnWxmvLLXPEwoV/HKyQaOjN4X+GwioDNtxFus2dHoeLx6LGqBjqRHNGJ1nl0Kh9pP5WDVo560do7R1Rs2lUoab7rUVOWLtTEo+bBWyu2A416y6bfHIodrr9VvHVxk8jKmnBeryqJBb5iJonhzjNGEV3g=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XmBIx-0004cD-5Z; Thu, 06 Nov 2014 01:52:03 +0100 Message-ID: <545AC637.4090905@polarssl.org> Date: Thu, 06 Nov 2014 01:52:07 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mrex@sap.com References: <20141106003604.8E3081AF95@ld9781.wdf.sap.corp> In-Reply-To: <20141106003604.8E3081AF95@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PDnCS7P04eAciAlCZ5Vm6iITua0 Cc: tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 00:52:12 -0000 On 06/11/2014 01:36, Martin Rex wrote: > Manuel Pégourié-Gonnard wrote: > [ Charset windows-1252 unsupported, converting... ] >> On 06/11/2014 00:58, Martin Rex wrote: >>> I agree with many parts of your root cause analysis why the content >>> of rfc7366 is a failure (beyond fixing through the errata process). >>> >> Really? Could you please elaborate on why you think the proposed fixes in [1] >> (undoubling the doubled paragraph) and [2] are not correct fixes suitable for an >> erratum? >> >> [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw >> [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs > > I had included the rationale in the mail from which you quote above: > >>> It doesn't really matter whether the seriously misleading and >>> backwards-incompatible protocol in rfc7366 could be hacked to >>> produce the same "bits-on-the-wire" as what was actually intended >>> protocol-wise, by frobbing the semantics and content of the >>> length field of the redefined rfc7366 TLSCiphertext and frobbing >>> the MAC computation. > > It would be like publishing > > 2+2 = 5 > > and then posting an errata that says > > ...provided that the first instance of "2" is sufficiently close to "3". > In my view, the proposed errata is closer to actually replacing the first 2 with a 3 (that's [1]) and then adding a paragraph pointing out the difference (that's [2]). Just to be sure: is your point that the proposed text for the errata is not clear enough, or that you think this is "too big" for an erratum? If it's the later, as I said before, I lack experience with the IETF process to have a serious opinion on that. I just hope we soon have a solid basis to continue writing implementations and deploying them, and I leave to more knowledgeable people the question of what's the best way to achieve that goal (errata, new RFC, etc.) Manuel. From nobody Wed Nov 5 17:00:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778211A1A4B for ; Wed, 5 Nov 2014 17:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGFo2Znfz53g for ; Wed, 5 Nov 2014 16:59:59 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9841A1A47 for ; Wed, 5 Nov 2014 16:59:59 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 65E4B47617; Thu, 6 Nov 2014 00:59:58 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 038B747615; Thu, 6 Nov 2014 00:59:57 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id C52782038; Thu, 6 Nov 2014 00:59:57 +0000 (GMT) Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 5 Nov 2014 19:59:38 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 5 Nov 2014 19:59:38 -0500 From: "Salz, Rich" To: Martin Thomson , Dave Garrett Date: Wed, 5 Nov 2014 19:59:37 -0500 Thread-Topic: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 Thread-Index: Ac/5TpJKqCur/GQyQmudFE97idxm5QADjA3w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC226@USMBX1.msg.corp.akamai.com> References: <201411031651.09896.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SC5_k34tXHqgra9VycPDMh1Wbgs Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:00:02 -0000 > My prediction is that not doing the latency improvements, and doing a > revision with a promise to follow with another revision a short time > afterwards will result in virtually no one using this intermediate revisi= on. But > that's just my prediction. Agreed. At one point we considered just doing "TLS 1.2 the editorial fix-up" editio= n. Someone could still do that. Codifying existing practice, pulling in w= idely supported extensions and cipher suites, etc. But it will probably be= a lot of work for very little gain. (Compared to say the HTTP/1.1 great r= ewriting....) -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Nov 5 21:58:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C01A1A5B for ; Wed, 5 Nov 2014 21:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hbw3ov-Pmeq for ; Wed, 5 Nov 2014 21:58:28 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B591A1A59 for ; Wed, 5 Nov 2014 21:58:27 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id z6so1076553yhz.10 for ; Wed, 05 Nov 2014 21:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=08w81Anbo7dywmhfr5gU7QpHSYO8X1keXgHWPz3NHII=; b=1DnXwRv6l37RXF0kMEmKkMWn2n/FsEKipZjAjwYJO5B56H/pUyUfKcLny69/XvP553 nOIx9EO9nWmIDxKz5J3+q3JyaL4U5ymaNLffiHQAllH7foaKN1FdY4cXGRIsUtdEQBtS akjxzM9fp1cgDWN3C1GwMGlW1FxFZcsOoN9P1TkK3UTYYX9T+sY6phHjJ12S+WP7V5tN 8qrXMFNE10s0pF0ufVbkWONCui7SRUzEwrRaCAp8ERv9zvUwKF+wxRFGao1UTIbVFvsJ 8mU2s2hl8MTGyCxAb07fcMxYQswDdlICS8UNdnVgX2awyFmN+/GASVi6HghAbuM4QQnj xRHQ== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr1740799yho.172.1415253507232; Wed, 05 Nov 2014 21:58:27 -0800 (PST) Received: by 10.170.195.203 with HTTP; Wed, 5 Nov 2014 21:58:27 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Nov 2014 21:58:27 -0800 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1UhXMJtLOTDzv0cxuSkCTTb2N94 Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 05:58:29 -0000 On Nov 5, 2014 10:01 AM, "Nico Williams" wrote: > > On Wed, Nov 5, 2014 at 11:56 AM, Watson Ladd wrote: > > On Nov 5, 2014 9:51 AM, "Nico Williams" wrote: > >> Perhaps we should pin latest datetime advertised by the server for > >> which other things are being pinned. This would prevent time travel > >> into the past. Time travel into the far future is, presumably, not > >> that big a deal, even with pinning, because server operators will > >> strive to make sure that doesn't happen. > > > > Or kernels can set the flag that stops this from being possible. We should > > note the issue, and, as with randomness, let the vendors solve it. > > User-land code can "correct" kernel time. For example, most Kerberos > libraries record time offset between the client and the KDC, and > correct local time when making AP-REQs for any service subsequently. > Clients trust KDCs, so that's OK. > > But if TLS clients also attempt to correct local clocks on the basis > of time advertised by arbitrary servers... Obviously, that's the > problem: TLS clients should not use the TLS protocol to attempt to > correct local clock skew. ?? No, the issue is that an attacker can fool NTP clients, and thus change the time on a computer. All we need to do is note the need for secure clocks, and let the implementor figure out how to get the right time. If there is an issue with NTP security, and there is, that's for the NTP WG to solve. That may be an OS issue: the same is true for the generation of random numbers. We already depend on secure time for OCSP stapling and certificate validity: I don't think Hugo's proposal is worse in that regard. We need to document the dependency, but whether water clock, sundial, atomic clock, pendulum clock, or RTC on the motherboard, we don't care how that is satisfied. Martin Thompson makes this same point upthread. I think the OPTLS proposal makes it extremely easy to host servers worldwide while keeping the certificate in a nice jurisdiction, or on a slow HSM while enabling performance enhancements as computers get faster. I think it resolves many longstanding security issues, and doesn't introduce any obvious new ones. (Of course, the cross-protocol attacks may be an issue: why data signed with the same key doesn't have a type pre-appended to it in the form of a UUID or similar is beyond me) It provides most of the tricky requirements like 0-RTT and privacy of certificates. It's genericly secure. It's a performance enhancement for sites that have avoided PFS until now because of performance issues. There's plenty of details to flesh out, and it may be that we find showstoppers that make the entire approach not work. But it would be a shame if we wasted another 6 months getting to this point by patching a protocol that is extremely hard to think about: there isn't a 0-RTT proposal on the table yet beyond this one. We still need to decide some details if we move forward, and hammer out the serialization and interaction with the TLS 1.2 negotiation that ensues when a TLS 1.3 hello is sent to a TLS 1.2 server (do we share group specifications? which extensions make sense and which don't? are ciphersuites going to be shared across the Client Hello? How do signature groups relate to the DH groups?) If I could start with a clean slate, it would be with this proposal. Yes, it's a major change. It doesn't solve all our problems. Some semantics, particularly around client authentication, will likely change. However, it has the great benefit of existing, and I hope we decide to build on it or find flaws that doom it. Sincerely, Watson Ladd > > Nico > -- From nobody Wed Nov 5 22:54:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16B1A1A83 for ; Wed, 5 Nov 2014 22:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN-cAaTjq7_P for ; Wed, 5 Nov 2014 22:54:53 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993271A1A81 for ; Wed, 5 Nov 2014 22:54:52 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so508109wib.17 for ; Wed, 05 Nov 2014 22:54:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hqhzZZDffpCXYDLRBmMfr3612pQU8CfnVMEvLkoMKIU=; b=F4jTIaRj2WcaSU+IL8sEbVHrDSYF24+U2snzPg9zNZ7wfYDoM+Q2K8Wjp9zHZoUc/L 9Ow9/TR0vISgOUCJdK88SGvZX4pk6WhNKoyT7CBoCR5u+eo2mzlN3f+1RPFy5lj+dg4E Hi2XJDQbM39dXpJj2lxkUHA1Mi4hK0mMcc73rJf9Y02hVxnJGLvK6IzvTMLvFK5l8K70 rNw5O2dVdJGWYi/zPA98PnZ0EmgWW7U/9rrNm6NlH939B+1P5t5fmbaHdP90Y2eJXziC c0ycRbvS88mARf1PeQ1AE3uekf0KoQCr/Df2144WO06x+/ZJ2gAZ4wLObJXb2JYQax6U s3rA== X-Gm-Message-State: ALoCoQnFz3O9DZAkq7wZmxQTVzA0Xg4UNgBSxRTPsoB5E5uU62LDg55MCug+Bj1+WKYtgh0hC0hK X-Received: by 10.194.89.161 with SMTP id bp1mr2843785wjb.114.1415256891382; Wed, 05 Nov 2014 22:54:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Wed, 5 Nov 2014 22:54:11 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 5 Nov 2014 22:54:11 -0800 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=089e010d8aa246e7b805072b2ca1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-p4sbPtg61K_f3f_a-w_g5E-WPM Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 06:54:55 -0000 --089e010d8aa246e7b805072b2ca1 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 5, 2014 at 8:27 AM, Hugo Krawczyk wrote: > The issue of validity period of the static key g^s is not different than > that of a regular certificate except that the server can choose a shorter > validity period for g^s than the one for the certificate. That is, if the > client's clock is skewed by Delta and the validity of g^s is up to time T, > the client will accept g^s till time T+Delta. Similarly, if the certificate > expires at time T', the client will accept it until T'+Delta. In either > case, if T the certificate. > > (Needless to say, a client should not accept a signed g^s past the > expiration date of the certificate signing g^s). > > Am I misunderstanding/missing something? > I'm not sure. The point I was trying to make below is that there are settings in which the signing key is stored in an HSM but the DH share cannot. In those cases, there is an additional risk of compromise of the machine holding the DH share, which can steal the share but cannot steal the signing key (because of the HSM). I agree that this is partially ameliorated by having g^s be only valid up to the expiry of the certificate, but since certificate lifetimes are generally long, only partially so, especially since if the signing key is online (as will be required for TLS 1.2 compat) compromise of the machine will let you sign a DH share with a very long lifetime. is that clearer? -Ekr > > Hugo > > > > On Tue, Nov 4, 2014 at 4:12 PM, Eric Rescorla wrote: > >> >> >> On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd >> wrote: >> >>> On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla wrote: >>> > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk > >>> The second option may be trivial, if the client already has some >>> > generic key storage mechanism (e.g., one in software) though it's of >>> > course more work for the programmer. However, if the client has a >>> > non-generic key storage mechanism, such as a smart card with their >>> > key, then this becomes a significant problem, as it may not be able to >>> > store a DH key and/or use it for the kind of key derivation that >>> > would be required here. In that case, the client must find somewhere >>> > to store the DH key, which may entail significant effort. >>> > >>> > >>> > This last point points us to a larger issue we need to consider here, >>> > which is as follows. In TLS as it currently stands (both in 1.2 and >>> > the current TLS 1.3 draft), you can implement a system where the >>> > authentication keys are stored in hardware and an attacker who >>> > compromises either the client and the server cannot steal a credential >>> > which he can then use to establish new sessions [Note that if >>> > he steals the session cache, he can use it to resume old sessions.] >>> > In particular, because each signature is tied to a specific exchange, >>> > the attacker cannot reuse signed ephemeral values to impersonate the >>> > server. >>> >>> 1: If ephemerals are reused, you can MITM until they are refreshed. A >>> time-bounded cert equivalent isn't worse in this regard. >>> >> >> I'm not following your reasoning here. For convenience, let's >> restrict ourselves to thinking about 1-RTT handshakes. With >> TLS 1.2 (or the current TLS 1.3 draft), the server can stop future clients >> from accepting any DH share simply by refusing to sign any >> further handshakes with that share. If, for instance, it determines >> a share has been compromised, it can prevent any new connection >> initiations with that share. By contrast, with a time-bounded >> cert, an attacker can get clients to continue using that share until >> the time expires (or perhaps longer, as you suggested elsewhere). >> >> The situation is of course somewhat more complicated with 0-RTT >> because the server must provide the client with a DH share which >> he can use for future connections. However, he need not provide >> every client with the *same* key, and if the key is authenticated >> as part of the initial connection establishment, an attacker cannot >> convince other clients to use that key. This is not true with certificates >> (or of statically signed keys) which are inherently portable. >> >> >> >> 3: 0-RTT requires a certificate that can be used for encryption as >>> well as signing, in ways that don't interfere. We need to use a DH >>> share anyway for this, and might as well use it again. >> >> >> I'm not sure I follow what you're saying here either. It's true that the >> server needs to supply a semi-static DH share, but there's no inherent >> reason it needs to be supplied as part of a free-standing transferrable >> credential such as a certificate, though of course doing so allows you >> to amortize the signature. >> >> >> > However, in a system where the server signs a long-term DH value, it >>> > may be the case that that value cannot be stored in the same hardware >>> > module that you are using for your signature key (purely for >>> > implementation reasons having to do with the interface the module >>> > exposes). In that case, the DH secret will be stored in software and >>> > compromise of the server potentially leaks a credential which can be >>> > used to impersonate the server for a significant period of time, where >>> > that time is dictated by the maximum amount of client-side clock error >>> > the server is willing to tolerate, so probably measured in days to >>> > weeks (and more if you are concerned about the time resetting attack >>> > Watson, Ilari, and I were discussing.) I haven't decided yet sure how >>> > serious an issue this is, but it's probably worth addressing >>> > explicitly. >>> >>> I'm not sure, because it wasn't explicitly addressed in Hugo's >>> original email, but it seems that the relevant server question is how >>> long it wants to receive 0-RTT without requiring the client to find >>> the new address: I don't remember resumption being addressed one way >>> or the other. So the server isn't picking the DH share lifetime for >>> reasons of clock skew, but rather for PFS refreshment if 0-RTT is >>> being used. >> >> >> I think we may be talking past each other. Let me try again. >> >> Forget about 0-RTT and just consider the 1-RTT flow. In the first flight >> the server needs to supply a signed version of g^s. Unless we want >> that value to be acceptable to clients indefinitely, it must have some >> validity interval. However, because clients have inaccurate clocks, >> that interval can't be too narrow or it will cause clients to reject the >> g^s value. I'm not sure how narrow it can be, but I would be surprised >> if it were less than 12 hours or so. Perhaps someone who runs a >> large server farm can report on the values they have historically >> seen in the GMT field of the ClientRandom. >> >> -Ekr >> >> >> >> >> >> > --089e010d8aa246e7b805072b2ca1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 5, 2014 at 8:27 AM, Hugo Krawczyk <hugo@ee.technion.a= c.il> wrote:
The issue = of validity period of the static key g^s is not different than that of a re= gular certificate except that the server can choose a shorter validity peri= od for g^s than the one for the certificate. That is, if the client's c= lock is skewed by Delta and the validity of g^s is up to time T, the client= will accept g^s till time T+Delta. Similarly, if the certificate expires a= t time T', the client will accept it until T'+Delta. In either case= , if T<T' the client will accept g^s for less time than it would acc= ept the certificate.

(Needless to say, a client should not accept a signed = g^s past the expiration date of the certificate signing g^s).

=
Am I misunder= standing/missing something?

I&#= 39;m not sure.

The point I was trying to make belo= w is that there are settings in which the
signing key is stored i= n an HSM but the DH share cannot. In those cases,
there is an add= itional risk of compromise of the machine holding the DH
share, w= hich can steal the share but cannot steal the signing key
(becaus= e of the HSM). I agree that this is partially ameliorated by
havi= ng g^s be only valid up to the expiry of the certificate, but since
certificate lifetimes are generally long, only partially so, especially = since
if the signing key is online (as will be required for TLS 1= .2 compat)
compromise of the machine will let you sign a DH share= with a very
long lifetime.

is that clea= rer?

-Ekr
=C2=A0

Hugo



On Tue, Nov 4, 2014 at 4:12 PM, Eric Rescorla <ekr@rtfm= .com> wrote:


On M= on, Nov 3, 2014 at 7:02 PM, Watson Ladd <watsonbladd@gmail.com>= wrote:
On = Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla <ekr@rtfm.com> wrote:
 > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>> = The second option may be trivial, if the client already has some
<= /div> > generic key storage mechanism (e.g., one in software) though it's = of
> course more work for the programmer. However, if the client has a
> non-generic key storage mechanism, such as a smart card with their
> key, then this becomes a significant problem, as it may not be able to=
> store a DH key and/or use it for the kind of key derivation that
> would be required here. In that case, the client must find somewhere > to store the DH key, which may entail significant effort.
>
>
> This last point points us to a larger issue we need to consider here,<= br> > which is as follows. In TLS as it currently stands (both in 1.2 and > the current TLS 1.3 draft), you can implement a system where the
> authentication keys are stored in hardware and an attacker who
> compromises either the client and the server cannot steal a credential=
> which he can then use to establish new sessions [Note that if
> he steals the session cache, he can use it to resume old sessions.] > In particular, because each signature is tied to a specific exchange,<= br> > the attacker cannot reuse signed ephemeral values to impersonate the > server.

1: If ephemerals are reused, you can MITM until they are refreshed. = A
time-bounded cert equivalent isn't worse in this regard.

I'm not following your reasoning here. For= convenience, let's
restrict ourselves to thinking about 1-RT= T handshakes. With
TLS 1.2 (or the current TLS 1.3 draft), the se= rver can stop future clients
from accepting any DH share simply b= y refusing to sign any
further handshakes with that share. If, fo= r instance, it determines
a share has been compromised, it can pr= event any new connection
initiations with that share. By contrast= , with a time-bounded
cert, an attacker can get clients to contin= ue using that share until
the time expires (or perhaps longer, as= you suggested elsewhere).

The situation is of cou= rse somewhat more complicated with 0-RTT
because the server must = provide the client with a DH share which
he can use for future co= nnections. However, he need not provide
every client with the *sa= me* key, and if the key is authenticated
as part of the initial c= onnection establishment, an attacker cannot
convince other client= s to use that key. This is not true with certificates
(or of stat= ically signed keys) which are inherently portable.



3: 0-RTT req= uires a certificate that can be used for encryption as
well as signing, in ways that don't interfere. We need to use a DH
share anyway for this, and might as well use it again.
I'm not sure I follow what you're saying here ei= ther. It's true that the
server needs to supply a semi-static= DH share, but there's no inherent
reason it needs to be supp= lied as part of a free-standing transferrable
credential such as = a certificate, though of course doing so allows you
to amortize t= he signature.


> However, in a system where the server signs a long-term DH value, it > may be the case that that value cannot be stored in the same hardware<= br> > module that you are using for your signature key (purely for
> implementation reasons having to do with the interface the module
> exposes). In that case, the DH secret will be stored in software and > compromise of the server potentially leaks a credential which can be > used to impersonate the server for a significant period of time, where=
> that time is dictated by the maximum amount of client-side clock error=
> the server is willing to tolerate, so probably measured in days to
> weeks (and more if you are concerned about the time resetting attack > Watson, Ilari, and I were discussing.) I haven't decided yet sure = how
> serious an issue this is, but it's probably worth addressing
> explicitly.

I'm not sure, because it wasn't explicitly addressed in Hugo= 's
original email, but it seems that the relevant server question is how
long it wants to receive 0-RTT without requiring the client to find
the new address: I don't remember resumption being addressed one way or the other. So the server isn't picking the DH share lifetime for
reasons of clock skew, but rather for PFS refreshment if 0-RTT is
being used.

I think we may be talkin= g past each other. Let me try again.

Forget about = 0-RTT and just consider the 1-RTT flow. In the first flight
the s= erver needs to supply a signed version of g^s. Unless we want
tha= t value to be acceptable to clients indefinitely, it must have some
validity interval. However, because clients have inaccurate clocks,
that interval can't be too narrow or it will cause clients to rej= ect the
g^s value. I'm not sure how narrow it can be, but I w= ould be surprised
if it were less than 12 hours or so. Perhaps so= meone who runs a
large server farm can report on the values they = have historically
seen in the GMT field of the ClientRandom.

-Ekr



=C2=A0



--089e010d8aa246e7b805072b2ca1-- From nobody Wed Nov 5 23:28:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D63B1A0117 for ; Wed, 5 Nov 2014 23:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Nj9zySMoVpo for ; Wed, 5 Nov 2014 23:28:33 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1691A00E6 for ; Wed, 5 Nov 2014 23:28:32 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so584445wiw.9 for ; Wed, 05 Nov 2014 23:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SgeKVJeVZ3fjg6LoBGe5x5aM3bI9cDqVmkFWPJZabLk=; b=wD7L6plydqV4RLkPq8SUnF41PK7raMmpNQ7umdKNSjjX4/8HDcl7ufgkHeJhnCpM8j vJhpWjxgVDOHOhgK+yPvUIc0IKxOWmVl7aqv+R6hH6PoEJ3Y3WZRTFa4g8STytLZTgdB 4L/GM/qruNgH3bu5knfW2US9DnABIkXZ24B/YSRf7iwuL/llrHBI5lssa+xYOZ9cNznZ gfGQPHJytBaa5ZVE7RlDBSQHlBjJ79CYvKSxBN4L1/SSPJ23Q/qR+lTuychi1iNBIhLB mE0enXtwVhs0Hpfr8gHR2/mUG8rH4CfjnL8Yi3j/ro+/HUTgWWwRvhy+flhFV9rEqxPD IXNw== X-Received: by 10.180.73.244 with SMTP id o20mr39140369wiv.12.1415258464913; Wed, 05 Nov 2014 23:21:04 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.12.148.243]) by mx.google.com with ESMTPSA id td9sm7173574wic.15.2014.11.05.23.21.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 23:21:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <201411031651.09896.davemgarrett@gmail.com> Date: Thu, 6 Nov 2014 09:21:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411031651.09896.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V4x3ry5hrjEuNsavBJ-_jmpJ-iQ Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 07:28:36 -0000 Hi, Dave I believe that ultimately this does not solve the issue raised about = 9.2.2 on the httpbis list. The issue there was that a client would propose AES-CBC and AES-GCM = (forgive me for shortening the grouping suites) with =E2=80=9Ch1=E2=80=9D = and =E2=80=9Ch2=E2=80=9D, and then it=E2=80=99s up to the server to know = that the AES-CBC and =E2=80=9Ch2=E2=80=9D combination is prohibited by = the HTTP/2 spec. This could be done either by the HTTP layer checking on = the TLS layer, or by adding callbacks and APIs for the HTTP layer to = make the choice of ciphersuite for the TLS layer, or by incorporating = some HTTP/2 specifications into the TLS layer. People claimed that this = was either ugly or hard to implement. The issue does not go away with your proposal. The reason servers = support =E2=80=9Ch1=E2=80=9D at all is to support legacy clients, and = the reason clients propose =E2=80=9Ch1=E2=80=9D and non-AEAD = ciphersuites at all is to support legacy servers. What your proposal = does is move the pain point from ciphersuite selection to version = selection. A client would still propose TLS 1.0, TLS 1.1, TLS 1.2, and = if it=E2=80=99s updated, TLS 1.3. A server would still have to know that = the =E2=80=9Ch2=E2=80=9D and TLS 1.2 combination is invalid, and the = complexity remains. It=E2=80=99s true that the current requirement in HTTP/2 has this issue = anyway, as it prohibits TLS versions under TLS 1.2, but I=E2=80=99m in = the =E2=80=9Crip out 9.2.2 and live with whatever the TLS layer = negotiates=E2=80=9D camp. Yoav From nobody Thu Nov 6 00:03:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9283C1A06FD for ; Thu, 6 Nov 2014 00:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVi159DI-zfL for ; Thu, 6 Nov 2014 00:02:58 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E4F1A1A12 for ; Thu, 6 Nov 2014 00:02:58 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so494209lbj.23 for ; Thu, 06 Nov 2014 00:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehL5n/WnNq0F70ixH5HGOZ2Q5gAQNut8vWQ6wz2G5sM=; b=AsCES/nRbn5ltbkNLdXlumLaLD+fc7T7+nJP2rjscqPjdo2/PHksE22scenvghaGz0 KwnXd30pu1uugF6Ms48fmUH0OvmCKi57mjxEros+jy+YRQQIwct3RYhyl9bwfF/a1Af3 i9+VygheDDYRj6U1l0+DtgCHwj5S2jfKw2zNarEhTJVa+k11qiFzoXXg+S8zjEWgqi3p hPvV9Uv5jpC9BFkkS79EqF5lgKuLnST/oiZh1I9CneT1GJvut6fDtz3Qs6GLwVvuGCoq XyrNRBO/PUPkar2WEnhtkagE600Xq+4b6qx/HdOHct1slZPG6uX3tHmscBxUtfe2IIHy X1RA== X-Received: by 10.152.27.133 with SMTP id t5mr2063013lag.88.1415260976641; Thu, 06 Nov 2014 00:02:56 -0800 (PST) Received: from [172.24.250.114] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id d9sm2235937lbp.49.2014.11.06.00.02.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 00:02:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <201411060250.11408.davemgarrett@gmail.com> Date: Thu, 6 Nov 2014 10:02:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <15DBB425-CFD4-492C-BACA-EA4071F84333@gmail.com> References: <201411031651.09896.davemgarrett@gmail.com> <201411060250.11408.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uquPnnEB240XKjHf-eml9xMaG_0 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 08:03:02 -0000 Having this intermediate version also makes supporting HTTP/2 more = difficult The most common platform for an HTTPS server is Apache + modssl. Getting = HTTP/2 support into Apache involves installing modhttp2. No way of = getting around that necessity. But your proposal would require a new = version of OpenSSL to be installed. That makes the administrator depend = on the release schedule of OpenSSL. That=E2=80=99s a problem. Yoav > On Nov 6, 2014, at 9:50 AM, Dave Garrett = wrote: >=20 > For clients wanting to attempt a fallback, yes, this might not be a = perfect solution. It is,=20 > however, far better than the current state. Ciphers would not have to = be assessed and implementation=20 > of the restrictions would be far more simple and clear. Moving the = painpoint, as you say, would be a=20 > notable improvement. One simple check vs. a handful of possibly = complex checks. >=20 > At this point, Greg Wilkins' proposal looks to be the best available = option getting any discussion: >=20 > http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0481.html >=20 > An HTTP/2 handshake would not be able to include any legacy ciphers, = and if this fails then the=20 > client could then fallback and retry with HTTP/1.1 instead. It gets a = more robust handshake in=20 > exchange for a slightly slower fallback if the server does not support = any modern ciphers. I should=20 > note that this is already something Mozilla is implementing with = respect to RC4. The plan is to do=20 > the initial handshake without RC4 and only offer it as a possibility = if the more ideal cipher set is=20 > rejected. (fallback order becomes: 1.2-RC4, 1.2+RC4, 1.1+RC4, 1.0+RC4) >=20 >=20 > Dave >=20 >=20 > On Thursday, November 06, 2014 02:21:02 am Yoav Nir wrote: >> Hi, Dave >>=20 >> I believe that ultimately this does not solve the issue raised about = 9.2.2 >> on the httpbis list. >>=20 >> The issue there was that a client would propose AES-CBC and AES-GCM >> (forgive me for shortening the grouping suites) with =E2=80=9Ch1=E2=80=9D= and =E2=80=9Ch2=E2=80=9D, and >> then it=E2=80=99s up to the server to know that the AES-CBC and = =E2=80=9Ch2=E2=80=9D combination >> is prohibited by the HTTP/2 spec. This could be done either by the = HTTP >> layer checking on the TLS layer, or by adding callbacks and APIs for = the >> HTTP layer to make the choice of ciphersuite for the TLS layer, or by >> incorporating some HTTP/2 specifications into the TLS layer. People >> claimed that this was either ugly or hard to implement. >>=20 >> The issue does not go away with your proposal. The reason servers = support >> =E2=80=9Ch1=E2=80=9D at all is to support legacy clients, and the = reason clients propose >> =E2=80=9Ch1=E2=80=9D and non-AEAD ciphersuites at all is to support = legacy servers. What >> your proposal does is move the pain point from ciphersuite selection = to >> version selection. A client would still propose TLS 1.0, TLS 1.1, TLS = 1.2, >> and if it=E2=80=99s updated, TLS 1.3. A server would still have to = know that the >> =E2=80=9Ch2=E2=80=9D and TLS 1.2 combination is invalid, and the = complexity remains. >>=20 >> It=E2=80=99s true that the current requirement in HTTP/2 has this = issue anyway, as >> it prohibits TLS versions under TLS 1.2, but I=E2=80=99m in the = =E2=80=9Crip out 9.2.2 and >> live with whatever the TLS layer negotiates=E2=80=9D camp. >>=20 >> Yoav From nobody Thu Nov 6 01:04:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1661A1AA8 for ; Thu, 6 Nov 2014 01:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHeIEOSZ0__Y for ; Thu, 6 Nov 2014 01:04:07 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CE61A1AA6 for ; Thu, 6 Nov 2014 01:04:07 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA6946i2004009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 6 Nov 2014 04:04:06 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA6943xO004611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2014 04:04:04 -0500 Message-ID: <1415264642.32520.9.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: mrex@sap.com Date: Thu, 06 Nov 2014 10:04:02 +0100 In-Reply-To: <20141106003604.8E3081AF95@ld9781.wdf.sap.corp> References: <20141106003604.8E3081AF95@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ngtRd5egXep-vVCjb-BzDN0W4W4 Cc: tls@ietf.org Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:04:10 -0000 On Thu, 2014-11-06 at 01:36 +0100, Martin Rex wrote: > > Really? Could you please elaborate on why you think the proposed fixes in [1] > > (undoubling the doubled paragraph) and [2] are not correct fixes suitable for an > > erratum? > > [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw > > [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs > I had included the rationale in the mail from which you quote above: > >> > >> It doesn't really matter whether the seriously misleading and > >> backwards-incompatible protocol in rfc7366 could be hacked to > >> produce the same "bits-on-the-wire" as what was actually intended > >> protocol-wise, by frobbing the semantics and content of the > >> length field of the redefined rfc7366 TLSCiphertext and frobbing > >> the MAC computation. > It would be like publishing > 2+2 = 5 > and then posting an errata that says > ...provided that the first instance of "2" is sufficiently close to "3". No point in arguing about that. No text is perfect. Given that this document is the only way to fix the issues with the cbc ciphersuites for tls >= 1.1, it must be corrected one way or another. That is because it is the only way to provide reasonable security for implementations which do TLS 1.1 and don't have any other choice (such as the GCM ciphersuites). If you think additional text is required please propose it. regards, Nikos From nobody Thu Nov 6 01:35:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D431A1AB0 for ; Thu, 6 Nov 2014 01:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtvJPm46KJCm for ; Thu, 6 Nov 2014 01:35:06 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A161A1AAB for ; Thu, 6 Nov 2014 01:35:05 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id hz20so2216937lab.23 for ; Thu, 06 Nov 2014 01:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xTQewjHVwk+znV5ymGLOeVYkAOZ0apyFTjRWWkOnZ+8=; b=ntJ28szDbofRT/VhKCWm/rc+ttOgZYn0l6+F5bLtazVSt0jrht5SdsKdubh8PTRAkF YuiTm17dETz58NkuM/S3xCyQwvxBR077CKk8fs4lwF7X1SngdUaFS/LmngDpnRHJjRyu 4h9gqqpKESz4gggduow45CnGUYDJh8BRE0koq8Ve/KwRv+KDuVU3Du9Au9qF7hblaK7V 0nTjhIQ7wc1noQAt6/UMN/rAxYYLZkFdnSQc6/RRi5MiDUzWDjxhPqGKWITbruhpzKVS cZVVfCDq+hkEx+jEJxBzQcv52hWlIsJzooPzLUEUJTDYk46i0UngU9XwKNbQUO7n2wxV wS3g== X-Received: by 10.112.247.43 with SMTP id yb11mr3694851lbc.51.1415266504219; Thu, 06 Nov 2014 01:35:04 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Thu, 6 Nov 2014 01:34:34 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Thu, 6 Nov 2014 11:34:34 +0200 X-Google-Sender-Auth: gOD05YBX1JlDFKgShQMR6_TqfL8 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1134de923f505c05072d69f6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6Ly1gMluDoJm330dWFM4nuZ5ro0 Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:35:10 -0000 --001a1134de923f505c05072d69f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that when a signature key is better protected than the static DH key, requiring a fresh signature in each session is better. I assume that there is no fundamental reason not to have the static DH key in the HSM other than the fact that this capability is not supported in current HSMs. We are in a transition period and there are some costs associated to it, but we should not tie ourselves to the past for this reason. This is a forward-looking proposal. Besides, it also has advantages regarding the security of long-term signature keys which need not be online for signing each exchange. Regarding the problems with insecure time, it seems that we are reaching agreement that this should not be a distraction for judging this proposal (in particular since it does not make things worse than the reliance of time synchronization for accepting certificates - and it can actually make things better by having shorter validity periods for the static DH key than for the long-term certificate). =E2=80=8B=E2=80=8B BTW, I have not mentioned one advantage of removing online signatures from =E2=80=8B the protocol: It provides plausible deniability of an exchange. I= n contrast, with per-exchange signatures that sign all the handshake messages, you also sign your peer's identity, hence leaving a proof that you communicated with that peer. The deniability property of OPTLS can be claimed similarly to that of SKEME as in http://eprint.iacr.org/2006/280. This is an additional privacy-protecting aspect of the protocol in addition to identity encryption and forward secrecy. Hugo=E2=80=8B On Thu, Nov 6, 2014 at 8:54 AM, Eric Rescorla wrote: > > > On Wed, Nov 5, 2014 at 8:27 AM, Hugo Krawczyk > wrote: > >> The issue of validity period of the static key g^s is not different than >> that of a regular certificate except that the server can choose a shorte= r >> validity period for g^s than the one for the certificate. That is, if th= e >> client's clock is skewed by Delta and the validity of g^s is up to time = T, >> the client will accept g^s till time T+Delta. Similarly, if the certific= ate >> expires at time T', the client will accept it until T'+Delta. In either >> case, if T> the certificate. >> >> (Needless to say, a client should not accept a signed g^s past the >> expiration date of the certificate signing g^s). >> >> Am I misunderstanding/missing something? >> > > I'm not sure. > > The point I was trying to make below is that there are settings in which > the > signing key is stored in an HSM but the DH share cannot. In those cases, > there is an additional risk of compromise of the machine holding the DH > share, which can steal the share but cannot steal the signing key > (because of the HSM). I agree that this is partially ameliorated by > having g^s be only valid up to the expiry of the certificate, but since > certificate lifetimes are generally long, only partially so, especially > since > if the signing key is online (as will be required for TLS 1.2 compat) > compromise of the machine will let you sign a DH share with a very > long lifetime. > > is that clearer? > > -Ekr > > >> >> Hugo >> >> >> >> On Tue, Nov 4, 2014 at 4:12 PM, Eric Rescorla wrote: >> >>> >>> >>> On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd >>> wrote: >>> >>>> On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla wrote: >>>> > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk > >>>> The second option may be trivial, if the client already has some >>>> > generic key storage mechanism (e.g., one in software) though it's of >>>> > course more work for the programmer. However, if the client has a >>>> > non-generic key storage mechanism, such as a smart card with their >>>> > key, then this becomes a significant problem, as it may not be able = to >>>> > store a DH key and/or use it for the kind of key derivation that >>>> > would be required here. In that case, the client must find somewhere >>>> > to store the DH key, which may entail significant effort. >>>> > >>>> > >>>> > This last point points us to a larger issue we need to consider here= , >>>> > which is as follows. In TLS as it currently stands (both in 1.2 and >>>> > the current TLS 1.3 draft), you can implement a system where the >>>> > authentication keys are stored in hardware and an attacker who >>>> > compromises either the client and the server cannot steal a credenti= al >>>> > which he can then use to establish new sessions [Note that if >>>> > he steals the session cache, he can use it to resume old sessions.] >>>> > In particular, because each signature is tied to a specific exchange= , >>>> > the attacker cannot reuse signed ephemeral values to impersonate the >>>> > server. >>>> >>>> 1: If ephemerals are reused, you can MITM until they are refreshed. A >>>> time-bounded cert equivalent isn't worse in this regard. >>>> >>> >>> I'm not following your reasoning here. For convenience, let's >>> restrict ourselves to thinking about 1-RTT handshakes. With >>> TLS 1.2 (or the current TLS 1.3 draft), the server can stop future >>> clients >>> from accepting any DH share simply by refusing to sign any >>> further handshakes with that share. If, for instance, it determines >>> a share has been compromised, it can prevent any new connection >>> initiations with that share. By contrast, with a time-bounded >>> cert, an attacker can get clients to continue using that share until >>> the time expires (or perhaps longer, as you suggested elsewhere). >>> >>> The situation is of course somewhat more complicated with 0-RTT >>> because the server must provide the client with a DH share which >>> he can use for future connections. However, he need not provide >>> every client with the *same* key, and if the key is authenticated >>> as part of the initial connection establishment, an attacker cannot >>> convince other clients to use that key. This is not true with >>> certificates >>> (or of statically signed keys) which are inherently portable. >>> >>> >>> >>> 3: 0-RTT requires a certificate that can be used for encryption as >>>> well as signing, in ways that don't interfere. We need to use a DH >>>> share anyway for this, and might as well use it again. >>> >>> >>> I'm not sure I follow what you're saying here either. It's true that th= e >>> server needs to supply a semi-static DH share, but there's no inherent >>> reason it needs to be supplied as part of a free-standing transferrable >>> credential such as a certificate, though of course doing so allows you >>> to amortize the signature. >>> >>> >>> > However, in a system where the server signs a long-term DH value, it >>>> > may be the case that that value cannot be stored in the same hardwar= e >>>> > module that you are using for your signature key (purely for >>>> > implementation reasons having to do with the interface the module >>>> > exposes). In that case, the DH secret will be stored in software and >>>> > compromise of the server potentially leaks a credential which can be >>>> > used to impersonate the server for a significant period of time, whe= re >>>> > that time is dictated by the maximum amount of client-side clock err= or >>>> > the server is willing to tolerate, so probably measured in days to >>>> > weeks (and more if you are concerned about the time resetting attack >>>> > Watson, Ilari, and I were discussing.) I haven't decided yet sure ho= w >>>> > serious an issue this is, but it's probably worth addressing >>>> > explicitly. >>>> >>>> I'm not sure, because it wasn't explicitly addressed in Hugo's >>>> original email, but it seems that the relevant server question is how >>>> long it wants to receive 0-RTT without requiring the client to find >>>> the new address: I don't remember resumption being addressed one way >>>> or the other. So the server isn't picking the DH share lifetime for >>>> reasons of clock skew, but rather for PFS refreshment if 0-RTT is >>>> being used. >>> >>> >>> I think we may be talking past each other. Let me try again. >>> >>> Forget about 0-RTT and just consider the 1-RTT flow. In the first fligh= t >>> the server needs to supply a signed version of g^s. Unless we want >>> that value to be acceptable to clients indefinitely, it must have some >>> validity interval. However, because clients have inaccurate clocks, >>> that interval can't be too narrow or it will cause clients to reject th= e >>> g^s value. I'm not sure how narrow it can be, but I would be surprised >>> if it were less than 12 hours or so. Perhaps someone who runs a >>> large server farm can report on the values they have historically >>> seen in the GMT field of the ClientRandom. >>> >>> -Ekr >>> >>> >>> >>> >>> >>> >> > --001a1134de923f505c05072d69f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that when a signature key is better pro= tected than the static DH key, requiring a fresh signature in each session = is better. I assume that there is no fundamental reason not to have the sta= tic DH key in the HSM other than the fact that this capability is not suppo= rted in current HSMs. We are in a transition period and there are some cost= s associated to it, but we should not tie ourselves to the past for this re= ason. This is a forward-looking proposal. Besides, it also has advantages r= egarding the security of long-term signature keys which need not be online = for signing each exchange.

Regardi= ng the problems with insecure time, it seems that we are reaching agreement= that this should not be a distraction for judging this proposal (in partic= ular since it does not make things worse than the reliance of time synchron= ization for accepting certificates - and it can actually make things better= by having shorter validity periods for the static DH key than for the long= -term certificate).

=E2=80=8B=E2=80=8B
BTW, I have not mentioned one advantage = of removing online signatures from
=E2=80=8B the p= rotocol: It provides plausible deniability of an exchange. In contrast, wit= h per-exchange signatures that sign all the handshake messages, you also si= gn your peer's identity, hence leaving a proof that you communicated wi= th that peer. The deniability property of OPTLS can be claimed similarly to= that of SKEME as in
http://= eprint.iacr.org/2006/280.
This is = an additional privacy-protecting aspect of the protocol in addition to iden= tity encryption and forward secrecy.
Hugo=E2=80=8B


On Thu, Nov 6, 2014 at 8:54 AM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Wed, Nov 5, 2014 at 8:27 AM, Hugo Krawczyk <hugo@ee.= technion.ac.il> wrote:
The issue of validity period of the static key g^s is no= t different than that of a regular certificate except that the server can c= hoose a shorter validity period for g^s than the one for the certificate. T= hat is, if the client's clock is skewed by Delta and the validity of g^= s is up to time T, the client will accept g^s till time T+Delta. Similarly,= if the certificate expires at time T', the client will accept it until= T'+Delta. In either case, if T<T' the client will accept g^s fo= r less time than it would accept the certificate.

(Needless to say, a cli= ent should not accept a signed g^s past the expiration date of the certific= ate signing g^s).

Am I misunderstanding/missing something?

I'm not sure.

The point I was trying to make below is that there are settings in which= the
signing key is stored in an HSM but the DH share cannot. In = those cases,
there is an additional risk of compromise of the mac= hine holding the DH
share, which can steal the share but cannot s= teal the signing key
(because of the HSM). I agree that this is p= artially ameliorated by
having g^s be only valid up to the expiry= of the certificate, but since
certificate lifetimes are generall= y long, only partially so, especially since
if the signing key is= online (as will be required for TLS 1.2 compat)
compromise of th= e machine will let you sign a DH share with a very
long lifetime.=

is that clearer?

-Ekr
=C2=A0

Hugo



On Tue, Nov 4, 2014 at 4:12 PM, Eric= Rescorla <ekr@rtfm.com> wrote:


On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd <= span dir=3D"ltr"><watsonbladd@gmail.com> wrote:
On Sun, Nov 2, 2014 at 2:= 33 PM, Eric Rescorla <= ekr@rtfm.com> wrote:
 > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>> = The second option may be trivial, if the client already has some
<= /div> > generic key storage mechanism (e.g., one in software) though it's = of
> course more work for the programmer. However, if the client has a
> non-generic key storage mechanism, such as a smart card with their
> key, then this becomes a significant problem, as it may not be able to=
> store a DH key and/or use it for the kind of key derivation that
> would be required here. In that case, the client must find somewhere > to store the DH key, which may entail significant effort.
>
>
> This last point points us to a larger issue we need to consider here,<= br> > which is as follows. In TLS as it currently stands (both in 1.2 and > the current TLS 1.3 draft), you can implement a system where the
> authentication keys are stored in hardware and an attacker who
> compromises either the client and the server cannot steal a credential=
> which he can then use to establish new sessions [Note that if
> he steals the session cache, he can use it to resume old sessions.] > In particular, because each signature is tied to a specific exchange,<= br> > the attacker cannot reuse signed ephemeral values to impersonate the > server.

1: If ephemerals are reused, you can MITM until they are refreshed. = A
time-bounded cert equivalent isn't worse in this regard.

I'm not following your reasoning here. For= convenience, let's
restrict ourselves to thinking about 1-RT= T handshakes. With
TLS 1.2 (or the current TLS 1.3 draft), the se= rver can stop future clients
from accepting any DH share simply b= y refusing to sign any
further handshakes with that share. If, fo= r instance, it determines
a share has been compromised, it can pr= event any new connection
initiations with that share. By contrast= , with a time-bounded
cert, an attacker can get clients to contin= ue using that share until
the time expires (or perhaps longer, as= you suggested elsewhere).

The situation is of cou= rse somewhat more complicated with 0-RTT
because the server must = provide the client with a DH share which
he can use for future co= nnections. However, he need not provide
every client with the *sa= me* key, and if the key is authenticated
as part of the initial c= onnection establishment, an attacker cannot
convince other client= s to use that key. This is not true with certificates
(or of stat= ically signed keys) which are inherently portable.



3: 0-RTT requires a certificate that can be used for encryption as well as signing, in ways that don't interfere. We need to use a DH
share anyway for this, and might as well use it again.
I'm not sure I follow what you're saying here ei= ther. It's true that the
server needs to supply a semi-static= DH share, but there's no inherent
reason it needs to be supp= lied as part of a free-standing transferrable
credential such as = a certificate, though of course doing so allows you
to amortize t= he signature.


> However, in a system where the server signs a long-term DH value, it > may be the case that that value cannot be stored in the same hardware<= br> > module that you are using for your signature key (purely for
> implementation reasons having to do with the interface the module
> exposes). In that case, the DH secret will be stored in software and > compromise of the server potentially leaks a credential which can be > used to impersonate the server for a significant period of time, where=
> that time is dictated by the maximum amount of client-side clock error=
> the server is willing to tolerate, so probably measured in days to
> weeks (and more if you are concerned about the time resetting attack > Watson, Ilari, and I were discussing.) I haven't decided yet sure = how
> serious an issue this is, but it's probably worth addressing
> explicitly.

I'm not sure, because it wasn't explicitly addressed in Hugo= 's
original email, but it seems that the relevant server question is how
long it wants to receive 0-RTT without requiring the client to find
the new address: I don't remember resumption being addressed one way or the other. So the server isn't picking the DH share lifetime for
reasons of clock skew, but rather for PFS refreshment if 0-RTT is
being used.

I think we may be talkin= g past each other. Let me try again.

Forget about = 0-RTT and just consider the 1-RTT flow. In the first flight
the s= erver needs to supply a signed version of g^s. Unless we want
tha= t value to be acceptable to clients indefinitely, it must have some
validity interval. However, because clients have inaccurate clocks,
that interval can't be too narrow or it will cause clients to rej= ect the
g^s value. I'm not sure how narrow it can be, but I w= ould be surprised
if it were less than 12 hours or so. Perhaps so= meone who runs a
large server farm can report on the values they = have historically
seen in the GMT field of the ClientRandom.

-Ekr



=C2=A0




--001a1134de923f505c05072d69f6-- From nobody Thu Nov 6 01:52:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FCD1A1AB4 for ; Thu, 6 Nov 2014 01:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSFDkm7j5zIL for ; Thu, 6 Nov 2014 01:52:31 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D56F1A1AB0 for ; Thu, 6 Nov 2014 01:52:30 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so670069lbj.13 for ; Thu, 06 Nov 2014 01:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LtxR/4+tVOG9iRA/26OiEZhtKhgO6VFkkg51RlqtLu4=; b=lmcucCqHoMX3TdQ0CegbtbzPE6UO4jcrvd9Up+ZoPqMriYCuWIEgV0nVQY6F3+PT7F 7Rmroh2G+1uGiT38fMZt84n9aHMPm0GX/L+WyliTHT2vGWRI6/1gpTybkeEzAPrKQzGl koPX7jtJsHmb8BkZ6GOpYODr3akEcLu/Wbcf4cLle6ZymKUbZ4eFAfrw2k4Kdf6VJ0OA Q+AEIkdTE2+tNkJkMY3Lmer17sTYQqYzHYuOUxRYxkJuVNGvBq07igDeLGlEEohPv8nn pVfkYp2TLzabCXneVp/TNeemq6nU75wy0TDpWJzleoptm81+HItNWwg/jX3NT43IRy0a Iepg== X-Received: by 10.152.206.68 with SMTP id lm4mr3985109lac.2.1415267547892; Thu, 06 Nov 2014 01:52:27 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Thu, 6 Nov 2014 01:51:57 -0800 (PST) In-Reply-To: References: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> From: Hugo Krawczyk Date: Thu, 6 Nov 2014 11:51:57 +0200 X-Google-Sender-Auth: vrmrSp7JDwko_5XZolNQiaU1FM4 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a11349258744f6705072da76e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mL2JbHXFwL7qyvUrECV87JzqtCk Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:52:32 -0000 --001a11349258744f6705072da76e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let me also clarify the following point from the minutes: > The construct presented by Hugo was from the SKEME paper published in '91: http://webee.technion.ac.il/~hugo/skeme-lncs.ps I referred to the paper when answering the question of whether this is a new design. I said that a similar design goes back to the above paper (from NDSS'96 not 91) which had actually many of the same motivations than the current proposal (PFS, identity protection, a uniform treatment of pre-shared key and re-key, etc). On the other hands, there are some significant differences in the new proposal such as the support of 0-RTT and server-only authentication. In cryptography little changes can introduce vulnerabilities so OPTLS needs to be considered as a new design for the sake of analysis (and there are important details to be nailed down, especially the key derivation definitions). Hugo On Thu, Nov 6, 2014 at 1:06 AM, Sean Turner wrote: > On Nov 05, 2014, at 09:56, Bodo Moeller wrote: > > > Adam Langley : > > On Wed, Nov 5, 2014 at 4:49 AM, Bodo Moeller wrote: > > > > > This isn't correct, and isn't what was said at the meeting. As > discussed at > > > the meeting, YouTube currently allows two cipher suites for video > streams, > > > TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but > Firefox > > > doesn't support the former without ECDHE > > > (https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179). > > > > Some locations additionally support ECDHE_RSA_AES_128_GCM_SHA256, > > which we are testing now. > > > > Yes, but the above is about correcting the 2014-10-21 minutes, not > updating them to reflect the current status. > > > > Bodo > > I=E2=80=99ll make sure these get updated. > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11349258744f6705072da76e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me also clarify the following point from th= e minutes:

> The construct presented by Hugo was from the SKEME p= aper published in '91: http://webee.technion.ac.il/~hugo/skeme-lncs.ps

I referred to the paper when answering the question of whether= this is a new design. I said that a similar design goes back to the above = paper (from NDSS'96 not 91) which had actually many of the same motivat= ions than the current proposal (PFS, identity protection, a uniform treatme= nt of pre-shared key and re-key, etc). On the other hands, there are some s= ignificant differences in the new proposal such as the support of 0-RTT and= server-only authentication. In cryptography little changes can introduce v= ulnerabilities so OPTLS needs to be considered as a new design for the sake= of analysis (and there are important details to be nailed down, especially= the key derivation definitions).

Hugo


On Thu, No= v 6, 2014 at 1:06 AM, Sean Turner <turners@ieca.com> wrote:
On= Nov 05, 2014, at 09:56, Bodo Moeller <bmoeller@acm.org> wrote:

> Adam Langley <agl@google.com&= gt;:
> On Wed, Nov 5, 2014 at 4:49 AM, Bodo Moeller <bmoeller@acm.org> wrote:
>
> > This isn't correct, and isn't what was said at the meetin= g. As discussed at
> > the meeting, YouTube currently allows two cipher suites for video= streams,
> > TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but= Firefox
> > doesn't support the former without ECDHE
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179= ).
>
> Some locations additionally support ECDHE_RSA_AES_128_GCM_SHA256,
> which we are testing now.
>
> Yes, but the above is about correcting the 2014-10-21 minutes, not upd= ating them to reflect the current status.
>
> Bodo

I=E2=80=99ll make sure these get updated.

spt
___________________________________= ____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11349258744f6705072da76e-- From nobody Thu Nov 6 02:01:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FAC1A1AB7 for ; Thu, 6 Nov 2014 02:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKrYkmiON8Ja for ; Thu, 6 Nov 2014 02:01:46 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715EF1A1AB5 for ; Thu, 6 Nov 2014 02:01:46 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 9639C3A117; Thu, 6 Nov 2014 11:01:44 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 869324132B; Thu, 6 Nov 2014 11:01:44 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 812BE1AF98; Thu, 6 Nov 2014 11:01:44 +0100 (CET) In-Reply-To: To: Bodo Moeller Date: Thu, 6 Nov 2014 11:01:44 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20141106100144.812BE1AF98@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ElhHwP20CseOEixNlTv54GJNCkw Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= , "tls@ietf.org" Subject: Re: [TLS] Minutes from Tuesday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 10:01:49 -0000 Bodo Moeller wrote: > > Manuel P=E9gouri=E9-Gonnard : >=20 >> Martin Rex wrote: >>> Bodo Moeller wrote: >>>> [...] reacting to a fatal alert is something that all TLS >>>> implementations already know how to do. >> >>> That reaction is called interop failure. That is the far opposite >>> of what IETF working groups are supposed to consciously cause to happen >>> when the alternative would be to make interop succeed. >=20 >>=20 >> the benefits of the solution you suggest, but I think the simplicity of = the >> current draft is a big advantage in getting it widely (and correctly) >> deployed sooner rather than later, which IMO outweighs the advantages >> of a more complex approach. It's actually hard to think of a more unreasonable behaviour than the one currently specified. A different, equally simple and magnitudes more useful server behaviour would be for the server to continue the handshake as normal and simply assume in the processing of the ClientHello that the Client means ClientHello.client_version +1 compared to what it sent over the wire. (but when doing that, the server ought to skip the RSA premaster secret client_version check later on when selecting a cipher suite with static RSA key exchange. Since Microsoft botched the RSA premaster secret version on renegotiation handshakes in Win7, and there is no security value in the check anyway, this should be perfectly OK.) -Martin From nobody Thu Nov 6 09:06:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC901A88AC for ; Thu, 6 Nov 2014 09:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUpvIsEcCtg4 for ; Thu, 6 Nov 2014 09:05:59 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7811A889F for ; Thu, 6 Nov 2014 09:05:58 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id u10so1234976lbd.25 for ; Thu, 06 Nov 2014 09:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gK0iVxXY9KAivzal8ajhwCcJ0yJWO8fe9E63CTrqoqI=; b=gZ5j2XWa+Yb/756YcK+ZBu+j8687Qz9JCZKWqOv8a8Pk33WVvlH7VarxaPl4yd5oxM 1tLtIco4Q/6+7oYuS1DTqNmBPcS5OEU4E8yh7IBSoTBhns85kjZp65uvjS/Ci9v34Y79 TmozfF6DGjE3Ihl251VQzaBBhH9x6WzaoH6+UHJZoAI8OPajF51Qb+Dbt7N3jy1yTZo3 /wowKBROHAZAwaMz06U4bPsAO4c9JSby3VCsKtkfdz4Z+Mz6S93HD9jNc6evaKdgBo3f pQp4h+sK+zc/HD1fqnlqmxcrxxbeOj+dxQBnEwDQWU0/ldJAhUwFYi6Z2r+VYDz5uMbE NSng== MIME-Version: 1.0 X-Received: by 10.152.204.99 with SMTP id kx3mr6222466lac.53.1415293557193; Thu, 06 Nov 2014 09:05:57 -0800 (PST) Received: by 10.25.215.134 with HTTP; Thu, 6 Nov 2014 09:05:56 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Nov 2014 09:05:56 -0800 Message-ID: From: Martin Thomson To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DhkS72loKTCFUUdEyULdkbmbHas Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 17:06:00 -0000 On 6 November 2014 01:34, Hugo Krawczyk wrote: > Regarding the problems with insecure time, it seems that we are reaching > agreement that this should not be a distraction for judging this proposal > (in particular since it does not make things worse than the reliance of time > synchronization for accepting certificates - and it can actually make things > better by having shorter validity periods for the static DH key than for the > long-term certificate). I think that, based on this discussion, I've concluded that there needs to be some sort of expiration bound to the signature over g^s. That at least allows servers to limit the duration of an exposure in the cases where g^s has to reside outside the HSM. At worst, the only concern is clock skew if the server wants to closely replicate online signing. Adding an expiration is a fairly trivial tweak. Other than that, I think that I'm happy with this being - on balance - worth doing. I haven't made up my mind whether the lack of a signature over a peer's credentials is a good or bad thing entirely. I like the idea of deniability, but non-repudiation in general is a hazardous business. From nobody Thu Nov 6 18:42:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743DB1ACE9D for ; Thu, 6 Nov 2014 18:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlWqKRa0P3z6 for ; Thu, 6 Nov 2014 18:42:01 -0800 (PST) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1A71ACE9B for ; Thu, 6 Nov 2014 18:42:00 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id u20so1740859oif.25 for ; Thu, 06 Nov 2014 18:42:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/V7zTxUKgtOHaesIdid92n9f61Hgl2MoVZug6QGcHJY=; b=QxcQzUHMTbdk9QAy+NxCiot1LvaQKpu+PRYpnGX3TL297+ObG+1oxXbU/p7Bp6Q+3I Z2VBJa9WIpYooDmD/QP+iXKbxlm0VwP5LxZFlzxyXpqgQR3mE/eCs2LgsOPjmPLYb8KX 3mQ85OSagHYbmEgitc0L1yoeR3qEESq8DTj1yVHTkgk4dFCrwMhhtASOOilBsyWswU5i Yu2oVzIsnfs+KvdmhABKGy/mfd1l6XQFZXwclJzUr8BIlEc4EERnkfKG2f4ZUy4835uE j8MNXWoZRfQNY630ZQXmdbV6/jxgPthdX4mxKtBR1amGspJFav9rilRKjyUfYtksQ84r KHLA== X-Gm-Message-State: ALoCoQmDWsXYmwR3JGWGIUPiXvg8WyJGY+knPoIfZ1bbTMFWuVA9sC460nR1uQnlm0S0cKbunnpI X-Received: by 10.202.81.198 with SMTP id f189mr5519060oib.25.1415328120204; Thu, 06 Nov 2014 18:42:00 -0800 (PST) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id yq1sm3432228obc.15.2014.11.06.18.41.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2014 18:41:59 -0800 (PST) Message-ID: <545C3175.5070204@amacapital.net> Date: Thu, 06 Nov 2014 18:41:57 -0800 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hugo Krawczyk , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K2nlcC0UhnjY0IBAMqU2vkxEibQ Cc: Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 02:42:02 -0000 On 10/31/2014 05:54 PM, Hugo Krawczyk wrote: > During the TLS interim meeting of last week (Oct 22 2014) I suggested > that TLS > 1.3 should abandon signature-based authentication (other than for > certificates) > and be based solely on a combination of ephemeral Diffie-Hellman for PFS and > static Diffie-Hellman for authentication. This has multiple benefits > including > major performance gain (by replacing the per-handshake RSA signature by the > server with a much cheaper elliptic curve exponentiation), compatibility > with > the mechanisms required for forward secrecy, natural accommodation of a > 0-RTT > option, and a simple extension without signatures for client authentication. I like this idea a lot. > Note on certificates: Since in current practice servers hold > certificates for > RSA signature keys rather than for static DH keys, the certificate field > in the > above protocol will be implemented by a pair consisting of (i) the > server's RSA > signature certificate and (ii) the server's signature using this RSA key > on the > server's static public DH key g^s. The latter signature by the server is > performed only when a new static DH key is created (how often this > happens and > how many such keys are created is completely up to the server - it has the > advantage that these keys can be changed often to increase security against > leaked keys). This use of RSA also enjoys the high efficiency of RSA > verification for the client. > The handling of Client certificates would be similar. I would like to see one modification of this: I think that the certificate should be (RSA/ECDSA certificate, server's long-term DH share, expiration), signed by the cert. That way any user of a certificate can sign short-term shares instead of long-term shares, significantly reducing the impact of a leak. It would be even better if there were a way to limit one of these things to a certain host. That being said, I do have one significant concern with this: what happens when someone builds a quantum computer? I don't expect TLS 1.3 to be post-quantum secure, but I would like the road to replacing primitives for post-quantum security to be reasonably clear. Unfortunately, I'm not aware of a credible post-quantum DH-like construction. On the other hand, post-quantum signatures are straightforward if rather large right now, and post-quantum public-key encryption is, as far as I remember, not guaranteed to be a drop-in replacement for DH. Will this end up being a problem? --Andy From nobody Thu Nov 6 21:45:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4676F1ACEE6 for ; Thu, 6 Nov 2014 21:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh-VLe2byZxH for ; Thu, 6 Nov 2014 21:45:21 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D649B1ACEEB for ; Thu, 6 Nov 2014 21:45:20 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id t59so2122610yho.13 for ; Thu, 06 Nov 2014 21:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QT3rUfMKdltQWUhulJmhaxWIfCXgEnwPW78VJrPlNjM=; b=inJuO1gyWH8f0r0EHbyZwmgovHziZap1qBxHvM6zUWULF8cPQfZPv9eJyLVqymiChQ TuLAqbm0YSLd5cA7NLxxhulbP+IO2bvYmC4aOn8Iuwul3bcnlZ6hyUzVekzV8VDEyKGs Fyi1eo1euBC7Bh++7nrLw4y8E8XsybaAyu4zNZWkokRxNLJStZzDttNJkE46NNO2vHIs HElaeRGPPlZ3zEnsvmI+dg+6jXWXJsXMGP0CSlE2qokTzx4qDptkuoYkpuxPOl/HgUq7 x/qOnRdPSBwu3qlrN79VZuVg381+apjZw5WNzOs0XT9kdExzuoCGtGgROHKwAbmTmjN7 S7cQ== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr8637860yha.163.1415339120173; Thu, 06 Nov 2014 21:45:20 -0800 (PST) Received: by 10.170.195.203 with HTTP; Thu, 6 Nov 2014 21:45:20 -0800 (PST) In-Reply-To: <545C3175.5070204@amacapital.net> References: <545C3175.5070204@amacapital.net> Date: Thu, 6 Nov 2014 21:45:20 -0800 Message-ID: From: Watson Ladd To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BOtR14xUrQRC2NR28Ygo6TQzHfo Cc: Hoeteck Wee , "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 05:45:26 -0000 On Thu, Nov 6, 2014 at 6:41 PM, Andy Lutomirski wrote: > On 10/31/2014 05:54 PM, Hugo Krawczyk wrote: >> During the TLS interim meeting of last week (Oct 22 2014) I suggested >> that TLS >> 1.3 should abandon signature-based authentication (other than for >> certificates) >> and be based solely on a combination of ephemeral Diffie-Hellman for PFS and >> static Diffie-Hellman for authentication. This has multiple benefits >> including >> major performance gain (by replacing the per-handshake RSA signature by the >> server with a much cheaper elliptic curve exponentiation), compatibility >> with >> the mechanisms required for forward secrecy, natural accommodation of a >> 0-RTT >> option, and a simple extension without signatures for client authentication. > > I like this idea a lot. > >> Note on certificates: Since in current practice servers hold >> certificates for >> RSA signature keys rather than for static DH keys, the certificate field >> in the >> above protocol will be implemented by a pair consisting of (i) the >> server's RSA >> signature certificate and (ii) the server's signature using this RSA key >> on the >> server's static public DH key g^s. The latter signature by the server is >> performed only when a new static DH key is created (how often this >> happens and >> how many such keys are created is completely up to the server - it has the >> advantage that these keys can be changed often to increase security against >> leaked keys). This use of RSA also enjoys the high efficiency of RSA >> verification for the client. >> The handling of Client certificates would be similar. > > I would like to see one modification of this: I think that the > certificate should be (RSA/ECDSA certificate, server's long-term DH > share, expiration), signed by the cert. That way any user of a > certificate can sign short-term shares instead of long-term shares, > significantly reducing the impact of a leak. Note that in the above proposal, long-term can be entirely defined by the server or client as the case may be. I feel I'm missing something here. > > It would be even better if there were a way to limit one of these things > to a certain host. The client cert that is? I'm not sure what this gets you: we know how to use certs securely. > > > > That being said, I do have one significant concern with this: what > happens when someone builds a quantum computer? I don't expect TLS 1.3 > to be post-quantum secure, but I would like the road to replacing > primitives for post-quantum security to be reasonably clear. > > Unfortunately, I'm not aware of a credible post-quantum DH-like > construction. On the other hand, post-quantum signatures are > straightforward if rather large right now, and post-quantum public-key > encryption is, as far as I remember, not guaranteed to be a drop-in > replacement for DH. > > Will this end up being a problem? If supersingular isogeny volcanoes are secure, it won't be a problem. NTRU for old TLS is also a possible backup plan. > > --Andy > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Nov 6 22:21:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6171ACEF9 for ; Thu, 6 Nov 2014 22:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo0L0eQSyyUE for ; Thu, 6 Nov 2014 22:21:48 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2C61ACEF8 for ; Thu, 6 Nov 2014 22:21:48 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id q1so3901074lam.38 for ; Thu, 06 Nov 2014 22:21:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VMSrOhdKU5tmKpmaKcZCZwFeJS72nRrL+Jptjz3KZvU=; b=BnFr2f8c0FFCTN5/6dd5HmEFV/1xncMdo+cajBfHZRxK+0L954P9aRPS0GxbbhlDb3 rZOk6Z5L07/izeItLHoHrlD+RFytVollGFnzNVxDHvjfHj47svLOMru9OIKN1VM96MVT 9VozLqbROwvgxrVkl51SeuRTjqSi8xLmd5lVmzcQi8Jue1emIpn9fTcwo5IhsLTCZdjB z5I7oO1rD51ZhYL1lBufpnhUMs1K0zd52Kj1LwBaO/34kdRLkPvBK2rwriqjC7SIsP0h QOVetkVpyIl5YacWYUcZbRJpBh5Oy6czLqRHle9UYlga/xtnmbTjyITNz3LN+TclG35A 71pQ== X-Gm-Message-State: ALoCoQkXOt3gWT4GF/Yp0/ZuFFRREu3TlbTAgeTxVwCSsbajBzmXkd/qbAEMC0aLkp58qqh1U+Xc X-Received: by 10.152.5.6 with SMTP id o6mr9547005lao.4.1415341306638; Thu, 06 Nov 2014 22:21:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.4.71 with HTTP; Thu, 6 Nov 2014 22:21:26 -0800 (PST) In-Reply-To: References: <545C3175.5070204@amacapital.net> From: Andy Lutomirski Date: Thu, 6 Nov 2014 22:21:26 -0800 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lTqpGdKHE23F-vobL0VilAUvDwM Cc: Hoeteck Wee , "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 06:21:54 -0000 On Thu, Nov 6, 2014 at 9:45 PM, Watson Ladd wrote: > On Thu, Nov 6, 2014 at 6:41 PM, Andy Lutomirski wrote: >> On 10/31/2014 05:54 PM, Hugo Krawczyk wrote: >>> During the TLS interim meeting of last week (Oct 22 2014) I suggested >>> that TLS >>> 1.3 should abandon signature-based authentication (other than for >>> certificates) >>> and be based solely on a combination of ephemeral Diffie-Hellman for PFS and >>> static Diffie-Hellman for authentication. This has multiple benefits >>> including >>> major performance gain (by replacing the per-handshake RSA signature by the >>> server with a much cheaper elliptic curve exponentiation), compatibility >>> with >>> the mechanisms required for forward secrecy, natural accommodation of a >>> 0-RTT >>> option, and a simple extension without signatures for client authentication. >> >> I like this idea a lot. >> >>> Note on certificates: Since in current practice servers hold >>> certificates for >>> RSA signature keys rather than for static DH keys, the certificate field >>> in the >>> above protocol will be implemented by a pair consisting of (i) the >>> server's RSA >>> signature certificate and (ii) the server's signature using this RSA key >>> on the >>> server's static public DH key g^s. The latter signature by the server is >>> performed only when a new static DH key is created (how often this >>> happens and >>> how many such keys are created is completely up to the server - it has the >>> advantage that these keys can be changed often to increase security against >>> leaked keys). This use of RSA also enjoys the high efficiency of RSA >>> verification for the client. >>> The handling of Client certificates would be similar. >> >> I would like to see one modification of this: I think that the >> certificate should be (RSA/ECDSA certificate, server's long-term DH >> share, expiration), signed by the cert. That way any user of a >> certificate can sign short-term shares instead of long-term shares, >> significantly reducing the impact of a leak. > > Note that in the above proposal, long-term can be entirely defined by > the server or client as the case may be. I feel I'm missing something > here. > >> >> It would be even better if there were a way to limit one of these things >> to a certain host. > > The client cert that is? I'm not sure what this gets you: we know how > to use certs securely. Sorry, I wasn't very clear. My thought is that, if we're going to introduce a new object signed by the PKIX cert, such that a server only needs the private key associated with that object and not the certificate's private key, then we should take advantage of this to add some features. In particular, we should let it expire before the certificate, and I think we should allow it to be pinned to a particular hostname or maybe set of hostnames. The former was covered elsewhere in this thread. The latter was not. Also, ha ha ha ha. We know how to user certs securely. Yeah, right. If I buy a cert for *.my.domain, I want to be able to provision foo.my.domain with some secret that lets it act as foo.my.domain but not bar.my.domain. Since the PKIX people seem to be completely unable to address this, pinning DH shares to a domain would solve the problem without involving any PKIX changes. > >> >> >> >> That being said, I do have one significant concern with this: what >> happens when someone builds a quantum computer? I don't expect TLS 1.3 >> to be post-quantum secure, but I would like the road to replacing >> primitives for post-quantum security to be reasonably clear. >> >> Unfortunately, I'm not aware of a credible post-quantum DH-like >> construction. On the other hand, post-quantum signatures are >> straightforward if rather large right now, and post-quantum public-key >> encryption is, as far as I remember, not guaranteed to be a drop-in >> replacement for DH. >> >> Will this end up being a problem? > > If supersingular isogeny volcanoes are secure, it won't be a problem. > NTRU for old TLS is also a possible backup plan. > The former is a big if, and it makes me nervous to say that, if someone builds a quantum computer, that TLS 1.2 might be better than 1.3. And my inner pundit expects NTRU to fail as soon as anyone pushes it hard. That being said, this may not be a big deal -- I suspect we'll have *something* that fits in this framework. --Andy From nobody Fri Nov 7 00:33:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911BD1A1A9A for ; Fri, 7 Nov 2014 00:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybXgKuDOWjHr for ; Fri, 7 Nov 2014 00:33:08 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE10D1A1A99 for ; Fri, 7 Nov 2014 00:33:07 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id z12so2279547lbi.15 for ; Fri, 07 Nov 2014 00:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=V1JdVPnklbDbGBGHzUKkYggGGZWORJjfiPCXpgS0Vhc=; b=mJN5OdBV30RDDM+MuoSbAaJxyok53Jq5VfJ8iSGg8cOmSzQ9A/Ph1bvLeY48ratj/F n4xlLvN0H8PT98zZ2SLO21r/BidUetLXkI1kiIw2fmJKDKVyK0Dy0oeha6CfO1kK7sVU 73hGg982jPaxiDwNf4KzZI+C51ooD8Mqy3JH/yS6VF73qIoaX2KO/sCPLa/4p9HBFYsd c47LWhGpOlsirsz8wtADXizXL+ZS3gN7vgTKEmGUcS5FqIRxuG7qrJsmKH18ZwQilKLe XK1RkVJLvya/ZBhZ9L0hDPRI0hSIk6NTpyoE2YqjSPOn4wEqfl7tJRnx5rncswv+VxhA aXMg== X-Received: by 10.152.43.97 with SMTP id v1mr9838405lal.3.1415349186366; Fri, 07 Nov 2014 00:33:06 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Fri, 7 Nov 2014 00:32:36 -0800 (PST) In-Reply-To: <545C3175.5070204@amacapital.net> References: <545C3175.5070204@amacapital.net> From: Hugo Krawczyk Date: Fri, 7 Nov 2014 10:32:36 +0200 X-Google-Sender-Auth: 6RKT_uUV9NazNtIeGZYxYi_O86I Message-ID: To: Andy Lutomirski Content-Type: multipart/alternative; boundary=001a11c356267c94b5050740a93f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N7B5o8lFYkqFDsMwWDtSRtYXHHw Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 08:33:11 -0000 --001a11c356267c94b5050740a93f Content-Type: text/plain; charset=UTF-8 Regarding the post-quantum question below: Any public key encryption (PKE) mechanism can be used for PFS, you just need to generate session-specific private-public key pairs and use them for that session only. So any quantum-resistant PKE (QR-PKE) scheme can be used for PFS. More fundamentally, digital signatures do not suffice for key exchange. You need a PKE, or similar mechanism, to actually exchange the key (signatures are only good for authenticating the exchange). Once you have a QR-PKE, you replace the key g^{xs} in OPTLS with an encryption of a random key under the server encryption public key and use this random key for computing the Finished message. By the way, I am personally more concerned about the possibility of a significant advance in (classic) ECC cryptanalysis in the near-medium future than with a practical-enough quantum machine that can break the ECC cryptography. In particular, progress in quantum will most likely be gradual and will give us time to prepare the next-generation QR cryptography while a mathematical break of ECC could happen overnight (or over several nights :). For all we know, it might have already happened... (I guess one can say that someone might have already built a quantum computer but to me that looks much more unlikely). Hugo On Fri, Nov 7, 2014 at 4:41 AM, Andy Lutomirski wrote: > On 10/31/2014 05:54 PM, Hugo Krawczyk wrote: > > During the TLS interim meeting of last week (Oct 22 2014) I suggested > > that TLS > > 1.3 should abandon signature-based authentication (other than for > > certificates) > > and be based solely on a combination of ephemeral Diffie-Hellman for PFS > and > > static Diffie-Hellman for authentication. This has multiple benefits > > including > > major performance gain (by replacing the per-handshake RSA signature by > the > > server with a much cheaper elliptic curve exponentiation), compatibility > > with > > the mechanisms required for forward secrecy, natural accommodation of a > > 0-RTT > > option, and a simple extension without signatures for client > authentication. > > I like this idea a lot. > > > Note on certificates: Since in current practice servers hold > > certificates for > > RSA signature keys rather than for static DH keys, the certificate field > > in the > > above protocol will be implemented by a pair consisting of (i) the > > server's RSA > > signature certificate and (ii) the server's signature using this RSA key > > on the > > server's static public DH key g^s. The latter signature by the server is > > performed only when a new static DH key is created (how often this > > happens and > > how many such keys are created is completely up to the server - it has > the > > advantage that these keys can be changed often to increase security > against > > leaked keys). This use of RSA also enjoys the high efficiency of RSA > > verification for the client. > > The handling of Client certificates would be similar. > > I would like to see one modification of this: I think that the > certificate should be (RSA/ECDSA certificate, server's long-term DH > share, expiration), signed by the cert. That way any user of a > certificate can sign short-term shares instead of long-term shares, > significantly reducing the impact of a leak. > > It would be even better if there were a way to limit one of these things > to a certain host. > > > > That being said, I do have one significant concern with this: what > happens when someone builds a quantum computer? I don't expect TLS 1.3 > to be post-quantum secure, but I would like the road to replacing > primitives for post-quantum security to be reasonably clear. > > Unfortunately, I'm not aware of a credible post-quantum DH-like > construction. On the other hand, post-quantum signatures are > straightforward if rather large right now, and post-quantum public-key > encryption is, as far as I remember, not guaranteed to be a drop-in > replacement for DH. > > Will this end up being a problem? > > --Andy > --001a11c356267c94b5050740a93f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the post-quantum question below: Any = public key encryption (PKE) mechanism can be used for PFS, you just need to= generate session-specific private-public key pairs and use them for that s= ession only. So any quantum-resistant PKE (QR-PKE) scheme can be used for P= FS. More fundamentally, digital signatures do not suffice for key exchange.= You need a=C2=A0 PKE, or similar mechanism, to actually exchange the key (= signatures are only good for authenticating the exchange). Once you have a = QR-PKE, you replace the key g^{xs} in OPTLS with an encryption of a random = key under the server encryption public key and use this random key for comp= uting the Finished message.

By the way, I am person= ally more concerned about the possibility of a significant advance in (clas= sic) ECC cryptanalysis in the near-medium future than with a practical-enou= gh quantum machine that can break the ECC cryptography. In particular, prog= ress in quantum will most likely be gradual and will give us time to prepar= e the next-generation QR cryptography while a mathematical break of ECC cou= ld happen overnight (or over several nights :). For all we know, it might h= ave already happened... (I guess one can say that someone might have alread= y built a quantum computer but to me that looks much more unlikely).
Hugo


On Fri, Nov 7, 2014 at 4:41 AM, Andy Lu= tomirski <luto@amacapital.net> wrote:
On 10/31/2014 05:54 PM, Hugo Krawczyk wrote:=
> During the TLS interim meeting of last week (Oct 22 2014) I suggested<= br> > that TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for P= FS and
> static Diffie-Hellman for authentication. This has multiple benefits > including
> major performance gain (by replacing the per-handshake RSA signature b= y the
> server with a much cheaper elliptic curve exponentiation), compatibili= ty
> with
> the mechanisms required for forward secrecy, natural accommodation of = a
> 0-RTT
> option, and a simple extension without signatures for client authentic= ation.

I like this idea a lot.

> Note on certificates: Since in current practice servers hold
> certificates for
> RSA signature keys rather than for static DH keys, the certificate fie= ld
> in the
> above protocol will be implemented by a pair consisting of (i) the
> server's RSA
> signature certificate and (ii) the server's signature using this R= SA key
> on the
> server's static public DH key g^s. The latter signature by the ser= ver is
> performed only when a new static DH key is created (how often this
> happens and
> how many such keys are created is completely up to the server - it has= the
> advantage that these keys can be changed often to increase security ag= ainst
> leaked keys). This use of RSA also enjoys the high efficiency of RSA > verification for the client.
> The handling of Client certificates would be similar.

I would like to see one modification of this: I think that the
certificate should be (RSA/ECDSA certificate, server's long-term DH
share, expiration), signed by the cert.=C2=A0 That way any user of a
certificate can sign short-term shares instead of long-term shares,
significantly reducing the impact of a leak.

It would be even better if there were a way to limit one of these things to a certain host.



That being said, I do have one significant concern with this: what
happens when someone builds a quantum computer?=C2=A0 I don't expect TL= S 1.3
to be post-quantum secure, but I would like the road to replacing
primitives for post-quantum security to be reasonably clear.

Unfortunately, I'm not aware of a credible post-quantum DH-like
construction.=C2=A0 On the other hand, post-quantum signatures are
straightforward if rather large right now, and post-quantum public-key
encryption is, as far as I remember, not guaranteed to be a drop-in
replacement for DH.

Will this end up being a problem?

--Andy

--001a11c356267c94b5050740a93f-- From nobody Fri Nov 7 04:57:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6EF1A8A6D for ; Thu, 6 Nov 2014 11:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQD0lmly1Pjs for ; Thu, 6 Nov 2014 11:40:39 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B041A1B83 for ; Thu, 6 Nov 2014 11:40:39 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id x12so1261877qac.7 for ; Thu, 06 Nov 2014 11:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W4IclgG+NNyeYw4rso1lkHu96jz3CIpZiwfuA9Hj1V0=; b=A7+GjciEw/1vRskRbtVqrcN239ITCodmGW6qJK4PaaLnhAdkBAczzDG/6yipFg/NUx gjcDjLRxbkUlI7PD492p1zIliAFMSWQaMd5GTaku94Y6W+SPDPzyMJaX+jeppd7SJyNX 9Pbe8X2TEXo4CEPqGM/A0laJS5j4UcF5FBuLF/N7SwmjfJvjM8xJTjos5cEJZcgXqi1S kLyPOR1bhP/4WferCMGoTLPZSU5lhRHFn/UD0DCAbcegBGahmi/oxspRUkQGIRdcDjmd rOohUcF5PecmwR5iowgYgNguXphioIAwXnbhBCe1PH+R8S4zR42eeE3EJW28dOBYQA6E KIqQ== MIME-Version: 1.0 X-Received: by 10.224.86.68 with SMTP id r4mr10172888qal.55.1415302838513; Thu, 06 Nov 2014 11:40:38 -0800 (PST) Received: by 10.140.195.132 with HTTP; Thu, 6 Nov 2014 11:40:38 -0800 (PST) In-Reply-To: <54438671.8060806@polarssl.org> References: <54438671.8060806@polarssl.org> Date: Thu, 6 Nov 2014 20:40:38 +0100 Message-ID: From: Fox Arcadia To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: multipart/alternative; boundary=001a11c3ec7af07752050735def2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gi8ibrZPaCRe43Y7l4WEooPe6p0 X-Mailman-Approved-At: Fri, 07 Nov 2014 04:57:37 -0800 Cc: tls@ietf.org Subject: Re: [TLS] RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 19:40:41 -0000 --001a11c3ec7af07752050735def2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mr P=C3=A9gouri=C3=A9 Thanks for your answer. It is very helpful. But one security concern. Tls is now used by GlobalPlatform Amd. B. (Basically SmartCards, UICCs and Embedded Secure elements). Please see http://www.globalplatform.org/specificationscard.asp. Part of the PMS is zeroes and this fact is known by the attacker. Now he can study the power consumption of the device when the PRF is processing the zeroes and try to get some information about counter measures implemented by the protocol for these devices. These attacks are known as DFA/SPA. Please see http://www.springer.com/computer/security+and+cryptology/book/978-0-387-308= 57-9 In your opinion using a key partially known by the attacker could imply a security threat? Thanks for your help Kind regards On Sun, Oct 19, 2014 at 11:37 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > Hi, > > Sorry for replying so late, I hope this reply is still useful. > > On 20/09/2014 09:51, Fox Arcadia wrote: > > Note 2: Using zeroes for "other_secret" effectively means that > > only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PR= F > > is used when constructing the master secret. This was considered > > more elegant from an analytical viewpoint than, for instance, > > using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. Se= e > > [KRAWCZYK ] for > > a more detailed rationale. > > > IMO, this is only a rationale for using the zeroes, not a normative part. > > > but if using a PRF defined in TLS V1.2, then HMAC-MD5 is not used but > > the HMAC defined by the PRF. > > > > And, in that case, part of the used premaster is zeroes. > > > Yes, in that case part of the PMS is zeroes, and it's fed to the TLS PRF > (using > SHA256) as is, including the zeroes. > > At least, that's what we do in PolarSSL and we never had interop issues > (tested > regularly with OpenSSL and GnuTLS at least). > > > should we in that case reuse PSK for other_secret? > > > Nope. > > Manuel. > --001a11c3ec7af07752050735def2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mr P=C3=A9gouri=C3=A9

= Thanks for your answer. It is very helpful.

But one security c= oncern.
Tls is now used by GlobalPlatform Amd. B. (Basically SmartCards= , UICCs and Embedded Secure elements).

Part of the PM= S is zeroes and this fact is known by the attacker.

Now h= e can study the power consumption of the device when the PRF is processing = the zeroes and try to get some information about counter measures implement= ed by the protocol for these devices.

These attacks are k= nown as DFA/SPA.
In your opinion using a key partially known by the attacker coul= d imply a security threat?

Thanks for your hel= p

Kind regards




=



On Sun, Oct 19, 2014 at 11:37 AM, Manuel P=C3=A9gouri=C3=A9-G= onnard <mpg@polarssl.org> wrote:
Hi,

Sorry for replying so late, I hope this reply is still useful.

On 20/09/2014 09:51, Fox Arcadia wrote:
>=C2=A0 Note 2: Using zeroes for "other_secret" effectively me= ans that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0only the HMAC-SHA1 part (but not the HMAC-MD= 5 part) of the TLS PRF
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is used when constructing the master secret.= =C2=A0 This was considered
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more elegant from an analytical viewpoint th= an, for instance,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using the same key for both the HMAC-MD5 and= HMAC-SHA1 parts.=C2=A0 See
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[KRAWCZYK <http://tools.ietf.or= g/html/rfc4279#ref-KRAWCZYK>] for
> a more detailed rationale.
>
IMO, this is only a rationale for using the zeroes, not a normative part.
> but if using a PRF defined in TLS V1.2, then HMAC-MD5 is not used but<= br> > the HMAC defined by the PRF.
>
> And, in that case, part of the used premaster is zeroes.
>
Yes, in that case part of the PMS is zeroes, and it's fed to the= TLS PRF (using
SHA256) as is, including the zeroes.

At least, that's what we do in PolarSSL and we never had interop issues= (tested
regularly with OpenSSL and GnuTLS at least).

> should we in that case reuse PSK for other_secret?
>
Nope.

Manuel.

--001a11c3ec7af07752050735def2-- From nobody Fri Nov 7 04:57:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0B1A1A12 for ; Wed, 5 Nov 2014 23:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9RwxeGT0E7f for ; Wed, 5 Nov 2014 23:50:13 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6041A1A0D for ; Wed, 5 Nov 2014 23:50:13 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id q108so337699qgd.41 for ; Wed, 05 Nov 2014 23:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Iw5X+fgTziTGrQNo42y9/GiOapEUzvp0Y0DI2a3pP1M=; b=TSChqJxQVz19+1c+rOf/pW1g2Y61dO0cmAU11CEbhxghAS8V30axwI+13frC1oUOn4 cbzy9v6I4TBUM4VGnnNr5GXwe19GvsMkNCduVkXbC3Gr0WsqyjwtENZHZy0nwhrEiNW+ M/25tdCl45waUQo8nffXkOpFWvWFHCQ1pj8hUMv7yv8W0BpT9nioVn/CkqD+nFdvkeor /kA9vrQwPiFcafkJbUPPoCEyjLalrpxtAQsbOc/ZclQ75OBlpKY/2eriJyNJ6M5l8wGy C0aBFbvLLiVfB7yn95pQZEsYoFfRkzmT2YlOpWFJH3sYsYNElu7OYVh5tzuFjJ8N8+yM AdTw== X-Received: by 10.229.139.195 with SMTP id f3mr4189366qcu.3.1415260212837; Wed, 05 Nov 2014 23:50:12 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id h79sm5276784qgd.27.2014.11.05.23.50.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Nov 2014 23:50:12 -0800 (PST) From: Dave Garrett To: Yoav Nir Date: Thu, 6 Nov 2014 02:50:10 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201411031651.09896.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201411060250.11408.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W5oVTGfbq9obj0gOUSd-m0NmL7o X-Mailman-Approved-At: Fri, 07 Nov 2014 04:57:44 -0800 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 07:50:15 -0000 =46or clients wanting to attempt a fallback, yes, this might not be a perfe= ct solution. It is,=20 however, far better than the current state. Ciphers would not have to be as= sessed and implementation=20 of the restrictions would be far more simple and clear. Moving the painpoin= t, as you say, would be a=20 notable improvement. One simple check vs. a handful of possibly complex che= cks. At this point, Greg Wilkins' proposal looks to be the best available option= getting any discussion: http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0481.html An HTTP/2 handshake would not be able to include any legacy ciphers, and if= this fails then the=20 client could then fallback and retry with HTTP/1.1 instead. It gets a more = robust handshake in=20 exchange for a slightly slower fallback if the server does not support any = modern ciphers. I should=20 note that this is already something Mozilla is implementing with respect to= RC4. The plan is to do=20 the initial handshake without RC4 and only offer it as a possibility if the= more ideal cipher set is=20 rejected. (fallback order becomes: 1.2-RC4, 1.2+RC4, 1.1+RC4, 1.0+RC4) Dave On Thursday, November 06, 2014 02:21:02 am Yoav Nir wrote: > Hi, Dave >=20 > I believe that ultimately this does not solve the issue raised about 9.2.2 > on the httpbis list. >=20 > The issue there was that a client would propose AES-CBC and AES-GCM > (forgive me for shortening the grouping suites) with =E2=80=9Ch1=E2=80=9D= and =E2=80=9Ch2=E2=80=9D, and > then it=E2=80=99s up to the server to know that the AES-CBC and =E2=80=9C= h2=E2=80=9D combination > is prohibited by the HTTP/2 spec. This could be done either by the HTTP > layer checking on the TLS layer, or by adding callbacks and APIs for the > HTTP layer to make the choice of ciphersuite for the TLS layer, or by > incorporating some HTTP/2 specifications into the TLS layer. People > claimed that this was either ugly or hard to implement. >=20 > The issue does not go away with your proposal. The reason servers support > =E2=80=9Ch1=E2=80=9D at all is to support legacy clients, and the reason = clients propose > =E2=80=9Ch1=E2=80=9D and non-AEAD ciphersuites at all is to support legac= y servers. What > your proposal does is move the pain point from ciphersuite selection to > version selection. A client would still propose TLS 1.0, TLS 1.1, TLS 1.2, > and if it=E2=80=99s updated, TLS 1.3. A server would still have to know t= hat the > =E2=80=9Ch2=E2=80=9D and TLS 1.2 combination is invalid, and the complexi= ty remains. >=20 > It=E2=80=99s true that the current requirement in HTTP/2 has this issue a= nyway, as > it prohibits TLS versions under TLS 1.2, but I=E2=80=99m in the =E2=80=9C= rip out 9.2.2 and > live with whatever the TLS layer negotiates=E2=80=9D camp. >=20 > Yoav From nobody Fri Nov 7 07:06:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2311A8713 for ; Fri, 7 Nov 2014 07:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdMRvFadb6tt for ; Fri, 7 Nov 2014 07:06:23 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED11A8718 for ; Fri, 7 Nov 2014 07:06:23 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6542647629; Fri, 7 Nov 2014 15:06:22 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5813547626; Fri, 7 Nov 2014 15:06:22 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 538652026; Fri, 7 Nov 2014 15:06:22 +0000 (GMT) Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 7 Nov 2014 10:06:21 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 7 Nov 2014 10:06:21 -0500 From: "Salz, Rich" To: Fox Arcadia , =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= Date: Fri, 7 Nov 2014 10:06:19 -0500 Thread-Topic: [TLS] RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2? Thread-Index: Ac/6im0CvPhreRFRSeK2jSNyTkMgYAAEaqkA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC693@USMBX1.msg.corp.akamai.com> References: <54438671.8060806@polarssl.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lE0MFg--Ro7VvfarDWnp_s4JQQE Cc: "tls@ietf.org" Subject: Re: [TLS] RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:06:25 -0000 PiBUaGVzZSBhdHRhY2tzIGFyZSBrbm93biBhcyBERkEvU1BBLg0KPiBJbiB5b3VyIG9waW5pb24g dXNpbmcgYSBrZXkgcGFydGlhbGx5IGtub3duIGJ5IHRoZSBhdHRhY2tlciBjb3VsZCBpbXBseSBh IHNlY3VyaXR5IHRocmVhdD8NCg0KWWVzLCBkZWZpbml0ZWx5LiAgQ29uc3RhbnQgdGltZSBpbXBs ZW1lbnRhdGlvbnMgaGF2ZSBiZWNvbWUgbW9yZSBpbXBvcnRhbnQgYW5kIHdpZGVzcHJlYWQgcmVj ZW50bHkuIFRoZSBzdGF0ZSBvZiB0aGUgYXJ0IG1vdmVzIGZvcndhcmQuIERpZmZlcmVudGlhbCBw b3dlciBhbmFseXNpcyBpcyBzaW1pbGFyLiAgUHJvdGVjdGluZyBhZ2FpbnN0IHRoYXQgY2FuIGJl IGRvbmU7IGl0IGNhbiBiZSBoYXJkLiAgU2VlIHRoZSAiUlNBIGJsaW5kaW5nIiB3b3JrIGluIE9w ZW5TU0wsIGZvciBleGFtcGxlLg0KDQoJL3IkIA0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkg RW5naW5lZXIsIEFrYW1haSBUZWNobm9sb2dpZXMNCklNOiByc2FsekBqYWJiZXIubWUgVHdpdHRl cjogUmljaFNhbHoNCg== From nobody Fri Nov 7 13:39:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADE21A1B39 for ; Fri, 7 Nov 2014 13:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hFA9_x1JdiV for ; Fri, 7 Nov 2014 13:39:04 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB7B1A1B0B for ; Fri, 7 Nov 2014 13:39:04 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so4736822wgh.12 for ; Fri, 07 Nov 2014 13:39:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=fzOnqUSrGNdqrLj5L1x6tqSPED8mqnsOEuxJPC1ku+w=; b=fGIFUVSO5gecS/QzxPZIgGXg1tM+B/L8/PBoHMV6pXgx7BXg81q9u5O4hiFq1zxrF8 KV8TpuM9p73lQ3+5SvshSQZIHESpzlM7fYbTZm46RldIXotpZZyTHuxKRwpUj8DZAzZj OLWaH46eO3zpFjIGSJTvNSdGn7KrrWO1qUQs61WGlFQ5o9rqAQj4GQ/jCt3+VWrGqO6Z yl8jZWDBNjS+O2vG9xg77m3N1HIt2qCI/zfPw5n3W5UY7UIORNM6ckKp5wYPw4RzYRnO z0VSofpnfirOcTMr2ibjIYsn1Bk9mqk8PIIFJd3dlUV4vZBkS2u+IYv0jc8WNwDzk10u wP+Q== X-Gm-Message-State: ALoCoQmcGJcl1g6sgSakicTL1vRqIcALfqu3pKjxqXtXgHcdGJnJWuyZ+/yuZl3ga4PginQqVJ7K X-Received: by 10.194.79.201 with SMTP id l9mr20178604wjx.59.1415396343128; Fri, 07 Nov 2014 13:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Fri, 7 Nov 2014 13:38:22 -0800 (PST) From: Eric Rescorla Date: Fri, 7 Nov 2014 13:38:22 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0d0f63fd75d05074ba4ff Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8euhGtnZT9izF3nEPIlJkhXuKHA Subject: [TLS] Pull request for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 21:39:06 -0000 --047d7bf0d0f63fd75d05074ba4ff Content-Type: text/plain; charset=UTF-8 Per WG discussion in YYZ, here is a pull request to remove renegotiation. https://github.com/tlswg/tls13-spec/pull/88 -Ekr --047d7bf0d0f63fd75d05074ba4ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Per WG discussion in YYZ, here is a pull request to remove= renegotiation.


-Ekr


--047d7bf0d0f63fd75d05074ba4ff-- From nobody Fri Nov 7 14:02:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649F51A1B3A for ; Fri, 7 Nov 2014 14:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH7du6am5Rby for ; Fri, 7 Nov 2014 14:02:09 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE161A1B46 for ; Fri, 7 Nov 2014 14:02:09 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so5872549wiv.6 for ; Fri, 07 Nov 2014 14:02:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=77KgWw4l6e1vCpOnkoQ8IpZR4RwiK2q14AtYvaGrpM8=; b=dJIrlNMErX3Rw31p8qBBmLzJvljLnLWeQsLiU2MXV5QOj0+i31weBMpbv8XinOXrre wvfjZ2q0VEdeI4Y8zgiStqseVNQJUsp4DTtjw/vDHitekNO060Ff/ovu3d+0vSn8cQA1 0gAehkZTF4xRaa4nUfh4NWB7A62s5e1Cc6vn86cbFNoc/PDxJUFSrqAUbhhJeqRB/oyx FeaAv8wq2xbSa05zh5xRu/ncAKt+alWihC7hlKb5fjRZxjcGzUbQGg96OQagkJcUtGmr TWoJmZwWgHAnxPMp8zpQ0mrQyAcpRcsAIT2KSPGBde5ykto2c6WskwM0r49WZZfylBF1 imfw== X-Gm-Message-State: ALoCoQm9P/zRArkLJ2zN50P3LDvo1R75lQiEWPGbASYqjHkLZ3rSUadmtU4tVgvPka3PdRUnjeg6 X-Received: by 10.180.88.68 with SMTP id be4mr8934970wib.36.1415397728094; Fri, 07 Nov 2014 14:02:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Fri, 7 Nov 2014 14:01:27 -0800 (PST) From: Eric Rescorla Date: Fri, 7 Nov 2014 14:01:27 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428f1acca35e05074bf639 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/30O7AEXDrZw19inkm-QgIIvtsbM Subject: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:02:12 -0000 --f46d04428f1acca35e05074bf639 Content-Type: text/plain; charset=UTF-8 I've created a preliminary pull request to adapt the session hash fix for TLS 1.3 for feedback from the WG. Points to note: - IMPORTANT: Because the initial handshake messages are encrypted under separate keys from the application data traffic, it seems like we need to have 2 sets of CCS messages or none. In anticipation of removing renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88). Based on conversations with Alfredo and Martin, it seemed easier to remove them. Warning: analysis needed here. - I created a separate resumption master secret that is fed into the key hierarchy. This makes the description of that simpler but will need revisiting if we adopt either Rich's unification of session hash and tickets or Karthik's PSK-as-tickets unification, but that seemed like a separate issue. - If we adopt the Update proposal we will also need to split the master keys into two directional keys, but that's distinct as well. - I still need to add the names of the session hash authors t acknowledgements. This will probably need another revision before it is ready for merging, but I wanted to get it out there for feedback. -Ekr --f46d04428f1acca35e05074bf639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've created a preliminary pull request to adapt the s= ession hash fix for TLS 1.3
for feedback from the WG.

Points to note:

- IMPORTANT: Because the ini= tial handshake messages are encrypted
=C2=A0 under separate keys = from the application data traffic, it seems like we need
=C2=A0 t= o have 2 sets of CCS messages or none. In anticipation of removing
=C2=A0 renegotiation (see PR=C2=A0https://github.com/tlswg/tls13-spec/pull/88).
=C2=A0 Based on conversations with Alfredo and Martin, it seemed easier
=C2=A0 to remove them. Warning: analysis needed here.
- I created a separate resumption master secret that is fed in= to the
=C2=A0 key hierarchy. This makes the description of that s= impler but will
=C2=A0 need revisiting if we adopt either Rich= 9;s unification of session hash
=C2=A0 and tickets or Karthik'= ;s PSK-as-tickets unification, but that seemed
=C2=A0 like a sepa= rate issue.

- If we adopt the Update proposal we w= ill also need to split the master
=C2=A0 keys into two directiona= l keys, but that's distinct as well.

- I still= need to add the names of the session hash authors t
=C2=A0 a= cknowledgements.

This will probably need ano= ther revision before it is ready for merging, but
I wanted to get= it out there for feedback.

-Ekr



--f46d04428f1acca35e05074bf639-- From nobody Fri Nov 7 14:19:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B91A1B6B for ; Fri, 7 Nov 2014 14:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXr0HQziA5RZ for ; Fri, 7 Nov 2014 14:19:06 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4111A1B58 for ; Fri, 7 Nov 2014 14:19:06 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so4715147wgh.15 for ; Fri, 07 Nov 2014 14:19:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=HuFct/loCZpxxDu0CG83gqBrwqtaGjZUewQL7yzhOBg=; b=O7qo8le4IAUF4WjMuxBAs7etGyM/PbAsdZxTg/tpSRBcryosR9urAzrgCwRbczbh+S RoSckNFYOPdYzcOpj0/pxDAW8w0fGzlNyC4ZGtGqgpEH3ysQaActh8NFxhzrVrNAics7 Ro8vbY3UtKCTsjeTrtWwOTV7OgBwYPXXgm9LmpxFVrDB5IjqMNIdRC04kUYEp3vtxyD/ 33RUzB2P/0ddcKlJ3dUtrCuoC3ry82Cr2Sr2r2JNRDJBfOnH5MiGQ+molDzSgZkaERok m0AmHG1S4xTnF2WeE/RhAo2tFH4RpjQ+7x/0PN31IryB0PpL5fERTOtf5SUwbqP8c616 YiqQ== X-Gm-Message-State: ALoCoQlB1HGDEpQ5UiyUeB7yBePGmTGMuVrglLAQx09PXjh3UYb6un+eke6WCslxp5FrQ3pSaN3R X-Received: by 10.194.79.201 with SMTP id l9mr20422697wjx.59.1415398744868; Fri, 07 Nov 2014 14:19:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Fri, 7 Nov 2014 14:18:24 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Nov 2014 14:18:24 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0d0f6675f1905074c33ac Archived-At: http://mailarchive.ietf.org/arch/msg/tls/54ckReA041rpeiMFBb64J_nWvJw Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:19:08 -0000 --047d7bf0d0f6675f1905074c33ac Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/89 On Fri, Nov 7, 2014 at 2:01 PM, Eric Rescorla wrote: > I've created a preliminary pull request to adapt the session hash fix for > TLS 1.3 > for feedback from the WG. > > Points to note: > > - IMPORTANT: Because the initial handshake messages are encrypted > under separate keys from the application data traffic, it seems like we > need > to have 2 sets of CCS messages or none. In anticipation of removing > renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88). > Based on conversations with Alfredo and Martin, it seemed easier > to remove them. Warning: analysis needed here. > > - I created a separate resumption master secret that is fed into the > key hierarchy. This makes the description of that simpler but will > need revisiting if we adopt either Rich's unification of session hash > and tickets or Karthik's PSK-as-tickets unification, but that seemed > like a separate issue. > > - If we adopt the Update proposal we will also need to split the master > keys into two directional keys, but that's distinct as well. > > - I still need to add the names of the session hash authors t > acknowledgements. > > This will probably need another revision before it is ready for merging, > but > I wanted to get it out there for feedback. > > -Ekr > > > > --047d7bf0d0f6675f1905074c33ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 7, 2014 at 2:01 PM, Eric = Rescorla <ekr@rtfm.com> wrote:
=
I've created a preliminary pull request to adapt the s= ession hash fix for TLS 1.3
for feedback from the WG.

Points to note:

- IMPORTANT: Because the ini= tial handshake messages are encrypted
=C2=A0 under separate keys = from the application data traffic, it seems like we need
=C2=A0 t= o have 2 sets of CCS messages or none. In anticipation of removing
=C2=A0 renegotiation (see PR=C2=A0https://github.com/tlswg/tls13-spec/pull= /88).
=C2=A0 Based on conversations with Alfredo and Martin, = it seemed easier
=C2=A0 to remove them. Warning: analysis needed = here.

- I created a separate resumption master sec= ret that is fed into the
=C2=A0 key hierarchy. This makes the des= cription of that simpler but will
=C2=A0 need revisiting if we ad= opt either Rich's unification of session hash
=C2=A0 and tick= ets or Karthik's PSK-as-tickets unification, but that seemed
= =C2=A0 like a separate issue.

- If we adopt the Up= date proposal we will also need to split the master
=C2=A0 keys i= nto two directional keys, but that's distinct as well.

- I still need to add the names of the session hash authors t
<= /div>
=C2=A0 acknowledgements.

This will= probably need another revision before it is ready for merging, but
I wanted to get it out there for feedback.

-Ekr=




--047d7bf0d0f6675f1905074c33ac-- From nobody Fri Nov 7 14:35:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5D1A1B3B for ; Fri, 7 Nov 2014 14:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0jMYPCZZKtr for ; Fri, 7 Nov 2014 14:35:12 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3EA1A00CF for ; Fri, 7 Nov 2014 14:35:11 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 591DA188772; Sat, 8 Nov 2014 00:35:08 +0200 (EET) Date: Sat, 8 Nov 2014 00:35:08 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20141107223508.GA23136@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZpqP4jjIJcnakjETWIOBCh4prDg Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:35:14 -0000 On Fri, Nov 07, 2014 at 02:01:27PM -0800, Eric Rescorla wrote: > I've created a preliminary pull request to adapt the session hash fix for > TLS 1.3 > for feedback from the WG. Quick comment: I presume "{ServerKeyShare}" in figure 2 should be "ServerKeyShare" (i.e. not encrypted). > Points to note: > > - IMPORTANT: Because the initial handshake messages are encrypted > under separate keys from the application data traffic, it seems like we > need > to have 2 sets of CCS messages or none. In anticipation of removing > renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88). > Based on conversations with Alfredo and Martin, it seemed easier > to remove them. Warning: analysis needed here. I would say that from implementation safety perspective (at least for non-D TLS) it is better to do the state transitions implicitly. Except this could cause fun issues if ContentType is encrypted. I favor "do it wrong and blow up at runtime" over "do it wrong and get a security hole". Even if the first would be more complex. (This can also be used to argue that session hash should not be restarted on retry, not that I think repeating data is a good idea anyway). > - I created a separate resumption master secret that is fed into the > key hierarchy. This makes the description of that simpler but will > need revisiting if we adopt either Rich's unification of session hash > and tickets or Karthik's PSK-as-tickets unification, but that seemed > like a separate issue. Oh, on topic of multiple master secrets, which one does TLS-Extractor get? :-) -Ilari From nobody Fri Nov 7 16:36:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0A31A007C for ; Fri, 7 Nov 2014 16:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l33EhO9oLqN for ; Fri, 7 Nov 2014 16:35:51 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CCA1A000E for ; Fri, 7 Nov 2014 16:35:51 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id n3so6063583wiv.8 for ; Fri, 07 Nov 2014 16:35:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yXPIXmCt/dsDfs6FpIsCRy/Bj89+uvLYOdquoSLKnLo=; b=QgGJLGLYkoSHHj3012f0k5TSwtuTyrYy4npxjmKV54o/j0mMjfFU1KTqWim2CLMwne QJdy4VU8NEDQ51RArADiLPnCWh6733vKXIw0u2WgDjIdlEyNZ/OyrT8ZZlexOJE08Dxy 14fyjO9PwVnLs9se4H6LenkLlciIubwbV72vENLmx0Jsr7umJJvcQWbgFR32+HnF7H8Q fKHxKYgi2q+N9+l4cMRiEXmigwiHFbXJzBJiS1ZdIS7HiJmPDVEFKOYYyb7Dik2aR6J1 baBoJWv6DSMjRT4FDErojIZQCRjv4qGTdmXUszXjZ2dNnScAPxVfifGIlqsswCiYORPE JJpw== X-Gm-Message-State: ALoCoQm0RSynLkHyv5uC0SKFuIOVfN5Y0ml4QCq1SaDppcgE1nGa5mbur0cr3Q3MOjIaxX4MBA1V X-Received: by 10.180.108.43 with SMTP id hh11mr9563417wib.80.1415406949969; Fri, 07 Nov 2014 16:35:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Fri, 7 Nov 2014 16:35:09 -0800 (PST) In-Reply-To: <20141107223508.GA23136@LK-Perkele-VII> References: <20141107223508.GA23136@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 7 Nov 2014 16:35:09 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e0122950a77469005074e1c0f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cU0Q7waEzC1fcJmsPMDAcZ1xTBw Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 00:35:53 -0000 --089e0122950a77469005074e1c0f Content-Type: text/plain; charset=UTF-8 On Fri, Nov 7, 2014 at 2:35 PM, Ilari Liusvaara wrote: > On Fri, Nov 07, 2014 at 02:01:27PM -0800, Eric Rescorla wrote: > > I've created a preliminary pull request to adapt the session hash fix for > > TLS 1.3 > > for feedback from the WG. > > Quick comment: I presume "{ServerKeyShare}" in figure 2 should be > "ServerKeyShare" (i.e. not encrypted). Good catch. Thanks. > Points to note: > > > > - IMPORTANT: Because the initial handshake messages are encrypted > > under separate keys from the application data traffic, it seems like we > > need > > to have 2 sets of CCS messages or none. In anticipation of removing > > renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88). > > Based on conversations with Alfredo and Martin, it seemed easier > > to remove them. Warning: analysis needed here. > > I would say that from implementation safety perspective (at least for > non-D TLS) it is better to do the state transitions implicitly This seems like a topic where we're going to have a lot of opinions :) If we do decide to have the CCS, we would restore the previous CCS after ClientKeyShare/ServerKeyShare and then put a new one after each side's Finished. I still have the text in git, so I can bring it back. :) > > - I created a separate resumption master secret that is fed into the > > key hierarchy. This makes the description of that simpler but will > > need revisiting if we adopt either Rich's unification of session hash > > and tickets or Karthik's PSK-as-tickets unification, but that seemed > > like a separate issue. > > Oh, on topic of multiple master secrets, which one does TLS-Extractor > get? :-) Also a good catch. I suggest we make a new TLS Exporter MS. -Ekr > > > -Ilari > --089e0122950a77469005074e1c0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 7, 2014 at 2:35 PM, Ilari Liusvaara <<= a href=3D"mailto:ilari.liusvaara@elisanet.fi" target=3D"_blank">ilari.liusv= aara@elisanet.fi> wrote:
On Fri, Nov 07, 2014 at 02:01:27PM -0800, Eric Rescorla wrot= e:
> I've created a preliminary pull request to adapt the session hash = fix for
> TLS 1.3
> for feedback from the WG.

Quick comment: I presume "{ServerKeyShare}" in figure 2 sh= ould be
"ServerKeyShare" (i.e. not encrypted).

Good catch. Thanks.
=C2=A0

> Points to note:
>
> - IMPORTANT: Because the initial handshake messages are encrypted
>=C2=A0 =C2=A0under separate keys from the application data traffic, it = seems like we
> need
>=C2=A0 =C2=A0to have 2 sets of CCS messages or none. In anticipation of= removing
>=C2=A0 =C2=A0renegotiation (see PR https://github.com/tlswg/tls13-spec/p= ull/88).
>=C2=A0 =C2=A0Based on conversations with Alfredo and Martin, it seemed = easier
>=C2=A0 =C2=A0to remove them. Warning: analysis needed here.

I would say that from implementation safety perspective (at least fo= r
non-D TLS) it is better to do the state transitions implicitly
=

This seems like a topic where we're going to have a= lot of opinions :)

If we do decide to have the CC= S, we would restore the previous CCS
after ClientKeyShare/ServerK= eyShare and then put a new one after
each side's Finished. I = still have the text in git, so I can bring it back. :)

=
=C2=A0
> - I created a separate resumption master secret that is fed into the >=C2=A0 =C2=A0key hierarchy. This makes the description of that simpler = but will
>=C2=A0 =C2=A0need revisiting if we adopt either Rich's unification = of session hash
>=C2=A0 =C2=A0and tickets or Karthik's PSK-as-tickets unification, b= ut that seemed
>=C2=A0 =C2=A0like a separate issue.

Oh, on topic of multiple master secrets, which one does TLS-Extracto= r
get? :-)

Also a good catch. I suggest we ma= ke a new TLS Exporter MS.

-Ekr
=C2=A0


-Ilari

--089e0122950a77469005074e1c0f-- From nobody Fri Nov 7 17:21:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205471A00DE for ; Fri, 7 Nov 2014 17:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53u1NIunoxOf for ; Fri, 7 Nov 2014 17:21:14 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD0F1A00D7 for ; Fri, 7 Nov 2014 17:21:13 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id C93983A374; Sat, 8 Nov 2014 02:21:11 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7D849423FD; Sat, 8 Nov 2014 02:21:11 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6EAF51AFAB; Sat, 8 Nov 2014 02:21:11 +0100 (CET) In-Reply-To: To: Eric Rescorla Date: Sat, 8 Nov 2014 02:21:11 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141108012111.6EAF51AFAB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SC-VqcjJhUa8v6YrJ2NsV-fSNHY Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 01:21:16 -0000 Eric Rescorla wrote: > > - IMPORTANT: Because the initial handshake messages are encrypted > under separate keys from the application data traffic, it seems like we > need to have 2 sets of CCS messages or none. In anticipation of removing > renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88). > Based on conversations with Alfredo and Martin, it seemed easier > to remove them. Warning: analysis needed here. Huh? >From an implementation standpoint CCS being a seperate content type record that is clearly visible to the record layer is one of the better ideas of the original SSLv3 protocol. It reduces the necessity for synchonizing the record layer and the handshake state machine, and allows having the record layer concatenate consecutive handshake messages into a single TLS record automatically on the sender side. On the recipient side, it allows the record layer to preprocess a batch of incoming TLS records without having to wait for the handshake message state machine (some TLS stacks create a seperate TLS record for each handshake message). -Martin From nobody Fri Nov 7 17:52:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B61A00C5 for ; Fri, 7 Nov 2014 17:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4zunZet8Oy2 for ; Fri, 7 Nov 2014 17:52:38 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755BA1A00A6 for ; Fri, 7 Nov 2014 17:52:38 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id i17so3547379qcy.28 for ; Fri, 07 Nov 2014 17:52:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=hO+gExtmUE2/CKaK0GweYJhoITKvd/HoepWbSLAQcfU=; b=TVmMu1mVH9HchGT8aMWBVfc5OW0acfXunryPjRUDHqRoDGeEqJuYqa0VY/Wm7Qtlsm NmaMvtUPzSDr+JhI3T1lFgw1H497JzqUBU6nj2dPgAaRut70cWEZh2ykpsTMkQi0pUGM L1YTRhsUm4vFPRcGgrDOhuMg0FcbDNJE2xa8176PbjCgJ+fn4YgJ5082MZ+Nasd2vLR4 90QMvCNTWCuZiSg3S/c2bMG6Dw9rPC1vz7Q4sIpU5MCSNkPIyTTyziibcZzrmU5b7Se4 xOp1rpZwYLNJbspu8R4PcgyY6T/4qkwG3Y5UsXA0cIj9bVWo8sEgA/nn6nBNvYTSTQih WN+w== X-Gm-Message-State: ALoCoQm71vmdhlmN75sFBDc+X46V3BVafWFj1Cq49zq9aJfPwOtAEs3nxTK8LiSQeqxFbHEhkEUf MIME-Version: 1.0 X-Received: by 10.140.104.65 with SMTP id z59mr21474142qge.75.1415411557782; Fri, 07 Nov 2014 17:52:37 -0800 (PST) Received: by 10.96.215.170 with HTTP; Fri, 7 Nov 2014 17:52:37 -0800 (PST) X-Originating-IP: [67.168.161.122] Date: Fri, 7 Nov 2014 17:52:37 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11354e4c1cf1b105074f2f39 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Oe84qb-76KVqa621-kiA-nU1wc Subject: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 01:52:41 -0000 --001a11354e4c1cf1b105074f2f39 Content-Type: text/plain; charset=UTF-8 Below is my summary of the fallback SCSV issue with some suggestions. Since I'm weighing in on the text as an individual I'm asking Sean to finish up the consensus process on this draft. I've gone through he SCSV comments and I think the following issues need to be resolved: 1. The draft does not really state that the fallback SCSV is really a hack and that standard version negotiation should really be encouraged. Here is some text that could go into the introduction: "The fallback SCSV defined in this document is not suitable substitute for proper TLS version negotiation. TLS implementations need to properly handle TLS version negotiation and extensibility mechanisms to avoid the security issues and connection delays associated with fallback mechanisms." 2. The current draft will cause TLS connections to fail if a downgrade happens for any reason. This will result in additional retries even if the server is willing to continue at the lower version. An alternative using extensions has been described to allow the server to communicate the status of the downgrade back to the client and let the client decide whether to continue. >From reading the list I don't think we have consensus to abandon the the SCSV approach. The SCSV mechanism is simpler and it does not rely on extensions which have been a reason for server failures in the past. However, I think the draft can better describe the conditions of when the client SHOULD include the SCSV and what the client SHOULD do if it receives an inappropriate_fallback alert. Here is some proposed text for section 4 and security considerations: Section 4 "If the client receives an inappropriate_fallback alert then the server intends to support a higher version and the client should retry with the highest version it supports. Implementors should review the security considerations section before deciding to make a connection with a lower version without including the TLS_FALLBACK_SCSV. Security Considerations "Section 4 does not require client implementations to send TLS_FALLBACK_SCSV in any particular case, it merely recommends it; behavior can be adapted according to the client's security needs. However, it is important to remember that omitting the TLS_FALLBACK_SCSV leaves the TLS connection vulnerable to version rollback so it is not recommended to omit the SCSV unless the negotiated version provides an acceptable level of protection. For example, during the initial deployment of a new protocol version (when some interoperability problems may have to be expected), smoothly falling back to the previous protocol version in case of problems may be preferrable to potentially not being able to connect at all: so TLS_FALLBACK_SCSV could be omitted for this particular protocol downgrade step. However, it is strongly recommended to send TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have weaknesses that cannot be addressed by implementation workarounds like the remaining weaknesses in later (TLS) protocol versions." 3. The introduction should indicate that the Fallback SCSV also applies to DTLS. 4. The IANA considerations section needs to allocate the number for the alert: "IANA is asked to assign the following value in the TLS Alert Registry for use with TLS and DTLS. 86 inappropriate_fallback Y [RFC TBD]" --001a11354e4c1cf1b105074f2f39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Below is my summary of the fallback SCSV issue with some suggestions.=C2= =A0 Since I'm weighing in on the text as an individual I'm asking S= ean to finish up the consensus process on this draft. =C2=A0

I've gone through he SCSV comments and I think the fo= llowing issues need to be resolved:

1.=C2= =A0 The draft does not really state that the fallback SCSV is really a hack= and that standard version negotiation should really be encouraged.=C2=A0 H= ere is some text that could go into the introduction:

"The fallback SCSV defined in this document is not suitable= substitute for proper TLS version negotiation. TLS implementations need to= properly handle TLS version negotiation and extensibility mechanisms to av= oid the security issues and connection delays associated with fallback mech= anisms."

2.=C2=A0 The current draft wi= ll cause TLS connections to fail if a downgrade happens for any reason.=C2= =A0 This will result in additional retries even if the server is willing to= continue at the lower version.=C2=A0 An alternative=C2=A0using extensions=C2=A0has been de= scribed to allow the server to communicate the status of the downgrade back= to the client and let the client decide whether to continue. =C2=A0=

From reading the list I don't think we have c= onsensus to abandon the the SCSV approach.=C2=A0 The SCSV mechanism is simp= ler and it does not rely on extensions which have been a reason for server = failures in the past.=C2=A0 However, I think the draft can better describe = the conditions of when the client SHOULD include the SCSV and what the clie= nt SHOULD do if it receives an inappropriate_fallback alert.=C2=A0 Here is = some proposed text for section 4 and security considerations:

Section 4

"If the c= lient receives an inappropriate_fallback alert then the server intends to s= upport a higher version and the client should retry with the highest versio= n it supports. =C2=A0 Implementors should review the security consideration= s section before deciding to make a connection with a lower version without= including the TLS_FALLBACK_SCSV. =C2=A0

Se= curity Considerations

"Section 4 does = not require client implementations to send TLS_FALLBACK_SCSV in any particu= lar case, it merely recommends it; behavior can be adapted according to the= client's security needs.=C2=A0 However, it is important to remember th= at omitting the TLS_FALLBACK_SCSV leaves the TLS connection vulnerable to v= ersion rollback so it is not recommended to omit the SCSV unless the negoti= ated version provides an acceptable level of protection. =C2=A0

For example, during the initial deployment of a new pr= otocol version
(when some = interoperability problems may have to be expected),
=C2=A0 =C2=A0smoothly falling back to the previou= s protocol version in case of
=C2=A0 =C2=A0problems may be preferrable to potentially not being able = to connect
= =C2=A0 =C2=A0at= all: so TLS_FALLBACK_SCSV could be omitted for this particular
=C2=A0 =C2=A0protocol downgrade step.=

=C2=A0 =C2=A0However, it is strongly reco= mmended to send TLS_FALLBACK_SCSV when
=C2=A0 =C2=A0downgrading to SSL 3.0 as the CBC cipher suites i= n SSL 3.0 have
=C2=A0 =C2= =A0weaknesses that cannot be addressed by implementation workarounds=
=C2=A0 =C2=A0like the remaining = weaknesses in later (TLS) protocol versions."

3.=C2=A0 The introduction should indicate that the Fallback SCSV al= so applies to DTLS. =C2=A0

<= span style=3D"font-family:arial,sans-serif;font-size:13px">4.=C2=A0 The IAN= A considerations section needs to allocate the number for the alert:=

"IANA is asked to assign the following value= in the TLS Alert Registry for use with TLS and DTLS. =C2=A0

86 =C2=A0inappropriate_fallback Y [RFC TBD]"<= br>
--001a11354e4c1cf1b105074f2f39-- From nobody Fri Nov 7 19:38:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77651A0022 for ; Fri, 7 Nov 2014 19:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpfVO16t5vpE for ; Fri, 7 Nov 2014 19:38:20 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959911A00F1 for ; Fri, 7 Nov 2014 19:38:19 -0800 (PST) Received: from 151.170.251.212.customer.cdi.no ([212.251.170.151]:62511 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Xmwqo-0002Av-NL for tls@ietf.org; Sat, 08 Nov 2014 04:38:10 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: Date: Sat, 08 Nov 2014 04:37:51 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YOrFbz6baL6rQIa0e4PNVKAM1_w Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 03:38:23 -0000 Hello all, Below is some statistics that I did not complete gathering until this week, related to something I think was mentioned in the SCSV discussion thread a couple of weeks ago: Some servers are apparently intolerant to the SCSV, and attempts to connect using the SCSV will fail. My TLS Prober runs indicates that 2.5% of servers will fail a connection using the SCSV when it is placed at the last position in the cipher suite list, and 4.9% will fail if it is placed at the beginning of the list. In fact, while a sample of just two weeks is problematic, these numbers appear to be increasing, as one week earlier the numbers were 2.1% and 4.0%, respectively. I also tested three other alternative SCSVs,placed at the end of the cipher suite list, and 0.6% of the tested servers did not tolerate each of those. As a comparison, 1.3% of the tested servers are extension intolerant when the client indicates TLS 1.x. The combination of SCSV intolerant and extension intolerant servers appear to be less than 0.1% of the sample. As I have not yet managed to pin down a server with this combination that fails during actual testing with an SCSV supporting browser, I am wondering if this combination is at least partly due to false postives, or if they fail at specific TLS versions. Further testing may be necessary to find out if that is so. 14.4% support the SCSV at this time. Related to TLS 1.3 and fallbacks: Essentially all of the SCSV supporting servers failed when the SCSV is used at the start and for the server's highest supported version; less than 0.1% did so for the SCSV at the end. Also, 2.4% of servers are intolerant for the TLS 1.3 version indication, half of them are Renego patched. On Sat, 08 Nov 2014 02:52:37 +0100, Joseph Salowey wrote: > Below is my summary of the fallback SCSV issue with some suggestions. > Since I'm weighing in on the text as an individual I'm asking Sean to > finish up the consensus process on this draft. > > I've gone through he SCSV comments and I think the following issues need > to > be resolved: > > 1. The draft does not really state that the fallback SCSV is really a > hack > and that standard version negotiation should really be encouraged. Here > is > some text that could go into the introduction: > > "The fallback SCSV defined in this document is not suitable substitute > for > proper TLS version negotiation. TLS implementations need to properly > handle > TLS version negotiation and extensibility mechanisms to avoid the > security > issues and connection delays associated with fallback mechanisms." > > 2. The current draft will cause TLS connections to fail if a downgrade > happens for any reason. This will result in additional retries even if > the > server is willing to continue at the lower version. An alternative using > extensions has been described to allow the server to communicate the > status > of the downgrade back to the client and let the client decide whether to > continue. > >> From reading the list I don't think we have consensus to abandon the the > SCSV approach. The SCSV mechanism is simpler and it does not rely on > extensions which have been a reason for server failures in the past. > However, I think the draft can better describe the conditions of when the > client SHOULD include the SCSV and what the client SHOULD do if it > receives > an inappropriate_fallback alert. Here is some proposed text for section > 4 > and security considerations: > > Section 4 > > "If the client receives an inappropriate_fallback alert then the server > intends to support a higher version and the client should retry with the > highest version it supports. Implementors should review the security > considerations section before deciding to make a connection with a lower > version without including the TLS_FALLBACK_SCSV. > > Security Considerations > > "Section 4 does not require client implementations to send > TLS_FALLBACK_SCSV in any particular case, it merely recommends it; > behavior > can be adapted according to the client's security needs. However, it is > important to remember that omitting the TLS_FALLBACK_SCSV leaves the TLS > connection vulnerable to version rollback so it is not recommended to > omit > the SCSV unless the negotiated version provides an acceptable level of > protection. > > For example, during the initial deployment of a new protocol version > (when some interoperability problems may have to be expected), > smoothly falling back to the previous protocol version in case of > problems may be preferrable to potentially not being able to connect > at all: so TLS_FALLBACK_SCSV could be omitted for this particular > protocol downgrade step. > > However, it is strongly recommended to send TLS_FALLBACK_SCSV when > downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have > weaknesses that cannot be addressed by implementation workarounds > like the remaining weaknesses in later (TLS) protocol versions." > > 3. The introduction should indicate that the Fallback SCSV also applies > to > DTLS. > > 4. The IANA considerations section needs to allocate the number for the > alert: > > "IANA is asked to assign the following value in the TLS Alert Registry > for > use with TLS and DTLS. > > 86 inappropriate_fallback Y [RFC TBD]" -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Fri Nov 7 21:08:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEFC1A0282 for ; Fri, 7 Nov 2014 21:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj6aqRMvZrYb for ; Fri, 7 Nov 2014 21:08:48 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FD91A026E for ; Fri, 7 Nov 2014 21:08:47 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id u10so3691862lbd.11 for ; Fri, 07 Nov 2014 21:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TR50WU972U8ZAvUrdZNiLCpnZLMDCXWj5pLwgG4KPIU=; b=ixbbSXe7P/PXLa6HVpk8p6UuWn1f4U56BWiSQev8laNhRmDBUHbpkzYs2UxXx7bijb GbU7NxbEnMsA8A1WjiU0ryXqGuj9UON48Xo3K2YYn2qxMM95KuwmtfdZPgyHD2ikADrT eyphK7Utv0tkTFKflF9W+9LLGRcondAGvoqaPyjJG3HepG2XtP0reI8oPnuswpdB2KOL k+KOQRfN5B8ntDvqindcntdmd4MNnJUAX4ru3dmo4g5g7S0brMSKicF4iUbHo/vp2HF0 MIDzIrZJKgCZCjIl2DQrYbJ+8X9vq+ULrIifWn1zpNOjx09ZzZ9hVbzQo/ZjbI74nafW uMlA== MIME-Version: 1.0 X-Received: by 10.112.200.34 with SMTP id jp2mr15215822lbc.1.1415423326090; Fri, 07 Nov 2014 21:08:46 -0800 (PST) Received: by 10.25.215.134 with HTTP; Fri, 7 Nov 2014 21:08:46 -0800 (PST) In-Reply-To: <201411060250.11408.davemgarrett@gmail.com> References: <201411031651.09896.davemgarrett@gmail.com> <201411060250.11408.davemgarrett@gmail.com> Date: Fri, 7 Nov 2014 21:08:46 -0800 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P2pJLZ6v07hjs1H7ezVaczm5ATw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 05:08:50 -0000 On 5 November 2014 23:50, Dave Garrett wrote: > I should > note that this is already something Mozilla is implementing with respect to RC4. We're only doing that because it aligns the incentives correctly. Sites using RC4 get to continue doing so (for now), but are penalized for doing so. Requiring Greg's proposed fallback causes almost all browser users to be penalized for attempting to use HTTP/2. Very few sites currently use a TLS profile that is even potentially HTTP/2 compatible, so those users are the ones who pay. I don't like creating externalities like this. From nobody Sat Nov 8 23:01:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBC01A19F2 for ; Sat, 8 Nov 2014 23:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZF5_BZYcAkV for ; Sat, 8 Nov 2014 23:01:04 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1F79D1A19EF for ; Sat, 8 Nov 2014 23:01:03 -0800 (PST) Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id E22E2F98C for ; Sun, 9 Nov 2014 02:01:01 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id BC70720073; Sat, 8 Nov 2014 14:29:31 -0500 (EST) From: Daniel Kahn Gillmor To: tls@ietf.org Date: Sat, 8 Nov 2014 14:29:31 -0500 Message-Id: <1415474971-7775-2-git-send-email-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.1.1 In-Reply-To: <1415474971-7775-1-git-send-email-dkg@fifthhorseman.net> References: <1415474971-7775-1-git-send-email-dkg@fifthhorseman.net> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bWzlJJiY9ygUChdlOOZgO9iv0ns Subject: [TLS] [removing renegotiation patch 2/2] avoid referring to the absent "hello request" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 07:01:05 -0000 The current changes remove hello_request from the HandshakeType enum, but then it is still referenced in the description of no_renegotiation alert. This changeset avoids reintroducing the value for the enum, but still clarifies when the client should send a no_renegotiation alert. --- draft-ietf-tls-tls13.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-tls-tls13.md b/draft-ietf-tls-tls13.md index 14ec39a..5a66e40 100644 --- a/draft-ietf-tls-tls13.md +++ b/draft-ietf-tls-tls13.md @@ -1432,7 +1432,8 @@ user_canceled by a close_notify. This message is generally a warning. no_renegotiation -: Sent by the client in response to a hello request or by the server +: Sent by the client in response to a hello request (a Handshake + message where msg_type is 0) or by the server in response to a client hello after initial handshaking. Versions of TLS prior to TLS 1.3 supported renegotiation of a previously established connection; TLS 1.3 removes this feature. When the -- 2.1.1 From nobody Sat Nov 8 23:01:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FE11A19EF for ; Sat, 8 Nov 2014 23:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFK7tP94GU5y for ; Sat, 8 Nov 2014 23:01:04 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7511A19EB for ; Sat, 8 Nov 2014 23:01:03 -0800 (PST) Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id A2751F989 for ; Sun, 9 Nov 2014 02:01:01 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id B9729200DC; Sat, 8 Nov 2014 14:29:31 -0500 (EST) From: Daniel Kahn Gillmor To: tls@ietf.org Date: Sat, 8 Nov 2014 14:29:30 -0500 Message-Id: <1415474971-7775-1-git-send-email-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.1.1 In-Reply-To: References: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hcgYUxS4npZNVTLihrzVFdUt2c4 Subject: [TLS] [removing renegotiation patch 1/2] clarify when no_renegotiation alert is fatal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 07:01:05 -0000 In 1.2 and earlier, the no_renegotiation alert is "always a warning". Under the current proposal, in TLS 1.3 it is "always fatal". I (think i) understand the scope of these statements, but i worry that "always" can be interpreted more broadly than intended. --- draft-ietf-tls-tls13.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-tls-tls13.md b/draft-ietf-tls-tls13.md index 729fa3a..14ec39a 100644 --- a/draft-ietf-tls-tls13.md +++ b/draft-ietf-tls-tls13.md @@ -1435,8 +1435,8 @@ no_renegotiation : Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Versions of TLS prior to TLS 1.3 supported renegotiation of a previously - established connection; TLS 1.3 removes this feature. This - message is always fatal. + established connection; TLS 1.3 removes this feature. When the + protocol version is TLS 1.3, this message is a fatal alert. unsupported_extension : sent by clients that receive an extended server hello containing -- 2.1.1 From nobody Sat Nov 8 23:01:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17E91A19F7 for ; Sat, 8 Nov 2014 23:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8jdli-Hj7VP for ; Sat, 8 Nov 2014 23:01:06 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 43B181A19EF for ; Sat, 8 Nov 2014 23:01:06 -0800 (PST) Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id A8C93F98C for ; Sun, 9 Nov 2014 02:01:03 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id F22BB20F7D; Sat, 8 Nov 2014 11:06:33 -0500 (EST) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sat, 08 Nov 2014 11:06:30 -0500 Message-ID: <87r3xdfzi1.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4nSa2WeFQvTM-qdC-M6jA3x6h8I Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 07:01:07 -0000 --=-=-= Content-Type: text/plain On Thu 2014-11-06 01:54:11 -0500, Eric Rescorla wrote: > if the signing key is online (as will be required for TLS 1.2 compat) > compromise of the machine will let you sign a DH share with a very > long lifetime. It's conceivable that the online key for TLS 1.2 compatibility could be one that is not the same as one that is used for signing g^s. To achieve this separation of purpose, though, we'd need to be able to distinguish between certificates capable of anchoring the end entity in a TLS 1.2 session and certificates capable of certifying a long-term g^s. Making these distinguishable would probably require a new X.509v3 extension, or extendedKeyUsage. So we're back to fiddling with X.509, if we want to avoid the described attack :/ --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUXj+HXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcO2IQAI5RGNyIFu1QfxpmtKQDKZtO je4nNvvd5ZJOCrKVFnAgwIWQqu/3o5y9eRwGpM9xSkFGvtsCFxDjCRQd94YkLlDp VHjgWEO7Q3Vi9aL4AWAp2A8Dok9nrDedZJccSNh1mC1rEfaj71/aDKn9qZVSwyKY vyH8bVjjWhwT6qmW8Bo49X686BgU/fMtwhS2uENy+lQtkIgP2Mt+VkzTWGlL3vBt XskhfQEEqhVJ9xLSG57U2al8xY1WSJBN/mKl+kxc0E+CGc4rMx2eZ0a3bfUEDJVw 0E8Qcv/rmaOtoRbh7dfvdML8KfR8rLK6tZNfLbBd0ZcBhj4niYygmZCgcvDTI+e3 rt/WslwA+pKP5w2EnJNOzzjxf7c8bJnqn+8gmXdsY7GHGO61C/BeKN3wzqYdCHw1 F5DzU6zICeK7LzvHXRGX4pZeggnAK+oVd26PngFUDVU0c6guDM1s5sg6T4oyHwT2 LUH0Vu/8zAWyQCRfKUI3ahYSBG7RxkWwJS7l2nGT510gcuYN3glWlcZ/QnntmMHx uBKE+xSkGr3s7y4d/pFZXupgZQCUEplFuJgpMgzL9ezPpyyVUtld+RGstKjaMiP+ ZlEWZhAY8/khq6mc1GTvE22VMk+mPnOXqzgihxUy0iBtWYdxFeCX8ljuTMd/IU4w G8qcDKI3W4dpmYxgMzlb =tgPX -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 8 23:01:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ED51A19FB for ; Sat, 8 Nov 2014 23:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA9dty9TCqyN for ; Sat, 8 Nov 2014 23:01:06 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 403831A19EB for ; Sat, 8 Nov 2014 23:01:06 -0800 (PST) Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id B3706F991 for ; Sun, 9 Nov 2014 02:01:03 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6017120087; Sat, 8 Nov 2014 10:20:42 -0500 (EST) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: References: <545C3175.5070204@amacapital.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sat, 08 Nov 2014 10:20:38 -0500 Message-ID: <87tx29g1mh.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WHvsAgF6HrH5bQ1X21964Q2Alq0 Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 07:01:09 -0000 --=-=-= Content-Type: text/plain On Fri 2014-11-07 01:21:26 -0500, Andy Lutomirski wrote: > If I buy a cert for *.my.domain, I want to be able to provision > foo.my.domain with some secret that lets it act as foo.my.domain but > not bar.my.domain. Since the PKIX people seem to be completely unable > to address this, pinning DH shares to a domain would solve the problem > without involving any PKIX changes. If we could provide this, it could be a very interesting operational win in the context of expensive/cumbersome CAs and medium-sized organizations with many services (internal and external). It would effectively allow a wildcard cert for a given domain to act as a domain-constained sub-CA, without getting into the X.509 weeds about domain constraints. The secret key material corresponding to the wildcard cert could be kept offline, and used to issue medium-term DH shares that are distributed to each service. Unfortunately, i don't see a way to deploy this effectively without putting the secret key material associated with the wildcard cert online for each service that needs to support legacy clients, which would make the security advantage moot. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUXjTHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc9tYQAIksO92c/UD7Vt2un8o4ArdE ZfvoXblOyPTJxVq7NsrI9bDync48oZ/ADOHTGfpPo4x1WTAR4PDHazc9kInV8JXx WWYiESF7CJolSxcL5rCdmhzLSC9eTLcVmg1iQkPfIr2iWi2AKkc+yaAzohRNu7Vc fgAcKZBEZQ4NNvAMcjFe3TrEJGkAvb31J+AAVf/sWkeR1yPsvk1DkdKQ2D475rxV hdmR/mVMFvFT09PcbMwSZsDiFhw+Vk4LEhHApsrwq6Q5cmIj4qUPrD2gDxeOcjDN hvndufOVj21beLdvU1HTPm08LHrmLXKxJUxaxN8rM229p3aBFBmW/Ic+umoMxOgq IZQehoaOHiGtkGo987PPBL4D1aq5SdRb46gmGI4QKwPEVrBX6TSPe5sB+2v2XB5U mVYtjo9jmoX4IaDZ9UIbo2EKG7vAAEdgxx+xWJcu9N4QqDI+sBK3w2DoADaKAmW9 dk0e8fIvL+fNLK3TPXWlvF2x+8ubXLfToYagm6RTrNjL0C7CQSCut3kLjxncRh5m C60K+zEqEHCMr+Q25URsYhu8miQUqnvug4MyRpDuUINQX76grE64FbrIphaS9Wph mHCxie/W2yh+w/xSMJ4GFoFcpyv79jm6ygWp+8Tz94qVGSKVPZ/hz0AT0BVGe1dg 70yr3es5E8s91dx9C+WW =XKnx -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 9 11:25:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7D21A6F3F for ; Sun, 9 Nov 2014 11:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgxKHbHSjSFr for ; Sun, 9 Nov 2014 11:25:28 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D66A1A3B9E for ; Sun, 9 Nov 2014 11:25:28 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id wn1so4782911obc.4 for ; Sun, 09 Nov 2014 11:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ybEfnkTX2KChgjQBRcFoIoXTDOqc1tuf/lSYYTr9pBc=; b=Lc9Cxtkh9Vr9qxpZU+6oR81XfjVxFBa20d0LyYrN+aWW38BThKdDmSRkWWPIHuMPqL jkaO7pK9AGIQ7ooD9YNQgctKzVhPazEnz4dH9NBhRk/5FEMT/BaFKERu6OVVgWYGb3YN avNesC45qWMQsn4MkK2cv32+0w5b9cc/NdJJp674bDTSKViaNVhZG/gIHuo2Nz+r3W/T 2SqB0Vjbe5/zwdBAs2MOINjetdLXbUWlVX0ATLz1z+8QUeEasCDaHoUvxQBVPd0XCz4V 6sUP2Vlk2gmZwTa0yOHwSLC39D7zosXtfxOyRfyP89e5IllVqr5T/bk5X/FxBoWoCvil bJ+g== MIME-Version: 1.0 X-Received: by 10.202.96.2 with SMTP id u2mr15336818oib.23.1415561127559; Sun, 09 Nov 2014 11:25:27 -0800 (PST) Received: by 10.60.42.210 with HTTP; Sun, 9 Nov 2014 11:25:27 -0800 (PST) In-Reply-To: <87r3xdfzi1.fsf@alice.fifthhorseman.net> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> Date: Sun, 9 Nov 2014 11:25:27 -0800 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uyGeZF25FZ8L3mPgBxw6IxgxnT0 Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:25:30 -0000 On 8 November 2014 08:06, Daniel Kahn Gillmor wrote: > To achieve this separation of purpose, though, we'd need to be able to > distinguish between certificates capable of anchoring the end entity in > a TLS 1.2 session and certificates capable of certifying a long-term > g^s. Making these distinguishable would probably require a new X.509v3 > extension, or extendedKeyUsage. There may still be operational advantages: you could issue the 1.2 cert with a shorter lifetime and the 1.3 cert with a longer one. Mucking with X.509 would probably make this harder than its worth, I think. From nobody Mon Nov 10 08:48:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38FB1A0146 for ; Mon, 10 Nov 2014 08:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLPmbNfb-7VB for ; Mon, 10 Nov 2014 08:48:29 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C19D1A014C for ; Mon, 10 Nov 2014 08:48:28 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAAGmQv6028738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 10 Nov 2014 11:48:27 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAAGmOWL020415 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2014 11:48:25 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 10 Nov 2014 17:48:24 +0100 Message-ID: <4414621.ICZNB95z47@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.1 (Linux/3.16.6-203.fc20.x86_64; KDE/4.14.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p6WxWjaeKp16czm-OSgCf-lLIf4 Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 16:48:30 -0000 On Saturday 08 November 2014 04:37:51 Yngve N. Pettersen wrote: > Hello all, > > Below is some statistics that I did not complete gathering until this > week, related to something I think was mentioned in the SCSV discussion > thread a couple of weeks ago: Some servers are apparently intolerant to > the SCSV, and attempts to connect using the SCSV will fail. > > My TLS Prober runs indicates that 2.5% of servers will fail a connection > using the SCSV when it is placed at the last position in the cipher suite > list, and 4.9% will fail if it is placed at the beginning of the list. I'm assuming you mean a test with ClientHello that otherwise includes ciphers that were verified as supported by server, includes the RC4 ciphers in the first 64 ciphers and is smaller than 256 bytes. In other words, tested in a way that won't trigger other common bugs. -- Regards, Hubert Kario From nobody Mon Nov 10 09:58:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509E11A06E9 for ; Mon, 10 Nov 2014 09:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XseqLo0-b4SK for ; Mon, 10 Nov 2014 09:58:19 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7290D1A038B for ; Mon, 10 Nov 2014 09:58:18 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Nov 2014 12:58:14 -0500 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 10 Nov 2014 12:58:13 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Mon, 10 Nov 2014 12:58:12 -0500 From: Dan Brown To: "'hugo@ee.technion.ac.il'" , "'tls@ietf.org'" Thread-Topic: rm Hello.random w/ (EC)DHE [was [TLS] OPTLS: Signature-less TLS 1.3] Thread-Index: Ac/9DaZQA7v0PjC5Tdu428nwfdryOw== Date: Mon, 10 Nov 2014 17:58:12 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D3_01CFFCE5.FBB27280" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GWU1jMUTjsGC8zXf699nZxEnvPA Cc: "'hoeteck@alum.mit.edu'" Subject: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: Signature-less TLS 1.3] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 17:58:22 -0000 ------=_NextPart_000_00D3_01CFFCE5.FBB27280 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D4_01CFFCE5.FBB27280" ------=_NextPart_001_00D4_01CFFCE5.FBB27280 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable When using (EC)DHE (inc. OPTLS below), the TLS random nonces = (ClientHello.random and ServerHello.random) seem redundant (unless one = re-uses ephemeral secret keys (but then maybe a counter or secure time = would be almost as good a nonce as a random in this case), or perhaps = for some other reason I=E2=80=99m missing), and perhaps even a point of = fragility (e.g. if a common generator for nonces and keys is weak, or = corrupted). So, does it make sense to remove these Hello.randoms, when = using (EC)DHE, or to replace them with something milder, like = Hello.time, Hello.counter, or just Hello.nonce? =20 Best regards, =20 Dan =20 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hugo Krawczyk Sent: Friday, October 31, 2014 8:54 PM To: tls@ietf.org Cc: Hoeteck Wee Subject: [TLS] OPTLS: Signature-less TLS 1.3 =20 During the TLS interim meeting of last week (Oct 22 2014) I suggested = that TLS 1.3 should abandon signature-based authentication (other than for = certificates) and be based solely on a combination of ephemeral Diffie-Hellman for PFS = and static Diffie-Hellman for authentication. This has multiple benefits = including major performance gain (by replacing the per-handshake RSA signature by = the server with a much cheaper elliptic curve exponentiation), compatibility = with the mechanisms required for forward secrecy, natural accommodation of a = 0-RTT option, and a simple extension without signatures for client = authentication. Below I present a schematic representation of the proposed protocol = referred to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. =20 The presentation is sketchy and omits the exact procedure for key = derivation. The latter is a crucial component for the security of the protocol, but=20 before getting into these details we want to get a sense of whether the = WG is interested in this approach. In the meantime, Hoeteck Wee and myself are = working on the details of the protocol and the security proof. We describe a setting with optional 0-RTT and server-only = authentication. Client authentication can be added as a further option or as an = extension (similar to the current 1.3 proposal) - see below. NOTATION AND TERMINOLOGY: [K] symbols represent pointers to key material whose exact derivation is = not included here except for specifying the basic DH values from which the = key is derived (actual derivation will include further information similar to = the extended hash mechanisms or SessionHash proposal considered for 1.3).=20 Asterisks represent optional fields that the WG can decide to leave as = optional, mandatory, or simply remove without changing the core cryptographic = security of the protocol. All references to encryption mean "authenticated = encryption" using the encrypt-then-mac paradigm (or any other secure AEAD = mechanism). =20 KeyShare's represent ephemeral Diffie-Hellman values exchanged by the = parties. All the public key and Diffie-Hellman operations are assumed to happen = over a cyclic group with generator g of order q (typically implemented by an = elliptic curve group). We use multiplicative notation where ^ denotes = exponentiation as in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), = etc. Omitted from the current high level description is a mechanism for = testing group membership of DH values or cofactor exponentiation (the specific = mechanism depends on the group type and is typically very efficient for elliptic = curves). SERVER PUBLIC KEY AND CERTIFICATE: The server has a long term private-public key pair denoted by (s,g^s) = where=20 s is uniform random in [0..q-1] (we refer to s and g^s as "static = keys").=20 We assume that the server has a certificate that includes the server's = public key g^s and a CA-signed binding of this key to the server's identity. We discuss the implementation of such certificates below. PROTOCOL OPTLS: ClientHello ClientKeyShare=20 ClientData* [K0] --------> ServerHello =20 ServerKeyShare =20 ServerCertificate* [K1] ServerFinished [K2] <-------- ServerData* [K2] ClientFinished* [K2] --------> Protected Application Data [K3] <-------> 1-RTT CASE: The basic 1-RTT case omits the ClientData* field. It includes a = ClientKeyShare g^x and a ServerKeyShare g^y and an optional (encrypted) server = certificate.=20 If the certificate is sent (it can be omitted if the client has = indicated that it knows the server key as in the case in the 0-RTT scenario) and is = encrypted, the encryption key K1 is derived from g^{xy}. Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is = used to authenticate-encrypt the ServerFinished and ClientFinished messages = (which include a hash of the previous traffic) and to encrypt data from the = server if such data is piggybacked to the second message. Key K3 is the "application key" used to derive key material for = protection of application data. This key material will include (directional) = Authenticated Encryption keys and, possibly, keys for derivation of further re-key = material. K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its = derivation will be different than K2, e.g., using a separating key expansion = technique. SUPPORT FOR 0-RTT:=20 The above protocol is compatible with a 0-RTT protocol such as QUIC. In = this case, the client is assumed to have information about the server's = public key and other security parameters. The server is assumed to have some = mechanism in place for detecting replay (e.g., via timestamps, stored client nonces, = etc.). The resulting protocol is as described above where the ClientData field = is sent encrypted under key K0 derived from g^{xs}. =20 The rest of the protocol is identical to the above. =20 Note: In this case, ServerCertificate is not sent as the client had to = know the server's public key before the first message (one can imagine a = setting where the server may send a different certificate in the second message = - if desired, this can be accommodated too as an option or extension). CLIENT AUTHENTICATION:=20 Client authentication can be supported via an option or extension. It = would include a client certificate for a static DH key g^c sent in the third = message=20 (the certificate can be encrypted under key K2 to provide client's = identity protection). In this case, the key for computing the ClientFinished = message and the application key K3 would be derived from a combination of the values = g^xy, g^xs, g^yc (and possibly also g^{cs}).=20 NOTES: Note on Finished messages: The above spec sets ServerFinished as = mandatory and ClientFinished as optional. The latter option is needed for a 1-RTT = protocol. In principle, both Finished messages could be omitted and still obtain = security via implicit authentication (assuming the inputs to key derivation are = chosen appropriately). But given the advantages of ServerFinished for providing explicit authentication, key confirmation, and active forward secrecy = (see below), it seems advisable to always include it. Including = ClientFinished provides key confirmation from client and also explicit client = authentication when client certificate is included. ClientFinished also provides = Universal Composable (UC) security (this is a result of the Canetti-Krawczyk proof = that=20 CK security implies UC security when a client confirmation step is = included). =20 Note on certificates: Since in current practice servers hold = certificates for RSA signature keys rather than for static DH keys, the certificate field = in the above protocol will be implemented by a pair consisting of (i) the = server's RSA signature certificate and (ii) the server's signature using this RSA key = on the server's static public DH key g^s. The latter signature by the server is performed only when a new static DH key is created (how often this = happens and how many such keys are created is completely up to the server - it has = the advantage that these keys can be changed often to increase security = against leaked keys). This use of RSA also enjoys the high efficiency of RSA verification for the client. =20 The handling of Client certificates would be similar. Note on forward security (a.k.a. as PFS for Perfect Forward Security):=20 PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys. The meaning of PFS is that an attacker that finds the (long-term) static private keys of the parties cannot compromise past session keys. Without = the ServerFinished message the above protocol ensures forward secrecy = against passive attackers (i.e., for sessions where the attacker did not choose = g^y). With ServerFinished, PFS holds also against active attackers. A similar consideration applies to ClientFinished. Client certificates in the first message: We note that in cases where = client certificates can be sent in the clear in the first message of the = protocol, one can provide PFS and mutual authentication in a 1-RTT at essentially the = same cost of an unauthenticated DH exchange (i.e., a cost of little more than = two exponentiations). In such a setting one can also obtain mutual = authentication in a 0-RTT protocol (with forward secrecy with respect to the client's = key). =20 These options, however, require HMQV-like mechanisms and may raise IP = issues (this can be investigated further if the WG is interested). ------=_NextPart_001_00D4_01CFFCE5.FBB27280 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

When using (EC)DHE (inc. OPTLS below), the TLS random nonces = (ClientHello.random and ServerHello.random) seem redundant (unless one = re-uses ephemeral secret keys (but then maybe a counter or secure time = would be almost as good a nonce as a random in this case), or perhaps = for some other reason I=E2=80=99m missing), and perhaps even a point of = fragility (e.g. if a common generator for nonces and keys is weak, or = corrupted). So, does it make sense to remove these Hello.randoms, when = using (EC)DHE, or to replace them with something milder, like = Hello.time, Hello.counter, or just Hello.nonce?

 

Best regards,

 

Dan

 

From:= = TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hugo = Krawczyk
Sent: Friday, October 31, 2014 8:54 PM
To: = tls@ietf.org
Cc: Hoeteck Wee
Subject: [TLS] OPTLS: = Signature-less TLS 1.3

 

During the TLS interim = meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should = abandon signature-based authentication (other than for = certificates)
and be based solely on a combination of ephemeral = Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. = This has multiple benefits including
major performance gain (by = replacing the per-handshake RSA signature by the
server with a much = cheaper elliptic curve exponentiation), compatibility with
the = mechanisms required for forward secrecy, natural accommodation of a = 0-RTT
option, and a simple extension without signatures for client = authentication.

Below I present a schematic representation of the = proposed protocol referred
to as OPTLS where OPT stands for OPTimized = and/or for One-Point-Three. 
The presentation is sketchy and = omits the exact procedure for key derivation.
The latter is a crucial = component for the security of the protocol, but
before getting into = these details we want to get a sense of whether the WG is
interested = in this approach. In the meantime, Hoeteck Wee and myself are =
working on the details of the protocol and the security = proof.

We describe a setting with optional 0-RTT and server-only = authentication.
Client authentication can be added as a further = option or as an extension
(similar to the current 1.3 proposal) - see = below.

NOTATION AND TERMINOLOGY:

[K] symbols represent = pointers to key material whose exact derivation is not
included here = except for specifying the basic DH values from which the key = is
derived (actual derivation will include further information = similar to the
extended hash mechanisms or SessionHash proposal = considered for 1.3).
Asterisks represent optional fields that the WG = can decide to leave as optional,
mandatory, or simply remove without = changing the core cryptographic security of
the protocol. All = references to encryption mean "authenticated = encryption"
using the encrypt-then-mac paradigm (or any other = secure AEAD mechanism). 

KeyShare's represent ephemeral = Diffie-Hellman values exchanged by the parties.
All the public key = and Diffie-Hellman operations are assumed to happen over a
cyclic = group with generator g of order q (typically implemented by an = elliptic
curve group). We use multiplicative notation where ^ denotes = exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of = the scalars x and y), etc.
Omitted from the current high level = description is a mechanism for testing group
membership of DH values = or cofactor exponentiation (the specific mechanism
depends on the = group type and is typically very efficient for elliptic = curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has = a long term private-public key pair denoted by (s,g^s) where
s is = uniform random in [0..q-1] (we refer to s and g^s as "static = keys").
We assume that the server has a certificate that = includes the server's public
key g^s and a CA-signed binding of this = key to the server's identity.
We discuss the implementation of such = certificates below.

PROTOCOL = OPTLS:

ClientHello
ClientKeyShare
ClientData* = [K0]       = -------->
         &nb= sp;           &nbs= p;            = ;         = ServerHello   =
           &nb= sp;           &nbs= p;            = ;       ServerKeyShare  =
           &nb= sp;           &nbs= p;            = ;       ServerCertificate* = [K1]
           = ;            =             &= nbsp;       ServerFinished = [K2]
           = ;            = <--------           = ServerData* [K2]
ClientFinished* [K2]   = -------->


        &= nbsp;   Protected Application Data = [K3]
           = ;            = <------->



1-RTT CASE:

The basic 1-RTT case = omits the ClientData* field. It includes a ClientKeyShare
g^x and a = ServerKeyShare g^y and an optional (encrypted) server certificate. =
If the certificate is sent (it can be omitted if the client has = indicated that
it knows the server key as in the case in the 0-RTT = scenario) and is encrypted,
the encryption key K1 is derived from = g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and = g^{xy}. It is used to
authenticate-encrypt the ServerFinished and = ClientFinished messages (which
include a hash of the previous = traffic) and to encrypt data from the server if
such data is = piggybacked to the second message.

Key K3 is the = "application key" used to derive key material for protection = of
application data.  This key material will include = (directional) Authenticated
Encryption keys and, possibly, keys for = derivation of further re-key material.
K3 is computed from  both = g^{xs} and g^{xy} similarly to K2, but its derivation
will be = different than K2, e.g., using a separating key expansion = technique.

SUPPORT FOR 0-RTT:

The above protocol is = compatible with a 0-RTT protocol such as QUIC. In this
case, the = client is assumed to have information about the server's public = key
and other security parameters. The server is assumed to have some = mechanism in
place for detecting replay (e.g., via timestamps, stored = client nonces, etc.).
The resulting protocol is as described above = where the ClientData field is sent
encrypted under key K0 derived = from g^{xs}. 
The rest of the protocol is identical to the = above. 
Note: In this case, ServerCertificate is not sent as = the client had to know
the server's public key before the first = message (one can imagine a setting
where the server may send a = different certificate in the second message - if
desired, this can be = accommodated too as an option or extension).

CLIENT = AUTHENTICATION:

Client authentication can be supported via an = option or extension. It would
include a client certificate for a = static DH key g^c sent in the third message
(the certificate can be = encrypted under key K2 to provide client's identity
protection). In = this case, the key for computing the ClientFinished message and
the = application key K3 would be derived from a combination of the values = g^xy,
g^xs, g^yc (and possibly also g^{cs}). =

NOTES:

Note on Finished messages: The above spec sets = ServerFinished as mandatory and
ClientFinished as optional. The = latter option is needed for a 1-RTT protocol.
In principle, both = Finished messages could be omitted and still obtain security
via = implicit authentication (assuming the inputs to key derivation are = chosen
appropriately). But given the advantages of ServerFinished for = providing
explicit authentication, key confirmation, and active = forward secrecy (see
below), it seems advisable to always include it. = Including ClientFinished
provides key confirmation from client and = also explicit client authentication
when client certificate is = included. ClientFinished also provides Universal
Composable (UC) = security (this is a result of the Canetti-Krawczyk proof that
CK = security implies UC security when a client confirmation step is = included). 

Note on certificates: Since in current practice = servers hold certificates for
RSA signature keys rather than for = static DH keys, the certificate field in the
above protocol will be = implemented by a pair consisting of (i) the server's RSA
signature = certificate and (ii) the server's signature using this RSA key on = the
server's static public DH key g^s. The latter signature by the = server is
performed only when a new static DH key is created (how = often this happens and
how many such keys are created is completely = up to the server - it has the
advantage that these keys can be = changed often to increase security against
leaked keys). This use of = RSA also enjoys the high efficiency of RSA
verification for the = client. 
The handling of Client certificates would be = similar.

Note on forward security (a.k.a. as PFS for Perfect = Forward Security):
PFS is provided by the (mandatory) use of = ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker = that finds the (long-term) static
private keys of the parties cannot = compromise past session keys. Without the
ServerFinished message the = above protocol ensures forward secrecy against
passive attackers = (i.e., for sessions where the attacker did not choose g^y).
With = ServerFinished, PFS holds also against active attackers.  A = similar
consideration applies to ClientFinished.

Client = certificates in the first message: We note that in cases where = client
certificates can be sent in the clear in the first message of = the protocol, one
can provide PFS and mutual authentication in a = 1-RTT at essentially the same
cost of an unauthenticated DH exchange = (i.e., a cost of little more than two
exponentiations). In such a = setting one can also obtain mutual authentication in
a 0-RTT protocol = (with forward secrecy with respect to the client's key). 
These = options, however, require HMQV-like mechanisms and may raise IP issues = (this
can be investigated further if the WG is = interested).

------=_NextPart_001_00D4_01CFFCE5.FBB27280-- ------=_NextPart_000_00D3_01CFFCE5.FBB27280 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTExMDE3NTgxMVowIwYJKoZIhvcNAQkEMRYEFKlI D0NO9N3fTLBsg0qMPLJr6tX3MG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYBCmmk55guZi5M2e6gxpjNbzZ3H1WvS 4ad2cSFAdM42Ur1/yO+CbjIujDf8Ay5vSuBN3j9KDn2VkRJdftmNbpm+dicWsl6i92xy1NwTYCZf zCVtowpUuGsB852McC+uZGIqSNUhGeppDNrG65KYMdqJM3t1AU2Q1nQ07X5aJV5ieAAAAAAAAA== ------=_NextPart_000_00D3_01CFFCE5.FBB27280-- From nobody Mon Nov 10 11:05:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927D91A9172 for ; Mon, 10 Nov 2014 11:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsNWlGBd93qT for ; Mon, 10 Nov 2014 11:05:11 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197181A9244 for ; Mon, 10 Nov 2014 11:04:58 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id n15so6438142lbi.32 for ; Mon, 10 Nov 2014 11:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w5eYrhdFZXMhjTp9Q7ZMrE/VX/sqOsF1paSkCkQUpBc=; b=i+/Y8f4lztLlQICTN/JPr2ioaRYhQiWQPAIUUQcOfuDb7DcOq9JUsE3tdKpoGgWQwQ xvLK8DKfmP9F2ATkGCEOmbaPAXHwm+ocdtKh1vhhVrB48A2HF354ivPs0wFKhueb7a21 UIcQ6cperjmtTXQ0xlODQ6WvUVY0VLGyTwQUA6SYEiVmXchciuaeOrwlUZZZYN2dotL0 ndZ66I1YUZ6qWVFCYSaxOHBTmCWuN6kB5CLWKy8F2mf4Vl4US44arPgBlEr55foifqq7 urolRnOctBPm9TaNeo6YMC05J8emzKvtWZA/J/jbtS1GY/40XuEFF75xZhhe4txAO/yY eKJQ== MIME-Version: 1.0 X-Received: by 10.152.45.1 with SMTP id i1mr31687049lam.7.1415646294366; Mon, 10 Nov 2014 11:04:54 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 11:04:54 -0800 (PST) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net> Date: Mon, 10 Nov 2014 11:04:54 -0800 Message-ID: From: Martin Thomson To: Dan Brown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z6jXze3arp7tDY8JZzDAlaWyhXA Cc: "hoeteck@alum.mit.edu" , "tls@ietf.org" Subject: Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: Signature-less TLS 1.3] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:05:12 -0000 On 10 November 2014 09:58, Dan Brown wrote: > When using (EC)DHE (inc. OPTLS below), the TLS random nonces > (ClientHello.random and ServerHello.random) seem redundant (unless one > re-uses ephemeral secret keys (but then maybe a counter or secure time wo= uld > be almost as good a nonce as a random in this case), or perhaps for some > other reason I=E2=80=99m missing), and perhaps even a point of fragility = (e.g. if a > common generator for nonces and keys is weak, or corrupted). So, does it > make sense to remove these Hello.randoms, when using (EC)DHE, or to repla= ce > them with something milder, like Hello.time, Hello.counter, or just > Hello.nonce? Aren't they still highly relevant in the resumption cases? In which case, a new source of entropy ensures that two sessions resumed from the same base don't have synchronized keys. From nobody Mon Nov 10 11:06:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB141A9146 for ; Mon, 10 Nov 2014 11:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHrnmNqvatnl for ; Mon, 10 Nov 2014 11:06:12 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5C91A9172 for ; Mon, 10 Nov 2014 11:05:53 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id A790733D1A3; Mon, 10 Nov 2014 19:05:51 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Dan Brown References: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net> From: Geoffrey Keating Date: 10 Nov 2014 11:05:51 -0800 In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net> Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/na3Hg2bqS2q0l58wXGyM5l9zkYc Cc: "'hoeteck@alum.mit.edu'" , "'tls@ietf.org'" Subject: Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: Signature-less TLS 1.3] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:06:13 -0000 Dan Brown writes: > When using (EC)DHE (inc. OPTLS below), the TLS random nonces > (ClientHello.random and ServerHello.random) seem redundant (unless > one re-uses ephemeral secret keys (but then maybe a counter or > secure time would be almost as good a nonce as a random in this > case), or perhaps for some other reason I=E2=80=99m missing), and perhaps > even a point of fragility (e.g. if a common generator for nonces and > keys is weak, or corrupted). So, does it make sense to remove these > Hello.randoms, when using (EC)DHE, or to replace them with something > milder, like Hello.time, Hello.counter, or just Hello.nonce? The client's nonce is its way of ensuring that the server has generated a fresh signature on the server's DHE parameters. However you could achieve the same thing by having the server sign both its and the client's DHE parameters, effectively treating them as a nonce. Another thing the nonces do is ensure that even if the DHE exchange is controlled by one side, the master secret (and therefore the connection identification) is still different between different connections from the client. To preserve this you would need to ensure all the DHE parameters are valid. This is necessary to prevent a triple handshake style of attack. From nobody Mon Nov 10 11:24:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4A71A0161 for ; Mon, 10 Nov 2014 11:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.134 X-Spam-Level: ** X-Spam-Status: No, score=2.134 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ov8nTlxfNDh for ; Mon, 10 Nov 2014 11:24:19 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96A1A015B for ; Mon, 10 Nov 2014 11:24:06 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 644552005D00D; Mon, 10 Nov 2014 11:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=YHOuH7G742STMFK5Gb5IFmUvAOs=; b=hZPqGi/6pGb 9MZhCMRxE/LJfhaqt5WQGkCQsQZghzcRiWH7CjIluZU2ZAR/T5GBlXY8QXsY+zE2 TDTX2OW24bXgQMCyK2L+4d7ESTwk6KEYB2rx1Sx1ZfzQHudnqE2ELRbl5evpgwiT j0/rNqKz833EE0sNJrp4VeswM2hkVCtk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id B6B1D2005D00B; Mon, 10 Nov 2014 11:24:05 -0800 (PST) Date: Mon, 10 Nov 2014 13:24:04 -0600 From: Nico Williams To: Dan Brown Message-ID: <20141110192402.GD3412@localhost> References: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6R8j6rCb-AxzCejjwNyl0SkA8yU Cc: "'hoeteck@alum.mit.edu'" , "'tls@ietf.org'" Subject: Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: Signature-less TLS 1.3] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:24:20 -0000 On Mon, Nov 10, 2014 at 05:58:12PM +0000, Dan Brown wrote: > When using (EC)DHE (inc. OPTLS below), the TLS random nonces > (ClientHello.random and ServerHello.random) seem redundant (unless one > re-uses ephemeral secret keys (but then maybe a counter or secure time > would be almost as good a nonce as a random in this case), or perhaps > for some other reason I=E2=80=99m missing), and perhaps even a point of > fragility (e.g. if a common generator for nonces and keys is weak, or > corrupted). So, does it make sense to remove these Hello.randoms, when > using (EC)DHE, or to replace them with something milder, like > Hello.time, Hello.counter, or just Hello.nonce? The main problem with the hello randoms today is that they are big. This is what made Dual_EC deadly for TLS. Besides, large nonces also create a large covert channel. Larger nonces make sense for plain PSK, static DH, and session resumption. For RSA key transport I don't see the point of larger nonces. For (EC)DHE small nonces help the briefly reused server-side ephemeral private key case, which is nice to have. 64-bit nonces should suffice for the key exchanges that need larger nonces, no? 32-bit nonces should suffice for the key exchanges that need smaller or no nonces. The client should send a nonce of size matching the largest needed by any of the ciphersuites it offers. The server should send a nonce whose size is given by the selected ciphersuite. If variable size nonces are a problem (e.g., fingreprinting), then send large nonces but set unneeded bits to one of a small set of suitable constant patterns. Nico --=20 From nobody Mon Nov 10 12:02:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A811AC3E3 for ; Mon, 10 Nov 2014 12:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn9D0U8lBfX8 for ; Mon, 10 Nov 2014 12:02:23 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2413A1A90CC for ; Mon, 10 Nov 2014 12:01:26 -0800 (PST) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0M3uUc-1Y6HHV3iPS-00raNy; Mon, 10 Nov 2014 21:01:24 +0100 Received: by mail-oi0-f53.google.com with SMTP id a141so5908768oig.40 for ; Mon, 10 Nov 2014 12:01:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.102.211 with SMTP id fq19mr29226432oeb.2.1415649682508; Mon, 10 Nov 2014 12:01:22 -0800 (PST) Received: by 10.60.32.42 with HTTP; Mon, 10 Nov 2014 12:01:22 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 21:01:22 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e01160a2e73d495050786a0c4 X-Provags-ID: V02:K0:Dps7oU+SGTrllpPCTrjSh5X5fa2tP0XQz5/gKw9BByg fI42A81BlT7WOU6ekQ/n2u9u3BZGDW19ModsydQWzRcUpSAPwj YstJW0m/eSL8rnrpYDBSL6ZmjZWUB79qtY2ErAOKV6SaC57PEN AkoLMj4k6/Cb8RAicd4FNapWQS4I1p21jlFlyD3/Kwe0PWIHCk 49GjJa4lbh86wgF8pFvYi8hx36KYgfk0RGQ9frem/v2Nv8Qu+s HIeW8lXbCFtZ2dWnKaGRcA1eT9YcNtjS9SpPuNxP7MB2U0DI+4 0NCIM4WjseE0GN4UisLtU86bX3um7+gGRPE27/VhWmhV7IUkui MuqUUh14Jq35JB0cHdzZ/y5K219R0iaDcpXPDZ069K1tonHO0V O2spTBgZSceBAYHOIv8k+oONqUAmK+EY2PxjRxvCZ0Wd/ZwCch D0zuX X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZAgf8r-DjMmZBzL2VT5QL-t7pmA Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:02:28 -0000 --089e01160a2e73d495050786a0c4 Content-Type: text/plain; charset=UTF-8 Thanks for the comments! > "The fallback SCSV defined in this document is not suitable substitute for > proper TLS version negotiation. TLS implementations need to properly handle > TLS version negotiation and extensibility mechanisms to avoid the security > issues and connection delays associated with fallback mechanisms." > Added to the introduction (but s/fallback mechanisms/fallback retries/). "If the client receives an inappropriate_fallback alert then the server > intends to support a higher version and the client should retry with the > highest version it supports. Implementors should review the security > considerations section before deciding to make a connection with a lower > version without including the TLS_FALLBACK_SCSV. > Added to Section 4: " [...] SHOULD include the TLS_FALLBACK_SCSV cipher suite value in ClientHello.cipher_suites; see Section 6 for security considerations for this recommendation." and "Fallback retries could be caused by events such as network glitches, and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may receive an inappropriate_fallback alert in response, indicating that the server supports a higher protocol version. Thus, if a client intends to use retries to work around network glitches, it should then retry with the highest version it supports." > [...] However, it is important to remember that omitting the > TLS_FALLBACK_SCSV leaves the TLS connection vulnerable to version rollback > so it is not recommended to omit the SCSV unless the negotiated version > provides an acceptable level of protection. > Added to Security Considerations: "It is important to remember that omitting TLS_FALLBACK_SCSV enables downgrade attacks, so implementors must take into account whether the protocol version given by ClientHello.client_version still provides an acceptable level of protection." 3. The introduction should indicate that the Fallback SCSV also applies to > DTLS. > New wording in the introduction: "This specification applies to implementations of TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]." > 4. The IANA considerations section needs to allocate the number for the > alert: > Oops, good point. Done. Bodo --089e01160a2e73d495050786a0c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks for the comments!

= =C2=A0
"The fallback SCSV defined in this docu= ment is not suitable substitute for proper TLS version negotiation. TLS imp= lementations need to properly handle TLS version negotiation and extensibil= ity mechanisms to avoid the security issues and connection delays associate= d with fallback mechanisms."

<= div>Added to the introduction (but s/fallback mechanisms/fallback retries/)= .


"If the client= receives an inappropriate_fallback alert then the server intends to suppor= t a higher version and the client should retry with the highest version it = supports. =C2=A0 Implementors should review the security considerations sec= tion before deciding to make a connection with a lower version without incl= uding the TLS_FALLBACK_SCSV. =C2=A0

Added to Section 4:

"=C2=A0[...] SHOULD= include the TLS_FALLBACK_SCSV cipher suite value in ClientHello.cipher_sui= tes; see Section 6 for security =C2=A0considerations for this recommendatio= n."

and

"Fallba= ck retries could be caused by events such as network glitches, and a client= including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may receive an in= appropriate_fallback alert in response, indicating that the server supports= a higher protocol version. Thus, if a client intends to use retries to wor= k around network glitches, it should then retry with the highest version it= supports."

=C2=A0
[...]=C2=A0However, it is important t= o remember that omitting the TLS_FALLBACK_SCSV leaves the TLS connection vu= lnerable to version rollback so it is not recommended to omit the SCSV unle= ss the negotiated version provides an acceptable level of protection. =C2= =A0

Added to Security Consider= ations:

"It is important to remember that omi= tting TLS_FALLBACK_SCSV enables downgrade attacks, so implementors must tak= e into account whether the protocol version given by ClientHello.client_ver= sion still provides an acceptable level of protection."

=

3.=C2=A0 The introduction should in= dicate that the Fallback SCSV also applies to DTLS. =C2=A0

New wording in the introduction:
"This specification applies to implementations of TLS 1.0 = [RFC2246], TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations= of DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]."

=C2=A0
4.=C2=A0 The IANA considerations section = needs to allocate the number for the alert:
<= br>
Oops, good point. Done.

Bodo
=C2=A0
--089e01160a2e73d495050786a0c4-- From nobody Mon Nov 10 12:08:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5423A1AC446; Mon, 10 Nov 2014 12:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9XR3F9diPWk; Mon, 10 Nov 2014 12:08:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0161ACDAF; Mon, 10 Nov 2014 12:07:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 12:07:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K7yaMsBj2tjlomB8pCUgRm7UTkM Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:08:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks Authors : Bodo Moeller Adam Langley Filename : draft-ietf-tls-downgrade-scsv-01.txt Pages : 8 Date : 2014-11-10 Abstract: This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 10 12:17:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54DF1ACDC3 for ; Mon, 10 Nov 2014 12:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q1xMSodBZls for ; Mon, 10 Nov 2014 12:17:41 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535C81A6F98 for ; Mon, 10 Nov 2014 12:17:41 -0800 (PST) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MbK2G-1XXURy1t5w-00InJl; Mon, 10 Nov 2014 21:17:38 +0100 Received: by mail-oi0-f46.google.com with SMTP id g201so6007037oib.33 for ; Mon, 10 Nov 2014 12:17:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.89.194 with SMTP id bq2mr28916356obb.12.1415650656234; Mon, 10 Nov 2014 12:17:36 -0800 (PST) Received: by 10.60.32.42 with HTTP; Mon, 10 Nov 2014 12:17:36 -0800 (PST) Date: Mon, 10 Nov 2014 21:17:36 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013cc45e7db3b6050786dad8 X-Provags-ID: V02:K0:aZB/gkG7NvMk7UAszPazoYGwBitwET7IAQ7fp4/Gxh4 IDcPnkcYFJNm9U6BWvkGA4ujhTGfYBHcpVMeTh4wpKYRPLJ6dz yHYw/bq0VnHcetJKR5Xt1G2rOE9xBEokNOQflptfKpO9EYy4Wa mAGrk3dTaKDi0fbu82silIvpTveyM1YZkYd8dlRM8EiaGRFPEK iNg10AR69CN6CWgKT0YHtW3yPcNQphO2/XPvDRzte1TAAWX8xE Ghdddvlg6C1OWa/4QzyBWIOeH58XSyORnLyoemkSj0NRtld441 afAGNsXvZAIWcKmZCI9HME0PY+Tj1fbfLuz68vcKD5Vv1IICKA tRB2jr8Kn8YwOhDOVQdqRRXiUyipCp9QyP8tm13yGTkHDilTJl bP1TdHwC1viECC4Dyz2MbPiz2a0sBfjajxtYjD62AC60i+Xg1w cVXhM X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N-0cAGlBqBD7Z5oObqbE6ZMrGus Cc: Adam Langley , Nagendra Modadugu Subject: [TLS] Adopt False Start spec as WG document? (draft-bmoeller-tls-falsestart-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:17:43 -0000 --089e013cc45e7db3b6050786dad8 Content-Type: text/plain; charset=UTF-8 At the TLS Interim meeting in Paris, I was asked to update the False Start Internet-Draft ( http://www.ietf.org/proceedings/interim/2014/10/21/tls/minutes/minutes-interim-2014-tls-3), first in the light of TLS_FALLBACK_SCSV, and second because it describes behavior deployed by multiple vendors and it would be good to have this described in an (Experimental) RFC. draft-bmoeller-tls-falsestart-01 is now available (see below). I'm asking the Working Group to consider adopting this document as a Working Group Internet-Draft. Bodo A new version of I-D, draft-bmoeller-tls-falsestart-01.txt has been successfully submitted by Bodo Moeller and posted to the IETF repository. Name: draft-bmoeller-tls-falsestart Revision: 01 Title: Transport Layer Security (TLS) False Start Document date: 2014-11-10 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-bmoeller-tls-falsestart-01.txt Status: https://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ Htmlized: http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-bmoeller-tls-falsestart-01 Abstract: This document specifies an optional behavior of TLS implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. The TLS False Start feature leads to a latency reduction of one round trip for certain handshakes. --089e013cc45e7db3b6050786dad8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the TLS Interim meeting in Paris, I was asked to u= pdate the False Start Internet-Draft (http://www= .ietf.org/proceedings/interim/2014/10/21/tls/minutes/minutes-interim-2014-t= ls-3), first in the light of TLS_FALLBACK_SCSV, and second because it d= escribes behavior deployed by multiple vendors and it would be good to have= this described in an (Experimental) RFC.

draft-bm= oeller-tls-falsestart-01 is now available (see below). I'm asking the W= orking Group to consider adopting this document as a Working Group Internet= -Draft.

Bodo



A new version of I-D, draft-bmoeller-tls-falsestart-01.txt
has been successfully submitted by Bodo Moeller and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bmoeller-tls-falsestart=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Transport Layer Security (TLS) Fal= se Start
Document date:=C2=A0 2014-11-10
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttp://www.ietf.org/internet-drafts/draft-bmoeller-tls-falsestart-01.txt=
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatra= cker.ietf.org/doc/draft-bmoeller-tls-falsestart/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/ht= ml/draft-bmoeller-tls-falsestart-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-bmoeller-tls-falsestart-01

Abstract:
=C2=A0 =C2=A0This document specifies an optional behavior of TLS implementa= tions,
=C2=A0 =C2=A0dubbed False Start.=C2=A0 It affects only protocol timing, not= on-the-wire
=C2=A0 =C2=A0protocol data, and can be implemented unilaterally.=C2=A0 The = TLS False
=C2=A0 =C2=A0Start feature leads to a latency reduction of one round trip f= or
=C2=A0 =C2=A0certain handshakes.
--089e013cc45e7db3b6050786dad8-- From nobody Mon Nov 10 12:19:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD8E1ACDF6 for ; Mon, 10 Nov 2014 12:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzdncdGOSdHr for ; Mon, 10 Nov 2014 12:19:27 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A057E1A00F9 for ; Mon, 10 Nov 2014 12:19:27 -0800 (PST) Received: from 151.170.251.212.customer.cdi.no ([212.251.170.151]:56903 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XnvQr-0001xH-O1; Mon, 10 Nov 2014 21:19:25 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "Hubert Kario" References: <4414621.ICZNB95z47@pintsize.usersys.redhat.com> Date: Mon, 10 Nov 2014 21:19:03 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <4414621.ICZNB95z47@pintsize.usersys.redhat.com> User-Agent: Opera Mail/12.17 (Win32) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ATCgPncFSlPbp3NoSRoN1EdxWWc Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:19:31 -0000 On Mon, 10 Nov 2014 17:48:24 +0100, Hubert Kario wrote: > On Saturday 08 November 2014 04:37:51 Yngve N. Pettersen wrote: >> Hello all, >> >> Below is some statistics that I did not complete gathering until this >> week, related to something I think was mentioned in the SCSV discussion >> thread a couple of weeks ago: Some servers are apparently intolerant to >> the SCSV, and attempts to connect using the SCSV will fail. >> >> My TLS Prober runs indicates that 2.5% of servers will fail a connection >> using the SCSV when it is placed at the last position in the cipher >> suite >> list, and 4.9% will fail if it is placed at the beginning of the list. > > I'm assuming you mean a test with ClientHello that otherwise includes > ciphers > that were verified as supported by server, includes the RC4 ciphers in > the > first 64 ciphers and is smaller than 256 bytes. > > In other words, tested in a way that won't trigger other common bugs. The Client Hellos in this case are usually smaller than 160 bytes, and includes the same cipher suites and extensions that the server was tested with originally to determine support for the TLS version and support for extensions. IOW, the Client Hello is just 2 bytes longer than those original Hellos. For reference, 13% of the servers intolerant against the SCSV at the end were also failing a 256 byte Hello, and 8% of those failing at the start also failed the 256 byte test. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Mon Nov 10 12:29:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DF11ACE77 for ; Mon, 10 Nov 2014 12:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCOmdXjyIp4v for ; Mon, 10 Nov 2014 12:28:57 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9771ACE7D for ; Mon, 10 Nov 2014 12:28:23 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0MMJXF-1XvJxx1wDN-0086cG; Mon, 10 Nov 2014 21:28:20 +0100 Received: by mail-ob0-f182.google.com with SMTP id nt9so6987500obb.27 for ; Mon, 10 Nov 2014 12:28:19 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.89.194 with SMTP id bq2mr28961049obb.12.1415651299404; Mon, 10 Nov 2014 12:28:19 -0800 (PST) Received: by 10.60.32.42 with HTTP; Mon, 10 Nov 2014 12:28:19 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 21:28:19 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013cc45ed3b1f105078700f9 X-Provags-ID: V02:K0:o3m2zpEL0QbI1pXnu1wRgFDacUQiF+cSCr7QwIn53bd BERUx6N/KIPUVOk2LoEIMPs0CSBiDZ52v4Gmzp6EMEjBr47CpP Cm7ulPOkc86LKYz5yM0Et/lSMKhFG7U5zLX0XM6ZSAIjhhbp7D S4bhXiP3KIcCSrGAoFuI++oSROzOif0ZVrOJiv6SunR5EWnlFx tIMQTFffyO3+G66Ad38yuggSwPR240wl2W2qttuTcYPWuZyIBu E4wWG3wkaRRJmaP0KVszwAXjONDBpS8WihHX+XR6p090bOAPPp D+L1FWV5ruSIFmEPwiiRwbioaf/39Lo7Zc00yk9bdp+IB2a3CU Qx66srvvgpGAgzis/FkJQbVJd1HMYDeAOiZKgf7xld9Fi5wUyC ocjxU3oVyStVqSPHLYCO65Xm9/D/wBIad00UMUDbnBU92+bQ8A zKYTI X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dgIC5meWRF5HnnIu5fm0GJ6O-i4 Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:28:59 -0000 --089e013cc45ed3b1f105078700f9 Content-Type: text/plain; charset=UTF-8 Yngve N. Pettersen : Related to TLS 1.3 and fallbacks: Essentially all of the SCSV supporting > servers failed when the SCSV is used at the start and for the server's > highest supported version; For OpenSSL servers, this is a known bug (fixed in the next release) -- when going through the list of cipher-suites, the server-side code fails to look anywhere after the SCSV. > less than 0.1% did so for the SCSV at the end. > --089e013cc45ed3b1f105078700f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yngv= e N. Pettersen <yngve@spec-work.net>:

Related to TLS 1.3 and fallbacks: Essentially all of the SCSV supporting se= rvers failed when the SCSV is used at the start and for the server's hi= ghest supported version;

For OpenSSL server= s, this is a known bug (fixed in the next release) -- when going through th= e list of cipher-suites, the server-side code fails to look anywhere after = the SCSV.
=C2=A0
less than 0.= 1% did so for the SCSV at the end.


=
--089e013cc45ed3b1f105078700f9-- From nobody Mon Nov 10 12:40:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE21ACE67 for ; Mon, 10 Nov 2014 12:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eImi49QfDqq7 for ; Mon, 10 Nov 2014 12:40:19 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E531ACE3E for ; Mon, 10 Nov 2014 12:40:19 -0800 (PST) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MRTkO-1XPm802EPo-00Sezl; Mon, 10 Nov 2014 21:40:16 +0100 Received: by mail-oi0-f42.google.com with SMTP id a3so6005448oib.15 for ; Mon, 10 Nov 2014 12:40:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.3.8 with SMTP id 8mr13472859oid.11.1415652014459; Mon, 10 Nov 2014 12:40:14 -0800 (PST) Received: by 10.60.32.42 with HTTP; Mon, 10 Nov 2014 12:40:14 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 21:40:14 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113b975872933b0507872b6a X-Provags-ID: V02:K0:+OACDGXtqKH95+UJvTI0sb/bgOG5lq1cNy5mucWCmRi 86m4s5nJU7aTh6n6S5koQCXaDIlh5s5riNZBrVS2iCkMcLJIHi uWIEMKR9qVg8QHugj6FAl2AiyoqUG2C6+dZz75p3K4KxUY8ADE rLdaYfkhrDkB1B+q/dh1sSoA8IWIi8fx6KedjLqnYeM7Z4tIQH abjq3aXr2niCmVa7MuWY4m9e4NqiBBSY9eZZKrxTyXrESfBMHT RR0K/jxozsQDfNsDs7VVtcSP/HYZ87vl1L9xFL/x2+Vwq9qbMd gEhuOgonhsVx/J83BG6mundGpbcV/DRVly1/ZG43xfWmKEKlNb 49oZK0/mA9xxfmgFh0fzm9+kmu1lByrKuhOeNecgOQx2txZJUk Wz2uRoognXy9LI1lrW9TH2q0R+bN1HeYa/iaz/XBLcQB71UUm1 V1VL5 X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-NEwlEgFffMWgF9V-TsMwdR7JWg Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:40:20 -0000 --001a113b975872933b0507872b6a Content-Type: text/plain; charset=UTF-8 Yngve N. Pettersen : I also tested three other alternative SCSVs,placed at the end of the cipher > suite list, and 0.6% of the tested servers did not tolerate each of those. So ... unless I'm misunderstanding what you describe here, these servers plainly don't tolerate new (= unknown, to them) cipher suites in the list?! Interesting. Bodo --001a113b975872933b0507872b6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yngv= e N. Pettersen <yngve@spec-work.net>:

I also tested three other alternative SCSVs,placed at the end of the cipher= suite list, and 0.6% of the tested servers did not tolerate each of those.=

So ... unless I'm misunderstanding wha= t you describe here, these servers plainly don't tolerate new (=3D unkn= own, to them) cipher suites in the list?!=C2=A0 Interesting.

=
Bodo

=C2=A0
--001a113b975872933b0507872b6a-- From nobody Mon Nov 10 12:46:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673491ACEAB for ; Mon, 10 Nov 2014 12:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxpG-k9rtEeg for ; Mon, 10 Nov 2014 12:46:10 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6670D1ACEA9 for ; Mon, 10 Nov 2014 12:45:57 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id 10so6609337lbg.0 for ; Mon, 10 Nov 2014 12:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u6752IpkgmfcvDnZvPyb0kzDLdoLoIpUyPzXtCEJxMk=; b=Xp0i1sZqdd9ap5Ir28kAed87BYFBNpkrc+P5+PvE/wAKvayEOf4IskI/vYX9TlQKEV uWoxJ9fFtqw3TsJeRZ0Pe2S5o5FBRt+KhSkLKPUyv1fc9bRx2o8rmGMOm1bwVWu+T65R ASxNbAQd0NpqqeL/cJ3uh3fs2CkCDEFU+A/N2cI+WrLWg6mvWISxdIHwqtPm3Ixa6TUc toEQd+jsHKbxdR2iWeTHg/IIlD32qej6yQvN1r6VLA8xrVV8EO/MPGVLsZaXIedyDJIu 7cE+O9o8UueyL6DabQlyzB/GqusdvZWF4E3eZIp4EOpKP+M1GpjiBWzDvfDNtvbg80pZ SRyA== MIME-Version: 1.0 X-Received: by 10.113.5.7 with SMTP id ci7mr32783038lbd.9.1415652354073; Mon, 10 Nov 2014 12:45:54 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 12:45:53 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 12:45:53 -0800 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rlmkSLE2fcpJEMo8IsPHcZHXoxM Cc: "tls@ietf.org" Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:46:13 -0000 On 10 November 2014 12:40, Bodo Moeller wrote: > So ... unless I'm misunderstanding what you describe here, these servers > plainly don't tolerate new (= unknown, to them) cipher suites in the list?! > Interesting. There's a suggestion that some implementations only look at the second byte. A legacy of SSLv2, I believe. I'm not going to lose sleep over this. The SCSV fortuitously or otherwise, has a zero value on the second byte, which those implementations might recognize as TLS_NULL_WITH_NULL_NULL. Changing that might fix some of the issues, but I'm not sure that I want to take the cost. From nobody Mon Nov 10 13:02:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692BA1ACEA6 for ; Mon, 10 Nov 2014 13:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htmhqde6VdDe for ; Mon, 10 Nov 2014 13:02:48 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92941A1BEE for ; Mon, 10 Nov 2014 13:02:47 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0LsyHC-1XzfA72o4w-012XuK; Mon, 10 Nov 2014 22:02:46 +0100 Received: by mail-ob0-f172.google.com with SMTP id wp4so6448742obc.3 for ; Mon, 10 Nov 2014 13:02:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.199.1 with SMTP id jg1mr3305324obc.73.1415653363361; Mon, 10 Nov 2014 13:02:43 -0800 (PST) Received: by 10.60.32.42 with HTTP; Mon, 10 Nov 2014 13:02:43 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 22:02:43 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff2512ad940070507877bcf X-Provags-ID: V02:K0:Q5C+p4ALmJrhgiwc1ytiEjeG8aE7mMhnoqCLM2PlAKu OOiBMMZwfqJI/hAIpMVNy4BlA37r6/B2vMSsMET2Y9+x2VrnP9 ZUuBM7PTRMoldM5erbsu1T/w8KRhzuC99wjSR81FDQeTwDgEUJ jcM+EPyUKd1+77XAMfmQw7BSShnzr+SQryZwNRdkSRM/zldTBy Zf5Svt9jZS69ToTpr/o3se/xuV8TF3KoEhD3F4/WyVTgT//nN9 EF0cj2FJfHSl1Vbx3rdzUehWg87wwNHTst9BFj9HWkr9zzrbhH ixj5jZaqVtzioRyeKjK9YKBR9HUZgg/q0/k1k3Hhuqr8Vng5BZ luAUqy7sXfELRIgLAZFzyg+L2K0N5o2FF65hCmSaiHRCRBzvvI GeVJ8djuWHQK460kQoHf0/gfy6Q1TrhODRY9AmacTplbWQxMQm OtoSb X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/02x9wZkOCqDJKsIhwf_qIpo6YcQ Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 21:02:50 -0000 --e89a8ff2512ad940070507877bcf Content-Type: text/plain; charset=UTF-8 > > So ... unless I'm misunderstanding what you describe here, these servers > > plainly don't tolerate new (= unknown, to them) cipher suites in the > list?! > > Interesting. > > There's a suggestion that some implementations only look at the second > byte. Oh, that. Good point. Obviously, these servers will have other problems too (just due to collisions between deployed cipher suites in the Standards Action range and the Specification Required space), and failing the entire handshake if one of the cipher suites supposedly suggested by the client seems suspect is broken too, but right, that kind of issue may explain why more servers reject our concrete SCSV value than other potential SCSV values. (It's not clear that you'd even *want* to interoperate with such servers ... keeping them around would make it harder to add new actual cipher suites.) > A legacy of SSLv2, I believe. > Actually, SSL 2 cipher suites ("cipher kinds") had three bytes. It's probably simply a legacy of all SSL 3.0 cipher suites having the common first byte 0x00. Bodo --e89a8ff2512ad940070507877bcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
> So ... unless I'm misunderstanding what you describe here, these s= ervers
> plainly don't tolerate new (=3D unknown, to them) cipher suites in= the list?!
> Interesting.
=C2=A0
= There's a suggestion that some implementations only look at the = second
byte.

Oh, that. Good point. Obviously, thes= e servers will have other problems too (just due to collisions between depl= oyed cipher suites in the Standards Action range and the Specification Requ= ired space), and failing the entire handshake if one of the cipher suites s= upposedly suggested by the client seems suspect is broken too, but right, t= hat kind of issue may explain why more servers reject our concrete SCSV val= ue than other potential SCSV values. =C2=A0(It's not clear that you'= ;d even *want* to interoperate with such servers ... keeping them around wo= uld make it harder to add new actual cipher suites.)
=C2=A0
=
=C2=A0 A legacy of SSLv2, I believe.
=
Actually, SSL 2 cipher suites ("cipher kinds") had= three bytes.=C2=A0 It's probably simply a legacy of all SSL 3.0 cipher= suites having the common first byte 0x00.

Bodo
--e89a8ff2512ad940070507877bcf-- From nobody Mon Nov 10 14:23:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E501A8934 for ; Mon, 10 Nov 2014 14:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui0AGEX5azur for ; Mon, 10 Nov 2014 14:23:42 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CC7381A8968 for ; Mon, 10 Nov 2014 14:23:41 -0800 (PST) Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id 731EDF986; Mon, 10 Nov 2014 17:23:37 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A9AF51FF74; Mon, 10 Nov 2014 12:23:36 -1000 (HST) From: Daniel Kahn Gillmor To: Martin Thomson In-Reply-To: References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 10 Nov 2014 12:23:33 -1000 Message-ID: <87r3xawv8a.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8v4AFSVv161sR3s4J3zLHMc6fZc Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 22:23:45 -0000 --=-=-= Content-Type: text/plain On Sun 2014-11-09 09:25:27 -1000, Martin Thomson wrote: > On 8 November 2014 08:06, Daniel Kahn Gillmor wrote: >> To achieve this separation of purpose, though, we'd need to be able to >> distinguish between certificates capable of anchoring the end entity in >> a TLS 1.2 session and certificates capable of certifying a long-term >> g^s. Making these distinguishable would probably require a new X.509v3 >> extension, or extendedKeyUsage. > > There may still be operational advantages: you could issue the 1.2 > cert with a shorter lifetime and the 1.3 cert with a longer one. I'm not sure i understand this suggestion (it may be moot since it sounds like we're not considering this approach for 1.3 anyway after yesterday's interim discussion about the risks of introducing delegation in this fashion). > Mucking with X.509 would probably make this harder than its worth, I think. i agree that X.509 is a disaster here, but i think making up a new delegation protocol won't necessarily be a non-disaster -- we could instead just rehash some of the sharp bits of the X.509 mess (revocation, duration, transparency, identity, etc) in a different format if we're not clear about what we're doing :/ --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUYTrmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcYPwP/0rJz2k/kNR5p4YgHgO8QfuQ ErYvs2PbYeDAmNHH4inTCeeoRvuZGo1dyXoVcbGPsjTSegxpM2G964xN37r7XwY1 bAaowv4nKAm3TF/7liPFjFEQgiI3fY/pEzRZGMaDzgSfRu16FvZiKm8Y7J+dJjwk k83QNIAgXBs/NhNuj3BSwmZ82sBABDoxoaXQHSTJ7hLN68b3Vlueo3XetGpZ5anO fJOlAe+0bx/Usq0Ab51vUzRuXbiAXKUH86Ub6H4Sr8W1PTpYYErj9F1yVY4/SIsA /Q9o7hoAiJ95X50qtJ4ftTj1/DWyr6Im/MFE0E6jo3eGfLcdMf5WAWLyMWwuuxQV mb3gU7qhuqJPj85dh1ux4kQS8g3MLCDbjqDnqurpdmAjbtKCunjqvhjTyei4RIPE ihFzdnfUSvt3oMe6RXg/bbWIEOn8q8Gy1TR8DvYfUSf4rQJiERlVXAFmFSI5E0Mi 3UFY5N+jfXd7voARB2+PknX0p3mQhq2zo+zrizlvPT+Ebb4XbNzkeZrIHag0oBwY RWKWchvopW4eEFLX6PQ9AbgQbgxpyLiLdIB/9+FKlz9xQEqgF5sb5res3W2IiYU4 fpl7U592Sbta5FVyogHkR8nEjlkagn8Z3HJviaD0GJpbSBOEjenjDQhOGzbmSxHr 1JnaihtO7lYWS8q9HXDD =AsA9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 10 15:17:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2F41ACFE0 for ; Mon, 10 Nov 2014 15:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT3HU1eIFt-a for ; Mon, 10 Nov 2014 15:17:52 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5AF1ACFD8 for ; Mon, 10 Nov 2014 15:17:52 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id mc6so8751606lab.12 for ; Mon, 10 Nov 2014 15:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bm1468IeZmYivk0LalIgWkEXEOX5Jd1NFoBQsfvBGmI=; b=sRdu20tg1IgOQcz4XTdOwIrZLxNS0aTxNUCnHy+HPbw28qbeyBdP79hxfxmSvxvndX wBVGvXTatlzqnvTwOt9GJitOoOluwpQMLFZKDLdCmcqJIdYs89da93m4dp1lbNzRzIkn Ln0LU/ZeQU9V5tbZthMTB//5lSVwfJuj9js999mZWPqttdc/FA+AzVprQPiw+3z65yx0 6h27BtQkpAYm18kXrJucNV2k8bxvOpqGYbRTwEKgxv7D5n5SwD7x3Pppms1wsrtZwPIi 2AoKKzeW6H+r1Y8ZpcVCJukIe0U6EmpjMYEnDuI4jEEl5TGizxPXlcZevrIp7Uvur971 nINQ== MIME-Version: 1.0 X-Received: by 10.152.20.72 with SMTP id l8mr32965191lae.43.1415661470442; Mon, 10 Nov 2014 15:17:50 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 15:17:50 -0800 (PST) Date: Mon, 10 Nov 2014 15:17:50 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BwtRvCQ5reh7weXa8J_pfER6sLU Subject: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:17:54 -0000 (UTA on BCC) The POODLE attack has been used across the industry to justify disabling SSLv3. For some of us, this was just the excuse, but others might need more motivation. A statement from the IETF might help move some people. Richard, Alfredo, Adam and I have proposed such a statement: https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/ From nobody Mon Nov 10 15:24:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019391ACFE9 for ; Mon, 10 Nov 2014 15:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2DN3_NV-8mq for ; Mon, 10 Nov 2014 15:24:08 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD311ACFDF for ; Mon, 10 Nov 2014 15:24:08 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gq15so8695497lab.29 for ; Mon, 10 Nov 2014 15:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+lvHaNQiHmLqP0F6Mo021vhSJWPtgsA4C0gFx/ZUVcA=; b=V+39SbPnxYYbuPjZfMZR61HELRBfEMqWdrIP1UPgLrTyg7tn5583XMBICupi6fu/ar pZ62vQ4xwnQraLOQ8UE9rEpfGS1bRUG22AukpXATYEQwgp4xR6v4EDckhz6AoA8yAWkf nVTVs5Wz0NnBtUVkwiLNK8QWEClITZj3AKQCS4l2bHad3ueGIKNg7GJhQXs9nUradQIQ wTjev4EtNLX+G64keOqDM7rsbbmDTSmtQkz56PwbCISD62aAKBqlUkEWvZubJ3E8mJrB qte3XDsUY87fMt6VlFXK/McdQxEd6x4dSb9N+MUUgiWc7ojVl7g3WKfjU1jZ0X7WeC5b WYPw== MIME-Version: 1.0 X-Received: by 10.152.204.99 with SMTP id kx3mr33003219lac.53.1415661846638; Mon, 10 Nov 2014 15:24:06 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 15:24:06 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 15:24:06 -0800 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LMxBFHAQLHP2HNKLddqLbtRTLTM Cc: "tls@ietf.org" Subject: Re: [TLS] Fallback SCSV summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:24:10 -0000 On 10 November 2014 13:02, Bodo Moeller wrote: > It's not clear that you'd even *want* to interoperate with such servers ... > keeping them around would make it harder to add new actual cipher suites. I tend to agree. We have to be cautious about making a blanket statement, but visible bugs like this are often strongly correlated with other more insidious bugs (and things that are arguably not bugs, like support for SSLv3). From nobody Mon Nov 10 15:30:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B951AD006 for ; Mon, 10 Nov 2014 15:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fIvBwgNP1aX for ; Mon, 10 Nov 2014 15:30:19 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184AE1ACFD3 for ; Mon, 10 Nov 2014 15:30:19 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so7446709lbj.37 for ; Mon, 10 Nov 2014 15:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kR7PZXZJj/dwG1prkHzZ2yj7hwqsta8DabRqiDlNWAE=; b=WcwfuIuhS3mpowxz2GuYfZ7Ezq8HXcePJbkyf7DqaPw48/8w6/z96Dw35GDo5SFyOP 0SmNvzMUX56uVUnBhpglVXYo8gVbyDzPbl9BJfknAyD298YLqmf2sFrHRef6QQoM4zqf pvjVQTxBvxu2QP8rPO9B/5VcR3bNp8OussgTO0sLIWMIlQdEGCa5x0i6CSvr1Wg8c0iy JUrzY6dQ67oey5XGTER0k9sN8KQTgrKYiJv+v5Xk0OFvfabctn/D4RVuIRL2kPhehX8c D+kYBJQNvfFNc/Z3VU0FamWn0nvpbpLaMQZuczWJqrnmlKtvAXKoiqh5iAMxXq++fcnR e64Q== MIME-Version: 1.0 X-Received: by 10.112.170.99 with SMTP id al3mr33106256lbc.17.1415662217265; Mon, 10 Nov 2014 15:30:17 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 15:30:17 -0800 (PST) In-Reply-To: <87r3xawv8a.fsf@alice.fifthhorseman.net> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 15:30:17 -0800 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-7-LYlvsy8zpzXap_ktX0WqU9vM Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:30:22 -0000 On 10 November 2014 14:23, Daniel Kahn Gillmor wrote: > i agree that X.509 is a disaster here, but i think making up a new > delegation protocol won't necessarily be a non-disaster -- we could > instead just rehash some of the sharp bits of the X.509 mess > (revocation, duration, transparency, identity, etc) in a different > format if we're not clear about what we're doing :/ Prior to the discussion yesterday, I was really warming to this idea. After it, particularly the discussion around the creation of a delegation point, I think that I've been convinced that we shouldn't do this. Aside fro the delegation advantage, the real benefits of this are largely seen in the short term for RSA certificates. Moving to ECDSA obviates one of the big performance advantages, and the concerns around getting delegation right make me now against pursuing this. I don't think that this is categorically bad, or that we should not do this ever, but it's a big change and one that is much harder to get right than I originally thought. From nobody Mon Nov 10 15:46:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839031AD0A8 for ; Mon, 10 Nov 2014 15:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dP8t9luN70I for ; Mon, 10 Nov 2014 15:46:00 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7DCD1AD0A7 for ; Mon, 10 Nov 2014 15:45:59 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id v1so1848985yhn.35 for ; Mon, 10 Nov 2014 15:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pLzrxvBkGH7Rer5JczUlFV1AdZZXPFnFOoOOGHaVHJ4=; b=0TvGG7HM8issO3hBXxpMdhonS/HN8491uVZ3JsN+lkMqdrap6sAgIzIG1Bo8+IC0c0 43nU4wisO6Y0xjIm1IOF6IkZtFSj/ItzNO1xbYuvqsVnuEDj0/Ip7XUrj++0p8Wx3Uob GavXiwN2gjMpwhufLfLjdT9dY0G0mIlnGlsWGDEG8oHHO2qXBN/zmj0fCuF1PuxErebo wA4IrNZHuULu6XBZ8XlMOch6Heyz+ozrO+Td+IAX26yalTkmhjn5tH+QtakoblVk8EAj 4uXv3xW6Fk3PLTfxKwENgY/QKM9YKbVDxi8VswmtwOILRHBmtY62Uf5M2dSbnJ0suJRL rGuA== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr34216464yha.163.1415663159201; Mon, 10 Nov 2014 15:45:59 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 10 Nov 2014 15:45:58 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 10 Nov 2014 15:45:58 -0800 (PST) In-Reply-To: References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 15:45:58 -0800 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01634d34b9d5ac050789c336 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cDwmFaTxviBSHdUBLEEN8DIzOoo Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:46:05 -0000 --089e01634d34b9d5ac050789c336 Content-Type: text/plain; charset=UTF-8 On Nov 10, 2014 3:30 PM, "Martin Thomson" wrote: > > On 10 November 2014 14:23, Daniel Kahn Gillmor wrote: > > i agree that X.509 is a disaster here, but i think making up a new > > delegation protocol won't necessarily be a non-disaster -- we could > > instead just rehash some of the sharp bits of the X.509 mess > > (revocation, duration, transparency, identity, etc) in a different > > format if we're not clear about what we're doing :/ > > Prior to the discussion yesterday, I was really warming to this idea. > After it, particularly the discussion around the creation of a > delegation point, I think that I've been convinced that we shouldn't > do this. Every 0-RTT solution involves a similar delegation, as the client is using data sent from the server in the prevoius interaction or OOB to encrypt the early data. What exactly was the problem mentioned at the meeting? > > Aside fro the delegation advantage, the real benefits of this are > largely seen in the short term for RSA certificates. Moving to ECDSA > obviates one of the big performance advantages, and the concerns > around getting delegation right make me now against pursuing this. > > I don't think that this is categorically bad, or that we should not do > this ever, but it's a big change and one that is much harder to get > right than I originally thought. So what is the alternative exactly? Is it hacking 0-RTT and 1-RTT modes onto TLS 1.2 and hoping miTLS fixes the mistakes? ECDSA only obviates the performance advantage for genus 1. For genus 2 is a different story. Furthermore, eliminating online certificates enables isolation of certs without a performance penalty. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --089e01634d34b9d5ac050789c336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 10, 2014 3:30 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 10 November 2014 14:23, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> > i agree that X.509 is a disaster here, but i think making up a ne= w
> > delegation protocol won't necessarily be a non-disaster -- we= could
> > instead just rehash some of the sharp bits of the X.509 mess
> > (revocation, duration, transparency, identity, etc) in a differen= t
> > format if we're not clear about what we're doing :/
>
> Prior to the discussion yesterday, I was really warming to this idea.<= br> > After it, particularly the discussion around the creation of a
> delegation point, I think that I've been convinced that we shouldn= 't
> do this.

Every 0-RTT solution involves a similar delegation, as the c= lient is using data sent from the server in the prevoius interaction or OOB= to encrypt the early data.

What exactly was the problem mentioned at the meeting?

>
> Aside fro the delegation advantage, the real benefits of this are
> largely seen in the short term for RSA certificates.=C2=A0 Moving to E= CDSA
> obviates one of the big performance advantages, and the concerns
> around getting delegation right make me now against pursuing this.
>
> I don't think that this is categorically bad, or that we should no= t do
> this ever, but it's a big change and one that is much harder to ge= t
> right than I originally thought.

So what is the alternative exactly? Is it hacking 0-RTT and = 1-RTT modes onto TLS 1.2 and hoping miTLS fixes the mistakes?

ECDSA only obviates the performance advantage for genus 1. F= or genus 2 is a different story. Furthermore,=C2=A0 eliminating online cert= ificates enables isolation of certs without a performance penalty.

>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--089e01634d34b9d5ac050789c336-- From nobody Mon Nov 10 16:06:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3171ACE6B for ; Mon, 10 Nov 2014 16:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvBhNc4XOSxx for ; Mon, 10 Nov 2014 16:06:13 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFAF1ACE35 for ; Mon, 10 Nov 2014 16:06:12 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id d1so82630wiv.3 for ; Mon, 10 Nov 2014 16:06:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B0udEbUY9tz1otcWG+1PGA/Ztv7QLhmsQED9VTzS0TM=; b=ZKO8mza4hrDkIdwaj9VqyTjtmWqCSBOYbsu8pCbqjQehSTKXXDc85NP5a2Efposr4+ l5cNGZqcN8hYrJW5pLHVf6/OC0gf/0ZrSFiIHHSnh27HxGl+rhmXLIF4wwTnfn5oi/u+ MCL6XJLeIykkoDVu0mTrrbpy/CD4aWiVu4GEo/gPHUvHbaVyeTcPQUZke8V130eVXHS4 jsHz80wdsj/WavgbNmAEYnkRN7HncU+mI6Wu/VxQNY2Lex+4I8lTWtByxqdw5zt7Ac2/ MosVZzuaRvURIjb+DiKGfBrskdGYwEoG8NDisoQCHJWOf+kCQH3EdZ81AbaxTgiWu4Mi th3w== X-Gm-Message-State: ALoCoQk9PwU4IAu6wJMFI2vTByvdZ4y7U3BONLmiUbc3WlH46j1Zk2VJwZHkBxXyJBRqTI6Vpz40 X-Received: by 10.194.93.168 with SMTP id cv8mr24388977wjb.114.1415664371486; Mon, 10 Nov 2014 16:06:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Mon, 10 Nov 2014 16:05:31 -0800 (PST) In-Reply-To: References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> From: Eric Rescorla Date: Mon, 10 Nov 2014 14:05:31 -1000 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bb0399efbec4805078a0bc3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FJaZduL9-i0w5R3PAdLdPWfsXRQ Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:06:15 -0000 --047d7bb0399efbec4805078a0bc3 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 1:45 PM, Watson Ladd wrote: > > On Nov 10, 2014 3:30 PM, "Martin Thomson" > wrote: > > > > On 10 November 2014 14:23, Daniel Kahn Gillmor > wrote: > > > i agree that X.509 is a disaster here, but i think making up a new > > > delegation protocol won't necessarily be a non-disaster -- we could > > > instead just rehash some of the sharp bits of the X.509 mess > > > (revocation, duration, transparency, identity, etc) in a different > > > format if we're not clear about what we're doing :/ > > > > Prior to the discussion yesterday, I was really warming to this idea. > > After it, particularly the discussion around the creation of a > > delegation point, I think that I've been convinced that we shouldn't > > do this. > > Every 0-RTT solution involves a similar delegation, as the client is using > data sent from the server in the prevoius interaction or OOB to encrypt the > early data. > Well, perhaps. It's quite possible to have the server deliver a key in the initial handshake that is usable by the client for future handshakes. However, if the authentication of that key is part of the initial handshake (e.g., it's signed as part of the transcript), then the key won't be usable by other clients [or more accurately, the client won't be able to hand it to other clients and get them to use it]. I suppose you could argue that this is a delegation, but if so it's a different sort of delegation than producing a freestanding credential that can be given out to any new client. -Ekr --047d7bb0399efbec4805078a0bc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 10, 2014 at 1:45 PM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
=


On Nov 10, 2014 3:30 PM, "Martin Thomson" <martin.thomson@gmail.com>= wrote:
>
> On 10 November 2014 14:23, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote= :
> > i agree that X.509 is a disaster here, but i think making up a ne= w
> > delegation protocol won't necessarily be a non-disaster -- we= could
> > instead just rehash some of the sharp bits of the X.509 mess
> > (revocation, duration, transparency, identity, etc) in a differen= t
> > format if we're not clear about what we're doing :/
>
> Prior to the discussion yesterday, I was really warming to this idea.<= br> > After it, particularly the discussion around the creation of a
> delegation point, I think that I've been convinced that we shouldn= 't
> do this.

Every 0-RTT solution involves a similar delegation, a= s the client is using data sent from the server in the prevoius interaction= or OOB to encrypt the early data.

Well, perhaps.

It's quite possible to have the server deliver a k= ey in the initial handshake that
is usable by the client for futu= re handshakes. However, if the authentication
of that key is part= of the initial handshake (e.g., it's signed as part of the
t= ranscript), then the key won't be usable by other clients [or more accu= rately,
the client won't be able to hand it to other clients = and get them to use it].

I suppose you could argue= that this is a delegation, but if so it's a different
sort o= f delegation than producing a freestanding credential that can be
given out to any new client.

-Ekr

<= /div>
--047d7bb0399efbec4805078a0bc3-- From nobody Mon Nov 10 16:08:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3F31A3B9C for ; Mon, 10 Nov 2014 16:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN6xTpbRBnI7 for ; Mon, 10 Nov 2014 16:08:13 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5896C1AD015 for ; Mon, 10 Nov 2014 16:08:13 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so63986wiw.15 for ; Mon, 10 Nov 2014 16:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lWTBaKTc0qBAleemaHeoTqjCWGFQ6F5Mqo5wIk4MSGs=; b=pi4uPhX3otqNa1+1Bc5Uv01O02RaV+hB5pp/rGR3yN/SoKe60O+l3W/PAlN4DUaXmM xi9ATJ+aPjo+Kc59WV2oq/bz5oktxk4CobQNGeoKGdZ95Aqn2ayj8fxbHmLe/qeyEM2t bxFTeX1RBzcwRj8ZV7DkaJRRq1u1Pb6yXoLhT6EQMhOffIerO0ERqL015vocuwDwbS2u vrY67FMko0Fd+VyNisS0eGDKrYLpkIS2yRDBYmKl6wqanwGbx9BS2auZEVdhJsHcqcEj FJRQ5iBMklPd6aaPkoplA4NTywCXpfKdBl2NaJZ2rDWdHtWwXzJwa4eKFYicIjVWwX8z uCPA== X-Received: by 10.194.249.136 with SMTP id yu8mr27838462wjc.30.1415664492011; Mon, 10 Nov 2014 16:08:12 -0800 (PST) Received: from nat64.meeting.ietf.org ([2001:67c:1231:998:80d3:c9b8:9a3f:cbec]) by mx.google.com with ESMTPSA id dm10sm7598081wib.18.2014.11.10.16.08.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 16:08:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5C3B657C-DB6C-4776-9832-011BA52A17D7" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Mon, 10 Nov 2014 14:08:06 -1000 Message-Id: <21EF390E-1F89-410B-8114-74C0A8D5502D@gmail.com> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> To: Watson Ladd X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vxkt5Fc1A2JamNORKZMIpxtSs0U Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:08:15 -0000 --Apple-Mail=_5C3B657C-DB6C-4776-9832-011BA52A17D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 10, 2014, at 1:45 PM, Watson Ladd = wrote: >=20 >=20 > On Nov 10, 2014 3:30 PM, "Martin Thomson" > wrote: > > > > On 10 November 2014 14:23, Daniel Kahn Gillmor = > wrote: > > > i agree that X.509 is a disaster here, but i think making up a new > > > delegation protocol won't necessarily be a non-disaster -- we = could > > > instead just rehash some of the sharp bits of the X.509 mess > > > (revocation, duration, transparency, identity, etc) in a different > > > format if we're not clear about what we're doing :/ > > > > Prior to the discussion yesterday, I was really warming to this = idea. > > After it, particularly the discussion around the creation of a > > delegation point, I think that I've been convinced that we shouldn't > > do this. >=20 > Every 0-RTT solution involves a similar delegation, as the client is = using data sent from the server in the prevoius interaction or OOB to = encrypt the early data. >=20 > What exactly was the problem mentioned at the meeting? >=20 >=20 The issue is that the server sends a certificate + a buffer that is a = long-term DH public key signed with the private key associated with the = public key in that certificate.=20 Anyone who has that certificate and buffer plus the long-term DH private = key can impersonate the server. It=E2=80=99s delegation in the sense = that the server can sign a DH public key and let another node = impersonate it.=20 So the argument against it is that the new signed buffer is in effect a = credential, a certificate. Except that this kind of certificate does not = have the PKIX stuff. Specifically, there is no revocation for that = signature. A compromised signed DH public key can only be revoked by = revoking the certificate. As we are not currently prepared to work on = TLS delegation, we don=E2=80=99t want to sneak delegation in through the = back door. It should be noted that CloudFlare manages to make delegation work ([1]) = even without changing the protocol, but I wonder a little about that = solution. Isn=E2=80=99t the latency horrible? How secure is the = connection between CloudFlare and the customer? Does it create a = sign-everything service? Yoav [1] = http://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/= --Apple-Mail=_5C3B657C-DB6C-4776-9832-011BA52A17D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 10, 2014, at 1:45 PM, Watson Ladd <watsonbladd@gmail.com> wrote:


On Nov 10, 2014 3:30 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 10 November 2014 14:23, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> > i agree that X.509 is a disaster here, but i think making up a = new
> > delegation protocol won't necessarily be a non-disaster -- we = could
> > instead just rehash some of the sharp bits of the X.509 = mess
> > (revocation, duration, transparency, identity, etc) in a = different
> > format if we're not clear about what we're doing :/
>
> Prior to the discussion yesterday, I was really warming to this = idea.
> After it, particularly the discussion around the creation of a
> delegation point, I think that I've been convinced that we = shouldn't
> do this.

Every 0-RTT solution involves = a similar delegation, as the client is using data sent from the server = in the prevoius interaction or OOB to encrypt the early data.

What exactly was the problem mentioned at the = meeting?



The issue is that the server sends a certificate + = a buffer that is a long-term DH public key signed with the private key = associated with the public key in that certificate. 

Anyone who has that certificate and buffer plus = the long-term DH private key can impersonate the server. It=E2=80=99s = delegation in the sense that the server can sign a DH public key and let = another node impersonate it. 

So = the argument against it is that the new signed buffer is in effect a = credential, a certificate. Except that this kind of certificate does not = have the PKIX stuff. Specifically, there is no revocation for that = signature. A compromised signed  DH public key can only be revoked = by revoking the certificate.   As we are not currently prepared to = work on TLS delegation, we don=E2=80=99t want to sneak delegation in = through the back door.

It should be = noted that CloudFlare manages to make delegation work ([1]) even without = changing the protocol, but I wonder a little about that solution. = Isn=E2=80=99t the latency horrible? How secure is the connection between = CloudFlare and the customer? Does it create a sign-everything = service?

Yoav

= --Apple-Mail=_5C3B657C-DB6C-4776-9832-011BA52A17D7-- From nobody Mon Nov 10 16:15:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281D11AD01E for ; Mon, 10 Nov 2014 16:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsnELksJPxeR for ; Mon, 10 Nov 2014 16:15:43 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 554F61ACFEE for ; Mon, 10 Nov 2014 16:15:43 -0800 (PST) Received: from [192.168.101.236] (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id 8E900F986; Mon, 10 Nov 2014 19:15:39 -0500 (EST) Message-ID: <54615526.5020504@fifthhorseman.net> Date: Mon, 10 Nov 2014 14:15:34 -1000 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: Watson Ladd References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PARQIHUaC4v2AplrRhXl4Pchid16QTXbM" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rJMTI_eCdwxidUCi7oPMQxLXkVE Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:15:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PARQIHUaC4v2AplrRhXl4Pchid16QTXbM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/10/2014 01:45 PM, Watson Ladd wrote: > Furthermore, eliminating online certificates enables > isolation of certs without a performance penalty. if we get people to move their secret keys offline by replacing certs with something that is cert-equivalent for purposes of authentication, then what have we gained? The reason to move secret keys offline is to protect the identity credentials of the TLS endpoint, not because those keys are valuable in themselves. If a delegation process creates a new object that is an identity credential for the TLS endpoint, and the secret part of that object remains online, we haven't actually gained anything. Note: we *could* gain something, of course, if we manage to clearly and effectively scope the utility of the delegated credential more narrowly than the parent credential; then moving the wider-scoped parent credential's secrets offline is indeed a win. But it's not clear how to do that kind of scoped delegation correctly -- or even what forms of scoped delegation are desirable -- do we want to narrow the scope by time? by identity? by network address? by protocol= ? If someone wants to work on delegation in its own right, i think that could be useful. But adopting delegation "by accident" while we're defining a new key exchange mechanism seems likely to get us into worse trouble down the road. --dkg --PARQIHUaC4v2AplrRhXl4Pchid16QTXbM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUYVUmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcPs4QAI0Gwm1vvZKiJ5QivCChp9C1 pzFBn/y9reu9pCLn8GTENfYkdlRdg82/p3xcEnjQej+TiXizvCtjr7RPUbMEkjQo 2QKZxmngV6SVG+708/ztusD5FRdyVvsxRNzPgLTbWUiS4NSyMUrjxx5Qx1/Y+SBn M20U8Mp3qau+npto5isIbcmg/G5qSrUxX29qvR7/jDg+WP8kN3ehxA4wGgiWq8AA Fpj2qEBtEyw/+aCJijWgnFpgGYwHcoN4RRr824lLApwykSr7a1yovRycZxNt6wxl ++MqBizj+ICtQgPm0FXAn/W4huaf0EiHxXRF92bOfOTLIrNb8zbeLrsgB7nmC+dn Oylk9s7JmcYs7AOQeljdJZ8fRWvV42Kir/VW3o2adhpjyYAaCDj3S9O0DqjloUBf o2nEtYO4xwfy9EBrpu14+nx27F12/kzn2QgnR5a6tX/p5OZwtn7INjv8f15mvctG khZwtmjhcsze76nfOUklmDdI9MD6J5HkuBUq9Q8Mr+lxsWsNZw+7L6cXKJm4m/gY Hwu15ki1yGW2qAwIL0PcV3W3Eq849hxX73govYHS8+BCcTbCu3wOH0eTJs3G2gVC EitPPbASvG4tCdeBP94w2EkG15NptklJPcXqRmjNDY2wFGp7c6B0LJ0JZ4aSZ3ak zkMICywBeoQYuDwBP1ry =h0TD -----END PGP SIGNATURE----- --PARQIHUaC4v2AplrRhXl4Pchid16QTXbM-- From nobody Mon Nov 10 16:19:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F7D1AD23D for ; Mon, 10 Nov 2014 16:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCGUvMRRG_x3 for ; Mon, 10 Nov 2014 16:19:36 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 084541AD0D1 for ; Mon, 10 Nov 2014 16:19:34 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id BB59527BC061; Mon, 10 Nov 2014 16:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=vZX3i0OfJRG1r1 yesG2mCw5yaW8=; b=sn6fl8Q/Us2F92/lYswrACpurvGs7HL1glx622EBZDVTTY jgfrWQyR+voOL1OAC07uW1x/ezOroWsiGV25tZ6XzN4Uyqah9+cEpwTvnXJAhAkd DhCKMtOtH1kZi8c5b1UjYGB8O/3nvoiBbivZlzIqoFYVelU691pppEKky5IOA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 69E6427BC05D; Mon, 10 Nov 2014 16:19:33 -0800 (PST) Date: Mon, 10 Nov 2014 18:19:32 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20141111001930.GE3412@localhost> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <21EF390E-1F89-410B-8114-74C0A8D5502D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21EF390E-1F89-410B-8114-74C0A8D5502D@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kRBBWHTT-towHaGHY9fCK7Yr-fI Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:19:37 -0000 On Mon, Nov 10, 2014 at 02:08:06PM -1000, Yoav Nir wrote: > The issue is that the server sends a certificate + a buffer that is a > long-term DH public key signed with the private key associated with > the public key in that certificate. > > Anyone who has that certificate and buffer plus the long-term DH > private key can impersonate the server. It's delegation in the sense > that the server can sign a DH public key and let another node > impersonate it. Session tickets too are a form of delegation, with narrower scope (just one client). But surely clients won't be sharing these delegated DH pubkeys with each other? This sort of delegation is probably a fine thing, except that: > So the argument against it is that the new signed buffer is in effect > a credential, a certificate. Except that this kind of certificate does > not have the PKIX stuff. Specifically, there is no revocation for that > signature. A compromised signed DH public key can only be revoked by > revoking the certificate. As we are not currently prepared to work > on TLS delegation, we don't want to sneak delegation in through the > back door. it needs to have an explicit notAfter date, that needs be in the near future. The acceptable lifetime of a delegated server pubkey should be comparable to the acceptable lifetime of a session ticket, and both should be relatively short (hours, not days, and certainly not weeks). Nico -- From nobody Mon Nov 10 16:30:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847EA1AD2C0 for ; Mon, 10 Nov 2014 16:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpLcChRBJ8Si for ; Mon, 10 Nov 2014 16:30:02 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA82B1AD28D for ; Mon, 10 Nov 2014 16:30:01 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id B8060264058; Mon, 10 Nov 2014 16:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5b2mIKWYIrhle5 K1oeUGsy9Mdqc=; b=WKTPdEiZxJrwNObNtlYvpOg96/Ur/IXU0oQWB9KV/gcMaR tivCA7xJyGGlBm/KO8f/mC2XitRaJa6SlhXDflC4XAne+YTlioVo4/Pq6i7p4n1B 01eKUm57T6zht0KAjGqLH4safDzD/JMOyYygEjN2ZTCwWn+djKop9oSpZr8og= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id 67FF326406A; Mon, 10 Nov 2014 16:30:01 -0800 (PST) Date: Mon, 10 Nov 2014 18:30:00 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20141111002959.GF3412@localhost> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <21EF390E-1F89-410B-8114-74C0A8D5502D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21EF390E-1F89-410B-8114-74C0A8D5502D@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cLnIQi4Hw5o18ey0iTAJ_s7hncQ Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:30:04 -0000 On Mon, Nov 10, 2014 at 02:08:06PM -1000, Yoav Nir wrote: > It should be noted that CloudFlare manages to make delegation work > ([1]) even without changing the protocol, but I wonder a little about > that solution. Isn't the latency horrible? [...] Session resumption makes up for it, amortizing the impact on the user. It's probably no worse (typically) than 2 or 3x the normal latency, for the first connection (or first handful of concurrent connections). It'd be interesting to see how noticeable this is, but I suspect that on the whole it's not really all that noticeable. > [...] How secure is the > connection between CloudFlare and the customer? [...] In principle it should be no less secure than TLS itself. (I've not looked closely enough, but I imagine that's exactly what CloudFlare uses for their connection to their customers' key sign server.) > [...] Does it create a > sign-everything service? Yes, which is why you need to get authentication (of CloudFlare to the key server) right, so you can authorize key sign requests. And the customer should be doing this with server names and certs and keys that are only for the CloudFlare use anyways. This brilliantly lets CloudFlare out of the business of having certs with lots of names, and it simplifies key management for their customers. The price is that this requires SNI. > [1] http://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ Nico -- From nobody Mon Nov 10 16:52:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9301D1AD37F for ; Mon, 10 Nov 2014 16:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJG98xnoFKRT for ; Mon, 10 Nov 2014 16:52:23 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 98C041AD37C for ; Mon, 10 Nov 2014 16:52:23 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 7871A20047B86; Mon, 10 Nov 2014 16:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=/QAUNfOoyRjKSf qpF287WvbmvMo=; b=RK7SFeLOZJ4jHJoDPCI3P6/Cusbk6o1hFD0s6rWtyuKKJX C/qLZB8Ja/gy7l5QW7igAEVWFBjdRB9JmqSY9MYWI+IyTC7FERyPxrtaFUrrp6pX QrfuK97ZfvPvCPCHE4xNgx6k9aQ4SrLfOwkHAArNpa+C/PPPbe5xNrenbD1Zw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 285D720047B84; Mon, 10 Nov 2014 16:52:23 -0800 (PST) Date: Mon, 10 Nov 2014 18:52:22 -0600 From: Nico Williams To: Daniel Kahn Gillmor Message-ID: <20141111005220.GG3412@localhost> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54615526.5020504@fifthhorseman.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cyDp3N-7BUxl3L-DJ4oa_cGDbqg Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:52:24 -0000 On Mon, Nov 10, 2014 at 02:15:34PM -1000, Daniel Kahn Gillmor wrote: > On 11/10/2014 01:45 PM, Watson Ladd wrote: > > Furthermore, eliminating online certificates enables > > isolation of certs without a performance penalty. > > if we get people to move their secret keys offline by replacing certs > with something that is cert-equivalent for purposes of authentication, > then what have we gained? The ability to use cheaper, lower-performance HSMs, for one (maaaybe, and only where one was using an HSM to begin with). Or, put another way, to handle more connections with a given HSM investment. It's not nothing. But see below! > The reason to move secret keys offline is to protect the identity > credentials of the TLS endpoint, not because those keys are valuable in > themselves. If a delegation process creates a new object that is an > identity credential for the TLS endpoint, and the secret part of that > object remains online, we haven't actually gained anything. The delegation has to have a short lifetime because otherwise it might as well be a certificate issued by an intermediate CA... ...which the customer can't get because of the failure to widely implement and deploy PKIX name constraints. But also because of revocation: if you have to check the status of the key then you lose the 0rt. By putting a short lifetime on the delegation that problem goes away. But then there's no advantage over plain session resumption. Even if each 0rt connection can lengthen the delegatee key's life by having the server send a fresh signature of the key as needed, the server could also just refresh the session resumption state/ticket. IMO the main value in static DH is in learning the server's static DH pubkey out of band, via DNSSEC (DANE). That eliminates all these concerns while enabling 0rt connections _every_ time for servers that have such keys. Of course, 0rt connections can't provide proper PFS to data sent immediately after the client's first TLS handshake message. That's a problem, no? Nico -- From nobody Mon Nov 10 17:53:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4571AD3E6 for ; Mon, 10 Nov 2014 17:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QcJPnH3HH8n for ; Mon, 10 Nov 2014 17:53:43 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638AA1AD3E1 for ; Mon, 10 Nov 2014 17:53:43 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so10507311wgh.26 for ; Mon, 10 Nov 2014 17:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XKpBwSWxIZJKS9Ze9fPn8FdeCmJadct4LJhHgWkYR1w=; b=jFeemxAXviS5G2mN0mevI6MgPWg0bSoCNApd+ErvbNnDSYtHH6UZh0C1O3cxPl6Zm0 4gZUNDvj0BUEknmdj+LxycOa384z8dF4UtbUpMCVUMTJ9Ka3c34v6lVjhyJaAFzg3Zho +blBfDhziuqHYxUc5ZRasgUyuQMBrUG+NHCNEUZiG0e1HendVRyDdF0WK3AY7W9ccL2L yj7cLvj5wN3ivclFd1kJ0MyiyzqB9qEyI2cLTkEccs770BbkeWAhjRe23ZBrl8XlAHDb 293WhaMT0IXmsM+wakgtgZ/9T0gGR1z3OY9uXFSEdrYlcQf48u+/V4mMIFYVfI7wqeQX BH9A== X-Received: by 10.194.93.168 with SMTP id cv8mr25107314wjb.114.1415670822184; Mon, 10 Nov 2014 17:53:42 -0800 (PST) Received: from t2001067c03700160e455ad7f8d9be850.wireless.v6.meeting.ietf.org (t2001067c03700160e455ad7f8d9be850.wireless.v6.meeting.ietf.org. [2001:67c:370:160:e455:ad7f:8d9b:e850]) by mx.google.com with ESMTPSA id ll2sm12566786wjb.11.2014.11.10.17.53.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 17:53:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <20141111005220.GG3412@localhost> Date: Mon, 10 Nov 2014 15:53:35 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fOF2o5TPXsjYc0dsA4_7bTjB3Yo Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 01:53:46 -0000 > On Nov 10, 2014, at 2:52 PM, Nico Williams = wrote: >=20 >> The reason to move secret keys offline is to protect the identity >> credentials of the TLS endpoint, not because those keys are valuable = in >> themselves. If a delegation process creates a new object that is an >> identity credential for the TLS endpoint, and the secret part of that >> object remains online, we haven't actually gained anything. >=20 > The delegation has to have a short lifetime because otherwise it > might as well be a certificate issued by an intermediate CA... >=20 > ...which the customer can't get because of the failure to widely > implement and deploy PKIX name constraints. >=20 > But also because of revocation: if you have to check the status of the > key then you lose the 0rt. >=20 > By putting a short lifetime on the delegation that problem goes away. > But then there's no advantage over plain session resumption. How short is =E2=80=9Cshort=E2=80=9D? This is yet another thing that is = hosed by the non-availability of a secure time signal. Clocks are = skewed, so if you use a notAfter date that is less than 24 hours away, = you=E2=80=99re going to have clients thinking that this has already = passed.=20 Sure, we MUST fix time. But we also MUST fix PKIX name constraints, and = I think we=E2=80=99re close to solving the latter than we are to solving = the former. > Even if each 0rt connection can lengthen the delegatee key's life by > having the server send a fresh signature of the key as needed, the > server could also just refresh the session resumption state/ticket. >=20 > IMO the main value in static DH is in learning the server's static DH > pubkey out of band, via DNSSEC (DANE). That eliminates all these > concerns while enabling 0rt connections _every_ time for servers that > have such keys. This assumes a deployed DNSSEC. That will happen some time after the = secure time signal. > Of course, 0rt connections can't provide proper PFS to data sent > immediately after the client's first TLS handshake message. That's a > problem, no? I guess you can=E2=80=99t have everything.=20 Yoav From nobody Mon Nov 10 18:12:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C631AD3F4 for ; Mon, 10 Nov 2014 18:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg50e93dIH7u for ; Mon, 10 Nov 2014 18:12:42 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 84B551AD3DE for ; Mon, 10 Nov 2014 18:12:05 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 615474012D696; Mon, 10 Nov 2014 18:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=c6n5w9tYE8MgA5T2o4eY2vPh33w=; b=eGpYCedz+jV PlY7mJWlJRVLtSI5TaNHzF+FktDJaxHEvX33Ra7g0Vmd0O4PY5CW4bulaqfloOau 6MCkqD3hfzkf/S6FnYucDRp/ooguTB6kQEsjD3+k6tDhLAY/K1rg7/yg4KcGI5Xf OvKs5Jb3fDif43lqb1AKdzPagAkjMSNE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 0AF5E4012D695; Mon, 10 Nov 2014 18:12:04 -0800 (PST) Date: Mon, 10 Nov 2014 20:12:04 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20141111021201.GH3412@localhost> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aQzDjiXBicVUnKTHerJ8kg5RhkE Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:12:43 -0000 On Mon, Nov 10, 2014 at 03:53:35PM -1000, Yoav Nir wrote: > On Nov 10, 2014, at 2:52 PM, Nico Williams wrot= e: > > By putting a short lifetime on the delegation that problem goes away. > > But then there's no advantage over plain session resumption. >=20 > How short is =E2=80=9Cshort=E2=80=9D? This is yet another thing that is= hosed by the > non-availability of a secure time signal. Clocks are skewed, so if you > use a notAfter date that is less than 24 hours away, you=E2=80=99re goi= ng to > have clients thinking that this has already passed.=20 The time should be relative, as a TTL. "This resumption ticket is good for 2 hours." "This DH pubkey is good for 2 hours." "hours" is good. "days" is not. That's good enough. The items in question should be stored in memory (tmpfs, ...), not stable storage anyways, so all that matters is that time tick somewhat accurately for that TTL, unless the client reboots. > Sure, we MUST fix time. [...] Not for this. > > IMO the main value in static DH is in learning the server's static DH > > pubkey out of band, via DNSSEC (DANE). That eliminates all these > > concerns while enabling 0rt connections _every_ time for servers that > > have such keys. >=20 > This assumes a deployed DNSSEC. That will happen some time after the > secure time signal. Maybe, but until and unless we convince ourselves that these delegated DH pubkeys can have lifetimes much longer than session resumption state tickets... then there doesn't seem to be much value in static DH here. > > Of course, 0rt connections can't provide proper PFS to data sent > > immediately after the client's first TLS handshake message. That's a > > problem, no? >=20 > I guess you can=E2=80=99t have everything.=20 API-wise we can: you can have integrity and confidentiality protection immediately, but PFS not until you consume the server's handshake message. (The GSS-API pretty much deals with this in the context of authentication state, and it'd take adding a boolean flag to do the same for PFS.) The problem is that HTTP can't know if the data to be sent is sensitive, and probably neither can the user-agent. They have to assume it's all sensitive. If you want PFS you have to settle for either: a) (EC)DHE and no 0rt every time, or b) (EC)DHE and no 0rt occasionally + 0rt w/ session resumption w/ short-lived sessions. Nico --=20 From nobody Mon Nov 10 18:21:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9101E1AD445; Mon, 10 Nov 2014 18:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQyVx7sveF7e; Mon, 10 Nov 2014 18:21:16 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03861AD441; Mon, 10 Nov 2014 18:21:15 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id k14so10429068wgh.28 for ; Mon, 10 Nov 2014 18:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eF84d63HUe946qA64CZBbz0A9K7G7JYtYF4DTdzLdvM=; b=URPkg8wRJv/PrBtXcVHVU1w+KQRS1BktZuZafpY7nkw1qPCazgg1eg+tRA3KYuIfeI Rot/uMfBQZfpDz8u6NH+FCqRUAKwu8wai2up08a65llMLldvtoBG6rxKu7NWwrXJyfyQ CsGe24EZJ7S+Lye+Tij+6eUZ+EuBKYH5+yFQ0H7KLMWjBjuCJAR0jjksEnG9rorTDmm8 r0bO0QbX2h+UZSJ5TeIgvjCOuQSCyu5Hn4JEqIC5NBjXEtA6ribYTuBnD0eNfcUk3y3n rt/53rqV308lldZfPDBvQq7yC3KY/0N240E49khXhkcdrnljhKSNkYtoauaWA/4pUQLg 8QRQ== X-Received: by 10.194.92.82 with SMTP id ck18mr48914104wjb.103.1415672474802; Mon, 10 Nov 2014 18:21:14 -0800 (PST) Received: from iMassi.local ([2001:67c:1231:998:2daf:6f04:992b:d693]) by mx.google.com with ESMTPSA id ft8sm2421452wjb.17.2014.11.10.18.21.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 18:21:14 -0800 (PST) Message-ID: <54617296.5070600@gmail.com> Date: Mon, 10 Nov 2014 16:21:10 -1000 From: "Dr. Massimiliano Pala" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "pkix@ietf.org" References: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bkON2RV480Do3BQwpNs4IPXP-3c Cc: "tls@ietf.org" Subject: Re: [TLS] [pkix] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:21:18 -0000 Hi all, I would just like to point out that stapling is not the only distribution mechanism for OCSP responses - a useful optimization for high-volume servers, but still an optimization: i.e. the server is not the sole (or authoritative) source of revocation information: that is the CA/OCSP server role. The application (and it is NOT only browsers!) can always reference the AIA:OCSP URI in the certificate for accessing the OCSP response. Maybe it should be mentioned/noted that the application could decide to (a) directly abort the connection or (b) use the default PKIX/OCSP response protocol as backup. Cheers, Max > On Sep 18, 2014, at 4:38 AM, Nikos Mavrogiannopoulos wrote: > > On Thu, 2014-09-18 at 07:57 -0400, Phillip Hallam-Baker wrote: > >>>> Section 3.1.1 specifies "a server MUST return a valid OCSP token". I >>>> would consider an expired ocsp staple to not actually be valid. I >>>> would refer to it as expired, with the implication that the signature >>>> is correct, because if it wasn't a person probably would have said >>>> that in addition to describing it as expired. >>> >>> That's pretty sketchy. OCSP responses have a recommended validity >>> interval, this is not the same as X.509 certificate expiration. I'm not >>> sure what popular browsers do with responses received by the server that >>> are outside the validity period, but I would be very surprised if they >>> dropped the connection. If in this document it is assumed that responses >>> not within the recommended interval should cause a TLS connection >>> failure, it should be explicit. >> Given that we currently have a situation where the vast majority of >> Web browsers are not PKIX compliant and ignore revocation information >> completely and Web browsers are only one PKIX application, I don't >> think it is appropriate to use a MUST here to direct how invalid >> status is handled. > > Maybe not, but it makes sense to define what is valid and invalid. > The problem statement of this draft as you set it is to close a door on > a "downgrade" attack where no OCSP response is sent. However, if you > don't define what is a secure connection to a server that supports OCSP > status request, how can you claim to fix an attack? > > regards, > Nikos > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Mon Nov 10 19:18:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040481A9122 for ; Mon, 10 Nov 2014 19:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-vTTi3vJSMZ for ; Mon, 10 Nov 2014 19:17:58 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.35.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CC51A887E for ; Mon, 10 Nov 2014 19:17:57 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 5213540575C42; Mon, 10 Nov 2014 21:17:57 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 41B0140575C14 for ; Mon, 10 Nov 2014 21:17:57 -0600 (CST) Received: from [31.133.171.207] (port=50268 helo=dhcp-abcf.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xo1xs-0006mL-Ly for tls@ietf.org; Mon, 10 Nov 2014 21:17:56 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 10 Nov 2014 17:17:55 -1000 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.171.207 X-Exim-ID: 1Xo1xs-0006mL-Ly X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-abcf.meeting.ietf.org) [31.133.171.207]:50268 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/diq6Ad87LQ2uWrsKyo1Cd7BHs9E Subject: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:17:59 -0000 All, This message is confirming the WG consensus we reached in Toronto about = producing an updated RFC4492 that is bound for standard track.* Yoav has = produced an individual draft that can be found here: http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ that we would like the WG to consider adopting. Please let us know by = November 18th whether you object to adopting Yoav=92s draft (and why). spt * This is for pre-TLS 1.3 because the 1.3 spec is going to incorporate = the EC text directly in the base spec. =20= From nobody Mon Nov 10 20:09:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50531AD545 for ; Mon, 10 Nov 2014 20:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.807 X-Spam-Level: X-Spam-Status: No, score=0.807 tagged_above=-999 required=5 tests=[BAYES_60=1.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miyOGMdK2cEG for ; Mon, 10 Nov 2014 20:03:03 -0800 (PST) Received: from nm47-vm7.bullet.mail.bf1.yahoo.com (nm47-vm7.bullet.mail.bf1.yahoo.com [216.109.115.142]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603531ACD51 for ; Mon, 10 Nov 2014 20:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1415678582; bh=V7mMA6LZcFQ1hIMd+5uqVDtjOF2oXxMZC1aKLgDuqGA=; h=Date:From:Reply-To:To:Subject:From:Subject; b=gJMzTAQaNF7/VXwoT5udanEA4BXWKI7igwPshhAQgQ+qXDd3e0clo4UAbiUT2K1qNOdt9vuhsS/EZAqlY7+yr2tEVI8qp0GqIlZMID3ykqcHntiGFfTXWSnqcJueBwjH7TC0UZ1FUA0rQE7r8CwW2V8AwNFJDgpGmOl4UQQM9B10OAjs47kmni2F1znDQtAx3mVkBAbazWn8Z+j5x6id7R37+Y4rjmaGXn33O/tF6NYyUSUzAB16FTo7nlmlHDITdbs8/ncBsyaF4A6g5dtN4aapVJWOlVc92EPuKhBeuZDMxcfKR/wBVeKV6cUmo+aUesZKXDFDESrsLj9V53jVnQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=OaAOwVXZ8fsYrDwCx0JWZI0ZQeTALhLWUCQdG1BUQN6lGo5zZ1kty04tBS5ouISyoBLNK3XVP1CMUf/XS+MS87HwwKMIoOIFebKb/yVxLPH0ddH6rAv2e95i+yqk4v3n4sWGv2DdJlwzzt9X8wMurxd525mayZfjpRW+xE0IcXZuiqJ6oypn2EghnJqguqmRN5wd3hFy8GiFOuSYhiODMq1+Ou42xxLKQ16ghrqhuYYTIKEC4YHYv6EdLDj9DFYr4e/GJHaVrnXwI2WAlqZqOPC0Lbg+hrrvNc5iwJURaEQ6MnePhnE4yGnGK6BEM0DcHjmZdVwXnyhAq3wjojaQEA==; Received: from [98.139.215.143] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 04:03:02 -0000 Received: from [98.139.212.248] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 04:03:02 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 04:03:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 429527.83348.bm@omp1057.mail.bf1.yahoo.com X-YMail-OSG: 7k9u41AVM1lB8xIIcO7iczvqEUn5HuG.e7EMjfAK_b.GVuGji2YCCJr7qWs9BMh IQx9liilvl.FY5RN5C40d0FdTZJRYwcCvxtRzRvFdZuQnRVTuPWpW47WXayzwSaAPl9M9vn8xI1O x8qDEZSkFxVYt3A7OOVASsQm2WQaRYdDqkJLfyv4j1juSPlB1JdNfHqLBmBpwEjwW4xw83sraoaa Lj06CtAa1VlKTl.rSn5NnA0wSNFrNYgZJIMJGPcKLuSSpxKoUKzBljenIQ_LHY85mV4BRFIAipIq PAC4o9jdWXFwxmrftuPmP72wvrWywwLLe_EXFyVzSgBr126m.hNHG_3Nh3jWqFoOxAReRTgVm4Ti 4OSkK1JAkGp1FLBf_Ai570ORzSRfecd8ssse.2Miew5XMFysmGagmSj9fIHQLD8H6CzXRI166uLw HQTzt6aEkrGo0D.qobZHhiq0jsFV5vMcYegdmcX70S_DXMycTA_TkKBO0wFfwChCkLXzn.x0EvaW uVsYcsZJYVo8r.T3NLX9RafvgvFb2n7n0nZoKhFMimJT_Fm8o82EmdUsb Received: by 76.13.26.143; Tue, 11 Nov 2014 04:03:02 +0000 Date: Tue, 11 Nov 2014 04:02:23 +0000 (UTC) From: Oleg Gryb To: "djb@cr.yp.to" , "tls@ietf.org" Message-ID: <2116033100.449850.1415678543902.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_449849_43534089.1415678543896" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ndoaTq5I3eNWsHK2N3p1ycTASlY X-Mailman-Approved-At: Mon, 10 Nov 2014 20:09:35 -0800 Subject: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 04:03:05 -0000 ------=_Part_449849_43534089.1415678543896 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Daniel and TLS community, I was going through SafeCurves pages recently and wanted to ask a question = about brainpoolP256r1's twist security. According to this research http://s= afecurves.cr.yp.to/twist.html,,=C2=A0 a combined cost of attacks on brainpo= olP256t1, which is a P256r1's "twist" is rather low. At the same time it's = obvious that small-group-attack is not applicable, because "h=3D1" is a req= uirement for all brainpool curves including the one under consideration. The other two "invalid-curve" attacks should be mitigated by openssl contro= ls, since latter does have a point-on-the-curve validation (e,g. see EC_POI= NT_is_on_curve function and its usage in the latest openssl stable versions= ). Given all that, can I consider the curve as secure? Are there any other att= acks that I should consider before adopting the curve as a standard? Thank you also for the wonderful research related to Curve25519 and Curve41= 417. They both seem to be perfect. I hope openssl community will adopt them= soon. Oleg =C2=A0 ------=_Part_449849_43534089.1415678543896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel and TLS community,

I was going through S= afeCurves pages recently and wanted to ask a question about brainpoolP256r1= 's twist security. According to this research http://safecurves.c= r.yp.to/twist.html,,  a combined cost of attacks on brainpoolP256t= 1, which is a P256r1's "twist" is rather low. At the same time it's obvious= that small-group-attack is not applicable, because "h=3D1" is a requiremen= t for all brainpool curves including the one under consideration.

The other two= "invalid-curve" attacks should be mitigated by openssl controls, since lat= ter does have a point-on-the-curve validation (e,g. see EC_POINT_is_on_curv= e function and its usage in the latest openssl stable versions).

Given all that, = can I consider the curve as secure? Are there any other attacks that I shou= ld consider before adopting the curve as a standard?
<= br style=3D"" class=3D"">
Thank you also for the wonde= rful research related to Curve25519 and Curve41417. They both seem to be pe= rfect. I hope openssl community will adopt them soon.
=
Oleg=
 
------=_Part_449849_43534089.1415678543896-- From nobody Mon Nov 10 20:23:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2E1AD41B for ; Mon, 10 Nov 2014 20:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN5HXEtdcprg for ; Mon, 10 Nov 2014 20:23:23 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.216.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236651AD3CE for ; Mon, 10 Nov 2014 20:23:23 -0800 (PST) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 62730B99470C; Mon, 10 Nov 2014 22:23:22 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 50476B994674 for ; Mon, 10 Nov 2014 22:23:22 -0600 (CST) Received: from [31.133.171.207] (port=50488 helo=dhcp-abcf.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xo2zB-0006bQ-NW for tls@ietf.org; Mon, 10 Nov 2014 22:23:21 -0600 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 10 Nov 2014 18:23:19 -1000 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.171.207 X-Exim-ID: 1Xo2zB-0006bQ-NW X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-abcf.meeting.ietf.org) [31.133.171.207]:50488 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sCPbI_d7NWJfzbQOsz6NQE_hWi0 Subject: [TLS] 20141109 TLS interim minutes posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 04:23:24 -0000 Drafts minutes for the 11 November 2014 TLS Interim meeting can be found = here: = http://www.ietf.org/proceedings/interim/2014/11/09/tls/minutes/minutes-int= erim-2014-tls-4 spt= From nobody Mon Nov 10 21:00:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B01AD556 for ; Mon, 10 Nov 2014 21:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gSIYjJ8xiGH for ; Mon, 10 Nov 2014 21:00:07 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5E91AD53D for ; Mon, 10 Nov 2014 21:00:07 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so4311922ykr.23 for ; Mon, 10 Nov 2014 21:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mvO2/nHlrSssu1kouz7OlSscnplD9MJ9gJgSW3BTUR4=; b=GKbn3m8TDL2ctT3yAyrNP6Xj8DzW8w/pL4NzzX/Y0OTBPcpFgL781p8hbu53Au0Aqu 7xGmwCv6LYat5uXVnLA6ctub7F9t/8GqbO6BuHqycMrpm2YhcGrWmxOMI/ysXBByCXwg M4e36h0fpcsi+HR8NDW6CN3u9iwnAc/t53hRpLeNsyLcYPYqvKUmgKxvQ1Gw5UBTxQrh ZVXRe5cHmY43XgmKeIXfVTqbWZO+Z/jJ/ecJnMAhn+BDrBRgp9nmV2euSuS7jLKnbT7b Pz+xkZp07TahpJen0zPWwWpr3xwJe9J8r9NquRltCOMRldVU3oRk1nDA+VIlh3L0TU9V c8Iw== MIME-Version: 1.0 X-Received: by 10.170.213.130 with SMTP id e124mr39269484ykf.24.1415682006753; Mon, 10 Nov 2014 21:00:06 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 10 Nov 2014 21:00:06 -0800 (PST) In-Reply-To: <20141111005220.GG3412@localhost> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> Date: Mon, 10 Nov 2014 21:00:06 -0800 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xig-i-LPpc0PF1d4DWbZonAzUgQ Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 05:00:12 -0000 On Nov 10, 2014 4:52 PM, "Nico Williams" wrote: > > On Mon, Nov 10, 2014 at 02:15:34PM -1000, Daniel Kahn Gillmor wrote: > > On 11/10/2014 01:45 PM, Watson Ladd wrote: > > > Furthermore, eliminating online certificates enables > > > isolation of certs without a performance penalty. > > > > if we get people to move their secret keys offline by replacing certs > > with something that is cert-equivalent for purposes of authentication, > > then what have we gained? > > The ability to use cheaper, lower-performance HSMs, for one (maaaybe, > and only where one was using an HSM to begin with). Or, put another > way, to handle more connections with a given HSM investment. It's not > nothing. But see below! > > > The reason to move secret keys offline is to protect the identity > > credentials of the TLS endpoint, not because those keys are valuable in > > themselves. If a delegation process creates a new object that is an > > identity credential for the TLS endpoint, and the secret part of that > > object remains online, we haven't actually gained anything. > > The delegation has to have a short lifetime because otherwise it > might as well be a certificate issued by an intermediate CA... > > ...which the customer can't get because of the failure to widely > implement and deploy PKIX name constraints. > > But also because of revocation: if you have to check the status of the > key then you lose the 0rt. > > By putting a short lifetime on the delegation that problem goes away. > But then there's no advantage over plain session resumption. Can we make 0-RTT resumption? Snap start doesn't do this, and my proposal from the summer to do this was thought to not be that great. I'll look up exactly what was wrong and try to fix it. This may work better than general 0-RTT exchanges, if delegation is considered to be a problem. I do see a benefit, which is that session resumption as currently envisioned involves keeping keys around that can decrypt old data. Changing this means that TLS 1.3 resumption works differently than TLS 1.2 resumption, which isn't a problem. We should at minimum fix this PFS failure. > > Even if each 0rt connection can lengthen the delegatee key's life by > having the server send a fresh signature of the key as needed, the > server could also just refresh the session resumption state/ticket. > > IMO the main value in static DH is in learning the server's static DH > pubkey out of band, via DNSSEC (DANE). That eliminates all these > concerns while enabling 0rt connections _every_ time for servers that > have such keys. So we have a root cert with RSA 1024 bit RSA, or the same delegation point issue. It doesn't eliminate revocation concerns either: DNSSEC doesn't guarantee liveness. (DNS can have dynamic data, but the size is strictly limited, so stuffing a cert chain in is a bad idea). > > Of course, 0rt connections can't provide proper PFS to data sent > immediately after the client's first TLS handshake message. That's a > problem, no? They can limit the time the key is around, so an attacker has a narrow window to steal the keys. There is another set of advantages beyond those mentioned above: TLS 1.2 is annoying to think about for technical reasons, whereas OPTLS had a good chance of avoiding those. We need to actually design a secure protocol, not just spray and pray as we have in the past. There was a 20 year gap between TLS 1.0, and the definitive security analysis, which discovered new attacks, and is dependent on tool support. A TLS 1.3 based on TLS 1.2 runs a risk of having significant security holes in new features unless we take care to do the analysis before deploying. I feel the delegation problem was clearly spelled out in Hugo's message describing the protocol. What I don't understand is why it is a problem to have a duration-limited credential equivalent in power to a certificate. Since there is no recording, I can't figure out what was said and what convinced everyone this was a bad idea. I've looked at the minutes but they are extremely sparse. What was the worry associated with complicating the key schedule? Can someone summarize the argument about delegation, so I can figure out if it convinces me or not? Sincerely, Watson Ladd > > Nico > -- From nobody Mon Nov 10 21:51:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35BF1AD546 for ; Mon, 10 Nov 2014 21:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUXNZmPrDEDh for ; Mon, 10 Nov 2014 21:51:32 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8770C1AD395 for ; Mon, 10 Nov 2014 21:51:32 -0800 (PST) Received: from [31.133.163.118] (dhcp-a376.meeting.ietf.org [31.133.163.118]) by che.mayfirst.org (Postfix) with ESMTPSA id 081E1F986 for ; Tue, 11 Nov 2014 00:51:29 -0500 (EST) Message-ID: <5461A3DD.4030102@fifthhorseman.net> Date: Mon, 10 Nov 2014 19:51:25 -1000 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: tls@ietf.org References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> In-Reply-To: <20141111021201.GH3412@localhost> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bBe8uMKR6WLiVF258llsjdACt7lP5e1PI" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5-lHkW3A8Jg_Z5o8HeZ3FveI39k Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 05:51:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bBe8uMKR6WLiVF258llsjdACt7lP5e1PI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/10/2014 04:12 PM, Nico Williams wrote: > The time should be relative, as a TTL. relative to what? If the credential is standalone (e.g. in such a way that the signing key can be kept offline) then the TTL established can be replayed by an attacker who takes control of the DH secret to extend the lifetime of the delegated credential, right? if the credential isn't standalone (i.e. if it's accepted by the client based on its inclusion in the signed handshake which has been authenticated by a signature from the signing key), then we aren't in a signature-less TLS scheme. if it's not relative, but it's long-lived, then we introduce a new revocation problem. if it's not relative and it is short-lived, then we introduce interesting clock skew issues (though perhaps those are the same as OCSP-must-staple clock skew issues?) None of this is to say that delegation is a terrible idea, but just that the details matter and it's not something to casually adopt without understanding the tradeoffs we're taking. and those tradeoffs are complex enough that they seem to overwhelm the possible performance gains from the OPTLS proposal. (esp. when there are other ways like ECDSA certs that give comparable performance gains). > "This resumption ticket is good for 2 hours." >=20 > "This DH pubkey is good for 2 hours." >=20 > "hours" is good. "days" is not. I agree that short-lived is nice; I think it also possibly removes the pro-OPTLS argument about keeping the signing keys offline. (maybe that's ok) But without a concrete specification of what the delegation mechanism looks like, the properties of the deployed proposal end up being very different. --dkg --bBe8uMKR6WLiVF258llsjdACt7lP5e1PI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUYaPdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcro4QAOE6p/7/QHIEoa7UQno0AQoq RUwxS4fesVjjYcA0x4LkWJsL7b5V2/FoYOzgYPB8hmOfJSbwwV43Z4Fp35uUx4ay X9ynErXlcmJE+gMrJIvnt9MlUuz8hvMuln3QoNCGSblfwotE6zK0hemgLukYMTzu 9P6BMPOSER+mnDzFpO1rFX61rdj4Y12s57wHpK3cCCIDfgrsxWb1aEW8dZ8ElJyL fl1wjMvpJ9lfAxe14r17+uj2qnYQ7B3buNBUDWVOdbShTQGRXneOHct0J0+Irj2j 2sVP661yrKqX+pVPfhLuh5cGBEh+cpWtXkLmB03X4NMEvFdA0LYTOsW23GYjq41T DrCshNJGqhxM5FzHGbDCR5a2sFDfmfM/ccqsO17OCbTas4KRRQIcGV/ntEzEtP4w fUbzCqSw/hV6Ai3XYTsQST19x/n5c69R9sTJHHwUJHrGJPVVDsK472CWxiYfqYg9 cXk/eX/eA5aqIyOD/bRban2IouYz6D2DNDDz9g+c9GHHzKc703omsDGl6Kzz0GgN mmpYQpAFFlud0OcOKUadioUoo/mEHKiswp/qZeLwboBK+l3Z4b1GKvK6vH4o5pyG jGy6UJpjmBsG1dm9QRLcJCs0ytHVfYP4DCuBDVVWmZehhR7a2MdWi+s76dFM997s MrTZUoGYuv19S0FEnhfJ =U/td -----END PGP SIGNATURE----- --bBe8uMKR6WLiVF258llsjdACt7lP5e1PI-- From nobody Tue Nov 11 01:00:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5DB1AD611 for ; Tue, 11 Nov 2014 01:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEUru-C5RJb2 for ; Tue, 11 Nov 2014 01:00:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7851A8549 for ; Tue, 11 Nov 2014 01:00:44 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAB90ega031323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 11 Nov 2014 04:00:40 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAB90cvO027987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 04:00:39 -0500 Message-ID: <1415696437.1938.6.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Sean Turner Date: Tue, 11 Nov 2014 10:00:37 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/epspzve6RwbgZ58JAJqARqMpZUM Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:00:51 -0000 On Mon, 2014-11-10 at 17:17 -1000, Sean Turner wrote: > All, > > This message is confirming the WG consensus we reached in Toronto about producing an updated RFC4492 that is bound for standard track.* Yoav has produced an individual draft that can be found here: > > http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ > > that we would like the WG to consider adopting. Please let us know by November 18th whether you object to adopting Yoav’s draft (and why). Two points: 1. This document includes fixed ECDH ciphersuites (ECDH_RSA, ECDH_ECDSA). Given they have 0 deployment on the internet, the question is why? What are the practical use cases of these ciphersuites and why should they be defined in a standards track document. 2. This document includes arbitrary curve support. What is the rationale for including that as no implementations support that [0], and even for DH we are switching from arbitrary to named groups as well (I also ignore the known attacks for this option). Unless there is sufficient argumentation and applicability for the above, I support the document only with the above removed. regards, Nikos [0]. http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves From nobody Tue Nov 11 01:58:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112981A86F6 for ; Tue, 11 Nov 2014 01:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICTQYtZsZ_yY for ; Tue, 11 Nov 2014 01:58:46 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADCE1A1B47 for ; Tue, 11 Nov 2014 01:58:46 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id bj1so10337455pad.31 for ; Tue, 11 Nov 2014 01:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VDFMe9RUWJ706ys9BYMQz9kb143MDrQPeuzU5au4yUY=; b=mCpRNedhDANDaYgJQ8hZWSshY1pO/H+7NMP7apuW2GKzWRIc716wo3XxVzudUn4yZc lcwsCkI8k4vdlZt3HVI1yUW/RK9RrZkc/0q9i/INpv4OxJMw93RZeNP9xTLzRIRRhTrf wWhRkTi1wqovk6tRS4j0n8j6O3e82QmVclanqVzKSIkYs3U+I5RjA9onKlOzy57SeuoH /2KrWWmPhOo7MtfLUICdhOFxXSyLRNFHrRe1cpcf3cs2ud4kSDnMR4/4uPJBH17COzx3 DAYyRXwSfb0aPGq4PIBkKpwowifftyx1gJr6T0zHVs71cn4+peYITs4GfcUeSpwnb7J8 WwQw== X-Received: by 10.66.139.234 with SMTP id rb10mr9049431pab.146.1415699925599; Tue, 11 Nov 2014 01:58:45 -0800 (PST) Received: from [172.16.7.139] ([66.135.227.226]) by mx.google.com with ESMTPSA id ce4sm8033470pbc.78.2014.11.11.01.58.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 01:58:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <1415696437.1938.6.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 10 Nov 2014 23:58:38 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <13DDAE38-237C-4130-A9D9-26B3B67851B2@gmail.com> References: <1415696437.1938.6.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Weob5ueydRg1gqWl0qWcysQN41o Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:58:50 -0000 > On Nov 10, 2014, at 11:00 PM, Nikos Mavrogiannopoulos = wrote: >=20 > On Mon, 2014-11-10 at 17:17 -1000, Sean Turner wrote: >> All, >>=20 >> This message is confirming the WG consensus we reached in Toronto = about producing an updated RFC4492 that is bound for standard track.* = Yoav has produced an individual draft that can be found here: >>=20 >> http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ >>=20 >> that we would like the WG to consider adopting. Please let us know = by November 18th whether you object to adopting Yoav=E2=80=99s draft = (and why). >=20 > Two points: > 1. This document includes fixed ECDH ciphersuites (ECDH_RSA, > ECDH_ECDSA). Given they have 0 deployment on the internet, the = question > is why? What are the practical use cases of these ciphersuites and why > should they be defined in a standards track document. >=20 > 2. This document includes arbitrary curve support. What is the = rationale > for including that as no implementations support that [0], and even = for > DH we are switching from arbitrary to named groups as well (I also > ignore the known attacks for this option). >=20 > Unless there is sufficient argumentation and applicability for the > above, I support the document only with the above removed. Hi, Nikos The current draft is pretty much a copy of RFC 4492. The intent is to = match whatever decision the WG will make for TLS 1.3. So the changes that you suggest will be made after the document is = adopted (either in the -00 or -01 version, whichever way the chairs = prefer it).=20 Following Sunday=E2=80=99s interim, we=E2=80=99re also likely to remove = all the defined curves weaker than P-256 (or maybe P-224 to match the = strength of 3DES, although I=E2=80=99m not in favor) We are also likely to deprecate point format negotiation. We won=E2=80=99t= remove it for TLS 1.2, just mandate non-compressed format for existing = curves) And when CFRG recommends a new curve, we will add it to this one. So this document is in no way in its final form. The question before the working group now is whether we want such a = document that obsolete 4492 and aligns EC for TLS 1.2 with what we want = for 1.3, or if we don=E2=80=99t. Hope this clarifies the situation Yoav From nobody Tue Nov 11 03:56:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0FA1A8704 for ; Tue, 11 Nov 2014 03:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TcEB_C6AFGE for ; Tue, 11 Nov 2014 03:56:47 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00821A1A88 for ; Tue, 11 Nov 2014 03:56:46 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mreue002) with ESMTP (Nemesis) id 0MAYXK-1Xi4Ri0zPe-00Bcve; Tue, 11 Nov 2014 12:56:44 +0100 Received: by mail-ob0-f172.google.com with SMTP id wp4so7296926obc.17 for ; Tue, 11 Nov 2014 03:56:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.160.206 with SMTP id xm14mr7359360oeb.7.1415707001944; Tue, 11 Nov 2014 03:56:41 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 11 Nov 2014 03:56:41 -0800 (PST) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com> Date: Tue, 11 Nov 2014 12:56:41 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0115f6baf5064f050793f8e2 X-Provags-ID: V02:K0:LTn51kp0F5wHvk8p/Gy734JqWW+btdpgmxPrKjmKI2m X0Q85Jgg3FtOLqvVaGjXKwTe0Cut6TmLLm34kPOsIpTeZAZ93c xOJnH5baFq5PxE61j68jdm2BCO+l9AfiAd/gbdk5eGOhvXN+X0 r+L0KV+AvRWxEnd85J/itiakity3hQWxTbHTyzmfX4yYl+59mp 6UgOkKie+3SBKzRRF0eWI4rk6r2anGZKNI8/F4T9NZyJwOsSab g/UO9HBCU+wMalah0x2gLtBFIdIi4E+dz51JIVfZssd5LryMEt G4mZ7FJYt6kN8GYDZOYbiVC5gBnFuq+a953YFjtQKPlSt0yp80 4+QIbHeIAEcwmcHesqVnXTOkU4ZDPNQDm1pm96tGKic7EFia4a qSro9bW1Xhjh/cqoaodrRBIFsiCGW0YHyHmd1rph+2ILrVVDNy CgNq9 X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kfQ6OvT1MZoRyBkL6weK4wWXycE Subject: Re: [TLS] Minutes from Tuesday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 11:56:48 -0000 --089e0115f6baf5064f050793f8e2 Content-Type: text/plain; charset=UTF-8 2014-10-22 3:35 GMT+02:00 Adam Langley : > On Tue, Oct 21, 2014 at 9:41 AM, Bodo Moeller wrote: > > That's not right: YouTube video streams currently can use two cipher > suites, > > TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The > > interoperability problem mentioned in the meeting was that > > TLS_RSA_WITH_AES_128_GCM_SHA256 (without ECDHE) isn't a supported cipher > > suite in Firefox, and RC4 is RC4; > > https://bugzilla.mozilla.org/show_bug.cgi?id=1029179. > > (And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's > already enabled in some locations.) > And by now, should be enabled everywhere. --089e0115f6baf5064f050793f8e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2014= -10-22 3:35 GMT+02:00 Adam Langley <agl@google.com>:
On Tue, Oct 21, 2014 at 9:41 AM, B= odo Moeller <bmoeller@acm.org>= ; wrote:
> That's not right: YouTube video streams currently can use two ciph= er suites,
> TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The
> interoperability problem mentioned in the meeting was that
> TLS_RSA_WITH_AES_128_GCM_SHA256 (without ECDHE) isn't a supported = cipher
> suite in Firefox, and RC4 is RC4;
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179.<= br>
=C2=A0
(And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it&#= 39;s
already enabled in some locations.)

And= by now, should be enabled everywhere.

--089e0115f6baf5064f050793f8e2-- From nobody Tue Nov 11 05:44:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79F1A9238 for ; Tue, 11 Nov 2014 05:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGGV9iVpxy3X for ; Tue, 11 Nov 2014 05:44:26 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECDC1A912A for ; Tue, 11 Nov 2014 05:44:24 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sABDiN8L026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 11 Nov 2014 08:44:24 -0500 Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sABDiMP3009700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 11 Nov 2014 08:44:23 -0500 Message-ID: <546212B6.9020304@redhat.com> Date: Tue, 11 Nov 2014 14:44:22 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> In-Reply-To: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CqpdRmv2IOZjrInw11F5MpOzM_c Subject: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 13:44:31 -0000 On 11/10/2014 09:07 PM, internet-drafts@ietf.org wrote: > Title : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks > Authors : Bodo Moeller > Adam Langley > Filename : draft-ietf-tls-downgrade-scsv-01.txt > Pages : 8 > Date : 2014-11-10 Section 3 still does not mention which version to put into the inappropriate_fallback alert message. For interoperability reasons, the TLS version from ClientHello.client_version has to be used (even if the version negotiation has not been completed because the server might opt to bail out early out of the handshake code). -- Florian Weimer / Red Hat Product Security From nobody Tue Nov 11 06:47:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1EE1A8A89 for ; Tue, 11 Nov 2014 06:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.323 X-Spam-Level: X-Spam-Status: No, score=0.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scrBb1k9O68m for ; Tue, 11 Nov 2014 06:47:11 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A531A8A56 for ; Tue, 11 Nov 2014 06:47:10 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gf13so9641157lab.31 for ; Tue, 11 Nov 2014 06:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=e6ApVwHovfa0/gNc2vPKP97iSKfK+qLl7uff1Ux/QaA=; b=Wuv2T8Vvjzsu8Ri1aowiYCFTjNYoUqIxNxf02gcqfgbtPZiAkGFfigfe2YFu5EJKl6 IPaQU4gjxSm2DUVpnX6AMVoqGxmGpSmurRbc7SX8z19Z5lkInuiC6FpYP4ZjPahjlKN5 474S5pDTSmkmK0xVOJcGJ9vpWRNFWH4fKup3NrkitfzHHm1lOHmRgZVUklShwteSo6ZY 6RKb7Ph1zCpS7ZmK6Gh/EzEnO9tBVtJtFEpnRMmFobJiCYEe1YEmJdl7RczabuKVM6Kv He2YYrZwrnay0H3X06b8R1oMYqN8bUf55G0UwMCZkRGvpJ7QQoNE/gHgsyYWI3Dc1soz SCuA== X-Received: by 10.152.43.97 with SMTP id v1mr36520975lal.3.1415717228972; Tue, 11 Nov 2014 06:47:08 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Tue, 11 Nov 2014 06:46:38 -0800 (PST) In-Reply-To: <5461A3DD.4030102@fifthhorseman.net> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> From: Hugo Krawczyk Date: Tue, 11 Nov 2014 09:46:38 -0500 X-Google-Sender-Auth: l9DdvnRhC2LaEgJVCcFqcmjBd9U Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c35626890f3a0507965a6b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MZSAv5n8TUJIkRWrNm0WotjRWD4 Cc: Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 14:47:14 -0000 --001a11c35626890f3a0507965a6b Content-Type: text/plain; charset=UTF-8 Wait, wait, wait... I am surprised to see such an abrupt decision to drop consideration of OPTLS. There is little information in the minutes as for the rationale for this move although it seems to be entirely based on the handling of static-DH certificates and the understanding that in the future one can still run TLS 1.3 with ECDSA and/or ECDH certificates. Let me address these issues and the multiple advantages of OPTLS that need to be considered. Please bear with me in spite of the long email. Since I will not be in Hawaii (I wish I was...) take this in lieu of a presentation at the WG meeting (and pardon the advertisement pitch, I believe it is fair and well-founded). First, note that if we had ECDH certificates then this whole issue of how to sign the static DH key g^s would be moot. You would use that certificate to vow for the server's static DH key. Security would be based on the protection of s exactly as it is based on the security of a private signing key today. In particular, the key s would need to be kept online with the same vulnerabilities (and potential protection) of a signing key today. The whole reason to create a "sub-certificate" for g^s by signing it with the server's certified signature is that we currently only have certificates for signature keys, not ECDH. This may or may not change in the future - actually, as I argue below, there are advantages of sub-certs for g^s over a long-term ECDH certificate. So what is the concern that has been voiced regarding the use of sub-certs for g^s? That the leakage of a private key s that was sub-certified allows to impersonate the server for the validity period of that sub-certificate, and that clients with skewed clocks will be accepting it beyond the intended validity period. This is true but not different than the situation with current certificates. In particular, the validity period of the sub-cert will never exceed that of the signing certificate. How about revocation? It requires the main certificate revocation exactly as needed now. So none of these issues is worse than vulnerabilities of signing keys today. Actually, there are two non-trivial advantages to the sub-cert approach: - clients with good clocks (or small skews) will not accept g^s much past its validity period, which would be typically much more limited than the main signing cert. Clients with terrible skews will never be in worse shape than they are today with respect to validating the signing certificate. - a server can issue multiple g^s keys for availability, distribution, sub-domain use, etc. and to support different groups ECDH groups - which need to be supported anyway for PFS also in a signature-based protocol. (There is also the ability to support online retrieval of currently validated sub-certificates via protocols such as DNSSEC or other specific mechanisms, even though there seems to be little enthusiasm for this option, at least currently) The only downside I can see for sub-certification of g^s is for cases where protection of an online signature key (as needed today) is better than the one affordable to the key s, e.g. with current HSMs that support signing but not ECDH. But this is the price of a looking-forward transition period as opposed to proposals that keep us tied to the sub-optimality of past solutions. It needs to be considered in light of the many advantages of a signature-less protocol as claimed here. Let me now address the claim that in the future we will have ECDSA certificates which would enable a signature-based protocol with less cost than RSA signing today. This claim is mostly true but ignores some important aspects of the use of ECDSA: - The wide use of RSA in certificates is not going away any time soon - so the very significant performance advantages of OPTLS vs a RSA-implemented signature-based protocol is going to be enjoyed for long time (actually, it may be a main motivation for adoption of signature-less TLS 1.3 in addition to PFS) - The total time of sign+verify in ECDSA is larger than the time of static-DH authentication used in OPTLS. - ECDSA presents definition and implementation complexities that do not exist with ECDH, in particular tied to specific EC groups. In particular, this is likely to postpone adoption of ECDSA. - Online ECDSA signatures amplify the vulnerability of the long-term ECDSA signing key to the leakage of ephemeral values (in ECDSA, as in other Schnorr-like signatures, there is a per-signature random value that if revealed, it fully reveals the long-term private signing key). Such vulnerability does not exist in OPTLS. - Signature-less protocols have a privacy advantage in providing plausible deniability, especially when compared to protocols (as current 1.3) that sign the peer's identity (I wrote on this in a previous message to this list). In addition, signature-less protocols can take advantage of sub-certs as noted above. Even when the algorithm to sign these sub-certs will be ECDSA, it will allow the use of Offline ECDSA hence ameliorating the above vulnerability of ECDSA to ephemeral disclosure. And now to summarize some of the general advantages of ECDH-based (and signature-less) protocols and some specific advantages of OPTLS: - 0-RTT support required static ECDH keys (or semi-static, exactly as in OPTLS) - thus in a signature-based protocol this support would be pure overhead - Critical performance gain relative to per-session signing with RSA (an advantage that will most probably stay with us for long time) - Compatibility with the already needed mechanisms to provide PFS (hence amortizing any cost of the underlying crypto) - Compatibility with pre-shared key authentication: simply replace g^{xs} with PSK. - Cryptographically, it relies on the ECDH security of the underlying EC groups rather than relying on this security PLUS the security of signatures (which means relying on the weaker of the two primitives) - Other advantages mentioned above: Sub-cert time limitation and support for multiple static ECDH keys if so desired, specific advantages with respect to ECDSA-based protocols (complexity of ECDSA and vulnerability to ephemeral information), privacy via deniability, offline signatures (specially significant with ECDSA). Finally, the advantage of a protocol built with cryptographic logic, not as a accidental result of many years of patches. I believe the WG has delayed or never implemented in the past significant changes such as Encrypt-the-MAC, OAEP, CBC IVs, session binding, etc. This time we can make it right from the begining. Hugo --001a11c35626890f3a0507965a6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wait, wait, wait...

I a= m surprised to see such an abrupt decision to drop consideration of OPTLS. = There is little information in the minutes as for the rationale for this mo= ve although it seems to be entirely based on the handling of static-DH cert= ificates and the understanding that in the future one can still run TLS 1.3= with ECDSA and/or ECDH certificates.

Let me addres= s these issues and the multiple advantages of OPTLS that need to be conside= red. Please bear with me in spite of the long email. Since I will not be in= Hawaii (I wish I was...) take this in lieu of a presentation at the WG mee= ting (and pardon the advertisement pitch, I believe it is fair and well-fou= nded).

First, note that if we had ECDH certificates= then this whole issue of how to sign the static DH key g^s would be moot. = You would use that certificate to vow for the server's static DH key. S= ecurity would be based on the protection of s exactly as it is based on the= security of a private signing key today. In particular, the key s would ne= ed to be kept online with the same vulnerabilities (and potential protectio= n) of a signing key today.

The whole reason to create a "sub-ce= rtificate" for g^s by signing it with the server's certified signa= ture is that we currently only have certificates for signature keys, not EC= DH. This may or may not change in the future - actually, as I argue below, = there are advantages of sub-certs for g^s over a long-term ECDH certificate= .

So what is the concern that has been voiced regarding the use of s= ub-certs for g^s? That the leakage of a private key s that was sub-certifie= d allows to impersonate the server for the validity period of that sub-cert= ificate, and that clients with skewed clocks will be accepting it beyond th= e intended validity period. This is true but not different than the situati= on with current certificates. In particular, the validity period of the sub= -cert will never exceed that of the signing certificate. How about revocati= on? It requires the main certificate revocation exactly as needed now.
<= br>
So none of these issues is worse than vulnerabilities o= f signing keys today.
Actually, there are two non-trivi= al advantages to the sub-cert approach:
=C2=A0- clients= with good clocks (or small skews) will not accept g^s much past its validi= ty period, which would be typically much more limited than the main signing= cert. Clients with terrible skews will never be in worse shape than they a= re today with respect to validating the signing certificate.
-=C2=A0 a server can issue multiple g^s keys for availability, distri= bution, sub-domain use, etc. and to support different groups ECDH groups - = which need to be supported anyway for PFS also in a signature-based protoco= l.
(There is also the ability to support online retriev= al of currently validated sub-certificates via protocols such as DNSSEC or = other specific mechanisms, even though there seems to be little enthusiasm = for this option, at least currently)

The only downs= ide I can see for sub-certification of g^s is for cases where protection of= an online signature key (as needed today) is better than the one affordabl= e to the key s, e.g. with current HSMs that support signing but not ECDH. B= ut this is the price of a looking-forward transition period as opposed to p= roposals that keep us tied to the sub-optimality of past solutions. It need= s to be considered in light of the many advantages of a signature-less prot= ocol as claimed here.

Let me now address the claim = that in the future we will have ECDSA certificates which would enable a sig= nature-based protocol with less cost than RSA signing today. This claim is = mostly true but ignores some important aspects of the use of ECDSA:
- The wide use of RSA in certificates is not going away any t= ime soon - so the very significant performance advantages of OPTLS vs a RSA= -implemented signature-based protocol is going to be enjoyed for long time = (actually, it may be a main motivation for adoption of signature-less TLS 1= .3 in addition to PFS)
- The total time of sign+verify in ECDSA is large= r than the time of=C2=A0 static-DH authentication used in OPTLS.
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;font-si= ze:small">- ECDSA presents definition and implementation complexities that = do not exist with ECDH, in particular tied to specific EC groups. In partic= ular, this is likely to postpone adoption of ECDSA.
- O= nline ECDSA signatures amplify the vulnerability of the long-term ECDSA sig= ning key to the leakage of ephemeral values (in ECDSA, as in other Schnorr-= like signatures, there is a per-signature random value that if revealed, it= fully reveals the long-term private signing key). Such vulnerability does = not exist in OPTLS.
- Signature-less protocols have a p= rivacy advantage in providing plausible deniability, especially when compar= ed to protocols (as current 1.3) that sign the peer's identity (I wrote= on this in a previous message to this list).
In addition, = signature-less protocols can take advantage of sub-certs as noted above. Ev= en when the algorithm to sign these sub-certs will be ECDSA, it will allow = the use of Offline ECDSA hence ameliorating the above vulnerability of ECDS= A to ephemeral disclosure.

And now= to summarize some of the general advantages of ECDH-based (and signature-l= ess) protocols and some specific advantages of OPTLS:
- 0-RTT support required static ECDH keys (or semi-static, exactly as in O= PTLS) - thus in a signature-based protocol this support would be pure overh= ead
- Critical performance gain relative to per-session= signing with RSA (an advantage that will most probably stay with us for lo= ng time)
- Compatibility with the already needed mechan= isms to provide PFS (hence amortizing any cost of the underlying crypto)
- Compatibility with pre-shared key authentication: simpl= y replace g^{xs} with PSK.
- Cryptographically, it reli= es on the ECDH security of the underlying EC groups rather than relying on = this security PLUS the security of signatures (which means relying on the w= eaker of the two primitives)
- Other advantages mention= ed above: Sub-cert time limitation and support for multiple static ECDH key= s if so desired, specific advantages with respect to ECDSA-based protocols = (complexity of ECDSA and vulnerability to ephemeral information), privacy v= ia deniability, offline signatures (specially significant with ECDSA).
<= br>
Finally, the advantage of a protocol built with cryptog= raphic logic, not as a accidental result of many years of patches. I believ= e the WG has delayed or never implemented in the past significant changes s= uch as Encrypt-the-MAC, OAEP, CBC IVs, session binding, etc. This time we c= an make it right from the begining.

Hugo
=

--001a11c35626890f3a0507965a6b-- From nobody Tue Nov 11 06:59:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033561A8A9B for ; Tue, 11 Nov 2014 06:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIcM2atfFJEk for ; Tue, 11 Nov 2014 06:59:37 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F6C1A8A95 for ; Tue, 11 Nov 2014 06:59:37 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id q107so7275012qgd.17 for ; Tue, 11 Nov 2014 06:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RCiVAphM3YNHNl8VbOJnAi+xMXBh2jKbJJnu5MDB8SA=; b=Xn5n5py+k3DuSHj+rlHKc2YTJwUDDMwnZWnmGm8GKq48WnCQGy/0UdLw6o0LWc7Wqo EyjXis9XibXBGRWvra55ePCNMeZoolq2MKmgEOA32Wdj4mYsdlukLEGI+jCFKQ07SYRG 5gJ6SYM7pzWz8YvLTP6Va9PxaxHWeQ5CnucM/3RQJWyUA/JUhVhMkMKxn+J7AyHgrD3M PclNxTJ9DnV879eL3qYQnuvUvqQ0/JlTI8jzEpcyyqpS2+REaSQFa+z2Tcj1oVZosq/x X6e13aUUfqnXF1rZHnz4DAqbjtjVmx4h5d32oeMFk9JChonsvjWSmOddt05SMoEW03s1 t1uA== MIME-Version: 1.0 X-Received: by 10.140.94.85 with SMTP id f79mr50593934qge.50.1415717976804; Tue, 11 Nov 2014 06:59:36 -0800 (PST) Received: by 10.140.20.199 with HTTP; Tue, 11 Nov 2014 06:59:36 -0800 (PST) In-Reply-To: References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> Date: Tue, 11 Nov 2014 06:59:36 -0800 Message-ID: From: Watson Ladd To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8kqk_s2vd-eLRWBRX2p9EtJHtPg Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 14:59:40 -0000 On Tue, Nov 11, 2014 at 6:46 AM, Hugo Krawczyk wrote: > Wait, wait, wait... > > I am surprised to see such an abrupt decision to drop consideration of > OPTLS. There is little information in the minutes as for the rationale for > this move although it seems to be entirely based on the handling of > static-DH certificates and the understanding that in the future one can > still run TLS 1.3 with ECDSA and/or ECDH certificates. > > Let me address these issues and the multiple advantages of OPTLS that need > to be considered. Please bear with me in spite of the long email. Since I > will not be in Hawaii (I wish I was...) take this in lieu of a presentation > at the WG meeting (and pardon the advertisement pitch, I believe it is fair > and well-founded). > > First, note that if we had ECDH certificates then this whole issue of how to > sign the static DH key g^s would be moot. You would use that certificate to > vow for the server's static DH key. Security would be based on the > protection of s exactly as it is based on the security of a private signing > key today. In particular, the key s would need to be kept online with the > same vulnerabilities (and potential protection) of a signing key today. > > The whole reason to create a "sub-certificate" for g^s by signing it with > the server's certified signature is that we currently only have certificates > for signature keys, not ECDH. This may or may not change in the future - > actually, as I argue below, there are advantages of sub-certs for g^s over a > long-term ECDH certificate. > > So what is the concern that has been voiced regarding the use of sub-certs > for g^s? That the leakage of a private key s that was sub-certified allows > to impersonate the server for the validity period of that sub-certificate, > and that clients with skewed clocks will be accepting it beyond the intended > validity period. This is true but not different than the situation with > current certificates. In particular, the validity period of the sub-cert > will never exceed that of the signing certificate. How about revocation? It > requires the main certificate revocation exactly as needed now. > > So none of these issues is worse than vulnerabilities of signing keys today. > Actually, there are two non-trivial advantages to the sub-cert approach: > - clients with good clocks (or small skews) will not accept g^s much past > its validity period, which would be typically much more limited than the > main signing cert. Clients with terrible skews will never be in worse shape > than they are today with respect to validating the signing certificate. > - a server can issue multiple g^s keys for availability, distribution, > sub-domain use, etc. and to support different groups ECDH groups - which > need to be supported anyway for PFS also in a signature-based protocol. > (There is also the ability to support online retrieval of currently > validated sub-certificates via protocols such as DNSSEC or other specific > mechanisms, even though there seems to be little enthusiasm for this option, > at least currently) > > The only downside I can see for sub-certification of g^s is for cases where > protection of an online signature key (as needed today) is better than the > one affordable to the key s, e.g. with current HSMs that support signing but > not ECDH. But this is the price of a looking-forward transition period as > opposed to proposals that keep us tied to the sub-optimality of past > solutions. It needs to be considered in light of the many advantages of a > signature-less protocol as claimed here. > > Let me now address the claim that in the future we will have ECDSA > certificates which would enable a signature-based protocol with less cost > than RSA signing today. This claim is mostly true but ignores some important > aspects of the use of ECDSA: > - The wide use of RSA in certificates is not going away any time soon - so > the very significant performance advantages of OPTLS vs a RSA-implemented > signature-based protocol is going to be enjoyed for long time (actually, it > may be a main motivation for adoption of signature-less TLS 1.3 in addition > to PFS) > - The total time of sign+verify in ECDSA is larger than the time of > static-DH authentication used in OPTLS. > - ECDSA presents definition and implementation complexities that do not > exist with ECDH, in particular tied to specific EC groups. In particular, > this is likely to postpone adoption of ECDSA. > - Online ECDSA signatures amplify the vulnerability of the long-term ECDSA > signing key to the leakage of ephemeral values (in ECDSA, as in other > Schnorr-like signatures, there is a per-signature random value that if > revealed, it fully reveals the long-term private signing key). Such > vulnerability does not exist in OPTLS. > - Signature-less protocols have a privacy advantage in providing plausible > deniability, especially when compared to protocols (as current 1.3) that > sign the peer's identity (I wrote on this in a previous message to this > list). > In addition, signature-less protocols can take advantage of sub-certs as > noted above. Even when the algorithm to sign these sub-certs will be ECDSA, > it will allow the use of Offline ECDSA hence ameliorating the above > vulnerability of ECDSA to ephemeral disclosure. > > And now to summarize some of the general advantages of ECDH-based (and > signature-less) protocols and some specific advantages of OPTLS: > - 0-RTT support required static ECDH keys (or semi-static, exactly as in > OPTLS) - thus in a signature-based protocol this support would be pure > overhead > - Critical performance gain relative to per-session signing with RSA (an > advantage that will most probably stay with us for long time) > - Compatibility with the already needed mechanisms to provide PFS (hence > amortizing any cost of the underlying crypto) > - Compatibility with pre-shared key authentication: simply replace g^{xs} > with PSK. > - Cryptographically, it relies on the ECDH security of the underlying EC > groups rather than relying on this security PLUS the security of signatures > (which means relying on the weaker of the two primitives) > - Other advantages mentioned above: Sub-cert time limitation and support for > multiple static ECDH keys if so desired, specific advantages with respect to > ECDSA-based protocols (complexity of ECDSA and vulnerability to ephemeral > information), privacy via deniability, offline signatures (specially > significant with ECDSA). > > Finally, the advantage of a protocol built with cryptographic logic, not as > a accidental result of many years of patches. I believe the WG has delayed > or never implemented in the past significant changes such as > Encrypt-the-MAC, OAEP, CBC IVs, session binding, etc. This time we can make > it right from the begining. I agree with what you say here: we need to get it right. However, EKR privately pointed out the following: once TLS 1.3 based on OPTLS is deployed, a user of TLS 1.2 who puts their private key in an HSM has a problem. If an attacker gains control of the box connected to the HSM they can sign a credential that permits permanent impersonation, and can do so even without the user upgrading to TLS 1.3. I don't think this is a major problem, and if we address it, it should be by designing a protocol that avoids it, not by hacking and patching TLS 1.2. Sincerely, Watson Ladd > > Hugo > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Nov 11 07:52:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF001A8AB2 for ; Tue, 11 Nov 2014 07:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiJPRNNEX_MG for ; Tue, 11 Nov 2014 07:52:25 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0983D1A8AB0 for ; Tue, 11 Nov 2014 07:52:25 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0Lfnn4-1YKlSf03uU-00pKrM; Tue, 11 Nov 2014 16:52:23 +0100 Received: by mail-ob0-f176.google.com with SMTP id va2so7527597obc.21 for ; Tue, 11 Nov 2014 07:52:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.102.211 with SMTP id fq19mr34051115oeb.2.1415721141958; Tue, 11 Nov 2014 07:52:21 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 11 Nov 2014 07:52:21 -0800 (PST) In-Reply-To: <546212B6.9020304@redhat.com> References: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> <546212B6.9020304@redhat.com> Date: Tue, 11 Nov 2014 16:52:21 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e01160a2ec481bb050797434c X-Provags-ID: V02:K0:S+jhw5HdHqJAo1f3Yul0RHBTmUZfNG3N3Z3g/lF9Whe RPEPhvS8G61IoigTIER3BD4XSX7UBFu3GsO5Ygt12XRjbRS6Oe sFYc5uCgXh2pR6oKC8Nzb7/jxI+R9m05LGGjaQRpR0tGCBXOt4 9hVPoTZEjKN0FjCk41DpLwga0j3Wr2rBVPG96TJefZABjM9His yLMl5pYWQWXsrd9Bd0T25+v2ETopi/4OyQgaFxJ9tiG7+Nkvzg eHgjxvr86DaFOW9koVgiZ2uFAW97RDVEE5NhAa9cACUxsHqJEY 4/FH4FQYrMoNca4BPInNABnutsFYL28wjkhzmVDCcbGRCgvEe4 +M3cFfpgMejRFjNKk9/D54egqPv1y80/lzF1QFUd6rKPRfwdlc DXRlumeiYy45hxWmiUWeIEIjzDUjb4fO1C3Ec0zLQfwSQTTJMR rgldl X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l-DYx6KornAdm8ZwU1TbR84Hl_I Cc: Florian Weimer Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 15:52:26 -0000 --089e01160a2ec481bb050797434c Content-Type: text/plain; charset=UTF-8 Florian Weimer : > Section 3 still does not mention which version to put into the > inappropriate_fallback alert message. Good point; it can't hurt to be completely explicit about this. Proposed new wording: o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the highest protocol version supported by the server is higher than the version indicated in ClientHello.client_version, the server MUST respond with a fatal inappropriate_fallback alert *(unless it responds with a fatal protocol_version alert because the version indicated in ClientHello.client_version is unsupported). The record layer version number MUST be set to ClientHello.cipher_suites for this alert (as it would for the Server Hello message if the server was continuing the handshake)*. Bodo --089e01160a2ec481bb050797434c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Flor= ian Weimer <fweimer@redhat.com>:
=C2=A0
Section 3 still does not mention which version to put into the inappropriat= e_fallback alert message.

Good point; it ca= n't hurt to be completely explicit about this.

Proposed new wording:

o If TLS_FALLBACK_SCSV appears in ClientHello.c= ipher_suites and the highest protocol version supported by the server is hi= gher than the version indicated in ClientHello.client_version, the server M= UST respond with a fatal inappropriate_fallback alert (unless it respond= s with a fatal protocol_version alert because the version indicated in Clie= ntHello.client_version is unsupported). The record layer version number MUS= T be set to ClientHello.cipher_suites for this alert (as it would for the S= erver Hello message if the server was continuing the handshake).
<= /div>

Bodo
--089e01160a2ec481bb050797434c-- From nobody Tue Nov 11 08:50:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F61A0053 for ; Tue, 11 Nov 2014 08:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaSWwJkZhYx7 for ; Tue, 11 Nov 2014 08:50:26 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 490431A0027 for ; Tue, 11 Nov 2014 08:50:26 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 878F81B4059; Tue, 11 Nov 2014 08:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=IeYgRg5a4WcR/f jaKnE4+Tn3Jiw=; b=TY8O5dZUIu6AJ2bFS7+FT9oeFx6RPYgzWrWxsL/+8CeFvU 9a8aoaN5RevYnIxNsWgxyjJbQl8Rg0+VQCK4xwuLEIS/jCxsu6Pbi0aHLeQJ4Wb7 shfnNhJdQ3TiouEE2oHiZL0Hl31IkFcJYxYupQoWPYu7nZXE+hLiPjcoDA7bw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id 463311B4058; Tue, 11 Nov 2014 08:50:25 -0800 (PST) Date: Tue, 11 Nov 2014 10:50:24 -0600 From: Nico Williams To: Daniel Kahn Gillmor Message-ID: <20141111165022.GI3412@localhost> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5461A3DD.4030102@fifthhorseman.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AvsRddwRqxJ6o4V6PvxDHiUBG3w Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 16:50:27 -0000 On Mon, Nov 10, 2014 at 07:51:25PM -1000, Daniel Kahn Gillmor wrote: > On 11/10/2014 04:12 PM, Nico Williams wrote: > > The time should be relative, as a TTL. > > relative to what? Relative to the time the server made the signature. The signature might need to be taken over a payload that includes a timestamp (see NTP thread) and/or a nonce from the client. > If the credential is standalone (e.g. in such a way that the signing key > can be kept offline) then the TTL established can be replayed by an > attacker who takes control of the DH secret to extend the lifetime of > the delegated credential, right? It has to be tied to the delegation act, the signature made with the delegator credential. > if the credential isn't standalone (i.e. if it's accepted by the client > based on its inclusion in the signed handshake which has been > authenticated by a signature from the signing key), then we aren't in a > signature-less TLS scheme. Well, sure we are: most of the time, just not all of the time. > if it's not relative, but it's long-lived, then we introduce a new > revocation problem. if it's not relative and it is short-lived, then we > introduce interesting clock skew issues (though perhaps those are the > same as OCSP-must-staple clock skew issues?) Right. Nico -- From nobody Tue Nov 11 09:16:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6831A00A9 for ; Tue, 11 Nov 2014 09:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9YJes0kb6UG for ; Tue, 11 Nov 2014 09:16:32 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FF01A00A6 for ; Tue, 11 Nov 2014 09:13:33 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sABHDVNt008765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 11 Nov 2014 12:13:31 -0500 Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sABHDURZ002263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 12:13:31 -0500 Message-ID: <546243B9.20309@redhat.com> Date: Tue, 11 Nov 2014 18:13:29 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> <546212B6.9020304@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S8bXYhNMg1hASDAr6fp-5lecBbM Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 17:16:34 -0000 On 11/11/2014 04:52 PM, Bodo Moeller wrote: > Florian Weimer >: > > Section 3 still does not mention which version to put into the > inappropriate_fallback alert message. > > > Good point; it can't hurt to be completely explicit about this. > > Proposed new wording: > > o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the > highest protocol version supported by the server is higher than the > version indicated in ClientHello.client_version, the server MUST > respond with a fatal inappropriate_fallback alert *(unless it > responds with a fatal protocol_version alert because the version > indicated in ClientHello.client_version is unsupported). The record > layer version number MUST be set to ClientHello.cipher_suites for > this alert (as it would for the Server Hello message if the server > was continuing the handshake)*. The final ClientHello.cipher_suites should be ClientHello.client_version. -- Florian Weimer / Red Hat Product Security From nobody Tue Nov 11 09:19:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6731A00CD for ; Tue, 11 Nov 2014 09:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_11=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs47CuTsW01n for ; Tue, 11 Nov 2014 09:19:39 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2081A0086 for ; Tue, 11 Nov 2014 09:19:39 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 54AF32006D30F; Tue, 11 Nov 2014 09:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=/3V7tfKsU17GNM 256s7pbakPQjg=; b=VBaeX46UFgKzrUwyeAAIQ8YnAlj5FNCdRXU7EEwW9pETS4 ewMF7EkRKsqrUyIJul+JVZVYHG+TQmvNgtNah7fCe8sy6uQ/rUY4BduEl5Iwf42N bLf29v409yfnHbtIKvevIZkn1PvqsdYXYbkC12LWdvoosyWN0mA79uSOZ+QOg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id E469F2006D30A; Tue, 11 Nov 2014 09:19:38 -0800 (PST) Date: Tue, 11 Nov 2014 11:19:38 -0600 From: Nico Williams To: Watson Ladd Message-ID: <20141111171936.GJ3412@localhost> References: <87r3xdfzi1.fsf@alice.fifthhorseman.net> <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5J26JHYChYXeeC4stKMOQLM1ZeY Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 17:19:41 -0000 On Mon, Nov 10, 2014 at 09:00:06PM -0800, Watson Ladd wrote: > On Nov 10, 2014 4:52 PM, "Nico Williams" wrote: > > By putting a short lifetime on the delegation that problem goes away. > > But then there's no advantage over plain session resumption. > > Can we make 0-RTT resumption? Snap start doesn't do this, and my > proposal from the summer to do this was thought to not be that great. TLS session resumption with tickets looks almost exactly like Kerberos, and Kerberos definitely supports a 0rt mode: you send the AP-REQ and immediately start sending protected data, and when the server sends an AP-REP you switch to a new set of session keys. In the Kerberos case there's an understanding that there's been no key confirmation until you get the AP-REP. The GSS-API calls this understanding "prot_ready": the security context is ready to provide data protection services, but it's not fully established therefore it's not safe to assume that both peers are fully authenticated to each other. The API has a way to signal this. The question is: if there's something wrong with 0rt session resumption, isn't there also something wrong with Kerberos "prot_ready"? My take is: there's nothing wrong with it that we aren't already well aware of and that isn't fully captured in the security considerations of the GSS-API's prot_ready concept. (The same prot_ready point about authentication not being complete also applies to PFS.) > I do see a benefit, which is that session resumption as currently > envisioned involves keeping keys around that can decrypt old data. Yes, because that's the only way to make it go fast (all symmetric key crypto; no PK), and it's also why a short lifetime on the resumption credentials is important. Session resumption with additional PFS but no additional authentication would also be faster than non-resumption (for non-anon ciphersuites anyways), since there'd be just the (EC)DHE PK + the session resumption symmetric key crypto, but it would be slower than all-symmetric-key- crypto resumption, and it would have the sec. cons. given above as to when PFS is available. > Changing this means that TLS 1.3 resumption works differently than TLS > 1.2 resumption, which isn't a problem. We should at minimum fix this > PFS failure. I'm not up on the details. I think the right way to do this is as follows: - model resumption as Kerberos-like authentication and key exchange; - add optional PFS key exchange to resumption by having the client and server exchange (integrity-protected, with the resumption session key) (EC)DHE pubkeys, and switch to using the new PFS session keys as soon as available; (one way to handle this is to make TLS modular, even if only conceptually) - adopt the GSS-API prot_ready concept. Which yields: - 0rt for sending "prot_ready" data (no PFS, no key confirmation yet); - 1rt for sending data with PFS and key confirmation. Not bad. > > IMO the main value in static DH is in learning the server's static DH > > pubkey out of band, via DNSSEC (DANE). That eliminates all these > > concerns while enabling 0rt connections _every_ time for servers that > > have such keys. > > So we have a root cert with RSA 1024 bit RSA, or the same delegation That's either missing the forest for the trees (i.e., the root key can, and we can bet will, be upgraded to something stronger), or [likely justified] paranoia (i.e., the root key is kept weak on purpose). > point issue. It doesn't eliminate revocation concerns either: DNSSEC > doesn't guarantee liveness. (DNS can have dynamic data, but the size > is strictly limited, so stuffing a cert chain in is a bad idea). There's no stuffing of cert chains. You can always build and/or staple the chain (as Chrome supported, briefly). And there are timestamps in some of the relevant RRtypes. > > Of course, 0rt connections can't provide proper PFS to data sent > > immediately after the client's first TLS handshake message. That's a > > problem, no? > > They can limit the time the key is around, so an attacker has a narrow > window to steal the keys. I meant this: C->S: hello w/ resumption and ephemeral (EC)DH pubkey, CCS -no-PFS-> C->S: S->C: hello w/ resumption and ephemeral (EC)DH pubkey, CCS ----PFS-> C<->S: You can have 0rt w/o PFS. You can have 1rt w/ PFS. You can have both too with the GSS prot_ready concept. The problem, of course, is that in a complex protocol stack you might have no idea if the first application record *needs* PFS, so you have to assume that if PFS was requested, then it must be afforded, and you're back to needing 1rt. > There is another set of advantages beyond those mentioned above: TLS > 1.2 is annoying to think about for technical reasons, whereas OPTLS > had a good chance of avoiding those. We need to actually design a > secure protocol, not just spray and pray as we have in the past. There > was a 20 year gap between TLS 1.0, and the definitive security > analysis, which discovered new attacks, and is dependent on tool > support. A TLS 1.3 based on TLS 1.2 runs a risk of having significant > security holes in new features unless we take care to do the analysis > before deploying. A new protocol has its costs too. Both, new design, and extension, have one-time costs, and both require careful analysis. I'm not convinced that TLS 1.2 is DoA here, but I'd love to see a fresh start if that's realistic. Among many benefits it'd give existing implementations' devs a great excuse to clean house. But again: is it realistic? > I feel the delegation problem was clearly spelled out in Hugo's > message describing the protocol. What I don't understand is why it is > a problem to have a duration-limited credential equivalent in power to > a certificate. Since there is no recording, I can't figure out what > was said and what convinced everyone this was a bad idea. No recording? That's terrible, unacceptable even. Can we do better than that for interims, *please*?? I've attended interim WG meetings for other WGs in the past. I know it's a low-tech affair by comparison to normal IETF meetings, but TLS WG interim meetings are potentially highly consequential! > I've looked at the minutes but they are extremely sparse. What was the > worry associated with complicating the key schedule? Can someone > summarize the argument about delegation, so I can figure out if it > convinces me or not? Seconded. Nico -- From nobody Tue Nov 11 09:33:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDB41A0140 for ; Tue, 11 Nov 2014 09:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs140l_5OTpU for ; Tue, 11 Nov 2014 09:33:28 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8336B1A0145 for ; Tue, 11 Nov 2014 09:33:28 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 5478120047B87; Tue, 11 Nov 2014 09:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KcAKqYsN5iBodE zdhKg0z8M9ra4=; b=VQQBKFvQx1JYe97TzRXMchitvm+Ckl22QXcYqC0P7OeYB+ erdszKfinq6X/9nvlEK+2yuawbMw3HyUX2nfoi6MEdtw+vfAIvbiFlEgYZg6OUBo GY9XGd1Xgw4OE3nqaI9gVrE80eA/kkENTuqCXGfNiUJzt1cSoZWEEGUmaRZIQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id DACE420047B85; Tue, 11 Nov 2014 09:33:27 -0800 (PST) Date: Tue, 11 Nov 2014 11:33:27 -0600 From: Nico Williams To: Hugo Krawczyk Message-ID: <20141111173325.GK3412@localhost> References: <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZagQxJuM--JbfrQW5f3flvO15TA Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 17:33:30 -0000 On Tue, Nov 11, 2014 at 09:46:38AM -0500, Hugo Krawczyk wrote: > I am surprised to see such an abrupt decision to drop consideration of > OPTLS. [...] I didn't see such a decision. Just a lot of questions. > First, note that if we had ECDH certificates then this whole issue of how > to sign the static DH key g^s would be moot. [...] Yes, though there'd be no 0rt the first time a client meets a server (unless DANE is used). > The whole reason to create a "sub-certificate" for g^s by signing it with > the server's certified signature is that we currently only have > certificates for signature keys, not ECDH. This may or may not change in That and the fact that we can't have intermediate CA certs because of the lack of implementation (and deployment) of naming constraints, nor can we have proxy certs [RFC3820] -I think, but correct me if I'm wrong- for similar reasons. (Note that RFC3820 proxy certs have no revocation mechanism.) > the future - actually, as I argue below, there are advantages of sub-certs > for g^s over a long-term ECDH certificate. Isn't "sub-cert" ~= proxy cert? > So what is the concern that has been voiced regarding the use of sub-certs > for g^s? That the leakage of a private key s that was sub-certified allows > [...] That the "sub-cert" needs either a revocation scheme (not likely) or a short lifetime. The latter puts this on a par with session resumption, thus making one (well, me) wonder what the advantage to the static DH concept would be. We could put static DH keys in DNSSEC and learn them that way, which would get us 0rt. > to impersonate the server for the validity period of that sub-certificate, > and that clients with skewed clocks will be accepting it beyond the > intended validity period. This is true but not different than the situation > with current certificates. In particular, the validity period of the > sub-cert will never exceed that of the signing certificate. How about > revocation? It requires the main certificate revocation exactly as needed > now. > > So none of these issues is worse than vulnerabilities of signing keys today. Server certificates can be revoked (wellll). Delegations can't be, not without losing the optimization value of delegation in the first place. That seems like a deal killer for anything other than short-lived delegation. Nico -- From nobody Tue Nov 11 10:49:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AEC1A1A5E for ; Tue, 11 Nov 2014 10:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1lrKQw2escL for ; Tue, 11 Nov 2014 10:49:41 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C820B1A036A for ; Tue, 11 Nov 2014 10:49:40 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 083F51A007A; Tue, 11 Nov 2014 19:49:32 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L2JNooWz4ERS; Tue, 11 Nov 2014 19:49:24 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id EF5461A006C; Tue, 11 Nov 2014 19:49:23 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 11 Nov 2014 19:49:30 +0100 Message-ID: <54625A39.70700@secunet.com> Date: Tue, 11 Nov 2014 19:49:29 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Oleg Gryb , "tls@ietf.org" References: <2116033100.449850.1415678543902.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> In-Reply-To: <2116033100.449850.1415678543902.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_fmycKZVagXs_xU1FpI07o5kAfo Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 18:49:43 -0000 > I was going through SafeCurves pages recently and wanted to ask a question about brainpoolP256r1's twist security. > According to this research http://safecurves.cr.yp.to/twist.html,, a combined > cost of attacks on brainpoolP256t1, which is a P256r1's "twist" is rather low. At the same time it's obvious that > small-group-attack is not applicable, because "h=1" is a requirement for all brainpool curves including the one under > consideration. This is a misunderstanding. The term "twist security" refers to non-quadratic twists (B/u)y^2=x^3+Ax^2+x, where u is a non-square in F_p. RFC 5639 considers "quadratic twist", where u is a square in F_p. Quadratic twists are isomorphic to the original curve and provide equivalent security. Therefore, brainpoolP256t1 is as secure as brainpoolP256r1. In contrast, the non-quadratic twists of brainpoolP256r1 are not secure, because their group order does not have a large enough prime factor, i.e., the cofactor is huge. > > The other two "invalid-curve" attacks should be mitigated by openssl controls, since latter does have a > point-on-the-curve validation (e,g. see EC_POINT_is_on_curve function and its usage in the latest openssl stable versions). > Twist security is only relevant, if you use an arithmetic on the x-coordinate only (Brier-Joye ladder) and don't perform point-on-the-curve validation. I am quite sure that openssl avoids both, i.e., computes on both coordinates and performs point-on-the-curve validation. Therefore, twist security is irrelevant here. x-coordinate arithmetic is generally quite slow for Weierstrass curves, and point-on-the-curve validation is mandated by the relevant standards. Therefore, twist security should be hardly an issue anywhere. -- Johannes From matt@openssl.org Tue Nov 11 01:28:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FE21A8894 for ; Tue, 11 Nov 2014 01:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIYfNaCbKnw1 for ; Tue, 11 Nov 2014 01:28:35 -0800 (PST) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 103101A8893 for ; Tue, 11 Nov 2014 01:28:35 -0800 (PST) Received: from [192.168.2.64] (host86-158-97-20.range86-158.btcentralplus.com [86.158.97.20]) by ns3.dns-engine.com (Postfix) with ESMTPA id EB6AB18002CC for ; Tue, 11 Nov 2014 09:28:32 +0000 (GMT) Message-ID: <5461D6C0.2060101@openssl.org> Date: Tue, 11 Nov 2014 09:28:32 +0000 From: Matt Caswell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LUsD0vGjPvUwoXv21fRTz6K2Iuw X-Mailman-Approved-At: Tue, 11 Nov 2014 10:55:45 -0800 Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:41:40 -0000 On 10/11/14 23:17, Martin Thomson wrote: > (UTA on BCC) > > The POODLE attack has been used across the industry to justify disabling SSLv3. > > For some of us, this was just the excuse, but others might need more > motivation. A statement from the IETF might help move some people. > > Richard, Alfredo, Adam and I have proposed such a statement: > > https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/ This sentence gave me pause for thought: "Servers SHOULD accept handshakes from clients that propose SSLv3 or higher, but MUST NOT negotiate SSLv3" I found that quite a confusing sentence and had to read it a couple of times. The "or" suggests that "servers SHOULD accept handshakes from clients that propose SSLv3 (only)"...and then goes on to contradict itself. Perhaps something like "Server SHOULD accept handshakes from clients that use a record layer version of {03,00} (SSLv3), but MUST NOT negotiate SSLv3" Matt From nobody Tue Nov 11 11:06:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD081A6F33 for ; Tue, 11 Nov 2014 11:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIrtWUwxoy8i for ; Tue, 11 Nov 2014 11:06:25 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF41F1A1A78 for ; Tue, 11 Nov 2014 11:06:20 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id s18so10210005lam.13 for ; Tue, 11 Nov 2014 11:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sPau3O42/8K24OIDntyUrXwDOjoByRXO7vnHx5B9cq0=; b=prxSdiNoBioPWwi9nGETATDXSldfgNseIzG96U9JMuoOrlHJG4bZZU0T5yQBBtHI/7 qdKrtX5azjub5QP0KJbPaFRAooG68JlknKG70tmexW2y/aXAgyxLMSrsNGTPieaSYR1k ku3XIb/1GZBZC3y/Svt4qOGEDOheY+F3YTJnqfWfajHuK66YYpEYVTXy1MFWS3VKH744 C01TwCcrAUqmaermIGK/MKBTcH7cgYY7HG9UpAWVjM2fzL2MZ8X+ziI6LOrxLL98Z5nU KnVLdJeQ3fR18wUKln8FhLmaVlXR3nBPoyxZWJnOeIaKnb42uDCeezkYlgl0x9DKy5z/ Qa9g== MIME-Version: 1.0 X-Received: by 10.152.204.99 with SMTP id kx3mr38127235lac.53.1415732778055; Tue, 11 Nov 2014 11:06:18 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 11:06:17 -0800 (PST) In-Reply-To: <5461D6C0.2060101@openssl.org> References: <5461D6C0.2060101@openssl.org> Date: Tue, 11 Nov 2014 11:06:17 -0800 Message-ID: From: Martin Thomson To: Matt Caswell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DCyY9V9eKVN903cgamLB_rfynFU Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:06:28 -0000 On 11 November 2014 01:28, Matt Caswell wrote: > "Server SHOULD accept handshakes from clients that use a record layer > version of {03,00} (SSLv3), but MUST NOT negotiate SSLv3" Thanks. I will make that change. https://github.com/unicorn-wg/sslv3-diediedie/pull/10 From nobody Tue Nov 11 11:25:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99361A873D for ; Tue, 11 Nov 2014 11:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGtmQOMQEfYG for ; Tue, 11 Nov 2014 11:25:09 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE2F1A8766 for ; Tue, 11 Nov 2014 11:24:55 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id l4so8295166lbv.12 for ; Tue, 11 Nov 2014 11:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XCJM9hPqr7vX8IOvudM1KHDfedpB8k4sBdFcZdB3tT4=; b=NOEQT732YOvyz32Tn2spHy7Nl0hbE48cvkoHZ2/dqnfJn5COPyaARbXvV7R2pu0uG2 /c5Ji9myirrhGVji8e4sxiSGia0AVIQ5JFh5cI8Q1J8JiDGwr5xqldBewiUX8Z/6K4Yl HWBUG8Gqx3odDNeM/E9x6+H8K9ktkrE1Z5cvgLqAAM0H0wSdDhtDUsxvGLtdR86q6/bQ RyZdLbwknSkuNT83wwiAo3gEmtS5S0vOUfmPfNAnD+WQc/1E4XA2YTLHOBoBN4LtYDbB GVlNRhaA7H4cR3Bnphbx8fvW7mSV3EtQgmr+rWnemV8ncgMZN2OXk9542T3c5mz0CssN O+Eg== MIME-Version: 1.0 X-Received: by 10.152.204.70 with SMTP id kw6mr11083483lac.85.1415733893376; Tue, 11 Nov 2014 11:24:53 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 11:24:53 -0800 (PST) In-Reply-To: References: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> <546212B6.9020304@redhat.com> Date: Tue, 11 Nov 2014 11:24:53 -0800 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/txKpSE4WIDMCLuyWRispB8Y5OYo Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:25:10 -0000 On 11 November 2014 07:52, Bodo Moeller wrote: > The record layer version number MUST be set to ClientHello.cipher_suites for > this alert (as it would for the Server Hello message if the server was > continuing the handshake). I think that you mean ClientHello.client_version for the record layer. From nobody Tue Nov 11 11:41:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36241A87D7 for ; Tue, 11 Nov 2014 11:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Byta2rquFi for ; Tue, 11 Nov 2014 11:41:38 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476241A889B for ; Tue, 11 Nov 2014 11:41:28 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0LdVp4-1YEECN3Occ-00io1A; Tue, 11 Nov 2014 20:41:26 +0100 Received: by mail-oi0-f51.google.com with SMTP id g201so7522192oib.38 for ; Tue, 11 Nov 2014 11:41:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.128.139 with SMTP id b133mr32467913oid.52.1415734883507; Tue, 11 Nov 2014 11:41:23 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 11 Nov 2014 11:41:23 -0800 (PST) In-Reply-To: References: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> <546212B6.9020304@redhat.com> Date: Tue, 11 Nov 2014 20:41:23 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ef442d3e5ae05079a7639 X-Provags-ID: V02:K0:aFo2cBsclURxIhxybfEob9VvxPRLdvNrT4HCv2V9n3N lZa4RNxUetlT/qUzfPZgbAqvsf65O+he6uz0/4qDtWJJLtMkQJ hMBdWEudUA+HNJHFTPRoMAm/1hh3mccPh2RQnNxN7KvK/X+1oR WC0YtZF08/iiC66tRL8joEsqAj1LVZCjax9ic2FCMllLnlE5Pj GNvZ0HQnbC4wBAJUsO0ZM9tRm7eSfRo8FAPCF0vqHRIMRi/gEu x/yvX3Qdu+69wZi8IBmw7OXyXkBlkclnyolnnInEbSL+ZA8UEM Y/6JpCvjCHY0amb9xMsgBDumdmaKsZg9h0ojjuDTQbOp4RC9a+ e6MU9RBtYo+PtvyXySr2td/b8b/gyxXJis43rByMnEV7y4dlD6 JNSW02aMPnJuXhlqKCPQLII2kp4qbbuqJ8wPSMFSqOC4qk28ny Jd0Zi X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eMLWwnGR-oAVM6kKGDU9CnT0JGo Cc: Florian Weimer Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:41:39 -0000 --001a113ef442d3e5ae05079a7639 Content-Type: text/plain; charset=UTF-8 > > [...], the server MUST respond with a fatal inappropriate_fallback alert *(unless > it responds with a fatal protocol_version alert because the version > indicated in ClientHello.client_version is unsupported). The record layer > version number MUST be set to ClientHello.cipher_suites for this alert (as > it would for the Server Hello message if the server was continuing the > handshake)*. > > Thanks to Yngve, Florian, and Martin for the correction -- of course, that version number must be set to ClientHello.client_version; I have fixed my working copy accordingly. Bodo --001a113ef442d3e5ae05079a7639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[...], the server MUST respond with a fatal inappropriate_fallback= alert (unless it responds with a fatal protocol_version alert because t= he version indicated in ClientHello.client_version is unsupported). The rec= ord layer version number MUST be set to ClientHello.cipher_suites for this = alert (as it would for the Server Hello message if the server was continuin= g the handshake).

Thanks to Yngve, Florian, and Martin for the correction -- = of course, that version number must be set to ClientHello.client_version; I= have fixed my working copy accordingly.

Bodo

--001a113ef442d3e5ae05079a7639-- From nobody Tue Nov 11 11:42:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15211A88C3 for ; Tue, 11 Nov 2014 11:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llrauikps9DA for ; Tue, 11 Nov 2014 11:42:02 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7B81A883B for ; Tue, 11 Nov 2014 11:42:01 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id C6C343A209; Tue, 11 Nov 2014 20:41:59 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B8D3441A04; Tue, 11 Nov 2014 20:41:59 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B1EC81AFBA; Tue, 11 Nov 2014 20:41:59 +0100 (CET) In-Reply-To: To: Martin Thomson Date: Tue, 11 Nov 2014 20:41:59 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141111194159.B1EC81AFBA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8C12aRGV5890Ym0oKebhYhPvVZU Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:42:03 -0000 Martin Thomson wrote: > On 11 November 2014 07:52, Bodo Moeller wrote: > > The record layer version number MUST be set to ClientHello.cipher_suites for > > this alert (as it would for the Server Hello message if the server was > > continuing the handshake). > > I think that you mean ClientHello.client_version for the record layer. ClientHello.cipher_suites as written by Bodo and echoed by Florian does not make any sense to me (not only because a list of integers can not possibly fit into a single integer. But I do _not_ think that a MUST for ClientHello.client_version would be appropriate for an fatal alert that is sent instead of ServerHello. For alerts that early in the handshake a server may for simplicity reuse the record layer protocol that was used for the in coming ClientHello. -Martin From nobody Tue Nov 11 11:47:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75E1A8945 for ; Tue, 11 Nov 2014 11:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKikGawTf-7n for ; Tue, 11 Nov 2014 11:47:46 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035481A8957 for ; Tue, 11 Nov 2014 11:47:30 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so2743733wiw.3 for ; Tue, 11 Nov 2014 11:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yVXlFqIgCaIBDKgqThP2hDEu7CSWagq68iRRSn8zoWo=; b=rwd0Zpe44mJbpntD7dUqPx1cubi4KS08O+t0/qOr7rZG9yZSXYGjXKffL1/NBlZt/h eWEVwMh4rQ7Bg9kiIZZHDKTso6z+nN+9neFN04CrRYHiNkjFXcsL+r6mo4DLC0exP3To 02gPBc+ZoL6f4Qpg74tWGwQ+Oy16yhtO2Vqfkyu5fCR4ydFLCHidV5kUfzih3AoJoWuD 2F1gCkZvPxtNI5l/Irz5olxaVr9bVwlOIwkVRrV+UYKyHPRMrQauG6kZ/eFH18bMsxkj pVooEM6TIbvaeotH4+hDUq8dPIqJD+iS5qvciJ4KTsv4vNWeRB29DmNig7A2fR0HYwFk c78w== X-Received: by 10.180.100.104 with SMTP id ex8mr39139117wib.80.1415735248727; Tue, 11 Nov 2014 11:47:28 -0800 (PST) Received: from t2001067c037001609c4604f98381795f.wireless.v6.meeting.ietf.org (t2001067c037001609c4604f98381795f.wireless.v6.meeting.ietf.org. [2001:67c:370:160:9c46:4f9:8381:795f]) by mx.google.com with ESMTPSA id lp14sm16814456wic.20.2014.11.11.11.47.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 11:47:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <20141111173325.GK3412@localhost> Date: Tue, 11 Nov 2014 09:47:23 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> References: <87r3xawv8a.fsf@alice.fifthhorseman.net> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NEiz-1gyGVQZFdB18HFfa-Q2qyA Cc: Hoeteck Wee , "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:47:50 -0000 > On Nov 11, 2014, at 7:33 AM, Nico Williams = wrote: >=20 >> So what is the concern that has been voiced regarding the use of = sub-certs >> for g^s? That the leakage of a private key s that was sub-certified = allows >> [...] >=20 > That the "sub-cert" needs either a revocation scheme (not likely) or a > short lifetime. The latter puts this on a par with session = resumption, > thus making one (well, me) wonder what the advantage to the static DH > concept would be. There is a revocation scheme. If the private ECDH key is lost, you = revoke the certificate, thereby invalidating the delegation. > We could put static DH keys in DNSSEC and learn them that way, which > would get us 0rt. Another possibility is to place the ECDH public key in a certificate = extension. This gives it a lifetime as long as the certificate, and it = doesn=E2=80=99t matter whether the =E2=80=9Cregular=E2=80=9D certificate = public key is RSA or ECDSA or anything else.=20 It removes the need to use signatures at all by the server. Not even = once. Yoav From nobody Tue Nov 11 11:50:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6F61A8917 for ; Tue, 11 Nov 2014 11:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rd03vERbbx1 for ; Tue, 11 Nov 2014 11:50:54 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155131A8911 for ; Tue, 11 Nov 2014 11:50:54 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id z11so1406750lbi.25 for ; Tue, 11 Nov 2014 11:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KmMwCR0Xir7F4bqq/Goqoo45pdOz6dAPNBgfdH6p/QU=; b=KOoL05zSZzwd/A/tA6Q9w9ucmT46pdUeEz32I1ZHUhbJCSxy8Sc9qa9pGLvbzIomPM YiF2wQAEzm5Ehu3INeYiVxqvlCnzsp1w491KP5hLWGge8uW4knwnTNO+D/dRFWbHQRA4 iISlN+KX22s+0Svlk1a9w53MIwlWhV03H9QHnM3KeNLwZCIK9ZS6DK+PaIpcAImD7ne5 xV/Lszp8P2wXLH8sO+jmDlRqL+BO8omjPgcIpVJ+ky8rhIAtg0xVXgNQXw5COdNma6pJ MFMbuoJPIzAGpWMCLUbg1SPHoUsfJKt3BBiG+ZtPHhu6HQnltFaO4BlGpmzynTkB0I7d Oplg== MIME-Version: 1.0 X-Received: by 10.112.199.40 with SMTP id jh8mr38346835lbc.5.1415735452615; Tue, 11 Nov 2014 11:50:52 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 11:50:52 -0800 (PST) In-Reply-To: <20141111194159.B1EC81AFBA@ld9781.wdf.sap.corp> References: <20141111194159.B1EC81AFBA@ld9781.wdf.sap.corp> Date: Tue, 11 Nov 2014 11:50:52 -0800 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PYnEEgGxsEkHudmnsdO4frckbY4 Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:50:57 -0000 On 11 November 2014 11:41, Martin Rex wrote: > But I do _not_ think that a MUST for ClientHello.client_version > would be appropriate for an fatal alert that is sent instead > of ServerHello. For alerts that early in the handshake a server > may for simplicity reuse the record layer protocol that was used > for the in coming ClientHello. I think that's reasonable. I think that we sometimes echo the record layer protocol version, depending on how far we are through the handshake processing. I can see why you wouldn't want to dictate this so strongly. From nobody Tue Nov 11 11:52:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141E61A88EE for ; Tue, 11 Nov 2014 11:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTw159fVrLCA for ; Tue, 11 Nov 2014 11:52:46 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20211A883B for ; Tue, 11 Nov 2014 11:52:45 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0M5Kwt-1YDO7g1qTH-00zWRk; Tue, 11 Nov 2014 20:52:43 +0100 Received: by mail-oi0-f51.google.com with SMTP id g201so7509987oib.24 for ; Tue, 11 Nov 2014 11:52:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.155.34 with SMTP id vt2mr34276360oeb.34.1415735556154; Tue, 11 Nov 2014 11:52:36 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 11 Nov 2014 11:52:36 -0800 (PST) In-Reply-To: <20141111194159.B1EC81AFBA@ld9781.wdf.sap.corp> References: <20141111194159.B1EC81AFBA@ld9781.wdf.sap.corp> Date: Tue, 11 Nov 2014 20:52:36 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6c550ebb0fc05079a9e01 X-Provags-ID: V02:K0:kVKYdkwTZdum1anEVsbeTTSzPhpMNwwcLypQcaGnUj9 UceH40mMDyOPUxsdiXS4medaZW9cHhucbo6cf9es+WFYvjoNkJ kUkks3eRwTDv5TaCjRPy5Au2F4GZjA2UNcbftIU3qnO9/Sd7G2 GyvtLpxM9HQjW++R+w0oDIp1FBaXLDxSj0UaGmYRmxabwDCU+O G+3c8kgAys3mkIXLBGvE4fQPxjOMbHxiTz2lV0U7zg4ZphgQlu R/svkbtgNcCLZiv6/0Kxp5xOF+LhcGXhgsQy64D0OvNVdIPFKy Mk/VCariF3JSo8mdPqpWg/C//IbKznM1Rc3M4FKNDA5UqLFCqC 4CNV/4qaP4/hvkj0R/uSnXYUTnZzg+fofpmeb19/jkJYoTAmwW ZYASCs0DodTJHPhmX/Fvd1RQFGUdBbAmYgfuh6h/DuDJLxOdmT qNkyI X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mt3aS1l15SkRCuAD3gNLkacYZTM Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:52:47 -0000 --047d7bd6c550ebb0fc05079a9e01 Content-Type: text/plain; charset=UTF-8 > > But I do _not_ think that a MUST for ClientHello.client_version > would be appropriate for an fatal alert that is sent instead > of ServerHello. For alerts that early in the handshake a server > may for simplicity reuse the record layer protocol that was used > for the in coming ClientHello. God point. If the record-layer version number differs from ClientHello.client_version, the client should really be ready to accept both version numbers. So what about the following? [...] The record layer version number for this alert MUST be set to either ClientHello.client_version (as it would for the Server Hello message if the server was continuing the handshake), or to the record layer version number used by the client. Bodo --047d7bd6c550ebb0fc05079a9e01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But I do _not_ think that a MUST for ClientHello.client_versio= n
would be appropriate for an fatal alert that is sent instead
of ServerHello.=C2=A0 For alerts that early in the handshake a server
may for simplicity reuse the record layer protocol that was used
for the in coming ClientHello.

God point.= =C2=A0 If the record-layer version number differs from ClientHello.client_v= ersion, the client should really be ready to accept both version numbers. S= o what about the following?

[...] =C2=A0The record layer version numbe= r for this alert MUST be set to either ClientHello.client_version (as it wo= uld for the Server Hello message if the server was continuing the handshake= ), or to the record layer version number used by the client.

Bodo

=C2=A0
--047d7bd6c550ebb0fc05079a9e01-- From nobody Tue Nov 11 12:11:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8864C1A0231 for ; Tue, 11 Nov 2014 12:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX8ZK6uuqON2 for ; Tue, 11 Nov 2014 12:11:20 -0800 (PST) Received: from nm40-vm2.bullet.mail.bf1.yahoo.com (nm40-vm2.bullet.mail.bf1.yahoo.com [72.30.239.210]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8868F1A01CB for ; Tue, 11 Nov 2014 12:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1415736679; bh=gzci818qRjv0xM/NgSkaiEsxLN1RHtx7yAZYXJRcc7c=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=MfVeCgZQAFJ/2uoaAkxcVLt1mUURZqiR3PJDQ/wOndAmRM7ZD6yNuDH3J2EFZU6zqrmJyND/9/0aixlWGbD/uGwVVTNj+RUiSZ2PUFfxxLKH2J5A9sGCkThCI2IonGV2S8+/ERrV17SHFNu3niCLbf+GVRiOOW3AdP8HRm6OhWZ6hg2HgGVV9//juX1Zcc6nyHk53/lks3mGJtZLx/6INU5RWlzpCRMm7UzxK6mjFz/S40VtwLWvfNw6epqvbld37LoD1PaUv/utJtr3SpUyOALYr4gGyEMk8u1yyLHb3sffGXInzILPJR7cDq4m2mFi52AiwXSEDAl0XaTfG/pxig== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=WzekA/JJYAM/l9ucSmgw56jdPwC3eiPymjpHkCsDisW963iAYaMEynPg4/CHj7/pBlk+ZVsL/qt7pEgwjN2gwce0Klzjf8nIroZi+UrFvpxX6kUHH5CQUlTHr8Pq0xFXxiK/AoGTvayKQAX9E8AS5jPqCBKhk0/D3vYjriGpmJIgdauAen/Sud2LHxqByKgu5eTta2BGQGGDDD0sRtbG/icloZN9ApO0kf302A9sSGupTHAhuiRC7qszJt2CXtgAMQvJGkqqdvQpjQK/cqKAH06Yy82c5aeSPrkaE/zTg6eH5bjcQhnef2sPiWiTkObUEOAi23JBLFmJmNPFQQxJHQ==; Received: from [98.139.215.140] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 20:11:19 -0000 Received: from [98.139.212.235] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 20:11:19 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 20:11:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 642885.76008.bm@omp1044.mail.bf1.yahoo.com X-YMail-OSG: HryRX8UVM1nX1Sz_gCn9phuX.jd_v15XQrWFLuuTr7AuDFpax5sk5K5WcF2Ec.e qEY.MAqWNYNwG2ZcL0QH3DU3uRs5JaEsa9JMds6BR7TyP6BfGnmPoSRIuUq4VEGhKWYDEROSxoxc B0JDy5bjpSoB7mKbYIsfZls92o48BeJuQtv15TIbSBPYegt.skxIZaw_fIC..zRW3wVWd5PjtT5m 0qcQe5qd3yavqquGTM55UQxkPq5vtzVRGOn2LIWQdif0uk78RsIwv.MlMajrZfjGimExw7kyBwX7 8KJut6rbvt_gsv2.LJPzssFAYbhssK87QF7IVdDbAL7XLR1CS8TS6lnvJRQY9N9sm2M7c787TxH3 i.K9kNLRVxtoT4Snq_sD_1YEkW53G06u7eESOwuPmHL9hbRWAepyQqEOXI.cwwksF8GoFA2K1rL2 s4Yns0rvrtz0PLF6cxp7BDBftSK5_1FVP3jIdnDWcadaknkiDtZ7bP5frkyhFfHxlFk6t6HUvKLA 0iO6kzVQhN.IggdrLrcJ1Hy9COEKRGvpr7kVxV.IPgXheSGQQetModfplZDP9idyE4SI- Received: by 76.13.26.142; Tue, 11 Nov 2014 20:11:19 +0000 Date: Tue, 11 Nov 2014 20:11:16 +0000 (UTC) From: Oleg Gryb To: Johannes Merkle , Oleg Gryb , "tls@ietf.org" Message-ID: <1437313076.601391.1415736676771.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> In-Reply-To: <54625A39.70700@secunet.com> References: <54625A39.70700@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VaK6hasRCQ84A1-lp4sChpLAdc8 Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:11:22 -0000 >> I was going through SafeCurves pages recently and wanted to ask a question > about brainpoolP256r1's twist security. >> According to this research http://safecurves.cr.yp.to/twist.html,, > a combined >> cost of attacks on brainpoolP256t1, which is a P256r1's > "twist" is rather low. At the same time it's obvious that >> small-group-attack is not applicable, because "h=1" is a > requirement for all brainpool curves including the one under >> consideration. > > This is a misunderstanding. The term "twist security" refers to > non-quadratic twists (B/u)y^2=x^3+Ax^2+x, where u is a > non-square in F_p. RFC 5639 considers "quadratic twist", where u is a > square in F_p. Quadratic twists are isomorphic to > the original curve and provide equivalent security. Therefore, brainpoolP256t1 > is as secure as brainpoolP256r1. In > contrast, the non-quadratic twists of brainpoolP256r1 are not secure, because > their group order does not have a large > enough prime factor, i.e., the cofactor is huge. Thanks for explaining all that, but I just want to clarify it a bit further. What 2^44 means for the brainpoolP256t1 in DJB table? brainpoolP256t1 False 2^44.5 Is it related to non-quadratic twists only, derived either from brainpoolP256r1 or brainpoolP256t1? >> >> The other two "invalid-curve" attacks should be mitigated by > openssl controls, since latter does have a >> point-on-the-curve validation (e,g. see EC_POINT_is_on_curve function and > its usage in the latest openssl stable versions). >> > > Twist security is only relevant, if you use an arithmetic on the x-coordinate > only (Brier-Joye ladder) and don't perform > point-on-the-curve validation. I am quite sure that openssl avoids both, i.e., > computes on both coordinates and performs > point-on-the-curve validation. Therefore, twist security is irrelevant here. > > x-coordinate arithmetic is generally quite slow for Weierstrass curves, and > point-on-the-curve validation is mandated by > the relevant standards. Therefore, twist security should be hardly an issue > anywhere. In other words, I don't need to be concerned about "invalid-curve" attacks in any of openssl's ECC implementations, right? The last question that I have is related to brainpool curves implementations in openssl. It looks like they are available only in version 1.0.2, which is a beta now and I would be hesitant to use beta in any production deployments, so what I tried was backporting the brainpoolP256r1 only from 1.0.2 to the latest stable 1.0.1j and it worked perfectly well. I was even able to statically compile my backported version with some open source web application servers, configured brainpoolP256r1 as a defualt and didn't see any problems with that. My qs is - can you envision any other problems with this "backporting" approach? One thing that I was thinking about was a possible performance impact if there is any barinpool's specific optimization in 1.0.2. I've seen some signs of EC arithmentic's optimization for NIST P-256 in the latest stable version, but I didn't find anything like that for brainpool curves. Thanks for you answers. They were very helpful and encouraging. I hope that openssl community will not use the controversial NIST P-256 as a default in their future releases. > -- > Johannes > From nobody Tue Nov 11 12:28:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BF91A701A for ; Tue, 11 Nov 2014 12:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXf7jDJ_nfRa for ; Tue, 11 Nov 2014 12:28:06 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967DE1A9095 for ; Tue, 11 Nov 2014 12:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=XZ0gSo/pnVM2hEjDQ0jpomVaetM6MV9Sxp/9jG3vkwA=; b=CL7p7eTdkMN6nMC8OLFlKcduVVIF7LEj5fQKJOwh9J/H+mYwDWsti4wd10cct0sFMpT/vK8FFiY+hlVoCefne3U/bGW20/xkFQDUjQUdXef5+MSbrEuRAb4UhGP2dhakOwcP3gYAo5T0Qr4DTgdJQpEkhOWhVO7mZU/ogqQtMA8=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XoI2c-0004z4-Lt; Tue, 11 Nov 2014 21:27:55 +0100 Message-ID: <5462714E.5020201@polarssl.org> Date: Tue, 11 Nov 2014 21:27:58 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Martin Thomson , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X1va75HTUXm22AZOlzJstr5Tn7k Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:28:09 -0000 On 11/11/2014 00:17, Martin Thomson wrote: > https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/ > Thanks for your work on this! I'm very sympathetic to the goal, but I'm a bit puzzled by the following statement: Clients MUST NOT set a record layer version number (TLSPlaintext.version) of {03,00}. Clients SHOULD offer their highest supported version (that is, the same value that appears in ClientHello.client_version); though clients MAY use any value greater than or equal to the lowest version number they are willing to negotiate. Servers SHOULD accept handshakes from clients that propose SSLv3 or higher, but MUST NOT negotiate SSLv3. The underlying assumption between the first sentence seems to be that TLSPlaintext.version somehow indicates the lowest version that the client is willing to negotiate. The last sentence also seems to imply the server knows the range of versions the client is willing to use (as opposed to just the highest version), which seems to confirm that. Is there already something in the standard that says that the client offers a range of versions by using TLSPlaintext.version for the lower bound in addition to ClientHello.client_version? I didn't find it, so I'm worried about (implicitly) introducing new semantics about version negotiation in this document. Also, I'm curious about the reason why clients SHOULD "offer" the same version in TLSPlaintext.version as in ClientHello.client_version: first, I'm not sure what purpose it serves. Second and more importantly, isn't there a risk of introducing new intolerance issues? This is an actual question, if you have the answer and it's no, I'm delighted. Manuel. From nobody Tue Nov 11 12:38:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20D11A88BB for ; Tue, 11 Nov 2014 12:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymbe-lNYoRDF for ; Tue, 11 Nov 2014 12:38:00 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C50771A90C1 for ; Tue, 11 Nov 2014 12:37:46 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 6B3AF26405D; Tue, 11 Nov 2014 12:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=9Us680y/C8/dPnAlG1Gwr086/zQ=; b=GFOWvBBXPYT 3V7SRx/m0vJIvIRn1ze65uTNKwl0WSP3Ky0h8+iFnEFbJEIFyk5KFf+la+iq8NXE lZsj0FAQ0CuiIbX9XpVH1S8D3dlbiWBgGgeBj4OphdVI4Cr0arDCDYlW6Um5nCTZ /Ezu+t9FMrSMSi6IQJIUu7uGFuNaSqwk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id E3000264059; Tue, 11 Nov 2014 12:37:45 -0800 (PST) Date: Tue, 11 Nov 2014 14:37:44 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20141111203740.GN3412@localhost> References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gyi8l0i2i4O4Qf0scm_XjUfXt10 Cc: Hoeteck Wee , "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:38:03 -0000 On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote: > > On Nov 11, 2014, at 7:33 AM, Nico Williams wr= ote: > > That the "sub-cert" needs either a revocation scheme (not likely) or = a > > short lifetime. The latter puts this on a par with session resumptio= n, > > thus making one (well, me) wonder what the advantage to the static DH > > concept would be. >=20 > There is a revocation scheme. If the private ECDH key is lost, you > revoke the certificate, thereby invalidating the delegation. Ah, good point! > > We could put static DH keys in DNSSEC and learn them that way, which > > would get us 0rt. >=20 > Another possibility is to place the ECDH public key in a certificate > extension. This gives it a lifetime as long as the certificate, and it > doesn=E2=80=99t matter whether the =E2=80=9Cregular=E2=80=9D certificat= e public key is RSA or > ECDSA or anything else.=20 Sure, certs could have multiple subject public keys. That'd be a very nice. A cert could have an encryption key, a different signature key, and a key agreement key. > It removes the need to use signatures at all by the server. Not even > once. Yes. I like this. Nico --=20 From nobody Tue Nov 11 13:07:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD4A1ACD34 for ; Tue, 11 Nov 2014 13:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-l173_PAzEf for ; Tue, 11 Nov 2014 13:07:47 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7303D1ACD44 for ; Tue, 11 Nov 2014 13:07:27 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id ge10so10313962lab.36 for ; Tue, 11 Nov 2014 13:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5vGq/EAlIJJGYJMdo1W7E77ifHj+FZps1BKl3DQ2kBA=; b=lWHuAQCoXglK5oxQ04dIZ1vXSoBXkKYAY+KZO0RBfRMcDOcyyxWLNngWE6oTfxKuQV ao4jD0znmvumeMcCZIqKSrwFPjjuxZrMaU8FbxginzY+0XelxQ/lp9ofpoFWVPzbdAXz K3pTchFcB9GK3yLNz1iAs2ZRUa4TnZOUF4mOQAnY98fJzcr4d4xJMB73KzR+cwcNoUqx RrEAIYOMrLcDfytQ3CIGpprtRAlxifyyqq9X9iA539/DT6MkwynPSz8mIf0zmeNi+DEK ooOsDw+qE37vdDKqgOYa0bR3NHuJltvEhtVojlk/gYbK98uXBagSSsrBHyyVdCSVHIBe N9Vg== MIME-Version: 1.0 X-Received: by 10.152.36.201 with SMTP id s9mr17650180laj.17.1415740045478; Tue, 11 Nov 2014 13:07:25 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 13:07:25 -0800 (PST) In-Reply-To: <5462714E.5020201@polarssl.org> References: <5462714E.5020201@polarssl.org> Date: Tue, 11 Nov 2014 13:07:25 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/16zNRV132_j0UnK8TgG45tBBUTw Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:07:48 -0000 On 11 November 2014 12:27, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > Is there already something in the standard that says that the client offe= rs a > range of versions by using TLSPlaintext.version for the lower bound in ad= dition > to ClientHello.client_version? I didn't find it, so I'm worried about > (implicitly) introducing new semantics about version negotiation in this = document. That's a fair point. We probably shouldn't do that, yes. Maybe a removal of the first sentence would suffice for that. TLS basically disavows all claims regarding what goes in the ClientHello. We do know slightly more today such that we might be able to fix it, but I don't think we need to open that can of worms here. That certainly wasn't the intent. From nobody Tue Nov 11 13:26:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1681A016F for ; Tue, 11 Nov 2014 13:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZekItCqejvEM for ; Tue, 11 Nov 2014 13:26:37 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715751A0019 for ; Tue, 11 Nov 2014 13:26:37 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id p9so5044428lbv.5 for ; Tue, 11 Nov 2014 13:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Q1eDxz2y/Rcc/xdyLDxrQmydIjhZZq1GQw44XURZS7M=; b=T3jjxrMubp/ONW64zxNlaUMk+FUjbtLc7JybwW0hhab+e9h+EEAt8Or5s71HNiYHfX Lt2nvUWgvD87Fn1VdQYBki3qerl7fBH1w4WBc47HyFwXIsIUTnEAanDVZJnkjP6qmPvL qCywXzPPv34L6RQYYjz7Kk0gWSYX/Uahw0/pKCdLi66qpuqvRqi0m/kh1nxuslDmd92L TE/++Au+XyYwN+ylx0FmdrHtlgakE97udab3buf7RxRowm7xATX2wjwyc9Uw1bpB8UNl FIt8L+/Sg57vpc3gmOsa67Km0eUWPTRfWkdC7hTjPkjIn+/U5ZbGFQazBafsPabJo6qt PVSQ== MIME-Version: 1.0 X-Received: by 10.152.20.72 with SMTP id l8mr38710629lae.43.1415741195853; Tue, 11 Nov 2014 13:26:35 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 13:26:35 -0800 (PST) Date: Tue, 11 Nov 2014 13:26:35 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" , Rob Trace Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dxZRbI-giZOnABzqvKpCeidhXtM Subject: [TLS] Downgrade SCSV info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:26:38 -0000 I realize that this new information is late, but this is my understanding of how Internet Explorer implements version fallback. Rob, please correct me if I'm wrong. TLS 1.2 (no RC4) TLS 1.0 (no RC4) TLS 1.0 (with RC4) It is my opinion that this is not that large a risk. We are highly likely - in my opinion, and based on the numbers we have - to have few TLS 1.1 servers that are both intolerant to the TLS 1.2 handshake AND implement the downgrade SCSV. From nobody Tue Nov 11 13:55:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382721ACEF4 for ; Tue, 11 Nov 2014 13:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4cDnywQvvwK for ; Tue, 11 Nov 2014 13:55:12 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F471ACEEF for ; Tue, 11 Nov 2014 13:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=7aTH2DevF2mChWtsugEiZpNi2Gx1mat6oo3kxRvDHEI=; b=jZFOHw+WCTpfQBayhvSLWuN4jH9a5Pen2FDVxGsHUzMJW5I27heNchC8L/1CMdDPfL7aiHUMo53mAJSQU8ZnaMw4Vz1gviv5/F2Xj1Ut28Ag96vNL3lyPikvEkdbZgJZirQDD21R3yJ6PIGzQVsyraaAvoCOeVp/Lx23dUd8umw=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XoJOw-00057D-Ee; Tue, 11 Nov 2014 22:55:02 +0100 Message-ID: <546285BB.6070600@polarssl.org> Date: Tue, 11 Nov 2014 22:55:07 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Oleg Gryb , Johannes Merkle , "tls@ietf.org" References: <54625A39.70700@secunet.com> <1437313076.601391.1415736676771.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> In-Reply-To: <1437313076.601391.1415736676771.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Oc7JjlPASaHtqJkF-b8vo3CD0Z8 Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:55:13 -0000 On 11/11/2014 21:11, Oleg Gryb wrote: > Thanks for explaining all that, but I just want to clarify it a bit further. > > What 2^44 means for the brainpoolP256t1 in DJB table? > It's the cost of an attack for an attacker who can force you to accept a point that is not on the curve but on its non-quadratic twist. In the context of TLS (with the currently available curves and point formats) what safecurves calls "twist security" is totally irrelevant: either the implementation validates that points are on the curve, or you're vulnerable to an invalid curve attack which is much more powerful than a twist attack. Any decent implementation (which includes OpenSSL and some others) of ECC with TLS will check that points belong on the intended curve. > The last question that I have is related to brainpool curves implementations in openssl. This question is more suited to the OpenSSL list, as it is specific to this implementation. This list is about the protocol. Manuel. From nobody Tue Nov 11 14:10:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF041AD3CE for ; Tue, 11 Nov 2014 14:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCDYc3Gyp5j4 for ; Tue, 11 Nov 2014 14:10:28 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DD31AD3B6 for ; Tue, 11 Nov 2014 14:10:25 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0Lyh7L-1Y2KQi0g9X-0164p1; Tue, 11 Nov 2014 23:10:23 +0100 Received: by mail-ob0-f171.google.com with SMTP id wp18so8226037obc.30 for ; Tue, 11 Nov 2014 14:10:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.142.10 with SMTP id rs10mr34920915obb.36.1415743821829; Tue, 11 Nov 2014 14:10:21 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 11 Nov 2014 14:10:21 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 23:10:21 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2df3498031605079c8b61 X-Provags-ID: V02:K0:neduevb1PfBp+TVoT88Iu5vTTmyRh/RhnkEBYoYjzFS u8dJhogxD5ZNADDxxfJ6P2Zk2Ygop/Ipa6aZzyF32FJab6JzG7 moAmDsoakdJyptizVSohF5oU5/XY3GakU6kHXdSnWFfR8Ioyk+ 8Tnb41d4uzKdqlCTNr4BJoSdloFecMKuVaom1AzNULvCGPuKqP TAf6qUa5smXyzhTI6jtKMW8e6ivYBi3FxbOQ5jLRlDgEJFophT xtHWZ2ccC418SqiufS99+WXyTW7VVZAVwCfrbLViP8gS259xBY YBtM6wO3wDZXrtgC8qcZG2rOYZymJGVGmpf7O5GPk/X920ErZ7 meB0vsOi8CoS91ASME/8ww/464RgL9dyNW17pdXLJ4lj5eQisc 1Y0HgisoxBIqehQ2Wlock+0HwMfSk9NVm7/HySGlBZWTe2sqgb hkP2z X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uX0TT-1hgUPXcjSsZymvJ3Zhd18 Subject: Re: [TLS] Downgrade SCSV info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:10:29 -0000 --001a11c2df3498031605079c8b61 Content-Type: text/plain; charset=UTF-8 Martin Thomson : > I realize that this new information is late, but this is my > understanding of how Internet Explorer implements version fallback. > Rob, please correct me if I'm wrong. > > TLS 1.2 (no RC4) > TLS 1.0 (no RC4) > TLS 1.0 (with RC4) > TLS 1.0 with TLS_FALLBACK_SCSV? It is my opinion that this is not that large a risk. We are highly > likely - in my opinion, and based on the numbers we have - to have few > TLS 1.1 servers that are both intolerant to the TLS 1.2 handshake AND > implement the downgrade SCSV. Right, although it couldn't hurt for the client to try TLS 1.1 next in case it sees an inappropriate_fallback alert. (Then in the end you have essentially the same outcome as if trying the protocols in decreasing order, in the presence of an active attacker forcing you to downgrade.) Bodo --001a11c2df3498031605079c8b61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com>:
I realize that this new information is late, but this i= s my
understanding of how Internet Explorer implements version fallback.
Rob, please correct me if I'm wrong.

TLS 1.2 (no RC4)
TLS 1.0 (no RC4)
TLS 1.0 (with RC4)

TLS 1.0 with TLS_FAL= LBACK_SCSV?

It is my opinion that this is not that large a risk.=C2=A0 We are highly likely - in my opinion, and based on the numbers we have - to have few
TLS 1.1 servers that are both intolerant to the TLS 1.2 handshake AND
implement the downgrade SCSV.

Right, althou= gh it couldn't hurt for the client to try TLS 1.1 next in case it sees = an inappropriate_fallback alert. (Then in the end you have essentially the = same outcome as if trying the protocols in decreasing order, in the presenc= e of an active attacker forcing you to downgrade.)

Bodo


--001a11c2df3498031605079c8b61-- From nobody Tue Nov 11 14:40:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE4F1A1B2B for ; Tue, 11 Nov 2014 14:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf3mi8PbcsMC for ; Tue, 11 Nov 2014 14:40:33 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B151A1A2A for ; Tue, 11 Nov 2014 14:40:33 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id u7so7749248qaz.13 for ; Tue, 11 Nov 2014 14:40:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=fEX2QeatzfuTawgD29HIUkyVovOKBKoKpDkjXFDjEXc=; b=lMaKCN5CEs+ttyzXwb5/hlein9rUlwEp9rkYf/zLBgLHN1Ntlbw4miwDyhHRmxXisZ 9vrZiGrOkJkyBpUKdOE8iFb6sEeUVLQQQJu3ojYHpGnTMyyc+PY6coLomwTy/E7Vpjs6 OIaDqHM/2HYeihW6IfwnFU3eiyZBdbyqAztT/UEI1Ga7OiHkYHZ5h22iWRn4UbJTJK+G QKdWtGs1mIk6Fymio9wkDRNrYfK5S/d+oZUFTotyq1kp7VuQL2ljBzlb7cNhdSk/LuUn waCUAM48tVyly36NwZ2Gd4hSnGDv/GCbaLiZpRL99lz9cIU5bKZROYJIzDi1yElqzX4J nkmw== X-Gm-Message-State: ALoCoQlNoP3o0p83ISX5HuNd2FAjMvLerg4KJpQKS0h08TpoZrfLZPxZ53SOiZ57aDW+MTci0Io0 X-Received: by 10.140.27.194 with SMTP id 60mr52517148qgx.57.1415745632350; Tue, 11 Nov 2014 14:40:32 -0800 (PST) Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id k6sm19469062qaz.41.2014.11.11.14.40.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 14:40:31 -0800 (PST) Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 489A6AC2867; Tue, 11 Nov 2014 17:40:29 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: Date: Tue, 11 Nov 2014 17:40:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <32DFF6C4-DF27-4E23-9A08-44CA3E22CE50@pahtak.org> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TKsQFXQ-xdxPq6z4vXrY4SuMEGQ Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:40:35 -0000 On Nov 10, 2014, at 6:17 PM, Martin Thomson = wrote: > Richard, Alfredo, Adam and I have proposed such a statement: >=20 > https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/ Is there any harm associated with having 03 00 in the record layer? It = seems like the three statements you want are: 1. The client MUST NOT send a ClientHello with = ClientHello.client_version set to { 3, 0 }. 2. The server MUST NOT send a ServerHello with = ServerHello.server_version set to { 3, 0 }. 3. If the client receives a ServerHello with ServerHello.server_version = set to { 3, 0 }, the client MUST send a "protocol_version" alert message = and close the connection. I think these three are sufficient to forbid negotiating SSLv3 and the = advice given in Appendix E still applies: TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document. 1 isn't necessary as long as you have 3, but it seems pointless to have = ClientHello.client_version =3D { 3, 0 } and then close the connection. The current draft seems to allow the following two scenarios where the = client adheres to the draft but the server does not. Scenario I: TLSPlaintext.version =3D { 3, 1 } ClientHello.client_version =3D { 3, 0 } ServerHello.server_version =3D { 3, 0 } Scenario II: TLSPlaintext.version =3D { 3, 1 } ClientHello.client_version =3D { 3, 1 } ServerHello.server_version =3D { 3, 0 } The first scenario is pretty unlikely (why would the client be compliant = with the draft but have a maximum version of SSLv3?) but would seem to = work with a TLSv1.2 server that was willing to negotiate SSLv3. The second scenario seems more likely with a SSLv3 server (which accepts = 03 xx in the record layer). Maybe I'm missing something that rules those two cases out. But even if = so, a clear MUST NOT regarding the client_version and server_version and = a MUST on the protocol_alert if the server wants SSLv3 seems better = overall. --=20 Stephen Checkoway From nobody Tue Nov 11 14:45:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468F61A1B5B for ; Tue, 11 Nov 2014 14:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.406 X-Spam-Level: X-Spam-Status: No, score=0.406 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhRZ1LhW4vtE for ; Tue, 11 Nov 2014 14:45:04 -0800 (PST) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66801A1B56 for ; Tue, 11 Nov 2014 14:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1415745903; bh=mcAjsLsn5oGu6jiiNp9rmgc5mNGxHjjNE1hEbzbhviY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=i7vUn5EmiqNHbbd/STCHXEshKTv9nmEDTeQo+GJ8nN+xMVq/3HpZbyoqV0FIljtLQ2O6YI0XXZag+r0k//K1ndBeY7uw6ThngAofTASkwh5clKv6Xqs/9dNIgaXFIxPu9HWj2txJSZTVKhgEf6XfORjY9S35gAnLT4aVl+yhPToStXvKttzTj7fv+HfKU0wwHybJStvVhEoTBzlex0jzHALPb7EiYsWE3jZf6nvHXkae5YVE2qdfdVUbHDF46hOjoFYDwoZiDXejgsHs4rVvUU2xuNR70MxFldk1a/N9hzmJ71ES2VQthtWFIDXTPwbbecW9KwMDmnXZXAwKiy6L8w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=ny0cIHi45otuNHnlzgtikYNooI3I8EjMh2fOfe7vP1NH4kdtDW4nw0rdsXEs98uhljRn4/EbRjn5QPfIj9wdsIGxTrWf74tenlcg/DpY4MU4zqoH+d5sjUOj4ZJdF6s/T4w/LUfyPLE7TTAnW3Gm6fGXEoYFmWHe4i1R7ci2bk33nELz/q0rhnxg8khl10T4ATT3XG7LvTQ0MyMYWqR2Vu9M3C5VWkQo7Itf4Wt2CdfvK0pbXm3uToWlEwCkK6JU/q0nIRSrB76+YflWm0J6envQlpiFKYrIHjPRRsLH4ByJICxfWuxxQrIjeSYJl/f1LPUqdq0QsM74RJXoClK09g==; Received: from [66.196.81.174] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 22:45:03 -0000 Received: from [98.139.212.243] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 22:45:03 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 22:45:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 993118.46423.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: gdtQyuIVM1lOGifHzVgcoYoiCNOX7Yxijh5a8pdn.qY6skOm38BfC6yeu_evPW. eNvbHTLzEA.bZf47cpsR0iQy9dUJfL5VW4GuktnAu3DyShzEmRz8F3Ly2FAF0ztsa_CueMwA.QQt MlKLK0hg6THLDZXEQorX7VjExH6dHFDRMcXnyL.dYqCetNjGznga5LKlENjHI.CIzoMfLUEIcCES VXaYE5dsl4IfwGPYsdmldo6t9MxMu8bjNblV0INeSj8uiAz8YcJrknpmucVO26lO0YjxqOACdECZ RZEFMJMXIbHowPQchPCU_lWONvfqoCtmmyd1hCC9YBz9AN4bEyv2v8OJv4aZcox0UsdDmz8QbBnQ aPANio9hZLM6wyfImAftxaq3GAcFA7xvXRjEqgi3APilPTEKt43o88o4MDN0hPu7C8WxHZDgsAum oF784hlBnH9hRWxXX6dyekfC.jxcZm926iNmDnDF353GjEuDwOhPlxSJ94J3RweYKzTTQ Received: by 66.196.80.122; Tue, 11 Nov 2014 22:45:02 +0000 Date: Tue, 11 Nov 2014 22:44:03 +0000 (UTC) From: Oleg Gryb To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= , Oleg Gryb , Johannes Merkle , "tls@ietf.org" Message-ID: <326376278.627731.1415745843824.JavaMail.yahoo@jws10697.mail.bf1.yahoo.com> In-Reply-To: <546285BB.6070600@polarssl.org> References: <546285BB.6070600@polarssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UBfgUGD7d0jLeSFo8LkKzg54l2Q Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:45:05 -0000 > It's the cost of an attack for an attacker who can force you to accept a > point > that is not on the curve but on its non-quadratic twist. > > In the context of TLS (with the currently available curves and point formats) > what safecurves calls "twist security" is totally irrelevant: either > the > implementation validates that points are on the curve, or you're vulnerable > to > an invalid curve attack which is much more powerful than a twist attack. > > Any decent implementation (which includes OpenSSL and some others) of ECC with > TLS will check that points belong on the intended curve. It answers my question, thanks. >> The last question that I have is related to brainpool curves > implementations in openssl. > > This question is more suited to the OpenSSL list, as it is specific to this > implementation. This list is about the protocol. What about EC arithmetic optimization specific to a curve? Is it a kind of qs that is appropriate for this forum? If it is, probably somebody can provide pointers about optimizations that have been already implemented for the curve in the subject. I think, efficiency should be an important consideration of this protocol. From nobody Tue Nov 11 15:28:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9601A6FD8 for ; Tue, 11 Nov 2014 15:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsDKEyu5iIAV for ; Tue, 11 Nov 2014 15:28:35 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414E11A1AAA for ; Tue, 11 Nov 2014 15:28:29 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so9374135lbj.27 for ; Tue, 11 Nov 2014 15:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xytX91rofNtJCVO5uoD7SLnJDEjEM+aop84c1prN5Mw=; b=kvxRWNnt4ZwfPaFag6DlE3jsirAG6EJ/IxLHgk/dehRW1RduMjOMXYhkHq2py47kEs UQKS3n+rMNzuA6/ktXatk6/u7sbm2gealWo3457gs0TSPKFDwjua94+RkHssz6lKUEdD 7mgZvvdbV0nwqir4sCGdzw4ZIdcWU2VdHglloqlEBsRkKHgLfEqPT4IXoAZZOwUaMrWx CJETVopMnGmZwljb61KX0pZbVTpltSJfg0sAsb1pRrfjppE4HDYty7jGKPIsNK6N2Hm4 /uuZQx922wCkitMmJV8zny/IafKGhYBivXtEIdwDn9zkZ5b0ehTuXRyhB6kE3GGOkFLu 1cZg== MIME-Version: 1.0 X-Received: by 10.152.28.6 with SMTP id x6mr4094074lag.12.1415748507662; Tue, 11 Nov 2014 15:28:27 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 15:28:27 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 15:28:27 -0800 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nW3iWW2xYvJC5XDqWAf9PCYXsgM Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade SCSV info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 23:28:38 -0000 On 11 November 2014 14:10, Bodo Moeller wrote: > TLS 1.0 with TLS_FALLBACK_SCSV? I don't believe so. >> It is my opinion that this is not that large a risk. We are highly >> likely - in my opinion, and based on the numbers we have - to have few >> TLS 1.1 servers that are both intolerant to the TLS 1.2 handshake AND >> implement the downgrade SCSV. > > Right, although it couldn't hurt for the client to try TLS 1.1 next in case > it sees an inappropriate_fallback alert. (Then in the end you have > essentially the same outcome as if trying the protocols in decreasing order, > in the presence of an active attacker forcing you to downgrade.) The 1.1 handshake would need the SCSV. From nobody Tue Nov 11 15:33:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837591A702A for ; Tue, 11 Nov 2014 15:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq3yIvO-k4z9 for ; Tue, 11 Nov 2014 15:33:48 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240571A7000 for ; Tue, 11 Nov 2014 15:33:48 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0MWORa-1XU4El3kSI-00XZuN; Wed, 12 Nov 2014 00:33:46 +0100 Received: by mail-ob0-f182.google.com with SMTP id nt9so8996905obb.13 for ; Tue, 11 Nov 2014 15:33:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.79.10 with SMTP id f10mr35572746obx.4.1415748824863; Tue, 11 Nov 2014 15:33:44 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 11 Nov 2014 15:33:44 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Nov 2014 00:33:44 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e4014cc1e7205079db529 X-Provags-ID: V02:K0:z9b2KpvIgrLIdX1FQJPK3YN+0W7hV83/3viP/gyI5KU AU/DG/LBYdzqPZHwOmHQuiaO7wLvbVTb4++8HJOCdoJe3KcHak M+Al4LTjJN3gsdYUQc2HWGt8GqLnQbSbdfXMDbUzMXDiyIFmMR KABlsFvGN7it1MkTsWayEyP58ULjA9awnDOG/reLQmkjNB3AFD 8EzuhVQkG7xdBE/Um/0laVwNSwT7ce8uC5JCQMBuRtMSZc+4lf abd8JIgGwNNOaJvgPvQhXQyzjG8XzHTONEtLYCiHI0C7Y47Joc FpvqJa5SXeX2jGElYEhGlYn5iuqNKjSYcOpsS/SZkcIgxiF0Yb hbIy3Y+JZoNFm/9+i0Vl6w3W0eRoe/6EyC2gxtZhOSQeuVGNDG 0vmTbSTmwEMi8A3BkwS872NiP+1JY8b740Onht82pdfLcUXWpT qit3+ X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x2D8UJ7f0P0tXNAxsf_LqtlwLE4 Subject: Re: [TLS] Downgrade SCSV info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 23:33:49 -0000 --047d7b2e4014cc1e7205079db529 Content-Type: text/plain; charset=UTF-8 Martin Thomson : > [...](Then in the end you have > > essentially the same outcome as if trying the protocols in decreasing > order, > > in the presence of an active attacker forcing you to downgrade.)' > > The 1.1 handshake would need the SCSV. > Certainly. Attempting the protocol versions in a different order doesn't change which of them should have TLS_FALLBACK_SCSV. --047d7b2e4014cc1e7205079db529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com>:

> [...](Then in the= end you have
> essentially the same outcome as if trying the protocols in decreasing = order,
> in the presence of an active attacker forcing you to downgrade.)'<= br>
=C2=A0
The 1.1 handshake would need the SCSV.

Certainly. Attempti= ng the protocol versions in a different order doesn't change which of t= hem should have TLS_FALLBACK_SCSV.

--047d7b2e4014cc1e7205079db529-- From nobody Tue Nov 11 18:04:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAFF1A6F27 for ; Tue, 11 Nov 2014 18:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJu-PySYlSy5 for ; Tue, 11 Nov 2014 18:04:12 -0800 (PST) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94631A6F28 for ; Tue, 11 Nov 2014 18:04:11 -0800 (PST) Received: by mail-oi0-f44.google.com with SMTP id h136so7994342oig.3 for ; Tue, 11 Nov 2014 18:04:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W0pVNVJCkG0PIV7SkgtfHv6tHcxzCzjhPC/FBbEMuuQ=; b=NnhpRFwC8nYArNnHqzNLEe4ZngYWQu3FyKC+a+Pctap2dtJGOsLWK4pSNI5TTxfA8Q cFrNq90zHmAhZBHoGvT3nqsvNKB1f5ehrf5naIZVJo9YcbDKZ0H/X/IyUn0qexTwu9L4 TzXO7wfQC+7OStiX7xDXAKrulzc7AIEbtY7Lkp+T96m0y8UkKjTv067zbl06jSC8GQf0 CAZdZGyGr3VVlBYMZmBFR+sW3g6MbaJ0d1jKfpuxE7ixFr2OozfkAY90sj37oVnAp6Gc dNeHtix+O4yrFWHvwfm0k6tX2F+56HJeFwNIUVYGs84C4BS/ePqJ27KhVsm7gg3StUne whGw== X-Gm-Message-State: ALoCoQlYgF7ZUIJO4MDHC8PiIhhmw8g0eU5NkAHf5EvMJRSu0a0aZbYlDSmJd3LQdI3DZvNvkYiY MIME-Version: 1.0 X-Received: by 10.202.207.207 with SMTP id f198mr33394603oig.46.1415757851125; Tue, 11 Nov 2014 18:04:11 -0800 (PST) Received: by 10.76.105.113 with HTTP; Tue, 11 Nov 2014 18:04:11 -0800 (PST) In-Reply-To: <20141106100144.812BE1AF98@ld9781.wdf.sap.corp> References: <20141106100144.812BE1AF98@ld9781.wdf.sap.corp> Date: Tue, 11 Nov 2014 18:04:11 -0800 Message-ID: From: Brian Smith To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/B9O1tyyOSAkP8aYHRmgMgGDZK4E Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] Minutes from Tuesday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 02:04:15 -0000 Martin Rex wrote: > It's actually hard to think of a more unreasonable behaviour than > the one currently specified. No it isn't. For example, the server could do all of these, which are more unreasonable: 1. Reboot the server. 2. Start thermonuclear war. 3. Send a reply on this thread to this mailing list. There are many other more unreasonable things the server could do. > A different, equally simple and magnitudes more useful server behaviour > would be for the server to continue the handshake as normal and simply > assume in the processing of the ClientHello that the Client means > ClientHello.client_version +1 compared to what it sent over the wire. No, because the client might have done multiple levels of fallback, but the server might not have seen all of the levels. So, for example, the server might be seeing ClientHello.client_version = SSL 3.0 with the fallback SCSV, but the client actually supports TLS 1.2. It wouldn't be good for the server to carry on with TLS 1.0 (because of the CBC IV problems in TLS 1.0, amongst other reasons). > (but when doing that, the server ought to skip the RSA premaster secret > client_version check later on when selecting a cipher suite with > static RSA key exchange. Since Microsoft botched the RSA premaster > secret version on renegotiation handshakes in Win7, and there is no > security value in the check anyway, this should be perfectly OK.) I disagree. If there is a compatibility issue regarding renegotiations only, then the compatibility workaround should be limited to renegotiations only. Since most clients don't even want to renegotiate unless the server demands it, limiting the workaround to renegotiations means that most connections will never be affected by it. Cheers, Brian From nobody Wed Nov 12 01:00:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CAD1A8AC3; Wed, 12 Nov 2014 01:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wn1JklnvOcw; Wed, 12 Nov 2014 01:00:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D29811A0451; Wed, 12 Nov 2014 01:00:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141112090000.29696.26200.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 01:00:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zPHURG5qwjhSbv-kmMw8tgB1El4 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 09:00:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension Authors : Karthikeyan Bhargavan Antoine Delignat-Lavaud Alfredo Pironti Adam Langley Marsh Ray Filename : draft-ietf-tls-session-hash-03.txt Pages : 11 Date : 2014-11-12 Abstract: The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the- middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-session-hash-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 12 04:29:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5E71A896E; Wed, 12 Nov 2014 04:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ4CVw0ldmRh; Wed, 12 Nov 2014 04:29:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9165B1A8984; Wed, 12 Nov 2014 04:29:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141112122909.6840.86809.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 04:29:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AasbHoF2GyRRp31kgybuw9JpZio Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 12:29:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks Authors : Bodo Moeller Adam Langley Filename : draft-ietf-tls-downgrade-scsv-02.txt Pages : 8 Date : 2014-11-12 Abstract: This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 12 06:57:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E3C1A019B for ; Wed, 12 Nov 2014 06:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjUcK7nUqu7Q for ; Wed, 12 Nov 2014 06:57:03 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15601A024C for ; Wed, 12 Nov 2014 06:57:02 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id B9FA61A007F; Wed, 12 Nov 2014 15:56:54 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bWUzEHVH7ZOv; Wed, 12 Nov 2014 15:56:49 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id C3A191A007E; Wed, 12 Nov 2014 15:56:49 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 12 Nov 2014 15:56:56 +0100 Message-ID: <54637537.2010408@secunet.com> Date: Wed, 12 Nov 2014 15:56:55 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Oleg Gryb , "tls@ietf.org" References: <54625A39.70700@secunet.com> <1437313076.601391.1415736676771.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> In-Reply-To: <1437313076.601391.1415736676771.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fP3tDQcj5TBLoyQFRb8-8T4SUkw Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 14:57:06 -0000 >>> I was going through SafeCurves pages recently and wanted to ask a question >> about brainpoolP256r1's twist security. >>> According to this research http://safecurves.cr.yp.to/twist.html,, >> a combined >>> cost of attacks on brainpoolP256t1, which is a P256r1's >> "twist" is rather low. At the same time it's obvious that >>> small-group-attack is not applicable, because "h=1" is a >> requirement for all brainpool curves including the one under >>> consideration. >> >> This is a misunderstanding. The term "twist security" refers to >> non-quadratic twists (B/u)y^2=x^3+Ax^2+x, where u is a >> non-square in F_p. RFC 5639 considers "quadratic twist", where u is a >> square in F_p. Quadratic twists are isomorphic to >> the original curve and provide equivalent security. Therefore, brainpoolP256t1 >> is as secure as brainpoolP256r1. In >> contrast, the non-quadratic twists of brainpoolP256r1 are not secure, because >> their group order does not have a large > >> enough prime factor, i.e., the cofactor is huge. > > Thanks for explaining all that, but I just want to clarify it a bit further. > > What 2^44 means for the brainpoolP256t1 in DJB table? > > brainpoolP256t1 False 2^44.5 > > Is it related to non-quadratic twists only, derived either from brainpoolP256r1 or brainpoolP256t1? As Manuel has explained its the security level of the non-quadratic twist. It is NOT the security of the quadratic twists, which is the same as of the original brainpoolP256r1. Background: All quadratic twists are isomorphic (equivalent) to each other. And each quadratic twist (i.e. brainpoolP256t1 and brainpoolP256r1) has the same set of non-quadratic twists, which are also all equivalent to each other (they are quadratic twists of each other). So we have two sets of curves: The quadratic twists of brainpoolP256r1 (which contains brainpoolP256t1) and the set of non-quadratic twists of brainpoolP256r1. Any curve from the former set (including brainpoolP256t1) is as secure as brainpoolP256r1. And any curve from the second set (the non-quadratic twists) have a group order that factors to moderately sized primes and are, thus, insecure. But nobody would use the non-quadratic twists, except potentially in an invalid-curve attack. > In other words, I don't need to be concerned about "invalid-curve" attacks in any of openssl's ECC implementations, right? If openssl uses a proper ECC implementation, yes. If not, you're in trouble anyway. > The last question that I have is related to brainpool curves implementations in openssl. It looks like they are available only in version 1.0.2, which is a beta now and I would be hesitant to use beta in any production deployments, so what I tried was backporting the brainpoolP256r1 only from 1.0.2 to the latest stable 1.0.1j and it worked perfectly well. I was even able to statically compile my backported version with some open source web application servers, configured brainpoolP256r1 as a defualt and didn't see any problems with that. > > My qs is - can you envision any other problems with this "backporting" approach? One thing that I was thinking about was a possible performance impact if there is any barinpool's specific optimization in 1.0.2. I've seen some signs of EC arithmentic's optimization for NIST P-256 in the latest stable version, but I didn't find anything like that for brainpool curves. My guess (and its nothing more than a guess) is that they just added the parameters and did not change the implementation. If this holds true, your approach should work, provided that you properly transferred all relevant parameters and identifiers. But this is something, you need to confirm with the openssl developers. -- Viele Grüße, Johannes From nobody Wed Nov 12 09:16:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F561A8AF5 for ; Wed, 12 Nov 2014 09:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0yZa30NNMSe for ; Wed, 12 Nov 2014 09:16:14 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337061A906A for ; Wed, 12 Nov 2014 09:12:22 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 35AB11A007A; Wed, 12 Nov 2014 18:12:13 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uECXc0CbByEp; Wed, 12 Nov 2014 18:12:04 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id A3A441A006C; Wed, 12 Nov 2014 18:12:04 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 12 Nov 2014 18:12:09 +0100 Message-ID: <546394E9.2010208@secunet.com> Date: Wed, 12 Nov 2014 18:12:09 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Oleg Gryb , "tls@ietf.org" References: <54625A39.70700@secunet.com> <1437313076.601391.1415736676771.JavaMail.yahoo@jws106117.mail.bf1.yahoo.com> <54637537.2010408@secunet.com> In-Reply-To: <54637537.2010408@secunet.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n528Nvahz8JeCSjtyFjXgsT9UMg Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:16:21 -0000 > As Manuel has explained its the security level of the non-quadratic twist. It is NOT the security of the quadratic > twists, which is the same as of the original brainpoolP256r1. > > Background: All quadratic twists are isomorphic (equivalent) to each other. And each quadratic twist (i.e. > brainpoolP256t1 and brainpoolP256r1) has the same set of non-quadratic twists, which are also all equivalent to each > other (they are quadratic twists of each other). So we have two sets of curves: The quadratic twists of brainpoolP256r1 > (which contains brainpoolP256t1) and the set of non-quadratic twists of brainpoolP256r1. Any curve from the former set > (including brainpoolP256t1) is as secure as brainpoolP256r1. And any curve from the second set (the non-quadratic > twists) have a group order that factors to moderately sized primes and are, thus, insecure. But nobody would use the > non-quadratic twists, except potentially in an invalid-curve attack. > As Watson Ladd just pointed out to me, the terms "quadratic twists" and "non-quadratic twists" are not common in math textbooks. For a curve in Weierstrass form E: y^2 = x^3 + a*x + b mod p, the term twist denotes a curve E': y^2 = x^3 + v^2*a*x + v^3* b mod p. - If v is a quadratic residue, i.e., if there is a w with w^2 = v mod p, then E and E' are isomorphic mod p and thus have equivalent security. - If v is a quadratic non-residue, E' is not isomorphic to E and the curve orders satisfy |E| + |E'| = p+2. Text books often discuss only the case of quadratic non-residues (e.g. Blake, Seroussi, Smart). In the case of the Brainpool curves, the twists mentioned in RFC 5639 are twists via a quadratic residue and have the same security as the respective random curves. -- Johannes From nobody Wed Nov 12 19:54:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5FF1A1B5D for ; Wed, 12 Nov 2014 19:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfoQrDbHKUaz for ; Wed, 12 Nov 2014 19:54:35 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::746]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00F41A1B51 for ; Wed, 12 Nov 2014 19:54:34 -0800 (PST) Received: from CY1PR0301MB0892.namprd03.prod.outlook.com (25.160.164.23) by CY1PR0301MB0891.namprd03.prod.outlook.com (25.160.164.22) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 03:54:12 +0000 Received: from CY1PR0301MB0892.namprd03.prod.outlook.com ([25.160.164.23]) by CY1PR0301MB0892.namprd03.prod.outlook.com ([25.160.164.23]) with mapi id 15.01.0016.006; Thu, 13 Nov 2014 03:54:12 +0000 From: Rob Trace To: "tls@ietf.org" Thread-Topic: Re: [TLS] Downgrade SCSV info Thread-Index: Ac/+9O5weiJnd0SQTLmp/+CUEBE1LA== Date: Thu, 13 Nov 2014 03:54:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:136:f443:da37:4451:c37d] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0891; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0891; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(41574002)(4396001)(31966008)(21056001)(108616004)(77096003)(106356001)(77156002)(40100003)(120916001)(99396003)(33646002)(110136001)(19625215002)(20776003)(101416001)(95666004)(99286002)(62966003)(2351001)(19300405004)(450100001)(122556002)(16236675004)(107046002)(105586002)(46102003)(64706001)(107886001)(15975445006)(2656002)(87936001)(19580395003)(76576001)(92566001)(15202345003)(97736003)(74316001)(86362001)(2501002)(54356999)(50986999)(86612001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0891; H:CY1PR0301MB0892.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d51dcf00811740edb16aade02a5d8fe5CY1PR0301MB0892namprd03_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7MB8E-7juKD8l5pHdacQV9AhhKA Subject: Re: [TLS] Downgrade SCSV info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 03:54:38 -0000 --_000_d51dcf00811740edb16aade02a5d8fe5CY1PR0301MB0892namprd03_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Right, although it couldn't hurt for the client to try TLS 1.1 next in ca= se > it sees an inappropriate_fallback alert. (Then in the end you have > essentially the same outcome as if trying the protocols in decreasing ord= er, > in the presence of an active attacker forcing you to downgrade.) When we looked at the fallback to HTTP 1.1, it was just as Martin stated an= d there were almost 0 times when the connection completed over TLS 1.1. Th= e 1.1 fallback was a lot of wasted roundtrips and did not provide any value= . I am not sure what a wasted fallback to HTTP 1.1 would provide with SCSV, i= n that the TLS 1.0 fallback would still result in the inappropriate_fallbac= k before we send any data. Thanks!! -Rob --_000_d51dcf00811740edb16aade02a5d8fe5CY1PR0301MB0892namprd03_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Right, although it couldn't hurt for the client= to try TLS 1.1 next in case

> it sees an inappropriate_fallback alert. (Then = in the end you have

> essentially the same outcome as if trying the p= rotocols in decreasing order,

> in the presence of an active attacker forcing y= ou to downgrade.)

 

When we looked at the fallback to HTTP 1.1, it was j= ust as Martin stated and there were almost 0 times when the connection comp= leted over TLS 1.1.  The 1.1 fallback was a lot of wasted roundtrips a= nd did not provide any value.

 

I am not sure what a wasted fallback to HTTP 1.1 wou= ld provide with SCSV, in that the TLS 1.0 fallback would still result in th= e inappropriate_fallback before we send any data.

 

Thanks!!

 

-Rob

--_000_d51dcf00811740edb16aade02a5d8fe5CY1PR0301MB0892namprd03_-- From nobody Wed Nov 12 20:03:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DB81A1B4D for ; Wed, 12 Nov 2014 20:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5yS_7A6ddDV for ; Wed, 12 Nov 2014 20:02:57 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079341A1B49 for ; Wed, 12 Nov 2014 20:02:57 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id b6so10387712lbj.2 for ; Wed, 12 Nov 2014 20:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fIw3rWd3TSNfVmSQM+zvP0n+q1L6R9SaiUw9rUQOrCo=; b=uBrElkZFQjab4VXdhAKrUm2UM6WP7hL6P1fYI528inFGCD3AdT7xj5F4tTWA9KVIFZ gmRWzfqbri4PvPv/Icpwes3CRcvTbYH10YXkbk1J7qw/H5KPGWTaQIqQbEv0pokZE6ms RhrQZGhhVnwy+ClJEx0VUMv8WxTtFI2ak9NN9WkI/GJ6WYnOQ08To8vA6j4iBrAWWz3u y3MVVtu1s/CD2WbmVGY7KI7QaMCcLhEIjgSRP+KwSC4arDZqX6g5slR0Qia6+BzfZ68W bMfp+zdEFotOwJ/Zsl/G7rGBlmZkOkuik+uonE3wHewT93DNgfxCl3UWjRz7klgaixAz bwVw== X-Received: by 10.112.199.100 with SMTP id jj4mr25592238lbc.71.1415851375341; Wed, 12 Nov 2014 20:02:55 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Wed, 12 Nov 2014 20:02:25 -0800 (PST) In-Reply-To: <20141111203740.GN3412@localhost> References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> From: Hugo Krawczyk Date: Wed, 12 Nov 2014 23:02:25 -0500 X-Google-Sender-Auth: FoZo9tDg7s-nlY4O1le-ph1oasw Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c2a9964836c40507b596bb Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C_s4pMl6UBm6cd3kEqLZN5Z84K8 Cc: Hoeteck Wee , "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 04:03:00 -0000 --001a11c2a9964836c40507b596bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From the discussions in this list and some offline conversations it is clea= r that people like OPTLS for its features but are concerned with the issue of "delegation", namely, the need for the server to create certificates for static DH keys g^s by signing (using the RSA key in the server's certificate) the key g^s, the validity period (T1,T2) and possibly some other information. I'll call this signature a sub-certificate or subcert (some suggested calling this a proxy certificate but I prefer not to use established terminology since I am not sure what the exact semantics/connotations of these terms). Here is a summary of the concerns and some of the available techniques to deal with them. * The delegation concerns do NOT exist in a model where the attacker either gets full control of the private signing key (e.g., steals it) or otherwise has no access to it. Indeed, in this case either the key is secure and the attacker cannot produce subcerts or the key is fully compromised and one cannot possibly provide server security (in this or any previous version of TLS). * Thus, delegation concerns only arise when assuming an attacker that canno= t steal the signing key but can get temporary access to a signing device an= d create a few signatures on arbitrary data. In such case, the attacker can generate subcerts for keys g^s for which it knows the secret key s, hence allowing him to impersonate the server against any client accepting this subcert. * I am not sure how common the above "partial exposure" problem is in practice but note that if the signing key was only used to generate TLS 1.3 subcerts then it could be well guarded since it would be used rarely and never needed online. This would be the case if servers equipped themselves with signature certificates solely used for this purpose (rather than using the same certificate in protocols like TLS 1.2 that require online signatures). NOTE: One way of using a TLS 1.3 RSA key would be to generate a bunch of subcerts for g^s values in all the EC groups that the server supports and then DESTROY the signing key. (This is equivalent, functionally and security-wise, to getting DH certificates for all these groups without requiring the CA to issue DH certificates at all!) * Assuming that servers will not want to get certificates for use with TLS 1.3 only (why not?), then we need to address the above subcert forgery scenario where the atacker gets limited access to the signing key. An imperfect bu= t effective solution is to only issue subcerts with short validity period, i.e. where the difference T2-T1 is small. In this case the attacker with temporary access to the signing key can only create a limited number of subcerts covering a limited time span. Operational note: It is the servers' responsibility to create such short-lived subcerts but it is the clients' responsibility to check the subcerts are indeed short-lived (otherwise an attacker can generate a long-lived subcert that the client will accept). * Clients with clocks with significant deviations from the correct time wil= l have trouble accepting valid subcerts and may be induced to accept old (o= r into-the-future) subcerts. I can imagine this to be a problem. But is it enough to abandon the benefits of a ECDH-based solution like OPTLS? * The acceptable validity periods can be fixed by the protocol or can be part of the "negotiation" where the client will say which validity-period lengths are acceptable to him and the server will send an error message if it doe= s not support such periods. Or the server can simply send the subcert with the shortest validity period which is still valid and the client accept it depending on his clock and policy. Note: One could accommodate, in principle, a period length of 0, meaning a subcert that is only valid instantaneously; in other words, this would be a per-session signature on g^s that will also include the client nonce. * There is no need to have a revocation mechanism for subcerts. The rule is that subcerts are not accepted once the RSA certificate is expired or revoked. Hence, the revocation of the RSA certificate implies revocation of all subcerts signed with it. FINAL NOTE: The above issues will be eventually solved with servers getting certificates for use with TLS 1.3 (either ECDH certificates or signature certificates used as explained in the first NOTE above). Hugo On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams wrote: > On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote: > > > On Nov 11, 2014, at 7:33 AM, Nico Williams > wrote: > > > That the "sub-cert" needs either a revocation scheme (not likely) or = a > > > short lifetime. The latter puts this on a par with session resumptio= n, > > > thus making one (well, me) wonder what the advantage to the static DH > > > concept would be. > > > > There is a revocation scheme. If the private ECDH key is lost, you > > revoke the certificate, thereby invalidating the delegation. > > Ah, good point! > > > > We could put static DH keys in DNSSEC and learn them that way, which > > > would get us 0rt. > > > > Another possibility is to place the ECDH public key in a certificate > > extension. This gives it a lifetime as long as the certificate, and it > > doesn=E2=80=99t matter whether the =E2=80=9Cregular=E2=80=9D certificat= e public key is RSA or > > ECDSA or anything else. > > Sure, certs could have multiple subject public keys. That'd be a very > nice. A cert could have an encryption key, a different signature key, > and a key agreement key. > > > It removes the need to use signatures at all by the server. Not even > > once. > > Yes. I like this. > > Nico > -- > --001a11c2a9964836c40507b596bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the discussions in this list and some offl= ine conversations it is clear
that people like OPTLS for its features bu= t are concerned with the issue of
"delegation", namely, the ne= ed for the server to create certificates for
static DH keys g^s by signi= ng (using the RSA key in the server's certificate)
the key g^s, the = validity period (T1,T2) and possibly some other information.
I'll c= all this signature a sub-certificate or subcert (some suggested calling
= this a proxy certificate but I prefer not to use established terminology si= nce
I am not sure what the exact semantics/connotations of these terms).=

Here is a summary of the concerns and some of the available techniq= ues to deal
with them.

* The delegation concerns do NOT exist in = a model where the attacker either
=C2=A0 gets full control of the privat= e signing key (e.g., steals it) or otherwise
=C2=A0 has no access to it.= Indeed, in this case either the=C2=A0 key is secure and the
=C2=A0 atta= cker cannot produce subcerts or the key is fully compromised and one
=C2= =A0 cannot possibly provide server security (in this or any previous versio= n of
=C2=A0 TLS).

* Thus, delegation concerns only arise when ass= uming an attacker that cannot
=C2=A0 steal the signing key but can get t= emporary access to a signing device and
=C2=A0 create a few signatures o= n arbitrary data. In such case, the attacker can
=C2=A0 generate subcert= s for keys g^s for which it knows the secret key s, hence
=C2=A0 allowin= g him to impersonate the server against any client accepting this
=C2=A0= subcert.

* I am not sure how common the above "partial exposur= e" problem is in practice
=C2=A0 but note that if the signing key w= as only used to generate TLS 1.3 subcerts
=C2=A0 then it could be well g= uarded since it would be used rarely and never needed
=C2=A0 online. Thi= s would be the case if servers equipped themselves with signature
=C2=A0= certificates solely used for this purpose (rather than using the same
= =C2=A0 certificate in protocols like TLS 1.2 that require online signatures= ).

NOTE: One way of using a TLS 1.3 RSA key would be to generate a = bunch of
subcerts for g^s values in all the EC groups that the server su= pports and then
DESTROY the signing key. (This is equivalent, functional= ly and security-wise,
to getting DH certificates for all these groups wi= thout requiring the CA to
issue DH certificates at all!)

* Assumi= ng that servers will not want to get certificates for use with TLS 1.3
= =C2=A0 only (why not?), then we need to address the above subcert forgery s= cenario
=C2=A0 where the atacker gets limited access to the signing key.= An imperfect but
=C2=A0 effective solution is to only issue subcerts wi= th short validity period,
=C2=A0 i.e.=C2=A0 where the difference T2-T1 i= s small. In this case the attacker with
=C2=A0 temporary access to the s= igning key can only create a limited number of
=C2=A0 subcerts covering = a limited time span.

Operational note: It is the servers' respo= nsibility to create such short-lived
subcerts but it is the clients'= responsibility to check the subcerts are
indeed short-lived (otherwise = an attacker can generate a long-lived subcert
that the client will accep= t).

* Clients with clocks with significant deviations from the corre= ct time will
=C2=A0 have trouble accepting valid subcerts and may be ind= uced to accept old (or
=C2=A0 into-the-future) subcerts. I can imagine t= his to be a problem. But is it
=C2=A0 enough to abandon the benefits of = a ECDH-based solution like OPTLS?

* The acceptable validity periods = can be fixed by the protocol or can be part
=C2=A0 of the "negotiat= ion" where the client will say which validity-period lengths
=C2=A0= are acceptable to him and the server will send an error message if it does=
=C2=A0 not support such periods. Or the server can simply send the subc= ert with the
=C2=A0 shortest validity period which is still valid and th= e client accept it
=C2=A0 depending on his clock and policy.

Note= : One could accommodate, in principle, a period length of 0, meaning a
s= ubcert that is only valid instantaneously; in other words, this would be a<= br>per-session signature on g^s that will also include the client nonce.
* There is no need to have a revocation mechanism for subcerts. The ru= le is
=C2=A0 that subcerts are not accepted once the RSA certificate is = expired or
=C2=A0 revoked. Hence, the revocation of the RSA certificate = implies revocation of
=C2=A0 all subcerts signed with it.

FINAL N= OTE: The above issues will be eventually solved with servers getting
cer= tificates for use with TLS 1.3 (either ECDH certificates or signature
ce= rtificates used as explained in the first NOTE above).

Hugo

<= /div>

On Tue= , Nov 11, 2014 at 3:37 PM, Nico Williams <nico@cryptonector.com>= ; wrote:
On Tue, = Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote:
> > On Nov 11, 2014, at 7:33 AM, Nico Williams <nico@cryptonector.com> wrote:
> > That the "sub-cert" needs eithe= r a revocation scheme (not likely) or a
> > short lifetime.=C2=A0 The latter puts this on a par with session = resumption,
> > thus making one (well, me) wonder what the advantage to the stati= c DH
> > concept would be.
>
> There is a revocation scheme. If the private ECDH key is lost, you
> revoke the certificate, thereby invalidating the delegation.

Ah, good point!

> > We could put static DH keys in DNSSEC and learn them that way, wh= ich
> > would get us 0rt.
>
> Another possibility is to place the ECDH public key in a certificate > extension. This gives it a lifetime as long as the certificate, and it=
> doesn=E2=80=99t matter whether the =E2=80=9Cregular=E2=80=9D certifica= te public key is RSA or
> ECDSA or anything else.

Sure, certs could have multiple subject public keys.=C2=A0 That'= d be a very
nice.=C2=A0 A cert could have an encryption key, a different signature key,=
and a key agreement key.

> It removes the need to use signatures at all by the server. Not even > once.

Yes.=C2=A0 I like this.

Nico
--

--001a11c2a9964836c40507b596bb-- From nobody Wed Nov 12 20:56:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3A1A1B5E; Wed, 12 Nov 2014 20:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJp5DIPhyuen; Wed, 12 Nov 2014 20:56:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3871A1B7B; Wed, 12 Nov 2014 20:56:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113045620.5749.69924.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 20:56:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F-StrDY2Uh245RrRsWWuD_VV7aQ Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 04:56:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-03.txt Pages : 22 Date : 2014-11-12 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 12 21:11:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6631A1B9E for ; Wed, 12 Nov 2014 21:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubzsYW8QRMH2 for ; Wed, 12 Nov 2014 21:11:43 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E3E301A1B75 for ; Wed, 12 Nov 2014 21:11:41 -0800 (PST) Received: from [31.133.163.118] (dhcp-a376.meeting.ietf.org [31.133.163.118]) by che.mayfirst.org (Postfix) with ESMTPSA id A5EC2F984 for ; Thu, 13 Nov 2014 00:11:38 -0500 (EST) Message-ID: <54643D87.1040009@fifthhorseman.net> Date: Wed, 12 Nov 2014 19:11:35 -1000 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: IETF TLS WG References: <20141113045620.5749.69924.idtracker@ietfa.amsl.com> In-Reply-To: <20141113045620.5749.69924.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sGSVU7K05MBck6joLf46uLO5pUoNNewRs" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gb_KG2jGzcKGwGWA1qB75Nz7vhw Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 05:11:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sGSVU7K05MBck6joLf46uLO5pUoNNewRs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/12/2014 06:56 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. >=20 > Title : Negotiated Finite Field Diffie-Hellman Epheme= ral Parameters for TLS > Author : Daniel Kahn Gillmor > Filename : draft-ietf-tls-negotiated-ff-dhe-03.txt > Pages : 22 > Date : 2014-11-12 highlights of the changes here (which we can discuss at tomorrow's sessio= n): * server now indicates its group selection by using the standard ServerKeyExchange and an un-modified ServerDHParams (simpler to implement and less tricky to reason about) * FFDHE groups are an explicit range in the NamedCurves registry, not individual callouts * removed ffdhe6144 for simplicity * more detailed security considerations for users of FFDHE --dkg --sGSVU7K05MBck6joLf46uLO5pUoNNewRs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUZD2HXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcxFwP/2GfD95JqZSU/QhfDhBv7isC V+FdU9cNzKaWFCccAsmWBvE5LGYpmGIWrUoWjQqxysQph692QN3jb85qMcEfMa1b x3vlWUOXWrzFbzxaFAyRnJtgna1yrlAYx5tsf0ezUAgpmvHMuvabPJCkKq6UW+Mf XbknqNMMNjNdjH0hn+d7hb/FZtexP75kK+GUGEMvEyNMTpjeh8oc1T/WNEXMSle5 wNCM6TlCEooyy3iYanthRC/Zmu8zt3BjFhtOWEnIBlEXnIWKgkcFxhdn28YmxYKZ KBCKEJkFBoMMohTM8FXKC2LtethYnBmykDwd9NVP/lLuz27eE6xwsIZVcVbXDB1z CPCrFPiehz9NGbvd2yv7eNAX7Zlv88FAPBTGiiL7tiY5eJZ/vVILJLS4OfZsGXeD dguy19qbnURS3ulb2oJUn20ezpC2+4v/gUTJTlzhGosAHl2QOCY2rSszn+18Nep4 dG0PJ7LsYE2gMSkQikcKrlnaaLfuvyKVK0aQFcIeBNPV8L/bMAeyYQJDKxQbr6D/ x9eT2wJEVgs+31/NjYPkmc/PhEkcYZCj5bHHFA+bc+NF0AVWOC42aQXhHNb+eRJX apFKhqHuwCXEn/FnNGJ1YSygZtY71FvL5LRWMLarJTrkCt+OD7RzM//aH2b2Ufew 9UG7KO/1f4w6g64+iSj2 =rDGF -----END PGP SIGNATURE----- --sGSVU7K05MBck6joLf46uLO5pUoNNewRs-- From nobody Wed Nov 12 22:37:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565091A1B9E for ; Wed, 12 Nov 2014 22:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h03nygY2-7M5 for ; Wed, 12 Nov 2014 22:37:53 -0800 (PST) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE481A19F4 for ; Wed, 12 Nov 2014 22:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1415860672; bh=PoPK0Iz94G6OYmjy0Rd0u3AmmkFngcQewlADS1jo3Qc=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=QwQUWKhCucGaFJkoZoy2oXxWaJhAfOrkp16A/8Mbv4mjFnY3ryJ8TdLC15OoLhs1PopJWwlDYTt/ZnqxF/q+gEbnJ2hDm0bMLhRyExnZltnQKjf8WaZXjZeWTJUVWvyWvElSc4ZWjX9OKzpKfXtl2aTC7CMsSaxEIuebVvRxQzulkmHl1lixjK0tEDSSoJia6BBD5AOtKXiJr1UlAEUpi9YuyLmXBq+lLlSMaT0mIvWSiyDyKklXFzyqsMKp1hSygQFocF6lKPr9BrYdMwlfOAXPKKMHgO6u7y06mddlGhu3i33hpCFtHkCkfw80KDJHnacwiBtjBMAXTjEFyEMajQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=HvlW/0j0EXjHrw/VKARnWo3qHRgR5yDmvlXRVshJ6JpVB7du9UUYkuY1L8TN4lfFffah7qiN/y9YHY2dnZaS4RscCIuEhTXDTxYvW8mseVNj6qP+68Bm5Md+2z4nRGiepDIuIrZaHg91CtWggXApBDfRPZ92ONraBHK4BUZ24Oqm04cTTZ4QKa2xXSjVCoDi+ItrI0MkNfeOmdSKfw3tNWfR2nUXyQs0bIxagq/gUsteQ+HVWv6zNl9jejEsSk22EwTfEaoocn32cRT1Q3x3E3G+8KV0nAj+WVddHMEafBFxoYTnoKm7E37ksljbko1w8X58+ZPqjeqHSGSC2kLMGg==; Received: from [66.196.81.174] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2014 06:37:52 -0000 Received: from [98.139.215.250] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2014 06:37:52 -0000 Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 13 Nov 2014 06:37:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 640236.47342.bm@omp1063.mail.bf1.yahoo.com X-YMail-OSG: bi_UTTYVM1mEEehJTHQ6eNZRPPCulaw9HRhwxzs.La9_2ITJ_NIbSTBX0lqngQD Kv0dv9eT9PIPx.7yXrhVdmdyyl3YFeq5X2L4bhpaaQKvVWn_DHQFUi1tHZfrCMDOK_qbexcXk.bo IVIe9ZwkrTOxkO01kS.Nk60JYta9RJt_IJbeluYWjw6GkOXMUKdcCBPgDNgljGyPg1XL7nM9Oe_C kkSSfSgKfi6yfOqgEK0y8.4ThNeq_.daq7wjmsIRRvYf0vpwKw6p849uD11ZtrAVD5I4tmWTK6tc wq6jGMeBYjxAwT.Sg_T71DcbGBH5KeZEXpMlHfsD8wOCfsDQz2o6Dc_yK8eUbURkvRZViBakooX3 Edb59ju1rOwussvYLeMvoaqFLUCP3GzF2_l2miup8Q0at2z1ipi723UzCAQ6KL8FXIp26w5.F8m_ GG4eoLJ4g7fhbmBKvnPE0pvJCt0uvTFG.L4tiZ1ZVLW1ohnlztHs3LNxfyWibippFUfvO Received: by 76.13.27.6; Thu, 13 Nov 2014 06:37:52 +0000 Date: Thu, 13 Nov 2014 06:35:21 +0000 (UTC) From: Oleg Gryb To: Johannes Merkle , Oleg Gryb , "tls@ietf.org" Message-ID: <1821348128.254417.1415860521951.JavaMail.yahoo@jws10668.mail.bf1.yahoo.com> In-Reply-To: <546394E9.2010208@secunet.com> References: <546394E9.2010208@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pqjQrQPHuN8xR1oPhbNYTWBhcBY Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 06:37:55 -0000 ----- Original Message ----- > From: Johannes Merkle > To: Oleg Gryb ; "tls@ietf.org" > Cc: > Sent: Wednesday, November 12, 2014 9:12 AM > Subject: Re: [TLS] Twist security for brainpoolp256r1 > > As Watson Ladd just pointed out to me, the terms "quadratic twists" > and "non-quadratic twists" are not common in math > textbooks. For a curve in Weierstrass form E: y^2 = x^3 + a*x + b mod p, the > term twist denotes a curve E': y^2 = x^3 > + v^2*a*x + v^3* b mod p. > - If v is a quadratic residue, i.e., if there is a w with w^2 = v mod p, then E > and E' are isomorphic mod p and thus > have equivalent security. > - If v is a quadratic non-residue, E' is not isomorphic to E and the curve > orders satisfy |E| + |E'| = p+2. > Text books often discuss only the case of quadratic non-residues (e.g. Blake, > Seroussi, Smart). > > In the case of the Brainpool curves, the twists mentioned in RFC 5639 are twists > via a quadratic residue and have the > same security as the respective random curves. Thanks, very helpful. Just to summarize yours and Manuel's notes in regard of quadratic non-residue, or non-quadratic twists (as they are called in other emails), they can be used as a source of malicious EC points to run invalid-curve attacks on the original curves, but since all implementations compliant with X9* standards including openssl must have point-on-curve validation, invalid-curve attacks and small-group attacks become irrelevant when it comes to brainpoool's openssl implementation. Note - small group attacks are not possible, because of a different reason: cofactor for all brainpool curves is equal to 1. Efficiency is still an issue for me. Since curves such as NIST P-256 do have optimized EC arithmetic, but nothing like that is available for brainpool curves, it would be nice to know what the delta is. If it's up to 30% percent, I would probably ignore, if it's essentially more than that, I might need to re-consider my choice. If no quantitative data is available, I would probably need to write/run my own tests. > > -- > Johannes > From nobody Thu Nov 13 00:47:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DBF1A6FA6 for ; Thu, 13 Nov 2014 00:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFtOYKjnDEdr for ; Thu, 13 Nov 2014 00:47:29 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7AC1A2130 for ; Thu, 13 Nov 2014 00:47:29 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0M9Gk2-1Xhfay3TJu-00Cgtp; Thu, 13 Nov 2014 09:47:27 +0100 Received: by mail-ob0-f182.google.com with SMTP id nt9so11381146obb.41 for ; Thu, 13 Nov 2014 00:47:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.174.16 with SMTP id bo16mr664932oec.55.1415868444618; Thu, 13 Nov 2014 00:47:24 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 13 Nov 2014 00:47:24 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Nov 2014 09:47:24 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e011838ecb0b6bb0507b98f03 X-Provags-ID: V02:K0:GdAH003u34OQ5GQ2EMaPBhOL8zOeysvU7IBV3J5vKUa kDvoJaLnsk9XQNk/H08dtVPBCXyUeXf8lgESIsdHddr86L27Dj iVhp50izwmLCmsjQAv4ublWXStRqk5ttFOcQaDGRY/pssUbOaO 9KKCavOUxV8lGeHbNcAQGPJAYniCOT5Fwa2sX3LeiL0EDoDdqE J/5bBqf/QUJYdTBvZF9dbFcIDSJxgx7yQt9s6CrsJKkNFaV8rc YLj8uGyQO5Pq3fpamsG3IFzi3+yDvXFbC2gFMw9JpLc13++XNG IACAxIN3xogyVpv2Ef9IJk4s4UILwt+1sAAbd52YNocOmlG7D4 YiFdjQq8BiKPtQbAntCr2xhCT9RztgXl3077PFiyB1HfN5GU/f W6yL/5Skga2nR6GVMGLao0uuj2KXh3Nfaqy8LGhJ6PfIGxUxQ3 9ZMG9 X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GLi6EdH3mzfGE__1H1DNUcJe0WY Subject: Re: [TLS] Downgrade SCSV info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 08:47:31 -0000 --089e011838ecb0b6bb0507b98f03 Content-Type: text/plain; charset=UTF-8 Rob Trace : > Right, although it couldn't hurt for the client to try TLS 1.1 next in > case > > > it sees an inappropriate_fallback alert. (Then in the end you have > > > essentially the same outcome as if trying the protocols in decreasing > order, > > > in the presence of an active attacker forcing you to downgrade.) > > When we looked at the fallback to HTTP 1.1, it was just as Martin stated > and there were almost 0 times when the connection completed over TLS 1.1. > The 1.1 fallback was a lot of wasted roundtrips and did not provide any > value. > > > > I am not sure what a wasted fallback to HTTP 1.1 would provide with SCSV, > in that the TLS 1.0 fallback would still result in the > inappropriate_fallback before we send any data. > I do understand the reasoning, although I don't think that this is a good tradeoff. - There are servers that are TLS 1.2 intolerant but do tolerate TLS 1.1, so in that case the fallback to TLS 1.1 does have a chance to complete the handshake without wasting any round trips (even if the negotiated protocol may still be TLS 1.0). - A handshake failure in the initial TLS 1.2 attempt may be due to network problems rather than incompatibility or an attack. Now assume that the server does not support TLS_FALLBACK_SCSV. In that case, if you fall back to TLS 1.1 first (rather than straight to TLS 1.0), you'll end up using the better protocol (TLS 1.1 instead of TLS 1.0). I'd rather incur additional latency with servers that are TLS 1.1 intolerant than risk falling back to an unnecessarily bad protocol version. (I said that before, about SSL 3.0. ) Anyway, if you *do* fall back from a TLS 1.2 Client Hello to a TLS 1.0 Client Hello with TLS_FALLBACK_SCSV, as I said above it might be a good idea to do the missing TLS 1.1 Client Hello (with TLS_FALLBACK_SCSV) later in the sequence, if you see an inappropriate_fallback alert with TLS 1.0. This doesn't address known interoperability issues with particular servers, but there *could* be servers that are TLS 1.2 intolerant but do support TLS 1.1 (take any decent TLS implementation and add a wacky load balancer in front of it). This sequence still feels wrong (you really, really should try TLS 1.1 before TLS 1.0), but it may improve interoperability further. Bodo --089e011838ecb0b6bb0507b98f03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rob = Trace <Rob.Trace@microsoft.com>:

> Right, although it couldn't hurt for the cl= ient to try TLS 1.1 next in case

> it sees an inappropriate_fallback alert.= (Then in the end you have

> essentially the same outcome as if trying the p= rotocols in decreasing order,

> in the presence of an active attacker forcing y= ou to downgrade.)

=C2=A0

When we looked at the fallback to HTTP 1.1, i= t was just as Martin stated and there were almost 0 times when the connecti= on completed over TLS 1.1.=C2=A0 The 1.1 fallback was a lot of wasted round= trips and did not provide any value.

=C2=A0

I am not sure what a wasted fallback to HTTP 1.1 wou= ld provide with SCSV, in that the TLS 1.0 fallback would still result in th= e inappropriate_fallback before we send any data.


I do understand the reasoning, although I don't = think that this is a good tradeoff.

- There are se= rvers that are TLS 1.2 intolerant but do tolerate TLS 1.1, so in that case = the fallback to TLS 1.1 does have a chance to complete the handshake withou= t wasting any round trips (even if the negotiated protocol may still be TLS= 1.0).

- A handshake failure in the initial TLS 1.= 2 attempt may be due to network problems rather than incompatibility or an = attack. Now assume that the server does not support TLS_FALLBACK_SCSV. In t= hat case, if you fall back to TLS 1.1 first (rather than straight to TLS 1.= 0), you'll end up using the better protocol (TLS 1.1 instead of TLS 1.0= ).

I'd rather incur additional latency with se= rvers that are TLS 1.1 intolerant than risk falling back to an unnecessaril= y bad protocol version. =C2=A0(I said that before, about SSL 3.0. =C2=A0<= ;Cue dramatic music>)

Anyway, if you *do* fall = back from a TLS 1.2 Client Hello to a TLS 1.0 Client Hello with TLS_FALLBAC= K_SCSV, as I said above it might be a good idea to do the missing TLS 1.1 C= lient Hello (with TLS_FALLBACK_SCSV) later in the sequence, if you see an i= nappropriate_fallback alert with TLS 1.0. This doesn't address known in= teroperability issues with particular servers, but there *could* be servers= that are TLS 1.2 intolerant but do support TLS 1.1 (take any decent TLS im= plementation and add a wacky load balancer in front of it). This sequence s= till feels wrong (you really, really should try TLS 1.1 before TLS 1.0), bu= t it may improve interoperability further.

Bodo

--089e011838ecb0b6bb0507b98f03-- From nobody Thu Nov 13 01:21:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D941A6FB9 for ; Thu, 13 Nov 2014 01:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38Mu-93acqdQ for ; Thu, 13 Nov 2014 01:21:34 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B42A1A1BBB for ; Thu, 13 Nov 2014 01:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=Tx9FlvVAFBZ2pL7lT3P3Oeb+4brv+Y3JAy7dffYPRkw=; b=E0d4GtDN9nulXoK4n7vEZtbU3U9Bj+dDkIYTJP2q1qSJyL5Tcoy+h5cfzIAK1pSAH6DJilwxnS9w6mZ0GNHcY0u9gZ2F90ZnXBDIY5Rbw66EJwu0ZRZS9EegsTf1zmfHZ5U0pe1AYeoqhcA4PO0jlWXafnmcDZArszswPJNllQ4=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xoqah-0007eQ-Qa; Thu, 13 Nov 2014 10:21:24 +0100 Message-ID: <54647819.3020802@polarssl.org> Date: Thu, 13 Nov 2014 10:21:29 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Oleg Gryb , Johannes Merkle , "tls@ietf.org" References: <546394E9.2010208@secunet.com> <1821348128.254417.1415860521951.JavaMail.yahoo@jws10668.mail.bf1.yahoo.com> In-Reply-To: <1821348128.254417.1415860521951.JavaMail.yahoo@jws10668.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SN0L3wSvbFazgkwJ1D1NSdJ3-DE Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 09:21:36 -0000 On 13/11/2014 07:35, Oleg Gryb wrote: > Thanks, very helpful. Just to summarize yours and Manuel's notes in regard of > quadratic non-residue, or non-quadratic twists (as they are called in other > emails), they can be used as a source of malicious EC points to run > invalid-curve attacks on the original curves, but since all implementations > compliant with X9* standards including openssl must have point-on-curve > validation, invalid-curve attacks and small-group attacks become irrelevant > when it comes to brainpoool's openssl implementation. The situation is actually a bit more complex. Here is a version that's still a bit simplified but closer to the truth: let's say there are two kinds of protocols (or curve representations): 1. Those who use both coordinates of the points. 2. Those who use only the x coordinate. With the first type, an attacker can for the point to be on (almost) any curve unless the implementation validates that the point lies on the intended curve. Here it doesn't matter if the twist* is secure, this it's not easier for the attacker to force a point on the twist than on any other curve, potentially much weaker. With the second type, the only curve other than the intended one that the attacker can force is the twist*. So, if the twist happens to be secure, the implementation can skip point validation: the attacker will not gain anything by forcing you to use the twist. * meaning what Johannes called the non-quadratic twist. TLS currently is in the first category, which means twist security is not relevant, because: - either the implementation validates points (which it must), - or the attacker can force *much* weaker curves than the twist. > Note - small group > attacks are not possible, because of a different reason: cofactor for all > brainpool curves is equal to 1. > Yes. While we're at it, let's note that the whole purpose of forcing another curve is to do a small subgroup attack by picking a curve that does have small subgroups. > Efficiency is still an issue for me. Since curves such as NIST P-256 do have > optimized EC arithmetic, but nothing like that is available for brainpool > curves, it would be nice to know what the delta is. If it's up to 30% > percent, I would probably ignore, if it's essentially more than that, I might > need to re-consider my choice. If no quantitative data is available, I would > probably need to write/run my own tests. > Openssl has a "speed" command that should be helpful. I'd expect a difference higher than 30%. Manuel. From nobody Thu Nov 13 07:43:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569AE1A897B for ; Thu, 13 Nov 2014 07:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O1gGXckXYMt for ; Thu, 13 Nov 2014 07:43:02 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79C91A8980 for ; Thu, 13 Nov 2014 07:42:47 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id 29so3933395yhl.41 for ; Thu, 13 Nov 2014 07:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ut9sa0cWEiuttQdQAj0yWW9NvslFO5J7Lof6AP6FNL4=; b=MSLifgb3KIxpmuI5m5XtUxjiTU2EzygZlGGBBSMDzRmaJ9odzgRe9yLtw7EX2ZSQ2K y6ZTcsgHStfTvCAB1zT/7iRX+Znvt35QJauKU4eLAEm2HbruwCSAzyi7SZVXm6RZGF9Z j35wipzBI0+nGK/dbim79mmAhS4zzKr9sKvcDRSrwSgecGyi2fvIPY0cRyFVsgym/XEw lhHa8p3S2mX1gZDkD2eQS/IQ+cXsP3H1VmuOR8cri7TpIAVSJxOLqu08IU+EtycO7mhS SmbCC7StVlP6RqwRKx6BVMom4mm2h6me821UDsFKiRn1//hevTh+XXq8AeaXKNZ0V4Qv 8IvQ== MIME-Version: 1.0 X-Received: by 10.170.100.215 with SMTP id r206mr4072113yka.19.1415893367036; Thu, 13 Nov 2014 07:42:47 -0800 (PST) Received: by 10.170.195.203 with HTTP; Thu, 13 Nov 2014 07:42:46 -0800 (PST) In-Reply-To: References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> Date: Thu, 13 Nov 2014 07:42:46 -0800 Message-ID: From: Watson Ladd To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VlkSglWBM7HdXyjBxtZyoq1YW4w Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 15:43:10 -0000 On Wed, Nov 12, 2014 at 8:02 PM, Hugo Krawczyk wro= te: > > > * Assuming that servers will not want to get certificates for use with TL= S > 1.3 > only (why not?), then we need to address the above subcert forgery > scenario > where the atacker gets limited access to the signing key. An imperfect = but > effective solution is to only issue subcerts with short validity period= , > i.e. where the difference T2-T1 is small. In this case the attacker wi= th > temporary access to the signing key can only create a limited number of > subcerts covering a limited time span. > > Operational note: It is the servers' responsibility to create such > short-lived > subcerts but it is the clients' responsibility to check the subcerts are > indeed short-lived (otherwise an attacker can generate a long-lived subce= rt > that the client will accept). > > * Clients with clocks with significant deviations from the correct time w= ill > have trouble accepting valid subcerts and may be induced to accept old = (or > into-the-future) subcerts. I can imagine this to be a problem. But is i= t > enough to abandon the benefits of a ECDH-based solution like OPTLS? I don't think this is quite right. An attacker might root a box connected to an HSM, and sign several thousand short term shares: to the HSM this looks like the website being popular, and will cover a large range of time. There doesn't seem to be an easy way to limit the time the signature was made, and such a limitation could be counterproductive in some scenarios. However, I don't think this is a real problem: HSM usage on major sites is extremely low, and OPTLS makes it easier. Sincerely, Watson Ladd > > On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams > wrote: >> >> On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote: >> > > On Nov 11, 2014, at 7:33 AM, Nico Williams >> > > wrote: >> > > That the "sub-cert" needs either a revocation scheme (not likely) or= a >> > > short lifetime. The latter puts this on a par with session >> > > resumption, >> > > thus making one (well, me) wonder what the advantage to the static D= H >> > > concept would be. >> > >> > There is a revocation scheme. If the private ECDH key is lost, you >> > revoke the certificate, thereby invalidating the delegation. >> >> Ah, good point! >> >> > > We could put static DH keys in DNSSEC and learn them that way, which >> > > would get us 0rt. >> > >> > Another possibility is to place the ECDH public key in a certificate >> > extension. This gives it a lifetime as long as the certificate, and it >> > doesn=E2=80=99t matter whether the =E2=80=9Cregular=E2=80=9D certifica= te public key is RSA or >> > ECDSA or anything else. >> >> Sure, certs could have multiple subject public keys. That'd be a very >> nice. A cert could have an encryption key, a different signature key, >> and a key agreement key. >> >> > It removes the need to use signatures at all by the server. Not even >> > once. >> >> Yes. I like this. >> >> Nico >> -- > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Nov 13 07:43:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB7D1A8998 for ; Thu, 13 Nov 2014 07:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnhH_J2GqFV1 for ; Thu, 13 Nov 2014 07:43:16 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B50C1A8971 for ; Thu, 13 Nov 2014 07:43:00 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id 29so2494329yhl.13 for ; Thu, 13 Nov 2014 07:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Vr2bAYNPhwRE2ms3VUfKw009bdC/Yn0iD9xucvvrOgQ=; b=Hc+HDIYBosfiwru4/rThrNnZy3n8l8L5R6QKgMPotovYkz9uCLH8AyTvKJ7DiC/lTM XkoLVV9ciDM/JdE0cqRHVk9jcDbGhfN3mwLzLrcb4scSTNH7dx41r+oIB3vYKqadqglJ UY5SqJJrljuJlCyj7EeTpuMUkTcy49/g943Bdw1trUWpJEWaEfzh0xfuP0vlXt6vv4aH NMMO5GoZFyC3wKn50AeSh4xovrB/ZnjZEXXM6ZTD0dXV0Lo2xhVvMOEqFw0GT5CLjtoV iVJH9ZI7rYPknvZWhAXLsyuK3ghQeclYWm4br590n6Qqz8zN4qlKdpIADHVN8EpPJt98 ixAg== MIME-Version: 1.0 X-Received: by 10.236.61.6 with SMTP id v6mr3621569yhc.44.1415893379424; Thu, 13 Nov 2014 07:42:59 -0800 (PST) Received: by 10.170.195.203 with HTTP; Thu, 13 Nov 2014 07:42:59 -0800 (PST) In-Reply-To: <54647819.3020802@polarssl.org> References: <546394E9.2010208@secunet.com> <1821348128.254417.1415860521951.JavaMail.yahoo@jws10668.mail.bf1.yahoo.com> <54647819.3020802@polarssl.org> Date: Thu, 13 Nov 2014 07:42:59 -0800 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Wd0uYaI8co5M5M1mO0gFJN1gClI Cc: Oleg Gryb , "tls@ietf.org" Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 15:43:17 -0000 On Thu, Nov 13, 2014 at 1:21 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 13/11/2014 07:35, Oleg Gryb wrote: >> Thanks, very helpful. Just to summarize yours and Manuel's notes in rega= rd of >> quadratic non-residue, or non-quadratic twists (as they are called in ot= her >> emails), they can be used as a source of malicious EC points to run >> invalid-curve attacks on the original curves, but since all implementati= ons >> compliant with X9* standards including openssl must have point-on-curve >> validation, invalid-curve attacks and small-group attacks become irrelev= ant >> when it comes to brainpoool's openssl implementation. > > The situation is actually a bit more complex. Here is a version that's st= ill a > bit simplified but closer to the truth: let's say there are two kinds of > protocols (or curve representations): > > 1. Those who use both coordinates of the points. > 2. Those who use only the x coordinate. The coordinates used on the wire do not determine the calculations used by an implementation. An interoperable implementation of TLS could use the Brier-Joyce ladder on x-coordinates only, and take a randomly chosen square root for use as the y-coordinate, validating signatures through a different method. This would be of interest in certain side-channel attack scenarios, as the Brier-Joyce ladder is easier to protect. Most implementations don't do this, so the rest of your email is correct. Sincerely, Watson Ladd From nobody Thu Nov 13 07:53:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09D1A8997 for ; Thu, 13 Nov 2014 07:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWQXslyNWpfT for ; Thu, 13 Nov 2014 07:53:09 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFBF1A8978 for ; Thu, 13 Nov 2014 07:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=JnUvn559hKAtuS5PqadzkM2LhWmp3IIH8aILSNz88FE=; b=ZtwZo60JwRDuNE7YTTsLdBQWF064NYebSeUTaLPoNRL5pU6w3itZvuaC6d4YLXT+0AYRivbMeHBSjqG8cOiSqy7e7diOXTXxD4j31EdcS7H1VyUGiEtuMFDK9ADN7vymHrdrsXum7Ndh+tVaplsbXsZ7xXWKNkW5lmYljqWje/A=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xowhc-0008F5-C3; Thu, 13 Nov 2014 16:52:56 +0100 Message-ID: <5464D3DD.8010507@polarssl.org> Date: Thu, 13 Nov 2014 16:53:01 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Watson Ladd References: <546394E9.2010208@secunet.com> <1821348128.254417.1415860521951.JavaMail.yahoo@jws10668.mail.bf1.yahoo.com> <54647819.3020802@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/407YJXyiJ1GmY7RrU1RJkY28-94 Cc: Oleg Gryb , "tls@ietf.org" Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 15:53:10 -0000 On 13/11/2014 16:42, Watson Ladd wrote: > On Thu, Nov 13, 2014 at 1:21 AM, Manuel Pégourié-Gonnard > wrote: >> On 13/11/2014 07:35, Oleg Gryb wrote: >>> Thanks, very helpful. Just to summarize yours and Manuel's notes in regard of >>> quadratic non-residue, or non-quadratic twists (as they are called in other >>> emails), they can be used as a source of malicious EC points to run >>> invalid-curve attacks on the original curves, but since all implementations >>> compliant with X9* standards including openssl must have point-on-curve >>> validation, invalid-curve attacks and small-group attacks become irrelevant >>> when it comes to brainpoool's openssl implementation. >> >> The situation is actually a bit more complex. Here is a version that's still a >> bit simplified but closer to the truth: let's say there are two kinds of >> protocols (or curve representations): >> >> 1. Those who use both coordinates of the points. >> 2. Those who use only the x coordinate. > > The coordinates used on the wire do not determine the calculations > used by an implementation. Sure. That's why I said that the above was still a bit simplified. > An interoperable implementation of TLS > could use the Brier-Joyce ladder on x-coordinates only, and take a > randomly chosen square root for use as the y-coordinate, validating > signatures through a different method. This would be of interest in > certain side-channel attack scenarios, as the Brier-Joyce ladder is > easier to protect. > I hope that an implementer who knows this somewhat exotic option and chooses to use it for its side-channel properties is also sufficiently knowledgeable and security concious to properly validate points... > Most implementations don't do this, so the rest of your email is correct. > Thank you. Manuel. From nobody Thu Nov 13 09:39:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9721A8AE9 for ; Thu, 13 Nov 2014 09:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NactdBAt4Kjx for ; Thu, 13 Nov 2014 09:38:57 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EEA1A8F4D for ; Thu, 13 Nov 2014 09:38:44 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id 10so11484438lbg.14 for ; Thu, 13 Nov 2014 09:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=wFjAGJdV7keGtKLP03oPtFb5ilhEwqIDn1X+oOKOo8s=; b=TVy9Et9ZPdZI9fPjXDulyMDfeVTNyv8j2REC53zjePQm/jnxBqgCzHliqHhSGJSSpw mPjj85Kdr5jFP2bHER8ipTBHxllL4rxFb4C2qfQ0JoznVcZm6pZgjS7jndJm/Q4Gk4OL DWhODrELnADDpB0NizKNsX5gL5heq2XyZkkmr5LUQz2Akp0iZgmNxhN9v95N2MmRZ1L1 375YCLaJrnJ9qwsgnuRiNmzf0jVPP072lQrB1RsK4mAe7wdyYjXUsPoizvXmOLFMXkO9 cDRVhFklpovudO5qMc601D0vd0fFo9QaWoieDOKEbednfzSWH76E1jW0y1PD7MtD67iy G67g== X-Received: by 10.152.7.193 with SMTP id l1mr3606734laa.57.1415900322823; Thu, 13 Nov 2014 09:38:42 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Thu, 13 Nov 2014 09:38:12 -0800 (PST) In-Reply-To: References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> From: Hugo Krawczyk Date: Thu, 13 Nov 2014 12:38:12 -0500 X-Google-Sender-Auth: jadpvtwM7TVODdbnlTH-eQaY1jA Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c23dbcc7838b0507c0fbcf Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tHwGIa3z7_cWxw2NVFijgAfL68g Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:39:00 -0000 --001a11c23dbcc7838b0507c0fbcf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am a bit hesitant to bring a new idea immediately before the meeting toda= y but since I won't be there I would like to mention it in case people find i= t useful. I will be happier with the direct adoption of OPTLS but the idea below addresses the delegation concerns at some extra (temporary) cost. The idea is to build OPTLS in a way that allows to use it in two "modes": In the regular mode (r-mode), the protocol is exactly OPTLS as proposed originally in the first message of this thread http://www.ietf.org/mail-archive/web/tls/current/msg14385.html. It enjoys all the benefits of OPTLS including avoiding online signatures. It also avoids most concerns with delegation when servers have TLS 1.3 certificates (more on this below). A second mode, call it "transitional mode" (t-mode), is appropriate for servers that use the same certificates for TLS 1.2 and 1.3 and completely avoids the delegation concerns. The price for this variant is one more exponentiation relative to the cost of the current TLS 1.3 specification. This extra cost is not nice but is not huge either: As a percentage of the performance cost of current TLS 1.3 spec (two exponentiations for PFS and a online RSA signature), the addition of one EC exponentiation is relatively minor (<10% ?). This t-mode works as in OPTLS but replaces the validity period of the subcert with the client nonce. That is, the subcert sign-rsa(g^s, T1, T2, stuff) used in OPTLS (where T1, T2 indicate the limits of validity period and sing-rsa indicates a server's signature using his certified signing key) will be replaced with sign-rsa(g^s, client-nonce, stuff). The rest of the protocol stays the same. Thus t-mode preserves the current online signature, preempts the delegation concerns, but costs one more exponentiation (g^{xs}) relative to current 1.= 3 spec. The cost of the t-mode stays the same as the original OPTLS in the cases of 0-RTT, PSK or session resumption. So why am I saying that TLS 1.3 specific certificates will address the delegation concerns? First, by "TLS 1.3 specific certificates" I mean certificates (typically RSA or ECDSA) that have an indication of use for TL= S 1.3 (I assume such indication can be accommodated in certificates). In this case, a server can use the signing key to only sign static DH keys, hence the signing key is never used online. This allows for a better protection of the key (the concerns with delegation stemmed from temporaril= y vulnerable keys). Moreover, as I indicated in a previous email, a server ca= n even use this signing key to sign multiple static keys (for multiple groups and/or multiple validity periods), securely store these DH keys, and destro= y the signature key. Why do these certificates have to be TLS 1.3 specific (i.e., have an indication in the certificate that this is for use in TLS 1.3)? Because clients need to know when to accept the protocol in r-mode or run i= t in t-mode. The idea would be that clients accept the former only with 1.3-enabled certificates. Interestingly, this approach supports "sound economics": It is the interest of the server to move to r-mode in order to save on the cost of online signatures hence it has a motivation for paying for the extra TLS 1.3 certificate... Hugo On Thu, Nov 13, 2014 at 10:42 AM, Watson Ladd wrote= : > On Wed, Nov 12, 2014 at 8:02 PM, Hugo Krawczyk > wrote: > > > > > > * Assuming that servers will not want to get certificates for use with > TLS > > 1.3 > > only (why not?), then we need to address the above subcert forgery > > scenario > > where the atacker gets limited access to the signing key. An imperfec= t > but > > effective solution is to only issue subcerts with short validity > period, > > i.e. where the difference T2-T1 is small. In this case the attacker > with > > temporary access to the signing key can only create a limited number = of > > subcerts covering a limited time span. > > > > Operational note: It is the servers' responsibility to create such > > short-lived > > subcerts but it is the clients' responsibility to check the subcerts ar= e > > indeed short-lived (otherwise an attacker can generate a long-lived > subcert > > that the client will accept). > > > > * Clients with clocks with significant deviations from the correct time > will > > have trouble accepting valid subcerts and may be induced to accept ol= d > (or > > into-the-future) subcerts. I can imagine this to be a problem. But is > it > > enough to abandon the benefits of a ECDH-based solution like OPTLS? > > I don't think this is quite right. An attacker might root a box > connected to an HSM, and sign several thousand short term shares: to > the HSM this looks like the website being popular, and will cover a > large range of time. There doesn't seem to be an easy way to limit the > time the signature was made, and such a limitation could be > counterproductive in some scenarios. However, I don't think this is a > real problem: HSM usage on major sites is extremely low, and OPTLS > makes it easier. > > Sincerely, > Watson Ladd > > > > On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams > > wrote: > >> > >> On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote: > >> > > On Nov 11, 2014, at 7:33 AM, Nico Williams > >> > > wrote: > >> > > That the "sub-cert" needs either a revocation scheme (not likely) > or a > >> > > short lifetime. The latter puts this on a par with session > >> > > resumption, > >> > > thus making one (well, me) wonder what the advantage to the static > DH > >> > > concept would be. > >> > > >> > There is a revocation scheme. If the private ECDH key is lost, you > >> > revoke the certificate, thereby invalidating the delegation. > >> > >> Ah, good point! > >> > >> > > We could put static DH keys in DNSSEC and learn them that way, whi= ch > >> > > would get us 0rt. > >> > > >> > Another possibility is to place the ECDH public key in a certificate > >> > extension. This gives it a lifetime as long as the certificate, and = it > >> > doesn=E2=80=99t matter whether the =E2=80=9Cregular=E2=80=9D certifi= cate public key is RSA or > >> > ECDSA or anything else. > >> > >> Sure, certs could have multiple subject public keys. That'd be a very > >> nice. A cert could have an encryption key, a different signature key, > >> and a key agreement key. > >> > >> > It removes the need to use signatures at all by the server. Not even > >> > once. > >> > >> Yes. I like this. > >> > >> Nico > >> -- > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > --001a11c23dbcc7838b0507c0fbcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am a bit hesitant to bring a new idea immedia= tely before the meeting today
but since I won't be there I would lik= e to mention it in case people find it
useful. I will be happier with th= e direct adoption of OPTLS but the idea below
addresses= the delegation concerns at some extra (temporary) cost.

The idea is to build OPTLS in a way that allows to use it in two &quo= t;modes":
In the regular mode (r-mode), the protocol is exactly=C2= =A0 OPTLS as proposed
originally in the first message of this thread
= = http://www.ietf.org/mail-archive/web/tls/current/msg14385.html.
It e= njoys all the benefits of OPTLS including avoiding online signatures.=C2=A0=
It also avoids most concerns with delegation when servers have TLS 1.3=
certificates (more on this below).

A second mode, call it "= ;transitional mode" (t-mode), is appropriate for
servers that use t= he same certificates for TLS 1.2 and 1.3 and completely
avoids the deleg= ation concerns. The price for this variant is one more
exponentiation re= lative to the cost of the current TLS 1.3 specification.
This extra cos= t is not nice but is not huge either: As a percentage of the
performance= cost of current TLS 1.3 spec (two exponentiations for PFS and a
online = RSA signature), the addition of one EC exponentiation is relatively
mino= r (<10% ?).
This t-mode works as in OPTLS but replaces the validity p= eriod of the subcert
with the client nonce. That is, the subcert
sig= n-rsa(g^s, T1, T2, stuff)
used in OPTLS (where T1, T2 indicate the limi= ts of validity period and
sing-rsa indicates a server's signature us= ing his certified signing key)
will be replaced with
sign-rsa(g^s, = client-nonce, stuff).
The rest of the protocol stays the same.
Thus t= -mode preserves the current online signature, preempts the delegation
co= ncerns, but costs one more exponentiation (g^{xs}) relative to current 1.3<= br>spec. The cost of the t-mode stays the same as the original OPTLS in the= cases
of 0-RTT, PSK or session resumption.

So why am I saying th= at TLS 1.3 specific certificates will address the
delegation concerns? F= irst, by "TLS 1.3 specific certificates" I mean
certificates (= typically RSA or ECDSA) that have an indication of use for TLS
1.3 (I as= sume such indication can be accommodated in certificates).
In this case,= a server can use the signing key to only sign static DH keys,
hence the= signing key is never used online. This allows for a better
protection o= f the key (the concerns with delegation stemmed from temporarily
vulnera= ble keys). Moreover, as I indicated in a previous email, a server can
ev= en use this signing key to sign multiple static keys (for multiple groupsand/or multiple validity periods), securely store these DH keys, and dest= roy
the signature key. Why do these certificates have to be TLS 1.3 spec= ific
(i.e., have an indication in the certificate that this is for use i= n TLS 1.3)?
Because clients need to know when to accept the protocol in = r-mode or run it
in t-mode. The idea would be that clients accept the fo= rmer only with
1.3-enabled certificates.

Interestingly, this appr= oach supports "sound economics": It is the interest of
the ser= ver to move to r-mode in order to save on the cost of online signatures
= hence it has a motivation for paying for the extra TLS 1.3 certificate...
Hugo

On Thu, Nov 13, 2014 at 10:42 AM, Watson Ladd &l= t;watsonbladd@gm= ail.com> wrote:
On Wed, Nov= 12, 2014 at 8:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
><snip>
>
> * Assuming that servers will not want to get certificates for use with= TLS
> 1.3
>=C2=A0 =C2=A0only (why not?), then we need to address the above subcert= forgery
> scenario
>=C2=A0 =C2=A0where the atacker gets limited access to the signing key. = An imperfect but
>=C2=A0 =C2=A0effective solution is to only issue subcerts with short va= lidity period,
>=C2=A0 =C2=A0i.e.=C2=A0 where the difference T2-T1 is small. In this ca= se the attacker with
>=C2=A0 =C2=A0temporary access to the signing key can only create a limi= ted number of
>=C2=A0 =C2=A0subcerts covering a limited time span.
>
> Operational note: It is the servers' responsibility to create such=
> short-lived
> subcerts but it is the clients' responsibility to check the subcer= ts are
> indeed short-lived (otherwise an attacker can generate a long-lived su= bcert
> that the client will accept).
>
> * Clients with clocks with significant deviations from the correct tim= e will
>=C2=A0 =C2=A0have trouble accepting valid subcerts and may be induced t= o accept old (or
>=C2=A0 =C2=A0into-the-future) subcerts. I can imagine this to be a prob= lem. But is it
>=C2=A0 =C2=A0enough to abandon the benefits of a ECDH-based solution li= ke OPTLS?

I don't think this is quite right. An attacker might root a box<= br> connected to an HSM, and sign several thousand short term shares: to
the HSM this looks like the website being popular, and will cover a
large range of time. There doesn't seem to be an easy way to limit the<= br> time the signature was made, and such a limitation could be
counterproductive in some scenarios. However, I don't think this is a real problem: HSM usage on major sites is extremely low, and OPTLS
makes it easier.

Sincerely,
Watson Ladd
>
> On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams <nico@cryptonector.com>
> wrote:
>>
>> On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote:
>> > > On Nov 11, 2014, at 7:33 AM, Nico Williams <nico@cryptonector.com>
>> > > wrote:
>> > > That the "sub-cert" needs either a revocation = scheme (not likely) or a
>> > > short lifetime.=C2=A0 The latter puts this on a par with= session
>> > > resumption,
>> > > thus making one (well, me) wonder what the advantage to = the static DH
>> > > concept would be.
>> >
>> > There is a revocation scheme. If the private ECDH key is lost= , you
>> > revoke the certificate, thereby invalidating the delegation.<= br> >>
>> Ah, good point!
>>
>> > > We could put static DH keys in DNSSEC and learn them tha= t way, which
>> > > would get us 0rt.
>> >
>> > Another possibility is to place the ECDH public key in a cert= ificate
>> > extension. This gives it a lifetime as long as the certificat= e, and it
>> > doesn=E2=80=99t matter whether the =E2=80=9Cregular=E2=80=9D = certificate public key is RSA or
>> > ECDSA or anything else.
>>
>> Sure, certs could have multiple subject public keys.=C2=A0 That= 9;d be a very
>> nice.=C2=A0 A cert could have an encryption key, a different signa= ture key,
>> and a key agreement key.
>>
>> > It removes the need to use signatures at all by the server. N= ot even
>> > once.
>>
>> Yes.=C2=A0 I like this.
>>
>> Nico
>> --
>
>
>
> ________________________________= _______________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

--001a11c23dbcc7838b0507c0fbcf-- From nobody Thu Nov 13 10:18:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA461A90C1 for ; Thu, 13 Nov 2014 10:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mehAPzuc05uO for ; Thu, 13 Nov 2014 10:18:16 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 86AE31A90BF for ; Thu, 13 Nov 2014 10:18:16 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 374C847FB9; Thu, 13 Nov 2014 18:18:15 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1E0E847FB7; Thu, 13 Nov 2014 18:18:15 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 0C6DB80058; Thu, 13 Nov 2014 18:18:15 +0000 (GMT) Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 13 Nov 2014 13:18:14 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 13 Nov 2014 13:18:14 -0500 From: "Salz, Rich" To: Hugo Krawczyk Date: Thu, 13 Nov 2014 13:18:13 -0500 Thread-Topic: [TLS] OPTLS: Signature-less TLS 1.3 Thread-Index: Ac//aLtDZMPP8r0NRuiIOmFaFXW2ywABLymg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D50B356CE@USMBX1.msg.corp.akamai.com> References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pPUlD7EkdCDrVZ_ixwop_tVZYfA Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 18:18:18 -0000 SSB0aGluayB0aGUgbWFqb3IgY29uY2VybiBpcyB0aGF0IHRoaXMgaXMgYSBwcmV0dHkgcmFkaWNh bCBjaGFuZ2UgZnJvbSB0aGUgY3VycmVudCBkZXBsb3ltZW50IG1vZGVsIG9mIFNTTC9UTFMuICBG b3Igd2hhdCBpdCdzIHdvcnRoLCBJIHRoaW5rIGl0J3MgY29vbCBhbmQgY2xldmVyIGFuZCBoYXMg YSBudW1iZXIgb2YgcmVhbCBuaWNlIHByb3BlcnRpZXMuIEJ1dCB3ZSBhcmUgYWxyZWFkeSBnZXR0 aW5nICdwaWNrZWQgb24nIGZvciBhZGRpbmcgdG9vIG1hbnkgbmV3IHRoaW5ncywgYW5kIEkgYW0g Y29uY2VybmVkIHRoYXQgYWRkaW5nIHRoaXMsIGZhaXJseSBsYXRlIGluIHRoZSBnYW1lLCB3aWxs IGRlbGF5IHRoZSBkZXBsb3ltZW50IG9mIFRMUyAxLjMgYXMgcGVvcGxlIHdpbGwgdGFrZSBhIHN0 ZXAgYmFjayBhbmQgY29uc2lkZXIgaWYgdGhleSByZWFsbHkgbmVlZCB0byB1c2UgdGhpcyByZXZv bHV0aW9uYXJ5IG5ldyBwcm90b2NvbCwgcmF0aGVyIHRoYW4gdGhlIGV2b2x1dGlvbmFyeSBjaGFu Z2VzIHRoZXkgd2VyZSBleHBlY3RpbmcuDQoNCkkgdXNlZCBteSBwZXJzb25hbCBvcGluaW9uIGhl cmUsIGJ1dCBJIGZlZWwgcHJldHR5IGNvbWZvcnRhYmxlIHNheWluZyBJJ20gbm90IHRoZSBvbmx5 IG9uZSB3aG8gZmVlbHMgdGhpcyB3YXkuIEl0J3MgYSBjYXNlIG9mICJ0b28gbXVjaCwgdG9vIGxh dGUuIg0KDQpEb2VzIHRoYXQgbWFrZSBzZW5zZT8NCg0KQ2FuIHdlIHdyYXAgdXAgVExTIDEuMyBh bmQgcGVyaGFwcyBkbyBhIFRMUyAyIGJhc2VkIG9uIHRoZXNlIGNvbmNlcHRzLCBpbmNsdWRpbmcg YSAgbm9uLUNBIHRydXN0IG1vZGVsPw0KDQoJL3IkDQogDQoNCg== From nobody Thu Nov 13 10:28:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129651A914C for ; Thu, 13 Nov 2014 10:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtnMyOY5dvOv for ; Thu, 13 Nov 2014 10:28:19 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE2CB1A9147 for ; Thu, 13 Nov 2014 10:28:07 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id sADIRxfW020300; Thu, 13 Nov 2014 13:27:59 -0500 From: "Blumenthal, Uri - 0558 - MITLL" To: "'rsalz@akamai.com'" , "'hugo@ee.technion.ac.il'" Thread-Topic: [TLS] OPTLS: Signature-less TLS 1.3 Thread-Index: AQHP9W5vfZf99orDg02SyWYYjHdgMJxLQviAgAL4FgCAAAf5AIAB3XMAgAC7OYCAAbglAIAA8gyAgAO++wCAAcnqgIABxBiAgAASpYCAAARiAIAACEUAgAAKSACAABEbgIAABSoAgAA9SYCAAJWKAIAALpuAgAAlbICAAA4RAIACDpOAgADDrQCAACBBAIAACy6A//+u6A4= Date: Thu, 13 Nov 2014 18:27:58 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC13F96B24@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D50B356CE@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-13_08:2014-11-13,2014-11-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411130142 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dRes4Ct22ooK0bSHL-_p5KkK8jY Cc: "'tls@ietf.org'" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 18:28:22 -0000 I'd be comfortable with OPTLS added to 1.3.=20 -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street, Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Salz, Rich [mailto:rsalz@akamai.com] Sent: Thursday, November 13, 2014 01:18 PM=0A= To: Hugo Krawczyk Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 I think the major concern is that this is a pretty radical change from the = current deployment model of SSL/TLS. For what it's worth, I think it's coo= l and clever and has a number of real nice properties. But we are already g= etting 'picked on' for adding too many new things, and I am concerned that = adding this, fairly late in the game, will delay the deployment of TLS 1.3 = as people will take a step back and consider if they really need to use thi= s revolutionary new protocol, rather than the evolutionary changes they wer= e expecting. I used my personal opinion here, but I feel pretty comfortable saying I'm n= ot the only one who feels this way. It's a case of "too much, too late." Does that make sense? Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts, incl= uding a non-CA trust model? /r$ =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 13 10:55:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947151A9253 for ; Thu, 13 Nov 2014 10:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pE4u1IZyKSp for ; Thu, 13 Nov 2014 10:55:12 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1581A924E for ; Thu, 13 Nov 2014 10:55:12 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gf13so1871001lab.27 for ; Thu, 13 Nov 2014 10:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ZTwh/ktEjV4LxHodyk7SHLVctOO8Y5Lr+8nhP2gzV0s=; b=ABHDAbgiVkUSica3ot9NVoYwG9FNP6hReKSBWc/vT+uj6ccofluyCtGSqCc8oHNEVt 2ehEYP0nz8ic2uiow9VL7PD+K1AaDFGiiRrXAQ6us9ZqFwxy/0TZ+yd53miaVBmeUThR VyTIX9n8JG0EJxG7G7qok+JwsQa607XPrE7NYY54wrKxfVx7PiKBlk9HJmBs6mRp2Muq TX8ddXsg5/AffekLM8UO/2t31fXI04fR/4C5c4szhWBjQAmlnsb6bT9Mx7i70Pwl30KK 7EMfvlM+GXu5/fIIPWkAkAtmcilm7zRU5KrK+zbq9o5KkEru8qHGnSs2w7lfbXcY8The 6nvg== X-Received: by 10.152.43.97 with SMTP id v1mr4016177lal.3.1415904910868; Thu, 13 Nov 2014 10:55:10 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Thu, 13 Nov 2014 10:54:40 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D50B356CE@USMBX1.msg.corp.akamai.com> References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> <2A0EFB9C05D0164E98F19BB0AF3708C71D50B356CE@USMBX1.msg.corp.akamai.com> From: Hugo Krawczyk Date: Thu, 13 Nov 2014 13:54:40 -0500 X-Google-Sender-Auth: atmPtd0sxqqw54NMJy1RCqBhRg0 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11c356263f857d0507c20d7c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EgT1BU6RJpGpURZiw3zaTCUfK0s Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 18:55:14 -0000 --001a11c356263f857d0507c20d7c Content-Type: text/plain; charset=UTF-8 If you consider the t-mode of OPTLS I suggested in the previous email then the changes relative to 1.2 are not much more significant than those introduced in 1.3. Please think about this point. It is important! Right now people are going through the process of digesting these ideas so it all seems much more complex than they really are. This is particularly true for the t-mode where the only thing that changes w.r.t current TLS 1.3 is that servers generate keys g^s which they can do as frequently or non-frequently as they wish, can support as many groups as they wish, require no certification and raise no issues of delegation. The rest is just a change of what you sign and the key derivation formulas. It is hard to believe that this should be considered as changing things radically. The fact that this enables the more forward looking r-mode should be an advantage that servers can enjoy down the road (without yet another revision of the protocol). In particular, the r-mode could be the real incentive (together with 0-RTT, for those that need it) to move to 1.3. Currently, the only substantial thing that 1.3 is offering (other than security improvements that people seem to consider less significant than functional/performance improvements) is forward secrecy. I am not sure that by itself it would be a strong enough incentive to upgrade. Hugo On Thu, Nov 13, 2014 at 1:18 PM, Salz, Rich wrote: > I think the major concern is that this is a pretty radical change from the > current deployment model of SSL/TLS. For what it's worth, I think it's > cool and clever and has a number of real nice properties. But we are > already getting 'picked on' for adding too many new things, and I am > concerned that adding this, fairly late in the game, will delay the > deployment of TLS 1.3 as people will take a step back and consider if they > really need to use this revolutionary new protocol, rather than the > evolutionary changes they were expecting. > > I used my personal opinion here, but I feel pretty comfortable saying I'm > not the only one who feels this way. It's a case of "too much, too late." > > Does that make sense? > > Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts, > including a non-CA trust model? > > /r$ > > > --001a11c356263f857d0507c20d7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you consider the t-mode of OPTLS I suggested= in the previous email then the changes relative to 1.2 are not much more s= ignificant than those introduced in 1.3. Please think about this point. It = is important! Right now people are going through the process of digesting t= hese ideas so it all seems much more complex than they really are.

= This is particularly true for the t-mode where the only thing that changes = w.r.t current TLS 1.3 is that servers generate keys g^s which they can do a= s frequently or non-frequently as they wish, can support as many groups as = they wish, require no certification and raise no issues of delegation. The = rest is just a change of what you sign and the key derivation formulas. It = is hard to believe that this should be considered as changing things radica= lly. The fact that this enables the more forward looking r-mode should be a= n advantage that servers can enjoy down the road (without yet another revis= ion of the protocol). In particular, the r-mode could be the real incentive= (together with 0-RTT, for those that need it) to move to 1.3. Currently, t= he only substantial thing that 1.3 is offering (other than security improve= ments that people seem to consider less significant than functional/perform= ance improvements) is forward secrecy. I am not sure that by itself it woul= d be a strong enough incentive to upgrade.

Hugo
=


On Thu, Nov 13, 2014 at 1:18 PM, Salz, Rich <rsalz@akamai.= com> wrote:
I think the maj= or concern is that this is a pretty radical change from the current deploym= ent model of SSL/TLS.=C2=A0 For what it's worth, I think it's cool = and clever and has a number of real nice properties. But we are already get= ting 'picked on' for adding too many new things, and I am concerned= that adding this, fairly late in the game, will delay the deployment of TL= S 1.3 as people will take a step back and consider if they really need to u= se this revolutionary new protocol, rather than the evolutionary changes th= ey were expecting.

I used my personal opinion here, but I feel pretty comfortable saying I'= ;m not the only one who feels this way. It's a case of "too much, = too late."

Does that make sense?

Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts, incl= uding a=C2=A0 non-CA trust model?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$



--001a11c356263f857d0507c20d7c-- From nobody Thu Nov 13 11:19:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F111ACCDF; Thu, 13 Nov 2014 11:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bWk1uHN_Bq7; Thu, 13 Nov 2014 11:19:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B7C1ACD55; Thu, 13 Nov 2014 11:12:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113191256.6548.35881.idtracker@ietfa.amsl.com> Date: Thu, 13 Nov 2014 11:12:56 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fgehC4r1nXGtAlJ6yu3x1JAwGLY Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-17.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:19:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-17.txt Pages : 11 Date : 2014-11-13 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-cached-info-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 13 11:20:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364631ACD75 for ; Thu, 13 Nov 2014 11:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMv26jMfZwSD for ; Thu, 13 Nov 2014 11:20:32 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E951ACD8F for ; Thu, 13 Nov 2014 11:14:27 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id n3so3041327wiv.2 for ; Thu, 13 Nov 2014 11:14:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=BxFNB9tXpxayWc4CJxz5hSiupiOUlxn5SkPrb/pplvg=; b=RMbRecF3nryRIUk01jkLzUA5lhGe+eNZ7S3XJUYIrI8hTFwo60f8nCWtp2ubstn3FY epWFwjevyTBmmHsudFhPB1XFPD1yTQPe9gUO/wepboxV5+iN6lv4qmrJWndhuWb5CzKQ Nfm+0xSf83Jn691H9oTi6pbRzaccx3AHNoiJA7/3lstUzvPGsgKDaFTwsqoP5MLHWSxP vvSUXLOr+Ba0J5tP6nf7tyEt7QxbJetVp/hRoIu5oncHkvxQtxjhURJ+j7xqkf/D/xhb sHrRULYRoMDYLk8HmyWdEKP1dEAHJyRYxppoKDvlHnTurH+AvVSdZXarjLccv4UFn/PB 9rbw== X-Gm-Message-State: ALoCoQmwG1MO9YgGON/0/JdIFA+hnPeSnJqDKZHGsq1A/Y9OJT3Ad+QVguUn3IDugLIL1G6s2aSH X-Received: by 10.180.104.232 with SMTP id gh8mr961387wib.78.1415906066089; Thu, 13 Nov 2014 11:14:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Thu, 13 Nov 2014 11:13:45 -0800 (PST) From: Eric Rescorla Date: Thu, 13 Nov 2014 09:13:45 -1000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428dc61addce0507c252e0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1VkrcEVkaMYV-bvPDw0bjRf-5-s Subject: [TLS] PRs for this morning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:20:38 -0000 --f46d04428dc61addce0507c252e0 Content-Type: text/plain; charset=UTF-8 Hi folks. At the interim, people asked to see initial treatments of some proposed changes to TLS 1.3 via the update mechanism. I've uploaded Work in Progress (i.e., not ready for merging) versions of these and put them up for comment as pull requests: Update mechanism: https://github.com/tlswg/tls13-spec/pull/94 Moving client auth to update: https://github.com/tlswg/tls13-spec/pull/95 Merging session resumption and tickets and moving ticket establishment to a update: https://github.com/tlswg/tls13-spec/pull/96 Warning: both of the latter two build on the first but they are independent for ease of understanding. If we have time, we'll be talking about these in the meeting today and then on the list. If people are generally happy with this approach I'll prepare new PRs for WG review (i.e., you will get another chance to take a look). -Ekr --f46d04428dc61addce0507c252e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks. At the interim, people asked to see initial trea= tments of some
proposed changes to TLS 1.3 via the update mechanism. I&= #39;ve
uploaded Work in Progress (i.e., not ready for merging) ve= rsions
of these and put them up for comment as pull requests:

Update mechanism:


Merging session res= umption and tickets and moving ticket
establishment to a update:<= /div>

Warning= : both of the latter two build on the first but they are independent
<= div>for ease of understanding.

If we have time, we= 'll be talking about these in the meeting today and
then on t= he list. If people are generally happy with this approach I'll prepare<= /div>
new PRs for WG review (i.e., you will get another chance to take = a look).
=C2=A0
-Ekr




--f46d04428dc61addce0507c252e0-- From nobody Thu Nov 13 11:42:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48CE1ACE3E for ; Thu, 13 Nov 2014 11:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9Jh8WCIPCsY for ; Thu, 13 Nov 2014 11:41:59 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65671ACE21 for ; Thu, 13 Nov 2014 11:41:58 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 19so754553ykq.4 for ; Thu, 13 Nov 2014 11:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BwJtuCzaN4sHjyBkaBDWkGRSVtu1Z4GqT9kFgyJY5F8=; b=IOpoZnRKjRK9h4DC35oG2M8XIDUsTplcXquOCK7BKpbE9t3Zrs6/CpaThqUUMiKiFa CVhL/EiZErYTpgaKdzsB121+zIAS9TSNFWPhAo216QRPeUwMKAXfy5LTuDHjLYeW+H8P 9Xuueqdn5jU0R6orlshccogCWnL8AmPdPz7OkyE9Cs2sslYmvLz9FnNJ2YvDMRibcvf6 DSX3pMw65+PS0bwwSrCfuucOW/DMQZVONzYF8tvhtWLOtuWrvb8DfUgHu/ougg8GYouz 73zCgMpqysBe8qzlr/jw0IMFQe7Kbo1tW48ba9cT4ULza4HcyTiYxD9uqCw+FEhg/cQ8 s08g== MIME-Version: 1.0 X-Received: by 10.236.11.19 with SMTP id 19mr5457939yhw.4.1415907718077; Thu, 13 Nov 2014 11:41:58 -0800 (PST) Received: by 10.170.195.203 with HTTP; Thu, 13 Nov 2014 11:41:57 -0800 (PST) Received: by 10.170.195.203 with HTTP; Thu, 13 Nov 2014 11:41:57 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D50B356CE@USMBX1.msg.corp.akamai.com> References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> <2A0EFB9C05D0164E98F19BB0AF3708C71D50B356CE@USMBX1.msg.corp.akamai.com> Date: Thu, 13 Nov 2014 11:41:57 -0800 Message-ID: From: Watson Ladd To: Rich Salz Content-Type: multipart/alternative; boundary=001a113674469222a00507c2b43e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Yuu6jjdn_b4uW5ZoS_AGkhJS6s Cc: tls@ietf.org Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:42:04 -0000 --001a113674469222a00507c2b43e Content-Type: text/plain; charset=UTF-8 On Nov 13, 2014 10:18 AM, "Salz, Rich" wrote: > > I think the major concern is that this is a pretty radical change from the current deployment model of SSL/TLS. For what it's worth, I think it's cool and clever and has a number of real nice properties. But we are already getting 'picked on' for adding too many new things, and I am concerned that adding this, fairly late in the game, will delay the deployment of TLS 1.3 as people will take a step back and consider if they really need to use this revolutionary new protocol, rather than the evolutionary changes they were expecting. > > I used my personal opinion here, but I feel pretty comfortable saying I'm not the only one who feels this way. It's a case of "too much, too late." > > Does that make sense? > > Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts, including a non-CA trust model? Wrap up what exactly? The TLS 1.3 draft as it stands has had very little security analysis applied. Important questions remain to be resolved. It's already a major change from TLS 1.2 and increasingly so as more gets reworked. OPTLS is not something to be added as an option on top of whatever else we want. It's a protocol that solves the problems TLS 1.3 was intended to solve, and to do so with a design that takes advantage of our knowledge of security analysis. Whatever deployment issues exist will exist for TLS 1.3: reuse of TCP connections reduces the impact of latency. TLS 2 could do a lot more for security: use formal languages to make parsing easy, make implementation simplicity a priority. I doubt the IETF ever could achieve this: we had IRC and now have XMPP, to name the most egregious example. While you can use a different deployment model you don't have to: certs can be put on all frontend machines exactly as now. As for non-CA trust model, I'm not sure we have a good one that includes all uses of TLS: I'd like to know what you propose, but I'm not sure this list is the place. Sincerely, Watson Ladd > > /r$ > > > _______________________________________________ > TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --001a113674469222a00507c2b43e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 13, 2014 10:18 AM, "Salz, Rich" <rsalz@akamai.com> wrote:
>
> I think the major concern is that this is a pretty radical change from= the current deployment model of SSL/TLS.=C2=A0 For what it's worth, I = think it's cool and clever and has a number of real nice properties. Bu= t we are already getting 'picked on' for adding too many new things= , and I am concerned that adding this, fairly late in the game, will delay = the deployment of TLS 1.3 as people will take a step back and consider if t= hey really need to use this revolutionary new protocol, rather than the evo= lutionary changes they were expecting.
>
> I used my personal opinion here, but I feel pretty comfortable saying = I'm not the only one who feels this way. It's a case of "too m= uch, too late."
>
> Does that make sense?
>
> Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts,= including a=C2=A0 non-CA trust model?

Wrap up what exactly? The TLS 1.3 draft as it stands has had= very little security analysis applied. Important questions remain to be re= solved. It's already a major change from TLS 1.2 and increasingly so as= more gets reworked.

OPTLS is not something to be added as an option on top of wh= atever else we want. It's a protocol that solves the problems TLS 1.3 w= as intended to solve, and to do so with a design that takes advantage of ou= r knowledge of security analysis.

Whatever deployment issues exist will exist for TLS 1.3: reu= se of TCP connections reduces the impact of latency.

TLS 2 could do a lot more for security: use formal languages= to make parsing easy, make implementation simplicity a priority.=C2=A0 I d= oubt the IETF ever could achieve this: we had IRC and now have XMPP, to nam= e the most egregious example.

While you can use a different deployment model you don't= have to: certs can be put on all frontend machines exactly as now.

As for non-CA trust model, I'm not sure we have a good o= ne that includes all uses of TLS: I'd like to know what you propose,=C2= =A0 but I'm not sure this list is the place.

Sincerely,
Watson Ladd
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$
>
>
> _______________________________________________
> TLS mailing list
>TLS@ietf.org
>https://www.ietf.= org/mailman/listinfo/tls

--001a113674469222a00507c2b43e-- From nobody Thu Nov 13 11:58:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43481ACE30 for ; Thu, 13 Nov 2014 11:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0yyvS63dn-B for ; Thu, 13 Nov 2014 11:58:46 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 181301ACEF3 for ; Thu, 13 Nov 2014 11:58:43 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4F658486C2; Thu, 13 Nov 2014 19:58:43 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 44036486C0; Thu, 13 Nov 2014 19:58:43 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 2AE449803E; Thu, 13 Nov 2014 19:58:43 +0000 (GMT) Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 13 Nov 2014 14:58:42 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 13 Nov 2014 14:58:42 -0500 From: "Salz, Rich" To: Watson Ladd Date: Thu, 13 Nov 2014 14:58:41 -0500 Thread-Topic: [TLS] OPTLS: Signature-less TLS 1.3 Thread-Index: Ac//eeTFL5FsUmKpTvG21mqCLO4g8gAAjexg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D50B35754@USMBX1.msg.corp.akamai.com> References: <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> <2A0EFB9C05D0164E98F19BB0AF3708C71D50B356CE@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Cmoiwe2tOZ41xDE2Lvwak1ypE0A Cc: "tls@ietf.org" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:58:48 -0000 PiBBcyBmb3Igbm9uLUNBIHRydXN0IG1vZGVsLCBJJ20gbm90IHN1cmUgd2UgaGF2ZSBhIGdvb2Qg b25lIHRoYXQgaW5jbHVkZXMgYWxsIHVzZXMgb2YgVExTOiBJJ2QgbGlrZSB0byBrbm93IHdoYXQg eW91IHByb3Bvc2UswqAgYnV0IEknbSBub3Qgc3VyZSB0aGlzIGxpc3QgaXMgdGhlIHBsYWNlLg0K DQpEb2Vzbid0IG1hdHRlciwgc2luY2UgSSBkb24ndCBoYXZlIG9uZSB0byBwcm9wb3NlIGFuZCB3 YXMganVzdCBwb2ludGluZyBpdCBvdXQgYXMgYW4gaXNzdWUgd2l0aCBPUFRMUyB2MQ0KDQoJL3Ik DQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlciwgQWthbWFpIFRlY2hub2xvZ2ll cw0KSU06IHJzYWx6QGphYmJlci5tZSBUd2l0dGVyOiBSaWNoU2Fseg0KDQo= From nobody Thu Nov 13 12:00:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4901ACF7A for ; Thu, 13 Nov 2014 12:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhlVF7Ibx4hU for ; Thu, 13 Nov 2014 12:00:41 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965F31ACF79 for ; Thu, 13 Nov 2014 12:00:39 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 7FABD3A1F9; Thu, 13 Nov 2014 21:00:37 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4BA2942870; Thu, 13 Nov 2014 21:00:37 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 455711AFCB; Thu, 13 Nov 2014 21:00:37 +0100 (CET) In-Reply-To: To: Eric Rescorla Date: Thu, 13 Nov 2014 21:00:37 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141113200037.455711AFCB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mvL_Teh8AGAJqB9Yio_UScg04eU Cc: "tls@ietf.org" Subject: Re: [TLS] PRs for this morning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:00:46 -0000 Eric Rescorla wrote: > > Merging session resumption and tickets and moving ticket > establishment to a update: > https://github.com/tlswg/tls13-spec/pull/96 In case that you intend to add rfc5077 TLS session ticket support to TLSv1.3, is that using the same bogus CBC-Encryption (i.e. mac+pad+encrypt instead of pad+mac+encrypt) that Vaudenay described as a security issue, that was never fixed in TLS up to v1.2 and provided the grounds for LuckyThirteen and Poodle? If yes, then how about fixing a known design flaw _before_ it is demonstrated to be exploitable? -Martin From nobody Thu Nov 13 12:05:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8760C1ACFAC for ; Thu, 13 Nov 2014 12:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHdcIhgRyic8 for ; Thu, 13 Nov 2014 12:05:22 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196B81ACFDC for ; Thu, 13 Nov 2014 12:05:03 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id gq1so11473358obb.20 for ; Thu, 13 Nov 2014 12:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q9LSC5LVEAm1iHtjlt3d7pFp0kavVTVK9r8QISC34a8=; b=QFn97bvtJTIWKbUVuY9iCcmbAQuk6PXUn9N5BpAZ0JnGPedXIuOcwt6S07Y2xALlBe 6XVdh2OXC94aZ5G278MwUpWdA0LSxMgvrnybz9PttjQePNXcyMwVV54xDzg+M0sr00DQ /UYrOfLhHU2WQBwVUKgxNCBJDFO8BkSlL3Lp4RW2SjCNZOQLeqQJjVBdl1vnQpBuwiLr KRfBu2Tj/3UgQ13fCasfWioB1pB7/h6UYXFjrVZYQciSwGlNMbvaJ2fuaaQPGOvNFV1n HPtOKOTCWeCm0ozS0PiOt9ArWvRQZxlWg/I+AUgY0TrG60QEaMLYjiV/wtmbQEh5tWs4 fPCg== MIME-Version: 1.0 X-Received: by 10.60.177.41 with SMTP id cn9mr3207961oec.63.1415909102394; Thu, 13 Nov 2014 12:05:02 -0800 (PST) Received: by 10.202.197.212 with HTTP; Thu, 13 Nov 2014 12:05:02 -0800 (PST) Date: Thu, 13 Nov 2014 12:05:02 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" , Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Kuth-Jp73n0ABYALzx-BiogqoVo Subject: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:05:24 -0000 The thesis here is that strong groups (and 2048 isn't that strong) are extremely expensive to verify, and folks are unlikely to do that verification. Therefore, the pick-your-own-group method is not just a bad idea, but an invitation to attack. The draft as written, however, allows all sorts of escapes in the form of SHOULD-based statements for clients and servers to negotiate FFDHE ciphersuites with the server doing PYOG. Clients who want to do PYOG can simply not support (or pretend to not support) this draft. ## Details: The draft says that, for servers: If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e. any codepoint between 256 and 511 inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server SHOULD NOT select an FFDHE ciphersuite. I think that this needs to be a MUST. If the client is willing to take the servers choice of group, then it would not be including the fixed groups. Similarly, all the SHOULDs in the client behaviour section needs to be hardened. OLD: The compatible client that wants to be able to negotiate strong FFDHE SHOULD send a "Supported Groups" extension NEW: The compatible client that wants to be able to negotiate strong FFDHE sends a "Supported Groups" extension Rationale: This is purely axiomatic. OLD: A client that offers any of these values in the elliptic_curves extension SHOULD ALSO include at least one FFDHE ciphersuite in the Client Hello. NEW: A client that offers a NamedCurve extension containing a FFDHE group cannot use Rationale: No need for normative language here, this is purely a (relevant) observation. And "SHOULD ALSO" doesn't appear in RFC 2119 ;) The only escape valve that is needed already exists: If none of the offered groups match, the server is not compatible with this draft. The client MAY decide to continue the connection if the selected group is acceptable under local policy, or it MAY decide to terminate the connection with a fatal insufficient_security(71) alert. From nobody Thu Nov 13 12:13:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9952B1ACE82 for ; Thu, 13 Nov 2014 12:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKBDnu2Yd3k3 for ; Thu, 13 Nov 2014 12:13:13 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19181ACF5F for ; Thu, 13 Nov 2014 12:13:08 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id z6so1302262yhz.25 for ; Thu, 13 Nov 2014 12:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u022rkKVJyhao+MFyCHwcardlhbfXX3RlU3ot9bx9Bg=; b=yz/ooKK3NQVrZw9Qm5Eidh8RbG4erYg6VCSZpQ3qqpDQMVV3oKvai8CslpMYb6H88b 5t4nREl9nzJODB9avjv0qhYPNXiP7PbZk+GdOMqvAlQ7umSMRuEiU6ED+kJkIsspbc3x gTT3xcT2ctSxEA6hgV9Wb63D5BjybPfkWsq9PPJ7/Sukpb8qllpR1AFvYdwHhfLlaG7N qjHqYwEPLcnHbfn4nMjf2FAuhOAZn2EeLFgcu8ib0EKCDH/NO7n7vyO3PhvhONoIDbJ0 OtM02asLOFrf4q+ItkW7+wjhrXTe4vhctvVI2WgAj1HSF4uP/86s4GZpWstQUjNHUgRM OsUw== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr5535373yha.163.1415909587958; Thu, 13 Nov 2014 12:13:07 -0800 (PST) Received: by 10.170.195.203 with HTTP; Thu, 13 Nov 2014 12:13:07 -0800 (PST) Received: by 10.170.195.203 with HTTP; Thu, 13 Nov 2014 12:13:07 -0800 (PST) In-Reply-To: <20141113200037.455711AFCB@ld9781.wdf.sap.corp> References: <20141113200037.455711AFCB@ld9781.wdf.sap.corp> Date: Thu, 13 Nov 2014 12:13:07 -0800 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: multipart/alternative; boundary=089e01634d34063fc30507c324d8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J88r3kRr24bttAh0Fx1IPRo0Cvk Cc: tls@ietf.org Subject: Re: [TLS] PRs for this morning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:13:20 -0000 --089e01634d34063fc30507c324d8 Content-Type: text/plain; charset=UTF-8 On Nov 13, 2014 12:01 PM, "Martin Rex" wrote: > > Eric Rescorla wrote: > > > > Merging session resumption and tickets and moving ticket > > establishment to a update: > > https://github.com/tlswg/tls13-spec/pull/96 > > > In case that you intend to add rfc5077 TLS session ticket support > to TLSv1.3, is that using the same bogus CBC-Encryption > (i.e. mac+pad+encrypt instead of pad+mac+encrypt) that Vaudenay > described as a security issue, that was never fixed in TLS up to v1.2 > and provided the grounds for LuckyThirteen and Poodle? Ticket encryption is not interop problem. This should be noted for implementors, but strictly speaking isn't in the protocol. > > If yes, then how about fixing a known design flaw _before_ > it is demonstrated to be exploitable? > Agreed. But do it EtM so it's obviously secure, no matter what encryption is used. > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --089e01634d34063fc30507c324d8 Content-Type: text/html; charset=UTF-8


On Nov 13, 2014 12:01 PM, "Martin Rex" <mrex@sap.com> wrote:
>
> Eric Rescorla wrote:
> >
> > Merging session resumption and tickets and moving ticket
> > establishment to a update:
> > https://github.com/tlswg/tls13-spec/pull/96
>
>
> In case that you intend to add rfc5077 TLS session ticket support
> to TLSv1.3, is that using the same bogus CBC-Encryption
> (i.e. mac+pad+encrypt instead of pad+mac+encrypt) that Vaudenay
> described as a security issue, that was never fixed in TLS up to v1.2
> and provided the grounds for LuckyThirteen and Poodle?

Ticket encryption is not interop problem. This should be noted for implementors, but strictly speaking isn't in the protocol.

>
> If yes, then how about fixing a known design flaw _before_
> it is demonstrated to be exploitable?
>

Agreed. But do it EtM so it's obviously secure, no matter what encryption is used.

>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--089e01634d34063fc30507c324d8-- From nobody Thu Nov 13 12:20:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEBC1AD02C for ; Thu, 13 Nov 2014 12:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebztAMaqY82m for ; Thu, 13 Nov 2014 12:20:22 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06931AD01F for ; Thu, 13 Nov 2014 12:19:27 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0MdLIx-1XXkxa2Qj5-00IUR6; Thu, 13 Nov 2014 21:19:25 +0100 Received: by mail-ob0-f177.google.com with SMTP id m8so11147467obr.36 for ; Thu, 13 Nov 2014 12:19:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.197.199 with SMTP id v190mr3633186oif.2.1415909964469; Thu, 13 Nov 2014 12:19:24 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 13 Nov 2014 12:19:24 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Nov 2014 21:19:24 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11352dfc775df30507c33a25 X-Provags-ID: V02:K0:qD2HMMIxcaXy56ORHGIMcHBwuFdR99u9awA1+Aw2rZt 5vUpvv5jVlwBsNvds0Qi0/L5y6v4Tt0rEKzoZG6fDfi5u15MRg n7s0WDYAuyG8KOaIqmBoqWBQTZFX/MZIWZLtbJdBB8aqEs0nyc QQtOJXYVGrdpStcMb/S9L1jOEScVeaHfafhACuWK+MgiiK0WwA jn2LB5O0HxvMeR5lnN2UYkZkrNK7e56oPsiS1pZrfErkS/XJJx P5amjLgH7eTeRAraWrpMqOy35Un25dtzkq8nDvp7UBMkJgf0TO dQeZl9H4WMKPseYwOLeHr751IwahibBgeuqmf66KzlfNnY/n/d isxXtPrufQVYEdB/RFpAUJHkknPgiFSS+Jp+/Qy2QAtKebm5Br 7xhIroPTYiQRaXPTOfQ7+YdWS0sqlmmDIoHSjW6PHHz5nLqdgm kZ/Rt X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nKJMIK7FRP1_hJeQxGcLUu-SweM Subject: Re: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:20:24 -0000 --001a11352dfc775df30507c33a25 Content-Type: text/plain; charset=UTF-8 Martin Thomson : The draft says that, for servers: > > If a compatible TLS server receives a Supported Groups extension from > a client that includes any FFDHE group (i.e. any codepoint between > 256 and 511 inclusive, even if unknown to the server), and if none of > the client-proposed FFDHE groups are known and acceptable to the > server, then the server SHOULD NOT select an FFDHE ciphersuite. > > I think that this needs to be a MUST. If the client is willing to > take the servers choice of group, then it would not be including the > fixed groups. > > NEW: > The compatible client that wants to be able to negotiate strong FFDHE > sends a "Supported Groups" extension > Rationale: > This is purely axiomatic. > NEW: > A client that offers a NamedCurve extension containing a FFDHE group > cannot use > Rationale: > No need for normative language here, this is purely a (relevant) > observation. And "SHOULD ALSO" doesn't appear in RFC 2119 ;) > All these suggestions look right to me. If we really wanted to allow explicitly specified ("PYOG") FFDHE groups as a fallback, we should create the equivalent of RFC 4492's arbitrary_explicit_prime_curves NamedCurve. (We don't actually want that, I hope.) Bodo --001a11352dfc775df30507c33a25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com>:

The draft says that, for servers:

=C2=A0 =C2=A0If a compatible TLS server receives a Supported Groups extensi= on from
=C2=A0 =C2=A0a client that includes any FFDHE group (i.e. any codepoint bet= ween
=C2=A0 =C2=A0256 and 511 inclusive, even if unknown to the server), and if = none of
=C2=A0 =C2=A0the client-proposed FFDHE groups are known and acceptable to t= he
=C2=A0 =C2=A0server, then the server SHOULD NOT select an FFDHE ciphersuite= .

I think that this needs to be a MUST.=C2=A0 If the client is willing to
take the servers choice of group, then it would not be including the
fixed groups.
=C2=A0
NEW:
=C2=A0 =C2=A0The compatible client that wants to be able to negotiate stron= g FFDHE
=C2=A0 =C2=A0sends a "Supported Groups" extension
Rationale:
=C2=A0 =C2=A0This is purely axiomatic.
=C2=A0
NEW:
=C2=A0 =C2=A0A client that offers a NamedCurve extension containing a FFDHE= group
=C2=A0 =C2=A0cannot use
Rationale:
=C2=A0 =C2=A0No need for normative language here, this is purely a (relevan= t)
observation.=C2=A0 And "SHOULD ALSO" doesn't appear in RFC 21= 19 ;)

All these suggestions look right = to me.

If we really wanted to allow explicitly spe= cified ("PYOG") FFDHE groups as a fallback, we should create the = equivalent of RFC 4492's arbitrary_explicit_prime_curves=C2=A0NamedCurv= e. (We don't actually want that, I hope.)

= Bodo

--001a11352dfc775df30507c33a25-- From nobody Thu Nov 13 12:22:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5648D1ACF8D for ; Thu, 13 Nov 2014 12:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_hSndjiLzQ0 for ; Thu, 13 Nov 2014 12:21:59 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A700F1AD004 for ; Thu, 13 Nov 2014 12:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=ZDVeYLxv2lVBYhoYmZ66+fYmny1gK0cUBRbFTLIcpD4=; b=UoqmGpqo684e5ZpaJSOUsfPMBs5/aeTcrpNgwKbk/vlAAQ01b2SY+ny2wXuwxayPM0o1hq7OFXU+3nFBohLXoHlehAPb667WlYkgxESxl16wQjg4pj6tPugGz9gz5P1biaSgLAsseQZdwrZ3ZPdFJ20J0ptBJHd6EWsC9/yt8vc=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xp0sw-00008i-Ar; Thu, 13 Nov 2014 21:20:54 +0100 Message-ID: <546512AB.903@polarssl.org> Date: Thu, 13 Nov 2014 21:20:59 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mrex@sap.com, Eric Rescorla References: <20141113200037.455711AFCB@ld9781.wdf.sap.corp> In-Reply-To: <20141113200037.455711AFCB@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YHkxYbf3aGcJVAaXkhKcAAzFwWM Cc: "tls@ietf.org" Subject: Re: [TLS] PRs for this morning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:22:00 -0000 On 13/11/2014 21:00, Martin Rex wrote: > Eric Rescorla wrote: >> >> Merging session resumption and tickets and moving ticket >> establishment to a update: >> https://github.com/tlswg/tls13-spec/pull/96 > > > In case that you intend to add rfc5077 TLS session ticket support > to TLSv1.3, is that using the same bogus CBC-Encryption > (i.e. mac+pad+encrypt instead of pad+mac+encrypt) that Vaudenay > described as a security issue, that was never fixed in TLS up to v1.2 > and provided the grounds for LuckyThirteen and Poodle? > I'm not sure what you're talking about. To me, RFC 5077 section 4 looks like it recommends pad+encrypt+mac (aka EEM) which is secure. The actual state information in encrypted_state is encrypted using 128-bit AES in CBC mode with the given IV. The Message Authentication Code (MAC) is calculated using HMAC-SHA-256 over key_name (16 octets) and IV (16 octets), followed by the length of the encrypted_state field (2 octets) and its contents (variable length). Manuel. From nobody Thu Nov 13 12:22:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9751AD004 for ; Thu, 13 Nov 2014 12:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rKzQWxLHuer for ; Thu, 13 Nov 2014 12:22:07 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375E91ACFD4 for ; Thu, 13 Nov 2014 12:21:33 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 0F9D23A2EB; Thu, 13 Nov 2014 21:21:32 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id F1F62429D5; Thu, 13 Nov 2014 21:21:31 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EB8391AFCC; Thu, 13 Nov 2014 21:21:31 +0100 (CET) In-Reply-To: <20141113200037.455711AFCB@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Thu, 13 Nov 2014 21:21:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141113202131.EB8391AFCC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6NmTj52Y4aObFw450QZDL3CiJoM Cc: "tls@ietf.org" Subject: Re: [TLS] PRs for this morning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:22:10 -0000 Martin Rex wrote: > Eric Rescorla wrote: > > > > Merging session resumption and tickets and moving ticket > > establishment to a update: > > https://github.com/tlswg/tls13-spec/pull/96 > > > In case that you intend to add rfc5077 TLS session ticket support > to TLSv1.3, is that using the same bogus CBC-Encryption > (i.e. mac+pad+encrypt instead of pad+mac+encrypt) that Vaudenay > described as a security issue, that was never fixed in TLS up to v1.2 > and provided the grounds for LuckyThirteen and Poodle? > > If yes, then how about fixing a known design flaw _before_ > it is demonstrated to be exploitable? Although .. reading the relevant part of rfc5077 again, it's possible that rfc5077 session tickets are already using EtM, and only the PDU & description is misleading. http://tools.ietf.org/html/rfc5077#section-4 The ticket is structured as follows: struct { opaque key_name[16]; opaque iv[16]; - opaque encrypted_state<0..2^16-1>; + opaque cbc_encrypted_state<0..2^16-16>; opaque mac[32]; } ticket; The actual state information in encrypted_state is encrypted using 128-bit AES in CBC mode with the given IV. The Message Authentication Code (MAC) is calculated using HMAC-SHA-256 over key_name (16 octets) and IV (16 octets), followed by the length of the encrypted_state field (2 octets) and its contents (variable - length). + length, but integer multiple of the AES blocksize (16)). Considering that a client will have to send a ticket to the server inside a TLS extension for resumption, and that all extensions inside ClientHello combined must fit within 2^16, the true maximum size of encrypted_state is more like (2^16-128), but using (2^16-16) is more indicative about the integer multiple of AES blocksize characteristic. Sorry for the confusion. -Martin From nobody Thu Nov 13 12:30:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995161AD08F for ; Thu, 13 Nov 2014 12:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZH1GhZVv-6S for ; Thu, 13 Nov 2014 12:30:08 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974F01ACFBA for ; Thu, 13 Nov 2014 12:29:43 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id u20so10748026oif.25 for ; Thu, 13 Nov 2014 12:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ezxweLGlsj1ogZxD75OLE0QEFCd8QrLlxZCIXGFGDrw=; b=tnrLA0TcYys3xsO2HFlEti+P6/hfVqrF1q5DYqoQnuY5fqxkEu3GCHbjf7pLq1BKPd n9Q5awUCwHwTzRW0c2p0t1eLhshxnp7Anzh28Zb0efDsaTdUAMenaCu2O5XzACmFhSo+ JsN6pLmn9i+W5Si6RQdIqqAZw3k1uJvYVNLl6NQ7v2O73P+A8LlvZsjQXI5OzWmpiPfF gMRzfWei2KIASQq4xt0fay3TFWoNdTTHRo9aZTI7QGTn1J3V6g5qnUfh3KKgo4mt2PGr FpqYnMil8DQEn4x3tji35XFZwN590ooXgD4S0ceQgoOqrfpfOZFWDV0Hyi0+3u41G/LF 3JwA== MIME-Version: 1.0 X-Received: by 10.182.112.233 with SMTP id it9mr3823517obb.8.1415910582980; Thu, 13 Nov 2014 12:29:42 -0800 (PST) Received: by 10.202.197.212 with HTTP; Thu, 13 Nov 2014 12:29:42 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Nov 2014 12:29:42 -0800 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mBYlrLuvbmsJ7Fq86Nu3Kf6NmYM Cc: "tls@ietf.org" Subject: Re: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:30:16 -0000 On 13 November 2014 12:19, Bodo Moeller wrote: > If we really wanted to allow explicitly specified ("PYOG") FFDHE groups as a > fallback, we should create the equivalent of RFC 4492's > arbitrary_explicit_prime_curves NamedCurve. (We don't actually want that, I > hope.) I teased that idea in the meeting, but it's a bad idea ;) From nobody Thu Nov 13 13:36:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE85E1AD62A for ; Thu, 13 Nov 2014 13:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8aAz69D3kQz for ; Thu, 13 Nov 2014 13:36:16 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36A01AD620 for ; Thu, 13 Nov 2014 13:36:15 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id A8FDF3A33D; Thu, 13 Nov 2014 22:36:13 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9F160423E3; Thu, 13 Nov 2014 22:36:13 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9302B1AFCC; Thu, 13 Nov 2014 22:36:13 +0100 (CET) In-Reply-To: To: Bodo Moeller Date: Thu, 13 Nov 2014 22:36:13 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141113213613.9302B1AFCC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Pdla-qa2R1SsEGyP4-VCsSjuX9M Cc: "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 21:36:18 -0000 Bodo Moeller wrote: >> >> But I do _not_ think that a MUST for ClientHello.client_version >> would be appropriate for an fatal alert that is sent instead >> of ServerHello. For alerts that early in the handshake a server >> may for simplicity reuse the record layer protocol that was used >> for the in coming ClientHello. > > > God point. If the record-layer version number differs from > ClientHello.client_version, the client should really be ready to accept > both version numbers. So what about the following? > > [...] The record layer version number for this alert MUST be set to either > ClientHello.client_version (as it would for the Server Hello message if the > server was continuing the handshake), or to the record layer version number > used by the client. I thought you were looking for simplicity and ease-of-implementation. I believe you should get rid of the MUST. we're talking about the text on page 3 of your I-D, right? o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the highest protocol version supported by the server is higher than the version indicated in ClientHello.client_version, the server - MUST respond with a fatal inappropriate_fallback alert (unless it - responds with a fatal protocol_version alert because the version - indicated in ClientHello.client_version is unsupported). The - record layer versio - 2000 - n number for this alert MUST be set to either - ClientHello.client_version (as it would for the Server Hello - message if the server was continuing the handshake), or to the - record layer version number used by the client. + MUST respond with a fatal inappropriate_fallback alert. There + has not been a protocol version negotiated at this point of the + TLS handshake, so the inappropriate_fallback alert, like any + other fatal alert this early during the handshake, should use + a record layer protocol_version that the client can reasonably + be expected to understand, such as the record layer protocol_version + that carried the client's ClientHello handshake message or the + ClientHello.client_version. I have a serious problem with the text in the parentheses in your current version (from above, re-flowed): - (unless it responds with a fatal protocol_version alert because the - version indicated in ClientHello.client_version is unsupported). This text (a) is ignorant about how the SSL&TLS version negotiation is supposed to work and (b) gives a blessing to version-intolerant servers. It hurts to see such text in a proposal whose purpose is to ask servers to mitigate dangerous client behaviour. Client behaviour that was invented to compensate for the failure of TLS servers to properly negotiate SSL&TLS protocol versions in combination with server's protocol version intolerance. -Martin From nobody Thu Nov 13 14:08:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3744C1ADFAD for ; Thu, 13 Nov 2014 14:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx5zU1n29GQz for ; Thu, 13 Nov 2014 14:08:09 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504991ADFAB for ; Thu, 13 Nov 2014 14:08:08 -0800 (PST) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0MMrlb-1XupBq2zHT-008edm; Thu, 13 Nov 2014 23:08:06 +0100 Received: by mail-oi0-f47.google.com with SMTP id v63so1889926oia.34 for ; Thu, 13 Nov 2014 14:08:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.89.161 with SMTP id bp1mr4232473obb.19.1415916484464; Thu, 13 Nov 2014 14:08:04 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 13 Nov 2014 14:08:04 -0800 (PST) In-Reply-To: <20141113213613.9302B1AFCC@ld9781.wdf.sap.corp> References: <20141113213613.9302B1AFCC@ld9781.wdf.sap.corp> Date: Thu, 13 Nov 2014 23:08:04 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013d0e021697d10507c4bfb4 X-Provags-ID: V02:K0:emXAJWpH4y9Lp96Ho4eOUNNZkQziLMrQdxnt4NA/uDp LGMnsQDv0vzWS1gedZEIf9cnMv1XcRQxesr5ho28kjhkFJZ0Au bf0WTIZ3gaOjD8zbueHB6fbXmCtQbxqAu0Ouceetcj7Wyoq/j0 6dpZfRy4VMiTxZ/KdG/Ufu6eTm+zJ9zVWjrpsDJEUBCFsi4M3F tms61dqTk9mBnUoii6tXB1fiRo91Z/BRVj0Bx8IjfHm7dC3pT5 g2jlyPg5FFnC+b+XqaH202gXkwaUTQ69hbPMAGZMwvMOGJVcQd rjsXa9Gm88J557tGCy4H6uKDH48U8LebLmiI6C4Bip7WMl+Pjz 251A6GKpsNpJLqFWDxO3KIqGAG8CFepjantDwwLM4nIo/RUQET OoBPyymWsBfL9oRiu+Z1yC3GXcD51MdjzFstgsihied/jhO2DS n2SlO X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tjebArhuuULYJqS1plIi-kYKOxE Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 22:08:13 -0000 --089e013d0e021697d10507c4bfb4 Content-Type: text/plain; charset=UTF-8 Martin Rex : I believe you should get rid of the MUST. > > - [...] The > - record layer version number for this alert MUST be set to either > - ClientHello.client_version (as it would for the Server Hello > - message if the server was continuing the handshake), or to the > - record layer version number used by the client. > + [...] There > + has not been a protocol version negotiated at this point of the > + TLS handshake, so the inappropriate_fallback alert, like any > + other fatal alert this early during the handshake, should use > + a record layer protocol_version that the client can reasonably > + be expected to understand, such as the record layer protocol_version > + that carried the client's ClientHello handshake message or the > + ClientHello.client_version. > Hm. What else would the client "reasonably be expected to understand"? Your proposed wording sounds very vague. I have a serious problem with the text in the parentheses in your current > version (from above, re-flowed): > > - (unless it responds with a fatal protocol_version alert because the > - version indicated in ClientHello.client_version is unsupported). > > This text (a) is ignorant about how the SSL&TLS version negotiation is > supposed to work and (b) gives a blessing to version-intolerant servers. > Well, actually I ended up with that text because I copied from the TLS RFCs -- see the definition of the protocol_version alert: "The protocol version the client has attempted to negotiate is recognized, but not supported. (For example, old protocol versions might be avoided for security reasons). This message is always fatal." The above wording is *not* meant to encourage servers to send a protocol_version alert if client_version is too high (new), which I think is what you got from it. It merely recognizes that servers may be sending a protocol_version alert if client_version is too low (old). I hadn't thought of the other interpretation -- the intention here was simply to be clear that previous current protocol_version behavior is still allowed, and not overridden by a requirement to always send inappropriate_fallback. If you read it in its actual context ("If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the highest protocol version supported by the server is higher than the version indicated in ClientHello.client_version, ..."), I think that's entirely clear in draft-ietf-tls-downgrade-scsv-02: if the highest protocol version supported by the client is higher than ClientHello.client_version and ClientHello.client_version is unsupported by the server, then clearly client_version is too old. That has nothing to do with version-intolerance. Bodo --089e013d0e021697d10507c4bfb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:

I believe you should get rid of the MUST.

- =C2=A0 =C2=A0 [...] =C2=A0The
- =C2=A0 =C2=A0 record layer version number for this alert MUST be s= et to either
-=C2=A0 =C2=A0 =C2=A0 ClientHello.client_version (as it wo= uld for the Server Hello
-=C2=A0 =C2=A0 =C2=A0 message if the server was continuing the handshake), = or to the
-=C2=A0 =C2=A0 =C2=A0 record layer version number used by the client.
+=C2=A0 =C2=A0 =C2=A0[...] =C2=A0There
+=C2=A0 =C2=A0 =C2=A0has not been a protocol version negotiated at this poi= nt of the
+=C2=A0 =C2=A0 =C2=A0TLS handshake, so the inappropriate_fallback alert, li= ke any
+=C2=A0 =C2=A0 =C2=A0other fatal alert this early during the handshake, sho= uld use
+=C2=A0 =C2=A0 =C2=A0a record layer protocol_version that the client can re= asonably
+=C2=A0 =C2=A0 =C2=A0be expected to understand, such as the record layer pr= otocol_version
+=C2=A0 =C2=A0 =C2=A0that carried the client's ClientHello handshake me= ssage or the
+=C2=A0 =C2=A0 =C2=A0ClientHello.client_version.

<= /div>
Hm. What else would the client "reasonably be expected to un= derstand"? Your proposed wording sounds very vague.


I have a serious problem with the text in the parentheses in your current version (from above, re-flowed):

-=C2=A0 =C2=A0 =C2=A0(unless it responds with a fatal protocol_version aler= t because the
-=C2=A0 =C2=A0 =C2=A0 version indicated in ClientHello.client_version is un= supported).

This text (a) is ignorant about how the SSL&TLS version negotiat= ion is
supposed to work and (b) gives a blessing to version-intolerant servers.

Well, actually I ended up with that text = because I copied from the TLS RFCs -- see the definition of the protocol_ve= rsion alert:

"The protocol version the client has attempted= to negotiate is recognized, but not supported. (For example, old protocol = versions might be avoided for security reasons). This message is always fat= al."

The above wording is *not* meant to = encourage servers to send a protocol_version alert if client_version is too= high (new), which I think is what you got from it. It merely recognizes th= at servers may be sending a protocol_version alert if client_version is too= low (old). I hadn't thought of the other interpretation -- the intenti= on here was simply to be clear that previous current protocol_version behav= ior is still allowed, and not overridden by a requirement to always send in= appropriate_fallback.

If you read it in its actual= context ("If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites a= nd the highest protocol version supported by the server is higher than the = version indicated in ClientHello.client_version, ..."), I think that&#= 39;s entirely clear in draft-ietf-tls-downgrade-scsv-02: if the highest pro= tocol version supported by the client is higher than ClientHello.client_ver= sion and ClientHello.client_version is unsupported by the server, then clea= rly client_version is too old. That has nothing to do with version-intolera= nce.

Bodo

--089e013d0e021697d10507c4bfb4-- From nobody Thu Nov 13 15:20:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2C1AE257 for ; Thu, 13 Nov 2014 15:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnjtvizKhtTH for ; Thu, 13 Nov 2014 15:20:07 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDBD1AE2B2 for ; Thu, 13 Nov 2014 15:19:56 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id D6EE33A2F7; Fri, 14 Nov 2014 00:19:54 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id CE508429CB; Fri, 14 Nov 2014 00:19:54 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C65861AFCC; Fri, 14 Nov 2014 00:19:54 +0100 (CET) In-Reply-To: To: Bodo Moeller Date: Fri, 14 Nov 2014 00:19:54 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rTCHpJ50mKC-4oVskW_0nabh1uQ Cc: "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:20:16 -0000 Bodo Moeller wrote: > Martin Rex : > > I believe you should get rid of the MUST. >> >> - [...] The >> - record layer version number for this alert MUST be set to either >> - ClientHello.client_version (as it would for the Server Hello >> - message if the server was continuing the handshake), or to the >> - record layer version number used by the client. >> + [...] There >> + has not been a protocol version negotiated at this point of the >> + TLS handshake, so the inappropriate_fallback alert, like any >> + other fatal alert this early during the handshake, should use >> + a record layer protocol_version that the client can reasonably >> + be expected to understand, such as the record layer protocol_version >> + that carried the client's ClientHello handshake message or the >> + ClientHello.client_version. > > Hm. What else would the client "reasonably be expected to understand"? Your > proposed wording sounds very vague. It is vague on purpose, because it is supposed to be non-normative. Why would you want to inconvenience existing implementations (where the record level protocol version for an alert might get determined at the record protocol layer, and _not_ in function (as function parameter) that triggers the alert response, such as: ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_INAPPROPRIATE_FALLBACK); > > I have a serious problem with the text in the parentheses in your current > > version (from above, re-flowed): > > > > - (unless it responds with a fatal protocol_version alert because the > > - version indicated in ClientHello.client_version is unsupported). > > > > This text (a) is ignorant about how the SSL&TLS version negotiation is > > supposed to work and (b) gives a blessing to version-intolerant servers. > > > > Well, actually I ended up with that text because I copied from the TLS RFCs > -- see the definition of the protocol_version alert: > > "The protocol version the client has attempted to negotiate is recognized, > but not supported. (For example, old protocol versions might be avoided for > security reasons). This message is always fatal." Which looks very much like an bug in the TLS RFCs. No, we don't need to be bug-for-bug compatible. > > > The above wording is *not* meant to encourage servers to send a > protocol_version alert if client_version is too high (new), which I think > is what you got from it. Non-obvious intentions of the author do not matter here. The wording clearly suggests that it would be OK for servers for too high as well. Consider the following scenario: - server that has TLSv1.0 and SSLv3 disabled (Win2012 ADFS?) - middlebox in the path that kills TLSv1.2 connections - Client that starts with record.pv={3,3}+ClientHello.client_version={3,3} observes a connection closure (caused by the middlebox) and retries with record.pv={3,1}+ClientHello.client_version={3,1}+FB_SCSV (MSIE 8 on Win7 with TLSv1.0+TLSv1.1+TLSv1.2 enabled) I can see three possible server responses, and which one do you think would be best in helping the client to decide how to continue (and why): (1) server sees the FB_SCSV and responds with fatal invalid_fallback alert (2) server sees ClientHello.client_version={3,1} and responds with fatal protocol_version alert (3) server continues handshake with ServerHello.server_version={3,2} -Martin From nobody Thu Nov 13 21:38:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8228E1A6EE4 for ; Thu, 13 Nov 2014 21:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BocFF29_lXM for ; Thu, 13 Nov 2014 21:38:15 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474161A1B6E for ; Thu, 13 Nov 2014 21:38:15 -0800 (PST) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0MVZ1v-1XUcZe07QN-00Z31g; Fri, 14 Nov 2014 06:38:13 +0100 Received: by mail-oi0-f47.google.com with SMTP id v63so2327400oia.34 for ; Thu, 13 Nov 2014 21:38:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.227.73 with SMTP id a70mr5560100oih.59.1415943487738; Thu, 13 Nov 2014 21:38:07 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 13 Nov 2014 21:38:07 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 13 Nov 2014 21:38:07 -0800 (PST) In-Reply-To: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> References: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> Date: Fri, 14 Nov 2014 06:38:07 +0100 Message-ID: From: Bodo Moeller To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a114093d29bdb1d0507cb08fb X-Provags-ID: V02:K0:jRXDUwGE0M4VzikgWt8PkJyWsdXQJmbNI7IoWpgTZhE UGXQo6IHN46FeqyluqLL1sTDlFVNMe7v7/4niOKJ1tIujXR8l7 Ybkoq8Ke4lMRm5n8VpCYK6nU76bRDGieojzpwV3WZrrAF7Fea8 Gg4Ruq2wqglmsTQU0T+lMHiMqM93+Qi2Qaix/lBtvnW+2y2plD 1dfmasx26YKuLW49PkIf08IaP92pHRMl3wAd6bxQD/W5JNjdR2 EdsqDAY135ydETIlEGfysNshMCo3ZWfSz4et9vnx/oEP5sCtl5 yxX7cXsneyLMgKQBKFOx2+A0KjGExXrk5ZzWrPvjdjuAVhZlpz BWz4NQQOJcUchLSe8ngGvl30n5WPvgOYoc4UNpdyQGoPHkkQZ7 Go92o+FKF+pZhbt2EOF/yJqE+WNs+s/6nlGhS2C06QRJalCZYr lJDtR X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o3UN-L1CSnAP0tULLe4GwQTWN5w Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 05:38:16 -0000 --001a114093d29bdb1d0507cb08fb Content-Type: text/plain; charset=UTF-8 > > The above wording is *not* meant to encourage servers to send a > > protocol_version alert if client_version is too high (new), which I think > > is what you got from it. > The wording clearly suggests that it would be OK for servers for too high > as well. As I subsequently explained, it doesn't if you don't take it out of context. The context is that the version is low. That wording in the TLS RFCs indeed appears to encourage version-intolerant behavior and should be fixed. However, for this I-D, I'm not worried. --001a114093d29bdb1d0507cb08fb Content-Type: text/html; charset=UTF-8

> > The above wording is *not* meant to encourage servers to send a
> > protocol_version alert if client_version is too high (new), which I think
> > is what you got from it.

> The wording clearly suggests that it would be OK for servers for too high
> as well.

As I subsequently explained, it doesn't if you don't take it out of context. The context is that the version is low.

That wording in the TLS RFCs indeed appears to encourage version-intolerant behavior and should be fixed. However, for this I-D, I'm not worried.

--001a114093d29bdb1d0507cb08fb-- From nobody Thu Nov 13 22:14:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E715F1A7026 for ; Thu, 13 Nov 2014 22:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d797G5ygQTXt for ; Thu, 13 Nov 2014 22:13:56 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A35E1A6FD0 for ; Thu, 13 Nov 2014 22:13:52 -0800 (PST) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0M9cAV-1XhlDt2xot-00D1dx; Fri, 14 Nov 2014 07:13:51 +0100 Received: by mail-oi0-f49.google.com with SMTP id u20so11474715oif.36 for ; Thu, 13 Nov 2014 22:13:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.163.33 with SMTP id yf1mr2450406obb.0.1415945629629; Thu, 13 Nov 2014 22:13:49 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 13 Nov 2014 22:13:49 -0800 (PST) In-Reply-To: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> References: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> Date: Fri, 14 Nov 2014 07:13:49 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f6427284685c60507cb88a4 X-Provags-ID: V02:K0:wnJ/SWkTM3T1Ej37Ta5BgpqWDWUMzQI3+MwY9C9UEXT E7ZnBo/sntTZEJTvfPqj7jf0TS5tpGZZt+jJLsk9t9tdwQaR4q 67n+tagluoxEue/tmdbiLcJjmVPDoQDFfOZKs/+0xfanYcnCbe ac52nTERoVXmPuxZvX+PByAmJvXsD2QT05K7oJmhfMyMpU8YSl WV6XpV0F1oqXNOuKBs87KOBak9UA+lPzhjgfSw5qSyJcNgCta+ V9lPhkd0E/ZyQDA4Qb9/1cSD0IIZBE27vtiZkar7bnZcxptFZm noE3ktFMB85yRLiwreDpd6md5uiYJa05nNqep2KS223nj6Ya3d sHmB/OXyR+b1Cfm775TB4+S8VNffL+6wO+i/SiIAW4jVxfkud8 iNawFNpEOJ3MgCBlWFSfEqBe7Y8f/bdMoZDO49lQFXTSUOME0X +jrPM X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XqmIP72Olesh9RudwKoDu4XVwJo Cc: Florian Weimer Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 06:14:08 -0000 --e89a8f6427284685c60507cb88a4 Content-Type: text/plain; charset=UTF-8 Martin Rex : >> + [...] the inappropriate_fallback alert, like any > >> + other fatal alert this early during the handshake, should use > >> + a record layer protocol_version that the client can reasonably > >> + be expected to understand, [...] > > [...] Your proposed wording sounds very vague. > > It is vague on purpose, because it is supposed to be non-normative. > Why would you want to inconvenience existing implementations > (where the record level protocol version for an alert might get determined > at the record protocol layer, and _not_ in function (as function parameter) > that triggers the alert response, such as: > > ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_INAPPROPRIATE_FALLBACK); > In that case, I think we should be saying nothing in the server behavior section at all (after all, alerts sent by the client in response to the Client Hello aren't new). Rather, the client server behavior section should point out that clients that want to detect the inappropriate_fallback alert must be prepared to see any record-layer protocol version. Florian, I'd put in explicit guidance on the record-layer protocol version to use with the inappropriate_fallback alert at your request. What do you think about explicitly asking the client to tolerate any version (as the TLS RFC does for the Client Hello record version) vs. explicitly telling the server what to use? Bodo --e89a8f6427284685c60507cb88a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:

>> +=C2=A0 =C2=A0 =C2=A0[...] the inappropriate_fallback alert, like = any
>> +=C2=A0 =C2=A0 =C2=A0other fatal alert this early during the hands= hake, should use
>> +=C2=A0 =C2=A0 =C2=A0a record layer protocol_version that the clie= nt can reasonably
>> +=C2=A0 =C2=A0 =C2=A0be expected to understand, [...]

> [...] Your=C2=A0proposed wording sounds very vague.
=C2=A0
It is vague on purpose, because it is supposed to be non-normative.<= br> Why would you want to inconvenience existing implementations
(where the record level protocol version for an alert might get determined<= br> at the record protocol layer, and _not_ in function (as function parameter)=
that triggers the alert response, such as:

=C2=A0 =C2=A0ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_INAPPROPRIATE_FALLBACK)= ;

In that case, I think we should be sa= ying nothing in the server behavior section at all (after all, alerts sent = by the client in response to the Client Hello aren't new). Rather, the = client server behavior section should point out that clients that want to d= etect the inappropriate_fallback alert must be prepared to see any record-l= ayer protocol version.

Florian, I'd put in exp= licit guidance on the record-layer protocol version to use with the=C2=A0in= appropriate_fallback alert at your request. What do you think about explici= tly asking the client to tolerate any version (as the TLS RFC does for the = Client Hello record version) vs. explicitly telling the server what to use?=

Bodo


--e89a8f6427284685c60507cb88a4-- From nobody Thu Nov 13 22:23:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7679C1A6F15 for ; Thu, 13 Nov 2014 22:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfoQqjZiG7a8 for ; Thu, 13 Nov 2014 22:23:42 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EFC1A0144 for ; Thu, 13 Nov 2014 22:23:41 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAE6NddA013293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 14 Nov 2014 01:23:39 -0500 Received: from oldenburg.str.redhat.com (ovpn-116-20.ams2.redhat.com [10.36.116.20]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAE6NZV4012088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 14 Nov 2014 01:23:38 -0500 Message-ID: <54659FE6.2060300@redhat.com> Date: Fri, 14 Nov 2014 07:23:34 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XsBckzH58T2m3SpZZVBdLEXOA34 Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 06:23:44 -0000 On 11/14/2014 07:13 AM, Bodo Moeller wrote: > Florian, I'd put in explicit guidance on the record-layer protocol > version to use with the inappropriate_fallback alert at your request. > What do you think about explicitly asking the client to tolerate any > version (as the TLS RFC does for the Client Hello record version) vs. > explicitly telling the server what to use? I think this would be rather misleading because at least OpenSSL is not version-tolerant here, in the sense that the application will see a different error, and not one that reflects the inappropriate_fallback alert, if there is an unexpected version number in the alert message. -- Florian Weimer / Red Hat Product Security From nobody Fri Nov 14 00:13:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31D1A870E for ; Fri, 14 Nov 2014 00:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcVJuaYHLvru for ; Fri, 14 Nov 2014 00:12:56 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480091A0083 for ; Fri, 14 Nov 2014 00:12:56 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0MS2iA-1XRZYF2xZK-00TB4m; Fri, 14 Nov 2014 09:12:54 +0100 Received: by mail-ob0-f169.google.com with SMTP id va2so12223377obc.28 for ; Fri, 14 Nov 2014 00:12:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.102.1 with SMTP id fk1mr1200546oeb.44.1415952772647; Fri, 14 Nov 2014 00:12:52 -0800 (PST) Received: by 10.60.32.42 with HTTP; Fri, 14 Nov 2014 00:12:52 -0800 (PST) In-Reply-To: <54659FE6.2060300@redhat.com> References: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> <54659FE6.2060300@redhat.com> Date: Fri, 14 Nov 2014 09:12:52 +0100 Message-ID: From: Bodo Moeller To: Florian Weimer , Joseph Salowey , Sean Turner Content-Type: multipart/alternative; boundary=089e0111b8440853880507cd32eb X-Provags-ID: V02:K0:9Ik27HiV9GkobS10JymTjgzbJiDM/yo5WhWUfNlDi61 u2r3Xk+N1NW5hhzYXk0S/5yLrXOpx+iNzMTI+aN/gGFoLGBMxm j1klnzW3txf8GZ5issQOd+s8PiT3CclC0mThwFGLT4Q/kajCwC JB5+aAFkZpLIhFJnSidV5uXJrPHcLnhHjHZiDTnn+g7BQV78F1 yS32QPUzVSEKrsIeUqmvs1d0h3OT8eJUkKoyJ2yvTqkciFOJTO uFeGnK8Dhr6OPhXIPRBFZctJf9cRujq7gabOGnhOeStNSPmhGX 8RAc9vB/hIk5iT1YYPRegPI2Vz8Ok/VNP6jMMgINZPlFlHYP4r i5PT3uZlKy9AZkQmaocbdyShxkPMPTLTi69+I2tD5ZKOblXJDK HlhrMDhMUOwFARrM3UDvU5aMt5PkQ4vuW+0HrxAe3/5whrWC1+ ZUWYO X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C6j6mTLQQJ-f_n4Hj5k5gQZ07PI Cc: "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 08:12:58 -0000 --089e0111b8440853880507cd32eb Content-Type: text/plain; charset=UTF-8 Florian Weimer : What do you think about explicitly asking the client to tolerate any >> version (as the TLS RFC does for the Client Hello record version) vs. >> explicitly telling the server what to use? > > > I think [the former] would be rather misleading because at least OpenSSL > is not version-tolerant here, in the sense that the application will see a > different error, and not one that reflects the inappropriate_fallback > alert, if there is an unexpected version number in the alert message. Thanks for your comment. Right, I just wouldn't want to use OpenSSL behavior that might not be ideal as an excuse to be unreasonably strict in the spec. But then I think that stating explicit requirements for the server as draft-ietf-tls-downgrade-scsv-02 does ("The record layer version number for this alert MUST be set to ...") is not unreasonable in this case: the main point of this alert is to provide an explicit signal from the server back to the client *if* the server would normally be willing to negotiate that protocol version. We're not requiring the server to use a record-layer protocol version that it doesn't support at all. Server implementations can first determine the protocol version to use, and *then* look for the SCSV to check if they should proceed with the handshake: even if the handshake will be aborted, they'll have the protocol version before they send the alert. So I believe that draft-ietf-tls-downgrade-scsv-02 addresses all comments (cf. slide 5 in http://www.ietf.org/proceedings/91/slides/slides-91-tls-0.pdf). Joe, Sean, can we proceed? Bodo --089e0111b8440853880507cd32eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Flor= ian Weimer <fweimer@redhat.com>:

What do you think about explicitly asking the client to tolerate any
version (as the TLS RFC does for the Client Hello record version) vs.
explicitly telling the server what to use?
= =C2=A0
I think [the former] would be rather misleading because at least OpenSSL is= not version-tolerant here, in the sense that the application will see a di= fferent error, and not one that reflects the inappropriate_fallback alert, = if there is an unexpected version number in the alert message.
=

Thanks for your comment.

Right= , I just wouldn't want to use OpenSSL behavior that might not be ideal = as an excuse to be unreasonably strict in the spec.

But then I think that stating explicit requirements for the server as dra= ft-ietf-tls-downgrade-scsv-02 does ("The record layer version number f= or this alert MUST be set to ...") is not unreasonable in this case: t= he main point of this alert is to provide an explicit signal from the serve= r back to the client *if* the server would normally be willing to negotiate= that protocol version. We're not requiring the server to use a record-= layer protocol version that it doesn't support at all. Server implement= ations can first determine the protocol version to use, and *then* look for= the SCSV to check if they should proceed with the handshake: even if the h= andshake will be aborted, they'll have the protocol version before they= send the alert.


So I believe that = draft-ietf-tls-downgrade-scsv-02 addresses all comments (cf. slide 5 in=C2= =A0http://www.ietf.org/proceedings/91/slides/slides-91-tls-0.pdf). Joe, = Sean, can we proceed?

Bodo

--089e0111b8440853880507cd32eb-- From nobody Fri Nov 14 04:07:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E672D1A000A for ; Fri, 14 Nov 2014 04:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd3s7pWMQx3d for ; Fri, 14 Nov 2014 04:07:27 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85481A0013 for ; Fri, 14 Nov 2014 04:07:26 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAEC7JOQ018110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 14 Nov 2014 07:07:19 -0500 Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAEC7HCN024337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 14 Nov 2014 07:07:18 -0500 Message-ID: <5465F075.1000306@redhat.com> Date: Fri, 14 Nov 2014 13:07:17 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bodo Moeller , Joseph Salowey , Sean Turner References: <20141113231954.C65861AFCC@ld9781.wdf.sap.corp> <54659FE6.2060300@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k3UKkanWO6v0uITgvilleRu2vpE Cc: "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 12:07:30 -0000 On 11/14/2014 09:12 AM, Bodo Moeller wrote: > Right, I just wouldn't want to use OpenSSL behavior that might not be > ideal as an excuse to be unreasonably strict in the spec. You are finalizing the specification after the implementation. I don't think there is value in *not* documenting existing interoperability requirements. > Server > implementations can first determine the protocol version to use, and > *then* look for the SCSV to check if they should proceed with the > handshake: even if the handshake will be aborted, they'll have the > protocol version before they send the alert. Agreed. -- Florian Weimer / Red Hat Product Security From nobody Fri Nov 14 09:11:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A3A1A1AFA for ; Fri, 14 Nov 2014 09:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1csr3X2hCjKz for ; Fri, 14 Nov 2014 09:11:40 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632401A1B06 for ; Fri, 14 Nov 2014 09:11:15 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 20F903A42F; Fri, 14 Nov 2014 18:11:13 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 1192242CB0; Fri, 14 Nov 2014 18:11:13 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 072DC1AFD0; Fri, 14 Nov 2014 18:11:13 +0100 (CET) In-Reply-To: <5465F075.1000306@redhat.com> To: Florian Weimer Date: Fri, 14 Nov 2014 18:11:13 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141114171113.072DC1AFD0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SyDhOqlz5XGlZFhkCTMeGL1iWBI Cc: "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:11:52 -0000 Florian Weimer wrote: > Bodo Moeller wrote: >> >> Right, I just wouldn't want to use OpenSSL behavior that might not be >> ideal as an excuse to be unreasonably strict in the spec. > > You are finalizing the specification after the implementation. I don't > think there is value in *not* documenting existing interoperability > requirements. > >> Server >> implementations can first determine the protocol version to use, and >> *then* look for the SCSV to check if they should proceed with the >> handshake: even if the handshake will be aborted, they'll have the >> protocol version before they send the alert. > > Agreed. This is ignoring the actual problem and passing the buck to implementors. Keep in mind that there is the general IETF rule "Be liberal in what you accept, be conservative in what you send", and we know that there are several "scanners" / "probers" out there, not just broken TLS implementations, and any kind of guidance should cover-it-all, rather than leaving undefined behaviour. The SSL alert response of the server should avoid using a protocol version at the record layer which (a) the server potentially does not even implement and (b) which the peer can not reasonably be expected to understand. (a) may often rule out ClientHello.client_version, not just for TLS probers / scanners, but also early adopter clients (like bleeding edge web browsers) talking to installed base servers (b) makes the record_version that the client used at the record layer for the record carrying the ClientHello a reasonably safe bet. but there still is the possibility that a scanner/prober or defective client uses a protocol version at the record layer that the server doesn't implement (or which doesn't even exist, mind you that TLSv1.2 requires servers to accept {0x03, 0xXX} at the record layer for the initial ClientHello), and depending on the design of the existing server code, the record layer may not want to use an invalid or unknown protocol value at all, and rather fallback to a truely safe bet (which I think would be {0x03, 0x00}, inspite of the specific alert this document is newly defining isn't described in the SSLv3 spec. (because the latter argument applies to *ALL* existing protocols, SSLv3 through TLSv1.2 and is therefore not applicable). Personally, I would use the record version of the record which carried the initial ClientHello, because independent of what it is, if the client used it for ClientHello, it must be OK to use for the response in the sense of "best effort". {0x03, 0x00} while being a theoretical and fully spec-compliant "safe bet" that no reasonable TLS implementation ought to choke on, may cause choking in less reasonable implementations that started with {0x03, 0x01} or above. -Martin From nobody Fri Nov 14 09:27:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAD1A00C2 for ; Fri, 14 Nov 2014 09:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlfDOwv5nroG for ; Fri, 14 Nov 2014 09:27:43 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F00E1A1B1D for ; Fri, 14 Nov 2014 09:27:30 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id i13so11740935qae.22 for ; Fri, 14 Nov 2014 09:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=7yFc5GXcqvEVg5cPUPVBv8/IwxiKc5eUYH9FFqBQZCI=; b=o4tn5stmCvvKEgyjswBZq7YTKbdXOshgvxmLU4xu/buYwyozQTIC/qThRw5idRPode t49M13UPXTwKMdZKFps4VRUoD99nzfB6N9Xz2oMkWsXqwtXxzhsREAtOZPRujdJT7+OF i+wvuFmucNAwb09DtZv5dsbBX2h2lsjY2RdfvSJj4fJW+6zfQYMNthhUt25xqNrqauEq Pr5sE7x81cEJUEJ+Sj3cEsxJevu93FjKNa4CBEBeTFAby+KhcG11EXth+IVz4lgHh+wj rq9zH0YrVE/xLncVmxjeqMTOjAYzXv+4iUZB/+ln7A3NT1Z1YE/WDFu9/9vkS7zfTQvh R4Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-type; bh=7yFc5GXcqvEVg5cPUPVBv8/IwxiKc5eUYH9FFqBQZCI=; b=dyN2Hd5C26nzgsKcIEJr3CTgHgYCGMgzIP/iT16RDJinoc+rbyxarisPVmu0JzDYYw 17P6xcebh4vFJ5Why+MTP3UoeET7VKzBuKDE+Z8SSZKwt7Sm+lVEcQ1sSrTy0+HC/L+e gCZKDe7Oxak7diiQMpmVWog3NKiuJI7Z4QYA9S5+9CBvFS2XJ4UfYa4Eq7AzwvfTP6pj YFfQkigm6BFiSipqcGMEgvuCfUyBUh+iMvzzQk9wZvdK7eGQk2JHJO4m5fzNKIOxh358 d51VMpIUvrDXUfdoflxuhD8z/LG9qK/KX7nD3P7D3hf7ys6SGiNJC9Zp4vDzRyJ/LhyQ xWzw== X-Gm-Message-State: ALoCoQlPqqI8JtcRzTbzZxUFGwgVd/gpg2NSaKefVGvnTRkiELJyytDpH3SgCN7uS6Qh9KU2hkQu X-Received: by 10.229.64.134 with SMTP id e6mr12797409qci.11.1415986049296; Fri, 14 Nov 2014 09:27:29 -0800 (PST) MIME-Version: 1.0 References: <5465F075.1000306@redhat.com> <20141114171113.072DC1AFD0@ld9781.wdf.sap.corp> From: Ben Laurie Date: Fri, 14 Nov 2014 17:27:28 +0000 Message-ID: To: mrex@sap.com, Florian Weimer Content-Type: multipart/alternative; boundary=001a11339f7e79d04c0507d4f115 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZLvTVmTHXbwuc9tvAIn2L1lXjFY Cc: "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:27:49 -0000 --001a11339f7e79d04c0507d4f115 Content-Type: text/plain; charset=UTF-8 On Fri Nov 14 2014 at 5:12:10 PM Martin Rex wrote: > Keep in mind that there is the general IETF rule > > "Be liberal in what you accept, be conservative in what you send", > This "rule" is terrible for security and absolutely should not be followed. --001a11339f7e79d04c0507d4f115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri Nov 14 2014 at 5:12:10 PM Martin = Rex <mrex@sap.com> wrote:
Keep in mind that there is the general IETF rule=

"Be liberal in what you accept, be conservative in what you send"= ,

This "rule" is terrible for= security and absolutely should not be followed.

--001a11339f7e79d04c0507d4f115-- From nobody Fri Nov 14 09:32:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34B81A1B26 for ; Fri, 14 Nov 2014 09:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUc7b0f9IkE3 for ; Fri, 14 Nov 2014 09:32:19 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0061A1B35 for ; Fri, 14 Nov 2014 09:31:54 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 69AE63A40F; Fri, 14 Nov 2014 18:31:53 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 570BA42C41; Fri, 14 Nov 2014 18:31:53 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4C6DC1AFD0; Fri, 14 Nov 2014 18:31:53 +0100 (CET) In-Reply-To: To: Ben Laurie Date: Fri, 14 Nov 2014 18:31:53 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141114173153.4C6DC1AFD0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0k3-517s8yFLDC6ZRIijiiKYtcs Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:32:21 -0000 Ben Laurie wrote: > Martin Rex wrote: > >> Keep in mind that there is the general IETF rule >> >> "Be liberal in what you accept, be conservative in what you send", > > This "rule" is terrible for security and absolutely should not be followed. You seem to have missed it, but what we were discussing here is a guidance for the server which protocol version the server should use at the record layer when returning the fatal invalid_fallback alert to the client. The protocol_version that that the server uses will *NOT* affect the fatal failure of the handshake (for the server), but may affect the behaviour of the client and the comprehensibility of the error message that the client produces, so this is *EXACTLY* the kind of situation where the general IETF rule applies. -Martin From nobody Fri Nov 14 09:42:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672311A1B14 for ; Fri, 14 Nov 2014 09:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj3soHkDgjvk for ; Fri, 14 Nov 2014 09:42:23 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC721A1B12 for ; Fri, 14 Nov 2014 09:42:22 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 10so6665488ykt.17 for ; Fri, 14 Nov 2014 09:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gtIcPM7qXK+OgnD/hn7YBg8tJtzMgBZYraRmpgMqJh8=; b=dHXqH+xUBvJox4NvzgFOAlaJv45xENiyAOB+mSzJzePxr3cNwhfAtY75j+8ODboRlH G48JuQg/fcRO0iY+/zhCmFEk0lzFAAHXRlB7l5CM+Sgfb9FuDi3yQTCZfMy3FqG1JJsA jssVxL+K8jhzX3i3gRsv5w6mNSQB/q3/mQfk/jKsTfWmZQlIf9uZioXO7IbOJjFLFCyo mndYpUe8fi1GhH4cRvtf86WMd8ohin+3fpkcduNwiJQK/meMsOT+M2sHXgCHg8WUAkIQ eMMTDWppuLEQ/4QIuQhAVN4DKNuulEL1Uqba9QFwx8UBHOuz/AGMUeLWZwlBa0zyyHsp qrpg== MIME-Version: 1.0 X-Received: by 10.170.213.130 with SMTP id e124mr12118653ykf.24.1415986942221; Fri, 14 Nov 2014 09:42:22 -0800 (PST) Received: by 10.170.195.203 with HTTP; Fri, 14 Nov 2014 09:42:22 -0800 (PST) In-Reply-To: <20141114173153.4C6DC1AFD0@ld9781.wdf.sap.corp> References: <20141114173153.4C6DC1AFD0@ld9781.wdf.sap.corp> Date: Fri, 14 Nov 2014 09:42:22 -0800 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QW47wwXO8JBuqmMIKgJdAT9I9Jg Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:42:26 -0000 On Fri, Nov 14, 2014 at 9:31 AM, Martin Rex wrote: > Ben Laurie wrote: >> Martin Rex wrote: >> >>> Keep in mind that there is the general IETF rule >>> >>> "Be liberal in what you accept, be conservative in what you send", >> >> This "rule" is terrible for security and absolutely should not be followed. > > You seem to have missed it, but what we were discussing here > is a guidance for the server which protocol version the server should > use at the record layer when returning the fatal invalid_fallback > alert to the client. I'm confused. The record layers in all versions of TLS are the same, except for the version number, until encryption is turned on, and we have a version negotiation mechanism. Why shouldn't the server send the alert using the version that version negotiation would produce? Sincerely, Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Nov 14 10:52:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBA61A88ED for ; Fri, 14 Nov 2014 10:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFuRgnK-HQla for ; Fri, 14 Nov 2014 10:52:52 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D291A88F5 for ; Fri, 14 Nov 2014 10:52:52 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3FF8F3A3C4; Fri, 14 Nov 2014 19:52:50 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 30369422BB; Fri, 14 Nov 2014 19:52:50 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 25A671AFD0; Fri, 14 Nov 2014 19:52:50 +0100 (CET) In-Reply-To: To: Watson Ladd Date: Fri, 14 Nov 2014 19:52:50 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141114185250.25A671AFD0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ig5678_OYR_JfFLlaAZbeQ9bLAc Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 18:52:54 -0000 Watson Ladd wrote: > Martin Rex wrote: >> >> Ben Laurie wrote: >>> Martin Rex wrote: >>> >>>> Keep in mind that there is the general IETF rule >>>> >>>> "Be liberal in what you accept, be conservative in what you send", >>> >>> This "rule" is terrible for security and absolutely should not be followed. >> >> You seem to have missed it, but what we were discussing here >> is a guidance for the server which protocol version the server should >> use at the record layer when returning the fatal invalid_fallback >> alert to the client. > > I'm confused. The record layers in all versions of TLS are the same, > except for the version number, until encryption is turned on, and we > have a version negotiation mechanism. Why shouldn't the server send > the alert using the version that version negotiation would produce? There never is a version negotiated in this situation. Actually, the "protocol version negotiation" is a little weird in TLS, because the client never "offers" protocol versions to choose from, but only indicates the highest protocol version that it supports (or more appropriately, the highest protocol version that it is willing to use), and the server does whatever the server feels like. There are a number of unreasonable TLS clients that send record.pv = {3,3} + ClientHello.client_version = {3,3} even when they are configured to use allow other protocol versions, and a server that does _not_ support TLSv1.2 (or has it administratively disabled) has two options here: (a) fail the handshake with a fatal protocol_version alert (b) successfully continue the handshake with the highest protocol version that the server supports and has enabled. (a) is technically spec-compliant behaviour for pre-TLSv1.2 servers, and it is nowhere clear that pre-TLSv1.2 server implementers will take into accound broken TLSv1.2 clients ahead of time and do (b) from the beginning. Creating specification with ambiguities or undefined behaviour, pushing the buck to implementors, is never a good idea. Especially if one knows that implementors have previously failed time and time again, and when providing more elaborate guidance is easy. -Martin From nobody Fri Nov 14 14:46:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0061AD0D6 for ; Fri, 14 Nov 2014 14:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.406 X-Spam-Level: X-Spam-Status: No, score=0.406 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R99ysoYNe4uq for ; Fri, 14 Nov 2014 14:46:33 -0800 (PST) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3771AD0BD for ; Fri, 14 Nov 2014 14:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416005190; bh=nxothzIyV5nOTDWcGNVAx6pSNig4hrvxMJzQkKVoGvo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=EEjZ8eL8PjCLNZnigB0UqcVrrCdLaLzXHLG91iPL4fE7WxHCg+w/W88GKAS117hrtHkC99ry1z6FPdrIPQTlk3Ex48sBA5qH0Ht8jEFH49BWcUL9HP4LDJZGdFb1y1rxpnZaHhvXYT7779njy9ehPJIk/bTpUYiGHLD/pCpN+9rGQGcVCdwUeEt9odyHkmUUNzHf04zJKpSCZNYfKI5b3BdMpu3VhOa+QVDDMBoGQcF74098P7kPrkpA74bVh9vB3MRKVr0cweKkl7Ed+wFv15QvRvYxs4hj+BqSCj0D0FNJaSihHQCaPLqfqM9vWvT/K4LaVgysI8ygx2r1ZXDrXQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=GfZKWW7nt4x1xw+PPt0lqNM7NptIQYd5JkWc9OvzFBkH0DJipfwI9dCnZCQ/Ep3/1sApOvR4xjAtKbrfONomB3gm4+UDJIa6GkMAxglDYfUIX5HjuxETzkjHdzt5fi7JkyKWOECFsjSDrmylFBXG18TwS2TNoL+RhNw17ObP6UNwxA9RqfPGenFII9HOiMp7YseNc7BbK335sd3AZJlZR7OC0Z1ihREphEs8hILBCwSnIPzvnT9Vi+eWnKhFHodV2jGqrNyrNYJLRCPvZEHj5uiqQAeOmOP2RCWi5OKG0REsxocsG3qxoWopQME7btMgeKk6sD6KdA0QhaRP/GQ1+Q==; Received: from [98.139.215.143] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 22:46:30 -0000 Received: from [98.139.212.245] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 22:46:30 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 22:46:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 803359.72247.bm@omp1054.mail.bf1.yahoo.com X-YMail-OSG: NFQ1Si4VM1nTSSjlQWVc0vBgwzFtxiTia7vlKg_U.pt6IlI77KX0tPluUkIAlWg WrW3lCBQE0zb8.FwIM4EQkaAtUJvEg55u7KGbx3J.mVDU2SdGB_ogLSGxKWzUppeqJ.6ONu6CBvI MC9ZZdl4U5GHLCO6LF6S.kQXZBhMUdeo.NXBQsXKex9chOZudKuSGlM3hefYOwq87fnJgQMnasHO aTFLPlWV2Z15gGCwtEC8HFHe3bg5YnN1oEWyKfAl0uqjU.bW7Y0rSgtwBXSMMqIUSlJ6Gzo_Yh3k L7JrUtd_x7khoPb2qfhK8nxNf_KEK5JrjgL1oVEXUjdYu2IZTn4tT_BnI2XAVP.IUs0R5VBxafXe GrMG3WvI2oBtdkP_1rvp41ocTjmAPgi.NgudYFVAhIJfe5ETJu3NQo7QNM8herWL_sE1sZhUafGs YBRT8qFqjSUOWUOVNPxy06qussrcbrrFooeedhsWG5qQ1S.Z3sn1C5e83Mm6_8H40If3L3Eg- Received: by 66.196.80.150; Fri, 14 Nov 2014 22:46:30 +0000 Date: Fri, 14 Nov 2014 22:46:13 +0000 (UTC) From: Oleg Gryb To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= , Oleg Gryb , Johannes Merkle , "tls@ietf.org" Message-ID: <2109273109.730596.1416005173738.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com> In-Reply-To: <54647819.3020802@polarssl.org> References: <54647819.3020802@polarssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OS5VhQhug4a3MjyyBte_MEsXCcE Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:46:34 -0000 ----- Original Message ----- > From: Manuel P=C3=A9gouri=C3=A9-Gonnard > To: Oleg Gryb ; Johannes Merkle ; "tls@ietf.org" > Cc:=20 > Sent: Thursday, November 13, 2014 1:21 AM > Subject: Re: [TLS] Twist security for brainpoolp256r1 >=20 > Openssl has a "speed" command that should be helpful. I'd expect a=20 > difference > higher than 30%. I had to change 'speed.c' in openssl to add barinpoolp256r1 (by default it = simply not there). The difference for both ecdsa (signature) and ecdh (diff= ie-hellman-merkle key exchange) is less than 5%, so P-256 'optimization' in= openssl is definitely overrated. I think, I'm good to go with Brainpool. Doing 256 bit sign ecdsa's for 10s: 92012 256 bit ECDSA signs in 10.00s=20 Doing 256 bit verify ecdsa(nistp256)'s for 10s: 26294 256 bit ECDSA verify = in 10.00s Doing 256 bit sign ecdsa's for 10s: 88745 256 bit ECDSA signs in 10.00s=20 Doing 256 bit verify ecdsa(brainpoolP256r1)'s for 10s: 24939 256 bit ECDSA = verify in 10.00s 256 bit ecdsa (nistp256) 0.0001s 0.0004s 9201.2 2629.4 256 bit ecdsa (brainpoolP256r1) 0.0001s 0.0004s 8874.5 2493.9 Doing 256 bit ecdh(nistp256)'s for 10s: 31820 256-bit ECDH ops in 10.00s Doing 256 bit ecdh(brainpoolP256r1)'s for 10s: 29748 256-bit ECDH ops in 1= 0.00s 256 bit ecdh (nistp256) 0.0003s 3182.0 256 bit ecdh (brainpoolP256r1) 0.0003s 2974.8 From nobody Fri Nov 14 14:56:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416431AD352 for ; Fri, 14 Nov 2014 14:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRPPa-XxM4hd for ; Fri, 14 Nov 2014 14:56:53 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EB11AD33F for ; Fri, 14 Nov 2014 14:56:52 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0MekDA-1XeUeI3vtw-00OEkm; Fri, 14 Nov 2014 23:56:51 +0100 Received: by mail-ob0-f181.google.com with SMTP id gq1so883027obb.26 for ; Fri, 14 Nov 2014 14:56:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.198.21 with SMTP id w21mr4182568oif.64.1416005808873; Fri, 14 Nov 2014 14:56:48 -0800 (PST) Received: by 10.60.32.42 with HTTP; Fri, 14 Nov 2014 14:56:48 -0800 (PST) In-Reply-To: <20141114185250.25A671AFD0@ld9781.wdf.sap.corp> References: <20141114185250.25A671AFD0@ld9781.wdf.sap.corp> Date: Fri, 14 Nov 2014 23:56:48 +0100 Message-ID: From: Bodo Moeller To: Martin Rex Content-Type: multipart/alternative; boundary=001a11c17ac83d1e410507d98b43 X-Provags-ID: V02:K0:qyfHJ0sMgP2xakRoaauxl0xI3lK9v+2gkQ8dmgr1NtP edQqlaM7FhDi0Sxguv2Sp5i1hwL8ttN1Hc6s4d4oOJ2ROY9X/u hCmOPW0acokp+SuBWQHys6/YvPdQGGn0pB44EAldxurZN9weBk ptcX4exp/WH/gOVXrCOQBuCk7JqIlUabbKgysKg9DQ8Spiij2u IugKWIvyn9kliD6Z2eXWhdqSiEMUi5ZoGR/Gm7siVsfo59meFH zBBaNVfUUCf+uwKK+UBrhXa2kTEMfB7IjaG2eZb+LxAAWRMn8G WjAZixM0TfoHgvr3/EqDOY7BPssvPF9srUXcX9E/fXY00XX24j ItCFHr84P4pUFFmpwQGqVY1ISdbrbssXIIQDQJ4j6D8QHn+rIe U8alexMVoivYaTXTgREg0nIYNzgoU3IAjKDdO+3XZwQOdtIgXa LiJMG X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/32YudT_QAc_frnzQimHwn13e-BY Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:56:54 -0000 --001a11c17ac83d1e410507d98b43 Content-Type: text/plain; charset=UTF-8 Martin Rex : Creating specification with ambiguities or undefined behaviour, > pushing the buck to implementors, is never a good idea. > Now I am thoroughly confused by what you're saying. A bit earlier you argued *against* specifying a MUST for the record-layer version number to be used with the inappropriate_fallback alert (as it appears in draft-ietf-tls-downgrade-scsv-02), proposing instead a wording that you said was "vague on purpose". I can't reconcile that with what you're saying here. The only constant theme I can make out is that whatever you're saying at a given time is undoubtedly right. (For the record, I'm still happy with what draft-ietf-tls-downgrade-scsv-02 says.) Bodo --001a11c17ac83d1e410507d98b43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:

Creating specification with ambiguities or undefined behaviour,
pushing the buck to implementors, is never a good idea.

Now I am thoroughly confused by what you're saying. A = bit earlier you argued *against* specifying a MUST for the record-layer ver= sion number to be used with the inappropriate_fallback alert (as it appears= in draft-ietf-tls-downgrade-scsv-02), proposing instead a wording that you= said was "vague on purpose". I can't reconcile that with wha= t you're saying here. The only constant theme I can make out is that wh= atever you're saying at a given time is undoubtedly right.
(For the record, I'm still happy with what=C2=A0draft-ietf= -tls-downgrade-scsv-02 says.)

Bodo

<= /div>
--001a11c17ac83d1e410507d98b43-- From nobody Fri Nov 14 20:23:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2E1A0AF1 for ; Fri, 14 Nov 2014 20:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efu3jrkb7a0R for ; Fri, 14 Nov 2014 20:23:09 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB571A0AC8 for ; Fri, 14 Nov 2014 20:23:08 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 665863A2FA; Sat, 15 Nov 2014 05:23:06 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 56C2E42599; Sat, 15 Nov 2014 05:23:06 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4EB711AFD4; Sat, 15 Nov 2014 05:23:06 +0100 (CET) In-Reply-To: To: Bodo Moeller Date: Sat, 15 Nov 2014 05:23:06 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141115042306.4EB711AFD4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_7OvzahMHpg_HNr8kdVf6XBRR40 Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 04:23:13 -0000 Bodo Moeller wrote: > Martin Rex : > >> Creating specification with ambiguities or undefined behaviour, >> pushing the buck to implementors, is never a good idea. > > Now I am thoroughly confused by what you're saying. A bit earlier you > argued *against* specifying a MUST for the record-layer version number to > be used with the inappropriate_fallback alert (as it appears in > draft-ietf-tls-downgrade-scsv-02), proposing instead a wording that you > said was "vague on purpose". I can't reconcile that with what you're saying > here. The only constant theme I can make out is that whatever you're saying > at a given time is undoubtedly right. Giving a implementors a guidance by describing the issue at hand calling for reasonable trade-offs and and recommending, but not mandating certain behaviour, promotes interop. Using imperatives where this isn't necessary is not only squarly in conflict with rfc2119, it will also result in interop failures, because it gives (some) implementors poor excuses for why their code aborts or fails interop in a neither useful nor reasonable fashion. -Martin From nobody Fri Nov 14 22:06:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3325B1A03E3 for ; Fri, 14 Nov 2014 22:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehHgvbqSwOlH for ; Fri, 14 Nov 2014 22:06:02 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116D91A1AAC for ; Fri, 14 Nov 2014 22:05:59 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 69360188793; Sat, 15 Nov 2014 08:05:56 +0200 (EET) Date: Sat, 15 Nov 2014 08:05:56 +0200 From: Ilari Liusvaara To: Oleg Gryb Message-ID: <20141115060555.GA18732@LK-Perkele-VII> References: <54647819.3020802@polarssl.org> <2109273109.730596.1416005173738.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2109273109.730596.1416005173738.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IqDhnZPy4sBIaaVEMcZfSmB8zyY Cc: Manuel =?utf-8?B?UMOpZ291cmnDqS1Hb25uYXJk?= , "tls@ietf.org" Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 06:06:07 -0000 On Fri, Nov 14, 2014 at 10:46:13PM +0000, Oleg Gryb wrote: > > > Openssl has a "speed" command that should be helpful. I'd expect a > > difference > > higher than 30%. > > > I had to change 'speed.c' in openssl to add barinpoolp256r1 (by default > it simply not there). The difference for both ecdsa (signature) and ecdh > (diffie-hellman-merkle key exchange) is less than 5%, so P-256 'optimization' > in openssl is definitely overrated. I think, I'm good to go with Brainpool. I did some quick benchmarking locally. The new code does ~2.4x(!) the number of ECDH/ECDSA (all area accelerated by similar factor) ops per second compared to the old. (Intel i7 Ivy Bridge, so AVX but no AVX2). > Doing 256 bit sign ecdsa's for 10s: 92012 256 bit ECDSA signs in 10.00s > Doing 256 bit verify ecdsa(nistp256)'s for 10s: 26294 256 bit ECDSA verify in 10.00s > Doing 256 bit sign ecdsa's for 10s: 88745 256 bit ECDSA signs in 10.00s > Doing 256 bit verify ecdsa(brainpoolP256r1)'s for 10s: 24939 256 bit ECDSA verify in 10.00s > 256 bit ecdsa (nistp256) 0.0001s 0.0004s 9201.2 2629.4 > 256 bit ecdsa (brainpoolP256r1) 0.0001s 0.0004s 8874.5 2493.9 > > Doing 256 bit ecdh(nistp256)'s for 10s: 31820 256-bit ECDH ops in 10.00s > Doing 256 bit ecdh(brainpoolP256r1)'s for 10s: 29748 256-bit ECDH ops in 10.00s > 256 bit ecdh (nistp256) 0.0003s 3182.0 > 256 bit ecdh (brainpoolP256r1) 0.0003s 2974.8 - What OpenSSL version that is based on? - What build options? - What CPU? Those number don't pass my sanity checks if I assume new OpenSSL code: - Difference between special prime and random prime is too small, hinting bad implementation of special prime. - Extrapolation from numbers I got gives unreasonably low CPU speed. If I estimate based on numbers I got (which is probably off for pre-AVX or AVX2), I would estimate new p256 has about 2.5x the performance of Brainpool. -Ilari From nobody Sat Nov 15 00:50:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7283B1A6EE5 for ; Sat, 15 Nov 2014 00:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT1XE93EMSvw for ; Sat, 15 Nov 2014 00:50:39 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597511A3BA7 for ; Sat, 15 Nov 2014 00:50:39 -0800 (PST) Message-ID: <546713DB.5020201@akr.io> Date: Sat, 15 Nov 2014 08:50:35 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: Oleg Gryb , Oleg Gryb , =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= , Johannes Merkle , "tls@ietf.org" References: <54647819.3020802@polarssl.org> <2109273109.730596.1416005173738.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com> In-Reply-To: <2109273109.730596.1416005173738.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r9rFAcL2yGeaHoIpi9Gkgw4kOik Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 08:50:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 14 November 2014 22:46:13 GMT+00:00, Oleg Gryb wrote: > I had to change 'speed.c' in openssl to add barinpoolp256r1 (by > default it simply not there). The difference for both ecdsa > (signature) and ecdh (diffie-hellman-merkle key exchange) is less > than 5%, so P-256 'optimization' in openssl is definitely > overrated. No, you just don't have the optimisation turned on: that's using the old unoptimised generic prime routine. If you're on 1.0.1, Configure/make depend/make it with flag enable-ec_nistp_64_gcc_128 (if you're on x86-64) to use the agl/Emilia Kasper optimised secp224r1/secp256r1/secp521r1 routines, because they're not on by default. Or try the 1.0.2 trunk for Intel's even faster AVX2 assembly routines. You will need to make sure it's using the correct library version. P256 can go at least twice as fast as that, and then some, and that should be about what you're seeing. Brainpool, unfortunately, just can't go that fast; the pseudo-random primes don't have a structure which allows optimisation. But if a generic multiplier is OK for your performance needs (like you're using here, or if you have hardware which can do it well), Brainpool will be okay. - -- /akr. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUZxPbAAoJEOyEjtkWi2t6cQUP/1WrBq/Zm+T+wDBqOieqJipG zneBxkEOUoTmfGGw+2qJO2m9K4mqN+c4Kb31FiJcXFKnXOwHspAmSyh7C/7pkq2w GI/qLk8vYz2N0x8796iR9LkocsbCe1rXaAZw7GPbz1Erjvtvjx/5lGNI4kKgOD5a +jSN4dlp16S6WfAWzgbdTnRx7cTX22NqtoH0LZQBXAQd7Z3WuanOYVOQMD30fl8b DrvyybrZkpqRc8clUmbu3J3/G+ZrxmY6Xgg3TlN6EmA3uhOMgTkRss9jjrdxyoSx xYKP2HfYpd3yYe1hIHbPf/1jKdHpDIWNhZJ3bQdCEyKm1XrW7u5JBaOLY07zqPMj X8EldFhGwI62HPISYFCR2rbQm3xODtxcxWkik2T5LX8ALLQsRsl95LB+PCcYXBJ7 fsxGW/KkUjdZXvzIQ9bQyiQRQ7Fzg2lEcHKFq97PFQoqd7FWMIs/U0C58p8U0mtW H/FRyr1/hZeBKqCM0Id/cgzuHbD9VrsJiFN+i4wkHMwYNia/nNjBpv0a8Aby15/i t607G3nl6aMZYyyyi0+YGbUEuIOIDJ1wb2MDy+UxacSRdWPlhqe9HBwbkbbrMwrg rXR/jyAOASI4sdilOA51wUKs/mLA2gmwTA+RTlSqfnjMJReA+gm2bI5uARxIdcfG RCOq3HlwDDGI4pQbd82R =hohO -----END PGP SIGNATURE----- From nobody Sat Nov 15 08:32:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9541A88AC for ; Sat, 15 Nov 2014 08:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtdVW6LOV1pW for ; Sat, 15 Nov 2014 08:32:04 -0800 (PST) Received: from nm46-vm10.bullet.mail.bf1.yahoo.com (nm46-vm10.bullet.mail.bf1.yahoo.com [216.109.114.203]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BB61A1BD1 for ; Sat, 15 Nov 2014 08:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416069123; bh=RGfnkyEawi8umFe+DSXp3RpiCRzk6B9Z9ByUHkrozV4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=WE8OLRFP0ReG6mwOYN4/nOZB9WO0Ub7AD0Bq8LBp8egCtggAkMYWK2E+dYjajsfpyeVbeKSjhgON5Uj+T9J4/pW5NmPnGg7MZwq76Vb6cFiav2QiBO49WiVGWbyYTpno+9wRmPFT6m06CERWlqHTQEx/jd96yGbihMqQrA1VTYxFWkDezsGaHd92FEEYyHOPxDSgGioC/KJ/y0hzgBVkI829fi49y7ggqv6BIXAuEc7/svHP19P6M6MTy91B/aqOuLvFblWOwg4rk07YFHsz+sVhWxbPZEzSj0+cUCCdqstsmXwE0H8xVGtCUXhJ9WDuVbSOOwIWkYgroErQP8XGAA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=Sn8zNH3CyZH0ooskw/STSFMuat3MrUcxajwJms5DhLUm4em8YkTlDT4QqBGNUSiyN6VVqvxYK44hQpU7fL28kzwAfyieWIHpWeeQt/4NJ4Jtz3f694xPSOsZQMAhflMdB94BzxeJuANoImeQNdDMonUnEgZu420eYZhXHuwCLETB7YPRaZA0MZBdRUDPAbQiIuPSI7k6lQ4+8u61QAkKCTXRTqF3YJKgIVJzh4NP2lq7KU7pHrxbWsfOp9AGavWYFlExcwhjhdqYjksaB0/7QGh6jyQxP6HItPh1XMxm0G8dRgL4WfqUMzy6Wnb8U3CKqZ2I56rEG/qddyhRAYMajQ==; Received: from [66.196.81.173] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2014 16:32:03 -0000 Received: from [98.139.212.237] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2014 16:32:03 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 15 Nov 2014 16:32:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 370947.86434.bm@omp1046.mail.bf1.yahoo.com X-YMail-OSG: xsAI7EkVM1kf8YM.GUVnVwCtB1SdMik.pcnQ_LAkbTt7GiZSfgMMYm1zlj_0sZb tfLZzY1pRIQPFSMUWjLpr_.oxI1w0QsbCfwFPHTw8N8SIuGQi3qSzwSS4aXjoz7wclHgUBoqjoNe .ayllTkdsyYo.eOs0vPeWTF1yZikSjuu0YDVNkaSjBUk5RI4uDeZ3xLFK2_JoDQdP8A4KxRdn8OK bbDVn398UjxmQxr1m6e5JEtMUmk1Zt4k5r9buQdANQyL2tNNvOXnewiAt9_7FGkS9cnLYtN1AP39 mz3Pd0FfjMY4BlHWi_qCZNp.EWBnfhy0fP538vOVdzaljcGyP4SJ0Lt00JfuRpa2fqPV3qXz2K_C IzYoCNJK5_uT1jSKKWU6H.9moGcFUQwqkHxAsjI_4AWPcv7_MlewmaNZtRX7rbzkTsFy8xv1PmVr 53ToRVgqIb9cWZt.ogA0AbVlaEz2i25uFVs3vHxHX.x7IfmyJmdaNIrvuw8DxoDFnjzQY Received: by 76.13.27.134; Sat, 15 Nov 2014 16:32:02 +0000 Date: Sat, 15 Nov 2014 16:30:40 +0000 (UTC) From: Oleg Gryb To: Alyssa Rowan , Oleg Gryb , =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= , Johannes Merkle , "tls@ietf.org" Message-ID: <1034833904.885136.1416069040217.JavaMail.yahoo@jws10657.mail.bf1.yahoo.com> In-Reply-To: <546713DB.5020201@akr.io> References: <546713DB.5020201@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xPIFF4L-Z54ae8rhgY1MUR_QhoA Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 16:32:06 -0000 ----- Original Message ----- > From: Alyssa Rowan > To: Oleg Gryb ; Oleg Gryb ; Manuel P= =C3=A9gouri=C3=A9-Gonnard ; Johannes Merkle ; "tls@ietf.org" > Cc:=20 > Sent: Saturday, November 15, 2014 12:50 AM > Subject: Re: [TLS] Twist security for brainpoolp256r1 >=20 > No, you just don't have the optimisation turned on: that's using the > old unoptimised generic prime routine. >=20 > If you're on 1.0.1, Configure/make depend/make it with flag > enable-ec_nistp_64_gcc_128 (if you're on x86-64) to use the agl/Emilia > Kasper optimised secp224r1/secp256r1/secp521r1 routines, because > they're not on by default. >=20 > Or try the 1.0.2 trunk for Intel's even faster AVX2 assembly routines. >=20 > You will need to make sure it's using the correct library version. >=20 > P256 can go at least twice as fast as that, and then some, and that > should be about what you're seeing. >=20 > Brainpool, unfortunately, just can't go that fast; the pseudo-random > primes don't have a structure which allows optimisation. But if a > generic multiplier is OK for your performance needs (like you're using > here, or if you have hardware which can do it well), Brainpool will be > okay. >=20 Thanks, it's very helpful and I'll try. Judging from multiple Linux forums = it's recommended and its estimated speed increases is 2x for ECDHE, less so= for ECDSA though. I'm wondering why no-ec_nistp_64_gcc_128 is still a defa= ult. Are there any indications that either multiplier algorithm or its open= ssl implementation are error prone? From nobody Sat Nov 15 11:14:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7A21A1B96 for ; Sat, 15 Nov 2014 11:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zqISVRL2d4N for ; Sat, 15 Nov 2014 11:14:40 -0800 (PST) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378D41A1B95 for ; Sat, 15 Nov 2014 11:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416078879; bh=igD1z182GMcq45tJpIUrIQe+3fLjiI6W7ElVQuMDUHo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Jg+lpg6YhoAa0ByW3uweIBtiT3cxJ99w6M6f04EYoNJNT4FmPpd8Yb2OkyPrCbxFardq7i75XmdLxY64ISjBG1Js2ekW7ZbE7yOZpuPVLkZdT4oowjjFNPhZXDhimjw3F0pLPkILYan3SrWpYhAGAE4nxqOx8CIdzrbBBpd8O7u4n9++u+4aY3gz1GSHqc8HqgyxX/aW7fHBo1jpTcdrvSQS7FEXNlaS+5B+72oDzmLNPVyVMnBe0QAXe5A4P3V3/jV7alE5emXpIkZyvbcP0oG5TQYA/c4m5haebMyANlxcnZxG/C2Vw+sxDNdr8jYlzPqwYkXYr0gojNeT8t0y+w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=obF6Z7Cldd3f7ybnalb1mxd/WElcMMDjFrQnnoDI8pIbNmL3bPvcCgT7dggwaDMyq7IuWrOK3eDCh9K3xzsKQRcMpfO2ukPHWik2BZid6ZgsLQOJ7v2hzPcCr4nGCbTCR1GNaIqdUQN6+Z/WUWAX1s11dPoC1HPJGUUi9spe31/A5sgXhUkGxqZ/61bXr38kfMohzKXppNQwPbl86LlQrJkK2MWEKB4w5pyM0iaW8za7Aw2Ba1W8WsLrdMznIZQmLsiA7NtGWMtMRVUbdx36HjDusMLWQw8inQJa5RpdHjmnLwLrvDkYl+oIVaRXlQ0cU81dxoCDFNWiUX1oRFSAcQ==; Received: from [66.196.81.173] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2014 19:14:39 -0000 Received: from [98.139.212.247] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2014 19:14:39 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 15 Nov 2014 19:14:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 392105.42811.bm@omp1056.mail.bf1.yahoo.com X-YMail-OSG: EhcHHOgVM1kKtxadjeH7.OIanAf7bT0pOoiyKYteFXrZauLrWiU9sV6N3V9lnks Wq8_8_0n7kskmXmZkodcks9FM.8w0_LEZOIY.8DDPCe1jbe.mWVY7C08e.rRSOORpkEdMoO7B07T 7ZLXX3hmfXFddbQrdzFQlK2JGAPJJFrlWxlYLtMIL4PaR8__pwmquDcVe0DF7ji0zKeorwNFU2BS l4hcWPm3xeGNIQ77T5fNbehlxkQBPrQm.mNJyUBfsOI5rgC5fy9dcK0n7zuPiSUChV8nP0rx.yMb PduXlqll_SOLI1PYU2sQmTDKiUUmiom_6aj2rwf._JTK93T5QA7PwsbKmALIPA9uPvwsnDfauoAK WOTVDov1Ajh8u2SDw.o2pJDyMOJNqJXyG_UvHiOVD_CJSak00Hx48ZTTd4Z6tH2jJKV.hRjZy5Jo X9Iz7qER7.YT9pvPhn1OfGZ0xsPVOYKq_ER_YEUNKMMIIfZYrDsz4Onyr7DsyhHxeVes- Received: by 66.196.81.117; Sat, 15 Nov 2014 19:14:38 +0000 Date: Sat, 15 Nov 2014 19:14:37 +0000 (UTC) From: Oleg Gryb To: Alyssa Rowan , =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= , Johannes Merkle , "tls@ietf.org" Message-ID: <1583016284.927983.1416078877960.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com> In-Reply-To: <1034833904.885136.1416069040217.JavaMail.yahoo@jws10657.mail.bf1.yahoo.com> References: <1034833904.885136.1416069040217.JavaMail.yahoo@jws10657.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-7wUo7nVU06P2ezlxrveOnQJDRY Subject: Re: [TLS] Twist security for brainpoolp256r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 19:14:42 -0000 ----- Original Message ----- > From: Oleg Gryb > To: Alyssa Rowan ; Oleg Gryb ; Manuel P=C3=A9= gouri=C3=A9-Gonnard ; Johannes Merkle ; "tls@ietf.org" > Cc:=20 > Sent: Saturday, November 15, 2014 8:30 AM > Subject: Re: [TLS] Twist security for brainpoolp256r1 >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Alyssa Rowan >> To: Oleg Gryb ; Oleg Gryb=20 > ; Manuel P=C3=A9gouri=C3=A9-Gonnard ;=20 > Johannes Merkle ; "tls@ietf.org"=20 > >> Cc:=20 >> Sent: Saturday, November 15, 2014 12:50 AM >> Subject: Re: [TLS] Twist security for brainpoolp256r1 >=20 >>=20 >> No, you just don't have the optimisation turned on: that's using=20 > the >> old unoptimised generic prime routine. >>=20 >> If you're on 1.0.1, Configure/make depend/make it with flag >> enable-ec_nistp_64_gcc_128 (if you're on x86-64) to use the agl/Emilia >> Kasper optimised secp224r1/secp256r1/secp521r1 routines, because >> they're not on by default. >>=20 >> Or try the 1.0.2 trunk for Intel's even faster AVX2 assembly routines. >>=20 >> You will need to make sure it's using the correct library version. >>=20 >> P256 can go at least twice as fast as that, and then some, and that >> should be about what you're seeing. >>=20 >> Brainpool, unfortunately, just can't go that fast; the pseudo-random >> primes don't have a structure which allows optimisation. But if a >> generic multiplier is OK for your performance needs (like you're using >> here, or if you have hardware which can do it well), Brainpool will be >> okay. >>=20 >=20 >=20 > Thanks, it's very helpful and I'll try. Judging from multiple Linux=20 > forums it's recommended and its estimated speed increases is 2x for ECDHE= ,=20 > less so for ECDSA though. I'm wondering why no-ec_nistp_64_gcc_128 is sti= ll=20 > a default. Are there any indications that either multiplier algorithm or = its=20 > openssl implementation are error prone? >=20 Yet another thought that I believe, I've seen somewhere in a an EC discussi= on. If there is a shortcut that allows simplifying EC arithmetic significan= tly, doesn't it mean that an attacker might be in a very good position to e= ventually find a way of decreasing a cost of attack significantly as well? I understand that this is just a "common sense" argument, but I think that = it correlates well with EC's "spectral weakness" discussed by Dan Brown, DJ= B and others here:=20 http://www.ietf.org/mail-archive/web/tls/current/msg10169.html From nobody Sat Nov 15 13:40:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AFE1A87D7 for ; Sat, 15 Nov 2014 13:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGyPuQXgfynl for ; Sat, 15 Nov 2014 13:40:18 -0800 (PST) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.38.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0EC1A87A1 for ; Sat, 15 Nov 2014 13:40:18 -0800 (PST) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 2E0714B02C6E6; Sat, 15 Nov 2014 15:40:18 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 1C4B64B02C6B3 for ; Sat, 15 Nov 2014 15:40:18 -0600 (CST) Received: from [198.180.150.142] (port=51027 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xpl4r-0007Rt-EQ; Sat, 15 Nov 2014 15:40:17 -0600 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <544F3620.1040402@gmx.net> Date: Sat, 15 Nov 2014 11:40:14 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <97615105-BF27-45E9-A8A4-D785B27C479A@ieca.com> References: <544F3620.1040402@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Exim-ID: 1Xpl4r-0007Rt-EQ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:51027 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qrfem4PlC0pUmIZKmx-aUUvxccg Cc: tls@ietf.org Subject: Re: [TLS] Updated TLS Cached Info Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 21:40:20 -0000 Please note the new version has been posted (thank Hannes): http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ spt On Oct 27, 2014, at 20:22, Hannes Tschofenig = wrote: > Hi all, >=20 > as a result of the WGLC the cached info draft got a few good review > comments. I have tried to address them with a new document update > (version -17). >=20 > Since I missed the draft submission deadline you can find the document > here: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-= info/draft-ietf-tls-cached-info-17.txt >=20 > I will respond to the review comments directly but here is a short = summary: >=20 > * Simplified the exchange (as suggested by Ekr). > * Incorporated the optimizations suggested by Ekr regarding the > certificate_authority structure > * Required a collision resistant hash function. > * Clarifications throughout the document. >=20 > Ciao > Hannes >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Nov 15 14:12:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA861A0267 for ; Sat, 15 Nov 2014 14:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmmQejTHHL1v for ; Sat, 15 Nov 2014 14:12:23 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.195.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AD21A0262 for ; Sat, 15 Nov 2014 14:12:23 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 284D2DA21A2B1; Sat, 15 Nov 2014 16:12:23 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 14005DA21A283 for ; Sat, 15 Nov 2014 16:12:23 -0600 (CST) Received: from [198.180.150.142] (port=51102 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XplZu-0006SX-76; Sat, 15 Nov 2014 16:12:22 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <13DDAE38-237C-4130-A9D9-26B3B67851B2@gmail.com> Date: Sat, 15 Nov 2014 12:07:17 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9F69F631-53D5-45DB-835B-C9E80C58B87C@ieca.com> References: <1415696437.1938.6.camel@dhcp-2-127.brq.redhat.com> <13DDAE38-237C-4130-A9D9-26B3B67851B2@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Exim-ID: 1XplZu-0006SX-76 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:51102 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tb7Igt0bFJWI8h3N0iKHDlNbCQc Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 22:12:25 -0000 On Nov 10, 2014, at 23:58, Yoav Nir wrote: >>=20 >> On Nov 10, 2014, at 11:00 PM, Nikos Mavrogiannopoulos = wrote: >>=20 >> On Mon, 2014-11-10 at 17:17 -1000, Sean Turner wrote: >>> All, >>>=20 >>> This message is confirming the WG consensus we reached in Toronto = about producing an updated RFC4492 that is bound for standard track.* = Yoav has produced an individual draft that can be found here: >>>=20 >>> http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ >>>=20 >>> that we would like the WG to consider adopting. Please let us know = by November 18th whether you object to adopting Yoav=92s draft (and = why). >>=20 >> Two points: >> 1. This document includes fixed ECDH ciphersuites (ECDH_RSA, >> ECDH_ECDSA). Given they have 0 deployment on the internet, the = question >> is why? What are the practical use cases of these ciphersuites and = why >> should they be defined in a standards track document. >>=20 >> 2. This document includes arbitrary curve support. What is the = rationale >> for including that as no implementations support that [0], and even = for >> DH we are switching from arbitrary to named groups as well (I also >> ignore the known attacks for this option). >>=20 >> Unless there is sufficient argumentation and applicability for the >> above, I support the document only with the above removed. >=20 > Hi, Nikos >=20 > The current draft is pretty much a copy of RFC 4492. The intent is to = match whatever decision the WG will make for TLS 1.3. >=20 > So the changes that you suggest will be made after the document is = adopted (either in the -00 or -01 version, whichever way the chairs = prefer it).=20 >=20 > Following Sunday=92s interim, we=92re also likely to remove all the = defined curves weaker than P-256 (or maybe P-224 to match the strength = of 3DES, although I=92m not in favor) >=20 > We are also likely to deprecate point format negotiation. We won=92t = remove it for TLS 1.2, just mandate non-compressed format for existing = curves) >=20 > And when CFRG recommends a new curve, we will add it to this one. >=20 > So this document is in no way in its final form. >=20 > The question before the working group now is whether we want such a = document that obsolete 4492 and aligns EC for TLS 1.2 with what we want = for 1.3, or if we don=92t. >=20 > Hope this clarifies the situation >=20 > Yoav The idea is that the -00 version is pretty much 4492 so that every = change we make will be easily tracked in the diffs. spt (as chair) From nobody Sat Nov 15 14:13:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F261E1A8890 for ; Sat, 15 Nov 2014 14:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BarYZ_yaOBkU for ; Sat, 15 Nov 2014 14:13:10 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.41.242.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4061A032D for ; Sat, 15 Nov 2014 14:13:10 -0800 (PST) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id DA08C6F6879E6; Sat, 15 Nov 2014 16:13:09 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id BED786F6879C0 for ; Sat, 15 Nov 2014 16:13:09 -0600 (CST) Received: from [198.180.150.142] (port=51102 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xplae-0006SX-TN; Sat, 15 Nov 2014 16:13:09 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <13DDAE38-237C-4130-A9D9-26B3B67851B2@gmail.com> Date: Sat, 15 Nov 2014 12:13:06 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <407A316F-DC9B-47BC-8329-FE14CB3CADA6@ieca.com> References: <1415696437.1938.6.camel@dhcp-2-127.brq.redhat.com> <13DDAE38-237C-4130-A9D9-26B3B67851B2@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Exim-ID: 1Xplae-0006SX-TN X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:51102 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QccXcTuT9etbOZq6ogC6XLXHP8Q Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 22:13:12 -0000 On Nov 10, 2014, at 23:58, Yoav Nir wrote: >>=20 >> On Nov 10, 2014, at 11:00 PM, Nikos Mavrogiannopoulos = wrote: >>=20 >> On Mon, 2014-11-10 at 17:17 -1000, Sean Turner wrote: >>> All, >>>=20 >>> This message is confirming the WG consensus we reached in Toronto = about producing an updated RFC4492 that is bound for standard track.* = Yoav has produced an individual draft that can be found here: >>>=20 >>> http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ >>>=20 >>> that we would like the WG to consider adopting. Please let us know = by November 18th whether you object to adopting Yoav=92s draft (and = why). >>=20 >> Two points: >> 1. This document includes fixed ECDH ciphersuites (ECDH_RSA, >> ECDH_ECDSA). Given they have 0 deployment on the internet, the = question >> is why? What are the practical use cases of these ciphersuites and = why >> should they be defined in a standards track document. >>=20 >> 2. This document includes arbitrary curve support. What is the = rationale >> for including that as no implementations support that [0], and even = for >> DH we are switching from arbitrary to named groups as well (I also >> ignore the known attacks for this option). >>=20 >> Unless there is sufficient argumentation and applicability for the >> above, I support the document only with the above removed. >=20 > Hi, Nikos >=20 > The current draft is pretty much a copy of RFC 4492. The intent is to = match whatever decision the WG will make for TLS 1.3. >=20 > So the changes that you suggest will be made after the document is = adopted (either in the -00 or -01 version, whichever way the chairs = prefer it).=20 >=20 > Following Sunday=92s interim, we=92re also likely to remove all the = defined curves weaker than P-256 (or maybe P-224 to match the strength = of 3DES, although I=92m not in favor) >=20 > We are also likely to deprecate point format negotiation. We won=92t = remove it for TLS 1.2, just mandate non-compressed format for existing = curves) >=20 > And when CFRG recommends a new curve, we will add it to this one. >=20 > So this document is in no way in its final form. >=20 > The question before the working group now is whether we want such a = document that obsolete 4492 and aligns EC for TLS 1.2 with what we want = for 1.3, or if we don=92t. >=20 > Hope this clarifies the situation >=20 > Yoav The idea is that the -00 version is pretty much 4492 so that every = change we make will be easily tracked in the diffs. spt (as chair) From nobody Sat Nov 15 15:49:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FE31A88BE for ; Sat, 15 Nov 2014 15:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNwSdZeFcbfP for ; Sat, 15 Nov 2014 15:49:32 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.166.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD7E1A88BD for ; Sat, 15 Nov 2014 15:49:32 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id AB670DFEFFBF4; Sat, 15 Nov 2014 17:49:31 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 8C553DFEFFBA3 for ; Sat, 15 Nov 2014 17:49:31 -0600 (CST) Received: from [198.180.150.142] (port=51416 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xpn5u-0005if-Nu for tls@ietf.org; Sat, 15 Nov 2014 17:49:31 -0600 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 15 Nov 2014 13:49:27 -1000 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Exim-ID: 1Xpn5u-0005if-Nu X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:51416 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dfIa9OyNuMOu7x0IlBUwe-i68cs Subject: [TLS] WG adoption: draft-thomson-sslv3-diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 23:49:34 -0000 All, This message serves as a WG call for adoption of "Deprecating Secure = Sockets Layer Version 3.0": https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/ Please let us know by November 29th whether you object to adopting this = draft as a WG item (and why). j/s= From nobody Sun Nov 16 10:21:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EA41A19F9 for ; Sun, 16 Nov 2014 10:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqyHL-f7KsGC for ; Sun, 16 Nov 2014 10:21:49 -0800 (PST) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9791A19E7 for ; Sun, 16 Nov 2014 10:21:48 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sAGILkXZ002863; Sun, 16 Nov 2014 13:21:46 -0500 Date: Sun, 16 Nov 2014 13:21:46 -0500 (EST) From: Nikos Mavrogiannopoulos To: Martin Thomson Message-ID: <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> In-Reply-To: References: <5462714E.5020201@polarssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: Deprecating SSLv3 Thread-Index: Brh+Y2gQtGDTYT8c6Ie1CnzKC8QCQQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2u8lsHozPf3H0WBHEXLyoT7CR4Y Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 18:21:51 -0000 ----- Original Message ----- > That's a fair point. We probably shouldn't do that, yes. Maybe a > removal of the first sentence would suffice for that. > > TLS basically disavows all claims regarding what goes in the > ClientHello. We do know slightly more today such that we might be > able to fix it, but I don't think we need to open that can of worms > here. That certainly wasn't the intent. Will that be included in the draft? There is no point to have: "Clients MUST NOT set a record layer version number (TLSPlaintext.version) of {03,00}." as it will make perfectly valid TLS 1.2 client non compliant with the draft for no apparent reason (if there is a reason for that please elaborate in the draft). Other than that, if that is fixed, no objections. regards, Nikos From nobody Sun Nov 16 14:22:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402F61A1B71 for ; Sun, 16 Nov 2014 14:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaWCzBQd0NO7 for ; Sun, 16 Nov 2014 14:22:31 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7ED1A0110 for ; Sun, 16 Nov 2014 14:22:30 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id a141so6073840oig.4 for ; Sun, 16 Nov 2014 14:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kNJPE42gXFO23/FLjJsVHYOKsJYzySyrUnvkw9W1orM=; b=fD/4qkjQ6kab67806UlWdRnKhzmvUWnps+5C4WgYC8h86CgfLyPr0M/iRfvrc6To1t kSpweZ8AwE5L3k0fYJkdrReccDHUgqP2BIXh0ssQuV6Up06XkaxvPCzk4Tle0dnxRtri bVuLEsVYdyTCo5lf6Rseb3Kv08f2muQlOnD/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kNJPE42gXFO23/FLjJsVHYOKsJYzySyrUnvkw9W1orM=; b=JXFDi9USYneluhAE7Oh9m5eMly9q6fYx/63k4B3etCs1oaEJPu12AGqJSo0SL3eMdy T3AX7ncYy6di/SeKVffJQ8uIE2xgWYjwKw0FN6LDnFwscxeYLBwquEbOdwMpsR0Qzteg cPcecx47Wt3u1fu5ryhgUeCINaGIn0JYEVDI13Una6+p4/FJIvk6CWOlkKIFAt9wodU0 z1ezOR5PnHvxRdMjyKybpUBN9uQK4xtGhEGbtBfkCR6ycyRyakQ5Hwbc+PQ7CU8d6pMc GTzTiWYrBqwle3tL5riDGkTg50w9DmUA0d3/5qmqDFrsVzflN2r9MWVhaZVcYjyFQrO5 /xKw== X-Gm-Message-State: ALoCoQl2J1FL2850gUX8ML876QmtIbuQNz6D+Pq6cUYkM3Km/gMt0FepiiWtHFWvn7hK3+2HFBz2 MIME-Version: 1.0 X-Received: by 10.60.74.169 with SMTP id u9mr3567938oev.50.1416176549728; Sun, 16 Nov 2014 14:22:29 -0800 (PST) Received: by 10.76.84.65 with HTTP; Sun, 16 Nov 2014 14:22:29 -0800 (PST) X-Originating-IP: [82.224.193.99] In-Reply-To: <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> Date: Sun, 16 Nov 2014 23:22:29 +0100 Message-ID: From: Alfredo Pironti To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a1135ef1c2fbaec0508014ca1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oIZ4VN_hq0lbcF8OgfrTDqWfOtQ Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 22:22:33 -0000 --001a1135ef1c2fbaec0508014ca1 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 16, 2014 at 7:21 PM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > That's a fair point. We probably shouldn't do that, yes. Maybe a > > removal of the first sentence would suffice for that. > > > > TLS basically disavows all claims regarding what goes in the > > ClientHello. We do know slightly more today such that we might be > > able to fix it, but I don't think we need to open that can of worms > > here. That certainly wasn't the intent. > > Will that be included in the draft? Yes, I agree this is a fair point. I'll complete the wording tomorrow in the pending PR, and these ideas will get into the updated version. Cheers, Alfredo > There is no point to have: > "Clients MUST NOT set a record layer version number (TLSPlaintext.version) > of {03,00}." > as it will make perfectly valid TLS 1.2 client non compliant with the > draft for no apparent reason (if there is a reason for that please > elaborate > in the draft). > > Other than that, if that is fixed, no objections. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1135ef1c2fbaec0508014ca1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 16, 2014 at 7:21 PM, Nikos Mavrogiannopoulos <nmav@redhat.co= m> wrote:
= ----- Original Message -----
> That's a fair point.=C2=A0 We probably shouldn't do that, yes.= =C2=A0 Maybe a
> removal of the first sentence would suffice for that.
>
> TLS basically disavows all claims regarding what goes in the
> ClientHello.=C2=A0 We do know slightly more today such that we might b= e
> able to fix it, but I don't think we need to open that can of worm= s
> here.=C2=A0 That certainly wasn't the intent.

Will that be included in the draft?

Yes, I agree this is a fair point. I'll complete the wording tomorrow = in the pending PR, and these ideas will get into the updated version.
Cheers,
Alfredo
=C2=A0
There is no point to have:
"Clients MUST NOT set a record layer version number (= TLSPlaintext.version) of {03,00}."
as it will make perfectly valid TLS 1.2 client non compliant with th= e
draft for no apparent reason (if there is a reason for that please elaborat= e
in the draft).

Other than that, if that is fixed, no objections.

regards,
Nikos

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a1135ef1c2fbaec0508014ca1-- From nobody Mon Nov 17 18:22:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9F71A0033 for ; Mon, 17 Nov 2014 18:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.114 X-Spam-Level: *** X-Spam-Status: No, score=3.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1cxbBZ2NrXC for ; Mon, 17 Nov 2014 18:22:29 -0800 (PST) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AC51AD05F for ; Mon, 17 Nov 2014 18:22:28 -0800 (PST) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1416277346; x=1417486946; bh=B30Es02WPmRzMs0sHfIi8nWGmZxhCNHuQbHnTOgtcHs=; b=WEjpdpgsBW57S6VwGMN6jqAe2GX mLZQRGt95qlw5E4dZnK2RfdwLAIn7mr9ZnKXuiihjKP7rTP6vTfo7bKzCnTOtoY7215mW12h9W/pE uHWt63nnLh2JBCPzVSfeJhta+yG3VqNrriPaTGKQ+4RdaiSZ4avT3HJ9aqJ4WDYM4rrgdPIFwYnNs +LscCZwHR9zfljeP3DmKtFmdq0LF28WRI7ogCaINz2NbpHfwyvD+n1B2B2Y/VDYQYcuoj+keXknBW xd/7mJUW8Z0KXqReiDPP6ANZas5lN8VYBN9c5ZuHcyecWonblAl+jzktrZdmgC2fu3SbKqUhcoMgI 6CMpPPg==; Received: by omgo.iij.ad.jp (mo30) id sAI2MQoO012150; Tue, 18 Nov 2014 11:22:26 +0900 X-MXL-Hash: 546aad621d68b016-bb3e6ca75597a08f5d7a90edcf35c41d1ec5f35b Date: Tue, 18 Nov 2014 11:22:25 +0900 (JST) Message-Id: <20141118.112225.554744252617408337.kazu@iij.ad.jp> To: tls@ietf.org From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fonti5SDcibTIpon2MmqW6Lcmos Subject: [TLS] a type in the charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 02:22:30 -0000 Hi, The charter page of this working group[1] includes "v1.2 [RFC5346]" but I think that it should be "v1.2 [RFC5246]". [1] http://datatracker.ietf.org/wg/tls/charter/ --Kazu From nobody Tue Nov 18 08:53:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CBE1A1A9B for ; Tue, 18 Nov 2014 08:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFPm5lY6pG7A for ; Tue, 18 Nov 2014 08:53:16 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id C94531A1A7C for ; Tue, 18 Nov 2014 08:53:15 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 18 Nov 2014 11:53:10 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0174.001; Tue, 18 Nov 2014 11:53:09 -0500 From: Dan Brown To: "'hugo@ee.technion.ac.il'" , "'tls@ietf.org'" Thread-Topic: [TLS] OPTLS: Signature-less TLS 1.3 Thread-Index: AQHP9W51D9MIkcxEn06cGpESEaxsFJxmrI8w Date: Tue, 18 Nov 2014 16:53:08 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5D0111D@XMB116CNC.rim.net> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010B_01D00326.37FBE500" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IVLsR-GXVm9O10zXAHFcwbJAx4w Cc: "'hoeteck@alum.mit.edu'" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 16:53:20 -0000 ------=_NextPart_000_010B_01D00326.37FBE500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_010C_01D00326.37FC0C10" ------=_NextPart_001_010C_01D00326.37FC0C10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Some similarity between the OPTLS proposal and some previous key agreements schemes may be relevant. The main benefit of such similarity is that portions of the previous security analysis (whether security proofs, or lack of attacks) of the previous schemes may be applicable to OPTLS. In other words, OPTLS is not a radically new design. Obviously, the details by which OPTLS differs from previous schemes can be also be very important, especially with different goals and fixes to defects. One previous similar scheme is Blake-Wilson, Johnson and Menezes (BJM) key agreement (protocol 1). Specifically, if one replaces the initiator (client) static key with the ephemeral key in the BJM protocol, then BJM derives an authentication key in a way similar to OPTLS, and derives a separate session key from both ephemerals, similar to OPTLS. Another previous similar scheme is the unified model key agreement from NIST SP 800-56A (and ANSI X9.63). As with BJM, OPTLS differs from Unified in that OPTS replaces a static key from one side (the client) with the ephemeral key, and derives several types of keys (instead of just one in Unified model). The unified model key agreement has the defect of key-compromise impersonation (KCI attacks), but that does not seem to apply to OPTLS if the client is anonymous. Best regards, Dan From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hugo Krawczyk Sent: Friday, October 31, 2014 8:54 PM To: tls@ietf.org Cc: Hoeteck Wee Subject: [TLS] OPTLS: Signature-less TLS 1.3 During the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS 1.3 should abandon signature-based authentication (other than for certificates) and be based solely on a combination of ephemeral Diffie-Hellman for PFS and static Diffie-Hellman for authentication. This has multiple benefits including major performance gain (by replacing the per-handshake RSA signature by the server with a much cheaper elliptic curve exponentiation), compatibility with the mechanisms required for forward secrecy, natural accommodation of a 0-RTT option, and a simple extension without signatures for client authentication. Below I present a schematic representation of the proposed protocol referred to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. The presentation is sketchy and omits the exact procedure for key derivation. The latter is a crucial component for the security of the protocol, but before getting into these details we want to get a sense of whether the WG is interested in this approach. In the meantime, Hoeteck Wee and myself are working on the details of the protocol and the security proof. We describe a setting with optional 0-RTT and server-only authentication. Client authentication can be added as a further option or as an extension (similar to the current 1.3 proposal) - see below. NOTATION AND TERMINOLOGY: [K] symbols represent pointers to key material whose exact derivation is not included here except for specifying the basic DH values from which the key is derived (actual derivation will include further information similar to the extended hash mechanisms or SessionHash proposal considered for 1.3). Asterisks represent optional fields that the WG can decide to leave as optional, mandatory, or simply remove without changing the core cryptographic security of the protocol. All references to encryption mean "authenticated encryption" using the encrypt-then-mac paradigm (or any other secure AEAD mechanism). KeyShare's represent ephemeral Diffie-Hellman values exchanged by the parties. All the public key and Diffie-Hellman operations are assumed to happen over a cyclic group with generator g of order q (typically implemented by an elliptic curve group). We use multiplicative notation where ^ denotes exponentiation as in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc. Omitted from the current high level description is a mechanism for testing group membership of DH values or cofactor exponentiation (the specific mechanism depends on the group type and is typically very efficient for elliptic curves). SERVER PUBLIC KEY AND CERTIFICATE: The server has a long term private-public key pair denoted by (s,g^s) where s is uniform random in [0..q-1] (we refer to s and g^s as "static keys"). We assume that the server has a certificate that includes the server's public key g^s and a CA-signed binding of this key to the server's identity. We discuss the implementation of such certificates below. PROTOCOL OPTLS: ClientHello ClientKeyShare ClientData* [K0] --------> ServerHello ServerKeyShare ServerCertificate* [K1] ServerFinished [K2] <-------- ServerData* [K2] ClientFinished* [K2] --------> Protected Application Data [K3] <-------> 1-RTT CASE: The basic 1-RTT case omits the ClientData* field. It includes a ClientKeyShare g^x and a ServerKeyShare g^y and an optional (encrypted) server certificate. If the certificate is sent (it can be omitted if the client has indicated that it knows the server key as in the case in the 0-RTT scenario) and is encrypted, the encryption key K1 is derived from g^{xy}. Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used to authenticate-encrypt the ServerFinished and ClientFinished messages (which include a hash of the previous traffic) and to encrypt data from the server if such data is piggybacked to the second message. Key K3 is the "application key" used to derive key material for protection of application data. This key material will include (directional) Authenticated Encryption keys and, possibly, keys for derivation of further re-key material. K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its derivation will be different than K2, e.g., using a separating key expansion technique. SUPPORT FOR 0-RTT: The above protocol is compatible with a 0-RTT protocol such as QUIC. In this case, the client is assumed to have information about the server's public key and other security parameters. The server is assumed to have some mechanism in place for detecting replay (e.g., via timestamps, stored client nonces, etc.). The resulting protocol is as described above where the ClientData field is sent encrypted under key K0 derived from g^{xs}. The rest of the protocol is identical to the above. Note: In this case, ServerCertificate is not sent as the client had to know the server's public key before the first message (one can imagine a setting where the server may send a different certificate in the second message - if desired, this can be accommodated too as an option or extension). CLIENT AUTHENTICATION: Client authentication can be supported via an option or extension. It would include a client certificate for a static DH key g^c sent in the third message (the certificate can be encrypted under key K2 to provide client's identity protection). In this case, the key for computing the ClientFinished message and the application key K3 would be derived from a combination of the values g^xy, g^xs, g^yc (and possibly also g^{cs}). NOTES: Note on Finished messages: The above spec sets ServerFinished as mandatory and ClientFinished as optional. The latter option is needed for a 1-RTT protocol. In principle, both Finished messages could be omitted and still obtain security via implicit authentication (assuming the inputs to key derivation are chosen appropriately). But given the advantages of ServerFinished for providing explicit authentication, key confirmation, and active forward secrecy (see below), it seems advisable to always include it. Including ClientFinished provides key confirmation from client and also explicit client authentication when client certificate is included. ClientFinished also provides Universal Composable (UC) security (this is a result of the Canetti-Krawczyk proof that CK security implies UC security when a client confirmation step is included). Note on certificates: Since in current practice servers hold certificates for RSA signature keys rather than for static DH keys, the certificate field in the above protocol will be implemented by a pair consisting of (i) the server's RSA signature certificate and (ii) the server's signature using this RSA key on the server's static public DH key g^s. The latter signature by the server is performed only when a new static DH key is created (how often this happens and how many such keys are created is completely up to the server - it has the advantage that these keys can be changed often to increase security against leaked keys). This use of RSA also enjoys the high efficiency of RSA verification for the client. The handling of Client certificates would be similar. Note on forward security (a.k.a. as PFS for Perfect Forward Security): PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys. The meaning of PFS is that an attacker that finds the (long-term) static private keys of the parties cannot compromise past session keys. Without the ServerFinished message the above protocol ensures forward secrecy against passive attackers (i.e., for sessions where the attacker did not choose g^y). With ServerFinished, PFS holds also against active attackers. A similar consideration applies to ClientFinished. Client certificates in the first message: We note that in cases where client certificates can be sent in the clear in the first message of the protocol, one can provide PFS and mutual authentication in a 1-RTT at essentially the same cost of an unauthenticated DH exchange (i.e., a cost of little more than two exponentiations). In such a setting one can also obtain mutual authentication in a 0-RTT protocol (with forward secrecy with respect to the client's key). These options, however, require HMQV-like mechanisms and may raise IP issues (this can be investigated further if the WG is interested). ------=_NextPart_001_010C_01D00326.37FC0C10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Some similarity between the OPTLS proposal and some previous key = agreements schemes may be relevant.=C2=A0 The main benefit of such = similarity is that portions of the previous security analysis (whether = security proofs, or lack of attacks) of the previous schemes may be = applicable to OPTLS.=C2=A0 In other words, OPTLS is not a radically new = design. Obviously, the details by which OPTLS differs from previous = schemes can be also be very important, especially with different goals = and fixes to defects.

 

One previous similar scheme is Blake-Wilson, Johnson and Menezes = (BJM) key agreement (protocol 1). Specifically, if one replaces the = initiator (client) static key with the ephemeral key in the BJM = protocol, then BJM derives an authentication key in a way similar to = OPTLS, and derives a separate session key from both ephemerals, similar = to OPTLS.=C2=A0

 

Another previous similar scheme is the unified model key agreement = from NIST SP 800-56A (and ANSI X9.63).=C2=A0 As with BJM, OPTLS differs = from Unified in that OPTS replaces a static key from one side (the = client) with the ephemeral key, and derives several types of keys = (instead of just one in Unified model).=C2=A0 The unified model key = agreement has the defect of key-compromise impersonation (KCI attacks), = but that does not seem to apply to OPTLS if the client is = anonymous.

 

Best regards,

 

Dan

 

From:= = TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hugo = Krawczyk
Sent: Friday, October 31, 2014 8:54 PM
To: = tls@ietf.org
Cc: Hoeteck Wee
Subject: [TLS] OPTLS: = Signature-less TLS 1.3

 

During the TLS interim = meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should = abandon signature-based authentication (other than for = certificates)
and be based solely on a combination of ephemeral = Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. = This has multiple benefits including
major performance gain (by = replacing the per-handshake RSA signature by the
server with a much = cheaper elliptic curve exponentiation), compatibility with
the = mechanisms required for forward secrecy, natural accommodation of a = 0-RTT
option, and a simple extension without signatures for client = authentication.

Below I present a schematic representation of the = proposed protocol referred
to as OPTLS where OPT stands for OPTimized = and/or for One-Point-Three. 
The presentation is sketchy and = omits the exact procedure for key derivation.
The latter is a crucial = component for the security of the protocol, but
before getting into = these details we want to get a sense of whether the WG is
interested = in this approach. In the meantime, Hoeteck Wee and myself are =
working on the details of the protocol and the security = proof.

We describe a setting with optional 0-RTT and server-only = authentication.
Client authentication can be added as a further = option or as an extension
(similar to the current 1.3 proposal) - see = below.

NOTATION AND TERMINOLOGY:

[K] symbols represent = pointers to key material whose exact derivation is not
included here = except for specifying the basic DH values from which the key = is
derived (actual derivation will include further information = similar to the
extended hash mechanisms or SessionHash proposal = considered for 1.3).
Asterisks represent optional fields that the WG = can decide to leave as optional,
mandatory, or simply remove without = changing the core cryptographic security of
the protocol. All = references to encryption mean "authenticated = encryption"
using the encrypt-then-mac paradigm (or any other = secure AEAD mechanism). 

KeyShare's represent ephemeral = Diffie-Hellman values exchanged by the parties.
All the public key = and Diffie-Hellman operations are assumed to happen over a
cyclic = group with generator g of order q (typically implemented by an = elliptic
curve group). We use multiplicative notation where ^ denotes = exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of = the scalars x and y), etc.
Omitted from the current high level = description is a mechanism for testing group
membership of DH values = or cofactor exponentiation (the specific mechanism
depends on the = group type and is typically very efficient for elliptic = curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has = a long term private-public key pair denoted by (s,g^s) where
s is = uniform random in [0..q-1] (we refer to s and g^s as "static = keys").
We assume that the server has a certificate that = includes the server's public
key g^s and a CA-signed binding of this = key to the server's identity.
We discuss the implementation of such = certificates below.

PROTOCOL = OPTLS:

ClientHello
ClientKeyShare
ClientData* = [K0]       = -------->
         &nb= sp;           &nbs= p;            = ;         = ServerHello   =
           &nb= sp;           &nbs= p;            = ;       ServerKeyShare  =
           &nb= sp;           &nbs= p;            = ;       ServerCertificate* = [K1]
           = ;            =             &= nbsp;       ServerFinished = [K2]
           = ;            = <--------           = ServerData* [K2]
ClientFinished* [K2]   = -------->


        &= nbsp;   Protected Application Data = [K3]
           = ;            = <------->



1-RTT CASE:

The basic 1-RTT case = omits the ClientData* field. It includes a ClientKeyShare
g^x and a = ServerKeyShare g^y and an optional (encrypted) server certificate. =
If the certificate is sent (it can be omitted if the client has = indicated that
it knows the server key as in the case in the 0-RTT = scenario) and is encrypted,
the encryption key K1 is derived from = g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and = g^{xy}. It is used to
authenticate-encrypt the ServerFinished and = ClientFinished messages (which
include a hash of the previous = traffic) and to encrypt data from the server if
such data is = piggybacked to the second message.

Key K3 is the = "application key" used to derive key material for protection = of
application data.  This key material will include = (directional) Authenticated
Encryption keys and, possibly, keys for = derivation of further re-key material.
K3 is computed from  both = g^{xs} and g^{xy} similarly to K2, but its derivation
will be = different than K2, e.g., using a separating key expansion = technique.

SUPPORT FOR 0-RTT:

The above protocol is = compatible with a 0-RTT protocol such as QUIC. In this
case, the = client is assumed to have information about the server's public = key
and other security parameters. The server is assumed to have some = mechanism in
place for detecting replay (e.g., via timestamps, stored = client nonces, etc.).
The resulting protocol is as described above = where the ClientData field is sent
encrypted under key K0 derived = from g^{xs}. 
The rest of the protocol is identical to the = above. 
Note: In this case, ServerCertificate is not sent as = the client had to know
the server's public key before the first = message (one can imagine a setting
where the server may send a = different certificate in the second message - if
desired, this can be = accommodated too as an option or extension).

CLIENT = AUTHENTICATION:

Client authentication can be supported via an = option or extension. It would
include a client certificate for a = static DH key g^c sent in the third message
(the certificate can be = encrypted under key K2 to provide client's identity
protection). In = this case, the key for computing the ClientFinished message and
the = application key K3 would be derived from a combination of the values = g^xy,
g^xs, g^yc (and possibly also g^{cs}). =

NOTES:

Note on Finished messages: The above spec sets = ServerFinished as mandatory and
ClientFinished as optional. The = latter option is needed for a 1-RTT protocol.
In principle, both = Finished messages could be omitted and still obtain security
via = implicit authentication (assuming the inputs to key derivation are = chosen
appropriately). But given the advantages of ServerFinished for = providing
explicit authentication, key confirmation, and active = forward secrecy (see
below), it seems advisable to always include it. = Including ClientFinished
provides key confirmation from client and = also explicit client authentication
when client certificate is = included. ClientFinished also provides Universal
Composable (UC) = security (this is a result of the Canetti-Krawczyk proof that
CK = security implies UC security when a client confirmation step is = included). 

Note on certificates: Since in current practice = servers hold certificates for
RSA signature keys rather than for = static DH keys, the certificate field in the
above protocol will be = implemented by a pair consisting of (i) the server's RSA
signature = certificate and (ii) the server's signature using this RSA key on = the
server's static public DH key g^s. The latter signature by the = server is
performed only when a new static DH key is created (how = often this happens and
how many such keys are created is completely = up to the server - it has the
advantage that these keys can be = changed often to increase security against
leaked keys). This use of = RSA also enjoys the high efficiency of RSA
verification for the = client. 
The handling of Client certificates would be = similar.

Note on forward security (a.k.a. as PFS for Perfect = Forward Security):
PFS is provided by the (mandatory) use of = ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker = that finds the (long-term) static
private keys of the parties cannot = compromise past session keys. Without the
ServerFinished message the = above protocol ensures forward secrecy against
passive attackers = (i.e., for sessions where the attacker did not choose g^y).
With = ServerFinished, PFS holds also against active attackers.  A = similar
consideration applies to ClientFinished.

Client = certificates in the first message: We note that in cases where = client
certificates can be sent in the clear in the first message of = the protocol, one
can provide PFS and mutual authentication in a = 1-RTT at essentially the same
cost of an unauthenticated DH exchange = (i.e., a cost of little more than two
exponentiations). In such a = setting one can also obtain mutual authentication in
a 0-RTT protocol = (with forward secrecy with respect to the client's key). 
These = options, however, require HMQV-like mechanisms and may raise IP issues = (this
can be investigated further if the WG is = interested).

------=_NextPart_001_010C_01D00326.37FC0C10-- ------=_NextPart_000_010B_01D00326.37FBE500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTExODE2NTMwN1owIwYJKoZIhvcNAQkEMRYEFAM3 vYJbhvF7AQH4Dq/uDLRfA/a5MG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYCwjhvAeVl9giOA+DXItYKLhXIjD1fl 1mUsd6DuCQV0TSj1mQn9iEnIkAjnbmnFibATwWr5TMsKmKvuBIqiO7meAMZFVfycQnmKYUW3hrkK wLTCHcMi5wWzYRx7tFTFjRBUyDGCEr5nGwYXpXOL4Z9S+BRogPAMHyyx4YmfC/yZLAAAAAAAAA== ------=_NextPart_000_010B_01D00326.37FBE500-- From nobody Tue Nov 18 12:10:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27AD1A87AF for ; Tue, 18 Nov 2014 12:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izhgM66wGyEd for ; Tue, 18 Nov 2014 12:10:44 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9AD1A87A4 for ; Tue, 18 Nov 2014 12:10:35 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so18266426lbv.10 for ; Tue, 18 Nov 2014 12:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4V64fVAKipnMdFjirM35ixQ5dFJ2HAd94DRjk9H828g=; b=jcTO2FuYz56U0HbmKBAw+m1gQ20c3SJxJsYkQtTk7DxM7pOAts2jKwi/WOcEnkN02O v3jd7rIydJdwNQjLEeHbfcyR3tpINpzXb1c8KQhS2F+ecV7527SgwiFcQT+3UlAGYJns Rqx/a8GSzQ2TcSEt70nMg7PXE0OjC2Y91sTSt0J8a8FdpA2D4PhwQZ1yHmD9hIWiAptR jfmTkCIhjN4oPGbS23zGeuAnWK9JEJeXvW0MF29llca+jQ5Va3mebqCPsdWiSJauc3rz rKEa50rgtkCjyOMmXtiqvCq3ze+gFBtdq/IpNHgUuxAxCMpfmxNyJruWGJwqEDq8IrHG jKSw== X-Received: by 10.112.201.72 with SMTP id jy8mr1137380lbc.65.1416341434216; Tue, 18 Nov 2014 12:10:34 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.20 with HTTP; Tue, 18 Nov 2014 12:10:04 -0800 (PST) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5D0111D@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF5D0111D@XMB116CNC.rim.net> From: Hugo Krawczyk Date: Tue, 18 Nov 2014 15:10:04 -0500 X-Google-Sender-Auth: k9CQXmfmfvGiqrbue-uUlkWqfdo Message-ID: To: Dan Brown Content-Type: multipart/alternative; boundary=001a11c372da1137ac050827b031 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HrGZnU2ILFXkGnZc8BZOb__9q6c Cc: "tls@ietf.org" , "hoeteck@alum.mit.edu" Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 20:10:49 -0000 --001a11c372da1137ac050827b031 Content-Type: text/plain; charset=UTF-8 I am aware of these protocols of course (and their shortcomings) and of several other relevant works (e.g Katz et al). There is also my own SKEME protocol from 1995 (which predates these other schemes) which is closer in the approach to OPTLS in the sense of providing a flexible framework for supporting things like session resumption and Pre-shared key. None of these, however, support basic requirements from OPTLS such as 0-RTT and server-only authentication. In any case, similarity between KE protocols is not a guarantee of security. The devil is in the details, and OPTLS has not even fixed these details. We are waiting to understand better the requirements before fixing these. It may well be the case that there will be no need to fix them if the WG is not interested in pursuing this direction (which is quite a shame). Hugo PS: BTW, the UM protocol from NIST 56A is not only subject to UKS but also to the interleaving attack from BJM. On Tue, Nov 18, 2014 at 11:53 AM, Dan Brown wrote: > Some similarity between the OPTLS proposal and some previous key > agreements schemes may be relevant. The main benefit of such similarity is > that portions of the previous security analysis (whether security proofs, > or lack of attacks) of the previous schemes may be applicable to OPTLS. In > other words, OPTLS is not a radically new design. Obviously, the details by > which OPTLS differs from previous schemes can be also be very important, > especially with different goals and fixes to defects. > > > > One previous similar scheme is Blake-Wilson, Johnson and Menezes (BJM) key > agreement (protocol 1). Specifically, if one replaces the initiator > (client) static key with the ephemeral key in the BJM protocol, then BJM > derives an authentication key in a way similar to OPTLS, and derives a > separate session key from both ephemerals, similar to OPTLS. > > > > Another previous similar scheme is the unified model key agreement from > NIST SP 800-56A (and ANSI X9.63). As with BJM, OPTLS differs from Unified > in that OPTS replaces a static key from one side (the client) with the > ephemeral key, and derives several types of keys (instead of just one in > Unified model). The unified model key agreement has the defect of > key-compromise impersonation (KCI attacks), but that does not seem to apply > to OPTLS if the client is anonymous. > > > > Best regards, > > > > Dan > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Hugo Krawczyk > *Sent:* Friday, October 31, 2014 8:54 PM > *To:* tls@ietf.org > *Cc:* Hoeteck Wee > *Subject:* [TLS] OPTLS: Signature-less TLS 1.3 > > > > During the TLS interim meeting of last week (Oct 22 2014) I suggested that > TLS > 1.3 should abandon signature-based authentication (other than for > certificates) > and be based solely on a combination of ephemeral Diffie-Hellman for PFS > and > static Diffie-Hellman for authentication. This has multiple benefits > including > major performance gain (by replacing the per-handshake RSA signature by the > server with a much cheaper elliptic curve exponentiation), compatibility > with > the mechanisms required for forward secrecy, natural accommodation of a > 0-RTT > option, and a simple extension without signatures for client > authentication. > > Below I present a schematic representation of the proposed protocol > referred > to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. > The presentation is sketchy and omits the exact procedure for key > derivation. > The latter is a crucial component for the security of the protocol, but > before getting into these details we want to get a sense of whether the WG > is > interested in this approach. In the meantime, Hoeteck Wee and myself are > working on the details of the protocol and the security proof. > > We describe a setting with optional 0-RTT and server-only authentication. > Client authentication can be added as a further option or as an extension > (similar to the current 1.3 proposal) - see below. > > NOTATION AND TERMINOLOGY: > > [K] symbols represent pointers to key material whose exact derivation is > not > included here except for specifying the basic DH values from which the key > is > derived (actual derivation will include further information similar to the > extended hash mechanisms or SessionHash proposal considered for 1.3). > Asterisks represent optional fields that the WG can decide to leave as > optional, > mandatory, or simply remove without changing the core cryptographic > security of > the protocol. All references to encryption mean "authenticated encryption" > using the encrypt-then-mac paradigm (or any other secure AEAD mechanism). > > KeyShare's represent ephemeral Diffie-Hellman values exchanged by the > parties. > All the public key and Diffie-Hellman operations are assumed to happen > over a > cyclic group with generator g of order q (typically implemented by an > elliptic > curve group). We use multiplicative notation where ^ denotes > exponentiation as > in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), > etc. > Omitted from the current high level description is a mechanism for testing > group > membership of DH values or cofactor exponentiation (the specific mechanism > depends on the group type and is typically very efficient for elliptic > curves). > > SERVER PUBLIC KEY AND CERTIFICATE: > > The server has a long term private-public key pair denoted by (s,g^s) > where > s is uniform random in [0..q-1] (we refer to s and g^s as "static keys"). > We assume that the server has a certificate that includes the server's > public > key g^s and a CA-signed binding of this key to the server's identity. > We discuss the implementation of such certificates below. > > PROTOCOL OPTLS: > > ClientHello > ClientKeyShare > ClientData* [K0] --------> > ServerHello > ServerKeyShare > ServerCertificate* [K1] > ServerFinished [K2] > <-------- ServerData* [K2] > ClientFinished* [K2] --------> > > > Protected Application Data [K3] > <-------> > > > > 1-RTT CASE: > > The basic 1-RTT case omits the ClientData* field. It includes a > ClientKeyShare > g^x and a ServerKeyShare g^y and an optional (encrypted) server > certificate. > If the certificate is sent (it can be omitted if the client has indicated > that > it knows the server key as in the case in the 0-RTT scenario) and is > encrypted, > the encryption key K1 is derived from g^{xy}. > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is > used to > authenticate-encrypt the ServerFinished and ClientFinished messages (which > include a hash of the previous traffic) and to encrypt data from the > server if > such data is piggybacked to the second message. > > Key K3 is the "application key" used to derive key material for protection > of > application data. This key material will include (directional) > Authenticated > Encryption keys and, possibly, keys for derivation of further re-key > material. > K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its > derivation > will be different than K2, e.g., using a separating key expansion > technique. > > SUPPORT FOR 0-RTT: > > The above protocol is compatible with a 0-RTT protocol such as QUIC. In > this > case, the client is assumed to have information about the server's public > key > and other security parameters. The server is assumed to have some > mechanism in > place for detecting replay (e.g., via timestamps, stored client nonces, > etc.). > The resulting protocol is as described above where the ClientData field is > sent > encrypted under key K0 derived from g^{xs}. > The rest of the protocol is identical to the above. > Note: In this case, ServerCertificate is not sent as the client had to know > the server's public key before the first message (one can imagine a setting > where the server may send a different certificate in the second message - > if > desired, this can be accommodated too as an option or extension). > > CLIENT AUTHENTICATION: > > Client authentication can be supported via an option or extension. It would > include a client certificate for a static DH key g^c sent in the third > message > (the certificate can be encrypted under key K2 to provide client's identity > protection). In this case, the key for computing the ClientFinished > message and > the application key K3 would be derived from a combination of the values > g^xy, > g^xs, g^yc (and possibly also g^{cs}). > > NOTES: > > Note on Finished messages: The above spec sets ServerFinished as mandatory > and > ClientFinished as optional. The latter option is needed for a 1-RTT > protocol. > In principle, both Finished messages could be omitted and still obtain > security > via implicit authentication (assuming the inputs to key derivation are > chosen > appropriately). But given the advantages of ServerFinished for providing > explicit authentication, key confirmation, and active forward secrecy (see > below), it seems advisable to always include it. Including ClientFinished > provides key confirmation from client and also explicit client > authentication > when client certificate is included. ClientFinished also provides Universal > Composable (UC) security (this is a result of the Canetti-Krawczyk proof > that > CK security implies UC security when a client confirmation step is > included). > > Note on certificates: Since in current practice servers hold certificates > for > RSA signature keys rather than for static DH keys, the certificate field > in the > above protocol will be implemented by a pair consisting of (i) the > server's RSA > signature certificate and (ii) the server's signature using this RSA key > on the > server's static public DH key g^s. The latter signature by the server is > performed only when a new static DH key is created (how often this happens > and > how many such keys are created is completely up to the server - it has the > advantage that these keys can be changed often to increase security against > leaked keys). This use of RSA also enjoys the high efficiency of RSA > verification for the client. > The handling of Client certificates would be similar. > > Note on forward security (a.k.a. as PFS for Perfect Forward Security): > PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys. > The meaning of PFS is that an attacker that finds the (long-term) static > private keys of the parties cannot compromise past session keys. Without > the > ServerFinished message the above protocol ensures forward secrecy against > passive attackers (i.e., for sessions where the attacker did not choose > g^y). > With ServerFinished, PFS holds also against active attackers. A similar > consideration applies to ClientFinished. > > Client certificates in the first message: We note that in cases where > client > certificates can be sent in the clear in the first message of the > protocol, one > can provide PFS and mutual authentication in a 1-RTT at essentially the > same > cost of an unauthenticated DH exchange (i.e., a cost of little more than > two > exponentiations). In such a setting one can also obtain mutual > authentication in > a 0-RTT protocol (with forward secrecy with respect to the client's key). > These options, however, require HMQV-like mechanisms and may raise IP > issues (this > can be investigated further if the WG is interested). > --001a11c372da1137ac050827b031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am aware of these protocols of course (and th= eir shortcomings) and of several other relevant works (e.g Katz et al).
=
There is also my own SKEME protocol from 1995 (which preda= tes these other schemes) which is closer in the approach to OPTLS in the se= nse of providing a flexible framework for supporting things like session re= sumption and Pre-shared key.
None of these, however, su= pport basic requirements from OPTLS such as 0-RTT and server-only authentic= ation.

In any case, similarity between KE protocols= is not a guarantee of security. The devil is in the details, and OPTLS has= not even fixed these details. We are waiting to understand better the requ= irements before fixing these. It may well be the case that there will be no= need to fix them if the WG is not interested in pursuing this direction (w= hich is quite a shame).

Hugo

PS: BTW, the UM protocol from NIST 56A is not only subject to UKS but als= o to the interleaving attack from BJM.


On Tue, Nov 18, 2014 at 11:53 AM, Dan Br= own <dbrown@certicom.com> wrote:

Some similarity between the OPTLS= proposal and some previous key agreements schemes may be relevant.=C2=A0 T= he main benefit of such similarity is that portions of the previous securit= y analysis (whether security proofs, or lack of attacks) of the previous sc= hemes may be applicable to OPTLS.=C2=A0 In other words, OPTLS is not a radi= cally new design. Obviously, the details by which OPTLS differs from previo= us schemes can be also be very important, especially with different goals a= nd fixes to defects.

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">One previous similar scheme is Blake-Wilson, John= son and Menezes (BJM) key agreement (protocol 1). Specifically, if one repl= aces the initiator (client) static key with the ephemeral key in the BJM pr= otocol, then BJM derives an authentication key in a way similar to OPTLS, a= nd derives a separate session key from both ephemerals, similar to OPTLS.= =C2=A0

=C2=A0

Another previous similar scheme is the unified model key agree= ment from NIST SP 800-56A (and ANSI X9.63).=C2=A0 As with BJM, OPTLS differ= s from Unified in that OPTS replaces a static key from one side (the client= ) with the ephemeral key, and derives several types of keys (instead of jus= t one in Unified model).=C2=A0 The unified model key agreement has the defe= ct of key-compromise impersonation (KCI attacks), but that does not seem to= apply to OPTLS if the client is anonymous.

=C2=A0

<= p class=3D"MsoNormal">Best regards,

=C2=A0=

Dan<= /u>

<= /u>=C2=A0

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: TLS [mailto:tls-bounces@ietf.org] On Behalf O= f Hugo Krawczyk
Sent: Friday, October 31, 2014 8:54 PM<= br>To: tls@ietf.or= g
Cc: Hoeteck Wee
Subject: [TLS] OPTLS: Sign= ature-less TLS 1.3

=C2=A0

During the TLS interim meeting of last week (Oct 22= 2014) I suggested that TLS
1.3 should abandon signature-based authentic= ation (other than for certificates)
and be based solely on a combination= of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authe= ntication. This has multiple benefits including
major performance gain (= by replacing the per-handshake RSA signature by the
server with a much c= heaper elliptic curve exponentiation), compatibility with
the mechanisms= required for forward secrecy, natural accommodation of a 0-RTT
option, = and a simple extension without signatures for client authentication.
Below I present a schematic representation of the proposed protocol referr= ed
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three= .=C2=A0
The presentation is sketchy and omits the exact procedure for k= ey derivation.
The latter is a crucial component for the security of the= protocol, but
before getting into these details we want to get a sense= of whether the WG is
interested in this approach. In the meantime, Hoet= eck Wee and myself are
working on the details of the protocol and the s= ecurity proof.

We describe a setting with optional 0-RTT and server-= only authentication.
Client authentication can be added as a further opt= ion or as an extension
(similar to the current 1.3 proposal) - see below= .

NOTATION AND TERMINOLOGY:

[K] symbols represent pointers to= key material whose exact derivation is not
included here except for spe= cifying the basic DH values from which the key is
derived (actual deriva= tion will include further information similar to the
extended hash mecha= nisms or SessionHash proposal considered for 1.3).
Asterisks represent = optional fields that the WG can decide to leave as optional,
mandatory, = or simply remove without changing the core cryptographic security of
the= protocol. All references to encryption mean "authenticated encryption= "
using the encrypt-then-mac paradigm (or any other secure AEAD mec= hanism).=C2=A0

KeyShare's represent ephemeral Diffie-Hellman va= lues exchanged by the parties.
All the public key and Diffie-Hellman ope= rations are assumed to happen over a
cyclic group with generator g of or= der q (typically implemented by an elliptic
curve group). We use multipl= icative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here = xy denotes multiplication of the scalars x and y), etc.
Omitted from the= current high level description is a mechanism for testing group
members= hip of DH values or cofactor exponentiation (the specific mechanism
depe= nds on the group type and is typically very efficient for elliptic curves).=

SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long ter= m private-public key pair denoted by (s,g^s) where
s is uniform random = in [0..q-1] (we refer to s and g^s as "static keys").
We assu= me that the server has a certificate that includes the server's public<= br>key g^s and a CA-signed binding of this key to the server's identity= .
We discuss the implementation of such certificates below.

PROTO= COL OPTLS:

ClientHello
ClientKeyShare
ClientData* [K0]=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ServerHello=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerKeyShare=C2= =A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerCertificate* [K1]
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ServerFinished [K2]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ServerData* [K2]
ClientFinished* [K2]=C2=A0=C2= =A0 -------->


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Protected Application Data [K3]
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------->



1-RT= T CASE:

The basic 1-RTT case omits the ClientData* field. It include= s a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypt= ed) server certificate.
If the certificate is sent (it can be omitted i= f the client has indicated that
it knows the server key as in the case i= n the 0-RTT scenario) and is encrypted,
the encryption key K1 is derived= from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} a= nd g^{xy}. It is used to
authenticate-encrypt the ServerFinished and Cli= entFinished messages (which
include a hash of the previous traffic) and = to encrypt data from the server if
such data is piggybacked to the secon= d message.

Key K3 is the "application key" used to derive = key material for protection of
application data.=C2=A0 This key material= will include (directional) Authenticated
Encryption keys and, possibly,= keys for derivation of further re-key material.
K3 is computed from=C2= =A0 both g^{xs} and g^{xy} similarly to K2, but its derivation
will be d= ifferent than K2, e.g., using a separating key expansion technique.

= SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT pr= otocol such as QUIC. In this
case, the client is assumed to have informa= tion about the server's public key
and other security parameters. Th= e server is assumed to have some mechanism in
place for detecting replay= (e.g., via timestamps, stored client nonces, etc.).
The resulting proto= col is as described above where the ClientData field is sent
encrypted u= nder key K0 derived from g^{xs}.=C2=A0
The rest of the protocol is iden= tical to the above.=C2=A0
Note: In this case, ServerCertificate is not = sent as the client had to know
the server's public key before the fi= rst message (one can imagine a setting
where the server may send a diffe= rent certificate in the second message - if
desired, this can be accommo= dated too as an option or extension).

CLIENT AUTHENTICATION:
Client authentication can be supported via an option or extension. It woul= d
include a client certificate for a static DH key g^c sent in the third= message
(the certificate can be encrypted under key K2 to provide clie= nt's identity
protection). In this case, the key for computing the C= lientFinished message and
the application key K3 would be derived from a= combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}). =

NOTES:

Note on Finished messages: The above spec sets Server= Finished as mandatory and
ClientFinished as optional. The latter option = is needed for a 1-RTT protocol.
In principle, both Finished messages cou= ld be omitted and still obtain security
via implicit authentication (ass= uming the inputs to key derivation are chosen
appropriately). But given = the advantages of ServerFinished for providing
explicit authentication, = key confirmation, and active forward secrecy (see
below), it seems advis= able to always include it. Including ClientFinished
provides key confirm= ation from client and also explicit client authentication
when client ce= rtificate is included. ClientFinished also provides Universal
Composable= (UC) security (this is a result of the Canetti-Krawczyk proof that
CK = security implies UC security when a client confirmation step is included).= =C2=A0

Note on certificates: Since in current practice servers hold= certificates for
RSA signature keys rather than for static DH keys, the= certificate field in the
above protocol will be implemented by a pair c= onsisting of (i) the server's RSA
signature certificate and (ii) the= server's signature using this RSA key on the
server's static pu= blic DH key g^s. The latter signature by the server is
performed only wh= en a new static DH key is created (how often this happens and
how many s= uch keys are created is completely up to the server - it has the
advanta= ge that these keys can be changed often to increase security against
lea= ked keys). This use of RSA also enjoys the high efficiency of RSA
verifi= cation for the client.=C2=A0
The handling of Client certificates would = be similar.

Note on forward security (a.k.a. as PFS for Perfect Forw= ard Security):
PFS is provided by the (mandatory) use of ephemeral Diff= ie-Hellman keys.
The meaning of PFS is that an attacker that finds the (= long-term) static
private keys of the parties cannot compromise past ses= sion keys. Without the
ServerFinished message the above protocol ensures= forward secrecy against
passive attackers (i.e., for sessions where the= attacker did not choose g^y).
With ServerFinished, PFS holds also again= st active attackers.=C2=A0 A similar
consideration applies to ClientFini= shed.

Client certificates in the first message: We note that in case= s where client
certificates can be sent in the clear in the first messag= e of the protocol, one
can provide PFS and mutual authentication in a 1-= RTT at essentially the same
cost of an unauthenticated DH exchange (i.e.= , a cost of little more than two
exponentiations). In such a setting one= can also obtain mutual authentication in
a 0-RTT protocol (with forward= secrecy with respect to the client's key).=C2=A0
These options, ho= wever, require HMQV-like mechanisms and may raise IP issues (this
can be= investigated further if the WG is interested).


--001a11c372da1137ac050827b031-- From nobody Tue Nov 18 15:46:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C2C1A876F; Tue, 18 Nov 2014 15:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbTJ3hb0v6gk; Tue, 18 Nov 2014 15:46:20 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 157391ACDC8; Tue, 18 Nov 2014 15:46:10 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id C802327BC065; Tue, 18 Nov 2014 15:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:reply-to:mime-version: content-type; s=cryptonector.com; bh=+bBtdPeYs8uQd7EBUB2zBPGC6cc =; b=W5w8dL1rZorHz/kZpIhlbGvY19W28hoQsRkOZtSs0JJKnQIvb5aq0FcTriG a3iO+KhC3KmPZoRFZSrbJ/K1OmSY/lDVBGB22LscR0ws2upi7EOdyBPlCvlcp69t As+5GZ/98gYe5etkaAx3eeNGay5IwSAH5s+tdOiOuNXVOURc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 802CA27BC064; Tue, 18 Nov 2014 15:46:09 -0800 (PST) Date: Tue, 18 Nov 2014 17:46:08 -0600 From: Nico Williams To: tls@ietf.org Message-ID: <20141118234608.GA20721@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OZwGgVhySbVhU36BMX1elQ9x0GE Cc: kitten@ietf.org Subject: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 23:46:22 -0000 Following up to the OPTLS proposal I thought it'd be interesting to explore the security (API, and other) considerations of 0-RTT protocols. I'm not sure[0] how much this has been done on this list before, so pardon me if this is noisy. My experience with 0-RTT is mostly from GSS [RFC2743] and Kerberos [RFC4120], where the matter was given some explicit treatment treatment many years ago. That treatment is not complete, so this should be relevant to KITTEN WG as well. I'm cc'ing KITTEN WG, but we should continue the discussion on the TLS list; Reply-To: is set. For me the security considerations of 0-RTT have to bleed into APIs in order to be manageable, which for many TLS apps may well be a deal killer (and I suspect it generally is). I.e., I think 0-RTT is generally more trouble than it's worth. 0-RTT means: The handshake might be two or three messages, but the client can send application data immediately after sending its hello, and the server can send application data immediately after consuming the client's hello. This is not a really a new concept[1]. And this concept generalizes to longer exchanges too; the optimization can be less good than 0-RTT but still better than full latency. A client can do 0-RTT handshakes whenever it can obtain a usable session key immediately upon sending the client's first[0] handshake message. 0-RTT could be made available when: - doing session resumption - the client knows the server's pubkey a priori - using PSK Security considerations: - Replay protection (use replay cache or defer protection) Replay protection on the server side requires either a replay cache (which can more than negate the latency of one network round trip), or deferring replay protection availability to the end of the handshake. Deferring replay protection availability requires that the client's first data record(s) be held for delivery until replay protection is available (again, limiting the value of 0-RTT), or that the application be aware of the replay potential. - PFS (not available for 0-RTT data) What about PFS? Can't be done in 0-RTT, but it can become available when each party learns the others' ephemeral (EC)DH key. Again, the application may (likely will) need to know about PFS being deferred, therefore this is an API consideration as well. - Server authentication state Even in the 0-RTT case the client must check that the server's pubkey hasn't been revoked, of course, but either it won't be able to until it receives the server's Hello (where stapled OCSP should be found), or it will have to check certificate status out of band (which has privacy considerations). The problem here is that any application data sent before receiving the server's Hello will be compromised if the server's private key was compromised (even if the cert was revoked). For HTTP(S) this is a problem: the HTTP request may or may not be sensitive, but the HTTP client implementation and TLS can't know if it is -- only the application can know. This might mean that XHR, HTML, need extensions for specifying this. Again, this is an API consideration as well. DANE makes this consideration go away, mostly[2]. - Client authentication state Imagine a handshake where the client is not authenticated until the second round trip, but we have key material for 0-RTT. The server cannot authorize any application protocol commands at this stage. - Symmetric session key non-reuse depends entirely on the client and its RNG. E.g., in the resumption and PSK cases. When using cipher modes where key/IV reuse is disastrous this could be a serious problem. How to do 0-RTT in non-resumption, non-PSK handshakes: - with key transport (the server's static pubkey must be an encryption key) - with key agreement (the server's static pubkey must be an (EC)DH key) PFS can be added, and anyways, it all looks a lot like session resumption. How to learn the server's pubkey prior to making the client Hello? - use DANE - recall the server's pubkey from a previous connection and use it optimistically (as in: it hasn't changed since last time) The latter is the basis of Hugo Krawczyk's OPTLS proposal. [0] I saw the thread starting at: https://www.ietf.org/mail-archive/web/tls/current/msg13298.html but the treatment of the security considerations of 0-RTT there was not exhaustive, unless I missed it. [1] The GSS-API [RFC2743] has supported sending application data early, and has since 1997 [RFC2078]. GSS calls the "ready to send somewhat-protected data" state "prot_ready". Kerberos V [RFC4120] effectively had it even earlier, in 1993 [RFC1510], and probably before then too. [2] Provided one does not object to DANE. Nico -- From nobody Tue Nov 18 16:05:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39131A8AFB for ; Tue, 18 Nov 2014 16:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czHkLn8Op5yY for ; Tue, 18 Nov 2014 16:04:52 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAE71A8706 for ; Tue, 18 Nov 2014 16:04:52 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so74242wiv.14 for ; Tue, 18 Nov 2014 16:04:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4Wkd0oYT4ErK6uNZYv94BlPxnGtMPv0iUmphIgMjMi4=; b=SugSfo7MeIM0aq5shmwuAsoD57CjtLTMsX1UEErjNrsDbj6gvEMSLHFhoZ/vfgQ4Fv KTda4KUvFAG1I2/IjI96ZyHFQpxUl0J0g4CPE+mhmPfnXaEmKEdtSczs40JSqXoYO0qb eD3+JRomfYvGFk0gLOqDIaSgE4Pt6TfEG6H9G6owQlme2p34f+clA/eKpLd2XZ8e4ooj j2XKdMuk9Jr+DzJbgW9Tv6NpyIKGMZ5OdtuWtYDIaqfR2Yj255wiFQrQu36zCWzeZLI3 IUG3OSHS3SuNwmRtENV4p9+iB+SVIZH1RzS3iZqcuuD/c0kbGUaIKFDR5akFXzAIRgpa cveA== X-Gm-Message-State: ALoCoQkTZFYz53XRKdqBzTeHITzyejaoFg+Co1dwdV8RMK5dxD9JRosiG0B5pB7e4hRS3qsI1EjN X-Received: by 10.180.150.138 with SMTP id ui10mr8121882wib.32.1416355490715; Tue, 18 Nov 2014 16:04:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 18 Nov 2014 16:04:10 -0800 (PST) In-Reply-To: <20141118234608.GA20721@localhost> References: <20141118234608.GA20721@localhost> From: Eric Rescorla Date: Tue, 18 Nov 2014 16:04:10 -0800 Message-ID: To: kitten@ietf.org Content-Type: multipart/alternative; boundary=001a11c3fb20e67d2705082af54d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iZdymVMmZR4NiVsftPWkQ_20M1Q Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:04:58 -0000 --001a11c3fb20e67d2705082af54d Content-Type: text/plain; charset=UTF-8 On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams wrote: > > Following up to the OPTLS proposal I thought it'd be interesting to > explore the security (API, and other) considerations of 0-RTT protocols. > I'm not sure[0] how much this has been done on this list before, so pardon > me if this is noisy. > A fair bit, including a complete solution in Snap Start and some handwavy stuff in draft-rescorla-tls13-new-flows-01, as well as the Watson Ladd mail you reference below > Security considerations: > > - Replay protection (use replay cache or defer protection) > > Replay protection on the server side requires either a replay cache > (which can more than negate the latency of one network round trip), > or deferring replay protection availability to the end of the > handshake. > > Deferring replay protection availability requires that the client's > first data record(s) be held for delivery until replay protection is > available (again, limiting the value of 0-RTT), or that the > application be aware of the replay potential. > Yes, I agree that this doesn't make sense. The server needs to provide anti-replay as part of the TLS stack using some sort of server-side state. Servers which don't want to do that should not offer 0-RTT. > - PFS (not available for 0-RTT data) > > What about PFS? Can't be done in 0-RTT, but it can become available > when each party learns the others' ephemeral (EC)DH key. > > Again, the application may (likely will) need to know about PFS being > deferred, therefore this is an API consideration as well. > Yes, we'll need APIs to let the client control whether data should be sent w/o PFS. Note that the we already have a parallel situation with resumption which currently never offers OCSP. - Server authentication state > > Even in the 0-RTT case the client must check that the server's pubkey > hasn't been revoked, of course, but either it won't be able to until > it receives the server's Hello (where stapled OCSP should be found), > or it will have to check certificate status out of band (which has > privacy considerations). > > The problem here is that any application data sent before receiving > the server's Hello will be compromised if the server's private key > was compromised (even if the cert was revoked). > > For HTTP(S) this is a problem: the HTTP request may or may not be > sensitive, but the HTTP client implementation and TLS can't know > if it is -- only the application can know. This might mean that XHR, > HTML, need extensions for specifying this. > I'm not following this. Generally, server 0-RTT keys will probably be fairly short-lived by comparison to OCSP-stapled responses, so you can just continue to use the key within the OCSP window. Remember that if the key is compromised within the OCSP window, then the attacker can attack you with 1-RTT as well as 0-RTT. Again, this is also an issue with resumption. - Client authentication state > > Imagine a handshake where the client is not authenticated until the > second round trip, but we have key material for 0-RTT. The server > cannot authorize any application protocol commands at this stage Every proposal I have ever seen for 0-RTT has the client delivering client auth in the first flight for exactly this reason. - Symmetric session key non-reuse depends entirely on the client and > its RNG. E.g., in the resumption and PSK cases. > > When using cipher modes where key/IV reuse is disastrous this could > be a serious problem. > The conventional way to address this (as in snap start) is to use an anti-replay mechanism which ensures uniqueness of the client random, thus providing key uniqueness. -Ekr --001a11c3fb20e67d2705082af54d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 18, 2014 at 3:46 PM, Nico Williams <nico@cryptonector.com&= gt; wrote:

Following up to the OPTLS proposal I thought it'd be interesting to
explore the security (API, and other) considerations of 0-RTT protocols. I'm not sure[0] how much this has been done on this list before, so par= don
me if this is noisy.

A fair bit, includ= ing a complete solution in Snap Start
and some handwavy stuff in = draft-rescorla-tls13-new-flows-01, as
well as the Watson Ladd mai= l you reference below

=C2=A0
Security considerations:

=C2=A0- Replay protection (use replay cache or defer protection)

=C2=A0 =C2=A0Replay protection on the server side requires either a replay = cache
=C2=A0 =C2=A0(which can more than negate the latency of one network round t= rip),
=C2=A0 =C2=A0or deferring replay protection availability to the end of the<= br> =C2=A0 =C2=A0handshake.

=C2=A0 =C2=A0Deferring replay protection availability requires that the cli= ent's
=C2=A0 =C2=A0first data record(s) be held for delivery until replay protect= ion is
=C2=A0 =C2=A0available (again, limiting the value of 0-RTT), or that the =C2=A0 =C2=A0application be aware of the replay potential.
=

Yes, I agree that this doesn't make sense. The serv= er needs to provide
anti-replay as part of the TLS stack using so= me sort of server-side state.
Servers which don't want to do = that should not offer 0-RTT.

=C2=A0
=C2=A0- PFS (not available for 0-RTT data)

=C2=A0 =C2=A0What about PFS?=C2=A0 Can't be done in 0-RTT, but it can b= ecome available
=C2=A0 =C2=A0when each party learns the others' ephemeral (EC)DH key.
=C2=A0 =C2=A0Again, the application may (likely will) need to know about PF= S being
=C2=A0 =C2=A0deferred, therefore this is an API consideration as well.
<= /blockquote>

Yes, we'll need APIs to let the client = control whether data should be sent
w/o PFS. Note that the we alr= eady have a parallel situation with resumption
which currently ne= ver offers OCSP.


=C2=A0- Server authentication state

=C2=A0 =C2=A0Even in the 0-RTT case the client must check that the server&#= 39;s pubkey
=C2=A0 =C2=A0hasn't been revoked, of course, but either it won't be= able to until
=C2=A0 =C2=A0it receives the server's Hello (where stapled OCSP should = be found),
=C2=A0 =C2=A0or it will have to check certificate status out of band (which= has
=C2=A0 =C2=A0privacy considerations).

=C2=A0 =C2=A0The problem here is that any application data sent before rece= iving
=C2=A0 =C2=A0the server's Hello will be compromised if the server's= private key
=C2=A0 =C2=A0was compromised (even if the cert was revoked).

=C2=A0 =C2=A0For HTTP(S) this is a problem: the HTTP request may or may not= be
=C2=A0 =C2=A0sensitive, but the HTTP client implementation and TLS can'= t know
=C2=A0 =C2=A0if it is -- only the application can know.=C2=A0 This might me= an that XHR,
=C2=A0 =C2=A0HTML, need extensions for specifying this.

I'm not following this. Generally, server 0-RTT keys w= ill probably be fairly
short-lived by comparison to OCSP-stapled = responses, so you can just
continue to use the key within the OCS= P window. Remember that if the
key is compromised within the OCSP= window, then the attacker can
attack you with 1-RTT as well as 0= -RTT. Again, this is also an issue
with resumption.

=C2=A0- Client authentication state

=C2=A0 =C2=A0Imagine a handshake where the client is not authenticated unti= l the
=C2=A0 =C2=A0second round trip, but we have key material for 0-RTT.=C2=A0 T= he server
=C2=A0 =C2=A0cannot authorize any application protocol commands at this sta= ge

Every proposal I have ever seen for 0-RT= T has the client delivering
client auth in the first flight for e= xactly this reason.



=C2=A0- Symmetric session key non-reuse depends entirely on the client and<= br> =C2=A0 =C2=A0its RNG.=C2=A0 E.g., in the resumption and PSK cases.

=C2=A0 =C2=A0When using cipher modes where key/IV reuse is disastrous this = could
=C2=A0 =C2=A0be a serious problem.

The = conventional way to address this (as in snap start) is to use an
= anti-replay mechanism which ensures uniqueness of the client random,
<= div>thus providing key uniqueness.

-Ekr
=
--001a11c3fb20e67d2705082af54d-- From nobody Tue Nov 18 16:45:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058531A8A64; Tue, 18 Nov 2014 16:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up44oVIrt7Ik; Tue, 18 Nov 2014 16:45:46 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B91051A8734; Tue, 18 Nov 2014 16:45:46 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 3D19D36006B; Tue, 18 Nov 2014 16:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=qqEGj5jbqoipyM alsNFxjveQaXY=; b=ZaDmNO2an2WXtfjXpBCMX3E+CbYp9Nsqee6xAT/CayeFqg +AVN06PW+Y84Ny2kBLRuhWMwW/lzWkzreCWhb5JVIO6KyXMnpaJNhW5ulnR0swPZ Q34Ezmqd0DwVfuJlRIAqLqglsbvcCKK+u/buX9IvkBrFUlZJUIcpZAoBTpjMs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id D122536005C; Tue, 18 Nov 2014 16:45:45 -0800 (PST) Date: Tue, 18 Nov 2014 18:45:45 -0600 From: Nico Williams To: Eric Rescorla Message-ID: <20141119004543.GC20758@localhost> References: <20141118234608.GA20721@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BweKEm4QpUOgyRGH5-OVsmYZjrQ Cc: kitten@ietf.org, "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:45:48 -0000 On Tue, Nov 18, 2014 at 04:04:10PM -0800, Eric Rescorla wrote: > On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams > wrote: > > - Replay protection (use replay cache or defer protection) > > [...] > > Yes, I agree that this doesn't make sense. The server needs to provide > anti-replay as part of the TLS stack using some sort of server-side state. > Servers which don't want to do that should not offer 0-RTT. But how would the client know the first time? Perhaps it shouldn't matter. The server should just hold back before delivering the data. Still, in order to do this without a replay cache the handshake has to have two more messages after the one where the client is prot_ready and the client has to confirm the early messages. So this has to be part of the protocol. > - Server authentication state > > > > Even in the 0-RTT case the client must check that the server's pubkey > > hasn't been revoked, of course, but either it won't be able to until > > it receives the server's Hello (where stapled OCSP should be found), > > or it will have to check certificate status out of band (which has > > privacy considerations). > > > > The problem here is that any application data sent before receiving > > the server's Hello will be compromised if the server's private key > > was compromised (even if the cert was revoked). > > > > For HTTP(S) this is a problem: the HTTP request may or may not be > > sensitive, but the HTTP client implementation and TLS can't know > > if it is -- only the application can know. This might mean that XHR, > > HTML, need extensions for specifying this. > > > > I'm not following this. Generally, server 0-RTT keys will probably be fairly > short-lived by comparison to OCSP-stapled responses, so you can just > continue to use the key within the OCSP window. Remember that if the > key is compromised within the OCSP window, then the attacker can > attack you with 1-RTT as well as 0-RTT. Again, this is also an issue > with resumption. Yes, this is a general problem that can only really be addressed via key freshness. > - Client authentication state > > > > Imagine a handshake where the client is not authenticated until the > > second round trip, but we have key material for 0-RTT. The server > > cannot authorize any application protocol commands at this stage > > Every proposal I have ever seen for 0-RTT has the client delivering > client auth in the first flight for exactly this reason. Even ones where the client is afforded confidentiality for its ID? I can certainly imagine protocols where that wouldn't be the case. > - Symmetric session key non-reuse depends entirely on the client and > > its RNG. E.g., in the resumption and PSK cases. > > > > When using cipher modes where key/IV reuse is disastrous this could > > be a serious problem. > > > > The conventional way to address this (as in snap start) is to use an > anti-replay mechanism which ensures uniqueness of the client random, > thus providing key uniqueness. By the time the server can check this it's too late: the client sent the bad ciphertext. Nico -- From nobody Wed Nov 19 11:24:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAE01A1F70 for ; Wed, 19 Nov 2014 11:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZpHeAfvZquE for ; Wed, 19 Nov 2014 11:23:58 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7A61A1BE9 for ; Wed, 19 Nov 2014 11:23:57 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so1669414wgg.36 for ; Wed, 19 Nov 2014 11:23:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XVVfgFSKJnF8xHNTXlDEs9Sj6idT05R6SR01RmhcMvM=; b=aawBR3PLQhWIwNqgKdkZGfId9obsr40H1EML321oFPnubJ4lm7EmNTfAH3b+LZxW5z xr6VDTuzyBWdfhRC482qDKZvzqFr4dP827eplc6pWawQRRMDhGEyMzvAR40ovb+oTbV4 +piH92StI+q2+OLOFopa/RmwUWPh2TeVVwxs34uKW9S4cvqSV+Sda0cHeJzC5z3+gVvR b460L45ELc5xUfOEX8ogSjgW2UP6YmfYedA9ZDJki3ODBvnH/VJZ55bqgwSceuEgmRsl RAJtcyREmdgDJzWubM2bGTLo5LcIgWktUifIqj8gdZ+6N1TCmaM9dSPeJXE2RO8kjvvP lmIA== X-Gm-Message-State: ALoCoQmadRIC1M/QTXH5JQOgEfIpkG/If+FcRTOSX7SzqR2AkVnunGUQLdvY9DR87DhKhwbXW6cd X-Received: by 10.194.176.198 with SMTP id ck6mr59385597wjc.25.1416425036590; Wed, 19 Nov 2014 11:23:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 19 Nov 2014 11:23:16 -0800 (PST) In-Reply-To: <20141119004543.GC20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> From: Eric Rescorla Date: Wed, 19 Nov 2014 11:23:16 -0800 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=089e013d191628396c05083b2722 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9Mws3hWNdDWimrrhoVjkAnJxnWg Cc: kitten , "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:24:00 -0000 --089e013d191628396c05083b2722 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams wrote: > On Tue, Nov 18, 2014 at 04:04:10PM -0800, Eric Rescorla wrote: > > On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams > > wrote: > > > - Replay protection (use replay cache or defer protection) > > > [...] > > > > Yes, I agree that this doesn't make sense. The server needs to provide > > anti-replay as part of the TLS stack using some sort of server-side > state. > > Servers which don't want to do that should not offer 0-RTT. > > But how would the client know the first time? Perhaps it shouldn't > matter. The server should just hold back before delivering the data. > Still, in order to do this without a replay cache the handshake has to > have two more messages after the one where the client is prot_ready and > the client has to confirm the early messages. So this has to be part of > the protocol. I'm not following. The idea here is that the server indicates to the client that it is in principle prepared to do 0-RTT and provides a key that can be used for that. If the client attempts it and it doesn't work out (e.g., because the server has lost the key), you fall back to a 1-RTT handshake, so the server can just discard the data rather than holding it. > > - Client authentication state > > > > > > Imagine a handshake where the client is not authenticated until the > > > second round trip, but we have key material for 0-RTT. The server > > > cannot authorize any application protocol commands at this stage > > > > Every proposal I have ever seen for 0-RTT has the client delivering > > client auth in the first flight for exactly this reason. > > Even ones where the client is afforded confidentiality for its ID? I can certainly imagine protocols where that wouldn't be the case. If you can send encrypted data to the server, you can also encrypt the client's certificate. Yes, it's possible to design protocols where that doesn't work, but it's also possible to design ones where it does. > - Symmetric session key non-reuse depends entirely on the client and > > > its RNG. E.g., in the resumption and PSK cases. > > > > > > When using cipher modes where key/IV reuse is disastrous this could > > > be a serious problem. > > > > > > > The conventional way to address this (as in snap start) is to use an > > anti-replay mechanism which ensures uniqueness of the client random, > > thus providing key uniqueness. > > By the time the server can check this it's too late: the client sent the > bad ciphertext. Good point. I agree that the client needs a strong PRNG. -Ekr --089e013d191628396c05083b2722 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Tue, Nov 18, 2014 at= 04:04:10PM -0800, Eric Rescorla wrote:
> On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> >=C2=A0 - Replay protection (use replay cache or defer= protection)
> >=C2=A0 =C2=A0 [...]
>
> Yes, I agree that this doesn't make sense. The server needs to pro= vide
> anti-replay as part of the TLS stack using some sort of server-side st= ate.
> Servers which don't want to do that should not offer 0-RTT.

But how would the client know the first time?=C2=A0 Perhaps it shoul= dn't
matter.=C2=A0 The server should just hold back before delivering the data.<= br> Still, in order to do this without a replay cache the handshake has to
have two more messages after the one where the client is prot_ready and
the client has to confirm the early messages.=C2=A0 So this has to be part = of
the protocol.

I'm not following. The id= ea here is that the server indicates to the
client that it is in = principle prepared to do 0-RTT and provides a key
that can be use= d for that. If the client attempts it and it doesn't work
out= (e.g., because the server has lost the key), you fall back to a
= 1-RTT handshake, so the server can just discard the data rather
t= han holding it.

=C2=A0
>=C2=A0 - Client authentication state
> >
> >=C2=A0 =C2=A0 Imagine a handshake where the client is not authenti= cated until the
> >=C2=A0 =C2=A0 second round trip, but we have key material for 0-RT= T.=C2=A0 The server
> >=C2=A0 =C2=A0 cannot authorize any application protocol commands a= t this stage
>
> Every proposal I have ever seen for 0-RTT has the client delivering > client auth in the first flight for exactly this reason.

Even ones where the client is afforded confidentiality for its ID? I=
can certainly imagine protocols where that wouldn't be the case.

If you can send encrypted data to the server, you= can also
encrypt the client's certificate. Yes, it's pos= sible to design protocols
where that doesn't work, but it'= ;s also possible to design ones where
it does.


>=C2=A0 - Symmetric session key non-reuse depends entirely on the client= and
> >=C2=A0 =C2=A0 its RNG.=C2=A0 E.g., in the resumption and PSK cases= .
> >
> >=C2=A0 =C2=A0 When using cipher modes where key/IV reuse is disast= rous this could
> >=C2=A0 =C2=A0 be a serious problem.
> >
>
> The conventional way to address this (as in snap start) is to use an > anti-replay mechanism which ensures uniqueness of the client random, > thus providing key uniqueness.

By the time the server can check this it's too late: the client = sent the
bad ciphertext.

Good point. I agree that th= e client needs a strong PRNG.

-Ekr

<= /div>
--089e013d191628396c05083b2722-- From nobody Wed Nov 19 12:51:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC021A1BEE; Wed, 19 Nov 2014 12:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6y9wLwmA4O3; Wed, 19 Nov 2014 12:51:36 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED91A1B04; Wed, 19 Nov 2014 12:51:36 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id DD1C050808D; Wed, 19 Nov 2014 12:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yI0oTI0J4o8JM3 ZkFokaoQOIKy0=; b=PXdk+rNY28KfOdjf7dlXSpVCDBHKh4A/QBB6b7eEDO6wqh rXP/2C6VOfmMsf+I4zD6YtG3AsAwUq4siAw3KdmFlvhyEqzLy/fLYkAiiVdaBSdi Il7YcsNDyn6r1Zd5ZGQj/seldZe+0AsxYGHwphuYPsqOc2DXe9w22BxYY6yNI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 7919D50808C; Wed, 19 Nov 2014 12:51:35 -0800 (PST) Date: Wed, 19 Nov 2014 14:51:19 -0600 From: Nico Williams To: Eric Rescorla Message-ID: <20141119205117.GE20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t6IPPSCADs217mEolB7QzC5FVlU Cc: kitten , "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 20:51:37 -0000 On Wed, Nov 19, 2014 at 11:23:16AM -0800, Eric Rescorla wrote: > On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams > wrote: > > > Yes, I agree that this doesn't make sense. The server needs to > > > provide anti-replay as part of the TLS stack using some sort of > > > server-side state. Servers which don't want to do that should not > > > offer 0-RTT. > > > > But how would the client know the first time? [...] > > I'm not following. The idea here is that the server indicates to the > client that it is in principle prepared to do 0-RTT and [...] Certainly in the resumption case. However, in other cases, we'd have to have ensure that whatever oob method is used for establishing the server's public key also conveys this (e.g., we'd need an RR type for indicating this for DANE). It's much easier to have the server hold the early data and have it bound into the client's next handshake msg. > > > - Client authentication state > > > > > > > > Imagine a handshake where the client is not authenticated until the > > > > second round trip, but we have key material for 0-RTT. The server > > > > cannot authorize any application protocol commands at this stage > > > > > > Every proposal I have ever seen for 0-RTT has the client delivering > > > client auth in the first flight for exactly this reason. > > > > Even ones where the client is afforded confidentiality for its ID? I > > can certainly imagine protocols where that wouldn't be the case. Sure, so can I. I was describing generic 0-RTT security considerations. If a specific protocol addresses one of those completely, great. > If you can send encrypted data to the server, you can also > encrypt the client's certificate. Yes, it's possible to design protocols > where that doesn't work, but it's also possible to design ones where > it does. Yes, of course. With TLS 1.2 one can renego. Unless I missed something, there's nothing in 1.3 for protecting the client's ID. With DANE one could definitely authenticate the client in a 0-RTT way, at least if the server has either a public encryption key or a public key agreement key. SSHv2, OTOH, is an example of a protocol where key exchange completes prior to authenticating the user, so in principle one could extend it to send "early data" and run into this security consideration. But this is mostly because SSHv2 is so... shockingly under-optimized as to round trips... so perhaps I was reaching with this consideration :) > > [...] > Good point. I agree that the client needs a strong PRNG. Yes, and perhaps it's just not worth pointing out all the ways in which not having a good RNG is bad. We take the need for a good RNG as a given nowadays... (though we should consider ways to minimize dependence on strong RNGs, see, e.g., EdDSA). Nico -- From nobody Thu Nov 20 09:07:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E171A1A07BC for ; Thu, 20 Nov 2014 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD6TadDpp6x4 for ; Thu, 20 Nov 2014 09:07:09 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687951A1A2E for ; Thu, 20 Nov 2014 09:07:03 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so4300333wgg.7 for ; Thu, 20 Nov 2014 09:07:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NT5QxIvyH6ixv+9MrbsAYu7PoHGko9cNjIfYMj23yWo=; b=JSAIlrXuPx8k9dsW6+x84bDvmZn/9KMLW4TPu/kjLGtDvl4QfcTqtNaIMOGKHvjJv1 9o4oPp+PRYIJNjg6fssz/ANl3/QZCRI7PEKdnR2/00UlEOC4yEvEpCKpBYio9/rKq5Rl anryIoNIQYOaStooDoiRMG5XRs1+XSL5kjjEfxSCz4GuzDykKokJuAZ7v+JC++4lSt3z J4NoKfnfojsoeJsTJOjnpvfqZIFIjmPFtIJiKC7JIPlCTc7p8/K9uSXUaj2GPvpWHpi7 muDicivOHPMaYepkgNoclPFl1Hh3FDwVfDSDxa1DSrUF3uA7upwyP1D9cnh1YsF9uO5w eMMA== X-Gm-Message-State: ALoCoQntoiB+zbQDc4t/8vnyFQ9nMG/QAsxRVooVSOmkZT+ApGAa8Sa548v21UhQdmlfWW4BQwVZ X-Received: by 10.180.150.138 with SMTP id ui10mr5927417wib.32.1416503221601; Thu, 20 Nov 2014 09:07:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Thu, 20 Nov 2014 09:06:21 -0800 (PST) In-Reply-To: <20141119205117.GE20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> <20141119205117.GE20758@localhost> From: Eric Rescorla Date: Thu, 20 Nov 2014 09:06:21 -0800 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c3fb2058d4c705084d5b16 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2NXsXAR0stmTWlov26jN_PnAV7Y Cc: kitten , "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:07:12 -0000 --001a11c3fb2058d4c705084d5b16 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams wrote: > On Wed, Nov 19, 2014 at 11:23:16AM -0800, Eric Rescorla wrote: > > On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams > > wrote: > > > > Yes, I agree that this doesn't make sense. The server needs to > > > > provide anti-replay as part of the TLS stack using some sort of > > > > server-side state. Servers which don't want to do that should not > > > > offer 0-RTT. > > > > > > But how would the client know the first time? [...] > > > > I'm not following. The idea here is that the server indicates to the > > client that it is in principle prepared to do 0-RTT and [...] > > Certainly in the resumption case. Also in the semi-static DHE cases. > However, in other cases, we'd have to > have ensure that whatever oob method is used for establishing the > server's public key also conveys this (e.g., we'd need an RR type for > indicating this for DANE). I don't see that that's a problem. At present DANE doesn't contain enough information for the client to generate a 0-RTT handshake at all, so as a practical matter we would need to extend the record format, so that would implicitly agree to 0-RTT (or explicitly if you prefer). > It's much easier to have the server hold the > early data and have it bound into the client's next handshake msg. This is not generically possible, because the client may have used a key that the server has forgotten, which requires the client to retransmit. > If you can send encrypted data to the server, you can also > > encrypt the client's certificate. Yes, it's possible to design protocols > > where that doesn't work, but it's also possible to design ones where > > it does. > > Yes, of course. With TLS 1.2 one can renego. Unless I missed > something, there's nothing in 1.3 for protecting the client's ID. > In TLS 1.3, the client's second flight is sent encrypted. If it were sent as part of the first flight, it would also be sent encrypted. -Ekr --001a11c3fb2058d4c705084d5b16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Wed, = Nov 19, 2014 at 11:23:16AM -0800, Eric Rescorla wrote:
> On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> > > Yes, I agree that this doesn't make sense. = The server needs to
> > > provide anti-replay as part of the TLS stack using some sort= of
> > > server-side state.=C2=A0 Servers which don't want to do = that should not
> > > offer 0-RTT.
> >
> > But how would the client know the first time?=C2=A0 [...]<= br> >
> I'm not following. The idea here is that the server indicates to t= he
> client that it is in principle prepared to do 0-RTT and [...]
Certainly in the resumption case.

Also in = the semi-static DHE cases.

=C2=A0
However, in other cases, we'd have to
have ensure that whatever oob method is used for establishing the
server's public key also conveys this (e.g., we'd need an RR type f= or
indicating this for DANE).

I don't see = that that's a problem. At present DANE doesn't contain enough
=
information for the client to generate a 0-RTT handshake at all, so as=
a practical matter we would need to extend the record format, so= that
would implicitly agree to 0-RTT (or explicitly if you prefe= r).

=C2=A0
=C2= =A0 It's much easier to have the server hold the
early data and have it bound into the client's next handshake msg.

This is not generically possible, because the c= lient may have used
a key that the server has forgotten, which re= quires the client to
retransmit.


> If you can send encrypted data to the server, you can also
> encrypt the client's certificate. Yes, it's possible to design= protocols
> where that doesn't work, but it's also possible to design ones= where
> it does.

Yes, of course.=C2=A0 With TLS 1.2 one can renego.=C2=A0 Unless I mi= ssed
something, there's nothing in 1.3 for protecting the client's ID.

In TLS 1.3, the client's second flig= ht is sent encrypted. If it were sent
as part of the first flight= , it would also be sent encrypted.

-Ekr
=

--001a11c3fb2058d4c705084d5b16-- From nobody Thu Nov 20 15:18:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F441A8733 for ; Thu, 20 Nov 2014 15:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPfc_jJYDGja for ; Thu, 20 Nov 2014 15:18:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 505B91A19FC for ; Thu, 20 Nov 2014 15:18:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DA2FF181C8E; Thu, 20 Nov 2014 15:17:23 -0800 (PST) To: rohit@4K-associates.com, lawrence@agranat.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, joe@salowey.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141120231723.DA2FF181C8E@rfc-editor.org> Date: Thu, 20 Nov 2014 15:17:23 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cLYfnpYpypTEghsmn4PGbf0Ui6I Cc: fielding@gbiv.com, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC2817 (4187) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 23:18:23 -0000 The following errata report has been submitted for RFC2817, "Upgrading to TLS Within HTTP/1.1". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2817&eid=4187 -------------------------------------- Type: Technical Reported by: Roy T. Fielding Section: 7.2 Original Text ------------- The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey the production for 'product': product = token ["/" product-version] product-version = token [...] This specification defines the protocol token "TLS/1.0" as the identifier for the protocol specified by The TLS Protocol [6]. Corrected Text -------------- The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey the production for 'product': product = token ["/" product-version] product-version = token [...] This specification defines the product token "TLS" as the identifier for the protocol specified by The TLS Protocol [6]. When a specific version of TLS is desired, it is indicated by appending a slash ("/") and the TLS version number as the product-version (e.g., "TLS/1.0"). Notes ----- This erratum clarifies that "TLS" is the product token and any TLS version number (currently DIGIT "." DIGIT) is the product-version token. This has already been corrected in the Upgrade Token Registry. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2817 (draft-ietf-tls-http-upgrade-05) -------------------------------------- Title : Upgrading to TLS Within HTTP/1.1 Publication Date : May 2000 Author(s) : R. Khare, S. Lawrence Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Nov 21 07:43:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74D11AD4EC for ; Fri, 21 Nov 2014 07:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.496 X-Spam-Level: X-Spam-Status: No, score=-9.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DSACOlTcMNx for ; Fri, 21 Nov 2014 07:43:46 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87B81A1A4D for ; Fri, 21 Nov 2014 07:43:30 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sALFhSc7019425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Nov 2014 10:43:28 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sALFhP68028731 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 10:43:27 -0500 Message-ID: <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Alfredo Pironti Date: Fri, 21 Nov 2014 16:43:25 +0100 In-Reply-To: References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xovf_NLVnHdn35InjTRiytuK5ig Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:43:54 -0000 On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote: > Yes, I agree this is a fair point. I'll complete the wording tomorrow > in the pending PR, and these ideas will get into the updated version. Some additional comments: 1. It has quite awkward structure. The main body of the document is at the introduction section. 2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be permitted." Not sure I understand what it means. Does it mean that fallback to SSL 3.0 from any version of TLS MUST NOT be permitted? 3. The document doesn't provide any instructions for clients that have no other way to communicate with a server that only supports SSL 3.0. MUST NOT is nice in theory, but can only be enforced on the systems one has control on, and if the advise is followed to the letter legacy systems (not talking of web) will be only be accessible in plaintext. I'd expect prohibiting the fallback dance instead, and requiring that SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the clientHello. regards, Nikos From nobody Fri Nov 21 07:51:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156911A1A84 for ; Fri, 21 Nov 2014 07:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03muEhwIaPDx for ; Fri, 21 Nov 2014 07:51:12 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B408D1A1A62 for ; Fri, 21 Nov 2014 07:51:12 -0800 (PST) Received: by mail-yk0-f181.google.com with SMTP id 142so2368243ykq.26 for ; Fri, 21 Nov 2014 07:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=DRC+VFKGu75FbVtUOJmPe60l+2KTa+bwOQXd3BgiX2s=; b=KEXHuz/M+kOapgZy78/VuwoHAU8cwJWceeWVS0sX0VuVCRfv2LJ3DSp3Txk4xLy5Qw C8VY+9hjmll7GNj3xZ94vCG4puQVo5brT7m8wcrDJPbn5efgByucOpzTlB5uymciLozi Z73VUIwkCf1ArmmpQvZQWrhgj/jw3kE2maexJXC1/d2MAfYI0n2MIhorQqlHxMk/jGP2 uZZeNx9yw0aar7ta34ElQBLkcgKCKXN1ae2ZdwQMUxQhoALvKpq9yFdIZ0ave5QzrMM9 L3gJEHv8eOoVKTzl2XiORVs3H91a3D0LwiBEn7MHIABSMj9viRmVqQzapzyGwcbW1LEj wH1Q== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr2604938yho.172.1416585071971; Fri, 21 Nov 2014 07:51:11 -0800 (PST) Received: by 10.170.195.21 with HTTP; Fri, 21 Nov 2014 07:51:11 -0800 (PST) Date: Fri, 21 Nov 2014 07:51:11 -0800 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lTN8TIfv_fXy84mChKvi_b6ZX8Y Cc: "tls@ietf.org" , Alfredo Pironti Subject: Re: [TLS] Deprecating TLS 1.3 (was SSL v3.0) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:51:15 -0000 On Fri, Nov 21, 2014 at 7:43 AM, Nikos Mavrogiannopoulos wrote: > On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote: > > >> Yes, I agree this is a fair point. I'll complete the wording tomorrow >> in the pending PR, and these ideas will get into the updated version. > > Some additional comments: > 1. It has quite awkward structure. The main body of the document is at > the introduction section. > > 2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be > permitted." > Not sure I understand what it means. Does it mean that fallback to SSL > 3.0 from any version of TLS MUST NOT be permitted? > > 3. The document doesn't provide any instructions for clients that have > no other way to communicate with a server that only supports SSL 3.0. > MUST NOT is nice in theory, but can only be enforced on the systems one > has control on, and if the advise is followed to the letter legacy > systems (not talking of web) will be only be accessible in plaintext. > I'd expect prohibiting the fallback dance instead, and requiring that > SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the > clientHello. Let this be a moral: it never matters how broken a protocol is, someone, somewhere, will resist turning it off. We need to get TLS 1.3 right. But I don't think taking a hacksaw to TLS 1.2 helps with that nearly as much as everyone seems to think. Sincerely, Watson Ladd > > regards, > Nikos > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Nov 21 08:22:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FAF1A1A7D for ; Fri, 21 Nov 2014 08:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VgCPIkot2v2 for ; Fri, 21 Nov 2014 08:22:07 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD551A0AFE for ; Fri, 21 Nov 2014 08:22:06 -0800 (PST) Received: from BY2FFO11FD060.protection.gbl (10.1.14.33) by BY2FFO11HUB051.protection.gbl (10.1.15.229) with Microsoft SMTP Server (TLS) id 15.1.6.13; Fri, 21 Nov 2014 16:22:03 +0000 Received: from mx02.five9.com (198.105.204.3) by BY2FFO11FD060.mail.protection.outlook.com (10.1.15.184) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Fri, 21 Nov 2014 16:22:03 +0000 Received: from MB01.five9.com (10.7.8.141) by mx02.five9.com (10.7.15.112) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Nov 2014 08:21:28 -0800 Received: from MB02.five9.com ([fe80::ede6:8312:5207:4046]) by mb01.five9.com ([fe80::ddc6:159a:f53:8ee7%15]) with mapi id 14.03.0158.001; Fri, 21 Nov 2014 08:22:01 -0800 From: Ronald del Rosario To: Nikos Mavrogiannopoulos , Alfredo Pironti Thread-Topic: [TLS] Deprecating SSLv3 Thread-Index: AQHQAco2e4qtTz+EvUazdX0Ck5kotZxkWiWAgAdsKID//4SnAA== Date: Fri, 21 Nov 2014 16:22:01 +0000 Message-ID: References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.7.8.112] Content-Type: multipart/related; boundary="_004_D094A69018053rrosariofive9com_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:198.105.204.3; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(438002)(24454002)(199003)(189002)(377424004)(377454003)(30436002)(66926002)(19580405001)(95666004)(84326002)(83506001)(15975445006)(6806004)(107046002)(106116001)(31966008)(20776003)(53416004)(16236675004)(19580395003)(36756003)(64706001)(2656002)(17760045003)(67866002)(87936001)(4396001)(50986999)(92566001)(92726001)(21056001)(99936001)(76176999)(86362001)(93886004)(46102003)(77156002)(77096003)(180100001)(18206015028)(512954002)(71186001)(44976005)(120916001)(62966003)(99396003)(54356999)(106466001)(19627595001)(19617315012)(7099021)(85436002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB051; H:mx02.five9.com; FPR:; MLV:ovrnspm; PTR:mx02.five9.com; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB051; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(1)(2); SRVR:BY2FFO11HUB051; X-Forefront-PRVS: 0402872DA1 Received-SPF: Pass (protection.outlook.com: domain of five9.com designates 198.105.204.3 as permitted sender) receiver=protection.outlook.com; client-ip=198.105.204.3; helo=mx02.five9.com; Authentication-Results: spf=pass (sender IP is 198.105.204.3) smtp.mailfrom=rrosario@five9.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB051; X-OriginatorOrg: five9.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A7sEdEcUrrBRfG-cT0vgvtwyQSo Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:22:10 -0000 --_004_D094A69018053rrosariofive9com_ Content-Type: multipart/alternative; boundary="_000_D094A69018053rrosariofive9com_" --_000_D094A69018053rrosariofive9com_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3. The document doesn't provide any instructions for clients that have no other way to communicate with a server that only supports SSL 3.0. MUST NOT is nice in theory, but can only be enforced on the systems one has control on, and if the advise is followed to the letter legacy systems (not talking of web) will be only be accessible in plaintext. I'd expect prohibiting the fallback dance instead, and requiring that SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the clientHello. +1 Ron F. del Rosario Information Security Officer [cid:C1FFC277-777B-42EE-B330-35D87AA7FD50] Five9, Inc. Cloud Contact Center Software From: Nikos Mavrogiannopoulos > Date: Friday, November 21, 2014 at 7:43 AM To: Alfredo Pironti > Cc: "tls@ietf.org" > Subject: Re: [TLS] Deprecating SSLv3 On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote: Yes, I agree this is a fair point. I'll complete the wording tomorrow in the pending PR, and these ideas will get into the updated version. Some additional comments: 1. It has quite awkward structure. The main body of the document is at the introduction section. 2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be permitted." Not sure I understand what it means. Does it mean that fallback to SSL 3.0 from any version of TLS MUST NOT be permitted? 3. The document doesn't provide any instructions for clients that have no other way to communicate with a server that only supports SSL 3.0. MUST NOT is nice in theory, but can only be enforced on the systems one has control on, and if the advise is followed to the letter legacy systems (not talking of web) will be only be accessible in plaintext. I'd expect prohibiting the fallback dance instead, and requiring that SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the clientHello. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_D094A69018053rrosariofive9com_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
3. The document doesn't provide any = instructions for clients that have
no other way to communicate with a s= erver that only supports SSL 3.0.
MUST NOT is nice in theory, but can = only be enforced on the systems one
has control on, and if the advise is= followed to the letter legacy
systems (not talking of web) will be= only be accessible in plaintext.
I'd expect prohibiting the fallback = dance instead, and requiring that
SSL 3.0 is negotiated only if TLS 1.= 0 or later are advertised in the
clientHello.

+1

= Ron F. de= l Rosario

I= nformation Security Officer

<= br>



Five9, Inc. 
Cloud Contact Center Software 

From: Nikos Mavrogiannopoulos <<= a href=3D"mailto:nmav@redhat.com">nmav@redhat.com>
Date: Friday, November 21, 2014 at = 7:43 AM
To: Alfredo Pironti <alfredo@pironti.eu>
Cc: "tls@ietf.org" <tls@ietf.= org>
Subject: Re: [TLS] Deprecating SSLv= 3

On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote:


Yes, I agree this is a fair point. I'll complete the wording tomorrow<= /div>
in the pending PR, and these ideas will get into the updated version.<= /div>

Some additional comments:
1. It has quite awkward structure. The main body of the document is at=
the introduction section.

2. The text "Negotiation of SSLv3 from any version of TLS MUST NO= T be
permitted."
Not sure I understand what it means. Does it mean that fallback to SSL=
3.0 from any version of TLS MUST NOT be permitted?

3. The document doesn't provide any instructions for clients that have=
no other way to communicate with a server that only supports SSL 3.0.<= /div>
MUST NOT is nice in theory, but can only be enforced on the systems on= e
has control on, and if the advise is followed to the letter legacy
systems (not talking of web) will be only be accessible in plaintext.<= /div>
I'd expect prohibiting the fallback dance instead, and requiring that<= /div>
SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the
clientHello.

regards,
Nikos



_______________________________________________
TLS mailing list



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.
--_000_D094A69018053rrosariofive9com_-- --_004_D094A69018053rrosariofive9com_ Content-Type: image/png; name="063218CA-78F5-4C87-B33F-1AF1081079A5.png" Content-Description: 063218CA-78F5-4C87-B33F-1AF1081079A5.png Content-Disposition: inline; filename="063218CA-78F5-4C87-B33F-1AF1081079A5.png"; size=4841; creation-date="Fri, 21 Nov 2014 16:22:00 GMT"; modification-date="Fri, 21 Nov 2014 16:22:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEsAAAAoCAYAAAC2LgceAAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAIY0lEQVRo BdVazXITRxCenhWB3JwniLhhKgf5mAIT+QkwDwCWnsDC5G77ntjyE2gND4D8BF4wVI44VSnMDfEE 0Q0StNv5enZnNftnW2KFyVStpqenZ6ant7une1bEzOpbLLd/P1lniu4zU4tItfI8guuxUhxopV+w DodnvfYoT1N3m74lYa30g6VPke5BEJuk1NJsm2Vfad5dpNC+GWGJJkXEg9mFlBUpBN3/Xke7b3pt aF69Rdc73XyzLe+9GDDx8wsFRRTE5le9DubofQz18U/9oGC61aMu13PlmiWCUoo65eyyT6yPrnth kNcUEcYk0hsQzjrGNvPjRagNHa391Wuf5vvmbV+psKoFxf4NzY/zAqra5PLeSYcV7+c1UwRGOlqp y49dmbBu753AkfO+KwCzuSh6cPZrO3Dxl4HN4cDec8Xcdulx2J++e3JvxcXNC1+JsJb7QVNF+r3L dF1mU6Gtu2db93bc9eaBr8TBc0QZjRLG6/IvZ1u/dEWbXGHgRWyK5rm4eeCvqlnC8Gc44zDSb3LM 1vLm7ZyiuYw1XB8GgfUpio4sjddQ41md/8KEFQeY3jqr6D5Ou7bLuGU4qUcwkZs53Bc3l/de7mCS 7Ysmgt8cktJHN5AFXHSg1G6GIiRh9KPxSRJk0vo5glLoP7hoQ/P039BR/zLjhD+kTQPhNxFw5bBa NUtiH5jYc6zWrFwx14FN/XDRG80NuXTz1t4LBLoijMsX8XcNL+qWmWhtmiWxDoLEY7DVPIe1Efrk MUUYW5SgZAEI6s94JWlQ4D7wYeO0zwEkaZd9yH4ctAEbecQ87eXfgrbSWvK6TBGGCD5BRXyYj51i LfRamQF1N3TkU+idvn2yOiybOuaBNjnnKmK3wQPkq2N37Bebofgosfd4gSlLxnEiCq8rep7OXD8U n56EDCBrsvKy3ZDmizXrY0SiUUvZLbD/DvFOFvfttpIX+uDW3ktJmXqWU9nXJNQDtE0GQOruox3b OUvNJ4c7ifkdZ8exL4FhFnd1LTeEIdLpS8U93inyxoO85pdnANQ921r1Sd15CG2buYz41dObJROP cLqtLNJpz8Kp9aUY06wah833323de+z2L++fHOdyTBMLznsaGocpjtFdBEfOQi7dsmtcrmVOM33h 6YwTU/Xilz6d16MwIzz0NOVycj5hER/JWxObtkvgDY1FVW37KmvjsHM3GufzQx03IJUYSw4od4x8 Dyg6eKJdl6gUnngjJSMjldLiJBmV0l4FMqJt90UKC+Dv8XUd+uIiyswTL1uS7b51IZICIbJPLUc+ nBSEJY77Mvujte6SmkyClDZqjNXWqqLVh+0UJ8CkMeI/BqMMLmnQz92makyabh+fPAvctpmPaQO4 Jp4WNjDC1seAj9Q1z+fjgcCZksRNKU4E9XZrtW8REvNB+9bcZFuE+0/otUEzFDrJFfHxZCCwFAlW 5zNDGT2ZtBQTHGHyUBhfuzBtpzjp88JtIS8t0mfHm1rFc4BYBEl3H8XzK9UBqo1nCT2tBN5Xn8P3 oOmhnRYJNF2tYrgHV1CWUE5BEzBbBGp8B5C5TbEaZttSzy8sdxYXZnXoNgF3jBbmkAluPYPmOKmm O90WhPwGfe1Mf7GxBNQ+BJZqQDiZ+lEhJ6LT4jCLoQ8Wukxdu7D49VMfC48zi/8bZoUinTFONmvL WH3nDY0QKTwG0u1LaPgUwChpuFUnr2G2E/FUy8LFmn8s4qoxBZ9lVL+aHrqqDhOBnEflo7OXEhBv AhacW+67DcDG/yRakhWUHDoN3bf+KfZjYrLGJO002xC037q/cfopsihQQOhy3583RTFXGFZnSinQ 9JCSYDZveAVhYURbhlUWTS8q+2xH6B3AjKbCwqbEB1lHH2uP+YRlRyiFMcbhe8Y/TfGsuvzq0J8i 8L5wCGCONfgsMdVm0ocDJ+rB1+wgqAzcoJIRRiA0WFJIrG9A6z9FcimpJbXJFh0GFmGcPcHjJUVu SGo3Q5nbCIXjU8UuphpRJ4WLZhmYMV7BXIMqLTZaxtPQxczNciuLEoa7ps7+bMtHEpxwf4PD0nzW TX0krsoMJxWUaVaGZu6Gx4cqciJ85g3MtZPMl2VkeijkfUh8IlYxQQxTcfUjNksJDZAU99HjaHfV JBAdtI3wPwlLkZhgx7allvv7grCQ87mru/Qzwfzy2RD+Z4RBzWRg05xy38FBU8YEx472tBJaW8lY eSpKNauS78FXfYgUFwLU/GQaadpb5184n4pfn0byAhZihikzRIcpLACFm/AznSzOuYPn3CmaIZy9 IU4dfxK5KUEp9McXv1OYBTeorvM30b2ijktHLOPxuc5F1g5PtJ8LStfBNLTH0QihsUXjGpinKQbQ 0MKcwC1tWc08zqOT4LIv+OQ2ISUx5kdhN0UIoL0meNy1OAg6vS1dqLDEadOdR0PH7JYgKAgrKTgE 7AlpMJEGbSbily/XQ349OLVD3LqQWoWNkdvvwhI+QAhtF5c3P+k77zJgsWYoq2s+kKq0yCHglEQo IwclpntcEAoITDyWSZWQWmmFl1EscgshvivTkzO/TF9FY6GaJWuamCjr6C0rIzkEbCOtibsmX0wR EACEQncfQrsoAFoE0sbTxOOWfpUGKvYQKsjJGZdS87Od59SL16x48aJ2Vfgic+uAQLTIM7WA6+Hp 4GnicQrSoGveroNIQWN+uX/WiPm5MVVKfAHwdYSFq5QCH0hfCrgEYUKJWGDjKhoH76trjTWbCjl4 VZf52TkbOG1K34glqKxxT4WofDo2knum8iIbgaPvKk1NQwHass25o0VgSGmGksLghNxAXzw2Jhoj kgzEH+bvv9w58M2wpSjnMyn0XZpZ4C/+bjjLYv932v8A3PTEbUKtr9sAAAAASUVORK5CYII= --_004_D094A69018053rrosariofive9com_-- From nobody Fri Nov 21 10:52:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF661A0276; Fri, 21 Nov 2014 10:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zDXwPSygzjF; Fri, 21 Nov 2014 10:52:26 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD1E1A033A; Fri, 21 Nov 2014 10:51:40 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 75EA477805F; Fri, 21 Nov 2014 10:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=U02JEDOOsNnBJt 3aseDR9ow6fhY=; b=AXbqMnydG47OMICMNTxrig2B11H9UCisTZZBmPACXYKYN8 ieeCF+DSMAcnPkO+Al7OqXHV1VEeF/H9sSdDKXUXpRCVk1bzqBDD6iPYnyIW8+3L LoEdlBrN88EcQ1TBPQ418AuXLLUAJQloHkxhup8gLnoASfCCal/jm4VhnN2PU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id 2330C778057; Fri, 21 Nov 2014 10:51:39 -0800 (PST) Date: Fri, 21 Nov 2014 12:51:38 -0600 From: Nico Williams To: Eric Rescorla Message-ID: <20141121185136.GF20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> <20141119205117.GE20758@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CrFWiYj98MQ3ALP5Gn_ZEWnTj7A Cc: kitten , "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:52:27 -0000 On Thu, Nov 20, 2014 at 09:06:21AM -0800, Eric Rescorla wrote: > On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams > wrote: > > > Certainly in the resumption case. > > Also in the semi-static DHE cases. Yes, of course (it's like resumption in a way). > > However, in other cases, we'd have to > > have ensure that whatever oob method is used for establishing the > > server's public key also conveys this (e.g., we'd need an RR type for > > indicating this for DANE). > > I don't see that that's a problem. At present DANE doesn't contain enough > information for the client to generate a 0-RTT handshake at all, so as > a practical matter we would need to extend the record format, so that > would implicitly agree to 0-RTT (or explicitly if you prefer). My inclination is to think that adding a new RR type or extending TLSA for this is not worthwhile. See below. > > It's much easier to have the server hold the > > early data and have it bound into the client's next handshake msg. > > This is not generically possible, because the client may have used > a key that the server has forgotten, which requires the client to > retransmit. Yes, indeed. Applications that can retransmit, could do that. For other applications (which is to say: most) the result has to be failure, and then a reconnect. Not good. This is a good reason to want to minimize 0-RTT usage to cases where the client has good reason to think the server will be able to handle it: when a) the server said or advertised so earlier, b) not much time has passed since. 0-RTT is an optimization, but if it can lead to failures that applications must special-case, then that's problematic. For HTTPS that's probably not a problem (it's just one reconnect). Will 1.3 support 0-RTT? > > Yes, of course. With TLS 1.2 one can renego. Unless I missed > > something, there's nothing in 1.3 for protecting the client's ID. > > In TLS 1.3, the client's second flight is sent encrypted. If it were sent > as part of the first flight, it would also be sent encrypted. So... is confidentiality protection of the client's cert/ID explicitly supported in 1.3? That'd be great news. Nico -- From nobody Fri Nov 21 13:56:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2565E1A8991 for ; Fri, 21 Nov 2014 13:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP52Pb2OLxjg for ; Fri, 21 Nov 2014 13:56:03 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322E71A8A82 for ; Fri, 21 Nov 2014 13:56:03 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so5078314lab.18 for ; Fri, 21 Nov 2014 13:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=ECAsyAxSiLEIukyE5wxCBsYjbMntFMT6m4J5u0synAw=; b=xqW9hViglVEeO9OS8JqIjiylzHuFdfLvGont/l88peEIp+ySdTVLv6+23iZdacyhh9 B8RypsN4QgwlLRErRq2VptTpiTN9Lemm/D94xc8ocfkH4a4oxFv0HkA1nduFgnN/K1IW IdjRNb8HkQ5nzmkdnY+vJn8RM8/RY4xj6f6gj70lFoW9YpI8kQML/pjnAjV5UWwPwf3e WcR41jrevgcwaXcZPl/pJnb5/GQQzwceWv/Dz4GoczNHvK75l4/y58Q75ZsiBYt1IIq3 a4SWHLg8tpUTNVpEa9IkA6gQrLSGauUs4lMzNnRHel0EuuhEHBPfZdOBYnNtgp6qyc5U GmYA== X-Received: by 10.112.247.43 with SMTP id yb11mr7717631lbc.51.1416606961531; Fri, 21 Nov 2014 13:56:01 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.135 with HTTP; Fri, 21 Nov 2014 13:55:31 -0800 (PST) From: Hugo Krawczyk Date: Fri, 21 Nov 2014 16:55:31 -0500 X-Google-Sender-Auth: SBNrAziVORWP9pqhQM1q34lNKzc Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1134de92ba82260508658213 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5Fz2nF2vcxJdiNJd-JwD64C_ze8 Cc: Hoeteck Wee Subject: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 21:56:08 -0000 --001a1134de92ba82260508658213 Content-Type: text/plain; charset=UTF-8 >From information I received regarding the meeting in Honolulu (which I did not attend and whose minutes are still unpublished) I gather that there was not enough support to continue consideration of the OPTLS proposal. This lack of support was based on three objections: - It is a "last minute" proposal that will delay the publication of TLS 1.3. - The "delegation" issue: An attacker that can gain access to the server's signing box, without necessarily learning the signing key, can obtain a signature on a static DH key and use it to impersonate the server. - The performance advantage of OPTLS relative to RSA signing is diminished when comparing to (current) TLS 1.3 with ECDSA signatures. I think these are important points but I feel that they were not given proper consideration, in particular, since there was not enough time to digest the proposal before the Honolulu meeting. I believe that OPTLS offers significant security and functional advantages over the current TLS 1.3 proposal and should not be dismissed without a more focused discussion. This is particularly so if we can clear the issue of delegation that was the main trigger to the change of sentiment on OPTLS from positive to "hesitating". In this note, I will address the three issues. The arguments are incomplete in the interest of not making this long email even longer. I will be happy to hear your feedback and expand on any issues that need further clarifications. *** The "last minute" objection *** This proposal is indeed coming at a late point in the process of specifying TLS 1.3. However, we are planning for a protocol that we hope will serve us for many years; a possible delay of a few weeks should not be a determining consideration. We must approach the design of TLS 1.3 with a *forward-looking* approach that considers evolving crypto technology, addresses a set of core requirements and leaves some flexibility for future functionality. TLS history shows that the protocol should be based on sound cryptographic design requiring as little crypto machinery as possible, and providing a consistent logic for the different modes of the protocol. OPTLS is rooted in this approach, building fully on a single underlying mechanism - Diffie-Hellman for both forward secrecy and authentication - and extending naturally to other authentication settings such as 0-RTT, pre-shared key and session resumption. Many of the benefits of OPTLS have been discussed in the original thread in this list and will not be reiterated here in detail. Please refer to these messages for more background: https://www.ietf.org/mail-archive/web/tls/current/msg14385.html https://www.ietf.org/mail-archive/web/tls/current/msg14592.html https://www.ietf.org/mail-archive/web/tls/current/msg14601.html *** The delegation issue *** I would now like to address the very valid concerns with using the server's existing signature key to sign static DH keys (a signature I refer to as a "subcert"). This has been the only technical objection to the protocol raised in this list and therefore I see its resolution as a necessary (and hopefully sufficient) condition for the adoption of the protocol. For some previous discussion on this issue see above cited messages, particularly the last one. Essentially, the problem is that the server's signature key becomes a "certifying key" for static DH keys and therefore its unauthorized usage can lead to adversarially-chosen static DH keys that allow the attacker to fully impersonate the server. This is not worse than an attacker stealing the signature key and using it to impersonate the server in current TLS. However, in the non-typical, but possible, scenario where an attacker can gain access to the signing functionality as a black-box (i.e., without learning the signing key) and obtain a signature on a message of its choice, this becomes a serious vulnerability. A particularly "ugly" case is that of a server that hasn't even upgraded to TLS 1.3 but that can be impersonated as a TLS 1.3 server if the attacker gets a signature of the server on a static DH key of the attacker's choice. One clean solution to the problem is to equip servers with new certificates that indicate use of the certified key for TLS 1.3. These can be either ECDH certificates or signature certificates (RSA, ECDSA or your favorite signature algorithm). In the case of ECDH certificates, no subcert or any form of signature is needed to run OPTLS. If the server's certificate is for a signing key then the server needs to send to the client a subcert with a signature on its static DH key. However, in this case, the certified key will only be used to sign subcerts - never as an online signature, hence can be afforded better protection. Indeed, the key can be stored offline and used only when new subcerts (for new static DH keys) are needed, or it can be protected even better by using it to to produce multiple subcerts (for multiple validity periods and/or multiple EC groups) and then be destroyed. For those who still feel this is not secure enough, the choice is simple: Use ECDH certificates and avoid the whole delegation issue. Note that ECDH certificates would be the simplest way of supporting a protocol like OPTLS. There is, however, one issue with ECDH certificates, namely, a server will need multiple certificates to support different groups. This is where server-signed subcerts are convenient. Note, however, that this is an advantage only when using RSA signatures. When the signature is ECDSA, we are back to the problem of requiring multiple ECDSA certificates for multiple groups. In this case, there seems to be no advantage on having signature certificates. Fortunately, OPTLS can work with any of these certificate types, leaving these choices to individual servers and accommodating any future (possibly unforeseeable) preferences. The bottom line is that the potential delegation vulnerabilities are addressed by servers obtaining new certificates for use with TLS 1.3. However, what about a server that is interested to upgrade to 1.3 (e.g. for providing PFS) but wants to keep using his TLS 1.2 signature key also with 1.3? For this case, I proposed (see third message above) a small tweak to the original OPTLS in which the server signs the static DH key together with the client's nonce, hence preventing any form of delegation attack. This forgoes the performance advantage of OPTLS relative to current TLS 1.3, but it facilitates a transition period until a server acquires a new certificate for use in TLS 1.3. The nice thing about this tweak is that the only change in the protocol's spec is replacing the validity period in the subcert with the client's nonce. *Everything* else in the protocol stays the same; in particular, it preserves all of the non-performance OPTLS advantages (including optional 0-RTT support at no extra cost and a single logic for all the protocol modes). It also presents a real incentive for servers to upgrade to TLS 1.3 (and TLS 1.3 certificates) as it saves the cost of RSA decryption in each session. As we know, performance gains are a better motivator than just added security. *** OPTLS vs ECDSA *** The argument was made that when people will start running TLS 1.3 (as currently specified) with ECDSA, the dramatic performance advantage of OPTLS relative to RSA signatures will diminish. That is true. But the OPTLS advantages are well beyond performance. In particular, as said above, OPTLS uses a single cryptographic mechanism, Diffie-Hellman, for all its functionality and does not depend on signatures (except for certification). Current TLS 1.3 depends on both DH and signatures, hence reducing its security to the weaker of the two. In addition, 0-RTT cannot be supported with a server's signature key and it requires adding a static DH key (or other PK encryption keys) to the server's public keys. Hence the signature is duplicating a functionality that can be provided by the static DH key only (as OPTLS does). There are also specific problematic aspects with ECDSA. For one, there is the issue of supporting multiple groups, hence necessitating multiple certificates (for the same "price", one can run OPTLS with ECDH certificates, avoiding signatures, subcerts, and their associated complexities and costs, including bandwidth). ECDSA requires deployment at servers and clients (in addition to ECDH that's needed for forward secrecy anyway), and presents non-trivial implementation issues for performance and to resist side-channel attacks (these implementation problems are specific to ECDSA signing and do not apply to ECDSA verification as may be needed for verifying certificates). OPTLS avoids these obstacles by solely building on the necessary and simpler-to-implement ECDH mechanism. Finally, ECDSA is vulnerable to the full compromise of the signing key upon the leakage of a single ephemeral quantity. OPTLS does not suffer of this problem and actually increases security over the ephemeral DH key computed in TLS 1.3 by feeding g^{xs} into the KDF that produces application keys. I respectfully ask for the re-consideration of OPTLS by the WG as a possible enhancement of TLS 1.3 design. Thanks, Hugo --001a1134de92ba82260508658213 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From information I received regarding the m= eeting in Honolulu (which I did not
attend and whose minutes are still u= npublished) I gather that there was not
enough support to continue consi= deration of the OPTLS proposal. This lack of
support was based on three = objections:

- It is a "last minute" proposal that will del= ay the publication of TLS 1.3.

- The "delegation" issue: A= n attacker that can gain access to the server's
=C2=A0 signing box,= without necessarily learning the signing key, can obtain a
=C2=A0 signa= ture on a static DH key and use it to impersonate the server.

- The = performance advantage of OPTLS relative to RSA signing is diminished
=C2= =A0 when comparing to (current) TLS 1.3 with ECDSA signatures.

I thi= nk these are important points but I feel that they were not given properconsideration, in particular, since there was not enough time to digest th= e
proposal before the Honolulu meeting. I believe that OPTLS offers sign= ificant
security and functional advantages over the current TLS 1.3 prop= osal and
should not be dismissed without a more focused discussion.=C2= =A0 This is
particularly so if we can clear the issue of delegation that= was the main
trigger to the change of sentiment on OPTLS from positive = to "hesitating".

In this note, I will address the three is= sues. The arguments are incomplete in
the interest of not making this lo= ng email even longer. I will be happy to
hear your feedback and expand o= n any issues that need further clarifications.

*** The "last mi= nute" objection ***

This proposal is indeed coming at a late p= oint in the process of specifying
TLS 1.3. However, we are planning for = a protocol that we hope will serve us
for many years; a possible delay o= f a few weeks should not be a determining
consideration. We must approac= h the design of TLS 1.3 with a *forward-looking*
approach that considers= evolving crypto technology, addresses a set of core
requirements and le= aves some flexibility for future functionality.
TLS history shows that = the protocol should be based on sound cryptographic
design requiring as = little crypto machinery as possible, and providing a
consistent logic fo= r the different modes of the protocol. OPTLS is rooted in
this approach,= building fully on a single underlying mechanism -
Diffie-Hellman for bo= th forward secrecy and authentication - and extending
naturally to other= authentication settings such as 0-RTT, pre-shared key and
session resum= ption. Many of the benefits of OPTLS have been discussed in the
original= thread in this list and will not be reiterated here in detail.
Please = refer to these messages for more background:

https://www.ietf.org/m= ail-archive/web/tls/current/msg14385.html
https://www.ietf.org/mail= -archive/web/tls/current/msg14592.html
https://www.ietf.org/mail-ar= chive/web/tls/current/msg14601.html

*** The delegation issue ***=

I would now like to address the very valid concerns with using the = server's
existing signature key to sign static DH keys (a signature = I refer to as a
"subcert"). This has been the only technical o= bjection to the protocol raised
in this list and therefore I see its res= olution as a necessary (and hopefully
sufficient) condition for the adop= tion of the protocol. For some previous
discussion on this issue see abo= ve cited messages, particularly the last one.
Essentially, the problem i= s that the server's signature key becomes a
"certifying key&quo= t; for static DH keys and therefore its unauthorized usage can
lead to a= dversarially-chosen static DH keys that allow the attacker to fully
impe= rsonate the server. This is not worse than an attacker stealing the
sign= ature key and using it to impersonate the server in current TLS.=C2=A0
= However, in the non-typical, but possible, scenario where an attacker can g= ain
access to the signing functionality as a black-box (i.e., without le= arning the
signing key) and obtain a signature on a message of its choic= e, this becomes
a serious vulnerability. A particularly "ugly"= case is that of a server that
hasn't even upgraded to TLS 1.3 but t= hat can be impersonated as a TLS 1.3
server if the attacker gets a signa= ture of the server on a static DH key of
the attacker's choice.
<= br>One clean solution to the problem is to equip servers with new certifica= tes
that indicate use of the certified key for TLS 1.3. These can be eit= her ECDH
certificates or signature certificates (RSA, ECDSA or your favo= rite signature
algorithm). In the case of ECDH certificates, no subcert = or any form of
signature is needed to run OPTLS. If the server's cer= tificate is for a signing
key then the server needs to send to the clien= t a subcert with a signature on
its static DH key. However, in this case= , the certified key will only be used
to sign subcerts - never as an onl= ine signature, hence can be afforded better
protection. Indeed, the key = can be stored offline and used only when new
subcerts (for new static DH= keys) are needed, or it can be protected even
better by using it to to = produce multiple subcerts (for multiple validity
periods and/or multiple= EC groups) and then be destroyed. For those who still
feel this is not = secure enough, the choice is simple: Use ECDH certificates
and avoid the= whole delegation issue. Note that ECDH certificates would be the
simple= st way of supporting a protocol like OPTLS. There is, however, one issuewith ECDH certificates, namely, a server will need multiple certificates t= o
support different groups. This is where server-signed subcerts are con= venient.
Note, however, that this is an advantage only when using RSA si= gnatures.
When the signature is ECDSA, we are back to the problem of re= quiring multiple
ECDSA certificates for multiple groups. In this case, t= here seems to be no
advantage on having signature certificates. Fortunat= ely, OPTLS can work with
any of these certificate types, leaving these c= hoices to individual servers
and accommodating any future (possibly unfo= reseeable) preferences.

The bottom line is that the potential delega= tion vulnerabilities are addressed
by servers obtaining new certificates= for use with TLS 1.3. However, what
about a server that is interested t= o upgrade to 1.3 (e.g. for providing PFS)
but wants to keep using his TL= S 1.2 signature key also with 1.3?
For this case, I proposed (see third= message above) a small tweak to the
original OPTLS in which the server = signs the static DH key together with the
client's nonce, hence prev= enting any form of delegation attack. This forgoes
the performance advan= tage of OPTLS relative to current TLS 1.3, but it
facilitates a transiti= on period until a server acquires a new certificate for
use in TLS 1.3. = The nice thing about this tweak is that the only change in the
protocol&= #39;s spec is replacing the validity period in the subcert with the
clie= nt's nonce.=C2=A0 *Everything* else in the protocol stays the same; in<= br>particular, it preserves all of the non-performance OPTLS advantages
= (including optional 0-RTT support at no extra cost and a single logic for a= ll
the protocol modes). It also presents a real incentive for servers to= upgrade
to TLS 1.3 (and TLS 1.3 certificates) as it saves the cost of R= SA decryption
in each session. As we know, performance gains are a bette= r motivator than
just added security.

*** OPTLS vs ECDSA ***
=
The argument was made that when people will start running TLS 1.3 (ascurrently specified) with ECDSA, the dramatic performance advantage of OP= TLS
relative to RSA signatures will diminish. That is true. But the OPTL= S
advantages are well beyond performance. In particular, as said above, = OPTLS
uses a single cryptographic mechanism, Diffie-Hellman, for all its=
functionality and does not depend on signatures (except for certificati= on).
Current TLS 1.3 depends on both DH and signatures, hence reducing i= ts security
to the weaker of the two.=C2=A0 In addition, 0-RTT cannot be= supported with a
server's signature key and it requires adding a st= atic DH key (or other PK
encryption keys) to the server's public key= s. Hence the signature is
duplicating a functionality that can be provid= ed by the static DH key only (as
OPTLS does). There are also specific pr= oblematic aspects with ECDSA. For one,
there is the issue of supporting = multiple groups, hence necessitating multiple
certificates (for the same= "price", one can run OPTLS with ECDH certificates,
avoiding s= ignatures, subcerts, and their associated complexities and costs,
includ= ing bandwidth).=C2=A0 ECDSA requires deployment at servers and clients (in<= br>addition to ECDH that's needed for forward secrecy anyway), and pres= ents
non-trivial implementation issues for performance and to resist sid= e-channel
attacks (these implementation=C2=A0 problems are specific to E= CDSA signing and do
not apply to ECDSA verification as may be needed for= verifying certificates).
OPTLS avoids these obstacles by solely buildin= g on the necessary and
simpler-to-implement ECDH mechanism. Finally, ECD= SA is vulnerable to the full
compromise of the signing key upon the leak= age of a single ephemeral quantity.
OPTLS does not suffer of this proble= m and actually increases security over the
ephemeral DH key computed in = TLS 1.3 by feeding g^{xs} into the KDF that
produces application keys.
I respectfully ask for the re-consideration of OPTLS by the WG as a p= ossible
enhancement of TLS 1.3 design.

Thanks,

Hugo
--001a1134de92ba82260508658213-- From nobody Fri Nov 21 14:35:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4411A8AB3 for ; Fri, 21 Nov 2014 14:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIsek6UnIQH7 for ; Fri, 21 Nov 2014 14:35:26 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB471A8AA8 for ; Fri, 21 Nov 2014 14:35:26 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id v63so4361777oia.15 for ; Fri, 21 Nov 2014 14:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IQaUiiF4LuzwGdglHlRTglqrblzDKb3V/NTjr07alqs=; b=WMUFiWRbHW3cBoGhU+TIxeJnWnGCh3W7sCcm2hEs0O5gyIZn559x2EKwA4Mk3NtpMG nF6exZawJSWq0OeCGfsWJaKC8sKvD/Mfnt9RF8qRotsGm11mx28/NtuCQWHkc4koXJDr GUrAsocJ2iPTOWny6GH2ECtvVyKNhzYZJuz+0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IQaUiiF4LuzwGdglHlRTglqrblzDKb3V/NTjr07alqs=; b=L0cAUKr9hH4jrIqYwUfC2tOaelUEZkApDvZEEwAlpEeueqXvXx/2b37jgzS4JYIAPQ ieaNETBMPLVYjaHASs+Pv84t2Wv82h0H8IuVSg3r5OZPnb1nuW0YtZ141+EwimUg5GrF 3kOo28pAn452w3qXg/TUtvjDzka/xVd0JABx2JYuCxzGIRTxT2rUUSESBxzSjR8Un7Yi uVDH4ALYGIGxfqa28UXHgMbpD0p2x7iY9C1aZit6HKJ/Hq/28gYDkRGJtU76bDoUuV1n 49r9H8cLrEKwDpia42nOawc+gxN0g5cl+4LvH8BU9ZeuAjfe1/yiJv+Hg/SPpDB+zbwa Hxrg== X-Gm-Message-State: ALoCoQmrhLxw3WbE3Ct2e1ZFzq0Ea3E59EesUlFJ6SfM+q0FWwIbKmbLBWNLN4JlePgBhxdCjj/l MIME-Version: 1.0 X-Received: by 10.60.134.20 with SMTP id pg20mr4708332oeb.36.1416609325565; Fri, 21 Nov 2014 14:35:25 -0800 (PST) Received: by 10.76.84.65 with HTTP; Fri, 21 Nov 2014 14:35:25 -0800 (PST) X-Originating-IP: [82.224.193.99] In-Reply-To: <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 21 Nov 2014 23:35:25 +0100 Message-ID: From: Alfredo Pironti To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=047d7b472948a2e4f10508660f60 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q9D7tCnQCD3QtbO-HraYa43tYRM Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 22:35:30 -0000 --047d7b472948a2e4f10508660f60 Content-Type: text/plain; charset=UTF-8 Hi Nikos, Thanks for your further comments. I'm answering to them inline. On Fri, Nov 21, 2014 at 4:43 PM, Nikos Mavrogiannopoulos wrote: > On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote: > > > > Yes, I agree this is a fair point. I'll complete the wording tomorrow > > in the pending PR, and these ideas will get into the updated version. > > Some additional comments: > 1. It has quite awkward structure. The main body of the document is at > the introduction section. > The structure can certainly be reworked once further consensus is reached, and hence the text stabilizes. I expect that some further editorial work may be required anyway if the draft proceeds forwards. > > 2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be > permitted." > Not sure I understand what it means. Does it mean that fallback to SSL > 3.0 from any version of TLS MUST NOT be permitted? > Well, the idea is that once SSLv3-only software is eradicated, then only TLS implementations capable of running SSLv3 will remain. Those should not negotiate SSLv3, even if they're able to do so. Anyway, most of this text is being recently reworked to be clearer and fix the Record layer potential interop issues you and others have already noted. See for instance the proposed draft [1]. > > 3. The document doesn't provide any instructions for clients that have > no other way to communicate with a server that only supports SSL 3.0. > MUST NOT is nice in theory, but can only be enforced on the systems one > has control on, and if the advise is followed to the letter legacy > systems (not talking of web) will be only be accessible in plaintext. > My understanding is that MUST NOT is the way legacy protocols usage is prohibited, see for example SSLv2 deprecation [2], which uses a very similar terminology. Of course closed systems will be free to ignore this document and still negotiate SSLv3 (or v2, for that matters). But yes, I'd claim the whole purpose of this draft is to outlaw (and encourage to update to TLS, not to retrofit to plaintext) open systems that connect to the Internet. > I'd expect prohibiting the fallback dance instead, and requiring that > SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the > clientHello. > I'd keep fallback out of the scope of this document, as the so notorious fallback dance has never been part of the TLS protocol negotiation itself. And, certainly, I wouldn't advocate fallback (even straight SSLv3 negotiation could be used as a last-resort fallback by some) to still support negotiation of SSLv3 for systems that don't really bother to upgrade to TLS almost 15 years after it was specified. Best, Alfredo [1] https://github.com/unicorn-wg/sslv3-diediedie/pull/10 [2] http://tools.ietf.org/html/rfc6176 > > regards, > Nikos > > > > --047d7b472948a2e4f10508660f60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nikos,

Thanks for your further commen= ts. I'm answering to them inline.

On Fri, Nov 21, 2014 at 4:43 PM, Nikos Ma= vrogiannopoulos <nmav@redhat.com> wrote:
On Sun, 2014-11-16 at 23:= 22 +0100, Alfredo Pironti wrote:


> Yes, I agree this is a fair point. I'll complete the wording tomor= row
> in the pending PR, and these ideas will get into the updated version.<= br>
Some additional comments:
1. It has quite awkward structure. The main body of the document is at
the introduction section.

The structure= can certainly be reworked once further consensus is reached, and hence the= text stabilizes. I expect that some further editorial work may be required= anyway if the draft proceeds forwards.
=C2=A0

2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be<= br> permitted."
Not sure I understand what it means. Does it mean that fallback to SSL
3.0 from any version of TLS MUST NOT be permitted?
Well, the idea is that once SSLv3-only software is eradicated, = then only TLS implementations capable of running SSLv3 will remain. Those s= hould not negotiate SSLv3, even if they're able to do so. Anyway, most = of this text is being recently reworked to be clearer and fix the Record la= yer potential interop issues you and others have already noted. See for ins= tance the proposed draft [1].
=C2=A0

3. The document doesn't provide any instructions for clients that have<= br> no other way to communicate with a server that only supports SSL 3.0.
MUST NOT is nice in theory, but can only be enforced on the systems one
has control on, and if the advise is followed to the letter legacy
systems (not talking of web) will be only be accessible in plaintext.

My understanding is that MUST NOT is the way legacy=20 protocols usage is prohibited, see for example SSLv2 deprecation [2],=20 which uses a very similar terminology. Of course closed systems will be=20 free to ignore this document and still negotiate SSLv3 (or v2, for that=20 matters). But yes, I'd claim the whole purpose of this draft is to=20 outlaw (and encourage to update to TLS, not to retrofit to plaintext) open = systems that connect to the Internet.
=C2=A0
I'd expect prohibiting the fallback dance instead, and requiring that SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the
clientHello.

I'd k= eep fallback out of the scope of this document, as the so notorious fallbac= k dance has never been part of the TLS protocol negotiation itself. And, ce= rtainly, I wouldn't advocate fallback (even straight SSLv3 negotiation = could be used as a last-resort fallback by some) to still support negotiati= on of SSLv3 for systems that don't really bother to upgrade to TLS almo= st 15 years after it was specified.

Best,
Alfredo
=C2=A0

regards,
Nikos




--047d7b472948a2e4f10508660f60-- From nobody Fri Nov 21 16:29:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6741A90F9 for ; Fri, 21 Nov 2014 16:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_3UC4qnSeK9 for ; Fri, 21 Nov 2014 16:29:29 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943051A90F8 for ; Fri, 21 Nov 2014 16:29:29 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id m8so4851387obr.13 for ; Fri, 21 Nov 2014 16:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rt0RkJzCSPzc0KcXlSmEgyub/K8wf4zIBdv0ZlDkyT8=; b=J3mzQvo3hd3CeE7wAcaRS/bdLt9/jIHyN1zeX/mbEE5s8scY6r13r/TQHgr3W14fpZ xt6P0j1ztixJv1rbQ35xbq4Hc+gxjVemNe/SQYGSV3t/C6QsNXR0fsUuhIGrpp+o5aOu z5Q9Kc0a2MjTOAR3mQGJg3lFrlOyek87OaqDYFIceeGsEqlG3pNmc37ZEIux/pu9khgW 6hgxKT1zlHuILluqJf4zUQ9yWtPKqdviFLJkjOSn+a2aCyF/W9UftePqpukusuELlGtW Qo9UYt+/zDQqsxWHmNYINBYFjd42ZXEJAVA7WZOtM7m2zcuqpSG5RC0LpCCPi0wDiB3w Elzg== MIME-Version: 1.0 X-Received: by 10.202.188.6 with SMTP id m6mr4656723oif.26.1416616168888; Fri, 21 Nov 2014 16:29:28 -0800 (PST) Received: by 10.202.115.4 with HTTP; Fri, 21 Nov 2014 16:29:28 -0800 (PST) In-Reply-To: References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 21 Nov 2014 14:29:28 -1000 Message-ID: From: Martin Thomson To: Alfredo Pironti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OHc7246jIEY4b-7RgdJFnR8Djgk Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:29:31 -0000 On 21 November 2014 12:35, Alfredo Pironti wrote: > My understanding is that MUST NOT is the way legacy protocols usage is > prohibited, see for example SSLv2 deprecation [2], which uses a very similar > terminology. Of course closed systems will be free to ignore this document > and still negotiate SSLv3 (or v2, for that matters). But yes, I'd claim the > whole purpose of this draft is to outlaw (and encourage to update to TLS, > not to retrofit to plaintext) open systems that connect to the Internet. Yes, I would be sad if we couldn't say anything more definitive about the use of TLS on the big 'I' Internet. People are of course welcome to use rot13 to protect their proprietary communications, noting that they won't remain proprietary long if they do. The same applies here. I merged Alfredo's text, and though I've proposed some minor grammatical changes, you can see the results live here: https://unicorn-wg.github.io/sslv3-diediedie/ From nobody Fri Nov 21 16:55:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A7C1A9114 for ; Fri, 21 Nov 2014 16:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0_jdvY6GKQC for ; Fri, 21 Nov 2014 16:55:25 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3601A910B for ; Fri, 21 Nov 2014 16:55:24 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 79so2820385ykr.28 for ; Fri, 21 Nov 2014 16:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R2DqKdlmYuvke+qmj9niMGEimGwpgEDiImWS7vWLKrU=; b=ih2PPMpcb6HkutJcyFYKc16JL2LOE2a58hGIVgd9bI2PD9ECYpFwzMGkvDaAdp35UE jWgXYA6P3eby5z1FA+/4K06Ew/xhf0PUu05Zps2fpW6RqVFMDvVkaRMOlOsuLDhWDwgo CZEFQ1z9S/eLw6mx+Zn/SfKrI3Uk6msJWOUeYpQufUX+SYhuGeMWNw7SSnR40qEM1vSF 0Z2T/79LDKI+NBjIS0z9nVB98po1bnzQ+jke90CdOOHYVS21FRVy3KrRhPVvV2XLK7iD sFfgx9kqNvjpKw8BKmS7zuiFKiGaetRCRXFXfvafmfxP+iVZmDcV+x3tACmplxwJP+34 48aw== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr5737704yhc.65.1416617723734; Fri, 21 Nov 2014 16:55:23 -0800 (PST) Received: by 10.170.195.21 with HTTP; Fri, 21 Nov 2014 16:55:23 -0800 (PST) In-Reply-To: <20141121185136.GF20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> <20141119205117.GE20758@localhost> <20141121185136.GF20758@localhost> Date: Fri, 21 Nov 2014 16:55:23 -0800 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zU_bdInMYUR9Txduapzb-D_mvr4 Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:55:30 -0000 On Fri, Nov 21, 2014 at 10:51 AM, Nico Williams wrote: > On Thu, Nov 20, 2014 at 09:06:21AM -0800, Eric Rescorla wrote: >> On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams >> wrote: >> >> > Certainly in the resumption case. >> >> Also in the semi-static DHE cases. > > Yes, of course (it's like resumption in a way). > >> > However, in other cases, we'd have to >> > have ensure that whatever oob method is used for establishing the >> > server's public key also conveys this (e.g., we'd need an RR type for >> > indicating this for DANE). >> >> I don't see that that's a problem. At present DANE doesn't contain enough >> information for the client to generate a 0-RTT handshake at all, so as >> a practical matter we would need to extend the record format, so that >> would implicitly agree to 0-RTT (or explicitly if you prefer). > > My inclination is to think that adding a new RR type or extending TLSA > for this is not worthwhile. See below. > >> > It's much easier to have the server hold the >> > early data and have it bound into the client's next handshake msg. >> >> This is not generically possible, because the client may have used >> a key that the server has forgotten, which requires the client to >> retransmit. > > Yes, indeed. Applications that can retransmit, could do that. For > other applications (which is to say: most) the result has to be failure, > and then a reconnect. Not good. This is a good reason to want to > minimize 0-RTT usage to cases where the client has good reason to think > the server will be able to handle it: when a) the server said or > advertised so earlier, b) not much time has passed since. Why wouldn't the implementation of TLS automatically resend 0-RTT data if the server didn't accept it? This seems like the right solution. > > 0-RTT is an optimization, but if it can lead to failures that > applications must special-case, then that's problematic. For HTTPS > that's probably not a problem (it's just one reconnect). > > Will 1.3 support 0-RTT? Isn't this a charter goal? > >> > Yes, of course. With TLS 1.2 one can renego. Unless I missed >> > something, there's nothing in 1.3 for protecting the client's ID. >> >> In TLS 1.3, the client's second flight is sent encrypted. If it were sent >> as part of the first flight, it would also be sent encrypted. > > So... is confidentiality protection of the client's cert/ID explicitly > supported in 1.3? That'd be great news. Again, I thought this was a charter goal. > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Nov 21 16:57:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF241A9125 for ; Fri, 21 Nov 2014 16:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCATM7FVRits for ; Fri, 21 Nov 2014 16:57:54 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34BD1A911A for ; Fri, 21 Nov 2014 16:57:53 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 131so2792802ykp.31 for ; Fri, 21 Nov 2014 16:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Y0a5az1APzMSSF3ANHApG/dcjucvrvsTrPeVjp4FTjY=; b=bdRc2KfoqtL3uo+XeVh0xoQ2B9f9Q3I22xr15A2giY792UiXf00Cp5KFn7vMP33PD3 UQuOZWc1eVWBux3lujL6fvndQA2h1Y/cF3qoCABugECg9fU73nSRqaB8tcqkpk25AtU5 ESmlMCvPbQ2wpVyYlVpqwBSArZtfixaRR8PSxCVIoOqXggSg6JPq86MFQST322xfJM+B k+L2ALayew4GTjS57LZzvUuKgUHNP3b3smujyluPpJtNFTsSJowad5laFDPKLKXBb6sC ZGWNqoG87ojW84uc78vH5SRZeGnDx5rvHyQCbU8GG4bGYL/9zDP6F2w+qHOOt5XFNazN RPLw== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr5745039yhc.65.1416617873139; Fri, 21 Nov 2014 16:57:53 -0800 (PST) Received: by 10.170.195.21 with HTTP; Fri, 21 Nov 2014 16:57:53 -0800 (PST) Date: Fri, 21 Nov 2014 16:57:53 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FNiz5Eyr-VOpLlkz_JctNcubdD4 Subject: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:57:56 -0000 Was the TLS 1.3 draft written by a cryptographer? No. Has it been reviewed by cryptographers? Unclear. Are the mechanisms secure? Unknown. Is it easy to analyze TLS 1.2? No. Was TLS 1.2 secure? No. Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains unincluded, but the record layer is finally fixed. How long will it take to analyze TLS 1.3? If past experience is any guide, a decade. Can we fix problems in deployed protocols? No. Will TLS 1.3 be deployed? Yes. Putting this together, it seems clear that substantially more attention needs to be paid to TLS 1.3 before we deploy it. A delay is inevitable. Even if we decide not to proceed with OPTLS, we need to make sure that there is a substantial degree of analysis of the protocol before, not after, it is deployed, and that it is designed to help, not hinder, analysis. The current draft is not in a state where it describes a protocol that we can analyze or implement. The sooner it gets to that state, the sooner we can start seriously finding problems or showing there are none. But we shouldn't expect that this process will be overnight: it's much faster to start with a good protocol and serialize each of the messages, instead of starting with mystery, figuring out what it actually does, and trying to show the result is correct (and discovering it isn't). Sincerely, Watson Ladd From nobody Fri Nov 21 17:11:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57231A924A for ; Fri, 21 Nov 2014 17:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmTInUm7vIT3 for ; Fri, 21 Nov 2014 17:11:32 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2072E1A923B for ; Fri, 21 Nov 2014 17:11:32 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so898639wiw.10 for ; Fri, 21 Nov 2014 17:11:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5+HWsxDSR0gqBgvo44cVVjEpeD7UNXzL8UXJQxWldRg=; b=fchhJNpLzFqIoI7JxDpJB+n2zK4E6pdMNfbsh7MoNl/Vm2L/zmTFS6kU6QzSRb09wy pEE8DFdG6ELttsQ9jhOBmu7XgF41LU/Q0bFfnVsnCmawO4h1UVqaPqWtSq3BieQQ6bfc RKNhFuuLzDF2N3DaqrUxp1ZrfIiS/6/PmM6/Uc5XCRiyKoSp3sUE0ExAjAe6oLB6Jdsh E8bdU2T5i9IV/4Sad/umqKHLJt79XiX/5BEuU+Db8UrMRZVc4DZ6GS0O+WVBHjlLJxdm uIn9PAxBrKu2nFwt/9eEEDbFtzFI+aufj+GU9vd5w64uDL9dC3Fmyz9y2aFA+koXVKHe 0PzA== X-Gm-Message-State: ALoCoQn5LbgZdVRl424hv4XHELeOGD3e2W1syV+Ggj4rIF1ENzxYNG9v0C8vdutCzXDGMeWomPDS X-Received: by 10.180.14.226 with SMTP id s2mr1588584wic.61.1416618690774; Fri, 21 Nov 2014 17:11:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Fri, 21 Nov 2014 17:10:50 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 21 Nov 2014 17:10:50 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d04138c9fd89a530508683da7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FjqSX_i-d1E5SXp4yqGRt4IEp4o Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 01:11:35 -0000 --f46d04138c9fd89a530508683da7 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 21, 2014 at 4:57 PM, Watson Ladd wrote: > Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains > unincluded, but the record layer is finally fixed. > We have a pull request up for session hash up at: https://github.com/tlswg/tls13-spec/pull/89 As I said in Honolulu, I've been planning to incorporate this next week. It would be great if you could take a look and send comments. > The current draft is not in a state where it describes a protocol that > we can analyze or implement. If there are specific things in the draft that you don't believe can be implemented (and that aren't otherwise called out in TODOs or Github issues) I would greatly appreciate it if you would let me know either on list or by filing issues. Best, -Ekr --f46d04138c9fd89a530508683da7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 21, 2014 at 4:57 PM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:
Has TLS 1.3 fixed flaws in TLS 1.2? Som= e: session_hash remains
unincluded, but the record layer is finally fixed.
We have a pull request up for session hash up at:

As I = said in Honolulu, I've been planning to incorporate this next week.
It would be great if you could take a look and send comments.
<= div>
=C2=A0
The current draft is not in= a state where it describes a protocol that
we can analyze or implement.

If there are s= pecific things in the draft that you don't believe can
be imp= lemented (and that aren't otherwise called out in TODOs or
Gi= thub issues) I would greatly appreciate it if you would let me
kn= ow either on list or by filing issues.

Best,
=
-Ekr




--f46d04138c9fd89a530508683da7-- From nobody Fri Nov 21 17:25:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6C61A916D for ; Fri, 21 Nov 2014 17:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo16eNJg3XCH for ; Fri, 21 Nov 2014 17:24:58 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273281A9231 for ; Fri, 21 Nov 2014 17:24:58 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so4978911obc.0 for ; Fri, 21 Nov 2014 17:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8fL85P2pfRBhQx3gwRKYzPHuOdgSE45W+wTEmdeZ6mQ=; b=gXx5Ijg+w56xhCDG+Y/MMU/JrubEUHZgM1spCCdPxi/S250fmxhzG+18ftuLDlspjb RSkAfY7cSgzHpLL/K16qJ9Zkx8gjgSAbGcmusNq1wuWn+Q7tvcnWmOEf7nXChlpMxU4d kBjcBrNESRi3cu0RnNYc2Pvfx/QUttb1fcyzmPmyAF+Ovs7ulTEbkUUMjgXNUGonOEPh hqyZw6aBP9R8qi5XS2OzugKeWQfHer5yBTsU9b5xcwOMd6Knvp8sv4T7XYzZA77uGKpa xedyVi3rNs0WBwv7w3nZHrUcqrARLKKhPSbUmS+0ydOXYpfaCh2BzTC3FBHIwuyRaQtO I4jw== MIME-Version: 1.0 X-Received: by 10.182.43.198 with SMTP id y6mr3917592obl.84.1416619497483; Fri, 21 Nov 2014 17:24:57 -0800 (PST) Received: by 10.202.115.4 with HTTP; Fri, 21 Nov 2014 17:24:57 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 15:24:57 -1000 Message-ID: From: Martin Thomson To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NcukWxfWBguFo0UT5bHeOAPmnHU Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 01:25:00 -0000 On 21 November 2014 11:55, Hugo Krawczyk wrote: > - It is a "last minute" proposal that will delay the publication of TLS 1.3. I don't think that this is at all the concern. Far from it. Not only did this not come up to my recollection, my impression that the participants in the conversation were seriously considering the proposal without regard to this particular cost. The most trite argument leveled against your proposal was the complexity one, but even that was recognized as being manageable. From nobody Fri Nov 21 21:30:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D189C1A003A for ; Fri, 21 Nov 2014 21:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbtb5xw67M3C for ; Fri, 21 Nov 2014 21:30:02 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1F01A0035 for ; Fri, 21 Nov 2014 21:30:02 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pv20so5275104lab.23 for ; Fri, 21 Nov 2014 21:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Zoa/aGQmOM40fwJQf9hYzuol15Qo0b45nZG+Oxp6IDo=; b=UFCgnrdRwAFDYC/sA1tP5laZDBVG2Hj7RCUTngYPbZ9FGkZYL9S52bkF8oBIgGW1rN XmH4utxq20dJ7wcBn/7ZYJWBnDxTzIjOfcej5eL4/f2f0iRy8k35FrFv8Ind48Nc1iLP UssvHeFCC8ZoDeBCA29U+j0ahqEVRI4UtYUEPOpvK0caDctSrrUBiChoI30tOYb5Egou x1HCoTioxpEp/eV4rFMhnNBpn8sfY+TJRfytfNOs6RMO93o+CwzghdandYBi3pm5cAjb Tx081wwpbE6YdL2oos/laJhaFAxrbOn/vTdCrx+ArKEb2lN7riDeVOIuBJuoTDqSKXMu 6rzQ== X-Received: by 10.112.254.162 with SMTP id aj2mr9177560lbd.70.1416634200638; Fri, 21 Nov 2014 21:30:00 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.135 with HTTP; Fri, 21 Nov 2014 21:29:30 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Sat, 22 Nov 2014 00:29:30 -0500 X-Google-Sender-Auth: j87sUCIX7IqtTqUhtupB3j4Y06M Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113462be4e4c5605086bda16 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lOXkAo3Te5N93EZY7npaQ9B1pTk Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 05:30:07 -0000 --001a113462be4e4c5605086bda16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 21, 2014 at 8:24 PM, Martin Thomson wrote: > On 21 November 2014 11:55, Hugo Krawczyk wrote: > > - It is a "last minute" proposal that will delay the publication of TLS > 1.3. > > I don't think that this is at all the concern. Far from it. Not only > did this not come up to my recollection, my impression that the > participants in the conversation were seriously considering the > proposal without regard to this particular cost. > =E2=80=8BI'm glad to hear that the "last minute" objection that was communi= cated to me is not a real concern and that people are willing to seriously consider the proposal. =E2=80=8B > > The most trite argument leveled against your proposal was the > complexity one, but even that was recognized as being manageable. > =E2=80=8BI am glad to hear this too. Please let me know what the sources of perceived complexity are. I might have addressed some of these in my recent posts, particularly the issue of delegation and certificates, but there is probably more to be cleared. In particular, I am not expert in the realities of the certification world - I do hope these realities will not mean a show stopper for the proposal. After all, the same certification issues will arise with any protocol that uses ECDH or ECDSA keys. Such protocol will either need per-group certificates or will have to accommodate some form of "delegation" (what I call subcerts) for signing keys in different groups. =E2=80=8B =E2=80=8BAnother possible source of =E2=80=8Bperceived complexity is the su= pport of 0-RTT as part of the protocol. Note, however, that while this feature is built-in into the protocol, its use is optional and it has no extra cost for those who do not use it. Its inclusion is simple to specify and it may avoid the need for a future revision/extension of the protocol. Hugo --001a113462be4e4c5605086bda16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 21, 2014 at 8:24 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 21 November 2014 11:55, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote: > - It is a "last minute" proposal that will delay the publica= tion of TLS 1.3.

I don't think that this is at all the concern.=C2=A0 Far from it= .=C2=A0 Not only
did this not come up to my recollection, my impression that the
participants in the conversation were seriously considering the
proposal without regard to this particular cost.

<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;font-si= ze:small;display:inline">=E2=80=8BI'm glad to hear that the "last = minute" objection that was communicated=20 to me is not a real concern and that people are willing to seriously consid= er the proposal.
=E2=80=8B
=C2=A0

The most trite argument leveled against your proposal was the
complexity one, but even that was recognized as being manageable.

=E2=80=8BI am glad to hear this t= oo. Please let me know what the sources of perceived complexity are.
I = might have addressed some of these in my recent posts, particularly the iss= ue of delegation and certificates, but there is probably more to be cleared= .
In particular, I am not expert in the realities of the certification w= orld - I do hope these realities will not mean a show stopper for the propo= sal.
After all, the same certification issues will arise with any protoc= ol that uses ECDH or ECDSA keys. Such protocol will either need per-group c= ertificates or will have to accommodate some form of "delegation"= (what I call subcerts) for signing keys in different groups.
=C2=A0=E2= =80=8B
=C2=A0
=E2=80=8BAnother possible source o= f =E2=80=8Bperceived complexity is the support of 0-RTT as part of the prot= ocol. Note, however, that while this feature is built-in into the protocol,= its use is optional and it has no extra cost for those who do not use it. = Its inclusion is simple to specify and it may avoid the need for a future r= evision/extension of the protocol.

Hugo



--001a113462be4e4c5605086bda16-- From nobody Fri Nov 21 22:15:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1901A0059 for ; Fri, 21 Nov 2014 22:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ-bWyjYNmJa for ; Fri, 21 Nov 2014 22:14:56 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0EC1A0056 for ; Fri, 21 Nov 2014 22:14:56 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so5070216obc.15 for ; Fri, 21 Nov 2014 22:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OrUm/A4yxR34orUDdVcmFxmb+Z93JL5pzu9PuiswRtk=; b=pTNys9Hc5o7saQBJ/UCkaZoJEI4T4ud72qx+6ZpIN9UtE3hXDRucukqe2AQRc0Nmd/ HttS2A5HX+oepXNdi4sMMqXkQkrXf8qyDuE4Y7FXRsl0EXDOqiZ6XX01ndLVpMdwC5VL oCcDvpl+koQiM8rfujt6ie0XKcAqrLdpA05AqoLYPe07evr4tDI0+xWP+nHaHc69jEP6 KCBqiD0Bv75u2fX4QgEKD2MX1j8Ct4Awx9IMDgZNPmAv7rOPQ36ash/gxQWUDqja1XJP N6rhkstGcLzl1w9lO2Qzk5pdlHGkHMMI1L1o8idcZKMdQcXi+0/C9aWdCjzUOyDgZwro XtQQ== MIME-Version: 1.0 X-Received: by 10.182.135.170 with SMTP id pt10mr4905229obb.30.1416636895744; Fri, 21 Nov 2014 22:14:55 -0800 (PST) Received: by 10.202.115.4 with HTTP; Fri, 21 Nov 2014 22:14:55 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 20:14:55 -1000 Message-ID: From: Martin Thomson To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bxfGlTbjNvEZWXnyMLaaJA91w8k Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 06:14:58 -0000 On 21 November 2014 19:29, Hugo Krawczyk wrote: > I am glad to hear this too. Please let me know what the sources of perceived > complexity are. The only items of note were: - the second update to the handshake protection under g^{xs}+g^{xy}. We all realized that this was trivially addressed (ekr had a slide at the meeting that showed an easy simplification, which should be in the meeting materials). - the delegation scheme itself I don't think that you can underestimate the costs involved with creating an external dependency of any sort - for any project. The reliance on PKIX updates could be problematic. That said, I'm not entirely sure that this is as straightforward a win as you suggest. If such a flag existed, using it would create the delegation problem we were most concerned about. I'll let others explain more of the thinking behind the delegation problem. I think that it's the only real issue with your proposal that you need to worry about. The performance characteristics are probably manageable. From nobody Fri Nov 21 23:23:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E201E1A007D for ; Fri, 21 Nov 2014 23:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpWysAJNCvfh for ; Fri, 21 Nov 2014 23:23:36 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8821A007B for ; Fri, 21 Nov 2014 23:23:36 -0800 (PST) Received: by mail-yk0-f182.google.com with SMTP id 131so2962799ykp.13 for ; Fri, 21 Nov 2014 23:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DzJh3RmgbK8Dh+qDoKCuBNQW1/LUFvpIP3uFmAj6Rkw=; b=VHDE9OrJcCYyTog7UPbEL2HyAdFhylSkVxkVL57Ilbp+zgWNrT0J/Sp4SsP8nvvbdO kSeM2b267MS1FAY3CaCHMi5XFg2zJP9DjFYa1+MFrRPZwam1ilbvUMaEgZU4WJylJQuT N9/b8W+W4uWMjF+KHhcmwTxwJY8AhJBkEx0etuAZzdH8MNOV5QclG9gHS0TdccHcQkS1 H8z+wUSeK/6vbm+P7Us0FUijpOSs5nLb3GvBv52dCjc+VawpHCjEQabvYPOlEmm35btF mPvh7p2DrZtGIyBnz4e7pIL+M14ACoJJmmmozjn69ZmWIP3deu3U5u3spPg6ZmDLGEGg jGTQ== MIME-Version: 1.0 X-Received: by 10.170.214.6 with SMTP id g6mr7925980ykf.34.1416641015750; Fri, 21 Nov 2014 23:23:35 -0800 (PST) Received: by 10.170.195.21 with HTTP; Fri, 21 Nov 2014 23:23:35 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 23:23:35 -0800 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DCmYq-McKLnnIBBcWr2fEqLOm_Y Cc: Hoeteck Wee , "tls@ietf.org" Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 07:23:40 -0000 On Fri, Nov 21, 2014 at 10:14 PM, Martin Thomson wrote: > On 21 November 2014 19:29, Hugo Krawczyk wrote: >> I am glad to hear this too. Please let me know what the sources of perceived >> complexity are. > > The only items of note were: > - the second update to the handshake protection under g^{xs}+g^{xy}. > We all realized that this was trivially addressed (ekr had a slide at > the meeting that showed an easy simplification, which should be in the > meeting materials). Both variants were in fact in Hugo's email. However, if you have computed [xy]g, there are no savings from computing [xy]g+[xs]g vs [xs]g. I'm not sure the "variant of Hugo's proposal" in the slides is worthwhile at all: the original reason to use [xy]g+[xs]g was for a 1-RTT round trip with forward secrecy, and it was mentioned that this would require other changes. In fact the scheme presented on the slides as a "variant" is insecure, in addition to having no efficiency gains. Did anyone catch the mistake? (For the correct variants, as well as description of the attack on this variant see https://www.infsec.cs.uni-saarland.de/~mohammadi/paper/owake.pdf, following http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf) > - the delegation scheme itself > > I don't think that you can underestimate the costs involved with > creating an external dependency of any sort - for any project. The > reliance on PKIX updates could be problematic. That said, I'm not > entirely sure that this is as straightforward a win as you suggest. > If such a flag existed, using it would create the delegation problem > we were most concerned about. I understood the delegation problem as one concerned with the following scenario: someone owns a box with an HSM attached, signs a delegation, uses it surreptitiously. So long as TLS 1.3 could work for a cert issues not for it, this was a problem: certain security guarantees would be broken. But if TLS 1.3 is opt-in how is this a problem? The HSM could execute the ECDH related operations itself, and return only the keys, and a server requiring this level of security without such an HSM could continue using TLS 1.2. Or is the issue one that any protocol not requiring online signatures would run into? Moreover, even if people don't want delegation, OTLS is still a good idea. Many of the areas like client authentication and 0-RTT that are labeled "very sketchy" or "TODO" in the EKR draft are solved by OTLS. As far as I know, we've not had anyone look at the TLS 1.3 draft and say they could prove it secure. That said, with renegotiation dead, it should be a lot easier. But I'm not an expert in this area: it may be the current draft is comparable to OPTLS in terms of provability. > > I'll let others explain more of the thinking behind the delegation > problem. I think that it's the only real issue with your proposal > that you need to worry about. The performance characteristics are > probably manageable. Not requiring online signatures is a win for performance for users with RSA certificates. The current draft has very similar performance. Sincerely, Watson > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Nov 22 02:40:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E501A0180 for ; Sat, 22 Nov 2014 02:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fRu7nH-c5Gt for ; Sat, 22 Nov 2014 02:40:32 -0800 (PST) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0E41A017A for ; Sat, 22 Nov 2014 02:40:32 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sAMAeSxB015598; Sat, 22 Nov 2014 05:40:28 -0500 Date: Sat, 22 Nov 2014 05:40:27 -0500 (EST) From: Nikos Mavrogiannopoulos To: Martin Thomson Message-ID: <1052358743.2229177.1416652827952.JavaMail.zimbra@redhat.com> In-Reply-To: References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: Deprecating SSLv3 Thread-Index: Qg0fCCTwTi2j/rPt+QvNosGJAKaVvg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u_3rMfYLJAfojTTt9emqQh18Z8Q Cc: tls@ietf.org, Alfredo Pironti Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 10:40:34 -0000 ----- Original Message ----- > Yes, I would be sad if we couldn't say anything more definitive about > the use of TLS on the big 'I' Internet. People are of course welcome > to use rot13 to protect their proprietary communications, noting that > they won't remain proprietary long if they do. The same applies here. > I merged Alfredo's text, and though I've proposed some minor > grammatical changes, you can see the results live here: > https://unicorn-wg.github.io/sslv3-diediedie/ I believe that comparison is way out of proportion, for the following reasons: * First SSL 3.0 is still in use - at least my experience shows many SSL 3.0 only services on a typical network (it did only take few hours to get the first bug report when SSL 3.0 was disabled in the development branch of Fedora), * there is no new attack on SSLv3 (the attack poodle uses on SSLv3 was already known 10 years ago), and the TLS protocol negotiation is still considered secure enough to negotiate the latest version supported between two parties * SSLv3 is orders of magnitude better than plaintext (or rot13). The latter shows the actual dilema many face at the moment, which is not whether to replace SSL 3.0 with TLS 1.2, but what to do to interoperate with the services that can only use SSL 3.0 or plaintext. You may choose to ignore them of course but that would also render that draft not applicable to them. Note here that I am not advocating the use of SSL 3.0, but it would be beneficial for everyone if that draft also described a path which leads to the abolishment of SSL 3.0 in a secure way, for the ones that cannot avoid its use. That highlights the main difference with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it was published. regards, Nikos From nobody Sat Nov 22 02:57:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5061A017D for ; Sat, 22 Nov 2014 02:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQcP-IVUF1m1 for ; Sat, 22 Nov 2014 02:57:02 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CAA1A017A for ; Sat, 22 Nov 2014 02:57:02 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 1470B1C2060; Sat, 22 Nov 2014 11:57:00 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id C94BD1FE00EF; Sat, 22 Nov 2014 11:56:59 +0100 (CET) Date: Sat, 22 Nov 2014 11:56:59 +0100 From: Kurt Roeckx To: Nikos Mavrogiannopoulos Message-ID: <20141122105659.GA26446@roeckx.be> References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> <1052358743.2229177.1416652827952.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1052358743.2229177.1416652827952.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ic6clEK4IiDDS55X2AZvsGl0o0Q Cc: tls@ietf.org, Alfredo Pironti Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 10:57:04 -0000 On Sat, Nov 22, 2014 at 05:40:27AM -0500, Nikos Mavrogiannopoulos wrote: > That highlights the main difference > with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it was published. There still are SSLv2 only services on the internet. Hubert Kario last scan results (https://lists.fedoraproject.org/pipermail/security/2014-October/001989.html) said: Supported Protocols Count Percent -------------------------+---------+------- SSL2 44800 10.2755 SSL2 Only 5536 1.2698 SSL3 302890 69.4723 SSL3 Only 2971 0.6814 Kurt From nobody Sat Nov 22 03:32:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA841A0AC8 for ; Sat, 22 Nov 2014 03:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z70EnL4-9bv4 for ; Sat, 22 Nov 2014 03:32:35 -0800 (PST) Received: from vsp1.ballou.se (vsp1.ballou.se [91.189.40.82]) by ietfa.amsl.com (Postfix) with SMTP id CCD131A0ABD for ; Sat, 22 Nov 2014 03:32:33 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp1.ballou.se (Halon Mail Gateway) with ESMTP for ; Sat, 22 Nov 2014 12:32:30 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id DB4B21DE89 for ; Sat, 22 Nov 2014 12:32:30 +0100 (CET) Message-ID: <5470742A.8020002@streamsec.se> Date: Sat, 22 Nov 2014 12:31:54 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fQKinV8KGOQ7R5zMK8tWEOnFY-k Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 11:32:37 -0000 On 2014-11-22 01:57, Watson Ladd wrote: > Was the TLS 1.3 draft written by a cryptographer? No. > Has it been reviewed by cryptographers? Unclear. > Are the mechanisms secure? Unknown. > Is it easy to analyze TLS 1.2? No. > Was TLS 1.2 secure? No. > Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains > unincluded, but the record layer is finally fixed. I think such discussions would benefit from the basic premise that "secure" is a relative notion. It is completely pointless to ask if a protocol is secure or not secure, unless you first present an exhaustive list of security claims. That is, you can't ask if TLS 1.3 is secure or not, without first describing what security is to be expected from different scenarios. In a sense, *every* protocol has the potential of becoming broken, unless it is unambiguously defined what is proper and improper usage of the protocol. From nobody Sat Nov 22 08:42:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FD91ACD22 for ; Sat, 22 Nov 2014 08:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtuTWmzRW0Bg for ; Sat, 22 Nov 2014 08:42:13 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id EE45D1AC3E8 for ; Sat, 22 Nov 2014 08:42:10 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 09A9528512; Sat, 22 Nov 2014 16:42:10 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id E3CA528510; Sat, 22 Nov 2014 16:42:09 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 67426202C; Sat, 22 Nov 2014 16:42:09 +0000 (GMT) Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 22 Nov 2014 11:42:03 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.19]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sat, 22 Nov 2014 11:42:02 -0500 From: "Salz, Rich" To: Nikos Mavrogiannopoulos , Martin Thomson Date: Sat, 22 Nov 2014 11:42:00 -0500 Thread-Topic: Deprecating SSLv3 Thread-Index: AdAGczzWN5HN3yirRFi/VTkSrxAKow== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D5211D3AB@USMBX1.msg.corp.akamai.com> References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> <1052358743.2229177.1416652827952.JavaMail.zimbra@redhat.com> In-Reply-To: <1052358743.2229177.1416652827952.JavaMail.zimbra@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1HP1JLPKpQkc1xGC_QaV149xQRA Cc: "tls@ietf.org" , Alfredo Pironti Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 16:42:15 -0000 > * First SSL 3.0 is still in use - at least my experience shows many SSL 3= .0 only > services on a typical network (it did only take few hours to get the firs= t bug Sure, there are lots of deployments. We see it too. (Well, not lots; sign= ificantly under 1% by connections.) But that does not mean it is the best practice. Sometimes you just can't b= e the best. I'll never win a medal at the Olympics, but that doesn't mean = that other folks should never be able to set world records. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Sat Nov 22 08:55:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319601ACD28 for ; Sat, 22 Nov 2014 08:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvhNREb7u-9N for ; Sat, 22 Nov 2014 08:55:12 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 93A231ACD27 for ; Sat, 22 Nov 2014 08:55:12 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B7EAD284C1; Sat, 22 Nov 2014 16:55:11 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A545D284AE; Sat, 22 Nov 2014 16:55:11 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id A0C438004A; Sat, 22 Nov 2014 16:55:11 +0000 (GMT) Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 22 Nov 2014 11:54:41 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.19]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sat, 22 Nov 2014 11:54:41 -0500 From: "Salz, Rich" To: Martin Thomson , Hugo Krawczyk Date: Sat, 22 Nov 2014 11:54:40 -0500 Thread-Topic: [TLS] Re-thinking OPTLS Thread-Index: AdAF8yZnWQrRimkiQNewuvh1GkOP0gAgaFuA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D5211D3AF@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s9D5dQ2aj5N2KgF6L0r0eDkL-Oc Cc: "tls@ietf.org" Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 16:55:15 -0000 > I don't think that this is at all the concern. Some of us have this concern, and discussed it off-list with WG "management= " who didn't disagree. But if the consensus is that this is not an issue, then not only am I okay = with it, I think that this is very good news. From nobody Sat Nov 22 09:19:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84141ACD8D for ; Sat, 22 Nov 2014 09:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xF9J8F_4YqJ for ; Sat, 22 Nov 2014 09:19:06 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C871ACD8C for ; Sat, 22 Nov 2014 09:19:06 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so5576374lbd.17 for ; Sat, 22 Nov 2014 09:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XEdpXhuradwYSpX+xaQG/UKNrsRSxS5OpzFQpGby3hk=; b=f5evQm2Fquk/LJhmqra+GVprbt3MpOJfINWsLospTKKKzP/n36wvPh+1AG8wnPku8J O9/KPesbS/NjRm/fb6FctgipFfZe+iXfLjTT8Ox6pzguPmgHB8gbeddwBwuD4hbSMtDc uWg/o+IOAs90No9RCcWiOxm3qdkwY8HCUfS2anxH/KE9J4/2QeBUA4PmJ/c7cxJqxdw+ CQ5FxnvRE8qYOntkMEVWdysLq4L+VGF6YtZGXy3WiHg1OyOvZB+nnwuyV0jz4//MJNLI xXj55G2BD3kdlvxp1Sds7/QoTNPUVTijd0vZdK1Ett1nunO/X3xCjBvtxISHg61gy/NH xDqQ== MIME-Version: 1.0 X-Received: by 10.152.37.69 with SMTP id w5mr11280211laj.67.1416676744513; Sat, 22 Nov 2014 09:19:04 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Sat, 22 Nov 2014 09:19:04 -0800 (PST) In-Reply-To: References: Date: Sat, 22 Nov 2014 09:19:04 -0800 X-Google-Sender-Auth: 3qS_H2ZmRcjcQLtP1c8OXSIK-dw Message-ID: From: Adam Langley To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KKagDxoLLyXDI9Y8zx4G_1hm5uk Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 17:19:08 -0000 On Fri, Nov 21, 2014 at 11:23 PM, Watson Ladd wrote: > Not requiring online signatures is a win for performance for users > with RSA certificates. The current draft has very similar performance. There is at least one data-point when it comes to "delegation" signatures: it's what QUIC does[1] (with its own message format and embedded expiry) and Google is perfectly happy with deploying QUIC. [1] https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit#heading=h.bzxklo2i5w6k Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sat Nov 22 14:15:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECBD1A028A for ; Sat, 22 Nov 2014 14:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g1rGZ7gceNx for ; Sat, 22 Nov 2014 14:15:32 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6FE1A020B for ; Sat, 22 Nov 2014 14:15:31 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id t59so3364676yho.19 for ; Sat, 22 Nov 2014 14:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FcF2IlqHzgYkq4ZYndQvm5xh37ZgvhtWKz22CVX2Ra4=; b=p4MVhorwKV3WgpM7RVO5SR4K86TV8tGLGTphg+aVe11FtRHyEl0bwuVUSIqrO9o/tg U9sBGbI2FOKmVLTNvJlZB891l1vnUxmPZRx9/d8iyC2D6MlVR7gpL1+xoxGm6N9QeQhN C/6HqOD0D+iwDvDOZx4f1MyrKRBJpn7xeqEpzNKRGTQLDtLEAyP5QITWbjwlgs71sw8n jL/YJNCoS/N8slfE/XxfTxLaneT0Rb651JWcwVotuhPNvyPONuKyXUcYBmd95uHerXfy mNff+j3ZzTl4W6tY+Nqje6lzhwRvxBQTRCRdXj8c1muOEjAHu2jvb2POAfiD9VUrMg9F V9qw== MIME-Version: 1.0 X-Received: by 10.236.17.197 with SMTP id j45mr9903319yhj.49.1416694530888; Sat, 22 Nov 2014 14:15:30 -0800 (PST) Received: by 10.170.195.21 with HTTP; Sat, 22 Nov 2014 14:15:30 -0800 (PST) In-Reply-To: <5470742A.8020002@streamsec.se> References: <5470742A.8020002@streamsec.se> Date: Sat, 22 Nov 2014 14:15:30 -0800 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Henrick_Hellstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wQlrGytZkb2Up8IsmWNQFUU9A20 Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 22:15:33 -0000 On Sat, Nov 22, 2014 at 3:31 AM, Henrick Hellstr=C3=B6m wrote: > On 2014-11-22 01:57, Watson Ladd wrote: >> >> Was the TLS 1.3 draft written by a cryptographer? No. >> Has it been reviewed by cryptographers? Unclear. >> Are the mechanisms secure? Unknown. >> Is it easy to analyze TLS 1.2? No. >> Was TLS 1.2 secure? No. >> Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains >> unincluded, but the record layer is finally fixed. > > > I think such discussions would benefit from the basic premise that "secur= e" > is a relative notion. It is completely pointless to ask if a protocol is > secure or not secure, unless you first present an exhaustive list of > security claims. That is, you can't ask if TLS 1.3 is secure or not, with= out > first describing what security is to be expected from different scenarios= . It's clear what the security claims of TLS are be: a TLS connection between two parties ensures that data sent between them isn't intercepted or manipulated, and that they are who they claim to be. This is a fairly standard notion, clearly present in research by the late 80's, and intuitively sensible. Of course, past versions of TLS haven't provided it. > > In a sense, *every* protocol has the potential of becoming broken, unless= it > is unambiguously defined what is proper and improper usage of the protoco= l. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Nov 22 15:04:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAEF1A037E for ; Sat, 22 Nov 2014 15:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1sNMhtfRDD0 for ; Sat, 22 Nov 2014 15:04:13 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0631A036A for ; Sat, 22 Nov 2014 15:04:12 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so4679049lbv.21 for ; Sat, 22 Nov 2014 15:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kl0E+Nc3F+nVZroI5E/JjPSd+DnC6WWt2CPF9y6NAoY=; b=tWSu/kp4/Fn1y8LlIai6RpYRDHpxLgy0CeVFGvQ1KRlKwHqENNUv4M34ips7RLjluV UHCxYv9gd/hIZcbECcZQSusZQKt2j1XQAXOE2jhi7VokXA8Wn+DHz3XFdsN8U+upOY7s RHCb+q1UzJ/sbovu+8ZS1e7fJpFANiavArnCKh0XfSWGmHGLUw3Z4OfLYFII1pnatdvd zjTNPsBC3XyqeuZRjkSkauxk3M1MEHKV+cbmru4fN37RlCkC/dg+rGfsplhLkfrYFljm 58EIp0s+0+k1wGLMGlKoqBYv3Xu73Okn4YI4JzMkUQOZJnU7HhJ8SKcEj/3aw9vS9JKH N0zA== X-Received: by 10.112.247.43 with SMTP id yb11mr12648751lbc.51.1416697450739; Sat, 22 Nov 2014 15:04:10 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.135 with HTTP; Sat, 22 Nov 2014 15:03:40 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Sat, 22 Nov 2014 18:03:40 -0500 X-Google-Sender-Auth: sX4NscvzZlwJYkgLZHeLSRRiLMk Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1134de924e3d9605087a94c5 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xFdkM_szmDcr0SkbEYWovgSnoBQ Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 23:04:16 -0000 --001a1134de924e3d9605087a94c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin, one does not have to resort to delegation for using OPTLS, you can use ECDH certificates, except that you may need a certificate for each group yo= u support. The *same* goes for using ECDSA in current TLS. That is, if you want to be able to sign in TLS with different groups (I think this will be needed), then you need one certificate for each group that you want to support or else you need delegation (for signing subcerts for mutliple ECDSA keys). Let me parse all the options we have. If you don't want delegation you have three options: RSA certificates (and pay for per-session RSA signing performance cost), per-group ECDSA certificate (requiring per-session signature), or per-group ECDH certificates (requires no signing at all and no delegation). All other cases require delegation. So, if you don't care about per-session RSA cost AND do not care about the added value/functionality of OPTLS, then you can keep current TLS 1.3. Otherwise, you are left with essentially two choices. - If you are willing to live with multiple certificates, one per-group, the= n run OPTLS with ECDH certificates: It gives the best security-functionality-performance return (and no delegation). - If you don't want per-group certificates then you must resort to delegation (this is the case whether you use current TLS 1.3 with ECDSA or use OPTLS). But if you are going to live with delegation then there is no advantage to TLS 1.3 over OPTLS. The interesting thing about OPTLS (with the optional online signature tweak= ) is that it can accommodate all of the above options in one compact protocol= : - you don't want delegation or per-group keys, use OPTLS with Online RSA signature (the subcert signs the client nonce) - you don't want delegation but accept per-group keys, use OPTLS with ECDH certificates (no signatures, no subcert/delegation) - you don't like the above options (hence forced to live with delegation), use OPTLS with offline-signed subcerts for ECDH keys. The above, I think, is nice and provides a strong justification for OPTLS. However, if you want the protocol to support delegation and are concerned about the "HSM attacks" discussed here, then you need to require servers to obtain ne= w certificates (ECDH, ECDSA or RSA). The point is that you don't want servers to use their TLS 1.2 (or earlier) keys to also sign subcerts. =E2=80=8BHugo=E2=80=8B PS: =E2=80=8BI will answer the issue of key derivation separately.=E2=80=8B On Sat, Nov 22, 2014 at 1:14 AM, Martin Thomson wrote: > On 21 November 2014 19:29, Hugo Krawczyk wrote: > > I am glad to hear this too. Please let me know what the sources of > perceived > > complexity are. > > The only items of note were: > - the second update to the handshake protection under g^{xs}+g^{xy}. > We all realized that this was trivially addressed (ekr had a slide at > the meeting that showed an easy simplification, which should be in the > meeting materials). > - the delegation scheme itself > > I don't think that you can underestimate the costs involved with > creating an external dependency of any sort - for any project. The > reliance on PKIX updates could be problematic. That said, I'm not > entirely sure that this is as straightforward a win as you suggest. > If such a flag existed, using it would create the delegation problem > we were most concerned about. > > I'll let others explain more of the thinking behind the delegation > problem. I think that it's the only real issue with your proposal > that you need to worry about. The performance characteristics are > probably manageable. > --001a1134de924e3d9605087a94c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin, one does not have to resort to delegation for usin= g OPTLS, you can use
ECDH certificates, except that you may need a certi= ficate for each group you
support. The *same* goes for using ECDSA in cu= rrent TLS. That is, if you want
to be able to sign in TLS with different= groups (I think this will be needed),
then you need one certificate for= each group that you want to support or else
you need delegation (for si= gning subcerts for mutliple ECDSA keys).

Let me parse all the option= s we have.

If you don't want delegation you have three options: = RSA certificates (and pay
for per-session RSA signing performance cost),= per-group ECDSA certificate
(requiring per-session signature), or per-g= roup ECDH certificates (requires no
signing at all and no delegation). A= ll other cases require delegation.

So, if you don't care about p= er-session RSA cost AND do not care about the
added value/functionality = of OPTLS, then you can keep current TLS 1.3.

Otherwise, you are left= with essentially two choices.

- If you are willing to live with mul= tiple certificates, one per-group, then
=C2=A0 run OPTLS with ECDH certi= ficates: It gives the best
=C2=A0 security-functionality-performance ret= urn (and no delegation).

- If you don't want per-group certifica= tes then you must resort to delegation
=C2=A0 (this is the case whether = you use current TLS 1.3 with ECDSA or use OPTLS).
=C2=A0 But if you are = going to live with delegation then there is no advantage to
=C2=A0 TLS = 1.3 over OPTLS.

The interesting thing about OPTLS (with the optional= online signature tweak)
is that it can accommodate all of the above opt= ions in one compact protocol:

- you don't want delegation or per= -group keys, use OPTLS with Online RSA
=C2=A0 signature (the subcert sig= ns the client nonce)

- you don't want delegation but accept per-= group keys, use OPTLS with ECDH
=C2=A0 certificates (no signatures, no s= ubcert/delegation)

- you don't like the above options (hence for= ced to live with delegation),
=C2=A0 use OPTLS with offline-signed subc= erts for ECDH keys. =C2=A0

The above, I think, is nice and provides = a strong justification for OPTLS.
However, if you want the protocol to s= upport delegation and are concerned about the
"HSM attacks" di= scussed here, then you need to require servers to obtain new
certificate= s (ECDH, ECDSA or RSA). The point is that you don't want servers to
= use their TLS 1.2 (or earlier) keys to also sign subcerts.

=E2=80=8BHugo=E2=80=8B

PS: =E2=80=8B= I will answer the issue of key derivation separately.=E2=80=8B
<= div class=3D"gmail_extra">
On Sat, Nov 22, 20= 14 at 1:14 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 21 Novembe= r 2014 19:29, Hugo Krawczyk <h= ugo@ee.technion.ac.il> wrote:
> I am glad to hear this too. Please let me know what the sources of per= ceived
> complexity are.

The only items of note were:
=C2=A0- the second update to the handshake protection under g^{xs}+g^{xy}.<= br> We all realized that this was trivially addressed (ekr had a slide at
the meeting that showed an easy simplification, which should be in the
meeting materials).
=C2=A0- the delegation scheme itself

I don't think that you can underestimate the costs involved with
creating an external dependency of any sort - for any project. The
reliance on PKIX updates could be problematic.=C2=A0 That said, I'm not=
entirely sure that this is as straightforward a win as you suggest.
If such a flag existed, using it would create the delegation problem
we were most concerned about.

I'll let others explain more of the thinking behind the delegation
problem.=C2=A0 I think that it's the only real issue with your proposal=
that you need to worry about.=C2=A0 The performance characteristics are
probably manageable.

--001a1134de924e3d9605087a94c5-- From nobody Sat Nov 22 15:09:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98401A037D for ; Sat, 22 Nov 2014 15:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLB0qhIlk6Wr for ; Sat, 22 Nov 2014 15:09:50 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE461A036A for ; Sat, 22 Nov 2014 15:09:49 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so252409lbv.11 for ; Sat, 22 Nov 2014 15:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=wh9FzI6DAG4o527N4psFasYYvQ43bLKcbOsprVqncFo=; b=SEZvAFeioBArobPzp0Svmvlf1toqR7C/BClnL+t1uplo9xNp5dH/MzcOzrQVPK9SdK PFlTXMtdJPJkQLYtI7gAmaMLrFFPSjtIPSPeOb4FDLuY0r34n4evKUV4LXsrz3YHImOM SuOW+yVJ0HJ4pagLg8OzWm6p/QuB/9i8BWHv+8X4TDECYgwkIr5txJ8OgQ3mCgAV1dKE DhpROThapq72V99JpWO+aUdSLbyq53Pd/1l5yyl22r1TaEfTNkXNx9kPTptOrQNHG2FB b2+ftM8Fb4LdP2BSlkP52tH4ww19BjYi642iAvZ24QfN8qSZO8LJMuYD4q/lpYNbzNrt 8XZA== X-Received: by 10.152.207.71 with SMTP id lu7mr12694567lac.81.1416697787553; Sat, 22 Nov 2014 15:09:47 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.135 with HTTP; Sat, 22 Nov 2014 15:09:17 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Sat, 22 Nov 2014 18:09:17 -0500 X-Google-Sender-Auth: l5FuK448BoqrIQAM48dL9d3njBc Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113473da61a08a05087aa839 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e9LeInuV3deUFS7DA_GApt6rC0M Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 23:09:52 -0000 --001a113473da61a08a05087aa839 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See below on the issue of key derivation On Sat, Nov 22, 2014 at 1:14 AM, Martin Thomson wrote: > On 21 November 2014 19:29, Hugo Krawczyk wrote: > > I am glad to hear this too. Please let me know what the sources of > perceived > > complexity are. > > =E2=80=8B=E2=80=8B > The only items of note were: > - the second update to the handshake protection under g^{xs}+g^{xy}. > We all realized that this was trivially addressed (ekr had a slide at > the meeting that showed an easy simplification, which should be in the > meeting materials). > =E2=80=8BI haven't seen these slides and didn't know about them. The derivation of keys based on g^{xs} and g^{xy} does NOT use a sum or any other algebraic combination (although some combinations are secure, most ar= e not, and identifying the good ones is non-trivial). Anyway, I have left the details of key derivation unspecified, not because they are not important for security (they are!), but because optimizing the derivation depends on the functionality and properties one wants from the protocol and I wanted to learn more about them from these discussions. For the moment just think that a ke= y derived from the above two quantities will be computed by hashing the two values together (with some additional information) and we will model the hash as a random oracle in the cryptographic analysis. The actual derivation will be a bit more involved for the sake of better provability but not significantly different from an implementation point of view. Hugo =E2=80=8B > - the delegation scheme itself > > I don't think that you can underestimate the costs involved with > creating an external dependency of any sort - for any project. The > reliance on PKIX updates could be problematic. That said, I'm not > entirely sure that this is as straightforward a win as you suggest. > If such a flag existed, using it would create the delegation problem > we were most concerned about. > > I'll let others explain more of the thinking behind the delegation > problem. I think that it's the only real issue with your proposal > that you need to worry about. The performance characteristics are > probably manageable. > --001a113473da61a08a05087aa839 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See below on the issue of key derivation

On Sat, Nov 22= , 2014 at 1:14 AM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 21 November 2014 19:29, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
> I am glad to hear this too. Please let me know what the sources of per= ceived
> complexity are.

=E2=80=8B=E2=80=8B
The only items of = note were:
=C2=A0- the second update to the handshake protection under g^{xs}+g^{xy}.<= br> We all realized that this was trivially addressed (ekr had a slide at
the meeting that showed an easy simplification, which should be in the
meeting materials).

=E2= =80=8BI haven't seen these slides and didn't know about them.
Th= e derivation of keys based on g^{xs} and g^{xy} does NOT use a sum or anyother algebraic combination (although some combinations are secure, most = are
not, and identifying the good ones is non-trivial). Anyway, I have l= eft the
details of key derivation unspecified, not because they are not = important for
security (they are!), but because optimizing the derivatio= n depends on the
functionality and properties one wants from the protoco= l and I wanted to learn
more about them from these discussions. For the = moment just think that a key
derived from the above two quantities will = be computed by hashing the two values
together (with some additional in= formation) and we will model the hash as a random
oracle in the cryptogr= aphic analysis. The actual derivation will be a bit more
involved for th= e sake of better provability but not significantly different
from an imp= lementation point of view.

Hugo
=E2=80=8B
=C2=A0
=C2=A0- the delegation scheme itself

I don't think that you can underestimate the costs involved with
creating an external dependency of any sort - for any project. The
reliance on PKIX updates could be problematic.=C2=A0 That said, I'm not=
entirely sure that this is as straightforward a win as you suggest.
If such a flag existed, using it would create the delegation problem
we were most concerned about.

I'll let others explain more of the thinking behind the delegation
problem.=C2=A0 I think that it's the only real issue with your proposal=
that you need to worry about.=C2=A0 The performance characteristics are
probably manageable.

--001a113473da61a08a05087aa839-- From nobody Sat Nov 22 15:30:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF61A0372 for ; Sat, 22 Nov 2014 15:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6X1qsIxzEOp for ; Sat, 22 Nov 2014 15:30:10 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E009E1A0371 for ; Sat, 22 Nov 2014 15:30:09 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so2522127wid.12 for ; Sat, 22 Nov 2014 15:30:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kLYRv8IMQ8xFdNpR9L3jyeE3MORskNDJKz4xOJBH5EI=; b=K3HyUWJgrOzYQhPtagEv2qjpunND81/FV81mfzTxACCE369FUztuscHOn6gSRXz+hH GOmIh9qQUg55H6QBaDH7/BSrIiv59X8v+p0pMU3u3yUOYYLCrWVT4dk4N8FrAvFzTfkj si4SaVpp+eGRF4VjhR0hlJpvYxhoHtO8Yq9mdZT8iitVjKXkuQ3bW+X5c+7Wt/uKhgZm PDby1aK7Itew/5wHBIuZi9YVyzazkg4r18rskwmr7SeEf7dHZ+D8N6Vz443QubBJoYCE OTDcv9G24Tk2kaZCpTnX6mBr990IaEELYuUwCmERitLgnKqSl1hPVRYfV4YbDNZlAF/9 yScw== X-Gm-Message-State: ALoCoQm8YqwlFe6sfgmgy4RJsnJKcfuT2iEbsRMa7rErN7+EXtOYZgNi7LKhQlYrgpUeqaf7RzFI X-Received: by 10.194.82.104 with SMTP id h8mr20631651wjy.44.1416699008679; Sat, 22 Nov 2014 15:30:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Sat, 22 Nov 2014 15:29:28 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sat, 22 Nov 2014 15:29:28 -0800 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=047d7bb049d02a926c05087af164 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OHGnLgFTlESWKxeH_3UCIh5pR4Q Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 23:30:12 -0000 --047d7bb049d02a926c05087af164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 22, 2014 at 3:09 PM, Hugo Krawczyk wrote: > See below on the issue of key derivation > > On Sat, Nov 22, 2014 at 1:14 AM, Martin Thomson > wrote: > >> On 21 November 2014 19:29, Hugo Krawczyk wrote: >> > I am glad to hear this too. Please let me know what the sources of >> perceived >> > complexity are. >> >> =E2=80=8B=E2=80=8B >> The only items of note were: >> - the second update to the handshake protection under g^{xs}+g^{xy}. >> We all realized that this was trivially addressed (ekr had a slide at >> the meeting that showed an easy simplification, which should be in the >> meeting materials). >> > > =E2=80=8BI haven't seen these slides and didn't know about them. > The derivation of keys based on g^{xs} and g^{xy} does NOT use a sum or a= ny > other algebraic combination (although some combinations are secure, most > are > not, and identifying the good ones is non-trivial). > Note, I didn't intend addition (and I suspect Martin didn't either). I was just using '+' as shorthand for "both" and being vague about the details of the key derivation (as you suggest below). Sorry about the confusion. -Ekr --047d7bb049d02a926c05087af164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 22, 2014 at 3:09 PM, Hugo Krawczyk <hugo@ee.technion.= ac.il> wrote:
See below= on the issue of key derivation

On Sat, Nov 22, 2014 at 1:14 AM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
=
On 21 November 2014= 19:29, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
> I am glad to hear this too. Please let me know what the sources of per= ceived
> complexity are.

=E2=80=8B=E2=80=8B
The only items of note were:
=C2=A0- the second update to the handshake protection under g^{xs}+g^{xy}.<= br> We all realized that this was trivially addressed (ekr had a slide at
the meeting that showed an easy simplification, which should be in the
meeting materials).

=E2=80=8BI haven'= t seen these slides and didn't know about them.
The derivation of ke= ys based on g^{xs} and g^{xy} does NOT use a sum or any
other algebraic = combination (although some combinations are secure, most are
not, and id= entifying the good ones is non-trivial).

Note, I didn't intend addition (and I susp= ect Martin didn't either). I was just using
'+' as sh= orthand for "both" and being vague about the details of the
=
key derivation (as you suggest below). Sorry about the confusion.

-Ekr



--047d7bb049d02a926c05087af164-- From nobody Sat Nov 22 16:34:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BA41A19EA for ; Sat, 22 Nov 2014 16:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7CGakNxOo-3 for ; Sat, 22 Nov 2014 16:34:01 -0800 (PST) Received: from vsp6.ballou.se (vsp6.ballou.se [91.189.40.85]) by ietfa.amsl.com (Postfix) with SMTP id 257D21A19E9 for ; Sat, 22 Nov 2014 16:34:00 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp6.ballou.se (Halon Mail Gateway) with ESMTP; Sun, 23 Nov 2014 01:33:56 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 91A2A1DE89; Sun, 23 Nov 2014 01:33:56 +0100 (CET) Message-ID: <54712B74.70609@streamsec.se> Date: Sun, 23 Nov 2014 01:33:56 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Watson Ladd References: <5470742A.8020002@streamsec.se> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2R2KY3BfphL6FLDamOalsYzOTCs Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 00:34:03 -0000 On 2014-11-22 23:15, Watson Ladd wrote: > On Sat, Nov 22, 2014 at 3:31 AM, Henrick Hellström wrote: >> On 2014-11-22 01:57, Watson Ladd wrote: >>> >>> Was the TLS 1.3 draft written by a cryptographer? No. >>> Has it been reviewed by cryptographers? Unclear. >>> Are the mechanisms secure? Unknown. >>> Is it easy to analyze TLS 1.2? No. >>> Was TLS 1.2 secure? No. >>> Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains >>> unincluded, but the record layer is finally fixed. >> >> >> I think such discussions would benefit from the basic premise that "secure" >> is a relative notion. It is completely pointless to ask if a protocol is >> secure or not secure, unless you first present an exhaustive list of >> security claims. That is, you can't ask if TLS 1.3 is secure or not, without >> first describing what security is to be expected from different scenarios. > > It's clear what the security claims of TLS are be: a TLS connection > between two parties ensures that data sent between them isn't > intercepted or manipulated, and that they are who they claim to be. > This is a fairly standard notion, clearly present in research by the > late 80's, and intuitively sensible. > > Of course, past versions of TLS haven't provided it. OK, but in such case, the problem with BEAST would be the browser implementation dependent violation of same-origin policy constraints, and not part where the CBC state is predicted. Your requirements imply a strict same-origin policy. If such a policy is violated, the problem is that SSL/TLS is used in a scenario that transcends its security claims, and not that the protocol is flawed. From nobody Sat Nov 22 16:46:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6413F1A1A06 for ; Sat, 22 Nov 2014 16:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzmr_QB1X3Ck for ; Sat, 22 Nov 2014 16:46:13 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78331A19FF for ; Sat, 22 Nov 2014 16:46:13 -0800 (PST) Received: from pc (ip5b4005e2.dynamic.kabel-deutschland.de [::ffff:91.64.5.226]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Sun, 23 Nov 2014 01:46:10 +0100 id 000000000000005C.0000000054712E52.000060C7 Date: Sun, 23 Nov 2014 01:46:20 +0100 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: tls@ietf.org Message-ID: <20141123014620.006dfe36@pc> In-Reply-To: References: <5470742A.8020002@streamsec.se> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-24775-1416703570-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vpPqSXZck1Tje5aTlxXGzbbxsVo Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 00:46:16 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-24775-1416703570-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, 22 Nov 2014 14:15:30 -0800 Watson Ladd wrote: > It's clear what the security claims of TLS are be: a TLS connection > between two parties ensures that data sent between them isn't > intercepted or manipulated, and that they are who they claim to be. I think it's really a bit more tricky than that. Adding to these one should probably add some confidentiality claims. However what are the confidentiality claims of TLS? I don't really know. If I grab my mail through imap or pop3 I can probably assume that my password and the content of my comm is safe. However if I surf to https blog X then probably the pure size of my connection packets will reveal which article on X I'm reading right now. The CRIME attack has revealed how powerful sidechannels can be. So what exactly are the confidentiality claims of TLS? --=20 Hanno B=F6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-24775-1416703570-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUcS5cAAoJEKWIAHK7tR5C158P/jsk5GLkQc+jZW89Kxjwx/DW 6TXdOhra4/H4gBbhG3qPJ+WvNLCgxE9M/2wDROoU1zbmUISIo/ZZCYExMAqkDePd 7VRppyLn30GRT+C09I1Q+tnBSyaGOHoNGL9r50S49SzXBfIT3J2j6o9Hma7C1s+5 ecE3WxPuQBh1HTIVC1g0aVz3d01OStO3zQXAbC392wH49W7mhfwDBlB166uM6RKj YHj0Qutv2Cb69KgA77CYtYnsjDR3OGEXPK+BbZ0RfQzQpbqxm1vSW5XbWNBoRNm4 I8eGQ5BRIfuPVKRi+88+43Dr2SmsgJ2ahFp+ZgvBRs4iQf5zU2R5ilGWrBXvJpEo rK9Q7ESMvt+/nJ2mU2+5mrQp9p9VEdazCFjvO50KOH4QboPhxKT4vSA++ijgm4jH LGX2zci2lNfHo4VYeryCLExT+9BBpAlPP+Z1nO+o++N78Zh9BWgzXYcgBshZmcb+ lwCQdIBe0RfUa5/dRr67RD2QjIP7nAvai/8U9Bj7zLyuPWfDivPrdBHXa/AEoWF+ il+TEiV1FvIyxD0K8CSgEPZbgznMEo6c4GVQS4IxqSkrAbzcXXgvYeQPrv4zmOwt qPE2tOTUzm49GGgPsDULs/v5vs/Lc2RP9XKyga9XTVoeAjQCiT1m7dHmhfPfhU2N RJRJWoFaMo/5vNWRdYNy =7Vvf -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-24775-1416703570-0001-2-- From nobody Sat Nov 22 17:03:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0BD1A1A0B for ; Sat, 22 Nov 2014 17:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nloqo6GBJCDB for ; Sat, 22 Nov 2014 17:03:08 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E511B1A1A06 for ; Sat, 22 Nov 2014 17:03:07 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so5895986lbi.15 for ; Sat, 22 Nov 2014 17:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Zk4sl6AUxGPH+tyMcF+idQp/wFQuw86VPsAGFwqyh4E=; b=KfK1tTSCvSwEy42RdC15IUbVKFULialtweiz5dgwTiFTXlvWyVMr4+CfIJT/9Oe1aJ bcdqoY1Dgbcp6stqdix+1baoEZlHlsvK540IbxO0w9MbEOmFYZx2lUPH1XoInxbCSTeL BMxtTUK99Kh0JBZlmqUdx4SSwoPcNVM2Yal+SUqQ68bEulmPZqjUJV8wkpKDbUN1Oi9U AWMtM6wk3ZaUFVUHTrEB5ruXNd0knxt7DIF5rsvvr5qmHDXiGonH5qjvMSsO4Ilq+9IL ERGEP/G1dURWz3NDJM/yKlgUDYjiPwSc9rC0FY9M/1qc99LUjuNu3jni/EMySGK6UcxD OY0Q== X-Received: by 10.112.156.138 with SMTP id we10mr12004899lbb.88.1416704586154; Sat, 22 Nov 2014 17:03:06 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.135 with HTTP; Sat, 22 Nov 2014 17:02:35 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Sat, 22 Nov 2014 20:02:35 -0500 X-Google-Sender-Auth: UWvH3JWin-Y6mf4eNfHKOYglMro Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c344c89c0a6205087c3da5 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7bfmQnokUiNERfch1rPwb5UosNo Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 01:03:10 -0000 --001a11c344c89c0a6205087c3da5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought that was what you meant but at least Watson seemed to be interpreting in the arithmetic sense and he was right to point out that it would be insecure to do so. On Sat, Nov 22, 2014 at 6:29 PM, Eric Rescorla wrote: > > > On Sat, Nov 22, 2014 at 3:09 PM, Hugo Krawczyk > wrote: > >> See below on the issue of key derivation >> >> On Sat, Nov 22, 2014 at 1:14 AM, Martin Thomson > > wrote: >> >>> On 21 November 2014 19:29, Hugo Krawczyk wrote= : >>> > I am glad to hear this too. Please let me know what the sources of >>> perceived >>> > complexity are. >>> >>> =E2=80=8B=E2=80=8B >>> The only items of note were: >>> - the second update to the handshake protection under g^{xs}+g^{xy}. >>> We all realized that this was trivially addressed (ekr had a slide at >>> the meeting that showed an easy simplification, which should be in the >>> meeting materials). >>> >> >> =E2=80=8BI haven't seen these slides and didn't know about them. >> The derivation of keys based on g^{xs} and g^{xy} does NOT use a sum or >> any >> other algebraic combination (although some combinations are secure, most >> are >> not, and identifying the good ones is non-trivial). >> > > Note, I didn't intend addition (and I suspect Martin didn't either). I wa= s > just using > '+' as shorthand for "both" and being vague about the details of the > key derivation (as you suggest below). Sorry about the confusion. > > -Ekr > > > > --001a11c344c89c0a6205087c3da5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought that was what you meant but at least = Watson seemed to be interpreting in the arithmetic sense and he was right t= o point out that it would be insecure to do so.

On Sat, Nov 22, 2014 at 6:2= 9 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Nov 22, 2014 at 3:09 PM, Hugo Kra= wczyk <hugo@ee.technion.ac.il> wrote:
See below on the issue of key derivation

On Sat, Nov 22,= 2014 at 1:14 AM, Martin Thomson <martin.thomson@gmail.com><= /span> wrote:
On 21 November 2014 19:29, Hugo Krawczyk <hugo@ee.technion.ac.il> wro= te:
> I am glad to hear this too. Please let me know what the sources of per= ceived
> complexity are.

=E2=80=8B=E2=80=8B
The only items of note were:
=C2=A0- the second update to the handshake protection under g^{xs}+g^{xy}.<= br> We all realized that this was trivially addressed (ekr had a slide at
the meeting that showed an easy simplification, which should be in the
meeting materials).

=E2=80=8BI haven'= t seen these slides and didn't know about them.
The derivation of ke= ys based on g^{xs} and g^{xy} does NOT use a sum or any
other algebraic = combination (although some combinations are secure, most are
not, and id= entifying the good ones is non-trivial).

Note, I didn't intend addition (and= I suspect Martin didn't either). I was just using
'+'= ; as shorthand for "both" and being vague about the details of th= e
key derivation (as you suggest below). Sorry about the confusio= n.

-Ekr



--001a11c344c89c0a6205087c3da5-- From nobody Sat Nov 22 17:21:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18C01A1A32 for ; Sat, 22 Nov 2014 17:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzSEYYslKcSl for ; Sat, 22 Nov 2014 17:21:32 -0800 (PST) Received: from vsp8.ballou.se (vsp8.ballou.se [91.189.40.104]) by ietfa.amsl.com (Postfix) with SMTP id 9FF6C1A1A27 for ; Sat, 22 Nov 2014 17:21:30 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp8.ballou.se (Halon Mail Gateway) with ESMTP for ; Sun, 23 Nov 2014 02:21:27 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id D49041DE89 for ; Sun, 23 Nov 2014 02:21:27 +0100 (CET) Message-ID: <54713697.2050904@streamsec.se> Date: Sun, 23 Nov 2014 02:21:27 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <5470742A.8020002@streamsec.se> <20141123014620.006dfe36@pc> In-Reply-To: <20141123014620.006dfe36@pc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f8wrZsFIFe0aOmomTf4Wsn8o4BA Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 01:21:34 -0000 On 2014-11-23 01:46, Hanno Böck wrote: > On Sat, 22 Nov 2014 14:15:30 -0800 > Watson Ladd wrote: > >> It's clear what the security claims of TLS are be: a TLS connection >> between two parties ensures that data sent between them isn't >> intercepted or manipulated, and that they are who they claim to be. > > I think it's really a bit more tricky than that. > > Adding to these one should probably add some confidentiality claims. > However what are the confidentiality claims of TLS? I don't really know. IND-CCA2 would cover a lot, in terms of both confidentiality and integrity, even under partial chosen plain text or chosen cipher text. From nobody Sun Nov 23 05:27:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4701A0278 for ; Sun, 23 Nov 2014 05:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7zgObsrL7NI for ; Sun, 23 Nov 2014 05:27:28 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022471A024C for ; Sun, 23 Nov 2014 05:27:26 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so10390145wgh.37 for ; Sun, 23 Nov 2014 05:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xWeXLX3Au8RRkPwNa0c9yabpXU+fg+4nUdYt3TowOx4=; b=LoD4aVhKkpKwKRaMp8VcTeVwCDBtfrm2x0bQqQ7ZeMagqPKhHQeYeX4dGCHkYnhbJs ehzQt8c1BImOpwabOnfLI1UwtfYTs9CxdddkTW2dB/HXakvwlL+526oTjYRKMTSiPwAO Wb/CNJrI77tgx3yyXEsvtooXRAW5AKuVRuhbFVdCtMbNm5cuastBPFKr67H3J1bkhDal QbjFJ68/FTTHsasDR7+R+ds0unlS9WADmibedTZ2CeaV7Q1am4LDsFEkNz3TvRD74l/V GYJvovsFSKB6JzPpWRaxDC7civ9v+nc6gJeoZpLMbYvXx9k2r3pkFcLs54KLiGWVuoCB XK/w== MIME-Version: 1.0 X-Received: by 10.194.237.162 with SMTP id vd2mr25186930wjc.52.1416749245369; Sun, 23 Nov 2014 05:27:25 -0800 (PST) Received: by 10.216.154.6 with HTTP; Sun, 23 Nov 2014 05:27:25 -0800 (PST) In-Reply-To: References: <5470742A.8020002@streamsec.se> Date: Sun, 23 Nov 2014 14:27:25 +0100 Message-ID: From: Ralph Holz To: Watson Ladd Content-Type: multipart/alternative; boundary=089e013d149c819512050886a3bd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GQW3aCS8ZBelIzXyDAohaWkapr0 Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 13:27:44 -0000 --089e013d149c819512050886a3bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd disagree with the notion of "it is clear what TLS supports" - there is no threat model describing the strength of an attacker (and there never has been). It's not even clear what TLS means by "authentication". As a possible step forward, we could say TLS supports authentication as Lowe's injective agreement - a fairly strong definition yet one matching intuitive expectation. On 22 November 2014 at 23:15, Watson Ladd wrote: > On Sat, Nov 22, 2014 at 3:31 AM, Henrick Hellstr=C3=B6m > wrote: > > On 2014-11-22 01:57, Watson Ladd wrote: > >> > >> Was the TLS 1.3 draft written by a cryptographer? No. > >> Has it been reviewed by cryptographers? Unclear. > >> Are the mechanisms secure? Unknown. > >> Is it easy to analyze TLS 1.2? No. > >> Was TLS 1.2 secure? No. > >> Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains > >> unincluded, but the record layer is finally fixed. > > > > > > I think such discussions would benefit from the basic premise that > "secure" > > is a relative notion. It is completely pointless to ask if a protocol i= s > > secure or not secure, unless you first present an exhaustive list of > > security claims. That is, you can't ask if TLS 1.3 is secure or not, > without > > first describing what security is to be expected from different > scenarios. > > It's clear what the security claims of TLS are be: a TLS connection > between two parties ensures that data sent between them isn't > intercepted or manipulated, and that they are who they claim to be. > This is a fairly standard notion, clearly present in research by the > late 80's, and intuitively sensible. > > Of course, past versions of TLS haven't provided it. > > > > > In a sense, *every* protocol has the potential of becoming broken, > unless it > > is unambiguously defined what is proper and improper usage of the > protocol. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e013d149c819512050886a3bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd disagree with the notion of "it is clear what= TLS supports" - there is no threat model describing the strength of a= n attacker (and there never has been). It's not even clear what TLS mea= ns by "authentication".

As a possible step for= ward, we could say TLS supports authentication as Lowe's injective agre= ement - a fairly strong definition yet one matching intuitive expectation.<= /div>

On 22 = November 2014 at 23:15, Watson Ladd <watsonbladd@gmail.com> wrote:
On Sat, Nov 2= 2, 2014 at 3:31 AM, Henrick Hellstr=C3=B6m <henrick@streamsec.se> wrote:
> On 2014-11-22 01:57, Watson Ladd wrote:
>>
>> Was the TLS 1.3 draft written by a cryptographer? No.
>> Has it been reviewed by cryptographers? Unclear.
>> Are the mechanisms secure? Unknown.
>> Is it easy to analyze TLS 1.2? No.
>> Was TLS 1.2 secure? No.
>> Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains
>> unincluded, but the record layer is finally fixed.
>
>
> I think such discussions would benefit from the basic premise that &qu= ot;secure"
> is a relative notion. It is completely pointless to ask if a protocol = is
> secure or not secure, unless you first present an exhaustive list of > security claims. That is, you can't ask if TLS 1.3 is secure or no= t, without
> first describing what security is to be expected from different scenar= ios.

It's clear what the security claims of TLS are be: a TLS connect= ion
between two parties ensures that data sent between them isn't
intercepted or manipulated, and that they are who they claim to be.
This is a fairly standard notion, clearly present in research by the
late 80's, and intuitively sensible.

Of course, past versions of TLS haven't provided it.

>
> In a sense, *every* protocol has the potential of becoming broken, unl= ess it
> is unambiguously defined what is proper and improper usage of the prot= ocol.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--089e013d149c819512050886a3bd-- From nobody Sun Nov 23 13:40:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD821A1AAD for ; Sun, 23 Nov 2014 13:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GVVyAIl5SEK for ; Sun, 23 Nov 2014 13:40:34 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF6C1A01D8 for ; Sun, 23 Nov 2014 13:40:34 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so7826756ier.14 for ; Sun, 23 Nov 2014 13:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A7AgsaSKGdU/NOr/Dt7wxyKoSPbGE79Jbq+doh8jZU4=; b=V/daHn9S1B8YD/2ekjIW2inuVFCCg5mSxM4Mzs1KMyb9QOkUw1gPtIENSUVKKNNmvq W2sOtpALKAK2KFnRyXfb2/+ni+h1Kf2Pljj2RFefEH+iTiK6FL7F34phxgTyNzAx9GmR b9hkiBXUFGIHw/KZEkyu0MDzpOzrLEJCIueimURX+50P6qUsQKVcgmScKWuURPBZEPg6 7AL2o70XkJd4hYmHlQorgcm+UTAp3kCL5qe99jRk4h/IU43xAxOQT//tOI2Lp+X2sZHX DY+2vB3c1BftdIHeaC8eOq679Pyw4ie+qqOXk2t6185Sbu5rSZJooFdT+vdTmyu/H7jO bGVg== MIME-Version: 1.0 X-Received: by 10.50.114.199 with SMTP id ji7mr8145166igb.49.1416778833057; Sun, 23 Nov 2014 13:40:33 -0800 (PST) Received: by 10.107.134.170 with HTTP; Sun, 23 Nov 2014 13:40:32 -0800 (PST) In-Reply-To: References: <5470742A.8020002@streamsec.se> Date: Sun, 23 Nov 2014 16:40:32 -0500 Message-ID: From: Jeffrey Walton To: Ralph Holz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/85sOOY2ulvorq_QvgnRMdASmq-M Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:40:35 -0000 On Sun, Nov 23, 2014 at 8:27 AM, Ralph Holz wrote: > I'd disagree with the notion of "it is clear what TLS supports" - there is > no threat model describing the strength of an attacker (and there never has > been). It's not even clear what TLS means by "authentication". +1. The charter could be a bit more clear about the security goals and objectives. The current charter is more like a TODO or task list. The task list is good, but the overall goals and objectives would be even better. Watson's statement about "interception free connection (sic)" caught my eye. That's never been a goal (cf., http://datatracker.ietf.org/wg/tls/history/). In fact, the IETF seem to accommodate interception in its standards, which makes me wonder if its an unwritten agenda. For example, Public Key Pinning opaquely accommodates interception by allowing attackers to break pinsets (cf. Section 2.7 of https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21). And the ability to surreptitiously break a pinset is not listed in security considerations. Interception support is so pervasive at times I'm wondering when the PKIX WG is going to allocate INTERCEPTION as a certificate Key Usage. From nobody Sun Nov 23 14:15:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7661A1B14 for ; Sun, 23 Nov 2014 14:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBIatYip3jRJ for ; Sun, 23 Nov 2014 14:15:50 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.103.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E011A1A69 for ; Sun, 23 Nov 2014 14:15:49 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 280C96A8368E2; Sun, 23 Nov 2014 16:15:49 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 16F506A836899 for ; Sun, 23 Nov 2014 16:15:49 -0600 (CST) Received: from [147.28.0.178] (port=58739 helo=vpn178.sea.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XsfRb-0004qo-3J for tls@ietf.org; Sun, 23 Nov 2014 16:15:48 -0600 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 23 Nov 2014 09:49:42 -1000 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 147.28.0.178 X-Exim-ID: 1XsfRb-0004qo-3J X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (vpn178.sea.rg.net) [147.28.0.178]:58739 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/swONyTQ2EqU9TLH_5EzoeO-Ibi8 Subject: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 22:15:51 -0000 This is the working group last call for = http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/. Please = review the document and send your comments to the list by Friday, = December 12, 2014. =20 Thanks, J&S= From nobody Sun Nov 23 16:12:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9B1A1B66 for ; Sun, 23 Nov 2014 16:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaYtj2yDxB_O for ; Sun, 23 Nov 2014 16:12:52 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451781A1B65 for ; Sun, 23 Nov 2014 16:12:52 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so6157568qcv.15 for ; Sun, 23 Nov 2014 16:12:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=g34H/cduIQUzTV37YR+GKH/x5HSHWV0smnxAhZW5b8g=; b=WHnuVMTr1GQBlvWUGVOgbZWjiCKDiMYoVu+HNOm1zfG867+f2ZSKqCD+3BNL0pxYi9 3SVld2SR+v4NOYrE6EDqUJfbKmmlHnY5NFBHoT2X1ncu58G1T0QFOoJeMBY55eEJbi7J fhijN5k15RfA6iD+ckLtRmUxM+e143a0IWewQkbkQXLICbrZNoSQnGergmgGVorwokZ/ 9UbC6ghYQ8Zkuqpniq7unggg0cGVtlVtJjTsdPVXxIab2iDrTXTeZaBQDWfTWvKVFdpR b+74YwJroZHfGii37drocTohkTk0DKBGaJzLly5yTwDhYO7VsSSwt17Ww41ZrxgAsWlb au3A== X-Gm-Message-State: ALoCoQlyOcJAyrcFdOeHN5nVZionvE/MsSCiJoh3QfDYEDLVPq3crOSQeWYMMV2LdILaFS2FwA0e X-Received: by 10.224.30.74 with SMTP id t10mr25930623qac.8.1416787971432; Sun, 23 Nov 2014 16:12:51 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id o30sm8216327qge.33.2014.11.23.16.12.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Nov 2014 16:12:50 -0800 (PST) Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 11930AC2842 for ; Sun, 23 Nov 2014 19:12:47 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: Date: Sun, 23 Nov 2014 19:12:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0AD24619-98DE-4D23-922A-E856B7B5B279@pahtak.org> References: To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/j3ZVo6F7pKKxypge10kcRfQAVrI Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 00:12:54 -0000 On Nov 23, 2014, at 2:49 PM, Sean Turner wrote: > This is the working group last call for = http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/. Please = review the document and send your comments to the list by Friday, = December 12, 2014. =20 Minor editorial comments: Synchronization of the "verify_data" in abbreviated handshakes also undermines the security guarantees of the renegotiation indication extension [RFC5746], re-enabling a prefix-injection flaw similar to the renegotiation attack [Ray09]. However, in a triple handshake attack, the client sees the server certificate changing across different full handshakes. Hence, a precondition to mount this stage of the attack is that the client accepts different certificates at each handshake, even if their common names do not match. Before the triple handshake attack was discovered, this used to be widespread behavior, at least among some web browsers, that where hence vulnerable to the attack. 1. I think it should be "...accepts different certificates _for_ each = handshake..." 2. I'm not entirely sure what the final sentence is saying. It doesn't = make sense for "the attack" to refer to the triple handshake attack = (which is the most recently mentioned attack). Is it saying that = browsers were vulnerable to a prefix-injection attack =E0 la the = renegotiation attack (which is referred to as a flaw rather than attack = in the paragraph)? 3. "that where hence" should be something else, but I'm not sure what = exactly that sentence means. --=20 Stephen Checkoway From nobody Sun Nov 23 22:33:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2D41A1BDD for ; Sun, 23 Nov 2014 22:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.634 X-Spam-Level: * X-Spam-Status: No, score=1.634 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSlR48AtCT4x for ; Sun, 23 Nov 2014 22:33:07 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA75E1A1BE5 for ; Sun, 23 Nov 2014 22:33:07 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 3946E1DE060; Sun, 23 Nov 2014 22:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0Ge6GUpn/osXem h+hxW1Xjk3NcY=; b=RnWTb6SVfP8UOGFoKWJgDWQ6Hdlk2XpfAxz40sRjo5kAYs 9GiQHPNQRESVILTmm6fKSknWaZtVbeevFnmoAKZZpfovL9CRlF7kxMzzox3DUp/k gYsUdiuZToljkDjx9o4Zeny+SLZSs0CGKKswrItvCKYLxctRsLGyplQD8eeRs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id D9E741DE05D; Sun, 23 Nov 2014 22:33:06 -0800 (PST) Date: Mon, 24 Nov 2014 00:33:06 -0600 From: Nico Williams To: Hugo Krawczyk Message-ID: <20141124063304.GA3200@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gpcGfbbVMfxXaUy08CtY7mtlg3Q Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 06:33:08 -0000 I'm in favor of using static server (EC)DH keys for server authentication and possible 0-RTT, particularly in connection with DANE. I *don't* think that OPTLS is worthwhile without connection to DANE, but only because OPTLS is just an optimization with roughly the same applicability as an existing optimization that is much faster: session resumption [with encrypted session state tickets]. But since I think sprinkling DANE on is the obvious thing to do given OPTLS as part of the protocol, I'm in favor. Security-wise the use of static (EC)DH keys is well-understood (as well understood as (EC)DH is in general). The g^xs plus (not the arithmetic operator) g^xy method of obtaining PFS is also OK, and heck, if need be the client could use two different x's, and the protocol ought to allow it (not least because the client might want to use different groups/ curves for PFS key agreement than for authentication key agreement). Nico -- From nobody Sun Nov 23 22:47:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34F21A1BEA for ; Sun, 23 Nov 2014 22:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEOk7BENOvwr for ; Sun, 23 Nov 2014 22:47:10 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 224811A1B62 for ; Sun, 23 Nov 2014 22:47:10 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 06E8520047B84; Sun, 23 Nov 2014 22:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=YwuWhz6Yj9dcWc ajcKRdyc8qHRc=; b=rAcg/sE8didfDWFyDpxCjfIfCSI1D/pybezuzU1poJBfT2 Oo3zb6evMpo5ierukC2DBAlaL8tGnLSjCsq7iZAvldnctCK0yRLFDym9MmKXM9pK 3lnDoyraDl8/uQ37dUEYJPf0p22yggpzvN0j3lHjkaLSHqji/NNNBPwlgIPpc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id A959220047B82; Sun, 23 Nov 2014 22:47:09 -0800 (PST) Date: Mon, 24 Nov 2014 00:47:09 -0600 From: Nico Williams To: Watson Ladd Message-ID: <20141124064707.GB3200@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> <20141119205117.GE20758@localhost> <20141121185136.GF20758@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/65LhtvqF6g8_EPzaQ_0KkOc5_HA Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 06:47:11 -0000 On Fri, Nov 21, 2014 at 04:55:23PM -0800, Watson Ladd wrote: > On Fri, Nov 21, 2014 at 10:51 AM, Nico Williams wrote: > >> > It's much easier to have the server hold the > >> > early data and have it bound into the client's next handshake msg. Actually, there's no need to bind early data into the handshakes. It's enough that the client has to eventually confirm a handshake message from the server, and for good measure the client should switch to a key to which the server contributed before sending non-early data. Then the server can detect replays. However, the security consideration remains that replay detection for early data is not available until the handshake completes. Thus early data bearing messages like "launch missiles" must not be acted upon until the handshake completes. This is a fairly severe security consideration... > Why wouldn't the implementation of TLS automatically resend 0-RTT data > if the server didn't accept it? This seems like the right solution. Agreed. In the case of the server not having the key with which to decrypt the early data the only available choices are: a) abort, b) notify the client app and let it abort or retransmit, c) hold on to the early data for retransmission. (a) is not a good idea, and (b) is probably too complicated (as are all of these security considerations) for many apps, which leaves (c) (your suggestion) as the best approach to the problem of the client using a stale key (e.g., a session resumption ticket for which the server forgot the key) for 0-RTT early data. Nico -- From nobody Mon Nov 24 00:16:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEAB1A1BF9 for ; Mon, 24 Nov 2014 00:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MoH20DzjnuJ for ; Mon, 24 Nov 2014 00:16:33 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621771A1BE3 for ; Mon, 24 Nov 2014 00:16:33 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAO8GWnV016853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 03:16:32 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAO8GTeQ023470 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 03:16:31 -0500 Message-ID: <1416816989.2533.7.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Kurt Roeckx Date: Mon, 24 Nov 2014 09:16:29 +0100 In-Reply-To: <20141122105659.GA26446@roeckx.be> References: <5462714E.5020201@polarssl.org> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> <1052358743.2229177.1416652827952.JavaMail.zimbra@redhat.com> <20141122105659.GA26446@roeckx.be> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Rdh1TGljNNTfye3GAretIzltNlQ Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 08:16:34 -0000 On Sat, 2014-11-22 at 11:56 +0100, Kurt Roeckx wrote: > On Sat, Nov 22, 2014 at 05:40:27AM -0500, Nikos Mavrogiannopoulos wrote: > > That highlights the main difference > > with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it was published. > > There still are SSLv2 only services on the internet. Hubert Kario > last scan results > (https://lists.fedoraproject.org/pipermail/security/2014-October/001989.html) > said: > Supported Protocols Count Percent > -------------------------+---------+------- > SSL2 44800 10.2755 > SSL2 Only 5536 1.2698 I believe that this shows more about issues with the sample of the test rather than functioning SSLv2 only servers. Given that there is no way to connect to them anyway, they could be misconfigured non functional servers or honeypots. regards, Nikos From nobody Mon Nov 24 00:44:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C4D1A1BFA for ; Mon, 24 Nov 2014 00:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuspCnTaes9V for ; Mon, 24 Nov 2014 00:44:42 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603B01A1BF2 for ; Mon, 24 Nov 2014 00:44:42 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so11818696wgg.35 for ; Mon, 24 Nov 2014 00:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oXDPINe88iUQSOfalrvu0lABtDNMSx+PRnh651L2dL0=; b=gh0usslA6xhgk3aTQpXwODYJCJBAIn4mI1yLK1RkGsHpWtm+iUQgXNL4M3NZv98zbg fUGPVPlSkxRdE6eXJNv/O0sj4HJqvDh6QijARMx+/+knWNETcna0+mc9qurMNRDU6/GI D51hB1bH9OM67KOrPuuBN7EMSVn3QQkL7GawyNbSnAF+DjiqSi9ztMeatDdf63yrQjj4 1X+WLrhZRKgfeZJK1QTiSsNAY7RpnbJPvAbEBzbMfa6YC3EVwPbbcQHISQThsy2nPD4B tCarl9OID9ikQ5KZfrIsU4jpNVotCCc1gnKfZkbgHueWg5cH9Si0AgHiW9ItuN/+LoAQ fv6w== X-Received: by 10.194.121.167 with SMTP id ll7mr25395469wjb.26.1416818681123; Mon, 24 Nov 2014 00:44:41 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id mc10sm11001602wic.24.2014.11.24.00.44.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 00:44:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Mon, 24 Nov 2014 10:44:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> References: To: Sean Turner X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NloS3ANl-F7mp_ucJkSelIF9ReA Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 08:44:44 -0000 Hi. I hadn=E2=80=99t read this before, so these issues may have been = discussed before. Sorry if I=E2=80=99m wasting time like this. The following paragraph from the Introduction is weird: Similar scenarios can be achieved when the handshake uses a DHE ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit curve. Even if the client or server does not prefer using RSA or DHE, the attacker can force them to use it by offering only RSA or DHE in its hello messages. Other key exchanges may also be vulnerable. The first sentence says that (EC)DHE ciphersuites are also vulnerable = with explicit params. The last sentence talks of "other key exchanges", = which in practice means DHE or ECDHE with named groups or curves. But = that lower case =E2=80=9Cmay=E2=80=9D is content-free. Suppose a new = server supports only ECDHE ciphersuites with named curves (there are = some popular web sites that do this today), does it also need the = session hash extension? This is not covered in either the introduction = or the security considerations. Second issue: The draft does not say whether a server should include the = extension in a resumed session. The extension has no effect (as section = 5.1 says), but it should be specified one way or the other. I would go = for the less meaningless bytes option. Third issue: Why can=E2=80=99t an attacker disable this protection by = simply omitting the extension from both its ClientHello and ServerHello? = At least in the short term it won=E2=80=99t be practical to fail a = handshake because the other side doesn=E2=80=99t support this extension. = I guess the answer is that the ruse will work, but the other attacks = mentioned in TRIPLE-HS will fail, but it=E2=80=99s not clear to me why. = A can still proxy unchanged records from C to S if the connections are = resumptions. Perhaps servers should be prohibited from resuming a = session set up without this extension if the ClientHello does include = the extension. Yoav > On Nov 23, 2014, at 9:49 PM, Sean Turner wrote: >=20 > This is the working group last call for = http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/. Please = review the document and send your comments to the list by Friday, = December 12, 2014. =20 >=20 > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Nov 24 02:17:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284F21A1E0C for ; Mon, 24 Nov 2014 02:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1k37yUTCE5F for ; Mon, 24 Nov 2014 02:17:47 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D0AAB1A1B24 for ; Mon, 24 Nov 2014 02:17:47 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 07DA143807E; Mon, 24 Nov 2014 02:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=000mNcx3VY0uLv eoxlyWvUfuCEs=; b=Jo9NYbUDqBhVLB/jFwvH3cCi3ea0aGfLZ1Obj1nFVSkaMC 2iscEaUEUjI28p7abEVg9dOtGZHS1yJoepVLMxLF4/LLLB/MEwfHmmuWZDAd4KnN mehsJMv9ta6ef61lXbcJ7YPwB5zmikk6PVVsp/07unqYy5xi8QVA2nRU0ceMU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id B0EF643801C; Mon, 24 Nov 2014 02:17:46 -0800 (PST) Date: Mon, 24 Nov 2014 04:17:46 -0600 From: Nico Williams To: Watson Ladd Message-ID: <20141124101744.GC3200@localhost> References: <5470742A.8020002@streamsec.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WVdMP9Kd5EiXTS35zNSr_vrVSlI Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:17:49 -0000 On Sat, Nov 22, 2014 at 02:15:30PM -0800, Watson Ladd wrote: > It's clear what the security claims of TLS are be: a TLS connection > between two parties ensures that data sent between them isn't > intercepted or manipulated, and that they are who they claim to be. > This is a fairly standard notion, clearly present in research by the > late 80's, and intuitively sensible. It's the standard Internet threat model. Aside from needing to be updated for massive adversay capabilities, the standard Internet threat model has held up well. What hasn't held up is TLS: > Of course, past versions of TLS haven't provided it. > > > In a sense, *every* protocol has the potential of becoming broken, > > unless it is unambiguously defined what is proper and improper usage > > of the protocol. We don't have a crystal ball. All we have is fairly decent (but almost certainly incomplete) public understanding of cryptography, and a fairly decent idea of today's applications' needs. We can imagine the near future and plan accordingly, but further out we run into trouble. I don't think we necessarily need, e.g., an explicit statement that resistance to BEAST/CRIME style attacks is required: the standard Internet threat model implies it. Though it doesn't hurt to list all of TLS's (and other protocols') vulnerabilities, of course... It also helps to design application protocols where BEAST/CRIME type attacks are of little use. I.e., we need better session continuation for HTTP than plain cookies. But we can't make that happen from the TLS layer, and we must act accordingly (besides, improving HTTP session continuation has proven to be a very difficult task). Nico -- From nobody Mon Nov 24 02:31:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756FA1A1EF9 for ; Mon, 24 Nov 2014 02:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThQn2NF_qdeZ for ; Mon, 24 Nov 2014 02:31:10 -0800 (PST) Received: from vsp3.ballou.se (vsp3.ballou.se [91.189.40.101]) by ietfa.amsl.com (Postfix) with SMTP id 57DEE1A1EEF for ; Mon, 24 Nov 2014 02:31:09 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp3.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 24 Nov 2014 11:31:05 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 6E6531DE89; Mon, 24 Nov 2014 11:31:05 +0100 (CET) Message-ID: <547308E2.6060809@streamsec.se> Date: Mon, 24 Nov 2014 11:30:58 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams , Watson Ladd References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> In-Reply-To: <20141124101744.GC3200@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fF5eIjCdPTV8-nmrkF34prtwo-o Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:31:12 -0000 On 2014-11-24 11:17, Nico Williams wrote: > On Sat, Nov 22, 2014 at 02:15:30PM -0800, Watson Ladd wrote: >> It's clear what the security claims of TLS are be: a TLS connection >> between two parties ensures that data sent between them isn't >> intercepted or manipulated, and that they are who they claim to be. >> This is a fairly standard notion, clearly present in research by the >> late 80's, and intuitively sensible. > > It's the standard Internet threat model. Aside from needing to be > updated for massive adversay capabilities, the standard Internet threat > model has held up well. What hasn't held up is TLS: > >> Of course, past versions of TLS haven't provided it. >> >>> In a sense, *every* protocol has the potential of becoming broken, >>> unless it is unambiguously defined what is proper and improper usage >>> of the protocol. > > We don't have a crystal ball. All we have is fairly decent (but almost > certainly incomplete) public understanding of cryptography, and a > fairly decent idea of today's applications' needs. We can imagine the > near future and plan accordingly, but further out we run into trouble. > > I don't think we necessarily need, e.g., an explicit statement that > resistance to BEAST/CRIME style attacks is required: the standard > Internet threat model implies it. Actually, no, it doesn't. The Internet threat model is based on the premise that both ends are uncompromised. If the client is allowing third party javascript to connect to arbitrary HTTPS servers, impersonating the client that runs the script, that client is compromised. From nobody Mon Nov 24 02:36:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386781A1EEF for ; Mon, 24 Nov 2014 02:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeyV8ArZiDEJ for ; Mon, 24 Nov 2014 02:36:24 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AEC1A1EFC for ; Mon, 24 Nov 2014 02:36:23 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so1530830lbv.39 for ; Mon, 24 Nov 2014 02:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=12LTfRv94HTGhKzBAHxE2G+L0ZRVarLwlbq3jm5HEXI=; b=KtGVMwjC30omwHzjquUjaaUBuSqvBOL9i19ZdsBhEC4KfUtVdxytDSffzwfWdLMS1I vseXCWWDNJrrZ5gyHehiJOT+rhSRdt5T7s0dU/QkjN4Zn2DEOxr9i8qIEWxVBJiK/m4y xwdvdlO4xU5ZEWDe+tTmsEPTJuNv50JCTvvi15dx1ZKPdDcmKev4iRNdCpD5ycCxUV7W azuZ9aXcGxvAFQpVQdI0YsZaKY+CJ2nrSar7E8YTJuiKzdIl58h4XxDy4/JO/vBMzs0h UqjtGaX6vN/HXKRT8TulA4xW+Ld61PDrB1bTHX5YHdcxpJdYXzyg9EIiPOi+f8XyQ+mM iV1Q== MIME-Version: 1.0 X-Received: by 10.153.11.133 with SMTP id ei5mr19752015lad.75.1416825382279; Mon, 24 Nov 2014 02:36:22 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Mon, 24 Nov 2014 02:36:22 -0800 (PST) In-Reply-To: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> References: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> Date: Mon, 24 Nov 2014 02:36:22 -0800 X-Google-Sender-Auth: DJXrF-LJa98MRNx-3j_vbCjzATs Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_QcEru8EqLilwcIb6ffELmTzKW8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:36:25 -0000 On Mon, Nov 24, 2014 at 12:44 AM, Yoav Nir wrote: > The first sentence says that (EC)DHE ciphersuites are also vulnerable wit= h explicit params. The last sentence talks of "other key exchanges", which = in practice means DHE or ECDHE with named groups or curves. But that lower = case =E2=80=9Cmay=E2=80=9D is content-free. Suppose a new server supports o= nly ECDHE ciphersuites with named curves (there are some popular web sites = that do this today), does it also need the session hash extension? This is = not covered in either the introduction or the security considerations. I think that last sentence was roughly aimed to mean: "other key exchanges (i.e. SRP, Kerberos, PSK), and future ones, may also have properties that allow for this attack. We're not going to worry about analysing them and instead will solve the problem in general (we hope)." But clearly some work tweaking is called for as that's evidently not completely clear. > Second issue: The draft does not say whether a server should include the = extension in a resumed session. The extension has no effect (as section 5.1= says), but it should be specified one way or the other. I would go for the= less meaningless bytes option. Sure, let's say that the server SHOULD NOT echo it. (And I'll make a note to check my implementations for that.) > Third issue: Why can=E2=80=99t an attacker disable this protection by sim= ply omitting the extension from both its ClientHello and ServerHello? Writing this down might be called for too. In practice, I'm implementing it so that calls to get tls-unique values and the like will fail on resumed connections where the original session did not use this extension. Cheers AGL From nobody Mon Nov 24 02:37:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5D91A1EFD for ; Mon, 24 Nov 2014 02:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAwB5rMyoU-I for ; Mon, 24 Nov 2014 02:37:49 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DC38E1A1EEF for ; Mon, 24 Nov 2014 02:37:49 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id A771B50808E; Mon, 24 Nov 2014 02:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=/I+TNvKHb5nGai 1YG8f1mlQ6eBA=; b=k9xyYLGa8Vgln78OriG/TBganlDORe4aEUZHrNHoMwJdHg KZIZb4sMZJbl7jaSxNlV6A1nkMi/hw/lar0G0JlW5p+QNu8XANaz5h6pt5rSD1K5 gp7+jmQgcRqKXhWnwF04uoGzwk8FelXUb+azeWHStbvF95VPpM9tBvf39FLKE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 46F61508072; Mon, 24 Nov 2014 02:37:49 -0800 (PST) Date: Mon, 24 Nov 2014 04:37:48 -0600 From: Nico Williams To: Ralph Holz Message-ID: <20141124103747.GD3200@localhost> References: <5470742A.8020002@streamsec.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/95PTDfiWut-KAksRwebEvRYs1II Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:37:50 -0000 On Sun, Nov 23, 2014 at 02:27:25PM +0100, Ralph Holz wrote: > I'd disagree with the notion of "it is clear what TLS supports" - there is > no threat model describing the strength of an attacker (and there never has > been). It's not even clear what TLS means by "authentication". This is true, and it is partly why we need algorithm agility: to trade-off performance/cost for security in a context-sensitive manner. Network security is an extension of physical security (if your hardware or the software it runs aren't secure...). If we assume physical security (a big assumption) then we can get perfect security at very high cost: e.g., every communicating pair of nodes meets physically to securely exchange one time pads. But we know that's too costly (it doesn't scale, for one), so out the window goes perfection. Everything we're doing (DNSSEC, DPRIV, CT, ...) is just an exercise in asymptotically approaching perfection. > As a possible step forward, we could say TLS supports authentication as > Lowe's injective agreement - a fairly strong definition yet one matching > intuitive expectation. That's implied in the Internet threat model, really. We should make some things more explicit, of course (e.g., we need liveness). Of course, in some cases we are willing to trade some features off (e.g., certificate status freshness tolerance vs. performance, or 0-RTT early data transmission). See above about trade-offs. Nico -- From nobody Mon Nov 24 02:42:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DAF1A1EF8 for ; Mon, 24 Nov 2014 02:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtFZqE9nx-zN for ; Mon, 24 Nov 2014 02:42:30 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 484581A1EEF for ; Mon, 24 Nov 2014 02:42:30 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 2A4DA674060; Mon, 24 Nov 2014 02:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=R/Rhf+omy/dwNPd5n0iz4unzK9E=; b=uahBgujuBcR n8wAKbPMH0rpsdNnU6XJ7BeL943jruo9gEk5fAVB1kt0QLJOFUueaqOuw3/8SKzQ vdi0XNsU8uMlAAHKxlcH3TbjxEpYZ3iKZ/PSTeqBMSdFvnhDdydrXjPOr8ER9spc l8DvxsI73Aodr4atCBVzx+s3cITjTmkg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id D60DB674059; Mon, 24 Nov 2014 02:42:29 -0800 (PST) Date: Mon, 24 Nov 2014 04:42:29 -0600 From: Nico Williams To: Henrick =?iso-8859-1?Q?Hellstr=F6m?= Message-ID: <20141124104226.GE3200@localhost> References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> <547308E2.6060809@streamsec.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <547308E2.6060809@streamsec.se> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i7tjzA36Fan1sR43VIM-ZOffogs Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:42:31 -0000 On Mon, Nov 24, 2014 at 11:30:58AM +0100, Henrick Hellstr=F6m wrote: > Actually, no, it doesn't. The Internet threat model is based on the > premise that both ends are uncompromised. If the client is allowing > third party javascript to connect to arbitrary HTTPS servers, > impersonating the client that runs the script, that client is > compromised. The Internet threat model always will have to assume local security. We're designing TLS. We are not really in a prosition to dictate to applications that they must not use cookies (though we can and must state clearly what applications can expect from TLS), especially not since we can (and must) make TLS 1.3 resistant to BEAST/CRIME style attacks (we shouldn't make apps change unnecessarily). This is NOT a defense of the web security model, BTW, please don't mistake it as such. Nico --=20 From nobody Mon Nov 24 02:43:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3171A1F01 for ; Mon, 24 Nov 2014 02:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rfB20ODIWYo for ; Mon, 24 Nov 2014 02:43:17 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC0D1A1EF8 for ; Mon, 24 Nov 2014 02:43:17 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id E365F2006D30A; Mon, 24 Nov 2014 02:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tFW5fIPvxvzb+A OJsJnzo5b1zjY=; b=mwuaG5LX4a+bML0EU3PfwiR+qELLwyBzvQZEkYQ0mE36iq xsJT/f6IGfJ0ig5JJo9YG2CzTizjK+AZuQBdFiA3JIOQinlg2ODN04nTTV3ahZGE dDp7AxtwsW1qG9rxehQqip9lLKcGptebYs47Dn1gexRBkI5892eEu+u8fksOY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id A50102006D309; Mon, 24 Nov 2014 02:43:16 -0800 (PST) Date: Mon, 24 Nov 2014 04:43:16 -0600 From: Nico Williams To: Watson Ladd Message-ID: <20141124104314.GF3200@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> <20141119205117.GE20758@localhost> <20141121185136.GF20758@localhost> <20141124064707.GB3200@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141124064707.GB3200@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/07rn3bRIj8avigI3sz5K5UhTqA0 Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT security considerations (was OPTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:43:17 -0000 On Mon, Nov 24, 2014 at 12:47:09AM -0600, Nico Williams wrote: > On Fri, Nov 21, 2014 at 04:55:23PM -0800, Watson Ladd wrote: > > On Fri, Nov 21, 2014 at 10:51 AM, Nico Williams wrote: > > >> > It's much easier to have the server hold the > > >> > early data and have it bound into the client's next handshake msg. > > Actually, there's no need to bind early data into the handshakes. It's > enough that the client has to eventually confirm a handshake message > from the server, and for good measure the client should switch to a key > to which the server contributed before sending non-early data. Then the > server can detect replays. One more note: the server has to know that it got all of the client's early data... From nobody Mon Nov 24 02:44:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567801A1EFD for ; Mon, 24 Nov 2014 02:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESTCwEMhjpWK for ; Mon, 24 Nov 2014 02:44:44 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4FA1A1EF9 for ; Mon, 24 Nov 2014 02:44:44 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 2B37A59807A; Mon, 24 Nov 2014 02:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=5pLSazagZrkM6VwDmNdWAVPQ91U=; b=mI6W9MB61IP sJAwpZpVwk/C6rKk43WeNh74HNgRIfP7Mr4vis1J/Iucbh8ODajI0hM7z4r14teu xt6r5iwVfQ/vgD7w/vyJso24M1pOD5uGElKoza4d0RC+uEBV8mz+H5/2TsFRyJOS bjGjbAIqTozZftKapTIsdrEA2TXyh4wM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id C52E659806A; Mon, 24 Nov 2014 02:44:43 -0800 (PST) Date: Mon, 24 Nov 2014 04:44:43 -0600 From: Nico Williams To: Adam Langley Message-ID: <20141124104441.GG3200@localhost> References: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ejG1gT1nBVXGteQjG1aPRo3GcJw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:44:45 -0000 On Mon, Nov 24, 2014 at 02:36:22AM -0800, Adam Langley wrote: > On Mon, Nov 24, 2014 at 12:44 AM, Yoav Nir wrote: > > Third issue: Why can=E2=80=99t an attacker disable this protection by= simply > > omitting the extension from both its ClientHello and ServerHello? >=20 > Writing this down might be called for too. In practice, I'm > implementing it so that calls to get tls-unique values and the like > will fail on resumed connections where the original session did not > use this extension. +1. From nobody Mon Nov 24 02:53:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71311A1F01 for ; Mon, 24 Nov 2014 02:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzXpzht6Fx2n for ; Mon, 24 Nov 2014 02:53:28 -0800 (PST) Received: from vsp7.ballou.se (vsp7.ballou.se [91.189.40.103]) by ietfa.amsl.com (Postfix) with SMTP id 795441A1EFD for ; Mon, 24 Nov 2014 02:53:26 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp7.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 24 Nov 2014 11:53:24 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 0DEDB1DE89; Mon, 24 Nov 2014 11:53:24 +0100 (CET) Message-ID: <54730E1D.8060104@streamsec.se> Date: Mon, 24 Nov 2014 11:53:17 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> <547308E2.6060809@streamsec.se> <20141124104226.GE3200@localhost> In-Reply-To: <20141124104226.GE3200@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YZAiTT6DhzoETxGm_fwny39cnLU Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:53:30 -0000 On 2014-11-24 11:42, Nico Williams wrote: > On Mon, Nov 24, 2014 at 11:30:58AM +0100, Henrick Hellström wrote: >> Actually, no, it doesn't. The Internet threat model is based on the >> premise that both ends are uncompromised. If the client is allowing >> third party javascript to connect to arbitrary HTTPS servers, >> impersonating the client that runs the script, that client is >> compromised. > > The Internet threat model always will have to assume local security. > > We're designing TLS. We are not really in a prosition to dictate to > applications that they must not use cookies (though we can and must > state clearly what applications can expect from TLS), especially not > since we can (and must) make TLS 1.3 resistant to BEAST/CRIME style > attacks (we shouldn't make apps change unnecessarily). This is NOT a > defense of the web security model, BTW, please don't mistake it as such. Yes, but the point I am trying to make, is that if the implied goal is to make TLS resilient even against BEAST/CRIME style attacks, the threat model should be defined accordingly. It makes little sense to ask for cryptographic review of the protocol, if it is inherently unclear exactly what kind of threats the protocol is designed to withstand. From nobody Mon Nov 24 02:59:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DA71A1EF8 for ; Mon, 24 Nov 2014 02:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5RV1koELumT for ; Mon, 24 Nov 2014 02:59:51 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 427A71A0151 for ; Mon, 24 Nov 2014 02:59:51 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 2519B59806A; Mon, 24 Nov 2014 02:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=mJuOHOEQneMYIXv572TZbTDq1xk=; b=FRZcbxGmV/T uElvTrTTNIp3VV6ng3kgHGIz1LWqWAoQR/pJ0hY7NggAZYJq0ACywxMUn84vwMnf OrQFGYJB81HIDE9H0sNfgZJCXa1Al3H09APAonf2yuOPnAY+gpboZvNL4SXyYjTZ mM8MbL8SdU54eXTX5Y8XPnlo3gGkZJZo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id C05D259805F; Mon, 24 Nov 2014 02:59:50 -0800 (PST) Date: Mon, 24 Nov 2014 04:59:50 -0600 From: Nico Williams To: Henrick =?iso-8859-1?Q?Hellstr=F6m?= Message-ID: <20141124105948.GH3200@localhost> References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> <547308E2.6060809@streamsec.se> <20141124104226.GE3200@localhost> <54730E1D.8060104@streamsec.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <54730E1D.8060104@streamsec.se> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P5NW2fDa4Fe0rZ6Z6VjZLf9APx4 Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:59:52 -0000 On Mon, Nov 24, 2014 at 11:53:17AM +0100, Henrick Hellstr=F6m wrote: > Yes, but the point I am trying to make, is that if the implied goal > is to make TLS resilient even against BEAST/CRIME style attacks, the > threat model should be defined accordingly. It makes little sense to > ask for cryptographic review of the protocol, if it is inherently > unclear exactly what kind of threats the protocol is designed to > withstand. BEAST/CRIME are dramatic demonstrations of the capabilities of attackers in the Internet threat model. From nobody Mon Nov 24 03:15:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341C91A1EFD for ; Mon, 24 Nov 2014 03:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7CUNpSoPgCb for ; Mon, 24 Nov 2014 03:15:55 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A65AB1A1EF7 for ; Mon, 24 Nov 2014 03:15:55 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 4FBE12005D00A for ; Mon, 24 Nov 2014 03:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+olBzahwmj9DQuOvAwy1 9cC58pE=; b=n1oWH4FN9zBpaid+FDHlS3ANyFMVfjKy+kBRyt9Or7BscxaRpjTb enj180JesB3d2eKQ8gHa/nX7zPZ1s951Zt2XIecIubR6Xo3tDZsA+6rTLGzh+Mjk qgz5tfNomWdN+fcaAm4WTFFngNVClJlu/O2uHbhWuqfQDhzJQUJtX/c= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 117AA2005D008 for ; Mon, 24 Nov 2014 03:15:55 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id a1so11867157wgh.39 for ; Mon, 24 Nov 2014 03:15:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.98.233 with SMTP id el9mr20306319wib.3.1416827753757; Mon, 24 Nov 2014 03:15:53 -0800 (PST) Received: by 10.216.32.136 with HTTP; Mon, 24 Nov 2014 03:15:53 -0800 (PST) In-Reply-To: <20141124105948.GH3200@localhost> References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> <547308E2.6060809@streamsec.se> <20141124104226.GE3200@localhost> <54730E1D.8060104@streamsec.se> <20141124105948.GH3200@localhost> Date: Mon, 24 Nov 2014 05:15:53 -0600 Message-ID: From: Nico Williams To: =?UTF-8?Q?Henrick_Hellstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OAml5gmEezJ_yflQcBPx7ZHuolw Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 11:15:56 -0000 Or, to put it differently, we need to state an Internet threat model succintly. The thing that has been missing from it is massive capabilities on the part of some attackers. If we have to publish a new standard Internet threat model, then we should do so. Nico -- From nobody Mon Nov 24 03:58:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431FA1A6EE6 for ; Mon, 24 Nov 2014 03:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHkiwQ0kUJPQ for ; Mon, 24 Nov 2014 03:58:53 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EF41A6EE5 for ; Mon, 24 Nov 2014 03:58:53 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id k15so6081380qaq.24 for ; Mon, 24 Nov 2014 03:58:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=unUXnrLb8sKjuH9n7qAos+R+lgG8niKlfR1EHSLjc8E=; b=AOABJJTvrUDpvWIhkawWSMumPNya657GU5EfmgDEl4x/4uW5ewiraTJ/BEQpATDaFH wLPqxjtx5AFsgSZu+htTjLz1XY55HQewU7pfS5xhZopWoBkc3peiCfQDcMVQhIe2v2Kv rCS/QzFkXh8FEnlyDpnEbeW2RZbzOP5nICSeWn3SVREoy+scblO6NgTBRNZCkN5Wo+wD 1mw1zXTi5yPxKMxD8M1r9IYUdnt0PYdgksgY1O03I28xWN4c788vja+ug8mAFIMhokq2 3f2ZXDYldWjcFyATiWw/UZk40/Qu2TPE5Z7+dR8Wrs6zEUwo7fpqHZPX2RajK06yjxKD 6jSA== X-Gm-Message-State: ALoCoQkL0Wwdba0K2giBBZZtLPEE1JquN4l1noKdD2+qahjCV/yOrhe9TprpCY/wOQOFF4Ky796v X-Received: by 10.224.94.9 with SMTP id x9mr12913018qam.45.1416830333005; Mon, 24 Nov 2014 03:58:53 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id b17sm9898069qah.35.2014.11.24.03.58.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Nov 2014 03:58:51 -0800 (PST) Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id ABE32AC2842; Mon, 24 Nov 2014 06:58:49 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> Date: Mon, 24 Nov 2014 06:58:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QrU7kbo7P-5vzpIlg1XNx5W7q9c Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 11:58:55 -0000 On Nov 24, 2014, at 3:44 AM, Yoav Nir wrote: > Third issue: Why can=92t an attacker disable this protection by simply = omitting the extension from both its ClientHello and ServerHello? At = least in the short term it won=92t be practical to fail a handshake = because the other side doesn=92t support this extension. I guess the = answer is that the ruse will work, but the other attacks mentioned in = TRIPLE-HS will fail, but it=92s not clear to me why. A can still proxy = unchanged records from C to S if the connections are resumptions. = Perhaps servers should be prohibited from resuming a session set up = without this extension if the ClientHello does include the extension. The draft currently says "Clients and servers SHOULD NOT resume sessions = that do not use the extended master secret..." Are you saying you want = that to be MUST NOT? --=20 Stephen Checkoway From nobody Mon Nov 24 04:07:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590781A1EF8 for ; Mon, 24 Nov 2014 04:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR5ZHJX-tDEj for ; Mon, 24 Nov 2014 04:06:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091A41A1AE0 for ; Mon, 24 Nov 2014 04:06:52 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOC6o5f006204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 07:06:50 -0500 Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAOC6lkK005349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Nov 2014 07:06:49 -0500 Message-ID: <54731F57.5000803@redhat.com> Date: Mon, 24 Nov 2014 13:06:47 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams , =?windows-1252?Q?Henrick_Hel?= =?windows-1252?Q?lstr=F6m?= References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> <547308E2.6060809@streamsec.se> <20141124104226.GE3200@localhost> <54730E1D.8060104@streamsec.se> <20141124105948.GH3200@localhost> In-Reply-To: <20141124105948.GH3200@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KitV7AC3OV5jKeZxyx80xYYMc6o Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 12:07:05 -0000 On 11/24/2014 11:59 AM, Nico Williams wrote: > On Mon, Nov 24, 2014 at 11:53:17AM +0100, Henrick Hellström wrote: >> Yes, but the point I am trying to make, is that if the implied goal >> is to make TLS resilient even against BEAST/CRIME style attacks, the >> threat model should be defined accordingly. It makes little sense to >> ask for cryptographic review of the protocol, if it is inherently >> unclear exactly what kind of threats the protocol is designed to >> withstand. > > BEAST/CRIME are dramatic demonstrations of the capabilities of attackers > in the Internet threat model. I really doubt that when people talked about the Internet threat model ten, fifteen years ago, they had adaptive chosen plaintext attacks in mind. For example, they are not discussed in (as far as I can tell). If such attacks are covered by the Internet threat model today, the model has evolved considerably. -- Florian Weimer / Red Hat Product Security From nobody Mon Nov 24 04:19:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821AA1A1B36 for ; Mon, 24 Nov 2014 04:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYTvgWXuqZTy for ; Mon, 24 Nov 2014 04:19:00 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7571A1B1B for ; Mon, 24 Nov 2014 04:19:00 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOCIxVB006001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 07:18:59 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAOCIubU011513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 07:18:58 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 24 Nov 2014 13:18:56 +0100 Message-ID: <1723354.osyxesJJiI@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <1416816989.2533.7.camel@dhcp-2-127.brq.redhat.com> References: <20141122105659.GA26446@roeckx.be> <1416816989.2533.7.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b-u-2660CAVadsQ0UarcKUZLuaY Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 12:19:02 -0000 On Monday 24 November 2014 09:16:29 Nikos Mavrogiannopoulos wrote: > On Sat, 2014-11-22 at 11:56 +0100, Kurt Roeckx wrote: > > On Sat, Nov 22, 2014 at 05:40:27AM -0500, Nikos Mavrogiannopoulos wrote: > > > That highlights the main difference > > > with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it > > > was published.> > > There still are SSLv2 only services on the internet. Hubert Kario > > last scan results > > (https://lists.fedoraproject.org/pipermail/security/2014-October/001989.ht > > ml) said: > > Supported Protocols Count Percent > > -------------------------+---------+------- > > SSL2 44800 10.2755 > > SSL2 Only 5536 1.2698 > > I believe that this shows more about issues with the sample of the test > rather than functioning SSLv2 only servers. Given that there is no way > to connect to them anyway, they could be misconfigured non functional > servers or honeypots. This is actually a result of their intolerance to SSLv3 ClientHello with large amount of ciphers (or RC4 placed after 64th position in the list - the win 2k3 TLS bug). I've extended the scanner to try more fallbacks when testing (retry with a much smaller client hello) and the stats for this month look like this: Supported Protocols Count Percent -------------------------+---------+------- SSL2 38835 8.7934 SSL2 Only 100 0.0226 SSL3 204062 46.2059 SSL3 Only 2195 0.497 SSL3 or TLS1 Only 108575 24.5847 SSL3 or lower Only 2293 0.5192 TLS1 438481 99.2856 TLS1 Only 46428 10.5127 TLS1 or lower Only 143729 32.5447 TLS1.1 281522 63.7453 TLS1.1 Only 25 0.0057 TLS1.1 or up Only 443 0.1003 TLS1.2 292517 66.2349 TLS1.2 Only 337 0.0763 TLS1.2, 1.0 but not 1.1 13585 3.0761 (the script managed to connect to about 100 more servers with even smaller client hello, most of which accepted just v2-compatible client hello, but I've not implemented the scan for such intolerant servers yet) I think we can safely banish a protocol that only 0.5% of servers require for interoperability. Regarding the SSLv3 MUST NOT: we have to remember that we're talking about a security protocol *used* for security. In such context SSLv3 should not be used. Just like MD5 use for digital signatures is completely broken but is completely fine to use it as a checksum to verify proper download of a file over internet (people use CRC32 for that!), use of SSLv3 for interop is fine, but not if it is used for confidentiality. +1 to MUST NOT -- Regards, Hubert Kario From nobody Mon Nov 24 06:22:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471011A6F71 for ; Mon, 24 Nov 2014 06:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21tN_uL3m6ll for ; Mon, 24 Nov 2014 06:22:36 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4206F1A6FAA for ; Mon, 24 Nov 2014 06:22:30 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so5903415wiw.16 for ; Mon, 24 Nov 2014 06:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GnC5DPha12qASO8S1K3e0dk2Z7bH51YZgnYnMa97NDc=; b=UulrxXER2Mw4zPChYWRTvnBDFcUpC7ue2AmkR9s5m4+MMRGuS92K1U1x8gbZN8+16m f2HvbyaFWR92O/NYCnlkCVdpupwv12wyM1i5BhYJA9PSRfesF/aHp9A8YSRWjNyvXDcb EYGO15XszVdLSR8/FE1oOOlEK1JBhsX+pPdBW8JnhHLQps5GKrPVz1aj9RV3eJhVReIY jMXsjZl25elocfGOwU43zOUU0JQ4iYohfVAoiKMrfBMeqjg33bZ1D6w6EdpdRoLi3NAR I2jJBi/1YMy6Yi23UGgvwoCe28soHJDBSufef+IT/MTwq83TCIshNfJE1zuLP5rwVbF9 haOw== X-Received: by 10.180.11.140 with SMTP id q12mr22274029wib.45.1416838949047; Mon, 24 Nov 2014 06:22:29 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id q7sm11657843wix.0.2014.11.24.06.22.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 06:22:28 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Mon, 24 Nov 2014 16:22:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com> References: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> To: Stephen Checkoway X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TqXbt2DjWj2vJ9qfJ-K4MNAgArQ Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 14:22:38 -0000 > On Nov 24, 2014, at 1:58 PM, Stephen Checkoway wrote: >=20 >=20 > On Nov 24, 2014, at 3:44 AM, Yoav Nir wrote: >=20 >> Third issue: Why can=92t an attacker disable this protection by = simply omitting the extension from both its ClientHello and ServerHello? = At least in the short term it won=92t be practical to fail a handshake = because the other side doesn=92t support this extension. I guess the = answer is that the ruse will work, but the other attacks mentioned in = TRIPLE-HS will fail, but it=92s not clear to me why. A can still proxy = unchanged records from C to S if the connections are resumptions. = Perhaps servers should be prohibited from resuming a session set up = without this extension if the ClientHello does include the extension. >=20 > The draft currently says "Clients and servers SHOULD NOT resume = sessions that do not use the extended master secret..." Are you saying = you want that to be MUST NOT? I missed that line. What I was suggesting was that servers MUST NOT resume sessions that = were negotiated without the extended master secret in handshakes that do = have the extension. Thinking it over now, I guess it would be better to have both lines, = because there=92s a significant performance penalty to prohibiting = sessions resumption with all existing clients, and prohibiting the = resumption where the attacker is not manipulating the handshake defeats = the known attacks. Yoav From nobody Mon Nov 24 07:59:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618741A6FB0 for ; Mon, 24 Nov 2014 07:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12chv6SFpP27 for ; Mon, 24 Nov 2014 07:59:41 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4416D1A6FF3 for ; Mon, 24 Nov 2014 07:59:38 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 994923A1C3; Mon, 24 Nov 2014 16:59:35 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 5DFD841C4F; Mon, 24 Nov 2014 16:59:35 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 51E0C1B004; Mon, 24 Nov 2014 16:59:35 +0100 (CET) In-Reply-To: <1723354.osyxesJJiI@pintsize.usersys.redhat.com> To: Hubert Kario Date: Mon, 24 Nov 2014 16:59:35 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141124155935.51E0C1B004@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9Z5ABIJLV4MjliDa3oR6Q4wSi8w Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 15:59:45 -0000 Hubert Kario wrote: > > I've extended the scanner to try more fallbacks when testing (retry with a > much smaller client hello) and the stats for this month look like this: > > Supported Protocols Count Percent > -------------------------+---------+------- > SSL2 38835 8.7934 > SSL2 Only 100 0.0226 > SSL3 204062 46.2059 > SSL3 Only 2195 0.497 > SSL3 or TLS1 Only 108575 24.5847 > SSL3 or lower Only 2293 0.5192 > TLS1 438481 99.2856 > TLS1 Only 46428 10.5127 > TLS1 or lower Only 143729 32.5447 > TLS1.1 281522 63.7453 > TLS1.1 Only 25 0.0057 > TLS1.1 or up Only 443 0.1003 > TLS1.2 292517 66.2349 > TLS1.2 Only 337 0.0763 > TLS1.2, 1.0 but not 1.1 13585 3.0761 How do TLS extension support fit into your picture? Just a few days ago I was working on a customer message about interop problems with a Business-2-Business scenario, and the Server that is used seems to be an extensions-intolerant TLSv1.0 server. The server is OK with ClientHello.client_version = { 3, 3 }, but when ClientHello includes any TLS extensions, it will abort with a fatal unexpected_message(10) alert. (the Website is http://www.elemica.com, the service(s) are on https://preprod.connect.elemica.com:5443 and https://connect.elemica.com:5443 authentication is by TLS client certificate, but you'll see the TLS extensions intolerance by the fatal alert response to ClientHello. > > I think we can safely banish a protocol that only 0.5% of servers require for > interoperability. Maybe you can, but I can not. The support load would still be prohibitive. > > Regarding the SSLv3 MUST NOT: we have to remember that we're talking about a > security protocol *used* for security. In such context SSLv3 should not be > used. > > Just like MD5 use for digital signatures is completely broken but is > completely fine to use it as a checksum to verify proper download of a file > over internet (people use CRC32 for that!), use of SSLv3 for interop is fine, > but not if it is used for confidentiality. You might not be aware of it, but there is only one TLS protocol version that allows digital signatures with md5WithRsaEncryption, and that is TLSv1.2. -Martin From nobody Mon Nov 24 08:33:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE481A6EEF for ; Mon, 24 Nov 2014 08:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRglEXm81_cD for ; Mon, 24 Nov 2014 08:33:09 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7CA1A870C for ; Mon, 24 Nov 2014 08:32:51 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOGWl3a003673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 11:32:50 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAOGWjTb007382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 11:32:47 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 24 Nov 2014 17:32:45 +0100 Message-ID: <1713002.kBYARvl7be@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <20141124155935.51E0C1B004@ld9781.wdf.sap.corp> References: <20141124155935.51E0C1B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gd_4U_ng12P7b-lJjdx0JFv2HM4 Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:33:11 -0000 On Monday 24 November 2014 16:59:35 Martin Rex wrote: > Hubert Kario wrote: > > I've extended the scanner to try more fallbacks when testing (retry with a > > much smaller client hello) and the stats for this month look like this: > > > > Supported Protocols Count Percent > > -------------------------+---------+------- > > SSL2 38835 8.7934 > > SSL2 Only 100 0.0226 > > SSL3 204062 46.2059 > > SSL3 Only 2195 0.497 > > SSL3 or TLS1 Only 108575 24.5847 > > SSL3 or lower Only 2293 0.5192 > > TLS1 438481 99.2856 > > TLS1 Only 46428 10.5127 > > TLS1 or lower Only 143729 32.5447 > > TLS1.1 281522 63.7453 > > TLS1.1 Only 25 0.0057 > > TLS1.1 or up Only 443 0.1003 > > TLS1.2 292517 66.2349 > > TLS1.2 Only 337 0.0763 > > TLS1.2, 1.0 but not 1.1 13585 3.0761 > > How do TLS extension support fit into your picture? I don't know. That is: I'm using openssl command line binary (albeit with few changes, modifications and additions compared to upstream) and as such I don't believe I can send TLS1.0/1.1/1.2 Client Hello without extensions. In other words, all those servers that report TLS1.0 as supported mean also support for typical extensions (server_name, curves, signature_algorithms, etc.). The amount of servers which are TLS extension intolerant and either have SSLv3 disabled or are V2 client hello compatible is under 0.1%. What I have no idea about is the amount of servers that are V2 ClientHello *and* TLS-extension intolerant. > Just a few days ago I was working on a customer message about interop > problems with a Business-2-Business scenario, and the Server that is used > seems to be an extensions-intolerant TLSv1.0 server. The server is OK > with ClientHello.client_version = { 3, 3 }, but when ClientHello includes > any TLS extensions, it will abort with a fatal unexpected_message(10) alert. > > (the Website is http://www.elemica.com, > the service(s) are on https://preprod.connect.elemica.com:5443 > and https://connect.elemica.com:5443 > authentication is by TLS client certificate, but you'll see the > TLS extensions intolerance by the fatal alert response to ClientHello. > > > I think we can safely banish a protocol that only 0.5% of servers require > > for interoperability. > > Maybe you can, but I can not. The support load would still be prohibitive. In the case you're talking about you can connect using TLS1.0 without extensions, and while that is suboptimal in general it is allowed under current draft (and supported with TLS_FALLBACK_SCSV). Anyway, you should file a complaint to the manufacturer that it haven't addressed the POODLE vulnerability in their product (or that it doesn't implement advertised protocols properly). If you don't have a contract under which you can do that or can't change the TLS library yourself, you have much bigger problems anyway... > > Regarding the SSLv3 MUST NOT: we have to remember that we're talking about > > a security protocol *used* for security. In such context SSLv3 should not > > be used. > > > > Just like MD5 use for digital signatures is completely broken but is > > completely fine to use it as a checksum to verify proper download of a > > file > > over internet (people use CRC32 for that!), use of SSLv3 for interop is > > fine, but not if it is used for confidentiality. > > You might not be aware of it, but there is only one TLS protocol version > that allows digital signatures with md5WithRsaEncryption, and that is > TLSv1.2. yes, I am aware about that. Quite a few servers will in fact happily sign the key exchange with MD5. But that will happen only if the client advertises support for it (I did found 3 that will sign using only MD5 but I haven't checked if it's not a false positive). And most will fallback to either non (EC)DHE cipher or just force SHA1 on the client if it doesn't advertise RSA key signature algorithms. -- Regards, Hubert Kario From nobody Mon Nov 24 08:56:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC301A870D for ; Mon, 24 Nov 2014 08:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MZpYqBiU8PF for ; Mon, 24 Nov 2014 08:56:03 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEB21A7113 for ; Mon, 24 Nov 2014 08:56:03 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4B6D13A157; Mon, 24 Nov 2014 17:56:01 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 169DC41266; Mon, 24 Nov 2014 17:56:01 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 0E7A71B004; Mon, 24 Nov 2014 17:56:01 +0100 (CET) In-Reply-To: <20141124105948.GH3200@localhost> To: Nico Williams Date: Mon, 24 Nov 2014 17:56:01 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DZ-Q1BMged_7Rj9YOvcMDKAwTpg Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:56:08 -0000 Nico Williams wrote: > > Henrick Hellstr=F6m wrote: > >> Yes, but the point I am trying to make, is that if the implied goal >> is to make TLS resilient even against BEAST/CRIME style attacks, the >> threat model should be defined accordingly. It makes little sense to >> ask for cryptographic review of the protocol, if it is inherently >> unclear exactly what kind of threats the protocol is designed to >> withstand. >=20 > BEAST/CRIME are dramatic demonstrations of the capabilities of attackers > in the Internet threat model. Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of the ridiculous insecurity of WebBrowsers in their default configuration. As I've previously mentioned, TLSv1.2 has an explicit product warning label against such Browser fallacies, and explicitly rules out BEAST, CRIME and Poodle from the attack model against which TLSv1.2 and all prior TLS and SSL protocol versions provide protection. The vulnerability of Web Browsers that attacks like BEAST, CRIME and Poodle exploit is called "Cross-Site-Request-Forgery" (CSRF) vulnerability, e.g.: https://www.isecpartners.com/media/11961/csrf_paper.pdf and as long as a Browser keeps providing authentication facilities for requests supplied by attackers, the vulnerability is wide open, independent of the TLS protocol version that is used (SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 or TLSv1.3). Often, browsers will voluntarily supply attackers access to CSRF for non-disclosing authentication schemes, including TLS client certificate authentication. So while current disclosing authentication schemes make the problems worse, replacing disclosing authentation schemes would only make boring demonstrations like BEAST and Poodle less likely, but would not address and fix the real problem (CSRF) at all. For many programmatic clients and servers, attacks like BEAST and Poodle are completely irrelevant, because the vast majority of these will neither execute attacker-supplied active content, nor will they provide Cross-Site-Request-Forgery facilities to attackers for free. If there is anything wrong, then it is the current (lack of) "Web Security Model" as it exists in common Web Browsers and as it exists on a growing number of Web Servers. -Martin From nobody Mon Nov 24 09:00:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62BF1A8729 for ; Mon, 24 Nov 2014 09:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbtaP7rWPNMw for ; Mon, 24 Nov 2014 09:00:06 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AE8931A6EF4 for ; Mon, 24 Nov 2014 09:00:06 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 510EA27BC06F; Mon, 24 Nov 2014 09:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=VLv6N5prfKKViZ FSGe1dpA1suH4=; b=GoFnjcfOWkLY3NzQUUfXVScWpUb/36sh5oZxjirg56ILjI +m3yf3ytEReCjwrSVUZsEnWwl19bakyqH0VM3ON8HToat9KhOKmtrK6EUFVP1fUm Xb/kmgsIbkFmwl96TX6/rdIHAI/R3aIMSpYPKGMcns+Wrene4lTyqskcv/bLQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 0BF4227BC06B; Mon, 24 Nov 2014 09:00:05 -0800 (PST) Date: Mon, 24 Nov 2014 11:00:05 -0600 From: Nico Williams To: Florian Weimer Message-ID: <20141124170003.GI3200@localhost> References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> <547308E2.6060809@streamsec.se> <20141124104226.GE3200@localhost> <54730E1D.8060104@streamsec.se> <20141124105948.GH3200@localhost> <54731F57.5000803@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54731F57.5000803@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rVpXZAkcKBJ1T8VwE545l4Ax_4c Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:00:07 -0000 On Mon, Nov 24, 2014 at 01:06:47PM +0100, Florian Weimer wrote: > I really doubt that when people talked about the Internet threat > model ten, fifteen years ago, they had adaptive chosen plaintext > attacks in mind. For example, they are not discussed in > (as far as I > can tell). If such attacks are covered by the Internet threat model > today, the model has evolved considerably. They are active attacks by an attacker with full control of the network between the end-points under attack. Therefore they fall squarely under the traditional Internet threat model. We have to take into account even attacks that today seem difficult to mount (as this one seemed not that long ago), but we can't predict future new active attacks. And yet new future active attacks will still be active attacks. I'm not saying that the Internet threat model doesn't require updating (it does, at least as to massive adversary capabilities). I'm saying we shouldn't blame TLS's shortcommings on the Internet threat model. The latter is very high-level, and can't cover every eventually in its small print, but in its high-level view, adaptive chosen plaintext attacks were covered. Nico -- From nobody Mon Nov 24 09:03:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1436E1A872E for ; Mon, 24 Nov 2014 09:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.333 X-Spam-Level: X-Spam-Status: No, score=0.333 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRQfvb3y6o-6 for ; Mon, 24 Nov 2014 09:03:00 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 724071A8721 for ; Mon, 24 Nov 2014 09:03:00 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 49F96438072; Mon, 24 Nov 2014 09:03:00 -0800 (PST) Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id DF546438079; Mon, 24 Nov 2014 09:02:59 -0800 (PST) Date: Mon, 24 Nov 2014 11:02:59 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141124170257.GJ3200@localhost> References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jVGtU6TgESJ2FYopYb7K-mLhuj4 Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:03:01 -0000 On Mon, Nov 24, 2014 at 05:56:01PM +0100, Martin Rex wrote: > Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of the > ridiculous insecurity of WebBrowsers in their default configuration. Yes, they were that too. And by then we knew well about adaptive plaintext attacks. Still, they also were demonstrations that the network has to be assumed to be under control of the adversary, and IMO they were dramatic at that. If anyone still doubted the adversary's control of the network before BEAST, no one does now. Nico -- From nobody Mon Nov 24 09:06:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8B11A874D for ; Mon, 24 Nov 2014 09:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSio7WXcYaCV for ; Mon, 24 Nov 2014 09:06:23 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AF41A8744 for ; Mon, 24 Nov 2014 09:06:23 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 6C44D3A1A4; Mon, 24 Nov 2014 18:06:22 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 5B4274124A; Mon, 24 Nov 2014 18:06:22 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5315A1B004; Mon, 24 Nov 2014 18:06:22 +0100 (CET) In-Reply-To: <1713002.kBYARvl7be@pintsize.usersys.redhat.com> To: Hubert Kario Date: Mon, 24 Nov 2014 18:06:22 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141124170622.5315A1B004@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2FxMW3eNeBtXul9RCWPoC9pjG1s Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:06:30 -0000 Hubert Kario wrote: > Martin Rex wrote: >> Hubert Kario wrote: >>> I've extended the scanner to try more fallbacks when testing (retry with a >>> much smaller client hello) and the stats for this month look like this: >>> >>> Supported Protocols Count Percent >>> -------------------------+---------+------- >>> SSL2 38835 8.7934 >>> SSL2 Only 100 0.0226 >>> SSL3 204062 46.2059 >>> SSL3 Only 2195 0.497 >>> SSL3 or TLS1 Only 108575 24.5847 >>> SSL3 or lower Only 2293 0.5192 >>> TLS1 438481 99.2856 >>> TLS1 Only 46428 10.5127 >>> TLS1 or lower Only 143729 32.5447 >>> TLS1.1 281522 63.7453 >>> TLS1.1 Only 25 0.0057 >>> TLS1.1 or up Only 443 0.1003 >>> TLS1.2 292517 66.2349 >>> TLS1.2 Only 337 0.0763 >>> TLS1.2, 1.0 but not 1.1 13585 3.0761 >> >> How do TLS extension support fit into your picture? > > I don't know. > > That is: I'm using openssl command line binary (albeit with few changes, > modifications and additions compared to upstream) and as such I don't believe > I can send TLS1.0/1.1/1.2 Client Hello without extensions. > > In other words, all those servers that report TLS1.0 as supported mean also > support for typical extensions (server_name, curves, signature_algorithms, > etc.). The amount of servers which are TLS extension intolerant and either > have SSLv3 disabled or are V2 client hello compatible is under 0.1%. When I tested with https://preprod.connect.elemica.com:5443/ I realized that the openssl s_client tool has become somewhat unusable, because it includes a lot of TLS extensions in client hello without being asked to do so and also without a command line option to have it stop doing this. openssl-0.9.8y with "openssl s_client -no_ticket" seems to be able to produce an extension-free TLSv1.0 ClientHello. > > Anyway, you should file a complaint to the manufacturer that it haven't > addressed the POODLE vulnerability in their product (or that it doesn't > implement advertised protocols properly). What are you talking about? Poodle is a *PURE* Web-Browser and client problem. Servers are not vulnerable to Poodle, and this site *REQUIRES* TLS client certs for authentication. Disabling SSLv3 on servers is only a practical mitigation against the stupid "downgrade dance" that so many browsers perform. It's difficult for me to understand how someone could implement the downgrade dance and *NOT* provide a switch to turn it off after addressing the rfc5746 tls renegotiation issue. -Martin From nobody Mon Nov 24 09:13:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69B21A8741 for ; Mon, 24 Nov 2014 09:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhZgpM2r0GqC for ; Mon, 24 Nov 2014 09:13:29 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1161A875D for ; Mon, 24 Nov 2014 09:13:21 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 628593A1B0; Mon, 24 Nov 2014 18:13:20 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4EEBE41223; Mon, 24 Nov 2014 18:13:20 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 45D2D1B004; Mon, 24 Nov 2014 18:13:20 +0100 (CET) In-Reply-To: <20141124170257.GJ3200@localhost> To: Nico Williams Date: Mon, 24 Nov 2014 18:13:20 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141124171320.45D2D1B004@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/448Ld3Pp3QviFotaFdtei9JZW7c Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:13:32 -0000 Nico Williams wrote: > > Martin Rex wrote: >> >> Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of the >> ridiculous insecurity of WebBrowsers in their default configuration. > > Yes, they were that too. And by then we knew well about adaptive > plaintext attacks. Still, they also were demonstrations that the > network has to be assumed to be under control of the adversary, and IMO > they were dramatic at that. If anyone still doubted the adversary's > control of the network before BEAST, no one does now. 5 years ago there was an exhausting discussion in this WG about how to fix the TLS renegotiation issue. The problem had been considered so huge, that a secret group (Project Mogul) had been setup to design (and have patches shipped) before the issue was publicly described. BEAST and Poodle require *MORE* control over the endpoint as a prerequisite for the attack than what a successful TLS renegotiation attack will provide. Please stop claiming that providing so much control to an attacker as something that is (or should be) normal, rather than considering providing so much control to attackers as what it really is: a huge and gaping vulnerability in Web-Browsers and in the (lack of a) Web Security Model. -Martin From nobody Mon Nov 24 09:18:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13E1A8547 for ; Mon, 24 Nov 2014 09:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q6CAtENlmug for ; Mon, 24 Nov 2014 09:18:34 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877E21A82E2 for ; Mon, 24 Nov 2014 09:18:33 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 948D71C2136; Mon, 24 Nov 2014 18:18:31 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 775011FE00EF; Mon, 24 Nov 2014 18:18:31 +0100 (CET) Date: Mon, 24 Nov 2014 18:18:31 +0100 From: Kurt Roeckx To: Martin Rex Message-ID: <20141124171831.GA8451@roeckx.be> References: <1713002.kBYARvl7be@pintsize.usersys.redhat.com> <20141124170622.5315A1B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141124170622.5315A1B004@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Csdc4KJbiseteMo8j9M4SFnnzZo Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:18:37 -0000 On Mon, Nov 24, 2014 at 06:06:22PM +0100, Martin Rex wrote: > Poodle is a *PURE* Web-Browser and client problem. I'm not sure I agree with that. But it is by far the most easy way to exploit it. Kurt From nobody Mon Nov 24 09:26:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9B61A6FF2 for ; Mon, 24 Nov 2014 09:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KmMLS848TAl for ; Mon, 24 Nov 2014 09:26:33 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3D71A6FDC for ; Mon, 24 Nov 2014 09:26:33 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 978EF3A0F3; Mon, 24 Nov 2014 18:26:31 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 8C7C841356; Mon, 24 Nov 2014 18:26:31 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 845CB1B004; Mon, 24 Nov 2014 18:26:31 +0100 (CET) In-Reply-To: To: Watson Ladd Date: Mon, 24 Nov 2014 18:26:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20141124172631.845CB1B004@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4N4QckV6HcRGRU9UylmwCP48ipo Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:26:38 -0000 Watson Ladd wrote: > Henrick Hellstr=F6m wrote: >> >> I think such discussions would benefit from the basic premise that "secu= re" >> is a relative notion. It is completely pointless to ask if a protocol is >> secure or not secure, unless you first present an exhaustive list of >> security claims. That is, you can't ask if TLS 1.3 is secure or not, wit= hout >> first describing what security is to be expected from different scenario= s. >=20 > It's clear what the security claims of TLS are be: a TLS connection > between two parties ensures that data sent between them isn't > intercepted or manipulated, and that they are who they claim to be. > This is a fairly standard notion, clearly present in research by the > late 80's, and intuitively sensible. >=20 > Of course, past versions of TLS haven't provided it. Actually, all versions of TLS, including SSLv3 still provide the properties you've just described today. Every problem that has been described so far was an (ab)use of the orginal SSL&TLS protocols beyond its stated design goals based on flawed assumptions what TLS should additionally provide or what the above should be interpreted to cover as well. -Martin From nobody Mon Nov 24 09:29:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4145E1A6FFF for ; Mon, 24 Nov 2014 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq-80DyLEBZ4 for ; Mon, 24 Nov 2014 09:29:45 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 55BDB1A6FF2 for ; Mon, 24 Nov 2014 09:29:45 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 37FFC1E071; Mon, 24 Nov 2014 09:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=em0o0EyE5g0eFX wQKV8zU92UbRg=; b=yNFAFIHoonXSm5lfxVZoj8ELkfjrQ0qpDfBJEKmi7NUpvm 8mxs9LnyU1nnHGmxWK9n1umGsP3V89WFMfLIh2S/c8xH8KXaN1k4prMHDnHV4CuC A7c/Yrcyma+yURYf+zoqhDfjSGFQ2s0MYT5ZiG2tbne34mKTeLH7klHKfAwN0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id D9B3E1E05D; Mon, 24 Nov 2014 09:29:44 -0800 (PST) Date: Mon, 24 Nov 2014 11:29:44 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141124172942.GK3200@localhost> References: <20141124170257.GJ3200@localhost> <20141124171320.45D2D1B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141124171320.45D2D1B004@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3O3I1Q3XZ-K0WE5zCaqaR4_6bCg Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:29:46 -0000 On Mon, Nov 24, 2014 at 06:13:20PM +0100, Martin Rex wrote: > Nico Williams wrote: > > Martin Rex wrote: > >> Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of the > >> ridiculous insecurity of WebBrowsers in their default configuration. > > > > Yes, they were that too. And by then we knew well about adaptive > > plaintext attacks. Still, they also were demonstrations that the > > network has to be assumed to be under control of the adversary, and IMO > > they were dramatic at that. If anyone still doubted the adversary's > > control of the network before BEAST, no one does now. > > 5 years ago there was an exhausting discussion in this WG about how to > fix the TLS renegotiation issue. The problem had been considered so huge, > that a secret group (Project Mogul) had been setup to design (and have > patches shipped) before the issue was publicly described. Renego, incidentally, was a feature of TLS that was originally not part of the spec, but grew ad-hoc. This is one of the ways in which we failed SSL and its users: we didn't analyze the protocol as-used. > BEAST and Poodle require *MORE* control over the endpoint as a prerequisite > for the attack than what a successful TLS renegotiation attack will provide. So what? > Please stop claiming that providing so much control to an attacker > as something that is (or should be) normal, rather than considering > providing so much control to attackers as what it really is: > a huge and gaping vulnerability in Web-Browsers and in the > (lack of a) Web Security Model. I'm claiming that we're not in a position in this WG to fix the web security model to use something better than cookies and other bearer tokens. I wish we were, but we're clealy not. There's proof of this in the pudding. There were several efforts in the last few years, in the WEBSEC and HTTPauth WGs to do something about that, and those efforts failed. HTTPbis is very active, but they are not doing something about this either (unless that's changed recently; I don't follow HTTPbis closely). Many things were tried, including some that were -IMO- pretty good ideas, like origin-bound-cookies (which was good in large part because it implied minimal or no real changes to HTTP stacks). That means that TLS 1.3 simply MUST be resistant to various cookie recovery attacks. Those attacks have to be active attacks (therefore foreseen by the Internet threat model) of the adaptive chosen plaintext or similar varieties. Fortunately we know how to beat them, therefore we don't have to go fix the web security model *even though* we all would like to also do that anyways. BTW, I'd like to be wrong about this. I'd like us to get so incensed over web cookies that we get that part of the web security model fixed, full stop! Having attempted -and failed- to provide an alternative to web cookies myself, I'm wondering how else we might fix them... Dirk Balfanz's latest proposal is OK with me, but I am so traumatized (in a way) by BEAST that I'm inclined to accept just about any improvements as to web cookies, especially ones where big players will do the work to get started on deployment. Nico -- From nobody Mon Nov 24 09:31:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663A01A8748 for ; Mon, 24 Nov 2014 09:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYahWaRP03NB for ; Mon, 24 Nov 2014 09:31:45 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D10051A8745 for ; Mon, 24 Nov 2014 09:31:45 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id B152910075; Mon, 24 Nov 2014 09:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=7eUbHhBHYKr71I 5m7G5ai3/0OgM=; b=sC0D4rGIWfiflQXKyH/EklsX6BBKMY/0qCyLJPj8mmiQxd GetTOxO4uvWz1k3t6MCDO951m/VJ1fMU+bNaMIi4nD0BAdDX/Zw862dGhBcB76lW +IxOn9hpS9eMoG7KktnkZ0rmkHIBTkDQcr8PXBchxVDIfw/1eP9Tq/3H/sCFE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 4345010073; Mon, 24 Nov 2014 09:31:45 -0800 (PST) Date: Mon, 24 Nov 2014 11:31:44 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20141124173142.GL3200@localhost> References: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com> <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/daCjRSdUZOD5rwx-gFaqQjXsYeE Cc: Stephen Checkoway , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:31:46 -0000 On Mon, Nov 24, 2014 at 04:22:25PM +0200, Yoav Nir wrote: > > The draft currently says "Clients and servers SHOULD NOT resume > > sessions that do not use the extended master secret..." Are you > > saying you want that to be MUST NOT? > > I missed that line. > > What I was suggesting was that servers MUST NOT resume sessions that > were negotiated without the extended master secret in handshakes that > do have the extension. Or they must not support tls-unique CB extraction (or the key exporter) in that case. But I prefer the "MUST NOT resume" language. Nico -- From nobody Mon Nov 24 09:32:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A2A1A6FF2 for ; Mon, 24 Nov 2014 09:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6FeZDjXyrQ1 for ; Mon, 24 Nov 2014 09:32:46 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2A1A8750 for ; Mon, 24 Nov 2014 09:32:46 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B40141658CF; Mon, 24 Nov 2014 17:32:45 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id A93F916586F; Mon, 24 Nov 2014 17:32:45 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 8F88E1E03D; Mon, 24 Nov 2014 17:32:45 +0000 (GMT) Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 24 Nov 2014 12:32:27 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.15]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 24 Nov 2014 12:32:18 -0500 From: "Salz, Rich" To: "mrex@sap.com" , Watson Ladd Date: Mon, 24 Nov 2014 12:32:17 -0500 Thread-Topic: [TLS] Rethink TLS 1.3 Thread-Index: AdAIC9J4Fq80MZJaQsi3aeTR3Z9iMgAAJZag Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC3B13@USMBX1.msg.corp.akamai.com> References: <20141124172631.845CB1B004@ld9781.wdf.sap.corp> In-Reply-To: <20141124172631.845CB1B004@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NRBpLS3biokWmOzQl-Q12zDgbOI Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:32:48 -0000 > Every problem that has been described so far was an (ab)use of the orgina= l > SSL&TLS protocols beyond its stated design goals based on flawed > assumptions what TLS should additionally provide or what the above should > be interpreted to cover as well. Are you advocating that saying "you're doing it wrong" is a more correct ap= proach rather than trying to address the problems at the TLS definition, us= age model, and protocol? /R$ =20 From nobody Mon Nov 24 09:35:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D591A876D for ; Mon, 24 Nov 2014 09:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knYNkNG6DoU3 for ; Mon, 24 Nov 2014 09:35:21 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706871A8767 for ; Mon, 24 Nov 2014 09:35:21 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id f10so4473528yha.4 for ; Mon, 24 Nov 2014 09:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=22gUO99Gj/A8KQEnwMroP5vLC/TLDkMB1aLiFJ2V8Gc=; b=TzIQggXUmciJMW9wvxjRatBYFi/axf3qk78xv7wMCyHe0UMTn/3MwIgSMHA5wADPbR t74pV043AUufCX4FtVyWNVBSZiuso0DugbRcxXC3+5bq2YiuOa8h53gWrRrODnsMgXj6 WFt+keRG1GLXYi3kkt66BWvDsnHK62sLclYQq2FB6a6Fu0tOy9c+IZuz8eA9L4JRCrnV PzExYYRwDvbQD4CLIwqGvhRV5QGHaULq0uMC3OGOKp++utB9W/YOPKGwoAAHyEt2B2yQ 4sKX3bxaf8TlfJL1piqcY9unnUCIz7NEK3n1xiRtCZFK3kyLCyjxSXExh4WVHUvbrDFq FTOQ== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr19164967yha.163.1416850520514; Mon, 24 Nov 2014 09:35:20 -0800 (PST) Received: by 10.170.195.21 with HTTP; Mon, 24 Nov 2014 09:35:20 -0800 (PST) In-Reply-To: <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> Date: Mon, 24 Nov 2014 09:35:20 -0800 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/23afv26qIRa8oei550gQ9oaC65k Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:35:24 -0000 On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex wrote: > Nico Williams wrote: >> >> Henrick Hellstr=C3=B6m wrote: >> >>> Yes, but the point I am trying to make, is that if the implied goal >>> is to make TLS resilient even against BEAST/CRIME style attacks, the >>> threat model should be defined accordingly. It makes little sense to >>> ask for cryptographic review of the protocol, if it is inherently >>> unclear exactly what kind of threats the protocol is designed to >>> withstand. >> >> BEAST/CRIME are dramatic demonstrations of the capabilities of attackers >> in the Internet threat model. > > > Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of the > ridiculous insecurity of WebBrowsers in their default configuration. So it's possible to get my Paypal login cookie if I browse to a malicious site on a fully patched browser? Because that's what BEAST enabled. Are you saying it's fine that SSL v3.0 leaks one byte per connection? Because that's POODLE. All of this was known in 2004, and not fixed in TLS 1.2: no action was taken on publicising the vulnerabilities, and in the case of some of the CBC mode issues, vulnerable options were left in. If the web browser is inherently insecure because it runs javascript, where's the exploit? > > As I've previously mentioned, TLSv1.2 has an explicit product warning > label against such Browser fallacies, and explicitly rules out BEAST, > CRIME and Poodle from the attack model against which TLSv1.2 and > all prior TLS and SSL protocol versions provide protection. If TLS provided a secure channel as defined in https://eprint.iacr.org/2002/059, then the browser wouldn't have a problem. Workarounds around the lack of an easily provided property are never a good idea, unless you know exactly what the problems are. Why are you so dead set against making TLS useful for browsers? Providing the right properties isn't that hard: the correct thing to do looks very similar to the wrong thing, except it's correct. What are the exact security claims of SSLv3.0? Or TLSv1.0? > > > The vulnerability of Web Browsers that attacks like BEAST, CRIME and Pood= le > exploit is called "Cross-Site-Request-Forgery" (CSRF) vulnerability, e.g.= : > > https://www.isecpartners.com/media/11961/csrf_paper.pdf Just because you don't like the Web Security Model doesn't mean it doesn't exist. In fact, if you read the link you posted you would see very simple solutions to the CSRF problem, that work unless the "secure channel" isn't. By contrast, a web application that uses cookies for authentication, and is reachable over TLS 1.0 with an unpatched browser or RC4, is completely vulnerable, and can do nothing to solve the problem. Don't believe there is a difference? Go extract an authentication cookie from a CSRF vulnerable endpoint. You can easily hit the endpoint and trigger actions, but you won't get the cookie, and so can't attack other endpoints. CSRF is a confused-deputy issue: a capability based model would solve it. But we can't end CSRF without making it impossible to do things like isolate user accounts from content as protection against XSS, or federate authentication. Capability This isn't even about browsers: TLS based VPN solutions also have to worry about BEAST. Something as simple as programmatic username-password authentication can be broken if the client automatically retries on failure. POODLE leaks one byte after a certain number of connections are broken: are you sure your code never retries on failure? We could fix all of this by providing an actually secure protocol. What's the disadvantage? Sincerely, Watson Ladd > > and as long as a Browser keeps providing authentication facilities > for requests supplied by attackers, the vulnerability is wide open, > independent of the TLS protocol version that is used (SSLv3, TLSv1.0, > TLSv1.1, TLSv1.2 or TLSv1.3). Often, browsers will voluntarily supply > attackers access to CSRF for non-disclosing authentication schemes, > including TLS client certificate authentication. So while current > disclosing authentication schemes make the problems worse, replacing > disclosing authentation schemes would only make boring demonstrations > like BEAST and Poodle less likely, but would not address and fix the > real problem (CSRF) at all. > > For many programmatic clients and servers, attacks like BEAST and Poodle > are completely irrelevant, because the vast majority of these will neithe= r > execute attacker-supplied active content, nor will they provide > Cross-Site-Request-Forgery facilities to attackers for free. > > > If there is anything wrong, then it is the current (lack of) > "Web Security Model" as it exists in common Web Browsers and as > it exists on a growing number of Web Servers. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Nov 24 09:43:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42541A8735 for ; Mon, 24 Nov 2014 09:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K40cqgoQdPIX for ; Mon, 24 Nov 2014 09:43:16 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5259B1A19EF for ; Mon, 24 Nov 2014 09:43:16 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOHhFoh027992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 12:43:15 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAOHhEGc014238 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 12:43:15 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 24 Nov 2014 18:43:13 +0100 Message-ID: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <20141124170622.5315A1B004@ld9781.wdf.sap.corp> References: <20141124170622.5315A1B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/27wETkxLOl67dOfXbeWpW7-qiDg Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:43:17 -0000 On Monday 24 November 2014 18:06:22 Martin Rex wrote: > Hubert Kario wrote: > > Anyway, you should file a complaint to the manufacturer that it haven't > > addressed the POODLE vulnerability in their product (or that it doesn't > > implement advertised protocols properly). > > Poodle is a *PURE* Web-Browser and client problem. > Servers are not vulnerable to Poodle, and this site *REQUIRES* > TLS client certs for authentication. > > Disabling SSLv3 on servers is only a practical mitigation against > the stupid "downgrade dance" that so many browsers perform. > It's difficult for me to understand how someone could implement > the downgrade dance and *NOT* provide a switch to turn it off after > addressing the rfc5746 tls renegotiation issue. To exploit POODLE you need fallback dance *or* support just SSLv3. It's not limited to web browsers (and there are some clients that do fallback and are not browsers, e.g. curl). Also, are you saying that an *automated* system won't retry on connection failure? We're talking about average of 128 failed requests per byte decrypted, even if we fail just every first connection on a system that queries remote server every 5 minutes 24/7 that will require just a month to decrypt 16 byte password/authentication string. There have been far more dedicated and longer attacks in the wild. SSLv3 has known security problems, more issues may be discovered in the future... or not (as the researchers may decide that it was thus completely broken and as such not worth investigating further). So while use of certificates may mitigate this problem, we may not ever know if it mitigates all problems SSLv3 has. For example, issues like 3-shake won't be fixed in SSLv3. In my opinion, continued use of it for security-critical applications qualifies for gross negligence. Do we really need the repeat of the MD5 signatures story or can we learn on our own (as in industry) mistakes? -- Regards, Hubert Kario From nobody Mon Nov 24 10:30:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD21A0673 for ; Mon, 24 Nov 2014 10:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joElNDBBsEGf for ; Mon, 24 Nov 2014 10:29:57 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884DE1A872B for ; Mon, 24 Nov 2014 10:29:57 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 5DA713A126; Mon, 24 Nov 2014 19:29:53 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id A703A41CB7; Mon, 24 Nov 2014 19:29:53 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9C8251B004; Mon, 24 Nov 2014 19:29:53 +0100 (CET) In-Reply-To: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com> To: Hubert Kario Date: Mon, 24 Nov 2014 19:29:53 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141124182953.9C8251B004@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/I5ULbPJIyRnu2vCwzO5-UeGagOs Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 18:30:06 -0000 Hubert Kario wrote: > On Monday 24 November 2014 18:06:22 Martin Rex wrote: >> Hubert Kario wrote: >> > Anyway, you should file a complaint to the manufacturer that it haven't >> > addressed the POODLE vulnerability in their product (or that it doesn't >> > implement advertised protocols properly). >> >> Poodle is a *PURE* Web-Browser and client problem. >> Servers are not vulnerable to Poodle, and this site *REQUIRES* >> TLS client certs for authentication. >> >> Disabling SSLv3 on servers is only a practical mitigation against >> the stupid "downgrade dance" that so many browsers perform. >> It's difficult for me to understand how someone could implement >> the downgrade dance and *NOT* provide a switch to turn it off after >> addressing the rfc5746 tls renegotiation issue. > > To exploit POODLE you need fallback dance *or* support just SSLv3. It's not > limited to web browsers (and there are some clients that do fallback and are > not browsers, e.g. curl). > > Also, are you saying that an *automated* system won't retry on connection > failure? _very_ few, if any. Exactly none of ours. > > We're talking about average of 128 failed requests per byte decrypted, > even if we fail just every first connection on a system that queries > remote server every 5 minutes 24/7 that will require just a month to > decrypt 16 byte password/authentication string. There have been far > more dedicated and longer attacks in the wild. You may have not understood the Problem. It's a plaintext recovery of 1 byte per 256 requests on average and you can only recover the last byte of any CBC ciphertext block, not the other 7 (3DES/IDEA) or other 15(AES). And you will need a high probability that the secret you want to recover is at a static position of the requests that you're attacking. A poodle attack will be pretty "noisy" on the server, so for many usage scenarios, this will be sufficient deterrent, just like many apartments have no bullet-proof windows and many doors have not pick-proof locks. And you could add random URL-parameters or other insert additional header fields before the credentials if you absolutely want to keep doing disclosing authentication rather than simply switching to using TLS client certs for the requests. > > SSLv3 has known security problems, > more issues may be discovered in the future. TLS has long known weaknesses and well-documented limitations. When you remain within the safe usage areas, even SSLv3 is still secure. Really, what we should worry about is the current usage scenarios where even TLSv1.2 can not provide protection, and one of these is Cross-Site-Request-Forgery as currently offered by Web-Browsers. > > So while use of certificates may mitigate this problem, we may not > ever know if it mitigates all problems SSLv3 has. I'm not expecting any. Honestly. > > For example, issues like 3-shake won't be fixed in SSLv3. I never offered TLS renegotiation to applications in our implementation, and I hardwired it to a fatal alert on the server in 2010. Conservative designs don't have to care about 3-shake. There are several more implementation pitfalls hidden in the TLS renegotiation design. > > In my opinion, continued use of it for security-critical applications > qualifies for gross negligence. Nope. Continued offering of SSLv3-only is the problem here. The original SSLv3 and TLS design protects the security parameters of the TLS handshake, so a TLSv1.0 capable client that does not send ClientHello.client_version = { 3,1 } (or can be coerced to not signale TLSv1.0 support by a network-based attacker) is the problem. > > Do we really need the repeat of the MD5 signatures story or can we learn on > our own (as in industry) mistakes? It would already be an improvement if the TLS WG stopped (mostly) ignoring problems (such as Vaudenay's), or didn't add new problems (such as making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm). -Martin From nobody Mon Nov 24 11:27:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D0F1A870B for ; Mon, 24 Nov 2014 11:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpQn5kOQasKb for ; Mon, 24 Nov 2014 11:27:13 -0800 (PST) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D2F1A700A for ; Mon, 24 Nov 2014 11:27:13 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id u20so7047444oif.35 for ; Mon, 24 Nov 2014 11:27:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bstCxcolFZYKVyCYx8YejclXOS6GCQEfwtKwz5U/V1w=; b=bORitSce6ZRg8Lyt89JUXoUxBJL/8anTqFb7eKTHD0rIRQmu8f3ICTf6Yc8VT5c5JP Kfj3Qib+dKhTDIFmb8+qPhY52lT/HMAbu5R+zHd4t5slpoZaOHRUZn9ql0hrNuyCP4UK 6C0UyVpr+CAJmm1PMyD2RLaWOGqGAfEpIa2rlG5Ko4HzdgfpfP51GFsaEByV/OmOghp4 t3aL4ZM6LQJxLUBZZVDNuAbMoGUaNvp4d+jPndhIKHhvS/saM8rGo7jBnq9EZQTbFh5K 67b7fLulon83JW2Mge8H2awtsTHQd0LwEnBtpovUQNwvYID5jFlrtBgg2J3nkfnOzwHK A1QQ== X-Gm-Message-State: ALoCoQlEzXy+s6p7YQqOjtIqHGBxmVPNs5xOjmmog5DGH/A04tBjJ5ypj6xgWMLAoX6DEq868GrD MIME-Version: 1.0 X-Received: by 10.182.210.232 with SMTP id mx8mr13684787obc.46.1416857232827; Mon, 24 Nov 2014 11:27:12 -0800 (PST) Received: by 10.76.19.144 with HTTP; Mon, 24 Nov 2014 11:27:12 -0800 (PST) In-Reply-To: <20141124171320.45D2D1B004@ld9781.wdf.sap.corp> References: <20141124170257.GJ3200@localhost> <20141124171320.45D2D1B004@ld9781.wdf.sap.corp> Date: Mon, 24 Nov 2014 11:27:12 -0800 Message-ID: From: Brian Smith To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-PRrgjvWHMz0fZl-10gX27CasGA Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 19:27:16 -0000 Martin Rex wrote: > 5 years ago there was an exhausting discussion in this WG about how to > fix the TLS renegotiation issue. The problem had been considered so huge, > that a secret group (Project Mogul) had been setup to design (and have > patches shipped) before the issue was publicly described. In terms of deployment of the solution, that approach wasn't successful, as the secure renegotiation extension is far from ubiquitous. The secret group designed a solution to solve the renegotiation flaw but not the quite similar Triple Handshake flaw. It would be interesting to know if somebody had proposed a (rejected) solution for the renegotiation flaw that would have also fixed the Triple Handshake flaw. In particular, we should recognize that the "conservative" approach of making minimal changes to address individual issues has negative consequences. Further, the renegotiation flaw, BEAST, CRIME, Triple Handshake, etc. all should be seen as evidence that the development model for TLS should shift to one that is likely to preempt unknown attacks, instead of one that reacts to attacks. > Please stop claiming that providing so much control to an attacker > as something that is (or should be) normal, rather than considering > providing so much control to attackers as what it really is: > a huge and gaping vulnerability in Web-Browsers and in the > (lack of a) Web Security Model. Attackers having that level of control is normal for people who build software for the web, which is a very large group of people in the TLS community. Ultimately, this means that adaptive chosen plaintext attacks and other negative consequences of the web security model are well within scope. Cheers, Brian From nobody Mon Nov 24 11:36:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653C91A886A for ; Mon, 24 Nov 2014 11:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McpZs4c8ppDs for ; Mon, 24 Nov 2014 11:36:15 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1FE1A896D for ; Mon, 24 Nov 2014 11:35:49 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOJZl2J006531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 14:35:48 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAOJZkrC004143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 14:35:47 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 24 Nov 2014 20:35:45 +0100 Message-ID: <2955685.UojdYEpn75@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <20141124182953.9C8251B004@ld9781.wdf.sap.corp> References: <20141124182953.9C8251B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_iIlsx27wehIPFpB-9d89PFf56I Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 19:36:17 -0000 On Monday 24 November 2014 19:29:53 Martin Rex wrote: > Hubert Kario wrote: > > On Monday 24 November 2014 18:06:22 Martin Rex wrote: > >> Hubert Kario wrote: > >> > Anyway, you should file a complaint to the manufacturer that it haven't > >> > addressed the POODLE vulnerability in their product (or that it doesn't > >> > implement advertised protocols properly). > >> > >> Poodle is a *PURE* Web-Browser and client problem. > >> Servers are not vulnerable to Poodle, and this site *REQUIRES* > >> TLS client certs for authentication. > >> > >> Disabling SSLv3 on servers is only a practical mitigation against > >> the stupid "downgrade dance" that so many browsers perform. > >> It's difficult for me to understand how someone could implement > >> the downgrade dance and *NOT* provide a switch to turn it off after > >> addressing the rfc5746 tls renegotiation issue. > > > > To exploit POODLE you need fallback dance *or* support just SSLv3. It's > > not > > limited to web browsers (and there are some clients that do fallback and > > are not browsers, e.g. curl). > > > > Also, are you saying that an *automated* system won't retry on connection > > failure? > > _very_ few, if any. Exactly none of ours. we're not writing the RFC for your systems only > > We're talking about average of 128 failed requests per byte decrypted, > > even if we fail just every first connection on a system that queries > > remote server every 5 minutes 24/7 that will require just a month to > > decrypt 16 byte password/authentication string. There have been far > > more dedicated and longer attacks in the wild. > > You may have not understood the Problem. > > It's a plaintext recovery of 1 byte per 256 requests on average no, you need 256 for 100% chance of recovery, statistically speaking you need 128 requests for a 50% chance of recovery - 50% *is* average, especially if we're talking about recovering multiple bytes. > A poodle attack will be pretty "noisy" on the server, so for many > usage scenarios, this will be sufficient deterrent, just like many > apartments have no bullet-proof windows and many doors have not > pick-proof locks. attacks are unlikely (in general), administrator will consider hardware failure or a software bug before an active attack that is *if* he will look in the logs at all... > And you could add random URL-parameters or other insert additional > header fields before the credentials if you absolutely want to > keep doing disclosing authentication rather than simply switching > to using TLS client certs for the requests. that means implementing mitigations. You might as well stop using 18 years old protocol while you're making changes to your application code > > SSLv3 has known security problems, > > more issues may be discovered in the future. > > TLS has long known weaknesses and well-documented limitations. > > When you remain within the safe usage areas, even SSLv3 is still secure. > > Really, what we should worry about is the current usage scenarios > where even TLSv1.2 can not provide protection, and one of these > is Cross-Site-Request-Forgery as currently offered by Web-Browsers. just because other systems have issues doesn't make this particular problem smaller > > So while use of certificates may mitigate this problem, we may not > > ever know if it mitigates all problems SSLv3 has. > > I'm not expecting any. Honestly. a protocol that requires 2 pages to describe all the pitfalls and workarounds needed to use securely is a bad protocol that basically makes it impossible to implement and use securely > > For example, issues like 3-shake won't be fixed in SSLv3. > > I never offered TLS renegotiation to applications in our implementation, > and I hardwired it to a fatal alert on the server in 2010. > > Conservative designs don't have to care about 3-shake. > > There are several more implementation pitfalls hidden in the > TLS renegotiation design. you did that, how many did not? have you peer reviewed your changes? can you trust those reviews? (see also: CloudFlare Challange) and let me repeat myself: we're not making RFC for your implementation only > > Do we really need the repeat of the MD5 signatures story or can we learn > > on > > our own (as in industry) mistakes? > > It would already be an improvement if the TLS WG stopped (mostly) ignoring > problems (such as Vaudenay's), or didn't add new problems (such as > making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm). Sorry, but that is simply not true. The specified behaviour is to select SHA1 in case the client doesn't provide the extension. At no point the RFC says that RSA+MD5 is a MUST or even SHOULD. -- Regards, Hubert Kario From nobody Mon Nov 24 11:58:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8041A89F2 for ; Mon, 24 Nov 2014 11:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQyXpScvwI7P for ; Mon, 24 Nov 2014 11:58:44 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E155B1A895A for ; Mon, 24 Nov 2014 11:58:43 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id A924120058D85; Mon, 24 Nov 2014 11:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nSecLQZLcCkwOb eQdoZJ1l9vss0=; b=mse9UD5BA9Sbt1G/GRXgjBlwXl+KSgJMnBr9emh4YBTng+ 16ibeWC8Rd9UasVHb/OPzszuJTg3pRtdD679vS3CRJ/+kB0bTGq6I/Xmc8Lf0+uU wyRFH7Bakb+I49pOdWxRLlhc9w9dB/3xFN4zYJEAcA7qRhfUOsh/zhefXyn2w= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id 565D220058D84; Mon, 24 Nov 2014 11:58:43 -0800 (PST) Date: Mon, 24 Nov 2014 13:58:42 -0600 From: Nico Williams To: Brian Smith Message-ID: <20141124195840.GP3200@localhost> References: <20141124170257.GJ3200@localhost> <20141124171320.45D2D1B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ijtpORRCkNyNXKz8B_tl_GERUWk Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 19:58:45 -0000 On Mon, Nov 24, 2014 at 11:27:12AM -0800, Brian Smith wrote: > [...]. In particular, we should recognize that the > "conservative" approach of making minimal changes to address > individual issues has negative consequences. Further, the Yes, and the session hash I-D takes that approach. > renegotiation flaw, BEAST, CRIME, Triple Handshake, etc. all should be > seen as evidence that the development model for TLS should shift to > one that is likely to preempt unknown attacks, instead of one that > reacts to attacks. Well, yes, but I think we need to subject TLS 1.3 to the sort of security analysis that is generally done for cryptographic algorithm contests. And the I-D and RFC really needs to include a security analysis where conceivable attacks are described, with text explaining why the attack does not work on TLS 1.3. Appendix F is a bit light-weight at this point. We can easily provide this for all attacks that have worked in the past against TLS and similar protocols. Finding new attacks is the fun (difficult) part. > > Please stop claiming that providing so much control to an attacker > > as something that is (or should be) normal, rather than considering > > providing so much control to attackers as what it really is: > > a huge and gaping vulnerability in Web-Browsers and in the > > (lack of a) Web Security Model. > > Attackers having that level of control is normal for people who build > software for the web, which is a very large group of people in the TLS > community. Ultimately, this means that adaptive chosen plaintext > attacks and other negative consequences of the web security model are > well within scope. And should be. Since otherwise the applicability of TLS would be quite constrained, and it'd be quite difficult to ensure that all uses of TLS are within those constraints. To make TLS 1.3 useful it must be secure relative to adaptive chosen plaintext attacks, and anyways, we can't fix the web security model at this layer. Nico -- From nobody Mon Nov 24 12:02:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD241A8A87 for ; Mon, 24 Nov 2014 12:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6eewSHPA3zF for ; Mon, 24 Nov 2014 12:02:16 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5095A1A8A75 for ; Mon, 24 Nov 2014 12:02:16 -0800 (PST) Received: from [10.70.10.64] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 7C0D6F984; Mon, 24 Nov 2014 15:02:13 -0500 (EST) Message-ID: <54738EB8.7040908@fifthhorseman.net> Date: Mon, 24 Nov 2014 15:02:00 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 Followup-To: tls@ietf.org To: noloader@gmail.com, "tls@ietf.org" References: <5470742A.8020002@streamsec.se> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="F81Iki6IElBU798IUhtq2Mo7XI3iMvBln" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Uf3ZdrzOjs_k_oxUyQ9W_6RamHI Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 20:02:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F81Iki6IElBU798IUhtq2Mo7XI3iMvBln Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/23/2014 04:40 PM, Jeffrey Walton wrote: > In fact, the IETF seem to accommodate interception in its standards, > which makes me wonder if its an unwritten agenda. For example, Public > Key Pinning opaquely accommodates interception by allowing attackers > to break pinsets (cf. Section 2.7 of > https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21). And the > ability to surreptitiously break a pinset is not listed in security > considerations. https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.7 reads: 2.7. Interactions With Preloaded Pin Lists UAs MAY choose to implement additional sources of pinning information, such as through built-in lists of pinning information. Such UAs should allow users to override such additional sources, including disabling them from consideration. The effective policy for a Known Pinned Host that has both built-in Pins and Pins from previously observed PKP header response fields is implementation-defined. Can you explain how this can be used by an attacker to break a pinset? --dkg --F81Iki6IElBU798IUhtq2Mo7XI3iMvBln Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUc464XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpct+EP/j/9IRbnYSaDuJSUyQnW9Lmh I9WgZPYrOBOfw7ztTBV5tEisX0hPkvEOxK0ylrF/wsX1MOTHRHCA9hHO4PJn0Es8 OhbI1bxNlvsqQgeVF5AyLpuipM0ph4NbhLU+lNUQ0c3naOkmsOlgs2QUSbg9SHb9 dSNR21qQNhwUoIpvccsAR2Zd35YQleRLwhxw5BVvOm+tj70CcP2aGOFsI1j1sQVZ Rx1sGBqF5kzqDyU6HlOCmE82CBeeyTs/rx+zsuNHCcmLZekV6Urg+a0ngOVmVr30 A30RaN5SrD12ZfjenjSEr4FIMOmfXImdD9mXLzlrPJDZxHb3pp64APXYLlX830ot s9MX2OXl8DOzLs5H+08cK2h9JYSMKnOl7MPXW+C+SNHkaDXVe9/Mbb8Yz8T+1ccK b+XnlFtxsYx1QzyHBclZU1JZlHwruLEJFDl040K9xIrvPVbVP1tmBLM+6v7UiUUJ OPD5/XsO6gML0mH6hyvti6aRby96+qA6zwrIUCJWx6TAgMuXzeZkOfm0U+Z59aVf BtsfwqHZj1IWDxhyrUfE8jb/I5hyq/cQv993j2Uofs0PXoXc6xt0GaDqHTlEDRtb PGxA98xD2XJzAJLdQeOa8BKwfdDGFcvoIHS4ppdFayIy4gS7DCT705JnEZiXIA4Y VGXXtaOQk/yRczcD1fJx =gAFu -----END PGP SIGNATURE----- --F81Iki6IElBU798IUhtq2Mo7XI3iMvBln-- From nobody Mon Nov 24 12:12:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64611A8AB6 for ; Mon, 24 Nov 2014 12:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrNgGXnFbZ6N for ; Mon, 24 Nov 2014 12:12:07 -0800 (PST) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB431A8A8C for ; Mon, 24 Nov 2014 12:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=2THN9qF9ZjYqLD8PDRiOYzuE8iwUNOyaNUj632wH0fw=; b=TWpr7MQBkpgdXgcIaoBr3F6RoO8E/typdeQZHzkzcUF+5xh2QMibggB1kScd+GZx1Nh8guB8FSqS9Zn7+DdXwvsYdFx/ySrsQu1FsMaaXK0+TnP7WdSLc24S8XwfcbdMKpQGVrI14cxRmY1/Vqu9zSaZ7Fhlxr1bhFMVSlrSkSo=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XszzI-0007q6-Kk; Mon, 24 Nov 2014 21:11:57 +0100 Message-ID: <54739113.100@polarssl.org> Date: Mon, 24 Nov 2014 21:12:03 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hubert Kario , tls@ietf.org References: <20141124155935.51E0C1B004@ld9781.wdf.sap.corp> <1713002.kBYARvl7be@pintsize.usersys.redhat.com> In-Reply-To: <1713002.kBYARvl7be@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XIlbxKIuAI86A8TBHpnQU9lnHRg Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 20:12:08 -0000 On 24/11/2014 17:32, Hubert Kario wrote: > On Monday 24 November 2014 16:59:35 Martin Rex wrote: >> How do TLS extension support fit into your picture? > > I don't know. > > That is: I'm using openssl command line binary (albeit with few changes, > modifications and additions compared to upstream) and as such I don't believe > I can send TLS1.0/1.1/1.2 Client Hello without extensions. > I'm not sure how (in)convenient it would be for you to use another tool in addition, but gnutls-cli allows that easily: just add %NO_EXTENSIONS to the priority string. http://gnutls.org/manual/html_node/Priority-Strings.html#tab_003aprio_002dspecial1 Manuel. From nobody Mon Nov 24 12:41:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4C71A9027 for ; Mon, 24 Nov 2014 12:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8BGAwrgPLC4 for ; Mon, 24 Nov 2014 12:41:49 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6A51A1A4F for ; Mon, 24 Nov 2014 12:41:49 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so7018639wid.9 for ; Mon, 24 Nov 2014 12:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JxGYzvOjIUN3i82s4xoP8tEwEn+RbPNWmosgg2Uuwew=; b=whsEm7uCXPjHuv6V0BSzL7HmwPCPxRZwdhDOvp6jQjUQbTBZnqVX/TnjRK9TFzDM9u JGqU252Zo6AxF/2NvwcNGLt9S4frwlf9WqdftCx2ZBOOAK4MNs+txlxrtVoXNeEOFT+Z X1Gd+x47ROLPivlgMccLiNMz/ScxNlmiBCWPO4l8si+hGgjrPvn6SFV8ODRlq5/6e++L 5e77OXsmJysaXGemEU5KJINaNVczCa2bbp3YJM8ZdokWGVs0q5zp5nQ+XNsNN5IhbWpy n24CDYNUx9iHJESzrJCoC726ryx2pErIfO6CCwOKtkjktWpCxE2P4DSfz7jmHhB6iS81 9xFw== X-Received: by 10.180.90.241 with SMTP id bz17mr25335515wib.41.1416861708026; Mon, 24 Nov 2014 12:41:48 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-228-139-23.inter.net.il. [84.228.139.23]) by mx.google.com with ESMTPSA id lp14sm13538148wic.20.2014.11.24.12.41.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 12:41:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <54738EB8.7040908@fifthhorseman.net> Date: Mon, 24 Nov 2014 22:41:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5470742A.8020002@streamsec.se> <54738EB8.7040908@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L1ZwBLuaUPUCKa1EsgOejrtescc Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 20:41:51 -0000 > On Nov 24, 2014, at 10:02 PM, Daniel Kahn Gillmor = wrote: >=20 > On 11/23/2014 04:40 PM, Jeffrey Walton wrote: >> In fact, the IETF seem to accommodate interception in its standards, >> which makes me wonder if its an unwritten agenda. For example, Public >> Key Pinning opaquely accommodates interception by allowing attackers >> to break pinsets (cf. Section 2.7 of >> https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21). And = the >> ability to surreptitiously break a pinset is not listed in security >> considerations. >=20 > = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.7 >=20 > reads: >=20 > 2.7. Interactions With Preloaded Pin Lists >=20 > UAs MAY choose to implement additional sources of pinning > information, such as through built-in lists of pinning information. > Such UAs should allow users to override such additional sources, > including disabling them from consideration. >=20 > The effective policy for a Known Pinned Host that has both built-in > Pins and Pins from previously observed PKP header response fields is > implementation-defined. >=20 > Can you explain how this can be used by an attacker to break a pinset? >=20 I think Jeffrey meant section 2.6: It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform). This is not some unwritten agenda of the IETF. This section was = discussed extensively. Browser vendors (among others) felt that Key = Pinning could not be deployed without the sentence above. The working = group did consider adding an optional =E2=80=9Cstrict=E2=80=9D directive = that would prohibit such behavior (and make such websites unaccessible = from behind an intercepting proxy), but ultimately rejected this option = as vendors (not the IETF) decided they didn=E2=80=99t want to implement = this. =20 Yoav From nobody Mon Nov 24 12:52:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3E01A8985; Fri, 21 Nov 2014 13:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 562xvSPrrORK; Fri, 21 Nov 2014 13:33:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BAB1A8939; Fri, 21 Nov 2014 13:33:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: Sean Turner , Joseph Salowey X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141121213350.31346.57940.idtracker@ietfa.amsl.com> Date: Fri, 21 Nov 2014 13:33:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RAE6HTLUuttcAsGvyY74kNwDXkI X-Mailman-Approved-At: Mon, 24 Nov 2014 12:52:51 -0800 Cc: Kathleen Moriarty , christian.groves@nteczone.com, tls@ietf.org Subject: [TLS] New Liaison Statement, "LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 21:33:53 -0000 Title: LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4] Submission Date: 2014-11-21 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1363/ Please reply by 2015-02-01 From: ITU-T Q3/16 (Rosa De Vivero ) To: Transport Layer Security (Sean Turner , Joseph Salowey ) Cc: Stephen Farrell ,Kathleen Moriarty ,tls@ietf.org Response Contact: christian.groves@nteczone.com Technical Contact: Purpose: For comment Body: ITU-T Q3/16 works on support for the TLS and DTLS protocols in decomposed gateways using ITU-T H.248 as gateway control protocol. Initial support of these protocols is available, see published Recommendations ITU-T H.248.90 (10/2014) for TLS and ITU-T H.248.93 (10/2014) for DTLS. Initial support means that the (D)TLS protocols were modelled by so-called H.248 bearer connections (termed as "TLS bearer session" / "DTLS bearer session" in the Recommendations). These are abstractions, not necessarily equivalent to real (D)TLS sessions or (D)TLS connections, but sufficient for basic support by H.248 gateways. However, additional support in the area of security and multiplexed protocol stacks ("WebRTC") imply a more precise model of TLS and DTLS protocol objects. ITU-T Q3/16 would appreciate if you could provide clarifications particularly with respect to: 1. the distinction between (D)TLS session and (D)TLS connection (which implies a definition for each term, beyond the available descriptions / glossary from RFC side) 2. the DTLS association concept, e.g., is it equivalent to a DTLS session or DTLS connection or something in addition? 3. the TLS renegotiation procedure: what is the definition and at which level (TLS session or TLS connection level) does this procedure occur? 4. the TLS resumption procedure: what is the definition and relation to TLS renegotiation? The location of TLS or DTLS endpoints in terminal and gateway equipment is slightly different due to the decomposition approach of H.248 gateways and their internal, hierarchical model of H.248 terminations and H.248 stream endpoints. Support of (D)TLS procedures (beyond the pure establishment and release) demand for the unambiguous detection of events (such as the differentiation between TLS renegotiation and TLS resumption from TLS establishment). As part of the support of (D)TLS endpoints, the H.248 media gateways are able to determine the TLS profile and protocol capabilities via so called auditing capabilities procedures. However it is unclear which protocol capabilities are related to a (D)TLS session and (D)TLS connection and thus the MGC and MG may have different interpretations. The results of auditing TLS protocol capabilities and parameter values should be based on a common object model between the H.248 media gateway and its controller. ITU-T Q3/16 is appreciative for your cooperation. Attachments: LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4] https://datatracker.ietf.org/documents/LIAISON/liaison-2014-11-21-itu-t-q3-16-tls-ls-on-tls-and-dtls-terminology-to-3gppa-sa3-ietf-wg-tls-3gpp-ct4-attachment-1.pdf From nobody Mon Nov 24 12:53:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681BF1A1A1D for ; Fri, 21 Nov 2014 07:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIqaHo2raz6Q for ; Fri, 21 Nov 2014 07:21:42 -0800 (PST) Received: from itu4out.svc.unicc.org (itu4out.svc.unicc.org [206.155.102.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A691A1A46 for ; Fri, 21 Nov 2014 07:21:35 -0800 (PST) Received: from TUCM01.TUECSP.UNICC.ORG (unknown [10.81.6.70]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iccpfxor04.svc.unicc.org (Postfix) with ESMTPS id 0A33460DB9; Fri, 21 Nov 2014 15:21:34 +0000 (UTC) Received: from TUCM02.TUECSP.UNICC.ORG (10.81.6.71) by TUCM01.TUECSP.UNICC.ORG (10.81.6.70) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 21 Nov 2014 15:21:32 +0000 Received: from TUCM02.TUECSP.UNICC.ORG ([10.81.6.71]) by TUCM02.TUECSP.UNICC.ORG ([10.81.6.71]) with mapi id 15.00.0847.030; Fri, 21 Nov 2014 15:21:32 +0000 From: "TSB SG16 Secretariat, ITU" To: "3GPPLiaison statements (3GPPLiaison@etsi.org)" <3GPPLiaison@etsi.org>, "'Susanna.Kooistra@etsi.org'" , "tls@ietf.org" , "mankin@psg.com" Thread-Topic: COM 16-LS 133 - Outgoing LS from Rapporteur Group meeting of ITU-T Q3/16 & ITU-T Q5 /16 (Seoul, 3-7 November 2014) Thread-Index: AdAFnrUUg43k4GdaTECP0WqXvCJoFQ== Date: Fri, 21 Nov 2014 15:21:31 +0000 Message-ID: Accept-Language: fr-CH, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.81.64.102] Content-Type: multipart/mixed; boundary="_005_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4qRjjhBRZdlXctVXQGktoZ4fo20 X-Mailman-Approved-At: Mon, 24 Nov 2014 12:53:17 -0800 Cc: "Paul E. Jones" , "Campos, Simao" , "Christian.Groves@nteczone.com" Subject: [TLS] COM 16-LS 133 - Outgoing LS from Rapporteur Group meeting of ITU-T Q3/16 & ITU-T Q5 /16 (Seoul, 3-7 November 2014) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:21:46 -0000 --_005_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_ Content-Type: multipart/alternative; boundary="_000_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_" --_000_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, Kindly find attached the Liaison Statement COM16 - LS 133 with title "LS on= TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]" agreed at = the Rapporteur Group meeting of ITU-T Q3/16 & ITU-T Q5 /16, held in Seoul ,= Rep. of Korea, from 3 to 7 November 2014 inclusive. Best regards, _______________________ Rosa Angeles-Le=F3n de Vivero Administrative Assistant for ITU-T Study Group 16, IPTV-GSI, JCA- IPTV & IR= G-AVA ITU - Telecommunication Standardization Bureau (TSB) SG 16 e-mail: tsbsg16@itu.int IPTV-GSI e-mail: tsbiptv@itu.int Tel. +41-22 730 5445 Fax +41-22 730 5853 --_000_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Kindly find attached the Liaison Statem= ent COM16 - LS 133 with title “LS on TLS and DTLS terminology [to 3GPPA SA3, IE= TF WG TLS, 3GPP CT4]” agreed at the Rapporteur Group meeting of ITU-T Q3/16 &= amp; ITU-T Q5 /16, held in Seoul , Rep. of Korea, from 3 to 7 November 2014= inclusive.

 

Best regards,

 

___________________= ____
Rosa Angeles-Le=F3n de Vivero
Administrative Assistant for ITU-T Study Group 16, IPTV-GSI, JCA- IPTV &= amp; IRG-AVA
ITU - Telecommunication Standardization Bureau (TSB)
SG 16 e-mail:= tsbsg16@itu.int
IPTV-GSI e-mail: = tsbiptv@itu.int

Tel.  +41-= 22 730 5445
Fax +41-22 730 5853

 

 

 

 

--_000_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_-- --_005_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="ls133-16.docx" Content-Description: ls133-16.docx Content-Disposition: attachment; filename="ls133-16.docx"; size=30088; creation-date="Fri, 21 Nov 2014 15:03:50 GMT"; modification-date="Fri, 21 Nov 2014 15:21:30 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCFp7lQnwEAAFwIAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lstuwjAQRfeV+g+RtxUxdFFVFYFFH8sWqfQDjD0Bq/FD9vD6+04IRBUCQgvZRIpn7r3HdqRJf7gy RbKAELWzGeulXZaAlU5pO83Y1/it88iSiMIqUTgLGVtDZMPB7U1/vPYQE1LbmLEZon/iPMoZGBFT 58FSJXfBCKTXMOVeyG8xBX7f7T5w6SyCxQ6WHmzQf4FczAtMXle0XJF4O2XJc9VXRmVMm1JfrvOD igBF3JMI7wstBVKdL6za4+psmVJSbnriTPt4Rw1HEsrK8YCt7oMOM2gFyUgEfBeGuvjSBcWVk3ND yvS0zQFOl+daQq0v3XxwEmKkWzJFWleM0HbHf5TDzs0EAimvD1JbN0JEXBcQr09Q+TbHAyIJ2gDY OjciLGHy2RrFL/NGkNw5tA7buI3auhECrGqJYefciDADoSD0rk9QGZ91D63kV8Zn5FOemBTQBsHW uhECaYBA9bz8JDY2pyKpcxScjzSQwj+2vZsfpbpDG/YQUJ/+0upEsr54f1COJgXqr9lyHtGZi+Mr mwPhfPNvMPgBAAD//wMAUEsDBBQABgAIAAAAIQCZVX4F/gAAAOECAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAArJJNSwMxEIbvgv8hzL072yoi0t1eROhNZP0BQzL7gZsPkqm2/94oii7UtYceM3nnyTND 1pu9HdUrxzR4V8GyKEGx094MrqvguXlY3IJKQs7Q6B1XcOAEm/ryYv3EI0luSv0QksoUlyroRcId YtI9W0qFD+zyTeujJcnH2GEg/UId46osbzD+ZkA9YaqtqSBuzRWo5hD4FLZv20Hzvdc7y06OPIG8 F3aGzSLE3B9lyNOohmLHUoHx+jGXE1IIRUYDHjdanW7097RoWciQEGofed7nIzEntDzniqaJH5s3 Hw2ar/KczfU5bfQuibf/rOcz862Ek49ZvwMAAP//AwBQSwMEFAAGAAgAAAAhACHfM/d6AQAA9wYA ABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAArJXPUsIwEMbvzvgOndztH1RUhoIHdYaDF8UHCO22zZBsOsmC4NObgaEGhY6H HPdr8+2v3ybpeLpRMlqDsUJjzrI4ZRFgoUuBdc4+5i9X9yyyxLHkUiPkbAuWTSeXF+M3kJzcItuI 1kbOBW3OGqJ2lCS2aEBxG+sW0D2ptFGcXGnqpOXFkteQDNJ0mBjfg02OPKNZmTMzK13/+baF/3jr qhIFPOlipQDpRIukcU5GClw6U25qoJwpLiTpUdEYYUlwjGuj12AfkaD4cp8cF1od3n7VpQN53hAY 5JIlp4mvQxJbIHKzsD/AByV2XucQ7kIiCOUG5gUGpeB7MYtbrM8xZIOQEOTWehC7ci9mfUEEZbC0 leBPYlf3tc9CtseVWoBxo/8h6KQ+iGFICMASNfkpHJTeHIIGUWmkOV9Ibz90Uh/FbVgITb+S6KTe KNLQFGCOEcD0HombkP0/YfH+54byxD6Qh6A3O/DSD2Jfd0EkR7+ryTcAAAD//wMAUEsDBBQABgAI AAAAIQBPl5IdsRMAAPFqAAARAAAAd29yZC9kb2N1bWVudC54bWzsWtty4sgZvk9V3qGLq6RqGBDi XGtvMYA9bGHMGiZbSSoXjdSAdiS1qtVge67yDnnDPEn+PkgIkLAMA+PJjquMWq3ur/9Tf/+vw08/ P3kuWhMWOtS/KhjvywVEfIvajr+4Knya3hSbBRRy7NvYpT65KjyTsPDz9Z//9NNj26bWyiM+RwDh h+3HwLoqLDkP2qVSaC2Jh8P3nmMxGtI5f29Rr0Tnc8cipUfK7FKlbJRlK2DUImEI63Wxv8ZhQcN5 +2g0ID5cnFPmYQ6nbFHyMPu8CoqAHmDuzBzX4c+AXa5HMPSqsGJ+W0MUY4HElLYSSB+iGSzPumpK T1tArlhixAUZqB8unWCjxrFocHEZgawPKbH23GjcY2BUT/NBj+FHOGwA84hvq0meqyQ/jGiUc3hE QMQz8oiwvWYkiYcdf7PwUaZJGNeovQ6gsgsQLE5zzi2jq2CD5pyGNvA/x1hiZ78CSzs5qVp4mjCT JQ5gB3pWe7DwKcMzFyQClyGwOhJhXbgGxplR+1kc+czVhzHTjd/Qo4iUVqtiFqDJnwMAsJ9woaQH DPEzXfH40tx5InZ8sUtc9w5LLJfMxSjAqjVSkJizWGZfL+2iiYUp/Qzj1ti9KpThT0yaOyzkDxRA 5KmLk2fyYpe6K89PXN/q8OnHD8DJ8dnforNYhtgwt8yxRXMBR8BQohtVo6H02eoGz6b01uqpYxst M6W72kyDqBqVlN5GuZXSa5rV2kaPSHzO4CpkKftBWLFRr9QbNaG77BqzRKcarfS3sM8nASQFjae7 uaV+ozMdPNIq+y5f3xG2IJELGYF0yHgkocYI8koXdfbIHK9cvn9lvKPKDMJHZLmJWBXGOLHXsQdS DvyQMD6kC6qETRtubIbb/soTZxZ1b0SYgR/16RCrs0wUOVCjcLFB8Wp7cN+3Y/nUXsn0j/bDTA7z 6ZhROpft8EtkZ7OuQFzsL6I+4hc/TYQYBITthA6+KnxZFrsj7QyNqtMRNIO247uOT5DthHwq7SZa H+LWMG4JxwnRgjZ54qKosZ4gQBtGrQKesZ6vCk2zGW0PGDOfE4v31UgQzGiVawAk3FlAoGxLTptF lghErTRmSDtDGXHsWHzFCIIOm4QWzHL4qkhdxUpB2xqtbxkOlo51w2CC0A3DTtn0DKn1OdQEjI/I 0yo7+rS7BBOTThiASkI+aczD65+6agKqhzlGK7afzF6GCpQFAQ1a7SAWC1ono/lr8I/QWZyAKbT3 yrm8F81RCFgIpJy1b+xNF2P0cUmwHUY+2EaRp1tSzVwnuHFcV6wg2oi1iTcjICUb2JKycTtk1gOs pNqcEW4tRXMO03R/KXFBrrGBFWdhAJrPHu+oDUrjFafSd09z5okjZHX0JK3yrGMdi/1zYPOUNpMD 4J9bQj0kGoJYLS7B8XoYasmiIaLbp0IquYTrI5HrBfzOFc/hhCHXgbK7KZKtlknYFehJtjl2XNUu CSSttdBTN+FfXksEaPJc7Q5FLJJ2Yr4RFCR/A50bDuSamlGXtLyTa0QmnATYjxhPkuBF8ozUP+bQ DQ9XoqJCXhHK6YEvkXsWBChzPRhN+w+jznRwP+oM0bQ/7Hfv7+4+jQZd2YegdT+Ser/OqrJ22LXq Jc0XTPizG9cKcEcH+XZGmM6He4ZpZtg2x2hhGzAaMurov//+DxpOkGGastnPNpysgeTck8sp0fuR 6GpYZexaXLedUGddymFpJY68ddAljo05eUWltCl+dALNE67VclWWci+QQPUt1KHb/KAqt1k3lMdE jEaE9Vq2yAco4nqPLbbC/SsuNWMqzK8n086o13noDf6h2GnS707vH1J22QX52cOu28XBng5nYGtR VUF+xBbEaABhR9gaqqTJ9FPv72jcfxjc99CuC/IBX1fKhlmEn3o2Y2XvnWq9nmPvyHvUS26Q3614 hwpy3GL+ZOTt+uhyPN1Qt+in87QY+oEym7BQ6kU5h2pOryKe6riSQcMvACXJUweR5DwgUsp0SRm5 KAb7ZhmgmsgAlIl7z6NyQBR1Z8oB37/tT8kmX58fzmdMwOi4ziJeziI+V+VgTjOfi35eW4bmmws6 XffBXE64RNR3n1N4/Q1R8PlscA8LOz5220hbIzvBnZXqzZp8DpCD6uupVL+7WyThfWOC2PdRGpFL YE3kHiFcvoI66rmnZBGNNHNXJHDEi5MklLyRj6Fk/Z+WFDSFx27OU58mg+rXFZT8DvX/Ev61nR1P mS42zXqeRHM5F2cbgl+bJaP+DtVKx5WGrWoe6pf+uGQwp/BSgmgOWGNC6Mp9h0xURA00omvxmI8h KJyrb51XMt7H7boiItBv4IpNRj6BbSR3Ru9GHK7KhQ1BRHWCIgj9dmSfIOTjk7QL+lXI0cwxHHQG E3HjOu1M+3f90fRHOrpwOmomAiSkKyY+NzkihegXsUcHwkQufUz2aJrim5oXPXK559WH+PJXkT7+ n2JcTPv+7/aEUI58m4vnwLlC1uhJxIGt09rl1mivvG7ryBRzwtaZiqXPvXP+KH4+tHmHE7h1RFM4 YHBeTzQAxHN8UG+xfUepfzKeUKJ/corM2/G4gyYd8x0a9Kc36LdbAf1O9qPutPqvHDSxH0yZD370 By3bxNLpmuV+b8fGra5Rv4ktOZV9eqBC+Kpk85o6bCcIORUBc74IzGGdZARuD5cRmDBb3vIu2tmZ IakFyJgm4/TkoipV807F6DQ6l4qLitGUjzxPeYp+DgfmKrRyuSyNy28oQ9gS99KI02M4vdEwZVp6 wWzx+9DcZstmXrPSuKlJX8Vma/Xq4p4+Ybbt18/DCSjakXpubYDkJ1VzVux+1GIeNu9+qjyII2wq SXaXe7/ONrksff5xt4lFPfmN/xvbJ9u74YUKZd9uKfukqxTdqVOUIYo/YvZ7ilnHV5/5vUF+z47b FH7vlKuV5ktxOwBld4I2dUllnqjs/RHQ30tAd4KAUVDsTYVxtsU+1KuVlrwZ2FhMVbRntVhcjGy+ DP8dF38Z71Qk6TeKDzgIKONkxfY+ZEla4vCzgv8BAAD//+xb63LbuBV+FYx+dOypI+t+cddqLclK 0m52vLY7+3MHIiEJCUmwAGhFeZo8S56s5wCgJEoURdlJk92pf0gieHCu3zk4AOnlVUCjOVleMar0 jeL0uvKevvrnXeVy8NPl8kreycFPyytNPobBlYqpx64rsWSKySdWGbyWIokJ0mlLjbQSmEnF/fvr Sq12M2rWbseVdOhO4mB/VO9M2hVDbPlPL83nSJWRGjKmOehcJLfWazdq3ZPkLst5YiBm5Nci0d1x Z3IzeamUZqFXG/Wb7s1LRVzWO+QvNIz/ViRqOGzedtvfwpH5wS1G01exuzB6387eQZuAx4tkT0bd Tr3+o/j6RZk7OCvi3Wx0J+3WDm83uMfbE4HA2U80MJkNf2jdiyx/YCIJLgrt73YanW6OqS9TZ3DP 4uqXz2L25fO/hGT0gnS/fP5BXDX4RTyxcMokadTqrW+IjfMMb/iMzaf27JelKi3QDT6aMUdoOVh5 Ho30QxxwbbTR8g3j84VOvdRsd50bUnpUAz/Tq9+AdHldadR7Jgx6FQOU/I/UenYuuf8Q02jNzw5r byikz6QyHhBaizClULB2BQxZqU/XlXrD/LIAreFvE8TrCk20SDXbMDNXVrP4RAfdj9mMJoHeJ7/b 8VxsBRREEWPmiJ4LgjGjfsAjdnUYDAdj0e02+yVi0f5DxGJy2+62bzOx2Mpv5+b4Qa8Clqr980Pq PadVGgzr2npR7tbGrX6vazPkGcvCVlnUgwmbyoTKFRaM9slJfdtpTW6bO35yS3wmqbdllkrqRq1V LqnrnbppEo8AqZEDJC0w6N8ORbneOYyiLPl3yeiRiDT19HMSutVoG68diYOJ6veNw3YRrbUavWwR dcTGWc4pC8mV5mADbJaemMpxzlcS6MKHBuPuCCLEZtBioO15ReImUVrSgNOdbJ8K8SGk8sODphIT ivvgSuO+iIbA7ffXYki9DzYSKfFt5G9InbQSUa/ZzuaPkn2tSf22b/jvRsZVqOLIuERxvZjR3Wev Rm+227CDaehkl+WDIX1kQTYXvwJTism/x824YNi+mQzzPXaK1n89pPJ+BjxfSKdOmqTf7MNXq909 OSefAQen+RYcDiTq/x4ntyHl3xgpC8hwCf3KByJNlZBv/R66ZwG1UcgVpK1lfUyozLRBb1Ku1m9H DfXSWlydm1r8j0gz75OIWNUT4S4I1ip/FW+U6bQyRRO/7NRsAuT1lnk908kbodI9U7/fMJlwpGr3 vkPVzvXO4TQttQs6lqbqU2pS3ZlcKnHzgo1f02DPqsawPqltjoW2DOiPO82OcVdenSlC3tvHf796 JL828QywqOA62QWclkJ+UERERCVxLKBlACcVsmy1Wp1eIUu9YC9U6vHnB0KhJxnjj5cpE0uhBaBR vVAlHhGfQZ2JhWI+mVPNlnSlSIKJQGw43lQbrR6hKr1LPOiopQhIqkOVvI04FLBg7eyytuGpNbhV sTUvRXi2GT3ZIkKfYOGg04BdEMWAczINuFqAdfdoaMgin2ouIrVtXrVfI2f12iUeMZ0brKSxyhA1 d4gwkPvWh4wCd72gGo0jZ+NzZLaxcMkkI6HwWRCAVtMVUeKVR82F9fWUUckk+jlintX1TDMZAgGE oYLcHIliSsH9CrkkFYOq3XGIL+qwY/p5lTwatwMxoVNsua2cCxIJTUAqzKeSByvC/pNwqBksAmNE 8dHssHUztscDeiAZDV4Yx9KynIOdzZD1MvX5lgcvyDTREKLZjHscrcH4Tani3jpuEAnr/zQNqhkV bG3cre1WkZwqWO923HnQ4So4eCOW7InJC0J9n6OeWzByoYMQUQJ5opiXSK5XBpUhCOFxwD4CJFJg EQX7XCh6Z5Xf2PT+cVQ5JzyMIYQUwCYxxZjHlUMecsyUozUXMX0PLitje7/TqLc369qJth9fAZYi CQDxsVEcQlKIiNGk1hmNCkvdjKxEAphArmDuE/f3WRbM9wLICECPqx5llRnEsGPlXgKzg9UJ4siS 6wWByxjCAblXWl7eScdO5LLxORI5N2SYuO4me+wH3esdlXQuabywvUaUhJaSB09BSucaFLj3Frfl ZqzjmhA3AZV1LXWBZzArfGyZI5PaUPP0krHoYERsw7VlhuuR+E4jnq0jp4QKs+grSd+UrFMUOFsu uLcw+c6Zgoz32YzjsgTuwULHKNzFJQTKIFsJUNeUlnSlBHLlSR5bZF+SeSCw/q/ITIqQ3E9GBCxh eQ9ISgPLQfQHARZiqCihtlR7zvK044ayEDCFmColsNzlIOBEDQFKHov1BWHVeXX/sWLBVA5tWHEX d1x8ceNQMJGWFmwd5vIVl31zvckgHFIiZHqB3Sysp+kqm6vN4O9/Hnw/bwfzTNii0yWL2FzofNwe nntiblmNhsNuv3nrIAALucf8RJZJ5yybgkXzZLCTJXb7HLt+LKbr2osLA9yw1TmAVi8gZzuY3YGs ITo/JV98wVAuCF/7onwGCQ+6yj99OvyY5d7mjUpCs+7+P2m2k0aywJQSXDuO1pdtsZnjhRdBuDFq jm+yT8BLbmJgb00CYTcK6UYrXZ1gDx4LHmll9nfQkXHc86HJ6fEKLpxxiOsmuEYFeBoKmzifz2ZM 4qifMPSKdZo9unF+g52SwEYPRGY3soY/TOASpIJQEHlBFpxJKj0oTaDAelNoJzrFbD+Ik+2w0rAZ DTc2VMmD26zCzM05h8UW7ES3es0YyxKDLao5jTHmuTgzqtg5mBLiNTarSJ5ENJzyeSISBbd0up7P CJRHdN6ZSsBQarGTlzoBVfoeFAWf+Xd0zoag+Qd79nugjKYOthhb7yr20Gf0zuau7ZNNeLctPK+W 3yXeQPnGR5v2RIzsHYJZqj1vr0NRWtAF8s/lfiBLbehD5nO6AVRpcfaEKTCQxUAirpgx0YFlxuEm unR9AuHRmE55AKAGDD3tPQouVFYJ4o7SaIK9HvR92+zKqn2A+wbbJ+hUHgT5890ZEXbkUBCSyIOM ka6lyPcZ+twUUHADuJ2mYEm7DvT23nbT1YjEptS71yMz8O41CaEmLegT7rnTEmSKCGiobYXYt/BI ccTMCSCLAcfrMGUOobLmIDigMQgRPgTW+4SVB2C+EmphToGmDI8AwUti//TAwZfgwSmWHnMs5upk WhvQUznpYTTmYJ87KQ+YrB5fibKPTbZXIvdy1DNWInucVuQrJ9Vaa8/dAGXrQzcOcceavBIJHkiL GNYMjHkJeybd2qi++47oZNhs5D81ypIbI92Q4ex6Hzq1j+zoNG39TDrgNFgHryvdfvo2ziGKer1f P0bS7qXPCQ+S9HvmPT70gtNJQJLOArG8gxS1DzPxMeEDhmR8u3P9i7323yewSuEK/zbyzdB7by2P YZI5NdhHfQOdQGTWTUeQPoRcpo2h+jRS6c2Gc8PxV2wxdlu98ot4ISR+z/wdh8mo1xl3Nv8Tsb2H yNzZhr1RR0E+3mXzPjPhAe7j6NZ7egtGoSG4Z6aMebjzcI+LrdDK5j2AvpUxE0LnTZhxqbbJ7ftF YNn8AR+84jt89b79T48Fvs/Xa60J3mHxxmfOMN6y7/lJRABOaRr825dBN7cDNtu6a20ApDdMrbAa ri/niTaXTpx93pTWBaSxeOI6YHdz89sX3mvJcSeFb27ece2Bxs1GuqOyXjY/p8JfmR8wJUEkDv4L AAD//wMAUEsDBBQABgAIAAAAIQB/0mJfhgMAADkMAAAQAAAAd29yZC9mb290ZXIxLnhtbNxWS2/b MAy+D9h/EHxe46TrM2hSrC3WFdiAomm3syzLsVpZFCQ5bvrrR8mPJH0EaXracoglkfxIfqQpn5w+ FpLMuLEC1Cga9PoR4YpBKtR0FN3dft85ioh1VKVUguKjaM5tdDr+/OmkGmbOELRWdlhpNopy5/Qw ji3LeUFtrxDMgIXM9RgUMWSZYDyuwKTxbn/QDyttgHFr0dU5VTNqowaueIkGmisUZmAK6nBrpnFB zUOpdxBdUycSIYWbI3b/oIWBUVQaNWwgdrqAvMmwDqh5tBZmE7+1yQWwsuDKBY+x4RJjAGVzoRdp bIuGwrwFma1LYlbIVq/Sg72P1eDC0AofC8BNwk9ro0LWka9HHPQ3qIiH6Cw2CWHVZxtJQYVaON6K miVyB/vvA9h9DqCnHyvOpYFSL9DEx9Cu1EOH5V/qd2A1RV5OzX4smElONb6BBRteTRUYmkiMCEtG kHXi2zoa47BxiWwe16ZZ/CGV75Dj492vES7dXKNh+kij2CvcMzybUTmKGL5Y3NSnaPaTzqF0nUEm Hnm6EAI8tHZ9/HngTBjrbgBdha2ky7sgPAdZFmpJvnKg4McZDtBu97vdodN4NaVLI1K/nOITMZYS 7HRbFRy+1RDHdnrjIz082D043Pf44ejaLB3W2rUPRpWbaByVb3LkvTTKjtX/7W494Y6dYV3xJgkb 0C20r7Hk3sA+jaK9sNCU8YYPBhIwWlo6qHEkz3x1trJNwDkotrU2Yppv6dqztpI/+0UDa002SNv+ 4SuktS5flwfUABRWdR08sRvVvT284BktpXspuX7WJLp24NPE5FEp4ThoQ8Z1sI38qeVocNREGSRx h9C15os+bCCSulrnNjzfAsScx9+cw9bEq3UYOKiFG/lYg+pHV1tNbbjlZsajMZlAwQkYQqUkkBGX c4K3DDeCSkKdozjdUuIABcISKaiwoPzHkeP+7kbdOUk4sWVyz5nzile3d4SBnocq98gVapcsJ5Qw ankNUwl0hlZCpYIhUoqr4NkfzERaou+0+TrokRUOPN//S0Osa4FJw1lLJPLBLVHgCNZu5pn3fJXI 6POiYbBEOItcYhOlyK0ujQbLv5AEbwDRAdhgZjheSmnJfLd5qNAGhmhqnN+iOpaGIkYifam8ViVc 7i8Tb46jIAcjnmoJGmD1e68ULLzKzZxth/o/UcYufPzwH/8FAAD//wMAUEsDBBQABgAIAAAAIQDf 2dCEtAEAAN8FAAASAAAAd29yZC9mb290bm90ZXMueG1spJTLbqswEIb3R+o7IO8TQ9TLKQrpolGr bnt5ANeYYBXPWLYJzdt3ICGhF0Vp2dh4PPPNPx7s+c27qaK1cl4jZCyZxixSIDHXsMrYy/Pd5D+L fBCQiwpBZWyjPLtZnP2bN2mBGACD8hExwKeNlRkrQ7Ap516Wygg/NVo69FiEqUTDsSi0VLxBl/NZ nMTdl3UolfeU8FbAWni2w5nvNLQKaLNAZ0SgpVtxI9xbbSdEtyLoV13psCF2fNljMGO1g3SHmOwF tSHpVtBu6iPcKXm3IUuUtVEQuozcqYo0IPhS20MZf6XRZtlD1seKWJuq92tscj6uB0snGpoOwFPk 59sgU22VHycm8QkdaRH7iFMkfM7ZKzFCwyHxn45mcLjJxe8As68AuxrXnHuHtT3Q9DjaA7ztWe3V /gVr1+RhaX6cmKdSWLqBRqYPK0AnXitSRC2L6NSj9rdmi8GTEzVp2Fjy8MoKJwI6RiadZ2ySdI6W lvSm5Y8Zi+Or2ez2etl6dKalKkRdhcFOG+HaYY/jiznvbDTabuxT/yhDIgQNdXf7n75Kisco+pF8 TN1g4RcfAAAA//8DAFBLAwQUAAYACAAAACEAkZiyS7QBAADZBQAAEQAAAHdvcmQvZW5kbm90ZXMu eG1spJTNTuMwEMfvSLxD5HvrpIKFjZpyoNoV12V5AOM4jUU8Y9lOQ99+J2nSlC6qCrn4c+Y3f3s8 Xj68myraKuc1QsaSecwiBRJzDZuMvfz9NbtnkQ8CclEhqIztlGcPq+urZZMqyAGD8hEhwKeNlRkr Q7Ap516Wygg/N1o69FiEuUTDsSi0VLxBl/NFnMTdyDqUynuK9yhgKzzrceZ/GloFtFmgMyLQ1G24 Ee6ttjOiWxH0q6502BE7/jFgMGO1g7RHzA6CWpd0L6jvBg93Sdy9yxplbRSELiJ3qiINCL7UdjzG d2m0WQ6Q7blDbE012DU2uZmWg7UTDXUj8BL5+d7JVHvl54lJfEFGWsTB4xIJH2MOSozQMAb+1tUc XW5y+zXA4hRgN9OS89thbUeankZ7grcDq63sL7D6JB8fzU8T81wKSxVoZPq0AXTitSJFlLKIbj1q nzVbjT9O1KRhZ8nAKyucCOgYLek8Y7Oks7M0pR8t/5OxOL5bLB5/rluLbmmtClFX4Win9XBtc8Dx 1ZJ3a9Taru0jfyZCIgQNdVf6z6eC4il6PiWf0TaO/eofAAAA//8DAFBLAwQUAAYACAAAACEAxFup xYwCAAA0CwAAEAAAAHdvcmQvaGVhZGVyMS54bWzcVltv2jAUfp+0/2D5cRJNQlvoooYKtbSr1KoI 2MOkvZjEIVnji44NKX3af9g/3C+ZnQvQG6JlbNOe7JzLd77j48/K8ckdy9CMgkoFD7C352JEeSii lE8C/Hl03jjCSGnCI5IJTgM8pwqfdN6/O879JAJksrnycxkGONFa+o6jwoQyovZYGoJQItZ7oWCO iOM0pE4uIHKarucWOwkipEqZUqeEz4jCFRx7iiYk5cYZC2BEm0+YOIzA7VQ2DLokOh2nWarnBttt 1TAiwFPgfgXRWBCyKX5JqFrqDNikbplyJsIpo1wXFR2gmeEguEpSuWzjrWjGmdQgs3VNzFhWx+XS O9huBmdAcrMsATehH5VJLCuZr0f03A0mYiEWGZtQeFizZsJIypeF33Q0K4frHb4OoPkYQE62G84F iKlcoqXboV3y2wWWFfUrsKohr7amtiMzTIg0CmShfznhAsg4M4zMyJA5dWSvNe6Yx0ai3DePVDQI sOt67VZ7/yOuTX2wxnar2WofLoxnNCbTTD/19FdMBXIfimWo5xk1MTOSBfgTJREF7FjPt7C2hkai tRXKNHVfO70j63Aqj7MAhmdpbgCR+9qesa8kCc2RSKCKwoziTgPZGF1GblkizqLThFiAajeaS1Ns TCdGP1XkliVSrjSM6N0L3aB+96KH0NcP6Lo3uOid3wyuu6Oiw0XiLjtVVBIgmj7brK3RbXrddne1 Bhd9ECIursGa4XWaOx8T5dFvGtJLw2k86MHeahv9QI2PhLdjNVqK5tUwLhIbMQa4eeD+bZ3+AyIa jr5c9Qa9c4TMvwSfsjEF9F+I6PTmGnkt9PP7D3Q1RN7+frHt/VlplffeKf55O78AAAD//wMAUEsD BAoAAAAAAAAAIQDbr6KLQxcAAEMXAAAVAAAAd29yZC9tZWRpYS9pbWFnZTEucG5niVBORw0KGgoA AAANSUhEUgAAAGsAAAB4CAMAAADCI/wLAAADAFBMVEWixNmHlcTs8fKKttLE1t+8093c5unV4eWY hKdkjrysytqRutUbN4/6+vqlss/qZ4XyxdAoRJaWo8nkVHZ1pcixzdt3ibvx8/g4U55pfLT09fbG 2eCtaI7Dy+KHo8bN3eJql8HvscDQ3uSdwdlKYKe40uPo7e9Zbq3k6+zg6OrtkaeEs8/k7vTe5+rr 7/Czvdji6uxVfrTkJlLyn7LY4+bT2OnLKlfI2uHz9PXA1t+6zNrdDT3n19620Nzv8vPm6+2kt9CW vdf29/jnP2akDEvjEED74OZdda+ar8suTJpchbdDWqE5XaKzxtfK1N/qfpdOda/W5Oq+RnBjHGji 5fGZv9hEYqbf6/J+k77Pma/IrL2sw9a8x9pHbqvGgJ3L3OPj5u0/ZadRaqnP4OrYGEeSr83O3ua9 N2W7xdXv4+fZ3+qywNXJ3OXK3uupvdKerczH3OnP2uPx8/Onx9r98PPR1+elsNP97/Knyd3j7O9g V5jhADN/sc4OK4n///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADNuXPEAAAAgHRSTlP///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////ADgFS2cAAAABYktHRH9Iv3HlAAAADGNtUFBKQ21w MDcxMgAAAANIAHO8AAATTUlEQVRoQ72a7UPa2BLGAwhUIGoQw4nIi0CJiCAqLlILIr01hkQqXbXc rawrvrRXXW1x18oawr9+5yQBEsS294N3sEID8sszM2fOnJMQHdW2JrQXz/hEaN9Nrmw9I0X96i6r 8/od+dywHqvzblZ+ZliftfXm2/+NJb+bfGYv9nV1Jt6uPK8wHUsef/u8uahjdb49PK8X9azOu4eV 58xFA2tr+Vm9aGDJ8w9v/nq+/DCwOlunD/PP50UjCyL28HxFeID1bfk7XiRJb8r8xx5YKuWVS/+z swdY8srDw/gwL25s+G9MDMtyLMs28G+avvNf/G+4AVYHhD0MFGGSvFisRQWWNrmLh5/9la+Vw8+X Y26abgjRmv9v8qcr2yCrM/vwsKwvH6kLN8uzpsvVjZi52TSbzbFYLIV/WvFMhW4LAmO6mP45fY9Y 39486MrH3iLLu+jKdKkA3w+2MQeWTsfBkjZbPM6xh4FGlDss/AztEUsGYVril/ZMUarNrjabKkil AU6BJdOtmNkmmAr2V+Bh08aPXfmI1SFB2Fuc+KumKMMgd6m0ttZcazab8NRsFgqpFKa1YjH/WMAU qLletWxJ+3ZDcO/9SNtjVmdiHUL2LeVGTOVSGLuo3JhqNAcGqVdzj/m/ZszTzaY9EEVwKgxLUQ36 MryQKTaQe/r7dWAISx4HL07W2Urss4tihSjL1IBRLCpMyL0GWysWBXYsA/KS8TAg0YHJlwxuCw3/ dx05hNXZeguwmY+04Gq4Lyt/kDI8SiQYvGjGK5/dtNBu05f2uVTLZktvC/YRk4BMwaqPRrXvOXIY q4mFPfxjooU5sjQNIQKDUDUL+GVzulQqCKZDOipwN9nUnC3TqLVswW10cF0NfxSEytPShrDImutf wFreqrtLqZRZ4awphlOjYE5NXwsbqWbs0NRAXNFmLqJKJgyiqNrRyVGNX3yyeD1mxbg29R4L+xSt NlUUYKbBtEQ0kzTdhNQ3N+OfaSQEvrI1WzhcbV2LTC54MoZM3icS8hHrQmgzI3OQ9w8P70mzgppW SAoNKzPLnLuJR3U6PRez30QFAYVbwcvtANdGbKOB2o3Y8HwcZFV46hrqzyzk/cP6SglQWFNJNQ1G 0rVmLKYM6XSsNHeD2tGGoOQrTwXOAtusMLyMDLAqVGM1NRdvmZX0WJ8omXWoLox0s9NKuYqZ0zsB rnGA2i7Oag+en1gFGp6snDDUjUbW3zwdb8Xj6XT6Nc77h+XXpKoKZzxJKrC1wtoqCptTBfPcJS0g 1nT9NSzQDRQ4CWfPd6jAVc56VR6qzMC64GuxeBJYc3Pmecx6eJMq9VEarFkosbScOqQPBGYsnEyl bXM0V3XzjUt79iSArDlrLscKsccJomfFBCYdtymsVkpNj4dxHCdVVVdYs0BWkIlFTDFthsphy2Qy frSTHGGomi84ItTOrdZ8nmMfTzQ6FtlAGZtNZc1teCcULz68K2k1Q1ZYpek1krTXXG33RbM5B/Xe Biy7jaVt9uo2Ej5WA0IuByyHYHo0qPssmXYdxgGWhHDNzbUW1PSA+UVRJIOpMPmCRtwiy6ylMApY ALONIV84WM0xVOCVcA2sqXyEWhzM/D7rsE2n4a80Viw1XcTVA2xFxyIVkp8kM4hJpXqszFdhrBrM Hp0EeE7Y9gFrKh/gVwdC1mNdUFQFn2HXh6nCVxceZJD5s1iRIksumBBXKZFQpyoCm0wpusCH9hbD 2YPZbNa+c9A+u8Isx0sGDWR+l0UyLiZt77NiMfNG470astMJzMG4RdTwyyXoOlKpQpJDh+Y56AQw K1kUssDy+YI7Lqroy+enHPcOsWYU1mUVBTRm67I+mBegiSEDS5OqF98qMPkPDhVJcq0J5TeVihVS NZ62m+MKyx4WimGFtS0w1JlPYZ25/jbANFYBmQ4qdo3Ver0yMfH6P//5/M9v0MGpykDUHaI3ZGgI cKnHDchG87CBTJmYDbNsHFMFHwZziD6p8bXclOP29n40aqj5KkuucdsN+AvsQ1synVleP10GWz9V nYiVLXDos0xOw/SvsTbmYHiNRVHtVSYdr9rcB9Vz+8m10Mj5sgFXzQosgkB3emEqa4+3BpgwZgEs Hl9Qi4beTv+hU7JWfBUXQu2F4ptKjrGoUbvZqbzir19tcxST8+WsvgAVygPqPmQoHwpLZpgWzYAu RRiMZZvmOz1tBftPmy2xCwGFm8S52Cs3J0QRcvHQlxaPRnJWsAAVmCLADtw6YQprj99pMTR2u5aI C9DWP7J3pZIyL2vRUrpEnIbJtO2r9fMrhrXmzoMjUDWgbFhrroCDiBAepGtAMEuG0mlj6Co4UYN9 sKnV0GjjBZjPMApkQbTUkQxut2fsYTsELHvk82msfH6Ut9xGIvvHd/3qgVl76PKoWuPgD/rClMly 0CZfw0ytoXqylIwPB+0f0U6PBUN5ahftE5FISOiXRWDJd2wwWzVx4bACU8pvckGrhkbc8gR0O0q+ K9FSXKixTl6h6yNVFpQNh8NBoDoR2XeixV7EgGWOnoWzdndDY2FYPN56PSQ9oF7Nm70L2vxvQAWP 7I1AELNwlQfW7b2TGiU298uMnrWKRmAQ7iCrAlPSHuaVIXmvaJx8bVaWDwZV4WDwqMowwRE1XOBC GF33NUqKOCXUK8Ggq0bbfb5sUNgGtysRU4t9SytQg0FbXllYUBcqfQ+Gg0dZe41VdGFZwIKEv99F m04n33Mi0SGj2xDT7AkUGZ0Xk/EPE6dD0kOVpqnqBgujsuHAAQwuTRZmRSJOfglYXLfcEx2/kLNB p+L9elhqNr2w+vHGMzEvnvknVobb/ARZSiWTZq0/9RaaXrP5JHuNlNGVty20Wq0Pio2MVQnRldIi RnSKnG8Bz7p927A3jQeG/G/aZisZDld9r9AO1Cdr3ms47jhud6s9IXOBXEx247W9+vDLaXtBf6D7 Rv+ZdctrmFXD+wL4wVbk6ogPEZg1VSJ7xxsX8n3d1Z3GiL1ocWRBZts9u5HT4YL+QP+t3qsGsDLT MuodWMQs4SyLW40SyfeO++WAKHJdH642pqwLMjPI0h0YympmgAXLMM3u5ExuJOrO4oQvkf3jh3LD VUZa6SD8B1ZrTC/j7id0sXIzYzfqso/4DtzQ1eQdJbKv1y9zLkn0q8IIE+Oztoy64sGCzA1R0z8k qCy9LjvWpbH0umiXVL/RWHTIl28ZdcWPzPINyzIcPBim7/w2YpQjHHMjF+yDunK5aAA3NfdGXY12 uUxrrEYgByxDvDALlsb4B/6Z+nJMSkeqHFdYBl1WYOWgZNzq4+WX6bpYNmms6Jl1akCXLTjnv0vB Og+aqZJM61lrhQv3TYw0F9LhsDFeJxrLces1xIvw8EusmhwEKuaBZdBlOzpCtC2Ii2M4Jtf0rLj9 6w2s+e02qJ1rBl0nVivowpXQmIeEJB43lCp1QSBi6pEuu0kIw5fhUhwz6orb7emwG2gjNvuaYXyd 5IFlhbaQMMaLkJb4qNIILGKWI27UlRxBbnsQs8LhlFHXB9wAVe3uA8R8NMbrPG89CFhh3iK8hvFF SCFXQ9loXAWWA1i6unEnm2uCLwgGqOCArtnqCT4DWxhaNb9B13k+j7bxvBUx6opIkktQNzUJFHHc Jo26sihgzx4pNGAZ4vVm/E+ABYPn1fCrpCFe51NTfHHqFljTRl0eC8VrLOrMcTugixFGYD7KHh0d BY82jPF68zBZOQnCO/ABrzFeuSJyQGo8jldCRBrLVZsiBnRFUS7oAxjgsq0BXbCE/nyCzyTr8xp0 XQdo/uws4Kmxe7rjhzLhSdS7rHYZswzxgkW3FaZqBZce1AWbA7/9iVckvoJBFy1SlADbKmJ9zzi+ JGCpDSlBHd9GBnRd5gQBlGGY77EuWEj8+88rhaWvG1dT3G7EWdwnoEbp6yHoWoqqXQAhuJyDuqq+ EVCGYT7fEF3QcYz7rnwjxnh9yUdHIVhExDlQN6REr24w7RBRNeah3eqDDYpr6K4wy5iHWrsz+fkL zOZR3fyVJVDgFprPfWAZdElS3aT22QTtqkeqxnhBafNdcfxYeMQ3YtRFwjUQ1ZZ/+6KfYWl54Uxt 4J338oWrdw4XpFNK7Hbr/B3ipQFdUNqsI1c0FYCeOW7Ulfm9C1v//YNuCnDtyZfHm5H9Tee9Vw70 UFSsZIHc6M5fF+Jx/YNRF5QbsCs3RY/4ksY8tPt+7y0qxmV/vyxzJdl8Ag12UpYP+0dZ+YMkSUJ3 Xl6NhqiXxnidTykw3zU62Fkw6jrJffmtCzvd0iV3WzhUW7U9U9+Dbbf8UpI8vLZdRHgbHsFt1HU0 lYfVWt7qy3P8olHXOWxsdRfsD+9kt75TEGj3jYmldIcQSVokS7nR7aPk2q5nbKAeQq3BuHwuVwsY dcG+lvXLtbaEWd76QWu3KH+RpISopQbcD7B44PzTqCt768A0RV3GqOsIn4J1R1tWjMt7ehmD7ZBJ NkNmePp9L6wqPQN56AOWSpuashl1XWHWVN4xo6bjirzXeKrhcrllEiaUxDHVXTLDmogtV2XdX9zI OQKmBowDqxp1ZTEfziOvpuM6bA7c6BotHZdZlUsEoEbbTHdDBVh36AT281yUZnfAIjDtXmWZeu/A mfq0U3Dc/1tdMY1/k0uHDK/LPeC54EKOLNs2Id8lvr2opQa+f2OBf2lciOQiKgzE3VYH3oJtJsc9 nAdxf/OLAjud34KPXNzBBcYoWIOj3X5o+eQPDkwCD/Z3HYBV4gLeBfP5qhfveF3smc0vIxiG7Zb4 AusxWF/BT9K/2iRzyingRSNxf61cMYCyPzk/MbBqsr2ESCkoVKd7mw54z6GCpIRzlPJsOjedYojY 34+AaTRVH5ZIjPJiLTIFpVwx+MTHme6wXn/7Znz+T7y6q37JOfYTCkhKSMe8B2lFA9de+OcVyomE pc5LTmdCDEU2Nzf3VV4PqGh0RGieXzq7vYdyrpmmTNX3ywuoEfDomiXEI6l80N9qU/aIrvmElEiI fAKz9p1OHc3Au494DqiDkIW4J+Bctl986hZi9Xn9k6kHkizSrqsuJfgx475Np4RGASaJoiWBMAvD NvdBXUSV1zOI0lkZ8cehxL57ZsjSff19QPVeQlqi+JAlUdZt26j3Ecl3vOJeXpTEkNNiAZrKw84c sMh9ROLQr7/0yr1R2+lMAKIVqlP8KHxhAuppN+O79yyREDGAeRBCmAU0Ha/PVNhO98ywjbEe8nSG E6njENZmKYv6TXptX3SRgrPAbmyHnJAnqinyDLbpfvH+KUV9feu/1ixqKvKHfVW9e7Fktm5R3UiB l3u0QdzmTHdT1ui5gf+dvsBfBhMyN2S/FxYsVAifCoxzahROCuO68hSPKg9Av3hqM0cn6z0OGS6F vPFKaXfPXA7g9IDJplymdrE/MU4nUHOrxXlmGFOP5a2/fwGRUn3kNl7l6F13KDWwFy31ujNEiQoM f1wFqkzlGY70qsUQP66/N2lFA1zUGLh607+eskeVYcLePYZ0FPlRxeF9UzmamdSq+9hOZ170PmQp 8919KF2d117KfggZZCmWs4SHvJGmB0vDpP3yHmpUzywhypCDSi/aT0rZzXughnkAYvHwIO1pmjRQ ntY/zbwwnFzCwwceXYzVX9cr0SCKV/NR2qXqngFHGqUZEvLF4IlR/amkp8ZwvdLLHFvEJS0vQiK1 9D1HBgwJOWOIroSYIZfqDSzYZhaXRE1NIjFKoTLU66fM8o++Jn5Sq66avmKvxxhSN7qHvCxP9WYg XKxhBngibJYlalRf60+7OQgDi/6J68sducC0l5z9bPLsUmIZl9FBSySWXKFEwqTLyHXVjwkPNVSV IQ9VbSUaKmLfHRbPEkzGnsHQJxK7FMx5YKb3fU/+AgMZMrn2xJ0OxngpsDsXtAR9HeBJBHOEbiwr nQTVzdKEqZ8kpzPSLu9+6g6Ox6wOXKk+NqS7RQodU/xuSIIypZwDHn54GHZzQaftX/88GsLDc757 9IIZSImExVM+5tHuKOAgeqMDZSUhBbTLqNAvvnvyRtAhurAfx0CaMSMsgBN5Stz1eOpU2YklauVc KcxS7ZN2OfpheeIJ2nAWzGc0vzswthKQMqElse1qo6XRUQ8eGlD8oU/zhMp1UaRcv77RZtLJiaF3 TD7F6pB+Fk9kxmxPWELHfLm8K0JjwoOJogi/ES/Wd0WeuyJnx1Xa8lBHPsnqyF64pLvkwWq6OZDw HOMqidV4QE1odGmpHAqBwtCuyC6W5A5JTrxbVsYAtPn6kqG8fpqFG+JDThCh98Lq4BdkYz+K2jyK QzUqioy/Vym2ZieVsrw8O0j7Lgtof8Mm6O4oxMYDo6wOo0w38CAnJM9onY+a9vSjl/y2pYh7+2aW NMwrP2CBOLJiih6IfBuiB92NrieQQuVj8SBquhhyCwqIw03k5Kz+fvIfswBnXi3SrMiLx7vl8mgI 4lRe2j2GjGDdNxdP3VS2tTWv3Bc3a7g2+iiGww7AzSmHcMcozTSi0QOWZkx3hxfekvy9e+VIcmse RkF/APyUrp86m6Ef2oK8fDs+oXrymVmdzl9/zY4vj8/+BVny7CwsCDJlHrLk/8ICdVuzs3/9F7xx FXSkR4mtAAAAAElFTkSuQmCCUEsDBBQABgAIAAAAIQAw3UMpAgYAAKQbAAAVAAAAd29yZC90aGVt ZS90aGVtZTEueG1s7FlLbxNHHL9X6ncY7R38iB2SCAfFjg0tBKLEUHEc7453B8/urGbGCb5VcKxU qSqteihSbz1UbZFA6oV+mrRULZX4Cv3P7Hq9Y4/BkFSgFh+88/j934+dsS9euhszdESEpDxpebXz VQ+RxOcBTcKWd7PfO7fhIalwEmDGE9LyJkR6l7Y//OAi3lIRiQkC+kRu4ZYXKZVuVSrSh2Usz/OU JLA35CLGCqYirAQCHwPfmFXq1ep6JcY08VCCY2B7YzikPkF9zdLbnjLvMvhKlNQLPhOHmjWxKAw2 GNX0Q05khwl0hFnLAzkBP+6Tu8pDDEsFGy2vaj5eZftipSBiagltia5nPjldThCM6oZOhIOCsNZr bF7YLfgbAFOLuG632+nWCn4GgH0fLM10KWMbvY1ae8qzBMqGi7w71Wa1YeNL/NcW8Jvtdru5aeEN KBs2FvAb1fXGTt3CG1A2bC7q397pdNYtvAFlw/UFfO/C5nrDxhtQxGgyWkDreBaRKSBDzq444RsA 35gmwAxVKWVXRp+oZbkW4ztc9ABggosVTZCapGSIfcB1cDwQFGsBeIvg0k625MuFJS0LSV/QVLW8 j1MMFTGDvHj644unj9HJvScn9345uX//5N7PDqorOAnLVM+//+Lvh5+ivx5/9/zBV268LON//+mz 33790g1UZeCzrx/98eTRs28+//OHBw74jsCDMrxPYyLRdXKMDngMhjkEkIF4PYp+hGmZYicJJU6w pnGguyqy0NcnmOXRsXBtYnvwloAW4AJeHt+xFD6MxFhRB/BqFFvAPc5ZmwunTVe1rLIXxknoFi7G ZdwBxkcu2Z25+HbHKeTyNC1taEQsNfcZhByHJCEK6T0+IsRBdptSy6971Bdc8qFCtylqY+p0SZ8O rGyaEV2hMcRl4lIQ4m35Zu8WanPmYr9LjmwkVAVmLpaEWW68jMcKx06NcczKyGtYRS4lDyfCtxwu FUQ6JIyjbkCkdNHcEBNL3asYepEz7HtsEttIoejIhbyGOS8jd/moE+E4depMk6iM/UiOIEUx2ufK qQS3K0TPIQ44WRruW5RY4X51bd+koaXSLEH0zli4SoJwux4nbIiJYV6Z69UxTV7WuBmFzp1JOLvG Da3y2bcP3Z31nWzZO/D2ctXMfKNehptvzx0uAvrud+ddPE72CRSEA/q+Ob9vzv/55rysns++Jc+6 sDmCTw/ahk289NQ9pIwdqgkj16Tp3xLMC3qwaCaGqDjkpxEMc3EWLhTYjJHg6hOqosMIpyCmZiSE MmcdSpRyCVcLs+zkrTfg/aGyteb0UglorPZ4kC2vlS+bBRszC82FdipoTTNYVdjahdMJq2XAFaXV jGqL0gqTndLMI/cm1A3C+qeE2no9Ew2JghkJtN8zBtOwnHmIZIQDksdI271oSM34bQW36Yvj6tI2 NdtTSFslSGVxjSXiptE7TZSmDGZR0nU7V44ssWfoGLRq1pse8nHa8oZw3IJhnAI/qVsVZmHS8nyV m/LKYp432J2WtepSgy0RqZBqF8soozJbORFLZvrXmw3th7MxwNGNVtNibaP2FrUwj3JoyXBIfLVk ZTbN9/hYEXEYBcdowMbiAIPeOlXBnoBKeFWYXNMTARVqdmBmV35eBfO/+eTVgVka4bwn6RKdWpjB zbjQwcxK6hWzOd3f0BRT8mdkSjmN/2em6MyFA+5aoIc+HAMERjpHWx4XKuLQhdKI+j0BBwcjC/RC UBZaJcT0L9haV3I061sZD1NQcGJRBzREgkKnU5EgZF/ldr6CWS3vinll5IzyPlOoK9PsOSBHhPV1 9a5r+z0UTbtJ7giDmw+aPc+dMQh1ob6rJ58sbV73eDATlNGvKqzU9Euvgs3TqfCar9qsYy2IqzdX ftWmcE1B+gsaNxU+m51v+/wAoo/Y9ESJIBHPZQcPpEsxGw1A52wxk6ZZZRL+rWPULASF3Dlnl4vj DJ1dHJfmnP1ycW/u7Hxk+bqcRw5XVxZLtFK6yJjZwj9ZfHAHZO/C/WjMlDT2kbtwKe1M/4MAPplE Q7r9DwAAAP//AwBQSwMEFAAGAAgAAAAhAN+z7r9ZBwAADhcAABEAAAB3b3JkL3NldHRpbmdzLnht bMRYW2/juhF+L9D/EPj5OBYvoiRjvQe6nk27Nxyf7QJ9oyUmFqIbKNlZb9H/3iElxYkzadO+FAgc cT7OlTMjDd/9+qOuro5K92XbbBbk2llcqSZvi7K52yy+/ZEt/cVVP8imkFXbqM3ipPrFr+///Kd3 D+teDQNs669ARNOv63yz2A9Dt16t+nyvatlft51qALxtdS0HWOq7VS31/aFb5m3dyaHclVU5nFbU ccRiEtNuFgfdrCcRy7rMddu3t4NhWbe3t2Wupn8zh36L3pElafNDrZrBalxpVYENbdPvy66fpdX/ qzQA97OQ479z4lhX874H4rzB3YdWF48cbzHPMHS6zVXfwwHV1Wxg2ZwV8xeCHnVfg+7JRSsK2Ilj n55a7v53AuiFgL56iycj9LHcaanHPJncqPP1zV3TarmrICvBnSuwaPEe0vJn29ZXD+ujBAU71Q9Z OSxg3Smdw1ltFpS6i5XZ2OmyGTItc5MDsor30jwr/b0shr3doeqdKranflB11jZDb4lm/1F916VJ /u1wqhRIl133WdZgyaftd3taD+tKmhIq1DJJzfKomqLVN8lmEZhlUVV/m6vOJdSQwNX83grcLJzR xN6svspGZTYmWVmBfbNzLHOI4ZNVZbl6qF8r59APbT2TnNGWAXx/RrKi+5vmW2/VAWWvpCn7Z7ua A4RAX1IHE/VnlKLUKh9GK01cvjS/H5rZoJfgVwj1nZbd/vUtn2fNr+74w1jx6HSlpD6jE3VoO/bh uVuWfiz78tIFaWLbQKAs1ZymRew5FOpWHqoBNG5B5HwArvBGeH/q9qqxveTv0CVnnM+ZVrSf2+HD tEnFshszqSj7rpKnD60uf0J6ySrR8gFM/U2XRQo9+TQLmq0Y90PeDGX+n3cbpXC6n6S+K5seYvOE 4YsugXjet93LwiZZIgdpyU379dDkw8F69VeIDHBaIJ/rZNvJHIgxmK7batZuxcXQ3jV0nyk8hQb5 nUrGKPbv37Xr3hCmsPZXx7X6AaWpClOrfVcWtfyxWfgkYFDSx/UA6K79cQVuKNjmXvtuN/xy7cHP k2ejbHUhGSiY/of1bdsOTTuor/rpCpwoi81iSUbDL8g2sKtLXqjrF4sLOc+ps5hnjOML0TwdepWl H+WpPQxjvC2yHV+2piRtn3n2Av3UFsqk8EGXb2/Ktg7MiUH3GQ062wCNqbBhMg+/g7uPueUIjzI6 5b1Bz4hDCKWTxxeIyyJmtbxAfBaQEEdc6uB6AsJS9goSUVxa6DHPR5GEBz6uJ2UhwfVkLudTbb9A RBpgCHHcLEP1EOrFIkIRl7IMjRvxuBC4Hk94DEd8GkWoP8QXwsGRjPkZeqaUOEESowjlHLeaBp7v 4NIiYt5mGBI7fohLi1kSpiiS8tBBEUhdODsUcVnioGfKfC+KcCRwPbwWIHPiGPWHpS7H/eGcCx/l 4RlJA5THdVw3RS1wicMSNONdThIHjYEbOamboUjsiAzNEEGcNEbzQFDmhQJH3GB+N14iHmM4wh2R ov4ITgMf1/NqrxIxowL1VCQ0wKvRozQOEhRh3MNP2xNUeKg/XsCTCI2bF7lhhluQiCxErfYySlI0 Bj5lIUN5fEaCGOfhroimz4gLxOOxh2ainxDHR/uOnzAnRPPNTyE+KBIQz3VRPQHlgqC1HVBB8Y4U CEpc9OQCIRhBzycQXuqjpxBELOI4EhOR4dJiRl6xLRFMoLEOMsESVFrocOqj/oSUhB76BgyZJ2JU T8jh/YxLC2mY4tIiAu0SR3iYoGcaxsxJUT2RI4SHSosY9yNUWmTKHueJWIrXXBTxgODSIi9gaFbF xGV4740pEz5aWbFgLEZrIYb2hn9TxL5I5nniAomgkeM8seviPT7OoMWh+ZZwJ8B7SJJQX6AxSBLo lmjGpxz+UNtSwTP8Ky0NuE9QTzPCSIaeT8Zpin8nZuYFiMYg8+DwcGmxJwjar7PU9Vwbg9UIwVdw vTZXO+YzfXwyVwFX9cgRy3qnS3n1yVz+rMyOnb6PymbGd+q21eopsj3sZnC5HIG+hhHeXETMgE3r 2s57MLPY52oc4y52aJQKw89fHmWZSw+lf9PtoRvRB5i7b5pCnZ0gnE+cZTN8LOuZ3h9225mrkfr0 BDo0xZejtnE6hwfmbZg5lInPR2lnFbtXNctvWzNtKNkPYV/KzeLnfhl/NqRdWcDIIvVyOx1uXumt mVxgbO26ceDZ3ZHNoirv9sM408OqkPreLnZ3dMLsFcpAR8wuZG58h93Tw5lGZ9qTfWymsTONzzR+ prkzzT3TxEwT9h7l1Cldlc09zGLzo6HftlXVPqjiwxl/QRqDYGfomyavDoWCfCnavL9ptoOcbqDs hPt/GaYnQmWn02eKDGY0dc/VF3KQ5s7libSR2RbYhSPmniUvoRi2p3p3vlG4HoNSlT1MwZ3Ucmgf 78B+sRhxIWT5TWHuAEf6P1Ke8Dh0/WWU+t6Si5AvQ5o6yyhhLPJTeBOQ9J9Tnc8X2e//BQAA//8D AFBLAwQUAAYACAAAACEAJO+2RBMBAAD/AQAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1slNFfSwMx DADwd8HvcPR9622oyLHbQGQi+A90vve63FZsmtJ0nvPTG885EV/mW9M0P5JmMntDX7xCYkehVqNh qQoIlpYurGq1eJoPzlXB2YSl8RSgVltgNZseH026qoPmEXKWl1yIErhCW6t1zrHSmu0a0PCQIgRJ tpTQZAnTSqNJL5s4sITRZNc47/JWj8vyTO2YdIhCbessXJLdIITc1+sEXkQKvHaRv7XuEK2jtIyJ LDDLPOi/PDQu7JnRyR8InU3E1OahDLPrqKekfFT2J/Q/wOn/gPEeQFtdrwIl03hZgXRSCKamsgOK 2aF7hzmli0QdQ9Kf1/IR2/vwfHvTR8Z76h7uriTQv9Y2/QAAAP//AwBQSwMEFAAGAAgAAAAhALEs eVGXAQAAiwQAABMAoAFkb2NQcm9wcy9jdXN0b20ueG1sIKKcASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8lM9uEzEQ xu9IvMPI527X3rBpN8qmopv0BC20hStydycbC/+T7d2wQki8A2/Ik+AoJcoeuIDCxRp7rO/7zWjs +dUXJaFH54XRJWHnlADq2jRCtyX58HiTXBLwgeuGS6OxJAN6crV4+WL+zhmLLgj0ECW0L8kmBDtL U19vUHF/HtM6ZtbGKR7i1rWpWa9FjUtTdwp1SDNKp2nd+WBUYg9yZK8368PfSjam3tH5j4+DjbiL +bP4AGsVRFOSr8u8Wi5zmifZqqgSRtl1UkyKi4ReUppdZ9VN8Xr1jYDdXZ4Q0FzF0j/d4vYee4Hb aqglRt0+zKTd+uAW8/Q4/u33j86x9Xvn2DHdqZFhdfcW2BR+fv8Bbx4g30erk2AURxgND/+hcBan 8FC5cZLrdlT8SrdS+A0YLQe4c6IVmssZPB+fpAmMHSE9yQ6t0J9HUJOUTc8gj+tpALIjgAZ9GJk/ oOnkGUwggQu4NT2qJ3SQUfbqNDCHRxFHk3dhY9wI555ba1zAzsH7XV/+BJHu3un+F1n8AgAA//8D AFBLAwQUAAYACAAAACEAuAyDQnIRAACYqQAADwAAAHdvcmQvc3R5bGVzLnhtbOxdW1PjOBZ+36r9 Dy4etnYfuskNAr3DTNGhmaYWaKZDbz9OObZCPNhWxnagmV+/kiw7co5l+1iCZqv6CWL5fDm3T9KR 5PinX75FofNAkjSg8cne8O1gzyGxR/0gvjvZ+3J7/uZoz0kzN/bdkMbkZO+JpHu//Pz3v/30+C7N nkKSOgwgTt9F3sneKsvW7/b3U29FIjd9S9ckZo1LmkRuxj4md/uRm9xv1m88Gq3dLFgEYZA97Y8G g8M9CZN0QaHLZeCRM+ptIhJnQn4/ISFDpHG6CtZpgfbYBe2RJv46oR5JU2Z0FOZ4kRvEJcxwAoCi wEtoSpfZW2aM1EhAMfHhQPwXhVuAAxzAqASIvHcXdzFN3EXIvM80cRjY3s/M/T71zsjS3YRZyj8m N4n8KD+JP+c0zlLn8Z2bekFwsncbRCxi1+TR+Uwjlxn4+I64aXaaBu7J3tXcuQpib0X55dVpnNYL eCm8vM+/LHTjO9b+4IYneyR+82VehS8vLQKfIbvJm/kpF9yX2uZ/FRvW5af8rh2DWbxZ9Od5ErJW sryk3j3x5xlrONkb8K9iF79c3CQBTViiba/NSRR8DHyfxMp98SrwydcVib+kxN9e/+1c5Iq84NFN zP4fT4ciBmHqf/jmkTXPPNYauxH75msuEPK7/yxkh9JDdbeviMvZ5gzREiO0xBgtMUFLHKAlDtES Uy6RKlEUztvshBDv0aNnwj22jBvEPvmWZ0wH1DYckUcWcER2WcAROWcBR2SiBRyRnxZwumZtG07X LG3D6ZqVepyMehaykKOY5yBHMc9AjmKefxzFPPs4innucRTzzOMo5nnHUcyzLh9gnQuWxHFmjLak NItpRpyMfDNHc2OGJWaidvD4CEISK0ZagMn7DTmqGaN5rvjcEcfpODZmfKrs0KWzDO42CStXTNUk 8QMJWeHguL7P8CwCJiTbJF3t75DBCVmShJVvxGYa2wMNg5g48SZaWMjEtXtnDYvEvmX3FYhWuoAy od1NtuKVTGAhqSOXlZ/mqlHXWm9wGaTmvuIgzvtNGBJLWObzEgFjPjFRLLOllESzq5v55ElFM59E CbRr0VHY8ptEs+Q3iWbJbxLN3G+3QRaKjrDToDsLKV89M/7WeXAXu2xQNO+C5VKRc+Mm7l3irlcO Xwszhn1P/Sfn1ka3XiLZmsiK+M+YkUG8MfdfBc0Wc0o8S9wp8Syxp8Qz588VmynyOcpHOxP4+WaR oRi5Ta/zIEmLJLMQyGs+seFW2eD7VktzxbZY5tm1S06r6klIC1qG1Lu30xt9fFqThE3Q742RzmkY 0kfi20OcZwnNc61T5n+I1is3DcQcuZNAsZPkXLlrY2VvQjeI7cTkw5vIDULH3pj48fbq0rmla15M cMfYAXxPs4xG1jDl6s4/v5LFv+woeMpKnfjJkrWnlhYBBNgsyCxFdUZ9S0hs4hTEAb9uB+8/5GlB 3cS3g3bDinRB6YxYQpy70TofVy1wi/V5j6xCtzDgC7z/uknAq39bpLq1AqYsDqWbxR/EM+/qrqlj pf7/tMnEKpOYzQlpe3DmU4AKnPnwL6LJhgeevxaMrcCZG1uBs2XsLHTTNLCx6VTFs2VugWfbXvP6 RuLRkCbLTWjPgQWgNQ8WgNZcSMNNFKc2LRZ4Fg0WeLbttZgyAs/CkpLA+zUJfGvBEGC2IiHAbIVB gNmKgQCzGgDzfWUFzHx7WQEz32XOwSxNARQwW3lmdfgXYLbyTIDZyjMBZivPBJitPBNgtvJsfOaQ 5ZJNgu0NMQqkrZxTIO0NNHFGojVN3OTJEuSHkNy5FpbCc7SbhC75qV4a58cxLUDyZdjQ4mQ7h7MV 5K9kYU01jmVTLwurnW4YUmppbS1X7HZFIvN6+CZ0PbKioU+SBuWC7Tnk4+MGNFYKz9euJ1fXVTGB 02lF8zK4W2XOfFUu0qswh4NWyaIWr4i1fyEfv4HYqEHsivjBJioUzXO3IjzuLiyStSI8aRfeThIq kgcdJeF3HrZLbifAFclpR0n4nUcdJQUFK5JNeXjmJve1iTBtyp+yfNMk37Qpi0rh2q9tSqRSsi4F p01ZVKGKc+p5fCMARqcbZ/Ty3cijl8ewSI+CoZMepTOv9BBNBPtMHgI+aJt1o0KDcvN/V3QsZsyd +tLfNjRfpFflR+IUayf5CzZLilPi1OKMxVMlnXAq/Y7es507ID1E555ID9G5S9JDdOqbtOKoTkqP 0rm30kN07rb0EOj+C44RuP4LyuP6Lyjfp/+CKH36L4N5gR6i8wRBD4EmKoRAE9Vg7qCHQBEViPci KkRBExVCoIkKIdBEhVMyHFGhPI6oUL4PUSFKH6JCFDRRIQSaqBACTVQIgSYqhEATtedsXyvei6gQ BU1UCIEmKoRAE1XMFw2ICuVxRIXyfYgKUfoQFaKgiQoh0ESFEGiiQgg0USEEmqgQAkVUIN6LqBAF TVQIgSYqhEATVexeGBAVyuOICuX7EBWi9CEqREETFUKgiQoh0ESFEGiiQgg0USEEiqhAvBdRIQqa qBACTVQIgSaq2Bk0ICqUxxEVyvchKkTpQ1SIgiYqhEATFUKgiQoh0ESFEGiiQggUUYF4L6JCFDRR IQSaqBCiKT/lfqR6gl6VHeJXPXVQo+6bWVKpz+rTuSrUuDtUoZUeS9T0HR+wofdO+ZRcBUTUG91A gkUYULFErdlDV3HF+QfULuenWfOjOiq6CC5E72qKfPBB7KsC8ElXSbCmMmlKeVUSFHmTpkxXJcGs c9LU+6qSYBicNHW6gpfFCRQ2HAHhpm5GER5qxJt6a0Ucuripj1YEoYebemZFEDq4qT9WBA8c3jnv Sh909NNheZgUIDSlo4Iw1SM0pSWMVdEdQ2J0DZoeoWv09Ahdw6hHQMVTC4MPrB4KHWE9VL9QQ5ph Q92fqHoEbKghQq9QA5j+oYZQvUMNofqFGnaM2FBDBGyo+3fOeoReoQYw/UMNoXqHGkL1CzUcyrCh hgjYUEMEbKgNB2QtTP9QQ6jeoYZQ/UINJ3fYUEMEbKghAjbUEKFXqAFM/1BDqN6hhlD9Qg2qZHSo IQI21BABG2qI0CvUAKZ/qCFU71BDqKZQi1WUSqhREVbEcZMwRRA3ICuCuM5ZEexRLSnSPaslBaFn tQRjVcQcVy2pQdMjdI2eHqFrGPUIqHhqYfCB1UOhI6yH6hdqXLVUF+r+RNUjYEONq5a0ocZVS42h xlVLjaHGVUv6UOOqpbpQ46qlulD375z1CL1CjauWGkONq5YaQ42rlvShxlVLdaHGVUt1ocZVS3Wh NhyQtTD9Q42rlhpDjauW9KHGVUt1ocZVS3WhxlVLdaHGVUvaUOOqpcZQ46qlxlDjqiV9qHHVUl2o cdVSXahx1VJdqHHVkjbUuGqpMdS4aqkx1Jpqaf+x8toUji3e4sNuzp7WhP+ssvLAjJ//hKbcBBQ3 Xvjl+024MNfEka98kZeFwnLDUPyfpKyqk/cMBoOD8fuxTLt1/pKazF0ITdjf4r6QLEXBtqbpyd70 WG7H6W4YDo+lo7R3HBzJ9NDecXwktu72t/rQB5IsQ/p4s4m9rLQgh3E3GeVPaZKzD9qW690W/49N mn3mTLqIty7JG9P8kU92dcF/4IqFYjiSTfxHpE/D4C4Wv1EnxRZuSvhvCUmdpSvla3/Sv4rbRsVO ZvXdPL++l3LFm3dEcFvSoUwAuaOcvwJHTYHtq2zEl3Id/U88Y0GCxPx3EE0T556Q9TUDEtf4h0vm kFTjznFxvCgQvufBz1OLfVgx7wT8hVdlqtH8l5ouH8JKnICnF+ZuHGndKK3dcWPpfXuOhN4aFXvR 0BHiiwtH9LR5rLVZ7tl/D5uHRYZAm4vO08TmidZmmXP1NkuHWLG5pqf1QuImiK52MCriX4CpfBLN KqGK++ucKiwzdGr+KrQ6p8qDGPVOlVZacSo0TKAbGnaoNUzOtZ7fsNZs2QZXf4scmnX5wsflSr6U AzV0azE+m7h1qnWrnIDWu1X6/JnyRaAbGnakNUz683sYJnxqaNix1jA5Xf8ehgmfthvmrZhlnvw1 UM1sWv5OffmkuviV+l2TNT9mL5TczvKLuyUpt6f98vsqJ/ty/TV6Z7yqaNBZVB2NZUBemOgULB7c b9OQ6bMIZWe0CPNJ86N8E2Ouqf/NlT3QIpyRMLxy87vpWn8r73ry1uFA9D477Yv894y18omohbUA vKtTlMk/NudJ/h6bID+kqa26eMFX425xYtjU0x3J6bEChkZzfsOufqcx49o1zX+kfldL0fg70/Uf brT+t5PfVMfeLjWC3bpgciRnfX94BSivoBlnFYpX5vuPan1V9ASYCqDJi+s1if1A70jZ3sWXlYj0 8qgFe+bXsExkF9+2l4jPM5utn5403VK3dLBzi1w7qNxSmTYfFI9B6Jcwxm0z7+mgZZFjNCqelNDe cTRuUXQ8GUgna+84Lh6m0N0xORjL0VfrjuFAljUNDisK7iLMkLr1JfnuO49ndJMEJOFvK+bw8sXG 6tU8E3OG0JuE0uUuy4tvssRywjr8kDxAZpQNxuSA3ir6uQ7rH8gpW7ulcI2jbKiztOqGVlsrFQVn tGrS+LjPLLTdJLiEUTY0mCQVx5kkeyB7JpyLNyPqxpi89UVH66YBmi9FsY/uko3Jyqpo5+HaHm35 m29qJmBZu3N609VezGVdtAAGyIbfF88b4nJCpl14e+boSTsDrQOCV+eAwKoDPhPvmgLr2VVG9Rcy vY3r+jyoDMeWJ93MBfU9IffNa6pVyj2MV1GrzNkUyoNOk5efzWM1XWVlhBgNXsJJlaWdBieJdZBl Qv4EfhItv4umFsMrqnp8p7e4j2822g2q0IqvsGn0FU0vw4bvWN/tVE0tpVlrdXdUbOQblH+TYdsO to0C8aA4EmJQQjKnt9zRXmQeHrWUkEUZ2lggHqn9gtk6T7EeYpNmIbkjsY5osrGNaq95leQHi/6v WSR5k58EAAx5Zm7oitOcHAa1qQDYjmL2J2hbz33PWlWYmZClxoG8BeM1m9UO2kWWvMHPUWncIZra /PGjq/3R1T5TV1tuRqnceJ6Od8uJTzO4AJ1R/m69Nibs7CYil/i+I02w+zbHxe9w1dzAoHweJp8q vJkewVQS+8UK5Lg9D8rjd+o68GE+nRVwOUUdZZ2btyrp0iMb4CI9zwYZyZ1sEMnTKxe6bUwMD/Jf dSrNkz2SgXlwwZ6bV79aL7yBMa+HPvA8INen/iygUP+Z9YFH6bg+9cfohPrPrA88Acf1qT/99hL6 wKNjXJ/6Y2MvoQ888cX1qT/t9Vz6NEy5Luf5b6PtKllcr1NTP9s6OxsdHX6QLWqJvpjxQcXevPly rlnWLBtereK3cHFfXHy1Cp/TpEZjfvXVqnzGBn3x2AXUu2zCKT84nY6nkrXP7+9Tjz9DVO912YZT /3Q2Hnw4eyn1L+JlXZIXLXWqA9N0+ltScUYj/pxOvZZF40soWqol35sn3ky3q1XlnXptkWfZfb8j yOVmK1cytqrxjE3ijtsmf93O8Ny6Kxq5YkKYH9/ZXvDS8pP4pm15NJRzhfSvGYdSrrVnZdftnV03 NPnX2Tpqx8m1Z4CbXN7m7pdxY+/HyireLX35kbUl3GDgxW0LzntVB51PmY/kNEg6qLKZxvriwfl5 3r4pLqYsXfPZSt86mx8vIDAz+BJkvszVmXM5ko5uo9Fkcv5qFqQ6VNpyoa+4ZyIr2KbaWW6AN9bO HcvgrgxXnA7SUjSZ0lrmR0tE4eKPjJzVJzvPKeUe2TV0mV/G5GqO9CNXXzRXFafvhjBvMs1VmR+v Ilf5Yw+lunC6xZ+O3za3pS58cqJY39Y/KTScHk7ztbwyiStna4utDY+/J/tbtnFD+V7fTjHvOuk8 o17++AhwwbYFQ9xSSsfd6eHocCoZIs3ebt7kHFAMrFQF9uZdVS21lpvm+44L9Y7QHRvAJX7xX/rz /wQAAAD//wMAUEsDBBQABgAIAAAAIQCz7QW8sgIAAFMKAAASAAAAd29yZC9mb250VGFibGUueG1s vJXBTtwwEIbvlfoOke8QJ4Rld0VAy0KkHuBQ6AN4vc7GamxHdpaFZ6jUSy89lEdoL73St2m58god O8lSIAsEFTZayRk7f2Y+/TPZ3j0TuXfKtOFKxihYx8hjkqopl7MYfThJ1vrIMyWRU5IryWJ0zgza 3Xn7ZnsxTJUsjQfPSzMUNEZZWRZD3zc0Y4KYdVUwCZup0oKUcKtnviD647xYo0oUpOQTnvPy3A8x 7qFaRj9FRaUpp2xf0blgsnTP+5rloKikyXhhGrXFU9QWSk8LrSgzBmoWeaUnCJdLmSC6JyQ41cqo tFyHYuqMnBQ8HmC3EvmNwGY3gXApIOjw3UwqTSY5wIdMPBBDOzV9bzGURMDGCRfMeEds4b1Xgkh3 oCBSGRbAmVOSxwiHcPXwBt7EEfxDWEXItwdpRrRhVqw6iKtwSgTPz5uodrpuo+AlzZr4KdHcJldt GT6DjbmZ4BgdYIzDUZKgKhLEaAyRrX4U1JHQvsv9BnVkYxnBNkKdjrsNKh3qdJZn4J1+ReIekcNj 75BLminHguTlEYSbpK8vv19f/vSuvn6++nZRF9VKawCsQqDVX0mr30pLqCnTbbhSfsam7axw+C+r 3mi8lewne3dZBeEjrMC+g46sxmquOdPWPyucswX1DxwT65yok3Oew6LVNxuv4ZsTkoHTV2DYA0tE dQtZY3TBYBbcmG4NFACIg7sgenjzninCx0AE3UEcc3E8rybJne758+PT719fVrVNABliYBQ0V3vb 9NoYkXmpOiGq62icAaWF/X7SlH+rb3qPIIrsoY59Q8QEMlthFjtlK6vYqdvNLM+btrcniC0IR8vI Tdc0bB7oms4ThOQcUKwgkbipYS/bPC/eNq0kRuMWEs2X6D+SGEFa+YPjoyLhaLw4h1eco/XC7PwF AAD//wMAUEsDBBQABgAIAAAAIQCilfIHDQIAAMcDAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMk0tu2zAQhvcFeoeB1pYpyq9UsBW0cQ0U iNs0dtqim4AhJw4RiRRI+qFd79Ab9iQlZVtxjSwKCJDI+efD/DOj8eWuLGCDxkqtJhHtJhGg4lpI tZpEd8tZfBGBdUwJVmiFk6hGG13mb9+MeZVxbfDG6AqNk2jBk5TNeDWJnpyrMkIsf8KS2a5XKB98 1KZkzh/NilSMP7MVkjRJhqRExwRzjARgXLXE6IAUvEVWa1M0AMEJFliicpbQLiUvWoemtK8mNJET ZSldXeGr0mOwVe+sbIXb7ba77TVSXz8lP+bXi8ZqLFXoFccoHwueOekKzK8XoBUs/ct3EabhIxQi lS70qh6TVhhSuEHmtMlvWVVp43Bt4GuP0GEjOwZD75+x3mojbB6iHRg0mtP7QBNouZGV87PNr77M gQ7hz6/f4CsY7L8+Asy0yWCBel10oAcxjOCz3mD5gAbShPbvd0mSiPup5uvQbPBzwgwOtwu2QQEP NXxa3g2oH+VFjwJzQJOMjjLaD8ZTSqh/+o2D04KCi4JZN/fL9ihRfKjz92rlh2rja/SJU4Rv0m+m 7sCttqxxd6YPCIMbGZY3HzSK9njE3xipHIo8mIkpjVO6TN5lg1GWJD9b5lE0PqzPvtXemx97tl+S Y+R772q6nEVnvF66553lvwDLQ9X/R/QNTA8VngPypuh/f738LwAAAP//AwBQSwMEFAAGAAgAAAAh ANfhOV3XAwAALBgAABIAAAB3b3JkL251bWJlcmluZy54bWy8WG1vmzAQ/j5p/yFC4mN5CxASLa3a rpk6bdO0dT/AIU5iDdvIOMn672dsCJBSBInbfAF8d4/vnjuOcz7d/MPJaA9ZhiiZG67lGCNIYrpC ZDM3/jwtriJjlHFAViChBM6NZ5gZN9cfP3w6zMgOLyETiiOBQbLZIY3nxpbzdGbbWbyFGGQWRjGj GV1zK6bYpus1iqF9oGxle47ryLuU0RhmmcC5B2QPMqOAwy/RaAqJEK4pw4CLR7axMWB/d+mVQE8B R0uUIP4ssJ2whKFzY8fIrIC4OjqUm8yUQ8WltGB99lUmn2m8w5BwuaPNYCJ8oCTborQK41w0IdyW IPuuIPY4KfUOqetfloPPDBzEpQLs4/5KGeFEed6N6Do9MpJDHC36uNDcs/QEA0Sqjc+ipkauGwwD 8E4B0s1lyfnC6C6t0NBlaI/k7xErf7UHYBVJroeWXebM7y1IxRuI49njhlAGlonwSKRsJFgf5WVt XIuWA5YZZyDmP3Z41Hh6XM0NR6qQDK2EbA+SubFQvzvDziV4l3D0De5h8vScwlJHrib5qtLiOE1K 2cNteH/veA9KkuxzARKXci/RGBkvlV2lJbriAh8XVzBGGBTQwvIJ/jvKzMJCLH+Ny8UErrlaTn8y 6Y+IsriWOmILQ9ynVHDuj71c3a4UEcnjz3GUVDxsAdnIhl5pF+isuCwo4VmuiQjPvV4DQUuhKnVs 6ecpDa4WGixTenUhE8Ek7GAil9aZqLT1MOHpYsIyxxrImHhOBxm5tE5Gpa2HjLFGMizT18BHFEqU V/jIpXU+Km09fKjmpY0Pyww0UOI6TtTBiRTXSanp62El0M6KZcqX+lJi3KCrp0pxg5hKXw8x4VsQ Y5kTHdx4064uK8UNbip9PdxM3ogby5TFfSk9vt/Vd6W4QU+lr4ee6O3oscypDoaCqKsTS3GDoUr/ XIbsxqSY23aOkWqmqY+RfhR67iIoekv7GLl9XjK0+t4xTN6Ftw8Pod86TIpbnibiwOtEztRxnIWe NPbJV9dcMA4b1dlecu6p9+5UroiDrDgN72H/KTGhB8i+Qc4ha4/IGxzRizeuV0iyvzdCurskpF8U A9Ie0bgtIoY229dD8tzwpIlEPUIat9TYeSF11pw/OENeFJ2RIdkk3qfogsEhiQjOCCl4t6ILhxed ODieUXRyFnj7opsMzlDgnNMWJu9XdNHwkCYnbaFXSHLEf5eimw4vutA/aQ2vFN3LDzyRH3ZS/6A3 vvLl/iUcaTFTJ/rBZursO9jsxf9b/czUGWqwmTphtJrJ5JZm6qr+5b/+DwAA//8DAFBLAwQUAAYA CAAAACEAZgtABTgCAABiBAAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACcVF1v0zAUfUfiP1h5Ammtm3YLULme0CbYJMoGTbdn49y0Fo5t2W61 8uu5TtaQMp7IQ3Q/j4/vPQm7fGo02YMPyppFlo8nGQEjbaXMZpGty0+j9xkJUZhKaGtgkR0gZJf8 9St2760DHxUEghAmLLJtjG5OaZBbaEQYY9pgpra+ERFdv6G2rpWEayt3DZhIp5NJQeEpgqmgGrke MOsQ5/v4v6CVlYlfeCgPDvE4K6FxWkTgX1OnHlc2Noz2UVbaKHSpGuCzHOO9x+7FBgKfMtoZ7NH6 KvDzYsZoZ7KrrfBCRhwhnxbnE0YHAfbROa2kiDhdvlTS22DrSO5ayiQBMDosYXiNFcidV/HAEWro si/KJCrIpbOQmxcbL9w28CIR7D22kkLDFU6A10IHYPRPgN2ASNu9FyoR3Mf5HmS0ngT1C/c7zcgP ESDNbZHthVfCxKwr65zW1i5Ez0sVNWL3fmsOy4a2Oud5W4DGaWHrtBzQPmXXnhDuarxb/AfZfEi2 5dBR7eh8F85ZH2HnyRIgIiqxNbkt16OSrD7nBfm2g5DGHkh+RqZnZHZGLghKnUxzmhcvLnak+Bep pTAoDc9bYEaPLruyjRPmwG8NSsG0+xWalKBB2qbZmeedk7VJ7zfY/ha189yUlv0zrF1pr5M+n7d4 Ghwo71HF7coJiaqYTT68G2pwkGIrjEKFoupl0QfYDQ7R63QA9poNVMeal4mk6oful8Hzi/EEn1bG xxhqsf+W+W8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAIWnuVCfAQAAXAgAABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAmVV+Bf4AAADhAgAACwAAAAAA AAAAAAAAAADYAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAId8z93oBAAD3BgAAHAAAAAAA AAAAAAAAAAAHBwAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQBP l5IdsRMAAPFqAAARAAAAAAAAAAAAAAAAAMMJAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAI AAAAIQB/0mJfhgMAADkMAAAQAAAAAAAAAAAAAAAAAKMdAAB3b3JkL2Zvb3RlcjEueG1sUEsBAi0A FAAGAAgAAAAhAN/Z0IS0AQAA3wUAABIAAAAAAAAAAAAAAAAAVyEAAHdvcmQvZm9vdG5vdGVzLnht bFBLAQItABQABgAIAAAAIQCRmLJLtAEAANkFAAARAAAAAAAAAAAAAAAAADsjAAB3b3JkL2VuZG5v dGVzLnhtbFBLAQItABQABgAIAAAAIQDEW6nFjAIAADQLAAAQAAAAAAAAAAAAAAAAAB4lAAB3b3Jk L2hlYWRlcjEueG1sUEsBAi0ACgAAAAAAAAAhANuvootDFwAAQxcAABUAAAAAAAAAAAAAAAAA2CcA AHdvcmQvbWVkaWEvaW1hZ2UxLnBuZ1BLAQItABQABgAIAAAAIQAw3UMpAgYAAKQbAAAVAAAAAAAA AAAAAAAAAE4/AAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEA37Puv1kHAAAO FwAAEQAAAAAAAAAAAAAAAACDRQAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAJO+2 RBMBAAD/AQAAFAAAAAAAAAAAAAAAAAALTQAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYA CAAAACEAsSx5UZcBAACLBAAAEwAAAAAAAAAAAAAAAABQTgAAZG9jUHJvcHMvY3VzdG9tLnhtbFBL AQItABQABgAIAAAAIQC4DINCchEAAJipAAAPAAAAAAAAAAAAAAAAALhRAAB3b3JkL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEAs+0FvLICAABTCgAAEgAAAAAAAAAAAAAAAABXYwAAd29yZC9mb250 VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAKKV8gcNAgAAxwMAABEAAAAAAAAAAAAAAAAAOWYAAGRv Y1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhANfhOV3XAwAALBgAABIAAAAAAAAAAAAAAAAA fWkAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQBmC0AFOAIAAGIEAAAQAAAAAAAA AAAAAAAAAIRtAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAASABIAgAQAAPJwAAAAAA== --_005_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_ Content-Type: application/pdf; name="ls133-16.pdf" Content-Description: ls133-16.pdf Content-Disposition: attachment; filename="ls133-16.pdf"; size=156513; creation-date="Fri, 21 Nov 2014 15:14:07 GMT"; modification-date="Fri, 21 Nov 2014 15:04:06 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDMxIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDIvS2lkc1sgMyAwIFIgMjIg MCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291 cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA4IDAgUi9GMyAxMCAwIFIvRjQgMTYgMCBSL0Y1IDE4 IDAgUj4+L0V4dEdTdGF0ZTw8L0dTNyA3IDAgUj4+L1hPYmplY3Q8PC9JbWFnZTIwIDIwIDAgUj4+ L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9Bbm5vdHNbIDE1IDAg Ul0gL01lZGlhQm94WyAwIDAgNTk1LjMyIDg0Mi4wNF0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwv VHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFy ZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1 ODQ1Pj4NCnN0cmVhbQ0KeJzFPWtz4zaS36dq/gMqH66kPZsmQPCVSuXOsScT380jGSuVuov3g2TJ NnclUStK48v++utuABQhAhL1yF2l4pFIoLvR6Dceurperoqn4eOKfffd1fVqNXx8mYzZ71c/lKtV Ofvr1eCPxeTq5+FzMR+uinJ+db8erfDRj2W5miy//579cHvD/vH2jcyDjMkE/+RxkHEmeSDZcvL2 zW9/YfO3b34YvH1z9SNnORs8vX3DWQj/cRaLQEqWhUEo2WAGLd7fp+y5evsmZM/45/3bN7/3gKpJ P+7N+3kPSOhfZvTx2/5f2eA/3r55B4B/efumMwlii4ScB5lo0tBEzc6FRAY89CG5719GPRhX0pvB MCd9CWgvhXqyZPhyCM+mU/y0efPU5/rr6gV5Uveb9XlGPVb9Sy7p+bIYTmtAq5X59Aj/vyAsbDPG Dwoe8Vh97HOumhQVm/azXjEsqhL7z+vm1YqgTvo8rgdAb1fwWhpyAOIf/VT1GBmcqv8a4dGzv00e +6YfUBGrBncDpOJX9kiIF9gQQS2LZ0P/KsAeqvG8nzTh1mOkZ0ODFB/jl2pimisuwjBf+1z0CuL2 lChpkHuoNJwiM0o3kjxIWhJTzJFWmrHicYgsm4wVB3ioX25NX83tAh/R9KjuX4HLxRj+rPErCRoN egwcJjlDTq2VcPKsMbma5efRD55lQe4e6/8H0+M8EJlbT9eGJx6hKoFvWkRFaMmoZit8LM2MVAyl tdSvM9VxiW++ApgtRdpScyJEiy/MelebMAFboCcZHlGHhqEpyDZUDGUo1zq9EZaGmTjPtEc8CWTu YTcxg0a5RCoXNedo0Bc4LBr5SLVLNZvUEOiNj50VW2FLWzEICX5TvUo16nQz4atC2em0Yfu2uN60 02ZOFGMXRruWNNFb/QzN+HFuzN7QaXFOF24JqtZWsw23RzDCaWFs59Az8lcUDUX3Sz0zm1lwWJ6h MSQgm7HmTfFPsl7Y2Hj2S7dAaycQnEnyBJdBnnp44eQ6NQBkkWBgrAQLA5nRnzBU6J7+0ul9pl4j sWnrfSzjIK77p3neBtGhiaKCeEJU1ByxXkY7x7C7Qabf7xqFwU8kWiTU76N9w9zdxiPlSZBIFmUB 3z2zalrZu48Uv8ZRkGUsyeIgjFkaBlnEsiTgeUOS2NXPGCR/vLm7ZeHVh+H8mfUm88v3P/Q3YXAD TEJgMLQEOJlLJLmwnSAH/5eAFwRzKIh0jyg2yOZCBilnKcxJCFId06iFCETkIZx7CCdACo5QcFKC I5y6RFrTJF2kQZyxFHhfk36HtuHTAPxM3HuHKvwFDMCna9Rt9ZAafP50/cGEYI22HyDCpw830Okz PBe9jx/RsPz6CbrF8Pgy7V2jSbBgsUaTz59avDttkFEMg4ztQe6bnygTKBB6fniSgijsnB/hmR8C VNPeAOSgHRBJSjQaxEt0tdAffIBINPHE249on3mCHGsP5hCskQtrygMb6Xdh+AP//hQ8ztGlWZBm 9uhOG40TS0bgLSwf7hkHrxeh/EXKi5+biTEoV5T9H3AxjmQgkz+bi3GUglm0sbw7PxZJPfaMpaGs TSWMdhlJbsy7CHkAXimJgjx2EiV8ZjIKIdtRNA3efXhHxuzzx4+/YtD96e7mGv8d3PkM2AkECOAq 2LwmAW2mNJHETSRJK8k6F0PAOIXGpN4Prj/dXmMw+OX2Djnx3+gy6AHwBP/5xO7f3Qzw0+cvZ2dR BI+y3CbpeB61REt2EC0vwH3+N8nBpcmaj+AZo96vt//F0Lj/jKys/bDyl7dHDsxLhwhBviKbDoHY Q/DxHD9E58YoSKItjJdnxxEHkjdxQCgKwjV4hNGF4DvPjA5CXxnbQ3KarjrIEBDygsgKCByR2iiI UsYxSnfHGLEvxmjAER44G8VxmtuIhnqguU1202NUGelJmJQBd6uyIyoA7QZNDhuOZv4MySel6AUW YCh/ZeUcc174/kfbD51Ig2FMkwiHT21giZtY9pmTtAPrYjOV2wB3cE5GGKImkGZyM52fl8ixZ8U6 qgDnquCBX75l7+YYjdNr5CQ1UeztMtpDiNMstYjbqR86KQMFzDjW4NN8l3Zku1M7hCIICuR0HZWD MtIkSdBGK3p/WaMxpBogLqsgnx561UMfhLO9sHE8ZkwpIxvz3owSgsAkNdziSUbxl59duc+hIZzE UO2G40uEIUKMFcMy44KjK55cgOVCTrks7gnYID8XiY1tb1oHfg4lWDFJgEDutrjcVy9oAhIeQB66 JedYn7DophI1SlW5nl6wyGFoTsAHYgjpr4Wv7WlPQgDTzvdNxCkIkrCFIGWfyq9YUJ6NJkssvQqM k0Iuz4nYWKzOImbJDtfiQoUsmIQUhDWLgkRggSmXYAuwrGuKYqrGoRvQm63XCUYV+n0WxGLrvVYk b/8I+tevlWGxGhg2+QBEoaQQUb2H6C1OthoY7+ADIDILAEQckd1iy+6DZwlh8vMEA8VdSuqrvTTg CAUn62h/BVgyAWORCZYn6mrk770PVNO+vrvXdSv6d4APrwem9IWVGfrwaeBzCUeQFMGcychB0j6b p1GCeIkOXpT7cugGmOPcKIhHbhGu1s9ptXepV7XRBHr96BGoc0wGXbi7elPFNcljrOTsYps3P9R6 qYgnQC3+73GnkCPquqUm/hd0ql5XegymxIOpm2zFkPEALiVbAhdzYh+bfClMCxBMMUJyV42c8hWC rY6bxA/UEt100o+8QtUJY4tfGXBauFB2FCuNVYvVbo75kiw93U1QeecBGNGCAUS5bd8gGSDFhOSK Ua2m8QjThvmY3Q5wja/xfAUuGLeMqPyinJbP7YTsJHqjMCbf0qLXUQg5DU/mxvM7LYCWLHr/M46R /lyz++vogmHccdcXUe/dAOuBP+KqyG+YJbxnW3y6wO4/U8X+htZN5F/PSz5WnDEk7sAmpx6naRBG XTyuL31twznQ48Zpjkbk7B73GJK0x22T1D0EzDRrVPQXA/Y8RmOTh63wTE87tfCFb/q15FHdyh07 xRCSC4iuwpz+2TGTvjSwDceTl3nMcRznQW5x7UfUgxI9PdgR0Bm1NwNzaAEWpPRa6CNIwGAZYsw2 DXvtMyQJnBucEWSYeSvUsFb9TH74tLy8+alpnRGQBSfuSnsSY6zSpp1sBw97SgPQ8tyhxZGKsWhy 8t77Pu0gy5WCkOrct03M0bRhDgDJ0+F81VMJOo6CvVcqhW+1uwHnOKmUIebebqk0QlnihxkEDfi/ 3n0U9VZshXu+vGJ6BE1cCkzD2kR1FVPFzw5i6suQtCgo2o8S0xbtjiL+CUhyHNnhDNJzwtMg6WIF xe6kpwnnQHkT4ZYnbsgbbtaLe0+0C2uJH2e4a2rYxSYeQRCPlU1sUdRV2BTODsLmTYWUHDTgHCps Ldprm3gzaBd+jseHxQkIAw/nlZoemVHtW8tdFAWJj1W70yGCU0/zFpzdcheGQWxRfr1YoIih4JVf h1OfZB2DEhtHLpwdJUuzS0vWLnZ5cyGaaU27numOtGvJatH+ZagYRqq6mqgNpapQ4cg5jsYvRB4k 3IH//bJcL9ybe07AllCJro3NeLoJYlwVZH+ez4k54iFFDi3MJdk/9ss5cUUCtwG2cTnWsE9AkrmR XPGE/cs5ESVUZOiiXScgSUM3krPOCyRSsUvWY+asZx2NSIYR7kH6c1kmwyRIXSx76J0TC+hN6uJZ Y8WIlm4vzjo2KTHldVhFXHFZIML2hu4T0CUZ7l/7k+cr5W4kYIHOiCXjWFj7k4cCfZxI/hOPKCx1 HX3oEIlTMWt3KaGPXRJJzzg8nnI3knPykKfSjYSWFS8jFYyPjJaR3xeu5cUTvHEcY8mrTcJD/6xY ctqm0YGbzlg2kd0qSWJ3TbAJ57AcSkLQYlcbbtEKDcdk9/SWFj1N3rD2COw8VLLeQt81rFU4OyRM vp0retIbcA5MmNq0c59kHYNE62kHBp2CRLqRUCKNcz4ycflanY+9zOnbH6iu8RkpETG44ugIedAi CJE+hIZqkQxV13uSYHdJluCkZsUKAXVfI5MyxiE0aL8p56vhYx+Cfq/qHIWPhzyIHPi6b+X27bzR S2iaLMFFkGQ+snzrXkhXnlp8wIznZVlU6swcLXSx97ixBN0Bbjh0LtQcS4cAkUPT36LDs56VGvEh PG35cXLQe2SoC8Q9DIxo926zvrCuVks8FDjVDDxqHN6tXhwLpW2s/u2DFidM+XM8sav0EW4GSuo5 DGuaOq0Vgj0QkWMOB3jrgaPCchq2JMddXF0k5jQ8WU5LTC08/3pmPHlC4tDCk8A7lkc5/CPjdlh5 ElJ1rOlQHiZNNHu1Luogawpi2lX8jaS1xP/dbNiP9J0Hu+XtUIx4Yirdr3B6+PeL4XzDAfkncEBL ZZMefL58Np++0DlROuBvW/HgeVkCk5QV//f5aoKL9Njun1Tem+PzgJZ9Zs6xNaY2Pv/AYhl1tWwn YUmCDrO54WnNbxA8iI9i2rKH2SYe5zVLzj5rm7T3PcpEYNizY+Vbt/CtfOvXIsGQxH4PbyhA9PWH UE+K+j0I9va2Q2Js7IcQyQxfGBIgshHJrsV3yVO8F8FsowjxKLQ71ItSj0Q1AOX1poUtQDjXW+Ed RBWy+34kixJ7p4IUKQZuu+ZLtfDOl3otOCcBcrHbB8CwW0Pwsdui3hky+5RB8SoM8QqLBq/uMOGn HU+/NrjW5HKKu2atrvZyZ7MtsC6WW20H7BewRLh5j3l6cQETn9i9Xku0WMu/V7gjq1ovFmpJgj2V 24sRTUgCtwJxG9LqZeJtLmWQxVvkenZ/ITn6nTDvPGAjIRCeBXaxLFclphzltPL2U/Voq18xZ+Pa eJezRVlhzE53m7BndUfKK118gefK6RaXiq0rUx/Ie8+0UNi6SKCtRpgVJgZrZ6mweu2RCqvtgP0E UhEImdEOBLrdCG95CRXFZmTgrMzQcBzEhPlqWU6ZZih8nwbYkSui5+qWD7xCSknNysttcCMRt6kq nxiIC8xShdsnmT1peKy/qDzQ0EFBZGdB82FGl7TdFgf8Ff+ouAY/jaaTC1ZN6lu2OsxhSqdBtcSt RyorqV5wMGP2xUiOEqWZKR/Nx41rU+Z6Fmhv304JEDwL4tTG6ZMAPPcYR3bbjQSAuWUPPfjCwyua SSw5PvRxBlDdk55vS6bahLhPVCVkXTHvRihePBDnfkKjmlBFY6dZifMgNMD0gLY3kwabsTgkeDbB HHNONwFBwk7TxdRtNiQaD71bkBLgGMDctlELKg015PgVpWGJa7tsVo6J35P6JiBlWEbYh4wJkVWV Pm5JunrEGqCXs2BrMb1ptjVX9jRx/6RsQge2SiokK0ijiQYFA8PrkcBSpCDMZAKNyG8k/AHXtqHt zFw7NWYNA/RNP2txcWQAEQ5zU9CS0e1OVaWvHII2c+zNrtg3+MTM8jYYj0FK6MiSNa4hbV/AyQJc 6AYooNf4FC7wEA1R6MK4iG/8S0ej8NAPQAk1korYNFF7GqWWJWPFR1QRAaotll+weUnCy+YGmRrJ EKtNaPPA3CiJw+f/WBdfh1PD87kW9tJrUMOMONccmBIEdeTTZ7KTVi8vBpG32hqtG+BoG8aJfEc9 RxDALDvNCu7Y2Qda+b/5xMHf0Vrxt1o/PSFLHwvNOh0xjWo3Wzwqw0KGYYUvMs16rXsgZs8OBxxB bBF4ZyCh/UbNQXiuL7LuF3DWO9vMEXmKEaKC+1P5qsXnKzFieQFimPbGY204y3nDdNrasbEQdF8Z uPtqYu4OWy+LFUQZ+UaUwcPM1mSaFJ8X08n/GB0c+5Q4o3OOFsHeCCSTrbY65LjEuIZVdPObufzy 72i4vsE46DdzHHdE6ju4IWvTzRsJXE0z2IqZGhd5AZrhevDgHJYYe2gHgjqORBTVBN6QARiT20Am 0hGAZly8YWDr1MSCrCcOEgZYjvQlml7BinDNIrWp7iJYzjKwgxsIPjk06rV67Yl6rbaNXOi1XE/B 7eB+q3TjUYjFw9W2KbdiqVBdnNCEWzypGxJJjcv1ZlMv4gCR+lpsZswrjZBqh1twEcZUmegnBWLr lr35jmQmxiDXArdQdwoWj8CE9XRII58q8+OLlEPc02IB8UfVUavta7F6YUvj5asFWubHTfTki2vi UGJ9ygL1rbdtRnct+Ej0Cahzc7Ila1hxkJSjSgOYb6vJ1Y+ydUwravfb5pmjQJCLdjdMncdFtVJX PT7iHl02mqxeMegh79KGG7cWfcKU7k1owkX3BoYNAlalcBFu2o9691uucz/RIqPVyZ1j3bSNWm1N HrF3FHgGIOS7R8HrYdRu2g48948nwhsKebfxRHnWavvQewVdfSkeXxiadjC6C2/0E9MOO6t7ManA RYLNJ0PxVEAqUpArmu/2LEZ2QFsTA0snOipm1uHKC52Zi3szCFfA7/JUGyyYArwCVmcizJ0Ls3Ed /6L9WBYLul9bYF50RaEPVQ6mZVWZXqD5PGkkMk9IUjnDTFjSkbUbFTIV44m1+8TmU4iRnzW2Lvrt 3Fzv0m/IOGvvLw7Q72a/A/S72Q1rHZ6SHB6m24ejpSUcq7V2r9vBB5z9ezasqvIRXFtnXeBYAN5N wqZpjofsrbZKB02isVhdsElAkS0KSXDhtRJJjFuTLVBFxUgNvKUkkSW428jqtElj9GGavLcvjYli TrX2DRh2iXewZ3R309DbLYFGFnZ4jD1a6adtXiExwRKLs7KpLZgrfe5mCsJoE69BAlSVM4SzelGV SVWVhNh8iFG7WyQ2daYQ77OyIP6bty2dmLXadlFW5+ENh7LyLN94+ai7slr9uiur1c1Rx/aqoNWx 6WCXKAHkmJ5LvVy4h/0cshMpDh6BwCJ2bHeDQPRRX209Xi99pgfrbILbPX3BlwCNidPdxG3aylbb 1xcUflVPU7VSRjEPJj5PPnUTEmuDFpyCnNe8TkDZcI4lJbwM/ZW88VSnq/oucw6eWuf2u5Wzi65x iLRlY7I7K/J0QnfJTO3E0c41BC6QWBjGpQGGzCLDWDGa2sRMresnCCywOaUwFliq5evr+3Evm4/5 cYsgnzHAYo3YatvFGDiPJ7mMQcI3IYE8wBg0+x1gDJrd9nnuPTh8ZqPZq2U2qvVsgbIjdhgL3G97 +AhRl7a7dTQWuDNri3CvscBqdb6buE3bqNX29UVpdNNQmNTSipV1VkE1kymdbDSOv7WAqEorGMSS Taar5DfbOPaYZkw94y22+ZQhxtPzO2bGpwzOw2ftOgqXPMjM9Y8DWkJj01L92kdt0Z7Qom0v5UBw QGnUNmtUEXpRFvP6Vx7UDyGoyj2e1tLrhFOytnVs56hcNsrKi02FW4Vkeja963owMAiurPGpZTVC 9rKaUuKncIyLp6e+Pk9Gsz9fsfF6stuKawaKzPzazu945UajaDnelOf18m/DzywWtF2z/oEcLMeh +W2Ucv1MUYV8I68g0AU5Hc1yYvQcS6vTC6YCNzUyfLSsf1lE/abLlBFjy01RcLO+22H0XEJTM3qV I6pI0a414cavuVkjqlZL2hIPLWZsomWF+BOo2wLUrgE8xA7kPPSg3S3dWbgtgotl/dsxWw4MK64j lXZexu5kdbHW6x8dRokxkRmluk1xOJoW6t7J2QSExbIcExObYI06wfLuGJ/PUNqxxA+a0/jhlDWx ajYqSB5p0te++lYEYTJatyY96wrBR/Q7TLwdKyjlVb9OUi/LIHuqNWbjL3oBbStI9VmVtLHpR988 m1FxNaHfH2ge8IDkJhVEN94Ugj8kQT85INkjkH11Nxs+T0TIbktmEP0vIkgRaA0KZW5kc3RyZWFt DQplbmRvYmoNCjUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEv QmFzZUZvbnQvVGltZXMjMjBOZXcjMjBSb21hbixCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9Gb250RGVzY3JpcHRvciA2IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1dpZHRocyAx NDkgMCBSPj4NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9UaW1lcyMyME5ldyMyMFJvbWFuLEJvbGQvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQg ODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjc3L0F2Z1dpZHRoIDQyNy9NYXhXaWR0aCAyNTU4 L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDIvRm9udEJCb3hb IC01NTggLTIxNiAyMDAwIDY3N10gPj4NCmVuZG9iag0KNyAwIG9iag0KPDwvVHlwZS9FeHRHU3Rh dGUvQk0vTm9ybWFsL2NhIDE+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlw ZS9UcnVlVHlwZS9OYW1lL0YyL0Jhc2VGb250L1RpbWVzIzIwTmV3IzIwUm9tYW4vRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDkgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hh ciAxMjIvV2lkdGhzIDE1MyAwIFI+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3IzIwUm9tYW4vRmxhZ3MgMzIvSXRhbGljQW5nbGUg MC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhX aWR0aCAyNTY4L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAv Rm9udEJCb3hbIC01NjggLTIxNiAyMDAwIDY5M10gPj4NCmVuZG9iag0KMTAgMCBvYmoNCjw8L1R5 cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L1RpbWVzIzIwTmV3IzIwUm9tYW4sQm9sZC9F bmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyAxMSAwIFIvVG9Vbmljb2RlIDE0NiAw IFI+Pg0KZW5kb2JqDQoxMSAwIG9iag0KWyAxMiAwIFJdIA0KZW5kb2JqDQoxMiAwIG9iag0KPDwv QmFzZUZvbnQvVGltZXMjMjBOZXcjMjBSb21hbixCb2xkL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5 cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gMTMgMCBS L0ZvbnREZXNjcmlwdG9yIDE0IDAgUi9XIDE0OCAwIFI+Pg0KZW5kb2JqDQoxMyAwIG9iag0KPDwv T3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRv YmoNCjE0IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3 IzIwUm9tYW4sQm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4OTEvRGVzY2VudCAt MjE2L0NhcEhlaWdodCA2NzcvQXZnV2lkdGggNDI3L01heFdpZHRoIDI1NTgvRm9udFdlaWdodCA3 MDAvWEhlaWdodCAyNTAvTGVhZGluZyA0Mi9TdGVtViA0Mi9Gb250QkJveFsgLTU1OCAtMjE2IDIw MDAgNjc3XSAvRm9udEZpbGUyIDE0NyAwIFI+Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwvU3VidHlw ZS9MaW5rL1JlY3RbIDM4Ny42IDQyOS4yMSA1NDUuNzYgNDQzLjAxXSAvQlM8PC9XIDA+Pi9GIDQv QTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShtYWlsdG86Y2hyaXN0aWFuLmdyb3Zlc0BudGVjem9u ZS5jb20pID4+L1N0cnVjdFBhcmVudCAxPj4NCmVuZG9iag0KMTYgMCBvYmoNCjw8L1R5cGUvRm9u dC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjQvQmFzZUZvbnQvQXJpYWwvRW5jb2RpbmcvV2luQW5z aUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDE3IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMzIv V2lkdGhzIDE1NCAwIFI+Pg0KZW5kb2JqDQoxNyAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRv ci9Gb250TmFtZS9BcmlhbC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2Vu dCAtMjEwL0NhcEhlaWdodCA3MjgvQXZnV2lkdGggNDQxL01heFdpZHRoIDI2NjUvRm9udFdlaWdo dCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEw IDIwMDAgNzI4XSA+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1 ZVR5cGUvTmFtZS9GNS9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJvbWFuLEl0YWxpYy9FbmNvZGlu Zy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMTkgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0 Q2hhciAxMTcvV2lkdGhzIDE1NSAwIFI+Pg0KZW5kb2JqDQoxOSAwIG9iag0KPDwvVHlwZS9Gb250 RGVzY3JpcHRvci9Gb250TmFtZS9UaW1lcyMyME5ldyMyMFJvbWFuLEl0YWxpYy9GbGFncyAzMi9J dGFsaWNBbmdsZSAtMTYuNC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjk0L0F2 Z1dpZHRoIDQwMi9NYXhXaWR0aCAxODMxL0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRp bmcgNDIvU3RlbVYgNDAvRm9udEJCb3hbIC00OTggLTIxNiAxMzMzIDY5NF0gPj4NCmVuZG9iag0K MjAgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDEwNy9IZWlnaHQg MTIwL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBm YWxzZS9TTWFzayAyMSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2ODg0Pj4NCnN0cmVh bQ0KeJztnd+PHeV9h/0HpKtcIjXXUdRIvekFzUVEpKJaaiqkpq5QqyChJGCSC9Qb3JvIzkWsiFxQ kciGIAEKxrFQbPkHCCJg6SIvNsYGG7v2rl3/Xns3XuMsXhO6coS2z8zj/ebtzJw57zl7vLuWPHp1 NDtnznve95nP98f7zjtnV61q2P50fnL2vSNN79zdsrabN2/OvrgHjMvdkDt4mxo7O73+GUgud0Pu 4A2AM7tH5ufnl7shd+qGCU/d9+gXM7PL3ZA7dUN7iPDSmnV3DbnvjVg88eVvEVCWuyF36laIcO1G GN6NyH1v+MALq/7mriEvZsMTwhBDvhuR+9uw30tf/c5dQ+57Q3jXnt6GCIus5tMby92cO3JDe+P3 rIYhJO8acn+bnrBwhnfnGfraCMd4woEb8s1yu35j7urMp59cn52YvHbx8vUoHKTwLrL//H/nBvWl y7LRBQKxIiQ5XIwhT169Rtl78OILOw79bNPoD3/82r8+voPy0BM73aH8049eSY/8x5NvUbbuOsan Tp6bHmC/lnILEVJ6mmdQZnT81eHx9b985x8e3vZ3//ZrsQBw85YDL79x5O39p9567zh8Pvjvc4dP TfDqkT0jx7fuOcw5MgQsn6UG6uHkj8emrPy2dnyAG9wECMmcrAYDhBvdB9df/+NzvEIMJsfGryDC 31+bwWyv37hBYcfCQQufTXcmPpk5//vp8YlJ2EJy6OtPQpKCgKmTb/nsj58vAYFFbogQH3iLYevw BA+G3uT2l/f+J12m4/QRVzYzeyPgRIHnpaufRLk4XRSIRTk7NX168grFP7VuVPqzLfuQJZrkCH9S +VIC6XXDbEOEjVkNfECHJOjR1+7fjE7oJnpTZnVudYxBssIQgPyJDtUtJJEfXwSx4xcuv3noVDgH DlLJirVrGhYiLOZqkqwGUKLDrCh/+88vYLwgpdz47I8UGPpqiYMWUChOSopRaBScHv4QyfEtvEIM bYOOE+AJYUg+t/OgfpKv5lIuH6e2DWhn/uKb4Qyxa7pMgyEGN0wVL0cX6CyuiT+NtvQXQ8bQokR4 5S0+zvkgIoLg6NAY9i5YsICL60L9cXWM3YicAjEq4UuPnL106Q+f8XGiEge9gtSz0pJ/p7nCkHGG qx//Ld2BFTohdCIM+sURIyY79BdKAYoOUipgI8Kaw3Dc0wzZfAoyIUv0hl1DLKiyc//3fkOF+06e 590Pz1xEjXyW2rguK82iCcHYbzDc8dhT2/eegAMNhh5tBhSSACm5MY2Hebxi0TeTLd5CbDDhI1wC 8xZqw4tSFBhShB5q12YpkJQSb42eOAc99iHJDgBPXJoGJp/lCJdjRVk0nU1FSHn4wWdptr2mm4LS DHVuUcLp+VZ6wvXCL36u2+RPIwKxlWoNEAgV3b5/6gIY+RYYIkuuF3ykqvBU4yvDR2GISrm45jxc nZUgRdqgA3/5S9/+syGXmSG2bOAwFuDKKtAMHGlJIwiFj/BBMNJ9ukw0KUdzN3AORdKyaVTnBkms G2Kczw5HgANMcIXwcCO08+DpicPnp3lln5yK5Gp5R4V0hMZjVjTvnb//91SEw/c+gk5ovxlLhV4Q A06UxkDMB7lGxhcORm5j1o2ZY+MaZiHRLfuIO/pMeAJQhgiSS/CNh17CPY6cOIcywYgj1cAZXy8L PaKqfolW4XPoVKQ0FpDSd8cUKT1ZpegqGCsAcYlcJsSs9irJITscxO9hzpq2rg90cIMVDhNDhq3X mrccX6tejrBDDUscnbERTADhcWVjeEVeHSkNhf3ZF/fowaSXqk7nVimNDFUgohIgpZJd88pBPs5B MIrFCC7PNPrbbHj+YueHvMLWDGEphy3QM+MiW9aB0wsAopZKNCkYvneErvFWV3qdGALQETTHK2M9 RyIAfHXfmBqjVYQMGeKZizHdsTPoEyl+dHYSy+VPcHFF4iBHOI2DS2PLH49NcRFpgNAcWykGytTY 2TSlMaBwEAh1ejdrW4UhBYC8cqW0SsOKpg1AzNNYr2Hi0LAI3CBnSkk7LXzj+SIEE7IhBm1FeOD0 ZVwiANn57sY3lkCH+D3oYQhcesekAVBJ0C9vmqQF30ivJdNCr5GhIuSIQxU8FVWZzKA0Z2AIB8Ch MbxFSwgftMSEnAiCemkzJM0eYQhM6AEWdALklaIt07XbRI+abbCexyFnChBBatGVaOK8a2qnneh1 Ashx/IZBk246TiRj4XuVouMRU0ELIw5OQ2wcJ8ZxvpkMWQ2WyxH6wp+aMOX1I6cpDipvx2wYXdAc aJuZfx0gBe+EJ3EdSJXh+mdEVx99OABJAcoQgB5EOWabeDYUhSHoIUVnG2yS9DiffUXLDn8iRZNq uJFL8yciZF/tBcDtH5wyYx9sjk0HaQntx3acyUwBRjqhCBnC16NJTHlV9DafbHWGHISVaR7acFIR LQFWqadzXHFZZciOmR6Sw8AdzY0sSBF6bx4qWOEzA+DuD/+H1+ffPckJfNcAExu4OQilwdG8RoBO GiOeYuyfjE2ikNh0BejxFJ0zAGx8tfbr6KYFIIVo4kQQ6ACI93MkAj28opEXWUI4AMrQE4hcA6FH R5wpwgul17eTCRslaTyKTdPCSGy8h9LJhIt52tkbGJHo+FJNPoZ1HHFOxqhRARgmTMEcQE0lZiwA tPAnvpEYhCrIBgnBKUCs+HdHJ5zSWXxiQ8upChTGDr66HaB5Gp2FJD6TwUjdGY7fsxonWZFckMR2 aLnzTt7BjLskqg68fC9YijC6/5RBJCb5U4AcdAYMaAEQvRlHYOhUG+dwRB8owG0HzvDK0A/Hu0iA NoCmYgh640aA564WHdT7WQCCIfzL+tcurVlXN2SnryvCm5i8Jha+1IMRhYOeox4nqx1WmBJzgiJM AVJMCKnQJDAF6NyXLhEdyjAFyEEIk/f2TY92mjmgdgzHJtUBYimkyjg3mFDYn5mYojDMf/jBZ9/f Phw3QOs6DOFt3XWM74IG0lV4kUinANM7JrBFgbdS5U2jtIrjMgyA/MlFgRJuMEwYegQOvw6X6IXg lYO3AO4vy4EzP3jqbYaB/c3Y0Avq5Nu9sxBNSgHK0MgCJfwbWNiJ4pG6Fac6RLcKD+Bq0iSwMqWQ AnQoF0kg1uEkPw0mttIYgwvQaCFpDwJgn5SP9kPMyTE6BTGEB1KMBbHxcZxhAHxp9CSlsL5dx/oA ePHyda4LFVI5VxATSAEGQ00YCPUBSE4BLypFCcBRePWxcMV+YzIh5hM4znUEozm2c6ov7DiEl8Nw QEpHgMYOYuBiYbPOa0HPHIYdusnxHz3zLoYc9BAhR/oYntAXb9ZgnvSOnVBgRYQRRIoBVJOp5hRX bKY37OrTqqn9Br30NrEhDEpIzhRFWVJQFwzj5jsukXxmdCGFjiJDXjFkAVoQMHX2IT+uoJkADFPH 0hhHEGEsmOmjOE4x5qboGr1f5U5xGoJ1KeyTR8EEtwBSb9s55sWQHcqNJAANwew43oEhhgw6kmpe n9j6Plch/zaK4w5H4rREgN5QaGFIIGa/PgrugeHajc4b1OnVvV89hQ7fYvMMwcYR3aCJtFG4EaCF wIF4fv76UQwZgJRf/df4fY9swxNmjk1ADfA9I8f5OrgZSqI97SKszKn2Wsh5nPtqodciv0oC4wiO fQa/Tiy0AIwsmtcHyqAGN0VI0RPmDJDNKBC8mWcx6N40CkDbU2FYmVXgFYaNo+AeGH71O87BVuhV ANbXyXQCSNjFigFCHBFghV4AhJ7F4Lv68d8KEJJPv3m8uATD410Bct3xveSQZp60BP0T1xoBpgzt jjlh39HEgoaJ6eVtozmuSOM0fiY9CtA4QhfwbPyZAkznYQKgGSDECCiYMww3D4/B8Lsb38CbdQXo 3C9fETknynfuscKwks+khtxfStNozo4K+9BeChA7MqkwfLTYb2SAMMR3wXDD7o8QITzZgUPXGQYX V9AMfYUMnbWItlVEWJ+cKSa1mkZw/Zjzi3u4IpS69nIAQk87ol/6pYoJh/wCYGQvMNQZokAAUryV 3EIPJ4n9wiqcrRPgMRrqasgRkfFjLuYflBQbtZdDj8Kf2C+BONK/RvmlAI0dQmNEHwBB0TJFs/fg RSdpvcvv1AfnFznV/lMmaWWZSxanzTnFiptiP520L4bGDJAXXXAIjpqNLGrPJVtNN+XnFm5AzxnK EQAMiSBoqZIBQq/IwP/wGSZj4dJXCuc7owjVbzz0ElkibegEkBQdwgiPOuezNxwUl54253+k7w1W Cs/56pzN1R0GYvx5DN8E6LL/nA19kg0Off3JTvMz8+UCAKRO/d6pN/7GCvn6q1N2zhNy3XM+0t8r hZqpH5mlAPVsnT7CQFiAo+WwF4CoKAWI5WosLfXQnZPnpqkHl0hi45xDI0DyZxwgIizWaZQK5OOu KOtUGLALECcjwK4f6bvQkQCIx3CppDfQOxXvawRAvBPpGeac3gQRIM6tpR51grQwYQpgGwESoGkk dVK5AAkcvQLs+pFFAsRRGDUEGIsGG4uDL04eKVMX5IGMAZiGDwG214P/px4agPzIBrlqjUMSOBOn rFwT7ionW7g0CqTmAIjHyFeg6y1RoJMqcQvJm5gCbK9HBSI8AJINIkKO1AH6oJD1E4/yFUgUJroJ 0BVQt6MgkjrAHAVycqrARoA5CvTGLgDxhHS8DpATGDJ7a0CAmQoEIPmV69CoWW/s7bB4tbS7mqFy 7Zlnpp9y34vlgwy9KtC8BYD4sfT+EXEhX4GYMPuYMAVWdYCOFvmiAJivwAA4v7DIOd2JfUTeXiEn pJnDzWTVtFsFYKYCnQkUoB00ed62P0uBAgQa2sN+AUg76wCdQzC496RAVyMzUC2e3dh1zPWoLqqM m3RmHT6W1RWg95J8LoxrhEN2gouD+ltKvgJd0lYH6LiDPDBTgc6sOjCBTD2OeD/RyntSIABRIMX7 XPJMh3vsG5XIoHIAIuni7s+pCeqPlfZOjcZgDciZChQgJQCmI998HwhAIwjpNNZaGdBxuc0zrbxX BRbPv5SPFcgtBqSBUYCZChQgRb2hw8A4Wg4zeUuAmQp0ul6Ampg3f+lvvg8UIPJDhFRVmeF3PYAA qZwu5CvQ9WM+CuQiihSgxZtumQpkBJrewyITdlrSpae0avveE/k+8KOzkwIsHr0pAabzBppwvgKJ sz78UnlU2WlAzrFyAWYqEO8EGdrgHf8o6cRITwqc2T0CNNeURnHVfdy7VBU5ChQghZOf23kwnfd7 /t0eFMjJAKQAkM7Wn/WmEs6xckSVr0Bye5fRuv4TZ1jBGAAzFTh136PTazd+cPZqMLQqUDil9uah Wy3MVKB+CdPDyRt8AyBKzlcgQeTnrx/92v2bqaoO0CUiAuxJgXCmAVhxzL+J0eK8nAs2MhXorb1L a9YVT6yfn7aGKNbvLEqmDyRw+ACO94wW4wN/+uph4gjn1wE6z+A95Z4U6P1rH2BxDjYtdtmolK9A p1LZeeu94z5blNbJtwgwR4GvDB/FOrh2yAaF+HQDWnIGhljQtZ5UgQAkG2wEOFSm2SnATAXGem/8 c0xlV0gST3tVYMzqv799GHNO11ZRHDnmKJAvRTMucXRxgjGdg6AAYK8KFGD9Pjv1k+HoGXpS4J6R 4yPlmm1ns9VhypCd/hRomfjytw7/aicMD5y+XAGYo0A+hSoYDz7wxE5n6TFn7/nGUK4nBZLJYHT1 iX2fTqX+XhXolC8+MHSYMrT0rcAohBXqkSHfle8D95++Qgimyz946u1wfd71oLM9jURUYKeRiHoj z+FMmOQr0MGmM70+aoHbift6KcD+FJjeXcIlAiTmzMHS9fpiAt4ox/WZ+3mv3NvlveaBzsbYzgpA p2t4l/oFmKnAGGyqEIwFd+3DL07E8ZqvQLoTPy3VeKMTlwjDnClfH8zhTAJHfbkL9FDjfLma3Qco OhVOoFXeGkaBuILG2RjXiPJFnNaTAmOwSYEVDH0+lyseSynMizIVOD4xue8nz7esW+BdRitdp3fA YpDFS+PeNw+Pic77vNDTD9DOlkroiE8ywj+CSON8IJwdKXOCzctUYIyVosCQkRdfDUlFqFPN9IG3 zP8nz7esU/Inp/BO7RViDk4EeX8zVnTYHjaf4GgpzoQDRPulYO+NM9KM5nAp+EA6/rujE/kKNNWv MISAt2KJLK/uG9PiMhVoT7FTrLUTw/F7Vv/p/GRX/z9UTmXrxCqbv2nTbrxD5YNRnAwQ6Tmj1fgs GHpmjMwJ/tBKvgKxUwHGMkVfnfvVJUZKlgOQKxLPAHZao36hXJM5X95Iba8zMPLtTjD6wJ2/BdRe vH/Epv3ySqoMpTq9VQuryvGQMCQE9DQWjiFSSpKivVAtfiZfgfEAIAUdouRGhv4yQ86F7rtEIqT8 HMc1RhA3zsficLBkrfkKBCDRzWmcwFjRJHEhX4FIOr0KfLxwAk2rlfSEGGOOnHotNgbnGeEDaQ11 XpmwamFtKqf1FIUx1QBYx2g5PXklX4HEoBSg14Jqdzz2VJ2hC9RpuTd9BlJwjDoxjDdmsQBIhOVK tS+WRnWYuQC7NkmAGGkxLFqYI0pJRrHCTAUi6RR+XBQw1kOzv8wwXy7ypz1db/x1LciGeGqFkTxD j4GM77Y/d2M2SBycX7gT6gNljUUTFuCtNXX7//yYTx2gUa9TbXHdkXTjVXAgxri4vnAOW/5iZtZe E3O9hdo1wqaSi98oM0YXS9OHxyJ1oXhpuq7yJd/gTNOYzA2APg5QZbggSF4FmF9hPLDmTlwUZwBQ 2sG/erCe2Fx7epthxY3MlkscvyxKkhYF43qoHFAAjaQu7snOlykfX5qiC+PNediBK+gaLdcnUzMx sfzRv7n0cULaRlXuQ9vxUfpwSsqTVwJZff1e7JDW0gt/WhC3A8DKVUgXjsqQ0Fz5qZ+YuiHcuKQw /5LNl5KzIym6oOeac8eG7QBXlb9qwvl+loiM7QOfyOIIyFeiudMOjsoF2IKxrsxUorzr0xk+YUol LhtorCe+ZfveE4SVTpk2x4Hp3QF4klekyyaxCCcl+HbaT08r3Ow+r9CjYT5r0zgAqW9IAodAKKEG CkEc+I6RXelqOgRAOgJPiyQrMFt4VtjSEU523tib17/Y+aFmG1MojaVRh/WCyT/7020xmojXToVe 00FaopagQYKX/9gmBsJnvQRihJhHUoDOaSjLdoyZMMHFaXSN1iJ7XvkW+uJbCt6qntt5ECDD9z6S Qy80yfm4xBZuouP1gXItFsqRgPNLOfbrBmrIY1bB0JvyFOrnT95NAaYMxRgwnQDppJ9OkMGFAl2M R+OxI76O7y1q3nIAy+17BTsYES1Ovm6wdhPxe9/Na8dBf5Mn5zGl2ObL55U029Qh6KaESf1w4yso gbEOM5VlTwWYCpKv84Hi73/lMSxxMY+SpSGbqwDG8H50B72JDuVEl5VfHz/i4TytnjAY6kstKcDA 2BVmO9jK8eLjpd4W8wxjV4xcHe86qfNUjc4e8G5P8gsRgt1HdVKGym+onPzXHxpo6qVCMrMUDLcc wL9haIPSW1ejRttEfw22YtrFU+f7T/VKLxiSfyJs/WrFln2+2y9twdgrSQCiik6/EnCbClLkkqXd jMlnp2T7A7hq4UdjdOD1zNzH8eLCpSRbeKbGXnkN2nRnUA86dZWfMaWiPQe/6GSRP1c7X94ySKNJ TIu52BWGRPzUzFOSXcXZQpgonJnjLQYdVyo8Xt3KHJsvBuCqMqVh5Jgasqk1hW56C8DQXHcgFWW2 gK0cj0+1jDUWq7pNo40DkDAxet1H7GjcnLFEbzGzjer4igjNptmac3uaWk+9UmiNhZ7Wpw769nVc EVXXkkjTU7rT8kxcr9t8ef8rnGEE91Rm5J9p6p6PMYczr4uRIvy11q7f5QiOnvYdeVsY+lOQrpFz nOhakfhq71iFFAeLkdLT2M2Bm3rLvKZaE+33Ds5gAa4qnaErnTYsJEj16LyhHEVyBZGiqG+HFDMD tJlJT9fRe9m3g57b9RtzP/zxa3g/GgZJzLYxcADW3J4TMq9+TxhRSGaAhnb+pXEB9qACR6fNX6WQ nnMLje0xj3IWF4e5YWGWY1CF2h5+8Nkcr1jMwNSmDur0/J3zpflleHTo//dxorW9YU5uxNzOQNQI PaulzhyLdqDRMmvqz+gt2W/Cz5ePXHnT098TaO8skHWMpt8h0f7s1xV6RHw9cGHRm0a7xmjerZuz UcPfIlv6/0pgTIkRcXuvxehTKk44G2J6wigur0XMVUYBI46xHSP5TOTPkUus/+U7y/U/HfjerbuO +RhyjqjCqLHomD7qmkinn3UM3im+q8b2+GIuvaHMFhys3e6o0b7dXPiJbLqWmbd4DuikQS/oixNx MaZr9AOqN00+O6HuqsaXv/RtYtDAs+W+t5Pnpv3Z2/xIEXaNer3zxcch6WxwZYaHgz0NczzHbKfT zBhSnF7/zMr5R8mFOZc/fK0U88OEkwmSdExtuHGdGMWZdt51yiudbahDq8xRcAQXRybT+KPWFxZ+ 62zlYPTXs7XKDb3kfvbafczZJNNFF0PlOj2OoEOKVCv8A6bvUgPAfT7alJ56vv+Vx6bue7RRkJfW rAPjCvmX03jFvQcvuoIxpgrzo60k9ZBcCGcdHyhvW8TtGJ2hRURK1+IJPkfjB/3JpgOnL9O2md0j 02s31jEixZVj0fPFr0PMxW8Um7SkGuuEzsTM4BKj6VRjCkyNURAklVOA7JHQJ/vS41L6z6cc4bri FL2By98ZrjhGF9gsN8Jbmxj9SVj6ErcLU03GnxGX271o4yRt6vT4FjVJXMMWWsYXgEKQ2G9lLANY jq8ojB+PTcWD54ba8GMm2GaGqC4yw66WHtyshDpdglI8mb5p9OLl6znpMWr8YmYWVhVBuq4GjP7k xRJQytlMGv2npfd/7zd6p6HyWQy9Zdxa6noLQCM1BaIeapMbUazvf0kTgvx/TzuuWcdBIA8WxSK3 T67PHhu/8vIbRwjZ+ChJ+pQKJA0cKEq3pq/jCEL1VkKECX+U7IUdh1xuN5C2gZGCJ6z8z1DVOJCv GOB2c+Ef3OAq4z+t+9Pf/qtlter/pvEfWDN45OTyn9rc+qctt6NfxhpJRvKzorKdO2gDY0RtSKLM AuMKM+qVvyE8imlkkTSu3Vj4xk9vrJwQcwdtEW4w8BUYYu6UDflJUin+Hycc54QNCmVuZHN0cmVh bQ0KZW5kb2JqDQoyMSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGgg MTA3L0hlaWdodCAxMjAvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQ ZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDMwNj4+DQpzdHJlYW0NCnic7drRDoQgDERR/v+n2cRNNqsBKTC9aEPfxxONMbUlpaNyTlTlbb2L 2re1rfVUVAukqlY+l4IqXSQXS22VFQF4DTehceycNUGj2F/U7Ixqv1ynNG6NFUg92JqiurBJqcOa lsyWQDJiGslCiSSDJZOallBqWFLp1hJLN5ZcMjcpjpSDVLFcJJKyt3kelptEUlfLUSKpzqZcZ3GU sxSUyisod2ngb+1NFCAFpfKmNlW1OIqRAlMxX4tNbWoZFfPLHpLim7OYjTRhcVQKTsWcW3hbHJVW UeA8kJxygrNbciJNUuD24OXrl5pE7q/IrRy5ayQ3qOReWEa1JRVmksiTCfOWGRJgpPVc7OHWOeP3 FAshH6yWUWt3oS6roTUznVhVM0V6saFagkHHeUnri30AwPIesg0KZW5kc3RyZWFtDQplbmRvYmoN CjIyIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9G MiA4IDAgUi9GNiAyNSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzcgNyAwIFIvR1MyNCAyNCAwIFI+Pi9Q cm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA1 OTUuMzIgODQyLjA0XSAvQ29udGVudHMgMjMgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5z cGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAyPj4NCmVuZG9iag0K MjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTI1Nz4+DQpzdHJlYW0NCnic lVfbbuJIEH1H4h/q0ZaWxt3tqxRFym0ys0q0Mwr7lIxWBgx4ZWyv3SSav5+qtgHbpBM2UYTd1PWc unSmV5VKV/FCwcXF9EqpeLFJlvA8nRXlz+nsV5lMv8frNI9VWuTTp91c0dHXJF4m1eUlXN/ewPVs PJp+ERDBbDUecXDwl4OIHOZEEEQBC0OYbVHm/imAdT0eObDWb8JtX+/Ho2drYv+E2Z/j0R2aI5NH Q3Jg6NkCo6zHZNCXFUbZiEXyPLvSEUzwvqwpXul4H8b733j0YxCJ57PQgyAMmOe3Gjd/PYI9cS1u T3zLt4OT0KZf/HcQp4Q6Zi4c55pfDhVPqfKYG/X9mxEOWBD0ZR9szq0neyJRiztNyBJDlvTwedxS +Brc/x23lA7zvfPillKwaCB7Z5QNmfzAbsMg3D3eAEy/U9883ny7BWf6EOdrsJJ8cn9tD5qDi17o yLjvQuA7zBWth2W6WtmuleBflSB6uUoJ0hjfm6cihzl9q97sSaTl6C+HmT0Juxw02o3MxLPWxEnx jjF6yZetOqqKVrXebUt6OwiuKtu3ii1JoqkHW+w9afu1iudZWtPBZpvk6sW2pcVMPLhYpLKf+FUN ZWx7VqWgIAQ+bpYWORc/9gbUJoHa4C8IWRQO5HdlWVQYJPmDFwtd3mLQnkX5hd389jhrMJdlkeaK zk2+BHcZl31ffwBGZ5KXru6lrryx72RwIvuVCTeELUW4TGNAokXDMObBdeBvMT5K65ctHKs2tobn MDEIOyZmdTVoEMjqPEtAFbBMeh6qbZoniCWlSQXidyuxrJBQ30ozekvOpRY7NTzGoWu0JLoKVSyK DBZ4RMflIbDGfqq5SZMaXg2J8lBShh0HgDsKt9Bs8WylsUkrwtnv97W0hglPjuO0r/Bs1QXG3fRf dkBjqVtwt2wjzzWoul0/T9I4ugLmy75vI++ucyKLjC2QdB3drpkGJm1ay0Ff29j1Enctj/rCXwt7 ElhvCRbIq64kSBWkNHhq2OWEVpaQRKy/e8P+3KSLDZ2cVUU8QmqPWWHtoAUqnxgdlu/WjR5CVMK6 VA9PWawatrD6Y5oXnnVLYbzYM+qSTr3X1Al1PRiwLyjuvSNNHBd5vh8yi+NspqODutrsaj2cqcMe 79HDjX5tvz4HC7yRiD0Wj/ewjSk1PRRgsy8wzQHgEqJ1sCLmDwDkmheJn0mFmZS6LpS+EerIjLQL N9AXm67/GY5Dr5kq7bbJaJq4yDpOYyLn2BBrO7RO1ltLJt6N3mXTtHd8V/d+N5QGbcqQuJdnoulH /Li7tOsqxjy2idLrsIJXes12iXHgcpczPjBUb4pdRmAuNTR60cOcrOuiWgLWk3E1eIRyz1yshy0a 0kW23bYVWcz/TRaImILmRA/zDK8VCvuwxSLXhUYFPtgvdKSnk94xyRtlS/vFa0vpHOyCoLtjdAE3 ZNd6Pha5qopM46BHAvsAQezunrkzbmjcdEMbROkFxzH1zcYFqmvwb9MVw2deONAy/XMQOsxze7Iw wR1Et0PcKDMTxXhpCvuBtTvoh5xyH9L6MBHK8tC2RH0aK6qC9DWBFc2/Clnkbe8XuwpBR8WiKDXa pNi9IZrQF1HIhNdP+Az0xWfoC8+j+7yP1+/D6P6n92PcehHzg75iN6CTUOSZhcDD47QwZPgb7dpT IQ0KZW5kc3RyZWFtDQplbmRvYmoNCjI0IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3Jt YWwvQ0EgMT4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9C YXNlRm9udC9UaW1lcyMyME5ldyMyMFJvbWFuL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFu dEZvbnRzIDI2IDAgUi9Ub1VuaWNvZGUgMTUwIDAgUj4+DQplbmRvYmoNCjI2IDAgb2JqDQpbIDI3 IDAgUl0gDQplbmRvYmoNCjI3IDAgb2JqDQo8PC9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJvbWFu L1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAx MDAwL0NJRFN5c3RlbUluZm8gMjggMCBSL0ZvbnREZXNjcmlwdG9yIDI5IDAgUi9XIDE1MiAwIFI+ Pg0KZW5kb2JqDQoyOCAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9i ZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjI5IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3IzIwUm9tYW4vRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9B c2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhXaWR0 aCAyNTY4L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAvRm9u dEJCb3hbIC01NjggLTIxNiAyMDAwIDY5M10gL0ZvbnRGaWxlMiAxNTEgMCBSPj4NCmVuZG9iag0K MzAgMCBvYmoNCjw8L1RpdGxlKExTIG9uIFRMUyBhbmQgRFRMUyB0ZXJtaW5vbG9neSkgL0F1dGhv cihSYXBwb3J0ZXVyIFEzLzE2KSAvS2V5d29yZHMoMy8xNiwgNS8xNikgL0NyZWF0b3Io/v8ATQBp AGMAcgBvAHMAbwBmAHQArgAgAFcAbwByAGQAIAAyADAAMQAzKSAvQ3JlYXRpb25EYXRlKEQ6MjAx NDExMjExNjA0MDYrMDEnMDAnKSAvTW9kRGF0ZShEOjIwMTQxMTIxMTYwNDA2KzAxJzAwJykgL1By b2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAwADEAMykgPj4NCmVu ZG9iag0KNDAgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gMTE0L0ZpcnN0IDkzNi9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDE2ODI+Pg0Kc3RyZWFtDQp4nJ1ZS2/cNhC+B8h/4LE9FNLwTSAIkNQJ muYJ20APQQ9rW7W3Wa+CzRpI/n2/kUYbJyWptS5LacnhvD5+JEcmqlaZoBwpqxW1UVlS5JKyVmny yhqlfVDGK6OtsmiSUxajLBqMShgCaTvM4ImUa5X3WqE7UFLOqJBa9Kto0XgV+S2oBC3OqZS0cqwW Pb5VRBrzJLQhKkxC2jhMijai3yoyMMcbtDDCO0UWwi7C3tYqz23UCtaSN3j3aBPBDEUBFgfMH9tW BchHmBAwf2qT8tCXMDh4pVuDfocW88AEDUUqBLQ8DwKiMU8kpQ1pFVu0MApDtdXoT2gxeYS8Q0Qj xruYVIS8R+DggvYJ8ohoYN8hHxEiDNERRiIUOumooEonTB6jMi3mgauGWvRbtIhnQjY0tSpxShCk ZJQxmIfgmzGYPSWFOCE6rcYDulnaOJgA7cYjVIg3HthxvJigOQOYNcA1ajFtNDwG80aWhi7Emwcj 3y08R5rwwHElA7gAF4TEW0KkiAALbfmfgIfE/0DKABWkWzwgCkQMH0SWEDXrADlioDlONDHG2HbY ZEMriORwkWbcIR6szzKMSEMqWZ7HAHbsrUPLOGAYac09ERBseSxjkaFmGI0cAwMhKMUDMOSIUQVx x7CA+86zOC8Mj0QQ8O8CMM2AcHEQx8yRTTZAcoJvBID7FqEmYNu3yBQxWjnWhIB4AuYAWOC65QSh hTSEvUHGYYO3QBKM8gHxgRofeHYsysCuP3nSfOB12qrT5qz50Jx/+9w1Z/vd3eX+xaa7bV5/VO3f qvlwrQyPefr08aNRxIvI+UlOxvDyP80JwomKLlqgC66UdJmaLr1Ely3pQpJF8DQbkCHE4r0YljXZ 1fRnJarJMw8XsQ+3i5l78CuV/MJCrah0C1Q6WpgK60dbx4yMhmVN1g9NxQIJVwuLf7hIeLhdvH0O kQgLA+rMKG/HxhUDmmqWx6xIrFrui8nzVZpJS3QVacZXaYay/DmnrMgzB8Gzz6vt/0Sn4c1r7HlH 52/Ii4RMvOFjUMndKntQllZ9nVZ9cbuYMd0XMRuqhENZXvSpamUoMk7QVWVZRp1TVtwiZkIyOi4m ZY2tEghluTjYurG+qKwOlizDzSlbCpbRcTEpJx/rmMlya6inMZYxMwnOLuR4rIOj/XxzKDloqw5m aTGauoNFnoi+pkxnaXFO2dItanRcTMoqru5NOnsujXUOT8XNKVU3J51l0DllxZzPRWYk/1TEaapi RmeJNNXTmIqYSXXMZIl0TtlSzIyOi0lZxXXMZIk01dPIl+2CNr5t19RlqXRW3VLYjL5PRuXtrQMn y6ZcHagbXIQOVxhq+rLny3l9S9Ej7k9m5ZXXAZSlYy5cVC2mMoKoiiCTZeQ5oSwzzhupx+BQ8ZTD JZua3ixJcsHnuE3VGBEaxrx//udp8/7iX5x+hv7MxMceu43NWPNmvf2Uj4MsI11J2tEuuWODx0W0 MfxR1FdW8VwmnUxVgfnRsfPHry4J3IjOyeGhvlcyQ9cBlecjPcMPusxHB9FZt48+4IkPQ4myREuH w/PqYtNlPZX6x5i4sTYg10q5p8ndRA7iclKVs5kcRGTXlQ1m4tEp15PzVQNfrq/vdl3zbLP/Zb2/ +63fXP2qsvWabGZMPZtZ7qzL2Hyhsy6Tpz8z3QffPO+vvuWLlnnBiWzfvMpfW8t8eTC0rDN7VpvX WYb4oVpa1pk9ss3rLG67ZOKszuzJa15nsXj5PbR5QdnMjCxOWWBULoLPgCp7lKvLCHZH+jtShhbI 6AUyJi9zOFesdvusmOwsWjYrPVGLUL9ppZUtwMq7nd6FkqykxQqO72/8o8bzXded9v2+Oe033dvV ZyXrF5Z126FXGSHrj+Iru3Tofdd93b/uvqnpTPESc237fde8458X26vvL+cYetF/bc66y33zR7e6 6nbjM8tMz6+2m/W2O7tZsYX8x7MtZljt1/1W3nf79T8rPAxvf/W7Txd9/6k56S/vbmHT8M+Xm67b j8F9u7rc9ffef7/B7733k/Vq01/f++Nss77q7o0d9WDY9W51K8Qtvr67u/0C+CkjWTkcKvTwkekQ 8embkHyukS8pP344kJr+jwVpKfJK/VUqo1KelMKhVOakZibVKKkTSQVGiiJSrpBCglzR5fIs11K5 ME5XsemONF09pivBdND++Sx770Q04VbGacGllvF6wrefwbfMO60H+ZREU8Qn3GvhTI717CJ4/Og/ pAjc9w0KZW5kc3RyZWFtDQplbmRvYmoNCjE0NiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAyMjQ+Pg0Kc3RyZWFtDQp4nF2QwWrDMAyG734KHdtDcdJdQ2BrGeSwbizbAzi2khkW 2SjOIW8/2QsdTGCD/P+f+C196a4d+QT6jYPtMcHoyTEuYWWLMODkSdUVOG/T3pXbziYqLXC/LQnn jsagmgb0u4hL4g0Ojy4MeFT6lR2ypwkOn5de+n6N8RtnpASValtwOMqgFxNvZkbQBTt1TnSftpMw f46PLSKcS1//hrHB4RKNRTY0oWoqqRaaZ6lWIbl/+k4No/0ynN1PtbjPVf1Q3Pt75vL37qHsyix5 yg5KkBzBE97XFEPMVD4/CUlvKw0KZW5kc3RyZWFtDQplbmRvYmoNCjE0NyAwIG9iag0KPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1OTY3Mi9MZW5ndGgxIDIwMTcyMD4+DQpzdHJlYW0NCnic 7J0JYFTV2ff/597Z9yXJZJ+ZzGSbkBAmLCFAmKxEQiBA1ARRwhYBEaOgdaugdY0brdYqbRWXqtVW J5NWg7ikalu7WLDVuhawaqtWhfpW27rd9zlnxohvS7/wfp0vX+X8Jud/tuec89xl7twzufcOGIBs Eh22NC8+as7JbQ9HoHx0LuA7d05zS+sq14nzoUwaBpQb53QuWPyqK2qGMrkb+N7FcxYf3fiTb6+9 BMq+fUDe2XMXd7WeHFlroPZLqdfCeV2L255Zc1MzUPwWYD9uweKJ0azes2+jvkxU39vZNK/rXN+F H1D/Wyg/9Zjmju7F92zwADVtgPvalScv78ecC74MdtGF1OZrK8/YFOh/98/HgN3cCZhK+vpPPHlN YPmHYJdmA/p3T1y+sR8ZIP8m9VN/rhPXn9V33KrGN8C+eyZw/NI1q04+c9E893ag+SWw2J1rVi9f tWfZj2MAu4KPv4YKvDr7Vso/TvnwmpM3nVl5lOMEGnsNELrwpNWnbfhkG3sNSpD8YXetP2Xl8qK/ zHgMiuFpIDd+8vIz+7PmeR+hutepfWDD8pNXl3e/8jiUUDXgKOw/ZeMmLQyyn9TJ6/tPW91/0oYZ S8GusgHeBvBtoXe/dfdT5+xZ5pz5nimHrybgllemtPL4iUdrFnx42cdXuGCaQrZmYc+h2Bj8pAXH uvDhZR/sdWG0JoXuJF5iPxYdUEWBAhcm4hhai5fTuBxVXac8CD1M+m36GuqgOBmr29GneJheUUyq Ua9XVN0+RLQRnMlbmXnDro6mAOgV8OpP+qSV1RiDbGcMTNM0an2Hfh5fUugM01l+cuBUuAv36k5F /GAvDXdhEZJ1iyjkfFpO9o2Uj1K8RJkORQfMpXAJhSiFIIUaCi0U5vF4tB2NgUOg/ymtgWS8kEKe /hiU615BlWE6FovVUYBy4dN0VFFdifFKlJNdAeU7yW4yjylfotuIdVQ/l9LV3J62mGd0jGMQPNT4 5OdSaluhXon5FC+geAH520jlHZRvpeWMjC7HdFTQupnHy8Wyb0Sp8PFKtJOfC6kd92M21XkP6t99 qLEl/zt00PaPtw8Hc/A+IpFIJBKJRPLvhl2nPTDePowV3R/+c3yVSCSS8YRBe8BEwQV53JRIJBKJ RCKRSCQSiUQi+c/GfqyRMfZ1A/jFDAaKjAaj0ZACyEhaFSPX4F1Uj1rMzuhy2hfN9jkKM/jlLS8k 6+fNy56X/fX8eROBKVfOmzcPU3IN844GbkiHy4Yx2BSnY2DJFwH2fzb5lPL0eXHEQUeZ8XZBIpFI JBKJJO2oUBlHr6pMofOfbP1b1hH8zaTBBLP2CcywkFqEWmEltcGmfQy7UAccpE6hLji1j+AW6oGL 1Au39iHNzzykmfCSZiGD1Cc0G5mkOcgmzSX9AHnIIc1HLmmB0ELka3+HHwWkAaFBFJIWwU8aQkD7 G8IIkhajiLQEIdJS0r+iDGHScpSQRlBKWoEy0gko195HJSKkVaggnSi0GhO09zAJlaRRVJHWYCLp ZFRrf8EUTCKdiijpNKG1qCGdjimkdZiq/RdmCJ2JaaSzUEtaL3Q26rR3EcMM0gahjZhJ2oRZ2p/R jHrSFswmbUWMdA4atANoE3oUmkjnopm0HS2k84R2oFXbj/mYQ7oAR2nvoJN0PxZiLqUXoZ10sdAu dJAejfmkx2CB9jaOFdqNTtIeLCRdgsWkx5G+haXoIj0eR5OeIHQZjtX+hF50ky5HD+kKoSuxhHQV lmpvYjWOJ+0TeiJOIF2DZaRrSd/AOiwnPQkrSNdjJenJpK9jA1aRnoI+0n6cqP0Rp5K+jtOwhtIb sZZ0k9DTcZL2B5yB9ZT+Ek6m9JlCz8IG0rPRT3oOTtVew7lCv4zTSM/DRtLN2ES6Badrr+J8nEF6 Ab5E+hWhF+JM0otwtvYKLsY5pJcIvRTnkl6GL2u/xwDOI70cm0mvwBbSK3G+9jKuEno1LiDdigtJ v4qLtH34mtBrcLG2F9fiEkp/HZeSXofLqOQbGCC9HpeT3iB0G67U9uCbuIrS38LVlP620BuxlfQm fJV0O76m/Q434xrSW3At6a34OultQr+Db2gv4XZcT3oHbiC9U+h3sY30LnxTexF349uk3xP6fdyo vYB7cBPpvULjuFl7HoO4hdIJ3ErpIaE/wG2kP8TtpPfhDtL7SZ/DMO4k3YHvkj4gdCfu1p7Fg/ge 6UP4PunDQh/BPaQjiJP+CIPab/Go0MeQIH0cQ6Q/Jn0GP8EPSX+K+0ifwP2kPxP6cwxrT+MXeID0 l9hJ+qTQX+FB7TfYhYdId+Nh0qfwiPZr/BojlP4NfkTpp4U+g0dJaTTSZ/Fj0udIn8Lz+AnpC/gp 6Yt4gvQl/Ezbjd/h56R78AvSvUL34ZekL+NX2i78HrtIXxH6KnaTvoanSP+AX2u/wh/xG9LX8TTp G3iG9E3SJ/En/Jb0LTxH+jaeJ31H6H68oP0SB/Ai6Z/xEum7+J32C/wX9lD6L9hL6feEvo+XSf+K 35P+Da9oP8ffhX6AV0k/xGukH+EPpB/jj9rP8AleJ9XwBqk8pstjujymf/GO6d+Sx3R5TP/CH9Mn fAGP6fvlMV0e0+V5+v+Hx/Rnx/GYDjriwr7UmmWGqur4f5LN0OkAVaeqn/3XW5f8+oYO/iaDgQxg MlpMFgpGg4kO/TAm6w0GvcGgMxjJXGcxUkO9XmfUj+0f1IfNWDrVpWNgyRcBZeymxvR5ccTBrFnj 7YJEIpFIJBJJurFli7kVP4u0/Mu5ldlo5HMrs9Fq5nMrAlY5t5L8xyHnVuOCYssebxckEolEIpFI 0o091/Lp3Mr66dxKZ0wxOkcxfza3MtHcymQx87mVXTyKnCNmYtRsdG7Fc+maW43ljFfOrSSHQB27 qSl9XhxxKPbc8XZBIpFIJBKJJN04C200pdLzs0g79DQd0ul1OlMKQJ+0ssJqtZitNFeyWZxWm9lm NVmscKR++YqmOyajyUTN+NzKxhsajHrePC1f/I/ljFfOrSSH4DDmVub0eXHEoTgLx9sFiUQikUgk knTjCoi5FT+L/NdzK5vFbBNzK5eN5lY2M82tnKNnnyY+t9L/49wqLV/8y7mV5P+Cw5hbWdLnxRGH 4gqMtwsSiUQikUgk6cZdZP90buUQv+CgM1AuxehFfVbYbFarg8+trC6b3WqnuZUNrtGzT5OZXtSM zA0O3tBkNJjTNbcay38T0nIxouSLgJxbjQuKu2i8XZBIJBKJRCJJN94SJ/R6vZWSLjG30hv0ekuK 0f9b2eFw2G1OGOGweRxOm9NhtdvhBX9UIMdiMVvMBouFzPVO3tBkMljMabqoaixnvPp0DCz5InAY /9K0pc+LIw7FWzLeLkgkEolEIpGkm8yIi+ZWRn4W6QF/eoXeqDdYU4zeMOWE0+lwuCjrdnidLofL abM7+c+S25P1VqvFajFarXxu5eYNTSYjb56WL/6tY7CRcyvJITiMuZU9fV4ccaiZkfF2QSKRSCQS iSTdZFd7YTAY+VlkBvgtUgaTwWhLMXpRnxtut8vpgRlel8/tdXrddqcbPj7pEvDLBK1Gm52mYkav 3WaH1WyyW9P0xf9YOpVPz5YcgsOYdjvT58URh5pdPd4uSCQSiUQikaSbvKmZMBrN/CwyC/wOK6PZ aHKkGL2oz4uMDI87ExZkenIyMt2ZGU5PBvL5dYQCfpmgzWx38lusspwOJ2xWs9ORpi/+HWOwkU/P lhyCw5hbudPnxRGHmjd1vF2QSCQSiUQiSTcFdT4+t3JRMhv8DiujxWhyphi9qC8DmZleTxZls735 mT5PVqbLk4m80bNPh8vuslucLj63ynY5XDS3srgcY5sGHTZj+W+CnFtJDsFhPObEkz4vjjh0BXXj 7YJEIpFIJBJJugnEcmAyWflZZB74LVImq8nsSjF6b5MPPl9mRjZlczP9vpyMHJ8n04cAkJmsd3kc HofN5eGPr8jzuDxw2KweV5ouqnKNwUb+MpHkEBzG3CojfV4ccegCsfF2QSKRSCQSiSTdBBtz/3Fu 5U5x0NwqOzsrIwd25GYFsnMzcrI9Wdl8bpWVrHd5nB6n1Z2aW7k9cNqtHvfYpkGHzViu1JJzK8kh OIxb8eTc6t+HLtg43i5IJBKJRCKRpJviuQUwm638/09+8KdXmG1mizfF6HMj8pCXl+MroLlVQU44 r8BXkJeZk4difh2hwJvpynTZvZkWwFKQ6cmEy2HL9KTpoirvGGzkLxNJDsFhzK186fPiiENfPHe8 XZBIJBKJRCJJN5GuIKxWBz+LDIE/vcLqsNoyU4zeMFWIwsL8nCBcCOaXFQZzigp9+YWIgD/OgpPp 8/q8jkwfTcVsRb4MH7wuR1bG6CWD/17G0qn8ZSLJITiMW/Fy0+fFEYc+0jXeLkgkEolEIpGkm6ql YdhsTn4WWQL+9Aqb02b3pRi9YSqIYNCfF4YHYX9FMJwXDub6g6jiky5BVk5GTobDl83nVuFsXw4y PM5sX5q++B9Lp/KXiSSH4DAuF81PnxdHHIaqpePtgkQikUgkEkm6ia4qhd3u5meREfA7rOxuuyMn xei9TWGEw8HCUnhRFqwOlxaWhvODYUTBb7ni5ORn5We5cvL5Y9fL83Pykel151PznHS4PJZO0/KA QskXgcO4XNSfPi+OOAzRVePtgkQikUgkEkm6mbo+AofDw///VAmPh2YlHoczL8XoDVOlKC0NB8uR iUi4pjQSjJQWhksxhV9HKMgryC7IducVOAFnRUFuAbIzPQV5/D6tNDCWTuWvvkoOgXXspsH0eXHE YZy6frxdkEgkEolEIkk3dZsq4XR6A5SsBn96hdPrdBWkGH1uRASRSGm4Ej5UltZGKsOVkUBpBHX8 OkJBQSA3kJtR4HcBrmp/fgC5Pq+fmhekw+WxdOpKx8CSLwKHcSteOH1eHHEY6zaNtwsSiUQikUgk 6abp4slwu33FlKxFVhbgznJ7i1KMPmO9GtXVleWTkYvJlbOrJ5dPri6urEYjMCFZX1RcWFzoKyqm qZh3anFRMQpzs4qDVJ4Ol8fS6VieJSg5IjmMW/HK0+fFEYep6eLxdkEikUgkEokk3bRfVwevNydC yXrwO6y8Od7MkhSj9zZNxdSp0ao6FGBGtG1qXdWMqZHoVMwFJiXri8uD5cGckvJMIHNmeXE5ggU5 5cWj/9b69zKWTtPygELJF4HDuFy0Kn1eHHGY268bbxckEolEIpFI0s3i2xuQmZnHzyJbkJ9Ps5L8 TF8kxeiT0mZi5sxpNTEE0DCtc2ZDTWxm1bSZWAx+yxUnUlVcVZwfqeKPBmyqilShOJBfFeHXEqaB sXQqf5lIcghcYzetSZsTRx6WxbePtwsSiUQikUgk6WbpcBt8Pj8/i+yA30+zEr8vtyrF6JPSGtHY OGv6HITRNuvYxrbpbY01sxqxlE+6BFU15TXlgaqaXCC3o6aqBuVhf01Vmr74H0un8peJJIfgMH7P ujZ9Xhxx2JYOj7cLEolEIpFIJOlm1RPzkZMT5GeRixEMAjnBnPxoitEnpbWhra1pZgdK0dF0Qtv8 mfPbapvasIpPugTR2gm1E4qitflA/qLaaC0mlAZrqXk0HS6PpVP5y0SSQ5AxdtNZ6fPiiMO+6onx dkEikUgkEonk/wFqKuSDifzTlKMUewE68O+aIwhQyoIilKAc01CHBszBUTgax2IJ1qIfZ+AsbMf3 2SRDLODVNPDfvSpBGSYI2yaybRe2y7Eep33eVnvlX75W0uu2j+L7bkz5NkaYAaMNmKIAyv80oEXW 6cF/SdZqA5wut8ebkZnly87JHX0QYRglpWXlEVqKqonVk6I1k6dMnVbLH46YOuVubmmd03bU3PZ5 wILOhYsW4+hjju3uAf7tv5GqCh0ci+kzB6X/Y7derPHortjs+lkzZ9RNr502ZXJNdFL1xKrKCRWR 8rLSkuJwqCgY8BcW5Ofl5mT7sjIzvB63y+mw26wWs8lo0OtUhWFCS6i1NxAv6Y3rSkJtbZU8H1pO BcsPKuiNB6io9fM28UCvMAt83jJGln3/wzKWtIyNWjJXYCZmVk4ItIQC8SebQ4FhtmRhN6WvbA71 BOJvi3SHSG8VaTulg0FqEGjJXtMciLPeQEu89Yw1Ay29zdTdoNXSFGpabamcgEGLlZJWSsV9of5B 5qtnIqH4WuoGFZjs5FQ8N9TcEs8JNXMP4mpxy/JV8c6F3S3NecFgT+WEOGtaGVoRR6gx7qwQJmgS w8QNTXGjGCawli8NLg8MThgZuGLYhRW9FbZVoVXLl3bH1eU9fAx3BY3bHPed/Wr2Z1nq3NPUfcnB tXnqQEv22gDPDgxcEohvX9h9cG2Qa08P9UFtleLW3oFWGvoKWontiwM0mnJRT3ecXURDBviS8KVK Lt/qUAsv6V0XiJtDjaE1A+t6adPkDsSx6KxgIjc3tkPbh9yWwEBXdygYn50X6lnenD+YgYFFZw3l xAI5n6+pnDDocidX7KDDmUrY7AcnVo/WiZQw56n2RaNrlnGPQkfRDhEPrAyQJ90hWqZaLqtrMbCy lsyIHkat4qtoi6yNm5t6B1x1vJy3j+uLXaHAwHugPSD09lufL1meKjEUu94DT/L9ZHRXo/pP0/GK ingkwncRYxNtU/KxXuSnVE44Y1i5KdTvClBEqw+dtG6X99RNpNUfDPINfPlwDCsoE9+ysDuZD2BF XgKxiRU9caWX14x8WpN5NK/Z8mnNaPPeEO3JPxDv9cy4qWT0z+nK8rasqYuzrH9RvTpZ37441L5w SXegZaA3tW7buz6XS9bXjtalUnFvU7eap6RSSp4qammnXDpqzDPdtriumP4MYqdeNWw00V4pSlig Ne7qbUtqjyUYHGOjYe0AbyWiz5ql3IzXVXw+P+Nz+c+5ZxtQyWFdidLetWRgwPK5ulY6Ag0MtIYC rQO9A8uHtS0rQgFXaGCHWqqWDvS39H66RYe1By7Pi7de0UMLsYbV0d6qoHEwxC5dOBhjly5e0r3D RUf3S7u6EwpTmnobewbDVNe9I0AHXVGqjJbyXIDn0M5oT08oJlGVtyMGbBG1OlEg8iuHGUSZ6dMy hpXDSrLMJcoI/kZv6uo+eBOK90VPJX26dQWGdbYhmyPK44TXFx3WWYfKAn5ng0vnwRYKCpyksyks o6AKZYjpPIkza2LDFJ2WjDYko3XJqKsm9iAZzkWNNqLzDPmyo7x4yGKLbuGxyczz7sSSmliDWefG McLOjcXJONFZI6o7eC9u+uAUpUPNLclWjcni+pRxXY2/IUz5AIUYhX4K91I4QMFA3rsxkcJWChoF nchxu80UrqawncI+bit6M9U4G/J0LqpxiWV3wU9hIgUVvTozLXtcqFNnorViwgIKN+mM0OksCaz3 76BO1KEW4ak6VFEl4kRZeVRUJHLzow/RJ+UNKIWfClgiK0/UINHYmEpMrU0mhiKV0b0NFh2wn4Ki g47R6YFoNVRWFT3wCOWZ+gmcjPFS9aMhVwaNpn485PRGYw0u9e/opKAgrg5ihIKCU9T3sJmCQub3 Jion8YHUe4csjqiL7PcjQGELBRXbSZnIxyhw+/1D3ize/R8TTrdotzdRPTmZGHJlRzsbMtSXyJ+f qb9GCH719xQXUvxTigso/on6BOzCz9uGnK7oFhrvVjK/VT2Lzo/86nfUsxGl+E71POQJs+cTjuQ4 zyfKItEGi3qHeq4w2aieiskUr1dPSkT9gZ3qbXx/VN8aMlu5f28lXJnRh9Q31JOQQVavkpXP73xI 3YCJFPiSDA+Z7dGtDTZ1mBZzmFaLn3xkuEloTP11gjqi8b6rbkEW1e1Sz0cmxXepFyQy/SM71b8K s/d5LzTeLbTH8GjI7oiONJjVW/geor5La/xdMdpfhkpqo2goUa9ANQWFVuorlHqFUi71HUq9Q5vp Hdo079CmeYe8eId2WqhvU83bZDNR3YN+9UVspXATpXXU5VkJWoM7RCJcFt2hflk9l9aEayetO0al 5w2ZHdyzcxMerzA7l7/BZz+kPosFFBRy/jn+jjxlp3qVWJStQ9l5vMHTCbONVt05yW1BDc/m2+Ah dYt6gVgT54s1EH+YsrT/q18RjbUhmzu6mbZ+F2VPIb2awm4K+ynoyKyLlqELyyioZN455HBGnTvV JaLxUQlHjf8htY0WvU2srbZEZpHweU4qoXMm8gqjD/MEKulDLKpz6AyJif6FO9V22n8WqPMTq/zk +8IE9csbzh+qrYtW71Tni3UxP+EPJYsT3hyRaE2Yk/tV05DFzT1pFoYVCZNDFFek3pJqZCjDF/XT flonlrZGzF6m0eabRptmGr1PasTGiA65PLT3r1KjYomi6KWwnUKcgo62cZTMo7SNo9gnSpzqVFrc qdAoqLRtp+IABTrUqJMwm8LVFB6hsI+CXpT2UlCovJpG6CXdSkGhHidS3kUao9BLYQuF7RRGKByg YMQutZLGqSTratItFOIU9lLQ0baaQH5MoDqPGsDHJn655Gblhlgd24zNbLOyWd2s26zf7NrsNsWm FE+IxtZxqeJSRjKt19xv3mJWq80xc6dZdZkDZmVYG0kY62ooinkMdTUvdLzZ8UGH6pm21bDVqOxq sDE39lLYT0HFLuainItyrtgl6q76vfX769VdHXs79neou/bs3bN/j7qrcm/l/ko11pFXF522jJ3C NrOrmc7PJrLZbAHTLVNPUTerV6s6vzpRnU37gq7X2m/dYlWrrTFrp1V1WQNWZat1uzVuHbHuturj hhHDbsM+wwGDvtPQa+g3bDFsNWw3GPzGicbZxphBd6ChSXmRVup20jgFBVtIt4qUS9SMkO4W+a0i 30vaL/Ix0k6RCpFW8xSFEPX1AtltId1KgdvxfIi0mucphOjo/jyV9ZNupaAoz8fyi6rDsbDiCgfC CsLsQJjtDu8LK/HwSFgZaahTnhNePkdePie8fI5aPifGfo76pRSFEHn7rLB7luyeFXbPkh1P/bOy XtJ+kYqRdopUiLSap5RnE6Fpzgaf8k3qcRnpTRT2UlAxkXQ2hVNEzs8tlG+SxpRtQ6UT6ANf2ZYo oWMkRUXJqDAZ5YtoKCc3uqzBqWyjLrdRl9uoE57zU5jNc9qIckOimdvekJiVjOpq9jZMo09R7soN uJeCggWkN4nURNLZInWvsHGO5uOk+0Sqn3T7aLtlIuUn/bStqmyj1w2UcipnU+nZMasinjoKj9vk GVYeSKz1+IeVHyTKXBQNJaMEjxq8ikrr3s7eEXqP0JuEXiv0WKHOmDVk/3vI/uOQ/Y6QvcGizEWY ig8IfUPoupgjbH89bP9J2H5r2H5L2L6TvYIiqgjGcovsrxXZf1dkv7/IfleR/Zoi+9Ii+8Ii+7wi 3lUZArArBVzZCULzY76A/aOA/eWA/RcB+xMB+80Be0/AXhcgc/YufZ7a2beEfkPolPsn2/2T7QWT 7Q8odGRixyWcMO9UFHYc7KolEan3D6tmESnBREcxRfmJjgaK8hIdiyjKTXScRpE30XGNv8GsONkg naz4FQcbNPHYloicT9XWZGRKRE6gSJ+ITPcPs08SkRBFHyb6Cij6INFXSNH7ib7JFL3HowfZf6FP oW7YnxN9N1L37E2U8W7ZH1Gi3E3xcKJjNlnfnxyd/QD1rJiKaVrFvWDfS0TIOXZnIlJG0R2JSJii 25PRrYmIn6KbE31VFN2Y6LuGom8n+l6laFuibD3v7waUiX6uR4mINyY68qj61EQH76E/0TGRolMS HVMoOilR/yRFaxP1r/KmJ7JBRns260NEeLo80Reh6mWpBTkeZaJ6KaaInuckOvgqaeWdNNhZS2pB mlkTP+djjWxQ9BJLRKrJrD4RKaFoVnLNzUz0VVBUmyijdcymJcpupDU3NTVAOd8+D7IwucE7CiUi d5ORP9FXTlFhoq+Fojzekpzypkb1oF445U5EuJUrEQn4H2ZW9IkeLShh2+7zf0z9flg/zI5J+D+I DZtYwv/XMoru87/VscL/p45hOuP1v0lv4bvv8+8l0z31lIxZ/S9FXvW/2Ffk/3mELGJ5/p9FqvyP lZzlHy7b6R/qKPQPkmPxvhX+e/tED/eUULOE/86yYYVR6+198/zXRyr83ygZ5j58jYwv4WNQRxdF zvJfUHK+/3TaFTZ1XObfGCnw95ed4F9Xxgfy+ddGFvnX0IKcSG1W953oXx65xt87RXh8QuRJ/+Ip Yhna+8QSHVUvKtr6FvlbyQOqmM0ryIMZtF9GqWnVlJ18HdGZStPQk/6jpz2o0Kcw20LhtFiV8SHj ecYVxi5jI33elBqLjUFjoTHD5DG5TA6TzWQxmUwGk86kmGCCkjGs7YtV8K9MMwwuHhl0XHUi7VK4 8m9X6ZxEYSaFJlpxr9qutC9ujE+raB82aovitRXtcVPncd2DjF3Vw9rjIyvRviIQf39xaJhZaBas DzWyuKcd7V2N2WQcVy6l6WRX9zDTeIuL8vhXSzvA2ISLrszjcetFV/b0IOuM2dmzPfXu6a3N/0R6 U9rSXPEZ2RUVn8sVxK9rX9wdv6ugJx7lCa2gpz1ezr9+2qGsV9a1NO9QTuJRT/cOtkZZ37KIl7M1 zT1kNkOYoV45iczQwSMyU5ainptR+dKDzNggFTcP1tcnjRawQW5Eb5oFwmhJ0qjpYCP1ctYkjJrU y4XRjckBI+QHDRjjEZnp1yMiBozo1wuzbG42WFJCPfWVcJPBaAkZDJZERfXCz6rLktXfT1Z/n1cP M/ZZ/ZSSpLdlKBEjlChlZFMxjqxu/F80YkOzztjQzb827A21rKbQG7/8jDXZ8S0rAoHBDWekvk8s 6V2xcg2Pl6+OnxFa3RzfEGoODM7q/ifV3bx6Vqh5EN0tXd2D3bHVzYlZsVktoeXNPUPzz6899XNj XTY6Vu35/6Sz83lntXys+af+k+pTefV8PtapfKxT+VjzY/PFWO2LGll7Z/egCY09TUuT8ZBitdC7 pTcv2NOY5eqvF2+dGcHs8/Ie0IHdCWtFT9wWaozbKfCqyobKBl5Fb2le5eBfDaeqss+bEcx7gN2Z qnJRsTvUiE3ZLWub6W8jsWnT6QSt440bk+s6O1mxqaJF1JPBJkptEpAlpXnYKEpT9Ztw+mdUVCRt sbGiqXuwo6Mle21zHp3ED/Hz7oqejaioSA5YUQEak5ZanOhniRN9qyGr5pmO1zre61BHxBn+bgr7 xBn+CJ3d76awj87wC9WR+t31++rVkY7dHfvIds/uPfv2qCOVuyv3VarTUh7woXoYefjZ6/SKjafz 4gomllYsN3eEnKYEX+pPV8NGUbFJrBgiWS6aVlBHFaPNKz5LbExWni6aJEs3frYPUwXvftPpFf9I qpQOwfqr4NfPEyFfvZb/VrH2MoVXKbz+yVztI/1JCH2yTtuneulwHU6GFMW4kE70Xsd1eATH4xd0 3tjCqtANHctGDh3Yp6OdVp8Pevp4LaOzxnZ0IpOO9a8xO+7FJLzJWnE+fTgvwLfovHA+TdIb8FVs Z3O0N3A+fsPW4m5qfSeLoRTzWJu2FwvRqd3P+D1oM/ANbGMO+rCaxywspO2hHjbiEjyA30LDElyv 3069dGIRNmj3YymeYkvYcVo+jsIGnIfrcTMewqvsUjai02u9mIIVOI0ZmZeVqRdod6JW/5z5h9rj 2m64yP5m6vUtpULXqr2DGF7XMW0N7R5e1NBrA27BfXiJZbMpahMcdPq5lNbFubhXLSMf23AZLdsD 7Bx2r+rQbqOlmYaV2Ey71JlsRAnqn9Mf0M6Gh5ZvMnk6gNvwIzyGP1FvraxLPfmT2dp8+ow0oQIt NNKFuBj30Jp7lF6PMycLsqOo5x+xPexldYP6B+r5DryN9/E3VsbWsvOU2coF+ujH52s/RAktYYz6 OArHYj2+x0pYjB1Hbb+lfEk5j6bK96kv6cp0+7Va7TEYQFNyXIC7aLl+hd/gWdperayD/VY5Tx3S X6ydQ/5OxBpaigvxHezAe0zPzMzGMliA1bBptGTnsBH2slKghJRudYV6r/4K7SztSgRpXzkeq6nl OnwFF+F+7MLv8Se8zXKp5URqOZt1sitpivy4sks9Vl2qXqeL6a7T3a17VPeR3q1/9JOnPtlHa533 U40Oeh2PPpxN63qYXo/hBaayPFZIPc1ic6mnZayPncu2sq+zW9nt7D72U7abvcH2s78r2coVyrXK TuW/+foS+Kiqs+/znLvNPnf2PTNzZ0syyUwgCwkJmQtJ0ABhcWORkUVWUSGIICotrhGslYrK4oZV EGtbkHVwgyLuKFrrq59SxZZit7y1XyO2Sibvc+4ETfu9v4/7yznn3rlz59znef7/5/+cOwmv0BP0 XS7EVXLt3GPccT7Kf8x/K83pDxUPF/82YBxID9QObBh4eOCTgV7NC0GM+Bxpw+haQtbi3W8gD5BH 0Ob7yNvkA4y7z7TtNPkSffAtiBhNPpyRAjFIQRXe3VSYBqtgPWyEJ+FV+BxOwzlKqIkquFXSBjqO zqS30r/Sc5yBi3GjuRu4TdyvuW/41cJw3J4R9gtfiqelhO74uYf6Py2S4uLig8WHBuoxFkWMPAdi ro6MwZgbh16eR7pxW05WklVooxvR4g9j5Owie8jz5HVyHG1/gnxCTmrzZduf0BN9pJ8UgaI/BdDh Vpp7DXqmDaNlNsxH35a2m+BWWAebcXsIHoXH0b7vwa/hffgMfg9f4T0RWk1H0wvwjibTy2ket1n0 SnoLvZvuw+0d+l/0E/o7+g0nczYuzKW4Dm4hdxe3ntvN7eN+w33AJ/nR/IX8Ev41/j288wuFTmGW cKVwt/C48IRwVHhTOC0MiBvFn4oF8Y+SQWqQJqMsXSc9LT0vnZQGdCmMpy6c/dD/VWAjXM5n6QYY oAW875foCu4tej88M/QJsrAeZzAPi+kC9yJ95OYN3O+4n9NbCeHbtZdHIYsdJy+Q48L7vEv4I3mN +sl/Ix/ez82hL2Gp7YUGrpm/gz+OrLMa5/kE/YxKdBee8Rf0xixyKfjI/+UvI39D+58Q1qNNx9JP 4Rn6KpbOefIReZI+T7CoJ/NhBM5uHtlPviE/gUNcBA5g3P2QvEv+Sk4NeVCf7R9Dc6KXrhRHoocO wZSB12jFwF8Q9Z/DHeQT7huM/ctgImTJDvJ79PoHUAdhvsgHyHvIfGXkIYzaL8hexOCbfBwR9BU5 xNWRGfwp9Hm2/41iu7CCuw3O0tHoTo/G3JMYGyMHb0auYjxqIbswEpBFNET/hbwNClrxffFjspXc S57jXCTBbadr6QD3Oh8h95FT3AT81DXIT0GowytdQxbjfUQGzhSfxCtcRRpJI8yFGaQdX7mQlA1c gzPfgVykDswc2CJMF9LkHZgALnIY2cuLVnxQ0Bd78cx9iMNPyIVwN9lbnEeOYF7xQgKGYzT1CiuF DcLPhH3CS8Lb4jByA6L2IfTi70gfZo0IXIm2+DP5GmN9DKKnCvEzGmdxIeawq+l07kXSBn6yDDmw HHl7DNpgBnryOrzKreRHiKftmEPeIV+CjBXvS+QjRI4HcX4lfr4OrzOeXIpev47sQHa8DfbikXmk jFSinb4BCzTSFfh5jGcfRJ49gnM6Sc4gcwxo86qCZiyTL8Nrfc2wjJ/QQCZjPUAGDpAmzJTt3HHy BxLH7DoGMfokvm82xoaFhEiT8HugpKo4caCRLuZeBDdmQwtG1SWY2UdBN87CivfRT1wwidQXL8Cr PYNcNlnYjtk3jZnBRV38VOFSnPfHmMneIcsHpsFWiSGAQhC9GxTYV0skMmYfhZdFqcDpVAcR+Jc5 YpD4l4H4dKLwMuVegNFEj064jHjT8tmW/paJcl9LV38LyeFYPofNsJqoLWpLYANBnpyLcEfOqQL5 lkT4I+ybN7sG/gBMe8jIuj94ke7GW/PTjaSM3rc3pAdS4Hyq39bpMW4o21ZGyzwev8nZ6SeqL1xH jgJoS7g4BpPVH/ZTf5XVFDZRUwEcqv6wCKIv9NEJbxrnlO/qzZ/O25vS2d603DtR7pjffiZPcl39 Z3LDamBs+9j2znaIJVOpZH1dQ+1wt8spSSLHejGmsGNwdZWUqsvOHHfhrOH1QaVt1qy2tllXwKHl P/342KVdV8zqnPDuxyuK781q116ZrS3ivcc9h3dmwoibpQaozu6so7pAqI6AgTdbPDYCkmhxW6il ADeqPqdTAlvPUs9jHurxBww9ER54n//76U+Uz+a7+tGucm+3rakJbPamJvaD00fRGeO+n/i/7+SH LXJOHTV2ohfWDp/vnd56wXg/fQ9uGd/UOvXy+uorirfA2mk1I6ddMSy2iHn8ooHPxSk46xoyioyD kepNW8QHAg+2b297sn1f+7HhUrlpZ5Dubz/a/koHt9pxazttFOdbV1q5HOToSJ7LZrM1qU6u3JSt zma4LMlClnLpimHiMFFsdYacTmdoWEVa5E3NodZOJ5+OiPgi36h3draG+NhYehRqjgIhtsadMRhb oOf2eIyGAu1X9TZjzSyyFM1a4KKq00TZMjuFKtNRqzlspubD/uRz9F+kDuNBj3bO1U2qo3UFOKwa s8255knNXLgZmgv0G9UsR7ZFaGSPdUx4DB1ToN/u9182fuk6Fr29+b58bx6bdK/cn+/vy7eg4TGS e9lmb8q29Mq9Nrunif3A+UGPJZO2rJGP9ViOHUNX5Ev/SD4PUZeFSm6Pu3b4CI8osTBKiYPBNCL5 nYNEPKWhvi6ZSjRgl0rGFNHldHP4BuzwvXgu/2PYNnby2hUL1Or0uJaKi/IXXD7xnvlrTq566dR/ Hff7P991z/anD3Z/vHFkY3H54gubU03Ztsi+ydHsNVu7krMa/86lU4bcmR/PjPvmuB9vr22becn4 d+5+8NMpo28eue2De67ofrzttTPbV1Y2i1empueWddWOyw1bVnxfSTZ2XPHcgmj0a7Z6c1FxAb0P o8JOJqvlPZaDVjqC30zv1++k2/UCHCWc6ajZYTaZ8Nwap1ViTyo4qUAfUPWqDPJljqUPMgOjdZEj ZNw0ow6rIXnIgwvvVRJtst3j9riSxCYTet+iYe3Jmqnj6/J/Lz4LE4UlmfbRM+7ZVXy1+FGxMH9s /fAp8A/kTRWYXvPh3KZrc7tIVRr4HuEua8HKP0i36HfQp/U8zs6Bs0Muk6XI4Kxsk9isnATAZDLX OC5i7u/TJqZNcsjsHPUNI3CzyTSVTNW72ex8i4a1pUqTg0nFZ4sLMh2jZ/xoN4xENX6BNrmiufhC 8VdFVkiRMcUt8CLUsopAtf2LgqTN6Li902Tgx7sKMFY1Qm3YCtbR3l/cw6aR7+vvxQn09YJNAzeb wmBkSIPhUwqcBSsWS0hSplC6eeq8Cy678RfFLVXDH7vYptdJtpmtY+bdseLeT9kMhsNSupq2Irb9 qol+QohfAB/PPmyifFo+Q7JdeK8QrY/S1f2H6AWw9AR714yBL+ApzN5GouwjnaKRY5xqjOhr9FTv MzHATJTPIS0RZikYSpRk7Jy5HR1z5kCd1nV0zNVWAQc+pzn0Ekca1BAaPkc5J8VKkgOgRm4Xm9Qu WsW/0MFswMiOXbol19IjZNIIL/wMlCs0V2xbC4eFJd+sFNaz7DFu4DS3X1jEchqMU336gBgWE/oK j+QNuCKuhLdCL+lglS5UAMMeu5DCbq9otnsKnEFNEDWerCNqOoNNbQM2zaPqVMyZ25ilqu1WJYx6 nZ1pudcMZtXhqjP7qr76O7vxs+nlmE/apqkeRY2n6hR2EYVdRGEXWapANyu6p+OJ2qCrly1RegaO 7MWTPWzFAs/XenwL6/fju2Z7Bt81GH1tq9W5UBmJhqNUtFpkCxXjsUSMikaTwaQ36Uy86HI73VT0 ef3egJcTKZZFPHBiZboiTcUymzKXJCVsgg7PXCgXsIlaQnMhZkrNJV43jtKAI20NjDXn/9LnLaQb usEpWSgjrCTLhyMaWMR53ILM9lkYIlo9jJwQGtz+JuW6+y6b++ioqmi6tfbdFSvfrmkrHucNSV9j 2pfwO62NmeG+SpHueGv31eunzMu3d2954reHtjzx+F3Pn4R5zXcPi3hjz/b/rXhq7gU1kcbrWaz0 YCK6Er3qIbe9QCzwC6gnOth+QJklLZUojDZrRyT4F4kRN2wnVvgaZU49cVOqWqw6IugkEx4MY34o cEhAFstk61LrLisnI8x8XstLlBAdfZV4qQc+03TLaZZi8y1dSPtMueTsTV/1noOv0pBPY+DZGBHX uqL1yMYN9ba6JLNBKkEfco/tCvc3xKeO89uHRWo77fAPYdG3z6zpqEokyseupYevyEYj8dMaBvGO HsY7CpI/qvG76C/pzzkuZXqAowajwQhECNi3ufe5qTtIcU4Goy5YgNkH7FnPbhQDBVD2gF3HwsVo rtMVuPg+iwAmBGSfGiCCLFDhpP19axAOByHoL7MCHAYAX+g5rEI3EA3l+W7kte6uvv78aZLL9bKl MdWhU93mnE71WLDxWbExN2nxh0ZomzkYr3iGFqd4ktYHZK3fE7TltHNP2zQRwsRI3tZkb8Jd+Q1G WiQfjdYTOyY2ZistgJgaESGKNhxRy00+9ztY+sitV2y9NNFwcsPCn80eN7/4c0hcPbpSibthP2Q2 LL57q/lIYfZTnXesO1Tcb093MDtGB37PrUc7pskJNSxZPdZF6dXpO1x3uB9yPOB+2r7D/ZzDWB3M BalTBwXA9MP+yie6O2ocrYfZWNpH6XGSpO8QP9Hh7ZhtdZpd7S7s6TsHVIvgNxNngTr2RQAEw3Pw ADGC/0BZycxIBgdt75MKuYJWMGKwWT3g8Vdby6CM0UOZr2qIzdNo825kiT5Men39tqasz9/bQry5 nL83nZb7T8unUVLkUVeUzAX1rXSotTRlgC2JKoOaVEMckwqQXT5NXT3jR3MTF36+/p6Dl15+/U3F t4vFn09qGpOOhuSXLx131RG6MxZtur7l4lX3m5/a+fPrxt9d3/TUD35T/LCpPJcZbdE9dv2MdV+g YWoxLn+B9jQQM9mienNmqAXgCE8lvUHQmU2E15nNRmMBZqoyASe6wIiqVWc0A0+eh3NEIAYqqyYd CDqTmehkHdU9z+nxwhLMVr1ZPsdTKx/mKe+3EmYi4rOUGPQ0kwP5rr4WDXE5zL5nWwZVrb2pJ5Pm kfOtVmvJNg6otdW6YlhGREdEbbX09htvvrnYW3TNgfUwwC0+t+lE8V2oOUE9GCEdmBH2ChOIApPV jEUEvcFnKCflHO80uAKuINcodooHBc4oAIrsIB+SsQ3x4Oc5rnSXCt6lguwPRJG1BKDfZyeoxQvw twP2CHeYo3iishcI7y/AVtVgdYQd1HHSZKYF+vpeeE9HnqciUUgIvlL9qm6ybpuO0/nj8nv3KqAw Gyi+WMkGfZhFTmOQ9GIa7kNg9uZ7sWpi4FOdnIoQ41TEG8cQyjGsaogrdmvg5DFq8Qx+EJT8IEi1 Hk9l/R6nSXtLenpvnr1JLVPYRRV2UYVdVGEXVVBMY2M3ls5NTx9MuOQ7lYtCqDsPy/PdEOWiEs++ Uy/ysfNRiXnBU4rLeFSRsNy9aX7/n2th+nNbflwsbt0xvXV0OjV5zqiqcOqi64rbin2BBmFCsdhj fuy2l9f87ZbWqsb0mEh7pWy64ZLdJ9mzwgnov6Ma96cQ43onBwvcK93UUBj4p+pCZV/JxV2vubic TlC83rCgT7pepG+inngAK1c9bN2fTMpECGOi3yeblZNYCX6+l/grvAX6xv5SiciAa3QyRzh95ecd gTjVNMdZpmeQ/rMo9U9rscgiUkvGmUDC4Igng4FQgIr2hCWZMChzoczmn0siVhzFjMm5EHCE55Ko GRtyPrGmK9O33ELymEtQ6mJFgGqyBG+mlxDy9jig1LeXjCiz/Mod3f/JD2NVodFjNr917ZvXrfnN qk9gY/ENXX0mWp25sC3dWS4sCmZ+cmJLmd7528N3nrpxHegeOg3r/tR/7Xp1fbFYl1jyJDgXtw+i 4QSiwUAeVI1E7xOoqENoGwrwqGotAdoAhNNLoJNYPjHZI/QwpYTKlFIM8wN6vY4nJrFA31INer9p gwTSWeNXh+AnLG+eyTObsZTSgkmjFLiUxRhlMUZZjNHvAve0vRROPVp4nRe3AmDUiFLMEQVYAt3F L7ZfPDKZnMuVF5uC/Kx02cWw/ZvNpXWCL+AcdxT1qIcMP0R8WOj57I46sZNIpk670cp16qsOu8Dl 835XMvf1n68zUOsMUaiOoWr1Mk2izpnTPqhauaNzSqp1Tv/y7/UrZX8sWtiNcRklcahRNyqy0Z5b IK+UV8V65DtjPzMflKUHzXvNFOIxSpRYLGqwGEMGT9Qb8hj1oKe6kN5tc4XcEDcQxX1dzCpHYiQq R2k0RqPVNtlps8kxGovScovVabFY6UoLWAw32iBqk628Oxa1WSgPnphViZej1wBOy6ps5TApGAx6 ndUN7ufgVhKDjBqLGHw1yWXJtcltyXeTp5JiQk5GkmpyMh7ZkNydlO69Bg3ULef7fP6ufqx2vDmt 9Mm1+Jn+6Uce/g77eczrWomr00rcjJcN8sfSLO03NXmJ3AvykVKbH7ojyS0tUkvLYIWXhigrZ1l9 F8ViZgQmGXdph0lIVtukUhzHXVKMNgUzgauKozqv6IA/OOBPY6uV1v5lgUkRt0iDV735Ltx6+5h0 U0DWJRLGKx/iR36789GKsJBIuOUyu0M/5h/wfrEao37KwOfCVKw14hA6RNwDa/fqDXXBQqkXB3sz 9up0HJj8+kCDo8t/p/tu/72BdUHdEtsS+2rbavs621PiTvN2z2uetwIG0U2Sbe7RwbXuOzx3Bm4P HuSfLzNkk4vCq8SV5pWBOx3PWaURFps9HiIzaAhQfDixzJkRfdpmtwhXhTjLVS49zMrawOZfloSk PXHtIRiuCQWsIvRWQ9hADV0+X1/Xn/KBvaVRL9YP+bN5hi8MYjT3X7EmlLEwJExijb949bPDdchL cXdQNJuSnoROL+mpGEia3YYEEYPYGL2WBNH7hQSUuKgyjVQE+W6CXK4Jf1uMaVltrcGurTW4GCvF NVZigoMdEqamqr7c/MPfDMvNPPbw2g9WLv96+/8p7jr4Fkw/eu9jM32RrCQsKVYWjt23ctOhA8UP tixbd/2qJb+EsYWjMPNIazxby9ATQPR0Iw8FsE4zqjP9a9HwMdbIrEmzZqFjkXdhYmtFoVxYaFuM O5tsm91POsQrLVIkRBRFFwlZlFgwY7VQpT4QIDp7ddAaCodoqFVXI8FkZKY1VaP2l7Df3dLVz/Q8 GlcmSTlJk13EKTtrnJyzAU2KRj6Q7KpxgrbXO11bVcu1oDArGfYKZthxsbTstztsDiqWpypSlSlO /H6Pim6Xx+V1+Vy8GE+k5WQCKlkT82OTcgRZk8Zj6YRLSZC03DK0zGL5AEsL/FfLaooRg0VFrD6K Nre7nJglxBiHZYe2eNRg0+quQHVzzqp3tzVV01n/uH//8zPvO7x+1G0zZEeg9qlpN1w0esGFiUTE tZi7eVFdKjFmSrFw4t6/PzLLb+IHvv30kqTBunwrtIPw8I1VYURIBSH8N+iPYTBR7XXzPj2N1NbU LqvdULvT86HzQ88Zz9ce/WrDCtfNmXXcfU5hnWEzt9mw0bWT22kQI84Ol1o7uXY1Jxg4g4HWMglx P/+w/kn+l/odTsEERJpiMr2lC0mRSMirKOkpw4Z9XhVKi1MA3hJCYjQSqlBiIBKTZCYu2UVd7rTT 5eY8kse9157xDiuvgIzJ5K2gXp0oWaVJEs1hc6+0SzohfSaJVlYHSsNrd6UPp2k2nUtPSs9KL03/ MH1v+rG0Ln2b7F7m3uDm3H61FmpJaYGwNRrxDR8MDy04BsGV72a1S/fyLJOhpcQv9/a2DDIgVjV2 VuCkEXh/JXL/YHd+l5OFQZJLd2vLft1gYw6ttcUyNFaqG9kuV2I6zdFaDY2uZtjDEc0EblkhJ5Om rgVzHHUjp7z0h+GJUd9eXd0c91uMgiGQHFPNL02GFs9u3MoX+z/66aP9I1fcX1u8ddnwyO59xSkJ l0XxLuBunumKYdAVl25cW8Z+7yWD/t2B/q2CqNol8XpDFacYxxkFURANCAYuyScNSWPSNIkba5hk XGBYabjTYLmxYkNmP7/f8Cr/quEMf8ZwVjhrMFgiIacSC0VCLkVJTqmqKtBy9apUKGnVgY45WR/S odiXplD6lhiSyiKhuBLTSVKSmiaZ6SRIHk5Awr87AxkCZqslbKGW1pCVhJETWsvKQr5qp6uqPE7L odxkNsedllATO5Ag5Yk4demqMy8AxZQ7CiTkyjQTGsw/LX3oH7Yeq+2A5lEZyyz0akvJr7h/Rj6j nTToq6/y/9EzrDMuLLlM8xnD4JBif8RQZJ53V21qxvJJpljM8fSSlAfB2N9cchUDJn9DheW6a1p+ io56v2HtNf1Tf3VTcQ6D43kvsXHxpnW3B1B7kYsHTolx4WpSC1erboMsxLmEpeKG8F3h2+O3J+6p uKvSEBvMVab/yF2VLHe14WCRtMi4yrgqfoh7iS+IB+MHkwcrDe2xsRVqZU/FnZXCluSmyqfEJ6Sd xlcSb1VI4yxeJsyWeaHs9ZB3psJKedWJR37oAdvrIY8Sqx2SvhQyo+bpdFkY5LDZ4/UqQn2aM9cr emKTbdTWCmX+evZ+vUmuq7eX++rqX4CL0VfXwinmq4l9XW3TDlj1YT3VM759Vq8ltPTZlq7BBVbm HDuWfPhD5PO5jS25lJZdCCPiDkbEwyOVotWI5k+k4kjCUsIU0yeIJSqPgUjYKouVuGdImRPEGjGP IboKLd8h3TJR853+hm6NcJm7Y8k4Jj16Pued9zDmPkyENlbbMFfXyyQ6WHOPEO5ItBX7Htv85iUz 375n2MIGd8ewGN04vlnW31r8YtOvBl4eMRYw5c2fUvWKPVjjxISoHDv+TPGdx18ufrze5QT/5Gwy kRDCcce44pmRzYufWbL+GRgOO2Td+IomUuJj+t/s2zlkvVodVUcEc4ZIiCqKPxKyK0ogEgIlZoyE bErMbqMUdH5rIByggVajgbnAOzaWO2WAGoNqWGY4YuBnYUMNvkiUvRgIhOpORWFZ9EiU1kTV6Kzo 2uhu3BFHrUQyROZja87YaqSoLbkyOzHNnPh/UeBiq3/MSgwl9L+HBj99hY2tRgRF4t8CvjQ+dzuO S8wkTsY7bYY5h8gorFaV8rpRbJ4Py7Y6HRjMxqyxuRM6zdeaV5IeshW2mreNKsCLpoL5YPPuUeeI fRuyQcaTaYZW88XZS5qvgoUZHbE0N1ut1uZMJlttRToy6zQucitKdSSUnKmMaG4MjRABc4+MTDYz Fo6EEkrM2gAN2fpQw2tZyGZeaYZMubXZiVdhv4TKlo2qLWaU4mbSbGZlNRq5mU20kQ2yqEPMQHSj 5O+G7hENyQR1uyRRJ/rVUTCq2iqHZSq3hreVQZmvZdQL9BKNy3wlfHSfT0Nn0OotLeznvOxOp3U9 XZl0nj1Y4ntQdWuj/KDexkAeIrUHd/KyrkXXIsmWwYTEwh2YzK7VNDeKbJA0r/0vTh30KZSkeAkJ 3KXw2/md9c39rW2pmcU3hnvbx/dfMsTbT3Sgs03w9eK0eyq1XTDlPq6j/5kfVEcSCbHMXbkCeiqL P76q7j8iwWmJ+hYWZ8CmS2uTbiOHkKhYiTGRRHVoxphIkHvVhrmwCm6KLUvxG2Ib4jvi3PdAmKCU IIDo5QKxOCEJObEssTaxLSEkCnBIlSPRcor4AB3VJX5NHoEC3aW6v4eKL1mTUlPbUtyoaSzyB3VA X18/5hVWwbb05VvYEhSzf3qwdOH+fxDwaOkd6cFc++2EIbZ5v1lDgjfmm9199YbFWThZjP8viNi2 qMmin/DkthL+pUVogQaYpC4vY7WlsQz0ZTeV0ZrGjobJjU+R14mQCDbAKrIquCp0J+kJ9oS2hHaG /hz6JmRa1niqkYbtYUfYKcflhGC1Wx1WJ4mThL5BHEokmZGhpDJoxfBIBoFsJFSvYJ65S20joWAE I788GHAGgwHS0EBIdajMGQqVEWgIBbkw+ElDPQWaTISCdpuOkBGNAdkP/lbDCeNnRmr0N2r5IFhW p02okWUpvctd11gWLs9m2Gs29lrmVIYeybyboRnfiMYCXLI3ikxUgKo7GCjyGhEhKtLL0yyNo4N8 LI17NYyUUKItEnqadD2ZtICw0DGAsMH5b3Brj2GXszKHdCMG/p20hsY/xMDm9Axiwt0w1Mvcu7CM lle1xH1Wo7u9qaq/pTTu/6e3/0vBPDVfrLFUTyw3UnwxTSvhHe4H6NWod/65W4ck/N5v0/zxcx3z PMNziQSE67LGy7kZC2tTCcb5IaxSN6HPo9C9x25Hrv7nHnMT69RVpiY5GLTKwVDIah4Z0mkZwKMo dGRIUmI25LUJg2sHqMuictAD1lCotbScEwooxGa1AIQ8UR0KMUI9bp1VD2xdwQyzzGBeMzkGMdlW HiQBmBwAEliK8FijaOlA7uvOL2cO6GIqannpmxwsJ7Bcaj+/PosNWxPo4dccI3jQe56V0ukeuWXN sR75GDAvsIdeZGC3mnbUE6tsHUGWR5ZF10bWRn9CNlg3RDZE95F9UTMf4aOVfMqoOCr9olwYuHyP ox67HarDzn67RHaCLG+AbcHd8u6gjjBWQ2pjX2neL+ucgZzMfgFBb/fmiM7iyJHCwJeDe1ZnzloY +GIvnoP9x3ssnlxpPU777i4wIS7Vs2f0LhsLg1JksOc7Kcz+9VCkj8RquuHIZc1R5dySJR2RYnjZ tFB6TKsw4dxBesGN6ZE0kTDGJs3+dhO/+NxPr78IHTzjau7FeINCE+zXHtG7XwpLiJmUwTNq7SJ5 kWOz4UP7h76P/B8FPwx9YddLXqnMQ70mj98TTMkpR8pZ7jeUsVLYwxrXoNizDlmwYL2OwWoeU4Ps LGCNfRM8SLeIW3QPmjaZd9AdpteE1/Svhj6ED81myks6US8aPOChHpPH7A7pF/gWBG8QVplW+laG NlkPeA+EPgx8qTNeZrHUE85dL+ntRl/42mlaOKCIU30kIGOIdKkccP5sJBehEas9bKd21HVMbXcz fada/+0EO/vCCnup9/zzTCbnpjA51wJlciKUdCb1CSHp83v9VLSa7Qm0UyABLh2OPCKObCZLAsxB ii04DO4E8fPYpNMtuJVKac2btwCinC097tOJ9iahMNCnGu1N1GtvMuEPLQz8cY+tCQX0X7ET2J65 SY97z5qbyPnvSE+H8yMMLYijvpVoNJJK2mQiKJL2rJMxhr1exsrJg1X0A5teL24s3vf6o/AQND43 Z9KNl25Z2DFt7ryHhFmm4rXFXxeLx4rn/nkMzJCBjRNeerh4srh9x4rhKvh+h8eM17IVkTqs0LYj +v1I0ycOkQii39QUYeifaWyalIRN3rOes5F/KXylLkjAFEHkKxAJiUrMzKg8FsjYSSYYFB12ioJD jkL009nute7HsOxdn01CMlB6AFptJibZRCebZpuoaU0i+W/1FKPbwYUSVgszXY5QLxXBaI3B6hZd VhaOOf1ej89DxZgzmoWwHxvFFc9CxFOWZWvdaMLBZQ22c15ofPe8tD4a0Z5oiZxt8CFWjFYEOmb2 T7qiLRBoz2OlGC8+uWHOF1HbjbfffhtdULzr2iYlkYg1XsstY6N3H779BcVLN/cfoD/ZvOlHzIKT iz8W/o4Ic5MkvKF28MZFvkXBhQnebrQaHJ3WTkeP+W7rOnmd/W5Hj8vQDm2GRcrCxBbzJnmTfYtr h/dnkSeTb1rfdJjdDEORtUMKrbLBXh7svQxzORwkNbixhhC93mAwGQWTKBvsBvdoeZz9TutdDtMq 0yr5BvcqZWXibsMm76vwqkE/xfKSAZCaPlK9VludsRwb9lXNvxo5YowFPPU2TmICM1FVJxWgYR83 TKwXCjBftRnDvyY6card4kuVXx1lkCzVVaqZxNhq8f8Q9iXgcRTXul3d0z1L90z37D1b90z37KPR jDStZSRZ0/Iiy7sI2CATxQaDMTZgSYAd2wEZbLMmmCXYECcPwyUQCIkFMrYwyWcRAoE83kMJCSHJ S/ALvvcL5JrlYZzkgkavqrplTJLvu+FTVXVPTXu6qs45/zn1n8oyX3gSus44v8Hp0bIG1MFiWRg8 g8Ty6Dl9nkVdIkgw0YenBlBgsesMcrpqpzCdDCrXQUNQlyJBbeXSCSiooVQqHQ+oKSBxkRQhCrBI e+Cl4pdTcPCjTlhxbJgPpkDSCwu4AKDfJZhSasro8GybMPaiBKfgrvrhHw+l1Av/CEMSB2nMK/Cj MGQGk4EScVSCcwQRxcOoNxp/cm+2uH/rsfrvF5+pvwEeAB2gCvbVf1K/5vClX9qxav8DK3csW8vt ucU2J31kTAPbAQPK4L76VfVf1P9W307Tz3+n/sf6o9+7/trvgiWg9150wALCob+FMqkSRfBVvbYy PBJ+wE/ZVFFdEl4YXahcEl2nWD0ETTACLTCWcumKyNbIVuU29bXI/1SnSrYHA78K/138NPRpmC7Z uAny14ex1OIGElzY0KtIeCG8wiq1qCo+VVVG1TvhZBL5aCKyUzmpnFYoQelXphRqSgFKMB9V1HSq MTIB/qQHVeg+JYuNXij28V8mEooCoboNOnqAho44kRfyZP6PwQmK1ANcMgVhhqkFOK4fWf7GOc9h 70OA0ApFSzDjaRpFTpDnh69OYSSMoyvTXebW/vDIYBVtClQHkdnHvoiIcRZcJPFMgy/sT4XS2VSD L18CmTAsCoFiCeTEdIkIR86GPg03fNAgF2ShomO5asHGVaOi198NDLOMNsL/hfIwyQNWc9sAUDhk g7VIHGqP6cWmFtly5uTdVy34GujVI7nW+sr6koHqnXesuOdhcmN99xf1yfyjO/Zd2i3XWwYCMpUi N5IPTv+wsmfTgW8iZLZx5oQlATVLFRT1qli+MLc1QTEuYOetBaYs8sFCkS8IOXdJiReSDa351sIV udtzt+ef0CbyxzRv9WwMZZHuJ1bzrXIr2fpEE8TRq+MxOS4DeQKurl5pNREWwmT4CX+uwNvSPMvz UTbKW7bwW3IH+O+yz7I/5ZlCjmctKt3SRKktfvsKMHu4AA0uNMLaE0DQXZ5wJ5R/rZO3ydD1gbcO y02NoY4JUH3atOInTyGVcAaTYI3thGB1cBgLPQq+IJKCubWA2rj5NIOO49HjFEvxZCqXLmxkr+S3 s9v4W3J7CvfzT7HPsz9nf847oUAPIGdpGHpLXmM/AW/14P/8PgumEaFNBtVdmWUwpDON5Dmchjbq J2wu9s7u9Vv9Mb305Pvnf6n+19f0kVVlOdzhSaUaPr1naE9lw+7nHrnw/WfndpdujYQlJ72p3vXk 61cvLKqlxsQF12/YcMuTn4STvmyOJN56Z/t55dXn9Vy883+seeSkwPXE56BZXQylm4PSHSeeeo5Q oL4Vw5qCVGen4NHiig5FblKxlGGDBH+wWj+DcyjGY4Ki2OMxHvpLfwiHP5NisjWcJeKkwNuIIYAm Oa8rNiPM1R0SRBAX+8W7RUqMCzKIy/3yqHy3bJGPgTwhkj8cxzpcOIM2KAT4h9xPM+gy3TUbW54N LkM3BjvxZuTxnyOT2K1R3TSXjC+fn15zeXBeR3G6w4jCXHp794XBNL20fs/o5oTn0/c+d0osgY7z 9oHNaETKMyfoR+GINAJKf1jkQwopOjJKXt2hfsN1l3pI/V/qjGrHGbyUAARSoIagUzQaGA0+53ol +1b2z1kXrfpdghJPpNWmxGrF+pPEJyr5mOuIi6zYrChopch4AyAfb4wRStKNvBhVDAYBfCa3MWmH Xkh8VAZr5BmZlG8ol/Vyf3mofLBMl22IREpau3O5/jzI31AyvROTo4XxyrDhnZwyFFdhViEpiayd d6TTKVeKTdlKRCbrVAWIVhL2DFcieAUWaIixhTKV0vAINFAjXuQoMqabaCqfTNrw+A33EW2OQe8A ayVrmfyRuqIz1Hbj2msOLEvHil8Cv45Wl7qdtdNvjK3ddVVYX0UvTSU6rpvecGTL8nU/fIvMXbwc 2shUY2P8/OnpD371TEl/5QnygeurCjpOk/DM/F8rigA2kYw+vtf+txy5SLwy9IQ4Ib4Sejf0bs5a FYG1IUikiFZiRfOa5v7KJujjNAsVtBMzVNlZubtysDJWsf8EvN78DvExMdNMX2u/NnRddo99V+gg 8bh/jHiRsIuhHByQUqVKLIr3No0QI8BOCBGhtpMA9lDICiFNKCSGwzaWiMBZ/3cLiBFGuDfoibnj WehvEnAlcHxMkMNQFpry5ViTbslZCHZiZve4yDoggt2hX5mDsx826EC2Yi7ry+WyHMEKLMmyRTHo E8Wg3WG3ObJiCLZDjNWazeVhp3yQYx0WIRsOoaMaRWYlnPpcPpdFJzly0Idhm+IyogezDpvVXgkG w0SPA/wYCnSO7CJ0KGA12BZmJo8Ibk0INVcmyCvGE3uvPhtcKIRDy6bD4nQ4NC0uRxkAZwNvRujN Ux2pQsWISArLDFY3faux5W00XGjv+/MWBDPYQFbDX9gI/xfb4cbFJ4O3oiAdcpC7wGDBULBH83G7 U4tnAXRtBwwC+fAwMTKMeNGIGA1URHxNm2E5qFmBFypPHK624muvF1vCTIv1/bTmY6r1CzP1sfpd qfrc+a06uXRhqQk4ft3e2NxTI+9ZIPnF4l//oArtK+DipJIpbu+nD1MbP9tnOf/xXiaVIjOx9I7p a0jy7i0roLUEDmvCH9wyfSO5YPXcaK5E4rhFAurRZrhSfSCos0DwSDWIB8VaAKnSskfSoIdDE2wM uFn6EP0E87hw2m5Zy2xhbqX3MPfT9zOP008IR+gx5kfC827OtDI8YkHavEzAzwp2QQPIjWdhg80S JMg6bNhmIV0I5yaiV6w2j5f1csBGsgQApDtaA0UH63PAp5AstzkAcUIQc6/W2oZsO2207UJigvw/ ethnG7MBm4Pgsj4fQZLwwb413l2OkD9wDO1dAO3pqw2IjelYaFMYgZ4SEOqnB/GCGSaQrrmVhsuj cOsNiCSF6Y/Cq8KrA0bEEIVBAEhAFY33/QBU0i7Sqnotf/rsHUAeXbT1qUSm7dM0Jb16fap3x3lQ IdBLPyWCyRceqQdo0upctvNS8A0oe1+e+Zj6I/Ui0UR0kYt1PyMIVUtcqDbrXfO1O1vusx5oobrR iF+ypOVIFdxofaz4VNfR4svFtxK/Kb7V8h9Fe4t1gXWxd3FwUctFwfW2+4kDLd8FR8ARG1exgp3d D1q+Vfx2k4Xo7u9eF1jbPRLc5z8EvttxHJzodtgC/d3XdVJ9NtLv8ZM45v3TYPWDTtBcsUHBLDRk Cw2pQkOuq/L9yvMVylKZU1lWuaHyjcpDlR9Uflz535U/VE5V2KEKqHT6bAnb5bbrbRbS1mlbattu u932kO0x2yu239rsrC0CZ4fyeWyU6EzLBfjE3PpSZx/ZvJ8YLJVIUc8VNF6UxTXiZvEh8ZB4XLS+ Lf6n+Bm0rqLuEjSRhCaC5RvkhlJDrcHSMD83j0/JKTL1HkGU7DX7qP243RKHFUnYBWifJ8DzuqB3 7+wm9e613WT39/zAj/LH9Wx/tjYTAZEC0Sa0kW3NtK6mtM30hzRZpnW6n15LW+jQnPaVUJE07TH4 BYVlp4ZPDxdeGIRm/PQgdKOhWTqDsFUN5RjBz+E6OY22J6dPnxQMtDWC95lnU3eEV21Cl6urCzHD RgwpOMyJMZEkBgewHWtu74iqDoGy8NAHS6TYdDXtktwSwcXtElDUDqpNIoSoUwIOBRbtlk7J5JwZ dg2btptuAlCTYG0yXCCQD5YyeU+pFoPGjLHaWTaUweczLWBbEFPUMm7G6FVpJhd9/7b+jROgJahn e/LhaHpRZ23lyGvX7DkQdDl8znBEat40v3+1Y1tnJhEqNt+x/8oVm75/11c2tuViHtEvF7JNC5ZW +nb1Ds/N76/fryeElLh43pL7QXXhea1tjWoEefWFmZOWCNQuQSIDztN5T6+NCApBEoghd1IOToD3 9Yia3k1ZpTTLukZ4XmCDBCEgaqU17Mkh2uOSlhzepumco/XnpnJkOafn+nNDuYO5sdxkzppzuQg+ JIfIUN7t0QVQFnShX5gUpqBPF8ouH8bekUGyhKZkPJRAIUYIFuO4fiYoIzrbAIJu1ZIwOFIo4K45 o2vO7Jo7p+sZM64inMRKjHIJXVD9G3McTlmcdCqZjoSjYZKxp+OplEXJgBgXkginS3bAtsqkMyDs lCQiYZMyX5hjzOeZd5Gu3kAP2Yfio8l9tsfpx2xHLbabbXvs5Khl1DEqj6b20fuTDA6TDQC3ycQ2 phaiR80Idxpx8ObZTBNwaMvX1z65dvtru5ZuqR5QrI5CBexmHEs7K4uaWjNzIbSZnt4+PHXbg/+1 q9x6ueW753mjETI1/Wh97ajauajjqRO/6e9AtmL5zElqDdRiKvGRfvUnDEjawYD9Mekl8iX1LfAe +BNpddhAA5n3XSivt18hb7FvcYxI+71PeZ/yTZDHfEekY+pL0uspNwH8XoJyRaeIE3CNTIETgLQA H/RsE16/GBI/dAP3X8Q0a030WVjeBVwFlBk43hyq4QzBiN2t8QAcBGPwG+FDqQ+gjuCjcpSMNlvN fqg+ki1oU1ZgNXa1XZo1lGy/y+CHDqIkDhzsRJGMZSdHsEE6NSx0YSbc4HB1GNsmk/yO+LLDKSw/ JMqfqMwyDmcTKPwGt6eV0uW5L21+/sT6HW/d8/0F7Z3L7EwwKJcV7YJFbUuaLvpI/No2EH75+D2H 7l1dnb/8slooVFn20O6POguNSFZWQFlZAGVFIopgu64+4Pye8znn0YDF42mzEZIgkUG5aLeJj8jS S6qBp6H8HAaPMDJsXHzUVtjNcTYWHeykh4LbEmmfFT6KMHAb9FcEkRTzeABdcIR4sAKQY9DlCZcM KUPVOBSyEmYRwPHqL02VyKHSwRJZktMgrSN50f3oq7NSNiVYhFBj+03iWSWKxhTKUOGMcXXK8Iag +4mMr4CzMAYNkTkrNFkl7/QmU2qKZDxpg4vlSinedIbIO2GRcicyIMMXMmZYEkpJHktJacg55B1S hvJjpckSM+Qa9WwJjqpDuR3FW4J3FB9w7g8caHgs8P2GYw2unfztbhLN4uAAlu6SId0lU7pLpnQD nK4zaAhP0E+3GA7CrCLFsqW2eI2UGXPK26hfMrZie/36hZt7xzdcsOHZDfM2dNq58txbF29KiamS VgxmL1oOMcFrV/sScUti2TdXdR+8+cf7P9iu9YDwpkAsmp++5S6f/O2Hn34y7b3DWAXUIJQxPxEH LfpFjGeJb9C32bfBf7m4zWdNOR4nXyZfdf+C/AX1lvMt/8fU35yOUb9BRV9Frac2K1upUWUXdYvr Peef/fa8bSYAbHZ7AS2DuI2yDdLxAAF6AxMgeziS9lrpCSCNc6wd4z0Wzm5ADyla4EoCSRCabAKF OifHWZdGYHKCu4UIl5Saskb5QLEo8ZwRkmoWTMnDteQx6nRZw6uGg8tpCnoaoYQpgXh3adn04Ekk g4UCWiyFgkHvPT2NHMDTgychDBs2wtVuKZYywtVRjywRYV9AApI7IoGgHxZmuBqFJQtokodBwpBG w+KhCfTA+bNqs8LqpwanZ+yrF1zSdWm7snRi29SmVdNP3vWL99WUX9USneCTY1edP+/CwIGbDt50 /D3gf/eRh78qeyoDB1SU/0cQ1Fx6E5TQgv5lvQQYr5wkeYawyoxgteQLEL/m3IKT4zxQ4RcEnkvK 1pcUkJQZKLMROVKLUIcgNGlO3+wHRdeuBtgF2mNHCZGr+ZJcertElSDYBSKG36GIJko5RYe1cneu 9Lu3i6D4JkHkzEHPc1M84N+cghryTafTk+PMtAFU66VcsxbnpjgSQgyuzO3k7uYOcgzaPliLm1Pc h5yVC8VL5RLZWPp54hi4DDBoG2F4OSaQQLUIbdzwyWEIhXDrP4QzhdMvFMxk6wI2gl3IaYeaE6lR xFVAPGFUmyUScbzvjkSqzZ9ASTFutaXSktE+V6JIo86mygb9FT942xdfNf3bWovvttvAG4d3bF08 R5vDWDghGMuQd1ALprd+RYTOThJEykvJ2y9dULp78svtxbmtCXvUzfsdfLnl0NZLUe7zsnov9Xso SSj3eSl4TT8vJbB8rSF1q/224n25Zy3P2Z/JHWn8MPnJfIejYm9hqkxnfDltg2Kbs+fkdrlP/rpt T/6A/fHi4/NYvS85N+HMiQJBdViTvu6cs8RhxB6Gi71b91S79XRG69YlGRZ+USt3g26ciyRq3ROU Rff7jCSFWNt+jouVSEovNWnUBBXVObiCm/aXrAvSMb4Pi5qnhmrdAX9tvA/09YkdEzNTWPU6O0BH szhiJcGIbAUlZN0oRs81zNXhl2DB10pzgZEL3ZcQ0E0B3xSAQV6ZoGjdl9bK8FGkBnhN1khNT6QL Dejfk+HdBj2b0xoQYOYbNjfsbaD6G6YayIatyyBcxkgKyu3JLjTfwqlBzFzB5fTg8GdwjZzCtxGz Dwly13QBE/tOIQxtYmKfLie0wsCpAtYAptP8HNGN9kvg8CFNHJM1qIfNfPizefHINauaVBiigFgA OB6JJRznWFfamoPGphQifOGs7HNSs61Gn2a80ijDZJtXafI7oHO8yStuPr6YGSnOaev+wS9XDG9Y edP3bpxaveArN2+89pavnhgbXNzRv6K1q78Yv359orrl3+58iI9cTX37mqZsa+dl951Pd+aSjWSj vmflnYmmpgvLjYtC+siCm8tNB6+8/dXu6yfu33zNQ+M95U8/csstlfMXzwu5pQBCVL0EYWnHzM63 nyOYmQ+fYauYWlFa0qLRvSTZj5gVVppmAkyasfBOQiEaZKegCA2M55DruIuMAMKblF0T5O91t5JJ yoqq2JOyU1WjSTkxQf5OX6dmk3KDqoII/CohrrdYlUTC5XI6bLId2PM+r57oqXn1BQs1rz6nxavP g3/VDnhRboJFJguLQhEWShIWcHV7dcGtve4FvBfEva97ScELvMgV80w2ArlxrJEsNQ6hkehuQS8y Dh+Fa/g0XMMH4ho+CdcNjbjWXVA4GgkDxuWzGXwL/rAPM6CUmcxMZSh0a7ytQ8M1lB1cwx+Fu9pj CS0TKi43oAhaWXCF4r1QwfSeoEqDjh3Sa2f/ZySrGckSEKBA6IdvU0h1AWNfI4EkmK1h5p3dx9Vc iBuNr7wBJ7yCytaFsi1diIjpQqs34at9vhE9iODjCOITwyXrNtMmEdMIcRNm6SkKY3XPJlMY9yCA f3HZzgUX3ZDLzqmnm0MeTyGSXdrAezvr6c6QO9MN8fo758277NaD9fs2tViTSWsifDl4+LrORNuC OntZSLElk0w8sIk6slGzIfZCHsJLlb6KYIko8Xs9IO10B2u8m/AQUdkteIQoE0zKHgQmFWdSdqOG Kibl6PP4MFkGMX20Vu0QAxidAFyU8bgddjQGUXjX8MV1KsdxBjM7LwZ1+HicV9rRgtNM46qRHu0N 4lovFcvaWBDsDQLsDAZ36FK/RMrSWumgNCZZSlJN2gsbk9IJiYktn4SKB07cmUFz1xFNG3TGTQtU O4U1CR7qL6YFfXGc4Zime1ZfrOurV7/WOK9u7ZZ8jXPpq/ANXb+43jkdWddmSSZJJbiOVGAzBaWz AMctCaVTIODLetCorfWAMQ/gaYIhBJkWGEFgWGjc8dhBK0/jsYNGX0CubUCF32RoBzFrrlk0Mqwx MqgaL2oaa44QqnUVDtEYC/aywIiv7pA9Bz1jHqrkqXn2eiY9Jzy0B/Vv0jRUHyk2am48QGiBf2GE Zqmfxhocxpv4XxyO8c+HYemnW86+PPXKpejl4dsvJQjmemg/e8nluryQBB6PrDukNhvvJbqIXtkL BaeXAa1toaQM3bvfHFaKSTkLG7pP6UnKXarCJ2WvquoZoCTlzAT51lFV7wRtSbkTtvW8Ojcp96qq VSm2JqzAInU1r7dI6x0Oi5XoZbo6sxmf19GnQ5uEjeFKSdGIvoN9Y32TfZY+CJFcPC/zJJ8Ph6Da CiEd9VDoeOj1EKWH9obI0LsJJd9YhB8V8UfF48XXi5Re3Fski+8SfJvcRrbl5/ZgAx5TtLU9J3rI gz1jPZM9VAkWUz1UT2hh3wR5/ngCKZXC8s9JtdgIdk3P1oNdRigRWT2T01ZD/HXjcBFkvzAD2kgQ MXULhrXJUlMkxjppppyOppvoRgkw1hgblgDnLDHNEohwkgFuZzc3UACIWHTBNt0jx232uE3K0LI9 kSHiCZsV4E0TwgggJNf2negjGS7JaZze9yZLr6BX2JbbV7CTfXQ7uYJZwf0XY0G4bHjEcIj6UJpp DA/0uOCvMRMzfxuHig7XUP1BPPnh2drtNO7DGl/zrHHNm58L5vdgja6fZj9n5mCgjjwsv+FR/fcK EeFFM7Jl/acF/OqyXctXb0/039d/ybXFTHc9Vo14fIVY4aKiO9hTj2aKvK8UySZKLfAzCetN6vEd F8y7YNXq/oHb99VvukqDepLORC4B994wP1Gr1R2Xh1NICtSmL4F7R/WkX15Sd6yrMVibXkUKWJsa NrsNykWBtCCb/edn2aqdAUUcpVrS0l8ENLTXKYb6Lfkm9esw5WdaoCWn3gRvR0gP7yISREF2CQmh cIg/zttAJOpLyrxhv9PQZquKA9pzbL/jyH77VWjVC6qaiMd53uUIracpizUCnfzxKbRhOfOsvkps Aduge8w4sEX3+33IpPvg2ud9IO573Uf6kHn3QdPuQ6bdp7e0wgJaZB+SDR8y8j5k333IvvuQfRd8 wIeMOi8Xx4pkqTgExQZa9KJp0XENH1I0LXvRtORF08IXTQuPx4SHlr0YNZJE8plM+qxpT4NSejI9 labSpmlPm6Y9bZj0pJYONXxu0rFFF84x6QUUq/18bWFxNI98gF8Yhia965zdxC/Y9bhh1+Ozdp1H dj0+a9d57I0hu84ju87/o12HMHQE+ZmDIygKO7ua/8VC/uc1+2Lf7qUXf9UnwCWZaQkKnkJ41eJM Sz1jLs9tyxdevqT6SP2bV2GzngqtAwev7UrsqLNXtlu/sAzN01KOwnXoJBLgAl38WRhkOOC50OZK OwFhDaatdhsb0y2zER+Lni5ovAVYwqoR8cHVQqOq4Wq8OkdDtZ7MFrRJdUolCVVX16qoSevqQyqp GlRBfYoFrOnx4xo+GtVHoKPPhhADeefhTEv7MNKcxuQZsSETf6FzVPCBMF14krA6nA8SQopMyVJc Ihmf1+8lGSYdiYajoSiFGIUZ+JYxCQTsHokQrbEMYhRmgES5JOB1BCUiSgcz55x/UsijcCpUhk1Z UAWLwCJhG0cPMaPcqDAU2sns5fYKO0OvkC/LjlHrkHOIHxX3Wnc6d/J7RRuirQwPIPKgSVTBYT9P UMEbdOZBKa14OxnUt//y6su3/+aNk+++XlkUdLF9jUUp4/SlU2HqxRv/fMfPbnkEZF98FRQWLnvn 55sGFy4OKXPWgMSTozE/msFMfbEFdoSgvgSu00Oekg2FEgg3CiYIbsZbUiHeSqLw3vs6a0YRTISm R9Ti7qDV7YFojEmlZZaxuoQcyOmRsKfJmN8mM6LXhGMJUAr7m6aayHKT3tTfNNRkafKYsMTpgT5o mdO5fm6Sm+JoLlT+QtycM8JlnBku4/4hbm6G/HDXJqNrk9m16dy4uUlIPGWgNiSQX4gDxtMNohRK FdKxdCbVIOYyIC3BIh8uZkA2mjob/yuYUfLOpF5bqKmoGBVHpdH0aIPlOt9oaCj2NXUoM1rY4/u6 us+3X3xQelA5kHzM94TyZPKI70dJz3w/wLFAxFBKzbKTzkpowm9k9M/6lulMYDarGcozOBQs907/ BaMmcFtTZdGqK5646OIfbFw2r7lt1aWtqlZN65f3rKk/2qeJqRSZCK6lfo+w5I6+eOnmf9991192 KOFHt1cv+M//N9B5L8JYSwiCugaugBzIQH8/zVZZHycYIgUVMosYzxHoD5uYD9Y7n5Fb8GVMMm7z Aq71jC+gCQWwj727QLIhp1vjY4RE5OSYIAk5BvgDwSChPCJLGKoGX5ZjGKqqSTmHVlNMdTTzutQF NV60rcZfgYwMkWOkmIMfJBzHwBrCAtYcvds6ZT2BDt0Cx3SWyPFBGaL3vKoY603B1kDDLJzxSNxg 4/g8AW1SAUOzB3D8Lr/ciCQYWBUuoNOnB0+dEk4aaL4LZe2ixWHFiwMHkAqf8w3RGvC3nhuAN5MB /EEjaGtwvs1dkFcHv97TPq+nsWW51eGMhXP+OLBypfa6dU7B5kiXqcd/dc+aBbV5i+dbmIBSu+T6 37RXhUiIgqCgup2k+wPRMJ3C+ecnyV/BOWomn9S/zJb9Qs0iOHM+IZazML6A7+XUy+nfCu8Jfxes OSGVbxda87ey96v3J59g/02dYA+rLM3RTlvOzy1kl3CMzuoc6WmWiQOkDACyOwDFaR7C7KMFupc4 4CnBG1rp44Iohw5E5HAYKVbY5e4wCE+ATboUOhD42OOh0wWrR0p7WFOOdY9fAxejzIMTh+0+ZiVq 6A67j1xpJBfgAC/La8aVgrxVvQPqb9kFXGFeAyVthbZG26yNaoc0RvPY4ughqCRXGkw0HX7ZaCnh XHY2PmwSVtEOSzZUQSofafzhAiKpwQrphWdtcWhG0dE8ehB+xab7EjVbl1+FRSAFL+G7mZYVmYgz I2jrYParibjhcZ/Q7fAZia/A76M3GYePwDV8Cq7hg1D9zNlnFQZOFjA3NQT0rAgHOeqGhRCBBcod 0J0B8zgVonYK/UOSJPE1aWLmT+Ocz6hhD1SjVAPcEfd7jqAh5PLAvrQEO9IS7EX7ZrugxMfBwiz3 Dh/MxJd0h7tW0u08LIwzXAZQJ6MX+pdTRfjToKhPjRs1fFUIPVJFCELg1Ru6HTZSRYhLUhMzH41D dQrrk0eRJo5CXfs5uh4gho3DXQZRhOwc8p7lrDKD0qJSZ3l7xnlgrbNHA5Df5JU5u3pyHb44SA8u v2vVvCGJTQQSglL8Tm95TteGB4tz7//G0oURtycgUi/UX7hrQ1syEsr97M5Vy/f159lm0L97d2e+ 3LtwY/uX1l11KMXzKtJx6ZmPyX2WaSJEPKC79rJ7ORIXLEeEJsAROD8Wn4/y7yIBE2fR/4cSxY7Y L3ex6GAelx6j2SNcOAIsFoKnZZqk896Af5vP59Xh6HvRkhKg/1byTnqnvJQ3FEbaxdhggGDxNMaD EADiA+jgJVGbPjmI2Hl4j6EL4A0+I2nYr57dJ8eKBQWq0eEWE3/8I58Wejqk844M7HA7tt/49FzL dP3JddPHzyvF1gUm181R9oG/qwM/3YbetTZz0tJEPU4o4N7niCT8dY9BjyA5lSTtXITLc4s4S5X7 VvSJ6ETU8oH1fRupIKZnAhU8TXhlWvBa3raCGStAwQRVNTxoCYX1VJqhHaHL7ayDJRQFDgBDMHnT gksMAvgMRPwMBPkMAvkMwvcMgvYMgvYMQvoMwvcMjt8xgGdAnHmdIQlGYEgGgX1HEvkNSYjzkybO T5r4Pmnie1Q/kzc+hk9OmjAf1XoIAozJJJCTY0mylBxKkkmf7Af+PI8UzTh8sMtE+S4T5buMh2E9 5IVg/0MXKLkmXVMuyhVSl5/dVMRWAkfyzo3e/UMsD5qRU2djeQhVYsyPSKz4PFUsFCNnYyCMESI2 7L056zhxONNCvZadU98175bzV+zIZ7rBDd5cJBnLtiNsPp1EsbYb+hddcvMj4FoEwqdvuqxD8oZX gNOmZ+iFiPx9OPtRsFsPe0iCBB7CAyxlaSA4IPZLR7kT0oeSFaUjPONskdCLp6OyVgusCKxiKKvL JlstQRCMiHLQmBVAy0xA8MuBiZnb9Y08EY1HotFeXvDxvAAI4iu8C7ZcURcgLIwQhxpCQNoSbc6S QiTIRwTeBegoNIxWK8NECTbyV2Fbmdf5fp7iB13vAXSaDzZBcXAQkGgxvQ4o0I9+2XjXCg3/woia 0STdyWsCjs+dkCyCBMbge5AxiCWo8cQLUOIKxmycRgzX6dDpwdOicdwjzjMzoiAoHcE4Lwifr0ob tLufFv7VqTOzFZ484yQiv4R+rIR+LCkghhgq4No58Yyviis/qv72DMvXZhMVBmiQNhJgDWKM12sw 63BCLAB/qb9UjQeL4KOSW2z41o6WYhU0N7S311+Jkr/epYbtqZQ7IKXW1x8GpZtb5QyZSjGtu6cV JOXuei91Cs5zCax7Fkc9OaS1f+j1dyMaw2JisbMvPBBeHbmocWN4Y2RD4+2RicgrEVfWm/W1E+3h XqLXeQVzhfUK7v+z9zVQUVx5vreqP2jo5kOCX8SPjiEEkSAiQUXGIQQZ1iBxEAkhDAFssIGmu+2u 7qagu4HuBtTJGNdxWZc1riebZYjH9Tis4zoc1+c46ssk6ngcxxjjuI6jruP6HMMYxzgO/X73VgGt MWN237533p6DdX73/uvW//7v/+ve6ltWN1vn9pP++I+nRkJq5NxI3dwotS5spnri1EkzJ8bQ33NX zsTN5amZcckTn09KmBM1d25+/NS4+PipusjIKbjzRFbSrwlGRhGOe2Zu/NSoSB0Jm/j8XJJASU6l ik+4MWfTjOiEGzMmxuEWoFLHE23VvEvzbs9TsF1BZFxSxrzJk+OjJ86dyE9EOHMmq2bP1j+f8Xze 84rnf/bMHKI6hTV3atq8sVAXsd9i+s4VLK3sydcc22iol8fQ1yik39KVvvocu6hbkzpH/kldOeRE /n+dP/N7Q5qYbE02e31yDvmOKvR9yYeDyIf8hupk+fdVFnBDw6fzXkrlPpuXlL6jafG8Jdyi1Ky8 4c9r5y01rlzzrYz0b3CcRhM95emkzET+R+8UROGT+qwpidbhzdzTf734uRREWvWNH/7pleEH2SVv vpxVmPNyolY7PbkHMQr+jntHGcNPIgrydE4k/00yLP386rKlIz+/+s2Rn19VxvzxX5XPcO+IyBf2 /B35EkP+JifuX7/28+Npz5IYdejzY/qHBnnp+bD02HiW9NhY+9SkDPmBcSx7SwN7gZmxVWNPjhUT 5Mfoc+5+h03WLz8i/vID4oHRB8RY/L78dDw4yD3H9fD07xhM+ReiUJzGVqYROPtDFTc35o70S7L0 d8J7hhO4C+CNkfoorz25j/La/TOqlLE+HPmqPp+PjUOGB7n8sT6ar9FHQ/4wqAnpE/OVff402ieG /G4wRupDSKZ8/D0ygR18OI7X+D52/JuCVyQrVilzlO+rlqs+V1eGLQm7qlnGjg2hR3hVeFXE7IjP tL/W/VPkjyN/HJUalRq9MPrHMf804d3YgadWxrkntk9qnHRn8uDkwanR7Dgcejy9ZNpz085M/3hG 30y3/uQsbtY79Hh2WkL/czcTTzx/8vmTSTuSc5L3zflRyvv0eKHvv83xk/+aIzVl/Bg/xo/x4z90 5P9fOarGj/Hj/8OjJXVL6u7xY/wYP8aP8WP8GD/Gj/Fj/Bg/xo/xY/wYP8aP8eO/60Ho/10Trg9l HtdO1GQKUZCE4NsoFwQ/RZmFMo7EoSWBKFi5IGhEmRWcjvJ1RlegnI2re1FGB/NQTmBlAtrnsl5z 0SsPZRYrK9Ayn7XPZ/zzGf98xv8iOPejzGJlBcoF4PwUZTSuLiAx4FwAfkpPZ2UCK9MZTx67ms/K AlYWsvZiRq9inKWMLmMl1TyLyc9immRB/l6UExg9HRpmQf50lHmMLmBlIeMvZvQqRpexsgJ9/wIH IauYzFVM5iomcxWTuQq60fYCVr7COIsZ/RqjK1C+jl5vo5yAsoLRFYym/1YqbhD6PVb6r4GVChbB GeyM0jzRcLEyrSAm9nfGKa0kSWRIplVkCv0L0IxWkxSuUKbDiHNUjoakkd0yHU66uGaZjuR7uWGa M+zfi8qtMs2RaOUJmeaJUvWMTCtIpkoj00oSp5og0yqiUyXKtJpMUi2R6TCyeFSOhkxR/k6mw8nL qhKZjuSWq/4akjmlAmNFhSllWklS1VcYrUJ7RFi6TCtJclgso9VoV4dVyLSSJIZlMzqM+i3MJ9Pw VVgNozVo14XtlGklSQnbwOhw2f8SLflfoiX/S7Tkf4mW/C/Rkv8lWvK/REv+l2jJ/xIt+V+iJf9T OoLZflamYXvYPkZr0R6rUcq0kqSHST7RUd00mTINfTSTGB1F//aVxijTSpKmKWB0DJOTKdOQI/M/ RX2o2SrT8KFG0i2O6qM5KNPQR7Od0RPRHqe5KdNKkqE5zuhJlD9cL9PgD5f8OZXyhxfJNPjDUxlN f68sItwn04hpuBSj6SymPpmmMZXaZzL+XTJN+d9idAKNafhZmUZMwyW/JVP/RPAyDf+EX2b0C1RO RLJMQ05EBKU1If7XhPhfE2KXJsQuXQi/LoRfFxIX3Uhc3id6ko4MmAfoSQkxklrUy4mFmAGBiMTK Wl7GmQ00LavRXs84UnHlJeSeCXUx2tagv0Ds7KwWdS24nSgN4CzB9SbWqidFqF2My4K2akjS4yq9 Ug0IbAwDeOg1G2lEm4XU/af0e5Qz64l65II2YfQsUsr0t8uy9LhLpMJLC0AlQW49WY2rFlynugm4 C41JluSOSV1BVpIXRiUvB+eXLSgZpfKYDS5IM8OjevIq5Nex8ejVF4CV6EflmtAiyv6wMQ9SqSlo KWX8AmvXk0LmR+pRM9r0iPYi3AXTsfZbiAPnVEsqx8FiRiNglONRxyQKLDL03Mp80oSrAg4aWT2p YX0FOTZLcXcpRFZIfW0hV6zMXwaMsppJrGdedbGxVqN8/LjSOeVdDXsdzAoD47WgNLDrVlyRLKBe Mchj1csSVsuyJOtpzuq/ZLmFeVNksa1HLPUs+2pGx3qcXuYvyf76XhqTbhiNs43ljsA0Xz2aw4+3 Xhr9y3otDvEBtUSyRWDjjcwOKl+y1YAWF7Pcwmbc4y2VPF39kFdrWWQtcilZJdEOnFlZqWfaOkcz V5JDOU3g+LMxel+fnjYvTV9irNUvt5gtgmit1b9ssVkttmqh3mJO1b9kMumL69cYBbu+uNZea3PW GlJL6ptq7fqiWpe+2NJUbdbX2/XVesFWbahtqrY16i11Xy1vpDHrURm5FpMhq7TWZgeX/sXUtAX6 pOX1q20Wu6VOmM2YwctYV6x8gTIvLxkdoIQWebZqV715jf7Vurr61bX6F/QrhWqzqVaEHrZ6u8Wc oi+tXy1YbPrCapuh1izo5y2an/66xaFvqhb1DnutXjDCjjoLrlTb9dZaW1O9INQa9DUirtTql64q fAlXbezEarMYHKsFfb1Z7zLWrzaG9EVdb15tchjQVbDoDfV2qwkDVJsN6FUPhtXgwvCpev3I4Baz SdQn1c/W1zbV0F5jsswj3I9VibEbqM22Wrtgg3XwXcjw6D4qazHTIKkeowi1TTQctnqMarC4zCZL deigULpaUrXWpoe9FgyF0iFYHYLeUOukzgWPsdZkfcSiJ674tG0Nm310VX0St0AcXCSo3z6Rs47N 1Sdx5bNxhSfxKdYp/kVxRPE/UP7wa1tU/7UsKsR1I2gn2mgPxxN7fIutI3Z2txDYvH6ylb/FrG8k dzHKb9H7SfylTPKTuApQmyCx7mtxrwBNveLAyiutrU/2Tagnn2ilcqZyiXKx8mVlpnKhMkf5DeUr ykVPHKHka+fTK9Rabh7oJ3PSbLbC30/UmZtALiuexdmTs8TC7lXVo/tCEnyG/JQ8/p+C0B1NJOGC Qfp5k5Dl/LV8fOT9ASG5KhX2gcv10lKba9Czf0H8I98MDpcsL8pNS1OQLmmvR4gO1XHuDP3OMTZ8 bxGO/x7/N0TB9/K9oP+W/1vQ2/htoN/hsQ/g/46/Dfoz/h7oLxTYBSpiFdgnKZ5S5IP+luIV0IUK L+g2RRvhFe2KO6A/VzwA/SelHZ+9BaVAFEqHUgTdomwB3ar8S9Cbld8HvUW5BfRfKf8KdI8qhXCq F1TY/6nmq+aDzlAtBp2tziOceqkaY6kL1ctBF6lfA12mLgP9uvoN0BVqAbRD7QDtVLtAN6s7Ca/u UneDXqdeD3pD2HuEC/uHsH8girC+sB+B3qd5ifCaXM02otC8o7mFT/6/09wB/Xk4JIe/Hu4iivBm LXaK2ghtJFFoo7RJoGdr54PO0P4AdL92D+gfan8C+rD2COij2o9AH9eeILz2pPY66N9qsYvS/i/t EOjfaz8HfVd7F/QftH8AfU/7Bej7WkRWR3SHsZv4qe4Y6P+p+wz0kO73hNfdiYwmXGRM5BSiiJwa WYpIKuV48uQZ5mHJt5JXZX/CrmJYVKKBrzRlGlikKddUgq7WrEZZp7GidGpElC0aN662aTpQ+jTY k2n8Gj/ogKYLdLdmPegNmu+C3gRfUS8NyT7h4Y05oFO0c2FLmjaN2XsD9L9r/53ZcgTlUd1RWHQM dlErJqKcFIldaeTkyMmgp1C7ZHsiSA93gKiqbdU1RL9atJnIkjW22kZSZKytsZFKU7Vgxl47gnCr ivP0JA6zJkifWxCtTKmIjvmGsJlCn1FEhpxz2KtHjZ5zmFWQVFhSoCeTZA4eu/ZomVbgagyZ0Fhr MxMjK82sFFjZQj8GkXZWrmPlJlb2sHInK0+y8nJTYxPWalYO05JTszKKlZNYOYPZr3xsyY/GWqo5 WEWfstCvHoRB3whYr4Nd9G/j0Z8Cegp+mQiLJpMpZCqJJ0+TaYR+g3gm1p3H93tcG09/Xf6hOpr+ re2vqOl+rQIrmgkru5sEyFtkC9lG3iO7yF5ygBwhx8kZcoFcITfJHfKAU3I6Lp5L4jK5PK6QK+Eq OBvXw23n+rjd3D7uIHeMO8mdhe0c4bgN0A21VoCGqCOPSHV0P91/Ey6mQPKUPlmqM96T6hedUp15 RqoXDEj10m1SnR+Q6m8ZpbroGFHCwdyrK4gaTua+M4uoYTb35gZJj+o8OhrhaqZI5zV5cl0p12ek 2nCA8SnrztRdr3uwJkY6W+Nds3lN35pB6cyYZMw2rjAapLP6xPqs+qL6Gql/Q4JUN8bI9Q3GpTEd MZ0z3WpSNsU3pTXlN1Ww1mhzrrnU3GD2mjeb+8yD5pPmy+a7lgjLDEu6Jd9SLmlspc/raF0oSbSW SPXaVKm2GaTafk7icxTKdQk8TGvcJcKzw330+Qu5SP8+UmsKkE641sOoFwJLQH9AiKcIdB7qEtS4 v7SuAEqBCvm8RoYR/CdRmwFBRotct8vALav1LRmU3ow+Z1Bvlc+7COecJtWt51Fvl/EesBPYg/ZL qPfJ5wcI8RlkNBDOZ0XtpOf8ZNc5MV/MEoubeQfPEC8aGJaIPhnrGNrFAYYucSOFI8XBUzTvkdEl XhczxFuui2Kh64pY7LqB+rZYLCaJAxSuu2KZ64FYSfmAO8161zEKtBeiPXT8BoZ00FS+RkYi+Cmi QFOkgKYY1VO4ImFU740MeaAlbGQwi30MgowuZtNA81syeHE/w1bwUoycbwe9PeRc9sOXzt97AszQ ZStwQDjefBjYCXoP8AHok8B54TQDte0ScEA8yHANdDowDBnDY/4XI4QrFA74kkKcJJ6VIFxkmCZe pmB9KeKpj9FvFurDjigxFfFJZT5g8UN9i9UjcZBiYm2+ib5Dkj4jsR2t5diOxHJU5ohPEW8mMw6y 4kJi92gsx3LAyfBVsV8IeuGf7e9mWAa/UtTAZxQrQFMYQRtZfozkyhYZI+e9DKWgKx7Lv4OhBfnT IueThF0MLTJGckxud9WJfY9D82b4aPND/vrzGOEbmZOjOQrbKUZzGPTWkPNHrz8ph/fB1hbgDPLy DPqN5CbFTeFu8xAwmq+gL42dO2i87gGj/FhThoDQ/L4Xkt8j2M7myMZH1xlRKW6kaN4JPXaGnI+s P8PiEQpHSksJxagtY+uTdC73b+5ibYW4FsXArlNe9N0T0n9kPHmeMZ0BMQbnMSHnj16PED8ETjn0 ooECc3AHw32xgQL+vkzRMkPC2HX0BVoS0A6ErF/rKFoI9MHa2JIszWM2l+X5Noqkh9GSLSNXwmh7 gYSQuU/X5lstRGygCMnHW6Frg5gBWzOE2y1FUv2k/GrRSWtcS6xY2DJFPIL16QLm58GW5DE/u06L OS1qsY9iZNyWNEdUS6Y8p9m8dh1iGJv3hxgenffyutGxU3RTjJ27DlF86V4zdv0YA3SVsZFiZN53 7BNuMxzoOEzRbG5NZxiZl7LdHR+g3wc0d2CzGv2wrneckdb6jvPAJZxfA27ium7sfGyuQMch4JG5 g9htpOg4D12Bx5/T+SLNgY4h8awE4SKFOKnjngRHHsM04TbFiF86hsXLFD6l6xhDBOiIsfNH7zW+ GHGA4tF754j9+NSkZftnwnbOGrZnDsfONoNEqRZifxvNdrZPYU+7ksSrS7Gz1bM97Sy2t3yO7QxT 6f/p8b/DXpwoZipmYW/9vCINn0/nKzJJjKIDe+44VRJ2z+tU2apfkO+pfqn6Jfec6mP1Yi5RvUT9 Mvdd7I/XcH+prlfXc++oG9UmbrvaprZzO7Th2nDuXexf93J/r92n/WfuBzpOZ+bex+fu23zm2Ce+ tVlADj4znkKdD+Az4tqzhNjxyW5tMWp8qltbBlQC+IS1tkE+t8pwgv8Cajfgk7FOrjfK2AL0yqD0 DvS5jLpPPt9COFOyVK+9jnqXjAFgP3AQ7bdQH5HPPySk2SajmXDNXtQBdj6RpNB3A0gRKSM17JlX O9mAHct20k8GsF85Rk6R89irDHMaoli7ZG362ry1C9cua8Kew3rdeqvhjqUG1A3rlYbbFiuoS9bz 1muWIlBnraesFywVoI5bj1n6GmiPw9YDlm3WM6D2Wwcsmy2JoHZb+y3rLBmg9li3W7yWWFB91i0W waIHtc26wdJgHga12dpuqbLoQK2zOi2l5hugvFaTpdB8D5QRV3PNt0BV4upC8xWitO61vmvdZO23 9mCMbab7aOm3VoGuwxVTU3/DFHCnWZMtEebtoBKtetc00/H/sixVsedAhD0B4tRedScJZ89CJrAn GU8hr6ZwPuwqdOQgYkDMiK8ZsYQNxHwHMcNezHwfdQQhFmzLLNjpwnoC/0jnU2Rgv2xJAJJlpMl1 poxsIFcGpQuAIpkeQYmMcqAKqANMMo2cccbLwK7ZmcLolMbsxtzGgsZca2VjkdXQWIKjnKEKV6oa 6xpNOGyom1F6AXqYGgOgNzCKHpsYH+AYqtc47jmG6+nTvQnw/xC203f4zwnP/wGxULJYqFkswlgs dIjFIhKpWjwakRhE5Ntksnol4vI0i8s0dbm6nMxAXHaRmdrdiE4CovOAPK8dRoyS/x+OxJEcIrBY p2InSpqwk2vaDGAH14Sd2pprqLFba8LuTMgimoashpw1VpT5DflrBgS2v+d/z/8emt7l7xJOlaXK Iry6WF1MFMi914lS/QYyUKX9R+0/ErX2T9o/kbD/VB8uapA9AzCQ05ySi+DSuFyuirNx67jTfAy/ jF/Hb+T3suMgf4Q/jeO6IkKhV6TiyFBUKoyK3YoLirvKDEWEcpnSoGxQ3lZVqoyqzaptqiH1QnWd ulmRqn6X8aeqT6mv4bgZlhnWHDagSdAs0RRonJqtmtOa6+F8eEb45vDjEbkRF7S8Vq9N1KZoM7VW ba/2A+1FnU6XqzPozLp1uj7dcd39SE1kZmRJZEvknsihKE1UVlRO1LIoY9TGqG3wOH0XjL4Jtoi+ 4QRkB/dynwXf5r4A/hh8m+eA8OCnfERwLx8d3Iso0XfFwtnbXfRNsUXD99i7YtnBPPa2WDlA37ra F6TPS+g7Y/QdKfpuFH2PK0zul4fx8tjbYrQffV9sXzCP8b/9EL+KvS22CKDvi2UD9I2xWPb2FX1f LIbxGtmbYjPou2oAfVOMvidG3xKj74jRt7no+2H07TD6bhh9M2xEy2hJEmyIwdkE1NNxdQYdHXR6 8GMmSZKyd1RKGdM5j0TJeuSxN8CozvSNshn0LTp4hL5RRt8nk8Z/m71JRt8jo2+RRY96Jka2dnRc IA+9CwBpzOlkJdpKUJcxH09HDPaRtSwGD49O3z0rYKN9Cv5PwUV/CZy+YUbfL+PIj4L0LSAF88Ne FiEV/0JwPp8JFALfHm7jS4LzMQcl7TTop+Huke9yXwwPIRt0PDc8xMcHB4kK+dGAlkHkRwNy4yPk xkdEgdYinF3F2VXC8QnBfyMRNKZcSnA99wI4VcH1yKZFfMTwfT4amBRs4xE3cO7BCjMiZwKXGpzJ zQXmAfOBe6QJOtzCiLHQ4RYfE5zJxwb7+aeQlVNQxwNPA9MhW49rs4MziZZlE6z8WqOrZT0/AtfP wbUW2iyANgtINFr70b8CWn0CrT6BVp9Aq0/A2Q9NPuEnA1OBmYAeSARmA3OCn8BTGP3RkaXR4OF8 eDgflv0Cls2FZb/AfS89uJ08E5Lh+aEZDmmfQpdPoUs+dKng0lDPA+YD94gLEVgEWU2IyyKM+ikf CUAGj3FgrxHe6oG3PoWnepjterQ/G/w+fGDkn0NbEjAbbcnBHvI001DSIB8a5EODfGiwDxr0PzFG quA+jP7RQ7GahChI8dr7pXjxzG/UZxGQvR6y10P2esheDxnrmYf1qBOB2cCc4HqWM1K2Tfw/0uur cohm4iCkDULaICLjgMRB9BxEz6OwZj16HoVmg+j9c/T+OXy6Hr0HoeUgJAxCy0GihZSjkHIUUo5C wlFIoL1+A86j/CwgEZgNzAkeJUo+DleeBZKA5OBvmD/60b8f/fvRn2ZdPzT4Bcu8Kaj1OJ8d7P+K kWYGf/rYkVRY+a5i1btK3g+2kZ3BE2QgSN/N3BfsxRq7L1jIvxQ8wRcEe/m/QP0K6kK0LQeKMHO+ Pfwz/jW0lyMCbwS38m+CNqJuRG0CbxNgDg6QGD4LHEuCA3wOrixlEocgbQjSrkLafkj7Nf8q2r+N HiXgez14gK/EeS2uN0GjKEhoC5EwIPcsD+n1ffTqZb2acM0CrEXPacjgqcjeqaEWQtozkAbryHx+ 6fBHfD64C5iFVyGlDhYV8hUYpRL0m0EDXwO6NjiVr0O9BjDiegM0agLtQO0EmjG6GKwjaiZ1OZkK q67yr4F+E3Q1mY9cfQnUUuSqVvYrHfEEbPkVbPkNbLiJkU/Al70YdStGqcMIBnxOWRL0w/Kr6NsH Tmox9dHAiI/gnxFZy4MfY1wjOOjYU1ls3gRnNWoj5EqxoT46wbvQU8W0fINxDYGDXYENRayF9rnK /LkWMlxkKtHBd73Qp1eORC//CkZZHvweX4T61WAVRj4hR+IqX4UekxEBgggQgvsZmQHshE+ysA4u CT4HKfslrwyfQBQ+gR13mMRCJvUE9PgVpI7EdkDWCbpDhog7RdSoPkuZ9VfB/RHToYTaBSnU+42A ScolWHKVWTIdetH30ucjM3qRGR/JktqYVVJGXMX4v2CepnGpYHEZQDac4A3M873ICJrz7/H1aG8A GgGa9xbAzrKjNyQ7BkgiZtwAZtwAVtMBrKYDGB0eQW6yvBwWocE8ZAdijTstnXk0mq+xvCxEnAag RRn/HaAyuBjaPMtXQXo1zmuA1bhuQC3lahlytQzaPQvtyqBdGbR7FpqV8VbABtiBZkAMLibh8hwr hP11fAGNAfOoAd5sY/6HvSRMztytyLYB6LaW6WYM/oTOBdzxC9h9v4nQd3z3sX6d+JREqSysUEuw +ueAfgl9lwZ3w8u7Q2ZBHWLXhNGelu39PolAjxKWadLMaWN6FaH9VWjwOqSNzAAt5A+Auw7ca1kE Ryx4Ffeyb8tzBfnIuFV8LYmFV64iKz6C5luRFbshg/LQDKtiUk/Ahx/LM2AAfhtgs0BAu4g5Eslm DZOK1ZSuVHXIVSNmkZRtdCYNYv27E9LrKj5ZyesRevaysWoxep2c1VQuj7ViKs1vzEI6h6g0mrdm 1BboQ1e1MHnGXmW8tGcj7ui4gnGuIpKVOKsC6NU6rCxGaNEU/CW0GQLXx+D6FT4dvQ/by7HyvsGs PiGvEVfZGtGEXmY2W/awdUIBziF2lc4dLbLwBEY5KnuK2v6JPMOop2i/jygnLPoE2lbKmko+/bXM Ka3Q4Xw5rozMVKyT7Ip5dA3/mI0YCb/VwW91jFteW0ZlUr0a5HnexHScz7wdMzrHp+NsBkDXnnJ5 xatEPr2JzK1iUTgxGoVGtJnlaKjkDDshrx0/Y3J1soyBEL/RuX9UjvsAve+BuxeeHmD+46iuiK2J tRuYT3ow8vcg+1OMfItligXeFuUIfjckCyFfXsFGuJBT+CQ/Yt1OyA7D2Ys4exG2noCtJ+SVZYDd 03mSzt5TIPS7PrjDJxD6lvxs+q0eMheHEvk2H58HXsShJgtwhJFFBHttko0jgn3rRUtW4dCR10k5 4lFBv7tCfoQ9Rgz5KTlCYrk53AskjpvLzSWTufncfDKF+4z7jEzlPufuknjuC+4LMo37I/dHMp3+ SCqZwat4FdHzYXwkeYaP5qNJEj+Zn0xm80/z00gyP5PXkxQ+gU8gqXwin0jm8rP52SSNn8PPIfP4 VD6VpPMZ/Iv0XoLV4UU+j88n3+ALMO9zsBNfQV7iV/IlpIAv5cvIMr4c/l/OG3gDWcXX8XWklDfC p6/xDbyVlPFOvpm8yXfxXaQGe/h1ZDXhYm89VQzf6LiDxESI0ABYASfgJnzjBdQ+QiruENJ4kJCG exLoubAO2AhswfkRua0X2CGdC32j4NxdhH+tRELjZeA62nehvjXWHorQ9sY7cn3/8fylp6R2/4WH rjM9GHbJulFdBghvUhNS+uEYL2pmk7Cf8bFxWH/YK1A7PgROAWfl8wsyfRmgdqC/cEfiGfEN5DM0 CGi/z9p5k06yhQF9HGRsfIda4gXY2FRGw/bHgl2n8l4r4X9lL28570uzV7Vc8mXa61qu+bLtppab vly7rWXIV2BvBl2E9ntor2sZ9pXYva1KX7m9qjXCV2UPoKXOvqE1xmeyb2qd5LPZ61qngaendZav 2d7cmoS+oGuN4E/1ee3bWjN8Afu7rVm+DfZAaw54+jHiJvvu1vzVxfb+1kLQ/Wj32ve2Fvt67IOt Zb5t9kOtlb537cdaDb5++/HWBt9u0FbQp1udvr32c61u36D9YqvPd8h+pazKd8x+o3Wd7zh6bfSd tl9p3YKW2629vnP2u607wHOutQ8yH7Tu8l0U+NYB3xVB07rfd0OIaj3ou70qt/WI7y7aP/Q9AM8p Py/EtZ71a1altV7wR6H9MvjjW6/74wR96y1fmpBIS+q32j1CSusdXwFa7qM93U18zcJCtxpluzvN t+2hssudOVq205Ja508U3nJn+/ofKje7s/0pwlZ3ru+YsN1d4E+X6fdYudNd5Dsk7HGXQE5ouS+k POAu9z0QDrNSoj9wV/kXCifddf4lwhK3zh9v72HannGb/Hn2c7SXM9cjBCYJee7YERtli266N/hr hDhwGoXzbpt/mTDkVvvNwjLGI3lAolcwurT1jl8vVLin+MrlskamZ6A0uhMgM7Q0u5NRCiHlPfcm RFDKMRZNYdjd4ws4lO5tvtuOCPe7vkxHjLvfL0h5K1xyN/tXCC3o64W9NsTrmtvrL4W9AX+FY5J7 t7/FMc291zfomOUe9LfTnPR30eivMmH0Q/63HEmIRcoI7T7mT5GyTraLRZDOGmMizU//Zkeq+zjm y3GMvnts7vi30iz1b4eGp6FhEo2jI4Na4chyn6MWuS9Si9xXxqxz3/Adc+Qgf0oc+Syyy2guybSR +Z/F11Hovu3zOordd303HGWMrqS07BkD9QydZf73aD77dzoa3A98GxxWD++763Ayrx5wVyETzCw/ Ge1ww5M9Dh88GedYB3qDYyOjt3g0/j2OXk+Uf59jhyfOf8DRx/zQRf3g2AUvGZGrx3z9jgH3IV+2 Yz+jD3ri/Ycd+z165HCKJx6ZIOXzCrqqgAe0FAtYRGNxBLQRGUvpD1vu+T9wnPIkgs7xpMAbZz3p vkOOC56FFRrHZc+SCr3jOs0ixy13rv+k4w6j71NayisnwUw5Q1cq/3mnuqzKf8kR4cnzVTl1nmVY GbBq1Z6k60NtqTPWs6JCT/1ft45m16oquoLV7qFrhf8aW82yGX3TOYX5X5pTUizaKU1XtjofXUP8 Q6GZ6ZzhKfXfcyZ4KvzDQiL1szOZ+blvjBaWjfmfrocBJV15/F3ONE9NIMKZ6TH6NkmZjFhjrjmz PeZATHODp6bzdrOVXm12empWFze7PUa/ptmH9rvN61j7Rndy5wOHrz2vi7f3eFqw0p7ztEPbgLcQ I/LeYoyIHO7SIEvL/NuhSexIbjdvaRnqipKyV0hB9hagPRtWr6BxlGPK/IyMLUD2Mj/Ttbczk672 ASVdY7viHDmY0dlSxlLruuKxin7YpUf2jmYgXe27EqV1lepMLW3PA90Lz3ibd7D5y3QTy91pXcNi FY21U41Yn5FXDBYF5iVZprPA0xWY5orz9gYOOos8b/mXOEs8mwOznOWerYEktGxHS7nnPUbTq1We nYFUZ51nTyDDafLsC2Q5bZ4Dvlxns+ew4SI4P2CcJ8Hp9ZwJ5DgDLLIbPOcD+cI1z6XVt5ybPNcC hc4ez81AsXObZwir6BXPPd8x57ue4UCZs9+rrNAIJ70RFXrnbm9MoNK51zvJH+Uc9E4LGJw276xA g/OQN8lfAc7UgNV5zJsRcDqPe7MCbudpb07Ah775/gq6jgXWSfdQ6W7lPOctC2x0XvRWBrY4r3gq Ar3OgNcA3W54G/zDlA7scN72WpFvd73OQJ/zgdcd2OXivb7AgH2vd52vR7qXuTTejYH9rijvlsB+ sa79TLdSNLWf744Qbe2XumPE5vZr3ZNEb/vN7mlioH2oe5a4of1ed5K4qX24O1Xs6VB2Z4jbOiK6 s8R3O2K6c8T+jknd+dI9WtzdMa27UNzbMSuQKn+KYPdreR1OovNdHPSkdBeLh9prustC84fOOMwI zLiuOPEYPg9cxMp8vTNgv0FnsXi8I6m7UjzdkdptEM91ZHTPCl1PxIsdWd0N4pWOnG6ro4yuqGjH KireoGsXVjl6Fw5Zz4VSmtvibbZGha5XyPNuJ83zbndoziOHsQJAzthqIK3MEXQ1Fu+673b7xAch K7NAZzrsRX6Kg2zWH6Z34dBVuoXvyO9e16LpKOzeKBg9KV3tzRew7p1uieoo7t7SEtdR1t3bEt9R GfiQxq57B41ddx/WltiR1TjkvpOI+3XCyHolZmNEE9YczCZXvHeHf4VL7+0LHEG5K3CEZdcSab6g HKCzxrvfX+FK9B4cbU/xHgl86Er3fhg4hfIUyoXes4GzriXeC4ELrjzv5UCva5n3Oj6Jsfi6Vnhv BS67Sr13AtddFd77gVvO2DaCHD5JP6fREvJr2tSBSpfRvSlwx2Vu0/nPuIS22MB9526UlbTsJK6W timdald724xOHStj6Wc5lGxNlkpXV1tC5xTZrrfakjtnuDa3pXUmOG1tmZ3Jrq1t2dB/e1suyq1t BZ1prri2os5MVma73msr8ae7draVd+a69rRVdRagrOssoPNr9S3XvjZTZ5HrQJuts8R1uK25s9z1 QZu3s8p1si3QWSdFDXZtgJfOtG3qNLnOt/V02lzxbds6m12X2t5944Fwqa0f9P8m7+vjokquROvW 7Q+ar0FkHIYYhnEIYRzAlucg9tIfdIjBO7QhroNNd4cxDGMIawjjOA52iDaMtMRlXIbnGOIaYwwx xhDDz0dcwxLDEMMjPp8hDuNjjePPOISwhrguIa6PZfGdc+69zaXF0WTz8s/+6ndOnXvuqVOnqk6d qrr9cUd3nmjcgePVuIvwHg2967XxnV2+bMDdgCd29oKdd3b2N7bIu+jXZnaeb9wv93OtbufFxoO1 kTuHX+e1cTuvll6G2kde99Uu2nmj8Ujt4p23oFfHd95WtdUu2TndeKw2PcAbT9RmBSIau2pXBGIb u2stgYTG3lpHIKmxv3Z1IKXxfG1RIK3xYu26QEbjcK07kN14tbYskNs4QmtELO5zghm1RwNSMPuV 3kAx7MbhvABrB+zMg7mwXlwL2mo7gC6oPVl3PijJ+6Xa0/7xYHHtmS9WBRNAZjxoQ36wBPdIQR/S r4/LMsQvB/4E8GndQU8OVsp07VnQWV17LlDS0FU7GPDBHG+t6wpuffUk7g1qaW+AZ5OgH08Br49v zca5494c4geRH2xGGlZ2lBnVrllbq0HPptorgfKGi7XXQT4JZPaCbWMg34b7hGBr7ekvxoGdsENo zHn1TKAyWFzqqxtuzCF+G/KDh3AXEWyXZWpvBqobttROBrY2DNdOIb2dIY2nJNWH4QQx9Xo1zMq1 weOveL64ONipeDXSp5CGvtLwt5YE/A1rtxsCgYarMBb+YPb26EDgs13b4zHOQJ9AnMHdSDAJdyPB HqL7iB7YnhgI4s4k0Aw7Q1hBgrno4cELW2cCrQ273L2BtoZbWhrlg7koDzLFcF4r3J4cONRwWxuv kA4OIf38wTl8XOsv01p/jeg0Ok+NaOnaA4H2hpbtqYHjr3M8AwbT8LQVTJH3MNuXfqkyOLrd/MXV wXE8f0GLUgKdr1dvzwmc8knb8wKdEGOdgZ7gBEQ23Oefgj1DN+yEQztYPD8GI2h1O070HaSfX0+e ULK9MNDXcHv72sBAcBTi9paGbnkV2L4+cGFXWVNek7Op0N9af3NXmb+5fqzh/La19RWwOp+or2pk 23rra173+VPqt+3uqK0I2BpvyNifVl+3+6Q/o75h9+lXPPVNu8/4s+v37j7rz63ft/ucssM/Un9g 96AcW+S577fVH/ZJyglXPtvKp1rtiVU+q9Ip1V9QfzTsrEoruF+q79h9yV9cf7Jxk7+k/vQuh99X f2b3FX95/dldU/7K+nOwTyM9/ur6wd3X/VvrLzVuluevPBOx3t1jymkafT5X9uQ58TZkye6b2giJ Y9dwFc/IwRS5XRQxEuTztRyX5LmMK8juSVxBdk8qM53moN//xYrdU/5A/ZUmJnuIP1h/vcngb6uf bIpWnk7QEwP/If/lpnj56YS/vX4K+lZ+FkGnfv/xBtaU6O9sMECN9MxB7jf5qYK8z/RfaEhtytGe KBVafl5BM8h/qiG6Kdnf0xDflOrva0hsWuofaEhuMuP/g9Bvw5jmt2Gcfhumi3BGuJmefg+2mH4P 9iT9Hiw1YltEHVsWsTPib1kO/dbrY/Rbr+Kop6PMbH3UP0f9lvno92kv0K/RXqQnkKnMyhgrYJ9m Sayc1bMV7MuQ1rMW9iZ7nh1m32Ab2FFIpayDdTIP+yHrZi+wfvYu+wy7xn7NXma/YePsNXab3WVf wrejsN3CHqGZdQr7hXfZ/xDeE0bY73VVus+zf9e1677N7up6dG8Lou687h3BpBvT/VZYoLutF4VH 9an6jwhPGfYYeoSPGHoNbwtuw08MPxE8hgHDLwSv4f8YDcJLRpPxMeEt44eNyUK78UnjTuGoaacp yPWmL5taeYzpK6YD/DHT10wd/EOm75vO8WdM75gu80+Y3jPd5p80/XtkAv8cfmeSvx4VG/UI3xUV H/UYD0ZdjfoNb47+QvTX+P7oyRiB/zQmKSaJvxOzOGYJH4p5OuZp/suYjJgMfoUJ0C9V9J2oZPzO kbQYYAlAOkAWS5KWSOlSlrRCskgOabVUJK2T3FKZVCFVSTXSNqlOagCqSdor7ZMOSIelo1KHVIO/ z6KxZREfi/gY4/hOEvolWzzP4BmM8VyeywRu4RbGuZ3bmcid/GNMR09VDdzFXczIn+fPswi+gXuY ib/AX2AxvJy/yGLpeWoc/zz/PFvAX+Wvgs7XuJ8tpKeqj0F/p7JEwy8Mv2CPQ5uG2VVqWTz+Sq1o Dysv2lPUUrS/6GDRkaJjRSekBCmpqKuou6i3qL/ofNHFouGiq2umi0aKbsDV+aJbRbeLbkv+omkw KMIV60pwJblSXGmuDFe2K9dlcxW4JFexq8Tlc5W7Kl3Vrq0uvyvgCrqaXa1F07MJyskpQ0nFobRV SW2uQwDNrnaA465O1ylXj6sP0oDrgmvIddl1zTUKEuOuCdcdF/5nkmD8FvTmojl+jv+0sILVgNda 2HbweSf5+XPg353MBR7+Q7YW/Ptd9kl2A1Ix9dGnjE8ZP8LWGT9q/Ch73viM8RlWYsw0ZrENRrPR zEqNOcYc5jFajBbmNeYZ85jP+AljIfu00Wv0sReMZcYymC8CO8iOUi8vYXrG1vQA9CkwQHnemtNr zqw5u+Yc4ME1l9ZcWXN9zdiam2sm10xJTDJI0VK8lCglrzkjpUpLJbOUI+VJTqlQWiutlzzSRmmT tFnaItVKO6Rd0h6pRdovHZSOSMekE1KX1A1XvVK/dF66KA1LV6UR6YZ0S7otTT/Hn8PvMAoRL0e8 Sr8JjJzTW9shrWA/h/Qsex9SDsz6X7OVbAxSrrHYWMxWGZ83Ps8sxgpjBfsrJsAsiqRvHy9lRsY2 rACwMMGDuQNgNRPs15ng2Cxmb8jyLN6wwrOEcpW2eNI3ODxZBKs9KzYUeSxE4711HgfJ4bUqh9du z+o5eso8RXN0og6UqfCsC+VVHneIX+Mpo2uV3uapIFq9r5ZBe1Q5vIf6MUfA+3VwXaepF+kGsLFO IxcOWC4c0AYtqPWFg2qbFrDtar+ocqpdaIvaN6r9yG9SbMUcYS+0UwtYTgVVFwLahu3EfB/Ujf2D 5bENah1q23G80D7Ugdco61bKoKzaf+oYaW1U9RzwVIX6FuWaNLlqy2FPDeVHPduoDOpSc7XuurD6 VNuxHI4v6uvw1N1Tvims3pOehg2nPU0bznj2zrFTq3s+WzFXbVFzh+Ya7cFrtX+wbWq+N+way6DN qrw6F/CeOjfOevZR7girK+s+7VfbmxXWfvVa9SF1bKGu0myZF56HZLDOc54D7mTPTXeqZ/Ie//iA vDT34e7PkQvv74fIS22a6/B+doSN1wfkZIeWD+2+b670S3hflxbI/fSg/IH9qLZD6/tYz6DncGiu XfIc3XDF00G0mqvxU53L1z0nQ/fGPKfJV256zsyJw5OesxumPOeoz1R/hLrdzDPoNnguhdoI99zR nivueM91d6JnjHhqfICy7qWeKbfZy8gXVZ+E3J3jNbjzvNFupzee2qLMLXehNxGhtNw7XVrp4yhf Wu2LKN3qiy31+xLQX0sDviTyW6inNOhLKW32pZW2+jKwfMhX5xvjfZp5o/BL26C+896DVM+h2TpC 99t92aXHfblz4kfRB/jm3rC5He5T4TElPC6pfQR+VNrps6l2l57yFZT2+KTSPl9xKA6pNqwIi0Oa Ncq91puMEFr3VD9Rrt3rvaluj3cpwUav2b3Jm4P1uzd78wi2eJ2kp9ZbOGdtQl/Y4V3r3uVdr13f 3Hu8HlpzVVDk3S3ejaRnv3eT+6B3c8gfw8B9xLuFQLUbfeiYt5ZsOuHd4e7y7qL+UdZud7d3j6pb nT/uXm8L6er37sexpfHV1nHRe4T8dth7DNuLbXRf9Z4I6Rzxdmn7y33D2+2+5e113/b2u6e950u5 92JphHe4NNZ7tTTBO1KatK62NMV7ozTNeys0h9Ef1PHU5uHjnvWAPNy/VoTlCr9UgrlQDPZr/U1d J9T1UrsWha9J4K+lJYq/zienrkMYW0s0ewUlL/XBfg7GW81pf4f5g9r5QbEW558kxxI1D/Vf+D4j fP1T24bXe8NydW8TFpPm5PezVztf92nigTLuofgTvq7eL26EjyfqVutX5jD29xbLFsc9e1vslwFf SWmG9zYC7WEQ1HivxgYEbDP6yQWfLzSHUZdmjqrzL7Q3RnvUPQmsE6VDvnKc7zjvqe7Lvkqcf1p9 pdd81ffsvTV77tJR39Y5+2UlRoXqV2JRaO+MNo/7/DQvYR6XTvgC6vmg9I4vGOo3xc7SGV9zaLw0 e1dPnO/QHJ/FNUrtIyjn0flaPZG+NjzFR7wR8XeMRS2n/xcajxpn+L+3aX/Z5yt6kd2l5ygv0HOU zxh6DT8R9tETlDZ6gnKEnqBcpCcov6InKO+bdkYmcCc9Fxmm5yL/RM9FfknPRX5Fz0V+i89FxCR8 LiKm43MR8Wl8LiKa8bmIuBxOtO3s+OzTg1UdrHBVx6qTq06vOrPq7KpzqwZXXVp1ZdX1VWOrbq6a XDVlYRaDJdoSb0m0JFtSLUstZksOpDyL01JoWWtZb/FYNlo2WTZbtlhqLTssuyx7LC2W/ZaDliOW Y5YTli5Lt6XX0m85b7loGQY+pm5IjFIqJbzaT4A0AD4JiCjFX0qGnW39MCJfYjvhVHsC0io651rY L9hFOMkOQbIKPxPOMZtuUPcOc+DzKigpMDcrm22v+RxbsjJxZfLK1JVLV5pX5kCeB1TeSufKQuCu XbkekmflxpWbCDabx1ZuWVm7cgdcbQS8Y+UukEpeuZFsrAAbH6PvAjLwHvz3l3RIHM7S+G+4GZB0 LIstY3q2nGXD+fpZlstMYFMBi2GrIcWyQkiPMAlSHCuCtICtZZ8ESz/F1rEE8Dk3W0T/VJfEtkH6 ENsBaTELQPowOw8pGdr+DntCiBVi2ZP0X1w7Ztu6PFLMtjqsq61F1nVWt7nVWmatsFaZS6w11m3W OmuDtclcad1r3Wc9YD1sPWpdZO2wnrSetp4xjy+3WM8SZFnPWQfNQ9ZL1iuAr1sHQWrMetM8am6z TsKdypwB8x3rlHkC6nGArBu1Wo+ax2eTzWA9KyfzkHnIFm2LJy1qGpSTLdHGrE22ZOsi2xHS1WRb ajNbp8AeB2hFcFurlNRE6SgmsGobwAGw5wxYsc58CEpMWeNsqdDac9YqW44tD9p/FgFa5AB7nLZC 6zqg19nW2taD1rOkQYUGsAahCWzbZx4lAO02j20j9NIk1DlIgLUhOJ7tt21CvWotpFEFtAHAthny CiiFUAW1KGDbYquF8bhkrcnh1iu2ZNsOa4Ntl22PrYXqJxuWHaPWaesGsO23HbR25Axga6FHkVIB 248lUdJhzybb7oH5+PZs2x47n2O/Buge2GzPtR2x2+wFIQs1MB8feXaJxmswHJBvL6ZRlgHtwL5R 7LcdM7ctt9hO2LoAI3RDP52FketdXgRX/bbzMJ4XrWW2YdtVaxx4Rg356aBtBMbwJvjQDdstc7t1 zHab+tBtm4Y2QE/aI+yx9gR7EtQIY2hPsafl788/aM/IP5J/LP9Efld+d35vfn/++fyL+Z78YfJE ZSSxhvyr+SMI9pT8G9ZLcgm8l38r/zb5jtqjau9V2aJDrdL6ldIL+dNO7oxwxqJ3OBOWrzZP5Iw7 k8hX9zhTqAT0zfIVy1dbTy+3mNscBxyHl1scRx1Hze2UJhwd0IYUx0nHaXO7Pc06+Gw/zLVKnG/m IccZx1nHOceg45J10HEFosEi6KsGW4v5kPkQ3LnuKILZ3OwYAy03HZOODnO7Y2rZdD4D29blG/Kj 8+MBEvOTzeOg6QxobctPzV9qbco35+dYD+fn5TvzC5en56+lO+uhvzbmb8rfbHXkb8mvzd+Rvwti D3rb6uUWe4ndZy+3V8J8MOAMhOtq+1a73x6APGhvDnlav73V3mY/BB7Xam6FGFSmzh57uzqL7Mft nfZT9h7o23gcE2uNvc8+YL9gHwLvRLhsv2YftY9DnLseAprb9gn7HfuMQ+eIDPdUiIZjCDg2jjjH IoLFjiXoO450Rxb5kEqDFzlWOCwOh2O1o8ixzuZxuB1ljgqwvTnk4aDRUeWowVnp2Oaosp6EWIlw WvY7R52jwdHk2OvYZ52EeTsF0VIq34/R1pnmzADIzt+T3+KIA092WIucuRC1DzuKnu3PH15ugZTl tEEdY+ZRWzxGY/OEs8ApOYudJTDqrdYx8JRxp89Z7oT+dlbb8pxbbcPWMXur0++YBE7AGXQ2O1sd V5xtzkPOdnMQ4ljesiPO485O5ynwkqMUc89idHL2OPvIX09TpJcjZSVwxq2TzgHnBVoLX/ovtIOq ZDX0zBz/yZ4tszEBIGGZBZID0uplq9MH0geWFUFaB8kNqWxZWfq19GvLKiAhr2rZvmU1yw48XfV0 1bJtkOogNUBqgrR32d6nLU9boB4e8ULERvqvxY+zT0C/rmHPwb7CBbsDA/tr6L0o6OdP4389RI9F T5BF9FlXXh8T7D7IByAvF7PzeuwleX0APQogPQBwQYEhgMsKjfeuKXIXNHJ4PRqmZzxM52VFZkKT 39HwZ5RrhbbqFFq9r5YZ0shdVvRfVmBCU6e2XRfC5MJhYh6YCYPR+5QdnQfG56lTtemCpm+0/D5N 3qe0UwsXNKBt44wir9o4pFxPhNVxWRmvUUXHZUVWLdOjKaOOUXh5yK2RGjsnwnLFFmucki+yz/pG T1jd89Wn2n5HKb94nvJh9VqXAKQDZIXZq9U9n60TGlvmy0c1+ZDStvvllxWbVXnVzplZu60rwtof 3g/h7Q9vd3iunV+XlbpUXnjeM1unFVZW616AffOP7581v1+/P2we3s8fNF4PyLHdD8zD+ljtpwfl D+yHcPtV/Y7ZsbeuBihS6CKNHRpftq7TyLjlfrKW2efEYdgHlVir7LMxQ42nNQDbNG3ENtcBNAA0 KTw1PkBZ6wGAw/bQXAzNyaMAHQAn546x9bQMsLsqsR2T5W0nALoAumVftPUqPgn1wF6oxHYe4KLS PtVXP2guavhUV55Sj6YO9b5tGOBq2Jh+kG8+yNfCY8p8cemO7Ee2kVm7bTcAbgHctt8bl8PjkGa9 sJ6RIbTuqTFCubaeBTinwCDAJaX+KwpcV/SMacqpvnATYNI+Z32zTslrrgqqvI0p/WkAiNa0Pwxs 8TKE7IZ+tCUq45MMkKr4kLJ225bO6lbbbTMrunLksaXx1dbhlPvKVii3F9toW6vRuX5uf9k8ABsB NgFsBtgCUAuwA2AXwB6AFoD9YWMyOk9+v3G/X/6wMW7APrt2zLf23C+fz1/nk9Osy/Pm15TxDs8f 1L4HxVw1lgzY7+2/+XK1TQ/KNbFo3vxhxyc8HtxvzXzYNW1UU7+654P+9TTb79nbkq9OAxyUgfYw S8Lq1e4DQb+d22fn8J25c1Sdf6G98YQ9tCfBdcIeIc93nPcob4+V559Wnz1h1r5w3ajXnqRpl6Jf G5/UWBTaO6PNKUpbYR7b0+yhPa49Q9Nvip327Hn8BO7ZC+xzfXZA00dYLhfAZi/B7z3Rf+Gz/zpn TaEF/yudRQuxzMFYZgRALEACQBJACmNPlkOeBpAhwxPbIM8GyAWwydfEK4C8SZGXZuHxBsiLZUBa vY+ymSVK7lP4CJUA1QBbAfzKdUChgwDNAK0AbYqMalOJAljXIUVvO8DxMNtL7gOdzJHRldGd0ZvR n3E+42LGcMbVjBFINzJuZdzOmIZ060OVwKOUyTMjMmMzEzKT4OpWZkpm2oeKMzMyszNzM22ZBZkS 5MWZJZm+zPLMyszqzILk5sytiTOJM5n+jBuZgYwbH6rMDGYGgatNfvyu573f9KX3P+jozQ+P0hse FtEbHh6ndzssprc6fJi+45tC3/HNpDc5LKd3OKygtzc8S29vyKH3NuTSextW0Rsb7H/x+gQhXpC/ NdvNnmEsI5Wxxw7KkLEUwAyQM8vTgpafkafkzvvIJ8r8jMKwcmtnr+m+U6HXyzoJcu6tD+CZZzqe ORmWTmvoMxr67H348yR8JyF9k5vR+z3kN3vo6ZvckfRN7hh6s0civc1jMb3H48P0Bo8UelPHEnpH Rxq9lyOd3sXxNL2FY+n/N70CO8G6Zj8DWryXuR4dUtNT5lkarpZqr+ZPcomnlqLsUzky3Hv/g/Rp JO6ES+KTQ74f30/JD/MfQVh/m/+UJfP/yUfZU4bXDK+xj2H0ZAVRP4zqZR+n94okAsQr7+d4MlRe B+UhlvCjvJvpeQ/oSqIyi0FiEWGlPxLOMSHhLJX7Gr3tAt9OmstsGoljLD6h91Ge0pV0K2Uk4URC F6RhSMcSuhN6E/oTzlO6SDrw0+RI/m3+baj7e/x7wPk+/z7j/CQ/yUT+A/4DsOwfwRo9tGmARVBr IsGyH7GoqB+DfXEw45qEAXp2t44tgNphlj2Z8ABIuu89ISGRuRIkSKMJo4+WQap4tILoqkerFo4s HEE6oTKhEq/xHt3nkArklHI55XJIjn9AGofkh1Qwm7DsHJ2qnDZJwFNhFCTL5DIomzKeMr5wJGUC 7ONoH5XPTbmj2Mfh3mXVKk0NnMqTPY/WULlR1Qrgo13XII2mULsTIiBVKkltw0TCBI0jvpWJ0buN BJPH9GnGTS+YNjKDqcJUwSJMm0yfZSbT50yfY1GmL5i+wKJNW0yvsBjTNtNr7JGH9mFB6BDu0Hhv g30Li7c8PCRXwQrpAdh4L+A9hIWb4Xq9nMO18MQuyl3xOQtuxl9cWLxQSu6PX7+weMHNBTfhqmTB YPLV+Ivx5vj1cLdkYUny9MLi+NTkkfhpSOb46HjzgptP8OT+BYMLBkEOEpbD0qBvWMmBF18I1GT8 cPymhT7IzSosLE7ufyIBSgyC3mmQm5bltEC2qXCPjcnDZON6oMG+hRLIkH2Qg21wr19r06w9wFHs wXai3vhUGdCu+E3J55Mvxg8/EQGaJ4GzHhLUAiWGn4iN3xR/9YkUHCX+BocYzb/Cv8JM/Kv8qyzS VGoqBQ8oM5WBB7xoehE8oMpUzWJNL5teZgvp3VQJUb+P+j17LOoPUX9gifT2qcf/qBjnBigGqKYo t4R+Y+Kh7zLkKZFvCcn56RsHAlutkctmm/A/ZkNyAkSjvweP5hCPqH6qLZlqwzcAR5CnM/J0HXm6 gTzdSJ5uIk+PJE+PAk/fxmJIE7aBURv01IaPUN34NiK0XK77KbKxlqwWWE2Ix5lPsVwrJ1stsEKF 96dY9qC2zm+3wPYr/d1BdacSr0Gxu1fDu6D0t1auW7G7RuHh/3v/Z3wGvSXxvi0wkCZGmgTSxEmT SJoiSAe+Y1t/rw1USxTpj/2AMdzPTmvGUOZ1s3aN78m8aqU3tLxWpTdU3p+rLx6mNf+Z3pqvL/A/ gs/TriAJ//crNpqx6FYCV0xE9Ej0iVgdwZHoE5jH6mKCsZHRJ2IigJLvx8XGxXTGBIHXGdMJVzpK iwgvjl0M3BmCCExzNar65DukSaMnegSuRlAaawMs19wZg78MEk2fMX0G2lxjAo80vWp6ld4r9pBr EztJI6h8shl1iMAVkx2TG2OLKQAsxRTHlEDyAZQDLzumMqYauJVwd2uMPyYAEIxpBn52TCslieRt JKtNczWq+irhOps0oZ4SoEuAkwv3/KCrOaYNOG0xhwi3x+D32Lip3LT1T21hZA+BK2o6mkdtBJiO 6o2OiOaQIqJjMQGnPyoazk79Uf3IV/KE6CQok4IJSsQqKUlOUGaaNG6iErJGVV8/6pI1AY4l6Tyi OGjjUD6NQMZJ1MKXTJV/xPrBYf9/iaKUPA/T8J/rhGwhl/XBddscbrqQRdGsYQ43WUilmLh5DjdB SGIBuC6Zw40U4uh3lo45XCYY2Hq4Xqrhcnab9tkJId7s6D14hsfzI/ybIPEtfhSi/Hf4d2Bn3cE7 oGQn74S+Oc1PMyP0zdssgp+FHjLxn/NBiD8X+Tsshr/L32WP8GE+zOL4ZX6ZLeDX+DXQ+T5/H2JO d1Q3xJwfwa78UdiV/xh8A/f2bxJ+g/BX76Hf1NCtGnqfhn5LoaHtwnrBA3u/DKXtHyVekbAO39Mw h1cgSMDTzeHlCU64ujWHt0LAbwhcmcPLELLhamAOL1XAM2HXHN5iAfcFh+fwcHQFWL+1vGghnlZw LU8nRMJVhZbHpgWuWTNk3iSb0qwZMm+cTWjWDJk3wm5ofOKj5Oc4/oxit0Cxm1PsFiF2b4adQDVE cGP4SJiq7hmJVg3/vxNdrqHLNKP1poZ+4x76LY3MW5qyb2l0vqWpS6b/Zo4HyDS2dwl9QxTPpHKL 02eloXXyeRbxScCR+A/T+OZMhTsndhlgl2/MZi5DuaHYUAlQDTgF8q0GP9ABQ5ohCHSzodWYZWgD /iFDO3DK4d5xQ6fhFKVKuKoGyTTgyamcklbjrL6thlbQgJpm9aBcADin4G4PAKY+SG2GHja7H3vY 6HxdWEQtxO/GMr0TAM47ejjf6DcpNMQk/RYlr1XoHQrsotylL9bb9CUAPsCxkJfrK4Gu1ifotwLt 1wcgDwK/Wd8KVDHca9Mf0rdTKoErH0gmAE9OxZS0Gmf1lZMu1DSrB+WqgdMOd48DYOqEFNQf/xP3 2w97sowV1lPvbYHzBtPDjkW8Ngt4rU+eCyr/kTsAMzLEQeyJi5R5cXEAiwDAW/Wps6DodImj4qhu G+Ah8bguDvAdwOOQjusi4U6drkEXCakJ0l5xSOfQ7dNl6VboLJjE47IkyGbJCbWFa5zVR7pA06we KDsqjgPPAvU6dAfEO5CvhnRY5/iz7T3/pL7nB6B/zLOA1/z6XCA+xG8xBwDipAjeLhYqgPRaAJjj Ing9vzkLeA33XbwK0hSAm2fxfYDrANdAyuJ7eRUswgbI94rRkOLh7lkxkZ+EVfIMpSxFMgufVFGq UpJWY0gf6kJNGj1Z+N+vwDkD9Z4VkwHX8XP8nJjKz/6l+57evjql2U3gM8KImZqZ6BkbQQ2A7Y9Y WfA8J9BoYkweuJsbitFMdxDxXYj0wum7QAujiHmabgd+VkOcPpQXWiA6AT2DO55R4vTNDAFOJpmM mRqiDShJ9CRiNmpoITwJnDJDLNZlQL9ipIcZtpD8EK0cDL0Oz62gnRGuAM6SGTyx7qe7tNuQ9xJC HWIeQauOvBs4QPgi3V1INK3qwiTR8i5ilEqZid9C+Dxx3HSXdiRCH3FoPZP3MgLtBXkB0deIDhDe QziNMO0t+QjhHqXGdNqVpJPN6aQ/mepNJ0vSqUWI20me9i8w6xCfRizuIm13iC4kPEaStKuBfpHt fIThExPk1JDMOcKbSM8loun9z+IKxLpOwlmEi0ibvH+hXdHdYaJpF3a3iXROU9mUu0PYOsTCJNFu otsJZyAWOdFb6O4hwj2EF9PdDqIDhI8R3kf8tYRrCI8R3kWY6tLFIWZTxsWE8TnSFHnUgMyJSCF+ D+EAedQkYpJk+ltEy/wW4qQTZzFhLDVKvkc+Dz5Zg+0iP2/RUz8YcSZ2Eb5COrsIXzFkII2Yp+nJ B7AUTzOUISb5UdIwinzA+P8tozKf/H/UcAl7Uk/+iRzAGYiNZsIF6IeEJ7EVQguWFcr0OCPKSKZM ljGcRkx6+kiyT5FkhGupx+TZJ+MW6issW0faEkmyju4mGuoQ411egHfBztOEr1ErBggTX65d34yj b2hHzTqMKlOIhTrE0Cey/gqSHECso3hCkl3gywL/LHnpd6j/rxDuUugsorNojOSYYyDcSRyKLTM+ KMtmCrGWmSMUqeR4FUfRqYYwypQRv+xuKvkqxqhEwslUKpmiWbIcwWY+g3OcONdkDSQ5KmO0RFB8 hnxglPq8jEahjHq+juhE7Gfwh0nCNOLUM4kkn0i9OkW910f9OSWPHfon2IDtvQu7K4iHKAN3ZRr3 zD+hMf0D8W8RfyHRo4QvUoz9FeFk3UuA86i30wknEGYKTiL8EmEDzY4uws8Rpmew+jcJV5BMKkWw YsIvoCUMTmd3rzOSp8/oGJ6yxRoca5jRBxHLvYSzRqxBLJTN0HzHvo1Iwf43tCDWr8Ye1h2kUtGI dbnYJ2K0vIKg5+ibZT7FvWNI6wewbyPG8K6B5qzuOvX2AFoC0eYC4Pfv/ivg71IcW4y0QLGRTyp3 Ea8imTfIG0m/0E8cRv5DawHIXKDohxpqCD9Pku1E71UiczXFf1hxeR32jPgeRnh+fmYX0Sj/PLU0 Dmk9RVrxNfYtwKfkdZNWhD7E4imql85UuiiSrMR+Ft8j/79LI36X/OEWxb27GA9nhrD/ZyZotjKI 9MLdf8Xx5d81/BvgfzEux1Yb8Az2Xf117BMZG+MRG1JQBu+Kv0M+P4UcXT3x3ycO0+E49uvgpMjX 6pYi1lcRH+aO+ARyhG6iYxHzpbK83oEycO6BnkdtLBnOPyCvrwT9vbpT0Bsv6vcA/b+R1nXqiwA3 IdbvR0n9N5HmuxGLO/Swe9G/TRwrYmMUSX6S+Ez3Myj7N6Tzbd1KoH+ItPie/m+BE0eS1aTzNZQ3 XqBSn6Qah0j/c2IQsFX8MuAl4stUFuwU9WI9YIc+H3CViLhTBJuFQ+I3Ad8R4Ywu/kY8A/RJquW2 mAmcnxFOEV9FPaKNODgLXhQbwP6/F/8XyPfofgOcn4odgH8g/gDKHhAh1olfEQ8B/ifx+4A/JeJZ n/FDhPFEzYQToKFcwD3bd/lRkPHC3lIQBaT5y8Qp5P04skgLe4nfxkG/UI+1CC0kc4j4P0c+SIIG /neiTJ9BPtJ8FfHf56cIA0eXjBhoLPu+gDNuO9FMSEV54es47sKviR4B+ibH50OvcPSQ2xzX2ZXi /wX8pHAY8OeEzwP+b2RVGln1vPArKvsr0vkvRMNaw1cIN3CnhHxhL/KFfK4DfiRJ/hvhBOEdxLA7 QxveIQ3foxaNUKku4ncQ/xjQK0jbs/yXgN+F/aPAHqd+exR9Q9dJ8adCbwecreMYqchb3qBRrkW+ 2IG0wUg++RXyyZfo7luEv0OldpJP9qFPgkchP5UkLxD9dfK9TSL0j07P/wHo5eJfo0dhTBZ9aLlY ptcDvi7C/lz8hvhpjBUijj5D39PpRYjYAs0L/TB53Y8J7+W/B/wO+d575GNvIJ//UPwG4Gby9l5x L2h4HLXpv44Y/BDx+4S/QPy3yIY21Ca8jfJwPkI7D4o4O/rEH4GGGPGjOAqIxVXiY0D/nugNhKdF jHLfFL8N+B9I55fENqodsO6MCDOUZ4o/hqh1kHahcRj97iYRzsX9M+wJAM90ECeLsEHZXe+niHeB 8Hu0Hv2E1q9XaL0uo10W4hZ5L4Q7Q1iPaIdA628d3U0kXIa7RKHOaKEd0WLiWGjXdIv2BkO007PQ 6hYgejHtvkiSVr1H9N+nnefHabf5LOK7VrIc99W0n787rpx6EG8hDu3PYaXB1YSeQM7Qfh7qS6fd OLaUnkLCmQ1XB/ruCJ6jMaKSZAfDvVYZyThJ83Kiu2nFoXOWSCcFHWkQaeWC8x6dCHAt09Npgj9L 8nQu0NFYGOiEpRuWTxAoKZ66i56WTXp8hG2Ef0d66NSmu00cP9E/IM1vy/K4iol0ihEOED1ENcqn sK/jvk7sRcwt8jqLMkb5tPUMrZUn5LKkbR3pv65IQinjE8S5IZ/XSP4SYn3yjB/kv41YdxAx/2fC d8gT/hExzGe0pAF3OHwt3hXOE85BDbokbJ3urHzOQnnxd6TzKsm0435GpHEU/0D4rwjTDkT3EaKj 6azxKFl7gjRMk20e6ucWxMbN2Ap9BWLd8N0C2iGAJN+G+nVFSOucNAodhOWT2grqyXMkmUOcIfw8 naeRVacQ8z1Ev0rYT7iQ+CNEryPf/g/EOpproo32bJw4P6ad1fvyWYlwBPWJAfwUZc6RF+GO4j9I G+3xeD/yeSHdLSDfGJPPlaQ5nyQ76HlCO3EW0XitJ/39/4+9746r6tj2n7Nnz5wDbBAFFRUUuyLi UTGCvWBDQcUSYxdsKIIClkSNSgwao2jUGPUaJSaxYe+xG2ti77HXWLCX2IU367u35/reu/e93/3j 994/L37y3Ys1a9asWTNr7Zk9mw1Kd4NfGBgIfjd4rJUZBVhDLsl9rmpthP3n0K4/6tYB7Qt8jlbu WjIDIT8Qo0z+zINe9AL2hvxceHsO8Bzaygud9aGhM/AvUxvG9zA8j/MnWzpWfYXMCEUrWzA6t2E5 nkUI7GJEJnx4zbKHLOGoFQvOGNJjKwHNR6HnKLyHJxIC0a3WBNT6ApSakahBfjtKzUi/Yq4/zVjD rLtIKPFcRXoRX66AHpyJqVlBdl4wxxf8ItB233ySAMuXoJW94EdB/7OcNczm3o1ox0pzJgPxVEQ+ s1pX6EB2sg+BzUPMrIJI3AKMpZkvT1vZYB7GvTOiGB7G3u13jMs77AH/tGYC6c9AabKJWIcb8NVr 9CsILTq1ovAS9RqRqDIA9dTbLAUdhlI83dKmQ/NSoD88Uwu4H5IrgVMxXuvATwMNvoaMLX/CyO5G L17AEmRdtVbPVGiIbZS9CXMLE6q7mA33r0xC+rvouc9pF5a7CfRjtSeg/R32bmpGkLw3cKVCd+Lb KthyFLoRsnWgSwOjgNHAFyjdDzwLThXQeUibasXU2R023KZ7kL0/WWuvoHC+GltbbhNCZeclYGXc 9TJArwf+CLwN3AP8A3gGkieAJYEpwD4o/Rn0RNC4m8ut1COd1rFuhGwdecZWGpwoYDR2xFHAF5DZ DzyLpxBVQDPso5l4AZ2rQMPbsgCzvcWzuFzs1FyneEWBtNt9jNJrWIfstkobU60cvOdjIZ5n0txT uB67JNo3JWANuc+uRkq0J9SvE8pwQh4ADiO0TwKdQugAh4OjLQFCXoIWl1C6AxiEWhVQ+i3o/pA5 BU5ZcBLBuQOOO+hI0ONRasqY+uujrVRofgCr0mEPrJJoS2SA7opah8CpCbow+H3BqQ66DfgLgbPA 16EZFurbQC8CHQ/cDCwFG4YDo8A5D3RCpw/0nEXdapCBNu0IELbpj4ARwCKQzAK+AScGOAfoBZ3m iLxGfwdBfyWUNge9GKUHwHkF3A0sBJ2wRLQDxw0cX9B7CD0wvm5tgRh9N8wEB1qxo9S+CxrgWy0H 9GWg6RMOPizUG8ASyOvdgJDksFC7CXoT6m6BJHzOH0ISmjlmRe41mpm5u81TANSNpUhXc7Uf0Jsy s1rpqHlLT/lEe0L9OqEMJ+QB4DBC+yTQKYQOcDg42hIg5CVoFQUJmPkJiIUEzP8EzHniXELdHcAg 6KyAut+C7g8Np8ApC04iOHfAcQcdCXo8Sk0Zs/X6sCQVmh/A5nRYC5sl2hIZoLui1iFwaoIuDH5f cKqDbgP+QuAs8HVohoX6NtCLQMcDNwNLwYbhwChwzgOd0OkDPWdRtxpkoE07AoRt+iNgBLAIJLOA b8CJAc4BekGnOV6v0d9B0F8Jpc1BL0bpAXBeAXcDC0EnLBHtzDHFGAFVRkpA7CcgjyUgOyUgOyUg gxHfDRp8oW0PoQdG2a0t0W6YS26YVw5YZTfn0kKS8QBt34XWMS5aDujLQNOfHHz0Tm+AXkBe7waE JEfvtJugN6HuFkhivPhDSEIzx4yytcQ6YR/WNu1xv76ONVI41ksB4OCpoH0S6BRCBzgcHM1cEUFe ghaXULoDGIRaFVD6Lej+kDkFTllwEsG5A4476EjQ41Fqypj666OtVGh+AKvSYQ+skmhLZIDGPlc/ BE5N0IXB7wtOddBtwF8InAW+Ds2wUN8GehHoeCD2Snop2DAcGAXOeaATOn2g5yzqVoMMtGlHgLBN fwSMABaBZBbwDTgxwDlAL+g0R+Q1+jsI+iuhtDnoxSg9AM4rYCFogw2iHThu4PiC3kPogZF1awvE uLthDjig345S+y5ogFe1HNCXgaY3OPjXzX0ZbIC83g0ISQ7bNKz5+SbU3QJJeJs/hCQ0c8wHtTJU a5WcAvRkXq0M12JluBYrsRdYDRbGavA2rUyIw2rRylCVPsGacAtWbuPpOQM47oRqTZiNNWE21oTZ WBNmY02YjTVhNtaE2VgTZmNNmI01IdF5zJWn2YregtbMdLalzSXkBUAfBa4GTiC0paO0DjjnQGcA g8CpAVwEjkGoh4CzF3Vz6CRa66BW7jZbNmgH0aoWYT5wIlAaDOxKyJuafGA0sAbQaZ5rE/JQ0FfA v0FnatpL4Gp7HFZTTrKHUG8Pe24QX8nEQYYkJxBtSwdOgXwQ6tYBakADpTniOHAk9QL0M9DBtMq1 lQAGq70s9WUk9YtkFI5ET4kuY+FI3Enz024IlvuDw4ijDRJq/6u3gCc1nBIG661Jg2khNMwFfZBo HgP6T9gzRZ6HVSRzFH08h9JgezSNLDgRKH0A2h/0XsichoafwFlktaVW4NpTSO6FJVesUpNWNotw spY3pFW3jqes2kuygYfCbwUgmY3ebbH45OEYjEU+SSuTCNjmT3q0cPEDxoJq6RQ1tnT0SCev2vww l/wwQyIxc8LJM2p1oWS0LNRtJ2Lg7ZG02zXHDv1aDfmDwGfws2m5QLs/A69jRIZKtUvVius5xIHM UpT66APQCtH+kNxMkrw2ZAIJbRmg/aWbos0elYHkLrN3pEE3xz0/tO0D/3vUjZRNYD89U20HmSCU /gL6M9Kp9YaHm8F7w+GNvdDDgC2A4ZCxEW1bB1wEPAlsh7kUCpkukK8ITj6U+oudCgOIY/MDlkGP yuKZtlkXfB6n0yn5PWiIAD8CvZgNPSMse0hDCtlvmwUsBhwPbCdmKplhlk6Svw4sgVp74cO90PkO /PKQPI1xiYbMUIyjHfwsnP6UpTkgqgOrEfJMmg/cJnYofE60vhP0cJS2J9QMtHIP3l5CbfE9ZuzQ zNFDMItCQXub+QTz+TJkRmMsLiOTeII/GrQTM+1L0FvMHAhOAjg16JSZx2DeDiFa60BRoD1A1Aea 2RXtTkOMZ6Dd3oi+aGAs2ppraaN4+Qh6ihOfa+b8R7vPxDzEuxM20GlOX7SuQY8/2nWY2QM90uGN CfBqLHnDAUvsc0lGwgaHRjJyM2bmMkJHCnHsNYkWt4Dl0LvrsCcQmmPRVjStDB0TZDo9NaKzcqWT zkkLw5PfYp5vQf75FVYthp1DoKE6Zs4ozIeHkFwLtIE/iGKHIzPwSNwdCsiyyD/D4Bl6nnAP+Zbp nyAWZiOua2NVT+/LlSFa5VuFWiXgMHD24i5zBq2cAqcrZqA/8CJp0zbC29lismq3BU5mw1Erhzgq l07G0wxqfRRazyY9uZu0cxhlZaGeSijSQB8GbgJnCfARerGFkN9G6eeE9liUbgP6gt8COAfoDX5j 4ETILwKdiNJr0NaUViC8h/Clux7ReinwA8G/ZLYIeizJaGiRvwVdF9ouoHQzMAa4A/gEmEGonQM2 o1q6RCshhFKHzFtwwkAvBT1VliAPEIptwGmE0oPQvgD21yZa5WHC3pCJB14F53va8yobCAcTakf1 TylzEure4C8kVPYQdgKmIJPsgw2TwGE4Pbyu01PKFF1lSPt35ptCtILSe6GtSthfV4fNNtC5oGuj lWRZWXHOQHIaSkvCzjyE2nTQ7eHVHdD8I3r3GPLXId8Y9Mf0jEt+ixVCf8rV4hTZKcJROg/WthOF lEwjcM6SvLhBWU5ZTvb3QYsb6HxNcdTsFbhvqrz3TvXrHTysw+aqlCd1eqfZJseiL/vR1nRB9/qi pE1cEzba1+AU1R34F/jJJCNf0v1Rfy3aEEdXK1tZlVDMM+1BBj7OE+meaHqYOHZvqiX9kcPvkTat GCQDCGVeWjnr5j0F/eIRGJExkH9oaua70Gt3xf+NeqG85Ie1SgtYvpOeYMPnH2GUb0JPoGiKUSD6 E6ol+0JnSdCLqF2xz3wzAaOD8dKnYtTCqBc8C32JoLb0CLKB9wKnKNpNEYqjC0jGAAsAtwPbEGpL MKPiIdmbNOh4YqyXgs6RRNueCjqNjSJaZZgXtFNDHJl1nYTijK6yohhLOpXn6aRjEvH5JPQuzKRJ J58ArIa2IjjdH2dBc3+yQVsCbEqjqWWYHH0W9QitNIKe89DQHh4OgJ0MMyTCalGNAk8FhsGSN5B/ R22JXnQ31+egxXaolYJeeMGSwuII1aK68jr6+BqI2BSVMHbNMb5tdTXH5BAaWf0V+LuBifB8CE7S W8G2MMRIqpk3kPEuYc6XxwxvTfGin0CGicUMuQD5H1CaH7Q3Iugc6F7yIMW+oLGbi9i0QfILxOwu tPIWkq2Rf/ZD5hPQ1+XfVOlarDq2UyTqe2gU3NdSLbe2JOOoSOiGmWZfh/m2ntBtH6EjglBeRWkW rE0mefe1kGlLHlAaFNqR7UWQ6AafKD9zT8yNCcRRdw2FfDliEPdxtWd5jjxG99lWtGoS98hXKh4L 425F8TWCkK8TEbi/7MI6mfRUg+cZN2dLS3rWQTtWmR/3iyiiNdxndV+i9UfgHIGGLNBYZ9puYJ2Z hDiaRG+4yWg6idDL6V6KM5k4Wje0+BAt9oVtuDvnXsP7Wi/x9tdcnKsWyL1F+R+c1cAJFp/e+0oH vgKnDkrPgc4ABqHuA/BjQS8C3wAH75jZcsDvQGjLBh0Bui9k8uEEHGemtmBCdhycDtDTFDLR5ik5 TsHqQfInaJgCbTWA0ZAPhXwZyPyKU+z24EwHJ9t8Aw11S1iSVDeckAeC9kdbDPQgyITjhLoFZELB vwFtB9FijGXJY1g4EF4iTg7OxVajxWzoXAT7p0DbdOg5gHcARqHuFlMbZHTo9zP9b73/CS9BZ4Tp B9BZ5nt6sC0ImiU4PsCqqIX+coFWfka718EZCro40AeS/uBvBtZGKxhlG94q5LusWkRDUodneH7U 3Qf9g3LVTk37HvQQaGiH0izgL9DwGUp7g7MXMnthAzys2eC9dcBFwJPgdwFWRK184AfANnOsMWq8 LND0RlNIwoc8DnXvmX1Hi/uAwcD+kHTAKrwfwl6A7w38Gm0Jsy+QGQY9fkAGTglzvkGPJ3nAhhNb rTxKT0PSjtl4HHgNbz5UI0meCQttsPw5vLoT9HD0wpy9iCbbPdBLUHoberzBuYzSK2hxLnA0rM0B /QBYBngD/NOmDOp2sORPMjoRJvzSnI3WfCPOUdBO4GpgAlp8BksKAIPMjIE3CiKAHVB3C95GCLbe RkAUQ/9L0C9ROsKy06QJZ1vxchI2D4T9FFkaei3N3pkZDDIOeFjHSE0AjfFyYPbakeVkb9BOKpWI Mo44UqXEQc4RnyOCeqEvgVZOe0w7MtQdAj7ejdFKwYbZ8EMksC341cEfBfsfAtfCniyc1ONND9sg jGykiaYfchcg385BrpiPLIr3DGHPZmiuZOZMK/YJ15mxA+wEPAW8CPmNsLaFNRPmI/MQvkDpKCsb E91dv6FaGaLTDrS7OQNxarATT2t3mqeujFmnwe5srm0JEz2Se8SywLhPkxNY2z7Jvfqzrn17xSaz fgk9UhPZMPodyHYxEYH0xlZuLv2lSubGPFhe5sM86SfFc9DzWmawPCwf82Ve6mf6vRcqYS7KRl8K smiNScZJb4u2TQPpi0Io160ywbxZ/ri4AQPZaGA6cCJwBnAucFHPhPg+bHXv+MQebCNwW3xifCrb Dfw9PiUpgR0FnlaCPdgF4LWEpLgEdhv4YECvnvHsGfB1siq2MSDeH2F/R7zfQr/3iT6If8f5O2Vj nkC3D9DjA3R8gF4foB1o6nH/AA0L87JSLJiFslosgrVgbVln1pMlsFQ2At/8mM7msJ+YpNdr2Xhm /r5RPvOKv0eirg76MrnawThKMXr/wub2u/mzu5NQXTNhr819k3Xdb169fc2rzxQlr64FS5n1/CLN n/3ot6qVfr/VFn+v1Yt86v8SaDsPvoDQgkUxhr/5qv3Pf1VN9KMZZSuhhfLGegfmz2qwBiySxbCO LJb1Y8nsM5amPDeFzWSZbBFbydazbWwvO8xOs0vsBrvHnrG3apFo2Nczbl9qX2bfgOty+0ZcV9h/ wXWlfZO6LlPUZlyX2bfguty+FdcV9m24rrRvZ5q67lA/LVfSO3FdZv8V1+X2XbiusO/GdaV9j5Je bleeVbyl9n24LrPvx3W5/TdcV9h/x3Wl/YCSXmE/qH5aqaQP4brMfhjX5fYjuK5QWYCuK+3HlPTK /+AR+r7+MDb6/8kjx9HzpfYTlmdOWp45ZXnmtOWZM6qdpfY/LP+ctfxyzvLLecsvFyyPXLQ8csny yGXLI1csj1yFR65ZHrlueeSG5ZE/LY/ctDxyCx65bXnkjuWRbMsjdy2P3LM8cv+/8cgMNpctYMv/ qUceWB55aHnkkeWRx5ZHnlgeeQqPPLM88pc1Y55bnnlheeal5ZlXmDGvLf+8sfzz1vLLO8svOZZH ck2PqEQDjzhspkccmukRByePOHTTIw5hesQhTY847KZHHA7TIw63f8Eju9lBdpJdwHcFnrDXagHo 7nA3PeLwMD3iMEyPODxNjzi8TI848pBHHN6mRxx5TY848pkecfiYHnH4mh5x5CePOAqYHnEUND3i 8DNnjKOQ6RlHYdMzjiI0Yxz+pn8cAZZ/ilr+KWb5pTT11BFo+aW45ZcSll9KWn4pZfrlX/bIPZdH ylgeKWt5pJzlkfKWR4Isj1SAR4Itj1S0PBJieaSS5RGn5ZHK8EgVyyNVLY+EWh6pZnnkI8sj1eGR MMsj4ZZHalgeqWnNmFqWZ2pjxtSxPFPX8kw9yzP1Tc/QF2LJbtyBpqo7gcES1S3Aoe4G/qwMcyp/ RbBo1sE4rjJ9Q0drfapxwqKmGSdBxSjeKYuaZpxWVCPInbGoacYfoEjurEVNw1eCSrEQFqbGowVr z7qrrJ7KPmfjjXOuls67Wrrgaumiq6VLrpYuu1q64mrp6vuWjGxFNXE0VLy7FjXNuAeqkeLdt6j/ yqJrLouuuyy64bLoT5dFN10W3XJZdNtl0R2XRQ9cFj10WfTIZdFjl0Uq9m0hthC1gCms0fPpklpJ 3IvVys2zKlYBqWrURrNC/9lmNlutL5azjey4mscvbfRlkgK2QFuQLdRWx9bUNoRWbh6/Mg1f2tA9 drmo3e8p7ZCiZoI67KKOuKijLuoYKFodGtpxorXrCmeg7IRL6qSLOgWKq154MV/tNGqQJZM0suJb yJz5QKYA/X68NkPbw7iSnKH94dJ01kWdc1HnXdQFF3XRRV1yUZdd1BVQQo2/r5rzJVg5Td2fte9V W+r+rM1V131K4nttv8K52lVXvWtWv+1ahjZFjVGmtkDJL9KWMndtubac5dFWaquYt7ZGW8vyaeu1 TUo/x2rUl9Earh7WWt7Wtzh/UAVZWpbSuVbJc22rtlWtz9Roa9PxXQD60iKNvcr0WMu601fgtNna bBagzdHmsKJKx3ZWDL/nXxe/50/6E9WofBjJym7eROl8Aaqpi2rmoiJdVHNQAl/59FP7iFKo+QS1 nqLGM0j/BcnnlEm0J9oL9FDdL+Q4ma7RzoBzdJu7c3rOanAD/VAS/I4M4DTLbbKYLE71bB3ZEp7N A3k5HsxDeBX+EU/jY3k6H88n8Aw+hU/nM/hsPpfP5wv4Er6UL+cr+Wq+nm/i2/ivfC//nR/mx/lp fo5f4tf4TaXrHn/AH/EnopwIFrVFXVFfNBSNRBPRTDQXLUUb8bHoJLqJONFH9BdJIkUMFcPFKDFG fCG+FOPEV+JrMUlMFt+IaeJb8Z2YJf4mvqczAvGzWCyWiVVindggNoktYofYLfaLg+KoOC5OijPi grgibojb4p54JJ6Jl+KtZFKXDmlIb5lP+ko/WVgWlSVlaVlWlpcVZEVZSVaWVWU1GS5ryrqyvmwo u8gespdM8VjtsdZjvaEZ0nA3vIx8RgGjsFHUKGGUMcoZQUaw4TRCjTCjllHPiDCaGi2MVkZbo4PR 2ehu9DT6Gv2MBOXjxdzBaXFRjBej5zS8LNN4BV5BjUJFXlGNdmVemQlejVdjko/hY5idf8G/YA7+ Jf+SufFxfBxz51/xr5gHn8QnMYNP5pOZJ5+mxs+Lf8u/ZXn4LD6LefPv+fcsL/+B/8Dy8Z/5z8yH L+aLmS/P4lksP1/Gl7ECfAVfwQryVXwV88NvIhbiv/BfWGG+lW9lRfhOvpP58z18Dwvgv/HfWFF+ iB9ixfgxfowF8lP8FCvOz/KzrAS/yC+ykvwqv6rm5p/8T1aa3+F3WBl+l99lZfl9fp+V4w/5Q1ae P+aPWZCaA+VYBTUPglmwqCVqsYqijqjDQkQ9UY9VEg1EA+YUESKCVRaNRWNWRTQVTVlVESkiWaiI FtGsmogRMewj0V60Z9VFR9GRhYmuoisLpy/WsBqit+jNaop+au9SSySKRFZbJItkVkcMEUNYXfGZ +IzVE5+Lz1l9MVqMZg1EmkhjDcVYMZZFiHSRzhqJ8WI8aywmiAmsiZgoJrKmIkNksGZiipjCIsVU MZU1F9PFdNZCzBAzWBR9bYdFi9liNmsp5og5rJWYK+ay1iJTZLIY+joPayMWiUWsrVgqlrJ29FUd 1l6sFWvZx2K9WM86qLm7mX0itovtrJPYJXaxzmKf2Me6iAPiAOsqjogjrJs4Jo6x7uKEOMF6qJl9 hsWK8+I8ixOXxWXWU1wX11kvcUvcYr3FXXGX9REPxUPWVzwVT1m8eCFesH7ijXjD+otckcsSJJec DZB2aWeJ0kN6sCSZR+ZhA2VemZcNkj7ShyXLgrIgS5GFZCGWKgNkABssS8gSbIgsJUuxofT1JTZM lpPl2KcySAaxz2SwDGbDZYgMYSOkUzrZSFlFVmGfy1AZykbJMBnGRssasgYbI+vIOixN1pP12Bey gWzAxsrOsjP7UnaX3Vm67Cl7snEyWSaz8R6rPFaxrzzWeKxhEzw2eGxgXxvqJsomGsIQbJLhZrix DMPT8GSTjbxGXjbFyG/kZ98YhYxCbKoRYASwaUZxozibbpQ2SrNvjbJGWTbDKG+UZ98ZFYwKbKZR yajEZhlVjapstlHdqM7+ZtQ0arI5Rl2jLvveaGg0ZHONJkYTNs9objRnmUZLoyX7wWhjtGHzjY+N j9mPRiejE/vJ6GZ0Yz8bcUYcW2D0MfqwhUa8Ec8WGf2N/myxivybbCAvwYO4k4fyZ3win8pn8jk8 k//EF/G1fCPfwnfw3Xw/P8iP8pP8D36BX+E3+G36ipAoz5+J8qIC/1pEidainfhEdBE9RC8RLwaI QWKw+FSMFD+KhSJLrBBrxC+igtgmfhV7xe/iMD+prqfFOXFJXBM3RbZ4IJ6I5+K1yJGalNJdevHb IkoW4CWkv0yQH/HispuMk308Nhq64TAMw9vwNfwMfyPQKGWEGFWMj4waRh2jgdHYiDSijRijvdHR 6GrEGr2NRNXLJGQ2hsxmQ07TkNM4cpqO3CWQtSTylR35yoF85YZ85Y585YG8ZCAveSIveSEv5UFe 8kZeyou8lA95yQd5yRd5KT/yUgHkpYLIS37IS4WQlwojLxVBRvJHRgpARiqKjFQM2SYQ2aY4sk0J ZJuSyDalkG1KI9uUQbYpi2xTDtmmPLJNELJNBWSbYGSbisgDIcgDlZAHnMgDlZEHqiADVEUGCEUG +AgZoDoyQBgyQDgyQA1kgJrIALWQAWojA9RBBqiLDFAPGaA+MkADZICGyAARyACNkAEaIwM0QQZo igzQDBkgEhmgOTJAC2SAKGSAaGSAlmp1UIy1Qiy3RvzGIGbbIGbbImbbIULbI0I/RoR2QIR+ggjt iAjthAjtjAjtggjtigjthnjsjnjsgXiMRTzGIR57Ih57IR57Ix77IB77Ih7jEY/9EI/9EY8JiMcB iMdExGASvuOXwovz8rwSr8qf8q/5N/w7/jc+j//IF/I1fAPfzLer+bWHH+BH+Al+hp/nl/l1fotm jIrBpyoGg1QMthCtRFvRQXQW3UVP0VckiIEiVQwTI8R8sUAsEcvFapXbN4ogsVXsFHvEb+IQP6Gu p8RZcVFcFX+KO+K+eCz+Eq/EO2mTQrpJT35LtJD5VfQVkf3lR6KtorrKWNlbXPVYpxZrdsPDyGP4 GAWNIkYxo6RR0ahsVDPCjdpGfaOR0cyIMlob7YxPjC5GD6OXMUD1Nfn/IvFfjkS6I1dFPIYiHqsh HqsjHsMQj+GIxxqIx5qIx1qIx9qIxzqIx7qIx3qIx/qIxwaIx4aIxwjEYyPEY2PEYxPEY1PEYzPE YyTisTnisQXiMQrxGI14bIl4bIV4bI14jMFdtQ2isi2ish2isj2i8mPcSTsgNj9BbHZEbHZCbHZG bHZBbHZFbHZDbHZHbPZAbMYiNuMQmz0Rm70Qm70Rm30Qm30Rm/GIzX6Izf6IzQTE5gDEZiJiMwmx ORCxOQixmaz2zxJ/BbQ7m8+WsvVsB/udnWSX2G32hL3FcxDsfViQ2kF9xGrxv9RsTuMvFI7lrxSO 528UZsjxTBO15TCFdeVnCuvLEQob/gMNz6HhJTS8hoa30PAVNHwKDcOhYSQ0qL2Y/JwkQI1yUaNd 1BgXleaivnBRY13Ul+8p+tunFvUUlNq9q4xzhTHxTuQwTeUGtStV+UFtWlSOcGcOFdu98V3NfMz8 epyu3VK7vqX0FEKjk4hIPDsqw0LxJMDb46CKdKWRZ7+n1Jyh5wuH1E9P1V7uIuS8+CiVF1SZeeXZ 2C/SDoNhr2BTNS+/3y+yUx55PLz+09kEtU2nTyVYsPJvPetJxAHsnA+6nijcoC9rgvrTRd18T8mh JP1f7sTNszcbTt0MnC8pZ2mPeBG9j95Xj7dO52ymFGMF+6qrL7isYHdnWsHO0i0ovWn6C0+bXctM KxilWM00m62yh9NNigpeXCssmLOHdK8gbbotrbpm0zPbOFs7gz/g+M8vOtqf1cK/liyWpahbSwLr xVLV/3Xon7P4B8p03xVv3gzdvfSY95D+rXp8vbCa9OrGkzPT8lV2punKIt4ik2s2TXMPycp7oVVu 5+8P7HhfO0CZMrByBWd5ydvpHj4lGiYN/DQ5vk/f1MByceUDK4eHVw+Mio9LTkpJ6p0a2DApeWBI 5aJOf1M4/78vSUrukRqflFi5uLMYlXMfv7+XxyQlpQbWH5zaNyk5PvVTZ9GCns7qzrAq6r+qlZ1V Ohb0rFxF/VhNMdV/HZ2fwldKifTR2rWp7OPMSz84fNw/7pHSNz6xT6pqxtvpRUy7jz2mV88BSYk9 3xvm/s8MK+ksbhpW+MPynr0C28T3SVRaA1s1rO9Ms5VweroG0GYTjKfZ8jDFd9fSbDa24dORp7us aRS+KHRp5XOvSldrNnTHm2Jz9zUa9PBY49snJ+7q3yIm9tksbVfUH80SKpWq02v74ZIbPJpuGDX4 YqOtSyZ7tdpTusKTzFueJYsdq1/qdeysI4Ua/TwtstisQ2sqldgVWXFE0tn8RWtODPcOv7i1/LPe NSvaquTmlG26YF2CbdycN5tWx41Ke9U5c8zYLzNWPtk4/ccjYQtafVmw7Ljoi87nrPazva9qj9mW fj8hfGFI6PO1ISvcR8Z+M6z3nJkpnukrnux+GvhLy3yT4g4En63SqNCDzZEzarZq43e4d+tPlywb t799nXlprcYnilXVdg4vtTWmd+1Z0QcrfF41cWwTeWzu0ch0LTGd/bRj3OU2Gn2/+scxr51jXjh9 lDsDSuuG01061NQVws65c8x84tr0MbOdY74b7d3p6MCH8clzS7b+3Hd1VEbugR+S/+fnW1oetpN9 XavW+LzH6jyPu3e5njMP2ehjs+XqwsnVxRlADC+9gO57MODwEDaw04rH53ZHz24dEfJjRNwjpwcV 59F1FUbpH4QOpxkxPGv555FlnhzeEp06v0PZ1KDBa9LfZbWYPoxF3fn9rt+F+D1e80c81Rru/X3c wZdtDv46b2v7pEdxEYsj2IMZ+2ef8t/oMa+Q5/Qz54ouKz/y4f0FKUsnXwrPqD2z35awAcfHryj5 7vKd0/Fu34zfmnOVbQ59+mLEK+98IeJu+RnTGvQvN2hD2OQrds/fuvQ9tHV0/f69F23esDkj9Pcn 3HvEZ38dv9Lg8vCcq1eX5jy/fMpzzcDTU6+3XB82f0TFk7XPh3rEVtfmjelX8qvnneMmr+y4OfxM 94ntxhau+lfNmZlpxvxuX68J3vDDzweyzgWu3+4s9GWgr2fQlphn9a90dV6fWi5+3M6B154uzDo8 ukHyEC+VYz5TOSbWyjE9bEfqIBfm+TCOhMoz/4tRTQknXOWY6lWqhDqrhFPCqeys6vrROeaL/y+2 eWLiqKmrR7VsFfNenP8T8f8292x1fvWmUfKiNv3nftWSldyx7WRA7VWf1At7mvJNWpmbM/KxNmf9 07xqHQ7YvPVFg0nfnXwbVvjGL6+u3zvRg2/PPHF6cFTnxovvd310/Fp8p8Ip2Wv8J+mHykdk9vyk UtGZXRL3ZfmFp/XavXBL1uDxhbLHfedbZs2oMkN+OhkWPvb6mjKn/F5VuHP8twId2xZ/8t2kcenl c541C7759Uu97shDh2ZMTfccxK8dzTEaVMs9s7HuxYxG7iOfn2m+rNOjIckBQ0uO/Krabv8uq1vx 5k0G2Be2Gz9Tjl4wZlnb6D/GnH69vcGOytvaec461aZZPufdP38eP6Lr7s86+o5zrK0en3m3SqmJ jruvTvpuuvL2UPZP+a3c89I55q9/nHv+HsVhw0TK/iJV/tZtanq7FV9t2jtrVWoGhi8gD0W9CmT7 aOSNgJK6n7PA6H8c9hEkUEyv7azpDM+snlktvWrf1NSBNSpViktOCBnwfgxD4pIGVBrYP564lQYm J/UcHJeaUqlhGzXxQhTL2fS9hTabXstZwxn2/menlh5sKRw6dOg/Utgr+QNNqf8hoJB9yvEvsnw8 H+fkTWow5I+GWRv3Nnhdqlfo8sErBzkzZqz/4nXyjZxD1W/VGDizdaDXpkFrf3t26saE2+UGppy6 f/XX4Q8etw/tODrtrveZZJ6dL/reRc+JwyNaGj0Gv0ucY794uEJHP8/wld3fncvVl2g//vE648fN W3f2a1uzcrcbwYkHHkcF+T8pOmR4+oq9406vCrq/9KDXjhvzRt0+cntscts0v3+rxtyjod72AP6b GeMRB3mcxHiGvCYzg2FIHnO884orzxuN13g/RznyGIPxSnlWHoVKHnXEMOKElCKE7tIhZiIpbxEh 4o7qFNVd96517zqt+9dvf/f+7d9e+7e/67M/e/vJtRVkUQRF7vhnDB6/esfE+3r7jGb6aJVieXgY xsML+JWYD+Gm47KMpHXpWRJ3Eth7+IqPDQWjgtAim22yrZJHzN0N24WFS1ulMXgLs5LpFmafA0FC 8+JPfSUNo2P4tSMudoaoGZsz6JPPoE/cR/pwe7GfN28GpMp3D+qJ2oZ7FH3NoB/jOmgGfNAIJEJZ WXULPRhG+ANcxxrv6xYc4uIb8J+6zpCq39pvbbrGgQJtjwwPWTW/K+erV0A18JgfaYudOaQ0YIRM l6k96zosakGqbzHpjYKuzIU2Jj+41ncDH+B+Yr/7eC11Lu5W12zZe57L7HYSsord2gM2TEKEGl9X X2PrQdo8veli7IPoZ1GHwaqZS80FrDYingZdA80ER8VTtVJMFBsHLxhuMzri4Gwfk5QpJiyExanF sT9eVSG0nXNSBMMWQdjI9/ELH54+lJZTEMh5TM5c4LgzquBxrJm8hKOnXjJdkcRtUbVaI5jqMyuV y7vSwf1HHOcikRCMvp8VXtTpzDwNrYxXoq5kOpB0SLZxmX6VogqGnf552GGv8Sjp094feUMEyTD+ iOT3iMP6/2E73Mxsn04W/KAthQG2gdJ/3Ewr55ZyuUl82u95kxUaOtj7PYi9nzvwgZk4RHYBVkAo 4xSCBXR2mtA3GvUdQGWa7ka2RFg07D5d6MIC4kwJ0EudC7a+rcUGhW/WWVrFwWYwZ6nFNuz0lFoN od61ipJ26k1LcSF/VnykN6RIQn/Gh+IbIVGn/w/Sm1SuRpYk9J2pyIkAJ72L6Y87H9FON480yXVF TLffQPUl3OrA3UP3Cog3EegaF6qFggvEyf0UCo91ymJei5vxBRnpPOckLo0HvG4nDBu6r8eqm1ce t6UjJiYwwqOJC08xMau84imu0ThmpuyFC2Cs4q/65PpN8IDbqjH9KSQkoxrqx9GZPyTjEmE4vydv t7gaGJZQwdyajaob075vpXm7NJE+7q6auiiRnddZGWZtqf4k6JeqfW8ZgCpjACr9Tz1izoR/0CO2 H6dH34Bgi1FqDBtSYaAJhfzAKKWPIXIrRMRU/xV6tB8h9TEU8cPiAzzdgsR+sdIT07MyU1fVUUPB 0WpqOnCMPgaFlELs+zgn2M45wa22JiVm5RZEwOPc/i3esmJ2iekKWIYPZM3kvh9K6F3jTOOdLFOV 4SFsmFqUE3LkMgyGS23w4LHMSNO4wajAuVBgsAHrs+ZfEfhavjci/VHmnvzC1vrV5UiaywgcIZIn DSdovdTPPn2jP1G1v3PuTbfD3XXP4QXXtNzxuzyrxY2k9SfJj6Cat0EEi/2QFRL15/hU50YnWYWD 3Vfen7NXETb/uVmtX8RFSxNdbcPHH5alwf0OqMx47qRavr8Bp2DIF/O3UZ/JUvmsVDJnZDFwJUyS 5ZxcAKROTvLMBXprkYRJ02E75jDrIGzlIVdaBonVtnZjIsGIDV1dvaJUGnm46GQUyk6Ws6Bmafhg gda0vsZ2nfoCBJkschNYY+ppZv0pfa53HYuR+Zu9O0zpu8T4b0wpJDgA5/I/MaU/vxTyfVjv8D/m 5u/RCpitWH/+mOz+UHbU/lYXQIzc49gqacfTcG3Z+4+EjdSOGoKokMTb5ZGHlFs6IEHV64aq2QHv OpVKZFLq2GtDeGWo1aEjcmzPk82fndPKoSrzxExy04SH6l27zSw0Die930uTutGXnTBpcm/s9arO HifQ1FHyKUL4mP9GglhFRl7KhaZjgpf4EZLDRZEuZ4VlZe8anVHHxibO0vtiaeYKKhqvdHRAZQAH +8ITI6FHuqm/Vr6BpzrJjjSmRp3lJ1Cc1/j2l/nz4HRlbNWTNJK1X1BbO9OPwvRtvNM60k1toMDD FYS2ntmzveTbS9yvaYLPZEQolgthw9KjDWwxPEMi6j16yA86xXQeDAIhYhJ+4JFtx0Hyy1XXpZi2 rd3p07KxQZAc2+/RGON+idiRnIjtrfwManzuyIRkpPo5/AMyvUpW4GBrOG93zhhhKW+POMJzWxcO pD3C9tKBaAXAGsADvoAbEAyIAWaMZxjjeQTwZ9S5AH6MshEQwij5MN7CFUpHS/7LXA05GeDvEeQS 4HlS7Cs2MRFBgLaJbgsRJhrgcRQWqiV5zEG0dtYh7T6VQ3ZhbRwJjUN3nWLjhx3VrtTxgtyc+f2A Qn8EuWe58dRvYTm7q47IZ4kFGTlm2xjKMyeQyIGgDogY1kgmd45jH/liyqVXeCe4f9UbGIsW+YqX 4wYacu4F9AklKJ4Wema+iuZH1BPlwrFZR65mY5j9Jo2rq+C1Rdhs+dxszOR9hReWGXzOVzv08x7r rqW793i8Qxn3TTr7UQ2mbIdHZlZzasElRufDr5V43JPt4zNwMpMm3hB/UYPlm3cpzPqp2x8ESytJ qraxOME1ZjQHniE+8/5JO/H0fKO6BkV/ke1eFgye6khNtp4LVi4kgkURRLDQl3ViRhLBHIwq1r88 Ib/eJHds3SyfEvKSE0Jgezayf7n6BTHG/NwCRXIx9lQEAoNSRqqpoFUw9t8k46Dekn719VJ75PxL g5PFUYX1yVakrwi1lSKRnUs5CsoHbfxxhU3WTlANj9cbcgP98qttY3KZucXnYRN9cKbki+mEFkWC YEYjpJbfITwEj26nTnGrCiygTKcNrj42kfaehYqq4BbXXZIoFOxL0LLWctBbyPCG6ERNaFHyoVcD k/VRy/MG63cyS2tDp5b7RhoTRKLm7f4eJedwOH2z44x6316EJql3WfhVvLbSgVf5e6XGXKG7PDif 9lxmUqlmopeWauKvep7kdg0S8AEHyrG2Te96UyNFAvDXIY40sPn65ah20+HExGKLqZt22aibs3Vd EXzt6Xe9Rrnch8rO0BS44ktDisS7n7CnL44MmXqceFunsgmI2qsYgo53/xNdvAeyDQplbmRzdHJl YW0NCmVuZG9iag0KMTQ4IDAgb2JqDQpbIDBbIDc3OF0gIDNbIDI1MF0gIDlbIDgzM10gIDExWyAz MzMgMzMzXSAgMTVbIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwXSAgMjlbIDMzM10gIDM2WyA3MjJdICAzOFsgNzIyIDcyMiA2NjcgNjExIDc3OF0gIDQ0WyAz ODldICA0NlsgNzc4IDY2NyA5NDQgNzIyIDc3OCA2MTEgNzc4IDcyMiA1NTYgNjY3IDcyMl0gIDYx WyA2NjddICA2OFsgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzhdICA3OVsgMjc4 IDgzMyA1NTYgNTAwIDU1Nl0gIDg1WyA0NDQgMzg5IDMzMyA1NTYgNTAwXSAgOTJbIDUwMF0gIDE3 N1sgNTAwXSBdIA0KZW5kb2JqDQoxNDkgMCBvYmoNClsgMjUwIDAgMCAwIDAgMCA4MzMgMCAzMzMg MzMzIDAgMCAyNTAgMzMzIDI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAw IDAgMzMzIDAgMCAwIDAgMCAwIDcyMiAwIDcyMiA3MjIgNjY3IDYxMSA3NzggMCAzODkgMCA3Nzgg NjY3IDk0NCA3MjIgNzc4IDYxMSA3NzggNzIyIDU1NiA2NjcgNzIyIDAgMTAwMCAwIDAgNjY3IDAg MCAwIDAgMCAwIDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYgMjc4IDAgMCAyNzggODMz IDU1NiA1MDAgNTU2IDAgNDQ0IDM4OSAzMzMgNTU2IDUwMCAwIDAgNTAwXSANCmVuZG9iag0KMTUw IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIyND4+DQpzdHJlYW0NCnicXZDB asMwDIbvfgod20Nx0l1DYGsZ5LBuLNsDOLaSGRbZKM4hbz/ZCx1MYIP8/5/4LX3prh35BPqNg+0x wejJMS5hZYsw4ORJ1RU4b9PeldvOJiotcL8tCeeOxqCaBvS7iEviDQ6PLgx4VPqVHbKnCQ6fl176 fo3xG2ekBJVqW3A4yqAXE29mRtAFO3VOdJ+2kzB/jo8tIpxLX/+GscHhEo1FNjShaiqpFppnqVYh uX/6Tg2j/TKc3U+1uM9V/VDc+3vm8vfuoezKLHnKDkqQHMET3tcUQ8xUPj8JSW8rDQplbmRzdHJl YW0NCmVuZG9iag0KMTUxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDY5MzI5 L0xlbmd0aDEgMjE3MzI0Pj4NCnN0cmVhbQ0KeJzsnQlgFOX5/78zs/d9ZLObbJK9sgm5SEi4CbA5 CQTlSIQEURKSAB5INGDVomCtVqMWq1SrtkK1IhUtm43agP4qtbUeqIAnWgsoh6K2olZ7qMzvmTch QP/m/0va7D//n3k/k/f7Xs/MPDM7+2Se7G4WAgAPiQpry2umT1uf/fQXkCa0Au7V08orKpttS8+E eHEVIN4zbfasmnOOd90Bse194JefTqs5q/Rx0+xESKlvA95LZtTUVi7PPk9D68+mrabNrK2pOjLt 6PlA0XjAfPasmvxCZ+1lq2lbOppvmF02s7b+lasP0vZt1B87r/yMujNDy74HRNYD9vVNyxtbL86t 0UC4dTetc0nTpSv9xwv2HYPw4A5A+9aS1qXLf7cpVYDw43JAM2ppY1srPNDT9mhzsC298PIlRx6Y cDGE2E+BO0Yua15+2Yd/c10BzB0BIbJ5WUtj877pD/8JEG5S9r+MBhwfJ4yl/u+pn75s+crLzkq3 ltC+lwEFuy9oueSiLx//WgOxWTkG1YUrmho/uTLpQ4jTXwCSo8sbL2t1HrGSrwKdH/gvalzeMqIy NxnikrWAoaF1RdtKOR3NEFsPKPOtl7S0TjjyrBnC3ZcB1gooj4Xa/tGkhXd1LrIWf65LUk4TcO/B 1KeU+tmniu74cuXXN9mgs1BXz+wVqNYGjldgvg1frvznfht6Z3ow2pUR83wsgMQGRNiQj3l01sK0 XwVJGiPcAjV06rvURbSBcHctbcQS0SGoRVEjqVVqUVIdQLa8A5eVMA+I2jPK/IjA73eqbzpeKRRp A8LjEQiyLNPa69UzlSOFSjNBSOnecU95EIekclyLb4DmaqmMVNqqaxAm+4uoX0P1j8QJkFTADCrH qORSqaHip7KYSh2VmVRWU5lDttF/3bZ0MxZqz0Wj+hko1xzU8zCD2iHVQWSr2hCgdpXSp/0VnViH 5rK0qQiqn5EPK/NkF2R282i9Nqyl+SnUNyq22pvhZdt9Bs6eY9ncU1ezbUH+uMeP6dT+kupK8rWc 6plkM4vak6mYyfdicYLcRG07tSdrJsBObROVClrvH8o6ZG+WUtFM8wkq5YIkW9qvmWqvYkvbzPqm 88v596Dz/peh9uFUlGtkqH3gcDgcDofz7UXYLG8fah/6i9r7v8dXDofDGUoEyNt1VGzgcZPD4XA4 HA6Hw+FwOBwOh8PhcDgcDocTf5T3wQ61DxwOh3MS83ytIAhLl7GORgOd+xzd5LRepinDLxRVwBLx LJ42pQVo8UQi9ZGcCXMjeBURyPgCOhSeO7Wq+lBz7aTY4mmf1Z577rn5waLaxoVNz7TEwWVdP2wm xWG/nG8Fwv9s8m+Ycv4HKMoMtQscDofD4fQJ/y3FGSwkSIKCWpIEke5/POqPjDvwd51MOYxOPg49 DKQGpkYY5a9hgonUzNQCM6mV9CvYYCW1M3XARuok/RIJsJO64CBNRAKpm/Sf8MBFmgQ3aTJTLzzy P5CCZNJUpmnwkvqQQuon/TsCSCUNwkcagp80nfRvCCNAmoEgaSbTEUiXv0AWwqTZyCDNQSZpLkbI nyMPWaQjkU2az7QAOfJfMQq5pIXIIy1iOhr58mcYgwLSsUzHYRTpeBTKn2ICikgnYgzpJKbFGEs6 mfQTTME40qkYTxrBRNIS0mMoxSTSMhSTlmMyaQXpx6jEVNJpiJBWMZ2OEvkvmIFS0mqUkc5EOekZ qJD/jDNRSToL00hnM52DKvkjzMUM0hqmtagmPQsz5Q8xD2eQzmdah1mk9ZhNugBz5A9wNtOFmEt6 DmpIz0WtfBSLcBZpA+aRNmI+6WLS99GEOtJmLCBtwdmkS0jfw1IsJF2Gc0jPY3o+FslHcAEaSC9E I+lyphdhsXwYK9BE2opm0ovRQnoJlsiH0IalpCuZrsIy0ktxHul3cIF8EJcxvRwXkl6B5aTfxUXy u1jN9Eq0kl6Fi0nXkL6DtbiE9Gq0kX4PK0mvwSr5AL6PS0mvxXdIr8NlpD8g3Y/rcTnpDfguaTvT G7Fa3oebcCXpzbiK9IdM12Gt/CfcgqtJf4Tvkd7K9DZcQ7oe35ffxo9xLentuI70DvyA1voJrqfZ O5nehRtI78aNpD/FTWTzM6b34GbSDfgh6UbSP+LnuIX0XvyI9D7cSvoL0rdwP24j3YT1pA/gdtLN pG/il7iD9EH8hHQL7qTxh5g+jLtp5Ff4KelWplH8jLQD98h7EcMG0k5sJH0EPyd9FPfKb+Ax3Ef6 a6Zd+AXpNmySX8d2po/jAdInsJn0v/BL+TX8humT2EK6Aw+R/hYPy6/iKaa/w69If48o6dOkr+AP 6CB9Bp2kz+IR0ueYPo9H5ZexE4+RvoBfk76ILtKXsE3eg13YTrqb6R48TvoynpB34xX8hvRVpuQF 6evYIe/CG/gt6V6mb+J3pG/h9/JL+CPTt/E06Z/wB9J9eEZ+EfvxLOkBPEf6Dp4nfRc75RdwkOkh vEB6GC+RHmH6HnbJO/E+dpMexR7SD5h+iFfk5/ERXiX9M14j/QvTj/E66TG8QfoJ9pJ+ijdJP8Nb 8nP4K/5I+jnTL/A26d+wT34Wf8d+0n8w/ScOkH6Jd+Rn8BXTr3GQ9DgOkco4LP+Bx/RhHtM/ZDH9 QxbTP2Ax/QMW0z9gMf0DFtOPsph+lMX0oyymH2Ux/SiL6UdZTD/KYvpRFtPfZzH9fRbT32cx/X0W 099jMf09FtPfYzH9PRbTj7CYfoTF9CMsph9hMf0Ii+mHWUw/zGL6YRbTD7OYfojF9EMsph9iMf0Q i+kHWUw/yGL6QRbTD7KY/i6L6e+ymP4ui+nvspj+Dovp77CY/g6L6e+wmH6AxfQDLKYfYDH9AIvp +1lM389i+n4W0/ezmL6fxfR9LKbvYzF93xDG9J/0xPQ3/62YvpfF9L0spu9lMX0vi+l7WUzfy2L6 XhbT32Ax/Q0W099gMf0NFtPfYDH9dRbTX2cx/XUW019nMf01FtNfZTH9VRbTX2Ux/VUW019hMf0V FtNfYTH9FRbTX2Yx/WUW019mMf1lFtP3sJi+h8X0PSymv8xi+h4W0/ewmL6HxfQ9LKbvZjF9N4vp u1lM381i+i4W03exmL6LxfRdLKa/xGL6Syymv8Ri+ksspr/EYvqLLKa/yGL6iyymv8Bi+k4W03ey mL6TxfSdLKbvZDF9J4vpO1lMf4HF9J0spu9kMX0ni+k7WUx/nsX051lMf57F9OdZTH+OxfTnWEx/ jsX051hMf3YYxfQcHtN5TB82Mf3O/yimvxGnmL6Vx/T/BzEdFHFhXmhM1EOSVGr2VxqVChpJJUma Xth/F1QbdNDqtBqtTgVoDTodddQ6Hf0C0EFFiwZqBZVaQ6tKelpNrVJRT0uNOPwtSdOvvzdxON+I 2H9Tbfy8GHYIxsShdoHD4XA4nD7hd46cQcLkOT230n5TbmXUQ6fXavV6Jbcy6fVavU6j05+aW2lo OZlbaTUqtUqj0au1/cmDBgrPrTj/AQPIrfrz3nVO/xBNnqF2gcPhcDicPuF3jpxBwpxsUHKr7nyl J7dS/UtupTEZWG6lOyW3og7MPbmVFpRNUT6l1bLcSkuolB7lVvF43ao/rybwZwinDwZwafDcavAQ zclD7QKHw+FwOH2iGmoHON8WrGkmSqnU3TkQVTpJrVJpe2E3olqLEQajXmcwkpnebDTqjQad3ggL jFArXzsMZqtWciutZGRtJbeiVjxet+rPHS/PrTh9MIBLwxA/L4YdojVtqF3gcDgcDqdPeG7FGSRs /tNzK71Ko1LpeunOraxGUEKlN7LcymIy6U0G6sF6MrdSPoKlvG6l0lFuRevx3Irz/yk8txoSRJt/ qF3gcDgcDqdPeG7FGSTsQfPJ3EqjgYFyK7W+FzbOcitKp0wm6hqsJpPBRJmWCbae3EoPJZ3SaSil UuvUZp2e2lq1TmvU6eLx3wD0/bCJx3sROd8KBhA8jfHzYtgh2oND7QKHw+FwOH3C7xw5g4Qzwwq1 WtP9WhDlVka1Rn1KbsVuRHV2M8xmo9Fi1tD9ps1soZbRZIYDZmhoMUBn0Bt0GjJX6VUWvcFg0Oho I2a9Ph6fWOnPqwnxeL2M861gALmVKX5eDDtEZ8ZQu8DhcDgcTp/w3IozSLiybSdzK60WJrVWrTH2 wnIUg9MCi9Vsslqpa3JYrSarxWiywgkrtLQYoafcSq+llEpj0NgMRoNBq9MYDVaDvj+vMQ2U/rya wHMrTh8MILcyx8+LYYfkyh5qFzgcDofD6RN+58gZJDwFTmg0uu7XgnQ6WDQ6jdbUS3dulWiHzW41 2+2UgllddrvFbjNZbHDDrnztIUwwmmjRGU0ajUnjUNbT6WkjdpMpHp9Y6c+rCfwZwumDAfxhyho/ L4YdkqdgqF3gcDgcDqdP+HdacgYJ71gXtNqe3Eqvh1Wr1+osvbAcxZTkhMNptzqdlFvZPE6n1emw 2pxIghN6WiwwWWjRmSxarVmXoKynN+gsJqfZHI93VVn6YcOfIZw+GEDabY+fF8MOyTt2qF3gcDgc DqdP+PeucAaJ1Inuk7mVwQDb6bkVu9JM3gQ4XQ5bQgKZ2ZNdCbYEp83hghculltZWW5l1pstOp1F l8hyKyNtJMFijse7qvrzagJ/hnD6YAC5lTN+Xgw7VKkTh9oFDofD4XD6hN85cgYJfyQJOp2xOwcy GuHQGXR6Wy/s81KW1ES43AkOt9tI95spbrfD7XI4E5EKN4y02GCx0WKwWvV6m95tpfWMRr3V6rZa +/Ma00Cx9cMmHp/z4nwrGMBLmgnx82LYofJHhtoFDofD4XD6hN85cgaJQGnyabmVU8mt7L2wK82a 5kaiJ8Hh8VBulZDq8Tg8iQ6XGz54WG5lh5XlVpSK6e36JCUnM5r0dpvbZotHbtWfd2rxZwinDwaQ W7ni58WwQxUoHWoXOBwOh8PpE37nyBkkwjNSodcbu99nZzLBpTfqDc5e2JVmCyYhyet2Jnspt0oM eL0ub1KC24sgvDDR4oTNQYvJ4dTrHfpUp8PhNFkMTofXYbfFweX+vFOLP0M4fTCAF/098fNi2KEO zxhqFzgcDofD6ZN4/Pc1zrAkuzYAo9HS/VqQxQKP0WI0uXph/4vCkZmGlLRkd1qqBUgKp6W507zu 5FRkIg0WWlxwJjhcDrMr0WR0mQKJCS6X1WZyJaS6nPH4xEp/Xk3g30zE6YMBpN3e+Hkx7FBn1w61 CxwOh8Ph9Am/c+QMEiMXpsNksjhYx2pFsslqMrt7YVdaQrYfvkBKciBgBVKyAoHkgC851Y8c+GGl xa18GivRaU1MNJkSTcHERHeizWF2J/rdifH4xIq7Hzb8GcLpgwH8YSo1fl4MOzQjFw61CxwOh8Ph 9An/TkvOIFHYnAmz2dadA9ntSDHbzZakXtjnpVx5IQTSfd70dDuQlpuenpIeSPGlYyTSYaclCYme xKREa5LHZEoyhT3JSUl2J/XSPe7EOLic1A8bnltx+mAAuZU/bk4MPzSFzUPtAofD4XA4fRKP/xDA GZaMvTAbFou9OwdyOJBmcVis3l7Y57A8hRlIzwykZWZSbuUvyMxMy0xPDWSiCJlw0OKFx0uLI9lr tSZbs5T1HC6rNznT643HJ1b6804t/q2vnD4w9t80GD8vhh3asRcOtQscDofD4fQJv3PkDBITV+bB arV3v8/O6UTA6rTaUnthV1rSmCxkZod82VlOut8cnZ3tz870h7IxDtlw0pKK5FRaHCkptKo1J4XW c7ptKSnZKSnJcXC5P+/U4s8QTh8M4CXNcPy8GHZoJ64cahc4HA6Hw+kT21A7wPm2UHbdaNjtCd2v BSUmIsOeaHcGe2Gfw0qdko+8gqz0/IIEILO4oCBckBceUYApKICbliDSgmnB1MRA0OkMOkYHA8Fg YrIzGMgP+OPxiZX+vJrAv/WV0wcDeNE/J35eDDt0ZdcNtQscDofD4fQJv3PkDBLVt0+E0+lJY52k JGQ7k5yujF7Y/+QLVIxB4diR2WPGJgF5ZWPH5owtzM4bi0qMRTItGQhk0OIJZ7hcYdcEZb2kVFdG eEw4PRAHlzP6YcO/mYjTB7b+mxbEy4dhiL769qF2gcPhcDicPuF3jpxBomZTCVwub4h1UlKQ7/K6 3Nm9sPcKZsychHHFRSOLi1OAwhnFxfnF40aOLsYsFCOFlmyEs2nxZmW5PVnuqVm0XorfnZU1MWtE PN5Vld0Pm/78L0HOsKQ/Xz3dw5j4eTHsMNRsGmoXOBwOh8PpE37nyBkkFnZVwe1O634tyOfDaHeq O3lkL+zzUlm1pZhcOr6otDQVGD+3tLSodHLRhFLMRyl8tIxE1khafHkjk715yZXKer705JF5pSPz RsTB5ZH9sInH57w43woG8KL/pPh5MewwLewaahc4HA6Hw+kTfufIGSSanz0TSUmB7hwoEMD4pEBS SmEvKcrwyIVVKKuaPK6qykf3m/VVVeOrysZPrsIiVCFISyFyC2kJjCpMSSlMOVNZL5BJG6kqys+L g8uF/bBJicN+Od8KBvCifyRuTgw/zM3PDrULHA6Hw+H0Cb9z5AweUk9JgcD6v6cetYTnocJmKJ9v 8lNLQ0lUFiaiBNNxFuajHmfjHEqvrsBGPCyMEsdpIn6nLEP5VqARyMFUlGHmKXaNp9vJB/tYmmj5 hW7vV9ED9/T40w8EDXqNBVEExH81oENUqVnTaILFarM7nAmuRLcnKdmbwv7hRjCUjozMEVnZOblA fsGowqLRY8aOG09HXIwpdJddivKKymlV02dUzzzjzFmz58ytqT1r3vy6+gVnLzznPzv//wcS047+ mL52Svt/zaMVKT2rNjJ1yuTiSRMnjB83dszoosJRBfkj83JzsrNGZGaE00PBgN+XlpriTU7yuBMT nA67zWoxm4wGvU6rUaskUUBuRaiywR/NaIiqMkJVVXlKP9RIA42nDDRE/TRUebpN1N/AzPynW0bI csm/WEa6LSO9loLNX4zivFx/RcgffbE85O8SFsypo/bN5aF6f/TPrH0Ga9/C2mZqBwK0gr/Cs6zc HxUa/BXRykuXtVc0lNPmOoyGslBZiyEvFx0GIzWN1Iq6Q60dgnuKwBqiu2JihwidmZyKJofKK6JJ oXLFg6gUrmhsjs6eU1dR7g0E6vNyo0JZU2hxFKHSqDWHmaCM7SaqKYtq2W785ylHgxv9Hbk72m/q smFxQ46pOdTcuLAuKjXWK/uw59B+y6PuKw55TnZp446yuh+cOuuV2is85/mVbnv7D/zRjXPqTp0N KFpfT9uIiuHKhvZK2vFNdAqra/y0L/Ha+rqocC3t0K8ch3JM3UfXEqpQRhrO90f1odLQsvbzG+iB SW6PYu7lgVhycmSbfADJFf722rpQIDrVG6pvLE/pSED73Ms7kyL+pNNn8nI7bPbu09phsfY0TOZT Gy29c6zFzJVW9dze8yooHoWm0+UQ9Tf5yZO6EB3TeEVaxqO9aTyZEfUCrRVtpsfjvKi+rKHdNpHG bcr6UXXYFvK3fw56/EN//uj0kcaeEU3Y9jmUpnKV9F5oNH+iHc3JiWZnKxeItoweUfJxCuuPycu9 tEuMhlptfqro9GE2ndvG+on5dPIDAeXhvbErgsXUia6dU9fd92OxN4ZIfk59VGxQZnacmHGdpcys PTHTu3pDiK7jR9iz3BXVZfT+WG2JzoplE6NC4v9luqV7vromVD1nQZ2/or2h59xW157W654f3zvX 0xK6J+iER1VhOlPTQ3TpzV1QpwzQjzpcGao4r6GKnmrkY9RZVid5xfruluiV2Kbo+l3Yu2WlU2dS tqUKa9j139yl1dEFzEYEf2XU1lDVrfWGQKCfK3XJx5S1WHVytZ5jik7MOb0/6bT+ae6Z2iVyWJUh VtcuaG83nDZXScGqvb0y5K9sb2hv7JLXLg75baH2bVKdVNfeWtFw4uHvkrff6I1W3lRPB7FMmEiX tojSjpBw/ZyOiHB9zYK6bTYK/tfX1sVEQSxrKK3vSKe5um1+is9sVFRGlUGl41c6qBboWRETdcze uy0CrGWzKjbA+k1dAtiY7sSYgKYusXvMdmJMpDFV91iEjSkokaKstu7Ua4A9seqVP9BuQ630UaeU 7Zta4pIOoUE6ig3SYeynooKNRmzUmkqlldoyFbW8Q3qns6KiMNJFdc5IVsdGZBVuUyZiySmF/yW9 Iz6ETPhoYH8s0ctm9sVKS3saY8d3Nzqz8wr3lxikffiYiijtk/bT70y2VueIkYXHSsw0IEhXwSoI 8GGj9CdEqYiISG91pmcUbnhSeoHmn5eeQzNb7bmY2V5IG3xG+jUc8EmPSY/2zDzaabEXoqRNuplO 2w7S3VQOUDlGRYUV0gNYQ2Udla1UVLCS+qjkU5mljEhbpC3k5/20vpU0n8oKKuuoqOgUPkjjFygq bZbOp3sEn3STtB4uqm+UbmP1L6hOpvpeGk+j+ufUV+oNPf27qVbm7+oZv5P6iVT/pKe+g8a9VN9O faX+cU//UmkVW29lT71Raoul+WwlaTTvp1JARaLWemqtp1O3XrkNIhWka6QL2Z46qC6kenl3Tafr ylggxB6jKzvdSYUb6ZReSaf+SjpzV9KZuxIqmlp9wmZ1t02etJpsVpPNarJZTWelQGqj/bUp94yk Nip+KhKd9zY678p4lHQHld1s/Pukt1DZqPSk79B5zCKvbpDOj43w0UW2tHNCpHDq49ISOtURaUln UmrhupM9vUG5EKm29NRWxbaFzbZ06k3KaEtncmp3TVYXlFikJnyXiogE0nQqo6mUU1FJTbH0fN92 6Uws1yFi8a0R10hrVGvUqoJywfGkVIjZOtAl6ZDyUEwGWb5FxcK4Bn2rfq1esun9+gJ9RD9br14h rZHWSZJPypemSrOkRZK6S94R004soioyTTOx6BbjRmPUuMO426iOanZodmsOaI5p1H5NgSaima1p 0LRq1mpu0WzU6G/R3KIVG4ytxrVGyWb0GwuMEeNso9qnFTaWXCstZvfhi+kcL6bn6WI6i4vp/B+T FtG4XzqXyiJ6NBbRqTiXxkEK6tmo7Kb2AarV1LOSnZXsrDRqpVErjYJUmZlNpYFKa8+spnfmxDqK /TFlhkomzVpo1ELn9gDpMaVFZQb1zNQzU89MVrvFr8hDG6mfymwqEhs7QEVJNr7qnSvomW+gomHz x5jNibmIsq74VaQxc0eWEM0SNmYJt2QJkeKpJYWRIInD4VgUWhReNGLR/aoVoRXhFSNW3K+aFZoV njVi1v2qqaGp4akjpt6vyg/lh/NH5N+v8oV8Yd8I3/2qdTO3znxy5q6ZqkUzV8xcM1MaRw9dZyyn oJDVwbBSPxpLSi4cZy2ZJG6lw1lEuoHKfioSfKT5VKZSWUFFJW4l9YkP0+jDNPowZlFZREVNazys hBdSX8+cMr6BzSktZV48bV6iA38oNrFoVskMCrmLqGygItG2H6L5h5h1d2srG4+SHmDjs3rsN7Jx H+mJdSQKcAtYmFtAT78FFPwXYBGVVipq7JLm0y+H+cqWSX1UWqlspaKSFtAyX5ovPkzLQ+JDUm7E PMrlU/6TI+Cw62wlNtFE14BZ2Mz0J0xvYDqVaXrEMsP8xQzzb2aYr5thzqSGOIJSLbOwnmkgYiwx P1JinlViziox09bcCMAsuphqFBU+ZHom09xIQsD8j4D5s4D5k4D5ZwHzxQHz5ICyXgo9d81iAlOj osLtTGcwzYgYfeY/+MzzfeZxPnOJWbhHoL2jlGkaU6+iwqePWMut0D8ufIpy2pIQK87y0a9kVgly rLiEquOx4mlUfR0rvoeqf8aKb/M9IfxDYL/ShC9i6Yd8JS7hr8J0ldL/rKf+RJiOLVQfo3op1ZtQ LISp/kWs+GrF/j5a/y7q34ugTrH/OWaz9TYI09n4z3rW+2ksdzHt9e5Y7uW017uQy/Z6Ryz3EI3e Fsu9gapbY7kXUrUuFlYcPD9WnO0rsQtLkS4qtk0Ii4onM3v2WEVbvpDqad0rV8RylbXKlR10CWWx 0CiqMhUvnxBCmM1254uF2EGmIsQ2kYIQc9qLMKstgpU5b0aQ1bpY6GraiuaR8CHf34ofVw4cnwvW 2D2+g0/Q8c2j7rvC9NgW355tyumK+Xbldgnhx3wvhR73PZ3eJcyL+Xbkdulo4sncLlF41NdBJzlK tqLwmG9r7lLfwyE2e3+IZumh3lCc57s7tMB3Z5j6Md/VuU8obmA5HfE8mq7PneKbWbzFVxnuEmg6 Ukw7ixh8E0OX+CbQ8PguYXrnFt+o9C7FlQLaxpbHfNm0x4wQc+WscdvFMdAKqyK52pXaxdp52jna SdoibZ7Wr03VpmgTdA6dTWfRmXQGnU6n0al0og66hC75QCRH+fNKgsamVBqVoirWtomKKn+Joagv CjqRnjtRp1QtVteUClFHNaprS6Pjcqq7tPLc6Pic6qhu9tl1HYLww3rqRcXr6U6yto4uUGXoWq+S f26DIORfe7NXqVdfe3N9vVAd3dGE6sX+6Bc1dBwGuo9Wh0o9SLx0qmeqY4p9QmX5N0hDj+acxJNz Kp7U6O3VNXXRB1Pro4VKQ06tr45OUzLXbeLF4oqK8m1iq1LV120TrhAvrpirjAtXlNf3miEotpIZ ipVKMetEUDFDUOhkZjOZGV2mwYryjmCw2+gpYbpiRJfPU8xoafe20mkXtK3ZSkVmYhrS2bbSxTTF jK6H7o1ZT92YCYKVbcxqAttYimLUEQ6TSW5YMekYFyaDjvA4Nr3l5HQo3O1OPcJsP2Ghnu1HEE7a jOi2oaugx0bUkU3OYNJSOgBjobPx7eYm5e8HDaGKFioN0RsvXeaJrl3s93c0v93zh4WMhsVNy5S6 sSX6dqilPNocKvd3NDZ9w3STMt0YKu9AU0VtXUdTpKU81hhprAg1ltd3blpTVn3avm7o3VfZmm/Y 2BplY2XKvjZVf8N0tTK9SdlXtbKvamVfmyKb2L6q55YK1bPrOnQoracElNWdotFAz4cGb6C+NNHW OoU9OSYFPFd5t6tAv7aMlLybQqVRMxVlKq8kr0SZomenMmVR/kLUM+W5alLAu13Y3DNlo2F7qBQ5 8FScV97709bWtlIpq1blkK5c5WFjK+lJG6ipjlYq+WxxtLgiGmkorxeUh2NVD2V1EduTxbuKxRXF a4rXFW8o3lqsXrWqnoYdTwZ3BcVFwRXBNcF1wQ3BrUGNMrGw7rFI8Ybgx0FpFV1NwkqiopztcxXV 9KN0V65qUwDtoI1K9+5yVuWU1ZUE0UR3uwLdmefBSSVEpYhKDRU1fkf6CpWDVD6josI1pLdRuY9K pzIi5Ul5FZ7zypU91ucoQccjFXYWjCkc30V145LuumZBd11xZnddXFLooTo2tchQYqUbbwHbSZ+n 8haVD6j8k4paKpQK2cZXdV+19W1oyxHIfVBnpSJtOSuFHGoIyule2ZaTA6UoFzg9AmSaI5x+3UNo WwU6FfSAUEVGbLRNWW2VUp9AmaBQrP4hlZnwUUlhGRrkd6gcovL+8RnyV+oLEDp+vnxAUt7e/3BP Ub4x5XZsQDqOCaPwFHZQJN9EtzqzsR7TsAtbYcHlwk46myG6w9hM8cJHcb8SbkGNO/EmFuISHMYB ypqrsU9w0HYq0ErZ4gT5KGk1rpe3kZUBZfgVtgsXCjXIp3aVmEtnIox18g64MUJ+Ud5LvZ/hsJAu d6CKWkdgp7vzNfgRpdHn43n5K/I0HYvxgLBaOEr3Vg24UTVa1S5fgEl4FK8J1dQ6A5er9+ofpbuD H+E+wS3skPfL7+E39Lu0hbb0PVxPHsewQxwplak3wo8MTMaZaKTZ7+JNwSmMkiJyplwq30mjD+BT MUf8g6QlP3IwHYtwM35OZ+N1HKJbAaMwhu5wttCyR/iLei/5Vo1VuAJryfNNtO5D2CaMEkaJbro/ FOkIs3AWza3D/bT/TuwWqoV6YYfwW+l+dcHxqXKC7JLfk2Vko4483IDf0j7+KhSQDe1BCkorVWmq lerCr6+mI2zGT7Ebe8iPfXTeP8ffhWxa3hGvEtfI8+XN8mHyRUf3DuMxBwuwApfiO7iXHtWn8Ht8 Inwp6slyl+pp9RXqY/KtdG4zUEq+zyLrGtr2jfQoxdBFy+t0lHbBT0cxXjhTmCssFdYJtwtdwpvC m6JGDNCvyg+kqLRTels1Vq2WJ9KWEpVMnq6S+VhGj8BVdLZvpePdjKfxnOASMoQ8OqLXaf0vxEli OS33ibvEfdK10jrVV+rrjh84/uHxL+V2aOkqm0bnYRUepLPwsZBIPmQJ5wttwkHy/BbxEcki2aSQ NEYqkWqleul6ab30rPSS6hLVFtVb6unqRvUWbePxi47vkavl77P7Ew35lYlcjMY4un6W0NV0AfnX SsslWI2r0Y4f0vVyKzbS/W4XnsRzeA1/wkf0CEAIkM//TceXwEdVZOtX1V17v92d3tfbne5O0km6 Q7oDiZHcsK8mbBHQSIgICChJRASUl4hoZFHQUURBiE9xA0cgAg24oKOOuIzMuM+Mj+iLCKPx+WYQ cSCdd+p2VOY/v3+KW1W5vdU93znf+U71DdfDp98AXncnvhfaw3gPfhW/gY/jL/A52kgIWgGpIDVk JBlDFpA7oT1ATpCPyWnGy1wL9XcHtB3MQeYzYGmWHeCGQBvHbeCe4t8RCoRxQrP47sW+/qL+Wf3/ lUVZd/aq7Jbsq9mvBxoGVsL6I6gElcJKO2GVD4MP7oL2LHjiQfQmehd9oq7175hgDjzeicPgDcWA Wg0eC1JjPJ6Mp0CbAe1KPBvaXNyMF0Jrxx14Db4Dr8X34AfVthWubRd+Bh+EdggfgfYRPolP4b/h vxNwYsKAN0dIjCRIJVzpSDKW1JGp0BaQpdBaSBtZDgg9RbrJYfIxY2UiwLZzmVbmYea3zGvMh8xP LGGL2QRbzTawC9g72PfZP7Kfshe4ADeaW8jt4F7jPXyKn8Ev4rfyz/On+YsCL9SDXL1N+FAYECPA Vr+H6z7wL183Jfj38U1cHruCnIS4cDItXCeeARbjyXRmCXMv8yduPv6eCeI/4/XM9czigceZMeQ8 sxQ3kFdwiAlwVcx8tBEN4N3kC3KWfM3a8HRyBhew9+FDZCkzEio6yqsfsDb2Du40KN1PUBVZjY+R N5g7mDsGXkJV3A58kttB/oiCbA+xopMQ1Z3kIXjRH8j1ZAOayaa4C+h6sPsz3Aqw93ByNy5iPmR3 oK+YMPkHVFdbgDXewxPYfHINqcS7gXH7sR/14VbUgh9ECj6KP8cZ0MRPM0/hSUQPaO0lBjwUZPd7 jIw/ZLRoFl0jjhIbriffkxnMi/wJJg1lzwn0J7QKMzgJvvPzTxbdCBHwAIkBp40GNvkAD0FO9BDw /dnsi5SxuU+5DeBnjzHFaCpKokbyDqqC2PgK2kx0FxqCjoAP3o2SZCu6baADzwPenwz8SRDUbSiB dcCWDlhbO+QLOwkBF86BTz0P/P82sP5E/B26BQchso6hApY+spEdDczUBPy7Ado81Ai/bUf38we4 D1AddiDEBrM7wMv/iq6BnPPf8PluVA3rm40eY4th1UFg5lZ4xfbsOKRAuwu9gwlaDWseDnFez44D 5t0ysAiu8HrIUZMgJx5H1w88hEYCdlMH7hjYgOYMPDZwNVSq0waeBv5dPrAfVaBObhZp4OJsCjj2 OH4d8tFf8Abg7XHoz8BHEexEf4P2W1j/cO4oWs9+AtxZM7Bx4CNkA3uEwELNkEV70Q3oO7DbOOYY Ks9eQfYNjGFaIEOdRFMGnhoIYC1aOLAEmPdFtEvggHs6kJ/bBb67gZ1PkrDeQmTHCTh7NbcT0SLL C57opdthwJGT9xF8lLwM3CaQV/Yjjs2Ql19gkFagkwMYuUSeewUeJ4jBhUiDF+NrkDMunavur75C Ols9ub8a1cBcughdWVI2y+YIdNjLootB5thFhUMXwKOPwet7B3rxm6Ac9OAnC4+SZ5ELaQaOKZqK YSmkKLUpke4j5vnllNZ93rigAilF6dRT6BCsN8OMP2QQGINi1cE8rRgQ0rKSYk9pFfa8SzrXd7bP bKlM9KGavhrpVFkSt6qaJ47HjMJhJppOVZQPsdvyBIb2fDhEz+CF0Zn8yESilr2xtLa2FA68gClK u2smTZrojF9M1pbQ0yW19C6BOyHCXoSVG8Bnth/KuN5y/ahn9JmB893hSEodS5IpnBk43Q1LRpmB txQfTFxO6NzDoPtRjwW9Q0+03jvhwgzg4dO7BcZthHF/HoPgkl4wGLSskV6b3e12mLU3sL9z3IDM 2Hynx/uAvGgVVJ7nGvvP5S5z8Fr7q2uoyeO4tXGwuGnDTOySq5UvvXSiVNjJsNJ4pbUy2zzUni4p rnJXMGGcv9LlqqmqKptxbfYvuGBVsVJ1WVns3uxnNN9Nz04gt4EWtKIqJbzF/JSZ3KVfZybarRoz 2goqB2DQPG0M1fOY78ibfg11i8a+/upqqZoi0VcGUY8bsS0ai5K0hIbaeJ7Y8hx+Qm576LrN2/GQ c7fuuEJ2T1idXRqZNP8+vP5DXIEHbiwa9W12yxsfP7/+qUdgDaWwhgZ1DZVKfiFbJI7jGPhwMyzC CmSm0cICclvMDN9hm/nEvy8CN1rTdofdYpOQkK6osKRTsVJSuvW6Tduz7/94687Jsmvibdy8oonz 78/e8lH27Sy+MTL6G7z4jY/2rn/yETVr3sNexf4O6dBOxZ0gCSYoBjVsAgW5IJ/QLUVLdXwTWAAE /RQkMDGkhVEHlUUMEt0UqqFgpmGmHNTpUBOHuZfgJN22hp6JHcJNIhaP8roME1PcXBN83NEgSRIF suAJwgUJJlfrZ+Ys23q2EWKstxEl+nql3kapWjrbp/7r723MmTpiltOyudws22QzcWSN+O/1+GxW fw/+x1T8v1nT1KyBonpjdjfeit4CLTlNic0isxyv2xmNo8l1wsVoMBJY1iRa0EGLotexVSZbwNZh Y2wZXKToAqY5JmJyObeDkSH2Gyf3N9KQ67VUYrPFUUktjVutYGKwcDQcEgYjTXVA/sYFrRpB0EUs eWVVEytGLNiU3V0c2lRvNWjyNFXlZWNumrNgH13dNNxBZoLWZVCNEiRch29eRTuHsfr9CoOIhOtx E96Mu/AJzIOITB1AHez02dRA/Y0U80Qf9HQpcSuYYRrh+i8Qx0P0ne8D/lkKWUGH4ooXKbyOUTRK VVqj1KTnaPBOzfMaorlTT2NNOtfaFo/TaytLRi7lDJRQVKp4Te1LEwp9X2aglwwHD2XQVEWDuHcC wF0YU0ANhMkjBJYNHKaDqA8oeUEmyTQxLUwX08PwzFH8HHmHzeCl+07ST+07Sw1aXVPdyZXGV0uv 0+AGGUaGZ231+Bvu3n82cM9SPpowcJo5xC1EEtQxR/bPFYMZzO/nOBsdDAZ3BpsUi8aNokqUKNGm aFe0J8pGzfS0cQ4I+XYoH7qgzHVFjmA/mHYQzb4rpMbWc5P7BsNm5EplEs4P54fyQaVD8ie8EPF6 fB6/h+GtUVNEF3W6HC7Cy6y5GQV4dzPOM8LMrodZPg42Y48InUWyNSOXFjqVoWhXpB5FRbdbU5ah 4B0OuzmPgIVj0aGSw14+pGJohRkcKOdCZMLGZbObtt+27e4Pml+7/YbXR1e2VizzlybzKwurRqXH pciO07huau3ON7LPf5s9+OBXr/6YPb3vwblte3Dl6W03JeXLp2W3A0bfQ8DxYDE7ekjJU5xNzi5n j5NFTsVJlkOqJ8ZaK6jzWshvXZB1GXUuwjwMAJ9HJnw9ZFBIBfjvihGbTFD6YE4j6gkDheiP8PTx isVoNCnmdNLUbtps6jKxJpfjCMnHvYPGjVdPliBqq1V0zTRgKtEPfRfxD/G4GrqtjdZIuTnPbnfY 5PRwkqYGoNf/PZ4gW6uvzpKmYXatEHFHRrC/f+xCZ9swP4lEiK9sFfnrA0VBf4D6YTFc4264Rj9e qKwRnLpKh9N7ecqpQOeinclvtxcK1cJ44RmBV4JXsbPFqxyznYvFZeZllu26R40Pm/fo9hiPc8cd bzk/c3zm7An+xP7ksNmwj3VxHpvL7nL4nILGoXPqfCnXWNc6x6ag4HQR4nC79C7ewLgIxzsdNN1Y WUMGlqHRKHn6mg4N1mSYckUvce5NLrzT9byLuI4w5WC4e7ox0fsz+B7I6fyXddY51qXWditrzWBB sdK7AtwoqAQ7gkxTsCtIgq6j+CeIMwNWlLw5UCq0k03kFSj+TpL/ISJxBY5AWfWLP/dW5zy6cTKE lUQDq6+/sRWSZus+nt5CcGiTBr+ieV9DUGPrrHgvpTAVGUtlJZFyT3lhteseFzw+y1jdKXGrXze+ TsVFWyMglhMYjJxGKJ0CqHghXDGYa3mBCPKQioqhzO45F3ugTgruuHHezmjE9f62XZ8nJzz503Dc vOTKMW7MZS9E8Ai89Znbn7y59fCbH25esOA/D2S/HyaV0b2paRDlDYDnEDzpMNIO9OzXV2qoRKrW V9ZqRmvH6CaG2Pc1uLBwWKGSakq9n+pJ/agVUArXatrDq0qfzT+cf6T0eOnJ8MnIX0r/FjoT0Y8X CzN4Y3dBgYQypLf7RBInM0zqAMNJdmzP4J0HfEo8kfJl8MhuyVBYcBQvRHlIQ/5b0dUDBmSzigEg 2b1Xj/UZvBnOl3SUkM0lXSWkBM4fmCO0w7VnyFeKVknhrtSxFAE9hIcfUqyvWInVVU4J5/QvAKno 9NHEBl0vqEmgnnhfW01fYx+VOCoHVZQm/FGtieVDcljOlyMyy3MRYzSqBXJJsCXN2G+CmayLNWOt ppRPNuOAwUfZRqoe3AQruh1+1BhrQyAMrRUq5wBOdhUseTBJOSD4KPukVe6JhsM0DimywsKqfWsf v3LEkdUdLfdnv1l3bUJ2uc0rHJGi+Q+F3YH4liuCdTvH3d60bSE7Yd2Di+pmP7Cj7OCte29/elTM VyxyNbxux5K6icN8BbV+7TVr6xa0P0k5PAjRehjQ1YKq/EQpsBuwCY02KCZGMeEiPbYJQLiY0XA8 ZvU6A2L1BpbXGyCqvIpFEPMEQRQZVuD1IgoYsOEo3g4KXod3KgYO8xqR50WO1evZo3g8xIuI5ys6 jcbE4J3M8wxhMvhHxYlr1PAy4Sbgqx4TY+IVAQsu4yUx1FqtIlQNAQTTUxLV+jWVCVAe1VKf1N9W ba40qwHTWRpnIV/RqclkAkZrAzXS2oZtYXMYNAkuhwEzhw/u6n+N3Hzjrmw+Pntv9hE8v4NZc3Ej eax/DuWvZvD3ldwkJGO/MvIJFltm+a/3t3PtfLtvI3uPT0iTtDyDmRG8Ul7sXc6t9HaS9e713seZ pzVd4Z6wCYWxesOuze4Q8yDzMtRU5qAMKZcNym6PlxGcLAdnd3YHg7L1CDCJk7EqYFP8JSJfyjKo siN4OPLgsQc6hC7qx/gH8OMwVsJNYRKGAPnpoES6ZCzTN1E0QUXqkojkCh3BD+IzqsV6G4HmpUZq HdW1e4F0YA75VHVoYH3KMp1iaZwDcyH6S45oFEMbbiNtwTV4DVkT5IFxKNEAz4y8eqaiW8wutczz t3AtPq5xFogsQRZY6sE8f4nGGnRe8N0YZlZekV04C2u23Xnl2ik3rVy1tDTsjiUmTr55344NN7yI WW7SswdjO+7OLD7YERs6bYg3Lsmpfe23flRVIhAT9c6ZgMU+8E4nVKEXlaKbNcu1txjXaD6LnInw PINXM6vYVfY7HWy1WMBzTNhV4OKZ4ByQssAdB4NRHI2aQJzd0+1EHBUn3SYDBuMqFCPFonOjIqWI KEVNRV1FPUVskStnd3gIWSVr0Jq0KtbN1i6rYHUV/ipRLoLg7B3UKCpVAKGDVRv72sCM+FdbvqDj PTxRTQj8UeyNaCw+r99LeHPEEI1owsAQkqcZyUaY5WujzdhrCTajkB469LNGoaShUga2GRnhZ16n GsWcsuRXlGPelveLxYH8mS1rn3p8cf7m+za8u+C2dzfMffl+bDq/uP9dy9gx5eOvXHf36uiV3MKI oe4/f7/u2p69z2589upu7DuIx2Vn9o/qnNb0xYjEE1t3/zMIUTBpoJfZBVGgQ68eRuxAT7fVM5xT v0CFiUvEHFOkGYEUQ5Ohy/A2Pk4+xZ+SHgOYFOswMigGhnAsKMrfKG6G5DEMYRkDp4xNc19iHgb+ SwxunsEPH+zSYZ1Lzx0hpxFDvlb0iJVYha1nu1iOfZGcQvpBu9Nqqlel67M0g8alvnhOn3YaV78+ 6LyaZdwyfi23lmcHHRcyZBvYERQ4yFcZZJwQ+wP5JFvdgh/MbmhNTi/3cZOi/3yZfcNT2qSj+xC3 gb+tB39zoSgqx6uUI7OgtCsPlBfFlpavCnXoOvQd7g7PmkhHdH35M85d7qci3foX3IeiR2NvaN/Q fWKwC0iLeQNxa2J2g8MdMUSME/FGfIfhTuMzyHgZqsIT0UQ8vmAOvip2dfkitAhfTxZEF8UWlt+K b4stL76tfBO7iesQOsQ15jWWTXmb7FvZLeID5i2WbfYno8/FnivPsAfFM7q/6c8Yz8TODCkUDJpY FarEw4Zwo0Skd8dYtZMcqhbnuRI6WA2+Wg3wugY8nx5JmEvAxRJKK2mipJvSXemeNJsOvwgPMBAD RRAD2qRDcWx2MA5X6gj+bpBYqDw/q5JKX+/ZnEKnDo9p1QVOPiSe8IfMdla0RWQuDHJc8DXj4ryi ZlRqgYwYYiFF+qkcj9tLmlHCXJJz9UFfp/mRkk0rRS36a8km2B252kfdVIhUDPo69XwrT4fBbInX Pdb47jNPvLVk997KSX/e9+qShpW4bIWyfP78jnRZxbT6e25YsiY6luxe29Ww9pX9bZN2LL77ivmt m95ZOfem2fs+XrK67vpbltelFiayX4/Z1XT7tlVXjqtcBBw0BSLhafAJB4phvVJ+a+wz7pPQZzF2 IbuSWy2u0tyiX2FYab0luEG8w6rViJsKyWUiF3PKMSfH+CMsErgj+FrkxMoLsXrIbMBMiiYRWRoB 5Yz8FB4jBxy18QWHAxmclIHc2HQIWSRL0MJYMvg6YKNCpbCjkFEKmwq7CnsK2UJMOUyGpynaV7RE 6yr4Fz3TlxM0/TnWrxkkJ0ndnDLnOKoyh1eRJ18066NSxBsNRwMGuRn5TLRsEmEW1PmhdjJDF9JE LqUkCpSaExx0F2NojvmHDooZAuyEKUA5hFRqWrKm54+Fj7Zvenf+rW8+dcv9//XmYy+TcsuIlZNn 3TWrdk7pf3gj5Gac//x1nx/av+GZ9bsvfJldefsicnjNFXO/WNG144NbGopp1Q1V82ZmL/CRA43Y x7joDSM+w4KKza4uKP4UJOiB0E2KDYrp1GZbl43YXsQRyBt/wijHHmdV7T24ExPHl5TT1ktLa3lw F644UTuCjszeXI1dWttvHZGbjaCZ6eqBr5jLuMVQpZWi0wc0oilJCKXHYcl0KpGsSdYl5yRv02zQ 7NLvcj/u0URFvcHISHaGkwMsNhmtWvqnIZJA6O5YcbsVQ6lx8IB2jItBULJPVTxhpVAHuhdFi4V9 J33Y5MO+zqh0g/1UcTKDbzgUVYLFyWJSfJQYUAICemi3vH12bnfulLoZ09r6y/7cuWrI+404V1g4 KhGF3+z4ebME3MDt8Ip6T0TnNPiQxi34sN6h9WHRCx3KoQ6Ig81aMdQWQy+Jv1/MlgMfZAAvXGrM NwuFssnV+Z3NV86rLpWLRr/25B/mjqu96r5a26B1sfIfu37TunJ4+5apycgSb37ZtAmtv10xc/H4 RxY+se5sbULd3VD3PudmxwjF3L1oBJqOP1cWPYmerP22lgGi9koum7feNcO73C5gCRWcRn+r7Wk4 N5qdWf+k7Un7iQY2WB+cEpw6x8nKKIihcqhjF6LryAJfJ2JXovXoQi2zT6yl/78hqptaNqKWIFbH uovqassJO9KDMswIRSMNx8MXopF4JPx2aIRpTBSNELxHmRHw+R5m7IFJt1f4xzgyzBSlQhhTmqrQ Tl3ADisrm9GgG1NU434u6El6FA/jcTdUDjON7xhPxj9trQqGkiElVB9iQ64ZDRn8GQB4jTODh94Z j19Bg7i/EcrGcyrfUiD7v0I1Z/sBWcD3q5qaPumHxv7Gr9RwzkU1PEk63ikZq1VILxs1cejlXHLs uDHjRo9j+MuqqqsIXxzVRGzRYMQcyY8WgAgZdfn4ZWji0PE+xCdYHxJLdMuwPQCeeHM3cvrcMB7C Xo/LLUXoOcWHjDF4xriqkcvwhGGTfIhLCj6kjQvLUJ7sUF/l8uZGS9gE4wGsLzQtw+iXu15oNQT1 0L/8FBXlaJ/+DBsGNTBmfiZ1SzpF8sMhltjyLGx5EFnLCZJD+SQtWVD5ENZiU/drKPvwuVHdx7E7 hgo01Q++SQX9m60o13FzrTceHP/e/buyHxz8Orvs63dwy4dYwM8sq5qdjWb/+F124Zfn8SsX3seT f/v4xXWTJlse2D9q7I0vbb/pqpGzJPm1iZNb6y8bW1zVsTE4bDzzcra1Z0V+sPh+PG7/bhza9kM2 df5U9u5XMXB39rvsni/wo+exiI9jvDt76PCh7MNPjKsddlX3ovZF9+GFrdNGj77RWrfsjc0za+pm Hrp657wRV4CHSwhxe4FRvChAnPuIqmgsOOAnfh8C3Yh8AQzqMe9l5kvkgEOAQ8t8qThE4vUzJtFr 96FAC+7ABGPRRESUqKHE/96J9xIJ6h9SX9933+JE7kda3fn66xIcZdQzRaPJZJC0fk2gXuZtJqvk Nrs9Hq/Tx8v01upImg7dyZkpdYyXquP+wtzpYDR32u3PnXaop/fb1EF5SLKmDCYdvHmlaYJpjDTe XyfPMl0pzcib6V9kWiAt9C+XOthO43pTp9RpWee/O7DNtE162LzNf9h0WHrJfdj/jult6S3f2/6/ mD6VvjGdlk77fzKdl37y/eQv1pgmekgA9CEYCfn8fq/GqPVo7F6Hxy4SwSPazHke2wq/SQpKfq83 ZJbyzC1mTP88z5ghxxUz8ecR4g/4diGUM1wGH1D0omRibHa7KGpEbwb/U9GY4DVkl1ExZ0iyu86P /RnyrWIMKsZ64/dGxvhUcPF6NcO43BCzTjctuuguD3V16M9CGdZf3WnM1VqdjcZSZ7yTW/163Imk Piwd+/e+U1r9erVQDf/U4uvXm8baoOqSVb+m23Pg2ENxOc7t1amb3TrCPNP/j6tDlzVnZ8xwlQ/H n4fxp5WN0/rPTKksuPHUt/jNj+tigYQQiZicyd+wV1/YevcULhJhS+XiOdhA8vv/SuvfCQNfcCbw w3xMlBEafwLT7xoSgS2mh/2Pmx63HDQdsuhEP7Y7oPy61bbCfg+z3v4os8W9hznKaPSMkSW+ccws hkuIkjkf+BNzB4gH4yPApBMPBh/hCrwMzpCTB8zxvRKWMkztgU2GnQZiyDAJJZGnIXsQxniItOd5 Mw6Ya8zE7FagkNNUB53Y5Aw4iRNKZTLDOT4y71pV8MQb29Q943NtrUCWrTTjtZ5tPHuqpu/bs2BO qlePq5wYtHl4vRBxR3VRe4T3aEqQ3gad6OJKsNZhKEHoF4mTUzhtUHdZw6qUoRSk7gk7eDYcpELU kk+TXvkQQIH9YyAw/NRjnX9evbxv69q3VwbmZ78/mn3+8PqDuOal32wqsnjy3Dpucbb8/YPrsh+e zGT/vrn16bwDT//zyMV38PSj4+xWT5LmuDAwAN15sIO2Y5RZOo/Od5f0oPSRxC2Xlud1SlutD9uO e477PpREp9mS5/Mzgg13uu/2kwKRD3iAG4WAxyCHHbIrUGA0GoirwG5Hore6zoJzgjJpUSycJTPw XwepDS3jwzRGh9eklTAOhnFLmO5gMGHZwVutZIZDbzLRnj7VAYyqlyQyg1dP8m56kt8RmjuIQTxe Pblf7UF7tsXPqaDk9Ccc5spKusEMGHjdfpNNiuRF/SZvA3bboPOZAw3YY3U1/Gx+WvK2grO3lqep edVN6HA4LQeB8SWBl2NgdWSWUDgkhMsb8u3e2ORyUoCT+PJX97yavfkv7Q2n8ZDsH76ffVNkqHwT s6Q9WBxZn335g+xXL3/Y7MVjsAO78Cgf9fUihNgXwOLluEKpUdILvLd4tyWfce5JHk32pMUGVwvf IrSL7ZoOvkPYJG7SaPIDHp8cigQ8cTksKtQgomw0BjQeUaCmlOkZQSYkwHsEr+QhOAzc6itHu+Kl qESi25PkA0UuLo6DQ+3yeU57vT5Rs0cU+T01dM8SCZJQJzDwXqeUevW9lpfuKY4HShLw0iXuPUFg 65OgJKbVp1ugaGPSSFKhklRUJBUqKRTJV6HKV0/mq1Dl70j1HMadqhSmMKlYQcw09p1t7O0HuBr7 qtW9aelbYCsYsiptQQap7q+mBYPU9y2SfojjwXHw+wJQlTKNgHJzWN2slOl3B+XqdydDyxlZxe9X AGkswQzvwUXLYik+EjEaLVNnZD+WCoadumlhcnhtwc0Xvkkm40GHO396krWZYrbyIQXXcaT/dLh0 WbbgWm+4IFs7O+YIJoavzu6JOCTlWqb1dn9BJPvJ4nqbiSIqA6L0fsESXLSvIJHBfmVoZF6FhtVo 9yaYrfEj8TfjnzEfxM+wZ7QX2AtaTQvXwrcDxh1cB78JMBYFraaICLJen8FRxSB6BF/A45BDPIBK zxRyHt4Y8NjlsD/gicrheHGBVtSzHAGowfyOEhSOogKpgBRQpCOxWJTYHWIsXrAHFWJUmIRSrgUq uM08HxBwnYBfUUvCA0opMqpIGlXQjCqSxpDfpyLpU0/6VCR9O0r/LejOQsxV069m1ZoP0Puu8Rfw 1KJPrfnig+j1/zwChK10gzSOzRQyALGUhMNmqNqA2Mpt8q/h9zN+8Dh+/McZdYZIBMdGj/rRoIUy pKz/SHJ61GnQBsApmP81hN2jr1sEoH0zcWk2XTchkm1YILsszkikLLiKWZKbZz+eM6uA4jUOss2z kG1SuFGZrmXHlBJXzF1AJKfkIsEKpaKpYoXY4mxxrSja7Nzs2uvc69KVJJbrOnWMs6LUXV/RUrGR fY7tqWD1zF26YxXMOBFwcf4jZKGohVNq/ulW8w/uRoiZqIwse6TY4XSG+IJixlgQ0uB4wK+nlver Rvbz1Mj+kNlcb9lsISZLnYVQ7my3DFhYC0vRsACB9r6gEmiGnFd02ur6KDZFA1ESzQx8r0j0baIS fTw6Pj1v/SBWQIgQZ4m4CpWKWq9ajlKUpJ8z1SBLpoJxQRIjBbHCWFGM4fXR/IhJNl+GgwHJLMS1 JcgQhk4KGi9DmhhfgnURYwn6F4FdlEthcTVG2yCT0UQGKAapfMhlMjMt0tOyjX69aTODglbTGgTu L7u4Q9kzAPv0lS9n+ztbt/yjY+LG2kDtVGJwXeHLu6lnXfaWdx9umL//wXcmrFw6zGr1MJDipndN ufm95/7nteyxB6MRfPf8GjkaTUVuyM4dXnXxpR+7n/jd9Vc6C23hckCeZrtHIVJH41tyavfQWIUa DUUyA+cOUEQiqczARcVCpynV91MqRCkrPEGx0tNWHFKxC6nxEsoMnFbUgAmpTwy5ayVQyT44iuFI wFGK9NBr4KiBoxr0s+5ylJ9fejkp9WoJqkmoqvk9EMvffqt2OEFT0rH34nT8PH6sLBn3KK0tY7vG nhjbM5a1jt3hVSrqYUrA43RyKBTweOVQKuAplUOjA57hcogEPFo5bA14PHIYEkeJHE4HPJfLYbBA OD/fM/zyy3U6LSktKfF6PaLFGiJKCJ8MYVoftoS6QidCPSE+lCFBxS2NbRp7bCwTHIvHjo6E0vWp phRJ7Rgz96/O+GTpbBu9CUpqbVPJQL0dalCBQstRwc9CMrcDQsXkr7GtugH4wf8b/PL/nw4GX4J3 keXAA/FkkoxSyRuIoDiZ7H8xOS3q6l+vPlTWf3SQIuARMhqMCELuE7x2YY4YHFLtvIsP/soS+NHs tZdwxuJLnkY5oxzE0gp6Xzh6VVkqq1lYVl1HVgrSLnmueV6FGPAQOeQMeCxyyBXwYDmsCXjMcthi BqIWnS5CvcYlUi9xsfSlrpCmRewQe0RmQMRJsV5sEpk54jHxhMiILH2aqHqgmBk4/wJ9LUyyik8V AHODLXKH3CMzSblebpKZY//H15eAt1Hd+54zI82idTTaRhoto2W0WJY0siXHcpxoILuTYENM4iSY uAVC2BrbhDSBpjEkwSRwSQplCa8lYQ/LewlZHaDFtCxlydeU29sboJT0fSmlULfpvSmXFiy/c47k JPT2PvnTOWdWnTnnv/9/Zxw5HqHwpFyEZoKIacT0A4N1WU0EdG0WcKn+D+M6ORPUun8YOjSoZEjV r8lT3P7q+6SNRyiNtOARNEIK2KfLAhCgAhSoR5dQV1PfprYpO5WnlaOKBUZH4N16s+3Klkupy0IU GiE6EvVMkR3ToqawLERiSlgBGtABDX4fcAhUIEbRHHgOXk+NUK/qec8/MxN53kQ40ET2msigmR6O fKP3nMqqSb8zZ0gqHNHnqV5sHmKqHERUCb105Ot2nztRJ0xiWbQY7o+s+fLj5sWqmxh+K69fogiW pk1X/OC7q+C32eoOtVVZQ1+HjT4VNujrv3puUdjtyt2ERiUKAPMfaFQ0+Kb+iV2CNsB5bT5ryp62 Nxg0VpwGp+WXSqvhKumG/HrpAfhQ/m3pfekT+JlktUrIRWC02RrdIrVocyTaoyWlhEYzklHzeukM SKOtqaDNW5ZKvpJWaepsWgVuBmul9b412jawVdqi7QQPaE+DJ7XdTfua3vG+KY02/dr7nnS8acz7 qfSp72TT5+Dv3v/S1Llwnnd2fhlc6l2cv9a7zve69Jr2K+lX2u+k32k2e1jmI1ElLPsj0VxYThHp wkViArFIImE5iax/pNwAdAHJB6BPkrCnO13LuzTJq+Ul5M2hvnv9Pp+X4jkOAE1LpjhtOeIoXz4X VZTI7si+CKbgkxEm8rDeBJsghW9hFeyK3UFdan+4QEgbzSWWNwuxDYkb7Y5yvoomlIibSbGDg4xn 04yolkhDOieFEF8MDCAjBKcX5bzgslRgrRDKkuQoS4JYBpxU9o5MHD/kLXs1V7kGeCDfpbAX9EYg poyviyes1iA8j4/OOwzp2eNnZLVLq6Y05Du4bPMXIdf/j/AUHMovQb6E2pUfH9WWxDzjfzXc9NXa DeEGVS0qg/TaZalgUv3yAwPZ/Grb2QPbvrwTcdzE7yY+RXbMApCEr+jzt4lQ3A6R/9xZ2k5BMUjB JJV1tjrXOR+kPqImKNYZjYoC1gvRCNYLURrPa8yF5zUmig5IUVEx6hLFKOLQR3V78jlo4nlIyX5O 5GkyHxZxkcOhCJqgC7QwMnHyoANNDmqcOUg8AdQgLp7wcBr7JQJy8dJQwUu4T6aptNOFb+GORLQo HI0iHUp0JjFcotiEMRFt6kt949FJru0dwHx71rtDO1D7Y5KIr8312NhwPZuMjM0ymWIWA+BA7+CM Hj3Fiz4xDSugLHaCDnEFWCauBteKN4v/Cz4NX4SHxLfh36H4Zwpie2UpQBbpwAy8lpCa2HMgJFYo HGDyWCvI8PrkMCIqPVDGzf31SibVYV8ZSXbcPKHbxbLoEcuU4EZfXxkZDCf2m8voNsdr1ReHXGVK d5QnQ5OTmQ1MVaCXRkRV/Josjv0jlRFHRob99DRMMfAEpqX4V7fJiU5EWJiQpk6bGpxqXPAVS9sm SeXLrYaZX/3oLOHsndXo5JHXjy3gdQSPLIPn9cID4h72adPTguHbcD07DO9gDTM4awrQ7hTDS+34 rQcUoAUaA/h02kjPC+L59VdKSlAPUkFHO35TAmXnwzzFzwvUQyTYGV8oDGQ+r3nlk7i6Jihj/Jw/ 4UzYLI4skKGUhS4WtTxG1BJM1iz0UagQOXcWeA3uLDh/sDK3IgZGmgW54hFcTmnBUQIHAc+JDgF5 PmOQg5uqN1c/q35S3fTrl//r8Le23n3DgZf/tvVbyFRcXf1l9e3qKng3bIcz3nl+3vCe6kvVgwfu gA3wAnjZs3fgiAiS2IYM0fSNcN1RkEOPem9bKZ+7SVojrwl8J9Wfuy/ArpeOxF9IfSB/EHg/zviS Qi6VKKvl5NSUlluWvCbZnxvKmV8H0B9IB+YH/t33gWzck4Jvxd/zvh9/L3ki9VmcCeixYIqzYVEa hWGZjcSQoHVHYiCoNDYEU5VYZww5Rqy7IeXxuCmO5UTgF/yaX/f3+43+ebl6FAXkoJ7bl6N25UZz x3N0rhESBQmJKoREQcKo3Ua4re7nEf1oezibG4HfPhDBjl3mov8eTeldiFf2JejsH2RSjS2tuXkk M4BBSmWxpkFxhCWe9gYkNZVIexPNMB5ARdLX0AxVGVnd5yIs87rX60IIiZ/YVEM0pExFUxgGkHgP IFNLww4ix6EXW4r/XcJi1mjy1DM9SU8dgIBBSvDxQGJhcfxFpJ9dMtLP8C+H393xwc8KgxeULgmu emDu5u7mLuqW6k1DYaSfW8Nr6Otxa/7+m588bptjMj0y1PPAfCfmiupq43rEFW6QAON6ehbsYe+D NGODS1BrJVwLb4c7wP3cG/bfAd5g18GFkF7M0Q8YRqjjep7zpAQahJ7jOGy/9IMhYACXcJyVzkTb w868kzqH7zA656UmOSilI7fd3y5YFStlt4atlHVe8p9x0CmcWOtFfNRewchnMuw6n1DUQMJsMVko RlLjMTVGMWF3NAuDvB8xjx0VCQfajLhCWfRUsgVVPOezebIwJqKCIMUmwWINGJ1aT4YbcYQ3EY8n 6/h1zGsuAM+yWg2mmqBvXzn2wLbq69Xfr9zRffMw3AaRyQK3IN67+fDqu+7+1qGXbhzuKP/Ivu9J i2K86sBVbRd8A8qvQA3eU72heuxv1TsMn972WHVf9cj+rVsfhe3/+eTQ+smY5CrEgSlQpCh9f1zC ZKsS4h2OQnFL4rXYa1l6XvypLCWFvbmVcZqHvJpQ54AeuJpaHb8F3kLdGL5RWRtdp26Dw8qD2Wfh s+qRxEvZibibUTbDu+Kbkw/Fn4CPU0/G92Zfzp7Q/pydyFpF4IF+SkwhLiu05dq0lfFr8qYGjgoE oDss2yNRoKZkgMx8WyTmwT5XTKca1Xg8SkEXMvHjz1EKxTaknyBhOS/uLiuwXWwfS+8goCogPxco jsDv6famVDAYoOw2G4SAE0nyoqeWvJjVWQKRvRGqExlFVOSQ0AL1lv6W4y10S5EjnM2RceAIZ3NR j5twtpvsdBPOdj9c+sZR6AP/EK8RerGXliHrdfM1rs7XubpuPI2NCYitewfzGeTTtfv8wtgwThxg cJtY9iMpQTIFGYIGLWgS5vtsIRQLq9lYvhkWQqjIRRubQSyuKU3NEExS1q23wsFaZJvoV5XAOSHS +ftdZcQHJw+7iMJEzdOHhLIm2JGKhDXNiMytTCYSgYTl/38igcU5Cdh0FpXEGldV76+WmhVrSAgk FpSIcCDGO/zTiWPbH3sWSn3bVn81zRngf/Lark1tV1A3UxBW135dRFSevmnDSKJ6y+09Fur7cM9t G3c5saczNPFbgxHJiVZqie4T72uEdminzDSwG1Igbcx0wk6Kd7SNwNn68ZbWFj8tG1ZIK3wr/Ctk xmg12kDDaJthjXmNdY1trb0/1B/uz/drW7nbzcPWYdtm+3Bmj2FPsyBam61FaynYHCwGSzghkjUo ISWcTmebp8PpVMWg+bSQFtYi04rTSnOtcxu6zYutS4TF6cWZYBiGKbk5XJJbuqVuX7d/adNlzZcV Lytd1rJsio02m9NOs5yOmZW2qWmtbVAcdG6NP8g+mN+p7cmPpl5peD0z2na6zXUR1yqD1ZS8F/4c UnAjrOdTdGvpoUJADq4Oy6HQC0G8p+h7yIWER7vF5rJYbBlLg82Q4EnFxOA48oBSBTqWwnkWqIei RQjDCZgYgTFdyDtedlAfOaDi2Ov4yEE7RqjhI+HnQhkB46bRCeFdOfhy7s+5CaTa9DklPfdztEGD nJLTkMIz5F6Cs0EZzoZSHYjSmxlAwnLwDIY7D44PlvOZmu1B9FYdf4DzYjbsE4CzMTDS6oXCwFhd tLbENdaZSpgb+WaQtmOl5kQFq6FNU9bSDMyWxkxSQCrObks3qCJSc1yewTRfC4aRYhJhhFyGwV5k kPJXmFdarxauyBh6l/ZCpGPBQA3kaDFL9rJBs5ebNTsxD5dCEhatoVm8IaqORKpBrR3NIWoS7hhP TCIhcOiMflYVe5+7bNUdmel/+PGd8//80tRi+Kd+X5BVVX/Poes3fG9KW7L6+L0LTv7v69e3ev0R E7KIMsO7L9948fTm+RtW3vD9ix/6iDdWQnn4i3u+17d5WdPKxtBP19zVfc+/lnzhPKb86cg22kds o7/obcvgMmpZcFnoOngddV3wuhCXj1QinZEHjQ/Ie4xPyiwFgyEP9umjPJaeMVaKgTAl2LnICDWq O3mYAbrXVhHt6HZdYC8G51Ep3c/xRM7xRKTxRM7xUa8nnAlh+WjDV4CQEFoR2h0yhF6gUsAz8Ufd jKWgh8g/D7r7AeXK3lra4UwvFnghJGDNJXyD/WZ7EQ1w5pTQXg9j45kBurmEvpOHPiamDg5eQeFN nMnDXl8tmpmoBavPk0MkIsXGnIZH7AmzM3x198vIIs+Pv4LN88dWpIodbEIwLqj+pDveNuXLM5Om uMFic15/GZyOR9U8cdL4PBrVHNx0FGjI7WjIFzWS546TWu/2BIoppo1ZwKy3G9SYmmyKNSVnxWYl n0iy6WQ5SXVpa8y32B9Kvpz8IsG022qRqHBY9kWiDSQS5QzLUiSGXHOkpyg1ZeUbkI/2l4N41FDj Y+LAkQYewTT21ASe53RLmdORkcJpHMUh9053uFxY9xA9xJBAFHb6aqEq0tOZlZKgwX5tt7ZPO6kZ tLBCJlMhk6mQyVSiorjRCVc7oZPoLqcNH3OG8DGnL3/mnP/XOxm3wchX4gFmes8FcwgKdhLbUdDm X7z++SkcYt1EJGVyYMQ8xdjVpBq3KVkgOBKWdBaaTRFBzYKUWcVeBawZPwTwCnsRL4IBzLLwXDSM QDySCaRrvhYkI/xX10D0L+DJ5q6M++Kxd37zsabMWthMdRS7477ggu2rtry7EGkcY1JVZ4QHxt9/ 57ePPHTb0r9S4oaLVLUUHxx/vvOdwY41h05Q6kalEdGBPPFbdgOigzIdqkWnD/OwNZ1wOUbo/4vd SypJBXhNNphFyswBHDb2lisVYfw4+ozCPMZV+HjGylo4E8+aTBpTZkWb5Cxb0FfG9MTxRVQP4TqA av0T1GjhS/kOfqmhh3+KZxJMhms0pywpZ8qflhtSyUILU/YXtTnMTHa+ea7czfSwPdxSU4+lx9+j dReuYa5krzev8q+Sr2tea1jLrGXXmtaZb7Hc4l8nbwisU27KbzHcxW0L3JG/Q9tauIfdab7Xea+0 0/+g/P3Uffnva3u4Z/hnzM/498hPB54JPpU/wB7gjphG/Ae1N7S/cX8zfxX8m9KxKn+VtqqwlTe0 yteHVoe/lTVcxV7FreLp+fyC8NzU/Lxhqbwkf7FGd7Fd3DIzbWCBCSm5gCffEEiHC2zZzNfBukEg Tm2TNT5gMDtqIyuLHGuGZq6cFCkcSargFORr+HMWtSjrjXwgwPG8KYC0XijEAQbKwOl3yc5UPi2n RAu6SzKUkJPlQqtcHpnoPyCbTcrIxGrdpXGsYjGbozI6W/YHAiHeZCJhEDmAdgTyQY6L4jiZli8w LIuPBLQC2iw4xWQqhVwsQJlNJo5j+akPM08U0Jzt10sFLMbaSKUnslpRKwwVdhTozsKKQl+hn2yc LJwucIVPuN/zl5jlQ37zC5QC/PDvulm3dFmOW2jLU21TR6hrD0QwjCSDYc4+4ZQkjJ8hJmJm/OOz VmE9tjaJeka1dF6DqzewOs38z+iS80tWsLVz6I8V2peScFztg7gPO4qIAbFGdKVSHmslhAtFQ0VY Es2Vmie5FCcR3EgRIpsvhpcIJpKTOSWsLqEziZ0WEtc+txPW1GWsxG4oXRhyZaq3p6pvV4/Fqzdk La5ZU+HnUqm1EZp/m1KQDe30+ZxpSoi3FrPQAKnGoCcxzbhATRRjm798kb7iqx8aVn7Xm1BVVYvG vjvOUsODy5sSTqvIMWhXunnjeJj67DuaFzn3KpbuyGQ0Pk2k+78dNAIoEjm5p1LStculy31dmqHR e4t3fWJ98k7v1iTjM/oYCmhu1p1StC7NaDSiJ025KQIkjLOpZDyl5jRtNtS1i5FXuizUk+rSbmRu ZG9M3djQrw3BIWYzuzk11DCk7Wp4DD5G7dZeDf5b8KSmbGGG2eEUDVlKhjW1HE4ochikcjKoKeiQ FJRD8YTk9SJjw4XGkeU4TJPRZAptpaSEN59iNS7FJhOSMSxA/H+cQ1ihez0jE38nKQrPZDQQN3Q7 0cdRneMposzRviNEnz+nJPEoiNaSktSSerIr2Z8cSu5IsskR6sEDeUyVPrx00I8kfbtfOpfEwLR4 ljPxd9hQM+ZQXSND5KvU6TBzHtXV2vVFEm2JtmRtkQSJBmMzDA7CDPFOjBMndRuiOJjCFIcLCYf7 LGW2VqF+f/K8pTwJTcZLUgiVIWr8x6hv4p/QIFIYx+F7fv+Vl7RXjwYSlzSOj2I7oXrXhfkOV4Ka Gcp3ToMyNLUHW1oQzeUWf2N8vPrcpNEAL6Bar2yKmVS1sTF+eXU+fPTyXKDRh6lsT/Vaqg/5JCy4 VZd0vJiZpw3GBE0JLJNAVMd7vX4aCw69RNfkB401QGxKCcf1+ukh2jBE76Cp3TSkh43MPgi7qD6K onwcssMLByLvLiNholpIFqf70MNfNOuqmVhSLBwn1lId441HhCzDjlB91blwpPobGK1ey8LOv+HV qPOr11A06edmPa7zu3mqj4eopwybgEAwGhIULVaQ8Y+6CyG1jzHWOosrPYQ6a1SM/cYho2HIuMNI 7TZC47CGTEcKoH6+BAsgAroJ+JrgWWvdJG9rwD3tPa+rtZ4O9DojZN14ZD7q51zUz98Yr/ui2slc CeDEn6uzDWL1IfzO3aOAwkuagZ0GLUYKXm2YMxdZl39try3bQzdC9zCIX35oiFVnd+MIxryJMXor vRc0gWn0vDquUqmQfGFFx3ziltmcypnNOK6B96rA0oyj4GZRpC5t9uBT0PZviIHWjFnJjRmomZzb XGZJzWZJEFDh0SW5ZhAypBu1okXn0U0tejCISwc6ZBmZ+KUewidZLIaNEpTIXomcIQlqiG1vNIA8 8pGQBO8VyyT3fCw/jifzl5ljMI82iCMzOvphJvOq8MtjOIko66vNgW3NlLioBYpKuDxU2cMfNtFi RtwANjTfDu4031ligqKnTagMVQx8YIFxATNLmRVd0KZXtgY5k41VQHQenG+aZ55Xmj9lRtu8aUvM V5u38JtNm832bs8mDxWurKhQfVwzKLbn0tnii0jpWoBlYvQwX7akzGULiaC1lQSk0Sis1vostEKq tRaDpV3CIfm0udwprZBWS3Re2ihR0neR0MJPrLXr7RR67H68hDNbQuM2Qs/WHQZzbjQLs30qaLZa LMUiGviv0Awwlza/iN+jCVT8i7YyUMPqkLpDNejqaZUaUqEq4JPUF6kZiKzdiF7DZfcIvFoPyfly gdVtZYXtYodYWmDhaRbiBRkzps/4Vs1hHRgczGC8dQYZtZhckVdSV7nC573tGH99qlcYG6iMDSKP NuMo1zgvX5Nk+2kLRHKstsiivr5iTmlqIGZ0TmltaaUYnjNxFBOJKlGKKZnLCnAEnQEgOu1hawBG Y1ON5QBo5YoKLBXNYkAIQFsUFW1MewCQmBF2YutWckMNND0IkbxEzivyXHv2V0SsjHszYBDJzoMF 9KSIIk/uF0h12FaeoqBnr8lNBS9UMJvLkmIue9E3gKndby6b0FROSeHahGoTqnlU82ezJJOfpeg5 1ck1f1NaWqbUwjyM23v+egCvx03QYBgf5q4FjfACAYLKpub8S7xl2opbQum3/7hkUUVNUPmEmt+3 6+aLpgZEk9cuWNzt/SsLbfCBxs6Zi1sXbL7B4bvt2hmFmesWx7eujEYb23JNxeziHenwhZkt1Tc3 TXWx1vbW+2feC3vbfY195bkrEOdPfDlxij5qvBt4QBy+W+P850NGzMEC5mWjywIkkuqSLNjdwoxu wWSGd5EG5nMLPt+Kz7dYJC8wULwTuwAOl86j01xuIKu8ObKUYklso/JhphbcIHz6YWZUeB0xLfIG 6lYvUuiARrdA1+Fr8LUhozGhAoxqZS6VKEy9uDtfHMTbqPGnI3iXxZJQHUQgIMYfxa1j9d87VlvG IevrhQR8nDnMHGI/DSNtM8Pa26IkbqLXGm6nhw1P0s9y7BwWtnGupPUCZ8g1U/JagEH2ACECz/ak EMaSvA/J9L1G2viZxYPEd9xiEaxd1n7rDqthCBX7rDSw4hC5hpqj1uNW1oq4/0h7ydqn/mR+HZGL 0Q4CjlwK472DtajPYMXhLZN3DRDWSPkU2swmFDqkQL9JCgCfZLYEOLQVNkQU6DPLARBkZKW+8Kju W956KyJ4gmoaXLoUnlsPiWirln5Iqs0Oh+dc6JGBU7c89C/vPnrns11PLLYrUqDBBp3Z5hvKy3/4 wytLpRT1+dG//OLMfUNtbfShH8z1C7H+8dT4r5uaf/byvh/JLqQjZyMa6kDaIwL/up8zwEn9Qfm/ BoclOoDxqHae7Yv0RygcPiYQpkgQSfyDTuSpo8Zbh7FGCRZoJOKR+M70Vl4dI4RyDOPwnxcJGvfG hmwRxPDsea1LjFTA2W1YZFzEdLM9ck+Avdq41jgEhiIH5deU48pJ8DsjPwXOgYulSwMrYn1SX2Ct NBjYJt7t3OHYIT0JH6f2xg7AV+Ab7Bu+P3CnAp8qZ6DEUB3iEvHO8J3KUOx0jHUo8KWJk0BB3zAS GCAIsADWEF30RYYiFIgIEYUAW/ojO85DB5yOWCMrgx/Zof0Nj8qzQZxidZVxpbeKZfSQ5sg7YQvs tGy3UJa8QHAkfaAf7AD7wCg4CXi8gwLP3Ojf5Ke6/HCXH/pHoEUXTzMQMAJTe5mOkZkRnXGU+l4t pIgR3r2DA+MDvacGCFllMpWxsQEiuk+JdRYzLQpeEbwxSN8bhPiNCog3WltbYStZsoahcMSrOQgE Cfvhpw87y0ZBwCHwUSQrkWQcfV4o19OciMQGII47UKUiaG6aXIRYfyUIEWRIttEd6olNP/gEwoPD /6fQODXkMMdi06+cdvEjW7950ZQivOzQTyHz0Qlo274wkU+414ZDHd985PEvZ+TWo6efOXHKYEQS Kgyy1Pw6bSXyBNGUZiRCVFyNwAixASXoIQLLY1ZICAjTk0JCQAo5G+39Qq/FdyR8hRJ4AQPgsKLG MNKwiEWX4NR5G3Wp0wVUNHGNjTSxOLDkyqMvrFsYHyL7YpQQJ4a81cf2EhFdBRQzTeNLA/1BqAf7 glQwbEa3MXuIDPMYsMBCPXThWjHY7aik8BFFyefS5BzycMylDJPPEal2LFMTbhhol8Hi4sPe3mOV MRxT+RBLz6MgPzF6YM6cYh6zyIWZXLEv/x3Dd4zbDEP5vfnRPKvnh/IUyHsa3JlLjZdy3Zn7WXYu C5X8FNMc02LTg4anGnbn2dH86QylKECJvICo3Yy04Kx2pVO5XFlpul65WdkFdinPsEfZ1xvMCc6Z tFwghpwz3cGk54JAKDgzjC4zGxrdZNTCjbCxMUybw8AcsSjYwBDdfZ4hz14PHfbs8FCez9JdDA7z pHJFXB+ZU2Jm5GZsrMfTFo6ND+K3KOEPRkENokdG4lEg8hEI58SkP5ExcEk1waUVkDGgIsWqCmww Nirg7NI80NuKKRwnC3FyB+lnpJ3rC6KQIi6dk4w1dew1xkoOHNKu0zD1xoyhjvtPfvHT9Z1IQvoz VujI2iMeOWuuns4x7Vfke2Yt33f98qtnT/vytdfgnIVP/5AIyi8/fGROwBEbeBOemNlf7lz1s7f+ HVE0Xje+iN4HXCBIb6hTdIrzIH1nsSMSBDZS1fHNbk0HEKdoKQAE/Mq9iVEiK3FDd2BECwBmWXWw GBdP4VTeQXw1S6QrOo81jEz8ilyBGm8dwdxgKJjNRDBgC5qga3HwspeQNVLH+WOj55Rx0D0EdiNx RE+i3Egnar9Yw/PHMQkLrMLuY2nA9rH4hQwG9h7Do4b9Bhr/FIseDXNiApOzyxUOoefETfS0iOzx 06IK+bBol80WDn1dhWeOHcdavPfV3t5MU22dLiJ7EjoUV0i9vj7Q5/oVbfQpAWSmBcoePVAO416Z ZnQUuTBWEWFCYqki2b2oIVeUGR/f47zcs8K7TFruZyHNMyzPWYzuecxW6i5m2LJN2BJ8jHpWOuT8 JfWe/X3hDPWftFPsY/u4fvR0W/lX2J/ZT7NI07HWzRTNYz5hEJ90tPCzqTl8Z7ib6ua/SQ1SW51b fTudj/OPm0a4Q/w+0xvU76mTljMmF3ecRQ7vcZYawDUeO5xw3ccy7AaDC2geN+6qUyyLK9wb3bvc H7kNbrf8rwZowOAcV9mATVQnrk7oc8UyHuPLZIhnhH2H86Tkst0DV3s2erZ7aM8Zl2sIgzV3cJTG bec+4miB0zn0JNw+7iTHcM/Y3AawFdMV3aiLmg2v2KKBTbApNvq0DdpwT3g0lrYZoRl1ywW5AAvH B7DZMoDfNTKG7HyybHgQk1Rm0IGmCNnaq93I1sbOLM5yDQwSRxu0tmI0/Yyegwz+r34DS4lzQFKn gySawaJfM8fKFj1btqIvfs3g/hQOZeAKy4j9cm1Lrh2rb5lqW6baFk+2dBtfdgu+sk9xlK0KgTGR 1zCfZ6IvXepkvPUVSzUNJmINpkYStdzV+/DKK4eXbcmG3W89+MRnfzn80Ovjw3CPUfBd0bJoEzX1 nTVrrljn2vpbCN/7DLJvP9PWE2/Vb0X2UCcA9M3Gu0CG4urcrWaJvsrqWO1kiV8tZ6BgYyBnS0OO oF5ENNaf6iJmUJtIWL8Gf2FeqKGxdRMXV0NeAOxp+wiU94sMXr84NiqMVo6NCWM1pTSKzelXhdfx 36sEPVtn5KPATq4B6FI9mGbi6E5cGhJGhAzmQEjsatKNE7qZcCPZj7bfJ/a1zZZtnFRBH+IC/fyx YzWklKxPv1PZ6d6ZoGfSMy1zfVvoLRbjQwaYz26M4H8hs4vbxT8sPOzYl+UFBsmpFQ0rMlSAsx0M cfdE4cEQO0JzejgW2hV6OUSFHHHVCzNdyPnVGtKig+FYk4AIfARecmA7cnhHqM/3w4bMCBR0ayoN RbtDuMduh3FMrAf6+oqkbmur1ZVKrY4XSK17ApHiDhvEJL7C1m8btR23MTZf4ws0Q7P1pGyNKBeO 4XgJNqrbUfVx76lBEtFrbx8fbK+MI882X0cTiWrS5Umo7oTqSQVA0hUPwH/AESAj6bxgG07FxErN yAWcXBOO9BAxmJDn5252wycD6vRF4x+mUxf69u/vOTRwTU9bMeRt7giHEzk98Ed6wfiTQ9HGeDw1 85vUsrntW39808xsa6gUucHpLFz9qwvn4rd0TKvOpj9ANvlUMA8spR/QbxM9XQ8kdrbQICssp9Y2 rF1EgQYmx1xyp2KoTOlcvnrKTYn+5fjNGpu8m6XtpW3TN83aPv/2zvu890k7O0cMR40HvQelN4tv zh9dfnz5yeWnl8t+xd0slFwt4eXGp7iOlooMPHRLpEMGvhnn/r8j73S6eG5IhaKK40Mi0kMqng6X pYJr3SyaK7vUverLKq2OwIcP9WSGkLOFTtWt+FxxV2Rv5OUIHalfQ2p0SQSdq0s7OmAHfmtZh452 dTRi1unockHXCOR052oObuRQw4FTgCVmJ1mZXtAtvg5T3ge7fEM+yvcj6l3AIOZaCNrRIRPD+i6G Fzc22hf+mNaQvguhsgwW0poeFjS4Wtuu7dJoTcL6VbNgltBK5Rw91A278bNZEbeixlsHBRdp/IbE YrprYFHESN1qOAUJkMrj9Re3p2Bnqj81mjqeMqRs+MzUZCwaNf6ki1hgpG5SlmvL9eW70Zgbl+NL A2ZLcblt+/2z4WwSxZldUDzQ7un3/BwJ+5GJ/9AdJLNswYaBh/TRM0L9SHfurMBKQaO7aKqLhhgc SeGw6gFfsEhqdFca/zw2k3HjCH5G+pply1+A65BfZ3p+K8671GD6g2OD46Qxlhk8JWQGCNR1IDOI pX9mQDhFFvKMCWN1pTD+MVYRFQG/XgOvoRsU8PnoZKQlDv488lGEQnpi8MwYXsSL96gfqWjP4GTk vB44J8HayZjRzfOXtM2KlwJBrwSNCbWp0FwoFmjmgkRnIqc2JBar3QEYmBoKgPmlhQq4EFYUMM1Y CYCu7P9j7FvA46iuNOtW9bP6UVX9rKp+Vau7urrUL0ndrVbLgi7hty1hAZZtmQgLcB48MpbN8sax kplgmMlgJeQxQDbyZjaBTb4EYYyxYQiC0bDkSwyeHcKEfEuGzXoJDHbiYQmbDHZ777lVLcvMzPdF dtW9favqdlXXuef853HPHY1TVxY2K2iVuCaOxrWtcbRla2Iwhk+PraBGejcoaOOGer9Br4T8Ppfa huLo8soVceoq/QqFWh1dGTdzsXQiJqzdxRn8u0mSFhj8EJmGdhPRZrBlHtNonQ+ArenMEwErbqIT D0GmE4Ge7shkLB3KYeYtgn9LGY3MuUcNchVaSh5CErs4ln/Cn+ubtx8/+KdTLxb8jMPOcIXbBxa/ s2ptMZXuiU+/csnkrhu/+dELX9zoEerOHbVCE4U37FxVGxu5bnW1/ftKz+DO5w5/v1p7+H+hy/UH J+5bNOwOd1Rm7Y510zNHQrlmSFCcNsbu9k1fufv6r2zt6xdF9TL39aneVOYaev9td31r62V77prb ftnZz1e3qT3ZS/etq0UiNiz0KR9mTv8Xa3P99AFLNiYGDBi4PCuwRBCyYhY+iyQ4QgQrD4wJEexx RMMT/UCkYg6kZQoaculaXSuhtM3rpcfTpI90SYQ+SuDmgVZc+ZCYrEqdMYYrpwyOCGXSXwlhLWyY xaI2gDcVb3m8aVQNXNl1Yseq91OakCjawIpVqYAuSGY/YaK09EECWvnFl/r4xYLZchwriIvLdMNt tQAMyTrZ42/UarhT6FLQWCJ+WSJyWSKWWcvSRZos25c40EBp0pwmzWnSnMZPc4ZwG1x5/zAcwJWz T8OxUmmgYUltIrSt+nEAXfgpTOsY8S6AlbwyYHTX2YEpjJs5lcvNDMwO2OYHFgZODDAFBxobmBqY hiZjACkuUU8KRxnOELpKelLb0MXqSX5DJq0nc0cZv1HO1LXycC1ZX4UUrZ8iT4lhlSDwrCRm3bMs mmcRx06zc+yrrI0FJqWWqHS2nCqNlaZK0yXbTGm2RM+XEEwKXiidKNlKU43v7iNpBMzpW4BAl0/j Ot0aEppNK1enJZxDctzucqixXNwuxZHTJTsTIJ4tSxkxDMPsTrBjCP3mrD5rHo0pq0nknhnJRFRD 3GrN17U0RjS66wvDl0/Hgn62x2hfGjb6WCa1qqf3xg3h5pr24CWZkMil5HDFjwL2B85dd9fqLZ8w vtf+m62KGId4Vf5ytOrr11Rqm9rxa8qpbDbIDmxhLjG1R/DMDOGdE48XD9VFW56ZY1QWC4IEmVzp I+TuSxNLRpoEnqaDIuPGEoTwcjdMeyAuTNACLafmK0fgbLdP7HB8XPnVYWu4vdUZbq8/RUabAuaQ 6Kb0rvQ+LIa7duExDCmUCZIlWjt04OhyBDEafB0z9eOT/JuTloXE9MQcx0MC88wCJORcGgk+hYyB NNlDP4c3brQqw8NmxZAaDce4Aaaugw4avpSilHSXMwiP96ERhyvd7mzGR8aDjway95HxAE9mjgcR Bj4ZP7jlaXMIZTPLxoCpY+J7f/N467jprLCGgjSbRVPZ6exs9mD2TNauZMeytAG7LAjMvr4aKQcG zbLUY5YZlZRGWZJreIAEN3T59GQADwtNGlaS6VVeyRucxY/SpKgurzMYYGfdyN0kLs6VxNNpcK06 c5PX65N8WdEoNEXiN+ofrM2KaExEU+K0OCseFM+IdvFQ5tBfm+mmIQUyjAEsek+bMBVLXpiRvpS4 1hRRmNRNs/Dy1E5LdN3fv5TMFtO13r1iRXf30IrPSb3D7ZUryzG3MynH834Usj8AB4a6u1e00+eU LU1MyPLQOLr2a0VF4rLTFH3++vYadMB+AFOtjhYtPu/JB4kSFEzB+/vgMDBoUrHI860Oef7cCJr0 adI2C80+rL23ySW4copcgiv/k1ySgkvccEmKcuga0Ks3b4AxL69HYq/wVOX0cbDa8a8ft8iyUOgQ ZuElrLsc+aaMHBIqwC/datR9hUOY/RmFscJs4TH/Y4mDBYeCP8wUGB63nCgwsiuvKcNaMr9Kgkdy jAdld7cUU3SvM3IU+Q0fT1FeJ/5mbo4krfq0MdRtvmZjbZ0pF6JRGb9fk2qJ6Q+eFO+zqdSsgjgF QQbdMwqjKMQ6ePT877DGCLbBQ92Fv0/DOycTICwPghlwBg7j0Q/w2+dJ1H2rZY6zecfx2GFCb6f3 TECiCSsLaKBgJTUmTJKPJ/1cQo1zqThK+mOAclBHf8FiAiswHyOYZS6sSPVjdJMvDA0VMHnMvHzw 6m29aTkmXJsWy5EL1HOAHO4uDLWVs5967+RlmUyfz7lV3fpl+kvfKKQJBSFKoCibF/O9BvO8RT8F mYh/iezN0DzBnC9ihul5fUABEdhjbPAOoRGoGAUTJPRr5RSy4AGZrZp2EMBQJvK/HAHiKndwQrmD E8rASaGDMkxmJdO/yjwSUrYcG5XVPPkigOzPYrSQo+qY9gL9BC30N6ic5PWafjLmV0fcXh8hb+ZX T7AOkjy3YIGIc4WFhYULDjFLTr+EuSYEKfX2mEYLwpOOcc1Ukw44eIT/P+j+GjvrmfU+wj0sPBJ4 ODXXfJJlm1JT3sHvEHakbuZ3CbtSj9Du95KnU/SM+/P+l5iXuHfpd7nTwm8DrpbQElupAaXVXMPt YW/lXBW6m1dUJVdpDqAB3hnmx9GV/GbFluG3oq3c2/zvePt6YV3qRfeL7P9m7VF3hE8lUqnV9GWc wyNwQZ/sTXBJf8pxFTNuu8o+wW8WNgcdEpdIJFNX0TaL7Vf6RULTiGdYrY5/o3u8yHs3HhusQ9K8 XvzVFrohRsF0GXyO8BlAM+HjuPKvhI+Xy82BC7iGwBrAM8exAFpy+GFxY4zzHKKFQDDISyk5KZUx VNG6WNqdZAGpaJl+rTJcT/avoiqUB/OdrJIKKYhWUhgb9iA6hBANE4NTQWTTaI7leZFtUFT0KDpl jIjen3o8rANTviSJrKfHO+Olz3jRCe9bXnrauwA+nWh0TkSinGqiJoY2VLZSocp8eZ5MfrKPldFM ebZMl6cGmkfRHU+mv/snZtDKHogkxejycn4PzBwFC9rk7mWz1SFN7ZAEjwxKESYcfmiIzH3wd+aQ +s2ctU3RkgDLgor2w7FFpxPCifbs2Q0unz1WWBu1mzLnFPJ42ISwvpLKY80LbwkDE16eg2mBC4c8 TQ8UQpMzC7dZQIDDE0LTmglheYfA3y40zPxiWj0ddjicziDRaaqdjEyok0u9r3EBbQEj2fTuBq8r nUMPXPnZ4ffeu66rJytd2l6Zi+Xbv5bKo+3ymkzYw/kVOdwtIN7+wNndr60KeL2hBK0odHnFG+1/ vDtd8bPZLAoHo1X06faJiQERZbOCJ5q+grlsbm1MyACnuQQjLA5zmjD6cgdfRTG8IPgq5HUgp2Wf IzwDEZ6BvACzLV/4PxMNw9uBUF4AWsQVfvT8L58i3nH7c5g5uCAfGRWEbArBJb+4E4BHoW/JfGdi kkWw4C3TGrQgQUkh4iwCtzhFOS3LnWmzI0IEbsoEPV6TeZGKCXq83mjkIuDfIj4j4ClPz0YXomei TJQYy9bUoDQGmytqKHrIt7N/LIqM6Fh0KjodnY0exCc6vXrSuaEL6UmHluk4yvEtOR0shbI+r9WN Ge5SX1Gb9aIxL5ryTntnvQe9Z7x276HIMthiwvfW0AWgglVmYj8jOOVibNKhjLul2tp2q1WW/SlR zgtIsD/w0fCWgQTBIYzxyFoTPRMp4uhhHqe2Mv9gSZHoBNE2J4gNNiqQVyuMj/R0+H0PvFB4fT0k IBDecU+BnFXobazpnLWmcxa0GGk4a83w2mFy3jAhlGFCKMMjIfi2kc51Ix35MtLpAFf+1ZDg3BEW uhkpkMsL5PJCg8RYQUODJEtpQGwUmTvQiEPHDaIEw6kNmhwnORsaAulDIH0IENBi9qH0WP7PF80+ lG7iGz16/heGB05VaOv4WUyj4C+NSJW+1esAUClrN48bcE5lHG0a3zW+b5wZ3+JY2yuqRY9zqGg3 IzsqINEmJzGwOrcAfx2BtoS4LqpapA72lEW+QMqXiJawZLQ2hnD3uHeP0+7cPL7FKfauFQjFCwpx oCoFogQXSFuhMUw+DZNPwyP4Of75adOluq0BZgRobpj2BFJ5nxxtNLaNgIyHxpHOCMKV35OjIyMT 26yBIyzteXznZMOPQJFnPt5qAVPG1Dvv27h52/PUmvPvUKvxVsFbz/l3npJFScTKu/k3ETPiNeeJ id9GmBlM4hOgbRd8aHYCK9WKnhSP0mcPdzX0ZC+uGJ6uET25dkOXoCejWK8+nCnoyZ6jjO9wZlhP rsEV49LMuDY6vDk5vsqlN0aNpp53UU517Zat8GLUopf1OB02u3Ptmt4eMcpOYPTJC9l0j4KmlXlY JADVDa6hlwvZgZ4Gmm7MN+gGtEVGtw5nR0ZSo2Oj9Mzo7ChNjfKj9Cge10dCkdro1LaJo/R2LLP2 iUfRTpKR80JMywegl580i6FO2CX8tcj/USLAOnGx1JLG3tHZu7JezqdmcllvOo78XJdfXa6zY5Ud FlKC4JaGqbL/O4q7JUuIVd3pjF7gI0vNzmUa/UUItorGdgZKn6luuSf86Qc2rt+djvjY/kvaQ8EV 6Shri2lb6jeN0HR4cE27d6TpsaeLm/rrV5Wk3o3tFa0+meBcjUOhAn1qJ5fr3rnjjo0bxwfvad+2 RYlgBT/KZ4Qx9OfTZaO+zlNobyRaP5ZKV+K2XiNRbLTD2/tj2WxsxTi65hvFDh72UhTz/zAnq9JL nKxOOFkPwcO95oRpFxfJAEsow6dMIqu7CEuysrMQfuCKEPOaNffI+/EgaDOEMwIW6BycHqES5OIE 6ShBukjoxLqmE+CsdwCybkI0UvnQmpeDeRsLV+hUnM72ACNx9xLNrLfPB0k6IfVQl2lvM9xZLtvn lItmlFilYuYXIrFizYuh8TL+wQMD4U0j2wW2cU0lQqzzxP7dS+rkBnrN/rmsi0hPF+EULsI1XBES fhEhTREXNEUi9RqVIGcmSEOCHEyQByURGh12oQMzgTN0vV77Y41tGJsO1o3uuqsO47+nPlafqk/X Z+v2kg0ZpD6DP83XHfP1E3V6vo6mcMNCnUm4InqSMw1vup7Mbuhy6Un/hkxCT2ZMw1uv1j3ck+xd FacyfVXyxNlMhuP8bDSSdc660LwLca5p15zrVZfNBYa3mF5NZLtT+pg+BZnXZvRZfV5nKJ3XaZIa w40HvD5VM41vhT/e+BYQJcZhUyUmGkd2h2iXO8OYTGAic5jQHmJ7+w8tb3hELm+8AAKqaON/+crG m5WI39N7WXtF0KiytuHR22/z+GEghtb0cqnOODz94sYtQ/e079yakojNjduEbt+7+wvtxGQkgUfa 2p1o83fWycRygZn2SeYYHmcclaC91kiLYxhoBjcSOGfqdDwEQ3tlG4wdOAgVIwiNNnKaLaq6PLxK mZLRDGEzrQ4XgivccBzOk+HiGNCUbAsRigt5eYLgeALfbAQHQNVmS3q9ZpAEEUVAXFgWUR037OrA TBg9GjkS+Tv0Y/di4g23I/BrFq1zr45sDX8Rfcl9P/dGzJky+uo2Ehwxl0IvhX8s00YKrXd17iZg g5dewPh/EyZFGzoB+zHblG3aNmubtzlspyCReMvwzmEVZykuAOKCwTBb2Difv2rj/NgV25/wJtc/ kbKtv3L7tucgEpqy4S11fgFE4Mptf0PJTB9lo0JM37v8u7FlH7F0mLiQgaMfJQKqP0er8RyrOnIC F1KoBJIVFHHjmujEtaCPV1CMwbuwJ6pQkh3vLJ2580cigTGtYapDK7cZwq30rY672Lv8dwXuiNwq 3hp3TU5YS3i447zQjOEtDI4aj+moAZOZuYyHlWK/Pwre2lDAcrjQ1InP3XTbq/tevevTe396Vf2m y+a+cO3nbljLPP6t/Y/ffXbmO3/xg8/94fbh1rfuebn9y4N/+8GXpiD29g/tDcwzmNY0qkl3WbSm ryDx9n1sNxTgDgCPSFCiFEYPEh4cVEi4vQK+jQ5eI3xXWYrCVZh8IWDzO+RnzETIhgfDj7Lq759w OIl9zE0RLkwhTJ2Yw2Lkdpow3IvCchf4lzBjrVwU3XaM6jt/9ikgxD4WaJKEqLHsikF8d4Rug4RH BhVTBhDr1W+MGAFrCj4r7/BrFJL8+GY8cDdwAyRGlzc5I1qK/jlhhf8UgKo/x64Aam3y6/mr+fsF 271FtKLYWrGxeHXxRuHG4i2uO4U7i3/m+o7zXdcf3L6eFduqE7WbazZjBaq4mLweCGJYJd3bFcTg SstQWnqTlqRW0YFCnrGV+X4Ed0I74Z4k0d/Xm2JnWXqKnWEfZxn2PYUmJryYooxB2OpMGkG4pxni aU9PDUJAL1FmIBmoFcsL7BAssNElCyzj5wH/mEl2K3Wnz6XWct5cj1p39imo4sO7qrtfQb2esvKx JLvEj4hJkFGr4aUFkQgdah0AU40s80nYTYYJk3osoEMjObf2wKY//8Tu+6a/t6E/3xdtbmwrUkML hvlMUlRRze3/7FU7L73iE8a2nkqWae55/c5rb/6z104/si/MldrvXlNNqiqKeHp3MtdN9Ij+fe3v 7coMbrv8U8f+x+7LxQD4KVa1N9goTMsJqoBes2hZzhFWmQtHSJ4HrEonLV3aDzoJicy0srsQHOIH IzDBMZB9iAS/2J8xVWeDdyYcXDKQUUWHPhHwOP0m3WCSaS1XnhcIxZpEsxDrBhYa6wY6jHUDDcqc nNzCM6hEILciamMl2ijNlP5r/mDJ1iP3pFvdA4VNvCEb6U3d6wrbuDF5IjmW3t69o7CLv06+Lr2r +x5+t7wvuTu9r/BF+S8L3+S+Ln8z+fX0X3V/q/BY5Lvy9+M/KByL/AjfwS8KpwofFbqV0i3qLfkD wW8EvxFaKDmvCqIulx9r0JqlQcdELpliMrKO4LEyakJ0Oh3+WIxKpfxAdhUqhWYRPYVm0OOIQS6i 77+X6+XDY2H6+fCr4d+GmTCJBAivLHZiJyGnwLnC5B4ztWmFKNinW+eAHgOdLMNiNh+MZqM5hcoH 8U6NZBSkhSCEsmP7hVjg3XsGChAOXLigilv5aq3oSYrg7wYjdJazAHswc5NY3dDuCw4kQuLV963/ 4t+j0N82p3KD9T/VdramD/71LSs+wTz+0ae29cVVlfc0MfS9edP7P3kXqYoSz56roB9ief2jF44t VCnTY0w/jSkrj57qxEp2Ex7pSEUFjYBTTUwhS5VfrvmmOrg21UGkKeBGJEIiRRTzFIGwKaLxkhMR z4gRCYy5IpXDZOffpO3S9mmMlneKXgYzq+Og4Z7G+u2/QaXg5eIvdvdmoLscvnaXe5+bduMORAe+ U8IoBaLBwj3+K2GUKbAIAL1ChcRbpVLd+jILJ79I4q0mlzBkzNiF1Teuj+7jDNrgvmBzGt1oRzdK AZcj+uK9GU1ThnNJbRXFerqFkMIjmwhL/DV5L/JOMAzlxBrhDgcyHMhRTnWjbkrIplIpBc0oswpN KTzWEBeUE4pdmdK/uzQDyNTx9pzcvcdKsbTn9KRgzXGklrmc9mB8hwVnuL8TF97RuqJLjtSLDH4j t9zZWFfLZraGA+FST9B32aXtwpouibX7MnJKY1GYefyVV1YWtf7VIf2a9voRDYO3bIToU9cfvCQO AA7Ty87zJ+mfYXrptdUsetGqhF6qBqAzGhFfKSK+UsTFZJfmhXYtzXXYDweCtA+Oc71Ol8albYGC Hd1pRzfbkV2tIIS6ndLtSXR9EiVVRUZT8rRMywEP1VqcnMQYqIJLXExCaDaQCMZ9x187zr9mStIl 6uhLc5rL1h1JBsp2urvXaXYjBTba0U32u+20Xe12rkqincn/lKSTasCD4A7fN2SgFo6r9skuP9Fi tAAUmlbtsyTmolkuQtzsJGz84uJki18ks66smTC6uygV6UCgbHiaxbynKYYmvNtzj/BfzdpZJ5tn 9anqdHWm6uCqR5Fi7Mfs8ie+n/gXs4vqP2Zez75RfNv2dubt7LtFT6BVnCz+SWlv8QA6QB9gZsKw +tNM/P7SgbIP8sywjNvriLPFl7t+nHHFmUgoEI8kJD1WfMj9EPuI8mDmwawnUPDlixuKm6o7qnfo dxTv9T+Webz6DvN23Ku7epPUc3QSpVCFLD5QOEQ9Vz6KZEPoFpPSc7GknJIRLyv4l4OD0nMRONgV CGQzPo+N00hhT6L/TpUr3b0UBT+q/DlJEmECRyhSgR+W/mkAoQCEIv0WIs2YkOGZhrX2prlZjuGO on5D0mSpnHIhV3FOQ1Nk8i8DM4Fp7RmkUH1IeWJjZ3BANheiHJ2DKNjzaTQ50axgXHnoPMJVsgjv B2TJIVCbTi5L84JRKYv1tKzPE/L5PJ2kLxNm1pfJPRflfcFVa25wWXH7alTBXEAtntdTCi84nCkh HUcO3RWnYFkHypm3x1GHsYPuBTlEPnJ+yH8ofJS3TU6gPSS1yzZDmkNz9Bwz53nYNxuelWdjs/GH ur6RmSt5MTwuQCwTxGgZnkqmkv2L4iPZR4r2yQkAzUJekZruvNREBtuk8RYzA3Jl4sdnm2XcVCSb u+nlk4GWX4EdJFWKNUkhNbNmWHPGLLyQrjDYLFq5IA4FzL64AP6KAP6KQLOoBOCaMwbH4dO4JsP7 8Pf4oIMzRsCHv8eHz8GbKJDt41P0Lv5D5pw9SGWztDBTdGlRLcijL1Q7k6ay2vI0NvRsOnf7J9Zs UVI7vvKT527dfHM6HPWl0/FvXbd667XtX5ZKj9zdP1oV+ICXebz98oM3bigN5PXy2uu/vfehJCuj tV964Irm6mtmB5tbd/9VlPOLmIeFzv8LPWR7gYqhc50I4oQRwDwsQVzoHi8xwHjDQWQPkmqQCLJg J1oq2PGrB+G3MNOWeFxFLhKyQegwhRxYkp07cbxyetGSYW92ZuFd4E9S1IwfJPvwsnoMvJ4ETnUq EuA54p6Y9iAPF0PhG0JofQiRrzMwKeLv9sSQnSgHdmJMsRMpaA+a5iMHuVMi/4IdD18wmIgvM6aQ eQCtcycmJxf44/ziZCemAb/W2DHKh29g2NvcgXbQdCvxkPCQ9Hz4+chR6R3JOZdA98tok3eTb4d3 h+93ot0hhkVNZCJhUZIZBLtQ7CBiwj3W3TI9NI0c3jrcdOTV8D8RjPXJUOynlAf8fkUFC89yJTGf oBMUQjabPRsaC6KZIIKUefPBheCJ4FtBR3Aq/v37O6rBOXOK7CRZ3hbWO6Fa506anjx86CQSYM0p QGdmvnmyKh+JSaqGMwLBVI0qQVw5iB3uJ+uabHj99Wo+famgZWZWlbd1f7lxSymq215o/8Oacz+c uFTPX3d9dcf19GfSkRvW5T4JkpE+f5I5x3yVUukei6oiGrEhuixY7lHylkfAwkNK0tIwT5oxGYpM TpQDxPsQ6JBboKOL4soHJGwokO2onn5RdXgUv+hIFP0eJ0TmPwWqp4ulKm8WIHrchPCnOqEZZi7x NwvLcdRWpzllgXGxHsUj+rNqFPdqdumxMDFr+sCIV0yRiUdMJhBLZoldJeBy5RRCeYrD9ArkAuDF g1MCnSghqBDaCwS03HK7P97xxN4IuwUSYIGJkAAxjAfJfJQ60kCrUDSQD/OareZppAaVdal1il12 BTeB5pnelFS1jEtDw86ka5XiUROuo2i1EWQpVcUiCZ7Hz3pYjydNpkv5qXmEODSN5tCryIZIiFxA krOBwFhwNkjP4N18kDHzNJpkh4ku9+K+i3EaLKR8DvKidJYaIalo4c6XkBqEgMTinBDn5DjFCzE+ EaeIoY6srDlZ6DjizHlRHTrEuM1ZT1vUKYB/l7meS0dSmr/9m9Jt96we3V2MN9ah4YlW4bMbm9uZ r5772RyZDfXizGUTX5pBDw33xZB67pGZsf4R2nl5g1bBY4dp9DSmUYV+oZNTyE3JAQdZ00nAm4I3 mvnVExQEUZw+dapVwRKhcsGm1iuy7pjL7e5K4+s8IWL8DQUdAtH/hICDJi14fCukokA/xwsX/puh xpU3j/NkVp3hDlzFbhOvlhiJJMitd4EUujZcD0khOePuYtOCEsiKiqTIg+4mOxiA5NaD8gbXevcq drW4Wlov3+D6push93+WH47Ndf036jHXd9zflr4tPxb7kesp9xH2iPi09Iz8bGyh62fih+yH4kdy ac6NukiM2VSNlIVes0zqZrl2rVlqmllmMmYpCKQ0DCle47ruoWCd2mn7Pcrn7V8UDnS5B101tiY2 Yy85FtI/l533sfeL+yWmEVgn0kExlAxSMSVJBVghiUfBvUbRLUuKKEk9bjbkdrMxWc66Xbjmcjrs NpsLQ7JgAMMmyiFLHvEowuJpB4t4NsvOsUfY11g7u9cdAyLmDUfloOuY6xU8eve6pVtlSIygUG58 v1yg5raC0EkMQV8diqe9dcq9gNWlo+j5I3wXmukyfw18FpRHuGAtDYxV4gsFyOQP/EI+J74NCVjE D+TTUO4RTy+lX+FPA3fdb6VdWcr+8+8k/zHT++zuIAJC+gUE4dtPsUrE18LM652ncenOeiAs7y2M UlgIS2aDTZeCYQrerOgHZM4u6uRSCQaJKYZkV7ESAcGED01Aj8c1Pfyz16MuT1cNFWqhTLz9rN4+ FsmnhD7mq2pOyfS0HbRvIOF3cx5VtQnJNWd/w9j7K7zbBbrx+ZP2w3i0FJnj1mjJpZOCny6Ckc9P uXOiy5ZXUw7OAWTealUq0eby/Fsdo14OS89VJDoyTlQKsheJWcFl7sWc20blSed3FlGRulVFqufW PMp7zN6LxVI6XS5Zdmn4rtZkC0JByZeZ4TjkV409ESBpQOKtekTDCqagakp5R/kG93T5XfXd/O/V 3+e9cMKhYJ2c93IsVUuXy/rO/oQkpWIZvmxjc4lcMdfMjUcfjT4qPppzedRGtqFtokbQqHO9a212 jTaaH9Xvc87wM8Jfqvfl79Nnyg/zX4WT1Wf5Y+qx/PPll9WX82+ob+RPlFOU3eZ0hG1Rt+rU3HmH Xo+u5FcKY/YrnVvEK/X7PQf4+8T7pfsz96n35WbK0f3ue6P7c4zPPYFu528XbHhM4Lepqixy4lHB R4Ukr2TSSYXSi0mKY/1JLiUlk1itv/dJCBw8en6vYYhqVnE5XW5nVs+HdD2PqUHVelzukMvlxuhE CmdZNcSyaiab7RGlkChKei4jYWUdjz8Wv4dn0Sk8iJLo1JMpxAnwiaf8GJtgKcjzWIFXKBoaEVXE p+BBKj6LbqRUyoW+a3B5A99sNpv3KGe5T7JYp3ri8AL1ST0Ds2bCRqwyJqGDEnpOelX6J8z1vpKt 4OEde1rhVMTjl27NFlGfRTyVo8J4hHsNtrIjh4zcDKzugk4ddu/VKq5n8DB3YTjFKlQezeTPwGo/ WPbjS/MHncSgOqajGVjvh9cV3dDn9QX9hO7Up0pLqOk0eJQl+fS5k1jp2W2Nbdwk4wZ8WDwpYygF W2cpOdmMjAKI1UlKYtZPm3oWZAUjXABipVwdduBa3vJHZwWDnGBmQiaSbBFsZJhdAK/IQXp+UExg wlIQ+EQCsvMvFSEozhyKNlUowuTTE+HmkrPC5BwOk3GQ1GAm2+gwEuszyjAmH/GhGSyGF/+uJmqR IXR4XTLkOvFCSGui9Fa9/Yr+f9q/U9u/SAwMYX5iS8ZTxXP/gn6wfyjqZ1SVifKZUPjc++ijfiWY pFXVd8PZ9+j1555m6PVVH2DGGEUxv8YcZoB538KM3hwr1nK2EoW7qmA+c7gU5OkBCHGkSknBZDSV CnCZBbIzfQogSvcHVrPogO+A/4CwP7e/9rrn9egvtF9U3Vw5x6qerHcPe6vn7T5nfLDMbe+3lVv2 Ft8SBnKtfLPWM7jes4nfJKxJrs+N5DfWjMEt0hZ1bPBW5z7PPn6fsC+yL/o15xw/JzwqPptL+u0c zwlcMcWnhFRRZ/VoZZDlB8fd2/vHBjuxiFl833cOoAF4kNsqqFLO1UTWRpXhGZLlRKJZLg82Owyt Umm1yBKRwNEWzD0807dzeGxGIxGtVquzHq+3iuGH0ynlavVata4GDkQqAhLqGJZGvIm90lgSJSvq rsy+DJ05kEEZSS2Xm9XS+7quVcfwr723jup2u1OVnM5sXQ3V66o3omk9VW+oWvXiNy+6vdGqpkqe gUpOZBlvzVnn4iiewm+iUobXgAW4IIBULttKqFRKJhOsF0PMp3ZFUKSsHkX+JxUJScBXvXzdkOal t6Qzkg0aQBpLz9L9VJVyok8fqpc1zA+epKqo+iz9AtWkBunRJ9PH7zfT78Eaq4XJwu7TH3SWcZzs SFuYsM8TvAnL6TaJYmMlsSV5+PxWQj4kBpp7K+Ip/uQk/MYnyQ8daE5WJnELTz7y95zCNaeLH/IP 7ffzQ3sXF6FYdC06ceHCrSSGcZIkO+mELnrwmGIhQvH3T7ubUbAy4Po7sEJCGJRUd1xo+YwYT9Kk PYk/QGkEo/6WHXyaTkjc1w+1QYAiuNTzHPR25gjXVBUOBP7PD3Ew0fgtXPRB3iAfPuAjLWCdyCmw CbhNgOtgTQUACYcCZiGYkCHma/L4BxDwFjUCTZ7nmgLeikYYFmIArhAxiwBZKBRsH2eMYLjZ7wo3 8z2hpo43wRWB2EvcWaSpGwLews0+2PA3R+Hb8RZYFpT5b/8+bhFBFx0gbKhjCCERnB384gwuRWxi XKNdtNxmA3BODD2upzOeyPDGdV051N+b7R3fe3LzumZ7rCQFjXsfXFUqtX+WjeW2L/xwwxWXYMYU j4p9fNdnPnO9HE5gtiR27Xm0ffTOXiabDfmj0cnFxasFUaOzWXsocfv5szc3ICKmvYb5AHOmviXf KUanhW6GukNDWgJrDMTOGwLGJJAqpCU9QpPq/2fva6Cbuq50z736sWzJv/gfbAQYYmxjHNsYcFwC 1CGEGIc4hhhjJBksWQJbNvoBWxJYMg6llCY0pZTxUJLhZShhKCUe1+UxKS8vJUxKgMUKKWESwqQZ yDCUuoQSSiix3nf2vZIVQvq3+t6at5Z91nfOvufus88+e+9z7r1HV7LIyWIiiw+HHibyf5N/Denh qaeWh5YseaXIjs5nWcmJoqdYKGZJWB4meHgf8cnJJYyVloRvej5YfgzPhbQ2SFv0hxIer637GRsd vM0ygtdZJhb6mAT5FbB/iubfCIzL/95kcVRpYWpT2UbVM2oxOlqVpMnQZEbnJ2dOis5JysmclD9D KEuaNvrRJGu0NcaWYclcOdpa0KHpjOnMWJfpGt1R8M2Yb2bsZDujv5+5I/9f2JnSy+oJuCfJzy/I y4sR6E49g9/eFxTLt/eTNPqMzMyivJhkMBTk59ONfX4emuRlRitjNAUoM3CnoZkg3+LTjx/GQdsH pk6YmRVfmpaWmcHvFkY/FyP8e8x1/mFpe8xvYxQx6x+OfiLaGK2IXq/hX4TIyj8Xz7/Q8IJe1D9n LBCmFjxcIBZklJS+zF8box+9cyy8tHzNpc9vLue/EvC5/KrYws8v5cv/lCv0G9iaiCs3/9XExPDP Jv6xi7Owhi8N+V91K0734uqILzPwJ9npgvR7nDrhn1KmTBn376cSozTj84W8ibnp0RlD3yr78ZMP VU0vGjczNyb70Zw5Qz+NH5eRkFaCGH4g64FHhoqFO5Nzk6K1sbhZTx8X9/Bd+zObKwvySlLjZy19 QfznsYUTdAk66b9PKVoQvSnCy7OnJmmU6coXlC/EvhD3svKwMuqFNCE2zR37YNkiVhe/KEUxWpkW NyreoKyJ/3flmfgoOSpzBUVaqiJejFPpHlcJXpWwSGVSiaoinboyXnDFC8b4tngxvkiMYQ9/jkWS suH/dDgTj7bsVkLCnJRsvq2VM7tYpeqPydYq4+LjcxTKZIVCqdCKynhBF5cWy3tRLlIJqqJYnTrB GC/EFwliTPy/iLNYHFOKs2YXKITCFzCswkWxQlHs7Nj2WEVs5tS0h9OeSFOk6Qq105goiBmpaf8g XUKqb65ZePMS/4e0CICbyy8lIOE6wr9Zz7OQjvJ3f/Hs9o31x9Ll/6spF7T0M0c+HtJo3Y8Lnpkd jVVeUYSMXmCJBRE/mx/lpPJ31S8MpM5U5iZz8vxA8kxlexIntw0kzVSmp3DyykAKyHgiX4n/4qJJ /0tJMW6aMI5+ynXC9HEpwjj6H56KBu3d86Jp6J3GilGjlblqBfu8V6i2PZ6WoBUyhv4zR5GXMaF4 wdDEu+9MKNA38/+DNCi8oUwU45iCZUm/1BjDWKYq9DONl6sTbrGpC0M/05jIf6ZReOMxGJe+C6j4 MUsV9KHNjmR6MzyF8tTklNQolUaTrsnCA1tUepr8drgYsTMW+Y74rXvfEU9P+8IX49jUkvzEkoc/ OJUgvSn+z9vSBfo2WkZxcWl7+o/Tr6cr9OmL0sXZyEzp29KV6fI34tLlb8Sly9+Io1YTMzJLh98d XzAh5YHYOcnZKZWxUaksit4ejxVy6LXxDP5tN3ptfJvuuk7k746Lur40+a1x/orRb6TtrIcrkmZ+ 8Rtu/Atu/M1x4Su+1ObNvPfLbIof3+8rbPDSEWGisE84Cy+l/wxe+ikTFPy/Yx5+RSVM5dEqO0jY N5QkDAoTD8ptVKP/dBvV6DsvqBqH2wjsq9pcHu6HDR0R5g230fwZbTTs90c0EW0S/ow2Cey3RxJC bfj3+DYg4say6tmxY7JnZ1VmRzGtkKXgdzazx8YklmoTlfFZD7CclJRx+rH8vULhCY1R06YJapSa qXAVj6jfYEn/4Fg+MxqWpz+88NNM9DQx/IV2+XcQh/9HhvRy34Zqw6tfK64sGp+elTLlQf3XkrXR uhJyWH7Kv3Y+lzJ62viS2OjJBU8WbONfGysnp+HvITntFJIj0hLh+0hBsVr0ij8UP1R0Kn6tPKt6 Xf14VGLUac1j0U/FpMYYQkmbqvtGLP+0c3P8nIS8RDExOGrMqB/xlDwjxZK6MS0xPS797czxo18Y syCrOqt67MyxM/UtSK/pXxuXglQyrmRCUU7NxMCkq7nv5Y0psBayqcuKfMWvlLxQppx+eMZgee1D gYq/m/WH2ZPmdHw9/pHZj357/rXHrv7/kRao/0bpZyNpJI2kkfQXpXf/r6RPRtJI+u+XHtc+PvHx h0fSSBpJI2kkjaSRNJJG0kgaSSNpJP3F6fsjaSSNpJH03yMx/oYd/3caAntK8DM1czAFywk+h3x6 8H3k5ZRXBPtZMktGnsMUOJuDs1nIy4MNyCuClciXBq3I64luQD6ZxePsZJZIeQ7OTkXbfuTTg/y3 7sqppiJYgrwBMkvobAlaZSFPpDwHnNPA/wzycvBMAz/PG4IH2XTwv488HnKmswRwTkcrTmcFe5Hn oN/prJh4KoNrkM+jfD7lVcHDyGuIXkz0EqLriK4nugF5OfVSjl4qkSeg93L0wuksaFuOXrKQV6Kv ckjmeRV0K4dkTi8muo7yBoyigsZYweKHbiNPQNsKlkh0FmRWkLQKSCtBPp/yKvRYAWmcfop4aomn jvKlqH+MPQYNF0PDg8gTgu8iT0SrxWwB6pei3os8EXk90fVENxDdQDRj5eJRxn+zn/+tolxBkZFN R5wWWZyQJNMKRMmHMq2M4FGxdGG8TKvZeKFGpqPY2jCPhhWxgzIdzTYJLpmOFXuFOzwW6W+acrtM Cyxe+QuZFlmUKkumFWymSinTyggeFdOpJsq0miWqvibTUeyhMI+GpSt/LdPR7OuqapmOFRaqvgPJ glKBvnTqi0SrQCeoB4lWU/0Q0VG8PiqGaA3RmURHyzaUaMmGEi3ZUKIlG0q0MoJHsqFESzaUaMmG Ei3ZUKIlG0q0ZENOx0ToryXd8ojWRdTHcTqqnGj+H3XiohYQPQp0UlQd0ckR/ClkB4lOjajPoLaS bqOpL0lmVgTP2Ag6h/g7iM4jehPRU4jezmlNhP6aiL50EfW60FheZnpWDIs8COhZLbMyM8qFrI3Z ARfrZO1U83UcOUDzvBH1NuIoxJk5rAVJz2pQ14z2LuakIzNKM7jXIm8CZy3Ot1KtnlWjXEdcbahr hCQ9zvIzjYCL+mgCDz/nYKtR18Ysf5V+93KW/0k9uObNzI0x8b7L2RIahVOWqMf6WQhbTQeVC+k2 thJn23Cea+jCWj0sX5I+LHsRewotau+jfW2YqiT910GGHVro2ROQaqFe+NkpwFNox6W1oKZTtoWD rMelFqBmCfG7qF7Pqmgc3Jp21Onh6Zm4NhRjVWvDKPWkG5fjJn9x61tlX1hIoou8wo/byRKtOOtC 4l7VsxXU1iX75RGsm1WICKmtI+JMO1mpCb2sJIk2suU66msl8vv3Kx1z3pUYr5tG0US8bcib6Hw7 eaqTtLTT2XayhyRhpSxLGj2PV/2XRt5G1uwkj9rgQT1F3opwX/fTy/4l2X++lYalN4X97KCIcZHm K8Pxe//RS71/Wa+HImzARyKNxUX9hWYGly+NtQk162jkbTTb7j9SydKNX7CqmTzbJufSqCTajaN2 yvWk7dpw5EpyOGcLOP6oj17WFxc9WKSvtZr1C9vsba7OdrP+622O9jZHo8vWZi/Uz2lp0dfYmq0u p77G7DQ71pqbCmttrWanvtq8Tl/T1tpo19uc+ka9y9HYZG5tdKzWt1m+Wl6osvxeGTXmZndLo6N8 idnhBKN+WmHRdH3uQttKR5uzzeKaTPxgJ+5FTy2sDYuv5Vmlo3Gdzd6sf8Jisa0066fon3I12lvM ndDCYXO22Qv0S2wrXW0OfVWjo8lsd+kfnFlSvLTNrW9t7NS7nWa9y4pRWNpwptGpbzc7Wm0ul7lJ v6ITZ8z6RxZXzcFZBx20O9qa3Ctdeptdv85qW2mNaIvSZl/Z4m5CU1ebvsnmbG9BB432JrSygWEl uNB9oV4f6rzN3tKpz7VN1ptbV/BWw7LsIe77qkTsTXzMDrPT5cDoYLaI7tE8LOsh0iDXhl5c5lbu DIcNvTa1rbO3tDVGdgqlGyVVzQ49xtuGrpC7Xe1ul77JvJYbFzxWc0v7PSPCCtxGc7ERUWdH1Lfx mSjEItJW4fi/aBUOnQ+tq03SeqnoVbyi+JnifwH/U3FEcSBCFue2hY9/RbLNX+jL/AVpJE+ZrXxQ +bjyUeXXkM8EdyNmB5930pXAKhwS/gG3cnw1mAN+B2aRnWRI95UsOA689/9TMH4HlciEYJBf2xlb KH5cLDLFdsbmqlRVONZLoR36C+KPPRwcql1YXVNUxNgm6V6R8V+pFE4K70DaAtwwbmWC+G3x75hC 7BV7Qf+9+Pegd4m7QP9A3A36BfE66E/E26A/U0ADRZIC92iKUYp5oB9VPA66SrEBdJeii4kKv+Im 6E8Vd0F/rnTivsWlxP2X0q3sBO1RekB7ld8B/bzyu6C38ztZ5feU3wO9Q1XABNUUVTFTqEpUJaBL VQ+BrlBXMkH9iBp9qavUC0FXq58GXaeuA71UvQx0g9oF2q12g16rXge6Q/0ME9Wb1N8AvVn9TdBb ol5iQtQ/Rv0jU0TtjfoJ6AHNHCZq5mp2MYXmB5pB3E39VnMT9KfRkBy9NHodU0R3aHGXqo3RxjKF Nk6bC3qyFs9i2lLtD0Hv0x4C/Yr2f4N+XXsM9Bvat0Cf1J5iova09gro/9JeQ/1vtDdA/077Kehb 2lugf6/9Pejb2s9A39HCszqmex13bj/XHQf9r7pPQN/Q/Y6Jupux8UyITYhNZ4rYjNgl8KRS9qfI xpGFJdtKVpXtiXHVYES1GthKU6fBiDT1GgPoRs1K5BZNO/K1mk7kHo0PZ7s0AeTdmm7UbNRsBN2j wb2n5huab4LeovkW6G2wFbfSDdkmIqyRD7pAi6dXbZG2iMZ7FfSvtb+msRxD/obuDYzoOMbFR5GC PDU2FWNJi00Dnc7HJY8nhu0QXmWqRkfjCqZf2eloYbOaHebVrNpqXuFghpZGlx0zO4YJi2sq9Xjm ZohzEdbQyhSeb8g2jGYKf8aJjTgW8JwQFz4WMKsgqap2vp6lyhwinhjiZVqBswkscbXZYWdWyu2U uyj38MsO81O+mfJtlO+gfD/lpyn/qHV162p2i/IhngtqyuMoT6U8Wx7//XKR/zJERClgVPwpTYUy CvrGYPQ6jIv/589ElsRGwS4pGFEaS2cZLJONZmNYFp6hxuJKfP9296vD8kKWGi7jIf+rSn5X3ID1 qwUrmo/1sK1sO9vFXmIHWD97lR1jJ9k77AK7xK6xm+yuoBR0QqaQK5QJlUKVUCs0CA5hh7Bb2Csc FAaEo8Jx4bRwDpI1TBC2MP4cKyRWQ0eUo2cw/l+qhKzNUjm2RZoLesnvQukmqZxWJ5VlA1I5fbtU PrJBKudZpPLRBVJZvY8p+T7PE8VMDbMLy5VMjQASjC1S/42TuDYo70jHKybJ5Wy5HJDKpt3Ep7QM WE5YLlpuSEfNpmZX8+bmXdKRNcaabS22zpOObBrbGFuRrVJqv0otlzekcvVJ4tK07G050nKm5eOW u61Jrbmts6g23p5jn2GvspvsLvtm+y77Ifsx+3n7tTbWltyW21YhadxOOcpCSWJ7mVSuSZBKxzyp dB6R+NyFcllGESe47UyIO0JWMrET8J5InqsVLIJPOC4ysVzsELvFnZT2iPvEI0hnxEGFUpGEvELx vGKn4rjigjJVHFQWKecpq5SnVbNVC1Qu1QbVedVFdY66Bqv1HvVJ9UdIV6IKo9qj9mvGaIo1FZpV mq2a45oLmhvR+mhPdH9MXsyxmKtajTZJm64dr23QbtL2a09ob+qKdbU6g65Ht0f3pu5OrDK2LLYu dkNsf+yNOF3crLjKuOq4lrhn43YhtvnuHd+7m8n3rYCKYL/wSfA54TPgD8HnRAGIDr4vxgT7xfhg P/3WTz9mhoLaZbGZQ7dpX4/v6vE9Pb6jx/fzBnBOQXt6fEeP7+dF0W4W382byXfEUMN38/he3kCQ e5uf5bt5fC+P7+SpaCdvJt8Z47taAN/HS6IdNr6Lx/fw+A4e37/L5ruM4OT7d3z3ju/d8Z07vm/H d+34nh3fseP7dXy3ju/VxUmSoD9JQpkFadl8XxJ0JbSYD1RBhxocL0ZZBzSgTm6JVnyHj+/v8d29 bL7fibN8d4/v7fGdPb6vx3f1+J4e39GLl0ZJfWbJfVaiZaXcsoT28fguHt/D4zt4fP+O797xvTuR 9u4G2BrYhu/f8d07vne3gGqr+NoT9NIencB+gnFwm1ox7ufY05wDtEqcEiwRy4Aq4MmhLrEWcqPQ LgbtYoTbrEr4bOjn8HycKAz9XMyEvVSIhd2oOYVY2I046EUc9DIFr8WRBUcWrJOIB6EgeECYEjwg qoDo4FgxZugXYjyQGnSKsKuYE3SyFHAtAFeaUBgsEaYGlwgPBkcLJaA/GzqEXhj6PQQJC8RYIAFa JiECRwHpQCYwOmgQswA9zj2A48kYgcD1wlqtoGga+2dpouLc4HgfHE60n4uRzGVxaOtEWyf064d+ /dCvH/r1g9MJzr3QqV9MAzKAscAkIB9eVUPeW7zne3slb42FfcfCZvMwRhMsiftFgUerPiKe58nx vAsRsQuS3oce70MPJ/RwCkXAg0AJQH4KNkBWLWRNoFHEAgnQMRFIhZfSoRf8B1v1Y8yHYS8nxn1Y nIjjXGAyjvOg9xg5Ju9AA66lCA3mQYN5f7WnUoMP/lFvibDZUdjsKIuB7PWQvR6y10P2eshZD8u+ D/714FoP/vXgXI82ochL5frKui3420YRbPwBS4TMAcgcgMwB+GgV5A5AxgBkHMLYBiDjEHQcgJxv QM4bsO4A5PBIGICcAeg7wLSQMggpZyHlLCQMQsIg4uUsOM+K44FJOJ6MMj84yKIhe1BMxrjTUWYG /xNyByH338QJqMsF8hAlMV+KyVAs8jjkGownv/YT59mI3s+CM7Lns3LPZ3lsDl3GSnSZvRzsYvuD p1gfIGAW9eLuaSBYJc7BzJ8P2z8OVOF4IVAd7MLq8QvxaZyrD14WlwV3ikbQVpSrUbaAtxWwB/tY glgOjlnBPnE2zjxC0m5A2g1IuwxphyHtV+ITqH8SLWrBtzT4qmjAsRnnW6FNHCR0RUjok1vWR7T6 Llr1UqtWnGsD1qDlGMysDMR0RuToIG0cpGFkrATSLOI8cM9H/eMol+K4HnQDejGANgabxBWgzaAt KJsBK9qugkatoN0o1wId6L0TK6GKpC5kGeLTKI0oGxmP+DmgHgleZlrZnry3UxjHBxjHf0D/a9Tr Mkgxwobcjq1YBzTQcyNGfRlt94KTj5bbpy9kH9gmJGth8F1Yci84LqPvDPKLEZyNKK2QK/mlD3It 4jq0VIGbe45z3QDHKbK1VGukNlQDO/ZB63JImAVIHkA0oIeFwW+L1SifwIr2JOqXBluh12XM0Pgg g9UZ7rOrcKddxfbDFuVDdyDBAgmHZWtYxPkouaQqknYKfX8AaW2Q1AVJfWE91qF9J/SIC+vxCI34 Mrjfor5r+VgghVt8NdAixQ60v4zWGdAkPsg/JyxBJPQiEt6SJXXRaKQIuIz+z5J1pQjoJfutAN1E 1u5FBPAYt4g21K8CVpM9exFvvaKToqE3Ihr62CTMrj7Mrj6sqX1YU/vQO6yBWKQ4HOqEBg8iIrh/ M2iWVePq9DTFYQZ80wUtMsTliDfD0K+gTYxoAt0IrABWgr8JpRk8FpTNgBW0jeKzCtrFQLMSsR20 A3ACHUAn5kO0PKeqwn6oIos2wZpd6J1L7WVRcrTuRIT1Qbcq0s1KsY/7DbKZFR4XxFbGP9kZoLbP 4A6JU+XBfehhFTzeBTl96OkgLH0wIvot8F8rehwtj/m7LAYtainKpBjpIt2qUf8EtFga/E448nlM 9skRtYa8GBrFE8F5NE84pwl1Zop2M0uCZS4jMt6C9jsRGQchlfPwKDOR1FOw4zWa120AIl90oa4T 8yJeXucuyy1uosUbtEJZELNWzKDVqGuhOXME697liNaX8eQhr0No3Uv9maGBRY5uLl/EOpHB4xz3 1nwc9YzzXqba1Yh+Hst20KGVLUqeuRIHl7IaVwmcQZ+X4V0DjkwAP2vBCmOFdq3BX0KzG+B6F1wf 4O7/ZdiiHqvvMhrTKXmtCK3hfAb9B1rwWXSI1gwR3DdoPunQwxs020zySm3B1YprKrXjFuTt3uLc GOG/YS0LjUfi/pXMSeORRk6jDs3iRhr15YhRv0s9xzJ+x5nI12nZRibiziD/IRrFVfIa0Epzv4Q8 EB+e/1k4ygb4mjTs0y45Crhn9oY9Y5e9o5ajTloR7bDlmuAvSK5OltEXYT++Lrwhx0IfvwaCuxcW 7yMbClxXWLKF6pvgSUNwB3ruh/z30fMgyW+DxSlycHZnRHReJquFOPjarAiPbD/k8nv5aTiahnGe wjhPyStOH13XRTaFdnIYfz8DV/kcxj9fnYykYFORlPBCCe4JpiGp2XSkKP5TOojfCqQY/vYA7rIX I+nYUlYPXzTwdwPYT/D8kcB+zo6xJCFfmMKShU+ET1ia8Knwe5YufCZ8xkYLfxD+wMbg+VhgWaJK VLGxYpQYy/RivBjPHhBTxTSWK44Wx7A8caw4lhWIOWIOmyIWioWsUCwVp7GpeLKewx4UK8V5bKY4 H7O9QlwgLmJfE58Sa1mluESsY/PEelj3MbFJbGJPirhisxrRKlrZU+IqsZ3VimvFDrZM3CRuYgZx s7iZGZkQXRHdzT8bZhdZKWOr1gI+JqxOR9kNbAadzdgaE+hn6RxbtR3oBV4E9gIHgD7gMHAU/Dko jwEnZJyRy3MyLgAfyeD0FbTJQzkoH19ggqVBKlcXobwp4w5jq+G61WrUl6HUAUlSG6IlCGv2hWgx rfmK9br1kvWuNcmcR8izxRHKzNUSbHpCvbmIUGabxGFuMedxWKtllNk81os2f/Og9VbzTevd5jvW W1YGuf02F0FtE606m4b4ymx+a1HzOYIafLrI/pvPEIpA7wHSZYT4s0ED5trmcxzDepqZjJDepKe1 AjSB08B82wxCtYwyPiagQkaSrZJgAS9H6LgFdEv4eEFYPqcjjptu/nFY50MXC7Ch6YK1B+gA7QC2 gObY1fQRYQ/GxrHBtogQOu6HjP4I+8vjDtvjuM0qoWmQcNKcTQjZ721uY2Af+brBeh6+4ZD9h3IT yk1hP0gxkWzdh7b7JH1Cvg37OOTbkC9DMkO+D8nOgSzAbIKupvv48t4Y/FO+/+r2mYR7fT8XNIHT 3F/h2MmWEYqdAsJX8tuKCbWIn1o5nghNVwi1MkIxNt82ixDivxcmxJ0pIgbL/gRCfHPlORmKUQfG zhGOYdCWiGMeLxxJiK8kc9lwDH/xOByrtRhrNbANbXYAodjk2GdOJ4TjFfSeiOOD8AdHmN+2hHDv +VB8h1AhxfeX1pl6HHO8BprjCOgjpGMeoR+xDJhbbDs5wmMbXp+k4xB/GQfitdpcQaDznBdtqyPa D/NL60tI7z95bFvBYa61LeHAHOwhFPG1jeZVNiFHxknbboIc67bnzdkcETGsJ/B1kSM0jzlC8+3e eRdChYx76+tlDM/90Nos6Tg8f6U1IVRexDgvmpNovLz8UnyZtxBkG9q2htY4jJ/juM2O+bnI+vaw nZs/sl61dmAucITiuwg+LZLndOS1QZ737Reaz3AMn2//iBBeN0AXRR6HbR/iv0K4d525d90Izfu5 sD+wJmdNHod1/poiQmhe3nOtCI8bc7J9ELgJGut9+x1z3hr25ePhuQIdOe6dO7Kt1iBO15QNx/Sa ChxXDB+H50APrgMcG3Ad4Di+Zq4Es5pwEr7jkO2yZr45m6BuPscRis01OhzrhmM8vN6G7gnuvXbK 48ddk5Y+C2f0KbiGPv+OVpWqSlmcaobqIRZPn1KPUlern2KZ6iXqp5mePp8eT58TT6RPeQv5+4Pi b8XrkDJWMZ7/vJSiiKkVJYoylqAIKG6yZFWuqoBtVlWozrJvq36p+qUwUfWu+iFhknqW+uvCt9QN 6mbhO2qb2ib8QL1a3SLsVjvUTuFFbbQ2WtijfUXbL/wP7YD2p8IPdYLOLrzMBOG6WDZ8x2fqAbbQ J1rMtA3YAbqAsWY76F10jpn2ALirMh0E+oEjwGvAceAk+ItRvg2cl3FRLi/JuApcl8HpW2gzA+Vd +fgqExpWSWXjLMYaRRkaIA7AvXpjJcpMQC+1IVqC0DwQplNYAX/DmFWzOraCtbC1zM+2sO1sN9vH +tir7Dg7w95j19iQoGEK02aTz/Ssqdu0fflhJppmmSqXlRrugCo1lS/LM+Jm3ZRnKjLYDR+D0psm GZoMg6BSTWNM4+tPgNKZkkzphg9BiSaNKc5wlInG28Yhk9JwHHXMeNN4x7AfdbeMV43XDX2grhk/ NH5s2AHqI+M54wXDblDnjSeNbxtwF248bXzd+KZhC6g+4wnjUYMf1D7ja8Z+w1qmhORrxveWHYGE G8aPl8eg5ppxP+hDODOwvK6+HNweo9+4yQD/GtuNa40+w6y/WZSq6J0ORm9zCOoN6mdYNL3XkEhv JYxCXKUL3fSfT4/CB8zAgbgwwM/QgplTUVbKdQuARcASAHf6hhWAFUDMGVyAB/DL2CSXW2U8D+yU wendwEsyHcJ+GYcAxIbhVeB14E35/OtfQsGytZR8TauWrW1qX9a9bPMyn4y1wLPLtiP1onwW+YtA Lx1xmufb5cTPo2ZpddMVpMGltfxNHdj/BmPiTfFTPPf+Hr5Qki/U5Iso8oUOvpjJYlUPhT2SAI88 ydLUT8Evo8kvY9T16nqWDb8cYGO1B+GdHHjnLntAOwQf5f0/7Elgs5mLfF2IZ2PWgCe5hisAnuAa 8KRWh7WkAU9ry/G0ttLBNPUL6hc9/TzyJfVLnr62cif/LF/8nfg7aHpLxFqgKlchdtU16hqmQOwt ZUr1MkSgSvsj7Y+YWvu59nMW9Ve1EZIGR/F3wnXCUawFzAnfOxE3Ky8SRHMCjhE/TsSPE/HiRLw4 ES9OxEsTYtSJ2HAiZpoqJThPy/Wc750wBG82E5/eIAFxLprHoP49lOOH678K5lyg8M/gKwUwYvNs Oia9CB/KunFdsE6txLq85MQX2kp81+ATJdrPk+tu/OVoSCDZYYTkOm8zMXCXid1ieMzcrsP9D0HH GQQ6bir4StB59INS/MBR0+nwL3HUdXb4GxyGzg3+FY6mzh6/1bGqc4vf7mjv3OZ3oX4H6g2du/ye xZbOPX6/Y23nPv8mh6/zoH+ro7uz3/+8Y3PnEf9Ox7Odr/l3g7MH/O2dx6ltj/8lyD8Jzu2db/v3 gz6Pvno7L4Lnxc5L/kOOvZ1X/QPgvO73IL+I/EDnLf+rjr7Ou/7XHYc9ov/Nxbs8Gv9px1FPnP8d xzFPsv89xwn063ec8WT6P3Sc8+j9HzsueCb5rzk+8hT4bziueIr9t+WaQc8M9HLTMws1Z5CfRl6J Vmc8C5Df8SzyDzmZZ0lA6VR7GgIxkL8A8s94Vvg/duo8Vv9uZ5LHHkhwpntcgVRntscTGOPM8fj9 S6Sc2631vDOPW8xZ5NkE/jLPVv8KZ4XneeQOz5v+17+Qd3hOh3MHz/noArnODZ53/O99Ie+hfIvn Pf815B9S/l6g0LmNanZ4Pvbfdu5CfvoL+R7PNcpvIN/guU3ShvMeyvd5hgKlzrmenYHxDgNpe9Cr DJRj1JDgHu+9GTjmnO/ZjTFW00ilER33jgnMcwx6xweqnP3eGFijDGP0gJPz5HleggUkutazH7RU U+855PfLuUmmB5BbPK9CZmTe4nn9nvykNxcelGKMvOl821vo3+887y2Fvy56y/2uxdXe2YExUtzK 47Kgrcd5hDR8zZtgRL03NTDbeck7L1Dj3OCt8n/ovOqtQfwgJgN13Pst3U6Ltw49XueR5rxF9F2v wf+mFHUukY/LpeEe5LOm9TiPz1aLKw6aWx1HvU2IzPDcCRh4lC7eIlnAlcz96Mrko3Dpvav4iLzt fETetcOjq8vB6C7x+HFN4p51FRBdTF62kP3Jv64ZXp9/q0vj7fYPuWYRXUn0Am4Z1yJuGT7LAk0U z6tgpc3+BtcS77OBGFcDt6prBcVAC8UnRYXLCku+6rzOLemyc6u6XER7vNsD7S6/tzew1rXJ+2LA 59pKdnie28G1k1sJ9jdAq92cdr1E9H7yfod3L3rJI9pBkVxLc6SD6Fveebx38kUZ0T2c5qtN63nX Ie8B1Fu8fX6Pa8B72P+xqc571LjE9ao31bhViiLEA2aB63WKKGlGUFyhHjOFr1T2V3nMLF3hetN7 zL/Jddp7AisDVq1AN18f7Jmud7xnjLSCBTZLnHwFCzzL1wp7pryagQ5sd73n2RrodX1I84t84fqY 03xlgzSsIYEXXdfI/je4/V23vecCe11D3guBAzRHVkjzzq2MoGOG7c/Xw9bzfOUJ9LkTvB/5B9yp 3itYSYYj+bB7jHcwcHSdhp9dF8fPrksmOpNoPdGTIltt6A6kOgzeO1hpz/gYtO31HQF9zPcaekQM b9zEY3jjVnmm0+okRe+6Ak/yxufXFXte2rhTXoukGd1DPiU7r5sRsnPrPrLepnWzOns27uZr7MaX 5BlNEctHh3oaHfp6PTxqrPYb98vraoTO8qoirTCkG2YQXznrh/3ekTosv2MMl9kxnss0VfnUgRPu c75b3Q7nPp8uUOrO9SUFzrgLl6cGzrlLfemoKfRlB87JZ8t9OYFy92xfXuCCe56vKPCRqc5X5re6 q3wVgSvgnEut5oOzxlcdGDTVcM+663y1gZvO13z1gTtug8/UzdxNPku32r3K19Ktc1zwOfzX3O2+ ju4k6LPBuMS91tdj3Or2+bZ0p7u7fdu6s92bfTu6c9CXpTvP/axvV2C2rPl2357uInevb193mftF 38HuCrTtx9qFdax7bkdu59s9L0pXK/de3/Hu+e4DvpPd1e4+74XuWlMNtN3rPux7O3CA09317qO+ 8/4VkHwRko/5LnWb3Cd8V7st0hVWupa5z/iud7fIeWlXTqB0bXpXXreDa9Wzt6Owq6jnQEdpV1lP X0d5V0XP4Y7ZXXN7jnbM65rfc6yjqqu650RHTVdtz5mOOtSf6zB01fdckK7RHU1dpp6POlZ1WXBl ke4i6Hrd0e6d13OlYzzN/bwNe/1bO9ZuOICrM+4WNu6X4gczZStiY4/n440vdfg6b3W/trja49mo 6ejms7hjc1dLz2DHs10OaLW9q6PnJpfJ44HL7OjtvBo40/Fi14aeO4jh8IoqXZs69lIsSdcp6YpM a1THgf9D3tdGRZVdiZ77UV98NV2WNE2QJjRdTQxjA4vGsiSGZ+DWB0KgqjC0baMxxhjHpmnEAnxQ lAU4xtg+w9iGGOOyDWMMMYbnGMc4xhjiGIbncoxNG8cwLkIbwjMslzHE8dk8fHvve29xq9TWdPLy Zzhr77PvPufss88+++xz7qWqLvo51O8N+7wmnmh9vunoTATQRuamExiNm05TNKYo3XQWaSXS1lOk zdasek2Ubhps6+hkTRfbtnXqtXGv6XLbzs64puG23Z3mjf62vZvzce46k3HuOtPgBIKro2fTQGcm rtz2u8q+U0CrowO0uqpdTRuHW6ZgZkdb+VATYCNg9K58hU94w6HWhM1FG8dbLcCndbTxZmvK5smN k63poYCC77VaQx1+1pod2ubXt+bBKoD6dKaC+fXHtdpCO/3m1kWh3f7k1uJQfcNQqxtk+vGchnhz kT+ttSKU7M9sXRoM+ue2Lod10dK6KgL7/Dmta0N7/QWttaEDhA/hWQ4wxWQZ+wtbG0JHNu5o3QR+ u7g1GDrmd7ZuCZ30l7duD53x+1rzQuf8y1q7APtau0Pn/Stb94UuhXFP6Ip/TWtv6Jp/fWtf6Drg 46HruL5CN/z1radCtxTc1NofuqPQgdaBULI8azCuC9CvuXUoNOXvaL3azvu3tY6s2O7f2Tq2Yql/ d+sE0Htbb8PpMQ29l3CChjb6D7TeXdEAeBpxQMRZCMS0W+RTtP9QILE9RbHzkUBSe/rKXYHUdqv/ WCCjPRt6XwSWPBnIas/bOBiYB7Qih/CZQH67zX8uYG9fBHRRe7H/fEBqd/svBZa0V/ivBDztS/3X AtXty/3XAzXtq/w3Aqvb1/pvBda11/rvBOraG3CP2OynPaKvsTgApwjYN/ngUKO7uan9OJ7M27vw 3qH9FNH9jRV4FmpcSqf0luaO2n2NyzcltA/guaidTu/tQ42rgL6K9OZdjWuBHoG2Ce1j5L0TjbWw 79zWenJDbWBHsKGxIbArGNwoBvaAVx9QzgywRho34RrBexOIG3AX0D6t8IOB/TIfdlXgd4hId8TQ ncKI9mzQuAXjT+N2ij9wNgCduzblbT5KdC/SHYl4QuhIUva47sDRjqTGfYETr2whfiryOzKIziJ6 XmNP4HSwu7E3cDbY19hH9HGk8S6pI7/x1CZbh72xn+4U6AyPJ43aCvTnjiKkOySk24eIXiL7+YZr gcFgw4a9gYvBEbAJ0geQbizGONM4gHEGTyO1+/A00uEhupfo6sYLgct4MgkMw8kQTrwdNejhHasb hwKjwd7Gq4FxOLG4iR5BGut31GB9qFOM92uNY4GbcGcE8apjHXp+Ld4zXmk/hXRHnTaO0V7fK+/1 M6eaqm1Id9C9VYe/cSIwGewD/e/BHME94OvX8G6rfbrx9swZBu8KO1rw/qu2YkNBG4M5vdumh3Uk 09NtcR0hiGx4ZjiGZ4YmceYEixGyYyuur44dRO9CumolecKeppg28+aYxpS2ZLD/Xjpj0C7QlNiW tvl057nOS53nm+f64zp3Iw7e3nCo7QDErpa2QyHfxh1tRzYXNY22Heuc658K+Ns3NfKBlvZg03jb yc6cppttZzoL6j1t5zoLmybbzncuripsu9Teo5zwq9uudDrR8p3lqM8rDU332q51+uQ7XOXeVr6r jbxjLVbvUptZ2/XIe1VlB6fzQ7O+7Ubnsua4tlubbzab2+50rpTj6obzbVNwl0Fy/OYgH5pqTg4a O9fQmh2TVyL227leuZuGszFwyJNRk856Jd6GNels0kZIulMewXvkzoAc0zBidHbI99dyXMK13OHH vaNzm4xljtxLc9omY7ulOTOY0LlT9hDcNYCTE7R07lWeTtATg+aC5vrOA/LTiebCYAr4mPwsgu76 mxcH0zsPNTuDVuhRfuZAdpOfKsjnzOY1weLOk9o7SoWWn1dAq84jzeXB7NfXNPuCeetvNi8L2tpT mlcGF3Uew18ToG9/Mc23v3j69pdoXGysZjr6xlcqfePr4/SNr0yj39jCXjK2Gb/KCujbXJ+hb3NV xH4iNof5Yv937O/YcvoG2gr6vtkXoI88lsk+xRgrZq+xFLaKbWb57CuQfGwn+xqrYvvZO+xz7CCk V9hh1seWsR+xk2wFO8feY59nI+w37E32WzbBGtkddp+1cjw3l/0dt43bzvq43dx77B+5/+Cusz+I 68TX2Qdij/gddl88Jf6UE8Tz4rucSRwXf8c9Ld7RCdxsXabuBe55/Tb9Ke4F/Rn9T7lq/c/0P+OW 6Qf0v+Be1f/SoOe+aDAZnuHeNswxpHE9ho8b2riDpjbTFl5n+oqpi483fd20h3/G9C3TYf5jph+Y BvlPmt41XeUdpv8w3eE/a/ogxsJ/Gf+TwrfHJsQ+xXfEmmOf4bfEXov9Lb897o24b/G74ybjOf5f 4lPiU/h341PjM/ih+E/Ef4L/VXx2fDY/zDiwyzp6UpqG35kpW63AOsYcO1hKWU3Z6rJ1ZXVl/rKW slDZ1rIdZbvK9pTtLztYdrjsaNmJstNlZ8sGyy6WXS4bLhstG4c6h/E7WDS3zPgZ42cYb3Qb3fRd NTOfzWczxtt4G+N4O29nPP9p/tNM4Bfzn2EifWZIz5fxZczAV/FVzMh/jl/GTPwKfgWL51fxX2AJ 9GmhRP51/nX2NL+R3wgyG/lNbBZ9ZugZsHcmS9b/Qv8L9iyM6Qq7RiMz4zfTnINslfOei7n0rjiX 2ZXsSnNluua6clwFrkLXYpcTuOUun2uZa6VrjWu9q97V5Aq4OlzbnIOuna7drr3Oi64DrkOuI87L rmOuk64zrnOu885h1yXXFdc113XXDeeo65brjmvKOe7mnYOadFFJl5U0HE6jcnIbnTfdCc5JtwXA 5k5xp7ut7mx3nnuRu9jtdte6K9xLncPu5VBzlXstfsfJ8A9gzaQIP8fvruezOvBaO2sGn19Mfl4K /t3HysDDf8TKwb/fY59lNyBVkI0qDc8bXmAew4uGF1mV4ZOGT7Klhr8xzGOfM+QYctgrhgJDAVtm sBvs7FVDoaGQLTc4DE72muFVw3K2wlBjqIH1wrG9sJLQyhlMx5iUAGBRIAUgnRVKiVKSlCplSFnS PClfsktFkiQtkTxStVQD/NXSOqlO8kNpixSStkK9HUDvkvZI+6WD0mHpqHRCOi2dlQali9JlaVga lcalm9KkdM/BHHpHnMPsSHakOTIdcx1Ox2LgzZX2OHIcBY5C/D6Y8U3jRvrWX0yEtZoh5bN/g/Qy ex9SAaz637D5bBySzVBhqGALDFWGKmY3rDasZgsZB6uIfq2EzWUGxircABWM81ohXwqwnHFF9QDr hbyKYm9ChdtrIUC6wptSsdSbTjTCcq+1YpU3O1y21psXLlPrYVuksVwtq/XawjTyG7yLKjZ5iyNy lI00QtDrJlDpLd6KcJkKqi5qPQSUr9Iocztcb1d0wn7VawQsf1JQ9dHq9aSg2gh1UHlaPdRyVX/k dSm6Yo7QDWPVgra9FlA3HCfm+2AO0D5dir3VPrYrOc6R9hrtuVRpg7pimx4lV3VT5ai27fUujZjT Lk2u6tLnXU75ce+qcF/ROfaD/au5qrs6FpR3yrv2gXZdUf32e2srBrwNFRe8m8J69kSN5WG6quPR ytbaa0hzjfqhTmreHXWt+qTWF9VxqLyr3mDFiHdLxLxj7n7E+B+mk/ZaXV8qH9p45sq86Dyi7Zh3 e2W+92ql3TsSMa+PyT05T1YeUS/a3k+QU3v1OtrO0bb4sHwo6hrG/ci8WJNr5HgKZDs9Lv9QvbTj eJi/qWttwttVcdvbTbSaq3FZXYN3vfvCZdPeHvSVStHbq43XlTHevspE73GymaoX9F2Z5D1Vmert 1/pfZYZ3oDLLe6FynncoHB+UeFBZ5B2j9auNL9if5J2gtku8t8N+DvpVerx3Echu5b6LldXeaaJ9 vsueZb5h9FfPSt+oZ41v3LPed9NT75vEa4rz0N6zGGKiugc9bC6j56YJ+lLitCcw00e4vMN3z7Ot ij0wF4/yze6otf24eBVdrtjIs7NK79ldFafqjbb17K0ya20V1qHiEXEI7VnjExHC+5rqJ2r5al9M 5TpfIkGdL6nS70vV7qeVLb6MiP1Ws89WhnxZ0ftb5VbfPJoLFVQ5O3z5lO/y2Sv3+Ioq9/sk6ucR UHnQtwSBYpnKO+zzhNewspdWHvVVV57w1WhjWuVp32oa21nfukfuy+h7g746HC+OsfKizx+WednX orVX5bAvVDnq21o57ttRedO3q3LSt6fynm+/h/kOevS+w54431GP2XfCk+w7HbF3qGtPm6t7SXQc flQe7V8VUbnKx7jf/RB/etReFL0nQVtPoeKvD6un2U+pnmYtk7/iuoP5VnM6m2D+uHF+WKzFfJ9y 1lBzdd24o9ZR9P6nnkfg2uOMzMNnm+CD43hgv31SfZXy8F4Zva8+6vwRPZ/K2gr3hzEN7P3G2TcG HzjbYn8HqpI9ab6znkzfoOdQVZrnSFVmxJkR5SLgmFHWsaq54TWM9tKej9X1p55DFH08J6tycJ/w nKkqCK975J+rKsT1p23vOV+1OKxftGyQ67lU5aS2VzTrSxOf1FgUPjujzteqysO2uF7lU+O750bV srDdFJ09t6pWRpyHFDt6+ar6iDlG/1D3RGx3p2qNZ6pqPd7FG98y/g/GYnPpF4QmYicY/mKm9a/7 fEUnsPv0HGUFPUf5vP6M/mfcLnqC0k1PUA7QE5RL9ATl1/QE5X1TW4yFX0zPRa7Qc5F/p+civ6Ln Ir+m5yK/w+ciQgo+FxGy8LmI8Al8LiLk4HMRIRfuaHtY78zTA3shc9p99mX2lfY19vX2enuTbcwe sHfYt9l32nfb99oL7QcADtmP2I/ZnfaT9jO2Mahxzn7efsl+xX7Nft1+w37Lfsc+tZBfaFyYsNCy MMW+eGH6QuvC7IV5C2328oWLFhYvdC+sWHDWvphSOaRCSk5KeLWYAGkAfBJgfAU/Pxl1b7sJZqSV tcFd7RFIC+g+185+wS7BnewQpE9x/8oNskXiRfFdVoTPq6Alx6pZzcx4cyZZhjpSGOcayNcAheNF Do4ZR30ARnxAGTWMGcZ7AEZ8DlIAajXZD5COq0HHZ+i7bAy8xwq8LEg83Evj75hmQxLZPPYS07Fc lgf31y8zGzOBTsUsnkmQEpgT0lPMDSmRLYH0NCtnnwVNK5mHWcDnqlkS/bphCvND+hgLQEplQUhz 2HlIaTD2d9lzXAKXwD5Ov7YVmBlrbpKQV9JfMlByoWSo5GqOrWSkZCynK6erZKLkdsldKJnOsUmi FJNbJCWWTOOzjJL+macZuUW59txqqahkYEGPJJUM4JONkoHcGnq6IT/bSMq5Lflz7uLzDZDWL20t uYpSQda8mfTSGZBDaUHPgp7cfGkXSlET9KqmHdBuT26NIxNlgZS70mGQnAH0VYKrqDvpPz2TFvSU 3M7NhxGsA71DJUPSfhhBC4zrYMmIVJTThU9ZSi5IdoTcItBxHj5zKRkCegifvJRczbWX3JaWlNxG SQBoL4Rp0C0GxglA0vEJTaJUh3YiW0FvCDnTUpE0inLVXkiiCqADgjQO+RhIBcjpWtADei3BHJ/3 AC2VTOBTn1zppWsl/Q69NOqIw/5lHRxm6j8xJ6j2jYDPhqRUyU+jzSNKBeDIraFmv+Mc6fYAPIzv OOc477gUob8GsAx1dlxxXHNcd9xQNdTCw/jIc9xy3NFqHx4F8B23cJZlQD3QNqr+jrmufCm/5Koj R8onKHAUgoWHHIsdTmmeo9zhcyxzrCwZcaxxrHfUk2eDnzqaHAGQBBIcHY5tCyakasdOtCHI2e3Y i5Z0HHAcchxxzIVeYQ4dxxwn3Tvdux1n3HvdB9yH3Efcx9wn3Wfc59zn3ZfcV9zX3NfVmcQeHMnu GwjuW+47kiS3wDL3VCkv+49iUcVy8oyDb4XnVParsC+Bb5UaSxPQO0otpSnS/py7pekowXHeWUEt 0D6JJVdddinfVeSSXEtyi1weye6qdtVAWu3IdK2DVOcod+W7/CUDrhbocRX415IFPa6Qa6trh2uX aw/w97sO5ta4DruOuk64TkM66xp0XZRWuy67hl2jrnFHJki66ZpccNx1T0qCsKR3x7nN7jhpnTvZ nebOdGe6LrthTlwnSqbdOe4Cd6F7sdvp8rvLi5dhidvnXuZe6V7jXp8z7a53N7kDOWMQe9DbBmD2 phyXnLzT6Ex46QyuQKfFmeJMd1qd2c4UxzFnnmovp825yFnsdOPoc2y51WR3Wj3Opeoqci53rnKu ddaSXWFOSiacDc5NzqBzi3M7QZez27nPYYYo4gkDzY3jhrPH2evscx6P9lSIGtUI8vw4riE4Tzn7 0XecA84LmKs0xgLnkPOqc8Q55pxw3kb9nXed0zQOdV4hPrpEVwyuSlei43pJf85dBJpN8DtXkivV leHKcgbpOXGLNM81b2U6RttSa2l2aV6pzd3h3la6qLQYNL+QFwdxKrHUXVpRulSCiJdbXbocrFoN usrROCQVla4qXVtaCxLqpOrSBjcr3VQaLN0C/GDp9tKu0m7g7ivtKe0t7Ss9Dv6dXHqqtL90oPRC 6VCuvfRq6UjpWOnESydLb2P8w5iLvgva3C2dJpuA3ksS5WgJdoqBWFq3RFwSQ3vhF/8LnaDWsjp6 Zo6/+c3ytjAOwJIXgrQV0g5IuyDtgbQf0kFIhyEdhXQC0mlIZ/Pu5Q1CugjpMqRhSKOQxiHdhDSZ N4m/MmhcYVxJv6ZYwhxgVxcrhXNFGZwO9MwL1osFO7+G3wCJG4+7TRrR/7penmKcbT1jBTzk9ULe y3dsa16eUgDoAh7AKNN0nQBg0ZSlaMrUelMyjeXhsnQNje2sANlReYJCI+QpoNI2TZkKii7hetmK /OwZmWqfpJNGH6pn/RMgLwqidfkwSNHooNEzrEfKjN5aG4VtxStj1YC2fYSsPKV+njIHlhl7a/sg PYxR1wkzbUhX60wermeNyhdFzak2V3UpVnL3gzqE8yllXFORekTIqXjIGKL7XQqwHGCVRs/osTxM 14fY51E56Zf3IbnikxG+yEfx1gLUPtoO0eN/rE7a9aWumfTItRddh/IGgH6AgUfM718wf5TdnziP svOTztdD84YnzLU2Vuz0uPxD+7U+Rn9lrRVsAggqdHDGN8K+jHW3aOpsV+zUZYuM190A+2zhmBH2 jR6A3qi++wCOA5yyzcQH1Q8v2Gj9RsQXzIeUtldtketxRAHgzT8B+ZhCnwY4K/vi/EGAiwCXAYbl a4rz2D5Fswc9yZocsYXjtLYPtXz+KMD4g7Z+pG8+ztei4tVD4xLqchNgUsMH286/F2mraB0ekIVl Ewqo16qfqNe3Ae4qMA19iLaI/XR+jKaudm9CHRNtD+xv85OUuVBBlZOq5BkAWQDzbA/sTVqYny8D +ZDKs2vsq+yl84sApMhxz18i6zvfoxlzFGDd+dXyeHGM82s0MldH2mv+OoA6AD9AC0AIYCvADoBd AHsA9gMcjNo7sh+RP2SuHumfTxrjjA/3pz91T/pQPaLXsDZPUeY7Kv+zYq0aSzT5A+vnUfv/4/LH jOcj6/the+aTzGt2ZP9qbKpOivR7Nbcx8LvDAEeB1gPEKf1OafrhlTGDLJvZNrOGE2yR52N1/aln Y0UfW7KN9glbmm1m3SM/U15/2va2uRr9omWDXFuOhqeuR218UmORdUYHW8FMua1wJr7bFmvspuhs c0b5iWJH2/qoOTbOrEVqVw7gs63Bzz3Rr92z/zr3mtxOeutdHJfAihiz7gbYy1jmPhmsByDvgfwQ wBGAYwAnAc4AnGMsbQDy8wpcUvhQL+3UDDwbkutR3StyXeRbrwFcV/g3AG4B3PkIMCXLUUGV9yIv 6/+iUZEN8GJCZN2odkVWszXZmmbNtM615lgLrIXWxZCc1nK49kEqty4D3kpKa6zrrfXWJmsA6HJr h3Wbdad19wujL4xa9yLGXKasBwgf+ljts1nPZlmPgLxlVufHGqzHIJ20ntGkI/hZzwc/6UtveBDp 3Q6z6R0OSfQOh2fp7Q2p9N6GOfQZ33T6jO/f0LsacuktDfn0foaX6f0MBfRmBhu9mWEBvZPh03/1 /jjOzMmfmj3JPsnYC9WMPXNOhhdqAFYDrJvhPQpeqAPwP0G9FgDwvxe2yteZxqjyHY+XocAnM8cy J6LS7WfXhem7Wn7mtEprajw04dve6JPcjN7gIb+7Q0ef5I6hT3LH07s7kul9Han0po459I6OdHoX Rwa9hcNKb97IordtfILeszH3/5tcjh1hx2b+B/TcLlaWkT97Wk4ZHgB7+KooQ1IoqiGXZCxRy9UW gKszqsOcfEyR5ao8VRZKUuUoEoCTZFfbqT3jk0N+N9hCz+/nfwxh/af8v7A0/uf8GHte36hvZJ/B 6MmKY38Ue4aV0JtDkgHMyjs5Ph5uL0J7iIP8Qf4k0/GnQFYKtUmFGkmEFXtYJhlnuUntvoUY3yrD bGyRpsYlZp59YXae5crsvHSz5YrlmuXabH42b7lkuW65YblluUNpimTgL2rE8N/hvwN9f5//PnB+ wP+A8fxR/igT+B/yPwTN/hm00cGYBpiRRhMDmv2Yxcb+BPRLhBW3lRugZ3ce9jT07mMsPRNg7odA ziPLOEshK5udKidLgiVBpWdvnb2VrhNnJ1qyLdl4rdSaQPzcreduWRosDc/dee4O1sPrcFttgvbU Ks+SNztkqdAmbBtdH+tpU3R5Op/Oa3VMN6YbVVrWTtbP0oDjSQe95P4fpc/MuJT+Ua+p56Ysbot7 dghquLGenCyLgOef7Yd8Ec0jvneJ0duLONMy02uMN60wrWR602rTamY0rTF9iZlMXzZ9mcWa3jC9 weJM9aYNLN7kNzWyp57YhznuMHeX5tsP5xZmXv3kkAZRNQ2ialrWQ6BOhlnrIV+n5HWMS8N3U1Wz MvPKWUZMT9+bc3NWrUynmdPMc0bnTJqnzIXmZOA0zGowX5llNPvMVwB8c4bnDGM7sx5q3YQE17IM ub05U8lXgoT1lKfNqgVZK2cAe0hLg77SSC4kuV4kzDKiZOoLytMyZR3NU6jjrAbSUdFv1vIZ/ajd zTn3QMspVaeH6YMyiO8Llxea0+aMmwvMBWnJUKMA60F+CWCuuWBWyqxVkAdwlvi3eIjR/Nf5rzMT /w3+GyzG9IrpFfCAGlMNeMAXTF8AD1hnqmUJpjdNb7JZ9PYpS+wfYv/Anon9Y+wfWTK9X+rZPynG VQNUANRSlMug75gso88yFCqRj969yjbRJw44Jmnq5bE1+K6UcD0OotE3waN5iEfUP/WWRr3h+06N 5OmMPF0kT9eTpxvI003k6THk6bHg6X4WT5JwDIzGoKMxvEB94/uGUHO57+dJxybSmmN1YR7Pliua a+vJWnPMqfA+imaPG+vD9ebYbsXeh6nvTOKFFL3PaHgXFHtr651U9K5TePirX3+Oz6C3JD9yBHqS xEgSR5J4kiSQJCPJwDf46h7UgXqJJfkJHzKHu9kJzRzKvJOsR+N7Mq9WsYaW16VYQ+X9pWzxJKP5 c6z1MFtw7Dg7T6cCfF8yS0hjLO4UQVnclXhLQlL8KYS48wlJmMNVatyRhCQoOyWXJ2QkZMT3JaRC aR/kGVgHamURnpcwD7mY4q5gipSoylNKQFKEHEtCarwFa2Nv0BP1jJJwLKbPmz4PY64zgUeaNppw NTzx3sSO0gwq/9mMHSAoiy+Od8dXxC8FvDx+VfxaSLUADcArjt8UHwTuJijdEr89vgugO34f8Ivj eygtp/oVVFebIiWq8jbBdTHQ20nOWqKXQ60GuO4Bub3A6QU7ID4efwpXvGmVqeGjjjBmjKAM3wQY Wx87FXsnjo8zAj0VlwBgIU4K3LUXxqVAPgU8NU+HEislHq+JNxKXjkDS7kDrGYlhedC6UJUUlpMX eybOFjcWZwU6PS6bADEkGuEXTWv/hP2Dh/P/ZYpS8jq04i+vc3mcjfXDdXcEN4ubR9EsFMFN4zIp Jq6P4Fq4FBaE66UR3Bgukb5nWRTBZZye+eB6robLszt0zraEeTOz9/gVbuYP8N+GGv/AH4Qo/13+ u3CyPswfhpZ9fB/Y5gR/ghnANj9lRv4sWMjE/xt/EeLPJf5dFs+/x7/HnuKv8FdYIn+Vv8qe5kf4 EZD5Pv8+xJyTsSch5vwYTuWz4VT+E/ANPNt/jfBbhL/xAP01Dd2loXdp6LcVGsbO+bhlcPbLVsb+ IvGWcB789cYIXjHnBp4YwSvkFsPVrQhePmeHq+EIXjaXB1cDEbxMDu8Jj0XwUjk8F+yP4OHscrB/ a3lxnJl2cC1P5PDzHqu1PHwXnWbPkHmT7J5mz5B5E+y2Zs+QedfZDY1PvEh+jvPPKHZzFLt5it0C xO71cBKohQhuiJ4J07oHZqJLw/97oldp6BrNbH1NQ7/1AP22ps7bmrZva2S+relLpv82wgNkGseb QZ8QxXtSecRZM7VhdPL9LOKjgGOYDk6OMWFuROzSdzBmyGNl+i5I3YSL9cv1QUhuoJfq9wGFvB59 L9C9+j6AXuD06o9DySlKxdRuH6TjSupSklaiKq8LZAUVSVh6nGpgWR/IOq7vJwlB/QBQF/QYbdTz 2JNG51EuiUaIn41lOhihbhvAToDdCr0X4ICSH1LoIwoco7xMF4S0hXCezq2rhWQDuli3HSjkdem6 ge7W7QPoBk63rgdKeinlUbvtkHqUFKTUD5JmJNqUWkGSJUuS5QRJQjFweuGqjyTU6o4DdUrX9xHP 2096Z5nA+ch69eA1TAdxRYyZAboejwKF/1S2BvIUsAEsAigGcEO9tBl46gK1LROTIKWKIuAWMVHE vxjhKqQh4oXELDFDzBCuivniVnEewA5xl6j8CQNyTahrV1KSklIRCwMkUZWXBLKSQEY+ANaxowSo hbJFuJLEPciDXBL3i9Jf7Oz5kWwvwL4X3zMDQgAgMxKQz98E2qlAOYBPAaSXAayU6fjeGUioJn4Z visadNvK74GwsgvfKsLv4GsgVRNPD7vjQUg1/Akhjj8qxAlmIZlqYVqi1KzmTytpj5L2I1Yk7gAa a+0BWVv5o7DHHhVtkJ8mCVh2AqjT/KCQRrxBoDL5wb+27en9qvc0pwl8RmicrpuOm15EQOlP2Fnw fo6j2cSYPHDfFo7RTNwLc33iPuIxwjVYyu1Emt3Tw30S16+zIFb4NuL0Ip7G08+YzJkewra6YcBp JCd7ug5lTqcTR49tiTNJmE3HYVv9TmwrBoieBNpNpTX6BNSN5DMdvkWP6etRDvbC8A/8E+9woW9G eDVypvHedjeVymcQOmGAHyPeSVg+r8inhz2ELxF/FtF0CuAmiZZPHWPEOU+YToTcCOEMwicI9yDm qwkbCQcJ02mTL1YkFJLMLNIhi3RLI62yaK6R30I90gmDv45YiCPaSrQTsUjjlU81MFqmnmbAalhn DWF6lzO3hfBlwvUkZx+VppOcJUQPEh6nOmQN2KWZeqJRzmzyqYrOZff7CK+U5dwfQj0Rc5NEVxPd QzgbscATXU+l+wifIs4JKnUSJ0j4EOFdxC8nXEd4nHAHYepLTCS8lbS9qtg2jXx1J2H8nOk9Q5Bw NXkOcphM624RB2uOkS+Rz4On1aH+uiacEVwRbNiAa/AY4WFqe4zwMLU9hpi36mh2UCZv1fsI47OG MR15DvJhpTDCRJO31+hWk4cTjTKB7yM8SaWMSk1E3yIaS1uoVQuVthC/heq3kCbFWAoryEf9Ei1L plb9RNfI9UUb6Ux1RFq5FAH6kWbHwBc4/kv3fw+c797fh+Ml+xwjPDyN/yM4RngMLQbW6yN6Oa44 Wrn9tPb7ZZr4NXJUofiQPH2AVjHFBKSh7SKKDzbiYKsRokeIzqb6NFOAZRrrZyvW3kmtMErcotm8 r8N1lCB+gLNPMSoBYxf7mTgK+I/Ev0XRbJZ4hyyAnD9iK3ZJ/yJiHT4n+7UOo2+a+EVcj2SZLMIW wkzGaCugv0hYT36VTD5WSpwPiP4a0ReIjqFV/zzhFagV3pPeH2VUn/7HxZAj1Omzyf/30pwSjTMo 1KFNjOloB/1OxDoJ46q4F2sKcYhFG/qGECd7OM6sbjvyYX0hPYB2M44jX78TfUkcJZ9h/D7C30bM XSb6Iq5N7n3A34M7VI6/CHsWSCb6TcILCJ9CPtx3As2tJTzC/xCjroC4ETnCDqr5Pv8/sRXyQdr/ QslEL8DehST+OEYMbCtMQczj+LvcblyPHHgL3I79I9DnuN8Q/QHSvIN6RG+Z5N9Aq4pzMTJzOO9F 3EbkCKA/l8r/HGSmcr+ktjKW5ewj/D7WRD63A8cOd4QTxL+C8Zw346i5I0hzgxgl+OdwjEhDTWxV xeOq2YZ7EIzrV9T2uyDzWf4cxiiI3JyQL6DP1wuwQwmbkBbWCN0YgYWvAD6ANYXDxHlOB/uy2EH/ Hf973adh1j4rgkCxTLcE8LOEf0n8XKR5C+HdOlgFOpl+Rgd3zfqfIa2r0UlQP11sBjpLLAN6gYi9 vKMrB7qb6nwVaV2LDvQ0lOugju51HdhWt0e3FOpswjrC1/l/AjxL8AJ+VdcKuEWnA3wWTm6c8Cnh NRjdtwU4LQjrhG8C/SVdG0h4U5CIg3grjXqdgDb5pjAf8N8JaP+PCTuA/0MB/fO7wjvYl/AtwJUC 3LOK49hK9wWy3peEHwA/U1gL+DXhx4APCbBm+f8kfBMxnNZQz6eFZ4BzTgAvEl5CzPmF75CGKPMd tLP4lPBVqPOU8BOos1zAaGbBqCiOiv9K8wX+o9ug+zLQG2nWntPhjKwRwVvEM3Dnxolj4nGyD9wl i1m6V2leXqMZeRVHp4PopxOxFOLtqzQj62hG4A5b+IkuEfAHhPtI2nEq3YOzb6gkH+imtr8VtpCF 0U8yhDcBL8HIJuiEzYBf1/03moW3kC+AHK5DuA54lzBC/NM4dt0/g2S/sIHqbKBZyMF5VOYiRHMB 65GrFn9Lc/ET1EToo7mA+3bh34Uf4fq9fwHXLO4O/Ju0/75PO0UV0d+j0gXEqaF9+RzVZLQL0NMB nlEdhnw2QXV2UP0vEX2EaDudNypoNZVTqxaMkEIznqD4XJJ5HqOf8A7Vz70Pp0fhINHfRqz7PmLh O4RfxrgqHJwG3+ZCsj7U17fxzCBsJZkx+D8dMRGxMFuWj/zpcd0AxOffi304Xv1/An7PkIuj1uPz izd1o0jL2GAmPkaq97BUaCV+D3LEVOJ/DzncObGaMPgAn4nxis+kWWbi5wlDKd9HceyfiPN/EXO/ lFvpirCODv+zdF+cQEx71h8N6zEO07j66YSWiedJ2EdhjPcTkZ4+rnAQp9CZczucbWF0sAvhLkPn FrQS7Ol4Vk+mk9I9QyrSWAqYThfYF+BU2u9eJPx/EN9/lc4zQdrr5X1fT5xUkmOnnV2PawHrwBki i07pqNsQnWDp6e40nXJZL43irHLOR/oK4QuEyXOmB5VWsgT5v4boLfJnKdIIW5Q6A3TvgxwdSThI 9NOEk6iXOcT/HtUf14HPTC9ADLOvR4wrDvbxTOJAPGRPKRg5F/A9NlA6D08LMo3170/IpwL0H6hJ tFzKk/XEFOInEr2S8Em0DFp4eoEBItj0O0jfdxj+O8mkE4JuF9m8iuhvEO4g/CvCPyL8S6qzmOgb RL9L+HnCX6bzsIlKu4mznWi6t9KTHH0TcYYJ039jcS0Afp/waaojEk5i3BTdE93/LdnzWcJP0Zmc MdiJ7t+h0t+TN95R+BbiAH+KznVwAqf/k4KfIpY5eEdQjic3fpXYBev65wbYL3RLEYvvE96AmO9F LMxBbJDxW8QhLDKqswCxnrAum0qLiH+G6L8l/veoPtHie/+PvS+Pq+LY8q/b1dX3Cg0qEkUFRTQq gnhZVHAXURFxR2PcBUFRFETcNRHiviZqcHkuxCRqXHBfEjUuUdx3XOMOibtx1xiFqfPt9j5n5r2Z 3/vjN/PPxE++fTh16tSpU3VOV1U3DTiLUfoCnLrQ4A56PugJKD0AjgKOL3Rawb8JzmTYkwBtoEUw +DVRy+jLSvCfgt8QnLbQ0At0DZSq4HQDZzPoacAstFgF/KXgvIG8EzAC/IHg3waOBacP6H3AJ8BX QHhYjQSdAnvgDQ2S2lmUGr3Ohv5A8FuBPwk4CohR4JdAFwIfgjOd0AnjVSSG0IbRsXpCJhWcfHAW gDMamI668K2ai/5OQbtG6wHgNwU/E5wK4EQDc1A3HjgeCHlxHLgEHMiooAtv0Xwr3E/zjcE23hGa Y+mMQuks952EMtKVOhTX4iCdkIhOhGoecAihsoqQexFaDZwBDlBlkAkj1IBybidhVidhPidhbidh thP6o24j1NoDegBqrYY20Oo5QzPkF0PmBTh10Yo76PmgJ6D0ADgKOL7QbAX/JjiTYXMCWgEtgsGv iVpGf1eC/xT8huC0hYZeoGugVAWnGzibQU8DZqHFKuAvBQdnTcIJGAH+QPBvA8eC0wf0PuAT4Csg RkGNBJ0Ce+ATDZLaWZQavc6G/kDwW4E/CTgKiJHil0AXAh8aY0de5UAZuUnIJ0nINknIPITTSdIJ Y1ckhmgbRtnqCT2p4OQbXiIZJ8wQ6wJwRgPT0TrGQs2Ff6bATsPaAPCbgp8JTgVwooE5qBsP+lmR CzTbwUEtcRy4BBxIqgbdEed7bSgPi4N01xadCNU84BBCZRUh9yK0GjgDHKCK1Z0SRqgBhT9KG4G/ B/QA8FdDHrR6DpzFKH0BTl1ocAc9H/QElB4ARwHHFzqt4N8EZzLsSYA20CIY/JqoZfRlJfhPwW8I Tlto6AW6BkpVcLqBsxn0NGAWWqwC/lJw3kDeCRgB/kDwbwPHgtMHNE4/+BPgKyA8rEaCToE98IYG Se0sSo1eZ0N/IPitwJ8EHAXEKPBLoAuBD8GZTuiE8SoSQ2jD6Fg9IZMKTj44C8AZDUxHXfhWzUV/ p6Bdo/UA8JuCnwlOBXCigTmoGw8cD4S8OA5cAg5kVIPuCPoWzg/bA69hlT4T9FucTBYjjoq1n4qV g0rrBYuGk1u+DPLjC+XqS92E9V4O+FjFCaw9OJ7Rq76gQyCzEjjXOFPFydVjnC/1Qy28K2AJpBUI b4+dQi3IYydiuQdtGuh0nBM+Quk7ojXjTPhTyOBcVDHOiv1Jj3oVnFi0tZ1QvVUwiqwCviVUlgBP Yc08GP4JgFWC1k6W76hUrqhJ/hrsN/yAnZcC31pqkWa+DDIlIR+F/dEytG54uzH8dgG+rQjOV8YJ Kmz7FZzqsNyGkToCa38z9nEoxfpcTMFY9EXvjgE3FUbIUsS+5Ty1q4ZCw2W0OBJ25sFCzEkF7fJR 9I6fGg4b7DjZ+w7YA5aHECqtQVcDHsFO7TXo9lgZrgQ+gmYd/K3Y0yWCf45Q3qEzsQNNgXwKLCT5 mQVHUJfQBs7WwluEaPcycDBKIwg5dlUCp+vKDtLMFVibinYH4HyyH9rdCW37Qd+EJPQrnvBngVz/ 0nhR6VxouIS2ckBvN2nSthEy44ynIdD5FpaUBHaAZBK8XQZo7JSLwx4r6naDnijwuwFfA4cBV2DG XsSIpIOTCJwFPArcC8vnYLzKQ/ImOKdMH0oUeOohOiPe3dHHEyhFi/R7HhLjoA15xnIA2uLRr1rm /YXo++C3g+QUw07oCcIMRL5VfgAHT2qU4ZDHsxURiFZ+RGmY2RZ8DnoksCtwA2qNN/aVkNkDDXiO IzYhou2Q2Q15H/QxCJrhN34dbZVDfw/BqpaQzDKj/muZe/HsxrYekfIYOA36z0EPZoIVT3A0zEb1 DSzpAA6e/si1JunciIgugtJaFGtaTzNTyVaUaZgz1zH6vZC78IxGcYGdA1A6A/NhOOgYOkVR8WxL 3ukiaZRhD2aX0hwW4tmZ4omvvi9G3+ErbgUijvgeyFfGqB2EjBGDW8DJQukkc3yp9aYoXQPJrujv ReBnwHBIZkMmBHQOcDjkq4LG8ykNKwo5u2gW5cGeurB2t7lnz8CePYv2lfwp9umLsHPPxM66GDih 2HGHYs+O03uSlHt2g8b+l1b4eDtD7t9RWhTIFBvot5CJpmii3bEyDPgIuBM4FRiLJ6H3QOcANxLy BKACjhvokkAdmAv+EtQ9TzsOqeENnZwAn2MPMoxoxQ20G/geQH/wbYRcR6kNGrKBY4BR9ISLK6AL IFMH9A3Qr+lplzLVWpNyIOhHhLwkcCZse43SHFPShhOemkBDvibkiXMez1/Oi55kOejnoD3EOmAf WNsTvVgFJJpplSSuNmwDpw5Kw+j0jF+DZzzUppLD0co0lMai3WqGJfSejvQY8U+B8yvoHNDZoGeB PgirToP2sEbAHjpZVcC5B8lh6G8dcGIMO0H/gLpR9Jya6+A8p1MRZQn8EAvP3CD71cmwPET7WGJv OtdVXmu7KNujd3uh/xTk94EzlUoVN60C2qLnIExcotZR6x7a8sdYMJwf5oNfAN8WwEI7ZMaAHizm 0emr0Gl0oDkfvlqBdh8Zz/Exc45h5jjh3DIayICrcZ4ZTN/hUyqo0rd8Fk4yb2EULCgdTqW8Pnrq TiNo6Who0HyodXAeU494hMGnunwTzlH3Q88C8GOgubRRS3yCuj6wkzR3g0yCmC7RDzMhR20GJA2l iJY2U6kF/GziW74HHgB2xMnqI8hXBp0D9ISHVch4EoczMZNyNUrfwc/XVbkeU5ahbgR6ZJzTrjf6 i7qlgc/AX4Be+Jp9oXcgb6Iug515prX5iERYAsk8tOVPfraE0pyxbCeOeljI+77QCLmv+o7uy3TK x5cJqyxNFGck7YdSH0LFFZ58AI99jna3wOejjPjFPM/FTFBM2gaaZtE9RN9KIy4w0/KNXIe5vdLI dZixXyPzYOYol8G/i3E5aGQqOktUugPdgM/Qek2a1TJeqNZGzF4Pel7J58CeSNiTAHt00CVJm4xK G+IXGQOWJBlxh9PpMcAo7I6vo+58yBfQsyrZ1ljEJmJHm0j3OETWO7RohVUc8dKZ7Lf1J451I3HE VUItlzypuSKKmxFat4OTR7RwIVQ7IL5Wk4W8LHTa0EoE2nWl/tom03ssUrO7rPWAUEYc+a0+xYJl IeJxOyy5DA2dUTcO/FTwG0FyrhE1iKD+Gq0KIiheOO4FvBT8/4jO5xUfmieWBcjzLdUfELk0o6I0 0hBkRgHJ98YM9Mccngf9ezGaz8VISZ9EWwx6zhNH3k1GYsZS3TaotYq0Fe6ns24+h+41ajTwJfAE cBGwE6EoB8wklHfMEYh04gRBpgyhVgDOKty57oBfDHQu6FsonQ7MILS2Bj0IpfsNnXTSzq3wdgOi VQ0avMG/A4ykUnkPIvnKKB2PMRqB0vbA8cBlhMpO4ClCmefdyVqixRvIvEUroaDXgE6jO4VYBWwA fEuobYadvkSrt8HXcU9pQijvFMQpDbwAfhidOkpLCAfgydRKdR5FGSFfDP4G4A7gQ0IV2Ux0giVf gDMEzy6Z+lracAMeO4geuXE5f9TyaKssTjiLgn4FOhF2BqPdF1opyWmM0inQeQLzsztk8uDDRuhd V8hYIXML/XqGyMITMbWGuEwnQvDVl5BpSe9OiJuoNQeSY+guxvFWmDKYTmhV3PtEAPGVMHUvTtJc 4X/qdTzNednrATihJXvqYnTGCG9aqVKvxWFhgQydJLQibwhnKtWG0L1MXSVcIE8v/teBZB61JeXJ klG8D51K4SntEOJo3amW5ka0uEb6LTvpnqKsAmeMgLcRX4+Iz1uqL+jMx9BJz7W1UyQj6sP/d/DM fQu9o6Idhf3fYOy6o79D6Zmv8pb6KJ5CfyDV1aaCvkF3QLUS/B/O44HSWp7P/wKSf7bQfFDxnEit CJnikDkLbESorJJ7HQvvSLZJC4meQai2JJS9aCLxClmrhBFHrtCa0CkZ2amBw98At5A24cRvy9I/ 4Tcf8o/0DPmnJ+qugp4XwFV4yr+It5B42yglO5VF6HWYmgidZMk66B9OtXh/6p0IJJT94pLzxLAZ z8fDDSR/yl6Q/BjSr9ai+6waafaIzjFSwMd7YtoA9GUfsD78PwGzNBt++131k3yFdKqTUDoK2A8z qhLerIiitkQoxjQUczvaGE1gGczYmZjnBzDPx4I+SbS6HrN9J7JEASRHQEOwIYN5nguZU+CXx4lu WXD8oO0pWolH5P6IWm8h2Rzx2xb3tabQ01zrgVlBq6zGFFlOyFRFYqjUOoPQxpBdPRHRqYS2fOTn MOAZWOhMkk7I1bJuGdQln4xGpKQj+nwxB+6AM4Wefct2pyM6aB11kJAvwN0kh1atYjby8Cx4fo74 BXH6C2oFIP8TvQ6rvlXIYJkq9eUAjakYb2R10qZaMGf6YFakYkblYabNoDe4RAeKIDmv3mDVF4/5 QPfxHNhvQ+tYPRa+ZF3wBLMc5Wecbg0DPiq8TeMFeiow1uTjjQjgl8apHXAjzscSgIohWSB3mkod 0sN18HPB74y654lvuQcsQFs20M9Bu2FH7wZJD7xfMQIcG+j7ZuskH2VqIM11cNq5zziDhUyBsXM3 3pSA5tVAPJ/l10zbCKuB3xr7/ak4jxoGbVGQzEXpEtjwu3lWSZIbsdNXQNtQmk+S7D44g2GDp9Ev 6KwDe1zBD4Z8Hlp3gs5o0MFoqwLoWZC8BUkL9HSEPcNRWh+0u8E32yJ8DA9EQGY46E3QsB+4AG2F 0RsOSgzkjfdJPFE6GDq7QSYBnM4ozYFVpdBWNvB74AGgMVsqo67hW/SaQ6flHbRdh8wyYAT4HVE3 Bs/KHwPfwJ7vgM+MUYZkMeA6oxXUugncB/5feFsjB7RxkuwPyUqYLZfB346z4sN4o0bDSe9hqsV9 IT8HNsM2NRG0H+z3QakxXg9Afw6fbAGuxUnUQuA9jO9KyOSDUwDOI1OG5Fea8yoX8oR480fZiRNO GxDWKndh8z3QU0EfNOkURMcyYAr0R2J25WI2En+u+W6qwYkETT1KwPlVScjYQCvm2S/JuOIthfuo VQc2f2lauwxRkItWEAvgPDdiGfQ+SHZGXTdgZ4wOTvls/UnSivwgrhJqA6hU/IIePSC0NiKOtgLj chrYAfO2LPFtk1EX/rdkoFYj2DzXmM/A/hjxwbDHOH/eBxuMKPAAloLk68LlyGOLkOuWo6d08omx trTEPIlC74KgoQd6rWN+3ke7BcDzwGzgRaA/NMxD3b3Ak2gRM1NpA22riC/tqyo5vdR8Qsy6YWpr iXvxNHMvzgb34jm+H2N4A4UxJ7bEsoqJ3qm9Y5l33MjUJBbTNzV+AOvRLz42lfVP6p02iI2g30br 2D7Cm94YKiykvxnIijBnVpyVYC70k+TJfaSU0llR5sbcmav8md6MpxLmoCz0zRaTVpjGOOmNjon0 pm+7oFw1ywQrxj6KixuYwsYBJwKnAzOBS4Ar+yQl9mUbExIH9WbbgT8nDkpMY/uBRxKHJCexU8Dz UrA3uwK8lZQcl8TuAB8NjO+TyJ4D36TKYgsD4lkW+ztyUPRiHPVB/DvO3ykLw5tY0jt/R6cP0PYB unyAODs29Th/gLqJxVkl5s9CWD0WwaJZDOvG+rAklsbG4OsLc9ki9h3T6LVkNhketljcjCv+MgSd tNM3ouUK3VaJ0TtWliJHjJ+d7Ay/9eKUBXstTj+Z10PGtZhuXEtkSXl5LeVpXD3CjfoeC2VbUr/H KvPnn81euMn/fdB2UfwuejRrxRj++qbyP/99K7mCkjPK4qOE8GZqZ+bJ6rBwFsXay1VKLOvPUtko liE99yWbz7LYSraebWU/sxx2gp1n11g+e8Ces7dycaRbtzJuXWNda92Ga7Z1O67rrD/iut76k7yu ldQOXNdad+Kabd2F6zrrz7iut+5mirzukT9lS+m9uK617sM12/oLruus+3Fdbz0gpbOtOfKndVL6 IK5rrYdwzbYexnWd9Qiu661HpfQ66zH503opfRzXtdYTuGZbT+K6znoK1/XW01J6/X/wCH3pfAQb 9//kkTPo+RrrWdMzuaZnzpmeOW965oJsZ431oumfS6ZfLpt++dX0yxXTI1dNj1wzPXLd9MgN0yM3 4ZFbpkfyTI/kmx75zfTI76ZHbsMjd0yP3DU9cs/0yH3TIw9Mjzz8bzySyZaw5Sz7n3rkkemRP0yP PDY98sT0yFPTI8/gkeemR16YM+al6ZlXpmdem575EzPmjemfv0z/vDX98s70S4HpkULDIzLRwCM2 i+ERm2J4xMbJIzbV8IhNGB6xaYZHbFbDIzab4RFbkX/BI/vZMZbLruA3vJ+yN3KB6WRzMjxiczY8 YtMNj9hcDI/YXA2P2IqSR2zFDI/YihsesbkZHrGVMDxiczc8YvuIPGIraXjEVsrwiM3DmDG20oZn bGUMz9jK0oyxeRr+sXmZ/iln+qe86ZePqac2b9MvFUy/+Jh+qWj6pZLhl3/ZIw8cHqlseqSK6ZGq pkd8TY9UMz3iB4/4mx6pbnokwPRIDdMjdtMjgfBIkOmRYNMjIaZHapoeqWV6pDY8Emp6JMz0SB3T I3XNGVPP9Ex9zJgGpmcamp5pZHqmseEZ+lYn2Y070Gx5J9DZIHkLsMm7gSerzOzSXxGsNeusn5GZ vomtnTpbP2tSc/RcUO0l75xJzdHPS6op5C6Y1Bz9IiiSu2RSc/C9lkosgIXK8YhmnVgvmdXT2Gds sn7Z0dKvjpauOFq66mjpmqOl646Wbjhauvm+Jf2epJrbmkjefZOaoz8A1VTyHprUf2XRLYdFeQ6L 8h0W/eaw6HeHRbcdFt1xWHTXYdEjh0V/OCx67LDoicMiGfuWAEuAXMCUUegMoKJSEfdiuXJzCcYq IE2O2jhW+j/bzBbK9UU2287OyHn82kLfiChp8bZUs4RYGlgiLcNo5ea8jyn45oHq/IuD2v+eUo5L aj6oEw7qpIM65aBOg6LVoa6cIVrJk5iJsrMOqVwHdQ4Ul71wZe7KedQgS2YoZMXXkLnwgUxJhWzK VA4wLiUzlYsOTZcc1GUH9auDuuKgrjqoaw7quoO6AUrI8XeXc96HVVXk/VlZLNuS92dlibwelBKL lUMSlyg3HfVumf22KjOVL+UYZSnLpfxKZQ1zUrKVbFZUWa9sYMWUTcpm5qZsVX6S+jlWo+6M1nCN sNYqZn4V8RtZsFpZLXVulvJc2aXskuszOdrKXPyGNn3zjsZeZnqsZZ3oe1z0O+DMS1mkLGLlpI7d rDx+47ohfuOa9A+So/JhJEu7eXOp8xWoSAfVwkFFOaiWoAS+t+gh9xGVUPMpaj1DjeeQfgHJl5RJ lKeyBsNX87g2SZuo0M6Ac3SbO3En2j9xHf2QEvyu5sVpllu08loFqmfpzH7g97g3r8r9eQAP4rV4 Bh/PJ/LJfCqfyb/kc3kmX8iX8GV8OV/F1/Bsvp5v5Fv5T/xnvo/n8CP8BD/Dz/PL/Bq/xX+Xuh7w R/wxfyqqCn9RXzQUjUUT0VQ0Fy1ES9FGdBCfiK6ip4gTfcUAkSyGiOFitPhcpIsvxAQxSUwR08QM MUt8JeaIr8U8sUD8TSwWS8U34nvxg1grNogtYpv4SewUe8R+cUgcE6fEGZErLogr4obIF3fEA/FY PBevxVuNaapm03StmOamuWseWhmtnFZR+1irovlqflp1rYYWqAVrNbUwra7WUGusNdG6a721eG2I 80bnzc5bdUXXdCfdVXfTS+pl9HK6j15Zr6r763Y9RA/V6+mN9Ag9Uo/W2+oxeme9m95L76P30/vr 9JcUV3Ibp6VFeV5ejkEVXoUp3I/7yTGozqvLsQ7kgUzwmrwm03g6T2dW/gX/gtn4BD6BFeGT+CTm xKfwKcyZz+AzmM5n8VnMhc+Ro+fKv+Zfs6J8AV/AivHFfDErzr/h3zA3/j3/npXgP/AfmDtfzVez j/havpaV5Ov4OlaKb+AbmAffwrew0vxH/iMrw3fxXaws38v3Mk9+gB9gXvwwP8zK8eP8OCvPT/PT zJuf4+dYBX6JX2I+/Cq/yirym/ymnJm/8d/Yx/wuv8sq8/v8PqvCH/KHrCr/g//BfPkT/oRVkzOg KvOTs8Cf+Yt6oh6rLhqIBixANBKNWA0RLsKZXUSICBYomolmLEhEikgWLKJEFAsRrUVrVlO0F+1Z LdFJdGK1RRfRhYWKHqIHCxOxIpbVEQkigdUV/eXOpR59y4TVF6kilTUQw8Qw1lCMEqNYI/GZ+Iw1 pm+SsHCRITJYEzFejGcRYqKYyJqKyWIyayamiqmsOX3ZhEWKmWImayG+FF+yKDFbzGYtxVwxl0WL TJHJWtEXTVhrsVAsZG3EIrGItRVLxBLWTmSJLNaevmjCOoiVYiWLEWvEGtZRrBfrWSexWWxmn4it YivrLGfuDvap2C12s67iF/EL6yYOioOsuzgqjrIe4qQ4yXqK0+I06yXOirOst5zXF1is+FX8yuLE dXGd9RF5Io/Fi9viNksQ98V91lf8If5g/cQz8YwlilfiFesv/hJ/sQGiUBSyJI1rnA3UrJqVDdKc NWeWrBXVirIUrbhWnA3WSmglWKpWSivFhmiltdIsTfPSvNhQzUfzYcO0SlolNlyrrFVmI7SqWlU2 UqumVWOjNH/Nn43WArQANkaza3Y2VgvSgthnWogWwj7XQrVQNk6ro9Vh6VoDrQHL0BppjdgXWrgW zsZr3bRubILWS+vFJmp9tD5skpaqpbLJzhucN7ApzpucN7Gpztuct7FpuryFsum60AWboRfRi7CZ uovuwmbpxfXi7Ev9I/0j9pVeWi/NZuteuhebo1fQK7C5+sf6x+xrvYpehWXqfrofm6fX0Guw+Xqw HswW6LX12myhXlevy/6mN9QbskV6E70JW6w315uzJXpLvSVbqrfR27AsvYPegX2jf6J/wpbpXfWu 7Fu9p96TfafH6XHse72v3pct1xP1RLZCH6APkPs/+orTEF6B+/IaPJg/49P4V3we/xtfyr/lK/gm vo3v4LtltB3gR/lJfpZf4L/y6zyP36b4Eb78mfAV1fg0ES3aihjRWXQTvUQf0U8kiRSRJkaIMWKZ WC5WiWyxUc6o7aKa2CX2igPisDjOz8rrOXFJXBU3xW/irngonogX4k/xTrNoQiuiufDbIlr7iFfQ ymoDtFoiRlI9tFgtQdx03iJvEFbdWS+ql9BL6WX18npFvboeqNfUw/T6emO9qd5Cb6W30zvqn+rd 9d56vD5Q9jUVmY0hs1mQ0xTkNI6cpiJ3CWQtDfnKinxlQ74qgnzlhHzljLykIy+5IC+5Ii8VRV4q hrxUHHnJDXmpBPKSO/LSR8hLJZGXSiEveSAvlUZeKoO8VBYZyRMZyQsZqRwyUnlkG29kmwrINj7I NhWRbSoh23yMbFMZ2aYKsk1VZBtfZJtqyDZ+yDb+yDbVkQcCkAdqIA/YkQcCkQeCkAeCkQdCkAdq Ig/URh4IRR4IQx6ogzxQF3mgHvJAfeSBBsgDDZEHGiEPNEYeCEceaII8EIE80BR5oBnyQHPkgUjk gRbIA1HIAy2RB6KRB1ohD7RGHmiDPNBWrhDKs3aI6PaI5Q6I5RjEb0fEbyfE7yeI386I2U8Rs10Q s10Rs90Qs90Rsz0Qsz0Rs70Qs70Rs7GI0zjEaR/EaTziNAFx2hdx2g9xmog47Y84HYA4TUKcDkSc DkKcJiNOUxCngxGbqXK+/s5SuA+vxu08hD/n0/lsPp8v4ln8O76Sb+bb+U6+h+/nh/gxforn8ov8 Cr/B8/kduZp5IGPzuYxNPxmbrUQ70VF8KrqL3iJeJIqBYrAYKkaKseJbsUKsFuvEJvGj8BM/i30i RxwRJ3iuvJ4Xl8U1cUv8Lu6JR+KpeCneiAJN0TTNSXPld0QrrST30Ty1JK2WjMueWpzW13m7ruo2 XdeL6e66h+6pe+uV9AA9SK+l19Eb6OF6Mz1Kb6231zvpXfQeeqyeoA+SvUz+v6j8l6OS4jEY8RiC eKyFeKyNeAxFPIYhHusgHusiHushHusjHhsgHhsiHhshHhsjHsMRj00QjxGIx6aIx2aIx+aIx0jE YwvEYxTisSXiMRrx2Arx2Brx2Abx2Bbx2A6R2B6R2AGRGINI7IgY7IQY/AQx2Bkx+ClisAtisCti sBtisDtisAdisCdisBdisDdiMBYxGIcY7IMYjEcMJiAG+yIG+yEGExGD/RGDAxCDSYjBgYjBQYjB ZLlv1vB3GHuxZWwN28r2sCMsl11jd9hT9hbnH9jzsGpy51SL1eMv5NzN4K8kjud/SpzM/5I4U5vM FFFfGyGxoTZKYmNtjMQm/0DDS2h4DQ1voOEtNEyBhpHQMBoaxkKD3INpn5EEqM8d1DgHle6gMhzU Fw5qvIOa8J6ivz5pUs9AyV27vOvfYEy8EwVMkfdnuRuV92i5WZH3aSdmk/fXBHzZMApnQ5VZCHb6 xZyPyfiVNfm995ScD3R+cFz+9Ezu1a5CzpV/LqNdlhlXfg/7QdpDMOwGLLLmddoB4umDDfvq23I3 uYZON5QsY5/IzjkXdXb9T88kyCZ66uTD/KV/G5knEEexYz7mOEnIp28bgvrNQf3+ntKGk/R/uQM3 nrlZ8LRNx3Ml6SzlMS+r9lX7qYnmUzmLIcVYKfrdK3dwWale9oxS3bQi1SZGTnzlYrEqWRmlWklW C8ViCXS2F9GEnytXyghm7605+WkW1ZJRW7GoWR3s7ez+H3A8l5Ub58nq4V8bFsuGyOmbxOJZmvy/ Af2zV/hAmeo+s2TA+Oh9BW4hBe4BobfSRo2/qJ3IynALtGeo0iIencUVi6I4BawufqVtYbfFR/e8 r+0lTUkJ9LP7aryj6lzCp0lyysjUxL790ryrxvl6B4aF1fZulRiXmjwkOSHNu0lyakpAYDm7pyH8 0b8vSU7tnZaYPCiwgr08lfMSHn8vb5+cnObdeGhav+TUxLSR9nKlXOy17aFB8r/gQHtQl1IugUHy x5qSKf/rYh8JX0klWgmlY4fAEvbi9IOthNMnvYf0SxzUN002U8zuSkxrCWv7+D4Dkwf1eW+Y0z8z rKK9gmFYmQ/L+8R7d0jsO0hq9W7bpLE9w+Jjd3EMoMUiGM+wFGWS76RkWCxs28ix57tvahq2MmRN 4OU/P67ZYviev8ovOdh08B+nm93Jnf7LgOj2sc8XKL+0utgiqUalBvG7T1Tc5hy57fOhV5vuWjXL te2Bj/2eZt12qVj+dONKb2IXnCzd9Ps5UeUXHN9Uw+eXqOpjki99VK7u9LBiYVd3+T5PqFvdElRY UCVy+ZYky6RFf/20Me7zjD+7ZaWPnzBz/dPtc789Gbq87YRSVSa1vmp/yeo/z/mzfvrPEx8mha0I CHm5OWCd09jYr0YkLJo/xGXiuqf7n3n/2MZtRtxR/0tBTUs/2hGVWbdtB48TCe1Grlo76VCnBksz 2k4eJDbU3Du60q72CfUXtD7m91nwoPHNtdNLTkVNVAZNZN/tmXS9g0JfEP42/Y09/ZW9hHSn18eq bnfSbHLqCmHl3J6+jLgWNX2hPX3euGJdT6X8kZi6pGK7z9w3tppZePSb1P/5+ZZRlO1l0+rVm1z8 dIOXcQ+uN7IXJRtLWCyFqrBzebF7EcNVLam6H/M6MYyldF335PL+1gvbRQR8GxH32O5MxUVVVYbR xA9Ch9OMGL06+7Ooyk9P7GydtqxzlbRqQzdNfLc6eu4I1urukfseVxIPuC4b80xpknNk0rHXHY7t W7qrU/LjuIgfItijzEMLz3lud15a2mXuhcvl1vqO/ePh8iFrZl0Lm1l/fv+doQPPTF5X8d31u+cT i3w1eVfBTbYj5NmrMX8WcwsQ930z54QPqDp4W+isG1aXw937Hd81rvGAhJU7tu2YGXLkKS82ZtSL MzfCr48uuHlzTcHL6+dcNqWcn53XZmvosjHVc+v/GuIcW1tZmt6/4pSX3eJmre+yI+xCr+kdx5cJ flF3flaGvqzntE3+2775/ujqy95bd9tLT/B2d6m2s/3zxjd62PNmV02ctDfl1rMVq0+MC08d5ipz zCiZY2LNHNPbcrIBcmHRD+NIyDzzvxjVlHDCZI6pHRQUYg8Ko4QTaA92/GhP/+L/i20umDhy6qqt 2rRt/16c/xPx/zb37LJP+atp6soOA5ZMacMq7vk516v+hk8bhT4b8lVG5d8z3ViHS54ZrvVOeO3Y 9Sp8xrzct6Fl8n/8M+/B2d58d9bZ80NbdWv2w8Mej8/cSuxaZsi9TZ4z1OO+EVl9Pq1Rbn73QQdX e4RlxO9fsXP10Mml702a51550+eVh32XGxo2Pm9T5XMef/rdPXO4ZJeYCk/nzZg00bfgeQv/36e9 VhuOPX48c/ZEl8H81qkCPbxm4YXtDa/ObOo09uWFlmu7Ph6W6jW84tgpNfd7dt/YlrdsPtC6ouPk +dq45elrY1pfTD//Znf4nsCfO7osONehhZv9/m/fTx7TY/+oLu6TbJtrJ2bdD6o03Xb/z1z3n268 PX7vu4/M3PPanv7iH+eev0dx6Agx5FDZoL/1nD2x47opP+Us2JA2E8PnVZSiXgaydRzyhldF1cNe ctw/DvsIEiiv1rfXtYdl1c6qOTG4X1paSp0aNeJSkwIGvh/DgLjkgTVSBiQSt0ZKanKfoXFpQ2o0 6SAnXoBk2SPfW2ixqPXsdeyh73+2KxP9TYXDhw//RwrjUz/QlPYfAgrZpyr/YnUJlycFxZPDh11s snp7TvibSvEh2UPXD7bPzNz6xZvU/ILjtW/XSZnfztv1p8GbDz8/lz/1TtWUIece3tw3+tGTTiFd xmXcL3Yhld9za/3gqsv00RFt9N5D3w1aZL16wq+Lh0vY+l7vLheqq5RvL76Z+e2OXXv7x9QN7Jnv P+jok1bVPJ+WGzZ64rqcSec3VHu45pjrnvyln985eWd8akyGx6Bqh5Z8vblMub3Jc36NXb635YC1 hx/Wn523scbqUcPD+vZnozMW82LX4r5uUTn82tc+eyc5n3L/tueVIUGptcoVHvI9UKl9m4TIw15e PxyoHJbYtvWKB/u0pIDUsv9WjXlHNZXsATiEhAQpgoiiIFUgSkmB0CEiBhAFRJCHlIehJlIMXTEq CaG3FRUXpYsiSsnSBZEISll67yiyIiqQpShNZS+rq6C+89457531vL/u/Gbu3Dlz53e++WZmJAY8 dhsGUQX3UVKbfNWMTAH6JAP0CflIH76TXImmTJD0Xf5BvJhVoGvG1wz6Ma6jAsBHBYVGKSurrqFH HQh/gOtYkDycfXwJHuT/1HWGVD1X8uv3G3kJ1bcY6pgzl+9uLZfHVGwxPVofPKWj1H8QHY8ouej0 VOwIvbz6UPsF6CLL70FU3e3uPBLZ5bSsy0RJKSvkXvP0nfdbMrmOS+5Btu7rt4QI+xd7OHkYWQwO z4xUpQbXBT25cBisevkNMwVuKUo0aO5n+tsiz5VIQ4osbU6KOK4GUbSmuyHSxuoBvjC7atu+UFV5 vwbeV6LqnBT/D8nunoFPJ3XirqZ48drvNRVyOIFJ6Qg2kZO0JeKjRpB0viMFS8U7Y9ynpa8LLDby 9YbwztP8fVRqrwRmNJ3gmIQyQpVKFy/b0HXpViGXPRli8oZNp5L0np6cuCAT6/aRNzQ2BPBHdn+P OPD/D9vh4+D8dLIQZFtTGNA6UJ6aMMFdvad891Bo3P2kVzmaunq1bagdnztsBUO4RTeBzEF+wClE D6S70YS+0ajvAOqyMT+6mnKkgj82nQBj440m42NYPhaVOE6owmqZmXmIyJT6xdIbllwj0SWawu0r OVkNpb+YSQifgpPOu7FnSOpPuRd5UCTL9DvpczGbH8AiVR6+Pv+SbIdPje9oahmOZY5W7W2mTDbk YbrD7jU6PlJpF5Ko8h/RvFYo7JMiEd5XVLTFIno+qdrZ6BpCJulE5GbNOgHn04YVrbnBGqYMB6sR 1MuX6rvGImYH1KlLAhLRTkGOHJCE2WtgPeRZ/fDyVXC/85LRyAC776VCqCd3U/IQgkAxnNmexC+h BhYJy+F4nIApe76v1ly7MjtiZMJFNWZeMiGpiRFgYabR432gQOotAKg7AKDi/9IjaAbqTz2C/zg9 +gYEa4xSA2wIC6AJjcauMUrpY4heC1HUwr9Dj2RR0h9DUU89Epno7C1+wBwvjjc30VDDHlBSUEJh 9RSw+/X00dIoqY9zEtk4JwXztUmJmzt7+5Mcnf8t3n6HKBQkMHdSXaV/kXEoFDjUgipnblF7R3VW hj1SKdhNfAuDMGFX50tnzoo6yOv3H8o0Uy7tdJ+y1iwKTjfQ5ocrYt3w49Va0WAXcLYQ6bXRlKz8 tFaATWYXOfHQP+h8bfkKixG7xl/tKXrRmsLhkOVtUa1Z24orG2VY8bk/v9lbU+2nWjkfMkqdQPQJ z8zmzdBu9PSyZ6QK0le0l++OlmDq08BOc+OrO2W84OaRguDZYFn/gzSvLFYu5nRtr/s2U0nnqw7G +shVqfyQyVvkSvbGgT4M9LHcT/tKUrrlQ91LGwUw52Jqz+dtR2LeuVTsYuCPLeYuK7gGu+65RO+w Tpdar1NfgDBx9e0CK3pmnDR2nGiy8HNk4PB1xQ2m9F1i/Dem5OtDdiT8T0zpry/5fh/WG/yPg/k9 WvHgAuwvaj24ic0chELpYpazrMRbdfAYZGEzzqs7lBIgNvx6e0ElZWwpcXYT3jB3awVJflbH1cFi dvqCLH+8+mRLf5hJ+MIJA6mzsoL74KlVPGgIrQ9bwp0E6oy6c5rwuDhcN1lHZcgqU/a6xkAlh93W WwWbDz+M1YqadUhcdJnqnhNBMDCDv6I5769IEvUPL3f6SL7YEysJWrGs4sijpgmWKy8hYsWMHKDp EW+oBi95LsJ7rTTjRN04SdlMQ8oxGs4epKaXxNGE60NWmfpwar8v/+d83aRqtRMhzbhLm9xkwxCg Puy6gd5Z6dST0BGI22ujb86p1cy+hDsOaoowJ6D/1ClIIpiNDUUN+4FHtg0HyS9XXWnU+rXd6dOy cbKjudffowHjfom40Lyo9a2CADU+d4SggVTPNTrzvDau3GiHA0z26bh8ohKn0BSKuK4LN9oaZZWm GCQPsgCRQB4gZ5APSBxkAjwDgOdR0CmgjgDyBMoHQb5AyR14yzFdJmj3v8xV3zPkU67eBDLxjPhX bILQgOwjyuUv6vchI38vgTomScCMqnUa+x7h2zA0LDyBbdNsx017dD68WdBY/f2MfpjXe4tUtYk3 QxO5hJWHrGsXij3tr8/UuHEnLuBi7gv86rVDO5w2n2MmZdqR3KaNyHpm6lPtt9370tiLgGD/+xli 4uAhOW47H7G2oFyW0ZUuMIvPBf8sp2WEtuLx/tyuuXuWutmbDzq1vsuaHY2/GCAlPkgUQUu6E2+V MJ4U9YxFNv3WmNyJq/BIDxtvUFWMUtsyoMtT5w9RbecflGuvLyOxKyWVGxi7Pfd9c25FO9+UjUdr W56QDnsFm23w4MxyHVsENJ2UYK+McJskyzT0GFQo+OKS02lgMRQNLPxlnTjQNDA3UAX/2xPy601y w9YN+5SQaXYoofXZyPXl6pcNGPNzCxS9GdhTUSh1jDJaDauCVbP+Jhl/vj2lPbR39xt698hh2G16 m1PxjctfEWotRchp2oWEmpbGiLsLxazFGvgdXtZS4f6muNVokXc/PbbOzteMvvIk8ll9fOVo2UMJ LsXhTDNbpFRx/4mFMIV2NBWp7tJ1s2jqaF1/KSyCEYeBpYswDY4hbXVs+COfIs511jmxeCqO9Xia RSkPn59UaQ/OhjC8DIi72B0QoguO/i3WFcjlmtYunc48OfbAyDCCZzmoM+tVb2jrEuoGtu25EFmk nrKTgtz2mDNoO0P9oKLYgChH/hV89G/3VCxwGh/eJn9o0BoLv55zoEWSNxmKm6zzwzzzPV9TKT6d 3zin/4wsqoM6osMXq/HAlRk556fgfYfJ5CmOAZchzjKOBgwS7Tz+ANIg5FcNCmVuZHN0cmVhbQ0K ZW5kb2JqDQoxNTIgMCBvYmoNClsgMFsgNzc4XSAgM1sgMjUwXSAgNVsgNDA4XSAgMTFbIDMzMyAz MzNdICAxNFsgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgMjc4XSAgMzRbIDQ0NCA5MjEgNzIyXSAgMzhbIDY2NyA3MjIgNjExIDU1NiA3 MjIgNzIyIDMzM10gIDQ3WyA2MTEgODg5IDcyMiA3MjIgNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjJd ICA1OFsgOTQ0XSAgNjBbIDcyMl0gIDYyWyAzMzNdICA2NFsgMzMzXSAgNjZbIDUwMF0gIDY4WyA0 NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUw MCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0XSAgMTc3WyA1MDBd IF0gDQplbmRvYmoNCjE1MyAwIG9iag0KWyAyNTAgMCA0MDggMCAwIDAgMCAwIDMzMyAzMzMgMCA1 NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCAyNzggMCAwIDAgMCA0NDQgOTIxIDcyMiAwIDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAw IDAgNjExIDg4OSA3MjIgNzIyIDU1NiA3MjIgNjY3IDU1NiA2MTEgNzIyIDAgOTQ0IDAgNzIyIDAg MzMzIDAgMzMzIDAgNTAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4 IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAg NTAwIDQ0NF0gDQplbmRvYmoNCjE1NCAwIG9iag0KWyAyNzhdIA0KZW5kb2JqDQoxNTUgMCBvYmoN ClsgMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNzIyIDAgMCAwIDAgMCAwIDAgNTU2IDAgMCAwIDAgMCAw IDUwMCA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgNDQ0IDAgNDQ0IDAgNTAwIDAg Mjc4IDAgMCAwIDcyMiA1MDAgNTAwIDUwMCAwIDM4OSAzODkgMjc4IDUwMF0gDQplbmRvYmoNCjE1 NiAwIG9iag0KPDwvVHlwZS9YUmVmL1NpemUgMTU2L1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9JbmZv IDMwIDAgUi9JRFs8MUVEMkQxMEU3MkI3NUM0Rjg4ODRFNTQzNzVGRDI1OEI+PDFFRDJEMTBFNzJC NzVDNEY4ODg0RTU0Mzc1RkQyNThCPl0gL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzU0Pj4N CnN0cmVhbQ0KeJw108dOQkEUxvHLtVfEDtKxYMOCDUWKDRAbYO+917j2Idy7cWviG/gIbl24cGtM 9A1c6OX8dRbzyyRnzswk8ymKNn5+dNpsUJQ0N/AkqGWC0QvvgulVqCkGKs0PgsUHC4JVhQnBloRv wX4nODjP2SW4PELgRQg9C+EPIWKBFLwBzaL38CnEvrSba29wK2dwDhdwCkuQDTr423epdYnr/1cZ oEIWZEIR5EA+5EIeFEIBlEEx6KEUSsAANVAB5VAFlWCEajCBFSxgBhfYwQZOcIAb6qAWGqAeWqAJ GqEZOsADrdAObdADXuiEbuiCAeiDXugHH4RgEPwQhACMwhCEYQSGYRYiMAbjEIUYJCEOCZiAaZiE KZiBFCzCPMzBAizDCqzCGuzDBqzDFmzCDmzDHuzCARzCFRzBMZxovzyZJ5FJdafR+SXFukCuEIwI oes06rRkTE1IpZq8hUdF+QWZxklLDQplbmRzdHJlYW0NCmVuZG9iag0KeHJlZg0KMCAxNTcNCjAw MDAwMDAwMzEgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAwMTI1IDAwMDAwIG4N CjAwMDAwMDAxODggMDAwMDAgbg0KMDAwMDAwMDUzMSAwMDAwMCBuDQowMDAwMDA2NDUxIDAwMDAw IG4NCjAwMDAwMDY2MzAgMDAwMDAgbg0KMDAwMDAwNjg3MyAwMDAwMCBuDQowMDAwMDA2OTI2IDAw MDAwIG4NCjAwMDAwMDcxMDAgMDAwMDAgbg0KMDAwMDAwNzMzOCAwMDAwMCBuDQowMDAwMDA3NDgx IDAwMDAwIG4NCjAwMDAwMDc1MTEgMDAwMDAgbg0KMDAwMDAwNzY4MiAwMDAwMCBuDQowMDAwMDA3 NzU2IDAwMDAwIG4NCjAwMDAwMDgwMTggMDAwMDAgbg0KMDAwMDAwODE4NyAwMDAwMCBuDQowMDAw MDA4MzQ4IDAwMDAwIG4NCjAwMDAwMDg1NzMgMDAwMDAgbg0KMDAwMDAwODc1NiAwMDAwMCBuDQow MDAwMDA5MDA2IDAwMDAwIG4NCjAwMDAwMTYwODUgMDAwMDAgbg0KMDAwMDAxNjU4OCAwMDAwMCBu DQowMDAwMDE2ODcyIDAwMDAwIG4NCjAwMDAwMTgyMDUgMDAwMDAgbg0KMDAwMDAxODI1OSAwMDAw MCBuDQowMDAwMDE4Mzk3IDAwMDAwIG4NCjAwMDAwMTg0MjcgMDAwMDAgbg0KMDAwMDAxODU5MyAw MDAwMCBuDQowMDAwMDE4NjY3IDAwMDAwIG4NCjAwMDAwMTg5MjQgMDAwMDAgbg0KMDAwMDAwMDAz MiA2NTUzNSBmDQowMDAwMDAwMDMzIDY1NTM1IGYNCjAwMDAwMDAwMzQgNjU1MzUgZg0KMDAwMDAw MDAzNSA2NTUzNSBmDQowMDAwMDAwMDM2IDY1NTM1IGYNCjAwMDAwMDAwMzcgNjU1MzUgZg0KMDAw MDAwMDAzOCA2NTUzNSBmDQowMDAwMDAwMDM5IDY1NTM1IGYNCjAwMDAwMDAwNDAgNjU1MzUgZg0K MDAwMDAwMDA0MSA2NTUzNSBmDQowMDAwMDAwMDQyIDY1NTM1IGYNCjAwMDAwMDAwNDMgNjU1MzUg Zg0KMDAwMDAwMDA0NCA2NTUzNSBmDQowMDAwMDAwMDQ1IDY1NTM1IGYNCjAwMDAwMDAwNDYgNjU1 MzUgZg0KMDAwMDAwMDA0NyA2NTUzNSBmDQowMDAwMDAwMDQ4IDY1NTM1IGYNCjAwMDAwMDAwNDkg NjU1MzUgZg0KMDAwMDAwMDA1MCA2NTUzNSBmDQowMDAwMDAwMDUxIDY1NTM1IGYNCjAwMDAwMDAw NTIgNjU1MzUgZg0KMDAwMDAwMDA1MyA2NTUzNSBmDQowMDAwMDAwMDU0IDY1NTM1IGYNCjAwMDAw MDAwNTUgNjU1MzUgZg0KMDAwMDAwMDA1NiA2NTUzNSBmDQowMDAwMDAwMDU3IDY1NTM1IGYNCjAw MDAwMDAwNTggNjU1MzUgZg0KMDAwMDAwMDA1OSA2NTUzNSBmDQowMDAwMDAwMDYwIDY1NTM1IGYN CjAwMDAwMDAwNjEgNjU1MzUgZg0KMDAwMDAwMDA2MiA2NTUzNSBmDQowMDAwMDAwMDYzIDY1NTM1 IGYNCjAwMDAwMDAwNjQgNjU1MzUgZg0KMDAwMDAwMDA2NSA2NTUzNSBmDQowMDAwMDAwMDY2IDY1 NTM1IGYNCjAwMDAwMDAwNjcgNjU1MzUgZg0KMDAwMDAwMDA2OCA2NTUzNSBmDQowMDAwMDAwMDY5 IDY1NTM1IGYNCjAwMDAwMDAwNzAgNjU1MzUgZg0KMDAwMDAwMDA3MSA2NTUzNSBmDQowMDAwMDAw MDcyIDY1NTM1IGYNCjAwMDAwMDAwNzMgNjU1MzUgZg0KMDAwMDAwMDA3NCA2NTUzNSBmDQowMDAw MDAwMDc1IDY1NTM1IGYNCjAwMDAwMDAwNzYgNjU1MzUgZg0KMDAwMDAwMDA3NyA2NTUzNSBmDQow MDAwMDAwMDc4IDY1NTM1IGYNCjAwMDAwMDAwNzkgNjU1MzUgZg0KMDAwMDAwMDA4MCA2NTUzNSBm DQowMDAwMDAwMDgxIDY1NTM1IGYNCjAwMDAwMDAwODIgNjU1MzUgZg0KMDAwMDAwMDA4MyA2NTUz NSBmDQowMDAwMDAwMDg0IDY1NTM1IGYNCjAwMDAwMDAwODUgNjU1MzUgZg0KMDAwMDAwMDA4NiA2 NTUzNSBmDQowMDAwMDAwMDg3IDY1NTM1IGYNCjAwMDAwMDAwODggNjU1MzUgZg0KMDAwMDAwMDA4 OSA2NTUzNSBmDQowMDAwMDAwMDkwIDY1NTM1IGYNCjAwMDAwMDAwOTEgNjU1MzUgZg0KMDAwMDAw MDA5MiA2NTUzNSBmDQowMDAwMDAwMDkzIDY1NTM1IGYNCjAwMDAwMDAwOTQgNjU1MzUgZg0KMDAw MDAwMDA5NSA2NTUzNSBmDQowMDAwMDAwMDk2IDY1NTM1IGYNCjAwMDAwMDAwOTcgNjU1MzUgZg0K MDAwMDAwMDA5OCA2NTUzNSBmDQowMDAwMDAwMDk5IDY1NTM1IGYNCjAwMDAwMDAxMDAgNjU1MzUg Zg0KMDAwMDAwMDEwMSA2NTUzNSBmDQowMDAwMDAwMTAyIDY1NTM1IGYNCjAwMDAwMDAxMDMgNjU1 MzUgZg0KMDAwMDAwMDEwNCA2NTUzNSBmDQowMDAwMDAwMTA1IDY1NTM1IGYNCjAwMDAwMDAxMDYg NjU1MzUgZg0KMDAwMDAwMDEwNyA2NTUzNSBmDQowMDAwMDAwMTA4IDY1NTM1IGYNCjAwMDAwMDAx MDkgNjU1MzUgZg0KMDAwMDAwMDExMCA2NTUzNSBmDQowMDAwMDAwMTExIDY1NTM1IGYNCjAwMDAw MDAxMTIgNjU1MzUgZg0KMDAwMDAwMDExMyA2NTUzNSBmDQowMDAwMDAwMTE0IDY1NTM1IGYNCjAw MDAwMDAxMTUgNjU1MzUgZg0KMDAwMDAwMDExNiA2NTUzNSBmDQowMDAwMDAwMTE3IDY1NTM1IGYN CjAwMDAwMDAxMTggNjU1MzUgZg0KMDAwMDAwMDExOSA2NTUzNSBmDQowMDAwMDAwMTIwIDY1NTM1 IGYNCjAwMDAwMDAxMjEgNjU1MzUgZg0KMDAwMDAwMDEyMiA2NTUzNSBmDQowMDAwMDAwMTIzIDY1 NTM1IGYNCjAwMDAwMDAxMjQgNjU1MzUgZg0KMDAwMDAwMDEyNSA2NTUzNSBmDQowMDAwMDAwMTI2 IDY1NTM1IGYNCjAwMDAwMDAxMjcgNjU1MzUgZg0KMDAwMDAwMDEyOCA2NTUzNSBmDQowMDAwMDAw MTI5IDY1NTM1IGYNCjAwMDAwMDAxMzAgNjU1MzUgZg0KMDAwMDAwMDEzMSA2NTUzNSBmDQowMDAw MDAwMTMyIDY1NTM1IGYNCjAwMDAwMDAxMzMgNjU1MzUgZg0KMDAwMDAwMDEzNCA2NTUzNSBmDQow MDAwMDAwMTM1IDY1NTM1IGYNCjAwMDAwMDAxMzYgNjU1MzUgZg0KMDAwMDAwMDEzNyA2NTUzNSBm DQowMDAwMDAwMTM4IDY1NTM1IGYNCjAwMDAwMDAxMzkgNjU1MzUgZg0KMDAwMDAwMDE0MCA2NTUz NSBmDQowMDAwMDAwMTQxIDY1NTM1IGYNCjAwMDAwMDAxNDIgNjU1MzUgZg0KMDAwMDAwMDE0MyA2 NTUzNSBmDQowMDAwMDAwMTQ0IDY1NTM1IGYNCjAwMDAwMDAxNDUgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDIxMDAxIDAwMDAwIG4NCjAwMDAwMjEzMDEgMDAwMDAgbg0KMDAwMDA4 MTA2NiAwMDAwMCBuDQowMDAwMDgxNDE2IDAwMDAwIG4NCjAwMDAwODE3MzUgMDAwMDAgbg0KMDAw MDA4MjAzNSAwMDAwMCBuDQowMDAwMTUxNDU3IDAwMDAwIG4NCjAwMDAxNTE4NjEgMDAwMDAgbg0K MDAwMDE1MjIwOSAwMDAwMCBuDQowMDAwMTUyMjM3IDAwMDAwIG4NCjAwMDAxNTI0NzMgMDAwMDAg bg0KdHJhaWxlcg0KPDwvU2l6ZSAxNTcvUm9vdCAxIDAgUi9JbmZvIDMwIDAgUi9JRFs8MUVEMkQx MEU3MkI3NUM0Rjg4ODRFNTQzNzVGRDI1OEI+PDFFRDJEMTBFNzJCNzVDNEY4ODg0RTU0Mzc1RkQy NThCPl0gPj4NCnN0YXJ0eHJlZg0KMTUzMDMwDQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8 PC9TaXplIDE1Ny9Sb290IDEgMCBSL0luZm8gMzAgMCBSL0lEWzwxRUQyRDEwRTcyQjc1QzRGODg4 NEU1NDM3NUZEMjU4Qj48MUVEMkQxMEU3MkI3NUM0Rjg4ODRFNTQzNzVGRDI1OEI+XSAvUHJldiAx NTMwMzAvWFJlZlN0bSAxNTI0NzM+Pg0Kc3RhcnR4cmVmDQoxNTYzMzANCiUlRU9G --_005_b4993942a5f34199810231dec9f75554TUCM03TUECSPUNICCORG_-- From nobody Mon Nov 24 12:57:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5629C1A90D7 for ; Mon, 24 Nov 2014 12:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYNgJVa-8OR8 for ; Mon, 24 Nov 2014 12:57:03 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E6F1A90C2 for ; Mon, 24 Nov 2014 12:57:02 -0800 (PST) Received: by mail-yk0-f181.google.com with SMTP id 142so4557932ykq.12 for ; Mon, 24 Nov 2014 12:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ob+yNvQZhytvLaRCHg4KzVhKznYEWlFE/czcYTpLgL0=; b=pAMB/oT496wQt85mEkiM3L60jCO6MFicQmtCfFv6ltLZmSMiwVp4VEvdaibaNkab26 A4N7k9WYPrlC75z/gLIo44ea/nvm0Ryl2bjSa1+kwJxhAUz2MVJPYXLcPDUW5vdZDN9H sNYPp3qhHF7+4AerDDp51dB6BWz/c0kjn2yj8tHJD5ipht82DAfxEUqrctu5CMVB8/Od WEWC+6DBaOBv7jqbuLZHaGKrW92bA0VGHHRwGQvCxMBAo8Lb7g3S3ZEfIdnR18yTrEUX NLJeQ0yfz9FulNYAkz+kFsYAWvP7pJa7oMBliR0y/HyAV8jZ4dT5vVpAQh62Zo6Tnypj zhQg== MIME-Version: 1.0 X-Received: by 10.170.207.5 with SMTP id y5mr22901781yke.28.1416862622209; Mon, 24 Nov 2014 12:57:02 -0800 (PST) Received: by 10.170.195.21 with HTTP; Mon, 24 Nov 2014 12:57:01 -0800 (PST) Received: by 10.170.195.21 with HTTP; Mon, 24 Nov 2014 12:57:01 -0800 (PST) In-Reply-To: <20141124182953.9C8251B004@ld9781.wdf.sap.corp> References: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com> <20141124182953.9C8251B004@ld9781.wdf.sap.corp> Date: Mon, 24 Nov 2014 12:57:01 -0800 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: multipart/alternative; boundary=001a1139638c4adc080508a109e7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8VrbH-CyYj65Brgq_IvLyIJGdXY Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 20:57:06 -0000 --001a1139638c4adc080508a109e7 Content-Type: text/plain; charset=UTF-8 On Nov 24, 2014 10:30 AM, "Martin Rex" wrote: > > Hubert Kario wrote: > > On Monday 24 November 2014 18:06:22 Martin Rex wrote: > >> Hubert Kario wrote: > >> > Anyway, you should file a complaint to the manufacturer that it haven't > >> > addressed the POODLE vulnerability in their product (or that it doesn't > >> > implement advertised protocols properly). > >> > >> Poodle is a *PURE* Web-Browser and client problem. > >> Servers are not vulnerable to Poodle, and this site *REQUIRES* > >> TLS client certs for authentication. > >> > >> Disabling SSLv3 on servers is only a practical mitigation against > >> the stupid "downgrade dance" that so many browsers perform. > >> It's difficult for me to understand how someone could implement > >> the downgrade dance and *NOT* provide a switch to turn it off after > >> addressing the rfc5746 tls renegotiation issue. > > > > To exploit POODLE you need fallback dance *or* support just SSLv3. It's not > > limited to web browsers (and there are some clients that do fallback and are > > not browsers, e.g. curl). > > > > Also, are you saying that an *automated* system won't retry on connection > > failure? > > _very_ few, if any. Exactly none of ours. > > > > > > We're talking about average of 128 failed requests per byte decrypted, > > even if we fail just every first connection on a system that queries > > remote server every 5 minutes 24/7 that will require just a month to > > decrypt 16 byte password/authentication string. There have been far > > more dedicated and longer attacks in the wild. > > You may have not understood the Problem. > > It's a plaintext recovery of 1 byte per 256 requests on average > and you can only recover the last byte of any CBC ciphertext block, > not the other 7 (3DES/IDEA) or other 15(AES). And you will need a > high probability that the secret you want to recover is at a static > position of the requests that you're attacking. > > A poodle attack will be pretty "noisy" on the server, so for many > usage scenarios, this will be sufficient deterrent, just like many > apartments have no bullet-proof windows and many doors have not > pick-proof locks. What part of "don't hack from your own machine" do you think the NSA doesn't understand? Even if you noticed the attack, and it isn't from the government, what deterrence is there? There was more law and order in the Wild West. > > > And you could add random URL-parameters or other insert additional > header fields before the credentials if you absolutely want to > keep doing disclosing authentication rather than simply switching > to using TLS client certs for the requests. > > > > > > SSLv3 has known security problems, > > more issues may be discovered in the future. > > TLS has long known weaknesses and well-documented limitations. > > When you remain within the safe usage areas, even SSLv3 is still secure. Trivial statement is trivial. What are the safe use areas exactly? > > Really, what we should worry about is the current usage scenarios > where even TLSv1.2 can not provide protection, and one of these > is Cross-Site-Request-Forgery as currently offered by Web-Browsers. > > > > > > So while use of certificates may mitigate this problem, we may not > > ever know if it mitigates all problems SSLv3 has. > > I'm not expecting any. Honestly. > > > > > > For example, issues like 3-shake won't be fixed in SSLv3. > > I never offered TLS renegotiation to applications in our implementation, > and I hardwired it to a fatal alert on the server in 2010. > > Conservative designs don't have to care about 3-shake. Why does a protocol like TLS have options to shoot yourself in the foot? Also, I seem to recall quite a bit of discussion of how renegotiation was a simple and elegant feature when the suggestion to remove it was made. I suppose it is when you hardwire it to fail. Conservative protocol designs minimize options and ensure that the easiest option is the secure one. They stress simplicity of implementation to ease auditing implementations, and thus are codesigned with an implementation. Features are bugs. > > There are several more implementation pitfalls hidden in the > TLS renegotiation design. Care to share? Or when these are exploited widely, will you insist they were well-understood limitations? > > > > > > In my opinion, continued use of it for security-critical applications > > qualifies for gross negligence. > > Nope. Continued offering of SSLv3-only is the problem here. > The original SSLv3 and TLS design protects the security parameters > of the TLS handshake, so a TLSv1.0 capable client that does not > send ClientHello.client_version = { 3,1 } (or can be coerced to not > signale TLSv1.0 support by a network-based attacker) is the problem. > > > > > > Do we really need the repeat of the MD5 signatures story or can we learn on > > our own (as in industry) mistakes? > > > It would already be an improvement if the TLS WG stopped (mostly) ignoring > problems (such as Vaudenay's), or didn't add new problems (such as > making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm). And by depreciating a protocol version that doesn't use a secure record layer because of Vaudenay's attack we are responding to the problem. Vaudenay's padding oracle is exploited in Lucky 13. Any response is going to involve depreciating protocols because of well-understood limitations. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --001a1139638c4adc080508a109e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 24, 2014 10:30 AM, "Martin Rex" <mrex@sap.com> wrote:
>
> Hubert Kario wrote:
> > On Monday 24 November 2014 18:06:22 Martin Rex wrote:
> >> Hubert Kario wrote:
> >> > Anyway, you should file a complaint to the manufacturer = that it haven't
> >> > addressed the POODLE vulnerability in their product (or = that it doesn't
> >> > implement advertised protocols properly).
> >>
> >> Poodle is a *PURE* Web-Browser and client problem.
> >> Servers are not vulnerable to Poodle, and this site *REQUIRES= *
> >> TLS client certs for authentication.
> >>
> >> Disabling SSLv3 on servers is only a practical mitigation aga= inst
> >> the stupid "downgrade dance" that so many browsers = perform.
> >> It's difficult for me to understand how someone could imp= lement
> >> the downgrade dance and *NOT* provide a switch to turn it off= after
> >> addressing the rfc5746 tls renegotiation issue.
> >
> > To exploit POODLE you need fallback dance *or* support just SSLv3= . It's not
> > limited to web browsers (and there are some clients that do fallb= ack and are
> > not browsers, e.g. curl).
> >
> > Also, are you saying that an *automated* system won't retry o= n connection
> > failure?
>
> _very_ few, if any.=C2=A0 Exactly none of ours.
>
>
> >
> > We're talking about average of 128 failed requests per byte d= ecrypted,
> > even if we fail just every first connection on a system that quer= ies
> > remote server every 5 minutes 24/7 that will require just a month= to
> > decrypt 16 byte password/authentication string. There have been f= ar
> > more dedicated and longer attacks in the wild.
>
> You may have not understood the Problem.
>
> It's a plaintext recovery of 1 byte per 256 requests on average > and you can only recover the last byte of any CBC ciphertext block, > not the other 7 (3DES/IDEA) or other 15(AES).=C2=A0 And you will need = a
> high probability that the secret you want to recover is at a static > position of the requests that you're attacking.
>
> A poodle attack will be pretty "noisy" on the server, so for= many
> usage scenarios, this will be sufficient deterrent, just like many
> apartments have no bullet-proof windows and many doors have not
> pick-proof locks.

What part of "don't hack from your own machine"= ; do you think the NSA doesn't understand? Even if you noticed the atta= ck, and it isn't from the government,=C2=A0 what deterrence is there? T= here was more law and order in the Wild West.

>
>
> And you could add random URL-parameters or other insert additional
> header fields before the credentials if you absolutely want to
> keep doing disclosing authentication rather than simply switching
> to using TLS client certs for the requests.
>
>
> >
> > SSLv3 has known security problems,
> > more issues may be discovered in the future.
>
> TLS has long known weaknesses and well-documented limitations.
>
> When you remain within the safe usage areas, even SSLv3 is still secur= e.

Trivial statement is trivial. What are the safe use areas ex= actly?

>
> Really, what we should worry about is the current usage scenarios
> where even TLSv1.2 can not provide protection, and one of these
> is Cross-Site-Request-Forgery as currently offered by Web-Browsers. >
>
> >
> > So while use of certificates may mitigate this problem, we may no= t
> > ever know if it mitigates all problems SSLv3 has.
>
> I'm not expecting any. Honestly.
>
>
> >
> > For example, issues like 3-shake won't be fixed in SSLv3.
>
> I never offered TLS renegotiation to applications in our implementatio= n,
> and I hardwired it to a fatal alert on the server in 2010.
>
> Conservative designs don't have to care about 3-shake.

Why does a protocol like TLS have options to shoot yourself = in the foot? Also, I seem to recall quite a bit of discussion of how renego= tiation was a simple and elegant feature when the suggestion to remove it w= as made. I suppose it is when you hardwire it to fail.

Conservative protocol designs minimize options and ensure th= at the easiest option is the secure one. They stress simplicity of implemen= tation to ease auditing implementations, and thus are codesigned with an im= plementation.=C2=A0 Features are bugs.

>
> There are several more implementation pitfalls hidden in the
> TLS renegotiation design.

Care to share? Or when these are exploited widely, will you = insist they were well-understood limitations?

>
>
> >
> > In my opinion, continued use of it for security-critical applicat= ions
> > qualifies for gross negligence.
>
> Nope.=C2=A0 Continued offering of SSLv3-only is the problem here.
> The original SSLv3 and TLS design protects the security parameters
> of the TLS handshake, so a TLSv1.0 capable client that does not
> send ClientHello.client_version =3D { 3,1 } (or can be coerced to not<= br> > signale TLSv1.0 support by a network-based attacker) is the problem. >
>
> >
> > Do we really need the repeat of the MD5 signatures story or can w= e learn on
> > our own (as in industry) mistakes?
>
>
> It would already be an improvement if the TLS WG stopped (mostly) igno= ring
> problems (such as Vaudenay's), or didn't add new problems (suc= h as
> making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm)= .

And by depreciating a protocol version that doesn't use = a secure record layer because of Vaudenay's attack we are responding to= the problem. Vaudenay's padding oracle is exploited in Lucky 13. Any r= esponse is going to involve depreciating protocols because of well-understo= od limitations.

Sincerely,
Watson Ladd

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
>TLS@ietf.org
>https://www.ietf.= org/mailman/listinfo/tls

--001a1139638c4adc080508a109e7-- From nobody Mon Nov 24 13:31:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8971AC39C for ; Mon, 24 Nov 2014 13:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CohE3gc2O7Ez for ; Mon, 24 Nov 2014 13:31:06 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 909381AC3BC for ; Mon, 24 Nov 2014 13:30:55 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 5749D67C06E; Mon, 24 Nov 2014 13:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=j0fih5VNx6Ha3q 22S8JvWobzJDY=; b=CeVqjyp2isNCMNyv22v0toaGu8srAYdofpW4I4IlDrlcIp o5eJPGozEd/k5ktlyuwgX43hjBZ4B9sXTClx8CrMWXarhaPnFKeDs236H2HIRc29 cSAj1jn7bM37iHmI7+rJiGdGvund5VYYsr/oLXEfvKZmU+WBga4USINtMripw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id 04E1367C06D; Mon, 24 Nov 2014 13:30:54 -0800 (PST) Date: Mon, 24 Nov 2014 15:30:54 -0600 From: Nico Williams To: Watson Ladd Message-ID: <20141124213052.GR3200@localhost> References: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com> <20141124182953.9C8251B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6SdQbHiBOYub_25KKZUhaobPxG0 Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 21:31:08 -0000 On Mon, Nov 24, 2014 at 12:57:01PM -0800, Watson Ladd wrote: > On Nov 24, 2014 10:30 AM, "Martin Rex" wrote: > [...]? Even if you noticed the attack, and it isn't from the > government, what deterrence is there? [...] And/or what mitigation... Bearer tokens are currently, and for the forseeable future, a fact of life. An annoying fact of life, maybe, but one that we must accept. Surely that can't be controversial. TLS 1.3 simply must be resistant to adaptive chosen plaintext attacks intended for recovery of frequently repeated secrets (bearer tokens). To be fair to Martin R., I suspect he's not objecting to this, so much as to the use of bearer tokens in the first place, much as I'm objecting to blaming TLS's past failures on the Internet threat model while... not being against updating the Internet threat model. That we can't fix the bearer token problem from where we stand doesn't mean that Martin can't complain about it... Nico -- From nobody Mon Nov 24 14:16:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EEF1A6EFB for ; Mon, 24 Nov 2014 14:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FczblnsI0Yzv for ; Mon, 24 Nov 2014 14:16:16 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.93.82.23]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF1F1A0673 for ; Mon, 24 Nov 2014 14:16:15 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 376AB2342EC8B; Mon, 24 Nov 2014 16:16:15 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 251DB2342EBF3 for ; Mon, 24 Nov 2014 16:16:15 -0600 (CST) Received: from [96.231.218.201] (port=52736 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xt1va-0000UF-Br; Mon, 24 Nov 2014 16:16:14 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Mon, 24 Nov 2014 17:16:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C12F3BB-4376-4056-AD4C-04C189575593@ieca.com> References: <54A8F330-D25A-40FF-81BF-7CA35C69343C@ieca.com> To: Hugo Krawczyk X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1Xt1va-0000UF-Br X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:52736 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oYq2WBDjEcNeObWTXGDyCV_Afd0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Paris Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 22:16:17 -0000 I updated interim minutes to incorporate your changes. spt On Nov 06, 2014, at 04:51, Hugo Krawczyk wrote: > Let me also clarify the following point from the minutes: >=20 > > The construct presented by Hugo was from the SKEME paper published = in '91: http://webee.technion.ac.il/~hugo/skeme-lncs.ps >=20 > I referred to the paper when answering the question of whether this is = a new design. I said that a similar design goes back to the above paper = (from NDSS'96 not 91) which had actually many of the same motivations = than the current proposal (PFS, identity protection, a uniform treatment = of pre-shared key and re-key, etc). On the other hands, there are some = significant differences in the new proposal such as the support of 0-RTT = and server-only authentication. In cryptography little changes can = introduce vulnerabilities so OPTLS needs to be considered as a new = design for the sake of analysis (and there are important details to be = nailed down, especially the key derivation definitions). >=20 > Hugo >=20 >=20 > On Thu, Nov 6, 2014 at 1:06 AM, Sean Turner wrote: > On Nov 05, 2014, at 09:56, Bodo Moeller wrote: >=20 > > Adam Langley : > > On Wed, Nov 5, 2014 at 4:49 AM, Bodo Moeller = wrote: > > > > > This isn't correct, and isn't what was said at the meeting. As = discussed at > > > the meeting, YouTube currently allows two cipher suites for video = streams, > > > TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but = Firefox > > > doesn't support the former without ECDHE > > > (https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179). > > > > Some locations additionally support ECDHE_RSA_AES_128_GCM_SHA256, > > which we are testing now. > > > > Yes, but the above is about correcting the 2014-10-21 minutes, not = updating them to reflect the current status. > > > > Bodo >=20 > I=92ll make sure these get updated. >=20 > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Mon Nov 24 14:29:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808E21A86E6 for ; Mon, 24 Nov 2014 14:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vRHSyvPxZVU for ; Mon, 24 Nov 2014 14:29:45 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864FB1A7D80 for ; Mon, 24 Nov 2014 14:29:45 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so7268575wiw.14 for ; Mon, 24 Nov 2014 14:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LEz/pacdl9w1u3DA25uT6Dp7mZJYn0X7DWk7kdJaLe0=; b=THwyhFeEVGlrR3OJJk75FsxGpmyDp0cz0UE+og+EwMLiTlRv2Dxgv7wkLnP4k6xOqU 8MSUVbyzQh+222uds48K06JU6YgY7NR5AMLMuEhMwgEogLqm3UabfrW5BqgyVWrlJLeN Z0hauYTGoeSQqQPSNZF3Qaz05cFZr69XRJt373yulzkJ+2i6v4LSpn8+IRsZVoEN7ww1 yVoL6YCmmabkGJS5mV+qswxQ/ME1Jl2eP0z2KU+6MOL7DIHkUss9MhF3nfwK090+Fgcn XuzYCWwdaAv8FMM3kZpgeMwpQEGriBYxEHsvRGeT4BoDf/V4bRy0tq3Mr6L7UPK0rXpI Md7g== X-Received: by 10.194.77.233 with SMTP id v9mr37714715wjw.24.1416868184303; Mon, 24 Nov 2014 14:29:44 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-228-139-23.inter.net.il. [84.228.139.23]) by mx.google.com with ESMTPSA id hs1sm13900082wib.1.2014.11.24.14.29.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 14:29:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <20141124213052.GR3200@localhost> Date: Tue, 25 Nov 2014 00:29:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88D3820D-E509-40E0-AF12-E8B82A9708B3@gmail.com> References: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com> <20141124182953.9C8251B004@ld9781.wdf.sap.corp> <20141124213052.GR3200@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JT8ak64-MM6YhFH7kG-GYD6R-i4 Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 22:29:47 -0000 > On Nov 24, 2014, at 11:30 PM, Nico Williams = wrote: > ] > To be fair to Martin R., I suspect he's not objecting to this, so much > as to the use of bearer tokens in the first place,=20 I don=E2=80=99t know about Martin, but the thing that bothers me most = about cookies is not that they=E2=80=99re bearer tokens or that = they=E2=80=99re a lucrative target for attacks, but the fact that they = can freely be used by attackers. CRIME, BEAST, POODLE, they all depend on my browser going to = http://www.attacker.com, and then a script loaded from that site running = on the browser, sending requests to Facebook and google and the like = with *my* cookies. For some reason these requests are treated as if they = come from *me* rather than the attacker. They call it CSRF, but it=E2=80=99= s not really forgery. It=E2=80=99s just the way the web is built. If I had to choose between =E2=80=9Cnew cookie=E2=80=9D that is not a = bearer token but is somehow bound to session or origin and a =E2=80=9Cnew = cookie=E2=80=9D that is scoped so that only scripts loaded from = *.google.com can use my google.com cookie while other scripts send = unauthenticated requests, I=E2=80=99d choose the scoping. Yoav From nobody Mon Nov 24 14:44:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE541A6FB7 for ; Mon, 24 Nov 2014 14:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_YKjheCtjSg for ; Mon, 24 Nov 2014 14:44:33 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id C9F4F1A0250 for ; Mon, 24 Nov 2014 14:44:33 -0800 (PST) Received: from [173.75.83.153] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Xt2Mt-0006zV-EE; Mon, 24 Nov 2014 17:44:27 -0500 Date: Mon, 24 Nov 2014 14:44:22 -0800 From: Bill Frantz To: Yoav Nir X-Priority: 3 In-Reply-To: <88D3820D-E509-40E0-AF12-E8B82A9708B3@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c4f73377754e87dc219159f9d4b9e9ea350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.153 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d17acUxeMbNRD5Jm9QMqPQWxmz4 Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 22:44:35 -0000 On 11/25/14 at 2:29 PM, ynir.ietf@gmail.com (Yoav Nir) wrote: >If I had to choose between =E2=80=9Cnew cookie=E2=80=9D that is not a=20 >bearer token but is somehow bound to session or origin and a=20 >=E2=80=9Cnew cookie=E2=80=9D that is scoped so that only scripts loaded=20 >from *.google.com can use my google.com cookie while other=20 >scripts send unauthenticated requests, I=E2=80=99d choose the scoping. That scoping is approaching a capability system. If the=20 authority and the object which recognizes that authority are=20 bound together in one reference, then you have a capability. The=20 closest we get to capabilities on the web are OATH tokens and=20 URLs with "unguessable" strings. A good capability system allows references to be transferred=20 between people/programs to allow rich sharing=20 . Rich sharing can greatly=20 reduce the incentive to share usernames and passwords. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | I don't have high-speed | Periwinkle (408)356-8506 | internet. I have DSL. | 16345=20 Englewood Ave www.pwpconsult.com | | Los Gatos,=20 CA 95032 From nobody Mon Nov 24 14:45:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0982E1A6EFB for ; Mon, 24 Nov 2014 14:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GitEoVy9Vz5O for ; Mon, 24 Nov 2014 14:45:06 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C9E5B1A89F0 for ; Mon, 24 Nov 2014 14:45:06 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id A6A5E1DE070; Mon, 24 Nov 2014 14:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=qNAXWnSoE90v6KlAror9eTEQDoI=; b=bRTQ6dGMheY 7mkGdvkJo2M9KvgVbezfyGL/VedKN2An5oBT1drIcakaBkAor/Ee+OS0rE0Yc1Qu 8eF8KDt9ZuAryMxIDuUXqZC04RQF4/YsGike+3Bb2AXS+b/DrFTrgFHELF/Xz70p 1Bn/Ti5B6He5oX3d0PiYc8Dk3bZoqbYE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 4A9901DE059; Mon, 24 Nov 2014 14:45:06 -0800 (PST) Date: Mon, 24 Nov 2014 16:45:05 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20141124224504.GS3200@localhost> References: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com> <20141124182953.9C8251B004@ld9781.wdf.sap.corp> <20141124213052.GR3200@localhost> <88D3820D-E509-40E0-AF12-E8B82A9708B3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <88D3820D-E509-40E0-AF12-E8B82A9708B3@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uC5A4CZ0hrL213hY_7Z7k1DSMDs Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 22:45:08 -0000 On Tue, Nov 25, 2014 at 12:29:41AM +0200, Yoav Nir wrote: > I don=E2=80=99t know about Martin, but the thing that bothers me most a= bout > cookies is not that they=E2=80=99re bearer tokens or that they=E2=80=99= re a lucrative > target for attacks, but the fact that they can freely be used by > attackers. >=20 > CRIME, BEAST, POODLE, they all depend on my browser going to > http://www.attacker.com, and then a script loaded from that site > running on the browser, sending requests to Facebook and google and > the like with *my* cookies. For some reason these requests are treated > as if they come from *me* rather than the attacker. They call it CSRF, > but it=E2=80=99s not really forgery. It=E2=80=99s just the way the web = is built. Oh sure, and I agree fully, we could totally have a bash-the-web- security-model thread :) but we can't really do anything about it from TLS WG. > If I had to choose between =E2=80=9Cnew cookie=E2=80=9D that is not a b= earer token but > is somehow bound to session or origin and a =E2=80=9Cnew cookie=E2=80=9D= that is > scoped so that only scripts loaded from *.google.com can use my And DOM elements (but I repeat what you said). > google.com cookie while other scripts send unauthenticated requests, > I=E2=80=99d choose the scoping. +1e6. After all, we can improve TLS's protection to bearer tokens, but we can't really help the web security model much more than that from here (here =3D=3D TLS). Nico --=20 From nobody Mon Nov 24 16:04:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976E71A8A72 for ; Mon, 24 Nov 2014 16:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuB4M42321uE for ; Mon, 24 Nov 2014 16:04:06 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8577D1A89B5 for ; Mon, 24 Nov 2014 16:04:06 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id w7so8291514lbi.5 for ; Mon, 24 Nov 2014 16:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uHr5ZGdhbja3enbkj+mRqPAFSvgnyT7k2eIqddnCTUo=; b=EHhiF3810+dF77Gb+dXtmjUN14dX6hCL9OAfRL71qPbxxTEG2lcH1hEf7+UGhTZKA7 mI2ITj4618k8Seu+UwlFJLvreSUGSsdXEBtrBKpIMQFA8RnlaylXRBAFLaKDuYnqsm/v BaEnUptVtGitcHuMpN6mfXJF+aMzgdfNwoXpx642xczzIFcp8WzWp1hctN6fURQGmZnB JGKMK0+TNLKxhwTqU+XqM4Xh2QlaTnYwlw51yzZa9m8YqPG0i23xRwjOKWX+R7WCV+2n YR1wIVz1xGaUWn1sJ9qb827ndvndIlkTuV625F9fqOpm/OlKNJ5D//GllnskG7v0klT7 o3fg== X-Received: by 10.112.254.162 with SMTP id aj2mr23482097lbd.70.1416873844900; Mon, 24 Nov 2014 16:04:04 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.135 with HTTP; Mon, 24 Nov 2014 16:03:34 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Mon, 24 Nov 2014 19:03:34 -0500 X-Google-Sender-Auth: 7pMP8vgpWCU9UR7l0094ibsRDKo Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a113462be378aef0508a3a616 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wNjh5toX9tBw8tE4JdxkTTMxWOY Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 00:04:09 -0000 --001a113462be378aef0508a3a616 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 22, 2014 at 12:19 PM, Adam Langley wrote: > On Fri, Nov 21, 2014 at 11:23 PM, Watson Ladd > wrote: > > Not requiring online signatures is a win for performance for users > > with RSA certificates. The current draft has very similar performance. > > There is at least one data-point when it comes to "delegation" > signatures: it's what QUIC does[1] (with its own message format and > embedded expiry) and Google is perfectly happy with deploying QUIC. > > [1] > https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDw= vZ5L6g/edit#heading=3Dh.bzxklo2i5w6k > > > =E2=80=8BQUIC was indeed a main motivation to build 0-RTT into OPTLS. I am glad to hear that the "delegation" approach works for you. =E2=80=8B > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113462be378aef0508a3a616 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 22, 2014 at 12:19 PM, Adam Langley <= agl@imperialviolet.org> wrote:
On Fri, Nov 21, 2014 at 11:23 PM, Watson Ladd <watsonbladd@gmail.com> w= rote:
> Not requiring online signatures is a win for performance for users
> with RSA certificates. The current draft has very similar performance.=

There is at least one data-point when it comes to "delegation&q= uot;
signatures: it's what QUIC does[1] (with its own message format and
embedded expiry) and Google is perfectly happy with deploying QUIC.

[1] https:= //docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/e= dit#heading=3Dh.bzxklo2i5w6k



=E2=80=8BQUIC was indee= d a main motivation to build 0-RTT into OPTLS.
I am glad to hear that the "delegation" approach works for= you.

=E2=80=8B
=C2=A0
Cheers

AGL

--
Adam Langley ag= l@imperialviolet.org https://www.imperialviolet.org

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a113462be378aef0508a3a616-- From nobody Mon Nov 24 16:06:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC71A89F5 for ; Mon, 24 Nov 2014 16:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRSGwKxzwN5w for ; Mon, 24 Nov 2014 16:06:51 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44F61A89B5 for ; Mon, 24 Nov 2014 16:06:49 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so2607922lbi.2 for ; Mon, 24 Nov 2014 16:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sGpW3wR7kcT4alynrEX2+Qf3xlHfqPInmIap71W/ZwQ=; b=GXRDbimMh5AnSiNx+XmIYEeSn65riIUBu1pofe//tALF1hSHrz3iWKCu1rFwzWkxUA bnMionQ3nXurE8x/PpRH46bCvGosaDE6fLdIMDsXJOQHp5kCyEgO90oNzew/FwCqbv+k X9WasfgMs6txW9Mm5Is3nJJSnm0LUGUfDPiNMPgyHZWGH5AphvCKiTDdnEJvbW5eCuXy wyOE8bye7pRyp5/X6i9Auq/gnhi08ZQpqWJ5L2R9jgnQubzjM8NXJuw1Nk6PL7nCE4YT 7ckW5ZeymyU3YJqDn+cIX+LxlLnBs07DHSDsdG2fNCKI/tNTBOPokLNVeMGUP3vGBDEz OQ5A== X-Received: by 10.152.23.9 with SMTP id i9mr1449168laf.81.1416874008260; Mon, 24 Nov 2014 16:06:48 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.135 with HTTP; Mon, 24 Nov 2014 16:06:18 -0800 (PST) In-Reply-To: <20141124063304.GA3200@localhost> References: <20141124063304.GA3200@localhost> From: Hugo Krawczyk Date: Mon, 24 Nov 2014 19:06:18 -0500 X-Google-Sender-Auth: Mo0wrzZrwFNuAfg92OTXgmGMgGQ Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=089e0160b870f437190508a3afa6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9EQUc_sv25g8IuKK3H5aZ_v7FgY Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 00:06:52 -0000 --089e0160b870f437190508a3afa6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 24, 2014 at 1:33 AM, Nico Williams wrote: > > I'm in favor of using static server (EC)DH keys for server > authentication and possible 0-RTT, particularly in connection > with DANE. > > I *don't* think that OPTLS is worthwhile without connection to DANE, but > only because OPTLS is just an optimization with roughly the same > applicability as an existing optimization that is much faster: session > resumption [with encrypted session state tickets]. > =E2=80=8BSession resumption is indeed faster if you don't do PFS - otherwis= e it is still faster but not by much. And of course, as I'm sure you agree, there are 0-RTT scenarios that cannot be reduced to session resumption as in the QUIC case mentioned by AGL or any setting where keeping a shared secret state at the client is not practical. Hugo =E2=80=8B > > But since I think sprinkling DANE on is the obvious thing to do given > OPTLS as part of the protocol, I'm in favor. > > Security-wise the use of static (EC)DH keys is well-understood (as well > understood as (EC)DH is in general). > > The g^xs plus (not the arithmetic operator) g^xy method of obtaining PFS > is also OK, and heck, if need be the client could use two different x's, > and the protocol ought to allow it (not least because the client might > want to use different groups/ curves for PFS key agreement than for > authentication key agreement). > > Nico > -- > --089e0160b870f437190508a3afa6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 24, 2014 at 1:33 AM, Nico Williams <n= ico@cryptonector.com> wrote:
=E2=80=8BSession resumption is indeed faster if = you don't do PFS - otherwise it is still faster but not by much.
And of course, as I'm sure you agree, ther= e are 0-RTT scenarios that cannot be=C2=A0 reduced to session resumption as= in the QUIC case mentioned by AGL or any setting where keeping a shared se= cret state at the client is not practical.

Hugo
=E2=80=8B

But since I think sprinkling DANE on is the obvious thing to do given
OPTLS as part of the protocol, I'm in favor.

Security-wise the use of static (EC)DH keys is well-understood (as well
understood as (EC)DH is in general).

The g^xs plus (not the arithmetic operator) g^xy method of obtaining PFS is also OK, and heck, if need be the client could use two different x's= ,
and the protocol ought to allow it (not least because the client might
want to use different groups/ curves for PFS key agreement than for
authentication key agreement).

Nico
--

--089e0160b870f437190508a3afa6-- From nobody Mon Nov 24 19:49:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347B31A1B8C for ; Mon, 24 Nov 2014 19:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFfiT5lI_P7l for ; Mon, 24 Nov 2014 19:49:18 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6D28B1A1B8A for ; Mon, 24 Nov 2014 19:49:18 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 34A691B4058; Mon, 24 Nov 2014 19:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=6MDFF8BRgDPszV +SUF4b8//IIxU=; b=nYiZR93QqIhzUT8lG51PFWRcPxXWBrfe6TiwyHbqRBI1pG TWZ5Jl1v/iR4GJ+VuJ89mGbAEMP4/WRQqZsAUlRyc69hijlzPRHxW9udDpLbNC7h poOd4gmXHionfTa3ieYJRvz+9SrUxt4C5a5AbzUhwB55bltyPfmRFHHWI9nN8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id D72121B4057; Mon, 24 Nov 2014 19:49:17 -0800 (PST) Date: Mon, 24 Nov 2014 21:49:17 -0600 From: Nico Williams To: Hugo Krawczyk Message-ID: <20141125034915.GT3200@localhost> References: <20141124063304.GA3200@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3oj3mOI4Q_qAXU4DOnnr0fMDekM Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 03:49:19 -0000 On Mon, Nov 24, 2014 at 07:06:18PM -0500, Hugo Krawczyk wrote: > On Mon, Nov 24, 2014 at 1:33 AM, Nico Williams > wrote: > > I'm in favor of using static server (EC)DH keys for server > > authentication and possible 0-RTT, particularly in connection > > with DANE. > > > > I *don't* think that OPTLS is worthwhile without connection to DANE, but > > only because OPTLS is just an optimization with roughly the same > > applicability as an existing optimization that is much faster: session > > resumption [with encrypted session state tickets]. > > > > Session resumption is indeed faster if you don't do PFS - otherwise it is > still faster but not by much. If one wants half-PFS (foward security relative only to client compromise) including for 0-RTT data then OPTLS wins every time. > And of course, as I'm sure you agree, there are 0-RTT scenarios that cannot > be reduced to session resumption as in the QUIC case mentioned by AGL or > any setting where keeping a shared secret state at the client is not > practical. Hmm, a client that can't keep a shared secret around probably can't keep a server sub-cert either... Nor reuse its ECDH keys (which the QUIC doc linked by AGL talks about in conjunction with caches of shared keys, which then is a lot like resumption). A client that can't keep state could use DANE though, and thus get 0-RTT with half-PFS every time. Of course, it's all about relative numbers: how long a client is willing to go without using new keys for PFS (relative to client compromise), how frequently it connects to the same server, and how long the server is willing to go without using new keys for PFS (relative to server compromise). That the client is more sensitive about PFS than the server makes some sense. (Shouldn't we really speak of PFS relative to compromise of each peer? After all, they can't really prove that the other peer isn't reusing PKs, not spending without extra effort monitoring for reuse.) Nico -- From nobody Mon Nov 24 22:55:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A941A0015 for ; Mon, 24 Nov 2014 22:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojI0g4TH_8NP for ; Mon, 24 Nov 2014 22:55:31 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F1C1A0008 for ; Mon, 24 Nov 2014 22:55:31 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id gd6so8877379lab.5 for ; Mon, 24 Nov 2014 22:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=D7PeUb3EWfixGpwGPV30/pVUOD63i2y7PpFucDP8rCA=; b=Zx+fVgQSiU8pnpi5m8Vs4+I7dJKRV4uv5r2hfPkz0dOWB37u+amhxbW+6+bZ3xjmGR GFznNAb/BCR4Pci+pJ3RLbGroP7nfQ8KhJvoRvF1OLV3hqRpVwTqltEb/WaFjptmj8Zl P7UcE5SP5B/PiAwxaTfwHb6917n17TfOexbpztjsCBZwrMBrf8XAw4iKnmIJoAVNRBuy tZXMCrepOF8Or7Gl7+tXGLOYhGibWhN4sprS+Crr3Di0RPGyxxPUBAs3Fb6wBdneT+Lq UWRKCZrrWBULeIwpbLQQd+/m3ubOkTbdm/rhl3997Qz4Pa4Ox5BwZV2+1j/adAF/+Tpv rTMg== MIME-Version: 1.0 X-Received: by 10.112.150.71 with SMTP id ug7mr24394223lbb.73.1416898529645; Mon, 24 Nov 2014 22:55:29 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Mon, 24 Nov 2014 22:55:29 -0800 (PST) Date: Mon, 24 Nov 2014 22:55:29 -0800 X-Google-Sender-Auth: kyfRb_Yt1XS72l1sWyZeZac75No Message-ID: From: Adam Langley To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kNHaCbvPbc7WQbdaqH3r5Kd4UpE Subject: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 06:55:33 -0000 I generally recommend that, whenever signing a message, a NUL-terminated, ASCII context string is prepended to the message to ensure that the verifier isn't confused about the context. (NUL-terminated, ASCII strings have the property that none is a prefix of any other.) I think that TLS 1.3 provides a good demonstration of why: Mavrogiannopoulos, Vercauteren, Velichkov and Preneel[1] showed a near-miss in the design of TLS <= 1.2 due to a lack of context in ServerKeyExchange messages resulting in an ambiguity about whether a specific message was DHE or ECDHE. TLS 1.3 has the server return a CertificateVerify message[2] that signs the handshake so far, similar to TLS <= 1.2's message of the same name. However, consider a client that implements any version of TLS and a server that implements TLS 1.3: An attacker watches for the ClientHello from the client. Assume, as is quite common now, that the client generates its client_random with 32 random bytes (i.e. there's no timestamp). With probability 2^-32, the client_random will start with 0x0100 and bytes 4 and 5 will be 0x03 and 0x04. The attacker now connects to the TLS 1.3 server and sends a ClientHello such that the prefix of the message (including handshake message type and length) is equal to the victim client's client_random value. (Most of the bytes can be put into the attacker's client_random value and the restriction on the victim client's message ensures that the handshake type, length and protocol version are taken care of.) With the rest of the ClientHello, the attacker is free to make the TLS 1.3 handshake look like a TLS 1.2 ServerKeyExchange message. An obvious choice is to stuff a dummy server_random into the session ID and specify a small p and g such that a discrete-log is easy, then consume the rest of the handshake with a huge Y. (The length of the TLS 1.3 handshake from the server is predictable.) Some clients might check that Y < p but, if they do the obvious thing, then the TLS 1.3 server's signature over the handshake can be used as a TLS 1.2 ServerKeyExchange signature and the client compromised. I may have missed something and, even if not, the restrictions on the client's client_random value make it an expensive attack to pull off. But it's still another near-miss. Thus I suggest that signed messages in TLS 1.3 be prefixed with context strings. For example, "TLS 1.3 CertificateVerify message from server\x00" in this case. However, since TLS <= 1.2 provides an attacker the ability to get a signature for a message with a 32-byte, chosen prefix via the ServerKeyExchange, I additionally suggest that the context string start with 48-64 bytes of "PADTLS" repeated, in order to clear that prefix and cover part or all of the server_random. (And that signature oracle in TLS <= 1.2 provides another reason, should any be needed, not to run a CA:TRUE certificate on a server.) [1] https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf [2] https://tlswg.github.io/tls13-spec/#rfc.section.7.4.7 [3] https://tools.ietf.org/html/rfc5246#section-7.4.1.2 [4] https://tools.ietf.org/html/rfc5246#section-7.4.3 Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Nov 25 01:01:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFDD1A006E for ; Tue, 25 Nov 2014 01:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9puEhpHV0WeA for ; Tue, 25 Nov 2014 01:01:53 -0800 (PST) Received: from vsp2.ballou.se (vsp2.ballou.se [91.189.40.83]) by ietfa.amsl.com (Postfix) with SMTP id 6FD941A006F for ; Tue, 25 Nov 2014 01:01:49 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp2.ballou.se (Halon Mail Gateway) with ESMTP for ; Tue, 25 Nov 2014 10:01:05 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 109B31DE8D for ; Tue, 25 Nov 2014 10:01:05 +0100 (CET) Message-ID: <54744542.1070705@streamsec.se> Date: Tue, 25 Nov 2014 10:00:50 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com> <20141124182953.9C8251B004@ld9781.wdf.sap.corp> <20141124213052.GR3200@localhost> <88D3820D-E509-40E0-AF12-E8B82A9708B3@gmail.com> <20141124224504.GS3200@localhost> In-Reply-To: <20141124224504.GS3200@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V_JjexT1q7RMvK-6ocj3EzEWWhQ Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 09:01:56 -0000 On 2014-11-24 23:45, Nico Williams wrote: >> CRIME, BEAST, POODLE, they all depend on my browser going to >> http://www.attacker.com, and then a script loaded from that site >> running on the browser, sending requests to Facebook and google and >> the like with *my* cookies. For some reason these requests are treated >> as if they come from *me* rather than the attacker. They call it CSRF, >> but it’s not really forgery. It’s just the way the web is built. > > Oh sure, and I agree fully, we could totally have a bash-the-web- > security-model thread :) but we can't really do anything about it from > TLS WG. The TLS WG might define a formal threat model that can be backed up by both, on one hand, the cryptographic protocol design, and, on the other hand, the security analysis section of the main RFCs that outline correct usage in layman's terms. Obviously there SHOULD be a straight logical connection between the cryptographic design, the formal threat model and the security analysis sections. Otherwise TLS is broken. Conversely, if TLS WG does this and browsers violate the implementation instructions in the security analysis section, the browsers are broken. In such a scenario some browser manufacturers and website publishers would probably fix the errors at the expense of some interoperability issues and some functionality loss, while others would ignore the issues. The point is, that it is hard to justify that the TLS WG should output standards that are not based on a coherent security analysis, just because sites like Facebook, Google, EBay, PayPal etc, have a vested interest in letting third party web publishers distribute fourth party javascript that logs in to their servers with the credentials of the client users, and claim this is "secure" just because it is done over HTTPS and not in direct conflict with the explicit recommendations of the TLS WG. From nobody Tue Nov 25 02:15:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3451A0081 for ; Tue, 25 Nov 2014 02:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5158CSuNvyM for ; Tue, 25 Nov 2014 02:15:39 -0800 (PST) Received: from BLU004-OMC1S30.hotmail.com (blu004-omc1s30.hotmail.com [65.55.116.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01201A0099 for ; Tue, 25 Nov 2014 02:15:38 -0800 (PST) Received: from BLU177-W4 ([65.55.116.7]) by BLU004-OMC1S30.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 25 Nov 2014 02:15:37 -0800 X-TMN: [AZ6zUboV4aXcjFfFdPsQjKGtWms1KOhE] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_50c77afc-37d5-44a6-bf05-2b2331af80e3_" From: Yuhong Bao To: Hubert Kario , "tls@ietf.org" Date: Tue, 25 Nov 2014 02:15:37 -0800 Importance: Normal In-Reply-To: <1713002.kBYARvl7be@pintsize.usersys.redhat.com> References: <20141124155935.51E0C1B004@ld9781.wdf.sap.corp>, <1713002.kBYARvl7be@pintsize.usersys.redhat.com> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2014 10:15:37.0837 (UTC) FILETIME=[C21B61D0:01D00898] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NdBdWzFd1yLTV5nMDnBsCdVLHwU Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 10:15:40 -0000 --_50c77afc-37d5-44a6-bf05-2b2331af80e3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > Just a few days ago I was working on a customer message about interop > > problems with a Business-2-Business scenario=2C and the Server that is = used > > seems to be an extensions-intolerant TLSv1.0 server. The server is OK > > with ClientHello.client_version =3D { 3=2C 3 }=2C but when ClientHello = includes > > any TLS extensions=2C it will abort with a fatal unexpected_message(10)= alert. > >=20 > > (the Website is http://www.elemica.com=2C > > the service(s) are on https://preprod.connect.elemica.com:5443 > > and https://connect.elemica.com:5443 > > authentication is by TLS client certificate=2C but you'll see the > > TLS extensions intolerance by the fatal alert response to ClientHell= o. > >=20 > > > I think we can safely banish a protocol that only 0.5% of servers req= uire > > > for interoperability. > >=20 > > Maybe you can=2C but I can not. The support load would still be prohib= itive. >=20 > In the case you're talking about you can connect using TLS1.0 without=20 > extensions=2C and while that is suboptimal in general it is allowed under= =20 > current draft (and supported with TLS_FALLBACK_SCSV). >=20 > Anyway=2C you should file a complaint to the manufacturer that it haven't= =20 > addressed the POODLE vulnerability in their product (or that it doesn't=20 > implement advertised protocols properly). > If you don't have a contract under which you can do that or can't change = the=20 > TLS library yourself=2C you have much bigger problems anyway... I'd explicitly say that the problem is TLS extensions intolerance which wou= ld cause browsers to fall back to SSLv3.As a side note=2C while TLS extensi= ons intolerance is a bit painful too=2C I feel that it is worth the effort = to eliminate. Besides SNI and OCSP stapling=2C there is also RFC 7366 which= is an Encrypt after MAC extension for TLS. Yuhong Bao = --_50c77afc-37d5-44a6-bf05-2b2331af80e3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B Just a few days ag= o I was working on a customer message about interop
>=3B >=3B proble= ms with a Business-2-Business scenario=2C and the Server that is used
&g= t=3B >=3B seems to be an extensions-intolerant TLSv1.0 server. The serve= r is OK
>=3B >=3B with ClientHello.client_version =3D { 3=2C 3 }=2C = but when ClientHello includes
>=3B >=3B any TLS extensions=2C it wil= l abort with a fatal unexpected_message(10) alert.
>=3B >=3B
>= =3B >=3B (the Website is http://www.elemica.com=2C
>=3B >=3B t= he service(s) are on https://preprod.connect.elemica.com:5443
>=3B >= =3B and https://connect.elemica.com:5443
>=3B >= =3B authentication is by TLS client certificate=2C but you'll see the>=3B >=3B TLS extensions intolerance by the fatal alert response to= ClientHello.
>=3B >=3B
>=3B >=3B >=3B I think we can safe= ly banish a protocol that only 0.5% of servers require
>=3B >=3B >= =3B for interoperability.
>=3B >=3B
>=3B >=3B Maybe you can= =2C but I can not. The support load would still be prohibitive.
>=3B =
>=3B In the case you're talking about you can connect using TLS1.0 wi= thout
>=3B extensions=2C and while that is suboptimal in general it i= s allowed under
>=3B current draft (and supported with TLS_FALLBACK_S= CSV).
>=3B
>=3B Anyway=2C you should file a complaint to the man= ufacturer that it haven't
>=3B addressed the POODLE vulnerability in = their product (or that it doesn't
>=3B implement advertised protocols= properly).
>=3B If you don't have a contract under which you can do t= hat or can't change the
>=3B TLS library yourself=2C you have much bi= gger problems anyway...
I'd explicitly say that the problem is TLS exten= sions intolerance which would cause browsers to fall back to SSLv3.
As = a side note=2C while TLS extensions intolerance is a bit painful too=2C I f= eel that it is worth the effort to eliminate. Besides SNI and OCSP stapling= =2C there is also RFC 7366 which is an Encrypt after MAC extension for TLS.=

Yuhong Bao
= --_50c77afc-37d5-44a6-bf05-2b2331af80e3_-- From nobody Tue Nov 25 03:07:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B646E1A00CA for ; Tue, 25 Nov 2014 03:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXuNOh7WNLfQ for ; Tue, 25 Nov 2014 03:07:24 -0800 (PST) Received: from BLU004-OMC3S24.hotmail.com (blu004-omc3s24.hotmail.com [65.55.116.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E821A00B9 for ; Tue, 25 Nov 2014 03:07:24 -0800 (PST) Received: from BLU177-W41 ([65.55.116.73]) by BLU004-OMC3S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 25 Nov 2014 03:07:23 -0800 X-TMN: [Vses1q/bOXUwQgFPUbypvbz5MR38V+7S] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "tls@ietf.org" , "mrex@sap.com" Date: Tue, 25 Nov 2014 03:07:22 -0800 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2014 11:07:23.0275 (UTC) FILETIME=[FD179DB0:01D0089F] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9qv8BZ9GO2-QgIGngnmNEnfAHwc Subject: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 11:07:26 -0000 Has the incorrect premaster secret version check described in this been fix= ed in=A0MS14-066:=0A= http://www.ietf.org/mail-archive/web/tls/current/msg08139.html=0A= =0A= Yuhong Bao = From nobody Tue Nov 25 03:32:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7948D1A00B9 for ; Tue, 25 Nov 2014 03:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0tHQLEEibLy for ; Tue, 25 Nov 2014 03:32:04 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A0E1A0084 for ; Tue, 25 Nov 2014 03:32:04 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPBW3IQ024691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 25 Nov 2014 06:32:04 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAPBW1XG023943 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 06:32:03 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 25 Nov 2014 12:32:01 +0100 Message-ID: <1727496.2fOsnqr20G@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <54739113.100@polarssl.org> References: <20141124155935.51E0C1B004@ld9781.wdf.sap.corp> <1713002.kBYARvl7be@pintsize.usersys.redhat.com> <54739113.100@polarssl.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xNj10AmNfo-TzE9nAXpUN-F9OkQ Cc: Manuel =?ISO-8859-1?Q?P=E9gouri=E9=2DGonnard?= Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 11:32:06 -0000 On Monday 24 November 2014 21:12:03 Manuel P=E9gouri=E9-Gonnard wrote: > On 24/11/2014 17:32, Hubert Kario wrote: > > On Monday 24 November 2014 16:59:35 Martin Rex wrote: > >> How do TLS extension support fit into your picture? > >=20 > > I don't know. > >=20 > > That is: I'm using openssl command line binary (albeit with few cha= nges, > > modifications and additions compared to upstream) and as such I don= 't > > believe I can send TLS1.0/1.1/1.2 Client Hello without extensions. >=20 > I'm not sure how (in)convenient it would be for you to use another to= ol in > addition, but gnutls-cli allows that easily: just add %NO_EXTENSIONS = to the > priority string. >=20 > http://gnutls.org/manual/html_node/Priority-Strings.html#tab_003aprio= _002dsp > ecial1 to actually detect which ciphers, protocol versions, etc. such server s= upports=20 it would require to write a new tool basically on the other hand, I can use it as a last resort fallback, just to get = a=20 number of such servers... I'll try adding that --=20 Regards, Hubert Kario From nobody Tue Nov 25 04:40:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F671A016A for ; Tue, 25 Nov 2014 04:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ck7Q_WfE9za for ; Tue, 25 Nov 2014 04:40:01 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC1D1A0166 for ; Tue, 25 Nov 2014 04:40:01 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPCdxEA013794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 25 Nov 2014 07:40:00 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAPCdv45004536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 07:39:58 -0500 Message-ID: <1416919197.32742.16.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Adam Langley Date: Tue, 25 Nov 2014 13:39:57 +0100 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y-XH4QM5eXHLUcKPa4DQ8lBXwIc Cc: tls@ietf.org Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:40:03 -0000 ----- Original Message ----- > I generally recommend that, whenever signing a message, a > NUL-terminated, ASCII context string is prepended to the message to > ensure that the verifier isn't confused about the context. > (NUL-terminated, ASCII strings have the property that none is a prefix > of any other.) > > I think that TLS 1.3 provides a good demonstration of why: [...] > TLS 1.3 has the server return a CertificateVerify message[2] that > signs the handshake so far, similar to TLS <= 1.2's message of the > same name. However, consider a client that implements any version of > TLS and a server that implements TLS 1.3: Thanks for bringing that up, as it is an interesting issue. I read the changes to TLS 1.3, and the current approach in TLS 1.3. as I understand is to use the following construction for both client and server certificate verify. struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; } } CertificateVerify; That would mean that CertificateVerify is compatible between a server and client, and I believe this was the thing the designers of SSL 3.0 wanted to avoid when they made different signature formats for each message. To add to your attack for that construction, an attack in early crypto protocols was a client using the server signed response to authenticate using the server's own key (Unfortunately I don't remember where this was first described). While in TLS 1.3 the hash contents will be different at the point both messages are sent, and the attack doesn't directly apply, I think the fact that the format of two different signatures matches cleanly is a reason for concern. I am for using any kind of distinguisher to make these messages context dependent. regards, Nikos From nobody Tue Nov 25 05:04:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F83C1A0358 for ; Tue, 25 Nov 2014 05:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkT19YRwEfQN for ; Tue, 25 Nov 2014 05:04:19 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066351A0263 for ; Tue, 25 Nov 2014 05:04:19 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 10C063A18F; Tue, 25 Nov 2014 14:04:16 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D178742158; Tue, 25 Nov 2014 14:04:16 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C715F1B00A; Tue, 25 Nov 2014 14:04:16 +0100 (CET) In-Reply-To: <2955685.UojdYEpn75@pintsize.usersys.redhat.com> To: Hubert Kario Date: Tue, 25 Nov 2014 14:04:16 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141125130416.C715F1B00A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uiYIQmN9IEnCLajMbdqGpICRVUQ Cc: tls@ietf.org Subject: Re: [TLS] Deprecating SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 13:04:21 -0000 Hubert Kario wrote: >Martin Rex wrote: >> >> It's a plaintext recovery of 1 byte per 256 requests on average > > no, you need 256 for 100% chance of recovery, statistically speaking you need > 128 requests for a 50% chance of recovery - 50% *is* average, especially if > we're talking about recovering multiple bytes. The 128 on average would apply only to things like an exhaustive key search, where you do not encounter duplicates, and the worst case would be the last possibility after 256 tries. For the poodle attack, you have a random distribution, caused by the IVs so you will regularly get duplicate wrong guesses during the first 128 tries, and worst case will be much more than 256 tries. The math might be what is described here: http://en.wikipedia.org/wiki/Coupon_collector%27s_problem Any math/probability takers? -Martin From nobody Tue Nov 25 06:47:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4A41A1A56 for ; Tue, 25 Nov 2014 06:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDm8momrSzd9 for ; Tue, 25 Nov 2014 06:46:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932DE1A02BE for ; Tue, 25 Nov 2014 06:46:51 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPEkmmG006202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 25 Nov 2014 09:46:49 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAPEkkiN022408 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 09:46:48 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 25 Nov 2014 15:46:46 +0100 Message-ID: <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q7m-vG6eEgTlpb7HxIhaS87tm4s Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 14:46:56 -0000 On Monday 24 November 2014 09:35:20 Watson Ladd wrote: > On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex wrote: > > Nico Williams wrote: > >> Henrick Hellstr=F6m wrote: > >>> Yes, but the point I am trying to make, is that if the implied go= al > >>> is to make TLS resilient even against BEAST/CRIME style attacks, = the > >>> threat model should be defined accordingly. It makes little sense= to > >>> ask for cryptographic review of the protocol, if it is inherently= > >>> unclear exactly what kind of threats the protocol is designed to > >>> withstand. > >>=20 > >> BEAST/CRIME are dramatic demonstrations of the capabilities of att= ackers > >> in the Internet threat model. > >=20 > > Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of = the > > ridiculous insecurity of WebBrowsers in their default=20 configuration.https://tcms.engineering.redhat.com/case/295339/ >=20 > So it's possible to get my Paypal login cookie if I browse to a > malicious site on a fully patched browser? Because that's what BEAST > enabled. Are you saying it's fine that SSL v3.0 leaks one byte per > connection? Because that's POODLE. All of this was known in 2004, and= > not fixed in TLS 1.2 are you suggesting that AEAD ciphers are vulnerable to them? based on w= hat=20 mechanism? I mean, sure they are not mandatory or the only TLS 1.2 compatible ciph= ers,=20 but there are there... --=20 Regards, Hubert Kario From nobody Tue Nov 25 07:15:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074241A8748 for ; Tue, 25 Nov 2014 07:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99RpxH51sKsV for ; Tue, 25 Nov 2014 07:15:47 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5C91A885B for ; Tue, 25 Nov 2014 07:14:39 -0800 (PST) Received: by mail-yk0-f180.google.com with SMTP id 9so335775ykp.25 for ; Tue, 25 Nov 2014 07:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AMVOV08ifLz8StWREYzP9eM+UkVB6nHDLQEF+yA4qmM=; b=VIOuVc0NNXjHl3Z0m+uEEykN6pVeJOA/27dtSQa5dK86ZDi828qLe8rvUNpr+t1+30 ImD1f3RDmhOzmW1q+3U7UpWMWP/+NHmiKHbKGe69bmdN2s/UsspkJHUlWpnGlqWqsOMj TAaav/DfO/T2Knib6GzilMH45ViLfQ/77r7OQJM9qpd/oHu04eudLTJVYdPCZRMEOD8D ZywhpeFAQUXVQN5lFvPWFIDNShzRSW2YO2Jr9ymDNpx+qkbJi6dv0kShGEviHaMAMUZ9 b0Juh0hpSQep0VWeQv8HO0hKfRRYSJ6AAnIOmluhXDmO9V9PjPWeQVTYdUCnQpuCqH/J GrAA== MIME-Version: 1.0 X-Received: by 10.170.111.210 with SMTP id d201mr27936231ykb.126.1416928478796; Tue, 25 Nov 2014 07:14:38 -0800 (PST) Received: by 10.170.195.21 with HTTP; Tue, 25 Nov 2014 07:14:38 -0800 (PST) In-Reply-To: <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> Date: Tue, 25 Nov 2014 07:14:38 -0800 Message-ID: From: Watson Ladd To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WscCGn4NxT6QtxuMFGcYVsygNtI Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:15:49 -0000 On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario wrote: > On Monday 24 November 2014 09:35:20 Watson Ladd wrote: >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex wrote: >> > Nico Williams wrote: >> >> Henrick Hellstr=C3=B6m wrote: >> >>> Yes, but the point I am trying to make, is that if the implied goal >> >>> is to make TLS resilient even against BEAST/CRIME style attacks, the >> >>> threat model should be defined accordingly. It makes little sense to >> >>> ask for cryptographic review of the protocol, if it is inherently >> >>> unclear exactly what kind of threats the protocol is designed to >> >>> withstand. >> >> >> >> BEAST/CRIME are dramatic demonstrations of the capabilities of attack= ers >> >> in the Internet threat model. >> > >> > Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of the >> > ridiculous insecurity of WebBrowsers in their default > configuration.https://tcms.engineering.redhat.com/case/295339/ >> >> So it's possible to get my Paypal login cookie if I browse to a >> malicious site on a fully patched browser? Because that's what BEAST >> enabled. Are you saying it's fine that SSL v3.0 leaks one byte per >> connection? Because that's POODLE. All of this was known in 2004, and >> not fixed in TLS 1.2 > > are you suggesting that AEAD ciphers are vulnerable to them? based on wha= t > mechanism? > > I mean, sure they are not mandatory or the only TLS 1.2 compatible cipher= s, > but there are there... Fixed means fixed, not "you get to play choose your own ciphersuite, where most of the options are wrong". It means aggressively removing ciphers and protocols known to be weak. Instead of considering the job done when secure options have been added, we should consider it done when the insecure options have been removed. Sincerely, Watson Ladd > > -- > Regards, > Hubert Kario --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Nov 25 07:25:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3901A1EEA for ; Tue, 25 Nov 2014 07:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYzUA1-89Xdw for ; Tue, 25 Nov 2014 07:25:23 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809FB1A0399 for ; Tue, 25 Nov 2014 07:25:17 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPFPGkJ003382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 25 Nov 2014 10:25:16 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAPFPE19001148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 25 Nov 2014 10:25:15 -0500 From: Hubert Kario To: "tls@ietf.org" Date: Tue, 25 Nov 2014 16:25:14 +0100 Message-ID: <5982358.T0UeBgPCAg@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: <20141124105948.GH3200@localhost> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4R-a4M8skMmPnzoZkcp49Wdg5LY Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:25:29 -0000 On Tuesday 25 November 2014 07:14:38 you wrote: > On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario wro= te: > > On Monday 24 November 2014 09:35:20 Watson Ladd wrote: > >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex wrote: > >> > Nico Williams wrote: > >> >> Henrick Hellstr=F6m wrote: > >> >>> Yes, but the point I am trying to make, is that if the implied= goal > >> >>> is to make TLS resilient even against BEAST/CRIME style attack= s, the > >> >>> threat model should be defined accordingly. It makes little se= nse to > >> >>> ask for cryptographic review of the protocol, if it is inheren= tly > >> >>> unclear exactly what kind of threats the protocol is designed = to > >> >>> withstand. > >> >>=20 > >> >> BEAST/CRIME are dramatic demonstrations of the capabilities of > >> >> attackers > >> >> in the Internet threat model. > >> >=20 > >> > Nope. BEAST, CRIME and Poodle are pretty boring demonstrations = of the > >> > ridiculous insecurity of WebBrowsers in their default > >=20 > > configuration.https://tcms.engineering.redhat.com/case/295339/ > >=20 > >> So it's possible to get my Paypal login cookie if I browse to a > >> malicious site on a fully patched browser? Because that's what BEA= ST > >> enabled. Are you saying it's fine that SSL v3.0 leaks one byte per= > >> connection? Because that's POODLE. All of this was known in 2004, = and > >> not fixed in TLS 1.2 > >=20 > > are you suggesting that AEAD ciphers are vulnerable to them? based = on what > > mechanism? > >=20 > > I mean, sure they are not mandatory or the only TLS 1.2 compatible > > ciphers, > > but there are there... >=20 > Fixed means fixed, not "you get to play choose your own ciphersuite, > where most of the options are wrong". It means aggressively removing > ciphers and protocols known to be weak. Instead of considering the jo= b > done when secure options have been added, we should consider it done > when the insecure options have been removed. But then you have ADH and AECDH ciphers which can be used securely (and= have=20 their valid uses) but are insecure for the web use case. as long as TLS will remain a general protocol, there will be "pick and = choose"=20 involved and I prefer situation with one protocol that has some problems than 20= =20 protocols, each with its own set of idiosyncrasies --=20 Regards, Hubert Kario From nobody Tue Nov 25 08:26:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818261ACD6F for ; Tue, 25 Nov 2014 08:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.637 X-Spam-Level: * X-Spam-Status: No, score=1.637 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XognET5IxQKY for ; Tue, 25 Nov 2014 08:26:48 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D562B1ACD72 for ; Tue, 25 Nov 2014 08:26:45 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MPp7i-1XpTSz228g-004yfE; Tue, 25 Nov 2014 17:26:43 +0100 Received: by mail-ob0-f180.google.com with SMTP id wp4so708998obc.11 for ; Tue, 25 Nov 2014 08:26:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.230.169 with SMTP id sz9mr16517134obc.31.1416932801413; Tue, 25 Nov 2014 08:26:41 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 25 Nov 2014 08:26:41 -0800 (PST) In-Reply-To: <20141124101744.GC3200@localhost> References: <5470742A.8020002@streamsec.se> <20141124101744.GC3200@localhost> Date: Tue, 25 Nov 2014 17:26:41 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c32d0a4c90720508b160e6 X-Provags-ID: V02:K0:143zWH0VsEBKlc9srDi5lnU+ZkGFju0+vffnF7WyiLC /S5E9EaTTrGld6lPHXe+El1cxdcqyLjNvu2aCWkGDrLau90Zwj WUjQNEIGVm3QwXdqVZCoKtO/WUHzNYy2245TJBGpBtpWBHlPeu sTCj1B7sT30bilGiXuFdfYpklHLqFWt/GKR3ck7zuHNEqeMZOa vdrvCTbXeA/hDMMT9rePrHHVvdwQsA5DEe84amfKGq0ASi9hJZ ID1AG9ok8k5nj4B0AzGKh53w8vOZ+mTyauboqIjP1OiTBd/cAE nscMvVYqPv2vP+gvJ+KoxyoYRMmRS39hnK37CYuT8b3XKOwFvA h5TotEFnQzs7BpQ7gaOu4lQgtIdhmFGrgXp9bDlYg5kD93tGWN /YtELsQmNj+UFRy/BR+w4SEbXfHGfPePdDQhgKbJ0zCh7tbumN N6KTK X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oqfXeEHkO72hJkKNCzV3evQRINs Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 16:26:50 -0000 --001a11c32d0a4c90720508b160e6 Content-Type: text/plain; charset=UTF-8 Nico Williams : > Watson Ladd wrote: > > > It's clear what the security claims of TLS are be: a TLS connection > > between two parties ensures that data sent between them isn't > > intercepted or manipulated, and that they are who they claim to be. > > This is a fairly standard notion, clearly present in research by the > > late 80's, and intuitively sensible. > > It's the standard Internet threat model. Aside from needing to be > updated for massive adversay capabilities, the standard Internet threat > model has held up well. What hasn't held up is TLS: > This is sort of true, and sort of isn't. If you look at RFC 3552 ("The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when one of the end-systems has been compromised extraordinarily difficult. [...] By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate.") and the goals of TLS according to RFC 5246 ("Cryptographic security: TLS should be used to establish a secure connection between two parties"), it's true that this can be read as covering all kinds of attacks, because it is sufficiently vague. But then if you look at the *specific* examples of attacks in RFC 3552, it becomes quite clear that classes of attacks including BEAST weren't really considered back then. I don't agree with claims elsewhere in this thread that such attacks violate the premise of RFC 3552 of end-systems being uncompromised. If a system is designed to tunnel externally provided data (some of which may be provided by an attacker) through TLS, this makes it vulnerable to BEAST, but I think it's a far fetch to call such a system "compromised" by design. Yes, "Cross Site Request Forgery" style attacks can be used to exploit the security weaknesses, but if the protocols were offering secure channels according to an appropriate definition, then the weaknesses wouldn't be an issue (even if the attacker can use scripting languages to partially remote-control the systems under attack). [Also, if you believe that POODLE *requires* this attack setting, you just lack imagination. The *full* POODLE attack assume this setting, but if an attacker can obtain just a single byte of your password, that's a breakage too. Cf. https://www.iacr.org/cryptodb/archive/2003/CRYPTO/1069/1069.pdf for inspiration for a setting not involving any Javascript or other scripting language.] As we know from the cryptographic literature, however, properly formalizing the needed security properties can be as hard as (or even harder than) achieving them. Everyone reading papers dealing with formal security proofs for cryptographic schemes will, on occasion, have run into some formally defined security notion that looks quite reasonable at first, but on closer inspection turns out to have problems -- e.g., assumes something that is in fact unsatisfiable, or insufficient, or even both. The security claims that TLS should fulfill, for example, may seem somewhat clear, but only if you don't actually go into all the details. Accordingly, I don't think it is meaningful to blame *either* the threat model *or* TLS for the shortcomings. The lack of clearness about the security goals can reasonably be blamed on both. Bodo --001a11c32d0a4c90720508b160e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nico= Williams <nico@cryptonector.com>:
= Watson Ladd wrote:
=C2=A0
> It's clear what the security claims of TLS are be: a TLS connectio= n
> between two parties ensures that data sent between them isn't
> intercepted or manipulated, and that they are who they claim to be. > This is a fairly standard notion, clearly present in research by the > late 80's, and intuitively sensible.
= =C2=A0
It's the standard Internet threat model.=C2=A0 Aside from needin= g to be
updated for massive adversay capabilities, the standard Internet threat
model has held up well.=C2=A0 What hasn't held up is TLS:

This is sort of true, and sort of isn't.

If you look at RFC 3552 ("The Internet environment h= as a fairly well understood threat model. In general, we assume that the en= d-systems engaging in a protocol exchange have not themselves been compromi= sed. Protecting against an attack when one of the end-systems has been comp= romised extraordinarily difficult. [...] By contrast, we assume that the at= tacker has nearly complete control of the communications channel over which= the end-systems communicate.") and the goals of TLS according to RFC = 5246=C2=A0("Cryptographic security: TLS should be used to establish a = secure connection between two parties"), it's true that this can b= e read as covering all kinds of attacks, because it is sufficiently vague. = But then if you look at the *specific* examples of attacks in RFC 3552, it = becomes quite clear that classes of attacks including BEAST weren't rea= lly considered back then.

I don't agree with c= laims elsewhere in this thread that such attacks violate the premise of RFC= 3552 of end-systems being=C2=A0uncompromised.=C2=A0 If a system is designe= d to tunnel externally provided data (some of which may be provided by an a= ttacker) through TLS, this makes it vulnerable to BEAST, but I think it'= ;s a far fetch to call such a system "compromised" by design.=C2= =A0 Yes, "Cross Site Request Forgery" style attacks can be used t= o exploit the security weaknesses, but if the protocols were offering secur= e channels according to an appropriate definition, then the weaknesses woul= dn't be an issue (even if the attacker can use scripting languages to p= artially remote-control the systems under attack). =C2=A0[Also, if you beli= eve that POODLE *requires* this attack setting, you just lack imagination. = The *full* POODLE attack assume this setting, but if an attacker can obtain= just a single byte of your password, that's a breakage too.=C2=A0 Cf. = https://www.iacr.org/cryptodb/archive/2003/CRYPTO/1069/1069.pdf for in= spiration for a setting not involving any Javascript or other scripting lan= guage.]

As we know from the cryptographic literatu= re, however, properly formalizing the needed security properties can be as = hard as (or even harder than) achieving them.=C2=A0 Everyone reading papers= dealing with formal security proofs for cryptographic schemes will, on occ= asion, have run into some formally defined security notion that looks quite= reasonable at first, but on closer inspection turns out to have problems -= - e.g., assumes something that is in fact unsatisfiable, or insufficient, o= r even both.=C2=A0 The security claims that TLS should fulfill, for example= , may seem somewhat clear, but only if you don't actually go into all t= he details.

Accordingly, I don't think it is m= eaningful to blame *either* the threat model *or* TLS for the shortcomings.= =C2=A0 The lack of clearness about the security goals can reasonably be bla= med on both.

Bodo

=
--001a11c32d0a4c90720508b160e6-- From nobody Tue Nov 25 08:41:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C124C1A700F for ; Tue, 25 Nov 2014 08:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4XZJPMtmwsB for ; Tue, 25 Nov 2014 08:41:31 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5991A6FE8 for ; Tue, 25 Nov 2014 08:41:30 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so9716854wiv.12 for ; Tue, 25 Nov 2014 08:41:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dBPxlk5aGJAb8PRh4mt5MjyXlrcQjoLN8Yt2xM31h08=; b=mk1SRl0PV8STIn4GWkV12L/mAcIr0y6xWklyhKmlv+ar1q+f/UwJ8LyGTw+NIwYW0m cpxZghzfiyt4TIcVLyy77uIvHUiTSJIBkiIqaPmyq6C63evfS/OdAb4Q1pLVuiw5WO6F wPSa2K4Q1AtL+SgQv21APQwwKtvPd/z6nEI1YXQZiLa2VizEm72ctn9+hnlMtofVFUEg sxTkutLk1CNwHyChJswJrYp1DToaUtPqBQuuAIJJY6QVOG8cybxAQ9f2qjBYIoapwyzC tTKXf1IkGlMBr6Ff42dcbD0lcWqGrQg+SFRzKmvUJCMBl1ywb5jdOuN4ggNlK659K8Oc DL+Q== X-Gm-Message-State: ALoCoQkeeCT7mbCmsfFXk9Y7Qie4FobcV6np2c+yPg721dR8rGhApWlnEzPJZ3tNQfRMsGByNaMb X-Received: by 10.180.102.98 with SMTP id fn2mr25479042wib.61.1416933689070; Tue, 25 Nov 2014 08:41:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 25 Nov 2014 08:40:48 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 25 Nov 2014 08:40:48 -0800 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=f46d0444ef3b352bb10508b19502 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bAM8x1W2FY3wqfxp_5t_1OVVGJ4 Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 16:41:32 -0000 --f46d0444ef3b352bb10508b19502 Content-Type: text/plain; charset=UTF-8 This seems like a good idea. Thanks for raising it. If you want to make a PR, I will merge it in. -Ekr On Mon, Nov 24, 2014 at 10:55 PM, Adam Langley wrote: > I generally recommend that, whenever signing a message, a > NUL-terminated, ASCII context string is prepended to the message to > ensure that the verifier isn't confused about the context. > (NUL-terminated, ASCII strings have the property that none is a prefix > of any other.) > > I think that TLS 1.3 provides a good demonstration of why: > > Mavrogiannopoulos, Vercauteren, Velichkov and Preneel[1] showed a > near-miss in the design of TLS <= 1.2 due to a lack of context in > ServerKeyExchange messages resulting in an ambiguity about whether a > specific message was DHE or ECDHE. > > TLS 1.3 has the server return a CertificateVerify message[2] that > signs the handshake so far, similar to TLS <= 1.2's message of the > same name. However, consider a client that implements any version of > TLS and a server that implements TLS 1.3: > > An attacker watches for the ClientHello from the client. Assume, as is > quite common now, that the client generates its client_random with 32 > random bytes (i.e. there's no timestamp). With probability 2^-32, the > client_random will start with 0x0100 and bytes 4 and 5 will be 0x03 > and 0x04. > > The attacker now connects to the TLS 1.3 server and sends a > ClientHello such that the prefix of the message (including handshake > message type and length) is equal to the victim client's client_random > value. (Most of the bytes can be put into the attacker's client_random > value and the restriction on the victim client's message ensures that > the handshake type, length and protocol version are taken care of.) > > With the rest of the ClientHello, the attacker is free to make the TLS > 1.3 handshake look like a TLS 1.2 ServerKeyExchange message. An > obvious choice is to stuff a dummy server_random into the session ID > and specify a small p and g such that a discrete-log is easy, then > consume the rest of the handshake with a huge Y. (The length of the > TLS 1.3 handshake from the server is predictable.) > > Some clients might check that Y < p but, if they do the obvious thing, > then the TLS 1.3 server's signature over the handshake can be used as > a TLS 1.2 ServerKeyExchange signature and the client compromised. > > > I may have missed something and, even if not, the restrictions on the > client's client_random value make it an expensive attack to pull off. > But it's still another near-miss. > > Thus I suggest that signed messages in TLS 1.3 be prefixed with > context strings. For example, "TLS 1.3 CertificateVerify message from > server\x00" in this case. > > However, since TLS <= 1.2 provides an attacker the ability to get a > signature for a message with a 32-byte, chosen prefix via the > ServerKeyExchange, I additionally suggest that the context string > start with 48-64 bytes of "PADTLS" repeated, in order to clear that > prefix and cover part or all of the server_random. > > (And that signature oracle in TLS <= 1.2 provides another reason, > should any be needed, not to run a CA:TRUE certificate on a server.) > > > [1] https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf > [2] https://tlswg.github.io/tls13-spec/#rfc.section.7.4.7 > [3] https://tools.ietf.org/html/rfc5246#section-7.4.1.2 > [4] https://tools.ietf.org/html/rfc5246#section-7.4.3 > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0444ef3b352bb10508b19502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems like a good idea. Thanks for raising it.
If you want to make a PR, I will merge it in.

-Ekr


On Mon, Nov 24, 2014 at 10:55 PM, Adam= Langley <agl@imperialviolet.org> wrote:
I generally recommend that, whenever signing a message,= a
NUL-terminated, ASCII context string is prepended to the message to
ensure that the verifier isn't confused about the context.
(NUL-terminated, ASCII strings have the property that none is a prefix
of any other.)

I think that TLS 1.3 provides a good demonstration of why:

Mavrogiannopoulos, Vercauteren, Velichkov and Preneel[1] showed a
near-miss in the design of TLS <=3D 1.2 due to a lack of context in
ServerKeyExchange messages resulting in an ambiguity about whether a
specific message was DHE or ECDHE.

TLS 1.3 has the server return a CertificateVerify message[2] that
signs the handshake so far, similar to TLS <=3D 1.2's message of the=
same name. However, consider a client that implements any version of
TLS and a server that implements TLS 1.3:

An attacker watches for the ClientHello from the client. Assume, as is
quite common now, that the client generates its client_random with 32
random bytes (i.e. there's no timestamp). With probability 2^-32, the client_random will start with 0x0100 and bytes 4 and 5 will be 0x03
and 0x04.

The attacker now connects to the TLS 1.3 server and sends a
ClientHello such that the prefix of the message (including handshake
message type and length) is equal to the victim client's client_random<= br> value. (Most of the bytes can be put into the attacker's client_random<= br> value and the restriction on the victim client's message ensures that the handshake type, length and protocol version are taken care of.)

With the rest of the ClientHello, the attacker is free to make the TLS
1.3 handshake look like a TLS 1.2 ServerKeyExchange message. An
obvious choice is to stuff a dummy server_random into the session ID
and specify a small p and g such that a discrete-log is easy, then
consume the rest of the handshake with a huge Y. (The length of the
TLS 1.3 handshake from the server is predictable.)

Some clients might check that Y < p but, if they do the obvious thing, then the TLS 1.3 server's signature over the handshake can be used as a TLS 1.2 ServerKeyExchange signature and the client compromised.


I may have missed something and, even if not, the restrictions on the
client's client_random value make it an expensive attack to pull off. But it's still another near-miss.

Thus I suggest that signed messages in TLS 1.3 be prefixed with
context strings. For example, "TLS 1.3 CertificateVerify message from<= br> server\x00" in this case.

However, since TLS <=3D 1.2 provides an attacker the ability to get a signature for a message with a 32-byte, chosen prefix via the
ServerKeyExchange, I additionally suggest that the context string
start with 48-64 bytes of "PADTLS" repeated, in order to clear th= at
prefix and cover part or all of the server_random.

(And that signature oracle in TLS <=3D 1.2 provides another reason,
should any be needed, not to run a CA:TRUE certificate on a server.)


[1] https://www.cosic.esat.kuleuven.be/publications/art= icle-2216.pdf
[2] https://tlswg.github.io/tls13-spec/#rfc.section.7.4.7
[3] https://tools.ietf.org/html/rfc5246#section-7.4.1.2
[4] https://tools.ietf.org/html/rfc5246#section-7.4.3


Cheers

AGL

--
Adam Langley ag= l@imperialviolet.org https://www.imperialviolet.org

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--f46d0444ef3b352bb10508b19502-- From nobody Tue Nov 25 09:20:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514F91ACE07 for ; Tue, 25 Nov 2014 09:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPBnC2FK3fes for ; Tue, 25 Nov 2014 09:20:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 615851A7015 for ; Tue, 25 Nov 2014 09:20:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B8C43BED1 for ; Tue, 25 Nov 2014 17:20:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0geQBQWDWA5 for ; Tue, 25 Nov 2014 17:20:08 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3708BEDB for ; Tue, 25 Nov 2014 17:20:02 +0000 (GMT) Message-ID: <5474BA41.1040009@cs.tcd.ie> Date: Tue, 25 Nov 2014 17:20:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hakTTNKN9byI1nzZiYqiIqSOgd8 Subject: [TLS] AD review of draft-ietf-tls-prohibiting-rc4-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 17:20:23 -0000 X-List-Received-Date: Tue, 25 Nov 2014 17:20:23 -0000 Hiya, I have a question to ask before starting IETF LC. I don't care much what answer you provide but we will be asked later and I don't recall it being discussed here, so let's get it out of the way: This says there are no IANA actions, which is consistent with how e.g. export ciphersuites were handled I think. But would the WG like to add a column saying "deprecated" or similar to [2]? My assumption is the answer is "no" or at least "not in this document" so unless the chairs tell me to hold off again I'll start IETF LC tomorrow. (OTOH, a part of me would be happy to see a draft that deprecated a whole nice big pile of ciphersuites;-) Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ [2] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 From nobody Tue Nov 25 09:58:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5339E1A6FEE for ; Tue, 25 Nov 2014 09:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnCfsj-Lwl2e for ; Tue, 25 Nov 2014 09:58:00 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D133C1A6EED for ; Tue, 25 Nov 2014 09:57:59 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so2329307wid.6 for ; Tue, 25 Nov 2014 09:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yex63a5i6MwsEF0k16UlR5wOPWhdTUKSkcgc7KOe++M=; b=QIIpE5UGYjHE0oIHb//wkn1sg1YfCoeHm79SuZwerKFoj/uvgXGr7+eaiDWyoJ0Rp/ 2titBjA8gxxbdArxGLW33Rm/mhrD9Ezv0RTQhb6O4+x2SBdTcSBKqRewJOnv35uFZzph KUv0I+A51RbkQSf6TAeX54o3tYQDaHkjexPQYJiY/YmGqmShdH3EH8eSNvD5gQjI4iRn bzVLHDX0ex2c1SciVSlNxxXo1RRICraoQyFeKt7pZXbeQ/OoObL1qOKfUPnPx3gx1zsd yeIy0hNg+jEuRPjq4Tf0nrEjxVMO7vC9CpWnGEi+tiRs8Pn3LkC/NukBoZ/L78sBYUxg Uv5w== X-Received: by 10.180.108.77 with SMTP id hi13mr34232621wib.73.1416938278536; Tue, 25 Nov 2014 09:57:58 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-139-23.inter.net.il. [84.228.139.23]) by mx.google.com with ESMTPSA id rx8sm2846166wjb.30.2014.11.25.09.57.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 09:57:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <5474BA41.1040009@cs.tcd.ie> Date: Tue, 25 Nov 2014 19:57:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C7E01A2-545A-45EB-BC45-E91AD7157EE3@gmail.com> References: <5474BA41.1040009@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kbEa4RVlkcC0Cg8hQA303sEbFXQ Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-prohibiting-rc4-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 17:58:02 -0000 I=E2=80=99d say no. Definitely not without also deprecating = TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, and that is out of scope for *this* = document. Perhaps, though we could add a reference to this RFC to all the = ciphersuites listed in appendix A? I see that many ciphersuites already = have more than one reference listed. Yoav > On Nov 25, 2014, at 7:20 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > I have a question to ask before starting IETF LC. I don't > care much what answer you provide but we will be asked > later and I don't recall it being discussed here, so let's > get it out of the way: >=20 > This says there are no IANA actions, which is consistent > with how e.g. export ciphersuites were handled I think. > But would the WG like to add a column saying "deprecated" > or similar to [2]? >=20 > My assumption is the answer is "no" or at least "not in > this document" so unless the chairs tell me to hold off > again I'll start IETF LC tomorrow. (OTOH, a part of me > would be happy to see a draft that deprecated a whole > nice big pile of ciphersuites;-) >=20 > Cheers, > S. >=20 > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ > [2] > = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-4 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 25 11:17:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378241ACF66 for ; Tue, 25 Nov 2014 11:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3sIch45VJ6O for ; Tue, 25 Nov 2014 11:15:53 -0800 (PST) Received: from BLU004-OMC3S31.hotmail.com (blu004-omc3s31.hotmail.com [65.55.116.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED731ACF67 for ; Tue, 25 Nov 2014 11:15:51 -0800 (PST) Received: from BLU177-W25 ([65.55.116.72]) by BLU004-OMC3S31.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 25 Nov 2014 11:15:51 -0800 X-TMN: [3Stv2GzzS1vl8W/zkIVByB7uiAV12t1/] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "tls@ietf.org" , "mrex@sap.com" , "andreipo@microsoft.com" Date: Tue, 25 Nov 2014 11:15:50 -0800 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2014 19:15:51.0367 (UTC) FILETIME=[3A138D70:01D008E4] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fWb1Tdr0aDPUtf23WbQhEOCHivA Subject: Re: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:15:54 -0000 Adding=A0Andrei Popov to To: list=0A= =0A= ----------------------------------------=0A= > From: yuhongbao_386@hotmail.com=0A= > To: tls@ietf.org=3B mrex@sap.com=0A= > Date: Tue=2C 25 Nov 2014 03:07:22 -0800=0A= > Subject: [TLS] MS14-066 and the TLS premaster secret version check=0A= >=0A= > Has the incorrect premaster secret version check described in this been f= ixed in MS14-066:=0A= > http://www.ietf.org/mail-archive/web/tls/current/msg08139.html=0A= >=0A= > Yuhong Bao=0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tls=0A= = From nobody Tue Nov 25 11:34:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C9A1A0367 for ; Tue, 25 Nov 2014 11:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YlwVbQRn7la for ; Tue, 25 Nov 2014 11:32:42 -0800 (PST) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F0A1AC528 for ; Tue, 25 Nov 2014 11:32:42 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id l89so973428qgf.10 for ; Tue, 25 Nov 2014 11:32:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=reYu3rk/Ik8RwXTckvylKUSzNLfCfmnGSvppR9F7SgA=; b=XFBKa2Ttx1LKdprQnLlAAKf2+sCAvy0fR+RJj9QH3PoX8R5OVuDLG+Fi163YGJbpso chy0aPrtu/Vd85LT3ikMl4uGWBmaaxqbZsJwejIcdSGpkyx656Hl/B5O0g6NPDNtKQrg EGLG5ZLeAxdk+e/zgFvGfFll6xMFv1xSVdNrrCVX86ykrwInbKuf/YYOcN5Y5kr67DcJ 0R+y6wnGYL+xeB2st1yU4jaJ/GfkmfA6Iq8SMlzhcL5HrLr3NKJ9CPmeuPerW8vpMfuR PDskoiVl2Hs/SlHwkuhWD/qlHl1AsB45KZ6WUyMic5LRvvhEw8kaZHVH1PQD3u2YvcEr 9qjg== X-Gm-Message-State: ALoCoQk0FN8aWsKK8CHs8ZSxJC/AmJ6HirbnC+EU6G4XEG9JVqZs3lCYLGMp/joHmDOVDDRf87yq MIME-Version: 1.0 X-Received: by 10.140.106.138 with SMTP id e10mr40050895qgf.71.1416943961729; Tue, 25 Nov 2014 11:32:41 -0800 (PST) Received: by 10.96.215.170 with HTTP; Tue, 25 Nov 2014 11:32:41 -0800 (PST) X-Originating-IP: [67.168.161.122] Date: Tue, 25 Nov 2014 11:32:41 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113a629081b4840508b3f9ed Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ytBtpCOvOv5NKZlfLzdCnKrxi9w Subject: [TLS] TLS Minutes for IETF-91 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:32:44 -0000 --001a113a629081b4840508b3f9ed Content-Type: text/plain; charset=UTF-8 The minutes for the TLS meeting in IETF-91 are available here: http://www.ietf.org/proceedings/91/minutes/minutes-91-tls Please let the chairs know if there are any corrections. Thanks, J&S --001a113a629081b4840508b3f9ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The minutes for the TLS meeting in IETF-91 are available h= ere:


Please let the chairs know if there are = any corrections. =C2=A0

Thanks,

J&S
--001a113a629081b4840508b3f9ed-- From nobody Tue Nov 25 13:12:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD61A1A6EEF for ; Tue, 25 Nov 2014 13:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VetCoPwH-bL6 for ; Tue, 25 Nov 2014 13:10:45 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358951A1EED for ; Tue, 25 Nov 2014 13:10:45 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id j7so1039283qaq.1 for ; Tue, 25 Nov 2014 13:10:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SboeU7lV3V6JxWVbQv0OsR78U1iHqhsw2p64YxRH3Vk=; b=fKHY2WqZJgXdYQh2G9rYgKgr0FmVELbNtwo9DG5c5Tg5ASTp/SZbLyWQDCv9lmCmJC Q0vF2scNS7FPpqVWLIICtDvjNR8sGv2sRY+SyvTU2E6C7uuuXhu9ZSQNh0pKLYCjJAop VA36cG1q5zJN4aMKxG8wdCO7jrgCYnRjyE9NuxIVhk0lE0f22fQ6E+iVIr2lXCgUkTW6 PmYiXq55Yqa7LhYtfeYXiQpYRVTOXOWN30t/alN8kYVNQ3MrcH9NRPj0ho8WT9DK3aMI JVl1FtoAiWXe9Gf1DH/lvF+1c16yyVeggK7Vo9RfBTZfoK17KiyvAl8347M/TpTYrF2W dclA== X-Gm-Message-State: ALoCoQknbSTn1eMGE/KocFj2yLHgPiUWHXMmjHS2Kxal+gBmBNn5TjWkPc5sV6AlT5jDlrVj1fk5 MIME-Version: 1.0 X-Received: by 10.224.37.133 with SMTP id x5mr40341698qad.59.1416949844451; Tue, 25 Nov 2014 13:10:44 -0800 (PST) Received: by 10.96.215.170 with HTTP; Tue, 25 Nov 2014 13:10:44 -0800 (PST) X-Originating-IP: [2601:8:b300:a5:c1b1:2530:58d2:4cbb] In-Reply-To: References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> Date: Tue, 25 Nov 2014 13:10:44 -0800 Message-ID: From: Joseph Salowey To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c1f4ba24d00e0508b5585b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u7pt-7RIPkANYaJoj4FsVuR3v9g Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 21:10:48 -0000 --001a11c1f4ba24d00e0508b5585b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This thread is wandering a bit off topic. TLS 1.3 is a work in progress. If you have suggestions on how to improve it please create a Pull Request ( https://github.com/tlswg/tls13-spec) or post the specific details to the list. Keep in mind that the discussions on starting over with TLS 1.3 are not in scope as the Working Group has consensus to follow the current path. Also, as the Working Group removes and deprecates less secure protocol options we need to keep in mind the reality of current deployments. Deprecating or removing widely deployed options requires careful consideration, since these actions may result in a protocol that is unusable and/or not deployable. Cheers, Joe On Tue, Nov 25, 2014 at 7:14 AM, Watson Ladd wrote: > On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario wrote: > > On Monday 24 November 2014 09:35:20 Watson Ladd wrote: > >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex wrote: > >> > Nico Williams wrote: > >> >> Henrick Hellstr=C3=B6m wrote: > >> >>> Yes, but the point I am trying to make, is that if the implied goa= l > >> >>> is to make TLS resilient even against BEAST/CRIME style attacks, t= he > >> >>> threat model should be defined accordingly. It makes little sense = to > >> >>> ask for cryptographic review of the protocol, if it is inherently > >> >>> unclear exactly what kind of threats the protocol is designed to > >> >>> withstand. > >> >> > >> >> BEAST/CRIME are dramatic demonstrations of the capabilities of > attackers > >> >> in the Internet threat model. > >> > > >> > Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of t= he > >> > ridiculous insecurity of WebBrowsers in their default > > configuration.https://tcms.engineering.redhat.com/case/295339/ > >> > >> So it's possible to get my Paypal login cookie if I browse to a > >> malicious site on a fully patched browser? Because that's what BEAST > >> enabled. Are you saying it's fine that SSL v3.0 leaks one byte per > >> connection? Because that's POODLE. All of this was known in 2004, and > >> not fixed in TLS 1.2 > > > > are you suggesting that AEAD ciphers are vulnerable to them? based on > what > > mechanism? > > > > I mean, sure they are not mandatory or the only TLS 1.2 compatible > ciphers, > > but there are there... > > Fixed means fixed, not "you get to play choose your own ciphersuite, > where most of the options are wrong". It means aggressively removing > ciphers and protocols known to be weak. Instead of considering the job > done when secure options have been added, we should consider it done > when the insecure options have been removed. > > Sincerely, > Watson Ladd > > > > -- > > Regards, > > Hubert Kario > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c1f4ba24d00e0508b5585b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This thread is wandering a bit off topic.=C2=A0 TLS 1.3 is a work in progr= ess.=C2=A0 If you have suggestions on how to improve it please create a Pul= l Request (https://github.com/tlswg/tls13-spec) or post the specific details to = the list.=C2=A0 Keep in mind that the discussions on starting over with TLS= 1.3 are not in scope as the Working Group has consensus to follow the curr= ent path.=C2=A0 Also, as the Working Group removes and deprecates less secu= re protocol options we need to keep in mind the reality of current deployme= nts.=C2=A0 Deprecating or removing widely deployed options requires careful= consideration, since these actions may result in a protocol that is unusab= le and/or not deployable. =C2=A0

Cheers,

Joe

On Tue, Nov 25, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.c= om> wrote:
On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario <<= a href=3D"mailto:hkario@redhat.com">hkario@redhat.com> wrote:
> On Monday 24 November 2014 09:35:20 Watson Ladd wrote:
>> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex <mrex@sap.com> wrote:
>> > Nico Williams wrote:
>> >> Henrick Hellstr=C3=B6m wrote:
>> >>> Yes, but the point I am trying to make, is that if th= e implied goal
>> >>> is to make TLS resilient even against BEAST/CRIME sty= le attacks, the
>> >>> threat model should be defined accordingly. It makes = little sense to
>> >>> ask for cryptographic review of the protocol, if it i= s inherently
>> >>> unclear exactly what kind of threats the protocol is = designed to
>> >>> withstand.
>> >>
>> >> BEAST/CRIME are dramatic demonstrations of the capabiliti= es of attackers
>> >> in the Internet threat model.
>> >
>> > Nope.=C2=A0 BEAST, CRIME and Poodle are pretty boring demonst= rations of the
>> > ridiculous insecurity of WebBrowsers in their default
> configuration.https://tcms.engineering.redhat.com/case/295339/=
>>
>> So it's possible to get my Paypal login cookie if I browse to = a
>> malicious site on a fully patched browser? Because that's what= BEAST
>> enabled. Are you saying it's fine that SSL v3.0 leaks one byte= per
>> connection? Because that's POODLE. All of this was known in 20= 04, and
>> not fixed in TLS 1.2
>
> are you suggesting that AEAD ciphers are vulnerable to them? based on = what
> mechanism?
>
> I mean, sure they are not mandatory or the only TLS 1.2 compatible cip= hers,
> but there are there...

Fixed means fixed, not "you get to play choose your own ci= phersuite,
where most of the options are wrong". It means aggressively removing ciphers and protocols known to be weak. Instead of considering the job
done when secure options have been added, we should consider it done
when the insecure options have been removed.

Sincerely,
Watson Ladd
>
> --
> Regards,
> Hubert Kario



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

____________________________= ___________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11c1f4ba24d00e0508b5585b-- From nobody Tue Nov 25 14:22:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D403C1A854B for ; Tue, 25 Nov 2014 14:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFPEI8WDuVDm for ; Tue, 25 Nov 2014 14:19:54 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FE61A86FB for ; Tue, 25 Nov 2014 14:19:54 -0800 (PST) Received: by mail-yk0-f180.google.com with SMTP id 9so730972ykp.11 for ; Tue, 25 Nov 2014 14:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=crGjIdlQfTJRmdsMYUZtQHW+i+/LIcilhvyLmDtGJTI=; b=p7vaZNNudvYl8wUq4tehKoaFBtfy2ysFrNGQQzLbnStk+yKVgm1L0M/5hWQJPdve8v JMmKcTDcdeF8chPp+ET5o406Sdr+5EqD/QKQgpckG25yh7LhT5ctDinXU+LWBVDX3rg8 JJn5+7O+Y0+OlbtWoGMwsFBNRXWOGyyL9qtI0k8NtmvzQ3EtjpafD7pbBOcGgNk34HPb R2gTUF4tY+lloah/obEntk5pSr8b0DW/bloL9iFkTpVU1vMpRGI2cxNtoH0J9Rx5h11J NmPzKluyM+ix8vvLmcRmuzokPzYO32+vW85BDgA5T+EYCFUY/DF//JjAavSs50eKBCXW f0yQ== MIME-Version: 1.0 X-Received: by 10.236.63.66 with SMTP id z42mr12887990yhc.49.1416953993764; Tue, 25 Nov 2014 14:19:53 -0800 (PST) Received: by 10.170.195.21 with HTTP; Tue, 25 Nov 2014 14:19:53 -0800 (PST) Received: by 10.170.195.21 with HTTP; Tue, 25 Nov 2014 14:19:53 -0800 (PST) In-Reply-To: References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> Date: Tue, 25 Nov 2014 14:19:53 -0800 Message-ID: From: Watson Ladd To: Joseph Salowey Content-Type: multipart/alternative; boundary=089e0139fd447623f10508b64f8a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Lt5sVMYsRRSxvhfZ0D8Q0mN-9-4 Cc: tls@ietf.org Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 22:19:58 -0000 --089e0139fd447623f10508b64f8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Nov 25, 2014 1:10 PM, "Joseph Salowey" wrote: > > This thread is wandering a bit off topic. TLS 1.3 is a work in progress. If you have suggestions on how to improve it please create a Pull Request (https://github.com/tlswg/tls13-spec) or post the specific details to the list. Keep in mind that the discussions on starting over with TLS 1.3 are not in scope as the Working Group has consensus to follow the current path. Also, as the Working Group removes and deprecates less secure protocol options we need to keep in mind the reality of current deployments. Deprecating or removing widely deployed options requires careful consideration, since these actions may result in a protocol that is unusable and/or not deployable. We should never have gotten ourselves into the position of having widely deployed broken protocols. Now that we are in that position, we need to start depreciating post haste, and ensuring we have safe alternatives, including timing attack resistant ciphers. The sooner we start, the sooner we finish. As for improvents, how about finding an existing, conservatively designed signature based key agreement mechanism with the right properties, and using it? The current proposal has two distinct client auth mechanisms, one in the handshake and the other in update. Making sure the actual proposal is in the draft, and not spread out across pull requests would make life a lot easier for analyzing the protocol. It would also be nice to know how each past attack is addressed, or not. Appendix F needs to incorporate many more implementation dependent issues, which luckily have been related mostly to now removed options. Parsing TLS is one of the biggest issues in implementations. I can't promise to write the tool to auto-generate the parser, but we should be sufficiently chastised by all those who tried and failed to parse TLS records with handwritten C to consider not doing it ourselves. Quality implementations need to be available: currently there are very few, possibly none, even for TLS 1.2. I understand two implementations of TLS 1.3 are in progress, but one is slow and the other built on NSS. The more we can simplify the protocol, the better. We should actively resist adding features unless they are well-understood. When it comes to TLS 1.2 we need to produce a document explaining which combinations of features and extensions are safe. There are no less then four or five ways to deal with Triple Handshake. Implementations need to disable application access to TLS unique unless one of those fixes is in use. TLS implementations tend to be part of the TCB. This means they need to be simple to make them easy to audit. None of the above is in the charter. All of it is far more important for security then 0 RTT. Sincerely, Watson Ladd > > Cheers, > > Joe > > On Tue, Nov 25, 2014 at 7:14 AM, Watson Ladd wrote: >> >> On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario wrote: >> > On Monday 24 November 2014 09:35:20 Watson Ladd wrote: >> >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex wrote: >> >> > Nico Williams wrote: >> >> >> Henrick Hellstr=C3=B6m wrote: >> >> >>> Yes, but the point I am trying to make, is that if the implied goal >> >> >>> is to make TLS resilient even against BEAST/CRIME style attacks, the >> >> >>> threat model should be defined accordingly. It makes little sense to >> >> >>> ask for cryptographic review of the protocol, if it is inherently >> >> >>> unclear exactly what kind of threats the protocol is designed to >> >> >>> withstand. >> >> >> >> >> >> BEAST/CRIME are dramatic demonstrations of the capabilities of attackers >> >> >> in the Internet threat model. >> >> > >> >> > Nope. BEAST, CRIME and Poodle are pretty boring demonstrations of the >> >> > ridiculous insecurity of WebBrowsers in their default >> > configuration.https://tcms.engineering.redhat.com/case/295339/ >> >> >> >> So it's possible to get my Paypal login cookie if I browse to a >> >> malicious site on a fully patched browser? Because that's what BEAST >> >> enabled. Are you saying it's fine that SSL v3.0 leaks one byte per >> >> connection? Because that's POODLE. All of this was known in 2004, and >> >> not fixed in TLS 1.2 >> > >> > are you suggesting that AEAD ciphers are vulnerable to them? based on what >> > mechanism? >> > >> > I mean, sure they are not mandatory or the only TLS 1.2 compatible ciphers, >> > but there are there... >> >> Fixed means fixed, not "you get to play choose your own ciphersuite, >> where most of the options are wrong". It means aggressively removing >> ciphers and protocols known to be weak. Instead of considering the job >> done when secure options have been added, we should consider it done >> when the insecure options have been removed. >> >> Sincerely, >> Watson Ladd >> > >> > -- >> > Regards, >> > Hubert Kario >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > --089e0139fd447623f10508b64f8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 25, 2014 1:10 PM, "Joseph Salowey" <joe@salowey.net> wrote:
>
> This thread is wandering a bit off topic.=C2=A0 TLS 1.3 is a work in p= rogress.=C2=A0 If you have suggestions on how to improve it please create a= Pull Request (https://gith= ub.com/tlswg/tls13-spec) or post the specific details to the list.=C2= =A0 Keep in mind that the discussions on starting over with TLS 1.3 are not= in scope as the Working Group has consensus to follow the current path.=C2= =A0 Also, as the Working Group removes and deprecates less secure protocol = options we need to keep in mind the reality of current deployments.=C2=A0 D= eprecating or removing widely deployed options requires careful considerati= on, since these actions may result in a protocol that is unusable and/or no= t deployable. =C2=A0

We should never have gotten ourselves into the position of h= aving widely deployed broken protocols.=C2=A0 Now that we are in that posit= ion, we need to start depreciating post haste, and ensuring we have safe al= ternatives, including timing attack resistant ciphers. The sooner we start,= the sooner we finish.

As for improvents, how about finding an existing, conservati= vely designed signature based key agreement mechanism with the right proper= ties, and using it? The current proposal has two distinct client auth mecha= nisms, one in the handshake and the other in update.

Making sure the actual proposal is in the draft, and not spr= ead out across pull requests would make life a lot easier for analyzing the= protocol.

It would also be nice to know how each past attack is addres= sed, or not. Appendix F needs to incorporate many more implementation depen= dent issues, which luckily have been related mostly to now removed options.=

Parsing TLS is one of the biggest issues in implementations.= I can't promise to write the tool to auto-generate the parser, but we = should be sufficiently chastised by all those who tried and failed to parse= TLS records with handwritten C to consider not doing it ourselves.

Quality implementations need to be available: currently ther= e are very few, possibly none, even for TLS 1.2. I understand two implement= ations of TLS 1.3 are in progress, but one is slow and the other built on N= SS. The more we can simplify the protocol, the better.

We should actively resist adding features unless they are we= ll-understood.=C2=A0 When it comes to TLS 1.2 we need to produce a document= explaining which combinations of features and extensions are safe. There a= re no less then four or five ways to deal with Triple Handshake. Implementa= tions need to disable application access to TLS unique unless one of those = fixes is in use.

TLS implementations tend to be part of the TCB. This means t= hey need to be simple to make them easy to audit.

None of the above is in the charter.=C2=A0 All of it is far = more important for security then 0 RTT.

Sincerely,
Watson Ladd

>
> Cheers,
>
> Joe
>
> On Tue, Nov 25, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario <hkario@redhat.com> wrote:
>> > On Monday 24 November 2014 09:35:20 Watson Ladd wrote:
>> >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex <mrex@sap.com> wrote:
>> >> > Nico Williams wrote:
>> >> >> Henrick Hellstr=C3=B6m wrote:
>> >> >>> Yes, but the point I am trying to make, is t= hat if the implied goal
>> >> >>> is to make TLS resilient even against BEAST/= CRIME style attacks, the
>> >> >>> threat model should be defined accordingly. = It makes little sense to
>> >> >>> ask for cryptographic review of the protocol= , if it is inherently
>> >> >>> unclear exactly what kind of threats the pro= tocol is designed to
>> >> >>> withstand.
>> >> >>
>> >> >> BEAST/CRIME are dramatic demonstrations of the c= apabilities of attackers
>> >> >> in the Internet threat model.
>> >> >
>> >> > Nope.=C2=A0 BEAST, CRIME and Poodle are pretty borin= g demonstrations of the
>> >> > ridiculous insecurity of WebBrowsers in their defaul= t
>> > configuration.https://tcms.engineering.redhat.com/case/295339/
>> >>
>> >> So it's possible to get my Paypal login cookie if I b= rowse to a
>> >> malicious site on a fully patched browser? Because that&#= 39;s what BEAST
>> >> enabled. Are you saying it's fine that SSL v3.0 leaks= one byte per
>> >> connection? Because that's POODLE. All of this was kn= own in 2004, and
>> >> not fixed in TLS 1.2
>> >
>> > are you suggesting that AEAD ciphers are vulnerable to them? = based on what
>> > mechanism?
>> >
>> > I mean, sure they are not mandatory or the only TLS 1.2 compa= tible ciphers,
>> > but there are there...
>>
>> Fixed means fixed, not "you get to play choose your own ciphe= rsuite,
>> where most of the options are wrong". It means aggressively r= emoving
>> ciphers and protocols known to be weak. Instead of considering the= job
>> done when secure options have been added, we should consider it do= ne
>> when the insecure options have been removed.
>>
>> Sincerely,
>> Watson Ladd
>> >
>> > --
>> > Regards,
>> > Hubert Kario
>>
>>
>>
>> --
>> "Those who would give up Essential Liberty to purchase a litt= le
>> Temporary Safety deserve neither=C2=A0 Liberty nor Safety." >> -- Benjamin Franklin
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.= ietf.org/mailman/listinfo/tls
>
>

--089e0139fd447623f10508b64f8a-- From nobody Tue Nov 25 14:40:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572A01A1A64 for ; Tue, 25 Nov 2014 14:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASEFqLGUFMGL for ; Tue, 25 Nov 2014 14:39:32 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C331A7013 for ; Tue, 25 Nov 2014 14:39:32 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so10704349wiw.8 for ; Tue, 25 Nov 2014 14:39:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=/0171qWgOhmK8KmNaquP0oyYKmWrw2BlEY6vtP8ryD4=; b=hxfuuSe7Yc9DhUne3Vl5fQPkiph7aHxNi0Du4FQsOoKyiilPaTBhFJ48fNWXR6+vj4 GVue2XssJjMcjGzSRymQFCfPaE6JaJKu157OQhtkAxQ5WYIkrtM7LUzCXt6YXHgrSJ3R NfeJMwrjx28TqdjI/xXozl+Mj2ouXNg0N0ddy98kWonp5lJBWsF/RsjbZ+hYZoAvVLPi WfJo3Fpszh78Oe9QBCQoXLDNhap5Ggi9Tg7dtgYh4TKfvNRsa8fwAXh8b5sAGkfKR+8V s45Jm8TN8d1bk8AD5JfQ/rBQCsR8y1KwcfYcyDN1n2eGQYY002/tAAVcb7b83STVSbTP TmxQ== X-Gm-Message-State: ALoCoQly8UqLcX24B0JK8JcRwGTzRmaVWcpN/Yngp2CCwFpWazNnA92d82cJ5MpqgDVOaSBuj2eg X-Received: by 10.194.85.197 with SMTP id j5mr40568564wjz.106.1416955170914; Tue, 25 Nov 2014 14:39:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 25 Nov 2014 14:38:50 -0800 (PST) From: Eric Rescorla Date: Tue, 25 Nov 2014 14:38:50 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0103eecaa01c730508b6957d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OzeOkXFQElutPk8_xhRDeqc879M Subject: [TLS] Editorial process X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 22:39:34 -0000 --089e0103eecaa01c730508b6957d Content-Type: text/plain; charset=UTF-8 [Starting a new thread to change topics] On Tue, Nov 25, 2014 at 2:19 PM, Watson Ladd wrote > > ... The current proposal has two distinct client auth mechanisms, one in > the handshake and the other in update. > > Making sure the actual proposal is in the draft, and not spread out across > pull requests would make life a lot easier for analyzing the protocol. > A few notes on the process here from my perspective: The way I think about this is that there is a current proposal which is what's in Github and then people (whether me or someone else) suggest changes. These changes go in Pull Requests so that the WG can see what exactly is being proposed and then if the WG is happy, those PRs get merged into the main document. Obviously, no process is perfect, but my experience and my read of the experience with HTTP is that this is better than the alternatives, which mostly involve big document revisions and then comments on the whole document [0]. With regard to the specific question of client auth, the state is as follows: The existing document (i.e., the I-D and the version in git master) contains a single client auth mechanism in the handshake. We have a proposal to remove that and instead have client auth in an Update [1]. The intention is that we would only have one client authentication mechanism. FWIW, I recognize that there are a lot of PRs outstanding right now and it can be confusing. I plan on merging a number of them in over the next week or two. Best, -Ekr [0] Note that it's easy to get git/github to give you the state of the document as a whole after a PR is merged. [1] The PR in question doesn't do that, but that's because I was asked to do an initial treatment to see if people liked it and s I tried to do the minimum to accomplish that. --089e0103eecaa01c730508b6957d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Starting a new thread to change topics]

<= div>we would only have one client authentication mechanism.

<= /div>
FWIW, I recognize that there are a lot of PRs outstanding right n= ow and it
can be confusing. I plan on merging a number of them in= over the next week
or two.

Best,
-Ekr


[0] Note that it's= easy to get git/github to give you the state of the document
as = a whole after a PR is merged.

[1] The PR in questi= on doesn't do that, but that's because I was asked to
do = an initial treatment to see if people liked it and s I tried to do the mini= mum
to accomplish that.


<= br>


--089e0103eecaa01c730508b6957d-- From nobody Tue Nov 25 15:25:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31E1A1F73 for ; Tue, 25 Nov 2014 15:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwA_J077-ibj for ; Tue, 25 Nov 2014 15:25:15 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30981A1EF5 for ; Tue, 25 Nov 2014 15:25:15 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id f51so1267889qge.32 for ; Tue, 25 Nov 2014 15:25:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=sj+WJ18vQ9bVWA9uLASz/K+gRptpVdkQlU82Uurf7qc=; b=Z+Ct8lAtaqG86oKo5aVQDvykdSBXb2jBILFOZa1pvWLMO5nDmBPhWMQ0ghOPZ+eh/y EJyIi5XZZv5GE+CKxnxNtETKyAEiEZ7KTtRUwkDtoyqt+GBdiMg11IOddjWMSamKzN/n iKqdC0IIPwVDi/HbWOjQwVDobtIkAv7ZHinyzqL+xiqtEOi/bngOiCTKXxJfPXMlwFHk PZXGyGYRfiHpUxcbqkUWfgsABh1du4nNFCVr2TMcD7jJ40qXytYLwbJnAnOHH4BpzOeU P55S3HodEGuLzkv9AaMglZRMFzhitHwYu7H2O8WsQWIM6pn8Gyqsf45Hoie9cU8aaWXa 8jMQ== X-Gm-Message-State: ALoCoQnuj1iBHCwQlCMV4GeJi0dEEjV+ow+ptfUbvWPspKmTHzofSGVPri5Vp71jPPROZid0z5u1 X-Received: by 10.140.81.6 with SMTP id e6mr5875697qgd.90.1416957914907; Tue, 25 Nov 2014 15:25:14 -0800 (PST) Received: from ?IPv6:2601:a:2a00:381:90e2:9268:c74c:cd55? ([2601:a:2a00:381:90e2:9268:c74c:cd55]) by mx.google.com with ESMTPSA id n5sm2447875qat.13.2014.11.25.15.25.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Nov 2014 15:25:14 -0800 (PST) Message-ID: <54750FDC.5040909@nthpermutation.com> Date: Tue, 25 Nov 2014 18:25:16 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RaeVmUZv3A_VA318AxPi6SFC0Kw Subject: [TLS] Two Decisions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 23:25:17 -0000 First item: A/O TLS 1.2 the PRF function changed to be negotiable. During discussions for things like session hash, the question was brought up (or at least I brought it up) as to whether or not the PRF function always needed to be a hash function (vs say a block cipher function) and I think the general consensus was that it was too difficult to remove due to its use in the finish message and session hash. Would that be a fair assessment? And if so, should text be added to make this clear? (Specifically, the PRF negotiation specifies a hash, and the KDF and various other derived functions are based on the HMAC construct of that hash.) [Side comment - as I've stated before, I really would have liked to have the possibility of having a block cipher only PSK TLS implementation, but I think that given the general trend toward PFS suites which have public key type requirements, I would guess that that ship has sailed, even in the constrained device space.] Second item: The Master Secret has always been 48 bytes long. A/O TLS1.2 wouldn't it make more sense to have the output of the Pre-Master Secret to MS key derivation be a key of the native length for the KDF function? E.g. 64 bytes for HMAC SHA256? Right now, each round of the PRF function produces 32 octets (assuming HMAC-SHA256) each round so the function is run twice to get 64 octets, then left truncated to get 48 octets of the Pre Master Secret. When you get to the MS to session key negotiation, the 48 octets is right zero padded back to 64 octets in the first step of the HMAC setup. Of course for other SHA functions, the block size is larger - 128 octets for SHA384, etc requiring additional rounds in PMS to MS vs just padding. This approach is slightly more complex, but does scale automatically with choice of cipher suite. From nobody Tue Nov 25 15:43:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC021A6EEF for ; Tue, 25 Nov 2014 15:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8L4aCfTGFIc for ; Tue, 25 Nov 2014 15:43:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C871A0358 for ; Tue, 25 Nov 2014 15:43:26 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 23:43:03 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0026.003; Tue, 25 Nov 2014 23:43:03 +0000 From: Andrei Popov To: Yuhong Bao , "tls@ietf.org" , "mrex@sap.com" Thread-Topic: [TLS] MS14-066 and the TLS premaster secret version check Thread-Index: AQHQCKANe9uQDUMNukKycgPp/+r+z5xxrSOg Date: Tue, 25 Nov 2014 23:43:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(13464003)(199003)(76176999)(54606007)(50986999)(54356999)(4396001)(46102003)(54206007)(99286002)(95666004)(106356001)(15202345003)(74316001)(107886001)(107046002)(99396003)(120916001)(77096003)(62966003)(122556002)(77156002)(106116001)(105586002)(40100003)(86362001)(20776003)(92726001)(92566001)(31966008)(2201001)(2501002)(2656002)(33656002)(64706001)(87936001)(101416001)(76576001)(86612001)(97736003)(15975445006)(19580395003)(19580405001)(21056001)(7059030)(219293001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ysX7ReTt1mUXfvkP1MzUEox7sdg Subject: Re: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 23:43:29 -0000 Hi Yuhong, The interop problem related to premaster secret version check is resolved i= n Win8 and above. MS14-066 is not related: it fixes a few security issues we found internally= . Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao Sent: Tuesday, November 25, 2014 3:07 AM To: tls@ietf.org; mrex@sap.com Subject: [TLS] MS14-066 and the TLS premaster secret version check Has the incorrect premaster secret version check described in this been fix= ed in=A0MS14-066: http://www.ietf.org/mail-archive/web/tls/current/msg08139.html Yuhong Bao =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 25 16:10:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B851A89A9 for ; Tue, 25 Nov 2014 16:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrCHjKggZYKp for ; Tue, 25 Nov 2014 16:10:31 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA5F1A89A7 for ; Tue, 25 Nov 2014 16:10:31 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so1364882obc.28 for ; Tue, 25 Nov 2014 16:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nRgU7p4PtMKvqNQJRUE91lfDMeAm7EGliubzcvMEU5k=; b=AQ5WR5LqG2EUEAUHyDDbFokbfkqbK+lxHyv7hMzU4nPVQhBPr5Lr0pOzTcCT0PQqUT uu1WnLvajUYXLop2pK+jVemHK+H4x7DY0muQFYcvX8rgl2LG7Il/exU1KmuLH0kTQ9j2 PyCKoe9hvEXBt8VGfX1abMfcAMVidaOlC9YeHyDnqNtycROoe7H7JQJmn/IajDv3pxqS XIWI83EhtS4h0S5KuczIkWsb7YAA6E2t/jCex7KllXW/18mie7iojY8iyXjCk5acWgc5 vjhd5N2oGLTEWrVKymLIYlpera0kMTlDhw8R74JKUJgmu1A/XKelgZ0rMbJKad9dgtI3 GfSg== MIME-Version: 1.0 X-Received: by 10.183.24.129 with SMTP id ii1mr16187056obd.34.1416960630569; Tue, 25 Nov 2014 16:10:30 -0800 (PST) Received: by 10.202.115.4 with HTTP; Tue, 25 Nov 2014 16:10:30 -0800 (PST) In-Reply-To: <54750FDC.5040909@nthpermutation.com> References: <54750FDC.5040909@nthpermutation.com> Date: Tue, 25 Nov 2014 16:10:30 -0800 Message-ID: From: Martin Thomson To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IGr50PmAEB5-NenkcxL-tCu1h38 Cc: "tls@ietf.org" Subject: Re: [TLS] Two Decisions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 00:10:37 -0000 On 25 November 2014 at 15:25, Michael StJohns wrote: > A/O TLS 1.2 the PRF function changed to be negotiable. During discussions > for things like session hash, the question was brought up (or at least I > brought it up) as to whether or not the PRF function always needed to be a > hash function (vs say a block cipher function) and I think the general > consensus was that it was too difficult to remove due to its use in the > finish message and session hash. Would that be a fair assessment? And if > so, should text be added to make this clear? (Specifically, the PRF > negotiation specifies a hash, and the KDF and various other derived > functions are based on the HMAC construct of that hash.) One of the properties we are relying on here is preimage resistance. I believe that to be a firm requirement for exporters, for instance. That should certainly be documented as an assumption, because it does remove a number of MAC constructions from consideration. The 48-byte thing always bothered me a little. If the PRF produces any MS that is shorter, it's not like it contains any less entropy when talking about traffic key derivation. I'd be inclined to say that a single crank of the PRF is all that is needed for any of the long-term keys, which will mean more or less than 48 depending on the negotiated PRF. I don't think that this is significantly more complex. And if we are running more PRFs, it might save a few cycles at a critical moment (i.e., the handshake). From nobody Tue Nov 25 16:28:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDC31A87E2 for ; Tue, 25 Nov 2014 16:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT_pFUVJGX4K for ; Tue, 25 Nov 2014 16:28:17 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D851A7001 for ; Tue, 25 Nov 2014 16:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1416961698; x=1448497698; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=6vadzZBSigX6tQynPMr6iZe/gbebjU8WKr+QhvYxsWM=; b=JqGXlyo+h1tMNM/WYK8APpFiPyuCF0WX7box3hDr3FcMlmJWxOp7oqdw BVsfqW8J8VjC1U/HKyufBkeWL+WCee4pbaXwqE3h43y7r3pzvTkfFewpD zVCauc5S6Y5Ym0ZumaH2EyWTmLCKl+OrabZ9aM+/HarF+50OFpV+VTROn I=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="293132580" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Nov 2014 13:28:15 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 26 Nov 2014 13:28:14 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Rethink TLS 1.3 Thread-Index: AdAJD90zClhBf9VhRayMCXccfbZNpA== Date: Wed, 26 Nov 2014 00:28:13 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9F4F82@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rfHC-d8v64LFQGqyjFveN0vklmo Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 00:28:23 -0000 Nico Williams writes:=0A= =0A= >Or, to put it differently, we need to state an Internet threat model=0A= >succintly.=0A= =0A= Exactly. The Internet Threat Model is frequently referred to, but I have n= o=0A= idea what it actually is. AFAIK it's either:=0A= =0A= "I'm OK, you're OK, and the network is the problem".=0A= =0A= a quaint relic from the 1980s that hasn't been relevant for 15-20 years, or= =0A= what I've referred to as the Inside-Out Threat Model:=0A= =0A= "The threat model is defined to be whatever it is that our crypto counter= s".=0A= =0A= Neither of these are very useful. In other words, we don't actually have a= =0A= threat model, just a cardboard cut-out that we point to and say "look, we= =0A= defend against that!".=0A= =0A= Peter.= From nobody Tue Nov 25 16:37:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE63B1A8729 for ; Tue, 25 Nov 2014 16:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBO29D52Ak01 for ; Tue, 25 Nov 2014 16:37:44 -0800 (PST) Received: from BLU004-OMC4S13.hotmail.com (blu004-omc4s13.hotmail.com [65.55.111.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9341E1A6EE1 for ; Tue, 25 Nov 2014 16:37:44 -0800 (PST) Received: from BLU177-W2 ([65.55.111.136]) by BLU004-OMC4S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 25 Nov 2014 16:37:43 -0800 X-TMN: [q7BOBn7BifCAkXlvdSO9t77OZ7Bd251i] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Andrei Popov , "tls@ietf.org" , "mrex@sap.com" Date: Tue, 25 Nov 2014 16:37:43 -0800 Importance: Normal In-Reply-To: References: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2014 00:37:43.0905 (UTC) FILETIME=[313EFD10:01D00911] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jQNkbWi73BYXEX5RgWnE-FhgA_s Subject: Re: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 00:37:45 -0000 I asked because it backported a lot of Win8.1 SChannel in addition to the s= ecurity fixes.=0A= To be honest=2C they screwed up the backport of the new GCM cipher suites a= nyway=2C=A0=0A= and to fix this will require a new SChannel=2C right?=0A= =0A= ----------------------------------------=0A= > From: Andrei.Popov@microsoft.com=0A= > To: yuhongbao_386@hotmail.com=3B tls@ietf.org=3B mrex@sap.com=0A= > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check=0A= > Date: Tue=2C 25 Nov 2014 23:43:03 +0000=0A= >=0A= > Hi Yuhong=2C=0A= >=0A= > The interop problem related to premaster secret version check is resolved= in Win8 and above.=0A= >=0A= > MS14-066 is not related: it fixes a few security issues we found internal= ly.=0A= >=0A= > Cheers=2C=0A= >=0A= > Andrei=0A= >=0A= > -----Original Message-----=0A= > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao=0A= > Sent: Tuesday=2C November 25=2C 2014 3:07 AM=0A= > To: tls@ietf.org=3B mrex@sap.com=0A= > Subject: [TLS] MS14-066 and the TLS premaster secret version check=0A= >=0A= > Has the incorrect premaster secret version check described in this been f= ixed in MS14-066:=0A= > http://www.ietf.org/mail-archive/web/tls/current/msg08139.html=0A= >=0A= > Yuhong Bao=0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tls=0A= = From nobody Tue Nov 25 17:14:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610971A86E1 for ; Tue, 25 Nov 2014 17:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_gjXc_-l7LN for ; Tue, 25 Nov 2014 17:14:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5381A6FAC for ; Tue, 25 Nov 2014 17:14:21 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 01:13:58 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 01:13:58 +0000 From: Andrei Popov To: Yuhong Bao , "tls@ietf.org" , "mrex@sap.com" Thread-Topic: [TLS] MS14-066 and the TLS premaster secret version check Thread-Index: AQHQCKANe9uQDUMNukKycgPp/+r+z5xxrSOggABj/oCAAAAcQA== Date: Wed, 26 Nov 2014 01:13:58 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(3905003)(377454003)(52314003)(13464003)(189002)(46102003)(99286002)(21056001)(92566001)(2201001)(106116001)(105586002)(92726001)(33656002)(95666004)(106356001)(120916001)(86362001)(101416001)(2656002)(15975445006)(54206007)(50986999)(15202345003)(122556002)(76176999)(54356999)(107886001)(87936001)(4396001)(54606007)(107046002)(99396003)(76576001)(62966003)(77096003)(77156002)(40100003)(97736003)(2501002)(31966008)(74316001)(64706001)(19580395003)(19580405001)(86612001)(20776003)(7059030)(3826002)(219293001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iuVYkH30rY6uF0KoXo7u4ciJIJE Subject: Re: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 01:14:23 -0000 > I asked because it backported a lot of Win8.1 SChannel in addition to the= security fixes. In addition to security fixes, MS14-066 includes a back-port of cipher suit= es added by KB 2919355 (http://support.microsoft.com/kb/2919355). Unfortunately, MS14-066 includes the wrong version of a kernel binary, so i= t only adds the new ciphers for user-mode SSPI callers. When a kermel-mode = SSPI caller (e.g. HTTP.SYS) negotiates one of the newly added cipher suites= , the connection fails at the end of the handshake. Update 3018238 disables= these new cipher suites, for now. > To be honest, they screwed up the backport of the new GCM cipher suites a= nyway, and to fix this will require a new SChannel, right? I expect that there will be a new update that will include the correct bina= ries, so the new cipher suites will work for the kernel-mode SSPI callers. Cheers, Andrei -----Original Message----- From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com]=20 Sent: Tuesday, November 25, 2014 4:38 PM To: Andrei Popov; tls@ietf.org; mrex@sap.com Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check I asked because it backported a lot of Win8.1 SChannel in addition to the s= ecurity fixes. To be honest, they screwed up the backport of the new GCM cipher suites any= way, and to fix this will require a new SChannel, right? ---------------------------------------- > From: Andrei.Popov@microsoft.com > To: yuhongbao_386@hotmail.com; tls@ietf.org; mrex@sap.com > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check > Date: Tue, 25 Nov 2014 23:43:03 +0000 > > Hi Yuhong, > > The interop problem related to premaster secret version check is resolved= in Win8 and above. > > MS14-066 is not related: it fixes a few security issues we found internal= ly. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao > Sent: Tuesday, November 25, 2014 3:07 AM > To: tls@ietf.org; mrex@sap.com > Subject: [TLS] MS14-066 and the TLS premaster secret version check > > Has the incorrect premaster secret version check described in this been f= ixed in MS14-066: > http://www.ietf.org/mail-archive/web/tls/current/msg08139.html > > Yuhong Bao > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls =20 From nobody Tue Nov 25 17:17:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B871A7021 for ; Tue, 25 Nov 2014 17:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5HhrMQNW8QJ for ; Tue, 25 Nov 2014 17:17:32 -0800 (PST) Received: from BLU004-OMC4S25.hotmail.com (blu004-omc4s25.hotmail.com [65.55.111.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1411A6FAC for ; Tue, 25 Nov 2014 17:17:32 -0800 (PST) Received: from BLU177-W40 ([65.55.111.137]) by BLU004-OMC4S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 25 Nov 2014 17:17:31 -0800 X-TMN: [wtVzHEah86OZwAoFlQVGMJYEzrkGlmvF] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Andrei Popov , "tls@ietf.org" , "mrex@sap.com" Date: Tue, 25 Nov 2014 17:17:31 -0800 Importance: Normal In-Reply-To: References: , , , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2014 01:17:31.0662 (UTC) FILETIME=[C075CAE0:01D00916] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2Ptxt3-ridQLtD057rLE-4trie8 Subject: Re: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 01:17:34 -0000 The point was that since a new version of SChannel will be shipped with the= new update anyway=2C=0A= it should be easy to backport the fix for the TLS premaster secret version = check to this new version.=0A= =0A= ----------------------------------------=0A= > From: Andrei.Popov@microsoft.com=0A= > To: yuhongbao_386@hotmail.com=3B tls@ietf.org=3B mrex@sap.com=0A= > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check=0A= > Date: Wed=2C 26 Nov 2014 01:13:58 +0000=0A= >=0A= >> I asked because it backported a lot of Win8.1 SChannel in addition to th= e security fixes.=0A= >=0A= > In addition to security fixes=2C MS14-066 includes a back-port of cipher = suites added by KB 2919355 (http://support.microsoft.com/kb/2919355).=0A= >=0A= > Unfortunately=2C MS14-066 includes the wrong version of a kernel binary= =2C so it only adds the new ciphers for user-mode SSPI callers. When a kerm= el-mode SSPI caller (e.g. HTTP.SYS) negotiates one of the newly added ciphe= r suites=2C the connection fails at the end of the handshake. Update 301823= 8 disables these new cipher suites=2C for now.=0A= >=0A= >> To be honest=2C they screwed up the backport of the new GCM cipher suite= s anyway=2C and to fix this will require a new SChannel=2C right?=0A= >=0A= > I expect that there will be a new update that will include the correct bi= naries=2C so the new cipher suites will work for the kernel-mode SSPI calle= rs.=0A= >=0A= > Cheers=2C=0A= >=0A= > Andrei=0A= >=0A= > -----Original Message-----=0A= > From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com]=0A= > Sent: Tuesday=2C November 25=2C 2014 4:38 PM=0A= > To: Andrei Popov=3B tls@ietf.org=3B mrex@sap.com=0A= > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check=0A= >=0A= > I asked because it backported a lot of Win8.1 SChannel in addition to the= security fixes.=0A= > To be honest=2C they screwed up the backport of the new GCM cipher suites= anyway=2C and to fix this will require a new SChannel=2C right?=0A= >=0A= > ----------------------------------------=0A= >> From: Andrei.Popov@microsoft.com=0A= >> To: yuhongbao_386@hotmail.com=3B tls@ietf.org=3B mrex@sap.com=0A= >> Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check= =0A= >> Date: Tue=2C 25 Nov 2014 23:43:03 +0000=0A= >>=0A= >> Hi Yuhong=2C=0A= >>=0A= >> The interop problem related to premaster secret version check is resolve= d in Win8 and above.=0A= >>=0A= >> MS14-066 is not related: it fixes a few security issues we found interna= lly.=0A= >>=0A= >> Cheers=2C=0A= >>=0A= >> Andrei=0A= >>=0A= >> -----Original Message-----=0A= >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao=0A= >> Sent: Tuesday=2C November 25=2C 2014 3:07 AM=0A= >> To: tls@ietf.org=3B mrex@sap.com=0A= >> Subject: [TLS] MS14-066 and the TLS premaster secret version check=0A= >>=0A= >> Has the incorrect premaster secret version check described in this been = fixed in MS14-066:=0A= >> http://www.ietf.org/mail-archive/web/tls/current/msg08139.html=0A= >>=0A= >> Yuhong Bao=0A= >> _______________________________________________=0A= >> TLS mailing list=0A= >> TLS@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tls=0A= >=0A= = From nobody Tue Nov 25 17:47:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A111A86EA for ; Tue, 25 Nov 2014 17:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1WXkmwIom4k for ; Tue, 25 Nov 2014 17:47:15 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A908F1A1F04 for ; Tue, 25 Nov 2014 17:47:15 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 7164C2C806B for ; Tue, 25 Nov 2014 17:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=EyUoesUn/dUTWEEfBXWL UXCUqqc=; b=bdxr9NgFzcrY2mc5XDQswlUuspYVPO91pm58ZrQ6cwuZ4UcxsuV5 2ETqJjJwpj5oJqyySqi69cMoLCjAiUjbC/vj8KuLbVCH65yHfbDTlKJoa2YPgLJP 8324QExZF+qZsfrbo+p0sK369NJ1uQp2NlIvIotBPTGletjT9SxI4Qk= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 477BE2C8058 for ; Tue, 25 Nov 2014 17:47:15 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so10953288wib.16 for ; Tue, 25 Nov 2014 17:47:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.195.11.68 with SMTP id eg4mr42641641wjd.18.1416966434104; Tue, 25 Nov 2014 17:47:14 -0800 (PST) Received: by 10.216.32.136 with HTTP; Tue, 25 Nov 2014 17:47:13 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9F4F82@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9F4F82@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 25 Nov 2014 19:47:13 -0600 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UMWG7U751txodltHjBKWkQORsXc Cc: "" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 01:47:16 -0000 On Tue, Nov 25, 2014 at 6:28 PM, Peter Gutmann wrote: > Nico Williams writes: >>Or, to put it differently, we need to state an Internet threat model >>succintly. > > Exactly. The Internet Threat Model is frequently referred to, but I have no > idea what it actually is. AFAIK it's either: > > "I'm OK, you're OK, and the network is the problem". > > a quaint relic from the 1980s that hasn't been relevant for 15-20 years, or > what I've referred to as the Inside-Out Threat Model: Yes, it's quaint. It's also as best we can do, unless... > "The threat model is defined to be whatever it is that our crypto counters". > > Neither of these are very useful. In other words, we don't actually have a > threat model, just a cardboard cut-out that we point to and say "look, we > defend against that!". Tell us how to go from "we assume we have local security" to "we have local security". I'm all ears :) Nico -- From nobody Tue Nov 25 17:51:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E131A1EB7 for ; Tue, 25 Nov 2014 17:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5fXod6zp_hB for ; Tue, 25 Nov 2014 17:51:37 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 53AA41A1E0F for ; Tue, 25 Nov 2014 17:51:37 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 36A83438079; Tue, 25 Nov 2014 17:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ivUlIliKbUdDFs ykHACnF3grS/Y=; b=LtVo0mB0J5/q0dR/uvm1y3TvUJ5zkYaOW4bBLDi09yGDIU BmAa7V/zMRc4QJexCRWVg2xO3oOcXavYoj5VPF7aCs1sfOhU0RrA50CwOtDQow+o aPJcVaoLwW638pzHvCjeuRogVed6KAa+p60NrA2KqrpL7idBhJ8Jz751wU1PA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id D7056438072; Tue, 25 Nov 2014 17:51:36 -0800 (PST) Date: Tue, 25 Nov 2014 19:51:36 -0600 From: Nico Williams To: Hoeteck Wee Message-ID: <20141126015133.GX3200@localhost> References: <20141124063304.GA3200@localhost> <20141125034915.GT3200@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C1xJn4VkukASfyILPDZlU3RoMkI Cc: "tls@ietf.org" Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 01:51:38 -0000 On Wed, Nov 26, 2014 at 12:54:07AM +0100, Hoeteck Wee wrote: > > Hmm, a client that can't keep a shared secret around probably can't keep > > a server sub-cert either... > > I don't think that is correct. If an adversary learns the shared > secret held by the client in resumption, then the session gets > compromised and the adversary can decrypt all of the data that gets > sent later. If an adversary learns the server sub-cert g^s held by the > client, no security is lost. That is quite true, and I conceded that clients can have different tolerance for sub-cert freshness than resumption state lifetime, but I thought the meaning of "can't" wasn't "because of policy" but "because of lack of storage". From nobody Tue Nov 25 20:46:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE49C1A6FF3 for ; Tue, 25 Nov 2014 20:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwbzMlsECC3m for ; Tue, 25 Nov 2014 20:46:54 -0800 (PST) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.21.22]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECF91A1B86 for ; Tue, 25 Nov 2014 20:46:53 -0800 (PST) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 561636B4E8C7B; Tue, 25 Nov 2014 22:46:53 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 41AFE6B4E8BDA for ; Tue, 25 Nov 2014 22:46:53 -0600 (CST) Received: from [96.231.218.201] (port=65441 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XtUVA-0000cc-Ko for tls@ietf.org; Tue, 25 Nov 2014 22:46:52 -0600 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8FB8D433-184E-41DA-8DBD-E929B9E8E9C2@ieca.com> Date: Tue, 25 Nov 2014 23:46:54 -0500 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1XtUVA-0000cc-Ko X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:65441 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0PBMII3cPBWmLIRNXPK4XLuP9To Subject: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 04:46:54 -0000 All, This message initiates the 2nd WGLC for = draft-ietf-tls-downgrade-scsv-02. Please review the document and send = your comments to the list by Friday, December 12, 2014. Version -00 was the subject of the 1st WGLC and there have been two = version since then addressing issue raised during WGLC. As result, = normative language was added to the draft and the chairs believe this = warrants a 2nd WGLC. The scope of this WGLC is however limited to = making sure that the text that has been added represents WG consensus. = For example, rehashing whether the documented solution should use an = extension or cipher suite is not in scope of this review. Mahalo, J&S (as chairs)= From nobody Tue Nov 25 22:47:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356EE1A1B8D for ; Tue, 25 Nov 2014 22:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc8K224-pDoX for ; Tue, 25 Nov 2014 22:47:46 -0800 (PST) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.216.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C3A1A1A34 for ; Tue, 25 Nov 2014 22:47:46 -0800 (PST) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 78D59563FA23B; Wed, 26 Nov 2014 00:47:45 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 69991563FA1F4 for ; Wed, 26 Nov 2014 00:47:45 -0600 (CST) Received: from [96.231.218.201] (port=49728 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XtWO8-0007ak-5v; Wed, 26 Nov 2014 00:47:44 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> Date: Wed, 26 Nov 2014 01:47:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com> To: "TLS@ietf.org (tls@ietf.org)" , Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1XtWO8-0007ak-5v X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:49728 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/77AwEmn46jcLw8FB-UbhgaCIRpk Subject: [TLS] closing - Re: STRAW POLL: Size of the Minimum FF DHE group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 06:47:47 -0000 Thanks to all those who participated in this poll, but after three weeks = it=92s time to close this poll. The rough consensus expressed on this = list is for 2048 as the minimum FF DHE group size. dkg - please make the appropriate changes in the draft. While you=92re = at it, please go ahead and add text to address the comment from the mic = for a reference to how one can check that the primes are prime. Once dkg posts as new version we=92ll initiate a WGLC. As noted during = the TLS session in Hawaii, the chairs make a point to ensure whether = using new groups vs the old IKE groups is an issue. Cheers, J&S (as chairs) On Nov 04, 2014, at 12:49, Sean Turner wrote: > Hi! >=20 > At the TLS Interim meeting in Paris, the WG discussed the FF DHE draft = (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/). = The chairs would like to poll the WG on one of the issues in the draft = namely the size of the minimum group. >=20 > The draft currently includes a minimum group size of 2432 but the WG = also discussed 2048. Groups smaller than 2048 were discounted for a = standards track document as too weak for use but might be documented in = a separate =93historic=94 draft. To help us reach consensus on this = point, please reply to this email indicating whether you favor a =932048" = or =932432=94 minimum group size. Note we=92re also looking to specify = the smallest number of options for groups as is acceptable - i.e., we=92re= not looking at specifying both 2048 and 2432. >=20 > Background: Regardless of whether you agree with what follows or not, = the following has been put forward as the rationale. We don=92t need = comments on the rationale, we=92re just providing it for background. >=20 > 1) 3DES has a 112-bit work factor and is still considered acceptable = in TLS 1.2 and the DLOG keying material shouldn=92t be any weaker than = the symmetric cipher. >=20 > 2) There is some disagreement about the work factor for the DLOG keys = - e.g., NIST says 112-bit work factor correlates to 2048-bit DLOG keys = but ECRYPT-II says 112-bit work factor correlates to 2432-bit DLOG keys = (see references in draft). >=20 > 3) The other point made about 2048-bit DLOG is that it=92s a power of = 2 and there=92s parity with the public key sizes. >=20 > Cheers, > j&s From nobody Tue Nov 25 23:40:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149391A0018 for ; Tue, 25 Nov 2014 23:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5uHtMDgDDzN for ; Tue, 25 Nov 2014 23:40:13 -0800 (PST) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3341A1B9C for ; Tue, 25 Nov 2014 23:40:13 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAQ7eDWW012748; Wed, 26 Nov 2014 02:40:13 -0500 Date: Wed, 26 Nov 2014 02:40:12 -0500 (EST) From: Nikos Mavrogiannopoulos To: Eric Rescorla Message-ID: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: Signed messages should be prefixed with a NUL-terminated context string. Thread-Index: se3lQURv69/UGYFxKHBKpZG8LoC9vA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2TTpn1TD7eGS-CnSXo6bToybpL0 Cc: tls@ietf.org Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 07:40:18 -0000 ----- Original Message ----- > This seems like a good idea. Thanks for raising it. An additional issue of switching to the new CertificateVerify format for client and server, is that privilege separation for authentication is not possible any more. On a previous mail I was asking for that feature to be extended for the server as well: http://www.ietf.org/mail-archive/web/tls/current/msg13398.html Was the removal of that protocol feature intentional? If not I'd suggest the following format for the signatures: struct { digitally-signed struct { opaque client_random[32]; opaque server_random[32]; opaque handshake_messages[handshake_messages_length]; } } CertificateVerify; regards, Nikos From nobody Tue Nov 25 23:46:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E7B1A1BCA for ; Tue, 25 Nov 2014 23:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lXSaURO2lrX for ; Tue, 25 Nov 2014 23:46:48 -0800 (PST) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6571A000E for ; Tue, 25 Nov 2014 23:46:48 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sAQ7kk8c004312; Wed, 26 Nov 2014 02:46:46 -0500 Date: Wed, 26 Nov 2014 02:46:46 -0500 (EST) From: Nikos Mavrogiannopoulos To: Watson Ladd Message-ID: <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: Rethink TLS 1.3 Thread-Index: 32+rwyEkLCs0m0tntk3uI3S30AF/tA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dqo0yw4Tpva06vjjIWDKBsYURp4 Cc: tls@ietf.org Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 07:46:54 -0000 ----- Original Message ----- > On Nov 25, 2014 1:10 PM, "Joseph Salowey" wrote: > As for improvents, how about finding an existing, conservatively designed > signature based key agreement mechanism with the right properties, and > using it? The current proposal has two distinct client auth mechanisms, one > in the handshake and the other in update. That does not need to be in TLS 1.3. New ciphersuites can be defined independently. > Parsing TLS is one of the biggest issues in implementations. I can't > promise to write the tool to auto-generate the parser, but we should be > sufficiently chastised by all those who tried and failed to parse TLS > records with handwritten C to consider not doing it ourselves. Where does this come from? TLS is one of the easiest protocols to parse. regards, Nikos From nobody Wed Nov 26 01:36:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852001A86EE for ; Wed, 26 Nov 2014 01:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NHo8xwxEkCk for ; Wed, 26 Nov 2014 01:36:02 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191BA1A702F for ; Wed, 26 Nov 2014 01:36:01 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0MDa6j-1XhC8B0MST-00GqSQ; Wed, 26 Nov 2014 10:35:58 +0100 Received: by mail-ob0-f182.google.com with SMTP id m8so1888514obr.13 for ; Wed, 26 Nov 2014 01:35:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.79.10 with SMTP id f10mr19845426obx.4.1416994554664; Wed, 26 Nov 2014 01:35:54 -0800 (PST) Received: by 10.60.32.42 with HTTP; Wed, 26 Nov 2014 01:35:54 -0800 (PST) In-Reply-To: <8FB8D433-184E-41DA-8DBD-E929B9E8E9C2@ieca.com> References: <8FB8D433-184E-41DA-8DBD-E929B9E8E9C2@ieca.com> Date: Wed, 26 Nov 2014 10:35:54 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e40141460ef0508bfc1a7 X-Provags-ID: V02:K0:XiTXdvJL3X1Tlot/HRPsFlpwW47c/P23mHfRWUPaWxl V/jm5W9MVfOSWQOhAAyp56l7c3skoAEz9Z3ZjE55Q0UXjxzUor 1edi/IecCt8NTICByTBjS709AkvRc3e0S1oVvNZdxRyYMD48G3 Cy5tnrWwb5+mLqsAYgE6Yk/2TzBYvLLkpQKEVfAZCnhU3Vyxc2 3V5ZjnWP0UDJKfkUW1MPoxrm8DgUSnE25AdMJ1YFmNdJVA2DLs +P8gYX44+L8EmAefaZC+bez3ZoHs8MGoOuajsUxNuPk6nV3lLx IacYuukmWWZJBUbgrM/P1nl48ZpS+rZoRemaYm4o7aD9QKffpi eSRzsuDj8kIMN8YnuHd44RCmijq0R6XS8dh0UUhKUtOSVfba68 e896PrqEDeG6lqHrhmdh/Yrj5uJoRqLXJ06oUWYBtTB93PTmnF DCc4t X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NOH1TR1caLyhxQsH62JqOjs-zZo Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 09:36:05 -0000 --047d7b2e40141460ef0508bfc1a7 Content-Type: text/plain; charset=UTF-8 Sean Turner : This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02. > Please review the document and send your comments to the list by Friday, > December 12, 2014. > > [...] The scope of this WGLC is however limited to making sure that the > text that has been added represents WG consensus. For example, rehashing > whether the documented solution should use an extension or cipher suite is > not in scope of this review. > The relevant part from the IETF-91 minutes ( http://www.ietf.org/proceedings/91/minutes/minutes-91-tls): Downgrading SCSV Very close to finished with WG LC Martin Thompson: still questions of how the step-by-step is done Maybe specify what version you tried and failed Andrei Popov: Would like this to be an extension Ekr (Eric Rescorla): There are only a few things, so we can just make a few SCSV Martin: Already shipped, and is willing to live with the current limitations Ekr: Are we going to break IE if we support this? That would suck Andrei: Can live with the current draft Martin: Their numbers show the step-by-step is stupid Joe Salowey: Will be another WG LC on this More people mentioned other weird cases The question of doing a step-by-step downgrade or not (as mentioned in the above) has come up on the list too: http://www.ietf.org/mail-archive/web/tls/current/msg14579.html http://www.ietf.org/mail-archive/web/tls/current/msg14591.html http://www.ietf.org/mail-archive/web/tls/current/msg14596.html As discussed there, trying protocol version in non-consecutive order isn't strictly disallowed by or impossible with draft-ietf-tls-downgrade-scsv-02, although I personally do think that it is a bad tradeoff and doing a step-by-step downgrade is not stupid -- see also https://www.ietf.org/jabber/logs/tls/2014-11-13.html: [19:13:16] MIC: If the server does not support the SCSV and you fall back by accident (network glitch), falling back to TLS 1.1 is better than to TLS 1.0. As mentioned before, the point of draft-ietf-tls-downgrade-scsv-02 is not to specify that or how clients should be doing fallbacks (ideally, there'd never be a need to), since this involves moving targets -- broken servers --, and all fallback connection attempts will be equally useless with servers that are current and correct. The point of this specification is to provide a simple and easy-to-deploy mechanism to help avoid downgrade attacks *if* clients choose to fall back to improve interoperability with broken servers. A detailed discussion of whether and how to fall back necessarily depends on the deployment status of legacy servers with a specific application protocol, and so is subject to change across space and time, and much more complex than would be appropriate for draft-ietf-tls-downgrade-scsv-02. The UTA WG is considering to create a BCP document on the fallback dance; see http://www.ietf.org/proceedings/91/minutes/minutes-91-uta for details. Bodo --047d7b2e40141460ef0508bfc1a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sean= Turner <turners@ieca.com>:
<= br>
This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02.= =C2=A0 =C2=A0Please review the document and send your comments to the list = by Friday, December 12, 2014.

[...] =C2=A0The scope of this WGLC is however limited to making sure that t= he text that has been added represents WG consensus.=C2=A0 For example, reh= ashing whether the documented solution should use an extension or cipher su= ite is not in scope of this review.

The= relevant part from the IETF-91 minutes (http://www.ietf.org/p= roceedings/91/minutes/minutes-91-tls):
        Downgrading SCS=
V
                Very close to finished with WG LC
                Martin Thompson: still questions of how the step-by-step is=
 done
                        Maybe specify what version you tried and failed
                Andrei Popov: Would like this to be an extension
                Ekr (Eric Rescorla): There are only a few things, so we can=
 just make a few SCSV
                Martin: Already shipped, and is willing to live with the cu=
rrent limitations
                Ekr: Are we going to break IE if we support this? That woul=
d suck
                Andrei: Can live with the current draft
                Martin: Their numbers show the step-by-step is stupid
                Joe Salowey: Will be another WG LC on this
                More people mentioned other weird cases
The question of doing a step-by-step downgrade or not (=
as mentioned in the above) has come up on the list too:
http://www.ietf.org/mail-archive/web/tls/curren=
t/msg14579.html
http://www.ietf.org/mail-archive/w=
eb/tls/current/msg14591.html
http://www.ietf.org/m=
ail-archive/web/tls/current/msg14596.html
As discussed there, trying protocol version in non-consecutive order=
 isn't strictly disallowed by or impossible with=C2=A0draft-ietf-tls-downgrade-=
scsv-02, althou=
gh I personally do think that it is a bad tradeoff and doing a step-by-step=
 downgrade is not stupid -- see also=C2=A0https://www.ietf.org/jabber/logs/tls/2014-11-1=
3.html:<=
/font>
[19=
:13:16]=C2=A0<Bodo Moeller>=C2=A0MIC: If the server does not support the SCSV and you fa=
ll back by accident (network glitch), falling back to TLS 1.1 is better tha=
n to TLS 1.0.
As mentioned before, the point of=
=C2=A0draft-=
ietf-tls-downgrade-scsv-02 is not to specify that or how clients should be =
doing fallbacks (ideally, there'd never be a need to), since this invol=
ves moving targets -- broken servers --, and all fallback connection attemp=
ts will be equally useless with servers that are current and correct.
The point of this specification is to provide a=
 simple and easy-to-deploy mechanism to help avoid downgrade attacks *if* c=
lients choose to fall back to improve interoperability with broken servers.=
 A detailed discussion of whether and how to fall back necessarily depends =
on the deployment status of legacy servers with a specific application prot=
ocol, and so is subject to change across space and time, and much more comp=
lex than would be appropriate for=C2=A0draft-ietf-tls-downgrade-scsv-02. The UTA WG is considering to create a BCP docum=
ent on the fallback dance; see=C2=A0http://www.ietf.org/proceedings/91/minutes/minutes-91-ut=
a for details.
<=
span style=3D"white-space:normal;font-family:arial">Bodo
=
--047d7b2e40141460ef0508bfc1a7-- From nobody Wed Nov 26 02:42:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3D91A00A6 for ; Wed, 26 Nov 2014 02:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-gI4baqxgqk for ; Wed, 26 Nov 2014 02:42:02 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD651A8A3E for ; Wed, 26 Nov 2014 02:42:00 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 98C478184F; Wed, 26 Nov 2014 12:41:57 +0200 (EET) Date: Wed, 26 Nov 2014 12:41:57 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20141126104157.GA13375@LK-Perkele-VII> References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2vM8lopoeZwJpLFWGCWNSLn5XEY Cc: tls@ietf.org Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 10:42:05 -0000 On Tue, Nov 25, 2014 at 02:19:53PM -0800, Watson Ladd wrote: > > As for improvents, how about finding an existing, conservatively designed > signature based key agreement mechanism with the right properties, and > using it? The current proposal has two distinct client auth mechanisms, one > in the handshake and the other in update. The parts of TLS 1.3 that worry me the most are: - Ensuring that implementations don't screw up the 2RTT case. - Certificate authentication. And yes, both worry me much more than key exchange. Both are quite nasty problems, because it is difficult to capture those in security model. And without security model, there can be no security proof. The certificate authentication is practicularly nasty because of the interactions with TLS 1.2 certificate authentication (see the recent message) and interactions with applications. And yes, the current server authentication, the current client authentication and the proposed client authentication via update all have problems here. E.g. With current scheme, trying to resume client-authenticated session can go wrong. And the new scheme can have weird interactions with applications if client authenticates midway. -Ilari From nobody Wed Nov 26 06:10:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2500B1A0137 for ; Wed, 26 Nov 2014 06:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCyoE2kQDtxL for ; Wed, 26 Nov 2014 06:10:23 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653BE1A0089 for ; Wed, 26 Nov 2014 06:10:21 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so5103599wid.6 for ; Wed, 26 Nov 2014 06:10:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aQmNaNrg2pJhsAky3qX8C885sYmCqWHwuZxdO2V+4Mw=; b=NdfXEPUc0iK3f26KjGbb7FADijhAoksqzNrM+vL3XWvN/OUY12++8Z/0R6lRwf3Xfi lY5gNU2JoaXx9K5Cw74J7nl3DphjJ6oBFuQJa8q7YQZhI7dYPeqA3N9pQoatWZI+Q2n5 IsR+7P/n608+F8/IMw7Nxy1U8f/N4rzak86IdQ0cq/i2bxV/M9WA1aA5AXFY3W1k+HKR 9ff3rsfhLk/TL0WuchPoF3d3GjpZbh6Q1fsPFwfkh1GXnPkkZJbFWmrqIRdCW8ityTCH ePC5Er3+49hxbjbFrRNnxeXa1LCp5z8RdP1wWZxMvx0JTFE5pkFVoncoIa1hnnvVtMg+ yRow== X-Gm-Message-State: ALoCoQkt95rYIDuB9ghNwNCOLm9gn3COFLYokC/8s7iBwOl4a1U70cJXz9nmFUW9Bjq/aCfEN8zW X-Received: by 10.180.78.225 with SMTP id e1mr21424538wix.32.1417011018536; Wed, 26 Nov 2014 06:10:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 26 Nov 2014 06:09:38 -0800 (PST) In-Reply-To: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> From: Eric Rescorla Date: Wed, 26 Nov 2014 06:09:38 -0800 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=f46d043c0864672fa20508c3966f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SgAzmk4meiS_8RGmQwB5ybyNViI Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 14:10:26 -0000 --f46d043c0864672fa20508c3966f Content-Type: text/plain; charset=UTF-8 On Tue, Nov 25, 2014 at 11:40 PM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > This seems like a good idea. Thanks for raising it. > > An additional issue of switching to the new CertificateVerify > format for client and server, is that privilege separation for > authentication is not possible any more. > > On a previous mail I was asking for that feature to be extended for the > server as well: > http://www.ietf.org/mail-archive/web/tls/current/msg13398.html > > Was the removal of that protocol feature intentional? > Not really. I was aiming for unifying the structures. > If not I'd suggest the following format for the signatures: > struct { > digitally-signed struct { > opaque client_random[32]; > opaque server_random[32]; > opaque handshake_messages[handshake_messages_length]; > } > } CertificateVerify; > I've filed https://github.com/tlswg/tls13-spec/issues/97 so this doesn't get lost. If someone wants to contribute a PR so that we can have something concrete to look at that would be even better. Best -Ekr --f46d043c0864672fa20508c3966f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 25, 2014 at 11:40 PM, Nikos Mavrogiannopoulos <nmav@redhat.c= om> wrote:
----- Original Message -= ----
> This seems like a good idea. Thanks for raising it.

An additional issue of switching to the new CertificateVerify
format for client and server, is that privilege separation for
authentication is not possible any more.

On a previous mail I was asking for that feature to be extended for the
server as well:
http://www.ietf.org/mail-archive/web/tls/current/msg13398= .html

Was the removal of that protocol feature intentional?
=
Not really. I was aiming for unifying the structures.
<= div>
=C2=A0
If not I'd suggest the following format for the signatures:
=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0digitally-signed struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque client_random= [32];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque server_random= [32];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque handshake_mes= sages[handshake_messages_length];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 } CertificateVerify;

I've filed=C2=A0https://github.com/tlswg/tls13-spec/issues/97 so this doesn't= get
lost.

If someone wants to contribut= e a PR so that we can have something
concrete to look at that wou= ld be even better.

Best
-Ekr
=
--f46d043c0864672fa20508c3966f-- From nobody Wed Nov 26 06:16:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584E71A0089; Wed, 26 Nov 2014 06:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUKOzq0UfpOe; Wed, 26 Nov 2014 06:16:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1352D1A0120; Wed, 26 Nov 2014 06:16:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141126141635.7427.74227.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 06:16:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tSnWWKOP0eddAAhj2v2_-9hKmSg Cc: tls@ietf.org Subject: [TLS] Last Call: (Prohibiting RC4 Cipher Suites) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 14:16:36 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Prohibiting RC4 Cipher Suites' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions, and updates [RFC5246], [RFC4346], and [RFC2246]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ballot/ No IPR declarations have been submitted directly on this I-D. From prvs=84062dfc82=hoeteck@alum.mit.edu Tue Nov 25 15:54:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DFA1A899B for ; Tue, 25 Nov 2014 15:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8y8iRrxviTi for ; Tue, 25 Nov 2014 15:54:10 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4098E1A87C3 for ; Tue, 25 Nov 2014 15:54:10 -0800 (PST) X-AuditID: 12074411-f79fa6d000006b8a-73-547516a1de63 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 98.0C.27530.1A615745; Tue, 25 Nov 2014 18:54:09 -0500 (EST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (authenticated bits=0) (User authenticated as hoeteck@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id sAPNs7FV004946 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Nov 2014 18:54:09 -0500 Received: by mail-lb0-f170.google.com with SMTP id w7so1567260lbi.1 for ; Tue, 25 Nov 2014 15:54:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.235.196 with SMTP id uo4mr30613760lbc.66.1416959647540; Tue, 25 Nov 2014 15:54:07 -0800 (PST) Received: by 10.152.42.202 with HTTP; Tue, 25 Nov 2014 15:54:07 -0800 (PST) In-Reply-To: <20141125034915.GT3200@localhost> References: <20141124063304.GA3200@localhost> <20141125034915.GT3200@localhost> Date: Wed, 26 Nov 2014 00:54:07 +0100 Message-ID: From: Hoeteck Wee To: Nico Williams Content-Type: text/plain; charset=UTF-8 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixO6iqLtQrDTEoHevtMWn812MDoweS5b8 ZApgjOK2SUosKQvOTM/Tt0vgzvjWNZm5oIetYseh2ewNjN9Zuhg5OSQETCQO/rnCBGGLSVy4 t56ti5GLQ0jgMqPE9ZVrGCGc20wSV7etY4dw2hglHv+YwQzSwisgKHFy5hOoUaUSGy+sZQSx hQTkJK7snc0GYXtLbN11G8zmFNCT2DlhLgvEoPuMEr3L29hBEiwCqhInXj1mgRgaIDFjyVmw BcICKhIvVm0Au49NQENi7/eLYDUiApoS1+ctBRvKLOApMWXqOaAaDiBbXWL9PKEJjEKzkJw3 CyGzgJFpFaNcYk5prm5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZIwAruYJxxUu4QowAH oxIPb8Ox4hAh1sSy4srcQ4ySHExKoryOwqUhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4JRiA crwpiZVVqUX5MClpDhYlcV6+Jep+QgLpiSWp2ampBalFMFkZDg4lCd5QUaBGwaLU9NSKtMyc EoQ0EwcnyHAuKZHi1LyU1KLE0pKMeFAMxxcDoxgkxQO0dwpIO29xQWIuUBSi9RSjJceivpe9 TBwtTW+B5JvD73qZhFjy8vNSpcR5/UAaBEAaMkrz4NbB0tYrRnGg74V5b4BU8QBTHtzUV0AL mYAWxs0sBFlYkoiQkmpgVLe+Fzjf1fXQO4lHksvNbLZsSt/lIFuRsf/LnkZFb5WSPgsrw8vH TyUdD74jVnR+3aSvThZbZj7TuiBlX2Hgfvit9H1J8Xl+xx5FWCrZJs3TzUpIvPlAavmclxMl c28e2/bFfuZ/19kN1bGZBw94ScWzmh7YenGbT0qaIdd+9bd8xzje7q9/pMRSnJFoqMVcVJwI ANlE8ls2AwAA Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4b4IKOcuuFo9FY8qTCinYQxVMcs X-Mailman-Approved-At: Wed, 26 Nov 2014 09:34:01 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] Re-thinking OPTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: hoeteck@alum.mit.edu List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 08:52:47 -0000 > Hmm, a client that can't keep a shared secret around probably can't keep > a server sub-cert either... I don't think that is correct. If an adversary learns the shared secret held by the client in resumption, then the session gets compromised and the adversary can decrypt all of the data that gets sent later. If an adversary learns the server sub-cert g^s held by the client, no security is lost. A sub-cert g^s is essentially like a public key in a public-key encryption scheme, whereas the shared secret in resumption is like a secret key in a secret-key encryption scheme. Learning the public key in public-key encryption does not compromise the security of the encryption scheme; learning the secret key in a secret-key encryption scheme does. Hoeteck From nobody Wed Nov 26 09:47:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984DB1A014D for ; Wed, 26 Nov 2014 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMttrPFIZBIX for ; Wed, 26 Nov 2014 09:47:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::748]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432841A016A for ; Wed, 26 Nov 2014 09:47:32 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 17:47:09 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 17:47:09 +0000 From: Andrei Popov To: Yuhong Bao , "tls@ietf.org" , "mrex@sap.com" Thread-Topic: [TLS] MS14-066 and the TLS premaster secret version check Thread-Index: AQHQCKANe9uQDUMNukKycgPp/+r+z5xxrSOggABj/oCAAAAcQIAACwOAgAES4kA= Date: Wed, 26 Nov 2014 17:47:09 +0000 Message-ID: References: , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(3905003)(52314003)(189002)(199003)(377454003)(54356999)(76176999)(54606007)(50986999)(107886001)(31966008)(40100003)(122556002)(4396001)(21056001)(76576001)(15202345003)(99396003)(46102003)(120916001)(74316001)(54206007)(62966003)(19580395003)(15975445006)(64706001)(86362001)(2201001)(92726001)(92566001)(101416001)(20776003)(77156002)(77096003)(19580405001)(97736003)(2501002)(93886004)(105586002)(95666004)(33656002)(107046002)(106116001)(99286002)(106356001)(86612001)(87936001)(2656002)(7059030)(219293001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eGSUyQ-vrLE5UuQPR-lEWUfQaVM Subject: Re: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 17:47:34 -0000 > The point was that since a new version of SChannel will be shipped with t= he new update anyway, ... Per my previous message, this is not necessarily the case. A new update may= just include the kernel binary that was missed the first time around. No n= eed to touch schannel.dll to fix the problem with the ciphers. Cheers, Andrei -----Original Message----- From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com]=20 Sent: Tuesday, November 25, 2014 5:18 PM To: Andrei Popov; tls@ietf.org; mrex@sap.com Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check The point was that since a new version of SChannel will be shipped with the= new update anyway, it should be easy to backport the fix for the TLS prema= ster secret version check to this new version. ---------------------------------------- > From: Andrei.Popov@microsoft.com > To: yuhongbao_386@hotmail.com; tls@ietf.org; mrex@sap.com > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check > Date: Wed, 26 Nov 2014 01:13:58 +0000 > >> I asked because it backported a lot of Win8.1 SChannel in addition to th= e security fixes. > > In addition to security fixes, MS14-066 includes a back-port of cipher su= ites added by KB 2919355 (http://support.microsoft.com/kb/2919355). > > Unfortunately, MS14-066 includes the wrong version of a kernel binary, so= it only adds the new ciphers for user-mode SSPI callers. When a kermel-mod= e SSPI caller (e.g. HTTP.SYS) negotiates one of the newly added cipher suit= es, the connection fails at the end of the handshake. Update 3018238 disabl= es these new cipher suites, for now. > >> To be honest, they screwed up the backport of the new GCM cipher suites = anyway, and to fix this will require a new SChannel, right? > > I expect that there will be a new update that will include the correct bi= naries, so the new cipher suites will work for the kernel-mode SSPI callers= . > > Cheers, > > Andrei > > -----Original Message----- > From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com] > Sent: Tuesday, November 25, 2014 4:38 PM > To: Andrei Popov; tls@ietf.org; mrex@sap.com > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check > > I asked because it backported a lot of Win8.1 SChannel in addition to the= security fixes. > To be honest, they screwed up the backport of the new GCM cipher suites a= nyway, and to fix this will require a new SChannel, right? > > ---------------------------------------- >> From: Andrei.Popov@microsoft.com >> To: yuhongbao_386@hotmail.com; tls@ietf.org; mrex@sap.com >> Subject: RE: [TLS] MS14-066 and the TLS premaster secret version=20 >> check >> Date: Tue, 25 Nov 2014 23:43:03 +0000 >> >> Hi Yuhong, >> >> The interop problem related to premaster secret version check is resolve= d in Win8 and above. >> >> MS14-066 is not related: it fixes a few security issues we found interna= lly. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao >> Sent: Tuesday, November 25, 2014 3:07 AM >> To: tls@ietf.org; mrex@sap.com >> Subject: [TLS] MS14-066 and the TLS premaster secret version check >> >> Has the incorrect premaster secret version check described in this been = fixed in MS14-066: >> http://www.ietf.org/mail-archive/web/tls/current/msg08139.html >> >> Yuhong Bao >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > =20 From nobody Wed Nov 26 10:49:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B961A1A1B2E for ; Wed, 26 Nov 2014 10:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVMVroq7E15c for ; Wed, 26 Nov 2014 10:49:19 -0800 (PST) Received: from BLU004-OMC4S4.hotmail.com (blu004-omc4s4.hotmail.com [65.55.111.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C12B1A1A9B for ; Wed, 26 Nov 2014 10:49:19 -0800 (PST) Received: from BLU177-W36 ([65.55.111.137]) by BLU004-OMC4S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 26 Nov 2014 10:49:18 -0800 X-TMN: [5IdxrUmty2rS8ReTv5yZjhToj+CnnDYk] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Andrei Popov , "tls@ietf.org" , "mrex@sap.com" Date: Wed, 26 Nov 2014 10:49:18 -0800 Importance: Normal In-Reply-To: References: , , , , , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2014 18:49:18.0598 (UTC) FILETIME=[AF200A60:01D009A9] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lQBFb2kdqSYCjB5XIvcaJgFIgKg Subject: Re: [TLS] MS14-066 and the TLS premaster secret version check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 18:49:20 -0000 Yea=2C I realized it now. But I forgot to mention that they also made the m= istake of using DHE_RSA key exchange for AES GCM when the other cipher suit= es uses ECDHE_RSA. I expect at some point that AES GCM with ECDHE_RSA key e= xchange will be backported=2C like what Win10 tech preview has already.=0A= =0A= ----------------------------------------=0A= > From: Andrei.Popov@microsoft.com=0A= > To: yuhongbao_386@hotmail.com=3B tls@ietf.org=3B mrex@sap.com=0A= > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check=0A= > Date: Wed=2C 26 Nov 2014 17:47:09 +0000=0A= >=0A= >> The point was that since a new version of SChannel will be shipped with = the new update anyway=2C ...=0A= >=0A= > Per my previous message=2C this is not necessarily the case. A new update= may just include the kernel binary that was missed the first time around. = No need to touch schannel.dll to fix the problem with the ciphers.=0A= >=0A= > Cheers=2C=0A= >=0A= > Andrei=0A= >=0A= > -----Original Message-----=0A= > From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com]=0A= > Sent: Tuesday=2C November 25=2C 2014 5:18 PM=0A= > To: Andrei Popov=3B tls@ietf.org=3B mrex@sap.com=0A= > Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check=0A= >=0A= > The point was that since a new version of SChannel will be shipped with t= he new update anyway=2C it should be easy to backport the fix for the TLS p= remaster secret version check to this new version.=0A= >=0A= > ----------------------------------------=0A= >> From: Andrei.Popov@microsoft.com=0A= >> To: yuhongbao_386@hotmail.com=3B tls@ietf.org=3B mrex@sap.com=0A= >> Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check= =0A= >> Date: Wed=2C 26 Nov 2014 01:13:58 +0000=0A= >>=0A= >>> I asked because it backported a lot of Win8.1 SChannel in addition to t= he security fixes.=0A= >>=0A= >> In addition to security fixes=2C MS14-066 includes a back-port of cipher= suites added by KB 2919355 (http://support.microsoft.com/kb/2919355).=0A= >>=0A= >> Unfortunately=2C MS14-066 includes the wrong version of a kernel binary= =2C so it only adds the new ciphers for user-mode SSPI callers. When a kerm= el-mode SSPI caller (e.g. HTTP.SYS) negotiates one of the newly added ciphe= r suites=2C the connection fails at the end of the handshake. Update 301823= 8 disables these new cipher suites=2C for now.=0A= >>=0A= >>> To be honest=2C they screwed up the backport of the new GCM cipher suit= es anyway=2C and to fix this will require a new SChannel=2C right?=0A= >>=0A= >> I expect that there will be a new update that will include the correct b= inaries=2C so the new cipher suites will work for the kernel-mode SSPI call= ers.=0A= >>=0A= >> Cheers=2C=0A= >>=0A= >> Andrei=0A= >>=0A= >> -----Original Message-----=0A= >> From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com]=0A= >> Sent: Tuesday=2C November 25=2C 2014 4:38 PM=0A= >> To: Andrei Popov=3B tls@ietf.org=3B mrex@sap.com=0A= >> Subject: RE: [TLS] MS14-066 and the TLS premaster secret version check= =0A= >>=0A= >> I asked because it backported a lot of Win8.1 SChannel in addition to th= e security fixes.=0A= >> To be honest=2C they screwed up the backport of the new GCM cipher suite= s anyway=2C and to fix this will require a new SChannel=2C right?=0A= >>=0A= >> ----------------------------------------=0A= >>> From: Andrei.Popov@microsoft.com=0A= >>> To: yuhongbao_386@hotmail.com=3B tls@ietf.org=3B mrex@sap.com=0A= >>> Subject: RE: [TLS] MS14-066 and the TLS premaster secret version=0A= >>> check=0A= >>> Date: Tue=2C 25 Nov 2014 23:43:03 +0000=0A= >>>=0A= >>> Hi Yuhong=2C=0A= >>>=0A= >>> The interop problem related to premaster secret version check is resolv= ed in Win8 and above.=0A= >>>=0A= >>> MS14-066 is not related: it fixes a few security issues we found intern= ally.=0A= >>>=0A= >>> Cheers=2C=0A= >>>=0A= >>> Andrei=0A= >>>=0A= >>> -----Original Message-----=0A= >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao=0A= >>> Sent: Tuesday=2C November 25=2C 2014 3:07 AM=0A= >>> To: tls@ietf.org=3B mrex@sap.com=0A= >>> Subject: [TLS] MS14-066 and the TLS premaster secret version check=0A= >>>=0A= >>> Has the incorrect premaster secret version check described in this been= fixed in MS14-066:=0A= >>> http://www.ietf.org/mail-archive/web/tls/current/msg08139.html=0A= >>>=0A= >>> Yuhong Bao=0A= >>> _______________________________________________=0A= >>> TLS mailing list=0A= >>> TLS@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/tls=0A= >>=0A= >=0A= = From nobody Wed Nov 26 16:03:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282D51A8866 for ; Wed, 26 Nov 2014 16:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl3tR-g3CmY6 for ; Wed, 26 Nov 2014 16:03:22 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BE21A1DE2 for ; Wed, 26 Nov 2014 16:03:22 -0800 (PST) Received: by mail-yk0-f182.google.com with SMTP id 131so1754079ykp.27 for ; Wed, 26 Nov 2014 16:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cI8QLhDd/scXwn3uoMvWVdr/lIfgYfxDpk+YwOsNirc=; b=hknYLH/WguXTzhJdzpNhWX7fZwqdyeRbh5YvuQ6f/gRic4AmPXJCRrTKSMExMms3Mf h0gy5prjGIeR3Jj1yWtL4UjzRv2Xc7WZnISCwruia1sX+JX3TUFQa8LwnrKuWb+l4y3V 8fpncTofLxVmnPvuS1FxC7xad4Dku4F+9E3NeIvurJY7arNBfELXPRYeo8ZAxd6rmPXL G6AxBKflpEVv3SI0kQjLCewC/FpMHHiLPuCcbXUeHB3Fete1Mw8apZjRS6MF1bZ5JeRF mfuuXeTxhxuop920H3Ii/HqqjXkwgQcFPIOnaOgKOF84O84unq1EYdB/5xtABRummtmP KdjQ== MIME-Version: 1.0 X-Received: by 10.170.100.215 with SMTP id r206mr39581824yka.19.1417046601807; Wed, 26 Nov 2014 16:03:21 -0800 (PST) Received: by 10.170.195.21 with HTTP; Wed, 26 Nov 2014 16:03:21 -0800 (PST) In-Reply-To: <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> Date: Wed, 26 Nov 2014 16:03:21 -0800 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h8PdtYuZ5mi75O5Uk1rU4WpGU30 Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 00:03:24 -0000 On Tue, Nov 25, 2014 at 11:46 PM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- >> On Nov 25, 2014 1:10 PM, "Joseph Salowey" wrote: >> As for improvents, how about finding an existing, conservatively designed >> signature based key agreement mechanism with the right properties, and >> using it? The current proposal has two distinct client auth mechanisms, one >> in the handshake and the other in update. > > That does not need to be in TLS 1.3. New ciphersuites can be defined independently. Options add complexity, and while OPTLS had some compelling advantages, it's likely that whatever scheme ultimately is adopted will be good enough. Right now TLS 1.3 makes many big changes from TLS 1.2. This increases the minimum complexity of an implementation that has to do both. Adding a simpler option doesn't help matters, unless a complex option is removed. The result of this complexity is that it is harder to test the code that runs, and harder to analyze the implementation for correctness. > >> Parsing TLS is one of the biggest issues in implementations. I can't >> promise to write the tool to auto-generate the parser, but we should be >> sufficiently chastised by all those who tried and failed to parse TLS >> records with handwritten C to consider not doing it ourselves. > > Where does this come from? TLS is one of the easiest protocols to parse. OpenSSL couldn't parse an echo request correctly. Many of recent CVEs in OpenSSL have been related to corner cases in parsing. Microsoft got bitten by a memcpy that didn't check its length. If it was easy to parse, we wouldn't have parser bugs when parsing it. CVE-2014-3466 looks like a GnuTLS parser issue to me, and there are plenty of others to pick from. Who wrote the buggy code? Well, one Nikos Mavrogiannopoulos according to git-blame. Maybe parsing TLS with handwritten C is not so easy, after all. Sincerely, Watson Ladd > > regards, > Nikos -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Nov 27 00:13:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73A1A1BF0 for ; Thu, 27 Nov 2014 00:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkSamvAqY9ba for ; Thu, 27 Nov 2014 00:13:38 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E471A01F0 for ; Thu, 27 Nov 2014 00:13:38 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so7440458wiv.1 for ; Thu, 27 Nov 2014 00:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y0oOJWV93k9fqyRJkVUYRaCHSpLEG7RnH5p5zJpLg0o=; b=lAUUNUToED/Ug3LeNZ7Cpx7J9Eej0DYGk6wq6esmho9IHAJAaWU0FWpByA7ShR9EHd LR+C/w1ZtEMBizsmfWwb8pMU3nYwWYl4DyDhx17O+tH5pbfJspP/afEJAnChNRHLYJ1y Fbv6fe9alnBeurEktqM1uNnQ3EH/PEH99ZJ+bcCJHFUmQHO6w8Tw5NNeRnQLZeCtI14l /NNUmjIXa5Gv6uBWlfooo4todjom6gZ6LWBDzOt5/PuLY9RNNiPTjTJHBhKCMwG2hR7Q y7W/gHWrbRC7l+nzPgym0cQGy+zR6JpA6m0OC0LU74gI4MyntuJsHMwL/F5mVVNNLjGZ ytDg== X-Received: by 10.180.87.72 with SMTP id v8mr49490809wiz.22.1417076017152; Thu, 27 Nov 2014 00:13:37 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id hs1sm24187910wib.1.2014.11.27.00.13.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 00:13:36 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Thu, 27 Nov 2014 10:13:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sean Turner X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yiBPQZN70E0LN1FMB17bJtpOx6Y Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 08:13:41 -0000 Seeing as the 18th has come and gone, can I take the near silence as = confirmation that I can resubmit as a WG draft? Yoav > On Nov 11, 2014, at 5:17 AM, Sean Turner wrote: >=20 > All, >=20 > This message is confirming the WG consensus we reached in Toronto = about producing an updated RFC4492 that is bound for standard track.* = Yoav has produced an individual draft that can be found here: >=20 > http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ >=20 > that we would like the WG to consider adopting. Please let us know by = November 18th whether you object to adopting Yoav=92s draft (and why). >=20 > spt >=20 > * This is for pre-TLS 1.3 because the 1.3 spec is going to incorporate = the EC text directly in the base spec. =20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 27 01:05:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159D51A88AF for ; Thu, 27 Nov 2014 01:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id era2WKGZWY8P for ; Thu, 27 Nov 2014 01:04:59 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB9E1A88BB for ; Thu, 27 Nov 2014 01:04:52 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAR94okk019763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 27 Nov 2014 04:04:51 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAR94mJc016043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2014 04:04:50 -0500 Message-ID: <1417079088.11680.7.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Thu, 27 Nov 2014 10:04:48 +0100 In-Reply-To: References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o6BnmGMM5hbOPQfe1nRLbmBRJxI Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 09:05:01 -0000 On Wed, 2014-11-26 at 16:03 -0800, Watson Ladd wrote: > >> Parsing TLS is one of the biggest issues in implementations. I can't > >> promise to write the tool to auto-generate the parser, but we should be > >> sufficiently chastised by all those who tried and failed to parse TLS > >> records with handwritten C to consider not doing it ourselves. > > Where does this come from? TLS is one of the easiest protocols to parse. > OpenSSL couldn't parse an echo request correctly. This is a TLS extension and is known to be unnecessarily complex. It proves nothing about the TLS parsing complexity that you mention. > Many of recent CVEs > in OpenSSL have been related to corner cases in parsing. Microsoft got > bitten by a memcpy that didn't check its length. If it was easy to > parse, we wouldn't have parser bugs when parsing it. CVE-2014-3466 > looks like a GnuTLS parser issue to me, and there are plenty of others > to pick from. > Who wrote the buggy code? Well, one Nikos Mavrogiannopoulos according > to git-blame. Maybe parsing TLS with handwritten C is not so easy, > after all. I believe you try to generalize based on your very limited view. Of course there will be bugs, and I guess there will be more by that author but there will not be any protocol that cannot be implemented incorrectly. However, you cannot prove your point in the complexity of TLS record parsing, by pointing to one parsing bug in the 14 years of a project. What does it make you think this is a recurring issue? regards, Nikos From nobody Thu Nov 27 08:16:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697A61A00D1 for ; Thu, 27 Nov 2014 08:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7Ihwucc43Gf for ; Thu, 27 Nov 2014 08:16:04 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6F31A00BD for ; Thu, 27 Nov 2014 08:16:04 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id s7so3422672qap.22 for ; Thu, 27 Nov 2014 08:16:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ecWLAWWdbaxKGqlmhPloNyZ48Oz0qBUF+4ibJsCvZ0Y=; b=gzjJXtkX7HD1+Co/q1NycQQgYVZ20OjzztNWFZwMYqwuLrwFyWkJftW82LGt8sSVPf 4Vf9p2wki7mvU9RAagKvC4jDQmD1HaWCDQz/PIxZLWlCfRKsUh81DuryGLa/cXbDBMV/ 4T4DzkrdIegXyLUQuqCDACa2iKY1xV1v96UOwjPT2vn1xB9vy1J0TuuV+NUi5LYen7U/ WoeHnKKG45qGKGyN190pbVZpXGDa19lF+dKUYx8hXoaasu6bQzEL0GlEE/ucGIIkHZHY WNVIZCwASoBFJRUM3Cn3HY3SrYgWqPC+UYiS7EECu3wz5WFc5N4zRrp3H7E1gQqaMdVp SDJQ== X-Gm-Message-State: ALoCoQkbWj2VkOG4N7QJs9/vZCoqQt9eaot2Xw99vfEaAOyQXCz6wK41luozC3tad7iOmh/IMi09 X-Received: by 10.140.43.6 with SMTP id d6mr53613579qga.104.1417104963846; Thu, 27 Nov 2014 08:16:03 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id s2sm6894531qan.29.2014.11.27.08.16.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 08:16:02 -0800 (PST) Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id B6009AC2896; Thu, 27 Nov 2014 11:16:00 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: Date: Thu, 27 Nov 2014 11:15:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p1KUCYgtNHFef8Qtw6FOGJBD-7M Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 16:16:06 -0000 On Nov 27, 2014, at 3:13 AM, Yoav Nir wrote: > Seeing as the 18th has come and gone, can I take the near silence as = confirmation that I can resubmit as a WG draft? I support adopting this draft. Maybe this isn't the right time to ask, but I think I'm misunderstanding = a part of it. Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in the TLS base documents) does not impose restrictions on signature schemes used elsewhere in the certificate chain. Why should we require that the certificate be signed with the signature = scheme corresponding to the public key? It's easy to produce working = certificates that don't meet this: $ openssl genrsa -out ca.key 2048 $ openssl req -new -x509 -days 2 -key ca.key -out ca.crt -sha256 $ openssl ecparam -out server.key -name prime256v1 -genkey $ openssl req -new -sha256 -key server.key -out server.csr $ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out = server.crt -days 1 -sha256 -CAserial ca.seq -CAcreateserial Now I have a cert with a P-256 public key that is signed with signature = algorithm sha256WithRSAEncryption. That is, this does not meet the MUSTs = in your draft. Using openssl s_server and s_client, I get a connection using = ECDHE-ECDSA-AES256-GCM-SHA384. Is my reading correct that this is disallowed by the draft? If so, can = you explain why that's the case? --=20 Stephen Checkoway From nobody Thu Nov 27 14:02:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3851A006E for ; Thu, 27 Nov 2014 14:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HlXXTuqfDCh for ; Thu, 27 Nov 2014 14:02:50 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F141A0056 for ; Thu, 27 Nov 2014 14:02:50 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 68EA03A334; Thu, 27 Nov 2014 23:02:48 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 5E2BC428A7; Thu, 27 Nov 2014 23:02:48 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 533AD1B01C; Thu, 27 Nov 2014 23:02:48 +0100 (CET) In-Reply-To: To: Stephen Checkoway Date: Thu, 27 Nov 2014 23:02:48 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141127220248.533AD1B01C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G3nH_SYLQTU9ejPj9HhDABgOFE4 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 22:02:54 -0000 Stephen Checkoway wrote: > > Yoav Nir wrote: >> >> Seeing as the 18th has come and gone, can I take the near >> silence as confirmation that I can resubmit as a WG draft? > > I support adopting this draft. > > Maybe this isn't the right time to ask, but I think I'm > misunderstanding a part of it. > > Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA > key exchange algorithms require the server's certificate to be signed > with a particular signature scheme, this specification (following the > similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in the TLS base > documents) does not impose restrictions on signature schemes used > elsewhere in the certificate chain. > > Why should we require that the certificate be signed with the signature > scheme corresponding to the public key? It's easy to produce working > certificates that don't meet this: > > Using openssl s_server and s_client, > I get a connection using ECDHE-ECDSA-AES256-GCM-SHA384. This is actually perfectly reasonable behaviour of OpenSSL and a lot of other TLS implementations. > > Is my reading correct that this is disallowed by the draft? > If so, can you explain why that's the case? I assume that this might be cause by a serious and stupid defect in the TLSv1.0 and TLSv1.1 specifications that is obviously unreasonable and backwards-incompatible to SSLv3, and was only fixed in TLSv1.2 (rfc5246). https://tools.ietf.org/html/rfc2246#section-7.4.2 7.4.2. Server certificate [...] Meaning of this message: The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509v3 certificate. It must contain a key which matches the key exchange *> method, as follows. Unless otherwise specified, the signing *> algorithm for the certificate must be the same as the algorithm *> for the certificate key. Unless otherwise specified, the public *> key may be of any length. For comparison SSLv3: https://tools.ietf.org/html/rfc6101#section-5.6.2 5.6.2. Server Certificate If the server is to be authenticated (which is generally the case), the server sends its certificate immediately following the server hello message. The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509.v3 certificate (or a modified X.509 certificate in the case of FORTEZZA(tm) [FOR]). The same message type will be used for the client's response to a certificate request message. So any *new* document should advise implementors to remove any such erroneous and counterproductive "same algorithm checks" that might accidentally got implemented by an unexperienced implementor who didn't realize that this must be a defect in the spec and is backwards-incompatible to SSLv3. -Martin From nobody Thu Nov 27 14:21:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A90C1A00D8 for ; Thu, 27 Nov 2014 14:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj2MNSKJgyVF for ; Thu, 27 Nov 2014 14:21:51 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311F41A0019 for ; Thu, 27 Nov 2014 14:21:51 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so7491496wgh.27 for ; Thu, 27 Nov 2014 14:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kV4g0rff4+jGYTc+36izkE29hZ18+i05HbvVtpY7Gq0=; b=aUpZfPg0wgGsAN/T9nThDGgiXPPr/n6K41KAEnLmRA9qCtZph8HGpICRUBTB/NDnmS X70NXxfTZAJzdKS7/NOhomsvuReWYTUUDIHgcMbAE4vTLk+cd2EAbf5HqEbvOrfoj3nq aXVo/3gmFQu6TQ0QsMHKnHDIWx+D7IhIetUiHMpkUasqynM2l5NTV9AnUK1t4Fe1DPPt 9f+yak1nkxL0nbuDMu5kPXMJFrXSOQHn6hCKN56NU4s8ZuSOz4CCG+79oJ8/pplKEEjf oVPr1kXQdgUdPW2J9YHRZQ4ll0KH3LHRMQgkCWdGObOPXPT4SqK7oF2AvhthiZZgSEP7 EZVw== X-Received: by 10.180.81.7 with SMTP id v7mr54231509wix.74.1417126910002; Thu, 27 Nov 2014 14:21:50 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-228-139-23.inter.net.il. [84.228.139.23]) by mx.google.com with ESMTPSA id mw7sm13377573wib.14.2014.11.27.14.21.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 14:21:49 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Fri, 28 Nov 2014 00:21:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12F35B29-212B-43D4-AC5E-239EB3D9BF9A@gmail.com> References: To: Stephen Checkoway X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Mpg4rpGAXaxghbn9xKm5vop4d_E Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 22:21:53 -0000 > On Nov 27, 2014, at 6:15 PM, Stephen Checkoway wrote: >=20 >=20 > On Nov 27, 2014, at 3:13 AM, Yoav Nir wrote: >=20 >> Seeing as the 18th has come and gone, can I take the near silence as = confirmation that I can resubmit as a WG draft? >=20 > I support adopting this draft. >=20 > Maybe this isn't the right time to ask, but I think I'm = misunderstanding a part of it. Hi, Stephen What Martin said. Once this is accepted and -00 submitted would be a great time to raise = this or make a pull request to get rid of this (IMO silly) restriction. Yoav From nobody Thu Nov 27 14:41:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A0F1A0130 for ; Thu, 27 Nov 2014 14:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQFs2H26Xo7y for ; Thu, 27 Nov 2014 14:41:18 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D606F1A00D8 for ; Thu, 27 Nov 2014 14:41:17 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id z60so4047341qgd.6 for ; Thu, 27 Nov 2014 14:41:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=5bgRm9B2w333OmgJOTlcuZXeN/+TkDUml4b8kkbains=; b=I2HjMk4lCbL8sTajwanj6fkw0I04NLw/+JoJEAfZrbtfb7AVzdJwFNJRp4lZNbNCP1 TVHdRYvW3xGqWrASgarJiN4z1aWAConEQJlzAl9oIvF6m6RLNpFaKauLKh21JaQLBBmN CiGitg7hoZA3CugTRYkiawi6gWy5+ZAiScpFuUXpGi2zMhStHW+7KlBIcaSBBIvPSjLI FT5K/HuGKGzM63qm0F6vFeQoeZj9Ee38j6fFv2oReqQy9i/SGpwu0AAG0XFgoohAMuvd 6b52Bh+d4uvHXgccVrOhIv2R/LwtRqh3FIZwaR2V06y9eHga2MCSfRnnXArzXXWNXkmX s+/g== X-Gm-Message-State: ALoCoQl+Edma7W4bJO9ubJiBfi+72q/tuCabZLW2snZw9bGYjbu0rQSIGKsMhxX2fqUGpkn8im9+ X-Received: by 10.140.51.99 with SMTP id t90mr56714316qga.72.1417128077056; Thu, 27 Nov 2014 14:41:17 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id k4sm7733816qaf.0.2014.11.27.14.41.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 14:41:16 -0800 (PST) Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 46104AC2896; Thu, 27 Nov 2014 17:41:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <20141127220248.533AD1B01C@ld9781.wdf.sap.corp> Date: Thu, 27 Nov 2014 17:41:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <83A4C4CC-55ED-4877-8E48-B79AB257BE2E@pahtak.org> References: <20141127220248.533AD1B01C@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CY8jzA7miaC0TSLmZ95A7b12oXk Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 22:41:19 -0000 On Nov 27, 2014, at 5:02 PM, Martin Rex wrote: >=20 > This is actually perfectly reasonable behaviour of OpenSSL and a lot > of other TLS implementations. I agree it seems reasonable. It's good to know there wasn't something = subtle I was missing. >> Is my reading correct that this is disallowed by the draft? >> If so, can you explain why that's the case? >=20 >=20 > I assume that this might be cause by a serious and stupid defect in > the TLSv1.0 and TLSv1.1 specifications that is obviously unreasonable = and > backwards-incompatible to SSLv3, and was only fixed in TLSv1.2 = (rfc5246). >=20 > So any *new* document should advise implementors to remove any such > erroneous and counterproductive "same algorithm checks" that might > accidentally got implemented by an unexperienced implementor who = didn't > realize that this must be a defect in the spec and is = backwards-incompatible > to SSLv3. It makes sense that a new document shouldn't mandate unnecessarily = restrictive behavior. SSLv3 compatibility isn't high on my list of concerns though. I know you = disagree, but we should stop using SSLv3 for all of the reasons = specified in draft-thomson-sslv3-diediedie. --=20 Stephen Checkoway From nobody Thu Nov 27 15:01:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2CA1A0127 for ; Thu, 27 Nov 2014 15:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaRhrWlrcZYm for ; Thu, 27 Nov 2014 15:01:14 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09DB1A0395 for ; Thu, 27 Nov 2014 15:01:14 -0800 (PST) Received: by mail-yk0-f181.google.com with SMTP id 142so2505467ykq.12 for ; Thu, 27 Nov 2014 15:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wzr/w8eHiAZiFW+0mXqUDVSfx5eQ6B2QzGpkknaJfic=; b=EMgryr9gVdaiKHPFlZLrlFcEzLDW1YF3HeNdLqdc8qpI95jrcM81WeaUC0giVyT64N kxyHjPrF0aOZNq2zyCHSDfBJYK2h28nE/Fr/ny9IGTBME0SO5GvNJeaiJuc3uNkRVBpy Mw4/W4az+UK2WKNP4aUt6jlR8kfADKfRUbCbK4h5uB1GOcgWVVW+GArawJACoiS+xx1i nRREkNImv0+u8uWieiIu4qDt+R+ToTYwoi3+IvyPSkBzaVjYdGO7/IjYmkm43UoMNzSh k+NFqkq0Xh6tNL8Mk852w/V9qfIcKTA/k+HGrh+TtwiIgCOFwsnVGyyrsJbqE3HQu8kT cZRw== MIME-Version: 1.0 X-Received: by 10.170.207.5 with SMTP id y5mr44649879yke.28.1417129273957; Thu, 27 Nov 2014 15:01:13 -0800 (PST) Received: by 10.170.195.21 with HTTP; Thu, 27 Nov 2014 15:01:13 -0800 (PST) In-Reply-To: <1417079088.11680.7.camel@dhcp-2-127.brq.redhat.com> References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> <1417079088.11680.7.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 27 Nov 2014 15:01:13 -0800 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KT-RtSgFSPQ15Kvmd-n1oQyCF8c Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 23:01:16 -0000 On Thu, Nov 27, 2014 at 1:04 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-11-26 at 16:03 -0800, Watson Ladd wrote: > >> >> Parsing TLS is one of the biggest issues in implementations. I can't >> >> promise to write the tool to auto-generate the parser, but we should be >> >> sufficiently chastised by all those who tried and failed to parse TLS >> >> records with handwritten C to consider not doing it ourselves. >> > Where does this come from? TLS is one of the easiest protocols to parse. >> OpenSSL couldn't parse an echo request correctly. > > This is a TLS extension and is known to be unnecessarily complex. It > proves nothing about the TLS parsing complexity that you mention. The construct of a heartbeat payload is a vector. It's simpler, not more complex, than many structures in TLS. > >> Many of recent CVEs >> in OpenSSL have been related to corner cases in parsing. Microsoft got >> bitten by a memcpy that didn't check its length. If it was easy to >> parse, we wouldn't have parser bugs when parsing it. CVE-2014-3466 >> looks like a GnuTLS parser issue to me, and there are plenty of others >> to pick from. >> Who wrote the buggy code? Well, one Nikos Mavrogiannopoulos according >> to git-blame. Maybe parsing TLS with handwritten C is not so easy, >> after all. > > I believe you try to generalize based on your very limited view. Of > course there will be bugs, and I guess there will be more by that author > but there will not be any protocol that cannot be implemented > incorrectly. However, you cannot prove your point in the complexity of > TLS record parsing, by pointing to one parsing bug in the 14 years of a > project. What does it make you think this is a recurring issue? The fact that every single implementation I can think of has had RCE or memory leak resulting from parsing errors, and usually quite a few? This doesn't sound like an easy task: it seems downright difficult if a lot of talented people can't do it. The Tor project is working on writing parser generators that can deal with the sort of structure we seem driven to produce in binary protocols for precisely this reason. Contrast TLS to this http://curvecp.org/packets.html, or https://tools.ietf.org/html/rfc2812#section-2.3.1. In the first case I chop out a header, and the rest is a message content: because everything is fixed width except the last field, no tricky issues. In the second case I can use yacc. It's probably too late now, but we need to at least not make the problem worse. Sincerely, Watson Ladd > > regards, > Nikos > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Nov 27 15:41:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783631A026F for ; Thu, 27 Nov 2014 15:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v17RZLWbq7Hy for ; Thu, 27 Nov 2014 15:41:11 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD63D1A0264 for ; Thu, 27 Nov 2014 15:41:10 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id CDBC43A0EB; Fri, 28 Nov 2014 00:41:08 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id C1DC142A80; Fri, 28 Nov 2014 00:41:08 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B8FA91B01C; Fri, 28 Nov 2014 00:41:08 +0100 (CET) In-Reply-To: <83A4C4CC-55ED-4877-8E48-B79AB257BE2E@pahtak.org> To: Stephen Checkoway Date: Fri, 28 Nov 2014 00:41:08 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141127234108.B8FA91B01C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/efkXOG741dFVGA6RoI2_frfSSm4 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 23:41:12 -0000 Stephen Checkoway wrote: > > Martin Rex wrote: >> >> So any *new* document should advise implementors to remove any such >> erroneous and counterproductive "same algorithm checks" that might >> accidentally got implemented by an unexperienced implementor who didn't >> realize that this must be a defect in the spec and is backwards-incompatible >> to SSLv3. > > It makes sense that a new document shouldn't mandate unnecessarily > restrictive behavior. Such a restriction would be in direct conflict with rfc2109 section 6. http://tools.ietf.org/html/rfc2119#section-6 The original wording can be seen as a may "unless otherwise specified", because it comes entirely without rationale, without any indication why this would be a problem and with no security consideration whatsoever. > > SSLv3 compatibility isn't high on my list of concerns though. > I know you disagree, but we should stop using SSLv3 for all > of the reasons specified in draft-thomson-sslv3-diediedie. This is only relevant when looking at that statement from a viewpoint of formal correctness of an implementor, who might have been reading at rfc2246 in Summer 1999, when pretty much the entire installed base was SSLv3-capable. This wording, if it was meant to be real, would have required a TLSv1.0 server implementation to negotiate SSLv3 (and not be allowed to use TLSv1.0) if the server cert did not fulfil that requirement. Such a "requirement", especially when it comes entirely without rationale, is clearly bogus and void. -Martin From nobody Thu Nov 27 22:51:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476211A1A43 for ; Thu, 27 Nov 2014 22:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4tESywl9-wD for ; Thu, 27 Nov 2014 22:51:57 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A151A1A3E for ; Thu, 27 Nov 2014 22:51:56 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id bm13so4091815qab.2 for ; Thu, 27 Nov 2014 22:51:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=FHnyB8u2j4BtDZDxYYQBiqmPT9lreFKQki6U1yL3Kvg=; b=aEDGXBV4jPq2uEAgV6yVU4VRIgtGcQpaq7uMxxfSPEHedkzP4d0jwyYL+L/WPbnJum PJeToOgZF11tUzJ7FY4asQGwIqak3GlevCXlre+JvKvCxEay6xluV+PwRQGfYoSW+k38 sATS1t93fUw9NvWyWxCb67xj8Z7R5Qx1jxHMLFPEKT7xt8t5QwSNpkAJ2qcrdbZ7qe7e qXA/+AESCK3JtGqOwzR8mDiYrgJxGszGjyubjveJHrSIwHkXcHb41u2D2Ql42FhHkECk mLHJhBJCOTEMgVOQo6Lw6C30cUAG3mN/m9L3x4tAORHW33Bci6TCtC/V2jX/qnGHYNaE P3MA== X-Gm-Message-State: ALoCoQnPPMvLsyUy1RYnSMLiLWjFmHpl/dW7uUmwPg26f4sfXTwSW0QR9X0ABfOSiMjunCIclGXv X-Received: by 10.224.173.8 with SMTP id n8mr61397569qaz.49.1417157516167; Thu, 27 Nov 2014 22:51:56 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id t5sm2922898qad.5.2014.11.27.22.51.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 22:51:55 -0800 (PST) Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 3C526AC2896; Fri, 28 Nov 2014 01:51:53 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <12F35B29-212B-43D4-AC5E-239EB3D9BF9A@gmail.com> Date: Fri, 28 Nov 2014 01:51:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12F35B29-212B-43D4-AC5E-239EB3D9BF9A@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BZiW5JMUasg6ZuzQVbhbYd3WcHw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 06:51:58 -0000 On Nov 27, 2014, at 5:21 PM, Yoav Nir wrote: > Once this is accepted and -00 submitted would be a great time to raise = this or make a pull request to get rid of this (IMO silly) restriction. Great. Sounds good to me! --=20 Stephen Checkoway From nobody Fri Nov 28 00:45:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED041A1AC6 for ; Fri, 28 Nov 2014 00:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIbX1wblRaMg for ; Fri, 28 Nov 2014 00:45:05 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90941A1ABB for ; Fri, 28 Nov 2014 00:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1417164305; x=1448700305; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uju8MCtFb25UamDLbAze8ESxMpvP3rGBjp2uwjLYoq8=; b=pv3pGXRnvU6H7t7REU1ATvzPcMiM+a7Zk2FPeiYebRorx/j/liV480Jg a7og+QwvV4wF4VRxkFDdabI+axgP9dcacoTqumcKzf+xJKNtpPjgRMSqm YrRtV8PKZk39SGn8Fn9++Q1JN4Gmfi6O3YFZBJlbUtj+T+l51LXPLsmek A=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="293657030" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Nov 2014 21:45:01 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Fri, 28 Nov 2014 21:45:01 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Rethink TLS 1.3 Thread-Index: AdAK55gq4jkCFYQCTFqXPvK/jKPC5w== Date: Fri, 28 Nov 2014 08:45:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9F68FC@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zyFYw8a5UuKl2BlxKF0SbiH2Q1A Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 08:45:10 -0000 Nico Williams writes:=0A= >On Tue, Nov 25, 2014 at 6:28 PM, Peter Gutmann=0A= > wrote:=0A= >> Exactly. The Internet Threat Model is frequently referred to, but I hav= e no=0A= >> idea what it actually is. AFAIK it's either:=0A= >>=0A= >> "I'm OK, you're OK, and the network is the problem".=0A= >>=0A= >> a quaint relic from the 1980s that hasn't been relevant for 15-20 years= =0A= >=0A= >Yes, it's quaint. It's also as best we can do, unless...=0A= =0A= If that's the best we can do then it's better to have no threat model at al= l=0A= than something that misleading, because all it's doing is giving a false se= nse=0A= of security. It doesn't even begin to capture semantics like:=0A= =0A= Alice will perform arbitrary scripted operations at the request of Mallor= y,=0A= directed against herself and/or Bob.=0A= =0A= a standard feature of every web browser out there. As a model against whic= h=0A= to measure the security of an application or implementation, it's only=0A= slightly less useless than nothing at all.=0A= =0A= Peter.= From nobody Fri Nov 28 02:18:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598C51A1ADC for ; Fri, 28 Nov 2014 02:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTdnEq5InKIv for ; Fri, 28 Nov 2014 02:18:46 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE6A1A1ADB for ; Fri, 28 Nov 2014 02:18:46 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sASAIi2c021133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 28 Nov 2014 05:18:44 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sASAIgS3016324 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2014 05:18:43 -0500 Message-ID: <1417169921.6779.18.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Fri, 28 Nov 2014 11:18:41 +0100 In-Reply-To: References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> <1417079088.11680.7.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0p6Bp2M5u_b0mYipKGfs0MnauHM Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 10:18:48 -0000 On Thu, 2014-11-27 at 15:01 -0800, Watson Ladd wrote: > On Thu, Nov 27, 2014 at 1:04 AM, Nikos Mavrogiannopoulos > wrote: > > On Wed, 2014-11-26 at 16:03 -0800, Watson Ladd wrote: > > > >> >> Parsing TLS is one of the biggest issues in implementations. I can't > >> >> promise to write the tool to auto-generate the parser, but we should be > >> >> sufficiently chastised by all those who tried and failed to parse TLS > >> >> records with handwritten C to consider not doing it ourselves. > >> > Where does this come from? TLS is one of the easiest protocols to parse. > >> OpenSSL couldn't parse an echo request correctly. > > > > This is a TLS extension and is known to be unnecessarily complex. It > > proves nothing about the TLS parsing complexity that you mention. > > The construct of a heartbeat payload is a vector. It's simpler, not > more complex, than many structures in TLS. Then you may not have seen many structures in TLS. The heartbeat structure is unlike _any_ other structure in TLS. struct { HeartbeatMessageType type; uint16 payload_length; opaque payload[HeartbeatMessage.payload_length]; opaque padding[padding_length]; } HeartbeatMessage; So you have a length, and two payloads. One is padding with separate non explicit length, defined as "padding_length = TLSPlaintext.length - payload_length - 3", and the other is supposed to have the previously mentioned length. That construction is unique on the TLS protocol, and has interesting properties, such as the padding length affecting the TLSPlaintext.length it depends on it. It is no surprise it has caused bugs. A simple structure according to the TLS rules is: struct { HeartbeatMessageType type; opaque payload<0..2^16-1>; } HeartbeatMessage; With the latter you can reuse any parser already created for TLS messages, and you have no interplay between different lengths. The former requires a special parser. So really have you actual read, or tried to implement the documents that you claim are simple or complex? regards, Nikos From nobody Fri Nov 28 03:20:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0C1A1B29 for ; Fri, 28 Nov 2014 03:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_pROakI_XT4 for ; Fri, 28 Nov 2014 03:19:54 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EADA61A1B0E for ; Fri, 28 Nov 2014 03:19:53 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 99D96BBA06C; Fri, 28 Nov 2014 03:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=jcTXcNuG0YEk/rW4FSkP4jCMraE=; b=ugOpF/1Upi7CF/jbB gYGEeUB+pdcGIjHDryIV/ebhDVOCkntGrA5zf2BmsnnZWJwjcfXLhtHOYog3ViRU fxgxO6B+nKKv6P2A+tfA5tkvlhfYtoiVsb0FMYG0Mq7sacmEU7XoqGVg+TaUA65e 5F39ppHS9PLasa84dDCN5qXHdU= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 4F8E2BBA06A; Fri, 28 Nov 2014 03:19:53 -0800 (PST) Received: from 74.125.57.233 (proxying for 74.125.57.233) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 28 Nov 2014 03:19:53 -0800 Message-ID: <297be8cca9e6e8bfc31b930610f12743.squirrel@webmail.dreamhost.com> In-Reply-To: References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> <1417079088.11680.7.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 28 Nov 2014 03:19:53 -0800 From: "Ryan Sleevi" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gSvimrfAsp_cMmRVSpXd2P61jLQ Cc: "tls@ietf.org" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 11:19:59 -0000 On Thu, November 27, 2014 3:01 pm, Watson Ladd wrote: > The fact that every single implementation I can think of has had RCE > or memory leak resulting from parsing errors, and usually quite a few? > This doesn't sound like an easy task: it seems downright difficult if > a lot of talented people can't do it. The Tor project is working on > writing parser generators that can deal with the sort of structure we > seem driven to produce in binary protocols for precisely this reason. > > Contrast TLS to this http://curvecp.org/packets.html, or > https://tools.ietf.org/html/rfc2812#section-2.3.1. In the first case I > chop out a header, and the rest is a message content: because > everything is fixed width except the last field, no tricky issues. In > the second case I can use yacc. > > It's probably too late now, but we need to at least not make the probl= em > worse. > > Sincerely, > Watson Ladd Watson, I don't think this argument is particularly germane, fruitful, or frankly= , entirely well reasoned. Your argument that it's a protocol issue because there are implementation issues lacks consideration that implementation issues exist regardless of the protocol. At best, you're writing a screed against parsers in C, and while I suspect you'll find a receptive audienc= e to this particular idea, the TLS WG is not the place for it. As a simple counter-point to your reasoning, consider the many (MANY) RCE bugs in msasn1.dll or cryptologic bugs such as the (poorly named and technically inaccurate) BERserker bug in NSS. ASN.1 is very much a structured representation for which one can create static representations of that lack any form of dynamic parsing. Indeed, many early ASN.1 implementations used exactly this - parsing the ASN.1 definition and generating static parsers that were "bug free", in as long as the parser generator was bug free. This is the same thing Tor is doing. There are a number of deficiencies in doing so, and implementors moved away from it, and as a result, many bugs when processing ASN.1 were introduced. However= , this is not an intrinsic property of ASN.1, but of how implementors have chosen to implement. Hopefully this will be the end of the discussion of this vein on the list= . I see Nikos has already explained why the Heartbeat construct was itself exceptional and, ostenstibly, non-idiomatic and error prone. That does not, however, apply to the entire protocol, and one can arguably write non-idiomatic and error-prone structures in the majority of parsers out there, but that doesn't mean we're all doomed to invent Yet Another Parse= r Language. If anything, your argument is best reduced to a "fixed width field" argument, which has its merits, but also lacks any form of extensibility. While some may see that as a Good Thing, I would suggest that the majorit= y do not view "lack of extensibility except via protocol update" to be an inherently valuable trait. Cheers, Ryan From nobody Fri Nov 28 11:11:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258251A00B1 for ; Fri, 28 Nov 2014 11:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5xkgbayhL2n for ; Fri, 28 Nov 2014 11:11:31 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 56EAA1A0089 for ; Fri, 28 Nov 2014 11:11:31 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 1EE462006D30D; Fri, 28 Nov 2014 11:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=XtRL8v69y4hTLC AVRFRpLjT0S50=; b=BcpWgtMZOYcHiCdET+tg9CL2WtJR41pNS3W6fWW6KhJFbE O4CWNw8Xa2vKN4i1FTv1D3M5OhzeX4o9QYj426rhT61VPZxEvsV6q1N/iZ+13s/x KDgt230T1J12YhACCJiq3T5l6vHJOgWCdfIeD22nFIFloqn+KMdiJHW0T9Gck= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id BE13D2006D30A; Fri, 28 Nov 2014 11:11:30 -0800 (PST) Date: Fri, 28 Nov 2014 13:11:30 -0600 From: Nico Williams To: Peter Gutmann Message-ID: <20141128191127.GE3200@localhost> References: <9A043F3CF02CD34C8E74AC1594475C739B9F68FC@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9F68FC@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AFUs4sEHiUV38Jcun-pCJ3mReN4 Cc: "" Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 19:11:34 -0000 On Fri, Nov 28, 2014 at 08:45:00AM +0000, Peter Gutmann wrote: > Nico Williams writes: > >Yes, it's quaint. It's also as best we can do, unless... > > If that's the best we can do then it's better to have no threat model at all > than something that misleading, because all it's doing is giving a false sense > of security. It doesn't even begin to capture semantics like: > > Alice will perform arbitrary scripted operations at the request of Mallory, > directed against herself and/or Bob. > > a standard feature of every web browser out there. As a model against which > to measure the security of an application or implementation, it's only > slightly less useless than nothing at all. That's changing the subject. Where have I argued that the web security mode is great or even permitted by the Internet threat model. The web security model is... unlike anything produced by the IETF, and it wasn't produced by the IETF. It's an alien as far as we're concerned here. You'd be hard-pressed to find fans of it at the IETF. And it would require torturing logic to say that the Internet threat model allows the web security model. From where we stand we can't really go fix the web security model either, much though we'd like, but we can make TLS 1.3 not fail spectacularly (BEAST and others) in a web context. If you want a holistic approach, well, I agree, but that means getting people in the same room who usually don't do that, and it means getting people to agree to things that they aren't inclined to. Let's! (Any ideas as to how to?) Nico -- From nobody Fri Nov 28 11:36:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CAF1A00D6 for ; Fri, 28 Nov 2014 11:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICE1Q80IA3_s for ; Fri, 28 Nov 2014 11:36:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC0F1A00D0 for ; Fri, 28 Nov 2014 11:36:29 -0800 (PST) Received: from [192.168.131.133] ([80.92.115.84]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Ljqgb-1YRZEP2RD7-00bsFj; Fri, 28 Nov 2014 20:36:24 +0100 Message-ID: <5478CEB7.2020206@gmx.net> Date: Fri, 28 Nov 2014 20:36:23 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "" , bmoeller@acm.org OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o3i1CU67SftptW0fEXXiwQL24naJaWg1x" X-Provags-ID: V03:K0:Q+hZAZNpbtV6ZLsZlHGyl9FfN8iDd4YTf+S34nL7LKSXbVRJXvg LNA7O3ZU+RbsePW2DBE681C8t//FPX3PgW/GL7onpx1wqwodzgJkuZijWsVQFZclZHp/uHz HYTQar5hMlB/LmotUo+1EIcB+SWmANZJwVPZUcDwBqBWdJxPSDxSdfnsEpCY+HVpvn8gm1d 7JDIE8LNo78Hzj/qyMtaQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2bcyGLpL_ngTyo2Jc6RGg4jARog Subject: [TLS] TLS False Start X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 19:36:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o3i1CU67SftptW0fEXXiwQL24naJaWg1x Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bodo, Hi all, I read through . The document is well written but I have a few questions. There are various conditions specified when the TLS False Start mechanism is fit for use. I believe there is room for improvement regarding the way how these conditions are formulated. At the moment, they are more written as examples rather than a list of security properties. I am worried that many of the provided examples will be outdated fairly soon as algorithms continuously evolve. For example, you say that AES-GCM is OK. You cite the key length and I guess you are also including the current state of security analysis of the given cipher in that consideration. Would it be OK to use AES-CCM with False Start? I think so. Then, you list a couple of key exchange methods (DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA), which you consider being fit for TLS False Start. You indicate that an ephemeral DH exchange is need and I was wondering why this is the case? Why isn't a "normal" DH not acceptable? Would a ciphersuite like TLS_PSK_WITH_AES_128_CCM_8 be acceptable since it does not use a public key based ciphersuite and it also does not use an ephemeral Diffie-Hellman exchange. Finally, you list "client certificate types". As someone who is interested in the PSK case I am wondering whether you would consider PSK ciphersuites as acceptable as well. With the indicated criteria it is a bit hard to tell. Ciao Hannes --o3i1CU67SftptW0fEXXiwQL24naJaWg1x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUeM63AAoJEGhJURNOOiAtrAsH/29XWKx6+EEHrGvvy8neW07c HLEjxpDvTLaZiYWRRoOt/HIX+uPL61p/rmmVOgeg7sljT35QXiqwO9v3Je87Ntoa Op7lsW9pMavz/u0AA92VaABgJbkcexSYOvZldMh/4EecL7d8ExomLaB9KRnzPQDy /zSkxlwOJvhUoHU8Y77Ko2++7/zYurb6sD4NdoSRLWP/hK2QVSThs5Krc82WIcQa lN2I8Pf7XXHHbcoNh4yux5Bb9HrrTbp7Ql7JrCmCED9ey2S5/EiKT5CoPkZFWz+d 27IojonRwIndnupvBaqqk8NdmUEwwWsRdV+SqS+Fjbx4LKDC4keVEvp7igPYvl8= =4nnR -----END PGP SIGNATURE----- --o3i1CU67SftptW0fEXXiwQL24naJaWg1x-- From nobody Fri Nov 28 23:37:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A91A00E9 for ; Fri, 28 Nov 2014 23:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slT7BIkrABBw for ; Fri, 28 Nov 2014 23:37:38 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E000A1A00B7 for ; Fri, 28 Nov 2014 23:37:37 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so5888561obc.29 for ; Fri, 28 Nov 2014 23:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jzuLipfUQH9A/A8QtxY25qDcZhTGrH5THlZAvtenyeI=; b=WpQFuo1Gfo4tAfrJ6UJtjEffHsPV1YAEYT8J23VlthzBaC+iARpZCrJTU2UdmA4EgT A9ViVbpMUKzzKtS3yb1JM4v4RoghDWEc8L7r9t3MAKYal6aQVgUBsvTKqpmWNCFMZ18g wdUZfVgMgMs2qSwMX5EwJY2q7k3NEA5Z/KGF7Biusn3LBTa9PaZ+HPOVQF/nWQynWYn+ 9iV6wbL2te5EgxzTMnevlEtbo8+Pcqwnez/HfGO7ka42NWN1LyYN9TgJPNbgrn36MjFP yhTU99G7ZNW8BuQCkiE4xSo4Y70+QEH9C9PG3j/DG9P01/OPmZkILWYVcGfu/L7sBQK1 9DSg== MIME-Version: 1.0 X-Received: by 10.202.168.204 with SMTP id r195mr10614110oie.72.1417246657098; Fri, 28 Nov 2014 23:37:37 -0800 (PST) Received: by 10.202.115.4 with HTTP; Fri, 28 Nov 2014 23:37:36 -0800 (PST) In-Reply-To: References: Date: Fri, 28 Nov 2014 23:37:36 -0800 Message-ID: From: Martin Thomson To: Stephen Checkoway Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k91ue0be5ZTVFlPE4tu3FEsyh1s Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 07:37:39 -0000 On 27 November 2014 at 08:15, Stephen Checkoway wrote: > Why should we require that the certificate be signed with the signature scheme corresponding to the public key? If the certificate is selected based on the cipher suite (ECDSA, for instance), maybe there is a desire to have a uniform chain so that a client doesn't end up in a situation where they can't verify the chain (because they don't have RSA, for example). Now, we do have a lot of implementations that do both, so that's cool. And we have other ways of advertising what signature methods are available. So, maybe this can be loosened to say that all certificates in the chain MUST be supported by the client (as determined by X, where X is TBD, mostly because I'm lazy). From nobody Sat Nov 29 12:38:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06B81A1EF1 for ; Sat, 29 Nov 2014 12:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys6yHuDLzFEl for ; Sat, 29 Nov 2014 12:38:12 -0800 (PST) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FA41A1EEC for ; Sat, 29 Nov 2014 12:38:11 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id z60so5951097qgd.17 for ; Sat, 29 Nov 2014 12:38:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+kvW89/wv112vy/1stpkN11Cp0dCiXFJ9wVAzeodo9w=; b=M+L6nhaNwgMp/qSZg1yN3tndpXmLj39LTTzF0FTJAACfEXkpG4IfOPWGWND5fhrLCF NWEpie7xc2A+mJfESOMI+rMorC6LHZqtm8GOew0jqjndNfR1tVRFmK8n+M4vaPrPJauW P6nf3im5LiMgF3SyDv6Wa+cBMY+odF45Eb2Yc5wTHeXcPdFhwcECUDlmvlgodG5exYYa G/tRu/yLY5+2T5RyrSX6U5NqdoCIJMXoX9RXaToCW/9DrlB0/nbsfZ3SgZ/ByY5hkF2T 1HXHdEDNHuaQJ4hfJvwZvASGy7q/ZsOfpbEDQXrefgaw6u3Rh947ieU+Eav2ZiXZZ2UL LMCg== X-Gm-Message-State: ALoCoQk/Tr+po48ephw6t7U5Q6l0K0SmG1rvmdGTvIwdUydjlHINDhvnrISETjpAjS9pyhqcUlNY X-Received: by 10.224.38.5 with SMTP id z5mr73803656qad.89.1417293491117; Sat, 29 Nov 2014 12:38:11 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id 78sm12907041qgp.2.2014.11.29.12.38.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Nov 2014 12:38:09 -0800 (PST) Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 03E15AC2899; Sat, 29 Nov 2014 15:38:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: Date: Sat, 29 Nov 2014 15:38:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <03BB9FA7-C0DD-4E05-A041-666354A6362C@pahtak.org> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cJPR19ugNSyLo3u1cOD5Hjs2D-k Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 20:38:13 -0000 On Nov 29, 2014, at 2:37 AM, Martin Thomson = wrote: > On 27 November 2014 at 08:15, Stephen Checkoway wrote: >> Why should we require that the certificate be signed with the = signature scheme corresponding to the public key? >=20 > If the certificate is selected based on the cipher suite (ECDSA, for > instance), maybe there is a desire to have a uniform chain so that a > client doesn't end up in a situation where they can't verify the chain > (because they don't have RSA, for example). >=20 > Now, we do have a lot of implementations that do both, so that's cool. > And we have other ways of advertising what signature methods are > available. So, maybe this can be loosened to say that all > certificates in the chain MUST be supported by the client (as > determined by X, where X is TBD, mostly because I'm lazy). I think that's reasonable. TLS 1.2 specifies If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. and it also specifies what the defaults are when that isn't sent. I = imagine similar text could be used here. --=20 Stephen Checkoway From nobody Sat Nov 29 23:31:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FC11A03A9 for ; Sat, 29 Nov 2014 23:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z09_wxvZkG8u for ; Sat, 29 Nov 2014 23:31:06 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB77B1A03A3 for ; Sat, 29 Nov 2014 23:31:06 -0800 (PST) Received: by mail-oi0-f47.google.com with SMTP id v63so6193765oia.6 for ; Sat, 29 Nov 2014 23:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cfzKEBr8EIYt2mO94xa8465zDGQVgR1FtDl8PkZLdyw=; b=Dmd8fJQtBST3RSs5TeZKoUkw44eMZoCmlSUHAGEt8aVr/imGyHMcpLhwdagxvD+/Qr 3NOpzH620BHhLKalYKwKevjnCzxZB8YML44jsmYuaaxTvhB9monxofIfk/3jOt0bM36m E3AB1FAZPIVe/A+cFpuhFVWNm+XkJIk5qnEk/nUFc7cvEwOkA+4JOaFIc56lOWb7StSG q58wLyjcnznNdJdc/IRBch74qkISSjpDfCBVzSCIKra9pCCkOT4uYIH0O7fe/aqVq39M gt+LZRmuQDLS3tqVKvbfnt7czNal/GSUNIyABMUQNEzid5qE47S/lklBL/gBAn1rbVat Us4A== MIME-Version: 1.0 X-Received: by 10.182.16.138 with SMTP id g10mr3694560obd.85.1417332665915; Sat, 29 Nov 2014 23:31:05 -0800 (PST) Received: by 10.202.115.4 with HTTP; Sat, 29 Nov 2014 23:31:05 -0800 (PST) In-Reply-To: <03BB9FA7-C0DD-4E05-A041-666354A6362C@pahtak.org> References: <03BB9FA7-C0DD-4E05-A041-666354A6362C@pahtak.org> Date: Sat, 29 Nov 2014 23:31:05 -0800 Message-ID: From: Martin Thomson To: Stephen Checkoway Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b9nlRUg40PwQSmP_xfZJEks1Q-A Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 07:31:08 -0000 On 29 November 2014 at 12:38, Stephen Checkoway wrote: > > On Nov 29, 2014, at 2:37 AM, Martin Thomson wrote: >> If the certificate is selected based on the cipher suite (ECDSA, for >> instance), maybe there is a desire to have a uniform chain so that a >> client doesn't end up in a situation where they can't verify the chain >> (because they don't have RSA, for example). [...] > I think that's reasonable. TLS 1.2 specifies > > If the client provided a "signature_algorithms" extension, then all > certificates provided by the server MUST be signed by a > hash/signature algorithm pair that appears in that extension. > > and it also specifies what the defaults are when that isn't sent. I imagine similar text could be used here. We can probably do better: https://github.com/tlswg/tls13-spec/issues/99 From nobody Sun Nov 30 02:10:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEEB1A0018 for ; Sun, 30 Nov 2014 02:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOUdV6A8qL_Y for ; Sun, 30 Nov 2014 02:10:00 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE281A0013 for ; Sun, 30 Nov 2014 02:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1417342202; x=1448878202; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=60698mBT7u5bg7t8OJUJDIvBPAnkwj0Lb7PNkmPa1JA=; b=ZRYkanic4qMLkszSktbXBtjLERBQ0VIuWotlq6NbS84ZqbH0fn+vp2lj R86WZOn1qJnP3qItKqidAt7HXowS+a6FPU07dy5Uv9/bqN5qZNJgbkrbv MGjWGENpb1MDEJcYbZbtHoknyymDUh0l1oXWexDhZ3WMKOPPNn1QXMdUJ w=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="293897385" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Nov 2014 23:09:58 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 30 Nov 2014 23:09:56 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] WG adoption: draft-nir-tls-rfc4492bis Thread-Index: AdAMhcqRURR5jkHMSL26EXhLM3yQJw== Date: Sun, 30 Nov 2014 10:09:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fSsVdVwJhRIEFffyxHRV-nPwuMU Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 10:10:05 -0000 Stephen Checkoway writes:=0A= =0A= >TLS 1.2 specifies=0A= >=0A= > If the client provided a "signature_algorithms" extension, then all=0A= > certificates provided by the server MUST be signed by a=0A= > hash/signature algorithm pair that appears in that extension.=0A= =0A= Which is one of the nonsensical requirements in TLS 1.2 that you pretty muc= h=0A= have to ignore in order to get an implementation that works (it's been=0A= discussed on the list before). Consider how this is supposed to work in=0A= practice: A client connects to Amazon and asks for ECDSA_P521_WITH_SHA384.= =0A= Amazon puts the client on hold and goes to Verisign and requests that they= =0A= reissue their entire cert hierarchy up to the root using ECDSA-P521 with=0A= SHA384, and then buys a new certificate using the requested algorithm. The= y=0A= then wait for Windows Update to propagate the new CA certs out to the clien= t,=0A= and after a few weeks on hold the client connects.=0A= =0A= At the time this was discussed, the approach by everyone who contributed wa= s=0A= that the client got whatever the server had available. In the rare cases= =0A= where the server had more than one cert then "signature_algorithms" could b= e=0A= used to implement a MAY, but it still won't change the fact that beyond the= =0A= server cert you get what the CA gives you and nothing else, no matter what = the=0A= TLS 1.2 RFC may wish for.=0A= =0A= Peter.= From nobody Sun Nov 30 02:18:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA591A0025 for ; Sun, 30 Nov 2014 02:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9OXxzBtxKXO for ; Sun, 30 Nov 2014 02:18:14 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4706A1A0018 for ; Sun, 30 Nov 2014 02:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1417342696; x=1448878696; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qaOsDHSLW2mbG2NwnpB7n9Bl4Gj/9xoD58+yKFsawis=; b=C+asbomM2ckqTJDrE0rJMBot20jtCXXeR3/IEw4I+tBHOn3LaQe4DkBF /cg/aOnWitUQXHoDWLdG7ZDXWN12kUg2/Vc1J4pu14Vy7PmV6eYGinNk+ cYLon1BNDZUpPEfO04pXJ2yjW4kRPdVZBb5/tjX/NI9ueNYSlEJBNTImZ 8=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="293897965" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Nov 2014 23:18:14 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 30 Nov 2014 23:18:12 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Rethink TLS 1.3 Thread-Index: AdAMhvG8ymSj6ixETIW55pXOIHHnfg== Date: Sun, 30 Nov 2014 10:18:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9F7A2D@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HWoj-JOPEOrBjp2oYPAWJJdeVoI Subject: Re: [TLS] Rethink TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 10:18:16 -0000 Nico Williams writes:=0A= =0A= >That's changing the subject. =0A= =0A= It's not changing the subject, which as far as I was aware was "do we have = a=0A= threat model to evaluate TLS 1.3 against?".=0A= =0A= >Where have I argued that the web security mode is great or even permitted = by=0A= >the Internet threat model.=0A= =0A= What's the web security mode? What's the Internet threat model (if it isn'= t=0A= the Strawman Model I mentioned earlier), and why does it permit or not perm= it=0A= something?=0A= =0A= >The web security model is... unlike anything produced by the IETF, and it= =0A= >wasn't produced by the IETF. It's an alien as far as we're concerned here= .=0A= =0A= Given that HTTP 2.0 and to a lesser extent TLS 1.3 are being designed as if= =0A= the only thing that mattered is web browsers, they had better be useful wit= h=0A= or for or in the web security model, whatever that is.=0A= =0A= What I want is a realistic, real-world threat model against which to evalua= te=0A= TLS 1.3. Without a way to evaluate whether TLS 1.3 is fit for purpose, we'= re=0A= just, to quote Linus, "a bunch of people wanking around with their opinions= ".=0A= =0A= Peter.= From nobody Sun Nov 30 13:52:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663681A1A9F for ; Sun, 30 Nov 2014 13:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcpuEXZUcs6b for ; Sun, 30 Nov 2014 13:52:40 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46FA1A1A99 for ; Sun, 30 Nov 2014 13:52:39 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id j7so6502132qaq.1 for ; Sun, 30 Nov 2014 13:52:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KTEBDFe6or6hMJvXo3/hD3ANkt3UX97/Kv8oCqkDmPg=; b=bQ+I8fMxu+0KPcYWCGOo0n+Ho6+gQ70PhGI/soSJmLhoycy9GUroixduC4JvxgVqfv bnUbYHXNerRWDa4tWRuq1vxadyHw9ep0ek01oqH3j1jV8tKVTAyJeep9MKuxx63pg54e fL/dLsJ52kYYHmJCPsqIWRWFhq+SZ5xoP9txcF21bi2kzxg+xkXgzubyHMaxwUdW4bVw WyInEMWAjBtFay7jXga8GxkjY06II26ZAacp7t09QLI8qbCM8dADxgmq/SRjy/qhxgta 2SfbIosgWRJNHH4UKZrtV7OTtguyHlaiZ9OYvGwn4ekhDLVB/JifHWbdLXLkpXiE29SP afmA== X-Gm-Message-State: ALoCoQk6rBUkoJIh6Ub8Hc6h2dtuK2+MLT5SCDy8OwYZCjaZ6m4aQEl8A/5icdU/Lj4MZorl4P79 X-Received: by 10.224.34.133 with SMTP id l5mr7869578qad.44.1417384359130; Sun, 30 Nov 2014 13:52:39 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id e6sm15579043qab.42.2014.11.30.13.52.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Nov 2014 13:52:37 -0800 (PST) Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 208D2AC2841; Sun, 30 Nov 2014 16:52:36 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 30 Nov 2014 16:52:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9FE323BF-2650-4EA3-9CBB-B46CF3A00298@pahtak.org> References: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k5Ntjmq4-Di6oXG3oWCkm5oIses Cc: "" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 21:52:41 -0000 On Nov 30, 2014, at 5:09 AM, Peter Gutmann = wrote: > Stephen Checkoway writes: >=20 >> TLS 1.2 specifies >>=20 >> If the client provided a "signature_algorithms" extension, then all >> certificates provided by the server MUST be signed by a >> hash/signature algorithm pair that appears in that extension. >=20 > Which is one of the nonsensical requirements in TLS 1.2 that you = pretty much > have to ignore in order to get an implementation that works (it's been > discussed on the list before). Sorry, I missed the prior discussion. > Consider how this is supposed to work in > practice: A client connects to Amazon and asks for = ECDSA_P521_WITH_SHA384. > Amazon puts the client on hold and goes to Verisign and requests that = they > reissue their entire cert hierarchy up to the root using ECDSA-P521 = with > SHA384, and then buys a new certificate using the requested algorithm. = They > then wait for Windows Update to propagate the new CA certs out to the = client, > and after a few weeks on hold the client connects. That seems wrong. In practice, a client connects and says I'm willing to = communicate using protocol parameters X, Y, and Z. If the server can't = accommodate the client, it closes the connection. How is the signature = algorithm any different from the cipher suite in this respect? If the = client says it can only do ECDSA, what's the point of giving it an RSA = cert that it cannot use? > At the time this was discussed, the approach by everyone who = contributed was > that the client got whatever the server had available. In the rare = cases > where the server had more than one cert then "signature_algorithms" = could be > used to implement a MAY, but it still won't change the fact that = beyond the > server cert you get what the CA gives you and nothing else, no matter = what the > TLS 1.2 RFC may wish for. Why does this same reasoning not apply to the symmetric algorithm? E.g., = the client wants AES but the server decides 3DES. --=20 Stephen Checkoway From nobody Sun Nov 30 23:17:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C97F1A1ADF for ; Sun, 30 Nov 2014 23:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gib9eID-WyIA for ; Sun, 30 Nov 2014 23:17:22 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F3E1A1ADB for ; Sun, 30 Nov 2014 23:17:22 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id gq1so7241974obb.26 for ; Sun, 30 Nov 2014 23:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IRLfYcsGVxYeJtaNq668UKE6o3AIjmnk99A0CMSXRGc=; b=jZJi0RE8apDGv8JQxrWQiiez/HAVSGL5GlD6ejMwSyz6Sb4ej7QMl/35mmSh6c8SGV z39UiE45V0m8ShBDmt4pZBe4NGbABbLkTIUGIabx3m92SjMr7HpKpDE4dHFumkKWo5gr FHkCyPh5zfkXHundOyCnvMdFjyV3r/zTez3EUQWULPEn8s7IVwpz+t5qXqDacAGT0Vfz VWoE2rNU21j4SYV735NjurUFRPJoRtzaLUYLIC8svUjPCEFO1gXxChybB8sH0bQAQTLk jmcvUNbVl3pU0aZRHppLlgYOQhLjVzox66rHswnifoLR7JUlpZkKykAbHhO6wFokc+c1 4EnQ== MIME-Version: 1.0 X-Received: by 10.202.225.197 with SMTP id y188mr6866804oig.94.1417418241274; Sun, 30 Nov 2014 23:17:21 -0800 (PST) Received: by 10.202.115.4 with HTTP; Sun, 30 Nov 2014 23:17:21 -0800 (PST) In-Reply-To: <9FE323BF-2650-4EA3-9CBB-B46CF3A00298@pahtak.org> References: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz> <9FE323BF-2650-4EA3-9CBB-B46CF3A00298@pahtak.org> Date: Sun, 30 Nov 2014 23:17:21 -0800 Message-ID: From: Martin Thomson To: Stephen Checkoway Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HTeQASiA4eoW6xNkXD7rQEaI4c8 Cc: "" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 07:17:23 -0000 On 30 November 2014 at 13:52, Stephen Checkoway wrote: > How is the signature algorithm any different from the cipher suite in this respect? If the client says it can only do ECDSA, what's the point of giving it an RSA cert that it cannot use? I think that the difference is that - at least for most clients - they support both. Or at least, servers have been able to deploy ECDSA certs that chain to RSA with the expectation that RSA hasn't gone away yet. And that's relatively new. Peter refers to the fact that servers (and CAs) have picked a certificate that works based on what they know of clients, and had just the one. That single cert is offered unconditionally. If the client doesn't like it, then it can be responsible for choking on it. CAs could have offered a range of certificates with varying strength and signature algorithms, but one is always easier in every regard. Migrating away from mostly RSA might have changed that a little.