From nobody Wed Jul 1 05:08:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB781A1BEF for ; Wed, 1 Jul 2015 05:08:32 -0700 (PDT) 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 IPlqef3vyLPR for ; Wed, 1 Jul 2015 05:08:29 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::623]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABAB1A1BDB for ; Wed, 1 Jul 2015 05:08:28 -0700 (PDT) Received: from DB3PR04MB027.eurprd04.prod.outlook.com (10.242.136.150) by DB3PR04MB025.eurprd04.prod.outlook.com (10.242.136.140) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 1 Jul 2015 12:08:23 +0000 Received: from DB3PR04MB027.eurprd04.prod.outlook.com ([169.254.6.129]) by DB3PR04MB027.eurprd04.prod.outlook.com ([169.254.6.129]) with mapi id 15.01.0201.000; Wed, 1 Jul 2015 12:08:22 +0000 From: Arnaud KAISER To: "tls@ietf.org" Thread-Topic: New version of draft-lonc-tls-certieee1609-01.txt Thread-Index: AdCz9Tm9D8nVaxGkT5W0tzCJM20T9A== Date: Wed, 1 Jul 2015 12:08:22 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [192.93.124.97] x-microsoft-exchange-diagnostics: 1; DB3PR04MB025; 5:B//ncC1BJo0XLCoD3gIa/QwYYd0Rm25FYbMq18x6ILP4dx3K5DRLXVe/SbzlEKT6N6ydYuHGi1wNcHGALOJVhjNj4X/oSrtFvOrRiWzcdSgsZLZd9gb2AvcHVxV5U2JFBu9GgjIHsLKqtS8XEfW4aA==; 24:SK7L3O+IAftqJvcIWqoAh92UCkgohr3YkUWl8X/fy2fnPPJdxscJIgAwsufEgpAYJwpZ4+g0NpbLCXF6/isG3/eDZ4u1HF6EQz81tE9O2NU=; 20:fdEfG7yY6Pccpi/9d/JDIDb0wPK2VwAmxRczujVrpHAQV0cpGXytffBekwo1OB9j+cAdOAAqEaBcTQhTW+Dhow== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB025; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR04MB025; BCL:0; PCL:0; RULEID:; SRVR:DB3PR04MB025; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(19580395003)(2656002)(19300405004)(5003600100002)(87936001)(74482002)(74316001)(230783001)(46102003)(86362001)(19625215002)(561944003)(110136002)(107886002)(189998001)(33656002)(5002640100001)(5001960100002)(2900100001)(102836002)(15975445007)(50986999)(54356999)(16236675004)(66066001)(229853001)(2501003)(19617315012)(2351001)(92566002)(62966003)(77156002)(450100001)(122556002)(40100003)(76576001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR04MB025; H:DB3PR04MB027.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR04MB0278992B0D7623C3E0C4599DBA80DB3PR04MB027eurprd_" MIME-Version: 1.0 X-OriginatorOrg: irt-systemx.fr X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 12:08:22.7080 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: efbb4c7c-8ac1-416d-bf30-791be86aad0b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR04MB025 Archived-At: Subject: [TLS] New version of draft-lonc-tls-certieee1609-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: Wed, 01 Jul 2015 12:08:33 -0000 --_000_DB3PR04MB0278992B0D7623C3E0C4599DBA80DB3PR04MB027eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear members of TLS WG, A new version (-01) of draft-lonc-tls-certieee1609 has been submitted. The = draft can be found here: https://tools.ietf.org/html/draft-lonc-tls-certieee1609-01 The proposal of this draft is to extend the TLS protocol to support ITS-spe= cific certificates defined by IEEE and ETSI. Any comments are welcome. Also, if possible, we can do a short presentation= of the draft at the 93rd IETF meeting. Best regards, Arnaud Kaiser --- Arnaud Kaiser Research Engineer IRT SystemX 8, Avenue de la vauve 91120 Palaiseau, France --_000_DB3PR04MB0278992B0D7623C3E0C4599DBA80DB3PR04MB027eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear members of TLS WG,

 

A new version (-01) of draft-lonc-tls-certieee1609 h= as been submitted. The draft can be found here:

https://tools.ietf.org/html/draft-lonc-tls-certieee1609-= 01

 

The proposal of this draft is to extend the TLS prot= ocol to support ITS-specific certificates defined by IEEE and ETSI.

 

Any comments are welcome. Also, if possible, we can = do a short presentation of the draft at the 93rd IETF meeting.

 

Best regards,

Arnaud Kaiser

 

--= -

Ar= naud Kaiser

Re= search Engineer

IR= T SystemX

8,= Avenue de la vauve

91= 120 Palaiseau, France

 

--_000_DB3PR04MB0278992B0D7623C3E0C4599DBA80DB3PR04MB027eurprd_-- From nobody Wed Jul 1 05:15:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2561A1BCA for ; Wed, 1 Jul 2015 05:15:32 -0700 (PDT) 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 ZhdIi4YH-BAM for ; Wed, 1 Jul 2015 05:15:29 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709F11A0373 for ; Wed, 1 Jul 2015 05:15:29 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id F23F79016E; Wed, 1 Jul 2015 15:15:26 +0300 (EEST) Date: Wed, 1 Jul 2015 15:15:26 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150701121526.GA29679@LK-Perkele-VII> References: <20150701052255.GB24615@LK-Perkele-VII> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2015 12:15:32 -0000 On Tue, Jun 30, 2015 at 10:33:23PM -0700, Eric Rescorla wrote: > On Tue, Jun 30, 2015 at 10:22 PM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > On Tue, Jun 30, 2015 at 03:23:18PM -0700, Eric Rescorla wrote: > > > > > > OPEN ISSUES > > > There are still a number of known open issues to discuss: > > > > > > 1. The present known_configuration mechanism allows the client to > > > resurrect the handshake parameters (though not the keys) which were > > > negotiated in a previous handshake, but this is done implicitly, > > > i.e., the server provides a label and the client returns it on > > > the next connection. This has the advantage of keeping things short > > > but the disadvantage the it means that you can't have a static > > > configuration ID for everyone (instead, the server has to somehow > > > embed the properties in the configuration ID). There are (at least) > > > three potential alternative designs: > > > > > > (a) Have the client indicate in his first flight "these are the > > > parameters I expect you to negotiate", along with the > > > configuration identifier, based on what the server > > > negotiated the previous time. [Optionally, the server > > > can run the same negotiation locally and abort on mismatch.] > > > > > > (b) As in (a) but with no indication of the expected parameters, > > > just the configuration ID, and the client just preemptively > > > uses the parameters from the last time and if the negotiation > > > ends up differently, all the data is undecryptable > > > (ugh) and you somehow fall back. > > > > > > (c) Have the server provide a preference list in his > > > ServerConfiguration (this can be the same as in the > > > ClientHello) and have the client do the negotiation based on > > > that rather than the server (as in QUIC). This is a little odd > > > in that it means that sometimes the server selects the > > > parameters and sometimes the client does, but it's not that > > > hard to make this code symmetrical. > > > > > > As I think this through, I am leaning towards (a) but other people's > > > opinions on this topic would be welcome. > > > > I think that there should be capability for server to fail decrypting > > the 0RTT data but still proceed with handshake (informing client of > > this fact). > > > > What I had in mind here was that you would be able to fail to decrypt > the 0-RTT data and you fell back to an ordinary 1-RTT handshake > (i.e., if there was client auth, it went in the second flight). Without a retry, right? > Are parameters here things like symmetric ciphersuite used for 0RTT > > encryption? Or something else? I think that even if one uses supported > > symmetric ciphers, one could still get decrypt failures. > > > > Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (the one remaked > > in #3)? > > > > Sorry, I'm not quite following this. Can you rephrase? Say, one has DHE-CERT (for full handshake) and pure-PSK (for resumption) key exchanges signaled. Which one provodes the key to decrypt the 0-RTT data (because the keys sure won't be the same)? > > Undecryptable 0RTT becomes practicularly fun when considering how > > that would interact with handshake transcripts. > > That's why I'm thinking that the above is the simpler approach. Well, if handshake is not retried and 0RTT is rejected (i.e. server replies with Finished in its reply), it shouldn't matter very much what is in 0RTT data. Then there's the more fun case of where handshake that has 0RTT data is retried (e.g. missing group key). One needs to ensure transport consistency[1] on retry as well as preferably defending against clients and servers doing dumb things (experience has shown that all kinds of dumb bugs creep in, despite MUST specifically against the behaviour in question). > > > 2. Should we require that PSK cipher suites where the PSK is used for > > > resumption use compatible ciphers? This is the way it was in TLS 1.2 > > > and below for resumption and tickets, but once you have a PSK, that's > > > not really necessary [0]. So, for instance, if you had the following > > > cipher list order: > > > > > > ECDHE + AES-GCM > > > ECDHE + ChaCha/Poly > > > PSK + ChaCha/Poly > > > PSK + AES-GCM > > > > > > You could potentially negotiate one connection with GCM, use it > > > to establish a shared key, and then reconnect with ChaCha/Poly. > > > This seems like it probably should be something we avoid, though > > > I'm not sure we have a concrete reason why, and it means a > > > weird special case for PSK. Note that this issue might be > > > ameliorated some (though not completely) with a la carte negotiation. > > > > I would place stuff like this into "client sending odd stuff and > > getting odd behaviour in response". And with the negotiation the > > way it is, I don't see security problem here. > > Thanks. More specifically, if there's a problem here, pure-PSK also has that problem (and more severe one). And due to THS fix, it is not possible to perform dangerous actions like keying two different ciphers with the same key. [1] Renego bug actually involved inconsistent transport state, as well as two different things looking confusingly similar. -Ilari From nobody Wed Jul 1 09:18:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4A31A9147 for ; Wed, 1 Jul 2015 09:18:56 -0700 (PDT) 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 ZdHmxE5lCZx0 for ; Wed, 1 Jul 2015 09:18:53 -0700 (PDT) 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 288641A9136 for ; Wed, 1 Jul 2015 09:18:53 -0700 (PDT) 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 1C2672ACAD for ; Wed, 1 Jul 2015 18:18:51 +0200 (CEST) X-purgate-ID: 152705::1435767531-00005316-018284C9/0/0 X-purgate-size: 6095 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 15FC040276 for ; Wed, 1 Jul 2015 18:18:52 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 22FE31A1B2; Wed, 1 Jul 2015 18:18:51 +0200 (CEST) In-Reply-To: <20150630235340.GI14121@mournblade.imrryr.org> To: tls@ietf.org Date: Wed, 1 Jul 2015 18:18:51 +0200 (CEST) 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: <20150701161851.22FE31A1B2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates 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, 01 Jul 2015 16:18:56 -0000 Viktor Dukhovni wrote: > On Tue, Jun 30, 2015 at 10:26:13PM +0200, Martin Rex wrote: >> is in conflict with >> >> Section 3.1, last paragraph >> https://tools.ietf.org/html/rfc7301#page-5 >> >> Unlike many other TLS extensions, this extension does not establish >> properties of the session, only of the connection. When session >> resumption or session tickets [RFC5077] are used, the previous >> contents of this extension are irrelevant, and only the values in the >> new handshake messages are considered. > > I don't think there's a conflict here. All that's said is that > ALPN is not a session property, and its value for a previous > connection is not directly relevant for a new connection. Each > connection signals its own ALPN value. There is a very clear conflict here. A TLS session resume skips the exchange of credentials&identities (such as certificates), so as a result of a session resumption the session will have the _cached_ certificates from the original full TLS handshake as session attributes. This is in direct conflict with the idea of selecting protocol-specific certificates through ALPN and describing ALPN as connection-specific rather than session-specific. Another issue is renegotiation: it makes little sense to allow ALPN to change the negotiated protocol during the renegotiation handshake, because this would cause extreme complexity and all kinds of problems, in particular because of two issues: - rfc5746 urges TLS implementations to not allow change of (server)certificate during renegotiation without an explicit opt-in by the application, because most application will not be able to properly deal with this--most even don't know or realize that it happens/happend, such as HTTP-based apps on a blocking OpenSSL-Style interface (SSL_read()) that are forced through a renegotiation by the server (who is asking for a client certificate with renegotiation), and do not actually realize that there was a renegotiation during the blocking SSL_read() operation while they were waiting for a response. - how would the change in the negotiated protocol affect the application layer protocol. e.g. what would it mean if the client offers http/1.1 and h2 through ALPN on both handshakes (initial and renegotiation) and the server would pick "http/1.1" on the inital handshake and "h2" on the renegotiation for "using renego to request a client cert after having seen the request" for the application layer protocol semantics. Will a client app that enables ALPN suddenly have to check the "current" ALPN protocol for every single SSL_read() operation that returns app data, because there may have been a transparent renegotation under the cover and the protocol may have changed? -Martin - How would a change in the ALPN protocol > > Now to the extent that a new connection elects a different protocol > and thus a different server certificate chain, or the server's > configuration has changed and the same ALPN protocol is now associated > with a new certificate chain, the server needs to perform a full > handshake, so that the client sees the correct certificate chain. > > > Currently, my client-side session cache management, and the decision whether > > to propose a TLS session to the server for resumption, is based on a match > > of the application supplied "target name" which is usually an fqdn hostname, > > but could also be an abbreviated hostname or an IP address. > > Postfix has had solved a similar issue some time ago, because > multiple SMTP destination domains can use the same MX host, but > the sending MTA administrator TLS policy may differ between domains > and these domains might use distinct "transports" (instances of > SMTP delivery channels, roughly analogous to a Sendmail "mailer"), > where each transport has different trust-anchors or other relevant > TLS settings. > > Therefore, the client cache is indexed by multiple properties that > extract the enough detail from the security policy to make sure we > are reaching the right server at the right security level. The > relevant attributes are: > > * Postfix "transport name". Different transports > have potentially very different base TLS settings, and it is > simplest to not mix session caches accross "transports" > > * Nexthop domain (with port), MX hostname and target IP address. > Some MX hosts that appear to be a single multi-homed host are > in fact multiple hosts with separate caches, so each IP address > gets a different parallel cache. > > * The EHLO name of the remote SMTP server, this detects split > caches (multiple SMTP servers) behind a load balancer. > > C: EHLO client-name > S: 250- > ... > 250 STARTTLS > > Google's pool of MX hosts at any given IP address, has a > shared session cache, and a common EHLO name, so session > caching works well across the load balancer. Some providers > have shared caches, but fail to return a common HELO name, > and the client cache is then not nearly as effective. > > * ... > > > Essentially, I believe that tagging of the session with the ALPN > > negotiated protocol to result in more "predictable" behaviour, because > > it will not interfere with client-side session cache management > > and not result in occasional confusion should other server implementors > > ever make their servers use different server certificates for > > different ALPN-negotiated protocols. > > So, yes include all TLS security-relevant attributes in some manner > in the client cache lookup key to avoid mixing cached sessions with > incompatible security requirements. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 1 09:34:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4D1A9239 for ; Wed, 1 Jul 2015 09:34:11 -0700 (PDT) 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 0F-TIVJ1glkK for ; Wed, 1 Jul 2015 09:34:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672071A9251 for ; Wed, 1 Jul 2015 09:33:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 10D53284D2B; Wed, 1 Jul 2015 16:33:53 +0000 (UTC) Date: Wed, 1 Jul 2015 16:33:53 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150701163352.GK14121@mournblade.imrryr.org> References: <20150630235340.GI14121@mournblade.imrryr.org> <20150701161851.22FE31A1B2@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150701161851.22FE31A1B2@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates 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, 01 Jul 2015 16:34:11 -0000 On Wed, Jul 01, 2015 at 06:18:51PM +0200, Martin Rex wrote: > >> Unlike many other TLS extensions, this extension does not establish > >> properties of the session, only of the connection. When session > >> resumption or session tickets [RFC5077] are used, the previous > >> contents of this extension are irrelevant, and only the values in the > >> new handshake messages are considered. > > > > I don't think there's a conflict here. All that's said is that > > ALPN is not a session property, and its value for a previous > > connection is not directly relevant for a new connection. Each > > connection signals its own ALPN value. > > There is a very clear conflict here. > > A TLS session resume skips the exchange of credentials&identities > (such as certificates), so as a result of a session resumption > the session will have the _cached_ certificates from the original > full TLS handshake as session attributes. And yet it is not a conflict. The specification says ALPN is per-connection. Since certificates are per-session, either the client or the server need to do the right thing and not re-use sessions that are not compatible with the requested ALPN. Clients can try to maximize session re-use and leave the logic up to the server (to perform a new handshake when the initial ALPN is associated with a different server identity), or clients can maximize correctness in the face of sloppily implemented servers and avoid reuse of sessions for a different ALPN value. So indeed most clients should create one session per ALPN value, thus turning ALPN into a session property. Clients that can reasonably expect correct server logic might leave it up to the server to decide whether to create a new session, or allow re-use, because both the new and the old ALPN value map to the same server identity. -- Viktor. From nobody Wed Jul 1 10:02:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827811A90F1 for ; Wed, 1 Jul 2015 10:02:06 -0700 (PDT) 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, 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 ylx34g4RQ1A2 for ; Wed, 1 Jul 2015 10:02:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D241A90E6 for ; Wed, 1 Jul 2015 10:02:04 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 17:02:03 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0195.005; Wed, 1 Jul 2015 17:02:02 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates Thread-Index: AQHQs3MRkef6bIVx+0iShvNHWvsYnZ3FuRMAgAETQoCAAAQzgIAABWyw Date: Wed, 1 Jul 2015 17:02:02 +0000 Message-ID: References: <20150630235340.GI14121@mournblade.imrryr.org> <20150701161851.22FE31A1B2@ld9781.wdf.sap.corp> <20150701163352.GK14121@mournblade.imrryr.org> In-Reply-To: <20150701163352.GK14121@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::5] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:nXEgVRJmf5Zx7NSwP7a5RJLrlIGuCFR0a6/oxR9uOTVnJ/XqyG+AhKfqweQlRDC7muLDZMUQkBh81ivCT0L3vEt2vPGrMi4jwQ61LvRoJcDNnHMNkqsAQ3sR+e63qQtTV+vZ/IKypmMJq72EoFs1Mw==; 24:VsR672gfCGsr87Ell1rafQPtBkfF5lclKdnSg36uT4ITDKAm1d8v4aOeLHPGXv44PEKF9LK2k7BnZ8lXMl94H/ryrsUElMN+wVmMTMCOHDk=; 20:xwrz/0aej/bhJZKhRZyTqoD8nEFTEgQBvl2uJ4m6OeyoKiJsFcSMagxx+Lw0qbFiWDy7UJxqvCTSibOm72CF4g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(377454003)(2900100001)(77096005)(15975445007)(102836002)(2501003)(2950100001)(107886002)(189998001)(5001960100002)(92566002)(106116001)(5002640100001)(76576001)(99286002)(19580405001)(46102003)(19580395003)(40100003)(74316001)(33656002)(2351001)(86362001)(2656002)(87936001)(122556002)(77156002)(5003600100002)(62966003)(86612001)(450100001)(50986999)(54356999)(76176999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 17:02:02.8770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2015 17:02:06 -0000 I agree with Victor that there is no conflict. If the server chooses to off= er different certificates for different application protocols, such server = needs to consider the negotiated ALPN ID while making the resumption decisi= on. And yes, if the same client alternates between different application protoc= ols, such client can be optimized by caching session state per negotiated a= pplication protocol ID. To me, these are implementation details, and probably not something a mains= tream implementation will support. But perhaps a better-written RFC would h= ave included this implementation guidance. I'll try to do better next time:= ). Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, July 1, 2015 9:34 AM To: tls@ietf.org Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific s= erver certificates On Wed, Jul 01, 2015 at 06:18:51PM +0200, Martin Rex wrote: > >> Unlike many other TLS extensions, this extension does not establish > >> properties of the session, only of the connection. When session > >> resumption or session tickets [RFC5077] are used, the previous > >> contents of this extension are irrelevant, and only the values in t= he > >> new handshake messages are considered. > >=20 > > I don't think there's a conflict here. All that's said is that ALPN=20 > > is not a session property, and its value for a previous connection=20 > > is not directly relevant for a new connection. Each connection=20 > > signals its own ALPN value. >=20 > There is a very clear conflict here. >=20 > A TLS session resume skips the exchange of credentials&identities=20 > (such as certificates), so as a result of a session resumption the=20 > session will have the _cached_ certificates from the original full TLS=20 > handshake as session attributes. And yet it is not a conflict. The specification says ALPN is per-connectio= n. Since certificates are per-session, either the client or the server nee= d to do the right thing and not re-use sessions that are not compatible wit= h the requested ALPN. Clients can try to maximize session re-use and leave the logic up to the se= rver (to perform a new handshake when the initial ALPN is associated with a= different server identity), or clients can maximize correctness in the fac= e of sloppily implemented servers and avoid reuse of sessions for a differe= nt ALPN value. So indeed most clients should create one session per ALPN value, thus turni= ng ALPN into a session property. Clients that can reasonably expect correc= t server logic might leave it up to the server to decide whether to create = a new session, or allow re-use, because both the new and the old ALPN value= map to the same server identity. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 2 06:17:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAFB1A6EE7 for ; Thu, 2 Jul 2015 06:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 rgSEq6R75BEV for ; Thu, 2 Jul 2015 06:17:22 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.14.11]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723041A21A8 for ; Thu, 2 Jul 2015 06:17:22 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id D1B337C94D47C; Thu, 2 Jul 2015 08:17:21 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id C26BD7C94D45E for ; Thu, 2 Jul 2015 08:17:21 -0500 (CDT) Received: from [96.231.221.219] (port=58733 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZAeMj-0001J3-2T for tls@ietf.org; Thu, 02 Jul 2015 08:17:21 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 2 Jul 2015 09:17:13 -0400 To: "" 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.221.219 X-Exim-ID: 1ZAeMj-0001J3-2T X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:58733 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] soliciting agenda topic for the ietf 93 tls sessions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2015 13:17:23 -0000 All, The IETF 93 agenda is out. We=92re scheduled for Tuesday 1520-1720 in = Congress Hall II and Wednesday 0900-1130 in the Grand Hilton Ballroom. = We requested two slots because a) we didn=92t have an interim between = IETF meetings and b) even with an interim between meetings last time we = were still rushing at the end. Please send in agenda requests to tls-chairs@tools.ietf.org. But, = please note that TLS 1.3-related issues and previously adopted drafts = will be given a priority during the sessions. We=92re also going to = give preferential treatment to items that got bumped last time as well = as drafts that generated discussion on the list. Cheers, j&s= From nobody Thu Jul 2 07:44:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9996B1A893F for ; Thu, 2 Jul 2015 07:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 OOdk5CxdOHKc for ; Thu, 2 Jul 2015 07:44:36 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D751A8949 for ; Thu, 2 Jul 2015 07:44:35 -0700 (PDT) Received: from pc1 (x4d030c1b.dyn.telefonica.de [::ffff:77.3.12.27]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 02 Jul 2015 16:44:32 +0200 id 000000000000011A.0000000055954E50.00004CB5 Date: Thu, 2 Jul 2015 16:45:36 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150702164536.598b0430@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-19637-1435848272-0001-2" Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2015 14:44:38 -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-19637-1435848272-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We recently had discussions about DSA and RSA padding modi. The draft still contains DSA and wants RSA in the old PKCS #1 1.5 padding mode. I think there was broad consensus to remove DSA, it's still in the draft. Would a Pull Request to remove it be welcome? On RSA there was only limited discussion, but I had the impression there is hardly an argument for not going with PSS cu, Hanno --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-19637-1435848272-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVlU6QAAoJEKWIAHK7tR5CcaQQAIW1a4KRIu1ybZATtTTOfq+1 N3gy9oRCWCIgq5TZKQzQyks1yWsqKBNfoWSfKyGi5yMcem3Wi9RuPdTQNv/JciKl Esdnb+/qs+3PmfM8zNkUL8AIIXupwm/5orcM/LnX4VfP+vSJ95zDFKpxW9HGwr8W WwfclEfuxvOc/0zOBfIEFH9ku5QQNY1NjCdI8dS+l8DDjBoymfQJekbdcbdc5DVw 0KoZkMuISROwZk8+M31os0bcqDhN9J0LkaTQyTL5dOGVEMGARPA7WG5aPwRk9G4L U332okIek+5oMXOtLFvm3JLlF77+73GqREygiH2ADFhTL5emb9qdmevcoEX5phLa wlJuAIvyJWpLeUpAZg/ZgO12JmVQJk3lVrX6MGybopgny/uE8kd2csrtysMa0St+ uZXpryA4U+xtEW5EZqf5zwnPrByEpLtubnXuF53aZgag5PtpoGnaAi5At3xr71NP tcoJJEa4X0S37IKICKEKDheO0QICKsyou0Gsas4GpsrWi86nyiCk8DdMdZmDsbQw uiPqTc5SJsgITGO2TMDPDr8YL43ds6ExdMBTx47FQIRypLRRloprTic1rL+B86BJ SGVbgtKsXn9HyUw/Ottq7wkTad/017E4zOoChjLTOnsBCiBjMUpq6b17z++ftWVf ZPnY6VBcavIsbrb+rhqC =FHWB -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-19637-1435848272-0001-2-- From nobody Thu Jul 2 09:42:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3BE1A00B4 for ; Thu, 2 Jul 2015 09:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, 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 YjEJqR7kXRpW for ; Thu, 2 Jul 2015 09:42:07 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA471A00B1 for ; Thu, 2 Jul 2015 09:42:07 -0700 (PDT) Received: by wgjx7 with SMTP id x7so67961261wgj.2 for ; Thu, 02 Jul 2015 09:42: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=8nNV/TEo8c4kN44vzKnziafYXDuMyDbL+8fzCXyPEDU=; b=atmLpwuy0NUS5vRSJ/4Qfhur9EQo3eKBiCbi0nBcIPxrepIvOEEvsFcKD7V4V5dg44 OHzAi1rxMv6bsABALMDUlukvwa+z+vdSl6DArBtBWehhVAsywSkcRQQX4ySd44V9XDhg SyBN2PLBPjeVAonbdzCLTKIrEq8hf5WvZVoKl8WvVvO93KFm39unvighDn7mBNfaFqqX ysacFO4zIxWr9sqrJifAVH6NvX8w2XCyebZaaoL2Y9Klplc9riThju+yK3wfKl2dz4+A 8YofDvavSdEt60831oVgnLA6DUT7ztDnT0x3aqKtZohpNWJ3giLZVhnOghFwoVshJGGa bafA== X-Gm-Message-State: ALoCoQl8EXzOS6ppXujOKPzygKwdt1SkOXajtM+ewYmSXpQQ8WiChJVEaZpH5rpMK52CENe8b1/u X-Received: by 10.194.158.42 with SMTP id wr10mr58666866wjb.81.1435855326066; Thu, 02 Jul 2015 09:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Thu, 2 Jul 2015 09:41:26 -0700 (PDT) In-Reply-To: <20150702164536.598b0430@pc1> References: <20150702164536.598b0430@pc1> From: Eric Rescorla Date: Thu, 2 Jul 2015 09:41:26 -0700 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Content-Type: multipart/alternative; boundary=089e013c6478a8cf780519e71e7e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2015 16:42:09 -0000 --089e013c6478a8cf780519e71e7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 2, 2015 at 7:45 AM, Hanno B=C3=B6ck wrote: > Hi, > > We recently had discussions about DSA and RSA padding modi. The draft > still contains DSA and wants RSA in the old PKCS #1 1.5 padding > mode. > Yes, these are orthogonal changes, I think. I think there was broad consensus to remove DSA, it's still in the > draft. Would a Pull Request to remove it be welcome? > I'll defer to the chairs on this point. If they declare consensus, I'll merge a PR. > On RSA there was only limited discussion, but I had the impression > there is hardly an argument for not going with PSS > We clearly can't go entirely to PSS as certificates have already been signed. We could require that the CertificateVerify be signed with PSS. -Ekr > > cu, Hanno > -- > Hanno B=C3=B6ck > http://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e013c6478a8cf780519e71e7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 2, 2015 at 7:45 AM, Hanno B=C3=B6ck <<= a href=3D"mailto:hanno@hboeck.de" target=3D"_blank">hanno@hboeck.de>= wrote:
Hi,

We recently had discussions about DSA and RSA padding modi. The draft
still contains DSA and wants RSA in the old PKCS #1 1.5 padding
mode.

Yes, these are orthogonal changes= , I think.


On RSA there was only limited discussion, but I had the impression
there is hardly an argument for not going with PSS
We clearly can't go entirely to PSS as certificates have al= ready been signed.
We could require that the CertificateVerify be= signed with PSS.

-Ekr



=C2=A0

cu, Hanno
--
Hanno B=C3=B6ck
http://h= boeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

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


--089e013c6478a8cf780519e71e7e-- From nobody Thu Jul 2 14:40:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA8D1A8740 for ; Thu, 2 Jul 2015 14:40:23 -0700 (PDT) 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 A63uMZ-bXo-N for ; Thu, 2 Jul 2015 14:40:21 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEAE1A872B for ; Thu, 2 Jul 2015 14:40:21 -0700 (PDT) Received: by ieqy10 with SMTP id y10so65851786ieq.0 for ; Thu, 02 Jul 2015 14:40:20 -0700 (PDT) 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=nLGBQZdJQzOkMKNLYuSpbnhPHM5I42/ZiZRZqIBnpa8=; b=dJ8RFANhYNM0V5X8TQIYuEFANbdb118McSQyUUc4rsIc1LwWG7CFHwM/J3rKWMSoTj /Nx2va/jutU4FzaN5sRQsqL6WRl1wHMZv54okDzBGi9CYdtO7tzegwYwmCxDcPAbWyY2 Z3Fx7P9JW+OtAqmN0tUwz5S0p9hqrKT/HECxxh4kfhSwrzgdm2LLI32Hb+sgVLZLxlAE vtUp2QHQxB5JGNVGDyNzrQ9ffT9AkiMaAhKMClh06mKJxkaUP5OTDpMzotAL8hlIOlD6 hCExOzYS70X+KCs5qaOCA1RiMQvJKjQ4YZqU2ruvivM9WTFjdJPxHAsghuyJBnoIl19A nCtA== MIME-Version: 1.0 X-Received: by 10.107.32.73 with SMTP id g70mr51215829iog.23.1435873220817; Thu, 02 Jul 2015 14:40:20 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.79.104.193 with HTTP; Thu, 2 Jul 2015 14:40:20 -0700 (PDT) Date: Thu, 2 Jul 2015 17:40:20 -0400 X-Google-Sender-Auth: cINjHuPIYXdkiXFliR39zRVlN5E Message-ID: From: Erik Nygren To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1140407844fc8e0519eb4947 Archived-At: Subject: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2015 21:40:23 -0000 --001a1140407844fc8e0519eb4947 Content-Type: text/plain; charset=UTF-8 Following a discussion last year in Denver, I've written up a proposal for a TLS Client Puzzles extension. It is specific to TLS 1.3 in that it is constructed using the HelloRetryRequest request flow (although it could be adapted to HelloVerifyRequest with prior versions of DTLS). The puzzles here are placeholders meant as a starting-point for discussion (and also take in some feedback from discussions on this list last year) and will likely evolve. Erik ---------- Forwarded message ---------- From: Date: Thu, Jul 2, 2015 at 5:30 PM Subject: New Version Notification for draft-nygren-tls-client-puzzles-00.txt To: Erik Nygren A new version of I-D, draft-nygren-tls-client-puzzles-00.txt has been successfully submitted by Erik Nygren and posted to the IETF repository. Name: draft-nygren-tls-client-puzzles Revision: 00 Title: TLS Client Puzzles Extension Document date: 2015-07-02 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-nygren-tls-client-puzzles-00.txt Status: https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/ Htmlized: https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-00 Abstract: Client puzzles allow a TLS server to defend itself against asymmetric DDoS attacks. In particular, it allows a server to request clients perform a selected amount of computation prior to the server performing expensive cryptographic operations. This allows servers to employ a layered defense that represents an improvement over pure rate-limiting strategies. Client puzzles are implemented as an extension to TLS 1.3 [I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRequest containing the puzzle as an extension. The client must then resend its ClientHello with the puzzle results in the extension. 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. The IETF Secretariat --001a1140407844fc8e0519eb4947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following a discussion last year in Denver, I= 9;ve written up a proposal
for a TLS Client Puzzles extension.=C2= =A0 It is specific to TLS 1.3 in that
it is constructed using the HelloR= etryRequest request flow (although
it could be adapted to Hel= loVerifyRequest with prior versions of DTLS).

T= he puzzles here are placeholders meant as a starting-point for discussion(and also take in some feedback from discussions on this list last year)<= br>and will likely evolve.

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Erik


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Jul 2, 2015 at 5:= 30 PM
Subject: New Version Notification for draft-nygren-tls-client-puzz= les-00.txt
To: Erik Nygren <erik+ietf@nygren.org>



A new version of I-D, draft-nygren-tls-client-puzzles-00.txt
has been successfully submitted by Erik Nygren and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-nygren-tls-client-puzzl= es
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS Client Puzzles Extension
Document date:=C2=A0 2015-07-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-nygren-tls-= client-puzzles-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-nygren-tls-client-puzzles-00


Abstract:
=C2=A0 =C2=A0Client puzzles allow a TLS server to defend itself against asy= mmetric
=C2=A0 =C2=A0DDoS attacks.=C2=A0 In particular, it allows a server to reque= st clients
=C2=A0 =C2=A0perform a selected amount of computation prior to the server =C2=A0 =C2=A0performing expensive cryptographic operations.=C2=A0 This allo= ws servers
=C2=A0 =C2=A0to employ a layered defense that represents an improvement ove= r pure
=C2=A0 =C2=A0rate-limiting strategies.

=C2=A0 =C2=A0Client puzzles are implemented as an extension to TLS 1.3
=C2=A0 =C2=A0[I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRe= quest
=C2=A0 =C2=A0containing the puzzle as an extension.=C2=A0 The client must t= hen resend
=C2=A0 =C2=A0its ClientHello with the puzzle results in the extension.




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.

The IETF Secretariat


--001a1140407844fc8e0519eb4947-- From nobody Thu Jul 2 15:23:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBFF1AC3DC for ; Thu, 2 Jul 2015 15:23:50 -0700 (PDT) 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_31=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 JePx6ILM5u33 for ; Thu, 2 Jul 2015 15:23:48 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1846F1AC3D4 for ; Thu, 2 Jul 2015 15:23:48 -0700 (PDT) Received: by wguu7 with SMTP id u7so74263123wgu.3 for ; Thu, 02 Jul 2015 15:23:46 -0700 (PDT) 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=pgc0BBFua3sNh/7fcg52kBeUSHL3v+p7zbjuZ12V1RE=; b=WcDVxI71pZntlsQ5amxGXyfhrd5m8VQ51I2DqpqZsoPHbdS1qgpqszCk+78VsoJJuh r353rgq3+hvp7b+sLeWnigCrZH9gFJe4wzxXbJJd5+B8ezJvpVaHvycQcpnEgoRYQ3B8 I2BwPR+ghgzIeoxgMyuWfCsrCMdiNFgKSNT7cxRBUtdkBZnymLC3FlqlH/0cI3D8pCOT J/BHu17mIn/WvfycF0iTQbqFGCLGrUrbv4S9FAjROwNMvPMDjtY6DKD+OrfcIGMgX75w 6E1virAyvVKzgV2d0j5MHjmgdbeisQ4/PcJ1RCMNWwKzNT2j/cYCAKqSP0eFzczImliu b4hA== X-Received: by 10.194.238.193 with SMTP id vm1mr14779620wjc.57.1435875826869; Thu, 02 Jul 2015 15:23:46 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ma15sm29316779wic.20.2015.07.02.15.23.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 15:23:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_862D7B1D-6D91-4A25-BA15-E25676889DFA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Fri, 3 Jul 2015 01:23:43 +0300 Message-Id: <8471B245-2B66-4F4D-8675-3A0F64E5681F@gmail.com> References: To: Erik Nygren X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2015 22:23:50 -0000 --Apple-Mail=_862D7B1D-6D91-4A25-BA15-E25676889DFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Erik You might be interested in the similar work we=E2=80=99re doing at = IPsecME: = https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-01#section-= 3 = After discussing multiple puzzle schemes, we (for now) settled on a = puzzle that uses a MAC function such as HMAC-SHA256. The server sets the puzzle level to n and generates a calculable = challenge (for TLS it could be random). The client finds a key k for the = MAC function such the result of MAC(k,challenge) has at least n trailing = zero bits. The expected time to solve such a puzzle is 2^n invocations of the MAC = function. There are two issues: 1. The time it takes to find a key that works varies a lot. A puzzle = that takes on average 1 second to solve could take an unlucky client = half a minute. 2. Clients are diverse. Mobile phones and embedded devices are far = weaker than desktop computers. What=E2=80=99s hard enough for one = machine is too hard for another. We can solve #1 by increasing the number or required distinct solutions = while reducing the number of zero bits: http://www.ietf.org/mail-archive/web/ipsec/current/msg09844.html = We don=E2=80=99t know how to solve #2. Yoav > On Jul 3, 2015, at 12:40 AM, Erik Nygren wrote: >=20 > Following a discussion last year in Denver, I've written up a proposal > for a TLS Client Puzzles extension. It is specific to TLS 1.3 in that > it is constructed using the HelloRetryRequest request flow (although > it could be adapted to HelloVerifyRequest with prior versions of = DTLS). >=20 > The puzzles here are placeholders meant as a starting-point for = discussion > (and also take in some feedback from discussions on this list last = year) > and will likely evolve. >=20 > Erik >=20 >=20 > ---------- Forwarded message ---------- > From: > > Date: Thu, Jul 2, 2015 at 5:30 PM > Subject: New Version Notification for = draft-nygren-tls-client-puzzles-00.txt > To: Erik Nygren > >=20 >=20 >=20 > A new version of I-D, draft-nygren-tls-client-puzzles-00.txt > has been successfully submitted by Erik Nygren and posted to the > IETF repository. >=20 > Name: draft-nygren-tls-client-puzzles > Revision: 00 > Title: TLS Client Puzzles Extension > Document date: 2015-07-02 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-nygren-tls-client-puzzles-00.tx= t = > Status: = https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/ = > Htmlized: = https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-00 = >=20 >=20 > Abstract: > Client puzzles allow a TLS server to defend itself against = asymmetric > DDoS attacks. In particular, it allows a server to request clients > perform a selected amount of computation prior to the server > performing expensive cryptographic operations. This allows servers > to employ a layered defense that represents an improvement over = pure > rate-limiting strategies. >=20 > Client puzzles are implemented as an extension to TLS 1.3 > [I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRequest > containing the puzzle as an extension. The client must then resend > its ClientHello with the puzzle results in the extension. >=20 >=20 >=20 >=20 > 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 = . >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_862D7B1D-6D91-4A25-BA15-E25676889DFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Erik

You might be interested in the similar work we=E2=80=99re = doing at IPsecME:
https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-= 01#section-3

After discussing multiple puzzle schemes, we (for now) = settled on a puzzle that uses a MAC function such as = HMAC-SHA256.

The= server sets the puzzle level to n and generates a calculable challenge = (for TLS it could be random). The client finds a key k for the MAC = function such the result of MAC(k,challenge) has at least n trailing = zero bits.

The = expected time to solve such a puzzle is 2^n invocations of the MAC = function. There are two issues:
  1. The time = it takes to find a key that works varies a lot. A puzzle that takes on = average 1 second to solve could take an unlucky client half a = minute.
  2. Clients are diverse. Mobile = phones and embedded devices are far weaker than desktop computers. = What=E2=80=99s hard enough for one machine is too hard for = another.

We = can solve #1 by increasing the number or required distinct solutions = while reducing the number of zero bits:
http://www.ietf.org/mail-archive/web/ipsec/current/msg09844.htm= l

We = don=E2=80=99t know how to solve #2.

Yoav

On Jul 3, 2015, at 12:40 AM, Erik Nygren = <erik+ietf@nygren.org> wrote:

Following a discussion last = year in Denver, I've written up a proposal
for a TLS = Client Puzzles extension.  It is specific to TLS 1.3 in that
it is constructed using the HelloRetryRequest request flow = (although
it could be adapted to = HelloVerifyRequest with prior versions of DTLS).

The puzzles = here are placeholders meant as a starting-point for discussion
(and also take in some feedback from discussions on this list = last year)
and will likely evolve.

        Erik


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: = Thu, Jul 2, 2015 at 5:30 PM
Subject: New Version = Notification for draft-nygren-tls-client-puzzles-00.txt
To: = Erik Nygren <erik+ietf@nygren.org>



A new version of I-D, draft-nygren-tls-client-puzzles-00.txt
has been successfully submitted by Erik Nygren and posted to the
IETF repository.

Name:          =  draft-nygren-tls-client-puzzles
Revision:       00
Title:          TLS Client Puzzles Extension
Document date:  2015-07-02
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-nygren-tls-client-pu= zzles-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzle= s/
Htmlized:       https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-00<= /a>


Abstract:
   Client puzzles allow a TLS server to defend itself against = asymmetric
   DDoS attacks.  In particular, it allows a server to = request clients
   perform a selected amount of computation prior to the = server
   performing expensive cryptographic operations.  This = allows servers
   to employ a layered defense that represents an improvement = over pure
   rate-limiting strategies.

   Client puzzles are implemented as an extension to TLS = 1.3
   [I-D.ietf-tls-tls13] wherein a server can issue a = HelloRetryRequest
   containing the puzzle as an extension.  The client = must then resend
   its ClientHello with the puzzle results in the = extension.




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.

The IETF Secretariat


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

= --Apple-Mail=_862D7B1D-6D91-4A25-BA15-E25676889DFA-- From nobody Thu Jul 2 15:33:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC101AC400 for ; Thu, 2 Jul 2015 15:33:55 -0700 (PDT) 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_31=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 dUucZI2KXqRf for ; Thu, 2 Jul 2015 15:33:53 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51DC1AC3EE for ; Thu, 2 Jul 2015 15:33:53 -0700 (PDT) Received: by ieqy10 with SMTP id y10so66552973ieq.0 for ; Thu, 02 Jul 2015 15:33:53 -0700 (PDT) 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=y7WUnyTXZVdlHBSi0TWPRWp33edyPuAuZ8xhxk4F6To=; b=V0m310iaZK/DwYbKDcRp3Jd7STOHlXPVjM73oGv6rB/CBwIoDAGeEZeD5uryLaR5Dx oE5loWSEUNNwrbw1y6RGdN3b5Myyw3oz/x5v+xdBBUcmcJnvqoEr4vAMBlPyYx6rnWEx 6D06dNsxB/agi9vbidvHPQu/Ylxjc0EFDOCCjwzA1zm1T1Do2kuVU6YfsXPGH0beZS5B P1q8rBcUUMkDTUJh+w/3aGUXUIg+zObbGmo1+bveYXBCYr7qyaA2Bjf4crQ/Nwgs1IgE O2htKq0W1gRtCwIe8y9EDg4Aj42yE9EKnYJYL7n9WGjbLxqtciLhjF/BOku1W/RvvGoi /9yg== MIME-Version: 1.0 X-Received: by 10.42.144.131 with SMTP id b3mr15228215icv.35.1435876432969; Thu, 02 Jul 2015 15:33:52 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.79.104.193 with HTTP; Thu, 2 Jul 2015 15:33:52 -0700 (PDT) In-Reply-To: <8471B245-2B66-4F4D-8675-3A0F64E5681F@gmail.com> References: <8471B245-2B66-4F4D-8675-3A0F64E5681F@gmail.com> Date: Thu, 2 Jul 2015 18:33:52 -0400 X-Google-Sender-Auth: u5OhkgNTSahehLj_dVXeQ85lqwY Message-ID: From: Erik Nygren To: Yoav Nir Content-Type: multipart/alternative; boundary=90e6ba1efd28ba88c80519ec080d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2015 22:33:56 -0000 --90e6ba1efd28ba88c80519ec080d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Yoav. Brandon Williams pointed that IPsecME doc out to me earlier toda= y and it's linked from later on in the draft. I was proposing something very similar using a SHA256 or HMAC-SHA256 as a starting point. Based on discussion here last year, I let the puzzle level parameter be specified directly (rather than as an exponent) as that allows servers to scale difficulty more linearly. I believe that for this proposed puzzle, the average solution time should be half the worst-case time for a given client (but the best case could be better). Incorporating a puzzle with a memory-hard component (I give one poor exampl= e where that component is symmetric) may be an option for mobile clients who are more CPU constrained than memory-bandwidth constrained. We have some other ideas here we're still exploring. Thanks, Erik On Thu, Jul 2, 2015 at 6:23 PM, Yoav Nir wrote: > Hi, Erik > > You might be interested in the similar work we=E2=80=99re doing at IPsecM= E: > https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-01#section= -3 > > After discussing multiple puzzle schemes, we (for now) settled on a puzzl= e > that uses a MAC function such as HMAC-SHA256. > > The server sets the puzzle level to n and generates a calculable challeng= e > (for TLS it could be random). The client finds a key k for the MAC functi= on > such the result of MAC(k,challenge) has at least n trailing zero bits. > > The expected time to solve such a puzzle is 2^n invocations of the MAC > function. There are two issues: > 1. The time it takes to find a key that works varies a lot. A puzzle > that takes on average 1 second to solve could take an unlucky client half= a > minute. > 2. Clients are diverse. Mobile phones and embedded devices are far > weaker than desktop computers. What=E2=80=99s hard enough for one machine= is too > hard for another. > > We can solve #1 by increasing the number or required distinct solutions > while reducing the number of zero bits: > http://www.ietf.org/mail-archive/web/ipsec/current/msg09844.html > > We don=E2=80=99t know how to solve #2. > > Yoav > > On Jul 3, 2015, at 12:40 AM, Erik Nygren wrote: > > Following a discussion last year in Denver, I've written up a proposal > for a TLS Client Puzzles extension. It is specific to TLS 1.3 in that > it is constructed using the HelloRetryRequest request flow (although > it could be adapted to HelloVerifyRequest with prior versions of DTLS). > > The puzzles here are placeholders meant as a starting-point for discussio= n > (and also take in some feedback from discussions on this list last year) > and will likely evolve. > > Erik > > > ---------- Forwarded message ---------- > From: > Date: Thu, Jul 2, 2015 at 5:30 PM > Subject: New Version Notification for > draft-nygren-tls-client-puzzles-00.txt > To: Erik Nygren > > > > A new version of I-D, draft-nygren-tls-client-puzzles-00.txt > has been successfully submitted by Erik Nygren and posted to the > IETF repository. > > Name: draft-nygren-tls-client-puzzles > Revision: 00 > Title: TLS Client Puzzles Extension > Document date: 2015-07-02 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-nygren-tls-client-puzzles-00.t= xt > Status: > https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/ > Htmlized: > https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-00 > > > Abstract: > Client puzzles allow a TLS server to defend itself against asymmetric > DDoS attacks. In particular, it allows a server to request clients > perform a selected amount of computation prior to the server > performing expensive cryptographic operations. This allows servers > to employ a layered defense that represents an improvement over pure > rate-limiting strategies. > > Client puzzles are implemented as an extension to TLS 1.3 > [I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRequest > containing the puzzle as an extension. The client must then resend > its ClientHello with the puzzle results in the extension. > > > > > 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. > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --90e6ba1efd28ba88c80519ec080d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Yoav.=C2=A0 Brandon Williams pointed th= at IPsecME doc out to me earlier today
and it's linked from later on= in the draft.

I was proposing something very similar using a = SHA256 or HMAC-SHA256 as a starting point.
Based on discussio= n here last year, I let the puzzle level parameter be specified directly
(rather than as an exponent) as that allows servers to scale di= fficulty more linearly.
I believe that for this proposed puzzle, t= he average solution time should be
half the worst-case time for a given= client (but the best case could be better).

Incorporatin= g a puzzle with a memory-hard component (I give one poor example
<= div>where that component is symmetric) may be an option for mobile clients = who
are more CPU constrained than memory-bandwidth constrained.=C2=A0 W= e have
some other ideas here we're still exploring.
Thanks, Erik



On Thu, Jul 2, 2015 at 6:23 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Erik

You migh= t be interested in the similar work we=E2=80=99re doing at IPsecME:
https://tools.ietf.org/html/draft-ietf-ip= secme-ddos-protection-01#section-3

After discu= ssing multiple puzzle schemes, we (for now) settled on a puzzle that uses a= MAC function such as HMAC-SHA256.

The server sets= the puzzle level to n and generates a calculable challenge (for TLS it cou= ld be random). The client finds a key k for the MAC function such the resul= t of MAC(k,challenge) has at least n trailing zero bits.

The expected time to solve such a puzzle is 2^n invocations of the M= AC function. There are two issues:
=C2=A0 1. The time it takes to= find a key that works varies a lot. A puzzle that takes on average 1 secon= d to solve could take an unlucky client half a minute.
=C2=A0 2. = Clients are diverse. Mobile phones and embedded devices are far weaker than= desktop computers. What=E2=80=99s hard enough for one machine is too hard = for another.

We can solve #1 by increasing the num= ber or required distinct solutions while reducing the number of zero bits:<= /div>

We don=E2=80=99t know how = to solve #2.

Yoav

On Jul 3, 2015, at 12:4= 0 AM, Erik Nygren <erik+ietf@nygren.org> wrote:

Following a discussion last year = in Denver, I've written up a proposal
for a TLS Client Puzzles= extension.=C2=A0 It is specific to TLS 1.3 in that
it is constructed us= ing the HelloRetryRequest request flow (although
it could be = adapted to HelloVerifyRequest with prior versions of DTLS).
<= div>

The puzzles here are placeholders meant as a starting-point fo= r discussion
(and also take in some feedback from discussions on this li= st last year)
and will likely evolve.

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Jul 2, 2015 at 5:30 PM
Subject: New Version Notification= for draft-nygren-tls-client-puzzles-00.txt
To: Erik Nygren <erik+ietf@nygren.org>



A new version of I-D, draft-nygren-tls-client-puzzles-00.txt
has been successfully submitted by Erik Nygren and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-nygren-tls-client-puzzl= es
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS Client Puzzles Extension
Document date:=C2=A0 2015-07-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-nygren-tls-= client-puzzles-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-nygren-tls-client-puzzles-00


Abstract:
=C2=A0 =C2=A0Client puzzles allow a TLS server to defend itself against asy= mmetric
=C2=A0 =C2=A0DDoS attacks.=C2=A0 In particular, it allows a server to reque= st clients
=C2=A0 =C2=A0perform a selected amount of computation prior to the server =C2=A0 =C2=A0performing expensive cryptographic operations.=C2=A0 This allo= ws servers
=C2=A0 =C2=A0to employ a layered defense that represents an improvement ove= r pure
=C2=A0 =C2=A0rate-limiting strategies.

=C2=A0 =C2=A0Client puzzles are implemented as an extension to TLS 1.3
=C2=A0 =C2=A0[I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRe= quest
=C2=A0 =C2=A0containing the puzzle as an extension.=C2=A0 The client must t= hen resend
=C2=A0 =C2=A0its ClientHello with the puzzle results in the extension.




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.

The IETF Secretariat


_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

<= /div>
--90e6ba1efd28ba88c80519ec080d-- From nobody Fri Jul 3 00:04:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794A51B2E08 for ; Fri, 3 Jul 2015 00:04:39 -0700 (PDT) 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, 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 KDFKrbAjgF4Y for ; Fri, 3 Jul 2015 00:04:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0087.outbound.protection.outlook.com [207.46.100.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A521B2E03 for ; Fri, 3 Jul 2015 00:04:35 -0700 (PDT) Received: from CY1PR0101MB1145.prod.exchangelabs.com (10.161.163.19) by CY1PR0101MB1146.prod.exchangelabs.com (10.161.163.20) with Microsoft SMTP Server (TLS) id 15.1.195.15; Fri, 3 Jul 2015 07:04:32 +0000 Received: from CY1PR0101MB1145.prod.exchangelabs.com ([10.161.163.19]) by CY1PR0101MB1145.prod.exchangelabs.com ([10.161.163.19]) with mapi id 15.01.0201.000; Fri, 3 Jul 2015 07:04:32 +0000 From: Douglas Stebila To: Erik Nygren Thread-Topic: [TLS] TLS Client Puzzles Thread-Index: AQHQtQ/CQ5dQDPZoIE+JhoJtUgQIC53JUuMA Date: Fri, 3 Jul 2015 07:04:31 +0000 Message-ID: <12E32989-ADA3-4008-B943-76A0BAF962DA@qut.edu.au> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: nygren.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [131.181.47.191] x-microsoft-exchange-diagnostics: 1; CY1PR0101MB1146; 5:WB4UdYsjCzMC9PTGsm/JMIKGaItMocviwUAhlJefA/C5U3xZPCDstF2HCXIuKBNXxS6WmXvuYS4isvSxwykNm8GHsfCYK5ZwRVOLls+NnMW7f1unxK0BMnJ4sDTignREUwFzo1qc8O9Q32oQPkHK4Q==; 24:kC6hrg/DkIpQh9MiAR4iZuvHoF+5Igl2aKrGBSR4MKkqnGt1C88Gyq7EwWXRPNmuxmSsWDyJUXc2xgRjFlWt0CEf8Wgby6yu+jTAd93Nf6k=; 20:dP/IJA8rDOU9qbFQtxIkZamVyf/qsOF+QcR4LhqCx4nXLxOzRC+38jk7g1onkGY7mWWXAAqG2/TIHeUSUsAjBw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0101MB1146; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005006)(3002001); SRVR:CY1PR0101MB1146; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB1146; x-forefront-prvs: 0626C21B10 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(377424004)(24454002)(51704005)(377454003)(36756003)(62966003)(77156002)(40100003)(122556002)(66066001)(2950100001)(15975445007)(102836002)(77096005)(1720100001)(86362001)(2900100001)(74826001)(50226001)(561944003)(50986999)(33656002)(106116001)(87936001)(19580395003)(19580405001)(5001960100002)(110136002)(5002640100001)(46102003)(92566002)(88552001)(83716003)(57306001)(2656002)(76176999)(189998001)(74482002)(82746002)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0101MB1146; H:CY1PR0101MB1145.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qut.edu.au X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2015 07:04:31.9377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dc0b52a3-68c5-44f7-881d-9383d8850b96 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1146 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 07:04:39 -0000 My research group did some experimental work a few years ago involving clie= nt puzzles in TLS; some of the results might be of interest, though not all= : we focused on RSA key transport ciphersuites (rather than ECDHE) and als= o considered a new signature algorithm for client authentication based on a= design of Bernstein. In our modifications to TLS, the client advertised "PuzzlesSupported" in a = ClientHello extension, and the server responded with a Puzzle in a ServerHe= llo extension. The client turned the solution in a new message coming in t= he same flight as the ClientKeyExchange. Our design focused only on RSA ke= y transport-based ciphersuites, so this was sufficient to save the server f= rom doing computationally expensive cryptographic operations before checkin= g the puzzle solution. Our puzzle was based on SHA-1, and involved finding an input that when hash= ed started with at least 12 zeros. We did some experiments to determine performance impact and benefit. The c= iphersuite was RSA key transport with server-only authentication, 1024-bit = keys; AES-128 in CBC mode for bulk encryption and SHA-1 for the hash functi= on. In the face of legitimate requests, this verification procedure reduce= d the number of supported connections by 0.6%, from 1924 connections/second= to 1911 connections/second. In the face of a flood of garbage requests, t= he server could discard 5109 requests/second. The paper can be found here: http://www.douglas.stebila.ca/research/papers/RSBG11 As I mentioned we were investigating another signature scheme as well, so t= hose portions of the paper would not be relevant to this proposal. Douglas > On Jul 3, 2015, at 07:40, Erik Nygren wrote: >=20 > Following a discussion last year in Denver, I've written up a proposal > for a TLS Client Puzzles extension. It is specific to TLS 1.3 in that > it is constructed using the HelloRetryRequest request flow (although > it could be adapted to HelloVerifyRequest with prior versions of DTLS). >=20 > The puzzles here are placeholders meant as a starting-point for discussio= n > (and also take in some feedback from discussions on this list last year) > and will likely evolve. >=20 > Erik >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Thu, Jul 2, 2015 at 5:30 PM > Subject: New Version Notification for draft-nygren-tls-client-puzzles-00.= txt > To: Erik Nygren >=20 >=20 >=20 > A new version of I-D, draft-nygren-tls-client-puzzles-00.txt > has been successfully submitted by Erik Nygren and posted to the > IETF repository. >=20 > Name: draft-nygren-tls-client-puzzles > Revision: 00 > Title: TLS Client Puzzles Extension > Document date: 2015-07-02 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-nygren-tls-cli= ent-puzzles-00.txt > Status: https://datatracker.ietf.org/doc/draft-nygren-tls-client-= puzzles/ > Htmlized: https://tools.ietf.org/html/draft-nygren-tls-client-puzzl= es-00 >=20 >=20 > Abstract: > Client puzzles allow a TLS server to defend itself against asymmetric > DDoS attacks. In particular, it allows a server to request clients > perform a selected amount of computation prior to the server > performing expensive cryptographic operations. This allows servers > to employ a layered defense that represents an improvement over pure > rate-limiting strategies. >=20 > Client puzzles are implemented as an extension to TLS 1.3 > [I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRequest > containing the puzzle as an extension. The client must then resend > its ClientHello with the puzzle results in the extension. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jul 3 10:23:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBF51A0127 for ; Fri, 3 Jul 2015 10:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 CrFfYaZJ09hP for ; Fri, 3 Jul 2015 10:23:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D031A0120 for ; Fri, 3 Jul 2015 10:23:31 -0700 (PDT) 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 (Postfix) with ESMTPS id 85AB0C12D5; Fri, 3 Jul 2015 17:23:31 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-81.ams2.redhat.com [10.36.112.81]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t63HNRRw028228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2015 13:23:30 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 03 Jul 2015 19:23:19 +0200 Message-ID: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1880323.POp5y8UydW"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 17:23:33 -0000 --nextPart1880323.POp5y8UydW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 30 June 2015 15:23:18 Eric Rescorla wrote: > Folks, >=20 > Yesterday, I posted the -06 draft which snapshots the consensus chang= es > made since -05, specifically: >=20 > - Prohibit RC4 negotiation for backwards compatibility. > - Freeze & deprecate record layer version field. > - Update format of signatures with context. > - Remove explicit IV. I've noticed that the default values in case the client didn't use sign= ature=20 algorithms extensions is to use SHA1+RSA, SHA1+DSA and SHA1+ECDSA. As we all know, those are not considered secure now. Maybe we should update it to SHA256 for all three? =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1880323.POp5y8UydW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVlsUNAAoJEJKo0bgB0vX1RjYP/AyVK2+7IJ/aKjHNAKuG4sve DbSgKDkXzekKDnoid6Or3f8Cmb4+xu64fjxN7w/Z6kzbTd7RnmTwWnfSNdRRaRZx tTj/Y8SxkHbDvVcKIMu/teYXVjZp2sPtyBhnb0Tyvpm/6hHpf71pW3yZN6nEBxvK XJuH21uQftpUlCTd49bUxlMcmKgG5+f58pKxY9gMhqcc+KiD3HwVdCK69kBU7bK3 x1dbWecc3Y/jkgRMQ+RVULDCsX4ENnZamkngFOgsqZ1nVKp3WCE7tnVDc9HvEZhT zbSlyDSK7Hw04OLbZWnwGKTM+gE4QTS5Qlnp5hZ2K9L6/PdeaDeldVqvGlVUTXiY 9LEum3FWeJ86RSEKEs0h8O5CWug9cGSsOQxoFh1e+3t9yiDhu3/uxM0LREJvECP3 xghwe/yohHZ052hkHFW49Cea2j7RTHGJBhkRz3yuhdtzfWt3werfCbNdg/s5g/CZ YU4Hcwt2bPK0l0HF0bIj7/ZiDzyxj1XIa6jxMD9ynpsSwxAkgqrrB5xypbIO9j4e 13z0HrAHhDZZb37+yVeDxOxYHGmIgCl8OPDVSC+fA08LgHFJmRGKpjNVOGY8Qz/Z IWxW0UMzDMiyCVoFXC4kNPsNgHkqVTVifDb90ors5p/2SbLR2dQ88UDLfKftskB3 180ELscIMxZOSFA+/Rjv =kPkx -----END PGP SIGNATURE----- --nextPart1880323.POp5y8UydW-- From nobody Fri Jul 3 10:35:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FDF1A0171 for ; Fri, 3 Jul 2015 10:35:23 -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 Qsp4vOkIrXkl for ; Fri, 3 Jul 2015 10:35:22 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD811A016B for ; Fri, 3 Jul 2015 10:35:21 -0700 (PDT) Received: by wguu7 with SMTP id u7so93443166wgu.3 for ; Fri, 03 Jul 2015 10:35:20 -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=waCGZ3pYKuSSOcrGopmJ9HbcRGFVkO7BokxSKm0mbT4=; b=KKZDGaVyP5/lPMeFMDNVo+H3uL3X8z3vVl/ClsGXvOuNWHUdaxlNyj74uc5ha9dkTY Rc2TumvSAq7mpY9FPH4tWMS9pVP0MI1P5ZIYy+sOIsJDxzOq/ZK8/9udEaZBnMAA1bZi ljGmwlpjOZZ0JKbzHpvRtv6hxaZrf25IsAO+HXgAVTc9xAgA026U13QTK3c9POGTczyu u9ZrvMZtZ3pksi+v4NiCjSKPGWvmzb8lnBIwfm5iza1Yzm7waFVvMulkiJa/ATR8ev4B Vl2UWBPcRBOH9m/0ZG3U0xXvSAjQ5wB+w3AQY+YWub1bQKHYKmth1YEc3/4PvRBMhzpF Hmkg== X-Gm-Message-State: ALoCoQkTdwc3b/rDtN1AtCC9GLMnjTKxXBSQHmdHMnA+M7jurkzdWEazaZ5qj8dyDPD1Q32LyWi0 X-Received: by 10.194.79.225 with SMTP id m1mr23290281wjx.8.1435944920679; Fri, 03 Jul 2015 10:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Fri, 3 Jul 2015 10:34:41 -0700 (PDT) In-Reply-To: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> References: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Fri, 3 Jul 2015 10:34:41 -0700 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=047d7b10c903ea1de40519fbfa58 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 17:35:23 -0000 --047d7b10c903ea1de40519fbfa58 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 3, 2015 at 10:23 AM, Hubert Kario wrote: > On Tuesday 30 June 2015 15:23:18 Eric Rescorla wrote: > > Folks, > > > > Yesterday, I posted the -06 draft which snapshots the consensus changes > > made since -05, specifically: > > > > - Prohibit RC4 negotiation for backwards compatibility. > > - Freeze & deprecate record layer version field. > > - Update format of signatures with context. > > - Remove explicit IV. > > I've noticed that the default values in case the client didn't use > signature > algorithms extensions is to use SHA1+RSA, SHA1+DSA and SHA1+ECDSA. > > As we all know, those are not considered secure now. > > Maybe we should update it to SHA256 for all three? I would welcome a PR for that. -Ekr --047d7b10c903ea1de40519fbfa58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 3, 2015 at 10:23 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Tues= day 30 June 2015 15:23:18 Eric Rescorla wrote:
> Folks,
>
> Yesterday, I posted the -06 draft which snapshots the consensus change= s
> made since -05, specifically:
>
> - Prohibit RC4 negotiation for backwards compatibility.
> - Freeze & deprecate record layer version field.
> - Update format of signatures with context.
> - Remove explicit IV.

I've noticed that the default values in case the client didn'= ;t use signature
algorithms extensions is to use SHA1+RSA, SHA1+DSA and SHA1+ECDSA.

As we all know, those are not considered secure now.

Maybe we should update it to SHA256 for all three?

I would welcome a PR for that.

-Ekr
<= div>
--047d7b10c903ea1de40519fbfa58-- From nobody Fri Jul 3 10:38:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED14F1A1B59 for ; Fri, 3 Jul 2015 10:38:21 -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 qXcwjUTN427r for ; Fri, 3 Jul 2015 10:38:20 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE461A0383 for ; Fri, 3 Jul 2015 10:38:20 -0700 (PDT) Received: by ykdy1 with SMTP id y1so100986217ykd.2 for ; Fri, 03 Jul 2015 10:38:19 -0700 (PDT) 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=Fe2YNanMYa9Kvzo2Rv+nOHUsEkNx5rGzwvstlQGK9xk=; b=VnY0jCAC+HRB9OkqyZlMMOjIuy5z24Vp7SQyA+pFx6lwU0cSaVSm19CLgMqf/2dMjw IAJYCGBAUlz/YEOv9xMm20xZvV0yUIm9nJ6mRNEzshb9zPGfyArHr/rQZXN+PA+zjip1 KiZhKsNF0asjBGKwg1m9aYG+xc6Y0ouzlHdM5n6Z8MTGzFT5Y2v/Gaj5py8vfANw2bDL MGecxboJVwqXIbUwLS55udKBxDEx4nbhth4QtPI3uX25kuSXUE0Rer898tpCWtKBMelv 9lO1vCPuHyPPUl/i5O8XndZtVcpT/IEgRrEUw0slvZaFiB2f9lUeVg2Syb8x4L2rXYgT 9Qgg== X-Received: by 10.170.173.7 with SMTP id p7mr20090135ykd.114.1435945099572; Fri, 03 Jul 2015 10:38:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id r203sm9671460ywb.27.2015.07.03.10.38.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Jul 2015 10:38:19 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 3 Jul 2015 13:34:44 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> In-Reply-To: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507031334.45268.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 17:38:22 -0000 On Friday, July 03, 2015 01:23:19 pm Hubert Kario wrote: > I've noticed that the default values in case the client didn't use signature > algorithms extensions is to use SHA1+RSA, SHA1+DSA and SHA1+ECDSA. > > As we all know, those are not considered secure now. > > Maybe we should update it to SHA256 for all three? No point; usage of the extension is probably going to be mandatory. If so, we can just remove the defaults bit. Dave From nobody Fri Jul 3 10:43:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5781A21C2 for ; Fri, 3 Jul 2015 10:43:17 -0700 (PDT) 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 mCxzZdiQw3wz for ; Fri, 3 Jul 2015 10:43:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339F81A21A3 for ; Fri, 3 Jul 2015 10:43:15 -0700 (PDT) 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 (Postfix) with ESMTPS id 00987BBF53; Fri, 3 Jul 2015 17:43:14 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-81.ams2.redhat.com [10.36.112.81]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t63HhAxv004665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2015 13:43:14 -0400 From: Hubert Kario To: Dave Garrett Date: Fri, 03 Jul 2015 19:43:08 +0200 Message-ID: <1464952.uPJxibJBm7@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <201507031334.45268.davemgarrett@gmail.com> References: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> <201507031334.45268.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart21445056.p8k5zfcOTi"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 17:43:18 -0000 --nextPart21445056.p8k5zfcOTi Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 03 July 2015 13:34:44 Dave Garrett wrote: > On Friday, July 03, 2015 01:23:19 pm Hubert Kario wrote: > > I've noticed that the default values in case the client didn't use > > signature algorithms extensions is to use SHA1+RSA, SHA1+DSA and > > SHA1+ECDSA. > >=20 > > As we all know, those are not considered secure now. > >=20 > > Maybe we should update it to SHA256 for all three? >=20 > No point; usage of the extension is probably going to be mandatory. I= f so, > we can just remove the defaults bit. It will be better to have it updated and then removed than not updated,= =20 forgotten and published, don't you think? =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart21445056.p8k5zfcOTi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVlsmsAAoJEJKo0bgB0vX1aIUP/2chdyRUI7pY4EQl0s++FPzc hFNGkCe6dZhhRMPJPiJGyTJmxZb0RWi/sglks0Xtz7KeT0Re1zPLIux6fOOdnajQ Xumpc7hoLV3jztfqE5vo0EpQevi1WPfXAxO2CnooJYkw24Cwuo4BKHpb2nMZIdo+ 87sxcCA/ZOd1n0NWuiSSlog4wSFrHlBEBxIAwdohwGUhMu33w1ImHiA9udKkVguv BVcCy0kI7lsEqM9uIAlvNQdDvH7TY3WvfbQE3k3oTkNZwZ2ha3WrGKUOgKDqVnMt WK4/6qt7sU5Rspx4RwuD9FBxOHc+xvoJZqP0MjJHb/On+/xREWq8wsDOaasaAdYo x4Q1ca3LeTehcxjHnnSBx0b6ZSwMpIXJO04cO9iXaCKvx7bvmjLuqg/DiYp9HItF PylkB8xF5ERRTVcDWSpHKcHpNAgfzrM9odU7XzIzIDdUh6IkQe7l1LDmpncZj5oN nqY28FlOAPtctu/QsNv4u0jde6Hl1o3NKAzR5DsmDJ/6P1gO5MHCqa2yVU9EhCAA ZeMGHH6o42TNb3tf7pEaBJ9QHCN4N31ZApKFXaFiFIPr5mC122czCS5g8Z6bW7rv eCL1TcPA4lW3tm1/Ayyhh5FhQMvZOIB/gKj8M+KETHhyg2hO1yjBDP+i4wkV1yfQ mWr/7czcZIz6Syg9LSW8 =Bu1F -----END PGP SIGNATURE----- --nextPart21445056.p8k5zfcOTi-- From nobody Fri Jul 3 10:54:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0693B1A7004 for ; Fri, 3 Jul 2015 10:53:59 -0700 (PDT) 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 eJwVMa-lCq4Y for ; Fri, 3 Jul 2015 10:53:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DDB1A7003 for ; Fri, 3 Jul 2015 10:53:57 -0700 (PDT) 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 (Postfix) with ESMTPS id 804CEC7855; Fri, 3 Jul 2015 17:53:57 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-81.ams2.redhat.com [10.36.112.81]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t63HrrxT016404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2015 13:53:56 -0400 From: Hubert Kario To: Eric Rescorla Date: Fri, 03 Jul 2015 19:53:45 +0200 Message-ID: <2070265.aJZlsBJAF8@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2010179.0ehfq59J8k"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 17:53:59 -0000 --nextPart2010179.0ehfq59J8k Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 03 July 2015 10:34:41 Eric Rescorla wrote: > On Fri, Jul 3, 2015 at 10:23 AM, Hubert Kario wro= te: > > On Tuesday 30 June 2015 15:23:18 Eric Rescorla wrote: > > > Folks, > > >=20 > > > Yesterday, I posted the -06 draft which snapshots the consensus c= hanges > > > made since -05, specifically: > > >=20 > > > - Prohibit RC4 negotiation for backwards compatibility. > > > - Freeze & deprecate record layer version field. > > > - Update format of signatures with context. > > > - Remove explicit IV. > >=20 > > I've noticed that the default values in case the client didn't use > > signature > > algorithms extensions is to use SHA1+RSA, SHA1+DSA and SHA1+ECDSA. > >=20 > > As we all know, those are not considered secure now. > >=20 > > Maybe we should update it to SHA256 for all three? >=20 > I would welcome a PR for that. Done: https://github.com/ekr/tls13-spec/pull/12 =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2010179.0ehfq59J8k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVlswuAAoJEJKo0bgB0vX1LGcP/iB02HXUJUWjaP91fQrToDub xeFHvAPnbiEkrOY1w1h2qv3rOynuGi1LW2QjL8nRqbTV5WsTVt5W2PE5PGEwdpDw wiLwehJ1xpB+5Ovp2LUJ44HACBFZ9GPHyytzozpa+dl5qY3YFsX2ppQVpdiWhr82 36LnGP8zp+mleiqITQk0qStdj2mDX5UoN0fnWMgRgCkLpr29gd72FR4umFhswtpp 8vCiM9yhRxeerXvhaU3PdpdimWcoNzlwYk9/ntjWhRfp46g9TOs8D4Ru35KgY8qb RnmcnO9LBvnumN0YVQEBQkdtMREnUx+Pcziiuf8Z7RoxerU0WUeg5oIOd2nZ8DvI nVXOCmrlLh1Ainx/6Mu6mGrxgWsGH3PFIxMyIcOuh7koQjKBgoet6Q6GMhSGNlUn XlrVjh9NEMZkBDxLXsqw8412byQqVeoURf6d6CsniO8Artc5Xu8X+RW8fjGBm+e+ KInUiFbMMPpUPBCj2swIFbSjVcrt17vufdRZSXzjtyYY6RpLOZxm6xj1EBnqbaM0 l8hUk4XTkPi4iL6eO6Retvq55NzbukZH7TzqqvzcYiM/BfA9JBk6cAEtnE7tq8fQ P73+6nCMWG9+tvY0Sy3Wt8zS8z9hd4wZrydUC/uEnq/Y7FtElyCZhxAwxsaIWHZy bplQXupymicNTDAgtrZE =y5Y4 -----END PGP SIGNATURE----- --nextPart2010179.0ehfq59J8k-- From nobody Fri Jul 3 12:16:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5041A6EFC for ; Fri, 3 Jul 2015 12:16:13 -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 DJpP_To6OYuY for ; Fri, 3 Jul 2015 12:16:12 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18E71A6EF2 for ; Fri, 3 Jul 2015 12:16:12 -0700 (PDT) Received: by ykfy125 with SMTP id y125so102682953ykf.1 for ; Fri, 03 Jul 2015 12:16:12 -0700 (PDT) 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=pl8qIJDvzpBZ8lx4pkp3Wneep+/81euLMzu9ItJUOXY=; b=WlzYdwQ+dxFuX1JPiNuMNQ6it16wsjl87msD4OaOqLkH/XqW3jfTMTY/+F/8TzVffd nJwIvhjdqNTIOSeYUTg5IdjSbj3luesQdxCOtLvCNQJVZqVfWPHQEj1o8lTCFuz3/Mh0 Yd5B26r1Qd7575J61FaVAn66pTAwY6nRQ4nCldoYKXlnwpvK7D8RSvYQFOB6wQHsXFHt yioXjZp9d+9HVOqPt7Ocl2dNTviNMlHUGOwT+r2ChOmzK/KecwqEn49Ug+JfsSzCoDhp Ci1TFe88aeqSmUz61XfcACa4GQvwdnngBebPjpZ1Rjv+7vKqoPruBHRiLFnizIchml9S Cczw== X-Received: by 10.170.121.210 with SMTP id n201mr45639934ykb.97.1435950972054; Fri, 03 Jul 2015 12:16:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id w139sm9910316ywa.56.2015.07.03.12.16.11 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Jul 2015 12:16:11 -0700 (PDT) From: Dave Garrett To: Hubert Kario Date: Fri, 3 Jul 2015 15:16:10 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507031334.45268.davemgarrett@gmail.com> <1464952.uPJxibJBm7@pintsize.usersys.redhat.com> In-Reply-To: <1464952.uPJxibJBm7@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507031516.10530.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 19:16:14 -0000 On Friday, July 03, 2015 01:43:08 pm Hubert Kario wrote: > On Friday 03 July 2015 13:34:44 Dave Garrett wrote: > > On Friday, July 03, 2015 01:23:19 pm Hubert Kario wrote: > > > I've noticed that the default values in case the client didn't use > > > signature algorithms extensions is to use SHA1+RSA, SHA1+DSA and > > > SHA1+ECDSA. > > > > > > As we all know, those are not considered secure now. > > > > > > Maybe we should update it to SHA256 for all three? > > > > No point; usage of the extension is probably going to be mandatory. If so, > > we can just remove the defaults bit. > > It will be better to have it updated and then removed than not updated, > forgotten and published, don't you think? Sure, that's fine too. From nobody Fri Jul 3 13:48:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82941A87B3 for ; Fri, 3 Jul 2015 13:48:47 -0700 (PDT) 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 2RN6OneSywUC for ; Fri, 3 Jul 2015 13:48:45 -0700 (PDT) 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 DEAAE1A87AB for ; Fri, 3 Jul 2015 13:48:44 -0700 (PDT) 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 8835944BA2; Fri, 3 Jul 2015 22:48:42 +0200 (CEST) X-purgate-ID: 152705::1435956522-00005316-5AEB258B/0/0 X-purgate-size: 2740 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7806842748; Fri, 3 Jul 2015 22:48:42 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6ED111A1B3; Fri, 3 Jul 2015 22:48:42 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Fri, 3 Jul 2015 22:48:42 +0200 (CEST) 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: <20150703204842.6ED111A1B3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates 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, 03 Jul 2015 20:48:47 -0000 Andrei Popov wrote: > > I agree with Victor that there is no conflict. If the server chooses > to offer different certificates for different application protocols, > such server needs to consider the negotiated ALPN ID while making the > resumption decision. You're oversimplifying the problem. Recall the specifics of the design-flaw in rfc7301: Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered. and then look at the data that rfc5077 proposes to carry along in session_tickets -- there is *NO* pointer to the server certificate that was used to establish this session: https://tools.ietf.org/html/rfc5077#page-11 struct { ProtocolVersion protocol_version; CipherSuite cipher_suite; CompressionMethod compression_method; opaque master_secret[48]; ClientIdentity client_identity; uint32 timestamp; } StatePlaintext; enum { anonymous(0), certificate_based(1), psk(2) } ClientAuthenticationType; struct { ClientAuthenticationType client_authentication_type; select (ClientAuthenticationType) { case anonymous: struct {}; case certificate_based: ASN.1Cert certificate_list<0..2^24-1>; case psk: opaque psk_identity<0..2^16-1>; /* from [RFC4279] */ }; } ClientIdentity; So rfc7301 + rfc5077 + application-specific certificates is a pig that can not fly. Btw. there is also a problem for use of TLS extension SNI in combination with rfc5077 -- a server using rfc5077 as suggested will be unable to prevent "virtual host confusion" https://bh.ht.vc/vhost_confusion.pdf and will also be unable to properly implement the checks that rfc6066 specifies for ression resumption when TLS extension SNI is used. > > To me, these are implementation details, and probably not something a > mainstream implementation will support. Nope, these are design characteristics (or failures) of the spec. SSL session cache management and session resumption is an area that has been underspecified in SSL&TLS from the beginning, and the contents of rfc5077 suggests to me, that the amount of folks (and implementors) who understand the consequences for caching, when a server has more than one server certificate on his hands, might be rather small. -Martin From nobody Fri Jul 3 15:22:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3971B317A for ; Fri, 3 Jul 2015 15:22:23 -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 gxW769CZMXeO for ; Fri, 3 Jul 2015 15:22:22 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D301B3176 for ; Fri, 3 Jul 2015 15:22:22 -0700 (PDT) Received: by ykdv136 with SMTP id v136so105646921ykd.0 for ; Fri, 03 Jul 2015 15:22:21 -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=gwp9ImrlF+bi5tktpHhoTl2zqGqbIlLepXCfaRIDWkU=; b=hVvbgq4AI05ZUkZQVQ4OL6f0N0S7D5t1RF+84g4EDleOUjiYl36/A15jvS/ih3em8E AJEgf3cU/Q6WB544WOdiE1+1kPcyq2NQX6rzwofU7O9RaEkLMbChQQKyNOAEEXDmUseM enOZD04XYBbSX1+kZLI6KsEAXM6tM2zVNkGNDPsXKEomYfCEGbqVWXSF91UE9GU6AwvM mYXRqpKyseDxikR5J1ZyuP8hm1pt4oY7UMG1Yye2BCYfE4vJmpqWZr8mITBZWZ3mKPkp 72myCP4H62eRR+0sOfJCf8KECnUvPK3dMyIq+O9Lrg3tLIQmEhZjC9oiWWTbVrmOPcZM dLtw== MIME-Version: 1.0 X-Received: by 10.129.93.136 with SMTP id r130mr47891639ywb.52.1435962141807; Fri, 03 Jul 2015 15:22:21 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 3 Jul 2015 15:22:21 -0700 (PDT) In-Reply-To: <2070265.aJZlsBJAF8@pintsize.usersys.redhat.com> References: <4069375.XY312j7rEL@pintsize.usersys.redhat.com> <2070265.aJZlsBJAF8@pintsize.usersys.redhat.com> Date: Fri, 3 Jul 2015 15:22:21 -0700 Message-ID: From: Martin Thomson To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 22:22:24 -0000 On 3 July 2015 at 10:53, Hubert Kario wrote: > https://github.com/ekr/tls13-spec/pull/12 [Make {sha256, xxx} the default signature algorithm extension value when the extension is absent] There is a problem with this, and I think that you need to highlight that in the text. The reason that this doesn't work particularly well, though it probably isn't strictly problematic, is that now you have an extension that means one thing {sha1, rsa} when you negotiate TLS <= 1.2 and another thing {sha256, rsa} when you negotiate TLS 1.3. Maybe that's OK, but it narrows the utility of having a default. Please add the following (or similar): A TLS 1.3 client that is willing to do TLS <= 1.2 MUST include the extension unless it supports SHA-256 for TLS 1.3 and SHA-1 for TLS <= 1.2. From nobody Fri Jul 3 15:26:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1841B3182 for ; Fri, 3 Jul 2015 15:26:30 -0700 (PDT) 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_05=-0.5, 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 hg-O3U5OM-9U for ; Fri, 3 Jul 2015 15:26:30 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85EE1B3180 for ; Fri, 3 Jul 2015 15:26:29 -0700 (PDT) Received: by igrv9 with SMTP id v9so84237583igr.1 for ; Fri, 03 Jul 2015 15:26:29 -0700 (PDT) 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:content-transfer-encoding; bh=NVv7zhGXvEAjFKmhKcMk+/CGxIP5LkNGo87cT5NeX0g=; b=nDRHlBcJmub5Hwgxqc2iKD6VhluAuamsRx9hq9yaJxsnXUmWIpMtfePA68Bu4IJmiq utc9FRNSW+uSJpqmBE437MxGgVu2olSvs1qfBLVyISxdbuOe3FTpYp5wcu1xIsgfXGHF htABGtzpFyXzvWimZAt6pMhYlg8497BUmWuMbpmdvRqZJt7/WNstDNS9mQrImIRrj9Tb 8GfG3HQBpCcLshM89ZGyz9ZOoZ5hadUcH/VVQf2gWlX92sX2qpsD7sSNoNVmPNh9FfNo sSx/T0DFO5uxSdQccJqyOg1lSgimg4X3L51qmH7bMth0w/Ozvxqp6icA6nJWiHeVyQms 5jww== MIME-Version: 1.0 X-Received: by 10.107.25.15 with SMTP id 15mr58013646ioz.11.1435962389305; Fri, 03 Jul 2015 15:26:29 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Fri, 3 Jul 2015 15:26:29 -0700 (PDT) In-Reply-To: <12E32989-ADA3-4008-B943-76A0BAF962DA@qut.edu.au> References: <12E32989-ADA3-4008-B943-76A0BAF962DA@qut.edu.au> Date: Fri, 3 Jul 2015 18:26:29 -0400 Message-ID: From: Jeffrey Walton To: Douglas Stebila Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles 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: Fri, 03 Jul 2015 22:26:31 -0000 Hi Douglas, > My research group did some experimental work a few years ago involving cl= ient puzzles in TLS; some of the results might be of interest, though not a= ll: we focused on RSA key transport ciphersuites (rather than ECDHE) and a= lso considered a new signature algorithm for client authentication based on= a design of Bernstein. > Are you aware of any papers or results that callout puzzles as a successful remediation to DoS and DDoS? (Vanilla TCP and SSL/TLS would both be useful). Jeff From nobody Fri Jul 3 15:29:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348B11B3182 for ; Fri, 3 Jul 2015 15:29:43 -0700 (PDT) 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 aI2LRJ6A_Fn9 for ; Fri, 3 Jul 2015 15:29:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF961B3181 for ; Fri, 3 Jul 2015 15:29:41 -0700 (PDT) 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 (Postfix) with ESMTPS id 487812F14CD; Fri, 3 Jul 2015 22:29:41 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-81.ams2.redhat.com [10.36.112.81]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t63MTa8b007798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2015 18:29:40 -0400 From: Hubert Kario To: Martin Thomson Date: Sat, 04 Jul 2015 00:29:28 +0200 Message-ID: <2729812.2vdokAE54M@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <2070265.aJZlsBJAF8@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2588215.VKD3VQ4PDM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 22:29:43 -0000 --nextPart2588215.VKD3VQ4PDM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 03 July 2015 15:22:21 Martin Thomson wrote: > On 3 July 2015 at 10:53, Hubert Kario wrote: > > https://github.com/ekr/tls13-spec/pull/12 >=20 > [Make {sha256, xxx} the default signature algorithm extension value > when the extension is absent] >=20 > There is a problem with this, and I think that you need to highlight > that in the text. >=20 > The reason that this doesn't work particularly well, though it > probably isn't strictly problematic, is that now you have an extensio= n > that means one thing {sha1, rsa} when you negotiate TLS <=3D 1.2 and > another thing {sha256, rsa} when you negotiate TLS 1.3. Maybe that's= > OK, but it narrows the utility of having a default. >=20 > Please add the following (or similar): > A TLS 1.3 client that is willing to do TLS <=3D 1.2 MUST include the > extension unless it supports SHA-256 for TLS 1.3 and SHA-1 for TLS <=3D= > 1.2. Hmm, true, I'll fix it. And while we're at it, maybe a security recommendation stating that=20 advertising support for sha-1 and md-5 is not recommended? =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2588215.VKD3VQ4PDM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVlwzPAAoJEJKo0bgB0vX1TCsP/05xxY1OFILnoOq145uUiu/h 1aMqz/oWrJvAuPEfEtnRZ8mOxx+Dm8+oiI8fQkihqyoQ8cutPjTjeBqDNIHZ/n6n KHHM6X/Fqpjzy8yeKmdXvgFtgFeaB/nhbxpw85qlz4/pQi+kBmT8104qGCCHJYdR 0ROFhMfl4yxHx4qpS2Pisx9wnY1wrETAoVQW1V5R8fMNuPuJMVnku7uc7v79fy7k gsfz2GggdbWDH9UuQ0B2CRQi56+zwaH85f1DdA1L6cv4JD4md+1eO7HE2GL8mdMl XC2BEkTeHEF7vmA+hHrTMaXmVfFvNxQ4VcZIrpXKG8hWFAWyc+RMEtRbKUl0Rh4X adfPiRdDDjzo6VJmAtXLlbQo0YLfbqmdzIlTxa6mHVH4afoeEuQHIWQFLvw2Ddgd lW2SZwQqcAAEYsHMMSOSDOQavWH2IEzKr6LeB1udPoElyNhhRPyJtaT5zv3cza2N VQNjEUOQEEaBlkktPEzh6U5BmYs8Fap1fSZhkJiQM7zVNp2XjswCBM1pfEdbZqks E1rbT56A2cuMjLzo86b6uJoHjubYWLPIkm9tRZnHyAgqk7xJckoOKpYVZtG0r58f Pk5aXvGE7llio+eO+0L09L1SnDMCQVZd0/2coKGFyxjwDbbRxSveZUFN+Z++O4v3 z/tuNkbLkoXBVVdsgfHJ =7SUL -----END PGP SIGNATURE----- --nextPart2588215.VKD3VQ4PDM-- From nobody Fri Jul 3 16:07:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C7B1A902D for ; Fri, 3 Jul 2015 16:07:17 -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 jfjxSj8ypJPV for ; Fri, 3 Jul 2015 16:07:16 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6B01A9029 for ; Fri, 3 Jul 2015 16:07:16 -0700 (PDT) Received: by ykfs198 with SMTP id s198so1121399ykf.2 for ; Fri, 03 Jul 2015 16:07:15 -0700 (PDT) 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=q4kBqDfyjbzrhsdEfc+9tC44Lwibm2+N5e8gloyE+tQ=; b=PLvJE3IfMwxpFHRdpaISl/Q//7K1s/NJYNK0/JhOvGAGna4VEiIZdixzq11OVY83+l Dsq/rYNN91m/rHTNq4czYF80eO9C+xrSkDOwPQtoWx3X1ofcXr5Y2yWe5yTx/1FmPsnC JdWztDW+2iMebYBN8sKJIsAVvMFWZw06j6dvcmDieTUsB7MJ5QCEfaeNQQKJwZe6VZSe HM55GEE938FbdDBGiJkAZir4yF8TNKgFJtPrNeZ/C77f+9E32AIChJu8xq5Ny0zdGHXz HqkjehynFtYclI1PYkpZT66rwUUPJ9Qfp9WEANW9iq5/Sue4tUbaoN9zJQ5b5ONuKt4+ fCtg== X-Received: by 10.170.54.203 with SMTP id 194mr46843511ykw.42.1435964835642; Fri, 03 Jul 2015 16:07:15 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id h7sm10557456ywb.10.2015.07.03.16.07.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Jul 2015 16:07:15 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Hubert Kario Date: Fri, 3 Jul 2015 19:07:13 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <2729812.2vdokAE54M@pintsize.usersys.redhat.com> In-Reply-To: <2729812.2vdokAE54M@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507031907.13872.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 23:07:17 -0000 On Friday, July 03, 2015 06:29:28 pm Hubert Kario wrote: > And while we're at it, maybe a security recommendation stating that > advertising support for sha-1 and md-5 is not recommended? I'm already handling some of this topic over here: https://github.com/tlswg/tls13-spec/pull/188/files see also: https://github.com/tlswg/tls13-spec/issues/186 That deals with MD5 but I don't have anything for SHA1 being not recommended, yet. I was thinking that we should probably come up with a deprecation timeline to write in the spec that lines up with what vendors are already doing. That PR was just for completely removed capabilities, though. Eric said he'd have review of this PR on his todo list soon, so a new PR for the SHA1 stuff is probably best. I might work on writing up something for that next. Dave From nobody Fri Jul 3 16:13:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3911A904A for ; Fri, 3 Jul 2015 16:13:58 -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 5DNdX39lI5C0 for ; Fri, 3 Jul 2015 16:13:57 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9E31A9048 for ; Fri, 3 Jul 2015 16:13:56 -0700 (PDT) Received: by wgck11 with SMTP id k11so97910580wgc.0 for ; Fri, 03 Jul 2015 16:13:55 -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=rspZGIdImkMknGbFdKFYDE7bsGODJiY8Z2w9D28/tdw=; b=VerWTxLA3HeAgv0jSmESlj0N46yyipVO/bQhn/wYrLoAwf1yT0cbTZ0ZqQgcvSjtmQ BCBDOzdS+xCYnb3bAfx63vzAB9ZGBndDE0VVberV3y5uRrxicbUq1C7okwkMTTaF0/be cFPmcD2dpMRr+RNQD4liBkM2JBkRw2axz1EAtdKE6zYwoM56VNG2cI63xLt4MyQfRWVv LYgiNHj5BIrBC3iVtrVcA6bKMKlwCLWu8133c8WO7iQRORWD6o/SFqB+vNaCaRE+mvtJ Bb7iS7yHlQKs3pQlKso774G4Io8C2PMXmEk3xAdtYz0n19DVw3E5WRWQywp0ef7cqZmg zZtg== X-Gm-Message-State: ALoCoQnCiKdx2wezD9DbWFn9HBuL43GJgKT4UoIr0+eUHW6iJTmLBuPlNMIorrsgafX83C6ehOF/ X-Received: by 10.194.158.42 with SMTP id wr10mr70818993wjb.81.1435965235338; Fri, 03 Jul 2015 16:13:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Fri, 3 Jul 2015 16:13:15 -0700 (PDT) In-Reply-To: <201507031907.13872.davemgarrett@gmail.com> References: <2729812.2vdokAE54M@pintsize.usersys.redhat.com> <201507031907.13872.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 3 Jul 2015 16:13:15 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e013c6478c33473051a00b5f5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 23:13:58 -0000 --089e013c6478c33473051a00b5f5 Content-Type: text/plain; charset=UTF-8 I think we probably need to have WG consensus for the SHA-1 thing. Sean? -Ekr On Fri, Jul 3, 2015 at 4:07 PM, Dave Garrett wrote: > On Friday, July 03, 2015 06:29:28 pm Hubert Kario wrote: > > And while we're at it, maybe a security recommendation stating that > > advertising support for sha-1 and md-5 is not recommended? > > I'm already handling some of this topic over here: > https://github.com/tlswg/tls13-spec/pull/188/files > see also: > https://github.com/tlswg/tls13-spec/issues/186 > > That deals with MD5 but I don't have anything for SHA1 being not > recommended, yet. I was thinking that we should probably come up with a > deprecation timeline to write in the spec that lines up with what vendors > are already doing. That PR was just for completely removed capabilities, > though. Eric said he'd have review of this PR on his todo list soon, so a > new PR for the SHA1 stuff is probably best. I might work on writing up > something for that next. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e013c6478c33473051a00b5f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we probably need to have WG consensus for the SHA-= 1 thing.
Sean?

-Ekr




On Fri, Jul 3, 2015 at 4:07 PM, Dave Garrett <davemg= arrett@gmail.com> wrote:
On Friday, July 03, 2015 06:29:28 pm Hubert Kario wrote:
> And while we're at it, maybe a security recommendation stating tha= t
> advertising support for sha-1 and md-5 is not recommended?

I'm already handling some of this topic over here:
https://github.com/tlswg/tls13-spec/pull/188/files=
see also:
https://github.com/tlswg/tls13-spec/issues/186

That deals with MD5 but I don't have anything for SHA1 being not recomm= ended, yet. I was thinking that we should probably come up with a deprecati= on timeline to write in the spec that lines up with what vendors are alread= y doing. That PR was just for completely removed capabilities, though. Eric= said he'd have review of this PR on his todo list soon, so a new PR fo= r the SHA1 stuff is probably best. I might work on writing up something for= that next.


Dave

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

--089e013c6478c33473051a00b5f5-- From nobody Fri Jul 3 16:25:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3A61A9095 for ; Fri, 3 Jul 2015 16:25:08 -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 G2zdTtJipkhk for ; Fri, 3 Jul 2015 16:25:07 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D0A1A9059 for ; Fri, 3 Jul 2015 16:25:06 -0700 (PDT) Received: by ykfs198 with SMTP id s198so1344427ykf.2 for ; Fri, 03 Jul 2015 16:25:06 -0700 (PDT) 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=thBmqharPRYoTdl40S5PqWBiQR5hvhBslXw7IogXD6k=; b=mGQ52XGlMdErtsaZ2J+77OZE7pVN1MiV4JP7vQ021aGvdNo+fHOPnaEmZQsHAAGh48 zx/j/ZihFojGwX3S8ZIFbUXfjghOWfDeBJhQXCaPQ8JhjgK83Sz3aGWIk6HqAfRmvYsl ZE1dpnIBcVlOSBpMbU/bN5rf6v773VHMXnztQr6Bh5X89oML8mNIje/X8tL2kbp15pSC fatvzL0UUIXw6wrV3nriLDfCbQiKkI20BdATFEd/gyn+IqUnSfeyrS29VgwMQhg/PEcE z7OJjWXKIl/x5JCLLY85P/SLSlucKyxNP7aYq9xJBjscqa/i9Y69nKPwUdpZEui+xRGz Tw4A== X-Received: by 10.170.116.14 with SMTP id i14mr3084191ykb.3.1435965906180; Fri, 03 Jul 2015 16:25:06 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f2sm10611488ywf.5.2015.07.03.16.25.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Jul 2015 16:25:05 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Fri, 3 Jul 2015 19:25:04 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507031907.13872.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507031925.04809.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2015 23:25:08 -0000 On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote: > I think we probably need to have WG consensus for the SHA-1 thing. Yes, that's why I left it out of that changeset. I don't think the topic of what to do in the TLS 1.3 spec with SHA1 has been discussed on this list. (if it has, please point me to the thread if someone can) The simplest thing would be to have a MUST NOT offer or negotiate in 2017 or later and a NOT RECOMMENDED to use until then. Or, we could go deeper into the weeds and talk about expiration dates. Banning it totally for TLS 1.3+ is also an option, but probably not wanted yet. Regardless of the exact details, the signatures extension needs to be mandatory, so adding an MTI extensions section (as previously discussed) first is probably a good idea. As noted earlier in this thread, this would fix the issue of SHA1 as defaults. Dave From nobody Fri Jul 3 16:54:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4488F1A8862 for ; Fri, 3 Jul 2015 16:54:32 -0700 (PDT) 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 LyXwVd2DZFAu for ; Fri, 3 Jul 2015 16:54:30 -0700 (PDT) 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 E29851A066C for ; Fri, 3 Jul 2015 16:54:29 -0700 (PDT) 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 DDAF82B00E; Sat, 4 Jul 2015 01:54:27 +0200 (CEST) X-purgate-ID: 152705::1435967667-00005316-6E765BDA/0/0 X-purgate-size: 1091 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id CFB9A429CE; Sat, 4 Jul 2015 01:54:27 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C674B1A1B3; Sat, 4 Jul 2015 01:54:27 +0200 (CEST) In-Reply-To: <20150702164536.598b0430@pc1> To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Date: Sat, 4 Jul 2015 01:54:27 +0200 (CEST) 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: <20150703235427.C674B1A1B3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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, 03 Jul 2015 23:54:32 -0000 Hanno B=F6ck wrote: >=20 > We recently had discussions about DSA and RSA padding modi. The draft > still contains DSA and wants RSA in the old PKCS #1 1.5 padding > mode. >=20 > On RSA there was only limited discussion, but I had the impression > there is hardly an argument for not going with PSS You seem to believe that RSA-PSS is better than PKCS#1 v1.5 signature padding. Could you elaborate why you believe this to be? It was my impression that RSA-PSS adds complexity and slows down things and very close to nothing else -- unless you have direct low-level access to an RSA crypto hardware token and want to extract the RSA private key from it through the software interface. A significant amount of TLS usage scenarios do not use dedicated RSA crypto hardware, and those who don't, will have to pay for RSA-PSS, but not see any benefit. And even those that do have the RSA crypto hardware -- allowing PKCS#1 v1.5 access will be necessary as long as interop based on TLSv1.0 through TLSv1.2 is still necessary, which may be quite some time. -Martin From nobody Fri Jul 3 17:16:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721421A9144 for ; Fri, 3 Jul 2015 17:16:41 -0700 (PDT) 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 1us6BwmAyjBc for ; Fri, 3 Jul 2015 17:16:40 -0700 (PDT) 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 CE2571A9142 for ; Fri, 3 Jul 2015 17:16:39 -0700 (PDT) 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 8B4B844B21; Sat, 4 Jul 2015 02:16:38 +0200 (CEST) X-purgate-ID: 152705::1435968998-00000B48-234B9738/0/0 X-purgate-size: 1231 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7D6DE4283D; Sat, 4 Jul 2015 02:16:38 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 780371A1B3; Sat, 4 Jul 2015 02:16:38 +0200 (CEST) In-Reply-To: To: Martin Thomson Date: Sat, 4 Jul 2015 02:16:38 +0200 (CEST) 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: <20150704001638.780371A1B3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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, 04 Jul 2015 00:16:41 -0000 Martin Thomson wrote: > Hubert Kario wrote: > > There is a problem with this, and I think that you need to highlight > that in the text. > > The reason that this doesn't work particularly well, though it > probably isn't strictly problematic, is that now you have an extension > that means one thing {sha1, rsa} when you negotiate TLS <= 1.2 and The two weak RSA signature algorithms {md5,rsa} and {sha1,rsa} were security vulnerability that were deliberately ADDED to TLSv1.2. All prior protocol versions, including SSLv3, are using RSA signatures with a 278-bit hash (a concatenation of sha1+md5), which is a reasonable and conservative design. Given that this TLS-specific signature scheme had been used successfully for more than a decade when TLSv1.2 was specified, it is difficult to understand why this was deliberately weakened in TLSv1.2, rather than using the straight forward safe solution to define a codepoint for { sha1+md5, rsa } to identify the SSLv3->TLSv1.1 RSA signature transform for use in TLSv1.2 rather than newly adding and allowing the well-known weak signature schemes {md5,rsa} and {sha1,rsa} (and de-facto mandating support for the latter). -Martin From nobody Fri Jul 3 17:39:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8721ACDD5 for ; Fri, 3 Jul 2015 17:39:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, 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 RIhuhUVhBNkv for ; Fri, 3 Jul 2015 17:39:41 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7318F1ACE6B for ; Fri, 3 Jul 2015 17:38:41 -0700 (PDT) Received: by ykfs198 with SMTP id s198so2182791ykf.2 for ; Fri, 03 Jul 2015 17:38:40 -0700 (PDT) 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=3hKDJzldejcYyUQDWGdAxKT/atjrMbIUjfWrS/YiG9Y=; b=F9QfEdFMALqzGxC1ZfOPXfhAXg9fizyl4fjkdwFgSHmwERk5pBFPs8hrPcdpq2qUWb EXKxXDPraPGL56C6FmoO80hqJ/0/Su0z6YchsxBvRa5DvtJSL/gCgAmC4sQTjg2gWuKB 25b0XpuPrOiTlQHEI5CBBOj13waDlc0V0lYL5DMPgLvZcGTtr6YGwgwI9b3NC6iuOPlp bWO0PcHrEnLGQdIFynSb8vn9gc3Z34l5ZVwiDeqYi+/kOFDQz22ns7++LvOEu7fsfHhT XopOnZNEM6NzAkpD29HxrJABYgAo6ZyIoz5JYzBAePDXYzCAjVScsPyX+HmbSBEAmk+N jq9g== X-Received: by 10.13.197.3 with SMTP id h3mr46793655ywd.139.1435970320833; Fri, 03 Jul 2015 17:38:40 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b131sm10780755ywc.18.2015.07.03.17.38.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Jul 2015 17:38:40 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 3 Jul 2015 20:38:38 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150704001638.780371A1B3@ld9781.wdf.sap.corp> In-Reply-To: <20150704001638.780371A1B3@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507032038.39057.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2015 00:39:42 -0000 On Friday, July 03, 2015 08:16:38 pm Martin Rex wrote: > All prior protocol versions, including SSLv3, are using RSA signatures > with a 278-bit hash (a concatenation of sha1+md5), which is a reasonable > and conservative design. Given that this TLS-specific signature > scheme had been used successfully for more than a decade when TLSv1.2 > was specified, it is difficult to understand why this was deliberately > weakened in TLSv1.2, rather than using the straight forward safe > solution to define a codepoint for { sha1+md5, rsa } to identify > the SSLv3->TLSv1.1 RSA signature transform for use in TLSv1.2 > rather than newly adding and allowing the well-known weak signature > schemes {md5,rsa} and {sha1,rsa} (and de-facto mandating support > for the latter). Yeah, that was a weird choice. I'm curious; how much more secure can SHA1+MD5 be considered in comparison to SHA1? For that matter, how strong is it in comparison to SHA256? Its strength would theoretically be stronger than the sum of its parts, though I don't know by how much. I'm wondering if there's a study on this topic somewhere that someone might be able to point me to. Dave From nobody Fri Jul 3 17:58:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78231B31C4 for ; Fri, 3 Jul 2015 17:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_SUMOF=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 eg9JZNBwBgmJ for ; Fri, 3 Jul 2015 17:58:50 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5824F1B31BD for ; Fri, 3 Jul 2015 17:58:50 -0700 (PDT) Received: by oiyy130 with SMTP id y130so86905538oiy.0 for ; Fri, 03 Jul 2015 17:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VNV6QTdoC2lT4RC4dm6K8aTI6t1/QL0VTRBwbdrh6GI=; b=PyfgrFLr0IP3v36s4Fj5KW9XoM+YIk/51RVN5TFUi5QXgXJMM1D/RRSqQALxpmzG2g q5WoXWaYZI6HCGJXWlqrqPX4xZCMyeoMrOsv5OpBK5TrzUdzEl3ZHkqKWwmYP9EgXQxK bJTEpPE1Xj4UKNwGanTwnHlES99i/fyfbpdn/LW0TO00KPHfQdwPDGsfDdsEPVl1iyMh Unb0nNSQSqlYkGY194UW5Vhekd2Ckk6Of6P/H4Dg3WSnoGPpj3DcK1ucRkdLDOCoG8+3 PjGHHgRdeougeJSgKkI/5OiITahAvC8fqrolyZBNa+8oo1EWdVRPGbZt1kuC/dIBWkVB Gw2Q== X-Received: by 10.202.209.9 with SMTP id i9mr11264101oig.109.1435971529864; Fri, 03 Jul 2015 17:58:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.65.4 with HTTP; Fri, 3 Jul 2015 17:58:30 -0700 (PDT) In-Reply-To: <201507032038.39057.davemgarrett@gmail.com> References: <20150704001638.780371A1B3@ld9781.wdf.sap.corp> <201507032038.39057.davemgarrett@gmail.com> From: Quynh Dang Date: Fri, 3 Jul 2015 20:58:30 -0400 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113d3634f1fbe5051a022cea Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2015 00:58:51 -0000 --001a113d3634f1fbe5051a022cea Content-Type: text/plain; charset=UTF-8 The ineffectiveness issue of cascading hashes has been widely known for a long time ago. Find block X and block X' which have collided hash for SHA1 which takes around 2^70 operations or possibly less. Finding a block N for which X|| N and X' || N have collided hash for MD5 which is expected to have very low complexity (finding collision for MD5). Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 require about the same computational complexity. Quynh. On Fri, Jul 3, 2015 at 8:38 PM, Dave Garrett wrote: > On Friday, July 03, 2015 08:16:38 pm Martin Rex wrote: > > All prior protocol versions, including SSLv3, are using RSA signatures > > with a 278-bit hash (a concatenation of sha1+md5), which is a reasonable > > and conservative design. Given that this TLS-specific signature > > scheme had been used successfully for more than a decade when TLSv1.2 > > was specified, it is difficult to understand why this was deliberately > > weakened in TLSv1.2, rather than using the straight forward safe > > solution to define a codepoint for { sha1+md5, rsa } to identify > > the SSLv3->TLSv1.1 RSA signature transform for use in TLSv1.2 > > rather than newly adding and allowing the well-known weak signature > > schemes {md5,rsa} and {sha1,rsa} (and de-facto mandating support > > for the latter). > > Yeah, that was a weird choice. > > I'm curious; how much more secure can SHA1+MD5 be considered in comparison > to SHA1? For that matter, how strong is it in comparison to SHA256? Its > strength would theoretically be stronger than the sum of its parts, though > I don't know by how much. I'm wondering if there's a study on this topic > somewhere that someone might be able to point me to. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d3634f1fbe5051a022cea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The ineffectiveness issue of cascading hashes has been wid= ely known for a long time ago.

Find block X and block X&= #39; which have collided hash for SHA1 which takes around 2^70 operations o= r possibly less.=C2=A0

Finding a block N for which= X|| N and X' || N have collided hash for MD5 which is expected to have= very low complexity (finding collision for MD5).

= Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 requi= re about the same computational complexity.

Quynh.= =C2=A0

On Fri, Jul 3, 2015 at 8:38 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:
O= n Friday, July 03, 2015 08:16:38 pm Martin Rex wrote:
> All prior protocol versions, including SSLv3, are using RSA signatures=
> with a 278-bit hash (a concatenation of sha1+md5), which is a reasonab= le
> and conservative design.=C2=A0 Given that this TLS-specific signature<= br> > scheme had been used successfully for more than a decade when TLSv1.2<= br> > was specified, it is difficult to understand why this was deliberately=
> weakened in TLSv1.2, rather than using the straight forward safe
> solution to define a codepoint for { sha1+md5, rsa } to identify
> the SSLv3->TLSv1.1 RSA signature transform for use in TLSv1.2
> rather than newly adding and allowing the well-known weak signature > schemes {md5,rsa} and {sha1,rsa} (and de-facto mandating support
> for the latter).

Yeah, that was a weird choice.

I'm curious; how much more secure can SHA1+MD5 be considered in compari= son to SHA1? For that matter, how strong is it in comparison to SHA256? Its= strength would theoretically be stronger than the sum of its parts, though= I don't know by how much. I'm wondering if there's a study on = this topic somewhere that someone might be able to point me to.


Dave

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

--001a113d3634f1fbe5051a022cea-- From nobody Fri Jul 3 20:11:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB31B3344 for ; Fri, 3 Jul 2015 20:11:05 -0700 (PDT) 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 BpepcmuV-y9J for ; Fri, 3 Jul 2015 20:11:03 -0700 (PDT) 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 4BD031B3343 for ; Fri, 3 Jul 2015 20:11:03 -0700 (PDT) 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 A823E44A42; Sat, 4 Jul 2015 05:11:01 +0200 (CEST) X-purgate-ID: 152705::1435979461-00005316-A186442D/0/0 X-purgate-size: 1144 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 99F4C42A5A; Sat, 4 Jul 2015 05:11:01 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 90F6D1A1B3; Sat, 4 Jul 2015 05:11:01 +0200 (CEST) In-Reply-To: To: Quynh Dang Date: Sat, 4 Jul 2015 05:11:01 +0200 (CEST) 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: <20150704031101.90F6D1A1B3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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, 04 Jul 2015 03:11:05 -0000 Quynh Dang wrote: > > The ineffectiveness issue of cascading hashes has been widely known for a > long time ago. Are you thinking of research like this: http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf > > Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 > require about the same computational complexity. I'm not a cryptographer. I have just found the above paper with google and just skimmed over it, and it looks a little misleading to me. Collision attacks and preimage attacks are not the same. finding a practial collision attack will not give you an equivalent practical preimage attack for free. Practical collision attacks against MD5 have been demonstrated. Did I miss the publication of a practical MD5 preimage attack? The reason why I prefer the conservative design of the concatenated hashes is _not_ because their security adds up as if it were a single hash algorithm of the combined bitsize (because it doesn't), but because the attacks against individual algorithms will not add up as if it was a single algorithm (because it isn't). -Martin From nobody Fri Jul 3 20:42:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C39B1B2A85 for ; Fri, 3 Jul 2015 20:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_OFF=2.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 8TKhQQnquOPY for ; Fri, 3 Jul 2015 20:42:20 -0700 (PDT) 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 539951B3377 for ; Fri, 3 Jul 2015 20:42:20 -0700 (PDT) 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 7907B2AF28; Sat, 4 Jul 2015 05:42:18 +0200 (CEST) X-purgate-ID: 152705::1435981338-00000B48-29921638/0/0 X-purgate-size: 1567 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6A41F42A73; Sat, 4 Jul 2015 05:42:18 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 613C41A1B3; Sat, 4 Jul 2015 05:42:18 +0200 (CEST) In-Reply-To: To: Quynh Dang Date: Sat, 4 Jul 2015 05:42:18 +0200 (CEST) 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: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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, 04 Jul 2015 03:42:22 -0000 Quynh Dang wrote: > The ineffectiveness issue of cascading hashes has been widely known for a > long time ago. > > Find block X and block X' which have collided hash for SHA1 which takes > around 2^70 operations or possibly less. > > Finding a block N for which X|| N and X' || N have collided hash for MD5 > which is expected to have very low complexity (finding collision for MD5). > > Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 > require about the same computational complexity. The previously mentioned paper http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf describes the issue for two arbitrary hash algorithms F and G with bit sizes nF and nG and you say this applies to F= md5 nF=128 bit G= sha1 nG=160 bit and that the security of F||G would be no stronger than the larger of the two (G alone, nG=160). OK, lets take two other hash algorithms F and G, and even use a weaker algorithm F with nF=96 and G with nG=160. The assertion is, that he security of F||G would still be only 160. OK, here are my algorithms F and G: F= sha-256, truncated to bits 0..95 of the output G= sha-256, truncated to bits 96..256 of the output Now if your original assertion is true, then the strength of F(m)||G(m) which curiously happens to be identical to the output of sha256 for the message (m) has a security of only 160 bits? Or lets look at a concatenation of 8 hashes of 32-bits each. F=sha-256, truncated to bits 0..31 of the output ... -Martin From nobody Fri Jul 3 23:07:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E681A3B9F for ; Fri, 3 Jul 2015 23:07:36 -0700 (PDT) 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 zn54ydOS8fvK for ; Fri, 3 Jul 2015 23:07:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EF91A3B9D for ; Fri, 3 Jul 2015 23:07:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 04C19284D2B; Sat, 4 Jul 2015 06:07:34 +0000 (UTC) Date: Sat, 4 Jul 2015 06:07:33 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150704060733.GY21534@mournblade.imrryr.org> References: <20150703204842.6ED111A1B3@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150703204842.6ED111A1B3@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates 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: Sat, 04 Jul 2015 06:07:36 -0000 On Fri, Jul 03, 2015 at 10:48:42PM +0200, Martin Rex wrote: > So rfc7301 + rfc5077 + application-specific certificates is a pig > that can not fly. Well, firstly there is no requirement to structure session tickets exactly as indicated. They are encrypted, and the server can put anything it wants in them. Secondly, just like clients can implement "split" caches (use more cache lookup attributes than just the transport endpoint), so can servers. The server can add a context id into the session ticket, and only resume sessions that match that context id. > Btw. there is also a problem for use of TLS extension SNI > in combination with rfc5077 -- a server using rfc5077 as suggested will > be unable to prevent "virtual host confusion" > > https://bh.ht.vc/vhost_confusion.pdf > > and will also be unable to properly implement the checks that rfc6066 > specifies for ression resumption when TLS extension SNI is used. Since session ticket content is a private matter for the server, the standard does not preclude implementations that apply all the relevant checks. When I write code in this space, I tend to put more of the responsibility for avoiding virtual host confusion on the client. > Nope, these are design characteristics (or failures) of the spec. > SSL session cache management and session resumption is an area that > has been underspecified in SSL&TLS from the beginning, and the contents > of rfc5077 suggests to me, that the amount of folks (and implementors) > who understand the consequences for caching, when a server has more than > one server certificate on his hands, might be rather small. Documenting the care due in more detail sounds like a reasonable idea. -- Viktor. From nobody Sat Jul 4 05:30:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FDA1A8AB3 for ; Sat, 4 Jul 2015 05:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_OFF=2.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 1OsXM7ChvuSR for ; Sat, 4 Jul 2015 05:30:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C501A89F2 for ; Sat, 4 Jul 2015 05:30:38 -0700 (PDT) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB121.namprd09.prod.outlook.com (10.255.200.145) with Microsoft SMTP Server (TLS) id 15.1.207.19; Sat, 4 Jul 2015 12:30:19 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0207.004; Sat, 4 Jul 2015 12:30:19 +0000 From: "Dang, Quynh" To: "mrex@sap.com" , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek Thread-Index: AQHQs4OCiSVGDnhMFEq7N51zJUqqfJ3KAuGAgAADLYCAAAVUgIAASwuAgAAf7wCAAAYlAIAABY0AgAAtxACAAIyF0w== Date: Sat, 4 Jul 2015 12:30:19 +0000 Message-ID: References: , <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> In-Reply-To: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sap.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.219.222] x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:T6FlKp+FBACXSzLPgIKipmMqMBLnR7vsagEFtsOobq09+TKFNpFuxIuq87YeQfCF6jpJ/ME6nYKRXYD0f4uYPpQGaTt+p4Yp4jeROuSeHNO0GVbtFlsKlsATwIl1r0KWOwAVa4H6Vwc1unhtrSxUmg==; 24:h8zLnWzwwshyGTUuexRBOloY+1myrtPICCy1LWcpDVLlEs16FvXKvZPKTEollCT0YaOnb9m81jTc/0sxAUNeEat/+VAeorVsuG6cCaC2oQI=; 20:mzBgDDSLHynYs/NpmmnIo4mhZU0o3VTwiVGEZHNwe1awCOm0k5VX/D2OmyJSPvxou2a6myhmbrAnUPqGPPlpHg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121; x-forefront-prvs: 06274D1C43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(243025005)(51704005)(106116001)(19580395003)(86362001)(66066001)(2501003)(50986999)(76176999)(19627405001)(5001770100001)(92566002)(46102003)(19625215002)(33656002)(99286002)(2950100001)(76576001)(5003600100002)(2656002)(189998001)(19617315012)(122556002)(107886002)(19580405001)(40100003)(54356999)(5001960100002)(2900100001)(87936001)(5002640100001)(74316001)(77096005)(102836002)(77156002)(62966003)(16236675004)(15975445007)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124CE159C28C9B617BB2E07F3950BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2015 12:30:19.1971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121 Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2015 12:30:42 -0000 --_000_BN1PR09MB124CE159C28C9B617BB2E07F3950BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin, I talked about this issue at the interim meeting in Denver last year. A lot= of people there who were very good at crypto, but were not aware of this i= ssue. In another word, nobody knows all. So, being not aware of something = is common to everyone. Let me explain one of your examples and I hope that will help to make the i= ssue clear. "OK, here are my algorithms F and G: F=3D sha-256, truncated to bits 0..95 of the output G=3D sha-256, truncated to bits 96..256 of the output" It takes approximately 2^48 operations to find a block X and X' (X and X' c= an be any blocks) as long as their 96-bit hash values ( F) are the same. It takes approximately 2^80 operations to find a block N (N can be any bloc= k) so that 160-bit hash values (G) of X|| N and X'|| N are the same. So, the work required to find a collision for G is 2^80 and the work requi= red to find a collision for F || G is 2^48 + 2^80 and 2^48 is like nothing = when being compared to 2^80. Happy the 4th of July! Quynh. ________________________________________ From: TLS on behalf of Martin Rex Sent: Friday, July 3, 2015 11:42 PM To: Quynh Dang Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek Quynh Dang wrote: > The ineffectiveness issue of cascading hashes has been widely known for a > long time ago. > > Find block X and block X' which have collided hash for SHA1 which takes > around 2^70 operations or possibly less. > > Finding a block N for which X|| N and X' || N have collided hash for MD5 > which is expected to have very low complexity (finding collision for MD5)= . > > Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 > require about the same computational complexity. The previously mentioned paper http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf describes the issue for two arbitrary hash algorithms F and G with bit sizes nF and nG and you say this applies to F=3D md5 nF=3D128 bit G=3D sha1 nG=3D160 bit and that the security of F||G would be no stronger than the larger of the two (G alone, nG=3D160). OK, lets take two other hash algorithms F and G, and even use a weaker algorithm F with nF=3D96 and G with nG=3D160. The assertion is, that he security of F||G would still be only 160. OK, here are my algorithms F and G: F=3D sha-256, truncated to bits 0..95 of the output G=3D sha-256, truncated to bits 96..256 of the output Now if your original assertion is true, then the strength of F(m)||G(m) which curiously happens to be identical to the output of sha256 for the message (m) has a security of only 160 bits? Or lets look at a concatenation of 8 hashes of 32-bits each. F=3Dsha-256, truncated to bits 0..31 of the output ... -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_BN1PR09MB124CE159C28C9B617BB2E07F3950BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Martin,

I talked about this issue at the interim meeting in Denver last year. A lot= of people there who were very good at crypto, but were not aware of this i= ssue.  In another word, nobody knows all. So, being not aware of somet= hing is common to everyone.

Let me explain one of your examples and I hope that will help to make the i= ssue clear.

"OK, here are my algorithms F and G:

  F=3D sha-256, truncated to bits 0..95 of the output
  G=3D sha-256, truncated to bits 96..256 of the output"

It takes approximately 2^48 operations to find a block X and X' (X and X' c= an be any blocks) as long as their 96-bit hash values ( F) are the same.
It takes approximately 2^80 operations to find a block N (N can be any bloc= k) so that 160-bit hash values (G) of X|| N and X'|| N are the same.
So, the work required to find a collision for G is  2^80 and the work = required to find a collision for F || G is 2^48 + 2^80 and 2^48 is like= nothing when being compared to 2^80. 

Happy the 4th of July!

Quynh. 

________________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Martin Rex <mrex@sap= .com>
Sent: Friday, July 3, 2015 11:42 PM
To: Quynh Dang
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek

Quynh Dang wrote:
> The ineffectiveness issue of cascading hashes has been widely known fo= r a
> long time ago.
>
> Find block X and block X' which have collided hash for SHA1 which take= s
> around 2^70 operations or possibly less.
>
> Finding a block N for which X|| N and X' || N have collided hash for M= D5
> which is expected to have very low complexity (finding collision for M= D5).
>
> Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5<= br> > require about the same computational complexity.


The previously mentioned paper

http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/147= 2.pdf

describes the issue for two arbitrary hash algorithms F and G
with bit sizes nF and nG and you say this applies to

  F=3D md5  nF=3D128 bit
  G=3D sha1 nG=3D160 bit

  and that the security of F||G would be no stronger than the larger   of the two (G alone, nG=3D160).


OK, lets take two other hash algorithms F and G, and even use
a weaker algorithm F with nF=3D96 and G with nG=3D160.
The assertion is, that he security of F||G would still be only 160.

OK, here are my algorithms F and G:

  F=3D sha-256, truncated to bits 0..95 of the output
  G=3D sha-256, truncated to bits 96..256 of the output

Now if your original assertion is true, then the strength of
F(m)||G(m) which curiously happens to be identical to the output of
sha256 for the message (m) has a security of only 160 bits?

Or lets look at a concatenation of 8 hashes of 32-bits each.

F=3Dsha-256, truncated to bits 0..31 of the output
...



-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--_000_BN1PR09MB124CE159C28C9B617BB2E07F3950BN1PR09MB124namprd_-- From nobody Sat Jul 4 06:31:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8DF1ACD98 for ; Sat, 4 Jul 2015 06:31:18 -0700 (PDT) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_OFF=2.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 clZcXpx3CzeD for ; Sat, 4 Jul 2015 06:31:16 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8670C1ACD80 for ; Sat, 4 Jul 2015 06:31:16 -0700 (PDT) Received: by wiga1 with SMTP id a1so195973301wig.0 for ; Sat, 04 Jul 2015 06:31:15 -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=74EW1oP8jqJZgknXWc0EMnt3AK+jPI5DKqutp3bv1f4=; b=e7ARM+KDOHyXmItZtStAAz1kDy3JimI+q1YZUvy8q4e+v1E2SSU+b+n1LcVpVeDp9+ pVuBoyoRQJsnJYJQYsKCoajQGpva2j7d30Bj8sYwYuXYmXmIAzdQCKQToDFswGqOjzMD OOByZ16/Vkm0IokxNF3DNRjC0m4rf884f775S18LkFc+IakWSEhWr1oAoMVfrtQw4wfH wp/LvRo+Ist6QuFaf/MQ3keRZ05rLGUFzNR/eqsJ4d22WiX9PG8xCL4jNjDzOcJkX7Mm gG9Q5Ep3JecXkyN6E7m6snld3+GfZC2ZLBGpqFXRurQ8w8ni3LC9f+vVhXPTt9lfiw31 nMGg== MIME-Version: 1.0 X-Received: by 10.180.188.48 with SMTP id fx16mr36457596wic.35.1436016675310; Sat, 04 Jul 2015 06:31:15 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Sat, 4 Jul 2015 06:31:15 -0700 (PDT) In-Reply-To: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> References: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> Date: Sat, 4 Jul 2015 06:31:15 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2015 13:31:18 -0000 But these assertions below are not what the paper actually claims! It's important to actually read the paper, and see that the claims apply to hash functions of a particular form, namely iterated ones. The functions mentioned in your counterexample are not iterated hash functions in the sense of the paper. Nor, if you believe that the designers of TLS got ciphersuite negotiation correct, is the claimed "vulnerability" a vulnerability. If the security of the scheme used by A and B was the strongest in the intersection, having MD5 based schemes would be fine so long as everyone had SHA-256 based ones. But we know now that this result isn't true. (There is an added wrinkle, where a scheme based on a sufficiently weak hash function will break the negotiation) On Fri, Jul 3, 2015 at 8:42 PM, Martin Rex wrote: > Quynh Dang wrote: >> The ineffectiveness issue of cascading hashes has been widely known for a >> long time ago. >> >> Find block X and block X' which have collided hash for SHA1 which takes >> around 2^70 operations or possibly less. >> >> Finding a block N for which X|| N and X' || N have collided hash for MD5 >> which is expected to have very low complexity (finding collision for MD5). >> >> Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 >> require about the same computational complexity. > > > The previously mentioned paper > > http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf > > describes the issue for two arbitrary hash algorithms F and G > with bit sizes nF and nG and you say this applies to > > F= md5 nF=128 bit > G= sha1 nG=160 bit > > and that the security of F||G would be no stronger than the larger > of the two (G alone, nG=160). > > > OK, lets take two other hash algorithms F and G, and even use > a weaker algorithm F with nF=96 and G with nG=160. > The assertion is, that he security of F||G would still be only 160. > > OK, here are my algorithms F and G: > > F= sha-256, truncated to bits 0..95 of the output > G= sha-256, truncated to bits 96..256 of the output > > Now if your original assertion is true, then the strength of > F(m)||G(m) which curiously happens to be identical to the output of > sha256 for the message (m) has a security of only 160 bits? > > Or lets look at a concatenation of 8 hashes of 32-bits each. > > F=sha-256, truncated to bits 0..31 of the output > ... > > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Jul 4 11:34:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86631B2A3A for ; Sat, 4 Jul 2015 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_OFF=2.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 97n2WMDIULmy for ; Sat, 4 Jul 2015 11:34:42 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1D41B2A39 for ; Sat, 4 Jul 2015 11:34:41 -0700 (PDT) Received: by oiaf66 with SMTP id f66so63596006oia.3 for ; Sat, 04 Jul 2015 11:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sXJaWGQ+k5f19bypChH18b2Wy5WGoBvBU4ASdBCwDTw=; b=evZqVX2yVG6Cs4pNipweXsNnUwUTOpPZTVkPqnaA9uFKJHmuLewltE1LWgCtK+Ftvb /vdJR212Sgye23wqiV50MwYtlUn+HmMeTH9eq33BxOnvXpWMnvhnb+Q8+lL5JeNhLIAK 7yv26TMn1u93J69Bosr4oCQIhQTVF6bcMnEcPG6B0WSlQOmHdbFdubCMR4y9MJVab0L8 CGRC3ySRPiIp7uE4KZl6U+fXCGYsDr3VU2e3aW42tpK/WzOHWQEqo7Hli1+GpOMtfC8W 5iv1hS0HIci52wJ3YHZepkiYZgWT9GsU1BfoGwMpx+A2hxwwKDXNcjz5apjpJLzmRGhG Kynw== X-Received: by 10.60.82.97 with SMTP id h1mr40069130oey.71.1436034881369; Sat, 04 Jul 2015 11:34:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.65.4 with HTTP; Sat, 4 Jul 2015 11:34:21 -0700 (PDT) In-Reply-To: References: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> From: Quynh Dang Date: Sat, 4 Jul 2015 14:34:21 -0400 Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=047d7b6767c8fd3d36051a10ec97 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2015 18:34:43 -0000 --047d7b6767c8fd3d36051a10ec97 Content-Type: text/plain; charset=UTF-8 Hi Martin, Right. The attack does not work for truncated hashes (or wide-pipe hashes) where hash outputs are smaller than their internal chaining hash values. Quynh. On Sat, Jul 4, 2015 at 9:31 AM, Watson Ladd wrote: > But these assertions below are not what the paper actually claims! > It's important to actually read the paper, and see that the claims > apply to hash functions of a particular form, namely iterated ones. > The functions mentioned in your counterexample are not iterated hash > functions in the sense of the paper. > > Nor, if you believe that the designers of TLS got ciphersuite > negotiation correct, is the claimed "vulnerability" a vulnerability. > If the security of the scheme used by A and B was the strongest in the > intersection, having MD5 based schemes would be fine so long as > everyone had SHA-256 based ones. But we know now that this result > isn't true. (There is an added wrinkle, where a scheme based on a > sufficiently weak hash function will break the negotiation) > > On Fri, Jul 3, 2015 at 8:42 PM, Martin Rex wrote: > > Quynh Dang wrote: > >> The ineffectiveness issue of cascading hashes has been widely known for > a > >> long time ago. > >> > >> Find block X and block X' which have collided hash for SHA1 which takes > >> around 2^70 operations or possibly less. > >> > >> Finding a block N for which X|| N and X' || N have collided hash for MD5 > >> which is expected to have very low complexity (finding collision for > MD5). > >> > >> Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 > >> require about the same computational complexity. > > > > > > The previously mentioned paper > > > > http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf > > > > describes the issue for two arbitrary hash algorithms F and G > > with bit sizes nF and nG and you say this applies to > > > > F= md5 nF=128 bit > > G= sha1 nG=160 bit > > > > and that the security of F||G would be no stronger than the larger > > of the two (G alone, nG=160). > > > > > > OK, lets take two other hash algorithms F and G, and even use > > a weaker algorithm F with nF=96 and G with nG=160. > > The assertion is, that he security of F||G would still be only 160. > > > > OK, here are my algorithms F and G: > > > > F= sha-256, truncated to bits 0..95 of the output > > G= sha-256, truncated to bits 96..256 of the output > > > > Now if your original assertion is true, then the strength of > > F(m)||G(m) which curiously happens to be identical to the output of > > sha256 for the message (m) has a security of only 160 bits? > > > > Or lets look at a concatenation of 8 hashes of 32-bits each. > > > > F=sha-256, truncated to bits 0..31 of the output > > ... > > > > > > > > -Martin > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --047d7b6767c8fd3d36051a10ec97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Right. The attack does not w= ork for truncated hashes (or wide-pipe hashes) where hash outputs are small= er than their internal chaining hash values.

Quynh= .=C2=A0

On Sat, Jul 4, 2015 at 9:31 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
But these assertions= below are not what the paper actually claims!
It's important to actually read the paper, and see that the claims
apply to hash functions of a particular form, namely iterated ones.
The functions mentioned in your counterexample are not iterated hash
functions in the sense of the paper.

Nor, if you believe that the designers of TLS got ciphersuite
negotiation correct, is the claimed "vulnerability" a vulnerabili= ty.
If the security of the scheme used by A and B was the strongest in the
intersection, having MD5 based schemes would be fine so long as
everyone had SHA-256 based ones. But we know now that this result
isn't true. (There is an added wrinkle, where a scheme based on a
sufficiently weak hash function will break the negotiation)

On Fri, Jul 3, 2015 at 8:42 PM, Martin Rex <mrex@sap.com> wrote:
> Quynh Dang wrote:
>> The ineffectiveness issue of cascading hashes has been widely know= n for a
>> long time ago.
>>
>> Find block X and block X' which have collided hash for SHA1 wh= ich takes
>> around 2^70 operations or possibly less.
>>
>> Finding a block N for which X|| N and X' || N have collided ha= sh for MD5
>> which is expected to have very low complexity (finding collision f= or MD5).
>>
>> Therefore, finding collisions for SHA1 and collisions for SHA1 || = MD5
>> require about the same computational complexity.
>
>
> The previously mentioned paper
>
> http://www.iacr.org/cryptodb/arch= ive/2004/CRYPTO/1472/1472.pdf
>
> describes the issue for two arbitrary hash algorithms F and G
> with bit sizes nF and nG and you say this applies to
>
>=C2=A0 =C2=A0F=3D md5=C2=A0 nF=3D128 bit
>=C2=A0 =C2=A0G=3D sha1 nG=3D160 bit
>
>=C2=A0 =C2=A0and that the security of F||G would be no stronger than th= e larger
>=C2=A0 =C2=A0of the two (G alone, nG=3D160).
>
>
> OK, lets take two other hash algorithms F and G, and even use
> a weaker algorithm F with nF=3D96 and G with nG=3D160.
> The assertion is, that he security of F||G would still be only 160. >
> OK, here are my algorithms F and G:
>
>=C2=A0 =C2=A0F=3D sha-256, truncated to bits 0..95 of the output
>=C2=A0 =C2=A0G=3D sha-256, truncated to bits 96..256 of the output
>
> Now if your original assertion is true, then the strength of
> F(m)||G(m) which curiously happens to be identical to the output of > sha256 for the message (m) has a security of only 160 bits?
>
> Or lets look at a concatenation of 8 hashes of 32-bits each.
>
>=C2=A0 F=3Dsha-256, truncated to bits 0..31 of the output
>=C2=A0 ...
>
>
>
> -Martin
>
> __________________= _____________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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

--047d7b6767c8fd3d36051a10ec97-- From nobody Sat Jul 4 12:50:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4A61ACE6C for ; Sat, 4 Jul 2015 12:50:39 -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 W0vQh1JRzmxv for ; Sat, 4 Jul 2015 12:50:38 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EBC1ACE69 for ; Sat, 4 Jul 2015 12:50:37 -0700 (PDT) Received: by ykfs198 with SMTP id s198so14454618ykf.2 for ; Sat, 04 Jul 2015 12:50:37 -0700 (PDT) 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=AUKFkMVJdyqsckSlW4dh6+1NDTq61/hpAVodp5ULrk0=; b=JyOIWDMJTZXtOz5FNZcc7Q0prJ39dOqEzuCrDw6nw+QOsn/yUyqft7EvCenEw7Z0zG pR7ESFUDh3DCrNCBuYZiQXc3FRPGB0yjPNTuFBxC78ln6i1l7YmkAl45JLlnSyE79dtP uePAf1SWAOYyb4mzU7mJzWI4zyNXLJ1vMWlABRKdxBUy/IckDV72u4nG3pw7kdyZS9Ay sIwVDXs5dMYPPgLqMfnPDr+RBN+DbGCb3vQQPTRH7NUPKGESHh0dQB369cKPMR5I3CMv DpAgXXq1CaARD722xdXg+O8CDPWjy7c0GXXi7spjaBsdLsMw9OMNIr1pstdc+D3J5UY3 jUKQ== X-Received: by 10.170.49.197 with SMTP id 188mr36254736ykr.87.1436039437265; Sat, 04 Jul 2015 12:50:37 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id y5sm13447940ywc.11.2015.07.04.12.50.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 Jul 2015 12:50:36 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 4 Jul 2015 15:50:34 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507031334.45268.davemgarrett@gmail.com> <1464952.uPJxibJBm7@pintsize.usersys.redhat.com> In-Reply-To: <1464952.uPJxibJBm7@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507041550.35289.davemgarrett@gmail.com> Archived-At: Subject: [TLS] MTI Extensions (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2015 19:50:39 -0000 A draft for MTI extensions, as was initially discussed a while ago: https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions?diff=split This adds a "missing_extension" fatal alert to properly handle the error cases. I also copied the note against using the Truncated HMAC extension from the BCP (in the backwards compatibility section, as it's not applicable to TLS 1.3+). Dave From nobody Sat Jul 4 13:33:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7DC1ACD48 for ; Sat, 4 Jul 2015 06:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 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, MANGLED_OFF=2.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 oGQR548bzq85 for ; Sat, 4 Jul 2015 06:19:50 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6841ACD47 for ; Sat, 4 Jul 2015 06:19:49 -0700 (PDT) Received: by qkei195 with SMTP id i195so89055908qke.3 for ; Sat, 04 Jul 2015 06:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mKMtLnSnLplMfx3X95XswlKX1dnRrMuRFkPHN89Vxwc=; b=RqKLjPP84Sh7j45fD74iTIdYR3anfJdwCx9h5jYk9qDGvx+6D35SsPLVl47nvoKMp7 jCxejq3ZO5AyE/7pIZRVrXh58aVs7LtQhSxUSe2TOrn3QNm5OS+pYVzvhGbSI/GhqNbk MRpf7FkOGAxpwLRm42mIibBaMIhIXFLUGKLD0= 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=mKMtLnSnLplMfx3X95XswlKX1dnRrMuRFkPHN89Vxwc=; b=WnBe/mZsIz+igtmBYsGoxFu6ZpUDUm8WLyc9p9TJ3NNtdmyren7esrHndQ/gh3NPge aWGaMbs92QklY3CVe13/b19uWCe1zvqcP+W9vel1xZhJkPPme9tikiQXQIED+fKAV8og kv+7j2EJWeSAxlTUmpZI2NuZgmzn6Rtz9I2qAufXTuYu6aLN3UBlqGswdLqE9aCL15+V 9Stvu+qi74xp/EqH+POp9lP1n76W7jz6taP1CKHLA+iC3oGXaZUdFcPAkUnJBqWDCUmT jeNA9bg/RBkw7ejBhU85hiZpVVQ0yBgFcLCCVqS9gKXIPTELfyNf9SqZkbagidAMx7yi L23A== X-Gm-Message-State: ALoCoQkMcfQ9AyspHovodoJbDIQrQJzuKPQrA6IAeAMyIwmbHij53qHLxTBjrACZWJ63iMRa/mQc MIME-Version: 1.0 X-Received: by 10.140.150.198 with SMTP id 189mr61733246qhw.88.1436015989065; Sat, 04 Jul 2015 06:19:49 -0700 (PDT) Received: by 10.96.80.7 with HTTP; Sat, 4 Jul 2015 06:19:48 -0700 (PDT) In-Reply-To: References: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> Date: Sat, 4 Jul 2015 09:19:48 -0400 Message-ID: From: William Whyte To: "Dang, Quynh" Content-Type: multipart/alternative; boundary=001a113569e2eba3e1051a0c865b Archived-At: X-Mailman-Approved-At: Sat, 04 Jul 2015 13:33:41 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2015 13:19:52 -0000 --001a113569e2eba3e1051a0c865b Content-Type: text/plain; charset=UTF-8 So it seems this attack applies if the output size and the chaining value size are the same, but not if they're different. The assumption you're making is that if F(X) = F(X') then F(X|N) = F(X'|N) but that's not true if the output of F is truncated. William On Sat, Jul 4, 2015 at 8:30 AM, Dang, Quynh wrote: > > Hi Martin, > > I talked about this issue at the interim meeting in Denver last year. A > lot of people there who were very good at crypto, but were not aware of > this issue. In another word, nobody knows all. So, being not aware of > something is common to everyone. > > Let me explain one of your examples and I hope that will help to make the > issue clear. > > "OK, here are my algorithms F and G: > > F= sha-256, truncated to bits 0..95 of the output > G= sha-256, truncated to bits 96..256 of the output" > > It takes approximately 2^48 operations to find a block X and X' (X and X' > can be any blocks) as long as their 96-bit hash values ( F) are the same. > > It takes approximately 2^80 operations to find a block N (N can be any > block) so that 160-bit hash values (G) of X|| N and X'|| N are the same. > > So, the work required to find a collision for G is 2^80 and the work > required to find a collision for F || G is 2^48 + 2^80 and 2^48 is like > nothing when being compared to 2^80. > > Happy the 4th of July! > > Quynh. > > ________________________________________ > From: TLS on behalf of Martin Rex > Sent: Friday, July 3, 2015 11:42 PM > To: Quynh Dang > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek > > > Quynh Dang wrote: > > The ineffectiveness issue of cascading hashes has been widely known for a > > long time ago. > > > > Find block X and block X' which have collided hash for SHA1 which takes > > around 2^70 operations or possibly less. > > > > Finding a block N for which X|| N and X' || N have collided hash for MD5 > > which is expected to have very low complexity (finding collision for > MD5). > > > > Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 > > require about the same computational complexity. > > > The previously mentioned paper > > http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf > > describes the issue for two arbitrary hash algorithms F and G > with bit sizes nF and nG and you say this applies to > > F= md5 nF=128 bit > G= sha1 nG=160 bit > > and that the security of F||G would be no stronger than the larger > of the two (G alone, nG=160). > > > OK, lets take two other hash algorithms F and G, and even use > a weaker algorithm F with nF=96 and G with nG=160. > The assertion is, that he security of F||G would still be only 160. > > OK, here are my algorithms F and G: > > F= sha-256, truncated to bits 0..95 of the output > G= sha-256, truncated to bits 96..256 of the output > > Now if your original assertion is true, then the strength of > F(m)||G(m) which curiously happens to be identical to the output of > sha256 for the message (m) has a security of only 160 bits? > > Or lets look at a concatenation of 8 hashes of 32-bits each. > > F=sha-256, truncated to bits 0..31 of the output > ... > > > > -Martin > > _______________________________________________ > 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 > > --001a113569e2eba3e1051a0c865b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So it seems this attack applies if the output size and the= chaining value size are the same, but not if they're different. The as= sumption you're making is that if F(X) =3D F(X') then F(X|N) =3D F(= X'|N) but that's not true if the output of F is truncated.

=
William=C2=A0

On Sat, Jul 4, 2015 at 8:30 AM, Dang, Quynh <quynh.da= ng@nist.gov> wrote:

Hi Martin,

I talked about this issue at the interim meeting in Denver last year. A lot= of people there who were very good at crypto, but were not aware of this i= ssue.=C2=A0 In another word, nobody knows all. So, being not aware of somet= hing is common to everyone.

Let me explain one of your examples and I hope that will help to make the i= ssue clear.

"OK, here are my algorithms F and G:

=C2=A0 F=3D sha-256, truncated to bits 0..95 of the output
=C2=A0 G=3D sha-256, truncated to bits 96..256 of the output"

 It takes approximately 2^48 operations to find a block X and X' (X and = X' can be any blocks) as long as their 96-bit hash values ( F) are the = same.

It takes approximately 2^80 operations to find a block N (N can be any bloc= k) so that=C2=A0160-bit hash values (G) of X|| N and X'|| N are the sam= e.

So, the work required to find a collision for G is=C2=A0 2^80 and the work = required to find a collision for F || G is 2^48 + 2^80 and 2^48 is like not= hing when being compared to 2^80.=C2=A0

Happy the 4th of July!

Quynh.=C2=A0

________________________________________
From: TLS <tls= -bounces@ietf.org> on behalf of Martin Rex <mrex@sap.com>
Sent: Friday, July 3, 2015 11:42 PM
To: Quynh Dang
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek


Quynh Dang wrote:
> The ineffectiveness issue of cascading hashes has been widely known fo= r a
> long time ago.
>
> Find block X and block X' which have collided hash for SHA1 which = takes
> around 2^70 operations or possibly less.
>
> Finding a block N for which X|| N and X' || N have collided hash f= or MD5
> which is expected to have very low complexity (finding collision for M= D5).
>
> Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5<= br> > require about the same computational complexity.


The previously mentioned paper

http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/147= 2.pdf

describes the issue for two arbitrary hash algorithms F and G
with bit sizes nF and nG and you say this applies to

=C2=A0 F=3D md5=C2=A0 nF=3D128 bit
=C2=A0 G=3D sha1 nG=3D160 bit

=C2=A0 and that the security of F||G would be no stronger than the larger =C2=A0 of the two (G alone, nG=3D160).


OK, lets take two other hash algorithms F and G, and even use
a weaker algorithm F with nF=3D96 and G with nG=3D160.
The assertion is, that he security of F||G would still be only 160.

OK, here are my algorithms F and G:

=C2=A0 F=3D sha-256, truncated to bits 0..95 of the output
=C2=A0 G=3D sha-256, truncated to bits 96..256 of the output

Now if your original assertion is true, then the strength of
F(m)||G(m) which curiously happens to be identical to the output of
sha256 for the message (m) has a security of only 160 bits?

Or lets look at a concatenation of 8 hashes of 32-bits each.

F=3Dsha-256, truncated to bits 0..31 of the output
...



-Martin

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

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


--001a113569e2eba3e1051a0c865b-- From nobody Sun Jul 5 04:15:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024011A0396; Sun, 5 Jul 2015 04:15:01 -0700 (PDT) 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 kbhfAQlHeWEK; Sun, 5 Jul 2015 04:14:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B27101A0397; Sun, 5 Jul 2015 04:14:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150705111459.11121.58982.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 04:14:59 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-06.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: Sun, 05 Jul 2015 11:15:01 -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-06.txt Pages : 15 Date : 2015-07-05 Abstract: The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. 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: https://tools.ietf.org/html/draft-ietf-tls-session-hash-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-06 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 Sun Jul 5 05:15:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7B1A1B79 for ; Sun, 5 Jul 2015 05:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 Wa0t6h--YICb for ; Sun, 5 Jul 2015 05:15:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800D81A1B74 for ; Sun, 5 Jul 2015 05:15:06 -0700 (PDT) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.207.19; Sun, 5 Jul 2015 12:15:05 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0207.004; Sun, 5 Jul 2015 12:15:05 +0000 From: "Dang, Quynh" To: "wwhyte@securityinnovation.com" Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek Thread-Index: AQHQs4OCiSVGDnhMFEq7N51zJUqqfJ3KAuGAgAADLYCAAAVUgIAASwuAgAAf7wCAAAYlAIAABY0AgAAtxACAAKSNgIAAVK+AgAEi6YY= Date: Sun, 5 Jul 2015 12:15:04 +0000 Message-ID: References: <20150704034218.613C41A1B3@ld9781.wdf.sap.corp> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.222.71] x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:CGqwDbX7lgupVN9lwkH2lzh+H7VvDLdomZJsO0aBzUbqV5gjVZTHOk33VbHVKW7KipncJejHlxqjMF+x/5MyURTw6akCKSDtSCbdavvdD+f5EUfNtdI80Uxt5o2n78pWZ0Oa8yXlRBkmsOIdwzoC+Q==; 24:nkjCieeLrPrKBb0McAMPsDTgu2Tm2moHi6oLGDpW51h3DUQfDbqRHUz5DSWD9XjsMBZ9EBmJ88C2wUk7fD1qqdFlk8TVD4HjLlZCeh11cZo=; 20:GVWFPYXStH9OnPKNfxNYjLVDqdN0Tbj/VTilYR0HTj4K/13ZDTWhQN2EvgxeC3tv1xhkLQKy/hbzE3ghU3FYxQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 062899525A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(24454002)(243025005)(377454003)(106116001)(5003600100002)(77156002)(62966003)(19625215002)(33656002)(19580395003)(19580405001)(189998001)(99286002)(5002640100001)(76576001)(93886004)(5001960100002)(122556002)(2501003)(92566002)(40100003)(110136002)(2950100001)(66066001)(74316001)(5001920100001)(16236675004)(16297215004)(46102003)(2900100001)(19617315012)(86362001)(102836002)(15975445007)(50986999)(2656002)(2351001)(77096005)(19627405001)(87936001)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124F77BAC56087A41761F3DF3940BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 12:15:04.9459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2015 12:15:09 -0000 --_000_BN1PR09MB124F77BAC56087A41761F3DF3940BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In order for the attack to work, I will have to find a collision for the wh= ole output of the compression function of the first hash function. The attack works for MD5 || SHA1, SHA1 || SHA-256 etc...But, it does not wo= rk for the construction Martin described which provides the same security l= evel of SHA-256. Quynh. ________________________________ From: TLS on behalf of Quynh Dang Sent: Saturday, July 4, 2015 2:34 PM To: mrex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek Hi Martin, Right. The attack does not work for truncated hashes (or wide-pipe hashes) = where hash outputs are smaller than their internal chaining hash values. Quynh. On Sat, Jul 4, 2015 at 9:31 AM, Watson Ladd > wrote: But these assertions below are not what the paper actually claims! It's important to actually read the paper, and see that the claims apply to hash functions of a particular form, namely iterated ones. The functions mentioned in your counterexample are not iterated hash functions in the sense of the paper. Nor, if you believe that the designers of TLS got ciphersuite negotiation correct, is the claimed "vulnerability" a vulnerability. If the security of the scheme used by A and B was the strongest in the intersection, having MD5 based schemes would be fine so long as everyone had SHA-256 based ones. But we know now that this result isn't true. (There is an added wrinkle, where a scheme based on a sufficiently weak hash function will break the negotiation) On Fri, Jul 3, 2015 at 8:42 PM, Martin Rex > wrote: > Quynh Dang wrote: >> The ineffectiveness issue of cascading hashes has been widely known for = a >> long time ago. >> >> Find block X and block X' which have collided hash for SHA1 which takes >> around 2^70 operations or possibly less. >> >> Finding a block N for which X|| N and X' || N have collided hash for MD5 >> which is expected to have very low complexity (finding collision for MD5= ). >> >> Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5 >> require about the same computational complexity. > > > The previously mentioned paper > > http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf > > describes the issue for two arbitrary hash algorithms F and G > with bit sizes nF and nG and you say this applies to > > F=3D md5 nF=3D128 bit > G=3D sha1 nG=3D160 bit > > and that the security of F||G would be no stronger than the larger > of the two (G alone, nG=3D160). > > > OK, lets take two other hash algorithms F and G, and even use > a weaker algorithm F with nF=3D96 and G with nG=3D160. > The assertion is, that he security of F||G would still be only 160. > > OK, here are my algorithms F and G: > > F=3D sha-256, truncated to bits 0..95 of the output > G=3D sha-256, truncated to bits 96..256 of the output > > Now if your original assertion is true, then the strength of > F(m)||G(m) which curiously happens to be identical to the output of > sha256 for the message (m) has a security of only 160 bits? > > Or lets look at a concatenation of 8 hashes of 32-bits each. > > F=3Dsha-256, truncated to bits 0..31 of the output > ... > > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. --_000_BN1PR09MB124F77BAC56087A41761F3DF3940BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


In order for the attack to work, I will have to find a collision fo= r the whole output of the compression function of the first hash function.&= nbsp;


The attack works for MD5 || SHA1, SHA1 || SHA-256 etc...But, it doe= s not work for the construction Martin described which provides t= he same security level of SHA-256.


Quynh. 



From: TLS <tls-bounces@i= etf.org> on behalf of Quynh Dang <quynh97@gmail.com>
Sent: Saturday, July 4, 2015 2:34 PM
To: mrex@sap.com
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek
 
Hi Martin,

Right. The attack does not work for truncated hashes (or wide-pipe has= hes) where hash outputs are smaller than their internal chaining hash value= s.

Quynh. 

On Sat, Jul 4, 2015 at 9:31 AM, Watson Ladd <watsonbladd@= gmail.com> wrote:
But these assertions below are not what the paper actually claims!
It's important to actually read the paper, and see that the claims
apply to hash functions of a particular form, namely iterated ones.
The functions mentioned in your counterexample are not iterated hash
functions in the sense of the paper.

Nor, if you believe that the designers of TLS got ciphersuite
negotiation correct, is the claimed "vulnerability" a vulnerabili= ty.
If the security of the scheme used by A and B was the strongest in the
intersection, having MD5 based schemes would be fine so long as
everyone had SHA-256 based ones. But we know now that this result
isn't true. (There is an added wrinkle, where a scheme based on a
sufficiently weak hash function will break the negotiation)

On Fri, Jul 3, 2015 at 8:42 PM, Martin Rex <mrex@sap.com> wrote:
> Quynh Dang wrote:
>> The ineffectiveness issue of cascading hashes has been widely know= n for a
>> long time ago.
>>
>> Find block X and block X' which have collided hash for SHA1 which = takes
>> around 2^70 operations or possibly less.
>>
>> Finding a block N for which X|| N and X' || N have collided hash f= or MD5
>> which is expected to have very low complexity (finding collision f= or MD5).
>>
>> Therefore, finding collisions for SHA1 and collisions for SHA1 || = MD5
>> require about the same computational complexity.
>
>
> The previously mentioned paper
>
> http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf
>
> describes the issue for two arbitrary hash algorithms F and G
> with bit sizes nF and nG and you say this applies to
>
>   F=3D md5  nF=3D128 bit
>   G=3D sha1 nG=3D160 bit
>
>   and that the security of F||G would be no stronger than th= e larger
>   of the two (G alone, nG=3D160).
>
>
> OK, lets take two other hash algorithms F and G, and even use
> a weaker algorithm F with nF=3D96 and G with nG=3D160.
> The assertion is, that he security of F||G would still be only 160. >
> OK, here are my algorithms F and G:
>
>   F=3D sha-256, truncated to bits 0..95 of the output
>   G=3D sha-256, truncated to bits 96..256 of the output
>
> Now if your original assertion is true, then the strength of
> F(m)||G(m) which curiously happens to be identical to the output of > sha256 for the message (m) has a security of only 160 bits?
>
> Or lets look at a concatenation of 8 hashes of 32-bits each.
>
>  F=3Dsha-256, truncated to bits 0..31 of the output
>  ...
>
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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

--_000_BN1PR09MB124F77BAC56087A41761F3DF3940BN1PR09MB124namprd_-- From nobody Sun Jul 5 11:18:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54F1A907F for ; Sun, 5 Jul 2015 11:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.699 X-Spam-Level: ** X-Spam-Status: No, score=2.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 wJ92Gowr3rsy for ; Sun, 5 Jul 2015 11:18:40 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3886F1A907A for ; Sun, 5 Jul 2015 11:18:40 -0700 (PDT) Received: from pc1 (x4d0c3270.dyn.telefonica.de [::ffff:77.12.50.112]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Sun, 05 Jul 2015 20:18:37 +0200 id 0000000000000072.00000000559974FD.000037D7 Date: Sun, 5 Jul 2015 20:19:44 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: mrex@sap.com (Martin Rex) Message-ID: <20150705201944.5dfce8d5@pc1> In-Reply-To: <20150703235427.C674B1A1B3@ld9781.wdf.sap.corp> References: <20150702164536.598b0430@pc1> <20150703235427.C674B1A1B3@ld9781.wdf.sap.corp> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-14295-1436120317-0001-2" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2015 18:18:42 -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-14295-1436120317-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 4 Jul 2015 01:54:27 +0200 (CEST) mrex@sap.com (Martin Rex) wrote: > Hanno B=C3=B6ck wrote: > > On RSA there was only limited discussion, but I had the impression > > there is hardly an argument for not going with PSS >=20 > You seem to believe that RSA-PSS is better than PKCS#1 v1.5 signature > padding. Could you elaborate why you believe this to be? The most obvious reason is the Bleichenbacher signature forgery attack and related issues like BERserk. I can hardly think how anything similar could happen with PSS. BERserk especially highlights a new problem of the old PKCS: Having a complex encoding (ASN.1) directly inside a cryptographic function seems like a bad idea. I know that it is possible to implement PKCS #1 1.5 without these issues. But the past has shown that these mistakes happen. There's also the theoretic argument (it has a "security proof" with a certain definition of proof), but imho the practical implications - PSS is harder to get wrong - are more relevant. > It was my impression that RSA-PSS adds complexity and slows down > things The added complexity is limited. The performance probably is hardly measurable. It's a couple of added hash calculations. But if this is a real concern I can try to create some benchmarks. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-14295-1436120317-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVmXVAAAoJEKWIAHK7tR5C1L8P/jAk1L7JqthmmJJZpzkrRUTn itXIQTjAiY9CigREwxV/iqgE2dvZYgFgLTlJEshI6ePWGf2+v11HyOVsbEmD6pZ4 QSbO3tdaeKLLfVekgDuLCE2XJVrwKQWev4Sju25slPliDUV2jEF/69/dvDxjnUhw lhgXELdLPbFULuoJHzB6jqCbeFTja33xrc/gw7tro/ZFfKFhSyILUE8VFJXbVPvd 27ozZF2Mqm+QybMqDhsXKbFegIS4aoXQJDPhypDq+ZGLDnLv7FY8cJSh0rIrwgYv GZbeQxZ/JpnwHkgiJ3tq7k1fQCPhwt1rKf3oIyNtaaJPjDP5DjMnCe5psOJlBBR4 Czzlpt/aJ50VwjvaUc6f+odBA2kM5vTbEHXMQ9Sf9VQBmgSAGbRQUfH9lTXaDHH0 7AATLNgvSbetPNfZVGe5FD6ZDjs0ru+zTD/bEZVtxELOEXUiEK0YwL8ykZjc/Dw+ 1g8Kuy6xo6pauWyE9TUmXEHw62HNPl2tiHxdpHMdOwtLomTAQ+nLHOHTj+VLarVk Ux9/Hm8fi+HUfmd78uSlx/sgHprX5adwtzQvRqC0brOAXo2uQWn0oIjFfXva1izP +QL6pdHzKImoKkE5MF1mOd98IWmkRPbGYYd7hN4DqJqu9A9eVzVTJ14vzdBj7p9C Vl683LJ432Utw7Lx0ATq =dnYB -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-14295-1436120317-0001-2-- From nobody Sun Jul 5 20:06:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E77F1B2A46 for ; Sun, 5 Jul 2015 20:06:16 -0700 (PDT) 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_40=-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 FL2e7KfYHJxF for ; Sun, 5 Jul 2015 20:06:14 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1EE1B2A49 for ; Sun, 5 Jul 2015 20:06:14 -0700 (PDT) Received: by igau2 with SMTP id u2so1679913iga.0 for ; Sun, 05 Jul 2015 20:06:14 -0700 (PDT) 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=LAzOGrgN2HtjfscrD0cXGuL8/lisU/nI9eAqLAJ73xo=; b=X8kMmy0dvLp7W6q451HCFGJQlQwWmMN1gFLpaa9TGUImjfIe73ggAT2rjccMdZ34ET Q2e7RTJ7v6mtectLJrTN9771p443tpwH8vOa0c+RhUZhp5jEdKEEmk1CmLe1j74Et8zj Mpbj0RlrNFZ2T2yeMlI3eGx9S8c/lzN6OD2IfF/D94UYmut/zgUSfuGVAb0gReWy6tZf jGSx9bcDyo5V8MqVyQIDQ7+WqSF8LWvWxa9iuiLTl/E3t3bEzaIrkA6TKphVkG8D7+55 QjcQAJxN+eN1Z2p0/oBXXoEmOwzXJaqxzfhglFaVoo8N6TeXF1Qzvz+/z+D+k2zh1VAk RL3g== MIME-Version: 1.0 X-Received: by 10.43.33.142 with SMTP id so14mr30629757icb.36.1436151973945; Sun, 05 Jul 2015 20:06:13 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sun, 5 Jul 2015 20:06:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Jul 2015 23:06:13 -0400 Message-ID: From: Jeffrey Walton To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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: Mon, 06 Jul 2015 03:06:16 -0000 On Tue, Jun 30, 2015 at 6:23 PM, Eric Rescorla wrote: > Folks, > > Yesterday, I posted the -06 draft which snapshots the consensus changes > made since -05, specifically: > > - Prohibit RC4 negotiation for backwards compatibility. > - Freeze & deprecate record layer version field. > - Update format of signatures with context. > - Remove explicit IV. > I think the record layer parameters need to be cryptographically bound in the protocol. Without a binding, a bad guy can tamper with the initial stages of the exchange an make it appear another party is responsible for the failure. For example, a bad guy can make it appears a particular protocol version is unsupported by a server. At minimum, I believe it causes a hard failure in auditing. In Krawczyk's Cryptographic Extraction and Key Derivation: The HKDF Scheme (https://eprint.iacr.org/2010/264.pdf), here's what he says about contextual information like record layer versions (from page 2): the latter is an important parameter for the KDF intended to include key-related information that needs to be uniquely and cryptographically bound to the produced key material (e.g., a protocol identi er, identities of principals, timestamps, etc.). And going back to Wagner and Schneier's Analysis of the SSL 3.0 Protocol (https://www.schneier.com/paper-ssl-revised.pdf), omitting the record layer versions violates semantic authentication (from page ): ... call this the Horton principle" (with apologies to Dr. Seuss) of semantic authentication: roughly speaking "we want SSL to authenticate what was meant, not what was said." To phrase it another way, Eschew unauthenticated security-critical context I know the protocol wants to avoid a hard coupling of the record layer from the data it carries, but its a security parameter and it needs to be tended to. Jeff From nobody Mon Jul 6 02:31:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED731A92FC for ; Mon, 6 Jul 2015 02:31:39 -0700 (PDT) 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, 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 d3308123AXMa for ; Mon, 6 Jul 2015 02:31:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAC01A92F6 for ; Mon, 6 Jul 2015 02:31:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3802ABDD8; Mon, 6 Jul 2015 10:31:36 +0100 (IST) 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 rwkRCeqE4FgO; Mon, 6 Jul 2015 10:31:36 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16ECCBDD0; Mon, 6 Jul 2015 10:31:36 +0100 (IST) Message-ID: <559A4AF7.3000901@cs.tcd.ie> Date: Mon, 06 Jul 2015 10:31:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , tls@ietf.org References: <20150705111459.11121.58982.idtracker@ietfa.amsl.com> In-Reply-To: <20150705111459.11121.58982.idtracker@ietfa.amsl.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-session-hash-06.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: Mon, 06 Jul 2015 09:31:39 -0000 Hiya, I've checked the changes here resulting from IESG review and I think they're either editorial and fine or else they do reflect the recent list and IESG discussion. So I plan to send the approval announcement for this later today. Since the changes look biggish, it'd be good if someone else could check the diff [1] and agree that there were no bloopers introduced. Please don't re-litigate issues already discussed though, but keep to validating that the authors' correctly handled the recent list and IESG discussion. Thanks, S. [1] https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-session-hash-05&url2=draft-ietf-tls-session-hash-06 On 05/07/15 12:14, internet-drafts@ietf.org 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-06.txt > Pages : 15 > Date : 2015-07-05 > > Abstract: > The Transport Layer Security (TLS) master secret is not > cryptographically bound to important session parameters such as the > server certificate. 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: > https://tools.ietf.org/html/draft-ietf-tls-session-hash-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-06 > > > 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 > > From nobody Mon Jul 6 03:11:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE25B1AC42B for ; Mon, 6 Jul 2015 03:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Lo8upCxy-mQQ for ; Mon, 6 Jul 2015 03:11:52 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E751ACD25 for ; Mon, 6 Jul 2015 03:11:34 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-31-559a54545827 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.B0.32595.4545A955; Mon, 6 Jul 2015 12:11:33 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.44]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Mon, 6 Jul 2015 12:11:32 +0200 From: John Mattsson To: Ilari Liusvaara Thread-Topic: [TLS] New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-00.txt Thread-Index: AQHQsl1RaIdIeD7NqkOXxvBF5+RB0w== Date: Mon, 6 Jul 2015 10:11:32 +0000 Message-ID: References: <20150629111811.16517.15754.idtracker@ietfa.amsl.com> <20150629115708.GA22118@LK-Perkele-VII> In-Reply-To: <20150629115708.GA22118@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-ID: <1533C70562D38D40AEAA54893FF38DB1@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3Rjc0ZFaowdGjHBYr1+xhtvh0vovR gclj5dlajyVLfjIFMEVx2aSk5mSWpRbp2yVwZXR1vGcqaGCvuPFiBXsD4wu2LkZODgkBE4kP P/8yQ9hiEhfurQeKc3EICRxllJg99SU7hLOIUaLr1mWwDjYBA4m5exrAbBEBQ4lVe16C2cwC ihJ7tp1kB7GFBaIk/m/5zQJREy3xvOk9lK0ncfP1HbB6FgEVidaVrxhBbF4Be4lvh9axQiyb ySixqnkqWBEn0HmLL54EK2IEOu/7qTVMEMvEJW49mc8EcbaAxJI956FeEJV4+fgfK4StKNH+ tAGolwOoXlNi/S59iFZriW2vLzLD3Dyl+yE7xA2CEidnPmGZwCg+C8mGWQjds5B0z0LSPQtJ 9wJG1lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgdF2cMtv1R2Ml984HmIU4GBU4uF9sGJm qBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLp5vNhm2RH2 7l36pxmbOmcJzha5NT/ySqr639tSSdU1V98uuLErS+LJ0lUZjXf+X30Td+Zzyom7Er9b+y2/ qjfsfPP4p5vLGRkThXkVPs/rJSafWbz5chNDANfhAzOOv3z27ciC1wkpiQH3Mqct36oyiekw R+fG3ZwSfW+/xGhyP5VcmtP4uF5HiaU4I9FQi7moOBEAVmZjt5cCAAA= Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-00.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: Mon, 06 Jul 2015 10:11:54 -0000 VGhhbmtzLA0KDQpHb29kIGNvbW1lbnRzLCBJ4oCZbGwgbWFrZSB1cGRhdGUgd2l0aCB0aGVzZSB0 aGluZ3MgZml4ZWQuDQoNCkNoZWVycywNCkpvaG4NCg0KPiBPbiAyOSBKdW4gMjAxNSwgYXQgMTM6 NTcsIElsYXJpIExpdXN2YWFyYSA8aWxhcmkubGl1c3ZhYXJhQGVsaXNhbmV0LmZpPiB3cm90ZToN Cj4gDQo+IE9uIE1vbiwgSnVuIDI5LCAyMDE1IGF0IDExOjQ5OjQzQU0gKzAwMDAsIEpvaG4gTWF0 dHNzb24gd3JvdGU6IA0KPj4gT24gMjkvMDYvMTUgMTM6MTgsICJpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+Pj4gTmFtZToJCWRyYWZ0LW1hdHRz c29uLXRscy1lY2RoZS1wc2stYWVhZA0KPj4+IFJldmlzaW9uOgkwMA0KPj4gDQo+PiBDb21tZW50 cyBhcHByZWNpYXRlZC4NCj4gDQo+IDEpIFNlYXJjaGluZyBleGlzdGluZyBjaXBoZXJzdWl0ZXMs IEkgdGhpbmsgdGhlIG5hbWVzIHNob3VsZCBiZQ0KPiBUTFNfRUNESEVfUFNLX1dJVEhfKi4NCj4g DQo+IDIpIEFsc28sIG1pZ2h0IGNvbnNpZGVyIGNoYW5naW5nIDI1NiBiaXQgbWluaW11bSBFQ0Mg c2l6ZSB0byAyNTUsDQo+IHNpbmNlIGxvd2VyLXNlY3VyaXR5IENGUkcgY3VydmUgaXMgMjU1IGJp dHMuDQo+IA0KPiANCj4gLUlsYXJpDQoNCg== From nobody Mon Jul 6 04:48:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14A1ACC92; Mon, 6 Jul 2015 04:48:16 -0700 (PDT) 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 UnbGNmOQ-2GS; Mon, 6 Jul 2015 04:48:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B15361A0370; Mon, 6 Jul 2015 04:48:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 04:48:14 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-curve25519-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, 06 Jul 2015 11:48:16 -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 : Curve25519 and Curve448 for Transport Layer Security (TLS) Authors : Simon Josefsson Manuel Pegourie-Gonnard Filename : draft-ietf-tls-curve25519-01.txt Pages : 11 Date : 2015-07-06 Abstract: This document specifies the use of Curve25519 and Curve448 for ephemeral key exchange in the Transport Layer Security (TLS) and Datagram TLS (DTLS) protocols. It updates RFC 5246 (TLS 1.2) and RFC 4492 (Elliptic Curve Cryptography for TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-curve25519/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-curve25519-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-curve25519-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 Jul 6 05:08:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451E61ACE50 for ; Mon, 6 Jul 2015 05:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 gJpxRbnOka8T for ; Mon, 6 Jul 2015 05:08:00 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 107AA1ACE3D for ; Mon, 6 Jul 2015 05:07:59 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t66C7m4F004357 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 6 Jul 2015 14:07:49 +0200 X-Hashcash: 1:22:150706:tls@ietf.org::tDvYZ5asLWA8hpEb:CBC5 From: Simon Josefsson To: tls@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Mon, 06 Jul 2015 14:07:47 +0200 Message-ID: <87vbdxcwvg.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [TLS] Update draft on Curve25519/Curve448 in (D)TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2015 12:08:02 -0000 --=-=-= Content-Type: text/plain Hi all, Version -01 of draft-ietf-tls-curve25519 has been posted, please see: https://tools.ietf.org/html/draft-ietf-tls-curve25519-01 Changes include: - Added Curve448/Ed448-Goldilocks. - Dropped the new ECPointFormat value and use "uncompressed" instead. - Clarified the logic for ECDSA compatibility. The open issues that I am aware of, and would appreciate feedback/suggestions on, are: - Compatibility with signing algorithm selection. The text now says: Since Curve25519 and Curve448 are Diffie-Hellman functions, and not applicable as signatures algorithms, clients who offer ECDHE_ECDSA ciphersuites and advertise support for Curve25519/Curve448 in the elliptic_curves ClientHello extension SHOULD also advertise support for at least one curve suitable for ECDSA signatures. Servers MUST NOT select an ECDSA certificate if there are no common curves suitable for ECDSA signing. This wording should permit use of Ed25519 for signing (assuming it is treated as a ECDSA signature) once that is available, and NIST P-256 for ECDSA certs now. The wording is a bit complicated, and might say more than what we actually need to enforce at this point. For example, the last sentence ought to be covered by other specification text already, and doesn't appear to me to be a new requirement introduced by this document. Maybe we can find the reference and add it instead. The SHOULD is a bit wishy-washy, why isn't it a MUST? I am also not confident that this text is aligned with TLS 1.3. - Naming of Curve448 / Ed448-Goldilocks. Is Ed448-Goldilocks the name of the curve, and Curve448 the name of the Diffie-Hellman function based on the curve? Naming is not terribly clear from the CFRG draft nor the upstream Ed448-Goldilocks paper. The latter does not mention the word Curve448 at all but does talk about ECHDE. Alas, the situation with naming of Curve25519 is not a lot better. Perhaps the only thing we can aspire to is to avoid confusion as to which curve/function is referred to. I believe everyone understand what is meant by the terms Curve25519, Curve448 and Ed448-Goldilocks anyway. Perhaps getting everyone to agree on terminology naming is simply infeasible. - Is anything more required for TLS 1.3 compatibility/alignment? - Amount of crypto details (Appendix A). Ideally I would prefer if the CFRG draft contained all the crypto details, but not all of it has been carried over to that document. I don't know what the status is on the CFRG document, so I left the majority of the Curve25519 details in this document pending clarity. - Section 2.3 on public key validation. I would prefer if this went into the CFRG document too. The source code for this draft is maintained in this repository, and pull requests are welcome: https://gitlab.com/jas/ietf-tls-newcurves /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVmm+TAAoJEIYLf7sy+BGdNm8IAID+9TbT8KU++OPzV6+btpNp W8yGXnl+sI733IbCgMOZiRvC8U3+ywIqd0rjfRHA9IcERHq+FOtv2qArNKwOhJEe q4ETI2H+Tmj9uAWWAnq7A89BV+dnJAxEuqoZrZE72K/jIRMM83CTq/U2K0/fjjwA 4jB3xAQX3EM4a7yukEkO7g8E4EZaXiorpz7FOOXMwqj8ToodMyHyQeCDm0ipVPyA eu3gqVNQijp68xpRtE1HUU8CK8rgiyTztACFFOMi/BZhuPV+d908e3myDoDewX+1 HB4OVyzZY8d7/UJ7uYd6QwfzlvlToJqp+M7n5uX3UlMmJPENvJYfwapexWf8xnA= =LIKm -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 6 05:37:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629E41ACEA4 for ; Mon, 6 Jul 2015 05:37:16 -0700 (PDT) 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 SzH-GrtSlEKO for ; Mon, 6 Jul 2015 05:37:13 -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 1A15E1ACEC6 for ; Mon, 6 Jul 2015 05:37:07 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 68DB31887BC; Mon, 6 Jul 2015 15:37:05 +0300 (EEST) Date: Mon, 6 Jul 2015 15:37:05 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150706123705.GA8834@LK-Perkele-VII> References: <87vbdxcwvg.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87vbdxcwvg.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update draft on Curve25519/Curve448 in (D)TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2015 12:37:16 -0000 On Mon, Jul 06, 2015 at 02:07:47PM +0200, Simon Josefsson wrote: > Hi all, > > Version -01 of draft-ietf-tls-curve25519 has been posted, please see: > > https://tools.ietf.org/html/draft-ietf-tls-curve25519-01 > > Changes include: > > - Added Curve448/Ed448-Goldilocks. > > - Dropped the new ECPointFormat value and use "uncompressed" instead. > > - Clarified the logic for ECDSA compatibility. > > The open issues that I am aware of, and would appreciate > feedback/suggestions on, are: > > - Compatibility with signing algorithm selection. The text now says: > > Since Curve25519 and Curve448 are Diffie-Hellman functions, and not > applicable as signatures algorithms, clients who offer ECDHE_ECDSA > ciphersuites and advertise support for Curve25519/Curve448 in the > elliptic_curves ClientHello extension SHOULD also advertise support > for at least one curve suitable for ECDSA signatures. Servers MUST > NOT select an ECDSA certificate if there are no common curves > suitable for ECDSA signing. > > This wording should permit use of Ed25519 for signing (assuming it is > treated as a ECDSA signature) once that is available, and NIST P-256 > for ECDSA certs now. > > The wording is a bit complicated, and might say more than what we > actually need to enforce at this point. For example, the last > sentence ought to be covered by other specification text already, and > doesn't appear to me to be a new requirement introduced by this > document. Maybe we can find the reference and add it instead. The > SHOULD is a bit wishy-washy, why isn't it a MUST? > > I am also not confident that this text is aligned with TLS 1.3. Also, there's edge case even in TLS 1.2: It is possible to offer ECDSA without offering ECDHE_ECDSA ciphersuites (the same looks to be true in TLS 1.3). All the proposed modifications to signatures in TLS 1.3 don't change the nature of TLS 1.2 signature negotiation (perhaps just removes legacy cases). > - Naming of Curve448 / Ed448-Goldilocks. > > Is Ed448-Goldilocks the name of the curve, and Curve448 the name of > the Diffie-Hellman function based on the curve? I think that is correct (basepoint is different tho). > Perhaps the only thing we can aspire to is to avoid confusion as to > which curve/function is referred to. I believe everyone understand > what is meant by the terms Curve25519, Curve448 and Ed448-Goldilocks > anyway. Perhaps getting everyone to agree on terminology naming is > simply infeasible. AFAIK, Curve25519 and Curve448 are what the cfrg-curves draft calls the DHFs. Ed448-Goldilocks is an Edwards curve, very closely related to the Curve448[1]. > - Is anything more required for TLS 1.3 compatibility/alignment? I don't think so. > - Amount of crypto details (Appendix A). Ideally I would prefer if the > CFRG draft contained all the crypto details, but not all of it has > been carried over to that document. I don't know what the status is > on the CFRG document, so I left the majority of the Curve25519 details > in this document pending clarity. Note that the CFRG document has internal clamping in Curve25519/Curve448 (some scalar bits are cleared/set by the function itself). > - Section 2.3 on public key validation. I would prefer if this went > into the CFRG document too. IIRC, CFRG document specifies check for all-zero output. [1] The relation is so close that it is possible to very quickly transform points on Ed448-Goldilocks to Curve448, preserving scalar multiplication structure. From nobody Mon Jul 6 07:41:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A005C1ACECB; Mon, 6 Jul 2015 07:41:50 -0700 (PDT) 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 eAe80lQPGKZS; Mon, 6 Jul 2015 07:41:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2191ACF19; Mon, 6 Jul 2015 07:41:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706144149.27536.44209.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 07:41:49 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Mon, 06 Jul 2015 14:41:50 -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 : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Author : Yoav Nir Filename : draft-ietf-tls-rfc4492bis-03.txt Pages : 29 Date : 2015-07-06 Abstract: This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-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 Mon Jul 6 08:34:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2ADA1B2C55 for ; Mon, 6 Jul 2015 08:34:01 -0700 (PDT) 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 byzRbXD4xD-m for ; Mon, 6 Jul 2015 08:34:00 -0700 (PDT) Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com [IPv6:2607:f8b0:400c:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6ED1B2BCD for ; Mon, 6 Jul 2015 08:32:22 -0700 (PDT) Received: by vnbf1 with SMTP id f1so12550176vnb.10 for ; Mon, 06 Jul 2015 08:32:22 -0700 (PDT) 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=4FY3DMaQBrv+wHIa/yiO32DyiMIee88RrIslKjYL+X8=; b=xpiOM8+J9+RMTe+3bGMd8sw+qAtjFKoaIQWHB1XaZZAEFDnzxxnfmqy56V2P9u8Riw GwKEiDy8jchltqb0TrfIoWBxh/3HpLhTCIi9pe3wSl0jKQ7NidF2aezotjoRm6zfExde DF9+vxaAzjzWQ83sapeJT5DyQGFQWNP6c/q9MSP2OIXv5QC2nJwm0Ulkc71MEekSIW8m K0AngYaQbQTJ5myn+/OX4lB4p2iY0Ba1U3QXg/YDRA1i12+G6uVkJfaQZg3a7WF+5XEK wJT+Nn3IJmkyg42LqwvqUouy+5zb/yu9G5Wg1FtE/hZlmKpi/FSs9+M7SP1Wmgw9fk2w a6uw== MIME-Version: 1.0 X-Received: by 10.52.233.129 with SMTP id tw1mr50645214vdc.52.1436196742078; Mon, 06 Jul 2015 08:32:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Mon, 6 Jul 2015 08:32:22 -0700 (PDT) In-Reply-To: <559A4AF7.3000901@cs.tcd.ie> References: <20150705111459.11121.58982.idtracker@ietfa.amsl.com> <559A4AF7.3000901@cs.tcd.ie> Date: Mon, 6 Jul 2015 11:32:22 -0400 X-Google-Sender-Auth: PdKN8cMPr3deo6d9LEiwA9sqvC0 Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-session-hash-06.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: Mon, 06 Jul 2015 15:34:02 -0000 I took a quick look, and it looks OK to me. Barry On Mon, Jul 6, 2015 at 5:31 AM, Stephen Farrell wrote: > > Hiya, > > I've checked the changes here resulting from IESG review and I > think they're either editorial and fine or else they do reflect > the recent list and IESG discussion. > > So I plan to send the approval announcement for this later today. > Since the changes look biggish, it'd be good if someone else could > check the diff [1] and agree that there were no bloopers introduced. > > Please don't re-litigate issues already discussed though, but keep > to validating that the authors' correctly handled the recent list > and IESG discussion. > > Thanks, > S. > > [1] > https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-session-hash-05&url2=draft-ietf-tls-session-hash-06 > > > On 05/07/15 12:14, internet-drafts@ietf.org 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-06.txt >> Pages : 15 >> Date : 2015-07-05 >> >> Abstract: >> The Transport Layer Security (TLS) master secret is not >> cryptographically bound to important session parameters such as the >> server certificate. 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: >> https://tools.ietf.org/html/draft-ietf-tls-session-hash-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-06 >> >> >> 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 >> >> From nobody Mon Jul 6 14:12:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4C91A01F7; Mon, 6 Jul 2015 14:12:00 -0700 (PDT) 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 NvYl7D0PoFwu; Mon, 6 Jul 2015 14:11:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1210F1A0273; Mon, 6 Jul 2015 14:11:45 -0700 (PDT) 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: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706211145.20167.71595.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:11:45 -0700 Archived-At: Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension' to Proposed Standard (draft-ietf-tls-session-hash-06.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, 06 Jul 2015 21:12:00 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension' (draft-ietf-tls-session-hash-06.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ Technical Summary The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. 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. Working Group Summary This document has been reviewed by the WG on the mailing list and has been discussed at numerous TLS meetings (both regularly scheduled IETF meeting and TLS interims). Document Quality It not only reflects WG consensus it documents an implemented solution. Personnel Sean Turner is the document shepherd. Stephen Farrell is the irresponsible AD. From nobody Mon Jul 6 14:35:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF741A0015 for ; Mon, 6 Jul 2015 14:35:27 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 PKBwyNtBonSC for ; Mon, 6 Jul 2015 14:35:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD4A1A0052 for ; Mon, 6 Jul 2015 14:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1436218523; x=1467754523; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=H1BY5rFtWoXvYyI6TSdI500dtEcvZXApO2gpFFfyxVQ=; b=eYU9xEhPnYTVBfr/Q0UvRv9O6qklpVrUk5PlXDSWzK+bV0rA5U4Ubou/ 0kA0uXxaJy2QeYi5hOS39CHXWo5XlZTypDGRvxLmkZXofH/3AeccybBzm 3OIC0TIjmTeQW3uApQZVSDWetNC0nPtsVl/i9lPZTrEygmYs0sr3hlwsw ScwKdKpN/tLK6DxUuVjnv1k4GkUIYtui4uJkgucX8OROXzoF/6dE0I4Ad VCe/gr0OBooTQXudPXkXDkMYOMmuJU/wEUkwBX24uG0cLOtrSF5L+bLUu vWMXfPz1tjlV5jC/rgZ1KvZciOO5C8t/PsgFDHcNS4qtOqCzufg+FtzwF g==; X-IronPort-AV: E=Sophos;i="5.15,417,1432555200"; d="scan'208";a="27039388" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 Jul 2015 09:35:21 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 7 Jul 2015 09:35:21 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek Thread-Index: AdC4M6hgSA9oFjXrT9uVHyuEK4MFlA== Date: Mon, 6 Jul 2015 21:35:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB05834A@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: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2015 21:35:27 -0000 Martin Rex writes:=0A= =0A= >All prior protocol versions, including SSLv3, are using RSA signatures wit= h a=0A= >278-bit hash (a concatenation of sha1+md5), which is a reasonable and=0A= >conservative design. =0A= =0A= It's also a totally nonstandard design that's a perpetual headache to suppo= rt=0A= when you're dealing with crypto devices and other things. The move to a=0A= standard, widely-supported scheme should have been made ages ago, long befo= re=0A= TLS 1.2.=0A= =0A= Peter.=0A= From nobody Mon Jul 6 18:51:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133C11A00DD for ; Mon, 6 Jul 2015 18:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 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, 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 IMRrkc-w0VM7 for ; Mon, 6 Jul 2015 18:51:31 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6A61A00CA for ; Mon, 6 Jul 2015 18:51:31 -0700 (PDT) Received: by oihr66 with SMTP id r66so75375256oih.2 for ; Mon, 06 Jul 2015 18:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EKg/Dh3jsNZF3CsTiEpX5rIPqP1QBnFGd0YOAZyYFWE=; b=usTbByDGeaMQD8Nf7IU6ykeHJCxm3KKmawaJ6SUcb/zhwEhj+awMR0YLQhmIg0LZXj fHf/RbMT9sQh8mfO7GGkZUTB2gaukh7Md3CQy0kcK18aajZwZ31g0QebH7L1XMMTnAUH SoYSOv+ZfmLAYXVgMWfXpCbRb9MjqhMpBQ2J8VvspgGRJIf3nIuzJ2yqoBRCZm8KRGuR rI+wIvJf9EugN6CXcQmg3Tfsh88ck4rJGwsfgxSGp4ir4lhOITJji9vwgW7f5cTqdmWK +p2ZBXU+wJpIVERLmbf4v6Xr1ZZs/EyDOhbATAHYx+AjQpNN7GFOpjryLZ1oSt625LbS VDMA== X-Received: by 10.182.186.2 with SMTP id fg2mr1610690obc.35.1436233890973; Mon, 06 Jul 2015 18:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.113.142 with HTTP; Mon, 6 Jul 2015 18:51:11 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Mon, 6 Jul 2015 18:51:11 -0700 Message-ID: To: Erik Nygren Content-Type: multipart/alternative; boundary=089e0141a71ae2cd37051a3f4205 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 01:51:33 -0000 --089e0141a71ae2cd37051a3f4205 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 2, 2015 at 2:40 PM, Erik Nygren wrote: > Following a discussion last year in Denver, I've written up a proposal > for a TLS Client Puzzles extension. > I'm sorry, but I think this is the wrong approach. I assume you're trying to solve the asymmetrical computation requirements of RSA, a.k.a. the "THC DoS attack" If you're using RSA for key exchange, don't. It's very broken in more ways than DoS. If you're using RSA for signatures, it should be deprecated and phased out. Trying to solve the latter problem by complecting TLS is likewise something I oppose. Moving to ECC-based signatures (ECDSA or EdDSA or CFRG-yet-to-be-standardized-signatures) would obviate this problem without complecting the TLS protocol. ECC punts the computational burden to the client, elegantly solving this problem by using the algorithms we want to move to anyway. Complexity is the enemy of security. I prefer simplicity. To solve this same problem, I would prefer RSA diediedie. I know that's a stretch, but I would prefer TLS gravitate towards simple solutions than adding complex band-aids. -- Tony Arcieri --089e0141a71ae2cd37051a3f4205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 2, 2015 at 2:40 PM, Erik Nygren <erik+ietf@nygren.org> wrote:
F= ollowing a discussion last year in Denver, I've written up a proposal
for a TLS Client Puzzles extension.
I'm sorry, but I think this is the wrong approach.

I assume you're trying to solve the asymmetrical comp= utation requirements of RSA, a.k.a. the "THC DoS attack"

If you're using RSA for key exchange, don't. It= 9;s very broken in more ways than DoS.
If you're using RSA fo= r signatures, it should be deprecated and phased out.

<= div>Trying to solve the latter problem by complecting TLS is likewise somet= hing I oppose.

Moving to ECC-based signatures (ECD= SA or EdDSA or CFRG-yet-to-be-standardized-signatures) would obviate this p= roblem without complecting the TLS protocol. ECC punts the computational bu= rden to the client, elegantly solving this problem by using the algorithms = we want to move to anyway.

Complexity is the enemy= of security.

I prefer simplicity. To solve this s= ame problem, I would prefer RSA diediedie. I know that's a stretch, but= I would prefer TLS gravitate towards simple solutions than adding complex = band-aids.
=C2=A0
--
Tony Arcieri
--089e0141a71ae2cd37051a3f4205-- From nobody Mon Jul 6 19:39:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C610D1A8704 for ; Mon, 6 Jul 2015 19:39:47 -0700 (PDT) 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 qLKpty1AX_oM for ; Mon, 6 Jul 2015 19:39:46 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BABC1A870C for ; Mon, 6 Jul 2015 19:39:45 -0700 (PDT) Received: by ieqy10 with SMTP id y10so126153132ieq.0 for ; Mon, 06 Jul 2015 19:39:44 -0700 (PDT) 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=TfU6HQKrgnbeKzLnPFvlolOmz0eVVBbeQ7i0yPFJFHw=; b=1I6lDcXJ4fJ1mJp0tAdgeVtxWyHUCzerqrK6jM5xJWKs2EJuwusqFnSzlVyC96bHlo vjHarq9/EII9flWaJjFfG3QEPvewrY3Ac64pVw39iA63x/lAR0zjG/ZT1qIrQ1MipTca XzBZXcgtRht49odRIHNBwHgJrS93Quw1PBmmOgPYxwDWmFbKBbLyVIwnDoNAHS6kaqOn NVDSQFWbzbCfn18O3xPkU45pJXB9XhvBlCB4tHf27TecgQZ3Z0vmBLoXmd/HzrVIqjqi NTsUxDXcxUsfSMuIHIGL21sdlwdon7wEJUwUPaZBdvFPmlvV695+3DQBkLTuKe8CEcDl ByiQ== MIME-Version: 1.0 X-Received: by 10.42.157.200 with SMTP id e8mr39459325icx.84.1436236784508; Mon, 06 Jul 2015 19:39:44 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.79.104.193 with HTTP; Mon, 6 Jul 2015 19:39:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jul 2015 22:39:44 -0400 X-Google-Sender-Auth: dNU2elz6FDKdjVlzWFPLs57A1HQ Message-ID: From: Erik Nygren To: Tony Arcieri Content-Type: multipart/alternative; boundary=90e6ba2121335aa6ce051a3feff8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 02:39:47 -0000 --90e6ba2121335aa6ce051a3feff8 Content-Type: text/plain; charset=UTF-8 Sadly, even the ECDSA schemes and ECDHE key exchange still require the server to do significant work without the client needing to do any work. For example on a sample modern processor (per core): - RSA 2048 signs = 1,070 per second - ECDSA P-256 signs = 10,515 per second - ECDHE P-256 ops = 6,070 per second - SHA-256 of 64 byte blocks = 2,136,484 per second So even if you can ditch RSA signatures and do one ECDSA signature and one ECDHE op for key exchange, you're doing 3848 per core (so 3.8x over RSA which is a big boost, but not orders of magnitude of improvement). This helps a bunch, but there's no need for a client to do any work to get you to do that work. With a client puzzle and when under attack, you do some small number of SHA-256 ops and then the client will have to do some amount of work of your choosing. For example, giving the client ~500 SHA-256 rounds to do before you do an ECDSA signature will put the server at-parity with the client with respect to amount of crypto work. I'm all for simple solutions here, which is part of why anything here would ideally share as much in common with what's needed for DTLS cookies as well as use crypto routines already in-use in TLS as much as possible... Erik On Mon, Jul 6, 2015 at 9:51 PM, Tony Arcieri wrote: > On Thu, Jul 2, 2015 at 2:40 PM, Erik Nygren wrote: > >> Following a discussion last year in Denver, I've written up a proposal >> for a TLS Client Puzzles extension. >> > > I'm sorry, but I think this is the wrong approach. > > I assume you're trying to solve the asymmetrical computation requirements > of RSA, a.k.a. the "THC DoS attack" > > If you're using RSA for key exchange, don't. It's very broken in more ways > than DoS. > If you're using RSA for signatures, it should be deprecated and phased out. > > Trying to solve the latter problem by complecting TLS is likewise > something I oppose. > > Moving to ECC-based signatures (ECDSA or EdDSA or > CFRG-yet-to-be-standardized-signatures) would obviate this problem without > complecting the TLS protocol. ECC punts the computational burden to the > client, elegantly solving this problem by using the algorithms we want to > move to anyway. > > Complexity is the enemy of security. > > I prefer simplicity. To solve this same problem, I would prefer RSA > diediedie. I know that's a stretch, but I would prefer TLS gravitate > towards simple solutions than adding complex band-aids. > > -- > Tony Arcieri > --90e6ba2121335aa6ce051a3feff8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sadly, even the ECDSA schemes and ECDHE key= exchange still require the server
to do significant work without = the client needing to do any work.=C2=A0 For example on a
sam= ple modern processor (per core):

- RSA 2048 signs=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 1,070 per second
- ECDSA P= -256 signs =3D 10,515 per second
- ECDHE P-256 ops=C2=A0=C2= =A0=C2=A0 =3D 6,070 per second
- SHA-256 of 64 byte blocks = =3D 2,136,484 per second

So even if you can ditch RSA sig= natures and do one ECDSA signature
and one ECDHE op for key e= xchange, you're doing 3848 per core (so 3.8x over RSA
whi= ch is a big boost, but not orders of magnitude of improvement).
This helps a bunch, but there's no need for a client to do any work = to get
you to do that work.

With a client p= uzzle and when under attack, you do some small number of SHA-256 ops
and= then the client will have to do some amount of work of your choosing.
<= /div>
For example, giving the client ~500 SHA-256 rounds to do before y= ou do an ECDSA
signature will put the server at-parity with t= he client with respect to amount of crypto work.

I&= #39;m all for simple solutions here, which is part of why anything here wou= ld ideally
share as much in common with what's needed for= DTLS cookies as well as use
crypto routines already in-use i= n TLS as much as possible...

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik



On Mon, Jul 6, 2015 at 9:51 PM,= Tony Arcieri <bascule@gmail.com> wrote:
On Thu, Jul 2, 2015 at 2:40 PM, Erik Nygren <erik+ietf@nygren.org> wrote:
Following a discussi= on last year in Denver, I've written up a proposal
for a TLS C= lient Puzzles extension.

I'm sorry, but I think this is the wrong approach.

I assume you're trying to solve the asymmetrical computation requ= irements of RSA, a.k.a. the "THC DoS attack"

=
If you're using RSA for key exchange, don't. It's very bro= ken in more ways than DoS.
If you're using RSA for signatures= , it should be deprecated and phased out.

Trying t= o solve the latter problem by complecting TLS is likewise something I oppos= e.

Moving to ECC-based signatures (ECDSA or EdDSA = or CFRG-yet-to-be-standardized-signatures) would obviate this problem witho= ut complecting the TLS protocol. ECC punts the computational burden to the = client, elegantly solving this problem by using the algorithms we want to m= ove to anyway.

Complexity is the enemy of security= .

I prefer simplicity. To solve this same problem,= I would prefer RSA diediedie. I know that's a stretch, but I would pre= fer TLS gravitate towards simple solutions than adding complex band-aids.
=C2=A0
=
--
Ton= y Arcieri

--90e6ba2121335aa6ce051a3feff8-- From nobody Mon Jul 6 20:16:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408001A88F9 for ; Mon, 6 Jul 2015 20:16:07 -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 xPIAyqH8i6QA for ; Mon, 6 Jul 2015 20:16:05 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4904C1A87F2 for ; Mon, 6 Jul 2015 20:16:05 -0700 (PDT) Received: by wifm2 with SMTP id m2so46375676wif.1 for ; Mon, 06 Jul 2015 20:16:04 -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=sFhFqrRTyW5VnRGnDyM9ziUIrNHX02hxO0yoQtzk3S8=; b=RW4ddNhODkO0f6rmej/cqK5TO3dZtw4fTX7nnO6DHcjGDPVyiVTfSmLH9BN1RSSilr ZT5fVVNMNBiEOI7CpkbaoKwZVZ+t9gME6DBItx8FG1ljVgCcdGzPwBZnn8b0O8HSYYiZ 8tonDJRtNZkKCtakiXyu2wf6F9ljqj0yejAUI4SjrJwUUqBoU9pcye1N7iMJHHPX565a OwJNYeGK6v7UFAa52afZ3wVTz2yuZRkkq1OnwTlFPzwibfV9uZokKzYsl5rFh9U3fDWq BSISJxvKOf/PmxCVwEj1YxpNKiCnskvx2OeoXJY3QknS3oYrnd1biTu07F0Bw1iqVWNn hzEg== MIME-Version: 1.0 X-Received: by 10.180.92.162 with SMTP id cn2mr58194716wib.26.1436238963974; Mon, 06 Jul 2015 20:16:03 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Mon, 6 Jul 2015 20:16:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jul 2015 20:16:03 -0700 Message-ID: From: Watson Ladd To: Erik Nygren Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 03:16:07 -0000 On Mon, Jul 6, 2015 at 7:39 PM, Erik Nygren wrote: > Sadly, even the ECDSA schemes and ECDHE key exchange still require the > server > to do significant work without the client needing to do any work. For > example on a > sample modern processor (per core): > > - RSA 2048 signs = 1,070 per second > - ECDSA P-256 signs = 10,515 per second > - ECDHE P-256 ops = 6,070 per second > - SHA-256 of 64 byte blocks = 2,136,484 per second These numbers are far below what faster cryptography can deliver: I have nearly a million gls254 computations per second, and 50,000 key agreements per second on a kummer surface. Changing TLS to not require online signing would realize this degree of performance. At these rates you saturate gigabit ethernet connections, which puzzles will not help with. In fact, they will make the problem worse. > > So even if you can ditch RSA signatures and do one ECDSA signature > and one ECDHE op for key exchange, you're doing 3848 per core (so 3.8x over > RSA > which is a big boost, but not orders of magnitude of improvement). > This helps a bunch, but there's no need for a client to do any work to get > you to do that work. > > With a client puzzle and when under attack, you do some small number of > SHA-256 ops > and then the client will have to do some amount of work of your choosing. > For example, giving the client ~500 SHA-256 rounds to do before you do an > ECDSA > signature will put the server at-parity with the client with respect to > amount of crypto work. > > I'm all for simple solutions here, which is part of why anything here would > ideally > share as much in common with what's needed for DTLS cookies as well as use > crypto routines already in-use in TLS as much as possible... What about improving performance? That avoids any protocol changes, and brings about the benefits you seem to want. > > Erik > > > > On Mon, Jul 6, 2015 at 9:51 PM, Tony Arcieri wrote: >> >> On Thu, Jul 2, 2015 at 2:40 PM, Erik Nygren wrote: >>> >>> Following a discussion last year in Denver, I've written up a proposal >>> for a TLS Client Puzzles extension. >> >> >> I'm sorry, but I think this is the wrong approach. >> >> I assume you're trying to solve the asymmetrical computation requirements >> of RSA, a.k.a. the "THC DoS attack" >> >> If you're using RSA for key exchange, don't. It's very broken in more ways >> than DoS. >> If you're using RSA for signatures, it should be deprecated and phased >> out. >> >> Trying to solve the latter problem by complecting TLS is likewise >> something I oppose. >> >> Moving to ECC-based signatures (ECDSA or EdDSA or >> CFRG-yet-to-be-standardized-signatures) would obviate this problem without >> complecting the TLS protocol. ECC punts the computational burden to the >> client, elegantly solving this problem by using the algorithms we want to >> move to anyway. >> >> Complexity is the enemy of security. >> >> I prefer simplicity. To solve this same problem, I would prefer RSA >> diediedie. I know that's a stretch, but I would prefer TLS gravitate towards >> simple solutions than adding complex band-aids. >> >> -- >> Tony Arcieri > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Jul 7 05:42:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8533B1A017D for ; Tue, 7 Jul 2015 05:42:50 -0700 (PDT) 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 LNYvQIfXNhzz for ; Tue, 7 Jul 2015 05:42:48 -0700 (PDT) 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 A85E91A0178 for ; Tue, 7 Jul 2015 05:42:47 -0700 (PDT) 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 494474427B; Tue, 7 Jul 2015 14:42:45 +0200 (CEST) X-purgate-ID: 152705::1436272965-00005316-73DF0377/0/0 X-purgate-size: 2690 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3C16242654; Tue, 7 Jul 2015 14:42:45 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2F8A41A1C0; Tue, 7 Jul 2015 14:42:45 +0200 (CEST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB05834A@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann Date: Tue, 7 Jul 2015 14:42:45 +0200 (CEST) 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: <20150707124245.2F8A41A1C0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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, 07 Jul 2015 12:42:50 -0000 Peter Gutmann wrote: > Martin Rex writes: >> >> All prior protocol versions, including SSLv3, are using RSA signatures with a >> 278-bit hash (a concatenation of sha1+md5), which is a reasonable and >> conservative design. > > It's also a totally nonstandard design that's a perpetual headache to support > when you're dealing with crypto devices and other things. The move to a > standard, widely-supported scheme should have been made ages ago, long before > TLS 1.2. My gripe with TLSv1.2 is about *NEWLY* mandating support for two known weak signature schemes: md5WithRSAEncryption and sha1WithRSAEncryption, schemes that are substantially weaker than what earlier versions of TLS and even SSLv3 had been using. TLSv1.2 (rfc5246) was published in August 2008 PKCS#1 v2.1 (rfc3447, Feb 2003) had been published >5 years earlier. http://tools.ietf.org/html/rfc3447#appendix-A.2.4 already knows about these stronger RSA signature algorithms: SHA-256 sha256WithRSAEncryption ::= {pkcs-1 11} SHA-384 sha384WithRSAEncryption ::= {pkcs-1 12} SHA-512 sha512WithRSAEncryption ::= {pkcs-1 13} and TLSv1.2 mandates support for sha-256 for the TLSv1.2 PRF anyway. and NIST SP 800-57 part1 rev 2 (08-Mar-2007) said the following about digital signatures with SHA-1 (footnote 22 on page 64): 22 SHA-1 has recently been demonstrated to provide less than 80 bits of security for digital signatures; at the publication of this Recommendation, the security strength against collisions is assessed at 69 bits. The use of SHA-1 is not recommended for the generation of digital signatures in new systems; new systems should use one of the larger hash functions. For the present time, SHA-1 is included here to reflect it's widespread use in existing systems, for which the reduced security strength may not be of great concern when only 80-bits of security are required. and says on page 65: A minimum of eighty bits of security shall be provided until 2010. Between 2011 and 2030, a minimum of 112 bits of security shall be provided. Thereafter, at least 128 bits of security shall be provided. so the originally planned the sunsetting(!) date for use of SHA-1 in digital signatures was end-of-2010. So it was a fairly crazy&irresponsible idea for TLSv1.2 (rfc5246) to newly add sha1WithRSAEncryption and md5WithRSAEncryption (rather than sha256WithRSAEncryption) as default and mandatory-to-implement signature schemes to TLSv1.2 as replacement for a _stronger_ schemes in prior protocol versions. -Martin From nobody Tue Jul 7 06:02:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDBF1A037F for ; Tue, 7 Jul 2015 06:02:06 -0700 (PDT) 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 v4cinh361HeO for ; Tue, 7 Jul 2015 06:02:01 -0700 (PDT) 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 EECA71A037E for ; Tue, 7 Jul 2015 06:02:00 -0700 (PDT) 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 6D1822AAC2; Tue, 7 Jul 2015 15:01:59 +0200 (CEST) X-purgate-ID: 152705::1436274119-00000B48-D109CCC5/0/0 X-purgate-size: 2049 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 5E1EE400A3; Tue, 7 Jul 2015 15:01:59 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 563111A1C0; Tue, 7 Jul 2015 15:01:59 +0200 (CEST) In-Reply-To: <20150705201944.5dfce8d5@pc1> To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Date: Tue, 7 Jul 2015 15:01:59 +0200 (CEST) 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: <20150707130159.563111A1C0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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, 07 Jul 2015 13:02:06 -0000 Hanno B=F6ck wrote: >=20 >> Hanno B=F6ck wrote: >>> On RSA there was only limited discussion, but I had the impression >>> there is hardly an argument for not going with PSS >>=20 >> You seem to believe that RSA-PSS is better than PKCS#1 v1.5 signature >> padding. Could you elaborate why you believe this to be? >=20 > The most obvious reason is the Bleichenbacher signature forgery attack > and related issues like BERserk. I can hardly think how anything > similar could happen with PSS. Both are pure implementation issues, and the solution to both have been well-known and specified several years before TLSv1.2: http://tools.ietf.org/html/rfc3447#section-9.2 This encoding method is deterministic and only has an encoding operation. But the designers of TLSv1.2, who _newly_ added support for BERserk-susceptible PKCS#1 v1.5 signatures failed to require the known-safe approach. > > BERserk especially highlights a new problem of the old PKCS: Having a > complex encoding (ASN.1) directly inside a cryptographic function seems > like a bad idea. No, BERserk highlights two other issues. Reckless spec writers in combination with superficial implementers. >=20 >> It was my impression that RSA-PSS adds complexity and slows down >> things >=20 > The added complexity is limited. The performance probably is hardly > measurable. It's a couple of added hash calculations. But if this is a > real concern I can try to create some benchmarks. As I've previously wrote about RSA-PSS, the real issue is not about the transform specified in rfc3447, but about the PKIX policy crap expected / associated with RSA-PSS, such as what rfc4055 says. You typically have to change low-level crypto functions to be able to pass along the crazy (and superflous) RSA-PSS algorithm parameters around (and the parameters necessary to be able to perform the expected policy checks). ECDSA signatures are much easier to accomodate with existing APIs (they have other problems). -Martin From nobody Tue Jul 7 07:04:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22FA1AC3E7 for ; Tue, 7 Jul 2015 07:04:47 -0700 (PDT) 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, 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 IqnqKeqdFNY1 for ; Tue, 7 Jul 2015 07:04:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7D61AC3E1 for ; Tue, 7 Jul 2015 07:04:43 -0700 (PDT) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.207.19; Tue, 7 Jul 2015 14:04:40 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0207.004; Tue, 7 Jul 2015 14:04:40 +0000 From: "Dang, Quynh" To: Eric Rescorla Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek Thread-Index: AQHQs4OCiSVGDnhMFEq7N51zJUqqfJ3QEZmx Date: Tue, 7 Jul 2015 14:04:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.230.6] x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:9ri6L03I8VhP22NOG8X79SLXfFD15SbGnWmRtRoKnMdpJF1uc+8PlJOM1nS68PDgBmKZRicbhdT4iz4gbgEpOnouVOgX+df8fOFxCw2GbX1apa7AcsZJ6bvLizoMp8o6H7UJKCrdNeNN2XOrWLi9Rw==; 24:E2jqv+7So+Hqpx9YRYFCX6hcp6uHypTrTQBn5q1wSzRorXTfRVrL9AqCNPnhTa8JzJmoSDK8NmAymYswCEm1bwPHzh9n8Ol/f9T3poNdTsU=; 20:7zc7d3CRippvfxL98QlCbSR29jIPEbBkLivB64NEYKCu0sqjjl778IG7RY59i0v97qN5giE2f4PgpvCHBfbdvg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(46102003)(50986999)(19625215002)(66066001)(2950100001)(40100003)(16236675004)(2900100001)(76176999)(86362001)(102836002)(77096005)(19627405001)(2656002)(74316001)(19580405001)(33656002)(189998001)(77156002)(5003600100002)(87936001)(62966003)(54356999)(106116001)(92566002)(99286002)(5002640100001)(110136002)(5001960100002)(76576001)(19580395003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124B3CB18E6E4B8ABE24739F3920BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 14:04:40.7285 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 14:04:48 -0000 --_000_BN1PR09MB124B3CB18E6E4B8ABE24739F3920BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, Since the key derivation method is the HKDF method, I think the current PRF= (in TLS 1.2) should be removed/changed. The key-expansion step in the HKDF= should be used to generate keying materials. For resumptions, will you re-run the resumption master secrets through the = extraction step again or just run them through the key expansion step? I do= n't think the extraction step is necessary here. Quynh. ________________________________ From: TLS on behalf of Eric Rescorla Sent: Tuesday, June 30, 2015 6:23 PM To: tls@ietf.org Subject: [TLS] TLS 1.3 draft-07 sneak peek Folks, Yesterday, I posted the -06 draft which snapshots the consensus changes made since -05, specifically: - Prohibit RC4 negotiation for backwards compatibility. - Freeze & deprecate record layer version field. - Update format of signatures with context. - Remove explicit IV. In the background, I've also been working with Hugo, Hoeteck, Karthik, and others to develop a new draft using semi-ephemeral DH based on Hugo's ideas as discussed in Dallas. I'm planning to merge this into master soon and submit it as draft-07 next week, but I wanted to e-mail the list and give people a chance to comment before I do that. I've provided a summary of the major changes and open issues below. Remember, this is a WIP so if you see something wrong, don't panic, but do let me know. CHANGES 1. Move ClientKeyShare into an extension so that the ClientHello is the only message in the client's first flight. This removes a bunch of ugliness around the "early_data" extension which could encapsulate handshake and application data. 2. Added a mechanism for the server to indicate a known (EC)DHE key/configuration which the client can then use in subsequent handshakes (via the known_configuration extension). The net effect here is that the client and server can skip over the signature in subsequent handshakes, which provides benefit when signatures are much slower than key exchange, as with RSA; it also enables 0-RTT. 3. Added support for 0-RTT data, both with and without client authentication. 4. Removed most of the support for resumption in favor of a mechanism proposed by Karthik where you just establish a PSK in connection N which you then use to key a PSK cipher suite in connection N+1. All of these keying mechanisms use a unified key schedule based on two keys the "Ephemeral Secret" (ES) and the "Static Secret" (SS). Depending on the exact handshake type, these may be equal, but the logic is the same regardless. In the process, I also converted the key schedule to use HKDF (per WG consensus). OPEN ISSUES There are still a number of known open issues to discuss: 1. The present known_configuration mechanism allows the client to resurrect the handshake parameters (though not the keys) which were negotiated in a previous handshake, but this is done implicitly, i.e., the server provides a label and the client returns it on the next connection. This has the advantage of keeping things short but the disadvantage the it means that you can't have a static configuration ID for everyone (instead, the server has to somehow embed the properties in the configuration ID). There are (at least) three potential alternative designs: (a) Have the client indicate in his first flight "these are the parameters I expect you to negotiate", along with the configuration identifier, based on what the server negotiated the previous time. [Optionally, the server can run the same negotiation locally and abort on mismatch.] (b) As in (a) but with no indication of the expected parameters, just the configuration ID, and the client just preemptively uses the parameters from the last time and if the negotiation ends up differently, all the data is undecryptable (ugh) and you somehow fall back. (c) Have the server provide a preference list in his ServerConfiguration (this can be the same as in the ClientHello) and have the client do the negotiation based on that rather than the server (as in QUIC). This is a little odd in that it means that sometimes the server selects the parameters and sometimes the client does, but it's not that hard to make this code symmetrical. As I think this through, I am leaning towards (a) but other people's opinions on this topic would be welcome. 2. Should we require that PSK cipher suites where the PSK is used for resumption use compatible ciphers? This is the way it was in TLS 1.2 and below for resumption and tickets, but once you have a PSK, that's not really necessary [0]. So, for instance, if you had the following cipher list order: ECDHE + AES-GCM ECDHE + ChaCha/Poly PSK + ChaCha/Poly PSK + AES-GCM You could potentially negotiate one connection with GCM, use it to establish a shared key, and then reconnect with ChaCha/Poly. This seems like it probably should be something we avoid, though I'm not sure we have a concrete reason why, and it means a weird special case for PSK. Note that this issue might be ameliorated some (though not completely) with a la carte negotiation. 3. I don't currently have PSK/Resumption + 0-RTT working, because you need a way to indicate the expected parameters (see point #1 above). 4. I plan to rewrite the Handshake Protocol Overview (S 6.2) to be clearer. I hope to do this before submitting -07. 5. Security Considerations is badly out of date, so I plan to rewrite that soon, but probably not before Prague. I also intend to do a pretty substantial editorial cleanup pass and potentially some restructuring after Prague. As indicated above, this is still a WIP, so no doubt contains a number of errors, potentially serious ones. Comments and PRs welcome. Thanks, -Ekr [0] With the exception of cryptographic concerns about the use of the same IKM with different hash functions for HKDF, but this is a problem that applies to any use of PSK, not just this one. --_000_BN1PR09MB124B3CB18E6E4B8ABE24739F3920BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi Eric,

Since the key derivation method is the HKDF method, I think the curren= t PRF (in TLS 1.2) should be removed/changed. The key-expansion step in the= HKDF should be used to generate keying materials. 

For resumptions, will you re-run the resumption master secrets th= rough the extraction step again or just run them through the key expan= sion step? I don't think the extraction step is necessary here.

Quynh. 

From: TLS <tls-bounces@i= etf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Tuesday, June 30, 2015 6:23 PM
To: tls@ietf.org
Subject: [TLS] TLS 1.3 draft-07 sneak peek
 
Folks,

Yesterday, I posted the -06 draft which snapshots the consensus change= s
made since -05, specifically:

- Prohibit RC4 negotiation for backwards compatibility.
- Freeze & deprecate record layer version field.
- Update format of signatures with context.
- Remove explicit IV.


In the background, I've also been working with Hugo, Hoeteck, Karthik,=
and others to develop a new draft using semi-ephemeral DH based on
Hugo's ideas as discussed in Dallas. I'm planning to merge this into
master soon and submit it as draft-07 next week, but I wanted to
e-mail the list and give people a chance to comment before I do
that. I've provided a summary of the major changes and open issues
below. Remember, this is a WIP so if you see something wrong, don't
panic, but do let me know.


CHANGES
1. Move ClientKeyShare into an extension so that the ClientHello
   is the only message in the client's first flight. This re= moves
   a bunch of ugliness around the "early_data" ext= ension which
   could encapsulate handshake and application data.

2. Added a mechanism for the server to indicate a known (EC)DHE
   key/configuration which the client can then use in subseq= uent
   handshakes (via the known_configuration extension). The n= et
   effect here is that the client and server can skip over t= he
   signature in subsequent handshakes, which provides benefi= t
   when signatures are much slower than key exchange, as wit= h
   RSA; it also enables 0-RTT.

3. Added support for 0-RTT data, both with and without
   client authentication.

4. Removed most of the support for resumption in favor of
   a mechanism proposed by Karthik where you just establish<= /div>
   a PSK in connection N which you then use to key a PSK
   cipher suite in connection N+1.

All of these keying mechanisms use a unified key schedule based on two=
keys the "Ephemeral Secret" (ES) and the "Static Secret= "
(SS). Depending on the exact handshake type, these may be equal, but
the logic is the same regardless. In the process, I also converted
the key schedule to use HKDF (per WG consensus).


OPEN ISSUES
There are still a number of known open issues to discuss:

1. The present known_configuration mechanism allows the client to
resurrect the handshake parameters (though not the keys) which were
negotiated in a previous handshake, but this is done implicitly,
i.e., the server provides a label and the client returns it on
the next connection. This has the advantage of keeping things short
but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). There are (at least)
three potential alternative designs:

   (a) Have the client indicate in his first flight "th= ese are the
       parameters I expect you to negotiate",= along with the
       configuration identifier, based on what the= server
       negotiated the previous time. [Optionally, = the server
       can run the same negotiation locally and ab= ort on mismatch.]

   (b) As in (a) but with no indication of the expected para= meters,
       just the configuration ID, and the client j= ust preemptively
       uses the parameters from the last time and = if the negotiation
       ends up differently, all the data is undecr= yptable
       (ugh) and you somehow fall back.

   (c) Have the server provide a preference list in his
       ServerConfiguration (this can be the same a= s in the
       ClientHello) and have the client do the neg= otiation based on
       that rather than the server (as in QUIC). T= his is a little odd
       in that it means that sometimes the server = selects the
       parameters and sometimes the client does, b= ut it's not that
       hard to make this code symmetrical.

As I think this through, I am leaning towards (a) but other people's
opinions on this topic would be welcome.


2. Should we require that PSK cipher suites where the PSK is used for<= /div>
resumption use compatible ciphers? This is the way it was in TLS 1.2
and below for resumption and tickets, but once you have a PSK, that's<= /div>
not really necessary [0]. So, for instance, if you had the following
cipher list order:

    ECDHE + AES-GCM
    ECDHE + ChaCha/Poly
    PSK + ChaCha/Poly
    PSK + AES-GCM

You could potentially negotiate one connection with GCM, use it
to establish a shared key, and then reconnect with ChaCha/Poly.
This seems like it probably should be something we avoid, though
I'm not sure we have a concrete reason why, and it means a
weird special case for PSK. Note that this issue might be
ameliorated some (though not completely) with a la carte negotiation.<= /div>


3. I don't currently have PSK/Resumption + 0-RTT working, because = you
need a way to indicate the expected parameters (see point #1 above).


4. I plan to rewrite the Handshake Protocol Overview (S 6.2)
to be clearer. I hope to do this before submitting -07.

5. Security Considerations is badly out of date, so I plan to
rewrite that soon, but probably not before Prague. I also intend
to do a pretty substantial editorial cleanup pass and potentially
some restructuring after Prague.


As indicated above, this is still a WIP, so no doubt contains
a number of errors, potentially serious ones. Comments and PRs
welcome.

Thanks,
-Ekr


[0] With the exception of cryptographic concerns about the use
of the same IKM with different hash functions for HKDF, but this
is a problem that applies to any use of PSK, not just this one.

--_000_BN1PR09MB124B3CB18E6E4B8ABE24739F3920BN1PR09MB124namprd_-- From nobody Tue Jul 7 07:37:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C524B1AC428 for ; Tue, 7 Jul 2015 07:37:25 -0700 (PDT) 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 qTyZCAQJpC5Q for ; Tue, 7 Jul 2015 07:37:20 -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 D09031AC3F8 for ; Tue, 7 Jul 2015 07:34:33 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 52A151887F4; Tue, 7 Jul 2015 17:34:31 +0300 (EEST) Date: Tue, 7 Jul 2015 17:34:31 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150707143431.GA853@LK-Perkele-VII> References: <201507031907.13872.davemgarrett@gmail.com> <201507031925.04809.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201507031925.04809.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 14:37:25 -0000 On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote: > On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote: > > I think we probably need to have WG consensus for the SHA-1 thing. > > Yes, that's why I left it out of that changeset. I don't think the > topic of what to do in the TLS 1.3 spec with SHA1 has been discussed > on this list. (if it has, please point me to the thread if someone > can) > > The simplest thing would be to have a MUST NOT offer or negotiate > in 2017 or later and a NOT RECOMMENDED to use until then. Or, we > could go deeper into the weeds and talk about expiration dates. > Banning it totally for TLS 1.3+ is also an option, but probably not > wanted yet. No, the simplest thing would be to ban it entierely: - MUST ignore entries with MD5 or SHA1 hash in supported_signature_algorithms, even if those are the only ones (which will cause handshake failure). - MUST terminate connection with insufficient_security if MD5 or SHA1 is seen in DigitallySigned.algorithm. SHA-1 is known to be seriously broken. That is way more than enough reason to completely remove it. Especially from new standards. If one wants those to also apply to TLS 1.2, plus: - MUST send signature_algorithms extension in TLS 1.2+, server MUST terminate connections without it. - MUST NOT send MD5 or SHA1 entries in supported_signature_algorithms. Effective immeidately for MD5, and in 1.1.2017 for SHA1 (including signature_algorithms) is separate matter (and separate draft). -Ilari From nobody Tue Jul 7 07:54:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDBD1ACD24 for ; Tue, 7 Jul 2015 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 78PKNDOr98mJ for ; Tue, 7 Jul 2015 07:54:27 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33AA1ACD22 for ; Tue, 7 Jul 2015 07:54:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,424,1432591200"; d="scan'208";a="169220268" Received: from pool-71-161-84-157.cncdnh.east.myfairpoint.net (HELO [192.168.0.100]) ([71.161.84.157]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 16:54:15 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Karthikeyan Bhargavan In-Reply-To: <20150707143431.GA853@LK-Perkele-VII> Date: Tue, 7 Jul 2015 10:54:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> References: <201507031907.13872.davemgarrett@gmail.com> <201507031925.04809.davemgarrett@gmail.com> <20150707143431.GA853@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 14:54:30 -0000 Putting aside the timeline for retiring SHA-1 from certificates, which = will happen sooner than later, I think we should ban MD5 and SHA1 from client and = server=20 signatures in TLS 1.3.=20 Recent events show that TLS servers get updated too slowly to hope for graceful deprecation. Using the version change to remove these=20 (like we removed RSA encryption and RC4) would be right thing to do -Karthik > On 07 Jul 2015, at 10:34, Ilari Liusvaara = wrote: >=20 > On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote: >> On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote: >>> I think we probably need to have WG consensus for the SHA-1 thing. >>=20 >> Yes, that's why I left it out of that changeset. I don't think the >> topic of what to do in the TLS 1.3 spec with SHA1 has been discussed >> on this list. (if it has, please point me to the thread if someone >> can) >>=20 >> The simplest thing would be to have a MUST NOT offer or negotiate >> in 2017 or later and a NOT RECOMMENDED to use until then. Or, we >> could go deeper into the weeds and talk about expiration dates. >> Banning it totally for TLS 1.3+ is also an option, but probably not >> wanted yet. >=20 > No, the simplest thing would be to ban it entierely: > - MUST ignore entries with MD5 or SHA1 hash in > supported_signature_algorithms, even if those are the only > ones (which will cause handshake failure). > - MUST terminate connection with insufficient_security if MD5 or > SHA1 is seen in DigitallySigned.algorithm. >=20 > SHA-1 is known to be seriously broken. That is way more than > enough reason to completely remove it. Especially from new > standards. >=20 >=20 > If one wants those to also apply to TLS 1.2, plus: > - MUST send signature_algorithms extension in TLS 1.2+, > server MUST terminate connections without it. > - MUST NOT send MD5 or SHA1 entries in > supported_signature_algorithms. >=20 > Effective immeidately for MD5, and in 1.1.2017 for SHA1 > (including signature_algorithms) is separate matter > (and separate draft). >=20 >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 7 07:55:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1171ACD22 for ; Tue, 7 Jul 2015 07:55:01 -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 HcmE9dFKD0D8 for ; Tue, 7 Jul 2015 07:55:00 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA501AC41C for ; Tue, 7 Jul 2015 07:55:00 -0700 (PDT) Received: by qgef3 with SMTP id f3so35398603qge.0 for ; Tue, 07 Jul 2015 07:54:59 -0700 (PDT) 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=6OOhUd2MG36xRNFnKrdqDd3S1g6JAtaoTYYQCKc3tzg=; b=T3BsHFZx/aJWUmFReyXN2o2oVraz2MAv44rx2CwYB9iS18ZshYoHJIBuRUGgsvY+un V77NVLC3dJkwxPXJkUvaSlKGJrhoUqLj8oLG20OANYjMofVH3UHyPdfkLJ+esFTyfs4r 3OmY+Ba6K7YBrRVKN+AdbRhvgWDs1eRQQg/8JPD+rkA9wD4t1zItcnT4epM2t3in37oN 221cQWChEHy7ZSxNxqMd5pF0OaDbWnTw1ks7P4gMqu8ReQLWmKG9gOegK7zmjY35u0EZ EYLtJfQMftpA5Mni6LYkEYz0/YsF4nT88XVtFbc1q70EoEVW8/NRg0zgJ7k+gPsvpFPz AM7A== X-Received: by 10.140.232.3 with SMTP id d3mr7884649qhc.46.1436280899359; Tue, 07 Jul 2015 07:54:59 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b31sm11328781qge.5.2015.07.07.07.54.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 Jul 2015 07:54:58 -0700 (PDT) From: Dave Garrett To: Ilari Liusvaara Date: Tue, 7 Jul 2015 10:54:56 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507031925.04809.davemgarrett@gmail.com> <20150707143431.GA853@LK-Perkele-VII> In-Reply-To: <20150707143431.GA853@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507071054.57330.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 14:55:01 -0000 On Tuesday, July 07, 2015 10:34:31 am Ilari Liusvaara wrote: > On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote: > > On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote: > > > I think we probably need to have WG consensus for the SHA-1 thing. > > > > Yes, that's why I left it out of that changeset. I don't think the > > topic of what to do in the TLS 1.3 spec with SHA1 has been discussed > > on this list. (if it has, please point me to the thread if someone > > can) > > > > The simplest thing would be to have a MUST NOT offer or negotiate > > in 2017 or later and a NOT RECOMMENDED to use until then. Or, we > > could go deeper into the weeds and talk about expiration dates. > > Banning it totally for TLS 1.3+ is also an option, but probably not > > wanted yet. > > No, the simplest thing would be to ban it entierely: > - MUST ignore entries with MD5 or SHA1 hash in > supported_signature_algorithms, even if those are the only > ones (which will cause handshake failure). > - MUST terminate connection with insufficient_security if MD5 or > SHA1 is seen in DigitallySigned.algorithm. > > SHA-1 is known to be seriously broken. That is way more than > enough reason to completely remove it. Especially from new > standards. > > If one wants those to also apply to TLS 1.2, plus: > - MUST send signature_algorithms extension in TLS 1.2+, > server MUST terminate connections without it. > - MUST NOT send MD5 or SHA1 entries in > supported_signature_algorithms. I very much agree that banning it entirely is the ideal route, but there were indications given that we didn't want to do this, unfortunately. Again I'll state: by the time TLS 1.3 is done and actually being adopted, an assumption of no SHA1 will be even more expected. Servers that are playing chicken with browsers planning on dropping support for them in a matter of months can stick to TLS 1.2. Dave From nobody Tue Jul 7 07:57:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738851ACD3E for ; Tue, 7 Jul 2015 07:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 nXPsJttAe1JY for ; Tue, 7 Jul 2015 07:57:35 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 022DB1ACD4A for ; Tue, 7 Jul 2015 07:57:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5AE96169B81; Tue, 7 Jul 2015 14:57:26 +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 45243169B80; Tue, 7 Jul 2015 14:57:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436281046; bh=o0qpxH4MLIu+5RJ6Kd/kR/kRvYLkqm++yNmpD6QAk0M=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=oGpc6qk9B4doKHRXX9AfPCS66DxiKzHYJ0yRdwsPY0dwBh2pUjfR0fVchXximn/Ey v099cYb4GEC4/Gf7JNhRKAtYatu0dnv0nO+a5XH7el6O+H0QA3KBJuTe55acNTMy67 UbjjgKOXhJipHjLZlzOLvADRcGN4xRcANrW8hTf0= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 438FA1E07C; Tue, 7 Jul 2015 14:57:26 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 09:57:25 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Tue, 7 Jul 2015 09:57:25 -0500 From: "Salz, Rich" To: Karthikeyan Bhargavan , Ilari Liusvaara Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek Thread-Index: AQHQs4N+HZfm/z0y00OjYka0WtcI8p3KVrOAgAADLYCAAAVTgIAASwyAgAAB/QCAAAqMgIAAAbCAgAADTQCABbUXgIAABX2A//+s+5A= Date: Tue, 7 Jul 2015 14:57:24 +0000 Message-ID: <20522301ad4047bf8a9e3794fd785da9@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201507031907.13872.davemgarrett@gmail.com> <201507031925.04809.davemgarrett@gmail.com> <20150707143431.GA853@LK-Perkele-VII> <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> In-Reply-To: <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 14:57:36 -0000 > Putting aside the timeline for retiring SHA-1 from certificates, which wi= ll > happen sooner than later, I think we should ban MD5 and SHA1 from client > and server signatures in TLS 1.3. Strongly in favor. I see no reason why a new protocol should ever use SHA1= . -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Tue Jul 7 08:17:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8201A88D0 for ; Tue, 7 Jul 2015 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 L8YIxVkg6cZ7 for ; Tue, 7 Jul 2015 08:17:45 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E56791A88C2 for ; Tue, 7 Jul 2015 08:17:44 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E0F8E48C3E; Tue, 7 Jul 2015 15:17:53 +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 C8ECA48B87; Tue, 7 Jul 2015 15:17:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436282273; bh=pg4h81t02XoR3rXWqIDv9VTpjV2Yqd9Hkt5y7cZWLoM=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=r7+wv6CHYDzOEZ8eVpdznDM+0xDOvA25kwn01Nm7qFJe3IxcI8B0OnKcPh91ALhB8 N12qG4+SbnjWUDw+DJ2gR/jeiZdOkM9aETXT9KLndn/WU3S530fTCAXG/D3WsXjagc rYl3/WlLxJh61RyKBrCU3otF82cJB7r7xQn18AtQ= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 90F4880087; Tue, 7 Jul 2015 15:17:43 +0000 (GMT) Received: from USMA1EX-CAS1.msg.corp.akamai.com (172.27.123.30) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 11:17:43 -0400 Received: from bos-mpeve.local (172.19.44.26) by USMA1EX-CAS1.msg.corp.akamai.com (172.27.123.30) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Tue, 7 Jul 2015 11:17:43 -0400 From: Brian Sniffen To: Watson Ladd , Erik Nygren In-Reply-To: References: User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-apple-darwin13.4.0) Date: Tue, 7 Jul 2015 11:18:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 15:17:46 -0000 > At these rates you saturate gigabit ethernet connections, which > puzzles will not help with. In fact, they will make the problem worse. It's now normal to deploy one 10GbE NIC per CPU. CPU load is definitely still the bottleneck. > What about improving performance? That avoids any protocol changes, > and brings about the benefits you seem to want. By all means! But it'll take 10-20 years to get those performance benefits out to the ends of the Earth. I hope we can have some conversations using that technology in 2-5 years, but we should expect to be supporting RSA-2048 at least through 2025 (or a few years after it's discovered to be broken), and NIST curves through 2030. I'm not happy (or sad) about those dates, but if we think we're going to go faster than final death of SSLv2, MD5, and similar, we should be able to explain why that would be. -Brian From nobody Tue Jul 7 08:35:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BE71A8901 for ; Tue, 7 Jul 2015 08:35:08 -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 ldpsCpxsiNlj for ; Tue, 7 Jul 2015 08:35:06 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F551A8912 for ; Tue, 7 Jul 2015 08:35:05 -0700 (PDT) Received: by qkhu186 with SMTP id u186so142569880qkh.0 for ; Tue, 07 Jul 2015 08:35:05 -0700 (PDT) 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=ORmGpJZhRUqQHH6iK6d4u6KDMQs5B2eBcv7PWkQkiQc=; b=e92sTwOPEtp1njXwpGpPfqRmydtcf/0C89VnodBNUGoTuo+ZtrucK5/N/ZZDl4mY+d 6BcSemqVUFcPfwWGpS/U55KAOvPams6rb0/ICT00s0wBcaJOej7bNJ7+zoyyHu6aMdI9 1DuR8a9MA1Agwzc5XyAWxN8nIXZOfquy/VeUiTz213c9KMU28vI8o7ukYBRhrM9r4PGl RaM98ez670Fx2mhy7zeh3s2g+S955UDXPMVri6fC7ArYBexZT4aqrpAWW6vXyiANlgfl 8CTha1EMyR5QcxRxUReU6mAWe6cZFzJlrRGyAX6LMV05aYfT3vbeFkehrE4fEIPX9t6y vAWQ== X-Received: by 10.140.98.238 with SMTP id o101mr7806194qge.12.1436283305212; Tue, 07 Jul 2015 08:35:05 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 10sm11386748qgl.9.2015.07.07.08.35.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 Jul 2015 08:35:04 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 7 Jul 2015 11:35:00 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> <20522301ad4047bf8a9e3794fd785da9@ustx2ex-dag1mb2.msg.corp.akamai.com> In-Reply-To: <20522301ad4047bf8a9e3794fd785da9@ustx2ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507071135.00448.davemgarrett@gmail.com> Archived-At: Cc: Karthikeyan Bhargavan Subject: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 15:35:08 -0000 On Tuesday, July 07, 2015 10:57:24 am Salz, Rich wrote: > > Putting aside the timeline for retiring SHA-1 from certificates, which will > > happen sooner than later, I think we should ban MD5 and SHA1 from client > > and server signatures in TLS 1.3. > > Strongly in favor. I see no reason why a new protocol should ever use SHA1. Good. There seems to be strong support all around for this. I've updated the PR to drop SHA1 too. PR: https://github.com/tlswg/tls13-spec/pull/188/files Issue: https://github.com/tlswg/tls13-spec/issues/186 I also have a mandatory extensions patch here: https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions I'll probably just submit a PR for that too in a bit. Dave From nobody Tue Jul 7 09:05:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E0B1A8A04 for ; Tue, 7 Jul 2015 09:05:30 -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 mFjEXP-5lH8N for ; Tue, 7 Jul 2015 09:05:27 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E8D1ACD52 for ; Tue, 7 Jul 2015 09:05:26 -0700 (PDT) Received: by wgjx7 with SMTP id x7so172160504wgj.2 for ; Tue, 07 Jul 2015 09:05:25 -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=K635PNo4TEQQE4oiPOe/IUC9ZiEjoTBda1VLeK4/8vo=; b=IHTNTL2wr7XBuL/2Wcz5i0wuilm6PjtP9U4poHZZ7QA567Hr82qgNOZCZKDYUcnqiY lFfvlMj/qPrkr/HkPVh9qkF3JyrUAhMuanu3T3+nPjnP/I2tBr2i/XI5XMh1AYx3b4uv RQ6kNyQbTBe4qq8XAKC1SdU1rupBXzAiciVHiHdmakdamjV/YEj4szBOKXic8HiIVt2x KWC4QSS6lSDj4vqvPTq1OEEkBjELD8EyBrvRyBkKXTzQdkoNL0Asysv8QnD1uoJZ7MsY 2rLt5Gn5kRfVT90hUK/paVoWs/dzas/ive+xcKMIrJAat/F3QVl3bqDF7creqpsXtq4a dHLg== X-Gm-Message-State: ALoCoQlFmYsCrhzhZ2TQA1S2gtmVj84MKchcoSKEQBYjxvFStwaotUw3AP6UJTRdzP0kJeY5YBqg X-Received: by 10.194.133.73 with SMTP id pa9mr9760316wjb.148.1436285125595; Tue, 07 Jul 2015 09:05:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 7 Jul 2015 09:04:45 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 7 Jul 2015 09:04:45 -0700 Message-ID: To: "Dang, Quynh" Content-Type: multipart/alternative; boundary=089e011771a9b52c8f051a4b30ee Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:05:30 -0000 --089e011771a9b52c8f051a4b30ee Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 7:04 AM, Dang, Quynh wrote: > > Hi Eric, > > Since the key derivation method is the HKDF method, I think the current > PRF (in TLS 1.2) should be removed/changed. The key-expansion step in the > HKDF should be used to generate keying materials. > Yes, that's how it's supposed to look. If I missed some PRF instances, please point them out. For resumptions, will you re-run the resumption master secrets through the > extraction step again or just run them through the key expansion step? I > don't think the extraction step is necessary here. > Since we're trying to model resumption as PSK, I want to run the entire key schedule for consistency. -Ekr > Quynh. > > ------------------------------ > *From:* TLS on behalf of Eric Rescorla < > ekr@rtfm.com> > *Sent:* Tuesday, June 30, 2015 6:23 PM > *To:* tls@ietf.org > *Subject:* [TLS] TLS 1.3 draft-07 sneak peek > > Folks, > > Yesterday, I posted the -06 draft which snapshots the consensus changes > made since -05, specifically: > > - Prohibit RC4 negotiation for backwards compatibility. > - Freeze & deprecate record layer version field. > - Update format of signatures with context. > - Remove explicit IV. > > > In the background, I've also been working with Hugo, Hoeteck, Karthik, > and others to develop a new draft using semi-ephemeral DH based on > Hugo's ideas as discussed in Dallas. I'm planning to merge this into > master soon and submit it as draft-07 next week, but I wanted to > e-mail the list and give people a chance to comment before I do > that. I've provided a summary of the major changes and open issues > below. Remember, this is a WIP so if you see something wrong, don't > panic, but do let me know. > > > CHANGES > 1. Move ClientKeyShare into an extension so that the ClientHello > is the only message in the client's first flight. This removes > a bunch of ugliness around the "early_data" extension which > could encapsulate handshake and application data. > > 2. Added a mechanism for the server to indicate a known (EC)DHE > key/configuration which the client can then use in subsequent > handshakes (via the known_configuration extension). The net > effect here is that the client and server can skip over the > signature in subsequent handshakes, which provides benefit > when signatures are much slower than key exchange, as with > RSA; it also enables 0-RTT. > > 3. Added support for 0-RTT data, both with and without > client authentication. > > 4. Removed most of the support for resumption in favor of > a mechanism proposed by Karthik where you just establish > a PSK in connection N which you then use to key a PSK > cipher suite in connection N+1. > > All of these keying mechanisms use a unified key schedule based on two > keys the "Ephemeral Secret" (ES) and the "Static Secret" > (SS). Depending on the exact handshake type, these may be equal, but > the logic is the same regardless. In the process, I also converted > the key schedule to use HKDF (per WG consensus). > > > OPEN ISSUES > There are still a number of known open issues to discuss: > > 1. The present known_configuration mechanism allows the client to > resurrect the handshake parameters (though not the keys) which were > negotiated in a previous handshake, but this is done implicitly, > i.e., the server provides a label and the client returns it on > the next connection. This has the advantage of keeping things short > but the disadvantage the it means that you can't have a static > configuration ID for everyone (instead, the server has to somehow > embed the properties in the configuration ID). There are (at least) > three potential alternative designs: > > (a) Have the client indicate in his first flight "these are the > parameters I expect you to negotiate", along with the > configuration identifier, based on what the server > negotiated the previous time. [Optionally, the server > can run the same negotiation locally and abort on mismatch.] > > (b) As in (a) but with no indication of the expected parameters, > just the configuration ID, and the client just preemptively > uses the parameters from the last time and if the negotiation > ends up differently, all the data is undecryptable > (ugh) and you somehow fall back. > > (c) Have the server provide a preference list in his > ServerConfiguration (this can be the same as in the > ClientHello) and have the client do the negotiation based on > that rather than the server (as in QUIC). This is a little odd > in that it means that sometimes the server selects the > parameters and sometimes the client does, but it's not that > hard to make this code symmetrical. > > As I think this through, I am leaning towards (a) but other people's > opinions on this topic would be welcome. > > > 2. Should we require that PSK cipher suites where the PSK is used for > resumption use compatible ciphers? This is the way it was in TLS 1.2 > and below for resumption and tickets, but once you have a PSK, that's > not really necessary [0]. So, for instance, if you had the following > cipher list order: > > ECDHE + AES-GCM > ECDHE + ChaCha/Poly > PSK + ChaCha/Poly > PSK + AES-GCM > > You could potentially negotiate one connection with GCM, use it > to establish a shared key, and then reconnect with ChaCha/Poly. > This seems like it probably should be something we avoid, though > I'm not sure we have a concrete reason why, and it means a > weird special case for PSK. Note that this issue might be > ameliorated some (though not completely) with a la carte negotiation. > > > 3. I don't currently have PSK/Resumption + 0-RTT working, because you > need a way to indicate the expected parameters (see point #1 above). > > > 4. I plan to rewrite the Handshake Protocol Overview (S 6.2) > to be clearer. I hope to do this before submitting -07. > > 5. Security Considerations is badly out of date, so I plan to > rewrite that soon, but probably not before Prague. I also intend > to do a pretty substantial editorial cleanup pass and potentially > some restructuring after Prague. > > > As indicated above, this is still a WIP, so no doubt contains > a number of errors, potentially serious ones. Comments and PRs > welcome. > > Thanks, > -Ekr > > > [0] With the exception of cryptographic concerns about the use > of the same IKM with different hash functions for HKDF, but this > is a problem that applies to any use of PSK, not just this one. > > --089e011771a9b52c8f051a4b30ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 7, 2015 at 7:04 AM, Dang, Quynh <quynh.dang@nist.gov= > wrote:


Hi Eric,

Since the key derivation method is the HKDF method, I think the curren= t PRF (in TLS 1.2) should be removed/changed. The key-expansion step in the= HKDF should be used to generate keying materials.=C2=A0
<= /blockquote>

Yes, that's how it's supposed to lo= ok. If I missed some PRF instances, please point
them out.
<= div>

For resumptions, will you re-run the=C2=A0resumption master secrets th= rough the extraction step again or just run them through=C2=A0the key expan= sion step?=C2=A0I don't think the extraction step is necessary here.

Since we're trying to m= odel resumption as PSK, I want to run the entire key
schedule for= consistency.

-Ekr

=C2=A0=
Quynh.=C2=A0

From: TLS <tls-bounces@ietf.org> on behalf of Eric Resc= orla <ekr@rtfm.com= >
Sent: Tuesday, June 30, 2015 6:23 PM
To: tls@ietf.org
Subject: [TLS] TLS 1.3 draft-07 sneak peek
=C2=A0
Folks,

Yesterday, I posted the -06 draft which snapshots the consensus change= s
made since -05, specifically:

- Prohibit RC4 negotiation for backwards compatibility.
- Freeze & deprecate record layer version field.
- Update format of signatures with context.
- Remove explicit IV.


In the background, I've also been working with Hugo, Hoeteck, Kart= hik,
and others to develop a new draft using semi-ephemeral DH based on
Hugo's ideas as discussed in Dallas. I'm planning to merge thi= s into
master soon and submit it as draft-07 next week, but I wanted to
e-mail the list and give people a chance to comment before I do
that. I've provided a summary of the major changes and open issues=
below. Remember, this is a WIP so if you see something wrong, don'= t
panic, but do let me know.


CHANGES
1. Move ClientKeyShare into an extension so that the ClientHello
=C2=A0 =C2=A0is the only message in the client's first flight. Thi= s removes
=C2=A0 =C2=A0a bunch of ugliness around the "early_data" ext= ension which
=C2=A0 =C2=A0could encapsulate handshake and application data.

2. Added a mechanism for the server to indicate a known (EC)DHE
=C2=A0 =C2=A0key/configuration which the client can then use in subseq= uent
=C2=A0 =C2=A0handshakes (via the known_configuration extension). The n= et
=C2=A0 =C2=A0effect here is that the client and server can skip over t= he
=C2=A0 =C2=A0signature in subsequent handshakes, which provides benefi= t
=C2=A0 =C2=A0when signatures are much slower than key exchange, as wit= h
=C2=A0 =C2=A0RSA; it also enables 0-RTT.

3. Added support for 0-RTT data, both with and without
=C2=A0 =C2=A0client authentication.

4. Removed most of the support for resumption in favor of
=C2=A0 =C2=A0a mechanism proposed by Karthik where you just establish<= /div>
=C2=A0 =C2=A0a PSK in connection N which you then use to key a PSK
=C2=A0 =C2=A0cipher suite in connection N+1.

All of these keying mechanisms use a unified key schedule based on two=
keys the "Ephemeral Secret" (ES) and the "Static Secret= "
(SS). Depending on the exact handshake type, these may be equal, but
the logic is the same regardless. In the process, I also converted
the key schedule to use HKDF (per WG consensus).


OPEN ISSUES
There are still a number of known open issues to discuss:

1. The present known_configuration mechanism allows the client to
resurrect the handshake parameters (though not the keys) which were
negotiated in a previous handshake, but this is done implicitly,
i.e., the server provides a label and the client returns it on
the next connection. This has the advantage of keeping things short
but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). There are (at least)
three potential alternative designs:

=C2=A0 =C2=A0(a) Have the client indicate in his first flight "th= ese are the
=C2=A0 =C2=A0 =C2=A0 =C2=A0parameters I expect you to negotiate",= along with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration identifier, based on what the= server
=C2=A0 =C2=A0 =C2=A0 =C2=A0negotiated the previous time. [Optionally, = the server
=C2=A0 =C2=A0 =C2=A0 =C2=A0can run the same negotiation locally and ab= ort on mismatch.]

=C2=A0 =C2=A0(b) As in (a) but with no indication of the expected para= meters,
=C2=A0 =C2=A0 =C2=A0 =C2=A0just the configuration ID, and the client j= ust preemptively
=C2=A0 =C2=A0 =C2=A0 =C2=A0uses the parameters from the last time and = if the negotiation
=C2=A0 =C2=A0 =C2=A0 =C2=A0ends up differently, all the data is undecr= yptable
=C2=A0 =C2=A0 =C2=A0 =C2=A0(ugh) and you somehow fall back.

=C2=A0 =C2=A0(c) Have the server provide a preference list in his
=C2=A0 =C2=A0 =C2=A0 =C2=A0ServerConfiguration (this can be the same a= s in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello) and have the client do the neg= otiation based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0that rather than the server (as in QUIC). T= his is a little odd
=C2=A0 =C2=A0 =C2=A0 =C2=A0in that it means that sometimes the server = selects the
=C2=A0 =C2=A0 =C2=A0 =C2=A0parameters and sometimes the client does, b= ut it's not that
=C2=A0 =C2=A0 =C2=A0 =C2=A0hard to make this code symmetrical.

As I think this through, I am leaning towards (a) but other people'= ;s
opinions on this topic would be welcome.


2. Should we require that PSK cipher suites where the PSK is used for<= /div>
resumption use compatible ciphers? This is the way it was in TLS 1.2
and below for resumption and tickets, but once you have a PSK, that= 9;s
not really necessary [0]. So, for instance, if you had the following
cipher list order:

=C2=A0 =C2=A0 ECDHE + AES-GCM
=C2=A0 =C2=A0 ECDHE + ChaCha/Poly
=C2=A0 =C2=A0 PSK + ChaCha/Poly
=C2=A0 =C2=A0 PSK + AES-GCM

You could potentially negotiate one connection with GCM, use it
to establish a shared key, and then reconnect with ChaCha/Poly.
This seems like it probably should be something we avoid, though
I'm not sure we have a concrete reason why, and it means a
weird special case for PSK. Note that this issue might be
ameliorated some (though not completely) with a la carte negotiation.<= /div>


3. I don't currently have PSK/Resumption + 0-RTT working, because = you
need a way to indicate the expected parameters (see point #1 above).


4. I plan to rewrite the Handshake Protocol Overview (S 6.2)
to be clearer. I hope to do this before submitting -07.

5. Security Considerations is badly out of date, so I plan to
rewrite that soon, but probably not before Prague. I also intend
to do a pretty substantial editorial cleanup pass and potentially
some restructuring after Prague.


As indicated above, this is still a WIP, so no doubt contains
a number of errors, potentially serious ones. Comments and PRs
welcome.

Thanks,
-Ekr


[0] With the exception of cryptographic concerns about the use
of the same IKM with different hash functions for HKDF, but this
is a problem that applies to any use of PSK, not just this one.


--089e011771a9b52c8f051a4b30ee-- From nobody Tue Jul 7 09:08:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198AC1ACDA3 for ; Tue, 7 Jul 2015 09:08:16 -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 CEoIWTPdjNko for ; Tue, 7 Jul 2015 09:08:15 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5621ACDA2 for ; Tue, 7 Jul 2015 09:08:14 -0700 (PDT) Received: by qkei195 with SMTP id i195so143205260qke.3 for ; Tue, 07 Jul 2015 09:08:14 -0700 (PDT) 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=4dJq26p/vc75VMP+36zyurymZgVCRrtGlREiq0U2q+Q=; b=na9PV0OIAo8BK1Wo0s1fGwCekRnWcqHx2nYYIfdtf0iaS9UK7KM127v8c6Yk5h8LHe ce0U9hJC7hBQyf+FuI3ksfVqxWGFkeyaw1QBH08X7tlNOzbIAeA4CTKrKy+iruloij1z 1ztj80nmmJoojabaKfswoiqQ7QdkZ4cXalPJaOz6gMOJZz6q8UBKWMmddT09Bzp8Ni0v +w0R+mRTVb27OvKQGK4HOrIEP+X6ltd2ENhQR/Tnqe6JkTYVBTYMhvubPhEkQSZUaiQf m/Bt6dLoIgInCgtG2soN8wJXhNFnd1wj2HwZk7ikAPlc0FrkU+k1/fvRfps/HQFnwS9R r4zA== X-Received: by 10.55.42.140 with SMTP id q12mr8106560qkq.64.1436285293965; Tue, 07 Jul 2015 09:08:13 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b66sm578376qkh.36.2015.07.07.09.08.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 Jul 2015 09:08:13 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 7 Jul 2015 12:08:11 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507071208.12082.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:08:16 -0000 On Tuesday, July 07, 2015 12:04:45 pm Eric Rescorla wrote: > Since we're trying to model resumption as PSK, I want to run the entire key > schedule for consistency. On that topic, it looks like you have: "{::comment} Describe key schedule {:/comment}" On the end of the file in the current draft. Dave From nobody Tue Jul 7 09:09:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47391ACDBF for ; Tue, 7 Jul 2015 09:09:13 -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 0cL0oS6wFtZg for ; Tue, 7 Jul 2015 09:09:11 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962AF1ACDB2 for ; Tue, 7 Jul 2015 09:09:11 -0700 (PDT) Received: by widjy10 with SMTP id jy10so193344763wid.1 for ; Tue, 07 Jul 2015 09:09:10 -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=oupd/q2CYXLqW1Qte4ki6mVkvL1JmtUXVrtHP55znxc=; b=Cqirqni1cYrAsi7sXUAdixXn5LeWe+uplS/53xSS92AdFwrSsj+RzBu5T/GqvT+Dfu GHDLrwA6mXZ0kDyhgsomndhs9dl7u/ht4pW1519z0ZQl0RsPt5tZXRPNAw6r4wfm4cB1 yfowSIfZCxx1x8QHcFsmKxayaVajYS8JfuA+dL3SYxiOdWscLVA6jbSN4kaJO0S/0chJ 2CIVUoimzBt3PwtamaRLpIZu3ipVKWBlHzQQteGBoDspwQ11r+r7erLMIzeCq0aldOtm Ivt6Ue6pW8zCMM+b9Pq/JbnjICaJg9ItJmxwW22+Rn1wimB9d5jOfvMuqRAFS5ztmxEA Cdtw== X-Gm-Message-State: ALoCoQnJsdi+fIJJgdlWWMzCoQjY+PaxNy4DCV8Bk6/J1kdERGurpY9EhXivkW/op5+2rGYgxeXN X-Received: by 10.180.83.137 with SMTP id q9mr107740902wiy.68.1436285350393; Tue, 07 Jul 2015 09:09:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 7 Jul 2015 09:08:30 -0700 (PDT) In-Reply-To: <201507071054.57330.davemgarrett@gmail.com> References: <201507031925.04809.davemgarrett@gmail.com> <20150707143431.GA853@LK-Perkele-VII> <201507071054.57330.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 7 Jul 2015 09:08:30 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d044401961b5261051a4b3e6c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:09:13 -0000 --f46d044401961b5261051a4b3e6c Content-Type: text/plain; charset=UTF-8 Let's distinguish between two different uses of SHA-1: 1. In certificates. 2. In TLS signatures. I have no problem with insisting that TLS 1.3 not do SHA-1 for signatures in the protocol. However, given that there are lots of SHA-1 certificates in the field and the world is bigger than browsers, it seems like forbidding use of SHA-1 in certificates for TLS 1.3 (while it's still available to TLS 1.2) acts mostly as a disincentive to adoption for TLS 1.3, so I'm currently not in favor of that. -Ekr On Tue, Jul 7, 2015 at 7:54 AM, Dave Garrett wrote: > On Tuesday, July 07, 2015 10:34:31 am Ilari Liusvaara wrote: > > On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote: > > > On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote: > > > > I think we probably need to have WG consensus for the SHA-1 thing. > > > > > > Yes, that's why I left it out of that changeset. I don't think the > > > topic of what to do in the TLS 1.3 spec with SHA1 has been discussed > > > on this list. (if it has, please point me to the thread if someone > > > can) > > > > > > The simplest thing would be to have a MUST NOT offer or negotiate > > > in 2017 or later and a NOT RECOMMENDED to use until then. Or, we > > > could go deeper into the weeds and talk about expiration dates. > > > Banning it totally for TLS 1.3+ is also an option, but probably not > > > wanted yet. > > > > No, the simplest thing would be to ban it entierely: > > - MUST ignore entries with MD5 or SHA1 hash in > > supported_signature_algorithms, even if those are the only > > ones (which will cause handshake failure). > > - MUST terminate connection with insufficient_security if MD5 or > > SHA1 is seen in DigitallySigned.algorithm. > > > > SHA-1 is known to be seriously broken. That is way more than > > enough reason to completely remove it. Especially from new > > standards. > > > > If one wants those to also apply to TLS 1.2, plus: > > - MUST send signature_algorithms extension in TLS 1.2+, > > server MUST terminate connections without it. > > - MUST NOT send MD5 or SHA1 entries in > > supported_signature_algorithms. > > I very much agree that banning it entirely is the ideal route, but there > were indications given that we didn't want to do this, unfortunately. > > Again I'll state: by the time TLS 1.3 is done and actually being adopted, > an assumption of no SHA1 will be even more expected. Servers that are > playing chicken with browsers planning on dropping support for them in a > matter of months can stick to TLS 1.2. > > > Dave > --f46d044401961b5261051a4b3e6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let's distinguish between two different uses of SHA-1:=

1. In certificates.
2. In TLS signatures.

I have no problem with insisting that TLS 1.3 not do = SHA-1 for signatures in
the protocol. However, given that there a= re lots of SHA-1 certificates in the
field and the world is bigge= r than browsers, it seems like forbidding use of
SHA-1 in certifi= cates for TLS 1.3 (while it's still available to TLS 1.2) acts
mostly as a disincentive to adoption for TLS 1.3, so I'm currently no= t in
favor of that.

-Ekr

<= /div>


On Tue, Jul 7, 2015 at 7:54 AM, Dave Garrett <= davemgarrett@gm= ail.com> wrote:
On Tuesday, July 07, 2015 10:34:31 am Ilari L= iusvaara wrote:
> On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote:
> > On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote:
> > > I think we probably need to have WG consensus for the SHA-1 = thing.
> >
> > Yes, that's why I left it out of that changeset. I don't = think the
> > topic of what to do in the TLS 1.3 spec with SHA1 has been discus= sed
> > on this list. (if it has, please point me to the thread if someon= e
> > can)
> >
> > The simplest thing would be to have a MUST NOT offer or negotiate=
> > in 2017 or later and a NOT RECOMMENDED to use until then. Or, we<= br> > > could go deeper into the weeds and talk about expiration dates. > > Banning it totally for TLS 1.3+ is also an option, but probably n= ot
> > wanted yet.
>
> No, the simplest thing would be to ban it entierely:
> - MUST ignore entries with MD5 or SHA1 hash in
>=C2=A0 =C2=A0supported_signature_algorithms, even if those are the only=
>=C2=A0 =C2=A0ones (which will cause handshake failure).
> - MUST terminate connection with insufficient_security if MD5 or
>=C2=A0 =C2=A0SHA1 is seen in DigitallySigned.algorithm.
>
> SHA-1 is known to be seriously broken. That is way more than
> enough reason to completely remove it. Especially from new
> standards.
>
> If one wants those to also apply to TLS 1.2, plus:
> - MUST send signature_algorithms extension in TLS 1.2+,
>=C2=A0 =C2=A0server MUST terminate connections without it.
> - MUST NOT send MD5 or SHA1 entries in
>=C2=A0 =C2=A0supported_signature_algorithms.

I very much agree that banning it entirely is the ideal route, = but there were indications given that we didn't want to do this, unfort= unately.

Again I'll state: by the time TLS 1.3 is done and actually being adopte= d, an assumption of no SHA1 will be even more expected. Servers that are pl= aying chicken with browsers planning on dropping support for them in a matt= er of months can stick to TLS 1.2.


Dave

--f46d044401961b5261051a4b3e6c-- From nobody Tue Jul 7 09:11:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803491A9060 for ; Tue, 7 Jul 2015 09:11:03 -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 Wg1u5VPrO2x8 for ; Tue, 7 Jul 2015 09:10:58 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A40E1A8F46 for ; Tue, 7 Jul 2015 09:10:56 -0700 (PDT) Received: by wiga1 with SMTP id a1so261365894wig.0 for ; Tue, 07 Jul 2015 09:10:55 -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=mrXg7u+9tdjAIzG+NpPUv4FyYLF/NeC9lXGSUxJ7S9s=; b=QDJVtjGTywSesxjnXgWmdcRHYewJjt254CGqvE7Ai7ITmBHLqDhWDEid0C8zQOPkIE AEZ5Ty5JFPsbDfj7SjS30runE4nEBT64jXVNNjQuAdIkl3zjlFJOcC4VeYkEb+RUHw6u 0yNUuj9rRCvFOs7fBiAToUK+4rLA8epMKLV2E6GpgH9nJcjsgf0D958PUj6wZkAZoO5u iKH9gvbHXH33UKDHommOIgq+/6QSG9zYM+KjcN3dGSiRJG74h1OitQ1DMX22hdjcQ9Jo lxfuQ4hU+MXz3bDOKs23h3SKO7yS03+/fG2T/uGK9AlbG4go6sLZEuVi21wF8M40aseq 6uhA== X-Gm-Message-State: ALoCoQlHvmskIcUdv54Yq8LZndtt5Yp3ZBqttvthl5CB1RpEw5cy6sTklP3kI19hSNpSnkYcKjj2 X-Received: by 10.194.158.42 with SMTP id wr10mr9695728wjb.81.1436285455213; Tue, 07 Jul 2015 09:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 7 Jul 2015 09:10:15 -0700 (PDT) In-Reply-To: <201507071135.00448.davemgarrett@gmail.com> References: <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> <20522301ad4047bf8a9e3794fd785da9@ustx2ex-dag1mb2.msg.corp.akamai.com> <201507071135.00448.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 7 Jul 2015 09:10:15 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e013c64785abdb1051a4b443c Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:11:03 -0000 --089e013c64785abdb1051a4b443c Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 8:35 AM, Dave Garrett wrote: > On Tuesday, July 07, 2015 10:57:24 am Salz, Rich wrote: > > > Putting aside the timeline for retiring SHA-1 from certificates, which > will > > > happen sooner than later, I think we should ban MD5 and SHA1 from > client > > > and server signatures in TLS 1.3. > > > > Strongly in favor. I see no reason why a new protocol should ever use > SHA1. > > Good. There seems to be strong support all around for this. I've updated > the PR to drop SHA1 too. > > PR: > https://github.com/tlswg/tls13-spec/pull/188/files > Issue: > https://github.com/tlswg/tls13-spec/issues/186 This PR seems to prohibit use of SHA-1 for certificates as well, which I'm not sure is wise. I suggest we put this on the agenda for Prague. -Ekr > > I also have a mandatory extensions patch here: > > https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions > > I'll probably just submit a PR for that too in a bit. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e013c64785abdb1051a4b443c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 7, 2015 at 8:35 AM, Dave Garrett <davemgarrett@gmail.= com> wrote:
On Tuesday, Jul= y 07, 2015 10:57:24 am Salz, Rich wrote:
> > Putting aside the timeline for retiring SHA-1 from certificates, = which will
> > happen sooner than later, I think we should ban MD5 and SHA1 from= client
> > and server signatures in TLS 1.3.
>
> Strongly in favor.=C2=A0 I see no reason why a new protocol should eve= r use SHA1.

Good. There seems to be strong support all around for this. I've update= d the PR to drop SHA1 too.

PR:
https://github.com/tlswg/tls13-spec/pull/188/files=
Issue:
https://github.com/tlswg/tls13-spec/issues/186

This PR seems to prohibit use of SHA-1 for cer= tificates as well, which I'm not sure
is wise. I suggest we p= ut this on the agenda for Prague.

-Ekr
= =C2=A0

I also have a mandatory extensions patch here:
https://g= ithub.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryext= ensions

I'll probably just submit a PR for that too in a bit.


Dave

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

--089e013c64785abdb1051a4b443c-- From nobody Tue Jul 7 09:14:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1761ACDC7 for ; Tue, 7 Jul 2015 09:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 aH_JF_s5Tx_q for ; Tue, 7 Jul 2015 09:14:00 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id EAFB61ACDB2 for ; Tue, 7 Jul 2015 09:13:59 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 639D8169BFE; Tue, 7 Jul 2015 16:13:59 +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 4DAFA169BFB; Tue, 7 Jul 2015 16:13:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436285639; bh=ZlJshVcDJ4gequw+rFA8LRfrGlakgUItriPptKaDt6I=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ve+AhWrhvVUHhzu/Yt2BMkiLqyJLytBn5b0vNtvjZcZpsKZAwJpbG4xkPqVD5Vehw 8DeqmFixp2lWnR8g/bMxj6M5LqurSXBmvgKDPhdzhkGd7LFWMlUiRSC2MZsdBt5m/u vs0sBqYY4Rtjxt5v7cv/HbzA6/fwiXvsSKpHTf8U= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 488B31E07C; Tue, 7 Jul 2015 16:13:59 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 11:13:57 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Tue, 7 Jul 2015 11:13:57 -0500 From: "Salz, Rich" To: Eric Rescorla , Dave Garrett Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqBnytZJHwlb02fn+qYqTOau53QgQ6A//+s1zA= Date: Tue, 7 Jul 2015 16:13:57 +0000 Message-ID: <932b567894524e17ae4b6631454f546e@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> <20522301ad4047bf8a9e3794fd785da9@ustx2ex-dag1mb2.msg.corp.akamai.com> <201507071135.00448.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:14:02 -0000 PiBUaGlzIFBSIHNlZW1zIHRvIHByb2hpYml0IHVzZSBvZiBTSEEtMSBmb3IgY2VydGlmaWNhdGVz IGFzIHdlbGwsIHdoaWNoIEknbSBub3Qgc3VyZQ0KPiBpcyB3aXNlLiBJIHN1Z2dlc3Qgd2UgcHV0 IHRoaXMgb24gdGhlIGFnZW5kYSBmb3IgUHJhZ3VlLg0KDQpZZXMsIEkgZGlkbid0IGludGVuZCB0 byBvdXRsYXcgU0hBMSBjZXJ0czsgcGVyaGFwcyBhIGJpdCBtb3JlIGZpbmVzc2UgaXMgcmVxdWly ZWQuOikgDQo= From nobody Tue Jul 7 09:16:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285791A8A12 for ; Tue, 7 Jul 2015 09:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 twlOHHkZIffw for ; Tue, 7 Jul 2015 09:16:31 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4711ACDB2 for ; Tue, 7 Jul 2015 09:16:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,424,1432591200"; d="scan'208";a="139266425" Received: from pool-71-161-84-157.cncdnh.east.myfairpoint.net (HELO [192.168.0.100]) ([71.161.84.157]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 18:16:07 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Karthikeyan Bhargavan In-Reply-To: <932b567894524e17ae4b6631454f546e@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Tue, 7 Jul 2015 12:16:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13D8AA16-046E-45C4-8D4B-A3C8CC6349D2@gmail.com> References: <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> <20522301ad4047bf8a9e3794fd785da9@ustx2ex-dag1mb2.msg.corp.akamai.com> <201507071135.00448.davemgarrett@gmail.com> <932b567894524e17ae4b6631454f546e@ustx2ex-dag1mb2.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:16:33 -0000 > Let's distinguish between two different uses of SHA-1: >=20 > 1. In certificates. > 2. In TLS signatures. I was recommending getting rid of (2). Getting rid of (1) would be nice, but I gather it relies on developments = outside TLS. > On 07 Jul 2015, at 12:13, Salz, Rich wrote: >=20 >> This PR seems to prohibit use of SHA-1 for certificates as well, = which I'm not sure >> is wise. I suggest we put this on the agenda for Prague. >=20 > Yes, I didn't intend to outlaw SHA1 certs; perhaps a bit more finesse = is required.:)=20 From nobody Tue Jul 7 09:31:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4BA1ACE2C for ; Tue, 7 Jul 2015 09:31:52 -0700 (PDT) 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 l43J9oFJ7GCi for ; Tue, 7 Jul 2015 09:31:49 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD54C1ACDF3 for ; Tue, 7 Jul 2015 09:31:49 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 814059002B; Tue, 7 Jul 2015 19:31:47 +0300 (EEST) Date: Tue, 7 Jul 2015 19:31:47 +0300 From: Ilari Liusvaara To: Karthikeyan Bhargavan Message-ID: <20150707163147.GA3550@LK-Perkele-VII> References: <7D0FA086-F797-4B11-B5DE-6D202DEF8001@gmail.com> <20522301ad4047bf8a9e3794fd785da9@ustx2ex-dag1mb2.msg.corp.akamai.com> <201507071135.00448.davemgarrett@gmail.com> <932b567894524e17ae4b6631454f546e@ustx2ex-dag1mb2.msg.corp.akamai.com> <13D8AA16-046E-45C4-8D4B-A3C8CC6349D2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <13D8AA16-046E-45C4-8D4B-A3C8CC6349D2@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:31:52 -0000 On Tue, Jul 07, 2015 at 12:16:04PM -0400, Karthikeyan Bhargavan wrote: > > Let's distinguish between two different uses of SHA-1: > > > > 1. In certificates. > > 2. In TLS signatures. > > I was recommending getting rid of (2). > Getting rid of (1) would be nice, but I gather it relies on > developments outside TLS. Well, for "public" CA system, one can't get SHA-1 certs after this year, neither Chrome nor Firefox accept those and Chrome reacts rather badly to SHA-1 certs with expiration in 2017 or later. (Of course, this is just WebPKI, and there is plenty of other stuff too). And I don't think it is at all clear which of (1) or (2) is actually worse for security (I think (1)). -Ilari From nobody Tue Jul 7 09:42:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392591ACE69 for ; Tue, 7 Jul 2015 09:42:27 -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 A4AIGiAP4lMT for ; Tue, 7 Jul 2015 09:42:25 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3411ACE40 for ; Tue, 7 Jul 2015 09:42:25 -0700 (PDT) Received: by qgef3 with SMTP id f3so37061071qge.0 for ; Tue, 07 Jul 2015 09:42:24 -0700 (PDT) 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=UqH/d5q97C8LM2XANiE0zapoiqeOBOfuwGK1A4fpfOM=; b=kXrrA6yUN/5TTrXLYm8p0GLHcAHQqKS5P79aqyChaMP1oBzAUlGuygUAh/2q6ftTv3 TNCiRDPWt43+PwVoK0ajV96leKS/KnIIgzhmIpQyXzYS74YpVyHIrfwu6AIr/iIckTya 7x1ayS5E11F8IDKZpUQVN7HCPuUIOBTAIAdtIKHCKSQSHJWx2i/kBngmM/n4dLca2NEi KA9ItXthZzEqW7INulo3Ay5wsXcnoe8U8ghbhQUTK+wbkPxbr1d3B3uxx65Lk30l46Xd RPrfAptnt1DXq6lieMOM1en1rURMWGHhQtI6/UEW9Y6gUfWnoKwq4keKjbx1K0sNfmTj KYlg== X-Received: by 10.140.129.130 with SMTP id 124mr8711580qhb.28.1436287344760; Tue, 07 Jul 2015 09:42:24 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 70sm11372399qhe.12.2015.07.07.09.42.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 Jul 2015 09:42:24 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Tue, 7 Jul 2015 12:42:22 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507071135.00448.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507071242.23235.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:42:27 -0000 On Tuesday, July 07, 2015 12:08:30 pm Eric Rescorla wrote: > Let's distinguish between two different uses of SHA-1: > > 1. In certificates. > 2. In TLS signatures. > > I have no problem with insisting that TLS 1.3 not do SHA-1 for signatures in > the protocol. However, given that there are lots of SHA-1 certificates in the > field and the world is bigger than browsers, it seems like forbidding use of > SHA-1 in certificates for TLS 1.3 (while it's still available to TLS 1.2) acts > mostly as a disincentive to adoption for TLS 1.3, so I'm currently not in > favor of that. On Tuesday, July 07, 2015 12:10:15 pm Eric Rescorla wrote: > On Tue, Jul 7, 2015 at 8:35 AM, Dave Garrett wrote: > > PR: > > https://github.com/tlswg/tls13-spec/pull/188/files > > Issue: > > https://github.com/tlswg/tls13-spec/issues/186 > > This PR seems to prohibit use of SHA-1 for certificates as well, which I'm > not sure is wise. I suggest we put this on the agenda for Prague. How does it prohibit SHA1 in certs? The commit message might be unclear, but it only modifies the signature algorithms extension. Dave From nobody Tue Jul 7 09:57:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BF71ACE80 for ; Tue, 7 Jul 2015 09:57:30 -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 gs5j6TTVbOow for ; Tue, 7 Jul 2015 09:57:28 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346171A9117 for ; Tue, 7 Jul 2015 09:57:28 -0700 (PDT) Received: by qkei195 with SMTP id i195so144257139qke.3 for ; Tue, 07 Jul 2015 09:57:27 -0700 (PDT) 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=RvJyWDqTcfWYnFo84FG6KVmzYr8SvxYqgNAQiuTqPGo=; b=bxaL2XmaTXSFN2CMxdnUBGPxV7IjiEDuqq6nVPFlCRJR1Nv3gyuwF8JOltqmCXjvYD dGPMdUVPMO3xSxvLx+HBFaPEE1bXqwAHCesrMdOqMd1Gn01K1YM/H8BaB24pRh8CdT3/ AdsdDJ2F6VvEpYVU4kW6S/FZuq9Kb8ABAvmp5wXMN4rwbisJk1wl0EVHUuqGObCcpPrc DMHk1Jiy/Bgs1lGcVyxhtfiL7uc4+eKluySXnSRAAZQsYSIiwmoFDwnQlgy3OpeKxMI9 0Nv5DrgNWWR0Y3GTvyL3DpvTkhsS3vLC2qUHWhNDJQPDpEuo+2NJKEYLuDv3BBD/3ACl Uufw== X-Received: by 10.140.107.180 with SMTP id h49mr8413423qgf.1.1436288247531; Tue, 07 Jul 2015 09:57:27 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id a3sm5278160qga.47.2015.07.07.09.57.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 Jul 2015 09:57:27 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Tue, 7 Jul 2015 12:57:25 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507071242.23235.davemgarrett@gmail.com> In-Reply-To: <201507071242.23235.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507071257.26088.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 16:57:30 -0000 On Tuesday, July 07, 2015 12:42:22 pm Dave Garrett wrote: > How does it prohibit SHA1 in certs? The commit message might be unclear, but it only modifies the signature algorithms extension. The relevant commit with a fixed message: https://github.com/davegarrett/tls13-spec/commit/56e481f19ed4d2ed374a6fb6e24a66637eb07b3c Dave From nobody Tue Jul 7 10:46:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8C81ACEF1 for ; Tue, 7 Jul 2015 10:46:07 -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 fqyga4iNoVc9 for ; Tue, 7 Jul 2015 10:46:06 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12531ACEEB for ; Tue, 7 Jul 2015 10:46:05 -0700 (PDT) Received: by widjy10 with SMTP id jy10so195634767wid.1 for ; Tue, 07 Jul 2015 10:46:04 -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=GpJC7Tlqjyq1q4BsO5THq++X6CaNTiDUln+hWvh7oFg=; b=jEZ79vNm/I/56T8urlgK19Cx4p5YxEH/ubc/OyLDR7myVX+hgxH3N38yypOWyq7dzo Qk7vFAsq/RwoelmhGT+R5dQ/UcW52OXN9YfrdvJhFaQqe8LAr9ezP2MLWvikRwHxEGPT uHvJmfoNCEAGGq+XWqC+lRWKeEMmC1/oQ6ZeItJYH3BcplJwSYZ9TZ5LpPpxQLqQXHsA tlEqhgM/h+ywSz7mZELFzQuZpT3O68XAo1rluMwLNAI5FgMV41bcbQ8dq5mOD9lFYaW1 cu92+nuGxObWJGOFAX7q9serSKyjSTrofOPQ093++w77GQU39XjYbesosw35Uv+4p7W6 Fzkg== X-Gm-Message-State: ALoCoQkcY0scUZwf0klKl8GNrSxJD1ZbP8dXDXST3dfmUQU2o/kFaLvjFQyLzSbQrWIBv2DlcQCi X-Received: by 10.180.99.39 with SMTP id en7mr105163692wib.31.1436291164686; Tue, 07 Jul 2015 10:46:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 7 Jul 2015 10:45:25 -0700 (PDT) In-Reply-To: <201507071257.26088.davemgarrett@gmail.com> References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 7 Jul 2015 10:45:25 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d04182808aa5f8b051a4c98f9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 17:46:07 -0000 --f46d04182808aa5f8b051a4c98f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2015 at 9:57 AM, Dave Garrett wrote= : > On Tuesday, July 07, 2015 12:42:22 pm Dave Garrett wrote: > > How does it prohibit SHA1 in certs? The commit message might be unclear= , > but it only modifies the signature algorithms extension. > > The relevant commit with a fixed message: > > > https://github.com/davegarrett/tls13-spec/commit/56e481f19ed4d2ed374a6fb6= e24a66637eb07b3c http://tlswg.github.io/tls13-spec/#server-certificate: If the client provided a =E2=80=9Csignature_algorithms=E2=80=9D extension, = then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). So if you can't express SHA1 in signature_algorithms, then the server can't send you a certificate signed with SHA-1. -Ekr > Dave > --f46d04182808aa5f8b051a4c98f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 7, 2015 at 9:57 AM, Dave Garrett <davemgarrett@gmail.= com> wrote:
On Tuesday, = July 07, 2015 12:42:22 pm Dave Garrett wrote:
> How does it prohibit SHA1 in certs? The commit message might be unclea= r, but it only modifies the signature algorithms extension.

The relevant commit with a fixed message:

https://git= hub.com/davegarrett/tls13-spec/commit/56e481f19ed4d2ed374a6fb6e24a66637eb07= b3c

If the client provided a =E2=80=9Csignature_algorithms=E2= =80=9D extension, then all certificates provided by the server MUST be sign= ed by a hash/signature algorithm pair that appears in that extension. Note = that this implies that a certificate containing a key for one signature alg= orithm MAY be signed using a different signature algorithm (for instance, a= n RSA key signed with a DSA key).

So if you can't = express SHA1 in signature_algorithms, then the server can't send you a = certificate signed with SHA-1.

-Ekr

=

Dave

--f46d04182808aa5f8b051a4c98f9-- From nobody Tue Jul 7 11:22:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC201A1A79 for ; Tue, 7 Jul 2015 11:22:52 -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 sIK2jbrzbOLY for ; Tue, 7 Jul 2015 11:22:49 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804FA1A1A7F for ; Tue, 7 Jul 2015 11:22:49 -0700 (PDT) Received: by qget71 with SMTP id t71so88456310qge.2 for ; Tue, 07 Jul 2015 11:22:48 -0700 (PDT) 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=Rc0cOM076zTNXxV3eAKW9f6sAxHvfnljhusUx0G4l1w=; b=r8pcV8PtPli1qopfIo6ge7k8kxJfeYLqtVj0hMwTbVLpwUqu1n1i7I0imMQrk9Kwzg QO5bA91sL5JyIgoc4m8bKYEP9KBB8KEWVdd0GHmkRWmtYryzuNWLOgzwBD9IjF6tjrjl hlugXG8UHic3Onr4UfGhFTKMTGpbRMmuVPZEAbDVc4U3QYaVtyjR2NcWenW0uLuCq7Dy zSffuLVik8QiDirStKo5DdedzGJaoSDn1ByLQFI6dgH8Q+zfLd+Tye+U4z99sixCqkW6 1ifgA4PHDE+HwPiT8pI+cK0Gdp+ulPH13zHjLbWCIIC/8L9BjnRGDC9SPySfZ8RN6v4O Hqnw== X-Received: by 10.140.31.74 with SMTP id e68mr8867843qge.95.1436293368749; Tue, 07 Jul 2015 11:22:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id z71sm11582902qkz.16.2015.07.07.11.22.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 Jul 2015 11:22:48 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Tue, 7 Jul 2015 14:22:46 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507071257.26088.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201507071422.47073.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 18:22:52 -0000 On Tuesday, July 07, 2015 01:45:25 pm Eric Rescorla wrote: > http://tlswg.github.io/tls13-spec/#server-certificate: > If the client provided a =E2=80=9Csignature_algorithms=E2=80=9D extension= , then all > certificates provided by the server MUST be signed by a hash/signature > algorithm pair that appears in that extension. Note that this implies that > a certificate containing a key for one signature algorithm MAY be signed > using a different signature algorithm (for instance, an RSA key signed wi= th > a DSA key). > > So if you can't express SHA1 in signature_algorithms, then the server can= 't > send you a certificate signed with SHA-1. Hmm... well, we could state a special case that SHA-1 within some restricte= d use-case is permitted in certs, but this could quickly become messy. Just= axing it all would be better, but yeah, that's a larger change than origin= ally intended. Dave From nobody Tue Jul 7 13:59:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4671ACCE5 for ; Tue, 7 Jul 2015 13:59:01 -0700 (PDT) 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 LWhss17mn5jG for ; Tue, 7 Jul 2015 13:59:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D911ACC8A for ; Tue, 7 Jul 2015 13:58:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0A0E4284D68; Tue, 7 Jul 2015 20:58:59 +0000 (UTC) Date: Tue, 7 Jul 2015 20:58:59 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150707205858.GH21534@mournblade.imrryr.org> References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Tue, 07 Jul 2015 20:59:01 -0000 On Tue, Jul 07, 2015 at 10:45:25AM -0700, Eric Rescorla wrote: > So if you can't express SHA1 in signature_algorithms, then the server can't > send you a certificate signed with SHA-1. This is a very unfamiliar use of the word "can't". In practice most servers will send whatever (fixed) certificate chain they're configured with, no matter the content of the signature_algorithm extension. Servers that possess otherwise equivalent chains that differ only in the signature algorithm are rather rare beasts AFAIK. Which SSL libraries allow server administrators to configure multiple chains based on the signature algorithm? Which SSL libraries allow clients to configure multiple chains and present the appropriate one to the server based on signature algorithm? My impression is that chain selection based on the extension is largely wishful thinking. -- Viktor. From nobody Tue Jul 7 16:01:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47031B2A0F for ; Tue, 7 Jul 2015 16:01:12 -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 d-MzMh0iscYk for ; Tue, 7 Jul 2015 16:01:11 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CF11A1A98 for ; Tue, 7 Jul 2015 16:01:07 -0700 (PDT) Received: by ykeo3 with SMTP id o3so71576280yke.0 for ; Tue, 07 Jul 2015 16:01:07 -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 :content-type; bh=2LAuPN0htdWQwlcK7y4XLnHgnajBnMwUA84BBT9oxZg=; b=P0PxDr+dP7f7EZEG/BNmTVy9yRVINk2xIYu2ZLzfaF2Mql9gUvNPek+Wog/0OW437o zOuLYWvpbNheL/emoOiRJGj8h7krJR5i4u4Rk1mBjvocpQDQs0Rf6jZ6Bg/HuQ68keIR ZzLEMvtGfd30G24Q3FZpEZ4RI8itq/1ZrPegkXQX/A3kVZxIGNxSF26wnsWsJ0gt30mq 21NSYWpy0WAU69xHJ4vAJwL1B1nnnYpXrLpkPQFMdHb2Np9UdalcOfSAzZLU3I732/kR IPaHO3c5bTl0EY+JrAnPNT/W4sUnq6IlKJaxVno+/AQAyw3hgVrA6upaHL1dLhJSfS45 VE6A== MIME-Version: 1.0 X-Received: by 10.170.131.198 with SMTP id x189mr7728745ykb.118.1436310067069; Tue, 07 Jul 2015 16:01:07 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 7 Jul 2015 16:01:07 -0700 (PDT) In-Reply-To: <20150707205858.GH21534@mournblade.imrryr.org> References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> Date: Tue, 7 Jul 2015 16:01:07 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2015 23:01:12 -0000 On 7 July 2015 at 13:58, Viktor Dukhovni wrote: > Which SSL libraries allow server administrators to configure multiple > chains based on the signature algorithm? I just investigated this earlier today. NSS maintains separate certificates keyed on the signature algorithm and selects based on the cipher suite, though this does not consider the hash part of the signature algorithm pair. That's the server end; the client side is far less capable (though I have a patch in progress that would enable what you describe). From nobody Tue Jul 7 18:55:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B71D1B2D0C for ; Tue, 7 Jul 2015 18:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 qGmRzPPWohSR for ; Tue, 7 Jul 2015 18:55:39 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0661B2D09 for ; Tue, 7 Jul 2015 18:55:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5620C28DFE; Wed, 8 Jul 2015 01:55:36 +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 383BA28DFC; Wed, 8 Jul 2015 01:55:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436320536; bh=oFN5roheE+4Z+kWwMx+TFKwIABNPDCBlfDl9Fb3L5vA=; h=From:To:Subject:Date:References:In-Reply-To:From; b=RAzN4Q+ppjtitOKdXKhg2zQtfW4tZIE633ZYrjGg91q9qByAL+PrN5CWQy8meHRt8 QKT2D4uoRl77CUaulzocJHyf4c7vrSWuOED/LhJzH7CXPkL8zjrRIFwh6xfJpjlAkT M5rPBARqr/fA/a5HsGw0xzU9nTROW8+YEfuD7cg4= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 218FB80084; Wed, 8 Jul 2015 01:55:36 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 20:55:35 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Tue, 7 Jul 2015 20:55:35 -0500 From: "Salz, Rich" To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqBnytZJHwlb02fn+qYqTOau53QgQ6AgAAI+QCAAAQ0gIAADWqAgAA2FYCAACIfgP//3B2w Date: Wed, 8 Jul 2015 01:55:35 +0000 Message-ID: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 01:55:40 -0000 > On 7 July 2015 at 13:58, Viktor Dukhovni wrote: > > Which SSL libraries allow server administrators to configure multiple > > chains based on the signature algorithm? >=20 > I just investigated this earlier today. NSS maintains separate certifica= tes boringSSL does it, too. They have an early callback that presents the enti= re parsed clientHello message, and allows the server to unify SNI, cipher-s= uite, and cert assignment all at once. I'm going to bring that feature int= o the next OpenSSL release, along with unified extension handling. Agreed, nobody cares much about the client side. From nobody Wed Jul 8 07:38:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C981B36EF; Wed, 8 Jul 2015 07:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=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 INk1YIkZUsNI; Wed, 8 Jul 2015 07:38:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 200201B36E3; Wed, 8 Jul 2015 07:38:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708143839.25395.62187.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 07:38:39 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-tls13-07.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, 08 Jul 2015 14:38:40 -0000 --NextPart 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 : The Transport Layer Security (TLS) Protocol Version 1.3 Author(s) : E. Rescorla Filename : draft-ietf-tls-tls13 Pages : 98 Date : 2015-07-08 This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-tls13"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2015-07-08073839.I-D@ietf.org> --NextPart-- From nobody Wed Jul 8 07:41:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54A21B3703 for ; Wed, 8 Jul 2015 07:41:39 -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 DmdISt5t0Ul9 for ; Wed, 8 Jul 2015 07:41:37 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B731B36F9 for ; Wed, 8 Jul 2015 07:41:36 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so214987997wib.1 for ; Wed, 08 Jul 2015 07:41:35 -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:from:date:message-id:subject:to :content-type; bh=83fDCp6N4QuicRpk7lzn1rts6vfVTDffv1InRjBpg1Q=; b=bMnCDSjmVojJyI3pADsT7bJWZl7Ro53HBFI+mVSbxqse4e0k9WhNEqrQ/9XkNDSN8t x8WSmGw3fg+jyfMkZVSj+cVU2L9+JFWx4o8WmUDErT+pDaWCPmvf/CsPe+tbjyPKBips UHI4soxaIj3mxPRM/qYv9VbTq0ZxCfpODdKCKEssWlherA5YScNebsZwSXYpAcMJuDlg 3G6J2SaYjkS7JkB5kgUUeNQFI6W9jhunlg9viXlaivf+rasM6N6gCqgovfzPEdFNgqWF RDuiO4PVnqmZ5EC1WufI4X6OOs1fPtBbKFiwe4cVrZBF+guaa61YI+slJQrGEhv9d565 BfTQ== X-Gm-Message-State: ALoCoQl/v6qysuWIUiZ9QMegAU1YVfkW1fd6GvWNSE1jhu2Es6SE4ToglYzdJ0rtgzlOosoJqW4M X-Received: by 10.180.99.39 with SMTP id en7mr114434757wib.31.1436366495514; Wed, 08 Jul 2015 07:41:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Wed, 8 Jul 2015 07:40:56 -0700 (PDT) From: Eric Rescorla Date: Wed, 8 Jul 2015 07:40:56 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04182808bb9711051a5e224b Archived-At: Subject: [TLS] TLS 1.3 draft-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 14:41:40 -0000 --f46d04182808bb9711051a5e224b Content-Type: text/plain; charset=UTF-8 As you probably expected from (https://www.ietf.org/mail-archive/web/tls/current/msg16881.html) I've just posted draft-07. This version is the result of a bunch of work in the the background, with Hugo, Hoeteck, Karthik, and others to develop a new draft using semi-ephemeral DH based on Hugo's ideas as discussed in Dallas. I've provided a summary of the major changes and open issues below and I expect to go over them in detail in Prague. Remember, this is a WIP with a lot of changes, so if you see something wrong, don't panic, but do let me know. CHANGES 1. Move ClientKeyShare into an extension so that the ClientHello is the only message in the client's first flight. This removes a bunch of ugliness around the "early_data" extension which could encapsulate handshake and application data. 2. Added a mechanism for the server to indicate a known (EC)DHE key/configuration which the client can then use in subsequent handshakes (via the known_configuration extension). The net effect here is that the client and server can skip over the signature in subsequent handshakes, which provides benefit when signatures are much slower than key exchange, as with RSA; it also enables 0-RTT. 3. Added support for 0-RTT data, both with and without client authentication. 4. Removed most of the support for resumption in favor of a mechanism proposed by Karthik where you just establish a PSK in connection N which you then use to key a PSK cipher suite in connection N+1. All of these keying mechanisms use a unified key schedule based on two keys the "Ephemeral Secret" (ES) and the "Static Secret" (SS). Depending on the exact handshake type, these may be equal, but the logic is the same regardless. In the process, I also converted the key schedule to use HKDF (per WG consensus). OPEN ISSUES There are still a number of known open issues to discuss: 1. The present known_configuration mechanism allows the client to resurrect the handshake parameters (though not the keys) which were negotiated in a previous handshake, but this is done implicitly, i.e., the server provides a label and the client returns it on the next connection. This has the advantage of keeping things short but the disadvantage the it means that you can't have a static configuration ID for everyone (instead, the server has to somehow embed the properties in the configuration ID). I'm not that satisfied with the present design and there are (at least) three potential alternative designs: (a) Have the client indicate in his first flight "these are the parameters I expect you to negotiate", along with the configuration identifier, based on what the server negotiated the previous time. [Optionally, the server can run the same negotiation locally and abort on mismatch.] (b) As in (a) but with no indication of the expected parameters, just the configuration ID, and the client just preemptively uses the parameters from the last time and if the negotiation ends up differently, all the data is undecryptable (ugh) and you somehow fall back. (c) Have the server provide a preference list in his ServerConfiguration (this can be the same as in the ClientHello) and have the client do the negotiation based on that rather than the server (as in QUIC). This is a little odd in that it means that sometimes the server selects the parameters and sometimes the client does, but it's not that hard to make this code symmetrical. As I think this through, I am leaning towards (a) but other people's opinions on this topic would be welcome. Expect a mesage about this shortly. 2. Should we require that PSK cipher suites where the PSK is used for resumption use compatible ciphers? This is the way it was in TLS 1.2 and below for resumption and tickets, but once you have a PSK, that's not really necessary [0]. So, for instance, if you had the following cipher list order: ECDHE + AES-GCM ECDHE + ChaCha/Poly PSK + ChaCha/Poly PSK + AES-GCM You could potentially negotiate one connection with GCM, use it to establish a shared key, and then reconnect with ChaCha/Poly. This seems like it probably should be something we avoid, though I'm not sure we have a concrete reason why, and it means a weird special case for PSK. Note that this issue might be ameliorated some (though not completely) with a la carte negotiation. 3. I don't currently have PSK/Resumption + 0-RTT working, because you need a way to indicate the expected parameters (see point #1 above). 4. Security Considerations is badly out of date, so I plan to rewrite that soon, but probably not before Prague. I also intend to do a pretty substantial editorial cleanup pass and potentially some restructuring after Prague. As indicated above, this is a pretty major revision, so is still kind of a hard hat area and no doubt contains a number of errors, potentially serious ones (as well as a big pile of TODOs). Comments and PRs welcome. Thanks, -Ekr [0] With the exception of cryptographic concerns about the use of the same IKM with different hash functions for HKDF, but this is a problem that applies to any use of PSK, not just this one. --f46d04182808bb9711051a5e224b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As you probably expected from=C2=A0
(https://www.ietf.org/mail-archive/web/tls/current/msg16881= .html)
I've just posted draft-07.

This version is the result of a bunch of work in the the background,
with Hugo, Hoeteck, Karthik, and others to develop a new draft using<= /div>
semi-ephemeral DH based on Hugo's ideas as discussed in Dalla= s.=C2=A0 I've
provided a summary of the major changes and ope= n issues below and I
expect to go over them in detail in Prague. = Remember, this is a WIP with
a lot of changes, so if you see some= thing wrong, don't panic, but do let me
know.

<= /div>

CHANGES
1. Move ClientKeyShare into an e= xtension so that the ClientHello
=C2=A0 =C2=A0is the only message= in the client's first flight. This removes
=C2=A0 =C2=A0a bu= nch of ugliness around the "early_data" extension which
=C2=A0 =C2=A0could encapsulate handshake and application data.
<= br>
2. Added a mechanism for the server to indicate a known (EC)D= HE
=C2=A0 =C2=A0key/configuration which the client can then use i= n subsequent
=C2=A0 =C2=A0handshakes (via the known_configuration= extension). The net
=C2=A0 =C2=A0effect here is that the client = and server can skip over the
=C2=A0 =C2=A0signature in subsequent= handshakes, which provides benefit
=C2=A0 =C2=A0when signatures = are much slower than key exchange, as with
=C2=A0 =C2=A0RSA; it a= lso enables 0-RTT.

3. Added support for 0-RTT data= , both with and without
=C2=A0 =C2=A0client authentication.
=

4. Removed most of the support for resumption in favor = of
=C2=A0 =C2=A0a mechanism proposed by Karthik where you just es= tablish
=C2=A0 =C2=A0a PSK in connection N which you then use to = key a PSK
=C2=A0 =C2=A0cipher suite in connection N+1.
=
All of these keying mechanisms use a unified key schedule ba= sed on two
keys the "Ephemeral Secret" (ES) and the &qu= ot;Static Secret"
(SS). Depending on the exact handshake typ= e, these may be equal, but
the logic is the same regardless. In t= he process, I also converted
the key schedule to use HKDF (per WG= consensus).


OPEN ISSUES
= There are still a number of known open issues to discuss:

1. The present known_configuration mechanism allows the client to
resurrect the handshake parameters (though not the keys) which wer= e
negotiated in a previous handshake, but this is done implicitly= , i.e.,
the server provides a label and the client returns it on = the next
connection. This has the advantage of keeping things sho= rt but the
disadvantage the it means that you can't have a st= atic configuration
ID for everyone (instead, the server has to so= mehow embed the
properties in the configuration ID). I'm not = that satisfied with the
present design and there are (at least) t= hree potential alternative
designs:

=C2= =A0 =C2=A0(a) Have the client indicate in his first flight "these are = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0parameters I expect you to negotia= te", along with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration= identifier, based on what the server
=C2=A0 =C2=A0 =C2=A0 =C2=A0= negotiated the previous time. [Optionally, the server
=C2=A0 =C2= =A0 =C2=A0 =C2=A0can run the same negotiation locally and abort on mismatch= .]

=C2=A0 =C2=A0(b) As in (a) but with no indicati= on of the expected parameters,
=C2=A0 =C2=A0 =C2=A0 =C2=A0just th= e configuration ID, and the client just preemptively
=C2=A0 =C2= =A0 =C2=A0 =C2=A0uses the parameters from the last time and if the negotiat= ion
=C2=A0 =C2=A0 =C2=A0 =C2=A0ends up differently, all the data = is undecryptable
=C2=A0 =C2=A0 =C2=A0 =C2=A0(ugh) and you somehow= fall back.

=C2=A0 =C2=A0(c) Have the server provi= de a preference list in his
=C2=A0 =C2=A0 =C2=A0 =C2=A0ServerConf= iguration (this can be the same as in the
=C2=A0 =C2=A0 =C2=A0 = =C2=A0ClientHello) and have the client do the negotiation based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0that rather than the server (as in QUIC). This= is a little odd
=C2=A0 =C2=A0 =C2=A0 =C2=A0in that it means that= sometimes the server selects the
=C2=A0 =C2=A0 =C2=A0 =C2=A0para= meters and sometimes the client does, but it's not that
=C2= =A0 =C2=A0 =C2=A0 =C2=A0hard to make this code symmetrical.

<= /div>
As I think this through, I am leaning towards (a) but other peopl= e's
opinions on this topic would be welcome. Expect a mesage = about this
shortly.


2. Sh= ould we require that PSK cipher suites where the PSK is used for
= resumption use compatible ciphers? This is the way it was in TLS 1.2
<= div>and below for resumption and tickets, but once you have a PSK, that'= ;s
not really necessary [0]. So, for instance, if you had the fol= lowing
cipher list order:

=C2=A0 =C2=A0 = ECDHE + AES-GCM
=C2=A0 =C2=A0 ECDHE + ChaCha/Poly
=C2= =A0 =C2=A0 PSK + ChaCha/Poly
=C2=A0 =C2=A0 PSK + AES-GCM

You could potentially negotiate one connection with GCM, u= se it
to establish a shared key, and then reconnect with ChaCha/P= oly.
This seems like it probably should be something we avoid, th= ough
I'm not sure we have a concrete reason why, and it means= a
weird special case for PSK. Note that this issue might be
ameliorated some (though not completely) with a la carte negotiation.=


3. I don't currently have PSK/= Resumption + 0-RTT working, because you
need a way to indicate th= e expected parameters (see point #1 above).

4. Sec= urity Considerations is badly out of date, so I plan to
rewrite t= hat soon, but probably not before Prague. I also intend
to do a p= retty substantial editorial cleanup pass and potentially
some res= tructuring after Prague.


As indicat= ed above, this is a pretty major revision, so is still kind
of a = hard hat area and no doubt contains a number of errors,
potential= ly serious ones (as well as a big pile of TODOs).
Comments and PR= s welcome.

Thanks,
-Ekr


[0] With the exception of cryptographic concerns ab= out the use
of the same IKM with different hash functions for HKD= F, but this
is a problem that applies to any use of PSK, not just= this one.

--f46d04182808bb9711051a5e224b-- From nobody Wed Jul 8 09:02:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794C81A0151 for ; Wed, 8 Jul 2015 09:02:52 -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 gyZ68F_uIgYB for ; Wed, 8 Jul 2015 09:02:45 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8844D1A0122 for ; Wed, 8 Jul 2015 09:02:45 -0700 (PDT) Received: by ykee186 with SMTP id e186so11574908yke.2 for ; Wed, 08 Jul 2015 09:02:45 -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=UzpHPYUTkC/u+G9ECADF0WST13X7xZNz/K/qvnT1QSg=; b=WGlg1aTkBaVnrcfqMWczZirzkjAdiaueH1aXGIM+4JqojvRgms0+eJN/4deJxihIKQ mRJxb3N4TPCcCxDBoPlLLmdnJE3/+WcYJ69ZQMLH8H+bv2sgscpuuAUJd7H0Ln6lhRhA 6fCbsPvNnM5gc5TtsD7UAHU26GfmuSUlAdASsNUCqdLiY0f1o7iYJYwQaAvIE7nHpLx4 Dytr3HTEHLzd9LdBVQmAs9E0GGBdCyVXfYkjkAVmnA51Yw7IkEFIliKHD/ZAlLYlVrFF fqeXdRL4QBluwVQE72WMcMM/L0nx7TZEFo62WV1PKzHeebyMim3tljeN9GoYxni/b6/m NOKg== MIME-Version: 1.0 X-Received: by 10.129.97.5 with SMTP id v5mr12276806ywb.56.1436371364964; Wed, 08 Jul 2015 09:02:44 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 8 Jul 2015 09:02:44 -0700 (PDT) In-Reply-To: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> Date: Wed, 8 Jul 2015 09:02:44 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 16:02:52 -0000 On 7 July 2015 at 18:55, Salz, Rich wrote: > Agreed, nobody cares much about the client side. I do, but only a little (we do mutual authentication for WebRTC and we want to migrate from RSA to ECDSA certs). From nobody Wed Jul 8 09:04:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0ED1A016C for ; Wed, 8 Jul 2015 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 sW4UuP3gMPMq for ; Wed, 8 Jul 2015 09:04:26 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 584EF1A0171 for ; Wed, 8 Jul 2015 09:04:26 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t68G4OHT016936; Wed, 8 Jul 2015 12:04:24 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqHM/L4/ZIBKEisF6Kbx4+pEp3QcEqAgAAI+QCAAAQ1gIAADWmAgAA2FYCAACIggIAAML+AgADssAD//71kgA== Date: Wed, 8 Jul 2015 16:04:24 +0000 Message-ID: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> 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.5.2.150604 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3519201859_4644496" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-08_08:2015-07-08,2015-07-08,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-1506180000 definitions=main-1507080248 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 16:04:28 -0000 --B_3519201859_4644496 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I do too - we do mutual certificate-based authentication. -- Regards, Uri Blumenthal On 7/8/15, 12:02 , "TLS on behalf of Martin Thomson" wrote: >On 7 July 2015 at 18:55, Salz, Rich wrote: >> Agreed, nobody cares much about the client side. > >I do, but only a little (we do mutual authentication for WebRTC and we >want to migrate from RSA to ECDSA certs). --B_3519201859_4644496 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgfECIWzIVNsp/v/abHRDJB2jkwsZFeiTlgDL9UVbRrLQwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzA4MTYwNDE5WjANBgkqhkiG9w0BAQEFAASC AQAq3ViIl2fUsiNj8Pe6fJSEuL6+MmpkukzvRK9WS2+fHPfmq0DH9d4Ev/eiwir2HwmEWt8u KkS/Y497fgesHrumoQuL1cVpvS87N8LiM5Reg/cxswGNGwFmCiCmkNs0ZeU8NwmIIOmpMvQp FqbZM6aB/FIZhfyp4qixJ69udf8AuhQsgXmnoR3J03qHJkcFZZNAW0q4SBehNDz+WMltekXb KJInKVTckTaugJo039WBhjCiryNFcfU40vnQssLuUk3Fm8Y8kD378MJMz/8yaecd4OiaNVWt /8g4CLi58Rd3v65yT5TvMAuXSwbLrNU6Mub5XSX4g05QSRvruTkB2yMl --B_3519201859_4644496-- From nobody Wed Jul 8 09:05:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896641A017A for ; Wed, 8 Jul 2015 09:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 qAcoejPt96ve for ; Wed, 8 Jul 2015 09:05:37 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3051A010F for ; Wed, 8 Jul 2015 09:05:37 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t68G5ZFZ018588; Wed, 8 Jul 2015 12:05:35 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqHM/L4/ZIBKEisF6Kbx4+pEp3QcEqAgAAI+QCAAAQ1gIAADWmAgAA2FYCAACIggIAAML+AgADssAD//71kgIAAAFIA Date: Wed, 8 Jul 2015 16:05:35 +0000 Message-ID: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> 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.5.2.150604 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3519201928_4604074" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-08_08:2015-07-08,2015-07-08,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-1506180000 definitions=main-1507080250 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 16:05:38 -0000 --B_3519201928_4604074 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 7/8/15, 12:04 , "Blumenthal, Uri - 0553 - MITLL" wrote: >I do too - we do mutual certificate-based authentication. Having said that, we do not care much for SHA1. >On 7/8/15, 12:02 , "TLS on behalf of Martin Thomson" on behalf of martin.thomson@gmail.com> wrote: > >>On 7 July 2015 at 18:55, Salz, Rich wrote: >>> Agreed, nobody cares much about the client side. >> >>I do, but only a little (we do mutual authentication for WebRTC and we >>want to migrate from RSA to ECDSA certs). --B_3519201928_4604074 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgtoLBxsjfsd0xVEPFxBxhfaedc1fF0Br0T8cGN3gMfJEwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzA4MTYwNTI4WjANBgkqhkiG9w0BAQEFAASC AQBCepAITLk5mk8+9BcOD0WnnVdwWYz24/np8Wwxq0wrkDeYZ0WCGUNFSfqNvd31ViDyUZaD MnsEy/b8VPvqNWpendO7jtpR5dBtL/kd4sjp/o86yXo1IWDuCyLnEBI15ulOUye9rPV9T+kU 6NDh2dsQ5xq8iGBj5/NcZQ1gw7QvSTj8JI8/3ySU+HMvDbjX5mA4Nlu9Bsz56sverhuqYQfg 2MMsGvxWY9Me4U3FJXyAscnMEHVmWMiQMEfgXn98ZgjoYyEnXD3s1cYRkedupYGORfeg7XNN akOfrEa1PaiWmAjIuvIQskzpksPDFp9FbZiTJY4QaZfgOKwAyhv9qmzY --B_3519201928_4604074-- From nobody Wed Jul 8 09:06:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CAB1A01AE for ; Wed, 8 Jul 2015 09:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 kW7HRwhR7sY8 for ; Wed, 8 Jul 2015 09:06:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 573D11A0171 for ; Wed, 8 Jul 2015 09:06:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CA89A4D464; Wed, 8 Jul 2015 16:06:34 +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 B549A4D45F; Wed, 8 Jul 2015 16:06:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436371594; bh=FzhIOI64kMNDmlmaOPQSqhT6GAkw+gvZhv8RzJwE+28=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=L/NU0Y/+QEFmweK8VbzbpZ30IQhoiCgNqIcaN4Boi3TVZhPAa5bqq1WWIGgkUzquR eu+vt4Jt4PsQbG0LU+WPWPV4eiNNDVrIZwSuBh0xIpKQepWdlHs8iutQfe8tGsv3xr wxyfBIKq1k0g63lruOA2m3tk/IEoCM6oxz6fLgEg= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id B244898084; Wed, 8 Jul 2015 16:06:34 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 11:06:34 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Wed, 8 Jul 2015 11:06:34 -0500 From: "Salz, Rich" To: "Blumenthal, Uri - 0553 - MITLL" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqBnytZJHwlb02fn+qYqTOau53QgQ6AgAAI+QCAAAQ0gIAADWqAgAA2FYCAACIfgP//3B2wgAFBUwCAAAB3AP//rHZQ Date: Wed, 8 Jul 2015 16:06:33 +0000 Message-ID: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 16:06:36 -0000 PiBJIGRvIHRvbyAtIHdlIGRvIG11dHVhbCBjZXJ0aWZpY2F0ZS1iYXNlZCBhdXRoZW50aWNhdGlv bi4NCg0KU28gbGV0IG1lIHJlcGhyYXNlIFZpa3RvcidzIHF1ZXN0aW9uOiAgZG8gbWFueSBjbGll bnQtc2lkZSBUTFMgYXBwcyBjYXJlIG5lZWQgdG8gY2FyZSBhYm91dCB3aGljaCBjZXJ0aWZpY2F0 ZSB0byBwcmVzZW50PyAgT3IgaXMgaXQgYSBjaG9vc2UgZnJvbSBhIGxpc3Qgb2Ygb25lIHR5cGUg b2YgdGhpbmc/IA0K From nobody Wed Jul 8 09:12:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2241A01AE for ; Wed, 8 Jul 2015 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 Qj1I8DWFlBkh for ; Wed, 8 Jul 2015 09:12:06 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0E811A017A for ; Wed, 8 Jul 2015 09:12:06 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t68GC4mv028996; Wed, 8 Jul 2015 12:12:04 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqHM/L4/ZIBKEisF6Kbx4+pEp3QcEqAgAAI+QCAAAQ1gIAADWmAgAA2FYCAACIggIAAML+AgADssAD//71kgIAAQ62A//++d4A= Date: Wed, 8 Jul 2015 16:12:04 +0000 Message-ID: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> 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.5.2.150604 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3519202319_4633163" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-08_08:2015-07-08,2015-07-08,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-1506180000 definitions=main-1507080250 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 16:12:08 -0000 --B_3519202319_4633163 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 7/8/15, 12:06 , "Salz, Rich" wrote: >> I do too - we do mutual certificate-based authentication. > >So let me rephrase Viktor's question: do many client-side TLS apps care >need to care about which certificate to present? Probably not, at least not now. Usually our clients have one cert per purpose, and are well-aware of what cert to use when (if one client has more than one purpose and therefore more than one credential). Maybe it=E2=80=99s because our usage model is still young and unsophisticated=E2=80=A6? > Or is it a choose from a list of one type of thing? :-) --B_3519202319_4633163 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgqlm1T1QIS0Jprn5W8bMIx1pmQlAzSBNvWJ9MZVldi7QwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzA4MTYxMTU5WjANBgkqhkiG9w0BAQEFAASC AQCQICS9624Wp9hWxTZA35kHQISFbL/mwPtEP22dIcQQ1FpaQ3O/RAZAHGCuxbw+x17Yre// 5l5/28gQSvZ5mZHdICIDmBUpyOTITpRIljZh/1ma9+/dW5PBez8s7rR4rcfiQHZ7VBNshL9I AkptmU27MMgCn7brdPV6SC3PDqDAt/0bHjkyKTYpVmNvRAPgAWS3yFcSIREedZHLtRs5IgLi JZ0wOKyR7hRIHI/yPozsPv2t4ElWxpMIXjRiXm9Tvv18NSIsxwgYMi/xYR701dJ93yJKqwwX O+ktdeenp7SMLqLVMBoUC9XzQ4rcHNIGN3jHr7FbpKSXdF63aeJFclil --B_3519202319_4633163-- From nobody Wed Jul 8 09:16:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF411A0264 for ; Wed, 8 Jul 2015 09:16:21 -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 6eYlgnas01Tj for ; Wed, 8 Jul 2015 09:16:20 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38C01A0252 for ; Wed, 8 Jul 2015 09:16:20 -0700 (PDT) Received: by ykeo3 with SMTP id o3so91324261yke.0 for ; Wed, 08 Jul 2015 09:16:20 -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=tvKfMfhe/qu0mcW7D78sgfMm3CJGTAi63IxNiYn4akU=; b=fBOpGTGwDx7kBUVBKKSnxLc3YMoLYl5evrWNJ4K/SW4GsxMEAzheHSJm0JfgB2mb8A PrdnRiLGdhfd+OJblStVYyFkCFw/5xjABw0nl+rp5blunFIzq3U4+onlXOVKvUWCY8Ci 5cyf72i7Ps56s8J1m0uliR5JEONFTLRroDqa/0ZRXrVT7qoSpoCm964XL80VUTw7CLAO ns7IqVOC5GTN6jEj72XBo44WvX03NwZa8Rq4cPppkzbridRn0ryHf2O7g2bul7U4tnRV HC3prpTthLXljL3KQD9gC7yVUBglHGi2gm14AOa+vScsiMeecD/85jUJmJtfqGIwjg0/ Dfcg== MIME-Version: 1.0 X-Received: by 10.170.57.200 with SMTP id 191mr1582364ykz.118.1436372180205; Wed, 08 Jul 2015 09:16:20 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 8 Jul 2015 09:16:20 -0700 (PDT) In-Reply-To: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> Date: Wed, 8 Jul 2015 09:16:20 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 16:16:22 -0000 On 8 July 2015 at 09:06, Salz, Rich wrote: >> I do too - we do mutual certificate-based authentication. > > So let me rephrase Viktor's question: do many client-side TLS apps care need to care about which certificate to present? Or is it a choose from a list of one type of thing? I was grappling with this exact problem yesterday. From nobody Wed Jul 8 10:45:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AAA1A1BFF for ; Wed, 8 Jul 2015 10:45:57 -0700 (PDT) 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 8m7YtgP1SMtR for ; Wed, 8 Jul 2015 10:45:55 -0700 (PDT) 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 D9B8D1A1C04 for ; Wed, 8 Jul 2015 10:45:51 -0700 (PDT) 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 48BC9446DE for ; Wed, 8 Jul 2015 19:45:49 +0200 (CEST) X-purgate-ID: 152705::1436377549-00000B48-3AE001A1/0/0 X-purgate-size: 2093 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3D037426C2 for ; Wed, 8 Jul 2015 19:45:49 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 336B51A1C7; Wed, 8 Jul 2015 19:45:49 +0200 (CEST) In-Reply-To: <20150707205858.GH21534@mournblade.imrryr.org> To: tls@ietf.org Date: Wed, 8 Jul 2015 19:45:49 +0200 (CEST) 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: <20150708174549.336B51A1C7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 08 Jul 2015 17:45:57 -0000 Viktor Dukhovni wrote: > On Tue, Jul 07, 2015 at 10:45:25AM -0700, Eric Rescorla wrote: >> >> So if you can't express SHA1 in signature_algorithms, then the server can't >> send you a certificate signed with SHA-1. > > This is a very unfamiliar use of the word "can't". In practice > most servers will send whatever (fixed) certificate chain they're > configured with, no matter the content of the signature_algorithm > extension. Servers that possess otherwise equivalent chains that > differ only in the signature algorithm are rather rare beasts AFAIK. > > Which SSL libraries allow server administrators to configure multiple > chains based on the signature algorithm? Unfortunately, a non-marginal installed base is exhibiting this self-imposed (mis)behaviour of connection failure: Microsoft SChannel beginning with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / 2012 and Windows 8.1 / 2012R2 exhibit the same (mis)behaviour. When you install a server certificate with a sha256WithRsaEncryption signature on a Microsoft IIS on one of these platforms, enable TLSv1.2 on the server and try to connect with an extension-free ClientHello that offers client_version= (3,3), you will face a connection failure (IIS simply closes the network connection--IIS is notorious in failing to put fatal alerts on the wire). The handshake succeeds (with TLSv1.1) if the client offers at most TLSv1.1, or if the client offers TLSv1.2 in a SSL Version2 CLIENT-HELLO rather than an extensionless TLS ClientHello, if TLSv1.2 is disabled on IIS, or if a server certificate with only sha1WithRsaEncryption ist used. > > My impression is that chain selection based on the extension is > largely wishful thinking. To me, it looks more like a lack of thinking on part of the spec writers and the implementors. Just how dumb the idea is should become obvious if you compare the handshake result for TLSv1.1 and for TLSv1.2. Essentially, this is a TLS protocol version intolerance created by the TLSv1.2 protocol specification itself. -Martin From nobody Wed Jul 8 10:50:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03331A21A3 for ; Wed, 8 Jul 2015 10:50:50 -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 rlRDAMu4GaAV for ; Wed, 8 Jul 2015 10:50:49 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D6D1A21A8 for ; Wed, 8 Jul 2015 10:50:41 -0700 (PDT) Received: by qgeg89 with SMTP id g89so103618542qge.3 for ; Wed, 08 Jul 2015 10:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=Yfzj8dsAFC//HRDhmSOPGqhFx9+xO5sqo61ZpJiqmt4=; b=hvy7jren7CP7QijVpbP037C6SVLUh5KF13970Qs6k66TClHQSsMRepwsFbRtuuIuAr avqAH03zCNua01p8+gFHegnTL8FbxRPs2Q2cc1EMpn8/K56SFPc0CXk3/Ur+Uauv/c4X dlqVRbgtoOJ84ytJ8JCHMWmw68Eca8VPUQ+1q4DoUEBrLo25ZmwTtYyIHBJEVAcjGO/E nmdf7l5oZjMIRIxmJGbscopy6X0VDo5l62LM6C5/fxgzmh6j7OrkMRpMDzsQitpfIixx iQACY2Uhd/WW/i3m3ffAyeevQfmuOBsWsuCoX7ENZEP9dGDT3ZnD/UmRNXv4M/F2C1rg yKUQ== X-Received: by 10.55.41.95 with SMTP id p92mr17433039qkh.10.1436377841018; Wed, 08 Jul 2015 10:50:41 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 7sm1514633qky.29.2015.07.08.10.50.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Jul 2015 10:50:40 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, mrex@sap.com Date: Wed, 8 Jul 2015 13:50:39 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150708174549.336B51A1C7@ld9781.wdf.sap.corp> In-Reply-To: <20150708174549.336B51A1C7@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507081350.39322.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 17:50:50 -0000 On Wednesday, July 08, 2015 01:45:49 pm Martin Rex wrote: > Unfortunately, a non-marginal installed base is exhibiting this self-imposed > (mis)behaviour of connection failure: Microsoft SChannel beginning > with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / 2012 and > Windows 8.1 / 2012R2 exhibit the same (mis)behaviour. > > When you install a server certificate with a sha256WithRsaEncryption signature > on a Microsoft IIS on one of these platforms, enable TLSv1.2 on the server > and try to connect with an extension-free ClientHello that offers > client_version= (3,3), you will face a connection failure (IIS simply closes > the network connection--IIS is notorious in failing to put fatal alerts > on the wire). > > The handshake succeeds (with TLSv1.1) if the client offers at most TLSv1.1, > or if the client offers TLSv1.2 in a SSL Version2 CLIENT-HELLO rather than > an extensionless TLS ClientHello, if TLSv1.2 is disabled on IIS, or if > a server certificate with only sha1WithRsaEncryption ist used. To clarify, how does this scenario respond with a TLS 1.2 ClientHello with at least one extension? Does it matter what extension(s)? (e.g. does IIS have to know what it is?) Dave From nobody Wed Jul 8 11:07:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A011A6EE8 for ; Wed, 8 Jul 2015 11:07:50 -0700 (PDT) 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 tl1_qKi7Np_h for ; Wed, 8 Jul 2015 11:07:49 -0700 (PDT) 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 E9D0F1A6EE6 for ; Wed, 8 Jul 2015 11:07:48 -0700 (PDT) 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 A4CC4446FE; Wed, 8 Jul 2015 20:07:47 +0200 (CEST) X-purgate-ID: 152705::1436378867-00000B48-885CB8CA/0/0 X-purgate-size: 2035 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 95560426F6; Wed, 8 Jul 2015 20:07:47 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8C9B11A1C7; Wed, 8 Jul 2015 20:07:47 +0200 (CEST) In-Reply-To: <201507081350.39322.davemgarrett@gmail.com> To: Dave Garrett Date: Wed, 8 Jul 2015 20:07:47 +0200 (CEST) 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: <20150708180747.8C9B11A1C7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 08 Jul 2015 18:07:50 -0000 Dave Garrett wrote: > Martin Rex wrote: >> Unfortunately, a non-marginal installed base is exhibiting this self-imposed >> (mis)behaviour of connection failure: Microsoft SChannel beginning >> with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / 2012 and >> Windows 8.1 / 2012R2 exhibit the same (mis)behaviour. >> >> When you install a server certificate with a sha256WithRsaEncryption signature >> on a Microsoft IIS on one of these platforms, enable TLSv1.2 on the server >> and try to connect with an extension-free ClientHello that offers >> client_version= (3,3), you will face a connection failure (IIS simply closes >> the network connection--IIS is notorious in failing to put fatal alerts >> on the wire). >> >> The handshake succeeds (with TLSv1.1) if the client offers at most TLSv1.1, >> or if the client offers TLSv1.2 in a SSL Version2 CLIENT-HELLO rather than >> an extensionless TLS ClientHello, if TLSv1.2 is disabled on IIS, or if >> a server certificate with only sha1WithRsaEncryption ist used. > > To clarify, how does this scenario respond with a TLS 1.2 ClientHello > with at least one extension? Does it matter what extension(s)? > (e.g. does IIS have to know what it is?) The issue here is the (lack of the) TLSv1.2 signature_algorithms extension. Windows SChannel appears to treat the absence of this extension the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha1,dsa) If you send the TLSv1.2 signature_algorithms extension with the algorithm matching the signature of the server certificate, e.g. (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed. Correcting a slight inaccuracy above: when the server certificate is signed with sha1WithRsaEncryption, the handshake will succeed with TLSv1.2. When an SSLv2 ClientHello offering TLSv1.2 is sent, the TLS handshake will succeed independent of the signature on the IIS server certificate, but the server will pick only TLSv1.1 rather than TLSv1.2. -Martin From nobody Wed Jul 8 11:08:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8631A6EF4 for ; Wed, 8 Jul 2015 11:08:50 -0700 (PDT) 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 0xX_dk8diHJA for ; Wed, 8 Jul 2015 11:08:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D441A6EE6 for ; Wed, 8 Jul 2015 11:08:41 -0700 (PDT) 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 (Postfix) with ESMTPS id D2D83923AB; Wed, 8 Jul 2015 18:08:40 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t68I8a0d017537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2015 14:08:40 -0400 From: Hubert Kario To: Martin Thomson Date: Wed, 08 Jul 2015 20:08:27 +0200 Message-ID: <6977707.v0cBc3NarS@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <2070265.aJZlsBJAF8@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12387570.6OPGYCdBbE"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 18:08:50 -0000 --nextPart12387570.6OPGYCdBbE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 03 July 2015 15:22:21 Martin Thomson wrote: > On 3 July 2015 at 10:53, Hubert Kario wrote: > > https://github.com/ekr/tls13-spec/pull/12 >=20 > [Make {sha256, xxx} the default signature algorithm extension value > when the extension is absent] >=20 > There is a problem with this, and I think that you need to highlight > that in the text. >=20 > The reason that this doesn't work particularly well, though it > probably isn't strictly problematic, is that now you have an extensio= n > that means one thing {sha1, rsa} when you negotiate TLS <=3D 1.2 and > another thing {sha256, rsa} when you negotiate TLS 1.3. Maybe that's= > OK, but it narrows the utility of having a default. >=20 > Please add the following (or similar): > A TLS 1.3 client that is willing to do TLS <=3D 1.2 MUST include the > extension unless it supports SHA-256 for TLS 1.3 and SHA-1 for TLS <=3D= > 1.2. Done and done. Also submitted a pull request directly to tlswg/tls13-spec repo: https://github.com/tlswg/tls13-spec/pull/196 =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart12387570.6OPGYCdBbE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVnWchAAoJEJKo0bgB0vX17/wP/3Xuc+78+QEB0o7iJVGv9g5V qJ6820/byUU15+HcTWo/VbKavE1EgBpQTDHMBWiv0ceQu1gOxDukPRHQ3O8r9LMZ 6Y6zT/KZwodedg1S/vH0are2vzNXy4zIsn5qbEGQxPZibFHqvkX7r1FmGKCkwMBJ z6PCWHftLF/hHYGIjCP+/inDQ9oLyafrT+FIbX4jQgdx9KXrcEXgTt+Q0MPKc7nd 2o++YVNJ4r2FKJx/RGl8Ef/5SrYa0lTpLrvdpl7ULPUR3ZbpJOk0gSjR1gej/VRJ /S6wIO0DctravwFyZyTU5EwaMdZy3QmmVz3eYQfhrF/gJHL5c6IOrZGRVdFVlBak EA3cG09ZnGZhthDT6tLxo07re89mF8zt9C/Po2FXkMdE2vfKrD3gaz1uWcOSzTn5 fJRVwDzrNtkRTc0tH8VGDBjKGBM2LV0v9ZQC230axNZQG9leUArhMSA2nKfYIaV3 x0hxGXPqBI6b9bix9URIEkPL//jpX/a1BD+HO1GEcI2G0TalIchmMTkQi6HvkMAJ SHYYw9xpsztH5+TFfihWJFRDsakeGEwcS55GbNm01cNhK2iD5qHP6H3wbistn99f jmgyPj+FxeHdFaYFfH9/S3qR+tvItNhsB8Ft/te+8EpqeUqHVwbXbkRCrS5W4Bif ElhRqT+qGQRfYyR0KAEE =mfp8 -----END PGP SIGNATURE----- --nextPart12387570.6OPGYCdBbE-- From nobody Wed Jul 8 11:08:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A6E1A6EE6 for ; Wed, 8 Jul 2015 11:08:51 -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 m_VGbGVubVsM for ; Wed, 8 Jul 2015 11:08:50 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C454D1A6EE8 for ; Wed, 8 Jul 2015 11:08:47 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so220482007wib.1 for ; Wed, 08 Jul 2015 11:08:46 -0700 (PDT) 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=4GT5puyTQ5c4rXiK23kp6hCvoy6ynSF6E4f3VXRQaU4=; b=NM1WpWffW012dMNPVxDUwAmJb3a80dE4lleYlm9UCCjyaOYceBa3crtKsd9CgDcqFt 4bg7OliPlEw95zVO2pqB9okDy3SYhDEpHL+mpvFtkCloRf0wYpZ2RP8qFwvYZu3T7wfd GB9dfLDnx8dSVCyv76E3MMddt6M9/mVs7ZOi3YI4fAUSwUjUq5Vf7Mvtyw4ISOHgVbff 1zxXDzqYfy/WPgSlol0g6VT0j2NmiRtp2IkTOdsWDATn4fRJKsfv3jjcAOSvSjOZtBty cdWbtZiVhaa9+FBdRo4rqZ1GgBNeXkuMUFUUe2UWI8EFVgszgdcHJsg8MOVQzvp46Z3v xvmQ== X-Received: by 10.194.110.100 with SMTP id hz4mr22351616wjb.6.1436378926557; Wed, 08 Jul 2015 11:08:46 -0700 (PDT) Received: from [192.168.1.15] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id b4sm4118322wic.7.2015.07.08.11.08.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jul 2015 11:08:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Wed, 8 Jul 2015 21:08:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> To: Rich Salz X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 18:08:51 -0000 > On Jul 8, 2015, at 7:06 PM, Salz, Rich wrote: >=20 >> I do too - we do mutual certificate-based authentication. >=20 > So let me rephrase Viktor's question: do many client-side TLS apps = care need to care about which certificate to present? Or is it a choose = from a list of one type of thing?=20 I believe it is never an issue. The use case I care about is =E2=80=9CSSL = VPNs=E2=80=9D and corporate portals. In both of them the organization = running the web server rolls out a CA. They hardly ever use a public CA. = It=E2=80=99s either a CA that comes bundled with the portal software or = a corporate CA. Such a CA will issue the user exactly one certificate, = because that certificate is meant to be used to access the portal or the = SSL VPN, and the portals are meant to look up the identity in the = certificate in the corporate LDAP server or RADIUS or DIAMETER. It=E2=80=99s possible that a single user might be issued multiple = certificates, but they will be from different CAs, and choosing a client = certificate based on CA will work. I don=E2=80=99t see any use case for = a corporate CA to issue multiple certificates to the same user or device = with different algorithms. This is at least true for my use cases. Yoav From nobody Wed Jul 8 11:09:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2C1A6F03 for ; Wed, 8 Jul 2015 11:09:00 -0700 (PDT) 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, 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 1ZOjuD-AeBL0 for ; Wed, 8 Jul 2015 11:08:58 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0134.outbound.protection.outlook.com [207.46.100.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46BD1A6F02 for ; Wed, 8 Jul 2015 11:08:55 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.207.19; Wed, 8 Jul 2015 18:08:53 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0207.004; Wed, 8 Jul 2015 18:08:53 +0000 From: Andrei Popov To: "mrex@sap.com" , Dave Garrett Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAAAu4A== Date: Wed, 8 Jul 2015 18:08:53 +0000 Message-ID: References: <201507081350.39322.davemgarrett@gmail.com> <20150708180747.8C9B11A1C7@ld9781.wdf.sap.corp> In-Reply-To: <20150708180747.8C9B11A1C7@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sap.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::5] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:rkw2EfCkTRlJOwikPhA0WIBbidWKZbS9D0ltCp6wKSnqyI7gflR3FIfqDjXzZLZT7TlGJto+aAIuHF3aroC7iGQ9U+O7wKu/VKphKEqqj5hqpSNR41qJfYpZDfRrJIwjaM6AQuyT8FgZg6rnfxd3Jw==; 24:p+lHLTUJbCYZnY7cPsHt8HA+C8vbgCnMLT+FvdM7Mno2uvZT9rqhHKUCBy9Eb665E9t/uo4W8k7luMsGuCBgoYaltCCNCOAtQRpoNxB6C4A=; 20:7zo5powz0l/UhZH4rjqh1EK2+j6jJ9gQwTgrxrXc0Q9ichRg2vCjs5+Zq78tu6AWFZo/wq87ih3XQ9GttD0XKA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(24454002)(13464003)(46102003)(122556002)(62966003)(189998001)(87936001)(50986999)(5003600100002)(86362001)(77096005)(76576001)(74316001)(5002640100001)(40100003)(5001960100002)(2900100001)(15975445007)(77156002)(102836002)(106116001)(2656002)(5001770100001)(2501003)(86612001)(92566002)(19580395003)(33656002)(54356999)(76176999)(19580405001)(7059030)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2015 18:08:53.3815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 18:09:01 -0000 For context: on multiple threads, Martin has repeatedly brought up the fact= that schannel complies with section 7.4.1.4.1 "Signature Algorithms" of RF= C 5246, which says: " If the client does not send the signature_algorithms extension, the server MUST do the following: - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent the value {sha1,rsa}. - If the negotiated key exchange algorithm is one of (DHE_DSS, DH_DSS), behave as if the client had sent the value {sha1,dsa}. - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}." This means that e.g. if IIS only has a SHA256 cert, and the client offers T= LS1.2 and no signature_algorithms extension, IIS will indeed fail the hands= hake. It is possible that we might improve the product by not complying with sect= ion 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel does = comply. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Wednesday, July 8, 2015 11:08 AM To: Dave Garrett Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek) Dave Garrett wrote: > Martin Rex wrote: >> Unfortunately, a non-marginal installed base is exhibiting this=20 >> self-imposed (mis)behaviour of connection failure: Microsoft SChannel=20 >> beginning with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 /=20 >> 2012 and Windows 8.1 / 2012R2 exhibit the same (mis)behaviour. >>=20 >> When you install a server certificate with a sha256WithRsaEncryption=20 >> signature on a Microsoft IIS on one of these platforms, enable=20 >> TLSv1.2 on the server and try to connect with an extension-free=20 >> ClientHello that offers client_version=3D (3,3), you will face a=20 >> connection failure (IIS simply closes the network connection--IIS is=20 >> notorious in failing to put fatal alerts on the wire). >>=20 >> The handshake succeeds (with TLSv1.1) if the client offers at most=20 >> TLSv1.1, or if the client offers TLSv1.2 in a SSL Version2=20 >> CLIENT-HELLO rather than an extensionless TLS ClientHello, if TLSv1.2=20 >> is disabled on IIS, or if a server certificate with only sha1WithRsaEncr= yption ist used. >=20 > To clarify, how does this scenario respond with a TLS 1.2 ClientHello=20 > with at least one extension? Does it matter what extension(s)? > (e.g. does IIS have to know what it is?) The issue here is the (lack of the) TLSv1.2 signature_algorithms extension. Windows SChannel appears to treat the absence of this extension the same as= the presence of an extension with (md5,rsa) (sha1,rsa) (sha1,dsa) If you send the TLSv1.2 signature_algorithms extension with the algorithm m= atching the signature of the server certificate, e.g. (sha256,rsa) in the a= bove example, then a TLSv1.2 handshake will succeed. Correcting a slight inaccuracy above: when the server certificate is signe= d with sha1WithRsaEncryption, the handshake will succeed with TLSv1.2. When an SSLv2 ClientHello offering TLSv1.2 is sent, the TLS handshake will = succeed independent of the signature on the IIS server certificate, but the= server will pick only TLSv1.1 rather than TLSv1.2. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 8 11:15:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE06C1A6F02 for ; Wed, 8 Jul 2015 11:15:48 -0700 (PDT) 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 5chtsZQ3iD8E for ; Wed, 8 Jul 2015 11:15:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A3F1A6F01 for ; Wed, 8 Jul 2015 11:15:47 -0700 (PDT) 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 (Postfix) with ESMTPS id 6793DBD01E; Wed, 8 Jul 2015 18:15:47 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t68IFge9028360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2015 14:15:46 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 08 Jul 2015 20:15:40 +0200 Message-ID: <4168412.YzbFrOzRpF@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <201507081350.39322.davemgarrett@gmail.com> References: <20150708174549.336B51A1C7@ld9781.wdf.sap.corp> <201507081350.39322.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1675202.eOFdqlj8Qf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 18:15:49 -0000 --nextPart1675202.eOFdqlj8Qf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 08 July 2015 13:50:39 Dave Garrett wrote: > On Wednesday, July 08, 2015 01:45:49 pm Martin Rex wrote: > > Unfortunately, a non-marginal installed base is exhibiting this > > self-imposed (mis)behaviour of connection failure: Microsoft SChann= el > > beginning with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / = 2012 > > and > > Windows 8.1 / 2012R2 exhibit the same (mis)behaviour. > >=20 > > When you install a server certificate with a sha256WithRsaEncryptio= n > > signature on a Microsoft IIS on one of these platforms, enable TLSv= 1.2 on > > the server and try to connect with an extension-free ClientHello th= at > > offers > > client_version=3D (3,3), you will face a connection failure (IIS si= mply > > closes the network connection--IIS is notorious in failing to put f= atal > > alerts on the wire). > >=20 > > The handshake succeeds (with TLSv1.1) if the client offers at most > > TLSv1.1, > > or if the client offers TLSv1.2 in a SSL Version2 CLIENT-HELLO rath= er than > > an extensionless TLS ClientHello, if TLSv1.2 is disabled on IIS, or= if > > a server certificate with only sha1WithRsaEncryption ist used. >=20 > To clarify, how does this scenario respond with a TLS 1.2 ClientHello= with > at least one extension? Does it matter what extension(s)? (e.g. does = IIS > have to know what it is?) The IIS is behaving as the RFC requires it to (with the exception of TL= S=20 alerts) - according to section 7.4.2 of RFC 5246 - bottom of page 48. If you send a TLS 1.2 Client Hello, include signature algorithms with (= sha1,=20 sha256)*(rsa, ecdsa, dsa) it will abort connection if the installed=20 certificate has SHA512 signature. =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1675202.eOFdqlj8Qf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVnWjMAAoJEJKo0bgB0vX1lQcP+wUjGvww7imG2N4cmd0tNn6k zGRz1AIfAG2EiZTTupNb4pYn2RfOnt3AagxlayrCNW27RY+JY2RLbf6WEHB2X01a zpBT6vGPQ/9742LIOzVhwd4FajRpDWeOhmfTQ1quSIrF3x/yzM7Xa9geE+l6ppvu m9RvvIpju9HmYP0zv+uEzbNKgFeajy1gfPv/cMYfS7u+gvw7f05B7YNeZfGIEYVu foWxC9ZQjkXqlhAPkAxYT80MxRLzwX1R1OWB6f6pxP4F/Yf35ndxn+cti9vSsviJ q+0wbJQ1LKsRKfVIuw85ztV8te4wkmqUDm1PgHMFantyNDlAhcSFOaEuF0maZ1X3 1gC96H+iVYpKKjFVB60vBO3rcjpBXKO+MnSu0rn6wb2YmFpIbf0PillV2phkmWhn k8kTBnnzKO8TjSld3d0+C9qM4Ry1RUnckT7ezfjSGc42Wi3rGcid4rY3KQrXvOSI hB33m25KMBX4lVhxsJzWZMprwTbit4nwXV7ss1BvRyPL62NRMyytwk8Sn9IDKVyS BQpOmIOj9yXwemvoxqLlv9w2WppZGG6FOJTCujTRBx4shNanyXM8FHOx3G44wd0T /erMG0Jrikid8YFL9Qd2Ducqzba7YEq0ti3VDMpzxv8CN271usmJJGeuoP5NUFVH QhW6mqLY5cC3jStUVRKG =ajY0 -----END PGP SIGNATURE----- --nextPart1675202.eOFdqlj8Qf-- From nobody Wed Jul 8 11:21:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E6B1A6F38 for ; Wed, 8 Jul 2015 11:21:45 -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 VNSLpVLqE4wp for ; Wed, 8 Jul 2015 11:21:44 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5C41A6F29 for ; Wed, 8 Jul 2015 11:21:41 -0700 (PDT) Received: by igrv9 with SMTP id v9so206328032igr.1 for ; Wed, 08 Jul 2015 11:21:41 -0700 (PDT) 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=OmIUai6sn85f9frNW/QzpBmq/kOWx0Zmil29nUBR5sE=; b=o17Pc4zShVH/AQT5Z8XjJZKScyf0LuPltKjDOZP3LVsmA84LJB6/4pjVYoCrNdqzJH yToJdPqtkC2AX7NKuwiE2YdPUg7+UBGRt+DrPuSaesWLnNzNBQEqFrzpXN7lQOUwW5rJ q7g8PnJpbZ8MH53MQLL+AvjG9V0RE6ARu68vG9zb/kvdw/d4VEAg/wlOj4Y9/XnmCtSD RtitLf3hJNRtR1TgO4nxsuHjz3hgpaVetrcoBNLzzUmLtViGuf4T5J+165eR8FeSAWAH SKw5DzSDL9b7hsKVv5Q/jVnatzsMGQcetsU67UV21wyDrmzMwRsrRi+hJ44QqM2lpC3Y Vzqg== MIME-Version: 1.0 X-Received: by 10.107.157.4 with SMTP id g4mr19391653ioe.66.1436379701405; Wed, 08 Jul 2015 11:21:41 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 8 Jul 2015 11:21:41 -0700 (PDT) In-Reply-To: <20150707143431.GA853@LK-Perkele-VII> References: <201507031907.13872.davemgarrett@gmail.com> <201507031925.04809.davemgarrett@gmail.com> <20150707143431.GA853@LK-Perkele-VII> Date: Wed, 8 Jul 2015 14:21:41 -0400 Message-ID: From: Jeffrey Walton To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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: Wed, 08 Jul 2015 18:21:45 -0000 On Tue, Jul 7, 2015 at 10:34 AM, Ilari Liusvaara wrote: > On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote: >> On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote: >> > I think we probably need to have WG consensus for the SHA-1 thing. >> >> Yes, that's why I left it out of that changeset. I don't think the >> topic of what to do in the TLS 1.3 spec with SHA1 has been discussed >> on this list. (if it has, please point me to the thread if someone >> can) >> >> The simplest thing would be to have a MUST NOT offer or negotiate >> in 2017 or later and a NOT RECOMMENDED to use until then. Or, we >> could go deeper into the weeds and talk about expiration dates. >> Banning it totally for TLS 1.3+ is also an option, but probably not >> wanted yet. > > No, the simplest thing would be to ban it entierely: > - MUST ignore entries with MD5 or SHA1 hash in > supported_signature_algorithms, even if those are the only > ones (which will cause handshake failure). > - MUST terminate connection with insufficient_security if MD5 or > SHA1 is seen in DigitallySigned.algorithm. The browsers have already independently moved to do the same: * https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html * https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ * http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx Other user agents could probably get on a similar schedule with little to no hardship. I've noticed the OS (like Windows) and Frameworks (like .Net) seem to be driven by the web security model, so its not a leap at all. Its kind of like the tail wagging the dog - folks get the weaker security model by default, and have to do extra work to close gaps. Jeff From nobody Wed Jul 8 11:27:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096481A6FEB for ; Wed, 8 Jul 2015 11:27:46 -0700 (PDT) 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 qrbmQntJ6kgq for ; Wed, 8 Jul 2015 11:27:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE621A6FFA for ; Wed, 8 Jul 2015 11:27:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 827B5284D68; Wed, 8 Jul 2015 18:27:37 +0000 (UTC) Date: Wed, 8 Jul 2015 18:27:37 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150708182737.GW21534@mournblade.imrryr.org> References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 08 Jul 2015 18:27:46 -0000 On Wed, Jul 08, 2015 at 09:08:39PM +0300, Yoav Nir wrote: > It's possible that a single user might be issued multiple certificates, > but they will be from different CAs, and choosing a client certificate > based on CA will work. I don't see any use case for a corporate CA to > issue multiple certificates to the same user or device with different > algorithms. This is at least true for my use cases. Are root-CA self-signatures subject to the algorithm compatibility requirements on intermediate and leaf certificates? I was under the impression that root-CA self-signatures were exempted from such a constraint. My impression was that it is not uncommon to use the same (say SHA-1 self-signed) root CA to issue both a SHA-1 and a SHA2-256 intermediate CA, each of which then issues chains signed with the corresponding algorithm all the way down to the leaf. In the above scenario, the server's signal of which root-CA to choose does not help the client to interoperate with the server by using a certificate that matches the agreed algorithm. And I still expect that most servers and clients will have just one certificate chain to offer. Therefore, the requirement to return a chain that uses a shared algorithm or fail seems too strong. Returning what you have seems a lot more reasonable to me. The peer can reject the chain if so desired. -- Viktor. From nobody Wed Jul 8 11:28:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9621A6FF6 for ; Wed, 8 Jul 2015 11:28:53 -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 xnHO_Fvv6p2M for ; Wed, 8 Jul 2015 11:28:51 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657D21A6FF1 for ; Wed, 8 Jul 2015 11:28:51 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so161665687iec.3 for ; Wed, 08 Jul 2015 11:28:51 -0700 (PDT) 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=P+qdS6Kg0strO6o8mTtSaLHbFuIUSCvfQp8g2kRxF1o=; b=aDW5lXHHeCQ2TE06XRZOwgtjTzE0xscfc9YGgIvpcr3VC5C1yAQn2MCZkoyJ/v4E+r 8r8zNep2C23rC/iiJZfz1EebOCZrOlB9W/zzmMoAuXRDHZkQFXhcsNilZyqKVKRoIUNm 71kg9CgT7WXvybDedv4EnFGAl21mQ/QiOfldUIyTOWbVCVDbiwBS0rl/TFHVB8LbsUpL T5jrQ9JR8Mk5o4bfc7s1MhzT4cM/nPCUxH7XDgJPB3tj5vFIra+NEbAk42l0NeY3OVa/ WRX/Mo4NubHQAz/xVA8HigUiIOtO8rSy6ynO6KiondSH7QhIOEsW3NDuZq1SaOA2CyUa kDXA== MIME-Version: 1.0 X-Received: by 10.50.30.196 with SMTP id u4mr63691311igh.11.1436380130821; Wed, 08 Jul 2015 11:28:50 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 8 Jul 2015 11:28:50 -0700 (PDT) In-Reply-To: References: <201507031925.04809.davemgarrett@gmail.com> <20150707143431.GA853@LK-Perkele-VII> <201507071054.57330.davemgarrett@gmail.com> Date: Wed, 8 Jul 2015 14:28:50 -0400 Message-ID: From: Jeffrey Walton To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek 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: Wed, 08 Jul 2015 18:28:53 -0000 > Let's distinguish between two different uses of SHA-1: > > 1. In certificates. > 2. In TLS signatures. > Marc Steven is engineering collisions on SHA-1 in 2^61. See the HashClash homepage at https://marc-stevens.nl/p/hashclash/. That's well within reach of many attackers given how cheaply one can purchase compute time on EC2 or Nova. 1024-bit RSA has been basically been deprecated, and it provided about 80-bits of security. I'm not sure what economic models those speculating on attacks are following, but adversaries usually perform the most economical attack first, not last. It kind of reminds me of the CAs ignoring the warnings about MD5. And then this happened: https://www.win.tue.nl/hashclash/rogue-ca/. Jeff From nobody Wed Jul 8 12:23:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0D1A1B6D for ; Wed, 8 Jul 2015 12:23:08 -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 k07MQqiov1dq for ; Wed, 8 Jul 2015 12:23:07 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2A61A1B5F for ; Wed, 8 Jul 2015 12:23:06 -0700 (PDT) Received: by qgef3 with SMTP id f3so55133392qge.0 for ; Wed, 08 Jul 2015 12:23:06 -0700 (PDT) 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=AzE4x034w0k4RXoR0GIGl7M9CAapd9WZ5oJNnfsOFr4=; b=WSwzdpkHyTEGUo4wshAiL69IF4sE5Zt4D6tQrgFFxbRon25BPQcd2dxQkDhxya3+K/ NcbjD5EtCwa7iGMPgWWCKRhhaDH4TVNxbvr6qn6t/2aEw8xnn5YqXjjviKc3RTR0wrlY 5w+00oQHc1oz7BJPkv6pasmqCFohAPfHEeS+RSahY1SspALoYPZ4ewUTQxIEL0C/75Px Heq4IF4OKQFSz0pN+lARmKQ608qPjx41yKSu7slNbk+GGtUOVrq7uujRh6lubF5Tl/2A f9R9B1Q+QhGbxN0FH6F0n9Re5ebOnGrILGuiOlzi+VIM7eF9cHm3fmqz77GfEM5ggZ1L 1agQ== X-Received: by 10.55.26.37 with SMTP id a37mr5124526qka.44.1436383386246; Wed, 08 Jul 2015 12:23:06 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id l79sm1915342qhl.24.2015.07.08.12.23.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Jul 2015 12:23:05 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 8 Jul 2015 15:23:03 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150708174549.336B51A1C7@ld9781.wdf.sap.corp> <201507081350.39322.davemgarrett@gmail.com> <4168412.YzbFrOzRpF@pintsize.usersys.redhat.com> In-Reply-To: <4168412.YzbFrOzRpF@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507081523.03733.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 19:23:08 -0000 On Wednesday, July 08, 2015 02:15:40 pm Hubert Kario wrote: > The IIS is behaving as the RFC requires it to (with the exception of TLS > alerts) - according to section 7.4.2 of RFC 5246 - bottom of page 48. I was just about to respond to this with the obvious joke: "It works perfectly fine except for the part that is broken" ... and then I read the spec and actually have to defend them here. There isn't actually a requirement of throwing an error alert in the spec, currently. There of course ~should~ be an alert, and it should be in the spec, but it isn't yet. Note, BTW, that my current WIP for MTI extensions already does have hard error cases added in, including a new alert: https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions There have already been a few spots that got clarifications on what errors should be expected, and I think this is an area that really should be given proper focus for TLS 1.3. We shouldn't have any spots where anyone can say: "huh, what should it do now?". In fact, I think a catch-all requirement that a server MUST always return ~something~ in response to a (mostly) valid client message might be helpful here. Radio silence in response to any error is a really bad scenario that makes dealing with things annoyingly difficult. Servers should only stealth block/drop connections when it's likely to be junk its receiving (e.g. DoS or explicitly invalid/unauthorized attempt). Dave From nobody Wed Jul 8 12:25:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C21A1BA4 for ; Wed, 8 Jul 2015 12:25:37 -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 JRaOw4I5YxSC for ; Wed, 8 Jul 2015 12:25:36 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01B21A1B9A for ; Wed, 8 Jul 2015 12:25:35 -0700 (PDT) Received: by wiclp1 with SMTP id lp1so89912824wic.0 for ; Wed, 08 Jul 2015 12:25:34 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=nvQ4dRS4EWtnt/rfKA1v6yVWhNagrzvVwYOXkp1cwGg=; b=Yxn781v831iIbUTRwRFMhUI8p2goH1XqVDDNVrTCC+jtwexHfxOO2LOiS1WdpHElXm pwAeys62Nvub4XLC+B2/z/IYWcIDBNDNWYFZ9dD95c6dLWJqy17QvHlNTxKjfgCCv/lv G77ZeFakYznFU2DDV5Foo+hSPJlCWa2HPwpzn5sc1hG+vFD42IBHGZPNlrCFlFVLXY8/ WS4lw263mIffH1fIzeHg0TlQo+Qe0kdpL0YhS5/BRFtXFRY8TSMdqTOhEsEQHCw+Ae6z /xrQ+ZnMn71kMKndo8srr4h1oACFbMEXUbu3xSiYzu2awRSlObINq72HmlWVbWq9KYh8 CLyA== X-Received: by 10.180.211.196 with SMTP id ne4mr116469692wic.23.1436383534711; Wed, 08 Jul 2015 12:25:34 -0700 (PDT) Received: from [192.168.1.15] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id q9sm4390488wiz.23.2015.07.08.12.25.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jul 2015 12:25:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150708182737.GW21534@mournblade.imrryr.org> Date: Wed, 8 Jul 2015 22:25:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1E312BED-3880-4B56-9E5A-47084A99712E@gmail.com> References: <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> <20150708182737.GW21534@mournblade.imrryr.org> To: tls@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2015 19:25:37 -0000 > On Jul 8, 2015, at 9:27 PM, Viktor Dukhovni = wrote: >=20 > On Wed, Jul 08, 2015 at 09:08:39PM +0300, Yoav Nir wrote: >=20 >> It's possible that a single user might be issued multiple = certificates, >> but they will be from different CAs, and choosing a client = certificate >> based on CA will work. I don't see any use case for a corporate CA to >> issue multiple certificates to the same user or device with different >> algorithms. This is at least true for my use cases. >=20 > Are root-CA self-signatures subject to the algorithm compatibility > requirements on intermediate and leaf certificates? I was under > the impression that root-CA self-signatures were exempted from such > a constraint. Root CAs are not subject to any restrictions. What I meant was that the = same user (or more to the point - the same device) can have multiple = certificates from multiple CAs for multiple applications. For example, = the user=E2=80=99s employer might have a corporate portal with user = certificates issued by the corporate CAs. Her employer may have also = deployed an SSL VPN solution that uses its own bundled CA to issue = certificates, and maybe the user=E2=80=99s bank also issues certificates = (there were a few of those in the 90s and early 00s, but they have = mostly given up on that). =20 Choosing which of these certificates to use is easy - the CA DN is in = the certificate request, and each portal asks for exactly one CA.=20 If instead we lived in a world where client certificates were provided = from commercial CAs, we would have trouble - perhaps the same CA issued = both the bank certificates and the SSL VPN certificate. How would the = browser know to send the correct identity? I don=E2=80=99t know the = answer to this hypothetical question about a hypothetical problem in a = hypothetical situation, but I=E2=80=99m pretty sure the answer is not to = hope that the CA issues certificates with different algorithms. Yoav= From nobody Wed Jul 8 12:36:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7BB1A21AF for ; Wed, 8 Jul 2015 12:36:51 -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_31=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 j8n68M9Sf4mB for ; Wed, 8 Jul 2015 12:36:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DC71A1BCF for ; Wed, 8 Jul 2015 12:36:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B17B0284D68; Wed, 8 Jul 2015 19:36:49 +0000 (UTC) Date: Wed, 8 Jul 2015 19:36:49 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150708193649.GX21534@mournblade.imrryr.org> References: <20150707205858.GH21534@mournblade.imrryr.org> <20150708182737.GW21534@mournblade.imrryr.org> <1E312BED-3880-4B56-9E5A-47084A99712E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E312BED-3880-4B56-9E5A-47084A99712E@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 08 Jul 2015 19:36:52 -0000 On Wed, Jul 08, 2015 at 10:25:31PM +0300, Yoav Nir wrote: > If instead we lived in a world where client certificates were provided > from commercial CAs, we would have trouble - perhaps the same CA issued > both the bank certificates and the SSL VPN certificate. How would the > browser know to send the correct identity? I don?t know the answer to this > hypothetical question about a hypothetical problem in a hypothetical > situation, but I?m pretty sure the answer is not to hope that the CA issues > certificates with different algorithms. Which I think supports my view, that signature algorithm constraints ought not strictly apply to client certificates. However, in the DANE WG we're going to be discussing an extension of DANE TLSA to client authentication, where "client" will typically not mean "user with a browser", but rather will likely be another server that initiates a connection. Such "clients" are just as likely to have multiple chains (varying by algorithm) as the servers they connect to (that is unlikely in both cases, but not never). Such clients are very likely to completely ignore the server's CA hints, and use whatever cert chain they have (modulo signature algorithm selection). So the question still stands, is sending what you have prohibited, or is the supported algorithms extension (in the context of certificate signatures) a hint to maximize interoperability, and not a prohibition of the algorithms not listed. I rather think that the "hint" perspective makes a lot more sense, because certificate chains are not generally built on the fly to comport with the negotiated parameters. So "send what you have" and let the peer accept/reject makes more sense to me. -- Viktor. From nobody Wed Jul 8 20:25:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FAB1A8A6A for ; Wed, 8 Jul 2015 20:25:09 -0700 (PDT) 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 Y65uiHGRZZwk for ; Wed, 8 Jul 2015 20:25:07 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FF51A8A67 for ; Wed, 8 Jul 2015 20:25:07 -0700 (PDT) Received: by wgov12 with SMTP id v12so26975112wgo.1 for ; Wed, 08 Jul 2015 20:25:06 -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=WR1BbzkCiEVJ1JMDRK6sEn2NiMVlKTd9ldBef+qGBwg=; b=0CGgYRUmA1p6sSmJhBCQgzEXecnDqO7tvjyCs27uQmntY7GliRRK9CRwUfoIg7m2MW KkKf8TGPXeLewCS8i71BQ5n94K0/R8gOvsn3WUdOwZ/XN8iQUKxnktMleitd9uop0nPW q5uONeSUypMEE3VSzdTSdDvVDpw/gb5SJ8sdN3PcsSF0VRM0TJGx7QSFhzUPQfgvzJyS Hvd4VNxvLR1oKXrV1bKfxcKf2Vi/WBC/eiyWdQRVT9HJm60xnN1Qyq8C9dJgOaWI+3xR f1LLg4vLKyq2Yc89SCJkQNsGEOqgh0pvIYfSKrldIGqmymgpo1+GPOrSKvfzjqZI9Qte WjoA== MIME-Version: 1.0 X-Received: by 10.180.79.134 with SMTP id j6mr81352960wix.83.1436412306073; Wed, 08 Jul 2015 20:25:06 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 8 Jul 2015 20:25:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Jul 2015 20:25:05 -0700 Message-ID: From: Watson Ladd To: Brian Sniffen Content-Type: multipart/alternative; boundary=f46d04428e44413062051a68cdcf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2015 03:25:09 -0000 --f46d04428e44413062051a68cdcf Content-Type: text/plain; charset=UTF-8 On Jul 7, 2015 8:17 AM, "Brian Sniffen" wrote: > > > > At these rates you saturate gigabit ethernet connections, which > > puzzles will not help with. In fact, they will make the problem worse. > > It's now normal to deploy one 10GbE NIC per CPU. CPU load is definitely > still the bottleneck. There is still going to be a bottleneck somewhere. The only question is can you serve more clients than an attacker can muster: plenty of zombies can solve puzzles. > > > What about improving performance? That avoids any protocol changes, > > and brings about the benefits you seem to want. > > By all means! But it'll take 10-20 years to get those performance > benefits out to the ends of the Earth. I hope we can have some > conversations using that technology in 2-5 years, but we should expect > to be supporting RSA-2048 at least through 2025 (or a few years after > it's discovered to be broken), and NIST curves through 2030. Why is deploying puzzles more likely to happen then faster crypto? > > I'm not happy (or sad) about those dates, but if we think we're going to > go faster than final death of SSLv2, MD5, and similar, we should be able > to explain why that would be. > > -Brian --f46d04428e44413062051a68cdcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 7, 2015 8:17 AM, "Brian Sniffen" <bsniffen@akamai.com> wrote:
>
>
> > At these rates you saturate gigabit ethernet connections, which > > puzzles will not help with. In fact, they will make the problem w= orse.
>
> It's now normal to deploy one 10GbE NIC per CPU.=C2=A0 CPU load is= definitely
> still the bottleneck.

There is still going to be a bottleneck somewhere. The only = question is can you serve more clients than an attacker can muster: plenty = of zombies can solve puzzles.

>
> > What about improving performance? That avoids any protocol change= s,
> > and brings about the benefits you seem to want.
>
> By all means!=C2=A0 But it'll take 10-20 years to get those perfor= mance
> benefits out to the ends of the Earth.=C2=A0 I hope we can have some > conversations using that technology in 2-5 years, but we should expect=
> to be supporting RSA-2048 at least through 2025 (or a few years after<= br> > it's discovered to be broken), and NIST curves through 2030.

Why is deploying puzzles more likely to happen then faster c= rypto?

>
> I'm not happy (or sad) about those dates, but if we think we'r= e going to
> go faster than final death of SSLv2, MD5, and similar, we should be ab= le
> to explain why that would be.
>
> -Brian

--f46d04428e44413062051a68cdcf-- From nobody Thu Jul 9 03:43:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C961AD068 for ; Thu, 9 Jul 2015 03:43:13 -0700 (PDT) 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 I-XUYH5uPZI0 for ; Thu, 9 Jul 2015 03:43:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9271AD067 for ; Thu, 9 Jul 2015 03:43:12 -0700 (PDT) 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 (Postfix) with ESMTPS id 99B922CD84C; Thu, 9 Jul 2015 10:43:11 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-167.brq.redhat.com [10.34.0.167]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t69Ah9GB000576 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 06:43:11 -0400 From: Hubert Kario To: Dave Garrett Date: Thu, 09 Jul 2015 12:43:09 +0200 Message-ID: <1972429.03AREYRsAB@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <201507081523.03733.davemgarrett@gmail.com> References: <20150708174549.336B51A1C7@ld9781.wdf.sap.corp> <4168412.YzbFrOzRpF@pintsize.usersys.redhat.com> <201507081523.03733.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2299335.WxHEuByXsK"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2015 10:43:13 -0000 --nextPart2299335.WxHEuByXsK Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 08 July 2015 15:23:03 Dave Garrett wrote: > On Wednesday, July 08, 2015 02:15:40 pm Hubert Kario wrote: > > The IIS is behaving as the RFC requires it to (with the exception o= f TLS > > alerts) - according to section 7.4.2 of RFC 5246 - bottom of page 4= 8. >=20 > I was just about to respond to this with the obvious joke: "It works > perfectly fine except for the part that is broken" ... and then I rea= d the > spec and actually have to defend them here. There isn't actually a > requirement of throwing an error alert in the spec, currently. There = of > course ~should~ be an alert, and it should be in the spec, but it isn= 't > yet. this is general behaviour of schannel implementation, as far as I've re= ad =20 > Note, BTW, that my current WIP for MTI extensions already does have h= ard > error cases added in, including a new alert: > https://github.com/davegarrett/tls13-spec/compare/pruning...davegarre= tt:man > datoryextensions >=20 > There have already been a few spots that got clarifications on what e= rrors > should be expected, and I think this is an area that really should be= given > proper focus for TLS 1.3. We shouldn't have any spots where anyone ca= n say: > "huh, what should it do now?". definitely agree, what action to take on an error state should be clear= ly=20 defined by the spec I'm quite sure that by differences in error handling you can fingerprin= t the=20 implementations very specifically - not catastrophic, but hardly ideal that being said, I don't think this part of spec is, let's say... "fort= unate". It should be left up to the client to decide if it likes the certificat= e or=20 not - not the server withholding it as a "you won't like it anyway". > In fact, I think a catch-all requirement that a server MUST always re= turn > ~something~ in response to a (mostly) valid client message might be h= elpful > here. Radio silence in response to any error is a really bad scenario= that > makes dealing with things annoyingly difficult. Servers should only s= tealth > block/drop connections when it's likely to be junk its receiving (e.g= . DoS > or explicitly invalid/unauthorized attempt). that was my general understanding for the TLS specs, given that we have= such=20 general alerts as "internal_error" and "handshake_failure" - but I can'= t point=20 to any specific part of RFC that says that. +1 for adding it to the TLS 1.3 spec =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2299335.WxHEuByXsK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVnlA9AAoJEJKo0bgB0vX1NRAQAIuHJcj2Q4hGk1Syztq7mvp7 Sf0++58oQOX9K8CafBlSV1Phz1way/Gg/fezzPmS2bJjNgoOZa6bdkh35f6LhDR5 aCrEpS/5f5NoI6nPP8CHGZHjn6anlE3hg+JZ3V+f2MAEDNX28Bn/KT/1+N8u/2Zf 3O6eq/P6bRhM3T3KJVSOLTxfMRZKtzTO7XTDBSkBSXrZ8Fbj539dbbFSl3tfKRlw 5itEDhg6eixqQQe1KDZaroL88Dl2jyEJKgww1NCmC0HwV6UIAHnmugEisWFy+0gN 32CS8lH4Fbuvx8MWGAALuq9rVcXRqQbls5QBrkKmcz5q4HT1qUhchj8dy4DFuyuD st30hXBt70Cdt/JAAnXYXyRMjajx7d6YvB06iAY1oYl+Pk6vdlGl9TSlhumJe7Qp Z+xMfeD1oObVx0lQyJiqocdeF4JbwfSFfnW5IGzxS4VniqJD7IfTEyLZoFPxsm2x 0adBZMAUAgGWyx1d5UgxeR/SsJRK8RbICFL0xXh7i727azorKgO8GAUmYuxxGJRi NcAzXpCprutKpPZ16WbNfVwfDVVqkcaY0K8nLsUyyxbdFYdeY9Yk84DRXzSBJSLV C6ZWYiNWjrPRsdVW2s6CzUuYu229OHRKcmL2UVrympyVoC0S0VmqLnyHXxx3r09r B7/ADeS9JZbm4P5lid1n =iqS/ -----END PGP SIGNATURE----- --nextPart2299335.WxHEuByXsK-- From nobody Thu Jul 9 05:20:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77D1AD356 for ; Thu, 9 Jul 2015 05:20:19 -0700 (PDT) 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 jBlJG3GKva6A for ; Thu, 9 Jul 2015 05:20:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1161AD2EE for ; Thu, 9 Jul 2015 05:20:16 -0700 (PDT) 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 (Postfix) with ESMTPS id 97CCBB7CCE for ; Thu, 9 Jul 2015 12:20:16 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-167.brq.redhat.com [10.34.0.167]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t69CKFuL007783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jul 2015 08:20:16 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 09 Jul 2015 14:20:04 +0200 Message-ID: <2960351.rch1apE1uy@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3774900.AVBmqFplr6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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, 09 Jul 2015 12:20:19 -0000 X-List-Received-Date: Thu, 09 Jul 2015 12:20:19 -0000 --nextPart3774900.AVBmqFplr6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 06 July 2015 04:48:14 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Layer Securit= y > Working Group of the IETF. >=20 > Title : Curve25519 and Curve448 for Transport Layer= > Security (TLS) Authors : Simon Josefsson > Manuel Pegourie-Gonnard > =09Filename : draft-ietf-tls-curve25519-01.txt > =09Pages : 11 > =09Date : 2015-07-06 >=20 > Abstract: > This document specifies the use of Curve25519 and Curve448 for > ephemeral key exchange in the Transport Layer Security (TLS) and > Datagram TLS (DTLS) protocols. It updates RFC 5246 (TLS 1.2) and = RFC > 4492 (Elliptic Curve Cryptography for TLS). As is described in secion 5.1. of RFC 4492, and then reiterated in=20 section 2.2. of this draft - the elliptic_curves (a.k.a. supported_grou= ps)=20 guides both the ECDH curves and curves understandable by peer for ECDSA= =20 signatures. As Curve25519 and Curve448 can only be used for ECDHE, maybe they shoul= d be=20 defined/named in the registry as such, to remove any ambiguity[1]: enum { Curve25519_ecdh(TBD1), Curve448_ecdh(TBD2), } NamedCurve; 1 - to not redo the mistake of diffie-hellman-group1-"really-group2"-s= ha1 in=20 SSH: https://tools.ietf.org/html/rfc4253#section-8.1 when the 2551= 9 and=20 448 are defined for some form of ECDSA =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart3774900.AVBmqFplr6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVnmb+AAoJEJKo0bgB0vX1BKwP/AxFd2nlwVq4W70Hfh5SP4fB 6YX1Dne4dlvlPeFasmpiXQ8cNj1Gy9y16jInx4SsPYlTw6tBI0FuWKIqhkhJi3Kl Z1kSFNPA8D1oyf/cyUw8YVTtP0zOEbZMW7gh8NOBpmhA5KWyEUEjswdsBoOMmszP 5Bw+DwbCbq/r53gH8tDqnnNWP0qP+qEd3bLgkBZAoLbDjA6sFbhb/skbRi3OaANi Y5tWr0tt+wBLSuqPH35zg5FW1/VVA9lcqHY9IUa/5f/ecNU8jWmUaBdoT1835uH+ pQoPdMJ5oCwuNEtUiqcaEp/ly/lqlBgrph/c4FXfCJKCzNWFF2GB2qUM/c/wiab+ 2FLNGJ5guxm2KMA1WwxYbau7oaBngTYSFwyLAPpjgMBZA90ehNvpx5BQ+anoMKug HF3KkU/XeSbL1six1o2zQEKydv7y8CrUG4q/o9HVFU03tAG3BneFuv/ArS9sMuEZ 64+hPJKQ25qwhSDpGb0nt1DZ4bpC9vNkaKNFfOyN2pEt6+t9EzsCBmB7mMIn3ZA/ OD/DIHfetZGZitjx8cUHSIHr3cp1L/hnfOgvVVDYpVt4nyVw87SwEPQO1JlLlGOd Dio54+sAhUaXAWqb19mcDGQoki9b5/yLiofAj3TGYKMMCBs27cQxA4DLpJsY0RZF zZiGfBYK03/R00cpwgVT =9m5l -----END PGP SIGNATURE----- --nextPart3774900.AVBmqFplr6-- From nobody Thu Jul 9 05:31:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EA11AD2DF for ; Thu, 9 Jul 2015 05:31:45 -0700 (PDT) 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 DsrduKhR0wul for ; Thu, 9 Jul 2015 05:31:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162501A3B9F for ; Thu, 9 Jul 2015 05:31:41 -0700 (PDT) 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 (Postfix) with ESMTPS id A14A13CBA33; Thu, 9 Jul 2015 12:31:41 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-167.brq.redhat.com [10.34.0.167]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t69CVdfA029546 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 08:31:40 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 09 Jul 2015 14:31:33 +0200 Message-ID: <1481010.DFpi5LKcUP@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1471962.4u47SiEIKr"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] New version of draft-lonc-tls-certieee1609-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, 09 Jul 2015 12:31:45 -0000 --nextPart1471962.4u47SiEIKr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 01 July 2015 12:08:22 Arnaud KAISER wrote: > Dear members of TLS WG, >=20 > A new version (-01) of draft-lonc-tls-certieee1609 has been submitted= . The > draft can be found here: > https://tools.ietf.org/html/draft-lonc-tls-certieee1609-01 >=20 > The proposal of this draft is to extend the TLS protocol to support > ITS-specific certificates defined by IEEE and ETSI. >=20 > Any comments are welcome. Also, if possible, we can do a short presen= tation > of the draft at the 93rd IETF meeting. In section 4 of draft, ec_point_formats also affects use of ECC =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1471962.4u47SiEIKr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVnmmqAAoJEJKo0bgB0vX11ksP/0t66YKkOdYNQmp/DSOYZ6YU 9vKQljcsNFbSBDAzRVcHWTwBZdNfljEK6fDEwDzGxDs9yEPIWnh8u+L/3rBEwZSC eeieOFPL8uBkbjyCDbDbx7w6mwHefTB0LP9VXGmqQjkkJPMOG+4IKu1SghAVWukR 3tZa//Ksck75VZyjdvWkEe0d9/CzvYokFWzdZh1J0wOzjVI9WXsbwMKn3uPTu/yc 440KFHJqaNKb3IJd4lDY6Kgx7mEm1xRRRNJBXzWZe0uAcDFGpy+zc3LJglvtvQvW AfB5hx76dkVkdGzXn9l5Mrw8GwbcDBr7l0w0dqufnsdfDNGyLNrvMHrIOaeQPnM/ 8O9Jji1hf8uZO6r1uQFrEMDqLHVooSj0Jt6wfAKSoyjAbIyJIz+ih9ZfZTZD84ck 5zt3UB8E9eNhnmJCQCrPRgb4FkX89pGM8G2e+Ghr5Esbt5TX5lHHsJnrw0aMZwIs cyQI2p+Sd+ZLKUljl2i/gwENXR09fDCIdDQX+bYUs9UgsBnAyvK4gzlxwI7HIFdd euMx08mjbeACwanF72PfROWTa3TAb+5vguDgfZ4YTjNFME1g2gsM7eB6cGhJSJME 1wydaSm5jzPrD/hz2Bw7a61/NcYww2g2aS7+nf63/qP/vUnBMiGnniU3+KZTaH7n gj2/Z0dzGcmIqzFeS5lD =1jxJ -----END PGP SIGNATURE----- --nextPart1471962.4u47SiEIKr-- From nobody Thu Jul 9 06:43:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EA51A9091 for ; Thu, 9 Jul 2015 06:43:22 -0700 (PDT) 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 IsMAqBKwfbGX for ; Thu, 9 Jul 2015 06:43:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711D21A90B4 for ; Thu, 9 Jul 2015 06:43:20 -0700 (PDT) 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 (Postfix) with ESMTPS id D205D1BE349; Thu, 9 Jul 2015 13:43:19 +0000 (UTC) Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t69DhGCM032711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 09:43:18 -0400 Message-ID: <1436449396.6877.4.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Arnaud KAISER , "tls@ietf.org" Date: Thu, 09 Jul 2015 15:43:16 +0200 In-Reply-To: References: 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: Subject: Re: [TLS] New version of draft-lonc-tls-certieee1609-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, 09 Jul 2015 13:43:22 -0000 On Wed, 2015-07-01 at 12:08 +0000, Arnaud KAISER wrote: > Dear members of TLS WG, > > A new version (-01) of draft-lonc-tls-certieee1609 has been > submitted. The draft can be found here: > https://tools.ietf.org/html/draft-lonc-tls-certieee1609-01 > > The proposal of this draft is to extend the TLS protocol to support > ITS-specific certificates defined by IEEE and ETSI. Hi, This draft uses the rfc6091 cert_type extension. If that is not intentional, rfc6091 was made obsolete by rfc7250 which uses the server_certificate_type and client_certificate_type extensions (even though the text doesn't mention that). regards, Nikos From nobody Thu Jul 9 07:14:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C911A9172 for ; Thu, 9 Jul 2015 07:14:47 -0700 (PDT) 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 XPz_y8v5isxz for ; Thu, 9 Jul 2015 07:14:46 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3381A9239 for ; Thu, 9 Jul 2015 07:14:44 -0700 (PDT) Received: by lagc2 with SMTP id c2so244249764lag.3 for ; Thu, 09 Jul 2015 07:14:42 -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:content-transfer-encoding; bh=qlJSvSwkbrK7PUc+GlB1TkXDHwSfKM1Ijxp8wiroR1o=; b=x1vvkMafDe6Qf1FkbVdAoFZHh9XBEgR2mBDIMyX7OMxsM+SYYjrUY55lq3Ue2Fsx1S bGXUnlqOJUIYaqUvwB/c+UVd0JL+I4Spy/Pv05FNryv9n4pTWNMpBLnp3SqCZ96REKfb OVv14X2cdVQmnQhPIE7C4mtLeU1ynXMASb5VfL5r6hLBtLLdtRM+BMFwJ3qrtKpPv6g0 PursWVyKfBJKC4V5sdRKNd5LZmZnSKp5/9tPgedyIu+4DM+y47/nNe6Gz6Tbh7xllWkl OQhmXdzQWUtzyVy/XZefIGoSu+R6m8GrXaW27iZ0Gym5gYOtjtnynFrXP8nXtjPi0FJZ ZILQ== MIME-Version: 1.0 X-Received: by 10.152.181.34 with SMTP id dt2mr14966619lac.84.1436451282621; Thu, 09 Jul 2015 07:14:42 -0700 (PDT) Received: by 10.112.148.105 with HTTP; Thu, 9 Jul 2015 07:14:42 -0700 (PDT) In-Reply-To: <20150708180747.8C9B11A1C7@ld9781.wdf.sap.corp> References: <201507081350.39322.davemgarrett@gmail.com> <20150708180747.8C9B11A1C7@ld9781.wdf.sap.corp> Date: Thu, 9 Jul 2015 16:14:42 +0200 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2015 14:14:47 -0000 On Wed, Jul 8, 2015 at 8:07 PM, Martin Rex wrote: > The issue here is the (lack of the) TLSv1.2 signature_algorithms extensio= n. > > Windows SChannel appears to treat the absence of this extension > the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha1,= dsa) > > If you send the TLSv1.2 signature_algorithms extension with the > algorithm matching the signature of the server certificate, > e.g. (sha256,rsa) in the above example, then a TLSv1.2 handshake will suc= ceed. Sounds like it is complying with the TLS v1.2 RFC. Fix your client. --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Thu Jul 9 09:38:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E541B2AD3 for ; Thu, 9 Jul 2015 09:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 oMjSYllbhESE for ; Thu, 9 Jul 2015 09:38:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id ABA131B2AD1 for ; Thu, 9 Jul 2015 09:38:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EA2C4290ED; Thu, 9 Jul 2015 16:38:39 +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 CBE56290E7; Thu, 9 Jul 2015 16:38:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436459919; bh=XDwxRT6GIDObrfJKRDaDNA+9P1HOmkD7lJiyeSA9WWk=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=W/vdY0eUSHOpji3/vZ9kMyPDiLTwNFP4vwgS1vDh+W5IwhA08pl/zaq/gykdwcN14 wRnB3ACNCheol0Vb7TM8W66WRE+JeiMh+b22IpM9gcRqfPxGHnDSr2TtOoU9Dx4lfW xFsbuGUUV7S26MftOFNoEJOW/fnICfpEAiDzEW1w= 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 4BE212029; Thu, 9 Jul 2015 16:38:39 +0000 (GMT) Received: from USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 9 Jul 2015 12:38:38 -0400 Received: from bos-mpeve.local (172.19.41.203) by USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Thu, 9 Jul 2015 12:38:38 -0400 From: Brian Sniffen To: Watson Ladd In-Reply-To: References: User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-apple-darwin13.4.0) Date: Thu, 9 Jul 2015 12:38:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2015 16:38:42 -0000 Watson Ladd writes: > On Jul 7, 2015 8:17 AM, "Brian Sniffen" wrote: >> >> >> > At these rates you saturate gigabit ethernet connections, which >> > puzzles will not help with. In fact, they will make the problem worse. >> >> It's now normal to deploy one 10GbE NIC per CPU. CPU load is definitely >> still the bottleneck. > > There is still going to be a bottleneck somewhere. The only question is can > you serve more clients than an attacker can muster: plenty of zombies can > solve puzzles. Not quite! Under a sufficiently big attack, we'll have to take *some* damage. But we can use puzzles---in particular in combination with resumption/PSK modes---to make some choices about where we take that damage. For example, mobile clients probably can't keep up with puzzles---but desktop browsers ought to be able to succeed at puzzles enough to justify asymmetric crypto once, then continue on. >> > What about improving performance? That avoids any protocol changes, >> > and brings about the benefits you seem to want. >> >> By all means! But it'll take 10-20 years to get those performance >> benefits out to the ends of the Earth. I hope we can have some >> conversations using that technology in 2-5 years, but we should expect >> to be supporting RSA-2048 at least through 2025 (or a few years after >> it's discovered to be broken), and NIST curves through 2030. > > Why is deploying puzzles more likely to happen then faster crypto? We get the benefit of puzzles when they hit the computationally powerful systems; those are mostly desktop browsers with a tight deployment loop. I don't think we get the benefit of faster crypto when they hit ~all the clients, and we can reasonably turn off slow crypto. I'd like both. -Brian From nobody Thu Jul 9 12:15:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019091A000B for ; Thu, 9 Jul 2015 12:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 1rgmvRM9fh42 for ; Thu, 9 Jul 2015 12:15:31 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDC21A000A for ; Thu, 9 Jul 2015 12:15:31 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2F54716A334; Thu, 9 Jul 2015 19:15:31 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1994216A30A; Thu, 9 Jul 2015 19:15:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436469331; bh=XV+X0x+8KFIbloSqLGG2XFlRG+EOPBk24z91mKmk0OA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MiAOMoeLLFoQ+z0Bee7MZcr3W3EjAGYkpclmFJo34XqrgdCUW2DklnKEIRf+2PU8C HRyT6rRrGCoAgT+yn2T7olTxAaPE65CHbfdxoZDkELZ5HAeBm11R/xvhmocghcZTAk +z2opQRbasvPQq+c0StXoDwtpkiyG7KfHzAqmNT4= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 12EA69803E; Thu, 9 Jul 2015 19:15:31 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 9 Jul 2015 14:15:18 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Thu, 9 Jul 2015 14:15:17 -0500 From: "Salz, Rich" To: "noloader@gmail.com" , Ilari Liusvaara Thread-Topic: [TLS] TLS 1.3 draft-07 sneak peek Thread-Index: AQHQs4N+HZfm/z0y00OjYka0WtcI8p3KVrOAgAADLYCAAAVTgIAASwyAgAAB/QCAAAqMgIAAAbCAgAADTQCABbUXgIAB0c2AgAFNT7A= Date: Thu, 9 Jul 2015 19:15:17 +0000 Message-ID: References: <201507031907.13872.davemgarrett@gmail.com> <201507031925.04809.davemgarrett@gmail.com> <20150707143431.GA853@LK-Perkele-VII> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2015 19:15:33 -0000 Clearly we need to discuss this more, but you're right about the browsers ,= and we're okay with SHA-1 being dropped from TLS 1.3 -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Jul 9 12:31:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D611A0022 for ; Thu, 9 Jul 2015 12:31:46 -0700 (PDT) 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 NXklrkGU1yaF for ; Thu, 9 Jul 2015 12:31:45 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58CB1A001C for ; Thu, 9 Jul 2015 12:31:44 -0700 (PDT) Received: by widjy10 with SMTP id jy10so253502677wid.1 for ; Thu, 09 Jul 2015 12:31:43 -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=h6nFt7H5FUN7MeNm4cynezUQ6btwR12ZtJ68qN9ssvU=; b=ZEe9EG+bCeznsBQmAB2z+AxRXaRYK8aNyjLzIrjUGkQKti/cLs9H1SZleL4jJVaqtD xo55SLFMpXxMKtHgNNz0ECg1yMiKVnrlKRT3xvhpg/VXDW/poXV5AKANFTcfquTYdtky RG7yFI2RWFgMq2yApgFEqAg09rYJScTcwkRq2wPxD29o4OveB9F0BGalhmmPztABDrts 2hvj9Te8u7TOvPuYm3/kXmj6YHrIAMMlGp6z3GpyNvREer5y+G9CezgggzeFmkEHiQRT AMT66GSAE6430JPjlyflrU3cTneLDtorzcbqQAoiwGDhplpsMopL9Ho57UcjeLSHbnnX 3okA== MIME-Version: 1.0 X-Received: by 10.194.172.130 with SMTP id bc2mr36046706wjc.85.1436470303563; Thu, 09 Jul 2015 12:31:43 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 9 Jul 2015 12:31:43 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 9 Jul 2015 12:31:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jul 2015 12:31:43 -0700 Message-ID: From: Watson Ladd To: Brian Sniffen Content-Type: multipart/alternative; boundary=089e013c63422ca2e5051a764e27 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2015 19:31:47 -0000 --089e013c63422ca2e5051a764e27 Content-Type: text/plain; charset=UTF-8 On Jul 9, 2015 9:38 AM, "Brian Sniffen" wrote: > > Watson Ladd writes: > > > On Jul 7, 2015 8:17 AM, "Brian Sniffen" wrote: > >> > >> > >> > At these rates you saturate gigabit ethernet connections, which > >> > puzzles will not help with. In fact, they will make the problem worse. > >> > >> It's now normal to deploy one 10GbE NIC per CPU. CPU load is definitely > >> still the bottleneck. > > > > There is still going to be a bottleneck somewhere. The only question is can > > you serve more clients than an attacker can muster: plenty of zombies can > > solve puzzles. > > Not quite! Under a sufficiently big attack, we'll have to take *some* > damage. But we can use puzzles---in particular in combination with > resumption/PSK modes---to make some choices about where we take > that damage. For example, mobile clients probably can't keep up with > puzzles---but desktop browsers ought to be able to succeed at puzzles > enough to justify asymmetric crypto once, then continue on. Let's assume you can handle X connections before dropping some. An attacker who can muster the resources to take up X connections wins. It doesn't matter which resource is limiting. > > >> > What about improving performance? That avoids any protocol changes, > >> > and brings about the benefits you seem to want. > >> > >> By all means! But it'll take 10-20 years to get those performance > >> benefits out to the ends of the Earth. I hope we can have some > >> conversations using that technology in 2-5 years, but we should expect > >> to be supporting RSA-2048 at least through 2025 (or a few years after > >> it's discovered to be broken), and NIST curves through 2030. > > > > Why is deploying puzzles more likely to happen then faster crypto? > > We get the benefit of puzzles when they hit the computationally powerful > systems; those are mostly desktop browsers with a tight deployment loop. > I don't think we get the benefit of faster crypto when they hit ~all the > clients, and we can reasonably turn off slow crypto. So now when puzzles turn on you start dropping mobile clients instead of randomly selected ones. Where is the win here? > > I'd like both. > > -Brian --089e013c63422ca2e5051a764e27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 9, 2015 9:38 AM, "Brian Sniffen" <bsniffen@akamai.com> wrote:
>
> Watson Ladd <watsonbladd@g= mail.com> writes:
>
> > On Jul 7, 2015 8:17 AM, "Brian Sniffen" <bsniffen@akamai.com> wrote:
> >>
> >>
> >> > At these rates you saturate gigabit ethernet connections= , which
> >> > puzzles will not help with. In fact, they will make the = problem worse.
> >>
> >> It's now normal to deploy one 10GbE NIC per CPU.=C2=A0 CP= U load is definitely
> >> still the bottleneck.
> >
> > There is still going to be a bottleneck somewhere. The only quest= ion is can
> > you serve more clients than an attacker can muster: plenty of zom= bies can
> > solve puzzles.
>
> Not quite!=C2=A0 Under a sufficiently big attack, we'll have to ta= ke *some*
> damage.=C2=A0 But we can use puzzles---in particular in combination wi= th
> resumption/PSK modes---to make some choices about where we take
> that damage.=C2=A0 For example, mobile clients probably can't keep= up with
> puzzles---but desktop browsers ought to be able to succeed at puzzles<= br> > enough to justify asymmetric crypto once, then continue on.

Let's assume you can handle X connections before droppin= g some. An attacker who can muster the resources to take up X connections w= ins. It doesn't matter which resource is limiting.

>
> >> > What about improving performance? That avoids any protoc= ol changes,
> >> > and brings about the benefits you seem to want.
> >>
> >> By all means!=C2=A0 But it'll take 10-20 years to get tho= se performance
> >> benefits out to the ends of the Earth.=C2=A0 I hope we can ha= ve some
> >> conversations using that technology in 2-5 years, but we shou= ld expect
> >> to be supporting RSA-2048 at least through 2025 (or a few yea= rs after
> >> it's discovered to be broken), and NIST curves through 20= 30.
> >
> > Why is deploying puzzles more likely to happen then faster crypto= ?
>
> We get the benefit of puzzles when they hit the computationally powerf= ul
> systems; those are mostly desktop browsers with a tight deployment loo= p.
> I don't think we get the benefit of faster crypto when they hit ~a= ll the
> clients, and we can reasonably turn off slow crypto.

So now when puzzles turn on you start dropping mobile client= s instead of randomly selected ones. Where is the win here?

>
> I'd like both.
>
> -Brian

--089e013c63422ca2e5051a764e27-- From nobody Thu Jul 9 12:39:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1AC1A0092 for ; Thu, 9 Jul 2015 12:39:29 -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 Ua6lXSjsxzYA for ; Thu, 9 Jul 2015 12:39:28 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FD21A008E for ; Thu, 9 Jul 2015 12:39:28 -0700 (PDT) Received: by qkhu186 with SMTP id u186so193157816qkh.0 for ; Thu, 09 Jul 2015 12:39:27 -0700 (PDT) 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=hT5xB7D73kyhVOrWCpuoshc3QbeAR3zogMcZXg4xsuI=; b=h1F6xQH+AQcGVO6BHEeXMYhXvpB2fXHd3ve/m2WA2MzkiAXGo/WfZaMMXE8DA57thU HsqL5mI/UCKSlm6/W3FJ7/suzELBX14bpPDuih8A4mmOWoDdtlZ+oN34bNNr0YvyspUA TuuDew6aSyWGpOtFo+usiSnBwZxDgbfB7CcSH3EboNguPMaDrBSm0ZKBNLyWQJtvmfzu N00YeDI5AMt1vqLGDC+Eb4f0llGN4x7plx3ITna0VTEJj7u0GeJbKFkY6cr2YJuxbeFi x9KJoznXK/TKEb5VeO1dHS54Nv5VZ4NtzkTNvSY1MWA29lkY89FIhTU21U0maIseev8n cr+Q== X-Received: by 10.140.150.142 with SMTP id 136mr25792190qhw.17.1436470767111; Thu, 09 Jul 2015 12:39:27 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 195sm4121756qhr.13.2015.07.09.12.39.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 Jul 2015 12:39:26 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 9 Jul 2015 15:39:25 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507091539.25403.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2015 19:39:29 -0000 I'm personally not a fan of the idea of raw processing puzzles. Has anyone investigated network puzzles of some sort, like requiring clients to retrieve a key/signature from a 3rd party? For example: a DDoS vulnerable server requests clients first get some token signed by a trusted 3rd party capable of handling heavy load & filtering DDoSes better, then can use that signed token to connect to desired server. Dave From nobody Fri Jul 10 07:31:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDF31B2C84 for ; Fri, 10 Jul 2015 07:31:14 -0700 (PDT) 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 T4DUPajFF4Ce for ; Fri, 10 Jul 2015 07:31:11 -0700 (PDT) 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 375761B2CCB for ; Fri, 10 Jul 2015 07:29:46 -0700 (PDT) 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 D924A2ADA0; Fri, 10 Jul 2015 16:29:44 +0200 (CEST) X-purgate-ID: 152705::1436538584-0000413A-5310A2E5/0/0 X-purgate-size: 2843 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id CAD70402EE; Fri, 10 Jul 2015 16:29:44 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C077C1A1D5; Fri, 10 Jul 2015 16:29:44 +0200 (CEST) In-Reply-To: To: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= Date: Fri, 10 Jul 2015 16:29:44 +0200 (CEST) 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: <20150710142944.C077C1A1D5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 10 Jul 2015 14:31:14 -0000 Henrik Grubbstr=F6m wrote: > Martin Rex wrote: >> The issue here is the (lack of the) TLSv1.2 signature_algorithms extensi= on. >> >> Windows SChannel appears to treat the absence of this extension >> the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha1= ,dsa) >> >> If you send the TLSv1.2 signature_algorithms extension with the >> algorithm matching the signature of the server certificate, e.g. >> (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed. >=20 > Sounds like it is complying with the TLS v1.2 RFC. Fix your client. Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions. SCHannel is violating a MUST requirement, failing to properly process a ServerHello without a TLS extension. https://tools.ietf.org/html/rfc5246#section-7.4.1.2 7.4.1.2 ClientHello extensions Clients MAY request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 7.4.1.4. A server MUST accept ClientHello messages both with and without the extensions field, The interpretation of rfc5246 that Microsoft is using to explain the broken behaviour is in clear conflict with rfc2119 section 6 https://tools.ietf.org/html/rfc2119#section-6 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Requiring a server admin to continue using a sha1WithRsaEncryption signed certificate and failing the handshake when a sha256WithRsaEncryption signed certificate is installed, or alternatively requiring the server admin to disable TLSv1.2 (which happens to be the default in Win7/2008R2) is a dumb idea and actively causing harm. So the alleged requirement they're looking at is either not meant the way they're reading it, or that requirement is simply VOID because it is clearly incompatible with rfc2119 section 6. What the implementor did not take into account is the warning sign on the front of rfc5246, where it says "Proposed Standard", which is explained by rfc2026: http://tools.ietf.org/html/rfc2026#section-4.1.1 Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. -Martin From nobody Fri Jul 10 07:44:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A31B2C94 for ; Fri, 10 Jul 2015 07:44:38 -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 JBBBFKccpjJk for ; Fri, 10 Jul 2015 07:44:37 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845B81B2C8F for ; Fri, 10 Jul 2015 07:44:36 -0700 (PDT) Received: by wiga1 with SMTP id a1so17406479wig.0 for ; Fri, 10 Jul 2015 07:44:35 -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:content-transfer-encoding; bh=ap8zeSUHgrLo8UToEByVWunb4iNSj4tmFMwUfQgdYDY=; b=X9mxqQVPH7JwB9OzazUN5kDH4/Dxm+yWKqOia/O0h9OMpON87WtaPpVALUNGJrbXv/ 1NrWWU3wuj+GtHVvNktb8myWR539YDhE3WGrAApgmSRdcJzgasNdj509YKXKMvRH7wej TDMkbX/lgTHqC+2UKSQgbcGyF3l5bBpKRtXVQEOj41BowL/IUJkf5tiRCHWMbbH7327y ird325IGgM3RoHpUxD3E41R/460oI3f40DD/91yx2ZM0y57v33VGBz412HRdNdIkLW8e Js7Eq1aGZAsK2S2Ix8D+ceRZ1ZbSLWhlWxcZYwoQg0We9yJLMlvKPAvYOfKvN3dG2buW ahlA== MIME-Version: 1.0 X-Received: by 10.194.20.161 with SMTP id o1mr43664937wje.32.1436539475329; Fri, 10 Jul 2015 07:44:35 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Fri, 10 Jul 2015 07:44:35 -0700 (PDT) In-Reply-To: <20150710142944.C077C1A1D5@ld9781.wdf.sap.corp> References: <20150710142944.C077C1A1D5@ld9781.wdf.sap.corp> Date: Fri, 10 Jul 2015 07:44:35 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2015 14:44:39 -0000 On Fri, Jul 10, 2015 at 7:29 AM, Martin Rex wrote: > Henrik Grubbstr=C3=B6m wrote: >> Martin Rex wrote: >>> The issue here is the (lack of the) TLSv1.2 signature_algorithms extens= ion. >>> >>> Windows SChannel appears to treat the absence of this extension >>> the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha= 1,dsa) >>> >>> If you send the TLSv1.2 signature_algorithms extension with the >>> algorithm matching the signature of the server certificate, e.g. >>> (sha256,rsa) in the above example, then a TLSv1.2 handshake will succee= d. >> >> Sounds like it is complying with the TLS v1.2 RFC. Fix your client. > > > Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions= . > SCHannel is violating a MUST requirement, failing to properly process > a ServerHello without a TLS extension. Specific overrules general. > > https://tools.ietf.org/html/rfc5246#section-7.4.1.2 > > 7.4.1.2 ClientHello > > extensions > Clients MAY request extended functionality from servers by sending > data in the extensions field. The actual "Extension" format is > defined in Section 7.4.1.4. > > > A server MUST accept ClientHello > messages both with and without the extensions field, > > > The interpretation of rfc5246 that Microsoft is using to explain the > broken behaviour is in clear conflict with rfc2119 section 6 This interpretation is so obviously wrong. ECDHE support requires sending extensions. A server configured to only support ECDHE ciphersuites will fail any handshake that doesn't contain the necessary extensions. You cannot expect psychic servers to negotiate unadvertised features. Why can't you advertise support for the signatures you in fact support, if you want to advertise support? > > https://tools.ietf.org/html/rfc2119#section-6 > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > > Requiring a server admin to continue using a sha1WithRsaEncryption > signed certificate and failing the handshake when a sha256WithRsaEncrypti= on > signed certificate is installed, or alternatively requiring the server > admin to disable TLSv1.2 (which happens to be the default in Win7/2008R2) > is a dumb idea and actively causing harm. If clients don't support sha256WithRsaEncryption, they won't work with that server. The problem is clients failing to advertise features, then their authors complaining about lack of psychic abilities on the behalf of servers. > > So the alleged requirement they're looking at is either not meant > the way they're reading it, or that requirement is simply VOID because > it is clearly incompatible with rfc2119 section 6. > > > What the implementor did not take into account is the warning sign > on the front of rfc5246, where it says "Proposed Standard", > which is explained by rfc2026: > > http://tools.ietf.org/html/rfc2026#section-4.1.1 > > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Jul 10 08:05:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C391A92F7 for ; Fri, 10 Jul 2015 08:05:19 -0700 (PDT) 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 dzvaSMOE0FLL for ; Fri, 10 Jul 2015 08:05:17 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78BA1AD351 for ; Fri, 10 Jul 2015 08:05:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 30658284D69; Fri, 10 Jul 2015 15:05:15 +0000 (UTC) Date: Fri, 10 Jul 2015 15:05:15 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150710150514.GS28047@mournblade.imrryr.org> References: <20150710142944.C077C1A1D5@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.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Fri, 10 Jul 2015 15:05:19 -0000 On Fri, Jul 10, 2015 at 07:44:35AM -0700, Watson Ladd wrote: > > Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions. > > SCHannel is violating a MUST requirement, failing to properly process > > a ServerHello without a TLS extension. > > Specific overrules general. While I don't agree with the line of argument that Martin takes to support his position, I still agree with the conclusion that the Schannel behaviour is unfortunate. If the client does not signal the signature algorithms extension, and the server's chain is not SHA-1, it should use whatever chain it has. Withholding the chain the server has is counterproductive. Yes, extensions are needed to negotiate the use of SHA2-256 for TLS MAC computations, but forcing the certificate chain signatures issued by arms-length CAs to agree with the client's preference for message MAC algorithms is I think needless restrictive. Yes, when possible servers should provide a chain that is more likely to be understood by the client. But refusing to provide the chain they have, just because the client did not disclose every signature algorithm it supports (or simply did not send any) is a mistake in the implementation and likely a design error in the specification. I encourage implementations to ignore the MUST in question, and respond with some default chain even if it does not match the client's signature algorithms extension. The client may well be able to handle the new chain, or may not even care about the CA signatures at all (e.g. opportunistic TLS or DANE-EE(3)). -- Viktor. From nobody Fri Jul 10 08:38:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAED1B29F8 for ; Fri, 10 Jul 2015 08:37:58 -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 b7Q-XN4xp03m for ; Fri, 10 Jul 2015 08:37:56 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CCE1B29FE for ; Fri, 10 Jul 2015 08:37:47 -0700 (PDT) Received: by qkdv3 with SMTP id v3so13978951qkd.3 for ; Fri, 10 Jul 2015 08:37:46 -0700 (PDT) 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=+vLCgBACXfuovxGEkBvaMEj7XRAQN4SV1hEvr9bh/MU=; b=gyzQoAEN9/n1LG0SywP4kHCXMgaeAplHFbPMDu6/VTveKoAEeUX9J9PnuJlv9Ol2GE 6mj1rpRQYh5mUzrnReqtaW56RJHLDdDb9r43H2n50iFDOCCuqLuxiGVhJ5MTWEEBErRs WhFQ1Sbh5KQqZ7Uj8oQOUjtrrOHOAKXNO3TNIkoh0hvZJIKdtKmXcByfmUcQ8IIYrnoy kGvyDgQbwJsKmWgk9Jnn2YMwFlAHdel69FV0yG/RJhRIxZgp4qFWRB6KnAFCw+MS38nP oTqR8MKHRwn2gnHOGU7jw357jPF4hdC1xys/Dk9K6SkEYAbXpXUNQ9Eve4TJWBrL80G2 4SWA== X-Received: by 10.140.96.38 with SMTP id j35mr33989715qge.43.1436542666495; Fri, 10 Jul 2015 08:37:46 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id f106sm5899470qgd.30.2015.07.10.08.37.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Jul 2015 08:37:45 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 10 Jul 2015 11:37:44 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150710150514.GS28047@mournblade.imrryr.org> In-Reply-To: <20150710150514.GS28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507101137.44703.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2015 15:37:59 -0000 On Friday, July 10, 2015 11:05:15 am Viktor Dukhovni wrote: > Yes, when possible servers should provide a chain that is more > likely to be understood by the client. But refusing to provide > the chain they have, just because the client did not disclose every > signature algorithm it supports (or simply did not send any) is a > mistake in the implementation and likely a design error in the > specification. A TLS 1.2 client is not capable of not indicating at least some set of support. (unless it sends an invalid empty extension) https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the signature_algorithms extension, listing the algorithms it is willing to accept. If the client does not send the signature_algorithms extension, the server MUST do the following: [use SHA1 defaults] The only instance a TLS 1.2 client is allowed to omit the extension is when it only support the defaults. If it doesn't support the default or supports something else (or both) then it MUST send the extension. The server MUST interpret the lack of an extension as equivalent to sending SHA1 support. A client not sending the extension is telling the server not to send it anything other than SHA1. Yes, it doesn't explicitly say what the server should do when the client has not indicated support for anything it has, but a client is in the wrong for not indicating it. The client side is a spec error; the server side is just problematic. Dave From nobody Fri Jul 10 08:48:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F931B2A4C for ; Fri, 10 Jul 2015 08:48:37 -0700 (PDT) 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 3UXW7arWggir for ; Fri, 10 Jul 2015 08:48:35 -0700 (PDT) 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 3B0061B2A30 for ; Fri, 10 Jul 2015 08:48:35 -0700 (PDT) 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 7E7EB2A84F; Fri, 10 Jul 2015 17:48:33 +0200 (CEST) X-purgate-ID: 152705::1436543313-0000413A-F72D566F/0/0 X-purgate-size: 3947 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 706E5404B6; Fri, 10 Jul 2015 17:48:33 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6B5D31A1D5; Fri, 10 Jul 2015 17:48:33 +0200 (CEST) In-Reply-To: To: Watson Ladd Date: Fri, 10 Jul 2015 17:48:33 +0200 (CEST) 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: <20150710154833.6B5D31A1D5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 10 Jul 2015 15:48:37 -0000 Watson Ladd wrote: > >> >> https://tools.ietf.org/html/rfc5246#section-7.4.1.2 >> >> 7.4.1.2 ClientHello >> >> extensions >> Clients MAY request extended functionality from servers by sending >> data in the extensions field. The actual "Extension" format is >> defined in Section 7.4.1.4. >> >> >> A server MUST accept ClientHello >> messages both with and without the extensions field, >> >> >> The interpretation of rfc5246 that Microsoft is using to explain the >> broken behaviour is in clear conflict with rfc2119 section 6 > > > ECDHE support requires sending extensions. This claim is also clearly invalid. Btw. rfc4492 is *NOT* a standard, and implementing TLSv1.2 does not require support for ECC (and neither does TLSv1.2 require support for any AES-GCM cipher suites). Our TLSv1.2 client, where we noticed the Microsoft SChannel goof, does neither implement ECC nor AES-GCM. rfc4492 says: 4. TLS Extensions for ECC Two new TLS extensions are defined in this specification: (i) the Supported Elliptic Curves Extension, and (ii) the Supported Point Formats Extension. These allow negotiating the use of specific curves and point formats (e.g., compressed vs. uncompressed, respectively) during a handshake starting a new session. These extensions are especially relevant for constrained clients that may only support a limited number of curves or point formats. A TLS client that proposes ECC cipher suites in its ClientHello message SHOULD include these extensions. A client that proposes ECC cipher suites may choose not to include these extensions. rfc4492 is a little inconsistent here, because it uses both "SHOULD" and "may" for the very same client behaviour. > A server configured to only support ECDHE > ciphersuites will fail any handshake that doesn't contain the > necessary extensions. You cannot expect psychic servers to negotiate > unadvertised features. > > Why can't you advertise support for the signatures you in fact > support, if you want to advertise support? Because sending TLS extensions is backwards incompatible behaviour when you have never sent TLS extensions before, and it will cause some interop scenarios to fail. We are not allowed to ship backwards-incompatible behaviour that breaks existing usage scenarios as patch into the installed base. For the very same reason, the use of protocol version > TLSv1.0 on outgoing connections is a pure opt-in. >> >> Requiring a server admin to continue using a sha1WithRsaEncryption >> signed certificate and failing the handshake when a sha256WithRsaEncryption >> signed certificate is installed, or alternatively requiring the server >> admin to disable TLSv1.2 (which happens to be the default in Win7/2008R2) >> is a dumb idea and actively causing harm. > > If clients don't support sha256WithRsaEncryption, they won't work with > that server. The problem is clients failing to advertise features, > then their authors complaining about lack of psychic abilities on the > behalf of servers. So what. Leave the matter of dealing with a sha256WithRsaEncryption certificate to the client. This is particularly true for the extremely unhelpful SSL Alert that is meant to be used here (handshake_failure), and doubly so for Microsoft IIS -- which does not put any alerts on the wire before closing the connection. The latter might not be a problem of SChannel, which seems to create the alerts and potentially offers them at the SSPI interface, but might a flaw of the SChannel SSP application callers (Microsoft IIS, MSIE), to process a token that is returned from a context iterator (InitializeSecurityContext / AcceptSecurityContex) along with an SSPI error code. -Martin From nobody Fri Jul 10 08:49:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240811B2A3A for ; Fri, 10 Jul 2015 08:49:39 -0700 (PDT) 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 6zEhJ9GJZdK1 for ; Fri, 10 Jul 2015 08:49:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF651B2A46 for ; Fri, 10 Jul 2015 08:49:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 72CC1284D69; Fri, 10 Jul 2015 15:49:12 +0000 (UTC) Date: Fri, 10 Jul 2015 15:49:12 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150710154912.GU28047@mournblade.imrryr.org> References: <20150710150514.GS28047@mournblade.imrryr.org> <201507101137.44703.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507101137.44703.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Fri, 10 Jul 2015 15:49:39 -0000 On Fri, Jul 10, 2015 at 11:37:44AM -0400, Dave Garrett wrote: > > ... refusing to provide > > the chain they have, just because the client did not disclose every > > signature algorithm it supports (or simply did not send any) is a > > mistake in the implementation and likely a design error in the > > specification. > > The only instance a TLS 1.2 client is allowed to omit the extension is > when it only support the defaults. If it doesn't support the default or > supports something else (or both) then it MUST send the extension. The > server MUST interpret the lack of an extension as equivalent to sending > SHA1 support. A client not sending the extension is telling the server > not to send it anything other than SHA1. Suppose the server's certificate is signed with SHAKE256, but the client has no idea that SHA256 exists. Suppose also the client is doing opportunistic (unauthenticated TLS) or using DANE TLSA with the server's certificate binding published in a DANE-EE(3) digest. Then the client does not care what signatures may or may not be present in the server certificate. And yet the specification demands that the server abort the handshake. The specification is wrong, and implementations that follow it are not well thought out. With time we learn to ignore some elements of specifications that don't make sense. This is one such element. Perhaps it is not too late to fix this in 1.3, so that the specification does not demand unreasonable server behaviour. -- Viktor. From nobody Fri Jul 10 08:54:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D731B2C96 for ; Fri, 10 Jul 2015 08:54: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 6jgX7chNVFiv for ; Fri, 10 Jul 2015 08:54:56 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADA21B2A03 for ; Fri, 10 Jul 2015 08:54:56 -0700 (PDT) Received: by qgeg89 with SMTP id g89so131125694qge.3 for ; Fri, 10 Jul 2015 08:54:55 -0700 (PDT) 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=H7dsTBwt4KtzID0tYJuvYg9P65HpV0UAAvfFGzhR194=; b=j1TjYLUIHbLjyhzMiQbcrVzrQjhdcuyG6JYqeiV6j+qeiKoj1p4ltIP6k4TimFZ8i+ kQHV3t/4UVyI6/gchobu3wR7K3ibCV58+m/qgNaD/s6v3tQt0lG3ZcBm7Ha0c0l/2iL1 EHdaJXw4ZmYi4ByVpwS+Mgq9ItoUUZwWT9u3yBJv7hVW2mGnTDo9io1eE2uAcDPWDv0h MoW9B7gVd9B5NgCdM20rFVmXns10bMCbMXIbU+NhN/+8IJHgidEcbNQsBsWuBvZYOitJ CdmM8kAdHiBS5XhWo0LQq6nHEjn/ffJoT0IXWdrIn4iZWj68tewg8huPwWHGELNiFjOW O79g== X-Received: by 10.140.107.101 with SMTP id g92mr33433899qgf.58.1436543695493; Fri, 10 Jul 2015 08:54:55 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 20sm5604058qkz.30.2015.07.10.08.54.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Jul 2015 08:54:54 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 10 Jul 2015 11:54:53 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> In-Reply-To: <20150710154912.GU28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507101154.53812.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2015 15:54:57 -0000 On Friday, July 10, 2015 11:49:12 am Viktor Dukhovni wrote: > With time we learn to ignore some elements of specifications that > don't make sense. This is one such element. Which will lead to problems like this because not everyone will agree on what parts to ignore. If you want it to actually work reliably, you're going to need to follow or amend the spec. Dave From nobody Fri Jul 10 09:08:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133FC1B2CCC for ; Fri, 10 Jul 2015 09:08:51 -0700 (PDT) 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 Z0Te3O_cN60q for ; Fri, 10 Jul 2015 09:08:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86F91B2CBB for ; Fri, 10 Jul 2015 09:08:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C421A284D69; Fri, 10 Jul 2015 16:08:48 +0000 (UTC) Date: Fri, 10 Jul 2015 16:08:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150710160848.GW28047@mournblade.imrryr.org> References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507101154.53812.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Fri, 10 Jul 2015 16:08:51 -0000 On Fri, Jul 10, 2015 at 11:54:53AM -0400, Dave Garrett wrote: > On Friday, July 10, 2015 11:49:12 am Viktor Dukhovni wrote: > > With time we learn to ignore some elements of specifications that > > don't make sense. This is one such element. > > Which will lead to problems like this because not everyone will agree on > what parts to ignore. If you want it to actually work reliably, you're > going to need to follow or amend the spec. I am proposing that the specification bug be fixed in TLS 1.3. Indeed specification bugs are suboptimal. In cases such as this one, not implementing the specification bug leads to unconditionally improved behaviour. In some other cases, one has no choice but to implement the bug. For example, Postfix ignores a bug in RFC 5321 that suggests treating a 552 response to "RCPT TO" as though it were a 452 response. Following this causes more problems in practice than the mostly theoretical problem it solves. So if Andrey Poppv is still following this thread, I would like to suggest that Schannel be revised to be more tolerant of clients that don't offer a signature algorithm that matches the server's chain and use the server chain anyway. -- Viktor. From nobody Fri Jul 10 09:17:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022021B2CEA for ; Fri, 10 Jul 2015 09:17:09 -0700 (PDT) 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 0cPn1Jq-FhFy for ; Fri, 10 Jul 2015 09:17:07 -0700 (PDT) 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 25E991B2CE8 for ; Fri, 10 Jul 2015 09:17:07 -0700 (PDT) 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 D551C2A810; Fri, 10 Jul 2015 18:17:05 +0200 (CEST) X-purgate-ID: 152705::1436545025-0000413A-77FCFC7D/0/0 X-purgate-size: 2024 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id C5D234041A; Fri, 10 Jul 2015 18:17:05 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id BD6C71A1D5; Fri, 10 Jul 2015 18:17:05 +0200 (CEST) In-Reply-To: <201507101137.44703.davemgarrett@gmail.com> To: Dave Garrett Date: Fri, 10 Jul 2015 18:17:05 +0200 (CEST) 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: <20150710161705.BD6C71A1D5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 10 Jul 2015 16:17:09 -0000 Dave Garrett wrote: > On Friday, July 10, 2015 11:05:15 am Viktor Dukhovni wrote: >> >> Yes, when possible servers should provide a chain that is more >> likely to be understood by the client. But refusing to provide >> the chain they have, just because the client did not disclose every >> signature algorithm it supports (or simply did not send any) is a >> mistake in the implementation and likely a design error in the >> specification. > > https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 > > The only instance a TLS 1.2 client is allowed to omit the extension > is when it only support the defaults. If it doesn't support the default > or supports something else (or both) then it MUST send the extension. This is the result of an incorrect reading of rfc5246. If the TLSv1.2 client uses the *PERMITTED* option in section 7.4.1.2 ClientHello: extensions Clients MAY request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 7.4.1.4. Then the entire Section 7.4.1.4 HelloExtensions and all of its SubSections are completely irrelevant to that client. There is no (valid) prohibition of TLSv1.0 and TLSv1.1 clients and servers to use server certificate that is signed by sha256WithRsaEncryption, and as you can test yourself, Microsoft SChannel will properly handshake with these protocol versions and a server certificate that has a (sha256,rsa) signature. The only situation where Microsoft SChannel crashes and burns is when an extension-less ClientHello arrives with ClientHello.client_version = (3,3). Was TLSv1.2 really meant to be backwards-incompatible to TLSv1.0 and TLSv1.1 and create new problems for the migration from sha1-signed server certs to sha256-signed server certificates, considering that sha1-signed certs had already been officially been deprecated (e.g. by NIST) more than a year before TLSv1.2 (rfc5246) was published. -Martin From nobody Fri Jul 10 09:39:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CB91B29D9 for ; Fri, 10 Jul 2015 09:39:41 -0700 (PDT) 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 l9wkHn4Sok-m for ; Fri, 10 Jul 2015 09:39:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D9C1B29B7 for ; Fri, 10 Jul 2015 09:39:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 89067284D69; Fri, 10 Jul 2015 16:39:38 +0000 (UTC) Date: Fri, 10 Jul 2015 16:39:38 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150710163938.GX28047@mournblade.imrryr.org> References: <201507101137.44703.davemgarrett@gmail.com> <20150710161705.BD6C71A1D5@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150710161705.BD6C71A1D5@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Fri, 10 Jul 2015 16:39:41 -0000 On Fri, Jul 10, 2015 at 06:17:05PM +0200, Martin Rex wrote: > Was TLSv1.2 really meant to be backwards-incompatible to TLSv1.0 and TLSv1.1 > and create new problems for the migration from sha1-signed server certs > to sha256-signed server certificates, considering that sha1-signed certs > had already been officially been deprecated (e.g. by NIST) more than a > year before TLSv1.2 (rfc5246) was published. Martin, I think that focusing on a fine-grained scholarly analysis of the specification is a distraction. Even if the specification unequivocally requires servers to do as Schannel does (and there is some evidence that it does even if not univerally convincing), the specification is wrong. There are many situations where the server has little choice of what chains it can present, and the client is perfectly happy with chains that bear signatures it does not recognize. There is no reason for the server to abort the handshake on the unjustified presumption that the chains it has are unacceptable to the client. Lawyering the RFCs is not worth the effort, concede the law and go for jury nullification. -- Viktor. From nobody Fri Jul 10 09:52:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6B41B2A4A for ; Fri, 10 Jul 2015 09:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.961 X-Spam-Level: *** X-Spam-Status: No, score=3.961 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, RDNS_NONE=0.793, 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 yz8Vm0MVnl_M for ; Fri, 10 Jul 2015 09:52:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id A7EEE1B2A3E for ; Fri, 10 Jul 2015 09:52:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 384A649DD0; Fri, 10 Jul 2015 16:52:35 +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 21CB849DCE; Fri, 10 Jul 2015 16:52:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436547155; bh=WkzVnFTGSryOeeHzfDOHO7I+b5rISMpqoFC10T5845w=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=G0O1nxS0/bcC9wHhJmfMsXTwyZGFrVgixMgftqNXH1IzlJwoW8nRd9MMwPcSjRg8Q 0tRRnqwXr7E6h24ZCuaEwkzKRdZ3r96A+6oDhWoN7FJY9bx77pLSxMVugPB1M+2LxV Zmk3YfzNHR80Q9EmJ4/9h9JaxtUbyPnpDURwjuIo= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 7F34180084; Fri, 10 Jul 2015 16:52:18 +0000 (GMT) Received: from USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 10 Jul 2015 12:52:18 -0400 Received: from bos-mpeve.local (172.19.44.44) by USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Fri, 10 Jul 2015 12:52:17 -0400 From: Brian Sniffen To: Watson Ladd In-Reply-To: References: User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-apple-darwin13.4.0) Date: Fri, 10 Jul 2015 12:52:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2015 16:52:21 -0000 >>> There is still going to be a bottleneck somewhere. The only question >>> is can you serve more clients than an attacker can muster: plenty of >>> zombies can solve puzzles. >> >> Not quite! Under a sufficiently big attack, we'll have to take *some* >> damage. But we can use puzzles---in particular in combination with >> resumption/PSK modes---to make some choices about where we take that >> damage. For example, mobile clients probably can't keep up with >> puzzles---but desktop browsers ought to be able to succeed at puzzles >> enough to justify asymmetric crypto once, then continue on. > > Let's assume you can handle X connections before dropping some. An > attacker who can muster the resources to take up X connections wins. > It doesn't matter which resource is limiting. 1:1? I think the adversary-win threshold is much higher---more like 5X: I think the steady state depends on the following rates: Lp, New legitimate connections that show up for handshake per second, Ln, Legitimate Connections that die off per second, Rp, resumptions that show up per second per "open" legitimate connection An, Adversary connections that show up per second, X, Number of new handshakes that can be done per second, R, Number of resumptions that can be done per second. >>X If the number of new legitimate + adversary handshakes exceeds handshake capacity, some handshakes will fail, in proportion to the ratio of legitimate to adversary handshakes. If the elements of the adversary and legitimate populations are identical, an adversary with An=Lp only takes half the available capacity. Users hit "retry," half of them make it through, and over time the good people accumulate on the right side of the asymmetric crypto barrier. > So now when puzzles turn on you start dropping mobile clients instead > of randomly selected ones. Where is the win here? Predictability. Secondarily, the ability of clients (say, a proxy with a lot of users behind it) to invest in being able to make it through a pile-up. -Brian From nobody Fri Jul 10 09:58:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2600B1B2A58 for ; Fri, 10 Jul 2015 09:58: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 ojBB2MUCPMag for ; Fri, 10 Jul 2015 09:57:57 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D54E1B2A57 for ; Fri, 10 Jul 2015 09:57:57 -0700 (PDT) Received: by ykax123 with SMTP id x123so20371502yka.1 for ; Fri, 10 Jul 2015 09:57:56 -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=lNhoLBTzCXzRL7c9NAjIrFtzQZGO85xsDVqrMPE63Ak=; b=okwgqRX3MSs7L12s5xoY7y8Xf8TdktNAMOB1fhKCFQpMBLFQ1PSJ7A7eea4CpG8EqT CYaO3ts3lJ+sawjnDHB//wJ5Q80TUPRNFRZ13AoOXgPeU517i93M+D0M0RWDQhKMNJmr fILKZJc6rAU3wCTcghYrwX1sjEcu6KEXKiVLjfsR/OjRVIFu0g1HxfBgu5W16pL8PkDM v8lCCR+R5Mn3ZLqU56Nu02gdXk+VoEd3TfGPoQBJH6ZzkR+HUdhCeIEnADjqr6sycMxq bKPOImi3xyHbdn6KgywLtvrCJXUnRbocRSe5kPyePUJrtVcc76EtwIhziGK31isJJg8b dhIg== MIME-Version: 1.0 X-Received: by 10.170.94.84 with SMTP id l81mr24092571yka.101.1436547476538; Fri, 10 Jul 2015 09:57:56 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 10 Jul 2015 09:57:56 -0700 (PDT) In-Reply-To: <201507091539.25403.davemgarrett@gmail.com> References: <201507091539.25403.davemgarrett@gmail.com> Date: Fri, 10 Jul 2015 09:57:56 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2015 16:58:01 -0000 On 9 July 2015 at 12:39, Dave Garrett wrote: > I'm personally not a fan of the idea of raw processing puzzles. Has anyone investigated network puzzles of some sort, like requiring clients to retrieve a key/signature from a 3rd party? Computational puzzles can be reduced to that. If a mobile device can't solve a (small) bitcoin puzzle, it can contact a server that can. From nobody Fri Jul 10 10:05:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EC21B2A52 for ; Fri, 10 Jul 2015 10:05:27 -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 6HwypO9bKBwO for ; Fri, 10 Jul 2015 10:05:26 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9DF1B2A4B for ; Fri, 10 Jul 2015 10:05:26 -0700 (PDT) Received: by qgep37 with SMTP id p37so39985914qge.1 for ; Fri, 10 Jul 2015 10:05:25 -0700 (PDT) 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=BFBakWF5q22n8ZQAPra5lYatVULNNR0hKZz3YHFEN3k=; b=g93yIoMpKSdz3LVHxGixHqe68W8DtzAtvX19yItX34raiTuHxmOsO7W/8LKqtTv3d2 VXkW7PwWkRmITNcekGpiXR/eTwlmrN/Yzy0QUftBD+0f8O6mWrAVrfVFbHGyhWfu4da6 Y7P1GPFl1vMUGIP05LY6w877TsT8Lv7mYKMBNj9pqyEwM6sqVmg9XwMPslIu/kjsduCr uins4/E7dOjJqBarQu7ZRnbDfNbQMlVFHiycOBIx2bqAYTeEXogDffsp93cRLldq13xd S8W1H5qJ9CjVOEwQtBMWJvr5d5ToH3c6CCLt/FD4iRboyZvcXwddqJgh5xhOoKBY1/+2 yWrw== X-Received: by 10.55.27.70 with SMTP id b67mr35264263qkb.86.1436547925824; Fri, 10 Jul 2015 10:05:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 188sm5909592qhh.48.2015.07.10.10.05.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Jul 2015 10:05:25 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 10 Jul 2015 13:05:23 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507101137.44703.davemgarrett@gmail.com> <20150710161705.BD6C71A1D5@ld9781.wdf.sap.corp> <20150710163938.GX28047@mournblade.imrryr.org> In-Reply-To: <20150710163938.GX28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507101305.24222.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2015 17:05:28 -0000 On Friday, July 10, 2015 12:39:38 pm Viktor Dukhovni wrote: > Lawyering the RFCs is not worth the effort, concede the law > and go for jury nullification. I will take this as the thread ender. :p Dave From nobody Fri Jul 10 10:31:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB9C1A0371 for ; Fri, 10 Jul 2015 10:31:06 -0700 (PDT) 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, 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 XTv5Gg0AySKF for ; Fri, 10 Jul 2015 10:31:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3962B1A0369 for ; Fri, 10 Jul 2015 10:31:04 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.207.19; Fri, 10 Jul 2015 17:31:02 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0207.004; Fri, 10 Jul 2015 17:31:02 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpA= Date: Fri, 10 Jul 2015 17:31:01 +0000 Message-ID: References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> In-Reply-To: <20150710160848.GW28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::4] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:7q3yKniVCo88wiAToNyM30PVMDvh15hft2i2Z81+3aXz3reJuHQHmY0FkQLo7oAwA5DilrQMqPvcW0PvIX8Vh1g7mgu+lU2Neeg8jYHGHk5z0HF0fAfnZfPU1cljXDpKiG9L8TPeb8uaPEc/qeHNEA==; 24:8ZpTTFMxBdzdd6X93DGLR0HfNh7RpD+YNEQhCwY12KHu5jC0oFNjyBtKlOfBA+kNbnra2uCYsM/0z0xd5AlgmAgRpOiWUw9F+TxoicnaK/E=; 20:A+ubvqdpLZlq/1GqQQt9lP02TDrZdulXf86VDdvATUyf7q//g2Lt0E7S7dtHso+BBO5wsj9a2wFkBsbBcFK8VQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(51704005)(13464003)(24454002)(74316001)(2950100001)(5003600100002)(2900100001)(189998001)(102836002)(15975445007)(122556002)(40100003)(5002640100001)(86362001)(76576001)(93886004)(5001960100002)(107886002)(110136002)(54356999)(2501003)(46102003)(19580405001)(92566002)(2351001)(86612001)(5001920100001)(50986999)(76176999)(450100001)(87936001)(77156002)(77096005)(62966003)(2656002)(99286002)(33656002)(106116001)(19580395003)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 17:31:01.5337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2015 17:31:06 -0000 Hi Viktor, Quoting my previous response to this thread:=20 "It is possible that we might improve the product by not complying with sec= tion 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel does= comply." This thread has shown that it is hard to argue that schannel is RFC non-com= pliant WRT this particular problem. However, indeed it can be argued that i= n this case the product does not benefit from being RFC-compliant. =20 Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Friday, July 10, 2015 9:09 AM To: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek) On Fri, Jul 10, 2015 at 11:54:53AM -0400, Dave Garrett wrote: > On Friday, July 10, 2015 11:49:12 am Viktor Dukhovni wrote: > > With time we learn to ignore some elements of specifications that=20 > > don't make sense. This is one such element. >=20 > Which will lead to problems like this because not everyone will agree=20 > on what parts to ignore. If you want it to actually work reliably,=20 > you're going to need to follow or amend the spec. I am proposing that the specification bug be fixed in TLS 1.3. Indeed specification bugs are suboptimal. In cases such as this one, not i= mplementing the specification bug leads to unconditionally improved behavio= ur. In some other cases, one has no choice but to implement the bug. For example, Postfix ignores a bug in RFC 5321 that suggests treating a 552= response to "RCPT TO" as though it were a 452 response. Following this causes more problems in practice than the mostly theoretical= problem it solves. So if Andrey Poppv is still following this thread, I would like to suggest = that Schannel be revised to be more tolerant of clients that don't offer a = signature algorithm that matches the server's chain and use the server chai= n anyway. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jul 10 18:06:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AD71A1B5D for ; Fri, 10 Jul 2015 18:06:49 -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 kfcy6Hq0lvRZ for ; Fri, 10 Jul 2015 18:06:48 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A193A1A1B5A for ; Fri, 10 Jul 2015 18:06:48 -0700 (PDT) Received: by ietj16 with SMTP id j16so33259435iet.0 for ; Fri, 10 Jul 2015 18:06:48 -0700 (PDT) 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=EkR7NVpdlVM+qZc5yO4KvTVCifPdvTiYXnhf+ILNY7o=; b=ECiy7/WBZxypPauXskAcc7NcVPiYYHRraP1R4Ph16Arqw2k0FV8JlRmQBYIAUarRmW PTLSJVwTPCPj+nSQ5wz2BPq8cUFoNQXhtm1Xu5GuEbFhAPUGDDJrSAdO1f9ZUMrW8gYQ lAt7aOs9YaMblGx49wuURDPQk3Bc7zg5SvtzOj6F1PAUYyP67nnzIat+05nguKiFLADO X01lOMM3iROF1IcJ+opwkEd4WhMrJQaQIpAdeIbM43p17xIdbCDrvVwhT3VD0NREN6b+ uSbhGnGuSSDkFo4d235TmrVtkj9mopUxEZmSyUEsW9E3ZsXstMOaaALXV0C4BYN+5TVS cg4Q== MIME-Version: 1.0 X-Received: by 10.50.8.68 with SMTP id p4mr1627175iga.4.1436576808124; Fri, 10 Jul 2015 18:06:48 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Fri, 10 Jul 2015 18:06:48 -0700 (PDT) In-Reply-To: References: <201507091539.25403.davemgarrett@gmail.com> Date: Fri, 10 Jul 2015 21:06:48 -0400 Message-ID: From: Jeffrey Walton To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles 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: Sat, 11 Jul 2015 01:06:50 -0000 On Fri, Jul 10, 2015 at 12:57 PM, Martin Thomson wrote: > On 9 July 2015 at 12:39, Dave Garrett wrote: >> I'm personally not a fan of the idea of raw processing puzzles. Has anyone investigated network puzzles of some sort, like requiring clients to retrieve a key/signature from a 3rd party? > > Computational puzzles can be reduced to that. If a mobile device > can't solve a (small) bitcoin puzzle, it can contact a server that > can. Doesn't that sort of delegation open another attack surface? Jeff From nobody Fri Jul 10 19:33:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD78D1A1B66 for ; Fri, 10 Jul 2015 19:33:30 -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 c519C27m6ieH for ; Fri, 10 Jul 2015 19:33:26 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913A01A1B61 for ; Fri, 10 Jul 2015 19:33:26 -0700 (PDT) Received: by ykee186 with SMTP id e186so77129740yke.2 for ; Fri, 10 Jul 2015 19:33:25 -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=CfqcvfklN6tsMGWdCFShKcPpFZwoECVzSMLsBfcgLf4=; b=0hGctQdNULscEUX8+0p/C4LiP/7MAMNVwFSXChPJmlbCHl/KAEs91E40ZXzghXBIUa UQL943y/xFitl1wwDeXdcHXmJcxdxRABNsTX6Q69Y2phQ4GzVUt/mQVkOH+I8HnwNo9R hogi+lPnhSNKTc/PHy9zvGIeJTdSPeR5tGoY2F0Jh++zFxzWJZRjiiMLLt7XwE4giKYH b2X0pImor0DK1ALXcq+KGHroJP8vyPX8HtPLnGqZmF154y4MjaJgw8ntdMfbnwNRwuJu VO8j4nt5DFcrClBdRl8JQpMKCh5tmUlUZNDCAX81iLZmlyHtH/j+3DaAoiSH3Q/yJmJl L2Eg== MIME-Version: 1.0 X-Received: by 10.13.233.133 with SMTP id s127mr27338799ywe.154.1436582005897; Fri, 10 Jul 2015 19:33:25 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 10 Jul 2015 19:33:25 -0700 (PDT) In-Reply-To: References: <201507091539.25403.davemgarrett@gmail.com> Date: Fri, 10 Jul 2015 19:33:25 -0700 Message-ID: From: Martin Thomson To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Client Puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 02:33:30 -0000 On 10 July 2015 at 18:06, Jeffrey Walton wrote: >> Computational puzzles can be reduced to that. If a mobile device >> can't solve a (small) bitcoin puzzle, it can contact a server that >> can. > > Doesn't that sort of delegation open another attack surface? Not if you consider that the mobile device is known to the server it contacts at the time it makes the request. The problem puzzles address is one where the client identity is unknown until the server commits the work. From nobody Fri Jul 10 21:56:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB581A21C0 for ; Fri, 10 Jul 2015 21:56:11 -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 CdDGnT_pV-33 for ; Fri, 10 Jul 2015 21:56:10 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673521A21BE for ; Fri, 10 Jul 2015 21:56:10 -0700 (PDT) Received: by qget71 with SMTP id t71so137853189qge.2 for ; Fri, 10 Jul 2015 21:56:09 -0700 (PDT) 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=Bj4XQ+HX0ddAC94nw2/AmdfCwUgmz76ON01szpgTxrU=; b=am5ksTty70CM80Nfwf8EVp5m39wxiTyEn4oFyRaEfJgTLgdLQNNbCqQrDkezcQuCl6 HK4Yo9AMQy3DKlNmoGu0/cowZeP70AHnsd9Ms2mDAdwttwdHlYGyBmu62DZEDgGKOnm7 eN+tpfyMhXnkwUOsVIukMIIigWDWeri98eLk3EzJMDsb2AVQk3/e+nIhMCzC+HybAq8G LWGTLJuxM+4IeC+MyOyXcgVvPnZk69TJ2Mn06F1ViAWLHDQ8Ab6gotvrwiPRI6jvIbwQ eOZzo1FcmDWuX2cg1AxDdGslvmpuEowHFAXu+ZkxZz+WZT/lm0wWc5m6wMbC112pwAdl iheg== X-Received: by 10.55.15.144 with SMTP id 16mr37394446qkp.98.1436590569640; Fri, 10 Jul 2015 21:56:09 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 195sm7047375qhr.13.2015.07.10.21.56.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Jul 2015 21:56:09 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 11 Jul 2015 00:56:07 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150710160848.GW28047@mournblade.imrryr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507110056.07539.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Explicit error expectations (was Re: Deprecate SHA1 for signatures in 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, 11 Jul 2015 04:56:12 -0000 Due to discussion here, I've started a branch to add some better expectations or errors to deal with things more clearly. Just a WIP at this point: https://github.com/davegarrett/tls13-spec/compare/seanfixesredux...davegarrett:morealerts I've also expanded the alerts list to include all standardized as I needed one from another RFC, and SNI will be required, so the full current registry really needs to be listed here for reference. I already have another WIP branch for MTI extensions over here: https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions (showing branch diffs because each of these is based on PRs still pending review by ekr) If anyone has any more "MUST NOT" requirements that really should have a corresponding alert specified to go with it, please send me a PR onto my "morealerts" branch. (I haven't completely scoured the spec for them all yet) See also: https://github.com/tlswg/tls13-spec/issues/156 Dave From nobody Fri Jul 10 22:09:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF51A6EE9 for ; Fri, 10 Jul 2015 22:09:14 -0700 (PDT) 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 L0l3Fkx3wuxa for ; Fri, 10 Jul 2015 22:09:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4D51A6EE6 for ; Fri, 10 Jul 2015 22:09:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8871C284D68; Sat, 11 Jul 2015 05:09:11 +0000 (UTC) Date: Sat, 11 Jul 2015 05:09:11 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150711050911.GK28047@mournblade.imrryr.org> References: <20150710160848.GW28047@mournblade.imrryr.org> <201507110056.07539.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507110056.07539.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Explicit error expectations (was Re: Deprecate SHA1 for signatures in TLS 1.3) 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: Sat, 11 Jul 2015 05:09:14 -0000 On Sat, Jul 11, 2015 at 12:56:07AM -0400, Dave Garrett wrote: > Due to discussion here, I've started a branch to add some better > expectations or errors to deal with things more clearly. Just a WIP at > this point: > > https://github.com/davegarrett/tls13-spec/compare/seanfixesredux...davegarrett:morealerts Thanks for collecting these. Is there a reason to "perpetuate" the TLS 1.2 specification anomaly under discussion in this thread in lines 2207-2211: If a server receives a ClientHello, but the server cannot produce a valid certificate chain using the hash/signature pairs known to be supported by the client (via this extension or the defaults assumed in its absence), then the server MUST send an "unsupported_certificate" alert message and close the connection. Or are you just summarizing current state, with any proposed changes to be discussed separately? I still maintain that is clearly incorrect server behaviour, any specifications to the contrary notwithstanding. The decision of whether the chain is or is not supported by the client MUST be left to the client. The server does not have sufficient information to make this decision unilaterally (even if knows all the signature algorithms the client appears to support). -- Viktor. From nobody Fri Jul 10 23:45:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34021A1DBD for ; Fri, 10 Jul 2015 23:45:05 -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 YhRy2voI3dmM for ; Fri, 10 Jul 2015 23:45:01 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40911A1BFC for ; Fri, 10 Jul 2015 23:45:00 -0700 (PDT) Received: by qkhu186 with SMTP id u186so221202217qkh.0 for ; Fri, 10 Jul 2015 23:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=mXHGBe7bqCrE64C5x0JHBRfBKi/O3TBK+XjYVtrsgu4=; b=IT0pKaNgAu+H6HbsDE7iDcNcnFu/rmOMbIwEh9VOwZOtTNvB6f1gIO6fqSuKNHYnlw iqCB2MlGy6UbweLc/GHaU0nGefa3bJ6SI5SgfxQ1VMKp3BFnbwkbh2JT8rW7hvPmt2a1 UvpxgFPHeAkyLC7Xbhb7b1C05GUM1YRObOLANNWXmrFSIGpu213O2KlF/ydGWk94M3ec 5vQS7jxWeZq8pE0a3fxMu/pRg6+AafPRjIYDBWpIgLvqhGr1Y0pgbbz9u7sfxnN1k+dF /50TYnH56eV6oR5oTOugXXg+ig7xZVo5+SqniMkBrLuqARmTP7UjN/ClrfmL+wDNutVV 6Epg== X-Received: by 10.55.40.214 with SMTP id o83mr38870463qko.106.1436597100283; Fri, 10 Jul 2015 23:45:00 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 73sm3858198qkv.22.2015.07.10.23.44.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Jul 2015 23:44:59 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Viktor Dukhovni Date: Sat, 11 Jul 2015 02:44:58 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507110056.07539.davemgarrett@gmail.com> <20150711050911.GK28047@mournblade.imrryr.org> In-Reply-To: <20150711050911.GK28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507110244.58707.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Explicit error expectations (was Re: Deprecate SHA1 for signatures in 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, 11 Jul 2015 06:45:06 -0000 On Saturday, July 11, 2015 01:09:11 am Viktor Dukhovni wrote: > Or are you just summarizing current state, with any proposed changes > to be discussed separately? Yes. > The decision of whether the chain is or is not > supported by the client MUST be left to the client. The server > does not have sufficient information to make this decision unilaterally > (even if knows all the signature algorithms the client appears to > support). Just an idea, but maybe a way for the client to state that desire should be added? Maybe add "any(255)" values to the enums so clients could request, e.g. {any,rsa}+{any,ecdsa} or {any,any}, etc.? (there might be a better way to do this, though) I'm not against the idea that the server should be required to always send a valid cert chain, even if it believes the client can't handle it. At a minimum, this could be useful for debugging as the client would be sent something for you to figure out why it's not working. Dave From nobody Sat Jul 11 00:25:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBF11A3BA0 for ; Sat, 11 Jul 2015 00:25:52 -0700 (PDT) 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 yxrtCPqBaX2K for ; Sat, 11 Jul 2015 00:25:50 -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 0B4571A21BD for ; Sat, 11 Jul 2015 00:25:49 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 913CF18876B; Sat, 11 Jul 2015 10:25:47 +0300 (EEST) Date: Sat, 11 Jul 2015 10:25:47 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150711072547.GA4632@LK-Perkele-VII> References: <201507110056.07539.davemgarrett@gmail.com> <20150711050911.GK28047@mournblade.imrryr.org> <201507110244.58707.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201507110244.58707.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Explicit error expectations (was Re: Deprecate SHA1 for signatures in 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, 11 Jul 2015 07:25:52 -0000 On Sat, Jul 11, 2015 at 02:44:58AM -0400, Dave Garrett wrote: > On Saturday, July 11, 2015 01:09:11 am Viktor Dukhovni wrote: > > > The decision of whether the chain is or is not > > supported by the client MUST be left to the client. The server > > does not have sufficient information to make this decision unilaterally > > (even if knows all the signature algorithms the client appears to > > support). > > Just an idea, but maybe a way for the client to state that desire > should be added? Maybe add "any(255)" values to the enums so clients > could request, e.g. {any,rsa}+{any,ecdsa} or {any,any}, etc.? (there > might be a better way to do this, though) It is not about clients that can process any hash or signature algorithm, it is about if chain processing will terminate (reached "trust anchor") before the client runs into the unsupported hash/ signature and chokes. And that trust anchor might even be the public key in the end- entity certificate, which would cause every signature except the one EE public key itself makes[1] to be skipped (so even if the EE cert itself was signed by Foo/Bar, both of which are unknown to client, it would still work). [1] Obviously the client must know the signature algorithm the key uses or things just plain won't work. Additionally if the key forces hash algorithm (at least some CFRG signature proposals work that way), that hash needs to be known too. -Ilari From nobody Sat Jul 11 05:53:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0972A1B2B53 for ; Sat, 11 Jul 2015 05:53:11 -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 AJJ3s7pZOUp0 for ; Sat, 11 Jul 2015 05:53:09 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDCB1B2B52 for ; Sat, 11 Jul 2015 05:53:08 -0700 (PDT) Received: by wicmz13 with SMTP id mz13so31217477wic.0 for ; Sat, 11 Jul 2015 05:53:07 -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=mrSavLM/GrQhF+IHpDDNHDiREtefoXq7JvlAkpav5ro=; b=aMVquLKIr+mzySjhNkpsxF8XhnSQDfuhYXjUG/QwBnFVanaelo1n98PxwlELg2BicF RcDGjU/KA/TohCnJW5Bc2h6wS+vN0BjHUgnYru1SogiHMtiStLdyR8yN2spWfcfLpuMd PGD3oniAWLxiiGfTOsLQSh3mKhfaxQ5+4ZCilhw16sFK+l64Kw77tL919ZTCKVbEZwCM eA0lQTIlbI9wk/4pV6Q6JLNyYFSL4ENanydyeBBzG+QXro52KGRO/7r0NvbHPjXhbvzQ rpcjIZdivoCf9i56B+QyMhGPyVma8l/DTE21y9Hq45Dlzj1CgvOmRApnGXlL1t+Oh2+V WwUg== X-Gm-Message-State: ALoCoQmAMeY9SbsBuBUwbGQ7lgLyR6pu6LcOV0Cw0RgZB6Gko6Z9SO9hamhXMbZUvCR/nAcZY5M0 X-Received: by 10.194.79.225 with SMTP id m1mr50654228wjx.8.1436619187449; Sat, 11 Jul 2015 05:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Sat, 11 Jul 2015 05:52:27 -0700 (PDT) In-Reply-To: References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> From: Eric Rescorla Date: Sat, 11 Jul 2015 08:52:27 -0400 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=047d7b10c90358a4ce051a98f8e5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 12:53:11 -0000 --047d7b10c90358a4ce051a98f8e5 Content-Type: text/plain; charset=UTF-8 I'm not necessarily opposed to relaxing this requirement on the server, but given that: 1. SHA-1 is on its way out. 2. Future versions of TLS seem very likely to explicitly indicate which hash algorithms the clients support. I'm kind of confused about the principle being espoused here. In general, when the client has told the server what's acceptable and the server doesn't have it, we abort the handshake. What makes this case different from (say) the client only supporting P256 and the server only supporting Curve25519 but deciding to send Curve25519 anyway? -Ekr On Fri, Jul 10, 2015 at 1:31 PM, Andrei Popov wrote: > Hi Viktor, > > Quoting my previous response to this thread: > "It is possible that we might improve the product by not complying with > section 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel > does comply." > > This thread has shown that it is hard to argue that schannel is RFC > non-compliant WRT this particular problem. However, indeed it can be argued > that in this case the product does not benefit from being RFC-compliant. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni > Sent: Friday, July 10, 2015 9:09 AM > To: tls@ietf.org > Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS > 1.3 draft-07 sneak peek) > > On Fri, Jul 10, 2015 at 11:54:53AM -0400, Dave Garrett wrote: > > > On Friday, July 10, 2015 11:49:12 am Viktor Dukhovni wrote: > > > With time we learn to ignore some elements of specifications that > > > don't make sense. This is one such element. > > > > Which will lead to problems like this because not everyone will agree > > on what parts to ignore. If you want it to actually work reliably, > > you're going to need to follow or amend the spec. > > I am proposing that the specification bug be fixed in TLS 1.3. > > Indeed specification bugs are suboptimal. In cases such as this one, not > implementing the specification bug leads to unconditionally improved > behaviour. In some other cases, one has no choice but to implement the bug. > > For example, Postfix ignores a bug in RFC 5321 that suggests treating a > 552 response to "RCPT TO" as though it were a 452 response. > Following this causes more problems in practice than the mostly > theoretical problem it solves. > > So if Andrey Poppv is still following this thread, I would like to suggest > that Schannel be revised to be more tolerant of clients that don't offer a > signature algorithm that matches the server's chain and use the server > chain anyway. > > -- > Viktor. > > _______________________________________________ > 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 > --047d7b10c90358a4ce051a98f8e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not necessarily opposed to relaxing this requireme= nt on the server,
but given that:

1. SHA-1 is = on its way out.
2. Future versions of TLS seem very likely to exp= licitly indicate which
hash algorithms the clients support.
=

I'm kind of confused about the principle being espo= used here. In general,
when the client has told the server what&#= 39;s acceptable and the server
doesn't have it, we abort the = handshake. What makes this case different
from (say) the client o= nly supporting P256 and the server only supporting
Curve25519 but= deciding to send Curve25519 anyway?

-Ekr



On Fri, Jul 10, 2015 at 1:31 PM, Andrei Popov <A= ndrei.Popov@microsoft.com> wrote:
Hi Viktor,

Quoting my previous response to this thread:
"It is possible that we might improve the product by not complying wit= h section 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel= does comply."

This thread has shown that it is hard to argue that schannel is RFC = non-compliant WRT this particular problem. However, indeed it can be argued= that in this case the product does not benefit from being RFC-compliant.
Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.= org] On Behalf Of Viktor Dukhovni
Sent: Friday, July 10, 2015 9:09 AM
To: tls@ietf.org
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek)

On Fri, Jul 10, 2015 at 11:5= 4:53AM -0400, Dave Garrett wrote:

> On Friday, July 10, 2015 11:49:12 am Viktor Dukhovni wrote:
> > With time we learn to ignore some elements of specifications that=
> > don't make sense.=C2=A0 This is one such element.
>
> Which will lead to problems like this because not everyone will agree<= br> > on what parts to ignore. If you want it to actually work reliably,
> you're going to need to follow or amend the spec.

I am proposing that the specification bug be fixed in TLS 1.3.

Indeed specification bugs are suboptimal.=C2=A0 In cases such as this one, = not implementing the specification bug leads to unconditionally improved be= haviour.=C2=A0 In some other cases, one has no choice but to implement the = bug.

For example, Postfix ignores a bug in RFC 5321 that suggests treating a 552= response to "RCPT TO" as though it were a 452 response.
Following this causes more problems in practice than the mostly theoretical= problem it solves.

So if Andrey Poppv is still following this thread, I would like to suggest = that Schannel be revised to be more tolerant of clients that don't offe= r a signature algorithm that matches the server's chain and use the ser= ver chain anyway.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
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

--047d7b10c90358a4ce051a98f8e5-- From nobody Sat Jul 11 06:45:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52CE1A891A for ; Sat, 11 Jul 2015 06:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 MWGXmxL-o-pF for ; Sat, 11 Jul 2015 06:45:21 -0700 (PDT) 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 DD8AF1A8919 for ; Sat, 11 Jul 2015 06:45:19 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id B06F781844; Sat, 11 Jul 2015 16:45:16 +0300 (EEST) Date: Sat, 11 Jul 2015 16:45:16 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150711134516.GA6970@LK-Perkele-VII> References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 13:45:23 -0000 On Sat, Jul 11, 2015 at 08:52:27AM -0400, Eric Rescorla wrote: > I'm not necessarily opposed to relaxing this requirement on the server, > but given that: > > 1. SHA-1 is on its way out. > 2. Future versions of TLS seem very likely to explicitly indicate which > hash algorithms the clients support. > > I'm kind of confused about the principle being espoused here. In general, > when the client has told the server what's acceptable and the server > doesn't have it, we abort the handshake. What makes this case different > from (say) the client only supporting P256 and the server only supporting > Curve25519 but deciding to send Curve25519 anyway? The ECDH example involves something that will certainly blow up. Same with the server signature itself being made with unsupported algorithm. But with sending non-compliant certificates, the further up the chain the non-complance is, the more likely client processing will terminate before the client hits the "bad" signature and chokes. In some cases the last thing client processes might even be the public key of the end-entity certificate (never reaching the issuer signature of any certificate in chain). So if server wants to make last-ditch hail mary attempt, it would be picking certificate chain that contains accepted algorithms as far as possible (if it doesn't have EE certificate that can sign using the indicated algorithms, it can abort right away because it is not going to work[1]). It may or may not work, but at least it has the greatest probability of working. [1] Unless the client is buggy. -Ilari From nobody Sat Jul 11 06:56:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0CB1A8928 for ; Sat, 11 Jul 2015 06:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[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 cpb4iYA5T-sx for ; Sat, 11 Jul 2015 06:56:27 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C061A8924 for ; Sat, 11 Jul 2015 06:56:27 -0700 (PDT) Received: by lagx9 with SMTP id x9so279151072lag.1 for ; Sat, 11 Jul 2015 06:56:25 -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=valRZpS5ybGh+QVdPw/rmCsEfkKwhU9xD5zq+lOhvXg=; b=Vhn8YD5ypZ74ml1xyQ1Ghh5eNn/w2aDl2zaB8CMdBksrgn7H+PTQgDh7hyaVcZ4c6M I6om1c2UiYWsSDM0sxbEhaVx1BogIm7uszs/baWhQ7QQ6nX5GAcMRdwEN6anLrZdK8MD FzxF+JyRX+QPO44D/VaCvkZWwPeqTsNTNyUg6Eb/dxSvWoRu7bIHbXdDBXgbEc+XtceN NyG9GEJ9jp79tNH2xSUy8dV11VezQr7bT5cL1QHxkYCYI+/ykL5+HScXN1remU/Xs0qD ghAZcOMzQnsJwNqGJFEhskaTUWbPsb9nXTWL6fqjZymW/2jADqQN585Q0xyYtX+QdYG4 s3EQ== X-Gm-Message-State: ALoCoQkscoJJyymyTqUZUyZwLX3Q1fOweW3U5xrjTgBRT19FHhMKPmKi2jENWAx5dVb5BKfQWg4X X-Received: by 10.152.37.228 with SMTP id b4mr24114598lak.117.1436622985433; Sat, 11 Jul 2015 06:56:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.99.103 with HTTP; Sat, 11 Jul 2015 06:55:45 -0700 (PDT) In-Reply-To: <20150711134516.GA6970@LK-Perkele-VII> References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> <20150711134516.GA6970@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 11 Jul 2015 09:55:45 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e014939fcb92c48051a99dae4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 13:56:30 -0000 --089e014939fcb92c48051a99dae4 Content-Type: text/plain; charset=UTF-8 This makes a certain amount of sense (though I wonder how often it's really an issue that a server declines to send a certificate that would otherwise have worked to a compliant client [0]). Perhaps the right text here is that if you have a conformant certificate, you MUST send it, but if not, you MAY send a nonconformant one? -Ekr [0] As you say, with a buggy client all bets are off. On Sat, Jul 11, 2015 at 9:45 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Sat, Jul 11, 2015 at 08:52:27AM -0400, Eric Rescorla wrote: > > I'm not necessarily opposed to relaxing this requirement on the server, > > but given that: > > > > 1. SHA-1 is on its way out. > > 2. Future versions of TLS seem very likely to explicitly indicate which > > hash algorithms the clients support. > > > > I'm kind of confused about the principle being espoused here. In general, > > when the client has told the server what's acceptable and the server > > doesn't have it, we abort the handshake. What makes this case different > > from (say) the client only supporting P256 and the server only supporting > > Curve25519 but deciding to send Curve25519 anyway? > > The ECDH example involves something that will certainly blow up. Same with > the server signature itself being made with unsupported algorithm. > > But with sending non-compliant certificates, the further up the chain the > non-complance is, the more likely client processing will terminate before > the client hits the "bad" signature and chokes. In some cases the last > thing client processes might even be the public key of the end-entity > certificate (never reaching the issuer signature of any certificate > in chain). > > > So if server wants to make last-ditch hail mary attempt, it would be > picking certificate chain that contains accepted algorithms as far > as possible (if it doesn't have EE certificate that can sign using > the indicated algorithms, it can abort right away because it is > not going to work[1]). It may or may not work, but at least it has > the greatest probability of working. > > > [1] Unless the client is buggy. > > > -Ilari > --089e014939fcb92c48051a99dae4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This makes a certain amount of sense (though I wonder how = often it's really
an issue that a server declines to send a certifi= cate that would otherwise
have worked to a compliant client [0]).=

Perhaps the right text here is that if you have a= conformant certificate, you
MUST send it, but if not, you MAY se= nd a nonconformant one?

-Ekr
[0] As you say, with a buggy client all bets are off.


On Sat, Jul 11, 2015 at 9:45 AM, Ilari Liusvaara <ila= ri.liusvaara@elisanet.fi> wrote:
On Sat, Jul 11, 2015 at 08:52:27AM -0400, Eric Resco= rla wrote:
> I'm not necessarily opposed to relaxing this requirement on the se= rver,
> but given that:
>
> 1. SHA-1 is on its way out.
> 2. Future versions of TLS seem very likely to explicitly indicate whic= h
> hash algorithms the clients support.
>
> I'm kind of confused about the principle being espoused here. In g= eneral,
> when the client has told the server what's acceptable and the serv= er
> doesn't have it, we abort the handshake. What makes this case diff= erent
> from (say) the client only supporting P256 and the server only support= ing
> Curve25519 but deciding to send Curve25519 anyway?

The ECDH example involves something that will certainly blow up. Sam= e with
the server signature itself being made with unsupported algorithm.

But with sending non-compliant certificates, the further up the chain the non-complance is, the more likely client processing will terminate before the client hits the "bad" signature and chokes. In some cases the= last
thing client processes might even be the public key of the end-entity
certificate (never reaching the issuer signature of any certificate
in chain).


So if server wants to make last-ditch hail mary attempt, it would be
picking certificate chain that contains accepted algorithms as far
as possible (if it doesn't have EE certificate that can sign using
the indicated algorithms, it can abort right away because it is
not going to work[1]). It may or may not work, but at least it has
the greatest probability of working.


[1] Unless the client is buggy.


-Ilari

--089e014939fcb92c48051a99dae4-- From nobody Sat Jul 11 08:17:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9019E1A8AD0 for ; Sat, 11 Jul 2015 08:17:32 -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 ly-gEwf9fQDQ for ; Sat, 11 Jul 2015 08:17:31 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA3E1A8ACD for ; Sat, 11 Jul 2015 08:17:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EDA70284D6A; Sat, 11 Jul 2015 15:17:29 +0000 (UTC) Date: Sat, 11 Jul 2015 15:17:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150711151729.GO28047@mournblade.imrryr.org> References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> <20150711134516.GA6970@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Sat, 11 Jul 2015 15:17:32 -0000 On Sat, Jul 11, 2015 at 09:55:45AM -0400, Eric Rescorla wrote: > This makes a certain amount of sense (though I wonder how often it's really > an issue that a server declines to send a certificate that would otherwise > have worked to a compliant client [0]). Every time with Schannel, Exchange SMTP servers, and opportunistic TLS SMTP clients. > Perhaps the right text here is that if you have a conformant certificate, > you MUST send it, but if not, you MAY send a nonconformant one? Correct. It is important to try to match a supported algorithm, but failing that, send what you have. It may well work just fine for the client, since the signatures in question are not made in real-time by the server, but rather at some previous time by some CA, which the client may not care about (pinned leaf cert, DANE leaf cert, opportunistic TLS, ...). And the point about debugging also makes sense. The client administrator can much more easily determine which additional algorithm is required to interoperate with the server. -- Viktor. From nobody Sat Jul 11 11:32:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101B81A9139 for ; Sat, 11 Jul 2015 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 jXN1GTng8Pdf for ; Sat, 11 Jul 2015 11:32:32 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9396D1A9138 for ; Sat, 11 Jul 2015 11:32:32 -0700 (PDT) Received: by qkcl188 with SMTP id l188so44305279qkc.1 for ; Sat, 11 Jul 2015 11:32:31 -0700 (PDT) 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=pWt2utagkrM2cB9RlB00/VzUzNEgAooFp5EeJHIdmYQ=; b=NxPb760KC+Iyk7e47xmqDYKb08xLFhIStN2WOby8Yfr06p01DAeEqyQbU/HXd4uEtf oUS4iehhRqkY8dhQkt1Fwu371BzcQzSbEZavddhkIrCc3FQs8aV2GiQy1x2Qan62+fNN uNoO4ocaljHyVF6i+I/JkVHbRrbcQCTcq0ltd6Fia5zeWktExZcPdZRqvsGvlGu6rECg vdVkz/t1EPjRi4NV2rC2TDVVb7AG5YZF6FWebnwrFYYJ7pZ3r98z5J/RcfTj90LtN5y1 MyF+96USMpPdvrDRGytxp622U4wLXA3SD2+vlbyJ8xcxnfl/VTxXbvNIEWn5KxJjncpn lj2A== X-Received: by 10.140.20.204 with SMTP id 70mr427909qgj.26.1436639551870; Sat, 11 Jul 2015 11:32:31 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id i197sm7952670qhc.36.2015.07.11.11.32.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 Jul 2015 11:32:31 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 11 Jul 2015 14:32:29 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150711151729.GO28047@mournblade.imrryr.org> In-Reply-To: <20150711151729.GO28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507111432.29731.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 18:32:34 -0000 On Saturday, July 11, 2015 11:17:29 am Viktor Dukhovni wrote: > On Sat, Jul 11, 2015 at 09:55:45AM -0400, Eric Rescorla wrote: > > Perhaps the right text here is that if you have a conformant certificate, > > you MUST send it, but if not, you MAY send a nonconformant one? > > Correct. It is important to try to match a supported algorithm, > but failing that, send what you have. It may well work just fine > for the client, since the signatures in question are not made in > real-time by the server, but rather at some previous time by some > CA, which the client may not care about (pinned leaf cert, DANE > leaf cert, opportunistic TLS, ...). > > And the point about debugging also makes sense. The client > administrator can much more easily determine which additional > algorithm is required to interoperate with the server. Ok, draft language for new behavior here: ============================== If a server receives a ClientHello, but the server cannot produce a valid end-entity certificate using the hash/signature pairs known to be supported by the client (via this extension or the defaults assumed in its absence), then the server MUST send an "unsupported_certificate" alert message and close the connection. In the event that a server can produce a valid end-entity certificate known to be supported by the client, however the known supported hash/signature pairs are insufficient to produce a known valid certificate chain, the server is RECOMMENDED to send a complete valid certificate chain which attempts to use supported hash/signature pairs where possible yet includes certificates with unknown client support. If the client cannot build a trusted chain using these certificates and any other trusted information it has access to, then it MUST send an "unsupported_certificate" alert message and close the connection. The server MAY instead choose to simply send an "unsupported_certificate" alert message and close the connection. ============================== Sound viable? (this might be a bit too wordy, though; the wording throughout the document about fatal alerts could probably be simplified a bit) I pushed the above to the morealerts WIP branch. Dave From nobody Sat Jul 11 12:00:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204C61A886E for ; Sat, 11 Jul 2015 12:00:53 -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 mFs2qBAHQSTg for ; Sat, 11 Jul 2015 12:00:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354541A8879 for ; Sat, 11 Jul 2015 12:00:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 56BA4284D6A; Sat, 11 Jul 2015 19:00:40 +0000 (UTC) Date: Sat, 11 Jul 2015 19:00:40 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150711190040.GS28047@mournblade.imrryr.org> References: <20150711151729.GO28047@mournblade.imrryr.org> <201507111432.29731.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507111432.29731.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Sat, 11 Jul 2015 19:00:53 -0000 On Sat, Jul 11, 2015 at 02:32:29PM -0400, Dave Garrett wrote: > > Correct. It is important to try to match a supported algorithm, > > but failing that, send what you have. It may well work just fine > > for the client, since the signatures in question are not made in > > real-time by the server, but rather at some previous time by some > > CA, which the client may not care about (pinned leaf cert, DANE > > leaf cert, opportunistic TLS, ...). > > > > And the point about debugging also makes sense. The client > > administrator can much more easily determine which additional > > algorithm is required to interoperate with the server. > > Ok, draft language for new behavior here: [ Reordered, feedback question before draft language ] > Sound viable? > > (this might be a bit too wordy, though; the wording throughout the document > about fatal alerts could probably be simplified a bit) Not really viable, and yes, much too wordy and not quite right: > ============================== > If a server receives a ClientHello, but the server cannot produce a valid > end-entity certificate using the hash/signature pairs known to be supported by > the client (via this extension or the defaults assumed in its absence), > then the server MUST send an "unsupported_certificate" alert message and > close the connection. The signature of the leaf certificate is just as irrelevant as signatures up the chain. With pinned leaf certificates, DANE-EE(3), opportunistic TLS, ... even the leaf (end-entity) certificate signature algorithm is of no consequence and is ignored by the client. Therefore, this qualification is not needed, and the server SHOULD NOT send any alert or close the connection even when the client's supported signature algorithms do not include the signature algorithm used for some certificate in the chain (regardless of depth). Instead the server MUST send whatever chain it has whose leaf public key is compatible with the agreed cipher-suite. (The server of course chooses the agreed cipher-suite to make the last condition true). If at all possible, the server SHOULD choose a chain all of whose signatures (excluding any self-signed root CAs) match the client's signature algorith list. If that's not possible, it SHOULD send a default chain (often the only chain it has) with a compatible public key. [ Of course, perhaps worth mentioning, none of this applies with RFC 7250 raw-public-keys, because there is no chain or signatures to send, the server just sends its SPKI public key per RFC 7250. ] > In the event that a server can produce a valid end-entity > certificate known to be supported by the client, however the known supported > hash/signature pairs are insufficient to produce a known valid certificate > chain, the server is RECOMMENDED to send a complete valid certificate chain > which attempts to use supported hash/signature pairs where possible yet > includes certificates with unknown client support. As above: s/RECOMMENDED/SHOULD/. It is NOT up to the server to decide which chains the client can accept. The server has insufficient information, and therefore SHOULD NOT preempt the client's decision of whether the chain works or not. > If the client cannot build > a trusted chain using these certificates and any other trusted information it > has access to, then it MUST send an "unsupported_certificate" alert message > and close the connection. If the client chooses to authenticate the server's chain (i.e. not unauthenticated opportunistic TLS) and fails to do so because it does not support the signature algorithm in one or more certificates that are needed for said authentication, then it MUST send ... > The server MAY instead choose to simply send an > "unsupported_certificate" alert message and close the connection. No, the server SHOULD NOT preempt the client's decision. I'd personally prefer MUST NOT, but there are arguably servers whose clients are all known to never use trust on first use certificate pinning, DANE, unauthenticated opportunistic TLS, ... If we need to weasel out and give some servers the choice to lock out all clients that do anything remotely unorthodox, then SHOULD NOT provides some rope. I think such weaseling out is likely to do more harm than good, but I'm open to concede the rope if need be. On the public Internet, such servers will be few and far between, and the choice to preempt the client should not be a default choice made by the TLS library. If some particular application wants to limit client support, that choice needs to be explicitly signalled to the TLS library. -- Viktor. From nobody Sat Jul 11 12:36:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A296B1AC40D for ; Sat, 11 Jul 2015 12:36:55 -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 yHZJUYab_v1r for ; Sat, 11 Jul 2015 12:36:53 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F601AC40C for ; Sat, 11 Jul 2015 12:36:53 -0700 (PDT) Received: by qkcl188 with SMTP id l188so44861226qkc.1 for ; Sat, 11 Jul 2015 12:36:53 -0700 (PDT) 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=NIrWPwXdN9zjPn/dukwWiHe09z/qEPPIdGh9Y7WFNo0=; b=ZdlVAw8nbj/cFSLWSIVjJCQjCp9g8LZFt+RIFF5SRNjKlgEuG8DnihqRcBLx10rLTm hEoNfRtX5UT0q/8CrBt9mb2eAok2X1q5EZha6KPjG/NjnxHaqRCSHciUEQZvIAvxS/OJ T7CgV/Uaj1gIn7YOGwuytqTAGdmple1Brn6LvlIo4YTNXpBzM1DoTZ48fFp3ecOv1r/l 8eO+hO6ER/LuDNJPtqNQ5lTeer8r9X4TFCpSM7Ew1vkg7+2PMitbJ2hZTJf3ccw5WKK5 uFLYajbWbwblVh4NGcO3qg8CfJzfayapqaxzFoDe2MdnrtfURHXG/mwJlYPY1Fx+OGUH 58DQ== X-Received: by 10.140.98.207 with SMTP id o73mr9815119qge.12.1436643413019; Sat, 11 Jul 2015 12:36:53 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id g19sm7868527qkh.18.2015.07.11.12.36.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 Jul 2015 12:36:52 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 11 Jul 2015 15:36:49 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507111432.29731.davemgarrett@gmail.com> <20150711190040.GS28047@mournblade.imrryr.org> In-Reply-To: <20150711190040.GS28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507111536.50433.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 19:36:55 -0000 On Saturday, July 11, 2015 03:00:40 pm Viktor Dukhovni wrote: > On Sat, Jul 11, 2015 at 02:32:29PM -0400, Dave Garrett wrote: > > ============================== > > If a server receives a ClientHello, but the server cannot produce a valid > > end-entity certificate using the hash/signature pairs known to be supported by > > the client (via this extension or the defaults assumed in its absence), > > then the server MUST send an "unsupported_certificate" alert message and > > close the connection. > > The signature of the leaf certificate is just as irrelevant as > signatures up the chain. With pinned leaf certificates, DANE-EE(3), > opportunistic TLS, ... even the leaf (end-entity) certificate > signature algorithm is of no consequence and is ignored by the > client. I was going based on Ilari's comments here: https://www.ietf.org/mail-archive/web/tls/current/msg17022.html The only scenario where having an EE cert that can't sign anything would be useful is opportunistic encryption. Using anon ciphers sounds better, but I guess attempting auth allows trust on first use so I agree that transmitting certs could be useful here. > If at all possible, the server SHOULD choose a chain all of whose > signatures (excluding any self-signed root CAs) match the client's > signature algorith list. If that's not possible, it SHOULD send > a default chain (often the only chain it has) with a compatible > public key. We don't really have an official definition of what constitutes a "default" chain here. > As above: s/RECOMMENDED/SHOULD/. It is NOT up to the server to decide > which chains the client can accept. The server has insufficient > information, and therefore SHOULD NOT preempt the client's decision > of whether the chain works or not. I was also going with RECOMMENDED/MAY language based on ekr's recent comments. > > The server MAY instead choose to simply send an > > "unsupported_certificate" alert message and close the connection. > > No, the server SHOULD NOT preempt the client's decision. I'd > personally prefer MUST NOT, but there are arguably servers whose > clients are all known to never use trust on first use certificate > pinning, DANE, unauthenticated opportunistic TLS, ... > > If we need to weasel out and give some servers the choice to lock > out all clients that do anything remotely unorthodox, then SHOULD > NOT provides some rope. I think such weaseling out is likely to > do more harm than good, but I'm open to concede the rope if need > be. > > On the public Internet, such servers will be few and far between, I think the rope, as you put it, needs to be there in some form. On the public Internet, yes, I can see your point. In a more tightly controlled system with a potentially constrained environment, I don't see the point in forcing the server to send down certs that the admin can 100% know will just waste bandwidth and processing. So, SHOULD/RECOMMENDED is the level that I think this'll need to be at. I think I understand all of your argued reasons better now. I'll come up with some replacement language that takes them into account. Dave From nobody Sat Jul 11 13:05:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F7D1AC43B for ; Sat, 11 Jul 2015 13:05:05 -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 8VHPHaM3aSJZ for ; Sat, 11 Jul 2015 13:05:03 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02081AC439 for ; Sat, 11 Jul 2015 13:05:03 -0700 (PDT) Received: by qkdv3 with SMTP id v3so33067575qkd.3 for ; Sat, 11 Jul 2015 13:05:03 -0700 (PDT) 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=/D3rN/twAYmf7wSLojn7tfBWZk13DVFKEdrOhiTIE54=; b=q5s9MMFI8+dvlwYc1048yBfQevSzHLkyIf8N4cMj7F0vfmi2NIR35N3OOIn6PcDrps V1RN6m9/pB5ppb+XL50FX0KyKDrRs+onq6Y71B7YC1aRe1mSsOwbdyEvdwU9FXL8xAp0 /SO1nUp82pksbj5OyKCFS0jC/UDtoG6Cisq3jy9DTDzeLyHvAN+CIpauL3ca543LR3e4 I7dPQK8ezPlpxfv/itlMMYVvKLQgqcVOVtr+OR3r3VTUKz+q6U4lmQn2b5LuZi90fYin dPx0pYQtQfmJ8Uy9pTegfB+/5N5GSKkilCr0yHekdTtNHcqiMZlrirjUlt6Zeyug++IP Hk7g== X-Received: by 10.140.89.197 with SMTP id v63mr11456511qgd.97.1436645102982; Sat, 11 Jul 2015 13:05:02 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id z81sm7889263qkg.44.2015.07.11.13.05.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 Jul 2015 13:05:02 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Viktor Dukhovni Date: Sat, 11 Jul 2015 16:05:01 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150711190040.GS28047@mournblade.imrryr.org> <201507111536.50433.davemgarrett@gmail.com> In-Reply-To: <201507111536.50433.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507111605.01407.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 20:05:05 -0000 Ok, revised: ======================================== If the client provided a "signature_algorithms" extension, then all certificates provided by the server SHOULD be signed by a hash/signature algorithm pair indicated by the extension (or defaults assumed in its absence). If the server cannot produce a valid certificate chain using these known supported pairs, then it SHOULD send the client a complete valid chain which attempts to match known support where possible, yet including certificates that are not known to be supported. If the client cannot build a trusted chain using these certificates and any other trusted information it has access to, then it MUST send an "unsupported_certificate" alert message and close the connection. ======================================== Comments? Note that for the purposes of discussion here, opportunistic encryption can "trust" whatever it wants; anything or nothing, depending on implemented strategy. Dave From nobody Sat Jul 11 13:36:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953C91AC82C for ; Sat, 11 Jul 2015 13:36:20 -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 kfJ22JFaBkAG for ; Sat, 11 Jul 2015 13:36:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13D91AC7E8 for ; Sat, 11 Jul 2015 13:36:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8374E284D6A; Sat, 11 Jul 2015 20:36:17 +0000 (UTC) Date: Sat, 11 Jul 2015 20:36:17 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150711203552.GT28047@mournblade.imrryr.org> References: <201507111432.29731.davemgarrett@gmail.com> <20150711190040.GS28047@mournblade.imrryr.org> <201507111536.50433.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507111536.50433.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Sat, 11 Jul 2015 20:36:20 -0000 On Sat, Jul 11, 2015 at 03:36:49PM -0400, Dave Garrett wrote: > I was going based on Ilari's comments here: > https://www.ietf.org/mail-archive/web/tls/current/msg17022.html > > The only scenario where having an EE cert that can't sign anything would > be useful is opportunistic encryption. Using anon ciphers sounds better, > but I guess attempting auth allows trust on first use so I agree that > transmitting certs could be useful here. Not, not "can't signed anything" rather "is signed *by* its issuer via an unsupported signature". The server's public key is not constrained to use the same signature algorithm that signed its certificate. Indeed it must, for example, sign EDH/EECDH parameters with an algorithm that is supported by the client. > > If at all possible, the server SHOULD choose a chain all of whose > > signatures (excluding any self-signed root CAs) match the client's > > signature algorith list. If that's not possible, it SHOULD send > > a default chain (often the only chain it has) with a compatible > > public key. > > We don't really have an official definition of what constitutes a "default" chain here. Whatever the server cares to use. Implementation dependent. Using something minimally exotic would be wise, but I don't the standar can or should specify how to choose. > > As above: s/RECOMMENDED/SHOULD/. It is NOT up to the server to decide > > which chains the client can accept. The server has insufficient > > information, and therefore SHOULD NOT preempt the client's decision > > of whether the chain works or not. > > I was also going with RECOMMENDED/MAY language based on ekr's recent comments. That would be wrong. It really MUST or at least SHOULD continue the handshake. > > On the public Internet, such servers will be few and far between, > > I think the rope, as you put it, needs to be there in some form. On the > public Internet, yes, I can see your point. In a more tightly controlled > system with a potentially constrained environment, I don't see the point > in forcing the server to send down certs that the admin can 100% know will > just waste bandwidth and processing. So, SHOULD/RECOMMENDED is the level > that I think this'll need to be at. > > I think I understand all of your argued reasons better now. I'll come up > with some replacement language that takes them into account. I'll settle for SHOULD. -- Viktor. From nobody Sat Jul 11 13:48:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319CB1ACC82 for ; Sat, 11 Jul 2015 13:48:13 -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 Qy3g2z0oZ0j5 for ; Sat, 11 Jul 2015 13:48:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD801ACC80 for ; Sat, 11 Jul 2015 13:48:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E92E5284D6A; Sat, 11 Jul 2015 20:48:10 +0000 (UTC) Date: Sat, 11 Jul 2015 20:48:10 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150711204810.GU28047@mournblade.imrryr.org> References: <20150711190040.GS28047@mournblade.imrryr.org> <201507111536.50433.davemgarrett@gmail.com> <201507111605.01407.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507111605.01407.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Sat, 11 Jul 2015 20:48:13 -0000 On Sat, Jul 11, 2015 at 04:05:01PM -0400, Dave Garrett wrote: > ======================================== > If the client provided a "signature_algorithms" extension, then all > certificates provided by the server SHOULD be signed by a hash/signature > algorithm pair indicated by the extension (or defaults assumed in its > absence). If the server cannot produce a valid certificate chain using > these known supported pairs, then it SHOULD send the client a complete > valid chain which attempts to match known support where possible, yet > including certificates that are not known to be supported. If the > client cannot build a trusted chain using these certificates and any > other trusted information it has access to, then it MUST send an > "unsupported_certificate" alert message and close the connection. > ======================================== > > Comments? > > Note that for the purposes of discussion here, opportunistic encryption > can "trust" whatever it wants; anything or nothing, depending on implemented > strategy. Largely close enough. Feel free to borrow any text from the below that you find to be an improvement. ======================================== Whenever possible, all certificates provided by the server SHOULD be signed by a hash/signature algorithm pair indicated by the client's supported algorithms extension (or the defaults assumed in its absence). If the server cannot produce a certificate chain that is signed via only the indicated supported pairs, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include hash/signature algoriths that are not known to be supported by the client. The public key in the leaf certificate must of course be compatible with the chosen cipher-suite, and the subsequent ServerKeyExchange message must be signed via a mutually supported hash/signature algorithm pair. If the client cannot construct a satisfactory chain using the provided certificates and decides to abort the handshake, then it MUST send an "unsupported_certificate" alert message and close the connection. ======================================== -- Viktor. From nobody Sat Jul 11 13:52:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503521ACC88 for ; Sat, 11 Jul 2015 13:52:37 -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 i-xmkjKMOlrK for ; Sat, 11 Jul 2015 13:52:35 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC311ACAD4 for ; Sat, 11 Jul 2015 13:52:35 -0700 (PDT) Received: by lagx9 with SMTP id x9so282024991lag.1 for ; Sat, 11 Jul 2015 13:52:33 -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:content-type; bh=ugf8Zrvu3iRfQ7+eXg0LYxIcnlRxoJs7Y6fD7dDgzYM=; b=PKKFxmMM87E5Mm856ept60mJjh8gVhBJi5SyETMQ3gnJDcuVfaanJ2jF6UF55av4YP TNTGzjvu0nP32tx94J5BDketcFYy9AcnSNvaWO/JsC9lJ7gIfX9tQNvoOA3D1i523XCf y2BxxeHseCNHH3qNf8FhKYPVxHHmS/KGdxuoWVsAPFz9ysw7YxCMyY1ZiiBBIucDh2C8 VLy9rXPtpQGLB87gad1PDo/9ru8Xz2AbymO9t1yxqLwGxJJ0ViNKaTfmEC7IFQLnCuhb +5lIz+ZVNG/BGMJ8Osrtg1ZouPriUYqcvHI5/LSYYixeSt0SAharr0QZ503mAhcJTmAK BdHw== X-Gm-Message-State: ALoCoQn59FbzMp+0wb1DrI/s56/y/0spI19/F3pHmVxZm6KktrGqY/JE6G/lVVApPKoK9JEka48S X-Received: by 10.152.225.164 with SMTP id rl4mr10358201lac.38.1436647953760; Sat, 11 Jul 2015 13:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.99.103 with HTTP; Sat, 11 Jul 2015 13:51:53 -0700 (PDT) In-Reply-To: <20150711151729.GO28047@mournblade.imrryr.org> References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> <20150711134516.GA6970@LK-Perkele-VII> <20150711151729.GO28047@mournblade.imrryr.org> From: Eric Rescorla Date: Sat, 11 Jul 2015 16:51:53 -0400 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11349aa6f39852051a9faa35 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 20:52:37 -0000 --001a11349aa6f39852051a9faa35 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 11, 2015 at 11:17 AM, Viktor Dukhovni wrote: > On Sat, Jul 11, 2015 at 09:55:45AM -0400, Eric Rescorla wrote: > > > This makes a certain amount of sense (though I wonder how often it's > really > > an issue that a server declines to send a certificate that would > otherwise > > have worked to a compliant client [0]). > > Every time with Schannel, Exchange SMTP servers, and opportunistic > TLS SMTP clients Well, I assume you mean every time you have a pair with the right properties. But my question is how often that happens on the live Internet. -Ekr > > Perhaps the right text here is that if you have a conformant certificate, > > you MUST send it, but if not, you MAY send a nonconformant one? > > Correct. It is important to try to match a supported algorithm, > but failing that, send what you have. It may well work just fine > for the client, since the signatures in question are not made in > real-time by the server, but rather at some previous time by some > CA, which the client may not care about (pinned leaf cert, DANE > leaf cert, opportunistic TLS, ...). > > And the point about debugging also makes sense. The client > administrator can much more easily determine which additional > algorithm is required to interoperate with the server. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11349aa6f39852051a9faa35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 11, 2015 at 11:17 AM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Sat, Jul 11, 2015 at 09:55:45AM -0400, Eric Rescorla wrote:

> This makes a certain amount of sense (though I wonder how often it'= ;s really
> an issue that a server declines to send a certificate that would other= wise
> have worked to a compliant client [0]).

Every time with Schannel, Exchange SMTP servers, and opportunistic TLS SMTP clients

Well, I assume you mean ev= ery time you have a pair with the right properties.
But my questi= on is how often that happens on the live Internet.

=C2=A0-Ekr

=C2=A0
> Perhaps the right text here is that if you have a conformant certifica= te,
> you MUST send it, but if not, you MAY send a nonconformant one?

Correct.=C2=A0 It is important to try to match a supported algorithm= ,
but failing that, send what you have.=C2=A0 It may well work just fine
for the client, since the signatures in question are not made in
real-time by the server, but rather at some previous time by some
CA, which the client may not care about (pinned leaf cert, DANE
leaf cert, opportunistic TLS, ...).

And the point about debugging also makes sense.=C2=A0 The client
administrator can much more easily determine which additional
algorithm is required to interoperate with the server.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a11349aa6f39852051a9faa35-- From nobody Sat Jul 11 13:57:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036F21ACC89 for ; Sat, 11 Jul 2015 13:57:57 -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 ceafxLeBetk3 for ; Sat, 11 Jul 2015 13:57:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7163C1ACC88 for ; Sat, 11 Jul 2015 13:57:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C8EFB284D6A; Sat, 11 Jul 2015 20:57:54 +0000 (UTC) Date: Sat, 11 Jul 2015 20:57:54 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150711205754.GX28047@mournblade.imrryr.org> References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> <20150711134516.GA6970@LK-Perkele-VII> <20150711151729.GO28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Sat, 11 Jul 2015 20:57:57 -0000 On Sat, Jul 11, 2015 at 04:51:53PM -0400, Eric Rescorla wrote: > > Every time with Schannel, Exchange SMTP servers, and opportunistic > > TLS SMTP clients > > > Well, I assume you mean every time you have a pair with the right > properties. > But my question is how often that happens on the live Internet. Well, the client would have to not offer SHA256, most do. Schannel issues with SMTP tend to be mostly in other corners of the spec. For example, Schannel opportunistic clients hang-up when the server certificate is "expired", even when they don't otherwise authenticate the certificate, and accept self-signed or wrong server name, ... That is also pointlessly strict. The breakage in this thread would require a client that offers TLSv1.2, but not SHA256, and those are at present rare. That does not mean that the specification should stay wrong. -- Viktor. From nobody Sat Jul 11 14:09:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EA71ACD21 for ; Sat, 11 Jul 2015 14:09:31 -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 Gg8zZekOq9wh for ; Sat, 11 Jul 2015 14:09:30 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACFF1ACD1D for ; Sat, 11 Jul 2015 14:09:30 -0700 (PDT) Received: by qkhu186 with SMTP id u186so229061621qkh.0 for ; Sat, 11 Jul 2015 14:09:29 -0700 (PDT) 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=U16qCiWBQvjUPfjeX0LwtxFXUHwJW57WSMkmPwGGbuo=; b=V08bVhg28y3hKJYbDoc44M0wFwHGdolICPQWB43orGQ0iAmNFSzjTvJy9NFp591+HK cWy/qYlbSsBmQhey4PQYt79AJ4WOYyCWinawtg9pper41BexBLhah1B4sYnE+voIHZiZ +YJbjqq2kbheF/OkSur3PGSFtjirdBlYlFCb0O3SScqdM1Ble64jTWMpczBV/coZXOAv 5tjb+c2gY6NWgd7b91tXTTtS9ypQN9hW671xKsX2486dp6/sR6Zht2ZoVExf6M3rFzU7 Q/H/yJLcSAd1dAcAxB1jZpOAabMemyyIP/elSYU08nfNYOylJg74QYkTF61yzd6eNGTr g9qw== X-Received: by 10.140.165.150 with SMTP id l144mr43197004qhl.99.1436648969445; Sat, 11 Jul 2015 14:09:29 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 59sm8307985qgj.12.2015.07.11.14.09.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 Jul 2015 14:09:28 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Sat, 11 Jul 2015 17:09:27 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507111605.01407.davemgarrett@gmail.com> <20150711204810.GU28047@mournblade.imrryr.org> In-Reply-To: <20150711204810.GU28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507111709.27725.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 21:09:32 -0000 On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote: > Largely close enough. Feel free to borrow any text from the below > that you find to be an improvement. > > ======================================== > > Whenever possible, all certificates provided by the server > SHOULD be signed by a hash/signature algorithm pair indicated > by the client's supported algorithms extension (or the defaults > assumed in its absence). If the server cannot produce a > certificate chain that is signed via only the indicated supported > pairs, then it SHOULD continue the handshake by sending the > client a certificate chain of its choice that may include > hash/signature algoriths that are not known to be supported by > the client. > > The public key in the leaf certificate must of course be > compatible with the chosen cipher-suite, and the subsequent > ServerKeyExchange message must be signed via a mutually supported > hash/signature algorithm pair. > > If the client cannot construct a satisfactory chain using the > provided certificates and decides to abort the handshake, then > it MUST send an "unsupported_certificate" alert message and > close the connection. > > ======================================== The middle bit is already in existing text above the section in question. New version with a little rewording and a typo fix. \/ ======================================== All certificates provided by the server SHOULD be signed by a hash/signature algorithm pair indicated by the client's "signature_algorithms" extension (or the defaults assumed in its absence), where possible. If the server cannot produce a certificate chain that is signed only via the indicated supported pairs, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST send an "unsupported_certificate" alert message and close the connection. ======================================== Dave From nobody Sat Jul 11 14:13:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3A1ACD32 for ; Sat, 11 Jul 2015 14:13:48 -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 y5eHFeSQIy6Y for ; Sat, 11 Jul 2015 14:13:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DD51ACD00 for ; Sat, 11 Jul 2015 14:13:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D517A284D6A; Sat, 11 Jul 2015 21:13:45 +0000 (UTC) Date: Sat, 11 Jul 2015 21:13:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150711211345.GA28047@mournblade.imrryr.org> References: <201507111605.01407.davemgarrett@gmail.com> <20150711204810.GU28047@mournblade.imrryr.org> <201507111709.27725.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507111709.27725.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Sat, 11 Jul 2015 21:13:48 -0000 On Sat, Jul 11, 2015 at 05:09:27PM -0400, Dave Garrett wrote: > New version with a little rewording and a typo fix. > > ======================================== > All certificates provided by the server SHOULD be signed by a > hash/signature algorithm pair indicated by the client's > "signature_algorithms" extension (or the defaults assumed in > its absence), where possible. If the server cannot produce a > certificate chain that is signed only via the indicated supported > pairs, then it SHOULD continue the handshake by sending the > client a certificate chain of its choice that may include algorithms > that are not known to be supported by the client. If the client > cannot construct an acceptable chain using the provided certificates > and decides to abort the handshake, then it MUST send an > "unsupported_certificate" alert message and close the connection. > ======================================== I find this version much improved, in fact very clear and concise. Excellent, works for me. Thanks. -- Viktor. From nobody Sat Jul 11 14:14:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB071ACD00 for ; Sat, 11 Jul 2015 14:14:06 -0700 (PDT) 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 zunj7TNWd_1L for ; Sat, 11 Jul 2015 14:14:05 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D401ACCF6 for ; Sat, 11 Jul 2015 14:14:05 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 83B041A2606 for ; Sun, 12 Jul 2015 00:14:03 +0300 (EEST) Date: Sun, 12 Jul 2015 00:14:03 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150711211403.GB19435@LK-Perkele-VII> References: <20150711190040.GS28047@mournblade.imrryr.org> <201507111536.50433.davemgarrett@gmail.com> <201507111605.01407.davemgarrett@gmail.com> <20150711204810.GU28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150711204810.GU28047@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 21:14:06 -0000 On Sat, Jul 11, 2015 at 08:48:10PM +0000, Viktor Dukhovni wrote: > > The public key in the leaf certificate must of course be > compatible with the chosen cipher-suite, and the subsequent > ServerKeyExchange message must be signed via a mutually supported > hash/signature algorithm pair. Actually, it only needs to be compatible with ciphersuite if client did not send signature_algorithms. If it did, then it needs to be compatible with any algorithm pair signaled in that. It also worked this way in TLS 1.2. E.g. if client advertised {sha256, ecdsa} + in its signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 + others in its ciphersuites, then the server MAY pick TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to sign the handshake with ECDSA/SHA-256. Despite there being no DHE_ECDSA ciphersuites. Also, it occurs to me that analogous situation occurs with client certificates. But there the rules are much less clear to me: There are two fields that control supported certificate algorithms: certificate_types and supported_signature_algorithms, both in CertificateRequest. Here's what TLS 1.2 says about interplay of those fields (and TLS 1.3 wg-07 has very similar language, quite possibly exactly the same): "The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types. If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms." Is say ECDSA key "compatible" with rsa_sign? Also, it seems like TLS 1.3 draft allows fixed_dh certificate_types. How would those even work? I thought only signature-capable ones do. Which would mean that certificate_types could be deprecated entierely. -Ilari From nobody Sat Jul 11 14:24:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F8B1ACD0A for ; Sat, 11 Jul 2015 14:24:03 -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 6uitS-kXj_KZ for ; Sat, 11 Jul 2015 14:24:02 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBEB1ACCFD for ; Sat, 11 Jul 2015 14:24:02 -0700 (PDT) Received: by qkdv3 with SMTP id v3so33757488qkd.3 for ; Sat, 11 Jul 2015 14:24:01 -0700 (PDT) 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=WJ17WFAaP7kAoRzfVncAQh/HoB7Gc0KkDsOFvkuA6e8=; b=xUvSxBuaWR+zB4y30viIZaxIP5lk2MhhylYuh+57jEd14KCxXwJhMmaZtrvWofX7hA k6Uu0KkDnT86h9Zew2OxyJzdsPtsB8ZAM0XEEKcSCWIeCFG5JvV2OmVVP4C1wdRjEa7n Dtjf5I1FD9wuyNfQDQ8SWTxH+Od2M4eIcUIxdnv0IZsXhkv1QmyAgT43/5gRyGRa+QH4 sFIDtlUj761+XlpDHW7F/CjGhk7hFEF27tDgJkJF+c6q9cZKKC6gpria4t3ijTyxpoBl E0g7co4r2I/Dyw+B/GJQhmpLxwspLYHB7Rp/KtZo90Cu5+iQsoB8qsrVnFZP7WAAwb/T NTqA== X-Received: by 10.140.89.197 with SMTP id v63mr11770453qgd.97.1436649841295; Sat, 11 Jul 2015 14:24:01 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id m48sm8311609qgd.35.2015.07.11.14.24.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 Jul 2015 14:24:00 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 11 Jul 2015 17:23:58 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507111709.27725.davemgarrett@gmail.com> <20150711211345.GA28047@mournblade.imrryr.org> In-Reply-To: <20150711211345.GA28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507111723.59136.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 21:24:03 -0000 On Saturday, July 11, 2015 05:13:45 pm Viktor Dukhovni wrote: > I find this version much improved, in fact very clear and concise. > Excellent, works for me. Thanks. Great. :) To actually get back to the title of this thread, the change under current discussion could actually help us drop SHA1 from the spec a little more easily. SHA1 can be prohibited to be offered for TLS 1.3+, the defaults can be changed to SHA256 (and eventually to mandatory to send), and nothing else is really needed. The new text allows for unspecified hashes to be used if forced to, which would apply to SHA1. SHA1 would be MUST NOT offer & implicitly SHOULD NOT be sent by server. Thus, the official stance would be that SHA1 is only ever permitted in a fallback chain, which is pretty much what we want. Note that clients willing to negotiate TLS 1.2 (e.g. the vast majority) would still probably want to offer SHA1 in the short term, so the 1.3 spec would need to state that this is not prohibited for them, but TLS 1.3 servers would have to ignore it. Dave From nobody Sat Jul 11 16:18:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4B1A00C1 for ; Sat, 11 Jul 2015 16:18:45 -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 4QAv_7rTd5Be for ; Sat, 11 Jul 2015 16:18:43 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DDB1A00C3 for ; Sat, 11 Jul 2015 16:18:43 -0700 (PDT) Received: by lblf12 with SMTP id f12so38959150lbl.2 for ; Sat, 11 Jul 2015 16:18:41 -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=rqUGFMlE9a87PVLYb7P1ZuBCfcE7Xa/qeeu5C8FbEAg=; b=GePnGt7yXGoPD3seNFu2fmOWTxZBGz5Olh49yAZbz/Z0wogf2zpXuGVBzT966qdqeG LoX1RNrRDfAjVgBerTuKCZEZCebn8Gz/9T9HjmiSLkB3rpXeOZSOKdEsbC/eIhnghU8D cIiB8GTwrCWoGPIRaZkhwFbDHHF2yZqzE83HJsXcX6MbhUjWSwf/pHY/5m/sJj5VqOll B5C+CWy4yB/cdcxikfzpxtzC1HSvvpGWgosrlrf6krqCiTGGUqixiGJjiu9MIIKusQit z0P8mfjewmpcWlhRvQYP5OCm4VgDTxqCxmT/h+svWH89Lw+Bul/vaQNHTBy1z8kyOBSl Df1A== X-Gm-Message-State: ALoCoQl4yYjzAc5n4fRdXj0GexAgLA9D3aH3DvSLiI20sXEGax6k2MHuPFOjtcwu7xI+vc3xDO1C X-Received: by 10.152.30.4 with SMTP id o4mr25060441lah.74.1436656721552; Sat, 11 Jul 2015 16:18:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.99.103 with HTTP; Sat, 11 Jul 2015 16:18:01 -0700 (PDT) In-Reply-To: <201507111709.27725.davemgarrett@gmail.com> References: <201507111605.01407.davemgarrett@gmail.com> <20150711204810.GU28047@mournblade.imrryr.org> <201507111709.27725.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 11 Jul 2015 19:18:01 -0400 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e0160b4368d8010051aa1b595 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 23:18:45 -0000 --089e0160b4368d8010051aa1b595 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 11, 2015 at 5:09 PM, Dave Garrett wrote: > On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote: > > Largely close enough. Feel free to borrow any text from the below > > that you find to be an improvement. > > > > ======================================== > > > > Whenever possible, all certificates provided by the server > > SHOULD be signed by a hash/signature algorithm pair indicated > > by the client's supported algorithms extension (or the defaults > > assumed in its absence). If the server cannot produce a > > certificate chain that is signed via only the indicated supported > > pairs, then it SHOULD continue the handshake by sending the > > client a certificate chain of its choice that may include > > hash/signature algoriths that are not known to be supported by > > the client. > > > > The public key in the leaf certificate must of course be > > compatible with the chosen cipher-suite, and the subsequent > > ServerKeyExchange message must be signed via a mutually supported > > hash/signature algorithm pair. > > > > If the client cannot construct a satisfactory chain using the > > provided certificates and decides to abort the handshake, then > > it MUST send an "unsupported_certificate" alert message and > > close the connection. > > > > ======================================== > > The middle bit is already in existing text above the section in question. > > New version with a little rewording and a typo fix. > > \/ > > ======================================== > All certificates provided by the server SHOULD be signed by a > hash/signature algorithm pair indicated by the client's > "signature_algorithms" extension (or the defaults assumed in > its absence), where possible. If the server cannot produce a > certificate chain that is signed only via the indicated supported > pairs, then it SHOULD continue the handshake by sending the > client a certificate chain of its choice that may include algorithms > that are not known to be supported by the client. If the client > cannot construct an acceptable chain using the provided certificates > and decides to abort the handshake, then it MUST send an > "unsupported_certificate" alert message and close the connection. > ======================================= > I'm not happy with this. There should be a MUST-level requirement to provide a conformant chain if possible. -Ekr > > Dave > --089e0160b4368d8010051aa1b595 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 11, 2015 at 5:09 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote:
> Largely close enough.=C2=A0 Feel free to borrow any text from the belo= w
> that you find to be an improvement.
>
>=C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>=C2=A0 =C2=A0 =C2=A0Whenever possible, all certificates provided by the= server
>=C2=A0 =C2=A0 =C2=A0SHOULD be signed by a hash/signature algorithm pair= indicated
>=C2=A0 =C2=A0 =C2=A0by the client's supported algorithms extension = (or the defaults
>=C2=A0 =C2=A0 =C2=A0assumed in its absence).=C2=A0 If the server cannot= produce a
>=C2=A0 =C2=A0 =C2=A0certificate chain that is signed via only the indic= ated supported
>=C2=A0 =C2=A0 =C2=A0pairs, then it SHOULD continue the handshake by sen= ding the
>=C2=A0 =C2=A0 =C2=A0client a certificate chain of its choice that may i= nclude
>=C2=A0 =C2=A0 =C2=A0hash/signature algoriths that are not known to be s= upported by
>=C2=A0 =C2=A0 =C2=A0the client.
>
>=C2=A0 =C2=A0 =C2=A0The public key in the leaf certificate must of cour= se be
>=C2=A0 =C2=A0 =C2=A0compatible with the chosen cipher-suite, and the su= bsequent
>=C2=A0 =C2=A0 =C2=A0ServerKeyExchange message must be signed via a mutu= ally supported
>=C2=A0 =C2=A0 =C2=A0hash/signature algorithm pair.
>
>=C2=A0 =C2=A0 =C2=A0If the client cannot construct a satisfactory chain= using the
>=C2=A0 =C2=A0 =C2=A0provided certificates and decides to abort the hand= shake, then
>=C2=A0 =C2=A0 =C2=A0it MUST send an "unsupported_certificate"= alert message and
>=C2=A0 =C2=A0 =C2=A0close the connection.
>
>=C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The middle bit is already in existing text above the section in ques= tion.

New version with a little rewording and a typo fix.

\/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
All certificates provided by the server SHOULD be signed b= y a
hash/signature algorithm pair indicated by the client's
"signature_algorithms" extension (or the defaults assumed = in
its absence), where possible. If the server cannot produce a
certificate chain that is signed only via the indicated supported
pairs, then it SHOULD continue the handshake by sending th= e
client a certificate chain of its choice that may include algorithms=
that are not known to be supported by the client. If the client
cannot construct an acceptable chain using the provided certificates
and decides to abort the handshake,= then it MUST send an
"unsupported_certificate" alert message and close the connection.=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I'm not happy with this. There should be a MUST-level r= equirement to provide
a conformant chain if possible.
<= br>
-Ekr

=C2=A0

Dave

--089e0160b4368d8010051aa1b595-- From nobody Sat Jul 11 16:19:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B791A00C1 for ; Sat, 11 Jul 2015 16:19:46 -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 gZdqVugV6vVT for ; Sat, 11 Jul 2015 16:19:44 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BBF1A00C3 for ; Sat, 11 Jul 2015 16:19:43 -0700 (PDT) Received: by labgy5 with SMTP id gy5so130888124lab.2 for ; Sat, 11 Jul 2015 16:19:42 -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=s1OnINk7yGO5rVh2v+oN+WrRmJw8oq1+ls/h0HpVOME=; b=Qz2zPRSUMMiBxfLDpCwrhDenNldguZ+35rjpYWENeY2dc3l8F5fbiQgj6xWJeag7bS Od3OqcEsfxSbCeHVL1X+UONiRrRNQXWjjC/UJDisoFNU/qTGE84xx0la2CkaA4tvI0Kq FBlFHipRHpwBXQn4X1lmDzNDCrysY4uBk7U8GDF69i3Fz98bSolUuGZy8ar37uH1mvhT nfHVnaNqSa7qn4iswUpZa4X5JLVXRIazfkXULYZFk3+YMgMTt9k54JlVPslQNo6NQ2bc qOZUBeIdz6+gJC7MG68BfB4XcgFiipdowy2DAyPL3eQKHnjr4PGv/QRLoLFcKkGCjJow db6g== X-Gm-Message-State: ALoCoQkQpE+PmG4rss1t0UbxaA574S2zZGBwzCcflNnB7wd5fj75sK+tWGGwOAxjNRyNGIWtPGva X-Received: by 10.152.244.170 with SMTP id xh10mr20233938lac.23.1436656782171; Sat, 11 Jul 2015 16:19:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.99.103 with HTTP; Sat, 11 Jul 2015 16:19:02 -0700 (PDT) In-Reply-To: <20150711211403.GB19435@LK-Perkele-VII> References: <20150711190040.GS28047@mournblade.imrryr.org> <201507111536.50433.davemgarrett@gmail.com> <201507111605.01407.davemgarrett@gmail.com> <20150711204810.GU28047@mournblade.imrryr.org> <20150711211403.GB19435@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 11 Jul 2015 19:19:02 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1134b65e2a7845051aa1b951 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 23:19:46 -0000 --001a1134b65e2a7845051aa1b951 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 11, 2015 at 5:14 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Sat, Jul 11, 2015 at 08:48:10PM +0000, Viktor Dukhovni wrote: > > > > The public key in the leaf certificate must of course be > > compatible with the chosen cipher-suite, and the subsequent > > ServerKeyExchange message must be signed via a mutually supported > > hash/signature algorithm pair. > > Actually, it only needs to be compatible with ciphersuite if client > did not send signature_algorithms. If it did, then it needs to be > compatible with any algorithm pair signaled in that. > > It also worked this way in TLS 1.2. > > > E.g. if client advertised {sha256, ecdsa} + in its > signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > + others in its ciphersuites, then the server MAY pick > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to > sign the handshake with ECDSA/SHA-256. Despite there being > no DHE_ECDSA ciphersuites. > > > Also, it occurs to me that analogous situation occurs with client > certificates. But there the rules are much less clear to me: > > There are two fields that control supported certificate algorithms: > certificate_types and supported_signature_algorithms, both in > CertificateRequest. > > Here's what TLS 1.2 says about interplay of those fields (and > TLS 1.3 wg-07 has very similar language, quite possibly exactly > the same): > > "The end-entity certificate provided by the client MUST contain a > key that is compatible with certificate_types. If the key is a > signature key, it MUST be usable with some hash/signature > algorithm pair in supported_signature_algorithms." > > Is say ECDSA key "compatible" with rsa_sign? > > > Also, it seems like TLS 1.3 draft allows fixed_dh certificate_types. > How would those even work? This is just editor error. > I thought only signature-capable ones > do. Which would mean that certificate_types could be deprecated > entierely. Yes, I think i observed this before but just haven't gotten around to updating the spec to remove it. -Ekr > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1134b65e2a7845051aa1b951 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 11, 2015 at 5:14 PM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= span class=3D"">On Sat, Jul 11, 2015 at 08:48:10PM +0000, Viktor Dukhovni w= rote:
>
>=C2=A0 =C2=A0 =C2=A0The public key in the leaf certificate must of cour= se be
>=C2=A0 =C2=A0 =C2=A0compatible with the chosen cipher-suite, and the su= bsequent
>=C2=A0 =C2=A0 =C2=A0ServerKeyExchange message must be signed via a mutu= ally supported
>=C2=A0 =C2=A0 =C2=A0hash/signature algorithm pair.

Actually, it only needs to be compatible with ciphersuite if client<= br> did not send signature_algorithms. If it did, then it needs to be
compatible with any algorithm pair signaled in that.

It also worked this way in TLS 1.2.


E.g. if client advertised {sha256, ecdsa} + <others> in its
signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
+ others in its ciphersuites, then the server MAY pick
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to
sign the handshake with ECDSA/SHA-256. Despite there being
no DHE_ECDSA ciphersuites.


Also, it occurs to me that analogous situation occurs with client
certificates. But there the rules are much less clear to me:

There are two fields that control supported certificate algorithms:
certificate_types and supported_signature_algorithms, both in
CertificateRequest.

Here's what TLS 1.2 says about interplay of those fields (and
TLS 1.3 wg-07 has very similar language, quite possibly exactly
the same):

"The end-entity certificate provided by the client MUST contain a
key that is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some hash/signature
algorithm pair in supported_signature_algorithms."

Is say ECDSA key "compatible" with rsa_sign?


Also, it seems like TLS 1.3 draft allows fixed_dh certificate_types.
How would those even work?

This is just ed= itor error.

=C2=A0
I thought only signature-capable ones
do. Which would mean that certificate_types could be deprecated
entierely.

Yes, I think i observed this bef= ore but just haven't gotten around to updating
the spec to re= move it.

-Ekr

=C2=A0

-Ilari

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

--001a1134b65e2a7845051aa1b951-- From nobody Sat Jul 11 16:29:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8838D1A0022 for ; Sat, 11 Jul 2015 16:29:06 -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 T_zdLdk1vRQW for ; Sat, 11 Jul 2015 16:29:05 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B791A0021 for ; Sat, 11 Jul 2015 16:29:05 -0700 (PDT) Received: by qkdv3 with SMTP id v3so34972535qkd.3 for ; Sat, 11 Jul 2015 16:29:04 -0700 (PDT) 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=O+LW0M5j3782goeN5LGICvGPzeoTzDOpui3vi5jgv1w=; b=R8fO6tEaaPCsQI7hms08gbYlIrN+/xN7e2+LbKNfKIM6GMcr80Kb8s96peGlOL4cZc cc7xL1zu4+gLm3tvSYEEsHsGK/m6WmEIkxbi4yQ4zQ45zIWlWicae4ucwW7nmlkCLOre tk7JyYh9TPM60aZrtZVqy82Dptx7Qk40OjcFaqrDwHiSNMg/EjlwrvWIpIy6aI9Bq7bv 3VZ9ALcwOu49DY/nC+irkv6KqSu2X425g0mMne4UFWAAryxd2bh8DtMvY+1NsDe0zw6l sEr6VZld+KsvSydhmkF2Tb87IDxTatkUA0LXsUGgSfiPLTMZkRNHquUVquGwjrlsBtY1 YLBg== X-Received: by 10.55.18.197 with SMTP id 66mr43941023qks.13.1436657344625; Sat, 11 Jul 2015 16:29:04 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id r81sm8298935qkr.2.2015.07.11.16.29.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 Jul 2015 16:29:04 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sat, 11 Jul 2015 19:29:02 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507111709.27725.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507111929.02696.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2015 23:29:06 -0000 On Saturday, July 11, 2015 07:18:01 pm Eric Rescorla wrote: > I'm not happy with this. There should be a MUST-level requirement to provide > a conformant chain if possible. Yeah. "SHOULD" & "where possible" aren't both needed. We only really want one or the other. I'll change it to "MUST" & "where possible". Dave From nobody Sun Jul 12 07:39:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40FF1A891E for ; Sun, 12 Jul 2015 07:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 WHohEkTWKT0w for ; Sun, 12 Jul 2015 07:39:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 3705A1A8911 for ; Sun, 12 Jul 2015 07:39:42 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6CEdcUv021884 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 12 Jul 2015 16:39:39 +0200 From: Simon Josefsson To: Hubert Kario References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <2960351.rch1apE1uy@pintsize.usersys.redhat.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150712:tls@ietf.org::C8bwq9KaJUxX4lIi:9vZf X-Hashcash: 1:22:150712:hkario@redhat.com::k8/2VNhBNy7vq2Uc:T+Px Date: Sun, 12 Jul 2015 16:39:37 +0200 In-Reply-To: <2960351.rch1apE1uy@pintsize.usersys.redhat.com> (Hubert Kario's message of "Thu, 09 Jul 2015 14:20:04 +0200") Message-ID: <87k2u5samu.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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: Sun, 12 Jul 2015 14:39:45 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hubert Kario writes: > As is described in secion 5.1. of RFC 4492, and then reiterated in=20 > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups= )=20 > guides both the ECDH curves and curves understandable by peer for ECDSA=20 > signatures. > > As Curve25519 and Curve448 can only be used for ECDHE, maybe they should = be=20 > defined/named in the registry as such, to remove any ambiguity[1]: > > enum { > Curve25519_ecdh(TBD1), > Curve448_ecdh(TBD2), > } NamedCurve; I don't care strongly. One disadvantage with this is that if we decide to reuse these NamedCurve allocations to have something to do with Ed25519, the naming above will be confusing. However, I believe it is already likely that Ed25519 will have its own NamedCurve. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVonwpAAoJEIYLf7sy+BGd06UIAJoodXRMbJv4IC8o7mhObTe9 yhNbtaSj0rktLsHw722DMS6bvjy/GgZvr0U4Y1jRxcn5uOYmQkmr1zphjv7H7LJx 4lEmTxDAjcXxwGC2HTJxnoYLlORFiy9yCuCuckst3aDtrQt27mTosBAccajOuegz mM4pHfEdqKUb5jIyVdm7pKo1fbR0s6wd3xM9tKTvfh6EqflzU02ZlF8MmzbZuwUE bnIkjEpCgw4/Pj/tI716VNpmI6eg/as8yDqNR0EigpoLJjX518kEcaCf9EZbgpju stpfBWSdZGvZ7tfsuIVlZnauwR3Nt/RrTPYQ7idu0wRVYW5XkJLfVkEJIbWQdTk= =6RDL -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 12 21:11:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B041A1ABC for ; Sun, 12 Jul 2015 21:11:09 -0700 (PDT) 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, 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 uaQ28XBbUynM for ; Sun, 12 Jul 2015 21:11:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC381A1ACA for ; Sun, 12 Jul 2015 21:11:06 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 13 Jul 2015 04:11:05 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0213.000; Mon, 13 Jul 2015 04:11:05 +0000 From: Andrei Popov To: Dave Garrett , Eric Rescorla Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpCAAUrngIAADsEAgAAC7oCAABbWgIAANnyAgAAH4ACAAAoZgIAAB+GAgAAMDwCAAAXygIAAI+yAgAADFACAAd8BsA== Date: Mon, 13 Jul 2015 04:11:04 +0000 Message-ID: References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> In-Reply-To: <201507111929.02696.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.46.200.154] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:ZgAvgcQnzZbC3CRw8uIi+zrl+AmzYbBArg/po7z0TJTK44PvW43R3DzU5gDwGl0/NxMcC8SjJaZ9NK+dgnUNWTf3rNDyBDOZmAjRmQNYfKJm24vrkKvYLFbtUPklQwIBPoWgmigN6k6PP+CbdY6PmQ==; 24:uTRnku4XA5QDLFtWWCxdU5J8dd2uYxkSWnNxjN0gXez8WTJl7kF3wKYyYcfcyx9FZ14Pgcs0/oeEJFwkFkbSBnoce/ho2QUQyjmIPNeZl68=; 20:1fxk61bYQHVtT1mnuvKyFQtREX1nGDUInnIZ8lXiV89m17DZH8beE5gVrwGC6lFPZM3LTERIopHMSZwRfGOudg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; blupr03mb1394: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(50986999)(86362001)(19580395003)(106116001)(46102003)(19580405001)(76176999)(87936001)(2656002)(54356999)(66066001)(76576001)(93886004)(62966003)(77156002)(92566002)(189998001)(122556002)(5001960100002)(40100003)(5001770100001)(2900100001)(74316001)(99286002)(5003600100002)(86612001)(77096005)(2950100001)(15975445007)(33656002)(102836002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 04:11:04.9401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 04:11:09 -0000 I'm not happy with this either. The spec already says: "If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the signature_algorithms extension, listing the algorithms it is willing to accept." This seems to be pretty clear: if the client properly advertises the algori= thms it supports, then the handshake has a deterministic outcome. =20 Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dave Garrett Sent: Saturday, July 11, 2015 4:29 PM To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek) On Saturday, July 11, 2015 07:18:01 pm Eric Rescorla wrote: > I'm not happy with this. There should be a MUST-level requirement to=20 > provide a conformant chain if possible. Yeah. "SHOULD" & "where possible" aren't both needed. We only really want o= ne or the other. I'll change it to "MUST" & "where possible". Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Sun Jul 12 21:41:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5551A8AF9 for ; Sun, 12 Jul 2015 21:41:07 -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 NHJWe-4Gqog3 for ; Sun, 12 Jul 2015 21:41:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B191A903E for ; Sun, 12 Jul 2015 21:41:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 909D9284D6A; Mon, 13 Jul 2015 04:41:04 +0000 (UTC) Date: Mon, 13 Jul 2015 04:41:04 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150713044104.GK28047@mournblade.imrryr.org> References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Mon, 13 Jul 2015 04:41:07 -0000 On Mon, Jul 13, 2015 at 04:11:04AM +0000, Andrei Popov wrote: > I'm not happy with this either. The spec already says: > > "If the client supports only the default hash and signature algorithms > (listed in this section), it MAY omit the signature_algorithms > extension. If the client does not support the default algorithms, or > supports other hash and signature algorithms (and it is willing to > use them for verifying messages sent by the server, i.e., server > certificates and server key exchange), it MUST send the > signature_algorithms extension, listing the algorithms it is willing > to accept." > > This seems to be pretty clear: if the client properly advertises the > algorithms it supports, then the handshake has a deterministic outcome. That's all fine, we're talking about what the server should do when it is certificate chain does not (in its entirety) match those algorithms. And in the context of TLS 1.3 which is not yet set in stone. Which part are you objecting to? The subsequent proposal to suppress SHA-1 advertisements (if the client supports only TLS 1.3 or later) when even when the client is willing to accept a SHA-1 chain when all else fails? That too seems sensible, and it was already noted that clients will need to send the SHA-1 codepoint when willing to accept TLS 1.2, since that spec does not contain the proposed new language for server-side behaviour. -- Viktor. From nobody Mon Jul 13 07:12:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2E1B2B10 for ; Mon, 13 Jul 2015 07:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 jC_6fgPXnKUX for ; Mon, 13 Jul 2015 07:12:49 -0700 (PDT) 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 C9FEE1B2B0D for ; Mon, 13 Jul 2015 07:12:48 -0700 (PDT) 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 EBDA44443C; Mon, 13 Jul 2015 16:12:46 +0200 (CEST) X-purgate-ID: 152705::1436796766-00000B48-0AB8D91F/0/0 X-purgate-size: 1748 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D9DA340676; Mon, 13 Jul 2015 16:12:46 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C6F221A1DC; Mon, 13 Jul 2015 16:12:46 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Mon, 13 Jul 2015 16:12:46 +0200 (CEST) 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: <20150713141246.C6F221A1DC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 13 Jul 2015 14:12:50 -0000 Andrei Popov wrote: > I'm not happy with this either. I liked that proposal. The spec already says: > > "If the client supports only the default hash and signature algorithms > (listed in this section), it MAY omit the signature_algorithms > extension. If the client does not support the default algorithms, or > supports other hash and signature algorithms (and it is willing to > use them for verifying messages sent by the server, i.e., server > certificates and server key exchange), it MUST send the > signature_algorithms extension, listing the algorithms it is willing > to accept." > > This seems to be pretty clear: if the client properly advertises the > algorithms it supports, then the handshake has a deterministic outcome. While this may seem true, the problem that you're ignoring here is that it changes the original meaning&semantics of ClientHello in a backwards-incompatible and undesirable fashion, which creates either an interop failure or a security problem or both. In TLS up to TLSv1.1, the absence of a TLS signature_algorithms extensions indicates *ONLY* the algorithm that has to be used a the TLS protocol layer (for digitally-signed), and it says *NOTHING* at all about the algorithms that may be used within certificates. As you might know, support for server certificates signed with sha256WithRsaEncryption was added to Windows XP with Service Pack 3 (21-Apr-2008) and into Windows 2003 with KB938397. So the lack of a TLS signature_algorithm extension ought to apply semantics exclusively to "digitally-signed". Applying any restrictive semantics to server certifcates is a backwards-incompatible dumb idea (in rfc5246) that needs to be fixed. -Martin From nobody Mon Jul 13 07:21:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9561B2B23 for ; Mon, 13 Jul 2015 07:21:56 -0700 (PDT) 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 7tMi2objQmJx for ; Mon, 13 Jul 2015 07:21:55 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199ED1B2B1F for ; Mon, 13 Jul 2015 07:21:55 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so2861015lbb.1 for ; Mon, 13 Jul 2015 07:21:53 -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:content-transfer-encoding; bh=hJ5in02ZJSvg1MJeEREX+lBdl0qE429wYgWtHkgKb4o=; b=B6b117U+EyqnuIC1k9iHyHZhm5+3erwr3Uf56ImA8z0/EKMGWOFAJw/KPgnk8ejxja tOZFusK1O2mb1cdT2pxZ3+uNIVEnUBaUgdtw8NC7/Y7AmPmBzQnzQZW0uqUn7EqbMc6B NxgpFMeeallWHqXbMMoOinJffFdf6GTw27exZU2qlBxDyL5GSrLOaXmpgc4rQewl/U1g 9yekE3xFrpkYXqWO662TXiC1WcDLUIJttLFEI2tdWvgZioWzwd4U6ehOQ1cd5Tx3iJNc exFU2zBPn+Yyij6mgLmJb4flzTIlC3Dg/Y8CJA5UuwdzKbF42OOQUOEgaM/LXHo1Br4P RKUQ== MIME-Version: 1.0 X-Received: by 10.152.37.196 with SMTP id a4mr32993804lak.59.1436797313573; Mon, 13 Jul 2015 07:21:53 -0700 (PDT) Received: by 10.112.148.105 with HTTP; Mon, 13 Jul 2015 07:21:53 -0700 (PDT) In-Reply-To: <20150710142944.C077C1A1D5@ld9781.wdf.sap.corp> References: <20150710142944.C077C1A1D5@ld9781.wdf.sap.corp> Date: Mon, 13 Jul 2015 16:21:53 +0200 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 14:21:57 -0000 On Fri, Jul 10, 2015 at 4:29 PM, Martin Rex wrote: > Henrik Grubbstr=C3=B6m wrote: >> Martin Rex wrote: >>> The issue here is the (lack of the) TLSv1.2 signature_algorithms extens= ion. >>> >>> Windows SChannel appears to treat the absence of this extension >>> the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha= 1,dsa) >>> >>> If you send the TLSv1.2 signature_algorithms extension with the >>> algorithm matching the signature of the server certificate, e.g. >>> (sha256,rsa) in the above example, then a TLSv1.2 handshake will succee= d. >> >> Sounds like it is complying with the TLS v1.2 RFC. Fix your client. > > > Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions= . > SCHannel is violating a MUST requirement, failing to properly process > a ServerHello without a TLS extension. > > https://tools.ietf.org/html/rfc5246#section-7.4.1.2 > > 7.4.1.2 ClientHello > > extensions > Clients MAY request extended functionality from servers by sending > data in the extensions field. The actual "Extension" format is > defined in Section 7.4.1.4. > > > A server MUST accept ClientHello > messages both with and without the extensions field, Yes, and section 7.4.1.4.1 says that that means: | If the client does not send the signature_algorithms extension, the | server MUST do the following: | | - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, | DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had | sent the value {sha1,rsa}. | | - If the negotiated key exchange algorithm is one of (DHE_DSS, | DH_DSS), behave as if the client had sent the value {sha1,dsa}. | | - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, | ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. Which indicates that the server in effect MUST behave as if there was an implicit signature_algorithms value of {{sha1,rsa},{sha1,dsa},{sha1,ecdsa}}. Section 7.4.2 then says that the certificate chain either MUST or SHOULD (depending on the interpretation of the "behave as if" above) be validated against the implicit signature_algorithms extension. --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Mon Jul 13 07:30:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1A1B2B28 for ; Mon, 13 Jul 2015 07:30:09 -0700 (PDT) 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 5NDx6HoDWbhS for ; Mon, 13 Jul 2015 07:30:07 -0700 (PDT) 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 BE1D71B2B20 for ; Mon, 13 Jul 2015 07:30:07 -0700 (PDT) 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 3E94A2A896; Mon, 13 Jul 2015 16:30:06 +0200 (CEST) X-purgate-ID: 152705::1436797806-00000B48-172B2CDE/0/0 X-purgate-size: 1180 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 2C88940393; Mon, 13 Jul 2015 16:30:06 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2463E1A1DC; Mon, 13 Jul 2015 16:30:06 +0200 (CEST) In-Reply-To: To: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= Date: Mon, 13 Jul 2015 16:30:06 +0200 (CEST) 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: <20150713143006.2463E1A1DC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 13 Jul 2015 14:30:09 -0000 Henrik Grubbstr=F6m wrote: > Martin Rex wrote: >> >> Nope, _our_ client is perfectly compliant by _not_ sending TLS extension= s. >> SCHannel is violating a MUST requirement, failing to properly process >> a ServerHello without a TLS extension. >> >> https://tools.ietf.org/html/rfc5246#section-7.4.1.2 >> >> 7.4.1.2 ClientHello >> >> extensions >> Clients MAY request extended functionality from servers by sending >> data in the extensions field. The actual "Extension" format is >> defined in Section 7.4.1.4. >> >> >> A server MUST accept ClientHello >> messages both with and without the extensions field, >=20 > Yes, and section 7.4.1.4.1 says that that means: Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT for a client that does not use Hello Extensions. You are looking at a defect of the rfc5246 document. As rfc2026 says, defects in "proposed standards" are to be expected -- and implementors with a clue about formal correctness proofing recognize specification defects and compensate for it while implementing. -Martin From nobody Mon Jul 13 07:37:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5182E1B2B3D for ; Mon, 13 Jul 2015 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 LCovk3DLZkYc for ; Mon, 13 Jul 2015 07:37:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095D11B2B2F for ; Mon, 13 Jul 2015 07:37:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 28E0D284D6A; Mon, 13 Jul 2015 14:37:29 +0000 (UTC) Date: Mon, 13 Jul 2015 14:37:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150713143728.GN28047@mournblade.imrryr.org> References: <20150713143006.2463E1A1DC@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150713143006.2463E1A1DC@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Mon, 13 Jul 2015 14:37:36 -0000 On Mon, Jul 13, 2015 at 04:30:06PM +0200, Martin Rex wrote: > Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT > for a client that does not use Hello Extensions. Let's not go back to lawyering the RFCs. We've been there already, with not much success. I think we can reach consensus around the proposed new language that fixes the specification defect for TLS 1.3. Once that's done, where necessary, we can suggest to implementors of TLS 1.2 to "improve the product by not complying with section 7.4.1.4.1 of RFC 5246 in a future release". I am confident this has a much better chance of success than trying to convince folks that their reading of the RFC is incorrect. And in any case, when the client *does* send a supported algorithms extension, that should *still* not rigidly constrain the server to a certificate chain with just those algorithms, Rather, as proposed, the server should strive to vend a chain with just the supported algorithms if at all possible, but failing that it should continue the handshake with some suitable chain it has at its disposal. -- Viktor. From nobody Mon Jul 13 07:40:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D2A1B2B41 for ; Mon, 13 Jul 2015 07:40:39 -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 PQF3F3fsTQpu for ; Mon, 13 Jul 2015 07:40:37 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9021B2B3C for ; Mon, 13 Jul 2015 07:40:37 -0700 (PDT) Received: by qkdv3 with SMTP id v3so60073102qkd.3 for ; Mon, 13 Jul 2015 07:40:36 -0700 (PDT) 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=FMnze+yJMGQdZVhLxqE++tLrgBU5ZevEBBsumTxe8HQ=; b=odtvLqNiDEXUyRY9ZAUAt6RAaQSISXu9rq9OQqH5Gq2y2hH9Mu6RVOCc1glVCxRWfR K805irfR3C3wDiuBkIx8iSu1Bip4ZO2gpUpcKwOIy0+yU+zWEhn5L5CFUuTeMYHf4vmG 62U+Lbx/o2dp/K43KfJeIloljfgPhnieHnFGgND191R4NEPJ8uXcsgJmLNDyiqRn66H1 2DXb1d3TFMGNUdz63RV/A7cqajtPdMBh0prmhpSVq3Hr2cniaP3koeYgPJUSp8jHqbuB zNmT5C9dbQJojKnGs0A774lf+xFPoZTbaC9DgNOjpYL4Ji8Bwpctk8s7X9qeBbYjacBA npUw== X-Received: by 10.55.26.94 with SMTP id a91mr8207126qka.20.1436798436650; Mon, 13 Jul 2015 07:40:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id d30sm5327380qkh.45.2015.07.13.07.40.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Jul 2015 07:40:36 -0700 (PDT) From: Dave Garrett To: mrex@sap.com Date: Mon, 13 Jul 2015 10:40:34 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150713143006.2463E1A1DC@ld9781.wdf.sap.corp> In-Reply-To: <20150713143006.2463E1A1DC@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507131040.35143.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 14:40:39 -0000 On Monday, July 13, 2015 10:30:06 am Martin Rex wrote: > Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT > for a client that does not use Hello Extensions. If you want to put it that way, sure, however they are NOT irrelevant for a _server_ that does use hello extensions. This is a direct part of the TLS 1.2 spec, therefore it is very well established that not sending the extension is a direct request for SHA1, and the server supporting this extension is required to interpret it that way. The expectations on what to do in lieu of that working are bad; that's what we want to fix here. Dave From nobody Mon Jul 13 09:10:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471C51A8A48 for ; Mon, 13 Jul 2015 09:10:55 -0700 (PDT) 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 3t2RLEqLE2g3 for ; Mon, 13 Jul 2015 09:10:54 -0700 (PDT) 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 E04691A8A46 for ; Mon, 13 Jul 2015 09:10:53 -0700 (PDT) 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 31CF22A87B; Mon, 13 Jul 2015 18:10:52 +0200 (CEST) X-purgate-ID: 152705::1436803852-0000413A-52072989/0/0 X-purgate-size: 613 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 2224840688; Mon, 13 Jul 2015 18:10:52 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1946D1A1DD; Mon, 13 Jul 2015 18:10:52 +0200 (CEST) In-Reply-To: <201507131040.35143.davemgarrett@gmail.com> To: Dave Garrett Date: Mon, 13 Jul 2015 18:10:52 +0200 (CEST) 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: <20150713161052.1946D1A1DD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 13 Jul 2015 16:10:55 -0000 Dave Garrett wrote: > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote: >> Section 7.4.1.4 Hello Extensions and its subsections are clearly >> IRRELEVANT for a client that does not use Hello Extensions. > > If you want to put it that way, sure, however they are NOT irrelevant > for a _server_ that does use hello extensions. This is a direct part > of the TLS 1.2 spec, That particular MUST in 7.4.1.4.1 is *VOID* because it is incompatible with rfc2119 section 6. As it can be easily verified, the behaviour described in rfc5246 is detrimental to interoperability and security. -Martin From nobody Mon Jul 13 09:28:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7C91B2C25 for ; Mon, 13 Jul 2015 09:28:15 -0700 (PDT) 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 QgYtg2MzIFh6 for ; Mon, 13 Jul 2015 09:28:13 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCC11B2C1D for ; Mon, 13 Jul 2015 09:28:13 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 10A5B1A28A6; Mon, 13 Jul 2015 19:28:10 +0300 (EEST) Date: Mon, 13 Jul 2015 19:28:10 +0300 From: Ilari Liusvaara To: Martin Rex Message-ID: <20150713162810.GA21594@LK-Perkele-VII> References: <201507131040.35143.davemgarrett@gmail.com> <20150713161052.1946D1A1DD@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150713161052.1946D1A1DD@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 16:28:15 -0000 On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote: > Dave Garrett wrote: > > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote: > >> Section 7.4.1.4 Hello Extensions and its subsections are clearly > >> IRRELEVANT for a client that does not use Hello Extensions. > > > > If you want to put it that way, sure, however they are NOT irrelevant > > for a _server_ that does use hello extensions. This is a direct part > > of the TLS 1.2 spec, > > That particular MUST in 7.4.1.4.1 is *VOID* because it is incompatible with > rfc2119 section 6. As it can be easily verified, the behaviour > described in rfc5246 is detrimental to interoperability and security. I don't see such conflict (except with TLS 1.0/1.1 client with TLS 1.2 server). The scenarios where that sort of behaviour would cause actual interop trouble (meaning it could have worked otherwise, assuming non- buggy client/server) are: - TLS 1.0/1.1 client (ClientVersion 3.1 or 3.2) connecting to TLS 1.2 server. Or - Server cert chain contains certificates TLS 1.2+ client does not care about (e.g. TLSA or excess certificates). The proposed changes for TLS 1.3 are for the latter case. (Then there is whole separate question on how compatible inter- operability and security are, and the answer seems to be not very). -Ilari From nobody Mon Jul 13 10:05:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC851A6FF5 for ; Mon, 13 Jul 2015 10:05:50 -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 XMt6jrz9thfu for ; Mon, 13 Jul 2015 10:05:49 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF0E1A6FF0 for ; Mon, 13 Jul 2015 10:05:48 -0700 (PDT) Received: by wiga1 with SMTP id a1so75589847wig.0 for ; Mon, 13 Jul 2015 10:05: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xyA+PjymTzoTmA2LNVYCS9A8Wq9DkHUlVVZRW7GprNM=; b=cAcYr0oeIp/C/g1gxujQsFjDuDVaNKitaLAEkI0yaUq4rt2nRABCFZaAUE/Up8O63G D1OGD4LQmwWhMFQwQCWr0GznbVCzngJv4lfvjvFL4ucC7IEJsgMecTrzhalpwrKg9va9 Psci9C/wVeqsjowSsuEDxHy4sixuLXQm514ozy95aSowMZLNJs6dYLfCoYIFej5zlKAg lbV30OmTCAaVvXZ+dNxsVYheoHn6PuDtX/iFiEm7B1zP2RcBUJtQk5vts48aK0h0hPqQ KTcGTBNH/TTyMsghKm7dDaeh4qVeJ8xkYslY7ZHX5murD+M+Ifz5kJQE6anWEVP5yxm+ fYPA== X-Gm-Message-State: ALoCoQm3y5J9GHFR/X/wXotnuas+DpExEuBVwz1Mtg2C3FwXqJ+0ivCYwaU8QW3/f5lotW1WJkjE X-Received: by 10.180.99.39 with SMTP id en7mr25089399wib.31.1436807147310; Mon, 13 Jul 2015 10:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Mon, 13 Jul 2015 10:05:07 -0700 (PDT) In-Reply-To: <20150713162810.GA21594@LK-Perkele-VII> References: <201507131040.35143.davemgarrett@gmail.com> <20150713161052.1946D1A1DD@ld9781.wdf.sap.corp> <20150713162810.GA21594@LK-Perkele-VII> From: Eric Rescorla Date: Mon, 13 Jul 2015 10:05:07 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d04182808a066d6051ac4bb91 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 17:05:50 -0000 --f46d04182808a066d6051ac4bb91 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 9:28 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote: > > Dave Garrett wrote: > > > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote: > > >> Section 7.4.1.4 Hello Extensions and its subsections are clearly > > >> IRRELEVANT for a client that does not use Hello Extensions. > > > > > > If you want to put it that way, sure, however they are NOT irrelevant > > > for a _server_ that does use hello extensions. This is a direct part > > > of the TLS 1.2 spec, > > > > That particular MUST in 7.4.1.4.1 is *VOID* because it is incompatible > with > > rfc2119 section 6. As it can be easily verified, the behaviour > > described in rfc5246 is detrimental to interoperability and security. > > I don't see such conflict (except with TLS 1.0/1.1 client with TLS 1.2 > server). The scenarios where that sort of behaviour would cause actual > interop trouble (meaning it could have worked otherwise, assuming non- > buggy client/server) are: > > - TLS 1.0/1.1 client (ClientVersion 3.1 or 3.2) connecting to TLS 1.2 > server. Or > Hmm... TLS 1.2 servers shouldn't be following this section if the client is claiming to be TLS 1.0 or 1.1. I don't think that this section says that you should (since in that case the TLS 1.1 or TLS 1.0 spec would control) but in any case, it shouldn't say that and I never interpreted it that way. -Ekr --f46d04182808a066d6051ac4bb91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 9:28 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= span class=3D"">On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote:=
> Dave Garrett wrote:
> > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
> >> Section 7.4.1.4 Hello Extensions and its subsections are clea= rly
> >> IRRELEVANT for a client that does not use Hello Extensions. > >
> > If you want to put it that way, sure, however they are NOT irrele= vant
> > for a _server_ that does use hello extensions. This is a direct p= art
> > of the TLS 1.2 spec,
>
> That particular MUST in 7.4.1.4.1 is *VOID* because it is incompatible= with
> rfc2119 section 6.=C2=A0 As it can be easily verified, the behaviour > described in rfc5246 is detrimental to interoperability and security.<= br>
I don't see such conflict (except with TLS 1.0/1.1 client with T= LS 1.2
server). The scenarios where that sort of behaviour would cause actual
interop trouble (meaning it could have worked otherwise, assuming non-
buggy client/server) are:

- TLS 1.0/1.1 client (ClientVersion 3.1 or 3.2) connecting to TLS 1.2
=C2=A0 server. Or

Hmm... TLS 1.2 server= s shouldn't be following this section if the client
is claimi= ng to be TLS 1.0 or 1.1. I don't think that this section says=C2=A0
that you should (since in that case the TLS 1.1 or TLS 1.0 spec woul= d
control) but in any case, it shouldn't say that and I never= interpreted
it that way.

-Ekr


--f46d04182808a066d6051ac4bb91-- From nobody Mon Jul 13 10:06:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84331A6FF0 for ; Mon, 13 Jul 2015 10:06:21 -0700 (PDT) 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 um6SqvntU7ul for ; Mon, 13 Jul 2015 10:06:19 -0700 (PDT) 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 52ECA1B2C2A for ; Mon, 13 Jul 2015 10:06:19 -0700 (PDT) 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 F35BE4426D; Mon, 13 Jul 2015 19:06:15 +0200 (CEST) X-purgate-ID: 152705::1436807176-0000413A-E21A56CF/0/0 X-purgate-size: 1000 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id E586C40414; Mon, 13 Jul 2015 19:06:15 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DF8201A1DD; Mon, 13 Jul 2015 19:06:15 +0200 (CEST) In-Reply-To: <20150711211403.GB19435@LK-Perkele-VII> To: Ilari Liusvaara Date: Mon, 13 Jul 2015 19:06:15 +0200 (CEST) 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: <20150713170615.DF8201A1DD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 13 Jul 2015 17:06:21 -0000 Ilari Liusvaara wrote: > > E.g. if client advertised {sha256, ecdsa} + in its > signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > + others in its ciphersuites, then the server MAY pick > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to > sign the handshake with ECDSA/SHA-256. Despite there being > no DHE_ECDSA ciphersuites. Which part of which RFC makes you believe that such weird behaviour would be allowed? The key exchange algorithm in the TLS cipher suites requires a specific kind of asymmetric key in the server certificate. A DHE_RSA key exchange requires a server certificate with an RSA key. The key of the CA that signed the server certificate ought to be irrelevant -- it *WAS* irrelevant in SSLv3, and the words in rfc2246 that suggest otherwise are a defect in rfc2246 (a defect, for which I haven't yet seen an implementor who got it wrong and implemented it in the obviously bogus fashion that rfc2246 suggests). -Martin From nobody Mon Jul 13 10:11:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD00A1B2C40 for ; Mon, 13 Jul 2015 10:11:52 -0700 (PDT) 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 mRSJNDaVKdN7 for ; Mon, 13 Jul 2015 10:11:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC011B2C3C for ; Mon, 13 Jul 2015 10:11:50 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 13 Jul 2015 17:11:29 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0213.000; Mon, 13 Jul 2015 17:11:29 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpCAAUrngIAADsEAgAAC7oCAABbWgIAANnyAgAAH4ACAAAoZgIAAB+GAgAAMDwCAAAXygIAAI+yAgAADFACAAd8BsIAACoIAgADHX/A= Date: Mon, 13 Jul 2015 17:11:29 +0000 Message-ID: References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> <20150713044104.GK28047@mournblade.imrryr.org> In-Reply-To: <20150713044104.GK28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:ByMS39/FWo+wZYM34JeJtgagjOpIdFPNGcVzVbbZxGc5CmTZQ1fOz4FvO86h3Awv1VJxhU7MibqEyWHEIzGletzOjeu1C77nxsy8MH/nT9USi72uhq0ihg6N6qRBJQxoiA8l2pNI05eSLuzmhJoSfg==; 24:ThlBEfJ2qXRkIw/KSlKaQN8VsGM/cmf9jspVYrLrNx7jl0N4nnmZUsnwkFzwh66ZP2ExUdxDiYKnzXOMaRefa6Syr3dp7AkF8eO86eLwQAg=; 20:mYpJNtjIsPacK3kX2c06ql0o9NtAFVZXJ5og5WLW4EYZjE8s4VsTGUfkT/SBLqBOILeXr+tisDddKtqjhe4ktg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; blupr03mb1396: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(13464003)(377454003)(54356999)(86612001)(33656002)(76576001)(15975445007)(86362001)(99286002)(102836002)(92566002)(189998001)(2900100001)(5003600100002)(74316001)(2950100001)(5002640100001)(40100003)(122556002)(19580395003)(450100001)(107886002)(19580405001)(5001960100002)(62966003)(77156002)(77096005)(110136002)(50986999)(2501003)(76176999)(46102003)(87936001)(93886004)(2656002)(2351001)(561944003)(106116001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 17:11:29.0575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 17:11:52 -0000 I think a good design is to have the client explicitly advertise any algori= thms the client is willing/able to support, and for the server to honor the= client's capabilities. IMHO the existing specs already meet the above goal, with an unfortunate qu= irk that SHA1/MD5-only clients don't have to be explicit about their suppor= ted signature/hash combinations. This quirk has caused some confusion, but = this should be easy to fix in 1.3 by requiring that all algorithms are adve= rtised. > Which part are you objecting to? The subsequent proposal to suppress > SHA-1 advertisements (if the client supports only TLS 1.3 or later) when = even when the client is willing to accept a SHA-1 chain when all else fails= ? =20 No, I don't care for SHA1; let's deprecate it ASAP. I do care for a straigh= tforward and deterministic handshake where the client MUST advertise suppor= ted algorithms and the server MUST honor the client's capabilities. Having shipped a product that implements the strict interpretation of the c= urrent specs (WRT signature_algorithms) for a number of years now, I rememb= er exactly 3 related problem reports. Without pointing fingers (as much as = possible), here they are: 1. A version of a popular Web browser failed to interoperate because it did= not include all of its supported algorithms in the signature_algorithms ex= tension. Unfortunately, the browser had already been fixed by the time I re= ported the issue to them, so I could not use this incident as an opportunit= y to promote IE. :) 2. An open-source TLS stack that had just added TLS1.2 support, but did not= implement extensions. I pointed them at the signature_algorithms section o= f the RFC and they quickly implemented this extension. 3. A vocal participant of this mailing list who seems to be opposed to the = idea of making certain TLS extensions MTI, as a matter of principle. My preference would be to keep the client explicitly advertising its capabi= lities, and the server strictly honoring the client-advertised capabilities= . And since the concept of "default algorithms" confuses people, let's just= get rid of it in 1.3. Conveniently, most of this WG no longer wants SHA1 o= r MD5. Why not just make signature_algorithms (even more) clearly and unamb= iguously MTI in 1.3? Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Sunday, July 12, 2015 9:41 PM To: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek) On Mon, Jul 13, 2015 at 04:11:04AM +0000, Andrei Popov wrote: > I'm not happy with this either. The spec already says: >=20 > "If the client supports only the default hash and signature algorithms > (listed in this section), it MAY omit the signature_algorithms > extension. If the client does not support the default algorithms, or > supports other hash and signature algorithms (and it is willing to > use them for verifying messages sent by the server, i.e., server > certificates and server key exchange), it MUST send the > signature_algorithms extension, listing the algorithms it is willing > to accept." >=20 > This seems to be pretty clear: if the client properly advertises the=20 > algorithms it supports, then the handshake has a deterministic outcome. That's all fine, we're talking about what the server should do when it is c= ertificate chain does not (in its entirety) match those algorithms. And in= the context of TLS 1.3 which is not yet set in stone. =20 Which part are you objecting to? The subsequent proposal to suppress SHA-1 advertisements (if the client supports only TLS 1.3 or later) when ev= en when the client is willing to accept a SHA-1 chain when all else fails? = That too seems sensible, and it was already noted that clients will need t= o send the SHA-1 codepoint when willing to accept TLS 1.2, since that spec = does not contain the proposed new language for server-side behaviour. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 13 10:45:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE91B2CB5 for ; Mon, 13 Jul 2015 10:45:08 -0700 (PDT) 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 mV9JXH39SCwp for ; Mon, 13 Jul 2015 10:45:07 -0700 (PDT) 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 134911B2CC3 for ; Mon, 13 Jul 2015 10:45:06 -0700 (PDT) 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 7CD1A2A8AA; Mon, 13 Jul 2015 19:45:03 +0200 (CEST) X-purgate-ID: 152705::1436809503-0000413A-34B513B6/0/0 X-purgate-size: 1964 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6F6F940494; Mon, 13 Jul 2015 19:45:03 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 66E451A1DD; Mon, 13 Jul 2015 19:45:03 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Mon, 13 Jul 2015 19:45:03 +0200 (CEST) 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: <20150713174503.66E451A1DD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 13 Jul 2015 17:45:08 -0000 Andrei Popov wrote: > > I think a good design is to have the client explicitly advertise any > algorithms the client is willing/able to support, and for the server > to honor the client's capabilities. A good design provides robust interop and good backwards-interoperability, and a reasonble default set of algorithms to be unconditionally available. Why TLSv1.2 did imply availability of sha256WithRsaEncryption by default, is beyond my understanding. The rfc5246 PDU Definition for ClientHello clearly makes HelloExtensions and optional (MAY) feature for clients and the acceptance of extension-less ClientHellos a mandatory (MUST) feature for Servers. Similarily, Appendix E allows the use of a SSL Version 2 CLIENT-HELLO instead of and extension-less TLS ClientHello, It has already been observed by others, a server can not make up signatures with client-requested signature schemes at will during the TLS handshake, but can only pick from the set of existing server certificates that have been preconfigured by the server admin -- and often this may be just one single server certificate. The server responding with an ambiguous "handshake_failure" if the admin-configured server cert does not fit the silly "implicit" algs that a server boldly assumes based on the design-flawed wording in rfc5246 7.4.1.4.1 in absence of ClientHelloExtensions is is a bad idea, and if the client-visible behaviour is a silent connection closure (this is what Microsoft IIS does) it is the worst possible outcome. This behaviour is completely indistinguishable from that of defective extensions-intolerant and TLS-version intolerant servers! Would the server respond with the next best fit (the way this has been and still is being done, even by Microsoft SChannel, for SSLv3, TLSv1.0 and TLSv1.1), then the client can at least produce a meaningful error message and show the certificates that it can not process. -Martin From nobody Mon Jul 13 11:01:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067751B2CE3 for ; Mon, 13 Jul 2015 11:01:56 -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 caO0skKq5LHn for ; Mon, 13 Jul 2015 11:01:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACC71B2CE2 for ; Mon, 13 Jul 2015 11:01:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5C950284D6A; Mon, 13 Jul 2015 18:01:53 +0000 (UTC) Date: Mon, 13 Jul 2015 18:01:53 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150713180153.GO28047@mournblade.imrryr.org> References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> <20150713044104.GK28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Mon, 13 Jul 2015 18:01:56 -0000 On Mon, Jul 13, 2015 at 05:11:29PM +0000, Andrei Popov wrote: > I think a good design is to have the client explicitly advertise any > algorithms the client is willing/able to support, and for the server to > honor the client's capabilities. To the extent possible. However, the server SHOULD NOT refuse to continue the handshake merely because it believes that some certificates in its chain might have signatures the client can't check. The point being that the client may not need or attempt to check those signatures. > IMHO the existing specs already meet the above goal, No, the language about the certificate chain is needlessly restrictive. The decision as to whether the chain works for the client or not, SHOULD be left to the client. The server's job is to *try* to avoid problems by sending a known-compatible chain when available. > No, I don't care for SHA1; let's deprecate it ASAP. I do care for a > straightforward and deterministic handshake where the client MUST advertise > supported algorithms and the server MUST honor the client's capabilities. The MUST honour bit cleanly applies to choices of algorithms in signature the server makes during and after the handshake. However, honouring the algorithms for the chain signatures is more subtle. Yes, send a compatible chain when possible, HOWEVER, DO NOT prejudge the client's inability to handle an alternative chain if that's all you have. As explained before, opportunistic TLS, DANE, pinning, ... may mean that the client does not in fact examine the signatures in the chain and the handshake would succeed, if only the server were not needlessly pedantic. Let's not be needlessly pedantic. > Having shipped a product that implements the strict interpretation of the > current specs (WRT signature_algorithms) for a number of years now, I > remember exactly 3 related problem reports. Without pointing fingers (as > much as possible), here they are: Past performance is not a guarantee of future returns. Today, TLS 1.2 clients generally support all the defined hash algorithms, so problems are rare. In the future, there will be new hash algorithms that not all clients will support, and there will servers with chains that are signed with bleeding-edge algorithms, there's no need to reject connections from clients that don't need to verify said signatures. > My preference would be to keep the client explicitly advertising its > capabilities, and the server strictly honoring the client-advertised > capabilities. And since the concept of "default algorithms" confuses > people, let's just get rid of it in 1.3. Conveniently, most of this WG no > longer wants SHA1 or MD5. Why not just make signature_algorithms (even > more) clearly and unambiguously MTI in 1.3? An opportunistic TLS or DANE TLSA client cannot advertise the capability of supporting algorithms it was aware existed (by ignoring all signatures in the chain). We surely don't want to muddy the waters by adding "wildcard" algorithm code-points, and new APIs for clients to request that the TLS stack send those. The proposal on the table is simply sensible. The server lacks sufficient information to make an informed decision as to whether its chain is unacceptable, and therefore should send whatever chain it has if it lacks a known compatible chain. This is simply sound engineering. The alternative is needless incompatibility. That this also fixes the problem for some folks who don't want to make sending the extension mandatory (and happen to get back a chain they can accept) is a harmless accident. -- Viktor. From nobody Mon Jul 13 11:18:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1621B2D09 for ; Mon, 13 Jul 2015 11:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 FA0KEw0QGgm3 for ; Mon, 13 Jul 2015 11:18:39 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id D80BE1B2D07 for ; Mon, 13 Jul 2015 11:18:38 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t6DIIbN0002146 for ; Mon, 13 Jul 2015 14:18:37 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqHM/L4/ZIBKEisF6Kbx4+pEp3QcEqAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxdgIAAAVmAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXHgIAACRMAgAADNACAAAGXgIAAA+MAgAAW+YCAAUSAgIAADsIAgAAC7YCAABbWgIAANnyAgAAH4ACAAAoZgIAAB+GAgAAMDwCAAAXygIAAI+yAgAADFACAAeEhAIAACGIAgADRqoCAAA4VgP//wZCA Date: Mon, 13 Jul 2015 18:18:36 +0000 Message-ID: References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> <20150713044104.GK28047@mournblade.imrryr.org> <20150713180153.GO28047@mournblade.imrryr.org> In-Reply-To: <20150713180153.GO28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3519641905_31005220" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-13_10:2015-07-13,2015-07-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-1506180000 definitions=main-1507130258 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 18:18:41 -0000 --B_3519641905_31005220 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable To keep it short, +1 to Viktor=E2=80=99s point. --=20 Regards, Uri Blumenthal On 7/13/15, 14:01 , "TLS on behalf of Viktor Dukhovni" wrote: >On Mon, Jul 13, 2015 at 05:11:29PM +0000, Andrei Popov wrote: > >> I think a good design is to have the client explicitly advertise any >> algorithms the client is willing/able to support, and for the server to >> honor the client's capabilities. > >To the extent possible. However, the server SHOULD NOT refuse to >continue the handshake merely because it believes that some >certificates in its chain might have signatures the client can't >check. The point being that the client may not need or attempt to >check those signatures. > >> IMHO the existing specs already meet the above goal, > >No, the language about the certificate chain is needlessly restrictive. >The decision as to whether the chain works for the client or not, >SHOULD be left to the client. The server's job is to *try* to avoid >problems by sending a known-compatible chain when available. > >> No, I don't care for SHA1; let's deprecate it ASAP. I do care for a >> straightforward and deterministic handshake where the client MUST >>advertise >> supported algorithms and the server MUST honor the client's >>capabilities. > >The MUST honour bit cleanly applies to choices of algorithms in >signature the server makes during and after the handshake. However, >honouring the algorithms for the chain signatures is more subtle. >Yes, send a compatible chain when possible, HOWEVER, DO NOT prejudge >the client's inability to handle an alternative chain if that's >all you have. As explained before, opportunistic TLS, DANE, pinning, >... may mean that the client does not in fact examine the signatures >in the chain and the handshake would succeed, if only the server >were not needlessly pedantic. > >Let's not be needlessly pedantic. > >> Having shipped a product that implements the strict interpretation of >>the >> current specs (WRT signature_algorithms) for a number of years now, I >> remember exactly 3 related problem reports. Without pointing fingers (as >> much as possible), here they are: > >Past performance is not a guarantee of future returns. > >Today, TLS 1.2 clients generally support all the defined hash >algorithms, so problems are rare. In the future, there will be >new hash algorithms that not all clients will support, and there >will servers with chains that are signed with bleeding-edge >algorithms, there's no need to reject connections from clients that >don't need to verify said signatures. > > >> My preference would be to keep the client explicitly advertising its >> capabilities, and the server strictly honoring the client-advertised >> capabilities. And since the concept of "default algorithms" confuses >> people, let's just get rid of it in 1.3. Conveniently, most of this WG >>no >> longer wants SHA1 or MD5. Why not just make signature_algorithms (even >> more) clearly and unambiguously MTI in 1.3? > >An opportunistic TLS or DANE TLSA client cannot advertise the >capability of supporting algorithms it was aware existed (by ignoring >all signatures in the chain). > >We surely don't want to muddy the waters by adding "wildcard" >algorithm code-points, and new APIs for clients to request that >the TLS stack send those. > >The proposal on the table is simply sensible. The server lacks >sufficient information to make an informed decision as to whether >its chain is unacceptable, and therefore should send whatever chain >it has if it lacks a known compatible chain. This is simply sound >engineering. The alternative is needless incompatibility. > >That this also fixes the problem for some folks who don't want to >make sending the extension mandatory (and happen to get back a >chain they can accept) is a harmless accident. > >--=20 > Viktor. > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --B_3519641905_31005220 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgmEzx8t8MD7mpd8asmf9f0IpKcUvWW7bCQhjetVmXWFQwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzEzMTgxODI1WjANBgkqhkiG9w0BAQEFAASC AQCyiOP4Yfu22FG6QyrMGcZEGCN5OyXoGtMt74GwCLUfRfOw1s89ifO2R4YyjrdfWDi2Qcx6 WHLkzVA5otXZOs+OOaGBpjcZszskHyWKDdqgQ6bR/477n/uPdi9Osl7B7oGb4fm6AXS9Zlsa QAYSHVN5HU6ujkVdmKtEDWHhqgn/hP9B6zMWbczHtCpcVnpGsXngWX/pXcQcApJ+oyBelTzR 3M4dRT4Duth5MFD0IDxdMgNR7Ram7k2raWJfuOxAYdVLh1NOWe/coolKAqU4ZXuyZZy4qNRc rRJhZOjfx0wPMMOQ60Jt+T5qXmTg+7Y9F/uE7i3NGUrprHfmdO06E7NL --B_3519641905_31005220-- From nobody Mon Jul 13 11:52:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3811B2D2A for ; Mon, 13 Jul 2015 11:52:14 -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 qKXnczB_KVqQ for ; Mon, 13 Jul 2015 11:52:12 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F291B2D22 for ; Mon, 13 Jul 2015 11:52:12 -0700 (PDT) Received: by qgef3 with SMTP id f3so110927992qge.0 for ; Mon, 13 Jul 2015 11:52:11 -0700 (PDT) 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=JSh+QxxfFu/Jul+aVCUgNdjr5pxEzgiDfZdOAc0nQQc=; b=Yj308yZ3PJSaT+bDxXtXyc6fwb4Zf8nDTfjZnC8jJo3IWZMotuSxeMtff6ulVcdhCp U/+Zt5hZjsS2C5vqeXDlXc3l9tEeDg9xpyYMRtrYZyZWQ7xiGcjB1mB6LMjO62dgaVig OCEhst9FpdEcjtXHmRO6yN4GwLe70pv312LMHPIwPIIMWce9Poe41hn5ifiX/WI6jiSt xAwKDizo74mcGeOPZ1vGnt2GqbnqZW5HJdaK8AMfE+j5MUzmsTcsqcXbtAckAW/7fCaQ 0bhQULLV17jknFhvbWpmQ7FMVUzd7NeO/9wghQrIzVMcjUA3KPe8WxTkLKIIHaT4EYRe 66ZA== X-Received: by 10.140.148.137 with SMTP id 131mr57115767qhu.60.1436813531838; Mon, 13 Jul 2015 11:52:11 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id f106sm11406880qgd.30.2015.07.13.11.52.11 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Jul 2015 11:52:11 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Andrei Popov Date: Mon, 13 Jul 2015 14:52:09 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150713044104.GK28047@mournblade.imrryr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507131452.10166.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 18:52:14 -0000 On Monday, July 13, 2015 01:11:29 pm Andrei Popov wrote: > My preference would be to keep the client explicitly advertising its capabilities, and the server strictly honoring the client-advertised capabilities. And since the concept of "default algorithms" confuses people, let's just get rid of it in 1.3. Conveniently, most of this WG no longer wants SHA1 or MD5. Why not just make signature_algorithms (even more) clearly and unambiguously MTI in 1.3? Yep. I already have that in a WIP branch at the moment. I'm merging together all my WIPs from WG discussion on the topics of alerts and certs here: https://github.com/davegarrett/tls13-spec/compare/seanfixesredux...davegarrett:alertsandcerts There's a backlog of PRs on main, so diffing on top of Sean Turner's fixes branch to reduce noise in the diff. Dave From nobody Mon Jul 13 12:45:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9511B2DE2 for ; Mon, 13 Jul 2015 12:45:52 -0700 (PDT) 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 gBqDFiByh-yD for ; Mon, 13 Jul 2015 12:45:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBE41B2DDA for ; Mon, 13 Jul 2015 12:45:49 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 13 Jul 2015 19:45:30 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0213.000; Mon, 13 Jul 2015 19:45:30 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpCAAUrngIAADsEAgAAC7oCAABbWgIAANnyAgAAH4ACAAAoZgIAAB+GAgAAMDwCAAAXygIAAI+yAgAADFACAAd8BsIAACoIAgADHX/CAABhggIAAFePg Date: Mon, 13 Jul 2015 19:45:30 +0000 Message-ID: References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> <20150713044104.GK28047@mournblade.imrryr.org> <20150713180153.GO28047@mournblade.imrryr.org> In-Reply-To: <20150713180153.GO28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:ZIokjTxk1uKP82QyAiZOzXbkRKi3ZgkN0SfjVmV6ifUnkg2mFZXUts4nXUxZEQC6r86dl3D8phow1/AoTHRzIZD/acwBLATgwqnMdMIKVQDwRYKWOcQUnThO6UNNBM85ZyEhZcTexiwfAraynkevPg==; 24:8aYrDn/zn704ztrI0vAADzjQbMWUYAN76Mv6hJJYAM6IyH014m88iRLLAYu0Drhw5TgRLGQT1LX363Rnf02uAcePjZ1ZGfz5Uh9dqaDVp7A=; 20:NymGduWtgmNQtGXT4gOo26vz2sApJN01sWYaefrapIFRI55LwcqMqPDhj90eYkC72FUlYsqToyDfbzF/kM1qcg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; blupr03mb1394: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(5001960100002)(122556002)(110136002)(107886002)(40100003)(2900100001)(5003600100002)(77156002)(74316001)(189998001)(450100001)(2501003)(62966003)(86612001)(5002640100001)(92566002)(15975445007)(2950100001)(77096005)(102836002)(33656002)(561944003)(2656002)(54356999)(86362001)(46102003)(50986999)(19580395003)(2351001)(106116001)(19580405001)(87936001)(76176999)(93886004)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 19:45:30.2533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 19:45:52 -0000 > An opportunistic TLS or DANE TLSA client cannot advertise the capability = of supporting algorithms it was aware existed (by ignoring all signatures i= n the chain). > We surely don't want to muddy the waters by adding "wildcard" algorithm c= ode-points, and new APIs for clients to request that the TLS stack send tho= se. Would it make sense for an opportunistic client to advertise all algorithms= commonly supported in the server certs? After all, there are relatively fe= w signature/hash pairs in use, and they are changing very slowly over time. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Monday, July 13, 2015 11:02 AM To: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek) On Mon, Jul 13, 2015 at 05:11:29PM +0000, Andrei Popov wrote: > I think a good design is to have the client explicitly advertise any=20 > algorithms the client is willing/able to support, and for the server=20 > to honor the client's capabilities. To the extent possible. However, the server SHOULD NOT refuse to continue = the handshake merely because it believes that some certificates in its chai= n might have signatures the client can't check. The point being that the c= lient may not need or attempt to check those signatures. > IMHO the existing specs already meet the above goal, No, the language about the certificate chain is needlessly restrictive. The decision as to whether the chain works for the client or not, SHOULD be= left to the client. The server's job is to *try* to avoid problems by sen= ding a known-compatible chain when available. > No, I don't care for SHA1; let's deprecate it ASAP. I do care for a=20 > straightforward and deterministic handshake where the client MUST=20 > advertise supported algorithms and the server MUST honor the client's cap= abilities. The MUST honour bit cleanly applies to choices of algorithms in signature t= he server makes during and after the handshake. However, honouring the alg= orithms for the chain signatures is more subtle. Yes, send a compatible chain when possible, HOWEVER, DO NOT prejudge the cl= ient's inability to handle an alternative chain if that's all you have. As= explained before, opportunistic TLS, DANE, pinning, ... may mean that the= client does not in fact examine the signatures in the chain and the handsh= ake would succeed, if only the server were not needlessly pedantic. Let's not be needlessly pedantic. > Having shipped a product that implements the strict interpretation of=20 > the current specs (WRT signature_algorithms) for a number of years=20 > now, I remember exactly 3 related problem reports. Without pointing=20 > fingers (as much as possible), here they are: Past performance is not a guarantee of future returns. Today, TLS 1.2 clients generally support all the defined hash algorithms, s= o problems are rare. In the future, there will be new hash algorithms that= not all clients will support, and there will servers with chains that are = signed with bleeding-edge algorithms, there's no need to reject connections= from clients that don't need to verify said signatures. > My preference would be to keep the client explicitly advertising its=20 > capabilities, and the server strictly honoring the client-advertised=20 > capabilities. And since the concept of "default algorithms" confuses=20 > people, let's just get rid of it in 1.3. Conveniently, most of this WG=20 > no longer wants SHA1 or MD5. Why not just make signature_algorithms=20 > (even > more) clearly and unambiguously MTI in 1.3? An opportunistic TLS or DANE TLSA client cannot advertise the capability of= supporting algorithms it was aware existed (by ignoring all signatures in = the chain). We surely don't want to muddy the waters by adding "wildcard" algorithm code-points, and new APIs for clients to request that the TLS sta= ck send those. The proposal on the table is simply sensible. The server lacks sufficient = information to make an informed decision as to whether its chain is unaccep= table, and therefore should send whatever chain it has if it lacks a known = compatible chain. This is simply sound engineering. The alternative is ne= edless incompatibility.=20 That this also fixes the problem for some folks who don't want to make send= ing the extension mandatory (and happen to get back a chain they can accept= ) is a harmless accident. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 13 14:21:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9989E1A8991 for ; Mon, 13 Jul 2015 14:21:03 -0700 (PDT) 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 qA-V4l1sh1qB for ; Mon, 13 Jul 2015 14:21:01 -0700 (PDT) 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 61D631A898D for ; Mon, 13 Jul 2015 14:21:01 -0700 (PDT) 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 8385344307; Mon, 13 Jul 2015 23:20:59 +0200 (CEST) X-purgate-ID: 152705::1436822459-0000413A-7EF01667/0/0 X-purgate-size: 1972 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 75D46406A1; Mon, 13 Jul 2015 23:20:59 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6D2091A1DD; Mon, 13 Jul 2015 23:20:59 +0200 (CEST) In-Reply-To: To: Eric Rescorla Date: Mon, 13 Jul 2015 23:20:59 +0200 (CEST) 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: <20150713212059.6D2091A1DD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 13 Jul 2015 21:21:03 -0000 Eric Rescorla wrote: > I'm not necessarily opposed to relaxing this requirement on the server, > but given that: > > 1. SHA-1 is on its way out. > 2. Future versions of TLS seem very likely to explicitly indicate which > hash algorithms the clients support. > > I'm kind of confused about the principle being espoused here. In general, > when the client has told the server what's acceptable and the server > doesn't have it, we abort the handshake. What makes this case different > from (say) the client only supporting P256 and the server only supporting > Curve25519 but deciding to send Curve25519 anyway? The choice of Curve25519 for an ECDHE_RSA or ECDHE_DSA key exchange is a transform at the _TLS_ protocol level that a client's _TLS_ implementation must support in order to perform the TLS handshake. Algorithms for the signature on the server certifcate or signatures higher up the certificate path conveyed by the server are - *NOT* part of the TLS handshake, they're instead performed by what is usally a totally different software module (PKIX) from the TLS protocol implementation - *NOT* predictable to be used to get used (and verified) by the client's certificate path validation function after whatever fancy "certificate path discovery" the client might be performing before validating the server's certificate. The client might also be directly trusting the server's key (cert pinning, DANE usage 3 and other possibilities), where it is not clear whether the the signature on the certificate presented by the server needs to be verified at all. So the difference here is HUGE. Btw., TLSv1.2 implementations that do not support multiple server certificates that differ only by algorithms, are probably skipping the entire TLSv1.2 cert signature algorithms fandango and exhibit a highly interoperable behaviour quite naturally. -Martin From nobody Mon Jul 13 15:08:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBF21A3BA0 for ; Mon, 13 Jul 2015 15:08:24 -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 bXnAE2GO1SM8 for ; Mon, 13 Jul 2015 15:08:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4A91A21C1 for ; Mon, 13 Jul 2015 15:08:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3DAA2284D75; Mon, 13 Jul 2015 22:08:20 +0000 (UTC) Date: Mon, 13 Jul 2015 22:08:20 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150713220819.GQ28047@mournblade.imrryr.org> References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> <20150713044104.GK28047@mournblade.imrryr.org> <20150713180153.GO28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Mon, 13 Jul 2015 22:08:24 -0000 On Mon, Jul 13, 2015 at 07:45:30PM +0000, Andrei Popov wrote: > Would it make sense for an opportunistic client to advertise all algorithms > commonly supported in the server certs? After all, there are relatively > few signature/hash pairs in use, and they are changing very slowly over > time. This does not work when new algorithms are introduced, since you can't advertise algorithms you don't know exist. -- Viktor. From nobody Mon Jul 13 15:31:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6241A700D for ; Mon, 13 Jul 2015 15:31:20 -0700 (PDT) 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, 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 FOrWN_AM58tl for ; Mon, 13 Jul 2015 15:31:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CCD1A6FBB for ; Mon, 13 Jul 2015 15:31:18 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 13 Jul 2015 22:31:16 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0213.000; Mon, 13 Jul 2015 22:31:16 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpCAAUrngIAADsEAgAAC7oCAABbWgIAANnyAgAAH4ACAAAoZgIAAB+GAgAAMDwCAAAXygIAAI+yAgAADFACAAd8BsIAACoIAgADHX/CAABhggIAAFePggAAu+ACAAADfAA== Date: Mon, 13 Jul 2015 22:31:16 +0000 Message-ID: References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> <20150713044104.GK28047@mournblade.imrryr.org> <20150713180153.GO28047@mournblade.imrryr.org> <20150713220819.GQ28047@mournblade.imrryr.org> In-Reply-To: <20150713220819.GQ28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::5] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:Hf72chTRTfJti05MY9YwNwmfbLWgiObhweTXdazX39Y0CO4Gfyc7yiAfJwFx9Pj67qDjgZDyy8yctKnp0rxlcF9PIqfP4JiBu1TRXElFwv9sZcVgkcodyopRDR9hfqvRS7ZmEtmCQPQJSEeVIh9jyQ==; 24:bCcSX8n8vrzerZcdCX14BuJyZGscHfR3PwiS0L0MHYlKlOWA2j2idGVrgOZ/u0PPBrLgFPdIb8sOy62h/oqHaMIpNjAok1SgZUB/6Rh4Nu0=; 20:AjX/IGNKFs2jt3iDeWo86psou2dhRCRLzv1SrU78cs0+WcqDI4E8ICFj9/wf5Dbz8Mdxh+lKAb7QRovIhmOc0Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; blupr03mb1395: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(50986999)(2950100001)(87936001)(2351001)(5001960100002)(189998001)(86612001)(74316001)(107886002)(110136002)(33656002)(62966003)(77156002)(2900100001)(40100003)(450100001)(2656002)(93886004)(2501003)(46102003)(5002640100001)(122556002)(19580395003)(54356999)(19580405001)(86362001)(76176999)(102836002)(106116001)(76576001)(5003600100002)(92566002)(77096005)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 22:31:16.5224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2015 22:31:20 -0000 > This does not work when new algorithms are introduced, since you can't ad= vertise algorithms you don't know exist. When old algorithms are deprecated and new algorithms replace them in actua= l deployments (a very slow process), an opportunistic client would need to = be updated, just like a normal server-authenticating client does. Except fo= r the opportunistic client this update would be rather trivial. Alternatively, can an opportunistic client explicitly negotiate anonymous c= onnections? -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Monday, July 13, 2015 3:08 PM To: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek) On Mon, Jul 13, 2015 at 07:45:30PM +0000, Andrei Popov wrote: > Would it make sense for an opportunistic client to advertise all=20 > algorithms commonly supported in the server certs? After all, there=20 > are relatively few signature/hash pairs in use, and they are changing=20 > very slowly over time. This does not work when new algorithms are introduced, since you can't adve= rtise algorithms you don't know exist. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 13 16:08:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0041A8734 for ; Mon, 13 Jul 2015 16:08:17 -0700 (PDT) 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 7XmIhBEkKQ5C for ; Mon, 13 Jul 2015 16:08:13 -0700 (PDT) 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 1A2C31A6FF8 for ; Mon, 13 Jul 2015 16:08:13 -0700 (PDT) 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 54DE12A9D8 for ; Tue, 14 Jul 2015 01:08:11 +0200 (CEST) X-purgate-ID: 152705::1436828891-0000413A-636D6F3B/0/0 X-purgate-size: 881 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 472EA40676 for ; Tue, 14 Jul 2015 01:08:11 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3D5C51A1DD; Tue, 14 Jul 2015 01:08:11 +0200 (CEST) In-Reply-To: <20150713220819.GQ28047@mournblade.imrryr.org> To: tls@ietf.org Date: Tue, 14 Jul 2015 01:08:11 +0200 (CEST) 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: <20150713230811.3D5C51A1DD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 13 Jul 2015 23:08:17 -0000 Viktor Dukhovni wrote: > Andrei Popov wrote: >> >> Would it make sense for an opportunistic client to advertise all algorithms >> commonly supported in the server certs? After all, there are relatively >> few signature/hash pairs in use, and they are changing very slowly over >> time. > > This does not work when new algorithms are introduced, since you > can't advertise algorithms you don't know exist. Pretty much *ALL* TLS implementations in the installed base implement TLSv1.1 _and_ do the right thing when negotiating a server certificate for a client that proposes at most TLSv1.1. So if the TLSv1.2 server certificate selection fails, just do the TLSv1.1 server certificate selection. It is really that easy, and produces a very backwards-compatible behaviour that will be highly appreciated by all TLS client, users and helpdesks. -Martin From nobody Mon Jul 13 19:47:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CAD1A89F5 for ; Mon, 13 Jul 2015 19:47:15 -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 drcmx4VTVN3U for ; Mon, 13 Jul 2015 19:47:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31EC1A89F1 for ; Mon, 13 Jul 2015 19:47:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1B16D284D75; Tue, 14 Jul 2015 02:47:11 +0000 (UTC) Date: Tue, 14 Jul 2015 02:47:11 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150714024710.GR28047@mournblade.imrryr.org> References: <201507111709.27725.davemgarrett@gmail.com> <201507111929.02696.davemgarrett@gmail.com> <20150713044104.GK28047@mournblade.imrryr.org> <20150713180153.GO28047@mournblade.imrryr.org> <20150713220819.GQ28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Tue, 14 Jul 2015 02:47:15 -0000 On Mon, Jul 13, 2015 at 10:31:16PM +0000, Andrei Popov wrote: > When old algorithms are deprecated and new algorithms replace them in > actual deployments (a very slow process), an opportunistic client would > need to be updated, just like a normal server-authenticating client does. > Except for the opportunistic client this update would be rather trivial. > > Alternatively, can an opportunistic client explicitly negotiate anonymous connections? Postfix tries to, as hard as it can, but many servers do not offer anon_DH cipher suites, and under-informed auditors give system administrators a hard time when they are offered. Furthermore, DANE-EE(3) clients and certificate pinning clients cannot use anon_DH, they still a recognizable certificate from the server, they just often don't need a recognizable signature. Even DANE-TA(2) clients might be able to stop part-way up the chain before the objectionable signature appears. -- Viktor. From nobody Mon Jul 13 21:38:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD81A005A for ; Mon, 13 Jul 2015 21:38:55 -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 L-ug21gGFaqw for ; Mon, 13 Jul 2015 21:38:54 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F71E1A0045 for ; Mon, 13 Jul 2015 21:38:54 -0700 (PDT) Received: by qgep37 with SMTP id p37so74616265qge.1 for ; Mon, 13 Jul 2015 21:38:53 -0700 (PDT) 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=LQbaJ9eHlHq+Ah7s+wT7cDeB+xYJdRh9AESGLXfnd24=; b=zT+VykMTDKbZANxaBqhKh3otZ73EtG84nmNUghlj1Jw92FS2JQoaWwr0B2T2ad4RZR Y1i5+29pQ24Y6PiNEeQjiHpukpWa7NAatZSLvFQ159RjCDdXB2BsCxsA25z9Kk8p3Www Utc4omHERVoLoJfIfBZCXtUEtZwWU1F8/btqmUBABIfqwxlZ6kQeBl3hus+kp0k4x/Qt 9gWx0vpQgDZSxdTuClHDy5c2VG5qhxekiD3ll3L17GJYGfyiB35BACzGrhawtDS0bgwl u7NPploSGV6WG9YntPS91GRmhhK3MXsZqaT51+2fafhfYAxtpFT+ZyCQvMFt/V8pE+wE R6Yg== X-Received: by 10.141.23.143 with SMTP id z137mr21737652qhd.46.1436848733502; Mon, 13 Jul 2015 21:38:53 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 18sm12182899qgh.40.2015.07.13.21.38.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Jul 2015 21:38:52 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Tue, 14 Jul 2015 00:38:51 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507111709.27725.davemgarrett@gmail.com> <20150714024710.GR28047@mournblade.imrryr.org> In-Reply-To: <20150714024710.GR28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507140038.51345.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: [TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 for signatures in 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, 14 Jul 2015 04:38:55 -0000 On Monday, July 13, 2015 10:47:11 pm Viktor Dukhovni wrote: > Furthermore, DANE-EE(3) clients and certificate pinning clients > cannot use anon_DH, they still a recognizable certificate from the > server, they just often don't need a recognizable signature. Even > DANE-TA(2) clients might be able to stop part-way up the chain > before the objectionable signature appears. Generic open-ended question: Is there anything else with regard to getting DANE working more smoothly that needs addressing? The current CA-based system generally sucks, and whilst not everyone agrees that DANE is currently the ideal alternative, fixing issues inhibiting it could improve things here. It really would be nice if TLS 1.3 was as DANE-friendly as possible so we can start getting support built into more clients and be less reliant on the current mess. Dave From nobody Mon Jul 13 22:22:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9E1A0125 for ; Mon, 13 Jul 2015 22:22:32 -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 ojDkdH03TLWC for ; Mon, 13 Jul 2015 22:22:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC87D1A0122 for ; Mon, 13 Jul 2015 22:22:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3BB3F284D74; Tue, 14 Jul 2015 05:22:29 +0000 (UTC) Date: Tue, 14 Jul 2015 05:22:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150714052228.GT28047@mournblade.imrryr.org> References: <201507111709.27725.davemgarrett@gmail.com> <20150714024710.GR28047@mournblade.imrryr.org> <201507140038.51345.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507140038.51345.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 for signatures in TLS 1.3) 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: Tue, 14 Jul 2015 05:22:32 -0000 On Tue, Jul 14, 2015 at 12:38:51AM -0400, Dave Garrett wrote: > > Furthermore, DANE-EE(3) clients and certificate pinning clients > > cannot use anon_DH, they still a recognizable certificate from the > > server, they just often don't need a recognizable signature. Even > > DANE-TA(2) clients might be able to stop part-way up the chain > > before the objectionable signature appears. > > Generic open-ended question: Is there anything else with regard to getting > DANE working more smoothly that needs addressing? >From a TLS standards perspective, we're in reasonably good shape. The main remaining friction point is server software that is incapable of including self-signed root CAs in the server's wire certificate chain. With DANE-TA(2), the trust-anchor certificate MUST be in the server's certificate message (wire chain) even if it is a self-signed "root". So if a site wants to designate a self-signed DANE trust anchor, it must find a way to include it in server chains. This is not a protocol problem as such. Rather, the fact that the specification says that server MAY omit root CA certs with a "traditional" X.509 PKI means that some software stacks provide no means for the server administrator to force inclusion. With TLS 1.3, perhaps updated text could reference the imminent RFC 6698 update (draft-ietf-dane-ops, scheduled for the IESG telechat on Aug 6th) and mention that a mechanism needs to exist for servers to request inclusion of root trust anchor certificates (when the library constructs the chain on the fly by augmenting the application provided leaf certificate with the requisite intermediate CA certs, but at present by default leaves out the root CA cert). In addition, with DANE-EE(3) TLS libraries are expected to accept end-entity certificates that are expired or bear the wrong server name, provided the certificate or enclosed public key matches the TLSA record. Thus (again not a protocol issue), it would be nice if TLS libraries did not get in the way of that, but presumably this gets fixed when the library adds DANE support. Speaking of DANE support in libraries, there are as yet no mainstream libraries that offer correct and complete DANE support. I expect to remediate this for one or two open source libraries. Last I looked GnuTLS DANE support was rather incomplete, "ldns" was insecure and libval was fragile. Neither OpenSSL nor mTLS (aka PolarSSL) at present support DANE. In general don't trust DANE "addons" that are not core parts of the underlying TLS library, this is very difficult to get right. DANE support needs to be "baked in" as part of the core chain construction and validation logic of the TLS library. The application can provide the validated TLSA RRset, the TLSA base domain and zero or more additional reference identifiers (with DANE there can be multiple valid hostnames for the server end of a client's TLS connection), and the library should then do the rest. I'd like to see DANE support in the not too distant future in at least: * OpenSSL * mTLS * GnuTLS * NSS * Schannel * Java -- Viktor. From nobody Tue Jul 14 01:34:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72061A909D for ; Tue, 14 Jul 2015 01:34:42 -0700 (PDT) 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 5B93oeqyxK2S for ; Tue, 14 Jul 2015 01:34:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72B01A9094 for ; Tue, 14 Jul 2015 01:34:41 -0700 (PDT) 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 (Postfix) with ESMTPS id C1F1536506A; Tue, 14 Jul 2015 08:34:40 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-73.ams2.redhat.com [10.36.112.73]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6E8YZXf030554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2015 04:34:40 -0400 From: Hubert Kario To: Simon Josefsson Date: Tue, 14 Jul 2015 10:34:26 +0200 Message-ID: <17744104.AefDTyBEY2@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.6-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <87k2u5samu.fsf@latte.josefsson.org> References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <2960351.rch1apE1uy@pintsize.usersys.redhat.com> <87k2u5samu.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2023122.mchXszdtPV"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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, 14 Jul 2015 08:34:43 -0000 --nextPart2023122.mchXszdtPV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote: > Hubert Kario writes: > > As is described in secion 5.1. of RFC 4492, and then reiterated in > > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_= groups) > > guides both the ECDH curves and curves understandable by peer for E= CDSA > > signatures. > >=20 > > As Curve25519 and Curve448 can only be used for ECDHE, maybe they s= hould > > be > >=20 > > defined/named in the registry as such, to remove any ambiguity[1]: > > enum { > > =20 > > Curve25519_ecdh(TBD1), > > Curve448_ecdh(TBD2), > > =20 > > } NamedCurve; >=20 > I don't care strongly. One disadvantage with this is that if we deci= de > to reuse these NamedCurve allocations to have something to do with > Ed25519, the naming above will be confusing. However, I believe it i= s > already likely that Ed25519 will have its own NamedCurve. Given that there certainly will be implementations that support ecdh an= d not=20 the signatures, we certainly *don't* want to reuse this codepoint for a= nything=20 else. So unless the PKIX and TLS parts are defined at the same time, in the s= ame=20 document, we definitely need to keep them apart. =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2023122.mchXszdtPV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVpMmYAAoJEJKo0bgB0vX1RaoQAJyfujnBw1+WIrCV+LHRC6+e pFIB2N/lEsGojIMVXe43LmlrdGeyjznBHDXNNrwVZZxkVtA/S2g1099q0f/k3Yhd nM5eXznbnivsFWAV9TO3PJM+3hfBZ5JFaHw9nvdEs0jo25OIuJ4oKpYw2Q4bOM/b S+aezLFBOKqO/d8nxeT1cZPe2OKYq9M6Firc6KpBMhXccQR3QZF3dmqSLHuy5nEh pdl9ci6SsBfl1gPQgnYFCyv2gwKywQBZ6PjFHVVQtVlJnygrC+VZZTKqXmhNTOXs WQ1SZ3jybkwxfHWiEvD/RqHiwu7AMsJfyNbUgax2hKXxTsqAkEZbVNeutX93co2J 8iYgXb8icdm/Qjp+yOhTGRQ7g9L+EWj4T7KnCEHDRoTqzCPI6CkgFGKbmDLDFF5W dBDgo0GsOp2oXp1UT9coaxLytPgjH8lg9Gzd5HSCcjX5IP/zGzu4H2COt+rKeTK7 tTjREIbpEkdY3YxM9Sv/8sBBSa8GeFu5Tmv7Q4zPIqzdEYxhnNmx7akauAtFJJKx 6l9IqGRO7cL8GUFLdhaSBOHEHhjdyooEMOmahgvu5HydV3+4TfuBjHjsvRl+xFZn nxh8lPGlAib2asmVga6DMsPvoZgUkPlpxChtYjUoB/rkkvCGqNY//mMjtd/bkz7m 3/ixaLn1dtsZHhAeCGcQ =UxKc -----END PGP SIGNATURE----- --nextPart2023122.mchXszdtPV-- From nobody Tue Jul 14 02:31:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3A1A911D for ; Tue, 14 Jul 2015 02:31:41 -0700 (PDT) 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 yvW9GOHssShz for ; Tue, 14 Jul 2015 02:31:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D8F1A9114 for ; Tue, 14 Jul 2015 02:31:39 -0700 (PDT) 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 (Postfix) with ESMTPS id 63D8C3187C2; Tue, 14 Jul 2015 09:31:39 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-73.ams2.redhat.com [10.36.112.73]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6E9VYc0000849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2015 05:31:38 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 14 Jul 2015 11:31:26 +0200 Message-ID: <1649068.52kEfPtajD@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.6-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <201507111709.27725.davemgarrett@gmail.com> References: <20150711204810.GU28047@mournblade.imrryr.org> <201507111709.27725.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1606914.3tkUhEPGc1"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2015 09:31:41 -0000 --nextPart1606914.3tkUhEPGc1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 11 July 2015 17:09:27 Dave Garrett wrote: > On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote: > > Largely close enough. Feel free to borrow any text from the below > > that you find to be an improvement. > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =20 > > Whenever possible, all certificates provided by the server > > SHOULD be signed by a hash/signature algorithm pair indicated > > by the client's supported algorithms extension (or the defaults= > > assumed in its absence). If the server cannot produce a > > certificate chain that is signed via only the indicated support= ed > > pairs, then it SHOULD continue the handshake by sending the > > client a certificate chain of its choice that may include > > hash/signature algoriths that are not known to be supported by > > the client. > > =20 > > The public key in the leaf certificate must of course be > > compatible with the chosen cipher-suite, and the subsequent > > ServerKeyExchange message must be signed via a mutually support= ed > > hash/signature algorithm pair. > > =20 > > If the client cannot construct a satisfactory chain using the > > provided certificates and decides to abort the handshake, then > > it MUST send an "unsupported_certificate" alert message and > > close the connection. > > =20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The middle bit is already in existing text above the section in quest= ion. >=20 > New version with a little rewording and a typo fix. >=20 > \/ >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > All certificates provided by the server SHOULD be signed by a > hash/signature algorithm pair indicated by the client's > "signature_algorithms" extension (or the defaults assumed in > its absence), where possible. If the server cannot produce a > certificate chain that is signed only via the indicated supported > pairs, then it SHOULD continue the handshake by sending the > client a certificate chain of its choice that may include algorithms > that are not known to be supported by the client. If the client > cannot construct an acceptable chain using the provided certificates > and decides to abort the handshake, then it MUST send an > "unsupported_certificate" alert message and close the connection. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What about the cert chain offered by client to server as a response to=20= Certificate Request message? They are also under the limitation of using just the signature algorith= ms=20 advertised as supported by server. =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1606914.3tkUhEPGc1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVpNb0AAoJEJKo0bgB0vX19sgP/0xTZm2kGViim9fqCwyi9Cke E+6+lXXDoNrRYKgnxcG97xh3nhUVzKYNID92aHI5x3zn6Ah7uu2vZkp+SYj87dXP zeFRpDWm+Rt1N58SyhnAunlhKBbrv42NgXAtGaU1JUf6BNNZAF/HN/vW4mVCuwB/ NzyGTCRJLjD5snSdtWQcPOblLa0VqmTvJadCTzFah+A3VbieL+jVdu1T6ER78lAU fc8oIf91k5moslRlaVI2aoBfW1JPa92CYt/vnSitjI3f+9yQ0Oks2acmSvDE8/z8 +JtnHYiGJ12cUbzzoHyKl4EcgqKf3lEPJaWTHttZBSIuYOi9m+M2lzIUhaYPTdgb 9JNC/us2iw2/kX1+Rom+RlGseiQxzIeHGg9ithA/6pU04atlq/Tb+V7HOXenj1CH tYyonaaXKcpKh7oB1NlDYwqSd5IOLH31rkJgezpxFilQIzCxJbu0FX7tS/1SwKdw o9OnvktY4PPd7qwrzbGoNU8dzQCqnQ9zMFQk3G/k4Cms1X27d1IJ3nnythlUzGCL WM/+03adTiOqhB2vsvvyI5h/PEbMrHhFiYyncTCvD99/l+7a3jz6dh2jXlkQLIDO dGJVv2l1krYb+D+Fod1KSWHN/p0G3jpZN6DQFyP33UHBHskrdHvSlMAB1EQpxvc3 SrQWHbjUmwBZauOG+l8e =kjGl -----END PGP SIGNATURE----- --nextPart1606914.3tkUhEPGc1-- From nobody Tue Jul 14 06:46:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C491ACD38 for ; Tue, 14 Jul 2015 06:46:17 -0700 (PDT) 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 btr09TfOTFKk for ; Tue, 14 Jul 2015 06:46:15 -0700 (PDT) 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 DAB951ACD33 for ; Tue, 14 Jul 2015 06:46:14 -0700 (PDT) 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 126872A97C for ; Tue, 14 Jul 2015 15:46:13 +0200 (CEST) X-purgate-ID: 152705::1436881573-0000413A-E2D81077/0/0 X-purgate-size: 2231 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 0727D406DF for ; Tue, 14 Jul 2015 15:46:13 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id F2DFF1A1DE; Tue, 14 Jul 2015 15:46:12 +0200 (CEST) In-Reply-To: <20150714024710.GR28047@mournblade.imrryr.org> To: tls@ietf.org Date: Tue, 14 Jul 2015 15:46:12 +0200 (CEST) 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: <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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, 14 Jul 2015 13:46:17 -0000 Viktor Dukhovni wrote: > Andrei Popov wrote: >> >> When old algorithms are deprecated and new algorithms replace them in >> actual deployments (a very slow process), an opportunistic client would >> need to be updated, just like a normal server-authenticating client does. >> Except for the opportunistic client this update would be rather trivial. >> >> Alternatively, can an opportunistic client explicitly negotiate >> anonymous connections? > > Postfix tries to, as hard as it can, but many servers do not offer > anon_DH cipher suites, and under-informed auditors give system > administrators a hard time when they are offered. anon_DH cipher suites are a true security problem, in particular with clients that perform server endpoint identification as a mere side-effect of processing the server's TLS Certificate handshake message (such as through a callback) rather than as a mandatory verification step at the end of a successful TLS handshake. Anonymous cipher suites are regularly not just "not offered by servers", they might not even be implemented in the server's TLS implementation. We don't support them, and I didn't notice any such cipher suites on these lists, either: https://msdn.microsoft.com/library/aa374757.aspx https://support.microsoft.com/en-us/kb/2929781 https://technet.microsoft.com/en-us/library/dn786419.aspx Btw., anonymous TLS ciphersuites have been officially deprecated already in TLSv1.0 (rfc2246) in 1999, several years before deprecation of the export-crypto cipher suites: https://tools.ietf.org/html/rfc2246#page-55 The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated. CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; -Martin From nobody Tue Jul 14 08:23:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA211ACEE0 for ; Tue, 14 Jul 2015 08:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 zs6bCSwHD0C0 for ; Tue, 14 Jul 2015 08:23:55 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 22B091ACEED for ; Tue, 14 Jul 2015 08:23:49 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6EFNjKw007267 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 14 Jul 2015 17:23:46 +0200 From: Simon Josefsson To: Hubert Kario References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <2960351.rch1apE1uy@pintsize.usersys.redhat.com> <87k2u5samu.fsf@latte.josefsson.org> <17744104.AefDTyBEY2@pintsize.usersys.redhat.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150714:tls@ietf.org::ZJyuhKyrEo4wGEoQ:1xlq X-Hashcash: 1:22:150714:hkario@redhat.com::oHTXsTSxjeLh9YkG:Bkom Date: Tue, 14 Jul 2015 17:23:44 +0200 In-Reply-To: <17744104.AefDTyBEY2@pintsize.usersys.redhat.com> (Hubert Kario's message of "Tue, 14 Jul 2015 10:34:26 +0200") Message-ID: <878uairce7.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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, 14 Jul 2015 15:23:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hubert Kario writes: > On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote: >> Hubert Kario writes: >> > As is described in secion 5.1. of RFC 4492, and then reiterated in >> > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_gro= ups) >> > guides both the ECDH curves and curves understandable by peer for ECDSA >> > signatures. >> >=20 >> > As Curve25519 and Curve448 can only be used for ECDHE, maybe they shou= ld >> > be >> >=20 >> > defined/named in the registry as such, to remove any ambiguity[1]: >> > enum { >> >=20=20=20=20=20=20=20=20=20=20 >> > Curve25519_ecdh(TBD1), >> > Curve448_ecdh(TBD2), >> >=20=20=20=20=20=20=20=20=20=20 >> > } NamedCurve; >>=20 >> I don't care strongly. One disadvantage with this is that if we decide >> to reuse these NamedCurve allocations to have something to do with >> Ed25519, the naming above will be confusing. However, I believe it is >> already likely that Ed25519 will have its own NamedCurve. > > Given that there certainly will be implementations that support ecdh > and not the signatures, we certainly *don't* want to reuse this > codepoint for anything else. > > So unless the PKIX and TLS parts are defined at the same time, in the sam= e=20 > document, we definitely need to keep them apart. It is conceivable to reuse the NamedCurve values for TLS authentication without affecting the ECHDE use, nor delaying the Curve25519 ECDHE work. Compare how we "reuse" the ECDHE ciphersuite values to refer to Curve25519 (instead of defining new ciphersuites for Curve25519), and how we are "reusing" the "uncompressed" code point to refer to Curve25519-compressed code points (instead of defining new ECPointFormat). Allocating new values when that creates additional costs and no improved clarity seems wasteful to me. This approach is what people have suggested for most other allocations here, so I prefer to stick to that philosophy unless it is clear that there is consensus for something else. What do others think? /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVpSmAAAoJEIYLf7sy+BGdU5IIAJR/ZiFPK7tHiMPJPy2pt35q 4r9WaZjTxDDt5xqwtIHWjEmYsTIIl+DxJs45VU2Nx86AIWWw7EdP1MizEouZMjvJ Jvsrxbi0M5YDXWJ8R5VpGSVitrcDVXr3KKlJ0lL9MpsXM9zVt/olZESILtIdvpUr QWLENQn/5BBjxPMrxRZDXc6Ui9k/yzTJYYM9elp04r9/QMrZPRoeN4UUmg/RKL3J ca3ZxLbSEGLJu93vTKgaGEGu5PGKha099OHXA43ubtsYZ4I3Qv+XMKn+/3d4ME9a PlxpWElit1EapaJ1C0YBz7Sr4wreCsWNSeXV6h5GCEGhPlLxX2siXWkyJ1uDDzk= =ZkOM -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 14 08:38:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE2B1A1A31 for ; Tue, 14 Jul 2015 08:38:53 -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 gbPd4fhe-gYl for ; Tue, 14 Jul 2015 08:38:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0971A1A25 for ; Tue, 14 Jul 2015 08:38:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 387B3284D74; Tue, 14 Jul 2015 15:38:51 +0000 (UTC) Date: Tue, 14 Jul 2015 15:38:51 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150714153850.GU28047@mournblade.imrryr.org> References: <20150711204810.GU28047@mournblade.imrryr.org> <201507111709.27725.davemgarrett@gmail.com> <1649068.52kEfPtajD@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1649068.52kEfPtajD@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Tue, 14 Jul 2015 15:38:53 -0000 On Tue, Jul 14, 2015 at 11:31:26AM +0200, Hubert Kario wrote: > > ======================================== > > All certificates provided by the server SHOULD be signed by a > > hash/signature algorithm pair indicated by the client's > > "signature_algorithms" extension (or the defaults assumed in > > its absence), where possible. If the server cannot produce a > > certificate chain that is signed only via the indicated supported > > pairs, then it SHOULD continue the handshake by sending the > > client a certificate chain of its choice that may include algorithms > > that are not known to be supported by the client. If the client > > cannot construct an acceptable chain using the provided certificates > > and decides to abort the handshake, then it MUST send an > > "unsupported_certificate" alert message and close the connection. > > ======================================== > > What about the cert chain offered by client to server as a response to > Certificate Request message? > > They are also under the limitation of using just the signature algorithms > advertised as supported by server. Exactly the same strategy should apply when client certificates are in use, send compatible if possible, else send something you have. -- Viktor. From nobody Tue Jul 14 09:55:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F1B1A0146 for ; Tue, 14 Jul 2015 09:55:51 -0700 (PDT) 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 DDaFRskZVfwW for ; Tue, 14 Jul 2015 09:55:50 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F191A011F for ; Tue, 14 Jul 2015 09:55:50 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id D1FAF900B2; Tue, 14 Jul 2015 19:55:47 +0300 (EEST) Date: Tue, 14 Jul 2015 19:55:47 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150714165547.GB1094@LK-Perkele-VII> References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <2960351.rch1apE1uy@pintsize.usersys.redhat.com> <87k2u5samu.fsf@latte.josefsson.org> <17744104.AefDTyBEY2@pintsize.usersys.redhat.com> <878uairce7.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <878uairce7.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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, 14 Jul 2015 16:55:52 -0000 On Tue, Jul 14, 2015 at 05:23:44PM +0200, Simon Josefsson wrote: > Hubert Kario writes: > > > So unless the PKIX and TLS parts are defined at the same time, in the same > > document, we definitely need to keep them apart. > > It is conceivable to reuse the NamedCurve values for TLS authentication > without affecting the ECHDE use, nor delaying the Curve25519 ECDHE work. > > Compare how we "reuse" the ECDHE ciphersuite values to refer to > Curve25519 (instead of defining new ciphersuites for Curve25519), and > how we are "reusing" the "uncompressed" code point to refer to > Curve25519-compressed code points (instead of defining new > ECPointFormat). Well, allowing curve to set point format isn't much of a stretch (and in fact, TLS 1.3 as of currently requires this). If one does only "uncompressed" format, all current ECDHE curves work as a triple: - Keybytes: How many bytes of private key it wants. - Generate: Take in private key, output public key. - Agree: Take in private key and peer public key, output premaster secret (or ES/SS in TLS 1.3). (Instantiating that for both uncompressed NIST P-256 and Curve25519 is left as an simple excercise). > Allocating new values when that creates additional costs and no improved > clarity seems wasteful to me. This approach is what people have > suggested for most other allocations here, so I prefer to stick to that > philosophy unless it is clear that there is consensus for something > else. What do others think? Well, that would imply that implementation that supports Curve25519 and/ or Curve448 sigs has to also do ECDHE with exactly those curves. And conversely, anything that does both Curve25519 and Curve448 ECDHE and does signatures with either has to do signatures with both. In implementation, signatures are quite a bit more complicated than ECDHE. -Ilari From nobody Tue Jul 14 12:16:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9821ACE00 for ; Tue, 14 Jul 2015 12:16:15 -0700 (PDT) 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_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=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 XvXC-s_ji5o9 for ; Tue, 14 Jul 2015 12:16:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E7F1B2A28 for ; Tue, 14 Jul 2015 12:16:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5E529284D74; Tue, 14 Jul 2015 19:16:13 +0000 (UTC) Date: Tue, 14 Jul 2015 19:16:13 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150714191613.GC28047@mournblade.imrryr.org> References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Tue, 14 Jul 2015 19:16:16 -0000 On Tue, Jul 14, 2015 at 03:46:12PM +0200, Martin Rex wrote: [ There's no need to belabour the obvious, yes unauthenticated TLS does not protect against active attacks, absent authenticated channel binding post handshake. This does not mean that the are no appropriate use-cases for anon_DH and anon_ECDH. ] > https://tools.ietf.org/html/rfc2246#page-55 > > The following cipher suites are used for completely anonymous > Diffie-Hellman communications in which neither party is > authenticated. Note that this mode is vulnerable to man-in-the-middle > attacks and is therefore deprecated. > > CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; > CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; > CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; > CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; > CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; Which still leaves us with (sorry about the OpenSSL-specific names): AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 AECDH-AES128-SHA SSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 As for "ADH" and "AECDH" being "insecure", that rather depends on the threat model, and presumption of lack of channel binding. For opportunistic TLS in SMTP, the threat model does not include active attacks. Active attackers can in any case suppress "STARTTLS", use some random certificate (the client performs no authentication anyway), ... Denying the client anon TLS is pointless, and loses audit information on the server side. https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3 https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-8.2 If the recently proposed changes to cipher suite negotiation bear fruit, perhaps there'll some day again be a reasonably complete/current set of anon_ECDH ciphers to work with. -- Viktor. From nobody Tue Jul 14 12:30:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3096C1B2AE3 for ; Tue, 14 Jul 2015 12:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 VT6TzznozRUg for ; Tue, 14 Jul 2015 12:30:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.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 39ABE1B2ADE for ; Tue, 14 Jul 2015 12:30:39 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.213.14; Tue, 14 Jul 2015 19:30:37 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0213.000; Tue, 14 Jul 2015 19:30:38 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpCAAUrngIAADsEAgAAC7oCAABbWgIAANnyAgAAH4ACAAAoZgIAAB+GAgAAMDwCAAAXygIAAI+yAgAADFACAAd8BsIAACoIAgADHX/CAABhggIAAFePggAAu+ACAAADfAIAATQqAgAC4IQCAAFw0gIAAAPZA Date: Tue, 14 Jul 2015 19:30:38 +0000 Message-ID: References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> In-Reply-To: <20150714191613.GC28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:8ZPDYsTKXwkcckr5qnVVX1CkMgmHICgfH+vq5pS4sOF55X5AOfILHOZ2Y5V7OcQLXodYIKPitBvCDeOv3XrOJSA6HtpsI/NjpcRTIMiIR3fkjIXv+XgVPg4a8ijvkwUQr3zeoHtB0NGO2QxDOnt5Gw==; 24:8W8UmwrrPIAnXSBxRG07GAbE7cGbppD2VGZMQ0HtcGbufC/j3eCcAaUKNdISgmt/8BXu5SdfAV4zwAtdcjWP7lW7s+PTMZbKPV/HQ6YB9L0=; 20:O6ooDZqmTgzyz1EcieAHPU0jWdL0oa627B0CexKGrduNa8XTShVuN+4zNuY6ZovQGk0UHvPA7OFGlDdhXrixyw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; blupr03mb1394: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(24454002)(377454003)(50986999)(19580395003)(106116001)(76176999)(19580405001)(86612001)(54356999)(86362001)(46102003)(87936001)(2656002)(2351001)(76576001)(77156002)(74316001)(5001960100002)(110136002)(122556002)(107886002)(2900100001)(40100003)(99286002)(5003600100002)(2501003)(2950100001)(15975445007)(5002640100001)(62966003)(33656002)(102836002)(77096005)(450100001)(92566002)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2015 19:30:38.1264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2015 19:30:41 -0000 Using anonymous cipher suites for opportunistic connections allows the serv= er operator to explicitly enable anonymous connections, and it saves bytes = on the wire. The downside is of course that the attacker can easily distinguish opportun= istic clients from server-authenticating ones. Is this a concern for the op= portunistic TLS community? -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, July 14, 2015 12:16 PM To: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.= 3 draft-07 sneak peek) On Tue, Jul 14, 2015 at 03:46:12PM +0200, Martin Rex wrote: [ There's no need to belabour the obvious, yes unauthenticated TLS does not protect against active attacks, absent authenticated channel binding post handshake. This does not mean that the are no appropriate use-cases for anon_DH and anon_ECDH. ] > https://tools.ietf.org/html/rfc2246#page-55 >=20 > The following cipher suites are used for completely anonymous > Diffie-Hellman communications in which neither party is > authenticated. Note that this mode is vulnerable to man-in-the-middle > attacks and is therefore deprecated. >=20 > CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 =3D { 0x00,0x17 }; > CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 =3D { 0x00,0x18 }; > CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA =3D { 0x00,0x19 }; > CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA =3D { 0x00,0x1A }; > CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA =3D { 0x00,0x1B }; Which still leaves us with (sorry about the OpenSSL-specific names): AECDH-AES256-SHA SSLv3 Kx=3DECDH Au=3DNone Enc=3DAES(256) M= ac=3DSHA1 ADH-AES256-GCM-SHA384 TLSv1.2 Kx=3DDH Au=3DNone Enc=3DAESGCM(256)= Mac=3DAEAD ADH-AES256-SHA256 TLSv1.2 Kx=3DDH Au=3DNone Enc=3DAES(256) M= ac=3DSHA256 ADH-AES256-SHA SSLv3 Kx=3DDH Au=3DNone Enc=3DAES(256) M= ac=3DSHA1 ADH-CAMELLIA256-SHA SSLv3 Kx=3DDH Au=3DNone Enc=3DCamellia(25= 6) Mac=3DSHA1 AECDH-AES128-SHA SSLv3 Kx=3DECDH Au=3DNone Enc=3DAES(128) M= ac=3DSHA1 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=3DDH Au=3DNone Enc=3DAESGCM(128)= Mac=3DAEAD ADH-AES128-SHA256 TLSv1.2 Kx=3DDH Au=3DNone Enc=3DAES(128) M= ac=3DSHA256 ADH-AES128-SHA SSLv3 Kx=3DDH Au=3DNone Enc=3DAES(128) M= ac=3DSHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=3DDH Au=3DNone Enc=3DCamellia(12= 8) Mac=3DSHA1 AECDH-RC4-SHA SSLv3 Kx=3DECDH Au=3DNone Enc=3DRC4(128) M= ac=3DSHA1 As for "ADH" and "AECDH" being "insecure", that rather depends on the threa= t model, and presumption of lack of channel binding. For opportunistic TLS in SMTP, the threat model does not include active att= acks. Active attackers can in any case suppress "STARTTLS", use some rando= m certificate (the client performs no authentication anyway), ... Denying t= he client anon TLS is pointless, and loses audit information on the server = side. https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1= .3 https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-8= .2 If the recently proposed changes to cipher suite negotiation bear fruit, pe= rhaps there'll some day again be a reasonably complete/current set of anon_= ECDH ciphers to work with. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 14 12:55:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4131B2BCA for ; Tue, 14 Jul 2015 12:55: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 ebA8sr0wbUFy for ; Tue, 14 Jul 2015 12:55:53 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC101B2BC7 for ; Tue, 14 Jul 2015 12:55:53 -0700 (PDT) Received: by ykax123 with SMTP id x123so17917059yka.1 for ; Tue, 14 Jul 2015 12:55:52 -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=CJVEily5oKfGaGm3jo4j0LziiqukOM/IJ8q69CtIWTk=; b=NBwj74DiElzmq/d9wrjT1SyNsB0BqhpgcRbHPaCCu8aCBfowxS0ipiFdaY9WnY/CcM GJ4550qGZtA0gr1kH4TYmYzjY/j7GbQOcMRw0EUG2Va8MBvNGqiVIZKkJiFcWG/frkpJ H/pVoGbL+WSgz2yxSYPC4zKof/TpSIqaHHKoSI2bhEl/+Ta72NDShUarLc+7PsWwjJTe obVuqTk8M8jAkzmkpXiGFx1N5loxrYzG2ef+8cK39v65YRo5jaueL84ZDc6uTDDpOLOk hBH08zZuA7nAtGJHK11hiFRu2P+Bt8B4i6MPPvjJlV5fGwoE91WsWt19ZOkYfTHmA4Ue 6PFA== MIME-Version: 1.0 X-Received: by 10.129.97.5 with SMTP id v5mr491902ywb.56.1436903752671; Tue, 14 Jul 2015 12:55:52 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 14 Jul 2015 12:55:52 -0700 (PDT) In-Reply-To: References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> Date: Tue, 14 Jul 2015 12:55:52 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2015 19:55:54 -0000 On 14 July 2015 at 12:30, Andrei Popov wrote: > The downside is of course that the attacker can easily distinguish opportunistic clients from server-authenticating ones. Is this a concern for the opportunistic TLS community? I raised the concern about this previously. Opportunistic MitM happens, and providing a strong signal that the connection won't be (or couldn't be) authenticated somehow is a problem for that. I'd rather have opportunistic security be indistinguishable from "real" security. It also means that you don't have separate code paths to support. The anonymous modes serve a different purpose. For instance tcpinc could use them. From nobody Tue Jul 14 13:06:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2809F1B2C26 for ; Tue, 14 Jul 2015 13:06:23 -0700 (PDT) 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, 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 Xcqg70049XFo for ; Tue, 14 Jul 2015 13:06:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F281B2C27 for ; Tue, 14 Jul 2015 13:06:20 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.213.14; Tue, 14 Jul 2015 20:06:19 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0213.000; Tue, 14 Jul 2015 20:06:19 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpCAAUrngIAADsEAgAAC7oCAABbWgIAANnyAgAAH4ACAAAoZgIAAB+GAgAAMDwCAAAXygIAAI+yAgAADFACAAd8BsIAACoIAgADHX/CAABhggIAAFePggAAu+ACAAADfAIAATQqAgAC4IQCAAFw0gIAAAPZAgAAKHgCAAAEsIA== Date: Tue, 14 Jul 2015 20:06:19 +0000 Message-ID: References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:wgIc9XRPbuvRyPZlVDB2dhm4MeheeguJiCmb5dMlN6meSR6Mq6ieoeqv4h6tJ3teXBwJnqOa1l8G8g81xF5IT/kZiPUWJ43ssMb5vR1B7BdDeOzc/D/K43UKXR2eaZ8Wrg5YW0BRbqsHZt6OKxrzhQ==; 24:v0Y67HSjZzIpsZCxKRf5OKVfqZe1pGFypGyRbubfzHbCRZB3zHYsPLyKbM+IkuZRacvXl8eyGpjVGL2G+FaIDwPV4PgPW9yVMljZy116oEQ=; 20:O/DRypkINisWsWefO/Op97sQqQEqhWHaYZlALcg7RhEhKjMg/dWGxwdTI2NWnKES4Ksv/RFSLOfq025fs2XVUw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; blupr03mb1395: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(76576001)(2950100001)(50986999)(87936001)(5001960100002)(2656002)(189998001)(74316001)(110136002)(33656002)(77156002)(2900100001)(93886004)(99286002)(46102003)(62966003)(40100003)(5002640100001)(122556002)(86362001)(106116001)(19580405001)(102836002)(76176999)(5003600100002)(86612001)(19580395003)(54356999)(92566002)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2015 20:06:19.2741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2015 20:06:23 -0000 SWYgb3Bwb3J0dW5pc3RpYyBUTFMgaGFuZHNoYWtlcyBuZWVkIHRvIGJlIGluZGlzdGluZ3Vpc2hh YmxlIGZyb20gc2VydmVyLWF1dGhlbnRpY2F0ZWQgVExTIGhhbmRzaGFrZXMsIHRoZW4gcGVyaGFw cyBvcHBvcnR1bmlzdGljIGNsaWVudHMgaGF2ZSBubyBjaG9pY2UgYnV0IHRvIHNlbmQgdGhlIHNp Z25hdHVyZV9hbGdvcml0aG1zIGV4dGVuc2lvbiAod2hlbiBvZmZlcmluZyBUTFMxLjIpLiBUaGUg YWJzZW5jZSBvZiBzaWduYXR1cmVfYWxnb3JpdGhtcyBpbiBhIFRMUyAxLjIgQ2xpZW50SGVsbG8g Y2FuIGJlIHVzZWQgYXMgYSBzaWduYWwgYnkgdGhlIE1JVE0uDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE0LCAyMDE1IDEyOjU2IFBNDQpUbzogQW5k cmVpIFBvcG92DQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gRGVwcmVjYXRl IFNIQTEgZm9yIHNpZ25hdHVyZXMgaW4gVExTIDEuMyAod2FzIFJlOiBUTFMgMS4zIGRyYWZ0LTA3 IHNuZWFrIHBlZWspDQoNCk9uIDE0IEp1bHkgMjAxNSBhdCAxMjozMCwgQW5kcmVpIFBvcG92IDxB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IFRoZSBkb3duc2lkZSBpcyBvZiBj b3Vyc2UgdGhhdCB0aGUgYXR0YWNrZXIgY2FuIGVhc2lseSBkaXN0aW5ndWlzaCBvcHBvcnR1bmlz dGljIGNsaWVudHMgZnJvbSBzZXJ2ZXItYXV0aGVudGljYXRpbmcgb25lcy4gSXMgdGhpcyBhIGNv bmNlcm4gZm9yIHRoZSBvcHBvcnR1bmlzdGljIFRMUyBjb21tdW5pdHk/DQoNCkkgcmFpc2VkIHRo ZSBjb25jZXJuIGFib3V0IHRoaXMgcHJldmlvdXNseS4gIE9wcG9ydHVuaXN0aWMgTWl0TSBoYXBw ZW5zLCBhbmQgcHJvdmlkaW5nIGEgc3Ryb25nIHNpZ25hbCB0aGF0IHRoZSBjb25uZWN0aW9uIHdv bid0IGJlIChvciBjb3VsZG4ndCBiZSkgYXV0aGVudGljYXRlZCBzb21laG93IGlzIGEgcHJvYmxl bSBmb3IgdGhhdC4gIEknZCByYXRoZXIgaGF2ZSBvcHBvcnR1bmlzdGljIHNlY3VyaXR5IGJlIGlu ZGlzdGluZ3Vpc2hhYmxlIGZyb20gInJlYWwiDQpzZWN1cml0eS4gIEl0IGFsc28gbWVhbnMgdGhh dCB5b3UgZG9uJ3QgaGF2ZSBzZXBhcmF0ZSBjb2RlIHBhdGhzIHRvIHN1cHBvcnQuDQoNClRoZSBh bm9ueW1vdXMgbW9kZXMgc2VydmUgYSBkaWZmZXJlbnQgcHVycG9zZS4gIEZvciBpbnN0YW5jZSB0 Y3BpbmMgY291bGQgdXNlIHRoZW0uDQo= From nobody Tue Jul 14 13:09:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1941B2C49 for ; Tue, 14 Jul 2015 13:09:04 -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 5sHIWLalXLLP for ; Tue, 14 Jul 2015 13:09:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0EE51B2C4E for ; Tue, 14 Jul 2015 13:08:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 07004284D74; Tue, 14 Jul 2015 20:08:40 +0000 (UTC) Date: Tue, 14 Jul 2015 20:08:39 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150714200839.GE28047@mournblade.imrryr.org> References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Tue, 14 Jul 2015 20:09:04 -0000 On Tue, Jul 14, 2015 at 07:30:38PM +0000, Andrei Popov wrote: > Using anonymous cipher suites for opportunistic connections allows the > server operator to explicitly enable anonymous connections, and it saves > bytes on the wire. Yes, and informs the server that the client is skipping authentication, which is often useful information on the server end. Is it a common mistake to suggest that servers should disable anon_DH, that advice is appropriate for most clients, but is mostly wrong for servers. Servers might in some cases want to minimize what they present to clients that connect with anon_DH ciphers, but they can't typically do that when they preclude the negotiation of anon_DH. > The downside is of course that the attacker can easily distinguish > opportunistic clients from server-authenticating ones. Is this a concern > for the opportunistic TLS community? A minor concern, but a determined adversary has many ways to figure out which client/server pairs don't involved server certificate checks. -- Viktor. From nobody Tue Jul 14 13:12:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC51B2BF5 for ; Tue, 14 Jul 2015 13:12:26 -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 6XJ24Up3xEGp for ; Tue, 14 Jul 2015 13:12:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939021B2BC8 for ; Tue, 14 Jul 2015 13:11:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BFC62284D74; Tue, 14 Jul 2015 20:11:57 +0000 (UTC) Date: Tue, 14 Jul 2015 20:11:57 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150714201157.GF28047@mournblade.imrryr.org> References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Tue, 14 Jul 2015 20:12:26 -0000 On Tue, Jul 14, 2015 at 08:06:19PM +0000, Andrei Popov wrote: > If opportunistic TLS handshakes need to be indistinguishable from > server-authenticated TLS handshakes, then perhaps opportunistic clients > have no choice but to send the signature_algorithms extension (when offering > TLS1.2). The absence of signature_algorithms in a TLS 1.2 ClientHello can > be used as a signal by the MITM. Nobody is suggesting that opportunistic clients employ the extension in question differently from other clients. The proposal under discussion is about how servers respond when their certificate chain is not unequivocally compatible. Correct server behaviour is to return some sort of chain, and let the client decide. TLS used by opportunistic TLS clients, largely looks the same as TLS used by other clients, except that anon_DH may be offered, which has little bearing on the signature algorithms extension. -- Viktor. From nobody Tue Jul 14 13:49:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4FB1B2CC9 for ; Tue, 14 Jul 2015 13:49:39 -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 bPKwJaSL_GRn for ; Tue, 14 Jul 2015 13:49:38 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B271A8731 for ; Tue, 14 Jul 2015 13:49:37 -0700 (PDT) Received: by ykeo3 with SMTP id o3so19084673yke.0 for ; Tue, 14 Jul 2015 13:49:37 -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 :content-type; bh=UOmCVBTYp8Mpai/yJrldbqrX3hB0EspcMgCiNSLAYUM=; b=Pdz2W58c5xq59sjcWxohQkEg3ou+b8EHnvSCR7ybbfnLfkTqDrTaYZ3xH8FqvOJu6Y PLgwqhvCGCOfta9dAhSoAb8DS7TyvodWeZAErNCoNRuo/CUFR+vdtc3tPYN4qRDaXK6r nUc9OLKI+od+nUVfwCLjr5q3eYP/W6G7kVdoQDjRX+NVIvdr0hDvpZq93rng18NrXtKt D/klC+cYCXyiUJt//wlUqIo7RW3sYemPx32F72cA0UDjaOQBxShy4jjlOOTmVTmy35PK pqYO4MZ9jArFKBJjClENCU0VktGdwPH+VuXpI6+g0jBYimltkPaoW3EdR4k9aaT9matr WRaA== MIME-Version: 1.0 X-Received: by 10.170.73.67 with SMTP id p64mr627486ykp.101.1436906977247; Tue, 14 Jul 2015 13:49:37 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 14 Jul 2015 13:49:36 -0700 (PDT) In-Reply-To: <20150714200839.GE28047@mournblade.imrryr.org> References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> <20150714200839.GE28047@mournblade.imrryr.org> Date: Tue, 14 Jul 2015 13:49:36 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2015 20:49:39 -0000 On 14 July 2015 at 13:08, Viktor Dukhovni wrote: > Yes, and informs the server that the client is skipping authentication, > which is often useful information on the server end. The problem here is that the server isn't the only recipient of that signal. From nobody Tue Jul 14 14:35:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3877D1ACD4F for ; Tue, 14 Jul 2015 14:35:37 -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 MyBjjusRrl7l for ; Tue, 14 Jul 2015 14:35:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06A91B2C59 for ; Tue, 14 Jul 2015 14:35:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9227E284D74; Tue, 14 Jul 2015 21:35:34 +0000 (UTC) Date: Tue, 14 Jul 2015 21:35:34 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150714213534.GG28047@mournblade.imrryr.org> References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> <20150714200839.GE28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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: Tue, 14 Jul 2015 21:35:37 -0000 On Tue, Jul 14, 2015 at 01:49:36PM -0700, Martin Thomson wrote: > On 14 July 2015 at 13:08, Viktor Dukhovni wrote: > > Yes, and informs the server that the client is skipping authentication, > > which is often useful information on the server end. > > The problem here is that the server isn't the only recipient of that signal. You forgot to mention that an on-path MiTM can hide the fact the client is doing it from the server. For clients doing unauthenticated TLS active attacks are not what they are defending against. None of this is news. We should stop here. -- Viktor. From nobody Wed Jul 15 07:15:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A457E1A9253 for ; Wed, 15 Jul 2015 07:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 04Y2u9f4QFvB for ; Wed, 15 Jul 2015 07:15:30 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E741A9172 for ; Wed, 15 Jul 2015 07:15:26 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id A35E81A26D2 for ; Wed, 15 Jul 2015 17:15:23 +0300 (EEST) Date: Wed, 15 Jul 2015 17:15:23 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150715141523.GA13669@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 14:15:38 -0000 Let's review: draft-ietf-tls-tls13-07 This is abridged version of mail I sent earlier, but was too large for the list due to its sheer size. (Note: I omitted some stuff I saw recently discussed (e.g. pruning unused crypto algorithms) or I remember discussed. I didn't explicitly check issue list when doing this). Note: The issue list could use some cleanup. It has multiple duplicate issues (especially about fixing THS) and also some issues that no longer look applicable. > Header Isn't 4346 already obsoleted by 5246, which this document also obsoletes? 4366 seems to be jointly obsoleted by 5246 and 6066. 5246 and 5077 are not in numerical order, whereas the rest are. > 1. (Introduction) DSA should be replaced by ECDSA (DSA is pretty much obsolete)? > 1.2. (Major Differences from TLS 1.2) Is this meant to be changelog or list of changes? It in current form looks more like a changelog. > 4.9.1. (Digital Signing) I think someone wanted randoms back here in order to support privilege separation (which I think is important to support, I consider it much more important than being "HSM friendly")? Reading what current draft of 4492-bis says, the hash function used is determined by signature_algorithms (or presumably the corresponding mechanism in CertificateRequest for client certs). Also, to my knowledge, there is no mechanism to indicate in ECDSA certificate what hash algorithms are allowed. > 4.9.2. (Authenticated Encryption with Additional Data (AEAD)) The example looks like it belongs to section 4.9.1, as it is about signatures, not AEAD construct. > 5. (The TLS Record Protocol) Documenting the security properties of TLS would be useful... The lack of record length hiding may be problematic in protocols that have no place for cover traffic (e.g. can DNS requests contain padding, DPRIVE WG is apparently planning on putting DNS into (D)TLS?). > 5.2.1. (Fragmentation) Zero-length fragments of application data are very much visible in ciphertext (unless record padding is added), so those are not currently useful as traffic analysis countermeasure. > 5.2.2. (Record Payload Protection) There looks to be latter limits that restrict ciphertext size to 2^14 +1024, which is smaller than 2^14+2048 here (but those limits might be tightened further). As for amount of expansion needed for length-hiding, I think that being able to represent 16384-byte record with no padding would be enough (since record sizes cap at 16384 bytes anyway). > 6. (The TLS Handshaking Protocols) Are encryption keys, finished value (tls-unique) and exporter secret part of session or not? > 6.1.1. (Closure Alerts) The semantics of closure alerts seem incompatible with half-closes, which some protocols actually use. > 6.1.2. (Error Alerts) Could use another example of warning alert, now that no_renegotiation is not a warning anymore? > 6.2.1. (Incorrect DHE Share) EncryptedExtensions is marked optional in Figure 2, but not Figure 1? The relationship between session hash and handshake restarts seems like a hairy problem. Also, I figured out a downgrade attack that works against careless _server_ (not requiring client to do anything else than have weak crypto enabled). Continuing hashes looks to block that attack. It involves attacker sending ClientHello with arbitrary parameters that triggers a retry (very easy to trigger a retry), eating the reply, followed by sending client's original ClientHello. That could trigger crypto downgrade in some badly made servers. > 6.2.2. (Cached Server Configuration) Issue #184 manifests here too. I think both accepting and provoding configuration in the same handshake is sensible (key rollover), and later the draft talks about exactly that case. Also, maybe note that provoding the message does not alter the configuration hash (even if there is no existing one) could be useful. > 6.2.3. (Zero-RTT Exchange) No EncryptedExtensions? How would the server know when 0-RTT data ended, so it could send its ServerHello? Also, how is the 0-RTT data bound to session if accepted, or is there a security analysis for leaving this binding out? Can anyone expand on the note about impersonation with compromised server key? I can't offhand figure out how attacker can calculate server-side ES (without having also compromised (possibly former) client or (current) server exchange key). > 6.3. (Handshake Protocol) Missing encrypted_extensions (it is a handshake message, right)? > 6.3.1.1. (Client Hello) The non-match case gives HelloRetryRequest, not ServerHello, right? s/should/SHOULD/ in description of session_id? I don't think client extensions are optional anymore in TLS 1.3 (being required for successful handshake. Also, TLS 1.2 servers that care about security (are there actually any?) already require extensions for successful handshake. > 6.3.1.2. (Server Hello) Well, at least it wouldn't be backward compatiblity hazard to remove session_id_len, since it comes after server version. Note: Unlike client extensions, I think server extensions might be empty in TLS 1.3 handshake (since extensions required for GDHE_CERT type key exchanges are not replied to by server). > 6.3.1.3. (Hello Retry Request) server_version and cipher_suite in HRR seem bit dangerous to me. If HashAlgorithm contained all PRF hashes (currently it does), one could use that to designate PRF hash. Merging DTLS cookies might be a good idea. However, then group mismatch wouldn't be the only source of failure (which needs some text adjustment about the selected_group check). s/use for/add to/ in description of selected_group? What happens if Ciphersuite and NamedGroup don't match between HRR and SH/SKS? I expect there be clients that don't check, no matter if it is MUST or not. Heck, I recently heard of servers that only partially(!!!) check client Finished (or omit the check entierely). > 6.3.1.4. (Hello Extensions) supported_groups is 10, right? Also, for matter of protocol testing, could be useful to give some free values to temporary squat on for extensions that aren't stable yet. The restriction on extensions appearing also holds for EncryptedExtensions, not just SH or HRR. It could also be useful to deprecate some extensions (client MAY send for backwards compat, server MUST NOT select). Some candidates: - truncated_hmac: Block modes have been removed. - encrypt_then_mac: Block modes have been removed. - extended_master_secret: The THS bug is fixed anyway. - sessionticket TLS: Session tickets are deprecated. - renegotiation_info: The renego bug is fixed anyway. The interaction of some extensions with PSK-based resumption isn't that clear. This is further complicated by the fact that PSK can also start a new session. Reference to "error alerts". Should that be "fatal alerts"? The part about being careful with extensions modifying handshake presumably also goes for functions that are sometimes used for authentication like TLS-EXPORTER or TLS-UNIQUE. > 6.3.1.4.1. (Signature Algorithms) Anonymous should be removed. It is apparently not used (there is reference to another section saying that section uses it, but I can't find in that section how it is actually used). Description of signature refers to 6.3,2, which is about SKS, which does not seem to have anything to do with signatures (leftover from TLS 1.2?) Then in description of the extensions there is reference to 6.3.4 and 6.3.2. 6.3.4 looks relevant, 6.3.2. doesn't look so. Also, making signature_algorithms mandatory would allow dropping the backward compatiblity special cases from here. There is text that talks about "offering prior versions". Does that refer to insecure version downgrade (I don't suppose TLS 1.1 maximum client would care about what TLS 1.3 spec says). > 6.3.1.4.2. (Negotiated Groups) One chould add Curve25519 and Curve448, and the corresponding signature groups (signature groups when CFRG signatures become stable). > 6.3.1.5.1. (Diffie-Hellman Parameters) > 6.3.1.5.2. (ECDHE Parameters) Drop the wrappers? Then DHE and ECDHE could be unified (the unification is currently blocked by different lengths of the length field). The point description might make it more clear that encodings are per- curve (altough most curves use X9.62). Does the note about only single point format apply to signatures too (if so, ec_point_formats could be deprecated). Regarding CFRG curves, the current draft (for TLS 1.2) specifies use of the native point format (32/56 octets) as if it was uncompressed. > 6.3.1.5.4. (Pre-Shared Key Extension) Client SHOULD offer at most two PSK identities (one for DH-PSK, the other for pure-PSK)? This would imply that one can't resume pure-PSK sessions, but that does not look to be useful anyway. Also, could be useful to state that the PSK identity hint from previous versions has been deprecated. > 6.3.1.5.5. (Early Data Indication) s/MUST not/MUST NOT/ in description of early_data with client auth? Also, I would say that 0-RTT data with 0-RTT auth is more dangerous than 0-RTT data with 1-RTT auth (for reasons mentioned earlier in the draft). Eeh, the rule for detecting end of 0RTT data, isn't the next client handshake message from the next flight at least in some cases (and waiting would obviously deadlock)? Again, how is binding of early handshake messages done (or security analysis showing this unnecressary)? Client receiving rejection knows that auth failed and data failed, it might try to fix things up in its next flight. As for what to sign for client auth, the ClientHello and Certificate (at least)? One thing to note is that if verify contains randoms, then server_random isn't available. Regarding finished, isn't Finished in second flight? Or is this another client Finished? Regarding cryptographic parameter set, I think one better prepare for failure (there are multiple causes of server failing to compute keys or decrypt data). Also, how does known_configuration interact with PSK (other than configurations seemingly not being usable with PSK)? Also, the record protection used for early handshake messages should be indicated. I think there are basically two things to signal for 0RTT: - What key material is used (either by PSK ID or configuration ID) - What record protection (and KDF to derive keys) is used? Tying the latter to client offered ciphersuites is probably not wanted. > 6.3.2. (Server Key Share) Add that connection will be rekeyed immediately after this message, and that it MUST be the last message in record it is in? > 6.3.3. (Encrypted Extensions) Some of the figures have this as mandatory, some optional. Which is it? Yeah, would be good to have explicit list of what goes to SH, and what goes to EE. Also, the list is affected by #184, as some extensions introduce extra messages (esp. status_request{,_v2} and signed_certificate_timestamp). > 6.3.4. (Server Certificate) > > The certificate MUST be appropriate for the negotiated cipher > suite's key exchange algorithm and any negotiated extensions. If signature_algorithms is mandatory, this would then key to that for signature algorithm, not ciphersuites (and even if it isn't, it would then key to its fallback default). Could change example of alternative certificate formats to RFC7250 (it seems better designed than RFC5081). Doesn't TLS 1.3 always use the certificate for signing, with indicated algorithm (which obviously needs to be supported by peer)? Wouldn't it make more sense to talk about signature algorithms instead of key exchange algorithms. (Unless some key exchange that uses non-signing certificates is added). > 6.3.6. (Server Configuration) Use TTL instead of of explicit time for expiration, as broken clocks are abound (also, just 32-bit field that only goes up to 2106 or so)? Also, considering the dangers of configuration, it might be appropriate to have other permission flags (especially client and server auth) too? Also, Could be useful for client to know what ciphers it can use for 0-RTT data? > 6.3.7. (Server Certificate Verify) Should PRF hash designation be added in order to avoid attacks from weak PRF hashes? I think note about checking signature algorithm against ciphersuite should be removed. Also, with regards to complications of DSA, just dump it? :-) > 6.3.9. (Client Certificate) > Doesn't CertificateRequest override algorithms anyway (and CR isn't an extension)? Again, could use RFC7250 instead of RFC5081 as an example? > 6.3.10. (Client Certificate Verify) Similar problems as in DSA for server auth. And missing identifier for PRF too. > 6.3.11. (New Session Ticket Message) Eh, if server starts transmitting immediately without waiting for client Finished (as is permitted for case where 1-RTT client auth is not performed), it can't resume the session? > 7.2.3. (Elliptic Curve Diffie-Hellman) Probably needs different description for Curve25519 and Curve448. Those are functions that take in octet strings and output octet strings (32 or 56 bytes). > 11. (IANA Considerations) Yeah, looks to need a rewrite. Doesn't register the new stuff, and furthermore has problems like: - signature_algorithms is already defined by RFC5246. - SignatureAlgorithm registry is already defined. - HashAlgorithm registry is already defined. > A.4. (The Cipher Suite) Probably remove note about 001C and 001D, since lots of ciphersuites are now reserved to avoid collisions with old ones. > C.1. (Random Number Generation and Seeding) Replace SHA-1 with SHA-256? The example is completely obsolete. Any sort of modern PCs have much faster timers (some reaching multi-GHz rates) and one really should use Operating System for (seeding) random numbers. > C.4. (Implementation Pitfalls) - Do you handle required handshake messages being missing or handshake messages being in wrong order properly (i.e. terminate the connection)? Also, ECDSA signing operations need timing protection. s/DSA/ECDSA/ in seeding? And shouldn't k be determinstically generated? > E.1.1. (Authentication and Key Exchange) Would be useful to list what can be used to authenticate peers, in practicular, are the following valid: - Signing TLS-Unique value? - Signing value from TLS-EXPORTER? Both have been seen in the wild, so these better be secure ways. This also goes for "anonymous" key exchange. > E.1.2. (Version Rollback Attacks) Is the note about PKCS #1 block type 2 about RSA key exchange, which is deprecated? -Ilari From nobody Wed Jul 15 09:27:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA6A1A1A66 for ; Wed, 15 Jul 2015 09:27:32 -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 HPqbZotVcqOp for ; Wed, 15 Jul 2015 09:27:30 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E931A1A62 for ; Wed, 15 Jul 2015 09:27:30 -0700 (PDT) Received: by qkbp125 with SMTP id p125so31849331qkb.2 for ; Wed, 15 Jul 2015 09:27:30 -0700 (PDT) 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=uzB1l+ZvuYam3RuHMjo+kfDs4HSP4NhvuSJKqb17yOU=; b=KUVPCxgi9b0zTX1bSZQwnm1pk2QeQyjTkRFNKvG26HtYadrlsw9GhyoKfYB2IWKJcx pms4NOnbPlVDP2buXPmDjTW/WJAM4l1DodasdFI2NgCBkQM9P0pEMnNibMsJT1q7FJyk aBLvv7FX0SZe4baH9yyi5OcNGpxMKDvSOO60KW+W2H2wZbxPaL+HRpTfT6NLga2aACKU ua8h+ESmK6C0n0nNWBcJoxil0nR08/8KBV2sAPPuuhF4CCzCtV+evWHHdP7F6QOgV3DL hLPjK+jGc8EH163LyVzrKYbHrK/CL91vOulmZGAeVms/2ujlCKdjpNHcNRWrRZvXXIUJ uvpg== X-Received: by 10.55.23.151 with SMTP id 23mr9489418qkx.1.1436977649996; Wed, 15 Jul 2015 09:27:29 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 47sm2503619qgt.15.2015.07.15.09.27.29 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 09:27:29 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Ilari Liusvaara Date: Wed, 15 Jul 2015 12:27:27 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150715141523.GA13669@LK-Perkele-VII> In-Reply-To: <20150715141523.GA13669@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507151227.27894.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 16:27:32 -0000 On Wednesday, July 15, 2015 10:15:23 am Ilari Liusvaara wrote: > Let's review: draft-ietf-tls-tls13-07 Eric obviously does all the heavy lifting here, but I can reply to a few bits in the areas I've touched. > (Note: I omitted some stuff I saw recently discussed (e.g. pruning > unused crypto algorithms) or I remember discussed. I didn't explicitly > check issue list when doing this). Some of these already do have issues/PRs so I'll cite them here along with the bits I have fixed in my WIP branch for the discussions we've been having about alerts and certs. I have quite a few PRs pending review by ekr, at the moment. Note that PR 195 is under my name, but is mostly Sean Turner's commits. It's large and was bitrotted severely over time, so ekr and I had to clean it up. (the original is PR 152 with bits from 150) > > Header > > Isn't 4346 already obsoleted by 5246, which this document also obsoletes? > > 4366 seems to be jointly obsoleted by 5246 and 6066. > > 5246 and 5077 are not in numerical order, whereas the rest are. I have a pending PR that fixes this: https://github.com/tlswg/tls13-spec/pull/198/files > > 1.2. (Major Differences from TLS 1.2) > > Is this meant to be changelog or list of changes? It in current form > looks more like a changelog. It is just a changelog for now. Will definitely need to be replaced by a summary for final RFC. > > 5.2.2. (Record Payload Protection) > > There looks to be latter limits that restrict ciphertext size to 2^14 > +1024, which is smaller than 2^14+2048 here (but those limits might be > tightened further). > > As for amount of expansion needed for length-hiding, I think that being > able to represent 16384-byte record with no padding would be enough > (since record sizes cap at 16384 bytes anyway). https://github.com/tlswg/tls13-spec/issues/55 > I don't think client extensions are optional anymore in TLS 1.3 (being > required for successful handshake. I'll address this in my WIP branch for changes we've been discussing on-list. > > 6.3.1.2. (Server Hello) > > Well, at least it wouldn't be backward compatiblity hazard to remove > session_id_len, since it comes after server version. There's a comment in there from ekr asking if we should remove. The answer is a clear yes, seeing as backwards compatibility is already gone here. https://tools.ietf.org/html/rfc5246#section-7.4.1.3 The compression field was already dropped, so there's no point in having a placeholder for this unless a new placeholder is added for that too. This message does not need to maintain backwards compatibility, though. It can never be sent to a pre-TLS 1.3 client, as the client has to offer 1.3+ for the server to negotiate it. A note that this structure has changed since 1.2 is probably warranted for servers that want to also know how to send a proper one for backwards compatibility, but modifying it here isn't helpful. > > 6.3.1.4. (Hello Extensions) > Some candidates: > - truncated_hmac: Block modes have been removed. [...] > - renegotiation_info: The renego bug is fixed anyway. I have bits for both of these on my WIP branch. (not in any of my PRs pending ekr's review, yet) > > 6.3.1.5.5. (Early Data Indication) > > s/MUST not/MUST NOT/ in description of early_data with client auth? I fixed that in my WIP for all the alert and certs changes we've been discussing on list. > > A.4. (The Cipher Suite) > > Probably remove note about 001C and 001D, since lots of ciphersuites are > now reserved to avoid collisions with old ones. I have a pending PR that updates the whole section. This bit is already dropped. https://github.com/tlswg/tls13-spec/pull/180/files > > C.1. (Random Number Generation and Seeding) > > Replace SHA-1 with SHA-256? Done in my WIP along with rest of SHA-1 deprecation, as was discussed very recently. Dave From nobody Wed Jul 15 11:13:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ABC1B3354 for ; Wed, 15 Jul 2015 11:13:26 -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 U3RkXjXD231s for ; Wed, 15 Jul 2015 11:13:24 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC4A1B335B for ; Wed, 15 Jul 2015 11:13:24 -0700 (PDT) Received: by qkcl188 with SMTP id l188so34068495qkc.1 for ; Wed, 15 Jul 2015 11:13:23 -0700 (PDT) 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=cadUCIF7xHhjgaqCLWpUiYrGLw1NwLNb0mL7GKseIFc=; b=H36sL/7AiyklHYS4PkR/O3qMkgDj1hmRkJEJessbEO2nCPkcko0SxXMuGMaq1MZUSd 5vsdM3q8RuPQL1ZiNfOjz1K5xcKJl1+CrVKe9RgHIKol+AHI2LC3JOq2NFflUC04KC5T Cjjg+10nEPGTdBNmOuzHcFJ6KKEJeLvvNTc3BpkBFNEJcrEkfG4+5tNS19SO7OvmGISL NyoP9M4O5TKNnAEgMwlCgTZT48lL5fHpVmh9aIZGyJu/jh+a2GrgsCg1iIAQrbjs8zGc zxXXoJx25XGpHJYaOPWCoScLvzr2MrPiYbHjNcZD4wwx8QzqPg8pv5em+48sWQ4JLrcr nTEw== X-Received: by 10.55.31.6 with SMTP id f6mr10324641qkf.57.1436984003702; Wed, 15 Jul 2015 11:13:23 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id e104sm2656799qgd.29.2015.07.15.11.13.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 11:13:23 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 15 Jul 2015 14:13:21 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201507151413.22408.davemgarrett@gmail.com> Archived-At: Subject: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 18:13:26 -0000 In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the ones actually used. (per Sean's recommendation) One point of discussion between Eric and myself: sect571r1. I'm in favor of keeping it, but not very strongly. Eric suggested removing it. It does get some use, though quite a bit less than the others. The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired by some. The main arguments for ditching is probably that it might not be safely implemented and nobody actually needs something this big. So, should it stay or should it go now? Opinions? Dave From nobody Wed Jul 15 11:19:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F21AD06A for ; Wed, 15 Jul 2015 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, 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 cMySRnFbGpG5 for ; Wed, 15 Jul 2015 11:19:41 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAD51B336E for ; Wed, 15 Jul 2015 11:19:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,481,1432591200"; d="scan'208";a="140143954" Received: from ra178-1-88-163-20-214.fbx.proxad.net (HELO [192.168.0.24]) ([88.163.20.214]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2015 20:19:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Benjamin Beurdouche In-Reply-To: <201507151413.22408.davemgarrett@gmail.com> Date: Wed, 15 Jul 2015 20:19:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C91711E-9B11-44DC-8CF0-C17FB231B51F@inria.fr> References: <201507151413.22408.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2102) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 18:19:43 -0000 Hey, Except if someone has a real need for it, I would favour removing p571 and keep secp521r1 as the maximum =E2=80=A6 Cheers, B. > On 15 Jul 2015, at 20:13, Dave Garrett wrote: >=20 > In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to = just the ones actually used. (per Sean's recommendation) One point of = discussion between Eric and myself: sect571r1. I'm in favor of keeping = it, but not very strongly. Eric suggested removing it. It does get some = use, though quite a bit less than the others. >=20 > The main reason I think this warrants discussion is that dropping it = would drop the maximum bits here, which whilst obviously not the only = factor to take into account, will possibly not be desired by some. The = main arguments for ditching is probably that it might not be safely = implemented and nobody actually needs something this big. >=20 > So, should it stay or should it go now? Opinions? >=20 >=20 > Dave >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 15 11:52:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78E51B3453 for ; Wed, 15 Jul 2015 11:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 AxCHufsAhVa2 for ; Wed, 15 Jul 2015 11:52:44 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 49D671B3468 for ; Wed, 15 Jul 2015 11:51:40 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t6FIpcr3011437; Wed, 15 Jul 2015 14:51:38 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] sect571r1 Thread-Index: AQHQvyn2cAWECIESWEOiLXG0Thx4353c4DWA Date: Wed, 15 Jul 2015 18:51:37 +0000 Message-ID: References: <201507151413.22408.davemgarrett@gmail.com> In-Reply-To: <201507151413.22408.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3519816693_41511985" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-15_07:2015-07-15,2015-07-15,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-1506180000 definitions=main-1507150258 Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 18:52:46 -0000 --B_3519816693_41511985 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m in favor of keeping sect571r1. I realize it doesn=E2=80=99t get a ton of us= age. --=20 Regards, Uri Blumenthal On 7/15/15, 14:13 , "TLS on behalf of Dave Garrett" wrote: >In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just >the ones actually used. (per Sean's recommendation) One point of >discussion between Eric and myself: sect571r1. I'm in favor of keeping >it, but not very strongly. Eric suggested removing it. It does get some >use, though quite a bit less than the others. > >The main reason I think this warrants discussion is that dropping it >would drop the maximum bits here, which whilst obviously not the only >factor to take into account, will possibly not be desired by some. The >main arguments for ditching is probably that it might not be safely >implemented and nobody actually needs something this big. > >So, should it stay or should it go now? Opinions? > > >Dave > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --B_3519816693_41511985 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgicdqma4J3mG4lYOI6RzYMVy1Cnnpt1tvO2Whfpm1spUwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzE1MTg1MTMzWjANBgkqhkiG9w0BAQEFAASC AQBE4o1gs0+3zbpE9/Nw48g88zFdtTLGSD3t6a8UswtpaN1uMw2EOHMo2X0FtUgMN5c4yhPj vRMHFckUCca4SkHqupMn9yj9oYHiul8MbphuAxw35QGYFXz4AQlfea1IKksY+nHikEcx11eQ BfjXOL3jUkElAursC3s5gMHZXSnoYIj6fhq5un32ojGejCDWj1kcjdgR5fE48yP9C2Yjq/S4 iykALh0FFh/oAvW0X28//KTC3FyDsYctHWu5iJZqLt9utgQaXwQcMCAUQ0m9rrKF73h3fVLK QRsoe225Xm+ZwADcVbON6+5rWjDZ6G9zu6Onwl36TnhOamSPck8B+bP6 --B_3519816693_41511985-- From nobody Wed Jul 15 11:55:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D7A1AD36E for ; Wed, 15 Jul 2015 11:55:23 -0700 (PDT) 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 p4qG07278IUQ for ; Wed, 15 Jul 2015 11:55:22 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F551AD369 for ; Wed, 15 Jul 2015 11:55:11 -0700 (PDT) Received: by oibn4 with SMTP id n4so35059934oib.3 for ; Wed, 15 Jul 2015 11:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gwsCvk5PORwKSbmh9abgJU8rdScpX5aBx6365IDeA5o=; b=jri1Gb43r2Rf2CDuEpfBktjwLVyxQuoC+R6uD0uo4Gd3ElWqlGTUOUTkHNOG+h6Wfz Gox4UXxbd9uPcqwBqyiTZWo+zLCaryiy21cJRl092Sog3KK6ZwZF6vTS6XnuOMktEcRM 4OestS1xVhsvzgZV4mojNw9gXfyAJt3jXyCrPlTYdSjrgIXrwBdLlypRJiauRCm38a0L UEZLZgNNcZ/KGy7f9Rsiq9uDs30VYT22L4xsP5iOYCiNelxdYjOUFQIsEItDYEfVv62Q E8ZG2xUAvA2o0grD1UrxC6g8p9tsDW2UsfZbHXkMqx30Dd+zzhM3BIvLlrvstExo0l3p pBGw== X-Received: by 10.202.210.68 with SMTP id j65mr4904249oig.68.1436986510732; Wed, 15 Jul 2015 11:55:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 11:54:51 -0700 (PDT) In-Reply-To: <201507151413.22408.davemgarrett@gmail.com> References: <201507151413.22408.davemgarrett@gmail.com> From: Tony Arcieri Date: Wed, 15 Jul 2015 11:54:51 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113d2b3884f4a6051aee7e4b Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 18:55:23 -0000 --001a113d2b3884f4a6051aee7e4b Content-Type: text/plain; charset=UTF-8 On Wed, Jul 15, 2015 at 11:13 AM, Dave Garrett wrote: > So, should it stay or should it go now? Opinions? I'd prefer to see it removed. There's no good reason to keep it, IMO. -- Tony Arcieri --001a113d2b3884f4a6051aee7e4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 11:13 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
So, should it stay or= should it go now? Opinions?

I'd prefer= to see it removed. There's no good reason to keep it, IMO.
= =C2=A0
--
Tony Arcieri
--001a113d2b3884f4a6051aee7e4b-- From nobody Wed Jul 15 12:38:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA651A1AE8 for ; Wed, 15 Jul 2015 12:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 S5OokdHrtzLL for ; Wed, 15 Jul 2015 12:38:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7264D1A1A9F for ; Wed, 15 Jul 2015 12:38:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D1BD9A888132; Wed, 15 Jul 2015 12:38:02 -0700 (PDT) Received: from 24.43.232.186 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 15 Jul 2015 12:38:03 -0700 (PDT) Message-ID: <6ce70b2d45a6aa67aae04ef7e6940ca7.squirrel@www.trepanning.net> In-Reply-To: <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> Date: Wed, 15 Jul 2015 12:38:03 -0700 (PDT) From: "Dan Harkins" To: "Hubert Kario" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org, Geoffrey Keating Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 19:38:04 -0000 On Mon, June 29, 2015 4:31 am, Hubert Kario wrote: > On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote: >> Dave Garrett writes: >> > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote: >> > > Currently SRP cannot be used with newer crypto primitives such as >> > > ciphers in AEAD mode or SHA-2 due to the lack of cipher suites >> enabling >> > > these. There's only 3DES and AES-CBC with SHA-1. >> > > >> > > Would there be support for expanding the SRP cipher suites? >> > >> > I don't think it's a good idea to add new SRP cipher suites. >> > >> > Instead, I think redefining SRP as an extension to PSK would make more >> > sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to >> get >> > similar capabilities. This would make updating SRP to use newer crypto >> > much easier, as modern PSK cipher suites are easier to get >> standardized. >> > The current SRP spec actually already appears to rely on PSK identity >> > alert codes. >> The problem with that is that there are surely many use cases where >> you're willing to do SRP, or if no SRP you can do a regular ECDHE and >> prompt for the username/password, but PSK is too insecure. >> >> I've been thinking an improved SRP would be useful. It should: >> >> - Specify Modern cipher and hash algorithms as mentioned above >> >> - Replace the existing SHA1+seed with a password whitening function >> like PBKDF2, so that in the event of a compromised server cracking >> the password is harder, and also making online password guessing >> attacks (sending lots of username+password pairs to the server) more >> expensive* >> >> - Deprecate the 1024-bit and the 1536-bit group, and the previous SRP >> ciphersuites; and say that these should only be chosen if the server >> has a legacy verifier for a particular username which requires >> them. > > +1, provided we do two more things: > > - Change the negotiation so that user name is not exchanged in the clear > - Change key exchange to do PFS TLS-pwd already supports both of these. It also supports ECC too, which is problematic with the current SRP protocol. regards, Dan. From nobody Wed Jul 15 12:52:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529CB1A87A6 for ; Wed, 15 Jul 2015 12:52:30 -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 eVgz7fVC_zf9 for ; Wed, 15 Jul 2015 12:52:29 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519F81A88A6 for ; Wed, 15 Jul 2015 12:52:12 -0700 (PDT) Received: by widic2 with SMTP id ic2so11612564wid.0 for ; Wed, 15 Jul 2015 12:52:11 -0700 (PDT) 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=lJwOHmPPPL6z94u+igXpQAkAPvRJ81HmBD11ZZ9KyhY=; b=H34PFGWgpIb70HaAhSaNkBWXh4zYHOtVj6kawm8E+XnpMMEkuB2h5H3m3t4Wo55hbr l5/dVDmpBzn2igkC5l9EzB7ZYZYy1lCcGsEwGTCPRZGAvGQpLrfeN9PWWIdwFrZSZiFv 0wR4csKGK2eMjJ/Krysbi5pp7DTmj3odOCo1XzKm3WNLq6VJWrxiYbxI7k/0VrvJiNHL k6IEpkZILJY1Pf5BirvTClZCZs32hsjf5nE515EqeQWkvMdY+5mk8j3jOTMtzRFFF1pO TEl7lfQGLPKNOoRKf+fgCaBLVKdUlKXvB0AQY/uzo36nDAXePl5F+Q+DP0Mzx7Fa21by U0qA== X-Received: by 10.180.78.136 with SMTP id b8mr3236085wix.44.1436989930963; Wed, 15 Jul 2015 12:52:10 -0700 (PDT) Received: from [192.168.1.15] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id ck18sm9378652wjb.47.2015.07.15.12.52.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jul 2015 12:52:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <0C91711E-9B11-44DC-8CF0-C17FB231B51F@inria.fr> Date: Wed, 15 Jul 2015 22:52:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F2EC5F9-A44C-4783-9EEC-48791C2AECC7@gmail.com> References: <201507151413.22408.davemgarrett@gmail.com> <0C91711E-9B11-44DC-8CF0-C17FB231B51F@inria.fr> To: Benjamin Beurdouche X-Mailer: Apple Mail (2.2102) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 19:52:30 -0000 > On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche = wrote: >=20 > Hey, >=20 > Except if someone has a real need for it, > I would favour removing p571 and keep secp521r1 as the maximum =E2=80=A6= +1 It should be noted that I have removed it from RFC4492bis. In terms of = real-world use secp256r1>>secp384r1>>secp521r1 and everything else is = lost in the noise.=20 At any rate, if the group decides to keep it, I might as well bring it = back to 4492bis as well. Yoav From nobody Wed Jul 15 13:04:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C0C1A3BA1 for ; Wed, 15 Jul 2015 13:04:56 -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 2OjoZj5lu1NO for ; Wed, 15 Jul 2015 13:04:54 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAF61ACE05 for ; Wed, 15 Jul 2015 13:04:54 -0700 (PDT) Received: by wibud3 with SMTP id ud3so7465514wib.0 for ; Wed, 15 Jul 2015 13:04:53 -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=1v8TT1t9fff7wa2kVgHyncHD4ZMckC3QsZG9tAPZBHE=; b=D2ZfeQqgnUTBaBe5RSr8wmq8T+pgQR8E5z6nTIoTpD/7kOhH8Sd33z8f7cy6FfDyUM RQmjJnvY+GRHsjbQtD7Gtkzkoq3d72t4G2NXZDXp3PxhymGJEYGqPwQ/Dks1UY03hCTI fRYmP8V8FBDUywpMhSN+ddUAnY0L/5MAB3ouQhfciFEMzUvzfQcGJThTjycttYSSC8K/ ivSb7i8/50VcjApabippDrUixBYVqqByXumm8GMxM6l+2hjdUQgWoHAHdDcerFkTmYD+ hkyoWpOicDIIYgBFA4rh3YyE2Ssb5DVNYdJI+5K0RrH6QrGNn6AlXpdy1B4xSttNVqn5 yXXA== X-Gm-Message-State: ALoCoQm0UrbfIyaQJAlyvB3m43rNAq1XzBTemlqTJVSBEnXPln+v6cxIJ22nKw1WaoWH2RIcZ/vJ X-Received: by 10.180.75.78 with SMTP id a14mr2340813wiw.68.1436990693303; Wed, 15 Jul 2015 13:04:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Wed, 15 Jul 2015 13:04:13 -0700 (PDT) In-Reply-To: <4F2EC5F9-A44C-4783-9EEC-48791C2AECC7@gmail.com> References: <201507151413.22408.davemgarrett@gmail.com> <0C91711E-9B11-44DC-8CF0-C17FB231B51F@inria.fr> <4F2EC5F9-A44C-4783-9EEC-48791C2AECC7@gmail.com> From: Eric Rescorla Date: Wed, 15 Jul 2015 13:04:13 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d0438eb9dd1fff2051aef7742 Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 20:04:56 -0000 --f46d0438eb9dd1fff2051aef7742 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We absolutely should have harmony between 1.3 and 4492bis. Since Uri objected, i'll let the chairs decide if/when we have consensus. -Ekr On Wed, Jul 15, 2015 at 12:52 PM, Yoav Nir wrote: > > > On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche < > benjamin.beurdouche@inria.fr> wrote: > > > > Hey, > > > > Except if someone has a real need for it, > > I would favour removing p571 and keep secp521r1 as the maximum =E2=80= =A6 > > +1 > > It should be noted that I have removed it from RFC4492bis. In terms of > real-world use secp256r1>>secp384r1>>secp521r1 and everything else is los= t > in the noise. > > At any rate, if the group decides to keep it, I might as well bring it > back to 4492bis as well. > > Yoav > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0438eb9dd1fff2051aef7742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We a= bsolutely should have harmony between 1.3 and 4492bis.

Since Uri objected, i'= ll let the chairs decide if/when we have consensus.

-Ekr


On Wed, Jul 15, 2015 at 12:52 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:<= br> >
> Hey,
>
> Except if someone has a real need for it,
> I would favour removing p571 and keep secp521r1 as the maximum =E2=80= =A6

+1

It should be noted that I have removed it from RFC4492bis. In terms of real= -world use secp256r1>>secp384r1>>secp521r1 and everything else = is lost in the noise.

At any rate, if the group decides to keep it, I might as well bring it back= to 4492bis as well.

Yoav

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

--f46d0438eb9dd1fff2051aef7742-- From nobody Wed Jul 15 13:58:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2461B2C36 for ; Wed, 15 Jul 2015 13:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 ZdQQFWPfyc7r for ; Wed, 15 Jul 2015 13:58:35 -0700 (PDT) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A151B2C2A for ; Wed, 15 Jul 2015 13:58:35 -0700 (PDT) Received: by vnbf62 with SMTP id f62so5911785vnb.9 for ; Wed, 15 Jul 2015 13:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=VM1aDLlwH4pJH2zcaguEznQaGT5tHh6NVH5XOKlZjbs=; b=H7mqtADencT30p4X0rlYKzCUUzkOROJaKLyEbLG31PJ3ey5DjXvV6PRbdV5YfmUbzz wHALoROTs6TQtCrjlYxzBe3yRRgKlvs8sC88G533hNOeYATW+/vfT2TU7HMhkzf/UsmK ZaCsdVRIn4CXFmuqqQvrXuivTEVojaggHChjoLrliD25pSpKdkO+n3qZuGpyya7LT0aO EaEPYZjM46T5i2zl/pJWCVXoiPMApZKk5CJxEIUiY+xeMboQt1Ee+048Dp9o/LflY+8k SG2T7IMyz9QXXuFXedaUeXSBPktcWzdlvecJmm5zsvaZO5R0HaOgMs198HWREArkY8oK b25A== X-Received: by 10.52.164.130 with SMTP id yq2mr6335189vdb.73.1436993914737; Wed, 15 Jul 2015 13:58:34 -0700 (PDT) MIME-Version: 1.0 References: <201507151413.22408.davemgarrett@gmail.com> In-Reply-To: <201507151413.22408.davemgarrett@gmail.com> From: Deirdre Connolly Date: Wed, 15 Jul 2015 20:58:24 +0000 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c2c960d51bd5051af037f2 Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 20:58:36 -0000 --001a11c2c960d51bd5051af037f2 Content-Type: text/plain; charset=UTF-8 > So, should it stay or should it go now? Opinions? > +1 that sect571r1 be removed. --001a11c2c960d51bd5051af037f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So, should it stay or should it go now? Opinions= ?

+1 that=C2=A0sect571r1 be removed.
--001a11c2c960d51bd5051af037f2-- From nobody Wed Jul 15 13:59:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6521B2C2D for ; Wed, 15 Jul 2015 13:59:29 -0700 (PDT) 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 PCOyZCOTdGvK for ; Wed, 15 Jul 2015 13:59:28 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDDB1B2C2C for ; Wed, 15 Jul 2015 13:59:27 -0700 (PDT) Received: by lagw2 with SMTP id w2so32056966lag.3 for ; Wed, 15 Jul 2015 13:59:26 -0700 (PDT) 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=SzwQ4F5yGG0TrpbvBRKERikofq7++6h+tviVGzqUP18=; b=PdTI7Wdvy4jNrqKqOk7XGyAm64AJXJ+IS8bJWISH7iAPJC2EUDi/Tyg39BId8zR4MF kGd33l7x6NBz5+ZVhWqXmiuDo1QR7EtF4Qu3H9nMuAz9EoWx8jVN2JotagBFz8vexo1i 80bLXqbII7gPFoq8TUMeLtwwRRBfL6UUh9BNNDclrFgghewg+ep7Efm4YzN7p6+UpUJE 24uxD02Wra8/0BwxrImtuFAzbFQkEUPPz68IEx90/ggg4PbJhiN2bM4WY3px37A5bDsT Xdrvp/7WSPZFy8wJiihwMLuWKMTtcgjJo6ddBFFzekxLU8g+B6dnFodlh2MqJYg3QRl7 yHkQ== MIME-Version: 1.0 X-Received: by 10.112.143.74 with SMTP id sc10mr692889lbb.116.1436993966269; Wed, 15 Jul 2015 13:59:26 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.89.69 with HTTP; Wed, 15 Jul 2015 13:59:26 -0700 (PDT) In-Reply-To: References: <201507151413.22408.davemgarrett@gmail.com> Date: Wed, 15 Jul 2015 13:59:26 -0700 X-Google-Sender-Auth: v8NcCP9_2c1p_hR0KyJ0dDExTjk Message-ID: From: Adam Langley To: Deirdre Connolly Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 20:59:29 -0000 On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly wrote: > >> So, should it stay or should it go now? Opinions? > > +1 that sect571r1 be removed. I also believe that it should be removed. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed Jul 15 14:06:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F71B2C5B for ; Wed, 15 Jul 2015 14:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.094 X-Spam-Level: ** X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 MDriXNnzdXSv for ; Wed, 15 Jul 2015 14:06:53 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 5AF9F1B2C4F for ; Wed, 15 Jul 2015 14:06:52 -0700 (PDT) Received: (qmail 13417 invoked from network); 15 Jul 2015 21:07:11 -0000 Received: from unknown (HELO hyperelliptic.org) (131.155.71.33) by calvin.win.tue.nl with SMTP; 15 Jul 2015 21:07:11 -0000 Received: (qmail 27966 invoked by uid 1000); 15 Jul 2015 21:06:37 -0000 Date: Wed, 15 Jul 2015 23:06:37 +0200 From: Tanja Lange To: tls@ietf.org Message-ID: <20150715210637.GT12152@cph.win.tue.nl> References: <201507151413.22408.davemgarrett@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507151413.22408.davemgarrett@gmail.com> User-Agent: Mutt/1.5.11 Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 21:06:54 -0000 > The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired by some. The main arguments for ditching is probably that it might not be safely implemented and nobody actually needs something this big. > Removing it would drop the max number of bits but not necessarily the max security. The exact security of binary curves is currently under discussion. The new algorithms offer at best an asymptotic speedup -- but 571 might be big enough to fall under asymptotics. I understand that libraries support it, but is it actually being used? Does anybody have statistics on how many sites use it? Tanja From nobody Wed Jul 15 14:11:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D399D1B34C3 for ; Wed, 15 Jul 2015 14:11:42 -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 ICxNVQKbU2gS for ; Wed, 15 Jul 2015 14:11:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850EF1B34C2 for ; Wed, 15 Jul 2015 14:11:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 781A0284D68; Wed, 15 Jul 2015 21:11:40 +0000 (UTC) Date: Wed, 15 Jul 2015 21:11:40 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150715211140.GU28047@mournblade.imrryr.org> References: <201507151413.22408.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] sect571r1 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, 15 Jul 2015 21:11:43 -0000 On Wed, Jul 15, 2015 at 01:59:26PM -0700, Adam Langley wrote: > On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly > wrote: > > > >> So, should it stay or should it go now? Opinions? > > > > +1 that sect571r1 be removed. > > I also believe that it should be removed. Same here, I think in this case "less is more". There is no compelling reason for this curve, and needless diversity here is counter-productive. -- Viktor. From nobody Wed Jul 15 14:39:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3E01B2CF6 for ; Wed, 15 Jul 2015 14:39:30 -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 WQrkLtUSS2yH for ; Wed, 15 Jul 2015 14:39:29 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55BC1B2CF5 for ; Wed, 15 Jul 2015 14:39:28 -0700 (PDT) Received: by qkdl129 with SMTP id l129so38143301qkd.0 for ; Wed, 15 Jul 2015 14:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=cYqRhhELv/JpBaY2JP0aOFSXj1AxAaZ/4p+OuWnThas=; b=tSqhWfgm2NqskC2dA7n+OTDOa3b0QwYO9dolyW/lOHctaEs58mI9/cTn6Bx6C2f1qz In3klQj3dlVifDGcG0PHBrps2GLcmf2Thu2iYg1pxx9rYwAbU+YTmi7bxbhz420yiJrC lQdjjWRlSPdCMT1UBNbguO0A/HYNzTKT7e4O8LRuaxwjno4fLaSbQcHJBJ1cGP5kApls /ERcYPwNfPkFjgDpXde0MqxJJ6o9v5dI9SldP6g52L5RoCyF6LCmuYBtH13+DX0wFaAg mW8LzQg2blLdJP/ssDTwY8gLTC9gtng+8HXDkQ1NndWkzOtwRLTi5+pr0ahMLLOwbwVK NOuw== X-Received: by 10.55.21.94 with SMTP id f91mr11649765qkh.51.1436996368195; Wed, 15 Jul 2015 14:39:28 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id w67sm2940048qgw.41.2015.07.15.14.39.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 14:39:27 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Tanja Lange Date: Wed, 15 Jul 2015 17:39:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507151413.22408.davemgarrett@gmail.com> <20150715210637.GT12152@cph.win.tue.nl> In-Reply-To: <20150715210637.GT12152@cph.win.tue.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507151739.27053.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 21:39:31 -0000 On Wednesday, July 15, 2015 05:06:37 pm Tanja Lange wrote: > > The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired by some. The main arguments for ditching is probably that it might not be safely implemented and nobody actually needs something this big. > > Removing it would drop the max number of bits but not necessarily the > max security. The exact security of binary curves is currently under > discussion. The new algorithms offer at best an asymptotic speedup -- > but 571 might be big enough to fall under asymptotics. > > I understand that libraries support it, but is it actually being used? > Does anybody have statistics on how many sites use it? It's the most used of the rarely used curves. https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/ Server-side support is generally low, however a number of servers prefer to use it for ECDHE. (usage is in the same order of magnitude as P-384 & P-521, though notably less) This is down from the previous month's results but up from the month before. Server support is at a similar rate to other rarely used larger curves, but still a fraction of a percent. Nothing requires it, outright. It's important to note that the dropped range(s) of curves are listed as "MUST NOT" offer or negotiate for any TLS 1.3 implementation, though I haven't added any requirement to enforce that. Dropping it really does drop down the max size drastically, but the general CFRG consensus seems to be that nothing above curve448 is even helpful and secp521r1 would still be permitted for those that want bigger numbers. (given the CFRG opinion, even secp521r1 should be on the chopping block, then) Dave From nobody Wed Jul 15 14:42:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C241B2D1E for ; Wed, 15 Jul 2015 14:42:51 -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 VhiZ6OR2oFdI for ; Wed, 15 Jul 2015 14:42:50 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B401B2D1A for ; Wed, 15 Jul 2015 14:42:50 -0700 (PDT) Received: by qget71 with SMTP id t71so24757227qge.2 for ; Wed, 15 Jul 2015 14:42:49 -0700 (PDT) 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=e8b1yJHNSrY32C2h9qcymhVMej2O9rB/tpxEvz0+eTk=; b=mF9qEuilOWPjGZ9d85i7eqJCxcF7rGUmoHbXNanOwsTfHUfeXj46oNtDTbUL7mNDHm zTStLJ76qs1Py58oZ0OJEO9mgV8nMn0pecJwyq95msKkC1CjSWs0rZ9Cxp6DI/XZk2y8 35xkUjO3fnVpIP30SpWzOjwmLn0Q8Pd9PbhrqTpYvS3m7E5xOZPYaJj2WPFQiCcouDZY BbAc4tnmfsBv9Pk427ykwfIl7tYYGX09jqFdURvbH/epNSGs5JJCi5oOKnWWoteZjKo4 GBFYWRDRnARQYTktSDF42frPu+B+5Zod/QyyxoenrY/b8YBov+sVX8d6xijbK9oxtQzy 7N6g== X-Received: by 10.55.51.79 with SMTP id z76mr12255485qkz.32.1436996569426; Wed, 15 Jul 2015 14:42:49 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id g30sm2956228qge.11.2015.07.15.14.42.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 14:42:49 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 15 Jul 2015 17:42:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507151413.22408.davemgarrett@gmail.com> <20150715210637.GT12152@cph.win.tue.nl> <201507151739.27053.davemgarrett@gmail.com> In-Reply-To: <201507151739.27053.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507151742.48038.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 21:42:51 -0000 On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: > It's the most used of the rarely used curves. This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE. Dave From nobody Wed Jul 15 15:06:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE28E1B2D7D for ; Wed, 15 Jul 2015 15:06:58 -0700 (PDT) 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 1MAsT09w-YpL for ; Wed, 15 Jul 2015 15:06:57 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669A81B2D7C for ; Wed, 15 Jul 2015 15:06:57 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so35670404obb.0 for ; Wed, 15 Jul 2015 15:06: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:from:date:message-id:subject:to :cc:content-type; bh=En76VBrpsek2gW3MPNxzb7lvpKWUYm8re41MKBTFKPQ=; b=SZ43JQgbP5zGLrhteHJBFv8IN0dCIRCH85bSqTeuYDZ375sR4XRWzTwJ6Ncq0+iaA9 cJJ1Syogimk3VtBJTBwEIlTg4im/TcdkDaKI2gl1ACC/Avy8C8wkzS6ofqFpACkeHBqj g5cdpg3o9asW7u9F0b9hFbyjASvz6Ec8gd0UBdvd2evQB66f+JNi7HT2xXuSfT1HZZrG 596NbEj4GnBO1ddVJ7yEY49t2pBHR5O9BSKePQljJXG73Gy+QW3lNHSvOlZ0GTBsROxc Y67/AJEP9kNl2FgbUQT7yjAHFC/lY+OAZUNzcS3p6L6J3ZGgUEJlhzDC+Vo9W0thk0CT wmdQ== X-Received: by 10.182.76.100 with SMTP id j4mr5571321obw.14.1436998016940; Wed, 15 Jul 2015 15:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 15:06:37 -0700 (PDT) In-Reply-To: <201507151739.27053.davemgarrett@gmail.com> References: <201507151413.22408.davemgarrett@gmail.com> <20150715210637.GT12152@cph.win.tue.nl> <201507151739.27053.davemgarrett@gmail.com> From: Tony Arcieri Date: Wed, 15 Jul 2015 15:06:37 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b67292457bed5051af12c8d Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 22:06:58 -0000 --047d7b67292457bed5051af12c8d Content-Type: text/plain; charset=UTF-8 On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: > It's the most used of the rarely used curves. I think all "rarely used curves" should be removed from TLS. Specifically, I think it would make sense for TLS to adopt a curve portfolio like this: - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks - NIST curves (SUPPORTED): P-256, P-384, P-521 All other curves should be removed, IMO. --047d7b67292457bed5051af12c8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 2:39 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:
It's the most used= of the rarely used curves.

I think all &qu= ot;rarely used curves" should be removed from TLS. Specifically, I thi= nk it would make sense for TLS to adopt a curve portfolio like this:
<= div>
- CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilock= s
- NIST curves (SUPPORTED): P-256, P-384, P-521

All other curves should be removed, IMO.
--047d7b67292457bed5051af12c8d-- From nobody Wed Jul 15 15:18:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921CD1B3515 for ; Wed, 15 Jul 2015 15:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 o3x3lAncM5r9 for ; Wed, 15 Jul 2015 15:18:49 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 165771B3512 for ; Wed, 15 Jul 2015 15:18:47 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t6FMIjTQ007502; Wed, 15 Jul 2015 18:18:45 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Tony Arcieri , Dave Garrett Thread-Topic: [TLS] sect571r1 Thread-Index: AdC/TDaKJSx8WBrRi0ybYAg/tRHgxw== Date: Wed, 15 Jul 2015 22:18:44 +0000 Message-ID: <20150715221853.17764416.1980.9532@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1753025329==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-15_07:2015-07-15,2015-07-15,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-1506180000 definitions=main-1507150294 Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 22:18:51 -0000 --===============1753025329== Content-Type: multipart/alternative; boundary="===============1566406619==" MIME-Version: 1.0 --===============1566406619== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSBsaWtlIFRvbnkncyByZWNvbW1lbmRhdGlvbiAtIGV4Y2VwdCB0aGF0IEknZCByYXRoZXIgbm90 IOKAjmxvc2UgdGhlIDU3MSBjdXJ2ZS4gQnV0IEknbSBub3QgZ29pbmcgdG8gZmlnaHQgdGhlIGVu dGlyZSBXRyBvdmVyIHRoaXMuwqAKClNlbnTCoGZyb23CoG15wqBCbGFja0JlcnJ5wqAxMMKgc21h cnRwaG9uZcKgb27CoHRoZSBWZXJpem9uwqBXaXJlbGVzc8KgNEfCoExURcKgbmV0d29yay4KRnJv bTogVG9ueSBBcmNpZXJpClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNSwgMjAxNSAxODowNwpUbzog RGF2ZSBHYXJyZXR04oCOCkNjOiA8dGxzQGlldGYub3JnPgpTdWJqZWN0OiBSZTogW1RMU10gc2Vj dDU3MXIxCuKAjgpPbiBXZWQsIEp1bCAxNSwgMjAxNSBhdCAyOjM5IFBNLCBEYXZlIEdhcnJldHQg PGRhdmVtZ2FycmV0dEBnbWFpbC5jb20+IHdyb3RlOgpJdCdzIHRoZSBtb3N0IHVzZWQgb2YgdGhl IHJhcmVseSB1c2VkIGN1cnZlcy4KCkkgdGhpbmsgYWxsICJyYXJlbHkgdXNlZCBjdXJ2ZXMiIHNo b3VsZCBiZSByZW1vdmVkIGZyb20gVExTLiBTcGVjaWZpY2FsbHksIEkgdGhpbmsgaXQgd291bGQg bWFrZSBzZW5zZSBmb3IgVExTIHRvIGFkb3B0IGEgY3VydmUgcG9ydGZvbGlvIGxpa2UgdGhpczoK Ci0gQ0ZSRyBjdXJ2ZXMgKFJFQ09NTUVOREVEKTogQ3VydmUyNTUxOSwgRWQ0NDgtR29sZGlsb2Nr cwotIE5JU1QgY3VydmVzIChTVVBQT1JURUQpOiBQLTI1NiwgUC0zODQsIFAtNTIxCgpBbGwgb3Ro ZXIgY3VydmVzIHNob3VsZCBiZSByZW1vdmVkLCBJTU8uCuKAjg== --===============1566406619== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
I like Tony's r= ecommendation - except that I'd rather not =E2=80=8Elose the 571 curve. But= I'm not going to fight the entire WG over this. 
= =
=
=
Sent from my BlackBerry 10&n= bsp;smartphone on the Verizon Wireless 4G LTE=  network.
= =
From: Tony Arcieri
Sent: Wed= nesday, July 15, 2015 18:07
To: Dave Garrett=E2=80=8E
Cc: <tls@ietf.org>
Subject: Re: [TLS] s= ect571r1
=E2=80=8E
On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett <davemgarrett@gmail.com>= ; wrote:
It's the most used of the rarely used curves.

I think all "rarely used curves" should be removed from TLS. Specifica= lly, I think it would make sense for TLS to adopt a curve portfolio like th= is:

- CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks
- NIST curves (SUPPORTED): P-256, P-384, P-521

All other curves should be removed, IMO.
=E2=80=8E
--===============1566406619==-- --===============1753025329== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcxNTIyMTg1MVowLwYJKoZIhvcNAQkEMSIEIOlugh4Zg7tQ clVgTMv0UtmKRkBqsjDRPBlRd5Bb8HaeMAsGCSqGSIb3DQEBCwSCAQBpfShCehfPf53gHMfCeszT vPppJDGd2N0wNR2qSAfeto8Ej4TnLAtgZQ/2SysQDGJQub+Or8txrO/MBCzeOd4cpus0dNKBlT60 ZH2gh0k0lS/ix4j3J7Rr/3heuhSK/sQhbx3rvBZuGn7QoKqXxqXlJmmObA69ZoLL/fifUaIC7OWJ l0MgzvnX29lN7YwULgMLvA+Qf6T85PK/z65cLUe+1ikB61lv2ODz5ZtaYYv2ogwJo3J6DJuyJx98 8TXH7zBvmNX1l3lmw9SVWNBoWNNgYAtEZCoCiJJQoJ4G9VxDh2d7DMKjLj+ln2++CGy7PYkl1sNn jT5YN+qTaMmkXgc6AAAAAAAA --===============1753025329==-- From nobody Wed Jul 15 15:23:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CCD1B3527 for ; Wed, 15 Jul 2015 15:22:58 -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 eeky_GpEbHec for ; Wed, 15 Jul 2015 15:22:56 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7511F1B2D5C for ; Wed, 15 Jul 2015 15:22:56 -0700 (PDT) Received: by qkbp125 with SMTP id p125so38825280qkb.2 for ; Wed, 15 Jul 2015 15:22:55 -0700 (PDT) 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=zpbjsljNciO8FWH59Wsh2Hbl5UBvtid/WiroW1x6qLs=; b=ngnHvbFFFOnxz1SVPOkVHHNCo1sWz4KllpfCuamZDqljOVfdas4GIMKgh4IN2NXXRl 6YtV5JXskxHAcTTEjdFfBkTQrIthXwF3lZ3H/AMPwuT7h1MjfVLIOaVt1Y9wM4I2fXAD 7tVHV397Wp2SQPWIUvoJwnDjFKGXkv7WINNp4lwyhQMfHXgjq31CJBuvkMKdyYh7c32B WaCvuDDV8B1aA12pCH3sSypF+Yw/Oo5HEMRp4MkMRx+86ojEsJd3ST0/acEdv0qPcpEw NUqvozUJ0H4ktvxBdVpyHVk1CdBxfO7G5hzH8A9nnW9ceQZU9ZKkzLP3cJplZ3EY61OW U5eA== X-Received: by 10.55.20.156 with SMTP id 28mr12353308qku.9.1436998975757; Wed, 15 Jul 2015 15:22:55 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id j60sm2997828qge.38.2015.07.15.15.22.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 15:22:55 -0700 (PDT) From: Dave Garrett To: "" Date: Wed, 15 Jul 2015 18:22:53 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507151413.22408.davemgarrett@gmail.com> <201507151739.27053.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507151822.54211.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 22:22:58 -0000 On Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: > > It's the most used of the rarely used curves. > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 > > All other curves should be removed, IMO. This does seem to be the growing consensus. I've submitted a PR to drop it: https://github.com/tlswg/tls13-spec/pull/200/files Unless someone can provide more detail as to why it might be needed to keep around, it looks like the WG wants rid of it. Dave From nobody Wed Jul 15 15:27:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3D11B3532 for ; Wed, 15 Jul 2015 15:27:43 -0700 (PDT) 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 BC1CCkVAJNRg for ; Wed, 15 Jul 2015 15:27:40 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 DA36E1B352B for ; Wed, 15 Jul 2015 15:27:39 -0700 (PDT) Received: (qmail 27276 invoked by uid 1004); 15 Jul 2015 22:27:37 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 15 Jul 2015 23:27:37 +0100 Received: (qmail 32234 invoked by uid 1000); 15 Jul 2015 22:27:37 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 15 Jul 2015 23:27:37 +0100 Message-ID: <55A6DE59.8080409@comodo.com> Date: Wed, 15 Jul 2015 23:27:37 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Garrett , tls@ietf.org References: <201507151413.22408.davemgarrett@gmail.com><20150715210637.GT12152@cph.win.tue.nl><201507151739.27053.davemgarrett@gmail.com> <201507151742.48038.davemgarrett@gmail.com> In-Reply-To: <201507151742.48038.davemgarrett@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 22:27:44 -0000 AIUI, OpenSSL's default highest preference curve is sect571r1 (aka B-571). See [1] and [2]. The result of calling OpenSSL's recommended SSL_CTX_set_ecdh_auto(ctx, 1) function is that "the highest preference curve is automatically used for ECDH temporary keys used during key exchange." [3] And sure enough, when my SSL scanner (an OpenSSL-based client) scans itself (an httpd/mod_ssl/OpenSSL-based server) [4], it reports that sect571r1 is used. I haven't explicitly configured it to use this curve. In fact, I would reconfigure it to use secp256r1 if I could find a mod_ssl directive that would let me do that. So I'm wondering if most people using sect571r1 are using it simply because it's a default setting that they can't change, not because they have a particularly strong desire to use it. +1 to dropping sect571r1 and to Tony's suggestion of further trimming the curve list. [1] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.1l [2] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.2 [3] http://openssl.org/docs/ssl/SSL_CTX_set_ecdh_auto.html [4] https://sslanalyzer.comodoca.com/?url=sslanalyzer.comodoca.com On 15/07/15 22:42, Dave Garrett wrote: > On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: >> It's the most used of the rarely used curves. > > This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jul 15 15:53:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0B1B2E62 for ; Wed, 15 Jul 2015 15:53:40 -0700 (PDT) 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 I2kbB0y47yNo for ; Wed, 15 Jul 2015 15:53:37 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 5D1871B2E41 for ; Wed, 15 Jul 2015 15:53:37 -0700 (PDT) Received: (qmail 18767 invoked by uid 1004); 15 Jul 2015 22:53:35 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 15 Jul 2015 23:53:35 +0100 Received: (qmail 6369 invoked by uid 1000); 15 Jul 2015 22:53:35 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 15 Jul 2015 23:53:35 +0100 Message-ID: <55A6E46F.7060106@comodo.com> Date: Wed, 15 Jul 2015 23:53:35 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Garrett , tls@ietf.org References: <201507151413.22408.davemgarrett@gmail.com><20150715210637.GT12152@cph.win.tue.nl><201507151739.27053.davemgarrett@gmail.com><201507151742.48038.davemgarrett@gmail.com> <55A6DE59.8080409@comodo.com> In-Reply-To: <55A6DE59.8080409@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 22:53:41 -0000 On 15/07/15 23:27, Rob Stradling wrote: > AIUI, OpenSSL's default highest preference curve is sect571r1 (aka > B-571). See [1] and [2]. > > The result of calling OpenSSL's recommended SSL_CTX_set_ecdh_auto(ctx, > 1) function is that "the highest preference curve is automatically used > for ECDH temporary keys used during key exchange." [3] > > And sure enough, when my SSL scanner (an OpenSSL-based client) scans > itself (an httpd/mod_ssl/OpenSSL-based server) [4], it reports that > sect571r1 is used. I haven't explicitly configured it to use this > curve. In fact, I would reconfigure it to use secp256r1 if I could find > a mod_ssl directive that would let me do that. > > So I'm wondering if most people using sect571r1 are using it simply > because it's a default setting that they can't change, not because they > have a particularly strong desire to use it. s/that they can't change// In httpd 2.4, the supported curve(s) can be configured using the SSLOpenSSLConfCmd directive. (Thanks to Steve Henson for pointing me in the right direction just now). > +1 to dropping sect571r1 and to Tony's suggestion of further trimming > the curve list. > > > [1] > https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.1l > > [2] > https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.2 > > [3] http://openssl.org/docs/ssl/SSL_CTX_set_ecdh_auto.html > > [4] https://sslanalyzer.comodoca.com/?url=sslanalyzer.comodoca.com > > On 15/07/15 22:42, Dave Garrett wrote: >> On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: >>> It's the most used of the rarely used curves. >> >> This statement is potentially confusing, actually, because in >> comparison to P256 _everything_ is rarely used when it comes to ECDHE. >> >> >> Dave >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Wed Jul 15 16:23:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E0F1B2ED6 for ; Wed, 15 Jul 2015 16:23:55 -0700 (PDT) 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 y6lGdhm5P16B for ; Wed, 15 Jul 2015 16:23:54 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFD91B2EBC for ; Wed, 15 Jul 2015 16:23:54 -0700 (PDT) Received: by ykeo3 with SMTP id o3so50211814yke.0 for ; Wed, 15 Jul 2015 16:23:53 -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=/mDCZkEP+Cl5Usrg2l7RnyrJLXysIeXvJv4a63zotso=; b=pEd/SzSAFGOkHTyEnOipjriVOTqcqlOohQfsTsQsZKVQCkeAp5HCxv+eURefzE655e yEt1Na5rywRaRG0AzDTAcjr5qpMX0V8fCiNMCiaQSl6Yq0m6qanwDsJX5ystnurkFML7 ggfVMkENHIBhdy1t3I/xrqfwR6FZiAooX5SOxYm3xZk7e0i2kxkE48Ny7pPwWxHFuyXE CRBkF0zBDouxOwVduz+aT+SnMzjOKNFdN4T3kg0lWYdN71nqf3ZwfWxDPU8b8Cj1IhLt oCqowJOp1NcNHiyvSfNHCCqNwWZF6pUcIiYcNTPKRnbG94TkDVfktF9d9rhHfSG61Vqz kK9Q== MIME-Version: 1.0 X-Received: by 10.129.97.5 with SMTP id v5mr6995538ywb.56.1437002633565; Wed, 15 Jul 2015 16:23:53 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 15 Jul 2015 16:23:53 -0700 (PDT) In-Reply-To: <20150715221853.17764416.1980.9532@ll.mit.edu> References: <20150715221853.17764416.1980.9532@ll.mit.edu> Date: Wed, 15 Jul 2015 16:23:53 -0700 Message-ID: From: Martin Thomson To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: multipart/alternative; boundary=001a1147585283ddcf051af23f48 Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 23:23:55 -0000 --001a1147585283ddcf051af23f48 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 July 2015 at 15:18, Blumenthal, Uri - 0553 - MITLL wrote: > I'd rather not =E2=80=8Elose the 571 curve. I'd like to understand why you think it's worth keeping. --001a1147585283ddcf051af23f48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 15 July 2015 at 15:18, Blumenthal, Uri - 0553 - MITLL = <uri@ll.mit.edu&= gt; wrote:
I'd rather not =E2= =80=8Elose the 571 curve.

I'd like to understand why you think it's worth keeping.
<= /div>
--001a1147585283ddcf051af23f48-- From nobody Wed Jul 15 16:40:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107E41B2EFE for ; Wed, 15 Jul 2015 16:40:06 -0700 (PDT) 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 5NOztwfk8062 for ; Wed, 15 Jul 2015 16:40:04 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE401B2AE6 for ; Wed, 15 Jul 2015 16:40:04 -0700 (PDT) Received: by obbop1 with SMTP id op1so36756146obb.2 for ; Wed, 15 Jul 2015 16:40:04 -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:date :message-id:subject:from:to:cc:content-type; bh=7SL155sZT/lxAi6K8NNthNVYbj6RuM2Ew3wxTSnmq1o=; b=TLP6yPdn6FsFofq0zX+QYdtiStGZy/IRVZskxcjXG5PEAaWcgraXtCIPrHx7wDHLEq LNLxJb3QKG8X/ASUFOko5JnogcktJDxtCA8YhkVD+69m942QuxRgKzqG4KxB5EgKclQO bRWIS229cTlinijBdWaDusEDzBFi3N6vMtprFQmQs5lXcMSoctS1fVuFuXYzS+fcM3mw GdAV8q1RTRVPFAdldJNMkIgIo8lI4RstJiNV/n8UX0+20WnK6j1dxgE3TT8a8XIWvOq5 9URk6XImexMEuoIBWrEEjphrwMQL/ir8+50ug9t5lumlRQ9cGLuF+xxkMSCjHK/Lsq1O vvtQ== X-Gm-Message-State: ALoCoQn1vsIvH50Gnqt2jmiVwGnBiphuy1QrJ1LR8eumoXcQJ/Q2ahMDEa18OZEv8bhRby+2qOiX MIME-Version: 1.0 X-Received: by 10.60.131.238 with SMTP id op14mr2064118oeb.78.1437003604017; Wed, 15 Jul 2015 16:40:04 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Wed, 15 Jul 2015 16:40:03 -0700 (PDT) In-Reply-To: References: <201507151413.22408.davemgarrett@gmail.com> <20150715210637.GT12152@cph.win.tue.nl> <201507151739.27053.davemgarrett@gmail.com> Date: Wed, 15 Jul 2015 19:40:03 -0400 Message-ID: From: Brian Smith To: Tony Arcieri Content-Type: multipart/alternative; boundary=e89a8f5025da5bdd7b051af279fb Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 23:40:06 -0000 --e89a8f5025da5bdd7b051af279fb Content-Type: text/plain; charset=UTF-8 Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett > wrote: > >> It's the most used of the rarely used curves. > > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 > I agree, except that I think we should get rid of P-521 too. Cheers, Brian --e89a8f5025da5bdd7b051af279fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tony= Arcieri <bascule@gmail.com> wrote:
On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett &= lt;davemgarrett= @gmail.com> wrote:
It's the most used= of the rarely used curves.

I think = all "rarely used curves" should be removed from TLS. Specifically= , I think it would make sense for TLS to adopt a curve portfolio like this:=

- CFRG curves (RECOMMENDED): Curve25519, Ed448-Go= ldilocks
- NIST curves (SUPPORTED): P-256, P-384, P-521

I agree, except that I think= we should get rid of P-521 too.

Cheers,
Brian

--e89a8f5025da5bdd7b051af279fb-- From nobody Wed Jul 15 16:47:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B5E1B3278 for ; Wed, 15 Jul 2015 16:47:10 -0700 (PDT) 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 9qLo7G8jEE5u for ; Wed, 15 Jul 2015 16:47:09 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E961B31FD for ; Wed, 15 Jul 2015 16:47:09 -0700 (PDT) Received: by oige126 with SMTP id e126so39695188oig.0 for ; Wed, 15 Jul 2015 16:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=syHmtybqqFU73iDpsqcJ+DqGsuJj5kgfIUmOK1n8wQs=; b=cxPyNOkS9VE9Dp5ui6IhvMQWBRmllxYfARKODsYc1SV3i2zLqusV1nGKMyQZEIbKgn u/rRv3F+1ruy/ThaZQ8R7SmtMtHu7RLn0egynsABB7s1qMSHomuRGTuBZRJRPZptIOm/ iTFxmten6zrE7Yu6v1Cqk3HJ6G/O1MhCR+g1C21sdybcqKzdyHoHe2a9vzOc1lqld5ft xZZbJTbsO1ZmB6oL4EPnO5i4QNnLIESQVb/eJ1lHlDuKq+QaoxGmPdJZCT1S/AQIzQge fPzWb08B9A7rkWgj0WcO1zVaYyg8mI4QM2sj2qCQxCOOuflI7kFCJ0S5KG9ewaLYAgIj hnbQ== X-Received: by 10.182.142.202 with SMTP id ry10mr5967808obb.27.1437004028510; Wed, 15 Jul 2015 16:47:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 16:46:49 -0700 (PDT) In-Reply-To: References: <201507151413.22408.davemgarrett@gmail.com> <20150715210637.GT12152@cph.win.tue.nl> <201507151739.27053.davemgarrett@gmail.com> From: Tony Arcieri Date: Wed, 15 Jul 2015 16:46:49 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a1130caeaa9099c051af292f5 Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 23:47:10 -0000 --001a1130caeaa9099c051af292f5 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote: > I agree, except that I think we should get rid of P-521 too. > I'd be fine with that -- Tony Arcieri --001a1130caeaa9099c051af292f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 4:40 PM, Brian Smith <brian@briansmith.org><= /span> wrote:
I agree, except that I thi= nk we should get rid of P-521 too.

I'd be fine with that

--
=
Tony Arcieri
--001a1130caeaa9099c051af292f5-- From nobody Wed Jul 15 16:53:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112AC1A8731 for ; Wed, 15 Jul 2015 16:53: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 HajiSwfbWqTm for ; Wed, 15 Jul 2015 16:53:36 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13481A8733 for ; Wed, 15 Jul 2015 16:53:35 -0700 (PDT) Received: by wiga1 with SMTP id a1so1632379wig.0 for ; Wed, 15 Jul 2015 16:53: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=XiIw75FKysQYiY6SvPyiVrd/dVBc/xQF0pXfuYI9bUA=; b=jsCcY5E7kG9zJIUfe0FCnXUmsfuUgNFsVJisTBkflcRTv1CtvwQ1Nc8OzxAvwT3hvS mEcKL0G2oE9tmXpBb63L41F+63cl1WlACa3nEUPc0pG0u+ghlW3uUNBLI+Pzj0L2T5A1 XJooNBI8SRwtDA2Rca5/ZTRBBlmzX2gmuZEvlcqi4ljuldU/u9owr6UQzunxmxB592S9 lB6ameonITeEQmlSK2LJiZcEaLvmMSrQz/3uy5KzwK8J4pl33U3+t9qifaLsjY9Ll07E gumci4cVrkoaT2Th8RZ65FADR7frZ8ZaIVW6Smczar4fZs3fC6+XK4tNUxmM2ayk7mkI J86A== X-Gm-Message-State: ALoCoQn2CoUTCe8kqnY49GsqtyRASYjUzXMOwzBBSo8pNpovP20EFLtFyQuwm7GeyVyXHSpZ3u7a X-Received: by 10.180.99.39 with SMTP id en7mr1162734wib.31.1437004414763; Wed, 15 Jul 2015 16:53:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Wed, 15 Jul 2015 16:52:55 -0700 (PDT) In-Reply-To: References: <201507151413.22408.davemgarrett@gmail.com> <20150715210637.GT12152@cph.win.tue.nl> <201507151739.27053.davemgarrett@gmail.com> From: Eric Rescorla Date: Wed, 15 Jul 2015 16:52:55 -0700 Message-ID: To: Tony Arcieri Content-Type: multipart/alternative; boundary=f46d04182808aed80c051af2a90d Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 23:53:38 -0000 --f46d04182808aed80c051af2a90d Content-Type: text/plain; charset=UTF-8 I don't feel really strongly about this, but I'd prefer to keep P-521. I suggest we remove sect571tr1 now and then we can debate P-521 later. -Ekr On Wed, Jul 15, 2015 at 4:46 PM, Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote: > >> I agree, except that I think we should get rid of P-521 too. >> > > I'd be fine with that > > -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f46d04182808aed80c051af2a90d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't feel really strongly about this, but I'd p= refer to keep P-521.

I suggest we remove sect571tr1 now = and then we can debate P-521 later.

-Ekr


= On Wed, Jul 15, 2015 at 4:46 PM, Tony Arcieri <bascule@gmail.com> wrote:
On Wed, Jul 15= , 2015 at 4:40 PM, Brian Smith <brian@briansmith.org> wro= te:
I agree, except that I think we shou= ld get rid of P-521 too.

I'd be fine with that

<= font color=3D"#888888">--
Tony Arcieri

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


--f46d04182808aed80c051af2a90d-- From nobody Wed Jul 15 17:10:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCC11A1B5A for ; Wed, 15 Jul 2015 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 n5QSOrD5E2eW for ; Wed, 15 Jul 2015 17:10:33 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF22D1A8861 for ; Wed, 15 Jul 2015 17:10:32 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t6G0AUHs008327; Wed, 15 Jul 2015 20:10:30 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Brian Smith Thread-Topic: [TLS] sect571r1 Thread-Index: AdC/W9L2JSx8WBrRi0ybYAg/tRHgxw== Date: Thu, 16 Jul 2015 00:10:29 +0000 Message-ID: <20150716001036.17764416.75486.9550@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1186910850==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-15_07:2015-07-15,2015-07-15,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-1506180000 definitions=main-1507150318 Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 00:10:35 -0000 --===============1186910850== Content-Type: multipart/alternative; boundary="===============1173953695==" MIME-Version: 1.0 --===============1173953695== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhpcyBJIGFic29sdXRlbHkgY2Fubm90IGFncmVlLiBQNTIxIG11c3Qgc3RheSwgYXMgcGFydCBv ZiB0aGUgc3VwcG9ydGVkIE5JU1Qgc3RhbmRhcmQgKHdoaWNoIEJUVyB3ZSB1c2UpLgoKU2VudMKg ZnJvbcKgbXnCoEJsYWNrQmVycnnCoDEwwqBzbWFydHBob25lwqBvbsKgdGhlIFZlcml6b27CoFdp cmVsZXNzwqA0R8KgTFRFwqBuZXR3b3JrLgpGcm9tOiBCcmlhbiBTbWl0aOKAjgpTZW50OiBXZWRu ZXNkYXksIEp1bHkgMTUsIDIwMTUgMTk6NDAKVG86IFRvbnkgQXJjaWVyaeKAjgpDYzogPHRsc0Bp ZXRmLm9yZz4KU3ViamVjdDogUmU6IFtUTFNdIHNlY3Q1NzFyMQrigI4KVG9ueSBBcmNpZXJpIDxi YXNjdWxlQGdtYWlsLmNvbT4gd3JvdGU6Ck9uIFdlZCwgSnVsIDE1LCAyMDE1IGF0IDI6MzkgUE0s IERhdmUgR2FycmV0dCA8ZGF2ZW1nYXJyZXR0QGdtYWlsLmNvbT4gd3JvdGU6Ckl0J3MgdGhlIG1v c3QgdXNlZCBvZiB0aGUgcmFyZWx5IHVzZWQgY3VydmVzLgoKSSB0aGluayBhbGwgInJhcmVseSB1 c2VkIGN1cnZlcyIgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSBUTFMuIFNwZWNpZmljYWxseSwgSSB0 aGluayBpdCB3b3VsZCBtYWtlIHNlbnNlIGZvciBUTFMgdG8gYWRvcHQgYSBjdXJ2ZSBwb3J0Zm9s aW8gbGlrZSB0aGlzOgoKLSBDRlJHIGN1cnZlcyAoUkVDT01NRU5ERUQpOiBDdXJ2ZTI1NTE5LCBF ZDQ0OC1Hb2xkaWxvY2tzCi0gTklTVCBjdXJ2ZXMgKFNVUFBPUlRFRCk6IFAtMjU2LCBQLTM4NCwg UC01MjEKCkkgYWdyZWUsIGV4Y2VwdCB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGdldCByaWQgb2Yg UC01MjEgdG9vLgoKQ2hlZXJzLApCcmlhbgoKCg== --===============1173953695== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
This I absolute= ly cannot agree. P521 must stay, as part of the supported NIST standard (wh= ich BTW we use).
= =

= =
=
Sent f= rom my BlackBerry 10 smartphone on the V= erizon Wireless 4G LTE network.
= = = =
=
From: Br= ian Smith=E2=80=8E
Sent: Wednesday, July 15, 2015 19:40
To: Tony Arcieri=E2=80=8E
Cc: <tls@ietf.= org>
Subject: Re: [TLS] sect571r1
=E2=80=8E
Tony Arcieri <bascule@gmail.com> wrote:
On Wed, Jul 15, 2015 at 2:39 PM, Dave Garr= ett <davemga= rrett@gmail.com> wrote:
It's the most used of the rarely used curves.
I think all "rarely used curves" should be removed from TLS. Specifica= lly, I think it would make sense for TLS to adopt a curve portfolio like th= is:

- CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks
- NIST curves (SUPPORTED): P-256, P-384, P-521

I agree, except that I think we should get rid of P-521 too.

Cheers,
Brian


--===============1173953695==-- --===============1186910850== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcxNjAwMTAzNVowLwYJKoZIhvcNAQkEMSIEIMyc3N2sVHLD nZVqM2KiBx7UOJPBOS+mBZ1dFAltlyg/MAsGCSqGSIb3DQEBCwSCAQAmWcR4geIa6Ibu3u5lIurM UwlLw4espHpIucZQn1ytL1SIPteuiFjAbK5ei9aNffpK3ssCuaQZG5LZnScxXY8BbvBBsfgdjz+T Uc2qGWnr/IwaR1A4Pm7nGczwkjlf147cwOoKjHlzjkSMoVB61sPWLySntEwkBSa8dEwSht4Cq3vN TYwlVyQw3DJoUMGePlmw6JUVT8ZfFWd22wG6aFXvn/rrOGdTjCACriKF6VTecm3TtrYStDUBK4e2 u5UF1D6z1KSrlTPexl36JEkF4uiIO9yWh5XWn3pEVLNu/FuRuHLazb1IuUh/u/uIgW28jADw8omE Z0zxJ7/Ywr7ue5KEAAAAAAAA --===============1186910850==-- From nobody Wed Jul 15 17:21:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F412E1B2AD4 for ; Wed, 15 Jul 2015 17:21:00 -0700 (PDT) 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 QE4WMNJBmJfv for ; Wed, 15 Jul 2015 17:20:58 -0700 (PDT) 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 A23BB1B2AD3 for ; Wed, 15 Jul 2015 17:20:58 -0700 (PDT) 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 A35482B998; Thu, 16 Jul 2015 02:20:56 +0200 (CEST) X-purgate-ID: 152705::1437006056-00000B48-76DFC12D/0/0 X-purgate-size: 1288 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9559840572; Thu, 16 Jul 2015 02:20:56 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8BD691A1E9; Thu, 16 Jul 2015 02:20:56 +0200 (CEST) In-Reply-To: To: Tony Arcieri Date: Thu, 16 Jul 2015 02:20:56 +0200 (CEST) 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: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 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, 16 Jul 2015 00:21:01 -0000 Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] > Dave Garrett wrote: >> >> It's the most used of the rarely used curves. > > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 P-256 and P-384 seem to be pretty important to some folks (those with a NIST/NSA Suite B checklist). I'm OK with P-521, but I would prefer to get rid of pretty much all _other_ NIST curves with unexplained parameters, including 571 Either the NIST curves with unexplained constants _are_ backdoored, then you get screwed no matter which one of them you use. Or the NIST curves are OK, then P-521 will be good enough. IMO. -Martin Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521), and MSIE 10 exhibits a curious behaviour on my Win7 machine: when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello with P-521 as the first curve in the named_curve extension. when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello with P-256 as the first curve in the named_curve extension. From nobody Wed Jul 15 18:42:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138941B2CEF for ; Wed, 15 Jul 2015 18:42:31 -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 JgBUYwa28d4A for ; Wed, 15 Jul 2015 18:42:29 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420381B2CD8 for ; Wed, 15 Jul 2015 18:42:29 -0700 (PDT) Received: by ieik3 with SMTP id k3so46631542iei.3 for ; Wed, 15 Jul 2015 18:42:28 -0700 (PDT) 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=KzT26AuQTKtWDLpeTko4d9T7iNjhKKdsH56k3wKmrdI=; b=Awk0zakgAoXsbajMybIS0XVezsY59pESlUUV9wy0nBRhUmPY7EfqYEi1qzRCyrfrex ECNDr31XwLWhDkE+A99Y0RCeMmapZYJ0iXhCuqj4j29LYz2d+NMCgrJGHD+FdjF0uq08 DY53cIDVLiPrZ4xVlu/x7vnGNENJ3MkOlm8ExqUs7XConsqsVZAyWWmrmsGUQ/PPnWKi nTR5kE8nZUUik9QqbLMlp6Du6+qdcNAK4DO1VBi36+MqLHBCqvw8xwRWqDYqJARvAnB2 UyLx/mrEU8OeaD7RlMGKlGjVfavCRE2n10wzRUf4oTenx2zGlZHDvjXpDs/bXdMVYokA EVBA== X-Received: by 10.107.3.33 with SMTP id 33mr8587889iod.132.1437010948740; Wed, 15 Jul 2015 18:42:28 -0700 (PDT) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by smtp.gmail.com with ESMTPSA id ji7sm555598igb.2.2015.07.15.18.42.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2015 18:42:27 -0700 (PDT) Message-ID: <55A70C01.8010907@gmail.com> Date: Wed, 15 Jul 2015 21:42:25 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: mrex@sap.com, Tony Arcieri References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> In-Reply-To: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 01:42:31 -0000 Dear colleagues: It seems prudent to keep some diversity of the gene pool and not only have curves defined over prime curves. Similarly, one should perhaps have some diversity of gene pool criteria within the set of recommend curves and not only include special primes. Should some problem with a particular subclass show up over time, one then at least has other classes available. On a general note, I do not understand what is wrong with having a dictionary of curves that is well-specified, but whose members are not all widely used. To my knowledge, having a dictionary does not force everyone to use every term in this (mandatory vs. optional to implement vs. mandatory to use, etc.). If one follows the line of reasoning of some people on the mailing list earlier today, doesn't this also call into question Brainpool curves, or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into question why one would have a whole set of new DLP groups (which certainly cannot be widely used yet, since the ink to write the parameters down is still wet). What about RSA-1024, etc.? I would suggest one to have a clear criteria by which to judge inclusion/exclusion of cryptographic algorithms. As a final note: if one can define curves explicitly, then removing these from a list does not really remove them, except "pestering" people who would like to use them by forcing sending big chunks of descriptive text instead of short-hand references. Best regards, Rene On 7/15/2015 8:20 PM, Martin Rex wrote: > Tony Arcieri wrote: > [ Charset UTF-8 unsupported, converting... ] >> Dave Garrett wrote: >>> It's the most used of the rarely used curves. >> >> I think all "rarely used curves" should be removed from TLS. Specifically, >> I think it would make sense for TLS to adopt a curve portfolio like this: >> >> - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks >> - NIST curves (SUPPORTED): P-256, P-384, P-521 > P-256 and P-384 seem to be pretty important to some folks > (those with a NIST/NSA Suite B checklist). I'm OK with P-521, > but I would prefer to get rid of pretty much all _other_ > NIST curves with unexplained parameters, including 571 > > Either the NIST curves with unexplained constants _are_ backdoored, > then you get screwed no matter which one of them you use. > Or the NIST curves are OK, then P-521 will be good enough. IMO. > > -Martin > > > Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521), > and MSIE 10 exhibits a curious behaviour on my Win7 machine: > when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello > with P-521 as the first curve in the named_curve extension. > when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello > with P-256 as the first curve in the named_curve extension. > > _______________________________________________ > 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 Jul 15 18:42:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129BD1B2CDB for ; Wed, 15 Jul 2015 18:42:55 -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 RM89_mhkHK0K for ; Wed, 15 Jul 2015 18:42:53 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC661B2CD8 for ; Wed, 15 Jul 2015 18:42:53 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 15 Jul 2015 21:42:53 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Wed, 15 Jul 2015 21:42:52 -0400 From: Dan Brown To: Martin Rex , Tony Arcieri Thread-Topic: [TLS] sect571r1 Thread-Index: AQHQv0IwQsvdAJpzLEuyOkTGR5u8jJ3dUfsAgAAHmICAACWHAP//09Vm Date: Thu, 16 Jul 2015 01:42:51 +0000 Message-ID: <20150716014248.5333071.47478.4400@certicom.com> References: , <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> In-Reply-To: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 01:42:55 -0000 Binary curves have some risks, due to recent work of Semaev on subexponenti= al ECDLP, building on much past work. Even so, there's an argument from Koblitz and Menezes that special curves (= e.g. binary curves) may survive some wider collapse. I think it's a weak ar= gument, but for those for whom supporting more curves is easy, it could jus= tify supporting a diversity of curves. What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way it= has no unexplained constants...). Has it been removed already, or does the= question also refer K-571 too? The issue of malicious curves seems off-topic to this thread about max curv= e size, so briefly, to respond to the issue of unexplained constants it is = a difficult issue, which CFRG is working on, and NIST too. My thought here = is Brainpool deals best with this issue, so far, but it is a far-fetched is= sue, and other security issues are at least as important. Original Message From: Martin Rex Sent: Wednesday, July 15, 2015 8:21 PM To: Tony Arcieri Reply To: mrex@sap.com Cc: Subject: Re: [TLS] sect571r1 Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] > Dave Garrett wrote: >> >> It's the most used of the rarely used curves. > > > I think all "rarely used curves" should be removed from TLS. Specifically= , > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 P-256 and P-384 seem to be pretty important to some folks (those with a NIST/NSA Suite B checklist). I'm OK with P-521, but I would prefer to get rid of pretty much all _other_ NIST curves with unexplained parameters, including 571 Either the NIST curves with unexplained constants _are_ backdoored, then you get screwed no matter which one of them you use. Or the NIST curves are OK, then P-521 will be good enough. IMO. -Martin Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521)= , and MSIE 10 exhibits a curious behaviour on my Win7 machine: when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello with P-521 as the first curve in the named_curve extension. when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello with P-256 as the first curve in the named_curve extension. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 15 18:47:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4506A1B2D0C for ; Wed, 15 Jul 2015 18:47:19 -0700 (PDT) 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 tuXswWqh4p23 for ; Wed, 15 Jul 2015 18:47:18 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E574D1B2D08 for ; Wed, 15 Jul 2015 18:47:17 -0700 (PDT) Received: by oihq81 with SMTP id q81so41107839oih.2 for ; Wed, 15 Jul 2015 18:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7wfTr4T1hxmtrzrhviywFYZjf8X4LNbONG0OlopuKXw=; b=j2G7iu3l0Cbs/7I+SPN6LsoqFEGpcRqHZBmxyiN1zUPBcwMesOb2hwU3fFgxTbQVJh OnIlZhMF037clZDYe0xqgsqmCneU2yom+ssMhTpaHrOzTpt8vC3Tsiyr+lBsGPVhBN63 J+p1LH94Rw+JWxB4dNpsDboMP9QvcbhNdvaeucggXHP4tQziU0F3WZnjhtiWCltFCfYM /J9ZqXF7N6PjIlLLGHq08Bgz9nBgNcWtdsgB7zf2dkGdX985vbj1uYKivNWFvYLlzQH8 BBnMvWCsAGdF/JV6cTz/BQM7vrs4ozGfsm/YzZ8b7kcMuWsMe0fIYb1G6SZ5nwU2e5PC /B9A== X-Received: by 10.202.1.67 with SMTP id 64mr6060429oib.6.1437011237469; Wed, 15 Jul 2015 18:47:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 18:46:58 -0700 (PDT) In-Reply-To: <20150716014248.5333071.47478.4400@certicom.com> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <20150716014248.5333071.47478.4400@certicom.com> From: Tony Arcieri Date: Wed, 15 Jul 2015 18:46:58 -0700 Message-ID: To: Dan Brown Content-Type: multipart/alternative; boundary=001a1137d51c59048d051af440ec Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 01:47:19 -0000 --001a1137d51c59048d051af440ec Content-Type: text/plain; charset=UTF-8 On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown wrote: > Even so, there's an argument from Koblitz and Menezes that special curves > (e.g. binary curves) may survive some wider collapse. I think it's a weak > argument, but for those for whom supporting more curves is easy, it could > justify supporting a diversity of curves. Others are pushing FFDHE in the event of some ECC disaster. I'm not really a fan of that either (all these things add attack surface in addition to being "backups"), but if we're going to keep a little used thing around in our pocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE? -- Tony Arcieri --001a1137d51c59048d051af440ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 6:42 PM, Dan Brown <dbrown@certicom.com> wrote:
Even so, there's an argumen= t from Koblitz and Menezes that special curves (e.g. binary curves) may sur= vive some wider collapse. I think it's a weak argument, but for those f= or whom supporting more curves is easy, it could justify supporting a diver= sity of curves.

Others are pushing FFDHE in= the event of some ECC disaster. I'm not really a fan of that either (a= ll these things add attack surface in addition to being "backups"= ), but if we're going to keep a little used thing around in our pocket = just in case of an ECC disaster, why do we need backup curves in addition t= o FFDHE?

--
To= ny Arcieri
--001a1137d51c59048d051af440ec-- From nobody Wed Jul 15 18:49:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735E11B2D15 for ; Wed, 15 Jul 2015 18:49:04 -0700 (PDT) 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 hSKq-AVEF5Dv for ; Wed, 15 Jul 2015 18:49:03 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22DE1B2D0D for ; Wed, 15 Jul 2015 18:49:02 -0700 (PDT) Received: by oibn4 with SMTP id n4so41138189oib.3 for ; Wed, 15 Jul 2015 18:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=27vhwafLCAm2tBGfQrki6+LA/ygIqZ2NyhAYCMWE0Kc=; b=jCJchDzw/ylyWFFadGXrj5gHYLR38jUHIW6FASA7DBigY3zDdpFtuG8vuF1jb25PaG uU/HlqQn5e5Nx/naW86h3P3ovdsGS7QQHkq8Tj43zEvurHDVmDUcynK8vmFbKwxUAVwz 9eUNE7rAY7eaF9E5EwtHOrDm2pT7eZjFmn9T35C+5uWIKYYv1nVfEiGTZ8MADmC6IKnf WL9zYKhBvmxc0UAOJef0fcOQt0uN2B6iUlh7kqgGmj1R/UGuwrNoDggIdKDPwelnAMOd 2/5BUcvM6pun5wp0YQiGuu+CPal2DOMmA83vLi0Z+EXTrrvmqP0UAnJOkRMjKG8MNM5t TsAg== X-Received: by 10.202.52.138 with SMTP id b132mr6073877oia.125.1437011342279; Wed, 15 Jul 2015 18:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 18:48:42 -0700 (PDT) In-Reply-To: <55A70C01.8010907@gmail.com> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55A70C01.8010907@gmail.com> From: Tony Arcieri Date: Wed, 15 Jul 2015 18:48:42 -0700 Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=001a113d3e02984b82051af44605 Archived-At: Cc: "" Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 01:49:04 -0000 --001a113d3e02984b82051af44605 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik wrote: > Dear colleagues: > > It seems prudent to keep some diversity of the gene pool and not only have > curves defined over prime curves. Similarly, one should perhaps have some > diversity of gene pool criteria within the set of recommend curves and not > only include special primes. Should some problem with a particular subclass > show up over time, one then at least has other classes available. I just responded to Dan Brown with this, but it applies here as well: ---------- Forwarded message ---------- From: Tony Arcieri Date: Wed, Jul 15, 2015 at 6:46 PM Subject: Re: [TLS] sect571r1 To: Dan Brown Cc: Martin Rex , "" On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown wrote: > Even so, there's an argument from Koblitz and Menezes that special curves > (e.g. binary curves) may survive some wider collapse. I think it's a weak > argument, but for those for whom supporting more curves is easy, it could > justify supporting a diversity of curves. Others are pushing FFDHE in the event of some ECC disaster. I'm not really a fan of that either (all these things add attack surface in addition to being "backups"), but if we're going to keep a little used thing around in our pocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE? -- Tony Arcieri --001a113d3e02984b82051af44605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 6:42 PM, Rene Struik <rstruik.ext@gmail.com>= ; wrote:
Dear colleagues:

It seems prudent to keep some diversity of the gene pool and not only have = curves defined over prime curves. Similarly, one should perhaps have some d= iversity of gene pool criteria within the set of recommend curves and not o= nly include special primes. Should some problem with a particular subclass = show up over time, one then at least has other classes available.

I just responded to Dan Brown with this, but it appl= ies here as well:

---------- Forwarded message --------= --
From:=C2=A0Tony Arcieri=C2=A0<bascule@gmail.com&= gt;
Date: Wed, Jul 15, 2015 at 6:46 PM
Subject: Re: [TLS] sect= 571r1
To: Dan Brown <dbrown@ce= rticom.com>
Cc: Martin Rex <mr= ex@sap.com>, "<tls@ietf.org<= /a>>" <tls@ietf.org>
<= br>
On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown=C2=A0<dbr= own@certicom.com>=C2=A0wrote:
Even so, th= ere's an argument from Koblitz and Menezes that special curves (e.g. bi= nary curves) may survive some wider collapse. I think it's a weak argum= ent, but for those for whom supporting more curves is easy, it could justif= y supporting a diversity of curves.

Others are pushing FFDHE in the event of some ECC disaste= r. I'm not really a fan of that either (all these things add attack sur= face in addition to being "backups"), but if we're going to k= eep a little used thing around in our pocket just in case of an ECC disaste= r, why do we need backup curves in addition to FFDHE?=C2=A0

--
Tony Arcieri
--001a113d3e02984b82051af44605-- From nobody Wed Jul 15 19:02:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649191B2D72 for ; Wed, 15 Jul 2015 19:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wKIfP1XiiNe0 for ; Wed, 15 Jul 2015 19:02:29 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D12D71B2D0B for ; Wed, 15 Jul 2015 19:02:28 -0700 (PDT) Received: from smtp-pop.rim.net (HELO XCT104CNC.rim.net) ([10.65.161.204]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 15 Jul 2015 22:02:27 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 15 Jul 2015 22:02:27 -0400 From: Dan Brown To: Tony Arcieri Thread-Topic: [TLS] sect571r1 Thread-Index: AQHQv0IwQsvdAJpzLEuyOkTGR5u8jJ3dUfsAgAAHmICAACWHAP//09VmgABENAD//8FFvA== Date: Thu, 16 Jul 2015 02:02:26 +0000 Message-ID: <20150716020223.5333071.63455.4405@certicom.com> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <20150716014248.5333071.47478.4400@certicom.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201507160202235333071634554405certicomcom_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 02:02:30 -0000 --_000_201507160202235333071634554405certicomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FFDHE with prime field is one big step away from FFDHE with binary field, w= hich has quasipoly time DLP, so that's quite a large risk. ECDHE with binary field is also one big step away from binary FFDHE, but it= 's a different type of step: hence diversity. I agree that diversity risks weakest link. Ideally, the rainy day backups s= hould be disabled by default, but possible to quickly enable, by administra= tor configuration or patch. From: Tony Arcieri Sent: Wednesday, July 15, 2015 9:47 PM To: Dan Brown Cc: Martin Rex; Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown > wrote: Even so, there's an argument from Koblitz and Menezes that special curves (= e.g. binary curves) may survive some wider collapse. I think it's a weak ar= gument, but for those for whom supporting more curves is easy, it could jus= tify supporting a diversity of curves. Others are pushing FFDHE in the event of some ECC disaster. I'm not really = a fan of that either (all these things add attack surface in addition to be= ing "backups"), but if we're going to keep a little used thing around in ou= r pocket just in case of an ECC disaster, why do we need backup curves in a= ddition to FFDHE? -- Tony Arcieri --_000_201507160202235333071634554405certicomcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: Tony Arcieri
Sent: Wednesday, July 15, 2015 9:47 PM
To: Dan Brown
Cc: Martin Rex; <tls@ietf.org>
Subject: Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown <dbrown@certico= m.com> wrote:
Even so, there's an argument from Koblitz and Menezes that special curves (= e.g. binary curves) may survive some wider collapse. I think it's a weak ar= gument, but for those for whom supporting more curves is easy, it could jus= tify supporting a diversity of curves.

Others are pushing FFDHE in the event of some ECC disaster. I'm not re= ally a fan of that either (all these things add attack surface in addition = to being "backups"), but if we're going to keep a little used thi= ng around in our pocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE?

--
Tony Arcieri
--_000_201507160202235333071634554405certicomcom_-- From nobody Wed Jul 15 19:27:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543071B34ED for ; Wed, 15 Jul 2015 19:27:13 -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 qFDEk2Qeq6na for ; Wed, 15 Jul 2015 19:27:11 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AF61B34EC for ; Wed, 15 Jul 2015 19:27:11 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so3618659igb.0 for ; Wed, 15 Jul 2015 19:27:11 -0700 (PDT) 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=Ry+7lhsvr64l/VPhEu2Opuql4YpCfwlvQHpQBDLUhD8=; b=LqDJdpa1qPe2iBk+++Cgqiii42S5rB9xcF+PeNu+QyU9Jm35wBacBs06MI7fRK+fu7 n1J7ADB9QLF9CHloqAb179lPGT7iYyLEM/TMvd23/B6/Y46qoI+hjTdlZkf3m9L7ybGh 1tqqjcjtNBoH25TZQ5+vhPQWkD33gWq8tLIWsdiUa42PZwWqmtqqSs7eS7uER+yc877k ey8rF84nccnk1YFAby3yeLj/VMU+BMlt+zUFrw/v4R7cEL7Jx8r+c5NABRuGKe/fJ21e XLdNfuYYKPgQBEITToiSAkc5vsTKpIn4U4QrLkE8cn6eJimPkf7KEjALvJEQvCBPNQGC ylEw== MIME-Version: 1.0 X-Received: by 10.50.73.165 with SMTP id m5mr1410429igv.60.1437013631092; Wed, 15 Jul 2015 19:27:11 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 15 Jul 2015 19:27:11 -0700 (PDT) In-Reply-To: <55A70C01.8010907@gmail.com> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55A70C01.8010907@gmail.com> Date: Wed, 15 Jul 2015 22:27:11 -0400 Message-ID: From: Jeffrey Walton To: Rene Struik Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 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: Thu, 16 Jul 2015 02:27:13 -0000 > It seems prudent to keep some diversity of the gene pool and not only have > curves defined over prime curves. Similarly, one should perhaps have some > diversity of gene pool criteria within the set of recommend curves and not > only include special primes. Should some problem with a particular subclass > show up over time, one then at least has other classes available. > > On a general note, I do not understand what is wrong with having a > dictionary of curves that is well-specified, but whose members are not all > widely used. To my knowledge, having a dictionary does not force everyone to > use every term in this (mandatory vs. optional to implement vs. mandatory to > use, etc.). Related, see Dan Geer's "Heartbleed as Metaphor", http://www.lawfareblog.com/heartbleed-metaphor. Geer says, "Nature teaches that monocultures are so unnatural as to require constant intervention to maintain." Jeff From nobody Wed Jul 15 19:31:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1D1B3517 for ; Wed, 15 Jul 2015 19:31:33 -0700 (PDT) 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 H3u4yQ33oqeJ for ; Wed, 15 Jul 2015 19:31:32 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2669C1B3508 for ; Wed, 15 Jul 2015 19:31:32 -0700 (PDT) Received: by oige126 with SMTP id e126so41603404oig.0 for ; Wed, 15 Jul 2015 19:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7YBCZb+VeHESCfxyqZ/P4/N59F5wjU9HWxCrJmBYLiA=; b=gJuTn4MsK25czrzsjFLk4uaS+pbyR8d6wtLaqlFFlp37HlFLPcwmcMPwunjNQXCNmL hib3NLE+AME9OhwDcNVZZkDrKjUpKsN7pC4oBiDjnI7sNPRNdsGzHImnysgGpJf8yvcK pdGqsNHXUDLwTNS3P4+YSh55SIwpMLxk8AyUs0p0JAvIe7WdqR4aa4d6DjwLLPKCk4tF i6VRbTo5ImQYB/91xWcix6s7bf+Q9ttSOCMlsVFSEpiqkh72RaeJb2KeXIlSwKiMGun6 g2FumUmcPO0UYZSdQLMttPKvPDdnCkg/JpNOf34o6XU4EKtY5nDUhXb3WHIy5NFS/GJv hrLg== X-Received: by 10.60.79.193 with SMTP id l1mr6343700oex.60.1437013891620; Wed, 15 Jul 2015 19:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 19:31:12 -0700 (PDT) In-Reply-To: <55A70C01.8010907@gmail.com> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55A70C01.8010907@gmail.com> From: Tony Arcieri Date: Wed, 15 Jul 2015 19:31:12 -0700 Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=089e011773738c27cd051af4dea4 Archived-At: Cc: "" Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 02:31:33 -0000 --089e011773738c27cd051af4dea4 Content-Type: text/plain; charset=UTF-8 To respond more specifically to your concerns: On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik wrote: > It seems prudent to keep some diversity of the gene pool and not only have > curves defined over prime curves. Similarly, one should perhaps have some > diversity of gene pool criteria within the set of recommend curves and not > only include special primes. Should some problem with a particular subclass > show up over time, one then at least has other classes available. > Binary curves in particular are showing warning signs of potential future security issues: https://eprint.iacr.org/2015/310.pdf I think even if we don't completely pare down the TLS curve portfolio to the list I suggested, if nothing else I would like to see binary curves removed. -- Tony Arcieri --089e011773738c27cd051af4dea4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To r= espond more specifically to your concerns:
=
On Wed, Jul 15, 2015 at 6:42 PM, Rene = Struik <rstruik.ext@gmail.com= > wrote:
It seems prudent to keep some di= versity of the gene pool and not only have curves defined over prime curves= . Similarly, one should perhaps have some diversity of gene pool criteria w= ithin the set of recommend curves and not only include special primes. Shou= ld some problem with a particular subclass show up over time, one then at l= east has other classes available.

Binar= y curves in particular are showing warning signs of potential future securi= ty issues:


I think even if we don't completely pare down the TLS curve portfolio = to the list I suggested, if nothing else I would like to see binary curves = removed.

--
Tony Arcieri
--089e011773738c27cd051af4dea4-- From nobody Wed Jul 15 19:43:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C534B1B35A2 for ; Wed, 15 Jul 2015 19:42:59 -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 stBid6Yb5dqr for ; Wed, 15 Jul 2015 19:42:58 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAA61B359E for ; Wed, 15 Jul 2015 19:42:58 -0700 (PDT) Received: by qkdl129 with SMTP id l129so42024663qkd.0 for ; Wed, 15 Jul 2015 19:42:57 -0700 (PDT) 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=h65lg71Ax5dXnszPATB0jqvmIUS0T+hGbEGsORbjUz0=; b=rjHyeKnGMFOEQgCaMCRkNFmwKE00BfKTGFlJArgUuVGIoBowpkxCRRDlQCTSgB3Ya0 UluEKFF1LkMl3AoUGXM9nXbNNDqMvdT4UeR5vXZUS+9IN79eXgINhsFooYchjWG3C9yW 5XImPJLNYQpAvSMzTwoslOYSFKi41WjTmxKr35gFWycqPHiMeMDKAjtIF5g792gANghG gY9uAKw+Ie3jOpG0UHvqF7xhzJQ0kofI5orkYIHYtsSomJxtcRvFwoF8ShJs5fPDuOS9 eO78kbfB58YAksxdKXL3ymmMTYV0PgkYkiuMRZ2YOHyOKmzmuf+2y+lXoekNLnDiZTRV bZ1Q== X-Received: by 10.140.19.82 with SMTP id 76mr13589002qgg.55.1437014577557; Wed, 15 Jul 2015 19:42:57 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id e78sm3306523qhc.18.2015.07.15.19.42.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 19:42:56 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Dan Brown Date: Wed, 15 Jul 2015 22:42:54 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <20150716014248.5333071.47478.4400@certicom.com> In-Reply-To: <20150716014248.5333071.47478.4400@certicom.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507152242.55454.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 02:42:59 -0000 On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote: > What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way it has no unexplained constants...). Has it been removed already, or does the question also refer K-571 too? Already dropped. That's obviously not irreversible, but it's unambiguously in the virtually unused camp. The initial goal was to drop all largely unused curves. This question is just about sect571r1, which is far closer to secp384r1 & secp521r1 in terms of usage, though still notably less. If you want to argue for going with sect571k1 and not sect571r1, I don't think the WG is on-board with that. Even if we continued to allow it, I doubt much would add support for it to be worthwhile. The scan I linked to found one; literally a single server on the entire Internet, that actually supports sect571k1 for ECDHE. The stats also show 1575 "support" it, so I'm not sure what's going on there specifically. (if someone can explain this bit of those stats, please do) https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/ Dave From nobody Wed Jul 15 19:49:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220851B35D1 for ; Wed, 15 Jul 2015 19:49:45 -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 2w97zEV-MRte for ; Wed, 15 Jul 2015 19:49:44 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C798F1B35CF for ; Wed, 15 Jul 2015 19:49:43 -0700 (PDT) Received: by qgee109 with SMTP id e109so4955635qge.0 for ; Wed, 15 Jul 2015 19:49:43 -0700 (PDT) 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=IhVUd261YpEmihwTKpZoyIidKQ/KBS1Gs0XGLmrW15w=; b=YLUgxpt3I2h9ZQzyrzKGhxce1d5s0JEsJdeuDtzolZzFZYCh2ezZ7z3ph50sR42YMZ K4f+boVCIjVXGpLVx9lNudexyCAUy80heJTS52dkfrsPy7iAhybDxKawtJWIEbHq3F0u mblmLlLzh8hm6QqztkJy1y6A3AQcH8s6ooshygP6krclKqp5s7ywsHoNnKimTXkJG1xm UxOWBXJ9iS31hw66P1jxHqb+d37wdETS/rMjD3CaVBfB5XbuDDtvhfCklB82Makyjfir 2UCY7chbJ2HZcUT7I0q/fG2KTKagUXpHef5tTOy+Y6wfuiYmKGb7G8NCz2q8VOnqfr+x f8fw== X-Received: by 10.140.44.73 with SMTP id f67mr13239977qga.88.1437014983152; Wed, 15 Jul 2015 19:49:43 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id b133sm3307966qhc.40.2015.07.15.19.49.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 19:49:42 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Dan Brown Date: Wed, 15 Jul 2015 22:49:40 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150716014248.5333071.47478.4400@certicom.com> <201507152242.55454.davemgarrett@gmail.com> In-Reply-To: <201507152242.55454.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507152249.40999.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 02:49:45 -0000 On Wednesday, July 15, 2015 10:42:54 pm Dave Garrett wrote: > The stats also show 1575 "support" it, so I'm not sure what's going on there specifically. (if someone can explain this bit of those stats, please do) Actually, now that I think about it, it could just be that every single implementation out there prioritizes sect571r1 over sect571k1. So, it has low support, but everything that supports it defaults to sect571r1. Note that both are supported by an order of magnitude fewer servers than secp384r1 and secp521r1. Dave From nobody Wed Jul 15 20:41:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5657C1B2C2F for ; Wed, 15 Jul 2015 20:41:06 -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 peVD2Br3-z3x for ; Wed, 15 Jul 2015 20:41:04 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0A41B2BF1 for ; Wed, 15 Jul 2015 20:41:04 -0700 (PDT) Received: by igvi1 with SMTP id i1so4683710igv.1 for ; Wed, 15 Jul 2015 20:41:04 -0700 (PDT) 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:content-type; bh=Tz8dc2aL5q9AVdrWz9ooqxUSqDg8UZV67fq//bgAJpU=; b=FeqMYMIajvT/qW0A5BNziMneeh6CqFNg6hsgaLywI6j3Z9KbW0lAQxjuLuIOE0p4vT WulESblX9JFf5e/g5FesjTgQYX9HGoIC8N4nexZGk9GPdwmXz5O9nfQ6BwK6cAF/iXKc YvrUfS/sS42z2UkoVRjHDVP4urAxVR9Xxw2zADkps1kxmfkKDbpRiUsWQPGePVxZ9f3q G7fpJ0IVEh0kT+kA65Y1afdk42OeXRxMjiSpyEl4SFG7D8uMuP/krsjHTQRmG4AS4u2H fqSRPovXrEFskDgqVIjxvxIJi7JI0Y00fwFEDp0sDJwxlv6EpIhQk055ICJ5taqBsVt2 656w== MIME-Version: 1.0 X-Received: by 10.50.25.167 with SMTP id d7mr1575239igg.59.1437018063948; Wed, 15 Jul 2015 20:41:03 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 15 Jul 2015 20:41:03 -0700 (PDT) In-Reply-To: <20150715211140.GU28047@mournblade.imrryr.org> References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> Date: Wed, 15 Jul 2015 23:41:03 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] sect571r1 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: Thu, 16 Jul 2015 03:41:06 -0000 >> >> So, should it stay or should it go now? Opinions? >> > >> > +1 that sect571r1 be removed. >> >> I also believe that it should be removed. > > Same here, I think in this case "less is more". There is no > compelling reason for this curve, and needless diversity here is > counter-productive. > It provides 256-bits of security. Its the only curve I am aware that can transport a AES-256 key while maintaining security levels. (I've been through C&A's where matching security levels were examined). From nobody Wed Jul 15 20:49:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89C71B2FB2 for ; Wed, 15 Jul 2015 20:49:08 -0700 (PDT) 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 rayLHXJ3ZErA for ; Wed, 15 Jul 2015 20:49:07 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9A31B2FB1 for ; Wed, 15 Jul 2015 20:49:07 -0700 (PDT) Received: by oige126 with SMTP id e126so42450494oig.0 for ; Wed, 15 Jul 2015 20:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IZ1+JiPpuR3XphII4iNdAANRnpc6b6KQYy6lPq01zMI=; b=ikZvW3G3CBJxp93GobnzZJDUE3gaApv85yhxZUlb1npNwIvBZ6o3w+IaDddMtLkatV kAe+AP2QA6cArw5GoCuUafiBcc25mjC/XA/YsZQTysKG/7v6BFoaH4NWWsPO1eHDn1v0 EjrBP4Qv+bxLOpmTMUIcEziHD41olm2ow8fRhqYTpcMeFpahCA1RdZN1M4wuagxAeYh5 +m2Ee+8tp7AWTpxnDI+bTyab7FL1RRvbjurteCkG4hMW+HckpGj/8lPLCBjXunQ7d6tq QnILxTxZvFKlUtO5MDBEjYyofNavur1uZ8aKIa68GyjIZdzxMiVuii30pL0XFIMV2AGx 6jUg== X-Received: by 10.202.86.215 with SMTP id k206mr6292426oib.13.1437018546957; Wed, 15 Jul 2015 20:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 20:48:47 -0700 (PDT) In-Reply-To: References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> From: Tony Arcieri Date: Wed, 15 Jul 2015 20:48:47 -0700 Message-ID: To: Jeffrey Walton Content-Type: multipart/alternative; boundary=001a113d7ba606f432051af5f485 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 03:49:08 -0000 --001a113d7ba606f432051af5f485 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton wrote: > It provides 256-bits of security. Its the only curve I am aware that > can transport a AES-256 key while maintaining security levels. Why do you think P-521 doesn't provide this? -- Tony Arcieri --001a113d7ba606f432051af5f485 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton <noloader@gmail.com> wrote:
It provides 256-bits of security. Its the only curve I am awa= re that
can transport a AES-256 key while maintaining security levels.
=

Why do you think P-521 doesn't provide this?
<= div>=C2=A0
--
Tony Arcieri
--001a113d7ba606f432051af5f485-- From nobody Wed Jul 15 20:50:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2552F1B2FB8 for ; Wed, 15 Jul 2015 20:50:20 -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 lbslJO4zMZJB for ; Wed, 15 Jul 2015 20:50:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB441B2C68 for ; Wed, 15 Jul 2015 20:50:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AE909284D2B; Thu, 16 Jul 2015 03:50:17 +0000 (UTC) Date: Thu, 16 Jul 2015 03:50:17 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150716035017.GX28047@mournblade.imrryr.org> References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] sect571r1 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: Thu, 16 Jul 2015 03:50:20 -0000 On Wed, Jul 15, 2015 at 11:41:03PM -0400, Jeffrey Walton wrote: > > Same here, I think in this case "less is more". There is no > > compelling reason for this curve, and needless diversity here is > > counter-productive. > > It provides 256-bits of security. Its the only curve I am aware that > can transport a AES-256 key while maintaining security levels. It provides a conjectured security level around 256-bits, as does secp521r1. > (I've been through C&A's where matching security levels were examined). An auditor who believes that we can rigourously quantify the security of these curves precisely enough to say which is stronger or more closely "matches" AES-256, should be laughed out of the room and fired. -- Viktor. From nobody Wed Jul 15 20:52:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0176C1B2FCC for ; Wed, 15 Jul 2015 20:52:15 -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 Sv4ZXHKVN3Ii for ; Wed, 15 Jul 2015 20:52:13 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF541B2FCA for ; Wed, 15 Jul 2015 20:52:13 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so4772176igc.0 for ; Wed, 15 Jul 2015 20:52:13 -0700 (PDT) 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:content-type; bh=nU+RtCCi89+0v6PXVvcHKWX9w173pxxS+aEiKWLWQ4U=; b=MQwdqLt5yK9EeAcz2KR4kL+WLTf3DgAkyIuooWreGt9gPu8FaLPc34JrhhN9dVZBdA QzNE8sLpMfeBm2UPTnc8bEbSA42nDVAbMEgpCYUxNHOQO+2xJxXijrM2jBUIQx/o8lEx gyVvJ0NB9DnJzSyPQ34vJ+ZoFhJqYYjlA/Or1hp1LJNW6VH5IEKUFwrRkIKsrjn8PO2V TtSBkLDHxSphvYta0yT6ccC452iJegN6A5WOrVCRV97rqIbf0UHQUuMlDaFCjqcRMLZZ iutsKGls1U4xnL4hXuL6ZLoVZzaTj0h/e8Cg4Jt9YCV9BFBK0HHF39AJVdOdMfWEGsT4 yUXQ== MIME-Version: 1.0 X-Received: by 10.50.73.170 with SMTP id m10mr682458igv.60.1437018733287; Wed, 15 Jul 2015 20:52:13 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 15 Jul 2015 20:52:13 -0700 (PDT) In-Reply-To: <20150716035017.GX28047@mournblade.imrryr.org> References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> <20150716035017.GX28047@mournblade.imrryr.org> Date: Wed, 15 Jul 2015 23:52:13 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] sect571r1 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: Thu, 16 Jul 2015 03:52:15 -0000 >> (I've been through C&A's where matching security levels were examined). > > An auditor who believes that we can rigourously quantify the security > of these curves precisely enough to say which is stronger or more > closely "matches" AES-256, should be laughed out of the room and fired. > Maybe so, but it is what it is. The IETF is probably not going to be able to change it. Jeff From nobody Wed Jul 15 20:52:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420101B2FCC for ; Wed, 15 Jul 2015 20:52:55 -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 SG0l4Rpwxjdj for ; Wed, 15 Jul 2015 20:52:54 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328FD1B2FAA for ; Wed, 15 Jul 2015 20:52:54 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so4640634igb.0 for ; Wed, 15 Jul 2015 20:52:53 -0700 (PDT) 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=t7Oxa5JoelLXgzw7gYwpzMLSnyHlCzb/fCRVBBl2fPE=; b=d+H1ke6pGz/uK+YvzYt01p4l/p62HYatm1zXqLZGTMGJch+7bPys6KOSrQA2hZzYaO 8myStXBXq/kx1IXLm/TH3X7cAbeJCXlod/0kzvaV0obNMSLODklD4fHqe9GBldmJm3Ax Sfv4bYhlRDg4G0fDkTEp0PP1cYcZ7mmWDg0B/ydzbta0m51I9iwCZXKCVRN6eUZ3cfQ7 oFlTPqeD+98cRdPL9nE/gl8iZJd9gfjw+QoXxXcsxz0t76R/Fef41/x0l0rQ/zFNEHOe Vj4btGoR9jfjPVphcjpTgtjRVBsQe1tHLCu/UaeUBXYXlDZwSAScifKJVRi9VvFllkzl Xc7A== MIME-Version: 1.0 X-Received: by 10.50.25.167 with SMTP id d7mr1618683igg.59.1437018773617; Wed, 15 Jul 2015 20:52:53 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 15 Jul 2015 20:52:53 -0700 (PDT) In-Reply-To: References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> Date: Wed, 15 Jul 2015 23:52:53 -0400 Message-ID: From: Jeffrey Walton To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] sect571r1 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: Thu, 16 Jul 2015 03:52:55 -0000 On Wed, Jul 15, 2015 at 11:48 PM, Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton wrote: >> >> It provides 256-bits of security. Its the only curve I am aware that >> can transport a AES-256 key while maintaining security levels. > > Why do you think P-521 doesn't provide this? My bad... I meant over the binary curves. Jeff From nobody Wed Jul 15 21:07:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0A1B3012 for ; Wed, 15 Jul 2015 21:07:32 -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 il3re6z6_i2t for ; Wed, 15 Jul 2015 21:07:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320FF1B3010 for ; Wed, 15 Jul 2015 21:07:28 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4AEDB284D2B; Thu, 16 Jul 2015 04:07:27 +0000 (UTC) Date: Thu, 16 Jul 2015 04:07:27 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150716040727.GY28047@mournblade.imrryr.org> References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> <20150716035017.GX28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] sect571r1 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: Thu, 16 Jul 2015 04:07:32 -0000 On Wed, Jul 15, 2015 at 11:52:13PM -0400, Jeffrey Walton wrote: > > An auditor who believes that we can rigourously quantify the security > > of these curves precisely enough to say which is stronger or more > > closely "matches" AES-256, should be laughed out of the room and fired. > > Maybe so, but it is what it is. The IETF is probably not going to be > able to change it. Well, the auditor can't ask for curves with TLS that the specification deprecates. So removing oddball choices will help users fend off clueless checklist-wielding auditors. A modest amount of diversity is fine, but I would posit that anything beyond a (conservative, performant, backup) triple is counterproductive. Between the anticipated CFRG curves and the NIST prime curves, I think we already have a couple too many. The way I see it: conservative = Goldilocks performant = 25519 backup = P-256, P-384, P-521 (legacy triple) All the above should ultimately be MTI, with each peer prioritizing either "conservantive" or "performant", and legacy peers do the same with "P-256" or "P-384" (with P-521 as backup for both camps). If there are signs that all these are about to fail, and we still somehow are left with some curves we're willing to trust, we can change the mix then. -- Viktor. From nobody Wed Jul 15 21:17:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F1C1B301F for ; Wed, 15 Jul 2015 21:17:33 -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 U5lK9oVJw6vE for ; Wed, 15 Jul 2015 21:17:32 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8F21B301E for ; Wed, 15 Jul 2015 21:17:31 -0700 (PDT) Received: by qkdv3 with SMTP id v3so42967860qkd.3 for ; Wed, 15 Jul 2015 21:17:31 -0700 (PDT) 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=uvd41aUFDSs2Wzde59DJ1vcaU+aWxVK8RiEFB2jlEt4=; b=z0/ckHF3tY3LCKj+FtOS/lq5KgozwIqPpBv+a31QYFgn1OMN8IKh0jT1hxv/ylqX89 nlNvIdqFZM09NgBKfX1l1bnIwn/zhU7Wc3XVhJIXUlA6aAgwBnZJNRooDawAZIgZekQK L3hmtoW1g4S/H9a7m3C8DuEXLE5Q4t6nFJR7eaPS23PH5otoZa7HVQlnValgn/9g1JH4 g/Ep7/zCFyPWuYBurZV7+mgnK1QYryUuf/rQabH9dOxGyYI6PFM5YClScye+YlJVC3f4 CsGvJWBU7p69QPnz7qNQISZaFzVrWpZY7k9MOaDLgKH7tw6+rnIuYtmK0rjnpzMr/J7M VeKQ== X-Received: by 10.55.17.151 with SMTP id 23mr13526358qkr.103.1437020251140; Wed, 15 Jul 2015 21:17:31 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id l33sm3444010qkh.12.2015.07.15.21.17.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 21:17:30 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 16 Jul 2015 00:17:28 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55A70C01.8010907@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507160017.29371.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 04:17:33 -0000 On Wednesday, July 15, 2015 10:31:12 pm Tony Arcieri wrote: > Binary curves in particular are showing warning signs of potential future > security issues: > > https://eprint.iacr.org/2015/310.pdf > > I think even if we don't completely pare down the TLS curve portfolio to > the list I suggested, if nothing else I would like to see binary curves > removed. As of today's draft version on GitHub [0], the only curves permitted in TLS 1.3+ are: secp256r1, secp384r1, secp521r1, & sect571r1 NIST naming [1] of these: P-256, P-384, P-521, & B-571 The other 571-bit is sect571k1 / K-571 (already cut). NIST notation [2] for these names: "P" denotes prime, "B" denotes binary, and "K" denotes Koblitz If there's sufficient evidence that binary curves are likely to be unsafe in the future, then I would certainly consider that to be an additional argument to cut sect571r1. Thus far, I haven't seen much of an argument to keep it. [0] https://tlswg.github.io/tls13-spec/#negotiated-groups [1] https://tools.ietf.org/html/rfc4492#appendix-A [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf Side question: what is the meaning of the "r" in the naming convention we use? (e.g. secp521r1, & sect571r1 vs. sect571k1) Dave From nobody Wed Jul 15 21:17:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBFB1B3024 for ; Wed, 15 Jul 2015 21:17: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 5w2tEYAEX3Pf for ; Wed, 15 Jul 2015 21:17:53 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5035A1B3023 for ; Wed, 15 Jul 2015 21:17:53 -0700 (PDT) Received: by wibud3 with SMTP id ud3so4688082wib.0 for ; Wed, 15 Jul 2015 21:17:52 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=jOQajt6cD6pI7TglacMtzL2W6+nlM+//dH661Eyq49k=; b=i+KuKNjR69iUju4lqMntVsxGE439BZJ+Zsw6YYdRMUFXIdnVZKj+z06PEYb0+RM59T MKhbz7xMMIYx7V7Duq6LWeZ9z7RG3E0hWvUupceo417VCEeR4JijaP/9xlFY2Bsda6Yc 6bt+VYZQ+wGABKnbf2dliB5ZJxmTiWopvU/I9CW6DUVqO9Z/YV/ioVrfRzEMOP1bPudu ntZ0mPus4vKE8RzKLFqy1Mo/TqcqRc2Q21BQy9uOOOpu4fUcj8EotBL3E2XNEhfCz0we 1JYB1N5GLSNAzkVLYbkczPzL6Gg5wSE+dDAVMdVp+8Hhw6WHuJdNNQnyIyfRUO/+YOp9 eYvA== X-Received: by 10.194.94.101 with SMTP id db5mr14397137wjb.91.1437020272149; Wed, 15 Jul 2015 21:17:52 -0700 (PDT) Received: from [192.168.1.15] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id js3sm10903294wjc.5.2015.07.15.21.17.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jul 2015 21:17:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150716035017.GX28047@mournblade.imrryr.org> Date: Thu, 16 Jul 2015 07:17:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> <20150716035017.GX28047@mournblade.imrryr.org> To: tls@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 04:17:55 -0000 On Jul 16, 2015, at 6:50 AM, Viktor Dukhovni = wrote: > An auditor who believes that we can rigourously quantify the security > of these curves precisely enough to say which is stronger or more > closely "matches" AES-256, should be laughed out of the room and = fired. Same kind of auditor who tells you that you can=E2=80=99t replace the = library with the next version that fixes the buffer overflow because it = was the previous version that was certified.= From nobody Wed Jul 15 21:33:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4241B307E for ; Wed, 15 Jul 2015 21:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 SI55Pq3uiFIG for ; Wed, 15 Jul 2015 21:33:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8AA1B307D for ; Wed, 15 Jul 2015 21:33:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1C1234BA10; Thu, 16 Jul 2015 04:34:22 +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 042154BA0B; Thu, 16 Jul 2015 04:34:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437021262; bh=QnpAQ6GZkEUj6xfYitogdNSKMDog97hYr3eEkjdScZw=; h=From:To:Subject:Date:References:In-Reply-To:From; b=xYHh10ye2ttjI2C6XEMAn76clWs6nYYIasoU/Yvn4U6A3WOK90cOtHphlwpbzyYry Z3gTPeC//UaIx+/mEMFRrQ9sXzy1QCUMYzIdf3qkyhuZke+M4KxtPKXvuUqMt8iwh+ lhQx2oprzwuriY1t/OCGJEXVHDCn6gXsc7d2/UYc= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id DCCD680170; Thu, 16 Jul 2015 04:33:53 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 15 Jul 2015 23:33:52 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Wed, 15 Jul 2015 23:33:52 -0500 From: "Salz, Rich" To: Yoav Nir , "tls@ietf.org" Thread-Topic: [TLS] sect571r1 Thread-Index: AQHQv0EIKSk+0qN1oEuW198UiGmBOZ3dV5MAgAADawCAAGzLgIAAApWAgAAHsAD//7CQ8A== Date: Thu, 16 Jul 2015 04:33:52 +0000 Message-ID: <3f74a3e717664f228a78acbe381dbf51@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> <20150716035017.GX28047@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.221.25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 04:33:56 -0000 DQo+IFNhbWUga2luZCBvZiBhdWRpdG9yIHdobyB0ZWxscyB5b3UgdGhhdCB5b3UgY2Fu4oCZdCBy ZXBsYWNlIHRoZSBsaWJyYXJ5IHdpdGggdGhlDQo+IG5leHQgdmVyc2lvbiB0aGF0IGZpeGVzIHRo ZSBidWZmZXIgb3ZlcmZsb3cgYmVjYXVzZSBpdCB3YXMgdGhlIHByZXZpb3VzDQo+IHZlcnNpb24g dGhhdCB3YXMgY2VydGlmaWVkLg0KDQpJbiB0aGVpciBkZWZlbnNlLCB5b3UgZG8gaGF2ZSB0byBw cm92ZSB0aGF0IHRoaXMgZml4IHdhcyB0aGUgT05MWSBjaGFuZ2UuIDopDQo= From nobody Wed Jul 15 21:37:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B61A885C for ; Wed, 15 Jul 2015 14:30:02 -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 NHlBocwCaj1F for ; Wed, 15 Jul 2015 14:29:51 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBE11B2CB7 for ; Wed, 15 Jul 2015 14:29:50 -0700 (PDT) Received: by wgmn9 with SMTP id n9so43512347wgm.0 for ; Wed, 15 Jul 2015 14:29:49 -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=SIil77uuQvQ9dT3fpVVqCN36/fbajD0GjTWwhb95xE8=; b=Ox/NmIyMcQcmqbFhfZ7YWF3CVidXDwiQ95PO6kOZWvGGaExUPyp5Mt5u3vYQvxWk3S tfoA8kkQCW2vKDt2jFF3EqTD1qGUA3+SINO4Xf80j0WfaC5tNv0zQCYg8gul2UQI7IVO YWbSejUN3Z9GHn3aiRKucCJSawGJHBmEFWDdzDRn0h+a96hCJnFESlf/ax3Eu6fhE9VA yP3nY1sA5RdEwObqCCTtXQrrg1uoPQERbD5m7sRwOnJHERNonloFzX4KVYS0dlPR6PCs GgIlp6DVVA3DgohMwgOQddwqRQGOBMaTCoG7aYSeSdpBywyhRkFDZ/3rLtC3nmYlUGuP DhTQ== X-Gm-Message-State: ALoCoQm7G0rxO6LXFHyS6Py0TbpPIh1eoGfhTVwLnR5xtYv8MI5J4talYTWpbxKSzS6fYnbunTbx X-Received: by 10.180.75.78 with SMTP id a14mr369220wiw.68.1436995788985; Wed, 15 Jul 2015 14:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Wed, 15 Jul 2015 14:29:09 -0700 (PDT) In-Reply-To: <20150715141523.GA13669@LK-Perkele-VII> References: <20150715141523.GA13669@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 15 Jul 2015 14:29:09 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d0438eb9d8bea1b051af0a7ab Archived-At: X-Mailman-Approved-At: Wed, 15 Jul 2015 21:37:14 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2015 21:30:02 -0000 --f46d0438eb9d8bea1b051af0a7ab Content-Type: text/plain; charset=UTF-8 Ilari, Thanks for your detailed comments. > > Header > > Isn't 4346 already obsoleted by 5246, which this document also obsoletes? > > 4366 seems to be jointly obsoleted by 5246 and 6066. > > 5246 and 5077 are not in numerical order, whereas the rest are. This was updated in a recent PR by Dave Garrett. > > 1. (Introduction) > > DSA should be replaced by ECDSA (DSA is pretty much obsolete)? Yes, I can do that. I'm happy to remove DSA entirely if the chairs declare consensus on this. > > 1.2. (Major Differences from TLS 1.2) > > Is this meant to be changelog or list of changes? It in current form > looks more like a changelog. It's just a changelog. I'll eventually make it a real list in the final version. > > 4.9.1. (Digital Signing) > > I think someone wanted randoms back here in order to support privilege > separation (which I think is important to support, I consider it much > more important than being "HSM friendly")? I think it was Nikos. Nikos, if you'd like to submit a PR that we can discuss, that would be great. > Reading what current draft of 4492-bis says, the hash function used is > determined by signature_algorithms (or presumably the corresponding > mechanism in CertificateRequest for client certs). Well, it's negotiated by that, but indicated in the message. > Also, to my knowledge, there is no mechanism to indicate in ECDSA > certificate what hash algorithms are allowed. I am also unaware of one. > > 4.9.2. (Authenticated Encryption with Additional Data (AEAD)) > > The example looks like it belongs to section 4.9.1, as it is about > signatures, not AEAD construct. > Oops. Yeah, I'll fix that. > > 5. (The TLS Record Protocol) > > Documenting the security properties of TLS would be useful... Agreed. I intend to rewrite the entire security analysis soon. > The lack of record length hiding may be problematic in protocols that > have no place for cover traffic (e.g. can DNS requests contain padding, > DPRIVE WG is apparently planning on putting DNS into (D)TLS?). > > > 5.2.1. (Fragmentation) > > Zero-length fragments of application data are very much visible in > ciphertext (unless record padding is added), so those are not currently > useful as traffic analysis countermeasure. Agreed. We have PRs for adding padding, but they haven't been merged yet because I wanted to get key management squared away. See: https://github.com/tlswg/tls13-spec/pull/147 > > 5.2.2. (Record Payload Protection) > > There looks to be latter limits that restrict ciphertext size to 2^14 > +1024, which is smaller than 2^14+2048 here (but those limits might be > tightened further). > > As for amount of expansion needed for length-hiding, I think that being > able to represent 16384-byte record with no padding would be enough > (since record sizes cap at 16384 bytes anyway). Yes. As you can see there is an open issue marker here. If you wanted to submit a PR, that would be great. > > 6. (The TLS Handshaking Protocols) > > Are encryption keys, finished value (tls-unique) and exporter secret > part of session or not? I'm planning to remove/rewrite this entire section, as I don't think it's useful. > > 6.1.1. (Closure Alerts) > > The semantics of closure alerts seem incompatible with half-closes, > which some protocols actually use. True, but this has been in TLS since the beginning, so there presumably should not be any TLS-using apps which depend on it. Do you think this is a feature which we should add. > > 6.1.2. (Error Alerts) > > Could use another example of warning alert, now that no_renegotiation > is not a warning anymore? Will see what I can find. > > 6.2.1. (Incorrect DHE Share) > > EncryptedExtensions is marked optional in Figure 2, but not Figure 1? It's not optional. I just got confused. Thanks. > The relationship between session hash and handshake restarts seems > like a hairy problem. > > Also, I figured out a downgrade attack that works against careless > _server_ (not requiring client to do anything else than have weak > crypto enabled). Continuing hashes looks to block that attack. > > It involves attacker sending ClientHello with arbitrary parameters > that triggers a retry (very easy to trigger a retry), eating the > reply, followed by sending client's original ClientHello. That > could trigger crypto downgrade in some badly made servers. Do you think you could walk through this in more detail? I'm having trouble understanding the issue. > > 6.2.2. (Cached Server Configuration) > > Issue #184 manifests here too. I think both accepting and provoding > configuration in the same handshake is sensible (key rollover), and > later the draft talks about exactly that case. I agree. > Also, maybe note that provoding the message does not alter the > configuration hash (even if there is no existing one) could be useful. Agreed. Will see what I can do. > > 6.2.3. (Zero-RTT Exchange) > > No EncryptedExtensions? Pilot error. > How would the server know when 0-RTT data ended, so it could send its > ServerHello? Is there a reason it needs to know? It needs to be able to distinguish the 0-RTT from the 1-RTT data, but the Finished allows that. > Also, how is the 0-RTT data bound to session if accepted, or is there > a security analysis for leaving this binding out? Can you say more about what you mean here? > Can anyone expand on the note about impersonation with compromised > server key? I can't offhand figure out how attacker can calculate > server-side ES (without having also compromised (possibly former) > client or (current) server exchange key). Will see what I can do. > > 6.3. (Handshake Protocol) > > Missing encrypted_extensions (it is a handshake message, right)? Yeah, pilot error. > > 6.3.1.1. (Client Hello) > > The non-match case gives HelloRetryRequest, not ServerHello, right? Yes. > s/should/SHOULD/ in description of session_id? > > I don't think client extensions are optional anymore in TLS 1.3 (being > required for successful handshake. > > Also, TLS 1.2 servers that care about security (are there actually any?) > already require extensions for successful handshake. I agree. We should mandate these. > > 6.3.1.2. (Server Hello) > > Well, at least it wouldn't be backward compatiblity hazard to remove > session_id_len, since it comes after server version. I'm sold. > Note: Unlike client extensions, I think server extensions might be empty > in TLS 1.3 handshake (since extensions required for GDHE_CERT type key > exchanges are not replied to by server). > > > 6.3.1.3. (Hello Retry Request) > > server_version and cipher_suite in HRR seem bit dangerous to me. If > HashAlgorithm contained all PRF hashes (currently it does), one could > use that to designate PRF hash. I think we only need the minimum information, so maybe we could skip these... > Merging DTLS cookies might be a good idea. However, then group mismatch > wouldn't be the only source of failure (which needs some text adjustment > about the selected_group check). Yes, I can fix this. > s/use for/add to/ in description of selected_group? Thanks. Yes. > What happens if Ciphersuite and NamedGroup don't match between HRR > and SH/SKS? I expect there be clients that don't check, no matter if it > is MUST or not. Depends on if we continue the hash. If not, I would imagine that the handshake succeeds. With that said, this is intended to be a client-side enforcement of correct server behavior. Since the client's offered parameters are the same as the ones it offered before (with just a new key in ClientKeyShare) the server should be picking the same parameters as before, no? > > 6.3.1.4. (Hello Extensions) > > supported_groups is 10, right? Thanks, yes, I'll bring this in. > Also, for matter of protocol testing, could be useful to give some > free values to temporary squat on for extensions that aren't stable > yet. I agree. Suggest you propose this as a PR. > The restriction on extensions appearing also holds for > EncryptedExtensions, not just SH or HRR. I wonder if we should relax these. > It could also be useful to deprecate some extensions (client MAY send > for backwards compat, server MUST NOT select). > > Some candidates: > - truncated_hmac: Block modes have been removed. > - encrypt_then_mac: Block modes have been removed. > - extended_master_secret: The THS bug is fixed anyway. > - sessionticket TLS: Session tickets are deprecated. > - renegotiation_info: The renego bug is fixed anyway. Agreed. > The interaction of some extensions with PSK-based resumption isn't > that clear. This is further complicated by the fact that PSK can also > start a new session. Yes, I haven't quite worked this out. > Reference to "error alerts". Should that be "fatal alerts"? Yes, thanks. > The part about being careful with extensions modifying handshake > presumably also goes for functions that are sometimes used for > authentication like TLS-EXPORTER or TLS-UNIQUE. We may be beyond that point. > > 6.3.1.4.1. (Signature Algorithms) > > Anonymous should be removed. It is apparently not used (there is reference > to another section saying that section uses it, but I can't find in that > section how it is actually used). I think there is still a desire to have anonymous DH cipher suites. > Description of signature refers to 6.3,2, which is about SKS, which does > not seem to have anything to do with signatures (leftover from TLS 1.2?) > > Then in description of the extensions there is reference to 6.3.4 and > 6.3.2. 6.3.4 looks relevant, 6.3.2. doesn't look so. I'll clean these up. > Also, making signature_algorithms mandatory would allow dropping the > backward compatiblity special cases from here. Agreed. Just waiting for the chairs to declare consensus on that :) > There is text that talks about "offering prior versions". Does that > refer to insecure version downgrade (I don't suppose TLS 1.1 maximum > client would care about what TLS 1.3 spec says). It was just to make clear that people shouldn't be adopting this for older versions. > > 6.3.1.4.2. (Negotiated Groups) > > One chould add Curve25519 and Curve448, and the corresponding > signature groups (signature groups when CFRG signatures become > stable). Yep. I think the drafts are now stable for this. > > 6.3.1.5.1. (Diffie-Hellman Parameters) > > 6.3.1.5.2. (ECDHE Parameters) > > Drop the wrappers? Then DHE and ECDHE could be unified (the unification > is currently blocked by different lengths of the length field). Yes, that looks like it would work. Will try that > The point description might make it more clear that encodings are per- > curve (altough most curves use X9.62). Will see what I can do. Suggested tet would help. > Does the note about only single point format apply to signatures too > (if so, ec_point_formats could be deprecated). Yes, it should. > Regarding CFRG curves, the current draft (for TLS 1.2) specifies use > of the native point format (32/56 octets) as if it was uncompressed. That sounds like a good fit then. > > 6.3.1.5.4. (Pre-Shared Key Extension) > > Client SHOULD offer at most two PSK identities (one for DH-PSK, > the other for pure-PSK)? My sense was just to offer a pile of identities, since they're untyped anyway. > This would imply that one can't resume pure-PSK sessions, but that > does not look to be useful anyway. > > Also, could be useful to state that the PSK identity hint from > previous versions has been deprecated. Willdo. > > 6.3.1.5.5. (Early Data Indication) > > s/MUST not/MUST NOT/ in description of early_data with client auth? Ack. > Also, I would say that 0-RTT data with 0-RTT auth is more dangerous than > 0-RTT data with 1-RTT auth (for reasons mentioned earlier in the draft). It is. It's also important for some applications. > Eeh, the rule for detecting end of 0RTT data, isn't the next client > handshake message from the next flight at least in some cases (and > waiting would obviously deadlock)? I don't believe that the server has to wait for the end of 0-RTT data before it sends the ServerHello. What is necessary is to be able to skip ahead through the handshake messages that you can't read (if you reject). > Again, how is binding of early handshake messages done (or security > analysis showing this unnecressary)? There are two cases here: 1. The server accepts the 0-RTT, in which case they are bound in the usual way. 2. The server rejects the 0-RTT in which case they aren't bound but also no data from them is used (though the fact of rejection is bound). We are working on analyzing this now. > Client receiving rejection knows that auth failed and data failed, it > might try to fix things up in its next flight. > As for what to sign for client auth, the ClientHello and Certificate > (at least)? One thing to note is that if verify contains randoms, then > server_random isn't available. Yeah, it would be 0. > Regarding finished, isn't Finished in second flight? Or is this another > client Finished? The client's Finished is in the second flight. Can you clarify this question. > Regarding cryptographic parameter set, I think one better prepare for > failure (there are multiple causes of server failing to compute keys or > decrypt data). Can you say more about this? > Also, how does known_configuration interact with PSK (other than > configurations seemingly not being usable with PSK)? I will have a proposal to fix this which I plan to send shortly. > Also, the record protection used for early handshake messages should be > indicated. Can you expand on that? > I think there are basically two things to signal for 0RTT: > - What key material is used (either by PSK ID or configuration ID) > - What record protection (and KDF to derive keys) is used? > > Tying the latter to client offered ciphersuites is probably not wanted. Yeah, I think we should signal this separately. > > 6.3.2. (Server Key Share) > > Add that connection will be rekeyed immediately after this message, and > that it MUST be the last message in record it is in? Thanks. Yes. > > 6.3.3. (Encrypted Extensions) > > Some of the figures have this as mandatory, some optional. Which is it? Mandatory. Pilot error. > Yeah, would be good to have explicit list of what goes to SH, and what > goes to EE. Yes. > Also, the list is affected by #184, as some extensions introduce extra > messages (esp. status_request{,_v2} and signed_certificate_timestamp). Good point. > > 6.3.4. (Server Certificate) > > > > The certificate MUST be appropriate for the negotiated cipher > > suite's key exchange algorithm and any negotiated extensions. > > If signature_algorithms is mandatory, this would then key to that for > signature algorithm, not ciphersuites (and even if it isn't, it would > then key to its fallback default). Yep. > Could change example of alternative certificate formats to RFC7250 (it > seems better designed than RFC5081). Ack. > Doesn't TLS 1.3 always use the certificate for signing, with indicated > algorithm (which obviously needs to be supported by peer)? Wouldn't it > make more sense to talk about signature algorithms instead of key > exchange algorithms. (Unless some key exchange that uses non-signing > certificates is added). Yeah, this is just old text. > > 6.3.6. (Server Configuration) > > Use TTL instead of of explicit time for expiration, as broken clocks > are abound (also, just 32-bit field that only goes up to 2106 or so)? Here's my argument for explicit time: We might in the future want to allow some kind of offline signing (potentially, as Hugo has suggested, with a special bit in the certificate). In that case, it would be really nice to have an absolute expiration time for obvious reasons. > Also, considering the dangers of configuration, it might be appropriate > to have other permission flags (especially client and server auth) too? I could see client auth, as in "I will want you to do client auth" but why server auth, since once you have the configuration, you have continuing auth. > Also, Could be useful for client to know what ciphers it can use for > 0-RTT data? This is a possibility, but I was more thinking that they would reuse the same ones as were negotiated here. More on this shortly. > > 6.3.7. (Server Certificate Verify) > > Should PRF hash designation be added in order to avoid attacks from > weak PRF hashes? Could you say more about this? > I think note about checking signature algorithm against ciphersuite > should be removed. This seems to interact with the a la carte discussion. > Also, with regards to complications of DSA, just dump it? :-) I'm fine with that if the chairs declare consensus on it. > > 6.3.9. (Client Certificate) > > > Doesn't CertificateRequest override algorithms anyway (and CR isn't an > extension)? Sorry, I'm not clear on what text you are sad about. > Again, could use RFC7250 instead of RFC5081 as an example? Yes. > > 6.3.10. (Client Certificate Verify) > > Similar problems as in DSA for server auth. And missing identifier > for PRF too. Sorry, can you expand on this. > > 6.3.11. (New Session Ticket Message) > > Eh, if server starts transmitting immediately without waiting for > client Finished (as is permitted for case where 1-RTT client auth > is not performed), it can't resume the session? Good point. This seems like a silly restriction, so let's remove it. > > 7.2.3. (Elliptic Curve Diffie-Hellman) > > Probably needs different description for Curve25519 and Curve448. > Those are functions that take in octet strings and output octet strings > (32 or 56 bytes). Now that those drafts are stable will see if I can incorporate. > > 11. (IANA Considerations) > > Yeah, looks to need a rewrite. Doesn't register the new stuff, and > furthermore has problems like: > > - signature_algorithms is already defined by RFC5246. > - SignatureAlgorithm registry is already defined. > - HashAlgorithm registry is already defined. > > > A.4. (The Cipher Suite) > > Probably remove note about 001C and 001D, since lots of ciphersuites are > now reserved to avoid collisions with old ones. > > > C.1. (Random Number Generation and Seeding) > Replace SHA-1 with SHA-256? > > The example is completely obsolete. Any sort of modern PCs have much > faster timers (some reaching multi-GHz rates) and one really should use > Operating System for (seeding) random numbers. > > > C.4. (Implementation Pitfalls) > > - Do you handle required handshake messages being missing or handshake > messages being in wrong order properly (i.e. terminate the connection)? > > Also, ECDSA signing operations need timing protection. > > s/DSA/ECDSA/ in seeding? And shouldn't k be determinstically generated? Thanks for the suggestions. Will edit. > > E.1.1. (Authentication and Key Exchange) I plan to rewrite all of E. > Would be useful to list what can be used to authenticate peers, in > practicular, are the following valid: > > - Signing TLS-Unique value? > - Signing value from TLS-EXPORTER? I think we should generate an explicit TLS-channel-binding output and recommend people use that. Thanks again, -Ekr On Wed, Jul 15, 2015 at 7:15 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > Let's review: draft-ietf-tls-tls13-07 > > This is abridged version of mail I sent earlier, but was too large for > the list due to its sheer size. > > (Note: I omitted some stuff I saw recently discussed (e.g. pruning > unused crypto algorithms) or I remember discussed. I didn't explicitly > check issue list when doing this). > > Note: The issue list could use some cleanup. It has multiple duplicate > issues (especially about fixing THS) and also some issues that no longer > look applicable. > > > > Header > > Isn't 4346 already obsoleted by 5246, which this document also obsoletes? > > 4366 seems to be jointly obsoleted by 5246 and 6066. > > 5246 and 5077 are not in numerical order, whereas the rest are. > > > 1. (Introduction) > > DSA should be replaced by ECDSA (DSA is pretty much obsolete)? > > > 1.2. (Major Differences from TLS 1.2) > > Is this meant to be changelog or list of changes? It in current form > looks more like a changelog. > > > 4.9.1. (Digital Signing) > > I think someone wanted randoms back here in order to support privilege > separation (which I think is important to support, I consider it much > more important than being "HSM friendly")? > > Reading what current draft of 4492-bis says, the hash function used is > determined by signature_algorithms (or presumably the corresponding > mechanism in CertificateRequest for client certs). > > Also, to my knowledge, there is no mechanism to indicate in ECDSA > certificate what hash algorithms are allowed. > > > 4.9.2. (Authenticated Encryption with Additional Data (AEAD)) > > The example looks like it belongs to section 4.9.1, as it is about > signatures, not AEAD construct. > > > 5. (The TLS Record Protocol) > > Documenting the security properties of TLS would be useful... > > The lack of record length hiding may be problematic in protocols that > have no place for cover traffic (e.g. can DNS requests contain padding, > DPRIVE WG is apparently planning on putting DNS into (D)TLS?). > > > 5.2.1. (Fragmentation) > > Zero-length fragments of application data are very much visible in > ciphertext (unless record padding is added), so those are not currently > useful as traffic analysis countermeasure. > > > 5.2.2. (Record Payload Protection) > > There looks to be latter limits that restrict ciphertext size to 2^14 > +1024, which is smaller than 2^14+2048 here (but those limits might be > tightened further). > > As for amount of expansion needed for length-hiding, I think that being > able to represent 16384-byte record with no padding would be enough > (since record sizes cap at 16384 bytes anyway). > > > 6. (The TLS Handshaking Protocols) > > Are encryption keys, finished value (tls-unique) and exporter secret > part of session or not? > > > 6.1.1. (Closure Alerts) > > The semantics of closure alerts seem incompatible with half-closes, > which some protocols actually use. > > > 6.1.2. (Error Alerts) > > Could use another example of warning alert, now that no_renegotiation > is not a warning anymore? > > > 6.2.1. (Incorrect DHE Share) > > EncryptedExtensions is marked optional in Figure 2, but not Figure 1? > > The relationship between session hash and handshake restarts seems > like a hairy problem. > > Also, I figured out a downgrade attack that works against careless > _server_ (not requiring client to do anything else than have weak > crypto enabled). Continuing hashes looks to block that attack. > > It involves attacker sending ClientHello with arbitrary parameters > that triggers a retry (very easy to trigger a retry), eating the > reply, followed by sending client's original ClientHello. That > could trigger crypto downgrade in some badly made servers. > > > 6.2.2. (Cached Server Configuration) > > Issue #184 manifests here too. I think both accepting and provoding > configuration in the same handshake is sensible (key rollover), and > later the draft talks about exactly that case. > > Also, maybe note that provoding the message does not alter the > configuration hash (even if there is no existing one) could be useful. > > > 6.2.3. (Zero-RTT Exchange) > > No EncryptedExtensions? > > How would the server know when 0-RTT data ended, so it could send its > ServerHello? > > Also, how is the 0-RTT data bound to session if accepted, or is there > a security analysis for leaving this binding out? > > Can anyone expand on the note about impersonation with compromised > server key? I can't offhand figure out how attacker can calculate > server-side ES (without having also compromised (possibly former) > client or (current) server exchange key). > > > 6.3. (Handshake Protocol) > > Missing encrypted_extensions (it is a handshake message, right)? > > > 6.3.1.1. (Client Hello) > > The non-match case gives HelloRetryRequest, not ServerHello, right? > > s/should/SHOULD/ in description of session_id? > > I don't think client extensions are optional anymore in TLS 1.3 (being > required for successful handshake. > > Also, TLS 1.2 servers that care about security (are there actually any?) > already require extensions for successful handshake. > > > 6.3.1.2. (Server Hello) > > Well, at least it wouldn't be backward compatiblity hazard to remove > session_id_len, since it comes after server version. > > Note: Unlike client extensions, I think server extensions might be empty > in TLS 1.3 handshake (since extensions required for GDHE_CERT type key > exchanges are not replied to by server). > > > 6.3.1.3. (Hello Retry Request) > > server_version and cipher_suite in HRR seem bit dangerous to me. If > HashAlgorithm contained all PRF hashes (currently it does), one could > use that to designate PRF hash. > > Merging DTLS cookies might be a good idea. However, then group mismatch > wouldn't be the only source of failure (which needs some text adjustment > about the selected_group check). > > s/use for/add to/ in description of selected_group? > > What happens if Ciphersuite and NamedGroup don't match between HRR > and SH/SKS? I expect there be clients that don't check, no matter if it > is MUST or not. > > Heck, I recently heard of servers that only partially(!!!) check client > Finished (or omit the check entierely). > > > 6.3.1.4. (Hello Extensions) > > supported_groups is 10, right? > > Also, for matter of protocol testing, could be useful to give some > free values to temporary squat on for extensions that aren't stable > yet. > > The restriction on extensions appearing also holds for > EncryptedExtensions, not just SH or HRR. > > It could also be useful to deprecate some extensions (client MAY send > for backwards compat, server MUST NOT select). > > Some candidates: > - truncated_hmac: Block modes have been removed. > - encrypt_then_mac: Block modes have been removed. > - extended_master_secret: The THS bug is fixed anyway. > - sessionticket TLS: Session tickets are deprecated. > - renegotiation_info: The renego bug is fixed anyway. > > The interaction of some extensions with PSK-based resumption isn't > that clear. This is further complicated by the fact that PSK can also > start a new session. > > Reference to "error alerts". Should that be "fatal alerts"? > > The part about being careful with extensions modifying handshake > presumably also goes for functions that are sometimes used for > authentication like TLS-EXPORTER or TLS-UNIQUE. > > > 6.3.1.4.1. (Signature Algorithms) > > Anonymous should be removed. It is apparently not used (there is reference > to another section saying that section uses it, but I can't find in that > section how it is actually used). > > Description of signature refers to 6.3,2, which is about SKS, which does > not seem to have anything to do with signatures (leftover from TLS 1.2?) > > Then in description of the extensions there is reference to 6.3.4 and > 6.3.2. 6.3.4 looks relevant, 6.3.2. doesn't look so. > > Also, making signature_algorithms mandatory would allow dropping the > backward compatiblity special cases from here. > > There is text that talks about "offering prior versions". Does that > refer to insecure version downgrade (I don't suppose TLS 1.1 maximum > client would care about what TLS 1.3 spec says). > > > 6.3.1.4.2. (Negotiated Groups) > > One chould add Curve25519 and Curve448, and the corresponding > signature groups (signature groups when CFRG signatures become > stable). > > > 6.3.1.5.1. (Diffie-Hellman Parameters) > > 6.3.1.5.2. (ECDHE Parameters) > > Drop the wrappers? Then DHE and ECDHE could be unified (the unification > is currently blocked by different lengths of the length field). > > The point description might make it more clear that encodings are per- > curve (altough most curves use X9.62). > > Does the note about only single point format apply to signatures too > (if so, ec_point_formats could be deprecated). > > Regarding CFRG curves, the current draft (for TLS 1.2) specifies use > of the native point format (32/56 octets) as if it was uncompressed. > > > 6.3.1.5.4. (Pre-Shared Key Extension) > > Client SHOULD offer at most two PSK identities (one for DH-PSK, > the other for pure-PSK)? > > This would imply that one can't resume pure-PSK sessions, but that > does not look to be useful anyway. > > Also, could be useful to state that the PSK identity hint from > previous versions has been deprecated. > > > 6.3.1.5.5. (Early Data Indication) > > s/MUST not/MUST NOT/ in description of early_data with client auth? > > Also, I would say that 0-RTT data with 0-RTT auth is more dangerous than > 0-RTT data with 1-RTT auth (for reasons mentioned earlier in the draft). > > Eeh, the rule for detecting end of 0RTT data, isn't the next client > handshake message from the next flight at least in some cases (and > waiting would obviously deadlock)? > > Again, how is binding of early handshake messages done (or security > analysis showing this unnecressary)? > > Client receiving rejection knows that auth failed and data failed, it > might try to fix things up in its next flight. > > As for what to sign for client auth, the ClientHello and Certificate > (at least)? One thing to note is that if verify contains randoms, then > server_random isn't available. > > Regarding finished, isn't Finished in second flight? Or is this another > client Finished? > > Regarding cryptographic parameter set, I think one better prepare for > failure (there are multiple causes of server failing to compute keys or > decrypt data). > > Also, how does known_configuration interact with PSK (other than > configurations seemingly not being usable with PSK)? > > Also, the record protection used for early handshake messages should be > indicated. > > I think there are basically two things to signal for 0RTT: > - What key material is used (either by PSK ID or configuration ID) > - What record protection (and KDF to derive keys) is used? > > Tying the latter to client offered ciphersuites is probably not wanted. > > > 6.3.2. (Server Key Share) > > Add that connection will be rekeyed immediately after this message, and > that it MUST be the last message in record it is in? > > > 6.3.3. (Encrypted Extensions) > > Some of the figures have this as mandatory, some optional. Which is it? > > Yeah, would be good to have explicit list of what goes to SH, and what > goes to EE. > > Also, the list is affected by #184, as some extensions introduce extra > messages (esp. status_request{,_v2} and signed_certificate_timestamp). > > > 6.3.4. (Server Certificate) > > > > The certificate MUST be appropriate for the negotiated cipher > > suite's key exchange algorithm and any negotiated extensions. > > If signature_algorithms is mandatory, this would then key to that for > signature algorithm, not ciphersuites (and even if it isn't, it would > then key to its fallback default). > > Could change example of alternative certificate formats to RFC7250 (it > seems better designed than RFC5081). > > Doesn't TLS 1.3 always use the certificate for signing, with indicated > algorithm (which obviously needs to be supported by peer)? Wouldn't it > make more sense to talk about signature algorithms instead of key > exchange algorithms. (Unless some key exchange that uses non-signing > certificates is added). > > > 6.3.6. (Server Configuration) > > Use TTL instead of of explicit time for expiration, as broken clocks > are abound (also, just 32-bit field that only goes up to 2106 or so)? > > Also, considering the dangers of configuration, it might be appropriate > to have other permission flags (especially client and server auth) too? > > Also, Could be useful for client to know what ciphers it can use for > 0-RTT data? > > > 6.3.7. (Server Certificate Verify) > > Should PRF hash designation be added in order to avoid attacks from > weak PRF hashes? > > I think note about checking signature algorithm against ciphersuite > should be removed. > > Also, with regards to complications of DSA, just dump it? :-) > > > 6.3.9. (Client Certificate) > > > Doesn't CertificateRequest override algorithms anyway (and CR isn't an > extension)? > > Again, could use RFC7250 instead of RFC5081 as an example? > > > 6.3.10. (Client Certificate Verify) > > Similar problems as in DSA for server auth. And missing identifier > for PRF too. > > > 6.3.11. (New Session Ticket Message) > > Eh, if server starts transmitting immediately without waiting for > client Finished (as is permitted for case where 1-RTT client auth > is not performed), it can't resume the session? > > > 7.2.3. (Elliptic Curve Diffie-Hellman) > > Probably needs different description for Curve25519 and Curve448. > Those are functions that take in octet strings and output octet strings > (32 or 56 bytes). > > > 11. (IANA Considerations) > > Yeah, looks to need a rewrite. Doesn't register the new stuff, and > furthermore has problems like: > > - signature_algorithms is already defined by RFC5246. > - SignatureAlgorithm registry is already defined. > - HashAlgorithm registry is already defined. > > > A.4. (The Cipher Suite) > > Probably remove note about 001C and 001D, since lots of ciphersuites are > now reserved to avoid collisions with old ones. > > > C.1. (Random Number Generation and Seeding) > > Replace SHA-1 with SHA-256? > > The example is completely obsolete. Any sort of modern PCs have much > faster timers (some reaching multi-GHz rates) and one really should use > Operating System for (seeding) random numbers. > > > C.4. (Implementation Pitfalls) > > - Do you handle required handshake messages being missing or handshake > messages being in wrong order properly (i.e. terminate the connection)? > > Also, ECDSA signing operations need timing protection. > > s/DSA/ECDSA/ in seeding? And shouldn't k be determinstically generated? > > > E.1.1. (Authentication and Key Exchange) > > Would be useful to list what can be used to authenticate peers, in > practicular, are the following valid: > > - Signing TLS-Unique value? > - Signing value from TLS-EXPORTER? > > Both have been seen in the wild, so these better be secure ways. This > also goes for "anonymous" key exchange. > > > E.1.2. (Version Rollback Attacks) > > Is the note about PKCS #1 block type 2 about RSA key exchange, which is > deprecated? > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0438eb9d8bea1b051af0a7ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ilari,

Thanks for your detai= led comments.


> > Header
>=C2=A0
> Isn't 4346 already obsoleted by 5246, w= hich this document also obsoletes?
>=C2=A0
> 4366= seems to be jointly obsoleted by 5246 and 6066.
>=C2=A0
=
> 5246 and 5077 are not in numerical order, whereas the rest are.

This was updated in a recent PR by Dave Garrett.



> > 1. (Introduc= tion)
>=C2=A0
> DSA should be replaced by ECDSA (= DSA is pretty much obsolete)?

Yes, I can do that. = I'm happy to remove DSA entirely if the
chairs declare consen= sus on this.


> > 1.2. (Major = Differences from TLS 1.2)
>=C2=A0
> Is this meant= to be changelog or list of changes? It in current form
> look= s more like a changelog.

It's just a changelog= . I'll eventually make it a real list in the
final version.


> > 4.9.1. (Digital Signing)
>=C2=A0
> I think someone wanted randoms back here= in order to support privilege
> separation (which I think is = important to support, I consider it much
> more important than= being "HSM friendly")?

I think it was N= ikos. Nikos, if you'd like to submit a PR that
we can discuss= , that would be great.


> Reading= what current draft of 4492-bis says, the hash function used is
&= gt; determined by signature_algorithms (or presumably the corresponding
> mechanism in CertificateRequest for client certs).
Well, it's negotiated by that, but indicated in the messag= e.


> Also, to my knowledge, ther= e is no mechanism to indicate in ECDSA
> certificate what hash= algorithms are allowed.

I am also unaware of one.=


> > 4.9.2. (Authenticated En= cryption with Additional Data (AEAD))
>=C2=A0
> T= he example looks like it belongs to section 4.9.1, as it is about
> signatures, not AEAD construct.
>

Oops. Yeah, I'll fix that.


&= gt; > 5. (The TLS Record Protocol)
>=C2=A0
> D= ocumenting the security properties of TLS would be useful...

=
Agreed. I intend to rewrite the entire security analysis soon.



> The lack of reco= rd length hiding may be problematic in protocols that
> have n= o place for cover traffic (e.g. can DNS requests contain padding,
> DPRIVE WG is apparently planning on putting DNS into (D)TLS?).
<= div>>=C2=A0
> > 5.2.1. (Fragmentation)
>=C2= =A0
> Zero-length fragments of application data are very much = visible in
> ciphertext (unless record padding is added), so t= hose are not currently
> useful as traffic analysis countermea= sure.

Agreed. We have PRs for adding padding, but = they haven't been merged
yet because I wanted to get key mana= gement squared away.



> > 5.2.2. (Record Pay= load Protection)
>=C2=A0
> There looks to be latt= er limits that restrict ciphertext size to 2^14
> +1024, which= is smaller than 2^14+2048 here (but those limits might be
> t= ightened further).
>=C2=A0
> As for amount of exp= ansion needed for length-hiding, I think that being
> able to = represent 16384-byte record with no padding would be enough
> = (since record sizes cap at 16384 bytes anyway).

Ye= s. As you can see there is an open issue marker here. If you wanted
to submit a PR, that would be great.


=

> > 6. (The TLS Handshaking Protocols)
= >=C2=A0
> Are encryption keys, finished value (tls-unique) = and exporter secret
> part of session or not?

I'm planning to remove/rewrite this entire section, as I don&#= 39;t think
it's useful.


> > 6.1.1. (Closure Alerts)
>=C2=A0
> Th= e semantics of closure alerts seem incompatible with half-closes,
> which some protocols actually use.

True, but= this has been in TLS since the beginning, so there presumably
sh= ould not be any TLS-using apps which depend on it. Do you think this
<= div>is a feature which we should add.


> > 6.1.2. (Error Alerts)
>=C2=A0
> Coul= d use another example of warning alert, now that no_renegotiation
> is not a warning anymore?

Will see what I ca= n find.


> > 6.2.1. (Incorrect= DHE Share)
>=C2=A0
> EncryptedExtensions is mark= ed optional in Figure 2, but not Figure 1?

It'= s not optional. I just got confused. Thanks.


<= /div>
> The relationship between session hash and handshake restarts= seems
> like a hairy problem.
>=C2=A0
= > Also, I figured out a downgrade attack that works against careless
> _server_ (not requiring client to do anything else than have we= ak
> crypto enabled). Continuing hashes looks to block that at= tack.
>=C2=A0
> It involves attacker sending Clie= ntHello with arbitrary parameters
> that triggers a retry (ver= y easy to trigger a retry), eating the
> reply, followed by se= nding client's original ClientHello. That
> could trigger = crypto downgrade in some badly made servers.

Do yo= u think you could walk through this in more detail? I'm having
trouble understanding the issue.


= > > 6.2.2. (Cached Server Configuration)
>=C2=A0
> Issue #184 manifests here too. I think both accepting and provoding=
> configuration in the same handshake is sensible (key rollov= er), and
> later the draft talks about exactly that case.

I agree.


> = Also, maybe note that provoding the message does not alter the
&g= t; configuration hash (even if there is no existing one) could be useful.

Agreed. Will see what I can do.


> > 6.2.3. (Zero-RTT Exchange)
>=C2= =A0
> No EncryptedExtensions?

Pilot e= rror.


> How would the server kno= w when 0-RTT data ended, so it could send its
> ServerHello?

Is there a reason it needs to know? It needs to be = able to distinguish
the 0-RTT from the 1-RTT data, but the Finish= ed allows that.


> Also, how is t= he 0-RTT data bound to session if accepted, or is there
> a se= curity analysis for leaving this binding out?

Can = you say more about what you mean here?


<= div>> Can anyone expand on the note about impersonation with compromised=
> server key? I can't offhand figure out how attacker can= calculate
> server-side ES (without having also compromised (= possibly former)
> client or (current) server exchange key).

Will see what I can do.

> > 6.3. (Handshake Protocol)
>=C2=A0
=
> Missing encrypted_extensions (it is a handshake message, right)?<= /div>

Yeah, pilot error.


> > 6.3.1.1. (Client Hello)
>=C2=A0
&= gt; The non-match case gives HelloRetryRequest, not ServerHello, right?

Yes.


> s/s= hould/SHOULD/ in description of session_id?
>=C2=A0
= > I don't think client extensions are optional anymore in TLS 1.3 (b= eing
> required for successful handshake.
>=C2=A0=
> Also, TLS 1.2 servers that care about security (are there a= ctually any?)
> already require extensions for successful hand= shake.

I agree. We should mandate these.


> > 6.3.1.2. (Server Hello)
= >=C2=A0
> Well, at least it wouldn't be backward compat= iblity hazard to remove
> session_id_len, since it comes after= server version.

I'm sold.



> Note: Unlike client extensions, I = think server extensions might be empty
> in TLS 1.3 handshake = (since extensions required for GDHE_CERT type key
> exchanges = are not replied to by server).
>=C2=A0
> > 6.3= .1.3. (Hello Retry Request)
>=C2=A0
> server_vers= ion and cipher_suite in HRR seem bit dangerous to me. If
> Has= hAlgorithm contained all PRF hashes (currently it does), one could
> use that to designate PRF hash.

I think we = only need the minimum information, so maybe we could skip
these..= .


> Merging DTLS cookies might b= e a good idea. However, then group mismatch
> wouldn't be = the only source of failure (which needs some text adjustment
>= about the selected_group check).

Yes, I can fix t= his.


> s/use for/add to/ in desc= ription of selected_group?

Thanks. Yes.
=

> What happens if Ciphersuite and NamedGro= up don't match between HRR
> and SH/SKS? I expect there be= clients that don't check, no matter if it
> is MUST or no= t.

Depends on if we continue the hash. If not, I w= ould imagine that the handshake
succeeds. With that said, this is= intended to be a client-side enforcement
of correct server behav= ior. Since the client's offered parameters are
the same as th= e ones it offered before (with just a new key in ClientKeyShare)
= the server should be picking the same parameters as before, no?
<= br>

> > 6.3.1.4. (Hello Extensions)
>=C2=A0
> supported_groups is 10, right?

Thanks, yes, I'll bring this in.


=
> Also, for matter of protocol testing, could be useful to gi= ve some
> free values to temporary squat on for extensions tha= t aren't stable
> yet.

I agree. S= uggest you propose this as a PR.


&g= t; The restriction on extensions appearing also holds for
> En= cryptedExtensions, not just SH or HRR.

I wonder if= we should relax these.


> It cou= ld also be useful to deprecate some extensions (client MAY send
&= gt; for backwards compat, server MUST NOT select).
>=C2=A0
> Some candidates:
> - truncated_hmac: Block modes h= ave been removed.
> - encrypt_then_mac: Block modes have been = removed.
> - extended_master_secret: The THS bug is fixed anyw= ay.
> - sessionticket TLS: Session tickets are deprecated.
> - renegotiation_info: The renego bug is fixed anyway.

Agreed.


> The in= teraction of some extensions with PSK-based resumption isn't
= > that clear. This is further complicated by the fact that PSK can also<= /div>
> start a new session.

Yes, I haven&#= 39;t quite worked this out.


> Re= ference to "error alerts". Should that be "fatal alerts"= ;?

Yes, thanks.


> The part about being careful with extensions modifying handshake=
> presumably also goes for functions that are sometimes used = for
> authentication like TLS-EXPORTER or TLS-UNIQUE.

We may be beyond that point.


=
> > 6.3.1.4.1. (Signature Algorithms)
>=C2=A0=
> Anonymous should be removed. It is apparently not used (the= re is reference
> to another section saying that section uses = it, but I can't find in that
> section how it is actually = used).

I think there is still a desire to have ano= nymous DH cipher suites.


> Descr= iption of signature refers to 6.3,2, which is about SKS, which does
> not seem to have anything to do with signatures (leftover from TLS = 1.2?)
>=C2=A0
> Then in description of the extens= ions there is reference to 6.3.4 and
> 6.3.2. 6.3.4 looks rele= vant, 6.3.2. doesn't look so.

I'll clean t= hese up.


> Also, making signatur= e_algorithms mandatory would allow dropping the
> backward com= patiblity special cases from here.

Agreed. Just wa= iting for the chairs to declare consensus on that :)


> There is text that talks about "offering prior = versions". Does that
> refer to insecure version downgrad= e (I don't suppose TLS 1.1 maximum
> client would care abo= ut what TLS 1.3 spec says).

It was just to make cl= ear that people shouldn't be adopting this for older
versions= .



> > 6.3.1.4.= 2. (Negotiated Groups)
>=C2=A0
> One chould add C= urve25519 and Curve448, and the corresponding
> signature grou= ps (signature groups when CFRG signatures become
> stable).

Yep. I think the drafts are now stable for this.


> > 6.3.1.5.1. (Diffie-Hellman P= arameters)
> > 6.3.1.5.2. (ECDHE Parameters)
>= =C2=A0
> Drop the wrappers? Then DHE and ECDHE could be unifie= d (the unification
> is currently blocked by different lengths= of the length field).

Yes, that looks like it wou= ld work. Will try that


> The poi= nt description might make it more clear that encodings are per-
&= gt; curve (altough most curves use X9.62).

Will se= e what I can do. Suggested tet would help.


> Does the note about only single point format apply to signatur= es too
> (if so, ec_point_formats could be deprecated).
<= div>
Yes, it should.


= > Regarding CFRG curves, the current draft (for TLS 1.2) specifies use
> of the native point format (32/56 octets) as if it was uncomp= ressed.

That sounds like a good fit then.


> > 6.3.1.5.4. (Pre-Shared Key Extens= ion)
>=C2=A0
> Client SHOULD offer at most two PS= K identities (one for DH-PSK,
> the other for pure-PSK)?
=

My sense was just to offer a pile of identities, since = they're
untyped anyway.


> This would imply that one can't resume pure-PSK sessions, but t= hat
> does not look to be useful anyway.
>=C2=A0<= /div>
> Also, could be useful to state that the PSK identity hint fr= om
> previous versions has been deprecated.

Willdo.



> = > 6.3.1.5.5. (Early Data Indication)
>=C2=A0
>= s/MUST not/MUST NOT/ in description of early_data with client auth?
<= div>

Ack.


<= div>> Also, I would say that 0-RTT data with 0-RTT auth is more dangerou= s than
> 0-RTT data with 1-RTT auth (for reasons mentioned ear= lier in the draft).

It is. It's also important= for some applications.


> Eeh, t= he rule for detecting end of 0RTT data, isn't the next client
> handshake message from the next flight at least in some cases (and
> waiting would obviously deadlock)?

I = don't believe that the server has to wait for the end of 0-RTT
data before it sends the ServerHello. What is necessary is to
b= e able to skip ahead through the handshake messages that you
can&= #39;t read (if you reject).


> Ag= ain, how is binding of early handshake messages done (or security
> analysis showing this unnecressary)?

There a= re two cases here:

1. The server accepts the 0-RTT= , in which case they are bound in
=C2=A0 =C2=A0the usual way.
2. The server rejects the 0-RTT in which case they aren't bound<= /div>
=C2=A0 =C2=A0but also no data from them is used (though the fact = of rejection
=C2=A0 =C2=A0is bound).

We = are working on analyzing this now.


= > Client receiving rejection knows that auth failed and data failed, it<= /div>
> might try to fix things up in its next flight.
> As for what to sign for client auth, the ClientHello and C= ertificate
> (at least)? One thing to note is that if verify c= ontains randoms, then
> server_random isn't available.

Yeah, it would be 0.


> Regarding finished, isn't Finished in second flight? Or is= this another
> client Finished?

The = client's Finished is in the second flight. Can you clarify this
question.


> Regarding cryptog= raphic parameter set, I think one better prepare for
> failure= (there are multiple causes of server failing to compute keys or
= > decrypt data).

Can you say more about this?


> Also, how does known_configurat= ion interact with PSK (other than
> configurations seemingly n= ot being usable with PSK)?

I will have a proposal = to fix this which I plan to send shortly.


> Also, the record protection used for early handshake messages s= hould be
> indicated.

Can you expand = on that?


> I think there are bas= ically two things to signal for 0RTT:
> - What key material is= used (either by PSK ID or configuration ID)
> - What record p= rotection (and KDF to derive keys) is used?
>=C2=A0
= > Tying the latter to client offered ciphersuites is probably not wanted= .

Yeah, I think we should signal this separately.<= /div>


> > 6.3.2. (Server Key Share)=
>=C2=A0
> Add that connection will be rekeyed im= mediately after this message, and
> that it MUST be the last m= essage in record it is in?

Thanks. Yes.
=

> > 6.3.3. (Encrypted Extensions)
=
>=C2=A0
> Some of the figures have this as mandatory, = some optional. Which is it?

Mandatory. Pilot error= .

> Yeah, would be good to have explicit list o= f what goes to SH, and what
> goes to EE.

=
Yes.

> Also, the list is affected by #184,= as some extensions introduce extra
> messages (esp. status_re= quest{,_v2} and signed_certificate_timestamp).

Goo= d point.



> > 6= .3.4. (Server Certificate)
> >
> > =C2=A0 = =C2=A0 =C2=A0 The certificate MUST be appropriate for the negotiated cipher=
> > =C2=A0 =C2=A0 =C2=A0 suite's key exchange algorith= m and any negotiated extensions.
>=C2=A0
> If sig= nature_algorithms is mandatory, this would then key to that for
&= gt; signature algorithm, not ciphersuites (and even if it isn't, it wou= ld
> then key to its fallback default).

Yep.


> Could change example o= f alternative certificate formats to RFC7250 (it
> seems bette= r designed than RFC5081).

Ack.


> Doesn't TLS 1.3 always use the certificate fo= r signing, with indicated
> algorithm (which obviously needs t= o be supported by peer)? Wouldn't it
> make more sense to = talk about signature algorithms instead of key
> exchange algo= rithms. (Unless some key exchange that uses non-signing
> cert= ificates is added).

Yeah, this is just old text.


> > 6.3.6. (Server Configurati= on)
>=C2=A0
> Use TTL instead of of explicit time= for expiration, as broken clocks
> are abound (also, just 32-= bit field that only goes up to 2106 or so)?

Here&#= 39;s my argument for explicit time:
We might in the future want t= o allow some kind of offline signing
(potentially, as Hugo has su= ggested, with a special bit in the
certificate). In that case, it= would be really nice to have
an absolute expiration time for obv= ious reasons.


> Also, considerin= g the dangers of configuration, it might be appropriate
> to h= ave other permission flags (especially client and server auth) too?

I could see client auth, as in "I will want you to d= o client auth"
but why server auth, since once you have the = configuration, you
have continuing auth.


> Also, Could be useful for client to know what ciphers = it can use for
> 0-RTT data?

This is = a possibility, but I was more thinking that they would reuse
the = same ones as were negotiated here. More on this shortly.



> > 6.3.7. (Server Certificate V= erify)
>=C2=A0
> Should PRF hash designation be a= dded in order to avoid attacks from
> weak PRF hashes?

Could you say more about this?

<= br>
> I think note about checking signature algorithm against = ciphersuite
> should be removed.

This= seems to interact with the a la carte discussion.


> Also, with regards to complications of DSA, just dump = it? :-)

I'm fine with that if the chairs decla= re consensus on it.


> > 6.3.9= . (Client Certificate)
> >
> Doesn't Certi= ficateRequest override algorithms anyway (and CR isn't an
>= ; extension)?

Sorry, I'm not clear on what tex= t you are sad about.


> Again, co= uld use RFC7250 instead of RFC5081 as an example?

= Yes.


> > 6.3.10. (Client Cert= ificate Verify)
>=C2=A0
> Similar problems as in = DSA for server auth. And missing identifier
> for PRF too.

Sorry, can you expand on this.


> > 6.3.11. (New Session Ticket Message)
= >=C2=A0
> Eh, if server starts transmitting immediately wit= hout waiting for
> client Finished (as is permitted for case w= here 1-RTT client auth
> is not performed), it can't resum= e the session?

Good point. This seems like a silly= restriction, so let's remove it.


> > 7.2.3. (Elliptic Curve Diffie-Hellman)
>=C2=A0
> Probably needs different description for Curve25519 and Curve4= 48.
> Those are functions that take in octet strings and outpu= t octet strings
> (32 or 56 bytes).

N= ow that those drafts are stable will see if I can incorporate.

> > 11. (IANA Considerations)
&= gt;=C2=A0
> Yeah, looks to need a rewrite. Doesn't registe= r the new stuff, and
> furthermore has problems like:
>=C2=A0
> - signature_algorithms is already defined by RF= C5246.
> - SignatureAlgorithm registry is already defined.
> - HashAlgorithm registry is already defined.
>=C2= =A0
> > A.4. (The Cipher Suite)
>=C2=A0
<= div>> Probably remove note about 001C and 001D, since lots of ciphersuit= es are
> now reserved to avoid collisions with old ones.
=

>=C2=A0
> > C.1. (Random Number Gene= ration and Seeding)
> Replace SHA-1 with SHA-256?
&g= t;=C2=A0
> The example is completely obsolete. Any sort of mod= ern PCs have much
> faster timers (some reaching multi-GHz rat= es) and one really should use
> Operating System for (seeding)= random numbers.
>=C2=A0
> > C.4. (Implementat= ion Pitfalls)
>=C2=A0
> - Do you handle required = handshake messages being missing or handshake
> =C2=A0 message= s being in wrong order properly (i.e. terminate the connection)?
= >=C2=A0
> Also, ECDSA signing operations need timing protec= tion.
>=C2=A0
> s/DSA/ECDSA/ in seeding? And shou= ldn't k be determinstically generated?


Thanks for the suggestions. Will edit.

> > E.1.1. (Authentication and Key Exchange)
I plan to rewrite all of E.


> Would be useful to list what can be used to authenticate peers, = in
> practicular, are the following valid:
>=C2= =A0
> - Signing TLS-Unique value?
> - Signing val= ue from TLS-EXPORTER?

I think we should generate a= n explicit TLS-channel-binding output
and recommend people use th= at.

Thanks again,
-Ekr


On Wed, = Jul 15, 2015 at 7:15 AM, Ilari Liusvaara <ilari.liusvaara@elisan= et.fi> wrote:
Let's rev= iew: draft-ietf-tls-tls13-07

This is abridged version of mail I sent earlier, but was too large for
the list due to its sheer size.

(Note: I omitted some stuff I saw recently discussed (e.g. pruning
unused crypto algorithms) or I remember discussed. I didn't explicitly<= br> check issue list when doing this).

Note: The issue list could use some cleanup. It has multiple duplicate
issues (especially about fixing THS) and also some issues that no longer look applicable.


> Header

Isn't 4346 already obsoleted by 5246, which this document also obsolete= s?

4366 seems to be jointly obsoleted by 5246 and 6066.

5246 and 5077 are not in numerical order, whereas the rest are.

> 1. (Introduction)

DSA should be replaced by ECDSA (DSA is pretty much obsolete)?

> 1.2. (Major Differences from TLS 1.2)

Is this meant to be changelog or list of changes? It in current form
looks more like a changelog.

> 4.9.1. (Digital Signing)

I think someone wanted randoms back here in order to support privilege
separation (which I think is important to support, I consider it much
more important than being "HSM friendly")?

Reading what current draft of 4492-bis says, the hash function used is
determined by signature_algorithms (or presumably the corresponding
mechanism in CertificateRequest for client certs).

Also, to my knowledge, there is no mechanism to indicate in ECDSA
certificate what hash algorithms are allowed.

> 4.9.2. (Authenticated Encryption with Additional Data (AEAD))

The example looks like it belongs to section 4.9.1, as it is about
signatures, not AEAD construct.

> 5. (The TLS Record Protocol)

Documenting the security properties of TLS would be useful...

The lack of record length hiding may be problematic in protocols that
have no place for cover traffic (e.g. can DNS requests contain padding,
DPRIVE WG is apparently planning on putting DNS into (D)TLS?).

> 5.2.1. (Fragmentation)

Zero-length fragments of application data are very much visible in
ciphertext (unless record padding is added), so those are not currently
useful as traffic analysis countermeasure.

> 5.2.2. (Record Payload Protection)

There looks to be latter limits that restrict ciphertext size to 2^14
+1024, which is smaller than 2^14+2048 here (but those limits might be
tightened further).

As for amount of expansion needed for length-hiding, I think that being
able to represent 16384-byte record with no padding would be enough
(since record sizes cap at 16384 bytes anyway).

> 6. (The TLS Handshaking Protocols)

Are encryption keys, finished value (tls-unique) and exporter secret
part of session or not?

> 6.1.1. (Closure Alerts)

The semantics of closure alerts seem incompatible with half-closes,
which some protocols actually use.

> 6.1.2. (Error Alerts)

Could use another example of warning alert, now that no_renegotiation
is not a warning anymore?

> 6.2.1. (Incorrect DHE Share)

EncryptedExtensions is marked optional in Figure 2, but not Figure 1?

The relationship between session hash and handshake restarts seems
like a hairy problem.

Also, I figured out a downgrade attack that works against careless
_server_ (not requiring client to do anything else than have weak
crypto enabled). Continuing hashes looks to block that attack.

It involves attacker sending ClientHello with arbitrary parameters
that triggers a retry (very easy to trigger a retry), eating the
reply, followed by sending client's original ClientHello. That
could trigger crypto downgrade in some badly made servers.

> 6.2.2. (Cached Server Configuration)

Issue #184 manifests here too. I think both accepting and provoding
configuration in the same handshake is sensible (key rollover), and
later the draft talks about exactly that case.

Also, maybe note that provoding the message does not alter the
configuration hash (even if there is no existing one) could be useful.

> 6.2.3. (Zero-RTT Exchange)

No EncryptedExtensions?

How would the server know when 0-RTT data ended, so it could send its
ServerHello?

Also, how is the 0-RTT data bound to session if accepted, or is there
a security analysis for leaving this binding out?

Can anyone expand on the note about impersonation with compromised
server key? I can't offhand figure out how attacker can calculate
server-side ES (without having also compromised (possibly former)
client or (current) server exchange key).

> 6.3. (Handshake Protocol)

Missing encrypted_extensions (it is a handshake message, right)?

> 6.3.1.1. (Client Hello)

The non-match case gives HelloRetryRequest, not ServerHello, right?

s/should/SHOULD/ in description of session_id?

I don't think client extensions are optional anymore in TLS 1.3 (being<= br> required for successful handshake.

Also, TLS 1.2 servers that care about security (are there actually any?) already require extensions for successful handshake.

> 6.3.1.2. (Server Hello)

Well, at least it wouldn't be backward compatiblity hazard to remove session_id_len, since it comes after server version.

Note: Unlike client extensions, I think server extensions might be empty in TLS 1.3 handshake (since extensions required for GDHE_CERT type key
exchanges are not replied to by server).

> 6.3.1.3. (Hello Retry Request)

server_version and cipher_suite in HRR seem bit dangerous to me. If
HashAlgorithm contained all PRF hashes (currently it does), one could
use that to designate PRF hash.

Merging DTLS cookies might be a good idea. However, then group mismatch
wouldn't be the only source of failure (which needs some text adjustmen= t
about the selected_group check).

s/use for/add to/ in description of selected_group?

What happens if Ciphersuite and NamedGroup don't match between HRR
and SH/SKS? I expect there be clients that don't check, no matter if it=
is MUST or not.

Heck, I recently heard of servers that only partially(!!!) check client
Finished (or omit the check entierely).

> 6.3.1.4. (Hello Extensions)

supported_groups is 10, right?

Also, for matter of protocol testing, could be useful to give some
free values to temporary squat on for extensions that aren't stable
yet.

The restriction on extensions appearing also holds for
EncryptedExtensions, not just SH or HRR.

It could also be useful to deprecate some extensions (client MAY send
for backwards compat, server MUST NOT select).

Some candidates:
- truncated_hmac: Block modes have been removed.
- encrypt_then_mac: Block modes have been removed.
- extended_master_secret: The THS bug is fixed anyway.
- sessionticket TLS: Session tickets are deprecated.
- renegotiation_info: The renego bug is fixed anyway.

The interaction of some extensions with PSK-based resumption isn't
that clear. This is further complicated by the fact that PSK can also
start a new session.

Reference to "error alerts". Should that be "fatal alerts&qu= ot;?

The part about being careful with extensions modifying handshake
presumably also goes for functions that are sometimes used for
authentication like TLS-EXPORTER or TLS-UNIQUE.

> 6.3.1.4.1. (Signature Algorithms)

Anonymous should be removed. It is apparently not used (there is reference<= br> to another section saying that section uses it, but I can't find in tha= t
section how it is actually used).

Description of signature refers to 6.3,2, which is about SKS, which does not seem to have anything to do with signatures (leftover from TLS 1.2?)
Then in description of the extensions there is reference to 6.3.4 and
6.3.2. 6.3.4 looks relevant, 6.3.2. doesn't look so.

Also, making signature_algorithms mandatory would allow dropping the
backward compatiblity special cases from here.

There is text that talks about "offering prior versions". Does th= at
refer to insecure version downgrade (I don't suppose TLS 1.1 maximum client would care about what TLS 1.3 spec says).

> 6.3.1.4.2. (Negotiated Groups)

One chould add Curve25519 and Curve448, and the corresponding
signature groups (signature groups when CFRG signatures become
stable).

> 6.3.1.5.1. (Diffie-Hellman Parameters)
> 6.3.1.5.2. (ECDHE Parameters)

Drop the wrappers? Then DHE and ECDHE could be unified (the unification
is currently blocked by different lengths of the length field).

The point description might make it more clear that encodings are per-
curve (altough most curves use X9.62).

Does the note about only single point format apply to signatures too
(if so, ec_point_formats could be deprecated).

Regarding CFRG curves, the current draft (for TLS 1.2) specifies use
of the native point format (32/56 octets) as if it was uncompressed.

> 6.3.1.5.4. (Pre-Shared Key Extension)

Client SHOULD offer at most two PSK identities (one for DH-PSK,
the other for pure-PSK)?

This would imply that one can't resume pure-PSK sessions, but that
does not look to be useful anyway.

Also, could be useful to state that the PSK identity hint from
previous versions has been deprecated.

> 6.3.1.5.5. (Early Data Indication)

s/MUST not/MUST NOT/ in description of early_data with client auth?

Also, I would say that 0-RTT data with 0-RTT auth is more dangerous than 0-RTT data with 1-RTT auth (for reasons mentioned earlier in the draft).
Eeh, the rule for detecting end of 0RTT data, isn't the next client
handshake message from the next flight at least in some cases (and
waiting would obviously deadlock)?

Again, how is binding of early handshake messages done (or security
analysis showing this unnecressary)?

Client receiving rejection knows that auth failed and data failed, it
might try to fix things up in its next flight.

As for what to sign for client auth, the ClientHello and Certificate
(at least)? One thing to note is that if verify contains randoms, then
server_random isn't available.

Regarding finished, isn't Finished in second flight? Or is this another=
client Finished?

Regarding cryptographic parameter set, I think one better prepare for
failure (there are multiple causes of server failing to compute keys or
decrypt data).

Also, how does known_configuration interact with PSK (other than
configurations seemingly not being usable with PSK)?

Also, the record protection used for early handshake messages should be
indicated.

I think there are basically two things to signal for 0RTT:
- What key material is used (either by PSK ID or configuration ID)
- What record protection (and KDF to derive keys) is used?

Tying the latter to client offered ciphersuites is probably not wanted.

> 6.3.2. (Server Key Share)

Add that connection will be rekeyed immediately after this message, and
that it MUST be the last message in record it is in?

> 6.3.3. (Encrypted Extensions)

Some of the figures have this as mandatory, some optional. Which is it?

Yeah, would be good to have explicit list of what goes to SH, and what
goes to EE.

Also, the list is affected by #184, as some extensions introduce extra
messages (esp. status_request{,_v2} and signed_certificate_timestamp).

> 6.3.4. (Server Certificate)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The certificate MUST be appropriate for the = negotiated cipher
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suite's key exchange algorithm and any n= egotiated extensions.

If signature_algorithms is mandatory, this would then key to that for
signature algorithm, not ciphersuites (and even if it isn't, it would then key to its fallback default).

Could change example of alternative certificate formats to RFC7250 (it
seems better designed than RFC5081).

Doesn't TLS 1.3 always use the certificate for signing, with indicated<= br> algorithm (which obviously needs to be supported by peer)? Wouldn't it<= br> make more sense to talk about signature algorithms instead of key
exchange algorithms. (Unless some key exchange that uses non-signing
certificates is added).

> 6.3.6. (Server Configuration)

Use TTL instead of of explicit time for expiration, as broken clocks
are abound (also, just 32-bit field that only goes up to 2106 or so)?

Also, considering the dangers of configuration, it might be appropriate
to have other permission flags (especially client and server auth) too?

Also, Could be useful for client to know what ciphers it can use for
0-RTT data?

> 6.3.7. (Server Certificate Verify)

Should PRF hash designation be added in order to avoid attacks from
weak PRF hashes?

I think note about checking signature algorithm against ciphersuite
should be removed.

Also, with regards to complications of DSA, just dump it? :-)

> 6.3.9. (Client Certificate)
>
Doesn't CertificateRequest override algorithms anyway (and CR isn't= an
extension)?

Again, could use RFC7250 instead of RFC5081 as an example?

> 6.3.10. (Client Certificate Verify)

Similar problems as in DSA for server auth. And missing identifier
for PRF too.

> 6.3.11. (New Session Ticket Message)

Eh, if server starts transmitting immediately without waiting for
client Finished (as is permitted for case where 1-RTT client auth
is not performed), it can't resume the session?

> 7.2.3. (Elliptic Curve Diffie-Hellman)

Probably needs different description for Curve25519 and Curve448.
Those are functions that take in octet strings and output octet strings
(32 or 56 bytes).

> 11. (IANA Considerations)

Yeah, looks to need a rewrite. Doesn't register the new stuff, and
furthermore has problems like:

- signature_algorithms is already defined by RFC5246.
- SignatureAlgorithm registry is already defined.
- HashAlgorithm registry is already defined.

> A.4. (The Cipher Suite)

Probably remove note about 001C and 001D, since lots of ciphersuites are now reserved to avoid collisions with old ones.

> C.1. (Random Number Generation and Seeding)

Replace SHA-1 with SHA-256?

The example is completely obsolete. Any sort of modern PCs have much
faster timers (some reaching multi-GHz rates) and one really should use
Operating System for (seeding) random numbers.

> C.4. (Implementation Pitfalls)

- Do you handle required handshake messages being missing or handshake
=C2=A0 messages being in wrong order properly (i.e. terminate the connectio= n)?

Also, ECDSA signing operations need timing protection.

s/DSA/ECDSA/ in seeding? And shouldn't k be determinstically generated?=

> E.1.1. (Authentication and Key Exchange)

Would be useful to list what can be used to authenticate peers, in
practicular, are the following valid:

- Signing TLS-Unique value?
- Signing value from TLS-EXPORTER?

Both have been seen in the wild, so these better be secure ways. This
also goes for "anonymous" key exchange.

> E.1.2. (Version Rollback Attacks)

Is the note about PKCS #1 block type 2 about RSA key exchange, which is
deprecated?


-Ilari

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

--f46d0438eb9d8bea1b051af0a7ab-- From nobody Wed Jul 15 21:45:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CD61B308C for ; Wed, 15 Jul 2015 21:45:08 -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 wdTSP9nE0U3W for ; Wed, 15 Jul 2015 21:45:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C4E1B3092 for ; Wed, 15 Jul 2015 21:45:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 25C45284D2B; Thu, 16 Jul 2015 04:45:06 +0000 (UTC) Date: Thu, 16 Jul 2015 04:45:06 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150716044505.GZ28047@mournblade.imrryr.org> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55A70C01.8010907@gmail.com> <201507160017.29371.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507160017.29371.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 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: Thu, 16 Jul 2015 04:45:08 -0000 On Thu, Jul 16, 2015 at 12:17:28AM -0400, Dave Garrett wrote: > Side question: what is the meaning of the "r" in the naming convention we > use? (e.g. secp521r1, & sect571r1 vs. sect571k1) The "r" means that a mysterious seed can be used to "verify" that the curve paramets are ("nothing up my sleeve") *r*andom. -- Viktor. From nobody Wed Jul 15 22:07:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F4B1A03A2 for ; Wed, 15 Jul 2015 22:07:51 -0700 (PDT) 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 cjKznISQxD0K for ; Wed, 15 Jul 2015 22:07:50 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F421A039C for ; Wed, 15 Jul 2015 22:07:49 -0700 (PDT) Received: by oihq81 with SMTP id q81so43289152oih.2 for ; Wed, 15 Jul 2015 22:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AALueGJI8REIq+rssK/ZbbPw6lNfcxAWPNzBlaLOkM0=; b=ktgnd1epEub+gs4QVOX/VUlvI2a92BrAgYTpwuRKTuOV2kHJG0MhTKZR/bfjTX60SB YrtJYbXzUhRPzzmIc41agYuv02pg6Q1uUNBvo2js03Ecyr7sf+Fk3LDoONKEJwZpTLsq nJq91wT8kVBbhomMFpWaXLkXJe75BKPZMg+18w2jfy75pL2EhXuOaiANAwQdZAuRSrRS G9/Jw4k//NGZP5lujEt+gAWJ26kbd8cGT7oqsZC6ebD1nilN0dNPRMv6AyPP3KYGqv0b GqewXuk3EUrzuq0gT4o7DhMgYtrAvtajfJAkgkL8Z5Ha/56vh1z4YjBsk3Bh7Tx91HUH /fYw== X-Received: by 10.60.92.198 with SMTP id co6mr6855144oeb.3.1437023269397; Wed, 15 Jul 2015 22:07:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.176 with HTTP; Wed, 15 Jul 2015 22:07:29 -0700 (PDT) In-Reply-To: References: <201507151413.22408.davemgarrett@gmail.com> <20150715211140.GU28047@mournblade.imrryr.org> From: Tony Arcieri Date: Wed, 15 Jul 2015 22:07:29 -0700 Message-ID: To: Jeffrey Walton Content-Type: multipart/alternative; boundary=047d7b33d54481ad06051af70d51 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 05:07:51 -0000 --047d7b33d54481ad06051af70d51 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 15, 2015 at 8:52 PM, Jeffrey Walton wrote: > My bad... I meant over the binary curves. Per my comments on the other thread ("selection criteria for crypto primitives"), I think binary curves don't instill confidence and should probably be removed -- Tony Arcieri --047d7b33d54481ad06051af70d51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 8:52 PM, Jeffrey Walton <noloader@gmail.com> wrote:
= My bad... I meant over the binary curves.

Per my= comments on the other thread ("selection criteria for crypto primitiv= es"), I think binary curves don't instill confidence and should pr= obably be removed

--
Tony Arcieri
--047d7b33d54481ad06051af70d51-- From nobody Thu Jul 16 03:08:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78751B37DE for ; Thu, 16 Jul 2015 03:08:45 -0700 (PDT) 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 V2AFaq_cI4a5 for ; Thu, 16 Jul 2015 03:08:43 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0632.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BB31A8941 for ; Thu, 16 Jul 2015 03:08:42 -0700 (PDT) Received: from DB3PR04MB027.eurprd04.prod.outlook.com (10.242.136.150) by DB3PR04MB028.eurprd04.prod.outlook.com (10.242.136.152) with Microsoft SMTP Server (TLS) id 15.1.213.14; Thu, 16 Jul 2015 10:08:22 +0000 Received: from DB3PR04MB027.eurprd04.prod.outlook.com ([169.254.6.215]) by DB3PR04MB027.eurprd04.prod.outlook.com ([169.254.6.215]) with mapi id 15.01.0213.000; Thu, 16 Jul 2015 10:08:22 +0000 From: Arnaud KAISER To: Nikos Mavrogiannopoulos , "tls@ietf.org" Thread-Topic: [TLS] New version of draft-lonc-tls-certieee1609-01.txt Thread-Index: AdCz9Tm9D8nVaxGkT5W0tzCJM20T9AGV/tcAAViEP7A= Date: Thu, 16 Jul 2015 10:08:22 +0000 Message-ID: References: <1436449396.6877.4.camel@redhat.com> In-Reply-To: <1436449396.6877.4.camel@redhat.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none; x-originating-ip: [192.93.124.97] x-microsoft-exchange-diagnostics: 1; DB3PR04MB028; 5:GUB9wlBSdPpHXNwduimHjZlWFesKKnGluURCVT8EIB8G45mm02jOqjA8QMv+3Mcv7l8O2wthMj2hpRjuGUxbI9NpIF72/fobiD/xg758RNpyPIvhseEdoqYwYaHu/3epI4iOb1zVXlkH7dcgggtIWw==; 24:Y33eQYXB0vZrtlQSJKXhaHNSPdMGVLIihIPj8cJBOw+5Z/1+GdiuV0lwhyGwKjunCB4n1YRZ2RjTAcfBih3gqfOzFDrcbbQ0WaMdfYLzG94=; 20:AuhctS0B3+0njMqx5M/STH9/9UQRbt4g7p7liUQEQyQaQtCVHp6YnJ2Sq7Hv96GOxhPmp1OfoJFfQIxtt6fZOg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB028; db3pr04mb028: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR04MB028; BCL:0; PCL:0; RULEID:; SRVR:DB3PR04MB028; x-forefront-prvs: 0639027A9E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377424004)(24454002)(2501003)(5003600100002)(87936001)(77156002)(76576001)(2656002)(5001770100001)(107886002)(66066001)(5001960100002)(92566002)(62966003)(5002640100001)(189998001)(102836002)(561944003)(54356999)(33656002)(2950100001)(2900100001)(86362001)(15975445007)(19580405001)(19580395003)(230783001)(122556002)(74482002)(46102003)(76176999)(74316001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR04MB028; H:DB3PR04MB027.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: irt-systemx.fr X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2015 10:08:22.4139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: efbb4c7c-8ac1-416d-bf30-791be86aad0b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR04MB028 Archived-At: Subject: Re: [TLS] New version of draft-lonc-tls-certieee1609-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, 16 Jul 2015 10:08:45 -0000 VGhhbmsgeW91IGZvciB0aGlzIGluZm9ybWF0aW9uLCB3ZSdsbCBoYXZlIGEgbG9vayBhdCB0aGF0 IGFuIHVwZ3JhZGUgdGhlIGRyYWZ0IGFjY29yZGluZ2x5Lg0KDQpSZWdhcmRzLA0KQXJuYXVkDQoN Ci0tLQ0KQXJuYXVkIEthaXNlcg0KUmVzZWFyY2ggRW5naW5lZXINCklSVCBTeXN0ZW1YDQo4LCBB dmVudWUgZGUgbGEgdmF1dmUNCjkxMTIwIFBhbGFpc2VhdSwgRnJhbmNlDQoNCi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogTmlrb3MgTWF2cm9naWFubm9wb3Vsb3MgW21haWx0bzpu bWF2QHJlZGhhdC5jb21dIA0KRW52b3nDqcKgOiBqZXVkaSA5IGp1aWxsZXQgMjAxNSAxNTo0Mw0K w4DCoDogQXJuYXVkIEtBSVNFUiA8YXJuYXVkLmthaXNlckBpcnQtc3lzdGVteC5mcj47IHRsc0Bp ZXRmLm9yZw0KT2JqZXTCoDogUmU6IFtUTFNdIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWxvbmMtdGxz LWNlcnRpZWVlMTYwOS0wMS50eHQNCg0KT24gV2VkLCAyMDE1LTA3LTAxIGF0IDEyOjA4ICswMDAw LCBBcm5hdWQgS0FJU0VSIHdyb3RlOg0KPiBEZWFyIG1lbWJlcnMgb2YgVExTIFdHLA0KPiAgDQo+ IEEgbmV3IHZlcnNpb24gKC0wMSkgb2YgZHJhZnQtbG9uYy10bHMtY2VydGllZWUxNjA5IGhhcyBi ZWVuIHN1Ym1pdHRlZC4gDQo+IFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvbmMtdGxzLWNlcnRpZWVlMTYwOS0wMQ0KPiAg DQo+IFRoZSBwcm9wb3NhbCBvZiB0aGlzIGRyYWZ0IGlzIHRvIGV4dGVuZCB0aGUgVExTIHByb3Rv Y29sIHRvIHN1cHBvcnQgDQo+IElUUy1zcGVjaWZpYyBjZXJ0aWZpY2F0ZXMgZGVmaW5lZCBieSBJ RUVFIGFuZCBFVFNJLg0KDQpIaSwNCiBUaGlzIGRyYWZ0IHVzZXMgdGhlIHJmYzYwOTEgY2VydF90 eXBlIGV4dGVuc2lvbi4gSWYgdGhhdCBpcyBub3QgaW50ZW50aW9uYWwsIHJmYzYwOTEgd2FzIG1h ZGUgb2Jzb2xldGUgYnkgcmZjNzI1MCB3aGljaCB1c2VzIHRoZSBzZXJ2ZXJfY2VydGlmaWNhdGVf dHlwZSBhbmQgY2xpZW50X2NlcnRpZmljYXRlX3R5cGUgZXh0ZW5zaW9ucyAoZXZlbiB0aG91Z2gg dGhlIHRleHQgZG9lc24ndCBtZW50aW9uIHRoYXQpLg0KDQpyZWdhcmRzLA0KTmlrb3MNCg0K From nobody Thu Jul 16 04:29:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255F31B39F0 for ; Thu, 16 Jul 2015 04:29:30 -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 8O9lXzY2RCqt for ; Thu, 16 Jul 2015 04:29:28 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCB81B39EE for ; Thu, 16 Jul 2015 04:29:27 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Jul 2015 07:29:22 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 16 Jul 2015 07:29:21 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Thu, 16 Jul 2015 07:29:21 -0400 From: Dan Brown To: Viktor Dukhovni , "tls@ietf.org" Thread-Topic: [TLS] (selection criteria for crypto primitives) Re: sect571r1 Thread-Index: AdC/uqfkb78N94uLW0qEgP5E41FxBA== Date: Thu, 16 Jul 2015 11:29:20 +0000 Message-ID: <20150716112916.5333071.99080.4433@certicom.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <53731489DD2998458C2154EA4A19F591@rim.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 11:29:30 -0000 ciBtZWFudCByYW5kb20gYXMgb3Bwb3NlZCB0byBrIHdoaWNoIG1lYW50IGtvYmxpdHouwqANCg0K dGhlIGtvYmxpdHogY3VydmUgaGFkIGEgYW5kIGIgY29lZmZpY2llbnRzIGxpa2UgMCBhbmQgMSwg YnV0IHRoZSByIGN1cnZlcyBoYWQgYSBhbmQgYiBkZXJpdmVkIGZyb20gb3V0cHV0IG9mIGhhc2gu Li4NCg0KYmFjayBpbiAyMDAwIHdoZW4gU0VDMiBjYW1lIG91dCBpbnRyb2R1Y2luZyB0aGVzZSBu YW1lcyAoYW5kIE9JRFMpIHRoZSBhdHRhY2tzIG9uIHNwZWNpYWwgY3VydmVzIChNT1YgYW5kIFNB U1MgYXR0YWNrcykgd2VyZSBtdWNoIG1vcmUgcmVjZW50LCBhbmQgdGhlIHIgdHlwZSB3b3VsZCBh dm9pZCBhbnkgc2ltaWxhciBhdHRhY2tzLCBpZiBzb21lIHdlcmUgdG8gZm9sbG93LiBUaGUgaWRl YSB0aGF0IHNvbWVib2R5IGNvdWxkIHNlYXJjaCBhIG1pbGxpb24gY3VydmVzIHRvIGZpbmQgYSAx LWluLWEtbWlsbGlvbiB3ZWFrbmVzcyB3YXMga25vd24gYnV0IGJ5IGNvbXBhcmlzb24gd2FzIGEg ZmFudGFzeSwgc28gYSBtdWNoIG1vcmUgcmVtb3RlIHRocmVhdC4gSW4gMTUgeWVhcnMsIGZvciBw cmltZSBmaWVsZCBFQ0Mgbm8gbmV3IGF0dGFja3MgaGF2ZSBzaG93biwgc28gb25lIGNhbiBmb2N1 cyBvbiBtb3JlIHNwZWN1bGF0aXZlIHRocmVhdHMsIGFuZCB0byBjaG9vc2UgYmV0dGVyIHNlZWRz LCBldGMu4oCODQrigI4NCsKgIE9yaWdpbmFsIE1lc3NhZ2UgwqANCkZyb206IFZpa3RvciBEdWto b3ZuaQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMTYsIDIwMTUgMTI6NDUgQU0NClRvOiB0bHNAaWV0 Zi5vcmcNClJlcGx5IFRvOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSAoc2VsZWN0 aW9uIGNyaXRlcmlhIGZvciBjcnlwdG8gcHJpbWl0aXZlcykgUmU6IHNlY3Q1NzFyMQ0KDQpPbiBU aHUsIEp1bCAxNiwgMjAxNSBhdCAxMjoxNzoyOEFNIC0wNDAwLCBEYXZlIEdhcnJldHQgd3JvdGU6 DQoNCj4gU2lkZSBxdWVzdGlvbjogd2hhdCBpcyB0aGUgbWVhbmluZyBvZiB0aGUgInIiIGluIHRo ZSBuYW1pbmcgY29udmVudGlvbiB3ZQ0KPiB1c2U/IChlLmcuIHNlY3A1MjFyMSwgJiBzZWN0NTcx cjEgdnMuIHNlY3Q1NzFrMSkNCg0KVGhlICJyIiBtZWFucyB0aGF0IGEgbXlzdGVyaW91cyBzZWVk IGNhbiBiZSB1c2VkIHRvICJ2ZXJpZnkiIHRoYXQNCnRoZSBjdXJ2ZSBwYXJhbWV0cyBhcmUgKCJu b3RoaW5nIHVwIG15IHNsZWV2ZSIpICpyKmFuZG9tLg0KDQotLSANClZpa3Rvci4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxp c3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bHMNCg== From nobody Thu Jul 16 06:08:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF8B1B3AC7 for ; Thu, 16 Jul 2015 06:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 QoMs463OPjUk for ; Thu, 16 Jul 2015 06:08:16 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70CC11B3AB8 for ; Thu, 16 Jul 2015 06:08:16 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t6GD8EvF025401; Thu, 16 Jul 2015 09:08:14 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Tony Arcieri , Rene Struik Thread-Topic: [TLS] (selection criteria for crypto primitives) Re: sect571r1 Thread-Index: AdC/yHkALNgqnPrruUqZIET3JjOxjQ== Date: Thu, 16 Jul 2015 13:08:14 +0000 Message-ID: <20150716130822.17764416.68011.9639@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============2097343213==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-16_03:2015-07-16,2015-07-16,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-1506180000 definitions=main-1507160201 Archived-At: Cc: "" Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 13:08:19 -0000 --===============2097343213== Content-Type: multipart/alternative; boundary="===============0103831495==" MIME-Version: 1.0 --===============0103831495== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSB0aGluayB5b3UgY29udmluY2VkIG1lLiBBbmQgdG8gdGhpbmsgb2YgaXQsIEkgbmV2ZXIgZGlk IGxpa2UgYmluYXJ5IGN1cnZlcy4gOi0pCgpObyBiaW5hcnkgY3VydmVzIGZvciB0aGUgZnV0dXJl LiA6LSkKClRueCEKClNlbnTCoGZyb23CoG15wqBCbGFja0JlcnJ5wqAxMMKgc21hcnRwaG9uZcKg b27CoHRoZSBWZXJpem9uwqBXaXJlbGVzc8KgNEfCoExURcKgbmV0d29yay4KRnJvbTogVG9ueSBB cmNpZXJpClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNSwgMjAxNSAyMjozMgpUbzogUmVuZSBTdHJ1 aWsKQ2M6IDx0bHNAaWV0Zi5vcmc+ClN1YmplY3Q6IFJlOiBbVExTXSAoc2VsZWN0aW9uIGNyaXRl cmlhIGZvciBjcnlwdG8gcHJpbWl0aXZlcykgUmU6IHNlY3Q1NzFyMQrigI4KVG8gcmVzcG9uZCBt b3JlIHNwZWNpZmljYWxseSB0byB5b3VyIGNvbmNlcm5zOgoKT24gV2VkLCBKdWwgMTUsIDIwMTUg YXQgNjo0MiBQTSwgUmVuZSBTdHJ1aWsgPHJzdHJ1aWsuZXh0QGdtYWlsLmNvbT4gd3JvdGU6Ckl0 IHNlZW1zIHBydWRlbnQgdG8ga2VlcCBzb21lIGRpdmVyc2l0eSBvZiB0aGUgZ2VuZSBwb29sIGFu ZCBub3Qgb25seSBoYXZlIGN1cnZlcyBkZWZpbmVkIG92ZXIgcHJpbWUgY3VydmVzLiBTaW1pbGFy bHksIG9uZSBzaG91bGQgcGVyaGFwcyBoYXZlIHNvbWUgZGl2ZXJzaXR5IG9mIGdlbmUgcG9vbCBj cml0ZXJpYSB3aXRoaW4gdGhlIHNldCBvZiByZWNvbW1lbmQgY3VydmVzIGFuZCBub3Qgb25seSBp bmNsdWRlIHNwZWNpYWwgcHJpbWVzLiBTaG91bGQgc29tZSBwcm9ibGVtIHdpdGggYSBwYXJ0aWN1 bGFyIHN1YmNsYXNzIHNob3cgdXAgb3ZlciB0aW1lLCBvbmUgdGhlbiBhdCBsZWFzdCBoYXMgb3Ro ZXIgY2xhc3NlcyBhdmFpbGFibGUuCgpCaW5hcnkgY3VydmVzIGluIHBhcnRpY3VsYXIgYXJlIHNo b3dpbmcgd2FybmluZyBzaWducyBvZiBwb3RlbnRpYWwgZnV0dXJlIHNlY3VyaXR5IGlzc3VlczoK Cmh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTUvMzEwLnBkZgoKSSB0aGluayBldmVuIGlmIHdl IGRvbid0IGNvbXBsZXRlbHkgcGFyZSBkb3duIHRoZSBUTFMgY3VydmUgcG9ydGZvbGlvIHRvIHRo ZSBsaXN0IEkgc3VnZ2VzdGVkLCBpZiBub3RoaW5nIGVsc2UgSSB3b3VsZCBsaWtlIHRvIHNlZSBi aW5hcnkgY3VydmVzIHJlbW92ZWQuCgotLSAKVG9ueSBBcmNpZXJpCuKAjg== --===============0103831495== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
I think you con= vinced me. And to think of it, I never did like binary curves. :-)

No binary = curves for the future. :-)


= =
=
=
From: Tony Arcieri
Sent: Wednesday, July 15, 2015 22:= 32
To: Rene Struik
Cc: <tls@ietf.org&g= t;
Subject: Re: [TLS] (selection criteria for crypto primi= tives) Re: sect571r1
=E2=80=8E
To respond more specifically to your concerns:

On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik <rstruik.ext@gmail.com><= /span> wrote:
It seems prudent to keep some diversity of the gene pool and not only have = curves defined over prime curves. Similarly, one should perhaps have some d= iversity of gene pool criteria within the set of recommend curves and not o= nly include special primes. Should some problem with a particular subclass show up over time, one then at lea= st has other classes available.

Binary curves in particular are showing warning signs of potential fut= ure security issues:


I think even if we don't completely pare down the TLS curve portfolio = to the list I suggested, if nothing else I would like to see binary curves = removed.

--
Tony Arcieri
=E2=80=8E
--===============0103831495==-- --===============2097343213== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcxNjEzMDgyMFowLwYJKoZIhvcNAQkEMSIEIHsgzipO35dB TqvQHMJTQ6/ccGvN8wnWVrG/2UDIN+Q4MAsGCSqGSIb3DQEBCwSCAQAsas+FjBW+uu/xc7TG7DSQ OlwpoMcKpcLzKdZavyojYiUGYJbn1xL2Paa6fNmUza1YYmI7iySUiAqOJXYPYPAVrk+IUUXmpGXx VwBw4Y48qZgETluOkfimwgRtD9FRBtmyvfIJFlLkCYUwgBZ1ESdARtFobxtqW+eqD6v5oBcNxGs3 7BvMBfoqiePJRW/PUpMpH9X0/VRaUwwO3Cdzd/oecv9nGpzniNbadfBdGj9Gt8OC81mC6KCKtiS6 ZZB8wJcMbrR5SVk/7ebul0Oyy9JXSigvezC3hE+u25t/DGgsBcGxrQVOzeehSxg6KOv/JYAXqjkc bKIhu1KSbORv5pjUAAAAAAAA --===============2097343213==-- From nobody Thu Jul 16 06:17:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636D71B3AE9 for ; Thu, 16 Jul 2015 06:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 CaoqdPcLMg40 for ; Thu, 16 Jul 2015 06:17:55 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEBE1B3AE8 for ; Thu, 16 Jul 2015 06:17:55 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t6GDHsm1008948 for ; Thu, 16 Jul 2015 09:17:54 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Viktor Dukhovni , "tls@ietf.org" Thread-Topic: [TLS] sect571r1 Thread-Index: AdC/ydJsMp+RfY8ndkeaEOui9clAdw== Date: Thu, 16 Jul 2015 13:17:53 +0000 Message-ID: <20150716131802.17764416.72247.9643@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0377397776==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-16_03:2015-07-16,2015-07-16,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-1506180000 definitions=main-1507160204 Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 13:17:57 -0000 --===============0377397776== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I concurrent. Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the Verizon=A0Wirele= ss=A04G=A0LTE=A0network. =A0 Original Message =A0 From: Viktor Dukhovni Sent: Thursday, July 16, 2015 00:08 To: tls@ietf.org Reply To: tls@ietf.org Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 11:52:13PM -0400, Jeffrey Walton wrote: > > An auditor who believes that we can rigourously quantify the security > > of these curves precisely enough to say which is stronger or more > > closely "matches" AES-256, should be laughed out of the room and fired. > > Maybe so, but it is what it is. The IETF is probably not going to be > able to change it. Well, the auditor can't ask for curves with TLS that the specification deprecates. So removing oddball choices will help users fend off clueless checklist-wielding auditors. A modest amount of diversity is fine, but I would posit that anything beyond a (conservative, performant, backup) triple is counterproductive. Between the anticipated CFRG curves and the NIST prime curves, I think we already have a couple too many. The way I see it: conservative =3D Goldilocks performant =3D 25519 backup =3D P-256, P-384, P-521 (legacy triple) All the above should ultimately be MTI, with each peer prioritizing either "conservantive" or "performant", and legacy peers do the same with "P-256" or "P-384" (with P-521 as backup for both camps). If there are signs that all these are about to fail, and we still somehow are left with some curves we're willing to trust, we can change the mix then. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --===============0377397776== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcxNjEzMTgwMFowLwYJKoZIhvcNAQkEMSIEIMQM+rnMR6d9 t+tp8/XEB4vxLPb6z+EOhS0XyNGIUEJ7MAsGCSqGSIb3DQEBCwSCAQAN38rdJjh4ehxoG6FmdLlt wFvc+ZVGKWeOMMJ+EU/mcF4/2TlqiWoUwZaLIf4HmZc+gK7dp/IMGbWgnM9AMSXgpWVdT/YvDABe p2LaC5egAyjowNZYgRXfrQDgotSDJhv8O3A43spc6xuSHlzBtFlHfwK3fj1FvJCSgrUuGXqLRQ1F KOZBC7atgxj3J7cUpANQ0CM2eCb3k3mG2p8lDCPwRClwcOsj0UHxwDuJHrH8OOpmYXneDonDN4ev Nrc5ro9cpqewPvpUjgqAW5yQ1OojOf3sSs9kbQyaanJli7R1CZL5/69htA7rWSmGqLRkXd8CzI/t OrrvdVBRjSO0igNuAAAAAAAA --===============0377397776==-- From nobody Thu Jul 16 06:19:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FB91B3AF5 for ; Thu, 16 Jul 2015 06:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 4U1llrVKGv8Q for ; Thu, 16 Jul 2015 06:19:02 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5B61B3AEB for ; Thu, 16 Jul 2015 06:19:02 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t6GDJ1YH010935 for ; Thu, 16 Jul 2015 09:19:01 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Viktor Dukhovni , "tls@ietf.org" Thread-Topic: [TLS] sect571r1 Thread-Index: AdC/yfrJMp+RfY8ndkeaEOui9clAdw== Date: Thu, 16 Jul 2015 13:19:01 +0000 Message-ID: <20150716131909.17764416.60828.9646@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1154061635==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-16_03:2015-07-16,2015-07-16,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-1506180000 definitions=main-1507160204 Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 13:19:04 -0000 --===============1154061635== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Damn the spell-checkers. I CONCUR.=A0 :-) Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the Verizon=A0Wirele= ss=A04G=A0LTE=A0network. =A0 Original Message =A0 From: Blumenthal, Uri - 0553 - MITLL Sent: Thursday, July 16, 2015 09:18 To: Viktor Dukhovni; tls@ietf.org Subject: Re: [TLS] sect571r1 I concurrent. Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the Verizon=A0Wirele= ss=A04G=A0LTE=A0network. =A0 Original Message =A0 From: Viktor Dukhovni Sent: Thursday, July 16, 2015 00:08 To: tls@ietf.org Reply To: tls@ietf.org Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 11:52:13PM -0400, Jeffrey Walton wrote: > > An auditor who believes that we can rigourously quantify the security > > of these curves precisely enough to say which is stronger or more > > closely "matches" AES-256, should be laughed out of the room and fired. > > Maybe so, but it is what it is. The IETF is probably not going to be > able to change it. Well, the auditor can't ask for curves with TLS that the specification deprecates. So removing oddball choices will help users fend off clueless checklist-wielding auditors. A modest amount of diversity is fine, but I would posit that anything beyond a (conservative, performant, backup) triple is counterproductive. Between the anticipated CFRG curves and the NIST prime curves, I think we already have a couple too many. The way I see it: conservative =3D Goldilocks performant =3D 25519 backup =3D P-256, P-384, P-521 (legacy triple) All the above should ultimately be MTI, with each peer prioritizing either "conservantive" or "performant", and legacy peers do the same with "P-256" or "P-384" (with P-521 as backup for both camps). If there are signs that all these are about to fail, and we still somehow are left with some curves we're willing to trust, we can change the mix then. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --===============1154061635== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcxNjEzMTkwOFowLwYJKoZIhvcNAQkEMSIEILut3WjU3yQA Dn/HPQdwzUXyfaM2HapDpviUiWudTFWWMAsGCSqGSIb3DQEBCwSCAQA4B2gknM9+ZVe90ACpQuuC LJ1vJg5yVErT7U+cx/1MGoFlyKYkRL8NKnlIkMSO/iFqul8Cxx3G12EZZT2ZtfiBf6U+4+dYIfb1 2jTN4Zk7WEDoQ1lkMtGQdP6TLuabDkND1A+nEIF1XD7h/TZtT9bCkor6rFWghyjyubmtcw2Y9kDG ZlulnVqD2SLk4mT6RzCoUKDprU09MO4HkVeAzTsEiSaR3JSrZNHIs4qJA2MSQ5GGJPwOReKam7jg bNmCvfyfp8TApILnwgsZ+xXHlO5KuwQrQd70GVFpOavpUB1Dma2QXPPxH6lic+p6p/5nhovj4oQv FCs0KLJhggXnHycuAAAAAAAA --===============1154061635==-- From nobody Thu Jul 16 06:49:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0591B3BC6 for ; Thu, 16 Jul 2015 06:49:36 -0700 (PDT) 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 mfvRngG7etRm for ; Thu, 16 Jul 2015 06:49:34 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCB91B3BC5 for ; Thu, 16 Jul 2015 06:49:34 -0700 (PDT) Received: by iggp10 with SMTP id p10so13360756igg.0 for ; Thu, 16 Jul 2015 06:49:34 -0700 (PDT) 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; bh=cr4i89yS+Wt7iNZGSOQIBtGLpv6z0OOAM0YFzqPwcfE=; b=UdibqhatNpdbjbrAq0AKJ29EG5Fdu1DR7b41GtxTFEpuVZFJfZaK0MX4sMLvlpV9f5 FsemgbvnCFMiOxXMr+tpL1okhH03nEBOoc5LtkYnbGfwI9IYyk+/aOAAGhxgR0/UUXIg 9EQYp3/UCGJ8HjD8qOpFo8uZ5LR+y0Gli2vknp8zGd/zJx05P2X1V5PZafMUCeg4gwVO HfeZoeSRLuyF9PBya9DQC/LkxZOK7j4XXtk32eUAaRI9jy6DSRvB4EpgvfZhzvA6rwap AJl2QCtDUX2Qy2yCwr2/g9qlW2TjHX3TBWRxxejD1o/k/SrWsAoyW+DdpaC3yfjNaQb5 XIdA== X-Received: by 10.50.80.19 with SMTP id n19mr4416539igx.30.1437054573953; Thu, 16 Jul 2015 06:49:33 -0700 (PDT) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by smtp.gmail.com with ESMTPSA id q187sm5013811ioe.37.2015.07.16.06.49.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2015 06:49:33 -0700 (PDT) Message-ID: <55A7B66A.70709@gmail.com> Date: Thu, 16 Jul 2015 09:49:30 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0553 - MITLL" , Tony Arcieri References: <20150716130822.17764416.68011.9639@ll.mit.edu> In-Reply-To: <20150716130822.17764416.68011.9639@ll.mit.edu> Content-Type: multipart/alternative; boundary="------------080507030908040305080802" Archived-At: Cc: "" Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 13:49:36 -0000 This is a multi-part message in MIME format. --------------080507030908040305080802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Of potential interest to this group: Steven Galbraith's perspective on papers, such as IACR ePrint 2015-310: https://ellipticnews.wordpress.com/2015/04/13/elliptic-curve-discrete-logarithm-problem-in-characteristic-two/ Best regards, Rene On 7/16/2015 9:08 AM, Blumenthal, Uri - 0553 - MITLL wrote: > I think you convinced me. And to think of it, I never did like binary > curves. :-) > > No binary curves for the future. :-) > > Tnx! > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Tony Arcieri > *Sent: *Wednesday, July 15, 2015 22:32 > *To: *Rene Struik > *Cc: * > *Subject: *Re: [TLS] (selection criteria for crypto primitives) Re: > sect571r1 > > ‎ > To respond more specifically to your concerns: > > On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik > wrote: > > It seems prudent to keep some diversity of the gene pool and not > only have curves defined over prime curves. Similarly, one should > perhaps have some diversity of gene pool criteria within the set > of recommend curves and not only include special primes. Should > some problem with a particular subclass show up over time, one > then at least has other classes available. > > > Binary curves in particular are showing warning signs of potential > future security issues: > > https://eprint.iacr.org/2015/310.pdf > > I think even if we don't completely pare down the TLS curve portfolio > to the list I suggested, if nothing else I would like to see binary > curves removed. > > -- > Tony Arcieri > ‎ -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080507030908040305080802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Of potential interest to this group:

Steven Galbraith's perspective on papers, such as IACR ePrint 2015-310:
https://ellipticnews.wordpress.com/2015/04/13/elliptic-curve-discrete-logarithm-problem-in-characteristic-two/

Best regards, Rene

On 7/16/2015 9:08 AM, Blumenthal, Uri - 0553 - MITLL wrote:
I think you convinced me. And to think of it, I never did like binary curves. :-)

No binary curves for the future. :-)

Tnx!

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Tony Arcieri
Sent: Wednesday, July 15, 2015 22:32
To: Rene Struik
Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
‎
To respond more specifically to your concerns:

On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik <rstruik.ext@gmail.com> wrote:
It seems prudent to keep some diversity of the gene pool and not only have curves defined over prime curves. Similarly, one should perhaps have some diversity of gene pool criteria within the set of recommend curves and not only include special primes. Should some problem with a particular subclass show up over time, one then at least has other classes available.

Binary curves in particular are showing warning signs of potential future security issues:


I think even if we don't completely pare down the TLS curve portfolio to the list I suggested, if nothing else I would like to see binary curves removed.

--
Tony Arcieri
‎


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------080507030908040305080802-- From nobody Thu Jul 16 08:09:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2CE1A6F10 for ; Thu, 16 Jul 2015 08:09:45 -0700 (PDT) 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 4A-_PCZJ0HHi for ; Thu, 16 Jul 2015 08:09:41 -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 F15FE1A6EDB for ; Thu, 16 Jul 2015 08:09:40 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 325D01888D5; Thu, 16 Jul 2015 18:09:38 +0300 (EEST) Date: Thu, 16 Jul 2015 18:09:38 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150716150937.GA30989@LK-Perkele-VII> References: <20150715141523.GA13669@LK-Perkele-VII> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 15:09:45 -0000 On Wed, Jul 15, 2015 at 02:29:09PM -0700, Eric Rescorla wrote: Firstly, the 0-RTT binding and how does server know it ended thing: Assume that if 0-RTT is accepted, the contents affect crypto keys, channel binding values, finished messages, etc... >From this it follows that server needs to receive the entiere 0RTT data before sending its own Finished. But the server would need a non-0RTT message from client to know it has ended. Unfortunately, the next client message after 0RTT is client Finished, and that is waiting on server Finished. Which is obvious deadlock. In contrast, assume the assumption is not true, that is, contents of accepted 0-RTT do not affect crypto keys, etc. Where is the security analysis for that (e.g. with regards to modifying 0-RTT data)? > > > 6.1.1. (Closure Alerts) > > > > The semantics of closure alerts seem incompatible with half-closes, > > which some protocols actually use. > > True, but this has been in TLS since the beginning, so there presumably > should not be any TLS-using apps which depend on it. Do you think this > is a feature which we should add. Maybe not, the protocols using half-closes are pretty obscure (I think I have run into only one). (I did run such over TLS, possibly due to TLS library allowing breaking of TLS specifications here, but it sucked for various reasons, and I eventually ended up replacing the encryption layer. This was years ago). But there's also "stunnel" which is intended for tuneling protocols over TLS (I did try that too, it sucked even worse). And if protocol uses half-closes, those better work there. > > The relationship between session hash and handshake restarts seems > > like a hairy problem. > > > > Also, I figured out a downgrade attack that works against careless > > _server_ (not requiring client to do anything else than have weak > > crypto enabled). Continuing hashes looks to block that attack. > > > > It involves attacker sending ClientHello with arbitrary parameters > > that triggers a retry (very easy to trigger a retry), eating the > > reply, followed by sending client's original ClientHello. That > > could trigger crypto downgrade in some badly made servers. > > Do you think you could walk through this in more detail? I'm having > trouble understanding the issue. Assume server is bit poorly coded: It latches cryptographic parameters (ciphersuite, exchange group, etc...) on first ClientHello. Then attacker sending its own ClientHello that elicts HelloRetryRequest, eating that and then forwarding real ClientHello might result the server choosing weaker algorithms than if real ClientHello got sent directly. And unless handshake hash covers earlier tries, the handshake hash would still match on both sides (since the attacker-sent message and reply to it have been reset away from hash on server side, and client side never knows about the attacker), despite the fact that connection has been downgraded. > > Can anyone expand on the note about impersonation with compromised > > server key? I can't offhand figure out how attacker can calculate > > server-side ES (without having also compromised (possibly former) > > client or (current) server exchange key). > > Will see what I can do. Well, this was more me being interested on how such attack would work. > > > 6.3.1.2. (Server Hello) > > > > Well, at least it wouldn't be backward compatiblity hazard to remove > > session_id_len, since it comes after server version. > > I'm sold. However, that would change ServerHello parsing. Thinking about it, if one decides to be careful with message parsing, one needs to assign all new/modified TLS 1.3 handshake messages new IDs. Currently there is only one offending message type w.r.t. that: 14, which is server_configuration in 1.3 and server_hello_done in 1.2. Some other messages share IDs, but I think those are compatible (even CertificateVerify, as it is just one digital signature in both). > > What happens if Ciphersuite and NamedGroup don't match between HRR > > and SH/SKS? I expect there be clients that don't check, no matter if it > > is MUST or not. > > Depends on if we continue the hash. If not, I would imagine that the > handshake > succeeds. With that said, this is intended to be a client-side enforcement > of correct server behavior. Since the client's offered parameters are > the same as the ones it offered before (with just a new key in > ClientKeyShare) > the server should be picking the same parameters as before, no? Unless there is attacker interfering... > > Also, for matter of protocol testing, could be useful to give some > > free values to temporary squat on for extensions that aren't stable > > yet. > > I agree. Suggest you propose this as a PR. Might be good idea to stay good bit away from existing registrations, at least in forward direction, in case a new extension comes along. Maybe starting from 13000? And maybe something like: "early_data(TBD), //For testing: 13000", and similarly for others (except supported_groups, as that already has a codepoint). (The language might need some improvement). > > The restriction on extensions appearing also holds for > > EncryptedExtensions, not just SH or HRR. > > I wonder if we should relax these. Well, extensions that don't respect the client advertisment restriction seem to fall into two classes: - Truly advisory extensions. Can't change key computations nor introduce messages. These are obvious candidates for EncryptedExtensions. - Extended fatal alerts: Extensions that contain additional data about rejected connection, since fatal alerts themselves can't seem to contain extra data, and sending such thing to client not supporting one isn't bad, since the connection already can't work. Obviously go to ServerHello. Can't produce examples of first. Crazy idea for second would be "captive portal" indication (note, some captive portals have whitelist of HTTPS sites they allow access to). > > The part about being careful with extensions modifying handshake > > presumably also goes for functions that are sometimes used for > > authentication like TLS-EXPORTER or TLS-UNIQUE. > > We may be beyond that point. I don't think there are any extensions currently that affect those directly (and even the indirect ones are to be deprecated anyway). > > > 6.3.1.4.1. (Signature Algorithms) > > > > Anonymous should be removed. It is apparently not used (there is reference > > to another section saying that section uses it, but I can't find in that > > section how it is actually used). > > I think there is still a desire to have anonymous DH cipher suites. Anonymous is meant for program-internal placeholder for DH_anon? I can't find any place it is used on the wire. And sharing ciphersuites for DH_CERT and DH_ANON is kinda dangerous. > > There is text that talks about "offering prior versions". Does that > > refer to insecure version downgrade (I don't suppose TLS 1.1 maximum > > client would care about what TLS 1.3 spec says). > > It was just to make clear that people shouldn't be adopting this for older > versions. Should it be rephrased in terms of MUST NOT offer unless offering at least TLS 1.2 or something like that? > > > 6.3.1.4.2. (Negotiated Groups) > > > > One chould add Curve25519 and Curve448, and the corresponding > > signature groups (signature groups when CFRG signatures become > > stable). > > Yep. I think the drafts are now stable for this. There was brief exchange (not finished) if ECDH and ECSIG grops should be the same or not. > > > 6.3.1.5.4. (Pre-Shared Key Extension) > > > > Client SHOULD offer at most two PSK identities (one for DH-PSK, > > the other for pure-PSK)? > > My sense was just to offer a pile of identities, since they're > untyped anyway. Well, I think offering more than two identities (potential resumption of DH-PSK case) is pretty exotic. But there might be cases where more than two is usable. > > Also, I would say that 0-RTT data with 0-RTT auth is more dangerous than > > 0-RTT data with 1-RTT auth (for reasons mentioned earlier in the draft). > > It is. It's also important for some applications. That was in reference to restriction that if client auth is desried with 0-RTT data, it has to be 0-RTT too. And the danger is from acting on "authenticated" data (it is replayable after all). > > Regarding finished, isn't Finished in second flight? Or is this another > > client Finished? > > The client's Finished is in the second flight. Can you clarify this > question. It was regarding this: " - Whether we really want the Finished to not include the server's data at all." The diagram has Finished be in 2nd flight, so it should include server's data? > > > Regarding cryptographic parameter set, I think one better prepare for > > failure (there are multiple causes of server failing to compute keys or > > decrypt data). > > Can you say more about this? Well: - Client expecting resumption, which doesn't pan out. - Server having ECC certificate, and wanting to save bit of CPU under load (ECDH + sign is cheaper than 2xECDH.). - Client using configuration that has been revoked by server for some reason. - Client trying to use ciphersuite server does not support. - Client request being routed to new server that doesn't have the config keys. All those cause decrypt failure. Some are pretty unlikely, some are less so. > > Also, the record protection used for early handshake messages should be > > indicated. > > Can you expand on that? How does the client know what record protection algorithms are valid for 0RTT transmission for that server? > > Also, considering the dangers of configuration, it might be appropriate > > to have other permission flags (especially client and server auth) too? > > I could see client auth, as in "I will want you to do client auth" > but why server auth, since once you have the configuration, you > have continuing auth. Configs can do both server auth (which can be quite dangerous) and 0-RTT, which is much less so. > > > 6.3.7. (Server Certificate Verify) > > > > Should PRF hash designation be added in order to avoid attacks from > > weak PRF hashes? > > Could you say more about this? If server or client supports some very weak PRF algorithm (they shouldn't, but we know how practice looks like), could it be possible to forge signatures by causing the weak hash value collide with one from strong hash peer accepts? Also known as "hash firewalling" (too bad most firewall schemes in signatures are broken). > > I think note about checking signature algorithm against ciphersuite > > should be removed. > > This seems to interact with the a la carte discussion. And also EdDSA / CFRG-whatever. Reusing ciphersuites seems to assume explicit signaling overrides ciphersuites. > > Also, with regards to complications of DSA, just dump it? :-) > > I'm fine with that if the chairs declare consensus on it. As datapoint, either the scan that was used as basis of that curve pruning doesn't support DSA, or there are no servers that even have DSA certs. I think I heard some time back that there are only 4 (or some other very small number) valid DSA SSL certs in the entiere public Internet. > > > > 6.3.9. (Client Certificate) > > > > > Doesn't CertificateRequest override algorithms anyway (and CR isn't an > > extension)? > > Sorry, I'm not clear on what text you are sad about. " 6.3.9. Client Certificate This message conveys the client's certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing). The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm, and any negotiated extensions." I thought what algorithms are valid for client certificate is dictated by CertificateRequest, and the same for every ciphersuite that allows client certificates at all. And CertificateRequest is not an extension nor message negotiated by extension. > > > 6.3.10. (Client Certificate Verify) > > > > Similar problems as in DSA for server auth. And missing identifier > > for PRF too. > > Sorry, can you expand on this. The same as for server certificate verify: - DSA hash algorithms edge cases. - Signing hash without indicating what hash it is from. > > > 6.3.11. (New Session Ticket Message) > > > > Eh, if server starts transmitting immediately without waiting for > > client Finished (as is permitted for case where 1-RTT client auth > > is not performed), it can't resume the session? > > Good point. This seems like a silly restriction, so let's remove it. Note that server needs to wait for client Finished before issuing the ticket, or resumption can get screwy (even just with random network failures). > > Would be useful to list what can be used to authenticate peers, in > > practicular, are the following valid: > > > > - Signing TLS-Unique value? > > - Signing value from TLS-EXPORTER? > > I think we should generate an explicit TLS-channel-binding output > and recommend people use that. Due to backward compatiblity, I think that value should be given as TLS-Unique (i.e. change the definition for TLS 1.3). TLS spec can freely change how it is is defined provoded that: - Both sides agree about computation. - It is auth-critical, so one needs to be careful not to allow attacker to screw things by causing mismatched extensions or somesuch. -Ilari From nobody Thu Jul 16 12:47:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46131A1F04 for ; Thu, 16 Jul 2015 12:47:37 -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 PIglmEEh3OV7 for ; Thu, 16 Jul 2015 12:47:36 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A461A1EFE for ; Thu, 16 Jul 2015 12:47:36 -0700 (PDT) Received: by qged69 with SMTP id d69so8346959qge.0 for ; Thu, 16 Jul 2015 12:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=h7sisODQwrE81KFtRsUPGckEhwQ4+szeRAV/RzglmKQ=; b=IbafF/mq72i7kTMLmvMFApW4CJwaZsQz+cyZsn7yWUYCQGiZupEdfMzZulz5STnC6+ YUWisCIcWFf9TmLbdGTQ5MYKUdIvtHe5Hk/dImt5flbKwI5kVY4T0eRBiMXJMvx8M0Ph bAP7yI03ZQtop8V6ROkNHmKKHveR42mgDZpR6JUW/9dXsOfY31EbnQb4Kg2tuw3NQCOR vSM0hTqOOPHIVfq5QZKE9cDlzaKyLOAt1IC5nY/orAPRTEaottwGSo6cx+TXSukEaoBh S+hsqWGEHomdancEy8DeV4B+MfNppea6O3SqI8wsfokg9MhCJdPUu64SDo4Fq0DQ8oKi P60w== X-Received: by 10.140.95.204 with SMTP id i70mr19700060qge.51.1437076055407; Thu, 16 Jul 2015 12:47:35 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id m134sm4553927qhb.30.2015.07.16.12.47.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 Jul 2015 12:47:34 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 16 Jul 2015 15:47:32 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201507161547.33302.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Alerts & Certs - PR #201 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2015 19:47:37 -0000 https://github.com/tlswg/tls13-spec/pull/201 I've finished up the WIPs I had been working on for the various discussions we've been having on-list and submitted a PR. There's a lot in there, so review and comments are welcome. Almost all of this has been discussed here at some point to some degree, though across more than a few different threads, and not necessarily in the detail in the PR. Main points: * More explicit alert expectations * Deprecate SHA-1 and allow as fallback only * Make signature_algorithms & supported_groups extensions mandatory (for applicable cipher suites) * Shift final decision to abort due to unsupported certificate chain to the client * Require SNI for application protocols for which it is meaningful (this was discussed a while ago) Dave From nobody Fri Jul 17 01:38:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591B31B31A9 for ; Fri, 17 Jul 2015 01:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 4DVnvM2HOI4J for ; Fri, 17 Jul 2015 01:38:25 -0700 (PDT) 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 051541B319A for ; Fri, 17 Jul 2015 01:38:24 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CB1811A0095; Fri, 17 Jul 2015 10:38:05 +0200 (CEST) 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 NVCWLgtyxwXq; Fri, 17 Jul 2015 10:38:04 +0200 (CEST) Received: from mail-essen-02.secunet.de (unknown [10.53.40.205]) by a.mx.secunet.com (Postfix) with ESMTP id 1BCD71A0094; Fri, 17 Jul 2015 10:38:04 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0248.002; Fri, 17 Jul 2015 10:38:20 +0200 From: =?Windows-1252?Q?Schmidt=2C_J=F6rn-Marc?= To: Dan Harkins , Hubert Kario Thread-Topic: [TLS] New cipher suites for SRP Thread-Index: AQHQsGrBqtA/zH8K5UuILxApfv460p2/Z1wAgAAr/wCAA6iDAIAZrUyAgAKI1bA= Date: Fri, 17 Jul 2015 08:38:20 +0000 Message-ID: <38634A9C401D714A92BB13BBA9CCD34F1665ADA2@mail-essen-01.secunet.de> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> <6ce70b2d45a6aa67aae04ef7e6940ca7.squirrel@www.trepanning.net> In-Reply-To: <6ce70b2d45a6aa67aae04ef7e6940ca7.squirrel@www.trepanning.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.56.185] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006A_01D0C07C.B27F9DD0" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" , Geoffrey Keating Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2015 08:38:27 -0000 ------=_NextPart_000_006A_01D0C07C.B27F9DD0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >> - Change the negotiation so that user name is not exchanged in the = clear >> - Change key exchange to do PFS >TLS-pwd already supports both of these. It also supports ECC too, >which is problematic with the current SRP protocol. I agree: Instead of modifying SRP I would prefer introducing a new PAKE scheme.=20 On CFRG I recently submitted a draft on requirements for such schemes (https://www.ietf.org/mail-archive/web/cfrg/current/msg07005.html). Or to be even more flexible - how about defining a generic way to = include PAKE in TLS to prevent a whole bunch of ExtensionTypes and CipherSuites = by merging them into one "PAKE_Auth"? Best, J=F6rn ------=_NextPart_000_006A_01D0C07C.B27F9DD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILcDCCA4Aw ggJooAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAj BgNVBAoMHHNlY3VuZXQgU2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMB4XDTEzMDkx NDE4MDczN1oXDTE2MDkwMjE4MDczN1owUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0wNDEWMBQG A1UECwwNUHVibGljIFNlY3RvcjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCRqvsVVv5MbQS8cy8hB4K/W1zCJkQmiEzH+Dq6Jk+v J60qwXQW+rAkohGpglka0Cunv/nEWcTuOV2WZg+GtvQcriWs6Xgo22SCE41r5zXOtmgYrWlXOYbl clirYVzfvpeQBOklcBd2Pu7scdlN7lR6ZNkxxJjcMZh/jLkEbIWV7pew3DdafUvjH7P9ecLaB2HD 9JM7h0/uUiwWCtJ1u+1Mnqu4SVYuFTu1oUTkBjrWxO7e7F3MweO6VxjMn0vEppBDSPiK19X/hUd8 Snq2clBGy+njz+SjgIntsvTT+VAm7Ax4J+Y1dYujzA4NDFdkWvcp7+HoxmUpOKprR6WXEsKhAgMB AAGjZjBkMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBTbc5QVtU5hMX1CgwnNa7eRfeSseDAS BgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQNs9mwGqcOKL6k9pOo2AZkexvv6jANBgkqhkiG 9w0BAQUFAAOCAQEAq0bGL+Dq20x3nEqUpirjsl2CKhN999HnMaybNrRpS9u4NueLdnHpTEVh2L5h WqRWm9bNpcKN+c8bOB4rC9pcKIQBzam+sDAbfAApsdfovBnmHVyeAWYJj5p04gwBS1ie8+pPJnnb 0DCOhqTwn2wZxtql2P0yLaTuZAdO7t7zFiZbdOUlniRI2dOnF9ZrsC+FMD3WE6sLgktO0+1cST4F QSAtLAJ0NfSp0e9aKJhX+4dzt3zps+GA5bP4OM4iFO0E+xVwzdERZ48lGsRIFo3DhdLwJbgM3uvn 9A63hUU/ig0hTf5gGllVSrSAPFmhsTTJgkqGOnBa0RffRxqHm2gmJDCCA5EwggJ5oAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAjBgNVBAoMHHNlY3Vu ZXQgU2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMB4XDTExMDkwNDIyMDAwMFoXDTE2 MDkwMjIyMDAwMFowTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAjBgNVBAoMHHNlY3VuZXQg U2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEArKUOCQL/pHw+XdjEHgzp8TgwonnZnVmh/8f90GdWdGb9qr2Yb/yRiP4qxGRX9fbI gY/DYoR8995d5Er9cYWfDZZErNkSW0IJIQh0xxHCLxlJG1zfp3vyJgVfpCCPVHmfLa3mH66gpLue cO+rmQ2dcrKpAMf8v9C6YLYe5gP0ng9CoHvGKVmZ/McejJMzO+36luZbo8Ueqv9S31XTeHj2FiTu JK8Vg8k/xZMVPkj1L1ZNiQi/hC9nAb6+YWAL6RKjHGtHdP7AQcmSQbTKaDmZvU/vEtty9DlQgL9z m0Ao8aZM5dJUtzfiafC1dHOnWLTmVtXDYGIhl0e4xpP0NWxW7wIDAQABo3wwejAOBgNVHQ8BAf8E BAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBATBUBgNVHR8ETTBLMEmgR6BFhkNodHRwOi8veDUwOS5z ZWN1bmV0LmNvbS9DUkw/aWQ9YjNhMWE2MzItMzRkNy00NzljLThiMTktNTBjZDNlMWI2NmY0MA0G CSqGSIb3DQEBBQUAA4IBAQBa6Bmjnd8xkB0vtybolc0A5op6EhnXNcJJsgB7CAGQD0Qt8C6Jj/6c V7mtcUg5MY/EblmJyoZfVuOuPlCOfRD25LDwQ386Lh3XdiaNeWp7t8jABHnCkNq9jLjt5VS4ZitT VmLqn78dUbypFezZnehNaELVuDCrkvKkqp9r+hw32MOgCCm42uUauIUL6N1oM0kZo9tV3m7ddBiA JPPqRgt1BUcbvN4fbSOgzFedC5vM+jobHZ1Y+qHW7FRgMkxJcNq+Rc0LeOtbU9/b0oDeUv/p75j4 eW7FZyHoGr9iWD/kqbn9pzPhI+iHgTczOSxHvw1ieSDu2QEm7XqLw+fqpiU0MIIEUzCCAzugAwIB AgIBSTANBgkqhkiG9w0BAQUFADBSMRkwFwYDVQQDDBBQdWJsaWMtU2VjdG9yLTA0MRYwFAYDVQQL DA1QdWJsaWMgU2VjdG9yMRAwDgYDVQQKDAdzZWN1bmV0MQswCQYDVQQGEwJkZTAeFw0xNDEwMjEx MjA1MjNaFw0xNjA5MDExMjA1MjNaMIGlMRswGQYDVQQDDBJKw7Zybi1NYXJjIFNjaG1pZHQxEDAO BgNVBAQMB1NjaG1pZHQxEzARBgNVBCoMCkrDtnJuLU1hcmMxEzARBgNVBAsMCkdvdmVybm1lbnQx FjAUBgNVBAsMDVB1YmxpYyBTZWN0b3IxJTAjBgNVBAoMHHNlY3VuZXQgU2VjdXJpdHkgTmV0d29y a3MgQUcxCzAJBgNVBAYTAmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn3zvWShw r9UJ9cOR9EnSf6TAFItMTptXsXT+oiQmmtOYJHaQUeJ4imehiVABAGL5azr8b4b6EFG1bo0jA1lO +hmb6WD6JEIiq0T1ppL7tZle2xVvM/xEsljMoSKroTrE6rx7AUwAhi54pqabF1HlmWsP87cXwEZZ bnR4sQuF/MfmN7mSe7SY5VG/5El+Dw4YOkjVBmSojiHEO2EBH63YCboPpMJ/hLMZ1rcBaIh9eRl2 uULeNAnGR4+R9IQGQjtJNPvw3n9ca20f8+irCqMpcv5e+VhlTTFHB0K2d/Nzh4BAVluH3u14nrCA IjHhplaOyuoPlw3Q+oPVf+C3ADg00QIDAQABo4HfMIHcMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6 Ly94NTA5LnNlY3VuZXQuY29tL0NSTD9pZD03OTZkNzQyNS0xNjU1LTRmMjctYTBmOC0wMTc1YjM1 MDk4YjYwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwHwYDVR0jBBgwFoAUDbPZsBqnDii+pPaT qNgGZHsb7+owHQYDVR0OBBYEFGOaRJ/ILBu0+4ik5ZQv6NKv0pzLMCkGA1UdEQQiMCCBHmpvZXJu LW1hcmMuc2NobWlkdEBzZWN1bmV0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAB1eAd0+CCJibZxRQ VpgQMp07AUXWyIDno76zBDUwbPioewEzJgerzOnvtGLqMeXaSfgde7nh88itchqYIPhre2pRPPI6 Jpdoqc3HkmtJYPy7cVGThsnr2f7Cn72Tv024/9ZWgN5Muzk8/PisuJa9Vd0nqzDrfcDwbRtfQq8Y kmVs3sNZsknljMfKqRyl6frO3RGGJukReVh+Puksv1Mn6Tn9Bb9w5nNropX6hmHJsyiofLs5IC03 faTKeQIufgven777EpRZePzqfdibhNOL4jvsm45dOXuzlwFDrAoBByiuWmUN3d6zPe8Z7UdUlzuv 8Q21RgJ8bMKpLyLKaa6nQjGCA18wggNbAgEBMFcwUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0w NDEWMBQGA1UECwwNUHVibGljIFNlY3RvcjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUC AUkwCQYFKw4DAhoFAKCCAd0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTUwNzE3MDgzODE5WjAjBgkqhkiG9w0BCQQxFgQU+VCA+WYHVOUGgm5peo+E/swWLXYwZgYJ KwYBBAGCNxAEMVkwVzBSMRkwFwYDVQQDDBBQdWJsaWMtU2VjdG9yLTA0MRYwFAYDVQQLDA1QdWJs aWMgU2VjdG9yMRAwDgYDVQQKDAdzZWN1bmV0MQswCQYDVQQGEwJkZQIBSTBoBgsqhkiG9w0BCRAC CzFZoFcwUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0wNDEWMBQGA1UECwwNUHVibGljIFNlY3Rv cjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUCAUkwgasGCSqGSIb3DQEJDzGBnTCBmjAL BglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG 9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhow CwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA jVbckmEx6D6XlOw6w2uUjwmpuYycnHQ7J5TVbSpVYX9LKN6CeLYwTmRW5yvdgN9odLPWdeIvg7vA SjVWj7uYXIl9tX2slsjynhWueCKMTEIdtCczmx3keVl3ffxvcgiV4aKpesvPbcXV0V1j0IelWu/m OTarBN29pTvEnBC7mOmwbbALetDfNAidsqA2lT7+pd8/QAXY0F+odIH/5ANHPCVt6G6Z3ScdgfKz kTevGfJqXiN+x2QqTakLUj1x1XAtw7UUuUtK6VO3tbf8Zh0Zd5izftHxZzYNp2buUN5EdWIh7ud1 iKpLlJvYjqMpsztbQ+sQPZRW2brSQpngwz7+CgAAAAAAAA== ------=_NextPart_000_006A_01D0C07C.B27F9DD0-- From nobody Fri Jul 17 08:01:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344161A6FF2 for ; Fri, 17 Jul 2015 08:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h-zIgy3KABBh for ; Fri, 17 Jul 2015 08:01:24 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A9E1A6FBB for ; Fri, 17 Jul 2015 08:01:24 -0700 (PDT) Received: from [10.0.69.133] (athyra.geoffk.org [198.0.208.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dragaera.releasedominatrix.com (Postfix) with ESMTP id 92A9E33D02E; Fri, 17 Jul 2015 15:01:23 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Geoff Keating In-Reply-To: <38634A9C401D714A92BB13BBA9CCD34F1665ADA2@mail-essen-01.secunet.de> Date: Fri, 17 Jul 2015 08:01:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7532E1F9-23E6-4B7D-AC1A-ABBEE5BD5D7A@geoffk.org> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> <6ce70b2d45a6aa67aae04ef7e6940ca7.squirrel@www.trepanning.net> <38634A9C401D714A92BB13BBA9CCD34F1665ADA2@mail-essen-01.secunet.de> To: =?windows-1252?Q?=22Schmidt=2C_J=F6rn-Marc=22?= X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2015 15:01:26 -0000 > On 17 Jul 2015, at 1:38 am, Schmidt, J=F6rn-Marc = wrote: >=20 >>> - Change the negotiation so that user name is not exchanged in the = clear >>> - Change key exchange to do PFS >=20 >> TLS-pwd already supports both of these. It also supports ECC too, >> which is problematic with the current SRP protocol. In the language of the CFRG draft, TLS-pwd is =93balanced=94 where SRP = is =93augmented=94, so they=92re not really equivalent, correct? > I agree: Instead of modifying SRP I would prefer introducing a new = PAKE > scheme.=20 > On CFRG I recently submitted a draft on requirements for such schemes > (https://www.ietf.org/mail-archive/web/cfrg/current/msg07005.html). >=20 > Or to be even more flexible - how about defining a generic way to = include > PAKE in TLS to prevent a whole bunch of ExtensionTypes and = CipherSuites by > merging them into one "PAKE_Auth=94? This is possible, but you=92d need to have the client and server = negotiate based on what they have. For example, if the server has a SRP verifier from the = current protocol, but the client has a stored PBKDF2 hash of the password for = that server, they cannot communicate and would need to pick a different cipher suite. = I am not sure how you can do this without revealing the existence of an account = under some circumstances. So this might be a situation where fewer protocol = options is better.= From nobody Fri Jul 17 21:38:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D361A9233 for ; Fri, 17 Jul 2015 21:38: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 xdlhAOq20aBr for ; Fri, 17 Jul 2015 21:37:59 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE901A9174 for ; Fri, 17 Jul 2015 21:37:59 -0700 (PDT) Received: by qkdv3 with SMTP id v3so81548058qkd.3 for ; Fri, 17 Jul 2015 21:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=wRvpaHJK4Xyomrqnw4qWXkKOv2ribVSis5/MzDR8xNY=; b=tfFm1k2NonJrdYLd4LzJcSUPjOj6/XzadyYJL7FDp+lOdudRq5zqi4MChes88Hx4Kk mS1n+vO4r8Z19RYcB73SqSqPER0cnkbdntBQiBswG/IDy2MuNy4YAd25OvmuvYpMv4F5 FkL9Dk7oyewvNBwgNF1D0GJSDfzSm8Rd3L6DPUcVSnlLzTYnU+2xVEFkhk+Hg+DfPSfZ yhOI6EFsGA+Vc8Hr3OxRNhBsH1dgLrgSoC2AonIM3YDigvwsEiPemKdRPpfp14Go1bLS 8+mGKcfDuH2JhKa26zh4uv1CjW71SpqTrPj9iueRvHVDFb73YLuEP8TDm/deSD8sZi44 rdbA== X-Received: by 10.55.15.103 with SMTP id z100mr31460271qkg.7.1437194278347; Fri, 17 Jul 2015 21:37:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id s5sm6995808qgs.1.2015.07.17.21.37.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 Jul 2015 21:37:57 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Brian Smith , Eric Rescorla Date: Sat, 18 Jul 2015 00:37:55 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201507180037.56413.davemgarrett@gmail.com> Archived-At: Subject: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2015 04:38:00 -0000 Brian Smith posted an RFE to GitHub a few months ago requesting "A mechanism is needed to indicate that a session will not be resumed": https://github.com/tlswg/tls13-spec/issues/137 The goal is to provide a simple way for either endpoint to request that the master secret be forgotten ASAP to provide a greater assurance of confidentiality. I've written up a short proposal with idea about how I'd suggest going about this: https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify The idea is to simply add a new "reset_notify" alert (generally a warning) which may be sent by either endpoint as soon as record protection is available, after which both endpoints would stop caching shared secrets after completion of traffic key completion. This could be sent right from the start, at the end of a connection just prior to a standard "close_notify", or at any point in between. This seems like a simple route that does what is specified in issue #137 without the creation of any new extensions or messages; just one new alert value. Comments? Suggestions? Any reason this would break everything? No PR yet. Just a WIP branch to spec out the idea, so far. Dave From nobody Fri Jul 17 21:51:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F941AC3FC for ; Fri, 17 Jul 2015 21:51:25 -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 htAqb0-x3pYs for ; Fri, 17 Jul 2015 21:51:24 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043301AC3E5 for ; Fri, 17 Jul 2015 21:51:21 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so1767265wgb.3 for ; Fri, 17 Jul 2015 21:51:19 -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=ywhVbPjs7Ji6zvUteDJg3Mw+aRo1u3rzgnnsLDwuXNo=; b=UdUPDkjgUrtmTxpxPGKwfsrypeTr2JoHcOKZXV76zUjOepUOtyp8viYwPA/BwDZMPv kAXO6yvTGW4JTjlsiin7EzZRdNBgEBZkX/ccQWjY7I4Fm9aKl+LN+hN6JSZ+LN9dsUXt 53+VB8yKKsgh+Scx0nm5+8DQvrKlq6T3GeXRdp1L680hsrri7umAeu+IqR4mUGmMJBtv zOVOBoKZKFedMu9C8PFgOXWa0LwiFZR1mJlLks+xEZQMzeCEqqYfWoedJV3ZLv1POdN4 RGHhZLYXwibDZBEZ/ElXgGzSx1YpiZOrBmW3kwZ6e4T+FPtOE+Enrslk7N/u+8ICRocW Re2g== X-Gm-Message-State: ALoCoQnLumEVeUJppHgeCEUDM7dYsFpsDA+3BGf9R/pypmgbOfu8ih1w8dO7Iq2bDzPFOfGET3af X-Received: by 10.180.87.168 with SMTP id az8mr1696282wib.53.1437195079795; Fri, 17 Jul 2015 21:51:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 17 Jul 2015 21:50:40 -0700 (PDT) In-Reply-To: <201507180037.56413.davemgarrett@gmail.com> References: <201507180037.56413.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 17 Jul 2015 21:50:40 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=90e6ba181b823457ce051b1f0e30 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2015 04:51:26 -0000 --90e6ba181b823457ce051b1f0e30 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett wrote: > Brian Smith posted an RFE to GitHub a few months ago requesting "A > mechanism is needed to indicate that a session will not be resumed": > https://github.com/tlswg/tls13-spec/issues/137 > > The goal is to provide a simple way for either endpoint to request that > the master secret be forgotten ASAP to provide a greater assurance of > confidentiality. > > I've written up a short proposal with idea about how I'd suggest going > about this: > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify > > The idea is to simply add a new "reset_notify" alert (generally a warning) > which may be sent by either endpoint as soon as record protection is > available, after which both endpoints would stop caching shared secrets > after completion of traffic key completion. This could be sent right from > the start, at the end of a connection just prior to a standard > "close_notify", or at any point in between. > > This seems like a simple route that does what is specified in issue #137 > without the creation of any new extensions or messages; just one new alert > value. > > Comments? Suggestions? Any reason this would break everything? > I don't think this is that useful or practical with the current structure of TLS 1.3. - Unless I've missed something, this is primarily an issue of PFS for the original connection, since compromise of either endpoint probably allows impersonation attacks going forward. - Because the resumption master secret is cryptographically independent of the master secret that initiated the connection, its existence in the server's database or in a ticket isn't a threat to the originating connection. - The server can opt not to allow resumption by declining to provide a NewSessionTicket message. - The client has the option of never initiating a new connection with the provided ticket (assuming that the server opts to supply one). Note also that because the ticket is encrypted with the original traffic keys, if the client never tries to resume the connection, the ticket never appears on the wire (which is relevant for self-encrypted tickets, but not so much for tickets which are database lookup keys). - Because many implementations use self-encrypted tickets, it's not practical to require them to delete keying material once it's been established. Once such a ticket has been transmitted on the wire, the server can't really forget it without deleting the ticket encryption key (it can of course mark the ticket invalid in some local database, but that doesn't reduce the risk from compromise of the ticket encryption key.) -Ekr --90e6ba181b823457ce051b1f0e30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
Brian Smith posted an RFE to= GitHub a few months ago requesting "A mechanism is needed to indicate= that a session will not be resumed":
https://github.com/tlswg/tls13-spec/issues/137

The goal is to provide a simple way for either endpoint to request that the= master secret be forgotten ASAP to provide a greater assurance of confiden= tiality.

I've written up a short proposal with idea about how I'd suggest go= ing about this:
https://github.com/tlswg= /tls13-spec/compare/master...davegarrett:resetnotify

The idea is to simply add a new "reset_notify" alert (generally a= warning) which may be sent by either endpoint as soon as record protection= is available, after which both endpoints would stop caching shared secrets= after completion of traffic key completion. This could be sent right from = the start, at the end of a connection just prior to a standard "close_= notify", or at any point in between.

This seems like a simple route that does what is specified in issue #137 wi= thout the creation of any new extensions or messages; just one new alert va= lue.

Comments? Suggestions? Any reason this would break everything?

I don't think this is that useful or practical = with the current structure of TLS 1.3.

- Unless I&= #39;ve missed something, this is primarily an issue of PFS for the original=
=C2=A0 connection, since compromise of either endpoint probably = allows impersonation
=C2=A0 attacks going forward.

=
- Because the resumption master secret is cryptographically inde= pendent
=C2=A0 of the master secret that initiated the connection= , its existence in the server's
=C2=A0 database or in a ticke= t isn't a threat to the originating connection.

- The server can opt not to allow resumption by declining to provide
=C2=A0 a NewSessionTicket message.=C2=A0

- = =C2=A0The client has the option of never initiating a new connection with t= he
=C2=A0 =C2=A0provided ticket (assuming that the server opts to= supply one). Note
=C2=A0 =C2=A0also that because the ticket is e= ncrypted with the original traffic keys,
=C2=A0 =C2=A0if the clie= nt never tries to resume the connection, the ticket never
=C2=A0 = =C2=A0appears on the wire (which is relevant for self-encrypted tickets, bu= t
=C2=A0 =C2=A0not so much for tickets which are database lookup = keys).

- Because many implementations use self-enc= rypted =C2=A0tickets, it's not practical
=C2=A0 to require = =C2=A0 them to delete keying material once it's been established. Once = such
=C2=A0 =C2=A0a ticket has been transmitted on the wire, the = server can't really forget it
=C2=A0 without deleting the tic= ket encryption key (it can of course mark the
=C2=A0 ticket inval= id in some local database, but that doesn't reduce the risk
= =C2=A0 from compromise of the ticket encryption key.)

<= div>-Ekr

--90e6ba181b823457ce051b1f0e30-- From nobody Fri Jul 17 22:06:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE931AC405 for ; Fri, 17 Jul 2015 22:06:36 -0700 (PDT) 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 5cVn9LqE9M8w for ; Fri, 17 Jul 2015 22:06:34 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556011AC402 for ; Fri, 17 Jul 2015 22:06:34 -0700 (PDT) Received: by oigd21 with SMTP id d21so39756800oig.1 for ; Fri, 17 Jul 2015 22:06:33 -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:date :message-id:subject:from:to:cc:content-type; bh=bpC6jvzKh+OQLKiyoPfo9o/b+fhOCMKWc+gWEBY1wz4=; b=NisoWN9ohU5YQHHbNcY7LZnCk2oKbk8GfE8c+t7yUSCzgpsIuLn3QTuif6SaI1dmzo L8UzB82VQb9i5uDk1H1BS80XMj6BiRcSThqi7Fpb1acEYTvGgqjFJwcsBdakoapdSkS0 QeZppTHsYlvNeUoSRNpQO/bwU4LZB2G/srf+ZXO7eztbl1gGuRvZ0rqDpb6UHgFw3LDp w0JpPKato0ZfWJko1g24H7ZC3VWqaQ1CWoSksXxLWz7Gfl1nDRv/aj3I83A7qz9eChFT 1ExfCFJuI+nXqrOEsIP00iShH3HOf337B/hwPdYdtruKKX4/ajMe7IhlWu0K5iq9AW0p 66QQ== X-Gm-Message-State: ALoCoQlQBUsKzMoeKgvWbi3kjvyU0bR75g2SFos11udGjSg3iI3ecf3Y4wtAXuhMwqALYoJhcIU6 MIME-Version: 1.0 X-Received: by 10.202.210.68 with SMTP id j65mr15783944oig.68.1437195993760; Fri, 17 Jul 2015 22:06:33 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Fri, 17 Jul 2015 22:06:33 -0700 (PDT) In-Reply-To: <201507180037.56413.davemgarrett@gmail.com> References: <201507180037.56413.davemgarrett@gmail.com> Date: Sat, 18 Jul 2015 01:06:33 -0400 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113d2b38ae5f69051b1f44e9 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2015 05:06:36 -0000 --001a113d2b38ae5f69051b1f44e9 Content-Type: text/plain; charset=UTF-8 Dave Garrett wrote: > Brian Smith posted an RFE to GitHub a few months ago requesting "A > mechanism is needed to indicate that a session will not be resumed": > https://github.com/tlswg/tls13-spec/issues/137 > > The goal is to provide a simple way for either endpoint to request that > the master secret be forgotten ASAP to provide a greater assurance of > confidentiality. > > I've written up a short proposal with idea about how I'd suggest going > about this: > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify > > The idea is to simply add a new "reset_notify" alert (generally a warning) > which may be sent by either endpoint as soon as record protection is > available, after which both endpoints would stop caching shared secrets > after completion of traffic key completion. This could be sent right from > the start, at the end of a connection just prior to a standard > "close_notify", or at any point in between. > This is not really what I was intending when I suggested the feature. I was intending for their to be an indication, in the ClientHello, that the server should not do any of the work that it would normally do to make the session resumable. That is, the server MUST NOT create a session ticket, and the server MUST NOT add the connection to any session cache, the server SHOULD forget the epheneral (EC)DHE key and master secret ASAP during handshaking. (And, so should the client.) An alert like you suggest may be useful for some cases, but it wouldn't be useful for what I was suggesting because it would occur after the server has already done all the things to cache a session that add needless risk and waste resources when the client has no intention of resuming the connection. In the context of web browsers, I believe that the Tor Browser would prefer to have this, since it disables session resumption to prevent the leaking of the tracking identifier inherent in it. It would also be useful for any (non-browser) application for which a 1-RTT handshake per connection is good enough, which is probably most applications, especially many server-to-server applications. Cheers, Brian -- https://briansmith.org/ --001a113d2b38ae5f69051b1f44e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dave= Garrett <davemgarrett@gmail.com> wrote:
Brian Smith posted an RFE to GitHub a few months ago requesting "= ;A mechanism is needed to indicate that a session will not be resumed"= :=C2=A0https://github.com/tlswg/tls13-spec/issues/137<= /a>

The goal is to provide a simple way for either endpoint to request that the= master secret be forgotten ASAP to provide a greater assurance of confiden= tiality.

I've written up a short proposal with idea about how I'd suggest go= ing about this:
https://github.com/tlswg= /tls13-spec/compare/master...davegarrett:resetnotify

The idea is to simply add a new "reset_notify" alert (generally a= warning) which may be sent by either endpoint as soon as record protection= is available, after which both endpoints would stop caching shared secrets= after completion of traffic key completion. This could be sent right from = the start, at the end of a connection just prior to a standard "close_= notify", or at any point in between.

This is not really what I was intending when I suggested the feature. I = was intending for their to be an indication, in the ClientHello, that the s= erver should not do any of the work that it would normally do to make the s= ession resumable. That is, the server MUST NOT create a session ticket, and= the server MUST NOT add the connection to any session cache, the server SH= OULD forget the epheneral (EC)DHE key and master secret ASAP during handsha= king. (And, so should the client.)

An alert like y= ou suggest may be useful for some cases, but it wouldn't be useful for = what I was suggesting because it would occur after the server has already d= one all the things to cache a session that add needless risk and waste reso= urces when the client has no intention of resuming the connection.

In the context of web browsers, I believe that the Tor= Browser would prefer to have this, since it disables session resumption to= prevent the leaking of the tracking identifier inherent in it. It would al= so be useful for any (non-browser) application for which a 1-RTT handshake = per connection is good enough, which is probably most applications, especia= lly many server-to-server applications.

Cheers,
Brian
--=C2=A0
--001a113d2b38ae5f69051b1f44e9-- From nobody Fri Jul 17 22:36:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3A81A8A47 for ; Fri, 17 Jul 2015 22:36:27 -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 VGsLx1PFp2La for ; Fri, 17 Jul 2015 22:36:25 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8197C1A036B for ; Fri, 17 Jul 2015 22:36:25 -0700 (PDT) Received: by qgy5 with SMTP id 5so55868105qgy.3 for ; Fri, 17 Jul 2015 22:36:24 -0700 (PDT) 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=IH7Tj1eQTRa4wFuifbyY/Ocy3AZQAl1aX07RNXUKN+w=; b=m197gerMbd4zsg+PdNhOZbswG1lRYjX5S6F5T1bM3h6t36Dl6HXFQs6gA9bf3YIAYV jSdWU986LUs7Xtz9m3i2Ljw6REx2RmLKAuBazIdxVthrIjoLJ1A5VahYdG20W0IehNfg rsJTw/MwhPnIjpaKpXt7QMMmY+szrO0taZczmJyLYWGql/MrxRuvR8oSEyn9moCkud0D qcQ43T+Y8Jt5+LtxeK/DeBaNmcabXz9A+d1bYLbbqLgR+2drbEy0/R6Y8mdqFcf6ruhG M31bDnd1fo7MQriFJfcjEaFnRFS8rIxcTvRUWD+T57cAsrdJZFXslILHRZtWMZXiJJOJ 30dQ== X-Received: by 10.140.83.178 with SMTP id j47mr30726332qgd.18.1437197784823; Fri, 17 Jul 2015 22:36:24 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id w67sm7037648qgw.41.2015.07.17.22.36.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 Jul 2015 22:36:24 -0700 (PDT) From: Dave Garrett To: Eric Rescorla , Brian Smith Date: Sat, 18 Jul 2015 01:36:22 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507180037.56413.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507180136.23158.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2015 05:36:27 -0000 On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett wrote: > Brian Smith posted an RFE to GitHub a few months ago requesting "A > mechanism is needed to indicate that a session will not be resumed": > https://github.com/tlswg/tls13-spec/issues/137 [...] > I've written up a short proposal with idea about how I'd suggest going > about this On Saturday, July 18, 2015 12:50:40 am Eric Rescorla wrote: > I don't think this is that useful or practical with the current structure > of TLS 1.3. [...] > - Because the resumption master secret is cryptographically independent > of the master secret that initiated the connection, its existence in the > server's database or in a ticket isn't a threat to the originating connection. > > - The server can opt not to allow resumption by declining to provide > a NewSessionTicket message. > > - The client has the option of never initiating a new connection with the > provided ticket (assuming that the server opts to supply one). Note > also that because the ticket is encrypted with the original traffic keys, > if the client never tries to resume the connection, the ticket never > appears on the wire (which is relevant for self-encrypted tickets, but > not so much for tickets which are database lookup keys). Ok, it looks like this late night idea isn't really needed anymore for at least this set of use-cases. On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > This is not really what I was intending when I suggested the feature. I was > intending for their to be an indication, in the ClientHello, that the > server should not do any of the work that it would normally do to make the > session resumable. That is, the server MUST NOT create a session ticket, > and the server MUST NOT add the connection to any session cache, the server > SHOULD forget the epheneral (EC)DHE key and master secret ASAP during > handshaking. (And, so should the client.) Ah, so just a simple empty extension would suffice for your main concern. I went with a simple alert to satisfy your 3rd point in the RFE along with 1 and 2. > In the context of web browsers, I believe that the Tor Browser would prefer > to have this, since it disables session resumption to prevent the leaking > of the tracking identifier inherent in it. It would also be useful for any > (non-browser) application for which a 1-RTT handshake per connection is > good enough, which is probably most applications, especially many > server-to-server applications. Ok, then I'll move the other little wording fixes/simplifications in there into my main WIP branch and set this idea aside for the time being. If the ability to easily request an ephemeral TLS session at-will sounds particularly useful to anyone, then we can discuss it further and I could submit a PR. Thanks, Dave From nobody Sat Jul 18 11:21:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DF01A1A70 for ; Sat, 18 Jul 2015 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 LHeTTTBIrNzl for ; Sat, 18 Jul 2015 11:21:53 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 51DBC1A065C for ; Sat, 18 Jul 2015 11:21:53 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DFE184C5D7; Sat, 18 Jul 2015 18:22:24 +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 C976F4C5D6; Sat, 18 Jul 2015 18:22:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437243744; bh=jLuv+XNTPxPhwq65eUPCTzYmRpXP4r5wqoEjk6Q0qck=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=XLnrL4pqIs3S3wisxq/m/LwkH51W9A5pTqVli+Lv7LFUqTHC/4aysvYHz0wLUi8MC AYyNk/8/bQXSmQcCIA5ahXRhPmvoxIEecKqG7eUvaDVxXav82qKs067DfUBYOdcxr1 gAOlxfjuH993vHGxirqbrm3IQcfHHRv9Let4WQE0= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 5615A205F; Sat, 18 Jul 2015 18:21:51 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 18 Jul 2015 13:21:50 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Sat, 18 Jul 2015 13:21:50 -0500 From: "Salz, Rich" To: Brian Smith , Dave Garrett Thread-Topic: [TLS] TLS 1.3 - method to request uncached shared secrets Thread-Index: AQHQwReJ7GOXOEU4BEqb1+g/MGuaCZ3hiuxQ Date: Sat, 18 Jul 2015 18:21:49 +0000 Message-ID: References: <201507180037.56413.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.167] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2015 18:21:55 -0000 QnJpYW4ncyBkZXNjcmlwdGlvbiBtYWtlcyBtdWNoIG1vcmUgc2Vuc2UgdG8gbWUgdGhhbiBEYXZl J3Mgc3VnZ2VzdGlvbi4gIEknZCArMSB0aGUgZm9ybWVyIGFuZCAtMSB0aGUgbGF0dGVyLg0K From nobody Sat Jul 18 11:28:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5CF1A1BDD for ; Sat, 18 Jul 2015 11:28:44 -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 ACVZmgMG7XR3 for ; Sat, 18 Jul 2015 11:28:43 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABD31A1BD4 for ; Sat, 18 Jul 2015 11:28:42 -0700 (PDT) Received: by qkdv3 with SMTP id v3so88857561qkd.3 for ; Sat, 18 Jul 2015 11:28:42 -0700 (PDT) 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=SYBk0howVDKvBF6DaxHSPSxmYiRWR8etUKNrXEY759U=; b=B5QwLi4Bi8G2476VUdTfpljjva4IlIp3Rt9OcnDGMJdY9B11BRulA0NfhqLnIKe0QJ FwjQHfNQY3VF6dGtelx/GEi+BWSdDhHIuXZWiwgk+qaCjz6DU5AYYpnFhB5xoowXyGRp cZNRqiKQ6plQxsPRhJaQG7UP5eExHDRO2ydD2pBGg6+ZRplWaIxnWQa7WHoaCaY12GOt hKTHWvCMxOrGxWvXr+PHWp0QRoYTGXLXc1feERzN1c8hWx2dGqeYzrqfx0OzgmwKAKid nMKgU1rCCnQi0wPy4rjGv0rgbwK2+dWG4CQh0XsqEaYMSVHSXB0xr426Chb5MDopcZsr D4iQ== X-Received: by 10.55.22.169 with SMTP id 41mr3700979qkw.13.1437244122258; Sat, 18 Jul 2015 11:28:42 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id g92sm7885894qgf.20.2015.07.18.11.28.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 18 Jul 2015 11:28:41 -0700 (PDT) From: Dave Garrett To: Brian Smith Date: Sat, 18 Jul 2015 14:28:40 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507180037.56413.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507181428.40766.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2015 18:28:44 -0000 On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > This is not really what I was intending when I suggested the feature. I was > intending for their to be an indication, in the ClientHello, that the > server should not do any of the work that it would normally do to make the > session resumable. Ok, I might as well write up the generic solution then: https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest This is an extension to allow a client to optionally request a specific session ticket lifetime. It can request a zero lifetime to disable session resumption and have the server not cache anything, request a max uint32 lifetime to request the maximum lifetime the server is willing to offer (up to the server if it wants to allow a longer lifetime than default), or request any specific lifetime (again, honoring is optional). The extension is just a single uint32 value; including overhead, this is a total of 8 bytes. Dave From nobody Sat Jul 18 18:22:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8B41A1BC0 for ; Sat, 18 Jul 2015 18:22:17 -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 HskhN5Is5vBA for ; Sat, 18 Jul 2015 18:22:16 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B4A1A1BBC for ; Sat, 18 Jul 2015 18:22:15 -0700 (PDT) Received: by qgeu79 with SMTP id u79so5605634qge.1 for ; Sat, 18 Jul 2015 18:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=WShOgCQ40rqtojgPNmLkLBUiH+OrT+ynrJ2fmPIFTZQ=; b=TWQrubY51aTDwp8QLArFQiUX92LWjjj+YFUEiSU6y6zzK2RPEkozjJ4pOzDvJN0PIQ VOvFOUBkm2H4x4uGsAREZW1RdsS2Ijn1vRpEC2XChppcc7xzdK8bGDQ66GbR/z5eFayp Jy4giKkb/D3CskwlHq7YsrmzkdyIWyL/93wVNzA6Qk2iPLmrFeROEPKHGXSgZfzPmzlL 0/S8OlkIp9Tt+whATTSjX405zy/yHQzuTBz4zjLpCoMkPMxZ2sdNr7Twxqy3Cg2L3SOQ lwWMJrUGI7W2JmZJtMsh6YO6X+XPFyzhpGlxcEEuTi2tmFUHRGKtWaIrk4NY57CvjocF s6ZA== X-Received: by 10.140.151.146 with SMTP id 140mr31260272qhx.57.1437268935242; Sat, 18 Jul 2015 18:22:15 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id t77sm2508797qge.42.2015.07.18.18.22.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 18 Jul 2015 18:22:14 -0700 (PDT) From: Dave Garrett To: "" , Eric Rescorla Date: Sat, 18 Jul 2015 21:22:12 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201507182122.12566.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Does the ServerHello really need unencrypted extensions at all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 01:22:18 -0000 There's two issues (basically duplicates) for this topic, as well as an inline TODO. https://github.com/tlswg/tls13-spec/issues/66 https://github.com/tlswg/tls13-spec/issues/72 https://tlswg.github.io/tls13-spec/#server-hello The current expectation is to separate extensions into unencrypted and encrypted, with: "The ServerHello MUST only include extensions which are required to establish the cryptographic context." The rest then go into the new EncryptedExtensions message. Are there really any extensions that this applies to? What extension couldn't we get away with encrypting? As soon as ServerKeyShare is sent, the client should have enough information to decrypt the encrypted extensions message. Site note: ServerKeyShare could probably just be merged into ServerHello at this point: struct { ProtocolVersion server_version; Random random; CipherSuite cipher_suite; select (DH) { case true: NamedGroup group; opaque key_exchange<1..2^16-1>; case false: struct {}; }; } ServerHello; Even if an extension is desired to set up a cryptographic context, then ideally you'd want to set up a basic extension-less one _first_, send an encrypted extensions message containing that needed extension, then send a second encrypted extensions message using the new context using the extension. The goal is to encrypt all the things, per TLS WG charter, so I don't see a point in allowing unencrypted extensions in ServerHellos at all anymore. Is there some reason why such a plan wouldn't be able to work? Having two places to put server extensions is bound to cause mistakes. Dave From nobody Sun Jul 19 01:02:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D83C1A1B95 for ; Sun, 19 Jul 2015 01:02:35 -0700 (PDT) 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 NR3Rw9bS5Rzs for ; Sun, 19 Jul 2015 01:02:33 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329431A21AD for ; Sun, 19 Jul 2015 01:02:24 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 8F95F1A25EC; Sun, 19 Jul 2015 11:02:21 +0300 (EEST) Date: Sun, 19 Jul 2015 11:02:21 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150719080221.GA15730@LK-Perkele-VII> References: <201507182122.12566.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201507182122.12566.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] Does the ServerHello really need unencrypted extensions at all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 08:02:35 -0000 On Sat, Jul 18, 2015 at 09:22:12PM -0400, Dave Garrett wrote: > There's two issues (basically duplicates) for this topic, as well as an inline TODO. > https://github.com/tlswg/tls13-spec/issues/66 > https://github.com/tlswg/tls13-spec/issues/72 > https://tlswg.github.io/tls13-spec/#server-hello > > The current expectation is to separate extensions into unencrypted and encrypted, with: > "The ServerHello MUST only include extensions which are required to establish the cryptographic context." > > The rest then go into the new EncryptedExtensions message. > > Are there really any extensions that this applies to? What extension > couldn't we get away with encrypting? As soon as ServerKeyShare is sent, > the client should have enough information to decrypt the encrypted > extensions message. Going through extension list, I think the following need to go to ServerHello (and aren't considered deprecated): max_fragment_length (existing, IIRC, a single enumeration) known_configuration (new in TLS 1.3, just an ACK flag) pre_shared_key (new in TLS 1.3, PSK only, 1 octet string) early_data(?) (new in TLS 1.3, just an ACK flag) (Technically known_configuration and early_data could be pushed further, but that would create annoying special cases). Additionally, if the handshake shape is to be fixed by CH/SH, the following need to go to SH, because these introduce or change messages (post EE, so with variable shape, EE is possible): client_certificate_url status_request user_mapping client_authz server_authz status_request_v2 signed_certificate_timestamp > Site note: ServerKeyShare could probably just be merged into > ServerHello at this point: > > struct { > ProtocolVersion server_version; > Random random; > CipherSuite cipher_suite; > select (DH) { > case true: > NamedGroup group; > opaque key_exchange<1..2^16-1>; > case false: > struct {}; > }; > } ServerHello; > > Even if an extension is desired to set up a cryptographic context, > then ideally you'd want to set up a basic extension-less one _first_, > send an encrypted extensions message containing that needed extension, > then send a second encrypted extensions message using the new context > using the extension. The goal is to encrypt all the things, per TLS WG > charter, so I don't see a point in allowing unencrypted extensions in > ServerHellos at all anymore. Changing ServerHello has the problem of then having incompatible message with the same message type (the only offender for this currently is IIRC ServerConfig, which collides with TLS 1.2 ServerHelloDone). Additionally, if you ever need a security fix extension (:vomit:), those likely would have to go to ServerHello. -Ilari From nobody Sun Jul 19 03:21:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2049D1A8AC0 for ; Sun, 19 Jul 2015 03:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_48=0.6, 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 Q4qVTyecazEn for ; Sun, 19 Jul 2015 03:21:18 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236361A8ABD for ; Sun, 19 Jul 2015 03:21:18 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 48577160B4; Sun, 19 Jul 2015 12:21:16 +0200 (CEST) Received: from [31.133.176.74] (dhcp-b04a.meeting.ietf.org [31.133.176.74]) by thue.elzevir.fr (Postfix) with ESMTPSA id 653491FA1E; Sun, 19 Jul 2015 12:21:15 +0200 (CEST) Message-ID: <55AB7A19.5030502@elzevir.fr> Date: Sun, 19 Jul 2015 12:21:13 +0200 From: Manuel Pegourie-Gonnard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bingzheng Wu , tls References: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com>, 011401d0aa68$af6818e0$0e384aa0$@alibaba-inc.com <----3-------MPf3-$9050573e-2304-452c-9b77-668deaf79dd6@alibaba-inc.com> In-Reply-To: <----3-------MPf3-$9050573e-2304-452c-9b77-668deaf79dd6@alibaba-inc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] is it good using password for authentication only? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 10:21:20 -0000 Hi, On 6/19/15 13:03, Bingzheng Wu wrote: > I am wrong again. Adding master-secret is useless. > > Now I think that asymmetric crypto must be used to prevent offline directory attack, which is the way PAKE works as. > I'm probably wrong since I only thought about it for a few minutes, but it seems to me that the PasswordVerify message would be encrypted with (keys derived from) the handshake master secret, which would prevent offline attacks. What am I missing? > Sorry for disturbing. > Probably sorry too :) Manuel. > ------------------------------------------------------------------ > From:武炳正(å…中) > Time:2015 Jun 19 (Fri) 16:19 > To:武炳正(å…中) , tls > Subject:RE: [TLS] is it good using password for authentication only? > > Maybe I realize the problem. The PasswordVerify message is susceptible to > offline dictionary attacks. > > Dose it become resistant to the attack if we add some secret generated from > master-secret into the HASH? > > PasswordVerify = HASH(username, passward, handshake_message_hash, > master-secret, label) > > This becomes involved with key-exchange, but it is not involved with any > specific key-exchange method. > It just need the key-exchange result. > > > Bingzheng > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Jul 19 03:42:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EB51AC406 for ; Sun, 19 Jul 2015 03:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 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_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 6oCLybuEGOvn for ; Sun, 19 Jul 2015 03:42:24 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C021AC402 for ; Sun, 19 Jul 2015 03:42:23 -0700 (PDT) Received: by wgmn9 with SMTP id n9so110930199wgm.0 for ; Sun, 19 Jul 2015 03:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X4rL6BkqnBGPbQTF0xugSFMNpCn5+I0AJxpv7Lds9uQ=; b=oUmdIOVveNDQpkZvhqgSmb/2tX7QxVBZjvSv8aM7JMDhl8zasQTeBLJYCgs20IktVf MVgRton6F7vbyav45t8XbMjM1Yf234HLtXZ13aouPhEQpl7FgIOHs/o8s3m5Ru2bCfO0 rjyH+7tKUBx/bQtBaqX5uviODTmmoIOdv/VaQ= 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=X4rL6BkqnBGPbQTF0xugSFMNpCn5+I0AJxpv7Lds9uQ=; b=MKqd0/dH9hNgviSoWulL3R2TSHfd5bFpVIIgJHbB7JDsWntFd4arJUDWvLEJPaQbD+ b3k48KD/pD7QLeSUA4ATynNThrE/8h5WLkKQIae/gEP3mO5wUg+hXzIr2rzKzf8Jh9Qw 15KG8dzliXkaF/OdSg0yzd7FE/2QnxXMX8wpA6bhBpULY6Ob1r7G9WWmrUvwFbHpgYwv HNNMs9dziLgxM2qCjb2W+In4r9PdoKawN8OJH5ZV5tR4gllCxtsj6FrYZwFpZobcHMQD f5glJxn9bE39t3vcVJUSWqxgVLHdmpnJPZBiAJG8Z1S6klK2oH5hD4o+rGVmeVAFZARg 8zSw== X-Gm-Message-State: ALoCoQmGQ3PO9KID28ChseHFYN/gZgz0Wdt4QRPo6bsEfgrEYeUCALCdfDpSztxchwlz4hzD3nxx MIME-Version: 1.0 X-Received: by 10.194.47.209 with SMTP id f17mr45397157wjn.39.1437302542643; Sun, 19 Jul 2015 03:42:22 -0700 (PDT) Received: by 10.28.90.85 with HTTP; Sun, 19 Jul 2015 03:42:22 -0700 (PDT) In-Reply-To: <55AB7A19.5030502@elzevir.fr> References: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com> <----3-------MPf3-$9050573e-2304-452c-9b77-668deaf79dd6@alibaba-inc.com> <55AB7A19.5030502@elzevir.fr> Date: Sun, 19 Jul 2015 12:42:22 +0200 Message-ID: From: Thijs van Dijk To: Manuel Pegourie-Gonnard Content-Type: multipart/alternative; boundary=047d7b86df467d950e051b381363 Archived-At: Cc: tls Subject: Re: [TLS] is it good using password for authentication only? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 10:42:25 -0000 --047d7b86df467d950e051b381363 Content-Type: text/plain; charset=UTF-8 Hi Manuel, On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard wrote: > I'm probably wrong since I only thought about it for a few minutes, but it > seems to me that the PasswordVerify message would be encrypted with (keys > derived from) the handshake master secret, which would prevent offline > attacks. > > What am I missing? The key observation is the following: (I mentioned this off-list a few weeks ago, but I guess I'll post it here as well for posterity.) [T]he master secret will be derived from the client's and server's > respective KeyShare messages, and will therefore be known at the time the > server's PasswordVerify is sent. A malicious client could therefore perform > half a handshake (just enough to get the server to give up its PV message), > abort, and proceed with an offline attack in its own time. I thought about switching the order in which server and client send their > PV, but in much the same manner this won't protect clients from malicious > servers. -Thijs --047d7b86df467d950e051b381363 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Manuel,

On 19 July 2015 at 12:21, Ma= nuel Pegourie-Gonnard <mpg2@elzevir.fr> wrote:
I'm pr= obably wrong since I only thought about it for a few minutes, but it seems = to me that the PasswordVerify message would be encrypted with (keys derived= from) the handshake master secret, which would prevent offline attacks.
What am I missing?

The key observation is t= he following: (I mentioned this off-list a few weeks ago, but I guess I'= ;ll post it here as well for posterity.)

[T]he master secret will be derived from the client's and serve= r's respective KeyShare messages, and will therefore be known at the ti= me the server's PasswordVerify is sent. A malicious client could theref= ore perform half a handshake (just enough to get the server to give up its = PV message), abort, and proceed with an offline attack in its own time.=C2= =A0
=C2=A0
I thou= ght about switching the order in which server and client send their PV, but= in much the same manner this won't protect clients from malicious serv= ers.

-Thijs
--047d7b86df467d950e051b381363-- From nobody Sun Jul 19 05:50:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421B31ACE88 for ; Sun, 19 Jul 2015 05:50:21 -0700 (PDT) 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 vjnijDTr0AJ0 for ; Sun, 19 Jul 2015 05:50:19 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208821ACE7C for ; Sun, 19 Jul 2015 05:50:18 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id BD3383FE8; Sun, 19 Jul 2015 15:50:16 +0300 (EEST) Date: Sun, 19 Jul 2015 15:50:16 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150719125016.GA17542@LK-Perkele-VII> References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201507181428.40766.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 12:50:21 -0000 On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett wrote: > On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > > This is not really what I was intending when I suggested the feature. I was > > intending for their to be an indication, in the ClientHello, that the > > server should not do any of the work that it would normally do to make the > > session resumable. > > Ok, I might as well write up the generic solution then: > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest Are the features besides "don't bother making resumable session, I won't resume." needed? E.g. For what would client hinting session lifetime be useful for? -Ilari From nobody Sun Jul 19 05:57:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F651ACE9A for ; Sun, 19 Jul 2015 05:57:04 -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 w8xI_62TpgQT for ; Sun, 19 Jul 2015 05:57:03 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F42351ACE61 for ; Sun, 19 Jul 2015 05:57:02 -0700 (PDT) Received: by widic2 with SMTP id ic2so69014426wid.0 for ; Sun, 19 Jul 2015 05:57:01 -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=NtopAAwXy3X5R0R93HNwa9BiX16xNQT0o9pLAeNH2ek=; b=ErcUt0SlQ8XzTG41OMjG1N3zawM2SQMOTztQ/pyfP28jKifSDgg5u22vTyZM4ARLQV kHnS3aK4J2JSXyQa16/cklGybpetuGfWBmX/5lxXisU0mjYS+TM3n5zUU4vk0ojV/FXP 5EnPSKl2dpJDLO2S13+VErmjfGq/QYuQQi2afwDZbjn0RGesn9tKSrLtEJc1wnA9hJdh OJ5jF+63cQ1X9v1u7PQCs0I7HhOgjzq+7sL1MrhNFnrAl6nT3Fg2kfY6ATxHAU6u+upQ QVu+ThLTV+8sAWMteerDPfo9w6XZ4j8fTM4uZPQzS1EMT2H3R0UDP5FqBb3x0/KgonAv zIPw== X-Gm-Message-State: ALoCoQktgCvj9uww6xRVcOoWZm1CG6QHBz8V/vw8uwkbbH7tXLTHwCLpyTf+glpgsjK3QHriYBzk X-Received: by 10.194.133.73 with SMTP id pa9mr46373111wjb.148.1437310621692; Sun, 19 Jul 2015 05:57:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 05:56:22 -0700 (PDT) In-Reply-To: <20150719125016.GA17542@LK-Perkele-VII> References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> From: Eric Rescorla Date: Sun, 19 Jul 2015 14:56:22 +0200 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e011771a909cf41051b39f56e Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 12:57:05 -0000 --089e011771a909cf41051b39f56e Content-Type: text/plain; charset=UTF-8 I'm not seeing a lot of value here. Remember that servers are not required (and have never been required) to do session resumption, but much of the overhead of doing it (having to have a database, session ticket machinery) is associated with being willing to do session resumption at all, so if a small fraction of clients would tell you that they're not interested in resumption, it's not clear that buys you much. Are there any server operators who think this is a useful feature and can explain why? -Ekr On Sun, Jul 19, 2015 at 2:50 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett wrote: > > On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > > > This is not really what I was intending when I suggested the feature. > I was > > > intending for their to be an indication, in the ClientHello, that the > > > server should not do any of the work that it would normally do to make > the > > > session resumable. > > > > Ok, I might as well write up the generic solution then: > > > > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest > > Are the features besides "don't bother making resumable session, I won't > resume." needed? > > E.g. For what would client hinting session lifetime be useful for? > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e011771a909cf41051b39f56e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not seeing a lot of value here. Remember that= servers are not
required (and have never been required) to do se= ssion resumption, but
much of the overhead of doing it (having to= have a database, session
ticket machinery) is associated with be= ing willing to do session
resumption at all, so if a small fracti= on of clients would tell
you that they're not interested in r= esumption, it's not clear that
buys you much.

<= /div>
Are there any server operators who think this is a useful feature=
and can explain why?

-Ekr


On Sun, Jul 19, 2015 at 2:50 PM, Ilari Liusvaara &= lt;ilari.l= iusvaara@elisanet.fi> wrote:
On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett w= rote:
> On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote:
> > This is not really what I was intending when I suggested the feat= ure. I was
> > intending for their to be an indication, in the ClientHello, that= the
> > server should not do any of the work that it would normally do to= make the
> > session resumable.
>
> Ok, I might as well write up the generic solution then:
>
> https://github.c= om/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest

Are the features besides "don't bother making resumable ses= sion, I won't
resume." needed?

E.g. For what would client hinting session lifetime be useful for?


-Ilari

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

--089e011771a909cf41051b39f56e-- From nobody Sun Jul 19 10:17:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397BE1A0381 for ; Sun, 19 Jul 2015 10:17:00 -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 bRlQBA6y9LcR for ; Sun, 19 Jul 2015 10:16:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39901A047A for ; Sun, 19 Jul 2015 10:16:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7C930284B6C; Sun, 19 Jul 2015 17:16:57 +0000 (UTC) Date: Sun, 19 Jul 2015 17:16:57 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150719171657.GL28047@mournblade.imrryr.org> References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets 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: Sun, 19 Jul 2015 17:17:00 -0000 On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote: > I'm not seeing a lot of value here. Remember that servers are not > required (and have never been required) to do session resumption, but > much of the overhead of doing it (having to have a database, session > ticket machinery) is associated with being willing to do session > resumption at all, so if a small fraction of clients would tell > you that they're not interested in resumption, it's not clear that > buys you much. > > Are there any server operators who think this is a useful feature > and can explain why? These days, I'm operating servers that only support session tickets (no server-side cache). If the client does not send the session ticket extension, no session is cached. So for servers that elect the same strategy, there's no need for a separate means to signal the client's intentions. -- Viktor. From nobody Sun Jul 19 10:36:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CC71B2AA0 for ; Sun, 19 Jul 2015 10:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, 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 4Dssm2gzRGxK for ; Sun, 19 Jul 2015 10:36:22 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CA31A0363 for ; Sun, 19 Jul 2015 10:36:21 -0700 (PDT) Received: from [192.168.1.102] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id C49B9F210A; Sun, 19 Jul 2015 10:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1437327090; bh=RKn2sMZoZwhAOdbUI39F2qmmPISKJG3k2eDijcVz+7Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=aJxigovoRSs/hEhLUBh+O3egeL/g0B6oBZDJbAa7+229ik7gdU5NSTLWrxJDz88Vk buwGly7cwksaeLxR1Xrx98rUAyFOHTPP2rA0dcxw7G8pdD9hYo4A2mGZb41q2pewEh My9RHYSxz1mRRduIHilpsmNQJZV2UDaLkuG+9myc= To: Thijs van Dijk , Manuel Pegourie-Gonnard References: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com> <----3-------MPf3-$9050573e-2304-452c-9b77-668deaf79dd6@alibaba-inc.com> <55AB7A19.5030502@elzevir.fr> From: Mike Hamburg Message-ID: <55ABE011.8000400@shiftleft.org> Date: Sun, 19 Jul 2015 10:36:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040603060201060105080202" Archived-At: Cc: tls Subject: Re: [TLS] is it good using password for authentication only? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 17:36:23 -0000 This is a multi-part message in MIME format. --------------040603060201060105080202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Also, it isn't too difficult to implement a PAKE. But there isn't a (known?) way to do it without adding rounds, if you want to protect the username. This is because the server needs the username before it can do anything with the password. Unless it has 0-RTT information the client can't encrypt the username before receiving the server's ephemeral share. So you need at least ClientHello -> <- ServerKeyshare PakeStuff -> <- PasswordVerify PasswordVerify, Finished -> (With other messages in there too of course, but these ones limit the round count with PAKE.) -- Mike On 7/19/2015 3:42 AM, Thijs van Dijk wrote: > Hi Manuel, > > On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard > wrote: > > I'm probably wrong since I only thought about it for a few > minutes, but it seems to me that the PasswordVerify message would > be encrypted with (keys derived from) the handshake master secret, > which would prevent offline attacks. > > What am I missing? > > > The key observation is the following: (I mentioned this off-list a few > weeks ago, but I guess I'll post it here as well for posterity.) > > [T]he master secret will be derived from the client's and server's > respective KeyShare messages, and will therefore be known at the > time the server's PasswordVerify is sent. A malicious client could > therefore perform half a handshake (just enough to get the server > to give up its PV message), abort, and proceed with an offline > attack in its own time. > > I thought about switching the order in which server and client > send their PV, but in much the same manner this won't protect > clients from malicious servers. > > > -Thijs > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------040603060201060105080202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Also, it isn't too difficult to implement a PAKE.  But there isn't a (known?) way to do it without adding rounds, if you want to protect the username.  This is because the server needs the username before it can do anything with the password.  Unless it has 0-RTT information the client can't encrypt the username before receiving the server's ephemeral share.  So you need at least

ClientHello ->
<- ServerKeyshare
PakeStuff ->
<- PasswordVerify
PasswordVerify, Finished ->

(With other messages in there too of course, but these ones limit the round count with PAKE.)

-- Mike

On 7/19/2015 3:42 AM, Thijs van Dijk wrote:
Hi Manuel,

On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard <mpg2@elzevir.fr> wrote:
I'm probably wrong since I only thought about it for a few minutes, but it seems to me that the PasswordVerify message would be encrypted with (keys derived from) the handshake master secret, which would prevent offline attacks.

What am I missing?

The key observation is the following: (I mentioned this off-list a few weeks ago, but I guess I'll post it here as well for posterity.)

[T]he master secret will be derived from the client's and server's respective KeyShare messages, and will therefore be known at the time the server's PasswordVerify is sent. A malicious client could therefore perform half a handshake (just enough to get the server to give up its PV message), abort, and proceed with an offline attack in its own time. 
 
I thought about switching the order in which server and client send their PV, but in much the same manner this won't protect clients from malicious servers.

-Thijs


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

--------------040603060201060105080202-- From nobody Sun Jul 19 11:18:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2121B2B7F for ; Sun, 19 Jul 2015 11:18:24 -0700 (PDT) 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 bzrpqQu1DNhB for ; Sun, 19 Jul 2015 11:18:22 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDFA1B2B7E for ; Sun, 19 Jul 2015 11:18:22 -0700 (PDT) Received: from fifthhorseman.net (dhcp-a29a.meeting.ietf.org [31.133.162.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 4E891F984; Sun, 19 Jul 2015 14:18:21 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E8C29202E8; Sun, 19 Jul 2015 20:18:18 +0200 (CEST) From: Daniel Kahn Gillmor To: Viktor Dukhovni , tls@ietf.org In-Reply-To: <20150701035820.GJ14121@mournblade.imrryr.org> References: <55922571.8080605@nomountain.net> <20150701035820.GJ14121@mournblade.imrryr.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 19 Jul 2015 20:18:18 +0200 Message-ID: <87k2twm2ol.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-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: Sun, 19 Jul 2015 18:18:24 -0000 Thanks for this draft, i'm definitely interested in seeing it push forward. On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote: > Instead, there would need to be in various cases: > > * A validated chain of CNAMEs (possibly synthesized via validated > DNAME RRs) leading from the client's requested SNI name to > a final TLSA base domain. (0 or more CNAME/DNAME indirection > records and all the DNSKEY/DS/RRSIG records to validate > these). > > * A validated chain of CNAMES from _port._proto. to > an actual validated TLSA RRset (and ...). > > * The final TLSA RRset with all the requisite validation records. > > * Also a potential change in the client's notion of the reference > identifier to match in certificates, to the final TLSA base domain. Complicating this further, there could be a chain to an SRV or MX record, which then needs to chain to the TLSA, in think (possibly with CNAMEs in the mix). This is potentially a pretty long chain. also: how does a multi-tenanted server know what SRV or MX chain to include in the chain? --dkg From nobody Sun Jul 19 11:19:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8005C1B2B84 for ; Sun, 19 Jul 2015 11:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 xCtzSaIWwHOt for ; Sun, 19 Jul 2015 11:19:16 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88B71B2B7F for ; Sun, 19 Jul 2015 11:19:15 -0700 (PDT) Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 501B81618A; Sun, 19 Jul 2015 20:19:14 +0200 (CEST) Received: from [192.168.11.181] (unknown [88.208.109.142]) by thue.elzevir.fr (Postfix) with ESMTPSA id 41BF71FA1E; Sun, 19 Jul 2015 20:19:13 +0200 (CEST) Message-ID: <55ABEA1F.6060601@elzevir.fr> Date: Sun, 19 Jul 2015 20:19:11 +0200 From: Manuel Pegourie-Gonnard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Thijs van Dijk References: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com> <----3-------MPf3-$9050573e-2304-452c-9b77-668deaf79dd6@alibaba-inc.com> <55AB7A19.5030502@elzevir.fr> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls Subject: Re: [TLS] is it good using password for authentication only? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 18:19:17 -0000 Hi Thijs, On 7/19/15 12:42, Thijs van Dijk wrote: > On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard wrote: > >> I'm probably wrong since I only thought about it for a few minutes, but it >> seems to me that the PasswordVerify message would be encrypted with (keys >> derived from) the handshake master secret, which would prevent offline >> attacks. >> >> What am I missing? > > The key observation is the following: (I mentioned this off-list a few > weeks ago, but I guess I'll post it here as well for posterity.) > >> [T]he master secret will be derived from the client's and server's >> respective KeyShare messages, and will therefore be known at the time the >> server's PasswordVerify is sent. A malicious client could therefore perform >> half a handshake (just enough to get the server to give up its PV message), >> abort, and proceed with an offline attack in its own time. Indeed. Thanks! (And sorry for the noise, as expected.) Manuel. From nobody Sun Jul 19 11:53:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C2E1B2BAD for ; Sun, 19 Jul 2015 11:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, 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 X5BUX2EQdyTF for ; Sun, 19 Jul 2015 11:53:57 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8A11B2BAB for ; Sun, 19 Jul 2015 11:53:57 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id A3567161A7; Sun, 19 Jul 2015 20:53:55 +0200 (CEST) Received: from [192.168.11.181] (unknown [88.208.109.142]) by thue.elzevir.fr (Postfix) with ESMTPSA id AA8AF1FA1E; Sun, 19 Jul 2015 20:53:54 +0200 (CEST) Message-ID: <55ABF240.6090506@elzevir.fr> Date: Sun, 19 Jul 2015 20:53:52 +0200 From: Manuel Pegourie-Gonnard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ilari Liusvaara , Dave Garrett References: <201506111558.21577.davemgarrett@gmail.com> <20150612083153.GA24990@LK-Perkele-VII> In-Reply-To: <20150612083153.GA24990@LK-Perkele-VII> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 18:53:58 -0000 Hi, sorry for resurecting an old message on a fairly tangential point. On 6/12/15 10:31, Ilari Liusvaara wrote: > AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for > both DHE (via ciphersuites) and ECDSA (via (possibly implicit default) > signature_algorithms). > > (In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA) > Either we're not talking about the same thing, or we don't read RFC 5246 in the same way. Section 7.4.2 (pages 47-48) says: - The end entity certificate's public key (and associated restrictions) MUST be compatible with the selected key exchange algorithm. Key Exchange Alg. Certificate Key Type [...] DHE_RSA RSA public key; [...] To me that clearly means that if the server selects a DHE_RSA ciphersuite, it MUST NOT use a certificate that contains an EC key, even if the client offered ECDSA in the signature_algorithm extension. However, in that case the certificate may be signed using ECDSA, which is not the same. > Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is > quite clear about interaction of signature algorithms in ciphersuites > and explicit signature negotiation (explicit negotiation always takes > percedence). > I'm afraid we both agree that TLS 1.2 is quite clear, but disagree about what it says, which is ironic :) My understanding is that, regarding the key in the server's certificate, there is indeed double negotiation, with a clear rule that the set of allowed choices is the intersection of what is allowed by the ciphersuite and what is allowed by the signature_algorithms extension. If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension. Note that there is a possibility for inconsistencies here. For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension. In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them. This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design. To me, the "MUST check against" does not suggest "may still pick the DHE_DSS suite and use an RSA cert with it if signature_algorithms contains acceptable RSA pairs". Regarding other signatures in the certificate chain, only signature_algorithms apply, so there is no "double negotiation" indeed. > Of course, I wouldn't be surprised if there was fair bit of software > that got those rules wrong... > Regardless of whether your interpretation or mine is correct, I'm pretty sure various implementations will do things in different ways here. Anyway, a large proportion of servers deployments only have one cert, in which case the RFC says "it [the server] SHOULD attempt to validate that it [the certificate] meets these criteria", which may be interpreted as an indication that the server may try to send its only certificate anyway and let the client decide how to deal with it. Manuel. From nobody Sun Jul 19 11:59:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9221B2BB4 for ; Sun, 19 Jul 2015 11:59:10 -0700 (PDT) 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_35=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 dtRQN0aeUWUS for ; Sun, 19 Jul 2015 11:59:09 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C3B1B2BB3 for ; Sun, 19 Jul 2015 11:59:08 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so75696086wib.0 for ; Sun, 19 Jul 2015 11:59:07 -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=PqvZjkLKWq1y4EhZ3R5o6a9zfdEa6/1+XV8xF1AkoU4=; b=XvSdG8Mw4aDN6hJl60+H8OlBslRmYdZ113i68732iywVRLCkJGG32P320wK4AMNKBX SkR3RovONbT2Jc95p0bsePMvFQ/EhSz8YsQxGRsGoAp8YMbckdk3BEOHf3vEMUuwumTJ iyKZFIdCtexThWDYhAgq0uPjZtrUoYYSB1kfhOMGhL8fSfR9SE2auaBKdEE6Qo4J1LNu /uFnhyrAOWggvorjM2yu0OZK+SkFupSsXOuYaENtHjAbjlIDwY+dmGC+eZuGKvjeTZrP JAFP/wskVgdbKz2DRlKmsUaoIAc5W4S9HobNca4sRA6meIPbqCbtMnJd1AE3mLHBJmvM 9vOQ== X-Gm-Message-State: ALoCoQmzVQ1CzTsv0UJsjduztSvg/S/SVECw1HAvrKNjA5vjc821H3wSB90FjxMyXODhjRk6C4UT X-Received: by 10.180.208.114 with SMTP id md18mr14633677wic.31.1437332347278; Sun, 19 Jul 2015 11:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 11:58:27 -0700 (PDT) In-Reply-To: <55ABF240.6090506@elzevir.fr> References: <201506111558.21577.davemgarrett@gmail.com> <20150612083153.GA24990@LK-Perkele-VII> <55ABF240.6090506@elzevir.fr> From: Eric Rescorla Date: Sun, 19 Jul 2015 20:58:27 +0200 Message-ID: To: Manuel Pegourie-Gonnard Content-Type: multipart/alternative; boundary=001a11c37eb8fbf09e051b3f03c0 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 18:59:10 -0000 --001a11c37eb8fbf09e051b3f03c0 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard wrote: > Hi, > > sorry for resurecting an old message on a fairly tangential point. > > On 6/12/15 10:31, Ilari Liusvaara wrote: > >> AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for >> both DHE (via ciphersuites) and ECDSA (via (possibly implicit default) >> signature_algorithms). >> >> (In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA) >> >> Either we're not talking about the same thing, or we don't read RFC 5246 > in the same way. Section 7.4.2 (pages 47-48) says: > > - The end entity certificate's public key (and associated > restrictions) MUST be compatible with the selected key exchange > algorithm. > > Key Exchange Alg. Certificate Key Type > [...] > DHE_RSA RSA public key; [...] > > To me that clearly means that if the server selects a DHE_RSA ciphersuite, > it MUST NOT use a certificate that contains an EC key, even if the client > offered ECDSA in the signature_algorithm extension. However, in that case > the certificate may be signed using ECDSA, which is not the same. > > Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is >> quite clear about interaction of signature algorithms in ciphersuites >> and explicit signature negotiation (explicit negotiation always takes >> percedence). >> >> I'm afraid we both agree that TLS 1.2 is quite clear, but disagree about > what it says, which is ironic :) My understanding is that, regarding the > key in the server's certificate, there is indeed double negotiation, with a > clear rule that the set of allowed choices is the intersection of what is > allowed by the ciphersuite and what is allowed by the signature_algorithms > extension. > > If the client has offered the "signature_algorithms" extension, the > signature algorithm and hash algorithm MUST be a pair listed in that > extension. Note that there is a possibility for inconsistencies > here. For instance, the client might offer DHE_DSS key exchange but > omit any DSA pairs from its "signature_algorithms" extension. In > order to negotiate correctly, the server MUST check any candidate > cipher suites against the "signature_algorithms" extension before > selecting them. This is somewhat inelegant but is a compromise > designed to minimize changes to the original cipher suite design. > > To me, the "MUST check against" does not suggest "may still pick the > DHE_DSS suite and use an RSA cert with it if signature_algorithms contains > acceptable RSA pairs". > > Regarding other signatures in the certificate chain, only > signature_algorithms apply, so there is no "double negotiation" indeed. This is how I understand the situation as well. I am sad to hear that we didn't manage to make the document clear on this point. -Ekr > > Of course, I wouldn't be surprised if there was fair bit of software >> that got those rules wrong... >> >> Regardless of whether your interpretation or mine is correct, I'm pretty > sure various implementations will do things in different ways here. Anyway, > a large proportion of servers deployments only have one cert, in which case > the RFC says "it [the server] SHOULD attempt to validate that it [the > certificate] meets these criteria", which may be interpreted as an > indication that the server may try to send its only certificate anyway and > let the client decide how to deal with it. > > Manuel. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c37eb8fbf09e051b3f03c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard <mpg2@elzevir.f= r> wrote:
Hi,

sorry for resurecting an old message on a fairly tangential point.

On 6/12/15 10:31, Ilari Liusvaara wrote:
AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
signature_algorithms).

(In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA)

 Either we're not talking about the same thing, or we don't read RFC= 5246 in the same way. Section 7.4.2 (pages 47-48) says:

=C2=A0 =C2=A0-=C2=A0 The end entity certificate's public key (and assoc= iated
=C2=A0 =C2=A0 =C2=A0 restrictions) MUST be compatible with the selected key= exchange
=C2=A0 =C2=A0 =C2=A0 algorithm.

=C2=A0 =C2=A0 =C2=A0 Key Exchange Alg.=C2=A0 Certificate Key Type
=C2=A0 =C2=A0 =C2=A0 [...]
=C2=A0 =C2=A0 =C2=A0 DHE_RSA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RSA p= ublic key; [...]

To me that clearly means that if the server selects a DHE_RSA ciphersuite, = it MUST NOT use a certificate that contains an EC key, even if the client o= ffered ECDSA in the signature_algorithm extension. However, in that case th= e certificate may be signed using ECDSA, which is not the same.

Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2= is
quite clear about interaction of signature algorithms in ciphersuites
and explicit signature negotiation (explicit negotiation always takes
percedence).

 I'm afraid we both agree that TLS 1.2 is quite clear, but disagree abou= t what it says, which is ironic :) My understanding is that, regarding the = key in the server's certificate, there is indeed double negotiation, wi= th a clear rule that the set of allowed choices is the intersection of what= is allowed by the ciphersuite and what is allowed by the signature_algorit= hms extension.

=C2=A0 =C2=A0If the client has offered the "signature_algorithms"= extension, the
=C2=A0 =C2=A0signature algorithm and hash algorithm MUST be a pair listed i= n that
=C2=A0 =C2=A0extension.=C2=A0 Note that there is a possibility for inconsis= tencies
=C2=A0 =C2=A0here.=C2=A0 For instance, the client might offer DHE_DSS key e= xchange but
=C2=A0 =C2=A0omit any DSA pairs from its "signature_algorithms" e= xtension.=C2=A0 In
=C2=A0 =C2=A0order to negotiate correctly, the server MUST check any candid= ate
=C2=A0 =C2=A0cipher suites against the "signature_algorithms" ext= ension before
=C2=A0 =C2=A0selecting them.=C2=A0 This is somewhat inelegant but is a comp= romise
=C2=A0 =C2=A0designed to minimize changes to the original cipher suite desi= gn.

To me, the "MUST check against" does not suggest "may still = pick the DHE_DSS suite and use an RSA cert with it if signature_algorithms = contains acceptable RSA pairs".

Regarding other signatures in the certificate chain, only signature_algorit= hms apply, so there is no "double negotiation" indeed.

This is how I understand the situation as well. I am = sad to hear that we didn't
manage to make the document clear = on this point.

-Ekr
=C2=A0

Of course, I wouldn't be surprised if there was fair bit of software that got those rules wrong...

 Regardless of whether your interpretation or mine is correct, I'm prett= y sure various implementations will do things in different ways here. Anywa= y, a large proportion of servers deployments only have one cert, in which c= ase the RFC says "it [the server] SHOULD attempt to validate that it [= the certificate] meets these criteria", which may be interpreted as an= indication that the server may try to send its only certificate anyway and= let the client decide how to deal with it.

Manuel.


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

--001a11c37eb8fbf09e051b3f03c0-- From nobody Sun Jul 19 12:49:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6D1A8A48 for ; Sun, 19 Jul 2015 12:49:46 -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 Vn9LtsiKpBmS for ; Sun, 19 Jul 2015 12:49:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC981A8A3A for ; Sun, 19 Jul 2015 12:49:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CB138284D6F; Sun, 19 Jul 2015 19:49:43 +0000 (UTC) Date: Sun, 19 Jul 2015 19:49:43 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150719194943.GO28047@mournblade.imrryr.org> References: <55922571.8080605@nomountain.net> <20150701035820.GJ14121@mournblade.imrryr.org> <87k2twm2ol.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k2twm2ol.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-00 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: Sun, 19 Jul 2015 19:49:46 -0000 On Sun, Jul 19, 2015 at 08:18:18PM +0200, Daniel Kahn Gillmor wrote: > On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote: > > Instead, there would need to be in various cases: > > > > * A validated chain of CNAMEs (possibly synthesized via validated > > DNAME RRs) leading from the client's requested SNI name to > > a final TLSA base domain. (0 or more CNAME/DNAME indirection > > records and all the DNSKEY/DS/RRSIG records to validate > > these). > > > > * A validated chain of CNAMES from _port._proto. to > > an actual validated TLSA RRset (and ...). > > > > * The final TLSA RRset with all the requisite validation records. > > > > * Also a potential change in the client's notion of the reference > > identifier to match in certificates, to the final TLSA base domain. > > Complicating this further, there could be a chain to an SRV or MX > record, which then needs to chain to the TLSA, in think (possibly with > CNAMEs in the mix). This is potentially a pretty long chain. also: how > does a multi-tenanted server know what SRV or MX chain to include in the > chain? My reading of the draft is that it is primary aimed at making DANE practical for HTTPS, where last-mile considerations on the client end are a significant part of the adoption barrier. For HTTP, MX and SRV records are out of scope. Clients that depend on DNS to the extent of determining the server identity based on MX or SRV records, already need DNSSEC to avoid MiTM issues, and at least in the case of SMTP and XMPP are expected to handle DANE without stapled TLSA RRsets (and associated RRSIG/DNSKEY/DS chains). -- Viktor. From nobody Sun Jul 19 13:17:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1121A894C for ; Sun, 19 Jul 2015 13:17:13 -0700 (PDT) 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 bTYXNcvGT2l8 for ; Sun, 19 Jul 2015 13:17:11 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876741A8948 for ; Sun, 19 Jul 2015 13:17:11 -0700 (PDT) Received: by oigd21 with SMTP id d21so55746683oig.1 for ; Sun, 19 Jul 2015 13:17:10 -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:date :message-id:subject:from:to:content-type; bh=yeR/I9pj9fq1q3Vmb6kd2Wg+6uu0YQO159rJ9/ndNMQ=; b=U3YpWCK+SkMgQZ93uW7Yw9/j6emOH7r7NveYBEeKDUWmNmAzKo56y2K1aOfnIOiYn7 BwsYWtES4AaYhA4yhCbvxtSCUyfZkjqGLHUuI3I+vsqL2bvNeU5U4MUSWLadj/2TI7+O zg/6Bu/kuBCJOF2VlrYVgN29Sxoz8ghUADHWVtywCQ0oHoxf9Al91diiBzaqIkYeob+f uPg8NmBtV32dpbRGUd2FjBPp/ZV754qU8ZQcmsMLlf2VTpdavvLFoYcQc0SAnQSKupZg 94/2shWbBucBi2YcyhDEYJDOe5SB5JNJ/bSuSfy/SthTFlv2aVskxflMwNb3JQ+HwMIN 6pdA== X-Gm-Message-State: ALoCoQmv2KoKZJ5/HuxRHQ3Fg1tEJhBq472gnPk0uEzn+sxcQ6MDOHEdrl5VdWoblx/Wm2zUQZ3X MIME-Version: 1.0 X-Received: by 10.202.52.138 with SMTP id b132mr21825964oia.125.1437337030661; Sun, 19 Jul 2015 13:17:10 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Sun, 19 Jul 2015 13:17:10 -0700 (PDT) In-Reply-To: <20150719171657.GL28047@mournblade.imrryr.org> References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> Date: Sun, 19 Jul 2015 16:17:10 -0400 Message-ID: From: Brian Smith To: "" Content-Type: multipart/alternative; boundary=001a113d3e0222a4aa051b401be1 Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 20:17:13 -0000 --001a113d3e0222a4aa051b401be1 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni wrote: > On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote: > > > I'm not seeing a lot of value here. Remember that servers are not > > required (and have never been required) to do session resumption, but > > much of the overhead of doing it (having to have a database, session > > ticket machinery) is associated with being willing to do session > > resumption at all, so if a small fraction of clients would tell > > you that they're not interested in resumption, it's not clear that > > buys you much. > > > > Are there any server operators who think this is a useful feature > > and can explain why? > > These days, I'm operating servers that only support session tickets > (no server-side cache). If the client does not send the session > ticket extension, no session is cached. > > So for servers that elect the same strategy, there's no need for > a separate means to signal the client's intentions. > First, I think that there should be only one way to do resumption in TLS 1.3 anyway. All I'm asking for is that the client have some way of indicating whether or not it supports resumption. Viktor's method seems fine with me. Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft actually contains a regression here. It seems like it is no longer possible for the server to indicate how long a PSK should be held by the client to resume a session, and it seems like it is no longer possible for the server to indicate that it doesn't support resumption. I don't know that the lifetime hint is valuable, but being able to reduce attack surface by being disabling resumption for a session seems clearly useful. See https://www.secure-resumption.com/, CVE-2014-1490 in Firefox/NSS, and CVE-2015-1791 in OpenSSL, which show that it can be useful to avoid resumption in many cases. Cheers, Brian --001a113d3e0222a4aa051b401be1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
On Sun, Jul 19,= 2015 at 02:56:22PM +0200, Eric Rescorla wrote:

> I'm not seeing a lot of value here. Remember that servers are not<= br> > required (and have never been required) to do session resumption, but<= br> > much of the overhead of doing it (having to have a database, session > ticket machinery) is associated with being willing to do session
> resumption at all, so if a small fraction of clients would tell
> you that they're not interested in resumption, it's not clear = that
> buys you much.
>
> Are there any server operators who think this is a useful feature
> and can explain why?

These days, I'm operating servers that only support session tick= ets
(no server-side cache).=C2=A0 If the client does not send the session
ticket extension, no session is cached.

So for servers that elect the same strategy, there's no need for
a separate means to signal the client's intentions.

First, I think that there should be only one way to do res= umption in TLS 1.3 anyway. All I'm asking for is that the client have s= ome way of indicating whether or not it supports resumption. Viktor's m= ethod seems fine with me.

Maybe I'm misunderst= anding, but it looks like the current TLS 1.3 draft actually contains a reg= ression here. It seems like it is no longer possible for the server to indi= cate how long a PSK should be held by the client to resume a session, and i= t seems like it is no longer possible for the server to indicate that it do= esn't support resumption.

I don't know tha= t the lifetime hint is valuable, but being able to reduce attack surface by= being disabling resumption for a session seems clearly useful. See=C2=A0https://www.secure-resumption.= com/, CVE-2014-1490 in Firefox/NSS, and CVE-2015-1791 in OpenSSL, which= show that it can be useful to avoid resumption in many cases.
Cheers,
Brian

--001a113d3e0222a4aa051b401be1-- From nobody Sun Jul 19 13:22:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4308E1A8999 for ; Sun, 19 Jul 2015 13:22:52 -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 6gdTtpUsC54A for ; Sun, 19 Jul 2015 13:22:50 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840E91A88D3 for ; Sun, 19 Jul 2015 13:22:50 -0700 (PDT) Received: by qkdv3 with SMTP id v3so101757674qkd.3 for ; Sun, 19 Jul 2015 13:22:49 -0700 (PDT) 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=vggP0VRkoMrY+hRn2SlFD9tW0d1gG3OOVtc44m20Xp4=; b=tKXRtvg12F6enZ8pS/TQPzgEGOOFUs5Op9kf1Dnr7HcciP9gVKYr6RcEkKFKOzx3Ob 7gVN9ud87xycu+9LTK2xYRkXIPcKEXqyHLadvSi4pA2oS9q0y1zTAJmtFP+fs/JYnAKp kyGam4PkyaDFwoJZwkD8CS67kVlIqGt5JUc6ZNrns6UeYfo02kf/ArpNC/09PYGHBAuA pbCeuTTlTQcJV4cBsz2Ah/FLGnM/b39EkN3Rr34ywUviQVQVIBdLZolmyDYE+hEIGCYt ZxGy5cg/CIRuMqJYE7EW8zGw/i0zYNWIiHaHr5EMsmnD+fhX6FGoPOYXdrwATB0W9NKr X7tQ== X-Received: by 10.140.91.66 with SMTP id y60mr41429544qgd.90.1437337369805; Sun, 19 Jul 2015 13:22:49 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id p185sm9152124qha.2.2015.07.19.13.22.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jul 2015 13:22:49 -0700 (PDT) From: Dave Garrett To: "" Date: Sun, 19 Jul 2015 16:22:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <55ABF240.6090506@elzevir.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507191622.47921.davemgarrett@gmail.com> Archived-At: Cc: Manuel Pegourie-Gonnard Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 20:22:52 -0000 Since the last time I posted it here, I've made some changes. Everything is rebased on top of what is now PR #201 (it's not really severable from that). https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Now that resumption is PSK-based, some of the language might need tweaking for that, but I not everything is sorted out for PSK-based resumption yet. (there's TODOs in the draft; e.g., doesn't yet say what cipher suites are to be used for resumption) Other than that, it's at a state that (with PR #201) I could submit a PR if we can agree that this is the general path forward. The highlights of this proposal, for those who didn't follow the previous (long) discussions on the topic: * All DH, DHE, ECDH, RSA, and DSS cipher suites are deprecated. (some could still be offered for backwards compatibility, just like before) * The only compatible cipher suites would be those with a handshake portion of ECDHE_ECDSA, ECDHE_PSK, PSK, or ECDHE_anon. (there is an exception in there for completely new stuff, which will essentially be amending this anyway) * All ECDHE_ECDSA suites can negotiate ECHDE/DHE & ECDSA/DSA/RSA via the existing extensions. (no new extensions need to be defined to do this) * Likewise, ECDHE_PSK and ECDHE_anon can negotiate ECHDE/DHE via the existing extension. * A new standards track RFC to promote ECDHE suites from informational is needed, but that was already true. * In addition to reducing combinatorial nonsense with the suites, it results in deprecation of existing DHE suites in favor or DHE done via ECDHE labeled suites only with strong groups. This is the general result of previous discussions. The alternate route that came up was just to ditch the concept of cipher suites entirely and add a new extension to negotiate the AEAD cipher/hash to use with the existing extensions. There's nothing that would preclude moving to that more extreme route if this were to be accepted first, as ECDHE/DHE negotiation via the extension would be needed for that too. I think the WG is more in favor of the route proposed in this changeset at the moment, though. Dave From nobody Sun Jul 19 13:27:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019421B2BCB for ; Sun, 19 Jul 2015 13:27:28 -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 muIsgPBB03hY for ; Sun, 19 Jul 2015 13:27:26 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F194B1B2BC9 for ; Sun, 19 Jul 2015 13:27:25 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so76642595wib.0 for ; Sun, 19 Jul 2015 13:27: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1ope7Jxcqeualc/mBO6pB4362FqdJpwGp3BqU+tTSCM=; b=jeHDboWR+mtkQidJr1B4po14/ZfFJ2pFjm1c8BP/qCw96aAqIyKsLL0q1dUUDL08ps orbIgpjpdOLT/XTLjoKxJSeeQS79tyl7VLzNv/jy4dd7oBmtIzZoFl1u50vJAWSdFEaw zDUdeyBjW1FRJSHqxr7vMy5I9zMB2m5Wx0xn07lwErBBcM74d4cG7tOoW+wZvBbzEKEe /3VMBiBow3Os60M14719JY35cwn5t2+VFtuVg2RGixzAIo8aSGKJ0ej6ryT2O1RgxHFs Qv8Q4bxll63MLoL3lJbHHGMg3b8pPX5lChEL3lGiybJ0+li5tgapZ6q70dlkVhE0kwoo zysw== X-Gm-Message-State: ALoCoQkGxzujA2UGCov341iobglJx7luB6I3W1bDGZCWTcJcWSRVL+5cdGeNcC4d1WClDHSb82bP X-Received: by 10.194.158.42 with SMTP id wr10mr48648942wjb.81.1437337644708; Sun, 19 Jul 2015 13:27:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 13:26:45 -0700 (PDT) In-Reply-To: References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> From: Eric Rescorla Date: Sun, 19 Jul 2015 22:26:45 +0200 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=089e013c6478bc4d17051b403f56 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 20:27:28 -0000 --089e013c6478bc4d17051b403f56 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith wrote: > On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni > wrote: > >> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote: >> >> > I'm not seeing a lot of value here. Remember that servers are not >> > required (and have never been required) to do session resumption, but >> > much of the overhead of doing it (having to have a database, session >> > ticket machinery) is associated with being willing to do session >> > resumption at all, so if a small fraction of clients would tell >> > you that they're not interested in resumption, it's not clear that >> > buys you much. >> > >> > Are there any server operators who think this is a useful feature >> > and can explain why? >> >> These days, I'm operating servers that only support session tickets >> (no server-side cache). If the client does not send the session >> ticket extension, no session is cached. >> >> So for servers that elect the same strategy, there's no need for >> a separate means to signal the client's intentions. >> > > First, I think that there should be only one way to do resumption in TLS > 1.3 anyway. All I'm asking for is that the client have some way of > indicating whether or not it supports resumption. Viktor's method seems > fine with me. > > Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft > actually contains a regression here. It seems like it is no longer possible > for the server to indicate how long a PSK should be held by the client to > resume a session, > Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint value. http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12 and it seems like it is no longer possible for the server to indicate that > it doesn't support resumption. > Well, it can't indicate it, but if it doesn't supply a session ticket, there's no way for the client to do it. -Ekr --089e013c6478bc4d17051b403f56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <brian@briansmith.org= > wrote:
On Sun, Jul 19, 201= 5 at 1:16 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> = wrote:
On Sun, Jul 19, 2015 at 02:56:22PM +0200, = Eric Rescorla wrote:

> I'm not seeing a lot of value here. Remember that servers are not<= br> > required (and have never been required) to do session resumption, but<= br> > much of the overhead of doing it (having to have a database, session > ticket machinery) is associated with being willing to do session
> resumption at all, so if a small fraction of clients would tell
> you that they're not interested in resumption, it's not clear = that
> buys you much.
>
> Are there any server operators who think this is a useful feature
> and can explain why?

These days, I'm operating servers that only support session tick= ets
(no server-side cache).=C2=A0 If the client does not send the session
ticket extension, no session is cached.

So for servers that elect the same strategy, there's no need for
a separate means to signal the client's intentions.

First, I think that there should be only one way to= do resumption in TLS 1.3 anyway. All I'm asking for is that the client= have some way of indicating whether or not it supports resumption. Viktor&= #39;s method seems fine with me.

Maybe I'm mis= understanding, but it looks like the current TLS 1.3 draft actually contain= s a regression here. It seems like it is no longer possible for the server = to indicate how long a PSK should be held by the client to resume a session= ,

Not unless I'= ve made a mistake. NewSessionTicket contains a lifetime_hint value.

http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12


and it seems like it is n= o longer possible for the server to indicate that it doesn't support re= sumption.

Well, it = can't indicate it, but if it doesn't supply a session ticket, there= 's no way for
the client to do it.

-= Ekr

--089e013c6478bc4d17051b403f56-- From nobody Sun Jul 19 13:40:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C609F1B2C1E for ; Sun, 19 Jul 2015 13:40:21 -0700 (PDT) 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 D6tQD8qPbl4f for ; Sun, 19 Jul 2015 13:40:16 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E851B2C0F for ; Sun, 19 Jul 2015 13:40:16 -0700 (PDT) Received: by oihq81 with SMTP id q81so98354849oih.2 for ; Sun, 19 Jul 2015 13:40:15 -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:date :message-id:subject:from:to:cc:content-type; bh=OnFbENUDu7H52YVU+MK3dL9jSLf6NzOmTD83zLQTr00=; b=IOpiLO7C+ANtccp/r3hCpfOzC1sqDXPmTDmVwI60ywn58y+15deRBCCNizrfFDv1K7 MGAR0eIJ1V3PYAGicy/2V1INckjjvg2/DXWwpFRa6/2Cf9r0EiaxEFeuxVFIs2pFeXtD JvHaPC1u2dvGm3/M9TKQtv4e/bkanzcuQ3+xXlUJ3Cm3rcZ+mm4X6ixeLDctdcrLrT/K DFJUZrV99PbQ281CtzRtDJ5gnuUiO6+OlYj9Y62TSkNRycVnJKfp16uRxuAsptYoltiE ZA6MnT0LOf969QNr32PQqwPb1g7igB2mLGIZ1q74wiioL/9vIFJ00PusUAlTOw95ueiB r2wg== X-Gm-Message-State: ALoCoQl+jdw3aDRBcmJifwa1r/08y/xyvgdj783xkdTfZxLtS9k9HSwHLCZpr1SCgGxPt5avS88I MIME-Version: 1.0 X-Received: by 10.60.59.102 with SMTP id y6mr23537186oeq.53.1437338415685; Sun, 19 Jul 2015 13:40:15 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Sun, 19 Jul 2015 13:40:15 -0700 (PDT) In-Reply-To: References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> Date: Sun, 19 Jul 2015 16:40:15 -0400 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0149d1b2b07972051b406d1f Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 20:40:21 -0000 --089e0149d1b2b07972051b406d1f Content-Type: text/plain; charset=UTF-8 Eric Rescorla wrote: > On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith > wrote: > >> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft >> actually contains a regression here. It seems like it is no longer possible >> for the server to indicate how long a PSK should be held by the client to >> resume a session, >> > > Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint > value. > > http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12 > > and it seems like it is no longer possible for the server to indicate that >> it doesn't support resumption. >> > > Well, it can't indicate it, but if it doesn't supply a session ticket, > there's no way for > the client to do it. > Great. I was misunderstanding. Here's the part that is not is still not clear to me: Is the SessionTicket extension still to be used or not? It seems not, AFAICT. If the SessionTicket extension were to be used, then everything would work perfectly as Viktor suggested in his message: the absense of the SessionTicket extension in the ClientHello would be the way that a client can indicate that it doesn't want the session to be cached. It seems weird that the server can supply a lifetime hint but the client can't, especially in cases like WebRTC where there is no functional difference between the two. But, that's a smaller issue than the lack of an indication that resumption machinery isn't wanted at all. Cheers, Brian -- https://briansmith.org/ --089e0149d1b2b07972051b406d1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric= Rescorla <ekr@rtfm.com> wrote:
= On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <brian@briansmith.org= > wrote:
Maybe I'm misunderstanding, but= it looks like the current TLS 1.3 draft actually contains a regression her= e. It seems like it is no longer possible for the server to indicate how lo= ng a PSK should be held by the client to resume a session,

Not unless I've made a m= istake. NewSessionTicket contains a lifetime_hint value.


<= div class=3D"gmail_extra">
and it seems lik= e it is no longer possible for the server to indicate that it doesn't s= upport resumption.

Well, it can't indicate it, but if it doesn't supply a sessi= on ticket, there's no way for
the client to do it.

Great. I was misunderstanding= . Here's the part that is not is still not clear to me: Is the SessionT= icket extension still to be used or not? It seems not, AFAICT. If the Sessi= onTicket extension were to be used, then everything would work perfectly as= =C2=A0Viktor suggested in his message: the absense of the SessionTicket ext= ension in the ClientHello would be the way that a client can indicate that = it doesn't want the session to be cached.

It s= eems weird that the server can supply a lifetime hint but the client can= 9;t, especially in cases like WebRTC where there is no functional differenc= e between the two. But, that's a smaller issue than the lack of an indi= cation that resumption machinery isn't wanted at all.

Cheers,
Brian
--
--089e0149d1b2b07972051b406d1f-- From nobody Sun Jul 19 13:49:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000A71B2C2B for ; Sun, 19 Jul 2015 13:49:53 -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 lmdhf2pJo8TG for ; Sun, 19 Jul 2015 13:49:52 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE8F1B2C2D for ; Sun, 19 Jul 2015 13:49:51 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so10722455wib.1 for ; Sun, 19 Jul 2015 13:49:50 -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=krmvfcI1VQNwgK7GblVU3ZHbFXcmTiooCkPLG14pYeQ=; b=l/n343sLdGv5sBkRlYZKIEWO/lJUZesTGzBNM4YImBCl1C/QqRt67mXhYZYzWp45xM rZRR+CZNEEstTb41KMX+21/eKh7xXCeFl+x3lPDA8DqFrKrN1VvgX3GrjhMk1lvj1+Cy EQIcxLxwNSlmo2iXJOhf/RiOOju6DcjRFw8GU1OQXylMBZjumMGKQJ1+dVzJo5XvapNx 9jSXzlzLDotHXwABOb0dRU7Vm6Scw6PAyjtOXfoN2Xlal6OShwmpZ/1WjaTcPzeu57hG ec5MTHo8sRVvo8zov4ckCeKymEUvJiZVgRTDQOIuISintC8VnIKLp7WP6EQVRuF67zL8 9qmQ== X-Gm-Message-State: ALoCoQk3zHw/aOWFMQ5MjOH6iUF8w26bN03N0CvrXN1E6eBNN4K26dpcU/7wChxrx5gnuHqfs+Sw X-Received: by 10.180.73.244 with SMTP id o20mr15494401wiv.31.1437338990345; Sun, 19 Jul 2015 13:49:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 13:49:10 -0700 (PDT) In-Reply-To: References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> From: Eric Rescorla Date: Sun, 19 Jul 2015 22:49:10 +0200 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=f46d0435c06af113b0051b408f1a Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 20:49:54 -0000 --f46d0435c06af113b0051b408f1a Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith wrote: > Eric Rescorla wrote: > >> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith >> wrote: >> >>> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft >>> actually contains a regression here. It seems like it is no longer possible >>> for the server to indicate how long a PSK should be held by the client to >>> resume a session, >>> >> >> Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint >> value. >> >> http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12 >> >> and it seems like it is no longer possible for the server to indicate >>> that it doesn't support resumption. >>> >> >> Well, it can't indicate it, but if it doesn't supply a session ticket, >> there's no way for >> the client to do it. >> > > Great. I was misunderstanding. Here's the part that is not is still not > clear to me: Is the SessionTicket extension still to be used or not? It > seems not, AFAICT. If the SessionTicket extension were to be used, then > everything would work perfectly as Viktor suggested in his message: the > absense of the SessionTicket extension in the ClientHello would be the way > that a client can indicate that it doesn't want the session to be cached. > No, it's not used. It seems weird that the server can supply a lifetime hint but the client > can't, especially in cases like WebRTC where there is no functional > difference between the two. But, that's a smaller issue than the lack of an > indication that resumption machinery isn't wanted at all. > I don't think it's *that* odd, since tickets have at least two fundamental asymmetries: - The client needs to actually keep state and the server does not (that being the point of tickets) - The client (because they speak first) gets to offer the ticket for resumption and the server can accept it or reject it. -Ekr --f46d0435c06af113b0051b408f1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <brian@briansmith.org= > wrote:
<= div class=3D"gmail_extra">
Eric = Rescorla <ekr@rtfm.com> wrote:
On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <brian@brians= mith.org> wrote:
=
Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draf= t actually contains a regression here. It seems like it is no longer possib= le for the server to indicate how long a PSK should be held by the client t= o resume a session,

Not unless I've made a mistake. NewSess= ionTicket contains a lifetime_hint value.

=

and it seems like it is no longer possibl= e for the server to indicate that it doesn't support resumption.
<= /div>

Well, it can't= indicate it, but if it doesn't supply a session ticket, there's no= way for
the client to do it.

Great. I was misunderstanding. Here's the p= art that is not is still not clear to me: Is the SessionTicket extension st= ill to be used or not? It seems not, AFAICT. If the SessionTicket extension= were to be used, then everything would work perfectly as=C2=A0Viktor sugge= sted in his message: the absense of the SessionTicket extension in the Clie= ntHello would be the way that a client can indicate that it doesn't wan= t the session to be cached.

No, it's not used.


It seems weird that the server can supply a lifetim= e hint but the client can't, especially in cases like WebRTC where ther= e is no functional difference between the two. But, that's a smaller is= sue than the lack of an indication that resumption machinery isn't want= ed at all.

I don= 9;t think it's *that* odd, since tickets have at least two fundamental<= /div>
asymmetries:

- The client needs to actua= lly keep state and the server does not
(that being the point of t= ickets)
- The client (because they speak first) gets to offer the= ticket for
resumption and the server can accept it or reject it.=

-Ekr
=C2=A0

--f46d0435c06af113b0051b408f1a-- From nobody Sun Jul 19 13:58:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882B31B2C45 for ; Sun, 19 Jul 2015 13:58:06 -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 8_4cLVGhW1Or for ; Sun, 19 Jul 2015 13:58:05 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409261B2C44 for ; Sun, 19 Jul 2015 13:58:05 -0700 (PDT) Received: by qgy5 with SMTP id 5so65791850qgy.3 for ; Sun, 19 Jul 2015 13:58:04 -0700 (PDT) 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=d2ec9tKZwx9FL0lApltyra0dXk/rrod8q2eflfkDcHM=; b=wTXoFozF86VNRxz0W9S9v+1q0MwouaUrIDRkw/b58mn/mr4mQ9H+ixR1PFe9hbhXqZ 7gjmr8P7lXwQNsjJjgbNPAXmGf61qFi561Aebc8UjGNTW0lwzBUpu4xpYpJjAJmo3/D6 C6jAXNjXs4oRvSSY9FgP6hBn6TmhqQfzWYn74cY135Pgic/cKuHPSOm8gxvBNukyaBE9 Mnj2hRZ0WRr/+oCdTvtCGadmICpE+lUiaOdyt98OJXDrRGFXooqcW5IV10EXOlfTLqqL dmDVEuq27JjK3fkELBUuZuJkHHMcTeZIaOLgFtbxZgecSeev12TQTOSyQaxkLNkReTeE bD0Q== X-Received: by 10.140.238.76 with SMTP id j73mr2260611qhc.41.1437339484533; Sun, 19 Jul 2015 13:58:04 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id j60sm9748019qge.38.2015.07.19.13.58.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jul 2015 13:58:04 -0700 (PDT) From: Dave Garrett To: Brian Smith Date: Sun, 19 Jul 2015 16:58:02 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507180037.56413.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507191658.02625.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 20:58:06 -0000 On Sunday, July 19, 2015 04:49:10 pm Eric Rescorla wrote: > On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith wrote: > > Great. I was misunderstanding. Here's the part that is not is still not > > clear to me: Is the SessionTicket extension still to be used or not? It > > seems not, AFAICT. If the SessionTicket extension were to be used, then > > everything would work perfectly as Viktor suggested in his message: the > > absense of the SessionTicket extension in the ClientHello would be the way > > that a client can indicate that it doesn't want the session to be cached. > > No, it's not used. This draft spec explicitly obsoletes RFC 5077. (listed up top) https://tools.ietf.org/html/rfc5077#section-3.2 Dave From nobody Sun Jul 19 14:04:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60091B2C8D for ; Sun, 19 Jul 2015 14:03:59 -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 0cagp0eeimLB for ; Sun, 19 Jul 2015 14:03:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B0B1B2C7A for ; Sun, 19 Jul 2015 14:03:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9C03D284B6C; Sun, 19 Jul 2015 21:03:56 +0000 (UTC) Date: Sun, 19 Jul 2015 21:03:56 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150719210356.GQ28047@mournblade.imrryr.org> References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets 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: Sun, 19 Jul 2015 21:03:59 -0000 On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote: > Here's the part that is not is still not > clear to me: Is the SessionTicket extension still to be used or not? While we now have https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 In TLS 1.2 and below, this functionality was provided by "session resumption" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3. at the same time we also have: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11 After the server has received the client Finished message, it MAY send a NewSessionTicket message. This message MUST be sent before the server sends any application data traffic, and is encrypted under the application traffic key. This message creates a pre-shared key (PSK) binding between the resumption master secret and the ticket label. The client MAY use this PSK for future handshakes by including it in the pre_shared_key extension in its ClientHello (Section 6.3.1.5.4) and supplying a suitable PSK cipher suite. struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } NewSessionTicket; ticket_lifetime_hint Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order. A value of zero is reserved to indicate that the lifetime of the ticket is unspecified. ticket The value of the ticket to be used as the PSK identifier. and https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4 The pre_shared_key extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background). opaque psk_identity<0..2^16-1>; struct { select (Role) { case client: psk_identity identities<0..2^16-1>; case server: psk_identity identity; } PreSharedKeyExtension; identifier An opaque label for the pre-shared key. So indeed it is no longer possible for the client to signal the ability/desire to resume sessions, and servers will generate session tickets absent any indication that the client intends to use them. This does not impose a space penalty on the server, but some CPU and bandwidth may be wasted on clients that don't or can't resume. > It seems not, AFAICT. If the SessionTicket extension were to be used, then > everything would work perfectly as Viktor suggested in his message: the > absense of the SessionTicket extension in the ClientHello would be the way > that a client can indicate that it doesn't want the session to be cached. In the current 1.3 draft, there is indeed no client signal. > It seems weird that the server can supply a lifetime hint but the client > can't, especially in cases like WebRTC where there is no functional > difference between the two. But, that's a smaller issue than the lack of > an indication that resumption machinery isn't wanted at all. The client lifetime is not that useful with session tickets anyway, whether the client caches at all, could be, but it is not clear that the resulting "inefficiency" needs to be fixed. The fix would be for the client to send an empty extension of some sort to signal its desire to elicit a session ticket. -- Viktor. From nobody Sun Jul 19 14:08:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0070D1B2CC0 for ; Sun, 19 Jul 2015 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 eWuG93s8MXS7 for ; Sun, 19 Jul 2015 14:08:52 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1443D1B2C8A for ; Sun, 19 Jul 2015 14:08:52 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id CAA80508072 for ; Sun, 19 Jul 2015 14:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=5/YEbDDuJeDapvVSXl8/2re8iLk=; b=MPfcNOnlW7OdN XRdNt2jcDUqtIV+TeClWE7fvb3e+g9FKS6CDxgbyuMa/TJA0+rna2/HL1ZpNISJl 2BjM128JB43qd39CN7yq8VGKFrAMuf7xOZf/S4BScKco80MWppWs4baWBwPaeufS xjTfi9VeU1xK+BVWam6jVc/krRQlwk= Received: from spandex.local (74-124-99-152-rb2.sol.dsl.dynamic.acsalaska.net [74.124.99.152]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 784A3508064 for ; Sun, 19 Jul 2015 14:08:51 -0700 (PDT) Message-ID: <55AC11DE.5070508@nomountain.net> Date: Sun, 19 Jul 2015 13:08:46 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <55922571.8080605@nomountain.net> <20150701035820.GJ14121@mournblade.imrryr.org> <87k2twm2ol.fsf@alice.fifthhorseman.net> <20150719194943.GO28047@mournblade.imrryr.org> In-Reply-To: <20150719194943.GO28047@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-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: Sun, 19 Jul 2015 21:08:53 -0000 On 7/19/15 11:49 AM, Viktor Dukhovni wrote: > My reading of the draft is that it is primary aimed at making DANE > practical for HTTPS, where last-mile considerations on the client > end are a significant part of the adoption barrier. > > For HTTP, MX and SRV records are out of scope. Clients that depend > on DNS to the extent of determining the server identity based on > MX or SRV records, already need DNSSEC to avoid MiTM issues, and > at least in the case of SMTP and XMPP are expected to handle DANE > without stapled TLSA RRsets (and associated RRSIG/DNSKEY/DS chains). Yup, exactly. Thanks. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Sun Jul 19 14:09:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5562F1B2CC1 for ; Sun, 19 Jul 2015 14:09:49 -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 ZCYHsy7bEyxD for ; Sun, 19 Jul 2015 14:09:48 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EBD1B2CC0 for ; Sun, 19 Jul 2015 14:09:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 38BDB284B6C; Sun, 19 Jul 2015 21:09:41 +0000 (UTC) Date: Sun, 19 Jul 2015 21:09:41 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150719210940.GR28047@mournblade.imrryr.org> References: <201507180037.56413.davemgarrett@gmail.com> <201507191658.02625.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507191658.02625.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets 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: Sun, 19 Jul 2015 21:09:49 -0000 On Sun, Jul 19, 2015 at 04:58:02PM -0400, Dave Garrett wrote: > This draft spec explicitly obsoletes RFC 5077. (listed up top) > https://tools.ietf.org/html/rfc5077#section-3.2 However, part of RFC 5077 remains applicable: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11 The ticket itself is an opaque label. It MAY either be a database lookup key or a self-encrypted and self-authenticated value. Section 4 of [RFC5077] describes a recommended ticket construction mechanism. -- Viktor. From nobody Sun Jul 19 14:11:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79EE1B2CC9 for ; Sun, 19 Jul 2015 14:11:25 -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 0STtwrrwSdB7 for ; Sun, 19 Jul 2015 14:11:23 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1851B2CC0 for ; Sun, 19 Jul 2015 14:11:23 -0700 (PDT) Received: by wgkl9 with SMTP id l9so117212303wgk.1 for ; Sun, 19 Jul 2015 14:11: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=cnMClM/iQQQYSrmlJr+ZwpJNaU0PtQWv4sOyp2t9s5M=; b=HeGaAKQ3w1Ga1lAkhdo5j172Chyi9a4uWBHoEPh2c9n+J0zm+pVrvxKkbqDq9pTJ5A iSnlZa0nXw73Q2S1ZQ5ZMb4YGRIMTGVhoxhQzV8M4h63PzB2SsTKe5y62IuWSGneBs6b WMrAez13x8fqafUeekd3+vCEpKVPpYFBDm+R84acZkbBRsiKTNt3wUJPigwHStnOz6qw whlPniMxp1ONC4Dl5EnWHjNBBIoVPa/EgW5Ie8cRjNmE4Kd9EJGj+9Z3xQ6Sr6pwTH3I XwhNrYPZkYIVr8FYVdIRxwkS8JaqbgRYDT0NCYd6KTfGj0FUdR9RG4B8mQNFjjICVeqy 4A5Q== X-Gm-Message-State: ALoCoQmSxFug8Cls3CDNyuxvrzcEiea1VtNypHCDtdy91yeuQCdvRzv+u15eI/X+AmheLn3LgiA8 X-Received: by 10.180.87.168 with SMTP id az8mr15774934wib.53.1437340281925; Sun, 19 Jul 2015 14:11:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 14:10:42 -0700 (PDT) In-Reply-To: <20150719210356.GQ28047@mournblade.imrryr.org> References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> <20150719210356.GQ28047@mournblade.imrryr.org> From: Eric Rescorla Date: Sun, 19 Jul 2015 23:10:42 +0200 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba181b82ed0f17051b40dc10 Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 21:11:26 -0000 --90e6ba181b82ed0f17051b40dc10 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 11:03 PM, Viktor Dukhovni wrote: > On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote: > > > Here's the part that is not is still not > > clear to me: Is the SessionTicket extension still to be used or not? > > While we now have > > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 > > In TLS 1.2 and below, this functionality was provided by "session > resumption" and "session tickets" [RFC5077]. Both mechanisms are > obsoleted in TLS 1.3. > > at the same time we also have: > > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11 > > After the server has received the client Finished message, it MAY > send a NewSessionTicket message. This message MUST be sent before > the server sends any application data traffic, and is encrypted > under > the application traffic key. This message creates a pre-shared key > (PSK) binding between the resumption master secret and the ticket > label. The client MAY use this PSK for future handshakes by > including it in the pre_shared_key extension in its ClientHello > (Section 6.3.1.5.4) and supplying a suitable PSK cipher suite. > > struct { > uint32 ticket_lifetime_hint; > opaque ticket<0..2^16-1>; > } NewSessionTicket; > > ticket_lifetime_hint > Indicates the lifetime in seconds as a 32-bit unsigned integer in > network byte order. A value of zero is reserved to indicate that > the lifetime of the ticket is unspecified. > > ticket > The value of the ticket to be used as the PSK identifier. > > and > > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4 > > The pre_shared_key extension is used to indicate the identity of the > pre-shared key to be used with a given handshake in association with > a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background). > > opaque psk_identity<0..2^16-1>; > > struct { > select (Role) { > case client: > psk_identity identities<0..2^16-1>; > > case server: > psk_identity identity; > > } PreSharedKeyExtension; > > identifier > An opaque label for the pre-shared key. > > So indeed it is no longer possible for the client to signal the > ability/desire to resume sessions, and servers will generate session > tickets absent any indication that the client intends to use them. > > This does not impose a space penalty on the server, but some CPU > and bandwidth may be wasted on clients that don't or can't resume. Yes. So my question is whether there are an appreciably large number of servers each of which have an appreciably large fraction of *both* caching and non-caching clients to make an optimization like this worthwhile (servers which only have non-caching or only caching clients can just send or not send a ticket as appropriate) -Ekr > > > It seems not, AFAICT. If the SessionTicket extension were to be used, > then > > everything would work perfectly as Viktor suggested in his message: the > > absense of the SessionTicket extension in the ClientHello would be the > way > > that a client can indicate that it doesn't want the session to be cached. > > In the current 1.3 draft, there is indeed no client signal. > > > It seems weird that the server can supply a lifetime hint but the client > > can't, especially in cases like WebRTC where there is no functional > > difference between the two. But, that's a smaller issue than the lack of > > an indication that resumption machinery isn't wanted at all. > > The client lifetime is not that useful with session tickets anyway, > whether the client caches at all, could be, but it is not clear > that the resulting "inefficiency" needs to be fixed. The fix would > be for the client to send an empty extension of some sort to signal > its desire to elicit a session ticket. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --90e6ba181b82ed0f17051b40dc10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 19, 2015 at 11:03 PM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:

> Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not?
While we now have

=C2=A0 =C2=A0https://tools.ietf.org= /html/draft-ietf-tls-tls13-07#section-6.2.4

=C2=A0 =C2=A0 =C2=A0 =C2=A0In TLS 1.2 and below, this functionality was pro= vided by "session
=C2=A0 =C2=A0 =C2=A0 =C2=A0resumption" and "session tickets"= [RFC5077].=C2=A0 Both mechanisms are
=C2=A0 =C2=A0 =C2=A0 =C2=A0obsoleted in TLS 1.3.

at the same time we also have:

=C2=A0 =C2=A0https://tools.ietf.or= g/html/draft-ietf-tls-tls13-07#section-6.3.11

=C2=A0 =C2=A0 =C2=A0 =C2=A0After the server has received the client Finishe= d message, it MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0send a NewSessionTicket message.=C2=A0 This mess= age MUST be sent before
=C2=A0 =C2=A0 =C2=A0 =C2=A0the server sends any application data traffic, a= nd is encrypted under
=C2=A0 =C2=A0 =C2=A0 =C2=A0the application traffic key.=C2=A0 This message = creates a pre-shared key
=C2=A0 =C2=A0 =C2=A0 =C2=A0(PSK) binding between the resumption master secr= et and the ticket
=C2=A0 =C2=A0 =C2=A0 =C2=A0label.=C2=A0 The client MAY use this PSK for fut= ure handshakes by
=C2=A0 =C2=A0 =C2=A0 =C2=A0including it in the pre_shared_key extension in = its ClientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0(Section 6.3.1.5.4) and supplying a suitable PSK= cipher suite.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32 ticket_lifetime_hint= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque ticket<0..2^16-1&= gt;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} NewSessionTicket;

=C2=A0 =C2=A0 =C2=A0 =C2=A0ticket_lifetime_hint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indicates the lifetime in seconds as a 3= 2-bit unsigned integer in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network byte order.=C2=A0 A value of zer= o is reserved to indicate that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the lifetime of the ticket is unspecifie= d.

=C2=A0 =C2=A0 =C2=A0 =C2=A0ticket
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The value of the ticket to be used as th= e PSK identifier.

and

=C2=A0 =C2=A0https://tools.ietf= .org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4

=C2=A0 =C2=A0 =C2=A0 =C2=A0The pre_shared_key extension is used to indicate= the identity of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0pre-shared key to be used with a given handshake= in association with
=C2=A0 =C2=A0 =C2=A0 =C2=A0a PSK or (EC)DHE-PSK cipher suite (see [RFC4279]= for background).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque psk_identity<0..2^16-1>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Role) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client:<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0psk_id= entity identities<0..2^16-1>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case server:<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0psk_id= entity identity;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} PreSharedKeyExtension;
=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An opaque label for the pre-shared key.<= br>
So indeed it is no longer possible for the client to signal the
ability/desire to resume sessions, and servers will generate session
tickets absent any indication that the client intends to use them.

This does not impose a space penalty on the server, but some CPU
and bandwidth may be wasted on clients that don't or can't resume.<= /blockquote>

Yes.

So my questio= n is whether there are an appreciably large number of servers
eac= h of which have an appreciably large fraction of *both* caching and
non-caching clients to make an optimization like this worthwhile (server= s
which only have non-caching or only caching clients can just se= nd
or not send a ticket as appropriate)

= -Ekr
=C2=A0
=
> It seems not, AFAICT. If the SessionTicket extension were to be used, = then
> everything would work perfectly as Viktor suggested in his message: th= e
> absense of the SessionTicket extension in the ClientHello would be the= way
> that a client can indicate that it doesn't want the session to be = cached.

In the current 1.3 draft, there is indeed no client signal.

> It seems weird that the server can supply a lifetime hint but the clie= nt
> can't, especially in cases like WebRTC where there is no functiona= l
> difference between the two. But, that's a smaller issue than the l= ack of
> an indication that resumption machinery isn't wanted at all.

The client lifetime is not that useful with session tickets anyway,<= br> whether the client caches at all, could be, but it is not clear
that the resulting "inefficiency" needs to be fixed.=C2=A0 The fi= x would
be for the client to send an empty extension of some sort to signal
its desire to elicit a session ticket.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--90e6ba181b82ed0f17051b40dc10-- From nobody Sun Jul 19 14:14:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABFA1B2CE3 for ; Sun, 19 Jul 2015 14:14:17 -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 eHmYRjUxHmtt for ; Sun, 19 Jul 2015 14:14:17 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17531B2CEA for ; Sun, 19 Jul 2015 14:14:16 -0700 (PDT) Received: by qged69 with SMTP id d69so36532813qge.0 for ; Sun, 19 Jul 2015 14:14:16 -0700 (PDT) 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=4eS7WLJYdqzrXjKAFVcEjXUSiOn3AhoDJ+14ALTXeE0=; b=VhxGLt3vqnhlncLlIWq8Zt/TrwnLZchwb7sOMgRZFTJuSSJ7Odjj34rA5mPSsI3eHt H5LyweCNrp4Bkdt85sR1ixqezLvwV1Kvw2su8kxsOiA/hIoS+3VZQqjh+eebLSPGRCLo Jb6GU3sEQ6A9+81k/CfwvwjCGI0Sm+owJf3ai/YBy/dFMl8sv54op7xRfFr4709+HULk CzxbYjPxDYWRAZjWhuESbao5PNhYOnfAIqWgnDOltRgbVNQdgv8PJ491Pjs/17msno82 6zyJR/YZLV0WpO78rPO+qXkhlDZUW6eXSYkkZk4Yt+ltdiOVhCVv0bwyKsOJK50oHk1j yzhw== X-Received: by 10.140.41.9 with SMTP id y9mr41175877qgy.28.1437340456208; Sun, 19 Jul 2015 14:14:16 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id z76sm9776387qge.22.2015.07.19.14.14.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jul 2015 14:14:15 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Sun, 19 Jul 2015 17:14:14 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507180037.56413.davemgarrett@gmail.com> <20150719210356.GQ28047@mournblade.imrryr.org> In-Reply-To: <20150719210356.GQ28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507191714.14645.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 21:14:18 -0000 On Sunday, July 19, 2015 05:03:56 pm Viktor Dukhovni wrote: > In the current 1.3 draft, there is indeed no client signal. [...] > The fix would be for the client to send an empty extension of some > sort to signal its desire to elicit a session ticket. Why is the SessionTicket TLS Extension being deprecated at all? Sure, obsolete the RFC, but include the same extension in the TLS 1.3 spec with the same semantics for requesting a ticket from the server (0-length to request). This could be backwards compatible easily enough. Dave From nobody Sun Jul 19 14:28:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430D81B2D76 for ; Sun, 19 Jul 2015 14:28:30 -0700 (PDT) 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 lmjBieRCpzr8 for ; Sun, 19 Jul 2015 14:28:28 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6411B2D72 for ; Sun, 19 Jul 2015 14:28:28 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so92054002obb.0 for ; Sun, 19 Jul 2015 14:28:28 -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:date :message-id:subject:from:to:cc:content-type; bh=4cpsWGgZisojq6nOvpkQ/PAQa5zooRUTIZNg+2DRGF8=; b=JTZ3rHU8dGaky65zLGtW78Gko498+RjW3ze7uPtABl6FmRMbRFXOT6fox6znVFt7v8 6SIkTpUXkOvLdLvPSDwJ3lCwdMf+tuZsKqOwEnAqOR4lbC1ShBpEEVZwJKWy0pnU+hhy F1B9MNVn+99C3RO5EhI0WL+89aX811DXcR3VTFhV4QneH4XGCORIPwgr1/K5yvc2XtiC YLv9B7g6VHBBF35H9zYmJaz6AkzFCVUp1n2t1XzM2URag4bk6F+TEr1zLQR96tpmA6rO fljTpAN4GJGu5b58fjuLt5StHcYrAVf3txGiClRr/zl4JBUCZOrqU60sj0A/wBehSjA8 hzLw== X-Gm-Message-State: ALoCoQlJmoIhm8S62EeNUFvmfXpbX/g2lJ10RfVPX4dodvFzldGr57ot7/oPY1puZDjW1VVm+MRg MIME-Version: 1.0 X-Received: by 10.202.210.68 with SMTP id j65mr21878914oig.68.1437341308071; Sun, 19 Jul 2015 14:28:28 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Sun, 19 Jul 2015 14:28:27 -0700 (PDT) In-Reply-To: References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> Date: Sun, 19 Jul 2015 17:28:27 -0400 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d2b3816c6ba051b411a51 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 21:28:30 -0000 --001a113d2b3816c6ba051b411a51 Content-Type: text/plain; charset=UTF-8 Eric Rescorla wrote: > On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith > wrote: > >> It seems weird that the server can supply a lifetime hint but the client >> can't, especially in cases like WebRTC where there is no functional >> difference between the two. But, that's a smaller issue than the lack of an >> indication that resumption machinery isn't wanted at all. >> > > I don't think it's *that* odd, since tickets have at least two fundamental > asymmetries: > > - The client needs to actually keep state and the server does not > (that being the point of tickets) > It depends on how the server implements tickets. The server could implement tickets the same way that it implements session ID-based resumption. That's not a good idea, but I don't think the spec should prohibit that type of implementation either since it unenforceable. Thus, because of that possibility, it is valuable to have the client be able to say "don't cache the session" and/or limit the session's lifetime, so the client can help direct the level of forward secrecy for the session. Right now, only the server has a say in how long a session will be forward-secret. Note also that the NewSessionTicket extension precedes any application data, so without a way to prevent an unwanted NewSessionTicket message from being sent, the client has to waste effort and time to consume the NewSessionTicket before it can do anything useful. Anyway, I don't understand why you keep directing your question to server vendors. The people that would be interested in such a feature are client software vendors, for client software that wants to control the level of forward secrecy for a session. Cheers, Brian --001a113d2b3816c6ba051b411a51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric= Rescorla <ekr@rtfm.com> wrote:
= On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <brian@briansmith.org= > wrote:
It seems weird that the server can = supply a lifetime hint but the client can't, especially in cases like W= ebRTC where there is no functional difference between the two. But, that= 9;s a smaller issue than the lack of an indication that resumption machiner= y isn't wanted at all.
<= span class=3D"">

I don't think it's *that= * odd, since tickets have at least two fundamental
asymmetries:

- The client needs to actually keep state and the s= erver does not
(that being the point of tickets)

It depends on how the server implem= ents tickets. The server could implement tickets the same way that it imple= ments session ID-based resumption. That's not a good idea, but I don= 9;t think the spec should prohibit that type of implementation either since= it unenforceable. Thus, because of that possibility, it is valuable to hav= e the client be able to say "don't cache the session" and/or = limit the session's lifetime, so the client can help direct the level o= f forward secrecy for the session. Right now, only the server has a say in = how long a session will be forward-secret.

Note al= so that the NewSessionTicket extension precedes any application data, so wi= thout a way to prevent an unwanted NewSessionTicket message from being sent= , the client has to waste effort and time to consume the NewSessionTicket b= efore it can do anything useful.

Anyway, I don'= ;t understand why you keep directing your question to server vendors. The p= eople that would be interested in such a feature are client software vendor= s, for client software that wants to control the level of forward secrecy f= or a session.

Cheers,
Brian
--001a113d2b3816c6ba051b411a51-- From nobody Sun Jul 19 14:35:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A361B2D8A for ; Sun, 19 Jul 2015 14:35:23 -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 i5wCkp-rdyGJ for ; Sun, 19 Jul 2015 14:35:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1431B2D8B for ; Sun, 19 Jul 2015 14:35:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D8799284B6C; Sun, 19 Jul 2015 21:35:20 +0000 (UTC) Date: Sun, 19 Jul 2015 21:35:20 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150719213520.GT28047@mournblade.imrryr.org> References: <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> <20150719210356.GQ28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets 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: Sun, 19 Jul 2015 21:35:23 -0000 On Sun, Jul 19, 2015 at 11:10:42PM +0200, Eric Rescorla wrote: > > So indeed it is no longer possible for the client to signal the > > ability/desire to resume sessions, and servers will generate session > > tickets absent any indication that the client intends to use them. > > > > This does not impose a space penalty on the server, but some CPU > > and bandwidth may be wasted on clients that don't or can't resume. > > Yes. > > So my question is whether there are an appreciably large number of servers > each of which have an appreciably large fraction of *both* caching and > non-caching clients to make an optimization like this worthwhile (servers > which only have non-caching or only caching clients can just send > or not send a ticket as appropriate) Such a mixture of clients is not at all uncommon with SMTP. Not all MTAs implement client-side TLS session caches (no such cache in Exim or Sendmail). However, sending a session ticket either way is not a major burden for SMTP servers. It would however be nice to not waste resources doing so, if an appropriate extension (say the existing one) were used to signal client support. This is not an absolutely compelling argument in favour of client signalling, more of an observation that it could be useful. -- Viktor. From nobody Sun Jul 19 14:43:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50591B2D95 for ; Sun, 19 Jul 2015 14:42:59 -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 UJhiCIPNG7Mf for ; Sun, 19 Jul 2015 14:42:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CAD1B2D86 for ; Sun, 19 Jul 2015 14:42:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EFA60284B6C; Sun, 19 Jul 2015 21:42:57 +0000 (UTC) Date: Sun, 19 Jul 2015 21:42:57 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150719214257.GU28047@mournblade.imrryr.org> References: <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets 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: Sun, 19 Jul 2015 21:43:00 -0000 On Sun, Jul 19, 2015 at 05:28:27PM -0400, Brian Smith wrote: > Thus, because of that > possibility, it is valuable to have the client be able to say "don't cache > the session" and/or limit the session's lifetime, so the client can help > direct the level of forward secrecy for the session. Right now, only the > server has a say in how long a session will be forward-secret. I think this is too much complexity, for too little gain. Servers will limit the lifetime of local session storage rather severely to avoid running out of space. > Note also that the NewSessionTicket extension precedes any application > data, so without a way to prevent an unwanted NewSessionTicket message from > being sent, the client has to waste effort and time to consume the > NewSessionTicket before it can do anything useful. This is typically much smaller than the server certificate chain, so the cost saving is marginal. > Anyway, I don't understand why you keep directing your question to server > vendors. The people that would be interested in such a feature are client > software vendors, for client software that wants to control the level of > forward secrecy for a session. I don't think the client would gain much if any control by signalling a lifetime hint. With actual session tickets, the key rotation lifecycle determines the effective forward-secrecy exposure (to server state compromise before a key is retired) of the ticket, and no client hint can influence that in any way. So I agree with Eric that the issue is fundamentally a server-side issue, modulo the fact that the CPU and bandwidth cost of processing the unwanted ticket is borne on both sides. -- Viktor. From nobody Sun Jul 19 15:13:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2CC1B2DC1 for ; Sun, 19 Jul 2015 15:12:59 -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 N6rAbWDDtaRL for ; Sun, 19 Jul 2015 15:12:57 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EDA11B2DC0 for ; Sun, 19 Jul 2015 15:12:57 -0700 (PDT) Received: by qgeu79 with SMTP id u79so10387157qge.1 for ; Sun, 19 Jul 2015 15:12:56 -0700 (PDT) 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=hLq8oE9zfyaj6yotyHQ4Ap94gUS/6ceUh7W6Y4ap3BU=; b=TuW/9uNBPVJAFpyKsJfIthJC3hb22eGsRDDKVmHC7t1bGAiJxK3nXax4YV77UYJfOU sV3TrmDDYEyGbjBxj5KYxpvLGmCvy9AGySerDxW4pkMEudehnmAV7n5As3oku6OsP2oq 4ju9ZA5TUKmhVgBHcwQf5iS9PA+gdUA0RH7WY5iCsTZP4Ncpn32sNaYdSrMIb8ck4H4j pLIal/LKLaJo6cUeCqi5yMquGubjMdxwt7sfBdVKD/rAZNLtI4LSr32LKieZ0tnzljkb bEBVeorwJnC13m2AzxcI7v2XYoJrrUI3KCT9N/fVTSi87t0GtxFSH3wHp55PEroA1J3b Ykkg== X-Received: by 10.140.33.21 with SMTP id i21mr41406500qgi.4.1437343976697; Sun, 19 Jul 2015 15:12:56 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id z76sm9852587qge.22.2015.07.19.15.12.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jul 2015 15:12:56 -0700 (PDT) From: Dave Garrett To: Brian Smith , Eric Rescorla Date: Sun, 19 Jul 2015 18:12:54 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507180037.56413.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507191812.55108.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2015 22:12:59 -0000 On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote: > It depends on how the server implements tickets. The server could implement > tickets the same way that it implements session ID-based resumption. That's > not a good idea, but I don't think the spec should prohibit that type of > implementation either since it unenforceable. Thus, because of that > possibility, it is valuable to have the client be able to say "don't cache > the session" and/or limit the session's lifetime, so the client can help > direct the level of forward secrecy for the session. Right now, only the > server has a say in how long a session will be forward-secret. > > Note also that the NewSessionTicket extension precedes any application > data, so without a way to prevent an unwanted NewSessionTicket message from > being sent, the client has to waste effort and time to consume the > NewSessionTicket before it can do anything useful. If the general ticket lifetime request route is not needed, here's the simplest route: just don't drop the Session Ticket extension. https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension This keeps it with the same semantics for requesting a ticket, thus allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 servers with no additional effort. TLS 1.3 sessions would be resumed using the new PSK-based method and TLS 1.2 sessions would be resumed using the old session ticket extension. Should I submit this as a PR? It seems like the obvious route if all we want is to just keep the ability for a client to not request a ticket. No need to write a new extension at all. Dave From nobody Sun Jul 19 21:20:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B350A1B2F65 for ; Sun, 19 Jul 2015 21:20:27 -0700 (PDT) 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_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, 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 DzOXMgPdSARd for ; Sun, 19 Jul 2015 21:20:26 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id C43211B2F51 for ; Sun, 19 Jul 2015 21:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1437366023; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=NjXZeny5oUiXvjTmqpnXbfqSvXaNWU7hsktsR/U4+lA=; b=Unz/GdJZq1JH8LZLAN1I7XwZM1MGyiAQ9LLtJqjbkfS+1ipqe2qm0TDJQ1tx17LSD9cav7uHc2fEXWLuw/bCCHJBRvE29XZ8nGuqJotUjRipuG9uGBShG/6l7nRI54FzOfgaZ+NQLIjZBSLxtbKn8DWy4DU8PQyfr5eN4sYGj6c= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R561e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03282; MF=bingzheng.wbz@alibaba-inc.com; NM=1; PH=DW; RN=1; SR=0; Received: from WS-web (bingzheng.wbz@alibaba-inc.com[42.120.75.4]) by e02c03312.eu6 at Mon, 20 Jul 2015 12:20:21 +0800 Date: Mon, 20 Jul 2015 12:20:21 +0800 From: "Bingzheng Wu" To: "tls" Message-ID: <----3-------MPf3-$01951b4c-26a0-42fa-aeb1-dfa6894711a8@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2700061 MIME-Version: 1.0 x-aliyun-mail-creator: W4_2700516_hLSTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQzLjAuMjM1Ny4xMzQgU2FmYXJpLzUzNy4zNg==2I Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] =?utf-8?q?Another_way_to_reduce_signature_computational_cos?= =?utf-8?q?t?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 20 Jul 2015 04:20:27 -0000 Hi all,=0A=0AIn TLS 1.3 draft-07, server provides a ServerConfiguration messag= e containing a long-term DH share.=0AIf used on future connections:=0A=0A(1) s= erver reduces the computational cost for cipher suites where signatures are sl= ower than key agreement;=0A(2) server omits both the Certificate or Certificat= eVerify message;=0A(3) and client encrypts zero-rtt data.=0A=0A=0AHere I'd lik= e to give another way to reach (1), to reduce server's computational=0Acost fo= r CertificateVerify message for RSA type certificate.=0A=0AIn normal way, the = CertificateVerify is computed as:=0A CA =3D=3D> CA2 =3D=3D> srv_cert_RSA --= > session=0Awhere "=3D=3D>" means reusing signature, and "-->" means signature= for each session which is computation sensitive.=0A=0AMaybe the server can ge= nerate a temparary ECC certificate, so the CertificateVerify is computed as:=0A= CA =3D=3D> CA2 =3D=3D> srv_cert_RSA =3D=3D> tmp_cert_ECC --> session=0Aand= the structure of CertificateVerify message becomes:=0A=0A struct {=0A = ECParam tmp_cert_public;=0A time tmp_cert_not_before;=0A = time tmp_cert_not_after;=0A digitally-signed struct {=0A= opaque handshake_hash[hash_length];=0A }=0A } Cer= tificateVerify;=0A=0A=0ACompared to ServerConfiguration, this tmp_cert_ECC has= some advantages:=0A=0A* The tmp_cert only modify the CertificateVerify messag= e.=0A While the ServerConfiguration brings MS and SS concepts.=0A=0A* The tmp= _cert need not to be global.=0A If there are multiple machines or processes b= ehind one service,=0A they must synchronize the key share for ServerConfigura= tion.=0A In practice the key share is always configured in server's configure= =0A file and need rotated periodically manually, like the ticket key in Nginx= .=0A While the tmp_cert can be generated randomly and independently.=0A=0A* T= he tmp_cert's lifetime could be short.=0A It could be re-new after used for o= nly 100 times, or 10 minutes.=0A=0A* The tmp_cert works even for the first con= nection.=0A=0A=0ASo could we use this tmp_cert to replace ServerConfiguration'= s "reducing computation" function?=0A=0AThe "omitting Certificate message" cou= ld be reached by cached-info extension.=0AThen the ServerConfiguration can be = used for zero-rtt data exclusively.=0A=0A=0AThanks=0ABingzheng From nobody Sun Jul 19 21:28:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546E41B2F86 for ; Sun, 19 Jul 2015 21:28:29 -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 pXNfQwVhc9Mx for ; Sun, 19 Jul 2015 21:28:27 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059D51B2F87 for ; Sun, 19 Jul 2015 21:28:23 -0700 (PDT) Received: by wgmn9 with SMTP id n9so121118761wgm.0 for ; Sun, 19 Jul 2015 21:28:21 -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=Fl9aDpZc51XtXdewEKh4gJbWak32HlAgYr12wzRgjPM=; b=GIfGitiV7iTzSOtc0IZSFFLunVaOODZJfmqCLNvoQ3SNAZnv4n+5HJ0uh4OAKR2J4s 07GS7T3RaMX/Yfbhf+NAcXEoJYXwj1s45Thl/fvWZVz4ls0qK5VFbBjEZmwTg3yVd4mV 6vNQzxG13fDVWRk/h6SVik1cyNvIXWcVxlgnR1abeiwjAKibbm88cDmZNIsLO70LFvrP 8nD/TYGCqKrq4wpawChhwtU27A/Bq72uiSz8d+96i13ZEIZk5v9ijqa68Q8SqRdRWlKM PHnU+l8R8z8nPtoS1D56d7H0Ia40wysbC4BBHc8fhcyjhWEWqLvskOlZRN25u5Dt8f++ Ve3Q== X-Gm-Message-State: ALoCoQn4eOPloUP5GWaph4RWc+FvsVKGj4WUQh7CKe+VlWxY92Tz8uqHu9ZyjyRHjCngodBlDqXH X-Received: by 10.194.158.42 with SMTP id wr10mr51231628wjb.81.1437366501638; Sun, 19 Jul 2015 21:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 21:27:42 -0700 (PDT) In-Reply-To: References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> From: Eric Rescorla Date: Mon, 20 Jul 2015 06:27:42 +0200 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=089e013c6478be1faf051b46f72e Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 04:28:29 -0000 --089e013c6478be1faf051b46f72e Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith wrote: > Eric Rescorla wrote: > >> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith >> wrote: >> >>> It seems weird that the server can supply a lifetime hint but the client >>> can't, especially in cases like WebRTC where there is no functional >>> difference between the two. But, that's a smaller issue than the lack of an >>> indication that resumption machinery isn't wanted at all. >>> >> >> I don't think it's *that* odd, since tickets have at least two fundamental >> asymmetries: >> >> - The client needs to actually keep state and the server does not >> (that being the point of tickets) >> > > It depends on how the server implements tickets. The server could > implement tickets the same way that it implements session ID-based > resumption. That's not a good idea, but I don't think the spec should > prohibit that type of implementation either since it unenforceable. > I don't think that the current spec does so. > Thus, because of that possibility, it is valuable to have the client be > able to say "don't cache the session" and/or limit the session's lifetime, > so the client can help direct the level of forward secrecy for the session. > Right now, only the server has a say in how long a session will be > forward-secret. > > Note also that the NewSessionTicket extension precedes any application > data, so without a way to prevent an unwanted NewSessionTicket message from > being sent, the client has to waste effort and time to consume the > NewSessionTicket before it can do anything useful. > > Anyway, I don't understand why you keep directing your question to server > vendors. The people that would be interested in such a feature are client > software vendors, for client software that wants to control the level of > forward secrecy for a session. > I think perhaps you have misunderstood the forward secrecy properties of the current draft. Unlike TLS 1.2 and previous, the current draft has a separate resumption master secret which is independently derived from the master secret used for the connection keys in the original connection. This means that if you don't resume the connection, you have forward secrecy for the original connection regardless of whether the server stores the session in the session cache or sends the client a ticket. -Ekr --089e013c6478be1faf051b46f72e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith <brian@briansmith.org= > wrote:
<= div class=3D"gmail_extra">
Eric = Rescorla <ekr@rtfm.com> wrote:
On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <brian@brians= mith.org> wrote:
=
It seems weird that the server can supply a lifetime hint but the client c= an't, especially in cases like WebRTC where there is no functional diff= erence between the two. But, that's a smaller issue than the lack of an= indication that resumption machinery isn't wanted at all.

<= /div>
I don't think it's *that* odd, since tickets have = at least two fundamental
asymmetries:

- = The client needs to actually keep state and the server does not
(= that being the point of tickets)

It depends on how the server implements tickets. The s= erver could implement tickets the same way that it implements session ID-ba= sed resumption. That's not a good idea, but I don't think the spec = should prohibit that type of implementation either since it unenforceable.<= /div>

I don't think t= hat the current spec does so.

=C2=A0
Thus, because of that possibility, it is valuable = to have the client be able to say "don't cache the session" a= nd/or limit the session's lifetime, so the client can help direct the l= evel of forward secrecy for the session. Right now, only the server has a s= ay in how long a session will be forward-secret.

N= ote also that the NewSessionTicket extension precedes any application data,= so without a way to prevent an unwanted NewSessionTicket message from bein= g sent, the client has to waste effort and time to consume the NewSessionTi= cket before it can do anything useful.

Anyway, I d= on't understand why you keep directing your question to server vendors.= The people that would be interested in such a feature are client software = vendors, for client software that wants to control the level of forward sec= recy for a session.

I think perhaps you have misunderstood the forward secrecy properties of t= he
current draft. Unlike TLS 1.2 and previous, the current draft = has a separate
resumption master secret which is independentl= y derived from the master
secret used for the connection keys in = the original connection. This means
that if you don't resume = the connection, you have forward secrecy for the
original connect= ion regardless of whether the server stores the session in
the se= ssion cache or sends the client a ticket.

-Ekr


--089e013c6478be1faf051b46f72e-- From nobody Sun Jul 19 21:28:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79EF1B2F80 for ; Sun, 19 Jul 2015 21:28:40 -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 umV-LWW2PZq4 for ; Sun, 19 Jul 2015 21:28:31 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826A11B2F83 for ; Sun, 19 Jul 2015 21:28:27 -0700 (PDT) Received: by wibud3 with SMTP id ud3so85869730wib.0 for ; Sun, 19 Jul 2015 21:28:26 -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=No0lepCbA2Evr3ca9bBy8JpeZmnWPiXgoTNBuPcVZMY=; b=RiKlyOIPMvUAyHH+uPFwZSnwr639G7mNu4S0932vtMUzfnOzHyydOli4SRq+128kcO 1roLAeXEmYKvEtw1mquPTmfExCQ6cB17IpQc7D5UuFgmaX6zZCfazD2QNM7EVjbeXCm7 gP+7ajAjJ55xLQqzxCQHuS3UP21zbbby1kQgiIFh+vrOq55f9ScXZ/zux7V6teW6YtbB Y/0FSbEs8LzFq2VurQFBE2d/9xfTS8EgbTsUaM3H9c6pbHGeogLOjVB4aKQVBb1E1J/j lPIZHBBeJr1BiGcj3T/0x01I1XV9rS50pmzCES0/AackUF8jtWF/rghuwhadogJr7Bvd f6Ug== X-Gm-Message-State: ALoCoQmwclBjLmu8oNDtyWBQy5rmZN9fQ/5JqBvQIXaRf/c1eiK+Db276EmFyNeipvcEcVu4+6bU X-Received: by 10.194.79.225 with SMTP id m1mr53301656wjx.8.1437366506254; Sun, 19 Jul 2015 21:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 21:27:46 -0700 (PDT) In-Reply-To: <201507191812.55108.davemgarrett@gmail.com> References: <201507180037.56413.davemgarrett@gmail.com> <201507191812.55108.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 20 Jul 2015 06:27:46 +0200 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b10c9030488ab051b46f86c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 04:28:41 -0000 --047d7b10c9030488ab051b46f86c Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett wrote: > On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote: > > It depends on how the server implements tickets. The server could > implement > > tickets the same way that it implements session ID-based resumption. > That's > > not a good idea, but I don't think the spec should prohibit that type of > > implementation either since it unenforceable. Thus, because of that > > possibility, it is valuable to have the client be able to say "don't > cache > > the session" and/or limit the session's lifetime, so the client can help > > direct the level of forward secrecy for the session. Right now, only the > > server has a say in how long a session will be forward-secret. > > > > Note also that the NewSessionTicket extension precedes any application > > data, so without a way to prevent an unwanted NewSessionTicket message > from > > being sent, the client has to waste effort and time to consume the > > NewSessionTicket before it can do anything useful. > > If the general ticket lifetime request route is not needed, here's the > simplest route: just don't drop the Session Ticket extension. > > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension > > This keeps it with the same semantics for requesting a ticket, thus > allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 > servers with no additional effort. TLS 1.3 sessions would be resumed using > the new PSK-based method and TLS 1.2 sessions would be resumed using the > old session ticket extension. > > Should I submit this as a PR? It seems like the obvious route if all we > want is to just keep the ability for a client to not request a ticket. No > need to write a new extension at all. As I said initially, I'm having trouble seeing why this is particularly useful. -Ekr --047d7b10c9030488ab051b46f86c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote:
> It depends on how the server implements tickets. The server could impl= ement
> tickets the same way that it implements session ID-based resumption. T= hat's
> not a good idea, but I don't think the spec should prohibit that t= ype of
> implementation either since it unenforceable. Thus, because of that > possibility, it is valuable to have the client be able to say "do= n't cache
> the session" and/or limit the session's lifetime, so the clie= nt can help
> direct the level of forward secrecy for the session. Right now, only t= he
> server has a say in how long a session will be forward-secret.
>
> Note also that the NewSessionTicket extension precedes any application=
> data, so without a way to prevent an unwanted NewSessionTicket message= from
> being sent, the client has to waste effort and time to consume the
> NewSessionTicket before it can do anything useful.

If the general ticket lifetime request route is not needed, here'= ;s the simplest route: just don't drop the Session Ticket extension.
https://githu= b.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension<= /a>

This keeps it with the same semantics for requesting a ticket, thus allowin= g TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 servers= with no additional effort. TLS 1.3 sessions would be resumed using the new= PSK-based method and TLS 1.2 sessions would be resumed using the old sessi= on ticket extension.

Should I submit this as a PR? It seems like the obvious route if all we wan= t is to just keep the ability for a client to not request a ticket. No need= to write a new extension at all.


--047d7b10c9030488ab051b46f86c-- From nobody Mon Jul 20 00:02:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A3E1A00DC for ; Mon, 20 Jul 2015 00:02:29 -0700 (PDT) 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 Ai3e_awaHSZ4 for ; Mon, 20 Jul 2015 00:02:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA841A00E0 for ; Mon, 20 Jul 2015 00:02:21 -0700 (PDT) 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 (Postfix) with ESMTPS id 1936192494; Mon, 20 Jul 2015 07:02:21 +0000 (UTC) Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6K72IRZ013704 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2015 03:02:20 -0400 Message-ID: <1437375738.3377.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Dave Garrett , "" , Eric Rescorla Date: Mon, 20 Jul 2015 09:02:18 +0200 In-Reply-To: <201507182122.12566.davemgarrett@gmail.com> References: <201507182122.12566.davemgarrett@gmail.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: Subject: Re: [TLS] Does the ServerHello really need unencrypted extensions at all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 07:02:29 -0000 On Sat, 2015-07-18 at 21:22 -0400, Dave Garrett wrote: > There's two issues (basically duplicates) for this topic, as well as > an inline TODO. > https://github.com/tlswg/tls13-spec/issues/66 > https://github.com/tlswg/tls13-spec/issues/72 > https://tlswg.github.io/tls13-spec/#server-hello > > The current expectation is to separate extensions into unencrypted > and encrypted, with: > "The ServerHello MUST only include extensions which are required to > establish the cryptographic context." > > The rest then go into the new EncryptedExtensions message. > Are there really any extensions that this applies to? The extensions which indicate the type of server (ALPN) or the name of server must be able to be sent in the clear. The reason is that middle -boxes or proxies must be able to determine the actual server to transfer the session without terminating it. regards, Nikos From nobody Mon Jul 20 00:04:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7987C1A00B9 for ; Mon, 20 Jul 2015 00:04:29 -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 1WIYhZDuKWXy for ; Mon, 20 Jul 2015 00:04:27 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D09F1A00B0 for ; Mon, 20 Jul 2015 00:04:27 -0700 (PDT) Received: by qkdv3 with SMTP id v3so107069178qkd.3 for ; Mon, 20 Jul 2015 00:04:26 -0700 (PDT) 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=4ZAShMftt9kviGyKeWDCIOz4ytrPXTGBEgPJARZJAok=; b=Pz1Rirrvbzji1wrxS0OMfNno2CRMoIT7w0oYFAepr446FpFdu6lIMPh7juTJ0lwre6 a2JQnVSWnDxQS+Mps0ZrClICpI1lZQk3TbUgCJhlzT0kfG/zgG0oHZt4289d3dQgRin5 +xinghfbYpjBAradV+ymMmi8dSkkG7McNLrynKyG7J4yUet9/CS9ZsxtWrszg4nP8eJ3 YQqSqMeE7kdZORP60KNOgue7K9+cix+vY+6V/+vHq0y+sQ/DjfS/fy3yDoanUWYkxIJb JpU8Hhg/7XR5urjChvLbweHTY8Y3QrVKxMCWX18opLH+l08yZn6n4EDXYV4jjn/Ike9h U90A== X-Received: by 10.140.239.9 with SMTP id k9mr39154672qhc.38.1437375866596; Mon, 20 Jul 2015 00:04:26 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id s91sm10482003qge.44.2015.07.20.00.04.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 00:04:26 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Mon, 20 Jul 2015 03:04:24 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507180037.56413.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507200304.24847.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 07:04:29 -0000 On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote: > I think perhaps you have misunderstood the forward secrecy properties of the > current draft. Unlike TLS 1.2 and previous, the current draft has a separate > resumption master secret which is independently derived from the master > secret used for the connection keys in the original connection. This means > that if you don't resume the connection, you have forward secrecy for the > original connection regardless of whether the server stores the session in > the session cache or sends the client a ticket. We've got lots of keys and secrets now. Could you please clarify the exact points where these are each to be discarded? If I am understanding it correctly, the master_secret, prior intermediate secrets, and finished_secret are to be discarded as soon as the keys, resumption_secret, and possibly exporter_secret (which currently has no explanation in the doc) are derived, the handshake is finished, and we're ready for application traffic? It would help if you provided a table/chart laying out the timeline of secret & key lifetimes, from derivation to discard. It should state in the spec explicitly what needs to be kept around for how long and require things be discarded as soon as viable. I think these various values need to be named more consistently in the doc to make searching for them easier. For example, "resumption_secret" is used in the computation part but the words "resumption master secret" are used when actually using this value. (also noted in issue #191 by Martin Thomson) I've pushed a small PR to correct this case along with a few tweaks that I think makes it a bit clearer. https://github.com/tlswg/tls13-spec/pull/205 Also, some other questions about various computations: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1 https://tlswg.github.io/tls13-spec/#key-schedule HKDF(,,,) doesn't seem to be fully defined here, just HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. Could you please clarify this? Why is finished_secret derived from extracted static secret instead of master_secret? There's a TODO about changes to use of the master_secret here; could you explain this bit please? (I assume this is a work in progress) Are there two finished_secret in the event that the client sends a certificate? The computation of verify_data could probably be moved up to the same section so this is all in the same place. Am I correct in reading that it could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, finished_label, handshake_hash, L) without the extra HMAC currently defined for verify_data) Thanks, Dave From nobody Mon Jul 20 00:11:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69161A00DD for ; Mon, 20 Jul 2015 00:11:25 -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 N1W_1qGtSsFI for ; Mon, 20 Jul 2015 00:11:23 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB491A00BB for ; Mon, 20 Jul 2015 00:11:23 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so7502077wic.0 for ; Mon, 20 Jul 2015 00:11: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DHVbOdgoe/dbtM2WhliMgyaIKLsB9ww9B/tlDvfBst4=; b=fupneafuNPVvvUEr9zr8HDhTc0cDH+Bri7dTkb4DwClBDD6CZOKsbzJZdlzosuEWZ+ 2P/ZWF53K8hhQ4P84ZYDxImBR0EgRHxfLUmoQsO/Y7JbAVkrgEXE7rLHmrhr1NpLF232 em/O7j/TXKen4eQ2cOo/RZcEjTrdJ684v0VZyLa/0j6xG/LLZEmtx/D3sJhvx7aoXOS/ LGqtUjPf4fX1NvMMY6n0vkJspSrjHQNMRAxfxPzxbU4bjUGX8k1gROH1JH5pT9yyjzAJ C2+0MBPXVQyAbRyfHLw5F6/+EaZlJ98WF4d+DV9Xe/AvpywBcH4q3dw+HA6imZ/Idi1p I/7w== X-Gm-Message-State: ALoCoQliaFsXT+eW37AEoN8cczz42+3rk7kkaq+444pT6rTC4PFDV8J6AMd/mraC0OgxlmjxhGAn X-Received: by 10.194.79.225 with SMTP id m1mr54454476wjx.8.1437376282019; Mon, 20 Jul 2015 00:11:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Mon, 20 Jul 2015 00:10:42 -0700 (PDT) In-Reply-To: <201507200304.24847.davemgarrett@gmail.com> References: <201507180037.56413.davemgarrett@gmail.com> <201507200304.24847.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 20 Jul 2015 09:10:42 +0200 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b10c903b36745051b493e5c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 07:11:26 -0000 --047d7b10c903b36745051b493e5c Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett wrote: > On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote: > > I think perhaps you have misunderstood the forward secrecy properties of > the > > current draft. Unlike TLS 1.2 and previous, the current draft has a > separate > > resumption master secret which is independently derived from the master > > secret used for the connection keys in the original connection. This > means > > that if you don't resume the connection, you have forward secrecy for the > > original connection regardless of whether the server stores the session > in > > the session cache or sends the client a ticket. > > We've got lots of keys and secrets now. Could you please clarify the exact > points where these are each to be discarded? If I am understanding it > correctly, the master_secret, prior intermediate secrets, and > finished_secret are to be discarded as soon as the keys, resumption_secret, > and possibly exporter_secret (which currently has no explanation in the > doc) are derived, the handshake is finished, and we're ready for > application traffic? It would help if you provided a table/chart laying out > the timeline of secret & key lifetimes, from derivation to discard. It > should state in the spec explicitly what needs to be kept around for how > long and require things be discarded as soon as viable. > Yes, I can do something along these lines. > I think these various values need to be named more consistently in the doc > to make searching for them easier. For example, "resumption_secret" is used > in the computation part but the words "resumption master secret" are used > when actually using this value. (also noted in issue #191 by Martin > Thomson) I've pushed a small PR to correct this case along with a few > tweaks that I think makes it a bit clearer. > https://github.com/tlswg/tls13-spec/pull/205 > > Also, some other questions about various computations: > > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1 > https://tlswg.github.io/tls13-spec/#key-schedule > > HKDF(,,,) doesn't seem to be fully defined here, just > HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. > Could you please clarify this? > Yes. > Why is finished_secret derived from extracted static secret instead of > master_secret? The rationale here is that the Finished message also serves to authenticate the server's ephemeral DH share (when in known_configuration mode) and because the master secret depends on the ephemeral DH keys, this creates an odd authentication logic. Hugo can expand on this some more, perhaps. > Are there two finished_secret in the event that the client sends a > certificate? > No, this shouldn't be necessarily. You just use the first one. I'll try to clarify. > The computation of verify_data could probably be moved up to the same > section so this is all in the same place. Am I correct in reading that it > could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, > finished_label, handshake_hash, L) without the extra HMAC currently defined > for verify_data) See above. -ekr --047d7b10c903b36745051b493e5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Monday, Jul= y 20, 2015 12:27:42 am Eric Rescorla wrote:
> I think perhaps you have misunderstood the forward secrecy properties = of the
> current draft. Unlike TLS 1.2 and previous, the current draft has a se= parate
> resumption master secret which is independently derived from the maste= r
> secret used for the connection keys in the original connection. This m= eans
> that if you don't resume the connection, you have forward secrecy = for the
> original connection regardless of whether the server stores the sessio= n in
> the session cache or sends the client a ticket.

We've got lots of keys and secrets now. Could you please clarify the ex= act points where these are each to be discarded? If I am understanding it c= orrectly, the master_secret, prior intermediate secrets, and finished_secre= t are to be discarded as soon as the keys, resumption_secret, and possibly = exporter_secret (which currently has no explanation in the doc) are derived= , the handshake is finished, and we're ready for application traffic? I= t would help if you provided a table/chart laying out the timeline of secre= t & key lifetimes, from derivation to discard. It should state in the s= pec explicitly what needs to be kept around for how long and require things= be discarded as soon as viable.

Yes, I= can do something along these lines.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I think these various values need to be named more consistently in the doc = to make searching for them easier. For example, "resumption_secret&quo= t; is used in the computation part but the words "resumption master se= cret" are used when actually using this value. (also noted in issue #1= 91 by Martin Thomson) I've pushed a small PR to correct this case along= with a few tweaks that I think makes it a bit clearer.
https://github.com/tlswg/tls13-spec/pull/205

Also, some other questions about various computations:

https://tools.ietf.org/html/draft-iet= f-tls-tls13-07#section-7.1
https://tlswg.github.io/tls13-spec/#key-schedule=

HKDF(,,,) doesn't seem to be fully defined here, just HKDF-Expand-Label= (,,,) which is based on HKDF-Expand(,,) from RFC 5869. Could you please cla= rify this?

Yes.

=C2=A0
Why is finished_secret derived from extracted static secret instead of mast= er_secret?

The rationale here is that the = Finished message also serves to authenticate
the server's eph= emeral DH share (when in known_configuration mode) and
because th= e master secret depends on the ephemeral DH keys, this creates
an= odd authentication logic. Hugo can expand on this some more, perhaps.

=C2=A0
Are there two finished_secret in the event that the client sends a certific= ate?

No, this shouldn't be necessar= ily. You just use the first one. I'll try to clarify.

=C2=A0
The computation of verify_data could probably be moved up to the same secti= on so this is all in the same place. Am I correct in reading that it could = be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, finished_label,= handshake_hash, L) without the extra HMAC currently defined for verify_dat= a)

See above.

-ekr=


--047d7b10c903b36745051b493e5c-- From nobody Mon Jul 20 03:55:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88F31A1B83 for ; Mon, 20 Jul 2015 03:55:47 -0700 (PDT) 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 YDegdED9TiG1 for ; Mon, 20 Jul 2015 03:55:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D24D1A1B78 for ; Mon, 20 Jul 2015 03:55:46 -0700 (PDT) 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 (Postfix) with ESMTPS id BCEB2BC901; Mon, 20 Jul 2015 10:55:45 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-167.brq.redhat.com [10.34.0.167]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6KAthJg012303 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2015 06:55:45 -0400 From: Hubert Kario To: Simon Josefsson Date: Mon, 20 Jul 2015 12:55:37 +0200 Message-ID: <4270669.Na8fLuOzTD@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.6-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <878uairce7.fsf@latte.josefsson.org> References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <17744104.AefDTyBEY2@pintsize.usersys.redhat.com> <878uairce7.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1773425.U4HHyec223"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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: Mon, 20 Jul 2015 10:55:47 -0000 --nextPart1773425.U4HHyec223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote: > Hubert Kario writes: > > On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote: > >> Hubert Kario writes: > >> > As is described in secion 5.1. of RFC 4492, and then reiterated = in > >> > section 2.2. of this draft - the elliptic_curves (a.k.a. > >> > supported_groups) > >> > guides both the ECDH curves and curves understandable by peer fo= r ECDSA > >> > signatures. > >> >=20 > >> > As Curve25519 and Curve448 can only be used for ECDHE, maybe the= y > >> > should > >> > be > >> >=20 > >> > defined/named in the registry as such, to remove any ambiguity[1= ]: > >> > enum { > >> > =20 > >> > Curve25519_ecdh(TBD1), > >> > Curve448_ecdh(TBD2), > >> > =20 > >> > } NamedCurve; > >>=20 > >> I don't care strongly. One disadvantage with this is that if we d= ecide > >> to reuse these NamedCurve allocations to have something to do with= > >> Ed25519, the naming above will be confusing. However, I believe i= t is > >> already likely that Ed25519 will have its own NamedCurve. > >=20 > > Given that there certainly will be implementations that support ecd= h > > and not the signatures, we certainly *don't* want to reuse this > > codepoint for anything else. > >=20 > > So unless the PKIX and TLS parts are defined at the same time, in t= he same > > document, we definitely need to keep them apart. >=20 > It is conceivable to reuse the NamedCurve values for TLS authenticati= on > without affecting the ECHDE use, nor delaying the Curve25519 ECDHE wo= rk. >=20 > Compare how we "reuse" the ECDHE ciphersuite values to refer to > Curve25519 (instead of defining new ciphersuites for Curve25519), and= > how we are "reusing" the "uncompressed" code point to refer to > Curve25519-compressed code points (instead of defining new > ECPointFormat). the point is, that if Ed25519 for signatures is defined, an implementat= ion=20 that doesn't understand it[1] can't advertise that fact 1 - be it because it wasn't updated yet, or because the programmers do= n't=20 consider it important enough yet - that doesn't matter =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1773425.U4HHyec223 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVrNOvAAoJEJKo0bgB0vX1z9IQAIcvDL0otWLxrmRnjTHR1cLq EyjNFhNWJ2r/04l5PpPZonvAITa4FJ3vVhXWdaO3dxITJspqLEN26BTQqaa0ynUM lApoYC6W+xq0XBn9s2JpNVr5I/egIKfHhgHLl/k9UO/ruPk+oz3/KVXnL1+3wiH+ 5aAD5J5RWurXwddApU3z7fpm0O3jru24GzVwOqSM+BQ5217MvR1aEhnQGjF/nukK fB37OKdvrD/vZbQLlyh7EUYUqg9xTbOgjilWGFr5sgeAwrI+iP8ZBxKkkq+osVvt jVRmYKGvde097ruVOliVTvSkE5KY6qWsXK+bOBBz7KbombqRNGdV7Tv43+mCGgJk uc3e7urQfV3Ybt9iZflz5ooPJO8rdBwAkQilvr3Ww2ciPHkxNylZ9eCZqQopadCc RydiinP3PnZxvIWyDMT1U9IS9UJVUwl0JgvPS/Tod0vmoNg8RKMPDs3Vl8PEiFWc MdQraoIgf2g0StZfJV6KUPz+nAY8oMrV2mXM8dTdvjgtzE54m5ObGkp7ET7lScYU SZATSyK1oya2eqctmLkIxmV0g8ldgDRSVjTzMCCp6nS7L18oq93wbjBwjyOmmPe2 rGiqV57FdKdRm7ImxHptmny+8TQmw6Lg592X2Kd+BE3h9iv9X1dH05xc91uz+/OL W8dxCzL4/OLq51nssQBA =phZ0 -----END PGP SIGNATURE----- --nextPart1773425.U4HHyec223-- From nobody Mon Jul 20 04:39:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7B01A219C for ; Mon, 20 Jul 2015 04:39:09 -0700 (PDT) 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 MvWbsB2VlQU0 for ; Mon, 20 Jul 2015 04:39:07 -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 26C721A21A4 for ; Mon, 20 Jul 2015 04:39:07 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 1F617188848; Mon, 20 Jul 2015 14:39:04 +0300 (EEST) Date: Mon, 20 Jul 2015 14:39:03 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20150720113903.GA29356@LK-Perkele-VII> References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <17744104.AefDTyBEY2@pintsize.usersys.redhat.com> <878uairce7.fsf@latte.josefsson.org> <4270669.Na8fLuOzTD@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4270669.Na8fLuOzTD@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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: Mon, 20 Jul 2015 11:39:09 -0000 On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote: > On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote: > > > > Compare how we "reuse" the ECDHE ciphersuite values to refer to > > Curve25519 (instead of defining new ciphersuites for Curve25519), and > > how we are "reusing" the "uncompressed" code point to refer to > > Curve25519-compressed code points (instead of defining new > > ECPointFormat). > > the point is, that if Ed25519 for signatures is defined, an implementation > that doesn't understand it[1] can't advertise that fact Are you thinking about 1.0/1.1? In 1.2 it can: signature_algorithms (I'm not confident new signature algorithm would work without either that nor new ciphersuites). There are other shortcomings tho: - If Ed25519 is supported, one also needs to support Curve25519. - If Ed25519 and Curve448 are supported, one needs to support Curve25519 and Ed448. - And the cross case from previous. So with the same, in TLS 1.2, the following combinations would be possible: - None at all. - Curve25519 - Curve448 - Curve25519 & Curve448 - Curve25519 & Ed25519 - Curve448 & Ed448 - Curve25519 & Curve448 & Ed25519 & Ed448. -Ilari From nobody Mon Jul 20 04:42:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0507C1A0377 for ; Mon, 20 Jul 2015 04:42:57 -0700 (PDT) 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 e-5E2etSN3E9 for ; Mon, 20 Jul 2015 04:42:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76371A6EEC for ; Mon, 20 Jul 2015 04:42:09 -0700 (PDT) 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 (Postfix) with ESMTPS id 5E7FBA2C19; Mon, 20 Jul 2015 11:42:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-167.brq.redhat.com [10.34.0.167]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6KBg7vO031691 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2015 07:42:09 -0400 From: Hubert Kario To: Ilari Liusvaara Date: Mon, 20 Jul 2015 13:42:01 +0200 Message-ID: <13826499.nuPJpBKYuN@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.6-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20150720113903.GA29356@LK-Perkele-VII> References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <4270669.Na8fLuOzTD@pintsize.usersys.redhat.com> <20150720113903.GA29356@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2682126.1F0lNH3VEJ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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: Mon, 20 Jul 2015 11:42:57 -0000 --nextPart2682126.1F0lNH3VEJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 20 July 2015 14:39:03 Ilari Liusvaara wrote: > On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote: > > On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote: > > > Compare how we "reuse" the ECDHE ciphersuite values to refer to > > > Curve25519 (instead of defining new ciphersuites for Curve25519),= and > > > how we are "reusing" the "uncompressed" code point to refer to > > > Curve25519-compressed code points (instead of defining new > > > ECPointFormat). > >=20 > > the point is, that if Ed25519 for signatures is defined, an impleme= ntation > > that doesn't understand it[1] can't advertise that fact >=20 > Are you thinking about 1.0/1.1? In 1.2 it can: signature_algorithms > (I'm not confident new signature algorithm would work without either > that nor new ciphersuites). >=20 >=20 > There are other shortcomings tho: > - If Ed25519 is supported, one also needs to support Curve25519. > - If Ed25519 and Curve448 are supported, one needs to support > Curve25519 and Ed448. > - And the cross case from previous. >=20 > So with the same, in TLS 1.2, the following combinations would > be possible: > - None at all. > - Curve25519 > - Curve448 > - Curve25519 & Curve448 > - Curve25519 & Ed25519 > - Curve448 & Ed448 > - Curve25519 & Curve448 & Ed25519 & Ed448. if we define separate codepoints for Curve25519 and Ed25519, yes =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2682126.1F0lNH3VEJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVrN6PAAoJEJKo0bgB0vX1QOcP/jePTVoJPuUdTZxYz6YN0zrm ETKfr9KdQvLVc1mtlczUXhyzKJ+wvsIs9SB+wdr/Vpw94mPeHWEeuMwv/B/l1A/n 1CL/KWfE8Bqjhg+2Lsgempw4BORQOVVpI1QITcU1Hb3HAYyp7LxnBmxR9VmeUSv8 0Kzu+I6kqyacp5ec/MIIeB9PcR553hTeZ45Quv6L6TzIw/VCfUEYxtJ2gOpoNDQ6 uK0pN5OQiRVM9eFK2jSrLHKcXD5JN9m6Ekep4VvoYhJ/MqQhx7OULwXaSHFW7Ghj iCJOO5lk0ABRUVzArNfLDC7fqLqWlLws6w/BLf1dpF/WCR4AYmma5NhPStXfueDw htskdLgYs44JTxYQJ3ukwbqvxONyWKlXZ2qHXGBP6BMUlrWLdSscx+h1xh773Fvs kUx5BeVN8YjyFeOgnfXnKjfXNBDxfl0LecZ9B3HyuqiYaT/kOiiAjJICOkZzvE1r rCB6DShdk+jIbyq4e2RWZNiZ8VZyLGHaCVjP6IZYKE5YGcGov+/OJwK0Mj/X3OzQ qMXl1JIJ6PhGB9+2FyXuVhxU3iKV/hdyi5cUIsCP9+oTUobbkgCyCl75Q0IDeIAk XiRR4aIlD4VP1uYsA5A0gj8awyfSIDw0y6wSAqO7xZuPImekEuPyz4dHsvOCvunR 2HP4Z8P9ZZI2rtED3Y64 =Spq7 -----END PGP SIGNATURE----- --nextPart2682126.1F0lNH3VEJ-- From nobody Mon Jul 20 04:59:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03191A6FFD for ; Mon, 20 Jul 2015 04:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 r5wHk2-sd_9c for ; Mon, 20 Jul 2015 04:59:00 -0700 (PDT) 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 1FB8E1A6FF7 for ; Mon, 20 Jul 2015 04:59:00 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BFB321A008A; Mon, 20 Jul 2015 13:58:56 +0200 (CEST) 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 zt8j_wNvTy9M; Mon, 20 Jul 2015 13:58:55 +0200 (CEST) Received: from mail-essen-02.secunet.de (unknown [10.53.40.205]) by a.mx.secunet.com (Postfix) with ESMTP id 67E781A007E; Mon, 20 Jul 2015 13:58:55 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0248.002; Mon, 20 Jul 2015 13:58:56 +0200 From: =?Windows-1252?Q?Schmidt=2C_J=F6rn-Marc?= To: Geoff Keating Thread-Topic: [TLS] New cipher suites for SRP Thread-Index: AQHQsGrBqtA/zH8K5UuILxApfv460p2/Z1wAgAAr/wCAA6iDAIAZrUyAgAKI1bCAAE6VAIAEmvmg Date: Mon, 20 Jul 2015 11:58:55 +0000 Message-ID: <38634A9C401D714A92BB13BBA9CCD34F1665C3EB@mail-essen-01.secunet.de> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> <6ce70b2d45a6aa67aae04ef7e6940ca7.squirrel@www.trepanning.net> <38634A9C401D714A92BB13BBA9CCD34F1665ADA2@mail-essen-01.secunet.de> <7532E1F9-23E6-4B7D-AC1A-ABBEE5BD5D7A@geoffk.org> In-Reply-To: <7532E1F9-23E6-4B7D-AC1A-ABBEE5BD5D7A@geoffk.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.56.185] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002A_01D0C2F4.37572090" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 11:59:02 -0000 ------=_NextPart_000_002A_01D0C2F4.37572090 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >> TLS-pwd already supports both of these. It also supports ECC too, >> which is problematic with the current SRP protocol. >In the language of the CFRG draft, TLS-pwd is =93balanced=94 where SRP = is =93augmented=94, >so they=92re not really equivalent, correct? Correct. >This is possible, but you=92d need to have the client and server = negotiate based on >what they have. For example, if the server has a SRP verifier from the current >protocol, but the client has a stored PBKDF2 hash of the password for = that server, >they cannot communicate and would need to pick a different cipher = suite. I am not >sure how you can do this without revealing the existence of an account under some >circumstances. So this might be a situation where fewer protocol = options is better. Of course both sides have to agree on common protocol details: You = could do this by specifying that you want to use PAKE and refine in an extension = a set of schemes that you are capable of.=20 I think there are many flavors out there that may be beneficial in = specific use-cases. I envision that e.g. in the context of the IoT with very constrained devices (specific) PAKE schemes might be helpful. Having an ExtensionType & corresponding CipherSuites for each of them would be way = too much.=20 Best, J=F6rn ------=_NextPart_000_002A_01D0C2F4.37572090 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILcDCCA4Aw ggJooAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAj BgNVBAoMHHNlY3VuZXQgU2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMB4XDTEzMDkx NDE4MDczN1oXDTE2MDkwMjE4MDczN1owUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0wNDEWMBQG A1UECwwNUHVibGljIFNlY3RvcjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCRqvsVVv5MbQS8cy8hB4K/W1zCJkQmiEzH+Dq6Jk+v J60qwXQW+rAkohGpglka0Cunv/nEWcTuOV2WZg+GtvQcriWs6Xgo22SCE41r5zXOtmgYrWlXOYbl clirYVzfvpeQBOklcBd2Pu7scdlN7lR6ZNkxxJjcMZh/jLkEbIWV7pew3DdafUvjH7P9ecLaB2HD 9JM7h0/uUiwWCtJ1u+1Mnqu4SVYuFTu1oUTkBjrWxO7e7F3MweO6VxjMn0vEppBDSPiK19X/hUd8 Snq2clBGy+njz+SjgIntsvTT+VAm7Ax4J+Y1dYujzA4NDFdkWvcp7+HoxmUpOKprR6WXEsKhAgMB AAGjZjBkMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBTbc5QVtU5hMX1CgwnNa7eRfeSseDAS BgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQNs9mwGqcOKL6k9pOo2AZkexvv6jANBgkqhkiG 9w0BAQUFAAOCAQEAq0bGL+Dq20x3nEqUpirjsl2CKhN999HnMaybNrRpS9u4NueLdnHpTEVh2L5h WqRWm9bNpcKN+c8bOB4rC9pcKIQBzam+sDAbfAApsdfovBnmHVyeAWYJj5p04gwBS1ie8+pPJnnb 0DCOhqTwn2wZxtql2P0yLaTuZAdO7t7zFiZbdOUlniRI2dOnF9ZrsC+FMD3WE6sLgktO0+1cST4F QSAtLAJ0NfSp0e9aKJhX+4dzt3zps+GA5bP4OM4iFO0E+xVwzdERZ48lGsRIFo3DhdLwJbgM3uvn 9A63hUU/ig0hTf5gGllVSrSAPFmhsTTJgkqGOnBa0RffRxqHm2gmJDCCA5EwggJ5oAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAjBgNVBAoMHHNlY3Vu ZXQgU2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMB4XDTExMDkwNDIyMDAwMFoXDTE2 MDkwMjIyMDAwMFowTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAjBgNVBAoMHHNlY3VuZXQg U2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEArKUOCQL/pHw+XdjEHgzp8TgwonnZnVmh/8f90GdWdGb9qr2Yb/yRiP4qxGRX9fbI gY/DYoR8995d5Er9cYWfDZZErNkSW0IJIQh0xxHCLxlJG1zfp3vyJgVfpCCPVHmfLa3mH66gpLue cO+rmQ2dcrKpAMf8v9C6YLYe5gP0ng9CoHvGKVmZ/McejJMzO+36luZbo8Ueqv9S31XTeHj2FiTu JK8Vg8k/xZMVPkj1L1ZNiQi/hC9nAb6+YWAL6RKjHGtHdP7AQcmSQbTKaDmZvU/vEtty9DlQgL9z m0Ao8aZM5dJUtzfiafC1dHOnWLTmVtXDYGIhl0e4xpP0NWxW7wIDAQABo3wwejAOBgNVHQ8BAf8E BAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBATBUBgNVHR8ETTBLMEmgR6BFhkNodHRwOi8veDUwOS5z ZWN1bmV0LmNvbS9DUkw/aWQ9YjNhMWE2MzItMzRkNy00NzljLThiMTktNTBjZDNlMWI2NmY0MA0G CSqGSIb3DQEBBQUAA4IBAQBa6Bmjnd8xkB0vtybolc0A5op6EhnXNcJJsgB7CAGQD0Qt8C6Jj/6c V7mtcUg5MY/EblmJyoZfVuOuPlCOfRD25LDwQ386Lh3XdiaNeWp7t8jABHnCkNq9jLjt5VS4ZitT VmLqn78dUbypFezZnehNaELVuDCrkvKkqp9r+hw32MOgCCm42uUauIUL6N1oM0kZo9tV3m7ddBiA JPPqRgt1BUcbvN4fbSOgzFedC5vM+jobHZ1Y+qHW7FRgMkxJcNq+Rc0LeOtbU9/b0oDeUv/p75j4 eW7FZyHoGr9iWD/kqbn9pzPhI+iHgTczOSxHvw1ieSDu2QEm7XqLw+fqpiU0MIIEUzCCAzugAwIB AgIBSTANBgkqhkiG9w0BAQUFADBSMRkwFwYDVQQDDBBQdWJsaWMtU2VjdG9yLTA0MRYwFAYDVQQL DA1QdWJsaWMgU2VjdG9yMRAwDgYDVQQKDAdzZWN1bmV0MQswCQYDVQQGEwJkZTAeFw0xNDEwMjEx MjA1MjNaFw0xNjA5MDExMjA1MjNaMIGlMRswGQYDVQQDDBJKw7Zybi1NYXJjIFNjaG1pZHQxEDAO BgNVBAQMB1NjaG1pZHQxEzARBgNVBCoMCkrDtnJuLU1hcmMxEzARBgNVBAsMCkdvdmVybm1lbnQx FjAUBgNVBAsMDVB1YmxpYyBTZWN0b3IxJTAjBgNVBAoMHHNlY3VuZXQgU2VjdXJpdHkgTmV0d29y a3MgQUcxCzAJBgNVBAYTAmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn3zvWShw r9UJ9cOR9EnSf6TAFItMTptXsXT+oiQmmtOYJHaQUeJ4imehiVABAGL5azr8b4b6EFG1bo0jA1lO +hmb6WD6JEIiq0T1ppL7tZle2xVvM/xEsljMoSKroTrE6rx7AUwAhi54pqabF1HlmWsP87cXwEZZ bnR4sQuF/MfmN7mSe7SY5VG/5El+Dw4YOkjVBmSojiHEO2EBH63YCboPpMJ/hLMZ1rcBaIh9eRl2 uULeNAnGR4+R9IQGQjtJNPvw3n9ca20f8+irCqMpcv5e+VhlTTFHB0K2d/Nzh4BAVluH3u14nrCA IjHhplaOyuoPlw3Q+oPVf+C3ADg00QIDAQABo4HfMIHcMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6 Ly94NTA5LnNlY3VuZXQuY29tL0NSTD9pZD03OTZkNzQyNS0xNjU1LTRmMjctYTBmOC0wMTc1YjM1 MDk4YjYwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwHwYDVR0jBBgwFoAUDbPZsBqnDii+pPaT qNgGZHsb7+owHQYDVR0OBBYEFGOaRJ/ILBu0+4ik5ZQv6NKv0pzLMCkGA1UdEQQiMCCBHmpvZXJu LW1hcmMuc2NobWlkdEBzZWN1bmV0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAB1eAd0+CCJibZxRQ VpgQMp07AUXWyIDno76zBDUwbPioewEzJgerzOnvtGLqMeXaSfgde7nh88itchqYIPhre2pRPPI6 Jpdoqc3HkmtJYPy7cVGThsnr2f7Cn72Tv024/9ZWgN5Muzk8/PisuJa9Vd0nqzDrfcDwbRtfQq8Y kmVs3sNZsknljMfKqRyl6frO3RGGJukReVh+Puksv1Mn6Tn9Bb9w5nNropX6hmHJsyiofLs5IC03 faTKeQIufgven777EpRZePzqfdibhNOL4jvsm45dOXuzlwFDrAoBByiuWmUN3d6zPe8Z7UdUlzuv 8Q21RgJ8bMKpLyLKaa6nQjGCA18wggNbAgEBMFcwUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0w NDEWMBQGA1UECwwNUHVibGljIFNlY3RvcjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUC AUkwCQYFKw4DAhoFAKCCAd0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTUwNzIwMTE1ODU1WjAjBgkqhkiG9w0BCQQxFgQU7UyFrYyDkTEFvegOCdHWC7/fQZswZgYJ KwYBBAGCNxAEMVkwVzBSMRkwFwYDVQQDDBBQdWJsaWMtU2VjdG9yLTA0MRYwFAYDVQQLDA1QdWJs aWMgU2VjdG9yMRAwDgYDVQQKDAdzZWN1bmV0MQswCQYDVQQGEwJkZQIBSTBoBgsqhkiG9w0BCRAC CzFZoFcwUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0wNDEWMBQGA1UECwwNUHVibGljIFNlY3Rv cjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUCAUkwgasGCSqGSIb3DQEJDzGBnTCBmjAL BglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG 9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhow CwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA Od6Gz0c9AmXFg8PXrcyPWvJ1aAZX1OgGfAcQPYp6o+gi+C7JeBa/MEE9newZA0t4irKKPz5hsixk l61KFg3yLeqB7iWgRFdnhbr5pASnXkbPKq9IhSLm9a0c6CZ/t63vL5xsj3LtBBlJqPyTpX9Iipqg 6yFADCgPdnvj4jRJHIwegBiL8KSChuGF7nRcepgdkSiu0DBQoJHbE2/1oNetf5vup2BxL6w6cdsG PY2HzBwsu5kGdhHj808kPWhWDLbNaY32DsgSkpXcIc/8Q8LRpacKAi+46+RIplyFDC5z723oJtH8 nuSHn19VJCs73rKLw1I5qJQzKMsGabB5I6WiUwAAAAAAAA== ------=_NextPart_000_002A_01D0C2F4.37572090-- From nobody Mon Jul 20 05:15:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AE51A6F39 for ; Mon, 20 Jul 2015 05:15:15 -0700 (PDT) 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 PGt_9pcwpabw for ; Mon, 20 Jul 2015 05:15:15 -0700 (PDT) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0668B1A1B8E for ; Mon, 20 Jul 2015 05:15:06 -0700 (PDT) Received: by igbij6 with SMTP id ij6so1108790igb.3 for ; Mon, 20 Jul 2015 05:15:05 -0700 (PDT) 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:content-transfer-encoding; bh=m2jqQV9Irgy54yMAYBIpiPQsYOEwJII1K3fBRYEuERE=; b=jjm2x//b7s/enfxElxJrR1wpCbHqjhKSqqDJGg2HtCA0pFAt8iqADbNZlDECdeguGu Zmvhvh6fo6nLnhNP9T+bp9R1HMRCvU/oXuU0iPuZrwKnvW4+/exJKThtBBnSWIL8eX13 bzIqljf7ixHuOjk1R4zp/4h2wVMdbSHrZtw5S7F8uCmdxBzbkitZY6HYv4k8UQUY7xX1 Eeu60w6kUXjdNJzv9gepjMQZhy7mi2eV6zC0SQyAaL5MAsIqOgCWMWN3poHKAIPjxg9k taLOCvBhiGR+McMRrfZDTmDhPa+HzT8PpYAjfWzisFZcJbStJcd7wcdTRassYo1Gf0wg y8hQ== MIME-Version: 1.0 X-Received: by 10.50.225.103 with SMTP id rj7mr14248810igc.59.1437394505583; Mon, 20 Jul 2015 05:15:05 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 20 Jul 2015 05:15:05 -0700 (PDT) In-Reply-To: <38634A9C401D714A92BB13BBA9CCD34F1665C3EB@mail-essen-01.secunet.de> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> <6ce70b2d45a6aa67aae04ef7e6940ca7.squirrel@www.trepanning.net> <38634A9C401D714A92BB13BBA9CCD34F1665ADA2@mail-essen-01.secunet.de> <7532E1F9-23E6-4B7D-AC1A-ABBEE5BD5D7A@geoffk.org> <38634A9C401D714A92BB13BBA9CCD34F1665C3EB@mail-essen-01.secunet.de> Date: Mon, 20 Jul 2015 08:15:05 -0400 Message-ID: From: Jeffrey Walton To: =?UTF-8?Q?Schmidt=2C_J=C3=B6rn=2DMarc?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New cipher suites for SRP 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: Mon, 20 Jul 2015 12:15:16 -0000 >>This is possible, but you=E2=80=99d need to have the client and server ne= gotiate > based on >>what they have. For example, if the server has a SRP verifier from the > current >>protocol, but the client has a stored PBKDF2 hash of the password for tha= t > server, >>they cannot communicate and would need to pick a different cipher suite. = I > am not >>sure how you can do this without revealing the existence of an account > under some >>circumstances. So this might be a situation where fewer protocol options > is better. > > Of course both sides have to agree on common protocol details: You could= do > this by specifying that you want to use PAKE and refine in an extension a > set of schemes that you are capable of. There's not much to negotiate. I would expend minimal energy on negotiating parameters. The server holds the verifiers, and they are set in stone. To get a verifier, the user needs to be pre-provisioned. Spend energy on keeping the identity private. If you want to go something cool, add an OTP as a second factor. There are two ways to do it based on the math around the verifiers (that I am aware). I have implementations for both in Crypto++, if interested. Jeff From nobody Mon Jul 20 06:03:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B121A87BB for ; Mon, 20 Jul 2015 06:03:00 -0700 (PDT) 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 s3SzpLGIE5qT for ; Mon, 20 Jul 2015 06:02:58 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3691A873C for ; Mon, 20 Jul 2015 06:02:57 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 61E3969A1B; Mon, 20 Jul 2015 16:02:55 +0300 (EEST) Date: Mon, 20 Jul 2015 16:02:54 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20150720130254.GA31614@LK-Perkele-VII> References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <4270669.Na8fLuOzTD@pintsize.usersys.redhat.com> <20150720113903.GA29356@LK-Perkele-VII> <13826499.nuPJpBKYuN@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <13826499.nuPJpBKYuN@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-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: Mon, 20 Jul 2015 13:03:00 -0000 On Mon, Jul 20, 2015 at 01:42:01PM +0200, Hubert Kario wrote: > On Monday 20 July 2015 14:39:03 Ilari Liusvaara wrote: > > On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote: > > > > There are other shortcomings tho: > > - If Ed25519 is supported, one also needs to support Curve25519. > > - If Ed25519 and Curve448 are supported, one needs to support > > Curve25519 and Ed448. > > - And the cross case from previous. > > > > So with the same, in TLS 1.2, the following combinations would > > be possible: > > - None at all. > > - Curve25519 > > - Curve448 > > - Curve25519 & Curve448 > > - Curve25519 & Ed25519 > > - Curve448 & Ed448 > > - Curve25519 & Curve448 & Ed25519 & Ed448. > > if we define separate codepoints for Curve25519 and Ed25519, yes That list was assuming the following: - TLS at least 1.2 (I don't see much point with bothering with lesser versions here). - Unified 255/448 bit signature algorithm as one of SignatureAlgorithm codepoints, using ECDSA ciphersuites. - The same codepoint used for both 25519 kex and sig curve (and the same for 448). Breaking any of those three assumptions changes things here. -Ilari From nobody Mon Jul 20 06:08:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49841A8778 for ; Mon, 20 Jul 2015 06:08:39 -0700 (PDT) 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 sUZmGsUzmCwp for ; Mon, 20 Jul 2015 06:08:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA651A8704 for ; Mon, 20 Jul 2015 06:08:38 -0700 (PDT) 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 (Postfix) with ESMTPS id 08CE6345A83; Mon, 20 Jul 2015 13:08:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-167.brq.redhat.com [10.34.0.167]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6KD8aYD012063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2015 09:08:37 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 20 Jul 2015 15:08:29 +0200 Message-ID: <3057217.d0lbc7rhst@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.6-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <201507152242.55454.davemgarrett@gmail.com> References: <20150716014248.5333071.47478.4400@certicom.com> <201507152242.55454.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2369558.bqGuUOlXTo"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 13:08:39 -0000 --nextPart2369558.bqGuUOlXTo Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote: > On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote: > > What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By th= e way > > it has no unexplained constants...). Has it been removed already, o= r does > > the question also refer K-571 too? > Already dropped. That's obviously not irreversible, but it's unambigu= ously > in the virtually unused camp. The initial goal was to drop all largel= y > unused curves. >=20 > This question is just about sect571r1, which is far closer to secp384= r1 & > secp521r1 in terms of usage, though still notably less. If you want t= o > argue for going with sect571k1 and not sect571r1, I don't think the W= G is > on-board with that. Even if we continued to allow it, I doubt much wo= uld > add support for it to be worthwhile. This is likely just an artefact of use of OpenSSL curve order, if K-571= was=20 first, the servers would likely select it over B-571 more often > The scan I linked to found one; literally a single server on the enti= re > Internet, _not_ a single server in the Internet, a single server among Alexa top = 1=20 million websites - the scan is checking only a set of popular _websites= _, not=20 even all popular services that use TLS, let alone the whole Internet > that actually supports sect571k1 for ECDHE. The stats also show > 1575 "support" it, so I'm not sure what's going on there specifically= . (if > someone can explain this bit of those stats, please do) The "Supported PFS" section describes what the server selects if the cl= ient=20 advertises default OpenSSL order of all defined curves. The "Prefer" li= nes,=20 means that the ciphersuite selected by server by default uses this key=20= exchange. IOW, if server supports FFDHE 2048 and ECDHE P-256 and prefers ECDHE, t= hen the=20 server will be counted in three lines: DH,2048bits ECDH,P-256,256bits Prefer ECDH,P-256,256bits The "Supported ECC curves" section describes what curves the server wil= l use=20 for ECDHE key exchange if its preferred one is not advertised by client= (in=20 most cases that means what happens if the client doesn't advertise P-25= 6=20 curve). Then that curve is removed and the process repeated until the s= erver=20 picks a ciphersuite that doesn't use ECDHE or aborts connection. feel free to ask more questions about the scans if something is still u= nclear =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2369558.bqGuUOlXTo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVrPLTAAoJEJKo0bgB0vX1NT4QAJoLPbR+j9nVaeHnvJIwDLOi SiR2WscSPnLr0OZfLD7CWRGWrOT6kjOABHAFpYNLRQUeIZEvJRudLncQldP9s9uG bt0SJ01jDP1fzP+ac+NtwmFuy8H8yxj21mRwe6DEwjEPh8fXgEZ1Z2pjuoULuc3o oC/IAaERxHOv+UjuU7lGZ5JWV+DLXvfpICNBeFsxBbEA9ao98F1oVlMR4F/lwLng t/8ny1m4+2488qbytYCBgd329p5eTU3D8qI9/PgBv1uGGv5fDwPVy+5KLfnJcVlw g2yhz3rwsai4um7mrjspHKwfR6uMGGvy8ejTzXAY9AHJoiARquP/8156HD6riSIQ 9QebLYFw56bvxts2trHW6YXU86RmyidyaTIZWgT14sSBHwqveF/ZQWO5ONO7DSKR 0cqbj9yZsT9OWP6iPsH5oWc3FJNu9Z8/P/i9pi8N85dOrRgmjyttNiE6mdieoYFg 3FFWGUTC8cUq6iLARD+cPdb+BdN7OJHJWW5Yvf7HKK38H/ZmSgQJX2k76PeBFFvp DiYXCWDJ8HADa49jULBLxsFzvueaQXRF3vPoTDgtE9s0OCg0jz9oJmGMEhk22en8 QYNIa+p4FCiONaOQv69r7mydioQpF+GlGomqBrqQUn8bhoMNpPfRGOfYBseRoc3q qVd5gTSspmtOrzzOaOdl =Hh7x -----END PGP SIGNATURE----- --nextPart2369558.bqGuUOlXTo-- From nobody Mon Jul 20 07:10:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232BB1A87BC for ; Mon, 20 Jul 2015 07:10:41 -0700 (PDT) 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 tiNcxep9Hh2I for ; Mon, 20 Jul 2015 07:10:39 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227481A87B9 for ; Mon, 20 Jul 2015 07:10:39 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 44B7A9013E for ; Mon, 20 Jul 2015 17:10:36 +0300 (EEST) Date: Mon, 20 Jul 2015 17:10:36 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150720141036.GA32204@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 14:10:41 -0000 Some commentary on client authentication slides (there is no linked draft nor other material yet). - Mechanism like proposed looks dangerous when combined with HTTP/2. Multiplexed protocols are in general not safe to authenticate without application-layer signaling (which can be implicit via separate connections), especially if dealing with something like web environment. - Regarding last point about interleaving: Assuming the scheme works in 1RTT (and I see no reason for requiring more rounds), you can't prevent application_data transmission after certificate_request. The best that can be done is to require the client to send all the authentication-related data in one go. - The certificate_types field in CertificateRequest is pretty much useless, since all supported algorithms are of signature type. - One can't just remove fields without breaking parse compatiblity, but adding field breaks parse compatiblity too, so removing field at the same time isn't a problem. - How does extension_values work? If multiple values for one OID are allowed, then the OID/value pair is repeated, once for each value? -Ilari From nobody Mon Jul 20 10:32:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84BB1B2D0C for ; Mon, 20 Jul 2015 10:32:06 -0700 (PDT) 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 M7tGmBtqVjiI for ; Mon, 20 Jul 2015 10:32:03 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287EC1B2CFB for ; Mon, 20 Jul 2015 10:31:46 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so19281899lbb.3 for ; Mon, 20 Jul 2015 10:31:44 -0700 (PDT) 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=lzcknb6o2reaCc0tkoOY9OPQLtsqOgUNTazBr9SGNEw=; b=hzUdzxR3bh59aZ1vEmRFir6sTJNo0vdrJMeM+VrXxujKtIU7FyDabuMUnl+nudyOQe v8z01KY+DUs8dfMrw0Q5pHjdMgZm1XT2pR248+XySvv38TiFXjfVdfVcnSPdmzKfKGZR Y5Rr4p9+yn9Ilx3PwSJLtguCvn6BTmzoABKyDTAIxnpD2sU5miAvYQHOhQXbIn3RZLva AflKoggAlNDfPWJT0r55UQ5kKt9YHZ/Ab4Dmw6zUnaIaVR9K9P9oqXInZT7iStvN3LHM raROAKh+1L8v1eRjbUJvvpBr849U5JLE0EoRq0Zq1r7qHYYLk412u32sHEzVXdTjArrg ysSg== X-Received: by 10.152.36.41 with SMTP id n9mr28905771laj.79.1437413504590; Mon, 20 Jul 2015 10:31:44 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.209.145 with HTTP; Mon, 20 Jul 2015 10:31:15 -0700 (PDT) In-Reply-To: References: <201507180037.56413.davemgarrett@gmail.com> <201507200304.24847.davemgarrett@gmail.com> From: Hugo Krawczyk Date: Mon, 20 Jul 2015 10:31:15 -0700 X-Google-Sender-Auth: ORxqL8LbLngZfAWt9n6BM40s2NE Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0158b608562a81051b51e9a9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 17:32:06 -0000 --089e0158b608562a81051b51e9a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8B On Mon, Jul 20, 2015 at 12:10 AM, Eric Rescorla wrote: > > > On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett > wrote: > >> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote: >> > I think perhaps you have misunderstood the forward secrecy properties >> of the >> > current draft. Unlike TLS 1.2 and previous, the current draft has a >> separate >> > resumption master secret which is independently derived from the maste= r >> > secret used for the connection keys in the original connection. This >> means >> > that if you don't resume the connection, you have forward secrecy for >> the >> > original connection regardless of whether the server stores the sessio= n >> in >> > the session cache or sends the client a ticket. >> >> We've got lots of keys and secrets now. Could you please clarify the >> exact points where these are each to be discarded? If I am understanding= it >> correctly, the master_secret, prior intermediate secrets, and >> finished_secret are to be discarded as soon as the keys, resumption_secr= et, >> and possibly exporter_secret (which currently has no explanation in the >> doc) are derived, the handshake is finished, and we're ready for >> application traffic? It would help if you provided a table/chart laying = out >> the timeline of secret & key lifetimes, from derivation to discard. It >> should state in the spec explicitly what needs to be kept around for how >> long and require things be discarded as soon as viable. >> > > Yes, I can do something along these lines. > > > >> I think these various values need to be named more consistently in the >> doc to make searching for them easier. For example, "resumption_secret" = is >> used in the computation part but the words "resumption master secret" ar= e >> used when actually using this value. (also noted in issue #191 by Martin >> Thomson) I've pushed a small PR to correct this case along with a few >> tweaks that I think makes it a bit clearer. >> https://github.com/tlswg/tls13-spec/pull/205 >> >> Also, some other questions about various computations: >> >> https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1 >> https://tlswg.github.io/tls13-spec/#key-schedule >> >> HKDF(,,,) doesn't seem to be fully defined here, just >> HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. >> Could you please clarify this? >> > > Yes. > > > >> Why is finished_secret derived from extracted static secret instead of >> master_secret? > > > The rationale here is that the Finished message also serves to authentica= te > the server's ephemeral DH share (when in known_configuration mode) and > because the master secret depends on the ephemeral DH keys, this creates > an odd authentication logic. Hugo can expand on this some more, perhaps. > =E2=80=8BEric's explanation is correct. Your question boils down to: Why is finished_secret derived from SS only and not from ES? First note that the issue only arises in the known_configuration case since in other cases ES and SS are the same. For the known_configuration case there are t wo important reasons =E2=80=8B to build on SS and not on ES: =E2=80=8B 1. Only SS can authenticate the handshake as it is the only element to involve the server's (semi) static private key. 2. One of the main elements to be authenticated by the server (via the Finished message) is the ServerKeyShare, thus deriving the key for the Finished message (i.e. finished_secret) from ES (calculated using ServerKeyShare) would create a circularity issue in the logic of the derivation. Note that the derivation of application keys (and other key material remaining after the end of the handshake) do involve both SS and ES, but in that case involving ES is crucial to achieve forward secrecy. Hugo =E2=80=8B > > > >> Are there two finished_secret in the event that the client sends a >> certificate? >> > > No, this shouldn't be necessarily. You just use the first one. I'll try t= o > clarify. > > > >> The computation of verify_data could probably be moved up to the same >> section so this is all in the same place. Am I correct in reading that i= t >> could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, >> finished_label, handshake_hash, L) without the extra HMAC currently defi= ned >> for verify_data) > > > See above. > > -ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0158b608562a81051b51e9a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B=E2=80=8B


On Mon, Jul 20, 201= 5 at 12:10 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Mo= nday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> I think perhaps you have misunderstood the forward secrecy properties = of the
> current draft. Unlike TLS 1.2 and previous, the current draft has a se= parate
> resumption master secret which is independently derived from the maste= r
> secret used for the connection keys in the original connection. This m= eans
> that if you don't resume the connection, you have forward secrecy = for the
> original connection regardless of whether the server stores the sessio= n in
> the session cache or sends the client a ticket.

We've got lots of keys and secrets now. Could you please clarify the ex= act points where these are each to be discarded? If I am understanding it c= orrectly, the master_secret, prior intermediate secrets, and finished_secre= t are to be discarded as soon as the keys, resumption_secret, and possibly = exporter_secret (which currently has no explanation in the doc) are derived= , the handshake is finished, and we're ready for application traffic? I= t would help if you provided a table/chart laying out the timeline of secre= t & key lifetimes, from derivation to discard. It should state in the s= pec explicitly what needs to be kept around for how long and require things= be discarded as soon as viable.

Yes, I can do something along these lines.

=C2=A0=
I think these various values need to be named more consistently in the doc = to make searching for them easier. For example, "resumption_secret&quo= t; is used in the computation part but the words "resumption master se= cret" are used when actually using this value. (also noted in issue #1= 91 by Martin Thomson) I've pushed a small PR to correct this case along= with a few tweaks that I think makes it a bit clearer.
https://github.com/tlswg/tls13-spec/pull/205<= span class=3D"">

Also, some other questions about various computations:

https://tools.ietf.org/html/dr= aft-ietf-tls-tls13-07#section-7.1
https://tlswg.github.io/tls13-spec/#key-schedule=

HKDF(,,,) doesn't seem to be fully defined here, just HKDF-Expand-Label= (,,,) which is based on HKDF-Expand(,,) from RFC 5869. Could you please cla= rify this?

Yes.

=C2=A0
Why is finished_secret derived from extracted static secret instead of mast= er_secret?

The rationale here is th= at the Finished message also serves to authenticate
the server= 9;s ephemeral DH share (when in known_configuration mode) and
bec= ause the master secret depends on the ephemeral DH keys, this creates
=
an odd authentication logic. Hugo can expand on this some more, perhap= s.

=E2=80=8BEric's explanation is correct.=C2=A0
Your question boils down to: Why is finished_sec= ret derived from SS only and not from ES?

First note that the= issue only arises in the known_configuration case since in other cases ES = and SS are the same.
For the know= n_configuration case there are t
wo important reasons
=E2=80=8B to build = on SS and not on ES:
=E2=80=8B
1. Only = SS can authenticate the handshake as it is the only element to involve the = server's (semi) static private key.
2. One of the main elements t= o be authenticated by the server (via the=C2=A0Finished=C2=A0message) is the ServerKeyShare, thus deriving the key for the=C2= =A0Finished=C2=A0message (i.e. finished_secret) fro= m ES (calculated using ServerKeyShare) would create a circularity issue in = the logic of the derivation.

Note that the derivation of application keys (and other key material= remaining after the end of the handshake) do involve both SS and ES, but i= n that case involving ES is crucial to achieve forward secrecy.
=


Hugo
=E2=80= =8B
=C2=A0

=C2= =A0
Are there two finished_secret in the event that the client sends a certific= ate?

No, this shouldn't be n= ecessarily. You just use the first one. I'll try to clarify.

=C2=A0
The computation of verify_data could probably be moved up to the same secti= on so this is all in the same place. Am I correct in reading that it could = be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, finished_label,= handshake_hash, L) without the extra HMAC currently defined for verify_dat= a)

See above.

-ekr



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


--089e0158b608562a81051b51e9a9-- From nobody Mon Jul 20 11:19:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5D11B2A80 for ; Mon, 20 Jul 2015 11:19:41 -0700 (PDT) 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_22=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 eOghKJTQhHkF for ; Mon, 20 Jul 2015 11:19:40 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796FE1B2A8E for ; Mon, 20 Jul 2015 11:19:40 -0700 (PDT) Received: by qgy5 with SMTP id 5so76572979qgy.3 for ; Mon, 20 Jul 2015 11:19:39 -0700 (PDT) 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=2z2VwNnBHSPuGxF7J4CCJXQoM+ITeK/X0yQ+kFO7q88=; b=Oo2BdA3eVc/kRHdUpsoHGxdvE/cxBVEJJAI/mBHk8Rz2O6gBGp/MH2YI9owF3E3Fz8 kGlhvRNmS5ixjpWtm15xXq9ErhXwxhzLRfsS2dsyC6gHVJkxaWuVoYjAPOyAxoY5fAY8 XxI7lWI60ABGHgurioGJNtRJX9ZdNGhnOtQmWKdN7l/zxoz+vjdjMXH7Zjk6aeCqsfdU UGjW/c63OKwiN/m2e8YC9GjNe2upPxZ9RG8MhPfeTSVeiQPteTXk3ByRiIwFLyLNDNKa +uv0m9egbDiiPkQ3ENiAkQwBLPtWUVYWXlN2F5N8QPMxdyUeW9f0C8JzH100HirYMCdp ptUg== X-Received: by 10.140.150.198 with SMTP id 189mr43748113qhw.88.1437416379741; Mon, 20 Jul 2015 11:19:39 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id k16sm11348182qgd.23.2015.07.20.11.19.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 11:19:39 -0700 (PDT) From: Dave Garrett To: Hugo Krawczyk Date: Mon, 20 Jul 2015 14:19:37 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507180037.56413.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201507201419.37691.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2015 18:19:41 -0000 On Monday, July 20, 2015 01:31:15 pm Hugo Krawczyk wrote: > Your question boils down to: Why is finished_secret derived from SS only > and not from ES? >=20 > First note that the issue only arises in the known_configuration case sin= ce > in other cases ES and SS are the same. > For the known_configuration case there are two important reasons > =E2=80=8Bto build on SS and not on ES: > =E2=80=8B > 1. Only SS can authenticate the handshake as it is the only element to > involve the server's (semi) static private key. > 2. One of the main elements to be authenticated by the server (via the > Finished message) is the ServerKeyShare, thus deriving the key for the > Finished message (i.e. finished_secret) from ES (calculated using > ServerKeyShare) would create a circularity issue in the logic of the > derivation. >=20 > Note that the derivation of application keys (and other key material > remaining after the end of the handshake) do involve both SS and ES, but = in > that case involving ES is crucial to achieve forward secrecy. Thanks for the explanation. Using the master secret could work, but adding the ES isn't productive so u= sing the SS directly makes more sense than mixing SS+ES first. Dave From nobody Mon Jul 20 22:41:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4206C1ACEE1 for ; Mon, 20 Jul 2015 22:41:46 -0700 (PDT) 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 3r5zMVgh331Y for ; Mon, 20 Jul 2015 22:41:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D4DB91ACEE3 for ; Mon, 20 Jul 2015 22:41:44 -0700 (PDT) Received: from fifthhorseman.net (31.208.broadband18.iol.cz [109.81.208.31]) by che.mayfirst.org (Postfix) with ESMTPSA id 36E3EF984; Tue, 21 Jul 2015 01:41:40 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7F38520075; Tue, 21 Jul 2015 07:41:39 +0200 (CEST) From: Daniel Kahn Gillmor To: Nikos Mavrogiannopoulos , Arnaud KAISER , "tls\@ietf.org" In-Reply-To: <1436449396.6877.4.camel@redhat.com> References: <1436449396.6877.4.camel@redhat.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 21 Jul 2015 07:41:39 +0200 Message-ID: <87k2tukqy4.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] New version of draft-lonc-tls-certieee1609-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, 21 Jul 2015 05:41:46 -0000 On Thu 2015-07-09 15:43:16 +0200, Nikos Mavrogiannopoulos wrote: > This draft uses the rfc6091 cert_type extension. If that is not > intentional, rfc6091 was made obsolete by rfc7250 which uses the > server_certificate_type and client_certificate_type extensions (even > though the text doesn't mention that). There is no explicit "obsoletes:" header in 7250. Should we post an erratum to either 7250 or 6091 or both to provide clearer guidance for future authors? --dkg From nobody Tue Jul 21 01:51:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F831B2BB2 for ; Tue, 21 Jul 2015 01:51:33 -0700 (PDT) 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_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 i8Q8lJG693sn for ; Tue, 21 Jul 2015 01:51:32 -0700 (PDT) Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.144.21]) (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 931051B2B03 for ; Tue, 21 Jul 2015 01:51:32 -0700 (PDT) Received: by gateway30.websitewelcome.com (Postfix, from userid 500) id 0FF6DC8BD53C4; Tue, 21 Jul 2015 03:51:32 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway30.websitewelcome.com (Postfix) with ESMTP id F3719C8BD539D for ; Tue, 21 Jul 2015 03:51:31 -0500 (CDT) Received: from [31.133.178.195] (port=52244 helo=dhcp-b2c3.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZHTGt-0004K8-3p for tls@ietf.org; Tue, 21 Jul 2015 03:51:31 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <08146A4E-C2CE-49ED-ACC5-FD7A5B8799AA@ieca.com> Date: Tue, 21 Jul 2015 10:51:26 +0200 To: "" 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.178.195 X-Exim-ID: 1ZHTGt-0004K8-3p X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b2c3.meeting.ietf.org) [31.133.178.195]:52244 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] ietf 93 slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 08:51:34 -0000 I've uploaded the chair=92s slides and the other presentations I=92ve = received to date: https://datatracker.ietf.org/meeting/agenda/ spt From nobody Tue Jul 21 04:04:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B181A0087 for ; Tue, 21 Jul 2015 04:04:56 -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 R7TNtTKab7pr for ; Tue, 21 Jul 2015 04:04:55 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D996B1A0078 for ; Tue, 21 Jul 2015 04:04:54 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so59993672wgb.3 for ; Tue, 21 Jul 2015 04:04:53 -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:from:date:message-id:subject:to :content-type; bh=qKYwz1ZV4j9vI82egDX1zRtHGyf+HO/0lCr63H3AAbY=; b=eI1bNMxKan3W3G3SjNMjKeOljp/1REYsPIESgWdZNKdYMkBAYcGwJR3AOsKExKOO/v 0pDaNF/ESlF4m6S/9QsVk3qZSV2oHdDv7e9MsZ2LF+5Sxt8fl5JBXCJ+MpGDIOOBijFc rKedJwyAHt0xjIkvUawaGmKLsvPLb/WzUe/vO7SMcDmrM/JQEZ4xp959IDCtzLnlhztg Tn4m2CJM5QX6bLfJdTDOLy2NR2A//7o/xhO4TjxDEI0a/SYkFJ1HJ1HXnW9ljKW94vEx BPloWkJiR1aai0JLLmbj1PmyOsiL2Q9GwjOf0NPvuJPE8Ut0Kdqy7+o9bmhRcsKORSXV GWRw== X-Gm-Message-State: ALoCoQnMCsRWKIOBdv3R3SD5WuyfcwK6VO9fpVA7D52Bwv4HnoPgTd8yYME65dqnsAyquxCm0weO X-Received: by 10.194.79.225 with SMTP id m1mr66966375wjx.8.1437476693557; Tue, 21 Jul 2015 04:04:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 04:04:14 -0700 (PDT) From: Eric Rescorla Date: Tue, 21 Jul 2015 13:04:14 +0200 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10c903b160f2051b609f4f Archived-At: Subject: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 11:04:56 -0000 --047d7b10c903b160f2051b609f4f Content-Type: text/plain; charset=UTF-8 The known_configuration mechanism in the current draft allows the client to resurrect the handshake parameters (though not the keys) which were negotiated in a previous handshake, but this is done implicitly, i.e., the server provides a label and the client returns it on the next connection. This has the advantage of keeping things short but the disadvantage the it means that you can't have a static configuration ID for everyone (instead, the server has to somehow embed the properties in the configuration ID). After some thought, I think this is a bad plan. Here's what I propose (and what's in my slides for today): - The client indicates configuration ID and cryptographic configuration, including the cipher suites and cryptographic extensions. This MUST replicate the server's selection from a previous handshake - The server verifies the client's ClientHello and (a) Checks that configuration ID is valid (b) Verifies that client's parameters are what it would negotiate Accordingly, this would change the extension to something like: struct { select (Role) { case client: opaque identifier<0..2^16-1>; CipherSuite cipher_suite; // NEW Extension extensions<0..2^16-1>; // NEW case server: struct {}; } } KnownConfigurationExtension The server would just need one configuration for each public key and woudldn't need to have any client-specific state. It also has the benefit that it makes PSK work with 0-RTT. Thoughts? Improvements? -Ekr --047d7b10c903b160f2051b609f4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The known_configuration mechanism in the current draf= t allows the
client to resurrect the handshake parameters (though= not the keys)
which were negotiated in a previous handshake, but= this is done
implicitly, i.e., the server provides a label and t= he client returns
it on the next connection. This has the advanta= ge of keeping things
short but the disadvantage the it means that= you can't have a static
configuration ID for everyone (inste= ad, the server has to somehow
embed the properties in the configu= ration ID). After some thought,
I think this is a bad plan.
=

Here's what I propose (and what's in my slides = for today):

- The client indicates configuration I= D and cryptographic configuration,
=C2=A0 including the cipher su= ites and cryptographic extensions. This
=C2=A0 MUST replicate the= server's selection from a previous handshake

= - The server verifies the client's ClientHello and
=C2=A0 (a)= Checks that configuration ID is valid
=C2=A0 (b) Verifies that c= lient's parameters are what it would negotiate


Accordingly, this would change the extension to something l= ike:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Role) {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client:
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque identifier<0.= .2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0CipherSuite cipher_suite; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// NE= W
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extensio= n extensions<0..2^16-1>; =C2=A0 =C2=A0 // NEW

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case server:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {};
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0} KnownConfigurationExtension


The server would just need one configuration for each public key an= d
woudldn't need to have any client-specific state. It also h= as the
benefit that it makes PSK work with 0-RTT.

<= /div>
Thoughts? Improvements?

-Ekr
<= br>
--047d7b10c903b160f2051b609f4f-- From nobody Tue Jul 21 04:11:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87A01A00BF for ; Tue, 21 Jul 2015 04:10:58 -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 wEl04zRlM4yc for ; Tue, 21 Jul 2015 04:10:57 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49A61A00C0 for ; Tue, 21 Jul 2015 04:10:56 -0700 (PDT) Received: by ykdu72 with SMTP id u72so162190005ykd.2 for ; Tue, 21 Jul 2015 04:10:56 -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=bwOWYgbq+Pnk+S3rQHDpZFMwuSYr9nYZt6sXSfC1Oac=; b=j6QBnvCnJumiD4Yh2Ht3VNrIWqYWfh5gCrfFpYMNHwIrU1IgQBeb4NSDKgFWlXgQmB lUsyjUcGc/m0pyGG/apHyZGp4nWkuEXEQ88G1omsCpnbkWq8PakKRenyTl0dCc2hE62p pUwXxPL86xGV6Vk7GnJthg08IuP6/Epz2qGob99HxfjNTPk1sA1rWV/xQyRDFfToHgub ES5u1fhjGPeI+5G/fk7AvsjZ1tvuFygFrhEIaPHAuNyXTOEzXqGoXlTVGgNVf9aQvevM f4sl29xL6mi+aL2SSXKmCHkBq1GCWh5ZqEUPdkbCNtZQXLm/xfoAsi3STxUR0jvOgDFj Qagg== MIME-Version: 1.0 X-Received: by 10.129.103.84 with SMTP id b81mr33038005ywc.55.1437477056259; Tue, 21 Jul 2015 04:10:56 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 21 Jul 2015 04:10:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2015 04:10:56 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 11:10:58 -0000 On 21 July 2015 at 04:04, Eric Rescorla wrote: > - The client indicates configuration ID and cryptographic configuration, > including the cipher suites and cryptographic extensions. This > MUST replicate the server's selection from a previous handshake That's not going to work if there was no previous session. For instance, if the configuration was learned out of band. It also implies that the selection can come from ANY previous session, where I think that it only makes sense to identify the session where the configuration was learned. From nobody Tue Jul 21 04:13:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52EA1A0024 for ; Tue, 21 Jul 2015 04:13:20 -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 LikmGDV0BB3w for ; Tue, 21 Jul 2015 04:13:19 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6951A00A0 for ; Tue, 21 Jul 2015 04:13:18 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so60180071wgb.3 for ; Tue, 21 Jul 2015 04:13:17 -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=aiTegZWRLKqdCxEVufxTEGnYUWNTB5eakOgFuAOazWU=; b=kvANKlh4MZeNxZ1VLj9PTH1O5PbdfHQHU5+T1wq/aLRFZJ1zhqfuAlVKBLquJ/Vqyg cQaGY2bdRADEcXAbrrsvkSoJ1/g/bi5zSfNkEelXkllwOJ2vYJ6U84H3qLP32fm4A2xd WlRklXqIv/Po5mLMQrxsBaD+Emuj8UWjE/L1dMoBJYOcvCkx/LrE2uXUyKHnguktiJ/t ldAWhuFsokVo8PQ7ifQ1tqjnnzypMCGjflyCjC93MmKM6gDi00R2m9vEWf/nCLrMIRLM 6A0GKkpUrCD/ceOQQkXcVH7Nk3XvVoHIkySodepIYAybDBCFOJM55Mlfz+68O5xtHS3m nk+w== X-Gm-Message-State: ALoCoQmYd/QVaaft0Td9l1C7aJWRR8HLQsgEIoemEbfujvlZpwEV1p+2LIwy27gZ/QaYWrsUgdXh X-Received: by 10.194.158.42 with SMTP id wr10mr64519210wjb.81.1437477197778; Tue, 21 Jul 2015 04:13:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 04:12:38 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 21 Jul 2015 13:12:38 +0200 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e013c6478bf3115051b60bdc5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 11:13:20 -0000 --089e013c6478bf3115051b60bdc5 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson wrote: > On 21 July 2015 at 04:04, Eric Rescorla wrote: > > - The client indicates configuration ID and cryptographic configuration, > > including the cipher suites and cryptographic extensions. This > > MUST replicate the server's selection from a previous handshake > > > That's not going to work if there was no previous session. For > instance, if the configuration was learned out of band. Yes, that's an issue. Not entirely sure what to do about other than have the server provide its negotiation preferences out of band in that case. It also implies that the selection can come from ANY previous session, where I > think that it only makes sense to identify the session where the > configuration was learned. > I agree with this point. -Ekr --089e013c6478bf3115051b60bdc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 21 July 2015 at 04:04, Eric Rescorla <ekr@rtfm.com> wrote:
> - The client indicates configuration ID and cryptographic configuratio= n,
>=C2=A0 =C2=A0including the cipher suites and cryptographic extensions. = This
>=C2=A0 =C2=A0MUST replicate the server's selection from a previous = handshake


That's not going to work if there was no previous session.=C2=A0= For
instance, if the configuration was learned out of band.
<= br>
Yes, that's an issue. Not entirely sure what to do about = other than
have the server provide its negotiation preferences ou= t of band
in that case.=C2=A0


=
=C2=A0It also
implies that the selection can come from ANY previous session, where I
think that it only makes sense to identify the session where the
configuration was learned.

I agree with this p= oint.

= -Ekr

<= br>
--089e013c6478bf3115051b60bdc5-- From nobody Tue Jul 21 04:30:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF891A0100 for ; Tue, 21 Jul 2015 04:30:15 -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 RU2CKhC5ssZ2 for ; Tue, 21 Jul 2015 04:30:13 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE0B1A00B7 for ; Tue, 21 Jul 2015 04:30:13 -0700 (PDT) Received: by ykfw194 with SMTP id w194so82418134ykf.0 for ; Tue, 21 Jul 2015 04:30:13 -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=zonGHEeUB1kC2Gmx42w59JP3qmsezDEeiwYp+tSlBPQ=; b=QMw5MhWOwyvr4kt7FODAALFY/apRoyGYNEFi85xCzfu2+xJJ5o4DbOEbd4ZGmt2ypy S9GHCTA3D6t32wz8PyfgDAZ9nNhQ1CiP4A5N4dan2KpmjplJxTZm1l0FZYbm5OgMV4vG mAkvi0y1plMe+scap5UeqT2yaPkaFaWOxqulJabEcNzLcb94QtjTZYS3L6sHL/1gQnG+ ZHELbE0IkF9cKhKjEKKPUyPfAZuIwz6F/IRJDLYVObojRfdRekMm95DQydcAOX8As/Qc wTS9USOB/TiY1uMspwTiVBwBRO/794lY8nH53rna8NNr8+D/7vcpCCHkOOuQiEtfQlME e9xQ== MIME-Version: 1.0 X-Received: by 10.129.36.14 with SMTP id k14mr32305213ywk.64.1437478212952; Tue, 21 Jul 2015 04:30:12 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 21 Jul 2015 04:30:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2015 04:30:12 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 11:30:15 -0000 On 21 July 2015 at 04:12, Eric Rescorla wrote: > > Yes, that's an issue. Not entirely sure what to do about other than > have the server provide its negotiation preferences out of band > in that case. I think that we could handle that at the point we define an out-of-band configuration priming mechanism. I don't think we need a full negotiation model for the server. A simple option would list the server's preference order for suites and so forth in its configuration advertisement; the client would then pick from that. From nobody Tue Jul 21 04:32:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2AA1A01F7 for ; Tue, 21 Jul 2015 04:32:23 -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 ViYIZ914fdM4 for ; Tue, 21 Jul 2015 04:32:22 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A9A1A01C6 for ; Tue, 21 Jul 2015 04:32:21 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so52644528wic.1 for ; Tue, 21 Jul 2015 04:32:20 -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=8GKBw6B86qCBPuFyTXvQ7ttATNQ00nupk+QqFs6aQvI=; b=CnUAFu9trulV+LKj7AQpXCFJgXwD1w8evpfn2TiKxAFjShjq6HcnIn6+K1lYfHO5bO 4L8g+KhjfS115/Zr8k5zCurwwpkebkxctceB50tcTpl7uPPXoe504vcmzv1N2SXf/V9z oHOdTosGuzxN5IQCsqyUjCk/agi8V6x+dddjox98m6u6ijBohjMk1IifVn6N8CEM7k58 TZ5qzdkLHaX+sENfcORWUcX+RqqcknWlXPYZkirDLvLMep2PdKyxjI8cljWAPrfLLm0s LrN+OdjwRVoqOAU6crclqUnfEXD9cTnYovZMMd7cBTeH7JIzaPLXxvkABcaqcRVuvnXv E7EQ== X-Gm-Message-State: ALoCoQkk7B7iZdnVIr55c5dzOaM6bqSal7Jhs80XfOjhfeJSMO/wDt2pEXp2LfedJTsVTie5/dJg X-Received: by 10.194.158.42 with SMTP id wr10mr64678274wjb.81.1437478340575; Tue, 21 Jul 2015 04:32:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 04:31:41 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 21 Jul 2015 13:31:41 +0200 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e013c6478dcd2c2051b610160 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 11:32:23 -0000 --089e013c6478dcd2c2051b610160 Content-Type: text/plain; charset=UTF-8 Yeah, or it could just have the semantics "this is my most preferred configuration and if you send me anything compatible with it, I will pick it" -Ekr On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson wrote: > On 21 July 2015 at 04:12, Eric Rescorla wrote: > > > > Yes, that's an issue. Not entirely sure what to do about other than > > have the server provide its negotiation preferences out of band > > in that case. > > I think that we could handle that at the point we define an > out-of-band configuration priming mechanism. I don't think we need a > full negotiation model for the server. A simple option would list the > server's preference order for suites and so forth in its configuration > advertisement; the client would then pick from that. > --089e013c6478dcd2c2051b610160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, or it could just have the semantics "this is my= most preferred
configuration and if you send me anything compatibl= e with it, I will
pick it"

-Ekr


On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
On 21 July 2015 at 04:12, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, that's an issue. Not entirely sure what to do about other tha= n
> have the server provide its negotiation preferences out of band
> in that case.

I think that we could handle that at the point we define an
out-of-band configuration priming mechanism.=C2=A0 I don't think we nee= d a
full negotiation model for the server.=C2=A0 A simple option would list the=
server's preference order for suites and so forth in its configuration<= br> advertisement; the client would then pick from that.

--089e013c6478dcd2c2051b610160-- From nobody Tue Jul 21 05:41:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F1A1A1AA7 for ; Tue, 21 Jul 2015 05:41:14 -0700 (PDT) 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 GjGN2KJrjjm2 for ; Tue, 21 Jul 2015 05:41:12 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAA61A0191 for ; Tue, 21 Jul 2015 05:41:12 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 6CB911A276A; Tue, 21 Jul 2015 15:41:10 +0300 (EEST) Date: Tue, 21 Jul 2015 15:41:10 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150721124110.GA20920@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: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 12:41:14 -0000 On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote: > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson > wrote: > > > On 21 July 2015 at 04:12, Eric Rescorla wrote: > > > > > > Yes, that's an issue. Not entirely sure what to do about other than > > > have the server provide its negotiation preferences out of band > > > in that case. > > > > I think that we could handle that at the point we define an > > out-of-band configuration priming mechanism. I don't think we need a > > full negotiation model for the server. A simple option would list the > > server's preference order for suites and so forth in its configuration > > advertisement; the client would then pick from that. > > > Yeah, or it could just have the semantics "this is my most preferred > configuration and if you send me anything compatible with it, I will > pick it" What cipher this is about? The cipher used for protecting 0RTT/Early handshake data? The cipher used for protecting main connection? For main connection, the server can pick from ciphersuites advertized by client (assuming client gives ciphers that are acceptable and are usable with configurations, i.e. GDHE_CERT-type things). For 0-RTT/Early handshake data you want cipher that the server supports and accepts. If it is about this, there could be multiple allowed ciphers. -Ilari From nobody Tue Jul 21 05:56:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71341A7017 for ; Tue, 21 Jul 2015 05:56:16 -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 tuf-x_cLt_UY for ; Tue, 21 Jul 2015 05:56:14 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6919F1A1B4B for ; Tue, 21 Jul 2015 05:56:14 -0700 (PDT) Received: by wibud3 with SMTP id ud3so126650268wib.0 for ; Tue, 21 Jul 2015 05:56:13 -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=K+HTUQvEnjCyHASrpGJyRKbzilJDNnk08SQJQxDLxos=; b=bCV+qCpN4TmrJ539RvGewXGMdcobf7I+MhaqFy7Y4muW9hPK3DbEgbx09nTg+Xuhwp XhdTtFFd0cJ2CX/enyZ03lbqI5Sv3tdKRL2lDrcib3qIj8n41M/tiYt9ldPAJxDG7Tz5 UPPzHTZuVV4jIEn+ePL2wXO1wZ0GKUuNMjI2M4VnCTtQVSvpl02bpj5fHTt9KuGkh8IJ 5LQzcFOBYo7TSzlCTZer8xXjeILOe0XhtbfVcnd9cGr6AMxeTvgujvi3Eaex3vpvcUCM O4MRfVSO05O1CJqdvqXU80K20Y4wMpi2Hsu2sIRmOl53IfLLY30MM7ml4DnUqoHl1+ze M9SA== X-Gm-Message-State: ALoCoQkqUPanxhcJnoKOtSULODKFfoh2012fHpWHGH53ITV6rMFlOrNWN/+IDOHJ5YwQmLLa9fcj X-Received: by 10.180.208.114 with SMTP id md18mr31691736wic.31.1437483373103; Tue, 21 Jul 2015 05:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 05:55:33 -0700 (PDT) In-Reply-To: <20150721124110.GA20920@LK-Perkele-VII> References: <20150721124110.GA20920@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 21 Jul 2015 14:55:33 +0200 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c37eb8d32aca051b622dab Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 12:56:16 -0000 --001a11c37eb8d32aca051b622dab Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote: > > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > > > > > On 21 July 2015 at 04:12, Eric Rescorla wrote: > > > > > > > > Yes, that's an issue. Not entirely sure what to do about other than > > > > have the server provide its negotiation preferences out of band > > > > in that case. > > > > > > I think that we could handle that at the point we define an > > > out-of-band configuration priming mechanism. I don't think we need a > > > full negotiation model for the server. A simple option would list the > > > server's preference order for suites and so forth in its configuration > > > advertisement; the client would then pick from that. > > > > > Yeah, or it could just have the semantics "this is my most preferred > > configuration and if you send me anything compatible with it, I will > > pick it" > > What cipher this is about? The cipher used for protecting 0RTT/Early > handshake data? The cipher used for protecting main connection? > The former. For main connection, the server can pick from ciphersuites advertized > by client (assuming client gives ciphers that are acceptable and > are usable with configurations, i.e. GDHE_CERT-type things). > Agreed. > For 0-RTT/Early handshake data you want cipher that the server > supports and accepts. If it is about this, there could be multiple > allowed ciphers. > In principle this is true. However, there are two complications, ISTM: 1. The client has no way of knowing which ciphers the server would support other than the one it negotiated with the client previously (assuming in-band) 2. I'm trying to avoid questions about the security of the negotiation for the 0-RTT data, and we already have negotiated parameters. I haven't done any analysis of what happens if the server doesn't check that it would negotiate the parameters that the client provides. That might be fine, but I'm trying to be conservative. Thanks, -Ekr --001a11c37eb8d32aca051b622dab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
O= n Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> > On 21 July 2015 at 04:12, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > Yes, that's an issue. Not entirely sure what to do about= other than
> > > have the server provide its negotiation preferences out of b= and
> > > in that case.
> >
> > I think that we could handle that at the point we define an
> > out-of-band configuration priming mechanism.=C2=A0 I don't th= ink we need a
> > full negotiation model for the server.=C2=A0 A simple option woul= d list the
> > server's preference order for suites and so forth in its conf= iguration
> > advertisement; the client would then pick from that.
> >
> Yeah, or it could just have the semantics &quo= t;this is my most preferred
> configuration and if you send me anything compatible with it, I will > pick it"

What cipher this is about? The cipher used for protecting 0RTT/Early=
handshake data? The cipher used for protecting main connection?

The former.


For main connection, the server can pick from ciphersuites advertized
by client (assuming client gives ciphers that are acceptable and
are usable with configurations, i.e. GDHE_CERT-type things).

Agreed.

=C2=A0
For 0-RTT/Early handshake data you want cipher that the server
supports and accepts. If it is about this, there could be multiple
allowed ciphers.

In principle this is t= rue. However, there are two complications, ISTM:

1= . The client has no way of knowing which ciphers the server would support
other than the one it negotiated with the client previously (assum= ing in-band)

2. I'm trying to avoid questions = about the security of the negotiation for the
0-RTT data, and we = already have negotiated parameters.

I haven't = done any analysis of what happens if the server doesn't check
that it would negotiate the parameters that the client provides. That migh= t
be fine, but I'm trying to be conservative.

<= /div>
Thanks,
-Ekr

--001a11c37eb8d32aca051b622dab-- From nobody Tue Jul 21 06:08:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5F01A87B3 for ; Tue, 21 Jul 2015 06:08:58 -0700 (PDT) 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 cB4hxvt5JCo9 for ; Tue, 21 Jul 2015 06:08:57 -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 13C9C1AD0C9 for ; Tue, 21 Jul 2015 06:08:53 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id AA1441888FD; Tue, 21 Jul 2015 16:08:50 +0300 (EEST) Date: Tue, 21 Jul 2015 16:08:50 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150721130850.GA21741@LK-Perkele-VII> References: <20150721124110.GA20920@LK-Perkele-VII> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 13:08:59 -0000 On Tue, Jul 21, 2015 at 02:55:33PM +0200, Eric Rescorla wrote: > On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > For 0-RTT/Early handshake data you want cipher that the server > > supports and accepts. If it is about this, there could be multiple > > allowed ciphers. > > > > In principle this is true. However, there are two complications, ISTM: > > 1. The client has no way of knowing which ciphers the server would support > other than the one it negotiated with the client previously (assuming > in-band) Well, if it is about supported ciphers, there could be multiple, and the proposal has slot for only one. > 2. I'm trying to avoid questions about the security of the negotiation for > the 0-RTT data, and we already have negotiated parameters. Can you give some examples of such questions? > I haven't done any analysis of what happens if the server doesn't check > that it would negotiate the parameters that the client provides. That might > be fine, but I'm trying to be conservative. I think it would either work fine (client picks something server supports/ accepts) or it would not work at all (client picks some unknown cipher). -Ilari From nobody Tue Jul 21 06:28:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9851B2BA6 for ; Tue, 21 Jul 2015 06:28:04 -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 8O48gfthR6ZN for ; Tue, 21 Jul 2015 06:28:02 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837651B2B39 for ; Tue, 21 Jul 2015 06:28:02 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so57146319wib.1 for ; Tue, 21 Jul 2015 06:28:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=V1cFYJu3uQ6R8D0tIqcey37DSOq8VH/5HBxipPQCF08=; b=NMFd4D/GquS3ni0PmGQpeA490I1rqeoV3MBxBn2XO6Plz9wp0K4DGrowRs8HpghRjs KkmmdLtN02dC/BKp6YMOAB+K0w5gWQs1MOj4WzYEzbY6HpDmLOS+uuDUOdK9N0un1mYT PPDMvBQ/0DVxyZlSPEx8l2KQFU6NmA17aIhft8na9gmh0tbvnS1G/aCQyCTlq6v0LMeN XVahFA3IbtZIPqB6hxjndZplEHhcfcn9X009/rPoq06W68DfJs3H7nOKeflaWZuyX4XN PRyajxo2kNbDs/39ogc39XvHnFoKDWtWg8lA6JygSBZnAHvgSWpi8piNQPoO+h8/SgfF JOdg== X-Gm-Message-State: ALoCoQnldm8CKTnhQ7Xb9OxSC6n9cWvNmes7govbbz6vllVj9SrE6Pa7Mus06S04FYQQnOueMxrz X-Received: by 10.180.83.101 with SMTP id p5mr32147511wiy.52.1437485281310; Tue, 21 Jul 2015 06:28:01 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:a5e5:419:248c:bf99? ([2001:67c:370:176:a5e5:419:248c:bf99]) by smtp.gmail.com with ESMTPSA id v20sm37085677wjw.17.2015.07.21.06.27.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 06:28:00 -0700 (PDT) From: Michael StJohns To: msj@nthpermutation.com, cfrg@irtf.org, "tls@ietf.org" Message-ID: <55AE48E7.8080104@nthpermutation.com> Date: Tue, 21 Jul 2015 09:28:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Fwd: I-D Action: draft-stjohns-kdf-with-assignment-00.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, 21 Jul 2015 13:28:04 -0000 On 7/21/2015 9:21 AM, Michael StJohns wrote: FYI - This is my long delayed KDF document. I think its late enough that it isn't a useful submission for TLS1.3, but I would appreciate any feedback on it. It may eventually be useful for the next group of protocol revisions. Thanks - Mike > > >> From: internet-drafts@ietf.org >> To: >> Subject: I-D Action: draft-stjohns-kdf-with-assignment-00.txt >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Key Derivation Functions with Assignment >> Author : Michael C StJohns >> Filename : draft-stjohns-kdf-with-assignment-00.txt >> Pages : 20 >> Date : 2015-07-21 >> >> Abstract: >> This document describes a key derivation function (KDF) wrap-around >> or a meta-KDF that's designed to mix in key assignment parameters to >> the key stream generation phase. This allows a security module to >> rely upon and enforce the key assignment parameters during the >> assigment of key material from the generated key stream to the >> cryptographic objects. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-stjohns-kdf-with-assignment/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-stjohns-kdf-with-assignment-00 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From nobody Tue Jul 21 06:38:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A06C1A8764 for ; Tue, 21 Jul 2015 06:38:30 -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 Vx-DYV9YAYlo for ; Tue, 21 Jul 2015 06:38:29 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99661B2DC3 for ; Tue, 21 Jul 2015 06:38:28 -0700 (PDT) Received: by ykax123 with SMTP id x123so165854953yka.1 for ; Tue, 21 Jul 2015 06:38:28 -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=k5sof5j2bffa2+TELve4Ws/e2fcAwE+444GiShC+qaI=; b=BoatQ2eOZgF3QuWqYIoBHusZ1yS2Jf46uUZKNpdytdtpy6MV6ylFQIN50iLl80uPnm wOEKtrSbUWYVtKg1pnWsmRnATQ6NTYpfnbD5INqIp60cV25N5nimnpBY5Jp8dMtC1FoJ cCp8zgP948ZmHfQyFR/Jtwzv4MxAlU7FMeZdnKzsHEE3B87EMODMcszBRd8XLOWaOEg8 SBUIk2wGQFwt5Ss2h2QqMzfgRS0XnowLD6ZpZRXp4bQfa7iszkWwjDOYJ6BtJecMjp5J vWqzmn8mzCLUjwS3f4BC3VMgtXVVWFhBaYcXvzT0fhO6VyMH39Wg8M8fNGRK/DMOyYao fggQ== MIME-Version: 1.0 X-Received: by 10.129.103.84 with SMTP id b81mr33693208ywc.55.1437485908374; Tue, 21 Jul 2015 06:38:28 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 21 Jul 2015 06:38:28 -0700 (PDT) In-Reply-To: <20150721130850.GA21741@LK-Perkele-VII> References: <20150721124110.GA20920@LK-Perkele-VII> <20150721130850.GA21741@LK-Perkele-VII> Date: Tue, 21 Jul 2015 06:38:28 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 13:38:30 -0000 On 21 July 2015 at 06:08, Ilari Liusvaara wrote: > Well, if it is about supported ciphers, there could be multiple, and > the proposal has slot for only one. The proposal is for what the client selects and uses for its first flight. From nobody Tue Jul 21 07:16:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E24E1B2D95 for ; Tue, 21 Jul 2015 07:16:08 -0700 (PDT) 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 o_YsR1wS4xhZ for ; Tue, 21 Jul 2015 07:16:06 -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 8F1521B2D7B for ; Tue, 21 Jul 2015 07:16:01 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id BE761188847; Tue, 21 Jul 2015 17:15:59 +0300 (EEST) Date: Tue, 21 Jul 2015 17:15:59 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150721141559.GA23844@LK-Perkele-VII> References: <20150721124110.GA20920@LK-Perkele-VII> <20150721130850.GA21741@LK-Perkele-VII> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 14:16:08 -0000 On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote: > On 21 July 2015 at 06:08, Ilari Liusvaara wrote: > > Well, if it is about supported ciphers, there could be multiple, and > > the proposal has slot for only one. > > The proposal is for what the client selects and uses for its first flight. Oh darn, mislooked what message it was. Also, with regard to ending 0RTT, even without encrypted content types. Either I am misunderstanding something, or: - Client: Send ClientHello. - Server: Read ClientHello. - Client: Send 0-RTT & client cert. - Server: Read 0-RTT & client cert. - Client: Wait for server reply. - Server: Wait for handshake message to end 0-RTT. *deadlock*. -Ilari From nobody Tue Jul 21 07:39:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFF11B2E9D for ; Tue, 21 Jul 2015 07:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 e7TloApWP9Rf for ; Tue, 21 Jul 2015 07:39:28 -0700 (PDT) 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 746451B2E99 for ; Tue, 21 Jul 2015 07:39:22 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 003401A0085 for ; Tue, 21 Jul 2015 16:39:05 +0200 (CEST) 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 Jd2UiXE4Eo1h for ; Tue, 21 Jul 2015 16:39:03 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id C898A1A007F for ; Tue, 21 Jul 2015 16:39:03 +0200 (CEST) Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 21 Jul 2015 16:39:18 +0200 Message-ID: <55AE5995.7060600@secunet.com> Date: Tue, 21 Jul 2015 16:39:17 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55A70C01.8010907@gmail.com> In-Reply-To: <55A70C01.8010907@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.212] Archived-At: Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 14:39:33 -0000 Rene Struik schrieb am 16.07.2015 um 03:42: > Dear colleagues: > > It seems prudent to keep some diversity of the gene pool and not only have curves defined over prime curves. Similarly, > one should perhaps have some diversity of gene pool criteria within the set of recommend curves and not only include > special primes. Should some problem with a particular subclass show up over time, one then at least has other classes > available. > > On a general note, I do not understand what is wrong with having a dictionary of curves that is well-specified, but > whose members are not all widely used. To my knowledge, having a dictionary does not force everyone to use every term in > this (mandatory vs. optional to implement vs. mandatory to use, etc.). > > If one follows the line of reasoning of some people on the mailing list earlier today, doesn't this also call into > question Brainpool curves, or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into question why one would > have a whole set of new DLP groups (which certainly cannot be widely used yet, since the ink to write the parameters > down is still wet). What about RSA-1024, etc.? > I absolutely back up this position. Currently, the TLS 1.3 draft only permits curves over special primes. It has become quite clear in the discussions in CFRG and at the NIST ECC workshop that some parties (major hardware manufacturers, certification bodies) prefer curves over random primes. And as Rene has pointed out, allowing both would also give more agility w.r.t potential future attacks on certain sub-classes. Why can't the draft just specify the curves that are MTI but allow (at least some) alternative options, instead of putting all our eggs in one basket? Johannes From nobody Tue Jul 21 07:47:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516851B2DD9 for ; Tue, 21 Jul 2015 07:47:09 -0700 (PDT) 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 nhxSxKDy62XO for ; Tue, 21 Jul 2015 07:47:07 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2011B2D03 for ; Tue, 21 Jul 2015 07:47:07 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id F3F9D1A2715; Tue, 21 Jul 2015 17:47:05 +0300 (EEST) Date: Tue, 21 Jul 2015 17:47:05 +0300 From: Ilari Liusvaara To: Johannes Merkle Message-ID: <20150721144705.GA24492@LK-Perkele-VII> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55A70C01.8010907@gmail.com> <55AE5995.7060600@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55AE5995.7060600@secunet.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 14:47:09 -0000 On Tue, Jul 21, 2015 at 04:39:17PM +0200, Johannes Merkle wrote: > > I absolutely back up this position. Currently, the TLS 1.3 draft only permits curves over special primes. It has become > quite clear in the discussions in CFRG and at the NIST ECC workshop that some parties (major hardware manufacturers, > certification bodies) prefer curves over random primes. And as Rene has pointed out, allowing both would also give more > agility w.r.t potential future attacks on certain sub-classes. I thought that Brainpool curves weren't removed (even if those aren't explicitly in), which are random prime curves. Also, the security of binary curves seems quite questionable. And I would expect that if more curves croak, either relatively few curves croak (in style of MOV or SASS), or almost everything croaks. -Ilari From nobody Tue Jul 21 08:10:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590161B2EE8 for ; Tue, 21 Jul 2015 08:10:45 -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 GLzrPk1KVLI2 for ; Tue, 21 Jul 2015 08:10:43 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBA21B2EF9 for ; Tue, 21 Jul 2015 08:10:12 -0700 (PDT) Received: by wgmn9 with SMTP id n9so159327825wgm.0 for ; Tue, 21 Jul 2015 08:10:11 -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=+bo/qxbU5pqidvg1ZLUbDn0lN5WWHKbfDu7gWKBFSXQ=; b=SQUlPHf6rU/hbfkNd3163PAZvR4Teiy/XDZTQxzxuQ0H+y3gQDG4ld/0t6IQSbSJ6o AgN5sx/FbIwOk07UC6OQfA5Fz6ZAT9YJNUGPBp2IJnufo6SxySwtclQWm9uDLZEqSIOO 2cnNgcAppTxKC/HjF7f+dhwf1au0w0EDTNvFCKub0dZ2sMOygq06PhI01CCIMAHuZ9AX 6GMthIfBWghHDKELWutJNbx10gSDEtWbBUX45InvpB5wQYMZb16fk7P3ai/1nF190ztu wk7llctAWPuLMOnUoaHzGsNKuzHuDcs5qw6UjpfYn/7LsK3jMULgvZ7nLy8Z/S7we6LT qghg== X-Gm-Message-State: ALoCoQkIJCVQPHoimiRqDcrkkGPTtXYPl6QvankEPnv3HmXjnbnDMsWXKnVYrCjQSdBbqc4hHlC0 X-Received: by 10.180.73.244 with SMTP id o20mr33075733wiv.31.1437491411240; Tue, 21 Jul 2015 08:10:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 08:09:31 -0700 (PDT) In-Reply-To: <20150721141559.GA23844@LK-Perkele-VII> References: <20150721124110.GA20920@LK-Perkele-VII> <20150721130850.GA21741@LK-Perkele-VII> <20150721141559.GA23844@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 21 Jul 2015 17:09:31 +0200 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d0435c06aef5a25051b640c78 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 15:10:45 -0000 --f46d0435c06aef5a25051b640c78 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote: > > On 21 July 2015 at 06:08, Ilari Liusvaara > wrote: > > > Well, if it is about supported ciphers, there could be multiple, and > > > the proposal has slot for only one. > > > > The proposal is for what the client selects and uses for its first > flight. > > Oh darn, mislooked what message it was. > > > Also, with regard to ending 0RTT, even without encrypted content > types. Either I am misunderstanding something, or: > > - Client: Send ClientHello. > - Server: Read ClientHello. > - Client: Send 0-RTT & client cert. > - Server: Read 0-RTT & client cert. > - Client: Wait for server reply. > - Server: Wait for handshake message to end 0-RTT. > *deadlock*. Is this the case where the server is accepting 0-RTT or rejecting it? -Ekr > > -Ilari > --f46d0435c06aef5a25051b640c78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara <ilari.liusvaara@e= lisanet.fi> wrote:
On Tue, Jul 21, 2015 at 06:38:28AM -0700, M= artin Thomson wrote:
> On 21 July 2015 at 06:08, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> > Well, if it is about supported ciphers, there could be multiple, = and
> > the proposal has slot for only one.
>
> The proposal is for what the client selects and uses for its first fli= ght.

Oh darn, mislooked what message it was.


Also, with regard to ending 0RTT, even without encrypted content
types. Either I am misunderstanding something, or:

- Client: Send ClientHello.
- Server: Read ClientHello.
- Client: Send 0-RTT & client cert.
- Server: Read 0-RTT & client cert.
- Client: Wait for server reply.
- Server: Wait for handshake message to end 0-RTT.
*deadlock*.

Is this the case where the serv= er is accepting 0-RTT or =C2=A0rejecting it?

-Ekr<= /div>

<= font color=3D"#888888">

-Ilari

--f46d0435c06aef5a25051b640c78-- From nobody Tue Jul 21 08:17:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7EA1B2F2B for ; Tue, 21 Jul 2015 08:17:57 -0700 (PDT) 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 UnN4yVTbvMKa for ; Tue, 21 Jul 2015 08:17:55 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A271A0252 for ; Tue, 21 Jul 2015 08:17:51 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 830D11A264F; Tue, 21 Jul 2015 18:17:49 +0300 (EEST) Date: Tue, 21 Jul 2015 18:17:49 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150721151749.GA24790@LK-Perkele-VII> References: <20150721124110.GA20920@LK-Perkele-VII> <20150721130850.GA21741@LK-Perkele-VII> <20150721141559.GA23844@LK-Perkele-VII> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 15:17:57 -0000 On Tue, Jul 21, 2015 at 05:09:31PM +0200, Eric Rescorla wrote: > On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > > Also, with regard to ending 0RTT, even without encrypted content > > types. Either I am misunderstanding something, or: > > > > - Client: Send ClientHello. > > - Server: Read ClientHello. > > - Client: Send 0-RTT & client cert. > > - Server: Read 0-RTT & client cert. > > - Client: Wait for server reply. > > - Server: Wait for handshake message to end 0-RTT. > > *deadlock*. > > > Is this the case where the server is accepting 0-RTT or rejecting it? Apparently, only for accepting case. (If the server rejects, it can reply immediately, avoiding this deadlock). -Ilari From nobody Tue Jul 21 08:22:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31F81A0252 for ; Tue, 21 Jul 2015 08:22:38 -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 yzanZ-g5_a0v for ; Tue, 21 Jul 2015 08:22:37 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312DE1B2F43 for ; Tue, 21 Jul 2015 08:21:13 -0700 (PDT) Received: by ykdu72 with SMTP id u72so168303654ykd.2 for ; Tue, 21 Jul 2015 08:21:12 -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=fQCm4lv5OuCLAIMr3r2Lrz5eh0ZS6YqcbvpAJiFoQHg=; b=NORzY3rq9OdV519d+jsDfEyRjEp0TvnG2oody5OFi6iyN4e0++QjWkPlxr5gW2AhOM qTYwfsIRaBe81Nh+ZpDuFPvg5U0XLhXlIWI3QCN+qP57QqCkbtky1KT36XB39jF4cWFC I9sWGuVyjkBMEqK7tPCOUBFDo7TcGvkIeGP/yyugOevec2BVdDLXz0xjFF6Dx1HZPG5i 8qycJnfOqkingqs+lxRW2arZlnFr0dYTEs3sTBqkpFYvA1Us5FfAPAiDa4hL5jh+HGPO DaGrfy2lYjCnDzPx1+70Wd4SL3oxIU6w+QP2WqlUvUQh223Bkzhk3CYVyJpN0eRcolnn 3lmw== MIME-Version: 1.0 X-Received: by 10.170.160.4 with SMTP id b4mr33849127ykd.26.1437492072527; Tue, 21 Jul 2015 08:21:12 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 21 Jul 2015 08:21:12 -0700 (PDT) In-Reply-To: <20150721151749.GA24790@LK-Perkele-VII> References: <20150721124110.GA20920@LK-Perkele-VII> <20150721130850.GA21741@LK-Perkele-VII> <20150721141559.GA23844@LK-Perkele-VII> <20150721151749.GA24790@LK-Perkele-VII> Date: Tue, 21 Jul 2015 08:21:12 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 15:22:39 -0000 On 21 July 2015 at 08:17, Ilari Liusvaara wrote: >> > *deadlock*. >> >> >> Is this the case where the server is accepting 0-RTT or rejecting it? > > Apparently, only for accepting case. > > (If the server rejects, it can reply immediately, avoiding this > deadlock). I don't think that this is a concern. You only have to say that the server should not wait for the 0-RTT data before continuing with the handshake. At some level, you can safely consider 0-RTT data as being streamable/equivalent to application data. From nobody Tue Jul 21 08:30:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC7B1A8A1F for ; Tue, 21 Jul 2015 08:30:22 -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 u_ZOfiXwTaWz for ; Tue, 21 Jul 2015 08:30:18 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2819C1A066C for ; Tue, 21 Jul 2015 08:30:18 -0700 (PDT) Received: by ykay190 with SMTP id y190so168501352yka.3 for ; Tue, 21 Jul 2015 08:30:17 -0700 (PDT) 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=USE61AowHuZBBv172zfl5qHgK6NRGQmgmi+Clwpff/w=; b=kpV8N5CCqI4HL7ZAQb+KAj8ilchB8x5TmxGMvfYbY/f9lpy7WMFIxI8WNZuVWM0h9+ BBx291KbNXTVtrjr/tR9gCQsUkAlXqqsY6FIUdncbH0Oy8o9oERCV6DnNZbPnpNVrrVg z3DYyjcpCEQ9VboZg9zuKNKcDxg73LzW9dOUb8qxrqKbSaCsJM+sqoW+UBltl9VkOL6Z zwh3Gs2hF1T4FjZh1cvysXzCFC6H5eiPK6S4Mx8wU1fcJDgpUP44aaAsFs2wHSdgWLKX ab9cXK3fswlddlQWN0mwKMgUFaLclTM/vZ09J/YkHT9rT6JeyjB8T3mncRrqM4Dc12jU KDqA== X-Received: by 10.129.74.135 with SMTP id x129mr34093934ywa.98.1437492617569; Tue, 21 Jul 2015 08:30:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id x22sm3428746ywd.46.2015.07.21.08.30.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 Jul 2015 08:30:17 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 21 Jul 2015 11:30:15 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55AE5995.7060600@secunet.com> <20150721144705.GA24492@LK-Perkele-VII> In-Reply-To: <20150721144705.GA24492@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507211130.15582.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 15:30:22 -0000 On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > I thought that Brainpool curves weren't removed (even if those aren't > explicitly in), which are random prime curves. > > Also, the security of binary curves seems quite questionable. Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited either. If there's no strong objection, I'd like to add them to the list, if just to document the current NamedGroup registry. I could add a recommendation to stick to standards track, for those worrying about them. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 Dave From nobody Tue Jul 21 09:05:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE911A8BBF for ; Tue, 21 Jul 2015 09:05:39 -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 aRGRuOWUDSlK for ; Tue, 21 Jul 2015 09:05:38 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC531A88BC for ; Tue, 21 Jul 2015 09:05:38 -0700 (PDT) Received: by ykay190 with SMTP id y190so169465430yka.3 for ; Tue, 21 Jul 2015 09:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=DRcWoAaIwzD8F8P03c2ryzXkvrh/stFstieWJjjnF5A=; b=y1vJQ7IZ/q4RywuvPYVM2rmH2eVFT0Gy7j1tzpqd8RF74wl9uTZ7imRrauws4No3PV 5okMzqOga46q1Ea6fslbNq4EJHY92JlmPom61O0kD+zitR2VmjpfbSmGBFXi+zP8RF+D vyFcRxs1Yglmy97t2Krzx8fnt8eY/JLRvk7Ea4kHRKW4Yp/dSFZBpF5/W/Hns2P4Ti8H 56Vo/S2UFjSQM1/ejOLhRe1HBojLv9Ymkl04d94tMNn7+fS2XEZlb9AorFSWPVc8UFAj 4FtHQLlRziHj9Nzuy7ZG1q6wgtmq++C/YTA3SGHhMbh6sJsvt/Yzm/Mp3RSthgvfOiqW Jv2w== X-Received: by 10.170.150.7 with SMTP id r7mr34467311ykc.48.1437494738118; Tue, 21 Jul 2015 09:05:38 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id i130sm23589324ywe.28.2015.07.21.09.05.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 Jul 2015 09:05:37 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Tue, 21 Jul 2015 12:05:36 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507211205.36675.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 16:05:40 -0000 On Tuesday, July 21, 2015 07:04:14 am Eric Rescorla wrote: > struct { > select (Role) { > case client: > opaque identifier<0..2^16-1>; > CipherSuite cipher_suite; // NEW > Extension extensions<0..2^16-1>; // NEW > > case server: > struct {}; > } > } KnownConfigurationExtension > > The server would just need one configuration for each public key and > woudldn't need to have any client-specific state. It also has the > benefit that it makes PSK work with 0-RTT. > > Thoughts? Improvements? A simple suggested improvement: name the fields clearly to indicate what they are. e.g. opaque server_configuration_identifier<0..2^16-1>; CipherSuite early_data_cipher_suite; Extension cached_server_extensions<0..2^16-1>; Use this same ID field name in ServerConfiguration. Also, why is this ID allowed to be so big? It's extreme overkill now that it's down to one config per pub key, with nothing client specific. It doesn't need a string with a 16-bit length; it barely needs a single 16-bit integer. Dave From nobody Tue Jul 21 10:20:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041081A0065 for ; Tue, 21 Jul 2015 10:20:39 -0700 (PDT) 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 IZ9t5TRMGXgd for ; Tue, 21 Jul 2015 10:20:37 -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 EAF901A1BCA for ; Tue, 21 Jul 2015 10:20:14 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id E8773188770; Tue, 21 Jul 2015 20:20:11 +0300 (EEST) Date: Tue, 21 Jul 2015 20:20:11 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150721172011.GA28095@LK-Perkele-VII> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55AE5995.7060600@secunet.com> <20150721144705.GA24492@LK-Perkele-VII> <201507211130.15582.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201507211130.15582.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 17:20:39 -0000 On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote: > On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > > I thought that Brainpool curves weren't removed (even if those aren't > > explicitly in), which are random prime curves. > > > > Also, the security of binary curves seems quite questionable. > > Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited either. > > If there's no strong objection, I'd like to add them to the list, if > just to document the current NamedGroup registry. I could add a > recommendation to stick to standards track, for those worrying about them. Related: There's the following draft: draft-iab-crypto-alg-agility (currently in IETF LC) which contains the following: 3.4 National Cipher Suites "The default server or responder configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required." While the thing is about cipher suites, it also goes for curves. Also, Brainpool is much slower than the special prime stuff, so I think the defaults should be high-performance where it is not known to hurt security. This could also be applied to some actual ciphersuite stuff, namely ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers). -Ilari From nobody Tue Jul 21 12:42:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09961B2B47 for ; Tue, 21 Jul 2015 12:42:45 -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 QKFtTUJmvJhF for ; Tue, 21 Jul 2015 12:42:44 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038531B2B45 for ; Tue, 21 Jul 2015 12:42:44 -0700 (PDT) Received: by wibud3 with SMTP id ud3so125733291wib.1 for ; Tue, 21 Jul 2015 12:42:42 -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=ntoaOsWaCPOYCpMmNgkKw+MVDkcBNV7GQ4h2BN+bVog=; b=fx3om59NGndSz4P02a8Bei+mKKoLWKgLpNnX+k4gz6Cm0gRBweD6wtvSE0FdCPSjzI WVudBRiBGrdfNbVzr8RFrQqiw0WGXVIS/fc9FeYRyquuqZ6zgyS9vzA2Ei2M8BHgmbvP hemeZdQIw0oWicXePm3GleyRIFFNVrnz6jvgJWi//u2by7LIfxZTOWfF8GurwqDMBovs nr46laeIVs/98JVJZduhFiwUX6/zqk32KzGY020hzmikmWK6v3zdPVoaM8b8WFAW4pTr 7dDAQxfldL46yIywGopi82YwABnZIG2okOn6neAOpUWbUqH58xJL+B+DDX++j9gbkSKr wcgA== X-Gm-Message-State: ALoCoQnN/1ggBITZd/MkREo6qHrLXAYHTgTjB83U2ZzKuVaIUgPTQ+JEfq0Tqy9tozJFhrHIg82A X-Received: by 10.194.158.42 with SMTP id wr10mr68634258wjb.81.1437507762761; Tue, 21 Jul 2015 12:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 12:42:03 -0700 (PDT) In-Reply-To: <20150721172011.GA28095@LK-Perkele-VII> References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp> <55AE5995.7060600@secunet.com> <20150721144705.GA24492@LK-Perkele-VII> <201507211130.15582.davemgarrett@gmail.com> <20150721172011.GA28095@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 21 Jul 2015 21:42:03 +0200 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e013c64788fcf50051b67db07 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 19:42:46 -0000 --089e013c64788fcf50051b67db07 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 7:20 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote: > > On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > > > I thought that Brainpool curves weren't removed (even if those aren't > > > explicitly in), which are random prime curves. > > > > > > Also, the security of binary curves seems quite questionable. > > > > Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited > either. > > > > If there's no strong objection, I'd like to add them to the list, if > > just to document the current NamedGroup registry. I could add a > > recommendation to stick to standards track, for those worrying about > them. > > Related: There's the following draft: draft-iab-crypto-alg-agility > (currently in IETF LC) which contains the following: > > 3.4 National Cipher Suites > > "The default server or > responder configuration SHOULD disable such algorithms; in this way, > explicit action by the system administrator is needed to enable them > where they are actually required." > > While the thing is about cipher suites, it also goes for curves. > > Also, Brainpool is much slower than the special prime stuff, > so I think the defaults should be high-performance where it is > not known to hurt security. > > > This could also be applied to some actual ciphersuite stuff, namely > ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers). I would be comfortable with taking a hard look at these. -Ekr --089e013c64788fcf50051b67db07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 21, 2015 at 7:20 PM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= span class=3D"">On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrot= e:
> On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote:
> > I thought that Brainpool curves weren't removed (even if thos= e aren't
> > explicitly in), which are random prime curves.
> >
> > Also, the security of binary curves seems quite questionable.
>
> Brainpool curves aren't in the TLS 1.3 draft, but they're not = prohibited either.
>
> If there's no strong objection, I'd like to add them to the li= st, if
> just to document the current NamedGroup registry. I could add a
> recommendation to stick to standards track, for those worrying about t= hem.

Related: There's the following draft: draft-iab-crypto-alg-agili= ty
(currently in IETF LC) which contains the following:

3.4 National Cipher Suites

"The default server or
responder configuration SHOULD disable such algorithms; in this way,
explicit action by the system administrator is needed to enable them
where they are actually required."

While the thing is about cipher suites, it also goes for curves.

Also, Brainpool is much slower than the special prime stuff,
so I think the defaults should be high-performance where it is
not known to hurt security.


This could also be applied to some actual ciphersuite stuff, namely
ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers).

I would be comfortable with taking a hard lo= ok at these.

-Ekr


--089e013c64788fcf50051b67db07-- From nobody Tue Jul 21 12:50:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB041B2B48 for ; Tue, 21 Jul 2015 12:50:19 -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 4eGNcbStbGPF for ; Tue, 21 Jul 2015 12:50:18 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90AC1A9043 for ; Tue, 21 Jul 2015 12:50:17 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so70551194wib.1 for ; Tue, 21 Jul 2015 12: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XV1lezY0YQV0zDB+3znaX6k5NXfr+XrCt1D7HT2MdJ8=; b=HnxUKaTAjgzaSqeO63ixj2zX5w/zoqoYVGEKsWPl4SewJ1nBQI6/N//Nt1pHmPGHpu +XaRBSefGCTS/SHg9z6uQZjAwm86VequaY1FsJYh7J0A+HmfNq8jF6c5jDtH2gkKDA8w Qkv5BDgp1krETBUEwV+EqpGtIrFIOxON8ecOkjxNc+/YMVQmmwibkAbKiFBmdyokFEh6 sT5PMPrd30cronpS6iBJ8iKzktpg8ZKT/gxjldEwcKhh09DwvsJiEEi85WbrR5AEfF7W xOWE6P3L9q77Z1Q4GcJvsGChMpzPrkVrhb4bVwUmMkW6sJT0m9ObkRZT4XpacqiK5HE1 +mNQ== X-Gm-Message-State: ALoCoQmaFOXYaGShH5ZAg/uoQuIgwQnl6fpEG7Ufcg1mDchqou+mC67xyChaU9+vaOVax/i7VnA/ X-Received: by 10.194.133.73 with SMTP id pa9mr69395045wjb.148.1437508216447; Tue, 21 Jul 2015 12:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 12:49:36 -0700 (PDT) In-Reply-To: References: <20150721124110.GA20920@LK-Perkele-VII> <20150721130850.GA21741@LK-Perkele-VII> <20150721141559.GA23844@LK-Perkele-VII> <20150721151749.GA24790@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 21 Jul 2015 21:49:36 +0200 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e011771a99a8454051b67f68a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiating with known_configuration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2015 19:50:19 -0000 --089e011771a99a8454051b67f68a Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 5:21 PM, Martin Thomson wrote: > On 21 July 2015 at 08:17, Ilari Liusvaara > wrote: > >> > *deadlock*. > >> > >> > >> Is this the case where the server is accepting 0-RTT or rejecting it? > > > > Apparently, only for accepting case. > > > > (If the server rejects, it can reply immediately, avoiding this > > deadlock). > > I don't think that this is a concern. You only have to say that the > server should not wait for the 0-RTT data before continuing with the > handshake. At some level, you can safely consider 0-RTT data as being > streamable/equivalent to application data. > This is what I have been assuming. -Ekr --089e011771a99a8454051b67f68a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 21, 2015 at 5:21 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 21 July 2015 at 08:17, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>> > *deadlock*.
>>
>>
>> Is this the case where the server is accepting 0-RTT or=C2=A0 reje= cting it?
>
> Apparently, only for accepting case.
>
> (If the server rejects, it can reply immediately, avoiding this
> deadlock).

I don't think that this is a concern.=C2=A0 You only have to say= that the
server should not wait for the 0-RTT data before continuing with the
handshake.=C2=A0 At some level, you can safely consider 0-RTT data as being=
streamable/equivalent to application data.

This is what I have= been assuming.

-Ekr

--089e011771a99a8454051b67f68a-- From nobody Tue Jul 21 19:02:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7AE1AC3ED for ; Tue, 21 Jul 2015 19:02:24 -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 CYlg1Hdft7TL for ; Tue, 21 Jul 2015 19:02:23 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9225A1AC3E5 for ; Tue, 21 Jul 2015 19:02:23 -0700 (PDT) Received: by ykdu72 with SMTP id u72so181441909ykd.2 for ; Tue, 21 Jul 2015 19:02:23 -0700 (PDT) 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=YxoF5dgGM4g+DjZuwRFjUbvw8YvT0beVNOOrRyro3Aw=; b=PlTRkRCrV6Kc8/KDefg7dm6hoqg2hJ6L7Jqf0k6gjX/vmsuAYdsZlYvaqzEpIymxtX i82sFTtyUrMiOaIhsXdsvmLjR1W8CNm/hQoFLZ9jAThpd40zJXJIa8xINYSA5m55fSLd cHZEQwqt5f0ifgGg/hidkUq6t3hjsw47+CDK/RtpIWjNGK2KBrxYrw7Tsw4ltxeLy082 ddmDI7uzMtWUKOqmGRdFca4zL879ZkvpEPBbEyK8wtIBuV+uJH9o2IVrZ1Qjyg4rLYmN XZ52x7kMIqNuKJuWGzrMyEsdv8zirsYsiRcHar3eaHrTPVOXhb+b4TTW59QGplM/u1Fy fcHA== X-Received: by 10.13.221.17 with SMTP id g17mr7228ywe.11.1437530543021; Tue, 21 Jul 2015 19:02:23 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id j127sm25117876ywd.51.2015.07.21.19.02.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 Jul 2015 19:02:22 -0700 (PDT) From: Dave Garrett To: "" Date: Tue, 21 Jul 2015 22:02:20 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201507191622.47921.davemgarrett@gmail.com> In-Reply-To: <201507191622.47921.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507212202.21120.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 02:02:25 -0000 I've updated the a la carte proposal again with some improvements to readability. I've also added in the ECDHE PSK cipher suites in the current draft, as they are required for this. current WIP text: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites diff from PR #201: https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Dave From nobody Wed Jul 22 01:36:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE1A1ACEB1 for ; Wed, 22 Jul 2015 01:36:15 -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 mnPU7O516YU4 for ; Wed, 22 Jul 2015 01:36:10 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B6D1ACD2C for ; Wed, 22 Jul 2015 01:36:01 -0700 (PDT) Received: by ykdu72 with SMTP id u72so186938247ykd.2 for ; Wed, 22 Jul 2015 01:36:01 -0700 (PDT) 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=PFBKLl+qWm3Csr1tZxwny1NtXlNI4jn+tVGLly41CNc=; b=0MnK0APEaLUB04e/Sl7srMXjQzv1T96+hB2bRvQntPukxFH8pszEIraPDa8el0f+9P DfAomHh9Z/825Z3+WHwAY7WqHFzv5dOIXiH+Lzfec5wr799pvR6oH/KaTfQTjST2mR0V /eHCOH2aRh9P+I5f+mZRsZagMHyzcm82zERkApcr+8eZCBxMUhGdjO0z1kFz2MNEf1aR wsrtrLlK1Icz6GyqBjVc6Qr+WbsgXby7PdzMV+NkMJ6V4DI95JaO9sRtCTBArnmyHqIY z9e9+BSeI61rWAP0RF6eFAeuCK97sN7S5Rp1p9Lt3QnuCmh5BjHudcF2OBzus7Ha+TyW w9NQ== MIME-Version: 1.0 X-Received: by 10.170.210.212 with SMTP id b203mr1250014ykf.110.1437554160347; Wed, 22 Jul 2015 01:36:00 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 01:36:00 -0700 (PDT) Date: Wed, 22 Jul 2015 01:36:00 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] 4492bis table 1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 08:36:16 -0000 Is table 1 correct? +-----------+-----+------------+ | Symmetric | ECC | DH/DSA/RSA | +-----------+-----+------------+ | 80 | 163 | 1024 | | 112 | 233 | 2048 | | 128 | 283 | 3072 | | 192 | 409 | 7680 | | 256 | 571 | 15360 | +-----------+-----+------------+ Aren't we dropping 571? Can we use values that match up. Or, drop the table. From nobody Wed Jul 22 01:45:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030A81A0211 for ; Wed, 22 Jul 2015 01:45:02 -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 MVjSeHN4VIJu for ; Wed, 22 Jul 2015 01:45:01 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901E81ACE3E for ; Wed, 22 Jul 2015 01:44:59 -0700 (PDT) Received: by ykax123 with SMTP id x123so187624358yka.1 for ; Wed, 22 Jul 2015 01:44:59 -0700 (PDT) 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=jjObl5+NgVc5+6lkbw++qzeExGHe2rkmq1MRqia9hgk=; b=q6BR3rxgjMLaQjxkovCaLkvpJvyxIEJh9Mz0VbtNxSHzWT7Ka2oSDIIJL+Rs17zpVA dAe6jEsLQRX6kaEU7Yut2AN14S4XSemUAc9sAsmPo/C7StY3VO0ET2yeycIRwZ00s4HA t3oZAgg+7EdcUV9kA7g/5dXgWvfbJm3SE6w2PelgE1Wc+pTpMSEqTpltEudyXvP+oXru CVM1YibsRNnlR/Yf7baONudTPWqwadG1eCax4GDWX0Aq8EKj2aaexJ6dF0x4N/ueOPn0 nh7Ctp65zjQyFC6bGeS/8A/bt8VN4r/RaGdeZf3cWQoiNwHTIZ+Dp2RnsqCNR7uN7sIO O5DQ== MIME-Version: 1.0 X-Received: by 10.129.93.136 with SMTP id r130mr1334031ywb.52.1437554699078; Wed, 22 Jul 2015 01:44:59 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 01:44:59 -0700 (PDT) Date: Wed, 22 Jul 2015 01:44:59 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 08:45:02 -0000 I have never understood why 4492 doesn't claim forward secrecy for ECDH_anon suites. Can someone explain why this doesn't have an 'E'? From nobody Wed Jul 22 01:50:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A667D1ACD71 for ; Wed, 22 Jul 2015 01:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 WlCqVAdzmqVa for ; Wed, 22 Jul 2015 01:50:10 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AD61ACD29 for ; Wed, 22 Jul 2015 01:50:09 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so153018836wib.0 for ; Wed, 22 Jul 2015 01:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rcoMoGH1rgM+SBt32sq1WQKATK0GnM6b9y0YpAeODeA=; b=nrzS2j24sOU2hfvq+YPlwU39m7bsAq9JUIZIiZuh3PkvIYC8Ef57BXPNYwNMSss25b ufC0TRJwa4iarFheptv/KYfzGRFbLc6zXoDPbQ/Ohzjiz1LixIiETpC7R91sfIDLe5kC FJlkXW7xph7T2TaDTPG80VF2gH1bcF3r79PVE= 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=rcoMoGH1rgM+SBt32sq1WQKATK0GnM6b9y0YpAeODeA=; b=R3Bv2uvUmzcytqY3kP0VKpDjPwU9YkP+XMmhLEZeqrRrAGzP3hvAqkLpmmhdklKlCI G750RPf1kiXkD90qfmFF3Njpk9itTOrTCGmjQ8rPnxQeYY4bpdcUNNVgAKR3/X9xeXhf YvxyG9YkxRF2cMwuvAIljWKhR67ZFY8IY2HVM0YkKEijtg1SHIHsTy6zmnPpJk7rcSx1 BM9QEGUuXckZz1tUiv/6xfuUFZ+e3wf3nZoRTDeOV1IKwhMLTcGv1Hn/7NNujKibCqUg j30euR+2eoPv2HUWRaQ5S9VUWHDML/s5px/PWD786rPHTR9n3+QMLOFkmcleHFrnynqJ ftyw== X-Gm-Message-State: ALoCoQnU851HZ7d+7F7A6A64vSVAtXIJwX0+SiW5Wz8TdAoFCd1FAqcZ7GlMFVT96ll5TeWdJpO1 MIME-Version: 1.0 X-Received: by 10.180.73.244 with SMTP id o20mr4364248wiv.31.1437555008431; Wed, 22 Jul 2015 01:50:08 -0700 (PDT) Received: by 10.28.88.66 with HTTP; Wed, 22 Jul 2015 01:50:08 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:e898:8358:a694:653c] In-Reply-To: <201507212202.21120.davemgarrett@gmail.com> References: <201506111558.21577.davemgarrett@gmail.com> <201507191622.47921.davemgarrett@gmail.com> <201507212202.21120.davemgarrett@gmail.com> Date: Wed, 22 Jul 2015 04:50:08 -0400 Message-ID: From: Kyle Rose To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 08:50:12 -0000 I'd like to see the bits of the cipher suite associated entirely with ephemeral data tied together roughly by security margin, to avoid combinations that don't make sense (e.g., straw men of RSA384 + AES256 or AES256 + CRC32). This means: the type/size of the (EC)DHE group and the symmetric cipher (and possibly the MAC, if it's anything other than "GCM"). So, you'd potentially have something like ECDHE256-AES256-GCM DHE2048-AES256-GCM DHE1536-AES128-GCM etc. The signature algorithm (ECDSA, RSA, etc.) would be entirely separate. This isn't like the old days when the RSA key was used to exchange the keys: in the FS world, RSA is never used for key agreement, so RSA/ECDSA is used only to authenticate the server and is therefore orthogonal to the cipher suite negotiated above... and it's also implicit from the set of certificates the server has available. This unfortunately means we can't really tie the signature security margin to the cipher suite (going back to the RSA384 straw man), but since it's a pre-existing credential nothing can be done by the client other than to hang up if it's spooked by that. To fix this, we'd really need to go down the road of specifying the key size in the cipher suite, e.g. RSA2048 or ECDSA25519, which I'm not sure anyone wants. Does anyone want that? I ask because there are a ton of servers with 1024-bit RSA keys negotiating AES256-GCM, which tells an attacker exactly what to focus on. (In theory: a tire iron is still probably faster than factoring RSA1024.) The nice thing about the above approach is that IMO it actually makes things simpler for an implementer: the cipher suite list becomes a lot smaller but still covers most of the options, avoiding the complexity of full a la carte, while the signature algorithm is implicit for the server. So, we're not at libsodium level of simplicity, but closer. The one thing I'm having trouble pinning down is PSK. I fear it's not a separate dimension, because it replaces both signature and KEX. Kyle From nobody Wed Jul 22 01:56:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69561ACF55 for ; Wed, 22 Jul 2015 01:56:49 -0700 (PDT) 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 Sq8JjQijAnOu for ; Wed, 22 Jul 2015 01:56:48 -0700 (PDT) Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57DD1ACF17 for ; Wed, 22 Jul 2015 01:56:45 -0700 (PDT) Received: from [31.133.180.42] ([31.133.180.42]) by p3plsmtpa08-09.prod.phx3.secureserver.net with id vLwc1q00L0vH0TB01LwhHo; Wed, 22 Jul 2015 01:56:45 -0700 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Wed, 22 Jul 2015 01:56:35 -0700 From: Peter Yee To: Martin Thomson , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] 4492bis table 1 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [TLS] 4492bis table 1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 08:56:49 -0000 The current recommendations in NIST SP 800-57 Part 1, Table 2 suggest that 256-bit symmetric strength is matched by ECC strength of 512+ bits. All of the ECC sizes given in Table 2 are slightly different than given below, and most are given as ranges, not single values. http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_gener al.pdf (see page 64) -Peter On 7/22/15, 1:36 AM, "TLS on behalf of Martin Thomson" wrote: >Is table 1 correct? > > +-----------+-----+------------+ > | Symmetric | ECC | DH/DSA/RSA | > +-----------+-----+------------+ > | 80 | 163 | 1024 | > | 112 | 233 | 2048 | > | 128 | 283 | 3072 | > | 192 | 409 | 7680 | > | 256 | 571 | 15360 | > +-----------+-----+------------+ > >Aren't we dropping 571? Can we use values that match up. > >Or, drop the table. > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Jul 22 02:16:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8851AD0A5 for ; Wed, 22 Jul 2015 02:16:45 -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 ZAPQgDyY065n for ; Wed, 22 Jul 2015 02:16:44 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E37C1ACEDF for ; Wed, 22 Jul 2015 02:16:44 -0700 (PDT) Received: by ykdu72 with SMTP id u72so187588459ykd.2 for ; Wed, 22 Jul 2015 02:16:43 -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=jhWk6QQKzceLaLpYyl6GSe8hGDNL+csJQcfTxMPh12w=; b=XUPphR/ivUk4j3bSmSv4mapjuBVA1hBDEbMqWUyTp3ejQDRYH6cqGliSZ5eJVi8mfY TIKkazsXFCDOe+IQse0ctRBqBvLwoALKFQDqftYxzJ0ntjl3ikurKYYQsns6sD7S+3bk 6ae8xeXSWlyIULhkEqcWcAR9McCpcWN3aPRSE67vCENi8pY3HloWOzfKvWUn0eDs04j9 NKG4Vpklu0BZZRPMW9gpeLkVs9uRRyOcyBMBdkpKpD5zPYcOZYatAUcmx+ZmGUZ0RqDa 92pHPGSbrEJP5BGXl4AFEg9SjysL/2Wxyqu0Ghaq9eacbMwKXEUxuta60JU+1OkPP2e7 KDCQ== MIME-Version: 1.0 X-Received: by 10.170.165.2 with SMTP id h2mr1381244ykd.1.1437556603717; Wed, 22 Jul 2015 02:16:43 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 02:16:43 -0700 (PDT) In-Reply-To: References: <201506111558.21577.davemgarrett@gmail.com> <201507191622.47921.davemgarrett@gmail.com> <201507212202.21120.davemgarrett@gmail.com> Date: Wed, 22 Jul 2015 02:16:43 -0700 Message-ID: From: Martin Thomson To: Kyle Rose Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 09:16:46 -0000 On 22 July 2015 at 01:50, Kyle Rose wrote: > I'd like to see the bits of the cipher suite associated entirely with > ephemeral data tied together roughly by security margin I've seen this argument several times, but there are reasons why you might want a non-homogenous strength profile. The argument for consistency is appealing, but given that the design of TLS is historically[1] vulnerable to the weakest *supported* algorithm as opposed to the weakest *used* algorithm, I am not concerned about ensuring consistency. [1] ... and likely in future, despite our best efforts > The one thing I'm having trouble pinning down is PSK. I fear it's not > a separate dimension, because it replaces both signature and KEX. Yes, this is a problem. I like to think of PSK as KEX with null auth. From nobody Wed Jul 22 02:23:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65B11AD0C0 for ; Wed, 22 Jul 2015 02:23:04 -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 MRszn-GYaAwg for ; Wed, 22 Jul 2015 02:23:01 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713C21A00AC for ; Wed, 22 Jul 2015 02:20:50 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so92385966wib.1 for ; Wed, 22 Jul 2015 02:20:49 -0700 (PDT) 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=APNR3YGu7gxAmZJrMacBBGSXVRSUARrSaSCw1yk6LU8=; b=cnOQ/Dz6fH/mTOx0/Cug1d/ULXmrPJhNKrKQYuH1twc1Q+SmQQ9jqpQPMFn5oh6iHt zG8wdhlugYScPj2isk41OzxaNv/iQ/URWUPW08V4pQIucg0Am8NnzHLlGdmF3O8njT8B n6CthlRRsoVeyI3t15RLlruHtJvQFDej7Fn2nq/i4sIfboHUVRG77vP63itJqS4N3CFa /HX9DQ01DyavZja8FSBIzguczldmh7Pl1LutkYNMLR5HWvoZCmu0mK/cVT3aSjHffCg+ uUelctGJxaG0RkgwPkxsH8Kt733Q9jVhBXUjP35LmFNk6WaC6Ba5v6jBL8QcaEdFN2Wt qfXg== X-Received: by 10.194.5.103 with SMTP id r7mr3012610wjr.47.1437556849239; Wed, 22 Jul 2015 02:20:49 -0700 (PDT) Received: from dhcp-b33a.meeting.ietf.org (dhcp-b33a.meeting.ietf.org. [31.133.179.58]) by smtp.gmail.com with ESMTPSA id ib9sm1393358wjb.2.2015.07.22.02.20.48 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 02:20:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Wed, 22 Jul 2015 11:20:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 09:23:04 -0000 On Jul 22, 2015, at 10:44 AM, Martin Thomson = wrote: > I have never understood why 4492 doesn't claim forward secrecy for > ECDH_anon suites. Can someone explain why this doesn't have an 'E=E2=80= =99? I wasn=E2=80=99t there for the original 4492, but I think it=E2=80=99s = because the old anonymous ciphersuites were called DH_anon (no E).=20 They both provide forward secrecy. Yoav= From nobody Wed Jul 22 02:23:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE761ACF09 for ; Wed, 22 Jul 2015 02:23:53 -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 waShEx-B-x1D for ; Wed, 22 Jul 2015 02:23:50 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83ECE1ACDAE for ; Wed, 22 Jul 2015 02:23:29 -0700 (PDT) Received: by ykax123 with SMTP id x123so188248030yka.1 for ; Wed, 22 Jul 2015 02:23:29 -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=ItAMiOCgmJNw0dt5RMtUwN5vTOdP11gbPnPFGPsw2WI=; b=iyVlVjWIs1X9smlmulwg6XvMWYkpSpJImCJFlc5svgU4U8ypVi29gWMjWlMawk6Vah +DBDU0ZhsKjGIytiY4p0SDRhTTeu5vDtsBlXZngQNU/7AqWfUdF5Mpmi0MRG2cR7KPYl sSavth+gA6Bt+/KTda5IwWpAhvFIfIrCjMuwEkaVxUEp+ZcngXIk/sI5/dc9RybaHfyQ Uv1vBHDuJCkuxg7i1+u8DntDFadZ8J8YRrSAMXcH8NaPFAyFrSfNqDCoxgJnqpJgyvci l2BDoGE72wYqdkt/XGm/OmjJ7CSc3gpSeUkmfDzmvJ+FiXVQrvcxffeBsxyaBwEoendz BJXg== MIME-Version: 1.0 X-Received: by 10.13.251.199 with SMTP id l190mr1442491ywf.148.1437557008986; Wed, 22 Jul 2015 02:23:28 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 02:23:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 02:23:28 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 09:23:53 -0000 On 22 July 2015 at 02:20, Yoav Nir wrote: > They both provide forward secrecy. The draft specifically excludes ECDH_anon from the following statement, implying otherwise: The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy. It might be a good idea to revise that. From nobody Wed Jul 22 02:29:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776781AD079 for ; Wed, 22 Jul 2015 02:29:50 -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 IEXj3DvxR3nM for ; Wed, 22 Jul 2015 02:29:49 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6171ACEBF for ; Wed, 22 Jul 2015 02:29:48 -0700 (PDT) Received: by wibud3 with SMTP id ud3so162923101wib.0 for ; Wed, 22 Jul 2015 02:29:47 -0700 (PDT) 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=d/ncUP7AIqLwNsEZVvBp5jqmbZXXMh+NqAXvpIWuIUY=; b=OkkKt3FNjey3x23RIsGmFTayRLYIwHuTHQP+x/+Cm70l/UVYG2H/U3IGAQuc0q6zJV pNao3k6LvEYHL8Eh0wKwxv4C7thQIlZwyxZHafcpZQmganVclm0cUnKhNO17kj+8U6xa Jsdg4itkCHLRwclEI7QRe4e27Xdu2tZzJlqpthCXbNU387OCosLcbhMyasXBnoItlO7O YARDajjLnmueagOqDQ+hTQVDJnCg27YsubYXJGzXRKpXmjV2aahbcUinbjcFPLEq6deP QuT6OIaLe/RH0J2fFKG71m8VKi1MI5TIqb0feHwZqHt5c49vnFULDeUvLh64SJkUhbaF 7TOg== X-Received: by 10.194.58.199 with SMTP id t7mr3275760wjq.45.1437557387577; Wed, 22 Jul 2015 02:29:47 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:8185:dc96:74af:5eec? ([2001:67c:370:176:8185:dc96:74af:5eec]) by smtp.gmail.com with ESMTPSA id eu2sm2423082wic.8.2015.07.22.02.29.45 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 02:29:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Wed, 22 Jul 2015 11:29:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 09:29:50 -0000 PR at = https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.= xml ? > On Jul 22, 2015, at 11:23 AM, Martin Thomson = wrote: >=20 > On 22 July 2015 at 02:20, Yoav Nir wrote: >> They both provide forward secrecy. >=20 > The draft specifically excludes ECDH_anon from the following > statement, implying otherwise: >=20 > The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide = forward > secrecy. >=20 > It might be a good idea to revise that. From nobody Wed Jul 22 02:30:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2DC1A0233 for ; Wed, 22 Jul 2015 02:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, 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 jxSbDdQ7tjWn for ; Wed, 22 Jul 2015 02:30:25 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37E61A887C for ; Wed, 22 Jul 2015 02:30:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,522,1432591200"; d="scan'208";a="171210736" Received: from unknown (HELO [172.20.10.5]) ([37.161.129.216]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2015 11:30:23 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Benjamin Beurdouche In-Reply-To: Date: Wed, 22 Jul 2015 11:30:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6270FF12-C208-4005-A267-AEB5AAA8BB01@inria.fr> References: To: Yoav Nir X-Mailer: Apple Mail (2.2102) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 09:30:27 -0000 >> I have never understood why 4492 doesn't claim forward secrecy for >> ECDH_anon suites. Can someone explain why this doesn't have an = 'E=E2=80=99? >=20 > I wasn=E2=80=99t there for the original 4492, but I think it=E2=80=99s = because the old anonymous ciphersuites were called DH_anon (no E).=20 >=20 > They both provide forward secrecy. This is very confusing =E2=80=A6 From nobody Wed Jul 22 02:31:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D901AC3E9 for ; Wed, 22 Jul 2015 02:31:48 -0700 (PDT) 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 Q6quHHP4m6Ru for ; Wed, 22 Jul 2015 02:31:46 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8735E1A887C for ; Wed, 22 Jul 2015 02:31:45 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 3A015901D9; Wed, 22 Jul 2015 12:31:43 +0300 (EEST) Date: Wed, 22 Jul 2015 12:31:43 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150722093143.GA7186@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <201507191622.47921.davemgarrett@gmail.com> <201507212202.21120.davemgarrett@gmail.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: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 09:31:48 -0000 On Wed, Jul 22, 2015 at 02:16:43AM -0700, Martin Thomson wrote: > On 22 July 2015 at 01:50, Kyle Rose wrote: > > I'd like to see the bits of the cipher suite associated entirely with > > ephemeral data tied together roughly by security margin > > I've seen this argument several times, but there are reasons why you > might want a non-homogenous strength profile. > > The argument for consistency is appealing, but given that the design > of TLS is historically[1] vulnerable to the weakest *supported* > algorithm as opposed to the weakest *used* algorithm, I am not > concerned about ensuring consistency. Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems like comparing apples, orangles, pears and kumquants. Even if the nominal strengths are the same, the scaling of strengths is going to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs. symmetric). > > The one thing I'm having trouble pinning down is PSK. I fear it's not > > a separate dimension, because it replaces both signature and KEX. > > Yes, this is a problem. I like to think of PSK as KEX with null auth. I think TLS has currently four non-obsolete key exchanges: - GDHE_CERT - GDHE_PSK - GDHE_anon - PSK (I couple things here because I think that decoupling those would lead to unacceptable interop problems). -Ilari From nobody Wed Jul 22 02:44:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A781A1A98 for ; Wed, 22 Jul 2015 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.094 X-Spam-Level: ** X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 NdhpZZ9lTtyk for ; Wed, 22 Jul 2015 02:44:20 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 8099C1A1A58 for ; Wed, 22 Jul 2015 02:44:19 -0700 (PDT) Received: (qmail 26385 invoked from network); 22 Jul 2015 09:44:39 -0000 Received: from unknown (HELO hyperelliptic.org) (131.155.71.33) by calvin.win.tue.nl with SMTP; 22 Jul 2015 09:44:39 -0000 Received: (qmail 14992 invoked by uid 1000); 22 Jul 2015 09:44:05 -0000 Date: Wed, 22 Jul 2015 11:44:05 +0200 From: Tanja Lange To: Martin Thomson Message-ID: <20150722094405.GD12152@cph.win.tue.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492bis table 1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 09:44:21 -0000 > Is table 1 correct? > > +-----------+-----+------------+ > | Symmetric | ECC | DH/DSA/RSA | > +-----------+-----+------------+ > | 80 | 163 | 1024 | > | 112 | 233 | 2048 | > | 128 | 283 | 3072 | > | 192 | 409 | 7680 | > | 256 | 571 | 15360 | > +-----------+-----+------------+ > > Aren't we dropping 571? Can we use values that match up. > > Or, drop the table. > >From all research I know the ECC numbers are larger than they should be. Breaking ECC (good curve etc.) with size ~2^n takes 2^{n/2} point additions. Breaking a cipher with m bits takes about 2^m cipher evaluations; usually some parts can be omitted. The difference for cryptographic sizes between one EC operation and a symmetric operation is somewhere around 2^3 to 2^5 depending on size. When attacking multiple symmetric keys at once security reduces faster than for ECC keys (k keys give factor k speedup for symmetric while giving a factor sqrt(k) speedup for ECC). In summary symmetric m corresponds to ECC with somewhat _less than_ 2m. The numbers listed in that table match up with NIST's Koblitz curves; the sizes were chosen because for those Koblitz curves of nearly prime order exist -- this is a rare property for Koblitz curves -- and not because that bit size is needed for other reasons. There are several proposals for matching key sizes, see http://www.keylength.com/ for an overview. I would go with +-----------+-------+------------+ | Symmetric | ECC | DH/DSA/RSA | +-----------+-------+------------+ | 80 | >=158 | 1024 | | 112 | >=221 | 2048 | | 128 | >=252 | 3072 | | 192 | >=379 | 7680 | | 256 | >=506 | 15360 | +-----------+--------+------------+ where the number in the ECC column refers to the bitlength of the prime order of the subgroup. This does not take into account that symmetric and DH are more weakened by multi-target attacks. I wouldn't haggle over a bit or two, but the previous table was certainly not reflective of ECC strength given all we know. All the best Tanja From nobody Wed Jul 22 03:27:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59CC1AD241 for ; Wed, 22 Jul 2015 03:27:33 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 38ARP4kzSTyg for ; Wed, 22 Jul 2015 03:27:28 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C25E1AD16B for ; Wed, 22 Jul 2015 03:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1437560848; x=1469096848; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sB3xcGlB3L2ctmun/t5ZrAZDs49BYKodOGixO33YiHA=; b=KEHCGhMLNwhpCrka5FkAbxUe+s8GGAq34D0dVFYDvu+FY02I0PsehVMF jPd256h4TohGXtWhXOxY7RCzkrb524iIAJAzBvi/W3dGkMQoSq3xS2Rt0 6llxQevZJLplePtW0RlIhlfxDQGhmIwXalw+j+W7yf5l7MqLxgtlKbh3x ycfq0HRVVfSMaRkgbQIfpO4wjmH3RxuP4E0MQN4jvLCvA04rQ9zSN4taB Voe0SylQHqVPQ55IkUSlFH4avIFrvnOupEnKi+PCSbJ/2+owxN6t1fo9g TEjEDRocLRX89WORiYxVslFn+FsNhtJPgVZwBThfcT/0uCRjsOYKsb5tt Q==; X-IronPort-AV: E=Sophos;i="5.15,522,1432555200"; d="scan'208";a="29939116" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 22 Jul 2015 22:27:24 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 22 Jul 2015 22:27:23 +1200 From: Peter Gutmann To: Ilari Liusvaara , Martin Thomson Thread-Topic: [TLS] A la carte handshake negotiation Thread-Index: AQHQwlRUbbvimOYW+0W0bK2NXNrprp3iW/eAgAAXkICAA4OIAIAAcfAAgAAHbYCAAAQxgIAA10qJ Date: Wed, 22 Jul 2015 10:27:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB068BE4@uxcn10-tdc05.UoA.auckland.ac.nz> References: <201506111558.21577.davemgarrett@gmail.com> <201507191622.47921.davemgarrett@gmail.com> <201507212202.21120.davemgarrett@gmail.com> , <20150722093143.GA7186@LK-Perkele-VII> In-Reply-To: <20150722093143.GA7186@LK-Perkele-VII> 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: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 10:27:34 -0000 Ilari Liusvaara writes:=0A= =0A= >Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems= =0A= >like comparing apples, orangles, pears and kumquants.=0A= >=0A= >Even if the nominal strengths are the same, the scaling of strengths is go= ing=0A= >to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH= vs.=0A= >symmetric).=0A= =0A= +1. It's just more numerology:=0A= =0A= (In case you're wondering why you shouldn't go straight to 2048 bits, thi= s=0A= is another piece of cryptographic numerology that arises from the confusi= ng=0A= idea of algorithm pairings, that every conventional encryption algorithm = or=0A= key size has to be somehow matched up to a public-key algorithm key size.= =0A= Since conventional encryption algorithms generally have the property that= =0A= every single bit added to the key doubles the work factor needed to break= it=0A= by brute force while public-key algorithms don't, this means that attempt= s=0A= to pair conventional-encryption with public-key sizes leads to insanely= =0A= large public keys as the conventional-encryption key sizes get larger.=0A= =0A= Using any known technology it's unlikely that humans can ever get beyond= =0A= about 2^^100 operations, which means that common key sizes of 112 bits=0A= (triple DES), 128 bits (AES), 192 bits (AES again), and 256 bits (yet mor= e=0A= AES, because you can never have too many key sizes) are all equally=0A= unbreakable, and yet the desire for algorithm pairing means that we're=0A= supposed to go to public-key sizes of 2048, 3072, 7680, and 15,360 bits= =0A= respectively for all of these equally-unbreakable conventional key sizes= =0A= ["Recommendations for Key Management --- Part 1: General", Elaine Barker,= =0A= William Barker, William Burr, William Polk and Miles Smid, NIST Special= =0A= Publication 800-57, 9 July 2012]. This is a good example of the strange= =0A= places that cryptographic numerology can lead you if you believe in it to= o=0A= fervently).=0A= =0A= So really the table of key sizes should be:=0A= =0A= Conventional RSA/DH=0A= --------------- ------=0A= 100 bits 1536 bits=0A= 112 (ie. > 100) 1536 bits=0A= 128 (ie. > 100) 1536 bits=0A= 192 (ie. > 100) 1536 bits=0A= 256 (ie. > 100) 1536 bits=0A= Anything > 100 1536 bits=0A= =0A= Peter.=0A= From nobody Wed Jul 22 04:09:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDECB1B2BCF for ; Wed, 22 Jul 2015 04:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 8Tdnbprgm6je for ; Wed, 22 Jul 2015 04:09:30 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653111B2A68 for ; Wed, 22 Jul 2015 04:09:26 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so158180265wib.0 for ; Wed, 22 Jul 2015 04:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PxzIABgYf/VtaPDUW6ujjhThK+aLGkyX7xXx/MC+ufM=; b=D8UZNsEnIdiZXSFqY9KJwYdbHvrjmQhS/izp4RyJE1I+JKuvGDNIVEFelKcJezCk24 5Ipol8RAp1MVWmxnDtEsjgPeGyQTq2K7+ZPh3Aa4nxRF62zxpBmy5hMcgnbEbn1McrFK Rr687YJXCgsvh3SoGAUJ6EUvN/ilF1K0gceKk= 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=PxzIABgYf/VtaPDUW6ujjhThK+aLGkyX7xXx/MC+ufM=; b=L6WcEJOZ5aYYvbAowfn90FgAjEFVCqbmmMjzSb/EsAFAcR2P4bJiEPuOc84SCTHvwH +kD6XZ265YQahmEAViyu7PZil8xmZZ5E9iaA1DDAShbvnsndU0drdCD4+S6Uyj3WYcHn JKYR6gy1PUoooenHW5QzqISw699Z60RFy5XB4+L7nwUhs1yxjDrZ9tycr3DwUBI6QFKS yqdjJhTH1e0KIc3/UPM0d0vxaU+bMvXDPPMMS8Z3sIVVQ6qlczV560aoI9gyhX4nRCfw ube9hU70roH+2/sL50dZij3nzDhkojPhD0uX/igxos5gs1roClgfInuFO13An8BuUCN8 ALOQ== X-Gm-Message-State: ALoCoQkmJ6BD09o/4uH/Sc1lU6Znb5a1oJD06ubADzdafXF93nsWHYhLfwBwxv5he/Mv2XCHZBx2 MIME-Version: 1.0 X-Received: by 10.180.208.114 with SMTP id md18mr40964694wic.31.1437563365131; Wed, 22 Jul 2015 04:09:25 -0700 (PDT) Received: by 10.28.88.66 with HTTP; Wed, 22 Jul 2015 04:09:24 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:40f1:60c1:3ca2:aeab] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB068BE4@uxcn10-tdc05.UoA.auckland.ac.nz> References: <201506111558.21577.davemgarrett@gmail.com> <201507191622.47921.davemgarrett@gmail.com> <201507212202.21120.davemgarrett@gmail.com> <20150722093143.GA7186@LK-Perkele-VII> <9A043F3CF02CD34C8E74AC1594475C73AB068BE4@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 22 Jul 2015 07:09:24 -0400 Message-ID: From: Kyle Rose To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 11:09:32 -0000 >>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems >>like comparing apples, orangles, pears and kumquants. >> >>Even if the nominal strengths are the same, the scaling of strengths is going >>to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs. >>symmetric). > > +1. It's just more numerology: In that case, we should dispense with any larger key sizes and recommend exactly one per algorithm, and vary only on algorithm. Adopting this would simplify things even further by reducing the cipher set list by an order of magnitude. Sadly, I'm guessing there are numerological requirements in various standards and regulations that make it necessary to keep both AES-128 and AES-256 around, for example. There are also a ton of existing 2048-bit RSA keys that aren't going anywhere for a while. I'm also skeptical of statements like "Using any known technology it's unlikely that humans can ever get beyond about 2^^100 operations", because that's true exactly up until it isn't. An open question is whether the innovation that undoes this will also subsume much larger keys. Kyle From nobody Wed Jul 22 04:36:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C841B2C05 for ; Wed, 22 Jul 2015 04:36:53 -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 DdGExyOjDKol for ; Wed, 22 Jul 2015 04:36:51 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D011A903F for ; Wed, 22 Jul 2015 04:36:50 -0700 (PDT) Received: by ykay190 with SMTP id y190so189776449yka.3 for ; Wed, 22 Jul 2015 04:36:50 -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=aC/EXne9ONFKQ6eqDSFFpoS73KxJSVbRKQHV/SaclyY=; b=xgMZhoB6iBiR90QJFUtGOBi6jNFD1FSG9JKDVbXBqLsft0XE9VtEFde7Ho8sbIsTrR XRzd3U5NMXnARBYQqbOlqnQ+GFmXkkWA9xZp5R0FBHd80mLENmPuHlrt2aa1CV4Jb4xm gptNButsnu8tFGSU/C+C/gyaewAwx8fN/O6d6Rrg0F3UWE1vAEoOyJ4rySsFLwlkJN2J Hzl1scf+eLKcAMdpqZzH/4dKlV13F/8H6a15Zz5MciG/oXXe/WOvdTj5rTHNaWRKHhUs CGNt6Hi6zBz3TIj7qoyRgkFkU4ppSMy5upWOk9zjMYjbzq96JkU0ewDu0zBHZOedVdbj 1tZA== MIME-Version: 1.0 X-Received: by 10.170.57.207 with SMTP id 198mr1893640ykz.118.1437565010459; Wed, 22 Jul 2015 04:36:50 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 04:36:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 04:36:50 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 11:36:53 -0000 On 22 July 2015 at 02:29, Yoav Nir wrote: > PR at https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml ? https://github.com/tlswg/rfc4492bis/pull/6 From nobody Wed Jul 22 04:45:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083891B2D49 for ; Wed, 22 Jul 2015 04:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 i09RkL62ysmE for ; Wed, 22 Jul 2015 04:45:22 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE0A1B2C40 for ; Wed, 22 Jul 2015 04:45:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mbw2l5yMYzD5f for ; Wed, 22 Jul 2015 13:45:19 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=onuuIETG X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id r33SiT1h7CS9 for ; Wed, 22 Jul 2015 13:45:19 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 22 Jul 2015 13:45:18 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A810C80042 for ; Wed, 22 Jul 2015 07:45:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437565517; bh=9GXeWoTvESzQV0TvzPex+JhLu4BhXNm9ZBeobKB+57w=; h=Date:From:To:Subject; b=onuuIETGY4lqvKhOOzGxItkoUzWKUNmc09VWen8Entv57yWhg9rjVX8nwBQBQD268 ffUP9jebfoTiXy3yrafO4uVEzBUPG3A3Vg+mEEzD1Us0d8lOeejfKT2SDW7nZSyL/7 txwvgJ6w/kP6grQprOD4oZDIKUjMQUZacmm6J2ag= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6MBjHLA003933 for ; Wed, 22 Jul 2015 07:45:17 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 22 Jul 2015 07:45:17 -0400 (EDT) From: Paul Wouters To: "" Message-ID: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [TLS] draft-shore-tks-dnssec-chains-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 11:45:28 -0000 I do like the dnssec-chain-extension. I think the server should stick to one chain, from the root to itself, so it does not have to deal with variable chain blobs per client. That will allow server code to stick to something like hourly regenerating the blob for use with all clients. I do strongly prefer the binary blob to be in raw dns format. That will make parsing easier with existing code, and over time we will not run into issues where dns libraries support newer algorithms but this specific dnssec parsing code isn't updated. The DNS answer packet format can contain many DNS records in the Additional Section, without requiring any new DNS data format (and note edns-query-chain also does not specify a new format). I would be fine with stating the order of the additional records should be top down, to make validation easier, although probably the TLSA record and RRSIG itself should appear in the DNS Answer Section. As for ekr's question on why not stuff this inside X.509, that would not be compatible with tls raw pulic keys that only contain a SBKI, and drag back into the protocol more ASN.1 parsing and containers. Paul From nobody Wed Jul 22 07:30:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8161B2B39 for ; Wed, 22 Jul 2015 07:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 Ugo-Y4X3p6CI for ; Wed, 22 Jul 2015 07:30:25 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0801A802A for ; Wed, 22 Jul 2015 07:30:25 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so105405680wib.1 for ; Wed, 22 Jul 2015 07:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=dkag3yTxcYhOPoiuDTaXQ9Iged9G8g3OlmS7AU+UQqk=; b=dDZ1w/Mj2OsS7dzIBI5svy5I8sH3epM2clL2cXlugdBQpXST2nvHDh2gLuExBR+WPO rjCG+7xBSBG+CKOXROgqZKFmsjY4HyqztVckK8MunLQBBp55HSAtF9Pb8hDRuuoQnovm mboHBhBa5O+qu4EKNTzSCQuT46VHYH7bIDkPo= 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=dkag3yTxcYhOPoiuDTaXQ9Iged9G8g3OlmS7AU+UQqk=; b=Qe+GWUDvglj9azfa6VwcauGcDqWBv5aSh5iuUL3iWa4pvlfvOxnMy3uRzbwtFXgbFc kVqZPouHtEwrKISEEj9RFf4xcgUCqmg+HPOvnFETBnvjSxPOA6B+ZtYtPlt4sUg/r7jY idlKld7eNzQZQiITUJWHHPgTg0XcMtrPICM7Lx2W9YwMNVXZZvJ8/O3OR2CEcSCiNHPH U2AWpkMWTutm+GAhEpDNqmczSFdwV/5XiVHiB8mDdIOE1menXdqr8rcULrcoGiGIk68v utBqnTZcjHdspWTA6Melt2MMOc5ogPrKSY6WvlWKzGjn+lAfQ6O47JIlvytKimmE88WI Mhjg== X-Gm-Message-State: ALoCoQlrzzFjlNpv9Q5GEl67iBXM13w0WjPHWMkkROGqIrrPra1u6vPzSm2KrxZb9UG5iyfd6TAR MIME-Version: 1.0 X-Received: by 10.194.185.8 with SMTP id ey8mr5750375wjc.118.1437575424107; Wed, 22 Jul 2015 07:30:24 -0700 (PDT) Received: by 10.28.88.66 with HTTP; Wed, 22 Jul 2015 07:30:24 -0700 (PDT) X-Originating-IP: [31.30.2.53] Date: Wed, 22 Jul 2015 10:30:24 -0400 Message-ID: From: Kyle Rose To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Remove signature algorithm from the cipher suite X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 14:30:27 -0000 How about removing the RSA/ECDSA from the cipher suite, and making the SigAlgs extension mandatory for connections requiring authentication? That halves the number of cipher suites and eliminates an unnecessary redundancy, while keeping the rest of the cipher suite negotiation logic intact. Kyle From nobody Wed Jul 22 09:41:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE861B2B3A for ; Wed, 22 Jul 2015 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 ZFCnmvaQTonu for ; Wed, 22 Jul 2015 09:41:48 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 61DFE1B2BAA for ; Wed, 22 Jul 2015 09:41:12 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUhB1q00F2NEPrz01UhBBg; Wed, 22 Jul 2015 18:41:11 +0200 Date: Wed, 22 Jul 2015 18:41:12 +0200 (CEST) From: Meetecho Team To: tls@ietf.org Message-ID: <637716982.3.1437583272792.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_110945054.1437583272789" Archived-At: Subject: [TLS] Meetecho recordings of TLS WG session X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 16:41:49 -0000 ------=_Part_2_110945054.1437583272789 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the TLS WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TLS In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_2_110945054.1437583272789-- From nobody Wed Jul 22 09:59:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F941A8AF0 for ; Wed, 22 Jul 2015 09:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 l5cEO36hSEAd for ; Wed, 22 Jul 2015 09:59:05 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpweb131.aruba.it [62.149.158.131]) by ietfa.amsl.com (Postfix) with ESMTP id A54FA1A89C4 for ; Wed, 22 Jul 2015 09:59:04 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd04.ad.aruba.it with bizsmtp id vUyb1q0092NEPrz01UycKY; Wed, 22 Jul 2015 18:58:36 +0200 Date: Wed, 22 Jul 2015 18:58:37 +0200 (CEST) From: Meetecho Team To: tls@ietf.org Message-ID: <330675554.17.1437584317186.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16_1949966003.1437584317184" Archived-At: Subject: [TLS] Meetecho recordings of TLS 2nd WG session X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 16:59:06 -0000 ------=_Part_16_1949966003.1437584317184 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the TLS 2nd WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TLS_II In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_16_1949966003.1437584317184-- From nobody Wed Jul 22 10:01:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDCE1A8711 for ; Wed, 22 Jul 2015 10:01:12 -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 BQTZX31aK8AR for ; Wed, 22 Jul 2015 10:01:10 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C9D1A1BC6 for ; Wed, 22 Jul 2015 10:01:10 -0700 (PDT) Received: by qged69 with SMTP id d69so76360433qge.0 for ; Wed, 22 Jul 2015 10:01:10 -0700 (PDT) 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=OmT3q2X0cyEpcxDrMLZlgzx2eibaRSypb0EQzmioS20=; b=Z0v1gQ9v/Da2xINz7XAeh8dPuMIIyEFfv9+SXmg5trFD0G7UeQWpRx8ExWrQGDPJWd +aTwQNRp68EyUFisf25HXYerh2eUGsIg5i0CJc1s+X7BUnHzRaZ7LrqQs6zexz0JfXPx PF6jyLD6bHvFARXy4sFu4IsyBp4euBhk93mDgSCRe/aQfGzGsgKxPO0szXqilzftblAQ CK8u161Hcl0uu+WEtuZasW6pD/wkEZIl6AO+RAkzXP/JyLfn1JRWw/eCYsln3Saxaxwc dTqUrxlQl9FwpbOorZ4xgiy72okwWSXppPvFIYFXPqODO0hv4d6eCrHFQ834iuVFawSU TJRQ== X-Received: by 10.55.48.133 with SMTP id w127mr5234524qkw.53.1437584470002; Wed, 22 Jul 2015 10:01:10 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id e78sm971653qhc.18.2015.07.22.10.01.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jul 2015 10:01:09 -0700 (PDT) From: Dave Garrett To: Kyle Rose Date: Wed, 22 Jul 2015 13:01:08 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507221301.08518.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Remove signature algorithm from the cipher suite X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 17:01:12 -0000 On Wednesday, July 22, 2015 10:30:24 am Kyle Rose wrote: > How about removing the RSA/ECDSA from the cipher suite, and making the > SigAlgs extension mandatory for connections requiring authentication? > That halves the number of cipher suites and eliminates an unnecessary > redundancy, while keeping the rest of the cipher suite negotiation > logic intact. This is already a part of the current a la carte proposal that's been under discussion. recent summary of changes: https://www.ietf.org/mail-archive/web/tls/current/msg17156.html current WIP text: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites diff from PR #201: https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Both the supported groups and signature algorithms extensions are mandatory in this proposal, and they are the sole methods to select key exchange and certificates, with the ECDHE_ECDSA prefix being essentially frozen for certificate authenticated cipher suites. Dave From nobody Wed Jul 22 10:07:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C421A8BAF for ; Wed, 22 Jul 2015 10:07:14 -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 0ba7I0JtKdiZ for ; Wed, 22 Jul 2015 10:07:13 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074D11A0110 for ; Wed, 22 Jul 2015 10:07:13 -0700 (PDT) Received: by qkfc129 with SMTP id c129so114507718qkf.1 for ; Wed, 22 Jul 2015 10:07:12 -0700 (PDT) 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=TG1bQIZDcfNpjZ9X6u/6f55H38wWDZaIiKyl2j+cnBU=; b=GnLdVEZNEUIsJPcsue5fiOuZxtwq4ofhIj/6DErNbrY6EfRCLYwbqeKWKkjXJUuJqO Oknw+7vmLjGAagx5uxaoz2mBCi9Nx3Y7EmJU9QbHdLMgSyUkw0DuZ6H0hC6w82FpE7Nm 12LvwR4eIXG6EdN9KJH/CZn2Cq2DXioWpTuUQU/30fozwTnj5glK88ld1/EZyyo9FslX kZlMT/P03HadspDZld06e0rUIIH4HP/E5/ukfWT01bW0aGv6uAkIsWLVDPj4QFIfyOWS XlEBkoQbyYK7uy7/toGoz+SdO4t0Ockj4B63wVXiAkHko7+WjRVTn0BdRn1jkNosHs72 XH+A== X-Received: by 10.55.25.131 with SMTP id 3mr5372045qkz.85.1437584832358; Wed, 22 Jul 2015 10:07:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id g81sm984302qhc.8.2015.07.22.10.07.11 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jul 2015 10:07:11 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Yoav Nir Date: Wed, 22 Jul 2015 13:07:09 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507221307.10279.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 17:07:14 -0000 On Wednesday, July 22, 2015 07:36:50 am Martin Thomson wrote: > On 22 July 2015 at 02:29, Yoav Nir wrote: > > PR at https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml ? > > https://github.com/tlswg/rfc4492bis/pull/6 Could the cipher suite names be officially changed to add the 'E' to them? It'd make things simpler to be consistent. e.g. TLS_ECDH_anon_WITH_AES_128_CBC_SHA => TLS_ECDHE_anon_WITH_AES_128_CBC_SHA Anon is ephemeral by nature, but putting the 'E' in there matches existing notation better. TLS 1.3 will be deprecating all ECDH in favor of ECDHE, so it would be nice to not have to always stick in side notes that ECDH_anon==ECDHE_anon. Dave From nobody Wed Jul 22 10:09:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B671B2B9B for ; Wed, 22 Jul 2015 10:09:13 -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 Y2YecLqFNzo5 for ; Wed, 22 Jul 2015 10:09:12 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842A51A8F46 for ; Wed, 22 Jul 2015 10:09:12 -0700 (PDT) Received: by ykdu72 with SMTP id u72so197881644ykd.2 for ; Wed, 22 Jul 2015 10:09:12 -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=j2ftsMjwTGYLa2nmunKgHN8vESq/vF1GIEiVAjBmT8E=; b=sHMp7dEwxLW5Xglv+0wIagKkR0ye2g6fkehxgvujQ9PDuXjomn2/fApbafxivhzpas +IBqt1/5cjuy17AuVmgH0lRCE2QAMl0oGzqW39wB85LVHg5sEUgL6Dx07auvf1+PWbWW dm7wNI1+Pl++EFg40riSixcNV1f1/f8pbhr9XA/dPRs/bKQiH64SLtbqjz577RvVKcxw zZofSXnO+0J8xKI6M00qmXbsODoLDUKkbGo/E77gBuwolxwHxXZ5kk6KoU3YhAXlob/U L+FpWnmBQrLL48ADNpcUbFk7w1MIDzq4+ipu5LeUrjlTO8Ki0FIXl6QBCRySTKUGx1Hp wj3A== MIME-Version: 1.0 X-Received: by 10.129.97.87 with SMTP id v84mr3579388ywb.56.1437584952009; Wed, 22 Jul 2015 10:09:12 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 10:09:11 -0700 (PDT) In-Reply-To: <201507221307.10279.davemgarrett@gmail.com> References: <201507221307.10279.davemgarrett@gmail.com> Date: Wed, 22 Jul 2015 19:09:11 +0200 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 17:09:13 -0000 On 22 July 2015 at 19:07, Dave Garrett wrote: > Could the cipher suite names be officially changed to add the 'E' to them? It'd make things simpler to be consistent. I'd be OK with that. I didn't do it in the PR, but would be happy to make a new one. From nobody Wed Jul 22 10:12:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B701B2BA4 for ; Wed, 22 Jul 2015 10:12:51 -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 ANSNqd4tb0w0 for ; Wed, 22 Jul 2015 10:12:50 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF071A8711 for ; Wed, 22 Jul 2015 10:12:49 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so107606415wic.1 for ; Wed, 22 Jul 2015 10:12:48 -0700 (PDT) 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=jEesyB2/PVJcz2QW3TwG4QU5MXZbdbz+taQQC00n1PA=; b=CcjxPP5RpDgf3UDHvybDczggG3VBb9m17E62njP0KayZJFusfgxDRtAbOFF9LIKTvP nZX/LbnPEg8Ox1Y6wkvjmefmq9HAu23OUzZvbTensnuUooW9CxexEY3PNEZwHpK4P7CP q2EklFTv7pDDNOuacxdYrhxgjreYyD7Vodr+ZGUiXyzZlVNRkelfw2jNPpR/mDoPJEPk K6HaxG2R9qyXs6B5Trcj3xttqKgPPSWZRiNWwE/9Dx92OXemHgqOi8I0I4G9SFbdkcPN v9d1K3cz9a8/ciDMclBTDf+7FeP5UX8rtEKHCbkXe7TTD95wKNOMIAYXFaZVutuq7ygo eb6Q== X-Received: by 10.180.24.198 with SMTP id w6mr7909702wif.49.1437585168669; Wed, 22 Jul 2015 10:12:48 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:c57a:9f1a:f0fb:dbd5? ([2001:67c:370:176:c57a:9f1a:f0fb:dbd5]) by smtp.gmail.com with ESMTPSA id x5sm4295874wif.21.2015.07.22.10.12.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 10:12:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Wed, 22 Jul 2015 19:12:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67B411CE-E6DD-4BC4-BEE5-1513C5C3D0AE@gmail.com> References: <201507221307.10279.davemgarrett@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 17:12:51 -0000 I=E2=80=99d like to hear from the chairs if it=E2=80=99s OK to rename = stuff in the IANA registry. That has some implications for implementations that use these names. Not to mention that the same issue applies to DH(E)_anon > On Jul 22, 2015, at 7:09 PM, Martin Thomson = wrote: >=20 > On 22 July 2015 at 19:07, Dave Garrett wrote: >> Could the cipher suite names be officially changed to add the 'E' to = them? It'd make things simpler to be consistent. >=20 > I'd be OK with that. I didn't do it in the PR, but would be happy to > make a new one. From nobody Wed Jul 22 10:16:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307ED1B2BC3 for ; Wed, 22 Jul 2015 10:16:26 -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 qAsNNXyHkQW7 for ; Wed, 22 Jul 2015 10:16:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA861A8711 for ; Wed, 22 Jul 2015 10:16:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AEE7C284B55; Wed, 22 Jul 2015 17:16:22 +0000 (UTC) Date: Wed, 22 Jul 2015 17:16:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150722171622.GH4347@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension 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, 22 Jul 2015 17:16:26 -0000 On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote: > I think the server should stick to one chain, from the root to itself, > so it does not have to deal with variable chain blobs per client. > That will allow server code to stick to something like hourly > regenerating the blob for use with all clients. >From the root to its own TLSA RRset, however, this can be complicated in the presence of CNAMEs: www.example.com. IN CNAME cdn.example.net. cdn.example.net. IN A 192.0.2.1 _443._tcp.cdn.example.net. IN CNAME _dane.example.net. _dane.example.net. IN TLSA 2 0 1 In this example, three leaf RRsets need to be verified back to the root (with notable overlaps in the chains): www.example.com. IN CNAME _443._tcp.cdn.example.net. IN CNAME _dane.example.net. IN TLSA How should these be organized? It seems to me that the immediate answer that gets the client going in the right direction is the first CNAME, which enables to construct the TLSA base domain, and then to follow the second CNAME to the ultimate TLSA RRset. Should everything other than the first CNAME be in additional records? Should all the above (with their RRSIGs) be in the answer section, with the union of the supporting DNSKEY/RRSIG/DS records as additional? I tried to ask a related question during the meeting, but bandwidth to explain the context was limited: Should proofs of non-delegation be included, to keep gTLDs and ccTLDs honest for some future CT for DNS? Specifically, suppose you see: _443._tcp.www.example.com. IN TLSA with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3 records that demonstrate that "example.com" (and www.example.com) are not delegated? (Such records might then be subject to "gossip" or related "transparency" counter-measures). > I do strongly prefer the binary blob to be in raw dns format. That > will make parsing easier with existing code, and over time we will > not run into issues where dns libraries support newer algorithms > but this specific dnssec parsing code isn't updated. I'm not sure what "algorithms" you have in mind? We should perhaps allow (even encourage) "compression" to reduce the payload size, this would require the client to "uncompress" (canonicalize) all the RRs before checking the RRsigs. Once canonicalized, DNSSEC signature checks don't care how the canonical forms of each RRset were constructed, and the wire form (which is not canonical) is not more compatible with new signature algorithms than any other representation. > As for ekr's question on why not stuff this inside X.509, that would not > be compatible with tls raw pulic keys that only contain a SBKI, and drag > back into the protocol more ASN.1 parsing and containers. This really can't go in the certificate, because then certificates would have to be updated as often as RRSIGS are regenerated. That seems exceedingly unlikely to be deployable. -- Viktor. From nobody Wed Jul 22 10:21:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7CE1B2C04 for ; Wed, 22 Jul 2015 10:21:03 -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 j25BKhgO5wT8 for ; Wed, 22 Jul 2015 10:21:02 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A041B2B80 for ; Wed, 22 Jul 2015 10:20:52 -0700 (PDT) Received: by ykfw194 with SMTP id w194so118038150ykf.0 for ; Wed, 22 Jul 2015 10:20:52 -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:content-transfer-encoding; bh=jkixpNuiIWz3SseuEtJDs3nP9LwlzLVE+ayHct3kuHI=; b=Y8AWzCT+cKrglKg4XhI4Il/fAGdajDkPrquduAZ0RdhhtUJO77Y7O1N2bkrXxlz0va Rpfzhel6ZZmdD8331laK2qL5GrFFeRs3sAiUl294dSFvg99rnxR0ONZx+UHqQRr2OI3L I1VAV4gLfwq/i/bRGVJ/M6dhF4wrd73H/neXVv+WjB1VqgQeJni8qMG1zeI+U5kAY4rL ViaOWvoqJTb+yw3JxxcUll4iSr3rZ7FKGWK0RMyBp9LQk47ZG2H7vUQJMnZuYsLv4982 lLsHn4zoJWxn/aE3IX3H5lO2uoMbWF81MAtwCBnccE0o5wo5Nyvdic2IY6pcVE5q4b+k O51g== MIME-Version: 1.0 X-Received: by 10.170.210.212 with SMTP id b203mr3609356ykf.110.1437585652170; Wed, 22 Jul 2015 10:20:52 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 10:20:52 -0700 (PDT) In-Reply-To: <67B411CE-E6DD-4BC4-BEE5-1513C5C3D0AE@gmail.com> References: <201507221307.10279.davemgarrett@gmail.com> <67B411CE-E6DD-4BC4-BEE5-1513C5C3D0AE@gmail.com> Date: Wed, 22 Jul 2015 19:20:52 +0200 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 17:21:03 -0000 On 22 July 2015 at 19:12, Yoav Nir wrote: > I=E2=80=99d like to hear from the chairs if it=E2=80=99s OK to rename stu= ff in the IANA registry. > > That has some implications for implementations that use these names. > > Not to mention that the same issue applies to DH(E)_anon I believe that renaming entries in the IANA registry is possible. I don't think that it affects implementations, though it might cause some minor usability issues if people attempt to configure them using the IANA names. From nobody Wed Jul 22 10:25:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE841ACDB3 for ; Wed, 22 Jul 2015 10:25:13 -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 s1u_RHzf8x0c for ; Wed, 22 Jul 2015 10:25:11 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35F81A8A1F for ; Wed, 22 Jul 2015 10:25:10 -0700 (PDT) Received: by qkdl129 with SMTP id l129so157627607qkd.0 for ; Wed, 22 Jul 2015 10:25:10 -0700 (PDT) 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=0DD+KBkv9gzP3sXVC5QMWK+GGL+pe8ZRVKrMdbU1Wlc=; b=F9jvC0P8plsys37y4fzYb4qEfmJ3oPvbqbM8z4ZaLuX+yeAvd4Y9b6YCAIwW7v5H84 37QSz9lJKLgz+8DobcK3AaX5P9qoJQV6cOz4UVo1kg53EB3I4ypYoswJValZXw2b1RRz GsCmriIeApYBnQlAKjsquLS91mgnp77AAJ4cIieS6WyZOamoQ43QLcWwYORhfL82AbBB tqUtOdz2zKopF3QsVtAm4tpQ//lWOCXaOh2Tt85XMFdLqP6rXPToppTt8WUKAmPpt82I fipuuRk64Xew7WrnPtOhBNxt0fw7RsFRFcj4DtgGqyiF8DDbQiz0Y/31dtnn3LT28nV6 lcFQ== X-Received: by 10.55.41.229 with SMTP id p98mr5184534qkp.99.1437585910269; Wed, 22 Jul 2015 10:25:10 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id h73sm1005274qkh.34.2015.07.22.10.25.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jul 2015 10:25:09 -0700 (PDT) From: Dave Garrett To: Martin Thomson Date: Wed, 22 Jul 2015 13:25:08 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <67B411CE-E6DD-4BC4-BEE5-1513C5C3D0AE@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507221325.08823.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 17:25:13 -0000 On Wednesday, July 22, 2015 01:20:52 pm Martin Thomson wrote: > I believe that renaming entries in the IANA registry is possible. Negotiated FFDHE is renaming an extension identifier in the IANA registry, so this is not an entirely new issue. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml Dave From nobody Wed Jul 22 11:35:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A271A3BA0 for ; Wed, 22 Jul 2015 11:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 2ESvGCH-Ad5Y for ; Wed, 22 Jul 2015 11:35:19 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id EDFB11A21B8 for ; Wed, 22 Jul 2015 11:35:18 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3653E16A59B; Wed, 22 Jul 2015 18:35:18 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1E28316A59F; Wed, 22 Jul 2015 18:35:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437590118; bh=7120h+0vTYr4bhD/wWquYQQOKz2RUnk9ag956o2wiOM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=APCKR6Zl8UsXDB9aweScvuSJjTgdS6yc8YdIlFPgYo4HGs0jyklV37LuPOpjBDKPW yqEosKC3yngsZaaFD5xzElxudEIiMTraW/A/xS7mMfL8SpIWb/wcJB9ZU0s36xDNoM f/37lfMn4fHSKx36s6cHCrUgvMzFZOURCIQstY7A= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 0E3ED980B0; Wed, 22 Jul 2015 18:35:18 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 22 Jul 2015 13:35:17 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Wed, 22 Jul 2015 13:35:17 -0500 From: "Salz, Rich" To: Martin Thomson , Dave Garrett Thread-Topic: [TLS] 4492 ECDH_anon Thread-Index: AQHQxFq3j8y9GhweGU6B7F15ZCvOJp3nin0AgAAAwQCAAAG/gIAAI4QAgABcS4CAAACRgP//xC6w Date: Wed, 22 Jul 2015 18:35:17 +0000 Message-ID: <5d9a2d44d61b41308612fb1b2f774a52@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201507221307.10279.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.153.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 18:35:21 -0000 > I'd be OK with that. I didn't do it in the PR, but would be happy to mak= e a > new one. Please do. From nobody Wed Jul 22 12:56:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7CF1ACEAF for ; Wed, 22 Jul 2015 12:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 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_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 h_0CLCqjjfhI for ; Wed, 22 Jul 2015 12:56:01 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D711ACEA4 for ; Wed, 22 Jul 2015 12:56:00 -0700 (PDT) Received: from pps.filterd (m0004077 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t6MJrYab030744 for ; Wed, 22 Jul 2015 12:56:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=jyVowcIbcksFqxbr18hLeZrXSrbbauDIS/hKaaYKNuQ=; b=WGZIfsriGXmWyHmpYb4OmMNlqRTGJyxWfYqBkZ2HX3zMnnKmd22FI/4XS1tZ+pkuyGil Y9k+GuR2GDWBsu3ekyB+5xHWr1hmeDu/r3mQ1dkJ0V5sYOAOIAL3us9ibZMuKSfIGgr5 JOrY0gqIGQpjuxt2Cjuf3rsY8kzlfpEe6/k= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1vtg0t0gcs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Jul 2015 12:56:00 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.114]) by PRN-CHUB12.TheFacebook.com ([fe80::ddee:413f:3120:8216%12]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 12:55:58 -0700 From: Blake Matheny To: "tls@ietf.org" Thread-Topic: Relative vs absolute ServerConfiguration.expiration_date Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dQ== Date: Wed, 22 Jul 2015 19:55:58 +0000 Message-ID: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [192.168.54.13] Content-Type: text/plain; charset="utf-8" Content-ID: <53085D9F55D9B24BB9D064544E52422A@fb.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-22_07:2015-07-22,2015-07-22,1970-01-01 signatures=0 Archived-At: Subject: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 19:56:02 -0000 T25lIG9mIHRoZSB0b3BpY3Mgb2YgZGlzY3Vzc2lvbiBhdCB0aGUgV0cgZGlzY3Vzc2lvbiB3YXMg d2hldGhlciBTZXJ2ZXJDb25maWd1cmF0aW9uLmV4cGlyYXRpb25fZGF0ZSBzaG91bGQgYmUgYW4g YWJzb2x1dGUgb3IgcmVsYXRpdmUgdmFsdWUuIFN1Ym9kaCAoQ0MpIGR1ZyBpbnRvIG91ciBwcm9k dWN0aW9uIGRhdGEgYW5kIGZvdW5kIHRoYXQgbmVhcmx5IGhhbGYgb2YgdGhlIFRMUyBlcnJvcnMg d2Ugc2VlIGluIHByb2R1Y3Rpb24gKGVuZCB1c2VyIHRvIGVkZ2Uvb3JpZ2luKSBhcmUgZHVlIHRv IGRhdGUgbWlzbWF0Y2guIFRoaXMgb2Z0ZW4gb2NjdXJzIHdoZW4gcGVvcGxlIGludGVudGlvbmFs bHkgcmVzZXQgdGhlIGNsb2NrIG9uIHRoZWlyIHBob25lLCBvciBmb3Igb3RoZXIgdmFyaW91cyBy ZWFzb25zLg0KDQpEdWUgdG8gdGhlIGhpZ2ggcmF0ZSBvZiBkYXRlIG1pc21hdGNoIGVycm9ycyB3 ZSBzZWUsIG15IHByZWZlcmVuY2Ugd291bGQgYmUgdGhhdCBTZXJ2ZXJDb25maWd1cmF0aW9uLmV4 cGlyYXRpb25fZGF0ZSBiZSBhIHJlbGF0aXZlIHZhbHVlIGluc3RlYWQgb2YgYW4gYWJzb2x1dGUg b25lLiBUaGlzIHByb3ZpZGVzIHRoZSBjbGllbnQgYW4gb3Bwb3J0dW5pdHkgdG8gY29ycmVjdGx5 IHVzZSBhIG1vbm90b25pYyAob3Igb3RoZXIgc2ltaWxhcikgY2xvY2sgdG8gbWluaW1pemluZyBl eHBvc3VyZSwgd2l0aG91dCBsb3NpbmcgdGhlIHZhbHVlIG9mIHRoZSBTZXJ2ZXJDb25maWd1cmF0 aW9uLiBVc2luZyBhbiBhYnNvbHV0ZSB2YWx1ZSBtZWFucyB0aGF0IFNlcnZlckNvbmZpZ3VyYXRp b24sIGZvciBjbGllbnRzIHdpdGggaW52YWxpZCBjbG9ja3MsIHdvdWxkIGVzc2VudGlhbGx5IG5l dmVyIGJlIGNhY2hlYWJsZS4gVGhlc2UgY2xpZW50cyB3b3VsZG7igJl0IGJlbmVmaXQgZnJvbSBT ZXJ2ZXJDb25maWd1cmF0aW9uLg0KDQpUaG91Z2h0cyBvciBmZWVkYmFjaz8NCg0KLUJsYWtlDQo= From nobody Wed Jul 22 13:01:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8B41A00BB for ; Wed, 22 Jul 2015 13:01:16 -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 k3KJ_pFgeHVp for ; Wed, 22 Jul 2015 13:01:14 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1982A1B2A64 for ; Wed, 22 Jul 2015 13:00:01 -0700 (PDT) Received: by wibud3 with SMTP id ud3so188485148wib.0 for ; Wed, 22 Jul 2015 12:59:59 -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=Bic5lG2BcKJWWXIhgJcqBd/sB9fyWA9JM5Fzm1t5/Qg=; b=L5lH87rEvajlWyaUl9qPN4k/03445LAG48L6aCCXlI3CX4fDDh0BgnXCiHObnp4Io7 9C4L5LDoWaq09adWppteFMpuyskEPeJhdHv1hoZSr5+JSyGFFpkB0dfYTz0o0FN8m1tG d/pdxff9d4bDqs/SPa0VfMapb3MhPsea4ma681FCcKFSS1/mIT/as7rEVE2Rp+feKe6w qttc0COz8OXWdAz5Emm8U/S/Eo+dc/8ubEM5810un0A09ID0yvJQHFDg4y2DmLayP9+N Bq2R7J9AmjmYfAPjAWMAX1ar93DKObu9MGGfMp73sewvW2Z5Uz1VnBLcWwoafpoat5dU rUkA== X-Gm-Message-State: ALoCoQl0C4TyrpNU9TaSJKKvx43CF5h+3mFiq/MaGZHTJ9ABEkRX5cxkSk6R+esD6qhSHRTCFjGV X-Received: by 10.194.133.73 with SMTP id pa9mr8295102wjb.148.1437595199856; Wed, 22 Jul 2015 12:59:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Wed, 22 Jul 2015 12:59:20 -0700 (PDT) In-Reply-To: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> References: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> From: Eric Rescorla Date: Wed, 22 Jul 2015 21:59:20 +0200 Message-ID: To: Blake Matheny Content-Type: multipart/alternative; boundary=089e011771a937fb68051b7c372d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 20:01:16 -0000 --089e011771a937fb68051b7c372d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote: > One of the topics of discussion at the WG discussion was whether > ServerConfiguration.expiration_date should be an absolute or relative > value. Subodh (CC) dug into our production data and found that nearly hal= f > of the TLS errors we see in production (end user to edge/origin) are due = to > date mismatch. This often occurs when people intentionally reset the cloc= k > on their phone, or for other various reasons. > > Due to the high rate of date mismatch errors we see, my preference would > be that ServerConfiguration.expiration_date be a relative value instead o= f > an absolute one. This provides the client an opportunity to correctly use= a > monotonic (or other similar) clock to minimizing exposure, without losing > the value of the ServerConfiguration. Using an absolute value means that > ServerConfiguration, for clients with invalid clocks, would essentially > never be cacheable. These clients wouldn=E2=80=99t benefit from ServerCon= figuration. > > Thoughts or feedback? Can you provide a sense of the range of clock skew you are seeing? I'm trying to figure out how many of these clients are going to start choking with OCSP must-staple, short-lived certs, etc. -Ekr --089e011771a937fb68051b7c372d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 9:55 PM, Blake Matheny <bmatheny@fb.com> w= rote:
One of the topics of discussion at = the WG discussion was whether ServerConfiguration.expiration_date should be= an absolute or relative value. Subodh (CC) dug into our production data an= d found that nearly half of the TLS errors we see in production (end user t= o edge/origin) are due to date mismatch. This often occurs when people inte= ntionally reset the clock on their phone, or for other various reasons.

Due to the high rate of date mismatch errors we see, my preference would be= that ServerConfiguration.expiration_date be a relative value instead of an= absolute one. This provides the client an opportunity to correctly use a m= onotonic (or other similar) clock to minimizing exposure, without losing th= e value of the ServerConfiguration. Using an absolute value means that Serv= erConfiguration, for clients with invalid clocks, would essentially never b= e cacheable. These clients wouldn=E2=80=99t benefit from ServerConfiguratio= n.

Thoughts or feedback?

Can you provide a sen= se of the range of clock skew you are seeing? I'm trying to
f= igure out how many of these clients are going to start choking with OCSP
must-staple, short-lived certs, etc.

-Ekr<= /div>


--089e011771a937fb68051b7c372d-- From nobody Wed Jul 22 13:10:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D25B1A8763 for ; Wed, 22 Jul 2015 13:10:31 -0700 (PDT) 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_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 FPnp8uI1PJ6H for ; Wed, 22 Jul 2015 13:10:30 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4841A871D for ; Wed, 22 Jul 2015 13:10:29 -0700 (PDT) Received: by qkfc129 with SMTP id c129so118001827qkf.1 for ; Wed, 22 Jul 2015 13:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=brI8dlUBeT2ZeqfxnFRuH8jkmu/CJSZacgQ4axV4wVU=; b=wvWb52ODSoQPQAK3dY1K+++myZ9mZjt/0N5i9Z4CQb7P8RsFu+yi++Y/U5zRMtx3qh GO8CkstAxCOEEkch107FKkhUApH/TYFUxlq5ODl3+RuPNMuRImQNL5b7yHjmWLVKUNYm wZ8dZbGtguka1gndy7kJ593hlJbAjYrHqTG7rMMp8k8QEI60QQDIvmVULEtpiL1Uq/lS 9dtryO/5LRBrAlnCiZOR++lP3VcnrXk79oCVkuAam2mrCewK+kazYmBbl5k85Apqpcmx AhOVX48d7h80Qq3qqB0cFQZJf3bwJmRNlxqLqVsm2nwel6cA65e6gnQn7fKC9/g3edis SxPQ== X-Received: by 10.140.194.206 with SMTP id p197mr6821182qha.21.1437595829073; Wed, 22 Jul 2015 13:10:29 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id v44sm1252216qgd.21.2015.07.22.13.10.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jul 2015 13:10:28 -0700 (PDT) From: Dave Garrett To: "tls@ietf.org" , Eric Rescorla Date: Wed, 22 Jul 2015 16:10:27 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201507221610.27729.davemgarrett@gmail.com> Archived-At: Subject: [TLS] A la carte concerns from IETF 93 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 20:10:31 -0000 Consensus was my current WIP proposal is not viable, for some of the following main reasons: 1) cost/benefit analysis doesn't seem to be worth it 2) backwards compatibility handling 3) some argue harder to implement; others argue easier To start, I'll note that I have not submitted a PR yet. This is all currently just on a WIP branch on GitHub to be easier to discuss specifics on-list. It's based on PR #201, but that's just to make keeping track of things easier. This is less of an issue now that my other PRs were merged (namely the updated cipher suite section). I'll switch to a standalone proposal for the next draft instead of editing the section inline, as it was indicated that would be easier to follow. Not everyone was a party to every discussion on-list about these topics, so a better summary is needed. On to the concerns: 1) The cost/benefit analysis is a very important concern. If you're only analyzing this from a perspective of combinatorial explosion reduction, then I actually agree it's not worth the cost. Here's how I perceive it, currently: benefit: + reduction in combinatorial mess (primarily achieved as we move forward, as back compat still needs to offer some old) + single point of negotiation for (EC)DHE + single point of negotiation for certificates (seemed to be wide agreement to do this regardless of full a la carte) + deprecation of existing DHE suites which risk wanting weak groups depending on server and are an interop hazard due to Java being crap + ECC is always an option, regardless of suite offer/selection + FFDHE doesn't need new suites to be offered by clients not offering DHE AEAD at the moment + missing combinations are no longer an interop failure cost: - change has risks of mistake at various points (implementation, deployment, admin, client config, etc.) - support for TLS 1.2 + 1.3 results in a mix; old suites still need to be offered - risk of confusion due to change in behavior (point #2 above) depends: +/- point #4, depending on implementation (the number of points in this list is not indicative of weight; the first cost could outweigh all benefits, depending on perspective) Additionally mentioned cost: - cannot specify exact combinations; some might not be desirable However, I set this one aside because it's a problem with a full a la carte proposal, but not my current one. All possible combinations of DHE/ECDHE+RSA/DSS/ECDSA/PSK/anon+cipher_hash are already considered valid, and generally have their own suite assignments. I'm not suggesting breaking up cipher_hash. Cert/PSK/anon still have to have separate suites in this system, which prohibits wrong stuff like none_anon (lack of DH from plain PSK + anon). If we ditch suites entirely, as was suggested by others, then this is a risk that comes up. The main difference in my calculus vs. others is that: a) I'm swayed by Tony Arcieri's argument that DHE, as it currently exists, needs to be scrapped. Old Java chokes on it and there is a risk of servers negotiating weak groups when offering it. Deprecating all DHE suites is an interop and security win. FFDHE is still around, but now with only strong groups, whereas without this proposal we go ECC or bust (until something post-quantum is a viable option here). b) ECC isn't separate anymore; it's always expected to be available. We don't have to worry about endpoints actually offering suites that claim support, as it's just a given now. c) Interop failure due to missing suites, regardless of algorithm support, is no longer a risk. It's currently possible to negotiate CBC because the GCM suites offered by the server are combinations not supported by the client, even though GCM is supported. (this does happen in the real world and is too often overlooked in this discussion) 2) Backwards compatibility is pretty straightforward. Here's what Firefox currently offers, minus RC4 & 3DES: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA The current TLS 1.3 draft would only accept the top two as viable (only AEAD). Both my current proposal and the general consensus minimum would pick just the top one and pick certs based on the extension. Note that DHE/FFDHE is available, but only for AES CBC with RSA. The second change here is that my proposal allows DHE with no changes to this list. Yeah, we'd like to move to an ECC only world, but I'm paranoid and want a backup. This gives it effortlessly. This would also permit FFDHE+ECDSA combinations without new suites. All DHE suites could be dropped in the future, in favor of ECDHE only on old TLS but the possibility of FFDHE on new. If you want to keep around FFDHE without this proposal, you need to add those suites for GCM. Just to make sure it's emphasized, the current path without this proposal would require Firefox add the following in order to use the new FFDHE groups: TLS_DHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Mozilla probably doesn't want to do that. Negotiating the new FFDHE groups might be acceptable, but whatever weaker junk you get without them is not. I guess a higher minimum could be put in place for AEAD suites or TLS 1.3+, but now we're already adding complexity. Once we get out of the AES monoculture, it's also the difference between adding: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 TLS_DHE_ECDSA_WITH_CHACHA20_POLY1305 or just: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 I'll also add that DHE_ECDSA suites just aren't defined. Yes, using the cert extension could let us get this combo via DHE_RSA, but that means offering RSA suites for everything old and new. As to the need to list all this stuff to work: If you want everything to be clean, abandon TLS and go for something QUIC based. Backwards compatibility is messy; that's one of the reasons why you shouldn't want it forever. 3) I argue that framing the negotiation in a manner more similar to what is actually being negotiated reduces the risk of problems. _Not_ doing so has the following issues: a) Offering an ECDHE suite will offer FFDHE groups via the upgraded extension, but no ability for a server to pick it if the right combo for DHE isn't there. The server can't select the 4k FF group if it'd rather have that than P-256 because no better curve is available. b) ECHDE/DHE has to be chosen based on cipher suite priority, rather than actually looking at the groups' priority and picking the one that should be preferred. Contrary to suite definitions, ECDHE and DHE are not monolithic things. c) The server should be able to offer any certs the client can use, regardless of connection encryption. (again, this part seems to have wide agreement) --- That covers the main issues. There's also the issue of making sure that any new system is understandable and doesn't introduce points of confusion down the road. I don't claim that this addresses everything that has been or can be said, but I also don't want to post a larger wall of text than this. ;) Also, others may likely not care about FFDHE as much as I do. It is, however, in the current draft on essentially equal footing with ECC. As such, I'm considering it that way in discussion and proposals. This proposal is shaped by the negotiated FF-DH draft and its integration into the current TLS 1.3 draft. Dave From nobody Wed Jul 22 13:56:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4FC1B2E4F for ; Wed, 22 Jul 2015 13:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 gKpoKWisGsyU for ; Wed, 22 Jul 2015 13:56:04 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C501B2E3E for ; Wed, 22 Jul 2015 13:56:03 -0700 (PDT) Received: from pps.filterd (m0004003 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t6MKtwh4012545; Wed, 22 Jul 2015 13:56:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=Bl17ncmqOabxf78llRnJH11t6TLStD+baHhSHzjwby4=; b=VZ214d/4/k6Z0sk5JYFQVkmUxcjRqOL3h0cUUFCgTdjo6L8xWYTMksApLmdqh3Je5FFu FdEmP6I6oq+aUcVqoElUp4L04wmisxwlEyGFCq5wfTmo/VyOyP3Y45YPApr62JbdV6Y0 B8Kd1j/5Rb7haYSSPLwXaCCP4AeG2KOgIQw= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1vtg1j8qbs-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 13:56:03 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.114]) by PRN-CHUB10.TheFacebook.com ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:54:32 -0700 From: Blake Matheny To: Eric Rescorla Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dZ3oXbMAgAAw8oA= Date: Wed, 22 Jul 2015 20:54:31 +0000 Message-ID: <3D04F5AE-61E1-45A9-A794-C3F0E6F3DEAD@fb.com> References: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_3D04F5AE61E145A9A794C3F0E6F3DEADfbcom_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-22_07:2015-07-22,2015-07-22,1970-01-01 signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 20:56:05 -0000 --_000_3D04F5AE61E145A9A794C3F0E6F3DEADfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gV2VkLCBKdWwgMjIsIDIwMTUgYXQgOTo1NSBQTSwgQmxha2UgTWF0aGVueSA8Ym1hdGhlbnlA ZmIuY29tPG1haWx0bzpibWF0aGVueUBmYi5jb20+PiB3cm90ZToNCk9uZSBvZiB0aGUgdG9waWNz IG9mIGRpc2N1c3Npb24gYXQgdGhlIFdHIGRpc2N1c3Npb24gd2FzIHdoZXRoZXIgU2VydmVyQ29u ZmlndXJhdGlvbi5leHBpcmF0aW9uX2RhdGUgc2hvdWxkIGJlIGFuIGFic29sdXRlIG9yIHJlbGF0 aXZlIHZhbHVlLiBTdWJvZGggKENDKSBkdWcgaW50byBvdXIgcHJvZHVjdGlvbiBkYXRhIGFuZCBm b3VuZCB0aGF0IG5lYXJseSBoYWxmIG9mIHRoZSBUTFMgZXJyb3JzIHdlIHNlZSBpbiBwcm9kdWN0 aW9uIChlbmQgdXNlciB0byBlZGdlL29yaWdpbikgYXJlIGR1ZSB0byBkYXRlIG1pc21hdGNoLiBU aGlzIG9mdGVuIG9jY3VycyB3aGVuIHBlb3BsZSBpbnRlbnRpb25hbGx5IHJlc2V0IHRoZSBjbG9j ayBvbiB0aGVpciBwaG9uZSwgb3IgZm9yIG90aGVyIHZhcmlvdXMgcmVhc29ucy4NCg0KRHVlIHRv IHRoZSBoaWdoIHJhdGUgb2YgZGF0ZSBtaXNtYXRjaCBlcnJvcnMgd2Ugc2VlLCBteSBwcmVmZXJl bmNlIHdvdWxkIGJlIHRoYXQgU2VydmVyQ29uZmlndXJhdGlvbi5leHBpcmF0aW9uX2RhdGUgYmUg YSByZWxhdGl2ZSB2YWx1ZSBpbnN0ZWFkIG9mIGFuIGFic29sdXRlIG9uZS4gVGhpcyBwcm92aWRl cyB0aGUgY2xpZW50IGFuIG9wcG9ydHVuaXR5IHRvIGNvcnJlY3RseSB1c2UgYSBtb25vdG9uaWMg KG9yIG90aGVyIHNpbWlsYXIpIGNsb2NrIHRvIG1pbmltaXppbmcgZXhwb3N1cmUsIHdpdGhvdXQg bG9zaW5nIHRoZSB2YWx1ZSBvZiB0aGUgU2VydmVyQ29uZmlndXJhdGlvbi4gVXNpbmcgYW4gYWJz b2x1dGUgdmFsdWUgbWVhbnMgdGhhdCBTZXJ2ZXJDb25maWd1cmF0aW9uLCBmb3IgY2xpZW50cyB3 aXRoIGludmFsaWQgY2xvY2tzLCB3b3VsZCBlc3NlbnRpYWxseSBuZXZlciBiZSBjYWNoZWFibGUu IFRoZXNlIGNsaWVudHMgd291bGRu4oCZdCBiZW5lZml0IGZyb20gU2VydmVyQ29uZmlndXJhdGlv bi4NCg0KVGhvdWdodHMgb3IgZmVlZGJhY2s/DQoNCkNhbiB5b3UgcHJvdmlkZSBhIHNlbnNlIG9m IHRoZSByYW5nZSBvZiBjbG9jayBza2V3IHlvdSBhcmUgc2VlaW5nPyBJJ20gdHJ5aW5nIHRvDQpm aWd1cmUgb3V0IGhvdyBtYW55IG9mIHRoZXNlIGNsaWVudHMgYXJlIGdvaW5nIHRvIHN0YXJ0IGNo b2tpbmcgd2l0aCBPQ1NQDQptdXN0LXN0YXBsZSwgc2hvcnQtbGl2ZWQgY2VydHMsIGV0Yy4NCg0K V2VsbCwgb3VyIHB1YmxpYyBjZXJ0IGlzIHNldCB0byBleHBpcmUgaW4gfjEgeWVhci4gVGhlIGVy cm9ycyBJ4oCZbSBzZWVpbmcgYXJlIOKAnGNlcnRpZmljYXRlIGhhcyBleHBpcmVk4oCdIGFuZCDi gJxjZXJ0aWZpY2F0ZSBub3QgeWV0IHZhbGlk4oCdLiBJIGRvbuKAmXQgaGF2ZSBjbGllbnQgdGlt ZXN0YW1wIHZzIHNlcnZlciB0aW1lc3RhbXAsIGJ1dCB0aGUgY2xvY2sgaW4gdGhlc2UgY2FzZXMg aXMgb2ZmIGJ5IGEgeWVhci1pc2g/DQoNCi1CbGFrZQ0K --_000_3D04F5AE61E145A9A794C3F0E6F3DEADfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <3B234D8A1303E54B8CD768B2538B082D@fb.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP Tl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElO RzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBKdWwgMjIs IDIwMTUgYXQgOTo1NSBQTSwgQmxha2UgTWF0aGVueSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEg aHJlZj0ibWFpbHRvOmJtYXRoZW55QGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJtYXRoZW55QGZi LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCk9uZSBvZiB0aGUgdG9waWNzIG9mIGRpc2N1c3Npb24gYXQg dGhlIFdHIGRpc2N1c3Npb24gd2FzIHdoZXRoZXIgU2VydmVyQ29uZmlndXJhdGlvbi5leHBpcmF0 aW9uX2RhdGUgc2hvdWxkIGJlIGFuIGFic29sdXRlIG9yIHJlbGF0aXZlIHZhbHVlLiBTdWJvZGgg KENDKSBkdWcgaW50byBvdXIgcHJvZHVjdGlvbiBkYXRhIGFuZCBmb3VuZCB0aGF0IG5lYXJseSBo YWxmIG9mIHRoZSBUTFMgZXJyb3JzIHdlIHNlZSBpbiBwcm9kdWN0aW9uIChlbmQgdXNlcg0KIHRv IGVkZ2Uvb3JpZ2luKSBhcmUgZHVlIHRvIGRhdGUgbWlzbWF0Y2guIFRoaXMgb2Z0ZW4gb2NjdXJz IHdoZW4gcGVvcGxlIGludGVudGlvbmFsbHkgcmVzZXQgdGhlIGNsb2NrIG9uIHRoZWlyIHBob25l LCBvciBmb3Igb3RoZXIgdmFyaW91cyByZWFzb25zLjxicj4NCjxicj4NCkR1ZSB0byB0aGUgaGln aCByYXRlIG9mIGRhdGUgbWlzbWF0Y2ggZXJyb3JzIHdlIHNlZSwgbXkgcHJlZmVyZW5jZSB3b3Vs ZCBiZSB0aGF0IFNlcnZlckNvbmZpZ3VyYXRpb24uZXhwaXJhdGlvbl9kYXRlIGJlIGEgcmVsYXRp dmUgdmFsdWUgaW5zdGVhZCBvZiBhbiBhYnNvbHV0ZSBvbmUuIFRoaXMgcHJvdmlkZXMgdGhlIGNs aWVudCBhbiBvcHBvcnR1bml0eSB0byBjb3JyZWN0bHkgdXNlIGEgbW9ub3RvbmljIChvciBvdGhl ciBzaW1pbGFyKSBjbG9jaw0KIHRvIG1pbmltaXppbmcgZXhwb3N1cmUsIHdpdGhvdXQgbG9zaW5n IHRoZSB2YWx1ZSBvZiB0aGUgU2VydmVyQ29uZmlndXJhdGlvbi4gVXNpbmcgYW4gYWJzb2x1dGUg dmFsdWUgbWVhbnMgdGhhdCBTZXJ2ZXJDb25maWd1cmF0aW9uLCBmb3IgY2xpZW50cyB3aXRoIGlu dmFsaWQgY2xvY2tzLCB3b3VsZCBlc3NlbnRpYWxseSBuZXZlciBiZSBjYWNoZWFibGUuIFRoZXNl IGNsaWVudHMgd291bGRu4oCZdCBiZW5lZml0IGZyb20gU2VydmVyQ29uZmlndXJhdGlvbi48YnI+ DQo8YnI+DQpUaG91Z2h0cyBvciBmZWVkYmFjaz88L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5DYW4geW91IHByb3ZpZGUgYSBzZW5zZSBvZiB0aGUgcmFuZ2Ugb2YgY2xvY2sg c2tldyB5b3UgYXJlIHNlZWluZz8gSSdtIHRyeWluZyB0bzwvZGl2Pg0KPGRpdj5maWd1cmUgb3V0 IGhvdyBtYW55IG9mIHRoZXNlIGNsaWVudHMgYXJlIGdvaW5nIHRvIHN0YXJ0IGNob2tpbmcgd2l0 aCBPQ1NQPC9kaXY+DQo8ZGl2Pm11c3Qtc3RhcGxlLCBzaG9ydC1saXZlZCBjZXJ0cywgZXRjLjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+V2VsbCwgb3VyIHB1YmxpYyBjZXJ0IGlzIHNldCB0byBleHBp cmUgaW4gfjEgeWVhci4gVGhlIGVycm9ycyBJ4oCZbSBzZWVpbmcgYXJlIOKAnGNlcnRpZmljYXRl IGhhcyBleHBpcmVk4oCdIGFuZCDigJxjZXJ0aWZpY2F0ZSBub3QgeWV0IHZhbGlk4oCdLiBJIGRv buKAmXQgaGF2ZSBjbGllbnQgdGltZXN0YW1wIHZzIHNlcnZlciB0aW1lc3RhbXAsIGJ1dCB0aGUg Y2xvY2sgaW4gdGhlc2UgY2FzZXMgaXMgb2ZmIGJ5IGEgeWVhci1pc2g/PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4tQmxha2U8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3D04F5AE61E145A9A794C3F0E6F3DEADfbcom_-- From nobody Wed Jul 22 13:59:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C2B1B2E3E for ; Wed, 22 Jul 2015 13:59:06 -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 H7SsWmFmkQNn for ; Wed, 22 Jul 2015 13:59:05 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E75C1A1B7B for ; Wed, 22 Jul 2015 13:59:05 -0700 (PDT) Received: by wibud3 with SMTP id ud3so190473492wib.0 for ; Wed, 22 Jul 2015 13:59:04 -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=4WuVN2F6+WJB2Hr5nQR/ezCe2mtLpeM9jcpp8SXI2lM=; b=nMpvVZk+G15BN+gtly8Kdu8jqSgvoCF59tPwpXLJQKzaplcf5fPVYf2XtX/7E2Jpzg PpsVlPP/NvfjRdbFy7NGqUSNElNZRRbrBxVO2NbaCzuy9OGLFj6wLgp08Lv8DHxBiR9k 7v7iFnuU7h99qRfKAZnwN8TRRuJphnha9+oydl3x3dDHgWy+g8t+5P4F1o2MxYtZX8ya uZrQMo+tmix0LEc2DB/JJvpeTZ1/9ESRPsfgY59nVWe5XIAuIrZHEOIduOUa2gd3hWnP XgsY2XoFG111+CPUk/Sb1wLvp/Oz8d8/4ynSvuAOteDf9skIQOXN7vl3gaZGMSsNgklr 1hjQ== X-Gm-Message-State: ALoCoQkfMnuzBxZtVA1ehhJmojlDh0BBgwypBBo27CjO7DTWw7GqDMw2dwGDmnk44Pc3KPkwdq7k X-Received: by 10.194.133.73 with SMTP id pa9mr8699772wjb.148.1437598743941; Wed, 22 Jul 2015 13:59:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Wed, 22 Jul 2015 13:58:24 -0700 (PDT) In-Reply-To: <3D04F5AE-61E1-45A9-A794-C3F0E6F3DEAD@fb.com> References: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> <3D04F5AE-61E1-45A9-A794-C3F0E6F3DEAD@fb.com> From: Eric Rescorla Date: Wed, 22 Jul 2015 22:58:24 +0200 Message-ID: To: Blake Matheny Content-Type: multipart/alternative; boundary=089e011771a976675f051b7d0aab Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 20:59:07 -0000 --089e011771a976675f051b7d0aab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I guess what I'm trying to get at is the following: Are there a lot of people whose clocks are accurate enough that they will be able to connect to the server and check the certificate/OCSP but not accurate enough to process ServerConfiguration if it is in absolute time. On Wed, Jul 22, 2015 at 10:54 PM, Blake Matheny wrote: > On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote= : > >> One of the topics of discussion at the WG discussion was whether >> ServerConfiguration.expiration_date should be an absolute or relative >> value. Subodh (CC) dug into our production data and found that nearly ha= lf >> of the TLS errors we see in production (end user to edge/origin) are due= to >> date mismatch. This often occurs when people intentionally reset the clo= ck >> on their phone, or for other various reasons. >> >> Due to the high rate of date mismatch errors we see, my preference would >> be that ServerConfiguration.expiration_date be a relative value instead = of >> an absolute one. This provides the client an opportunity to correctly us= e a >> monotonic (or other similar) clock to minimizing exposure, without losin= g >> the value of the ServerConfiguration. Using an absolute value means that >> ServerConfiguration, for clients with invalid clocks, would essentially >> never be cacheable. These clients wouldn=E2=80=99t benefit from ServerCo= nfiguration. >> >> Thoughts or feedback? > > > Can you provide a sense of the range of clock skew you are seeing? I'm > trying to > figure out how many of these clients are going to start choking with OCSP > must-staple, short-lived certs, etc. > > > Well, our public cert is set to expire in ~1 year. The errors I=E2=80=99= m seeing > are =E2=80=9Ccertificate has expired=E2=80=9D and =E2=80=9Ccertificate no= t yet valid=E2=80=9D. I don=E2=80=99t have > client timestamp vs server timestamp, but the clock in these cases is off > by a year-ish? > > -Blake > --089e011771a976675f051b7d0aab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess what I'm trying to get at is the following:Are there a lot of people whose clocks are accurate enough that they will= be able to connect to the server and check the certificate/OCSP but not ac= curate enough to process ServerConfiguration if it is in absolute time.

On Wed, J= ul 22, 2015 at 10:54 PM, Blake Matheny <bmatheny@fb.com> wrote= :
On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny <= span dir=3D"ltr"> <bmatheny@fb.com> wrote:
One of the topics of discussion at the WG discussion was whether ServerConf= iguration.expiration_date should be an absolute or relative value. Subodh (= CC) dug into our production data and found that nearly half of the TLS erro= rs we see in production (end user to edge/origin) are due to date mismatch. This often occurs when people in= tentionally reset the clock on their phone, or for other various reasons.
Due to the high rate of date mismatch errors we see, my preference would be= that ServerConfiguration.expiration_date be a relative value instead of an= absolute one. This provides the client an opportunity to correctly use a m= onotonic (or other similar) clock to minimizing exposure, without losing the value of the ServerConfiguratio= n. Using an absolute value means that ServerConfiguration, for clients with= invalid clocks, would essentially never be cacheable. These clients wouldn= =E2=80=99t benefit from ServerConfiguration.

Thoughts or feedback?

Can you provide a sense of the range of clock skew you are seeing? I&#= 39;m trying to
figure out how many of these clients are going to start choking with O= CSP
must-staple, short-lived certs, etc.


--089e011771a976675f051b7d0aab-- From nobody Wed Jul 22 14:15:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BEB1A0193 for ; Wed, 22 Jul 2015 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 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_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 3asE1xfhKU0w for ; Wed, 22 Jul 2015 14:15:03 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E0F1B2E70 for ; Wed, 22 Jul 2015 14:15:00 -0700 (PDT) Received: from pps.filterd (m0004003 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t6MLEtAY006185; Wed, 22 Jul 2015 14:14:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=g/qeeIlyrIdhlDcMjNA8rQ761pIrFslC54wT32qtjT4=; b=mHS0RvOUV/6wns8krK91NjRfRviyaDaxYkpwKpN00LHytG87PtK4xXR9tDuoXS2H6LEO 1dLV67rW815jVSApC7s2J2d/CELpiCyVM5wMUADl6u7958juP8b0v5S1GKgLOboEZVTh 6HxyrawD7UP/6L3JAEblRVW1maCauKnLzpE= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1vtjqgg1gn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 14:14:59 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.114]) by PRN-CHUB10.TheFacebook.com ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 14:14:40 -0700 From: Blake Matheny To: Eric Rescorla Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dZ3oXbMAgAAw8oD//9+PAIAAJhAA Date: Wed, 22 Jul 2015 21:14:39 +0000 Message-ID: <45822829-5DA1-4AA8-9317-BE4D4AEC41E6@fb.com> References: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> <3D04F5AE-61E1-45A9-A794-C3F0E6F3DEAD@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-22_07:2015-07-22,2015-07-22,1970-01-01 signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 21:15:04 -0000 QWhoLiBJIGNhbid0IHRlbGwsIHRoZSBkYXRhIEkgaGF2ZSBpcyBvbmx5IGNsaWVudHMgd2l0aCB2 ZXJ5IHZlcnkgYnJva2VuIGNsb2NrcyB3aG8gZmFpbGVkIHZhbGlkYXRpb24gYXMgYSByZXN1bHQu IE15IGFzc3VtcHRpb24gd291bGQgYmUgdGhhdCB0aGVyZSBpcyBhIG11Y2ggbGFyZ2VyIG51bWJl ciBvZiBjbGllbnRzIHRoYXQgZml0IHdoYXQgeW91IGRlc2NyaWJlZCAoY2VydC9PQ1NQIGNoZWNr IHBhc3NlcywgYnV0IFNlcnZlckNvbmZpZ3VyYXRpb24gd291bGQgbm90IGJlKS4gU2luY2UgSSBk b27igJl0IGhhdmUgdGhlIGRhdGEsIEkgY2Fu4oCZdCBzYXkgdGhhdCBmb3Igc3VyZSwgYnV0IGFu ZWNkb3RhbCBldmlkZW5jZSB3b3VsZCBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMgdGhlIGNhc2UuDQoN Ci1CbGFrZQ0KDQoNCg0KDQpPbiA3LzIyLzE1LCAxMDo1OCBQTSwgIkVyaWMgUmVzY29ybGEiIDxl a3JAcnRmbS5jb20+IHdyb3RlOg0KDQo+SSBndWVzcyB3aGF0IEknbSB0cnlpbmcgdG8gZ2V0IGF0 IGlzIHRoZSBmb2xsb3dpbmc6DQo+QXJlIHRoZXJlIGEgbG90IG9mIHBlb3BsZSB3aG9zZSBjbG9j a3MgYXJlIGFjY3VyYXRlIGVub3VnaCB0aGF0IHRoZXkgd2lsbCBiZSBhYmxlIHRvIGNvbm5lY3Qg dG8gdGhlIHNlcnZlciBhbmQgY2hlY2sgdGhlIGNlcnRpZmljYXRlL09DU1AgYnV0IG5vdCBhY2N1 cmF0ZSBlbm91Z2ggdG8gcHJvY2VzcyBTZXJ2ZXJDb25maWd1cmF0aW9uIGlmIGl0IGlzIGluIGFi c29sdXRlIHRpbWUuDQo= From nobody Wed Jul 22 14:23:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3231B2E97 for ; Wed, 22 Jul 2015 14:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 iwcK2fLT74_N for ; Wed, 22 Jul 2015 14:23:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3FC1B2E95 for ; Wed, 22 Jul 2015 14:23:44 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mc8t72R60z1bq for ; Wed, 22 Jul 2015 23:23:43 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=B+wlul9q X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KXoACfwThtec for ; Wed, 22 Jul 2015 23:23:41 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 22 Jul 2015 23:23:41 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0002880042 for ; Wed, 22 Jul 2015 17:23:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437600220; bh=w4u399Cl3wYYld84mgUza9FRc6z9ao/tMU1UWoM5xDo=; h=Date:From:To:Subject:In-Reply-To:References; b=B+wlul9qQmDznUH5kMeP0CBgWQSEyifMOLSIzyCv47U8vkqs/g4myPndRoaJ5JR2J hokcmAPNXBKBoT3c7bVaj5G9REoUOdnIN1HeH4fz4wAShgY5j1MOudXv0huy+amB/K yfgsDN5Y/MHnq5+X3RdCWWhd527EgWOdc28idqUk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6MLNdDC017490 for ; Wed, 22 Jul 2015 17:23:39 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 22 Jul 2015 17:23:39 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: <20150722171622.GH4347@mournblade.imrryr.org> Message-ID: References: <20150722171622.GH4347@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2015 21:23:47 -0000 On Wed, 22 Jul 2015, Viktor Dukhovni wrote: >> I think the server should stick to one chain, from the root to itself, >> so it does not have to deal with variable chain blobs per client. >> That will allow server code to stick to something like hourly >> regenerating the blob for use with all clients. > >> From the root to its own TLSA RRset, however, this can be complicated > in the presence of CNAMEs: > Should everything other than the first CNAME be in additional > records? I think so. > Should all the above (with their RRSIGs) be in the answer > section, with the union of the supporting DNSKEY/RRSIG/DS records > as additional? No, only the TLSA record and its RRSIG should be in there, so it is identical to a real DNS response packet. > I tried to ask a related question during the meeting, but bandwidth > to explain the context was limited: Should proofs of non-delegation > be included, to keep gTLDs and ccTLDs honest for some future CT for > DNS? Specifically, suppose you see: > > _443._tcp.www.example.com. IN TLSA > > with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3 > records that demonstrate that "example.com" (and www.example.com) > are not delegated? (Such records might then be subject to "gossip" > or related "transparency" counter-measures). That's an interesting question. I'd be tempted not to do this work in the TLS extension but keep that to a ct-dnssec document. >> I do strongly prefer the binary blob to be in raw dns format. That >> will make parsing easier with existing code, and over time we will >> not run into issues where dns libraries support newer algorithms >> but this specific dnssec parsing code isn't updated. > > I'm not sure what "algorithms" you have in mind? The successor to ECDSA or something like Curve*. I meant new DNSKEY algorithms used to generate RRSIG records. I would like to see DNS code maintained by DNS people used by browser people but I am young and naive. > We should perhaps > allow (even encourage) "compression" to reduce the payload size, Is that a problem in TLS? I thought the CA chains were already massively bigger? Or is this something specific to the client/server hello message? >> As for ekr's question on why not stuff this inside X.509, that would not >> be compatible with tls raw pulic keys that only contain a SBKI, and drag >> back into the protocol more ASN.1 parsing and containers. > > This really can't go in the certificate, because then certificates > would have to be updated as often as RRSIGS are regenerated. That > seems exceedingly unlikely to be deployable. I agree, but Adam Langley did make that work so perhaps we are wrong? Paul From nobody Wed Jul 22 15:18:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E11B2F3F for ; Wed, 22 Jul 2015 15:18:21 -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 e_RD5MsIR7Kq for ; Wed, 22 Jul 2015 15:18:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138831B2F3D for ; Wed, 22 Jul 2015 15:18:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 38A40284B55; Wed, 22 Jul 2015 22:18:17 +0000 (UTC) Date: Wed, 22 Jul 2015 22:18:17 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150722221816.GN4347@mournblade.imrryr.org> References: <20150722171622.GH4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension 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, 22 Jul 2015 22:18:21 -0000 On Wed, Jul 22, 2015 at 05:23:39PM -0400, Paul Wouters wrote: > >Should everything other than the first CNAME be in additional > >records? > > I think so. > > > Should all the above (with their RRSIGs) be in the answer > >section, with the union of the supporting DNSKEY/RRSIG/DS records > >as additional? > > No, only the TLSA record and its RRSIG should be in there, so it is > identical to a real DNS response packet. But, the presence of a CNAME chain (either from host to TLSA base domain, or from TLSA base domain to ultimate TLSA RRset) the start of the chain is in the answer per your first comment? > >I tried to ask a related question during the meeting, but bandwidth > >to explain the context was limited: Should proofs of non-delegation > >be included, to keep gTLDs and ccTLDs honest for some future CT for > >DNS? Specifically, suppose you see: > > > > _443._tcp.www.example.com. IN TLSA > > > >with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3 > >records that demonstrate that "example.com" (and www.example.com) > >are not delegated? (Such records might then be subject to "gossip" > >or related "transparency" counter-measures). > > That's an interesting question. I'd be tempted not to do this work in > the TLS extension but keep that to a ct-dnssec document. But it would affect which RRsets servers should put in the extension. I guess the extension structure remains the same, so no need to pin this down yet? > >>I do strongly prefer the binary blob to be in raw dns format. That > >>will make parsing easier with existing code, and over time we will > >>not run into issues where dns libraries support newer algorithms > >>but this specific dnssec parsing code isn't updated. > > > >I'm not sure what "algorithms" you have in mind? > > The successor to ECDSA or something like Curve*. I meant new DNSKEY > algorithms used to generate RRSIG records. I would like to see DNS > code maintained by DNS people used by browser people but I am young and > naive. Oh, I see, indeed I DO NOT want to see applications shipping with their own rarely updated DNSSEC libraries. They should at least use an actively maintained library that is sepeparate from the application, and provides a "standard" API for doing the validation. Even better would be a new type of query to the local resolver that includes all the records as part of the query, and the local resolver validates the results (for clients that can reach a resolver on 127.0.0.1, but which in turn can't get DNSSEC data). (That is a protocol is even better than an API). > > We should perhaps > >allow (even encourage) "compression" to reduce the payload size, > > Is that a problem in TLS? I thought the CA chains were already massively > bigger? Or is this something specific to the client/server hello > message? Sure, CA chains are largish, but no reason to make DNS chains needlessly large, or for servers to perform uncompression just to forward DNS packets to clients. > >This really can't go in the certificate, because then certificates > >would have to be updated as often as RRSIGS are regenerated. That > >seems exceedingly unlikely to be deployable. > > I agree, but Adam Langley did make that work so perhaps we are wrong? Google might be more at liberty to mint certificates as they please and to coordinate this with any DNS RRSIG refreshes, I don't see the world at large being at liberty to do this. -- Viktor. From nobody Wed Jul 22 18:38:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6045B1A1B76 for ; Wed, 22 Jul 2015 18:38:44 -0700 (PDT) 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_05=-0.5, J_CHICKENPOX_12=0.6, 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 SiXlK-XQHTFf for ; Wed, 22 Jul 2015 18:38:42 -0700 (PDT) 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 6DFA11A1AE3 for ; Wed, 22 Jul 2015 18:38:42 -0700 (PDT) Received: from [68.34.215.90] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZI5T6-00040E-Ga; Wed, 22 Jul 2015 21:38:40 -0400 Date: Wed, 22 Jul 2015 18:38:42 -0700 From: Bill Frantz To: Blake Matheny X-Priority: 3 In-Reply-To: <45822829-5DA1-4AA8-9317-BE4D4AEC41E6@fb.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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79a7c74cfc5aadb00f828d073285374e2a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.34.215.90 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 01:38:44 -0000 One place we may run into a lot of those clients are on machines=20 like the Raspberry Pi and Beaglebone machines. These boards do=20 not include clock chips, so the machines must get the current=20 time via NTP every time they power on. If there is a problem=20 with NTP, or if the shell script to set the clock is not run,=20 then the date will probably be 20 or 30 years back in the last millenium. Cheers - Bill On 7/22/15 at 2:14 PM, bmatheny@fb.com (Blake Matheny) wrote: >Ahh. I can't tell, the data I have is only clients with very=20 >very broken clocks who failed validation as a result. My=20 >assumption would be that there is a much larger number of=20 >clients that fit what you described (cert/OCSP check passes,=20 >but ServerConfiguration would not be). Since I don=E2=80=99t have the=20 >data, I can=E2=80=99t say that for sure, but anecdotal evidence would=20 >indicate that this is the case. > >-Blake > > > > >On 7/22/15, 10:58 PM, "Eric Rescorla" wrote: > >>I guess what I'm trying to get at is the following: >>Are there a lot of people whose clocks are accurate enough that they will= be able to connect to the >server and check the certificate/OCSP but not accurate enough=20 >to process ServerConfiguration if it is in absolute time. >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > ----------------------------------------------------------------------- Bill Frantz | Ham radio contesting is a | Periwinkle (408)356-8506 | contact sport. | 16345=20 Englewood Ave www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos,=20 CA 95032 From nobody Wed Jul 22 18:39:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82881ACD18 for ; Wed, 22 Jul 2015 18:39:52 -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 92SMW2B_1aG5 for ; Wed, 22 Jul 2015 18:39:50 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3D31ACD12 for ; Wed, 22 Jul 2015 18:39:48 -0700 (PDT) Received: by qged69 with SMTP id d69so82251024qge.0 for ; Wed, 22 Jul 2015 18:39:48 -0700 (PDT) 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=DOrftDIqNyPU8lXSjXJPGap9bdEtsihg2uowvnMQt8I=; b=iEDQc3hmLbm6MzsVja5TCMmANdNZ0+IRTc5NXS+9CIEsx3TWLBKnpw76+lzru8JTMX G+3DCoRcm67BQTtDYK75oClQ3VIpTHcvq5eBHw2W1ypQ0o+L8WOtPMbaWts49chzv8NU 7SFzVFbckOfSrcjJlTQIen6Uq9j7DLuhBof5E3lQXLbfWB3sXxtUDt6ESEiwUhu7C3Ny EikIkhIOhK8fLUurHimSsv3Tedg6rlBWWFFNbzEnDnqK/7HnKTRa7JPkmKOAnQDf0FpH H7RLIOBhx4EA81Uv1GVE8nyDliVUgnAJ1SohjE6sOXzw5uBSdv/D8lNnJaf4UzUKXsyq RSkQ== X-Received: by 10.140.33.130 with SMTP id j2mr8220290qgj.8.1437615588200; Wed, 22 Jul 2015 18:39:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 137sm1678337qhs.5.2015.07.22.18.39.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jul 2015 18:39:47 -0700 (PDT) From: Dave Garrett To: "tls@ietf.org" Date: Wed, 22 Jul 2015 21:39:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: <201507222139.46391.davemgarrett@gmail.com> Archived-At: Subject: [TLS] new error 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: Thu, 23 Jul 2015 01:39:52 -0000 SHViZXJ0IEthaXJvIGZvdW5kIHF1aXRlIGEgZmV3IG1vcmUgc3BvdHMgaW4gbmVlZCBvZiBleHBs aWNpdCBlcnJvciBkZXNpZ25hdGlvbnMsIHdoaWNoIGhhdmUgYmVlbiBhbWVuZGVkIGludG8gUFIg IzIwMS4KaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC8yMDEKCkkganVz dCBub3RpY2VkIG9uZSBlcnJvciBpbiB0aGUgY3VycmVudCBkcmFmdCB0ZXh0IHRoYXQgd2FzIHdy b25nIGFuZCBhZGRlZCBhIGZpeCBmb3IgdGhhdCBhcyB3ZWxsLiBUaGUgU2VydmVyIEhlbGxvIHNl Y3Rpb24gc2FpZCB0aGF0IGxhY2sgb2YgYWNjZXB0YWJsZSBncm91cCB3b3VsZCByZXN1bHQgaW4g YW4gImluc3VmZmljaWVudF9zZWN1cml0eSIgZXJyb3IsIHdoaWNoIGlzIGluY29ycmVjdC4gVGhh dCBlcnJvciBpcyBjbGVhcmx5IGRlZmluZWQgdG8gYmUgZm9yIGxhY2sgb2YgYWNjZXB0YWJsZSBj aXBoZXIgc3VpdGUuIFRoZSBOZWdvdGlhdGVkIEdyb3VwcyBzZWN0aW9uIHNheXMgbGFjayBvZiBh Y2NlcHRhYmxlIGdyb3VwIGlzIGEg4oCcaGFuZHNoYWtlX2ZhaWx1cmXigJ0gZXJyb3IuIEkgY2hh bmdlZCB0aGUgdGV4dCB0byBzdGF0ZSB0aGUgZXJyb3IgZm9yIHN1aXRlcywgYXMgdGhlIG90aGVy IGlzIGFscmVhZHkgbm90ZWQgZWxzZXdoZXJlLiAodGhpcyBjaGFuZ2UgaXMgbm93IGluIFBSICMy MDEpIFRoaXMgYnJpbmdzIHVwIGEgcHJvYmxlbSwgaG93ZXZlcjogdGhlcmUgaXMgbm8gZGlzdGlu Y3QgZXJyb3IgZm9yIGxhY2sgb2YgZ3JvdXAgc3VwcG9ydC4gVGhlIOKAnGhhbmRzaGFrZV9mYWls dXJl4oCdIGlzIGEgYml0IG9mIGEgY2F0Y2hhbGwsIHNvIHRoZXJlJ3Mgbm8gd2F5IGZvciBhIGNs aWVudCB0byByZWFsbHkga25vdyB3aGF0J3Mgd3JvbmcgaWYgdGhpcyBoYXBwZW5zLiBUaGlzIGlz IGFsc28gd2h5IEkgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgdGhlIGRlZmluaXRpb24gb2YgdGhlICJp bnN1ZmZpY2llbnRfc2VjdXJpdHkiIGVycm9yLiBDbGllbnRzIHJlbHkgb24gdGhlc2UgYmVpbmcg cmVsYXRpdmVseSBwcmVjaXNlIGluIG9yZGVyIHRvIHNob3cgZXJyb3IgbWVzc2FnZXMgdGhhdCBh cmUgaG9wZWZ1bGx5IG1lYW5pbmdmdWwgZW5vdWdoIHRvIGdldCB0aGVtIGZpeGVkLiBBcyBzdWNo LCBJJ2QgbGlrZSB0byBwcm9wb3NlIGFkZGluZyBhIG5ldyBlcnJvciBqdXN0IGZvciB0aGlzIGFu ZCByZW5hbWluZyB0aGUgb2xkIG9uZSB0byBmb2N1cyBwcmVjaXNlbHkgb24gaXRzIGxvbmcgZGVm aW5lZCBtZWFuaW5nLiBXaGlsZSB3ZSdyZSBhdCBpdCwgYSBmYWlsdXJlIG9mIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBkb2Vzbid0IGhhdmUgaXRzIG93biBlcnJvciBhbGVydCBjb2RlIGVpdGhlci4K CiAgZW51bSB7CiAgICAgICBoYW5kc2hha2VfZmFpbHVyZSg0MCksCiAgICAgICB1bnN1cHBvcnRl ZF9jaXBoZXJfc3VpdGVzKDcxKSwgIC8qIGZvcm1lcmx5IGluc3VmZmljaWVudF9zZWN1cml0eSAq LwogICAgICAgdW5zdXBwb3J0ZWRfZGhfZ3JvdXBzKDcyKSwgIC8qIG5ldyAqLwogICAgICAgY2xp ZW50X2F1dGhlbnRpY2F0aW9uX2ZhaWx1cmUoNzMpLCAgLyogbmV3ICovCiAgICAgICAoMjU1KQog ICB9IEFsZXJ0RGVzY3JpcHRpb247CgpQcmV0dHkgc3RyYWlnaHRmb3J3YXJkLiBBcmUgdGhlcmUg YW55IG90aGVyIGVycm9ycyB0aGF0IGNhbid0IGJlIGNsZWFybHkgaWRlbnRpZmllZCBieSB0aGUg cmV0dXJuZWQgY29kZT8gRGVidWdnaW5nIHNob3VsZG4ndCBiZSBndWVzc3dvcmsuIDspCgoKRGF2 ZQo= From nobody Wed Jul 22 19:51:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D331A8883 for ; Wed, 22 Jul 2015 19:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 NjplAKS6wNau for ; Wed, 22 Jul 2015 19:50:55 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E321A8861 for ; Wed, 22 Jul 2015 19:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1437619854; x=1469155854; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=P43wgJtUGGRkdTWtTZLtWjjKC4cJoeMuJEFh740iqZg=; b=wQyEwLz5qr06Ys4keDTfc+rB+iJ/h9O4uF7wGtN/DbierZyzY+u9QCFm J9ibnQuiGbWoWQqkRntovqtdMxKU6Uzk5T3Or8Wrk0YHSjqsVt0F1GCOt VpiujmVvfsNREPfGOKXZecCVOJwTop0GllbTgqE8rd/n4tldMsg4O+2uy xLQZVQHA65dSOXXh8Ve+KF7dwFr1rM6CAH9z+Fv9DA+bFzuy12DOjtKwh GCFw0xpAt9l3MAvVlyeJ+h9v6G/f8wdb1w0Bk4n6Bj2nTb0h0ElIZKkIF FFqtbMznDnEPo2oV3oSQ9MKAolf+Ed0G6LSxzrPPLijae/lD45agjpRad Q==; X-IronPort-AV: E=Sophos;i="5.15,527,1432555200"; d="scan'208";a="30120602" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Jul 2015 14:50:52 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 23 Jul 2015 14:50:52 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] A la carte handshake negotiation Thread-Index: AdDE8mNqdt9tbqxyQpSNJggOd5zCFg== Date: Thu, 23 Jul 2015 02:50:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB06B5CB@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: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 02:50:59 -0000 Kyle Rose writes:=0A= =0A= >In that case, we should dispense with any larger key sizes and recommend= =0A= >exactly one per algorithm, and vary only on algorithm. Adopting this would= =0A= >simplify things even further by reducing the cipher set list by an order o= f=0A= >magnitude.=0A= =0A= Yup.=0A= =0A= >Sadly, I'm guessing there are numerological requirements in various standa= rds=0A= >and regulations that make it necessary to keep both AES-128 and AES-256=0A= >around, for example. There are also a ton of existing 2048-bit RSA keys th= at=0A= >aren't going anywhere for a while.=0A= =0A= You could just say "anything over 1536 bits, 1536 or 2048 recommended", whi= ch=0A= would deal with both.=0A= =0A= >I'm also skeptical of statements like "Using any known technology it's=0A= >unlikely that humans can ever get beyond about 2^^100 operations", because= =0A= >that's true exactly up until it isn't.=0A= =0A= Right, but if you're going to use that argument then AES is breakable until= it=0A= isn't, you can't find SHA-256 collisions until you can, quantum crypto can = be=0A= broken by whoever you're afraid of, and so on.=0A= =0A= One thing we've become pretty good at doing is taking current progress on= =0A= breaking crypto and mapping out what'll happen in the future, to the point= =0A= where there have been zero sudden breaks of properly-designed algorithms (D= ES,=0A= AES, IDEA, SHA, RSA, DH, and so on), ever. In every case we've been able t= o=0A= see, from a long way off, what's in store.=0A= =0A= And to see what's in store for PKCs, you can't use the computers used by=0A= mathematicians/numerologists, which all have infinite amounts of=0A= zero-cycle-time memory, but the ones that actually exist in the real world.= =0A= For a 1024-bit RSA key that's around 40 terabytes of memory for the final= =0A= step, and a 1280-bit key would require roughly a petabyte of RAM, all in a= =0A= single machine or a single-machine equivalent (a standard distributed clust= er=0A= won't work because of interconnect latency problems). So you'd need to=0A= dedicate the entire Tianhe-2 to breaking a single 1280-bit key (I don't kno= w=0A= how its memory architecture will affect performance, I just chose the world= 's=0A= most powerful supercomputer because that happens to be barely enough to att= ack=0A= a 1280-bit key, so I'm not sure how many years of time you'd need).=0A= =0A= Or you could just backdoor the server, which is what'll actually happen to= =0A= anyone who wants to get in. Heck, just the interest on the power bill for = the=0A= Tianhe-2 (if you assume the computer itself comes for free) would be enough= to=0A= bribe most of the maintenance staff to plug in a trojan USB key for a minut= e=0A= or two while they're cleaning.=0A= =0A= And if you really are concerned about China secretly building a second=0A= Tianhe-2 and using it to attack your mail server, just change your key once= a=0A= year and you're OK.=0A= =0A= Peter.=0A= =0A= From nobody Wed Jul 22 22:03:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C801A1AC9 for ; Wed, 22 Jul 2015 22:03:06 -0700 (PDT) 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 3QPxscAQ51gg for ; Wed, 22 Jul 2015 22:03:05 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69481A1AB5 for ; Wed, 22 Jul 2015 22:03:04 -0700 (PDT) Received: by wibud3 with SMTP id ud3so200972967wib.0 for ; Wed, 22 Jul 2015 22:03:03 -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=t0d4X8z7y/6pAEQdcmCoBSAYEAq3tzyf6lKgSjj6UAM=; b=fDE7n0qX9AgHQAOaRHlwARDR00ftH3MVo6QjpBuQO8DB48R774zjm+5Nudo4VloKG4 AHvDuGmvpG0Pl1QAqZu9WgkpiDPAGp7XxwiXiJXrxEHC0v5GMSD0vfDZ3xdcSGeczMe9 NQjqSX0XFRJ1A4J68jPRuO8hYt66/jkS/CWwsC82arhslDew+F16vq9ugLzVCiEK1AMB BlKiy13P5jhuIWNIy6jTPHgdpZ50UjGUeNyvf0VPbrSBgLlwwABN1iSStK64ZoiyYGdF RM2T9sokLtEkObuRvGwLl5cbe6YATy3tGNtTeTh5d7zcj9MWJN2N+tSXZjQG28rehdY0 +H5Q== X-Gm-Message-State: ALoCoQlnDPy/7ZWux2//X5R1gz7N+kDEzlVG89LZQPWt+aQETzdAciqDt6ktLTBTialaoaLZmqHF X-Received: by 10.180.75.78 with SMTP id a14mr13488960wiw.68.1437627783567; Wed, 22 Jul 2015 22:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Wed, 22 Jul 2015 22:02:24 -0700 (PDT) In-Reply-To: References: <45822829-5DA1-4AA8-9317-BE4D4AEC41E6@fb.com> From: Eric Rescorla Date: Thu, 23 Jul 2015 07:02:24 +0200 Message-ID: To: Bill Frantz Content-Type: multipart/alternative; boundary=f46d0438eb9d5bf1df051b83cdfb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 05:03:06 -0000 --f46d0438eb9d5bf1df051b83cdfb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz wrote: > One place we may run into a lot of those clients are on machines like the > Raspberry Pi and Beaglebone machines. These boards do not include clock > chips, so the machines must get the current time via NTP every time they > power on. If there is a problem with NTP, or if the shell script to set t= he > clock is not run, then the date will probably be 20 or 30 years back in t= he > last millenium. > That's definitely a problem, but not a specific problem for ServerConfiguration since those implementations will also have problems with certificates (and ironically, will accept ServerConfiguration just fine) -Ekr Cheers - Bill > > On 7/22/15 at 2:14 PM, bmatheny@fb.com (Blake Matheny) wrote: > > Ahh. I can't tell, the data I have is only clients with very very broken >> clocks who failed validation as a result. My assumption would be that th= ere >> is a much larger number of clients that fit what you described (cert/OCS= P >> check passes, but ServerConfiguration would not be). Since I don=E2=80= =99t have the >> data, I can=E2=80=99t say that for sure, but anecdotal evidence would in= dicate that >> this is the case. >> >> -Blake >> >> >> >> >> On 7/22/15, 10:58 PM, "Eric Rescorla" wrote: >> >> I guess what I'm trying to get at is the following: >>> Are there a lot of people whose clocks are accurate enough that they >>> will be able to connect to the >>> >> server and check the certificate/OCSP but not accurate enough to process >> ServerConfiguration if it is in absolute time. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> ----------------------------------------------------------------------- > Bill Frantz | Ham radio contesting is a | Periwinkle > (408)356-8506 | contact sport. | 16345 Englewood Ave > www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 > > --f46d0438eb9d5bf1df051b83cdfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz <frantz@pwpconsult.co= m> wrote:
One place we may = run into a lot of those clients are on machines like the Raspberry Pi and B= eaglebone machines. These boards do not include clock chips, so the machine= s must get the current time via NTP every time they power on. If there is a= problem with NTP, or if the shell script to set the clock is not run, then= the date will probably be 20 or 30 years back in the last millenium.

That's definitely a problem, but not a s= pecific problem for ServerConfiguration since those implementations will al= so have problems
with certificates (and ironically, will accept S= erverConfiguration just fine)

-Ekr

<= /div>
Cheers - Bill

On 7/22/15 at 2:14 PM, bmatheny@fb.com (Blake Matheny) wrote:

Ahh. I can't tell, the data I have is only clients with very very broke= n clocks who failed validation as a result. My assumption would be that the= re is a much larger number of clients that fit what you described (cert/OCS= P check passes, but ServerConfiguration would not be). Since I don=E2=80=99= t have the data, I can=E2=80=99t say that for sure, but anecdotal evidence = would indicate that this is the case.

-Blake




 On 7/22/15, 10:58 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:

I guess what I'm trying to get at is the following:
Are there a lot of people whose clocks are accurate enough that they will b= e able to connect to the
server and check the certificate/OCSP but not accurate enough to process Se= rverConfiguration if it is in absolute time.
 _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

-----------------------------------------------------------------------
Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Ham radio contesting is a=C2=A0 = =C2=A0 | Periwinkle
= (408)356-8506=C2=A0 =C2=A0 =C2=A0 | contact sport.=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 16345 Englewood Ave
= www.pwpconsult.com |=C2=A0 - Ken Widelitz K6LA / VY2TT | Los Gatos, CA = 95032


--f46d0438eb9d5bf1df051b83cdfb-- From nobody Thu Jul 23 01:24:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B401A8ABD for ; Thu, 23 Jul 2015 01:24:24 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 SJEyyjd0t4qE for ; Thu, 23 Jul 2015 01:24:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6DA1A8AAA for ; Thu, 23 Jul 2015 01:24:22 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 23 Jul 2015 08:24:20 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Thu, 23 Jul 2015 08:24:20 +0000 From: Andrei Popov To: Eric Rescorla , Bill Frantz Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dZ3n6FoAgAAPa4CAAAEWAIAABIqAgABJxgCAADjqAIAANzGQ Date: Thu, 23 Jul 2015 08:24:20 +0000 Message-ID: References: <45822829-5DA1-4AA8-9317-BE4D4AEC41E6@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none; x-originating-ip: [90.181.160.186] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:rgUvtX4/C8jMxrd1QYbqxyUXBmVQ9fPVrIfrl4KH/gbbNFSqbptrh7goyEZRbXR7ygXqZJV4IeUiPPD53jYi9css0V2F3asbUqXznXWnD0lJUr7x4VZY9nDzAzuFTNA56CdJ9Rz3SDTJg8X8mX8oyA==; 24:nilJgKdzX3M8Zge5sLu0/cpi1zJaBrgwlIjE3YdeaWOCJqx0EAzWdfLcNhrnENElBn921sgV+BK+tSWdW5v4ZtvMbU2UVmKMmwwvE6OI6/4=; 20:vd8k1UCDTcgGitzccWd8v0Uk5RHpoRukPAoF43apiFW/9RFY6SWVjXPq+vW1RBItxhnlX9JfiwUSX2stSjKP7Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; blupr03mb1396: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(377454003)(24454002)(54356999)(77096005)(66066001)(62966003)(33656002)(16601075003)(77156002)(19580405001)(15975445007)(99286002)(102836002)(189998001)(19625215002)(19617315012)(5003600100002)(106116001)(76176999)(2950100001)(87936001)(76576001)(16236675004)(2656002)(5001920100001)(5001960100002)(46102003)(19300405004)(122556002)(19580395003)(5001770100001)(10090500001)(92566002)(74316001)(5002640100001)(40100003)(86362001)(19609705001)(2900100001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396A23A468A6FE6CFF0B3DD8C820BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2015 08:24:20.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 08:24:24 -0000 --_000_BLUPR03MB1396A23A468A6FE6CFF0B3DD8C820BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3VyIHRlbGVtZXRyeSBzaG93cyB0aGF0IHRoZXJlIGFyZSB0b25zIG9mIG1hY2hpbmVzIChpbmNs dWRpbmcgcmVjZW50bHkgbWFudWZhY3R1cmVkIHRhYmxldHMpIHdpdGhvdXQgcGVyc2lzdGVudCBj bG9ja3MgKGkuZS4gbm8gYmF0dGVyeSBwb3dlcmluZyB0aGUgc3lzdGVtIGNsb2NrKS4gU3VjaCBt YWNoaW5lcyBpbmRlZWQgYm9vdCB3aXRoIGRhdGUvdGltZSBpbiB0aGUgcGFzdCBtaWxsZW5uaXVt OyB0aGV5IGNhbm5vdCBoYXJkLWZhaWwgb24gT0NTUCBlcnJvcnMgKHdoaWNoIGdyZWF0bHkgcmVk dWNlcyB0aGUgdmFsdWUgb2YgT0NTUCkuDQoNCklmIHdlIGNhbiBhdm9pZCBjcmVhdGluZyB0aGUg c2FtZSBpc3N1ZSBmb3IgU2VydmVyQ29uZmlndXJhdGlvbiwgSSB0aGluayB3ZSBzaG91bGQuDQoN CkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMjMs IDIwMTUgNzowMiBBTQ0KVG86IEJpbGwgRnJhbnR6DQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW1RMU10gUmVsYXRpdmUgdnMgYWJzb2x1dGUgU2VydmVyQ29uZmlndXJhdGlvbi5leHBp cmF0aW9uX2RhdGUNCg0KDQoNCk9uIFRodSwgSnVsIDIzLCAyMDE1IGF0IDM6MzggQU0sIEJpbGwg RnJhbnR6IDxmcmFudHpAcHdwY29uc3VsdC5jb208bWFpbHRvOmZyYW50ekBwd3Bjb25zdWx0LmNv bT4+IHdyb3RlOg0KT25lIHBsYWNlIHdlIG1heSBydW4gaW50byBhIGxvdCBvZiB0aG9zZSBjbGll bnRzIGFyZSBvbiBtYWNoaW5lcyBsaWtlIHRoZSBSYXNwYmVycnkgUGkgYW5kIEJlYWdsZWJvbmUg bWFjaGluZXMuIFRoZXNlIGJvYXJkcyBkbyBub3QgaW5jbHVkZSBjbG9jayBjaGlwcywgc28gdGhl IG1hY2hpbmVzIG11c3QgZ2V0IHRoZSBjdXJyZW50IHRpbWUgdmlhIE5UUCBldmVyeSB0aW1lIHRo ZXkgcG93ZXIgb24uIElmIHRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIE5UUCwgb3IgaWYgdGhlIHNo ZWxsIHNjcmlwdCB0byBzZXQgdGhlIGNsb2NrIGlzIG5vdCBydW4sIHRoZW4gdGhlIGRhdGUgd2ls bCBwcm9iYWJseSBiZSAyMCBvciAzMCB5ZWFycyBiYWNrIGluIHRoZSBsYXN0IG1pbGxlbml1bS4N Cg0KVGhhdCdzIGRlZmluaXRlbHkgYSBwcm9ibGVtLCBidXQgbm90IGEgc3BlY2lmaWMgcHJvYmxl bSBmb3IgU2VydmVyQ29uZmlndXJhdGlvbiBzaW5jZSB0aG9zZSBpbXBsZW1lbnRhdGlvbnMgd2ls bCBhbHNvIGhhdmUgcHJvYmxlbXMNCndpdGggY2VydGlmaWNhdGVzIChhbmQgaXJvbmljYWxseSwg d2lsbCBhY2NlcHQgU2VydmVyQ29uZmlndXJhdGlvbiBqdXN0IGZpbmUpDQoNCi1Fa3INCg0KQ2hl ZXJzIC0gQmlsbA0KDQpPbiA3LzIyLzE1IGF0IDI6MTQgUE0sIGJtYXRoZW55QGZiLmNvbTxtYWls dG86Ym1hdGhlbnlAZmIuY29tPiAoQmxha2UgTWF0aGVueSkgd3JvdGU6DQpBaGguIEkgY2FuJ3Qg dGVsbCwgdGhlIGRhdGEgSSBoYXZlIGlzIG9ubHkgY2xpZW50cyB3aXRoIHZlcnkgdmVyeSBicm9r ZW4gY2xvY2tzIHdobyBmYWlsZWQgdmFsaWRhdGlvbiBhcyBhIHJlc3VsdC4gTXkgYXNzdW1wdGlv biB3b3VsZCBiZSB0aGF0IHRoZXJlIGlzIGEgbXVjaCBsYXJnZXIgbnVtYmVyIG9mIGNsaWVudHMg dGhhdCBmaXQgd2hhdCB5b3UgZGVzY3JpYmVkIChjZXJ0L09DU1AgY2hlY2sgcGFzc2VzLCBidXQg U2VydmVyQ29uZmlndXJhdGlvbiB3b3VsZCBub3QgYmUpLiBTaW5jZSBJIGRvbuKAmXQgaGF2ZSB0 aGUgZGF0YSwgSSBjYW7igJl0IHNheSB0aGF0IGZvciBzdXJlLCBidXQgYW5lY2RvdGFsIGV2aWRl bmNlIHdvdWxkIGluZGljYXRlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZS4NCg0KLUJsYWtlDQoNCg0K DQoNCk9uIDcvMjIvMTUsIDEwOjU4IFBNLCAiRXJpYyBSZXNjb3JsYSIgPGVrckBydGZtLmNvbTxt YWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpJIGd1ZXNzIHdoYXQgSSdtIHRyeWluZyB0byBn ZXQgYXQgaXMgdGhlIGZvbGxvd2luZzoNCkFyZSB0aGVyZSBhIGxvdCBvZiBwZW9wbGUgd2hvc2Ug Y2xvY2tzIGFyZSBhY2N1cmF0ZSBlbm91Z2ggdGhhdCB0aGV5IHdpbGwgYmUgYWJsZSB0byBjb25u ZWN0IHRvIHRoZQ0Kc2VydmVyIGFuZCBjaGVjayB0aGUgY2VydGlmaWNhdGUvT0NTUCBidXQgbm90 IGFjY3VyYXRlIGVub3VnaCB0byBwcm9jZXNzIFNlcnZlckNvbmZpZ3VyYXRpb24gaWYgaXQgaXMg aW4gYWJzb2x1dGUgdGltZS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KQmlsbCBGcmFudHogICAgICAgIHwgSGFtIHJhZGlvIGNvbnRlc3RpbmcgaXMgYSAg ICB8IFBlcml3aW5rbGUNCig0MDgpMzU2LTg1MDY8dGVsOiUyODQwOCUyOTM1Ni04NTA2PiAgICAg IHwgY29udGFjdCBzcG9ydC4gICAgICAgICAgICAgICB8IDE2MzQ1IEVuZ2xld29vZCBBdmUNCnd3 dy5wd3Bjb25zdWx0LmNvbTxodHRwOi8vd3d3LnB3cGNvbnN1bHQuY29tPiB8ICAtIEtlbiBXaWRl bGl0eiBLNkxBIC8gVlkyVFQgfCBMb3MgR2F0b3MsIENBIDk1MDMyDQoNCg== --_000_BLUPR03MB1396A23A468A6FE6CFF0B3DD8C820BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk91ciB0ZWxlbWV0cnkgc2hvd3MgdGhhdCB0 aGVyZSBhcmUgdG9ucyBvZiBtYWNoaW5lcyAoaW5jbHVkaW5nIHJlY2VudGx5IG1hbnVmYWN0dXJl ZCB0YWJsZXRzKSB3aXRob3V0IHBlcnNpc3RlbnQgY2xvY2tzIChpLmUuIG5vIGJhdHRlcnkgcG93 ZXJpbmcgdGhlIHN5c3RlbSBjbG9jaykuDQogU3VjaCBtYWNoaW5lcyBpbmRlZWQgYm9vdCB3aXRo IGRhdGUvdGltZSBpbiB0aGUgcGFzdCBtaWxsZW5uaXVtOyB0aGV5IGNhbm5vdCBoYXJkLWZhaWwg b24gT0NTUCBlcnJvcnMgKHdoaWNoIGdyZWF0bHkgcmVkdWNlcyB0aGUgdmFsdWUgb2YgT0NTUCku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBjYW4gYXZv aWQgY3JlYXRpbmcgdGhlIHNhbWUgaXNzdWUgZm9yIFNlcnZlckNvbmZpZ3VyYXRpb24sIEkgdGhp bmsgd2Ugc2hvdWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDIzLCAyMDE1IDc6MDIgQU08YnI+DQo8Yj5Ubzo8 L2I+IEJpbGwgRnJhbnR6PGJyPg0KPGI+Q2M6PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtUTFNdIFJlbGF0aXZlIHZzIGFic29sdXRlIFNlcnZlckNvbmZpZ3VyYXRp b24uZXhwaXJhdGlvbl9kYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwg MjMsIDIwMTUgYXQgMzozOCBBTSwgQmlsbCBGcmFudHogJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFu dHpAcHdwY29uc3VsdC5jb20iIHRhcmdldD0iX2JsYW5rIj5mcmFudHpAcHdwY29uc3VsdC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbmUgcGxhY2Ugd2UgbWF5IHJ1biBpbnRvIGEgbG90IG9mIHRob3NlIGNsaWVudHMg YXJlIG9uIG1hY2hpbmVzIGxpa2UgdGhlIFJhc3BiZXJyeSBQaSBhbmQgQmVhZ2xlYm9uZSBtYWNo aW5lcy4gVGhlc2UgYm9hcmRzIGRvIG5vdCBpbmNsdWRlIGNsb2NrIGNoaXBzLCBzbyB0aGUgbWFj aGluZXMgbXVzdCBnZXQgdGhlIGN1cnJlbnQgdGltZSB2aWEgTlRQIGV2ZXJ5IHRpbWUgdGhleSBw b3dlciBvbi4gSWYgdGhlcmUNCiBpcyBhIHByb2JsZW0gd2l0aCBOVFAsIG9yIGlmIHRoZSBzaGVs bCBzY3JpcHQgdG8gc2V0IHRoZSBjbG9jayBpcyBub3QgcnVuLCB0aGVuIHRoZSBkYXRlIHdpbGwg cHJvYmFibHkgYmUgMjAgb3IgMzAgeWVhcnMgYmFjayBpbiB0aGUgbGFzdCBtaWxsZW5pdW0uPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGF0J3MgZGVmaW5pdGVseSBhIHByb2JsZW0sIGJ1dCBub3QgYSBzcGVjaWZpYyBwcm9ibGVt IGZvciBTZXJ2ZXJDb25maWd1cmF0aW9uIHNpbmNlIHRob3NlIGltcGxlbWVudGF0aW9ucyB3aWxs IGFsc28gaGF2ZSBwcm9ibGVtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+d2l0aCBjZXJ0aWZpY2F0ZXMgKGFuZCBpcm9uaWNhbGx5LCB3aWxsIGFj Y2VwdCBTZXJ2ZXJDb25maWd1cmF0aW9uIGp1c3QgZmluZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMgLSBCaWxsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDcvMjIvMTUgYXQgMjoxNCBQTSwgPGEgaHJl Zj0ibWFpbHRvOmJtYXRoZW55QGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJtYXRoZW55QGZiLmNv bTwvYT4gKEJsYWtlIE1hdGhlbnkpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWhoLiBJ IGNhbid0IHRlbGwsIHRoZSBkYXRhIEkgaGF2ZSBpcyBvbmx5IGNsaWVudHMgd2l0aCB2ZXJ5IHZl cnkgYnJva2VuIGNsb2NrcyB3aG8gZmFpbGVkIHZhbGlkYXRpb24gYXMgYSByZXN1bHQuIE15IGFz c3VtcHRpb24gd291bGQgYmUgdGhhdCB0aGVyZSBpcyBhIG11Y2ggbGFyZ2VyIG51bWJlciBvZiBj bGllbnRzIHRoYXQgZml0IHdoYXQgeW91IGRlc2NyaWJlZA0KIChjZXJ0L09DU1AgY2hlY2sgcGFz c2VzLCBidXQgU2VydmVyQ29uZmlndXJhdGlvbiB3b3VsZCBub3QgYmUpLiBTaW5jZSBJIGRvbuKA mXQgaGF2ZSB0aGUgZGF0YSwgSSBjYW7igJl0IHNheSB0aGF0IGZvciBzdXJlLCBidXQgYW5lY2Rv dGFsIGV2aWRlbmNlIHdvdWxkIGluZGljYXRlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZS48YnI+DQo8 YnI+DQotQmxha2U8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiA3LzIyLzE1LCAxMDo1 OCBQTSwgJnF1b3Q7RXJpYyBSZXNjb3JsYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBy dGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3Mgd2hh dCBJJ20gdHJ5aW5nIHRvIGdldCBhdCBpcyB0aGUgZm9sbG93aW5nOjxicj4NCkFyZSB0aGVyZSBh IGxvdCBvZiBwZW9wbGUgd2hvc2UgY2xvY2tzIGFyZSBhY2N1cmF0ZSBlbm91Z2ggdGhhdCB0aGV5 IHdpbGwgYmUgYWJsZSB0byBjb25uZWN0IHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5z ZXJ2ZXIgYW5kIGNoZWNrIHRoZSBjZXJ0aWZpY2F0ZS9PQ1NQIGJ1dCBub3QgYWNjdXJhdGUgZW5v dWdoIHRvIHByb2Nlc3MgU2VydmVyQ29uZmlndXJhdGlvbiBpZiBpdCBpcyBpbiBhYnNvbHV0ZSB0 aW1lLjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpCaWxsIEZyYW50eiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8IEhhbSByYWRpbyBjb250ZXN0aW5nIGlzIGEmbmJzcDsgJm5ic3A7IHwgUGVyaXdp bmtsZTxicj4NCjxhIGhyZWY9InRlbDolMjg0MDglMjkzNTYtODUwNiIgdGFyZ2V0PSJfYmxhbmsi Pig0MDgpMzU2LTg1MDY8L2E+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBjb250YWN0IHNwb3J0LiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IDE2 MzQ1IEVuZ2xld29vZCBBdmU8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LnB3cGNvbnN1bHQuY29t IiB0YXJnZXQ9Il9ibGFuayI+d3d3LnB3cGNvbnN1bHQuY29tPC9hPiB8Jm5ic3A7IC0gS2VuIFdp ZGVsaXR6IEs2TEEgLyBWWTJUVCB8IExvcyBHYXRvcywgQ0EgOTUwMzI8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB1396A23A468A6FE6CFF0B3DD8C820BLUPR03MB1396namp_-- From nobody Thu Jul 23 03:50:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA321A1A06 for ; Thu, 23 Jul 2015 03:50:30 -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 8qrfi-4QELiR for ; Thu, 23 Jul 2015 03:50:29 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F381A033A for ; Thu, 23 Jul 2015 03:50:28 -0700 (PDT) Received: by wibud3 with SMTP id ud3so18271700wib.1 for ; Thu, 23 Jul 2015 03:50:27 -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 :cc:subject:references:in-reply-to:content-type; bh=LcHUPzKmDpdvOTfMAWZWAduRUJvC5XsURRicW986Q/g=; b=hWfuCVNqZTc+aQ7dSX+i8wH6vMrEHjQ1vSvHUF6vFaellXVQV38NIMTSdREL5rlWyw wbgV0sVrsm9turz0ZdOxSAYZXYXApU1wnyZsJYlNtVeOMEnQTlAPZoWvA6tkefq0jxWg zLa98mZp5u5W0r0P7kOnolXXgMgPJEpDiqmRRfU79uv/+Y3nRNk1zvw7Iug37Wy9YH7A D0ga5d1P+XBVTncK4dNrzphYkNtbrdwMHOnQb66KzAEqBO50XjdB+17A/7IYekHsj1RM wNrgL9ctz1LZZHep7sOpEnE2tds/FTIzCySSoEkSu5YZic3s7J8cDMJIWIL5Aa1AMM2K rqxw== X-Gm-Message-State: ALoCoQk0qPw1/5eEoiIWoKFgdSZUkuPcB22UCZmonvGPpFTUJ6s041RQwdXc8c/fhiynE9eKYvoT X-Received: by 10.194.77.97 with SMTP id r1mr13911682wjw.98.1437648627649; Thu, 23 Jul 2015 03:50:27 -0700 (PDT) Received: from [31.133.162.148] (dhcp-a294.meeting.ietf.org. [31.133.162.148]) by smtp.gmail.com with ESMTPSA id di7sm7885232wib.23.2015.07.23.03.50.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 03:50:26 -0700 (PDT) Message-ID: <55B0C6A2.40304@azet.org> Date: Thu, 23 Jul 2015 12:49:06 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201507222139.46391.davemgarrett@gmail.com> In-Reply-To: <201507222139.46391.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE34FE0F6851A90ED22667D62" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Thu, 23 Jul 2015 10:50:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE34FE0F6851A90ED22667D62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dave, Dave Garrett wrote: >=20 > enum { > handshake_failure(40), > unsupported_cipher_suites(71), /* formerly insufficient_securit= y */ > unsupported_dh_groups(72), /* new */ > client_authentication_failure(73), /* new */ > (255) > } AlertDescription; >=20 I mean I kinda agree that 'insufficent security' is a misleading name, but as it has been used for decades in TLS I'm a bit hesitant if it's a good idea to change the name now. Aaron --------------enigE34FE0F6851A90ED22667D62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVsMajAAoJEOTbZJL9ubXVKusQAKHhMv7u2J6/rblCKXTyD7tI PY5C6X1PdBXseW4wY/DRIZ0jrb0VLCl+SvLnWstJ0IlFZjQRnD6ksNYw7cuWddwc 17WEA652yyB4vOOWTt6mHGIv2/A9JrwZN+BPN3qHvRfcAnSIM8bGCpqOcmUG55Tj 4K36XDmsxXynGvhVye8G6hzj1XRhVUMlwQW51Pj4hQjz8XTBnSFm1X0yoiJs3bkZ O3gIUjfBWBwmDN4Mt1J2YvZL+u5HsBTuiImFqTfEG6FQcbP93GYP4C/UA8ZfaKZh s/LZH6AWfsloBk/F6V7m4t4ng26ecTcHVlzKVlVzKCs3PO5KMEKVYPR2NCTgeUlz 5aE0C2hyi9Q2ZTHz+l1qmjlv/cjJNlJ793yjpiL4xSV6GU/9ZtSvUkwJyCEvckJ+ 2Oy4NOUkBrB9+5s3Oeoe7el/13RQsh1lPUz2jcoIJG0VcmZEzTLigI83pHy9sByY dQuVsrIcQnIaN+/qBnWVCwSg3oDyHdfFQMEWCOtmfoQ9ZQ5HHaaL8m5UbzB3VVPZ 1AaIyzm5vWzQIm2wrYunvSpG3vBSaMxOTUAo+ue25wgQ6Cc21MEbyUL2TwCZl7mz k73WShprpxK1RFlJOisFuQQ/5KQFMjxyKI1OVWEmS1wi4ehmFVSollgjSlrijYvW MnjG4I0pGrRwF53na50p =YhFZ -----END PGP SIGNATURE----- --------------enigE34FE0F6851A90ED22667D62-- From nobody Thu Jul 23 04:10:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7141A8729 for ; Thu, 23 Jul 2015 04:10:02 -0700 (PDT) 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 M2NA1WK1THjo for ; Thu, 23 Jul 2015 04:10:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304A41A872A for ; Thu, 23 Jul 2015 04:10:01 -0700 (PDT) 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 (Postfix) with ESMTPS id C734F42891E; Thu, 23 Jul 2015 11:10:00 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-79.ams2.redhat.com [10.36.112.79]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6NB9uue029323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2015 07:09:59 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 23 Jul 2015 13:09:49 +0200 Message-ID: <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <201507221610.27729.davemgarrett@gmail.com> References: <201507221610.27729.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2130764.cYrfbPgWRb"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] A la carte concerns from IETF 93 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 11:10:02 -0000 --nextPart2130764.cYrfbPgWRb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 22 July 2015 16:10:27 Dave Garrett wrote: > Consensus was my current WIP proposal is not viable, for some of the > following main reasons: >=20 > 1) cost/benefit analysis doesn't seem to be worth it > 2) backwards compatibility handling > 3) some argue harder to implement; others argue easier > > cost: > - change has risks of mistake at various points (implementation, depl= oyment, > admin, client config, etc.) and server/client config is a huge cost vast swaths of web servers are misconfigured; introducing a more comple= x=20 mechanism to server configuration when the existing situation is=20 incomprehensible to many administrators won't help (and even many peopl= e that=20 write the various blog posts about "how to configure SSL [sic] in httpd= "=20 clearly haven't read openssl ciphers(1) man page) any changes like this will require new APIs for configuration, that in = turn=20 means that not only libraries will need to be modified to add support f= or=20 TLS1.3 configuration but applications too - that will slow adoption =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2130764.cYrfbPgWRb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVsMuDAAoJEJKo0bgB0vX1BeQP/2gYRXx9egn2pAJDFZ59yku+ zgQslWilcf7QnsbrYxFKyJOYO5uX034gUXNZZns/IcpavI72OH+KDylbqJ6AiOSu pTZc/N/sH0cBG+XVgHDb8OGJymbi+vZp4DVE3U/rOeB/eZuw6UDnZxtI5D5v71y8 ojCShrwJkSn0XZQbEtB2N3uBvY+tYN4t/DDvJ3a400t8GQqnYNzqrWLEgeg4+Ix7 S2uIeCxvYx6Y50wwgCXvYfNrRDzSFMocVdbJurp4yW0jC0enIdKhP7j1FTU2rAT9 VLDe1vgD/WEMWh5nHWUne9uZIHNT21UWgQa3y3T+OMnIcH57BIX7tZ48VWBn2KQu oHUe3USg9uKoR3nPSYJTikR1f7KU104TKx24XwGVUJlFPQFF6Kc5XXHMpLWp2Gex Wmnu+kDPZPUFYrQlr9b0Gv5J8y0PKJRiesILEo1X5NH1KZjBWnTCHCHsDDH1DIig OYNRSQO00Knj02AThDyWBPWSqywASTXMh8XLXGfa4h1ek1bbVqdXwaozkGM84JgE rm+9LejDNAZ6Niv3ogslKdlXJaAX4kzycCQrMpMxIdcV55XBgEsDoHdQHGxywasc 32BbjPvdu3GocQajOMUgk2gUstw9+/FpRY6sLZjg14Hhsf2M7xVD7TDZusUouWN8 P+e3D+7eklaoUkT2URGa =k5SM -----END PGP SIGNATURE----- --nextPart2130764.cYrfbPgWRb-- From nobody Thu Jul 23 04:33:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5251A9062 for ; Thu, 23 Jul 2015 04:33:39 -0700 (PDT) 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 RKBdgzNK6Qrv for ; Thu, 23 Jul 2015 04:33:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA5B1A710C for ; Thu, 23 Jul 2015 04:33:35 -0700 (PDT) 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 (Postfix) with ESMTPS id 04BAE3674B0; Thu, 23 Jul 2015 11:17:04 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-79.ams2.redhat.com [10.36.112.79]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6NBH0t4029816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2015 07:17:04 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 23 Jul 2015 13:16:59 +0200 Message-ID: <8317321.tSLWD7hxNu@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> References: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2815115.eKH31EVcf4"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 11:33:39 -0000 --nextPart2815115.eKH31EVcf4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 22 July 2015 19:55:58 Blake Matheny wrote: > One of the topics of discussion at the WG discussion was whether > ServerConfiguration.expiration_date should be an absolute or relative= > value. Subodh (CC) dug into our production data and found that nearly= half > of the TLS errors we see in production (end user to edge/origin) are = due to > date mismatch. This often occurs when people intentionally reset the = clock > on their phone, or for other various reasons. =20 > Due to the high rate of date mismatch errors we see, my preference wo= uld be > that ServerConfiguration.expiration_date be a relative value instead = of an > absolute one. This provides the client an opportunity to correctly us= e a > monotonic (or other similar) clock to minimizing exposure, without lo= sing > the value of the ServerConfiguration. Using an absolute value means t= hat > ServerConfiguration, for clients with invalid clocks, would essential= ly > never be cacheable. These clients wouldn=E2=80=99t benefit from > ServerConfiguration. =20 the hint on tickets is already relative, so +1 on relative in server=20= configuration too =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2815115.eKH31EVcf4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVsM0rAAoJEJKo0bgB0vX1Hb0P/0qP0SG5da4D+1z9zEOKi8PP FWkQwpxBLk3hcUT8aAEtww806UhgbL2tZnGhFgpXyBBXjMFNnGbU8CYbuBxuTVn8 Sc0nB5kxWBr8F2hiR//A6Z+EVWN1iFBKSia5vDWLGlA0R/LTFIVOpyFFaA/RwQnX FcOHOFvCxPlSqMXOBbPZBBalmBhNij4CDZw5v5Q0lA0nUR7e0PC9YlUJiASgpFQc Zcb1X9MtTdv4FKnSCJRwlDzT2Tl/QbOK/t0N9EwfBMMN/BLKgfouYHgnYrqlubxm 5ckb3OQLs2jVFzI+lAHTanml65hSobuY191MrNBCi0wsrQcwowRj6Cc1wEtKPAV/ t1dZWgC60ygeqwa+8kuG/LeopTlgFZq7s42Ir29BV1TZsEpAqP1kSyacQA8OtjlI WXO35aGH0YbT6x36mBpcc/rhddab0FtUpN8jJqu85/fA+tBF8UyNatt+1/0M+4Oj puuGdshBRMCMt25DwicfAuAmAC3tl02M1IvsXbykF1E7c4hPEGXd26twKjAtalyA WVNo1YxtvIKTqv0INimsfFVBsztwAwh/AHnj5BdqdwQKHt8e4UStEFzp1MTsVHnQ NIAgDrFPhZxXwsDQ4dS67ppgRBu0s2pcJjBv7It8/hXhcUzsg4HGyXiRbYSpteef EvRX1L1/fTtUc7mn1375 =ovfY -----END PGP SIGNATURE----- --nextPart2815115.eKH31EVcf4-- From nobody Thu Jul 23 04:54:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C491A9234 for ; Thu, 23 Jul 2015 04:54:51 -0700 (PDT) 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 4jLLnQcziPaH for ; Thu, 23 Jul 2015 04:54:49 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673311A916F for ; Thu, 23 Jul 2015 04:54:49 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 75EA240D9; Thu, 23 Jul 2015 14:54:46 +0300 (EEST) Date: Thu, 23 Jul 2015 14:54:46 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150723115446.GA31576@LK-Perkele-VII> References: <201507221610.27729.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201507221610.27729.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A la carte concerns from IETF 93 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 11:54:51 -0000 On Wed, Jul 22, 2015 at 04:10:27PM -0400, Dave Garrett wrote: > Consensus was my current WIP proposal is not viable, for some of the following main reasons: > > 1) cost/benefit analysis doesn't seem to be worth it > 2) backwards compatibility handling > 3) some argue harder to implement; others argue easier IMO, the present situation is mainly problem for: 1) Users: Not having combinations they want (whitness the recent proposal for ECDHE_PSK ciphersuites). Sometimes leads to suboptimal ciphersuite choices. 2) TLS WG: Processing all the complaints about previous. 3) Admins: Configuring the mess. What isn't in the list: TLS library authors: Most TLS libraries have decoding tables (or equivalent) that break down ciphersuite down to its component parts. Using strict interpretation of TLS 1.2 rules, adding all the relevant combinations would be about 100 ciphersuites (haven't checked how many already exist). Granted, not all of those are equally important. But that brings question of what are important and what are not. Also, if SHA-2 ever fails, defining the replacement ciphersuites is going to be "fun". -Ilari From nobody Thu Jul 23 07:52:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20191ACEC4 for ; Thu, 23 Jul 2015 07:52:56 -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 bHLtrD8EO0Pb for ; Thu, 23 Jul 2015 07:52:55 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65101ACD4C for ; Thu, 23 Jul 2015 07:52:49 -0700 (PDT) Received: by qkdl129 with SMTP id l129so174730006qkd.0 for ; Thu, 23 Jul 2015 07:52:49 -0700 (PDT) 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=KeIrf1OMq0AzaUulPKqtOfoLFJmdbLMH77tnIwUjeb4=; b=nKdX4q6esteTTRk0d0rJGKMBcs3jZjhWpoYFruBDE9KxEq4CuhtGeF9dEvIBXH56U/ xKgDZWiOCIWvUNKOSr7kHew+8pScUkwPd4qCbbUiOXtPyKAKHk7hP1WiD5TfBlTh1GYi 4N4begc6dql7CcXSesFhD94rMZ3WKzwAmd+e2GwHoYsXru5iVZCdjDuovMRxUSM9Mwkq b2HXYeh1Ead5FVIP+841VZ07ff7pRXD061L6kXh2R3IEZ4FteRjIVkesMozUtJqqW+3x S60OZUlnUr4gkL6lgftmMuRJaCcXDcRy4/hcNaIzAfFKwdzr8pAGaHhq0qmkiBm2ADj9 8oTQ== X-Received: by 10.140.107.101 with SMTP id g92mr12374813qgf.58.1437663168990; Thu, 23 Jul 2015 07:52:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id e21sm2480690qhc.14.2015.07.23.07.52.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 07:52:48 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Thu, 23 Jul 2015 10:52:46 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507222139.46391.davemgarrett@gmail.com> <55B0C6A2.40304@azet.org> In-Reply-To: <55B0C6A2.40304@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507231052.47153.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Thu, 23 Jul 2015 14:52:56 -0000 On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote: > Dave Garrett wrote: > > > > enum { > > handshake_failure(40), > > unsupported_cipher_suites(71), /* formerly insufficient_security */ > > unsupported_dh_groups(72), /* new */ > > client_authentication_failure(73), /* new */ > > (255) > > } AlertDescription; > > I mean I kinda agree that 'insufficent security' is a misleading name, > but as it has been used for decades in TLS I'm a bit hesitant if it's a > good idea to change the name now. If that's really an issue, then it could just be insufficient_security, insufficient_dh_security, & client_authentication_failure. The name isn't as important as not producing errors without clear meanings. Dave From nobody Thu Jul 23 08:43:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1CB1ACE77 for ; Thu, 23 Jul 2015 08:43:50 -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 fok8BBn9pzYd for ; Thu, 23 Jul 2015 08:43:48 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B311AC39C for ; Thu, 23 Jul 2015 08:43:48 -0700 (PDT) Received: by qgeu79 with SMTP id u79so63736649qge.1 for ; Thu, 23 Jul 2015 08:43:47 -0700 (PDT) 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=f1ve0Gbcw3npCeKGxtnNarLlVSmPUOK6L50rhMZKaDc=; b=Ds0AOgl0kyNhe/fTjShdXrynIyuiYuTZz+Vpttk7UCgKoGbguhWDmLIuGhuYBQvGKy uj6JHVNzpaJwKempnQPhKBAkxkp2s69PVO5PKsaoFwcKJ3UQlvBbnZqvrLnwfXJSMhyl ZpKrDmMwJ09lJBodbS/ebiMR0PdbXF0Dloi2h8Ml0/dVc1sxJiiZUMoIyrFRHeaYFNJB oAYsNIfT9KSNCYzEYqAHFiXe0z3dTy6ItWwczTfHXSvhumwUDxD+8g9aGjo0PfVaXgS8 w6PHUm7clcoF34FuaItaONh/Kwg0LEY2E6IVTUUpmjBzaHgZgR7ElNDDxMdy7XUfCMXt pgjA== X-Received: by 10.140.23.102 with SMTP id 93mr12849889qgo.61.1437666227936; Thu, 23 Jul 2015 08:43:47 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id k16sm2565900qgd.23.2015.07.23.08.43.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 08:43:47 -0700 (PDT) From: Dave Garrett To: Hubert Kario Date: Thu, 23 Jul 2015 11:43:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507221610.27729.davemgarrett@gmail.com> <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> In-Reply-To: <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507231143.46288.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: [TLS] ban more old crap (was: A la carte concerns from IETF 93) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 15:43:50 -0000 On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote: > vast swaths of web servers are misconfigured; introducing a more complex > mechanism to server configuration when the existing situation is > incomprehensible to many administrators won't help (and even many people that > write the various blog posts about "how to configure SSL [sic] in httpd" > clearly haven't read openssl ciphers(1) man page) We should just get more serious about banning old crap entirely to make dangerous misconfiguration impossible for TLS 1.3+ implementations. Right now, the restrictions section prohibits: RC4, SSL2/3, & EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0, or abort with a fatal error. (the wrench in this is plain PSK, which should be restricted to resumption within a short window; IoT people who want to use intentionally weak security can write their own known weak spec) By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be badly configured to only allow it with DSS, because missing combos from the cipher suite nonsense happen. If we actually have to care about IE on XP, we could state an exception that the only non-PFS cipher suite to be permitted on servers for backwards compatibility is TLS_RSA_WITH_3DES_EDE_CBC_SHA. Also add a requirement that all config provided by the admin must be validated to meet the TLS 1.3 requirements and auto-corrected if not, with a warning if there's an issue. This doesn't have to be a mess for admins to sort out. Dave From nobody Thu Jul 23 09:00:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EA91A03A9 for ; Thu, 23 Jul 2015 09:00:38 -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 r0Rq-xZgo3Hy for ; Thu, 23 Jul 2015 09:00:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232A41A0195 for ; Thu, 23 Jul 2015 09:00:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4F2C5284B53; Thu, 23 Jul 2015 16:00:34 +0000 (UTC) Date: Thu, 23 Jul 2015 16:00:34 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150723160034.GV4347@mournblade.imrryr.org> References: <201507221610.27729.davemgarrett@gmail.com> <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> <201507231143.46288.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507231143.46288.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93) 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: Thu, 23 Jul 2015 16:00:38 -0000 On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote: > Right now, the restrictions section prohibits: > RC4, SSL2/3, & EXPORT/NULL entirely (via min bits) > and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available So much for using NULL ciphers for client-server authentication on loopback interfaces. :-( Surely, in at least some cases, making it harder to make mistakes needs to be addressed in toolkit and application interfaces, not the protocol. Removing weak algorithms that serve the same use-cases poorly is fine, but removing non-traditional use-cases is perhaps too drastic. > Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0, > or abort with a fatal error. Who's going to police the Internet to remove all the legacy services? > By the way, even IE6 on XP supports DHE. But not Exchange server 2003, and various Windows-based email gateway appliances. > If we actually have to care about IE on > XP, we could state an exception that the only non-PFS cipher suite to be > permitted on servers for backwards compatibility is > TLS_RSA_WITH_3DES_EDE_CBC_SHA. Exchange 2003 has a broken 3DES implementation. The only working ciphersuites are RC4-SHA/RC4-MD5. And there are surely plenty of legacy system that are neither HTTPS or email. It sure sounds like the radical surgery is largely for HTTPS, and should be implemented in web servers and clients, not the TLS protocol. -- Viktor. From nobody Thu Jul 23 09:45:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6A11AD1A3 for ; Thu, 23 Jul 2015 09:45:16 -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 ygOVQ419xoBH for ; Thu, 23 Jul 2015 09:45:15 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A39E1AD289 for ; Thu, 23 Jul 2015 09:43:42 -0700 (PDT) Received: by qkdv3 with SMTP id v3so176876650qkd.3 for ; Thu, 23 Jul 2015 09:43:42 -0700 (PDT) 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=Ev9gMPoL6VwTn5/D48hfg4pg/dVH8eIQ0NXWdVhnShg=; b=Q9Kxv9ie0cn9BID34fx4qYb1RorDWwJoBSEDGLXjEvfWDuc5Dig41qM+AGfNYhuyVy XRZzYZ0ssfvvCOjlKmFpc7oIx9CB45L0EL3gsKWnsw6r+UzuLrLpErrL1BkDOrA/+3MN /QF4Z/epkXBMqz4FfQb0IlhCDqVLF9VUy1TWvuIJxTBBf9lJSXbL0jTT/OXTmNB2U0Jr bBYp1OtLXjrU0PC1iLOxRUMERNOJajFr5fuZD/Fme7IZokIpOM6wCbpui+9GmnI2FGkG Be+QcQDNODjXdYAEAL49Q7yVU4VwB1Rwqm5N0wIJRORB4LWdqRwUi6O+Y1JCzlPrLBVg PL9A== X-Received: by 10.140.232.200 with SMTP id d191mr14361065qhc.84.1437669821919; Thu, 23 Jul 2015 09:43:41 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id z76sm2646263qge.22.2015.07.23.09.43.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 09:43:41 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Thu, 23 Jul 2015 12:43:40 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507221610.27729.davemgarrett@gmail.com> <201507231143.46288.davemgarrett@gmail.com> <20150723160034.GV4347@mournblade.imrryr.org> In-Reply-To: <20150723160034.GV4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507231243.40418.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 16:45:16 -0000 On Thursday, July 23, 2015 12:00:34 pm Viktor Dukhovni wrote: > On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote: > > Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0, > > or abort with a fatal error. > > Who's going to police the Internet to remove all the legacy services? I'm not proposing a non-PFS diediedie RFC; just that no TLS 1.3+ server should ever be willing to negotiate non-PFS. (again, with very limited possible exceptions) I was probably unclear, but I'm primarily talking about server-side here, as it was a reply to a server-side issue. Clients SHOULD only be negotiating PFS, but I think servers MUST only negotiate PFS. > Exchange 2003 has a broken 3DES implementation. The only working > ciphersuites are RC4-SHA/RC4-MD5. RC4 already got a diediedie RFC. If their 3DES stays broken, and nothing better is available, it's already considered illegitimate to continue using. Also, I don't care. It is not the role of the TLS 2015 WG to work around bugs in abandoned software from 12 years ago. Dave From nobody Thu Jul 23 10:06:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D3D1A1F70 for ; Thu, 23 Jul 2015 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 pemDBbx1Mvpl for ; Thu, 23 Jul 2015 10:06:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02F61A8823 for ; Thu, 23 Jul 2015 10:06:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 73BE0BDD8; Thu, 23 Jul 2015 18:06:06 +0100 (IST) 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 I3jDBTPiokWQ; Thu, 23 Jul 2015 18:06:05 +0100 (IST) Received: from [31.133.179.222] (dhcp-b3de.meeting.ietf.org [31.133.179.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4370BBDCF; Thu, 23 Jul 2015 18:06:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437671165; bh=y04m7GR08bvWiq2HY646+JsG6uBnvhRbQkuGYwkU6yI=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=L7DS+aROhX+13YezOYNpTgLlE/4uNtiG3fQ45/fGflmxcKygbW/ieE4FBXoXokMjR NoPH3gOJ6fZcswJRRT+JNDYgftc6czwPia8pvCe2dkyO6i5M3XBXzZZ3zmp+4m2vjl Rs002fNLNp8mT+9qHYQ4Wv+HacxkhsfH4TayjxRg= Message-ID: <55B11EFC.6070400@cs.tcd.ie> Date: Thu, 23 Jul 2015 18:06:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Dave Garrett , Hubert Kario References: <201507221610.27729.davemgarrett@gmail.com> <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> <201507231143.46288.davemgarrett@gmail.com> In-Reply-To: <201507231143.46288.davemgarrett@gmail.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 17:06:32 -0000 On 23/07/15 16:43, Dave Garrett wrote: > We should just get more serious about banning old crap entirely to > make dangerous misconfiguration impossible for TLS 1.3+ > implementations. > > Right now, the restrictions section prohibits: RC4, SSL2/3, & > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+ > compatible with TLS 1.2, if available A suggestion - could we remove mention of anything that is not a MUST or SHOULD ciphersuite from the TLS1.3 document and then have someone write a separate draft that adds a column to the registry where we can mark old crap as deprecated? Not sure if it'd work though. S. From nobody Thu Jul 23 10:11:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EA51A212D for ; Thu, 23 Jul 2015 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 DJOFo0s2Eh6Y for ; Thu, 23 Jul 2015 10:11:11 -0700 (PDT) Received: from BLU004-OMC3S27.hotmail.com (blu004-omc3s27.hotmail.com [65.55.116.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AEA1A8764 for ; Thu, 23 Jul 2015 10:11:09 -0700 (PDT) Received: from BLU177-W35 ([65.55.116.73]) by BLU004-OMC3S27.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 23 Jul 2015 10:11:09 -0700 X-TMN: [PaZkSo0iXcao1ou6ToT8/5S+0MuYudyI] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "tls@ietf.org" , "Andrei.Popov@microsoft.com" , "maray@microsoft.com" Date: Thu, 23 Jul 2015 10:11:08 -0700 Importance: Normal In-Reply-To: <20150723160034.GV4347@mournblade.imrryr.org> References: <201507221610.27729.davemgarrett@gmail.com>, <1724827.ajpDBsKllU@pintsize.usersys.redhat.com>, <201507231143.46288.davemgarrett@gmail.com>, <20150723160034.GV4347@mournblade.imrryr.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2015 17:11:09.0004 (UTC) FILETIME=[916190C0:01D0C56A] Archived-At: Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 17:11:13 -0000 =0A= =0A= =0A= It is Windows Server 2003 SMTP service that has this problem.=0A= There is a hotfix for it.=0A= I had been asking for these fixes to be pushed out and the KB article corre= cted before Windows Server 2003 ended support.=0A= =0A= > Date: Thu=2C 23 Jul 2015 16:00:34 +0000=0A= > From: ietf-dane@dukhovni.org=0A= > To: tls@ietf.org=0A= > Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF = 93)=0A= > =0A= > On Thu=2C Jul 23=2C 2015 at 11:43:45AM -0400=2C Dave Garrett wrote:=0A= > =0A= >> Right now=2C the restrictions section prohibits:=0A= >> RC4=2C SSL2/3=2C & EXPORT/NULL entirely (via min bits)=0A= >> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2=2C if available=0A= > =0A= > So much for using NULL ciphers for client-server authentication on=0A= > loopback interfaces. :-(=0A= > =0A= > Surely=2C in at least some cases=2C making it harder to make mistakes=0A= > needs to be addressed in toolkit and application interfaces=2C not=0A= > the protocol. Removing weak algorithms that serve the same use-cases=0A= > poorly is fine=2C but removing non-traditional use-cases is perhaps=0A= > too drastic.=0A= > =0A= >> Plus=2C "MUST" use DHE or ECDHE for ALL connections=2C even back to TLS = 1.0=2C=0A= >> or abort with a fatal error.=0A= > =0A= > Who's going to police the Internet to remove all the legacy services?=0A= > =0A= >> By the way=2C even IE6 on XP supports DHE.=0A= > =0A= > But not Exchange server 2003=2C and various Windows-based email gateway= =0A= > appliances.=0A= > =0A= >> If we actually have to care about IE on=0A= >> XP=2C we could state an exception that the only non-PFS cipher suite to = be=0A= >> permitted on servers for backwards compatibility is=0A= >> TLS_RSA_WITH_3DES_EDE_CBC_SHA.=0A= > =0A= > Exchange 2003 has a broken 3DES implementation. The only working=0A= > ciphersuites are RC4-SHA/RC4-MD5.=0A= > =0A= > And there are surely plenty of legacy system that are neither HTTPS=0A= > or email. It sure sounds like the radical surgery is largely for=0A= > HTTPS=2C and should be implemented in web servers and clients=2C not=0A= > the TLS protocol.=0A= > =0A= > -- =0A= > Viktor.=0A= > =0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tls=0A= =0A= = From nobody Thu Jul 23 10:11:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43741A87EB for ; Thu, 23 Jul 2015 10:11:14 -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 xYzJM8zbssaY for ; Thu, 23 Jul 2015 10:11:12 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A1C1A6EFC for ; Thu, 23 Jul 2015 10:11:11 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so32986710wic.0 for ; Thu, 23 Jul 2015 10:11:10 -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=VwOdm6XpcQeUf9u+jCGhpZZbE9wee9JCJcBP9C7ov+4=; b=YEbYXcN83LVQheoW3atf4Wd21q8hk1CZEHf9h1nDFcHxBtGaBdvlgi6A3JeY5/NoEk iWU9mC//zr6ZGpKXyEouhm5eDgV7ToUYIWOTlUnpwiqJrXkU4iMIpuEFaDP5YRappTcq ytHdp8Z44KAYe9C6zawa3Eto2nsMqWeJ5rcGP+qVzwShk7dYFvMehAhtwBVDqh2IaP4q wJ6OVi8pjPCMaOWpuQhwGumR+/MtMMDCcJ2A9uabkGfUKI99q5lm7jAHgdzEcejXHMtT xDUmjF0JgczK2L2SBdsXE5zRNWZXhODVGs3scjMkNqCCCA0fLiIFOg8yKAa/WMjm7miP 61Rg== X-Gm-Message-State: ALoCoQl06gYkCqdvHRzi6mcOdmPTajyajGiii6RzXSrHlm0r4mOBA0IYtpGibRDmHGKQBBpGCMG0 X-Received: by 10.180.208.114 with SMTP id md18mr54391964wic.31.1437671469885; Thu, 23 Jul 2015 10:11:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Thu, 23 Jul 2015 10:10:30 -0700 (PDT) In-Reply-To: <55B11EFC.6070400@cs.tcd.ie> References: <201507221610.27729.davemgarrett@gmail.com> <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> <201507231143.46288.davemgarrett@gmail.com> <55B11EFC.6070400@cs.tcd.ie> From: Eric Rescorla Date: Thu, 23 Jul 2015 19:10:30 +0200 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c37eb8443e6a051b8df9ff Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 17:11:15 -0000 --001a11c37eb8443e6a051b8df9ff Content-Type: text/plain; charset=UTF-8 On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell wrote: > > > On 23/07/15 16:43, Dave Garrett wrote: > > We should just get more serious about banning old crap entirely to > > make dangerous misconfiguration impossible for TLS 1.3+ > > implementations. > > > > Right now, the restrictions section prohibits: RC4, SSL2/3, & > > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+ > > compatible with TLS 1.2, if available > > A suggestion - could we remove mention of anything that > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > and then have someone write a separate draft that adds a > column to the registry where we can mark old crap as > deprecated? > > Not sure if it'd work though. > I'm starting to lean towards this. I don't generally think of TLS 1.3 as a vehicle for telling people how to configure use of TLS 1.2, and I think it might be better to move all that stuff out. -Ekr > S. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c37eb8443e6a051b8df9ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:


On 23/07/15 16:43, Dave Garrett wrote:
> We should just get more serious about banning old crap entirely to
> make dangerous misconfiguration impossible for TLS 1.3+
> implementations.
>
> Right now, the restrictions section prohibits: RC4, SSL2/3, &
> EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS= 1.3+
> compatible with TLS 1.2, if available

A suggestion - could we remove mention of anything that
is not a MUST or SHOULD ciphersuite from the TLS1.3 document
and then have someone write a separate draft that adds a
column to the registry where we can mark old crap as
deprecated?

Not sure if it'd work though.

I'= ;m starting to lean towards this. I don't generally think of TLS 1.3 as= a vehicle
for telling people how to configure use of TLS 1.2, an= d I think it might be better
to move all that stuff out.

-Ekr
=C2=A0
S.

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

--001a11c37eb8443e6a051b8df9ff-- From nobody Thu Jul 23 10:14:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1001A6F29 for ; Thu, 23 Jul 2015 10:14:56 -0700 (PDT) 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 RhHHt2baxzrO for ; Thu, 23 Jul 2015 10:14:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BD51A8943 for ; Thu, 23 Jul 2015 10:14:46 -0700 (PDT) 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 (Postfix) with ESMTPS id 78AAA35B95C; Thu, 23 Jul 2015 17:14:46 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-79.ams2.redhat.com [10.36.112.79]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6NHEg1P008641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2015 13:14:45 -0400 From: Hubert Kario To: Stephen Farrell Date: Thu, 23 Jul 2015 19:14:40 +0200 Message-ID: <2352509.B5b9Hsa38F@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <55B11EFC.6070400@cs.tcd.ie> References: <201507221610.27729.davemgarrett@gmail.com> <201507231143.46288.davemgarrett@gmail.com> <55B11EFC.6070400@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1481740.0UWiPiD8Xh"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 17:14:57 -0000 --nextPart1481740.0UWiPiD8Xh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 23 July 2015 18:06:04 Stephen Farrell wrote: > On 23/07/15 16:43, Dave Garrett wrote: > > We should just get more serious about banning old crap entirely to > > make dangerous misconfiguration impossible for TLS 1.3+ > > implementations. > >=20 > > Right now, the restrictions section prohibits: RC4, SSL2/3, & > > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+ > > compatible with TLS 1.2, if available >=20 > A suggestion - could we remove mention of anything that > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > and then have someone write a separate draft that adds a > column to the registry where we can mark old crap as > deprecated? >=20 > Not sure if it'd work though. https://tools.ietf.org/html/rfc7525 lists 4 RECOMMENDED ciphers, 6 if y= ou=20 include ECDSA versions =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1481740.0UWiPiD8Xh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVsSEAAAoJEJKo0bgB0vX1DDIP/Rr4txTobdNk4aZ8aKtuEOr4 QWKlwaaWubf45DqqRlg5xo7FdsGynXK9Q0MVl/tGm/ci2x3PfJjGQEOcyzDYmvlr i9wtRYFTOaXL8i+uc7VNPCJB02Qf2l3/fz0VIwp9CCLnd9Y4SKiEPSWY+ZFzB6hB jghfY7gLq4BRxrDTVueY82cnO99roIZQ1/aedqjpg1lW9ioE2cH0eyn9J9GIbRVl EpQZpfqYZ6717FrftGHSxjJXGOkvtGVC32fwbnVbeJ1GaFf//LnZfRvkYlTsS62n y9QTRUcL3CKmDlivdPFZRTJr3L6VSWWpni3LZdt5P5Sr+Gg0XZBRHGaAUOkSfO1E vCQZjNtB71lmOIozm0gybwvzAsQNHBvvm8cLeXfPk2YP+R9afnWA1hDkNTVpQ3/g fKDJLTIrCwaeALrVENmoEe7RKDJTG3aW05LS1KzbZF5ghxywUL/h4RFC8zIDvJSQ U2KIz73IUTg86nBWBoQdAAR0XkLl4gLHD++uvZVx2wqslJa7Kj+Sdi3a/925xQen baw1bw1j3IZalejvRsNcPvA9WBhCY0xrCSdSucLRJ3bmuPWSUW3JZIGS34P1Da49 CLjTSjAz6Zl5VzyZlvF9sI/VjTNBFYH4qn/sEDN7ht49L8kBTMw6AkHHupuCcDek OC77VhuA6tj207kNYT8s =ri9F -----END PGP SIGNATURE----- --nextPart1481740.0UWiPiD8Xh-- From nobody Thu Jul 23 10:18:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC651A895B for ; Thu, 23 Jul 2015 10:18:19 -0700 (PDT) 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 F-6_eWGkgcZx for ; Thu, 23 Jul 2015 10:18:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557531A8957 for ; Thu, 23 Jul 2015 10:18:17 -0700 (PDT) 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 (Postfix) with ESMTPS id B54DA2CD816; Thu, 23 Jul 2015 17:11:50 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-79.ams2.redhat.com [10.36.112.79]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6NHBktT013841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2015 13:11:49 -0400 From: Hubert Kario To: Dave Garrett Date: Thu, 23 Jul 2015 19:11:38 +0200 Message-ID: <3105634.KntybK3qFp@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <201507231143.46288.davemgarrett@gmail.com> References: <201507221610.27729.davemgarrett@gmail.com> <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> <201507231143.46288.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart55302262.phjt5pjf2m"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 17:18:19 -0000 --nextPart55302262.phjt5pjf2m Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 23 July 2015 11:43:45 Dave Garrett wrote: > On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote: > > vast swaths of web servers are misconfigured; introducing a more co= mplex > > mechanism to server configuration when the existing situation is > > incomprehensible to many administrators won't help (and even many p= eople > > that write the various blog posts about "how to configure SSL [sic]= in > > httpd" clearly haven't read openssl ciphers(1) man page) >=20 > We should just get more serious about banning old crap entirely to ma= ke > dangerous misconfiguration impossible for TLS 1.3+ implementations. there are valid use cases for both aNULL and eNULL at the same time 3.5% of Alexa top 1 million will negotiate AECDH, some= how I=20 doubt this many use it knowingly when ADH has just 0.2% market share TLS is a universal protocol, that means that something that is a danger= ous=20 misconfiguration in one threat model is entirely valid and good configu= ration=20 in other IoT and cloud computing will create a market for an implementation that= is=20 compatible with many threat models > Right now, the restrictions section prohibits: > RC4, SSL2/3, & EXPORT/NULL entirely (via min bits) > and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available >=20 > How about we stop being fuzzy? I'd like to make it "MUST" use AEAD wi= th all > TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use D= HE or > ECDHE for ALL connections, even back to TLS 1.0, or abort with a fata= l > error. (the wrench in this is plain PSK, which should be restricted t= o > resumption within a short window; IoT people who want to use intentio= nally > weak security can write their own known weak spec) yes, it would make situation better, thing is, nobody would implement t= his and=20 nobody would deploy it (certainly not Red Hat). People care more for availability of data than for confidentiality or=20= integrity. > By the way, even IE6 on XP supports DHE. Windows XP, however, appears= to be > badly configured to only allow it with DSS, because missing combos fr= om the > cipher suite nonsense happen. If we actually have to care about IE on= XP, > we could state an exception that the only non-PFS cipher suite to be > permitted on servers for backwards compatibility is > TLS_RSA_WITH_3DES_EDE_CBC_SHA. and that would prevent the server from never selecting DHE+RSA or clien= t=20 aborting the connection when server selects DHE+RSA how exactly? > Also add a requirement that all config provided by the admin must be > validated to meet the TLS 1.3 requirements and auto-corrected if not,= with > a warning if there's an issue. >=20 > This doesn't have to be a mess for admins to sort out. but it is, and for histerical reasons it will remain like this so given choice I prefer my mess to be at least consistent between vers= ions =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart55302262.phjt5pjf2m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVsSBRAAoJEJKo0bgB0vX1k1oP/0EkKeL0WVEN1I4k9hMsLZJ2 umUYpEA1Q2qecEihbueW4YfrF3RuCIy7TIYgnpx4tsV6H2PIBX6RDAA0PAY5KQIf ti9GExjzsGTcSmWSUB4f06mLFFsnIanmjI44GvE0AHgD3NvaGrZvTptMcFOkbbD2 d7h/us9cGC0VYUGxOmNNYawEWsDoAEPoU18A8BVjKd9KFfcs8Xk9TC6xaOl7AUgK JozeFhIYzcGFfh+WzGcr9RABkT6+uVgOz4pA92zg87qHh0Nbgc94Yra4y7pS6T3k rKM1yhg2j6QDV8jwUWkBiWuBBn4Hbi6bNJ2HmhjQ42xbcun78J0fQvOXa1fLBGt/ MpnbLhQ8wOHG1F+szVp3Yw8Y2viwQBVR61izQ99kDPvTb8tBUdCtp3+DhlLw2ozo ivJwOYv6/gupp55BvYKdk92FQRoe10S/ymob2g4L7vZpOswURzaG+58WCoaZyFlq xbqizslqoAt84Z7bk4mTzIIrXn4URsOrrBy1dGZYOAYJBdjJb0u0CmFaD5neNiwP t+NXHft6zoPYCB4f/Lpik+uy3k+2Rf/A6633+JLzNFqPd+yDnydAq8U5dZwGt/LP ESqVajQ8ckGUq/PMvkO7vBn9hwNU259hUUVx35k2Z78iTxtw22Z1VdrSHxXSH+GN 9J01OBgFJ/0VkzY4cUwa =1s0m -----END PGP SIGNATURE----- --nextPart55302262.phjt5pjf2m-- From nobody Thu Jul 23 10:28:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0047C1A89FA for ; Thu, 23 Jul 2015 10:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 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_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 t7nEgMd80pvZ for ; Thu, 23 Jul 2015 10:28:29 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451701A9068 for ; Thu, 23 Jul 2015 10:27:55 -0700 (PDT) Received: from pps.filterd (m0004347 [127.0.0.1]) by m0004347.ppops.net (8.14.5/8.14.5) with SMTP id t6NHOx3Q029245; Thu, 23 Jul 2015 10:27:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=cgd9kJCvABp0euopTWNNogSPnGsTEVh7vrOZSH2yGIw=; b=g56K9RSqxo9EvA4QdWPIsetXhO/K8RiVKgUhrjdJTpUuS8nL2KYLelmVqSOcJBEtS3TE grkDEcVDY1SxgX2l1aLLVwVQVx7FlKRTMSPex7hj4QgxLrELf8t8NFN0mCUr475JZJrW tzsIh1fIgSCk0HbRfDq9F/NzcTiEzqy/bls= Received: from mail.thefacebook.com ([199.201.64.23]) by m0004347.ppops.net with ESMTP id 1vu4jxg0eq-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Jul 2015 10:27:55 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.142]) by PRN-CHUB04.TheFacebook.com ([fe80::7ded:c10e:ef04:80d8%12]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 10:26:15 -0700 From: Subodh Iyengar To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dZ3pXhaA///uI1c= Date: Thu, 23 Jul 2015 17:26:14 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99563F648B@PRN-MBX01-4.TheFacebook.com> References: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com>, <8317321.tSLWD7hxNu@pintsize.usersys.redhat.com> In-Reply-To: <8317321.tSLWD7hxNu@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-23_09:2015-07-22,2015-07-23,1970-01-01 signatures=0 Archived-At: Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 17:28:31 -0000 Our data suggests that during successful handshakes the clock skew of mobil= e devices is within a few hours, and is within years for unsuccessful cases= . Having relative time thus is definitely better from the client's perspect= ive. =0A= =0A= With this however, there is a tradeoff on the server. The expiry time for t= he config is signed into the server config itself. So if the server wants t= o expire its server config in a predictable way it probably needs to resign= it periodically. This adds some operational issues on the server, for exam= ple performance, and becomes more operationally challenging in situations w= here there is cryptographic offloading to either a different process or a d= ifferent box. If we can come up with a reasonable solution to the resigning= problem, then relative time seems superior. =0A= =0A= Cheers,=0A= Subodh Iyengar=0A= =0A= ________________________________________=0A= From: TLS [tls-bounces@ietf.org] on behalf of Hubert Kario [hkario@redhat.c= om]=0A= Sent: Thursday, July 23, 2015 4:16 AM=0A= To: tls@ietf.org=0A= Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date= =0A= =0A= On Wednesday 22 July 2015 19:55:58 Blake Matheny wrote:=0A= > One of the topics of discussion at the WG discussion was whether=0A= > ServerConfiguration.expiration_date should be an absolute or relative=0A= > value. Subodh (CC) dug into our production data and found that nearly hal= f=0A= > of the TLS errors we see in production (end user to edge/origin) are due = to=0A= > date mismatch. This often occurs when people intentionally reset the cloc= k=0A= > on their phone, or for other various reasons.=0A= =0A= > Due to the high rate of date mismatch errors we see, my preference would = be=0A= > that ServerConfiguration.expiration_date be a relative value instead of a= n=0A= > absolute one. This provides the client an opportunity to correctly use a= =0A= > monotonic (or other similar) clock to minimizing exposure, without losing= =0A= > the value of the ServerConfiguration. Using an absolute value means that= =0A= > ServerConfiguration, for clients with invalid clocks, would essentially= =0A= > never be cacheable. These clients wouldn=92t benefit from=0A= > ServerConfiguration.=0A= =0A= the hint on tickets is already relative, so +1 on relative in server=0A= configuration too=0A= --=0A= Regards,=0A= Hubert Kario=0A= Quality Engineer, QE BaseOS Security team=0A= Web: www.cz.redhat.com=0A= Red Hat Czech s.r.o., Purky=F2ova 99/71, 612 45, Brno, Czech Republic=0A= From nobody Thu Jul 23 10:58:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7521B2A49 for ; Thu, 23 Jul 2015 10:58:15 -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 BjjUc4ID0dpo for ; Thu, 23 Jul 2015 10:58:13 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457C91B2A45 for ; Thu, 23 Jul 2015 10:58:13 -0700 (PDT) Received: by iecri3 with SMTP id ri3so1835311iec.2 for ; Thu, 23 Jul 2015 10:58:12 -0700 (PDT) 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:content-transfer-encoding; bh=pst3wu0ZxHHMufizNbfxsIeiH1HteyaT4qO2Dg68cVs=; b=uj+O/3RseGRo7Un5hXs8O+gXHvWFPVQtW+s7kewaX+daDwFT2qIXE3JAeVyQDDYhHb 841aGaisjVxyrrdmjhetTg/xQ4yhJaswFuyokm5O2F6BuaJnaijAcWgRJZAqYFAdW1d8 WBSRUdLhDGDgeCBqnATfNHELaXpBmFsOhpXY1gtAuJw8Rc0eX0wTlGTB3bJo3RiHfQOs Zvoz1Hlb31ZItV9lD7jK5YxTe1lu/GNT1/b6aKr7f5TP0JYGtlZjHpmtjAWlzkgnvwT2 gcvOwRIN1N1EWjhVm11xoXiOUOM4Sr+qDbUnPXGrKJKHuT8J/5WXPPskSNTMQRslN0jj 4Uuw== MIME-Version: 1.0 X-Received: by 10.107.132.154 with SMTP id o26mr15070365ioi.3.1437664627538; Thu, 23 Jul 2015 08:17:07 -0700 (PDT) Received: by 10.36.107.150 with HTTP; Thu, 23 Jul 2015 08:17:07 -0700 (PDT) In-Reply-To: <201507222139.46391.davemgarrett@gmail.com> References: <201507222139.46391.davemgarrett@gmail.com> Date: Thu, 23 Jul 2015 11:17:07 -0400 Message-ID: From: Jeffrey Walton To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error alerts? 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: Thu, 23 Jul 2015 17:58:16 -0000 On Wed, Jul 22, 2015 at 9:39 PM, Dave Garrett wrot= e: > Hubert Kairo found quite a few more spots in need of explicit error desig= nations, which have been amended into PR #201. > https://github.com/tlswg/tls13-spec/pull/201 > > I just noticed one error in the current draft text that was wrong and add= ed a fix for that as well. The Server Hello section said that lack of accep= table group would result in an "insufficient_security" error, which is inco= rrect. That error is clearly defined to be for lack of acceptable cipher su= ite. The Negotiated Groups section says lack of acceptable group is a =E2= =80=9Chandshake_failure=E2=80=9D error. I changed the text to state the err= or for suites, as the other is already noted elsewhere. (this change is now= in PR #201) This brings up a problem, however: there is no distinct error = for lack of group support. The =E2=80=9Chandshake_failure=E2=80=9D is a bit= of a catchall, so there's no way for a client to really know what's wrong = if this happens. This is also why I don't want to change the definition of = the "insufficient_security" error. Clients rely on these being relatively p= recise in order to show error messages that are hopefully meaningful enough= to get them fixed. As such, I'd like to propose adding a new error just fo= r this and renaming the old one to focus precisely on its long defined mean= ing. While we're at it, a failure of client authentication doesn't have its= own error alert code either. > > enum { > handshake_failure(40), > unsupported_cipher_suites(71), /* formerly insufficient_security = */ > unsupported_dh_groups(72), /* new */ > client_authentication_failure(73), /* new */ > (255) > } AlertDescription; > > Pretty straightforward. Are there any other errors that can't be clearly = identified by the returned code? Debugging shouldn't be guesswork. ;) > Alert 40 shows up frequently in my debugging experiences. A few things can cause it. It would be nice to see that one broken out. Jeff From nobody Thu Jul 23 11:21:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12A1B2B19 for ; Thu, 23 Jul 2015 11:21:21 -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 xVAqX3QguOn0 for ; Thu, 23 Jul 2015 11:21:20 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9D71AC41A for ; Thu, 23 Jul 2015 11:21:18 -0700 (PDT) Received: by qkdv3 with SMTP id v3so116381qkd.3 for ; Thu, 23 Jul 2015 11:21:17 -0700 (PDT) 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=rjncr9Sw1PdwmudVLvWxTBC6WUjOA0oSDAtYn8mBW1g=; b=XQacC9s2nFH6x1AvvJFB07hFkvaSnPqLyK4koRVxjp25rhgMaTrhBEN9C4xoU4hnSH G0Da+WCGzZpQl5NOCDtZE/WfJurSmrSM8W3or/jyTYtTSRs1bvvah/vT4/mKJzB7kVJS 2sgYAWX1IetvOd1ndwvk4KlmK+ZgMKS/z6lTRBKpEY6sNR2kl94YFHNhg+xTjzOANBPK MFREVDV5yc/FxOLo1EEJnS9ybgg0fa0vM9NzGbrO2o5ajdXYtOywqnYg7EFAqtWFD51H HiojqxQpUuugx6VC/bc0cLeZK5d4GPSm3QAtvr2JKDulacR1T5vH1zGUIHr+fw9kUk8E s53w== X-Received: by 10.140.235.6 with SMTP id g6mr4940527qhc.7.1437675677778; Thu, 23 Jul 2015 11:21:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 128sm2751977qhg.45.2015.07.23.11.21.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 11:21:17 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Thu, 23 Jul 2015 14:21:15 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507221610.27729.davemgarrett@gmail.com> <55B11EFC.6070400@cs.tcd.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507231421.15927.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2015 18:21:22 -0000 On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote: > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell > wrote: > > A suggestion - could we remove mention of anything that > > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > > and then have someone write a separate draft that adds a > > column to the registry where we can mark old crap as > > deprecated? > > I'm starting to lean towards this. I don't generally think of TLS 1.3 as a vehicle > for telling people how to configure use of TLS 1.2, and I think it might be better > to move all that stuff out. If we've learned one thing from the past year of high-profile vulnerabilities with names and logos, it's that TLS is not really secure if you don't take into account its weakest/oldest feature that's still possible. I don't think any responsible TLS 1.3 spec can afford to not acknowledge this. That said, if all you want to move out are things that aren't MUSTs or SHOULDs, I don't see a problem with that. (with possibly the exception of a "NOT RECOMMENDED" or two, though that's really just a synonym for "SHOULD NOT") What would that actually entail? Or, did you just mean to cut out all non-MUST/SHOULD cipher suites? I also don't see a problem with that. I just updated the list with everything. The full list can go in a separate document if we want to just focus on MUST/SHOULD support ciphers in the spec, proper. Also on the topic of cutting out hunks of text, someone should write up a DSS/DSA removal PR. There's quite a bit of text scattered throughout the spec to handle it that we don't need anymore. Dave From nobody Thu Jul 23 11:27:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D6F1B2C74 for ; Thu, 23 Jul 2015 11:27:08 -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 M4d2vpphYgFM for ; Thu, 23 Jul 2015 11:27:06 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790491B2BCD for ; Thu, 23 Jul 2015 11:26:22 -0700 (PDT) Received: by qgeu79 with SMTP id u79so164889qge.1 for ; Thu, 23 Jul 2015 11:26:21 -0700 (PDT) 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=0CZLTTcLR+gqZNXx8a9Ixx0E9L49UciD4KqnoxHNpw4=; b=ffiTeOWMBm164anH6qRANprLJl0w+gCuX5BNEa9QokkWZKTi2dy2GmalT7Hh0k4BA4 7xYAI8+hIwBOjY7KzTYh4yYr8aWGyCqWsCis2VZ3bmjZge/qIe0ncCoAZwn6nLpsBg8g Zy98oZnXoTFpoCoz4O2N+P1s72ogO13cPL3DjjskzLWRe7OGq1Y4XMYcRUwD12u4MkYY w41S286adStyDwvg8rBubaWSkmH33P9/gXdcPupqDnPLcUemRQ5fovJKbviOZWmj98+e 9adrptmwzULipzc/sOcxe7Fzq3GYJMM7nU1LlmlMouJ/z6WRssSct4R14HclQhn25p+e 6Mig== X-Received: by 10.55.15.75 with SMTP id z72mr13922998qkg.58.1437675981760; Thu, 23 Jul 2015 11:26:21 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 76sm2756185qhg.49.2015.07.23.11.26.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 11:26:21 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Thu, 23 Jul 2015 14:26:20 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507222139.46391.davemgarrett@gmail.com> <55B0C6A2.40304@azet.org> In-Reply-To: <55B0C6A2.40304@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507231426.20542.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Thu, 23 Jul 2015 18:27:08 -0000 On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote: > I mean I kinda agree that 'insufficent security' is a misleading name, > but as it has been used for decades in TLS I'm a bit hesitant if it's a > good idea to change the name now. Alternate bikesheddy response: what about renaming it to "insufficient_cipher_security" and adding a new "insufficient_dh_security"? That keeps the legacy naming, but modifies it to include actual specific meaning, rather than a total replacement. Dave From nobody Thu Jul 23 12:31:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4751A1EFF for ; Thu, 23 Jul 2015 12:31:14 -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 dmYI8V5RMNcK for ; Thu, 23 Jul 2015 12:31:13 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C490D1A1B62 for ; Thu, 23 Jul 2015 12:31:12 -0700 (PDT) Received: by wibud3 with SMTP id ud3so7899986wib.0 for ; Thu, 23 Jul 2015 12:31:11 -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 :cc:subject:references:in-reply-to:content-type; bh=Toy9W+u2ZZCtrOzF4dLEkZz72AiG8vuoLYXYjdgDjZQ=; b=RdGPvwCpoyMfUz6rB1wXqjWNU9+3ElmH9YZHHxuSZfuuBr914sAykxUhNlv12IO9nE BT646Fyh7wrxtFhNeSUEjGX+3N4kS9YMV/mRFGs4zBC3NlRWNrjUsqSfQdKKeu/ArkIk cSKuNc2KIBMAiCrgx8BOgvJSKd9lf+9oCX5eRH/T+h+XXm6ycDu+3sBaT5fUkkrnH6ji J2FOxKqm3uBn7bqg0llAuCvpwZg5WOe2DIK1fITCdcdqk/6eRdt6OXBXZyRZbqLJiA7R fVDaIkJQROMkjZBW8sd8Hee7bTvgQZSNjy9yLpHwRqd21tgAKV0tDXmbv0tosygZi587 I7ig== X-Gm-Message-State: ALoCoQmiTUhW87UaIJT4vT+bW1hMBMws0X02tBKuG4/RPp55bjRjmA8ue2Gt6EZmgFFcMNTY3GSp X-Received: by 10.180.103.69 with SMTP id fu5mr26098274wib.95.1437679871287; Thu, 23 Jul 2015 12:31:11 -0700 (PDT) Received: from [200.200.100.37] ([80.250.10.250]) by smtp.gmail.com with ESMTPSA id i6sm8368785wjf.29.2015.07.23.12.31.09 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 12:31:10 -0700 (PDT) Message-ID: <55B140FA.4060705@azet.org> Date: Thu, 23 Jul 2015 21:31:06 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201507222139.46391.davemgarrett@gmail.com> <55B0C6A2.40304@azet.org> <201507231426.20542.davemgarrett@gmail.com> In-Reply-To: <201507231426.20542.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3F8CE70D57AD0837330BCEC4" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Thu, 23 Jul 2015 19:31:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F8CE70D57AD0837330BCEC4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dave Garrett wrote: > On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote: >> I mean I kinda agree that 'insufficent security' is a misleading name,= >> but as it has been used for decades in TLS I'm a bit hesitant if it's = a >> good idea to change the name now. >=20 > Alternate bikesheddy response: what about renaming it to "insufficient_= cipher_security" and adding a new "insufficient_dh_security"? >=20 > That keeps the legacy naming, but modifies it to include actual specifi= c meaning, rather than a total replacement. >=20 Fine with that. Now that I think about it again; I'm also fine with the original proposal. The thing is 'insufficient security' has a nicer ring to it than 'unsupported XYZ'. Aaron --------------enig3F8CE70D57AD0837330BCEC4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVsUD7AAoJEOTbZJL9ubXV614P/3KQWcitpVZTKF82L2MYmzuJ Q5U27ZCaXR2Wuv0XJkhSZqoMZ05StQObhSAOfVyhbhyTbWITFS0R1pVhq+386UFP b4lDvK/iHFWWwKYNlsm7AKtbqj69h62Za91wzO83cT4/sMZp6sH2GcSoCY3aMxC1 1s+g9220zRXxubRyG2yTMfeBRp1EzLh4msfiaYe3gwWikPJ9ULLVIxUobMfv4BXl uUZEHtpdvfjrL23TlxcOHMRQ2BClnHmW9oLqZlDf900iC7CVARxEd4FLaxfXdou2 xsBwOdeL1MBj5BFIm7/BrJr5X+iD1moeLl3hRIt8t78EG+5N1VRxK19Pqg03mSqb X9FLaKXSKJG0cL51LHV3hV5/eRhPZj9brBSGQ3sdeQm147A0551PC6E1q7S6jAuc lJGwpFwSWkK52e2EQ6mNiVjRHPcUxK7rhmdhZc9Psg5EvEc7tYaMs2vQBUBz672l 4tK9dHezGAPh8gr5tF/UXwWMF9TZgU/+aL7FvAcdkNP20gtWctepjYx6l0Y3AZ+2 0EplKtbHz/nTWmJ1MhU+umKxqSJ9f9jz1DjWE+kb5bTv/hBWXqsfdMlT3Z+9sWez Gq/Gpyj0RWAaZnFjNi0jWWqGotWJMUhq0Twm5TqCsKxF6mpWLgBROLEDQY3OdWLu vDuZeUKLfbhCASqfKozh =7ZRx -----END PGP SIGNATURE----- --------------enig3F8CE70D57AD0837330BCEC4-- From nobody Thu Jul 23 13:01:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296561A8836 for ; Thu, 23 Jul 2015 13:01:20 -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 676MTjJlnh5F for ; Thu, 23 Jul 2015 13:01:15 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3069D1A87C7 for ; Thu, 23 Jul 2015 13:01:15 -0700 (PDT) Received: by qkdl129 with SMTP id l129so2083747qkd.0 for ; Thu, 23 Jul 2015 13:01:14 -0700 (PDT) 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=qHcjMRvf9gFRZ5hVPOJTNzSEskoNWJoXGqSDqxCSB7U=; b=Swg/Z6Fu9mNfae7NRW1s861Bh8Sb8av2FfxRhyGNUqp0KypamcDO87OFF6Uc9WFvuh 2dMafggLkDoyipNutorJr5XN0e6DoOw4DH4wFYnb+AozoB7Z12/jeuS5uKTEKiHF2/ut +MBRv/w1Vv8kNp+R+Bp0Rymg3OT8tr4rF16NxCP9PGWfCGz1mHau41geOmSvE40TjhYc zpaACbyCcrNIfomgY5YMzArK5b2DoOgBFGYa/QV+caFgo6pv/hMrHD4OPKHzuLtDj3jY 410pNOdfNjRjqtO7y4Mp4x4mVv3Y23VNOVJtFi3QzXQwlvFhSjLelr6OXslKp3n+OkBZ Z+cQ== X-Received: by 10.140.151.203 with SMTP id 194mr15550382qhx.80.1437681674498; Thu, 23 Jul 2015 13:01:14 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id b196sm2925937qka.14.2015.07.23.13.01.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 13:01:14 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Thu, 23 Jul 2015 16:01:12 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507222139.46391.davemgarrett@gmail.com> <201507231426.20542.davemgarrett@gmail.com> <55B140FA.4060705@azet.org> In-Reply-To: <55B140FA.4060705@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507231601.13026.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Thu, 23 Jul 2015 20:01:20 -0000 On Thursday, July 23, 2015 03:31:06 pm Aaron Zauner wrote: > Fine with that. Now that I think about it again; I'm also fine with the > original proposal. The thing is 'insufficient security' has a nicer ring > to it than 'unsupported XYZ'. It's wrong, though. If a server rejects a client connection because the server only supports RC4 and the client doesn't, the correct error for the server to return is "insufficient_security". If you invert the meaning, I guess the server has insufficient security, but it's not the same. If we're ok with a complete change, then I'll just go with the "unsupported_X" format as there's already an "unsupported_certificate" and "unsupported_extension". I'll stick a commit for this into my ever growing PR #201 in a bit. Dave From nobody Thu Jul 23 13:18:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154361A70E1 for ; Thu, 23 Jul 2015 13:18:54 -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 vDzMcGAhXE9e for ; Thu, 23 Jul 2015 13:18:52 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2FF1A1B22 for ; Thu, 23 Jul 2015 13:18:52 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so39019852wic.0 for ; Thu, 23 Jul 2015 13:18:51 -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 :cc:subject:references:in-reply-to:content-type; bh=UtnQP2tDRsDem9o42gD1wwG+N+MUKSGZUTmjxrbXv/Y=; b=jojgLLsnZBnH0w8eurxuBsGPtJ9QOjPHdCveRy83aKublbSgbS5x9gs6Mii1xr4xFP G8GN55tgQlE3uFNjlLa3Q56bGkEzYPZb0UNpOa9n6SB58pRlBdRHzem7axlzpAUNGtzL m4EOmJRDXNjCUHNADExxf2Tw8WPaNfdf3SwKeuFO5MUhQYPG+d+9ZiHh2JQxOFDQSzSR AWpIVKR6Q7vz9A9Re75kpvTvEE6EKUzszNVNzjLMYk1Rpb4h/3GqcJ0nV3vQgoc5kKq3 wJVyq7BhHXXtQurmi5KQZNhjtwBfGuPnQ3p9IATCPj6R2YUoaEu+7mj/m6Cy0JkDuWqO 1ySg== X-Gm-Message-State: ALoCoQmFIDXl4FpiJJVsR1tthmD6vbs+7JlWrGUnIuq8h1Um8+RxX6gmjAoFoNsi7lDk8R9lIGQk X-Received: by 10.180.105.36 with SMTP id gj4mr93510wib.64.1437682731086; Thu, 23 Jul 2015 13:18:51 -0700 (PDT) Received: from [200.200.100.37] ([194.228.129.228]) by smtp.gmail.com with ESMTPSA id pd7sm9113086wjb.27.2015.07.23.13.18.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 13:18:50 -0700 (PDT) Message-ID: <55B14C25.3080800@azet.org> Date: Thu, 23 Jul 2015 22:18:45 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201507222139.46391.davemgarrett@gmail.com> <201507231426.20542.davemgarrett@gmail.com> <55B140FA.4060705@azet.org> <201507231601.13026.davemgarrett@gmail.com> In-Reply-To: <201507231601.13026.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig13AAF732E43F694564A2E97A" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Thu, 23 Jul 2015 20:18:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig13AAF732E43F694564A2E97A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dave Garrett wrote:> > It's wrong, though. If a server rejects a client connection because the= server only supports RC4 and the client doesn't, the correct error for t= he server to return is "insufficient_security". If you invert the meaning= , I guess the server has insufficient security, but it's not the same. >=20 Well that was kinda what I was getting at, yea :) > If we're ok with a complete change, then I'll just go with the "unsuppo= rted_X" format as there's already an "unsupported_certificate" and "unsup= ported_extension". >=20 > I'll stick a commit for this into my ever growing PR #201 in a bit. >=20 Fine with me - didn't want to bikeshed here. Aaron --------------enig13AAF732E43F694564A2E97A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVsUwmAAoJEOTbZJL9ubXVn90P+gIWahPPQ1X7orMtBgt7QZKB 7DgvFq4Cs9yvLOHtAI1hPCpdDuG9CYccAg7ObLyVjkviNAm3B3V7OPxyxghoc628 8bL2F7CYVYs/OkNdtfPsDOD9wy2gpt6EHaPpvh9uLx9KCyNDHYhYVhG6ndq5nS4j T7tFa1qF8RNRhopRkyhp3CohZTFh+yDMtSEwOT+1IwVa6gW0eq5cN5fx/CCPojyC fKIl/LjmTYNdFoylDCtUdHj0fQtZmr235W4NWgSvztEOmyRy0u1tTM1go2Z1LCok cOzTuq7Wa90D0f72dMGlDzM/7eMUeCD6a4+5Oq8OksG5RskkyztUOoaXkfOGB4BI 270PEHVmno5jBH/1NS57HzvRqhQFjTgBeK1o9k9ffXk5v3f1hGMyPzTASBe9RdBt JU0x+61iy28l9FZTN4scDoJcCUh0ikoITSggL71fc7rnkDkOpMQqhmHmT5jACGNT NrDxJna1wSM/jK2tTEIgcel53mET+wGuvdEkOZuZduY5w0EwU9TcQAbcAC602wuI 09qvqou2sfkANvUgl0HQ0u9c6SsJtU0AL4izj+FwhOoOnXz975/lOIYb3XpLw+ei dtd9HdMEYuZ0628V8DIl61UW6MXLoSszPE7YFTacJOXsLF7Y5/odF4CsnAiMQLhQ 185vb/ap4WJkDK9G8j5I =vyMA -----END PGP SIGNATURE----- --------------enig13AAF732E43F694564A2E97A-- From nobody Thu Jul 23 16:32:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6F81A1EEA for ; Thu, 23 Jul 2015 16:32:25 -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 lML1yWv90v9o for ; Thu, 23 Jul 2015 16:32:23 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268071A1BD1 for ; Thu, 23 Jul 2015 16:32:23 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so43642828wic.0 for ; Thu, 23 Jul 2015 16:32: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MMcMWPNTzNXIPxT2lFzFG9rDMaiSPRBMnvr/NkgvWmE=; b=H4NMvdg6fsgDo1lnxyycfd0hjnl4osokjTxbbFVSAInjeTHz34DPI/jj600JICmaO8 WEzGjKZnQmL359OHa0vZ2hqywOsiN9nloMVhR15RNEO796PLMNP643BAmW5lWwTvH0Ao 6OvCSYrdm8uhde++z0mSj7hl2NHC466SrcLWJQGNLnKo7M6eRkHF+newoZTLdU7/8rzL bUyyAY+8iDntT96X8coqpb+GB+YxrjoudfZUqvLeZhlze4bjwHQCV+uln8DP610bxN+g PReSQSyQSE9SaQWRaiLNXQ2nodCvtSliTpT/GZnjtkmFPyl6f7FbOROLj9QhaeYnx8O9 EHjg== X-Gm-Message-State: ALoCoQkwi65UPlFDljmMUIam5PKEUsA4/jZ8N16DY4CVh4KlxnAL8s3tZzZcBfVtVKGHHTR8zgn4 X-Received: by 10.194.158.42 with SMTP id wr10mr19853611wjb.81.1437694341952; Thu, 23 Jul 2015 16:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Thu, 23 Jul 2015 16:31:42 -0700 (PDT) In-Reply-To: <201507222139.46391.davemgarrett@gmail.com> References: <201507222139.46391.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 24 Jul 2015 01:31:42 +0200 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e013c64788c4ef2051b934c59 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Thu, 23 Jul 2015 23:32:25 -0000 --089e013c64788c4ef2051b934c59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's not clear to me that there is consensus that more granular error codes are a good idea. I'll defer to the chairs on the process question. -Ekr On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett wrote: > Hubert Kairo found quite a few more spots in need of explicit error > designations, which have been amended into PR #201. > https://github.com/tlswg/tls13-spec/pull/201 > > I just noticed one error in the current draft text that was wrong and > added a fix for that as well. The Server Hello section said that lack of > acceptable group would result in an "insufficient_security" error, which = is > incorrect. That error is clearly defined to be for lack of acceptable > cipher suite. The Negotiated Groups section says lack of acceptable group > is a =E2=80=9Chandshake_failure=E2=80=9D error. I changed the text to sta= te the error for > suites, as the other is already noted elsewhere. (this change is now in P= R > #201) This brings up a problem, however: there is no distinct error for > lack of group support. The =E2=80=9Chandshake_failure=E2=80=9D is a bit o= f a catchall, so > there's no way for a client to really know what's wrong if this happens. > This is also why I don't want to change the definition of the > "insufficient_security" error. Clients rely on these being relatively > precise in order to show error messages that are hopefully meaningful > enough to get them fixed. As such, I'd like to propose adding a new error > just for this and renaming the old one to focus precisely on its long > defined meaning. While we're at it, a failure of client authentication > doesn't have its own error alert code either. > > enum { > handshake_failure(40), > unsupported_cipher_suites(71), /* formerly insufficient_security = */ > unsupported_dh_groups(72), /* new */ > client_authentication_failure(73), /* new */ > (255) > } AlertDescription; > > Pretty straightforward. Are there any other errors that can't be clearly > identified by the returned code? Debugging shouldn't be guesswork. ;) > > > Dave > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e013c64788c4ef2051b934c59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's not clear to me that there is consensus that more= granular error
codes are a good idea. I'll defer to the chairs on = the process question.

-Ekr


On Thu, Jul 23, 2015 at 3:= 39 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
=
Hubert Kairo found quite a few more spots in= need of explicit error designations, which have been amended into PR #201.=
https://github.com/tlswg/tls13-spec/pull/201

I just noticed one error in the current draft text that was wrong and added= a fix for that as well. The Server Hello section said that lack of accepta= ble group would result in an "insufficient_security" error, which= is incorrect. That error is clearly defined to be for lack of acceptable c= ipher suite. The Negotiated Groups section says lack of acceptable group is= a =E2=80=9Chandshake_failure=E2=80=9D error. I changed the text to state t= he error for suites, as the other is already noted elsewhere. (this change = is now in PR #201) This brings up a problem, however: there is no distinct = error for lack of group support. The =E2=80=9Chandshake_failure=E2=80=9D is= a bit of a catchall, so there's no way for a client to really know wha= t's wrong if this happens. This is also why I don't want to change = the definition of the "insufficient_security" error. Clients rely= on these being relatively precise in order to show error messages that are= hopefully meaningful enough to get them fixed. As such, I'd like to pr= opose adding a new error just for this and renaming the old one to focus pr= ecisely on its long defined meaning. While we're at it, a failure of cl= ient authentication doesn't have its own error alert code either.

=C2=A0 enum {
=C2=A0 =C2=A0 =C2=A0 =C2=A0handshake_failure(40),
=C2=A0 =C2=A0 =C2=A0 =C2=A0unsupported_cipher_suites(71),=C2=A0 /* formerly= insufficient_security */
=C2=A0 =C2=A0 =C2=A0 =C2=A0unsupported_dh_groups(72),=C2=A0 /* new */
=C2=A0 =C2=A0 =C2=A0 =C2=A0client_authentication_failure(73),=C2=A0 /* new = */
=C2=A0 =C2=A0 =C2=A0 =C2=A0(255)
=C2=A0 =C2=A0} AlertDescription;

Pretty straightforward. Are there any other errors that can't be clearl= y identified by the returned code? Debugging shouldn't be guesswork. ;)=


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

--089e013c64788c4ef2051b934c59-- From nobody Thu Jul 23 19:53:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A43E1ACED8 for ; Thu, 23 Jul 2015 19:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 uhQ3DCuEklrJ for ; Thu, 23 Jul 2015 19:53:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374411B29DD for ; Thu, 23 Jul 2015 19:53:01 -0700 (PDT) Received: from BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) by BLUPR03MB183.namprd03.prod.outlook.com (10.255.212.149) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 24 Jul 2015 02:52:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T5J7JnBYLJmb0I7ztwIqUO1Z7Na2N7ahNbH01TWYvd0=; b=oCq6X9A3OcKeytBvuaKxm3bsBUUfGCE56LxKGoTLtjpO3UPnXCFNT3Rsdx4kfy1HbOaXp1pT7fK5s3BcBCr5aKUHCrAJLkUNVXxByJsat37lfluiMRN7yNod75WisqURUHPv1TIiaEPErftRtQkInBLRv907XRQFJ2tWQL1zmUw= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 02:52:59 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Fri, 24 Jul 2015 02:52:59 +0000 From: Andrei Popov To: Eric Rescorla , Dave Garrett Thread-Topic: [TLS] new error alerts? Thread-Index: AQHQxZ/bGudh2TqShEeKMw5Vn1emwZ3p6+uQ Date: Fri, 24 Jul 2015 02:52:59 +0000 Message-ID: References: <201507222139.46391.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none; x-originating-ip: [90.181.160.186] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:6yK7KJ+i0dhguhtAOn0DJpCY2zVgP6qj/KIl7N9nj0dFje+UfqD8T25t0+aAJ3lqK+rGmr5/SWbmduHAnYVUWUl7JPGlcns5gylG/k050wBDEWpcvMVRBe+21BXQgffCYMDl8t68ZrS1eLw4NdnxyA==; 24:sVu8GRZXCQmpUHMqoDinGN8VOLib/RPS6hPBL9ScvV46c5ptFXQ3LG1YL+kcr/DMFRe0VDcbrEPSaqaTYzK7O4d5iisuMrU4/Zq9oDnJr7Q=; 20:ht2YDs0xt5TFk2UtvLc/VE0WUpyZpUiUL+26pMnWnoaeeADVKRJUTHe+CtF3YSkW/uNBc9nB3LqEcBoz4Hr9BQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB183; blupr03mb1393: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(19580395003)(19625215002)(50986999)(54356999)(5003600100002)(76576001)(19300405004)(40100003)(16236675004)(77156002)(33656002)(19617315012)(19580405001)(76176999)(7110500001)(2900100001)(86362001)(189998001)(92566002)(2950100001)(5001770100001)(15975445007)(74316001)(106116001)(5001920100001)(2420400003)(19609705001)(102836002)(2656002)(77096005)(66066001)(5002640100001)(5001960100002)(87936001)(99286002)(10090500001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396750B52053B7AEFF418B68C810BLUPR03MB1396namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 02:52:59.8788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB183; 2:wpM+QbFf7KgIrkc4JFiNZqw7hDckahuyeW8bhiD8KgDu4VEcFRqZ6f/nL4pEWOsRsQbe32QmIkOInjI+WjvyHk0Nh+/z3TNgLcptOCI7FSiqVSkg8oo5jX/iqx/Gvm4hvV04WL1pvywF0g3NRL80CLse1l8rBg96M9UxoGj6ycY=; 3:I5HKZysmMWOGGqgvSZpEbEUdG9P+F3EyTlqiu+BGs6O43xCpY211Puv6lSNsCNNROzq+DbQJO1QKlJI924HsVzuw9u1ym2haP55zRR15okUMBk2OUy2AVc6el/Ho0OAzKbeeef4KX2zhQdH8ToH+jA==; 25:aSBR2PYndqtutB8AilvQATTvYtpuKt59lD/TF68cztWjUo3xotgSsKwKTif/+Sdf+26iiw4pHGOzDVtGa/PAPvGK/ko9QI1cSHZ8uXqtc6r1qxYjwNDzEYHibLkm+6E9iaeWivWm7RpC6gx4sCkACgAY65Ekw4ZrqofLxhiDHSxSV21cjaQ3yNkqp+Hy/SSjIbACTmVc9aN/pIBYDM0CXhFXj+PN+iy1T6MAhPuUT7z18aG6MsJjPYsvamaUdwDbLksCAp7mx5W/z9UZ/8D9mA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB183; 20:I7N5XzfyNiStTL9gRjob9HgHaN+XwmQdJSkSfH/AhAXgQ5SXU6FEWUCzAjCASW34eg58gn4kw7fSRF2/qzB78HJIpRtNU9XmVlq9CB09aOqxWHX3fFuBN0ofvTwNckrt1mo8pje1j0sDkOs/8krDZRdoGRie0OOLcGY2B8BJdgyR2OyjFmGNGK73RLHNbck7i6M/Js43xH+rDwDpoZLu1IhkZVMZkulqxvWmsDKfsPhGWWvWRtcDUf484OgZrpJ71tqy+VP7Y/Btal04ja96rvY+N53DOuLZqjtD3fIqGRs/xwHvqRzJlkigL1uIkbcp5YlxjCvBW7QvQH0ZQqiG9kVYRiEKfBmT/Wbn++kjHw8onOYN/nqt0fKE0KBwMZSyxgAIG8HmBSmQj64WVfoc1iyeErgPtxkVMFGqdOWj6KCREFh+NVulbtan2LRfSeM9lG8hExnmr1cjSd9Pnk3KsDpkXg09HEu5ktJWd0z2JjHZ+oS6tCJ2SK+JksuYyxSN; 23:MSuWALtWyNPwQ9LCeKNeUOxc8ztI5jjTTz7/D5yNzoBz3bl/lALNHzGE+cFDtn+tcrea96SKz/887xdknp8rHpHE2fIZDSp+NkpWQuSI/EqHYMC0CvkmUSPO3T5XM/5Onkz36fAb+qQXeHCOZ282xJNN9pZTIplqGT4V92R4NV60gNMm/PxmVk56scbIoWLP X-OriginatorOrg: microsoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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, 24 Jul 2015 02:53:07 -0000 --_000_BLUPR03MB1396750B52053B7AEFF418B68C810BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmF0aGVyIHRoYW4gcmVuYW1pbmcgYW5kIG90aGVyd2lzZSBtb2RpZnlpbmcgdGhlIG1lYW5pbmcg b2YgdGhlIGV4aXN0aW5nIGFsZXJ0cywgd291bGQgaXQgYmUgYmV0dGVyIHRvIGRlZmluZSBuZXcs IG1vcmUgZ3JhbnVsYXIgYWxlcnRzIGluIDEuMz8gV2UgY2Fu4oCZdCBhc2NyaWJlIG5ldyBtZWFu aW5ncyB0byBhbGVydHMgZ2VuZXJhdGVkIGJ5IHRoZSBjb2RlIHdl4oCZdmUgc2hpcHBlZCBpbiB0 aGUgcGFzdC4NCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBGcmlkYXksIEp1bHkgMjQsIDIwMTUgMTozMiBB TQ0KVG86IERhdmUgR2FycmV0dA0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNd IG5ldyBlcnJvciBhbGVydHM/DQoNCkl0J3Mgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMg Y29uc2Vuc3VzIHRoYXQgbW9yZSBncmFudWxhciBlcnJvcg0KY29kZXMgYXJlIGEgZ29vZCBpZGVh LiBJJ2xsIGRlZmVyIHRvIHRoZSBjaGFpcnMgb24gdGhlIHByb2Nlc3MgcXVlc3Rpb24uDQoNCi1F a3INCg0KDQpPbiBUaHUsIEp1bCAyMywgMjAxNSBhdCAzOjM5IEFNLCBEYXZlIEdhcnJldHQgPGRh dmVtZ2FycmV0dEBnbWFpbC5jb208bWFpbHRvOmRhdmVtZ2FycmV0dEBnbWFpbC5jb20+PiB3cm90 ZToNCkh1YmVydCBLYWlybyBmb3VuZCBxdWl0ZSBhIGZldyBtb3JlIHNwb3RzIGluIG5lZWQgb2Yg ZXhwbGljaXQgZXJyb3IgZGVzaWduYXRpb25zLCB3aGljaCBoYXZlIGJlZW4gYW1lbmRlZCBpbnRv IFBSICMyMDEuDQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzIwMQ0K DQpJIGp1c3Qgbm90aWNlZCBvbmUgZXJyb3IgaW4gdGhlIGN1cnJlbnQgZHJhZnQgdGV4dCB0aGF0 IHdhcyB3cm9uZyBhbmQgYWRkZWQgYSBmaXggZm9yIHRoYXQgYXMgd2VsbC4gVGhlIFNlcnZlciBI ZWxsbyBzZWN0aW9uIHNhaWQgdGhhdCBsYWNrIG9mIGFjY2VwdGFibGUgZ3JvdXAgd291bGQgcmVz dWx0IGluIGFuICJpbnN1ZmZpY2llbnRfc2VjdXJpdHkiIGVycm9yLCB3aGljaCBpcyBpbmNvcnJl Y3QuIFRoYXQgZXJyb3IgaXMgY2xlYXJseSBkZWZpbmVkIHRvIGJlIGZvciBsYWNrIG9mIGFjY2Vw dGFibGUgY2lwaGVyIHN1aXRlLiBUaGUgTmVnb3RpYXRlZCBHcm91cHMgc2VjdGlvbiBzYXlzIGxh Y2sgb2YgYWNjZXB0YWJsZSBncm91cCBpcyBhIOKAnGhhbmRzaGFrZV9mYWlsdXJl4oCdIGVycm9y LiBJIGNoYW5nZWQgdGhlIHRleHQgdG8gc3RhdGUgdGhlIGVycm9yIGZvciBzdWl0ZXMsIGFzIHRo ZSBvdGhlciBpcyBhbHJlYWR5IG5vdGVkIGVsc2V3aGVyZS4gKHRoaXMgY2hhbmdlIGlzIG5vdyBp biBQUiAjMjAxKSBUaGlzIGJyaW5ncyB1cCBhIHByb2JsZW0sIGhvd2V2ZXI6IHRoZXJlIGlzIG5v IGRpc3RpbmN0IGVycm9yIGZvciBsYWNrIG9mIGdyb3VwIHN1cHBvcnQuIFRoZSDigJxoYW5kc2hh a2VfZmFpbHVyZeKAnSBpcyBhIGJpdCBvZiBhIGNhdGNoYWxsLCBzbyB0aGVyZSdzIG5vIHdheSBm b3IgYSBjbGllbnQgdG8gcmVhbGx5IGtub3cgd2hhdCdzIHdyb25nIGlmIHRoaXMgaGFwcGVucy4g VGhpcyBpcyBhbHNvIHdoeSBJIGRvbid0IHdhbnQgdG8gY2hhbmdlIHRoZSBkZWZpbml0aW9uIG9m IHRoZSAiaW5zdWZmaWNpZW50X3NlY3VyaXR5IiBlcnJvci4gQ2xpZW50cyByZWx5IG9uIHRoZXNl IGJlaW5nIHJlbGF0aXZlbHkgcHJlY2lzZSBpbiBvcmRlciB0byBzaG93IGVycm9yIG1lc3NhZ2Vz IHRoYXQgYXJlIGhvcGVmdWxseSBtZWFuaW5nZnVsIGVub3VnaCB0byBnZXQgdGhlbSBmaXhlZC4g QXMgc3VjaCwgSSdkIGxpa2UgdG8gcHJvcG9zZSBhZGRpbmcgYSBuZXcgZXJyb3IganVzdCBmb3Ig dGhpcyBhbmQgcmVuYW1pbmcgdGhlIG9sZCBvbmUgdG8gZm9jdXMgcHJlY2lzZWx5IG9uIGl0cyBs b25nIGRlZmluZWQgbWVhbmluZy4gV2hpbGUgd2UncmUgYXQgaXQsIGEgZmFpbHVyZSBvZiBjbGll bnQgYXV0aGVudGljYXRpb24gZG9lc24ndCBoYXZlIGl0cyBvd24gZXJyb3IgYWxlcnQgY29kZSBl aXRoZXIuDQoNCiAgZW51bSB7DQogICAgICAgaGFuZHNoYWtlX2ZhaWx1cmUoNDApLA0KICAgICAg IHVuc3VwcG9ydGVkX2NpcGhlcl9zdWl0ZXMoNzEpLCAgLyogZm9ybWVybHkgaW5zdWZmaWNpZW50 X3NlY3VyaXR5ICovDQogICAgICAgdW5zdXBwb3J0ZWRfZGhfZ3JvdXBzKDcyKSwgIC8qIG5ldyAq Lw0KICAgICAgIGNsaWVudF9hdXRoZW50aWNhdGlvbl9mYWlsdXJlKDczKSwgIC8qIG5ldyAqLw0K ICAgICAgICgyNTUpDQogICB9IEFsZXJ0RGVzY3JpcHRpb247DQoNClByZXR0eSBzdHJhaWdodGZv cndhcmQuIEFyZSB0aGVyZSBhbnkgb3RoZXIgZXJyb3JzIHRoYXQgY2FuJ3QgYmUgY2xlYXJseSBp ZGVudGlmaWVkIGJ5IHRoZSByZXR1cm5lZCBjb2RlPyBEZWJ1Z2dpbmcgc2hvdWxkbid0IGJlIGd1 ZXNzd29yay4gOykNCg0KDQpEYXZlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQo= --_000_BLUPR03MB1396750B52053B7AEFF418B68C810BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJhdGhlciB0aGFuIHJlbmFtaW5nIGFuZCBv dGhlcndpc2UgbW9kaWZ5aW5nIHRoZSBtZWFuaW5nIG9mIHRoZSBleGlzdGluZyBhbGVydHMsIHdv dWxkIGl0IGJlIGJldHRlciB0byBkZWZpbmUgbmV3LCBtb3JlIGdyYW51bGFyIGFsZXJ0cyBpbiAx LjM/IFdlIGNhbuKAmXQgYXNjcmliZQ0KIG5ldyBtZWFuaW5ncyB0byBhbGVydHMgZ2VuZXJhdGVk IGJ5IHRoZSBjb2RlIHdl4oCZdmUgc2hpcHBlZCBpbiB0aGUgcGFzdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBKdWx5IDI0LCAyMDE1IDE6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IERhdmUgR2FycmV0dDxi cj4NCjxiPkNjOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExT XSBuZXcgZXJyb3IgYWxlcnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkl0J3Mgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgbW9yZSBn cmFudWxhciBlcnJvcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmNvZGVzIGFyZSBhIGdvb2QgaWRlYS4gSSdsbCBkZWZlciB0byB0aGUgY2hhaXJzIG9uIHRoZSBw cm9jZXNzIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUaHUsIEp1bCAyMywgMjAxNSBhdCAzOjM5IEFNLCBEYXZlIEdhcnJldHQgJmx0OzxhIGhy ZWY9Im1haWx0bzpkYXZlbWdhcnJldHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2ZW1n YXJyZXR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkh1YmVydCBLYWlybyBmb3VuZCBxdWl0ZSBhIGZldyBt b3JlIHNwb3RzIGluIG5lZWQgb2YgZXhwbGljaXQgZXJyb3IgZGVzaWduYXRpb25zLCB3aGljaCBo YXZlIGJlZW4gYW1lbmRlZCBpbnRvIFBSICMyMDEuPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC8yMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzIwMTwvYT48YnI+DQo8YnI+DQpJIGp1 c3Qgbm90aWNlZCBvbmUgZXJyb3IgaW4gdGhlIGN1cnJlbnQgZHJhZnQgdGV4dCB0aGF0IHdhcyB3 cm9uZyBhbmQgYWRkZWQgYSBmaXggZm9yIHRoYXQgYXMgd2VsbC4gVGhlIFNlcnZlciBIZWxsbyBz ZWN0aW9uIHNhaWQgdGhhdCBsYWNrIG9mIGFjY2VwdGFibGUgZ3JvdXAgd291bGQgcmVzdWx0IGlu IGFuICZxdW90O2luc3VmZmljaWVudF9zZWN1cml0eSZxdW90OyBlcnJvciwgd2hpY2ggaXMgaW5j b3JyZWN0LiBUaGF0IGVycm9yIGlzIGNsZWFybHkgZGVmaW5lZA0KIHRvIGJlIGZvciBsYWNrIG9m IGFjY2VwdGFibGUgY2lwaGVyIHN1aXRlLiBUaGUgTmVnb3RpYXRlZCBHcm91cHMgc2VjdGlvbiBz YXlzIGxhY2sgb2YgYWNjZXB0YWJsZSBncm91cCBpcyBhIOKAnGhhbmRzaGFrZV9mYWlsdXJl4oCd IGVycm9yLiBJIGNoYW5nZWQgdGhlIHRleHQgdG8gc3RhdGUgdGhlIGVycm9yIGZvciBzdWl0ZXMs IGFzIHRoZSBvdGhlciBpcyBhbHJlYWR5IG5vdGVkIGVsc2V3aGVyZS4gKHRoaXMgY2hhbmdlIGlz IG5vdyBpbiBQUiAjMjAxKQ0KIFRoaXMgYnJpbmdzIHVwIGEgcHJvYmxlbSwgaG93ZXZlcjogdGhl cmUgaXMgbm8gZGlzdGluY3QgZXJyb3IgZm9yIGxhY2sgb2YgZ3JvdXAgc3VwcG9ydC4gVGhlIOKA nGhhbmRzaGFrZV9mYWlsdXJl4oCdIGlzIGEgYml0IG9mIGEgY2F0Y2hhbGwsIHNvIHRoZXJlJ3Mg bm8gd2F5IGZvciBhIGNsaWVudCB0byByZWFsbHkga25vdyB3aGF0J3Mgd3JvbmcgaWYgdGhpcyBo YXBwZW5zLiBUaGlzIGlzIGFsc28gd2h5IEkgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgdGhlDQogZGVm aW5pdGlvbiBvZiB0aGUgJnF1b3Q7aW5zdWZmaWNpZW50X3NlY3VyaXR5JnF1b3Q7IGVycm9yLiBD bGllbnRzIHJlbHkgb24gdGhlc2UgYmVpbmcgcmVsYXRpdmVseSBwcmVjaXNlIGluIG9yZGVyIHRv IHNob3cgZXJyb3IgbWVzc2FnZXMgdGhhdCBhcmUgaG9wZWZ1bGx5IG1lYW5pbmdmdWwgZW5vdWdo IHRvIGdldCB0aGVtIGZpeGVkLiBBcyBzdWNoLCBJJ2QgbGlrZSB0byBwcm9wb3NlIGFkZGluZyBh IG5ldyBlcnJvciBqdXN0IGZvciB0aGlzIGFuZCByZW5hbWluZw0KIHRoZSBvbGQgb25lIHRvIGZv Y3VzIHByZWNpc2VseSBvbiBpdHMgbG9uZyBkZWZpbmVkIG1lYW5pbmcuIFdoaWxlIHdlJ3JlIGF0 IGl0LCBhIGZhaWx1cmUgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGRvZXNuJ3QgaGF2ZSBpdHMg b3duIGVycm9yIGFsZXJ0IGNvZGUgZWl0aGVyLjxicj4NCjxicj4NCiZuYnNwOyBlbnVtIHs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtoYW5kc2hha2VfZmFpbHVyZSg0MCksPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dW5zdXBwb3J0ZWRfY2lwaGVyX3N1aXRlcyg3MSks Jm5ic3A7IC8qIGZvcm1lcmx5IGluc3VmZmljaWVudF9zZWN1cml0eSAqLzxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3Vuc3VwcG9ydGVkX2RoX2dyb3Vwcyg3MiksJm5ic3A7IC8qIG5l dyAqLzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NsaWVudF9hdXRoZW50aWNhdGlv bl9mYWlsdXJlKDczKSwmbmJzcDsgLyogbmV3ICovPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7KDI1NSk8YnI+DQombmJzcDsgJm5ic3A7fSBBbGVydERlc2NyaXB0aW9uOzxicj4NCjxi cj4NClByZXR0eSBzdHJhaWdodGZvcndhcmQuIEFyZSB0aGVyZSBhbnkgb3RoZXIgZXJyb3JzIHRo YXQgY2FuJ3QgYmUgY2xlYXJseSBpZGVudGlmaWVkIGJ5IHRoZSByZXR1cm5lZCBjb2RlPyBEZWJ1 Z2dpbmcgc2hvdWxkbid0IGJlIGd1ZXNzd29yay4gOyk8YnI+DQo8YnI+DQo8YnI+DQpEYXZlPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpU TFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB1396750B52053B7AEFF418B68C810BLUPR03MB1396namp_-- From nobody Thu Jul 23 22:02:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD50F1A00B0 for ; Thu, 23 Jul 2015 22:01:59 -0700 (PDT) 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 QPg19NrLf3Og for ; Thu, 23 Jul 2015 22:01:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B33F1B2DDF for ; Thu, 23 Jul 2015 22:01:57 -0700 (PDT) Received: from BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) by BLUPR03MB232.namprd03.prod.outlook.com (10.255.213.25) with Microsoft SMTP Server (TLS) id 15.1.219.9; Fri, 24 Jul 2015 05:01:40 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 05:01:38 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Fri, 24 Jul 2015 05:01:38 +0000 From: Andrei Popov To: Ilari Liusvaara , "tls@ietf.org" Thread-Topic: [TLS] Commentary on the client authentication presentation slides Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQ Date: Fri, 24 Jul 2015 05:01:37 +0000 Message-ID: References: <20150720141036.GA32204@LK-Perkele-VII> In-Reply-To: <20150720141036.GA32204@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: elisanet.fi; dkim=none (message not signed) header.d=none; x-originating-ip: [90.181.160.186] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:6oFKUBjpGSSlvX4Ef5ri5r0tPVslIOClFNDmiYRXaxRGlrx+34tAGVCjG/cxtH8ZGwZb5RnQLh0rPjD1AiyMMK0Oiidg8qnmrAa8lEUIeU2L5eQLP275e3i70iDLr0OsYy2zpELzGtBvIYvwlJNn9w==; 24:w3EhOPZGZ9qQosODvi18A1OsEhSl6kf6V7K9yEDRGZxV14Q/4X4TvE6CyPBMFzMKcgnvVfWlvQcvPo8fmpYvD2YdopMdlaWkZlO0BvmNlKQ=; 20:nwJ98zTJEAb5gcxguyQlsNrMNdUGlQNFykEo15Iuko+QkJ7ufDkK66KX/2h/DnBGN6dmjeAQmKIgHpizArPT3Q== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB232; blupr03mb1395: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51914003)(377454003)(5003600100002)(5001770100001)(92566002)(189998001)(76576001)(5002640100001)(2501003)(122556002)(106116001)(107886002)(5001960100002)(46102003)(10090500001)(33656002)(15975445007)(77156002)(99286002)(66066001)(62966003)(50986999)(19580405001)(40100003)(76176999)(2950100001)(74316001)(19580395003)(86362001)(2900100001)(77096005)(54356999)(102836002)(2656002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 05:01:37.8444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB232; 2:bTKYrCJFK0x6QBUbzyNWIg2nh4Syb0Or0ErnHP37aHZMNJriBzPNFeZYCbkTv4nQ; 3:2dgHv2+Vax2l81PPZ7ynsxocI4PDXwPalGZ1CRe5rPWTrvybL4GKqQchFg9Oc82oE0XHUbLbwLUh0wTxPXFkIn1/IFt04pQeJGTANwl9oxqD9XAzXjLl+UzZde3EPF3AcB2qVUczgGGsvLIs02/t2Q==; 25:H5kiv8Pf2btFljZG+IZqX9g1Z2DV12Cb0JdZ2AASkQNFP2d82JuJRa7P8CXt1Ya2UP4AFu1ozOE9iBsmW4ZbE7mJPPbrYS3qGIMGAutMHhzhJfPmuvxd1uH5YnslIRvYcGsE07Criq7VFNv/NHzWu85hjiWM5ko5lNpinbjP1TPwOhRwe3Iku/phRVODU/Oz00snJENJC7rEpAAJgyWzrd7C1f9yBwu6imyiFzSKyZXBvWt6ixVCiC4XT+/wZsPY3RTzTfO498BsGfDgWa25Tw== X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB232; 20:rmE3cye9dItVxY8JQSqmRfr2oFKC48wUik/v/XFxcaAsrYNrMuJOnjgio+Mlp+Q6YzFvZU+48EZO3B0cG2kH3Ock10a4moXujGFtDDI+60BG1dDB9SFYRnNvdwlUXr8gzcCvMqqBttkcLrJrMquOOfl3kB7llnA+l0HFzi71Idt2q7xwC4NLW3W0mudGX9udEcgmxOxFUFg/0Pk87aw6XkJ78p2334u8HUPRE1JhFYKH7q/SxRbJ4PXnpG8Ei/rwzd8ubDJ8fhYUtZdoyxKmB5JeXGjsUZwG54P3or739YDv+etKpOTFJVqtKOv+9YAj1/3QTQXE/RwPlmjsvtty85thgstUsisGXG1FhDWKKfJOnfkVV8Nco8qW+0UBltI9Ti4mVdF/6VR4hKMhVQRDZz1BM+xig5YRJTF0ohxIiOfj25NXvEsV+Ap0zK+qtSb8j8NcxMAzgF1k8UM+MNqj260QokM/BfOjlX5+kW+zdiqo+eF+uJol3EJcQsV8LDQ7; 23:aYoUJwuCa8AO5TEert6CV3r49WvO5xzXZ7guM4sxXqoAvEoPysdFzAL0PY0MD7A0hIThtIIbxor9niG9BWcXDwkgqCD68QA52JbzB/3SToMMemcDy1ZLCdnY1H3fBJtgZPafOGEcEA0RVjBh0ZhSBGqXuInfj7leF0KtJCvOwLx1TQRAS+jB7p8/ii9iiKFtf8ddJyqIBrMoaMhWpQgBRAvzMcM2tvWhxFnY/CIIi3TltSJOhhLQAa+bTxtn5SpG BLUPR03MB232: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 05:02:00 -0000 Thanks for the detailed comments, Ilari. Based on the discussion at the TLS WG meeting, I created a pull request: ht= tps://github.com/tlswg/tls13-spec/pull/209 > - Mechanism like proposed looks dangerous when combined with HTTP/2. I believe the same issue already exists in HTTP/1 where multiple requests c= an be in flight at the same time. The way we handle this in HTTP/1 is by having the server application query = the HTTP stack for the client cred. If there's no cred available, the HTTP stack triggers client authentication= (and the server application waits until the client cred is provided so it = can authorize the request). > - Regarding last point about interleaving: Assuming the scheme works in 1RTT (and I see no reason for requiring more rounds), you can't prevent application_data transmission after certificate_request. We discussed at the meeting that this restriction cannot be implemented. Instead, a server may block the processing of any in-flight requests while = waiting for the client to authenticate (if the server's architecture requir= es this). > - The certificate_types field in CertificateRequest is pretty much useless, since all supported algorithms are of signature type. If the signature_algorithms extension officially becomes MTI, then perhaps = we can discus getting rid of certificate_types in the CertificateRequest. E= xcept we may want to use this field when we introduce new certificate types= (e.g. something like IEEE1609 certs). > - How does extension_values work? If multiple values for one OID are allowed, then the OID/value pair is repeated, once for each value? Multiple values are DER-encoded per RFC that defines the OID that allows mu= ltiple values. The idea here is to simply reuse the existing OID-parsing code. A TLS imple= mentation (or certificate API) that recognizes the OID in the cert, already= knows how to parse its representation. A TLS implementation (or certificat= e API) that does not recognize the OID in the cert will also skip this OID = in the extension_values. In the degenerate case, an implementation may choo= se to skip all extension_values. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: Monday, July 20, 2015 4:11 PM To: tls@ietf.org Subject: [TLS] Commentary on the client authentication presentation slides Some commentary on client authentication slides (there is no linked draft n= or other material yet). - Mechanism like proposed looks dangerous when combined with HTTP/2. Multiplexed protocols are in general not safe to authenticate without application-layer signaling (which can be implicit via separate connections), especially if dealing with something like web environment. - Regarding last point about interleaving: Assuming the scheme works in 1RTT (and I see no reason for requiring more rounds), you can't prevent application_data transmission after certificate_request. The best that can be done is to require the client to send all the authentication-related data in one go. - The certificate_types field in CertificateRequest is pretty much useless, since all supported algorithms are of signature type. - One can't just remove fields without breaking parse compatiblity, but adding field breaks parse compatiblity too, so removing field at the same time isn't a problem. - How does extension_values work? If multiple values for one OID are allowed, then the OID/value pair is repeated, once for each value? -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 23 22:09:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A821F1B2DE1 for ; Thu, 23 Jul 2015 22:09:30 -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 j137mtUDiDmw for ; Thu, 23 Jul 2015 22:09:28 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9C41B2DE5 for ; Thu, 23 Jul 2015 22:09:28 -0700 (PDT) Received: by qged69 with SMTP id d69so6267466qge.0 for ; Thu, 23 Jul 2015 22:09:27 -0700 (PDT) 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=QEvX+PzIVMqxOJ33chOyn4O95bSZeJHbuHFeFIaWq6c=; b=jEuZeKFNcPmxXNlAEq+xQH6qONucKdj1ZGJzzZPvs6O5+4H+rQ1kiCfpcuc4Ng5LgB NDauHiZpA0wpKJZ+4FAfxLRP2YAPlsOb9VsdLB83h2HytwBzlvWD39XQOaJWW/kjkCwK nJ05fCMXoX7FzvWscvb8MM/O6DovftIrjowYM+ARBL01BfruMURcJb9U5t22XFFZFrvD Izaa9AnPCE/QsIyjDtBoWbHtLhfvsunYoVbmsRusAfDRkg1TfxA18jibkjKp5DPT8ABq LJGEmLkfkNj7zM144v73Uc8Mf8eArmKHCot50XU5gFGBckhMfcPBcXAoNMqqwIidnY8S 4lXQ== X-Received: by 10.140.92.2 with SMTP id a2mr17579900qge.6.1437714567900; Thu, 23 Jul 2015 22:09:27 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id z135sm3527435qhd.29.2015.07.23.22.09.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 22:09:27 -0700 (PDT) From: Dave Garrett To: Andrei Popov , Eric Rescorla Date: Fri, 24 Jul 2015 01:09:25 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507222139.46391.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201507240109.25969.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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, 24 Jul 2015 05:09:30 -0000 On Thursday, July 23, 2015 10:52:59 pm Andrei Popov wrote: > Rather than renaming and otherwise modifying the meaning of the existing = alerts, would it be better to define new, more granular alerts in 1.3? We c= an=E2=80=99t ascribe new meanings to alerts generated by the code we=E2=80= =99ve shipped in the past. I'm not proposing changing the meaning of existing alerts. At most, the Neg= otiated FF-DH draft would need to be updated/fixed. I'm proposing renaming "insufficient_security" to "unsupported_cipher_suite= s", which is explicitly what it's been for since TLS 1.0. There isn't a spe= cific error defined for lack of a supported group yet. RFC 4492 just says "= fatal handshake failure alert". The Negotiated FF-DH draft has "insufficien= t_security" for unsupported group. _That_ does change the meaning, as previ= ously it was explicitly defined for cipher issues only. What I want is to a= dd a new "unsupported_groups" alert to use instead. (both here and there) T= he "client_authentication_failure" alert suggestion is to pull that out of = the "handshake_failure" catchall. I just want to clarify the existing alert, not reuse it for a related but d= istinctly different alert, and not lump stuff into a catchall that we can't= debug. ;) Dave From nobody Thu Jul 23 22:50:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DCA1B2F1E for ; Thu, 23 Jul 2015 22:50:38 -0700 (PDT) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wrKqj4dXlgfZ for ; Thu, 23 Jul 2015 22:50:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F33A1B2EB4 for ; Thu, 23 Jul 2015 22:50:35 -0700 (PDT) Received: from BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) by BLUPR03MB002.namprd03.prod.outlook.com (10.255.208.36) with Microsoft SMTP Server (TLS) id 15.1.219.9; Fri, 24 Jul 2015 05:50:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lJ1FZm+eFFn+kTCGHxjZXjgq1nJiRPkH9rtPyNS3QjY=; b=OpJS43vIZ+hNyYb+3EQSRLc+33kC2UF0peSKiPGWWhhMDvcYnTxj/pXRKSWigG4Bluvy8eSVQtBgg7iDV2IK/YSDuasUfEqg3nFQHHqrvuopCsJ4PacvM1NErdVoYRMMT8BxKd+fvx67d0EKvGAONMo8waZc2tcNHygzkAn/EdI= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 05:50:31 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Fri, 24 Jul 2015 05:50:31 +0000 From: Andrei Popov To: Dave Garrett , Eric Rescorla Thread-Topic: [TLS] new error alerts? Thread-Index: AQHQxZ/bGudh2TqShEeKMw5Vn1emwZ3p6+uQgAAmpoCAAAhMIA== Date: Fri, 24 Jul 2015 05:50:31 +0000 Message-ID: References: <201507222139.46391.davemgarrett@gmail.com> <201507240109.25969.davemgarrett@gmail.com> In-Reply-To: <201507240109.25969.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [90.181.160.186] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:Rjca4boHvp4+iEZjJOOrzJxLap/cT3RneK575NvLnUGQARmcPiBvotR9lyMXiqsiw3jgP528dnM2UzQC8vGeeNnP7gzizcqJXytMi8tuDpgGAVuZ7RWlVklPyY/YW7fEOAHOdX15B7Hg9KjfG/jGVg==; 24:/UCTf8G5brOm6h88QQQAirnG8tNCzfztuPEWXa7cZfpldi2pvcQ605X49Lr+0reLVT0rdMPje/BQWTJeglTySsXijWNM0FHx2b6oUbxT68c=; 20:urOe+mtQ5SI1noe8JiGhhavC0p8r+WyZ3ZMgIYPexQW/wWqoxxbKh1mRgQIcU7wxOjKK8ijLrnE23fV4ToYkEQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB002; blupr03mb1393: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(24454002)(13464003)(377454003)(19580395003)(50986999)(54356999)(5003600100002)(122556002)(76576001)(40100003)(77156002)(33656002)(93886004)(62966003)(19580405001)(76176999)(2900100001)(86362001)(189998001)(92566002)(86612001)(2950100001)(5001770100001)(5001920100001)(66066001)(106116001)(74316001)(102836002)(2656002)(77096005)(5002640100001)(5001960100002)(99286002)(10090500001)(46102003)(87936001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 05:50:31.3699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB002; 2:jerprggjPnG6byPxtSzPUlP7FU9oKW+QPK0NAl9SO0hmsxdzG4FJgzYABsQS7lWW; 3:GNWfvVN/Wd5tjLBW3FxmfnuQ+JHZ+rY5CSKyVgo8h62dwdTLAgn0WVofL0V1djAmlJFrzIytlQlkMPy75HYUP9MPWNm85FnoRt7dM0aWqqg7i+o+uMG/35LH2A401MYYXP5J97b0vT5qubKz92cH5A==; 25:evJ+c2vrGJB85lEUH/a3r8+tQMGLtXoDfav3GtHGUyZ9AOIOat73zIP84I8dw3MH7xJEWNPxVXYe7IPPnBRxicvLyRHk91HbruS9mCfhMI+2RPJXTivk1VSF+G2qz2ELv7cKkHdVsSos0TNCjd1ehP7fD1E0xLsQG37/tCiaBmW24tAnbgG781LoVNhtYv6JUZLNfiON4jazsTsw9MVEbaWafg2KXBUyfi87RhzPn9bZvTrDqFoxILDNb1GFfyn/nB4eegNG+54QL2x1RXZzXQ== X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB002; 20:p3cVgh8PsDgFnY4BFBtXdX3YGirR9aKfF6PNFrxqDty4iLI0u7CUmjgza/ZV+sRM/+kj9dOOrKZaejDa6KrPDnVXfYykRnlGuTXaFf/FnjABoL1/Y2wJOq1813rmMtL9ScwHWCkfYnzRowLCb0Wm9PI2SMlsSYQL0B1XuSbnnUH+ulV1X3s4QSJ4UceMjS92th97WX2pMw2rmZydtnNsxN2wh9/4LABeb+YymI/HQ+nRYrBRLL7W/U2DcOn2O0r3JLO7paKzg6QWk+NHTbEZic+45OFSbV4pCOqIe9pTUF6nYjH6li2/oN8C20Uc7YA3ZY8VnatSDMngQfxbb/f0Kzvwc0bYHcC2YC4AHjSDBMRC1ouJRtPLX7ck2IUbzI6aG4Zwh0ZA9EkysIvaaYQw1daoNMnKrPTdWA61Fv3TUJ2ZVW7g7aCaMbCV/xf90oAN/MaYM5fMQqKaXrbZjS0eEfqIaq0Sqd5lx4kv8247xvXCIkcgxPsBP/uq3m44DLco; 23:2CyS6M1TYyRr22lil0MxTepEaQVm2VrA0bsQvVcyZBgEuRavmc203uP4jpTd3tEOXuzcY3RMsF/oLIrcPoRu7eLZJZNSTFw8JoTpRZ+PMTWlsd2JDl0olngdQvnqfRpE51OK8pensxtwnL9PnlFl7djaxvkZZn9aQmiZLYDjJgj7rlZk8APy9RFpmSMN0PCSAz0ypedGh8CUjr7Pqg2rtmiqB1VYC+VYcxFnB6mgFXsicVKKYuYh0t5SYQfYMn2V BLUPR03MB002: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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, 24 Jul 2015 05:50:38 -0000 PiBJJ20gcHJvcG9zaW5nIHJlbmFtaW5nICJpbnN1ZmZpY2llbnRfc2VjdXJpdHkiIHRvICJ1bnN1 cHBvcnRlZF9jaXBoZXJfc3VpdGVzIiwgd2hpY2ggaXMgZXhwbGljaXRseSB3aGF0IGl0J3MgYmVl biBmb3Igc2luY2UgVExTIDEuMC4NCg0KTm90IHF1aXRlLiBJbnN1ZmZpY2llbnRfc2VjdXJpdHkg YWxlcnQgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KIiBSZXR1cm5lZCBpbnN0ZWFkIG9mIGhhbmRz aGFrZV9mYWlsdXJlIHdoZW4gYSBuZWdvdGlhdGlvbiBoYXMNCiAgIGZhaWxlZCBzcGVjaWZpY2Fs bHkgYmVjYXVzZSB0aGUgc2VydmVyIHJlcXVpcmVzIGNpcGhlcnMgbW9yZQ0KICAgc2VjdXJlIHRo YW4gdGhvc2Ugc3VwcG9ydGVkIGJ5IHRoZSBjbGllbnQuICBUaGlzIG1lc3NhZ2UgaXMgYWx3YXlz DQogICBmYXRhbC4iDQoNClRoaXMgaXMgYSB2ZXJ5IG5hcnJvdyBhbmQgc3BlY2lmaWMgZGVmaW5p dGlvbi4gVGhlIHNlcnZlciBzYXlzICJJIGtub3cgYWxsIHRoZSBjaXBoZXIgc3VpdGVzIHRoZSBj bGllbnQgYWR2ZXJ0aXNlcywgYW5kIGNvbnNpZGVyIHRoZW0gdG9vIHdlYWsiLiBCeSBjb250cmFz dCwgdW5zdXBwb3J0ZWRfY2lwaGVyX3N1aXRlcyBtZWFucyBzb21ldGhpbmcgbGlrZSAiSSBkb24n dCBoYXZlIGEgY2lwaGVyIHN1aXRlIGluIGNvbW1vbiB3aXRoIHRoZSBjbGllbnQiLiBUaGUgbGF0 dGVyIGNhbiBoYXBwZW4gd2hlbiB0aGUgY2xpZW50J3MgY2lwaGVyIHN1aXRlcyBhcmUgbW9yZSBz ZWN1cmUgdGhhbiB0aGUgc2VydmVyJ3MuDQoNCj4gV2hhdCBJIHdhbnQgaXMgdG8gYWRkIGEgbmV3 ICJ1bnN1cHBvcnRlZF9ncm91cHMiIGFsZXJ0IHRvIHVzZSBpbnN0ZWFkLiAoYm90aCBoZXJlIGFu ZCB0aGVyZSkgVGhlICJjbGllbnRfYXV0aGVudGljYXRpb25fZmFpbHVyZSIgYWxlcnQgc3VnZ2Vz dGlvbiBpcyB0byBwdWxsIHRoYXQgb3V0IG9mIHRoZSAiaGFuZHNoYWtlX2ZhaWx1cmUiIGNhdGNo YWxsLg0KDQpJIGhhdmUgYWJzb2x1dGVseSBubyBwcm9ibGVtIHdpdGggdGhlIG5ldyBhbGVydHM7 IG15IGNvbmNlcm4gaXMgYWJvdXQgcmVkZWZpbmluZyBleGlzdGluZyBhbGVydHMgKGFuZCwgZm9y IHRoYXQgbWF0dGVyLCByZWRlZmluaW5nIGV4aXN0aW5nIGNpcGhlciBzdWl0ZXM6KSkuDQoNCkNo ZWVycywNCg0KQW5kcmVpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYXZl IEdhcnJldHQgW21haWx0bzpkYXZlbWdhcnJldHRAZ21haWwuY29tXSANClNlbnQ6IEZyaWRheSwg SnVseSAyNCwgMjAxNSA3OjA5IEFNDQpUbzogQW5kcmVpIFBvcG92OyBFcmljIFJlc2NvcmxhDQpD YzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gbmV3IGVycm9yIGFsZXJ0cz8NCg0K T24gVGh1cnNkYXksIEp1bHkgMjMsIDIwMTUgMTA6NTI6NTkgcG0gQW5kcmVpIFBvcG92IHdyb3Rl Og0KPiBSYXRoZXIgdGhhbiByZW5hbWluZyBhbmQgb3RoZXJ3aXNlIG1vZGlmeWluZyB0aGUgbWVh bmluZyBvZiB0aGUgZXhpc3RpbmcgYWxlcnRzLCB3b3VsZCBpdCBiZSBiZXR0ZXIgdG8gZGVmaW5l IG5ldywgbW9yZSBncmFudWxhciBhbGVydHMgaW4gMS4zPyBXZSBjYW7igJl0IGFzY3JpYmUgbmV3 IG1lYW5pbmdzIHRvIGFsZXJ0cyBnZW5lcmF0ZWQgYnkgdGhlIGNvZGUgd2XigJl2ZSBzaGlwcGVk IGluIHRoZSBwYXN0Lg0KDQpJJ20gbm90IHByb3Bvc2luZyBjaGFuZ2luZyB0aGUgbWVhbmluZyBv ZiBleGlzdGluZyBhbGVydHMuIEF0IG1vc3QsIHRoZSBOZWdvdGlhdGVkIEZGLURIIGRyYWZ0IHdv dWxkIG5lZWQgdG8gYmUgdXBkYXRlZC9maXhlZC4NCg0KSSdtIHByb3Bvc2luZyByZW5hbWluZyAi aW5zdWZmaWNpZW50X3NlY3VyaXR5IiB0byAidW5zdXBwb3J0ZWRfY2lwaGVyX3N1aXRlcyIsIHdo aWNoIGlzIGV4cGxpY2l0bHkgd2hhdCBpdCdzIGJlZW4gZm9yIHNpbmNlIFRMUyAxLjAuIFRoZXJl IGlzbid0IGEgc3BlY2lmaWMgZXJyb3IgZGVmaW5lZCBmb3IgbGFjayBvZiBhIHN1cHBvcnRlZCBn cm91cCB5ZXQuIFJGQyA0NDkyIGp1c3Qgc2F5cyAiZmF0YWwgaGFuZHNoYWtlIGZhaWx1cmUgYWxl cnQiLiBUaGUgTmVnb3RpYXRlZCBGRi1ESCBkcmFmdCBoYXMgImluc3VmZmljaWVudF9zZWN1cml0 eSIgZm9yIHVuc3VwcG9ydGVkIGdyb3VwLiBfVGhhdF8gZG9lcyBjaGFuZ2UgdGhlIG1lYW5pbmcs IGFzIHByZXZpb3VzbHkgaXQgd2FzIGV4cGxpY2l0bHkgZGVmaW5lZCBmb3IgY2lwaGVyIGlzc3Vl cyBvbmx5LiBXaGF0IEkgd2FudCBpcyB0byBhZGQgYSBuZXcgInVuc3VwcG9ydGVkX2dyb3VwcyIg YWxlcnQgdG8gdXNlIGluc3RlYWQuIChib3RoIGhlcmUgYW5kIHRoZXJlKSBUaGUgImNsaWVudF9h dXRoZW50aWNhdGlvbl9mYWlsdXJlIiBhbGVydCBzdWdnZXN0aW9uIGlzIHRvIHB1bGwgdGhhdCBv dXQgb2YgdGhlICJoYW5kc2hha2VfZmFpbHVyZSIgY2F0Y2hhbGwuDQoNCkkganVzdCB3YW50IHRv IGNsYXJpZnkgdGhlIGV4aXN0aW5nIGFsZXJ0LCBub3QgcmV1c2UgaXQgZm9yIGEgcmVsYXRlZCBi dXQgZGlzdGluY3RseSBkaWZmZXJlbnQgYWxlcnQsIGFuZCBub3QgbHVtcCBzdHVmZiBpbnRvIGEg Y2F0Y2hhbGwgdGhhdCB3ZSBjYW4ndCBkZWJ1Zy4gOykNCg0KDQpEYXZlDQo= From nobody Thu Jul 23 23:32:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2302C1B2F68 for ; Thu, 23 Jul 2015 23:32:42 -0700 (PDT) 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 YnOm7UoWTLP3 for ; Thu, 23 Jul 2015 23:32:40 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DD61A92F6 for ; Thu, 23 Jul 2015 23:32:39 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id DE3A71A26DE; Fri, 24 Jul 2015 09:32:36 +0300 (EEST) Date: Fri, 24 Jul 2015 09:32:36 +0300 From: Ilari Liusvaara To: Andrei Popov Message-ID: <20150724063236.GA8759@LK-Perkele-VII> References: <20150720141036.GA32204@LK-Perkele-VII> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 06:32:42 -0000 On Fri, Jul 24, 2015 at 05:01:37AM +0000, Andrei Popov wrote: > > > - The certificate_types field in CertificateRequest is pretty much > > useless, since all supported algorithms are of signature type. > If the signature_algorithms extension officially becomes MTI, then > perhaps we can discus getting rid of certificate_types in the > CertificateRequest. Except we may want to use this field when we > introduce new certificate types (e.g. something like IEEE1609 certs). Don't confuse signature_algorithms extension and supported_signature_algorithms field of CertificateRequest. Those two carry similar tasks in opposite directions, except that ssa is REQUIRED with signature certs. There are seemingly no defaults for SSA, so it has to be non-empty for signature certs to work at all. And all present types of TLS 1.3 key exchange can only use signature certs. As for IEEE1609 certs, those are negotiated via certificate format negotiation, which is entierely separate mechanism (described in RFC 7250), not involving CertificateRequest message at all. -Ilari From nobody Thu Jul 23 23:41:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AF41A871B for ; Thu, 23 Jul 2015 23:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UPPERCASE_50_75=0.008] 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 VRK7OY2lx-2l for ; Thu, 23 Jul 2015 23:41:22 -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 7BE4F1B2D52 for ; Thu, 23 Jul 2015 23:41:22 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 3F788188860; Fri, 24 Jul 2015 09:41:19 +0300 (EEST) Date: Fri, 24 Jul 2015 09:41:19 +0300 From: Ilari Liusvaara To: Stephen Farrell Message-ID: <20150724064119.GA9208@LK-Perkele-VII> References: <201507221610.27729.davemgarrett@gmail.com> <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> <201507231143.46288.davemgarrett@gmail.com> <55B11EFC.6070400@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55B11EFC.6070400@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 06:41:24 -0000 On Thu, Jul 23, 2015 at 06:06:04PM +0100, Stephen Farrell wrote: > > > On 23/07/15 16:43, Dave Garrett wrote: > > We should just get more serious about banning old crap entirely to > > make dangerous misconfiguration impossible for TLS 1.3+ > > implementations. > > > > Right now, the restrictions section prohibits: RC4, SSL2/3, & > > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+ > > compatible with TLS 1.2, if available > > A suggestion - could we remove mention of anything that > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > and then have someone write a separate draft that adds a > column to the registry where we can mark old crap as > deprecated? Checked the ciphersuite registry. Of 316 negotiable ciphers, marking everything that doesn't work in TLS 1.3 or is DSS ciphersuite (nobody uses that) would leave 52 ciphersuites undeprecated. Unfortunately, completing the various sets could add up to 31 new ciphersuites... :-/ Flags: A => Anonymous (6+8) D => Dubious use (6+1). I guess IoT devices don't appreciate FFDHE. F => FFDHE (26+3) I => IoT foucus (18+12) N => New signature type (0+11), merging would take bending TLS 1.2 rules. R => RSA signature type with ECDHE (6+1) V => Vanity (24+8) The 52 are: --F-- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 --F-- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 A-F-- TLS_DH_anon_WITH_AES_128_GCM_SHA256 A-F-- TLS_DH_anon_WITH_AES_256_GCM_SHA384 ----- TLS_PSK_WITH_AES_128_GCM_SHA256 ----- TLS_PSK_WITH_AES_256_GCM_SHA384 -DFI- TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 -DFI- TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 ----- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ----- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ----R TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ----R TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 --FV- TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 --FV- TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 A-FV- TLS_DH_anon_WITH_ARIA_128_GCM_SHA256 A-FV- TLS_DH_anon_WITH_ARIA_256_GCM_SHA384 ---V- TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 ---V- TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 ---VR TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 ---VR TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 ---V- TLS_PSK_WITH_ARIA_128_GCM_SHA256 ---V- TLS_PSK_WITH_ARIA_256_GCM_SHA384 -DFV- TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256 -DFV- TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384 --FV- TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 --FV- TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 A-FV- TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256 A-FV- TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384 ---V- TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 ---V- TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 ---VR TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 ---VR TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 ---V- TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256 ---V- TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384 -DFV- TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256 -DFV- TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384 -DFI- TLS_DHE_RSA_WITH_AES_128_CCM -DFI- TLS_DHE_RSA_WITH_AES_256_CCM -DFI- TLS_DHE_RSA_WITH_AES_128_CCM_8 -DFI- TLS_DHE_RSA_WITH_AES_256_CCM_8 ---I- TLS_PSK_WITH_AES_128_CCM ---I- TLS_PSK_WITH_AES_256_CCM -DFI- TLS_DHE_PSK_WITH_AES_128_CCM -DFI- TLS_DHE_PSK_WITH_AES_256_CCM ---I- TLS_PSK_WITH_AES_128_CCM_8 ---I- TLS_PSK_WITH_AES_256_CCM_8 -DFI- TLS_PSK_DHE_WITH_AES_128_CCM_8 -DFI- TLS_PSK_DHE_WITH_AES_256_CCM_8 ---I- TLS_ECDHE_ECDSA_WITH_AES_128_CCM ---I- TLS_ECDHE_ECDSA_WITH_AES_256_CCM ---I- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ---I- TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 And the new 31 would be: ----R TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 ----- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 --F-- TLS_DHE_RSA_WITH_CHACHA20_POLY1305 ----- TLS_PSK_WITH_CHACHA20_POLY1305 ---I- TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 -DFI- TLS_DHE_PSK_WITH_CHACHA20_POLY1305 ---I- TLS_ECDHE_PSK_WITH_AES_128_GCM ---I- TLS_ECDHE_PSK_WITH_AES_256_GCM ---I- TLS_ECDHE_PSK_WITH_AES_128_CCM_8 ---I- TLS_ECDHE_PSK_WITH_AES_256_CCM_8 ---I- TLS_ECDHE_PSK_WITH_AES_128_CCM ---I- TLS_ECDHE_PSK_WITH_AES_256_CCM A---- TLS_ECDH_anon_WITH_AES_128_GCM_SHA256 A---- TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 A--V- TLS_ECDH_anon_WITH_ARIA_128_GCM_SHA256 A--V- TLS_ECDH_anon_WITH_ARIA_256_GCM_SHA384 A--V- TLS_ECDH_anon_WITH_CAMELLIA_128_GCM_SHA256 A--V- TLS_ECDH_anon_WITH_CAMELLIA_256_GCM_SHA384 A---- TLS_ECDH_anon_WITH_CHACHA20_POLY1305 A-F-- TLS_DH_anon_WITH_CHACHA20_POLY1305 ----N TLS_ECDHE_ECIDSA_WITH_AES_128_GCM_SHA256 ----N TLS_ECDHE_ECIDSA_WITH_AES_256_GCM_SHA384 ---VN TLS_ECDHE_ECIDSA_WITH_ARIA_128_GCM_SHA256 ---VN TLS_ECDHE_ECIDSA_WITH_ARIA_256_GCM_SHA384 ---VN TLS_ECDHE_ECIDSA_WITH_CAMELLIA_128_GCM_SHA256 ---VN TLS_ECDHE_ECIDSA_WITH_CAMELLIA_256_GCM_SHA384 ---IN TLS_ECDHE_ECIDSA_WITH_AES_128_CCM ---IN TLS_ECDHE_ECIDSA_WITH_AES_256_CCM ---IN TLS_ECDHE_ECIDSA_WITH_AES_128_CCM_8 ---IN TLS_ECDHE_ECIDSA_WITH_AES_256_CCM_8 ----N TLS_ECDHE_ECIDSA_WITH_CHACHA20_POLY1305 -Ilari From nobody Thu Jul 23 23:42:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F98F1A8AEE for ; Thu, 23 Jul 2015 23:42:38 -0700 (PDT) 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 P4qgk7A24muv for ; Thu, 23 Jul 2015 23:42:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AD21B2F65 for ; Thu, 23 Jul 2015 23:42:35 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 06:42:19 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Fri, 24 Jul 2015 06:42:19 +0000 From: Andrei Popov To: Ilari Liusvaara Thread-Topic: [TLS] Commentary on the client authentication presentation slides Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAAiSACAAAH3wA== Date: Fri, 24 Jul 2015 06:42:19 +0000 Message-ID: References: <20150720141036.GA32204@LK-Perkele-VII> <20150724063236.GA8759@LK-Perkele-VII> In-Reply-To: <20150724063236.GA8759@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: elisanet.fi; dkim=none (message not signed) header.d=none; x-originating-ip: [90.181.160.186] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:y0ZSuQ+24mZb/9AkDLyY7B7TN0RPdnfZkTBwQ0yeX2fD5RiZuAxxheTFVIoGQiMV0h8pm5aQRLUcifajegRf2Q4rAetaFCgfsMGp5xFiPSfzCkIOJY08xhbvt66l1gPxsbgWD/qwNn2FMkI2GWwMlw==; 24:G9mEWV+fTuKFxP1PCfzISWyOtMhjmsw92SIsyAHfkMaQEaHynBXMGYyKV+C35ENmbwyweunZ/nqPUXgz4O/DVdaGI7mNCxaL4rtpEI2828w=; 20:UDmep9kYRqY0QKO5u49Kdq+WdPboYdvK3DkCi+OZAq9jULBT4wVTL/6ijTgNbBTuDXTilntjdyNnH42juHnm3A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; blupr03mb1396: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(19580405001)(46102003)(2950100001)(76576001)(87936001)(110136002)(2656002)(5001960100002)(40100003)(74316001)(2900100001)(50986999)(86362001)(122556002)(19580395003)(92566002)(10090500001)(33656002)(62966003)(5002640100001)(54356999)(77156002)(77096005)(106116001)(76176999)(5003600100002)(99286002)(102836002)(189998001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 06:42:19.6130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 06:42:38 -0000 U291bmQgZ29vZCB0byBtZTsgaWYgdGhlIGdyb3VwIGFncmVlcyB0byByZW1vdmUgY2VydGlmaWNh dGVfdHlwZXMsIEknbGwgbWFrZSB0aGlzIGNoYW5nZSBpbiB0aGUgUFIuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJbGFyaSBMaXVzdmFhcmEgW21haWx0bzppbGFyaS5saXVz dmFhcmFAZWxpc2FuZXQuZmldIA0KU2VudDogRnJpZGF5LCBKdWx5IDI0LCAyMDE1IDg6MzMgQU0N ClRvOiBBbmRyZWkgUG9wb3YNCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBD b21tZW50YXJ5IG9uIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gcHJlc2VudGF0aW9uIHNsaWRl cw0KDQpPbiBGcmksIEp1bCAyNCwgMjAxNSBhdCAwNTowMTozN0FNICswMDAwLCBBbmRyZWkgUG9w b3Ygd3JvdGU6DQo+IA0KPiA+IC0gVGhlIGNlcnRpZmljYXRlX3R5cGVzIGZpZWxkIGluIENlcnRp ZmljYXRlUmVxdWVzdCBpcyBwcmV0dHkgbXVjaCAgDQo+ID4gdXNlbGVzcywgc2luY2UgYWxsIHN1 cHBvcnRlZCBhbGdvcml0aG1zIGFyZSBvZiBzaWduYXR1cmUgdHlwZS4NCj4gSWYgdGhlIHNpZ25h dHVyZV9hbGdvcml0aG1zIGV4dGVuc2lvbiBvZmZpY2lhbGx5IGJlY29tZXMgTVRJLCB0aGVuIA0K PiBwZXJoYXBzIHdlIGNhbiBkaXNjdXMgZ2V0dGluZyByaWQgb2YgY2VydGlmaWNhdGVfdHlwZXMg aW4gdGhlIA0KPiBDZXJ0aWZpY2F0ZVJlcXVlc3QuIEV4Y2VwdCB3ZSBtYXkgd2FudCB0byB1c2Ug dGhpcyBmaWVsZCB3aGVuIHdlIA0KPiBpbnRyb2R1Y2UgbmV3IGNlcnRpZmljYXRlIHR5cGVzIChl LmcuIHNvbWV0aGluZyBsaWtlIElFRUUxNjA5IGNlcnRzKS4NCg0KRG9uJ3QgY29uZnVzZSBzaWdu YXR1cmVfYWxnb3JpdGhtcyBleHRlbnNpb24gYW5kIHN1cHBvcnRlZF9zaWduYXR1cmVfYWxnb3Jp dGhtcyBmaWVsZCBvZiBDZXJ0aWZpY2F0ZVJlcXVlc3QuIFRob3NlIHR3byBjYXJyeSBzaW1pbGFy IHRhc2tzIGluIG9wcG9zaXRlIGRpcmVjdGlvbnMsIGV4Y2VwdCB0aGF0IHNzYSBpcyBSRVFVSVJF RCB3aXRoIHNpZ25hdHVyZSBjZXJ0cy4NCg0KVGhlcmUgYXJlIHNlZW1pbmdseSBubyBkZWZhdWx0 cyBmb3IgU1NBLCBzbyBpdCBoYXMgdG8gYmUgbm9uLWVtcHR5IGZvciBzaWduYXR1cmUgY2VydHMg dG8gd29yayBhdCBhbGwuDQoNCkFuZCBhbGwgcHJlc2VudCB0eXBlcyBvZiBUTFMgMS4zIGtleSBl eGNoYW5nZSBjYW4gb25seSB1c2Ugc2lnbmF0dXJlIGNlcnRzLg0KDQpBcyBmb3IgSUVFRTE2MDkg Y2VydHMsIHRob3NlIGFyZSBuZWdvdGlhdGVkIHZpYSBjZXJ0aWZpY2F0ZSBmb3JtYXQgbmVnb3Rp YXRpb24sIHdoaWNoIGlzIGVudGllcmVseSBzZXBhcmF0ZSBtZWNoYW5pc20gKGRlc2NyaWJlZCBp biBSRkMgNzI1MCksIG5vdCBpbnZvbHZpbmcgQ2VydGlmaWNhdGVSZXF1ZXN0IG1lc3NhZ2UgYXQg YWxsLg0KDQoNCi1JbGFyaQ0K From nobody Fri Jul 24 03:43:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982081A8AC8 for ; Fri, 24 Jul 2015 03:43:27 -0700 (PDT) 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 2kT3y_yhPGlm for ; Fri, 24 Jul 2015 03:43:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4331A8AA6 for ; Fri, 24 Jul 2015 03:43:25 -0700 (PDT) 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 (Postfix) with ESMTPS id 200ADC03F9; Fri, 24 Jul 2015 10:43:25 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-111.brq.redhat.com [10.34.0.111]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6OAhMPG029704 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 06:43:24 -0400 From: Hubert Kario To: Dave Garrett Date: Fri, 24 Jul 2015 12:43:17 +0200 Message-ID: <2433298.8v8VhukdnX@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <201507231421.15927.davemgarrett@gmail.com> References: <201507221610.27729.davemgarrett@gmail.com> <201507231421.15927.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart19973229.HYUFYfiIF4"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 10:43:27 -0000 --nextPart19973229.HYUFYfiIF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 23 July 2015 14:21:15 Dave Garrett wrote: > On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote: > > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell > > >=20 > > wrote: > > > A suggestion - could we remove mention of anything that > > > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > > > and then have someone write a separate draft that adds a > > > column to the registry where we can mark old crap as > > > deprecated? > >=20 > > I'm starting to lean towards this. I don't generally think of TLS 1= .3 as a > > vehicle for telling people how to configure use of TLS 1.2, and I t= hink > > it might be better to move all that stuff out. >=20 > If we've learned one thing from the past year of high-profile > vulnerabilities with names and logos, it's that TLS is not really sec= ure if > you don't take into account its weakest/oldest feature that's still > possible. I don't think any responsible TLS 1.3 spec can afford to no= t > acknowledge this. And I completely agree. FREAK and Logjam wouldn't happen at all if we d= idn't=20 drag with us stuff that was considered legacy 10 years ago. But stuff like "server MUST abort handshake if it sees export grade cip= hers in=20 Client Hello" (or anything similar) will just get ignored. For a user a= bad=20 connection is better than no connection. One works and the other doesn'= t, the=20 details are voodoo witchcraft. The way to remove all this legacy junk is to work towards sensible defa= ults in=20 libraries (RFC7568, RFC7465 style), not by putting antifeatures in prot= ocol=20 specifications. =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart19973229.HYUFYfiIF4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVshbKAAoJEJKo0bgB0vX1u2kQAJgZC3/HJOHVJZ+5M7kmKRXb bQP38dn0vqLptndlcaTHf/fDmm3S5eBHCcUjE8sRRNAHLzWabGGXVw2PUNm5z2cZ 7zz3Y5uTcsDjRFso2mKKeAQVIS1pJ5kpMhcp8RMpRP1OgrdcE5Q+vtzwv5goaJws sXHZ0blve9YGtjFV3O5CJbq4PFic+Qi/lcsRXlOdDZjuS8UYbD/fMTEknAkrY/WA DA/3jI88/iq8gOpeMT365NNyUrx8kkjcg30ewrj9WSTDedHYSLal+2dVILIwWNqR QY7vp8m4iVmy6jNGK4ujcn4C0XkK07kldP/eVGNqSG45FPU++ve0A9vtCpB/vsAh 564u0FvMku/bay+ebER73pfUHU5jrz1srri3SYuaKPnm2BOuY66TsJxE6zo0VIak jD8Er0hSqvFdIA/QGHXzY9QDgszJj13NmcI7XCDv0QjHqutEoJnTqFkCkWAhv7AV EUDxlLVL0JKHUsYPa7vpIeJZFIEzcAWSOGTxOOoZx4T01Q6I0tRWk1bXGrf8Tdxo 7aTU4NCEevuVno52ToeWzdQgLKaLs5c3LyyRalC2kkx+c8xGUtBNkRJFVt6MQA68 NIXAwMjMTj0x9JVaB+1RcjD+fqZc5vZZ4aAJ6RzVn2cbc0H1/1XgfOdvP0Kblvx+ IDO9YjGueS6hoC2CkyVf =tOmT -----END PGP SIGNATURE----- --nextPart19973229.HYUFYfiIF4-- From nobody Fri Jul 24 08:22:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E2F1B30D9 for ; Fri, 24 Jul 2015 08:22:18 -0700 (PDT) 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 fPDilaMOA9ie for ; Fri, 24 Jul 2015 08:22:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E9E1B30D5 for ; Fri, 24 Jul 2015 08:22:16 -0700 (PDT) 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 (Postfix) with ESMTPS id 15EC032B0C8; Fri, 24 Jul 2015 15:22:16 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-111.brq.redhat.com [10.34.0.111]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6OFMDWb027447 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 11:22:14 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 24 Jul 2015 17:22:08 +0200 Message-ID: <3965440.JCWWbo1jAa@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20150716150937.GA30989@LK-Perkele-VII> References: <20150715141523.GA13669@LK-Perkele-VII> <20150716150937.GA30989@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2769599.1PVPNEMR14"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 15:22:18 -0000 --nextPart2769599.1PVPNEMR14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 16 July 2015 18:09:38 Ilari Liusvaara wrote: > > > > 6.3.1.2. (Server Hello) > > >=20 > > > Well, at least it wouldn't be backward compatiblity hazard to rem= ove > > > session_id_len, since it comes after server version. > >=20 > > I'm sold. >=20 > However, that would change ServerHello parsing. >=20 > Thinking about it, if one decides to be careful with message parsing,= one > needs to assign all new/modified TLS 1.3 handshake messages new IDs. >=20 > Currently there is only one offending message type w.r.t. that: 14, w= hich > is server_configuration in 1.3 and server_hello_done in 1.2. >=20 > Some other messages share IDs, but I think those are compatible (even= > CertificateVerify, as it is just one digital signature in both). Server Key Exchange for DHE, ADH, SRP, etc. not to mention TLS1.1 vs TL= S1.2=20 it's not uncommon to have different parsers for "same" message type > > > Also, the record protection used for early handshake messages sho= uld be > > > indicated. > >=20 > > Can you expand on that? >=20 > How does the client know what record protection algorithms are valid > for 0RTT transmission for that server? And how does the client know that the algorithms came from the server. = We=20 should have a "client MUST wait for the full handshake to finish before= =20 recording this information" or we will have a very nice cipher downgrad= e. Just=20 having it signed is likely not a good idea, as they may depend on ciphe= rsuites=20 advertised by client. > > > Also, with regards to complications of DSA, just dump it? :-) > >=20 > > I'm fine with that if the chairs declare consensus on it. >=20 > As datapoint, either the scan that was used as basis of that curve > pruning doesn't support DSA, or there are no servers that even have > DSA certs. >=20 > I think I heard some time back that there are only 4 (or some other v= ery > small number) valid DSA SSL certs in the entiere public Internet. that scan uses Mozilla trust roots and reports only trusted servers (to= weed=20 out unmaintained ones out), Microsoft list is a bit bigger =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2769599.1PVPNEMR14 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVslglAAoJEJKo0bgB0vX1RtcQAItg0yE/50K7DykAKIhgnr/o hx0gOu1lup/52MYSbQA/nhiIE2hDLJKaK089rtUMZ7cG216s/QKjGiIQS6zRgC6p yHdjC2nCUkf/WbYS3FIfSC6vrnHrckGFtpo05uJWx3ZXNo9HEydTL7Niu5XeRw6d nrdQsyMJHKka76WuFw+RU5DeB/aM6WtCF7nra1PpYW/6SLTLpL5bBFd+JqkLxLYr mM9MBtSUbejm4pzfzniw/JS6iP7Me7G8l6QP4EmktTHkUcgn7b3rLExWXu6V2vhO 9LGZQdTklweNoJ/XfC+XDKWYkBtY7/HmPnzxckXeqRotLg7BN7NtuXtwnKxhcDS9 Ns2nGcNE41UQsaJwST8+xPKbuopdUfce6B/pk0Mg8MD1SuMPPfm3XTfcw3ccH5St gJ9jdliRwKALArb71k0OegbsWwXidjbPoJAQd1+TTBCxvTYRPS3tuBfChvwin1EZ xtdsZeMXYlbtpSyIBSqt8Lq8X36NgxBcReQi/2b9phSLCrFYxVq8eeXGGb7B0bOO hLudI5h1ZRNojK0J0gkWnHcPZ7FqfzRZF5dTtsKsDQocT27kdgZgSC+oV2uxh0yB d92L1vz143DgJO4A89i2l5y8Motae7SLxHCzBiLS+vgrBQiYwPDH4Uj1KM2nsaFE TZ6CalYg8k4UO+O8norU =cUje -----END PGP SIGNATURE----- --nextPart2769599.1PVPNEMR14-- From nobody Fri Jul 24 09:15:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449701A037B for ; Fri, 24 Jul 2015 09:15:55 -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 yqCIzIXBLUDS for ; Fri, 24 Jul 2015 09:15:54 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87621A87C0 for ; Fri, 24 Jul 2015 09:15:48 -0700 (PDT) Received: by qged69 with SMTP id d69so12904767qge.0 for ; Fri, 24 Jul 2015 09:15:48 -0700 (PDT) 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=BMEzeq4njNwnoZUQM4XXbMni1rETKUHxirgmI4gjqq4=; b=w8sU19bEYDwLwnfpxsMfvksFPvWYPRPUU9V2Td2wpwKVQa+fHttvUfrWozKF6nJFqU C8J0u5rnQSL9SmqysHUVFXA6x0LLP4aJIHPWhrg+0HzSfsZByL0zU6xaE5TSs8SIJCrS XE7TzW08YTmqPu6ELw2S7PXlPr3kgUBQyYJutOoHUapc4af86y6VPoyLmtkjQK5AlDtx uSii3hxQS4X+eJEPTEuChjFsnvDgHK6P8K/1S5RbkLgGS0iIBRWUKx4B3NL7ZjYDsG2h OWAk7yrFw/rQn7an/xE9LbEp5L6fJNuNUHUbo1u1Xqq+4yGnUzp5HKD5BD1wH4vW4DDg YQ+g== X-Received: by 10.140.131.81 with SMTP id 78mr23181150qhd.70.1437754548044; Fri, 24 Jul 2015 09:15:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id c88sm4270859qge.26.2015.07.24.09.15.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 24 Jul 2015 09:15:47 -0700 (PDT) From: Dave Garrett To: Andrei Popov Date: Fri, 24 Jul 2015 12:15:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507222139.46391.davemgarrett@gmail.com> <201507240109.25969.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507241215.46209.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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, 24 Jul 2015 16:15:55 -0000 On Friday, July 24, 2015 01:50:31 am Andrei Popov wrote: > > I'm proposing renaming "insufficient_security" to "unsupported_cipher_suites", which is explicitly what it's been for since TLS 1.0. > > Not quite. Insufficient_security alert is defined as follows: > " Returned instead of handshake_failure when a negotiation has > failed specifically because the server requires ciphers more > secure than those supported by the client. This message is always > fatal." > > This is a very narrow and specific definition. The server says "I know all the cipher suites the client advertises, and consider them too weak". By contrast, unsupported_cipher_suites means something like "I don't have a cipher suite in common with the client". The latter can happen when the client's cipher suites are more secure than the server's. Then if we wish to keep this as narrow as written, we can just have a separate one for unsupported with no judgment on strength: insufficient_security(71), // unchanged unsupported_cipher_suites(72), // new unsupported_groups(73), // new client_authentication_failure(74), // new e.g. RC4 gets insufficient_security & Camellia gets unsupported_cipher_suites Sounds good to me, if we prefer this. Dave From nobody Fri Jul 24 09:57:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E091ACD2F for ; Fri, 24 Jul 2015 09:57:46 -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 rHa05jW3A_Nv for ; Fri, 24 Jul 2015 09:57:45 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817F61ABC75 for ; Fri, 24 Jul 2015 09:57:45 -0700 (PDT) Received: by qgy5 with SMTP id 5so13319818qgy.3 for ; Fri, 24 Jul 2015 09:57:44 -0700 (PDT) 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=B3QLMh5mwVuKNbPgFQbiH420Tr5foG4/e/IpUu6fESA=; b=rH7AO+qvTPs2mJicMQ5PsZNIKPF57upGaUn0ynVvSYTiak4ATpr9LVVBlHLvuUDAmu OtaLKbFZ/+YDMpBg4cwF+Mo1ja5OYQNieAuZR2/At1TNSIKYOhOfqn4+3kQ56r6+/4LR Xu2LRH0CnynFqprQ58KwowaNWpKTjUwYdWQsPP3hakPuCSBU1GfUbxq4+aSqGvH7KY3i oAsaj0Kza3bYpBUaVlAVT5192fsCIbzxgjFbUT0c98EIQLLqsFZtE1PdutBHtmePh1E7 zO7wBirFYjpmzRwqvzcF214y/l8wpJB2evoje+4dAzIB9UW4rg8v3vR+tkUIkoh1c6x9 uQqw== X-Received: by 10.140.238.76 with SMTP id j73mr22266599qhc.41.1437757064859; Fri, 24 Jul 2015 09:57:44 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id j62sm4294048qhc.33.2015.07.24.09.57.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 24 Jul 2015 09:57:44 -0700 (PDT) From: Dave Garrett To: Hubert Kario Date: Fri, 24 Jul 2015 12:57:42 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507221610.27729.davemgarrett@gmail.com> <201507231421.15927.davemgarrett@gmail.com> <2433298.8v8VhukdnX@pintsize.usersys.redhat.com> In-Reply-To: <2433298.8v8VhukdnX@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507241257.43115.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 16:57:47 -0000 On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote: > And I completely agree. FREAK and Logjam wouldn't happen at all if we didn't > drag with us stuff that was considered legacy 10 years ago. > > But stuff like "server MUST abort handshake if it sees export grade ciphers in > Client Hello" (or anything similar) will just get ignored. For a user a bad > connection is better than no connection. One works and the other doesn't, the > details are voodoo witchcraft. To be clear, the wording I have in the PR is not this broad. It only requires aborting if export ciphers were offered by a TLS 1.3+ client, not just any client. The point is to ensure that all TLS 1.3 implementations cut this out and don't regress due to error or exploit. Applying it to everything would, unfortunately, be a mess. In particular, search engine spiders actually have a legitimate reason to have export ciphers actually still enabled. Dave From nobody Fri Jul 24 10:28:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08B1A1AD9 for ; Fri, 24 Jul 2015 10:28:19 -0700 (PDT) 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 9jhitBkVNNeS for ; Fri, 24 Jul 2015 10:28:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB311A1A7D for ; Fri, 24 Jul 2015 10:28:17 -0700 (PDT) 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 (Postfix) with ESMTPS id AC7C92E1238; Fri, 24 Jul 2015 17:18:48 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-111.brq.redhat.com [10.34.0.111]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6OHIkh6024023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 13:18:47 -0400 From: Hubert Kario To: Dave Garrett Date: Fri, 24 Jul 2015 19:18:41 +0200 Message-ID: <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-300.fc22.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <201507241257.43115.davemgarrett@gmail.com> References: <201507221610.27729.davemgarrett@gmail.com> <2433298.8v8VhukdnX@pintsize.usersys.redhat.com> <201507241257.43115.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2888615.WXAVBIlkHJ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 17:28:19 -0000 --nextPart2888615.WXAVBIlkHJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 24 July 2015 12:57:42 Dave Garrett wrote: > On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote: > > And I completely agree. FREAK and Logjam wouldn't happen at all if = we > > didn't drag with us stuff that was considered legacy 10 years ago. > >=20 > > But stuff like "server MUST abort handshake if it sees export grade= > > ciphers in Client Hello" (or anything similar) will just get ignore= d. For > > a user a bad connection is better than no connection. One works and= the > > other doesn't, the details are voodoo witchcraft. >=20 > To be clear, the wording I have in the PR is not this broad. It only > requires aborting if export ciphers were offered by a TLS 1.3+ client= , not > just any client. and how a server can tell that the client is TLS1.3 only and not TLS1.0= =2Dup-to- TLS1.3? > The point is to ensure that all TLS 1.3 implementations > cut this out and don't regress due to error or exploit. Applying it t= o > everything would, unfortunately, be a mess. In particular, search eng= ine > spiders actually have a legitimate reason to have export ciphers actu= ally > still enabled. and not only them, opportunistic encryption in SMTP is another example technically it's already in the draft, isn't it? - TLSv1.3 supports onl= y AEAD,=20 all export ciphers were either CBC or stream mode - if you intend to ac= cept=20 only TLS1.3 reply from server there's no point in including them, moreo= ver=20 negotiating them is a clear bug and protocol violation anyway but if you want a "clients SHOULD NOT advertise support for ciphersuite= s=20 incompatible with TLS1.3 if it will not accept a TLS1.2 or lower protoc= ol=20 reply from server" as a reminder/idea for implementers then it certainl= y won't=20 hurt =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2888615.WXAVBIlkHJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVsnNxAAoJEJKo0bgB0vX1jSgQAI53s/l6bWnp6Z5lUnnFas34 BzabbUIet87dvCIFXVY7SXeSpJCMgy8pOheDh8js/yOKp9Fo4SUQ7zV9abXwac0Q GKU7peS50Mv6I/aORUZ6Bp7VpL2KHzuQtIyNdGm9gbYlGSAudBlag3+GRE0ypucQ /KJnnqk3mMhiBPagw0JaerIIk7hPpsYuWFNdJhXB2Wq/9eoks8EIw7criQ3+wQd7 HSIr91yfVMBIhPgPA4X68lJhxbL4u5NmlKZwlRJEbVypM7zHMLu58x+TACS6gfiz b1ovMO/Qj6RBLFBPxAiLzawdygtmoLWVfDtM1HOke84TCY6/l+d1Uewgm3THLM1h uPJkhUh9mpWUe345XiJgL2owO7WiQs4F2TFlkEknTY8vuYv+4C2Yy8xpbzZhvW5U mFXQUbSn9BUC4esx56z4CVvSI6HNm4ztc+jN/U5DfxCb5M7u52dRRYW0i5MZqdRt Ro78u9DejZCuGnYPVacOfHDiWdwDxPmcH7Qe1NogqGwakr2S0dD3Uop86HXaEW7c RD1oluzsC7Mg+eE9s1W4TfG2A/qNTHOfhNcvpsz/vyMtCDM1wOfasVCe0t9knjSY mHjTKoDz35VARKt1+85GMOiv/628fGsMX5NKUbaQFThrH55guclPz2T7q6oQaHqX caLBaWhqQRhiN62uF8Ff =20hy -----END PGP SIGNATURE----- --nextPart2888615.WXAVBIlkHJ-- From nobody Fri Jul 24 11:04:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCCF1A89F1 for ; Fri, 24 Jul 2015 11:04:12 -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 Rebjyz-Ojes1 for ; Fri, 24 Jul 2015 11:04:11 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4B11ACDEB for ; Fri, 24 Jul 2015 11:03:16 -0700 (PDT) Received: by qkfc129 with SMTP id c129so19095443qkf.1 for ; Fri, 24 Jul 2015 11:03:15 -0700 (PDT) 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=ZbC41UBeKFWD7umGsHMT49vJ4eVsjD1VuiIvACvrX0o=; b=OYRjPDzGz359J3hUS4Y5HnmC9jFEsqXE7Mt1jc9v62RsCkJ/9u0AWHPs7iruG89Rim lQDP+zZXHVq1V4tSWrmSvujydvoZjFZOrg6V+u3J3iIDof296ZmXJhx+Mb0+njY9KwcL /5LQdLH66dR4JkvjZMydF+8rejqAzGEyzIzoR0ETwWo5t2X7Nm3GrMcGHJl6Hp2QxQQV ESTsshoDZVgT/F5yZhmZ0BUbp2P9JBbSW92Ak+2tSQmmwqqhUUNL6aBUPSkP/bFURoFr /2DhS1Uqpc3kPG6Mu7T2OOejVW9B1qWDoHWp3K7hI4sSPyUYUZbCYgBc1UA6M4DWIzKB TjmA== X-Received: by 10.55.40.65 with SMTP id o62mr21467071qkh.41.1437760995458; Fri, 24 Jul 2015 11:03:15 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id o64sm4421694qkh.25.2015.07.24.11.03.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 24 Jul 2015 11:03:14 -0700 (PDT) From: Dave Garrett To: Hubert Kario Date: Fri, 24 Jul 2015 14:03:13 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> In-Reply-To: <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201507241403.14071.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 18:04:12 -0000 On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote: > On Friday 24 July 2015 12:57:42 Dave Garrett wrote: > > To be clear, the wording I have in the PR is not this broad. It only > > requires aborting if export ciphers were offered by a TLS 1.3+ client, not > > just any client. > > and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to- > TLS1.3? TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 only. A TLS 1.0-1.2 client, or at least one offering that, is what it would not complain about. For the rare case of "legitimate" use of export ciphers, namely spiders, it'll need a fallback attempt with a full set of suites. Export ciphers are not something we should be accounting for allowance of in any protocol we want to claim to be secure. We do have to remember that even _offering_ them is dangerous, even if they're not negotiated. It's dangerous to even _support_ them, even if not offering. Having this in any way presents an unacceptable attack surface for a MitM to try and find a way to confuse implementations into using them. If all implementations were perfect, yeah, this wouldn't be a problem. History has shown this is not the case. :( Dave From nobody Fri Jul 24 11:14:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937B21ACD13 for ; Fri, 24 Jul 2015 11:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BwOhGDyNm6xq for ; Fri, 24 Jul 2015 11:14:18 -0700 (PDT) Received: from BLU004-OMC3S33.hotmail.com (blu004-omc3s33.hotmail.com [65.55.116.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9833F1ACC85 for ; Fri, 24 Jul 2015 11:14:15 -0700 (PDT) Received: from BLU177-W51 ([65.55.116.74]) by BLU004-OMC3S33.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 24 Jul 2015 11:13:49 -0700 X-TMN: [alusQMfAT0QkhD72dS3viNrs0qK8cjcD] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Dave Garrett , Hubert Kario Date: Fri, 24 Jul 2015 11:13:41 -0700 Importance: Normal In-Reply-To: <201507241403.14071.davemgarrett@gmail.com> References: <201507221610.27729.davemgarrett@gmail.com>, <201507241257.43115.davemgarrett@gmail.com>, <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com>, <201507241403.14071.davemgarrett@gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jul 2015 18:13:50.0844 (UTC) FILETIME=[7E068BC0:01D0C63C] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2015 18:14:19 -0000 > On Friday=2C July 24=2C 2015 01:18:41 pm Hubert Kario wrote:=0A= >> On Friday 24 July 2015 12:57:42 Dave Garrett wrote:=0A= >>> To be clear=2C the wording I have in the PR is not this broad. It only= =0A= >>> requires aborting if export ciphers were offered by a TLS 1.3+ client= =2C not=0A= >>> just any client.=0A= >>=0A= >> and how a server can tell that the client is TLS1.3 only and not TLS1.0-= up-to-=0A= >> TLS1.3?=0A= >=0A= > TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 on= ly. A TLS 1.0-1.2 client=2C or at least one offering that=2C is what it wou= ld not complain about.=0A= >=0A= > For the rare case of "legitimate" use of export ciphers=2C namely spiders= =2C it'll need a fallback attempt with a full set of suites. Export ciphers= are not something we should be accounting for allowance of in any protocol= we want to claim to be secure.=0A= >=0A= > We do have to remember that even _offering_ them is dangerous=2C even if = they're not negotiated. It's dangerous to even _support_ them=2C even if no= t offering. Having this in any way presents an unacceptable attack surface = for a MitM to try and find a way to confuse implementations into using them= . If all implementations were perfect=2C yeah=2C this wouldn't be a problem= . History has shown this is not the case. :(=0A= =0A= Personally=2C I don't think this is worth the effort. You'd need a full lis= t of EXPORT cipher hardcoded=2C and there are also EXPORT1024 ciphers not i= n the cipher suite registry but less dangerous. It is rare for current TLS = 1.2 clients to offer export ciphers either=2C and most practical attacks ar= e prevented by disabling them on the server side. = From nobody Fri Jul 24 16:26:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6651F1ACECB for ; Fri, 24 Jul 2015 16:26:39 -0700 (PDT) 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 LurwleIbhSnL for ; Fri, 24 Jul 2015 16:26:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EEB61ACE94 for ; Fri, 24 Jul 2015 16:26:37 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 23:26:19 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Fri, 24 Jul 2015 23:26:19 +0000 From: Andrei Popov To: Dave Garrett Thread-Topic: [TLS] new error alerts? Thread-Index: AQHQxZ/bGudh2TqShEeKMw5Vn1emwZ3p6+uQgAAmpoCAAAhMIIAAseCAgAB2viA= Date: Fri, 24 Jul 2015 23:26:18 +0000 Message-ID: References: <201507222139.46391.davemgarrett@gmail.com> <201507240109.25969.davemgarrett@gmail.com> <201507241215.46209.davemgarrett@gmail.com> In-Reply-To: <201507241215.46209.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [85.70.249.143] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:bjDsVWSPde64TcgIcnPhYGLTFkrG5+lmEKyMLMQEniWQf2x3GttmMAKbn/Uh7UJ2W1wMX4tWNrtP/mKo61buwxJuUiMIyHD4YSF6Qsn57aCWlw/JZ7WqchpeQTK+jP0mLtTnPsvqJbC/+cBNzMZRWA==; 24:euByTTiTvM7ecccFPm0ZGtGafbp8o4W16LLFZTeLDeMIGjRRkRjJuruf2Ux0mMuZrPORpfiLhez/dI2Co9H1X8r0c1bkke+N0YWnQvqTDeM=; 20:VBdkm9S/l0nnzXLaYzJZ/b/v3uO3mmXS0PvPiWtHNjsa7+yATlTqqPDKCrG3feAm3Qv/CUz/2y5RYehYjJYEYA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; blupr03mb1396: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(54356999)(77156002)(106116001)(93886004)(77096005)(102836002)(189998001)(99286002)(66066001)(5002640100001)(33656002)(76176999)(5003600100002)(110136002)(87936001)(2950100001)(46102003)(5001920100001)(2656002)(5001960100002)(19580405001)(76576001)(122556002)(19580395003)(10090500001)(1411001)(50986999)(86362001)(40100003)(92566002)(74316001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 23:26:18.9478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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, 24 Jul 2015 23:26:39 -0000 WWVzLCB0aGlzIHNvdW5kcyBnb29kIHRvIG1lIHRvby4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhdmUgR2FycmV0dCBbbWFpbHRvOmRh dmVtZ2FycmV0dEBnbWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBKdWx5IDI0LCAyMDE1IDY6MTYg UE0NClRvOiBBbmRyZWkgUG9wb3YNCkNjOiBFcmljIFJlc2NvcmxhOyB0bHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbVExTXSBuZXcgZXJyb3IgYWxlcnRzPw0KDQpPbiBGcmlkYXksIEp1bHkgMjQs IDIwMTUgMDE6NTA6MzEgYW0gQW5kcmVpIFBvcG92IHdyb3RlOg0KPiA+IEknbSBwcm9wb3Npbmcg cmVuYW1pbmcgImluc3VmZmljaWVudF9zZWN1cml0eSIgdG8gInVuc3VwcG9ydGVkX2NpcGhlcl9z dWl0ZXMiLCB3aGljaCBpcyBleHBsaWNpdGx5IHdoYXQgaXQncyBiZWVuIGZvciBzaW5jZSBUTFMg MS4wLg0KPiANCj4gTm90IHF1aXRlLiBJbnN1ZmZpY2llbnRfc2VjdXJpdHkgYWxlcnQgaXMgZGVm aW5lZCBhcyBmb2xsb3dzOg0KPiAiIFJldHVybmVkIGluc3RlYWQgb2YgaGFuZHNoYWtlX2ZhaWx1 cmUgd2hlbiBhIG5lZ290aWF0aW9uIGhhcw0KPiAgICBmYWlsZWQgc3BlY2lmaWNhbGx5IGJlY2F1 c2UgdGhlIHNlcnZlciByZXF1aXJlcyBjaXBoZXJzIG1vcmUNCj4gICAgc2VjdXJlIHRoYW4gdGhv c2Ugc3VwcG9ydGVkIGJ5IHRoZSBjbGllbnQuICBUaGlzIG1lc3NhZ2UgaXMgYWx3YXlzDQo+ICAg IGZhdGFsLiINCj4gDQo+IFRoaXMgaXMgYSB2ZXJ5IG5hcnJvdyBhbmQgc3BlY2lmaWMgZGVmaW5p dGlvbi4gVGhlIHNlcnZlciBzYXlzICJJIGtub3cgYWxsIHRoZSBjaXBoZXIgc3VpdGVzIHRoZSBj bGllbnQgYWR2ZXJ0aXNlcywgYW5kIGNvbnNpZGVyIHRoZW0gdG9vIHdlYWsiLiBCeSBjb250cmFz dCwgdW5zdXBwb3J0ZWRfY2lwaGVyX3N1aXRlcyBtZWFucyBzb21ldGhpbmcgbGlrZSAiSSBkb24n dCBoYXZlIGEgY2lwaGVyIHN1aXRlIGluIGNvbW1vbiB3aXRoIHRoZSBjbGllbnQiLiBUaGUgbGF0 dGVyIGNhbiBoYXBwZW4gd2hlbiB0aGUgY2xpZW50J3MgY2lwaGVyIHN1aXRlcyBhcmUgbW9yZSBz ZWN1cmUgdGhhbiB0aGUgc2VydmVyJ3MuDQoNClRoZW4gaWYgd2Ugd2lzaCB0byBrZWVwIHRoaXMg YXMgbmFycm93IGFzIHdyaXR0ZW4sIHdlIGNhbiBqdXN0IGhhdmUgYSBzZXBhcmF0ZSBvbmUgZm9y IHVuc3VwcG9ydGVkIHdpdGggbm8ganVkZ21lbnQgb24gc3RyZW5ndGg6DQoNCmluc3VmZmljaWVu dF9zZWN1cml0eSg3MSksICAvLyB1bmNoYW5nZWQgdW5zdXBwb3J0ZWRfY2lwaGVyX3N1aXRlcyg3 MiksICAvLyBuZXcgdW5zdXBwb3J0ZWRfZ3JvdXBzKDczKSwgIC8vIG5ldyBjbGllbnRfYXV0aGVu dGljYXRpb25fZmFpbHVyZSg3NCksICAvLyBuZXcNCg0KZS5nLiBSQzQgZ2V0cyBpbnN1ZmZpY2ll bnRfc2VjdXJpdHkgJiBDYW1lbGxpYSBnZXRzIHVuc3VwcG9ydGVkX2NpcGhlcl9zdWl0ZXMNCg0K U291bmRzIGdvb2QgdG8gbWUsIGlmIHdlIHByZWZlciB0aGlzLg0KDQoNCkRhdmUNCg== From nobody Fri Jul 24 20:17:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82DD1ACE48 for ; Fri, 24 Jul 2015 20:17:29 -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 QvfIMP2Vv1t1 for ; Fri, 24 Jul 2015 20:17:29 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0413E1ACEFC for ; Fri, 24 Jul 2015 20:17:23 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so48095083wib.0 for ; Fri, 24 Jul 2015 20:17:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ZSqGidcGWY0oHUKdYIRQIXOCXP9rtHYApqsXDud8cmU=; b=kcmbBjMgivc8AcorF8i4GNF1B20CzFBRvWR3sQ+uAoMRfyCRlLVWU0+vBX+RXw2ORo QoRMIO6ic+NBLOUd19yn57GH+wz6IwRxLx070Rg4iL2tkLp724Ex9u2wEvahYEcK07O2 DiYhnjeMr+Eu+Y48CeM/xaR7iQ0wFgUa6LYvzNWTUWOQGszxbw6wB8tH6nqNe6axuuU7 9S0bKcAJ5kZJwWsfle0X+4sXUUw0WVAlpLQVMiHQwNN4xZGl56pZyepA0fGfE25onXrZ slsU/SotXGoY8CGkcdny6t9519yhyvEGejogLvI5aPKOODzBte4xQZRPWB+ttIVsoYZg ET4w== X-Gm-Message-State: ALoCoQmQiJ6xieVc6nLH6mFmxPIc2XCC1uBjVTyTwt40MDIVBTTvSqSP0Hy/KscyeBmAKikhTcyA X-Received: by 10.194.93.226 with SMTP id cx2mr32403488wjb.28.1437794241809; Fri, 24 Jul 2015 20:17:21 -0700 (PDT) Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by smtp.gmail.com with ESMTPSA id ft5sm1260117wib.4.2015.07.24.20.17.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 20:17:21 -0700 (PDT) Date: Sat, 25 Jul 2015 05:17:20 +0200 From: Aaron Zauner To: Andrei Popov Message-ID: <20150725031717.GA17810@typhoon.azet.org> References: <201507222139.46391.davemgarrett@gmail.com> <201507240109.25969.davemgarrett@gmail.com> <201507241215.46209.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] new error 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: Sat, 25 Jul 2015 03:17:30 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Andrei Popov [25/07/2015 01:26:41] wrote: > Yes, this sounds good to me too. >=20 +1. Aaron --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVsv+9AAoJEOTbZJL9ubXV0ucP/1y10wgrB5+7rCi37HHGwU/9 DWfzddEvwkeSkdrLHQ9vKBuSaoJ3Z8GF8Bh5pOEeEXZXHsCNS3p9ZbG6qylTB+Q2 tNxHzxQmWU0LrhLC2OEoD91Tk6j3b3/tvVcNj9NSUlGjzI1vMDjLcik83+vElCLf ae0p0Wc3DtTTyAeMp8AGVd1/M0K8OinKuHOB6wGb3a/MyFvobaofcHPmLW8LTZTI 6Mkev+pkrptG2yC0O4DWCGWGVEKXUTNbi2pLCf2nNakaqPjfKsCDxvK5f9Znsek7 MpO0IOjXSjZ/28h3pKY1/wIrlt66YOMzv/dMIpweZNfJJKnohAX/aQrfXMBjaCND blojIrH67brUDNQtaWxznfyUu52p7euN+jpwMQGpxjtd3fN/KR/jJF1dnWKGEEKW hSN6BGn/va5stZlzyIauUF6D1WwsbItp48P5A4e86NHSFpYPsqh6FiYBHFdPfVRG FRmJBfF8bOT+nzxHWfibAQgA/5ik+vWrv/4CBNJa6xlqY7BHPuG4mZ0S7hgqaKTR zXbkIHshffRu61Yx97Z9nE8SigNNtyT1AfOpjfjlSB5la2rNySZvfU6WSsXe2WK+ o8+5ntyJzK+oZahjeoId4NyxVz/q9f39SyWrPlMlwSXAVcdovt9WlfRkwWvlPo0d ilvjGNOqAggrW+ut/OBl =NxhK -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From nobody Fri Jul 24 22:35:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13071B2B18 for ; Fri, 24 Jul 2015 22:35:56 -0700 (PDT) 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 POA6qKV171IF for ; Fri, 24 Jul 2015 22:35:54 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C721B2B2B for ; Fri, 24 Jul 2015 22:35:52 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 12179699AB; Sat, 25 Jul 2015 08:35:49 +0300 (EEST) Date: Sat, 25 Jul 2015 08:35:49 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150725053549.GA24205@LK-Perkele-VII> References: <201507221610.27729.davemgarrett@gmail.com> <1724827.ajpDBsKllU@pintsize.usersys.redhat.com> <201507231143.46288.davemgarrett@gmail.com> <55B11EFC.6070400@cs.tcd.ie> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 05:35:57 -0000 On Thu, Jul 23, 2015 at 07:10:30PM +0200, Eric Rescorla wrote: > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell > wrote: > > > A suggestion - could we remove mention of anything that > > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > > and then have someone write a separate draft that adds a > > column to the registry where we can mark old crap as > > deprecated? > > > > Not sure if it'd work though. > > > > I'm starting to lean towards this. I don't generally think of TLS 1.3 as a > vehicle > for telling people how to configure use of TLS 1.2, and I think it might be > better > to move all that stuff out. The MUST/SHOULD list is presumably: {ECDHE_RSA,ECDHE_ECDSA,PSK}*{AES-128-GCM,AES-256-GCM,Chacha20-Poly1305}? (9 ciphersuites)? Or are there some others there as well (of course, if new signatures appear and get their own ciphersuites, then three of those too)? Then what to mark as deprecated? Everything that doesn't work with TLS 1.3 is pretty obvious candidate. Which would mean deprecating TLS 1.0 and 1.1, as all ciphersuites for those get deprecated. Then I made this table of ciphersuites that work with TLS 1.3: +---------------+-------+-------+-------+-------+ | |AESGCM |VANITY |AESCCM |CHACHA | +---------------+-------+-------+-------+-------+ |DHE_RSA |Y |Y |Y |P | |DHE_DSS |Y |Y |Y |- | |DHE_PSK |Y |Y |- |- | |DHE_anon |Y |Y |Y |- | |ECDHE_RSA |Y |Y |- |P | |ECDHE_ECDSA |Y |Y |Y |P | |ECDHE_PSK |P |- |P |P | |ECDHE_anon |- |- |- |- | |ECDHE_ECIDSA |- |- |- |- | |PSK |Y |Y |Y |P | +---------------+-------+-------+-------+-------+ Legend: - => No active proposal, P => active I-D proposes these, Y => In registry AES-GCM => AES-GCM ciphers VANITY => ARIA and CAMELLIA (GCM). SEED doesn't have AEAD. AES-CCM => AES-CCM ciphers CHACHA => Chacha20-Poly1305. Comments on some methods: - DHE_RSA: Uses FFDHE, problematic especially on 1.2 and older. - DHE_DSS: Virtually nobody uses this or will use this (already removed from two major browsers. - DHE_PSK: IoT type, but I don't think IoT appriciates FFDHE. - DHE_anon: Anonymous. - ECDHE_RSA: ECC certs are still much harder to get than RSA. - ECDHE_anon: Should add if not deprecating anonymous. - ECDHE_ECIDSA: New signature scheme. Or try merging this with ECDHE_ECDSA (requires bit of bending of 1.2 rules). - PSK: Needed for resumption in TLS 1.3. -Ilari From nobody Fri Jul 24 22:46:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128A21B2B73 for ; Fri, 24 Jul 2015 22:46:25 -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 pFMNpEmQe15H for ; Fri, 24 Jul 2015 22:46:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FAFA1B2B72 for ; Fri, 24 Jul 2015 22:46:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 91496284B64; Sat, 25 Jul 2015 05:46:22 +0000 (UTC) Date: Sat, 25 Jul 2015 05:46:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150725054622.GK4347@mournblade.imrryr.org> References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507241403.14071.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] ban more old crap 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: Sat, 25 Jul 2015 05:46:25 -0000 On Fri, Jul 24, 2015 at 02:03:13PM -0400, Dave Garrett wrote: > > and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to- > > TLS1.3? > > TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 > only. A TLS 1.0-1.2 client, or at least one offering that, is what it > would not complain about. We can probably put the "export" ciphersuite issue out of its misery, already in email, these are no longer seen on the public Internet. The latest official versions of all supported Postfix releases now turn off "export" ciphers (and also single-DES) by default. We've also by default turned off SSLv2 and SSLv3 (neither are needed for SMTP interoperability). What we've cannot yet turn off is RC4. That's still sufficiently widely used that disabling RC4 would result in excessive cleartext fallback and even in some cases failure to deliver email. So for opportunistic TLS (in SMTP) we've raised the bar to exclude deprecated TLS features that we can (finally) easily do without. I hope, that by ~2017, RC4 will no longer be required either, and we'll be able to disable RC4 in Postfix at that time. If I recall correctly, the upcoming OpenSSL 1.1.0 release will by default also compile with no "export" ciphers, SSLv2 or SSLv3 support. We're starting to leave some of the older cruft behind. Let's get Chacha20 widely deployed (for systems without hardware AES), and the passage of time lead to more RC4-only systems being replaced, and in the not too distant future, even opportunistic TLS clients should be able to forgo RC4, but we're not quite there yet today. -- Viktor. From nobody Fri Jul 24 23:54:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058AC1B2D03 for ; Fri, 24 Jul 2015 23:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 AutR-HrHmV4l for ; Fri, 24 Jul 2015 23:54:39 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 809601B2D02 for ; Fri, 24 Jul 2015 23:54:39 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3720E74000A for ; Sat, 25 Jul 2015 06:54:38 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 1FC6D740005 for ; Sat, 25 Jul 2015 06:54:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437807278; bh=UrznYmvgqA2Mx6GzPYjgioleDxl14TIlLMl7W8snAso=; h=From:To:Subject:Date:References:In-Reply-To:From; b=XgSB+abZJYic5Ff4v0N2GMDTPJP+Bup8MUBnrOUCKDO1b6cTfpkE0vY8SLkr0HDpW ANQ96L9rckEGuYA1pCS6FZ4OdWCkE8JL83V9rOR6vuhpKvn6cz9Tsc8P1zgHhVz5p+ oNgwXvJ9tqUL3ZHpzKV4Do5QGIdFcv/S3sHz2oZ0= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 1BD7F1E09A for ; Sat, 25 Jul 2015 06:54:38 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 25 Jul 2015 01:54:37 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Sat, 25 Jul 2015 01:54:36 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: [TLS] ban more old crap Thread-Index: AQHQxWn1V9PLNbSSek+n2xTWp60PmZ3pnfIAgAATxICAARJggIAAaJ0AgAAF3YCAAAxxgIAAxHUA//+/LHA= Date: Sat, 25 Jul 2015 06:54:36 +0000 Message-ID: References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> In-Reply-To: <20150725054622.GK4347@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.153.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 06:54:41 -0000 > What we've cannot yet turn off is RC4. Then do not use TLS 1.3 From nobody Sat Jul 25 02:28:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A742B1A01EC for ; Sat, 25 Jul 2015 02:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 s4FWJGI-ThzN for ; Sat, 25 Jul 2015 02:28:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611401A1B86 for ; Sat, 25 Jul 2015 02:28:15 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-a3-55b356ad4cf4 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.25.29223.DA653B55; Sat, 25 Jul 2015 11:28:13 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.7]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Sat, 25 Jul 2015 11:28:12 +0200 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-02.txt Thread-Index: AQHQxrT1jraT/AGJ3EGwUDbzhcU+0Z3r6wkA Date: Sat, 25 Jul 2015 09:28:12 +0000 Message-ID: References: <20150725083606.926.69740.idtracker@ietfa.amsl.com> In-Reply-To: <20150725083606.926.69740.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <3D6E9F5932E85C41A6157B2305347A0F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje7asM2hBi1zFCw+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqu+n6wFSyQrdnWsYGlgvCDRxcjJISFgInH44DNWCFtM4sK9 9WxdjFwcQgJHGSWe3T0DlhASWMQo0XBTBMRmEzCQmLunAaiIg0NEQFHi0+dskLCwQIjE4eVH mEFsEYFQiSk/G1khbCOJm5/+M4LYLAKqEqtWTmAHsXkFzCVmf73LBDHeXuLqlvlgNqeAg8Tc iadZQGxGoHu+n1oDFmcWEJe49QSiRkJAQGLJnvPMELaoxMvH/8B2iQroSUy/uA0qriSx6PZn JpAzmQU0Jdbv0ocYYy2xeNJhqJGKElO6H0KdIyhxcuYTlgmM4rOQbJuF0D0LSfcsJN2zkHQv YGRdxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYVQe3/DbYwfjyueMhRgEORiUe3geqm0OF WBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRh/H571jlnGZ2 A9vHfVvf/WbrO3SjI3bdSpbtJ37FV/1ZbLwq4DVr9u6u8n7mR9tbJJ9bXg7NOem6+tUB+yx+ v4Yil2Vmp98s8Aw5G7LFWF65Othb2YL7OUdYvHjf3I22rVemL/LqftfkMDu/wPjypHvzdb+4 rNS5d99KrExgr9jLjNmLHwspsRRnJBpqMRcVJwIAK8H0cYsCAAA= Archived-At: Subject: Re: [TLS] New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-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: Sat, 25 Jul 2015 09:28:17 -0000 VGhhbmtzIGZvciB0aGUgZ29vZCBjb21tZW50cyBkdXJpbmcgdGhlIG1lZXRpbmcuIFRoaXMgbmV3 IHZlcnNpb24gc2hvdWxkDQp0YWtlIGNhcmUgb2YgdGhlbSBhbGw6DQoNCi0gVXBkYXRlZCB0aGUg UFJGIGFuZCBFQ0MgY3VydmVzIGZvciB0aGUgQUVTLTI1NiBjaXBoZXIgc3VpdGVzLg0KLSBJbmNs dWRlZCBTSEFfMjU2IGFuZCBTSEFfMzg0IGluIHRoZSBjaXBoZXIgc3VpdGUgbmFtZXMuDQotIE1h ZGUgaXQgY2xlYXIgd2hpY2ggc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhhdCBhcHBseS4gRm9y IHRoZSBQU0sNCmFzcGVjdHMsIEkgbWFkZSBhIHNob3J0IHN1bW1hcnkuDQoNCkkgYWxzbyBtYWRl IHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCg0KLSBGaXhlZCBhIHdyb25nIHJlZmVyZW5jZSB0byB0 aGUgRUNDIFRMUyBSRkMuDQotIEFkZGVkIG1pc3NpbmcgcmVmZXJlbmNlIHRvIEFFQURfQUVTXzEy OF9DQ01fOA0KLSBEaXZpZGVkIHRoZSByZWZlcmVuY2VzIGludG8gTm9ybWF0aXZlIGFuZCBJbmZv cm1hbA0KDQpIb3cgZG8gd2UgcHJvY2VlZCB3aXRoIHRoaXMgbm93PyBGcm9tIG15IHBvaW50IG9m IHZpZXcgdGhlIGRyYWZ0IGlzIG1vcmUNCm9yIGxlc3MgZG9uZSwgYW5kIEkgZG8gbm90IHNlZSBt dWNoIHdvcmsgbmVlZGVkIGZyb20gdGhlIHRscyB3Zy4NCg0KKEFzIGEgbm90ZSwgdGhpcyBkcmFm dCB3b3VsZCBub3QgaGF2ZSBiZWVuIG5lZWRlZCB3aXRoIGFuIGEgbGEgY2FydGUNCnN5c3RlbSku IA0KDQpDaGVlcnMsDQpKb2huDQoNCg0KT24gMjUvMDcvMTUgMTA6MzYsICJpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQp3cm90ZToNCg0KPg0KPkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXR0c3Nvbi10bHMtZWNkaGUtcHNrLWFlYWQtMDIu dHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIE1hdHRzc29uIGFu ZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1tYXR0 c3Nvbi10bHMtZWNkaGUtcHNrLWFlYWQNCj5SZXZpc2lvbjoJMDINCj5UaXRsZToJCUVDREhFX1BT SyB3aXRoIEFFUy1HQ00gYW5kIEFFUy1DQ00gQ2lwaGVyIFN1aXRlcyBmb3IgVHJhbnNwb3J0DQo+ TGF5ZXIgU2VjdXJpdHkgKFRMUykNCj5Eb2N1bWVudCBkYXRlOgkyMDE1LTA3LTI0DQo+R3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTYNCj5VUkw6ICAgICAgICAgICAgDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hdHRzc29uLXRscy1l Y2RoZS1wc2stYWVhZC0wMi4NCj50eHQNCj5TdGF0dXM6ICAgICAgICAgDQo+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWF0dHNzb24tdGxzLWVjZGhlLXBzay1hZWFkLw0K Pkh0bWxpemVkOiAgICAgICANCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0 dHNzb24tdGxzLWVjZGhlLXBzay1hZWFkLTAyDQo+RGlmZjogICAgICAgICAgIA0KPmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tYXR0c3Nvbi10bHMtZWNkaGUtcHNrLWFl YWQtMDINCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIG1lbW8gZGVmaW5lcyBzZXZlcmFsIG5ldyBj aXBoZXIgc3VpdGVzIGZvciB0aGUgVHJhbnNwb3J0IExheWVyDQo+ICAgU2VjdXJpdHkgKFRMUykg cHJvdG9jb2wuICBUaGUgY2lwaGVyIHN1aXRlcyBhcmUgYWxsIGJhc2VkIG9uIHRoZQ0KPiAgIEVw aGVtZXJhbCBFbGxpcHRpYyBDdXJ2ZSBEaWZmaWUtSGVsbG1hbiB3aXRoIFByZS1TaGFyZWQgS2V5 DQo+ICAgKEVDREhFX1BTSykga2V5IGV4Y2hhbmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1dGhlbnRp Y2F0ZWQgRW5jcnlwdGlvbg0KPiAgIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdvcml0 aG1zIEFFUy1HQ00gYW5kIEFFUy1DQ00uICBQU0sNCj4gICBwcm92aWRlcyBsaWdodCBhbmQgZWZm aWNpZW50IGF1dGhlbnRpY2F0aW9uLCBFQ0RIRSBwcm92aWRlcyBwZXJmZWN0DQo+ICAgZm9yd2Fy ZCBzZWNyZWN5LCBhbmQgQUVTLUdDTSBhbmQgQUVTLUNDTSBwcm92aWRlcyBlbmNyeXB0aW9uIGFu ZA0KPiAgIGludGVncml0eSBwcm90ZWN0aW9uLg0KPg0KPiAgICAgICAgICAgICAgICAgIA0KPiAg ICAgICAgDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5U aGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Sat Jul 25 06:08:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90951B2DE9 for ; Sat, 25 Jul 2015 06:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3Hn9yb0aGP5F for ; Sat, 25 Jul 2015 06:08:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2DF1B2E0F for ; Sat, 25 Jul 2015 06:08:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6B1B8BE88 for ; Sat, 25 Jul 2015 14:08:28 +0100 (IST) 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 KsRm17pJHCqd for ; Sat, 25 Jul 2015 14:08:27 +0100 (IST) Received: from [10.17.4.205] (unknown [193.86.243.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 13813BE58 for ; Sat, 25 Jul 2015 14:08:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437829707; bh=RYKREjfb/wAUx11PGooaeUPnZcBVeNQbnONeWrtvS7I=; h=Date:From:To:Subject:References:In-Reply-To:From; b=wuDnh71Rx0WJhi0R6pMu7ltGnqPNPi17aXztBNaT+Rke6Blg/LYdK7ItMF3+W1+3K ZC99kvXQo+7o/MXN+UsAwkLr3Xn5g/Yr7S+WqpSkYS/dUJioZHO/FzDswOOtlYHPl4 YcMYgPut49ZZmEDv9Kt1+u/c3yNOm3aCEjgGS8Ho= Message-ID: <55B38A47.2010002@cs.tcd.ie> Date: Sat, 25 Jul 2015 14:08:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: tls@ietf.org References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> In-Reply-To: <20150725054622.GK4347@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 13:08:31 -0000 (no hats and al that) On 25/07/15 06:46, Viktor Dukhovni wrote: > I hope, that by ~2017, RC4 will no longer be required either, and > we'll be able to disable RC4 in Postfix at that time. Seems to me that should be a reasonable match for expecting to see TLS1.3 getting deployed in lots of parts of the mail infrastructure, so that date would argue to not support rc4 at all in TLS1.3 in my conclusion (not that I know much about mail deployment trends). And if we have any support for rc4 in TLS1.3 it'll end up a footgun that'll damage many toes, so count me amongst those arguing for no rc4 (or similar) at all in TLS1.3. Cheers, S. From nobody Sat Jul 25 06:41:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140501A854D for ; Sat, 25 Jul 2015 06:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, 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 SNWSNewBb82m for ; Sat, 25 Jul 2015 06:41:28 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CC41A7001 for ; Sat, 25 Jul 2015 06:41:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,542,1432591200"; d="scan'208";a="171607242" Received: from 131.106.31.93.rev.sfr.net (HELO [192.168.1.76]) ([93.31.106.131]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2015 15:41:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Benjamin Beurdouche In-Reply-To: <55B38A47.2010002@cs.tcd.ie> Date: Sat, 25 Jul 2015 15:41:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> <55B38A47.2010002@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 13:41:30 -0000 > On 25/07/15 06:46, Viktor Dukhovni wrote: >> I hope, that by ~2017, RC4 will no longer be required either, and >> we'll be able to disable RC4 in Postfix at that time. >=20 > Seems to me that should be a reasonable match for expecting to see > TLS1.3 getting deployed in lots of parts of the mail infrastructure, > so that date would argue to not support rc4 at all in TLS1.3 in my > conclusion (not that I know much about mail deployment trends). >=20 > And if we have any support for rc4 in TLS1.3 it'll end up a footgun > that'll damage many toes, so count me amongst those arguing for no > rc4 (or similar) at all in TLS1.3. +1, though, my understanding was that RC4 was already out of TLS 1.3.. In general I think we could all agree that we should never keep broken = stuff in TLS even if it is used a lot=E2=80=A6 Best, B. From nobody Sat Jul 25 07:14:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586BA1B312B for ; Sat, 25 Jul 2015 07:14:23 -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 QgE6gS3RI-Ji for ; Sat, 25 Jul 2015 07:14:21 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0931B312A for ; Sat, 25 Jul 2015 07:14:21 -0700 (PDT) Received: by wibud3 with SMTP id ud3so64379670wib.0 for ; Sat, 25 Jul 2015 07:14:20 -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=ceOkR9yFnwr09S6wSZIpSIkEcmThzGcInLzadp5VZVQ=; b=hikCl35gi2lPSacGtqjZHhiz2f7tdvF0BRQBqx0x9/a5wPADEpjYOMWko3vczGX4zc A1MUqrephIrsPZ6HtCZ6u6TnU/WajawIFAbAlaKc/h5sUpM/Cz2MhyZlZ9nrDCfh+Sos QSQVasyJWqIGx6Jg8DYhBrXjpRE48AXh8MNejyotpNR57VazPDzfebpGZNyy080PYH2N lGfYBgCJzLVgSYqPHdN/M6QMD35oo3hW/P06xtWAa97E+k+SF3evOgCl1q2vhaJ384wA crWSsRACrYQ3KIObK+hfzQY8GNpXY+zXKD/F2j+9k1CwW3nPx1Doncg/67C97UoWu0DG 5fEw== X-Gm-Message-State: ALoCoQl/YRkDUK3tjb5UUvybhfb3Rdvb9NP+SMxMFYEiYRN3YOtrEfAUvQDwK8/OVZih1/Tjind2 X-Received: by 10.194.79.225 with SMTP id m1mr37243728wjx.8.1437833660188; Sat, 25 Jul 2015 07:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.10.30 with HTTP; Sat, 25 Jul 2015 07:13:39 -0700 (PDT) In-Reply-To: References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> <55B38A47.2010002@cs.tcd.ie> From: Eric Rescorla Date: Sat, 25 Jul 2015 16:13:39 +0200 Message-ID: To: Benjamin Beurdouche Content-Type: multipart/alternative; boundary=047d7b10c9038ffb15051bb3bc7c Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 14:14:23 -0000 --047d7b10c9038ffb15051bb3bc7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be clear: TLS 1.3 does not support RC4. The only question is whether it's legal to concurrently offer RC4 with TLS 1.3 for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC even though TLS 1.3 does not support it.) I am trying to work through this myself, as the interactions with browser fallback are very complex. -Ekr On Sat, Jul 25, 2015 at 3:41 PM, Benjamin Beurdouche < benjamin.beurdouche@inria.fr> wrote: > > > On 25/07/15 06:46, Viktor Dukhovni wrote: > >> I hope, that by ~2017, RC4 will no longer be required either, and > >> we'll be able to disable RC4 in Postfix at that time. > > > > Seems to me that should be a reasonable match for expecting to see > > TLS1.3 getting deployed in lots of parts of the mail infrastructure, > > so that date would argue to not support rc4 at all in TLS1.3 in my > > conclusion (not that I know much about mail deployment trends). > > > > And if we have any support for rc4 in TLS1.3 it'll end up a footgun > > that'll damage many toes, so count me amongst those arguing for no > > rc4 (or similar) at all in TLS1.3. > > +1, though, my understanding was that RC4 was already out of TLS 1.3.. > In general I think we could all agree that we should never keep broken > stuff in TLS even if it is used a lot=E2=80=A6 > > Best, > B. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b10c9038ffb15051bb3bc7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To be clear: TLS 1.3 does not support RC4.

<= div>The only question is whether it's legal to concurrently offer RC4 w= ith TLS 1.3
for purposes of using RC4 with TLS 1.2 (just as you c= an offer AES-CBC
even though TLS 1.3 does not support it.) I am t= rying to work through this
myself, as the interactions with brows= er fallback are very complex.

-Ekr

<= /div>



On Sat, Jul 25, 2015 at 3:41 PM, Benjamin Beurdouch= e <benjamin.beurdouche@inria.fr> wrote:

> On 25/07/15 06:46, Viktor Dukhovni wrote:
>> I hope, that by ~2017, RC4 will no longer be required either, and<= br> >> we'll be able to disable RC4 in Postfix at that time.
>
> Seems to me that should be a reasonable match for expecting to see
> TLS1.3 getting deployed in lots of parts of the mail infrastructure, > so that date would argue to not support rc4 at all in TLS1.3 in my
> conclusion (not that I know much about mail deployment trends).
>
> And if we have any support for rc4 in TLS1.3 it'll end up a footgu= n
> that'll damage many toes, so count me amongst those arguing for no=
> rc4 (or similar) at all in TLS1.3.

+1, though, my understanding was that RC4 was already out of TLS 1.3= ..
In general I think we could all agree that we should never keep broken stuf= f in TLS even if it is used a lot=E2=80=A6

Best,
B.


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

--047d7b10c9038ffb15051bb3bc7c-- From nobody Sat Jul 25 07:59:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB31A1B03 for ; Sat, 25 Jul 2015 07:59:56 -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 QKOYwbhp9zF2 for ; Sat, 25 Jul 2015 07:59:55 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A721A1A58 for ; Sat, 25 Jul 2015 07:59:54 -0700 (PDT) Received: by ykdu72 with SMTP id u72so40035056ykd.2 for ; Sat, 25 Jul 2015 07:59:54 -0700 (PDT) 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=n+B569AIH8EQO3U5MSv1udN+f0TBxPZ/qdDqZINB9+E=; b=aVUheP7Lm+HDnlF7PfHSJ94+TCPl58H7RvxfJwNz8iGAaPHiFB4GUcLxs+wO7AV2EK QWScqSGN5bO3Z0N1FYAnHvGI++C/F7HiucqmbShFzyWTWk4JDHxNMvxQNeyfT1629v7J NH43xv9PqJex/wgvm1JxnQkc5YZRKlW1i4PUiHaNWsXqSg9+dOyuksQpmhsPsNZARFuW tP9eFPzWLKxBehzvzOVWNz4LUphO/wnziFE9pEQox0xzAAzKaEM17FbS/uuNiB+AwdlJ y+ArBs0uiDgIVjCKT++vzCRh5z/buS27Cggo5Mcu+nEZH7sSqocdquRgaa7hY3O9piJU GFqw== MIME-Version: 1.0 X-Received: by 10.13.225.11 with SMTP id k11mr6998840ywe.148.1437836394307; Sat, 25 Jul 2015 07:59:54 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Sat, 25 Jul 2015 07:59:54 -0700 (PDT) Date: Sat, 25 Jul 2015 16:59:54 +0200 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Review of PR #209 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 14:59:56 -0000 Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209 The first expands the ways in which a server can identify certificates. This is fine. I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately). The second is worrisome. I don't like that a handshake message now has two different potential locations that it might appear in. That seems like a hazard. I think that we need a new content type for a new message that can be used after the handshake completes. Then there are two options: a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses) b) use CertificateRequest within the handshake, and the new content type outside of it From nobody Sat Jul 25 08:02:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E391A1BF2 for ; Sat, 25 Jul 2015 08:02:21 -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 CUJRxPs0KwdP for ; Sat, 25 Jul 2015 08:02:20 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90A31A038F for ; Sat, 25 Jul 2015 08:02:19 -0700 (PDT) Received: by ykay190 with SMTP id y190so39954093yka.3 for ; Sat, 25 Jul 2015 08:02:19 -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=ayvwRxT+rddwnsihSVTQwGNcy6G0+fbeHHIR6z+lOrs=; b=hxcu9GYpenA731DxeiSvCHYRmerJmRzzfl6KIOKbupCUT5DIHbWManD62+v2K2yZKA Nx1WjfRjLGps3hrjcqrYslngnoeed7X7dTkakwn7LcW3xY8DG19hXuHWfW5JdTM63mH1 B4DQRnCbForwFiK+0xiT8lbOpZsSJKyFKaK0+ea+3MJ28LlZ6qVxSFSD5yrg+O8WlWqQ xqunL9buGsHGfTAkpvIDEvyUraw1QzYAigomP7TLalGp3+8Im/LDSfUuKDEef5ZFBDBq hcmRVb1mtQLdTnT/rGJhtoXw7UeGoDchs3hZLC1xhEfgi+JLXrGrxk6yx17j8zWTkGjn y2JA== MIME-Version: 1.0 X-Received: by 10.129.97.87 with SMTP id v84mr21026018ywb.56.1437836539324; Sat, 25 Jul 2015 08:02:19 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Sat, 25 Jul 2015 08:02:19 -0700 (PDT) In-Reply-To: References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> <55B38A47.2010002@cs.tcd.ie> Date: Sat, 25 Jul 2015 17:02:19 +0200 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 15:02:21 -0000 On 25 July 2015 at 16:13, Eric Rescorla wrote: > The only question is whether it's legal to concurrently offer RC4 with TLS > 1.3 > for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC > even though TLS 1.3 does not support it.) I am trying to work through this > myself, as the interactions with browser fallback are very complex. And the strategies vary. It might be that we don't need to worry about this, because we might have widely disabled RC4 by the time TLS 1.3 ships. https://ipv.sx/telemetry/rc4.html From nobody Sat Jul 25 08:48:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEE21A9043 for ; Sat, 25 Jul 2015 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 iOnxk2MZs5_Q for ; Sat, 25 Jul 2015 08:48:39 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 60AB21A8F49 for ; Sat, 25 Jul 2015 08:48:39 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C294A74000C; Sat, 25 Jul 2015 15:48:38 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id AB87674000B; Sat, 25 Jul 2015 15:48:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437839318; bh=k6lbOjY4BQKrpczOt49zvozd1bnZ7dVW24GeAWTSioQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=i+pFUe/D0ITjMe2vBLqhzZLJ5Of79UfS8Zp7iQppiGl+UCbdvq1Po52uHbzrXDXIa r146KqI94ehXy2HtiJNpBFl0z7MqqwWvpf7gxwYEJMa64q1ssnuwgR5FC4qM6Mx6Jy 9klNlM92luDcEbYViJ7J6ArayEgGz3X6dmhz17F0= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A58241E10C; Sat, 25 Jul 2015 15:48:38 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 25 Jul 2015 10:48:38 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Sat, 25 Jul 2015 10:48:38 -0500 From: "Salz, Rich" To: Martin Thomson , Eric Rescorla Thread-Topic: [TLS] ban more old crap Thread-Index: AQHQxWn1V9PLNbSSek+n2xTWp60PmZ3pnfIAgAATxICAARJggIAAaJ0AgAAF3YCAAAxxgIAAxHUAgAB7gICAAAk5AIAACQOAgAANmYD//7iY8A== Date: Sat, 25 Jul 2015 15:48:37 +0000 Message-ID: <1fd27bd0bb81466ab5fb134acd8b07f4@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> <55B38A47.2010002@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 15:48:41 -0000 > And the strategies vary. It might be that we don't need to worry about t= his, > because we might have widely disabled RC4 by the time TLS > 1.3 ships. "we" meaning browsers. "we" not being everyone who will use TLS 1.3 Ekr has pointed out a problem; if you connect with a protocol range and pro= ffer RC4, can we do anything about it except point out multiple times that = 1.3 servers MUST NOT accept it? From nobody Sat Jul 25 10:01:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455F31A886C for ; Sat, 25 Jul 2015 10:01:44 -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 LKme3_HQUPUL for ; Sat, 25 Jul 2015 10:01:43 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0349D1A7D83 for ; Sat, 25 Jul 2015 10:01:43 -0700 (PDT) Received: by ykdu72 with SMTP id u72so41378736ykd.2 for ; Sat, 25 Jul 2015 10:01:42 -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=/9PpO5UBdUHEgbgy7ByM1hHV0w0j5b+2BolT9eRG2SI=; b=ZfcXUFpX46T5PKLGE56Abd7d4Zdmf9LxViLaVioxx96m+jZ31E2V7j2eVNk8c5ctNi I/vs1ez+FNagerw242aZgFC7C1nWaD078JdEA0c6d3yhSzcK1ePYnzwa/qdu7cUAQ0H4 jr0Ku1tnRczCfdgrnV5q9ynlUz+JxHzkmnFhpv8iGoZQZVBltrM7eAcdAnFwOj7MuNOu J9k35XUAiwIKkq9+n6rPREhOWsGUvx5a4vK0Gy92FBg7addrEW6o7ge5qEj761q0LqAV drP6hm9tFK/MRPD5IBw7px26Pl4LNLrb6uh/IPj/Du6TKiNnCFUGwKCKVDMN9nGFbIs8 5XzQ== MIME-Version: 1.0 X-Received: by 10.170.86.132 with SMTP id d126mr21623071yka.57.1437843702365; Sat, 25 Jul 2015 10:01:42 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Sat, 25 Jul 2015 10:01:42 -0700 (PDT) In-Reply-To: <1fd27bd0bb81466ab5fb134acd8b07f4@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> <55B38A47.2010002@cs.tcd.ie> <1fd27bd0bb81466ab5fb134acd8b07f4@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Sat, 25 Jul 2015 19:01:42 +0200 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 17:01:44 -0000 On 25 July 2015 at 17:48, Salz, Rich wrote: > "we" meaning browsers. "we" not being everyone who will use TLS 1.3 > > Ekr has pointed out a problem; if you connect with a protocol range and proffer RC4, can we do anything about it except point out multiple times that 1.3 servers MUST NOT accept it? Agreed. But I'll point out that other users of TLS will likely not be doing fallback either, so they have to deal with offering what they support straight up. Prohibiting RC4 probably won't do anything more than what our existing efforts are doing already. From nobody Sat Jul 25 10:13:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726E41ACED3 for ; Sat, 25 Jul 2015 10:13:31 -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 VAPCYgJai-bB for ; Sat, 25 Jul 2015 10:13:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BC51ACE8A for ; Sat, 25 Jul 2015 10:13:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6820C284B64; Sat, 25 Jul 2015 17:13:28 +0000 (UTC) Date: Sat, 25 Jul 2015 17:13:28 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150725171328.GL4347@mournblade.imrryr.org> References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] ban more old crap 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: Sat, 25 Jul 2015 17:13:31 -0000 On Sat, Jul 25, 2015 at 06:54:36AM +0000, Salz, Rich wrote: > > What we've cannot yet turn off is RC4. > > Then do not use TLS 1.3 Actually, we can use TLS 1.3, just not with peers that only do RC4. Provided the 1.3 servers don't do anything actively hostile and terminate the handshake when they see RC4-SHA1 offered among other more acceptable ciphersuites. I was definitely not arguing for inclusion of RC4 in TLS 1.3. I am more than happy with AEAD-only in TLS 1.3, with no RC4. When an opportunistic TLS client that supports TLS 1.0--1.3, and includes RC4 in its list of ciphersuites, connects to a 1.3 server RC4 will not be the negotiated ciphersuite when the server decides to use 1.3. I was just noting for the record, that even with opportunistic TLS we've already made some progress in getting rid of "old crap", but not yet all. -- Viktor. From nobody Sat Jul 25 10:18:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070721A1C00 for ; Sat, 25 Jul 2015 10:18:52 -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 CTiUCp-wFDkz for ; Sat, 25 Jul 2015 10:18:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A701A1A4E for ; Sat, 25 Jul 2015 10:18:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E7CE8284B64; Sat, 25 Jul 2015 17:18:49 +0000 (UTC) Date: Sat, 25 Jul 2015 17:18:49 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150725171849.GM4347@mournblade.imrryr.org> References: <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com> <201507241403.14071.davemgarrett@gmail.com> <20150725054622.GK4347@mournblade.imrryr.org> <55B38A47.2010002@cs.tcd.ie> <1fd27bd0bb81466ab5fb134acd8b07f4@ustx2ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] ban more old crap 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: Sat, 25 Jul 2015 17:18:52 -0000 On Sat, Jul 25, 2015 at 07:01:42PM +0200, Martin Thomson wrote: > On 25 July 2015 at 17:48, Salz, Rich wrote: > > "we" meaning browsers. "we" not being everyone who will use TLS 1.3 > > > > Ekr has pointed out a problem; if you connect with a protocol range and proffer RC4, can we do anything about it except point out multiple times that 1.3 servers MUST NOT accept it? > > > Agreed. But I'll point out that other users of TLS will likely not be > doing fallback either, so they have to deal with offering what they > support straight up. > > Prohibiting RC4 probably won't do anything more than what our existing > efforts are doing already. I would go further, and say that "prohibiting RC4" in any sense that is more than prohibiting its use as the final outcome of a handshake would be a rather counter-productive strategy. Servers and clients are strongly encouraged to not choose it, but to reject connections from peers that offer it for interoperability with others would just create a mess that would be operationally challenging. RC4 is dying, just let it fade away into insignificance. -- Viktor. From nobody Sat Jul 25 11:53:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58EF1A8956 for ; Sat, 25 Jul 2015 11:53:22 -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 nPbNEDu2oSAI for ; Sat, 25 Jul 2015 11:53:20 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990451A8944 for ; Sat, 25 Jul 2015 11:53:20 -0700 (PDT) Received: by qkdv3 with SMTP id v3so27777090qkd.3 for ; Sat, 25 Jul 2015 11:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=rPFkkVbBYC0Ix142cqR1UB35JCyBqJBMKRlZo4TYbhA=; b=L2QDcozWfMlm1ShJVjHaaFIoYGtx4eNUT/MjmJYQlyLuEZuN6ruLe7ZyiYW8kIwsYC Bf48haWC9LPU2JawIGjdN94B9SZxIfHba3xqCDEXMR8hOW5vSNk5MZ0HpnXmmWFhPk/I KdD+QeRsVo8B/3QMf9fLfP/EHnKD5L0MpNtzVQP+4F6lBMqRecVO/9w6G2Y7DdPM2Al5 97z4vIFDs40EmlS5SAFonRHAbqbWOGNKIshcIHInE3kcf2fIhnLMbmopOD5ov49vQ9jX ZCLRljlBnEpnBXEuuRclDxz9pUyrOmyd1/BZAH67smewLJFJpWztwDorrvGLaZLwc6kX JVmg== X-Received: by 10.55.19.40 with SMTP id d40mr29107333qkh.15.1437850399917; Sat, 25 Jul 2015 11:53:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id o65sm6064979qge.34.2015.07.25.11.53.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 25 Jul 2015 11:53:19 -0700 (PDT) From: Dave Garrett To: "tls@ietf.org" , Eric Rescorla Date: Sat, 25 Jul 2015 14:53:17 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <201507251453.18237.davemgarrett@gmail.com> Archived-At: Subject: [TLS] 0-RTT & 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: Sat, 25 Jul 2015 18:53:22 -0000 I'm pretty sure some/all of this was likely mentioned elsewhere, but I don'= t see any discussion on-list. (it was mentioned in part of the IETF 93 reco= rding I watched as this whole topic needing to go to the list, as well) The= re's also related TODOs in the draft on this topic. Here's a start to this = discussion. Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT c= onnections using the known configuration extension & PSK-based session resu= mption. I don't think their roles are well defined yet. 1) There is no 0-RTT resumption. The point of resumption is to get back int= o the session quick, but it's arguably slower than not doing it, currently. 0-RTT can do first flight (repeatable) requests: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.3 but PSK-based resumption needs 1-RTT: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 2) There's not yet specifics on what cipher suite to use for PSK-based resu= mption. I don't see a point in doing PSK-based resumption with anything oth= er than plain PSK, with no PFS (no (EC)DHE). If you're willing to do the ex= tra work for DH, just go straight to normal 0-RTT to get more benefit/flexi= bility with a similar amount of work. The goal is really to get forward sec= recy on the session, not necessarily every single connection within it. (no= t that it wouldn't be nice) As long as the resumption is within a reasonabl= y short window (e.g. few minutes), not doing another DH is fine. After this= window, normal 0-RTT should be the preferred route. 3) Just to state the obvious: If a client is going to do PSK resumption wit= h a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not real= ly going to be negotiated for anything else, I don't really like the feel o= f this. I think it'd also be cleaner if the offered suites didn't have to c= hange for resumption. One idea would be to rename the groups extension, aga= in, to "supported_key_shares" and mark point 0 (or some other if we want to= leave 0) as PSK-resumption, specifically. (_not_ general PSK) A resumption= PSK offer could then be listed in the ClientKeyShare like any other, and n= egotiation of it could side-step the need to pick a new cipher. Mixing it i= n with regular PSK complicates things a bit and has an expectation of needi= ng to offer a PSK suite with the PSK extension. In this case, it'd just be = the previously used suite. 0-RTT becomes a little more straightforward: giv= e both short-term resumption via PSK and mid-term semi-static secret 0-RTT = clear expiration dates, then the first flight data is just encrypted using = whatever is still valid. Worst case scenario is the server ditched the sess= ion early and it falls back to 1-RTT. (double-encrypting early data might w= ork, but would be ugly) This sort of re-separates PSK & resumption a little= bit, though the handling is still similar. 4) Related issue: maybe define a generic KeyShare struct (group+key_exchang= e), simplify the few spots to use these, then allow ServerConfiguration to = offer a vector of KeyShares? Alternatively, just have one KeyShare in there= and offer a vector of ServerConfiguration in the message so each has an ex= piration date. If we want the possibility of ServerConfiguration being obta= inable through alternate means, then it might help for a server to be able = to offer two keys with different curves to make support easier to offer. (e= =2Eg. P-256 & Curve25519, as we may be transitioning this way for a bit; co= uld be ECC & PQ of some kind, in the future) This might make constructing a= 0-RTT first-connect system a little easier. Not a solid proposal, really; just some discussion on the topic. Dave From nobody Sat Jul 25 12:01:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CC91A00D4 for ; Sat, 25 Jul 2015 12:01:02 -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 h7uMGpK_Cw2g for ; Sat, 25 Jul 2015 12:01:01 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC911AC432 for ; Sat, 25 Jul 2015 12:00:56 -0700 (PDT) Received: by qkbm65 with SMTP id m65so27798186qkb.2 for ; Sat, 25 Jul 2015 12:00:56 -0700 (PDT) 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=8v9R5CGXkEbTHLW4CwCVHCzJg2RQzU3D5Jbl42vrSHo=; b=Pej7pqifGcXSOJHeJOTecaHiA/DcUzkBsgVrkODeR6eS98nuUQAoubWowhy5ZmCyK4 aIjujSdPFg76ttI+JLGU1J6M1JwpVEJt1PGTGBU/r0QPNXyQQMNsSrbExeW2nkXg2Eyv A2I5EIgGWNK9D5ZTqiWAydoABEIVBqPjXqD/MvYkX+rtfe4NXkRvtsSeq6Lr0VVzZl/k +KK5OHysDEA+fVL7SnnRchtctK0VuBaKImex34W3WNF0s0Lxx27/fcGdcNbvGT1qA4HG ZOGM0n3I/FK3uCnghKjZfVVCxyquIlWFlNhgARsCtsyc8jiFXR4eHvAC7N1eWT21Sl3f cDWg== X-Received: by 10.55.15.23 with SMTP id z23mr28963653qkg.47.1437850855996; Sat, 25 Jul 2015 12:00:55 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id c100sm6087165qkh.15.2015.07.25.12.00.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 25 Jul 2015 12:00:55 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Viktor Dukhovni Date: Sat, 25 Jul 2015 15:00:54 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201507241257.43115.davemgarrett@gmail.com> <20150725171849.GM4347@mournblade.imrryr.org> In-Reply-To: <20150725171849.GM4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201507251500.54604.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] ban more old crap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2015 19:01:03 -0000 On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote: > I would go further, and say that "prohibiting RC4" in any sense > that is more than prohibiting its use as the final outcome of a > handshake would be a rather counter-productive strategy. > > Servers and clients are strongly encouraged to not choose it, but > to reject connections from peers that offer it for interoperability > with others would just create a mess that would be operationally > challenging. RC4 is dying, just let it fade away into insignificance. I agree. The current draft language of not offering or negotiating RC4 is fine, as-is. My proposal of stopping tolerance of garbage suite offers is just for <112-bit junk. Dave From nobody Sat Jul 25 12:07:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D91ACC92 for ; Sat, 25 Jul 2015 12:07:35 -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 sxreYRLo6-PC for ; Sat, 25 Jul 2015 12:07:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF041ACD0A for ; Sat, 25 Jul 2015 12:07:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D9778284B64; Sat, 25 Jul 2015 19:07:32 +0000 (UTC) Date: Sat, 25 Jul 2015 19:07:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150725190732.GO4347@mournblade.imrryr.org> References: <201507251453.18237.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507251453.18237.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] 0-RTT & resumption 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: Sat, 25 Jul 2015 19:07:35 -0000 On Sat, Jul 25, 2015 at 02:53:17PM -0400, Dave Garrett wrote: > 3) Just to state the obvious: If a client is going to do PSK resumption > with a non-PFS suite, it needs to offer a non-PFS suite. Forward-secrecy is not about doing or not doing DHE/ECDHE those are just means to an end. Forward-secrecy is about retaining confidentiality of past traffic even when long-term secrets (for TLS server private keys) are later disclosed. With that in mind, resumption without DHE/ECDHE has the same forward-secrecy as the original session. The session master secret is not a "long-term" secret. > Even if it's not > really going to be negotiated for anything else, I don't really like the > feel of this. I think it'd also be cleaner if the offered suites didn't > have to change for resumption. Perhaps I am missing something, but I see no reason for the offered ciphersuites to change. -- Viktor. From nobody Sat Jul 25 12:08:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5341A903A for ; Sat, 25 Jul 2015 12:08:32 -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 yq-Dcxr7mvuH for ; Sat, 25 Jul 2015 12:08:30 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D658A1A1A3B for ; Sat, 25 Jul 2015 12:08:29 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so64340304wic.1 for ; Sat, 25 Jul 2015 12:08:28 -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=7Mjx4i9V83q49zQofB2fACVk0mecW50auiSKOgncITg=; b=meWl9BuMRTB/t7XJaWzJrmr+/FXNRQUO8go9uVcQ5olbHzPpMtlYfGs8ffI+9eYcqe fNFwTah0LXJ/Zjo6WIguR8rSvJ+DZ4Cj2XPi/kOCSk4nFj8bPsSYMsW5TqAhlRLW49hq jk2gBId46GOp/AZ7K7yP2r+sWO/px+EUn3eoOwCsb4bmnCIffNtYCLVyzhXl8wSsgM3W rrEfVJxxq83j9CPt4j5f2OAV+Qt663KCMeAV9qmkWRXkDMyxWHOFqibdXmpQEf2N7mfE iefCOHTKxtqwoHq0ryJAQFReKWUYNgM+GP80ITDSrUOqUOXMMBPnI1QYoGbAihfNEt7t gIyg== X-Gm-Message-State: ALoCoQmN4uIo8nlSIBlPS7ZJhV94vVse2E/iNAwBe7LqAigJcIyn2mzG+Qy7RuA4rGd5QSMe8l2e X-Received: by 10.180.73.244 with SMTP id o20mr8641249wiv.31.1437851308624; Sat, 25 Jul 2015 12:08:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Sat, 25 Jul 2015 12:07:49 -0700 (PDT) In-Reply-To: <201507251453.18237.davemgarrett@gmail.com> References: <201507251453.18237.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 25 Jul 2015 21:07:49 +0200 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d0435c06a7da583051bb7d864 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT & 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: Sat, 25 Jul 2015 19:08:32 -0000 --f46d0435c06a7da583051bb7d864 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 25, 2015 at 8:53 PM, Dave Garrett wrote: > I'm pretty sure some/all of this was likely mentioned elsewhere, but I > don't see any discussion on-list. (it was mentioned in part of the IETF 93 > recording I watched as this whole topic needing to go to the list, as well) > There's also related TODOs in the draft on this topic. Here's a start to > this discussion. > > Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT > connections using the known configuration extension & PSK-based session > resumption. I don't think their roles are well defined yet. > > 1) There is no 0-RTT resumption. The point of resumption is to get back > into the session quick, but it's arguably slower than not doing it, > currently. > > 0-RTT can do first flight (repeatable) requests: > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.3 > but PSK-based resumption needs 1-RTT: > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 We agreed on how to do this in Prague. The sticking point was establishing the cipher suite. I have WIP text on my machine for both of these which I will be sending early next week, once I get enough sleep to be able to clean it up, so I'd ask people to sit tight till then. 2) There's not yet specifics on what cipher suite to use for PSK-based > resumption. The consensus in Prague was that you should have to use a matching symmetric cipher suite. I don't see a point in doing PSK-based resumption with anything other than > plain PSK, with no PFS (no (EC)DHE). If you're willing to do the extra work > for DH, just go straight to normal 0-RTT to get more benefit/flexibility > with a similar amount of work. The goal is really to get forward secrecy on > the session, not necessarily every single connection within it. (not that > it wouldn't be nice) As long as the resumption is within a reasonably short > window (e.g. few minutes), not doing another DH is fine. After this window, > normal 0-RTT should be the preferred route. > I don't think this is correct. The reason is that resumption also resumes the client's authentication state, and client authentication often involves user interaction, which is undesirable from the site's perspective. So, it's actually quite attractive to do resumption with (EC)DHE. It's also significantly faster if you have an RSA certificate. > 3) Just to state the obvious: If a client is going to do PSK resumption > with a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not > really going to be negotiated for anything else, I don't really like the > feel of this. I think it'd also be cleaner if the offered suites didn't > have to change for resumption. One idea would be to rename the groups > extension, again, to "supported_key_shares" and mark point 0 (or some other > if we want to leave 0) as PSK-resumption, specifically. Yeah, we discussed this internally, but I think it's clumsy. I'd rather just offer two separate cipher suites. -Ekr --f46d0435c06a7da583051bb7d864 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 25, 2015 at 8:53 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
I'm pretty= sure some/all of this was likely mentioned elsewhere, but I don't see = any discussion on-list. (it was mentioned in part of the IETF 93 recording = I watched as this whole topic needing to go to the list, as well) There'= ;s also related TODOs in the draft on this topic. Here's a start to thi= s discussion.

Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-R= TT connections using the known configuration extension & PSK-based sess= ion resumption. I don't think their roles are well defined yet.

1) There is no 0-RTT resumption. The point of resumption is to get back int= o the session quick, but it's arguably slower than not doing it, curren= tly.

0-RTT can do first flight (repeatable) requests:
https://tools.ietf.org/html/draft-i= etf-tls-tls13-07#section-6.2.3
but PSK-based resumption needs 1-RTT:
https://tools.ietf.org/html/draft-i= etf-tls-tls13-07#section-6.2.4


We agreed on how to do this in Prague. The sticking point was establ= ishing
the cipher suite. I have WIP text on my machine for both o= f these which I will be
sending early next week, once I get enoug= h sleep to be able to clean it up,
so I'd ask people to sit t= ight till then.
=C2=A0

2) There's not yet specifics on what cipher suite to use for PSK-based = resumption.

The consensus in Prague was tha= t you should have to use a matching symmetric
cipher suite.
=


I don't s= ee a point in doing PSK-based resumption with anything other than plain PSK= , with no PFS (no (EC)DHE). If you're willing to do the extra work for = DH, just go straight to normal 0-RTT to get more benefit/flexibility with a= similar amount of work. The goal is really to get forward secrecy on the s= ession, not necessarily every single connection within it. (not that it wou= ldn't be nice) As long as the resumption is within a reasonably short w= indow (e.g. few minutes), not doing another DH is fine. After this window, = normal 0-RTT should be the preferred route.

=
I don't think this is correct. The reason is that resumption also = resumes the client's
authentication state, and client authent= ication often involves user interaction, which
is undesirable fro= m the site's perspective. So, it's actually quite attractive to do<= /div>
resumption with (EC)DHE. It's also significantly faster if yo= u have an RSA certificate.

=C2=A0
3) Just to state the obvious: If a client is going to do PSK resumption wit= h a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not = really going to be negotiated for anything else, I don't really like th= e feel of this. I think it'd also be cleaner if the offered suites didn= 't have to change for resumption. One idea would be to rename the group= s extension, again, to "supported_key_shares" and mark point 0 (o= r some other if we want to leave 0) as PSK-resumption, specifically.

Yeah, we discussed this internally, but I think i= t's clumsy. I'd rather just offer two separate
cipher sui= tes.

-Ekr

--f46d0435c06a7da583051bb7d864-- From nobody Sat Jul 25 12:18:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5CC1ACE11 for ; Sat, 25 Jul 2015 12:18:48 -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 msRsfAg4aAjh for ; Sat, 25 Jul 2015 12:18:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBB61ACE03 for ; Sat, 25 Jul 2015 12:18:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C352C284B64; Sat, 25 Jul 2015 19:18:45 +0000 (UTC) Date: Sat, 25 Jul 2015 19:18:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150725191845.GP4347@mournblade.imrryr.org> References: <201507241257.43115.davemgarrett@gmail.com> <20150725171849.GM4347@mournblade.imrryr.org> <201507251500.54604.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507251500.54604.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] ban more old crap 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: Sat, 25 Jul 2015 19:18:48 -0000 On Sat, Jul 25, 2015 at 03:00:54PM -0400, Dave Garrett wrote: > On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote: > > I would go further, and say that "prohibiting RC4" in any sense > > that is more than prohibiting its use as the final outcome of a > > handshake would be a rather counter-productive strategy. > > > > Servers and clients are strongly encouraged to not choose it, but > > to reject connections from peers that offer it for interoperability > > with others would just create a mess that would be operationally > > challenging. RC4 is dying, just let it fade away into insignificance. > > I agree. The current draft language of not offering or negotiating > RC4 is fine, as-is. My proposal of stopping tolerance of garbage > suite offers is just for <112-bit junk. If you mean the export suites plus the non-export single-DES suites (these are only suites that I know to meet the above criterion), and the idea is to refuse client connections when these are offered, that's still rather aggressive. Is that really necessary? The browsers will disable these through software updates, consumers don't configure browser cipher suites. For non-browser applications, a lot of administrators would face mostly unnecessary interoperability issues and would have to reconfigure client systems to disable cipher suites already disabled on the server end. Is the benefit worth the cost. They'll upgrade their systems to ones that don't implement these features in due course without duress. -- Viktor. From nobody Mon Jul 27 07:26:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63691B2E45 for ; Mon, 27 Jul 2015 07:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 hMzlHyHvJB4l for ; Mon, 27 Jul 2015 07:26:18 -0700 (PDT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.100]) (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 544941B2E2E for ; Mon, 27 Jul 2015 07:26:18 -0700 (PDT) Received: by gateway32.websitewelcome.com (Postfix, from userid 500) id 170B59C78876A; Mon, 27 Jul 2015 09:26:16 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 056899C78870A for ; Mon, 27 Jul 2015 09:26:16 -0500 (CDT) Received: from [96.231.221.219] (port=55139 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZJjM7-0000Tq-C1 for tls@ietf.org; Mon, 27 Jul 2015 09:26:15 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2015 10:26:12 -0400 References: To: "" Message-Id: <11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com> 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.221.219 X-Exim-ID: 1ZJjM7-0000Tq-C1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:55139 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] Fwd: Summary of today's discussion on server-side signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2015 14:26:20 -0000 All, I asked ekr to write a brief summary of the server-side signing issue. = The summary provided matches the WG consensus as judged by the chairs. = Please let us know if you object to the way forward by August 3rd. J&S Begin forwarded message: > From: Eric Rescorla > Subject: Summary of today's discussion on server-side signing > Date: July 22, 2015 at 08:52:31 EDT > To: Sean Turner >=20 > Sean, >=20 > Here's a summary of today's discussion on signing and = KnownConfiguration. >=20 > SUMMARY > The WG agreed that the server must sign whenever certificate = authentication > is used (even if the KnownConfiguration is used). >=20 >=20 > BACKGROUND > The current draft requires the server to send a = Certificate/CertificateVerify > whenever either: >=20 > (a) The KnownConfiguration option is not in use. > (b) The server sends a ServerConfiguration >=20 > but it does not need to sign if the KnownConfiguration option is in > use but no new ServerConfiguration is provided. Several people (most > recently Martin Thomson) have suggested that it would be simpler to > just require the server to sign any time certificate-based > authentication is in use. The penalty for this is an extra = sign/verify, > as shown in the following table: >=20 > Scenario Client Server > ------------------------------------------------------------------ > 1-RTT 1 (EC)DHE + Verify 1 (EC)DHE + Sign >=20 > 0-RTT (current, 2 (EC)DHE 2 (EC)DHE > no new config)=20 >=20 > 0-RTT (current, 2 (EC)DHE + Verify 2 (EC)DHE + Sign > new config) >=20 > 0-RTT (proposed) 2 (EC)DHE + Verify 2 (EC)DHE + Sign >=20 >=20 > So, the performance difference here is between line 2 and line 4, > since whenever you provide a new config (line 3) you have to sign > anyway. The benefit is that it makes the server side of the handshake > essentially identical in both 0-RTT and 1-RTT, which is nice from an > implementation and analysis perspective. >=20 >=20 > SUMMARY OF WG DISCUSSION > During the WG discussion today, there was rough consensus to adopt > this change (i.e., always sign). A number of arguments were advanced > in favor of this change. >=20 > (1) It's significantly simpler for implementors and (at least = informal) > analysis. A side benefit is being able to merge the extension > logic for 0-RTT and KnownConfiguration, since KnownConfiguration > is only useful with 0-RTT. > =20 > (2) It extends the properties we were shooting for with online-only > signatures and requiring that the server always sign = ServerConfiguration, > namely continuous proof of access to the signing key. >=20 > (3) The performance cost of an extra ECDSA signature is small and > shrinking fast (per Ian Swett channelling Adam Langley), and > people who care about speed will cut over to ECDSA (certs are > readily available). >=20 > (4) You can still do 0-RTT with PSK resumption, which is = computationally > much faster. >=20 > On balance the WG seemed to feel that these were more compelling than > the performance value of the optimization. >=20 > There was also a recognition that signature amortization was valuable, > but the consensus was that instead of doing this here, it would be > better to adopt Hugo's suggeston from a while back to have a > certificate extension that allowed offline signatures. This allows > both amortization *and* delegation, while not constituting a threat > to existing TLS 1.2 implementations. We agreed that this could be > worked in in parallel but shouldn't hold up TLS 1.3. >=20 > Per WG guidance, I'll be preparing a draft PR for this. >=20 > -Ekr >=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Mon Jul 27 22:52:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F87F1A1B98 for ; Mon, 27 Jul 2015 22:52:35 -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 bXG7Ap46M0LK for ; Mon, 27 Jul 2015 22:52:33 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9521A1B96 for ; Mon, 27 Jul 2015 22:52:33 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so164604747wic.0 for ; Mon, 27 Jul 2015 22:52:32 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=YS/Ir8Ms0bK0krH7Lb49xyulz/lcnnh4vwFecCSH9+o=; b=KuwaAFGzKVH3CmCivaoOf8P9e9YhFBC2vMFgmPzzwr5x+9TEnwgPBevu8N0Vl67/GR EcDjgsm/YH3BvTwQ6GFBaQVyMBrWAkk7O2t0dy03W080h6oMRjDQPIR7ZNikLOWS4dya MHTWuE6IrSFL13pU/hPNOJRx3ZvrW/e8Z4VbybdWUC+vQl8Gop1jb2V9/D2U+jrKHaa3 y5Y4mZxKXoHdyBn5Agmm2wcy8Qd1U6SN7IL5QmcwGu7lOcp7g0Ftzh+dsSZ/q4sRzwJ8 dAHiBKqMbXgn99EwJfNTXucpFMgQ/Y9XXjVUxU3g007Cg7fkYuYq5Q38/seblnLP+Z26 5KXQ== X-Received: by 10.180.90.209 with SMTP id by17mr30790859wib.2.1438062752229; Mon, 27 Jul 2015 22:52:32 -0700 (PDT) Received: from [172.24.249.238] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id uc16sm17159917wib.8.2015.07.27.22.52.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jul 2015 22:52:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Tue, 28 Jul 2015 08:51:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2FC04292-EA91-42B2-AE8D-F647E44FC799@gmail.com> References: To: "tls@ietf.org" X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2015 05:52:35 -0000 > On Jul 22, 2015, at 2:36 PM, Martin Thomson = wrote: >=20 > On 22 July 2015 at 02:29, Yoav Nir wrote: >> PR at = https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.= xml ? >=20 > https://github.com/tlswg/rfc4492bis/pull/6 So the change seems fine to me. Unless anyone objects by Friday the = 31st, I will merge this. If you object, please speak now. Thanks Yoav From nobody Tue Jul 28 08:42:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8F1ACD22 for ; Tue, 28 Jul 2015 08:42:10 -0700 (PDT) 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 yRVancKRTo7W for ; Tue, 28 Jul 2015 08:42:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045541ACD14 for ; Tue, 28 Jul 2015 08:42:08 -0700 (PDT) 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 (Postfix) with ESMTPS id 80398A37FE for ; Tue, 28 Jul 2015 15:42:08 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-197.brq.redhat.com [10.34.0.197]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6SFg7qP007016 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jul 2015 11:42:08 -0400 From: Hubert Kario To: "tls@ietf.org" Date: Tue, 28 Jul 2015 17:41:58 +0200 Message-ID: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-300.fc22.x86_64; KDE/4.14.9; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6545367.A87tjg4WYV"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: [TLS] No cypher overlap (was: ban more old crap) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2015 15:42:10 -0000 --nextPart6545367.A87tjg4WYV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I see one possible problem with TLS1.3 not being a superset of TLS1.2. Consider the following: Server which supports TLSv1.3 but is configured to accept only AES256= =20 ciphers. Client which advertises TLSv1.3, but no support for AES256-GCM. The c= lient=20 advertises also CBC ciphers (both AES128 and AES256) as it wants to be = able to connect to legacy servers too. Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, o= r=20 should it be aborted? I think we should go for continue connection with downgraded protocol, = but=20 explicitly say that it may not happen if the negotiated ciphersuite wou= ld be=20 DES, RC4, export grade... That would allow us to reiterate in the TLS1.3 spec that they are a big= no-no,=20 and that if you claim support for TLS1.3 you should never negotiate the= m with=20 a similarly modern peer. =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart6545367.A87tjg4WYV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVt6LGAAoJEJKo0bgB0vX1FYsP/308kmgfqtGQdxcgIcGvpINM DmFYNFl8Z+VYpM13PrZyKSyod6I7OFvQZk+rjUt92bkENGFS7zztrAuCoqiqxetu oFHf+TAS07IxK/47QsoFoV9U8/2g+F6asRJ1rzuP1/4BSXcWQGVb4W8I1cL67UD8 MVZj25g/A5NTU4mZTARBAehl0JmqP8tkO51AtD+nagSXv1nX3vN96iVDc58/Bypg OeKSy/To8bJIfS9flU3/3c6NRS0Bab6sZJq3WOQxLKAz2GYHD2e9sicKnWt3sJ/K WtChpzV4ZscK+e4O2YNrVBF55MUDB0lkGoEhKiOILUbML/VaCqqVVGXqfXPjpXFi NjVVmQQ/KxqYVrG4z0Ku9nUmZp9l3dtDeM63VHy5Hf+kOvl8KH5htHT1YguCUVm6 4BkSAxcP3NbOTWxPRBLyWFtNizMoSW8Ki7UXjQ3c6sLWPrA8jLKBSlCvce3/MXOf 1lGhRkXS57Q3n/8mto0hVOC9sRAmG5gE40XfUTZepUBrWsP26X+bg3qEDhgRU7aU GZHUYgK3v5bOD4PdYHPXwbmO++m/0706W9/GNzntq3sb5wUGcmh0qJ3zfhmlfrWS BpB3qOEErEJBoD6ea3g7VZwso3KIVp11WL85zZ+N51X+wxb2YeUPkXsIMLwLV++L DVc0PuQZZayXvpYqnQ37 =BdSE -----END PGP SIGNATURE----- --nextPart6545367.A87tjg4WYV-- From nobody Tue Jul 28 09:02:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B301ACD6D for ; Tue, 28 Jul 2015 09:02:01 -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 jWNbmOdNYG8g for ; Tue, 28 Jul 2015 09:01:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BD91ACD60 for ; Tue, 28 Jul 2015 09:01:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9C47D284B64; Tue, 28 Jul 2015 16:01:55 +0000 (UTC) Date: Tue, 28 Jul 2015 16:01:55 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150728160154.GU4347@mournblade.imrryr.org> References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] No cypher overlap (was: ban more old crap) 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: Tue, 28 Jul 2015 16:02:01 -0000 On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote: > I see one possible problem with TLS1.3 not being a superset of TLS1.2. > > Consider the following: > Server which supports TLSv1.3 but is configured to accept only AES256 > ciphers. > > Client which advertises TLSv1.3, but no support for AES256-GCM. The client > advertises also CBC ciphers (both AES128 and AES256) as it wants to be able > to connect to legacy servers too. > > Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or > should it be aborted? We already see a similar dilemma with clients that (artificially) support only SSLv2 ciphersuites, but advertise TLS protocol versions. OpenSSL will first choose a common protocol (TLS 1.x) and then fail to find any shared ciphers. To complete the connection, the client must explicitly request only SSL 2.0. There is at present no filtering out of protocol choices for lack of compatible ciphers. > I think we should go for continue connection with downgraded protocol, but > explicitly say that it may not happen if the negotiated ciphersuite would be > DES, RC4, export grade... In that case, it should be said that a client MUST NOT advertise TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers (or perhaps less restrictive at least one TLS 1.3 compatible cipher). Otherwise, there'll be lots of clients whose TLS libraries advertise 1.3 (just because they implement the protocol), but whose cipher configuration includes only TLS 1.2 (or lower) suites (because the application configuration has not been updated). Punishing those clients by having servers abort the handshake is a bad idea. The right outcome is use of TLS 1.2, whether because client implementations of 1.3 need to check that adequate cipher suites are available, or because servers negotiate 1.2 when 1.3 is impossible. -- Viktor. From nobody Tue Jul 28 15:30:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3EF1B32E8 for ; Tue, 28 Jul 2015 15:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 UxYpBzO3Pttj for ; Tue, 28 Jul 2015 15:30:24 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A611B32DE for ; Tue, 28 Jul 2015 15:30:24 -0700 (PDT) Received: by ioii16 with SMTP id i16so2795608ioi.0 for ; Tue, 28 Jul 2015 15:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=xAdgOlRdyAOGK0VbAzHzgmog5QxwoqJmrULFY7eslvw=; b=KdSy0biH10e3c1Yjdot55VBzIQ+q9m30+vfBF557f8HHxr2O3ouPaipoxrHRsSmcmH lmQfGqkv0fBuS6kP2zEpxkrvhGv9OdCTwmgKOsHdfQMHWrQuClzrV2Xzk/I6fpYpAW3M YxyCq4yIpqxq7v3oaRJawuEybCNYaOCR1wkqs= 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:in-reply-to:from:date :message-id:subject:to:content-type; bh=xAdgOlRdyAOGK0VbAzHzgmog5QxwoqJmrULFY7eslvw=; b=BUA4PRb4B8k1ZVUnbIcsVG4svOXm15ymoiq6b8FteuiwJS/eKQKKuzHBxFBqKy2/jE 49PvDZ8sqQoTjb1xcgZzMRI4XriMeHRLM5JvLsFid49a373C0sontM8326dHQBdE3qwF NpaHLvc+CRpI6a+g68Diaj09ilqGxs9P/K7thXws+M1GSlSIL019DuGZGA6LZgdYKv6k yDh7ZJZAcfneOppHvCXqjy2i0XA+MTVn6BvFCkzHnuR043Mb7748HRS0xP1JETsSlFRT bGLbChN6FV4dzV42zRW1UOqvDiVAeBHFuwiAtISU3tjFRNGELhhJTpkxEjg4LnrH52xF w/Ug== X-Gm-Message-State: ALoCoQmyqSoLpItytiGEcjWpinxsiQatKfURdS28WMkP6/DE6Cf5IVdyTIXHThCp+XG8haWIQkQP X-Received: by 10.107.170.204 with SMTP id g73mr41086281ioj.85.1438122623885; Tue, 28 Jul 2015 15:30:23 -0700 (PDT) MIME-Version: 1.0 References: <20150720141036.GA32204@LK-Perkele-VII> In-Reply-To: From: David Benjamin Date: Tue, 28 Jul 2015 22:30:14 +0000 Message-ID: To: Andrei Popov , Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1142721824089a051bf70429 Archived-At: Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2015 22:30:27 -0000 --001a1142721824089a051bf70429 Content-Type: text/plain; charset=UTF-8 Sent from the right email this time. (Sorry folks who got it twice. One of these days I'll not mess this up! :-) ) On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote: > On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov > wrote: > >> Thanks for the detailed comments, Ilari. >> >> Based on the discussion at the TLS WG meeting, I created a pull request: >> https://github.com/tlswg/tls13-spec/pull/209 >> >> > - Mechanism like proposed looks dangerous when combined with HTTP/2. >> I believe the same issue already exists in HTTP/1 where multiple requests >> can be in flight at the same time. >> The way we handle this in HTTP/1 is by having the server application >> query the HTTP stack for the client cred. >> If there's no cred available, the HTTP stack triggers client >> authentication (and the server application waits until the client cred is >> provided so it can authorize the request). >> > > The issue only exists in HTTP/1 if the client does pipelining. As far as I > know, no current[*] major browser deploys HTTP pipelining by default. > Chrome certainly doesn't. > > [*] Wikipedia says Opera used to do it before they switched to Chromium? > > Are you intending that this mechanism be enabled by default for HTTP/2 or > would the prohibition against renego still apply? Without any way for the > client to tie the CertificateRequest to the HTTP request that triggered it, > this mechanism would have many of the same problems as renego as far as > HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > suppose.) > > >> > - Regarding last point about interleaving: Assuming the scheme works >> in 1RTT (and I see no reason for requiring more rounds), you can't >> prevent application_data transmission after certificate_request. >> We discussed at the meeting that this restriction cannot be implemented. >> Instead, a server may block the processing of any in-flight requests >> while waiting for the client to authenticate (if the server's architecture >> requires this). >> > > This requires the server buffer arbitrarily many requests from the client, > which seems poor. For renego-based mid-stream auth, I believe Apache httpd > does not do this and will actually fail the connection on interleave. (But > I've never tested this, just glanced at how they use OpenSSL, so I could be > wrong.) > > > - The certificate_types field in CertificateRequest is pretty much >> useless, since all supported algorithms are of signature type. >> If the signature_algorithms extension officially becomes MTI, then >> perhaps we can discus getting rid of certificate_types in the >> CertificateRequest. Except we may want to use this field when we introduce >> new certificate types (e.g. something like IEEE1609 certs). >> >> > - How does extension_values work? If multiple values for one >> OID are allowed, then the OID/value pair is repeated, once for >> each value? >> Multiple values are DER-encoded per RFC that defines the OID that allows >> multiple values. >> The idea here is to simply reuse the existing OID-parsing code. A TLS >> implementation (or certificate API) that recognizes the OID in the cert, >> already knows how to parse its representation. A TLS implementation (or >> certificate API) that does not recognize the OID in the cert will also skip >> this OID in the extension_values. In the degenerate case, an implementation >> may choose to skip all extension_values. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara >> Sent: Monday, July 20, 2015 4:11 PM >> To: tls@ietf.org >> Subject: [TLS] Commentary on the client authentication presentation slides >> >> Some commentary on client authentication slides (there is no linked draft >> nor other material yet). >> >> - Mechanism like proposed looks dangerous when combined with HTTP/2. >> Multiplexed protocols are in general not safe to authenticate without >> application-layer signaling (which can be implicit via separate >> connections), especially if dealing with something like web >> environment. >> - Regarding last point about interleaving: Assuming the scheme works >> in 1RTT (and I see no reason for requiring more rounds), you can't >> prevent application_data transmission after certificate_request. >> The best that can be done is to require the client to send all >> the authentication-related data in one go. >> - The certificate_types field in CertificateRequest is pretty much >> useless, since all supported algorithms are of signature type. >> - One can't just remove fields without breaking parse compatiblity, >> but adding field breaks parse compatiblity too, so removing >> field at the same time isn't a problem. >> - How does extension_values work? If multiple values for one >> OID are allowed, then the OID/value pair is repeated, once for >> each value? >> >> >> >> -Ilari >> >> _______________________________________________ >> 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 >> > --001a1142721824089a051bf70429 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sent from the right email this time. (Sorry folks who got = it twice. One of these days I'll not mess this up! :-) )

On Tue, Jul 28, 2015 at 6:28 PM David = Benjamin <davidben@google.com= > wrote:
On Fri, Jul 24, 2015 at 1:02 AM Andre= i Popov <Andrei.Popov@microsoft.com> wrote:
Thanks for the detailed comments, Ilari.

Based on the discussion at the TLS WG meeting, I created a pull request: https://github.com/tlswg/tls13-spec/pull/209

> - Mechanism like proposed looks dangerous when combined with HTTP/2. I believe the same issue already exists in HTTP/1 where multiple requests c= an be in flight at the same time.
The way we handle this in HTTP/1 is by having the server application query = the HTTP stack for the client cred.
If there's no cred available, the HTTP stack triggers client authentica= tion (and the server application waits until the client cred is provided so= it can authorize the request).

=
The = issue only exists in HTTP/1 if the client does pipelining. As far as I know= , no current[*] major browser deploys HTTP pipelining by default. Chrome ce= rtainly doesn't.

[*] Wikipedia says Opera used= to do it before they switched to Chromium?

Are you intending= that this mechanism be enabled by default for HTTP/2 or would the prohibit= ion against renego still apply? Without any way for the client to tie the C= ertificateRequest to the HTTP request that triggered it, this mechanism wou= ld have many of the same problems as renego as far as HTTP/2 is concerned. = (I realize Microsoft has a draft floating around for a TLS_RENEG_PERMITTED = HTTP/2 setting. The setting can control this too I suppose.)
=C2=A0
> - Regarding last point about interleaving: Assuming the scheme works =C2=A0 in 1RTT (and I see no reason for requiring more rounds), you can'= ;t
=C2=A0 prevent application_data transmission after certificate_request.
We discussed at the meeting that this restriction cannot be implemented. Instead, a server may block the processing of any in-flight requests while = waiting for the client to authenticate (if the server's architecture re= quires this).

This requires the ser= ver buffer arbitrarily many requests from the client, which seems poor. For= renego-based mid-stream auth, I believe Apache httpd does not do this and = will actually fail the connection on interleave. (But I've never tested= this, just glanced at how they use OpenSSL, so I could be wrong.)

> - The certificate_types field in CertificateRequest is pretty much
=C2=A0 useless, since all supported algorithms are of signature type.
If the signature_algorithms extension officially becomes MTI, then perhaps = we can discus getting rid of certificate_types in the CertificateRequest. E= xcept we may want to use this field when we introduce new certificate types= (e.g. something like IEEE1609 certs).

> - How does extension_values work? If multiple values for one
=C2=A0 OID are allowed, then the OID/value pair is repeated, once for
=C2=A0 each value?
Multiple values are DER-encoded per RFC that defines the OID that allows mu= ltiple values.
The idea here is to simply reuse the existing OID-parsing code. A TLS imple= mentation (or certificate API) that recognizes the OID in the cert, already= knows how to parse its representation. A TLS implementation (or certificat= e API) that does not recognize the OID in the cert will also skip this OID = in the extension_values. In the degenerate case, an implementation may choo= se to skip all extension_values.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Monday, July 20, 2015 4:11 PM
To: tls@ietf.org
Subject: [TLS] Commentary on the client authentication presentation slides<= br>
Some commentary on client authentication slides (there is no linked draft n= or other material yet).

- Mechanism like proposed looks dangerous when combined with HTTP/2.
=C2=A0 Multiplexed protocols are in general not safe to authenticate withou= t
=C2=A0 application-layer signaling (which can be implicit via separate
=C2=A0 connections), especially if dealing with something like web
=C2=A0 environment.
- Regarding last point about interleaving: Assuming the scheme works
=C2=A0 in 1RTT (and I see no reason for requiring more rounds), you can'= ;t
=C2=A0 prevent application_data transmission after certificate_request.
=C2=A0 The best that can be done is to require the client to send all
=C2=A0 the authentication-related data in one go.
- The certificate_types field in CertificateRequest is pretty much
=C2=A0 useless, since all supported algorithms are of signature type.
- One can't just remove fields without breaking parse compatiblity,
=C2=A0 but adding field breaks parse compatiblity too, so removing
=C2=A0 field at the same time isn't a problem.
- How does extension_values work? If multiple values for one
=C2=A0 OID are allowed, then the OID/value pair is repeated, once for
=C2=A0 each value?



-Ilari

_______________________________________________
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
--001a1142721824089a051bf70429-- From nobody Tue Jul 28 18:44:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE971B3367 for ; Tue, 28 Jul 2015 18:44:37 -0700 (PDT) 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_25=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 8XxxPBwzurB5 for ; Tue, 28 Jul 2015 18:44:35 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B291B3364 for ; Tue, 28 Jul 2015 18:44:35 -0700 (PDT) Received: by qkfc129 with SMTP id c129so59919959qkf.1 for ; Tue, 28 Jul 2015 18:44:34 -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 :content-type; bh=+kslX0bOs/CoBEzT80hDoRDkarrYh7EDbAnmx3z1yIQ=; b=fVQqpLIFE6da/fMPG4nFimBceDy6YLTwNPKjwZ2mtnlXRYUnIRr4dSVmXncu1GWJuf e8gjs9ytXgqx5ydfsxrJgblwY+I7KTlnnQ7M4MewpDa/ipVpQ5EIeyoAEKFI1ZcN6qKn HGmaUrA5NtSTDBgaMl/+ncDqk0yE+oNRc7Vsti6nN1sLNeNIWt2BwJ2jsF9+6sebgHjD 3YqHOaEHa1y7NVklzIEMBklNacr6o6+wsRXATrIbXj+Ilw4IPQu4Ijmp91jWxtAR2m4I O1jaCY1or40tENkQJXD39fsbYdfM0+rt0az//0RZOxa0J27XdvvDcita/XHyb/tlt6FY AMtQ== MIME-Version: 1.0 X-Received: by 10.55.31.83 with SMTP id f80mr54057583qkf.2.1438134274658; Tue, 28 Jul 2015 18:44:34 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Tue, 28 Jul 2015 18:44:34 -0700 (PDT) In-Reply-To: <20150722171622.GH4347@mournblade.imrryr.org> References: <20150722171622.GH4347@mournblade.imrryr.org> Date: Tue, 28 Jul 2015 21:44:34 -0400 Message-ID: From: Shumon Huque To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1147b55c949709051bf9baf0 Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2015 01:44:37 -0000 --001a1147b55c949709051bf9baf0 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 1:16 PM, Viktor Dukhovni wrote: > On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote: > > > I think the server should stick to one chain, from the root to itself, > > so it does not have to deal with variable chain blobs per client. > > That will allow server code to stick to something like hourly > > regenerating the blob for use with all clients. > > >From the root to its own TLSA RRset, however, this can be complicated > in the presence of CNAMEs: > > www.example.com. IN CNAME cdn.example.net. > cdn.example.net. IN A 192.0.2.1 > _443._tcp.cdn.example.net. IN CNAME _dane.example.net. > _dane.example.net. IN TLSA 2 0 1 > > In this example, three leaf RRsets need to be verified back to the > root (with notable overlaps in the chains): > > www.example.com. IN CNAME > _443._tcp.cdn.example.net. IN CNAME > _dane.example.net. IN TLSA > > How should these be organized? It seems to me that the immediate > answer that gets the client going in the right direction is the > first CNAME, which enables to construct the TLSA base domain, > and then to follow the second CNAME to the ultimate TLSA RRset. > There are a number of possibilities here, including more complicated data structures. But I think we can use the current linear chain structure and have it composed of multiple sequences corresponding to intersecting branches of the DNS tree. For the following hypothetical example: _443._tcp.www.example.com. IN CNAME ca.example.net. ca.example.net. IN TLSA 2 0 1 the getdns library's validation chain function currently returns (RRSIGs omitted for brevity): _443._tcp.www.example.com. CNAME ca.example.net. TLSA example.com. DNSKEY example.com. DS com. DNSKEY com. DS . DNSKEY example.net. DNSKEY example.net. DS net. DNSKEY net. DS Should everything other than the first CNAME be in additional > records? Should all the above (with their RRSIGs) be in the answer > section, with the union of the supporting DNSKEY/RRSIG/DS records > as additional? > > I tried to ask a related question during the meeting, but bandwidth > to explain the context was limited: Should proofs of non-delegation > be included, to keep gTLDs and ccTLDs honest for some future CT for > DNS? Specifically, suppose you see: > > _443._tcp.www.example.com. IN TLSA > > with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3 > records that demonstrate that "example.com" (and www.example.com) > are not delegated? (Such records might then be subject to "gossip" > or related "transparency" counter-measures). > I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit more before considering DNSSEC key transparency issues. It looks like that draft proposes SCT RRs (with DS+chain data in them, signed by log providers), so we could in the future incorporate SCT RRs in the chain. However do we really need to? The TLS server is the one doing the DNS queries, so it could perform the SCT checks against the logs it trusts, while querying the chain records, and then build the validated chain. I'm not sure there is a need for the TLS client to additionally do these log checks, so it doesn't need to have that info delivered in the chain. > > As for ekr's question on why not stuff this inside X.509, that would not > > be compatible with tls raw pulic keys that only contain a SBKI, and drag > > back into the protocol more ASN.1 parsing and containers. > > This really can't go in the certificate, because then certificates > would have to be updated as often as RRSIGS are regenerated. That > seems exceedingly unlikely to be deployable. > I believe Eric's question was about why this couldn't be done via a new 'Certificate Type' (and not about embedding the chain in the X.509 cert). I presume the idea being the new certificate type would allow both the server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to be delivered in the server's Certificate Message. I believe the argument for doing it via a new TLS extension was that it would allow us to mandate the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature Extension. Shumon Huque --001a1147b55c949709051bf9baf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 1:16 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
O= n Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote:

> I think the server should stick to one chain, from the root to itself,=
> so it does not have to deal with variable chain blobs per client.
> That will allow server code to stick to something like hourly
> regenerating the blob for use with all clients.

>From the root to its own TLSA RRset, however, this can be compli= cated
in the presence of CNAMEs:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 www.example.com. IN CNAME cdn.example.net. =C2=A0 =C2=A0 =C2=A0 =C2=A0 cdn.example.net. IN A 192.0.2.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _443._tcp.cdn.example.net. IN CNAME _dane.ex= ample.net.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _dane.example.net. IN TLSA 2 0 1 <trust-an= chor-digest>

In this example, three leaf RRsets need to be verified back to the
root (with notable overlaps in the chains):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 www.example.com. IN CNAME <RDATA>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _443._tcp.cdn.example.net. IN CNAME <RD= ATA>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _dane.example.net. IN TLSA <RDATA>

How should these be organized?=C2=A0 It seems to me that the immediate
answer that gets the client going in the right direction is the
first CNAME, which enables to construct the TLSA base domain,
and then to follow the second CNAME to the ultimate TLSA RRset.

There are a number of possibilities here, includin= g more complicated data structures. But I think we can use the current line= ar chain structure and have it composed of multiple sequences corresponding= to intersecting branches of the DNS tree.=C2=A0

F= or the following hypothetical example:

_443._= tcp.www.example.com. =C2=A0 IN = =C2=A0 CNAME =C2=A0 =C2=A0ca.example.net<= /a>.
ca.example.net. =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IN =C2=A0 TLSA =C2=A0 =C2=A0 2 0 = 1 <cadata_blob>

the getdns library's val= idation chain function currently returns (RRSIGs omitted for brevity):

=C2=A0 _443._tc= p.www.example.com. CNAME
=C2=A0 ca.example.net. TLSA <set>

=C2=A0 <= a href=3D"http://example.com">example.com. DNSKEY <set>
=
=C2=A0 example.com. DS <set><= /div>
=C2=A0 com. DNSKEY <set>
=C2=A0 com. DS <set&g= t;
=C2=A0 . DNSKEY
=C2=A0 example.net. DNSKEY <set>
=C2=A0 example.net. DS <set>
=C2=A0 net. DNSKEY <= ;set>
=C2=A0 net. DS <set>


Should everything other than the first CNAME be in additional
records?=C2=A0 Should all the above (with their RRSIGs) be in the answer section, with the union of the supporting DNSKEY/RRSIG/DS records
as additional?

I tried to ask a related question during the meeting, but bandwidth
to explain the context was limited:=C2=A0 Should proofs of non-delegation be included, to keep gTLDs and ccTLDs honest for some future CT for
DNS?=C2=A0 Specifically, suppose you see:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 _443._tcp.www.example.com. IN TLSA <rrd= ata>

with an RRSIG from the ".com" zone, should there also be NSEC/NSE= C3
records that demonstrate that "example.com" (and www.example.com) are not delegated?=C2=A0 (Such records might then be subject to "gossi= p"
or related "transparency" counter-measures).

I'd prefer to wait till the trans-ct-dnssec draft has p= rogressed a bit more before considering DNSSEC key transparency issues.=C2= =A0

It looks like that draft proposes SCT RRs (wit= h DS+chain data in them, signed by log providers), so we could in the futur= e incorporate SCT RRs in the chain. However do we really need to? The TLS s= erver is the one doing the DNS queries, so it could perform the SCT checks = against the logs it trusts, while querying the chain records, and then buil= d the validated chain. I'm not sure there is a need for the TLS client = to additionally do these log checks, so it doesn't need to have that in= fo delivered in the chain.
=C2=A0
> As for ekr's question on why not stuff this inside X.509, that wou= ld not
> be compatible with tls raw pulic keys that only contain a SBKI, and dr= ag
> back into the protocol more ASN.1 parsing and containers.

This really can't go in the certificate, because then certificat= es
would have to be updated as often as RRSIGS are regenerated.=C2=A0 That
seems exceedingly unlikely to be deployable.

I believe Eric's question was about why this couldn't be done= via a new 'Certificate Type' (and not about embedding the chain in= the X.509 cert). I presume the idea being the new certificate type would a= llow both the server's X.509 certificate chain and the corresponding DA= NE/DNSSEC chain to be delivered in the server's Certificate Message. I = believe the argument for doing it via a new TLS extension was that it would= allow us to mandate the use of the DANE chain ("Must staple DANE"= ;) via the X.509 TLS Feature Extension.

Shumon Huq= ue

--001a1147b55c949709051bf9baf0-- From nobody Tue Jul 28 18:52:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20771B30DB for ; Tue, 28 Jul 2015 18:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 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_CHICKENPOX_25=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 pxVRCj7JALaX for ; Tue, 28 Jul 2015 18:52:18 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 70D0E1B30D9 for ; Tue, 28 Jul 2015 18:52:18 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 30974202043 for ; Tue, 28 Jul 2015 18:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=MTvKWGHTSzvERbObrqV6J55xRSE=; b=hbguyCzwq6r4o yIaPeCC+SOPRVhEMcjJoCpYHH9IAqlMmfs6KrmxR7pXPUzeHpJ/Ae8jF8a6J6YOs 2vwVOUiFOe/wJ4tsaeMipntqZmIixpFAq9osM9nk0i/DcS1nq8FBxTjvbydu3zUX Y5rE+MeF1wZUurTmzEU5Jq6wDmWSfI= Received: from spandex.local (216-67-70-212-radius.dynamic.acsalaska.net [216.67.70.212]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id DB51B20202C for ; Tue, 28 Jul 2015 18:52:17 -0700 (PDT) Message-ID: <55B831D0.1080907@nomountain.net> Date: Tue, 28 Jul 2015 17:52:16 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <20150722171622.GH4347@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2015 01:52:19 -0000 On 7/28/15 5:44 PM, Shumon Huque wrote: > I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit > more before considering DNSSEC key transparency issues. > > It looks like that draft proposes SCT RRs (with DS+chain data in them, > signed by log providers), so we could in the future incorporate SCT RRs > in the chain. That draft really is pretty immature and at this point it's not clear whether and how it's going to progress. Paul Wouters can speak for himself about where he thinks the draft needs to go but I think it does bear pointing out that he's offered to help out with content, given that he's got considerable DNS and DNSSEC expertise. If the document does continue to progress I would expect quite substantial changes. > I believe Eric's question was about why this couldn't be done via a new > 'Certificate Type' (and not about embedding the chain in the X.509 > cert). I presume the idea being the new certificate type would allow > both the server's X.509 certificate chain and the corresponding > DANE/DNSSEC chain to be delivered in the server's Certificate Message. I > believe the argument for doing it via a new TLS extension was that it > would allow us to mandate the use of the DANE chain ("Must staple DANE") > via the X.509 TLS Feature Extension. Well, sort of. We did talk about creating a new certificate extension rather than a TLS extension but opted not to. The one advantage of an X.509 extension would have been that it wouldn't require protocol changes, but it still would have required modifying both the server and the endpoint. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Tue Jul 28 19:05:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6E51A1B59 for ; Tue, 28 Jul 2015 19:05:40 -0700 (PDT) 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_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPOOF_COM2OTH=2.723] 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 1-30jy83ifdK for ; Tue, 28 Jul 2015 19:05:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154061A1B40 for ; Tue, 28 Jul 2015 19:05:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3048B284D5A; Wed, 29 Jul 2015 02:05:38 +0000 (UTC) Date: Wed, 29 Jul 2015 02:05:38 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150729020538.GJ4347@mournblade.imrryr.org> References: <20150722171622.GH4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension 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, 29 Jul 2015 02:05:40 -0000 On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote: > For the following hypothetical example: > > _443._tcp.www.example.com. IN CNAME ca.example.net. > ca.example.net. IN TLSA 2 0 1 This is simpler than the general case, everything is still "linear", because there's only a CNAME chain leading to the TLSA RRset. More generally, there's also a CNAME chain leading to the TLSA base domain: www.example.com. IN CNAME www.example.com.cdn.example.net. www.example.com.cdn.example.net IN CNAME node1.example.net. node1.example.net. IN A 192.0.2.1 _443._tcp.node1.example.net. IN CNAME ca.example.net. ca.example.net IN TLSA 2 0 1 Here, we have CNAME (perhaps via a DNAME) indirection from the SNI name (www.example.com) to the actual TLSA base domain (node1.example.net). And then more CNAME records from there to the CDN provider's TLSA RRset. This is no longer the DNS response to a single query (iterative resolvers generally chase CNAMEs), since one first CNAME expands the original target hostname to obtain the TLSA base domain (provided the CNAME chain is validated end-to-end) and then CNAME expands the _443._tcp. prefixed base domain to find the TLSA RRset. > the getdns library's validation chain function currently returns (RRSIGs > omitted for brevity): > > _443._tcp.www.example.com. CNAME > ca.example.net. TLSA > > example.com. DNSKEY > example.com. DS > com. DNSKEY > com. DS > . DNSKEY > example.net. DNSKEY > example.net. DS > net. DNSKEY > net. DS The getdns library is unlikely to handle the fully general case, because first the TLSA base domain has to be found. > It looks like that draft proposes SCT RRs (with DS+chain data in them, > signed by log providers), so we could in the future incorporate SCT RRs in > the chain. However do we really need to? The TLS server is the one doing > the DNS queries, so it could perform the SCT checks against the logs it > trusts, while querying the chain records, and then build the validated > chain. I'm not sure there is a need for the TLS client to additionally do > these log checks, so it doesn't need to have that info delivered in the > chain. The TLS server is not trusted, the whole point is detect malfeasance, where the DNS operator and TLS server conspire to lie (to selected clients). > > This really can't go in the certificate, because then certificates > > would have to be updated as often as RRSIGS are regenerated. That > > seems exceedingly unlikely to be deployable. > > > > I believe Eric's question was about why this couldn't be done via a new > 'Certificate Type' (and not about embedding the chain in the X.509 cert). I > presume the idea being the new certificate type would allow both the > server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to > be delivered in the server's Certificate Message. I believe the argument > for doing it via a new TLS extension was that it would allow us to mandate > the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature > Extension. I see. I think the question of whether "must staple DANE" is supported or not is quite orthogonal to the question of how DANE stapled data is encoded. The disadvantage of this being a new certificate type is that AFAIK it would then not be orthogonal to the choice between X.509 chains and raw public keys. We might then have a (small) combinatorial mess: traditional X.509 chain X.509 chain with stapled DANE evidence raw public key raw public key with stapled DANE evidence I think the extension is a more logical separation of duties, but I am willing to hear contrary arguments. -- Viktor. From nobody Tue Jul 28 19:43:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361A11B352D for ; Tue, 28 Jul 2015 19:43:32 -0700 (PDT) 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_25=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 CzJJMOVgGVe7 for ; Tue, 28 Jul 2015 19:43:30 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049BE1B3524 for ; Tue, 28 Jul 2015 19:43:30 -0700 (PDT) Received: by qgii95 with SMTP id i95so85651337qgi.2 for ; Tue, 28 Jul 2015 19:43:29 -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 :content-type; bh=VsfyhEn7xDiwPYm0tvK/0YB1TGT3dyUtJ47PSLuZtdk=; b=rf/+mmOmqJptazPxAm3K+vnsXU/jofTygOqmLvcE+ONBCgWTN5zgRChqpbvQNBHUZP dEdF9SxxPZZlGlik2I0yik5ap/4v/2GGrHsnVxPPRvr84FfIBmgH/pXeL4AR3N2sKwqP Os4WXOZ8PP5/4NlMElL9+fnT1zdzNGCGkoPhJ+C9EL8QTVVhepaEj2IbIYaas6binHXD HFGIBonVkYrezwmo/3ki6/X3wA/Qf5JqROl+jOdzJqTa9cEsIM8Lm7w0QilFoFBgQ9xq v94PhbyGF+j/A8TSE5j25e7reIsTAw3L12u6I2IrTZ6CZS59y5P+EyXfkmLjb4x1rP7W sPHQ== MIME-Version: 1.0 X-Received: by 10.140.38.21 with SMTP id s21mr41004044qgs.10.1438137809306; Tue, 28 Jul 2015 19:43:29 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Tue, 28 Jul 2015 19:43:29 -0700 (PDT) In-Reply-To: <20150729020538.GJ4347@mournblade.imrryr.org> References: <20150722171622.GH4347@mournblade.imrryr.org> <20150729020538.GJ4347@mournblade.imrryr.org> Date: Tue, 28 Jul 2015 22:43:29 -0400 Message-ID: From: Shumon Huque To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c12c4043125a051bfa8d84 Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2015 02:43:32 -0000 --001a11c12c4043125a051bfa8d84 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni wrote: > On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote: > > This is no longer the DNS response to a single query (iterative > resolvers generally chase CNAMEs), since one first CNAME expands > the original target hostname to obtain the TLSA base domain (provided > the CNAME chain is validated end-to-end) and then CNAME expands > the _443._tcp. prefixed base domain to find the TLSA RRset. > Hmm, I guess the DANE ops draft says to look for TLSA records at the alias target rather than the owner name. This doesn't seem to be how many early HTTPS sites are deploying TLSA records though, e.g. www.ietf.org. > the getdns library's validation chain function currently returns (RRSIGs > > omitted for brevity): > > > > _443._tcp.www.example.com. CNAME > > ca.example.net. TLSA > > > > example.com. DNSKEY > > example.com. DS > > com. DNSKEY > > com. DS > > . DNSKEY > > example.net. DNSKEY > > example.net. DS > > net. DNSKEY > > net. DS > > The getdns library is unlikely to handle the fully general case, > because first the TLSA base domain has to be found. > It probably doesn't today. I'll check into this. > > It looks like that draft proposes SCT RRs (with DS+chain data in them, > > signed by log providers), so we could in the future incorporate SCT RRs > in > > the chain. However do we really need to? The TLS server is the one doing > > the DNS queries, so it could perform the SCT checks against the logs it > > trusts, while querying the chain records, and then build the validated > > chain. I'm not sure there is a need for the TLS client to additionally do > > these log checks, so it doesn't need to have that info delivered in the > > chain. > > The TLS server is not trusted, the whole point is detect malfeasance, > where the DNS operator and TLS server conspire to lie (to selected > clients). > Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional threat we should take into account. > > > This really can't go in the certificate, because then certificates > > > would have to be updated as often as RRSIGS are regenerated. That > > > seems exceedingly unlikely to be deployable. > > > > > > > I believe Eric's question was about why this couldn't be done via a new > > 'Certificate Type' (and not about embedding the chain in the X.509 > cert). I > > presume the idea being the new certificate type would allow both the > > server's X.509 certificate chain and the corresponding DANE/DNSSEC chain > to > > be delivered in the server's Certificate Message. I believe the argument > > for doing it via a new TLS extension was that it would allow us to > mandate > > the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature > > Extension. > > I see. I think the question of whether "must staple DANE" is > supported or not is quite orthogonal to the question of how DANE > stapled data is encoded. > Encoded yes, but not necessarily on what protocol element carries the encoding. It depends on what mechanism is being used for the must-staple assertion. The X.509 TLS feature extension mechanism requires a list of TLS extension values to be specified. Using a new TLS certificate type would not be compatible with that. The disadvantage of this being a new certificate type is that AFAIK > it would then not be orthogonal to the choice between X.509 chains > and raw public keys. We might then have a (small) combinatorial mess: > > traditional X.509 chain > X.509 chain with stapled DANE evidence > raw public key > raw public key with stapled DANE evidence > > I think the extension is a more logical separation of duties, but > I am willing to hear contrary arguments. > Yes, I agree. Shumon Huque. --001a11c12c4043125a051bfa8d84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
O= n Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:

This is no longer the DNS response to a single query (iterative
resolvers generally chase CNAMEs), since one first CNAME expands
the original target hostname to obtain the TLSA base domain (provided
the CNAME chain is validated end-to-end) and then CNAME expands
the _443._tcp. prefixed base domain to find the TLSA RRset.

Hmm, I guess the DANE ops draft says to look for TLSA = records at the alias target rather than the owner name. This doesn't se= em to be how many early HTTPS sites are deploying TLSA records though, e.g.= www.ietf.org.

> the getdns library's validation chain function currently returns (= RRSIGs
> omitted for brevity):
>
>=C2=A0 =C2=A0_443._tcp.www.example.com. CNAME
>=C2=A0 =C2=A0ca.example.net. TLSA <set>
>
>=C2=A0 =C2=A0example.com. DNSKEY <set>
>=C2=A0 =C2=A0example.com. DS <set>
>=C2=A0 =C2=A0com. DNSKEY <set>
>=C2=A0 =C2=A0com. DS <set>
>=C2=A0 =C2=A0. DNSKEY
>=C2=A0 =C2=A0example.net. DNSKEY <set>
>=C2=A0 =C2=A0example.net. DS <set>
>=C2=A0 =C2=A0net. DNSKEY <set>
>=C2=A0 =C2=A0net. DS <set>

The getdns library is unlikely to handle the fully general case,
because first the TLSA base domain has to be found.
It probably doesn't today. I'll check into this.
=
=C2=A0
> It looks like that draft proposes SCT RRs (with DS+chain data in them,=
> signed by log providers), so we could in the future incorporate SCT RR= s in
> the chain. However do we really need to? The TLS server is the one doi= ng
> the DNS queries, so it could perform the SCT checks against the logs i= t
> trusts, while querying the chain records, and then build the validated=
> chain. I'm not sure there is a need for the TLS client to addition= ally do
> these log checks, so it doesn't need to have that info delivered i= n the
> chain.

The TLS server is not trusted, the whole point is detect malfeasance= ,
where the DNS operator and TLS server conspire to lie (to selected
clients).

Yeah, I had a feeling you'= ;d say this :-) Fair enough, that's an additional threat we should take= into account.
=C2=A0
> > This really can't go in the certificate, because then certifi= cates
> > would have to be updated as often as RRSIGS are regenerated.=C2= =A0 That
> > seems exceedingly unlikely to be deployable.
> >
>
> I believe Eric's question was about why this couldn't be done = via a new
> 'Certificate Type' (and not about embedding the chain in the X= .509 cert). I
> presume the idea being the new certificate type would allow both the > server's X.509 certificate chain and the corresponding DANE/DNSSEC= chain to
> be delivered in the server's Certificate Message. I believe the ar= gument
> for doing it via a new TLS extension was that it would allow us to man= date
> the use of the DANE chain ("Must staple DANE") via the X.509= TLS Feature
> Extension.

I see.=C2=A0 I think the question of whether "must staple DANE&= quot; is
supported or not is quite orthogonal to the question of how DANE
stapled data is encoded.

Encoded yes, b= ut not necessarily on what protocol element carries the encoding. It depend= s on what mechanism is being used for the must-staple assertion. The X.509 = TLS feature extension mechanism requires a list of TLS extension values to = be specified. Using a new TLS certificate type would not be compatible with= that.

The disadvantage of this being a new certificate type is that AFAIK
it would then not be orthogonal to the choice between X.509 chains
and raw public keys.=C2=A0 We might then have a (small) combinatorial mess:=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 traditional X.509 chain
=C2=A0 =C2=A0 =C2=A0 =C2=A0 X.509 chain with stapled DANE evidence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 raw public key
=C2=A0 =C2=A0 =C2=A0 =C2=A0 raw public key with stapled DANE evidence

I think the extension is a more logical separation of duties, but
I am willing to hear contrary arguments.

Yes, I agree.

Shumon Huque.

=
--001a11c12c4043125a051bfa8d84-- From nobody Tue Jul 28 20:05:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161261B3559 for ; Tue, 28 Jul 2015 20:05:35 -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 oef-oE7vz7AT for ; Tue, 28 Jul 2015 20:05:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299BE1B355B for ; Tue, 28 Jul 2015 20:05:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 33A21284D5A; Wed, 29 Jul 2015 03:05:32 +0000 (UTC) Date: Wed, 29 Jul 2015 03:05:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150729030531.GK4347@mournblade.imrryr.org> References: <20150722171622.GH4347@mournblade.imrryr.org> <20150729020538.GJ4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension 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, 29 Jul 2015 03:05:35 -0000 On Tue, Jul 28, 2015 at 10:43:29PM -0400, Shumon Huque wrote: > > This is no longer the DNS response to a single query (iterative > > resolvers generally chase CNAMEs), since one first CNAME expands > > the original target hostname to obtain the TLSA base domain (provided > > the CNAME chain is validated end-to-end) and then CNAME expands > > the _443._tcp. prefixed base domain to find the TLSA RRset. > > > > Hmm, I guess the DANE ops draft says to look for TLSA records at the alias > target rather than the owner name. This doesn't seem to be how many early > HTTPS sites are deploying TLSA records though, e.g. www.ietf.org. With www.ietf.org, the TLSA record for HTTP was there long before the DANE ops draft: www.ietf.org. IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net. _443._tcp.www.ietf.org. IN TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6 www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.1.85 www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.0.85 The DANE ops draft says to look at the end of the CNAME chain (if secure) first, and if there are no TLSA RRs there, only then stick with the original name. So sites that do it the old way (as above) also work. But with the new model cloudflare can provision the "3 1 1" record on their end. In the case of DANE stapling, the CNAME chasing (or not) is done by the server, which should ideally know whether it has a TLSA RRset for the requested SNI domain, or whether it should construct a CNAME chain starting with that name. The point is that clients have to be prepared for either outcome. In essence the server is a DNS proxy for a client that is either cut-off from DNSSEC, or simply unwilling to pay the latency cost. The data consumed by the client is the same whether acquired unilaterally, or via the server. One could almost imagine a VPN tunnel set up by the client and server between the DNS caches on either end, except that for multiple reasons that mental model is rather a crude approximation of the details. It can however be a useful source of inspiration. > > The TLS server is not trusted, the whole point is detect malfeasance, > > where the DNS operator and TLS server conspire to lie (to selected > > clients). > > Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional > threat we should take into account. If and when CT for DNSSEC comes into the picture. -- Viktor. From nobody Wed Jul 29 02:59:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760201A028A for ; Wed, 29 Jul 2015 02:59:54 -0700 (PDT) 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 5QJBnvndV5Ey for ; Wed, 29 Jul 2015 02:59:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A62E1A0217 for ; Wed, 29 Jul 2015 02:59:53 -0700 (PDT) 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 (Postfix) with ESMTPS id 5DEE078; Wed, 29 Jul 2015 09:59:52 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-64.ams2.redhat.com [10.36.112.64]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6T9xlCh022403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2015 05:59:51 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 29 Jul 2015 11:59:41 +0200 Message-ID: <2289724.pXJjcWpFTc@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.0.8-300.fc22.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20150728160154.GU4347@mournblade.imrryr.org> References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> <20150728160154.GU4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2165947.i50fGD6tct"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] No cypher overlap (was: ban more old crap) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2015 09:59:54 -0000 --nextPart2165947.i50fGD6tct Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote: > On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote: > > I see one possible problem with TLS1.3 not being a superset of TLS1= .2. > >=20 > > Consider the following: > > Server which supports TLSv1.3 but is configured to accept only AES2= 56 > > ciphers. > >=20 > > Client which advertises TLSv1.3, but no support for AES256-GCM. The= client > > advertises also CBC ciphers (both AES128 and AES256) as it wants to= be > > able > > to connect to legacy servers too. > >=20 > > Should such a connection end up with TLS1.2 with AES-CBC ciphersuit= e, or > > should it be aborted? >=20 > We already see a similar dilemma with clients that (artificially) > support only SSLv2 ciphersuites, but advertise TLS protocol versions.= > OpenSSL will first choose a common protocol (TLS 1.x) and then fail > to find any shared ciphers. To complete the connection, the client > must explicitly request only SSL 2.0. There is at present no > filtering out of protocol choices for lack of compatible ciphers. >=20 > > I think we should go for continue connection with downgraded protoc= ol, but > > explicitly say that it may not happen if the negotiated ciphersuite= would > > be DES, RC4, export grade... >=20 > In that case, it should be said that a client MUST NOT advertise > TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers > (or perhaps less restrictive at least one TLS 1.3 compatible cipher).= MTI does not mean Mandatory To Enable > Otherwise, there'll be lots of clients whose TLS libraries advertise > 1.3 (just because they implement the protocol), but whose cipher > configuration includes only TLS 1.2 (or lower) suites (because the > application configuration has not been updated). yes, that's what I'm afraid of > Punishing those clients by having servers abort the handshake is > a bad idea. The right outcome is use of TLS 1.2, whether because > client implementations of 1.3 need to check that adequate cipher > suites are available, or because servers negotiate 1.2 when 1.3 > is impossible. neither clients nor servers are required to support (have them enabled)= all=20 ciphersuites defined for TLS1.3, so there is always chance for no commo= n=20 cipher between them =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2165947.i50fGD6tct Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVuKQNAAoJEJKo0bgB0vX1p3kQAIVuCbD+kmxhr3P4dZDD1QWr pqQJI5YNJIReOg/ttQ/Vq94g9j0kRUt7QTrTDNTYt6X566De2gLEHitKFR53M4v8 kVqp2Ch2iH57yk49ChDUb89y6ORAa2uH063TB7kt7JrD1P+Nn9jFssUz4hvY/HX4 HIX8M6ytxjn62ELtkM9d/J/Qd0KFlAnwgHEagdEU0CYydxHzV5GRR/wKxfzU7+y/ FDd1V+XK33DQN99Hs8bb88CX/2OjZKDzGJTUAO3RAHzkIVWdW4XAleD0dgqhLhKU Hq1KLsU+a20Tg4l4F71CqUmXqULotPyk0y6eoC++yMYu/G0QTynqG/rOiDpXA+aJ 3ARypBsAZD6anyMOWKzOW9ttEnlPprxTxZUv+aq0Du58KTH0wPVML8DE+je0+Chf 0Zf3qkM4zSxdNYwH4DNVZnbXAaf5QgZcEiuCP7sMQiye69picSutw914OGjgguEz k8KcL8wbN1YW/CWfXaHVW9MPjovIOZs7y6GFFmJlljcS9xpisxBU4XpaeFqgkwyj Iu5KGWhT4d/olIrlHrhMYb20o3aVFLquM1KBVl1e6hQd6b5nVq+FMgroKMEByAqV F7BGkF06NFttOQf3rZETYAO3+7DpApAL9xHyiT14Wam+L8ET0uA7bmQqHNuGvr6X XXHQSukUUpLDMRarLUmY =XnC+ -----END PGP SIGNATURE----- --nextPart2165947.i50fGD6tct-- From nobody Wed Jul 29 05:06:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0F1A001B for ; Mon, 27 Jul 2015 16:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 IPmCJhAa3jIS for ; Mon, 27 Jul 2015 16:11:28 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD4D1A0019 for ; Mon, 27 Jul 2015 16:11:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 80C43290DA for ; Mon, 27 Jul 2015 23:11:26 +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 49BA2290CF for ; Mon, 27 Jul 2015 23:11:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1438038686; bh=woM1FabmKdoaFBYq1xKg9jYtM1SNqcgliW5fMzcfGno=; h=From:To:Subject:Date:From; b=BFPcij/ZJaqiKVKBXs0l0lWPXNLWqdPnaUC3XZGx8eYNtvCaqEZmVesYW25UbDtL8 f+Eq5lnghHk97RIHMuYf3euAkIisazPKIClbij77ukWRl2PRHkMtD1CUA+KAOAoovu 6WeUmQtFYWpZnCZ792JPVhAu9Q7mf48kiuVg1AgI= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E9C452029 for ; Mon, 27 Jul 2015 23:11:25 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 27 Jul 2015 18:11:25 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 27 Jul 2015 18:11:25 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: Our [TLS] fearless leader Thread-Index: AdDIwYq6asBiUoObRb2djP5Y5276UQ== Date: Mon, 27 Jul 2015 23:11:24 +0000 Message-ID: <83d1c18c633149ffa7f7ff1e34838c1f@ustx2ex-dag1mb2.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.243] Content-Type: multipart/mixed; boundary="_002_83d1c18c633149ffa7f7ff1e34838c1fustx2exdag1mb2msgcorpak_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 05:06:05 -0700 Subject: [TLS] Our fearless leader X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2015 23:11:29 -0000 --_002_83d1c18c633149ffa7f7ff1e34838c1fustx2exdag1mb2msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sean, at the CFRG meeting last week, wasn't bothered at all when all the se= ats were taken. --_002_83d1c18c633149ffa7f7ff1e34838c1fustx2exdag1mb2msgcorpak_ Content-Type: image/jpeg; name="IMG-20150722-00055.jpg" Content-Description: IMG-20150722-00055.jpg Content-Disposition: attachment; filename="IMG-20150722-00055.jpg"; size=105904; creation-date="Mon, 27 Jul 2015 23:10:07 GMT"; modification-date="Mon, 27 Jul 2015 23:10:07 GMT" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAMABAADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxhSFA yM9s96kV1BPXPINOEYGOMn1pSoABAOaxaTNlJpWE3gDnOe5Ip5cbS2BzS7BnGD64oKKDjHHGMmly rqPnkM3gYySQe1KXBJ5OO3HQ1IIweuM+lOMXzfd470WWwe0lfQgUgMCcjHcDrS7gAC2evpzUwixx j3+lL5Q9AQTkepp8qDndtSHeBwQT6Yo3AHGWz2qfYvBxzjkUeWCOB7jilZMSmyHeAc4JPsKMgnA6 9SanEYGeMmlWMf3c/hRZFc72IBt+bgk9+aAcdARVrysEnAFHlKAMjOD6UWQuZoqgkkkZJoLMT0Pu athOM7QD/Sl8obSSMe1HKrBzSKYyTjk46UZJIG0kirwjU5460oiAHT1oSRLm9ij8xGApPNLhjwc/ gKu+UAc9+3vTvL6k4FFkHM0yhhsEEHH8z60uGzyCeP1q75eAMgdec0vlDJJxjsKLIfNIokNxjJ9M ml2tjOOPU1f8oE5wMdx0pfKBxkYxQ0hOUjP2vkADn0FOwwz8uPSr+wDoMkd6Xy8jlaOVWDnkZ+HI AwMZpdr4PBB45FXhFg8YHbGKcYue2KLISm2zP8t+eM5pdkuMYx/Or5jGMgnFOMQx659aElcfPIzt j4zj8u9Aicj7o9eTWgIs5GOPpTvLGBgDnqMUtOwc8rmdsfJBHQUojbAwB6kitIxDqQPbik8o49+3 NOy6i5pX1M7y5D2Ge1LsbuoGDzk1oCMAYxz60pj74BHvRZD5pGd5TEZK8CgxOMHAP9K09mQPpil8 vvxj8qLIOaRmiKUg8A/SjypMjIHPvWkEXBA60gQFsED60WQc0uhn+VJyQAQKPLl9AQK0vKHPA+tA jHPqTSshc0upm+RKwwcAdKcIZAScA46Vo+UCQDySaXy1KngfWiyHzS3MswyH0BpfKm4GAPWtLyjn GB1zSiMcd/pT5UHM2ZoilxjpR5MoPr+NaXljGOMDtTjHx047UrK+ocz6My/Il+nHY0C3lI7fhWn5 YIIOMgcUojA4FOy6g5SsZfkS/TPTHeneRKBkgZ9TWkUGAcc4p3lcZ4P9KVkLmkZfkykgcfXNL5D5 OeceprSEYAPHJNL5eOMZzTshqUloZvkPgHH601reTjgA+me1amwZ6AmnBBjBAz70mkNSlsZP2aXP bPpS/Z5cHAAOQa1Co7joeSDQYhwQD+FCsHNKxmeRJkZGeOTmjyJPTj61qrFgc8nNGwZxjk0WTBSk ZXlS57Eg8c0n2eUHBGBWqEGcAH3oMY46mnZdQ5pGX9mlPQDIFAgm4A/+sa1fL9AMe9GzODgUmkCk +pleRKT2HoM8CgQS9SO/NanljJNHlZB4zj07UJIOZmZ5EvbnPfPSk8iXI759+tavljjAGD1o2AYG Py7U7ISlJGZ5EueQDR5UmAABnvWr5YyQcnP6UeUMgYyPYUlYfNKxleVLnGOfWl8qTIIUnHbNanlD kgjnt6UCIY6D86dlcSlIy/KkPOME+9IYn2YwQfr1rV8tcfd5HpSeUM+vpS0BzZmeVKFIAJ9eaPLk 9O3r1rTEQzzgk0vkjjpx2p2Q1KXQzdsuBhTxRtlyRtxnpWn5IOPlOD+FHlAnoPYUrJ6C55dTN2uA fkwR+VKA+fuZ59a0PLAyMDmkEXPIwO+KLLYbkzPw7EAJnmjMmceXz65q/sGOB7cUvlgcn+VCikLm kZ5LgY2HPWgFiBlDkGr4i4zx7e1O8sY6AHPWiyHzMzy5AyYz+Bpd5xyhB9qvmIbOxyeuKaYgRkAD 3NNJE80rlIOcfcal38j5WFXPK5B7fSjygecDPtSsh88rlLecHCsKTzDjoxweTV7yhxkZyMik8oBy SBjjtT0sJuRU809dpGRkZ9KXeBjG4DHYVa8oA+oPajyhjgUJKwczRU8xSf4vypfOB4APHU4q0IBt BAwe+R1o8pcjIH4ijQOZlIyqeu4Y9qbvyD1Az6VdMPORgHpR5QOeBke1LlQ+ZopF1JHByPal3KBk 5HvirfkgE9AD2pfIHcAgfrTSsLmdylvQHknHWl3pwN349M1a8oZOVAB6UfZxjJUHB4osLmb3K29c kkkAUnmoRw2as+QpBwBx1z3prQKTyAPQgUWGm9yHzIwD83PpSB15GRjtzVj7OADxnjFHkLj7o468 UOKHzsr71IBDY/GhmUrjcMetT/ZlwDgAdxTfs6gEBRg9KElsLmb3IgRjls++aaSDkg4qf7MODtGa PsygH5QM9896LIfM+hDwOcjPY+tKcHAzjI7U77MPQZ/SkFsoOMdPehRHzvqNyAQNw+lB6HJBHuKe bdSTgA+2KZ9kGOOtLlBy7DRg8HBPr2puCepB5wKf9nU8AEn+VH2cEgDqD607agpq1hjZKgcAd6Zg 4DcE+x6VL9myO4x3z2phg54J56EdxRyq4+cbtJGOCT700pjtgfWpPs5OME00wEH5s9fXgUuVMObu NKkDIGSeCM4ppBGMDknqKd9nOTyc/Wl8kjnJ4754xRygpkZJBwcEelJg9Mc5wfYVJ9nJIyx54+lL 9nO7JJHPBzxiny9h82hAQTxknHvmkwwzwSSeMnqal8hgcqxGSQab5DZyScUOIKaSI8NgZB7d6ZgA ZC4zU3lEZO5sfWjyCT9849KFHS4OeuxFgkEd/UGmkEDpx3qbyWIBLcilMRBABOM85PAFLlsHOmyq q4PbI60Ywc4J9utJjO0DFPxjjJ9yOaszQY9M9OaXGVAx9cdqMYwME/zNPHGBgnk5qdRiAew6cHNO AOSGIycnk/pQuSchTjqMClA4yQfy5oHqHHHHHfNAHJx3Gadg9wSMZxSYPoSD0Ap6WDqG3PUYHrS4 yQSMcdqdjC4IPHrR0wDnFCa2F11G4yRkDmngZ6kHHrRwQAFxz+NLySTtPtSuh2QAZOf60uzJ/XGa NpxnaR3pw9gRkfhTBeY0d8447inc55AxjrS9Scjr+tAGOoJHv2qbg03qKB7cfzpcdsCkGQxwDjti lwcZJ5pq2wWDAJBPPbilyCcY4NIByDgj0p2OvHbp70MQjZzjjBPNKOM+/I4o75PAoHXOTjsKNBbi 4ABOcijtgjBoAJPGcGlxxjnjvRZD0FxkkgAnHQUdgMZJPc0dc4HPTIpwBI9R2oYkxAcA5/EUuMjJ IIz0NGMjOT6GjA6AZPbNIdnuBGCQQevSjGSBz9KXkDk8j0peQeBnNHoJN9RBxjBANOx8oz+dGMgD GBQPu8g0wTDsBwaOwx2o5BBIH+FLgEHOMdqBsTgNnBzjrTgCW6Z9jRyAemOlJzgkDjOKLdhWdrju pGe3FGMjnJozg84PpmjBGM5x7UtRihSc9QcdqM4POTijp9KUdjkZ9xQtQ0QvPGDkEcmkx155pQOo yaQjnBzxzQlqDQvB7c56ilwMcnnPal6jpkgdKTggEDGKF3YrvYOSc8Y6Uo75wcelJnsc880Y6gg4 6/WjoF9QwONpOadgjqR7YpvUdMelOyOOMn2o3C6uIPQ9e5p3TkYOPWkwSOnPbNKB2yAcU1cGhOSC OPbFKD0HoeaXOFHH14o6c5z7UMFuLjv2pDnOM8H1NLyQMccdKMggcDI6Ugb1Dtz+nejuBkfTvQe3 bjtSgdSR9DijUAI6GgDnkZoGScUYOR1x7UX6AvMMjHXIyeO9Lj27UY+nfFKAemODQPXoNAAA4x68 U7GO4HHGaMYbgd+c0ZycAUPca2AA8g9aUADjIwO9J17ZPfml5DE8fShMT2EwM9iO1HY84PvRgMDk kU7GOTzR6BrYToMjnHXNLgfXvSY9iPWlAyaNQEwc9e1LjjJyKMAHnpjvR1BGcgGjUHuJjKjnHPSl 5yQCOKApx6+1HIJwPzoeorO9x2ARycn1pvYntmjHOAc+vpTuc/T9aAV7jQOOmfQijHUjpnp3pcEe 1Ls7jkkc8UMfoJgkdMD0zR+YycUmD1GcZpScDPUDpQtheQmMHBxnPNDZ28ijblt2M0uCRgZI96Fv cBMccYHHIoAAAx0Pr2oKkAn0HH0o6Yyc5ouMCCOOMfzoIIIzxxkUoHJzmgcnOCeOlGiYuonO0Z4z 6UAYwOvNLk545PpS7Djjrii4dRuMnBz9aTnv0pcEde3JowSCelNbBfWwcZGen0o4JH16UDBzwSBm gE8HpxxihJXBsCODxj0zSYOMjj3pSDk5we44oweM8D0zQCVwwAMEdaaRx2x2p2DgHJNHIHTiloLU TgAk9f5Un+Rmnc4OMU3AJxz9TRrcd9AwSTjnHajZgEjIP1pcZB9ewo53ZPI7UatB5iEfL70dWx0p cjpyTSYweDgnjmgNBMDJHFNxnGccU/qSO/GaNmSQRg+tCEu4zByemP50bcD2xSkHII449KMYJB5N Owa2EwCM5HGOvSmkZyMj29qdtBAJORS44xxjpSfkNDMEkYxwMgik2nBGcd6dz1GcYwAO9Lg4wBnp giiyYrWGDGcEA9jSbSDk8CpMck4460zjJxnBprYauMwCSeetLtGeBxinfw7TyPSk59+nFFxDdmCD zzSYAPOMdqdngHoKCOnAz70nqNbEe0beAMHrQMeg6VJjj0AFMwAckHGOlNdmOw3aMZ7DqPSmlQQS DgdQKkI+XjAz1+lNwckH1yeKNR6pDQoweMEjqaTZgZ9T2p/PU9O3FG3GCeh680hXaQzaCTgjPIJp uwY5NSEDrgUhHpgjv7UdB9CIoCcUbRnB49PapOvy547U3Hcdjzz0FF9At2Iyg4yP8KTaAxyOP0p+ Oo6CkC4BYjIz2p3G07DdgAGMAZ7d6aQBxzjOetSkkkdcHtRzkZ7eo5o6CMnAAK9DUsW0MDgYz65p jccnpmnISDxyPcUN6CtqW9i8dMd+MZpwRQegHsBQCTGOAad2U8g+pOKi5orAiLkArz7elP2LnG0Y B5zTRgdiMU4dSMZobYbCbFIHGM9sUuxQSNoODR1GOh4HHOKMAnggHHSjWwasaY0xyB+PTNG1ccgY Pp605geBjijAGOQR7dqNRDdijtkfyp2FGCRnmgc8dOuOKM44xkj2oQtAKjt/kUYU8dPb1pSTgZH6 0dgcdKaTDToJtAyAAMdqFAHBHOOmKd2780vYjnJ/OgNRBjntjrQQByDkUZ54yCPype3PSjXcL20E 9Ccep560pAB6Z75HajBJGCPyoIIGDg+9C8xW1EIB579cUgA7H86cCAxGPrSADHOSM8euKauS9xMD OMkd80pA5xnPv3oXnk9Pel4AJJJ44B6UBoIF+Xpn60AZGKcvTjOPQUoOAeCPai/cat0GY57Cn4BP HOelAU4yRRyAD69BTuF3ewgHOM55zTunQHmlxyAPSkG4jPbOOO9FhDsZxjJ9qMA9OP6UmSDxzSjA JJBP9KTbGkGBtINKACwHY0ZB460Y44Jzn9KF5ibYpA5A/WkwM4p2MnvSdyQfzppg3cMAH8expccG jGRwP/10Z6fSiwWYuBtBwcdaFA75I7UDocZzn0pc45x3paghcYOcgn0pON2TxS4+XP60Adzzn1oS HpuLjIGCcY9acEAO7gg8Gm8gHpgUoJGc5Pt2psWvQTA6kYwaMDOScHqKccHPBz3x1pp6dPpSBobz kkdT7U4DGCMZFGc9OBQMA55x34p62EkKCMEnr7UnQ9M+9L16ZGTSgEDnOM0DDnI9COlLgE4/+tRg bsZJxRgAk88e1ILhjABwfTpQOecClz0IzyelGAOOvPSgOgZxjI70dskEDPWlzznANB4OcfhTswE4 J47daXkd+cmkHQnHOe1LwevHuBRbQY3AJ5JHoadjAxjGfejB5A45zj1pcDPU570kJBzgdOfzowRw AQe5pcHNHr3FN36DTAAg5PajABJ6DtSkEg+lHrwfxpC0ExgHHPqT0oPIAyAfal6HsR1pPU80IPIM HBxkU7oMkUmOe5x7Uo+70A55o1GtBvGT1IoUDac5HPpTscnpil7HkZ7UaCGnBOeaCBgnHT+VKMgA ngHuaXAA5P0xSHoNGc9AQfWgnkYBpcdMZJIpOWAHQCn6C9BevUk+goHcHn0NLjgHrjsaTk84/DpR 5jVgHGc5H9aADznnnvS5yBnk0ZG7+WRQK4nI+np60Y9sZ7ZpRknqBj1FJwO5oAQZ5I5B4xS4yR0P pRxxyQc9aXPHvkfhQxITBGSDRnJAAOfWlyASM9uaO3I+mDQwa6icYGB06mjPAIJwaMc5564xS4Oe QMCgfTQTvnnHuaQ8gjnOeRil4JyCcDrR2JHTOCfSmha7CAHnsaMcde9KCCCQMfjQADySOKQeoEHv +dN6g4A/Gnk5HHIHemjjnA6elMA6EnpxScY4/Sl56nkHrS5wuBQC7sQnA4HJ6UncgjGKXIBxnr0o Gcknj1pBcQ8kEetBGWA5yKdt555HrTeACMZwelPWwLzDkk9D7ZpOMA8DHHWlycd896MDABzx14pL YBuAf60hAJBOQAadkAk+nTFGQTnIBzmjXYNLCZBwM454pOSetLgHoeTQCcHjBP60bAmN7YIyKMqO 2R0HNLkADOTn1FGcZx9T6UbjE2YHXA9x0pM8ccep9aevUE85oIAPcYPWnbQL6EeSRnOR2FHTp0x0 p+FJHHakAPTAxjpS1FcZz74zxQQQCcd+MU8gDoD9KMAnBGMjii4/MiIwo469KTHIBJ+nvUhXjJHG TznrShFycggZ5PcUJgRYIPAJx1owcHkZ9/SpdpOMDI5yDTSnB4Hoe9F9AIuM5GeOgo46DqexNSFC M84puwAdec8cdKEytSPByBjtQww2DnOM1JtJA/LPpTdmCctgdz6mhPUEu5G3OBjqeOKaRhh754qb Znnoe3vTVQluvqeKLvsCGEYGSDimjOAccZqTYDwSff6UnlnHB6ntRuGttSPHXAzngCjAAAwCRT9v UHOPYUMpwMf/AF6OgyI8Drj8aMnHIPp9akKAkA8kdeKNnB5P1zRdWsJGTgk4GRnsaFJBGfzo4xwc k+1HTgEjPGKHdhdXuXYv9WSDgCnYJU9T6GoYiCoBx0xzU2MdTj2zxUbMtajsEKM9adzgE54P6UzO cAED0FOGQwyR+NMV9LjuhJGc/Sg4BBOMD0p2Dkjjpz9KbjjnIzj6UaBdicgZzx696TODuHI7UvoM nnr7U3PTnke1P0BrS4uenHfJJoBBbIGOcfWgdTwcdeaXA28AZ9PSgBcfMTjI7c04A4568c1HjAyc E47UoBxnOfbFO4mkL90jP4ijocA849KP1PrjFBzx1I+lDsFx+eQDz6GkGRnIJzwKbjpjP1peh5PP vSsJC8cDOM9exoxkngYz1pByeue9GSOfU00FwzjHqTjpS4AGcE8dRSZyACMmlwQp5GBxRrYV+4YO AP1oJGAME0Lyx6596acZxkgnoaPUBw6nPTtS8Zyc/gKTJGAec8cilGSDzwPzoXcEgyT3wf5UfMDz kD1oOc8E+lOwQOT254701sPQb/F3+lPAHXJz7Uh7HrRgnp29aVriVx2SR0I/CkycE8ke/rRk4xk5 9e1OxjGT1FCYeoDHHBHqaAcDpwe+aQjIC557GlUEDHBxT8heQvHTml6g84poxnIPTrS54GTjJ5NK wdNReAODnI5oHbOfpS4+X1+lCjI5yPrQNXYuD2PFKOCQKQAk9zR34wMd800LZ6C4IAOR9O1LxjJ5 PpTQeTnGO1KRnHbvSsAq9CMZNL2yePY9KMYIJHNGMjGcHHOaNGUg6fMcnNGOc+vQelAycDOPQUdG ODx6UIT8g78DGOtKcFuT9TSYwD3FHBGR9KauJWDgHnr2OacSBjvzTcZI55p2Duxnj1pX1AMd8ZPt R0BGOfWj8elIenUnntTC2ovNLjPA4NIcHOMg9xS8k9OMUvQNgGR0I60YJx3ozke3t1pw4HJycc5F PUAwAOMgd6TkkYPJ6ClXkEdQTRnAHoDQ77j8g4GSeDQMnnsaMZODyetH8J56UkJoOpI6cUuMDH8q TkkdjS8HPOfWmAuSRz0zzSDoSQSCfWl6YwSMUegHr3oQ93oHBOe4pB14BHrS4Y8jGOuabxu6/rS0 sJJ31HDqQ2c460pIPfH0pOCw7cc0cD0H0oH1DA6Z5HNLgY6Z5oPTOSfoKOc5BJFAuodVB54pCSce nejkEY9eaXndyePcUadQQmevH0NLnHbj2o24Jzx6UdG5zjpR6AHJyASDRweMnPejt70A5IJzz3FA 9LBkAc//AFqMgjpnjmjjrjjvR3IBJ+tDEtgBJxjJPajBA7f4UfMMnPv+FHUcE+tArCYwACSeeppR 3yAR7UvHOTj2pOcjAAz3ovqUgxx6jvQAM8ZNKOpz+dNyQ3fnijpqIPTrmlHXnmjoKQ5xjHPrR0Fd 3FwcECkx14Ao5656UvGBnjPSjW41oAyCcfiMUZAI4PuKOQD+tNwQevNG4aXHcEdOh6UgwSQOfXnp S5JOM9BTSccdM8cU0+gNWFwSOvWlwADnmm5wOoA6UYOR1xS2AX5RgHrR35HFBIxzke1HbrgdsU1u KyGgY6ZPHpS5GMgd/SkyeueTS5YjjGPWj0G9wxknBHPJpoJwOnX86fy3pkU3HJ7HPakLzEwc9gfe jnJzjApcHjJJIoxk9unf0ofcEAGTkZHvSc4AIyOaXjr603BOcZz3FNeYdAHI6Z/wpeSCBwB19KTP UZwBQOmMH60hsVc4ySST6UuTnnkcfWgcY47dBQepHP0x0pMFsBI3dPz7CkydvHrRjnPXHf0pcZB6 nHXBoV7WC6GsAAAO/QUZODyOn60vUZJzj1/lSAjAOOfSmFkA68kEdsDpTckjgc5707HB5xn+dNx7 4xz9aEkO1wzyBnGfSkHBOTk0p5PYDucUYA57etL1DVCYPuB7U3HzADJGOhNO9xkDtnoKO3r3z7U7 j1vcbgZGTx3560hC8AEjuc0pGc9M9hjtSZHOc4PTihIQnHpSEZBwT6emKdkFSTgDpSYIHBOO3FC2 HsMI+XPJOMfSjocAnI6ntSkADkkUh4yD37g0X7jeo3IHGfyoxnPUHGB704qe/UCg5HvwKNLghmRg jp6cdaXjAIAPrmkycZ5x3OKMDJAOM8kGgL6WMkrgjGcEYppxuGQc9jSk4X7x/KkwcDJJHtTFoTQH DDOAM9+9WsA88fhVGIgPyMD3q+OAM8A+1S9yoy0G9xk8D2pw7dfoelB4IGcA/rQcgDtzjFSGo7pw Sc9fwo4PTIx70nO3GSCB+lLjOc4HpQMM9MnAx2pOScA8jpSE89+uKdg5OPwqkxaWsJ0GeeT0oHJy SAPSgkg8/wD6qX2OOnWmS3qIM7gSeD+NOBAPTPpTOAuDnFKMYA5BpIbsL3z0+vagcjg8D1oIyCKQ A4xgDJ4oe4tR3H4daDyRwfrSZO7BJ6YFOxwcgfnQnqHUToPfuaQnkc5HajOSRx159qUcA5zgU1sF 0IMZJyfel6tkHigdSCQAe1A74/Ki4aMXI55NIR3PXvRjkjFKOoBHWndNWEA464PsaMHOc49qdx1x +frRgADB/CldBYTtkZGQOtKMAZOTR3wOPWl4AHcmgSFzx9R0FBHAGCM0mf07AUmTxz09RTDqOzkY 9PSjHHTmjnqSB7AUcAemKSQaMcCMkZ57UYIyc0nAweeR2pc8jA5/WgXUBnGO3elPBJGCc0nPPOT3 o/iPqPanuVo9CTPA/nQcFcdqbwT26dqdwBnt6UKwraiYwTk5xSggHkZ749qB19D60gwSSTyRSvYe uw7Aye2eRQSPWlwPXH4UdBwOM09WLQXqcdT7UuAO9IAfXB9aXAzg5H49aLAGMDkjOaQ8g44pcDPJ J9jQRkd6OoXEBIGDnPrRnBIHX1peAO5pQDkH60wQcjHr14oJPHT3zSgY5GT9aOoBz+dKwMMHHpzR nJJ46+tGQDgED3o57c5oQ0nYMZHGfw5o79cmncHGBgjrSYwQcgHPFIQuMeh9qAOB9ego7cAAdzQO mc9aOo7BgA8jHOTRxnpjvSg5OCe3JpMcjPQGnoHkKMjJAP19qXBwOfw70enp3pcckjketHmJtidC CT9AKOpxj8fWjvk8elAABzn3pdR+ouADnIxSd+Rx60vU9/wpCMnA445p2AGJA4GaOoGe9KeOAc5o zycn26UJKwkxOc57ULye+P6Ud+2PWlHUjPFGltQ6hnBwQTSZz2I9eaVgCD0yKQDAHOTQh30sLgFe p680g4HPNLjAx3NG0g80mAZJOD07HNIOmePWlxgcnHcUvQDP16U9BLbUQEcZ+vWjqBxz7UAckYII 9qOvB4HrSuF7gAMHr9CelHuemODRjA6YpcDA5z3FAMM46E5/lS8gHkjj8qbnIOKMHjuO9AByR9aM HaOcDNL36ECkzyATz2FFgvoA+71574pSMZJzk9KT17k9adkY6deBQ7huN4xg+nrR1A60uARkjp7U nUnHJFGrFqGQOCfpSYyBzgZpeGAH50oxjnn0xTu0NMQ8jOcHFGQMZGT2pf59qTjOSQQKVxMMc5GB zzSc5znn3oJ45OATxQMgcYzQxq4mBkEgkZ/OlzkdCOtLgAjByaD1I7ULUQ3GMHIIFLxyB+dJwQAO OaXAGck8DtT1DQOScdAKaDgEU7hh64o4OcHB9KQdROeDmhevQn3oxwcZ96Q5BwO360MHuO6Egk4H IpqkZOMgH+dL655OaOh5+tGgeQnPrj0o4zkcY6ZpOTgEgjtRnjAzkUeYabC9ssOM03gnjIHfFKMH HPbI5pOV+p560LuDY8EAjOaTIBxxn0o+8AOhxRjB9eOpFBSfRh369+lGT16e4o4IOemacDxgdKTE nYQ4x0HtTD04Bz7mnH0PbrxR3xyPcU9LAr2GEkceh5FHcHAHuT0pcDcCeQTQQOcA5/pS9Ck9BueC Tj0pcY46cdBSdQACQc9qXuTgdO9PRh1GkjqRx/M005xjHXrTs4JB6HpxQOFx6+tAMaPvDIAyOp/l RgZIGRjkUHqDnj070nJGew9TSC7ExzyBkc496XkfgBxmlAByQQQT35pD1AwAex9aAXcTGMAHBHT3 puflGOvPalIOQM80jZxjrjr7UWd9Q6ADkHmm4688joKcSAOASO/FJn5sHBBprRj6DdxzjPB6gUZy QACecc07r1GSPT0pOhPt0FJILGN0OSM8fnSg5GB1HqOlITkZIGD2oGScdT+tVp0JQoPzYI4B6+tX kOVHBxiqJyDnoPTHerkRBUAgenvSbKjqyU4DAHPtmkyMDIHvzT+OpGc8ZJ7U3HU4/Cp9CtegZ5OA TjsKUgYyenem9sDinsffBPTmhXDUbyOmABx0pMjByQe5IpcAc5P4etAHPPAouhIQEdSRgmlyDweM +tGOBjB5puOTuHHfFMVrvUcOmMZOPzpcgZBGD7daTAwFGCevWgHJyT+FFtQ1sOwAeucjOKTIIzk+ 1HHGBjn1pMYGecdeKPMLaDs84zwehNJnJGPpQuSQMde9BODjOcdqaYmJ1GcgU/tg8f1pAMdcUE8e n1ouFgBGCDwc8UdTkDkdaCBtx1P8qB2/XNFkJJoMZOPxPNKCADnsPWkyCTx+FKCc9uO3pRawACD0 PPqadggdiPak7564PSlyOO3pRYNQ/wAk0KeT3oyfTJo45Jzj0FNAGcA+gNGcnHSjB9zxzQCQSc/p SHdC9xnH4UcAZxRnPUAfSl6DGMkdBTuSkNAPJyMe9Pzxx6daU4xgYB7+lJ6+h6CiwXF4B68fWlyS eOKb2PAxSg45PtQA7GDyR0/Cge2Cc8k0mcnOCf6UvTHHFIBRnPH4Gl+UAnI/+vTMYA54z3pQPx+t MCTOACQMd6M5OBg8dBSckYwAM9SaMDIPr6UgXmOAI789qO4yRnvS9DnOQKOCex5oBhzkk9PSjHfg D+VLnnGetHOSADT0H0Eyc47dMUZ44wKXHJ7ntSHrk/rQIOn8Qpe465NOwMfMBn2pv04x3o0GttQI 4HpmjjOADTh6EAj1NHUnHGKYWAZBznigAnAOKULxg8DilwAR6VIridSeaTuDxj607Azjvnk0h6jA pgn3FwM5xnj1o79hRnHbijAPB6fzph0F64xjPvRwCMHP0owQc9DRwPSkCDJI5POccCkAyB6etLkd PWl7nGKLBqJ0GCe/FOwCT6jrR0ByPpTed2M9Rmi47JoOmQPzozkgClyc4PpSD3xyeKLBa2gdDjk4 9aXqeOv0oxgE49e9AyMkZHfpRcA78nnp0pvQk5HWlz0P5mgYx/hRYGkOxz/WkOOnPPelxkc8AUme DnA96LdQu0wIyQe/vRjGOT6UoIAPekwNw7Y7ntSDQXGM9vUU3gkcHNOBGSSPrQMYOOSOn0oCwnPT gnFJzkA9+OKdyBntmlzwOlNCQgAAJ6nt9aTJxwe/NLwMHgZ6EUmOccfX1peYabC8npwKbjqcgfhT sjnHajueAeOlK4aWEweuMZowM4zz707PTj6ik4ySOfWmwDGVODgg+tIeo5we/vS4Bz6ijGce1CbE JjqQScUvb3NGMjPQ/Wg9+lP1DoJkkAH04poJzjH504gAAdT6UgyTk4HpR5D1TE6jGOe2KXBHXHPf vTioxjOO3FNJAGOfxpag9dRe4HJpOMkcYIowMAkZznvSEHrwB274oQmHAAJ69qXkgg9SaTjjdwPb mlxj8fzoBIMEHjt196Oc5A74xQvXJxjOKTgggdT15o8gDoMnp6Cjvk8D0oAwcAjgc5oPQEnGOetC QBjBBxn+lBxycgH0zRklc5460nbJAotYeontwefxpQevOPUUdMEY5pODnOBRYAwQx+nFGM4GKDyR kjGOtA4PPTFAuo7GOhBOaTIOQcCl7ZzQMZ9/ehIrdCDBxzwKTLYAwOvbvTsDBwee+aNpwDz7jNL1 Fa4mOcY5HWkzjJ4obhhjGaTgnOcEDOKECelkIcg5BGD/ADozk89eopePXBz6d6TgNnIzTWwLQbnk nvjk5oJAIJIAHFPJ4PQGkGCcjkjmj0HqNxn1Iz2owCMnOM0Y59s85NHAO7gZ68cUAtxueCQPxpp5 GM96fjAJyMHpQDzz0Ao1uPTqNwAoIxjPUUnUeo9SO1OycdAR65/pSY6njB9aOoITjPrxzTeg6U4A 4z19MdKbxnkEjtRvqgDkEjsBxim4HXJ5IxxT+Np/wpvU8dfSgLCY7Z5pMnIAIz3p5GCcYA6HPrTc dcc4oHpcxc5OM9R+NKAQuQOnTmkxnt24PrS+3GB+tArdAxhOvWrNvyeTnn8qgx3xn61LAcMOTj0x 0oeqGi1n5sEkfqBTiOOec+gpvODyQSOCBS84GMn/ABqSuo3C5I5BIxnpS5+6M59aP4s4x35p2CTk duKL9xah1bHoeeOtNIyANx4pcnBPPPfNKODkULYbGA49SOlL0yCfel4yTn9KTsTgGmLqAJHAHA5p 2AST69aTPJ44x1peRg9R14ob0C2g31yT1/KnAjGBjBHajkkEggZ9aOQTmhWJ9BO2RwPWkGB0OQfa n8Yxk+1IMDI6+nPWgNWGBnjNHGOp+tJnJ4xmlHU9CMUwTs7AMZxk/hS89R2PNHY4AyOlJk5znH0o 6A3qKSM+oFGABxnFABB/SnYyAcfUUaC8hg65zgU8Yz3z9abxzjr1wadnjknmn10AOM9fajJ46Y7i lyM8frTSDn0+lA7odg5zwDz26UZGRzweppOTkUYwMZOe1CtYWlxcYNKOW6mjJPuDS4oVrAr3Fxg8 jvyOtIO5BFAyOoyOaUEEdMegzSuFhBjBz19+lOxgdfrxQMnrz2peCefSmGu4nIPfFLkEEDIIpO+e g7U7OBk80ai8xOoAzn1NL3PTijnvg0uCOe/ehsBDyMnj6U7sOcjFJ1JAzml56YP50vId1YcAeegB PajoCB1pB06HPrineuefSncVuoozgcDPvS9ieAaYDhfUmnYBweTS6hoJj3NByOc9qXuQOfTNBOeO /rVAGCScZzinAEkdgaM5bnpjtSggdBx9aQ9LiADPOSKMAcjNO+goAJAwCDnvRpcQ0c+vPenAHoTx /KgAj256UuCR0OaGtQG4APTIJ9acevc96UBjj5STnpg07yZTjCN35waA1GcE5JPTpQMAckn09KlF tMRkQvnvgGnCzuT/AMsZCP8AdNA3chIyPT2zSYA5I5ParP2C6IP7lyB7VINOuyf9Q+O2RT1Ap8Z6 dunpS9SeRnsat/2ZebsiBunqKP7LvBx5Bx7kClYNSnwABn8zRjnJA+gq6NNujwyqpHYsKd/ZVwO8 Y6dXFOwkyjgFhwDSdyOOK0P7KmH/AC0jH1ak/sqTvNEPbdTSY29SiMEZI4o6jj1q/wD2b63EIH1N N+xIME3kI9Rk0uVk3RSJz2zjrRkFSSOaum2t1630IJPQ03ybEZLahGB3AH/16ai7gpIp5wAcfhmj HGO9W9mmY+bUUBzjgD/Gq9yYIkLQzrKOoAGKOVoaldjcZOASPekIPTiqa6khbBBHPOato6uAwwQa llW6seoGe+KMgHj8qTkEcil757CgSYnIJHSjuOfwNKAR06ntSEkNzS1uFtRcc8Hp0Ao4PrilHWkw Qc9u1DQLzExzgfjQQAeCTntS4wePxzR1OOv6ULzDYTjGecjtml4I7Amg5IOR9eKMEexoa1FoIRz3 460DGe4z70vOeD+FH696LBZCcA9yMUKBgY70cEYPX0FGB7jHSgENOCeOOaX0zgjPSlHAIPWkzwOB +FG4JicevFHGT9OOetLhiO1NJ5B4HPpR1C7F52joDnmkx70pGO/tRwoJ69ulGgnZhnApOc8E80d+ enpSgcDPIzxQrD6CdPTil4yDg0EA9ATmggjBHA9c0BYaSO54zQFwecEYoIOeeTS4zjtg889aGxK+ 7EPIzxnOOaOwyM/SjLDAxx6Upz+P8qLghDnGeQBSdfU57GjtnNHINHUSD26fypM4/P8AKlJzg4OP SjjBA6Z6Gi2g7CjJxxkc496Ontx+NLye3UcU3oM5/KjQF2Dpk5wDRng4J4HXNO5IJ6Y603qCQMZ9 6N9Bpjcgg85PalwSD+maU4JPGAP1owQMYOTzQ9ASEI+UDIFIBxnAIPvRggk9vSnY+XHTHvRfQQ3B 6cAU3HTaec9MU7vk9jR1Izgk9PalZrUq/Rjc4GOTzk+lKvGOO/TFIehHoeBQM5HJyOOvSmAjdeAO e9JnHB/KlI5znnHAxR07596LobTG5A4PQ+lBIOCf0o5PA6j1owMEkDPTNHqCfQbnPTPuaTPUEn2p +Bk4JBx0z1NJg5I5A9aE0CGsCDjgD1z1ozgHsfTNLgZweaToDjAHbnv60K1xvyAAk5JP0FNIB5z9 acTx056gikB5Ixz1+lJBYwlPyAgHp3pwIOD0PPGaq2j5jAznjpVrceAAc+pHQVTS6iWqFyAAAT1z T0PzbvU9PSmgjkkcdM5pR1yM5FK+gdS8hO0HkdgaeCCMgHP0qKJiV65HBHtUuRkYyMelSUrhgEn0 x0o4De+eKMgZ6g+vrRzkEkYznikkP1F6DgcetNJI6HBA6UEndjHXoKUEgcZPNNNEsbkY546UbcZO cZ5GKUggZPINNJwScYo1GPBHTnHejqcDn8Kb0J4P9RTgTg4OAfajcV+4EdTyaACcjp35HSgE84PU d6P4eDk96aVtAbDJAxnk9Qabnpjt607I6nnij2A47cUuodLCZBHr/Slyc4PORQex2jn2pCTnPJPY CqFbqKTznB/CkzkccGl7Dr+PSkUg57Yo6WC7HZweBkAd+9GTjGDik74HB70A5OfelbQQ7I7daUA5 5Jx2pOOnTnqaQ8dPrT0sD2H9hxnHU0dMg4xnmgHIAAJ45NB79Afr0oF1DncR2pRndmm9STk5pcH0 J9xRcdhQRjBPJpRjjGc+/ek4zk56dqXnI9fWnqIXqepAxRxxz0poPckH6U/jgg0rWBsOh74oz3I7 4FJz9RS555HFMEOIwOR37Uh9hg0meeuadkHI59qA8gA5PXr1pRx1x7UgBOeTil7j1B60agx2Oec8 0DBA/lTcnJ5/OnKecYIFCBbCg8AHnHejkcdR2pP4jgc96XkHGOO/NHUY7gEnHJoyAee9N9SefSnY yBx2oWoaFWTW7CynInR5CB0ApP8AhLNLHSyP1I7fnWLrlptYyjHXsOlZthAl3exQSyCNWYAtitYx TIlJrVHXDxhp2MiwyexIFKPGVpgkaevsMCur034YaTc20c4mkKsowM9T61qRfCbReDIXI/3j/jXT 9UZk6yOA/wCE0hxkacgPuB/hTB43GQPsMYPuB/hXpkfwq0BMlo2Y/wC8f8atJ8L/AA4MD7MD7kk/ 1o+qide55UfGsx+7aR/px+lJ/wAJpeZJFvEB7CvY0+GXhoAYs19+vNTj4deGlwRYRk98jrR9XQva s8QfxtqAGFSMY64FQ/8ACb6q2cFAfTFe7/8ACAeGhx/ZsHHUlQamTwN4cQ/LpcGe3yD/AAp+wihe 2Z4F/wAJnrDYAdB9BTG8W6weswH0FfQ6eDPDy5xptv8AjGOanTwpoSEY0+3wO2wUexiL2rsfNv8A wk2suTi4b6BaQ+IdZbgTv9AOa+l10DRkckWFuMdPkFTrpekxjiyh/BQKfsogqrPmH+19ePKzTnns poN/4hfkNeHsMIf8K+o/smmovFrEcf7Ip0dpYIh226DPJ+UUeziL2zufLG7xE4J23p6c7G/wqQWf id1H7m+PPHynrX1D5doNoFsgycnIHFSbLYDiJAM5+6Kfs4i9q7ny4dG8TuTm1viR6gipF8M+LJTn 7FeAkdST0/Ovp/Zb4+6vqBin5iAA2j8qOSN9A9pqfMQ8F+K362Vxzzy2P61Ivw/8VOeLKTnrlxX0 4HjP8IPocU7emQMAH0xT5Y9hOoz5oX4b+KWIH2IgDuZKnX4WeJz1tUHGTmSvpLevBAGc+lO38Hgc 9zU8sewe0fQ+X9V8Ba3ommtf3kKLCpAOGyea5yOV4jwSBnpmvqLxnYnUvDF7BgH92SBjuK+XHjKM VbqCRjHepnFWuaQk2aOc4IOcj861NMlOWQnI7cVkQENAvPTir2nvsus5PIwc1xyWp2x1ibmAccd6 Tv6c0ZxzgYHTBpGY8bQTkgAAVGpNugucHngA1YjsrmYZjhOD0JOBWhpWmK5Mk4DN6EcD6V0kECIw UAYHHHepctTWNNvc486TfoM+WpB6c9apSRXcLEPA34HNehvGA5AXIPA9qz7+AI6gJ168dKLj9nG+ pwYvFDFXDIfcVZR1kGVYE+tblzpUMilmTJB7ismfSUwWgkMbjt2NPmJlTdtCPsSOTSc5PNUXlubR yJlJGevarUMqyx5B689aa1RnytbkuBxwc0meTk4x2xRzgYznPFJ1Oe+OlCDUUA9evPNJn0xkdqMH qc464FNzgggkZ6/SjcWw4jPTnijHPQEDvQT74/rSYAzzxQhLzF6MB6+lN6ZyaOTz+tKc4HHB70ML oTg4JozkYB5zRg8cdfSk6DnFO4IMDqcnmlJzng+1JkZ4zxR1xk/pQFuwuTgEnjGKTPFKfQ80mBkc c9jSv0BXuA5zgceg60A846HuKM8+hHcUZPp6/hQg62EOR/jQDySRxSZGAOaUEAHqTQJ3DHJyM596 TIAzjpQScA9KCcdcc+3Wgdw7Yzg4oB4yRyPyoycccE9qB6YyMUbCv2FySB7d6XAORnOPWmhcnI6G lxwcDBPHNJ7FWEzgEEHk0Z56/h6UpJ4I6AYpM/ICOTnv3phsJkDvxS5zjrxSeuc47YpMELnrg9qQ Ck5JP9KMgrzyc80nQ5xRyV6AAmi4NaB1zgZJFJ8oGOgzj6UudpOBj154ppOAMH8KE2NJWsKcjrkj 86b1yCcY9e1KR3Bxx0pOTzkfjT0DzDJ3EA9Ogo5wORnFLn25zTfmBJGD2pDvpqHQ9uR9aOQPQe/e lOM9Bn2puAQDk9fyo1ErtCZ5II4HNH1PfgAd6MHt065pMjGMkDuMUJajshO/HGPWnHAPT8PSm9By c4HSj3PHNHkCYZIwOevGabyHBzjv9KCCc45P0owBwBkgYz701tcN2cpYuMgHArQz1x6dc1kWbkSB fTkitYAHBII9KuS1Ji9By4OQTz3p3AzyfcGk4wM9MU5VB6moQ7FiAg4GTjvx2qwO2M1WiOOM1aGC Mjp7HpUyKiwwcYyDkdPegg7eRjB4pccDAwfSjnJAznr/APWqU9Bu+4nBIGMn6Uh4IxwKXsOx/pTc 5zjIp+YeodRgA0gHvj3pc49/rQOpycc96dmLroGcA46Hp70uAAMD9KTA6jJ5pw5GcfSnawCcgjjA PWk4IJwCD0p3bByPQ03qSAMfWi+gtkOA5x6dqOfTnPWkA6Cl6EnOKPMHsITyCDxSgkY6nj0po684 pc5IwecU1YVxRyOhOO1HJOB37UmOSM8j2peM8Hg9qGFxec4z0oHUDGBnnApMEMTjj2pcDrzQF9Rc A+vH8qXI9CMikGMEjj6UvUD0oFcAcjnII6UvfgE56ZpBgdjSnAIJOO1PyBK44cHBzjHakHXsO1Jw STn2pwJxwKXQSA4HvRgjk/TFAB9iM0vUHnGDRfQaDAB6f/WoyOf50oznpk/zo44yOnXPrQCQDBAG fwpcADnkigcA56Cl7DnPrTC3QMZ6Yzjmk5x6Gl4BPIwPSlyMZ4/KgL9AzhuvbtRg88gDsKB0GQAO 9GAeeoFGoC9AD270o5Hpj3o7dsE8jHagHjHGaLaBoB9e/rRyeMce9HXqeaONp7nNIAwCeSCB2pcD r1GeBSZGBwc/zpxGT3Ap6DtoVry2E9uy8HI6YrjZke3uSvIIPFd3jJ7YrnNesip85AAO+KuDdyJL Q9O+HHiE3tiLaR8yIAME816IshGBnNfOHg/W30bXI3LERuQGHbPrX0RaXMdzbRzRtkMoOfSvVpT5 46nFONmXhITnJNKJW3YwcVCGGD0pyydMYNaNGencuq77cjrQZXznFNVyAOlIzdRWdtRt6D97NyD1 96TfLk4pocA8DBFPEmVJwKCbi7piBgjmnK0oYBjgGkEgyDjil35II6/SkwuiTgNjJJNLsyen40IN 3OeRUoBPBqXuWldXGLEPqfSnkDI4wafjkHFLg8n0qWwSRHsHAKigKMkYFS7T3FBTDDjj2ouFkRBB n0/CnbBjoKeFOeRxTgh3Z459qTYDADjgD8Kac5BwanCHJNIUODgc9hRcb2IwCeBzxzTxz2zSqmB6 E1IFwcUmxJaEE0Ilt2QgEMCCK+VfE9kdP8R39sVI2ykgY7E5FfWgXPAFfPfxe0k2XikXSqQtwucj 1HWpk04lwdmcFZn5WXHIwQM1cibZOrAYwc1Qtztn54BGOlW+Qe3B4rjqLW6O+m/dsdJvGxWxnjOK uaXbiWYTsCVB4BrOt8zwRKvVhjNdJaQ+VbqFGAOMdc1lJ6GtOKvc0o0KwljwOo5qaIvuD5JHp/hU aEiME4xnkGpEJeIBT0JrPU266luGUuxGeO+R0qO4APzMQQOhqKI43DOD3Peo5JwFwvIHXNFmJ7kF zt5GeT1BrLukxEdpI6c1NNueQMzdOwqB3DgDIIzxVJCbRQugki7WAII5B9a54s1ldHklT2zW/cAD JGDg/pWJqADruAyQc8VS8yZJGlDIJIwwJOfzpx69xWZpk5IK5yMfkK1M9/yzT8zB6CYIOcZFGOpO KXnHtTeAueozRoLUO9HbI59qP1pDwRnn3o2QdQyQBwfajqOv0pfU9T2pMHAB4yOadxNBx3HShhkD nHHBozg468d6CPl9O2KQWYmBkZBHHpR0AI5A6AUpGeCME8fSlx8oGc49Kd2CfQYeTnv/ADpQcHr2 peO+AMUnQjkfl0paB6BwSTim8A8gmnE496Ceev0GKdguxvXPUE96MY4xS4yMjH09KX0yf/r0rWC4 0nAOOfWjqD164o4yCTj0xQADyQcZ/OmhK4hJB4zzSgnnuP5UZBx39DThkDnPPShjVt0NzgZI4pc+ mcHrmjkkDIA9aTIA4PXpS6jFUYPXg+tHTrk+lJ1JOOtBzj+lDQg9MjOTRxyB+tHA/rSdFJyBnjmh XGthPr0/nScde1Ke2SOOnFGTkjHHfPFK2ugXTGkZwR0o46Ec9jS8ZwCTg8UhOB1APrinYA4JPQDF N7nByPTFL6EHFHGMEjOaLAthMZx2pOnOck/zpx9RSY6nPWjyHYMEEZAyelIwwCM4/HpS5GARniky MjBzR0BDcjOCcDqTik98ZPf3p3A4656UEZIyD19aXSw1uI3AwAAT0GKTJwBxjvxTjzg4wOw9KYO4 9DxjvTSsJ7gVHHOD7UnAboc8jOKd3PJB+lHTHUYNDtYexw8L7JARge3rWxG4K5wDgY5NYhOcEHAx zWjZyA4B6H8a1mrq5nF6l/k9MjI6GnHjAJxmkBJHAOB0+lLjOOh96yu7mm5JECGA6DtmrowB1Gao LjI5OeOfQVdQnGeMA/lUyGiTHIOcg8fSggngHHXNAAJwR1HWlHGO/PNTqVdDBgYOOaMZwcfjS9yc mmnlvl6e9NaaCfYU9fUD0pMc9Pxox04/AUvqQOO3NO4LQaPu84IHSndPX8KaMDkg0pxxwST0FMQu DkEjjPHNLg8nvSbc+uaMEkfrRawNaAcgZxmm9f65pwBIHoelBGOc4Pai4vMQDIwcYowOcfypevXr 60FcdMEepp+YABkdAcdaMY/pSDgknoeo70vQHGaTYegvOTnjpRkZGQfwoAJ5JHPrS45wfwxT0EJz yOg70vIGOh9+lGMjJyfTmgZxkgegoW4mL07c/wA6U8k8c9eaTnAzx9aMjIB6CjcBcHJPQU4cDAHN N7Z7U7jIznNFwuGAACc8ntS8EkYIpM4zkfSnZI5BzTsCQncZ4OeopcDgcgY70c7s/nmjr0FIEHBG ORil6cHge1GTx04oGd3QdM/SnqGzDA64FO42jI+lJnGcg0ZyecYzSTHZbignGMDr+lKAe5GPSjkc YGOmaQ9ST+tAK1h3WjoM54B6d6CTgYHFHJ54J7ihXFsGcgEfjSjFBHc4xjoKByBxmmF+omeg70o9 eM9qCOR6Ue+cUPsF7i9jng+tV7qATwshAPHcVY7HvSY46c96E7A0jhbmJra4KkEFTxXs/wAOfEK3 +li0lYmaMAcmvMtfsiAJ1GPXjrSeENXbSNbhmJIichXweMZ613YepytXOWtC8dD6IE4z0P1qRZQD kZOaZBEtxbxzI4KuoIwPWphbAEfMQPpXoXiefyz2LKXA2g4PTijzQTzx+NEVsuMbiaebZAclj17V npcrlnYYJDg4FAlHTHPpmrC2yBSSWxTPsybs7jg+1CaFyzY1ZwAT1FSLPkEAcUfZkyBkmpBboBjn P1pNxBQmC3OwHAyfep4LnzQQRgiohbJjnOacsKRtuUEHvk1Dsy4xmtycyuCQCoHbNNM8nXcgzUUh UnhSW+vajZ8oJhB/HpSshyunZEwnbqXT86PNYn/WoBUYiwMCBR+NKsbA8W6c+4oshaknnt185B9K XziD/r1phRgf9RGKUwyBQRDHyenpS0F7yHCcnP8ApAH4U4TDgmbJ74FNRJf+eUYFKBJ3VB9BSshq 5ZR+M5yO3FSB88Y5qtlhgHHPHAp+8AgjqOtQ0aJ6FjceMda8q+ONkW0G2v0UFoZQGOOxH/6q9TEn HT6Zrl/iBp39r+DNRtwgZhGWX6jkUkik9T5cinYEEjODya0yOcjByMisRZGQBSB154rZgzNFHjkt gdO9c1RHdSZ1Hh2AyJubIA4X6V2VvGqxjB47g9qyNItvs9pHhcEAfjWoqEAsTgnoK5mm2diaiiQh TuQHPPBFWBFHDCD146epqn90g7skntSmVyAN5OOme1JJidRboexPzMMgH2qvIQGIJyT2p7SuBjcD 6iq0hJfeMZAp2BTT3K8oJOTjHIxmqr5AKgAccVLdSEKWKHOOCPWqgZ5Ii3U4xz2p2E2rFWVgVPGS TgiqLwBlK56A5Bq4EPmfNzzyKjKAsx6Y60AtdEYduxiuCOwOPwrezlc4rBvFMU4I4DVr2MhltwT1 HBzT9DKSSLHJHGR7mm4JJxxj170rHjk/XFGOmPXvRYz6hjgg8Ed/Wm4HNLjII96Qg5I4JFPoMOAM Y/WjnjjNLg4HFJnH40uoncXqMAcjpikx6885o5Ax7dqUcjHQ470/Qeg0k8n9KXvnp+NHHAo5B9jw TQxddA4LDIzijBbp1zQcbuKTJAPb0NJLQLdQxgnHUj86TBwCePXFKSSQR170HIJ4PNFgdrB2xwM9 6P4QD074ppye2e3NO5AGMjnoadg0sJnGO4pO+TyCeM0oyMcjnvSAE9cGlcFYBwPfrTuSR3AHrSLw CAMdKXjJHFF7gHfIGSB1o6HjAPejB3YpMkEHn3oWgXDJHT/69AHU/lSHkg+nXFHbIyQRijXoPzDA x3J7ChiSoyPbFHfBBAoyMnGfajUQ3BxnggdKOMdB68045B69uhphyCelGlx9BTgA+lNwSOv4U704 5pvcDk0J6BZ9BuQR6c+lLjtjGT1pcEHjpntSM2GBwD7UDDgdM89MGgnI7ADtR1OTxz1owep6DrRu JCDAAODz60dc4wCDz7Ug5JGeO1BGevr0AzSHddAzgkYOR60mD1Hp3pSRgjHHr1pOMAc4PNCHoxuQ G5OTigYGOADmggZPY46kdqMg4xz2p9dQ6ARnPAFBGcgZAAxRg4I/lRyDgkkGl6jvc4PuOABj86s2 z4Ygnvx7VUz+R7YqxaA/aBhdwzyD0NdEn0Mdbm2gzGOc596fjk4yTV62ltjEFe3UnHc9anBsiwJg IA9D1rB3NVsZgGCD1PpVyIZXkA/hVrZYMw/dsPXB6VqWUOilcSiYH1B6Um32KilcxgCT0x9aXHTr k9vauk+xaCcbbiZfUECg6ZoxGEv3X0yBxWXM7lqKOZ2nOB09DRtz3/AV0h0bTTkrqQBHByvQ03+w rU/c1GP6kU+byFynPFSCD2A/Cm4OOeRXRnw6pHyX0B7896b/AMI1Ifu3ELY9DRzCt2Od2jAJxxS4 +UDv7Gt8+G7kcB4jx/epn/COXYJICH6NT5g5GYWO+SPajDc4I/Ktr/hHr3dgIpJ7BhmmtoF+g5hJ 9ACDVKa6i5WjI4Ao4PP8+9aLaLeqCTbuRnsKgbT7lePIfOcdKLoWtyrjjPFL3PIHtUxtJ0xmNvoR TfLYZyCD9Kd+gNDOx4pMgqMDnvnvUhTjJHPrTQmCeD9cdKLroLoIoORnv1Aox24z/SlwScdqNpzg 55FMVkkNwQev6UY5BBp+CD049aTaDz29c0XBbaicZzS8AZx060bDkHvTsAnB/EUDS7jcAnvg07HG c4xQBjH60cEnkEelAkgAzg8kk0o6dRwaOg79eMUbR0zzR1E0KCMn1xQBgZ65NOCnPPHH5031HpQA DGQaMEZ5Ht7UuD6CjGSOhOelCTH5ikds5oxnp27UvJGO/X8KGxjpjigBMHBJ6D1pR0Gc/SlAwM8H 3NGRke3emL0FzgdARR1IIIFJkHml6HoaQB7DkUY78cUvAGeRikzwPWn1HZdBe+Og96MY6kUm7IIP XNO6gY6H1osC2Fx3IyPakOCfQUevrRgHk8c0IWtiO4iW4gMTAEEdCK4q5ha2naMjGD+ldzwM+3es LX7MMouFAyDyR1rSErOxMldHp3wy8Si/0safO5M0AAGTyRXoO8+nHvXzR4W1ptD12G5ViFJAcDuC a+jLO7S7tYp0IKyKCCO+RXp0Z80dTjqRszQik55/KpSSKrRkZznmrC5bOatrUjfQV5XVcAjGKi85 sY3cVGzjcR6Gk3KeMZNNRRk2yfzmIznjvUkU5LAMePaqhfkgHrTgSAPXNDSJUnctNIRJt3HFSxuc YJJ5qs3MYcA09HIYZHGKhrQq7uW8naSOvrTA8p/iB9eKYwJGVJx6Cl+YAcNmkVZt3Hs05HDqB9Kd mYdJBx6CmDdtyVJwfWnjOQSrAVLC2g7ZPgHzRnPpS+XO2QZuB7UzrnhgPrUm3kAKeevNIOVNiCOb GPOPPA4p3lOODOcDsBSKoHO09fWnBcsPkPc5zQOw/YVXJbce1OU8ZIH1NR8nkJnHTmqt7fNasoMJ bI7HpQotuw1orsvq5JpJ0WWBomwQykEexFZf9rsFyLY9OMsKQaxIZFH2Y5PcnpT9nK5PPG58s+Ib M6Z4g1C02gCKdgPpnj9K0/C0aXNwFkxiP5gD3rT+KtmYPG1xcKm2O5UOMDgkDB/pWD4fk8vUVG7b 5gwfauWtFrRnbRk9GerRyqIlCgDgdqcN0gyASPUmo7FIpbRQp+YcH1qOV5oGIGQPSuPyOx3vqTtF IoJ4Ix2qEbs8k57U6DUFLBZM56VLcRErvj5U9MUWJRA8cpx8pweuKrnhsdCDzmni5aN8E/h2qeRo 54xkAE85FDTBWKMkoJKkZqAxqwJ6DHanvhHIUEgn9ajc4j245J5NMNblR7aUMZE5GOQe9VJQEJPQ 4wRW0MCMKQfwqs8ayAqwDAnuKVrj5rI5W+Vntg2OQcmp9Jl6pnrzWjdWEUkckcYKg9D1FZkVpPYy bmUsg6lef0p2sJtSRrGmkEgHuKbFOkoyjg+o9KdkgcnP4UiHogHQ46980YA54OaTgDPr1pPvHOeC RT1AU8HrmjjAz0pSMYI55xzSZwCD9aVhB7HPXqaCOAecUm7gHGBS89M45oH1DjI46UHOCOo/lS98 nFJgHimTpcTIBI6ZpfQ9T7UAYPrRnAAHB74pDEPWm8ZJBOCM0/JJ4P400ggEnnFO7CwgPJHQY6+t LkEjryep7UY5oz0xjP50vMLW2E4IJzj/ABoz8wweO9GBjpz6Zo9wPrRsLUcOpPJGKO2c8U3vwP0p 5I6Dik+4/QQEdc49PejGcY5pM8npSnB6DPFPSwJK2oZA6EZxSZyvGc0uDyTTTnOM4oB2A5wccnA5 o5x1we/FJycgk0vAYA8cfrSXca2G9QT1OO9JnjPBp3GO5GaTjAPQZ4NCWoCAcHg8Uirg9QR6U7AO Qfryab0zg4/pRYFuGME4I+gNJwT0xjvTuOuc+5pDzj1BzxQvIdhOpOc/SggjjPXtilPJyCM0mARn vR1CwhB74Bx2oyCQQfajnGM579KMYIbpjkU9LWDUTgDBx070HGBgA0pyV579DjpSZAwQM89R2oHo HQ4A7c0zBAPGPSnYwD1APINGTnPTHr3NGvUVncQjC8kA+1NwQR0/DvTsAk9Pxo689ecCl0uNpHnx zyeuPar1lKqMCTgnrVPGSOcD61IuUYEc856V0NGWx1cTB4wRg471Jz3554ArFtbxyAowMd25xWjH OxbJKsCMcDv61k07lp3RbBwB0B7CrMGT36nqKrggjOOCMVLCTkAHknFJjSW5aUnJ4GehJFPODycf lTR97Hv0p4HUYJ71BSGcEduTTckk9sfyp5GGx074pMHJPTimrCe1gLsACCfcg0CZ8EhmHpzRkkcY zRwTjGQPT1qtLCY4XEo481hx6mni5uAuRM/rwTUG0gZwTzilxkHkY70WQLsib7Xc8Hznznrk5qUX 90DxO5P16VUxzg0vXAzz9KNOwtS7/ad4BgTMR1pP7UuwTmTd+FVRg9s8UY56EGmkrA21qXf7UuAu W2k+pFH9pyMMNFGSe5AqlwCOcdaUnGeMY65FLlXYHJ2Lv9oDODbRkA9wKd9rgfraJ+AqjjAPf3NO AGOepo5UHNLYuebabTm3HPTFNIsHGfKI9arcdjzS5IHtmjlVw5n1JzBp5HRsd8037JZHOJSB9KiI +uP1owNpPOO4o5UHN0JPsFqcET5PvThpkbZKyqQexqLAJ4HFOzkAZOc9qOQFLUd/ZRzgSITjoKYd KlB424+tPBIOc4B9DTt7cfMc59aHFhzFf+zLgZwufcUz+zpx/wAszmrwlcfxkfjThPLk4cgj3o5W PmW5m/Yps/cJppt3BOVbPfitYXMwJG4En1FP+0Oc5Cn2Io5WLmRiGJucgg9uKTaeDit0Tk9UQ/UU F4yMGFT+FNJhzIwthyAaTBHUdB2FbuLdyMwgH2o8u0J5jPvSswVrmEQcHH50u0kjtW39mtDkYZfc U02NseA7A/SizuFluY+04GBnnnFGOnBxWx/Z8JBAlGR6ik/spSSQ65z60tR6mQM9Mc570ZOTx0rV OlN2ZTx0zUZ0qbsAR7Gi76h1M3Byf60qgcZBrQOmXGf9WcVH9hnQ8xEjtxTuO2pVwcHPU9DRzjnj FWPs0oHKkfhUbQOOdpIPbHWkS0yPrmmSxCWFkIByMGp/LYMOOelHlkcgHPemn1CzscDeW7W106MM YJIr2H4X+IPt+nHTZmJmgHy5PVa8/wDEFgJIROg+ZevHOKq+FNUfRNcgvAxCA4kAPUHrXZQqaowq R0PpaNRgY9KshMRk9Kp2M0d3bRXEbZjkUMCO4Iq4xyAATgV3N6nI+5WlU4JAzk81GAfTFXAAAMkm lEYz9aFKxDi27oqAH0/SnKG3ZNWvKHqPrTvLUZ6E49KHIXs33I4QXBTnpSoDkr3FTIFBzwBU6CLc eRn9alsfKyAFwAFOKdvkAJPB7DFWAqnPIGO4pxjQk4Ykd+ahsbiyl5soYfX0qaR5QoYZx3p7w4GV bJ9xTkA24Yjr0zRcEnci3vgYIHFIJZgfU1a+QDllA6nmlBi4IZfzFK/kHK77lMSTEjOQPTFSxSS+ ZhskY4OKs4jP8YHHbFN2KSSZcY6cihyXYFFpkhBwCOc+1VLizadt2c47GpjhVwsg69SRSrkgASL7 kkUldalc2upDFp4CYkGSemO1OfToSc7T+dW1VUyXnUj3IpxlhwR5q4+oqed3Ha/Q8Y+NuiKmmWOp QoQUlMbnPYjI/UV5BaOYrhJBjKkZr6T+JdhDqfge/jSRGkjUSoMjkqc/yr5tVNucioqXerN6bsj0 3TJnWIOmQCAevqK2BcpOAHUZxXO+HJRdafGM4IXB59K1PLYHAz7EVwNWZ3XbSYt1ZLkvHwc9Kitr x4G8uQkqeOanRyhw2aguIA43KR7cU1tYl9ye6iR13pjB56VTjkMb4OcHpT7W4IzE5JHTNMuI9rE9 +1NX6idrXRKUV5M9AeTTZo1CgHGB0NRqSY+OoFQSlivBPFJId9Lg5eME5yM9qr+eNxOPpn1p/mFs BgCAPypGRSpAx7U1uTfqQ5yOo5qvev5Vq56HHWpWUg4B6dM1m6s7LbhCfvHn8Kp7Cje5X0lSWkkJ 9hWnz0qrpyCK1UjgtyatdjyBUDk9Rc4B7+1JyBn1owTz/KjHHXFAumoZyCO9GeMHr60deMY9fejH 4+1Aa2E9PWlOSOOCKQYzSgD60DQAnHPWjPQEY/rS9Dz37UnfqPw60WFYTnPXJo5GSMc9/SlIJHX9 KBjqOeOmaOoaCc46Gkzg+54wO1KSSueSM9qOcHGDzxQHUCeDj1xRjkHOMdqMDA6g0gAzjBB9aQr3 AnIGD29KTOW6gjHSndOuDk8UmBkY45xQMUDnP40ZJ4OM54NHy8j8ue1Gc0dR9A7EHGP60mfTg96U nI4PHfNJgd+R2pIWrYvbHtTTnrkHinHJ6cU3HH0pj02EA55574oPXkClweuCR2o6jpg0AIenPHNN 9sgDtS4PpwOtBHAOBgnnFHmCsAyPr9KQnI59KXI6nt0FISSOlHUeghJwceo4pMjJwMZHWn5yeg4p OMHOPyo0FfUbjgdj6UZwc9eDxS9wc0mRkjqccCjQEBP0yRSY5yR14zmlwByRRjABxx3xQhvcQ5Ge p6ZowPXApcZPSggAYGTk45FFxsaRgA88jjmkB+mfen4yc4HcU0jI9BRrcaY1uv174o54IJA+lO7g Hoe/XFGMZGST9aLC63RxEEYY8qCMHtVqCBZJQoUH1IHSmJhTj8OO9WrVwkmRnJNbSehmjZt9HgeM EghjUr6fLbqWCBl68Dmp7SXzVyDggdK1IZRkKwyPc8GudyktzZRTRyp1OCNiHypHGCPenJq1rvBD j8q6O70awvlIkiAJ5yOD9axJ/BlsCTFdMuD3AOKpSi9WS4ST0HLrNkGyZOMcHHel/tm0BOZRgn0r Nl8JSqMx3KNjsQRmsu50a7tQWdCy+oORimopvQG3Y6j+2bQ5AnGfQipBqdqeROmCMcngVw2wgY5z RtccA/4Vfs9CedHfx3MLY2yoc+hFOR1JIz0z0NcAHkQ8HBxzyeaet1coeJHHbgmlyO2onJdTvcA4 BOT9aOANuBgfrXELqd6hOJ3x7nNTLrd6OTKfYkU+V20BNI7HOMgEHtmnIAB3x61yC6/djGSuO/FT p4kuApUpGefcUrMaaOqBAAGcH1NLkEEDk+9cz/wk0n8UAP0NSDxMMcwHJ96LBzdzocjGCM4NL1GA M/Wuf/4SeE8NCw9881IviO0bGVcfUU7MLpm4CCT1B+lGehzWUuvWLkfvGHsRUg1myc/LMoyehpNA n0RpjsOOfalzwcjIqkmoW7EbZlOe2anE6nOGyPY01YnrYsDnpxxR2BzUPmYPDd6XzAT3B+tCQKxL 3BB+uKXPJx1NM3g4x1oyBk7gO9AJrckxx1xz+VOBIJx0zUYcDgkU4FfrTS0C4ucNzz3p3fpnvmm5 BAJ7Cl3gj+tFgHr0yAc45zS5wSaYp4wT+RpdwIOKEA/OB1wcUv480zPrSggE4PH0o1DoPBzjBJ55 NO4GRnmmZyeBzTs/XjuaPQNkKcUvORnODTRgjP8AWnZwORimAuMDg/lS5460gPUUvHGOaSFrYMkH OTml8xgMBmPv6Ug6cnFGRz1NHQB3muAAGI/GnefLj72TTOgHH50o9SOfWixV2OadsYIB/CjzckZQ EY6YppBx/nmk6cE9adlcV2OzGeDEKXZCeqAe4pvGOe3elXkk9qOVBdjJbO2niaNk4YY5Fee6tYS6 VevbTRshzlcjGVPQ16ZbpvuolxkFh0+ta3ifSLbWLxTPEp8pAoIGDj0zRFpOwSV0eU2njHW7C2WC 11KeOFBhVB4AqZvHniJuTq1wQfQ11n/CF6SCT5THnn5jin/8IhpTLxAc59TW6qSsY8i6nGTeOvEe MLq1z7kGoB438TFcHV7oeh3U/wAUaZDYan5FspVdoJB55rD8th3JH0pupMSjE2P+E18TYwdYu/8A vs0Hxp4mYY/tm7/77NY/ltyev4UeW3oaOeZXJE1f+Ev8SHrq94f+2hpP+Et8Qj/mL3mf+uhrN8pj kc0nlP0AJxRzy3Fyx6GkfFniHvq95g/9NTQPFWv5/wCQveD6Sms7ymxnBwD6UeWw7Hr6Uc8rByRs aP8AwlGvE86veH/tqef1ph8Sa2T/AMhW8P8A21P+NUvJc9jge1HkyZ6H8jRzyDkiXP8AhIdbJ51O 8OfWU/403+3ta/6Cd3z/ANNT/jVcQSZ5Bx24NJ5EgJ4bH0NCnKwcsCwNc1nkf2ld4P8A01b/ABo/ tvV/+gjdnPrK3+NQfZ5cjAPX0NL9ml6kMMexpc87hywJv7Y1Xob+7Pp+9b/Gm/2vqoAP2+69P9a3 +NM+ySkHIbHbg0otJSSMNkexp88gcYjv7V1Mn/j+uj7ea3+NWo9XvhGFa7uSe58w8/rVeKwld1Xa +SQPumvZrDwppSWMPmWULSbASSMknFCchPl6HkJ1O7dSDNcNng5cniqrXWONjZ/lXuI8MaZgj7FC Bj+7WbPoGhvMYWs49x44GCD9aJJtaiVtkcb4QuXyBggAkde1duHyBjGaqx6NaadceXCgQHketWjE EbIYHHbFcct7HZD4URyHnoah3gccirWVPDDNRyIhXPQ+lSOxnzAI25RjmpiwlgBzkjgileIlTkd6 gjJjkwTkE4xTJtqNVjHIPQ8YpsvBBHQ806ZNjZySDyDQPnjIxyBxTs7CRXdcg4BA9KgDsGAPIHvV llOCD07DNVnGO4BoQpJ7jXBOSDz2rG1onER9c54razleD29Kw9ZfM8aA8gE/nTvpYEm3dFy1P+iR /SpyDxx9KitR/osY7kDPpU+DnHUUgaSG44A596MAdaXBI5OOeKMcgHn8aTaATqfQHpxS5OCcZoHX vjFHOcDOf50aDEznBPI9qUA8cnHoe1GOOv1oxk/hzRYVhMEnpx1o5wSDS+3OD3pcZXHI+tC2GNxg EjkUcc9c+lGOM84PajB2k9KGLSwnvxz2NLjBwB9KMA98nHWjA6Dn1FHkC8hDwQMZIowevv0pSOM8 DB60nAzznnrQwSDnBJ6DtQMADI/GjgeuDSdvalrYfoLgevel68YzSDBJ6jjilxz2z24oQKwg6kkE CggHOD05xilzg+vtSZHfn1xTtqAqgYJNJjnHANGR09aTgnNDH1EPPTr3pRySP1pcnH40dAc8DqDm jYQhTHemk8cUuTjvn19abxnnOfpS66hdBjgYIzSYA6E5xS5XHc0HHT2puwaDehx3/pTsZBIHIFGR t75oAOcdqATG9BkYpMHdjPPfIp2MEDGCfyozgbqXUb0QADsM44pfLJJxgA+opqk5z1B9K24dN823 V1yQRnFJjik9TI2ZIGMn6UeWc5zjnr6VsNpjYACNgc9OtNOnOM/KcDtg5oHa25kkEYPBPv3pmMk4 wMdsVqtpj7ScDGOhGMVnqQSQBnBweKXmBFg8kACgp2I57mpinAAHHfikKHgDjnk0XA4Rm656+mKd HKEYEE4qp9rcE5wc9SRTvtiE4MQHrg10NaHPqb1pfhAPm5BrUj1AbhlhgDnNcklzD/EWX8M1ZWWH ORPgccEEVEoJlxm0jrU1MdVbj3Oc0NqIfPr7Vyv22BF5mJxzgCmtq6ICIlYnsSelT7NbIr2j6nTi 9JU7unfJxWbqGsJt8tTnI6g1gSXt1dttXcc8gAUn9mXbjeynPU5PSqUUnZhzTl8Ow1nyxPc55zRG iOSHkKDuSOtRlGQ4JHHSg5yexrXoZ63NB47FYz87MRxx1qkxTf8AIDt9zTRz16+tJyDzmhKzKk7r YUnOQOR6mp4LWS4bCDjHU9KgyPbBFKHYfdYjPYHApu/QlWvqWpLB4gS7IBjuaqYBbHHFKXdz8zEj tk5pMgA9M9Md6S31G7dAK4xihYmfhVJPt2pAPcj6VOlzJEAFwB9Kb8hK19SJraVQSVYVGVA4yc1Y lu5ZuGY4HYcCoeCME0RXcT7obg54PajB9eRS4x0P61bgktkGWRmYjnPIodhrVlL5gev61Is8ydHY fQmrE0sTA+VEo9SRzVcjvz9DQkmhvR6Dxe3QORNIPTkmpBqV6uMTv+JyagzwOBx0FWYbZJBueZVy OBnmk0khavQUa1fD/lu341Kuv3wABlB+oqCS2hT/AJa5GOgwear4HA4x9KElYdmtDUHiW6Xhgh9e KnTxVMCCYkOPwrEwCDkUqQmRtqLn19KfKhXfQ3x4s55hx9DUy+K4ScGFvwNYDWEoGdox9cVXKLnG Oe9JRvsN3TOsXxRaHqrjHripV8S2R7sPwrjSgHB4NJsOBg0cgKTsdyviCxfIMxHsRVmPWLJ84nT8 TXn4RwM5ow3qPxpcvYD0hb+3c/LMhPseanE6dnByfWvMQXBAB59jSieZDkO4I9DRysLo9PEgxgEc dKeH75rzNdTu04FxIMe5qymuX8fIuCceozRZhc9FVwSRzx+tOyARjn1rgU8UX6nBZG+o5q1H4vuF GGgRvUg4NKzC522QAOnNA5bqK5FPGK4G+2cdiA1TL4wtSfmikH5UK4XVjqeBgA5o6YArnB4ssCRu Migd8VZXxNppGTPj6g0WBdzbzkfj1oOeMAfWspdd0984ukHoCcVOmqWTgYuYyT6MKEtR3sXsEgD8 6djC4zjmqouY3bAdT6EGpRKrDqKbDrc09HQyanAOwbJ/Ct+6fzJnbgZJ4rlba5lguEeBgr5wCRkH NdKQSBnqRzSSdwT0L1pp1o9i09xOUIPTGBj60Z0YYAu1Jz/eFZniJxH4UnV5lhDIQHYnAz9K8mtN ME91BCuq2wYMMbWILVsrJGOtz2W4tPDzyEztCXHUuAT+tM/szwyFDHyNpPBwuPzryPV7OKbVZ2/t e2AJ2kMxyMdR0q1daYkWi2loNVgV2Yygkkgg+lCavdis+h6kmneFnyB5DEDsq8Uq2XhXON1uR04C 15ZpNhFbtPevqluURCpKMcAkYGRVW200XTLaJqdm7McgZIJ+hxVJq4nc9haw8LocMIASMj5QM04W HhbaWxCFHU4XANeSalDCbyNk1a3AijERVycAjr2qf+zorbSJLZ9SgSW7AePDEgqO9F0FmeqpZ+En YqrQk5xgBTTjb+Eo2IZ4QR1BC8V5DpmkRRTLetqds0FuwMhRjkc8ZqOXT4b/AFSUQapbN57kqCWB OTx2oFZtntAg8JJErM0SqejALg/jTki8Iu2EaNiBn5QpIArxy+t7Uadb2P8AasCSWrt5m4nAJ7VL ZWMOnSLe3Oo2yrcRMIihOGJGOlF/IOVpnsCnwZkAvEfb5c08p4NiYB2RSRkZ29PWvDrfRxcRTBNU s5FiBeQ8ggevSrF9FZXk9p5GsWo2RLHiQHkj8Kd0JJntaJ4OILBkIUZJG3j605D4MOMSxEngAMvN eMJYW2mQahZXWq20dzKgGATgc55qnHoEMdnHeyavafZhJtDjOc9cdKLoLOx7sz+DYZNjuiMBnBIF OEng4oZRKnlg4JyMA+ma8SuNMg1rX5HsdYtHaUYVGznAHPb2qIWunQaHPp51m3WZ5gzHLEADjHTr S0DlPdEufBhYBJUYk4AVhkn2qU6l4PiYpJdIhBwQ0oBB9OteEjS7bTrqwub7V7QR8SIUBBZQevFU b+20+71G6nXXbYLKxI3KTgE59OtDaBJnvuo6h4fNhv09/OYtgMjZArEeyhEvnAEsTmuX8IadDZ6H CsV0lysk2d6Zx16c12zKCRjg+lGg0ranMX08Sa+tvIwBaMFQfalljMTd/Y9qxdeRpfFUjqcmJQOv PStCx1IOginGQOAe9ck7NtnZBq1mTfKSQCc0jIwGAeO1SyWodS8TZyelVxI8LYlXj3FT6FMGVsDk e9VJkOMgc1pKIZcFGAPoajmtSSeO1K9gautDPI3x4PUDioFYo2OlWGQxMCemailXncOM1SZDTHYV mzgHI6VRlwJGAHB6CrQOAc4yKqE5k6e9Jb2ZT1RDgh/QViXdu9xqZwwOAAATxXQlM/Wueu3I1Y4O ACOhq7LoTHQ37fS5/IXAzxyRT/7PnA+6c46Vbs5HFshDMARwM1ZEr54Y5p8hLlrqZRspgBlDn0qL 7PKHwUPPbHWtz7Q+MEgk+1NMr5BwDjpS5NA50YpgcdVP4CmbGxjByDxW+JgQMouQPSl8yI8mFTz1 9qXIx8y6nPbDxgdKNh44roM25JzCD9BSeXaHrEfwpKDByTMAg445FJnAOQTW99msyDwR9BTfsVoc YJGafKw5kYYyAc9KQqSe/Fbh02AniTA96b/ZSYyJQT2561PKwVmYuOOR0pMHBx+Fa50dsYV1Ipp0 iUHkqfahXQJWMsZ9O3SkIJOAMZrQOlTgdMj2pjaZOufkNGoehR5Hpj1oxyQBxVxrGZDkocd8CmfZ JQB8hGT6Ug8yv7D8aMHd7elT/Z5MnKnH0pvlMDkg59DRoNp2IgDkkZGRSY5Oe9S7GyRg47UhjOOn NFxdCPnHIpGzwen0qTaQOeKaUJAxRfsMYD2PPvR6gfzp+GPQd6THJwPTINPUXWwwgnBHbpR296cQ WGBn6+lGAF55JovqVYZnrzjPp2pMEc578HFOOME9OKMjIzkij1EJgkE9cnikwc46etPIHBA6dhSd QeRn1o12B9xhzuyRwO1J0zkAml6ZOaAQTnPSjqJbXBMngHPNdNpwzGEZyFVR371zsKlplUeuSMVe uNTawkwoDDAyCOlUldCvbU6J4wqkrK2SOAD1+lMhDumS7ox7EcgVz0fiZmYbYgWHU4xTv+EpUvzE M5xnJ5o5XYd09zYu3lhQESgnBzkVkaKftLylgCGY4NLPqZuNPnkClQqkdfWq+nZgsYyhwcE5/lSc egJ21R0L6Z0G1cE5ph0wEn5Fx7CqC3s+MmVsgdzR/asoIBlIGehNTyMpTVzx7axHGTThGd2T/wDr qSG6eMbBgE98U/7xJJyT3PrXQm76melhoXA5/Wl2AscAcdM0uBwCeD1NX7aKyyGlmycfdxwKTdtW KOrsZ5QE5wAaMAZ4BJ61fn+xAkRKXJ6EHAFUsZb36GiLb2CUUmTQXctvnym2k9wB0p0l/cSphpSR njHFV8EnAFX4tJmkAdiqA9M80S5U7sqLl8KKB689TSYxk5q7cWawLzOjN3UDNVCPQDGapO6uiXo7 MtW1xbxD5odzdSc/0p896kqFYoFXPc4JFUiB9DU0VtNMpKISB3PTFTypu7KUpWsiuQSCcD8KMZOM dqsPazRrloiAD17VAccHiqWq0Jaa3LNvFbEAzSHPcAf1p8ws0GI1LHtzgVT9cd+tHBIzU8ut2x8+ lhCOeBz6ZoOCOnPel4ByfwpCARkVa7EX7liKymnUMoCr6k0+bT3jUs0iAAd6qrK6ZCsw+hxTmlZw NxJI9TU2lctONrWIyME9MUdOh60uBnnvRjBxk1VmTohFBPTnJ4AqT7NNg5jbB9qkguPIPyqhI7kZ NTPqEzjblVHU460ryvYpctrsolSOGyPrS4496dnLZbkH1pcDtgcVSS3JvoM7/jSEDJ781JGItw8x iFzyQM1e3WGzAGSB6cmlJtDiuYzakSV0yUYgA9BSSlXPyqEGeBTcEHGaNWJuz0JJbmaRQGY4PUZ6 1ETkAYGfalwDgHr2q3Fp0ki5JVcjjJ5odkNXkUx155/GpYXRJAzpuHpnrUs1mYUOXUn0zVbBGMED FF00JpxZofb4gDiEA4wBgVSlcuSxAGTwBxTMYz70cHjj8qFFIbnzbikcetA5OMc/WnbGA5BH1FM5 Gc49qpO5JoR6erx7nmUE9gQcCoZ7SKHpMGbP3cciqwJHelJ7nn1NTZ33K5o2t1E2LxxyTSbB0pcd MYINKDgH19aom4CIscDJPYA1I1pKAAUbn2p1vcNAxZVUnHcZIqy2qSlSMAH1A6VLT6FRUbameYGA weCPWkMZAIwMVKzs7ZYkk9SaQnkjtT5SW9SHyzwe49DS4bsTn61IDnsMVoQLYpGPOJZieSRjFKSU VccVzOxmK0yHIdgPYkVOt7docrPID7Mas3RtANsIJY9weBVQdcdc96S11HJcrsbnh+/vrjW7SFp3 ZWkAIJzkV7RjCgdTwK8g8EQCXxLbEYO3LH8q9iA3SKAASSAKGtbAnoY/xEinfwusEEbOzFchRk4r zHQtHvzrMDy2kqqmTllOOBXo/wAVLi4hsrKG2laORm6q2OAPWvIG1XVFYg31wCDziQ/41TvsRG3U t3WkajJczsbK4y0hJ+U4xk1q6ppmoR3VmEtp8RW4BKLnBxzUUup30fhm0LXkwaSY5bcc4A9afoep 3oub1/t08scVuzAs5POOOtCDQIdH1CPwvd5tJjJLMBjac49cU7Q9Kvjr8MktrOEjjJy6YxgcVlQ6 rfs0GzU7lpHcBk3nA5q5r2sX41q5UX86CMAKFcgEgCnqL0K02lak63CmzuAzSlsbDjGT+ta2q2F/ Df2Gy2nxBbqMopOCRz+tMn1XUY/CdmzXk4aWZiX3HOB2z1o8P6vffbrtjfzzQx27MC7E544PNNXB CW2magPDOoE2svmTSrxtIJHfimaJo15/btm32acRoASZFIwcfyzWZHrepP5ezUbnzGkwV3nGM8Vr eINZvI9dkiW/niWOJQNjHBbAz+dPcXoZ97Yakbi9AtJyJZCfuEg8mtLVdMvvsujQi2nIji3NsU5B J7e9NOr6ivg7zmvZjJJc4D7jkADkZpfDeqX76/GrajPLGsbMQzEg4Gcc0PQPUbpmlX8djrMxtpgz xbV3KQWyeazrXRr2S6s4haXAIcbyynA57VFNr+qNJKw1G4UlzgBzjGTWvrmr36NpkJv5ox9mVmYM QST3NCtuBFrel302vXz/AGWcgkqhVSQccVJc6Rfp4Ns4VtZtzXDMyhTkYHGRRp2s6kNG1aY3077V VUZmOQSeo/AVRsdZ1ObULKJdSuXLyKGUscAkjik7XFfTQv8AhTR9QTXfOe1mXZExBZSOccCsh9H1 RxIv2G4yzkkbDg89a1Nb13U01/UBHezqiMVUK5AGOKtXes6lH4KsZfts/nS3LfPuO7AA4z6UdBkH ibRtRLafElnMwjtVBwpOD3rJi0C5MY32t0r+giJre8Lazqc3iILNezSRpE7FXckcKfWsR9e1UiVx f3Iy5xiQ8de1LzBHqHg6zlstA0+CZCjlixUjBGTXYLnOT0rn/DbzT6Tpb3Ds8hhDM7HJOR3rpVHJ 6AD1p+YHFXFu0us3dwvILEfl/wDqqrNanBZQQR6UtjqoGr6hFKRsExCk89zW15UU6BlI55xiuV3T OyKTVjGtb6SBtpOR271rR3MFygDgZPrVO50/OWUYNUVR4iCMiloyNUbDWa4JiPvxSCR0G18n1qpD evGfmJx9aurMkw6gmps+pSaIZYFkUlevXFZ7IUJUjP1rUI25wcVDKgkGQBnvxQmN3exmbGGeM9ap fx5OODjpWoRx6HtWfLGySHODnnNUtxWGHJBrlmJk1Fz1G4jr7107tiMsuMAHNcpE2boEDqckk9ea YkdtZg/Z1GCDj1qwPqRUVqM26HvgGpeSDWphLcTgDPBo3Y5OMepowO1IoyTnp70J9h9NR/b0FHXt jFHQkc0djR1uJBwSAAfenAAkjp703kc0oGSDk4NLUegYyBQBgnPNGD7HFHPNDYJCHjB/A0hOCMUo xk560uMjpxSCzGgkHgn8DTt7f3iPxpMUmMH14phccJJAfvn3HWl8+UDHmEj3pvI78YpMDqaWg7u2 hJ9plzzgj6Uv2hhyVU/XvUIHH/16Dxgduxo32FfXUsC7IJzGpB6Zp/2qInDQqc+gFVARk5PFLgD/ APXS5UPmZY8y1YnMAzSbLFxzGB26YqA4xnIFJjJH6UuVFc7Jvs9gRjaQOxpv2GxPRyKjycY6fSm9 yMGlyIfM2P8A7MtWJIlwaT+x4mBKzCm8gHHWk6Ec4+lPkQcwn9inPEqkVG2iTAnayHHoakLEZG4j PTmje4HDt19ankDmRVbRrnbnaCR1wajfS7scmIn6VofaJRg7yPx60C7nGRvPtmjkYcyZlmwuU5ML Z796ja0lAOY2HPHFbX22YY+Yfj3o+2vn5gpx04o5XcE1YwWiIblSO3NNKEEnBHv2roDcgkgxKR34 qNpYHUhrdSMccdKFFjTRkWSE3IJxwM9asSRwvI29CfUnmnNFChLRgo3qB2pm58ffHX+7VpWVibq4 C3tSykqBu4GB6VH9ktCDtGMHkkVLmYDqjD6d6TL8fJG2T0NNJi0uQ3yLBpwiXnzGAH+fwqcJthVS AMAA8+lQ3CSztCXVQqtng9atYyOTyaXUPQrXfnGIrAoLcYBOAfxqlNbXIkMqxFsAADPXNbCFRgNj PT61ZjaBVYMVG4HBOSQaaethOPU8YUgE+tWI33AAZz/KqpGDx9acrkSAgkGrAt46nHU0mSCMcDsc 9KVGJGcZqxALbdm4LbcjhRSe1xJalcAgEknnp6Ug+hPPWtdrnTo0xHBuIGACP51nSy+bISEVBnoB ilFtlyil1I++RnPvT/MYEYZh6YNNIOcg4/SrFtZyXLbUKjnBJOKppWuyFq9CuSSc5JPfJpOSec4F bLaNCkW6S5CkDJORjNZk0ccbARybx6kcGlGSbsipQcVqQAgMD+VW11K4QABlAHAGO1VsBQfU9KaQ STj9abSEm1sTTXUs5O9j647VCBgE4qeOzuJUDrExA7+tJJbzRDdJGVHqRSTjsgadrsg6nkcZrRtZ 7GFRuRi56kgHFZ2SST0oxk89KckrWCLs7l+5u7dwVigHP8RHSqPr60ZxkHAA6UmQFyAT7miKSQNu WoAY96t2tkbkgllVe5J5qtgAA8Z70mSOhIHtTa00DRas0ZdPhiUsZyAOACAcn2rPbaCdpJA6H1pN xyckkfWgFck0opocnF7BgdgaMZ46k07PIAyCKVHMbBxyR6jNUyEtSRLKZwGWJiD+FNlgliADqR6E 96sf2pcE87enpVV5ZZSdzk+me1Qua+uxb5baEZ4B4pcYGRRn15zRnI6ce1WRcTGfX86COOM596vW ptUAaYlm7AjIFTSz2O3KRKx7DGKnnd7Fxgmr3MvnjANPWRwQQzfnQcAkjHXgU3ng5HWq3J1HF2Y5 JLH1NNxwc96euXO1RkngYHery6VMYwzFVJHAPX8aXMogotuyM4DuAeKnhlEDbjEr+mT0qW4spLdN zOpz0APJqoevGfx6U01JaBZxZpf2mpU/uQDj1zWfLIZTuPB9AOKb2FL1HYn6UlFIbk3uNzxyKUAE cg0uOABmlwcdT9KYkXrfTxLHueRVyOBnmknsEgXcZgD2GOtUugGCRS7iSASTjpk1Li77lXja1tRu CO/frQeoJpcHn0oxjjr9apECEc4GTUogldAwRiD3ApIyFkDEBgOx6Gr41dhgGJcDsDjiiTl0Lgov 4jPaNkOCpHPcUhAPYg1PcXbXDFjwB0HYVXOaFd7ktK+gdAAKdk5PHPrSYI6elTW8aSyANKqDuTT2 BK7sdb8OoBJrrSAfdiP6kV65aoHvIlzwWGa8/wDh/aW6TXM0BDEKFJzmvSdKi336E54yf0qFq7lS VkcJ8U9XS01CCA2sM/BYCQE4xgcelecnXkU5OkWWPdTXb/EK703/AISVhdXc8c6LghIwykE8dTwa 42V9AlUB9Qujjp+4H+NU73Mo2sadrr0d3ol01xpdoyWoBiUKcAk0zR9czqUNqdJs0jugFcKDypqG Cbw5Hpc9kL65BmZSX8npjtjNTwWuiaBrELz6hNIyKHAEXQEZHP40xla416C0v5mt9Fs9kEpCkg54 PBq7quqWzizmGj2r3N1GZJNxOM54xVWbR9GlsZdU/tWUQtMVIMRyScnpn0q2bPRfEFxbQWmpyo0E G0BoiBgDJOc0Cew62123vNFuvtOj2wSyAMajOMk4IqHSNfiXUYbcaNaIl0AjBSc7TUcB8PQaVd2J 1WUvOwJfyTgYPTrU0GnaLoOr2s11qrNtUSBRETkEcfSmgvoRXmp2trqFz9n0S1aO2kIDEkHg9au6 tqVnJZWN+dGge7vQSwLEDjgGqU2j6VdwXepprREBlww8o9SSQMVaks9I106bYWmr7JYYygBiIyep IPam72DqO0/WrW9sry1udHgWG0QyhQx+90/WqGn+JoLa4RodEtlMh2ZDHJB4Iqe2i0HTrbUbWXWd 006+XuERIGDzz3pn9g6XpktjPc6ynlSASoBGSSuf0paiJNWv9Ms9WuLaDQoJFhALEsQeQCTVi81r Trrw/Hqk+iwtN5ogVN5xtA4qC80jTNZvdQ1G21pFhUeZIChBVTwB70Pa6Lc6FZ6ZFrKCRZixJibD E8CjZWAn8PazYXt2dIk0SCOCYFpMOScqCRWdH4j0qyvTNBoMAaKT5CZDnIJwavafp2leH9ZmN5rM bSJGyECMkgkYBJ9s1SfwxYjTFvzrdt9mklKhzGwORyRj8aOlw02NDW9V0iCSzuH0SN5r2ITS5kIA JPtU1lr2mano13DPosQt9PjMkQWQgEk4x+NMu9G03X9Qs7ex1mASRW6xhHRgSVHJ6fjUFnY6LZaX qVo+v23nXG1QQrYAByc8UDsVbLxhp2nztNb6BCrshQnzScg9R0qOPXNEZCx0GDJP3PNYH+WKq/2B pZJx4hs+T1Kt/hV2HRtOnaOH+3dO5IHyxsD19cUxNWR6/pQiItfKi8tPs4KpnhQQOK2CgEbMcggE 5/CqNhAsV0UHIjiVQfYDFX7w+XYzOMgiM/ypLZj0ujy6GybzbmfgiSQnGOepq1b3b2zYYsRUGk3Z ltnLknMhA/Crc0YkXI49feuXV7m7XVGnDepKAMj3zUrQxy8gDrXP4aFsg4Aq9bXpDAEnH6UOKtdD U9LMsSWXPT61XETxsSMgVo/a1KZzk4qu90CMkYB71KvexTta4xZS6c5BHWmiTB6/nTS65JXnNQsR 15OaGgvbYllAOCKoTjjJ7VZWTjBzjpUUxypHUnpTDqZF24jtZ25GFJFcd9tW0nUsuR35rqdVciwk HrwefU1w+oBllAOPqKqKuxPa52lt4tsRGqMsilQOcCrsfifTZOBPg+hBFebhiOOtHmkDlfyrazMO p6imsWMg+W6jJx03DNSx3sBzmZADz94V5QXGMgkemRR5hxw4/EUrWBnrYvLcnHnJ/wB9Cn/aYM5W VT9CK8iEjAn58mniWUdHosOx64JUPVhjPrTwwIPIx2ryMXVymCJGHtuNSLqV8gyJ5QR6OaXULaHr AORjP/16XpjFeXR6/qMY+W5myfU5qwvivUoxgzFv95QabWgXZ6OCehGfel6g+vauDj8bXSY3xRuP xFXYvHEf8dqeR1Vh/WpSC/c7DoOhpvbOefSucj8Z2LfejlUH2BxU6eK9LckmVl+qnFFgWuht8E88 Udeh/wD1VnR69psoyLuPJ6ZOP51YW9gcApOje4YUrB6FlulAPcCozKvZhgc5zxTPNUn/AFij15FC Qbk2eh55pOM981D5q9AwYdue9L5gz1B+lNrsPQm5yM9PSk3c5wQAepqPfyCBzSE8gUaWEtSXd2BF JnjA4JpgcZOQeB2FAIJ6ZPrS6Ah2Sc84oyMcHpSbhg4z1pOORzn0xxRpca2AEAjHPPpRkY7k0cYz SHgDPelqNMOD0z+NJ25HNLkdBSdDkkGn5Cv3EGMnk0EH0GfejsT6n0owQwyRigF5h0GQee/pSdCf YUvUYzgZ4pOeS38+DSVhjOuTxjoaTaDwBwO5qTY23IGQe9R71PG4ZyCe1MLq9hoGTjHbp0pCgJAz zT854BzkdjThtwDnB70XYtOhBIQhXHUA1VJnDbt4A6AY5q1KR5h74qJuR0zx1oHbQh825AyCpPYk 0vnzk52qeOxp5GT3PfPvRx1I9eRRpYPU8tIIxnI96ToeetaDyieySF4l3L0YdfxrPKkMQeMU1e2o O19CaFxwp5+lWlwMnp6e9Z6nBGOxq7HiRlDNtB6k5wKafcT7juvT8KMgc5ye9a9vFpyAb5VdiOpy BVa6lswCsEJ3f3s4FJVNbJF+zfLco5HUHrSbiMc4wc9TTQWzjpRzj8eKvdGVx+8ngk4PUE0ZwDj1 qxb6dcXK7lXCnoxOKsPo0yjJlQADJJOKjminYtQlJXM3rxx9T1p8bGOTdtViOgYZFI6FGI3A4PJH SmE8Z9avcjVGmdYmC42IPcDFU5rmWcku5bOOM8VAegPanYbsue3SpUYxdynOTVhOo9qAO2c89e1H I5II96TJJGOOOapbE7GlajTkXdI5Z+4I4pLiWxX/AFcQYkdegFZvOcd6VckckD0FTya3LjN2sKcE nGBRgHkEfSk5A5wRRhvUc+narsybksUDzvsiUkn8hV/+x3xjzVz34yBWYrsudrlT6g1J9qnHHnMR jnmpkpdCoyin7w+4tzAQPMVj3A7VBnrg5pCGJyTn1pvJ5BINMl6vQfnOfXtSgEgAAknpj1po3d+v er9pew2y48glsYLZ5/Ch3S0BWvZlMxuvVCvsQab6joa0pdVyuIkKsepPOKzmJYlieTyTRFt7jkox +ETnOAeaODnkEjtSZJxg/jTgjMQAQCT602rE30EHJ5PTpQBnvWtb6SjLmWZWJHRCOPxqO6sre3Uk zHdjhQMk/jUqavY05Hy8xQBII25BHcGpRdzr0mbj1OagII5BzzSckk96qyejRndrVEryPMdzuWPb J5pnfnPHajBA6kA9KkjtZ5VLLGzD1A4o2GrtkfI7Yz61LbNCswMwZlHOB3NNaCVFO5GAHqKjIJH1 odmgu09jZ+22BABiAHptrPuZUeTKRBFHHHeq2CDjP4U45xzSUbDdRy0HZ47Hjik4ByePakwc+vGe tLgkc9fXFV1JZPb2k13IViBwOST0FXTo0q5Csp/Os+KWWLISRl9cHFS/b7oKR57Y7nPNS1JvQuDg l7xHcRNBIUYhmHXaciovr+NG8knJJPqTSnkfzqlfYi+oY568elKBnHcHpQAc9f1q7YT2kLFp1Z2B 44GB70m9BxSbsUsEDGO/pVi1tJr24WCCIvKxwqgck1rR3VlPIqqgd2OAuzkk9BXqnhXwvbaHaC/n iX7XIuTxkID2FYzrcq13OmGG5paPQq+EPD0ug6ey3DKZpSGZQPu8dM+tdxo8Y892JwFUnNYsMpmD S+rHA9q3NKX/AEe5f0UCqp3erMaySdkeOeMNAu9R8S304hRwzARt5oGABjkVzD+DNYABMKBSeD5g wab4neWXxFfSh22tO20g9gcVZ1eO6bR9ItkLsREZCAfU8Vo1qZRskRQ+DNXMqkwJtUgsfMBAHqa0 9Y8O6rc6xNNbQLJGVCKQ4OQBjis/Rxc2+maqxL7xGqAE5ySar6PFdNr9mknmLulXjJAODmhdwerN 248Mamnha2tFgBuPtBkdNwyBjAzS+H/Derw3t3czWoQi3YKMgAsRgAVzusNfXGtXsqGYgzMBhjjA NaGmXNzHo+rzM0iFbdYwCxzkt1570JgrEK+FNbcpG1kQA2c5Hc1ra94e1mTWnlt7IyRiJYwSARwo HFcZ9tugDi4mB7/OaBf3oGRdTgY7SH/GhOzBpnaf8I1q0Xg024s2M8lyGKDGQAOCRT/D+g6sPEEd 1PYGFY4jjAwCQMD8TXFjUb/GBeTgf9dD/jThqWoZ4vbge3mH/Gne5PKzZk8Ma6/mqdNc7nJ3beRz 2rW13QNWS508Q2LzLBaKpBGRnHIrkf7T1Ec/bbj/AL+H/GnDVdS6C/uPb94f8aVx6nVWHh3Vo9A1 d2sZEkm2KqhcEjOTgVm6V4Y1d9Xs1ks5xGsqkllIAGea0LTU7+Lwa0z3Nw7PeBR+8OSAuSM+lYUm qauZGYXd2gJJA8xuBTDW1zQ13QtXn16+lSyuCHkYAhTgjPFX77QNSTwXplutnMZDNJI6hSSOABkU 3xHquqxxaVFDe3CsLNWfY5yxPOT6mtv4d+IJYrm+u9WvZRaQRKGMrFhkng4PemkK5keFND1KHX3u ZbOdVjt5CC6kEnaQBXNSaFqu5mNjOMsefLPeveYPHnhm4lSKLUELOwCgqRkk8dRXk/i/xBqy+LNQ S31CaOFJSqokhAAHsKGgT1ObGhakc/6DP/37NammeHrk6jYgWtzuMy7g0RAAzzzXoHgTxCLTwvPd 63qQIa42RvMc9s4BrrNO8VaJf3i21rqMMkzghUB5P0oS00He6sW7BD9ouMDoQP0pPEF2llospbJa QeWoHqal07JaZgOsh5+lZXjIEwWYGQpkOc9M4/8A10m7RKhFOaTOBvUe2t41tgVYsCMd/WtpLOZ4 gWyDgZFU9WeS2t0khHzggA1oLNOY1ZieQDXJd3OyrGK0IXtHAwec1F9mdMEA/hV4SsRyc0E5yeBx TTaMLIqwuwO1qmePcoOaryMwOcY9DilSdlPPI7iqfdAn0YnKEjnjpzS53Ag+vWpGdJAcAcVC52nj HFId7O40jAJJqGSQ5BB5HGKm3F1AP1qvMCCOgwc5pWKuYWsOVtwo5JccVx1/zcHnHtXSanOXdUY5 IJJ5rmLslrgkYI7Yq4bky+HQixg+1KAGIUcknApvOevUdKASB1wR+lb7mNmaJ0zAwHGe+RwKrTWR hUuWUgccdzUQnlH/AC0b86GnkkADsSAeM1KTvqW5RtbqR4GfSkwAe9P5zzxSZwOeaqyIv3G844JH oKUbuzUuc+tTWrxJKGmBKjoAO9KyBEILDHI/KjcQDkA8+lan2m0P3lwRx92ql20DMphAAA5wMc1K d3ZluKRXBGCCoNMO3djaKcc8Y6dqMEmm0iBvy9gfelyMYAOPc0Y5PWp7e2NzIVUhcDJJoskrgm9i ESYFAlcYw2CDwQatNp02eCpOagmgeAhWA5GRg9qlWexbi1uJ9quCMGZyOwDGjz5TnLv+Z5qMgHti k255BNVy6kkv2iTj53H4mpUvpkwBcyDA4wxFVeRjrS4PXPGKVmHQ1Itb1GLBS8c+xOauw+LL9Mea FcD1GDXPYJJ/wowc8Dj2NOwlax2cHi+BgPOhdD3IORWlF4gsJsYnxnqDxXnP1yfTmjDA8EjvxU8p XQ9QTU7R+lxGe33hVgXMZIw6kdOCK8pEjg9eh61ILlgCAzDPpRyiueqiQZ47UhdS3JxivL/tlwCN s7AY4BY0q313niZ+fRjSSGnqeo7gAcYpM4PXOe1eZf2jdgj97KSP9s09dXvVHFxMMf7R4osF9T0o ng5//VSBsH19zXni67fg8Xjg4781OniPUR0uFbB6EClZ2C+p32csAPwro9C8I3erXJQlVUKGZjyA D0/GvNdI8QXU+oQpMqMuQWwOSO9fSPgmOOLw3FOq4M5LknqRnA/QU0rmc5a2G2ngbRraJVljM7Ac lzx+VJP4F8PTDmwVWHQqSK6In5i2eg6VH5nGWUjn61pypmDklscjJ8MdFcHZ5iZHY1lXnwriDObW +cDHyhhnB969DWQmQcNgjg0mXOcjBOQOaORB7TTQ8qk+FepIA0d5ExPUEVlz/D7X4RkJG/oA1ezl 5FA7nPPtRINzK2MY6nNHIrj9s0zwefwjrtsGLWTFRnO05rLayvIiQ9rIuOo2k19AvPCrMAu4P1OO BVd7SNz5ohQqFwQQOQaHTQ/rErnxshxHnBJ7HFNmQFc5IPbIrQ0y5tomCyxKCBneefwxVi8v7Z12 xQozHguVFZOTvZI7FBW5mznh1wQetWlOFHBqJgTKc4HParCjgAnBprcnoJg55OMUoBz3J71atrKa 6bES/L3YjgVeOhkAfv1Bx3GB+eaHOK3BQnJaGTg5H6mm8gAjJ5qe5iED7RKr46lelQ9QACD7D1q1 qrohprRliO9uo12rM4GOBmkmu55wPNdmA6A/4VDyDzyP0o2sW4yT6AZpNLcq7tYTJJ9c96Z64yDT iGUc5HPGRijOSR/Sqv2JJrdoEkBnVmX0B6mtUarZCLakZXHbAxWJweB+OaOuV4H0FQ4X3LhUcFoW bm7NwSAqqoOQAKq8Y5OSOTT+MDOfpTSSQCADVJWVkS227h1HAq/ZaZLcgOxCxjuOSfwqhkHuQfSp Fdh0Zhg8YOKJXtoEWk9TUl0iGJSzTMo68ismTarkI24dASKcZHcYZmY+hJNMJGDj0qYKS3KnKLei E5xzxR6elLzjqDilXAYbsMM5I9atLS5A6KCWckRozEegpzWk4BzE4x7VpRa0kSBFtQoH90//AFqh udVlnJVP3a98HJP41F5c1jRKFr3M3kHBBBHrR2HHWnZ59c9SaMDGcj2q0Z6dBue3el654qWKISuq AhSepJwB+NbNvplosRLyo7Z6huBUynZFU4uTsjBBz9ewpGJzjFa95BYWykKWMnYA5A+tZJPJx+tO MuZXCUeV2FBIPBIx6GjJJyc5/Om54ORjNLgkA9KqxDvsLu6jGPejcCM4yPQ1NFazzITFGzD1HShr O4j5aFwPULkUuZX3K5Xa9hkUqo4YoGC9QTwa1I9cCgA24Ax0U4FZGCDzxQDz/KlKKktRxnKL0L95 qT3PygFE7DOSfqapEk+1GT1zjHTmjPHAyTTSsrImUm3dgMHqT1p6xGWVURdxPAFMGSTnrSg4IIJ/ wp6gjdh0AeWDJIfMPJCgHFVb7TorOPd5+WPRSOTVDzZAuVkYfQnimGR5CSzEse5OahRlfc0coONr agTmmjGeKdg57A0mMDIrQyXYQgY6805Qx6KTz1xTQDuJPQc1vW2p2MEKxiFwcckgHJ96mTaWhcIq Ts3YwyjA8g8ijbnA6HNbd3qdvJEVgiBY9SyjimeH9En13VFtYh8pOXbHAHc1Kk7c0inBcyjHU6b4 b+HHv9SOoToPIiGFJHBb/wCtXqeruYrQgEAY6U6xsLbRtMjtoQFWNQOByT61jX08l43fYD09RXFJ upK56UYqjC3Vjre4jttPjaU4yMketOh8SSxRSRxxAwyHkk/NiqJQbMMMgDAzVZF3yhU4XNdMeboc bjHVsSTwppN5K0zWKlnJYkMeSeas3HhSxu1h82xIEShF2sRgVqWuVUDGQBire8heuKt3uYNJnPR+ E9PitZLYWRCSEFvmOSR05zS2fhTTrS7jnjsmMiHKkuSAfxrod2QOuaUM3pxRfzGoo5STwPps0rP9 mnBZiTiQjBJqzH4O01LCe1+xTMkxBclyTxyOa6lHx7ZonuGihLLjOQBmquyGjhj8OtIJOLSfnoA1 KPhvpWObScD/AHq6z7fODyyjPtTv7QuRgBhz7U00L5HJf8K40knAtbj14b/61N/4VtpRbiC5Gf8A a/8ArV2K6jcZxlfbinrqVwD0Qn6UXQanFt8MtKJJMV2PTB/+tSf8Ky0rIO27H1x/hXcjVrjHITH0 pf7VnOPlQ49AaFYTTOVPgixOkRaeoukWOQyBwOSSMVUPw+tGG03N6QeoIzXcLq0/OUQj8a0rK7M0 HmEYbOCB0qkiTz3UPA9tfXMcyz3cJSJYlCrkYAwKbF4Gs4tLvLJp7pmuipZyvICnIA/OvSTMckdh Sh88kZPpT1SDTc8qs/hvp1te287XVwwicMFK8HBzimap8P7O/wBUurv7XKpncsQUzjJr1djgZwPy qEkEdB+VKwJKx5pP4Hsn8PW+lLdyL5UrSl9nUkYpmheC7PR9Xj1E3ckrxgkKUxk4x1/GvUPk28qD kdcU7y0K/dUfhStqPRFDSYmFpuIILMWGfQ1l+LUPl2efu+Yc/XFdMuAQOmOtc940J+w2oVRkzcfQ A0ppcrLp/GjldQt82ZbA45otHEttGT6YOatzxM9lg8ZHOK5vTb/M91ZzEgxSfKR1wfWuSN27HZVf U2mRRkgjGaZnAHfNV3MuCyneueCOv5VD5rgDg4rS2hztl1hvGQBUXkDgkjIqFbghgMY+tS7yQSeg pbAmmtRD8h68e1QO+c4weaHc+tR+hJ5PWnYNRwODk8e9QTkBSxPA71IehGQD6VmalfJBGATkg9uh NAzmbolrucZJAOAc1izjFya2VViS7dWJY59TVK4s2kmL7kVMZJJxTi1cck+Uz+xIHSryadvhRy5D MM4xkCqskbR4yQRnqDkU1Z5Y+jsAfQkVq720MU0ndlt9OZIy5cYGSQR1qizAYAqZriUoVaViD71D kc80JPqEuVu6DPHvTc4J6Yp2MA9PakPIzkegqlsJhnIGeKUc4GDTemO5rTjurYQKjKQVGCSMjNTJ tIqKTepm5oycc960XeyMTbQu7BwCCMms/OMZoTb3HKKT0Y3PPXilyc4o5HHelwMc02RYTJz6inJI 8Z3IxB9QcHFNOMZzirMVo00RdWUDOAD3obSWo0m3oC3s4Gd+fqKjklaeTL9e2BipfsE2OCpz2zVZ wUcqxwQcGlHlvoEubqB9OlJkZwOtKD+PpRk5/Cq1EkGehPT19KntXiWXMwO3HYZqD6kjPek9hSfY NdzTBsXOMgfUYqtdiAMohIIxzj1qtyCMnFHUdSTSULO9ynK/QMjAGOc0EkDoPrRkAdOKM88cA9jV E6sD065x7U9VywHQnjmmck8Y/CnZIIPoeKVwsWG0+UN/CePWo3tZYhuYEAHsalW/mHUhuOhFI968 sZRguD1wKhKV9S2oW8yryDkk07JJ4OfwpPfjGelGMknBHHIBq7IjXYNxx1X8ulG85HyjPrRxg5wc U4DJzkZxzx0osg1RueGk36gDt5A7e9fV+iW/laFYw/dKxLkD1xXzX4EtFu9Rt4sZZpQDx2zX1LGq IqqMYAwPwpRepz1NZCRjy0OSTz3p5IC5bj60ZAbAx0zihiOrYwKozS0sNLYccnB4HpTZCwdWH3c8 1J8p5Ugg1XcMZiASGxkEHr7U0DTQSFmlC9F5JJ70TFY1OWGCMY96RQ5T5icrnNRNENxZsZxySapJ EPchQMxIAUAeg61HJcMJACBgDGOxNSN1IViD1JIqqSZCvl9VPOe9Ow09T43U4IIPHSpVGRnjIPNV +mAeAO1KsrkbQDj+Vc9zvSZYA+bceSOgxS5AB649Kr5ccZye+KXLHjOBTSHzWVkW0u5oxiORkHcA 4H5U5724kQI0zEZ6Z61XGcAHrj86UHjp0NDigUnfcOhJPSlxkgHp9KMjGeetLnHXOc0+grAmwPl9 23vjrWzb31hAuFhcE9TtBNYu4ZJxTsnHI9/rSlBS3HGTi7mjd6mso2woFXuSOazGOTk+vNLnK4Ap uTjkcg9MURioqyCUnJ3Y4YHv6VLb28lzIEhXcx9agzg46H2pwd0YFWKnvg4zVPVaE3NddDyuHmIY HBAHFUrqyW0OBOrN/dA5Apn225C7RM+D0BNVySSSSSfes1GV7tmrlBxslqIDknA7c5FL2wOPalxk A54Pp1o5781pYysxuTntmpBHIU3bGx6gGrFlJbRSZniLkdMEYH4Vqf2vbBSAjAgYAwMYqJSadkaR inrJmDsIBJB98jmgAd8irN5etdPkgKo6ACq3I6kY6Vav1M3ZbAME5yetBOScYHtTsHj+dWbWymvH IiXIHBY9BRdJXYJN6FTAxkijsOfwrov7AiVQGlfeByQOKzLy2gtm2pMXcdQBwPxqI1E3ZGkqUoq8 ihg9Se1GTjqRjpTic9uKbitPUyv2A8jtkUmeSD/Kl7d8U8RuylgjEDjIFDsh6jMHAJp8TCOUMV3g HOD0NMKsCAc49CKd0HWhWauF7GzHrqoFVrYKo4AQ4Aqve6q9wNkKmNO+Tkms4ZOc/wD6qX0HXFQq cb3LdadrdBpwTzjNLgAjP8qU5/yKQdTnkfSrS1M76hwTgAZJ4rastBMsXnTsVBAIC9axuhH61Klz OgwkzqOwDGlJSasjSm4p3ktDUm0SKKNna42KO5FYrhQ5C5ZegOMZ96mluZ50Cyys4B4yciocnp3p Ri0tQqSjJ+6rBzgevpRnHuemKXkDrz3NJjGDxnvVkMUDJ7ke1OK5XnOKv6ZLYQNvuQWbPyjGRn1N a5v9MlDMxQ45A21nObi7WNadNSWrscvg4wD065pOc4q5e3EU8v7mFY0B4IHJqrkdM8+1XurmTsnZ EkCNLKsSruZiAAB3Ne7eEdATRNJjAVftMgBkfHOfT8K8k8J2wl1uFnUFUyxz6jpXs1tenamDgetc uIbbsjtwqSTkzSu1It2JJJPFY8gSBMHkn3q/d3BaEZ5xXPXc74JGc9AKUI2Wo6knJjpd0r4Xj1qx bWwTBIBJHWo7RSYlJByeprThTkDj610pJLQ45Sd7DkjIA/WpcHI6U7GByOKUAYHHbrUspB9Bz3p2 OMc9aco6ep9adgZpJIG2MxyO9RXRIjUEcE5FWO/NV7sgsoHYE00K6KfU8jP4U7A69qMEn0PrS4P5 dqBtgAc08AH1oB4HFOUc9qZL7De+BinAccZpcEHpzSgHPTFMT2ADmtqyAFouDjJJrH5ArZtxi2QY 5xzTQn5k+AAe5FCnBBFAB655p+3vjk1ZNyNskEjgd6jweOc1YKcYz3phTA7A1OtwTViMHkfyNTKe QOfwpojIH9alVOBVJA2mIBz1rmfGUuJNPiJ5JZvyA/xrq0Qn/CuF8byN/b+mxLwFiZjn1JA/pUT+ G5VL4xChNrk46cVwFwPsvieVRjEyZ6dxXosIJtgCe1cRrmnSvrUM6ghQCGI61yxdmdtRXjYA80Z3 Ix5PAzUg1BkOJoSRnqBUJE8QO3DDHTvSpdq4w64Ydq10OPVFoXlrIAMlfqOlI88XRGJGc5qBhAx5 CjPXIpvlRBcrjnpg8UWQ22T+YrDg557Uhbjk1DgAgLnj0qvf3gs7Z5SCxA4APWgabEv79LOAu7cn gAdSfQVzhMtxKZ5s88qnYCiIy3kguJyWZhlR2UHsBVsQt3HUUnZFx3IFh3ZOB7Cq2oRLHEjSfdzg /jW3DBgAAYOKzPEGI7EAgZLACpT1saSS5dTFMAclUPIHIPOR6ioltJHGRtOO2elNjuWUAkcqQAQO 1X/JS7jEqNtJHIHQGtW30OdW6mUUK5B5I9KbjnPBNWZomg7hhkjIPeq5IyOxqlIT7ITtmk49Kd9D 9aQAntVC1uJwcUuP8+tXbFYCH87bnjbk1c+z2kg42e+GqHKzKhC6vcx8EjnrRjjmrF4kUc22I5GO ec1BngZHSqWupLunYTHI9abkY6d6d1JpOvA609LBfqHf/wCtU8V3LEuFf5QeBjioeTwB1qf7JOOs ZIxUyaS1CKbd0PGoTpzlT6ZFVmfeSxOSTnOKc0UicMhA+lM6j0xQrdCnJ9Q/DPNGOOmT60Bjk/Wj kkmn6E9QJB71ZtFgLt5pGNvGemarc55o/wAmhrQEzUWztnOQy4HX5hVO7gjikAQ8EZ65qDOeBnAo z0zzUqLTuU5K2wmMYHc9aMcZApcntzR2/nVtOxKDAx3AoxyBx7UZ46H2oII9KTXYLkjW8wI3IwB6 cU3ymGcqQR3xV1dQxGqtFnaAMg4pTfxFCBEwYjHJzU3lcu0bGd1Hrg80oPJz170uc5wPc4pATngj NUiHYdkD1pwGT16/hSE4xgc+9PjyXwQM/TpTdrE3fU9V+Edh5uvWbEAYLSHI64r6CJVZOV+bsa8c +ENri/MrDiOHI47mvY1IkOR+BNKKOab10FdiOQM88/SmtneD1znApv3s7uw5xSSODHuDYK8j3qiL 9xm9o5ip4TGcnvTTlmJJCjORg8j3FRmXe4L429Mn1pC8aKQASQcjnrmqsLmZJLOwBG3dk4B9fQ1B MWdwz8Ag/L6EVFNICrIueSCCT29qbK5FuCSSSMHJ5oW+gb7j0kaVW4GCMgk8AVTLgAtkqD3TsadH MArAEZUdD3FQl8oQThG5APOPpTu9hrY+OvmPJBJzUqq23GcfzqVYuhJ57in5AGAKwSO9tkaxnGSc e+KeEKnOOPelzzwD1o6nvTQtOosYBkAZgqE8nGcCtuzXTYlB81Wb1cEc+1YowDz29adg/wBTUyjz aXKhJRdzWvL20UFY4kc4644rIJDtuwADzgUhGemcU7ABxinGPKrBObk7jMnkkAjvThuJ4HXoBSYw SevtU0Mz2770wSBxkZqmmJFiHSrmaLeQEB6Bup/Ckm0ueBdzsmOxzU/9t3BGCiHHU4wapXF1LcOW dj6gZ4FZrnvqW1T5dNyDHzcduaTqMnGaXqM0qgADIOc9fWtFdGSfQTB6n19KXGOhBP0qeCATzhWl VF7luBXRQWNjFAFUxSMRkkkEmonPl6GlOnz9Tlxnnjt2oA55HQVsX72EYKRRBnxgkHgGsrAOMcVU ZXV2TKPK7DenJ4oDHk560oQZ5OfTFLtGM9SKroT1uM7cgDmnAk8elWYLKa6BMSEgdSeBUh0y7jGT AT6EGlzJO1y+WVr2KfGeaekssR/duy5/ukikIKyEMMYPI96UY6gYHvTsmRdk/wBvumUq0z7SOQST mqbZ3Zz1OT71IQSvH4Gm7eM96Ekim292N6npScZ9cc07GAcZwaNmAPWjQl36Elq0AnDXAZkGThe5 rdj1awRAiqyKBjAXOK57Zgc/lQEPJwenSplBS3NIVZQ2NTUNVjnBjhiUDoXKjJHb6VlggZyMZ7Yo 2EHABHtQUIXJyacYqKsiZT5ndi9QPWkPHUikxg8g/WnYCgEc07El6y0i5vFLgBI/7xB5+lSvoF0O VaMge/Wmx67exqqhlKqAACo6elLdazc3MYTiMHrs4JrP95zabG6dHl13M+aNo5DGxGQcEjp+dR96 ceTjoetJjA/Hk1r01MXrsGBgA8fSjjOAcYoxgA81bsLE3suzeFA5JJxxRdJXBXbsipjqeaOc9M46 5rqzotkUVAhwB97PJ96ydTsrKzAWKRjLnoCCMe9ZxqpuxvOhKMeZsycHpwKXABxnn1p2OO9Jgdxm tGc6WoZznP5CjjrxijGcDJJ9qlRDJ8qqTgjpQ9B2Z0nhGMi4aXkdAK9Js3OAe3uK4bw3aGC3DHOW OcV3FtxGOMHFcr96VzqT5Y2Ls0uYCMjNYrglzk5yT1q/NNtjbPUVUtlM8+Dk1oo3IUras0rSIiJf THatKMY4xgYpIUGAMAYwKseWACelaPsjFSvqR46evvTgQOKUoQOM80gXH196ixSaHZz+PanAcnAp oXFWBGNoOOooSYNjI4i/071VvQBcBcZworTgUA5z171mXp3X0mDnGB+lUloTfWxW6HkYFOxg0uO5 6UuM9e/ekrD6gOO2TTwB35pAOOOmacB+PFMGJgGnY5BH60AZPHJ9KfjpnvQITHsa3I0xBGPQCsYI SwUHGTiugaMooGMYAqkiZMjwAelS5AA9aiPBHalByRkcetUmJku0H3pGGwEnGAMn2FOAOKSWLzra SMnG5SMj3FHQm2phS+KLKGUqqO6g4JGOT7VqWOp2l/xC/wA+MlTwRXmUkMttqE1tNkNGxH1FbFqG iCvEzLIOQQcYrH2jT1Ov2MZRvE9F2cDJ4rzjxhID4ujiJyUgUfTJJrt9E1MX8BDjEsZAcevoa4Lx DbtceOr6diRGkaRqPUgZP86uo043RlRi1UtY0ITmEDPGBWXfofMycdcVqxjZCCB2rM1EkISOp/Su R2sdr3MLVNTWzXytiGR8hHI6euazLSZLgnzACwPUHGaTxEVEcMzZJikDfh0NP+yxSIskQCgjOB3B rSOxz1Y+8XPK3jAxj6VA8TKcoRnPQniqji5iHysxUdsninRzpgeapz69atNGLjbcsZckKrDPsaoa 8RHpM5ZgcgDOO5NaSuj8qQB3rG8VkjRiAOC4pFJdShZXtqkEatKoIUZyfatZJYmUFSDx1B4rhQcD HXipEu54QVilZQeoFNx0BSOzmvkgUs7BQPWuU1TU/t04C8RqeM9z61QkeaYkvIzfU0iqAMnkZ/M0 KKTKc21YcxxgDqeTVizuTASCcg8EVA8ZG1uu7kUznJ9apWuZlu7cFlK9GHPoTVbqcDNBJxg549ab k+/PpSsVckMbCISY4Jx+NN5x1GfStKeIxaNGGGGLgnPriqNvAbiUIOCe5q1tqQ1qR5P/ANejJPpx Wg2mMMASDrzxUE1k8MZckEZx70KUZOw3CUVexWyc8cmjJzjnPtRj5u/4UY9zTsLUMgkc80Z+Yjij gYHOeKMEE9+aAFVikgbGcHP1rQGqAgBoevcHpWd+lLjJx/Wk0nuNSa1Relv0lhZFTDEdT0FUM8kg ilwAOc4puOMetCSSsglJt6i5AHIGfUUckjGMngUmB64NOxzjPamroVxBnOT1FXbW0+0oxyVIxg+t Ux6ZJp6yOhBRip9jg0ne2gR8y/8A2WSRtcj1yKqXFubdgpwcjIPrSfa7gEYlYH602SRpTudixAwC amKlfUuTi1ZIYTjAxilHIAHWj1/SjIxjnJNWZrRicg84I9KUZJPrScYwTz/KjkE46UBqGD0FGDnr kmtO2mt/s4STAYdyKkAtWPJjOO3Tioc2nYtQur3MkcDjB9aOc8AAVLcKqXDBCNueMHIFRchjyatb ELezHA5IP8qmtYxJcKueSRgVCBxznFamiRLLqUOc4ByfwpWdgk9D6G+FWmLHpE9yQQWYIDnsOteg FQG2ggEcjFc/4FtvsnhW2OCPMBfB9zXQ556fjRHY5HaxFIDjeDtAzmoghRfmIbjuev0FSTI2wgOF B9RkAUwxeYBwCcckdjV9CHuRttmPl9CDnJGKinTyyMdQcHPOQafOvluoYnbkcD1qOQGMjLse+M8Y NUDWhAxyoXIBBOCepNQTksMFgT1/+tVLxDq0OjW/2hlJU9Ae59q5Y+P4GjQeQBgkkj09KLpaFJaH ZDeFKthQRgkc1WlwgVlYEA4IPaudi8c2TyZfcqkdO341ZbxTpMqsA+MkcgdDSTVhWfQ+bobaaeQJ EhY56gdK1YtCURgzOd4PIU8VkxzyxHMTshz2PWpzqF2yYaZj75rmmpte7oelTlCPxakt3YwWxJE5 LYyFxk/jWfxgn3qQjceT1Ock00lRxjmrimlqTJpvQQAk4I7U4EhuOaTGTxnnrzVqzS13n7QzAdQA OPxNVLa5CTvuQBG6hSRjnAzSEEZBGOetdEl/YrF8siqAOFAwTWXf6glwQkSbV7kjk1lGcm7WN5U4 qN09Sh6EkfgaXGDwo9yKYDgnn05xxUnrxj0xWpjrcTZwc96aUIORgjFSIC5AUEnOMCtSLQppIgzu qEjhSCTUynGK1KhBzfumTjHDH8qMkE4Ga0LjRJYELs6YAzknGazyCMjH15pxakroTi4uzDdg8AZ9 aXLE5z/9amkA9BjFLjgU2hXDgEDH15pM8k9KUeuO1KR2AOPWmkK7uMyfb0FPikWOQM6BwOSCcZpM AGkxkY9e9Gg7o3o9eiVFX7KFAGPkbAqrd6xNONsS+WvfB5PHrWYRkYAAoAGcHnio9nG9y/azat0F zk5OSe+acOTjFMxgjjAoJyBn1rTbYzsSAc4HUdK17DRJbpRNKSsJGRjqaxwQMj0qWO5uIseVK6+w JqZJtaaFQcU7y1Ojk0OzCkneuBk88AVgXa2yT7bZmZQeSaHvruSMpJcOV7gmq2B6Zx0NRCElq2aV akJfCrCj73v3zR35pOARkYyaCRwBitdTAXHf24pyxO+CqFhjJIGansltWnX7VIUjHJwM59q6aLUt NjjCRSqijjGMVnUm47am9KnGfxOxx5BBywx7Yoycn0A6Vv6nqtqVaKCJJGP8ZAwB7e9YOBnOAKcZ OSuyakVGVk7jQMn+dLj0BIoyAe4z0oB+XByTmtNDP1Exn0pWBxxjFKkbSuERSzHgACr7aJehQTCS T2BGRUuST1HGMn8KuZ2fl245PvSjIAKkjA7VM9jcwAtJEygHuKhwcZOB7VSs9UJpp6oeJ5UPyyuP YMeKYQWJPJJ659aXHHtil7dcE0rIG+gzHBGOaXHGO46UvB/pRgg9qfQQgQknOfrXRaGlqxWOIM1w xwSRwPpWCBk4HWu08IacBmeUdR8oI5+tZVWlE3opuV+xvQWZjZVABIHNaquY1Gck4qaK3UjOTkd/ Wqt58ikA4wOtZQWhdR66Fa7ucck8ehqbw7qUFzeTW5AVlAKk9/WuevJXlJRSc5xnPFNt4TaJ5mds mOCDgitVJLUys5I9OQe35VPwR7CvHL3xJqVoT5WozD0Gc4qNPFmuoo/099x5PA/wrSEXN6GUpKG5 7P246+9Jtzk9K8dHjHXg3/H6cHplRUy+M/EGf+PlSOvKjFa/Vpke3ieuoADnI/Gpt2QCDXki+Ntd AyZYz9UFRS+LdbnJJu2QdggAxVLCzYniI2PY0IzzWbNBK1y5Ck5bIIHBryVtc1Nxlr64z/vmm/2v qWOL649f9Yf8a0+oy7kvELoj1r7PIDyjc+1L5TjjafyryMatqJxm9uMf9dD/AI0p1W/P/L7Ocf8A TQ/401gX3D6zpset7GyflI/CnBCBwp9+K8hXV9QUnF9cDn++f8alTXtURgV1C5H/AG0NDwMujF9Z PWwhA5BH4UuDkDkY715ani7W4xtXUJSAcjcQf51bi8ea9Ef+PpX/AN+MGpeCmH1hdT0+0jMl1GoG TuBP0rpZhGQBkA141F8TNaQ5aK2b/gGD+YqzH8T74MPOs4XHU7WIOKSwtRIftos9OkADcdKABgcc muIh+JWmNGDPbXCP3CgEfnmph8T9AUAst2o6cxdP1rN0pp7Fc8X1O1U0/qSK41fib4cIA82cH0MR qcfEjw0Rk3Uig+sRoUJdhc67ieLNLwU1GJQWX5ZMDqOxrMs2DqM8cdBWu3j/AMLTxlGvgQwwQ0Zx j8q5k6ppqamVsLoSwvyoAIK+3NY1KbWtjopVdLG1HJNaSiaByrg8jsR6Gs6bz57555gpaRtzEfyq +kgcZB69qHAByQDXM77HXB63YcBcdsVk35BY4HFXpZcDAPFZF5LnJHBzU26Dvd3Oa1xBJayIemD+ dUtMnlOnxsrFtowRnPIrQ1EebGw4PtWPpAUwSJgrscjIPIq4bGVZI0Uv1J2yDHvipWijcZU985FR tb712yKG9HAqs8U9owaNiVJ6E8GrSuY3aLPCHBUhs5yPSqPiEF9EmOQQCCD+NXVnW6AUghwOQaiv LTz7Ca2VgGcYUN0zS1W4LyOOt204wAXKXCyY5dCCD+BpTbWTg+Ven2Drg1Ungktp2glUrIhwRUfF aXJtZl37BkZWVWHqBTDZkclhgegqsu5jhM564FXILa5kzlyq+9IauNuNvkKoxx0NU8n9a2E0zfIB 87n0A4q7BoZcgFEUdyxzQmPrY51IZZzhVJyRzjitjTdIcyAsu5ieg6D3ra+yabYRbrq5UnsiDAzW bqHiJPLMFhH5a9N/Q0tXsOySuyprsy+alohBEeSx9TWZHK8DBlYqRnkUwncSSSSepJyc0YOfWrSa ViHuWv7QuByXyD6imT3csyKrkYBzwKg56c0cdDnHamoroPmbW4mcnpS85PNGAaNox3zTJ9A6YzRg gZ60YGcdKBwSeoosFy/p6QuJDLtyAMbqufZIWJ/dKQehBrHxjGKCSBnJ+oNZyhd3RpGaSs0Wb6CO BlCZBIyQe1UskEgDn1qQkueSSemSab3IHNUk0iW09hCDgnjgc0p6ZOB9KMAHkZz+RpCMkAUxNIXP PQf4VItu7IXVSR64qLOSR3rRtb2KK38pgxIOcik27aAlrqUvLkAyUbHrim4I9RgVrre2xzliAemR Wdduj3BZCMH0qYybdmXKKSumQ5wRj9DSA4Bz0+tO68im49ORVka9Q4PTrTsjcOO1NGMHmnY5J9RT sLXqG7JHrQWwMVZgszcqzBgNp/On/wBmy43ZBHaobV9SlCTV0UsgYAGaUnjAxkVLPbNAQXGMjIxU YAOTiqFZpi5O4ZFdD4WgMmoZwRxgHtk1ggEjP4V2/wAP7M3OqQLjIeVQcdxnmk27Gc21E+l9Itxb aNaWwHCRKP0qwDtJGRwePenBdgUDoBgUiqMHg8nvTRzybY1gHLISefQUABQG6ZGKVjgEjHGeajdw x2KBjbkn0pkvcgni8yVMc885ptyEVgoB+Xk5PT2qSUMigIcjP4iq85WURkMCy/eB74ql3Fc87+Jd wRbWsRbIkOcHjFcw8Vvb2MY2gEDk456VteP5Vl8R2tuTvCkFh6fT2rm9QcPK2zACjAGeKN2aRWiu UJLlN+FjAFRSMdm7yiAfQ9aIYS8oHOWbA96+g9K8MaV/wj1nb3FhA/7lSxKckkAk561lKbTsbRhc +O+e4GDS5I6ng9KUgkkDrmrdrpk1xhgAq9yT/KhtJXZrGLbstSlnBwTj1p2RwSCeetajaE/JEynj uCMD1qhLEIn2l1bA5I5GaUZqWxcoSi9SPIzjr7UA5xwM55NKAMjAxx19aXoeAM1RFhDjGRz2xSYI PAp/U9AfakJJxwCOnFAO/QZg9euO1P2nHTr6UdcgHA/nTsgAdvXNCFsS208toxePaCcZJANaS6/O FIaONvQisbfyAOaMls8AD2pSinuVGcov3dCzc3k1w372QnPQA8CqoOTjrScEc8YFJ6YppJKyQNtv VjsnnPGKEQuwwR+JxSDJPPTuaXHJ7CmLU6Gy0aMIGlIkJA+UHgU++srC2hDyps9Ap5J+lc+krxn5 HYcdiRSSSvKxMjMx9Sc1k4Scr30No1I8traiyFGcmJcLngE5/WmZz9DSA84GQD3zTsYAB5z+lapW MdBvAHHNL3BPBoxjoMCtHTXsYmL3JLODkDbkChuyvYI6u2xV+x3O3d5D47HacVC0bJwysCOuRius Gq2joWM4yB0IINYuo6mbs7IlCxjjJHJ/wrGE5ydmrG1SnTjG6ldmZ0I4/OncAn+tNx1weR2oHPXr 9a3uc62JMjAJxSE8gDGBSZAGMA/WrVpplxen90pCDqxHFEmkrsaTbskVTzjgZ/lS9uw7Vrnw9cg/ LLGR3BzVG4sZbRsTBQSeMMCTUxqRk7IuVOcV7xVwTxwRTckgZ5NPIIOOo9qZjA/rmqsZq6Yo6kEZ Jo6jv19KUdexPrR19s0D3E5zzgenpSk4HOCe2KCOgPOPWkw3p1NMDT0zUorEljAGc/xg8ge1ao8Q 2rAkxyKe4ODXMAcjj605sYAH1rKVKMneRrCvOCtEu3+ozXhOWKxg8J7e9UsZOR3pO2eaUAnPIAxW iSSsjOUnJ3YuTz0xR1A4GaAD3xjuKXv6CmSXtN0ua+kAIKxZ5fGQK1H8NIT8k5B7ZHWsiHUru3j2 RTkKP4e1aFlq1/O4iDKS2BkqMisKntN1ojqoOla0lqSW2hN9uWISK4HJIHSu9sLfyoVUKFCgAYFZ elW6wIQcFj1J6k1vxyBIwwAIxg4rC7k9TZqNOOnUsggKT0rIv5sgqenoKuS3HykDoPSsuVhLJyT9 PauiKSVjklK7KLoUXdgEVh6lq/kAqMb+wzWtfTlIyg78CsuGyguBl0R88knnApTaSTNaUXU0TsYN pcO8szSoHDA9ex7GrSoTg1anjgE+yBFVR1I70gGDgZr0cPD3bnBX0k1e9hiRjaMgZNPAwCCP/wBV HQYODzxSngYIzXdGK2Oa6DJJIHTHFGT6fSk5A4A/HpR0BGBir5RXFwepPWjH4jvR+lO784OaaQrj SAOjcY6UoxgEnj06U7AAB/CjGQQenrTsxdRCMnAoxwc4z2pV7DkY7UE5yP8AOaRWg0jv3ppBOOOM 089OvSjHA7e1PUNLkZPuffNKCcH0p5AxUZBHoKF5ifkSbjgYJo4YYPP1FM39MHmlzz6/0oaQJkTx kMWGAPSonOcDGD3q3nPHtVaQYbJzjPQVnJJDV9yIEg4OMdqtLqcoKBSAVIOQOTVeRd69MHtVfOCQ RzWFSmnujSM2tj1HR9T863UnkkDJrWNwXGTznpXn3h6/yPKLYK9Oa6+OXKg549a8mpTcW0elTmpJ MsTNg5BP0rOucsDt5P0q3uDknnrUEqEnjPvWL2N07mBeAhTnIPNc3YXDWmrzpn5ZDkD1rrLuLIb1 +lchqMRt71ZeBnkEdaqjZysyK8XyXR06yKRuU7SR07Uy6bMQBGMfzqpalbm2WVSdwGGAPU+tTfMB 5Tcgj5Tn9KqUWm0c8XpdlGBgkjM3PPJz0q/vBUFxkdjVCYGKUccA88UXVzFDZNNI5XA4weppK2zC z6Gbr1vHe6lGYSFbb85+nSqkWjJn5iXPoBWvpmp6UkIadVaZuWLnv6VpNq9gYyIhCoxzggVVrILp sx7PRpHb5I1RR1J64rWFvZWSfMBJJjksOAaoXPiG3t4iqMC3cJ3Nc3eanPekhm2r1AB/nQotjUkb d74iijDJbqpYcfKAAKxJNVvZgQZiATnC8VSxkjj607IxxVqKJd2DO0hJdix9Sc0nGetH0FBGR0+t NCtoORQ0gB6EjNbht4CoCohHTPGawcYHFLuI4ycfWplG60LhLlZsSWUKozugAAJHasbHzY4Apd7l cFmI9CTikySaUYtbhOSk9FYM4J5/CjJ//XQBg8nv3o6571ZIpPQd6OScDHpTfcinqQkisQCAQSKE L1Jfs0wGAjE1EUdcgqfxFa32+2fkllJxxjpS/arYqwEoPB6jms+aV7WNeWNr3Mbn6UZOPX8KViC3 Hc0nPT071omZ2QoJzycUnc4NHOMUYOM4AoEw4zgUdCeR70vfjHIq2lg8kSyZUBhxSckldjjFvRFT PQZGO1LwMZ5q1/Z0/YL+dV5I2RyjYyOuDSTT2KcWtGJk4BHANN6nOQKd2Ax060mOvaqsTqJ3weKd 7UnfJApcdDjvSVwLEVzJACEIAPUHpU41WYYyiNjviqB9O1KMkEDqKTimxqTS0LN1dm7IJQLgY4Oa r5wQBjp1oABB6DijHIHBJ9aasJ3eo5SRk5zXrvwjshLrVqxAIUGQgj0HFeRoCXAHavf/AIN2W15p 2UfJCFyR0JNJvWxlPsescOMAkYNDBiuAcH1px45J4FMDeYfkbGOoqjCwEEqBx1596jOAwck+mCOK e+dw446cVDISI22ksOQABnFNEPVj1w4JwBnvjtVQosc7PlQDnOe9SCQRIzSEYIAA9DWfqTlN0wAV VQ4GcgnrTVxqx5hq80Fx4tvpJMv5akRkdAwx19qxrzZk4UAtVizU3Ooajcng7iefqaje3kvLpYox l2ICqByTStZXNetkQaTbibVbaE9GlUc89SK+kEASMKOgGBXzzLpd/peoLFNA6TqQwBBz6giu/uPi P5en2qRwsbpSBNvGAcdcfWsZJudzWM1GOp8zJIY5AQFYjnkZFaKa5Mi/NCjDPbissn0B4pd2AODg +tNxTWprGTi7ouXOq3N0MACNCMEA9RVTYSBn160oOQB1x/KnZ5ORx34pxilogcm3du4wADjv7d6X aSwxnk8CnHAwMfSmM/zZwfb3p2syWkbNjokhAluDhTghRySPetOSxskj3PEiqOp6GuXS4lB+R3UD 0Y0+a7mnIEsrsB0yeKylCTd7m8KkIxs1qS3z2QO22QgA9Sf5VRLZI7AU71Oc03APX+VaxVkYybb0 DHOcDrxzS8jpnGPWkz2x19Ks2aWzyA3MhRR2Azmh7XDUjjt5pVJRGYdyBmkaGVSAUYfUdK6e2u7F I9kc0aL7nFVL3WECmK3wxPBcjj8KyVWTlaxs6MVG7epz+zHrnNKCTjjp1p7NliSM5/nTeBkHrW2p jpYMkHocdqbgsMnI9qkHTpxiliieWQIilmJ6ChiIwOCevtS55/DitQ6JdhASFJPOAeagl0y6gj8y WPC9zmpUk3a5ThJK9imOpOD9DS5ySBwc0mTuPXFAODyMVdk9SBecHODijJAwent3oHr3PrSnA9RR 1HYb6k596bk89/TmpPbGc9aT0PAPSiwxASCCR07Gtu3194Ili+zJsUYABIJrE7kkY+lA6+gzSlBS VmOM5Rd0dBL4jJgZYoAkh/iLZxWHLK8rlnYsx5JNRk++PT3pSPlJxk4pQpqOw51JTd5MXjHagjjI 79eabyADjml5JGR0qzO6FBwcY/Gtqx0BriMS3BKRkZUDqfesZSUIYZBHStCPWr9CAZiwAwAQDgVF TmatE0puCleexffw5EcbJ2GOgIzWPeWwtpjEsqyEdcDp7Vbl127liKfKuepUYNZhLFiW5JPJqacZ r4jStKm/gQDIHBGfegnJHPT0peCPlGDR36fjWupz3QY4zjj2o5xgEHPUGjqOByTx710Wl6IMLPdJ kEZCZ6/WlKSirsqFNzfKjncHOBxn3pTwAMcetdgdEtJOREF+hxisHUksopPKtlJYfeJORURqqT0R rVoSprVmdGm9sDqeBXVaRYG3VWYDcefes3R7DzG85xx2BHWumiGCGxkjjFZVZ3fKjShBRXMy5byF GIIPNa0b4izjgis2NFyGIyT0q8pwuM0oRsObuMkyc4PFVH+TnvVhiRVK7kwuSenvWy7GD3MDW7wx KxHXoK5m1MzSjbIwyecHFdEuiar4n1MWem2rzMeTjoBnqT2FamveBz4QhtVvbtJL6YFjDGOI1Hcn uc1dNJy5TOTaTZgopVe3171JnAOOnYk0Y5Hp2ox146+9etCKSscMpXBRnk9qTIJ4zml34GBkjHNI vIyTxW6SWpm9rCgDGDk+lA5I6Zowc8nijHQAc/zouC2FwT9RS4wQSSfagdevNOOccjp6CjQLCdR1 xR0UDqfel2579aXGQBTBDVozyQBg072PUUmB16n3oCwlIfvdTxT8d+M+1NYZPIIPrRoPWwzknGcC juM4pcjdgc0vBPpTErkbKQeKcoweT0FLgEYPXt9KTHQ4JHqaSuJoaQQM9vXvTZBvQ9qkPOBjPFN4 BwaTXRlJlXJHH6etMdDkMMY75qd1IbOMA9KjbPQg49KykujKv1GW9w9tcLKhIIPSu30rVUuIgScE AZBPQ1wjKd2Rmpbe6ltZQ0bEHuPWuSvSU9janUcWemrKCQVGSeMCpyuUORg1g6LqIu4g3Jbvz0Nd JFiQAYOa82cXF2Z6FOV1cxbpACRjgVzWrWRlhJGdynI/wrtLuIAjjOT1rInt+pODkcisb2d0dKtJ WZyej3HkzGIkgNwPYiti6I8skZ4wSB2rE1O3a0uDMinbuzwK0xOJ4t4PDoG/Gt5tTSktzj5HF8rG TkbxnqRmuW1e7NxMIVJMcZ/Amr2q6mUJhiJDbQGbPTjoKwsknB5pxjd3ZLdtBqoxOOmeBWmtom1Q AG4GTnvWcDzSh2A4Yjnsapp9Ai1F66mh9iRm5XaPas5gBKwHQEgU/wA+XG0u2D1BNM6H1pRiwlJP ZCcgkijJ5AxilzzSYwe2avyJ1uOGfxpOc8H8aO2TzzTgeeQMUAL5b4GFOOxxSbGznB/KtlLu18lV 3gEKAQRjmnrLbNjLoQOoNZ88k9jVU423MHH50uD14FTXbq9y5RQFzxj0qHI4qzJhgAc4PNBHyjoK MgHkY96Mj8KAsIevXignjApe+P1qaG0luAzJjC4zk0Nq12CTbsiDHOcUvYccmrDWM4/gyfUGoWje PG5GHPUikmhtNboZxnPGaMDqOBRz6DNHPXtTYBg4NAyATx9KcMHrxSd8dqQMQcn3q/HqTRxiJolY AYGODVLgE+44NIDz7YoaTVmCk07o0xqcf8UJ/A5xVG4kWWcuqkAnIqM9sUD8cUlFLYcpuW4AksfS l5GQTxRk0nU5OPpVE2AEntS4bH8qBzn1oBJ659qa2HpcvWFslwHDKSQAc5qz/ZkY5ywz0xWbFO8R yjFT3wamXULkEfvCQD3GazlGT1RpGUUrNDrmxMMfmhsgHGCMGqgxzng1amv5Z4tjhSM5OBg5qvgY JA6iqjdKzIk1e6JrNPMuY1GCCRxX078LbZYPDskm0AySYzjqAK+btFjD6hHxkLyRX1L4NiFt4Vsl CnLKWOB0JotdnNUlZnQhsgg84NIhwx9/SlxhOeB601CpzjGB1NPoYtu43cS7KeASCDn86iciInAJ BbPFSSjOMHGRwRUau2Gy2cDAyO9Uu4a9Rm6KcFmUZGeD3rH8Q3sUOk3ZA24jOCeecVeyqSEgEjnP vXLeObmOLwzIFOWlYL1p7II72OM0a2b+yXnJOZXJBPerOlmGy1+zuZ2KpHIGYgZwB7UtiPK0i2jL HOASPTNVLhCZGJYknofShL3S7q56r/bnhm6m8+WWNpNw2tIpyCOhGegrn/Guk6bPFZ39kkQWScLL JGwwc46gfjXASFto6nAyTUUlzKYREsrFQc7QTj6/Wo5GNu+jPKioAJA603HGSadnJ/8Ar1o2mlNO A7uojPQA8ke1RJqKuzrim3ZGapwDjPt7UpYnrgDFdXHbRQoFSFNoGDlQSfrWRqE9kmY0iV5O5AwA azjWTdkjWVFwV5MySRnBJP8ASk3AAZyQOmKbnJzjHPIFOAHbkelarUxurjtwycE89BSdRznOetHB IAPIFPVHkfailmPQAZobAaCcdQBRjJPTHrUr2k8eQ0TKR7UzYyHBGPUEc0J3Bp31G4xg49qTHIx3 pwAJJIyKMHkgYFHoK4hGTyB9KCDjINLgkn09KXYcAnOKaWo1e4oA7CkxjGBjil5CjHNNyehyBTBs XrjP4itqy1a1tYQgtMHA3ODyaxBjHHSlyTjBFS4qSsxqXK7o6b+3bRUyqOW9CMViX2ozXj8khM8K OgFVQTjOBRtz7ZHepjSjF3RpOtKaSY3OScHBpcAn1x+tLgZHOPWmnr1/GtHojIdwT/Sr1hpU16S2 NsY/iPSqK/KwPBrWg1+5giWLZGygYAIxj8qmfNb3Soct/e2LMnhxCD5U5HuR3rNvtONkBvmRiegB 5/Grz+I5WhIWBEY9Gzmsh5WndnkJJJySTWdNVL3kaVXSt7m5HnPTFN4A59fWnZGSBScHqDWxgvMM gk/5xSsSQADQRWjp2lTX7Aj5YgcM57f40NpK7HFOTsZ5AA560BeOSc11D6BZsAFaQEdSSDWff6ND ZQ+Ybnk8BCvJrONaDdkazw9SMbtGSuOOlGBn2pAMDI654GKVvrzjtWtjAMDgA9TTMEEjqT0p2R27 9vSkyRnJ/ChPUeoHK4AGaCCfp1pfpyccZ60EHoRgUPcFYRcZA7Dtmpxd3EeAk8gHbDGq+eeMZHeg HOO9Gj6Bdp3Lg1K8Mew3DhT1BPWlsbRrubAznGSTUNvbvcTBFBOa7PT9PW1jUFQGI5NY1ZqCstze lSdSV29AjtxBGqKMAACrNsDjPPHUUSqQ20HB706NPnDc88HNc8b9TpqO2iNCN8gbhtHUU/ex57D0 qJSMYJ/CnM2DgGtoo527iPIAM5/+tWe0ct/ew2kALSzyBFA9SalnlABJwB3966v4W6SLvWrjVrgD 7PaKQrN0DHqc+w/nTqPlVzPS56PbQaZ4L8MiecIiW0IDyBRuc+nuSa+fvEOtT+ItauL+Zm2uxEak 52qDwK7f4neMbXW/J0rTZ/Mt4mLTOB8rMOBj1A5rzf5VGM9+eK7cDQcY80lqzkr1LuyGbcdOB2NB zjC5+tDSZHA4phJ6A16ii7HM2KE68daXaeOMfSk5wAO1ODHOTyAOlUkyb9GJsOOfrSg4A4zS56gn FJ06dfWmk+oxOoz270/PGB+tN5/GjIBwc5p2C66itgjI69zQM5BJ4xSY5wKd0GSKdrC63G455/IU 4jIGM0bhn0oBJ6UNAnrqAU+uTQQe/FKDxkfjSE55HIHWlYEM2YPPX+dHI4xx60pyeSeB0oxnqfek 9hrcM49eBTc5459adjBGTScZ9am9h3G5OfejBIJwOD60EYOc9aAcnA9OlVdNWYrakbjKngg5qA9c H+dWmGBnk47VXdOcnof0rOS1KVuhCcZOfxqLABJ9elTlCc46npmoyMHkZOKyauUu5d0e9a0ux82F bj2FehWd4GRcEkkcmvLgcEYrrdC1AOFSQkEYGfWuDE076o6qMnsdVcI20HJOecis6aIIuScE1pmV WjBJyBjAA5NVpAHlZyBtAGAR3rz5R1PQhJuxz95beahjK/KTycda55w+mSFHB8o52n0FdrKowTgc nIBrJv7RLmEo4znOcdvpUJtM0nFSR51PJ5s0knJyxP4UzjGc/hVrUbB7C5KkEoSSD2xTLOJZrhQx G3PUmuyLVrnBJNOzIMYHP40dyD0rca2QtgRgjoDiopbWBY2YoMKOcHFQql3Yp07K9zI7ZNHWl4JI 6UnHfk9q1RmGAOTRngE0vGORzik9Bjii1gTDnGccUuOM9KAT3p2xiN2049ccUgsNOMZGM0ucj0ow R2IHekIJx6UAg5A6Gk+nWlHbAP40mTTsMO/PejHB9qXuBjtR045OaEK4hPA65q9ZXiWyOGUnd6Hp VLoSDxS54qZJNWGm1qjWXUbc8MHHPXGag1C6imiVYiTzk1n9MEijnJx61MYRTui5VJNWYYwOetGM dSaP5ijB4yeaszvZAAOc0vf3peSM/wAhRjnOeMUWBNCAZwOeavHS5EAJYdAcYqkr7WDDsc1pDWCT 88IJ46HFTJO2hceW/vFc6ZPuwNp9OarOjRuVYYI4Na6atBn5oXX6NmsueUSzswJwSSMjnFKHN9oc 3BfCRjGcYNHqcUZxx3oyevAq9SEwwT6n0pcHoOvrmlGNp65ozn1FAhMDqMkUoAIqa1RZbhUYEgnH FacmlxAkKWHJ61EpKO5cYOWiMYA5xk4pwBx7+9aR0k4yH5Azgis7BVtpzkHnNOMlLYUouO50XhW2 8/UBjk8KBj1NfVenWwtNNt4FwAkSg/lXzh8N9PN3rdsgGQ0o/IcnNfTfAGPwoW5y1HdjWbLBcjbj nNRYCggAYI5AqX5QvOPxpWC57YxniqVjNq+pWm+6CMjaMVFkrgYzuHGTyKmnyRtAAJOM+3rVabzF jZVzuAzk1Udibdyvs3T/AHsgnHXpXCfERz5draggmR8gZ7dK71gqCMA/MwycV5p4odrzxfbxAkhD nB56df5U29LFR30HPAY7eMA5OAOKoXCFVP8AOt64iURqWGe4yeKyLsrICcY47dqeg9OhjTOAuC2T 3OapeYwHQAZ5Nblr4bv9Tb/R4HIIJDEYB/GlufCer2kRZ7KQr2YKSP0pX6ofkzxfOQOSO/NJ5jqw w5GBxgkUEnkcH0pOueKyaudexMLu5Ksv2iQg9QWNQ4JJwTn1NHQE+oowc5B/CkkDlcUA9uvvS4Az 3x0GaME9epGaAMf40xJEtvEk0oV3Ea9ye1dTY29lCgFs8bSAAFiwya5LBxwOfepOQoPOPaoqQ51Y unNQd9zq7y+hssl2DSdkBzXOXd613MXYADPAAqDccZOSc9z0pO/PAJ5pU6SiiqlZzYgGM4Gc9vSl zkjIx9KUAg8d6bxt5wa1ujK2gHG4jIqxb2NxeZ8pCQOCc4AoszaiYG5LbR2A6muhTVLDaESXy1HA G3FZ1JyXw6mtKEZP3nYwX0e9QkeSSBxkHOapyxSxNh1ZT2BFdDe6zFGuy2bzGP8AF2H0rAmkklkL uxZj1zRTlN6yHVjCL9x3IxnHTB7mk7c+tP6Ke4pAMnsB1ArTqYoQZz9OlPJIzz1HemAnOAeKv2Ol T343DCRgffb+nrQ5JK7Gk27JFHkHP6ZpcjORnitd9BuQPkeN8DjBxmqF3aTWhCyrgnkcjmlGcZbF SpzitdCvyAeDk9KToD2/GjJOOccc0uTj3+lWZpBggAE80ZOCKOTg559MUYyOSc0gG5GcYOc0Z6g5 OPelwAOTSdM8Y96eg3fQXnIORV6DW7u2jEUbjYOgIBFZ+eeaMAfh60mk1qOLa1RuJ4kuFA3woxwc 4yKy7i7lupzJKxLHtngVBzjrx3oxxyetTGEd0VKrKWkmLuO7qSaXdzxkH2FN5AzxzRk5zg4qiEtR 304HrVi0tpbuZYokLEkc9sepqrnBAycGrEF7c2rZhlZOO1PW2gK19djq4tEtI7dUlTe2OXJ5z6VD caHYiMuS0YUZJB4H51jLrt+hBM24ehAxSXmq3N+oSVwqgdFGAfrXMqdRyu3odjq0VCyjqU5REszC IkoDwT1NNVS7AAdT2pNuPfPTFb+g6WZ3M0gyF5GehraclCOpzQg5y0NHRNMEAErAFmGRntW5sySD jgdqfBDghcYwKmaL5lAx71wNuTuz01FQjZFGRF6Z5PWnRgldoByB1p7p+/A7fzp/3QR0/rW0Oxyz b6hnZjODkcU2RyM+wpkkg4A471DK5x1zxWyRg2Ur+cIhGc9eK0I/E89v4RGiW6+SJJC0sinBYHnH FYdy4Zju5APAqDeCSSOR0rtoYXntKRzVK7iuVDmYE4XPvTWzt9BTlQk5yR7Uu3jnk969SKSRxNu9 yHYevXj8qdgjBI/GpdnbnJ70uz159apLsLWxDg9utOwRycn8KfsHt7Ubc8A1SWgiPt1PPelxwM8+ 9SeXgc8jOKbjkYHFHUeqGHIPHrRwCT2p23PTil2nJ446cU1bqJoTGMtjFJnPpUvl9RnA96MYXpz7 0KzGRZGBk5OfSjB65yCe1OPHTmkzjp0oS1FcTjJ5NJnnjjNLg5B6jtSd8YoDYMdcjJNGB6H3pcHr SYJPU0rML3DGTxn8qCAOuPpR0HU80hz25FJpjW1wI+mfSm7CASD+lPXPBJ4+lLjCnnIJrJp30LXc YOTjk4FROMnkYz3FTY9OOOtNIwDzxTvfRit1KmME9frTGAyTjip3BGCKiIPJAz6Vk9HqXbQr45P6 VcspzFMME49jVVwRn1JpYzg8cfWsZpNNFRbTTO+sbzzYFIJyB0NWJJHIHzYBPOeprmNJuyCF3c47 Gt9WMgLdSO+a8qpGzPRpy0TLBQFSzHgDGKgkCbcYA454/Sp94xjOQOMe9QSpkKehzWD8jpT0MPUt PjvImjK4YAkHHOa4W5t5LOdo3GADwa9MeJtxC4x6kVjaxpKXcTDgSDJBx19qqEuVk1Ic6ujihPKA P3rgdhk0puJWUqzsQexNNnhltpDG64IPcU3GcnqRXSrPVHHK60Yc8nOKTBJ60c88ClHT61QmHtRn t1NHfI7Uc4NF9RdbCggnB4rehMIt0VXTgcjIzWB24ozg1Mo8yKjLldzpPIUqOFOfTBrI1DYJwsag bRzgYyaqbyMYY49j3pGZnJLEk+pNTCnZ7lzqcy2EyO2eaO3Y0YOB6UoBPIzjvWjM1YMjB9aMjHfO KCPTmk56UeYdRQC52gEknpUxtJ1JzGwGOeKbblRcIzHC5BJrc+0wyMcTJj3PNROTitNSoRUtG7GC 0Tr/AAsOe9Nwcds10S+WTlmQqOTyCKwpyDPIVwBuOBRCXNuhzhyWSZEOhySKBkg4P60fUkGjPWrI dxc5oAz06+9JnpxyKOwPPNINhR0INJxngHNSJG0rBVBLE4AFSvZzoeUYEcYAobS0Y0m3oQc+/wBK byQKk2Ov3lYenFNOccjihNWB6bhjjv8AjSc56/pTuwHOOxpDxx2pai0Ac89cU7JBx60nOcD/AOtS 4OeabAcjtG4dSQQeDVxdVuAuGCsc9xVHHr+FHOfbvSsnuUm1sai6u+BuiUn2JFUCfMnZsEAnOM9K i5yOpPr6VNGCzADGSe9CSWwnJvc9m+DdiH1WORh/q4mfkdzgCvcSePpwa8u+EFkYba5uMfwKg/nX pyggn3PJpJHLJ66CEAZbPUdKj4kbacgjqPUVK3X8Krx5MrHJ9iTxmrRm3qEwJXA6KOvr7VAZmOAV yD3FSTRF4iGPINVyCEHzY96pbDvpYjkCBCxyCAQBnpXmduWvPG104BYxqQAe1elXeVtXdeAASc8Y 4rzjwxK51DUrwYJkcqCfqc0+oJrlNO4RmjIYkjPIpmm6X9v1SG2AADHJJGeByaln3Ab8jGea1/B6 KdcdieRGSAe3IHFFR2Q4JNpHX3dr5elNbWqbSE2qF4xUeiztJamKbPmIdrButaGzMm4k/TNMaCFW aXAUnlm6ZxWKkrcps4Pn50fEBJ2g9s0dCevPY0vGcE4PWpYbeS5kCRIWPtQ1Y13ZFjkcnpmnjr0w RXQ2WkR2wDzrvkx0PIFTz2tiqF5YkUAdenNYuulKyR0LDyceY5fnPPFLn5scZ61Yu5LV5SLZCq+p PWqeRnPHXoe9bJ31MHpoSbueQCe9Ozx6VHnOQelO4IGOop6BbUfnkYGCe9IRnvzSZ6EHOKByepxi gQ7JPHNBAx7+hpMgjHeg9B3x1NHkGthccA4FGBjk4+gpuT079hS5Oc4wO/vRZB00EOMEr26Um8n6 ilYEkY45pMYJzgZqg2EJJxkdaARgccClwSOc49aMDA6Y96Wga7k1q1tHOHuUZ0HOAcZroI9dsjGF 8qSMDoAAQB+Fc1jI6DGKXqAQcVE4KS1LhUlB3idFca7AiYtgzsR1IwBWFNLJcuXcliT1NQ859BSh yCeeveiFOMFoFSrOo/eDB445owM8cnHP1oJ9+aAeOnStFczE5z9OKmtbSa9lMcKFjjkjtUIIBJIJ NdDZ63ZWlssSW7ocYYjBLe9TJtLTVlwim7S2K7+Hp0ACyxlgORzxVWXR7uJCxQEAZJBGMVvDWdPK 5ExBAzgqc1ialqzXhCRApCOgzyfc1jCVRuzR01YUFH3XqZeCCeM44xSNjPXnHT0px6k0YBHqe9bn Ixo5PJOO9KCM/TtRgkEjBPrRtxnIx9aegugdTjHuDRk+xrUstGuLyIy4CIehbv8AQVI/h67DEK0Z A98ZqPaRTs2axpTaukY2QDz/APqp+8ZyKnu7CezYLMoUkZGCOarDHpzVqzV0ZtNaMdzg5AyelSDh RgfU03tnr71IiGRgvTPQ0OyV2Cu3YtaZZNdTgAYXPXFd5ZQJbQiJVHAFZWiWS28WWGWYc8dK24Rj qM+9efVm5S8j06FNQjd7lgDgkc471HzuxnIHWpl4QgA5Jwah5Jz07D3pRWo5yIWwZR6DiiU8ADjH WhgEJJAz6ZqBpCWx2FdCVjlkxjvgniqF5cCOM4JyeBipbify1JJz6e9Y8ztKxJ6Z6V3YahzPmZxV attEMLM5GTn371LHGcZYcZ4pYIsAEjjrUrFjgDjjgEV6cV22ON+YuMEYGfQU/A9hn2p9vaz3HEUM jn/ZUkVfXRL0jLxhARn5jiq5khWfQzdnPGM+tBQ8Ec+uK1YtP8xCmQrrnOeQaYbTZkMoyByalVY3 sVyO1zNCnOSAQPanNtA4AqSbCZGQRmqhYsSR0xzWyd1chrUcTk4zjPbNNAPPFSrCSAQCc+lSiIkZ AIx1yOlHMgs7alYIxxwKl2BAQetOLLHkDBz0qu784zz0p6sV7LQcz4GOKiL5Gc5puc+4FPCNjpVW siRoyWOD26U8ITkDHvUoiAPIx0pTtGD39qLgiPy+AM4pMAHBOce9KXIPTkiozuPXr9KXoNDyQQTn pTCeBnOAKXbzgY59BTguMDB+lGgXIuAM/lRk/wAI5qVohgdvamYIBx17/Si+oLRDdxBA6ZpDyTnn P6U4kkD1pvQZ7nnipdxpjeQACcGjfnr0HanEgAHB6U3qMjp1zioaLQEZI6Y96ruCp9RnipsnI55x TWGQcgDuKznFtXQ01cqOCAc+tMU4OOlSsCc9c+tQdHxWD3K16Fy2lMcqtnAzXUW07mMYI56Eelcg DnPbB4rY0+9LRKp4YcGuHER1ujqoy6HSK67cFiAOT70ffAUkj1JqrCA+ATg9/WrpTnI/CuNo7IsP L+Qnp2qtJEqqWYgknAHtVxPQn8KjaEli7YGTx7Vk0zeLucxrGkrdqSgCydQQOv1rjJYnt5WjcEEH BzXqEq7sgKRjuRXOa1pC3KGVAN49B1rSFRp2M6tO6ujkcjJx07Udc5HFDIY3KOMEHvSZ5IHSupNN aHE1bQMkZIPFGe5HNAPGM849KBnIBxzTsIWk6nrz6Vqx6dF9nVnJDMM4HpTTpi5BDkDPU9qhzinY 0jSk1dGZ+Ipe/fFWbq2+zMAWDAjPA7VXxxz2q1Zq6JkncQ5I4wQKcCMAfzpvbjoetL1A4oELnB44 +lJwTj+QpBk56UvTvigNBMjoOaMfnRj2/GjHPejoCaHZIBAJ56470325owAcnOaXqD+lINGxO/PF B5GcjPpRggHI7UY5yKYX0F5BPFA7Uucn09qTk8jFFg6FmwlWK8RnOFBOTW19ogkfKyocngZrnc+u KMEg9vxrOcOYuFTlOl2IwwGQgHoCDXP3AVZ3A6AkA1Hkg4BI/GkzzkkmiEOUc584oyODx6UuQRnq aacAd/agcelaGe47t7mgcHJBwKDgD0xSjnPp70eo9hcbiAByatf2dcLg7M5Hr2qqCQQRjrW/Fe2z xqGmCsFAIIxUTbSui6cYylaTsYxtplODEQT7VPYQk30SFSMsOorZDxOcLKjDGRgjIp1rGJdYjAUE Kucj1qIzb0aHVhGMbpn0D8OrbyPC4kxt8xyQfYcV12TgY57/AFrL8L26W/hixiAwTEGP1PNazEKu B17VpHY89rW5EzsSwI4x1zUeShbcvBxjFSOQFG/jJycdqc7LJwOCORmqIK1wWKBRkNnOPUVHG5JK MgIx19KeQIixLHPvUeWSVWOApq1sJvqY3iG7Fpol4+cAKQCT0JGK5Pw1ZlNDSUjmVixz3GeK2PHc qw6LJEThpGA56VYsbdbTw/ZgAH92BjGOcULWRW0dC3odnb3VxcLNF5ojUFVPc1LN4YkuHN5YyG0d jxGSRtHfkVz0l1dWc7TQO0ZIwSpwahXxHrEaDbeNtDZ5GSaicWXFq1mjoJdI8VWx/cX/AJqk9Nx4 H41z17Y+KTL9lnkunV2wAGJB9en1rQsfHs1rMRfgyxhSBtGDuFS2vxPtnd1urNgwb5NjZ49896hX W5VotaM+XuMg44x6VJHNLEcxOyZ4JBxmmemMHjnJobAAwDzzTaOhPTQux6xdxqAZC4HTcM1Dc301 1gyNnJ4UDAFV85H17UbMnJ6+lSopO9iueVrNjSexBHvSAjjHSpCCQOMg0FOcjH5VWpL30G4PXoKt 2VhNeShIlJz1PaqwXg55x1qZJJIyDE5TB6gkUmnYNLnVW2h29mAXUSydyw4B9hU0llaKpeS3jVR1 JAGB7VzK6xfRsALlmI6buR+tMudRurw4nlLAdAOAPyrD2M3K9zrjXpxjZR1HahJbSS4togiDgHua pdPfPtScknnntS4yOvP1roSsrHJJu9xNxA+6aUbiOMZJ70uMDJJ69KkihknkEaAsxOAAOc0BqRc7 sYNLsOeV49a6iw8PiAia7G5x/wAsyMgH3rRe3RwF8lcdhtGKxniFF2SOmnhpTV3ocMBjqOO2KaxI +nbit3VZLCBWhihVphwWA4FYZOR149xWsW5K+xhNKLtuJnI5FBJAIxR2HI9vakIJAx1PeqsRcMk4 4P1NGenPP0oyAAOc03POTwM0J6APJyRnjnrRxu9zTcc5FLye/J60wYvHr+FHA9eKMH8RT8YAyOcU 7ajvoNAIHT6YowcnJ4xTuQB1GaQgg46jFK2oric5POfYUdjwM9KM8nHXvRxnrzQrBcXnAI79qtWU lrFcq92jSRjnaD1+tVcYA9PrQUIx1I65oeqsO63Otj13TigBMiY+6pXgD8Kbda3aR27NBKsrnouC CPc1ye3HQZ4pcNxxWHsIt3Oj63UUeVD57iS5lMsrEsf0pm0njOD1OadwBwATTcE88ntXQkkrHM3d 3YoA71saXaebIrEZGQayYwGcDkc+ldfpcXl26kgDuKwrzsrHTh6abuzagiIZeO3SrYQHOcjmo4WU qCCN3cGrBwcZGcntXFFM729BnIAyeDxUTSfKeOR6VI5AyQCMcCq8jfKcnnPNbRRhJ6jHJPPPPIqt NKEUk9upqRnAySeKoXIafIBIHtXVRpubRxVqnKjPmla4c46dhS+Scqqjk4zV620+Z2xDA7n0Ck10 ulaGkMAuLwqrSECOMjkn69q9S6irI4LNu5Lo3hRrnT1nktIyP4Wd2wx9sAgfjUq6BcLZNObK2t1D ZQyAljg9emMcV2NnLFbWUKLKJFjwgjBGMk/T8aj1G4SWEQ+bG67gDtUDA/p+VZOrJLUv2ab0MS10 A+cDc3sqwlQVMJWMFj1HJ5wPx5qXV9H0qy0mS48hmcAgF5mYg9jwMEk9qL24d41VHbZuHHA7+wqh fSyzoIDnbu3HJJ/QnFR7V31LdNGdp8RMQDKA55z3qtqNsW3MFIAPboa27SLktjAx1IqO+ibbswSG B5xWftfeuaKGlmcZ5fmkAKSc8YHBNacGjpHGHkCo5GcEk1pW2mNFKXbGCOBjpVma2LyrgkL3zWrx LtZERpLdmYtiqQlpCME5yB/KocZBCLlenI61syWryY5GAOMDrVR4DGp2gc9QeazVWXcvkRzF1bFG Jix9Ac1RwcgEc10E4MSsVA56jH9Ky3A3cjj0xXdh67b5Wc1SkkrorrHweDipeEXkfjQTgYAxxUZJ Peu3VnNZIdvyP/r0nUd6UJkYxmniIhckGloCbIsfiKcEyQc9qlwoA5B9hUe4dQe9A9BcdQePShmw BgYP1qMv3OaaTkAdaaQXQNJx1BJ7elNGT1JGKUL1Pp0FS4G0EjPrStrcLkRU4JHb0pMYOc/WpC4U HioWO4EgH8qTY9NwLY4GPxpu7gDsaTHt2peAfUVL2DW4pAPSoz3wKfuBYjpSEj15xWbTRZXcDGQe DVRxycCrbA4PUc1UfIYjp+FYVFZ3NItWHqc47HFSWk3lTgc4bg+1V4wSOefpS4GSAehzWU4qSsVC VmdbBLiMMSTzjIPQVdSVgFGc5HBrCsJ/MiAyenIPrWvCx2KuSeec15U1Z6nfB6aF6Il2JJIxxx3q ySDGCRwOBVaLGeuT3xVgFSoUgk5yPpWTOmLsytcjKgAFQT+lVpoF8rgEjrWiyZPzc98CoJOIyqrk k1Jpc4nW9KBBniXBAyQP5iuaztJVgQRXpM8QQEE7jj6iuR1nS/LcyoMBjnHpWtKbWjOerT0ujFzn HApc4GeMj2puO3AI6ilxg8mutanH1NFNVlCbTEpIAAPSpU1SIj95C3uQayjnJpOcZzUOEXuWqkkr Jlm8uftMxcA7QAAD2FVckAkgn2NB6nrmlzxjNUlZWRN7gDgH60fh09KT8M0ueeeKYIAOeuKXqOve k9s9aOgHP0pA0zUj05HtY5GJ3MOxpDpYyCH+oIoi1VUijieLIUYBBwTUw1O1J5EgP0BxWMudO62N oeza94oXNk1socsCDwKqZIPtWlqF5FPEiREnBySRWdjpxzWkbtamcuW9ohg9uh9aXkH1pPrQAM0x C8Z9DSc5zjFGOcg8UdT1PHFMXTQOcj+VLj171esLRbpnDE4UZGPWpjpgOMPyPUVEpKL1KjCUloZn Tofzo78nitE6Y4XIIPBrPxhiueRwR704yUthSi1oxQMkZIPtRjIyeCKbggdh607j17UxegA4GSQf Wl64P9KQAA9OtKCM45zT16BcXOcjH5CjgkZHHTIpAxBxzS5GeCaQJjlyDnOD2rqPBls1zqignIZl UA+5rls816b8KrD7Rr1nkDG/ceOw5pS2Jm3Y+iYIFgt4ogMBECjHsKVgGOCOnQ0853daiY7CTgk0 I5pWK8kP7xeW5yD704rld3IAPIqQkOmQcEVDLKSu0Z5HJxVq5m9w5lToDjtnoKrmXefKIGDwCexp 8T7PlZiMjqKbMIYzmM9B1PqaryH0OH8ao1zf6bp5OXklHOeDXVNbK/lwgbY41ABHcgYrjriM6j8Q beEMSYgSSegI5rqNUlaCMgHA7nPeiO7G1qkYesKYmdAQAD3PWuYubpgdoI2554rW1G588ksSx+uM 1iPaSzqzLEx75xnFPRblJLYqTzk7ipyev0rJaVQWLcnJyc1buVliUqVKjOCcYrMkIRtpGSfWpb0K Vtzz7GB2ox9cZx1pcgk4BNAHTIyO1Z6WudKSE5wfSnYIPUn6dqXg5zxg4NXItKupoi6Jke5AzSck tylFvRFTOAc8+lKSNuMY57dKsSadcwk7oG6dQMgfjVcqUbByPbFCkm9AastdBvrnjsKXIA7+/NKM Z6Hg03OCeKbJHYBwe/fNN2kEk5wT0oBAH+eKdxkYOTjJoFdh0PA4NLjJz6CkwRhsE5PT0o5GSARQ NikZUEcU5XaNgyMVYdwcYpmSFx1HqaTcc44/GqT6CNCLVb6IYFzIQTnBOefxp8ut3ksexpj74GCf yrLPJ+lABIz3zUuEW72KUpJWTHscnJJyTkmk29hxkUYyBgnjqfWnkZ6DrTXkSR7Mngn8aMkDnB+t Ljg/TpSHGNxzgUwLFnYTahMI4QCc5JPQCuktNJs7SPayiWTGGYjjPfFcxBdzwZMErICOcHGavw67 exjDlHAPVl5/OsasZy0job0ZQjK8tTdbSbKdgTAoyO3Fc5qMVnFPstdxxkEk8celSXutz3ahBiNc chD1rOBBOc9aVKEl8THWqQm/dVhMEDnABH505cEjOeOKOpBIz60uRgdK38jnFORznj6d6AuT7dx6 0uRnkVPa2c97MUhBLHn2Ap3srsEruyKxABODz6UHBOe9dVb6JaJAFuELynqwJ4PoKQ+HrR1YrvXP Qk8D86w9vC9jo+q1LXOV6nGc0mRgAc+tWLyCG3uGiil37SQTjjNVTwT61sndaHO00P6H+tLkFeDy KZkAdTmjAIAIxTuFkLvyOfwxRyRngim4GMDrS7STg/hRoCLdpGXkBA75rq7OQLEF5GBz71z2nREs D0A9fWtlHJGMEKByR1op4f20rvY0df2UbLc01u9rdRx055qf+0VCjOeDishSM8cfhk1KgAJzzXQs FSW5l9bqMvvqalMAGo2vwwGFOB3NQAqMHA96R3AztGSP0qlhafQh4id7sSe53qCMgnrmmxXbwSLI hxIpyDiofnlcbkIA7k9aeUByMA+ldFGgoqyMalRydzRHiS/LEvdOwPYnj8qim1i6uiC0zMQMLg4w Pasx4TngfkadFCwYEY+p9a1cYR1M05N2N7TJ7zz1YzyEA8AkmulQygjfnBHJPUfWsbSwRAu8jcBw cd62InZwSxOPcV5uIq3lodtKCUSNUmeX7wKg9utWHCBRuB3HinA+UMrjJ9qA6gncMgDuK5XK7NUh 0ODySABTyRkjkjsSKrCVVUnOBnpUP2tvNLOSQBwPShNWG1oaOQsZ3ICccEmoVCOSSTn0zxVS4uy6 qMgAngluaFmUEgFcgZOTQmJokuHABXPAHTpWTNPsBIBx7CrE1yBnJBbH5VmyTk5GT9RVJk6pFO7m JjLKCCe9Z8m9lBOCfUVoSB2yTynrVaTiMhVOT0IHSuqlLlaM5q6ZURGIB6fWnAIDyQT3qORnjOCD iq5nBOBnivYjJSSOBpp6lsyhchRimNKc8Zwaq7yQOuaUZY8kj61SRFyUuT3PSkySCRwfehVJOCOR +tPxgYIxnuKAVxuOvWgKQMk07GTgHOKcELDPT69KB21EVee/XnFK7BOOc0b9gwOp/KoTzkkE+9Jv QLWG8s33qeE5OOT3NCocDjrT9pycHGaQ0yFhyexpuCTxVrYPc9zmo55REmABz2qZaK41qyELznge 5NMwckj+dV2lYjBPNN3tjg5FZtl6IsFCcccVUuUIAbHHSphMVxnmiUiZCDgZHGB3rGoroqLSepUQ 8Y6/SlJO4j1pkfTBzkEg/Whj84PGMYrOWyZdlcu2E+yUqTx1rpbaXIB4zjpXGNMIHVvUjNdHYy71 BBweK86vBKR10paHRRHbGOOSc1LCScknPOM9KpwzYXBGQBUwLBQwOAeoxXI0dkWrF0/MvQg+tNCg A7uuMCno4MYPBGPxqH5iucjPr6VJomrkDRoWYgAkdT61nX9srghkBGMEHtWxCg2luORyarzouOc+ xxmp1TK3R5tqViba4PBAJyD6iqAAxnnNdxqlkJYiAMn1xXPJBGh2sik56kV0QqWVmctSk3LQycHP JApMc5zmts2MDtkpgcdDWbewpbTFEJIIyQeoraNRSdkYTpygtSvjB684pMA9AOtGDxS84qyLKwuM Dt+FGB1yabjIHvTsce4pAkN7jPNGPbilHXvR2PrRcfmNwSaUYAJ6n0p2MDnJNNI64ouwXcMZ7fjQ AQO5oGM+maCSDxxihgtwzk496MDOKXGR6UnvQD3AA885NOxkd80d8nrR/WgNC5Y3v2NmLKWDDBAP NXRqdqeSsi+mQDmsfgHPWmlgTnv2qJQTepUako7HQnULYqcS4OOAwxmsFyDIxI5zn2puCSDnt0p2 QQOCMdzTjFR2Cc3PcT7w449aXoOentSZO3gUAHHvTJSshQOOOn6ijHPrRnBNOzknjGO4qgVhpznq fwrTj00SW6yK5BbsR0rNAPJJzWvaX8EVqqSltw6YGRWcm7aFQSctdiH+zJA4AKkflmvZPg7YFNS3 EZ8qEkn0JNeXRS2kzKBKAx7EEYr3j4T2Qi026ucDDEIpxycDn+lZxcn8QV4w0UT0Bjg4x1qKTPzY zzjHtUrcfU1Fj7x55rZHDLRkR3bdoAX3NVJC5OFI64GDVuVTJAxztPrVRU4DEHPv2q1YjrdjyAIy zEZxyPeq7OAoLnC579TUpYYIYYwOAO9VtZYW+nPJgfKhYevFPyHo2cZ4fAv/AB1qNyM4UlR+eK6P xBzhfQc1g/D9GZru7wQZJDg/5+tdDrEZ27iSMjmiG1wl8Rxl6mGA4yTyPQV6T4WtoP8AhH7f92jb gckqOeT1rza6VzNjGcHP1FeneFwRoFtn0P8AM1nUvY3pJORLe+H9Lv42SeyiO4csFAP5ivDfFdlY ab4huLewcvCnB3c4buM98V71ql4NP0y5uzjEUZbB7kCvna5JuZ5J5cl3YsSTk5JzRT2uyqiXMkjz AjqRgEdiaMEkD3wPSmjBHOD6U/tjj1zQaXOg0rSrUKJppUkkxnZngH39a12UKu7ICgZ9gK4gMQuA ce445p4nlKhPNcjHTJxXNUoub3OmniFTVram9fawsBKQAO3JJPQGsKSVpG818sSck1Hk5A6gjoOt Hfvz0rWFNQRlUqyqO7HEY9AD2pNpzkEHNBIJHAwPQ0vYjnBPFaGasNI4x1IqS3jlncJEpZj2AzVm w0ybUZwiMAB1Y9h/WurtLKPT4CkK/NjBfHJNZVKigtjanRc3Y5J7S5hJDwuCOvHeq5BwM59+K7WY rFEZZnwo656n8K5nUr9bptkUQWMHOSACTSp1XPoXVoxh1M4cgk5x0FBHQY4+tIDtHAOAaMjGSSTW 5zNIcdowOfekHHPBH9KTIIyCfQ570gyM55NK4WQ/OBjgewo5AHXHY0gzjgZ+nakyepHI9+tFwH44 4PU03B6ZyKTsAMijJzjg+1OwXewu046fjTgDgkkEetJuwRwfpS7gBnrTBrqIACcgD8aMHnGPrT+p GACD0pCQFIxgigSegmOMfrS8AZPIB6UZO0YGR9O9B6Y6c5x60DDOTn3rS07WZdPjZI4YyGPJI5I+ tZu4DqCB34zSeYACB0PShpNWY02ndHSReJ4gCs1rn3Run51T1LX2ukMMGUj7nuaxM5PTr2FGOT3x WapQvexo69Rrlb0AnIyOp9aTH0z6UuSByMikycjsK06mY8AHFNOMkCjJpMnAwM4pq1hWW49VZiBy SemBmt6LRoU07zrgsJSAVX0qjpF/BYzmSa3EnHHqD6itWXVra9XbGsitkEhsYFZz520omlLk1cmM giSGMADHck1N5rOSEAAz1pqoWwOT3NTrtTJAwB+telTSikjjk+ZseuI1HBJPU1IMnBIPPU1GhyMk HHYVICcYzyelbJXM3cXJyAMYHWnL1zwT2qMEgnA+p96M4UjPNaJKxDeoM2GI6n2oXkZ5qLJJHQ89 af5gAwDzVpWQnuPT55CMEj2q3HEMbQMg9QR0qvbofMAGMnk11On28RHzKCSOcjiuDFV1DQ7cLh5V dSpa/u0C5OB2I5NakWXUY4A/WorvTyGDQsMZ5FOSeOABSMMR0ry3LmdzrdKUNCXewbaSRg8kisy+ 1PY5RcEL1wetX3laUFVzn1I4xWBdW7JKzsy7c44FJ3BLXUT+02nkwX2Afmatw3cbIFDkkdcjk1gy KiEsSoz2AORT47pQvA59BxmhMmSOhM6j5icD3PNV2u4lk3AMQOTk8Vkm7DkKwOenBpzThOCAAe+a pNktGjI6yEyhj9D0qDBkICgYPoapxz7yVyQPUd6swkNLtOMY69KdxONy0kAbGTnbwV7GnG0CjlQC ehHYVbs7bPqR65zV940SMErnB5rWMiWmcfdWjtJlSSOayzFsY5HOa62/jzAzRKBnocYrnXtmDnJ5 z0NenhZ3VmclZIrAc44p4GScYPtTwnPXHrxwaXhDyvWu67OXRCYOMcZoEZIweB1pfN4OBimGQnvR rsMkAUDJ+mKaXycDgegphJIPrTOQM5p8vcV10Jcrg5waMjPAGO9R4OM9qAuRkHv+VJpdRptkm8cY 5FAOfWjZ8w4x74p67U6DJz1padBWbAssaZYYOO9UCGnlJA4HTFT3BMjBSeD15qWJAie/86iSbKVl oV/sy85HNRfY2JIUVfzzwAPenZ4J4qHTKUzJkjSDAckn27U2ONpThTxVkxGWcsQMZwKnVQFwBjjk e9Qou/kU2jPaxbzCyuBnqPeq1zFJAoLqQAcgjkGtfBDYzTgpI2nBz2Pek6SasgU2nqclNKZXyMgD pzW5pFxujCk8jj8Knm063nBBjVSf4k4NU7azmsrvgF4T0I6j6159ahJanXTqROviclFA7Drirm/C rkknvWPaT4IGeCM81qoyMo3YzjOPSvPlFp6nbBpotxllI5ABByKexXaRwM96ijdSQSQVIIP1psxI ClQMZGaysbolUFI/mOATgUyQB1J3YPt2p/3wBnAHOKichD83BPp6UmirlG4QyAY7e1cvqkDW8hmA BGeQa7OQYiyACetYOpReapXaOeuacbpimro55NXjAAaAgjrhuprNupxPcM+CMnpS3URimYEd8VBx nmuuCW6OGcpN2YuT70gA6UE9ODR2OBitLkPe4c4xk5pRjHJOaTGCOevrQcke59qAuGR1FaOmW6XD SGRdyhSR7Gs0ehq9Y3xtCxMYcMMEE4pO9tAVr6l19MickqSvtUX9kbgdsvPoRUw1W2cgNG6jPJBB pw1C2RWZWJODgEY5rBc6dmdD9la6MR0KOyHBIOKb3xgZFSO25yxOSSTmmE4z3Nb6nPdX0DnBH+RS 9AOOelNAOfWndR7etAw6nGDRjGelIcZHqKXsfegV9Q7HApOwOMdqvW1g1xAZAwUA4Oe9OOlzAfKy kg9CalySdmylCTV0UN2SR0NGDn19Ktvp06EnbkDk4Oaq8jg469KaaewndboXtz29KMg9MjA4pCST S9O1PUW4Zy2c0YGMjoepo5BJyMdqdkgkdc9BQCWomDg9MUq/eGfwpMk8jA+tKORk49qGguaOlxmS +iUYILDOa+qfAdr9m8I2mRzIC5/GvmPw1CZdRTjJxx7dq+tNJtha6NaQYxsiUfoKzdrmbu5Flhhf YVEOOR36CpnwpPPFROCCCuOuOatGE1roMYMAxY5OOB7VWklwM7cDcOD6U+RmMgBz1waJowcZzgDj 3q1czZXaIy3COoweQM1ieL7nyNDuWc4O3aD3ya2gWKsVIyp4GelcZ4+uCdNSDkGSQDI6mm9rlQ8z Y8DWP2bw5BI3IkywHfk1t6lpL3lm8kR/ekZCkcH2qtoto9lpFsGJ2rGOPQ4pX8TLZsEliLKOMg81 OqWg48vN7xylxpt1bmTzIZMrjJx0FXdG8XNpVstpNavMuTsKcHJPTmuntPEthfTGHmM4JPmYAOPe oYNU8PO5INujRvgblA6dCKhybVmaxik/dZxHiXxtPqunSafHa+VvbDndzgHpiuGkUhTkEHPU8V7N qGj6Jc6vp00SQmSWUuQuCHABPI+uKm1rwVpurRkpGtvKcZdF7D2oU1sPlfqz5D4wNy8nofSjeOTg +w9KQkYGAaQ4yc5PHOBT6GyQu885ANJnDe59DQCCOPyoCjPA+hNINR3PGQR6HPIpRySAOh9aBwQC MinYx1JwORTC1gwDz0HekAIIJ4APTPakABGRnH1qTGeCMD60Ni6Do5ZUYFHZR7HFXItUvYBtSdsZ zyc/zqipwc7cClzkkkZBPrScU3qh3a6lm5v57tt0zljjjsKqHIGeAPrQThsn8Pakfjvk+lCSWwNt 6sZk5yCPwNOAHUnJ603I69vSjIU56GmIfj5c5AB7VLa20t5OIoVyT1PYD1qAsSBkHFXLPVZrHIh2 kHqCOTSd7aDVup0drp1vYRlVCyyEYZiMjPtTmsbafG63QY5JAxWVF4kGQJ7YEHqUOCai1DXWnj8q BTHGRySeT+Ncvs6rlqztVajGFktSHU/sCMUtVJYHBYNkH6Vn5GTknNIp9cHr3oPQHqK64qyscTd3 cfnHTk9zikUYfjkDv603tg8etL2wpqhPsPzz8pyaTt1/OkC455Ofatuw0Pz4hNcMY1PQAcn/AAqZ SUVdlQg5u0TFzxjBx7UnUDPPv6V00mgWxyIndeRgnkVnX+kCxhLtOpz0BGCaiNaEnZFzozgtTL6E 9/w4NM6tj+YpT9TRgY6kn3PFaoyTEBIORRzkntTgMgnp9KMEDigBMe/FLggg4PSjpgY/Gn8Y5JwR 1pgxuABjqfpSYBA447560owD1z9aMYxyPWgSsGMYAHSr2nJmRmx0x1qlxkZ69MVq2duY4AxBBY5O auCdxPY0wQemQcckd6XIwAecHrUKnjAJBPY1Jj5cHtXUmzBrqSoR0HWpd3U44FVkkAzzx9KUsdp6 Y9q2jqjN3JUcYJ5z6GkYkg0xT1IBPbmkySSD16VqrWsR1HADFOX1PIpmQASc5o3g8A/Wm3ZDS1NC 02idfU111rCRACMA9q4/SmL3GWOAOhPetW+8WWGlxeWz+bJjhEOT+deBi23UPewbUaV2b8iMVzkE j3rOu544h+9KqQO5wRXEXXjXVNRkMNjGIgxwMDJxVR9I1W8Yy3t6VzzhiSayUX1NJ101aOp10+v2 tuCq3CLxzzmue1HW45V3Q3Mjc54AAqK28MWMpCzXchbGTtHAq5ceD4orYzWMryEDJVz1q4+ZyuLa uixoWnPqcTSzuWU8gg8/jWhLoUSEFCwOehNYGh6q2kXoSUlYWOGX0969BBSeFZEIYMMjHepvqdFO MJLzOQns3gPp6GqrhnbliOOh5FdjLbK64ZQQfWse7hSPO1QB34xSuyZ0Va6MhUcnAIx9K07eP7rB gcetLAUIAVQSOgxVuGFSSTgd8YxVxZzyjbQuWkuDtHUj8KtO4BO4EA+vSo4pECg7Mke1JJIZWCjI FWnqQ0JcIssG1WwfpWHcQEFmYgjvkdK3VjAYqT+IrN1UiJSdp2gcEetdVGo00kYVIKxhOFDbcYI7 im4XnJOaqeaxduetHn4xnmvZi7pM897lrysgYIx70vk8DpnNVxPx1NSLKDzkcU7uwJKw/wAvB6ge 9Hk56mjzFIzk/gKTzDnHNGtrhpcXygRz0zS4VewxTC45OOPY0m4YwCRmkF0gZiTwRikHfkmkyO2Q fWgHj096ewX6oQjLDPI6Zp+fl47U1cYySc0u4Z44HvU3DcUA5/pikkcgEAc54pd3cHI9aTI64Boa bQ9ELGoAGeOOaOAxxml3dAvJpD3INStB6NEbkCUZAwfelI7jOKikyZB0GOc4qZjlMA9BUJlWbVmN I+XI5wKFOT16dBSA5AJGBim9DnJNNrQFox28ZOBz7dqljuJAchieO5qvnnI/EUeZt6Ej04rGdKL3 RcaklszSh1B0PzDI7gdq0VvYpowu4qxAwDXOZ4yM5qxb3IiJ3KHQ8FT2+lcVbBJq8Dso4tp2mdLF OpBUEZ7kU2ZyzgZAwc8VQis2kiM1jLtyOUc5APp7VV+2y202LtCuDgMOQTXlyi07NHoqSautjVaU kEYz6Cs64QupIyOfzqaO4ScFkbORjI9ainLGMquAR1OKnYu90ctqtsPvDr3PrWJk7ueldTfQHyyT z1FczMmyYg5+lb0nrY460VuNJwQQKb05HXtQQe9GAOPWugwFJwee9HYUh4I4zk07scUIQ3JOBjAo 56Dilxnik4I/H86XUatYXk8Y5pcnp1FGPqKOAehPvTCwnQjqaTPXilz05JozkGkwshQeuOD2pBnH HJzSj2PNHPXPNAW1uHU+9OAxnJJxSH9fajPI5zTBWZradeW0Nq8UpIZjnOOKuefbn7s6njOOhFc7 kE9DSZOfp3rKVNSd2axqSjojqPMAiZgVICnGT1Nc27AyEgE5PbpTQWBOGPNB7djVQgoomc3J3FwM 9B7UgHOcnrS9ueoo7Z/OquRa4nGMDk56U7JBzjAPFN9Mjr6UuTnHPFF+obDsDPPerNrbPcZEQyV6 81VHUHofrWvojKJ3DMFJXgk9TUyvbQEldXOn8BaVLLrkETAAvIqjvxnk19QYCxqo7CvC/hhZNN4l gfjEYLk+oA4r3Vl561nFtu7IlGzdiJsHqOlRyMOF6+1SlQVqJ8COtVY5pXGNGCxJzzj8KrmUpO2R kKOPSrPIVicAAcY7VXZFlxlsg9R/WqRFrkIXarEYJY5JrhPFrm817TrAAjMgZgR+X6Cu5OUBCgHA wTnpXBxltR+Ie3GRApB9M03e1ilc9DIWPTQsrHbtA44rmJzFdB8gKqdSeprY1GWSNhGRwBgfWuR1 BpV8xASAeuD1qlorkpNszdQu4QzCHoDjPTNYc0rbs7iMjrmp7sNsJIIGeM1TUGRsnhcc5PpSsnsa JWQfbZ4pEZZnVl5BBII+lWI/FGsROdl9OAeuXPNULrGSRnAP5mq7Agg44xxQ4p9Cra3PMMjBwT+V LkYz3x3pmOT3BFHQZyDnsfWsjpTFU5HOQO9SZO0c9D1poJcA5yfTqK0rDSZbxgzny4x1Y8Z+gpSa S1CKbehR7EdT6mlyB0zg/pXTfYbQxhDFwoxnuarXOmWkVuZfMaMDoTyD7YrONaDdjeVCcVdmGMEA du1LweckDFNYjOFJIzwT3ppJBAA57mtrq5zjsgAAk9Kaz4IAzSHGTlSec4FITycj86NQW4pIByST TSckc5+tBGQCCcZ6UbTg5HGafUYudpyOfWjA6gmlIHTPQ0HAOOcfSlYS31E5ztPI9h1pOAeDx6U7 GSNp/OlY5GRgCmlYNBBjHPY8UEjPb0o5x2wPamkkYHXIxzQPQdkADHr6UoPBx1pAOenOOQKMYIA4 9KdtRX00F4I75pcnAxzz6UnbBOTindDk/hxQHQu6bcWlvP5lxEz4IwB2P9a6JNYsZefNKegYf4Vy GDjrxnpSHOOnH0rOdNT3NKdaVN+6drdaja2UQczpISMhEIOT71yV3dy3crSSMTzwM8CqwweD0FOz nt24op0Yw2CrXnU3DOFAwMGjGQPbHFIDk8n2+tLyBkHBrSxkkLjA4PueKCOM9u9NPJ4zx1HrT1PA wMZ9aYkSw28ly4SNCzE8AVqP4cnQf61GI6gGtXSIra2hVkmRrhwA2D09qvNE+Tn8s1y1K0ou0Udt DDxkryZycmjXqk/us+mCKji0q6kbbt2gcEntW7qWpxWcRSI5mIx7Cs/SbxpGaJySTkkk9a6cPebv LQ5sSo03aOpYtdNgg5YB3x1PQVPIgI4AH0qXjqPx4pu3JOenvXc4pLQ5E23qRIncgYHc0rY6dDSu +wHH61CXx0xn6URWopPUTPzHnjvin7ht7kgVDuBJA49c0u7jPTHp3reKM5PUmDcdz64NLvAORz68 1EzrGhZ2CqO5rJuNY5KWqlj3YinOpGGsgjGUtjZkmVRyQPXPSmFJ5LUy26FgeAR/MVn6do19qjCS ZykWeSf6Cu3srKGyt1hTLYHUnJrgq45vSJ30cE5Wcjjl0DWrk5aUqT23Hj8BV+HwHORumuVLEZOA etdnbxEkHbz9K1IISeSv0rz5Tk3dnpqhBKxxEXhS6sRut5Vz6hcH86l+zahE2biMTDuCOtd55QwB 0H05oNsGHzAEdORU3YvZrocWstqgxLYshIxlOorV0y9ssCMygZ4AcY/nWrPZRHOUUjp0rIuNOhJJ 2DOfSmpLqS4NPQxvE+gKpN9aqCpPzAc4z3pvhfWTAwsbhsoThCT0PpW1FujBi3bkPG08giuV13Sn 0+X7RDgRM2Rjqp9KqzaM9YvmPQJcdccexrIvoBIpx+NVPD2trf2ot5iRMgxknqPWtRxkkYJFRsdS amrmGjCA9OR09q0IJxLhWAORwTwKrXUYD5wB64FSW6KRuGAOCBVR1OSrFJmjGVRQGPyjuOalygYM cbSOCKonIBBH5U1ZXVShbK5446Votjne2hpkqJFYdOmRWJrkrvCygEKDitJHyo2sRWdqrhYnBbcD +hropbqxlPY5RlKEFcn1FKCCAMYPeiYsCcZHtUYYMeeCOte1FuyuedJakjKDk9PQ0mGA+Ug8dKTc VznOCeDUqkEdattC13GK7ZwQfx7U/wAw54OaTGW5xTdmM46+xoBD955HBHvQG5wBgfWm4wMGnYGA enFMTDfycHjvxShxjntTSMdM59KbgnjipuCSJd+SPagZOeaiGAeck5p6kkkEEUaD8xwBz7UvJPA4 +tAGPcUZGMZ/KgNWAJBxkfWgHJxnJ+tJgge2c4pARk9R7CgNhrMSwzzT8jy/b61G5yRjpzTsgRE+ nFZtFptiB8qAKVsFQQOnWogwC54yeKlBwAOueMVKbtqV5DMgggmmryDmkwA+MDjNHIw2KXTUSvck B+UCm52tzzzyKdwDgnI7Ypsm0Nx9aB3bLdteNbSB1JKnqAcZre2Q3cAc4KsMgYziuVBOQOmelaOm 3hiBic5Ungk9K4cZh+dc0dzswmI5Xyy2Hy6aIyXhYoQc4B61F9omRSHwRjv1rUlcbcjpjgnvVCZF 4OMnGSa8Zprc9TToZtxKrgjdyex7Vzt8hDhuTnqa2r5MMx4Hp2rGu2PlqCcnJzWkLp3MauqKuMdO RSYBAPFGCOeTS98jg119DjdxMgc9fal/H/61BHp1zRkdDQCZLBA08oiU8seM1M+mXKZULkg9Qadp IBvoyW24OfrW5KjFtwGQScEc1lUk47GlKCm9Wc81pOgyUbjqcVAQUYggjPqK6XDcjBA4zkdaztYA AjQYyBk8c4ohUcnaxVSmoq6dzL4xgUnQ0HpjNJy2cEH2rQx1uOwBnrz0owQOlHfrjFGc9vxpgA5P PfpS44Az70mfwAowTyDSYXsLnjrRnAB59KMHAJBPPpQTx9PUU7BcM5PUZpGHPfNKMn6jilOSOcij cYDr1OaUAkYJ5HemnOMml6gZOOKSC/Yd2xkZFHAPr6803IHY4707B5ODg/rRYGL3zj8KkjwWABPX NR5wQcYzU9uu+VQMkkgZoYntoe9fBe0+a4nOfkiC5Puc/wBK9alwoyT1rg/hNYtb6BLOwx5jgA+o A/8Ar13koJx7Hms47mUvhGKuVpjDJ+h/OnhjuxTWYr+Jq0YO1iKWT5MZx6iqxdQBtyWYZPsKsTfM p2/dPB+tVZldEDKCcjB+lWhdSKYGOJnBOMZxmuF8GyCfxRqd46FgWKjnpzXW6ncm20y4cnJRCQRx jiuW8BREWskzcPLISDjqM07XdmDdkdheASXALcqBk5/lWHHape6ksCkgGQAn1HetO8ZvMYB+QMEH 0ql4ZQy68Dn5UBIB7+/60VJcsSqcbyRt6h4M0u9iKqhhbsVOf0NcF4l8HXGiRfaY5BLb5wWAwR9R XsFZPiYxDw5fmYAoIW6+uOP1xXPFu51zirHz/dMdmFYgk859KiRyzAHJP0pZTg46Z6k859qfDGTK BzkkAfWuj1MVa2h5bkEjJwPagAEkgYpcZHAzntRgg8jA6GsjdpE9rLHDMHeISBRkAnArfTXbRwu+ N48DgAZFczjBI5x704ccnGew7VM4RloyoTlB3idNNrFokZdHMjY4GMYrBub+W6kLSsSo5Cg4AFQZ ycEZJppAwAOPrUwpxjsVOtOatJihsk9c+lA9SDjPOKTOODjP5UZOMDHNamY4MQvGR6Z70g65/rRn GemO1SwwieRULqgJxljgUNiS1sPtbeW7nEUS5OfwArUbw+6gnzkLDsAa1rS2htogLfawYDc6kcn6 1JscueCeOc/zrmqV5X91HXSw6avJnNtpF2pwED5HBU1ReIxOVcEMOoPrW9f6usaGKBstnDMO30rn yxcksc5OSTW1NyavIwqRipe6HccikOD93k5zS9Sc8gdKOuQCBx3rS+hlZ7hkg5z9aQYzk85p2OM5 wPUDrTcDGc4PrTGkxSecUoJJ5PT0FKkcrg7VLAdeM0hDDgggdOnFLQWyG7iCcjIpwJOCcgfypM4y euKM9uASKaQDgeSM96Qk59h0zSAdAetL7EZ96B2QmeSMnPoKUYwOR9KBHkkHj9aNmBxgimK1mGRt xjFLkDgZ696aOB2zS5JOMdvyoWwPcDkkAe9HO046DoDS55ORn2xSnjB5OegpJC9BoZhypII6c4qZ by5QkiaQHHPzGowTnp+lIQM5Jz6iiy6jWnURpGdixJyepJ60+C5+zzowJ98VHgZ45+tQuCuM9ad7 WB3e52EN2sqggggjsac0oINctbXrREKScexrQXUFcDBGffiuiNRPRmLg0aDygnr+NRFycgHp0qEM TkgjkZ4NKDyen1reLVjN7kqn5SSOc+tRz3aWsYZzzjgdzSgkA59etZc8Bn1BRM5CHv6ClUm4Rugh FSdmQS3M17Ll2IQnhRXRaJpAk/eSRBYx0z1NUbG0hbUfJhQkD+Ijmu3soBGgXGAAOK8ypN2u2ejh 6SbJ4IQFAVQqgYAAq/DAMgkZ96bCoIAHFX4YwB04rlvqemkkh6RYHBA47VdiUBQMnNQqABxx71Yi IIwSc00wsmPUEZ556inMMjrigHgDOTSkcZB6VVyWtdCrKMjPJx1qhIgye4rQlIHGe9VWjJJPWkxo otEDyBj8KpXUQlhaKUAoRjHpWxs559MVXngDDjp6UXdyXBNHnc8M+kX4kjJBU5Uj+Ieldvpl/FqV ikykZxhl7g1n6ppn2iAqRyDkHHQ1zel30mi6mUkDCNjtcD9DV7q5gm6crHZXsQKjAIOaZCFWNSVI IqQus6hgcq3INK0DpHlcMO4zTijOq7hv81QFIB6cmoGDoctjpyKrz3QiACoQc9T1zUH9pSuCjHJH IJq0zGza0L6TqisSQB059axr+7M52ZIAPQd6cbliQCMjP61QvBsuMjoea68K05pGWIi1C41uRk9c 9D1qB4weRgGpQQxxn6Uw8kjI4r2keY79CAllIB6U4EgEqc+xpxAIAI4I60woVPB+lS7huWElVj6H 0pzDgnkj1FVR8w54PqO9PWTB2seKd2PQlIHHPSlxgE9ePyoyCBjp2pSc5GQOKLis7jMjPt6U/AK5 zimMM9PwNALdPzo32C2op5IA5GM07GDn2pAcHGRjFLnrnt2ot3GhOAo5yQeaTPA7GjjBBB96Qc5P ND7iW47OR6mlAJbPGO+BUZ4/HuKXOF4OM0hpMewAAI7VDI2F56DsKezkADqSeDUBRmJyD+NRJ9Bx 3BSSOgx2FOLkEDnFIcrwMgd6YpIJycmp0KvdkzEAZxye+etMbnGDnNB5A9aZkkjnHbipbGk7E2fl wM5zTCc7RgEk4pVHUZzx+VIMAjJzim9g6jmBA7Z6HNN8zC4xk9sUkkgJAHIpuMYJ/KlfoLW5p2l4 0kRibJweMelSTyAgqRyf0rNRzG4YDHPPNSXNyAu4cEjr7V4+Mpck7rqerhavNCzKN9IQW5zj2xWL cENIAc8DNXrmXcSSeBz9ay2ctJn1rCnHXUqpLSwZwDgmjsPSjkjjpRXRoc4d8cc0pAxjnPel4OKT jn8qYIUZB7gjoc1Ik8yAFZXHOeCajzxR1BFJ6gi0uq3aMCZSwHQMcioZ7l7mUu5BJqPGMjtmgHP4 H0pKwXY0+/HNHUkelOyc+oz0o4wSOtMBvbGe9OzkjjijtkYoBB6546UaDsA57E4607BxgDJNHU8Y pM4Oecj9KBWOlW3jFlbhkGSuTkdahazhc5MQ/CqiazKFVXRXUDHTBqYaxbn70LKeOhzmuecJ3umd FOdNK0htzYQCFmQFWUZGCTk1kEHA71tXF/azWjKGYMegIrGbBPHHqa0he2plU5XL3RB36kUvXGM0 mDg5PFHT+laakPYOpxkg04A7gcn8elGB1PB+lLxkc/WgOgpPPPY8Cr2lIZb6MDsc49qpADHXnNbn hu387UkAXJJAH1JxUyehLZ9QeCYPs3hOxUJtLJuPuT3rcIYPuzxjpVbTYPs2l2sH9yJQR+FSTSY+ UNg+1SkZN2VmSAAnkDI5qCSQZI5JB6YpVYq+N3UZ6dBTWdcbkILZ6mrS1Mm7oiLEDB6Z4GOlQGd5 JCpzjPAxxUhnUyFQQccnA71G8gEhJXJI5x/Or6ktNnO+OJWs/DszAqPPGM5qPwjEIdJtV24IQEnH c1n/ABGuSbSzsRjEkmQTyTW3pZWGxUKMBVAHPXinDWWpUl7oag5eeRFU5PQAcmqWi3403WFNwpRG ypJ7Z71saLdRHUZDMyhiuFLHoa1b7Q7DVkLyAeYRjzEP+c1FRp+60XTi/iTL8N/aXG7ybiJ9v3sM Diud8f3iReE5gsgHmsqjHcZz/Sqtz4C/59b5kJXByOp/DtUV58O1u7eKP+0JAVGWDZIz6gZ4rJJJ mzlNqzR4/JiRwQQCDmtDR4DdapawDJMkqg8epGam8R6HJ4e1L7I7KzFQwZe4JrT8AWv2jxVa5HEe ZCfoP8cVpKXu3Ij2PC+p4AwOlAGWB/OlJ44GOeMUnQgZHPvU9DbXoB+72xnqKTJOR6DmlPfnrwDT TkDOeCaB31AHJGCM/wBKM8kEgHPekC46EE4pQN5wDkn+dCv1BiAjqeMHuKf1APfvzxTeoxjn1pwx x+tNWENyMkYBOc80oyR0H9afkA8ADjtTcjIFOwJaj45pIslHZT0wCRU39pXhQo1xIV6YJNQcEDGM d+etMI9CaVk9bDV11FJ5zk49fejoDxjPc0AjHByaPw49aeghwJOPTpxRjZke1NycYAwO4p2QDyfw zQgDnAxnpzVqwsnvZto+6PvMR0FVN3PH5VftNYmtF8pVjZOMjHJ/GlK/QaVnqdHbxQ20QSEAY6nH J+tNkgSfI8tSfpWYmvQkDfAUyeSpzUd/rQdRFaBlUjljwTXJ7Ko5as7fa0lG1iHUxawkwwopcYJd ScfSs0DBzwfagnIyefrQD68D0FdkVZWOJ6tsdxkA/U0/AxlSMZ59RTO4JxilyADjj3p6EdRM4B5O R3puSRjPFOGCDkirNraPeSiKJck9zwAKei3GvIqnGfQ0cZBzzXTHQ7RVVCWL8ZIP6Cq0mgISxSYj HQEZrL20Lm3sJ2uYOecHPJ9adgAe9WLuyazYBmVsngA8j61WJwDxnNa3utDJ6Ow7ORnOABgfWmg4 wevqTRwRgkD+tLjAxjOOtHQkTnOffFRSdTU2RgHpnoBUeQck8/WpexRDgcnjrRnkAHJzxS8Akn8q OhB4poTNeAEAYPYde1WO349ahtjuiHfIBqXeORyCO9d8NUjmle44/Wql+uAHXqCKs59/amsnmjZj Oaqa5otCg7SRoeH4ixM7DJPAPt6V18A+UHgHHNYGlQCGBV44H51v2/3Rk8+leHLex71CNoovJwQe o9qvxElfT0zVWBRtB4q0EHG04+tTY2JlJxj3qVZNvBBqMADOTz/WjkjnHHShIaepaVwRnFBkCkjq ahUhh1xTuCep6daZOlwYbjwPzpoTqaftOeTSjpgYwaL6jsQFB1HXNV2B3Y6nNWmwD7dqgfG8459a EtBW1K8kSkZ6HFct4g0Tz4zPCMyL19xXWyDjIIPNVpRxg96pLsZTSkrM5Tw9qB2myuM71GUOeCPS tmWUjADlRj16Vj6vpz2VwL2DgA5JHY/4Vahf7TEtwpDBhkjPI9apXRzcutmOWM3EoHBwexq1Jp0T x5Aw2Oo4ptkqxXW4kCNxwfersz8sq8cdaV2dNOmranLygxyMjZypxmo75A8KOD04qa8ybtgSOvWi ZC1owAHHNdFGXLNM5q8E4NGeG4HQc0rjnIOfWox0/wDrU/cCvIr307o8N7jTgkjgY6e9NBxkdccY p7DI4wDiozyAckEUJ9w2Fx2A5pMHOCBkUivg8kA084J5xz3FNNCsxFJQ5zkDtmpQVYcHBxUfGcDH 9KQBh8y8+oHek9Nhq5KB2Jz6UjHGMDjvQrBzgHkdaUg8ZFNS0E0GcAdxSZHQ+vUU0kgfWm8AEflR cPIdkZP6Uv40zILYzg+lOwccikwVxeMZowOOfwpBkMAcClHLA8ZzS6jGSEjBzxTN3AxmnzjLDsCM ioc8gcj61DavZlpOw8k4PPOaYSe+T70j5PAOPamZOMAj2qXoC3JCQEz3z0oBAHJGfemFsL1yfao8 luuMUropFjfnkH3qMP8AOTnj6U0uAvXH0qMOM5Hr1pNgkT7gDk/jQXyRzgevpUBck4FJyz4JJHbB qeZBZEzSjPHPaq88x2gE8jrSO6oCeRk4x6VnTTkk4JJzya8/FycmonZh1yq424m3EqDUKnHp0pMZ zTsDHH6VhFWRcpNi5OMds0vb0NNxgeo9afxjP51ehKuN46ClycnnIpRyDz+FOjQuwXOMnGad9QQ3 +EZoyACSea0JNImjX5XVj6DrUP2C4BA2Ek1PNHuNRlvYq9cdKT8OfrUskMsZwykH6U0Dg5xmmmns Ib36jHrQcY460dAfX0o5ycUdQDgkE/lSjHfqaMZI5HuKMZHUYHBoATnpxTiMDrk0HB6HpRxkn0FD AMkDtg9Kb6nqacOx4OOx70uB2x7UkAgOTyMCjn1GPYdaOfYkdaF9hknpT0BXFyMc8elLwAOOvpRw CAcUY5JyfwoDVMTGfQ+nPSnDgD09aB0OScduKfwSBRYLjR1GO9d98M7D7Z4itASBmUZ4zkDmuDAy wwB/9evXfg3ZGTXI5cAiNWYnHTtUyIk9LHvh447YqLapbdgE9jTmJPsfWoySVIBOT3oSMJyVxroA dwPJ/Wq5QSQldp6k9eakuNxiAUjI6881S+0ENlCQfQmrjczlrsPjiVGJK5YH17UjOAAzFB6+pFK7 ERFwDnOGIOOfSqpAy8hwdoyAfaqSGr7HDeJWN/4vsbULgRjOCffOa6RybaxUYwxODxXIRXv2nx5N c4LrHkDPat7Vb13lU5IXk8dqcLbjlfYzr+5CYO4jv15qjc65f/Zkto7p1iQkqFJHP9anKfaZ/LyC T6noayryCa1Y5TP06YoavqVHYtxeNNbSTJvnIU8BjkVtW3xPvYgftFtHKAABjg59a4RiC38xUTOC CqgjHGRU8kSk5HQ+M/ENpr88FxBbPFMq4diwII7ACtv4VW5l1S5uSB+7hAB9yf8A61efFArgZz6m vX/hfZ+Ro9xcEAGWQAH2A/8Ar1lU0jZFwTcrnyrgjJ4Pp7UHJXkDgdfSgkkjHP8AKmEnkZ59KPM1 QvIx05HHFHIUA9aQZPck+hOKQg5xnkc00F+g4d8cZ9KPuDg5J/SrFrZTXbhUU4A+ZiDgCr0mjkDC TKwHqMVDnFaMqMZPYy+cAkgcUmSME9M1oHSLkH5QrcDgEVQkRkYowwwPT0qk09hOLW43qeOB2opA M46g/Wlz78561WlhLQdkAdhjoKbkc+vakySTjnnvSnAOSM+wpDuOxkZHU9sUDljzzik5wMcUmDg8 /lTVthNh65IIFLnpxn3puOc8HNLtIHHShWC7DuM0ZHUH9KdjBz2xTck9OPU0gYHOBggg9RSjg8jA 96XAxkk8+1BJ2jnPpVKwDsqAeQT2pAQQQeo9qUbQBn86bjg85PsaLah0FDgkZIxTgVB9/wCVM43Y wRS8kHjmizESxYLBWIVSeTjpXUWLWEFuI7adSxHzFuCfauU4C8nn0pMsfYDnipnHmVmVCTjK526q M7kYOe+Oap397HZKQT+8YfKB1HvXLpczxDKSsp9mNJJK8zBpWZmPcntWMcOlK5vPFSlGw+WVpZC7 ksT1yaiJAJI4ppPGBx+NHI710LQ5ne+o4HgkgfjRnJOPSm7sHoMZpdwBznGelPQa0FIGMZ5Pamk9 geB0p2ct0yKs2Nk15MQciMclgOntSukrsVm2U/IkK7gpI9QOKZsbowx+FdRdBfLVYgFReAKokBiQ VBz0zWKqq5u6MralGwn2yCNiQD6jpWn5YPIPBqhI8aSqoVd2eSO1WhJheo+lehh53VmcNWNmKUKH I59fepYPnlUevSojLkep+lT2xXzQePwrabtF2FTTclc6O0QBQTitWDDY9qyrZsKO49K1ID8oOcHv XiPe57sXoaUThQB+FXMgAEY/GsyI4bJOePWriuOCc0aXNEy0M9SOPX1qVcEZBxj1qJHGBnpipMjH HNO3UdyePYoJIFKSCSFAqNAXGAD9acY3z/Sk0+hGw07s9ec05cgEcdc005POOnUUwuQM85pDvcRz z1ziq7Pz1wambI5yCc1Vl5+nrTKuKZMHgDNQv85OfXvS5BXg/j61C24HJFUZTsJMiyIUZQykdO1c yyPo2oA5JtZWwO+0ntXTq4xk8+oqnqFrHe2skTADI4I6g+tPcye9xhi3xFoiNh5K+h9qEfBjVjkj jmuc0vWZrS6exnyWjJHPcDvWw91G+JVIwOcA1NmdEJReqKGortv2AxyM1JAdylSeCKq3VwLi6L54 xjJqazOWz25xWidtTCdm2Zki4ZgRgg4/WgDIxnv1qW7BFw/BAJyKrbgDnPFe/SleKZ4FVcs2hQSG wcdeKeRzkYHqM1ECCSc8GplHGM5HrWiIdiFxyCvahWz69etS7RxnAz1prIM46elVZ2FewgJ3DOMU pyAOgBHFM5zyOBwDmn/MUOTkD1pIelyIkxtuBOO9WVkEijBFVs5OByfSnKdvzA4BPIqW9RpdyxjJ 6/WoiCDwRjPFTIQwznJpSowTnIq07kvcr4I5xk0qsehyD/OpNwzgkUuUUBiRn3pOwJu4zBLZ7U7B yOgpjzKDwR9OlM88NjGPpUNoqzsOcgnkg4quwJOeg6nNTYAGTzxTM7uOAKmVnqUrrQj34yCATTCM njoOaVh8xpMHBOT9M1nfoyrdUMYk9MCky2MEgnpxSkYOecUnAIyTz6Gk2MOSwHFISACoPJo6cUmM c5zUu9gVwycDFMLbQWLAD1p7HYu4nA7k9qyZ5jK5AJ2jgCsak+VeZpCPMwnuDI+FJ2iohnknpRjP /wBalGOBkHmuNu7uzpWisIB09KdkcYFNxkkY/Klwc8/hSVhegoHBOTil6DPB9qQcAg5JpeuAARTA B0zxV7T0L3sYGCM8g9KogjaPenKSpBViCOeDzTaEda6tvJKkD2phx1IwD61zyahdqpHnseg5OasR 6zcgneQ4IxgjpXPKi73R1RxFlZov6jhdPc4wcgA+1c9nAB71pXmqNdxCIRhccnB61QyMY/KtYRsr MwnLmldDc9/5UuO+RmkxkADijkA+tUTfUPX69qDx059aOvIOe9GWJyQKLBcCeM9hTgBk+nfmkxwe /tU9ogkuo1ZcgkZGKAWxBjkgDGKXoOtdDcWVv5pGwDHXHBqq2nQs2FJX3rP2sb2NVRna6MgOTwv4 ijPzD9cVfudOMEZdXBGQACKpcA8j6VaaaujNpxdmJnIGOvrTs5AweaQcHj8KMn0p6Cd9xeCCTkGj 3z6Uh5GB17e9P54AB6U09LivYeiksMcn3r3/AODVr5Vtc3BAxsCg46dzXgtqhlnVNvUjFfTnwzsD Z+GFlK4MzZH0HFRK1zOcrnYsdo3dz61W3sZcbgTngVPIT3HA5JqvJ82GVflB5Pc1SOeWo4kiTBXP qewqB1ieQnbwBxjuafLuAQhyOeR7VXLkTEHO3OAaaJXmQN5hl25/dseg9aZPIsSSEsq7FJOeccVa ZQcKGAPJBHXPrWD4hcWeg3ExJ8woQSR1JqtOo0nc4rw1mfUb27wCDIeSe2f/AK9at9OHkIHIBIrM 8NHZpe7IG5iTzyasXUoGeOT096cF7po1d3IlO6VQnUnHqTmp73T9RijPnW8qgnglTyKu+D7YXWvQ bwGVSWIPsMj9a9YKqRggEfSs5VHF2LhT5tT54ng2scqFPPFUthjmHBJJ6dRXsXjrw7a3WizX0MaR XFuC+5RjcB1BxXjySkE7jkjmnGSkEk4uxHlXlJ4HPSvd/BNsLbwnZLjl13n8T/hivC4kEs6qoAyc YA6kmvoKErpXhxCxwtvbAk/Rc1lVd3ZGlPq2fFWcE85FJnGCOSe1HAAGMnPFJwADjGaq+hpawvOB nAGep7Vo6dp6XTZklAUdQDyazsAgg4IPSn5KHhjj2OKTWlkCte7OrjjEcYSNdqAcAdD71Hu2qScB R1z0Fc/DfzwECN2GDyCc0641C4uV2uwCg5IAxmud0G3ds6I4hRVki3faohDRwFhkYLHisnk8kkk9 yaQlcDjt3oXHPPNbwioqxhKTk7scM9BxSZwACcnPSlyQMY47n1owOo6VfQm4gOAKNzcgAE0ucjoK dFE0soRASxPQUg3YZOMHNH4Zx1roLSwjt4tsqh5D949ce1TG0tZsBoRkdhwT+VZOtFOxtGjOSujm DjPpScEcZ962b6wt7aIsZCGY8JjOB2rHb5R/KtYtSV0Yyi07MQ8k5/8A1U4juAMd6buOeeaXI5IB FMFfYTOT6U7nb6+9MB5yehHpTt2R7dhTBig44PpxQAMZBx6U3JJ5Bx2pACPx9aNQ2Q/PFKp6dgBS bTxil5wDwB70xACCT39DS4Gcgcd6Q8egoHXkZz+VK4BwOT1zSE5GRn6U5sZxgD2pMggDGPSnbuCu M5J6fhTjnn9cU7qDgd6aeeOgoQO43g4HQd6djYMdfSgkDgj/AOvSZw3AosFxcAcnqa07PV/s0Yi8 lSmO3B+tZmM49BRgAZz160nFPcabWqNx9TspUbIdCBkjGRmqNzewrH+5bcTwcjpVA+2KjwOcYrNU 4p3Rbqya1Yb/AN4GJPXJrTDq6jbzisrHHXn2FSJIYzlTXRCfKzGUbmouAM9x196s2z5lABFZsd0j 8FgD2FXrYjzcgjI9K2lLmg2iYJxmrnSWzgYz0rWgfI5BxWJC3yAgjHetS3YFQSSc9MV5m566ZqIe RjGferSfMB1yKzo5MEHBNXI5c4x1xRZFovoSAO/HQ1agBcnAz7GqCP3J69Kv2kuxhyCDTsmEm7F6 GIu2DgYqzcWUqKGHTHTHUV1fhZrGe0MbxRmcEk5AJIqTW9LUxebDgBT9wDgCqST0RzOq1Kx57JwO 4OeaYAOMmtC7iCFhtHJ5BFUdpAwSAB0qJKzOiMrpMjYgrjrVKXG7A49BVuTjIGM1nSZJOTj6Ukim xu09c49RSO+B680dV5HPrUbAcgnj0pkvVACNpzweozURPGRyKRiM8Hjpioi5AwDnPU09DJuxyXii 3MVxHfw5BBwxFSWd4l3aCRcBsYYDsa1dStxdWskRAJIJrl9KiltJ7iJ1IGMj3OapLQybaloaORnI 6g5q7aMcbs4FZTy4lIz9avwEqmecY5pSKTGXuTKW6cetUgQc5xzVi8kBAYnGapb8If0xXsYWX7tX PJxC/eMkDqH4IA6c1MJlAwWXFUWOEAzyT+VQS3KxfK3JA4A61tKryaszUHLY192SSGGKaSRknkVh JqbrJwpx0PNasF3HOAAQCBkjNOniITdrilScUTb1JA5Bz0FKSMEAc+pproB8wIqrIzlsqeOgq3Jk JJk7cHOcnvSoS64xkD1qEBgoJ5NPMixgjofWpcikuhYVypwAM470EsRjOD7c1SZyQSCaRZiOrGl7 RbByMsyMwbvTCzE4IwPSkWQHkkn1o385PSm3fYdrDSpY5yaUAjOOcj0p24AHJHrxTTIuPrS0SGr7 BljyWxjjFB7EHBFQvMAwUELnoDRgg5LE9qjmWyHZ9SQuO/XNNL5J6Y6UwgEZJPX86YD155J6VHMx 7ImJG0AkYNM4zjHHrUZcnjr7Cl5BHHBpNjJNowaaXABwR703Jx3x0xUUsTupCsASec1lOpyq7LUW 3oVrq53rsXp3PrVTnirLWcowAoI7YNQtG8ZG5SD2yK5HLmdzoUeVDcAg9qTkAYxS5zkdzS4wKQXD pkjrS4GcHqaAMjqRmk7g5z70BoHPAB+op3bApMZ70uOmDihoGwxgc4ozkjuaXB5OPrSAe3T0poPQ Oc9Ppml5PTpR2zxQeMc4oSuxaAODjHOaM8gY/Ck6nHSk5HPfNA9B2OeM/lRnrnjNJznsaXHGc9KQ OwvQcjFISDxjmj2ByKOCenSgExeg6c/WrNjOILuOUgAA856VVzgZ5+lLwc8duaOgJnUefbTtvWdO TyDwaf5OcEEEZ7GuUDjOAMAVIJXBGGYc9j0rJ0VfQ2jiJJWN/UUKae24chhjNc6SCcYyPrUr3Msk e1nYrnoTmoep64/CqjHlRnOXM7jsYIGSB2xS89M/SjqcmjPHb2q0SLhgB7UvQkn0oB4HX396B154 9DQLTc09GQvfR4AIBzzX1p4biEHhuwjAAxCCQO2ea+XfB1sLnWIkI4LAYx2zX1dFtit44kXCqoAx wOlQ9zKcknqOJ+YknqOBVdThirEjBGfcVIeCGYAknjHaqs4+csc4PerSRzuV2PlZZYmI7HA7ZNQP EBEucgk5FSMp8oEBtpIzkVVnDjkEleMEnPFUn2DWwh2K+VJIHUmuQ8f3jpovl7tpkcAc9q6wvvjK qOSepHX6V5548uDNdWdrkYzkjuKcrcpUL3IdKjEFlC3J+XkCkvHJPBJAOAcV0nhLSINRmeKViYo0 BI6EnNbOr+B1uZDJZSLHkj92RwPXmlzpaFKDepmfD2Pfqcrt1SI/qRXpNcPpvhHUdMWWaC+EdxyF AGQw64NUm8U+JdLlEd7YiUHJX5CCQOvIrGWrujaM+RWaOh8c3X2XwlekdZFEY9ySB/KvCGB3EDAF ei+Mta1LWdAg/wCJbLBbFw7SZJBIBAHTpk1508UqNiRGUnuRjNaU1ZakSkpSuaXhm2N74gs7fBO6 Vc8dgcmvY/Hl59h8F6g6nazR+Wv1YgfyNeb/AA0tTP4qjYjIhjZicd8YH86674s3XleG7e36+dcD I9QAT/MioavULelNs+VOc9AD09qMccn8KcQM5/Q03JIz2FNGm4cgcZA9aDnAI6Y5pOcHJ57UuQFA 5yO/akwSG85Oad8xNGBk9aOcDnvRohsDySfWjnI7fSjB57ijHPt7UW1uCFGSAMYHrTj7Z49aaMkA c59TRnkYz6fWquJDgQcA8YPat2wksYoMrKFlxyzjH5VhZJHQDmmjggj8qUlzKw1dO6OwQLJgh1cY 6g9ahubtLEEsAZB0WuZEjjG1mH0OKHkaUhpWLHpkntWKw6vdm31iVrbElzcyXMpdiSSeAe1QkZ5N IAevJH1pcHOc/h2rdGDTeoY478+tHGMc8elLyMknntSAHGc4p3Qahg5GeO9HQE4zRz0HOalt4Hnn VIlLMew6Yodtw1Ftbaa5YiNCx68dhStaXEbEPCwI9q6W3t0s4gkfDHG4+p9M1KS23GMjOTiud10n obrDtq7OROVJBBBz3pepAxx2rpL57aODM0Skn7owM1zMkm5ywXaM8AVtCfMrmUocrsNPGcg470/P 4D61EMg8kkGncA5PNWTZh8pFGcr7ZxSZBJGM46YpQQQB0JovcWwcg9CR9adngjp7+lHCjqcUdieo NKwCdTjnHbigcE96AfalGMev9KabBaaBk7vQUmQRjGKXJ6YyBTSTgjgcUg6BngAA574phA9cU7nB HQ4pMZx1o0GkM5pGPGB371INoYAggHrjrULBQxAyAD361En0KUW9RuO/vVi0neOdfmOCehNQdc4O PakBO4HHQ1N2thpa6ndWrgxLyCK2LZxgdvrXO6fIGiXrnA5raiYZA744Oaz8zsi9DVRwSMHpVmMj PH61QjOCAM/WrMZbOCetPQ0i2XkJPJ/KponKMMk4qvGcE/yqUZJyeMULQb2NuyvDHKCJWX1wcV2F pfzW0e5/njdcZJzkGvOo32sMc1uabq0tm4yN0f8AdPI/KrjJGM4NrQ6Sewhv4GeNgjAZ5HB/wrl7 qIRYGQTnBGa62HWbe4DMNo3KBsAxtPrWBqyI8u9EIbPQd6qUU1dEU207MxJkKHLcDFUGTJLLgmte 4QmEAkfSskghj2NYtWOm90V94JIwcg9KaRxnkGpJOHzjBPWopCcZxgDqaBNaFWTIYccdqhYEAcgc 1PMwI44NVAQ7EEkEGqSuZO5BO+GIU8VmXIAkGMAkZJxV+YfMx6jNZ1+VAUjg01oZszCwa4YH+HGe 1W/PG3bnA9awWuCJ5SMnJwPoKjNzLxhiBjgCna7uZKZsXlwAQGOBjk5qg+oKGBVSQPfGapu8jnLs T+NNwOuM57V0/WHFJROd01KV2TS3kshBBCj0HaocFznv3JpDnnikwVAxnJHNZSnKb1LUVFWQYxkb qTJRgVJB9c0qpyD1Pp61v6T4ae7ZZrkFISMhc4JH9KSdhtaFS01DdhJATjjI5q0SrsNtdXFpttBE EjhRFA9OT71Um02FwWVDnnlRXTTxckrSMJUU3dHONJsUk/hVZ5DJkDgjtWpNpZlkVIfMZieECkk/ lzVS7s5rB9s1uwkH8BGM/XNazxCauSqTKgdkUseFHc9Ki+3Qk5JJ98UnlX1zICybY1OcEYWqlzA1 vKUJDkjPA6VzPEST0NVSRorcJuG1gc9OakWfB5yQay7SF/ORyh2hhkkcH2rUXTpZ5C8XWM52ZJLA ntVwxTvZBLDNR5mtCQSh+M960dO0a71GVFtrZnJPBPA/Or+gtbpcA3Okh+QN5xwfoa7N/EthYQMt oUWcDDFgAIx7eprGtjqidoRIjQ05nsc6Phs8Z8/VtRhgB5WOPlvpk0290PRLGLLXTBQPvyNyfwFY WveLDcS/uXkmmDZMhJwPYetcrdX1xdyF7iRnOehPA+grmhzu8pS1Z0U5RX2Tev7/AEeI7bMTTMOC Twv+NVYLy0lwJUaM56g5FYqDvg5NTY+UDkHvW0JSj1uXUkpfZNq5+yRRmSGYtg42nGT7giqyTxyH IPOOQazsHAGeKON3FbRxDW5g6aexqoN+Qo4HJxUnlEcEcE1iJPNAxKueetW49VnXkkMMdxWdVuoa Umobmht2twT1qpqjDEagDIGSQeaItUUn97CD6EHmqdxOZ5y5BAPQe1Z04OL1NKlRSWhBz1Ap3J6D B9aTpSg5J61qjEXHHvRg59fSjtk0dxyQcUeoebAZAOefTtSjIAyOKTt1/GnZJAz0prcOomCTT+i4 x360+2jMlxGhxgkDFbUumWySldrBR15qJSUVdlQhKbsjAHOcg0EcEAfia2G0qI8hyOeB7VWl0ySK J5AwKg5x3xRGcW9GEqco7mfk8AcGl7DNHI/GkwTk8c9Kq2pCTQdwDxS8E4FGDkZzjFHTp0FGg9bW Dov+NAznPFHGBn8aBgAgetCSFrbQOSScZHanZIHSm5yepo7DryaA1FH0oyAc5xijOPcUmSOMfShD sOXpyOnSjg9RyKQdT70vcY6ChdgDtgggmndQM5z0o4wAQfrRkY5z7UMQuRnA69xTlA5IB6d6b1HH 4mnL97kcUaCu7HonwusBd+IrZSP4txJ9BzX0Y7YOAAMdyK8U+DlkH1EzN0jiJz9TXtUu44C7SCeK mK1Oap8RGZSCyjkeuKYzgId7YUDj2oJMaEoB15z3qozmcMrLjJySa0SJLK3LNwjZ2g5BHBqq0xCt jhcZAPfNTGBhCDkDPXHpVLy2eUg5IHQe1CsCV3ZDt4UbmXBPIx6V5l4huftHi8LtGIASfc16VIyg kEEgDNeQSTNc+JLuUEnDEZz2zx/Kh2Lgjchv5rbc0LsjdipIOKmXxZq9rtKXjkIchWOR+PrWS0hz gkgHjiq7HOckk9vTFVZMNmdcnxM1GKILJBDI5PDkYwPpW5b/ABM0uSQLdW0kQ2jDcNknrj2rymfJ Cg4yDgY9KqS7hJyfoM1LpxLTke6r4w8OXMcMJuYyspCiJl+6ffsKyvGWjJr2nxJpwtZL2N92I2AP lnOOn4V43lhuBbaQMgA96kt7+5ik3JO6NjkhyDU+zsDbaPVvhtolxpupagbpCkiIqYPbPP8AStjx loVvr0ttFczNGkQJXaO5wP6Ck+HCzN4da7uHd5Z5CSzkkkDgda57xJ8QP7M8QXtn9lEohO1G3Ywc DOfUZqaWs7meJ51RtHdnzSSM85PTvSZJYgdM8Z7U+VI0lKodyg8N61DnnJ4+lC0OxbD8jJHejkDG cAHj3pmSCDRnBwcg54psVh+cD8KQ9Rg8Z/Gk78HANKAAOc9evep6juPyTwB+dJ2/rRkk9cCjaMjt g9/SqQuoHgdCMdKTkdOD707ABxxim9zk/kKGAvfg8e9JnAPPU03ocg/Wlz+OKB6WHg4Bx0pMEk80 gOR1yD+lGSD9KYh3UDnHpRnAB9KTJz7YpcHbn9aQai/5FNPXB6D3o7Dv707gqDwOeaYX1ED8YGBW pY6pFbDa0ABIwXA5rLJAIAxgUpbJxgcUNJqzBN7nUQajp82dzsnru71NNf21vCZVdXByFAOcmuP3 cEUZJ55/OsfYxvc19tO1ixdXcl3MXdu/AHQVBkdifp7UmQTweaOg962W1kZC/TIz60maUHkDH0pM 5Bz19KAvoKBz7HrS/QcUgPJB60ZGMAE5ouK9hR1wTzWgmjzvCsgKjcMgE4NWtLsDGftMyZGMIpH6 1oyPlsnOT27AVhUq8rsjelRc9Wc/Jp1zGDlCeOxzVYq6gkqQPpXUqCe31yKx9UvVY+RGFZQeTjvT p1XPoFWkoLczD25Iphzj3pxOTxk+uaADu4PtW2pgmxOccj60oxu5OB3pRnkZyc/hUuAVDFQAOAO5 NKTSWg0rkcsgOMADAwOP1qu65Jxj3zVpoGERkc4zyD61WbhMt1PQVkWmiJvQZz0rY8N6daajqiRX 0/k24BZjnBOOwNYqg5JJzUqHHNTOLcbIpNJ3O2vP7Oi1NotMYtbKAAc557896tQyYIz+dcrpkvJU 5GDkV0MDZAyRSjHlVnqbwkbUUoz71bjODnqMdKzIHA78Vdiccc/pTNUzQVsY7Y9TU4bK5yPrVUbQ AfX2qVMYJB/Cgu5ZB6EEcelWYpW+7kc9KpKxxwacj/MORnqKA0aNS2lKTAFiM989avm4klbAOdow DmsRZAepB9KmW8aIFVxg8HPNNPQlx7GhIp8vDnBJ71lyLgnJAwac92Xb5jxjgVXkkDZ5zzSZUU+o xvvc4PvVaU8EAgAVIzEH1qrKeCcfWkVIryvk47VXIy2c4/wqRzg84PpULOAS2enGMU1uYzWlyK5O FJUg461jakXdY0QbnbhQO5rTnYk5yME9KrWqmXUN/AWJeCR0Jq4q7OSpJJHP/wBhX4UkwgZPJJAq SLQLt8EhF9STXZ4Z1JJBPOB1qGSB0gMUOWmbqRwB+NbuEUrnKpyb0OdtfDD3JKrcoWB5wCQKuR+D laQpJcsCDjgYre0rS5rYBjISxPIA6VrfZGckkEsT1qOaKRTUtzln8F20S/NctnHQEVW/4Ri2DcyO wHQZx/Su0fSpcAlCRjgkVUkjSI7SMsOwFLn7ILWV2zHtNGs7dgywqWHQkZIq5LcxW6gEgtjhR1q/ a6BreuTiHT7V1Q9ZCMAD3J4Fd3oXwitLX9/rF008h5KRnaoPuep/Sk1rdhzfynmiuzxmWQlUB4Xu a0vD/hrV/E02+GL7Lp4OGmkBGfUKO5r0+98P+DrbbD9njaSP5giuSSAe4zyKi8671Ui1sYjBZLwA FIBA7HH8hW0UraEtNvUfbeFrDRLL/QrdHn2/6x+WY47nsK871zS7zU4ZLnW2trGBWIQOBnI9O5rt fGviW58PwQ2NjDG148YIMjYWNegJA6n2ryy8vWuZTNc3LXt4erOcrH9B0Fc1Sso3tqdNOHO1FGFf 6aIZwY7qaSAn5VRdpP5/zqiLGeWTbHabMnGSMk/Umtu6lgiVWmlBYDJxyaz/AO3Iy2yFXUggh845 HTis6TdRNtWZ11ksO48tmblnplrDpMyPEjTxgyAsMjIHT0/OsxdTWDV1aHyysYIG0DGCORnvg0t1 rc12ArKoJ4JUYzVUWUUsQdWA9wOhq6VKa1kxV8dCStFF/W9WsXsMpbObr+J87Rn3HeuNlmlmBLsc E5Az2rb1KLZpykkFsgZ7Eg1z7HA6nGMCq5EmcvtZzST2IuuSfXijy8jOaEwT37ilHysaSFoOAKjJ NJnJGD+dPyDgH0p2ODgZNMQmDjjGM96aQB25zS7uSMdKCcLk80dQuRMeoGDnpTF4kwc9Oad1J7el OKB1yPvD16U1uAmARkHBpO3pSg5HQcdaXAzycDFaJk3Yh6gmlwOpFBPHTj1pc5XtxTe4X0DjHFBx nGOKTjA9aTnOCaQBkZwentT+2O1Nx04wOlGcUwLulhPtsZc7QDnnpntXQzIXYsDkZ9c1yfcZOPSp EuJkOFdhnrg1nOCmrMqnUcHdHREEckEEHrVe/cpaMSCQSBxWemr3KEAsHA7MM0tzqstzF5TIqqew FZwpNSuazr88bGeeTyc8Uoxg88+nrSd8UdO/HtW5hYUnNHbkcUmOnPFLjGOtFkAZBHfr1pO/vS45 5HFJg/WgLDsDOBwO4pcEHJz1pvfBOa2NMt0kt5GdAcDgkZOaTdlccdXYyeD6D60c49QfStw2FucE oAahOmRknaxAH8qzVWLZo6MzJ/r+lHOT6D1q3dWYtgGDEg8DiqncHjnsK1TurmTTT1F9Tk/hQCMf 1pOvPSnAcgcEUPYPUF5HWpo+WAOOvJJqHAz1I5q3Yp5t1GpA68570hPbQ9++EluINKuZtowQATjk 47CvQnlYhfLXByOvauU8AWqW3hqAMMNJk5rrHIQAqu5sAU0rHFOWo3LfMW5GDxjp61TyTJuPT1FW pZd8m1sBcc49apzPGXITJIOB6VaYaD8yAhcnHXJNQ5ZZHYMSe2PSl5ZC75AAx+NVXlKj5ASuetGg 00kV9Wu1gsLmZgQwQ4I6CvJtPOWmn5yzHOe/Neh+MJ/J8OzEHG4YP49a88s322SKAMDkZHJoe5cG +UuyPkBcYI647U3DFSeTxwajMoIHr357V1Hg7SYdX1dI5xuhRSzD1A6D9abaSuykruyORlRicAcj FVjneAw5GQM17rc+BNFmO6OFoW9UPH5V5x418JS6FMtyjCS2kbCtjkHHcVMaiehTjJbnDy8sScgn pzUSgmQdfqalZQSTkkg+nQ1asYDPeQxKMl3A6dycVUtFcVr7H0B4SgFp4T09Oh8kMfqef618+a7e fbdd1C5DEiSd2B74ycV9D6tMuj+FLqX7ot7UgY9QuB+tfMsjtnJx3OQO/esaK6lVHql2OHGR703q RkcHpmnEnpgcd6TlgTjjtxRc2Wmg3HP070vUgk596dzjpRjkdOn50CE5IyfXilxxkdfelyCen4Vr 2GnABZp8DPKp/jUykoq7KUXLYyu2SCPT3pCCSByMdOeK6dooiNzRowIxjFRf2dbSlsRbe5IOMCs4 1ot2NJUJJXOcBJB7Y/Wk6k88dvarF3EkUxWJ9yg8EdKg6jpit1doxEOCOD+dKOOmRkUKOce/elOd 2ce1G6FqITnnn/GgEAgdOKCD0Gee3pSgHaOMn3oQ7CbgOCaNxxwTg9qMDPT60nOe9NAKDwMdvWlz ngY6daQEHPGKTkUB6hwRgg/hS8Z4FBIIHTrRkEilpa4LYOATg0ZOBxx3oI464+lGeM8elNsPIOvG PfNGeDj9aQZz7UucdBkYoCwZOME89qUkY6c9KQct2980HkEAd+1CFrcd1oD7WB9DSdMDn60n1HFC 1G0bUWvsABLErKBgYOMGrSavaSE7g6HjqMiub7nGPwp2QRjnIqHCLdyo1Jx0Rt3+pxiLZbuWLclx xisTO5s+vek5Geo9aUA44A59aqMUtES5Sk7sBwc5z/Wl4zknApMc+9NY54703KwKLeo+IeaxUEhR yx9AK17O2R4jdS4VAMID2A71npGCVg6Zw0hxyB6VNdXBcCCL5VA59AKxvfUbetkQ3M6zyFsYhQnA Hc1ntulfcRx2qY7p5BFEPlH+STTmCoAqgEDqR3NHmUkQ7DjgdKUdMdh2pwckYAI9c0n4UJ3G9yxZ ybJx1weK6W3kJUAj6VyqZUhsHIPAzXQ2MpdQenHSkXBu9jZiOMcmr8T4AznrWShIORyKvxOGAIJB 9M0ro6I3NNZRgAkkVNHJkHnis5STxnpViLjnJApXfU1jaxoBxgA5xT+C3BwccVChGAc5Hv61IMZB HXrTuhokywxkc1NvVhjgeuaq789RkZ45pwHQcnPSjqGlh798HJ7Uh6DPBI7etGMN1yB2qN+COeCe aT8x3GOTnGO2DmoHycjPFSOeSR0PrzUbgYGTzQrCKsnAJJ49qqEjjccAmrE5BGOnoM1QdwDnqAaE jKpsRXTgAjIJB/SupjbwufCcMFtZ3SasVUvOx4LZ5yM4I7dPSuPIFzcKOi5yx9hWy09tBEHdlRQO pNWpNbHDUSkyQQDIwCPpxWjaW7TzJBCpeRiFCgZJJrkL3xSqkpaIWPTe3T8BWUNRvJ5DK80m4dCG Ix9MVV29WRFK2h9I6F4DWKNZdRI3EA+Wh5H1P+Fbx0rw7YMPNW1jYc4kcZ/Imvmq08Q6jBGNt7OA B0MpPP50PrM87EzSs5xySeTS3HqfTkuoeH/s+2S5sTEB03KR+Vc7HrfgWXU0tokt5LlmwuyAsCfb ivA0u7i5mWGAPJJIQqIoyST2FeveH/Dtt4I0P+1dTdP7TnAVSwyIs9h7juaauFr6M9GuZTHamKx2 I5HynbgD04ryHxb4qubS6exlu7jULzGGhtyVjQ+5659hXpEcs0+kwqJt00qAmTbggHqQP5V5v4y1 3RvBm6Kxijn1eUZXeARED/Efc04uxTpruc39v1uwUahcwWenQkgh5yWZgDnABOTWhrPxwvZbMWek 2kdocYacD27A9P515xLrEmq3bz6rcSvIWyrk5C+2OmKmnsIJoBKMID0kTlfxHahu5NhLjXdS1W4k uLm5kdmPzMzZJ9s1AHkyWDMCT69aYY/sv7ptpI7g8HPcVIDjAFawirbGV2noxyKWB3ZOe1U7mEpl sHBPGO3vVwz+X9O9OlKyxAkgjtxTkk0Ck7kVpKJUAJ+ccEVo2bkTmIjhgT9CKxbVjDdkE8scH61p pJ5V1E+TnJz78Uk9AluVdYuMBIBzgkn3z0rDmfC4GDV28ZnvXLAg5JH9KoMCXJxWMr3No2sNTJwR x61OQCo60xBwOgHvTwPzzU9RtajcANjpTieMjOaMEnpR3yeKdw0toGR3zUcjHAHTucVIMAZwc96j PJJIwTQgQ3jrkgU9eGGM4NNAB4xxS4I57Ci2oaCyJgkjj+tMBBHfPep2AdQRwcDioliZ5gigZJx9 KqMrOwmlYOmMdMUue4H1xQVIcqcEjvmkGe4Aq7oVhCc8jjNGCeelL3PHakHIwPxoFuGc8ZpenFAA 4IBpMkcmi6sNXF7jOeKUc8jg0gwRyOfrR0PTIoDUXt05pQeACM4/Wm8jkml6HOPxoFZsTGTnkGjJ /CjNHBJwMigEgyOhpc9ieB0NJgE/0NLnnAAo6gGcHJ59KXPXvzR2wcHnim45yMUnuOw7HOR1xxW3 pU8QtXR3CsSODWJjgEZ56mlzgdD9abSasCbTudUsZcZVlcEZ4OaXynQD5cZ6e9cxHLLEdyOwIHGD Uov7rgec/sSc1g6K6G6xEi7qrYCIVIIyc+tZXOAetSyTyzNl2JwMDNRZ+YYHGK2SSVjBtydxw57E ijPB6ijg55x/WjrxgH3p3XQWtgycAYJxzWrocJn1GNQCWyMVl4wQTzxziuq8E2L3mtwxoCWZwAB9 aT2FK9j6L0W3Fro1pEGChYhnA6mtKSQCJeSTnrjGKjjia3QRbMlVAA7DAqvKXeQBmwARz0q4rY5J bkzFUk3EFx7DpVWTyzypwwOCAelTLKdrY+YYIAA4z61EQYAHKgk8H3qhLyEY4twoywI7dz61CgOC SuAo6E9ae8h8wbEIBHIzUDs7OW+6q9QRSBR7nGfEC522EUCAjc2SM1yEIIXaSQAvQCtnxpd+fq8c RIATJJzWHGcxnJzu/lUq9zZaKxPGR5g45A7ivTPhjb7pby5I4ChAfqc/0ry/IAUgcn1rvfAviUaZ Hc2xs5Z1JDkxDJUDjkelOqm0OLUXqet1xXxQlWPwiyt1edAv15P8ga0ofGuiygeZO0BPaVSMVxPx Q16y1C3sbOzuUmCsZXKHIHGB+PWsYJ8xrUnFx0PMd2ST0wOuetdH4HszeeLLBWGQJNxHsOf6VzmA T24r0H4VW3m+IZJiufKhJzjpk4raq7RM4rVHafE26Nt4LuUDYMzLGPUgnJ/lXz7IPmJU5Hp6V7R8 X5mbT9Ps05LyNIQOuAMD9TXi8wKMQ2Qc9RSpr3RzXvOTOGzkfhT+AMkcfWkGB1GB7UcemTj1rNdj XUD14GAaAe2B7UbvbJxxQSCOmKL6Dtoa+lwWoUyzshc8KhPArVKFwCFBAPBHT8K5LPQgkDvU8d7O m1UldQOgBrOdJSLhUcDoyDGpMpCqM4J7Vl3+pZBhgJCDhiD96qU17PPGFkcsB2NVcHHWlCiou46l aUlYeTkdRgmjnPselJ7DmjIGCMn2rcy1sP4GckdaOB8x6Z9OBTRjjrnvzS5HPGT6elCtYEKW5xwP emknORx7UYyMHHHpU1vbPO4VRnnk0tgTI1UnIAJPcgUhz0IIrpIYEtogqoDkfMTzk0Pa20oG6IZz k44zWftopm3sZyV0c1jnGaOM9OnFbV7pttHF5qkx+xOcn2rEOM9DxWqakroxaadmGQT0HHFGev6U Bs9uM0Z49aA8wzyRjGR3HejGBjGTSZ5PHNGT1Iph0Fz2PB9KXnFJyfUH1o5B9+3PegBQfqOaMjBB GSaTPJI4IoxknFAXQvb27mnd+etJgAAEcEUHnjNMV9AyQf504gE+g7+9JwDyM45oznkA89s0dQHf LyccdqaDjOc47UhIIGAfzppJI6ZpN2Q0mxS/AA6+tTQJsHnMATnCAjqfX8Kjt4DPJjOFAyx9BWhl Yo/OK9RthT39ay3d2NuysiJiYBsA3TMcnuc+lVpXJYW8WWkY/MR3J7U6dzAWUtmdvvEHpnt9amtI xZqsrAGeQZGf4R6/WkK1tSYRRWFt5J5nYZZvTPaqJGATjFTTP5j85OT655qCQnlTnAoY1fqREgnr 0pM4NJjk9MYpwABAoKbJF4Iz65NXtOuCsxQnG45HtVHgLk/QYppJVgQSMdCKbWgRdnc7KM5Az+dT pwM5zzxWLp98rxhW+8B61rRuGAwe9R5HSmrF2OTaSSeKuxvkY/LFZasDwc1bhfp1OOmDSZopGhG/ O0E8DpVpCcDk9KoJIoPOSfWrCyAHGc5FC8y0+xKSwPAxnpUyueARj6VW5znJ/Onhug5xnv2ofcpE 7Hv1qMvn6013OcAHHc1EcjkHNK+oLVDmJyeOM9qikcgHigyLjkkfWqktyuG5Oc8Ubg9CCeUDOeor JnutjEAjJyBRqN+kQOWz7dzXNzXjyyMQSARwM1aRyVpq1ka8mqpbIViw85GC3Yf41lyzSzvvnkJP bngVV3kk4yT3p+CSO/PAqkjm13Hbl/hySOuaernjkD15pmCMccUYwDwOemaEgSS1LSyAHknntVm3 WW4nWGBHklkICogyST6U3SNJvtbvks7CBpZW6kdFHqT2Fe7eB/CGm+HIWmlkS51IACSXGRGfRfT6 01FvVjTRX8HeE7LwdZLrWuOp1BwPLj4PlA9hnqeeT2rVuriW9uBqd7HJIoU/ZrJCMuwJPTuMAGp9 Qt4b+9F1bwNcTxghN7Exg/TvUjeF9ekAnhmt1vmBAuJiSsQI6Ko/qau6Quupz2t+L5fDGmy3d3ct JfXaD7PZsADGcckgdAMgY9q8Kv7+fUb2W6upGkmlYszk8k16x4k+GcdneLc614ha8upwSfl2n8Bk nFcje+DINhe1mZCCeJOQR9e1SouWonPocYCOmMe9WLS4mtpAYmPPBQ8gj0Iretfh74iv1Z7KxNxG oyWjcf1OaR/BGu2mnyahc2TRW8EirIHOGBJ4GOtJrsHOrF2y05NSufKi1K0hZV5gkj3cD1J6Csi7 gjiZpICpQSGOQKcqGHcZ7HtXqBsbO10V7uIQoViMm2KMAkAZ5OCTXlUZL6ffTHoWQg5/iJJ/lmqT sybXRCrkyEOAR6VaAXYAMYweKr4WRgBkEgVMUMSEk5Hf2rZPQyMy4OyQMOCGyBV2aQvPb4yOQTWd MweQADuATir0EqteFn4jhQkn0Pas4s0ktCtfkC/k5yPT0qkRxkgnNEkpluHkboxPNSKDt45FZvU0 jsQKCQO9SZwO/vTB3IOOacTn6Uh3YoPI96U578CmjpuA4owMDjNFuo12FY4HfGeuaZuGT1oc4UA+ uajzk/8A1qBW0Hg5J4/KnjJ7ZAFRAYGRnNSjIAPQUmw66D+hHvSxkpOp6A8E03IbHXPvUbSHOBjr 1ppg0yzJECu76/hVXJBwcAjjFXElEictkkdMdarzIAQwHU4NaehCuNHQ80ikA/zpABzijBGQO4pt j6C8EAYpCT7fjRnJA596fHE0jbFBJPQDvRYPMbz1wOetGanltJoTyhzx0GajKMuQykZ9qNNgvrqM zxg/hRjnk9qMEeo9KAOp7mgL66BnJOOfxo/h9/pSkAc0nY4NMA+vSnZ59qaB3ycCjBxwaVhKw7IP PY0eo4pOnTkCl4J9qLsfmKOcAHjvS9Mg0gxn5elLzkA5P40LYQc5Jx+tGehxzS4xxgg+9JjAJIPW hIEGRkd6MDI68djTTnI+lL2z7etIfUfgg8kHPoelHAHt/OkAGMkCkzg9OKdhXJBjH4816N8LrR5N dgZcAqS3vivOVx0xk5Fex/CeyXzmuJAVVYxyOuTQ7XVyJvTQ9WZ5MMS+WB5JPU+1MBLSAMxJznB6 ZrhvEeqXM/iA2VrdNBBGpZiDzkCtPwXq9zf2rNdN5vlOUUkcn3Jq766HM1bU6V3YtwVGBx9aiyyA necZwcinTkjKqcFjwAKYIm2oWcEAHgH+dPyQJaXGySEkEMST3AxTX5iIJyQM8mmk/vAc4IHAJpl0 3lQySlgoAJz+FLZjWp5J4hmE+vTkEEKSB+FXrHw/qN3p63cFq8kByAwUkZ9qw7g+fqE8oH3nOD+N d34d+IEmj2cNg1srQxLgFTgnJyT9alXvdGr6I5Oe2nhYh0ZcHBBGMH0ruvh7f2Oi/aptRuo4DMAF V1OSB6H8a6CPxh4U1ZY47uBELNuIljGFPqSKv3WjeGPEUYkSSElBtVomAwB2xSlO6sxWd7otahZa HrVhMgNu58s4aPBZeMgjHevArshLqRUyyhiATwcA16ZrPgA2lubnSL2WRsgCMHHB4yCK5+/+GWt2 8ZlQJMTyQhyR/jTi0gbd9jjCQeCBivXfhLZlLK9uiMb2VB9AM1wsHgjWpZJU+xsrRLuYHgke2ete teALI2XhWBWGGdmcj3zj+lRVkmrF0/iPO/itqEj+KUgRmAggAyD3Jyf6V5xI5fLMxLE8n1rrPGt+ bnxbqb7QyCUoCfQcf0rkH4Y4GM+natYbWCT93Q4zoSMc0mOemcd80oHOTn3oJIGePwFYmzYoGeuS KMYHA7+tNLZPTHt3pd3HHA9aAV+ou08DHHf2pMgdAc0cgE5Iz1o3HlQfoaAvrYUcg5HfvQPpgj9a RcjjOfxpxOAOBx39aYmriEDnA5PT2pcHt26mkz060AnHp9aaYWYdvfvSg8ZIOMetNJ4PWkyc4z09 KA0LNtF58wQsEB6knAFdFBFFBAEhZCPUdTXLbu/605J3Q5VmGPeolHmViovldzp9jZ5HX1FJPKLa IyNjA4Ax3rHj1m4QYOD6ZFVrq9muX3M34A8D6CslRV9TeWIdrIdd3s94wDngHAAGAKqsOccY7Uue Oc5HU0nXBzj2NdCsloc7u9wxk88Cg88Cgkg9aTk8d6HuCWg7HOOaQDJOB9aPugc5pcHHNCFfoLgA jg8+9GN3Qf8A1qsWttLcyiOPknv2FdAlpb20Sp5Su2OWI5J+tTOajuVCEpbHL7CSSAcgUoBxnjFd IdMtpckqUOD0PBqjPpSwRtL5oCgcAjn2pRqRlsOVOUdWZPBPQ+1LyOwxSdT2/wAaeSAMEEH2rVMz GYBJxkUYI/P1pQRwM5JpMgZyQO3NIAbpjpg9qasbSyBVBJPQUYZmCoCSTgD1NaEUQhhbJ2kD539P YVjKV2Wk0PVEiTYciNPvsP4j6Cq89wY5DM4BkIxGnUKPWlllEUQZskkfu0Pb3NS6fYeaGvbs4iHP PU0a7CfcitLZYyb27GV6qpPLGmPK08zSsME9AOgHpTrq5a5nJXIQcKvYCoCSFH17UPsPzFDnOcDI HFRSEsxJFO9Mc1E2Sfxp2sgWrFXBFORRuGc8n1pgPXng8U8cEDIHHJpXGPbGcYJANJkFhgfrQrdR noPzoAHrj0oF1BJDFIGUkHPrW7ZanG4CvhW7g9KwSh3ZGDz0puWUgjgg8YotoUpWZ24lDrhSCexq xDKQMED2xXK2N9KWVCjszHC7QSSfYDrXQOtzbj/SIHjJAOGUgn8DRZ9jVVEtzUVwATj61Ksozw36 1jR3JzzkegzVyNZZeUiJz3HepaNIzXQ1VmzyDmpPPUL2x6+9ZyxTp95Co471IxKgBioHfJpO5qpd yw1wTnntxUEkxUZLdsYzVC51OztlO+4XOeg5NYl1r6yArbRO7H+I9vwoUWxSqxitzcnvRzuYgDuD WHe62FJERyfUVm7dR1CQRrHM7MeERSSfwHNT3Ph3UbOdYLqBoJCASsgKkA9CQecU+Tqcsq93ZGc8 0tw2WJJPOKUQMe2a9B8I/D611S6he/1CMWxOW8uVVJA6gEn+lewQ+CfBWi6d9oTR/te3AwwMjnHs TirS0MHNtnzHFbPJJsiiZ2PGFGea6bRPAWu65Iq21uiKcZMjhQB616Fqt/Nc6gY9H8PwWEIGFHlr kj1IAwP1rX0S8v8ARY/Ovb0j5cCFVBJ5+lXZdyPfa0Rgp8ERaxLNrGvW1vFxuEaEn3AJI5/CqB8K eGLC8bY813GjEAMMkjPc8AVs+INfhRWvJ4nDSt+7R2yzHtx0UVy9sb29uGlZgXJJOR8q+3NVGIpS a0Z2djJZRR+RpMMdrb9JHiUAke7dP1qWTUoIAYbKNrgjgKMqmfUk8t9OlYYsb4wqWugQR91eMGoW jvomHzMcd88CtORkOr2NRtT1eCQv5rxseAIpCoA7AAcU19Z1sKzPezhDyDJMeCeO1VvtpRc3C5AG Sc4rHnvJr197MQgPypnGBRNxiiVFyd7lxFWeZp7yeW4lYD5mcngdBknNPeNCvyowJ6EMQappKAAS MfXvU6XJDAAgDOR7VkqkmW4JDbTUtR0e8WS0uXhPI3A8HPqOhra1rxlrWoaNNZzi3CTKA5EPzMM9 jkjPvisaYGbgDnPXtTPs5GSQ2FGSAeT+FVvuidtmY2pXhj0OZBI/mMVhjAQElSM4J6n04rnbwfZo ItOQAyA75iP73YfgP5muy/suC+VZbe4CspOA68oT3Hoaxm8JXtvIzxuJySTndgn86m2pqm0jFigK Hc3JPY9qiupgF2Dr3xWhdwzWK5niZPTIwDWBczlmJ9RVzkrWQopt3K7uTLgdc8Y61PdHyIFtwcyN hpCD+QpI41iszdOQXY4jU8n61UJLEsSCTySay1sa2uyRYsKDjqO9OBO0gZwKBxEBwSfaomcqTg4+ lS7jW4qgEZxTScE46UqHCAnrSck9aSHqO3YUUBgwGcgDpTGzkfoKacg9aaF1Hyj5Rj16UwA49PrT uSMZ6evak5BxnNDYLuP4AOO/WkJyAOMZpFHJz+VP4A6ZpIeiHRgA5xxUbR4JPY+9PySO+Kd1A44o BNiW7qjBHHHUH0qxNFuQgYJ6g+oqkRgkVYhmJAjfP+yauL6ESi73IO3TBzzRznngUsibJCM8HkU3 JI9qthdDsH8K0tFQm73HBAGfw9qzATjjJ4rT0m5ggdjM2GIwDjpSd7B2NSU5clQCM9TxTNgcEEA/ UU7fBPkxToST0JxUnkOOBg+47VxtSTO9Sg0U57OF4GIQKVBOegrDONxAzjoK6C9DJYSBgQcj8R71 z2AB1571002+XU46lubQUg5HHtSDgHjNHJOc9qXGDyCKu6IG/hTskjFN/iz09qXnB55PTihMNLC9 vT+tGDwMnmkweASPc0uDnIOaLgLwOnXFJnGOe3alxx0/GrBsLkRCTY209MCmBBk98mgEZwc4xTjG 4UsVOBxkDgGm87elF9RhgZ6cUEc+tHccgU48+1CQdLB3AwfajAIIwc9uetAyAM9e3tRjnsKOgiWF S0gUjqRXvPw7gFvoErsvDYwfXArw7T41ku0BPfkV9AaJs0/wQhJYHaWPAHahJXMqj6HGXN2X1HU7 kkkgFQR+Vdn4Ethb+HFndtvmMWwep9K86mctp8sucmeU5x1xmvWfDsCwaJaxEgEKDjHXimtzOdrF 6U73yuMnnn+lLuiUj5gSRgr/AFphby5ySPkPGQOlVchpRhyOuB3IqvMzVth8oQYCtuJ6kdqzfEF6 sWhTgZ3hSCT9K1W2dUDZAyOMVyHjW7KaTjacO2ATxml0KhvqefwyliFAA5Jz61Yzgk5yap2SYYkk HiruORjBHWqgrI0k9R8YZjuHH+FSh5hwjsoHQg4rrPCPgybXUNy8vlWwOC2MknuAK6a6+F0Q+a0v OQeki9vqKTqRvYlRbV0eeWviPV9MI8m+mUADgtkHHsa6jQPiVdw3qJq0nmW2DuYLyP8AGsTxN4T1 DQcS3Cq0UhIDocj6H0rlCOfx5Bp8sZK49vU9kb4naXMs2y1nEwUrGePm9M+nrXYafiy8PQNJgeXA GY/hk14B4ftDfazaW+AfMlUH3Ga9y8X3K6d4Pv3B2gQ+WD9eP61hOKU7GkW7NngGpXMNzNLKwbzJ JGYn1ySeaymyQCBn/CrlzEqAMjbs9s9Kque4APY471utgelrnDZOc8gGkJyOmD70nO4HJFKSM7SS PesDYXIyAR25pcYIwOew9qTjbx3/AFpODxkg9qF5i1FyQc44Pc0uCSOgHtTQAFIOSc9aXK47jHvT 6BbXUfg9uM/pTCQOucH07UvAwQabgE9DjsaFYBxPAwOB1o7nI9qQ9cc8+tGOecn6UAkxQcAccDg0 3knoPejAHDZx1p2ARnofSmgVxMdsEfhSjpyOlKCNpBPI6EjrRx0/rRdBqIeQMAY+tJyCD0FKQMcZ puRwD39aegtmLyRgA/jS5we1Gecjp7CjgjnPrS0SE7hj1GM9M0YB68YoA3nB6UEgHABIpqw7i57+ nUVNbxNPII0AJJxn0qHAwecHFOileKQMjFSO4oQHU2tmLKDagzIR8zevtTyDwQDn2rnl1e7HHnEk nqe9WYdddMCWNXAH0JrmnSlJ3udFOsoq1jZHCklgABls9hWHqOqG5HlIuIxxnPX60l3qpnj2Q5QH 7wrNyMY561pTp8urM6lXndkOyDgDNJliTknGKTOMgCjuOpzWrZkkOAyQB1J7dqRsAbRyScZpSQow M574qeGIoVY4DsMqD/CPU1nKXQtLTUfbwGPJJwwGWb+6P8aWWUBRKwIgBwiE8sfU0+WVXjJwRbxn k9DI1QWtu2ozmWU7YVxzjgD0FQt9Ad1uS2Nm99Obm4B8sdj0PsPan6jfmd/Ii4hTgAcA1Lf3apH5 EIKjGMA8AVljAwQOOlU2Sld3Y4fKpznJ6c01ueuDxyKsWto92TtIAHTPc+lMuLZ7Z8OMH1B4NOFm 9RtNIgzjkjPbimdT0pX+7kdzTVIxgke5onqxx2DBLYxTwp6k/hS5VTwM/WgHJwOO/FTcfkOwMdef egkAdMmmgD1yaXIGDjjoKNw6C7j04FOjhknlCIpZvboBRGhdwqglyQAMdTW/b6Q1vFl8+YQCQDwK V7C1NPRtZl0Czjgs0SKfcWadVAkYntk8gAdhirsmqXN+++9JkL8kyMSc+uTWIYnQYBOQRweRTd7D IcAgHIAJGPyrSNRbEOm27nV2Z0g74tT0qWUEAJJaShGX35yD+NVbfSpnLNbPIqZJUuwGB6EjvXPr 4jitnKhHkxgDkEcdhXV6db3WqWSzXMsVraMMgPKASPQ+1X7m5CVTm30MO+e5DFIbpnIODgZA9we9 Yktjqs7ENK7DPBJIyPpXf/Y9GgYl9as0A7Bs4FH2nwnAA0utK+OoSMkZ9OlZNa6HSmktWcFBoswl JeEycAgFiOa17aC7tlK21tDDnGWCkk/jXT/8JR4Ni4Wa5cDusfWoLjxn4WbAjsr1ieBgAD9aaugf JYzNHu9d0q8kk0u6aKYjLMFBwPx6CrNzq+sX12LjW2jv2VSqifAK59NuDVObxnpSMy22mTsDwN8o H54FUpPHDDm30q1XB4Lksf1NK19yPdvoa01tb3NtbPY2LwXceCzgFgxHcelej6fqesvoNis8UmZF KzM5JMmDjIxgrxXj7fEPXwuIpIYFJ4EcQBxVWTxt4idctq06567SB+WKatYTPUrjRL+O9l+zNIkJ kJAVsqBnoO+PTNUZdEuhKZXluXOejzYH5Zry+XxHrU5w+qXLeoEpH48GqbX107Ze6nbvy5J/nS5Y 3uWqklHlOp8Ra5cQbrOEhR5gYgHPI6E5zzWAdc1Tqt3IpHoap7y/LEse5PJ/+vSZAIJJ9u1XfQz3 d2akfifWY1UC7dsdNwyal/4SzVnIJlAx2I61jAZLEZwAT9a1NH05r+6DlSYEOW44PoKLsmyvsdLa Xt7Ppyy38gzIflAGAB1yaq3HiO0tDtjzPIDyBwB+NUvFtyY1tbZCQcEkD04ArnLa3FxIQxICgE46 k1KvJ2G4xWpunxXdG6V9iCIfeQc5Hsa1ofGNg/DI6H3Xp+Ncmbe2ilKFS3qSak+yInzBBj1xzWsY yRnJpo7+31u0nAKToTjgZ5rQF1FIAQwBxjIryi3guL24MduqggnJJxgetb66Xf2CxldRDOQdyIch fQHNHt0nyi9lpdM7BgIpTIg2s3XHQ+9H2xuMk56VztrqN7ENk+HA7jj9OlXzOHUMAdh6knBBpVLN XW44XTszUM6XCGOZFkjPUMMj9a5jWfCyynz7AEAnLRE8Y74Nb0KAqDjI61T1rVVsLfyo2zcN90dc A96x1NEnc8/uEl3MWjZUjO0A/wAPtUI5HHfvXZ2eird2rPellDAnAODn19zXJyWy2t/NDvDqpIBH cdqd9dSlsGCqgdagYgk9CSamlZUHUA+lVfvEHt3ov2GlpckwSAOgp4XHOBz05pgGSOpH1qTHB4yO 1LqAHAHI/pSZU/w8mlJHAOT6UA4zj0ouCvcayAZI6VHk9ae5BUAdutR8YJGaHYaH5GMgHryc03JL HmkyMZ9aXIx0x6UA0OU8ZA79amHTp+J71CoyRg9O1TDGOemPTmjSwEchwBnmmRyEyKeAM96JeWAG aFRQg9c0J2YrXRZuRhVcDIBxkVWyc4q2xMsBUgZA7D0qooBGc8gc1qmmRa24ucc0Ak9OD60dhnk+ lHBzyc+1Fx2FyRjHX2qdLmdOFlYegzVfjHQ5oIBxjOaemwtblmS9uJ4ykjlhnoTVbJx05peowBg0 g6E4zj0pWsUh3I5wMfWm9zn+dA5GDnNLwM5oYl5hkZPAFGen1pDjnHFLnAyRQJC5ySR2PSgk5AAA /GjPy8CgDOODnuafQdh8YJcADJJxiumcgWUMX8QAzg1zCcMDkjB6jsa6RQJY4juXpjk8k96zqJ8u hVNpS1GbQQEwCMjNNa2hK/Mg5ParAgZSDtyT096ZtIOCp69K5k5Jnb7jRi30CwT7EGQOR+NVR0OR VvUTm7YgYA4BPeqg5GTXYndI4Ha+g7njkHHOBQMkgj8KbkE8Zx607GeSD+FMLGtocXm3y8ZIIr2z W5GsPBwUEKpjCkDsSK8o8FWYudUiXBwWGa9N8Zf8guNMkx7gCByMjvQuphJ62OTw8n9m2aqMMwJH HJr1tMRQIhIAAAKjqOOteW6LGb3xPbiH5liUc9uBXpZJCDDAscAgCnGxMxXndwyhmAB/DHrTHO0E 9M4GcdqcCEg4xgnqe/4UBTIABnYOCT0zVakXWg8kRZVF3MVAJJ6D2rz7x9dgywwAtjkkHtXfTXGG KqwAAxkdTXlHjGcyayy8naMA5zU3SNIq7uULbJQkjvxVyMHJBPHc1UtFAiUDOSPTmragjJbOD3rS OwO3U9z8AS258M28MUiNIuTIoIyCT3FdXXlnwxvrK0F59ouEjkcqEEjYyOema9PSVJV3I4YHuCDX LKLTN6Uly2ZleKLO3vvD15HcgbFjL5PYgZBr5ycAsSAeema9/wDHt6LLwdftu2mRRGDnHJOK+f8A jGQc465OcV0UfhMqlnUsjsfhxaC48V25I/1YL9PQf416P8QbafUNBjsIMb5plzk44GSa5P4T2m/U bu6I4SMKCeoJP/1q0PiZd3wv9PgsNwaJHmYg49AP5GsJ/Hcio2qTtuzyXU7KXTr2S1lJDIxB44NU DnPBOc4NWLq4mvJ2kuHeR8nJJ5HtVcjgEjORmumKbWoRclFHL3otkT5VAkz2OAPwrOJAyR3FKxZ5 Cz9Tzmk29O5965oqysdb1dw4CgDr1z7UYGQc9u1HOMk5x1oHJP0puyDUBwMjk0ucEHBI70gwAQMD Io5yAc5o6XEGOemBQCBwB1PFGQTyT7+1Kwz0P40IV0IQTwT0zQMDnJ+lOIAB69OaOuSeQKq6BNob wc8/nS5wfXmjBwPekzjqB6cUIet7i5G7JJ+lJkEdQPSk4ye1Gc8nip1uIXsDnPrSZAwMZpeBjnmj J59B6Uxi549AaUHg4JHvTT2GeKQ8cdBQA/oSc0E4GSM0wHJxxil45GT+FGtxC5GTznFH8RPakxxn qKcBlemSapNWGmgwM9KB2PtTckYBOTSknI/SlcPMAASe1KOT1xj0oAweuT+lAzk8U1qLccQBg5z6 0pXy1znJxnHpQv7s7jzxkCnLGZSZGJCgjJ9fYVnOa2RS21FjjAXz5QSvRV/vH/CnZLhpJGIXjc38 gKcytLId7bUQdMcKPQe9RbZb+cQQg+WOg/qfeoDzHQxPqM6ouVhXnHYD1+tXrm5SCJYYQQo4A7k+ pp0hjsLdYI8g/wAR7k1ms/mPk5PPrRsJWluJy7F2JOetSRxmVlRM8nkntUZJIxxk1saabSKEs7jz OrZ4H0FDu1oUnFPUswpBZW29yAAOATgk1hXdw1zM0hOcngDoBU2oXv2qQKpIjXhR2+tUs9cHNaQh yq73FObkyOToBzn0puRwaWQknrTeQOoP4VMr3BbDwQRnHNOXAXJGTmmr0PcYpU6H+VIYdW9Bin4J xk4Hr7UwdyTmpYY2ldUQFiSAAOtNeYpbHS+GdMEmb11yASIyehPc1vyxEggY/LpVuzt1tLGGBQAF UA/XuaHQEYyOe1Q73BMxJYigOcY6k+lc5qOoiTMUJO0HBYHr7fStXxNfeUBaxNhj98jsPSuYVCzB VGW7CiK11HfqNznqcVL5ruAu9iAO5JAp4tHIJxgA4JPan/ZHUEAcgZI7keo9a0FdEPJwM5FJwFxj vxVsWbkA7gQcEHsfamSWjAAg5AOCM4waL9hWRUwCcc05eGyHwB604xlSQwIPv/So2Qhjk8+lLWw0 h+BgncSc5IpRgkAMMHv6fWnQ2zOVLE7MgkAjOM44FSLAiyOrbgCCF3EDkdM9apLS5N7Eb5HBzz0P rTdwyAM49O1JkAgEk8c5zgUoETEYYgngkjilYabAeoyM9T7U0nHrjsRTjwcKflxzmmhwevToDSsP SwfNwc4HWgE5PJORRjBA5Ge571as7We9uBDEpJ9ewHcmnfQH5D9OsptRuFgQkDOWJ6KO5r0G2tYr O2WGIYVRjPqfWqunadBp8ARACxALMByT9auzTrFC0rnaqgk/SobuKxw3iWbzdacZJEahR6Z71n2b hJyCeGAGfSkuZzc3c0zE/MxOPbPFRxkCVQQMZGRVQ0YSSaaLd4MEOB35NWoCDACxIBAqB1M7iIEk ZyTjoKtY8tQOCoFdXW7OdbWKq280U5eCTbnvTpXcAGWdm47sTk96ZJOSxVMk+vpVcuASGAZj09sV lJxTukWot7l2wvhFfRpIxEbnBJPTPQ+1XrfWZDLNbMd7RMSpHRlz0PvXNOX8wEjOOR7fWtLT1mQE sADIc5A5NQryZVkkdTPrkNpabwdznhVB7+hqrpVi9/Mb+7bOeQCeBXK35IupWUkBWGPY1fi8QzLp X2XgMDw2Oo96mSsy1qjU1/X1RDbWpPy8Eg1ykUuZC7nccZ5PU03JdiWJJJyfehUGSTxjpkUhpBI+ 5yegoQe2KaepIHFPyQo4NLqUO37CPlJ96dvVgfmwf5UwYOe9BAA6Z/DpTJ0JOCBg8detBxj3HpUe B1BI45FNwc9T06UFJDic/wBab0HGcUZxzjjvR6kdKPMWocAc9OlJgZzz/hS+nTHpTuOuc/WmnqAo 6DPGacvA4GT7U0HPU5qRcgZHB9aQmuxEeW74qUgBBnmmMQDwfzpm/Ixk+9IfoOaVtpAOO1IpGMkf Wm9QfShRwCDz6VpDcTWg4kZzn6UvBz1+tJ06igcDrxViXkAPXBPvTvTtTec+9O7YGaLEsb35NHQ8 ZNGMHHU4zzRj0NJWGKOoBznNBxyOvNJwDjrQTlc8gg0XHZC8dOvtS5GCCeO1Jnocc0YHJ4zTXYBS RjHP0pRx3wKb1zgZP0peCADn8qQrASfWnq7A8Mw9OaZ0OCDS5GOP1FPQLFhb6dAFErjbyMmrMer3 KJyQ47Z5rOzls8ZpQeTk/gKmy6jV0tGT3Ny1y4ZsZA6AcVDxkkijgk96MY5zgj1qhXDt7U9T8oBP B4HtTFIY4OT609RlsDuf0pXF5novw4tQ97vPG1ScgdTXqUttFcRlZo1ePurCuG+HVsojd2yDtAH/ ANau7kJ3GLfgHGSacb2sc837wWWlWGmASWsCRq2QzgZYnrj6VI8SyBpFbj0zjik+0MkSwhlIJxnq KQTqCyiIlQCCc9/eqSaM73FyqYIdWI6AjIFMM4jhYMRjOSe5+lVWYiUE4yR8wA4FPUm5c8DPQADo KbbHZCT3Ci2LKMbQSCRXkWsXBk1WaRiWO88ntzXp2qz/AGexl5AKg5Gea8kkYy35JII3Z5+tQ7aG sE1qdP4Yu7K11i1lv0326nMgIByMeleq21t4H1uXbAIlfbnGSn8+M14rj+IAgetSpIwJIYgjHIrV xvsxWPabr4c6feSrLbXPlxgAYQAggdTnPWsbVvCWr6FFc3lhqMiQRYKqJCGI/lmuTtvHOs2WlLp9 vOI4wchwPmHtmrVr8RNVihFvdeVexHGVmXk496hRmmKUYNDtWi8W6npD/b/Pe0gYMwcYOex965Ax sjgEEHODkV61YfFPTp4xHqNk0XGCUwy8e1c7421fQdUhtTpESLKzlpiI9rAYGM/rVKctrCUUtmdh 8LrTytBmuCuDLLgfQD/69cv408VT2Piq/giRXURrFhhkA45/nXong22Fp4TsVxgmPcfqTmvCfEt2 bzxFqFwMkSTsVJPUA4H8qwhFTbuXUipRSMa5mM0rOAASckAYA9hUHJGSP1qcjnIAyf5UwjK45GTg e9dSVtECstDg8HJ64P6Ufw47/pS8+pH40p9/T1rl6nS7IbwB3IozyAKXAA6/hSccYJz60C0YcBsg DHXNKOGzz9aQcdCff6VZtbR7lwqYI4yemBRsFhLa3a5lCKCD3J6YraW0tREItgZs8npmhIkto9ij LDGWHc04cAnvz0zXPUqO+h0UqKavIryaXC7ZhcqMdxkZqjPp0kCeZncvUkVsKcqC7bVHJOcYFZOo XxlYpESYwPTrVU5ybsTVhGOxQzkY7UE5PANJnoDn3NLu68cdq2MQzjAPPvRjuBx7UAk9enpS+4JH pTsw6iYOehxRgcgdfrS8k4JPB/OjjB+tCQabMTr0znv7UmeSDyMZGad1HTHqab2zQFg5xkYxS9D0 7U4A7cj9O1KCMZBJ+tOwaiAEjP4YoBxnjHbrQeRnJpMjOc5zR0ELgkgD8KMHJ4wR1pO+QOg4pQSc k/jTQXF57DmpFj4LEcAc57n0oiUuxGcADJPoKGJmYRRjCj3xx6mpk7IEtRqIbiQjOFUZY54Aq1jc QqjAA+UE/dHqfekAG1YogMHkH+8fU+1RsWmkNtEcgn5mHU+1YtlDSXupRbQAlQck92Pqa2I44tNt 9o/1rD5jjoKljhTSLcO4UzMMKD2z3NZN1cmRzliSeSc01awne5DNIZJSzZxk45qPOBwOccUmcg+v ekGckk8dqdtS1ogO4nJzk0NkDBJJzQTgg9+4zSjr1471rFJIz31G4wBnNGB6fWl985pOMHJp3AYw 7gUzGAAaewG4YpvfnrWL3LS0FU46c0uMMGwT6imqfQfWnHGMgkevNAkmSMBjIrU0DH9rQqVJLEYO cYxzmshX6DtW34cAOrxknOFJAppiZ6AxGM8Y7YqCaRYYHkbgKCT9Kcr9AMY61j+KLrytJZQcFyF4 44qXcS3OPmne8v5J+rMxIyOMVZijTGcAFjww7H0qtbrkjbkEjg+hHrVwMMFiBtbGTjIBq4g3oTIQ CXKg8ESKBnj1H+NP8tiAqjLdYzjO4envUcLkyFiQSow6n+IevXk+1SZL/u1YBG5jJOMH0J/oKr0I bDywFZ8kRA444CN6k/4U2RPlBYZbjcMYDD1BPJ/KpwQVDkjjiQYBz7gf1phBM42knAzGSMsR6e1F tQuiBolkwWAIA4J4BHpk96pyQAAkICAeDjn8fetTapHQgMeR1ZW/pR5ReTaVy6g7gOSw9cngGiyK Ri+cFPzKSOmOtDKsrgrgHnJzgH/CtKS1ikDHAIIwHHJB9CeBWdLbtCdysTjg45x+NJt7Bo2R4aM8 gEZ69QakCxOAGQofUcg0iyEhRkkZ9OM+9Sh0IOFCkAA46HnqR2FJWG7kDxOh6BgByw5BpoweqjAH XNWZPmjBBYZJzxhT9KbFKEIDIrIOCQvUelDSuCZHFA88qxRjczHCgdzXfaTpCadaBQFMp5dupJ/w qj4b0+Py/tZhVRyIyc5I7k10gAxwaljV2iNYiTnAxXLeLdTEKrYxk7mOZMHoOwrqLu4WztXmbOFX OPU15pfGW4uZZ5smRmO4HqD2pJNg3YqqQWIOcH0oY+mOPfmho2QfMCCR0qJkbOMjNVsO1zZt3URD ywASATk8moLi5Z3EUWSzHHFZqSMgJUkZGDz1ojlaOYOgO4dM9jWjqO1jNQSd2dFDpCxLGLmZUZ8Y QN8xJ7H0qnqkSwSxwqBuAy2O2egp+nwEzrdXTmRxyE5JJ9zVoaXPd3TTy8AnILHAqYxbYNoyYLZi 25h8uc8963Rbf8S9mVTnBPHWrMNpDAAMNI/sOAfarXksbf5QR1JH4dK1UbLQy5m2cWFMshjJPzMM 568mobqHyLh4lyVUkAnqRVzhLjLdFbJ9sGmX8sEt8WTJQnk9M1i0bq+hTTlsdMdzXQaHo/2yQXEy /uVPAI+8f8Kr6RpA1K8JAIt4yCxJyT7V3EUUcUaxRKFVRgAdAKnUbelkc7qnhdZQXsgEbuhPBPt6 VzE9tNakLNGynOORxmvSXcJGzHgDOeax3AugzFVMecAEZzVRjcXNZHEYIzkH60ucjpXRT6RBKcoT C/5isu406a2BZl3KP4l5FDi0xqSZRIPHYUFelPyCeMnAp42kdDn1qSrkGCR0zijIGOOamIBPy4/H rUWASAOD70BdCcHJxzTsHHT8qkVOP50FlQDnj0pCFRDjOAaCAoPPPpTN7E4HANGQMkkk9M560wu9 xjY54JJNK0Tou5gVHqatWlsZXDMCFHc9zV69tAbFio5XkU7KwuZ3sZAUCMkDOaYucZ6c9KXY0cfU 47ikQ5HXvTi9Rt6DtrYPc0DG3kc962NKiikt5POUEdAccg/WpmsrVwQIgDg8g0SqRi7MIQk1dGFn jIHFIeBnGM1qf2RwSJAAOnFVZrCWFdzFSueCDVRmnohOLW6Khz0x+VKAMDjmgkgjijI/wyaYtLiY O4/Sl6EgAECjByeKOnqeab2DqGOeASB60Y5OfwoOMgAEUuM8H1qQAZ7etL3xgGjOR34oAOaYwwff NN5+tPIwODScepzijQQdcEA59M0d/fNHUgelHXHY9qA0THcZ7D0o5ByMH1Bo6DBJz7indRnvQnqH QaORxjPsKnt0DyqCAcnHNRAjAxnjtV3TYzJdKOhFPoS3ZXPaPBEa2mjbnQhpPun0x3roWOGLsCSR gDsfrWXof7nSrZXUgqo/EelaXnh2JMQAA6ZwKaVkcrbb1HYYEDaDn0HA+lTbxGwQkAkfhVZpHcAD oOgBwAKQiOM7nJD9PXiq3QrJIhfeJCVJOSTkDrQCzMTwjZyQDgU2R/uomeepPUCq7s4JXgEHOT1x S6AZfiefyNMlBYEtwB3Nea23z3THqASfpXZeLbkG2UAZO4k81ylgoyzlRyetCXvWNo/CXwDtAwc9 jT1UgYI784HIpyjJAI+mK3dI8MalrRP2S3LAdXPCj8a1uoq7IuYLDIJFJgkAda6W/wDButaeh82y cjuyDI/SsKe2eElWUqR1BGDmqTT2BPWxWGSCDyc/TAq3YxG5uI0AwS2MHvmq4U5BPJ9zXR+DbQXf iKzQ8r5gJBHUA5P8qippG40j24q2n+HSkKktDb4VR1JC8Yr51ubS5SWQzRMHJJbIIIOeetfTmOKq 3Gm2V0pE9rFJn+8gNc1OaibSpttNHzCYyByOQODUZQ46EnqK+hL34f6FeAkW5iJOcoePyrltQ+E7 AsbG7U55CyDB/MVsqsSHGS6HzKTuIxkEe9GeOeTSZHckDHT3peg7fgaxRu97iZzwD60ZGOQQR096 MkLkgemKcD7DHbinYE2JkZB/MVfs9Re0UhY1IPUnqR6VQOCMAUZIGDgD270O1gTNyLVYHAMqbG9V 71Y823aPeJgFAyQOtc1k5OMDHXNLnoR+lZeyi3ctVJrZmhfX4mbZECE9QeprOYjPU570oY9sAe9I ST1AzWiVloS7t3Ym7kHB46ZpAfel4OAfzpQOMYFF2K2tw55APFGTgYxxSjjrgf1o46cE46U9QABi B/OlOTwccUvOD2ParNnZPdyYAIUck+lF7asBLSyluc7cBQPvHoKedKuc4Chvoa28JEoijGABjgYz 70q8DgkGsJVrPQ3jQbV2zmzFIjFSpBB54ppOM8EjviunyACzhQM5LEDkVhX0kU05MKhVxjjv71tC fMrmM48rsVMg+3HSjHA4/wDr0oxj3PQUvcdOvWrV7EsTGD16+lJhgCTyM0/ueMgcmmlugAGc9KUp JIEmwyzAImSWI4HrVpIgiiJfmYnBI7n0+lOhgMClm4kI5PcA9h7mmSMyuIYv9Y3BIPT2Fc7bbNLd hHLFvIg+ZzwxB/Qe1blpbxaPaLPMB5pHygjOfrT9M0uKxt/tF3heMg4yTnpWNqF+95cEseAcAE9B QncLWRHeXr3UpYkkknqelVc8H1px6DkEikOSARg+lUKyG88Y9eaeSBjvTeo4wAPekxjGMc81pBab EyfQM8YNHAHB/wDrUcEkmjOCAQCD3q9CQzk9Pxppz1A59DTjk+mPSjp3+lICNhyO1Mwemc81ITkY NM2kHP5VDWty0KCAO2adjI68H170zOM9808HgZx1qb6js+gdDnoK1dAlCapHkkZBArM4JwQPepYH ME6SA4CsCcUadBanoqy4GDjArC8WSB7eFCSACTj3ArRt5xLEpGCSBzWN4mIcxjcAQpIHryKLXZBi 2ZJUgkAHjJ7H1q/vAJZgQuAHGM9e4z3P6VQtsJGTgEkZIz1FW1YgEk8gZzgDKnvz39KrUbJgWi4Q 8p90g5BB7Djk1YRwVEWAI2+ZQGOIz7n1qAEgKquFx80RLDEY9/epS6FQzZ8iQkeWJASzep9qdmid CTzyFM+cyL8ruTy49AKAmAqglRJho8DLE+hPaocyySYBDXEQ5JIIA9BUqYwMsRDIchgAWLeg9BTT E12JARuJwdwGJYVzyPUmm5/5Z7lYdYnzhV9ie9PG8EgofOGcxjILr6k0zI4T5WiboMkLGfen1Czu HWMuNp2nEoPC/UAHmq88TOqh87CDscggEemKsFyWzkNOg++SCrD2FRNsKggny3PUgFgfYZ4FS9io NKVykYkRehEbEhgxyc9MgCn/AGZQozlGUAkucBh2wO9RTMyyFSAXHByQcj/GpPPdEDIpJXJVicke x9B+FKJU7XuuoySBu7kwkZjLcDPoBTrCzbUb1Ihk5OJBjgDuRilM2No8p1EgyGcZwfbFbnhK1Jku bmRSSDtU4x9TQ2QkrnTwRJbwpEi7UUAACps8Zx+NRhwDx0HrTmkCjnjgmoKszl/FWppHJHZkbsgs 2DjHp/jWB9pheIlsM4GGJOAw9AO5qPVbgXepTyEg5YgfQcCs7HzA9veri2kDimSO5Zy2OMYH0oO0 kEkLkcjGaTOScc4HcdaTjBIIz0A7mgfQfGFQBiw3BuFIzj3qzaW7XlwpWLcQ2WAXgj0rR0XQJb1m nnhJAI2hjgH6+1dHHpjRxkbhCvOAgwPzrWFNvUxnVinYohGjXlYYFBx6kU5Lm334LPK3TJ4FZ94D FNtRjLjkkmqn2x4iC0ZAHoM1o0kQn1TN6SeUnEKqo7n0qz9rWKIjAJx+tYg1NHjIGQSOvYVSmu7i SBvLOVzgsOxNJzS2Fytsz7iQNPM2cAsePXJqiMEYPrUs6PFLsdSGHXNRdB0rmd7nXG1jb0DV49OL Qy5CyEEt1H412cF3FcRB4nVgRxg5rzHJwM4qxbXc9ud0MjJjsDxSsJrqjt9QuySYVyGyBnsSagdx GiopG1Rj3qnFPLKqSSkM4QHjjk0yS6QvtJww6jFdEVZGMncsfaFBO4AgnAzUZuVJ4yDnBxyPyqo0 oeTGeM1KJokJyOntRdPcST6Ec1tDKSzw4B/jQAH8qoPYZz5Tqw9M4NXJ9TRTwQBWbLdlySqgEnrm oko9C481xksbRYWRWUjpn/GoDjO7IA9qkNxNICrMWGOhojtpXI2xEA9OKzNU1bUZ5m4dcD1pMgtg DOa0YtOPWUggdQOTV5LeGLBRFBxjOOaEhc5kxWE8uPl2qe5q8mmRJyxLDsDV7JK4wPwpAM8dPWmr dSLt6CKgCqFAAHYCpZ3WOzkJ6bT1oVQBms/V7nEQgXlmxn2FHQa3MckeWc5PPWo1BOB1zSuT93j8 KFwpojuVI6KzQwaepA5c55HSpMkgdeeCBVW31aJFVJkJAAAIGatxXFpO5CyhT1GRjNZVISk7o3pV YxjZinAIB5Ppmq+oEixOBgE88Vb8oO2Y2RuPWs/VpGEKxFgMckep9KmlFqWpVWpFx0Mc89RkdqTB PIpScDPX0pOSc9K6l3OVbCgnv0xSYx0JwKXOSc9OvWl5JIA7Z5oT7hZgD6jNJxySMe1HbgDpzQTj jv70gSYo65560o4PXn0pBkgEUfhzmmg2Qv8AX0o6njOasW1o9yxVAAR3qSTT5kYrtBwOSDSbsgSv sVPQ9R35o7ccDNP2OBjbxnrimlCDz696pO6ATORnj2pRkgk8DsM0nfp+XalBGSB17k0gHKDjqcA1 teHYDNqKLjOSBgfWsTPOMj8q7PwPAH1ON2AAByfpQ7ky0R63aiOKFInYgAAA4wBxRv4Kq24ZOOOc VGWDkBckjmhiwUMAAenFU79DltqS5wFYgMQOQen401pEklXJ2g9SB2quJDgg8k+gzk0M2wAldrE5 yfShAlqLcjZIQCRzgc9qhk2pAxZiCffrTicyFmKsSMgk5xUEhGxyxBI56cUbsrS5w3iyZDdBVzgD BB6ZPpWdYD90CT16CjX5/NvnP+1gZ6U+2Q+UoA6Ad6cNZXNHsaMJBkAPfHSvojwxapaeHLGJQP8A UqSR3JGa+dIyAwPAzXuvw7lnn8NJJPKz4cqgJztAxxSrp7ipP3rHW4BGCK8++I/hyCbTDqUEapNE cSFQBuX1P0r0GuO+Jd2LfwjKmeZnVMe2c/0rOk3zpI1rpcjZ4ceDxz2FdN4G1S10vxDFPeHZCARu 6gEjg1zLDJAHIPfGTSZOcDGM9z1FdUo3Vmc+ttD6Us9Z06/GbW7il9lYZ/Kr+7PTBr5ihuZYDlHZ TnIwcEflXf8AgnUtWv7nyBqMqgAY3HcPyNYSpW2Nqc6knax6/SVTtUvo0xcSxSHsQpGasqzfxLWN jbm7nwsQABjmgAcDHU9aDgD/AAPejoAeQTV3EtrBjDcjg9jTicn2pMe+fTnmjPU4Of50xC8nAGBk 03bx3Hbn1oHJzyPU5o4Dck4pWHsAHr096NmACfXjFOB55JIJ/Ghicgnn0FOwJ6DejHJz6UgPJ7nF GDgg45OeaU47c+tJofTQACRjjNG0jOccdKcuB1544oIzyCc9xTSJV+oYBHIOfrRgYH6mjIIAwQKU DPA+lPXYOtySCMSyKpwAT1J4FdRHCnkLHCylQMEr3NcpkqeD0NSxXEsTEq7AkYJBqZQ5la44ycZX OiKFQMKeh/GnJHlM8gj7xNY8Gr3MKFdwZfc80tzrEssIRTsGSDt6n8axVDU2WI0sN1C985vKT/Vg 9fU1n5xwR+AppOWJGcdetKCOvORW6SWiMLtu7FJAPPT6c0ijP1x3NIOT3NKMDJJwPQ96ptJDtd2Q pJGCCAfarEMWwiRiM4yM9h6n+lMgjDt5jj5QOB6mp2lJw2AwP3RnGT/hXPKTbLStohrysj8HLsfl B5Iz3PvWxpGmLGGuZ2XOMkt39xVXTbAvJ50wDc5JPOfan6lqOE8iLOBwSD/Kp62QLTVjdX1NrlvL jJKKeMdxWT1Pr9aA+Dk5NIMEHJ5p7aD3QmCST270nAXsD71ZtbOS5ZtmMKMkk4BNNuLV7dysgAbr wa0grsib00K/BHGKMdOevSjAIPrQfu5zzWr8iExMcYwevNB4IBo34GDmlAHp+tA0hqnJ9qQg8455 p3QZHU8YpvQ96T3FfUMADqPpTevfFKTwDjqaDj0xxxzSepSfUbj64pOc496XJxjrQRwcGsyug4HB 6cetO3DHQ1H25znvSb9vqfxoC2h1Oi3avAIyx3LxyeoqLX5VE8LMTjaQQO5NYNtcvbyhlz789RV3 VLtbuGFweQCCD2oJtqRRA7AASc9B6n/69WU3jZsHJOY8gckdc+wqlE+cKSQPX29q0FQYYNkADEpC 52jtimhSJVcOhyW8ssNwwMmT/CiZ8SMSWExAEpwMBfb3phRioKr+8xhV28bf7x96aICCp+8M5j+U 5kPofaq6k27lpEOxFCknrCMf6wd81KoGGYqMEYlyvER9qjUEAjOCfvyYP7o+gp4yMErgnGE5/ee5 p+YiQ4CBQzDHKSYOZfb1oLqASIzjB3W4JGD6mmAnJB5wMkgnEP8A9ekZ2ABJKkjiTJ/eY7UkFnYY XBVQH3bTmOTJwntTQ+WztZnONy55kHtxwKiy0khVVAIBLR5wBz1FKzkLhWyhOMjhh7DnpR6hrsQO S7kliI14Vxn5D6e5qdSBgkAORnBPDD1Y5pNiggZ6DgjkKPU+9N8pQA25grDII53fUdhSW+g3ewpc YGeVPU4yCR/d9K7LSEEGnRooAJAJB5IJrlLeEvcxqAFMhxvU5H0ArsVATABAAA70Sa6jS7ExPQ9T 3xVLVLloNOuJemEIH1PA/nUxfAznnPWsXxPOU0zYOrsAcdxUgm72ON3HAzkkHPWlx1z1I4NRnJGB n86UAkjJx2yaE0XbUfgE4J6dO3Fdn4P8JrqUB1K5X9yrYjUHqQeSa5aw097/AFK2tEI3zuF+gJ61 9IaNpFjbafFZQKqRxIWbA7Ack+5NbU43dzGrOysjiby38iLAAyeAAMYrIupJEtwrANzhc9TW9qco urxyv3FJCgenrWQcTzlCm5Y8DPcE9cV6HIoUr9WeVGo6ta3RHOpbymXMiHBJ5xXX6X4Si1yyaGAI kwUkEkAkgdDn1qhd2wijUx5KcEn09jWJJq8ouBhz5cZyADjkDg5FcjlZHoKDYmr+BdRsYpHZAGVs FAefrjvXKxGbTLgiZCYjxIh6Yz/Ou4h8YXM6mK7QzIowrA5IH9avXWmWep6fHcQKj+auSpwGrKXL J6GsbxRwuo2gntFniIYgZBHUr2/EVhY7DmunuYJdKMqKGkh52r0KmuakR4LgiZCrdSpGOtZtNOxp F3Wg3A9elX9NjzcBpEPlqpYkjjinQ3tqhyYwjAc4AINR3OomVSiKQh6nuadktRNvYla9YO0oOA3Q A9B2FQy3JcgknJ/SqoVnGApJ7YqVbS4cgBDn3o5mUopLUcLlgMA5prXDt1Jx2A7VImmXLnDFVyfW rcOlRjBZmY+nQUrsStcy/mc45J6irkGnysQXIUH8T+VaKQxxnCoBjjIqY8Ac8460WFd9CCO2ijAA QE92I5qfOcYI9OnFAGeppecDFFydeoYPTPPelXkYHBJoxkZIz24pVA6DqBRcElcAPm5HQZp6j2By aFXjjIPUnNV7q9jtFGTluy560i0m0SXd3HaR5JBY9FHeubmlaVzI5OSc8GnT3DyymSU5z0HpUPL4 JGB6UDUUtwUAglic54pc88mlzgZNJgY5+tWloD3uO7dc+lHbvn27UcDHHal98UAxwldFwrHg8YNB nd+GYsT1JOaZnAOcZ9KOgz60/MVluLnpjJo7dMevrSdsAigdwckdeKNLjsKuCSeeKXAzkH8KTtz+ FL36/jSEtBQQRjse5ppAB/lSHBNLznOQR0xT8g6C+55+lKOmec03Ixgdc+tGCByeaPQEjW0UZndi QMDPNaJI3Ek47Y61S0RATIQeSAAKvNE4VgQRznNYVr7nRh7X1GYUnlVHHpwaZ9nhcgMgI7Y7U8q+ cEE+59acI8vgYHHINZptOxtOKsYNwEEzbD8ucAkYqHJz05HSpZwBI6jkZPJqNSAOeTXX6nCOXBwM cmvRvAdt+8MnynanfjrXnkSkyADucZNeq+EYVg0wvtG4nr7CjrYio9DqjKQNqYXAyTnrUSyMzEhi f1p2/aS4BBIAHHSmKFQZXHvzVKy0ML6Dg+JCxJwB271GHaRiRjPbvk0gLAkc4PI+lEu3ACgg55IN Ca2BMkViikORuI5x0qjfTlLV9owMEk96sEk4CqQMc571m65Ky6bIdwHGB7UXSWpVux55ev598VyR lske9ep+D/Dvh7WNDAu7zyb3cRguBkY4ODXlUX72+Oc5DflW1GxQgqzAD0NVBNrQcz1S4+Fm6NXs dQRlPOXGBj2IzTZtD8T+F2EelzzS2+Nx2dM98iuKtPE+rWgRYr6dVUYA3kgD6GursPinqEIIuoEu OMA42n9KHGaXcjT0Ldn8Q9btn8u7sln2jLHaVYf0rG8Z+Mh4ltba3htnhWJy77mBzxgV19r4/wDD 12rGWAwzyIQzNGCM46ZHJFS6RoHhW8iDJJbzyspDYbAJPoDSTindoTUtnK6PGcYHQ+uaRjkjuSOO Old74o8Af2PaS38N2hgU9GGDk9APWuX0fQbvXrs21mELou4gnAx9a1Uk1ct6IyeOCD04rR0nUbmx uFe2dkYkcg4qze+FtWsmbzLWQBSQCFJBNUIEa2u4/OiYAMMgjHGaTs07CjOzuj6J0V5pdGtXuG3S tGCxPc4q7HGI12gk+5rP0fUbG8sYBbXEbYjA2hhkcdMVp1x6nZF3R8JNn0yCelHXHBFLg5PI/A9K aMZ4HB71V2yReSD0PvQSTgH8qBkggHoaM4IOOc015h1FwMcAilxjJ54PFJknPB69aDkAnH400xCg kHHGTSAnJyO/FJnJHPOKcSAfb2o1uO+gZ5OMZ9xS4PoM03p2PsAaXJ9T+dGtwTQYOcYINL3yOTjH Sk5xyTS5/wAk09gYZPTAwKcOFyQM9hSZGOOeOhNJtBIJz7ihbiFxgg5GD260uRgEEH1puAMg9+nN Jg4IAP502w8xxOR6HpSH7gGBTST0POe1OJAAyetJgtgyQMtxntSc5JAAH8qTOT3I6UoBJA6Y9qPM FYeOhwBjuakhtzcS/KCVXqajyXIiTk/zNWtxhj8pGwTySP1NYzk3oWkkhzuu4g8IvDY6Z9KfZW73 d1uOAOw7KKrKhnlCqCIwcdOp9a1mkXT7YBMGTHP1qLaD1JL64+zRGCJgD0GDyKwnYkkn160ryNKx d2JYnOT3pChJBOSPWhaD3G9z39afDAZ5BGowxpQFAIxk9vetuxs1gh8+QBcjJJ7Ch36CjvqEca2N uHLAKB065NYtxcNPIXbqx5qS+uzPMQpHlg4AzVM47EEegreEeVakSlzMRgAcDv6UvQAAdabnPHan bxwOgFXuTbsA64PQc0nJzx+Xen4+Yc9RTSMcdz3oHoJyByOaQknOehpcHGT1pnX1peYJK2oEHA5o wePfmlwc8HNSGJwM7CBj0pXDyIgOcdab37ZzTsEHkGkA55HFJoabG4IPXikx0OaeeOox+FKApOCA c0nEd9QwBjgGlI+THHWjBBPGR0zRu+XnoKnULjoI3dwFxwCST6VrxRYEblcgj90pXHmH3rHjbDHO Sucke9a0D+YhIYZx+8fHCj/Z96cbky1JmQbWydoyC77T8p/u/SkRiM9Fc/dGSPKx3/Go3LuQiLkZ +VcHMg9TT0QKSN4zgmSTJAI/u8jrVKxBMCmcEZQY3DcT5x9QO9O+Ygjdl/7/ADmEehqJJR8rc88R KW/1Y9TTmYn5SQB/y0YE4lPoKEHoKWOR8uV7dcTGo5MsSoALDlkIyIx7GnkuSQE5xxEQcxD1FQyA GMMQXj7OBhmPoe9PTcNLjV2+UMqXXkhQcNnuT7U7cRmUsMjq69R7AUxSTGxbJxwZAeVHoBTdxPQj I5BAwQPUj1pX1C3URizsATgEcbfX1IpwIVc5ODxuX+I+mPSopJUAy2Gz3Bwxx60ecHbGGcY5YDBU elF7DS6mtoyiXUA5CkxgnK8Ae2K6QnkEmuc8PqWlkcgBQAFyOfxrezkjJyKh6j80SeYQ31A5rnPE 82TCgOASScGtqRyGwDx61yuuyebfAZ4VR39aE9RpXZl5JJ2gYHc0HcSQBxjJFAJAIA5J/OgnJPPF MrU7H4eWivqcl64B8hcKT0yf64r1GfVGhspUR9rSgICT0BOSc1534XCQaXEY/keRixI79q6aEi6n Z5ixjjIAAIBY9SBmuuhHucGIldWGXBNmJDLkFM596W2hC26l1KtIN2fXNR61dxXHlREOrFiGZ8Ak DnFRHWWii2SASRgDaD1AHYV1VZ30ZyUKXLqiLWlu4bI/ZQJGJwwAzx7iuTM6TKEmgEbA8vGDnPuO laEt5LPevdI7xBiQqhiCq+la/hvRG1+9+wQovnOC6seOnXJ9K4JtSZ6cJOCMjSxcaZcfbbWaJ2Cl SjIGypGDkHrRb3jBgEYoQcgjjn6Vv+KPCR8P2sDi9ie4LFZYEJ3RkdCfUH1rl45CCNyBznp6/wBa ySaZd01oWtQuTdkGcKWIwWAx+dYGqgXMSrLkyR4CydSV9D9O1bUiRSRF0YpzjY5zg1mpb+fdiJjh X4wOcHsauTUlqKKa2KcWl26qGOXzyDng1OtpAmcRAe5GTRHFNCzBiCoJAGec1PkEgc5wO1TZjbGh VDAKABjsOlHIJ56U/YQQQp/GjbjIOM0mtAVn1GYwTyc84oB5H0p+M564FNAJz0/CkO2omOhGD9KO oz7Yp/HBPPpQEPPHB5Ap3YktbDcHnJAFKQSAR1zS7SRjgH3FI8kMRAdwvtmkFrDwMY49aXKjLHgD nntWfPq0KDEYLnJ56Cs2e9muG+Y4HoOlA1e5o3erIAyW4y3Td2FZDSMzF5Gy57nvTN4QkAAk1HuJ Ynvn0oSdy9LD87zk4NGc4xxTf0pwJ5P6mqXkK4ZJJzS9RxR2470mMDjPvTB76DuT/Sk6HFKBjqTR kEYx3607J7hbQX04o6HHBNNyCeecd6O4xzmhWEr9R2eR3/pSg8nB6U3kDoB/OlwRgj1osrjQZ5I6 4oPJB45pAOp9O9Lkng/nRYT7C5JODj16UYz6GkPUdBxz70Dn0H40bD12HYDEHB460gHUfzpFODn2 5FOHX+Z9qErsE9LEscrxMGQkEcgjrVgandoRmYkehql29ffNLjkY5NIWxrLrrgYMak/1qf8AtmEj /UEMRknPSsLAyDjOKOvsP1o5YvUcZStYkZ8uSeSSTmm8An0pvTuCPenDgj6dqoTuWbNPMulHGCa9 f0WJYNGt1yOQCfXnvXlOkIJLxFwDzjnn8a9dtNscMcQ6BQCSaXUymyyHAEnVlHc9KIpMDcSAD2Ip pIGSGUr0x0pN4fJIJBAzjHFPzM1qSlHZTKAWB4Bz0oEoWMkgDgj3zUCzGMsASQO2cCgSLISW9OBS TE13F8xwFJwfY9qwfEdyfsJUAYZucVsSOxGSOM+tcp4nnEWxUbcQM47Zp7rUpbmFZREXDHHHrnmt hBwcY+lZ2mhniLtySetbMMRkYBQCxwOnOa2pq0QkNCYAHPP8qDkEEdPaujk8G61HarObOQqwBBAz gfQVjzWU8DEMjKw4ORiq5ovZkX1KWTn055qWOeWJwyMVIOQQSCKCoxjBJqPByQccntVWVrsL6mld a7qd1ataz3s0kLEEo7Ej9a1fDHigeHRI62qyyuAAxONozzXMnBAAzwcGjp09cGk4pqw13Z7Pb/ET SL2MLsMcpbCiQZHuSR0rL17Qotd8S24hdPs0sYJkjUYB9Mjg15aCQcjIwex6Vp22valaweRBeSpG DnaG4B/pWXJbYG7noFz4AvrYK2nXH7xSedxGR/jXbeHLe+tdIjj1B2acE5LHJxXnfhfx3PZq0eoG a5LfcJbkfnXqlnM1xaRSsu0uoYj0yKwqXTszWkle58OEMMgA8deKZzkEnAHWtpdqK24AqB8xIFZ9 3PHKQIlCgdwO9RCXMdEo8u5TyckAjPXNOBPqCc/lSYB70oOBziqdyRVPBPOOvNLuXoenp600HkZ4 9KCBxx+OKaTDSwuMHjH0oJzxjpRkkkfn7UDAGR19qpCsGSAMY6UdQTnBAoOAMAjn2ozuGAceppbj 0uOAGzd+mOaQEZJJ4pDwQMg+lHAGCOT7UC0H8LyM+1OycYz7AdKYeowaXuSc5x0p6hoDYGCAM007 gRzwKTHOcc+gp2Tgg4xxz60PcL9BpBGcdT7UZOOeT2p3IBBBpAMjjOPWhAIuScAHk8U/O0YB5Oc+ 1AOxQwHIPFT2sIkYyyf6sckkZyaylLoXFaajo4hbxiV+WYYCj+VNmzxCDmR+WI6AdhTnm2AzEHHI iU84PrUmnWZmk3s2eMsT6Vn5srRlu2iW2tvNfIKj5QO59apSyvJISSS2c4J4FTXc/myBUOUHCjGP 0qDgkAE7scn1pXYvIjKgnJ49iaM8Y569qeQAPmPUcGmZUc/kKpXB6Ee5kIIPfjNSNe3DxbC5K9CM 1CeeScentTTzkDGK2jHQzbFzznvzn3puBnpRyBkdu+KXPr19MVSD1Adc5H0oyAM980oxkZOD1pvU k5oDQfnngg+tBwMkEk56UznP6UbsAD360X0GrMOrDJOP5UHpxjr60AE8/jUkULSyhUBJJ6UtROxY 0+0a4mDZwinkmtaZhuKqcgcelAgNnbCNRgnlif5VEwycjg4/CuepPWx0UqfVgViclXRSMdaqPYxu QqHbn15qcjnPOehz0xS3DrbWu4/6wnC4pQlJuxVSEEr9TGnRUlKqSQOMn1pinABJpWYu5Y5yTk0m CTnAHFdHSxzEy8jlsgd+1RuqgjnJ746U3qO+PSkzz04pNMOo7OPfPSrFtOYyoPzAHIHYGq2e3B96 kABGAQCORU6j3NVfmDspBYDMjgcKPag78qSpKnlYwTlj61Vt5SQAcNg8IOmfU1aWQl8CQ7+pfHEf 0/wqtLGdhfmMpzIBIwy7k8EensakV8sFCsyjIjhJOUP973pARgEjdGTkJk/vT6imuWDE7jvzliCd 0Y9KPQNh7YaNizFlH3phwSfTmmElWDZAbGcoeFX3HrSKdwAA3N/yzAO0j3PrScZwSDnIG8YLH1J9 BT6C0GbsMSSoI5BIII9z6mmeV5pILMQDkkEE5PQe5qwN235VY88ENnJ7nBqIkRyBgVcg4G8Y3H1p eo1cZ5UaE78krywK9fQZqVIlHGEAxlyrYz6CkkfCcFgqnGQchmPWm+aEPJVtvJJBBJ7flTFY3NLV o43LAgscnJ5A9K094GcADiszTlJtgxPLDJ59anZzypOAPSs76jSJWlzkg5Pv6VyOqSb9QkPUA4/K uiaUbcg1ydw/mXMjdQWP86F2LQmRwFJpMEkk803IHTr29qCxBI6nrkVWxSOq0fV1SCOLdho1wBXS 215DLbxRPMFY5YEDgE+vqa8zV8DcpIPqOCK07TWWiXZL8ygYHr9a3pVeXc5K9Fy1R6LLZvq0r3MQ Zo4gFB9Pr+VZGoWd1DkmImNRuZhyPQVo+GtdUaNJEoyxYk465PAqp4i8VXgul06xlU20MYEisgId upznnjp+FdE3Fq5z01KLszCWUhskAj0rXsddk0uZbiyme3uUPyOnp3BrFRxqd2I3RYCTy6HAB9xV i98P6nZKrkCSJj8rgcH05rkad9DrU7KzNifxHPqdy0moS+dI/JkOAR/9b2ptvLbGQMFDdcgrj8fr WFHp18WOAinsC2Kljtr5mWIlI2OQGZuM+mRRqCcVsbMENu8+4xK45yD3Poage0P2oSoFh2nKhT6d KpWtleq4ZpgoLEEDn9a6HU/DFxZ6RY6gzGQ3R8tG3ZAfOMH0NLldh86uVP7HN3p1zNCVeeNlZjkB QrEg5J6HNZr2y6VPLBdxsk7KCApyCDyKn1qw1LR5kttQWOGZl6owwwHrjrz3pwu5bsQmQgvGuwE8 5XtzRBu9mOSurouWcC3MZmhLBV6o4GM/U1cvfDEj6SuoMqxq0nlqCACxxknArR0PWbKALDchI48E u7R7skDrge+Kg1zV31aySzsrZI5DLkODjJPAA9M1vdWOfXm0OL8sJK0TsqMDkBuh+hqpJdW8bFWk AIPI70+6uGdp4rgYkiODyCQc461mXUBliJCjzFBOf7wrFxTXMjpu07MsNqtshyu5ieoxUMus8YjQ j03Gs5IJXwAucjIzUT7kbBxwecc4rLW+hokralqTUrl8gPgY7DmqrOWYlnyx6knJphznJPX0pMYz 3P0ppMNEP3qOnIHQ03eSAAMDvSYGMUvIOO9OwBjnjqaAOc45o445yaUZB68U1bYBOpyefandiD+A pOSeOvpRycUBqO52+nFGeMcn0xSc4ODSjOAMECmhWDORjoaBj1NKD+WKCM8An1oTYCZOQM5PejPT rmjoRzj3pc8enPHFHUQnIxk0vJxRk4HtQM4PpT8gAn5sHj1FHTP6Cm8k88elO4Oe1FwaFJz/AIUY 5H8qbz179KdnI96Q7oXHTOR7etGeOcZpMkj1NGPp+NP0DqL0PWnDrxknFN5wScUuTgAZ5odwFIyc flQDkYAP9KQHjPp2oBIGemO1CYk9RQQTkkemKcMA4J7cUmeASATnmlHU55B7elF2wt3Oj8KxB9Rj LADJHOM16btixgtgg8EDiuD8FwZuA5AIAzkDNd6oUSEBcFuFOOn1oRhN6jMKWOOSOvNO3iIgnOCM EVGytGxBYHbyCBUXLHc+cntTRKJd25sqcHOfwp2cyE4BAH5mo2CsCV6460xGIAwSSTyO1AbonJLj aAAB2J5rgvEb+Zdum7BBrtpJFSNjyDg5PvXnmpP51+2T1POR70m1YqCZo6fGEto8HIxz9c11Hhu0 F3rVpCFyGkAPPbNYFqm2NV29AM13fw7tln8Twnj92pbB+nFbvSBO7se1KoVAoHAHFVbrSrG9BFxa xSZ9UGau0VxXOvlTWp5h478KaXpekm+tE8qQuF2ZyDnPT0rzArkgnPHtXrnxTudum2dsOryFyPYD /wCvXk+GDEqa7KLbjqck0lLQh2YAPHPrSNnBx1zweuaewOeccdcUigkZBwc9TWtybobng8kY5PFK vzKSOF61at7Ga5fbAjOcZIUZ4+lSyadc2zBJYWTjoVwanmWw0rssaJb/AGnUYIlxlmAGfr0r6FhQ RwxoP4VArxPwPZmfxHbZGQpyT0xjmvcB0rlqu8jeitWfD15dhyYo+E7nuaoEkHqRxxS7txyOOOtB PGP1rNKysjRtydxM8dc568dKCTwPzwKTjFKM5wO3JppsNLACc8k4xS5OcZ4x0IpwA796QgA8HnNU gQvB5GelHQHNJjAGTgn1oBPJOPce1CuGguQemRx2pAMA9KvWVgbj52bEYH5+2asS6YjsfJbAxkAj vScknZgot7GWEPXnrxS8AjnnvVqTT5ogCQCD3HNVnRkJBU1W6ug20Y3dk+nvRnjg8560cf8A16To STyPpRcVkITk9RyaXoMZz3IowCODR2HHbseaEnYLCk8cE0oHyknGBz9aVQSRgkAetJzIQqjHPpUy l0Q4xvqx9tA13OFDADqSeABVqWUH92hxBH14+8aZu8qIwRHDNjcw9PSoXIJECHgHLHsTWXUq/YdE DdzBmzsB+UY/StG4lFtCYI3AZjliB2I6U2AC0tywGJCMKM8j3xVJ3LuSSSSefep1bKvZBu53ZxRv UAknJowpHBO4cnjimYDjBBB9fSgPIa5Y/MGB/pTGJcjnjHYUrnnaMcd6aRgcHrW8I9SJPWwvByOn TNIRlsAn0oxjrzz6UYOcVYmJnGQDg5ozjqfqTRjHXJoJG0jHGaESrgeWGOfpQRzxkZpDwARnk9aC TgZ/OgYvbAH40mMkccUue3PHSkHXAOaVhpqwZ56mrVpcm0lEmc4PIqqc4zj8qDknPShXEby6rBOx Eq7cnjmn77aZCUlACnGDxmufwcA4yaN5BODis3Tiy4zklZG/Iixjc8gCjmsW6uWuHzk7AcAUwzOw KsxIPIBPeosntkAHpTjBR2CUnLcOMnBJ9qXjcASQKXAwMDk96THQ5B9TWliQIxk9RScH/ClxzjsK TBJz0HQUW7how6DGQAfSlBwM56UgXPOeR/KjHBHX3pCJkkCsCCcE8gda0EKPjnIwdsackn1PvWUp 49qlilaMAgnk8gDkj61OwNX1RqhyDyVMhGcE4VPf2NRNtLDd8y543cFj6kjtUJuFeMgYAP8ADnBJ 9Se9NVzu4JIHUjjj+goQuXuSvK5BJJYZwTjJPsD6UecxydxHABA5Cj0FQead2QueOCO1H7wsBnaM d+g+tK/YLaakzTYJGACQBkDG0d+nc0w3S4A3NgDCjqAP8aiWNeNzE5PIBxgd6a/lgHaCC3QA5wP8 aA0B7licKCAOBxj8aYzHGCxJB4pmQnQcetCMzso4GSBn8aLsrTodNbSiO3jXdjgZ5608ygnqc/Wq WcAAGl3nAyTxz7VDvfUS3JZ5cRscngE8GuaJJBOQMmti7kP2Vyc9MdPWsft1qkupV0KGGO/uaCcn kmk7AeoqSOF5mCoMse3pVabsWo0EkhRyT27mpJLWWNVZlIB6fWte0sFgXewDSY/KroCgjI5+lFri cmZ2iC5t7oXCllC9ieCfpXVRDTruOZ5JPJu35yw4J9j2rK2AkYGMdTmjGD1JHYU4Sa0M5RUvUu2l hNpd3uvoWFvLHkPjggngj1rqrKW6t3jNuEvtPPLQ5yCPcdQa5D+0LoqiPcSOqLtRHYsFXPQA9B7V ENTawYywztA55Gw4yfpVqSsZum7HYX1lb3sLXFjuTax3278le/Ht71izIDGV27WBGRnPPY1UtvG9 07BWSCd+RudMMfxplxrEVzIzlVhcD7o6fh/hQmCi0tUWvOCQElmDA5GByDmopfFF1bWstuWE1s7F vJkJKh8YDAdiKz3vQLdmBDNIMADsPaufldmYryRnnPOKht30NYwW7NBr6Sd1kmdpG4IZiSQO45rQ S5MeHjfEZ5AIyQe4rBhO/AyOBkg1pIGEbLuRg6hhsOQDjofQ4p8qZrzWR0NrrkUuA0SsQeQQASPr 61qazLZAsukStJCFH+sXaQxHIz04NcppNot7eQwTSrCjuFMjjIXPc+1ek+MNN07Qfs0Fg0EimJSx jfcS+MEn0BxkV0Qhqkccp63PO9P0p76eQYYsSSxxxgfWpTZplomDZX7pA79x9K07O5keUK9wyg5B A4GPSlle0iaQKSzEEEDpn1zXXGjHlstyJVHzXexxV3O9ndSWwwVU5Uj0Pas0nLEnPrWhqpD3pGcl RgnH5Vn9Wx0+grzpRUZNHbF3SY3Gc9j/ADoyeTTsY96BnpU+Q9BMAgckHHpR14PNL6jkGkGcEZGc elJBdWEwAc54xxinc4+ppR0IxzR1zk9BzQwTG985OfelAOAMjnvRkZHXNLgH6k9adrh1LmnQebdj JUgcnNaUltCzk7FPPaquj8TuTwNvOK0NuDwc5PHrWFWTWxtRim9Sn9ggOcKwJ9+lQHS3LYRgSTwP atEEg49aUbj3IBOMjtUxqSNZUY2bRgTwPC5Vxgg1FnJA4q9qbBrggEEjgmqWBnjp6mulPqcdgHTH PvR7e+KXuDnn0pep96YPYb6DGfXFL0/pSZxken60uD3H6UaWBeYnPTP50YznGRTs5JAwR/KgDjHQ YoQadAB9+fSlyByO9IBkA8gig9CR64pahr0HcEjr9KQHJ47UYI64yRS8gYI568U2tA1aDGTnPHWg gE55HFKDySB0/WmjJwKVhX1DJOc5J7U5eWGSce3akAIwP5Cp4ULyqMHk880N9EHS53nhZWS23biM gY+ldSkilDyQcc/X2rG0KIRafGM5OMnNaTAEAggHqQDQvMxtce05JC5JY8YzTlcZ2nkng4HSoUIL kkAHHAxSCTYWHBz7dKrd6E2dycu2SAeMfnUW/aQTxgZ47VEWcupUcdjSPySTk+vvRbQa3G3cuLdm ySSDXDxp9p1dUyfmYA57c9a6zV3K6eeSMjAGeK5TT9z6gxBPAyMdqErtIroewx/DC4ks4Zba8jdm UMQegyM9apr4d8Q+H7j7TBDKrISA8fP8qztF8Zapo8LxxTNJuUKvmEkJ9BXTaf8AE+6iiCXtssrD +MHGfqK1an6oy0sLZ/ELWLFtl9CswBwdy7WH5V01n8RtKnX/AElJLc9yRkfmKrw+JPCutBVu4oo5 G5bzFA5+orL17QLfV9Xs7TTEWK3MRJmUcMfTPrisuWLdmrFKco7O5hePNet9c1eH7E++CGPbuIOC ScnA/KuRI45OD6g13DfDq+aT9zcRPHkgPkgn8K4+/tGs7+S2ZwxiYqcdMjrXRBJKyJT5m2yn0Ocn B70DOSeoPSnYAI9j+dAzkHGPUVQ7HonwxtBLqM1yw+5HgZHcmvTbnT7S7XbcW8cn+8oNcV8MIU/s y4lGNxYAj0613pGehrhm3zM6KcVy3MOy8MWWnat9stECAqQUHQE9xW9SDgUtS23uaRiktD//2Q== --_002_83d1c18c633149ffa7f7ff1e34838c1fustx2exdag1mb2msgcorpak_-- From nobody Wed Jul 29 05:50:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1777B1A8A76 for ; Wed, 29 Jul 2015 05:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, 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 BF__J78A9Os3 for ; Wed, 29 Jul 2015 05:50:14 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BC81A8A72 for ; Wed, 29 Jul 2015 05:50:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,570,1432591200"; d="scan'208";a="172014440" Received: from unknown (HELO [172.20.10.5]) ([37.165.110.148]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2015 14:50:09 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Benjamin Beurdouche In-Reply-To: <83d1c18c633149ffa7f7ff1e34838c1f@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Wed, 29 Jul 2015 14:50:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83d1c18c633149ffa7f7ff1e34838c1f@ustx2ex-dag1mb2.msg.corp.akamai.com> To: Rich Salz , Sean Turner X-Mailer: Apple Mail (2.2102) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] Our fearless leader X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2015 12:50:16 -0000 Wow, he brings the word fearless to another level =3DP > On 28 Jul 2015, at 01:11, Salz, Rich wrote: >=20 > Sean, at the CFRG meeting last week, wasn't bothered at all when all = the seats were taken. From nobody Thu Jul 30 03:30:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A811A89AB for ; Thu, 30 Jul 2015 03:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_25=0.6, 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 y9lud74Kd2yD for ; Thu, 30 Jul 2015 03:30:37 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3D21B29B2 for ; Thu, 30 Jul 2015 03:28:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mhnyM2Wdnz3Hd; Thu, 30 Jul 2015 12:28:27 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=M2LSThC6 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id n2Xan6f7rVBO; Thu, 30 Jul 2015 12:28:26 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 30 Jul 2015 12:28:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 85D8A80042; Thu, 30 Jul 2015 06:28:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438252105; bh=xUQvl9+N1fzGzvBmrTbzMSIC9yPzDxfrzwlieMuNZSI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=M2LSThC67rlDXXzVwmEzDLGgEK6qXiVc6yzYiUZQ1ucodkNOZQzgJY4256DrQiEyj +y1cG3pDRGH+auPStbqUhJp3yTjTtKu4ZHbCt1gF76q97u3HJ70pB6NE8YcRaX0l78 cALO4fa5xwQb4SwlQpciBtvahnt7ryESm2XwrW2w= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6UASO0g001584; Thu, 30 Jul 2015 06:28:24 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 30 Jul 2015 06:28:24 -0400 (EDT) From: Paul Wouters To: Melinda Shore In-Reply-To: <55B831D0.1080907@nomountain.net> Message-ID: References: <20150722171622.GH4347@mournblade.imrryr.org> <55B831D0.1080907@nomountain.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2015 10:30:38 -0000 On Tue, 28 Jul 2015, Melinda Shore wrote: > On 7/28/15 5:44 PM, Shumon Huque wrote: >> I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit >> more before considering DNSSEC key transparency issues. Agreed. >> It looks like that draft proposes SCT RRs (with DS+chain data in them, >> signed by log providers), so we could in the future incorporate SCT RRs >> in the chain. > > That draft really is pretty immature and at this point it's not > clear whether and how it's going to progress. Paul Wouters can > speak for himself about where he thinks the draft needs to go The current draft focussed on the container format of the data, but after some discussion in the dns and trans groups, it became clear that the more important question to answer first is what to log. Especially when you want to protect against a rogue parent, it becomes important to log zone cuts along with the keys so that consumers of the log can see the key/parent responsible for publishing the data. There are also issues with preventing spam/ddos attacks against the logs, similar but different from certificates. > Well, sort of. We did talk about creating a new certificate > extension rather than a TLS extension but opted not to. The > one advantage of an X.509 extension would have been that it wouldn't > require protocol changes, but it still would have required modifying > both the server and the endpoint. The TLS extension would be easier to configure than requiring the system administrator to regenerate (and re-sign?) certificates. Or mark certain data (the dnssec blob) as not covered by the certificate signature. People will end up putting the wrong certificate signatures in TLSA records, etc. The TLS extension separates this more cleanly, and only the TLS servers supporting the new extension need to know about how to generate and serve the dnssec blob. Aind finally, with raw public keys there is no way to embed the dnssec blob into the "certificate" payload, as it is defined (on purpose) to only contain the SPKI. Paul From contact@simonbernard.eu Fri Jul 31 07:42:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB131A894F for ; Fri, 31 Jul 2015 07:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-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 RO3W32o8TycL for ; Fri, 31 Jul 2015 07:42:32 -0700 (PDT) Received: from 1.mo54.mail-out.ovh.net (1.mo54.mail-out.ovh.net [178.33.45.132]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6B91A896E for ; Fri, 31 Jul 2015 07:42:23 -0700 (PDT) Received: from mail169.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo54.mail-out.ovh.net (Postfix) with SMTP id 6B612FF8D0E for ; Fri, 31 Jul 2015 16:42:21 +0200 (CEST) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 31 Jul 2015 16:41:02 +0200 Received: from 130.163-14-84.ripe.coltfrance.com (HELO ?10.41.51.97?) (contact@simonbernard.eu@84.14.163.130) by ns0.ovh.net with SMTP; 31 Jul 2015 16:41:01 +0200 Message-ID: <55BB88FD.4060901@simonbernard.eu> Date: Fri, 31 Jul 2015 16:41:01 +0200 From: Simon Bernard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 9871045958844037362 X-Ovh-Remote: 84.14.163.130 (130.163-14-84.ripe.coltfrance.com) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrtdelucdltddurdefkedvrddttddmucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrtdelucdltddurdefkedvrddttddmucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: [TLS] DTLS epoch and resume session/handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2015 14:46:23 -0000 Hi, I search in DTLS RFC 6347 if the epoch should be (re)set to 0 when we start a resume handshake, or if we keep the last used value, or the last used value+1 ? I can not any clue of that in the spec. Any idea ? Thx Simon From nobody Fri Jul 31 07:55:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E9F1A8972 for ; Fri, 31 Jul 2015 07:55:40 -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 sg0ArYTPsfkJ for ; Fri, 31 Jul 2015 07:55:39 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E331A89AC for ; Fri, 31 Jul 2015 07:55:33 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so61385199wic.0 for ; Fri, 31 Jul 2015 07:55:31 -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=N2mC+HlzP3xQLKMYAYSo9a9eC7w/En/4hLA+msoBp9o=; b=jmvznvZQofObRqpZ00/Dt8Tl+w7SD+/7pYf8/GeN6Lt4lo5EnqD+5yOgoe+cMvNrNI HeQi/CmK2fcpxW1iR1q7RnyxOV4LGF5xnnCSPxJ5CydPXq/L+ucHbupuoWY90zYRFOtg kypbar/Ri663L85TazfE9E6DNaMzfgezdJbxR7RYQQLIb/GhRKtkacVaWQGoVuy4b6W5 zKJJMKsQjXvJvt6+kbZQJ0MMeGw/OY6uMwbQ46sexZKDJcuTrs96AVvPcoQgudGuUkfJ kn5T1A+vbWBSIS/UTIT3zy6G3XdmdIwvzownrUsCHB/iBwgqMPkqpSJ4+FZf36K/Lwr/ 3UTQ== X-Gm-Message-State: ALoCoQmx2w/u0DmATlQtytTpDozpD0MicEMYtoyqL/5J98UicQmJSF2cgzrFIgYtcrWNlVuIEyAk X-Received: by 10.180.91.79 with SMTP id cc15mr7425570wib.53.1438354531894; Fri, 31 Jul 2015 07:55:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 31 Jul 2015 07:54:52 -0700 (PDT) In-Reply-To: <55BB88FD.4060901@simonbernard.eu> References: <55BB88FD.4060901@simonbernard.eu> From: Eric Rescorla Date: Fri, 31 Jul 2015 16:54:52 +0200 Message-ID: To: Simon Bernard Content-Type: multipart/alternative; boundary=f46d043be246ef59d6051c2d0207 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS epoch and resume session/handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2015 14:55:40 -0000 --f46d043be246ef59d6051c2d0207 Content-Type: text/plain; charset=UTF-8 The epoch is set to 0 at the start of each connection and then incremented with each handshake on that connection. -Ekr On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard wrote: > Hi, > > I search in DTLS RFC 6347 if the epoch should be (re)set to 0 when we > start a resume handshake, or if we keep the last used value, or the last > used value+1 ? I can not any clue of that in the spec. > Any idea ? > > Thx > Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043be246ef59d6051c2d0207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The epoch is set to 0 at the st= art of each connection and then incremented
with each handshake on that connection.
-Ekr
On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard = <contact@simonbernard.eu> wrote:
Hi,

=C2=A0 I search in DTLS RFC 6347 if the epoch should be (re)set to 0 when w= e start a resume handshake, or if we keep the last used value, or the last = used value+1 ? I can not any clue of that in the spec.
=C2=A0 Any idea ?

Thx
Simon

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

--f46d043be246ef59d6051c2d0207-- From nobody Fri Jul 31 09:42:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCEF1B2E7B for ; Fri, 31 Jul 2015 09:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 7LD2EUTm7g2Z for ; Fri, 31 Jul 2015 09:42:24 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5081B2E61 for ; Fri, 31 Jul 2015 09:42:15 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id EFE18414C; Fri, 31 Jul 2015 19:42:12 +0300 (EEST) Date: Fri, 31 Jul 2015 19:42:12 +0300 From: Ilari Liusvaara To: Nico Williams Message-ID: <20150731164212.GA28398@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> <20150626165415.GA28534@LK-Perkele-VII> <20150626184128.GG6117@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150626184128.GG6117@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2015 16:42:35 -0000 On Fri, Jun 26, 2015 at 01:41:29PM -0500, Nico Williams wrote: > > tls-unique depends on the Finished message strongly binding the entire > transcript up to that point. I find this elegant (despite the > resumption problem, which anyways, should be fixed by the session hash) > and easy to understand and analyze. > > If the Finished message no longer has this property in 1.3 then that's a > problem for tls-unique, and we'd have to fix one or the other. Surely > 1.3 will have some handshake message that binds the transcript, and why > that wouldn't be the Finished message is beyond me (but I am missing a > lot of the 1.3 context, so please forgive and inform me). Also, it turns out some are assuming tls-unique is both connection nonce and secret value. :-/ I don't think the present construct for Finished values is appropriate for such values, which means one would have to redefine tls-unique so it meets the need. (TLS-Exporter values already look to be secret and connection nonces, and I have already seen stuff relying on both properties). Basically, the value needs to derive from both "master secret" (to make it secret) and session hash /w configs (to make it connection nonce). -Ilari From nobody Fri Jul 31 09:55:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256CE1B2E59 for ; Fri, 31 Jul 2015 09:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 Ut_zRRci9Ikh for ; Fri, 31 Jul 2015 09:55:49 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA87B1A914B for ; Fri, 31 Jul 2015 09:55:49 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 4BB9420058D85; Fri, 31 Jul 2015 09:55:49 -0700 (PDT) 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=k++g8ZvSxgowas GY2AGJcwjJKPY=; b=ZfTwIU0adYt1vvYFTAEDpxKVifQBYcdqsa4gpMNamjblbS 6GGW8EaWWalbkM0xFuC+pSLWm84K8fqLpca/RtACS2fTKcx9kHP/GGkAJTDKfBxN OCf73Xd3R6tSoNLI6AwXkAh17g6jXerJX1FrACCDHM+b2Wap3BSoyhkm/6zYw= 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 CF71320058D82; Fri, 31 Jul 2015 09:55:48 -0700 (PDT) Date: Fri, 31 Jul 2015 11:55:48 -0500 From: Nico Williams To: Ilari Liusvaara Message-ID: <20150731165547.GI2957@localhost> References: <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> <20150626165415.GA28534@LK-Perkele-VII> <20150626184128.GG6117@localhost> <20150731164212.GA28398@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150731164212.GA28398@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2015 16:55:51 -0000 On Fri, Jul 31, 2015 at 07:42:12PM +0300, Ilari Liusvaara wrote: > On Fri, Jun 26, 2015 at 01:41:29PM -0500, Nico Williams wrote: > > tls-unique depends on the Finished message strongly binding the entire > > transcript up to that point. I find this elegant (despite the > > resumption problem, which anyways, should be fixed by the session hash) > > and easy to understand and analyze. > > > > If the Finished message no longer has this property in 1.3 then that's a > > problem for tls-unique, and we'd have to fix one or the other. Surely > > 1.3 will have some handshake message that binds the transcript, and why > > that wouldn't be the Finished message is beyond me (but I am missing a > > lot of the 1.3 context, so please forgive and inform me). > > Also, it turns out some are assuming tls-unique is both connection nonce > and secret value. :-/ RFC5929 quite rightly says not to do that. Do you have examples of apps doing this? (The Finished message is generally sent encrypted, so that's not that terrible an assumption.) > I don't think the present construct for Finished values is appropriate > for such values, which means one would have to redefine tls-unique > so it meets the need. I'd rather avoid this unless we really need to. Examples of applications mis-using tls-unique would be nice. > (TLS-Exporter values already look to be secret and connection > nonces, and I have already seen stuff relying on both properties). A proper TLS-Exporter can be used (was intended to be used!) as secret and whatever "connection nonces" are. > Basically, the value needs to derive from both "master secret" (to make > it secret) and session hash /w configs (to make it connection > nonce). Which Finished messages do! The only problem with Finished messages as secrets is that the cipher used might not provide confidentiality protection. (Again, I'm not endorsing the use of tls-unique as a secret.) If we have no such ciphersuites left in TLS 1.3... Nico -- From nobody Fri Jul 31 17:57:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FFC1A8A86 for ; Fri, 31 Jul 2015 17:57:20 -0700 (PDT) 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 6CdJ5JuU_VpO for ; Fri, 31 Jul 2015 17:57:17 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4386E1A8862 for ; Fri, 31 Jul 2015 17:57:17 -0700 (PDT) Received: by lblf12 with SMTP id f12so55039827lbl.2 for ; Fri, 31 Jul 2015 17:57:15 -0700 (PDT) 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=thAJIRLOi8Uo3b1SP820EBYScm1bFat2Ev5dn6Ljukw=; b=lyWA4oA9mD1T5ZI0wSGC5ZEYpFLJskIQRVh62KS+XGmX+aBO23Gl6AIINgCqQtutX2 ZV6p8VLFCaothUEEwewtYvF9Te167HHRziSvxReKB/q+xnm9ZBp02ZGq5K8aew1Ru2vP WrF2yBSYRee3vpgE7cIFFU6nJguekNefJvIZvSdKlZXuqwaYtZHMrGIG32TtXdlljU9R X0Sd2xgcaCcJpRRysTpKW6NF5b5Rmpm6qWTgtFqiCfqmgs0tdtpKd38d8tL/HDeDQ5WM JQ50v0zARhTvOz/8J/hhTGEL22vCrqMLr0g98Fzad8rH1eo2/potGxd1/RgDhNcVPJ4F OPGQ== X-Received: by 10.112.85.3 with SMTP id d3mr6144713lbz.33.1438390635641; Fri, 31 Jul 2015 17:57:15 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.151.131 with HTTP; Fri, 31 Jul 2015 17:56:46 -0700 (PDT) In-Reply-To: <11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com> References: <11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com> From: Hugo Krawczyk Date: Fri, 31 Jul 2015 17:56:46 -0700 X-Google-Sender-Auth: FphpsuhVVBNx0vSvghT2_mPD6co Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a1134946ce2c2c5051c356a9d Archived-At: Cc: "" Subject: Re: [TLS] Fwd: Summary of today's discussion on server-side signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Aug 2015 00:57:20 -0000 --001a1134946ce2c2c5051c356a9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am ok with whatever the WG decides, particularly when the reasons are non-cryptographic but rather based on implementation considerations. Still, for the record, I'd like to correct the statement " =E2=80=8B KnownConfiguration is only useful with 0-RTT. =E2=80=8B"=E2=80=8B. KnownConfiguration could be used with 1-RTT even if the client does not send early application data in the first flight. This would have allowed to save a signature also in the 1-RTT case whenever the client has cached a KnownConfiguration. Saving a signature is a major performance benefit with RSA signatures (are they really going away soon?) but is a benefit also with ECDSA as it avoids the need to send a certificate chain (shortening the handshake) and the need to verify these certificates. ECDSA also has a cost for the client. Lastly, the protocol would be secure without the signature (in the case the client uses a known configuration), a property that enables the use of the protocol with offline signatures (to-be-specified). Hugo On Mon, Jul 27, 2015 at 7:26 AM, Sean Turner wrote: > All, > > I asked ekr to write a brief summary of the server-side signing issue. > The summary provided matches the WG consensus as judged by the chairs. > Please let us know if you object to the way forward by August 3rd. > > J&S > > Begin forwarded message: > > > From: Eric Rescorla > > Subject: Summary of today's discussion on server-side signing > > Date: July 22, 2015 at 08:52:31 EDT > > To: Sean Turner > > > > Sean, > > > > Here's a summary of today's discussion on signing and KnownConfiguratio= n. > > > > SUMMARY > > The WG agreed that the server must sign whenever certificate > authentication > > is used (even if the KnownConfiguration is used). > > > > > > BACKGROUND > > The current draft requires the server to send a > Certificate/CertificateVerify > > whenever either: > > > > (a) The KnownConfiguration option is not in use. > > (b) The server sends a ServerConfiguration > > > > but it does not need to sign if the KnownConfiguration option is in > > use but no new ServerConfiguration is provided. Several people (most > > recently Martin Thomson) have suggested that it would be simpler to > > just require the server to sign any time certificate-based > > authentication is in use. The penalty for this is an extra sign/verify, > > as shown in the following table: > > > > Scenario Client Server > > ------------------------------------------------------------------ > > 1-RTT 1 (EC)DHE + Verify 1 (EC)DHE + Sign > > > > 0-RTT (current, 2 (EC)DHE 2 (EC)DHE > > no new config) > > > > 0-RTT (current, 2 (EC)DHE + Verify 2 (EC)DHE + Sign > > new config) > > > > 0-RTT (proposed) 2 (EC)DHE + Verify 2 (EC)DHE + Sign > > > > > > So, the performance difference here is between line 2 and line 4, > > since whenever you provide a new config (line 3) you have to sign > > anyway. The benefit is that it makes the server side of the handshake > > essentially identical in both 0-RTT and 1-RTT, which is nice from an > > implementation and analysis perspective. > > > > > > SUMMARY OF WG DISCUSSION > > During the WG discussion today, there was rough consensus to adopt > > this change (i.e., always sign). A number of arguments were advanced > > in favor of this change. > > > > (1) It's significantly simpler for implementors and (at least informal) > > analysis. A side benefit is being able to merge the extension > > logic for 0-RTT and KnownConfiguration, since > =E2=80=8B=E2=80=8B > KnownConfiguration > > is only useful with 0-RTT. > > > > (2) It extends the properties we were shooting for with online-only > > signatures and requiring that the server always sign > ServerConfiguration, > > namely continuous proof of access to the signing key. > > > > (3) The performance cost of an extra ECDSA signature is small and > > shrinking fast (per Ian Swett channelling Adam Langley), and > > people who care about speed will cut over to ECDSA (certs are > > readily available). > > > > (4) You can still do 0-RTT with PSK resumption, which is computationall= y > > much faster. > > > > On balance the WG seemed to feel that these were more compelling than > > the performance value of the optimization. > > > > There was also a recognition that signature amortization was valuable, > > but the consensus was that instead of doing this here, it would be > > better to adopt Hugo's suggeston from a while back to have a > > certificate extension that allowed offline signatures. This allows > > both amortization *and* delegation, while not constituting a threat > > to existing TLS 1.2 implementations. We agreed that this could be > > worked in in parallel but shouldn't hold up TLS 1.3. > > > > Per WG guidance, I'll be preparing a draft PR for this. > > > > -Ekr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1134946ce2c2c5051c356a9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am ok with whatever the WG decides, particula= rly when the reasons are non-cryptographic but rather based on implementati= on considerations.

Still, for the reco= rd, I'd like to correct the statement "
=E2=80=8B
KnownConfiguration=C2=A0is only useful with 0-RTT.
=E2=80=8B"=E2=80=8B.=C2=A0

<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;font-si= ze:small">
KnownConfig= uration could be used with 1-RTT even if the client does not send early app= lication data in the first flight.
This would have al= lowed to save a signature also in the 1-RTT case whenever the client has ca= ched a KnownConfiguration.
Saving a signature is a major pe= rformance benefit with RSA signatures (are they really going away soon?) bu= t is a benefit also with ECDSA as it avoids the need to send a certificate = chain (shortening the handshake) and the need to verify these certificates.= ECDSA also has a cost for the client.

Lastly, the protocol would be secur= e without the signature (in the case the client uses a known configuration)= , a property that enables the use of the protocol with offline signatures (= to-be-specified).

Hugo

On Mon, Jul 27, 2015 at 7:26 AM= , Sean Turner <turners@ieca.com> wrote:
All,

I asked ekr to write a brief summary of the server-side signing issue.=C2= =A0 The summary provided matches the WG consensus as judged by the chairs.= =C2=A0 Please let us know if you object to the way forward by August 3rd.
J&S

Begin forwarded message:

> From: Eric Rescorla <ekr@rtfm.com>
> Subject: Summary of today's discussion on server-side signing
> Date: July 22, 2015 at 08:52:31 EDT
> To: Sean Turner <turners@ieca.c= om>
>
> Sean,
>
> Here's a summary of today's discussion on signing and KnownCon= figuration.
>
> SUMMARY
> The WG agreed that the server must sign whenever certificate authentic= ation
> is used (even if the KnownConfiguration is used).
>
>
> BACKGROUND
> The current draft requires the server to send a Certificate/Certificat= eVerify
> whenever either:
>
> (a) The KnownConfiguration option is not in use.
> (b) The server sends a ServerConfiguration
>
> but it does not need to sign if the KnownConfiguration option is in > use but no new ServerConfiguration is provided.=C2=A0 Several people (= most
> recently Martin Thomson) have suggested that it would be simpler to > just require the server to sign any time certificate-based
> authentication is in use. The penalty for this is an extra sign/verify= ,
> as shown in the following table:
>
> Scenario=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server
> ------------------------------------------------------------------
> 1-RTT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = (EC)DHE + Verify=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01 (EC)DHE + Sign
>
> 0-RTT (current,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A02 (EC)DHE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 (= EC)DHE
>=C2=A0 =C2=A0no new config)
>
> 0-RTT (current,=C2=A0 =C2=A0 =C2=A0 =C2=A0 2 (EC)DHE + Verify=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A02 (EC)DHE + Sign
>=C2=A0 =C2=A0new config)
>
> 0-RTT (proposed)=C2=A0 =C2=A0 =C2=A0 =C2=A02 (EC)DHE + Verify=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A02 (EC)DHE + Sign
>
>
> So, the performance difference here is between line 2 and line 4,
> since whenever you provide a new config (line 3) you have to sign
> anyway. The benefit is that it makes the server side of the handshake<= br> > essentially identical in both 0-RTT and 1-RTT, which is nice from an > implementation and analysis perspective.
>
>
> SUMMARY OF WG DISCUSSION
> During the WG discussion today, there was rough consensus to adopt
> this change (i.e., always sign). A number of arguments were advanced > in favor of this change.
>
> (1) It's significantly simpler for implementors and (at least info= rmal)
>=C2=A0 =C2=A0 =C2=A0analysis. A side benefit is being able to merge the= extension
>=C2=A0 =C2=A0 =C2=A0logic for 0-RTT and KnownConfiguration, since
=E2=80=8B=E2=80=8B
KnownConfiguration
>=C2=A0 =C2=A0 =C2=A0is only useful with 0-RTT.
>
> (2) It extends the properties we were shooting for with online-only >=C2=A0 =C2=A0 =C2=A0signatures and requiring that the server always sig= n ServerConfiguration,
>=C2=A0 =C2=A0 =C2=A0namely continuous proof of access to the signing ke= y.
>
> (3) The performance cost of an extra ECDSA signature is small and
>=C2=A0 =C2=A0 =C2=A0shrinking fast (per Ian Swett channelling Adam Lang= ley), and
>=C2=A0 =C2=A0 =C2=A0people who care about speed will cut over to ECDSA = (certs are
>=C2=A0 =C2=A0 =C2=A0readily available).
>
> (4) You can still do 0-RTT with PSK resumption, which is computational= ly
>=C2=A0 =C2=A0 =C2=A0much faster.
>
> On balance the WG seemed to feel that these were more compelling than<= br> > the performance value of the optimization.
>
> There was also a recognition that signature amortization was valuable,=
> but the consensus was that instead of doing this here, it would be
> better to adopt Hugo's suggeston from a while back to have a
> certificate extension that allowed offline signatures. This allows
> both amortization *and* delegation, while not constituting a threat > to existing TLS 1.2 implementations. We agreed that this could be
> worked in in parallel but shouldn't hold up TLS 1.3.
>
> Per WG guidance, I'll be preparing a draft PR for this.
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

--001a1134946ce2c2c5051c356a9d-- From nobody Fri Jul 31 18:01:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DE61A906F for ; Fri, 31 Jul 2015 18:01:41 -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 A-ZGM2z-Mljq for ; Fri, 31 Jul 2015 18:01:38 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61181A9034 for ; Fri, 31 Jul 2015 18:01:37 -0700 (PDT) Received: by wibud3 with SMTP id ud3so75723932wib.1 for ; Fri, 31 Jul 2015 18:01:36 -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=d3WZvxiyr/QYjT4VVwcIyOKTfLKlNgQVbPadsg4oSs4=; b=RQtQAV/F0MQDRnM7ZSpp/I9peWgQytb/AE+qBE2YhYOpUVbYSWfRlzAKVLhfy4z6Ki JRrs7HA/uQO85IhKpIr7MoUpkw0+2Vbzxx/8dQIZawkLuwOGRUlmvh8IujwbJUldJOw4 vFikH3iFDfrtotCcS7tczKtuK4Yqe0QBtIJBhsuUMwJPs6z2TKH6xjsMCqHS3SwGQiEv P1vzH18jgerDgNEP+gxiRvtI6pfTb6QkZyjAXJfo2yNZbxpCDuD7jdl0qiqtYNzz3I2S /svWIaDwJmycOFNHqItB9q3z3YOx6OaU9UzXbD7H3Uw5RFfmqeU6YVQYGcn8DBoUREgB JZoA== X-Gm-Message-State: ALoCoQmi7Es756gknts1BhrWMOHvM7Y3+6MsquZNvDplOYwMReMBPBj5FDWUpEUV91LkHx5knyWi X-Received: by 10.194.216.68 with SMTP id oo4mr11169707wjc.81.1438390896541; Fri, 31 Jul 2015 18:01:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Fri, 31 Jul 2015 18:00:57 -0700 (PDT) In-Reply-To: References: <11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com> From: Eric Rescorla Date: Fri, 31 Jul 2015 18:00:57 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=089e0141a0926fd799051c357ac5 Archived-At: Cc: "" Subject: Re: [TLS] Fwd: Summary of today's discussion on server-side signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Aug 2015 01:01:41 -0000 --089e0141a0926fd799051c357ac5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 5:56 PM, Hugo Krawczyk wrote: > I am ok with whatever the WG decides, particularly when the reasons are > non-cryptographic but rather based on implementation considerations. > > Still, for the record, I'd like to correct the statement " > =E2=80=8B > KnownConfiguration is only useful with 0-RTT. > =E2=80=8B"=E2=80=8B. > > KnownConfiguration could be used with 1-RTT even if the client does not > send early application data in the first flight. > This would have allowed to save a signature also in the 1-RTT case > whenever the client has cached a KnownConfiguration. > Saving a signature is a major performance benefit with RSA signatures (ar= e > they really going away soon?) but is a benefit also with ECDSA as it avoi= ds > the need to send a certificate chain (shortening the handshake) and the > need to verify these certificates. ECDSA also has a cost for the client. > This was very bad writing on my part. What I was trying to say was that once you commit to signing every transaction, then it's not helpful to use the KnownConfiguration mechanism with 1-RTT because you've already given up the optimizations you quite rightly point out. Sorry for the confusion. Lastly, the protocol would be secure without the signature (in the case the > client uses a known configuration), a property that enables the use of th= e > protocol with offline signatures (to-be-specified). > Thanks for pointing this out. Best, -Ekr Hugo > > On Mon, Jul 27, 2015 at 7:26 AM, Sean Turner wrote: > >> All, >> >> I asked ekr to write a brief summary of the server-side signing issue. >> The summary provided matches the WG consensus as judged by the chairs. >> Please let us know if you object to the way forward by August 3rd. >> >> J&S >> >> Begin forwarded message: >> >> > From: Eric Rescorla >> > Subject: Summary of today's discussion on server-side signing >> > Date: July 22, 2015 at 08:52:31 EDT >> > To: Sean Turner >> > >> > Sean, >> > >> > Here's a summary of today's discussion on signing and >> KnownConfiguration. >> > >> > SUMMARY >> > The WG agreed that the server must sign whenever certificate >> authentication >> > is used (even if the KnownConfiguration is used). >> > >> > >> > BACKGROUND >> > The current draft requires the server to send a >> Certificate/CertificateVerify >> > whenever either: >> > >> > (a) The KnownConfiguration option is not in use. >> > (b) The server sends a ServerConfiguration >> > >> > but it does not need to sign if the KnownConfiguration option is in >> > use but no new ServerConfiguration is provided. Several people (most >> > recently Martin Thomson) have suggested that it would be simpler to >> > just require the server to sign any time certificate-based >> > authentication is in use. The penalty for this is an extra sign/verify= , >> > as shown in the following table: >> > >> > Scenario Client Server >> > ------------------------------------------------------------------ >> > 1-RTT 1 (EC)DHE + Verify 1 (EC)DHE + Sign >> > >> > 0-RTT (current, 2 (EC)DHE 2 (EC)DHE >> > no new config) >> > >> > 0-RTT (current, 2 (EC)DHE + Verify 2 (EC)DHE + Sign >> > new config) >> > >> > 0-RTT (proposed) 2 (EC)DHE + Verify 2 (EC)DHE + Sign >> > >> > >> > So, the performance difference here is between line 2 and line 4, >> > since whenever you provide a new config (line 3) you have to sign >> > anyway. The benefit is that it makes the server side of the handshake >> > essentially identical in both 0-RTT and 1-RTT, which is nice from an >> > implementation and analysis perspective. >> > >> > >> > SUMMARY OF WG DISCUSSION >> > During the WG discussion today, there was rough consensus to adopt >> > this change (i.e., always sign). A number of arguments were advanced >> > in favor of this change. >> > >> > (1) It's significantly simpler for implementors and (at least informal= ) >> > analysis. A side benefit is being able to merge the extension >> > logic for 0-RTT and KnownConfiguration, since >> =E2=80=8B=E2=80=8B >> KnownConfiguration >> > is only useful with 0-RTT. >> > >> > (2) It extends the properties we were shooting for with online-only >> > signatures and requiring that the server always sign >> ServerConfiguration, >> > namely continuous proof of access to the signing key. >> > >> > (3) The performance cost of an extra ECDSA signature is small and >> > shrinking fast (per Ian Swett channelling Adam Langley), and >> > people who care about speed will cut over to ECDSA (certs are >> > readily available). >> > >> > (4) You can still do 0-RTT with PSK resumption, which is computational= ly >> > much faster. >> > >> > On balance the WG seemed to feel that these were more compelling than >> > the performance value of the optimization. >> > >> > There was also a recognition that signature amortization was valuable, >> > but the consensus was that instead of doing this here, it would be >> > better to adopt Hugo's suggeston from a while back to have a >> > certificate extension that allowed offline signatures. This allows >> > both amortization *and* delegation, while not constituting a threat >> > to existing TLS 1.2 implementations. We agreed that this could be >> > worked in in parallel but shouldn't hold up TLS 1.3. >> > >> > Per WG guidance, I'll be preparing a draft PR for this. >> > >> > -Ekr >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> _______________________________________________ >> 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 > > --089e0141a0926fd799051c357ac5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 5:56 PM, Hugo Krawczyk <hugo@ee.technion.= ac.il> wrote:
I am ok w= ith whatever the WG decides, particularly when the reasons are non-cryptogr= aphic but rather based on implementation considerations.

Still, for the record, I'= d like to correct the statement "
= =E2=80=8B
KnownConfigurat= ion=C2=A0is only useful= with 0-RTT.
=E2=80=8B"=E2= =80=8B.=C2=A0

= KnownConfiguration could be used with 1-RTT even if the client does not sen= d early application data in the first flight.
This would have allowed to save= a signature also in the 1-RTT case whenever the client has cached a KnownC= onfiguration.
Saving a signature is a major performance benefit with RSA signatures= (are they really going away soon?) but is a benefit also with ECDSA as it = avoids the need to send a certificate chain (shortening the handshake) and = the need to verify these certificates. ECDSA also has a cost for the client= .

This was very bad writing on = my part. What I was trying to say was that
once you commit to sig= ning every transaction, then it's not helpful to
use the Know= nConfiguration mechanism with 1-RTT because you've
already gi= ven up the optimizations you quite rightly point out. Sorry for the
confusion.



Lastly, the protocol = would be secure without the signature (in the case the client uses a known = configuration), a property that enables the use of the protocol with offlin= e signatures (to-be-specified).

Thanks for pointing this out.

Best,
-Ekr

Hugo
=
On Mon, Jul= 27, 2015 at 7:26 AM, Sean Turner <turners@ieca.com> wrote:
All,

I asked ekr to write a brief summary of the server-side signing issue.=C2= =A0 The summary provided matches the WG consensus as judged by the chairs.= =C2=A0 Please let us know if you object to the way forward by August 3rd.
J&S

Begin forwarded message:

> From: Eric Rescorla <ekr@rtfm.com>
> Subject: Summary of today's discussion on server-side signing
> Date: July 22, 2015 at 08:52:31 EDT
> To: Sean Turner <turners@ieca.com>
>
> Sean,
>
> Here's a summary of today's discussion on signing and KnownCon= figuration.
>
> SUMMARY
> The WG agreed that the server must sign whenever certificate authentic= ation
> is used (even if the KnownConfiguration is used).
>
>
> BACKGROUND
> The current draft requires the server to send a Certificate/Certificat= eVerify
> whenever either:
>
> (a) The KnownConfiguration option is not in use.
> (b) The server sends a ServerConfiguration
>
> but it does not need to sign if the KnownConfiguration option is in > use but no new ServerConfiguration is provided.=C2=A0 Several people (= most
> recently Martin Thomson) have suggested that it would be simpler to > just require the server to sign any time certificate-based
> authentication is in use. The penalty for this is an extra sign/verify= ,
> as shown in the following table:
>
> Scenario=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server
> ------------------------------------------------------------------
> 1-RTT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = (EC)DHE + Verify=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01 (EC)DHE + Sign
>
> 0-RTT (current,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A02 (EC)DHE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 (= EC)DHE
>=C2=A0 =C2=A0no new config)
>
> 0-RTT (current,=C2=A0 =C2=A0 =C2=A0 =C2=A0 2 (EC)DHE + Verify=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A02 (EC)DHE + Sign
>=C2=A0 =C2=A0new config)
>
> 0-RTT (proposed)=C2=A0 =C2=A0 =C2=A0 =C2=A02 (EC)DHE + Verify=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A02 (EC)DHE + Sign
>
>
> So, the performance difference here is between line 2 and line 4,
> since whenever you provide a new config (line 3) you have to sign
> anyway. The benefit is that it makes the server side of the handshake<= br> > essentially identical in both 0-RTT and 1-RTT, which is nice from an > implementation and analysis perspective.
>
>
> SUMMARY OF WG DISCUSSION
> During the WG discussion today, there was rough consensus to adopt
> this change (i.e., always sign). A number of arguments were advanced > in favor of this change.
>
> (1) It's significantly simpler for implementors and (at least info= rmal)
>=C2=A0 =C2=A0 =C2=A0analysis. A side benefit is being able to merge the= extension
>=C2=A0 =C2=A0 =C2=A0logic for 0-RTT and KnownConfiguration, since
=E2= =80=8B=E2=80=8B
KnownConfiguration
>=C2=A0 =C2=A0 =C2=A0is only useful with 0-RTT.
>
> (2) It extends the properties we were shooting for with online-only >=C2=A0 =C2=A0 =C2=A0signatures and requiring that the server always sig= n ServerConfiguration,
>=C2=A0 =C2=A0 =C2=A0namely continuous proof of access to the signing ke= y.
>
> (3) The performance cost of an extra ECDSA signature is small and
>=C2=A0 =C2=A0 =C2=A0shrinking fast (per Ian Swett channelling Adam Lang= ley), and
>=C2=A0 =C2=A0 =C2=A0people who care about speed will cut over to ECDSA = (certs are
>=C2=A0 =C2=A0 =C2=A0readily available).
>
> (4) You can still do 0-RTT with PSK resumption, which is computational= ly
>=C2=A0 =C2=A0 =C2=A0much faster.
>
> On balance the WG seemed to feel that these were more compelling than<= br> > the performance value of the optimization.
>
> There was also a recognition that signature amortization was valuable,=
> but the consensus was that instead of doing this here, it would be
> better to adopt Hugo's suggeston from a while back to have a
> certificate extension that allowed offline signatures. This allows
> both amortization *and* delegation, while not constituting a threat > to existing TLS 1.2 implementations. We agreed that this could be
> worked in in parallel but shouldn't hold up TLS 1.3.
>
> Per WG guidance, I'll be preparing a draft PR for this.
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

_______________________________________________
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


--089e0141a0926fd799051c357ac5--